Author: shew

Overview

In the Pectra escalation, the most complex governance disputes arise. When EIP3074 was included in the Pectra upgrade, it caused great debate, especially the opposition from the team from ERC4337.

EIP3074 is in trouble and the governance process cannot continue. Until Vitalik raised EIP7702 and ended the ERC4337 team's doubts about EIP3074.

GCC Research found that governance issues for EIP3074 and ERC7702 in Pectra upgrades are rarely discussed in the Chinese world. However, this governance issue also reflects the deep-seated problem of Ethereum governance, that is, who can control the specific content of code under the premise of code is law. 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 reprinted 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 conform to the Ethereum values ​​(Value), and then the proposal should be reflected in the Vitalik design vision (Vision), and the final proposal should be reflected in the Roadmap (Roadmap), and finally the core developers will include it in the client implementation after discussion.

The EIP2537 introduced by GCC Research in the previous article only had an implementation problem at the Client level, resulting in the final delay in joining the hard fork, while the EIP3074 was not included in the hard fork due to the Vision and Roadmap problems. The core Ethereum developers directly chose EIP7702 written by Vitalik as the final account abstract proposal.

Overview of the proposal content

Before introducing the specific governance process, we need to briefly introduce the specific contents of this article involving EIP3074, EIP7702 and ERC4337.

EIP3074 is an execution layer proposal, and node software upgrade is required to execute the proposal. The core purpose of EIP3074 is to implement gas selling and bulk transaction functions. 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 abstract proposals that allow changes to signature verification algorithms, EIP3074 does not allow users to use any signature algorithm other than secp256k1. In other words, EIP3074 is not a proposal that satisfies all account abstract functions. This is also the point that EIP3074 has been criticized.

To achieve the expected goals, EIP3074 introduces two opcodes, namely AUTH and AUTHCALL. The AUTH opcode can pass the signature verification. After the signature verification is passed, the opcode will be configured as the authorized address of the signer in the current EVM context. When the authorized in the context is configured, AUTHCALL can initiate the transaction using the authorized address as the msg.sender that calls the transaction. To some extent, users can sign their account to a smart contract for use in a transaction. We generally call this smart contract entrusted by the user an invoker contract.

So what is the specific signature of the user? The user needs to sign the following:

The invoker address in the above content refers to the invoker contract address the user wants to entrust. The EVM will verify whether the user's signature content is consistent with the contract that truly verifies the signature, so as to avoid the user's AUTH signature content being used by other contracts.

And nonce is an identifier that prevents transaction replay. However, when you need to pay attention, the AUTH opcode will verify whether the nonce in the signature is consistent with the nonce of the currently signed EOA. Theoretically, as long as the user does not initiate a transaction using the EOA account 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, meaning that users using EIP3074 must trust the relay service provider that has obtained the signature. If the relay service provider that obtains the user's signature is malicious, the service provider may replay the user's AUTH signature at a certain moment to steal user assets.

Another security issue is the commit field. The commit field is used to ensure that certain operations are performed, and users can fine-grainedly control their signature permissions within commit, such as writing some content in commit to avoid their signature content being used for ETH transfer. In the EIP3074 document, the proposer gives a series of examples of using the commit field. But the problem is that the role of commit depends entirely on the definition of smart contracts, and is essentially an optional content. Different smart contracts may have completely inconsistent parsing content in commit, and some contracts may even not read content in commit at all. If users want to use EIP3074 safely, they must simply review the smart contract by themselves.

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

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

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

EIP7702 is a proposal proposed by Vitalik to replace EIP3074. Instead of introducing a new EVM opcode, the proposal introduces a new transaction type called SET_CODE_TX_TYPE. Once the user initiates an EIP7702 type transaction, the user can add the function of the smart contract while retaining the basic functions of the EOA. Simply put, users can continue to initiate transactions using wallets such as MetaMask, or other users can call EOA addresses in the form of smart contracts.

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

From a technical perspective, the transaction type introduced by EIP7702 has added an authorization_list list compared to traditional transactions. The specific content in this list is [[chain_id, address, nonce, y_parity, r, s], ...]. where address is the smart contract address the user wants to delegate, and nonce is the user's current nonce value. The remaining y_parity, r and s are all user signature results. During the specific execution process, we will first traverse each item in authorization_list for processing. The processing method is to restore the EOA address through signature parameters such as y_parity, and then point the EOA address to a smart contract with address 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 most 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 explorations and reuse existing infrastructure in the current field of account abstraction, such as EIP7702 can directly use ERC4337's infrastructure. Currently, ERC4337 has launched EntryPoint v0.8 that supports EIP7702 calls. From the perspective of reusing existing infrastructure, EIP7702 is the same as ERC4337.

Of course, EIP7702 does not actually completely fix the problems that occur in EIP3074. Most of the problems that exist in EIP3074 still exist. EIP7702 requires that the account contract be implemented safely, and the agreement itself does not guarantee any security. In the early days of EIP7702, some developers proposed to standardize signature nonces to avoid possible replay attacks, but EIP7702 did not accept these suggestions in the end. So if the user wants to use EIP7702 safely, then the user needs to review the contract security by himself.

At the same time, EIP7702 will also bring a series of problems to the execution layer. In the above we have introduced a possible approach to leveraging EIP3074 to perform DoS attacks on execution layer memory pools. 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.

To sum up, the biggest problem with EIP3074 is that EIP3074 does not implement the complete account abstraction function, while EIP7702 implements the complete account abstraction function. And what defines what "full account abstraction" contains is the author of ERC4337. After reading this, readers should be able to understand why EIP3074 was opposed by the ERC4337 team and was finally replaced by EIP7702. We will introduce the entire process of overall governance and discussion in the following text.

Governance process for EIP3074 and EIP7702

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

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

What's more interesting is that Vitalik believed in this meeting that Ethereum needs a technical solution to generate multiple calls for a transaction designed for EOA. Although there are possible security problems in EIP3074, EIP3074 provides a possible technical solution, and developers need to move forward based on EIP3074.

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

In Meeting #115 on June 11, 2021, EIP3074 developers submitted a report on security audits, and the meeting focused on the security issues of EIP3074. A simple conclusion is that the EIP3074 invoker contract is very important within 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 is also some discussion about whether some contracts use msg.sender == tx.origin to make the EOA judgment. When EIP3074 is introduced, these judgments will be invalid, but the conclusion is that the invalidity of this part of the judgment will not cause serious security problems. In short, the conference was mainly about the EIP3074 proposer introducing the security audit results of 3074 to the core developers. The final conclusion of the meeting was that 3074 also needs to consider the invoker contract issue, and it is recommended not to join in the London hard fork.

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

The author of EIP3074 at the meeting here responded to Yova's submission:

1. I hope to include the invoker contract address in the EIP specification, and then write a secure invoker contract by Ethereum core developers to avoid security issues
2. Regarding the content of commit in signatures, EIP3074 developers believe that this is entirely a problem for users and wallet software, and does not require specifications within the EIP.

Vitalik put forward the following three points in this meeting:

1. EIP3074 still uses the traditional secp256k1 signature scheme that cannot achieve quantum resistance.
2. EIP3074 Without future compatibility, using EIP3074 cannot make an EOA evolve into a smart contract account
3. EIP3074 has limited life cycle. 3074 introduced two pre-assembled codes, AUTH and AUTHCALL, but according to the account abstract roadmap, all wallets in Ethereum may be smart contract wallets in the future. The pre-assembled code of EIP3074 will be abandoned in the future.

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

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

Developers discussed in detail whether EIP3074 should be included in the Pectra upgrade on February 29, 2024. Vitalik proposes any account abstraction standard that requires the following three functions:

1. Key rotation
2. Key deprecation
3. Compatible with anti-quantum signatures

Vitalik's decision to point out that EIP5806 may be a better choice than EIP3074. Andrew believes that EIP3074 is more general than EIP5806, so it is recommended to use EIP3074. Vitalik refuted Andrew, who believes that all wallets in the future may be smart contract wallets. Once this happens, the pre-assembled opcode introduced by EIP3074 will be invalid. Yoav, as the author of ERC4337, made a long speech at this meeting, and his speech mainly included:

1. EIP3074 may lead to DoS attacks on Ethereum memory pools, while ERC4337 conducts a lot of research on this part and gives some rules to avoid attacks.
2. EIP3074 requires signing twice when a user initiates a batch transaction, which is unreasonable
3. EIP3074 requires the use of a centralized repeater

Yova prefers to use EIP5806 as an account abstraction solution.

Within the Meeting #183 meeting on March 14, 2024, the core developers invited MetaMask's Dan Finlay to discuss what the wallet thinks about EIP3074. Dan is up against EIP3074, and points out that MetaMask will also support EIP3074 testing. MetaMask believes that EIP3074 can enable EOA to enjoy all the functions of account abstraction. In terms of security, EIP3074 provides a solution for wallet service providers, namely, separation of hot and cold keys. The wallet service provider can hold the EOA's EIP3074 signature to initiate transactions. Users can use hot private keys in normal transactions, but the cold private keys can be stored in the user's hardware wallet. When an emergency occurs, the user can use the cold private keys in the cold wallet to initiate transactions to revoke the signature of EIP3074. This solution of hot and cold private key separation brings flexibility to wallet providers.

Vitalik pointed out that within EIP3074, wallet designers must design strict authorization logic to avoid abuse of user EIP3074 signatures. Interestingly, when discussing MetaMask's addition of EIP3074 feature support, Vitalik pointed out that L2 can be used as a transitional solution, that is, any new execution layer modification should be pioneered within L2, because the L2 funding is limited, and even serious problems can cause serious losses.

