From 4337 to 7702: An In-depth Interpretation of the Past and Future of Ethereum Account Abstraction Track

Author: Shisi Jun

Preface

This article is divided into two main modules:

In the first half, we will start from the first AA proposal in 2015, systematically organizing the main content of the EIP proposals up to now. The aim is to explore the historical process of AA proposals from a historical perspective and to comprehensively evaluate the advantages and disadvantages of each proposal.

In the second half, we will focus on comparing the market's sluggish feedback after the proposal of EIP4337, and then delve into the EIP7702, which is about to be included in the next version of the Ethereum upgrade. Once this proposal is merged, it will fundamentally change the form of on-chain applications.

EIP-7702 has epoch-making changes; let Shisi Jun elaborate.

1. Background of Account Abstraction

1.1 The Significance of Account Abstraction

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

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

Since the launch of EIP4337 over a year ago (on March 1, 2023, at WalletCon in Denver, it was officially announced that the core contract of ERC-4337, designed and implemented by Ethereum Foundation developers, has passed OpenZeppelin's audit, marking a historical node for its official launch), it has received widespread recognition from users but has not been widely used. This contradictory market environment has significantly accelerated the progress of EIP-7702, which has already been confirmed to be merged in the next upgrade.

1.2 Current Market Status of Account Abstraction

No need for further words, let's look at the data directly.

After a year and a half of development, EIP4337 has only 12 million addresses under the mainstream chain accounts, among which the most surprising fact is that there are only 6,764 active addresses on the Ethereum mainnet. Perhaps there are issues with the statistical dimensions, but at least it is vastly different from the number of EOA and CA addresses. It is worth noting that the number of unique 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 progress on the mainnet.

(Chart data source: https://dune.com/niftytable/account-abstraction)

However, this does not diminish the essential value of AA, as its design from the beginning of EIP4337 destined it to struggle with severe backward compatibility issues on the mainnet. Therefore, with the widespread embedding of native AA in various L2 chains, the number of EIP4337 addresses has exploded on L2, with the monthly active users on the Base and Polygon chains in July being 1 million and 3 million, respectively, which is quite impressive.

Thus, it is not that the design of EIP4337 is wrong; it has many advantages, which we will summarize systematically later. The current situation stems from the differences between the mainnet and L2, and they need to use their respective suitable solutions.

2. What is Account Abstraction?

Account abstraction sounds complicated, but it essentially addresses the issue of property rights separation.

In the EVM architecture (Ethereum Virtual Machine), there are two types of accounts: External Owned Accounts (EOA) and Contract Accounts (CA). The ownership and signing rights of an external account 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 Ethereum accounts.

From the structure in the diagram below, it can be seen that standard transactions on Ethereum do not have a From party. So when I make a fund transfer, which address's funds are actually being consumed? It is actually parsed out from the From address through its VRS parameters (i.e., user signature).

This involves concepts such as ECDSA and asymmetric encryption, one-way threshold functions, etc., which we will not elaborate on here. In short, cryptography ensures security, but this has also led to the current predicament of property merging with EOA addresses.

The core effect of EIP4337 is to add a Sender Address field in the transaction fields, allowing the private key to be separated from the address being operated on.

So why is property rights separation so important?

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

1. Difficult to protect private keys: Losing a private key (loss, hacking, cryptographic cracking) means losing all assets.

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

3. High signing authority: There is no native multi-signature (multi-signature can only be achieved through smart contracts), and a single signature can execute any operation.

4. Transaction fees can only be paid in ETH, and batch transactions are not supported.

5. Transaction privacy leakage: One-to-one transactions easily analyze the privacy information of account holders.

These constraints make it difficult for ordinary users to use Ethereum:

First, to use any application on Ethereum, users must hold ETH (and bear the risk of ETH price fluctuations).

Second, users need to deal with complex fee logic; concepts like 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 lies in achieving account abstraction, decoupling ownership (Owner) and signing rights (Signer), thereby addressing the above issues one by one.

In fact, there have been many historical solutions, which ultimately converge into two routes.

3. Historical Context of AA Proposals

The solutions to the problem seem to have many EIP proposals, but fundamentally, they boil down to two core ideas. Thus, every past EIP that was not approved has contributed to the current solution's breakthrough.

3.1 The First Route: Transforming EOA Addresses into CA Addresses

As early as November 15, 2015, around EIP-101, Vitalik proposed a new structure for accounts as contracts. The address would be changed to contain only code and storage space, altering the fee support to be paid by ERC20, and using precompiled contracts to convert native tokens into ERC20-like for balance storage (capable of supporting features like authorization for deduction), simplifying the transaction fields to only include to, startgas, data, and code.

In retrospect, this was a leap-forward reform that would significantly alter the underlying design, allowing each account address to have its own "code" logic (which is essentially what EIP-7702 aims to achieve).

It could also derive other functionalities, such as:

1. Allowing transactions to use more cryptographic algorithms, which can be specified by the internal code of each address for verification and authentication methods.

2. Possessing quantum attack resistance features, as the code has upgrade capabilities.

3. Allowing ETH to have functionalities consistent with ERC20 contracts, with core effects including authorization for deduction, thus eliminating the need for native coin consumption.

4. Enhancing the customization space of accounts, compatible with social recovery, SBT support, key recovery, etc.

The reason it was not further advanced is simple; it was clearly too ambitious. Concerns about the current transaction hash collision issues and security risks were not adequately considered, so it was shelved. However, each of its advantages has become one of the core functions of subsequent EIP4337 and EIP7702.

Later, a series of EIPs attempted to refine this logic.

EIP-859: Main Chain Account Abstraction - January 30, 2018

This aimed to solve the code deployment issue. Its core function was that if a transaction's contract was not deployed, it would execute the contract wallet deployment using the code parameter attached to the transaction. It also proposed a new PAYGAS opcode, which, in addition to paying gas, also became a separator between the verification and execution parts of a transaction.

Although it ended without results at that time, it has become one of the core logics of EIP7702. Each transaction of EIP7702 can combine a special transaction structure that allows EOA addresses to have contract capabilities.

EIP-7702: Setting EOA Account Code - May 7, 2024

This is also the core EIP discussed later in this article. Vitalik published EIP-7702 as a replacement for EIP-3074 (May 7, 2024). Therefore, EIP-3074 was abandoned, and EIP-7702 was confirmed to be included in the upcoming ETH Prague/Electra (Pectra) hard fork, which we will elaborate on later.

3.2 The Second Route: Driving CA Addresses with EOA Addresses

EIP-3074: Adding AUTH and AUTHCALL Opcodes - October 15, 2020

This introduced two new opcodes, AUTH and AUTHCALL, into the EVM, allowing EOAs to authorize contracts to call other contracts on behalf of the EOA through these two opcodes.

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 send this transaction on behalf of the EOA.

EIP-4337: Implementing Account Abstraction through Transaction Memory Pool - September 29, 2021

I have previously analyzed its mechanism in depth in many articles; you can read more:

• https://research.web3caff.com/zh/archives/3212

• Interpretation of Ethereum Account Abstraction ERC4337 Approval Plan (Part 1)

• A Comprehensive Research Report on Ethereum Account Abstraction: Dissecting 10 Related EIP Proposals and the Seven-Year Journey to Break Through the 10 Million Daily Active User Bottleneck

• Explaining Account Abstraction in One Hour

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

EIP4337 proposed a new transaction object, UserOperation, which users send to the memory pool. Bundlers package it in bulk from the miner's perspective and deliver it for contract execution. Essentially, it pulls the underlying transaction and account operations to be executed at the contract level.

EIP-5189: Operating Abstract Accounts through Endorsers - June 29, 2022

This optimized the logic of EIP4337, addressing malicious Bundlers by establishing a funding penalty endorsement mechanism to prevent DoS blocking attacks.

3.3 Other Proposals Supporting AA

EIP-2718: New Transaction Type Envelope - June 13, 2020

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

The final effect is that when introducing new transaction types, it distinguishes which type of transaction it is through specific encoding, allowing it to only require backward compatibility without needing forward compatibility. The most common example is EIP1559, which distinguished transaction fees, used a new transaction type encoding, and did not affect the original legacy transaction type.

EIP-3607: Preventing EOA Addresses from Deploying Contracts - June 10, 2021

This is a supplementary solution on the AA path, aimed at preventing conflicts between contract deployment addresses and EOA addresses. It controls the contract generation method, preventing the system from allowing code to be deployed to an address that is already an EOA address. This risk is actually quite small; after all, Ethereum addresses are 160 bits long. Although there are methods to collide a private key to produce a specific contract address, it would still take about a year with full Bitcoin computational power investment.

3.4 How to Understand the Development History of Account Abstraction?

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

Basically, this 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 better, but it falls into a dead cycle of market development. Many DApps are still not compatible, so users are reluctant to use CA addresses, and using CA incurs higher transaction costs (in ordinary transfer scenarios, transaction fees can double), making it too dependent on the compatibility of the DApps themselves.

Thus, it has not gained popularity on the Ethereum mainnet to date.

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

However, to truly lower GAS, Ethereum itself must undergo a soft fork upgrade, modifying GAS calculations or changing the GAS consumption of opcode modules. 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 distinguishes itself through a new transaction type, allowing EOAs to temporarily possess the functionality of smart contracts in a single transaction, thereby supporting batch transactions, gasless transactions, and custom permission management, without introducing new EVM opcodes (which would affect backward compatibility).

It enables users to gain most of the AA capabilities without deploying smart contracts, and even allows third parties to initiate transactions on behalf of users without requiring users to provide private keys, only needing to sign authorization information.

4.2 Data Structure

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

• rlp([
  chainid, // Chain ID, used to prevent replay attacks. nonce, // Transaction counter, ensuring transaction uniqueness. maxpriorityfeepergas, // 1559 transaction fee maxfeepergas, // 1559 transaction fee
  gaslimit, destination, // Transaction target address value, data, accesslist, // Access list, used for gas optimization in EIP-2929.
  authorizationlist, signatureyparity, // 3 signature parameters for verifying transaction signatures. signaturer,
  signature_s
  ])

Importantly, it introduces the authorization_list object, which stores the code that the signer wishes to execute in their EOA. When users sign the 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 for batch operations.

• authorizationlist = [[chainid, address, nonce, y_parity, r, s], …]

 

4.3 Transaction Lifecycle

4.3.1 Verification Stage

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

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 how the From address is derived from previous signature verification, this derives the local signed address for this list).

2. Verify the chain ID (to prevent replay on forked chains).

3. Verify whether the authority signer's code is empty or has been delegated (to verify whether the transaction belongs to a valid 7702 transaction, which will later be executed through the delegation mechanism).

4. Verify the authority signer's nonce (to prevent replay of the authority's signature).

