Preface

This article is divided into two main sections:

In the first half, starting from the first AA proposal in 2015, the main content of the EIP proposal is systematically organized up to now, with the expectation of exploring the historical process of AA proposals from a historical perspective, and comprehensively evaluating the advantages and disadvantages of each proposal.

In the second half, it focuses on comparing the market downturn feedback after the proposal of EIP-4337, and then deeply analyzes the EIP-7702, which is about to be included in the next version of the Ethereum upgrade. Once this proposal is merged, it will comprehensively change the form of on-chain applications.

EIP-7702 has epoch-making changes, let's listen to the detailed explanation by Shijun.

1. Background of Account Abstraction

1.1 Significance of Account Abstraction

Vitalik, the founder of Ethereum, updated the ETH development roadmap at the end of 2023, but the setting for account abstraction has not changed. The current mainstream mode is from EIP-4337, entering the next stage of Voluntary EOA Conversion.

https://x.com/VitalikButerin/status/1741190491578810445

Since the launch of EIP4337 more than a year ago (at WalletCon in Denver on March 1, 2023, the core contract of ERC-4337 designed and implemented by Ethereum Foundation developers has been audited by OpenZeppelin and is considered a formal historical milestone).

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 significantly advanced, and it has been confirmed to be merged in the next upgrade.

1.2 Market Status of Account Abstraction

Let's look at the data directly without much ado.

After a year and a half of development, EIP4337 has only 12 million addresses in the collection of mainstream chain accounts, of which the most surprising is that there are only 6,764 active addresses on the Ethereum mainnet. Perhaps there are some problems with the statistics, but at least the difference between the number of EOA and CA addresses is quite large. 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 EIP4337 has made no substantial development on the mainnet.

Data source: https://dune.com/niftytable/account-abstraction）

However, this does not diminish the essential value of AA, because from the beginning, the design of EIP4337 has determined that it cannot handle the serious forward compatibility issues on the mainnet. Therefore, with the widespread embedding of native AA in various L2 chains, the number of addresses of EIP4337 has exploded on L2, with 1 million and 3 million monthly active users on the base and polygon chains in July, which is quite considerable.

So, it's not that EIP4337 was designed wrong, it has many advantages, which we will summarize systematically later. The current situation is due to the differences between the mainnet and L2, and they need to use their own suitable solutions.

2. What is Account Abstraction?

Account abstraction may sound confusing, but it essentially solves the problem of property separation.

In the EVM architecture (i.e., Ethereum Virtual Machine), there are two types of accounts, external accounts (EOA) and contract accounts (CA). The ownership and signing rights of external accounts are actually held by the same entity. The person holding the private key not only owns the 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, it can be seen that standard Ethereum transactions do not have a "From" field. So, when I make a fund transfer, what specific address's funds are being spent? It is actually resolved through its VRS parameters (i.e., user signature).

This involves concepts such as ECDSA and asymmetric encryption, one-way threshold functions, etc., which we won't go into. In short, this is safeguarded by cryptography, which also leads to the current predicament of property consolidation of EOA addresses.

The core effect of EIP4337 is to add a Sender Address field in the transaction field, thereby separating the private key from the address being operated.

So why is property separation so important?

Because the design of external accounts (EOA) leads to more problems:

• Difficult to protect private keys: If a user loses their private key (loss, hacking, cryptographic cracking), it means losing all assets.

• Limited signature algorithms: The native protocol can only use ECDSA signature and verification algorithms for transaction verification.

• High signature authority: No native multi-signature (multi-signature can only be achieved through smart contracts for collaboration), a single signature can execute any operation.

• Transaction fees can only be paid in ETH and do not support batch transactions.

• 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).

Second, users need to deal with complex fee logic, gas price, gas limit, transaction blocking (Nonce order), these concepts are too complex for users.

Finally, although many blockchain wallets or applications try to improve user experience through product optimization, their actual effects are minimal.

Therefore, the breakthrough lies in achieving account abstraction, decoupling ownership (Owner) and signing authority (Signer), in order to solve the above problems one by one. In fact, there are many historical solutions, and they will eventually converge into two routes.

3. Historical Proposal Context of AA

