Ethereum Pectra Upgrade: EIP-7702 Practical Guide

Author: Cobo Global

The upcoming Pectra upgrade on the Ethereum mainnet is a significant update that introduces multiple Ethereum Improvement Proposals (EIPs) at once. Among them, EIP-7702 implements a major overhaul of Externally Owned Accounts (EOAs), blurring the lines between EOAs and Contract Accounts (CAs). The new capabilities provided will have a significant impact on ordinary users, various infrastructure providers, and developers.

Recently, Pectra has been completed on the testnet and is expected to go live on the mainnet soon. This article will delve into the implementation of EIP-7702, showcasing the opportunities and risks it may bring, providing references for various users and practitioners.

Overview of EIP-7702

The actual title of EIP-7702 is EIP-7702: Set EOA account code with the subtitle Add a new tx type that permanently sets the code for an EOA. This succinctly summarizes the core elements of the proposal: it provides a transaction type that can set contract code for an EOA.

Specifically, this proposal introduces a transaction type called SETCODETX_TYPE (0x04), with the following data structure:

rlp([chainid, nonce, maxpriorityfeepergas, maxfeepergas, gaslimit, destination, value, data, accesslist, authorizationlist, signatureyparity, signaturer, signature_s])

authorizationlist = [[chainid, address, nonce, y_parity, r, s], …]

Compared to the common 0x02 transaction type, the main change is the addition of the authorizationlist field. Each element in the authorizationlist represents an authorization for an address proxy. Among them:

chain_id is the chain ID where the authorization is effective, used to prevent replay attacks.
nonce is the nonce of the authorizing address, consistent with the nonce of ordinary transactions, also used to prevent replay attacks.
address is the specified proxy address for the address proxy.
y_parity, r, s are signature data, from which the authority address can be obtained through ecrecover, i.e., the EOA address that initiated the authorization.

Each transaction can contain multiple such authorizations. It is important to note that the above authorizations have independent signatures, different from the main transaction's signature, allowing for gas payment for address authorization actions. Wallet service providers or app developers can pay gas for the authority, enabling EOA authorization without the authority needing to hold gas on its own address.

Once the transaction is on-chain, the code field of the authority address will be set to the Delegation Designation (DD) for the proxy address. The DD format is as follows:

0xef0100 || address

Where 0xef0100 is a fixed prefix, and address is the target proxy address. There is a detail here: according to EIP-3541, users cannot deploy contract code starting with 0xef through conventional contract deployment methods (transactions with to empty, create/create2 instructions). Therefore, the above delegation can only be initiated by EOAs, completed through the 0x04 transaction.

After delegation is completed, all contract calls targeting the authority will use the code on the address as code while using the authority's own storage. The user experience is very similar to that of ERC-1167 proxy contracts.

In summary: EIP-7702 allows EOAs to retain their original transaction initiation capabilities while also having the effect of Proxy contracts. Users can use SETCODETX_TYPE (0x04) transactions to set, modify, or remove the Implementation contract of the Proxy.

For other technical details regarding EIP-7702, please refer to the original proposal.

Impacts and Opportunities Brought by EIP-7702

EIP-7702 is a significant change that has a major impact on all participants in the blockchain industry and offers many new opportunities.

Contract Wallet Service Providers

From the title and implementation mechanism of the proposal itself, it can be seen that EIP-7702 does not specifically provide upper-layer capabilities related to Account Abstraction (AA) (such as gas abstraction, nonce abstraction, signature abstraction, etc.), but merely provides the basic capability to convert EOAs into Proxy contracts. Therefore, this proposal does not conflict with existing contract wallet infrastructures (such as Safe, ERC-4337, etc.). On the contrary, EIP-7702 can be almost seamlessly integrated with existing contract wallets, allowing users' EOAs to transform into Safe wallets or ERC-4337 wallets. This integration can provide features such as multi-signature, gas payment, batch transactions, passkey signatures, and more. If contract wallet providers can quickly and smoothly integrate EIP-7702, they can effectively expand their user base and enhance user experience.

