What do you think of the recently hotly discussed new Ethereum proposal EIP-7702? To put it simply, it is an optimized and advanced version of EIP-3074, which is more compatible with ERC-4337 Ethereum account abstraction grand strategy. However, in my opinion, calling for EIP-7702 to cater to the orthodox development framework of ERC-4337 would limit the unlimited potential of EIP-3074 in terms of "invoker", and can only be regarded as a "compromise". Why？ Next, I would like to share my views:

1. By definition, ERC-4337 is the most well-known, allowing users to delegate permissions to a new contract account Address to control, and then realize a series of account abstraction operations such as social recovery and gas payment through proxy contract functions such as Paymaster. ERC-4337 is in line with the most orthodox Ethereum permission management optimization development direction, but to Onboard the user-to-account abstraction system, to be independent of the original EOA Address, will incur a large "migration" cost;

EIP-3074 can be operated by AUTH and AUTHCALL to give the original EOA Address a new smart contract capability, each EOA Address can set an Invoker logic contract to expand the function, Invoker has a great custom transaction logic and permission control and other functions, flexible enough, the disadvantage is that once the Invoker contract is evil, it will cause great asset damage to users;

EIP-7702 is a "compromise" proposal between 3074 and 4337, which upgrades the EIP-3074 scheme to allow users to upgrade their EOA Address to the contract control state only once under the current transaction, and then restore the EOA state after the transaction is completed. Therefore, it can better fit the account abstraction framework of ERC-4337, and at the same time limit the chaos that may be brought about by EIP-3074's ultra-flexible state.

2. @VitalikButerin will naturally vigorously maintain the logic of ERC-4337 account abstraction, and EIP-3074, which may deviate from the main development direction of ERC-4337, will naturally not be "proactively" advocated. There are long concerns that once the 3074 program is Depth developed, the result will be to induce a "Hard Fork" in the Ethereum. In my opinion, this may be too unfounded, unless one day the ERC-4337 solution is abandoned and the EIP-3074 is fully upgraded, the two are a parallel concept. Moreover, the market has chosen 4337 as the focus of development, but it does not mean that 3074 should be completely banned, and the free invoker market pointed to by EIP-3074 is actually promising.

If the invoker is suspicious, the user will undoubtedly lose assets, but if the invoker is friendly, it will accelerate the development of the "intent-centric", which is highly anticipated to optimize the trading experience. Because the Sover market that everyone expects in the direction of intent-centric essentially relies on invoker to design complex transaction logic in the contract: for example, automated dropshipping transactions; The condition triggers the next trade; automatic asset allocation; Batch aggregation of transactions; Increase the number of longest signature approval transactions; Trading time limits; Integrate transactions with external systems; Trade financial strategies and more.

A fully flexible invoker market will accelerate the development of the intent track Sover solver market, which can have more long flexible and customized long wick candle refined services for specific people, such as:

@ApertureFinance is building a new invoker infrastructure that is intent-driven, gasless, and automates workflows, with $2.6 billion in volume, which is favored by some institutional trading users.

For another example, @bentobatch has built a Streamlined Transaction layer based on the Wallet application, allowing users to simplify on-chain operations and make transactions simpler and cheaper.

In addition to the optimization of the trading experience, @dappOS_com is also exploring the rapid implementation of Intent infrastructure in the direction of chain architecture and Decentralization Solver market incentives and application implementation.

3. In my opinion, ERC-4337, as the mainstream orthodox "account abstraction" standard, has indeed become the benchmark for some layer2 chains, middleware network services and wallet service providers in the past few years in the reform and upgrading of account rights, helping users to rapidly improve their transaction experience. However, objectively speaking, the account abstraction standard is restricted by the stability of the Ethereum system framework in terms of customization, development experience, transaction logic complexity, etc., so the development and landing speed is relatively limited.

The invoker market pointed to by EIP-3074 does deviate from the direction of ERC-4337 account abstraction in the short term, and may bring some malicious contract risks, but if this invoker market is placed in a more longer decentralization solver solver network market, the positive significance of the Invoker free market may outweigh its negative effects.

The new EIP-7702 framework not only inherits the advantages of EIP-3074's "flexible account conversion", but is also ERC-4337 compatible. However, the one-time grant of permissions cannot maximize the potential of "invoker" in the design and management of transaction logic complexity.

However, Invoker can also accept the EIP-7702 framework, which can be adapted with a number of products and services to accelerate the development of rich Solver solvers. But Invoker's more free and scalable service upgrade along EIP-3074 will the exploration shorter actually be larger? (With a tight spell, he is also a monkey brother, but he has no ability to make trouble in the heavenly palace.)

How so? I tend to view ERC-4337 and EIP-3074 as two separate and parallel free markets, and it would be a bit of a choke to completely discard the broader development potential of EIP-3074 in order to maintain the legitimacy of ERC-4337. Of course, in the short term, using EIP-7702 as a transition is also an optimal solution. What do you think?