Vitalik's latest proposal EIP-7702 detailed explanation: can replace EIP-3074

Author: Vitalik, founder of Ethereum; Translation: xiaozou@黄金财经

1, Overview

Add a new transaction type (transaction type), which adds a contract_code field and a signature, and converts the signing account (not necessarily the same as txt.origin) into a smart contract wallet during the transaction, with the goal of providing functionality similar to EIP-3074.

2, Motivation

Adding short-term functional improvements to EOA, increasing the usability of applications, and in some cases supporting security improvements, is of great interest to many people. Three specific applications are as follows:

• Batching: Allowing the same user to perform multiple operations in one atomic transaction. A common example is an ERC-20 that is approved and then spent again, which is a common workflow in decentralized exchanges today that requires two transactions. Advanced use cases for batching occasionally involve dependencies: the output of the first operation is part of the input of the second operation.

• Sponsorship: Account X pays a transaction fee on behalf of Account Y. Account X can pay for this service with other ERC-20s, or it can be an application operator that includes its users' transactions for free.

• Privilege downgrade: Users can sign subkeys and give them specific permissions that are much weaker than the global access permissions for the account. For example, you can imagine the permission to pay with ERC-20 tokens instead of ETH, or spend 1% of the total balance every day, or only interact with specific applications.

EIP-3074 solves all of these use case challenges, but there are concerns about future compatibility:

• It introduces two opcodes, AUTH and AUTHCALL, which are useless in a world of "account abstraction finality" where all users eventually use smart contract wallets (which seems to be the world that will eventually happen, not the least because eventually quantum computers will terminate ECDSA used by EOA).

• It will lead to the development of an "invoker contract" ecosystem that will be independent of the "smart contract wallet" ecosystem, resulting in decentralized efforts and a lack of synergy.

The goal of this EIP is to enable all use cases of EIP-3074 without these two problems.

3、规格

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Parameters:

• FORK_BLKNUM = TBD

• TX_TYPE = TBD

• MAGIC = TBD

• PER_CONTRACT_CODE_BASE_COST = 5000

Starting from FORK_BLOCK_NUMBER, a new EIP-2718 transaction was introduced, TransactionType = TX_TYPE(TBD).

The EIP-2718 TransactionPayload of this transaction is:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s], ...], signature_y_parity, signature_r, signature_s])

The inherent cost of the new transaction is inherited from EIP-2930, which is: 21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count

In addition, we add 16 * non-zero calldata bytes + 4 * zero calldata bytes on each contract_code bytes, plus PER_CONTRACT_CODE_BASE_COST multiplied by the length of the contract_code array.

At the beginning of the transaction, for each [contract_code, y_parity, r, s] tuple:

• Set signer = ecrecover(keccak(MAGIC + contract_code), y_parity, r, s]

• Verify that the contract code of the signer is empty

• Set the contract code of the signer to contract_code

At the end of the transaction, reset each signer's contract_code to empty.

Note that the singer of any contract_code signature and the txt.origin of the transaction can be different.

4、Basic Principles

（1）Conversion of EIP-3074 Use Cases

In this design, the existing EIP-3074 workflow can be converted without much work. Specifically, AUTH and AUTHCALL will be replaced by calls to this EOA. One approach is that contract_code will be a user wallet (which can be a DELEGATECALL forwarder to save gas) and will expose two functions, verify and execute.

• AUTH will be replaced by a verify code that will use TSTORE to locally set authorized[msg.sender, ...] = True

• AUTHCALL will be replaced by an execute call that will use TLOAD to verify authorized[msg.sender, ...] and then execute from there.

Thus, converting from the "existing EIP-3074 workflow" to the workflow under this new scheme is very simple.

(2) Forward compatibility with future account abstractions

This EIP is designed to have a very high degree of forward compatibility with the future of account abstractions, without over-saving any details of ERC-4337 or RIP-7560.

Specifically:

• The contract code that the user needs to sign can be the existing ERC-4337 wallet code.

• The "code pathways" used are code pathways that continue to "work" in the pure smart contract wallet world in many cases (although perhaps not all).

• Thus, it avoids the problem of "creating two separate code ecosystems" because they will be the same ecosystem to a large extent. There may be some workflows that need to be combined under this solution, which may be better done in various "more native" environments under "account abstraction finality", but this is a relatively small part.

• It does not require the addition of any opcodes and will be useless in a post-EOA world.

• It allows EOAs to temporarily convert themselves into contracts for inclusion in ERC-4337 transaction packages in a way that is compatible with existing EntryPoints.

• Once deployed, EIP-5003 will be "only one line of code": just add a flag and don't set the code to empty at the end of the transaction.

5, Backward Compatibility

This EIP breaks the stereotype that an account balance can only be reduced by transactions originating from that account. This has implications for memory pool design and other EIPs such as inclusion lists. However, these issues are common to any proposal that provides similar functionality, including EIP-3074.

6, Security Concerns

Many of the security concerns about EIP-3074 are common. In particular, user wallets should be extra cautious when signing contract_code.