The Final Battle of 10 Years of Account Abstraction: Looking at the Past and Future through EIP-7702

Pectra is the first major upgrade after Ethereum Dencun, covering the Prague execution layer hard fork and the Electra consensus layer update, integrating the most EIPs ever with a total of 11, significantly enhancing validator flexibility, network scalability, and execution efficiency. With the Ethereum mainnet Pectra hard fork expected to be officially activated on May 7, 2025, the "ultimate form" of account abstraction (Account Abstraction) ------ EIP-7702, also officially enters the public eye!

If there are any EVM-based Web3 wallets that do not support EIP-7702, then without a doubt, it means they have given up on the entire Ethereum ecosystem and its users. This is the determination of Vitalik and EF, and it is also the prologue to the unveiling of Pandora's box!

Please follow this article to gain a comprehensive understanding of the evolution of account abstraction, the user value and market changes brought about by EIP-7702, as well as the hidden dangers it may pose.

Overview

• EIP-7702 introduces a new transaction type that allows ordinary EOAs to set a specific contract address as their logical proxy contract.

• EIP-7702 will fully inherit and surpass the ecosystem built over many years by ERC-4337 due to its "cost advantages" and "flexibility."

• EIP-7702 poses an invisible risk to ordinary users; even if users do not upgrade, it may cause transaction failures or security asset loss risks in certain scenarios.

• EIP-7702 will bring a brand new user experience. When user entities undergo contractual migration, market applications will evolve accordingly. The long-awaited smooth experiences such as Gas abstraction and hierarchical family accounts will lead billions of people into the Web3 world at a low cost.

• For exchanges and DApps, applying the features of EIP-7702 will lead to a cost reduction of over 50%, thereby fully embracing the era of account abstraction.

Why Should Accounts Be Abstracted?

It's hard to imagine that the vision of account abstraction predates Ethereum itself.

During this HK Web3 Carnival, Vitalik emphasized multiple times that Ethereum has achieved 50% of the "iPhone moment" goal through a series of solutions such as Multi-sig, account abstraction, and ZK Email.

Is it fast or slow, optimistic or limited? Let's delve into the underlying layers and see why account abstraction (AA) has such influence! After all, after a decade-long journey, Vitalik has finally welcomed the long-awaited conclusion in the field of AA, adding a significant stroke to the progress bar of the Ethereum roadmap drawn for 2023.

What is account abstraction really for?

In fact, the essence of the solution is the issue of property separation, because currently the ownership and signing authority of EOA (Externally Owned Account) are held by the same entity (both rely on private keys for control of any instructions). The root of this comes from Ethereum's transaction structure, where there is actually no From field in Ethereum's standard transactions; the From address is derived from its VRS parameters (i.e., user signature) during execution.

Moreover, the design of Ethereum as a "world-class state machine" relies entirely on transactions to achieve changes in on-chain state. Combined with the inability to specify the From party, this couples the execution authority of transactions with the highest ownership.

This is the root of a series of problems with EOA, which, although simple and easy to understand, is inconvenient to use:

• Difficult to protect private keys: Losing the private key (loss, hacking, quantum attacks) means losing all assets.

• There are few signature algorithms, and different signature algorithms bring different performance overhead and even the cost of on-chain storage.

• High signature authority, EOA's native private key has all these rights.

• The transaction fees for complex transactions are high, and fees can only be paid with ETH. Any transaction or single operation requires at least a base fee of 21000.

• Transactions lack privacy; even though there was once a confidential ERC-20 protocol proposed by Circle, it did not become mainstream.

Ultimately, the current blockchain world is too complicated for users who enter it. Users need to understand concepts like Gas price, Gas limit, and transaction blocking (Nonce order). The goal of EIP-7702 is to hide this complex information from regular users.

What are the core differences between ERC-4337 and EIP-7702?

Focusing on account abstraction (AA) as the goal, there are actually more than ten different proposals, which I have previously explored. In fact, when sorted out as a whole, it essentially boils down to two routes:

Route 1: Let EOA address drive CA address

ERC-4337 is a typical example in this regard, summarized in one sentence as follows: it introduces a new transaction object UserOperation, which users send to the memory pool, and in the form of bundlers, batch packages the instructions to be executed one by one through delivery contracts. Essentially, it brings the underlying transactions and account operations to be executed at the contract level.

The execution principle is shown in the figure below:

Through the role of the bundler, it can be said that this solution can address issues such as batch transactions, gasless transactions, signature algorithm simplifications, and so on. However, it cannot resolve the complexities and user transaction costs, as well as the single point of failure risk between the bundler and EntryPoint.

Because once users migrate to ERC-4337, even if the demand of user2 in the above image is just to make a Transfer transaction, the user's transaction fee is doubled compared to EOA.

From the latest user data of CA and EOA, it can be seen that even if some users are high-end players who heavily rely on various on-chain operations based on CA, such as batch calls, why not just use ordinary CA directly?

