Account Abstraction

Account Abstraction has been a subject of extensive discussion since 2015. However, it is now gaining significant attention in the Web3 community due to the growing momentum of EIP standards such as 1271 and 4337, as well as the widespread adoption of powerful smart contract wallets like Safe, Argent, and Ambire.

Unfortunately, the recent surge of interest in Account Abstraction has also led to numerous misconceptions and a lot of noise. There are various definitions and misunderstandings that need to be clarified. Let’s unravel and shed light on the topic.

Account Types

Firstly, lets talk accounts. An account exists on the EVM with the following structure:

As we can see it has and address associated with an Account state, within which the nonce, balance and other key fields are defined. Notice the statement “An account state could contain EVM code and storage”. This brings us to the next part, differentiating between the two account types that exist, EOAs, and Smart contract accounts.

EOA

• An Externally Owned Account (EOA) is an account type that is controlled by a private key, which enables the account owner to access and manage the account.
• The transactions executed by an EOA require the explicit authorization and signature of the account owner, via the private key.
• It cannot contain EVM bytecode; hence the lack of a storage hash and code hash.
• Metamask wallets are an example of an EOA wallet.

Smart Contract account (Contract Account)

• A Contract Account, is an account type that is governed by code rather than being controlled by a private key. The contract can perform predefined functions and operations.
• Contract Accounts are deployed as smart contracts and can interact with other accounts, including EOAs and other Contract Accounts, based on the conditions and rules set within their code.
• A contract account does not have a private key; its own executions do not require a private key signature. However, a smart contract cannot execute transactions on its own volition; the entry point always begins with an EOA transaction.

In summary, the main difference between an EOA and a Contract Account lies in their control mechanisms. EOAs are controlled by private keys owned by individuals, while Contract Accounts are governed by the code within the smart contract and cannot execute predefined actions autonomously.

EOA and problems in life

Before we jump into the what of account abstraction, lets bite into why — which brings us to the tragedy of EOA wallets and their limitations. For reference, this is the typical EOA execution flow:

1. Single static private key for access

Users sign transactions using their private key in the public-private key pairing that is their EOA wallet. If you lose your keys, you lose access to your account — and you cannot authorize another private key, just as you would have a joint bank account. What if you die? The only metamask will be the funereal shroud that covers your face.

“Hardware wallets!”, you howl. Yeah, that’s not a solution but a stopgap measure at best. There’s a reason why banks very quickly skated pass physical 2FA devices onto digital methods.

1. Inability to do transaction batching

EOA wallets cannot execute transactions in batches natively. Meaning approve and transfer in a single transaction, as opposed to two. This results in poor UIUX experience, greater fees paid out in gas.

There are a number of other issues with EOAs, but these two key points are sufficient for setting the stage.

Account Abstraction

Account Abstraction entails the concept of doing away with EOAs, and having user wallets be Contract accounts with the objective of enhancing usability and flexibility.

Advantages of Account Abstraction

• Native multi-sig,
• Social recovery,
• White/Black address lists,
• Gasless transactions/Payment in ERC20 tokens
• Custom custody setups
• Easy wallet migration and key handling

These features will enable us to create a user-friendly experience for Dapps and wallets, without requiring users to manage private keys/seed phrases or to hold/pay for gas. Soon using a contract account is going to be very much like using a bank account.

To achieve this, the validation conditions of a transaction, such as signature verification, gas payment, and replay protection, are moved from the core protocol level (consensus layer) to the EVM smart contract level (execution layer).

In simpler terms, Account Abstraction involves more than just using smart contract accounts as the default type of account. It also addresses how a blockchain can interact with smart contracts and verify data from them. With Account Abstraction, several specific components of an Account are abstracted away:

1. Signature abstraction: Enables different contract accounts to utilise different signature validation schemes.
2. Gas abstraction: Allows for various transaction fee payment models, such as payment by another entity or even payment in Non-L1 tokens.
3. Nonce abstraction: Permits the usage of multiple nonces for different types of transactions, expanding the replay protection schemes beyond a singular, linearly incrementing nonce for an account.
4. Network abstraction: Smart contract accounts can be controlled by accounts on a different network through arbitrary message bridges.

Sounds intriguing, but why bother? If we want to onboard a billion users into web3, and have cryptocurrencies a mainstream form of payment and value transfer, we simply cannot expect the everyday user to contend with the difficulties of securely storing private keys.

It is just not tenable, and anyone who tells you otherwise is delusional. It’s akin to expecting everyone to be cybersecurity trained, just so they can fend off spearphishing, social engineering, backdoors, trojans and that African prince who has a million dollars to give you if only if you could spare him a minute (and your banking credentials). The solution there was to have institutions bear the burden, in most cases at least, on behalf of their clientele.

In the same vein, the introduction of account abstraction will pave the way for user accounts being contract accounts as opposed to EOAs, doing away with the hassle of dealing with private keys, amongst many other ancillary benefits that will reduce the onboarding friction so pervasive in web3.

