Author: Fourteen

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 current EIP proposal will be systematically organized, hoping to explore the historical process of AA proposals from a historical perspective and comprehensively evaluate the advantages and disadvantages of each proposal.

In the second half, it will focus on comparing the market downturn feedback after the proposal of EIP-4337 and further analyze EIP-7702, 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 epoch-making changes, let's listen to Fourteen's detailed explanation.

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 transitioning from EIP-4337 to the next stage, Voluntary EOA Conversion.

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

Since the release 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 explanation.

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

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

However, this does not diminish the intrinsic value of AA, because its design from the beginning of EIP4337 has determined that it cannot handle the serious forward compatibility issues on the mainnet. Therefore, with the widespread integration of various L2 chains, EIP4337's address count has exploded on L2, with 1 million and 3 million active users on the base and polygon chains in July, which is quite considerable.

So, it's not that EIP4337 was designed incorrectly; it has many advantages. We will summarize them 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 complicated, but it essentially solves the problem of property separation.

In the EVM architecture (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 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, which address's funds am I actually spending? It is actually resolved through its VRS parameters (i.e., user signature) to derive the From address.

This involves concepts such as ECDSA and asymmetric encryption, one-way threshold functions, etc., which we won't delve into. In short, cryptographic techniques are used to ensure security, which also leads to the current predicament of property consolidation in 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 on.

So why is property separation so important?

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

1. Difficulty in protecting private keys: User loss of private keys (loss, hacking, cryptographic cracking) means loss of all assets.

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

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

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

5. Transaction privacy leakage: One-to-one transactions make it easy to 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 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), and other concepts that are too complex for users.

Finally, although many blockchain wallets or applications attempt 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 rights (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 main routes.

3. Overview of Historical AA Proposal

Although there seem to be many EIP proposals for solving the problem, ultimately, 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 proposal.

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. Native tokens were converted to ERC20-like balances through precompiled contracts (with features such as authorization for withholding), and the transaction fields were streamlined to only include to, startgas, data, and code.

In hindsight, this was a revolutionary change, which would significantly alter the underlying design, allowing each account address to have its own "code" logic (which is actually the effect that EIP-7702 aims to achieve now).

It could also lead to other functions, such as:

1. Allowing transactions to use more encryption algorithms, with the verification and authentication methods specified by the internal code of each address.

2. Having resistance to quantum attacks, as the code has upgradeable features.

3. Making Ether have the same functional features as ERC20 contracts, with the core effect of authorization for withholding, thereby eliminating the need for native token consumption.

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

The Reasons for the Stagnation of Continued Progress

The reasons for the lack of continued progress are quite simple. It is evident that the pace was too ambitious, and there were concerns about the current transaction hash conflict issues and security vulnerabilities. These concerns led to the proposal being shelved. However, the principles of each advantage have become core features of subsequent EIP4337 and EIP7702.

Subsequently, there were a series of EIPs attempting to improve this logic.

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

This proposal attempted to address the deployment issue of code. Its core function was to allow the deployment of a contract wallet if the recipient contract was not deployed, using the code parameter attached to the transaction. It also introduced a new PAYGAS opcode, which, in addition to paying gas, served as a separator between the verification and execution parts of a transaction.

Although it was abandoned at the time, this also became one of the core logics of EIP7702. Each transaction in EIP7702, combined with a special transaction structure, can carry a certain amount of code, allowing EOA addresses to have contract capabilities in the current transaction.

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

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

The Second Route: EOA Addresses Driving CA Addresses

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

This proposal introduced two new opcodes, AUTH and AUTHCALL, to the EVM, allowing EOAs to authorize contracts to call other contracts on their behalf.

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

EIP-4337: Implementing Account Abstraction Using the Transaction Memory Pool - 2021-09-29

I have previously analyzed the mechanism in detail in many articles, which can be further explored in the following links:

• Ethereum Account Abstraction ERC4337 Approved Proposal Interpretation (Part 1)

• Ethereum Account Abstraction Research Report: Deciphering the Seven-Year Journey of 10 Related EIP Proposals and the Impact on Breaking Through the Bottleneck of Ten Million Daily Active Users

• Explaining Account Abstraction in One Hour

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

EIP-5189: Operating Abstract Accounts through Endorsers - 2022-06-29

This proposal optimized the logic of EIP4337 and aimed to prevent DoS blocking attacks by malicious Bundlers through the establishment of a fund penalty endorser mechanism.

Other Proposals Supporting AA

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

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

The ultimate effect is that when introducing new transaction types, they can be distinguished by specific encoding, 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 type.

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

This is a supplementary solution on the AA path, aimed at preventing 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 require a year of time even with the entire Bitcoin hash rate invested.

Understanding 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 an improvement, but it has fallen into a market development deadlock. Many Dapps are still not compatible, so users are unwilling to use CA addresses, and even using CA addresses results in higher transaction costs (even in regular transfer scenarios, transaction fees are doubled). It also relies too much on the compatibility of the Dapps themselves.

Therefore, it has not been widely adopted on the Ethereum mainnet to date.

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, modifying GAS calculations or the GAS consumption of opcodes, etc. However, since a soft fork is required, why not consider EIP-7702 directly?

Comprehensive Analysis of EIP-7702

4.1 What is EIP-7702

It allows EOAs to temporarily have the capabilities of smart contracts in a single transaction, thereby supporting batch transactions, gasless transactions, and custom permission management in business operations, without introducing new EVM opcodes (which would affect forward compatibility).

It allows users to obtain most of the capabilities of AA without deploying smart contracts, and even provides the ability for third parties to initiate transactions on behalf of users without requiring the user to provide their private key, only requiring the authorization of signed 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.

• rlp([
  chain_id, // Chain ID, used to prevent replay attacks.
  nonce, // Transaction counter, ensuring 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 for verifying the transaction signature.
  signature_r,
  signature_s
  ])

The important addition here is the authorization_list object, which stores the code that the signers wish to execute in their EOA. When users sign a transaction, they also sign the contract code they want to execute. It exists as a two-dimensional list, indicating that it can store multiple operation information for batch operations.

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

4.3 Transaction Lifecycle

4.3.1 Verification Phase

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

1. Recover the signer's address from the signatures r and s using ecrecover (note that this is Ethereum's 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 deriving the from address from the signature, this yields the local signing address for this list).

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

