bg

Vitalik Proposes EIP-7702 for Externally Owned Accounts

Updated at: August 14, 202415 Mins Read

Author: QuillAudits Team

The Ethereum team is taking steps to improve the platform for crypto users. One exciting proposal is EIP-7702, which aims to streamline transactions and boost security for externally owned accounts on Ethereum. This could lead to a smoother user experience, potentially bringing crypto to a wider audience.


Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett have proposed a new transaction format to improve Externally Owned Accounts (EOAs). This draft proposal introduces a fresh transaction type that temporarily transforms EOAs into smart contract wallets when executing transactions, providing features similar to those described in EIP-3074.


This blog will explore the technical details of the newly proposed EIP-7702, examining its similarities to EIP-3074, its fresh updates, and other relevant aspects.



The Evolution of Previous EIPs Regarding Account Abstraction


The latest EIP-7702 proposal is surprisingly concise, sparking confusion about its implementation. To fully understand its intricacies, let's explore three related proposals it refers to:


1/ EIP-4337

2/ EIP-3074

3/ EIP-5003


Let's start by looking at the common goal of all these suggestions. Regular Ethereum accounts, called EOAs, have some issues. They carry risks and have notable restrictions. By using account abstraction, you can employ a smart contract as your account, improving both what you can do and how secure it is, thus addressing these challenges.


In March 2023, ERC-4337 was launched on the mainnet. This protocol enabled smart contracts to function similarly to accounts, empowering them to validate and execute transactions, known as UserOps. Since its debut, ERC-4337 has been widely adopted, particularly by Polygon, although Base has seen increased activity in recent months.

chain activity

So what's wrong with 4337? Why is there another account abstraction proposal today?


The answer: EOAs are still the most used type of account by far! In addition to this, most 4337 smart contract accounts are controlled by a single EOA signer! Because there is no way to "convert" your EOA to a smart contract account, we have this weird middle-step solution. Also it lacks native support by web3 apps to connect smart contract accounts.


img2.png

This brings us to our following suggestion, EIP-3074. Surprisingly, this proposal predates 4337! Nonetheless, it hasn't been incorporated into the mainnet yet. EIP-3074 aims to empower EOAs by enabling them to transfer control of their EOA to a smart contract.


The proposal outlines the following:


Add two new opcodes.


1/ AUTH: EOAs can call AUTH to authorize a given smart contract to perform actions on their EOA's behalf.


2/ AUTHCALL: An authorized smart contract can use AUTHCALL to perform transactions for the EOA.


img3.png

This enables many of the same use cases as 4337 does, without each user having to deploy a new smart contract. One key difference is that transactions come **from** your EOA, not a new contract that has none of your account history, or ETH, NFTs, tokens, etc.


A common reaction to 3074 was "what if people make malicious contracts and users delegate to them?" Delegating to a malicious contract could result in EVERYTHING being drained from your wallet.

Secure Your Ethereum Smart Contracts with QuillAudits

Ready to secure your Ethereum smart contracts? Take the first step towards a safer blockchain journey. Request an Audit with QuillAudits today & ensure your contracts are robust and secure!

Check Our Pricingarrow

A likely solution to this issue is that wallet providers may restrict AUTH access only to specific contracts. They might maintain a roster of approved contracts eligible for delegation, while excluding any contracts not on this list from user visibility.


An essential aspect of EIP-3074's delegation feature is its non-permanence. "A single transaction from the EOA will cause the nonce to increase, invalidating outstanding authorizations." In essence, once a transaction is executed, the delegation becomes null and void.


We also don't really want to give more power to EOAs. After all, the goal of these proposals is to move users from EOAs to smart contract accounts, so why are we adding features to EOAs? This leads us to our next proposal: EIP-5003.


EIP-5003 adds another opcode, "AUTHUSURP", that deploys code at an EIP-3074 authorized address.


  • 3074 is a temporary delegation to a smart contract, which is revocable.
  • 5003 is a permanent migration from EOA and "conversion" from EOA to a smart contract account.

One major concern surrounding EIP-3074 + EIP-5003 is its lack of compatibility with the existing account abstraction through ERC-4337. Some members of the Ethereum community worry that this could result in the development of two distinct code ecosystems.


