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

Introduction

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

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

Protocol Analysis

Overview

EIP-7702 introduces a new type of transaction that allows an Externally Owned Account (EOA) to specify a smart contract address to set its code. This enables an EOA to execute code like a smart contract while retaining the ability to initiate transactions. This feature endows EOAs with programmability and composability, allowing users to implement functions such as social recovery, permission control, multi-signature management, zk verification, subscription payments, transaction sponsorship, and transaction batching within the EOA. It is worth noting that EIP-7702 is perfectly compatible with the smart contract wallets implemented by EIP-4337, and the seamless integration of the two greatly simplifies the development and application process of new features.

EIP-7702 introduces a transaction type SET_CODE_TX_TYPE (0x04), with the following data structure definition:

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, except for the authorization_list field, the rest follows the same semantics as EIP-4844. This field is of list type and can contain multiple authorization entries, each authorization entry includes:

• chain_id indicates the chain on which this authorization delegation is effective.
• address refers to the target address for delegation
• nonce must match the current authorized account's nonce
• y_parity, r, s are the signature data signed by the authorized account.

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

implementation

When the authorizer signs the authorization data, they need to first perform RLP encoding on the chain_id, address, and nonce. Then, the encoded data is hashed using keccak256 together with the MAGIC number to obtain the data to be signed. Finally, the authorizer uses their private key to sign the hashed data, obtaining y_parity, r, and s data. MAGIC (0x05) is used as a domain delimiter to ensure that the results of different types of signatures do not conflict.

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

After the authorizer signs the authorization data, the transaction initiator will aggregate it in the authorization_list field for signing and broadcast the transaction through RPC. Before the transaction is executed in the 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, meaning that when sending a transaction of type EIP-7702, the to address of the transaction cannot be empty.

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

During the execution of the transaction, the node will first increase the nonce value of the transaction initiator, and then perform the applyAuthorization operation on each authorization entry in the authorization_list. In the applyAuthorization operation, the node will first check the nonce of the authorizer and then increase 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 increased by 1 when signing the authorization transaction.

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

After the authorization 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 of the delegation. Due to the limitations of EIP-3541, users cannot deploy contract codes starting with the 0xef byte in the usual way, 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, just 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 still retaining the ability to initiate transactions. Compared to EIP-4337, this provides users with a much closer experience to 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 will also bring new risks. Here are some aspects that ecosystem participants need to be cautious about in practice:

Private Key Storage

Even though the EOA can use built-in social recovery and other means in smart contracts to solve the problem 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 has the highest control over the account, and holding the private key allows one to freely dispose of the assets in the account. Users or wallet service providers cannot completely eliminate the risk of private key leakage even after fully deleting the locally stored private key for the EOA after delegation, especially in scenarios where there is a risk of supply chain attacks.

For users, when using accounts after delegation, the protection of private keys should still be the top priority, 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 on multiple chains with a single signature. However, it should be noted that the same contract address on multiple chains may have different implementation codes.

For wallet service providers, when users make a delegation, 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 same contract address on different chains does not always have the same contract code, and they should understand the target of the delegation clearly first.

Unable to initialize

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 problem of being initialized in advance. However, when users delegate using EIP-7702, only the code field of their address will be updated, and they cannot initialize by calling the delegate address. This means that EIP-7702 cannot call the initialization function in the contract deployment transaction for wallet initialization like common ERC-1967 proxy contracts.

For developers, when integrating EIP-7702 with existing EIP-4337 wallets, it is important to perform permission checks during the wallet initialization process. For example, use ecrecover to recover the signed address for permission checks, in order to avoid the risk of the wallet initialization 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, there is a possibility that the new contract inadvertently reuses the data of the old contract, which may lead to adverse consequences such as account lockout and financial losses.

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

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

( Fake Recharge

After users delegate, EOA can also be used as a smart contract. Therefore, centralized exchange )CEX( may face the situation of the generalization of smart contract deposits.

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

) Account Conversion

After implementing EIP-7702 delegation, users can freely switch their account types between EOA and SC, allowing the account 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 only EOA participates in projects.

For contract developers, assuming that tx.origin is always an EOA will no longer be feasible. Similarly, using the check msg.sender == tx.origin 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 a Hook function 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 entrusted by users should implement the corresponding callback functions to ensure compatibility with mainstream tokens.

( Fishing Check

After implementing EIP-7702 delegation, 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 users to mitigate the risk of phishing attacks that users may suffer.

In addition, conducting a more in-depth automatic analysis of the target contracts for account delegation, such as open source checks and permission checks, 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, enabling EOA to have programmability and composability, blurring the lines between EOA and contract accounts. As there is currently no battle-tested standard for EIP-7702 compatible smart contracts, different ecosystem participants such as users, wallet service providers, developers, and CEXs face numerous challenges and opportunities in practical applications. The best practices outlined in this article cannot cover all potential risks, but are still worth considering and applying in actual operations.