Interpreting the past and future of the ETH account abstraction track from 4337 to 7702

Preface

The article is divided into two main sections:

In the first half, starting from the first AA proposal in 2015, the system will organize the main contents of the Eip proposals so far, hoping to explore the history of AA historical proposals from the perspective of history, and comprehensively evaluate the advantages and disadvantages of each proposal.

In the second half, the emphasis is on comparing the market’s downturn feedback after the proposal of EIP4337, and then analyzing in depth EIP7702, which is about to be included in the next version of Ethereum upgrade. Once this proposal is merged, it will comprehensively change the form of on-chain applications.

EIP-7702 has a revolutionary change, let’s listen to Shisijun’s detailed explanation.

1. The background of account abstraction

1.1 Positioning of Account Abstraction

Ethereum founder Vitalik updated the ETH development roadmap again at the end of 2023, but the settings for account abstraction have not been changed. The current mainstream mode is also transitioning from EIP-4337 to the next stage, Voluntary EOA Conversion.

For over a year since the launch of EIP4337 (officially announced at WalletCon in Denver on 3.1.2023, the core contract of ERC-4337 designed and implemented by the developers of the ETH Foundation has passed the audit of OpenZeppelin and is considered the historical Node officially launched).

Always 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

No need to say more, just look at the data.

After a year and a half of development, EIP4337 has only 12 million addresses under the collection of mainstream chain accounts. The most surprising thing is that there are only 6,764 active addresses on the ETH mainnet. Perhaps there is a problem with the statistical dimension, but at least it differs greatly from the number of EOA and CA addresses. You should know that the number of independent addresses on the ETH mainnet has reached 270 million (data source: ).

It can be said that there is no substantial development of EIP4337 on the Mainnet.

(Chart data source: )

However, this does not erase the intrinsic value of AA, because its design from the beginning of EIP4337 has destined it to be unable to cope with the serious backward compatibility issues of the Mainnet. Therefore, along with the widespread embedding of native AA in various L2 chains, the number of Addresses of EIP4337 has surged on L2, with the monthly active users of base and polygon chains in July reaching 1 million and 3 million respectively, which is quite impressive.

So, it’s not that EIP4337 was designed wrong, it has many advantages. We will summarize it systematically later. The current situation is due to the differences between the Mainnet and L2, and they need to use their respective suitable solutions.

2. What is account abstraction?

Account abstraction may sound confusing, but it actually addresses the issue of separating ownership rights.

In the EVM architecture (i.e., Ethereum Virtual Machine), there are two types of accounts, external accounts (EOA) and contract accounts. 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 transaction structure of the ETH account.

From the structure in the figure below, it can be found that standard transactions in Ethereum do not have a From field. So, when I made a fund transfer, which Address’s funds were actually consumed? In fact, the FromAddress is reverse-parsed through its VRS parameters (i.e., the user’s signature).

This involves concepts such as ECDSA and asymmetric encryption, one-way threshold functions, etc. We won’t delve into it. In short, cryptography is used to ensure security here, which has led to the current predicament of property merging into EOA addresses.

The core effect of EIP4337 is to add the Sender Address field in the transaction field, which can separate the Private Key from the operated Address.

So why is property rights separation so important?

Because the external account (EOA) design will lead to more issues:

1. Difficult to protect Private Key: Losing the Private Key (due to loss, hacker attacks, or cryptographic cracking) means losing all assets.
2. Signature Algorithm is limited: The native protocol can only use ECDSA for signature and verification in transaction validation.
3. High signature authority: No native multi-signature (multi-signature can only be achieved through Smart Contracts for collaboration), single signature can execute any operation.
4. Transaction fees can only be paid in ETH and do not support batch trading.
5. Privacy Leakage in Transactions: One-to-one transactions make it easy to analyze the privacy information of the account holder.

The constraints of appeals make it difficult for ordinary users to use Ethereum.

First, users of any application on the Ethereum network must hold Ether (and bear the risk of Ether price Fluctuation).

