Intro
At the ETHDenver 2023 event held earlier this month in the United States, a new Ethereum update was unveiled. Among the updates, the ERC-4337 standard for Account Abstraction received much attention, as it is expected to overcome the limitations of the existing Ethereum account system and enable convenient and scalable feature implementations.
In this post, we will explore what Account Abstraction is and how it can be utilized for various use cases in the future.
Why did AA (Account Abstraction) emerge?
AA (Account Abstraction) is a technology that abstracts the concept of accounts in Ethereum by unifying it into a single idea at the higher layer of the protocol to overcome the functional constraints imposed by the type of account. To understand the motivation of AA, we need to know the characteristics of “accounts” in the Ethereum protocol first.
“Account” is a concept used to identify entities that trade assets and perform smart contracts in the Ethereum protocol. Accounts are classified into EOA(Externally Owned Accounts) or CA(Contract Accounts). EOA is a type of user account that can sign and execute transactions with a private key that controls the account’s address. Therefore, the account can send its assets to other EOAs or call smart contracts. We usually manage accounts through wallet applications like MetaMask to hold assets (i.e., cryptocurrencies or NFTs), and these are all EOAs. On the other hand, CA is an account assigned to smart contracts deployed on the blockchain. Therefore, it is mainly used to distinguish a specific smart contract. Since CA does not have a bound private key, it cannot sign or issue transactions independently. It can only do on-chain execution of embedded codes triggered by receiving transactions issued by other EOAs or by being called from other contracts. In summary, there have been constraints for each type of account; EOA can create and execute transactions but cannot execute on-chain code by itself, while CA can execute embedded on-chain code but cannot create transactions by itself.
These constraints by each account’s original function have caused a lot of inconvenience for users. For CA, it was impossible to create a new transaction or deploy a contract (via deploying transaction). Therefore, a separate transaction processing through EOA was always required, which even required paying double the gas fee.
What about EOA? The secure storage of private keys required to use EOA has been identified as one of the biggest obstacle for the mass adoption of blockchain. Reports have shown that about 20% of Bitcoin assets got abandoned due to the loss of private keys by EOA owners, indicating that managing private keys is very cumbersome. Additionally, when the transaction from EOA requires any specific business logic, such as the limitation of transfer amount or destination allowlisting/blocklisting, it was impossible to implement them as on-chain functionalities. Therefore, supplementing this with an of—chain system was essential, which required much effort to implement trustworthy wallets or payment services.
AA is a concept that has emerged to solve these problems. By abstracting accounts and implementing them as smart contracts, AA eliminates all the constraints mentioned above and makes it possible to execute embedded on-chain functions and issue transactions. Thus, implementing AA aims to minimize the inconvenience of account management and increase the scalability of Ethereum applications.
Basic Processing Structure of AA by ERC-4337
Although AA was first proposed in EIP-2938, it was not adopted because it involved modifications of the Ethereum protocol. Nevertheless, when EIP-4337 was proposed later, it eventually became the stand ERC-4337. Unlike EIP-2938, it did not require any modifications to the Ethereum consensus, and instead, it used an “account contract” to enable the abstraction of EOA and CA on the application layer. This implementation was possible because the account contract acted as the intermediary layer between the application layer and the Ethereum blockchain, allowing the abstraction of account types without requiring changes to the underlying consensus protocol.
Basic Idea: Introducing a concept of User Operation, a pseudo-transaction.
ERC-4337 provides the account abstraction through a new layer that resembles the protocol processing that occurs in Ethereum’s consensus layer. To explain it, ERC-4337 achieved the idea of an integrated account by implementing a pseudo-transaction-processing mechanism on the application layer, which functions like a consensus layer; nodes gather transactions from accounts into their mempool and suggest a block containing the high-fee transactions. In the abstract layer, a new actor called “Bundler” appears instead of the node. Anyone in the Ethereum network can participate as a Bundler, reflecting Ethereum’s philosophy of pursuing decentralized transaction processing. In the new layer, users create “User Operations” that contain valid signatures instead of transactions, and transmit them through a specific RPC endpoint. User Operations are composed of data structures such as sender, to, calldata, maxFeePerGas, masPriorityFee, signature, and nonce, just like transactions.
| Field | Type | Description |
| sender | address | The account that created the User Operation (This is a deterministic account contract address; subsequent verification and execution of User Operations are requested through this address.) |
| nonce | uint256 | anti-replay parameter; also used as a salt for initial account creation |
| initCode | bytes | initCode for account creation, which is used to create a new account if it doesn’t exist |
| callData | bytes | Execution data used in the main execution call |
| callGasLimit | uint256 | Amount of gas allocated for the main execution call |
| verificationGasLimit | uint256 | Amount of gas allocated for verification |
| preVerificationGas | uint256 | Amount of gas to be paid as compensation to the bundler who processed pre-verification execution and callData |
| maxFeePerGas | uint256 | https://eips.ethereum.org/EIPS/eip-1559 max_fee_per_gas |
| maxPriorityFeePerGas | uint256 | https://eips.ethereum.org/EIPS/eip-1559 max_priority_fee_per_gas |
| paymaster | Address | Paymaster address that pays the transaction fee (If the address is 0, the fee is paid directly) |
| paymasterData | bytes | Additional data to be sent to the paymaster |
| signature | bytes | Data transmitted to the account along with the nonce during the verification step |
Bundlers collect the User Operations in their User Operation Mempool and bundle the high-fee User Operations into a Bundle Transaction. Then, it passes the Bundle Transaction to the EntryPoint contract by calling its functions so that it can verify and process it.
User Operation Processing on EntryPoint Contract
Now we need rules to verify and execute User Operations. The EntryPoint contract is a smart contract that implements common logic for verifying and processing User Operations. It exists as a standard singleton contract throughout the entire Ethereum network because of its reliability. Its reliability is critical because it includes the standard process of AAs. The EntryPoint contract acts as a protocol for AA to handle the things that happen at the consensus layer, like transaction validation and block generation. The only difference is that it is implemented as a programmable application, a smart contract. Among the various interfaces supported by the EntryPoint contract, the simulateValidation(UserOperation upserOp) and handleOps(UserOperation[] ops, address beneficiary) functions are core functions for User Operation processing.
- The
simulateValidationfunction is called when a Bundler wants to verify the signature and the possibility of paying fee for the User Operations collected in the Mempool. This is very similar to how a node verifies the nonce, content, and signature of a transaction according to the protocol. Bundler can minimize unnecessary gas consumption caused by failures due to incorrectly requested User Operations through this verification. - Once the verification is complete, the User Operations are bundled into a Bundle Transaction and passed to the EntryPoint through the
handleOpsfunction. Subsequently, final verification and execution are completed through the two important loops within the EntryPoint, a verification loop and an execution loop.
Processing delegation to the account contract
Most parts of the two loops mentioned above are processed by the account contract of the User Operation’s sender, not by the EntryPoint contract itself. In other words, the EntryPoint contract acts as a proxy that receives and processes Bundle Transactions at the front-end. Then, the actual execution of the User Operation is carried out by invoking the implementation of the account contract.
- In the verification loop, the User Operation is passed to the
validateUserOp(UserOperation userOp, bytes32 userOpHash, uint256 missingAccountFunds)function implemented in the account contract, where it is verified according to the defined logic. - In the execution loop, the account contract is called through the calldata included in the User Operation, and various custom functions are executed based on the implementation of the account contract.
Finally, any remaining gas from the pre-paid gas is refunded, and the processing of the User Operation is completed. If you have followed so far, you should now have an understanding of how the concept of ‘accounts’ in ERC-4337 has been extended to allow the creation of transactions (User Operations) and execution of on-chain logic.
Extension: Aggregator and Paymaster
In addition to the primary account abstraction process, ERC-4337 includes several extension concepts for the convenience of implementation. These are the Aggregator contract and the Paymaster contract. In the case of these two extension concepts, they can be optionally used by accounts and users during AA processing.
Aggregate Signature and Aggregator
The first extension concept, Aggregator, is an external helper contract that the account contract trusts, providing “Aggregate Signature verification” functionality to the EntryPoint contract and the account contract for the convenience of implementation. As we reviewed the basic process earlier, the Bundler called the simulateValidation function of the EntryPoint for every single User Operation to verify its validity. Then, EntryPoint is also remembered to perform the validateUserOp function on the account contract repeatedly. Although this is a very intuitive way of verification, it may seem inefficient since they are always bundled. The concept to improve this is the Aggregate Signature.
Aggregate Signature is a technique that uses signature techniques such as BLS to construct and verify a single signature structure by bundling multiple messages signed with individual keys. The Aggregator refers to a contract that helps verify the signature at the Bundle level instead of the individual User Operation level by generating an AggregateSignature for multiple User Operations and verifying the generated signature again. The contract must provide the aggregateSignature(UserOperation[] ops) and validateSignature(UserOperation[] ops, bytes signature) functions and can be used by account contracts deemed safe in their implementation. To do this, the account contract should return the address of allowed Aggregator contract from the getAggregator() function call.
EntryPoint can interact with Aggregator as follows:
- First, if the account is using Aggregator, the EntryPoint contract returns the ValidationResultWithAggregator object instead of the ValidationResult object when
simulateValidationfunction is called by the Bundler. - Bundler firstly checks whether the account is using Aggregator or not, then performs signature verification during the subsequent verification process. In Aggregator case, it calls the
handleAggregatedOpsfunction of EntryPoint instead of thehandleOpsfunction to delegate the signature verification to the Aggregator instead of the account contract.
Paymaster
If you have ever operated or used a blockchain-based application, you may have experienced the inconvenience of transaction fee processing. For example, when trying to use an application based on a specific ERC20 token in the Ethereum environment and issuing a transaction from EOA, you have to purchase and charge Ethereum separately for the gas fees for transaction processing. Users had to endure such inconvenience because transaction processing fees were only paid with the Native token in EVM-based chains.
The Paymaster contract, the second extension concept of ERC-4337, is a custom payment agency contract that allows DApp providers to pay gas fees for those using their services or process fees with ERC20 tokens. Applications based on AA can implement flexible and scalable services by utilizing the Paymaster contract.
The Paymaster contract interacts with EntryPoint as follows:
- If the paymaster field exists in the User Operation structure, this request is considered as an operation that must be processed through a specific Paymaster. At the point where the
validationOpof the account contract is performed in the validation loop of the EntryPoint, the verification of this request is partially delegated to the address of this field. The function called at this time in the Paymaster isvalidatePaymasterOp(UserOperation op), which corresponds to the standard spec. - The Paymaster contract checks the account that requested payment first and then verifies balances to return a decision if it pays for the account or not. Accordingly, after the execution loop ends, the EntryPoint contract calls the
postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost)function of this Paymaster contract to request payment of the fee.
Then, what can we do with AA?
To summarize what we have looked at so far, using AA, we can now implement the following new scenarios.
- By defining an account as a contract, we can issue transactions without the management of private keys.
- By defining an account as a contract, we can define and execute custom on-chain code within the account.
- With the account contract, general smart contracts can issue transactions now. This allows the implementation of features such as batch processing transactions or atomic actions, which can save fees.
- We can use Paymaster functionality to delegate transaction fees.
Ultimately, we hope that these changes will improve the usability for users, leading to the expansion of the Web3 ecosystem. With the elimination of the constraints of account-based implementation, on-chain implementation of applications with various scenarios becomes possible, such as:
- Multi-sig functionality requiring signatures from a specific number of people for token transfers, or account recovery using this functionality.
- Asset transfer or transaction creation functionality using multi-factor authentication.
- Periods of fee-free services using Paymaster, processing gas fees through payment with tangible values, and transaction processing systems based on specific ERC20 tokens.
- Various account access restriction functionalities, such as allowing/blocking accounts that can send tokens from my account, specifying transfer limits, or limiting token movement for a certain period.
Despite the downturn in the crypto market, various Web3 products are being released for the population of blockchain. Support for AA on the Ethereum mainnet is expected to be a great opportunity for the development of the Web3 market in terms of both usability improvement and scalability for applications. Especially wallet services that have not been attractive to Web2 users due to usability issues are expected to expand through the utilization of AA, supporting various payment methods, social account recovery, and account authentication using Web2 infrastructure.
Conclusion
In this post, we have summarized the recently implemented AA(Account Abstraction) function, what kind of technology it is, and what changes it will bring about. The Luniverse team, which is implementing node services and various APIs for public chains, is also quickly reviewing related technologies to provide new developer tools and various use cases with the commercialization of AA. The word “abstraction” may sound ambiguous and new, but it will become a technology that can greatly expand the boundaries of the blockchain.
Try out Luniverse Testnet!
The Luniverse Testnet is a free trial service for Web3 builders, available in the Luniverse Console. You can take advantage of a 60-day free trial to upload or test your Dapp for free!
