Original author: Madoka Kame,IOBC Capital
There are actually two types of accounts in the Ethereum system:
One is controlled by a private keyexternal account(externally-owned account, EOA), such as the account in the wallet we use, this type of account has its own balance. Owners can send messages from their external accounts by creating and signing a transaction;
The other is a contract account controlled by code deployed to the blockchain, controlled by Ethereum virtual machine code stored in a smart contract account (sometimes called a smart wallet). When a contract account receives information, its internal code is activated, allowing it to read and write internal storage, create new contracts, and more.
first level title
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.Allows the account to have the function of contract account and external account at the same time.
first level title
Various schemes of account abstraction
It has always been the vision of the Ethereum developer community to achieve account abstraction. The community has also proposed various proposals, such as:EIP-86，EIP-2938wait.
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 that everything be packaged into a transaction originating from an ECDSA-secured external account (EOA), and every user action needs to be wrapped by a transaction from the EOA, which incurs a cost of 21,000 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, contract accounts can 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.
new protocolERC-4337first level title
How is ERC-4337 implemented?
ERC-4337 does not attempt to modify the protocol consensus, but replicates the functionality of the mempool in the system.
The user sends a UserOperation (UserOperation) object, which contains the user's intent, signature, and other data. There is a separate mempool for user actions, and nodes connected to this pool do ERC-4337-specific validation to filter actions to ensure they only receive actions that pay fees.
These user actions are collected in batches by miners or packagers using the Flashbots service and packaged intoSingle bundle transaction, and included in the Ethereum block.Packers pay gas fees for bundled transactions in Ethereum, and is compensated for what each individual UserOperation pays. 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: the wallet that performs the 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, the initialization code used to create the wallet;
4. callData: the data used to call the wallet in the actual execution steps.
And each wallet is a smart contract, which must include two functional 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;
first level title
Changes brought by ERC-4337
If the proposal is generally adopted,Signature verification moved to the Ethereum Virtual Machine (EVM), the validateUserOp function adds arbitrary signature and random number verification logic, making the verification logic more flexible.
In this way, new cryptographic tools can be used when signing transactions, and wallets can also provide some new functions, such as:
multi-signature;
social recovery;
More efficient and simpler signature algorithms (such as Schnorr, BLS);
Post-quantum secure signature algorithms (eg, Lamport, Winternitz);
Upgradeable wallet.
This approach also opens up various other transaction permission management, such as allowing transactions to pay gas fees through smart contracts.
At present, the gas fee for external wallets to interact on Ethereum can only be paid by ETH in the wallet. If you only have ERC-20 tokens in your wallet without ETH, you will have no way to transfer these tokens out. When ERC-4337 is adopted, the user can use the ERC-20 token in the account to pay the fee, and the miner node uses the contract as an intermediary to pay for the ETH chain and obtain the user's ERC-20 token.
After the abstraction is realized,Having a transaction signed and broadcast by the owner of an external account 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 scheme 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:
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, which can be reduced to about 2500 through compression);
（3）ECRECOVER (~3000)；
(4) First access to the wallet itself (~2600)
(5) Access to the payee account for the first time (~2600)
(6) Transfer ETH to the beneficiary's account (~9000)
(7) Edit Storage to Pay Fee (~5000)
(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, shuffle variables, etc.)
3. Need to consume gas to pay the log fee (EOA does not publish logs);
4. One-time contract creation cost (about 32,000 gas, plus 200 gas for each code byte in the proxy, plus 20,000 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.
Since Rollup is good at data compression, it has a natural fit with account abstraction schemes with complex data.
In Vitalik's latest proposal,It is proposed to process the data generated by account abstraction through layer 2.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.
epilogue
epilogue
Now that the pattern of focusing on the development of Layer 2 in Ethereum has been set, Vitalik's follow-up plan for upgrading Ethereum has begun to turn to account abstraction. The latest proposal showcasesrollup+account abstractiontechnical path. Various Rollup providers have also released new versions 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, which added a signature aggregation function including the BLS signature algorithm. Signature aggregation allows builders and batch submitters to also aggregate signatures (such as BLS, SNARKs), greatly reducing data on the chain and reducing data costs for rollups.
We have reason to believe that the changes brought about by account abstraction also contain the possibility of ecological explosion. With the development of Rollup, the abstraction of accounts that can be combined with Rollup must also develop better and more refined solutions.
