EIP-7702, along with the existing EIP-4337, is highly compatible with the account abstraction work. Once this proposal is implemented, it could completely change the way people interact with Web3 applications. This article, based on Jarrod Watts’ work, provides an overview of the working principles and everything one needs to know about this new proposal.
Firstly, the EIP-7702 proposal is surprisingly concise, which has left some people confused about how it actually works. To understand EIP-7702, we first need to understand three other proposals mentioned in it: EIP-4337, EIP-3074, and EIP-5003.
All these proposals share a common goal, which is to address the limitations and risks associated with Ethereum’s EOA (Externally Owned Accounts) and introduce account abstraction. Account abstraction allows users to use smart contracts as accounts to add more functionality and security.
EIP-4337 was launched on the mainnet in March 2023. It allows smart contracts to be written like accounts, enabling them to verify and execute transactions and improving user experience (UX). It has gained widespread adoption, primarily led by Polygon, with increased activity from Coinbase’s ecosystem and Coinbase Wallet.
However, EIP-4337 has some limitations. Most smart contract accounts under EIP-4337 are controlled by a single EOA signer, resulting in a workaround solution due to the lack of native support for connecting smart contract accounts in Web3 applications. Currently, most people still use EOAs through plugins like MetaMask.
This leads us to the next proposal, EIP-3074. It aims to empower EOAs by allowing them to delegate control of their EOAs to smart contracts. It introduces two new opcodes: AUTH, which allows EOAs to authorize a smart contract to execute operations on their behalf, and AUTHCALL, which enables authorized smart contracts to execute transactions for EOAs.
A common concern with EIP-3074 is the potential for malicious contracts to be authorized by users, leading to the loss of all their encrypted assets. Wallet service providers may address this issue by not allowing users to authorize any contracts and maintaining a whitelist of smart contracts eligible for authorization.
Another key point of EIP-3074 is that the delegation is not permanent and becomes invalid after a single transaction by the EOA, as the nonce increases. The goal of these proposals is to transition users from EOAs to smart contract accounts, so adding more functionality to EOAs may not be desired.
This brings us to the next proposal, EIP-5003. It introduces another opcode, AUTHUSURP, which deploys code to the authorized address under EIP-3074. The difference between EIP-3074 and EIP-5003 is that EIP-3074 allows temporary delegation to smart contracts, while EIP-5003 enables a permanent migration from EOA to smart contract accounts.
However, the compatibility between EIP-3074 + EIP-5003 and the current account abstraction scheme through EIP-4337 is a concern, as it may lead to the creation of two separate code ecosystems for account abstraction.
To address this, Vitalik Buterin proposes EIP-7702, which modifies EIP-3074 to make it more concise and compatible with EIP-4337. This avoids the creation of two independent account abstraction ecosystems. EIP-5003 is considered the next step for permanent migration.
EIP-7702 introduces a new transaction type that accepts both contract_code and signature fields. It sets the contract code of the signer’s account to contract_code at the start of the transaction execution and resets it to empty at the end. It achieves temporary delegation, similar to EIP-3074, without introducing new opcodes.
One notable aspect of this proposal is its high compatibility with all the account abstraction work built through EIP-4337. Users can use existing EIP-4337 wallet code as the contract code to be signed. This means that existing EOAs will be able to execute any smart contract code. Through an additional EIP, EOAs can also permanently upgrade to execute specific code.
Over time, this could fundamentally change the way we interact with Web3 applications.
Related articles:
– EIP-3074: Will malicious signatures deplete Ethereum wallet funds? Developer explains
– Ethereum’s next step: EIP-3074 incorporated into Prague upgrade, introduces three major reforms with wallet integration