Ethereum Pectra Upgrade: In-depth Analysis and Best Practices Guide for EIP-7702

Foreword

Ethereum is about to welcome the Pectra upgrade, which is a significant update that will introduce several important Ethereum Improvement Proposals (EIPs). Among them, EIP-7702 has brought transformative changes to the Ethereum external account (EOA). This proposal blurs the lines between EOA and contract accounts (CA), marking a key step towards native account abstraction following EIP-4337 and bringing a new interaction model to the Ethereum ecosystem.

Pectra has completed its deployment on the test network and is expected to go live on the mainnet soon. This article will delve into the implementation mechanism of EIP-7702, explore the opportunities and challenges it may bring, and provide practical operational guidelines for different participants.

Protocol Analysis

Overview

EIP-7702 introduces a brand new transaction type that allows an EOA to specify a smart contract address, thereby setting code for it. This enables the EOA to execute code like a smart contract while retaining the ability to initiate transactions. This feature endows the EOA with programmability and composability, allowing users to implement functions such as social recovery, permission control, multi-sign management, zk verification, subscription payments, transaction sponsorship, and transaction batching within the EOA. It is worth mentioning that EIP-7702 is perfectly compatible with the smart contract wallets realized by EIP-4337, and the seamless integration of the two greatly simplifies the development and application process of new functionalities.

The specific implementation of EIP-7702 introduces a transaction type SET_CODE_TX_TYPE (0x04), with the data structure defined as follows:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

The authorization_list field is defined as:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

In the new trading structure, in addition to the authorization_list field, the rest follow the same semantics as EIP-4844. This field is of list type, and the list can contain multiple authorization entries, in each authorization entry:

• The chain_id field indicates the chain on which this authorization delegation is effective.
• The address field represents the target address for delegation.
• The nonce field must match the nonce of the current authorized account.
• The y_parity, r, and s fields are the signed data of the authorization signed by the authorized account.

The authorization_list field in a transaction can contain multiple different authorized accounts authorized by (EOA), meaning that the transaction initiator can be different from the authorizer, allowing for gas fee payment on behalf of the authorizer.

implementation

When the authorizer signs the authorization data, they need to first RLP encode the chain_id, address, and nonce. Then, the encoded data is hashed with the MAGIC number using keccak256 to obtain the data to be signed. Finally, the authorizer's private key is used to sign the hashed data, resulting in the y_parity, r, and s values. Among them, MAGIC (0x05) is used as a domain separator, aimed at ensuring that the results of different types of signatures do not conflict.

It is important to note that when the chain_id authorized by the authorizer is 0, it means that the authorizer allows the authorization ( to be replayed on all EVM-compatible chains that support EIP-7702, provided that the nonce also matches exactly ).

After the authorizer signs the authorization data, the transaction initiator will aggregate it in the authorization_list field for signing and broadcast the transaction via RPC. Before the transaction is executed and included in a block, the Proposer will first perform a pre-check on the transaction, which includes a mandatory check on the to address to ensure that this transaction is not a contract creation transaction. In other words, when sending a transaction of type EIP-7702, the to address of the transaction cannot be empty.

At the same time, such transactions will require that the authorization_list field in the transaction must contain at least one authorization entry. If there are multiple authorization entries signed by the same authorizer, then only the last authorization entry will take effect.

Subsequently, during the transaction execution process, the node first increments the nonce value of the transaction initiator, and then performs the applyAuthorization operation on each authorization entry in the authorization_list. In the applyAuthorization operation, the node first checks the nonce of the authorizer, and then increments the nonce of the authorizer. This means that if the transaction initiator and the authorizer are the same user (EOA), the nonce value should be incremented by 1 when signing the authorization transaction.

When a node applies a certain authorization entry, if any errors are encountered, the authorization entry will be skipped, and the transaction will not fail. Other authorization entries will continue to be applied, thus ensuring that there is no risk of DoS in bulk authorization scenarios.

After the authorized application is completed, the code field of the authorizer's address will be set to 0xef0100 || address, where 0xef0100 is a fixed identifier and address is the target address for the delegation. Due to the restrictions of EIP-3541, users cannot deploy contract codes starting with 0xef in a conventional manner, which ensures that such identifiers can only be deployed by transactions of type SET_CODE_TX_TYPE (0x04).

After the authorization is completed, if the authorizer wants to remove the authorization, they only need to set the delegated target address to the 0 address.

The new transaction type introduced by EIP-7702 allows the authorizer (EOA) to execute code like a smart contract while also retaining the ability to initiate transactions. Compared to EIP-4337, this provides users with an experience that is closer to the native account abstraction (Native AA), significantly lowering the usage threshold for users.

Best Practices

Although EIP-7702 has injected new vitality into the Ethereum ecosystem, new application scenarios also bring new risks. The following are aspects that ecosystem participants need to be vigilant about during practice:

Private Key Storage

