Ethereum governance war: EIP3074, ERC4337 and EIP7702

Author: shew

Overview

The most complex governance dispute occurred during the Pectra upgrade. When EIP3074 was included in the Pectra upgrade, it caused a huge debate, especially opposition from the ERC4337 team.

EIP3074 got into trouble and the governance process could not proceed. It was not until Vitalik proposed EIP7702 that the ERC4337 team ended their doubts about EIP3074.

GCC Research found that the governance issues of EIP3074 and ERC7702 in the Pectra upgrade are rarely discussed in the Chinese world. However, this governance issue also reflects the deep-seated problem of Ethereum governance, that is, under the premise of code is law, who can control the specific content of the code. The governance issues of EIP3074 and ERC7702 can give us a good perspective to observe the real governance process within Ethereum.

The final conclusion of this article is paraphrased from a commentary article published by ZeroDev, which points out that the Ethereum governance system is a VVRC model. The inclusion of any proposal must first comply with Ethereum's values (Value), then the proposal should be reflected in the vision (Vision) designed by Vitalik, and finally the proposal should be reflected in the roadmap (Roadmap), and finally the core developers will discuss and incorporate it into the client (Client) implementation.

EIP2537 introduced by GCC Research in the previous article was delayed in its inclusion in the hard fork due to implementation issues at the Client level, while EIP3074 was not included in the hard fork due to Vision and Roadmap issues. Ethereum core developers directly chose EIP7702 written by Vitalik as the final account abstraction proposal.

Proposal content overview

Before introducing the specific governance process, we first need to briefly introduce the specific content of EIP3074, EIP7702 and ERC4337 involved in this article.

EIP3074 is an execution layer proposal, and the execution of this proposal requires node software upgrades. The core purpose of EIP3074 is to implement the functions of gas sponsoring and batch transactions. The so-called gas sponsoring means that users can use any token to pay gas fees, or users can pay gas fees offline. However, it should be noted that compared to other account abstraction proposals that allow changes to the signature verification algorithm, EIP3074 does not allow users to use any signature algorithm other than secp256k1. In other words, EIP3074 is not a proposal that meets all account abstraction functions. This is also a point that EIP3074 has been criticized for.

In order to achieve the expected goal, EIP3074 introduced two opcodes, AUTH and AUTHCALL. The AUTH opcode can verify the signature. Once the signature verification is passed, the opcode will configure the authorized in the current EVM context as the address of the signer. After configuring the authorized in the context, AUTHCALL can use the authorized address as the msg.sender of the call transaction to initiate the transaction. To some extent, users can entrust their accounts to a smart contract in a transaction by signing. We generally call this smart contract entrusted by the user the invoker contract.

What is the specific content of the user's signature? The user needs to sign the following content:

The invoker address in the above content refers to the invoker contract address that the user wants to delegate. The EVM will verify whether the user's signature content is consistent with the contract that actually verifies the signature to prevent the user's AUTH signature content from being used by other contracts.

The nonce is an identifier to prevent transaction replay. However, it should be noted that the AUTH opcode will verify whether the nonce in the signature is consistent with the nonce of the currently signed EOA. In theory, as long as the user does not use the EOA account to initiate a transaction to increase the nonce value, the AUTH signature issued by the user can always be used by the invoker contract. This is a huge security vulnerability, which means that users using EIP3074 must trust the relay service provider who obtains the signature. If the relay service provider who obtains the user's signature is malicious, the service provider may replay the user's AUTH signature at a certain time to steal the user's assets.

Another security issue is the commit field. The commit field is used to guarantee certain operations. Users can finely control their signature permissions in the commit, such as writing some content in the commit to prevent their signature content from being used for ETH transfers. In the EIP3074 document, the proposer gave a series of examples of using the commit field. But the problem is that the role of commit depends entirely on the definition of the smart contract, and it is essentially an optional content. Different smart contracts may have completely inconsistent interpretations of the content in the commit, and some contracts may not even read the content in the commit at all. If users want to use EIP3074 safely, they must simply review the smart contract themselves.