DApp Developers

As EIP-7702 enhances the user experience for AA wallets, DApp developers can consider broader integration of AA wallets, providing users with a more convenient and secure experience when interacting with DApps. For example, utilizing the batch transaction capabilities of contract wallets to complete multiple DeFi operations in one go.

Another direction is that DApps can consider custom developing Delegation contracts based on project characteristics, providing users with proprietary complex contract interaction functionalities.

Asset Custodians

For exchanges and fund custodians, there is often a need to manage a large number of addresses as deposit addresses for their users and regularly consolidate funds. In traditional fund consolidation models, EOA addresses are used as deposit addresses, and during consolidation, a certain amount of gas needs to be deposited into the deposit address, which then transfers funds to the withdrawal address. The entire funding process involves a large number of transaction sends, is lengthy, and incurs high gas fees. Historically, there have been instances where institutions consolidating funds led to increased on-chain transaction fees and transaction congestion.

The emergence of EIP-7702 can seamlessly convert EOA addresses into contract wallets. Due to the gas payment mechanism of EIP-7702, there is no longer a need for gas deposit transactions. Additionally, the programmability of contract wallets can be utilized to bundle multiple consolidation transfers into a single transaction, reducing the number of transactions and saving gas consumption. Ultimately, this improves consolidation efficiency and reduces consolidation costs.

Potential Risks Brought by EIP-7702

EIP-7702 introduces new account functionalities while also bringing potential security risks, requiring wallet service providers, contract developers, and users to remain vigilant.

Wallet Service Providers

Since EIP-7702 introduces a new transaction type SETCODETX_TYPE (0x04), this transaction type is also directly related to ordinary users. Therefore, software wallet service providers like Metamask, Rabby, and various hardware wallet services need to update their software to accommodate the new transaction type.

Given that EIP-7702 authorizations have the potential to take over entire accounts, wallet service providers need to provide users with sufficient warnings in the UI, with alert levels that should be comparable to or even higher than Token Approve and Permit.

If the integration of the new transaction type and user interactions do not have strict security checks, it may lead to users falling victim to phishing attacks.

Ordinary Users

Ordinary users also need to pay attention to the new transaction types on Ethereum and keep an eye on updates from various software and hardware wallets. They should be able to effectively recognize and give sufficient attention to the new special transaction types.

This transaction type requires careful verification of the target contract for Delegation. If there is a technical background, it is best to audit the contract source code to avoid introducing security risks. Ordinary users should pay attention to whether the authorized contract is open source and provides a trustworthy third-party audit report.

New transaction types are more difficult to audit compared to previous transaction types and have stronger control capabilities over wallets. It is foreseeable that phishing attacks using this transaction type will emerge in the future. Ordinary users must actively acquire relevant knowledge and enhance their security awareness.

Contract Developers

For contract developers, EIP-7702 provides a new perspective. There are currently no mature public library components or development standards for Delegation contracts, and in the early stages of the upgrade, developers may need to implement their own Delegation contracts. It is recommended that developers conduct sufficient research to ensure they avoid security risks introduced by the new features.

According to the analysis by the Cobo security team, the following points regarding contract security need attention in EIP-7702:

1. Initialization Race Condition of Delegation Contracts

EIP-7702 only provides the ability to set code and does not provide the ability to initialize contracts. Compared to the Proxy mechanism familiar to developers, EIP-7702 essentially provides the ability to update the implementation but does not provide the ability to call the initialize function.

Taking existing mainstream contract wallets as an example, such as the wallet in the official implementation of ERC-4337, it provides an initialize method with no permission checks. The first user to call this method can gain ownership of the wallet.

contract SimpleAccount {
function initialize(address anOwner) public virtual initializer {
_initialize(anOwner);
}
}

