Preface

The article is divided into two main sections:

In the first part, it will start with the first AA proposal from 2015, systematically organizing the main content of EIP proposals to date. It aims to explore the historical development of AA proposals and comprehensively assess the strengths and weaknesses of each proposal.

In the second part, it will focus on comparing the market feedback following the introduction of EIP-4337 and then delve into the analysis of EIP-7702, which is set to be included in the next Ethereum upgrade. This proposal, once merged, is expected to significantly transform the nature of on-chain applications.

EIP-7702 promises revolutionary changes, and we will discuss it in detail.

1. Background of Account Abstraction

1.1 The meaning of account abstraction

At the end of 2023, Ethereum founder Vitalik Buterin updated the ETH development roadmap once again. However, the provisions related to Account Abstraction remained unchanged. The current mainstream model continues to evolve from EIP-4337 to the next phase: Voluntary EOA Conversion (self-initiated conversion of EOA accounts).

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

Since the release of EIP-4337 over a year ago (on March 1, 2023, at WalletCon in Denver, Ethereum Foundation developers announced that the core contracts of ERC-4337 had passed OpenZeppelin’s audit, marking a historical milestone for its official launch), it has received broad user recognition but has not seen widespread adoption. This paradoxical market environment has accelerated the progress of EIP-7702, which is now confirmed to be included in the next upgrade.

1.2 Current market status of account abstraction

Without further ado, let’s look at the data.

After a year and a half of development, EIP-4337 has only amassed 12 million addresses under mainstream chain accounts. What’s particularly surprising is that on the Ethereum mainnet, there are only 6,764 active addresses. While there may be issues with the statistical dimensions, this number is still vastly different from the address counts for EOAs and CAs. For context, the number of unique addresses on the Ethereum mainnet has reached 270 million (source: https://etherscan.io/chart/address).

It can be said that EIP-4337 has made no substantial progress on the mainnet.

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

However, this does not diminish the inherent value of Account Abstraction (AA). From the outset, the design of EIP-4337 was destined to face significant backward compatibility issues on the mainnet. Consequently, with various Layer 2 chains integrating native AA, EIP-4337 has seen substantial growth in addresses on Layer 2. For example, in July, the number of active users on the Base and Polygon chains reached 1 million and 3 million, respectively, which is quite impressive.

Therefore, it’s not that the design of EIP-4337 is flawed; it has many advantages that we will summarize systematically. The current situation arises from the differences between the mainnet and Layer 2, each requiring tailored solutions.

2. What is Account Abstraction?

Account Abstraction might sound complex, but it essentially addresses the issue of separating ownership.

In the Ethereum Virtual Machine (EVM) architecture, there are two types of accounts: Externally Owned Accounts (EOAs) and Contract Accounts. In EOAs, ownership and signature authority are held by the same entity. The person with the private key not only owns the account but also has the right to sign and transfer all its assets.

This setup is determined by Ethereum’s account transaction structure. In a standard Ethereum transaction, there isn’t a direct “From” address visible. When a fund transfer occurs, the actual address from which the funds are spent is inferred through the VRS parameters (i.e., the user’s signature).

This involves concepts like ECDSA asymmetric encryption and one-way threshold functions, but we won’t delve into those details here. Essentially, cryptography ensures security, which leads to the current situation where ownership and signature authority are combined in EOAs.

The core effect of EIP-4337 is to add a Sender Address field to the transaction, allowing the private key and the operated address to be separated.

So why is separating ownership so important?

Because the design of Externally Owned Accounts (EOAs) leads to several issues:

Private Key Protection: Losing the private key (due to loss, hacking, or cryptographic compromise) means losing all assets.

Limited Signature Algorithms**: The native protocol only supports ECDSA for signing and verification.

High Signature Authority: Without native multi-signature support (which can only be achieved through smart contracts), a single signature can execute any operation.

Transaction Fees: Fees can only be paid in ETH, which does not support a high volume of transactions.

Transaction Privacy: One-to-one transactions make it easy to analyze the account holder’s private information.

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

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

Users need to deal with complex fee logic, such as gas price, gas limit, and transaction blocking (nonce order), which can be too complicated.

Although many blockchain wallets or applications attempt to improve user experience through product optimization, their effectiveness has been limited.

The solution lies in implementing Account Abstraction, which decouples ownership (Owner) and signature authority (Signer) to address these issues. Historically, many solutions have emerged, eventually converging into two main approaches.

3. Historical Overview of Account Abstraction Proposals

While it may seem like there are many EIP proposals addressing the problem, fundamentally, there are just two core approaches. The issues considered in past proposals that were not approved have ultimately converged into the current solutions.

3.1 The first route is to turn the EOA address into a CA address

On November 15, 2015, Vitalik Buterin proposed a new account structure around EIP-101, which involved using contracts as accounts. This would transform addresses into entities with only code and storage space, change fee support to be paid via ERC20 tokens, and use precompiled contracts to convert native tokens into ERC20-like tokens for balance storage (with features like delegated authorization). The transaction fields were simplified to include only to, startgas, data, and code)

