4337 से 7702 तक: एथेरियम खाता अमूर्तता के अतीत और भविष्य पर एक गहन नज़र

प्रस्तावना

This article is divided into two modules:

In the first half, we will start from the first AA proposal in 2015 and systematically organize the main contents of the Eip proposals so far. We hope to explore the history of AA proposals and comprehensively evaluate the advantages and disadvantages of each plan.

In the second half, we will focus on comparing the sluggish market feedback faced by EIP 4337 after it was proposed, and then conduct an in-depth analysis of EIP 7702, which is about to be included in the next version of Ethereum upgrade . Once this proposal is merged, it will change the form of on-chain applications in all aspects .

EIP-7702 is a revolutionary change. Let’s listen to Mr. Shisi’s detailed explanation.

1. Abstract background of the account

1.1 The significance of account abstraction

Vitalik, the founder of Ethereum, will update the ETH development roadmap again at the end of 2023, but the setting for account abstraction has not changed. Todays mainstream model is also entering the next stage of VoluntaryEOA Conversion (voluntary conversion of EOA accounts) from EIP-4337.

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

More than a year after the launch of EIP 4337 (at WalletCon in Denver on March 1, 2023, it was officially announced that the core contract of ERC-4337 designed and implemented by Ethereum Foundation developers has passed the audit of OpenZeppelin and is considered to be the historical node of the official launch).

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 incorporated into the next upgrade.

1.2 Market Status of Account Abstraction

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

After a year and a half of development, EIP 4337 has only 1.2 million addresses in the collection of mainstream chain accounts. The most surprising thing is that on the Ethereum mainnet, there are only 6,764 active addresses. Perhaps there is a problem with the statistical dimension, but at least it is far from the number of addresses of EOA and CA. 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 there is no substantial development of EIP 4337 on the mainnet.

डेटा स्रोत: 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 EIP 4337 that it could not handle the serious forward compatibility issues of the main network. Therefore, with the widespread embedding of native AA in various L2 chains, the number of EIP 4337 addresses has exploded on L2. The monthly active users of base and polygon chains in July were 1 million and 3 million respectively, which is quite impressive.

Therefore, it is not that EIP 4337 is designed wrongly. It has many advantages, which we will summarize systematically later. The current situation is due to the differences between the main network and L2. They need to use their own suitable solutions.

2. What is account abstraction?

Account abstraction sounds confusing, but in essence it solves the problem of separation of property rights.

There are two types of accounts in the EVM architecture (i.e. Ethereum Virtual Machine), external accounts (EOA) and contract accounts (Contract Account). The ownership and signing rights of external accounts are actually held by the same entity. The person holding the private key not only has the ownership of this 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, we can see that in fact, the standard transaction of Ethereum does not have a From party. So when I make a fund transfer, what address does the fund consume? In fact, the From address is deconstructed through its VRS parameter (i.e. user signature).

This involves concepts such as asymmetric encryption such as ECDSA and one-way threshold functions, which we will not elaborate on. In short, cryptography is used to ensure security. Of course, this has also led to the current EOA address dilemma of property rights mergers.

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

So why is property separation so important?

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

• Private keys are difficult to protect: If a user loses his private key (due to loss, hacker attack, or cryptographic cracking), it means losing all assets.

• Few signature algorithms: The native protocol can only use ECDSA signature and verification algorithms to verify transactions.

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

• Transaction fees can only be paid via ETH, and batch transactions are not supported.

• Transaction privacy leakage: One-to-one transactions make it easy to analyze the privacy information of account holders.

The above 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).

Secondly, users need to deal with complex fee logic. Concepts such as 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 is to realize account abstraction and decouple ownership (Owner) and signature rights (Signer), so as to solve the above problems one by one. In fact, there are many solutions in history, and they will eventually converge into two routes.

3. A brief overview of AA’s historical proposals

There seem to be many EIP proposals to solve the problem, but in the final analysis, there are only two core ideas. Therefore, the issues considered by each EIP that was not passed in the past have converged into the solution to the current solution.

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

As early as November 15, 2015, around EIP-101, Vitalik proposed a new structure of using contracts as accounts. The address was changed to only have code and storage space, the handling fee was changed to support payment by ERC 20, the native token was changed to ERC 20-like to store the balance through pre-compiled contracts (with functions such as deduction authorization), and the transaction fields were simplified to only to, startgas, data and code. Now it seems that it is a great leap forward reform, which will greatly change the underlying design, so that each account address has its own code logic (in fact, this is exactly the effect that EIP-7702 is trying to achieve now). Other functions can also be derived, such as

• Allow transactions to use more encryption algorithms, and the signature verification and authentication method can be specified by the internal code of each address

• It is resistant to quantum attacks because the code is upgradeable.

• Make Ethereum have the same functional characteristics as ERC 20 contracts, and the core effect has the withholding authorization, so there is no need to lose the native currency

• Improve account customization space, compatible with social recovery, sbt support, key retrieval, etc.

The reason for not moving forward is very simple. It is obviously too big a step. The current transaction hash conflict problem and security risks have not been carefully considered, so it has been shelved. However, the concept of each advantage has become one of the core functions of the subsequent EIP 4337 and EIP 7702.

