Talking about account abstraction and ERC-4337 in Ethereum
Original title: "Ethereum Account Abstraction and ERC-4337"
Original source: IOBC Capital
The actual situation in the Ethereum system There are two types of accounts:
· An externally-owned account (externally-owned account, EOA), such as the account in the wallet we use, this type of account has its own balance. The owner can send a message from his external account by creating and signing a transaction;
· The other is by Code-controlled contract accounts deployed to the blockchain are controlled by Ethereum Virtual Machine code stored in smart contract accounts (sometimes called smart wallets). When a contract account receives information, its internal code is activated, allowing it to read and write internal storage, create new contracts, and more. According to the current Ethereum protocol, only external accounts can initiate transactions, and only the owner of the account is allowed to modify its account state.
What is account abstraction?
Account abstraction is an improvement on the above two accounts, trying to blur the boundaries between the two, and become a general-purpose account with complex logic , Enabling the account to have the function of contract account and external account at the same time.
This approach is equivalent to allowing users to define external accounts in the format of contract accounts, and users can include any logic verification in the smart contract wallet. Accounts controlled by keys can also be supported by codes.
Various schemes for account abstraction
For a long time , Realizing account abstraction is the vision of the Ethereum developer community. The community has also proposed various solutions, such as: EIP-86, EIP-2938, etc..
EIP-86 is a technical preparation for account abstraction, which defines a new account type that allows users to create accounts based on smart contracts.
The Ethereum protocol itself requires all content to be packaged into transactions originating from an ECDSA-secure external account (EOA), and each user action needs to be , which incurs a cost of 21000 gas. Users need to own ETH in a separate EOA to pay for gas.
The account abstraction proposed by EIP-86 brings new types of transactions that have no sender compared to traditional transactions that must have an EOA as a sender. Such transactions destroy the uniqueness of the transaction hash. EIP-86 was originally planned to be upgraded in the Metropolis phase, but due to the problems mentioned above, the developers decided to postpone the introduction in Metropolis.
EIP-2938 provides an account abstraction solution, by changing part of the Ethereum protocol, allowing contract accounts to initiate transactions just like external accounts. However, since this solution requires changes to the Ethereum protocol at the consensus layer, it has not been widely accepted.
The new protocol proposed later ERC-4337 provides a solution without changing the consensus protocol to try to achieve With the same effect as EIP2938, this more secure implementation is currently receiving more attention in the community.
How is ERC-4337 implemented?
ERC-4337 does not attempt to modify the protocol consensus, but instead replicates the functionality of the mempool in the system.
The user sends a UserOperation (UserOperation) object, which includes the user's intent, signature and other data.
User operations have a separate mempool storage pool, nodes connected to this storage pool will perform ERC-4337 specific authentication to filter operations to ensure that they only An action that receives a paid fee.
These user operations are collected in batches by miners or packagers using the Flashbots service, and packaged into a single bundle transaction, and included in the Ethereum block. Packagers pay the gas fee for bundled transactions in Ethereum, and are compensated by the fees paid by each individual UserOperation. The packager will use cost priority logic to choose which UserOperation objects to include.
The user operation UserOperation looks like a transaction, but it is an ABI encoded structure, including the following fields:
1. Sender: wallet for operation;
2, nonce and signature: parameters passed to the wallet verification function so that the wallet can verify the operation ;
3. initCode: If the wallet does not exist yet, use Initialization code for creating a wallet;
4. callData: used for The actual execution step calls the data of the wallet.
Each wallet is a smart contract, which must include two functions:
1. validateUserOp, which accepts a UserOperation as input. This function should verify the signature and nonce in UserOperation, pay the fee and increase the nonce if the verification is successful, and throw an exception if the verification fails;
< /p>
2. The op executes the function and parses the calldata into one or more instructions for the wallet to perform operations.
Changes brought by ERC-4337
If the The proposal was generally adopted, signature verification was transferred to the Ethereum Virtual Machine (EVM), and the validateUserOp function added arbitrary signature and random number verification logic to make the verification logic more flexible.
In this way, new cryptographic tools can be used when signing transactions, and the wallet can also provide some new functions, such as:
< p>1. Multi-signature;
2. Social recovery;
3. More efficient and simpler signature algorithms (such as Schnorr, BLS);
4. Post-quantum security signature algorithm (for example, Lamport, Winternitz);
5. Upgradeable wallet.
This approach also opens up various other transaction permission management, such as allowing transactions to pay gas fees via smart contracts.
At present, the gas fee for external wallets to interact on Ethereum can only be paid through the ETH in the wallet, if your wallet only has ERC-20 Token, without ETH, you will have no way to transfer these Token transfer out. When ERC-4337 is adopted, users can use the ERC-20 in the account Token To pay the fee, the miner node uses the contract as an intermediary to pay the ETH on the chain and obtain the user's ERC-20 Token .
After the abstraction is implemented, signing a transaction by the owner of the external account and broadcasting it will no longer be the only way to initiate a transaction. This will open up the possibility of Ethereum acting as a relayer for meta transactions. Many current applications on Ethereum rely on relayers to publish user transactions on the blockchain and pay fees to relayers. If more complex contracts could be built into the wallet, some relayers would no longer be necessary, and no additional fees would need to be paid to them.
Although there are many advantages, the new solution also faces some problems.
The most prominent point is the higher gas cost. Basic ERC-4337 operations require about 42,000 gas, while regular transactions require 21,000 gas. The reasons are as follows:< /p>
1. You need to pay a lot of individual storage read/write costs, in the case of EOA, these costs will be bundled into a single payment of 21000 gas:
（1）Edit the storage slot containing pubkey+nonce (~5000);
（2 ) user operation call data cost (about 4500, can be reduced to about 2500 through compression);
(3) ECRECOVER (~3000);
< p>(4) First visit to the wallet itself (~2600)
(5) First visit to the payee account ( ~2600)
(6) Transfer ETH to the beneficiary’s account (~9000)
(8) access the storage slot containing the agent (~2100), then access the agent itself ( ~2600);
2. In addition to the above storage read/write costs, the contract also needs to execute "business logic" (unpack UserOperation, hash it Greek, shuffling variables, etc.)
3. Need to consume gas to pay the log fee (EOA does not publish logs);
4. One-time contract creation cost (about 32000 gas, plus 200 gas for each code byte in the proxy, plus 20000 gas for setting the proxy address)
In short, every step of the abstract address of the account needs to be calculated, which consumes more resources and adds additional costs.
Fortunately, this is not unsolvable.
Because Rollup is good at data compression, it has a natural fit with the account abstraction scheme with complex data.
In Vitalik's latest proposal, proposes to use layer 2 to process the data generated by account abstraction. The improvement is to package the functions that can only be realized step by step into batch transactions, and use SNARK technology to ensure the validity of transactions.
Conclusion
In Now that Ethereum's focus on developing Layer 2 has been set, Vitalik's follow-up plan for Ethereum upgrades has begun to shift to account abstraction. The latest proposal shows the technical path of rollup+account abstraction. Various Rollup providers have also released new versions that are compatible with the account abstraction.
In June this year, zkSync released V2 update information: adding the "account abstraction" function and increasing compatibility with Ethereum EVM. In October, a new version of ERC-4337 was released, adding signature aggregation functionality including the BLS signature algorithm. Signature aggregation allows builders and batch submitters to also aggregate signatures (such as BLS, SNARKs), greatly reducing on-chain data and reducing data costs for rollups.
We have reason to believe that the changes brought about by account abstraction also contain ecological possibility of outbreak. With the development of Rollup, the abstraction of accounts that can be combined with Rollup must also develop better and more refined solutions.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
