On March 2nd, Yoav Weiss from Ethereum Foundation announced that the core contract of the new Ethereum account abstraction proposal, ERC-4337, had successfully passed the audit conducted by Open Zeppelin, and will be available on any Ethereum Virtual Machine (EVM) compatible network. This new technology will eliminate the complexity of mnemonic phrases or wallet setup for new users, enabling them to enter the decentralized world of cryptocurrencies seamlessly. This will help to promote and expand the overall Web3 ecosystem.
The goal of this protocol is to allow users to use a smart contract address (CA) containing arbitrary verification logic rather than an externally owned address (EOA) as their main account, without changing Ethereum’s consensus, and to eliminate the need for users to use EOA entirely.
A bit confused? Don’t worry, let me give you an example:
Currently, most users create EOA from MetaMask, SafePal, imToken, etc, and users control the entire account through a set of mnemonic phrases. However, this means that if you lose or leak the phrases, you will lose control of the accounts!
So that’s why many developers are currently working hard to develop another type of account — Smart Contract Address (CA). By using CA, many advanced features that EOA cannot provide can be achieved, such as using other ERC-20 tokens to pay gas fees, social account recovery, etc. This can greatly reduce the asset risk of Web3 users and enhance the user experience.
Let’s take a technical look at how EIP-4337 works, as shown in the following figure:
The user submits packaged transaction information to the mempool, and then the bundler (similar to the miner) selects profitable transactions and bundles them together then executes on the blockchain.
Form of user-submitted transactions
The transaction information submitted by the user is as follows:
How bundler executes
First, the bundler will select profitable
UserOperation from the mempool and start verification. The bundler will first call simulateValidation() locally to verify the transaction. This function must revert, and if the function reports ValidationResult, it means verification is successful. If it reports other errors, it means failure, which will be discarded by the bundler.
Then, the bundler will bind the UserOperations that have passed verification together and execute handleOP() in EntryPoint. In handleOP(), two loops are executed. The first is a verification loop, which verifies all the UserOperations sent in again. If a user has not deployed their own account contract, it will be deployed at this step, and payment will also be completed at this step. The second loop is the execution loop, which performs what the user wants to do, such as trading on a DEX or buying and selling NFTs on an NFT platform, etc.
Another feature of this protocol is that third-party payment gas fees. This means that users do not necessarily have to transfer some native tokens (Ethereum => ETH) to their accounts before they do operations.
Users can choose to pay Paymaster with off-chain methods such as credit cards and cash, and Paymaster will pay gas fees on their behalf.
Users can also choose to pay fees with ERC-20 tokens. After completing the main task, Paymaster will call postOp() to execute transferFrom() in ERC-20 to retrieve the tokens in the account.
The social recovery function inherits UpgradeableACL to implement it. Users can specify or revoke the permission of their friends and family to help them recover their accounts through grantGuardian() and revokeGuardian(). When a user loses their private key, their friends and family can call transferOwner() to help them recover their account.
One of the reasons why blockchain cannot be widely promoted has always been asset security and accessibility problems. For example, lots of users are worried about losing their assets due to the loss of mnemonic phrases, or find gas fees inconvenient when trading. EIP-4337’s launch is expected to solve these problems and increase the public’s use of blockchain.
However, since the verification of this protocol can be customized according to needs, the more complex the verification, the more likely it is to have vulnerabilities. Moreover, once a smart contract is deployed, its content cannot be changed. Therefore, before deploying the contract, the smart contract should undergo multiple stress tests and security audits to avoid causing serious financial losses!
If you are looking for a professional auditor, feel free to contact our technical experts.