skip to content

Ethereum All Core Developers Execution Call #204 Writeup

Ethereum All Core Developers Execution Call #204 Writeup - Thumbnail

On January 30, 2025, Ethereum protocol developers met over Zoom for All Core Developers Execution (ACDE) Call #204. This week, the call was chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko. The ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum.

On ACDE #204, developers shared updates about:

  • Pectra Devnet 5,

  • a security bug impacting the Geth client,

  • and Fusaka.

Developers did not pick precise block times and slot numbers for Pectra activation on public testnets due to newfound bugs on Pectra Devnet 5. They plan on picking times for upgrading public testnets on next week’s ACD call.

Devnet 5 Updates

A developer by the screen name “pk910” shared updates about Pectra Devnet 5. Though the devnet is finalizing again and the gas estimation bug shared on last week’s ACD call is now resolved among clients, it appears there is a new consensus bug impacting the Nethermind client. Senior software engineer at Nethermind Marek Moraczyński said the bug was caused due to a BLS precompile optimization in the Nethermind client. Moraczyński added that the bug should not be a blocker for the launch of Pectra Devnet 6 as a fix for it has already been implemented by his team.

Devnet 6 Updates

On the topic of Pectra Devnet 6, Pk910 said a new hive release for Pectra is ready. Once most client teams pass the new hive tests, the EF Developer Operations team will launch Pectra Devnet 6. Pk910 said there is a pending change for Devnet 6 specifications impacting system contract addresses. The change will update all system contract addresses created through Pectra to be more recognizable and follow a pattern that highlights which EIP each specific system contract address relates to. Developers agreed to merge these changes on GitHub and finalize them for Devnet 6.

Testnet Fork Slot Proposals

On the prior ACD call, Beiko shared tentative dates for upgrading public Ethereum testnets. Given that developers have not yet launched Pectra Devnet 6, Beiko asked if developers should update their initial timeline and when they would feel comfortable picking more specific times for upgrade activation. Prysm developer Terence Tsao said it was “premature” for developers to commit to specific times for public testnet activations. “Obviously, there are a lot more issues than we expected for Devnet 5 and those are actually consensus issues. They’re quite serious,” Tsao said. Agreeing with Tsao, Beiko said that developers should wait an additional week, until the launch of Devnet 6, before picking slot numbers for testnet upgrades.

A few potential slot numbers that were shared by Beiko before this week’s call include:

  • Holesky:

    • 3620864 (Wed, Feb 12 at 09:32:48 UTC)

    • 3670016 (Wed, Feb 19 at 05:23:12 UTC)

    • 3710976 (Mon, Feb 24 at 21:55:12)

  • Sepolia:

    • 7020544 (Wed, Feb 19 at 15:48:48 UTC)

    • 7061504 (Tue, Feb 25 at 08:20:48)

    • 7118848 (Wed, Mar 5 at 07:29:36)

Developers plan on re-discussing these numbers on the next ACD call.

Geth Security Bug

Geth developer Marius van der Wijden shared details about a bug in Geth. As background, Geth is the most widely run execution layer client in the Ethereum ecosystem. Van der Wijden said the bug impacts Ethereum’s peer to peer layer and Layer-2 rollups built on top of Ethereum. His team has since published a new release for Geth that fixes the issue. Nodes running a version of Geth that is 1.14 or later should update immediately to the newest version. Nodes running a version of Geth that is 1.13 are not affected.

When asked how this bug could impact nodes in a worst-case scenario, Van der Wijden said that the bug could enable malicious nodes to shut down other nodes or peers that it is connecting to. A Geth developer by the screen name “Felix” said in the Zoom chat that the bug is a “P2P DoS issue.”

Pectra Timeline

