Author: Kong
Editor: Sherry
Introduction
Ethereum is about to welcome the Pectra upgrade, which is undoubtedly a significant update, with many important Ethereum improvement proposals being introduced at this opportunity. Among them, EIP-7702 has made transformative changes to Ethereum external accounts (EOA). This proposal blurs the boundary between EOA and contract accounts (CA) and is a key step towards native account abstraction following EIP-4337, bringing a new interaction model to the Ethereum ecosystem.
Currently, Pectra has completed 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, exploring the potential opportunities and challenges it may bring, and providing practical operational guidelines for different participants.
Protocol Analysis
Overview
EIP-7702 introduces a brand new transaction type that allows EOA to specify a smart contract address and set code for it. This enables EOA to execute code like a smart contract while retaining the ability to initiate transactions. This feature endows EOA with programmability and composability, allowing users to implement functionalities such as social recovery, permission control, multi-signature management, zk verification, subscription payments, transaction sponsorship, and transaction batching within the EOA. Notably, EIP-7702 can be perfectly compatible with smart contract wallets implemented by EIP-4337, and their seamless integration 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 following data structure defined:
The authorization_list field is defined as:
In the new transaction 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:
The chain_id field indicates the chain on which this authorization delegation is effective.
The address field indicates the target address of the delegation.
The nonce field must match the current authorization account's nonce.
The y_parity, r, and s fields are the signed data of the authorization account.
The authorization_list field within a transaction can contain multiple authorization entries signed by different authorization accounts (EOA), meaning that the transaction initiator can be different from the authorizer, allowing for gas payment for the authorization operation.
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 together with the MAGIC number using keccak256 to obtain the data to be signed [1]. Finally, the authorizer's private key is used to sign the hashed data to obtain the y_parity, r, and s data. Among them, MAGIC (0x05) is used as a domain separator to ensure that the results of different types of signatures do not conflict.
It should be noted that when the chain_id authorized by the authorizer is 0, it means that the authorizer allows [2] the authorization to be replayed on all EVM-compatible chains that support EIP-7702 (provided that the nonce also matches).
When the authorizer completes signing 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 conduct a pre-check on the transaction [3], including 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 [4].
At the same time, such transactions will require the authorization_list field in the transaction to contain at least one authorization entry. If multiple authorization entries are signed by the same authorizer, only the last authorization entry will take effect.
Subsequently, during the transaction execution process, 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 incremented by 1 when signing the authorization transaction.
When a node applies a certain authorization entry, if any error occurs, that authorization entry will be skipped, and the transaction will not fail; other authorization entries will continue to be applied, ensuring that no DoS risk occurs in bulk 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 restrictions of EIP-3541, users cannot deploy contract codes starting with the 0xef byte in the usual way, ensuring that such identifiers can only be deployed by transactions of type SET_CODE_TX_TYPE (0x04).
After authorization is complete, if the authorizer wants to remove the authorization, they only need to set the target address of the delegation to the 0 address.
The new transaction type introduced by EIP-7702 allows the authorizer (EOA) to execute code like a smart contract while retaining the ability to initiate transactions. Compared to EIP-4337, this brings users a closer experience to native account abstraction (Native AA), significantly lowering the usage threshold for users.
Best Practices
Although EIP-7702 injects new vitality into the Ethereum ecosystem, new application scenarios will also bring new risks. The following are aspects that ecological participants need to be vigilant about during the practice process:
Private Key Storage
Even if EOA can leverage built-in social recovery methods in smart contracts to address fund loss issues due to private key loss, it still cannot avoid the risk of EOA private keys being leaked. It is important to clarify that after authorization, the EOA private key still holds the highest control over the account; possessing the private key allows one to freely dispose of the assets in the account. After users or wallet service providers complete the delegation for EOA, even if they completely delete the locally stored private key, 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 accounts after delegation, they should still prioritize protecting their private keys, always keep in mind: Not your keys, not your coins.
Multi-chain Replay
When users sign delegation authorizations, they can choose the chain on which the delegation can take effect through chainId. Of course, users can also choose to use chainId equal to 0 for delegation, allowing the delegation to be replayed across multiple chains, facilitating users to delegate across multiple chains with a single signature. However, it should be noted that within the same contract address across multiple chains, there may also be different implementation codes.
For wallet service providers, when users make delegations, they should check whether the effective chain of the delegation matches the currently connected network, and remind users of the risks related to signing delegations with chainId equal to 0.
Users should also be aware that the contract code at the same contract address on different chains is not always the same; they should first understand the target of the delegation.
Cannot Initialize
Currently, most mainstream smart contract wallets adopt a proxy model. When the wallet proxy is deployed, it initializes the contract's initialization function through DELEGATECALL, achieving atomic operations for wallet initialization and proxy wallet deployment, thus avoiding the problem of being initialized ahead of time. However, when users use EIP-7702 for delegation, it will only update the code field of their address and cannot initialize via calling the delegate address. This makes it impossible for EIP-7702 to call the initialization function during contract deployment like common ERC-1967 proxy contracts.
For developers, when combining and adapting EIP-7702 with existing EIP-4337 wallets, they should ensure to perform permission checks during the wallet initialization process (e.g., using ecrecover to recover the signing address for permission checks) to avoid the risk of the wallet initialization operation being preempted.
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, different contracts may have different storage structures (for example, different contracts’ slot0 slots may represent different types of data). In the case of re-delegation, this could lead to new contracts inadvertently reusing old contract data, which may result in account lockout, loss of funds, and other adverse consequences.
For users, caution should be exercised when handling re-delegation situations.
For developers, during the development process, they should follow the Namespace Formula proposed in ERC-7201, assigning 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 using ERC-7201 to prevent storage conflicts and verifying storage compatibility before re-delegation, as well as calling the interface of the old delegation to clean up old data in storage.
False Recharge
After users perform delegations, EOA can also be used like a smart contract, which may lead centralized exchanges (CEX) to face the generalization of smart contract deposits.
CEX should check the status of each recharge transaction through trace to prevent the risk of false recharge by smart contracts.
Account Conversion
After the implementation of EIP-7702 delegation, the user’s account type can freely switch between EOA and SC, which allows the account to initiate transactions and be called. This means that when the account calls itself and performs external calls, its msg.sender will also be tx.origin, which breaks some security assumptions that limit participation to EOA.
For contract developers, assuming that tx.origin is always EOA will no longer be feasible. Similarly, using msg.sender == tx.origin checks to defend against reentrancy attacks will also be invalid.
Developers should assume during the development process that future participants may all be smart contracts.
Contract Compatibility
Existing ERC-721 and ERC-777 tokens have Hook functionality when transferring to contracts, meaning that the recipient must implement the corresponding callback function to successfully receive tokens.
For developers, the target contract of user delegations should implement the corresponding callback functions to ensure compatibility with mainstream tokens.
Phishing Check
After the implementation of EIP-7702 delegation, the assets in the user's account may all be controlled by smart contracts. Once the user delegates the account to a malicious contract, it becomes easy for the attacker to steal funds.
For wallet service providers, it is especially important to support EIP-7702 type transactions as soon as possible. When users perform delegated signatures, the target contract of the delegation should be prominently displayed to users to mitigate the risk of phishing attacks.
In addition, conducting more in-depth automated analysis (open-source checks, permission checks, etc.) of the target contract for account delegation can better help users avoid such risks.
Summary
This article discusses the upcoming Pectra upgrade in Ethereum, focusing on the EIP-7702 proposal. EIP-7702 introduces a new transaction type that endows EOA with programmability and composability, blurring the lines between EOA and contract accounts. Since there is currently no battle-tested standard for smart contracts compatible with EIP-7702, various ecological participants such as users, wallet service providers, developers, and CEX face numerous challenges and opportunities in practical applications. The best practice contents described in this article cannot cover all potential risks, but are still worth referencing for practical operations.
Example
[Set EOA Account Code]
https://holesky.etherscan.io/tx/0x29252bf527155a29fc0df3a2eb7f5259564f5ee7a15792ba4e2ca59318080182
[Unset EOA Account Code]
https://holesky.etherscan.io/tx/0xd410d2d2a2ad19dc82a19435faa9c19279fa5b96985988daad5d40d1a8ee2269
Related Links
[1] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/types/tx_setcode.go#L109-L113
[2] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L562
[3] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L304
[4] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L388-L390
References
[EIP-7702]https://eips.ethereum.org/EIPS/eip-7702
[EIP-4844]https://eips.ethereum.org/EIPS/eip-4844
[Go-ethereum]https://github.com/ethereum/go-ethereum/tree/7fed9584b5426be5db6d7b0198acdec6515d9c81
[EIP-3541]https://eips.ethereum.org/EIPS/eip-3541#backwards-compatibility
[Cobo: EIP-7702 Practical Guide]
https://mp.weixin.qq.com/s/ojh9uLw-sJNArQe-U73lHQ
[Viem]https://viem.sh/experimental/eip7702/signAuthorization
[ERC-7210]https://eips.ethereum.org/EIPS/eip-7201
[ERC-7779]https://eips.ethereum.org/EIPS/eip-7779