Author: 0xNatalie Source: ChainFeeds Reseach
ERC-4337 is an application layer standard for account abstraction, EIP-3074 is a protocol layer standard that directly modifies EVM, and EIP-7702 is a bit in between the two, temporarily giving smart contracts to EOA.
EIP-3074 was included in Ethereum's next hard fork plan in April this year. The proposal aims to bring a more convenient experience to users by allowing externally owned accounts (EOA) to delegate transaction permissions to smart contracts. However, this feature has also caused concerns in the community, and many members are worried that if the signature is misused, the entire account funds will be at risk, providing opportunities for phishing attackers. To further enhance security, Vitalik Buterin recently proposed EIP-7702 as an alternative to EIP-3074, which has sparked widespread discussion in the community. EIP-7702 introduces a new transaction type to improve account abstraction. This new transaction type allows externally owned accounts (EOAs) to temporarily adopt the characteristics of smart contracts during a transaction and then restore their original state after the transaction. So, as they are all account abstraction proposals, what are the differences between ERC-4337, EIP-3074, and EIP-7702? ERC-4337: Account Abstraction Standard for the Application Layer ERC-4337: Account Abstraction Using Alt Mempool ERC-4337 was proposed by Vitalik and is an application layer standard. Its main goal is to allow smart contract accounts to have the characteristics of EOA actively initiating transactions. It introduces a smart contract called EntryPoint, which allows smart contracts to behave like user accounts, which means that users operate account-like smart contracts to manage their assets and transactions. This allows complex logic to be implemented, such as multi-signatures, automatic execution of transactions, etc.
Main features:
No hard fork required: ERC-4337 does not require a hard fork to be implemented, and no modifications to the Ethereum protocol are required.
Compatibility: This method is compatible with the existing EOA system, making the transition smoother.
Goal: Realize account abstraction so that smart contracts can process and verify transactions as accounts.
Essence: Let smart contract accounts have the feature of EOA actively initiating transactions.
EIP-3074: Authorization and Proxy Execution
EIP-3074: AUTH and AUTHCALL opcodes. EIP-3074 was proposed by Ethereum researcher Sam Wilson, Go Ethereum developer Matt Garnett, and others, and Vitalik did not participate in the drafting of this proposal. This is a method that allows EOA to delegate its authority to smart contracts, introducing two new opcodes: AUTH
and AUTHCALL
, allowing smart contracts to perform operations on behalf of EOA, such as batch processing of transactions and sponsoring gas fees. This is a major change for Ethereum's virtual machine.
Main features:
Delegation mechanism: EOA can authorize a smart contract through the AUTH
opcode, and then let the smart contract perform operations on its behalf through AUTHCALL
.
Security risks: The delegation mechanism may cause security issues, because if authorized to a malicious contract, it may lead to theft of funds.
Goal: Enhance the functionality of EOA by allowing EOA to temporarily authorize its permissions to smart contracts.
Essence: Upgrade EVM and add two opcodes.
EIP-7702: Temporary smart contract EOA
EIP-7702: Set EOA account code for a transaction. Vitalik, as the first author, just released this proposal on May 7. As an alternative to EIP-3074, EIP-7702 introduces a mechanism that allows EOA to temporarily adopt smart contract functions during a transaction. In this way, EOA can convert EOA into a smart contract wallet during a single transaction execution, and restore to a normal state after the transaction is completed. And because EIP-7702 already provides a framework for temporarily changing the EOA code, it becomes relatively simple to implement EIP-5003 (allowing EOA to be permanently converted to a smart contract account) on the basis of EIP-7702. By setting it not to clear the code after the transaction is completed, the permanent conversion of EOA to a smart contract can be achieved.
Main features:
Temporary conversion: During the transaction process, the smart contract code of EOA is temporarily given the ability to perform specific operations.
High compatibility: EIP-7702 is highly compatible with the smart contract wallet code of ERC-4337, and can directly use the smart contract code that has been written and deployed for ERC-4337, so that the existing account abstraction work can be reused to avoid splitting the existing account system.
No need to introduce new opcodes: Compared with EIP-3074, although EIP-7702 is also a protocol layer standard, it temporarily applies smart contract code in transactions and does not require permanent changes to the Ethereum virtual machine.
Goal: Combining the characteristics of EIP-3074 and ERC-4337, provide a more flexible and compatible account abstraction solution.
Essence:Temporary application of smart contract code.
EIP-7702 provides a way to implement functions similar to EIP-3074 without introducing new opcodes, while better preparing for the implementation of the endgame of account abstraction. The endgame of account abstraction refers to a foreseen future state in which all accounts on Ethereum use smart contract wallets to manage assets and transactions instead of relying on traditional EOA. This scenario in which universal accounts use smart contract wallets is called the "endgame" of account abstraction. EIP-7702 not only solves current problems, but also ensures long-term effectiveness and practicality through compatibility design with possible future account models.