Author: Cobo Global
The upcoming Pectra upgrade on the Ethereum mainnet is a major update that introduces multiple Ethereum Improvement Proposals (EIPs) at once. Among them, EIP-7702 has implemented a significant transformation of Externally Owned Accounts (EOAs), blurring the boundaries between EOAs and Contract Accounts (CAs) and providing new capabilities that will have a significant impact on regular users, various infrastructure providers, and developers.
The Pectra upgrade has recently been completed on the testnet and is expected to be launched on the mainnet soon. This article will delve into the implementation of EIP-7702, showcase the opportunities and risks it may bring, and provide a reference 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 summarizes the core elements of the proposal: providing a new transaction type that allows setting contract code for an EOA.
Specifically, this proposal introduces a new transaction type called SET_CODE_TX_TYPE (0x04), with the following data structure:
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])
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Compared to the commonly used 0x02 transaction type, the main change is the addition of the authorization_list field. Each element in the authorization_list represents an authorization for address delegation. Among them:
- chain_id is the chain ID for the authorization to take effect, used for replay protection
- nonce is the nonce of the authorizing address, consistent with the normal transaction nonce, also used for replay protection
- address is the proxy address specified for the address delegation
- y_parity, r, s are the signature data, from which the authority address, i.e., the EOA address that initiated the authorization, can be obtained via ecrecover
Each transaction can contain multiple authorizations as mentioned above. It's worth noting that the above authorizations have independent signatures, different from the signature of the main transaction, so the gas for the authorization can be paid by the wallet service provider or App developer on behalf of the authority.
After the transaction is included in a block, the code field of the authority address will be set to the Delegation Designation (DD) of the proxy address. The DD format is as follows:
0xef0100 || address
Where 0xef0100 is the fixed prefix, and address is the target proxy address. It's worth noting that according to EIP-3541, users cannot deploy contracts with 0xef prefix through regular contract deployment methods (transactions with empty "to" field, create/create2 instructions). Therefore, the above delegation can only be initiated by an EOA through the 0x04 transaction.
After the delegation is completed, all contract calls to the authority address will use the code of the address specified in the DD, while using the authority's own storage. The user experience is very similar to the ERC-1167 proxy contract.
In summary, EIP-7702 allows EOAs to have the effect of a Proxy contract while retaining the ability to initiate transactions. Users can set, modify, or remove the Proxy's Implementation contract through the SET_CODE_TX_TYPE (0x04) transaction.
For other technical details about EIP-7702, please refer to the original proposal.
Impacts and Opportunities of EIP-7702
EIP-7702 is a significant change that has a major impact on various participants in the blockchain industry and also provides many new opportunities.
Contract Wallet Service Providers
From the title and implementation mechanism of the proposal, it can be seen that EIP-7702 does not specifically provide higher-level capabilities related to Account Abstraction (AA), such as gas abstraction, nonce abstraction, or signature abstraction. It only provides the basic capability to transform an EOA into a Proxy contract. Therefore, this proposal does not conflict with the existing contract wallet infrastructure (such as Safe, ERC-4337, etc.). On the contrary, EIP-7702 can be seamlessly integrated with existing contract wallets. It allows users' EOAs to be transformed into Safe wallets, ERC-4337 wallets, and thereby integrate the functions provided by contracts, such as multi-signature, gas payment, batch transactions, and passkey signing. If contract wallet providers can quickly and smoothly integrate EIP-7702, they can effectively expand their user base and improve the user experience.
DApp Developers
Since EIP-7702 has improved the user experience of AA wallets, DApp developers can consider integrating AA wallets more widely to provide users with a more convenient and secure interaction experience with DApps. For example, they can utilize the batch transaction capability of contract wallets to complete multiple DeFi operations in a single transaction.
DApps can also consider developing customized Delegation contracts based on project characteristics to provide users with specialized and complex contract interaction functions.
Asset Custodians
For exchanges and fund custodians, they usually need to manage a large number of addresses as user deposit addresses and periodically perform fund aggregation. In the traditional fund aggregation model, using EOA addresses as deposit addresses requires depositing a certain amount of gas to the deposit address, and then the deposit address needs to transfer the funds to the withdrawal address. The entire fund process involves a large number of transaction submissions, a long flow, and the need to pay high gas fees. In the past, there have been cases where institutions' fund aggregation has caused a surge in on-chain transaction fees and transaction congestion.
The emergence of EIP-7702 can seamlessly transform EOA addresses into contract wallets. Due to the gas payment mechanism of EIP-7702, there is no longer a need for gas top-up transactions. At the same time, the programmability of contract wallets can be utilized to package multiple aggregation transfers into a single transaction, reducing the number of transactions and saving gas consumption. This ultimately improves the efficiency of aggregation and reduces the cost of aggregation.
Potential Risks of EIP-7702
EIP-7702 brings new account functions, but also introduces potential security risks that wallet service providers, contract developers, and users need to be vigilant about.
Wallet Service Providers
Since EIP-7702 introduces a new transaction type, SET_CODE_TX_TYPE (0x04), which is also directly related to regular users, software wallet providers like Metamask, Rabby, and various hardware wallet services need to update their software to adapt to the new transaction type.
As EIP-7702 authorization may involve the takeover of the entire account, wallet service providers need to provide users with sufficient warnings in the UI, with the alert level comparable to or even higher than Token Approve and Permit.
If the integration of the new transaction type and user interaction are not strictly security-checked, it may lead to users being subjected to phishing attacks.
Regular Users
Regular users also need to pay attention to the new Ethereum transaction types and be aware of updates from various software wallets and hardware wallets. They need to effectively identify and pay enough attention to the new special transaction types.
For this transaction type, it is necessary to carefully verify the target contract of the Delegation. With the necessary technical background, it is best to audit the contract source code to avoid introducing security risks. Regular users need to pay attention to whether the authorized contract is open-source and provides a third-party trusted audit report.
Compared to previous transaction types, the new transaction type is more difficult to audit and has stronger control over the wallet. It can be foreseen that there will be phishing attacks using this transaction type in the future. Regular users must actively acquire relevant knowledge and enhance their security awareness.
Contract Developers
For contract developers, EIP-7702 provides a new perspective. As there are no mature open-source library components or development standards for Delegation contracts yet, developers may need to implement their own Delegation contracts in the early stages of the upgrade. It is recommended that developers conduct sufficient research to ensure the avoidance of security risks introduced by the new features.
After the analysis of Cobo's security team, the aspects that contract developers need to pay attention to in the contract security of EIP-7702 include but are not limited to the following:
1. The race condition problem in the initialization of the Delegation contract
EIP-7702 only provides the ability to set the code, and does not provide the ability to initialize the contract. Compared to the familiar Proxy mechanism, EIP-7702 is equivalent to providing the ability to update the implementation, but not the ability to call the initialize function.
Taking the official implementation of the ERC-4337 wallet as an example, its initialize method has no permission check. The first user to call this method can obtain the ownership of the wallet.
contract SimpleAccount {
function initialize(address anOwner) public virtual initializer {
_initialize(anOwner);
}
}
Other mainstream contract wallets like Safe also have similar problems. In the past implementation of contract wallets, the deployment of the contract and the initialization were often packaged in a single transaction to achieve atomic operation, thereby avoiding the occurrence of race conditions.
However, in the scenario of EIP-7702, the authorized signature exists separately in the authorization_list, and the front-running bot can monitor the authorization transaction in the memory pool and send the authorization transaction first, while calling the initialization function to seize the permission of the contract wallet. If the EOA wallet already has certain crypto assets, the assets may be directly transferred during the front-running process, causing financial losses to the user. We can boldly speculate that in the initial period after the upgrade is completed, there will definitely be attacks based on the initialization front-running of EIP-7702 on the chain.
After research, the vast majority of the original Proxy model code implementation cannot be safely initialized in the EIP-7702 scenario. Developers should adapt the original code to EIP-7702 before opening it to users. Users should also be careful not to authorize various old version contracts to ensure fund security.
For developers, the adaptation of EIP-7702 is mainly to perform permission verification on the initialization method. The typical verification code may be 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 the holder of the legal signature can call the initialization method. Considering the gas payment scenario, the latter may be more commonly used.
2. Storage structure conflict problem of Delegation contract
In the EIP-7702 scenario, EOA may frequently update Delegation, which is equivalent to Proxy upgrade. Since each Delegation contract may be provided by different wallet vendors and DApp developers, the implementation may be different from each other. Unlike the contract upgrade scenario under a single developer, it is easy to ensure the compatibility of each version.
The variable storage structure of different Delegation contracts is most likely completely different. If the contracts share the same Storage slot, it may read incorrect data or write unexpected data, causing contract function anomalies. And once the data is wrong, the repair requires very high technical capabilities, and ordinary users are difficult to handle.
It is recommended that developers use the Storage management mode of ERC-7201, using the Namespace method to use independent Storage space, and avoid using the default slot starting from 0x0.
3. Delegation permission management problem
EIP-7702 is very similar to Proxy contract, but in the EIP-7702 scenario, the management of the implementation contract is done at the Ethereum protocol level. It is equivalent to the Proxy having a fixed and immutable owner. Therefore, the EOA account can update the contract at any time, modify any data in the Storage space, and perform any operation.
Developers should be aware of this difference and should not trust the data in the EOA Storage space when developing DApps, especially for developers who are used to the Solana, SUI user model. Ordinary users also need to pay attention to this issue when using it.
For example, after delegating the EOA to a multi-signature wallet, the highest level of authority is still the EOA private key itself.
4. The problem of new EOA breaking the original security assumptions
In the old version contracts, some security assumptions that depend on the initiator being an EOA may be broken. Typically, the existing specifications often use the following code to check whether the caller is an EOA
require(msg.sender == tx.origin, "Only EOA")
Further, it may be assumed that the EOA does not have the ability to call contracts and does not perform batch call restrictions or re-entry check logic.
In the EIP-7702 scenario, the boundary between EOA and CA begins to blur, and the EOA also has the ability to execute code. Even if the above check is passed, transferring ETH to that EOA may still trigger the fallback of the EOA proxy contract, causing a re-entry problem. Or some methods that restrict each transaction to only be called once (such as some token mining distribution methods, NFT mint methods, etc.), in the new scenario, can be implemented through EOA Proxy code to achieve batch calls, realizing the developer's unexpected arbitrage attacks.
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
