The Ethereum ecosystem has witnessed a growing interest in enhancing the functionality of Externally Owned Accounts (EOAs) to enable more complex operations and interactions. While EOAs can initiate transactions, they currently lack the ability to perform stateful computations and maintain persistent storage, capabilities that are inherent to Contract Accounts.
Efforts to bridge this gap have led to proposals such as EIP-3074, which introduces new opcodes, AUTH and AUTHCALL, to allow EOAs to delegate control to smart contracts for specific operations . However, concerns have been raised regarding the forward-compatibility of EIP-3074 with future account abstraction efforts, particularly in light of the anticipated transition to a pure-smart-contract-wallet world.
EIP-7702 emerges as a novel proposal aimed at addressing these concerns while providing functionality similar to EIP-3074. This EIP introduces a new transaction type that empowers EOAs to temporarily set their code to a smart contract for the duration of a single transaction. By enabling EOAs to execute smart contract logic on a per-transaction basis, EIP-7702 opens up a myriad of possibilities for complex interactions and advanced use cases.
The primary motivation behind EIP-7702 lies in its potential to enable key functionalities such as batching, sponsorship, and privilege de-escalation, while ensuring forward-compatibility with future account abstraction efforts. By allowing EOAs to temporarily assume smart contract capabilities, EIP-7702 aims to bridge the gap between the current limitations of EOAs and the envisioned future of Ethereum account abstraction .
In the following sections, we will delve into the technical specifications of EIP-7702, exploring its implementation details and potential implications for the Ethereum ecosystem. We will also examine the advantages of EIP-7702 over alternative proposals and discuss the security considerations and challenges associated with its adoption.
EIP-7702 aims to address the growing demand for enhanced functionality in EOAs by enabling them to temporarily assume smart contract capabilities. The primary motivations behind this proposal are:
1. Enabling key use cases such as batching, sponsorship, and privilege de-escalation, which are currently limited or require complex workarounds.
2. Addressing the forward-compatibility concerns associated with EIP-3074, particularly in the context of future account abstraction efforts.
3. Facilitating a more seamless transition towards a pure-smart-contract-wallet world, where EOAs are eventually phased out in favor of smart contract accounts.
While EIP-3074 provides a solution for delegating control to smart contracts, it introduces new opcodes (AUTH and AUTHCALL) that may become obsolete in a future account abstraction landscape. EIP-7702 seeks to provide similar functionality without introducing new opcodes, thereby ensuring better compatibility with future Ethereum upgrades.
EIP-7702 introduces a new EIP-2718 transaction type with the TransactionType set to TX_TYPE(TBD). The TransactionPayload for this new transaction includes the following fields:
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s], ...], signature_y_parity, signature_r, signature_s])
The key feature of this new transaction type is the contract_code field, which allows EOAs to temporarily set their code to a smart contract for the duration of the transaction. The intrinsic cost of the transaction is inherited from EIP-2930, with additional costs for the contract_code field.
The execution process for EIP-7702 transactions involves the following steps:
1. For each [contract_code, y_parity, r, s] tuple, verify the signature and set the contract code of the signer's account to contract_code.
2. Execute the transaction as a regular transaction.
3. At the end of the transaction, reset the contract code of each signer's account back to empty.
This approach allows EOAs to temporarily assume smart contract capabilities without permanently altering their account state, enabling a wide range of complex interactions and use cases.
EIP-7702 offers several advantages over existing proposals and the current EOA functionality:
1. Compatibility with EIP-3074 use cases: EIP-7702 can be used to implement the same use cases as EIP-3074, such as batching, sponsorship, and privilege de-escalation. This can be achieved by replacing the AUTH and AUTHCALL opcodes with calls to the temporary contract code set by EIP-7702 transactions.
2. Forward-compatibility with future account abstraction: Unlike EIP-3074, which introduces new opcodes that may become obsolete in a future account abstraction landscape, EIP-7702 leverages existing transaction types and mechanisms. This approach ensures better compatibility with future Ethereum upgrades and reduces the risk of creating redundant or deprecated features.
3. Seamless integration with existing smart contract wallets: The temporary contract code set by EIP-7702 transactions can be based on existing smart contract wallet implementations, such as those used in ERC-4337. This allows for a more unified ecosystem and reduces the fragmentation of efforts between EOA-based solutions and smart contract wallets.
4. Simplified path to full account abstraction: EIP-7702 can be seen as an intermediate step towards full account abstraction, where all accounts are eventually replaced by smart contract accounts. By enabling EOAs to temporarily assume smart contract capabilities, EIP-7702 facilitates a gradual transition towards a pure-smart-contract-wallet world, reducing the need for abrupt and disruptive changes to the Ethereum ecosystem.
5. Reduced complexity and gas costs compared to EIP-3074: EIP-7702 achieves similar functionality to EIP-3074 without introducing new opcodes, which can lead to reduced complexity in the Ethereum protocol and potentially lower gas costs for users.
These are all discussed in the current discussion on EIP-7702 on the Ethereum Magicians Forum as of 05/07/24
Nonce management: There is an ongoing debate about whether the contract_code signature should sign over the account's nonce. Some argue that signing over the nonce would invalidate popular use cases of account abstraction, such as alternative signers and transaction delegation. Others propose signing over a user-picked maxNonce or delegating nonce control to an external nonceManager contract.
Signature invalidation: The contract_code signature could potentially be made invalid by introducing a "code assumption nonce" distinct from the transaction nonce. This would allow EOAs to revoke existing signatures over code and prevent the "perpetual signature" risk identified with EIP-3074.
Compatibility with existing contracts: There may be compatibility issues with existing contracts that use anti-patterns like <address>.transfer() or erc721.safeTransferFrom(). If the recipient has signed a contract_code that does not have a receive() or onERC721Received() function, these transfers might fail.
Standardization of contracts: If EIP-7702 is implemented, there may be a need for standardization around which contracts are used, similar to ERC-4337 entry points and EIP-3074 invokers, to ensure safety and verifiability.
Gas costs: The intrinsic cost of the new transaction type should account for the contract_code size and the cost of jump destination validation (EIP-3860).
Quantum computer concerns: The argument that quantum computers will eventually break ECDSA, necessitating a move away from EOAs, may not be sound. If ECDSA breaks, the entire Ethereum ecosystem would be at risk, and a plan for moving towards quantum-safe curves would be needed.