In hindsight, this was a revolutionary change that would drastically alter the underlying design, giving each account address its own “code” logic, which is essentially what EIP-7702 aims to achieve today. This approach could also enable additional features, such as:

Allowing transactions to use more cryptographic algorithms specified by the internal code of each address for verification and authentication.

Providing quantum resistance due to the upgradable nature of the code.

Endowing Ether with the same functional characteristics as ERC20 contracts, with features like delegated authorization, eliminating the need for native coin expenditure.

Enhancing account customization, supporting social recovery, SBT (soulbound tokens), and key recovery.

The reason for not advancing this proposal was simple: the steps were too ambitious. Issues such as transaction hash collisions and security concerns were not fully addressed, which led to its postponement. However, many of its benefits have become core features in subsequent EIPs, including EIP-4337 and EIP-7702.

Several EIPs later attempted to refine this logic:

EIP-859: Account Abstraction on Mainnet (January 30, 2018) aimed to address code deployment issues. Its core function was to use the code parameter attached to transactions to deploy contract wallets if the contract was not deployed. It also introduced a new PAYGAS opcode to separate the verification and execution parts of a transaction.

Although it did not progress at the time, this logic has become a core component of EIP-7702, which allows EOA addresses to have contract capabilities through special transaction structures that can include code.

EIP-7702: Setting EOA Account Code (May 7, 2024) is the key EIP discussed here. Vitalik proposed EIP-7702 as an alternative to EIP-3074. Consequently, EIP-3074 was abandoned, and EIP-7702 is set to be included in the upcoming ETH Prague/Electra (Pectra) hard fork. Further details will be discussed below.

3.2 The second approach is to let EOA addresses drive CA addresses.

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

This EIP introduces two new opcodes, AUTH and AUTHCALL, into the EVM, allowing EOAs to authorize contracts to replace their identity and call other contracts. In essence, an EOA can send a signed message (transaction) to a trusted contract (called an Invoker). The Invoker contract can then use the AUTH and AUTHCALL opcodes to send the transaction on behalf of the EOA.

EIP-4337: Implementing Account Abstraction via Transaction Pools (September 29, 2021)

Inspired by MEV, this EIP’s core value is that it avoids changes to the consensus layer protocol. EIP-4337 introduces a new transaction object, UserOperation, which users submit to a memory pool. Bundlers then batch and deliver these transactions to contract execution, effectively moving lower-level transaction and account operations to the contract layer.

EIP-5189: Abstract Account Operations via Endorsers (June 29, 2022)

This EIP optimizes EIP-4337 by addressing potential issues with malicious bundlers. It introduces a mechanism for endorser-backed funds to prevent DoS attacks by penalizing bad actors.

3.3 Other Proposals Supporting Account Abstraction

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

This finalized proposal defines a new transaction type as an envelope for future transaction types. It ensures that when new transaction types are introduced, they can be distinguished by specific encoding, maintaining backward compatibility without affecting legacy types. A common example is EIP-1559, which differentiated transaction fees with a new transaction type encoding while preserving legacy types.

EIP-3607: Prevent EOA Addresses from Deploying Contracts (June 10, 2021)

This supplementary proposal addresses the issue of contract deployment addresses conflicting with EOA addresses. It controls contract creation methods, preventing code from being deployed to addresses already used by EOAs. The risk is minimal given the 160-bit length of Ethereum addresses, though theoretically possible through key collisions, it would require significant computational effort.

