Summary of the latest meeting of Ethereum core developers: Preparing to implement EIP 3074 and the Rollup roadmap

Original Title: 《Ethereum All Core Developers Execution Call #186 Writeup》

Original Author: Christine Kim

Original Compiler: Frost, BlockBeats

Editor’s Note:

The Ethereum All Core Developers Execution (ACDE) call is held bi-weekly, primarily to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 186th ACDE call, during which developers discussed the preparations for Pectra Devnet 0 and the implementation of EIP 3074. They provided detailed updates on the progress of various client teams in preparing for Pectra Devnet 0 and discussed proposed modifications to the EIP 3074 specification as well as related testing progress.

Additionally, this article mentions other important topics, such as discussions on other code changes that may be included in the Pectra upgrade and how changes to the Ethereum EIP process are influenced by the L2/RIP process. Christine Kim, Vice President of Research at Galaxy Digital, took detailed notes on the key points of this meeting, and BlockBeats compiles the original text as follows:

On April 25, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #186. The ACDE call is a series of meetings held every two weeks, hosted by Tim Beiko, the Ethereum Foundation's Protocol Support Lead, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed the preparations for Pectra Devnet 0 and the implementation of EIP 3074. They also discussed which other EIPs should be considered for inclusion in the Pectra upgrade, taking into account the broader reflections on governance changes in light of Ethereum's "Rollup-centric roadmap."

Latest Progress on Pectra Devnet 0

Beiko asked client teams to share the latest progress on Pectra Devnet 0 during the call. Marek Moraczyński from the Nethermind team stated that Nethermind has implemented all Pectra EIPs and is currently testing them. Justin Florentine from the Besu team mentioned that Besu is implementing Pectra EIPs and preparing for the launch of Devnet 0. Andrew Ashikhmin from the Erigon team said, "I'm not sure if Erigon is ready for the full suite of EIPs for Devnet 0, partly because the specifications for these EIPs are still changing, and the Erigon client is transitioning to a new major version, Erigon 3, which is consuming the team's resources and time. Erigon 3 and the Pectra EIPs will be finalized and integrated into the Erigon client together." The Geth team's "Lightclient" indicated that Geth is "a few days away" from being ready for Devnet 0. Gajinder Singh from the Ethereum JS team stated that Ethereum JS will also be "ready for Devnet 0."

EIP -7685

Lightclient has merged EIP 7685, which creates a general framework for storing EL-triggered requests to the Consensus Layer (CL) and its implications for EIP 6110 and 7002. Beiko stated that developers should include this EIP in their Devnet 0 release and continue to refine the Pectra EIPs.

In terms of testing, Mario Vega from the EF testing team reported that testing for EIP 6110 and 2537 has been completed, and testing for EIP 7002 and EIP 2935 will be completed this week or next. Testing for EIP 3074 is not yet ready for Devnet 0. EF researcher Antonio Sanso mentioned that the EIP 2537 specification has been updated, and new test vectors have been added to the GitHub repository, encouraging everyone to check it out. EF researcher Hsiao Wei Wang pointed out that there was an error in the CL specification test vectors, which was quickly corrected, and a new version was released.

Updates on EIP -3074

This week's ACDE proposed several changes to the EIP 3074 specification. Ahmad Mazen Bitar suggested changing the behavior of EIP 3074 to allow DELEGATECALL before AUTH CALL, which would expand the use cases of the EIP. Derek Jiang, founder and CEO of blockchain wallet operating system ZeroDev, proposed creating a "noncemanager" to facilitate global revocation of AUTH messages and other changes when needed. Some developers participating in the call felt that changes to EIP 3074 should be postponed, as this would significantly increase the difficulty of its implementation.

Beiko suggested that developers discuss the proposed changes to EIP 3074 in a separate breakout meeting. He noted that to have enough time to implement EIP 3074 in Pectra, developers should aim to finalize its specification "within the next month or two." Lightclient agreed to organize a breakout meeting for EIP 3074. For Devnet 0, Beiko confirmed that client teams should implement EIP 3074 without any changes, even if developers may decide to implement EIP differently in future devnets or remove it entirely from the upgrade.

In addition to the implementation details of EIP 3074, developers also seriously discussed whether there is sufficient community support for the EIP. A developer with the screen name "Siri" expressed concerns during the call, stating, "EIP 3074 is fundamentally bad and will slow down our progress toward full account abstraction." Beiko responded that, based on discussions from Ethereum Magicians and ACD calls, client teams seem to support EIP 3074 rather than other proposals related to Account Abstraction (AA). Beiko stated, "This seems to be the most consensus-driven proposal in the short term, and we can actually improve the state of EOAs in the next fork." Siri countered that client teams should not make this decision in isolation. "We should listen to other stakeholders," Siri said, adding, "We don't want to venture into the territory of creating controversial hard forks… I think it's best to understand the perspectives of other stakeholders and how they view this proposal."

Beiko and Siri also discussed how to build broader consensus for the EIP outside of ACD calls. Chiang suggested first holding a breakout meeting for EIP 3074 to delve into the technical specifications of the EIP, and then decide whether it should be retained in the Pectra upgrade. EF researcher Ansgar Dietrichs stated, "We should understand that unless we make sufficient progress, EIP 3074 will be withdrawn."

Ethereum co-founder Vitalik Buterin added, "The account functionalities for users are about to change in the coming years, especially for externally owned accounts (EOAs). Activating account abstraction-related EIPs, such as EIP 3074, is essential."

Other Pectra Proposals

Developers continued to discuss which other code changes should be considered for inclusion in the Pectra upgrade. Geth developer Marius van der Wijden stated that this should depend on whether more complex EIPs like EOF will enter Pectra. "If we include EOF, it will lead to fork saturation. If we don't include EOF, maybe we can include more," van der Wijden said.

Siri expressed concerns about including EIP 3074 in Pectra without a security audit. Beiko suggested postponing this discussion until the specification for EIP 3074 is finalized.

Bitar expressed his hope to see EIP 7212 added to Pectra. EIP 7212 would create a new precompile for signature verification in the secp256r1 elliptic curve. This could be used with hardware devices that support user biometric identification. Bitar stated that supporting biometrics for signing Ethereum transactions would be a significant improvement in user experience. Ashikhmin also expressed support for this proposal. Dietrichs pointed out that this is the only proposal approved for implementation by Layer-2 Rollups through the "Rollup Improvement Proposal" (RIP) process.

Other developers, including Dietrichs, van der Wijden, and Moraczyński, expressed support for EIP 7623, which would increase the cost of call data, thereby limiting the maximum block size. Beiko suggested marking EIP 7623 and EIP 7212 as "consider for inclusion" or CFI for Pectra, and revisiting the client teams' bandwidth to support these two improvement proposals after the launch of Devnet 0.

Regarding the EIP bundle related to updating the serialization method of the EL to SSZ, van der Wijden expressed concerns that these would be too difficult to transport in Pectra. His colleague from the Geth team, Guillaume Ballet, agreed with this assessment. Buterin interjected, "At least updating the serialization method of transaction receipts will have significant value beyond Ethereum itself, as it eliminates the additional security audit overhead for Layer-2 Rollups built on Ethereum." The main supporter of the SSZ-related EIPs, Etan Kissling from the Nimbus team, was not present at the call, but he wrote a detailed explanation on GitHub about why these code changes are important and should be considered for inclusion in Pectra.

Developers also revisited discussions on EOF. Independent Ethereum protocol developer Danno Ferrin stated that the EOF team is conducting EL specification testing for code changes. EVMOne and Reth are two EL client teams that have reportedly completed EOF implementation. Ferrin noted that the Geth team has made "good progress" on implementation. Ferrin added that Ballet is working with "Daniel" from the Solidity team to address concerns about EOF and Verkle compatibility.

Ballet pointed out that based on his conversations with Daniel and other developers like Dietrichs, it is challenging to narrow the scope of EOF without undermining its purpose and creating more work for developers to implement another set of similar EOF code changes in the future.

A developer with the screen name "Charles C" suggested looking for a way to iteratively implement EOF through a Side Car mechanism (such as a mechanism for Blob transactions) rather than choosing between small or large EOF upgrades. Dietrichs asked in the chat whether client teams would be more interested in EOF if its complexity were reduced. The Ipsilon team noted that the code changes causing the highest complexity in EOF (such as "TX create") have already been addressed, and specific requests to remove features like "EOF create" would not significantly reduce the overall complexity of EOF. For context, Ipsilon is the name of the EF-funded EVM research and development team. Beiko suggested that developers continue to discuss EOF implementation in recurring EOF breakout discussions.

ACD / EIP and L2 / RIP

As the final topic of discussion in ACDE #186, developers discussed how the consideration of the new RIP process affects changes to the Ethereum EIP process. Dietrichs noted that it has been six months since developers initiated the series of meetings for Rollup coordination, RollCall, and the RIP process. There are still some unresolved questions about how these processes will and should influence the Ethereum EIP process. Dietrichs stated that one ongoing research question in L2 is whether long-term equivalence with the Ethereum Virtual Machine (EVM) is desirable for Rollups. He also added that one unresolved question is to what extent changes implemented on L2 will ultimately affect protocol decisions on Ethereum Layer 1.

Geth developer Péter Szilágyi stated that certain functionalities offered on L2 may not be suitable for L1, and in some cases, even if following the functionalities provided on L2, there may be differences between L2s, which could confuse Ethereum protocol developers. EF researcher Carl Beekhuizen pointed out that RollCalls and the RIP process do not require Ethereum protocol developers to release any functionalities on L2, but rather improve communication between Rollups and Ethereum developers to avoid the confusing situations described by Szilágyi. Van der Wijden expressed concern about protocol developers spending time supporting changes implemented on L2 that may ultimately become outdated or unnecessary as L2 itself shuts down or ceases to be used.

In response to these concerns, Dietrichs stated, "I think people have always thought Layer 2 could experiment and become more radical. What we see in practice is that most of them decide not to do so, or at least may start doing so, and then over time, most stop. So now they are primarily following Layer 1 specifications. I think at least considering the Rollup-centric roadmap, or what we all think is the best way for the ecosystem to evolve, we at least owe Layer 2 clear guidance and communication on what the best way forward is here."