Vitalik: Ethereum’s account abstraction

Account abstraction allows us to use smart contract logic to specify the effects of transactions, as well as fee payment and validation 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 methods of account abstraction have been proposed and implemented to varying degrees, see: EIP-86, EIP-2938‌, and this article two years ago‌. Today, development of these EIPs is deadlocked as developers want to focus on merging and sharding, and ERC-4337‌, an alternative that doesn’t require any consensus changes, has come a long way.

ERC-4337 attempts 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 and packaged into a single transaction by the block proposer or the builder who generates bundles for the block proposer. Proposers or builders are responsible for filtering actions to ensure they only accept actions that pay a fee. There is a separate mempool storage pool for user actions, and nodes connecting to this pool undergo ERC-4337-specific validation to ensure that user actions can pay before forwarding them.

Vitalik: Ethereum's account abstraction

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

  1. Existing users cannot upgrade without moving all their assets and activities to the new account;
  2. Additional gas overhead (~42k for basic UserOperation and ~21k for basic transaction);
  3. Less benefit from in-protocol censorship-resistant techniques (e.g. crLists), which target transactions and miss user operations

A realistic way to achieve the best results is to start supporting ERC-4337 strongly in the short term, and then add EIPs over time to compensate for its weaknesses . This does not necessarily require a specific commitment to comply with ERC-4337. Instead, the in-protocol support can be designed to be more general and support ERC-4337 and its alternatives and improvements.

Here, I will list some of these EIPs and show in what order they can be implemented.

Convert EOA wallet to smart contract wallet

In order to upgrade existing EOA wallets to ERC-4337 wallets, we can make an EIP that allows EOA to perform operations that set its contract code. Once EOA does this, the transition is irreversible. From then on, the account will only be used as a smart contract wallet. Fortunately, since ERC-4337 accounts are DELEGATECALLproxies , 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 been introduced as an official EIP, but the method is simple: add a new EIP-2718‌ transaction type, just replace the account code with calldata.


EIP-5003‌ is an extension proposal to EIP-3074‌ ( AUTHand AUTHCALL) that introduces AUTHUSURPnew opcodes. If using the EIP-3074 mechanism, EOA address A has authorized another address B to act on its behalf, then B is AUTHUSURPallowed to set A’s code.

This approach is more complicated than the “replace code” route, which only makes sense if we intend to adopt EIP-3074.


In the longer term, we may want to do a coercion 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 whereby, starting from a certain block, accounts without a code are considered 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 will convert 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.


  1. 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 to a contract and then its verification key is changed, the original key is still able to “represent” the account in these specific contexts. This can be done by starting to encourage all such projects to change to use EIP-1271 verification instead of using ECRECOVER if the account has a code.
  2. Accounts that have not yet been detected : One challenge with coercion is accounts that own assets (such as ERC20 s, ERC721 s, but not ETH) but have not yet sent or received any transactions, so the protocol cannot reliably detect these accounts. The protocol must 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.
  3. 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-transferability. Fundamentally, this is a bad idea and incompatible with the goal of moving to smart contracts for improved security. Therefore, this practice should not be encouraged, and applications should be encouraged to rely on the original owner recovery procedure to render the transfer unenforceable.

Reduce gas cost

ERC-4337 wallets face higher gas costs (~42,000 gas for basic ERC-4337 operations and 21,000 gas for basic regular transactions) for the following reasons:

1. There are significant individual storage read/write costs that are bundled into a 21000 gas payment in the case of EOA:

(1) Edit the storage slot containing pubkey+nonce (~5000);

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

(3)ECRECOVER (~3000);

(4) First access to the wallet itself (~2600)

(5) First visit to the payee account (~2600)

(6) Transfer ETH to the recipient’s account (~9000)

(7) Edit storage to pay fees (~5000)

(8) Access the storage slot containing the agent (~2100), then access the agent itself (~2600);

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

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