ERC-4337 Architecture

ERC-4337 introduces the latest advancement in smart accounts and associated infrastructure. Contract accounts offer a flexible and programmable layer, replacing the rigid requirements of EOA wallets. Within this programmable layer, three key actors are integrated:

1. Bundlers: Bundlers play a specific role within ERC-4337 by grouping user transactions, and transmitting them on-chain. Responsible for ensuring user transactions are broadcast to the blockchain.
2. EntryPoint contract: A single instance of this contract exists and serves as the universal entry point for everyone using ERC-4337 compliant contract wallets. It serves to warehouse the more complex smart contract functions centred around validation and pre-execution checks.
3. Paymasters: These smart contracts can act on behalf of users and either fully cover their gas fees or allow them to pay fees using non-native gas tokens such as USDC. Developers can program paymaster contracts to have control over who bears the gas costs and in which token, granting them greater flexibility in product design.

ERC-4337 also presents a different way of conducting transactions compared to the conventional EOA method — it introduces additional stages. Instead of directly sending transactions, users express their intention through UserOperations, which are then distributed via a dedicated UserOperations mempool. Bundlers, acting as proxy EOAs, monitor this specific mempool. They bundle the UserOperations and forward them to block builders as standard EOA transactions that can be processed by the network. If the Bundler is a block builder itself, both bundling and block building can be handled by the same node.

Here’s a high-level graphic of the entire process:

💡 Bundlers are special kind of nodes that monitor the UserOperation mempool for incoming UserOperations, bundle them and transmit the bundle to the EntryPoint contract. Bundlers can be block builders, but not all block builders are bundlers.

Architecture

Off-Chain Flow

EIP-4337 eliminates the need for sending individual transactions. Instead, users are required to send a set of UserOperations. The easiest way to think of UserOperations is that they are blueprints of unexecuted transactions. Bundlers then pack these UserOperations into a single transaction and send it to the EntryPoint contract. The contract executes the transaction, and the bundlers are compensated accordingly.

1. The smart wallet sends user operations to a bundler node via RPC. The bundler node subsequently adds them to the UserOperations mempool. The UserOperation ****mempool is specialized for UserOperations and separate from the standard transaction mempool.
2. Bundlers monitor this specific mempool for incoming UserOperations collecting them to run simulations and assemble them into a single transaction bundle. This transaction bundle it submitted to the EntryPoint contract. The rest of the execution is done on-chain, where the bundle transaction is validated normally and added to a block.
3. With the implementation of ERC-4337, bundlers fulfill similar roles to block builders. Consequently, they should enjoy similar incentive and business models.

💡 Prior to including a UserOperation in the mempool, bundlers are required to execute the simulateValidation function of the entry point. This step ensures the accuracy of the signature and confirms that the operation includes the necessary fee payment. If verification fails, the UserOperation is omitted from the mempool.

On-chain Flow

This begins with the EntryPoint contract receiving bundles of UserOperations. The handleOps function on the contract then proceed in two executional loops:

1. verification loop
2. execution loop

In the verification loop, the **handleOps**call performs the following for each UserOperation:

1. Create : This serves to create new wallet contracts, if they do not yet exist. Contract is created as per the initCode provided.
2. Call validateUserOp on the account: verifies the validity of the UserOperation by simulating the transaction; verifies the signature and nonce on the UserOperation, gas fee requirements, and so forth. This serves as a protective layer over wallets, as malicious calldata payloads would result in a revert here.
3. **validatePaymasterUserOp**: This optional call occurs if the paymaster field is set and serves to confirm that the paymaster is willing and able to pay for said UserOperation.

In the execution loop, handleOps sends a transaction call out to the respective contract accounts and their verified UserOperation’s calldata. Said account will parse the calldata and execute the transactions as intended by the UserOperation.

There are two key scenarios we need to be aware of with regards to the paymaster:

1. Gas in ETH: Paymaster pays gas fees from its Eth staked on the EntryPoint contract on behalf of user. This would typically be applied for Dapps willing to cover gas fees for their users.
2. Gas in ERC20: Paymaster verifies that user’s wallet has sufficient ERC20 tokens to pay for the transaction, and pays gas the gas fees in ETH while collecting the tokens as compensation.

💡 A paymaster contract allows Dapps to cover gas costs for their user’s operation, allow gas payments in ERC20 tokens, amongst other gas-related use cases. A paymaster must deposit ETH with the EntryPoint contract, to cover on gas expenses on behalf of users.

In summary, users will construct their transactions off-chain via user operations. These user operations are bundled sent off to EntryPoint contracts which handle validation and execution in two separate steps.

Account Abstraction reduces barriers to entry for mainstream users, promoting wider adoption of cryptocurrencies and decentralized applications. The future of Web3 is set to be more user-friendly and inclusive thanks to Account Abstraction and ERC-4337.