Author: Fourteen Jun
Preface
This article is divided into two modules:
In the first half, we will start from the first AA proposal in 2015 and systematically organize the main contents of the Eip proposals so far. We hope to explore the history of AA proposals and comprehensively evaluate the advantages and disadvantages of each plan.
In the second half, we will focus on comparing the sluggish market feedback faced by EIP4337 after it was proposed, and then conduct an in-depth analysis of EIP7702, which is about to be included in the next version of Ethereum upgrade. Once this proposal is merged, it will change the application form of the chain in all aspects.
EIP-7702 is a revolutionary change. Let’s listen to Mr. Shisi’s detailed explanation.
1. Abstract background of the account
1.1 The significance of account abstraction
Ethereum founder Vitalik updated the ETH development roadmap again at the end of 2023, but the account abstraction setting has not been changed. Today's mainstream model is also moving from EIP-4337 to the next stage, VoluntaryEOA Conversion (voluntary conversion of EOA accounts).
More than a year after the launch of EIP4337 (at WalletCon in Denver on March 1, 2023, it was officially announced that the core contract of ERC-4337 designed and implemented by developers of the Ethereum Foundation has passed the audit of OpenZeppelin and is considered to be the historical node of the official launch).
It has always been widely recognized by users but not widely used. In such a contradictory market environment, the progress of EIP-7702 has been greatly advanced, and it has even been confirmed that it will be merged into the next upgrade.
1.2 Market Status of Account Abstraction
No need to say more, just look at the data.
After a year and a half of development, EIP4337 has only 12 million addresses in the collection of mainstream chain accounts. The most surprising thing is that on the Ethereum mainnet, there are only 6,764 active addresses. Perhaps there is a problem with the statistical dimension, but at least it is far from the number of addresses of EOA and CA. It should be noted that the number of independent addresses on the Ethereum mainnet has reached 270 million (data source: https://etherscan.io/chart/address).
It can be said that there is no substantial development of EIP4337 on the mainnet.
However, this does not erase the essential value of AA, because it was destined from the beginning of the design of EIP4337 that it could not handle the serious forward compatibility issues of the main network. Therefore, with the widespread embedding of native AA in various L2 chains, the number of EIP4337 addresses has exploded on L2. The monthly active users of base and polygon chains in July were 1 million and 3 million respectively, which is quite impressive.
Therefore, it is not that EIP4337 is designed wrongly. It has many advantages, which we will summarize systematically later. The current situation is due to the differences between the main network and L2. They need to use their own suitable solutions.
2. What is account abstraction?
Account abstraction sounds confusing, but in essence it solves the problem of separation of property rights.
There are two types of accounts in the EVM architecture (i.e. Ethereum Virtual Machine), external accounts (EOA) and contract accounts (Contract Account). The ownership and signing rights of external accounts are actually held by the same entity. The person holding the private key not only has the "ownership" of this account, but also has the right to "sign and transfer all assets."
This is determined by the Ethereum account transaction structure
From the structure in the figure below, we can see that there is no From party in the standard Ethereum transaction. So when I make a fund transfer, what address does the fund on? In fact, the From address is deconstructed through its VRS parameter (i.e. user signature).
This involves concepts such as asymmetric encryption such as ECDSA and one-way threshold functions, which we will not expand on. In short, cryptography is used to ensure security. Of course, this has also led to the current EOA address dilemma of property rights mergers.
The core effect of EIP4337 is to add a Sender Address field to the transaction field, so that the private key can be separated from the address being operated.
So why is property separation so important?
Because the external account (EOA) design will lead to more problems:
Private keys are difficult to protect: If a user loses his private key (due to loss, hacker attack, or cryptographic cracking), it means losing all assets.
Few signature algorithms: The native protocol can only use ECDSA signature and verification algorithms to verify transactions.
High signature authority: There is no native multi-signature (multi-signature can only be achieved through collaboration through smart contracts), and a single signature can perform any operation.
Transaction fees can only be paid via ETH, and batch transactions are not supported.
Transaction privacy leakage: One-to-one transactions make it easy to analyze the privacy information of account holders.
The above constraints make it difficult for ordinary users to use Ethereum:
First, to use any application on Ethereum, users must hold Ether (and bear the risk of Ether price fluctuations).
Secondly, users need to deal with complex fee logic. Concepts such as Gas price, Gas limit, and transaction blocking (Nonce order) are too complicated for users.
Finally, although many blockchain wallets or applications attempt to improve user experience through product optimization, their actual effects are minimal.
Therefore, the solution is to realize account abstraction and decouple ownership (Owner) and signature rights (Signer), so as to solve the above problems one by one.
In fact, there are many historical plans, and they will eventually converge into two routes.
3. Sorting out the historical context of AA proposals
There seem to be many EIP proposals to solve the problem, but in the final analysis, there are only two core ideas. Therefore, the issues considered by each EIP that was not passed in the past have converged into the solution to the current solution.
3.1 The first route is to change the EOA address to a CA address
As early as November 15, 2015, Vitalik proposed a new structure of using contracts as accounts around EIP-101. The address was changed to only code and storage space, the handling fee was changed to support ERC20 payment, the native token was changed to ERC20-like to store the balance through pre-compiled contracts (with functions such as deduction authorization), and the transaction fields were simplified to only to, startgas, data and code.
Now it seems that this is a great leap forward reform, which will significantly change the underlying design so that each account address has its own "code" logic (in fact, this is exactly the effect that EIP-7702 is trying to achieve now).
Other functions can also be derived, such as
Allow transactions to use more encryption algorithms, and the signature verification and authentication method can be specified by the internal code of each address
It is resistant to quantum attacks because the code is upgradeable.
Make Ethereum have the same functional characteristics as ERC20 contracts, and the core effect has the withholding authorization, so there is no need to lose the native currency
Improve the account customization space, compatible with social recovery, sbt support, key retrieval, etc.
The reason for not moving forward is very simple. It is obviously too big a step. The current transaction hash conflict problem and security risks have not been carefully considered, so it has been shelved. However, the concept of each advantage has become one of the core functions of the subsequent EIP4337 and EIP7702.
Later, a series of EIPs attempted to improve this logic.
EIP-859: Mainchain Account Abstraction - 2018-01-30
It attempts to solve the problem of Code deployment. The core function is that if the transaction party's contract is not deployed, the code parameter attached to the transaction is used to execute the contract wallet deployment. Secondly, a new PAYGAS operation code is proposed. In addition to paying gas, it also becomes the separator between the verification part and the execution part in the parameters of a transaction.
Although it ended in failure at the time, it has become one of the core logics of EIP7702. Each transaction of EIP7702, combined with a special transaction structure, can be accompanied by certain codes, so that the EOA address has contract capabilities in this transaction.
EIP-7702: Set EOA account code 2024-05-07
This is also the core EIP of the mechanism discussed later in this article. Vitalik published EIP-7702 as an alternative to EIP-3074 (2024-05-07). Therefore, EIP-3074 was abandoned, and EIP-7702 was determined to be included in the upcoming ETH Prague/Electra (Pectra) hard fork. The specific content is expanded below.
3.2 The second route is to let the EOA address drive the CA address
EIP-3074: Add AUTH and AUTHCALL opcodes - 2020-10-15
Add two new OpCodes AUTH and AUTHCALL to EVM, so that EOA can use these two opcodes to authorize contracts to call other contracts on behalf of EOA.
Combined with the figure below, in summary, an EOA can send a signed message (transaction) to a trusted contract (called Invoker). This Invoker contract can use the AUTH and AUTHCALL opcodes to replace this EOA to send the transaction.
EIP-4337: Account abstraction with transaction memory pool - 2021-09-29
I have already written many articles in this regard to analyze its mechanism in depth, which can be further read:
https://research.web3caff.com/zh/archives/3212，
Interpretation of the review plan for Ethereum account abstraction ERC4337 (Part 1)
Ethereum Account Abstract 10,000-word Research Report: Disassembling 10 Related EIP Proposals and the Seven-Year Journey to Break the Bottleneck of Tens of Millions of Daily Active Users
Explain account abstraction in one hour
In short, his design was inspired by MEV, and its core value is that consensus layer protocol changes can be completely avoided.
Eip4337 proposes a new transaction object UserOperation. The user sends this object to the memory pool, and bundlers batch package and deliver contracts to execute transaction transactions from the miner dimension. In essence, it pulls the underlying transactions and account operations to the contract level for execution.
EIP-5189: Operating abstract accounts through endorsers — 2022-06-29
This is an optimization of the logic of EIP4337. It prevents DoS blocking attacks by establishing a mechanism for fund penalty endorsers in the face of malicious Bundler.
3.3 Other proposals to support AA
EIP-2718: Packing envelopes for new transaction types - 2020-06-13
This is a final proposal, which defines a new transaction type as an envelope for new transaction types to be added in the future.
The end result is that when a new transaction type is introduced, a specific code is used to distinguish which type of transaction it is, so that it only needs to be backward compatible without having to be forward compatible. The most common example is EIP1559, which distinguishes transaction fees and uses a new transaction type code without affecting the original legacy transaction type.
EIP-3607: Make it impossible to deploy contracts on EOA addresses--2021-06-10
This is a supplementary solution on the AA path, used to prevent the problem of conflict between the contract deployment address and the EOA address. It will control the contract generation method so that the system does not allow the code to be deployed to an address that is already an EOA address. This risk is actually very small. After all, the Ethereum address is 160 bits long. Although there is a way to collide the private key with the specified contract address, it is estimated that it will take another year based on the full computing power of Bitcoin.
3.4 How to understand the development of account abstraction?
First, you need to understand the value of switching to CA
Basically, this is the actual effect of EIP-4337. It can achieve
However, the core drawback of EIP-4337 is that it violates the principle of human motivation.
It seems to be better, but it has fallen into a vicious circle of market development. Many Dapps are not compatible, so users are not willing to use CA addresses. There are even higher transaction costs for using CA (in ordinary transfer scenarios, the transaction fees will double). It is also too dependent on the compatibility of Dapp itself.
Therefore, it has not been popularized on the Ethereum mainnet so far.
Cost is the most important criterion for users, and costs must be reduced.
However, to truly reduce GAS, Ethereum itself must perform a soft fork upgrade, modify the GAS calculation or modify the GAS consumption of the opcode and other modules. However, since a soft fork is required, why not directly consider EIP-7702?
4. Comprehensive analysis of EIP-7702
4.1 What is EIP-7702
It is distinguished by a new transaction type, which allows EOA to temporarily have the function of a smart contract in a single transaction, thereby supporting batch transactions, gas-free transactions, and custom permission management in business, without introducing a new EVM opCode (affecting forward compatibility).
It allows users to obtain most of AA's capabilities without deploying smart contracts, and can even provide the ability for third parties to initiate transactions on behalf of users. Users do not need to provide private keys, only sign authorization information.
4.2 Data Structure
He defines a new transaction type 0x04, whose TransactionPayload is the RLP encoded serialization result of the following content
rlp([
chain_id, //Chain ID, used to prevent replay attacks.
nonce, // Transaction counter to ensure transaction uniqueness.
max_priority_fee_per_gas, //1559 transaction fee
max_fee_per_gas, //1559 transaction fee
gas_limit,
destination, //transaction destination address
value,
data,
access_list, //Access list, used for Gas optimization in EIP-2929.
authorization_list,
signature_y_parity, // 3 signature parameters, used to verify the transaction signature.
signature_r,
signature_s
])
What’s important is that the authorization_list object is newly added to store the code that the signer wants to execute in his EOA. When the user signs the transaction, he also signs the contract code to be executed. It exists as a two-dimensional list, which means that multiple operation information can be stored in batches and batch operations can be performed.
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
4.3 Transaction Lifecycle
4.3.1 Verification Phase
At the beginning of the transaction execution, for each [chain_id, address, nonce, y_parity, r, s] tuple of authorization_list:
Use ecrecover to recover the signer address from the signatures r and s (note that this is Ethereum's own mechanism, so this EIP does not change the signature algorithm). authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s] (Similar to the previous decryption of the signature to get the from address, here we get the local signature address for this list)
Verify the chain ID (to prevent forked chain replay).
Verify whether the authority signer's code is empty or has been delegated (verify whether the transaction is a valid 7702 transaction, and the delegation mechanism will be used to execute the transaction later).
Verify the nonce of the authority signer (to prevent the authority from replaying the signature).
Set the authority signer code to 0xef0100 || address (used to bypass the EIP3607 anti-collision strategy)
Add the nonce of the authority signer (to prevent local signature replay).
Add the authority signer account to the list of accessed addresses (convert to hot addresses to reduce the gas fee for query storage)
4.3.2 Execution phase
Where is the contract code and operation instructions to be executed?
The "new" version only changes the behavior with respect to code deployment.
Instead of setting the account code to contract_code, it retrieves the code address from authorization_list and sets that code as the account code.
So, when authorization code needs to be executed, the code is loaded from the address specified by the address field of authorization_list and executed in the context of the signer's account.
This means that the user’s contract code is actually stored at a specific address on the chain rather than being included directly in the transaction.
The operation instructions and related parameters are stored in the data field of the transaction payload.
4.4 What is the value of EIP-7702?
It will change the entire chain of Web3 wallets, and the user experience will also change dramatically, because ordinary transactions initiated by EOA can also execute multiple logics similar to contracts, such as batch transfers. For CeFi scenarios, it will affect transaction identification and also affect the collection fees for deposits and withdrawals.
Due to its appearance, many previous stereotypes have been broken, such as:
This breaks the invariant that an account balance can only be reduced by transactions originating from that account.
This breaks the invariant that the EOA nonce increases by 1 after the transaction execution starts (and possibly multiple times at the same time).
The protection logic of the comparison between tx.origin and msg.sender has been broken, and many past contracts are at risk.
This breaks the current situation where EOA itself cannot issue events, and attention may need to be paid to the identification and monitoring of some on-chain events.
It breaks the status quo that EOA addresses must succeed in accepting ERC20, 721, 1155 and other assets (due to the callback mechanism, it may fail)
4.5 Comparison between EIP-7702 and EIP-4337
1. Advantages of EIP-7702
The gas is lower because it does not need to go through the entrypoint module, reducing on-chain operations.
User migration costs are lower, and there is no need to deploy on-chain contracts in advance as the main body
Compared with Eip4337, there will also be code delegation execution, and there will also be two ways:
Full Delegation
Full delegation means delegating all permissions for an operation to a specific address. For example, a user can delegate the management permissions of all ERC-20 tokens to a smart contract address, so that the smart contract can perform all relevant operations on behalf of the user.
Protected Delegation
Protected delegation means adding some restrictions and protection measures during the delegation process to ensure the security and controllability of the delegation operation.
For example, a user can delegate the management of only some of their ERC-20 tokens to a smart contract, or set some restrictions (such as spending a maximum of 1% of the total balance per day).
2. Disadvantages of EIP-7702
Its core disadvantage is that it is a soft fork upgrade, which requires consensus and huge changes, and has a wide impact on the on-chain ecology. After preliminary evaluation, Shisijun found the following challenges, but challenges are also market opportunities:
The degree of freedom is extremely high and it is difficult to be audited, so users will need more reliable wallets to provide security protection.
The changes to the original architecture are too great. Although different transaction types are used to distinguish them, many infrastructures, especially the immutable contracts on the chain, cannot be directly adapted.
Contract capabilities are provided for EOA addresses, but the corresponding storage space cannot be retained.
The cost of a single transaction is slightly higher because the Calldata portion will be greatly increased. The total cost of the estimated call will be 16 (gas) * 15 (bytes) = 240 (gas) calldata cost, plus the cost of EIP-3860 2 * 15 = 30, plus the runtime cost of about 150. Therefore, just preparing the account, even if you do nothing, will increase the Gas by 500.
"If the receiver signs code without receive functionality, the sender may face DoS when trying to send assets." See example. The problem is that EOA A signed something it shouldn't have signed - a replayable file with a wrong implementation (no receive()).
The on-chain withdrawal and deposit logic may be inconsistent. For example, when transferring ERC-20 tokens, if the recipient account has a code, the token contract will call onERC20Received on the recipient account. If onERC20Received is restored or returns an incorrect value, the token transfer will be restored.
Also if EOA can emit events, will there be any problems? Some infrastructure may need attention.
These are just some of the shortcomings that Shisijun has summarized based on the current EIP7702 proposal content and the corresponding official forum discussions. The final analysis will ultimately need to be based on the final implementation code.
References are as follows:
https://eips.ethereum.org/EIPS/eip-7702
https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923
https://github.com/ethereum/EIPs/pull/8527
5. Summary of the full text
This article may seem long, but in fact, the text content is only more than 6k words. Many of the previous EIP interpretations involved in it are linked in the article and can be expanded, so I will not trace them further.
At present, account abstraction can only be placed in the sixth module, that is, to fix everything, which is the final implementation. Now the progress of EIP7702 has been greatly accelerated, which brings more challenges to the security of the system. It can be expected that it will eventually be realized. After all, subversive events such as Ethereum mergers and modifications to consensus algorithms can occur, let alone new transaction types.
However, this time, there are too many subversions, breaking the unspoken rules that are impossible on multiple chains, and breaking the application logic of most Dapps, but it firmly occupies the most core point, that is, the cost for users is lower! Compared with the nearly doubled transaction cost of EIP4337.
The user still has an EOA address and only drives and uses the CA logic when needed, so the cost of holding is low. There is no need to convert the on-chain CA identity before performing operations, which means that users do not need to register.
Users can easily use EOA to perform multiple transactions in parallel, such as combining authorized deduction and executed deduction into one, which reduces the transaction cost for users. For Dapp, especially for projects that need to do on-chain enterprise-level management, such as exchanges, it is a disruptive optimization. Once batch aggregation is realized in the original ecology, the basic exchange cost can be reduced by more than half in an instant, which will ultimately benefit users.
Therefore, although it has changed a lot, the dimension of cost is worthy of research and adaptation by all Dapps, because this time, users will definitely stand on the side of EIP7702.