Originating from the design of the bundler, it allows for upgrades to avoid hard fork levels and to be rolled out directly at the application layer. However, ERC-4337 also brings about doubled costs, single point of failure risks, and users have lost the original flexibility of EOA. Therefore, in the face of diverse user needs, it is clear that current market users are not so fond of the ERC-4337 solution. The overall trend has significantly declined over the past two years, and even at peak user numbers, it is still far from Ethereum's 300M independent address count.

Of course, we are not criticizing the shortcomings of ERC-4337, but rather, alongside its development, the roles and concepts such as Paymaster and Gas abstraction that have developed on it are actually applied once again in EIP-7702.

The author believes that the development of any industry will not happen overnight; what is important is to be able to discover patterns and summarize experiences from past ups and downs.

Route 2: Change EOA address to CA address

In fact, as early as November 2015, Vitalik proposed EIP-101, a new structure for accounts using contracts. The address was changed to only have code and storage space, altering the transaction fee support to be paid by ERC20, and converting the native token to a type similar to ERC20 for balance storage through a precompiled contract (which can have features like automatic deduction authorization). In January 2018, there was also the EIP-859 proposal, which core function was to deploy contract wallets using the code parameter attached to the transaction if the counterparty's contract was not deployed. Ultimately, from the EIP-3074 proposal, the further deduced EIP-7702 was eventually incorporated into the Ethereum mainnet!

The concept and effect of EIP-7702 are actually quite simple. It achieves initialization through a new transaction type, allowing users to enable EOA to temporarily and optionally have smart contract functionality in a single transaction. This further supports batch transactions, gasless transactions, and custom permission management in business operations. The most critical capability is that it provides users with temporary and optional flexibility.

Moreover, multiple people can share the same logic contract, significantly reducing the cost of user migration. To complete the setup of EIP-7702, users only need 80,000 Gas, which is about 0.06 USD, while setting up a new contract again or canceling the logic contract only requires 40,000 Gas.

After completing the setup, it can significantly bring about a large gas optimization for users during batch transactions. See the table below:

Of course, you might think, is it necessary to do the Token Transfer twice, or even six times?

Regular users are accustomed to doing one thing per transaction, which may seem limited in scenarios. However, in diversified application scenarios like Web3 Game and Web3 Pay, this frequently occurs. For example, there might be situations where users consume both copper coins (in-game currency) and silver coins (user top-up currency) at the same time. Or, participating in a certain event while consuming both NFT tickets and entrance fees.

Even if we do not imagine complex scenarios, returning to the current mainstream Swap demand on the chain, there is still a demand for batch approve and Transfer. Moreover, nowadays, we can create a small tool that simply helps users quickly delete their already useless approve authorizations. The effect is easy to compare, and it is obvious that costs can be directly reduced by about 40%.

The Core Principle of EIP-7702

To explore why there is such an effect, we must return to its principles. In fact, its core consists of two logics, divided into the user settings phase and the daily usage phase.

set up logic contract link

The core process is as follows:

• Step 1: Signature authorization, sign a special hash string using the private key of the original EOA. The content is composed of an encoded chain_id, address, and nonce. Here, the Address is the address of the logical contract that will ultimately be set, while the Nonce is the strategy to ensure that the transaction is not replayed.

• Step 2: Sign the transaction. With the authorization information from Step 1, anyone can construct a transaction of type 4, which can include multiple authorization messages, allowing for the unified authorization setting for multiple addresses at once.

• Step three: Broadcast on-chain, then when the transaction has completed internal Authorization, the logical contract will have already taken effect.

There are more technical details here that can be referenced: the implementation of the okx open-source js sdk, to see the underlying data encoding process. Of course, this solution also hides some security risks and complexities, which we will explain in detail later.

execution logic contract process

Once you have completed the setup, when any transaction is directed to your To address, it will be like calling a smart contract. The system will "load" the code of the logical contract you originally set into the current state of your EOA to execute its logic.

Similarly, we use 2 scenarios to view:

The first type, you call yourself.

If you set it up like the OKX 7702 Smart Contract with high security and customizable control capabilities, then you can specify the calldata that you have pre-written to complete multiple instructions in one go. For example, you can simultaneously complete Approve+Transfer, or you can complete Approve+Swap at the same time.

Don't underestimate it. Out of a total of 2.7 billion Ethereum transactions, there are approximately 75 million Approve transactions. Calculating at 80,000 Gas per transaction, this results in 460,000 ETH consumed. Based on the market price of ETH at 1700 USD, this amounts to nearly 800 million USD.

The second way is for others to call you.

In the past, there were no cases of others calling EOA addresses on Ethereum, but now you are a universal contract, fully customizable. You can create sub-accounts with different permissions, and you can also grant a whitelist to a few Paymasters, allowing designated accounts of DApps to initiate some transactions on your behalf, thereby completely eliminating the need for repetitive signature prompts in traditional blockchain applications.

What a powerful ability! So this is almost all