Vitalik Buterin recently proposed EIP-7702, which could be one of the most impactful changes in Ethereum’s history. This article will introduce the workings of this new proposal and everything needed to understand its implementation.

Firstly, the EIP-7702 proposal is surprisingly brief, which has left some people puzzled about its operation. To understand EIP-7702, we need to look at three other proposals mentioned within it:

1. EIP-4337

2. EIP-3074

3. EIP-5003

Let’s start with the common goal of these proposals: “account abstraction.” On Ethereum, EOAs (“ordinary” accounts) have significant drawbacks—they are highly risky and have very limited functionality. Account abstraction allows users to use smart contracts as accounts, adding more functionality and security to address these issues.

EIP-4337

EIP-4337 went live on the mainnet in March 2023. It allows 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 seen widespread adoption, primarily led by Polygon, with increased activity from Base in recent months.

The latest innovations related to EIP-4337 come from the Coinbase ecosystem and the Coinbase Smart Wallet. This wallet is based on biometric technology, providing an excellent user experience. Last weekend, I created another small demo at ETH Global Sydney to showcase this.

So, what issues does EIP-4337 have? Why is there another account abstraction proposal today? Because EOAs are still the most widely used account type by far.

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

Because it is not possible to “convert” a user’s EOA into a smart contract account, this strange interim solution exists. This is mainly due to the lack of native support in Web3 applications for connecting smart contract accounts. Nowadays, most people still use EOAs through plugin wallets like MetaMask.

EIP-3074

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

In fact, this proposal was introduced before EIP-4337, but it has not yet been merged into the mainnet. EIP-3074 attempts to empower EOAs by allowing them to delegate control of their EOAs to smart contracts.

The proposal outlines the addition of two new opcodes:

1. AUTH: An EOA can call AUTH to authorize a given smart contract to act on its behalf.
2. AUTHCALL: The 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 originate from the user’s EOA, rather than from a new contract that lacks 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 it?” After all, delegating to a malicious contract could result in all the crypto assets in the user’s wallet being drained.

The solution to this problem is for wallet service providers to restrict users from authorizing any contract indiscriminately. They might maintain a whitelist of smart contracts that users can delegate authority to, ensuring that any contracts outside this list are not presented to users for authorization.

A crucial point about delegation in EIP-3074 is that it’s not permanent. “Delegation from an EOA is invalidated by a single transaction, which increments the nonce, rendering any outstanding authorizations void.”

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

EIP-5003

We indeed don’t want to grant EOAs more power. After all, the goal of these proposals is to transition 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 introduces another opcode, “AUTHUSURP,” which deploys code to the EIP-3074 authorization address.

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

EIP-3074 is a temporary delegation to smart contracts, revocable.

EIP-5003 is a permanent migration from EOAs and a “conversion” from EOAs to smart contract accounts.

A major issue with EIP-3074 + EIP-5003 is its incompatibility with the current account abstraction scheme through EIP-4337. Some in the Ethereum community are concerned that we may “create 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. EIP-5003 is then seen as the next step for permanent migration.

EIP-7702 introduces a new transaction type that accepts both contract_code and signature fields. Upon transaction 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, this achieves temporary delegation of EOAs to smart contracts. However, EIP-7702 does not introduce new opcodes (which would require a hard fork) but rather defines functions to be called:

AUTH -> calls “verify”

AUTHCALL -> calls “execute”

Specifically, it:

Checks if your account’s contract code is empty.

If it’s empty, sets it to the provided contract code.

Executes the transaction according to how the provided smart contract handles transactions.

Restores the account’s contract code to empty.

“Contract code” is literal; it’s where the code of a smart contract is stored. Since an EOA itself is not a contract, this field is typically empty. However, the brilliance of EIP-7702 is that it temporarily populates this field with some smart contract code during transaction execution.

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

One of the best aspects of this proposal is its high compatibility with all the account abstraction work done so far for EIP-4337. “The contract code that users need to sign can actually be the existing EIP-4337 wallet code.”

Once this change takes effect, users’ existing EOAs 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 how all of us interact with Web3 applications.

Statement:

1. This article is reproduced from [panews], the original title “Exploring the EIP-7702 proposal: Vitalik’s ultimate prescription for the account abstraction problem?”, the copyright belongs to the original author [Foresight News], if you have any objection to the reprint, please contact Gate Learn Team, the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team, not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.