3. Verify if the code of the authority signer is empty or already delegated (to verify if the transaction is a valid 7702 transaction, subsequent delegation mechanisms will be used to delegate transaction execution).

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

5. Set the code of the authority signer to 0xef0100 || address (used to bypass the collision prevention strategy of EIP3607).

6. Increment the nonce of the authority signer (to prevent local signature replay).

7. Add the authority signer's account to the list of accessed addresses (hot address, reducing gas fees for storage queries).

4.3.2 Execution Phase

Where is 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 contract_code, but retrieves the code address from the authorization_list 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 address field of the authorization_list 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 significant change in user experience. This is because ordinary transactions initiated by EOA can also execute various logic similar to contracts, such as batch transfers. It will also impact transaction identification in CeFi scenarios and affect withdrawal and aggregation fees.

Its appearance has broken many previous fixed ideas, 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 are guaranteed to successfully receive ERC20, 721, 1155 assets (due to callback mechanisms, 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.

• Similar to EIP4337, it also involves code delegation execution and can be done in two ways:

Full Delegation

• Full delegation refers to granting 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 involves 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 limiting conditions (e.g., maximum spending of 1% of the total balance per day).

1. Disadvantages of EIP-7702

Its core drawback is that it requires a consensus-driven soft fork upgrade, and the changes are significant, with a broad impact on the on-chain ecosystem. Upon initial assessment, there are the following challenges, but challenges are also opportunities in the market:

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

2. The original architecture has changed too much. Although it is distinguished 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, even if an account is prepared to do nothing, it will increase the gas cost by 500.

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

6. On-chain withdrawal and deposit 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 pay attention.

These are just some of the drawbacks summarized by Shi Si Jun based on the current content of the EIP-7702 proposal and corresponding official forum discussions. A complete analysis will ultimately require analysis based on 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

Although this article seems extensive, the actual text is only over 6,000 words. Many previous EIP interpretations mentioned in the middle can be expanded through the links in the text, 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. Now, the rapid progress of EIP-7702 brings more challenges to the security of the system. It can be anticipated that it will eventually be implemented, after all, Ethereum's merge and disruptive events such as changing consensus algorithms can occur, so what about a new transaction type?

But this time, the content of the disruption is too much, breaking many implicit rules that were previously impossible on the chain, and also breaking the application logic of most DApps. However, 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 EOA, such as combining authorization and execution of deductions. 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 batch aggregation is natively implemented, the cost of 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 will inevitably stand on the side of EIP-7702.

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