Summary of the latest Ethereum core developer meeting: Preparing to implement EIP 3074, Rollup roadmap

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

Original author: Christine Kim

Original translation: Frost, BlockBeats

Editor's note:

The Ethereum All Core Developers Consensus Call (ACDE) is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 186th ACDE call, during which developers discussed preparations for Pectra Devnet 0 and EIP 3074 implementation. They detailed the progress of various client teams in preparing for Pectra Devnet 0, and discussed proposed changes to the EIP 3074 specification and related testing progress.

In addition, the article also 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 affected by the L2/RIP process. Christine Kim, vice president of research at Galaxy Digital, took a detailed note of the key points of this meeting, and BlockBeasts compiled 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 biweekly series of meetings hosted by Tim Beiko, head of protocol support at the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed preparations for Pectra Devnet 0 and the implementation of EIP 3074. They also discussed what other EIPs should be considered for inclusion in the Pectra upgrade, as well as broader thinking about governance changes given Ethereum's "Rollup-centric roadmap."

Pectra Devnet 0 Latest Progress

Beiko asked the client teams on the call to share the latest progress on Pectra Devnet 0. Marek Moraczyński from the Nethermind team said that Nethermind has implemented all Pectra EIPs and is working on testing them. Justin Florentine from the Besu team said that Besu is implementing Pectra EIPs and working with them to prepare for the launch of Devnet 0. Andrew Ashikhmin from the Erigon team said, "I am not sure if Erigon is ready for the full suite of Devnet 0 EIPs, partly because the specifications for these EIPs are still in flux and the Erigon client is transitioning to a new major version, Erigon 3, which is taking up resources and time from the team. Erigon 3 and Pectra EIPs will be finalized and built into the Erigon client together.". "Lightclient" from the Geth team said that Geth is "a few days away" from being ready for Devnet 0. Gajinder Singh of the EthereumJS team said Ethereum JS will also be "ready" for Devnet 0.

EIP-7685

Lightclient merges EIP 7685, which creates a common framework for storing EL-triggered requests to the consensus layer (CL) and its impact on EIP 6110 and 7002. Beiko said developers should incorporate this EIP in their Devnet 0 releases and continue to improve the Pectra EIP.

On the testing side, Mario Vega of the EF testing team said that testing of EIP 6110 and 2537 has been completed, and testing of EIP 7002 and EIP 2935 will be completed this week or next. Testing of EIP 3074 is not yet ready for Devnet 0. EF researcher Antonio Sanso said that the EIP 2537 specification has been updated and new test vectors have been added to the GitHub repository. He suggested that everyone go to GitHub to have a look. EF researcher Hsiao Wei Wang pointed out that there was an error in the CL specification test vector, so the error was quickly corrected and a new version was released.

Updates on EIP-3074

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

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

In addition to the implementation details of EIP 3074, developers also seriously discussed whether EIP has enough community support. A developer named "Siri" expressed concern in the conference call that "EIP 3074 is bad in principle and will slow down our implementation of full account abstraction." Beiko responded that according to the Ethereum Magician and ACD call discussions, the client team seemed to support EIP 3074 instead of other proposals related to account abstraction (AA). "This seems to be the most consensus proposal in the short term, and we can actually improve the state of EOA in the next fork," Beiko said. In response, Siri believes that the client team should not make this decision in isolation. “We should listen to other stakeholders,” Siri said, adding, “We don’t want to veer into contentious hard fork territory. … I think it’s good to understand what other stakeholders think and how they view this proposal.”

Beiko and Siri also discussed how to build a broader consensus for EIPs outside of the ACD call. Chiang suggested first holding a breakout meeting for EIP 3074 to discuss the EIP’s technical specifications in depth and then decide whether it should remain in the Pectra upgrade. EF researcher Ansgar Dietrichs said “We should understand that unless we make enough progress, EIP 3074 will be withdrawn.”

Ethereum co-founder Vitalik Buterin added that "there are changes coming to the functionality of users' accounts in the coming years, specifically externally owned accounts (EOA). Activate EIPs related to account abstraction, such as EIP 3074, etc."

Other Pectra Proposals

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

Siri expressed concern about the inclusion of EIP 3074 in Pectra without a security audit. Beiko suggested putting this discussion on hold until the specification of EIP 3074 is finalized.

