EIP-7702 and the existing EIP-4337 account abstraction work are highly compatible. Once this proposal is implemented, it could fundamentally change the way people interact with Web3 applications. This article, sourced from Jarrod Watts, compiled, translated, and written by Foresight News, will introduce the working principles of this new proposal and everything you need to know to implement it.
First, the new EIP-7702 proposal is surprisingly short, which has confused some people about how it actually works. To understand 7702, we first need to understand the three other proposals mentioned in it: EIP-4337, EIP-3074, and EIP-5003.
Let’s start with the common goal of all these proposals: account abstraction. The EOA (Externally Owned Account) on Ethereum is not ideal. They are risky and have limited functionality. Account abstraction allows users to use smart contracts as accounts to add more functionality and security to address this problem.
EIP-4337 was launched on the mainnet in March 2023. It allows writing smart contracts like accounts so that they can verify and execute transactions, improving user experience (UX). EIP-4337 has been widely adopted, primarily led by Polygon, and there has been an increase in related activities by Base in recent months. The latest innovation related to EIP-4337 comes from Coinbase’s ecosystem and Coinbase Smart Wallet, which uses biometric technology and provides a great user experience.
However, EIP-4337 has some issues. EOAs are still the most widely used account type to date. Additionally, most smart contract accounts in EIP-4337 are controlled by a single EOA signer, which presents a strange intermediate step solution due to the lack of native support for connected smart contract accounts in Web3 applications. Currently, most people still use EOAs through plug-in wallets like MetaMask.
This leads us to the next proposal, EIP-3074. This proposal, which was actually introduced before EIP-4337 but has not been merged into the mainnet, aims to give EOAs more power by allowing them to delegate control of their EOAs to smart contracts. The proposal outlines two new opcodes: AUTH and AUTHCALL. AUTH allows an EOA to authorize a specific smart contract to execute operations on its behalf, while AUTHCALL enables an authorized smart contract to execute transactions for the EOA.
A common concern with EIP-3074 is what happens if someone deploys a malicious contract and the user delegates their EOA to it. Delegating to a malicious contract could result in the user’s wallet being drained of all their crypto assets. One solution to this problem is for wallet service providers to not allow users to authorize any contract. They may maintain a whitelist of smart contracts that users can delegate authorization to and not display any contracts outside of this list to users.
One key point of delegation in EIP-3074 is that it is not permanent. “A single transaction from an EOA causes a nonce increment, rendering any outstanding delegations invalid.” Essentially, once users make a new transaction, the delegation will no longer be valid.
However, the goal of these proposals is to move users from EOAs to smart contract accounts, so adding more functionality to EOAs raises the question of why we are enhancing EOAs when the goal is to transition users to smart contract accounts. This leads us to the next proposal, EIP-5003. EIP-5003 adds another opcode, “AUTHUSURP,” which deploys code to the EIP-3074 authorization address.
The difference between EIP-3074 and EIP-5003 is that EIP-3074 provides temporary delegation to smart contracts that can be revoked, while EIP-5003 involves a permanent migration from EOAs to smart contract accounts. A concern with EIP-3074 and EIP-5003 is that they are not very compatible with the current account abstraction scheme built through EIP-4337, leading some in the Ethereum community to worry about “creating two separate code ecosystems” for these two types of account abstractions.
This brings us to Vitalik Buterin’s latest proposal, EIP-7702. He suggests modifying EIP-3074 to make it more concise and compatible with EIP-4337. This way, we won’t end up with two separate account abstraction ecosystems, and EIP-5003 will be considered the next step for permanent migration. EIP-7702 introduces a new transaction type that accepts both contract_code and signature fields. It sets the contract code of the signer’s account to the contract_code when the transaction begins execution. It then resets the code to empty when the transaction ends.
Similar to EIP-3074, this achieves temporary delegation of EOAs to smart contracts. However, EIP-7702 does not introduce new opcodes (which would require a hard fork) but defines the functions to be called: AUTH calls “verify,” and AUTHCALL calls “execute.”
Specifically, it checks if the account contract code is empty, sets it to the provided contract code if it is empty, executes the transaction based on the provided smart contract’s handling, and resets the account contract code to empty. The “contract code” is the literal meaning, where the code of the smart contract is stored. Since EOAs themselves are not contracts, this field is usually empty. However, the clever part of EIP-7702 is that it temporarily populates some smart contract code into that field during the transaction execution.
This is a way to provide new behavior (in code form) for your EOA to execute a specific transaction. The next step is to make it a permanent behavioral change by choosing not to set the code to empty after the transaction ends.
One of the best things about this proposal is that it is highly compatible with all the account abstraction work built through EIP-4337. “The contract code users need to sign can actually be existing EIP-4337 wallet code.”
Once this change is implemented, users’ existing EOAs will be able to execute any smart contract code. Through additional EIPs, EOAs can also be permanently upgraded to execute specific code.
In time, this could completely change the way we all interact with Web3 applications.