Later, a series of EIPs attempted to improve this logic:

EIP-859: Mainchain Account Abstraction – 2018-01-30

It attempts to solve the deployment problem of Code. Its core function is that if the contract of the transaction party is not deployed, the code parameter attached to the transaction is used to execute the contract wallet deployment. Secondly, a new PAYGAS operation code is proposed. In addition to paying gas, it also becomes a separator between the verification part and the execution part of the parameters of a transaction. Although it ended in failure at the time, it has become one of the core logics of EIP 7702. Each transaction of EIP 7702 can be attached with a certain code in combination with a special transaction structure, so that the EOA address has contract capabilities in this transaction.

EIP-7702: Set EOA account code 2024-05-07

This is also the core EIP of the mechanism discussed later in this article. Vitalik published EIP-7702 as an alternative to EIP-3074 (2024-05-07). Therefore, EIP-3074 was abandoned, and EIP-7702 was determined to be included in the upcoming ETH Prague/Electra (Pectra) hard fork. The specific content is explained below.

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

EIP-3074: Add AUTH and AUTHCALL opcodes – 2020-10-15

Add two new OpCodes AUTH and AUTHCALL to EVM, so that EOA can use these two opcodes to authorize contracts to call other contracts on behalf of EOA. Combined with the following figure, in summary, an EOA can send a signed message (transaction) to a contract it trusts (called Invoker), and this Invoker contract can use AUTH and AUTHCALL opcodes to send the transaction on behalf of this EOA.

EIP-4337: Account abstraction using transaction memory pool – 2021-09-29

I have already written many articles in this regard to analyze its mechanism in depth, which can be further read:

• https://research.web3 caff.com/zh/archives/3212,

• Interpretation of the review plan for Ethereum account abstraction ERC 4337 (Part 1)

  Ethereum Account Abstract 10,000-word Research Report: Disassembling 10 Related EIP Proposals and the Seven-Year Journey to Break the Bottleneck of Ten Million Daily Active Users

• Explain account abstraction in one hour

In short, his design was inspired by MEV, and its core value is that consensus layer protocol changes can be completely avoided.

EIP 4337 proposes a new transaction object UserOperation. The user sends this object to the memory pool, and bundlers batch package and deliver the contract to execute the transaction from the miner dimension. In essence, it pulls the underlying transactions and account operations to the contract level for execution.

EIP-5189: Operating abstract accounts through endorsers — 2022-06-29

This is an optimization of the logic of EIP 4337. It prevents DoS blocking attacks by establishing a mechanism for endorsing endorsers with financial penalties in the face of malicious Bundlers.

3.3 Other proposals to support AA

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

This is a final proposal that defines a new transaction type as an envelope for new transaction types in the future. The final effect is that when a new transaction type is introduced, a specific code is used to distinguish which type of transaction it is, so that it only needs to be backward compatible without forward compatibility. The most common example is EIP 1559, which distinguishes transaction fees and uses new transaction type codes without affecting the original legacy transaction type.

EIP-3607: Make EOA addresses unable to deploy contracts–2021-06-10

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

3.4 How to understand the development of account abstraction?

First, you need to understand the value of switching to CA

Basically, this is the actual effect of EIP-4337. It can achieve

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

It seems to be better, but it is caught in a vicious circle of market development. Many Dapps are not compatible, so users are not willing to use CA addresses. There is even a higher transaction cost for using CA (in ordinary transfer scenarios, the transaction fee will double). It is also too dependent on the compatibility of the Dapp itself.

Therefore, it has not been popularized on the Ethereum mainnet so far.

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

However, to truly reduce GAS, Ethereum itself must perform a soft fork upgrade, modify the GAS calculation or modify the GAS consumption of the opcode and other modules. However, 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 is distinguished by a new transaction type, which allows EOA to temporarily have the functions of a smart contract in a single transaction, thereby supporting batch transactions, gas-free transactions, and custom permission management in business, without introducing a new EVM opCode (affecting forward compatibility).

It allows users to obtain most of AAs capabilities without deploying smart contracts, and can even provide the ability for third parties to initiate transactions on behalf of users. Users do not need to provide private keys, only sign authorization information.

4.2 Data Structure

He defines a new transaction type 0x04, the TransactionPayload of which is the RLP encoded serialization result of the following content

What’s important is that a new authorization_list object has been 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, which means that multiple operation information can be stored in batches and batch operations can be performed.

4.3 Transaction Lifecycle

4.3.1 Verification Phase

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

1. Use ecrecover to recover the signer address from the signatures r and s (note that this is Ethereums own 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 the previous decryption of the signature to get the from address, here we get the local signature address for this list)

2. Verify chain ID (anti-fork chain replay).

3. Verify whether the authority signers 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 later).

4. Verify the nonce of the authority signer (to prevent the authority from replaying the signature).

5. Set the authority signer code to 0x ef 0100 || address (used to bypass the EIP 3607 anti-collision strategy)

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

7. Add the authority signer account to the list of accessed addresses (convert to hot addresses to reduce gas fees for querying storage)

