VITALIK JUST PROPOSED ONE OF THE MOST IMPACTFUL CHANGES TO ETHEREUM

Vitalik just proposed EIP-7702, and it's set to be one of the most impactful changes to Ethereum ever. Here’s everything you need to know about how it works and the journey to this point:

The new EIP-7702 proposal is surprisingly short, which can confuse some people about its implementation. To understand it, we need to look at three other proposals it references: EIP-4337, EIP-3074, and EIP-5003.

First, let’s talk about the goal of all these proposals. Externally Owned Accounts (EOAs) on Ethereum are considered risky and have limited capabilities. Account abstraction allows users to employ a smart contract as their account, enhancing features and safety.

EIP-4337 went live on the mainnet in March 2023. It enabled smart contracts to function like accounts, capable of validating and executing transactions (UserOps). Since its release, EIP-4337 has seen solid adoption, especially on Polygon, with Base gaining traction recently.

The latest innovation leveraging EIP-4337 comes from the Coinbase ecosystem with their Coinbase smart wallet. With support for biometrics, the user experience is outstanding.

So, what’s wrong with EIP-4337, and why do we need another account abstraction proposal today? The primary issue is that EOAs are still the predominant type of account. Additionally, most EIP-4337 smart contract accounts are still controlled by a single EOA signer.

Here are the key issues:

A) There's no way to "convert" an EOA to a smart contract account, resulting in a convoluted interim solution. B) There’s a lack of native support by web3 apps to connect smart contract accounts.

This brings us to the next proposal: EIP-3074. Interestingly, this proposal was made before EIP-4337 but has yet to be merged into the mainnet. EIP-3074 aims to enhance EOAs by allowing them to delegate control to a smart contract.

The proposal outlines the addition of two new opcodes:

1. AUTH: EOAs can call AUTH to authorize a specified smart contract to perform actions on their behalf.
2. AUTHCALL: An authorized smart contract can use AUTHCALL to execute transactions for the EOA.

This approach enables many of the same use cases as EIP-4337 without requiring each user to deploy a new smart contract. One significant difference is that transactions originate from the EOA, maintaining account history, ETH, NFTs, tokens, and more.

However, a common concern with EIP-3074 is the risk of delegating to malicious contracts. Users who delegate to a malicious contract could drain their entire wallet. This security risk is a significant consideration in the ongoing discussions about the proposal.

Top of Form

The likely solution to this problem is that wallet providers will not allow users to authorize any contract. Instead, they would maintain a whitelist of approved contracts that users can delegate to, ensuring that any contract outside this list is not shown to users.

A key feature of EIP-3074's delegation is that it is temporary. Any single transaction from the EOA will cause the nonce to increase, invalidating outstanding authorizations. Essentially, after you make a transaction, the delegation is no longer valid, adding a layer of security.

However, these proposals aim to transition users from EOAs to smart contract accounts, so why are we adding more features to EOAs? This brings us to the next proposal: EIP-5003.

EIP-5003 introduces another opcode, "AUTHUSURP," which allows code to be deployed at an EIP-3074 authorized address. Here's the difference between the two:

• EIP-3074 offers temporary delegation to a smart contract, which can be revoked.
• EIP-5003 enables a permanent migration from an EOA to a smart contract account, effectively "converting" the EOA.

A significant issue with combining EIP-3074 and EIP-5003 is their compatibility with the current account abstraction via EIP-4337. Some in the Ethereum community are concerned about creating two separate code ecosystems for account abstraction.

This concern leads us to Vitalik's proposal, EIP-7702. His proposal modifies EIP-3074 to make it leaner and more compatible with EIP-4337, preventing the fragmentation of account abstraction methods. It also considers EIP-5003 as the next step for permanent migrations, ensuring a unified approach to evolving Ethereum's account system.

EIP-7702 proposes a new transaction type that includes both a contract_code and a signature field. When executing a transaction, the proposal sets the contract code of the signer account to contract_code at the start and reverts it to empty at the end of the transaction.

This approach achieves the same temporary delegation of an EOA to a smart contract as EIP-3074 but without adding new opcodes (which require a hard fork). Instead, it defines functions to be called:

• AUTH becomes a call to "verify"
• AUTHCALL becomes a call to "execute"

To break it down:

1. It checks if the account's contract code is empty.
2. If empty, it sets the account's contract code to the provided contract_code.
3. It executes the transaction based on how the provided smart contract handles transactions.
4. It resets the account's contract code to empty.

"Contract code" refers to the code where the smart contract's functionality is defined. For EOAs, this is typically empty since they are not contracts. EIP-7702 temporarily populates this field with smart contract code for the duration of the transaction, allowing new behaviors specific to that transaction.

This method allows for the temporary addition of new behavior for EOAs without a permanent change. However, the next step could be to make this behavior permanent by opting not to set the code back to empty at the end of the transaction.

One of the best aspects of this proposal is its compatibility with the existing account abstraction (AA) work built for ERC-4337. The contract code that users need to sign could be the existing ERC-4337 wallet code.

Once this change is implemented, existing EOAs will be able to execute any smart contract code. With an additional EIP, EOAs could permanently upgrade to run specific code, potentially transforming how users interact with web3 applications.

EIP-7702 provides a seamless and backward-compatible method for introducing smart contract functionalities to EOAs, facilitating a smoother transition to more secure and feature-rich account abstractions. This could significantly enhance user interactions with Web3 apps, paving the way for a more versatile and secure Ethereum ecosystem.