Secondly, users need to deal with complex fee logic, concepts such as Gas price, Gas limit, transaction blocking (Nonce order) are too complex for users.

Finally, although many Block chain Wallets or applications try to improve user experience through product optimization, their actual effect is minimal.

Therefore, the way to break the deadlock is to achieve account abstraction, decoupling ownership and signing authority (Signer), so as to solve the above problems one by one.

Actually, there are many historical plans, and they will all eventually converge into two routes.

3. AA historical proposal context sorting

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

3.1 The first route is to change EOAAddress to CAAddress

As early as November 15, 2015, around EIP-101, Vitalik proposed a new structure for accounts using contracts. The Address was changed to only include code and storage space, and the fee support was changed to be paid by ERC20. The native Token balance was converted to a class ERC20 through precompiled contracts (which can have functions such as authorized deduction), and the transaction fields were simplified to only include to, startgas, data, and code.

Now it seems to be a Great Leap Forward-style transformation, which will greatly change the underlying design, allowing each accountAddress to have its own “code” logic (which is actually the effect that EIP-7702 is supposed to achieve now).

Other functions can also be derived, such as

1. Allowing more Encryption Algorithms for transactions, which can be specified by the internal Code of each Address for signature verification and authentication methods
2. Have the anti-quantum attack feature because the code has the upgrade feature.
3. Give Ethereum the same functionality as ERC20 contracts, with the core effect of delegated authorization, thus avoiding the loss of the native currency.
4. Improve the custom space of the account, compatible with social recovery, sbt support, Secret Key retrieval, etc.

The reason for not continuing to advance is also very simple, apparently the pace is too great, and the security risk of the current trading hash conflict is not considered carefully, so it has been shelved, but the concept of each advantage has become one of the core functions of the 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

Attempting to solve the deployment problem of Code, the core function is, if there is a case where the contract of the transaction party is not deployed, then the contract Wallet deployment is executed using the code parameter attached to the transaction. Secondly, a new PAYGAS opcode is proposed, which, in addition to paying gas, also serves as a separator between the verification part and the execution part of a transaction’s parameters.

Although he died suddenly at that time, it also became one of the core logics of EIP7702 now. Each transaction of EIP7702 combines a special transaction structure, which can carry certain code, so that EOAAddress can have contract capability in this transaction.

EIP-7702: Setting EOA account code 2024-05-07

This is also the core EIP of the subsequent discussion mechanism in this article. Vitalik proposed EIP-7702 as an alternative to EIP-3074 (2024-05-07). Therefore, EIP-3074 is deprecated, and EIP-7702 is confirmed to be included in the upcoming ETH Prague/Electra (Pectra) Hard Fork, and the specific content will be discussed in the following text.

3.2 The second route is to drive CAAddress with EOAAddress

**EIP-3074: Adding AUTH and AUTHCALL opcodes–2020-10-15

Add two new OpCodes AUTH and AUTHCALL in EVM, so that EOA can authorize contracts to call other contracts on behalf of EOA through these two opcodes.

With reference to the figure below, in summary, an EOA can send a signed message (transaction) to a trusted contract (referred to as Invoker), which can use the AUTH and AUTHCALL opcodes to send out the transaction on behalf of the EOA.

EIP-4337: Implementing account abstraction with transaction mempool–2021-09-29

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

EIP4337 proposes a new transaction object UserOperation. Users send this object to the mempool, and bundlers batch pack and deliver contract execution transaction transactions from the perspective of Miner. Essentially, it pulls the underlying transactions and account operations to the contract level for execution.

EIP-5189: Operating abstract account through endorser - 2022-06-29

This is an optimization of the logic of EIP4337, which is to prevent Dos blocking attacks by establishing a mechanism for malicious Bundlers to impose fines on fund endorsement endorsers.

3.3 Other Proposals to Support AA

EIP-2718: Packaging Envelope for New Transaction Types–2020-06-13