4.3.2 Execution phase

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

The new version only changes the behavior with respect to code deployment.

Instead of setting the account code to contract_code, it retrieves the code address from authorization_list and sets that code as the account code.

So, when authorization code needs to be executed, the code is loaded from the address specified by the address field of the authorization_list and executed in the context of the signers account.

इस का मतलब है कि the user’s contract code is actually stored at a specific address on the chain rather than being included directly 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 change the entire chain of Web3 wallets, and the user experience will also change dramatically, because ordinary transactions initiated by EOA can also execute multiple logics similar to contracts, such as batch transfer. For CeFi scenarios, it will affect transaction identification and the collection of withdrawal and recharge fees. Due to its appearance, many previous stereotypes have been broken, such as:

1. This breaks the invariant that an account balance can only be reduced by transactions originating from that account.

2. This breaks the invariant that the EOA nonce increases by 1 after the transaction execution starts (possibly multiple times at the same time).

3. The protection logic of comparing tx.origin and msg.sender has been broken, and many past contracts are at risk.

4. This breaks the current situation where EOA itself cannot emit events, and attention may need to be paid to the identification and monitoring of some on-chain events.

5. This breaks the current situation where EOA addresses accepting ERC 20, 721, 1155 and other assets will inevitably succeed (due to the callback mechanism, they may fail)

4.5 Comparison between EIP-7702 and EIP-4337

1. Advantages of EIP-7702

• Gas is lower because it does not need to go through the entrypoint module, reducing on-chain operations.

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

• Compared with Eip 4337, there will also be code delegation execution, and there will also be two ways:

Full Delegation

• Full delegation means delegating all permissions for 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 the smart contract can perform all relevant operations on behalf of the user.

Protected Delegation

• Protected delegation means adding some restrictions and protection measures during the delegation process to ensure the security and controllability of the delegation operation.

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

2. Disadvantages of EIP-7702

Its core disadvantage is that it is a soft fork upgrade, which requires consensus and huge changes, and has a wide impact on the on-chain ecology . After preliminary evaluation, Shisijun found the following challenges, but challenges are also market opportunities:

1. The degree of freedom is extremely high and it is difficult to be audited, so users will need more reliable wallets to provide security protection.

2. The changes to the original architecture are too great. Although different transaction types are used to distinguish them, many infrastructures, especially the immutable contracts on the chain, cannot be directly adapted.

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

4. The cost of a single transaction is slightly higher because the Calldata portion will be greatly increased. The total cost of the estimated call will be 16 (gas) * 15 (bytes) = 240 (gas) calldata cost, plus the cost of EIP-3860 2 * 15 = 30, plus the approximate runtime cost of 150. Therefore, just preparing the account, even if you do nothing, will increase the Gas by 500.

5. If the receiver signs code without receive functionality, the sender may face DoS when trying to send assets. See example. The problem is that EOA A signed something it shouldnt have signed – a replayable file with a wrong implementation (no receive()).

6. The on-chain withdrawal and deposit logic may be inconsistent. For example, when transferring ERC-20 tokens, if the recipient account has a code, the token contract will call onERC 20 Received on the recipient account. If onERC 20 Received is restored or returns an incorrect value, the token transfer will be restored.

7. Also, if EOA can emit events, will there be any problems? Some infrastructure may need attention.

These are just some of the shortcomings that Shisijun has summarized based on the current EIP 7702 proposal content and the corresponding official forum discussion. The final analysis will need to be based on the final implementation code. References are as follows:

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 of the full text

This article may seem long, but in fact, the text content is only more than 6k words. Many of the previous EIP interpretations involved in it are linked in the article and can be expanded, so I will not trace them further.

At present, account abstraction can only be placed in the sixth module, that is, to fix everything, which is the final implementation. Now the progress of EIP 7702 has been greatly accelerated, which brings more challenges to the security of the system. It can be expected that it will eventually be realized. After all, subversive events such as Ethereum mergers and modifications to consensus algorithms can occur, let alone new transaction types.

However, this time, there are too many subversions, breaking the unspoken rules that are impossible on multiple chains, and breaking the application logic of most Dapps, but it firmly occupies the most core point, that is, the cost for users is lower! Compared with the nearly doubled transaction cost of EIP 4337.

The user still has an EOA address and only drives and uses the CA logic when needed, so the cost of holding is low. There is no need to convert the on-chain CA identity before performing operations, which means that users do not need to register.

Users can easily use EOA to perform multiple transactions in parallel, such as combining authorized deduction and executed deduction into one, which reduces the transaction cost for users. For Dapp, especially for projects that need to do enterprise-level management on the chain, such as exchanges, it is a disruptive optimization. Once batch aggregation is realized in the original ecology, the basic exchange cost can be reduced by more than half in an instant, which can ultimately benefit users.

Therefore, although it has changed a lot, the dimension of cost is worthy of research and adaptation by all Dapps, because this time, users will definitely stand on the side of EIP 7702.

This article is sourced from the internet: From 4337 to 7702: An in-depth look at the past and future of Ethereum account abstraction