Estimated time: 8 minutes read
What is Account Abstraction?
Account abstraction is a new paradigm in EVM-compatible blockchains that extends the capabilities of user wallets beyond what conventional Ethereum accounts, the Externally Owned Accounts (EOA), allow.
According to the Ethereum protocol, there are two types of accounts:
- Externally Owned Accounts (EOA): Controlled by the user’s private key through a wallet. These accounts can initiate blockchain transactions to send funds and interact with smart contracts. More details can be found in my article on user wallet connection.
- Contract Accounts: Commonly known as smart contracts, they do not manage private keys nor can they initiate transactions. They execute programmed code within the context of a blockchain transaction according to EVM rules.
With account abstraction, a new type of account can be created: the ‘smart wallet account’ or simply ‘smart account‘. This is essentially a smart contract where the account logic is programmed to extend the user experience beyond the limitations of conventional wallets controlled by an EOA.
What does Account Abstraction consist of?
The concept of account abstraction emerged in Ethereum several years ago, primarily with the goal of improving user experience and fostering greater adoption of the web3 ecosystem among internet users unfamiliar with the crypto world.
This standard allows, among other things:
- Customizing transaction fee payments: It enables paying gas fees with ERC-20 tokens or even sponsoring the costs so that transactions are gasless for the user.
- Authorizing transactions with methods other than an EOA private key signature: Options include passkeys, biometrics, and multi-signatures.
- Developing user-friendly mechanisms for account recovery: This avoids the friction of seed phrases in conventional wallets.
- Bundling multiple transactions into a single operation: For example, minting and transferring an NFT in one order.
After several proposals, the ERC-4337 standard has gained the most adoption. Although it is still under review, there are various initiatives that allow exploration of its possibilities in real-world use cases.
ERC-4337 Architecture
ERC-4337 is the most widely adopted account abstraction standard in Ethereum, likely because its implementation does not require changes to the consensus layer.
The main components are:
- UserOperations: These are precursors to conventional blockchain transactions, containing information such as the nonce, gas payment values, data for interacting with a smart contract, and the signature authorizing the transaction.
- Bundlers: These actors package UserOperations from an alternative mempool (different from the one used for conventional blockchain transactions) and send them to the EntryPoint.
- EntryPoint: A singleton smart contract deployed on the blockchain that validates and executes transaction logic.
- Smart Account: A smart contract that executes the transaction on the blockchain. Transactions are authorized by the user controlling the account. It behaves as the user’s wallet with additional logic to enhance user experience.
- Paymaster: Optional smart contracts that sponsor the gas fees of transactions on behalf of users. They can also accept payments in ERC-20 tokens or stablecoins and support more complex payment schemes like subscriptions or recurring payments.
- Aggregator: An optional reliable entity for smart accounts that validates and aggregates signatures from multiple UserOperations.
This architecture corresponds to the following scheme:
UserOperations
UserOperations are the starting point of user interactions with the blockchain in the account abstraction ecosystem. They represent the user’s intent and will become a transaction on the blockchain.
In addition to transaction-specific information (data for writing to a smart contract), they include other values specific to the account abstraction architecture. The details of all fields are specified in the standard.
Key aspects:
- They represent one or more actions to be executed by the smart account.
- They include data to verify the signature of the operations.
- They define how gas fees will be paid (by the smart account or a paymaster).
- They allow multiple actions to be executed atomically.
Bundlers
Bundlers are responsible for sending UserOperations to the EntryPoint. Before doing so, they validate them by running simulations to ensure that the resulting blockchain transactions will not be rejected due to format issues. For each valid UserOperation, they collect a small fee.
UserOperations are gathered from one or more mempools. Ideally, the mempool for UserOperations should be a public, permissionless p2p network. The community is currently working on developing this canonical mempool. Latest updates and the roadmap for this project can be checked. However, to speed up initial use cases, private mempools managed by major account abstraction technology providers have been developed.
EntryPoint
The EntryPoint is a singleton smart contract that acts as the central entity in the ERC-4337 architecture. It coordinates the verification and execution of UserOperations.
Its address is the same across different EVM networks. It is an immutable and audited smart contract, ensuring security for all actors.
There are currently two implementations in use:
- Version 0.6 (contract address 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789): The first version to see real use cases and community support. It remains active, but new developments are encouraged to use the latest version.
- Version 0.7 (contract address 0x0000000071727De22E5E9d8BAf0edAc6f37da032): The most recent version, introducing numerous improvements, though it is currently supported by few providers.
A comparison between the two versions and their key differences can be found in this article.
Smart Account
The smart account acts as the user’s wallet. At a minimum, it must verify whether a UserOperation will be accepted during the verification phase.
Since it is a smart contract deployed on the blockchain, it can provide additional features, such as flexible gas payment options and transaction bundling.
The smart account is usually deployed on the blockchain when the first transaction is made.
One key difference from EOAs is the authentication logic used to sign and authorize the UserOperation (via the “signature” field).
The traditional method involves using a conventional wallet compatible with the EIP-1193 standard, meaning an EOA is used to authorize UserOperations execution on the smart account.
More advanced schemes are also possible, such as passkeys for storing private keys in secure enclaves or session keys for maintaining a temporary authorization window.
Smart accounts offer the highest flexibility and programmability in the account abstraction ecosystem.
Initially, each smart account provider programmed their functionality in separate contracts, leading to integration issues for developers. To address this, standards are being developed to delegate smart account functions to interoperable modules.
Two emerging standards, each with its own community supporters, are:
- EIP-7579: Describes the interfaces and minimum functionalities for modular smart accounts to ensure interoperability across implementations, avoiding vendor lock-in. This web page contains up to date information about modular account through EIP-7579 proposal.
- ERC-6900: A stricter implementation aiming to become a standard by enforcing specific guidelines for providers. This web page contains the roadmap about ERC-6900 standard.
The debate over which approach is more suitable has spread across the internet. An article discusses the differing viewpoints of leading proponents of each standard.
Paymaster
Paymasters are smart contracts that offer greater flexibility in gas payment options. Possible use cases include:
- Sponsoring transactions under specific service rules, potentially making them gasless for users.
- Accepting ERC-20 tokens to pay gas fees.
- Developing subscription-based payment models.
The ERC-7677 standard has been introduced to standardize how wallets and the account abstraction ecosystem interact with paymasters, and more providers are gradually adopting it.
Other Related Standards
EIP-7702: A proposal to temporarily convert an EOA into a smart account, allowing users to represent their EOA with smart contract logic. This involves a new type of transaction to authorize the transformation, requiring updates to Ethereum’s execution and consensus layers (as defined in the “Pectra” hard fork).
EIP-5792: Aims to unify how DApps interact with different types of wallets (EOA or smart accounts) to mitigate fragmentation issues that hinder web3 adoption. It introduces a standardized API.
Conclusion: Improving User Experience
While the goal of onboarding the next million users to the web3 ecosystem remains distant, the crypto community is actively working toward it.
One major challenge is improving how users interact with the blockchain. Initially, users had to sign atomic, independent transactions with an EOA and pay gas in the network’s native currency.
Account abstraction represents a significant leap in simplifying and enhancing user experience by allowing multiple transactions in a single order and offering flexible gas payment options.
However, new challenges arise, such as increased wallet ecosystem fragmentation, reliance on centralized technology providers, and greater integration complexity for developers.
Are you looking to improve or simplify how users of your DApps interact with the blockchain? Do you know of other community initiatives promoting those tasks?
If you are interested in implementing these or other improvements to facilitate onboarding for your web3 project, feel free to contact me and we can discuss it.