Finally, we introduce the impact of EIP3074 on the current Ethereum transaction memory pool. After the introduction of EIP3074, there may be a method of attacking the memory pool. Hackers can use a large number of accounts to initiate transactions, and then use EIP3074 transactions to drain the ETH in these accounts at once when the transactions are about to be packaged, which will cause all previously initiated transactions to fail. This type of attack will have a considerable impact on the execution layer nodes, which is essentially a DoS attack. However, it should be noted that EIP7702, which is used to replace EIP3074, also has this problem, but EIP7702 introduces some restrictions to avoid this problem, which we will discuss later.

In addition to the problems with EIP3074 itself mentioned above, Yova, the author of ERC4337, introduced more objections in the article Implications of EIP-3074 inclusion. In short, these opinions mainly include:

1. Centralization risk. Due to the special properties of AUTH signatures, users must fully trust the relay service providers and underlying infrastructure of EIP3074. At the same time, the infrastructure built by account abstraction protocols such as ERC4337 is completely incompatible with EIP3074.
2. User security. As mentioned above, EIP3074 does not have a unified permission control method, and the signature nonce design also has security risks, which is likely to lead to serious security issues.
3. Incomplete account abstraction function. Compared with other account abstraction proposals, EIP3074 is incomplete and cannot implement functions such as changing the user signature algorithm.
4. There are problems with user experience. When a user needs to delegate his account to a smart contract, the user needs to make an AUTH signature and then publish the call containing the AUTH signature to the chain. The user needs to sign twice.

EIP7702 is a proposal by Vitalik to replace EIP3074. This proposal does not introduce new EVM opcodes, but introduces a new transaction type called SET_CODE_TX_TYPE. Once a user initiates a transaction of type EIP7702, the user can add smart contract functions to his EOA while retaining the basic functions of EOA. In short, users can continue to use wallets such as MetaMask to initiate transactions, or other users can call EOA addresses in the form of smart contracts.

We introduce the function of EIP7702 with a simple batch transaction example. Users can use EIP7702 to entrust their EOA address to a smart contract that can execute batch calls, and then users can directly call their EOA address in the form of smart contracts to initiate batch transactions.

From a technical implementation perspective, the transaction type introduced by EIP7702 adds an authorization_list list compared to traditional transactions. The specific content of the list is [[chain_id, address, nonce, y_parity, r, s], ...]. Among them, address is the address of the smart contract that the user wants to entrust, and nonce is the user's current nonce value. The remaining y_parity, r, and s are all the user's signature results. In the specific execution process, we will first traverse each item in the authorization_list for processing. The processing method is to restore the EOA address through the signature parameters such as y_parity, and then point the EOA address to the smart contract with the address of address. After that, the EOA address can accept calls to play the function of the contract.

The advantages of EIP7702 are very obvious, and the core advantage is that EIP7702 essentially allows EOA to have the function of smart contracts. This is consistent with the basic rules of account abstraction such as ERC4337, which means that EIP7702 can utilize all the explorations and reuse existing infrastructure in the current account abstraction field. For example, EIP7702 can directly use the infrastructure of ERC4337. Currently, ERC4337 has launched EntryPoint v0.8 that supports EIP7702 calls. From the perspective of reusing existing infrastructure, EIP7702 and ERC4337 have the same degree of decentralization.

Of course, EIP7702 does not actually completely fix the problems in EIP3074. Most of the problems in EIP3074 still exist. EIP7702 requires account contracts to have secure implementations, and the protocol itself does not guarantee any security. In the early days of EIP7702, some developers proposed to standardize signature nonce to avoid possible replay attacks, but EIP7702 did not accept these suggestions in the end. So if users want to use EIP7702 safely, then users need to review the security of the contract themselves.

At the same time, EIP7702 will also bring a series of problems to the execution layer. In the above article, we introduced a possible method of using EIP3074 to perform a DoS attack on the execution layer memory pool. This method is also effective in EIP7702. Therefore, EIP7702 recommends that all EOA addresses using EIP7702 can only have one pending transaction in the memory pool to avoid large-scale DoS attacks.

In summary, the biggest problem with EIP3074 is that it does not implement the complete account abstraction function, while EIP7702 does. And it is the author of ERC4337 who defines what "complete account abstraction" includes. After reading this, readers should understand why EIP3074 was opposed by the ERC4337 team and was eventually replaced by EIP7702. We will introduce the entire process of overall governance and discussion later.

