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 simulateValidation function 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 handleAggregatedOps function of EntryPoint instead of the handleOps function 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 validationOp of 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.

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.