Dror Tiros pointed out in the discussion that the best way to ensure EIP3074 is to directly give the invoker contract by Ethereum. But Dan Finlay opposes the official opinion on the contract. Dan believes that the invoker contract should be completely decided by the user, and the market will eventually choose the safest invoker contract.

Ansgar still insists that EIP3074 signing should only correspond to one transaction, and wallet service providers should not reuse user signatures to initiate transactions, but Dan Finlay also expressed objections. Dan Finlay believes that EIP3074 should be signed by a cold wallet, and the wallet service provider can reuse the signature and initiate transactions directly for the user. If the user is asked to resign each time, it may lead to the cold private key being used multiple times. This is inconsistent with the idea of ​​separation of hot and cold private keys.

In this conference, another important topic was the inclusion list. Including lists is a means to increase Ethereum's anti-censorship attributes. Simply put, the inclusion list allows some transactions to be promised to be included directly within the next block. But the core developers pointed out that EIP3074 is in conflict with the inclusion list.

Most client implementations within the Meeting #185 meeting on April 11, 2024 agreed that EIP3074 was added to the Pectra hard fork, but Geth opposed it because EIP3074 could cause problems with Verkle tree. Danno still objected because EIP3074 may have signature reuse. Yoav also expressed opposition, and Yoav gave a solution to attack the memory pool using EIP3074 and Blob transactions. Simply put, an attacker can initiate a large number of blob transactions, which contain a large amount of data, and then use EIP3074 to invalidate all of these blob transactions.

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

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

The possibility of EIP7702 replacing EIP3074 was discussed in the core development within Meeting #188 on May 23, 2024. The final conclusion of this meeting was to replace EIP3074 with EIP7702 as the account abstraction standard in the Pectra hard fork. Vitalik points out that EIP7702 also has some irrevocable properties consistent with EIP3074, and these properties have been discussed extensively in discussing EIP3074. What is more interesting is that there were a large number of representatives from ERC4337 participating in the speeches at the meeting.

In fact, the discussion on the replacement of EIP3074 by EIP7702 was widely discussed before 188 core developer meetings. The result of the discussion at that time was that 3074 would be replaced, so there was no large amount of disputes in the core developer meetings.

Roadmap and ruling

Account abstract core infrastructure Zerodev published an interesting article titled Reflections on Ethereum Governance Following the 3074 Saga, which concluded that EIP7702 is a good proposal that can make all users profitable. However, the governance process for EIP7702 replacing EIP3074 is not the best, for reasons including:

1. EIP3074 After a long discussion process, we have introduced many discussions on EIP3074 in the core developer meeting above.
2. EIP3074 was confirmed to be included in the Pectra upgrade and received a lot of opposition from the ERC4337 community. Of course, in the above, we have pointed out that yova, the core developer of ERC4337, has expressed his opposition to EIP3074 in core developer meetings many times.

Zerodev believes that the best governance path should be during the long core developer discussions in EIP3074 in the past, and the ERC4337 community should participate widely and express their opinions.

EIP3074 Developers believe that ERC4337 should be responsible for governance failures. Because EIP3074 has been actively involved 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 governance failure. ERC4337 community members believe that Yova, as the core developer of ERC4337, expressed opposition to EIP3074 in multiple core developer meetings, but the core developer does not seem to listen to the opinions. Most community members in ERC4337 do not pay attention to the governance dynamics of EIP3074, and most members believe that EIP3074 is a dead standard. The ERC4337 community also believes that the core developers do not actively communicate with the ERC4337 community.

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

Simply put, this deeper reason is actually Ethereum’s roadmap. The Ethereum roadmap has power over core developer meetings. The account abstract 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 Ethereum roadmap, it will definitely happen that EIP3074 is replaced.

Of course, the Ethereum roadmap is a personal display of Vitalik's vision for Ethereum's future. Once serious debate occurs during Ethereum's governance process, Vitalik, the roadmap definer, has the final right to ruling. It was Vitalik's ruling that caused EIP3074 to be replaced.

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

1. values ​​values, especially the values ​​of the community, and the values ​​of the Ethereum community include decentralization, censorship resistance, etc.
2. Vitalik's personal thoughts on the future of Ethereum
3. roadmaps roadmaps, the researcher gives some technical details based on his vision and gives a relatively complete implementation roadmap
4. clients client implementation, the core developers of the client use tools such as core developer meetings to discuss the roadmap and implement the requirements within the roadmap

The above process is the real governance process of Ethereum. We can see that Vitalik's personal vision is located at the bottom of the Ethereum governance model, so once there is serious debate within the client implementation, Vitalik's personal opinion will be finalized.

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