Beiko reiterated the tentative timeline for Pectra moving forward.

  1. Launch Devnet 6 the week of February 3.

  2. Decide on slot numbers for upgrading the Holesky and Sepolia testnets on the next ACD call on Thursday, February 6. (On a prior ACD call, developers indicated that they should upgrade Sepolia ahead of the Holesky testnet. However, on this call, EF Researcher Alex Stokes clarified that the Holesky testnet should be upgraded first to give Ethereum validator node operators more time to test their setups before Pectra mainnet activation.)

  3. Client teams cut releases for the Holesky and Sepolia testnet upgrades that weekend and the EF published an official announcement featuring these releases on Monday, February 10 or Tuesday, February 11.

  4. Holesky upgrades on or around February 19.

  5. Ethereum developers decide on a slot number for upgrading Ethereum mainnet on the ACD call scheduled on February 20.

  6. Sepolia upgrades roughly one week after Holesky around February 26.

  7. Client teams cut final releases for the Ethereum mainnet upgrade one or two days after the Sepolia upgrade on February 27 or 28. The EF to publish an official announcement for these releases a few days thereafter.

  8. Ethereum mainnet upgrade in mid-March.

Beiko encouraged client teams to focus on getting their client releases ready for the launch of Pectra Devnet 6. He also stressed that both EL and CL client teams should be present for next week’s ACD call where developers may decide on slot numbers for the public testnet upgrades, assuming Pectra Devnet 6 launch goes over well.

EF Researcher Ansgar Dietrichs asked in the Zoom chat if developers should also pick slot numbers for the Ethereum mainnet upgrade as early as next week. Beiko said, “I can look at possible mainnet fork slots for next week’s All Core Devs as well if people find that helpful. I do feel like this can backfire though because sometimes I’ll say this is the tentative mainnet fork block and then it will be tweeted, and people will just assume it’s that and they’ll be disappointed if it’s not.”

Pectra System Contracts Audits

EF Security Research Lead Fredrik Svantes shared an overview of the process for auditing system contracts in the Pectra upgrade. As background, system contracts are smart contracts that extend the functionality of the Ethereum Virtual Machine (EVM). They create built-in functions such as ECDSA signature recovery or SHA-256 hashing that smart contract developers can access at specific addresses on Ethereum without having to deploy their own smart contracts to enable these widely used functions.

Pectra system contracts were audited by four security firms: Blackthorn, Dedaub, PlainShift, and Sigma Prime. Each audit was performed sequentially, meaning that fixes based on a previous report were integrated first before the next audit commenced. All audit reports have been published on GitHub. Representatives from each of the security firms shared a summary of their key findings on the ACD call.

Pectra Retrospective

Last week, Beiko started an Ethereum Magicians thread sourcing feedback on the upgrade planning process. Beiko said that one of the key takeaways for implementation when planning the Fusaka upgrade should be that developers refrain from adding new EIPs into the upgrade scope until existing EIPs are implemented on a devnet. In the context of Fusaka, this means not including new EIPs into Fusaka until EOF and PeerDAS are implemented on a multi-client devnet. Beiko clarified that by “devnet”, he means a dedicated test network for the official upgrade, as opposed to a “feature” devnet, which may only be testing for one code change in isolation. Beiko also suggested further discussion on the upgrade planning process on the next ACDE call in two weeks.

In the Zoom chat, EF Protocol Support Member Trent van Epps and EF Researcher Alex Stokes said they were strongly in favor of keeping the scope of Fusaka to just PeerDAS and EOF. Beiko expanded on his earlier comments about staging EIPs for an upgrade across devnets and said, “We could choose to remove something from a devnet. That’s fine. What we should not do and what we did wrong with Pectra and what caused months of delay is schedule 10 unimplemented things for inclusion. … Then, we have 12 different client teams that have to implement 10 different things and try to move all of that forward. It’s just extremely hard to do this in a coherent way.”

When asked if this technique may slow down the pace of development, Beiko asserted that from his intuition, using devnets to stage EIPs will help speed up the process due to more coordination across client teams. Reth developer Roman Krasiuk added that developers should try to finalize the scope for the next upgrade by the time the current upgrade is ready for activation on mainnet. So, for example, once Fusaka is ready for mainnet activation, developers should have the scope of the upgrade after Fusaka is ready for testing.

Nethermind developer Lukasz Rozmej went one step further and said developers should aim to work on devnets for the next upgrade by the time developers are ready to activate the current upgrade on mainnet. So, for example, once Fusaka is ready for mainnet activation, developers should be ready to launch a devnet for the upgrade after Fusaka. Besu developer Justin Florentine expressed his support for all these ideas and added that developers should schedule 1 week of holidays for all client teams after a hard fork activates on mainnet.

