Ethereum Account Abstraction and ERC-4337

Author: Madoka Kaname, IOBC Capital

In the Ethereum system, there are actually two types of accounts:

One is the externally-owned account (EOA), controlled by a private key, such as the accounts in our wallets, which have their own balances. The owner can send messages from their external account by creating and signing a transaction;

The other is the contract account, controlled by code deployed on the blockchain, governed by the Ethereum Virtual Machine code stored within the smart contract account (sometimes referred to as a smart wallet). When a contract account receives a message, its internal code is activated, allowing it to read and write to internal storage and create new contracts, among other operations.
According to the current Ethereum protocol, only external accounts can initiate transactions, and only the account owner is allowed to modify its account state.

What is Account Abstraction?

Account abstraction is an improvement on the two types of accounts mentioned above, attempting to blur the lines between them into a universal account that includes complex logic, allowing accounts to have the functionalities of both contract accounts and external accounts.

This approach essentially allows users to define external accounts in the format of contract accounts, enabling users to include any logical verification within a smart contract wallet. Accounts controlled by keys can also gain support from code.

Various Solutions for Account Abstraction

Achieving account abstraction has long been a vision of the Ethereum developer community. The community has proposed various solutions, such as EIP-86, EIP-2938, etc.

EIP-86 prepares the technical groundwork for account abstraction by defining a new account type that allows users to create accounts based on smart contracts.

The Ethereum protocol itself requires that everything be packaged into transactions originating from ECDSA-secured external accounts (EOA), with each user operation needing to be wrapped in a transaction from an EOA, incurring a cost of 21,000 gas. Users need to hold ETH in a separate EOA to pay for gas.

The account abstraction proposed by EIP-86 introduces a new type of transaction that, unlike traditional transactions which must have an EOA as the sender, does not have a sender. This type of transaction disrupts the uniqueness of transaction hashes. EIP-86 was initially planned for the Metropolis upgrade, but due to the aforementioned issues, developers decided to postpone its introduction in Metropolis.

EIP-2938 provides a solution for account abstraction by modifying part of the Ethereum protocol, allowing contract accounts to initiate transactions just like external accounts. However, this solution has not been widely accepted because it requires changes to the consensus layer of the Ethereum protocol.

The later proposed new protocol ERC-4337 offers a solution that aims to achieve the same effect as EIP-2938 without changing the consensus protocol, and this more secure implementation has garnered more attention in the community.

How Does ERC-4337 Work?

ERC-4337 does not attempt to modify the protocol consensus but instead replicates the functionality of the mempool within the system.

Users send a UserOperation object, which includes the user's intent, signature, and other data. User operations have a separate mempool storage pool, and nodes connected to this storage pool perform ERC-4337-specific validations to filter operations, ensuring they only receive operations that pay fees.

Miners or packagers using Flashbots services collect these user operations in bulk, package them into a single bundle transaction, and include them in Ethereum blocks. Packagers pay the gas fee for bundle transactions in Ethereum and are compensated by the fees paid for each individual UserOperation. Packagers will use fee priority logic to select which UserOperation objects to include.

The UserOperation looks like a transaction, but it is an ABI-encoded structure that includes the following fields:

1. Sender: the wallet performing the operation;

2. Nonce and signature: parameters passed to the wallet verification function so that the wallet can verify the operation;

3. InitCode: initialization code used to create the wallet if it does not yet exist;

4. CallData: data used to execute the actual steps calling the wallet.
   Each wallet is a smart contract and must include two functional functions:

5. validateUserOp, which takes a UserOperation as input. This function should verify the signature and nonce in the UserOperation; if verification is successful, it pays the fee and increments the nonce; if verification fails, it throws an exception;

6. An op execution function that parses the calldata into one or more instructions for the wallet to execute.

Changes Brought by ERC-4337

If this proposal is widely adopted, signature verification will be moved to the Ethereum Virtual Machine (EVM), with the validateUserOp function adding arbitrary signature and randomness verification logic, making the verification logic more flexible.