Although there seem to be many EIP proposals for solving the problem, fundamentally, there are only two core ideas. Therefore, every EIP that has not been passed in the past has converged into the breakthrough of the current solution.

3.1 The first route is to transform EOA addresses into CA addresses

As early as November 15, 2015, around EIP-101, Vitalik proposed a new structure with contracts as accounts. The address was changed to only have code and storage space, and the fee support was changed to be paid by ERC20, and the native tokens were converted to ERC20-like balances through precompiled contracts (with functions such as authorization for withholding). The transaction fields were simplified to only include to, startgas, data, and code. Now it seems like a great leap forward, which will significantly change the underlying design, allowing each account address to have its own "code" logic (which is actually the effect that EIP-7702 wants to achieve now). It can also lead to other functions, such as

• Let transactions use more encryption algorithms, which can be specified by the internal Code of each address for signature authentication methods
• Possess resistance to quantum attacks, because the code has upgrade capabilities
• Enable Ether to have the same functionality as ERC20 contracts, with the core effect of authorization for withholding, thereby avoiding the loss of native tokens
• Enhance the customization space of accounts, compatible with social recovery, SBT support, key recovery, etc.

The reason for not continuing to advance is also simple. It is obviously because the pace is too large, and the consideration of security risks and hash conflicts in current transactions is not thorough, so it has been shelved. However, the concept of each advantage has become one of the core functions of subsequent EIP4337 and EIP7702.

Later, there were a series of EIPs attempting to improve this logic:

EIP-859: Main Chain Account Abstraction--2018-01-30

It attempted to solve the deployment problem of Code. The core function is that if a transaction party contract is not deployed, the transaction will use the code parameter to execute the contract wallet deployment. It also proposed a new PAYGAS opcode, which, in addition to paying gas, also serves as a separator between the verification and execution parts of a transaction. Although it ended without success at the time, it has become one of the core logics of EIP7702 now. Each transaction of EIP7702 combines a special transaction structure, which can carry a certain code, allowing EOA addresses to have contract capabilities in this transaction.

EIP-7702: Setting EOA Account Code 2024-05-07

This is also the core EIP for the subsequent discussion mechanism, and was published by Vitalik as an alternative to EIP-3074 (2024-05-07). Therefore, EIP-3074 was deprecated, and EIP-7702 was confirmed to be included in the upcoming ETH Prague/Electra (Pectra) hard fork. We will discuss the specific content in the following sections.

3.2 The second route is to drive CA addresses with EOA addresses

EIP-3074: Add AUTH and AUTHCALL opcodes--2020-10-15

It adds two new opcodes, AUTH and AUTHCALL, to the EVM, allowing EOAs to authorize contracts to call other contracts through these two opcodes. In summary, an EOA can send a signed message (transaction) to a trusted contract (called Invoker), and this Invoker contract can use the AUTH and AUTHCALL opcodes to send out this transaction on behalf of the EOA.

EIP-4337: Implement account abstraction using the transaction pool--2021-09-29

I have previously written many articles analyzing its mechanism, which can be further read at:

• In-depth analysis of Ethereum account abstraction ERC4337's approved solution (Part 1)
• Ethereum account abstraction research report: Deciphering the seven-year journey of 10 related EIP proposals and the impact on millions of daily active users
• Explaining account abstraction in one hour

In short, it was inspired by MEV for its design, and its core value is to completely avoid changes to the consensus layer protocol.

EIP4337 proposes a new transaction object, UserOperation, which users send to the transaction pool, and bundlers batch package and deliver the contract execution transaction from the miner's perspective. Essentially, 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, and it is a mechanism to prevent DoS blocking attacks by malicious Bundlers through the establishment of a fund penalty endorsement endorser.

3.3 Other proposals to support AA

EIP-2718: Envelope for new transaction types--2020-06-13

This is a Final proposal that defines a new transaction type as an envelope for future new transaction types. The ultimate effect is that when introducing new transaction types, they can be distinguished by specific encoding to indicate which type of transaction it is, allowing for backward compatibility without the need for forward compatibility. The most common example is EIP1559, which distinguishes transaction fees and uses a new transaction type encoding without affecting the original legacy transaction types.

