Partnered With:

Vitalik: The road to account abstraction in Ethereum

Read this article in 18 Minutes

A realistic path to achieve the best results is to start with strong support for ERC-4337 in the short term, then add EIPs over time to compensate for its weaknesses.

Original title: "Vitalik: The Road to Account Abstraction in Ethereum"

Original Author: Vitalik Buterin

Original Compilation: Overnight Porridge, the Way of the Metaverse

Account abstraction allows us to use smart contract logic to specify the effects of transactions, as well as fee payment and verification logic. This brings a number of important security benefits, such as multi-signature and smart recovery wallets, the ability to change keys without changing wallets, and quantum security.

Many approaches to account abstraction have been proposed and implemented to varying degrees, see: EIP-86, EIP-2938, and this article from two years ago. Today, the development of these EIPs has stalled as developers want to focus on merging and sharding, while ERC-4337‌, an alternative that does not require any consensus changes, has made great progress.

ERC-4337 tries to achieve the same thing as EIP-2938 with additional protocol means. Users need to send off-chain messages called user operations, which are collected in batches by the block proposer or the builder that generates bundles for the block proposer and packaged into a single trade. Proposers or builders are responsible for filtering operations to ensure they only accept operations that pay a fee. There is a separate mempool for user actions, and nodes connecting to this pool do ERC-4337-specific validation to ensure user actions are paid before they are forwarded.

ERC-4337 can do many things as a purely voluntary ERC. However, it is weaker than a true in-protocol solution in a few key areas:

- Existing users cannot upgrade without moving all their assets and activities to the new account;

- additional gas overhead (basic UserOperation UserOperation ~42k vs. ~21k for base transactions);

- Less benefit from in-protocol censorship-resistant techniques (e.g. crLists) which target transactions and will miss user operation (user operation)

A realistic way to achieve the best results, It is to start with strong support for ERC-4337 in the short term, and then add EIPs over time to make up for its weaknesses. This does not necessarily require everyone to specifically commit to complying with ERC-4337. Instead, in-protocol support can be designed to be more generic and support ERC-4337 and its alternatives and improvements.

Here I will list some of these EIPs and explain in what order they can be implement.

Convert EOA Wallet to Smart Contract Wallet

In order to upgrade the existing EOA wallet to ERC-4337 wallet, we can make an EIP that allows EOA to execute Set the operation of its contract code. Once EOA has done this, the shift is irreversible. From then on, the account will only be used as a smart contract wallet. Fortunately, since ERC-4337 accounts are DELEGATECALL proxies, the wallet can later be converted to other ERC-compatible smart contracts if desired.

There are some proposals on how to implement this upgrade process:

1. "replace code" transaction type

This has not yet been introduced as an official EIP, but the method is simple: add a new EIP-2718‌ transaction type, just pass The account code is replaced by calldata.

2, AUTH_USURP (EIP-5003)

EIP-5003‌ is an extension proposal to EIP-3074‌ (AUTH and AUTHCALL) , which introduces the new AUTHUSURP opcode. If using the EIP-3074 mechanism, EOA address A has authorized another address B to act on its behalf, then AUTHUSURP allows B to set A's code.

This method is more complicated than the "replace code" route, only if we intend to use EIP- 3074, this makes sense.

Forced conversion

In the longer term, we may want to do a mandatory conversion to simplify the protocol and make contracts the only account type, removing ECDSA from the protocol. One possible approach is to add an override rule, starting from a certain block, accounts without a code are treated as accounts with a specific standardized "ERC-4337 EOA wallet" code.

This can be done through a "poking" process, where any transaction originating from an EOA converts it, and any transaction that touches an EOA with a non-zero nonce will Convert it. It can also be done by going through the entire state at once.

Question

In-Contract ECRECOVER Verification: Some smart contracts rely on the assumption that if you provide a signature of ECRECOVER to a particular account, you own that account . If the EOA is converted into a contract, and then its verification key is changed, the original key will still be able to "represent" the account in these specific contexts. This can be done by starting to encourage all such projects to change to using EIP-1271 verification instead of ECRECOVER if the account has a code.

Accounts not yet detected: One challenge with the cast is having assets (like ERC20s, ERC721s, but not ETH) but not yet sending or receiving any transactions, so the protocol cannot reliably detect these accounts. The protocol must either retain the ability to permanently convert such accounts to the default wallet, or there needs to be a deadline (e.g. 4 years after deployment) after which accounts that have not been converted will be burned.

