As they are all account abstraction proposals, what are the differences between ERC-4337, EIP-3074 and EIP-7702?

Original title: "Why is Vitalik in a hurry to propose a new account abstraction solution EIP-7702?"

Original author: 0xNatalie, ChainFeeds

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. Many members are worried that if the signature is misused, the entire account funds will be at risk, providing opportunities for phishing attackers. In order to further enhance security, Vitalik Buterin recently proposed EIP-7702 as an alternative to EIP-3074, which has aroused widespread discussion in the community.

EIP-7702 introduces a new transaction type to enhance the account abstraction function. This new transaction type allows an externally owned account (EOA) to temporarily adopt the features of a smart contract during a transaction, and then restore its original state after the transaction is over. So what are the differences between ERC-4337, EIP-3074, and EIP-7702, all of which are account abstraction proposals?

ERC-4337: Account Abstraction Standard at the Application Layer

ERC-4337: Account Abstraction Using Alt Mempool. ERC-4337 was proposed by Vitalik as an application layer standard. Its main goal is to allow smart contract accounts to have the feature of EOA actively initiating transactions. It introduces a smart contract called EntryPoint, which allows smart contracts to behave like users' 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 approach is compatible with the existing EOA system, making the transition smoother.

· Goal:Achieve account abstraction so that smart contracts can be used as accounts to process and verify transactions.

· Essence: Allows smart contract accounts to 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 SamWilsn , 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. It introduces 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 it is authorized to a malicious contract, it may lead to the theft of funds.

· Goal:Enhance the functionality of EOA by allowing EOA to temporarily delegate its permissions to smart contracts.

· Essence:Upgrade EVM and add two opcodes.

EIP-7702: Temporary smart contract EOA

EIP-7702: Set the 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 the 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 into a smart contract account) based on EIP-7702. By setting it not to clear the code after the transaction is completed, the permanent conversion of EOA to 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 utilize the smart contract code that has been written and deployed for ERC-4337, so that the existing account abstraction work can be reused and 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 features 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 EIP-3074-like functions without introducing new opcodes, while better preparing for the realization 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.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia