May 30th, 2023
One of the main selling points of ERC-4337 — and why it succeeded while earlier proposals (EIP-86 and EIP-2938) failed is that it doesn’t change how the Ethereum blockchain works at a fundamental level. However, it will have a dramatic impact on how people interact with the blockchain and the integration of Web2 and Web3 systems.
In our earlier article, What is ERC-4337, we provided a high-level introduction to ERC-4337 and the concept of Account Abstraction. This guide aims to go deeper, providing a clearer understanding of Account Abstraction and its impacts on the Ethereum ecosystem.
One of the main selling points of Account Abstraction is that it will make it easier for users to interact with the blockchain. In the past, a certain level of technical knowledge — or trust in third-party wallet providers — was necessary to use blockchain technology. ERC-4337 will lower the bar for entry, making Web3 and blockchain more accessible to new users and service providers alike.
To understand the impact of ERC-4337, it’s necessary to understand how accounts work in Ethereum. In Ethereum — and blockchains compatible with the Ethereum Virtual Machine (EVM) — there are two different types of accounts.
If you “have an Ethereum account”, then that account is likely an externally owned account (EOA). This is the type of account used by most crypto wallets and is commonly used to hold cryptocurrency, store NFTs, and interact with smart contracts on the blockchain.
On Ethereum, there are a few defining features of NFTs that are relevant to Account Abstraction. These include the following:
Public/Private Keypairs: EOAs are controlled by a public/private keypair. The private key is used to digitally sign transactions, and these signatures are verified using the public key. Knowledge of an EOA’s private key provides complete control over the account. If a private key is stolen, then the attacker can perform transactions on the account’s behalf and drain it of value. If the private key is lost, then the contents of the account are lost forever.
Gas Fees: Ethereum uses gas fees to cover the costs of operating the Ethereum network. These gas fees go to Ethereum validators and are paid in ETH. This is true even if the transaction in question doesn’t involve a transfer of ETH. To perform transactions with an EOA, the owner needs to hold some ETH.
Ethereum is famous as one of the leading smart contracts, and many DeFi protocols and other projects are built on it. The other type of address in Ethereum is a smart contract account.
One of the main differences between an EOA and a smart contract account is that a smart contract account has code associated with it. This code is executed on the decentralized Ethereum blockchain, any Ethereum user can perform a transaction calling a smart contract, which will take some action based on that transaction.
As a smart contract platform, the Ethereum Virtual Machine allows Turing-complete smart contracts to be hosted and run on top of the Ethereum blockchain. One of the defining attributes of ERC-4337 is that it takes advantage of this capability to support Account Abstraction without the need to change the underlying Ethereum protocol — a process that would require a hard fork and be long and painful to carry out.
Ethereum has the concept of a mempool, which is a location where transactions are stored as they wait to be added to the distributed ledger. Each new block draws some transactions from this mempool, validates that they are correct, and distributes them within a block to be run within the EVM.
ERC-4337 creates the concept of an alternate mempool managed by a smart contract (called the EntryPoint contract). Users can create pseudo-transactions — called UserOperations — that will be bundled together into a single transaction and executed by that EntryPoint contract.
As its name suggests, Account Abstraction adds a layer of abstraction to the Ethereum protocol.
Instead of directly submitting transactions to the blockchain via an EOA, a user can indirectly create UserOperations that are submitted via a Bundler. While this adds additional steps and complexity to the process, it pays off by unlocking capabilities that are impossible with EOAs.
The ERC-4337 standard has the potential to minimize friction in the user experience and unlock some new capabilities for the EVM. However, this also means that the standard includes a number of moving parts and new actors within the Ethereum ecosystem. Understanding all of these components is necessary to understanding the details of Account Abstraction.
A UserOperation is the ERC-4337 equivalent of a traditional transaction on the Ethereum blockchain. It performs the same role as a traditional transaction — executing some operation within the EVM — with some restrictions. For example, UserOperations can only access the data stored by the sender’s address and can’t use certain temporal pieces of information (block hash, time, etc.).
A UserOperation contains all of the same information as a traditional Ethereum transaction. However, it also includes additional fields designed to enable its indirect execution and unlock new capabilities.
For example, some of the additional fields included in a UserOperation include:
Sender: The address of the account performing the operation.
Nonce: Protects against replay attacks and is used as a salt when creating new accounts.
InitCode: Used to help create a new address on the blockchain. This eases the on-ramp to blockchain for new users.
CallData: Data being sent to the sender when the UserOperation is executed.
CallGasLimit: The maximum amount of gas to use when executing the UserOperation in the EVM.
VerificationGas Limit: The maximum amount of gas to use when the UserOperation is undergoing verification.
PreVerificationGasLimit: The maximum amount of gas paid to the Bundler for calldata and execution before verification occurs.
MaxFeePerGas: The maximum fee per unit of gas (see EIP-1559).
MaxPriorityFeePerGas: The maximum priority fee per unit of gas (see EIP-1559).
PaymasterAndData: Identifies the paymaster who is paying to sponsor a UserOperation. Self-sponsored UserOperations pass no data to the paymaster.
Signature: Data used to help verify the validity of the UserOperation.
A UserOperation operates differently than a traditional EVM transaction. As part of this, new mempools and roles are defined within ERC-4337.
Traditional transactions go to traditional mempools. Since UserOperations are not intended to go directly to the blockchain, they have their own mempools as well.
ERC-4337 defines a general higher-level mempool for UserOperations, which operates as a peer-to-peer (P2P) network. There will also be “alternate mempools” that have an allowlisted set of Paymasters and/or SignatureAggregators.
In the Ethereum base protocol, validators draw transactions from a mempool and make a block. In ERC-4337, Bundlers draw UserOperations from a mempool to make a transaction to send to the blockchain. A Bundler can draw from the main UserOperation mempool and/or any alternate mempool whose allowlist they support.
A Bundler works similarly to an Ethereum validator but builds bundled transactions rather than blocks. They determine which UserOperations to include in a block based on the fees paid to them by users. They’ll also simulate each transaction to ensure that its signature is correct and that the user has the ability to pay the associated fees.
In the end, a Bundler will create a single, bundled transaction and pay the gas fees for the complete transaction. That transaction will then be submitted as a traditional Ethereum transaction sent to the EntryPoint contract.
The EntryPoint contract is a smart contract on the Ethereum blockchain whose purpose is to execute UserOperations. There will only be one EntryPoint contract on the Ethereum blockchain, which will be used by all Bundlers and ERC-4337 compliant smart contract wallets.
The EntryPoint contract is responsible for executing all UserOperations on the Ethereum blockchain. However, two other types of contracts are also involved in this process:
Aggregator: A bundle of UserOperations will have a single aggregated signature that proves the validity of each transaction in the bundle. An Aggregator is a helper contract trusted by a Bundler or client to verify aggregated signatures.
Paymaster: A Paymaster is a contract that sponsors UserOperations by paying their gas fees. This is not necessary for a UserOperation but can unlock some new capabilities. A Paymaster may use an off-chain process to collect payments — enabling credit card payments while maintaining account custody — or enable gas to be paid in some other ERC-20 token — something not possible in the base Ethereum protocol.
Aggregators and Paymasters may be required to stake if they access global storage. The reason for this is that they have the potential to invalidate large numbers of UserOperations, performing a DoS attack if abused.
In a nutshell, Account Abstraction simply adds a layer of abstraction to the EVM. Instead of transactions being added directly to the blockchain — paying their own gas in ETH and being directly signed by a private key — UserOperations can be created off-chain and bundled into a single transaction with verification and gas payment handled by a third party.
These tweaks to how transactions can be performed on the Ethereum blockchain have major impacts on what is possible in the EVM.
Some of the capabilities that they unlock include:
Social Recovery: With a traditional EOA, a lost private key means that an account is lost forever. UserOperations are validated differently, making it possible to regain access to an account in an ERC-4337 compliant smart contract wallet via social recovery.
Alternative Authentication Methods: With a traditional Ethereum transaction, the validity of the transaction is verified using the Elliptic-Curve Digital Signature Algorithm (ECDSA). Account abstraction makes it possible to define other authentication methods, including the ability to incorporate multi-factor authentication (MFA) or step-up authentication — where higher-value or more privileged actions require additional authentication.
Session Keys: Ethereum transactions need to be digitally signed, which can add friction to blockchain-based games and other highly-interactive processes. Account abstraction makes it possible to generate “session keys” that allow a dApp to sign transactions on your behalf during a session (with limits on duration, value, etc.).
ERC-20 Token Gas Payment: With traditional transactions, a user must pay their own gas fees in ETH to perform a transaction even if the transaction doesn’t involve ETH. With Paymasters, it is possible to pay a gas fee in any ERC-20 token since the Bundler pays the fees and is reimbursed after.
Off-Chain Payment Methods: Paymasters also enable a user to submit gas payments off-chain using credit cards, subscriptions, and similar means. This differs from traditional EOAs where off-chain payments typically require handing over custody of the account.
Subsidized Fee Payments: Account abstraction also makes it possible for a user not to pay their own transaction fees at all. For example, an app developer may decide to pay or subsidize gas fees for their users.
Transaction Batching: An EOA uses a nonce as replay protection, which enforces strict first-in-first-out (FIFO) ordering of transactions. Account abstraction enables batched transactions, such as both approving and performing a token swap in a single transaction.
These are only some of the potential use cases of Account Abstraction. In a nutshell, ERC-4337 makes it easier to get started with EVM-compatible blockchains, increases integration between Web2 and Web3, and unlocks capabilities that are impossible with EOAs.
Account Abstraction is still in its early days with test cases running on the Ethereum mainnet and some testnets. As the technology matures and users and developers gain familiarity with it, Account Abstraction will likely become a core component of many Web3 projects and will help introduce new users to blockchain technologies.
However, since Account Abstraction is still in its early stages, it’s essential to take extra care when integrating it into Web3 projects. For help with designing, implementing, and securing ERC-4437 compatible solutions, get in touch with Halborn.