Including Safe and other mainstream contract wallets, similar issues also exist. In the past implementations of contract wallets, the deployment of contracts and initialization were often bundled in a single transaction to achieve atomic operations, thus avoiding the race condition problem.

However, in the context of EIP-7702, the authorization signatures exist separately in the authorization_list, allowing race bots to monitor authorization transactions in the memory pool and preemptively send authorization transactions while calling the initialization function, seizing control of the contract wallet. If the EOA wallet already holds a certain amount of crypto assets, it may directly transfer assets during the race, causing financial losses to users. We can boldly speculate that in the initial period after the upgrade is completed, there will certainly be on-chain attacks based on EIP-7702 initialization race conditions.

After research, it has been found that the vast majority of existing Proxy model code cannot be safely initialized in the EIP-7702 context. Developers should adapt their existing code to EIP-7702 before making it available to users. Users should also be cautious not to authorize various old version contracts to ensure the safety of their funds.

For developers, adapting to EIP-7702 mainly involves implementing permission checks for the initialization method. A typical validation code might look like:

require(msg.sender == address(this), "Only self")

require(ECDSA.recover(hash, signature) == address(this), "Only signed")

to ensure that only the EOA itself or those holding a valid signature can call the initialization method. Considering the gas payment scenario, the latter may be more commonly used.

2. Storage Structure Conflict Issues of Delegation Contracts

In the EIP-7702 context, EOAs may frequently update Delegation, akin to Proxy upgrades. Since different Delegation contracts may be provided by various wallet vendors and DApp developers, their implementations may differ. This is unlike the scenario of contract upgrades by a single developer, where compatibility across versions is easier to ensure.

The variable storage structures of different Delegation contracts are likely to be completely different. If the same Storage slot is reused between contracts, it may read incorrect data or write unexpected data, causing contract functionality to malfunction. Once data errors occur, fixing them requires high technical capability, making it difficult for ordinary users to handle.

Here, it is recommended that developers use the Storage management model of ERC-7201, adopting a Namespace approach to use independent Storage space, avoiding the use of default slots starting with 0x0.

3. Delegation Permission Management Issues

EIP-7702 is very similar to Proxy contracts, but in the EIP-7702 context, it manages implementation contracts at the Ethereum protocol level. This is equivalent to the Proxy having a fixed, immutable owner. Therefore, EOA accounts can update contracts at any time, modify any data in the Storage space, and perform any operations.

Developers should be aware of this difference and should not trust the data in EOA Storage space when developing DApps, especially developers accustomed to the user models of Solana and SUI should pay particular attention to this issue. Ordinary users also need to be mindful of this issue when using the system.

For example, after proxying an EOA to a multi-signature wallet, the highest level of authority still belongs to the EOA private key itself.

4. New EOA Breaking Existing Security Assumptions

In older version contracts, some security assumptions that rely on the initiator being an EOA may be broken. Typically, existing standards often use the following code to check if the caller is an EOA:

require(msg.sender == tx.origin, "Only EOA")

Further assumptions may be made that EOAs do not have the capability to call contracts, thus not implementing batch call restrictions or reentrancy checks.

In the EIP-7702 context, the boundary between EOAs and CAs begins to blur, and EOAs also have the ability to execute code. Even if the above checks are passed, transferring ETH to that EOA may still trigger the fallback of the EOA proxy contract, leading to reentrancy issues. Alternatively, certain methods that restrict each transaction to a single call (such as some token mining distribution methods, NFT minting methods, etc.) can be implemented through EOA Proxy code to achieve batch calls, resulting in unintended arbitrage attacks by developers.

References

[1] EIP-3541: https://eips.ethereum.org/EIPS/eip-3541

[2] ERC-1167: https://eips.ethereum.org/EIPS/eip-1167

[3] EIP-7702: https://eips.ethereum.org/EIPS/eip-7702

[4] ERC-4337 SimpleAccount: https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/SimpleAccount.sol

[5] ERC-7201: https://eips.ethereum.org/EIPS/eip-7201

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