Bitar said he would like to see EIP 7212 added to Pectra. EIP 7212 would create a new precompile that performs signature verification in the secp256r1 elliptic curve. This could be used with hardware devices that support user biometrics. Bitar said supporting biometrics to sign Ethereum transactions would be a major improvement in user experience. Ashhemmin said he was also in favor of the proposal. Dietrichs noted that this is the only one that has been approved for implementation by Layer-2 Rollups through the "Rollup Improvement Proposal" (RIP) process.

Other developers including Dietrichs, van der Wijden, and Moraczyński have expressed support for EIP 7623, which would increase the cost of call data and thus limit the maximum block size. Beiko suggested marking EIP 7623 and EIP 7212 as “considered for inclusion” or CFI into Pectra, and revisiting the bandwidth of client teams to support both improvement proposals after Devnet 0 launches.

Regarding the EIP bundle related to updating EL’s serialization method to SSZ, van der Wijden expressed concerns that these would be too difficult to ship in Pectra. His colleague on the Geth team, Guillaume Ballet, agreed with this assessment. Buterin chimed in, saying that “at least updating the serialization method for transaction receipts will have “significant value” beyond Ethereum itself, as it eliminates additional security auditing overhead for layer 2 Rollups built on Ethereum.”. Etan Kissling from the Nimbus team, a major proponent of the SSZ-related EIPs, was not present on 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 EOF. Independent Ethereum protocol developer Danno Ferrin said the EOF team is working on EL spec testing for code changes. EVMOne and Reth are two EL client teams that have reportedly completed EOF implementations. Ferrin said the Geth team has made "good progress" on the implementation. Ferrin added that Ballet is working with "Daniel" from the Solidity team to address concerns about EOF and Verkle compatibility.

Ballet noted that based on his conversations with Daniel and other developers like Dietrichs, it would be difficult to reduce the scope of EOF without defeating its purpose and creating more work for developers to implement another set of EOF-like code changes in the future.

A developer with the screen name "Charles C" suggested looking for a way to easily implement EOF iteratively through a side car mechanism (such as the one used for blob transactions), rather than choosing between small or large EOF upgrades. Dietrichs asked in the chat whether customer teams would have more interest in Pectra if its EOF complexity was reduced. The Ipsilon team noted that code changes that caused the highest complexity in EOF (such as "TX create") have already been resolved, and specific requests to remove features such as "EOF create" will not significantly reduce the overall EOF complexity. For background, Ipsilon is the name of the EVM RD team funded by EF. Beiko suggested that developers continue to discuss EOF implementations in the recurring EOF breakout discussion.

ACD/EIP and L2/RIP

As the last topic discussed in ACDE #186, developers discussed changes to the Ethereum EIP process in light of the new RIP process. Dietrichs noted that six months have passed since developers started the meeting series on Rollup coordination, RollCall, and RIP processes. There are still some open questions about how these processes will and should affect the Ethereum EIP process. Dietrichs said that one of the ongoing research questions in L2 is whether long-term equivalence to the Ethereum Virtual Machine (EVM) is desirable for Rollups. He also added that an open question is to what extent changes implemented on L2 will ultimately affect protocol decisions on Ethereum Layer 1.

Geth developer Péter Szilágyi said that some features available on L2 may not be suitable for L1, and in some cases, even if they follow the features available on L2, they may differ from L2 to L1, which may cause confusion for Ethereum protocol developers. EF researcher Carl Beekhuizen pointed out that the RollCalls and RIP process does not require Ethereum protocol developers to release any features on L2, but rather improves communication between Rollups and Ethereum developers in order to avoid confusing situations like the one described by Szilágyi. Van der Wijden expressed concern that protocol developers spend time supporting changes implemented on L2, which will eventually become obsolete or unnecessary because L2 itself is shut down or stopped being used.

In response to these concerns, Dietrichs said: "I think people have always thought that Layer 2 can experiment and get crazier. I think what we see in practice is that most of them decide not to do it, or even or at least maybe start to do it, and then over time, most of them stop. So now they actually mainly follow the first layer specification. I think at least given the Rollup-centric roadmap, or we all think this is the best way for the ecosystem to develop, we at least owe Layer 2 clear guidance and communication, like the best way forward here."

「 Original link 」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia