Author: shew

Overview

In the Pectra upgrade, the most complex governance dispute arose. After EIP3074 was included in the Pectra upgrade, it sparked significant controversy, particularly from the ERC4337 team.

EIP3074 became mired in difficulties, and the governance process could not proceed. It wasn't until Vitalik proposed EIP7702 that the ERC4337 team's doubts about EIP3074 were resolved.

GCC Research found that there has been little discussion in the Chinese community regarding the governance issues of EIP3074 and ERC7702 in the Pectra upgrade. However, this governance issue also reflects a deeper problem in Ethereum governance, namely, under the premise of "code is law," who can control the specific content of the code. The governance issues surrounding EIP3074 and ERC7702 provide us with a valuable perspective to observe the true governance processes within Ethereum.

The final conclusion of this article is a paraphrase of a commentary published by ZeroDev, which points out that the Ethereum governance system follows the VVRC model. Any proposal must first align with Ethereum's values (Value), then the proposal should reflect the vision designed by Vitalik (Vision), and finally, the proposal should be incorporated into the roadmap (Roadmap). After discussions among core developers, it will be included in the client (Client) implementation.

In the previous article, GCC Research introduced EIP2537, which faced implementation issues at the Client level, leading to its delayed inclusion in the hard fork. In contrast, EIP3074 was ultimately not included in the hard fork due to Vision and Roadmap issues, and Ethereum core developers directly chose Vitalik's EIP7702 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 that requires node software upgrades to implement. The core purpose of EIP3074 is to achieve gas sponsoring and batch transaction functionality. Gas sponsoring refers to the ability for users to pay gas fees using any token or to pay gas fees offline. However, it is important to note that, unlike other account abstraction proposals that allow changes to the signature verification algorithm, EIP3074 does not permit users to use any signature algorithm other than secp256k1. In other words, EIP3074 is not a proposal that satisfies all account abstraction functionalities, which is a point of criticism against EIP3074.

To achieve its intended goals, EIP3074 introduces two opcodes: AUTH and AUTHCALL. The AUTH opcode can verify signatures, and once the signature verification passes, this opcode will configure the authorized address in the current EVM context to the signer's address. After configuring the authorized address in the context, AUTHCALL can use the authorized address as the msg.sender to initiate transactions. To some extent, users can delegate their accounts to a smart contract for use in a transaction through signatures. We generally refer to this delegated smart contract as the invoker contract.

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

In the content above, the invoker address refers to the address of the invoker contract that the user wishes to delegate. The EVM will verify whether the user's signed content matches the contract that actually verifies the signature, preventing the user's AUTH signature from being used by other contracts.

The nonce is an identifier that prevents transaction replay. However, it is important to note that the AUTH opcode will check whether the nonce in the signature matches the nonce of the current EOA. Theoretically, as long as the user does not initiate a transaction with the EOA account to increase the nonce value, the AUTH signature issued by the user can be continuously used by the invoker contract. This presents a significant security vulnerability, meaning that users utilizing EIP3074 must trust the relay service provider that obtains the signature. If the relay service provider that obtains the user's signature is malicious, it could replay the user's AUTH signature at some point to steal the user's assets.

Another security issue lies in the commit field. The commit field is used to ensure certain operations, allowing users to finely control their signature permissions within the commit, such as writing content to prevent their signature from being used for ETH transfers. In the EIP3074 documentation, the proposer provides a series of examples utilizing the commit field. However, the problem is that the function of commit entirely relies on the smart contract's definition, essentially making it an optional content. Different smart contracts may interpret the content of the commit differently, and some contracts may not read the content of the commit at all. If users wish to use EIP3074 securely, they must conduct a simple review of the smart contract themselves.

Finally, we introduce the impact of EIP3074 on the current Ethereum transaction memory pool. After the introduction of EIP3074, a potential attack method against the memory pool may arise, where hackers can initiate transactions using a large number of accounts and then, just before the transactions are packaged, use EIP3074 transactions to drain the ETH from these accounts in one go, causing all previously initiated transactions to fail. This attack method could significantly impact execution layer nodes, essentially constituting a DoS attack. However, it is important to note that the EIP7702 proposed as a replacement for EIP3074 also encounters this issue, but EIP7702 introduces certain restrictions to prevent this problem, which we will discuss later.

In addition to the issues inherent in EIP3074, Yova, the author of ERC4337, presented more opposing views in the article "Implications of EIP-3074 inclusion." In summary, 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. Additionally, the infrastructure built by current account abstraction protocols like ERC4337 is completely incompatible with EIP3074.
2. User security. As mentioned above, EIP3074 lacks a unified design for permission control, and the design of the signature nonce also poses security risks, which could lead to serious security issues.
3. Incomplete account abstraction functionality. Compared to other account abstraction proposals, EIP3074 is incomplete and cannot achieve functionalities such as changing the user's signature algorithm.
4. User experience issues. When users need to delegate their accounts to a smart contract, they must perform an AUTH signature and then publish a call containing the AUTH signature on-chain. Users need to sign twice.

EIP7702 is a proposal put forward by Vitalik to replace EIP3074. This proposal does not introduce new EVM opcodes but instead introduces a new transaction type called SETCODETX_TYPE. Once a user initiates a transaction of type EIP7702, they can enhance the functionality of their EOA while retaining the basic functions of the EOA. In simple terms, users can continue to initiate transactions using wallets like MetaMask or allow other users to call the EOA address in the form of a smart contract.

We will introduce the functionality of EIP7702 with a simple example of batch transactions. Users can use EIP7702 to delegate their EOA address to a smart contract capable of executing batch calls, allowing users to directly call their EOA address to initiate batch transactions in the form of a smart contract.

From a technical implementation perspective, the transaction type introduced by EIP7702 adds an authorizationlist, which contains specific content of [[chainid, address, nonce, yparity, r, s], …]. Here, address is the smart contract address that the user wishes to delegate, and nonce is the user's current nonce value. The remaining yparity, r, and s are the user's signature results. During the execution process, we will first iterate through each item in the authorizationlist for processing, where the method involves recovering the EOA address using the signature parameters like yparity, and then directing the EOA address to the smart contract at the address specified. After that, the EOA address can accept calls and utilize the contract's functionality.

The advantages of EIP7702 are very clear, with the most core advantage being that EIP7702 essentially allows the EOA to possess smart contract functionality. This aligns with the basic rules of account abstraction like ERC4337, meaning that EIP7702 can leverage all existing explorations in the account abstraction field and reuse existing infrastructure. For example, EIP7702 can directly utilize the infrastructure of ERC4337, which has already launched EntryPoint v0.8 supporting EIP7702 calls. From the perspective of reusing existing infrastructure, EIP7702 has an equivalent degree of decentralization as ERC4337.

Of course, EIP7702 does not completely resolve the issues present in EIP3074. Most of the problems found in EIP3074 still exist. EIP7702 requires account contracts to have secure implementations, while the protocol itself does not guarantee any security. In the early proposals of EIP7702, some developers suggested standardizing the signature nonce to avoid potential replay attacks, but EIP7702 ultimately did not accept these suggestions. Therefore, if users wish to use EIP7702 securely, they will need to review the security of the contracts themselves.

At the same time, EIP7702 will also bring a series of issues to the execution layer. As mentioned earlier, there is a potential method to utilize EIP3074 for a DoS attack on the execution layer memory pool. This method is also effective for EIP7702. Therefore, EIP7702 suggests that all EOA addresses using EIP7702 should 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 complete account abstraction functionality, while EIP7702 achieves complete account abstraction functionality. The definition of what constitutes "complete account abstraction" is provided by the authors of ERC4337. By this point, readers should understand why EIP3074 was opposed by the ERC4337 team and ultimately replaced by EIP7702. We will introduce the entire governance and discussion process later.

Governance Process of EIP3074 and EIP7702

EIP3074 was mentioned very early in Ethereum core developer meetings. In Meeting #109 on April 2, 2021, Ethereum core developers had a brief discussion about EIP3074. The discussion results were quite simple:

1. Alexey pointed out that the signature content of EIP3074 poses security risks that could lead to serious security losses for users, suggesting that EIP3074 further standardize the specific content of AUTH signatures, a proposal supported by Martin.
2. James raised concerns that EIP3074 might introduce potential vulnerabilities in the execution layer, such as DoS attacks, and suggested that EIP3074 provide a written threat analysis.
3. Alexey and Martin complained about the general quality of the EIP3074 documentation, which took a lot of time to read and understand.
4. Martin believed that the core of EIP3074 lies in collaboration and implementation with applications, especially wallet developers, and the authors of EIP3074 stated that they had engaged in a series of communications with application developers.

Interestingly, Vitalik believed in this meeting that Ethereum needs a technical solution that generates multiple calls for a single transaction designed for EOA, regardless of the potential security issues with EIP3074. Although EIP3074 has possible security problems, it provides a potential technical solution, and developers need to move forward based on EIP3074.

Clearly, due to the security issues with EIP3074, it was not included in the London upgrade during this meeting.

In Meeting #115 on June 11, 2021, the developers of EIP3074 submitted a report on security audits, and the meeting mainly discussed the security issues of EIP3074. A simple conclusion was that the invoker contract of EIP3074 is very important within the system, so whether to manage the invoker contract is a question. The developers of EIP3074 hoped to formalize the invoker contract to increase security.

Of course, there was also some discussion about whether certain contracts using msg.sender == tx.origin to determine if the calling address is an EOA would become invalid once EIP3074 is introduced, but the conclusion was that the invalidation of these checks would not lead to serious security issues. In short, this meeting was primarily about the proposer of EIP3074 presenting the security audit results to the core developers. The final conclusion of the meeting was that EIP3074 still needs to consider the invoker contract issue and it was recommended not to include it in the London hard fork.

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

In this meeting, the authors of EIP3074 responded to Yova's submitted materials:

1. They hoped to include the invoker contract address in the EIP specification and then have Ethereum core developers write a secure invoker contract to avoid security issues.
2. Regarding the content of the commit in the signature, the developers of EIP3074 believed that this is entirely a matter for users and wallet software and does not need to be standardized in the EIP.

Vitalik raised the following three points in this meeting:

1. EIP3074 still uses the traditional secp256k1 signature scheme, which cannot achieve quantum resistance.
2. EIP3074 lacks future compatibility, and using EIP3074 does not allow an EOA to evolve into a smart contract account.
3. EIP3074 has a limited lifecycle. EIP3074 introduces two precompiled codes, AUTH and AUTHCALL, but according to the roadmap for account abstraction, all wallets in Ethereum may become smart contract wallets in the future, and the precompiled codes introduced by EIP3074 will be deprecated.

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 developers only briefly synchronized the development dynamics of EIP3074. Notably, before the meeting began, Nethermind wrote an article titled "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337," which did not include opposing views on EIP3074.

In Meeting #167 on August 3, 2023, core developers mentioned EIP3074 while discussing another EIP5806. EIP5806 is a proposal that allows EOAs to call external contracts using delegate call during transactions. This solution is somewhat similar to EIP7702. However, core developers also raised concerns about the security of this proposal, with Ansgar pointing out that EIP3074 has been unable to be included in hard forks due to potential security issues, and EIP5806 is a more radical proposal.

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

1. Key rotation
2. Key deprecation
3. Compatibility with quantum-resistant signatures

Vitalik pointed out that EIP5806 might be a better choice than EIP3074. Andrew believed that EIP3074 is more general compared to EIP5806 and suggested using EIP3074. Vitalik countered Andrew, arguing that in the future, all wallets may become smart contract wallets, and once this happens, the precompiled opcodes introduced by EIP3074 will become ineffective. Yoav, as the author of ERC4337, gave a lengthy speech in this meeting, mainly including:

1. EIP3074 could lead to DoS attacks on the Ethereum memory pool, while ERC4337 has conducted extensive research on this and provided some rules to avoid such attacks.
2. EIP3074 requires users to sign twice when initiating batch transactions, which is unreasonable.
3. EIP3074 requires the use of centralized relayers.

Yova is more inclined to use EIP5806 as the account abstraction solution.

In Meeting #183 on March 14, 2024, core developers invited Dan Finlay from MetaMask to discuss the wallet's views on EIP3074. Dan expressed support for EIP3074 and pointed out that MetaMask would also provide support for testing EIP3074. MetaMask believes that EIP3074 can allow EOAs to enjoy all the functionalities of account abstraction. In terms of security, EIP3074 provides a solution for wallet service providers, namely cold and hot key separation. Wallet service providers can hold the EIP3074 signature of the EOA to initiate transactions, while users can use their hot private keys for normal transactions, but the cold private key can be stored in the user's hardware wallet. In case of an emergency, users can use the cold private key in the cold wallet to initiate a transaction to revoke the EIP3074 signature. This cold and hot key separation solution provides flexibility for wallet providers.

Vitalik pointed out that in EIP3074, wallet designers must design strict authorization logic to prevent the misuse of users' EIP3074 signatures. Interestingly, when discussing the addition of EIP3074 functionality support in MetaMask, Vitalik suggested using L2 as a transitional solution, meaning that any new execution layer modifications should first be practiced in L2, as the capital volume in L2 is limited, and even if serious problems occur, it would not lead to significant 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 the invoker contract. However, Dan Finlay opposed the idea of the official providing the contract, believing that the invoker contract should be entirely determined by users, and the market will ultimately choose the safest invoker contract.

Ansgar still insisted that a single signature for EIP3074 should correspond to only one transaction, and wallet service providers should not reuse user signatures to initiate transactions. However, Dan Finlay also expressed opposing views. Dan Finlay believed that EIP3074 should be signed by cold wallets, and then wallet service providers could reuse that signature to directly initiate transactions for users. If users are required to re-sign each time, it may lead to the cold private key being used multiple times, which contradicts the idea of cold and hot key separation.

In this meeting, core developers discussed another important topic: the inclusion list. The inclusion list is a means to enhance Ethereum's anti-censorship properties. In simple terms, the inclusion list allows certain transactions to be promised to be directly included in the next block. However, core developers pointed out that EIP3074 is in conflict with the inclusion list.

In Meeting #185 on April 11, 2024, most client implementations agreed to include EIP3074 in the Pectra hard fork, but Geth expressed opposition, citing potential issues with the Verkle tree. Danno also opposed it, as EIP3074 could lead to signature reuse. Yoav voiced his opposition as well, presenting a method to attack the memory pool using EIP3074 and Blob transactions. In simple terms, an attacker could initiate a large number of Blob transactions, each containing a significant amount of data, and then use EIP3074 to invalidate all these Blob transactions.

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

In Meeting #187 on May 9, 2024, core developers discussed for the first time the issue of EIP7702 replacing EIP3074. EIP7702 was completed just 90 minutes before the core developer meeting began. During the meeting, core developers recognized EIP7702 as a superior standard compared to EIP3074. There were no opposing voices regarding EIP7702 in this meeting, although some researchers noted that EIP7702 also has similar irrevocable properties to EIP3074, which could lead to security issues with funds.

In Meeting #188 on May 23, 2024, core developers discussed the possibility of EIP7702 replacing EIP3074. 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 possesses some irrevocability characteristics consistent with EIP3074, which had already been extensively discussed during the discussions on EIP3074. Interestingly, there were many representatives from ERC4337 participating in the discussions during this meeting.

In fact, the discussion about EIP3074 being replaced by EIP7702 had been widely discussed even before the 188th core developer meeting, and the outcome of those discussions was that EIP3074 would be replaced, so there was not much contention during the core developer meeting.

Roadmap and Judgment

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

1. EIP3074 underwent a lengthy discussion process, as we have already introduced in the previous text regarding the multiple discussions of EIP3074 in core developer meetings.
2. After EIP3074 was confirmed to be included in the Pectra upgrade, it received significant opposition from the ERC4337 community. Of course, as mentioned earlier, Yova, the core developer of ERC4337, has repeatedly expressed his opposition to EIP3074 in core developer meetings.

Zerodev believes that the best governance path should have involved broad participation and expression of opinions from the ERC4337 community during the lengthy core developer discussion process regarding EIP3074.

The developers of EIP3074 believe that ERC4337 should be held responsible for the governance failure, as EIP3074 has actively participated in governance over the past few years and has communicated multiple times with Yova, the core developer of ERC4337.

On the other hand, the ERC4337 community believes that EIP3074 should bear the primary responsibility for the governance failure. Members of the ERC4337 community argue that Yova, as the core developer of ERC4337, expressed opposition to EIP3074 in several core developer meetings, but the core developers seemed not to heed those opinions. Most members of the ERC4337 community did not pay attention to the governance dynamics of EIP3074, and many believed that EIP3074 was a dead standard. The ERC4337 community also felt that core developers did not actively communicate with the ERC4337 community.

Both EIP3074 and ERC4337 believe they have conducted proper governance work, while the other side should bear the primary responsibility for the governance failure. Clearly, there is a deeper underlying reason at play in this governance process.

In simple terms, this deeper underlying reason is actually the Ethereum roadmap. The Ethereum roadmap holds authority above the core developer meetings. The roadmap for account abstraction is centered around ERC4337. EIP7702 is fully compatible with the ERC4337 standard, while EIP3074 does not fully comply with the ERC4337 standard. Therefore, from the perspective of the Ethereum roadmap, the replacement of EIP3074 was bound to happen.

Of course, the Ethereum roadmap is a reflection of Vitalik's personal vision for the future of Ethereum. If serious disputes arise during the governance process of Ethereum, Vitalik, as the definitor of the roadmap, holds the final decision-making power. It was precisely Vitalik's judgment that led to the replacement of EIP3074.

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

1. values: values, especially the values of the community, including decentralization, anti-censorship, etc.
2. vision: essentially Vitalik's personal thoughts on the future of Ethereum.
3. roadmaps: researchers provide a more complete implementation roadmap based on the vision, detailing some technical considerations.
4. clients: core developers of clients discuss the roadmap using tools like core developer meetings and implement the requirements outlined in the roadmap.

This process is the true governance process of Ethereum. We can see that Vitalik's personal vision is at the foundational level of the Ethereum governance model, so once serious disputes arise within client implementations, Vitalik's personal opinion will serve as the final judgment.

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。