Interpretation of the past and future of the Ethereum account abstract track from 4337 to 7702

Preface

This article is divided into two major modules:

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

In the second half, we focus on comparing the feedback of the market downturn faced by EIP4337 after the proposal, and then analyze in-depth analysis of EIP7702, which will be included in the next version of Ethereum upgrade. Once this proposal is merged, it will change the on-chain application form in all aspects.

EIP-7702 has epoch-making changes, let me listen to the fourteen kings in detail

1. Account abstract background

1.1 The abstract meaning positioning of account

Ethereum founder vitalik updated the ETH development roadmap again at the end of 2023, but the settings for account abstraction have not been changed.Today’s mainstream model is from EIP-4337 to the next stage of VoluntaryEOA Conversion (voluntary conversion of EOA account).

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

More than a year since the launch of EIP4337 (at Denver WalletCon, 2023.3.1, the core contract of ERC-4337, which was officially announced to be designed and implemented by developers of the Ethereum Foundation, has passed the audit of OpenZeppelin and is considered to be the official history of its launch.node).

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 greatly advanced, and it has even been confirmed that it will be merged into it in the next upgrade.

1.2 Account abstract market status

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

After a year and a half, EIP4337 has only 1200W addresses under the collection of mainstream chain accounts. The most surprising thing is that on the Ethereum main network, there are only 6,764 active addresses. Perhaps there are some problems with the statistical dimension, but at leastThe number of addresses that are very different from EOA and CA. You should know that the number of independent addresses on the main network of Ethereum has reached 270 million (data originated from: https://etherscan.io/chart/address).

It can be said that EIP4337 on the main network has no substantial development.

(Source of chart data: https://dune.com/niftytable/account-abstraction)

However, this does not erase the essential value of AA, because it was destined from the beginning of the design of EIP4337. He was unable to do a good job in the main network’s serious forward compatibility issues, so it is accompanied by various L2 layer chains.The number of addresses of EIP4337 is generally embedded in native AA, and the number of addresses of EIP4337 exploded on L2, among which the monthly active users of base and polygon chains in July are 100W and 300W respectively, which is quite considerable.

Therefore, it is not that EIP4337 is designed incorrectly. It has many advantages. We will summarize it systematically later. The current situation is due to the difference between the main network and L2. They need to use their own suitable solutions.

2. What is account abstraction?

Account abstraction sounds puzzling, but in fact, it essentially solves the problem of separation of property rights.

There are two types of accounts in the EVM architecture (i.e., Ethereum virtual machine), external account (EOA) and contract account (Contract Account), and external accountownershipandSignature RightIn fact, it is held by the same unit.holdPrivate keyThe person not only owns the “ownership” of this account, but also has the right to “signature transfer of all assets.”

This is determined by the transaction structure of the Ethereum account

From the structure of the figure below, we can find that in fact, Ethereum’s standard transactions do not have From. So I made a fund transfer. What is the specific fund at the address?In fact, the From address is reverse parsed through its VRS parameters (i.e., user signature).

This involves concepts such as ECDSA, one-way threshold functions, etc. We will not expand it. In short, cryptography is used to ensure security, which of course has caused the current EOA address dilemma of property rights mergers.

The core effect of EIP4337 is to add a Sender Address field to the transaction field, so that the private key can be separated from the operated address.

Then why is the separation of property rights so important?

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

1. Private keys are difficult to protect: the user loses the private key (lost, hacking, cryptographic cracked) means losing all assets.

2. There are few signature algorithms: native protocols can only use ECDSA signature and signature verification algorithms in verification transactions.

3. High signature permission: no native multi-signing (multiple signing can only be achieved through smart contracts), and arbitrary operations can be performed by single signing.

4. Transaction fees can only be paid through ETH and do not support bulk transactions.

5. Transaction Privacy Break: One-to-one transactions are easy to analyze the privacy information of account holders.

The appeal constraints make it difficult for ordinary users to use Ethereum:

First, using any app on Ethereum, users must hold Ether (and assume the risk of Ether price fluctuations).

Secondly, users need to deal with complex cost logic, and the concepts of Gas price, Gas limit, and transaction blocking (Nonce order) are too complicated for users.

Finally, while many blockchain wallets or applications try to improve user experience through product optimization, they have little effect.

Therefore, the way to break the deadlock is to realize account abstraction and decoupling ownership (Owner) and signature right (Signer), so as to solve the above problems one by one.

In fact, there are many historical plans, and they will eventually gather in two routes.

3. Clarify the context of AA historical proposals

There seem to be many EIP proposals for the solution to the problem, but in the final analysis, they are two core ideas. Therefore, the problems they consider in each EIP that has not been approved in the past have become the way to break the current plan.

3.1 The first route is to change the EOA address to the CA address

As early as November 15, 2015, Vitalik proposed a new structure for using contracts as an account around EIP-101.Change the address to only code and storage space, change the handling fee and support payment by ERC20, change the native token to ERC20 through precompiled contracts to save the balance (can have functions such as deduction authorization), and streamline the transaction fields to only to,startgas, data and code.

Now it seems that it is a great leap forward change, which will significantly change the underlying design so that each account address has its own “code” logic (in fact, it is exactly the effect that EIP-7702 needs to achieve now).

It can also derive other functions, such as

1. Let transactions use more encryption algorithms, and the signature verification method can be specified by the internal code of each address.

2. It has the characteristics of anti-quantum attacks because the code has the characteristics of upgrade.

3. Let Ethereum have functional characteristics consistent with the ERC20 contract, and the core effect is deducted authorized, so that the loss of native coins is not required.

4. Improve the account’s custom space, compatible with social recovery, sbt support, key recovery, etc.

The reason for not continuing to advance is also very simple. Obviously, the pace is too big. Regarding the current transaction hash conflict problem, security risks are not considered well, so they have been put on hold. However, the concept of each advantage has become one of the core functions of subsequent EIP4337 and EIP7702..

Later, there was a series of EIPs trying to improve this logic

EIP-859: Main chain account abstraction-2018-01-30

Trying to solve the deployment problem of Code, the core function is that if the transaction party contract is not deployed, the contract wallet deployment will be performed using the transaction attached code parameters. Secondly, a new PAYGAS operation code is proposed, which in addition to paying gas, also becomes a transaction.The separator between the verification part and the execution part in the transaction parameters.

Although it ended in vain at that time, this has become one of the core logics of EIP7702. Each transaction in EIP7702 can be accompanied by a certain code in combination with a special transaction structure, so that the EOA address has contract capabilities in this transaction.

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

This is also the core EIP of the mechanism discussed in the subsequent article, and Vitalik published EIP-7702 as an alternative to EIP-3074 (2024-05-07).Therefore, EIP-3074 has been deprecated and EIP-7702 has been determined to be included in the upcoming ETH Prague/Electra (Pectra) hard fork. We will expand the details below.

3.2 The second route is to let the EOA address drive the CA address

EIP-3074: AddedAUTHandAUTHCALLOpcode–2020-10-15

Add two new OpCodes to EVMAUTHandAUTHCALL, allowing EOA to call other contracts instead of EOA’s identity through these two opcode authorization contracts.

Based on the figure below, a summary of the EOA can send a signed message (transaction) toA contract that you trust(calledInvoker) on thisInvokerContracts can be usedAUTHandAUTHCALLThe opcode is used to send this transaction instead of this EOA.

EIP-4337: Use transaction memory pool to realize account abstraction-2021-09-29

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

eip4337 proposes new transaction objectUserOperation, the user sends this object to the memory pool, bybundlersBulk package delivery contracts to execute transactions from the miner’s dimension, which essentially brings the underlying transactions and account operations to the contract level for execution.

EIP-5189: Operation of abstract accounts through endorsement—2022-06-29

This has optimized the logic of EIP4337 and is facing maliciousnessBundlerPrevent Dos blocking attacks by establishing a mechanism for endorser for funds fines.

3.3 Other proposals for supporting AA

EIP-2718: Packaging envelopes for new transaction types-2020-06-13

This is a proposal that has been final, which defines a new transaction type as an envelope for new transaction types in the future.

The end effect is that when a new transaction type is introduced, it is distinguished by a specific encoding, so that it only needs backward compatibility without forward compatibility.The most common example is EIP1559. It distinguishes the transaction fee and uses a new transaction type encoding without affecting the initial legacy transaction type.

EIP-3607: LetEOAThe address cannot be deployed contract-2021-06-10

This is a supplementary solution on the AA path to prevent the problem of the contract deployment address conflicting with the EOA address.It controls the contract generation method so that the system does not allow the code to be deployed on addresses that are already EOA addresses.This risk is actually very small. After all, the Ethereum address is 160 bits long. Although there is a method to use the private key to collide with the private key to the specified contract address, it will take another year to estimate the full computing power investment of Bitcoin.

3.4 How to understand the abstract development history of account?

First of all, you need to understand the value after converting to CA

Basically, it is the actual effect of EIP-4337, which can achieve

However, the core disadvantage of EIP-4337 is that it violates the principle of human motivation.

It seems better, but it is trapped in a vicious cycle of market development. Many Dapps are not compatible, so users are not willing to use CA addresses, and even use CAs has higher transaction costs (ordinary transfer scenarios, they will also be able to use CAs.The transaction fee doubled), which also depends too much on the compatibility of the Dapp itself.

So it has not been popularized on the Ethereum main network so far.

Cost is the most important measure for users, and costs must be reduced.

However, to truly reduce GAS, Ethereum itself must upgrade soft forks, modify GAS consumption and other modules such as GAS calculations or modify opcodes. However, since soft forks are required, why not directly consider EIP-7702?

4. Comprehensive analysis of EIP-7702

4.1 What is EIP-7702

It distinguishes it by new transaction types, allowing EOA to temporarily have the function of smart contracts in a single transaction, thereby supporting batch transactions, Gas-free transactions and custom permission management in the business, without the need to introduce new EVM opCode (affects forward compatibility).

It allows users to obtain most of the AA’s capabilities without deploying smart contracts, and can even provide third-party capabilities to initiate transactions on behalf of users, without requiring users to provide private keys, only signing and authorized information.

4.2 Data structure

It defines a new transaction type 0x04, and the TransactionPayload of this transaction type is the RLP encoding serialization result of the following content

What is important is that the authorization_list object is added to store the code that the signer wants to execute in his EOA. The user also signs the contract code to be executed while signing the transaction. It exists as a two-dimensional list, indicating that multiple operation information can be stored in batches., perform batch operations.

4.3 Transaction life cycle

4.3.1 Verification phase

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

1. Use erecover to restore the signer address from signatures r and s (note that this is the mechanism of Ethereum itself, so this EIP does not change the signature algorithm).authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s](Similar to the previous de-signature to obtain the from address, the local signature address for this list is obtained)

2. Verify the chain ID (anti-forked chain replay).

3. verifyAuthorityWhether the signer’s code is empty or has been delegated (verify whether the transaction is a valid 7702 transaction, and the transaction will be executed through the delegation mechanism in the future).

4. verifyAuthoritySigner’s nonce (defenseAuthoritysignature playback).

5. set upAuthorityThe signer’s code is0xef0100 || address(Used to bypass EIP3607 anti-collision strategy)

6. IncreaseAuthoritySignator’s nonce (prevent local signature replay).

7. WillAuthorityAdd the signer account to the accessed address list (replace hot addresses, reduce the gas fee for query storage)

4.3.2 Execution operation phase

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

The “new” version only changes behavior in terms of code deployment.

It no longer sets the account code tocontract_code, but fromauthorization_listSearch code inaddressAnd set the code as the account code.

So, when the authorization code needs to be executed,authorization_listofaddressThe address specified by the field loads the code and executes in the context of the signer 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 transaction loaddatain the field.

4.4 What is the value of EIP-7702?

His full link of Web3 wallet will change, and the user experience will also change drastically, because ordinary transactions initiated by EOA can also execute multiple logics similar to contracts, such as batch transfers.For CeFi scenarios, it will affect transaction identification and also affect the withdrawal collection fee

Because of its appearance, it has broken many of the former constellations, such as:

1. Breaks an invariant whose account balance can only be reduced by transactions originating from that account.

2. Break the invariant that EOA nonce increases by 1 (maybe more than one at the same time) after the transaction execution begins.

3. Breaking the protection logic of the comparison of tx.origin and msg.sender, many past contracts are risky.

4. It breaks the current situation that EOA itself cannot issue events, and it may be necessary to pay attention to the identification and listening of some on-chain events.

5. Break the current situation that EOA addresses will inevitably succeed in accepting ERC20, 721, 1155 and other assets (because of the callback mechanism, it may fail)

4.5 Comparison of EIP-7702 and EIP-4337

1. Advantages of EIP-7702

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

User migration costs are lower, no need to deploy on-chain contracts in advance as the main body

Compared with Eip4337, there will also be code delegated execution, and there will be two ways:

Full Delegation

Full delegate refers to delegating all permissions of an operation to a specific address.For example, a user can delegate the management permissions of all ERC-20 tokens to a smart contract address, so that this smart contract can perform all related operations on behalf of the user.

Protected Delegation

Protected delegation refers to adding some restrictions and protection measures to the delegation process to ensure the safety and controllability of the delegation operation.

For example, users can delegate management permissions for only part of the ERC-20 tokens to a smart contract, or set some restrictions (such as spending up to 1% of the total balance per day).

2. Disadvantages of EIP-7702

His core disadvantage is that it is a soft fork upgrade, which requires everyone’s consensus and promotion, and has huge changes, which has a wide impact on the chain ecology. After the preliminary evaluation of the Fourteen Lords, there are the following challenges, but the challenge is the market opportunity:

1. The degree of freedom is extremely high and difficult to be audited. Users will need a reliable wallet to undertake security protection.

2. The original architecture has changed too much. Although it is distinguished by different transaction types, many infrastructure, especially on the chain, cannot be directly adapted.

3. Contract capability is provided for EOA addresses, but the corresponding storage space cannot be retained.

4. The cost of a separate transaction is slightly increased because the Calldata part will be greatly increased, and the total cost of the estimated call will be16 (gas) * 15 (bytes) = 240(gas) calldata cost, plus EIP-3860 cost2 * 15 = 30, plus approximately runtime cost150.Therefore, just preparing an account and doing nothing, you need to add 500 Gas.

5. “If the receiver signs a code without the receiving function, the sender may face DoS when trying to send the asset.” See case.The problem is that EOA A signs something that it shouldn’t sign—a set up an error implementation (noreceive()) playable file.

6. The on-chain retraction logic may be inconsistent, for example, when transferring ERC-20 tokens, if the receiver’s account has code, the token contract will be calledonERC20ReceivedReceiver’s account.ifonERC20ReceivedRestore or return the wrong value, and the token transfer will be restored.

7. In addition, if EOA can issue events, will there be any problems?Some infrastructure may need attention.

These are just some shortcomings summarized by the Fourteen Jun based on the current EIP7702 proposal content and the corresponding official forum discussion. In the end, it still needs to be based on the final implementation code to fully analyze.

References are as follows:

5. Full text summary

This article seems to be grand, but in fact the text content is only more than 6k words. Many of the previous EIP interpretations involved in the middle can be expanded in the article, so I won’t trace it back.

At present, account abstraction can only be placed in the sixth module, that is, repair everything, that is, it is finally being implemented. Now the progress of EIP7702 has been greatly accelerated, and more challenges to system security are brought about. It can be expected that in the end,He will implement it. After all, disruptive events such as Ethereum merger and modification of consensus algorithms can happen, so how can we talk about the only new transaction type?

However, this time there was too much subversion, breaking the impossible unspoken rules on multiple chains and breaking the application logic of most Dapps, but it occupied the most core point, that is, the cost of users is lowerNow!Compared with EIP4337’s nearly double transaction costs.

The user itself is still an EOA address, and only drives and uses CA logic when needed, so the holding cost is low.No need to convert the on-chain CA identity first before doing the operation, which means that the user does not need to register.

Users can easily use EOA to achieve multiple transactions parallelism, such as authorized deduction and execution deduction, which will reduce the transaction cost for users. For Dapps, especially those that require on-chain enterprise management.Project parties, such as exchanges, are even more disruptive and optimization. Once batch collection is realized, the cost of basic exchanges can be reduced by more than half in an instant, and ultimately it can benefit users.

Therefore, although he has changed a lot, it is worth studying and adapting to all Dapps, because this time, the user must be on the side of EIP7702.