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.
|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|
|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.
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 the
handleOpsfunction to delegate the signature verification to the Aggregator instead of the account contract.
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 is
validatePaymasterOp(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.
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!