That brings us to Vitalik's proposal today: EIP-7702. His proposal modifies EIP-3074 to make it leaner and more compatible with ERC-4337; so that we don't end up with two separate AA ecosystems.



What is EIP - 7702?


EIP-7702 proposes a significant enhancement to Ethereum's functionality by introducing a new transaction type designed to improve the flexibility and security of Externally Owned Accounts (EOAs). This transaction type incorporates a `contract_code` field along with a signature, allowing EOAs to temporarily adopt smart contract functionalities during a single transaction execution.


The process begins by checking if the contract code of the signer account is empty. If so, the contract code is temporarily set to the provided smart contract code. This effectively transforms the signing account into a smart contract wallet for the duration of that specific transaction, allowing it to execute based on the smart contract's logic. Once the transaction completes, the account's code is reset to empty, ensuring the EOA reverts to its original state.


Unlike previous proposals such as EIP-3074, which required the introduction of new opcodes and a hard fork, EIP-7702 achieves temporary delegation of an EOA to a smart contract without these complexities. It instead defines specific functions to be called:


- `AUTH` -> a call to "verify"
- `AUTHCALL` -> a call to "execute"

img4.png

This approach not only simplifies the implementation but also enhances compatibility with the account abstraction (AA) work already established under ERC-4337. The contract code that users would need to sign could leverage existing ERC-4337 wallet code, further streamlining the process.


Overall, EIP-7702 seeks to address common challenges such as batching transactions, sponsoring transactions, and enabling privilege de-escalation, bringing Ethereum closer to providing a seamless and secure environment for decentralized transactions and interactions. This innovation opens up new possibilities for developers, inspiring them to explore innovative ways of leveraging Ethereum's enhanced functionality.


Motivation Behind EIP - 7702


There's a growing interest in enhancing the short-term functions of EOAs (Externally Owned Accounts) to make apps more user-friendly and, in some cases, more secure. Here are three key improvements:


1. Batching: This lets a user perform multiple actions in one single transaction. For example, a user can approve and then use ERC-20 tokens in a decentralized exchange (DEX) in one go, whereas currently, this requires two separate transactions. In more complex scenarios, the result of the first action might be used as the input for the second.

2. Sponsorship: Here, one account pays for another account's transaction. The paying account might get compensated with another type of ERC-20 token, or it might be an app operator covering costs for its users.

3. Privilege De-escalation: Users can create secondary keys with limited permissions. For instance, a key might be allowed to use ERC-20 tokens but not ETH, or it might only be able to use up to 1% of the total balance each day, or interact with just one specific app.


EIP-3074 addresses these improvements but has concerns about its long-term viability:


  • It introduces two operations, AUTH and AUTHCALL, that might become obsolete if all users eventually switch to smart contract wallets—something that seems likely as technologies like quantum computing develop.
  • It could lead to a split between two ecosystems: those using "invoker contracts" and those using "smart contract wallets," which could dilute efforts in development.

The goal of this EIP is to support the features of EIP-3074 without these downsides.



Beyond words we dedicate ourselves to pioneering the web3 industry towards a secure future

DSA MemberTS GovBWA LogoCoinweb Logo
Check Our Pricingarrow

Conclusion


EIP-7702, currently in its draft stage, represents a significant advancement in Ethereum's account models by enabling EOAs to temporarily function as smart contract wallets. This proposal simplifies transactions and enhances security, promising a more accessible and efficient user experience. While the future of EIP-7702 remains uncertain, it aligns with broader efforts to refine Ethereum, as seen with the planned inclusion of EIP-3074 in the upcoming Pectra upgrade slated for late 2024 or early 2025. These developments highlight a commitment to improving Ethereum's functionality and user-friendliness, marking a progressive step towards a more sophisticated blockchain ecosystem.

Frequently Asked Questions

What is EIP ?
An EIP (Ethereum Improvement Proposal) is a document that proposes new features, processes, or changes to the Ethereum protocol.
What is EIP-7702 and how does it improve Ethereum's account model?
How does EIP-7702 differ from previous proposals like EIP-3074 and ERC-4337?
What potential user benefits does EIP-7702 offer compared to existing Ethereum functionalities?
logo

Subscribe to our Newsletter

Your weekly dose of Web3 innovation and security, featuring blockchain updates, developer insights, curated knowledge, security resources, and hack alerts. Stay ahead in Web3!

Telegram