4. One-time contract creation cost (about 32,000 gas, plus 200 gas per code byte in the proxy, plus 20,000 gas for setting the proxy address)

Many of these issues will be automatically addressed in the Verkle tree witness gas cost EIP‌ and write gas cost reform EIP‌, replacing massive storage costs with a leaner system. For example, pubkey and nonce can be stored in slots 0…63, which reduces the cost of accessing them below 1000. Users will pay less when transferring ETH and paying fees because the destination and receiving accounts only need to be accessed once for the first time.

There are many more EIPs that can help us simplify. E.g:

  1. Prohibiting smart contract logic from using a voluntary ERC for slot 0 would allow it to be used for storage proxies, allowing it to benefit from cheaper gas costs.
  2. The “code address” field can make the proxy easier and consume less gas.
  3. “snappy compression” precompilation makes it easier to use ABI objects without paying the calldata gas cost for all zero bytes.

This is an area that needs more research.


This is a long-standing issue, as crLists only really apply when a full protocol proposer/builder separation scheme is enabled. The challenge is that we want proposers to identify user actions that are “worthy” of inclusion (i.e. they pay enough fees) 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 “enforcement” be explicit in the protocol. For user actions, there must be a defined method to validate the action, and a defined method to perform the action, such that if an action is validated, an attempt to perform the action will be guaranteed to pay, unless The read state is modified during verification. 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 treat ERC-4337 as a final standard, but instead incorporates a weaker concept supported by ERC-4337 that other largely different ERCs can easily support as well.

The reason is that the complexity of ERC-4337 and EIP-2938 is largely related to solving the problem of stronger DoS resistance: it is impossible to make one operation cancel hundreds of other operations, as this would allow cheap garbage to the mempool Transactional attack. This requires imposing restrictions on what account verification can access. Here we can do something simpler: just record which state objects were touched during validation, and if any of these state objects are edited, they don’t need to be included.

This allows individual accounts to choose their own trade-offs between censorship resistance and flexibility. In extreme cases, accounts can pay fees during verification through Uniswap if they so desire, but since anyone can send transactions that affect the state of Uniswap, there is effectively no censorship resistance guarantee for such accounts.

The rough outline of the crList design is as follows:

  1. Proposals can contain one crList, which specifies a list of operations to include, and a list of state object (key, value) pairs that each operation reads. crListThe builder (or anyone else) that accepts must check that all operations pass the validatecheck.
  2. The block is required for every operation in the execution unless the block does not have enough gas remaining, or the current state at the time of execution has edited one of the state objects read by the operation.crList

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

One disadvantage of this approach is that it is not fully compatible with signature aggregation (as ERC-4337 tries to do): because the protocol does not “understand” the aggregation scheme, it cannot enforce aggregation, malicious builders may incorporate unaggregated operations, and Force the sender to pay the full gas for it. But the inconvenience can be said to be modest.

possible roadmap

short term

  1. Bring ERC-4337 into full production. Ideally, it could be extended with signature aggregation functionality for rollup friendliness.
  2. There should be an easy-to-use browser wallet with access to ERC-4337.
  3. Consider implementing signature aggregation and compression to make ERC-4337 more L2 friendly;
  4. Guide the ERC-4337 ecosystem in the L2 protocol, in which the gas cost problem will be less;

medium term

  1. Implement Verkle tree, add EIP to reduce gas cost;
  2. Add optional EOA-to-ERC-4337 conversion;
  3. Add crList logic at the same time or shortly after PBS rollout;


  1. Consider coercion;

possible alternatives

  1. Consider writing an EIP that includes ERC-4337 equivalent accounts and transactions at the protocol layer and drive its adoption in L2;
  2. Use a censorship-resistant solution that works through axuliary blocks, eliminating the need for user actions to make the Ethereum protocol readable;

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-06-28 00:25
Next 2022-06-28 00:26

Related articles