Involving 3 accounts, 3074, 4337, and 5003, this proposal aims to either abstract the past or completely change the way everyone interacts with Web3.

Author: Jarrod Watts

Translator: Frank, Foresight News

Vitalik Buterin has recently proposed EIP-7702, which may 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 implement it.

First, 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 goal of all these proposals, "account abstraction" – EOAs ("ordinary" 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 that 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 seen increased related activities in the past few months.

The latest innovation related to EIP-4337 comes from the Coinbase ecosystem and the Coinbase smart wallet, which is based on biometric technology and provides a great user experience. I made another small demo to demonstrate this at ETH Global Sydney last weekend.

So, what issues does EIP-4337 have? 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, as shown in the example code below:

Due to the lack of native support for connecting smart contract accounts in Web3 applications, most people still use EOAs through plugin wallets 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. EIP-3074 attempts to give EOAs more power, allowing them to delegate control of their EOA to smart contracts.

The proposal outlines the addition of two new opcodes:

• AUTH: EOAs can call AUTH to authorize a given smart contract to act on behalf of their EOA.
• AUTHCALL: Authorized smart contracts can use AUTHCALL to execute transactions for 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 the 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 of this list will not be shown to the user.

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

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

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," which deploys code at the EIP-3074 authorization address.

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

• EIP-3074 is a 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" through 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 proposes a new transaction type that accepts both contractcode and signature fields. When the transaction begins execution, it sets the contract code of the signer's account to contractcode. At the end of the transaction, it resets the code to empty.

Similar to EIP-3074, this implements temporary delegation of EOA 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"
• AUTHCALL -> calls "execute"

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 the provided smart contract's way of handling transactions;
• Restores the account contract code to empty.

The "contract code" is exactly what it sounds like, the code of the smart contract is stored in the "contract code." Since an EOA itself is not a contract, this field is usually empty. However, the cleverness 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. 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 things about this proposal is that it is highly compatible with all the account abstraction work done so far for EIP-4337, "the contract code that the user needs to sign can actually be existing EIP-4337 wallet code."

Once this change takes effect, 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 completely change the way all of us interact with Web3 applications.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。