This is a Final proposal that defines a new transaction type as an envelope for future added transaction types.

The ultimate effect is that when introducing new transaction types, they are 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, uses a new transaction type encoding, and does not affect the original legacy transaction type.

EIP-3607: Make EOA Address not deployable contract–2021-06-10

This is a supplementary solution on the AA path to prevent conflicts between the deployed contract Address and EOAAddress. It controls the contract generation method and prevents the system from deploying code to an Address that is already an EOA Address. This risk is actually very small, after all, Ethereum Address is 160 bits long. Although there is a method to collide with a specified contract AddressPrivate Key using a Private Key, it is estimated that it will still take a year with the full computing power of BTC.

**3.4 How to understand the abstract development process of the account?

First, it is necessary to understand the value after conversion to CA.

Basically, it’s 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.

He seems to be better, but he is trapped in a dead cycle of market development. Many Dapps are not compatible, so users are unwilling to use CA addresses. Even using CA has higher transaction costs (in ordinary transfer scenarios, Money Laundering will double), and it is too dependent on the compatibility of Dapps themselves.

So far, it has not been popularized on the Ether mainnet.

Cost is the most important criterion for users to measure, and the cost must be dropped.

But to truly drop gas, Ethereum itself must undergo a soft fork upgrade, modifying gas calculation or 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

What is EIP-7702

It distinguishes itself through new transaction types, allowing EOA to temporarily have the functionality of smart contracts in a single transaction, supporting business operations such as batch transactions, gas-free transactions, and custom permission management, without introducing new EVM opCodes (which would affect backward compatibility).

He can allow users to obtain most of the capabilities of AA without deploying Smart Contracts, and even provide the ability for third parties to initiate transactions on behalf of users without requiring users to provide Private Key, only signed authorization information is required.

4.2 Data Structure

He defined a new transaction type 0x04, and the TransactionPayload of this transaction type is the RLP encoding serialization result of the following content.

The important thing is the addition of the authorization_list object, which stores the code that the signer wants to execute in its EOA. When a user signs a transaction, they also sign the contract code to be executed. It exists as a two-dimensional list, indicating that multiple operation information can be stored in batches for batch execution.

4.3 Trade Lifecycle

4.3.1 Verification Phase

At the beginning stage of executing a transaction, for each [chain_id, address, nonce, y_parity, r, s] tuple in the authorization_list:

1. Recover the signer Address from the signature r and s using ecrecover (note that this is an Ethereum 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 obtaining fromAddress from signature earlier, this recovers a local signature Address for this list)
2. Verification chain ID (anti-fork chain replay).
3. Verify that the code of the authority signer is not empty or has been delegated (to verify if the transaction belongs to a valid 7702 transaction, the delegation mechanism will be used to execute the transaction later).
4. Verify the nonce of the authority signer to prevent signature replay attacks.
5. Set the code of the authority signer to 0xef0100 || address (used to bypass EIP3607 collision prevention strategy).
6. Increase the nonce of the authority signer to prevent local signature replay.
7. Add the authority signer account to the accessed Address list (convert hot Address, drop the stored gas fee query)

4.3.2 Execution Phase

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

“New” version only changes the behavior of code deployment.

It no longer sets the account code to contract_code, but retrieves the code address from the authorization_list and sets that code as the account code.

So, when it is necessary to execute the authorization code, load the code specified by the address field of the authorization_list, and execute it in the context of the signer’s account.

This means that the user’s contract code is actually stored at some specific on-chain Address, rather than directly included in the transaction.

While the operation instructions and related parameters are stored in the data field of the transaction payload.

What value does EIP-7702 have?

There will be changes to the entire chain of Web3Wallet, and the user experience will also change significantly as a result, because ordinary transactions initiated by EOA can also execute various logics similar to contracts, such as batch transfer. It will affect transaction identification in the CeFi scenario, as well as the collection of withdrawal and deposit fees.

Due to its emergence, it has broken many preconceptions, such as:

