Exploring EIP-7702 Proposal: Vitalik's Ultimate Solution to the Account Abstraction Challenge?

Author: Jarrod Watts

Translation: Frank, Foresight News

Vitalik Buterin has recently proposed EIP-7702, which may be one of the most significant 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 has left some people confused about how it actually works. To understand 7702, we first need to understand three other proposals mentioned in it:

• EIP-4337
• EIP-3074
• EIP-5003

Let's start with the common goal of all these proposals, "account abstraction" - EOAs ("Externally Owned Accounts") on Ethereum are bad, they are risky and have very limited functionality. Account abstraction allows users to use smart contracts as accounts to add more functionality and security to address this issue.

EIP-4337

EIP-4337 went live on the mainnet in March 2023, allowing smart contracts to be written like accounts so they can verify and execute transactions, improving many user experiences (UX).

Since its release, EIP-4337 has been widely adopted, mainly led by Polygon, and Base has also seen increased activity in 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 offers a great user experience. I made another small demo at ETH Global Sydney last weekend to showcase this.

So, what issues exist with EIP-4337? Why another account abstraction proposal today? Because EOAs are still the most widely used account type to date.

In addition, most smart contract accounts of EIP-4337 are controlled by a single EOA signer. Here is an example code:

Due to the inability to "convert" a user's EOA into a smart contract account, there is this strange intermediate step solution - mainly because Web3 applications lack native support for connecting to smart contract accounts, so most people still use EOAs through browser extensions like MetaMask.

EIP-3074

This leads us to our next proposal: EIP-3074.

In fact, this proposal was made before EIP-4337, but it has not been merged into the mainnet yet. EIP-3074 aims to give EOAs more power, allowing them to delegate control of their EOA to smart contracts.

The proposal outlines the following, adding two new opcodes:

• AUTH: EOAs can call AUTH to authorize a given smart contract to act on behalf of their EOA;
• AUTHCALL: An authorized smart contract can use AUTHCALL to execute transactions on behalf of the EOA;

This achieves many of the same use cases as EIP-4337 without requiring each user to deploy a new smart contract. A key difference is that transactions come from the user's EOA, not a new contract with no user account history, ETH, NFTs, tokens, etc.

A common reaction to EIP-3074 is "What if someone deploys a malicious contract and users delegate to them?" After all, delegating to a malicious contract could result in all of the user's crypto assets being drained from their wallet.

The solution to this problem is that wallet service providers may not even allow users to authorize any contract. They may maintain a whitelist of smart contracts that users can delegate authorization to, and any contract outside this list will not be shown to the user.

A key point of delegation in EIP-3074 is that delegation is not permanent, "a single transaction from an EOA will increment the nonce, rendering any outstanding authorizations invalid."

Essentially, after a user makes a new transaction, the delegation will no longer be valid.

EIP-5003

We also don't really 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 add functionality to EOAs?

This nicely leads us to our next proposal: EIP-5003. EIP-5003 adds another opcode "AUTHUSURP," deploying code at the EIP-3074 authorization address.

The difference between EIP-3074 and EIP-5003 is:

• EIP-3074 is temporary delegation to smart contracts, revocable;
• EIP-5003 is a permanent migration from EOA and "conversion" from EOA to a smart contract account;

A major issue with EIP-3074 + EIP-5003 is that it is not very compatible with the current account abstraction scheme through EIP-4337, so some in the Ethereum community are concerned that we will be creating "two separate code ecosystems" with these two types of account abstractions.

EIP-7702

This brings us to Vitalik Buterin's proposal today: EIP-7702 - he proposes to modify EIP-3074 to make it more concise and compatible with EIP-4337, so we don't end up with two separate account abstraction ecosystems, and views EIP-5003 as the next step for permanent migration.

EIP-7702 introduces a new transaction type that accepts both contract_code and signature fields. When the transaction begins execution, it sets the contract code of the signer's account to contract_code. At the end of the transaction, it resets the code to empty.

Similar to EIP-3074, it implements temporary delegation of EOA to smart contracts. However, EIP-7702 does not introduce new opcodes (which would require a hard fork), but defines functions to be called:

• AUTH -> calls "verify" for validation
• AUTHCALL -> calls "execute" for execution

Specifically, it:

• Checks if your account contract code is empty;
• If it is empty, sets it to the provided contract code;
• Executes the transaction based on how the provided smart contract handles transactions;
• Restores the account contract code to empty;

"Contract code" is literal, the code of the smart contract is stored in "contract code." Since an EOA itself is not a contract, this field is usually empty. However, the clever part of EIP-7702 is that it temporarily populates some smart contract code into this field during transaction execution.

This is a way to provide new behavior (in code form) for your EOA to execute this specific transaction, with the next step being to make it a permanent behavioral change by simply choosing "not to reset the code to empty after the transaction ends."

<s

One of the best aspects of this proposal is that it is highly compatible with all the account abstractions built for EIP-4337 so far, </s

"The contract code that users need to sign can actually be the existing EIP-4337 wallet code."

Once this change takes effect, users' existing EOA can execute any smart contract code. Through additional EIPs, EOAs can also be permanently upgraded to run specific code.

In time, this could fundamentally change the way all of us interact with Web3 applications.