Authored by Kiwi Yao, researcher @OKX Ventures
Account abstraction (AA) has been a hot topic recently in the crypto space for it's game-changing influence on managing individual accounts on Ethereum. By simplifying numerous pain points, this might be the proposal that lowers the barrier to entry for non-crypto natives. These benefits include decoupling transaction sources from signatures and giving users more flexibility in account security.
Keen to learn more? Here's everything you'll need to know when understanding AA with the EIP-4337 proposal.
What's account abstraction?
Before diving into AA, it's important to first understand the types of accounts on Ethereum. These include externally owned accounts (EOAs) and contract accounts (CAs). EOAs are controlled by private keys and seed phrases, while contract accounts are controlled by smart contracts. AA refers to the process of decoupling transaction sources from signatures and upgrading EOAs to CAs. This will give smart contracts control over EOAs and allow for the creation of smart contract wallets, which will improve the overall experience for account holders and unlock greater account management flexibility.
Why AA is helpful
AA is largely welcomed by the Ethereum community because it simplifies the entire account management process. Some benefits include offering more flexibility to rigid on-chain actions and enabling greater security options. From these improvements alone, AA greatly improves the overall experience of interacting with the Ethereum ecosystem as numerous inconveniences and pain points are dealt with.
Ethereum's history with AA
Before going through the history of AA, let's first understand the various Ethereum Improvement Proposals (EIPs) that play a part in where we are today with AA.
EIP-2938 involves making CAs 'top-level' accounts capable of paying fees and executing transactions. EIP-3074 introduces two new OpCodes to allow EOAs to use contracts. These OpCodes are AUTH and AUTHCALL, which allow EOAs to delegate their actions to a contract. This ultimately lets developers design transaction objects and verification mechanisms within a more flexible framework.
EIP-4337 reveals the user operations (user ops) memory pool, which is a new operational logic that replaces the current transaction memory pool and enables AA.
While AA was first mentioned as part of EIP-2938 and EIP-3074 back in 2020, the suggested changes were ultimately put on hold. This was due to the need for extensive changes to the Ethereum protocol. With the introduction of EIP-4337, AA will be made possible without the need for protocol changes.
Comparison with other account abstraction solutions
Although EIP-4337 might seem complex to Ethereum beginners, the previous AA solution, EIP-3074, involved the introduction of two new op codes. As this involved extensive consensus layer changes to Ethereum, the proposal was ultimately paused and put on hold.
A deep dive into EIP-4337
Source: OKX Ventures
With EIP-4337 being the latest proposal to enable AA, it's important to understand how it achieves this and the difference between EIP-4337 and its predecessors. Here are a few key terms:
UserOperation is an object that's performed for the individual to send a transaction
Entry point is a contract that executes bundle transactions of user ops
Bundler is a node that handles user ops as a bundle transaction and adds entry point transactions to the block while they're still valid
Wallet contracts are user-owned smart contract accounts
Wallet factory is a smart contract that can create new smart contract wallets on-demand for individuals
Aggregators are helper contracts trusted by accounts to validate aggregated signatures. Bundlers then whitelist the supported aggregators.
Paymasters are contracts in charge of putting custom logic onto the blockchain. This includes enabling gas payment flexibility in any currency on any network.
EIP-4337 simplifies the AA process with the introduction of bundler, entry point contract, paymaster, wallet factory, signature aggregator, and user ops.
When an individual wants to send a transaction, they create a user op. A user op contains all of the information needed to send a transaction, but is not yet signed by the individual.
The user op is then sent to a bundler, which is a smart contract that groups user ops together into a single transaction. The bundler then sends the bundled transaction to the entry point contract that identifies and validates the user ops associated with the smart contract wallets.
Finally, after validation, the smart contract wallets associated with the user ops implement the ExecuteUserOp function, which executes the transactions.
Understanding the flow of transactions
Here's an example of how a transaction would occur under the new AA-enabled proposal.
Starting the transaction process
The account expresses its intent by creating a user op. A user op can access data related to the sender's address, which includes 'maxFeePerGas' and 'maxPriorityFee'. As for access to 'signature' field usage, each instance of access is determined by account implementation rather than the existing protocol. Each user op is then sent to a dedicated user ops memory pool.
Sending transactions
The user ops are then handled by validators, which bundle these user ops into a separate memory pool. With the bundler acting as a block builder, the user ops are then added to the block while the entry point transactions are still considered valid. Even if the bundler isn't a block builder, it can accomplish this by working with the block building infrastructure. Some examples of such infrastructure include mev-boost, proposer-builder separation, and experimental eth_sendRawTransactionConditional RPC APIs.
Identifying transactions
Following the previous sending process, the user ops are then sent to the entry point contract, which executes the bundles of user ops. To accept the user ops, the bundler must make use of the validateUserOp function to validate the user ops' signature. After successfully doing so, bundlers then whitelist the supported entry point contract.
Executing transactions
Finally, the transaction is completed by the smart contract wallet, which implements the ExecuteUserOp function. Bundlers package up a set of these user op objects into a transaction and initiate a function call on the handleOps EntryPoint smart contract. This transaction then gets included in a block.
Comparison of EOA, MPC, and AA crypto wallets
Curious about the differences between the different types of crypto wallets? Here's a helpful table that summarizes the similarities and differences.
EOA wallet | MPC wallet | AA wallet | |
|---|---|---|---|
Account type | EOA | EOA | CA |
Creation cost | Low | Low | High |
Gas fees | Low | Low | High |
Gas payment method | Single | Single | Multi-currency, allows third-party tokens and |
Batch transactions | None | None | Available |
Signature method | ECDSA | ECDSA | Various signature methods |
Private key management | Required | Required | Not required |
Wallet recovery | None | None | Available |
Audit requirement | Basic security audit | Off-chain signing authorization policy, transparency consideration needed | Audit of on-chain contracts and demand pool required |
Security | No standard, low security | Possible offline recovery on trusted devices | Chain-level security achieved after EIP-4337 |
Ecosystem compatibility | Strong | Weak | Moderate |
Elimination of single point of failure | Not possible | Possible | Possible |
How does EIP-3074 AA differ from EIP-4337 AA?
EIP-3074 was put on hold because it was a core EIP and required consensus layer changes. Two new OpCodes needed to be introduced to enable EOA accounts to use the contract. This comes with its own set of advantages and disadvantages when considering EIP-3074's version of AA.
Advantages
The biggest factor in favor of EIP-3074's AA is that it allows users to delegate control of their EOA to a contract. This gives developers a flexible framework for developing novel transaction schemes for EOAs like batch trading, packaged trading, and flexible gas payment.
Another advantage is how EIP-3074's AA solution involves using invoker contracts, which accept payment in tokens other than ETH. These trustless intermediaries act like middlepeople that execute transactions between sponsors and sponsees.
Additionally, EIP-3074's AA solution allows any EOA to act like a smart contract wallet without deploying a contract.
Disadvantages
One big reason EIP-3074 isn't preferred among the Ethereum community is that it involves changes to the consensus layer. This can be disastrous since a hard fork may be required to solve any problems that happen because of consensus layer changes.
Since EIP-3074 allows EOAs to have the characteristics of CAs, it still uses a fixed ECDSA signature on the signature mechanism. This prevents the use of arbitrary signatures.
The introduction of EIP-5003
Although EIP-3074 has been put on hold, this doesn't mean the proposal has been entirely abandoned. EIP-5003 introduces the AUTHUSURP OpCode, which deploys code at EIP-3074 authorized addresses.
EIP-5003 works together with EIP-3607 to revoke the original signing key's authority for EOAs. For example, EOA one has authorized address two to act on its behalf under EIP-3074. Thanks to the AUTHUSURP OpCode, address two can set EOA one's codes. This effectively allows an existing EOA to upgrade to a CA and grants it the ability to migrate from ECDSA signatures to a more efficient and secure signature method.
The bottom line
As Ethereum continues to innovate in the pursuit of mass adoption, we're seeing plenty of pain points being resolved thanks to the introduction of EIP-4337's AA solution. With AA, we're witnessing benefits like greater security options and gas payment flexibility that will greatly lower the barrier to entry when interacting with the Ethereum ecosystem.
Watch this space for more updates on how OKX will integrate EIP-4337 into our multichain wallet.
© 2024 OKX. This article may be reproduced or distributed in its entirety, or excerpts of 100 words or less of this article may be used, provided such use is non-commercial. Any reproduction or distribution of the entire article must also prominently state: “This article is © 2024 OKX and is used with permission.” Permitted excerpts must cite to the name of the article and include attribution, for example “Article Name, [author name if applicable], © 2024 OKX.” No derivative works or other uses of this article are permitted.