3.4 Understanding the Development of Account Abstraction

To understand the value of transitioning to CA addresses, it’s essential to grasp the practical effects of EIP-4337, which can achieve…

However, the core drawback of EIP-4337 is that it violates the principle of human incentives. Although it appears to offer improvements, it falls into a market development deadlock. Many Dapps are still not compatible with it, causing users to be reluctant to use CA addresses. Additionally, using CAs can result in higher transaction costs (e.g., transaction fees can double in ordinary transfer scenarios), making it heavily dependent on the compatibility of Dapps.

As a result, it has not become widespread on the Ethereum mainnet to date. Cost is the most crucial factor for users, and it must be reduced. To truly lower GAS costs, Ethereum itself would need a soft fork upgrade to modify GAS calculations or change the GAS consumption of opcodes. Given the need for a soft fork, why not consider EIP-7702 directly?

4. Comprehensive analysis of EIP-7702

4.1 What is EIP-7702

It is distinguished by new transaction types, which allows EOA to temporarily have the function of a smart contract in a single transaction, thereby supporting batch transactions, gas-free transactions and customized permission management in business, without the need to introduce 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 a third party with the ability to initiate transactions on behalf of users. It does not require users to provide private keys, but only needs to sign authorized information.

4.2 Data structure

He defined a new transaction type 0x04. The TransactionPayload of this transaction type is the RLP encoding 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 target 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 transaction signature.

signature_r,

signature_s

])

The important thing is that the authorization_list object is 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, indicating that multiple operation information can be stored in batches. , perform batch operations.

authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]

4.3 Transaction Lifecycle

4.3.1 Verification Phase

At the start of the transaction execution phase, for each [chain_id, address, nonce, y_parity, r, s] tuple in the authorization_list:

Use the ecrecover function to recover the signer’s address from the signature (r, s). Note that this uses Ethereum’s existing mechanism, so the signature algorithm remains unchanged by this EIP. The address is recovered using: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s). This is similar to how the from address is derived from signatures, but it applies to the specific list signature.

Verify the chain ID to prevent replay attacks on different chains.

Check if the authority signer’s code is either empty or delegated (to confirm whether the transaction is a valid EIP-7702 transaction, with delegation mechanisms handling execution).

Verify the authority signer’s nonce to prevent replay attacks on signatures.

Set the authority signer’s code to 0xef0100 || address (to bypass EIP-3607 collision prevention strategies).

Increment the authority signer’s nonce (to prevent local signature replay).

Add the authority signer’s account to the access list (to transition to hot storage, reducing gas costs for access).

4.3.2 Execution Phase

Where are the contract code and operational instructions executed?

The “new” version changes how contract code is deployed. Instead of setting the account code directly, it retrieves the code from the authorization_list address and sets it as the account code.

When executing authorized code, load the code from the address specified in the authorization_list and execute it in the context of the signer’s account. This means the user’s contract code is stored at a specific address on the blockchain, rather than directly included in the transaction.

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

4.4 What is the value of EIP-7702?

EIP-7702 introduces significant value as it fundamentally changes the entire transaction process for Web3 wallets, leading to a drastic transformation in user experience. Ordinary transactions initiated by an EOA (Externally Owned Account) can now execute multiple logics similar to smart contract executions, such as batch transfers. This also impacts CeFi scenarios, affecting transaction identification and fees for withdrawal and consolidation.

EIP-7702 breaks many long-standing assumptions: It breaks the invariant that an account balance can only decrease due to transactions originating from that account. It breaks the invariant that the EOA nonce increases by 1 after the execution of a transaction begins (it may now increase by multiple values simultaneously). It breaks the protective logic that relies on comparing tx.origin and msg.sender, introducing potential risks to many existing contracts. It also breaks the fact that an EOA itself cannot emit events, which could affect the identification and monitoring of certain on-chain events. Finally, it breaks the assumption that an EOA address will always successfully receive ERC20, 721, 1155, and other assets (as it may fail due to the callback mechanism).

4.5 Comparison between EIP-7702 and EIP-4337

1.Advantages of EIP-7702