EIP-3607: Prevent EOA addresses from deploying contracts--2021-06-10

This is a supplementary solution on the AA path to prevent conflicts between contract deployment addresses and EOA addresses. It controls the contract creation method, preventing the system from allowing code deployment to addresses that are already EOA addresses. This risk is actually very small, as Ethereum addresses are 160 bits long. Although there is a method to collide private keys to generate a specific contract address, it would still take a year with the entire Bitcoin hash rate invested.

3.4 How to understand the development history of account abstraction?

First, it is necessary to understand the value of transforming into CA.

Basically, it is the actual effect of EIP-4337, which 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 market development dead end. Many Dapps are still not compatible, so users are unwilling to use CA addresses, and even using CA addresses incurs higher transaction costs (in the case of ordinary transfers, transaction fees will double). It also relies too much on the compatibility of the Dapps themselves.

So, it has not been popular on the Ethereum mainnet so far.

Cost is the most important measure for users, and it must be reduced.

But to truly reduce GAS, Ethereum itself must undergo a soft fork upgrade, modify GAS calculations, or modify the GAS consumption of opcodes, etc. However, since a soft fork is required, why not consider EIP-7702 directly?

4. Comprehensive Analysis of EIP-7702

4.1 What is EIP-7702

It distinguishes itself through new transaction types, allowing EOAs to temporarily have the functionality of smart contracts in a single transaction, thereby supporting batch transactions, gasless transactions, and custom permission management in business operations, without the need to introduce new EVM opCodes (which would affect backward compatibility).

It allows users to obtain most of the AA capabilities without deploying smart contracts, and even provides the ability for third parties to initiate transactions on behalf of users without the need for users to provide private keys, only requiring the signing of authorized information.

4.2 Data Structure

It defines a new transaction type 0x04, and the TransactionPayload of this transaction type is the RLP-encoded serialization result of the following content:

The important addition is the authorization_list object, which stores the code that the signers wish to execute in their EOA. The user signs the transaction and also signs the contract code to be executed. It exists as a two-dimensional list, indicating that multiple operation information can be batched for execution.

4.3 Transaction Lifecycle

4.3.1 Verification Phase

At the beginning of transaction execution, for each tuple of [chainid, address, nonce, yparity, r, s] in the authorization_list:

1. Recover the signer's address from the signature r, s using ecrecover (note that this is Ethereum's own mechanism, so this EIP does not change the signature algorithm). authority = ecrecover(keccak(MAGIC || rlp([chainid, address, nonce])), yparity, r, s] (similar to obtaining the from address from the signature, here the local signing address for this list is obtained).
2. Verify the chain ID (to prevent replay on forked chains).
3. Verify if the signer's code is empty or already delegated (to verify if the transaction is a valid 7702 transaction, subsequent delegation mechanism will be used to delegate transaction execution).
4. Verify the signer's nonce (to prevent replay of the signer's signature).
5. Set the signer's code to 0xef0100 || address (to bypass the collision prevention strategy of EIP3607).
6. Increase the signer's nonce (to prevent local signature replay).
7. Add the signer's account to the list of visited addresses (hot addresses, reducing gas fees for storage queries).

4.3.2 Execution Phase

Where is the contract code to be executed and the operation instructions?

The "new" version only changes the behavior of code deployment.

It no longer sets the account code as contractcode, but retrieves the code address from the authorizationlist and sets that code as the account code.

So, when the authorized code needs to be executed, the code is loaded from the address specified in the authorization_list's address field 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 directly included 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 bring changes to the entire Web3 wallet chain, leading to a huge change in user experience, as ordinary transactions initiated by EOAs can also execute various logic similar to contracts, such as batch transfers. It will affect transaction identification in CeFi scenarios and also affect the withdrawal and aggregation of fees. Its appearance has broken many previous conventions, such as:

1. Breaking the invariance that account balances can only decrease due to transactions originating from that account.
2. Breaking the invariance that EOA nonce increases by 1 after transaction execution begins (it may increase by multiple).
3. Breaking the protection logic of comparing tx.origin and msg.sender, posing risks to many past contracts.
4. Breaking the current situation where EOAs cannot emit events, requiring attention to some on-chain event identification and monitoring.
5. Breaking the current situation where EOA addresses must necessarily succeed in receiving ERC20, 721, 1155 assets (due to callback mechanism, it may fail).