Even though an EOA can use built-in social recovery methods in smart contracts to address the issue of fund loss due to private key loss after delegation, it still cannot avoid the risk of EOA private key leakage. It is important to clarify that after executing the delegation, the EOA private key still holds the highest control over the account, and possessing the private key allows for the disposal of assets in the account at will. Even if users or wallet service providers completely delete the locally stored private key after completing the delegation for the EOA, they cannot completely eliminate the risk of private key leakage, especially in scenarios where there is a risk of supply chain attacks.

For users, when using the account after delegation, they should still prioritize the protection of their private keys and always remember: Not your keys, not your coins.

Multi-chain Replay

When users sign the delegation authorization, they can choose the chain on which the delegation can take effect by selecting the chainId. Of course, users can also choose to use chainId 0 for delegation, which allows the delegation to be replayed and take effect on multiple chains, making it convenient for users to delegate with a single signature on multiple chains. However, it is important to note that there may be different implementation codes for the same contract address on multiple chains.

For wallet service providers, when users delegate, they should check whether the effective delegation chain matches the currently connected network and remind users of the risks that may arise from signing a delegation with chainId of 0.

Users should also be aware that the contract code at the same contract address on different chains is not always the same, and they should first understand the target of the delegation.

could not be initialized

Most mainstream smart contract wallets currently adopt a proxy model. When deploying the wallet proxy, it will call the initialization function of the contract through DELEGateCALL, achieving an atomic operation for wallet initialization and proxy wallet deployment, thus avoiding the issue of being initialized in advance. However, when users delegate using EIP-7702, it only updates the code field of their address and cannot initialize by calling the delegated address. This means that EIP-7702 cannot call the initialization function for wallet initialization in the transaction of contract deployment like common ERC-1967 proxy contracts.

For developers, when combining EIP-7702 with existing EIP-4337 wallets, it is important to conduct permission checks during the wallet initialization process, for example, by using ecrecover to recover the signature address for permission checks, in order to avoid the risk of the wallet initialization operation being rushed.

( Storage Management

When users use the EIP-7702 delegation feature, they may need to re-delegate to different contract addresses due to changes in functional requirements, wallet upgrades, and other reasons. However, the storage structures of different contracts may vary; for example, the slot0 of different contracts may represent different types of data. In the case of re-delegation, this could lead to the new contract inadvertently reusing the old contract's data, resulting in account locking, capital loss, and other adverse consequences.

Users should handle the situation of re-delegation with caution.

For developers, during the development process, they should follow the Namespace Formula proposed by ERC-7201, allocating variables to designated independent storage locations to mitigate the risk of storage conflicts. In addition, ERC-7779 )draft### specifically provides a standard process for re-delegation for EIP-7702: including using ERC-7201 to prevent storage conflicts, verifying storage compatibility before re-delegating, and calling the old delegation interface to clean up old data in storage.

( Fake Recharge

After users make a delegation, the EOA can also be used as a smart contract. Therefore, centralized exchanges )CEX( may face a situation where smart contract deposits become widespread.

CEX should check the status of each deposit transaction through trace to prevent the risk of fake deposits in smart contracts.

) Account Conversion

After implementing EIP-7702 delegation, users' account types can freely switch between EOA and SC, allowing accounts to both initiate transactions and be called. This means that when an account calls itself and performs an external call, its msg.sender will also be tx.origin, which will break some security assumptions that limit project participation to EOA.

For contract developers, assuming that tx.origin is always an EOA will no longer be feasible. Similarly, using msg.sender == tx.origin check to defend against reentrancy attacks will also fail.

Developers should assume that future participants may all be smart contracts during the development process.

Contract Compatibility

The existing ERC-721 and ERC-777 tokens have Hook functionality when transferring to contracts, which means that the recipient must implement the corresponding callback function to successfully receive the tokens.

For developers, the target contract delegated by users should implement the corresponding callback functions to ensure compatibility with mainstream tokens.

( Fishing Check

After the implementation of EIP-7702 delegation, the assets in user accounts may be controlled by smart contracts. Once users delegate their accounts to a malicious contract, it will become easy for attackers to steal funds.

For wallet service providers, it is particularly important to quickly support EIP-7702 type transactions, and when users perform delegated signing, the target contract of the delegation should be prominently displayed to alleviate the risk of users potentially falling victim to phishing attacks.

In addition, conducting deeper automatic analysis of the target contracts of account delegation, such as open source checks, permission checks, etc., can better help users avoid such risks.

Summary

This article discusses the EIP-7702 proposal in the upcoming Pectra upgrade of Ethereum. EIP-7702 introduces new transaction types, giving EOAs programmability and composability, thereby blurring the lines between EOAs and contract accounts. As there is currently no battle-tested smart contract standard compatible with EIP-7702, various ecosystem participants such as users, wallet service providers, developers, and CEXs face numerous challenges and opportunities in practical applications. The best practice content outlined in this article cannot cover all potential risks, but it is still worth referencing and applying in actual operations.