Account Abstraction: Use Cases, Technical Overview, and Security Considerations

Written by Kevin Coyle on May 15, 2023.

In this blog post, we’ll do a quick tour of an important draft ERC standard that is getting a lot of attention, known as EIP-4337: Account Abstraction. What is it, and why is it useful?

TL;DR: Account abstraction is the concept of using smart contracts to represent Ethereum accounts, which provides a workaround to some existing limitations of EOAs. Under this model, users can implement their own customized account security (instead of being restricted to ECDSA signatures and nonces as dictated by the Ethereum protocol), and contracts can pay for gas.

What is account abstraction?

In the Ethereum network, all transactions must be originated by an Externally Owned Account (EOA). To prove that the account owner was the originator of a transaction, the transaction message must be signed using the private key associated with the account; the ECDSA signature can then be verified by anyone on the network using the EOA’s public key.

The current approach to transaction message signing is limited in two ways:

• There is only one way to authorize a transaction in Ethereum — using an ECDSA signature.
• There is only one type of account from which a transaction can originate — an EOA.

The idea behind account abstraction is to generalize the concept of an account in order to remove these limitations. Instead of using an EOA to initiate and authorize transactions, this functionality can be abstracted into a smart contract, allowing for customization of the security scheme. Under this model, users can implement their own arbitrary transaction authorization logic directly within the account contract, and the need for users to have EOAs is eliminated.

Why is this useful?

Here are some example use cases for account abstraction:

• Customized authorization: Ethereum transaction signing is currently done using ECDSA. Account abstraction enables any arbitrary authorization logic to be used, which allows for alternate cryptographic schemes to be chosen. This provides some future-proofing in case a weakness is found in ECDSA and a different algorithm needs to be chosen to maintain security.
• Gas abstraction: EOA-initiated transactions require the account owner to purchase ether and store it in their wallet to pay for gas. With account abstraction, transactions initiated from a contract account can be paid for by the owner or by a third party known as a paymaster, which is an entity that pays the gas fees for a transaction. The use of paymasters also lowers the barrier to entry for inexperienced users because the paymaster can be funded with fiat currency off-chain, and the account owner does not need to deal with ether directly.
• Social recovery wallets: Losing your private key and backup seed phrase means losing access to your wallet and its funds. With account abstraction, you can program an account contract with a backup owner address controlled by a trusted party (e.g., a family member) or use a multisig scheme that would allow the wallet to be recovered.
• Transaction bundling: If a user wishes to do multiple transactions, an EOA account must submit them separately. For example, a staking contract may have separate unstake() and withdraw() functions, and a user wishing to exit the contract must submit two separate transactions from their wallet. With account abstraction, transactions can be batched within contract accounts.

What’s the current state of account abstraction?

The idea of account abstraction has been around in the Ethereum community for a long time, going back to EIP-86 where it was first proposed. There have been several attempts so far to implement this feature, but it’s not an easy problem, and prior proposals have recommended changes to the Ethereum protocol itself, which would require a hard fork.

The Ethereum Foundation put forth EIP-4337 as their proposal for how to implement account abstraction without changing Ethereum’s consensus layer protocol. This is a key advantage over prior proposals because it could be immediately deployed on any EVM-compatible network with no fork required.

After two rounds of security audits, which can be found here and here, in March 2023 the EntryPoint contract went live on Ethereum mainnet, and is actively being used to handle user operations. The contract address is 0x0576a174D229E3cFA37253523E645A78A0C91B57. The Ethereum Foundation has also deployed EntryPoint contracts to other EVM-compatible chains. An up-to-date list from Etherscan can be found here.

Technical overview

To avoid changes to the Ethereum protocol, EIP-4337 introduces its own transaction type called a UserOperation, and an associated new mempool for these transactions. Multiple UserOperations from different users are bundled together for execution, and sent to a special contract named EntryPoint; each chain that supports EIP-4337 will have a single EntryPoint contract. For each operation, the EntryPoint contract calls the associated contract account to validate the transaction, and then executes the calldata if everything checks out.

A UserOperation contains normal transaction fields such as to and callData that specify which contract to invoke and the data to send. Like a normal transaction, it also contains signature and nonce fields, but how these fields are used is up to the implementer of the contract account. Additional fields specify the sender (the account performing the operation), gas amounts and limits, and any optional paymaster data.

Analogous to miners taking transactions from the Ethereum mempool and putting them into blocks, bundlers monitor the UserOperation mempool and create UserOperation bundles. Bundlers perform pre-execution checks to ensure that each transaction is valid and pays for its gas fees, otherwise the bundler could lose money. Bundlers then send validated batches of operations to the EntryPoint contract for execution on-chain. Note that this step involves creating a normal Ethereum transaction to call the EntryPoint contract’s handleOps function. Anyone can be a bundler, but the expectation is that block proposers or validators will take on the bundler role.

Security considerations

The EntryPoint contract is the core of EIP-4337. Users, bundlers, and paymasters all directly or indirectly interact with this contract. It handles validation and execution of all user operations, verifies that the correct gas fees are collected, and ensures that bundlers are correctly compensated. All the EIP-4337 protocol contracts were initially audited by OpenZeppelin in April 2022 and a second audit was performed in January 2023 to examine new features and changes. As EIP-4337 is under active development, users of this protocol should watch for re-audits to make sure they are happening whenever the core code is modified.

Before submitting a batch of UserOperation transactions on-chain, bundlers first simulate transactions off-chain to ensure they will actually get paid. If one or more transactions in the bundle do not pay sufficient gas fees, they get dropped from the bundle and the bundler must redo the simulation. To ensure that user operations don’t use a different amount of gas between simulation and on-chain execution, certain opcodes such as GASPRICE or TIMESTAMP are banned during validation (not during actual execution of the user op).

A potential risk is that a paymaster will pass the simulation check, but when the transaction is executed on-chain, whether accidental or intentional, the paymaster contract does not pay. To mitigate against this potential behavior, paymasters must lock staked funds in the EntryPoint contract for a given time period. Paymasters also earn a reputation score based on what percentage of their transactions are included in bundles. Paymasters that cause bundlers to perform a significant amount of unpaid work are initially throttled and can eventually be banned.

Each contract account must implement the IAccount interface, which contains a single function named validateUserOp. The EntryPoint contract calls this function to validate the signature and nonce data that was passed along with the user operation. The validateUserOp function must also check that msg.sender is the EntryPoint contract. The Ethereum Foundation’s developers have provided a sample contract named SimpleAccount that shows how to correctly perform validation of a user operation, and it is highly recommended to use their implementation which has been professionally audited. However, users can choose to write their own custom validation logic. This flexibility comes with the potential for mistakes, so developers should be cautious when developing custom validation schemes.

Wrap up

EIP-4337 is an exciting developing standard for account abstraction that opens up new use cases that are not possible within the current restrictions of EOAs, and without requiring changes to the Ethereum protocol. Eventually, account abstraction may do away with the need for EOAs altogether.

For developers who are interested in experimenting with EIP-4337, you can use the EntryPoint deployment on Goerli testnet as a starting point. All of the core protocol code along with examples of account and paymaster contracts is available on GitHub in the eth-infinitism repository.

One early adopter of the EIP-4337 standard is Laser Wallet, a multi-signature contract wallet that relies on EIP-4337 for account abstraction. Arbitrary Execution had the privilege of auditing the Laser Wallet codebase in March 2022. The audit report can be found here.

Arbitrary Execution is a team of security research engineers who are bringing our expertise in traditional cybersecurity to the domain of decentralized technology. If you have any questions about blockchain security or are ready to schedule an audit, please contact us today.