IOBC Capital: Ethereum Account Abstraction and ERC-4337

Author: Madoka Kaname, IOBC Capital

There are two types of accounts that actually exist in the Ethereum system:

• One is an externally-owned account (EOA), controlled by a private key—such as the wallet accounts we commonly use. These accounts each have their own balance. The owner can create and sign a transaction to send messages from their EOA.

• The other is a contract account, controlled by code deployed on the blockchain. It is governed by Ethereum Virtual Machine (EVM) code stored within a 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 internal storage and create new contracts.

Under the current Ethereum protocol, only externally owned accounts can initiate transactions, and only the account owner is allowed to modify the account's state.

What Is Account Abstraction?

Account abstraction is an enhancement of these two account types, aiming to blur the boundary between them and create a generalized account with complex logic, enabling an account to possess both contract and external account functionalities.

This approach effectively allows users to define externally owned accounts using the format of contract accounts, enabling them to include any logic validation within a smart contract wallet. Even key-controlled accounts can gain support from code.

Approaches to Account Abstraction

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

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

The Ethereum protocol requires all content to be packaged into transactions originating from ECDSA-secured external accounts (EOAs), where each user operation must be wrapped in a transaction from an EOA, incurring a fixed gas cost of 21,000. Users need to hold ETH in a separate EOA to pay for gas.

The account abstraction introduced by EIP-86 proposed a new type of transaction. Unlike traditional transactions requiring an EOA as sender, these transactions have no sender. However, this breaks the uniqueness of transaction hashes. Originally planned for inclusion in the Metropolis upgrade, developers decided to defer its implementation due to these issues.

EIP-2938 offers a solution for account abstraction by modifying parts of the Ethereum protocol to allow contract accounts to initiate transactions like EOAs. However, since this requires changes at the consensus layer, it has not gained widespread acceptance.

A newer proposal, ERC-4337, provides a way to achieve similar results without modifying the consensus protocol. This safer implementation has attracted more attention within the community.

How Does ERC-4337 Work?

Instead of modifying the consensus protocol, ERC-4337 replicates the functionality of the mempool within the system.

Users send a UserOperation object, which includes their intent, signature, and other data.

UserOperations are stored in a dedicated mempool. Nodes connected to this mempool perform ERC-4337-specific validation to filter operations, ensuring they only accept those that pay fees.

Miners or bundlers using services like Flashbots batch collect these UserOperations, package them into a single bundle transaction, and include it in an Ethereum block. The bundler pays the gas fee for the bundled transaction on Ethereum, then recoups the costs by collecting fees paid by each individual UserOperation. Bundlers prioritize which UserOperations to include based on fee incentives.

A UserOperation resembles a transaction but is an ABI-encoded structure containing the following fields:

1. Sender: the wallet performing the operation;

2. Nonce and Signature: parameters passed to the wallet’s validation function so it 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 steps by calling the wallet.

Each wallet is a smart contract and must implement two functions:

1. validateUserOp, which takes a UserOperation as input. This function should verify the signature and nonce within the UserOperation. If validation succeeds, it pays the fee and increments the nonce; otherwise, it throws an exception;

2. Execution function, which parses calldata into one or more instructions for the wallet to execute.

Changes Brought by ERC-4337

If widely adopted, signature verification will move onto the Ethereum Virtual Machine (EVM). The validateUserOp function introduces arbitrary signature and nonce verification logic, making validation more flexible.

This enables the use of new cryptographic tools when signing transactions and allows wallets to offer new features 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 approach also enables various other transaction authorization mechanisms, such as allowing transactions to pay gas fees via smart contracts.

Currently, gas fees for interactions on Ethereum must be paid in ETH from an external wallet. If your wallet holds only ERC-20 tokens and no ETH, you cannot transfer those tokens out. With ERC-4337, users could pay fees using ERC-20 tokens in their account. Miners or bundlers would act as intermediaries, paying ETH on-chain and receiving the user’s ERC-20 tokens in return.

Once abstraction is implemented, having the external account owner sign and broadcast a transaction will no longer be the sole method to initiate transactions. This opens the possibility for Ethereum to serve as a relay for meta-transactions. Currently, many Ethereum applications rely on relayers to publish user transactions and pay fees. If wallets can embed more complex contracts, some relayers may become unnecessary, eliminating the need to pay them extra fees.

Despite its advantages, the new scheme also faces challenges.

The most prominent issue is higher gas costs. A basic ERC-4337 operation requires about 42,000 gas, compared to 21,000 gas for a standard transaction, due to the following reasons:

1. High costs from numerous individual storage read/write operations, which in the case of EOAs are bundled into a flat 21,000 gas payment:

(1) Editing the storage slot containing pubkey+nonce (~5,000 gas);

(2) UserOperation call data cost (~4,500 gas, compressible to ~2,500);

(3) ECRECOVER (~3,000 gas);

(4) First access to the wallet itself (~2,600 gas);

(5) First access to the recipient account (~2,600 gas);

(6) Transferring ETH to the recipient account (~9,000 gas);

(7) Editing storage to pay fees (~5,000 gas);

(8) Accessing the storage slot containing the proxy (~2,100 gas), then accessing the proxy itself (~2,600 gas);

2. In addition to the above storage costs, the contract must execute "business logic" (unpacking the UserOperation, hashing it, shuffling variables, etc.);

3. Gas is consumed for log fees (EOAs do not emit logs);

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

In short, every step involving an abstracted account requires computation, consuming more resources and incurring additional costs.

Fortunately, this is not unsolvable.

Rollups excel at data compression, making them naturally compatible with the data-intensive nature of account abstraction.

In Vitalik's latest proposal, Layer 2 is suggested to handle the data generated by account abstraction. The improvement lies in batching what would otherwise be step-by-step operations into bundle transactions, while using SNARKs to ensure transaction validity.

By combining ERC-4337 with rollup technology, data compression and reduced gas costs can be achieved in account abstraction, better unlocking its potential.

Conclusion

With Ethereum's strategic focus firmly on Layer 2, Vitalik's roadmap for future upgrades is now shifting toward account abstraction.

Recent proposals highlight the rollup + account abstraction technical path. Various rollup providers have already released new versions supporting account abstraction.

In June, zkSync announced its V2 update, adding “account abstraction” functionality and improved compatibility with the Ethereum EVM.

In October, ERC-4337 released a new version introducing signature aggregation with BLS. Signature aggregation allows bundlers and batch submitters to also aggregate signatures (e.g., using BLS or SNARKs), significantly reducing on-chain data and lowering data costs for rollups.

We have good reason to believe that the changes brought by account abstraction harbor the potential for ecosystem breakthroughs. As rollups evolve, account abstraction integrated with rollups will surely develop even more optimized and refined solutions.