1. The invariance that the account balance can only be reduced by transactions originating from that account has been broken.
2. Breaks the invariant that the EOA nonce increases by 1 after the start of transaction execution (which may increase multiple at the same time).
3. The protection logic of tx.origin and msg.sender comparison is broken, and many past contracts are at risk.
4. Breaks the current situation where EOA itself cannot emit events, and attention may be needed to identify and listen to certain on-chain events.
5. Breaks the current situation where EOAAddress accepting assets such as ERC20, 721, 1155 is inevitably successful (may fail due to pullback mechanism)

4.5 Compare EIP-7702 and EIP-4337

1. The advantages of EIP-7702

Lower gas because there is no need to go through the entrypoint module, reducing on-chain operations.

The user migration cost is 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 methods:

Full Delegation

Full delegation refers to delegating all permissions of a specific operation to a specific Address. For example, a user can delegate all management permissions of ERC-20 Tokens to a Smart Contract Address, allowing this Smart Contract to execute all relevant 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 delegation operation.

For example, users can delegate management authority of only some 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. The disadvantages of EIP-7702

His core drawback is related to the Soft Fork upgrade, which requires Consensus from everyone to promote and involves significant changes, with a broad impact on the on-chain ecosystem. Upon initial assessment, there are the following challenges for the Fourteen Lords, but challenges also present market opportunities:

1. Very high degree of freedom, difficult to audit, users will increasingly demand a reliable Wallet to take on security protection.
2. The original architecture has changed too much, although it is differentiated by different transaction types, many infrastructures, especially on-chain immutable contracts, cannot be directly adapted.
3. Contract capabilities have been provided for EOA Address, but corresponding storage space cannot be retained.
4. The cost of individual transactions is slightly higher because it will significantly increase the Calldata part. The estimated total cost of the call is 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 without doing anything will increase the Gas by 500.
5. “If the recipient signs code that does not include the receive function, the sender may face DoS when attempting to send assets.” See case. The issue is actually EOA A signing something it shouldn’t have signed - a replayable transaction with a faulty implementation (no receive()).
6. The on-chain deposit and withdrawal logic may be inconsistent, for example, when transferring ERC-20 Tokens, if the receiving account has code, the Token contract will call the onERC20Received of the receiving account. If onERC20Received restores or returns an incorrect value, the token transfer will be reverted.
7. Additionally, if EOA can issue events, would there be any problems? Some infrastructure may need to pay attention.

These are just some of the shortcomings summarized by the 14 gentlemen based on the current EIP7702 proposal and the corresponding official forum discussions. Ultimately, a complete analysis will need to be based on the final implementation code.

Refer to the following:

5. Summary of the Whole Text

This article seems to have a large volume, but in fact, the actual text content is only about 6k words, many previous EIP interpretations mentioned in the middle can be expanded through links in the article, I will not further trace back.

Currently, account abstraction can only be placed in the sixth module, which is to fix everything, and finally implement it. 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, the ETH merge, changing the Consensus Algorithm, and other disruptive events can occur, so what about mere new transaction types.

But this time there are too many disruptive changes, breaking multiple on-chain impossible unwritten rules, and also breaking the application logic of most Dapps. But it firmly holds onto one crucial point: the cost for users is lower! Compared to the nearly doubled Transaction Cost of EIP4337.

The user itself is still an EOAAddress, but only drives and uses the CA logic when needed, so the holding cost is lower. There is no need to convert the on-chain CA identity before operation, which means that the user does not need to register.

Users can easily achieve multiple concurrent transactions with EOA, such as combining authorization withholding and execution withholding. This reduces the Transaction Cost for users themselves. For Dapps, especially project parties that require on-chain enterprise-level management, such as exchanges, it is a disruptive optimization. Once batch collection is implemented in the native ecosystem, the basic exchange cost can be reduced by more than half in an instant, ultimately benefiting users.

So, although he has changed a lot, it is worth all Dapps to study and adapt to the cost dimension, because this time, users must stand on the side of EIP7702.