This way, new cryptographic tools can be used at the time of signing transactions, and wallets can provide some new functionalities, such as:

1. Multi-signature;
2. Social recovery;
3. More efficient and simpler signature algorithms (e.g., Schnorr, BLS);
4. Post-quantum secure signature algorithms (e.g., Lamport, Winternitz);
5. Upgradeable wallets.

This solution also opens up various other transaction permission management options, such as allowing transactions to pay gas fees through smart contracts.
Currently, external wallets can only pay gas fees for interactions on Ethereum using ETH in the wallet; if your wallet only contains ERC-20 tokens and no ETH, you will not be able to transfer those tokens out. After the adoption of ERC-4337, users can use ERC-20 tokens in their accounts to pay fees, with miner nodes acting as intermediaries to pay ETH on-chain and obtain the user's ERC-20 tokens.

After the implementation of abstraction, signing transactions and broadcasting them by the owner of an external account will no longer be the only way to initiate transactions. This will create possibilities for Ethereum to act as a relayer for meta-transactions. Currently, many applications on Ethereum rely on relayers to publish user transactions on the blockchain and pay fees to the relayers. If wallets can incorporate more complex contracts, some relayers may no longer be necessary, eliminating the need to pay them additional fees.

Although there are many advantages, the new solution also faces some issues.

The most prominent one is the higher gas cost; basic ERC-4337 operations require about 42,000 gas, while conventional transactions require 21,000 gas, for the following reasons:

1. A significant amount of individual storage read/write costs need to be paid; in the case of EOA, these costs are bundled into a payment of 21,000 gas:
   (1) Editing a storage slot containing pubkey+nonce (~5000);
   (2) User operation call data cost (about 4500, which can be reduced to about 2500 through compression);
   (3) ECRECOVER (~3000);
   (4) First access to the wallet itself (~2600);
   (5) First access to the recipient's account (~2600);
   (6) Transferring ETH to the recipient's account (~9000);
   (7) Editing storage to pay fees (~5000);
   (8) Accessing a storage slot containing the proxy (~2100), then accessing the proxy itself (~2600);

2. In addition to the above storage read/write costs, contracts also need to execute "business logic" (unpacking UserOperation, hashing it, shuffling variables, etc.);

3. Gas is required to pay for log costs (EOA does not publish logs);

4. One-time contract creation costs (about 32,000 gas, plus 200 gas for each code byte in the proxy, and an additional 20,000 gas for setting the proxy address).
   In short, every step of the account abstraction address requires computation, consumes more resources, and increases additional costs.

Fortunately, this is not without solutions.

Since Rollups excel at data compression, they have a natural fit with the data complexity of account abstraction solutions.

In Vitalik's latest proposal, it is suggested to handle the data generated by account abstraction through layer 2. The improvement lies in packaging functionalities that can only be implemented step by step into batch transactions while using SNARK technology to ensure transaction validity.

By combining ERC-4337 with Rollup technology, data compression and reduced gas costs can be achieved in account abstraction, better leveraging the advantages of account abstraction.

Conclusion

With Ethereum's focus on developing Layer 2 now established, Vitalik's subsequent plans for Ethereum upgrades have begun to shift towards account abstraction. The latest proposal showcases the rollup + account abstraction technical path. Various Rollup providers have also launched new versions compatible with account abstraction.

In June of this year, zkSync released V2 update information: adding "account abstraction" functionality and increasing compatibility with the Ethereum EVM. In October, ERC-4337 released a new version, adding signature aggregation functionality, including the BLS signature algorithm. Signature aggregation allows builders and batch submitters to also aggregate signatures (e.g., BLS, SNARKs), significantly reducing on-chain data and lowering data costs for rollups.

We have reason to believe that the changes brought by account abstraction also harbor the potential for ecological explosion. With the development of Rollups, account abstraction that can be combined with Rollups is sure to evolve into more optimal and refined solutions.