Governance process of EIP3074 and EIP7702

EIP3074 was mentioned very early in the Ethereum core developer meeting. In Meeting #109 on April 2, 2021, Ethereum core developers had a brief discussion on EIP3074. The result of the discussion was very simple:

1. Alexey proposed that the EIP3074 signature content has security risks, which may cause serious security losses to users. He suggested that EIP3074 further standardize the specific content of the AUTH signature. This proposal was supported by Martin.
2. James proposed that EIP3074 may bring potential execution layer vulnerabilities, such as DoS attacks, and suggested that EIP3074 provide a written threat analysis
3. Alexey and Martin complained that the EIP3074 documentation was of average quality and took a lot of time to read and understand.
4. Martin believes that the core of EIP3074 is the cooperation and implementation with applications, especially wallet developers. The author of EIP3074 said that he has had a series of exchanges with application developers.

Interestingly, Vitalik believed in this meeting that Ethereum needs a technical solution for multiple calls for one transaction designed for EOA. Although EIP3074 has possible security issues, EIP3074 provides a possible technical solution, and developers need to move forward on the basis of EIP3074.

Apparently, due to security issues with EIP3074, this meeting did not include EIP3074 in the London upgrade.

In Meeting #115 on June 11, 2021, EIP3074 developers submitted a security audit report. The meeting mainly discussed the security issues of EIP3074. A simple conclusion is that the EIP3074 invoker contract is very important in the system, so whether the invoker contract needs to be managed is a question. EIP3074 developers hope to formally prove the invoker contract to increase security.

Of course, there was also some discussion about some contracts using msg.sender == tx.origin to determine whether the calling address is EOA. When EIP3074 is introduced, these judgments will become invalid, but the conclusion is that the failure of these judgments will not cause serious security issues. In short, the meeting was mainly for the proposer of EIP3074 to introduce the security audit results of 3074 to the core developers. The final conclusion of the meeting was that 3074 still needs to consider the invoker contract issue, and it is recommended not to be included in the London hard fork.

In Meeting #116 on June 25, 2021, Yova, the core author of ERC4337, submitted a case for a simpler alternative to EIP 3074, which pointed out that EIP3074 has many security issues and suggested modifying some of its contents, such as limiting the content of the commit field in the signature and requiring the commit field to be in the form of {nonce, to, gas, calldata, value, chainid}. After using this signature mode, EIP3074 can only be used to execute certain specific transactions to ensure the security of transactions.

Here is the meeting where the author of EIP3074 responded to Yova’s submission:

1. It is hoped that the invoker contract address will be included in the EIP specification, and then the Ethereum core developers will write a secure invoker contract to avoid security issues.
2. Regarding the content of the commit in the signature, the EIP3074 developer believes that this is entirely a problem for users and wallet software and does not need to be regulated in the EIP.

Vitalik made the following three points in this meeting:

1. EIP3074 still uses the traditional secp256k1 signature scheme, which cannot achieve quantum resistance.
2. EIP3074 has no future compatibility, and using EIP3074 cannot make an EOA evolve into a smart contract account
3. EIP3074 has a limited lifespan. 3074 introduces two pre-assembled codes, AUTH and AUTHCALL. However, according to the account abstraction roadmap, all wallets in Ethereum may be smart contract wallets in the future, and the pre-assembled code of EIP3074 will be abandoned in the future.

In Meeting #131 on February 4, 2022, developers discussed the types of EIPs that should be included in the ShangHai upgrade. EIP3074 was included in the discussion, but the developers simply synchronized the development dynamics of EIP3074. It is worth noting that before the meeting, nethermind wrote the article Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337, which did not contain any objections to EIP3074.

In Meeting #167 on August 3, 2023, the core developers mentioned EIP3074 when discussing another EIP5806. EIP5806 is a solution that allows EOA to call external contracts using delegate calls during transactions. This solution is similar to EIP7702 to some extent. However, the core developers also questioned the security of this solution. Ansgar pointed out that EIP3074 has not been included in the hard fork in the past due to possible security issues, and EIP5806 is a more radical solution.