EIP-7702 has several advantages. One is lower gas costs, as it does not require going through the entrypoint module, reducing on-chain operations. Another is lower user migration costs, as there is no need to deploy an on-chain contract as the main entity in advance.

Compared to EIP-4337, EIP-7702 also supports delegated code execution and offers two types of delegation:

Full Delegation: This means delegating full control of a certain operation to a specific address. For example, a user can delegate the management of all ERC-20 tokens to a smart contract address, allowing the contract to perform all related operations on the user’s behalf.

Protected Delegation: This involves adding restrictions and safeguards during delegation to ensure the security and controllability of delegated operations. For instance, a user can delegate only partial management rights of ERC-20 tokens to a smart contract or set conditions (e.g., spending a maximum of 1% of the total balance per day).

2.Disadvantages of EIP-7702

The main disadvantage of EIP-7702 is that it involves a soft fork upgrade, requiring consensus from the community to push forward. Its changes are substantial and could have a wide impact on the on-chain ecosystem. Based on an initial assessment by Shisi Jun, several challenges have been identified, but these challenges could also represent market opportunities:

The high degree of freedom makes auditing difficult, leading users to demand more reliable wallets to ensure security protection.

The changes to the original architecture are significant. Although different transaction types can be distinguished, many foundational infrastructures, especially immutable on-chain contracts, may not be directly compatible.

While EIP-7702 provides contract capabilities to EOA addresses, the corresponding storage space cannot be retained.

The cost of individual transactions is slightly higher because of a significant increase in the Calldata section. The estimated total cost of a call will be 16 (gas) 15 (bytes) = 240 (gas) for calldata costs, plus EIP-3860’s cost of 2 15 = 30, and approximately 150 for runtime costs. Therefore, even preparing an account with no operations would increase gas costs by around 500.

“If the receiver signs code that lacks a receive function, the sender may face a DoS when attempting to send assets.” See the case. This issue arises when EOA A signs something it shouldn’t have—a replayable file with incorrect implementation (lacking receive()).

On-chain consolidation and withdrawal logic may be inconsistent. For example, when transferring ERC-20 tokens, if the recipient account has code, the token contract will call onERC20Received on the recipient account. If onERC20Received reverts or returns an incorrect value, the token transfer will revert.

Additionally, if an EOA can emit events, could there be any issues? Some infrastructures may need to pay attention to this.

These are just some of the disadvantages summarized by Shisi Jun based on the current EIP-7702 proposal and discussions on the official forum. A complete analysis will require examining the final implementation code.

5. Summary

The article may appear extensive, but it contains only about 6,000 words. Many references to past EIP interpretations are linked within the text for further exploration, so I won’t delve into those here.

Currently, it seems that account abstraction can only be placed in the sixth module, which is the final stage of fixing everything before pushing it forward. The accelerated progress of EIP-7702 mainly brings challenges to system security. It is foreseeable that it will eventually be implemented. After all, the Ethereum merge, which involved a major overhaul of the consensus algorithm, has already happened. A new transaction type is relatively minor in comparison.

However, this time the changes are quite disruptive, breaking multiple previously “impossible” on-chain rules and altering the logic of most DApps. Yet, EIP-7702 firmly grasps the most crucial point: it significantly reduces user costs. In contrast, EIP-4337 nearly doubles transaction costs.

Users remain EOA (Externally Owned Account) addresses but only invoke and use CA (Contract Account) logic when needed, thus reducing holding costs. There’s no need to first convert to an on-chain CA identity before performing actions, which means users don’t need to register.

Users can easily perform multiple transactions in parallel using their EOA, such as combining authorization for deduction and executing deductions. This inherently lowers transaction costs for users. For DApps, especially projects that require on-chain enterprise-level management, such as exchanges, this optimization is revolutionary. If batch consolidation is implemented natively, the basic operational costs for exchanges could be reduced by more than half, ultimately benefiting users as well.

Therefore, although EIP-7702 introduces many changes, its impact on cost alone makes it worth studying and adapting for all DApps. This time, users are undoubtedly on the side of EIP-7702.

Disclaimer：

1. This article is reprinted from [PANews]. All copyrights belong to the original author [Fourteenth Lord]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.