4.5 Comparison of EIP-7702 and EIP-4337

1. Advantages of EIP-7702

• Lower gas costs, as it does not need to go through the entrypoint module, reducing on-chain operations.
• Lower user migration costs, as there is no need to deploy on-chain contracts in advance.

Compared to EIP4337, it will also have code delegation execution and two ways:

Full Delegation

• Full delegation refers to delegating all permissions for a specific operation to a specific address. For example, a user can delegate all ERC-20 token management permissions to a smart contract address, allowing the smart contract to execute all related operations on behalf of the user.

Protected Delegation

• Protected delegation refers to adding some restrictions and protective measures during the delegation process to ensure the security and controllability of the delegated operation. For example, a user can delegate only some ERC-20 token management permissions 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 drawback is that it requires a soft fork upgrade, needs consensus to push, and has a huge impact on the on-chain ecosystem, which presents several challenges, but challenges are also opportunities in the market.

1. The freedom is extremely high, making it difficult to audit, and users will increasingly demand reliable wallets to provide security protection.

2. The original architecture changes too much. Although it is differentiated by different transaction types, many infrastructures, especially on-chain immutable contracts, cannot be directly adapted.

3. It provides contract capabilities for EOA addresses, but the corresponding storage space cannot be retained.

4. The cost of individual transactions is slightly higher because it will significantly increase the Calldata portion. The estimated total cost of the call will be 16 (gas) * 15 (bytes) = 240 (gas) Calldata cost, plus the cost of EIP-3860, 2 * 15 = 30, and approximately 150 for runtime cost. Therefore, just preparing the account, even if nothing is done, will increase the gas by 500.

5. "If the recipient signs a code that does not have a receive function, the sender may face a DoS when attempting to send assets." See the case. This problem actually arises when EOA A signs something it should not sign—a replayable file with an incorrect implementation (no receive()).

6. The on-chain withdrawal logic may be inconsistent. For example, when transferring ERC-20 tokens, if the receiving account has code, the token contract will call onERC20Received in the receiving account. If onERC20Received reverts or returns an incorrect value, the token transfer will be reverted.

7. Additionally, if EOAs can emit events, will there be any issues? Some infrastructure may need to be cautious.

These are just some of the drawbacks summarized by Shi Jun based on the current content of the EIP-7702 proposal and corresponding official forum discussions. A complete analysis will ultimately require the final implementation code. References:

• 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 Entire Article

This article, although seemingly lengthy, actually contains only over 6,000 words. Many previous EIP interpretations mentioned in the middle can be expanded by following the links in the article, so I won't delve further into them.

Currently, it seems that account abstraction can only be placed in the sixth module, which is to fix everything, and ultimately to be implemented last. Now, the significant acceleration of EIP-7702's progress brings more challenges to the system's security. It can be anticipated that it will eventually be implemented, after all, Ethereum's merge and changes to consensus algorithms are possible, so what's the big deal about a new transaction type?

However, this time, the content of the disruption is too much, breaking many implicit rules that were previously impossible on the chain, and also disrupting the application logic of most DApps. But it firmly holds onto the most crucial point, which is that the cost for users is lower! Compared to the nearly doubled transaction cost of EIP-4337.

Users themselves are still EOA addresses, only driving and using CA logic when needed, so the holding cost is lower. There is no need to first convert to an on-chain CA identity before performing operations, which means users do not need to register.

Users can easily perform multiple transactions in parallel using EOAs, such as combining authorization and execution of deductions into one. This reduces the transaction cost for users, and for DApps, especially for project parties that need on-chain enterprise-level management, such as exchanges, it is a disruptive optimization. Once native batch aggregation is implemented, the basic transaction costs for exchanges can be reduced by more than half in an instant, ultimately benefiting users.

Therefore, although it has changed a lot, from the perspective of cost, it is worth it for all DApps to research and adapt, because this time, users are bound to be on the side of EIP-7702.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。