How to view Vitalik's support for EIP-7702: Will it sacrifice the infinite potential of the EIP-3074 invoker market?
Author: Haotian
How do you view the recently discussed Ethereum proposal EIP-7702? In simple terms, it is an optimized advanced version of EIP-3074, more compatible with the grand strategy of ERC-4337 Ethereum account abstraction. However, in my opinion, the call for EIP-7702 aligns with the orthodox development framework of ERC-4337 but limits the infinite potential of EIP-3074 on "invoker," making it merely a "compromise." Why? Next, I will share my views:
1) From a definitional standpoint, ERC-4337 is the most familiar to everyone, allowing users to delegate permissions to a brand new contract account address for control, thereby achieving a series of optimized user operation experiences through Paymaster and other proxy contract functions, such as social recovery and gas payment. ERC-4337 aligns with the most orthodox direction of Ethereum's permission management optimization development, but onboarding users to the account abstraction system, independent of the original EOA address, incurs significant "migration" costs.
EIP-3074 can empower existing EOA addresses with new smart contract capabilities through AUTH and AUTHCALL operations. Each EOA address can set up an Invoker logic contract to extend functionality. The Invoker has great customization for transaction logic and permission control, making it sufficiently flexible. The downside is that if the invoker contract behaves maliciously, it can cause significant asset damage to users.
EIP-7702 is a "compromise" proposal that lies between 3074 and 4337. It upgrades the EIP-3074 scheme, allowing users to upgrade their EOA address to a contract-controlled state for a one-time transaction, which can revert back to EOA status after the transaction ends. Therefore, it can better fit the ERC-4337 account abstraction framework while also constraining the potential chaos that may arise from the super-flexible state of EIP-3074.
2) @VitalikButerin will naturally strive to maintain the ERC-4337 account abstraction logic, and proposals like EIP-3074, which may deviate from the main development direction of ERC-4337, will not be "actively" promoted. Many people worry that if the 3074 proposal is deeply developed, it could lead to a "hard fork" in Ethereum. In my view, this concern may be overly pessimistic, unless one day the ERC-4337 proposal is abandoned in favor of a full upgrade to EIP-3074; the two are essentially parallel concepts. Moreover, the market has already chosen 4337 as the development focus, but that does not mean 3074 should be completely eliminated. The free invoker market that EIP-3074 points to actually has great potential.
In the standard framework of 3074, the invoker is the "authorizer" delegated by the user. If the invoker is suspicious, users will undoubtedly suffer asset losses. However, if the invoker is friendly, it will accelerate the development of the "intent-centric" transaction experience optimization track that everyone heavily anticipates. The Sover market that everyone expects in the intent-centric direction essentially relies on the invoker to design complex transaction logic in contracts: for example, automated transaction dispatch; condition-triggered subsequent transactions; automated asset distribution; transaction batch aggregation; adding multi-signature approval transactions; transaction time limits; integration with external systems; transaction financial strategies, etc.
A completely flexible invoker market will accelerate the development of the intent track Sover solver market, allowing for more flexible and customized refined services targeting specific groups, such as:
@ApertureFinance is building a new intent-driven, gasless, automated workflow invoker infrastructure, which has already seen $2.6 billion in transaction volume and is favored by some institutional trading users;
For example, @bentobatch has built a Streamlined Transaction trading layer based on Wallet applications, allowing users to simplify on-chain operations for a simpler and cheaper trading and usage experience.
In addition to optimizing the trading experience, @dappOS_com is also exploring the rapid implementation of intent infrastructure in the direction of chain architecture and decentralized solver market incentives and applications.
3) In my view, ERC-4337, as the mainstream orthodox "account abstraction" standard, has indeed become a benchmark for some layer 2 chains, middleware network services, and wallet service providers in the account rights reform and upgrade over the past few years, helping users achieve rapid improvements in transaction usage experience. However, objectively speaking, the account abstraction standard is constrained by the stability of the Ethereum system framework in terms of customization, development experience, and transaction logic complexity, thus limiting its development and implementation speed.
The invoker market pointed to by EIP-3074 does indeed deviate from the ERC-4337 account abstraction direction in the short term and may bring some malicious contract risks. However, if we view this invoker market within a more diverse decentralized solver network market, the positive significance of the free invoker market may outweigh its negative impacts.
The new EIP-7702 framework not only continues the advantages of EIP-3074's "flexible account transformation" but is also sufficiently compatible with ERC-4337. However, one-time permission granting does not maximize the potential of the "invoker" in designing and managing transaction logic complexity.
Although the Invoker can also accept the EIP-7702 framework and adapt some products and services within it to accelerate the rich development of the Solver, the exploration space for service upgrades along the more freely extendable EIP-3074 may actually be larger? (With a tightening spell, the Monkey King is still there, but has lost the ability to wreak havoc in the Heavenly Palace.)
How should we say it? I tend to view ERC-4337 and EIP-3074 as two independent parallel free markets. Completely abandoning the broader development potential of EIP-3074 to maintain the orthodoxy of ERC-4337 may be somewhat counterproductive. Of course, in the short term, using EIP-7702 as a transition is also a viable optimal solution. What do you think?