EOA only checks for non-transferability: Some applications implement in-contract checks to only allow EOA to interact with them. This is usually to enforce non-assignment. This is fundamentally a bad idea and incompatible with the goal of moving to smart contracts for increased security. Therefore, this practice should not be encouraged, and apps should be encouraged to rely on the original owner recovery procedure to make the transfer impossible.

Reduce Gas Cost

ERC-4337 wallets face higher gas costs (basic ERC-4337 operations are about 42000 gas, while basic regular transactions require 21000 gas), the reasons are as follows:

1. You need to pay a lot of single storage read/write costs, in the case of EOA, these costs will be Bundled into a payment of 21000 gas:

(1) Edit to include pubkey+nonce ( ~5000) storage slot;

(2) User operation call data cost (about 4500, which can be reduced to about 2500 through compression);

(3) ECRECOVER (~3000) ;

(4) first access to wallet itself (~2600)

(5) first access to payee account (~2600)

(6) will ETH transferred to beneficiary account (~9000)

(7) edit storage to pay fee (~5000)

(8) access storage slot containing proxy (~2100) , and then access the proxy itself (~2600);

2. In addition to the above storage read/write costs In addition, the contract also needs to execute "business logic" (unpack UserOperation, hash it, shuffle variables, etc.)

3. Need to consume gas to pay the log fee (EOA does not publish logs);

4. One-time contract creation cost (about 32000 gas, plus 200 gas for each code byte in the proxy, plus 20000 gas for setting the proxy address)

Many of these issues will be automatically resolved in the Verkle tree witness gas cost EIP‌ and write gas cost reform EIP‌, replaced by a leaner system Large storage costs. For example, pubkeys and nonces can be stored in slots 0…63, which reduces the cost of accessing them to under 1000. Users will pay less when transferring ETH and paying fees, because the target and receiving accounts only need to be accessed once for the first time.

There are many more EIPs to help us simplify. For example:

Disallowing smart contract logic from using slot 0's voluntary ERC will allow it to be used for storage Proxy, thus enabling it to benefit from cheaper gas costs.

The "code address" field makes proxying easier and consumes less gas.

"snappy compression" precompilation makes it easier to use ABI objects without paying the calldata gas cost for all the zero bytes.

This is an area that needs more research.

crLists

This is a long-term problem, because crLists only really apply when a full protocol proposer/builder separation scheme is enabled. The challenge is that we want proposers to be able to identify user actions that are "worthy" of inclusion (i.e. they pay enough) so that the protocol can force them to be included in the next block that has room.

This requires that the concepts of "validation" and "execution" be made explicit in the agreement. For user actions, there must be a defined way to validate the action, and a defined way to perform the action, such that if an action is validated, attempts to perform the action will be guaranteed to pay unless The read state is modified during validation. These operations can be implemented by embedding ABI methods, or by adding a dedicated EOF section if the EOF EIP is implemented.

Fortunately, this does not require us to consider ERC-4337 as a final standard, but is a weaker concept supported by inclusion in ERC-4337, which can also be easily supported by other largely different ERCs.

The reason is that the complexity of ERC-4337 and EIP-2938 is largely related to solving Stronger DoS resistance problem: it is impossible to make one operation cancel hundreds of other operations, because this would allow cheap transaction spam attacks on the mempool. This requires imposing restrictions on what account verification can access. Here, we can do something simpler: just log which state objects were touched during validation, and don't need to include if any of those state objects were edited.

This allows individual accounts to choose their own tradeoff between censorship resistance and flexibility. In extreme cases, accounts can pay fees during verification via Uniswap if they wish, but since anyone can send transactions that affect the state of Uniswap, such accounts have effectively no censorship-resistant guarantees.

The general outline of the crList design is as follows:

A proposal can contain a crList, which specifies the list of operations to include, and the state object (key, value) pair read by each operation list of. A builder (or anyone else) who accepts a crList must check that all operations pass the validate check.

Each operation in the crList requires the block, unless the block does not have enough remaining gas, or the current state at the time of execution is already One of the state objects read by this operation was edited.

The remaining complexity of ERC-4337 will only be used for mempool security. In principle, there could be multiple competing ERCs that achieve this goal in different ways, as long as they all adhere to the same verification and enforcement standards.

One disadvantage of this approach is that it is not fully compatible with signature aggregation (as ERC-4337 try to do): since the protocol doesn't "understand" the aggregation scheme, it cannot force aggregation, and a malicious builder could incorporate operations that are not aggregated and force the sender to pay full gas for it. But the inconvenience is arguably modest.