Geth developer Guillaume Ballet expressed his discontent with the upgrade planning process, saying that developers were chasing to implement “what’s the rage on Twitter” instead of what is important to the Ethereum protocol. As background, Ballet is the developer who was leading efforts to implement the Verkle upgrade. Despite his efforts, developers decided to delay Verkle in favor of the EIPs in Pectra and Fusaka. “I started working on [Verkle] four years ago. It was always supposed to be the next fork and every time it’s pushed. Yet another small fork in between and then something more important,” said Ballet, adding that he wanted “some guarantee” to ensure that his time is not wasted. Unfortunately, no such guarantees exist, nor have they ever existed for Ethereum protocol developers. Beiko called this desire for some assurance and consolation to soothe Ballet’s discontent as a “hard problem” to solve.

Moving beyond Ballet’s disgruntlement about delays to Verkle, Reth developer Dragan Rakita noted in the Zoom chat that another helpful recommendation for the upgrade planning process is encouraging client teams to share their thoughts about the scope of an upgrade asynchronously from the calls through blog posts and X statements. Beiko agreed. Nethermind developer Ahmad Bitar added that EIPs with spec tests should be prioritized for implementation in an upgrade ahead of EIPs without spec tests. Beiko agreed and went so far as to say that EIPs scheduled for inclusion in an upgrade must have spec tests as a prerequisite.

Prysm developer “Potuz” was in favor of the idea of staging EIPs on multiple devnets. However, he emphasized that developers should not freeze the scope of a fork too hastily. Rather, they should be open to implementing EIPs that everyone wants and adding them to a devnet on a rolling basis. Beiko agreed.

Fusaka Planning

As developers are getting close to finalizing Pectra and preparing it for mainnet activation, Beiko asked developers to start reviewing the EIPs proposed for inclusion in Fusaka. The two that developers have already agreed to include in Fusaka as a baseline for the upgrade are EOF and PeerDAS. Potuz asked if developers could schedule a Fusaka devnet featuring these two code changes on the call. However, Beiko, independent Ethereum developer Danno Ferrin, and EF DevOps Engineer Parithosh Jayanthi were in favor of focusing on Pectra Devnet 6 launch first. Jayanthi said in the Zoom chat that a new PeerDAS-only devnet should be ready to launch in a week or two.

Nethermind developer Marc Harvey Hill presented two EIPs for consideration in Fusaka, EIP 7793 and 7843. EIP 7793 proposed a new precompile that returns the index of the transaction being executed within the current block for the purposes of improving support for encrypted mempools. EIP 7843 proposes a new precompile that returns the corresponding slot number for the current block, which would also be useful for encrypted mempool applications. Hill requested feedback from application developers and protocol developers on the two EIPs.

Independent Ethereum developer Kevaundray Wedderburn presented EIP 7870 which formalized the hardware and bandwidth recommendations of Ethereum validating nodes and full nodes. Nixo, who is part of the EF Protocol Support Team, pushed back on the requirement of 50 Mbps upload bandwidth for local block builders. Potuz also voiced concerns about “max blobs flag” which would indicate when block builders do not have enough bandwidth to support building maximum size blocks. Due to limited time on the call, Beiko recommended taking the discussion to Discord.

EF Researcher Alex Beregszaszi presented EIP 7823 which introduces an upper bound on the inputs of the MODEXP precompile to reduce the surface area for bugs and consensus failures on Ethereum. Due to limited time on the call, Beiko recommended continuing the discussion on this EIP on Discord.

ACD Call Bot and RPC Standards Breakout Meeting

Nicolas Consigny, an employee at the EF, shared that he is working on a bot to help organize ACD calls and share summaries of the calls on different platforms. Consigny said that he will give a demo of the tool on a future ACD call but in short, the bot can automatically create GitHub entries for ACD meetings and cross-post meeting summaries onto platforms like Eth Magicians and Farcaster. He also mentioned the use of AI like granola.ai to create summaries of the meetings and in general , improve the efficiency of the calls.

Finally, Beiko flagged a breakout meeting on RPC standards happening on February 3, 15:00 UTC.