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 transformation of Externally Owned Accounts (EOAs), blurring the lines between EOAs and Contract Accounts (CAs). The new capabilities provided by this proposal will have a significant impact on ordinary users, various infrastructure providers, and developers.

Recently, Pectra has completed testing on the testnet and is expected to go live on the mainnet soon. This article will analyze the implementation of EIP-7702 in depth, 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 designated proxy address.
• y_parity, r, s are the 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 signature of the main transaction, allowing for gas payment for address authorization actions. Wallet service providers or app developers can pay gas for the authority, allowing EOA authorization without the authority needing to hold gas on their 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 the delegation is completed, all contract calls to the authority will use the code from the address while using the authority's own storage. The user experience is very similar to that of an ERC-1167 proxy contract.

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

For other technical details regarding EIP-7702, you can read 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 provides 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 almost seamlessly integrate with existing contract wallets, allowing users' EOAs to transform into Safe wallets or ERC-4337 wallets, thereby integrating 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

Since EIP-7702 enhances the user experience of AA wallets, DApp developers can consider broader integration of AA wallets to provide 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 at once.

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

Asset Custodians

For exchanges and fund custodians, it is usually necessary 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 charged to 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 have 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 recharge transactions. Additionally, by utilizing the programmability of contract wallets, multiple consolidation transfers can be packaged 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 introducing 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 in Ethereum and keep an eye on updates from various software and hardware wallets. They should be able to effectively recognize and pay sufficient attention to the new special transaction types.

This transaction type requires careful verification of the target contract of the Delegation. If there is a technical background, it is best to audit the contract source code to avoid introducing security risks. Ordinary users should also 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 certainly 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 new features.

According to analysis by the Cobo security team, the following points should be noted regarding contract security 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);
}
}

Other mainstream contract wallets like Safe also generally have similar issues. In past implementations of contract wallets, the deployment of contracts and initialization were often packaged in a single transaction to achieve atomic operations, thus avoiding the occurrence of race conditions.

However, in the EIP-7702 scenario, authorization signatures exist separately in the authorization_list, and race condition bots can monitor authorization transactions in the memory pool and send authorization transactions ahead of time while calling the initialize function to seize the contract wallet's permissions. If the EOA wallet already has certain 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 implementations cannot be safely initialized in the EIP-7702 scenario. Developers should adapt their existing code for 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 permission checks for the initialization method. Typical verification code might look like:

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

or

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 scenario, EOAs may frequently update Delegations, akin to Proxy upgrades. Since various Delegation contracts may be provided by different wallet vendors and DApp developers, their implementations may differ. This is unlike the scenario of contract upgrades under a single developer, where compatibility between versions is easier to ensure.

The variable storage structures of different Delegation contracts are likely to be completely different. If contracts reuse the same storage slot, it may lead to reading incorrect data or writing 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 scenario, the management of implementation contracts is conducted at the Ethereum protocol level. This means that the Proxy has 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 the EOA storage space when developing DApps, especially developers accustomed to the user models of Solana and SUI should pay special attention to this issue. Ordinary users should also be mindful of this issue when using the service.

For example, after proxying an EOA to a multi-signature wallet, the highest-level permission remains with the EOA private key itself.

4. New EOA Breaking Existing Security Assumptions

In older versions of 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 whether the caller is an EOA:

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

Further assumptions may restrict EOA from having contract calling capabilities, thus not implementing batch call restrictions or reentrancy checks.

In the EIP-7702 scenario, the boundary between EOAs and CAs begins to blur, and EOAs also have the capability to execute code. Even if the above checks pass, transferring ETH to this EOA may still trigger the fallback of the EOA proxy contract, leading to reentrancy issues. Alternatively, certain methods that restrict each transaction to only call once (such as some token mining distribution methods, NFT mint 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