5. Set the authority signer's code to 0xef0100 || address (to bypass EIP3607's anti-collision strategy).

6. Increment the authority signer's nonce (to prevent replay of local signatures).

7. Add the authority signer's account to the accessed address list (to reduce gas fees for querying storage).

4.3.2 Execution Operation Stage

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

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.

Thus, when the authorized code needs to be executed, it loads the code specified by the address field of the authorization_list and executes it 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 Value Does EIP-7702 Bring?

It will change the entire chain of Web3 wallets, significantly altering user experience, as ordinary transactions initiated by EOAs can execute various logics similar to contract execution, such as batch transfers. For CeFi scenarios, it will affect transaction identification and also impact withdrawal and aggregation fees.

With its emergence, it breaks many previous conventions, such as:

1. Breaking the invariant that account balances can only decrease due to transactions originating from that account.

2. Breaking the invariant that the EOA nonce increases by 1 after transaction execution starts (it may increase multiple times simultaneously).

3. Breaking the protective logic comparing tx.origin and msg.sender, which poses risks to many past contracts.

4. Breaking the current situation where EOAs cannot emit events, which may require attention for some on-chain event recognition and listening.

5. Breaking the current situation where EOA addresses must successfully accept ERC20, 721, 1155, and other assets (due to the 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 go through the entry point module, reducing on-chain operations.

• Lower user migration costs, as there is no need to deploy a contract on-chain in advance.

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

Full Delegation

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

Protected Delegation

• Protected delegation means 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 part of the management permissions of ERC-20 tokens to a smart contract or set some limiting conditions (such as spending a maximum of 1% of the total balance per day).

1. Disadvantages of EIP-7702

Its core drawback is that it is a soft fork upgrade that requires consensus among everyone to promote, and the changes are significant, impacting the on-chain ecosystem broadly. After preliminary assessment, Shisi Jun has identified the following challenges, but challenges also present market opportunities:

1. Extremely high freedom makes it difficult to audit; users will demand reliable wallets to undertake security protection.

2. The changes to the original architecture are too large; although different transaction types are used to distinguish, many infrastructures, especially on-chain immutable contracts, cannot be directly adapted.

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

4. The cost of individual transactions slightly increases because it will significantly increase the calldata portion. The estimated total cost of invocation will be 16 (gas) * 15 (bytes) = 240 (gas) calldata cost, plus EIP-3860's cost of 2 * 15 = 30, and an estimated runtime cost of 150. Therefore, just preparing the account, even if doing nothing, will increase gas by 500.

5. "If the recipient signs code without receiving functionality, the sender may face DoS when attempting to send assets." See case. This issue arises when EOA A signs something it should not sign—a replay file with an incorrect implementation (without receive()).

6. 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 on the receiving account. If onERC20Received reverts or returns an incorrect value, the token transfer will revert.

7. Additionally, if EOAs can emit events, could there be any issues? Some infrastructure may need to pay attention.

These are just some drawbacks that Shisi Jun has summarized based on the current content of the EIP7702 proposal and corresponding discussions in the official forum. A complete analysis will 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. Full Summary

This article may seem lengthy, but the actual text content is only over 6,000 words. Many past EIP interpretations mentioned in the article can be explored through the links provided, so I will not trace them further.

Currently, it seems that account abstraction can only be placed in the sixth module, which is to fix everything, and ultimately promote it. The progress of EIP7702 has significantly accelerated, bringing more challenges to system security. It can be anticipated that it will ultimately be realized, as disruptive events like Ethereum's merge and changes to the consensus algorithm can occur; how can a mere new transaction type be an exception?

However, this time the content of the disruption is too extensive, breaking multiple impossible unspoken rules on-chain and altering the application logic of most DApps. Yet it firmly occupies the most critical point: the cost for users has decreased! Compared to the nearly doubled transaction costs of EIP4337, this is significant.

Users remain as EOA addresses, only driving and using CA logic when needed, thus lowering the holding costs. There is no need to first convert to an on-chain CA identity before performing operations, meaning users do not need to register.

Users can easily achieve multiple parallel transactions with EOA, such as combining authorization for deduction and executing deductions, which inherently lowers the transaction costs for users. For DApps, especially projects that require on-chain enterprise-level management, such as exchanges, this is a revolutionary optimization. Once batch aggregation is realized in its original form, the basic trading costs for exchanges can be reduced by more than half, ultimately benefiting users.

Therefore, although it changes a lot, occupying the dimension of cost makes it worthwhile for all DApps to study and adapt, because this time, users will undoubtedly stand on the side of EIP7702.