In Meeting #182 on February 29, 2024, developers discussed in detail whether EIP3074 should be included in the Pectra upgrade. Vitalik proposed that any account abstraction standard needs to have the following three functions:

1. Key rotation
2. Key Deprecation
3. Compatible with quantum-resistant signatures

Vitalik pointed out that EIP5806 may be a better choice than EIP3074. Andrew believes that EIP3074 is more versatile than EIP5806 and recommends using EIP3074. Vitalik refuted Andrew, saying that all wallets in the future may be smart contract wallets. Once this happens, the pre-assembled opcodes introduced by EIP3074 will become invalid. Yoav, the author of ERC4337, made a long speech at the meeting, which mainly included:

1. EIP3074 may lead to DoS attacks on the Ethereum memory pool, and ERC4337 has done a lot of research on this part and provided some rules to avoid attacks.
2. EIP3074 requires users to sign twice when initiating batch transactions, which is unreasonable
3. EIP3074 requires the use of centralized relayers

Yova prefers to use EIP5806 as the account abstraction solution.

In Meeting #183 on March 14, 2024, core developers invited Dan Finlay of MetaMask to discuss the wallet's views on EIP3074. Dan is in favor of EIP3074 and pointed out that MetaMask will also provide support for the testing of EIP3074. MetaMask believes that EIP3074 can functionally enable EOA to enjoy the full functionality of account abstraction. In terms of security, EIP3074 provides a solution for wallet service providers, namely the separation of hot and cold keys. Wallet service providers can hold EOA's EIP3074 signature to initiate transactions. Users can use hot private keys in normal transactions, but cold private keys can be stored in the user's hardware wallet. When an emergency is discovered, users can use the cold private key in the cold wallet to initiate a transaction to revoke the signature of EIP3074. This solution of separating hot and cold private keys brings flexibility to wallet providers.

Vitalik pointed out that within EIP3074, wallet designers must design strict authorization logic to prevent users' EIP3074 signatures from being abused. Interestingly, when discussing MetaMask's support for adding EIP3074 features, Vitalik pointed out that L2 can be used as a transitional solution, that is, any new execution layer modifications should be implemented first within L2, because L2 has limited funds and even serious problems will cause serious losses.

Dror Tiros pointed out in the discussion that the best way to ensure the security of EIP3074 is for Ethereum officials to directly provide an invoker contract. However, Dan Finlay opposed the official opinion of providing a contract. Dan believed that the invoker contract should be completely determined by the user, and the market will eventually choose the safest invoker contract.

Ansgar still insists that EIP3074 should only be signed for one transaction, and wallet service providers should not reuse user signatures to initiate transactions, but Dan Finlay also expressed his opposition. Dan Finlay believes that EIP3074 should be signed by a cold wallet, and then the wallet service provider can reuse the signature to directly initiate transactions for the user. If the user is required to re-sign each time, the cold private key may be used multiple times. This is inconsistent with the idea of separating hot and cold private keys.

Another important topic discussed by core developers during the meeting was the inclusion list. The inclusion list is a means of increasing Ethereum's anti-censorship properties. Simply put, the inclusion list allows some transactions to be committed to be directly included in the next block. But core developers pointed out that EIP3074 is in conflict with the inclusion list.

At Meeting #185 on April 11, 2024, most client implementations agreed to include EIP3074 in the Pectra hard fork, but Geth objected because EIP3074 could cause problems with the Verkle tree. Danno still objected because EIP3074 could cause signature reuse. Yoav also objected, and Yoav gave a solution to attack the memory pool using EIP3074 and Blob transactions. In short, an attacker can initiate a large number of Blob transactions, all of which contain a large amount of data, and then use EIP3074 to invalidate all of these Blob transactions.

In short, at this meeting, all client developers agreed that EIP3074 would be included in the final upgrade.

In Meeting #187 on May 9, 2024, the core developers first discussed the issue of EIP7702 replacing EIP3074. EIP7702 was completed by Vitalik within 90 minutes before the core developer meeting. In the meeting, the core developers recognized that EIP7702 is a standard that is superior to EIP3074. There was no opposition to EIP7702 at this meeting, but some researchers believed that EIP7702 also has irrevocable properties similar to EIP3074, which may lead to fund security issues.

