Original author: Jarrod Watts
Original translation: Frank, Foresight News
Vitalik Buterin has recently proposed EIP-7702, which may be one of the most influential changes in Ethereum’s history. This article will introduce the working principle of this new proposal and everything you need to know to implement it.
First of all, the new EIP-7702 proposal is surprisingly short, which confuses some people and makes them wonder how it works. In order to understand 7702, we must first understand the other three proposals mentioned in it:
EIP-4337
EIP-3074
EIP-5003
Let’s start with the common goal of all these proposals: account abstraction - EOAs (“ordinary” accounts) on Ethereum are terrible, they are very risky and have very limited functionality, and account abstraction allows users to use smart contracts as accounts to add more functionality and security to solve this problem.
EIP-4337
EIP-4337, which went live on the mainnet in March 2023, allows smart contracts to be written like accounts so that they can verify and execute transactions, which improves many user experiences (UX).
Since its release, EIP-4337 has seen widespread adoption, led primarily by Polygon, while Base has also seen increased activity over the past few months.
The latest innovation related to EIP-4337 comes from the Coinbase ecosystem and Coinbase Smart Wallet, which is based on biometric technology and has a great user experience. I made another small demo at ETH Global Sydney last weekend to demonstrate this.
So what’s the problem with EIP-4337? Why is there another Account Abstraction proposal today? Because EOAs are still by far the most widely used account type.
In addition, most EIP-4337 smart contract accounts are controlled by a single EOA signatory. Here is the sample code:
Because it is not possible to convert a users EOA to a smart contract account, there is this strange middle-step solution - mainly due to the lack of native support for connecting smart contract accounts in Web3 applications. Today, most people still use EOA through plug-in wallets such as MetaMask.
EIP-3074
This brings us to our next proposal: EIP-3074.
In fact, this proposal was made before EIP-4337, but it has not yet been merged to the mainnet. EIP-3074 seeks to give EOAs more power by allowing them to delegate control of their EOAs to smart contracts.
The proposal outlines the following, adding two new opcodes:
AUTH: An EOA can call AUTH to authorize a given smart contract to perform operations on behalf of its EOA;
AUTHCALL: Authorized smart contracts can use AUTHCALL to execute transactions for EOA;
This enables many of the same use cases as EIP-4337 without requiring each user to deploy a new smart contract. A key difference is that the transaction comes from the user’s EOA, rather than a new contract that does not have any of the user’s account history, ETH, NFTs, tokens, etc.
A common reaction to EIP-3074 is “What if someone creates a malicious contract and the user delegates to them?” After all, delegating to a malicious contract may result in all the crypto assets in the user’s wallet being drained away.
A solution to this problem is for the wallet service provider to not even allow the user to authorize any contract, they might keep a whitelist of smart contracts that the user can delegate authorization to, and any contracts outside of this list will not be displayed to the user.
A key point of EIP-3074 delegation is that delegation is not permanent. “A single transaction of EOA will cause the nonce to increase, thereby invalidating the unfinished authorization.”
Essentially, after the user makes a new transaction, the delegation will no longer be valid.
EIP-5003
We also really don’t want to give EOAs more power. After all, the goal of these proposals is to move users from EOAs to smart contract accounts, so why would we add functionality to EOAs?
This leads nicely to our next proposal: EIP-5003. EIP-5003 adds another opcode, “AUTHUSURP”, which deploys the code at the EIP-3074 authorization address.
The difference between EIP-3074 and EIP-5003 is:
EIP-3074 is a temporary delegation to a smart contract, which is revocable;
EIP-5003 is a permanent migration from EOA and a conversion from EOA to a smart contract account;
A big problem with EIP-3074 + EIP-5003 is that it is not very compatible with the current account abstraction scheme via EIP-4337, so some people in the Ethereum community are worried that we will create two separate code ecosystems with these two types of account abstraction.
EIP-7702
This brings us to Vitalik Buterin’s proposal today: EIP-7702 — he proposes to amend EIP-3074 to make it leaner and more compatible with EIP-4337 so that we don’t end up with two separate account abstraction ecosystems, and also considers EIP-5003 as the next step towards permanent migration.
EIP-7702 proposes a new transaction type that accepts both contract_code and signature fields. At the beginning of the transaction, it sets the contract code of the signer account to contract_code. At the end of the transaction, it sets the code back to empty.
This is the same as EIP-3074, which implements the temporary delegation function of EOA to smart contracts. However, EIP-7702 does not introduce new opcodes (which requires a hard fork), but defines the function to be called:
AUTH -> call verify
AUTHCALL -> Call execute
Specifically, it:
Check if your account contract code is empty;
If empty, it is set to the provided contract code;
Execute transactions according to the provided smart contract’s way of processing transactions;
Restore the account contract code setting to empty;
Contract code is literally what it means. The code of the smart contract is stored in Contract code. Since the EOA itself is not a contract, this field is usually empty. However, the clever thing about EIP-7702 is that it temporarily fills some smart contract code into this field during transaction execution.
This is a way to give your EOA a new behavior (in the form of code) for this specific transaction, the next step is to make it a permanent behavior change, just select Do not set code to null after transaction ends.
One of the best things about this proposal is that it is highly compatible with all the account abstraction work built so far for EIP-4337, and the contract code that users need to sign can actually be existing EIP-4337 wallet code.
Once this change takes effect, users existing EOAs will be able to execute any smart contract code. Through additional EIPs, EOAs can also be permanently upgraded to run specific code.
Over time, this could revolutionize the way we all interact with Web3 applications.