In Meeting #188 on May 23, 2024, the core developers discussed the possibility of replacing EIP3074 with EIP7702. The final conclusion of this meeting was to use EIP7702 to replace EIP3074 as the account abstraction standard in the Pectra hard fork. Vitalik pointed out that EIP7702 also has some irrevocable properties consistent with EIP3074, which have been widely discussed when discussing EIP3074. Interestingly, there were a large number of ERC4337 representatives participating in the meeting.

In fact, the discussion of replacing EIP3074 with EIP7702 had been widely discussed before the 188th core developer meeting. The result of the discussion at that time was that 3074 would be replaced, so there was not a lot of dispute in the core developer meeting.

Roadmap and ruling

After learning that EIP3074 would be replaced, Zerodev, the core infrastructure of account abstraction, published an interesting article titled Reflections on Ethereum Governance Following the 3074 Saga. The article concluded that EIP7702 is a good proposal that can benefit all users. However, the governance process of replacing EIP3074 with EIP7702 is not optimal for the following reasons:

1. EIP3074 has gone through a long discussion process. In the above, we have introduced the multiple discussions of EIP3074 in the core developer meeting.
2. After EIP3074 was confirmed to be included in the Pectra upgrade, it received a lot of opposition from the ERC4337 community. Of course, in the above, we have pointed out that the core developer of ERC4337, Yova, has repeatedly expressed his opposition to EIP3074 in the core developer meeting.

Zerodev believes that the best governance path should be that the ERC4337 community should participate widely and express its opinions during the long core developer discussion process of EIP3074.

EIP3074 developers believe that ERC4337 should be held responsible for the governance failure because EIP3074 has actively participated in governance in the past few years and has communicated with ERC4337 core developer yova many times.

The ERC4337 community believes that EIP3074 should bear the main responsibility for the governance failure. ERC4337 community members believe that Yova, as the core developer of ERC4337, expressed opposition to EIP3074 in many core developer meetings, but the core developers did not seem to listen. Most community members in ERC4337 did not pay attention to the governance dynamics of EIP3074, and most members believed that EIP3074 was a dead standard. The ERC4337 community also believes that the core developers did not actively communicate with the ERC4337 community.

Both EIP3074 and ERC4337 believe that they have done the right governance, and the other party should bear the main responsibility for the governance failure. Obviously, there is a deeper reason at work in this governance process.

In short, the deeper reason is actually the Ethereum roadmap. The Ethereum roadmap has a higher power than the core developer meeting. The account abstraction roadmap is centered on ERC4337. EIP7702 is fully compatible with the ERC4337 standard, but EIP3074 is not fully compatible with the ERC4337 standard. So from the perspective of the Ethereum roadmap, the replacement of EIP3074 is bound to happen.

Of course, the Ethereum roadmap is Vitalik’s personal vision for the future of Ethereum. Once a serious dispute occurs in the governance process of Ethereum, Vitalik, as the roadmap definer, has the final say. And it was Vitalik’s ruling that led to the replacement of EIP3074.

Ethereum's governance model is the values ⇒ vision ⇒ roadmaps ⇒ clients model, or VVRC model for short. The governance process is as follows:

1. Values, especially the values of the community. The values of the Ethereum community include decentralization, anti-censorship, etc.
2. Vision is actually Vitalik’s personal thoughts on the future of Ethereum.
3. roadmaps Roadmaps, researchers give some technical details based on the vision and give a more complete implementation roadmap
4. Clients are implemented by the core developers of the client. They discuss the roadmap using tools such as the core developer meeting and implement the requirements in the roadmap.

The above process is the real governance process of Ethereum. We can see that Vitalik’s personal vision is at the bottom of the Ethereum governance model, so once there is a serious dispute in the client implementation, Vitalik’s personal opinion will make the final decision.

References

ZeroDev Introduction

null

https://docs.zerodev.app/blog/3074-governance

ZeroDev Introduction

null

https://docs.zerodev.app/blog/4337-and-3074-disagreements

Notes on the Account Abstraction roadmap - HackMD

# Notes on the Account Abstraction roadmap *Special thanks to Vitalik and the AA team for feedback

https://notes.ethereum.org/@yoav/AA-roadmap-May-2024