skip to content

Ethereum All Core Developers Consensus Call #149 Writeup

Ethereum SecurityBlue2

On January 23, 2025, Ethereum developers met over Zoom for All Core Developers Consensus (ACDC) call #149. The call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. The ACDC calls are a biweekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also known as the Beacon Chain.

On ACDC #149, developers discussed newfound bugs on Pectra Devnet 5 and agreed to launch another devnet before upgrading public testnets. They fleshed out a tentative timeline for Pectra mainnet activation which would require client teams to release updated software by Feb 3 for a hopeful activation of Pectra on the Sepolia and Holesky testnets on Feb 12 and Feb 19, respectively. Thereafter, developers plan on releasing final Pectra software for a hopeful mainnet upgrade on March 11, 2025.

Pectra Devnet 5 & 6

A gas estimation bug caused a three-way chain split on Pectra Devnet 5. The network, according to EF DevOps Engineer Rafael Matias, is still not finalizing. The Nethermind, Reth, Erigon, and Besu client teams are working on bug fixes. Matias added that the latest hive test run on Pectra Devnet 5 also failed, so his team is investigating what happened.

Based on pending changes to Pectra specifications and recent network failures on Pectra Devnet 5, developers agreed they should launch another devnet, Devnet 6, before upgrading public testnets. Matias said that client teams should work on bug fixes first and once hive tests have been run against the updated clients, his team can launch Devnet 6. Stokes highlighted that there are specifications changes to EIP 7702 that still need to be finalized on GitHub. Geth developer “Lightclient” said that he would do this. Stokes also flagged that there is a new CL specifications release for Pectra, version 1.5.0-beta.1, but there are no substantial changes in it that make it very different from the prior release.

Stoked asked how quickly client teams feel confident to launch Devnet 6. Developers agreed to aim for a devnet launch early next week. EF DevOps Engineer Parithosh Jayanthi wrote in the Zoom chat that in parallel developers can also start planning a shadow fork to test Pectra. As background, a shadow fork is a devnet created by forking a live testnet or mainnet. Shadow forks unlike regular devnets keep the same state and history of the forked network so transactions from the forked network can be replayed on the shadow fork.

Pectra Public Testnet and Mainnet Fork Timing

Then, developers discussed timing for upgrading Ethereum public testnets and mainnet. EF Protocol Support Lead Tim Beiko suggested aiming for a mainnet activation on March 11 as this would mean Pectra activates on Ethereum less than one year from its prior upgrade, Dencun, which occurred on March 13, 2024. A hopeful mainnet activation on March 11 means that public Ethereum testnets, Sepolia and Holesky, must be upgraded on February 19 and 24, respectively, at the latest. Ideally, the two testnets are upgraded earlier on February 12 and 19 to allow for end-users and the broader Ethereum ecosystem more time to adequately prepare for the mainnet upgrade.

There were no objections to Beiko’s proposed timeline, though clearly the timeline is tentative as developers have yet to fix the bugs on Devnet 5 and launch Devnet 6. Beiko said that he would follow up with specific block numbers to accompany the proposed dates and put these block numbers up for discussion on the next ACD call. He stressed that if client teams are serious about the proposed timeline then near-final client releases must be ready by February 3, 2025.

PeerDAS

A developer by the screen name “Manu” shared updates about progress on PeerDAS. Other than Lighthouse and Prysm, other client teams are in the process of implementing the latest specifications for PeerDAS. Testing is underway for both Lighthouse and Prysm PeerDAS implementations. Manu said that developers are debugging issues with client interoperability between the two clients.

As background, PeerDAS is the next major scaling improvement to Ethereum that is tentatively planned for activation in the upgrade after Pectra, which is called Fusaka. PeerDAS will enable “data availability sampling” on Ethereum so that Ethereum nodes have greater capacity to process and include blob transactions in blocks. EF Research Ansgar Dietrichs said that developers on the call should anticipate PeerDAS to increase the blob throughput of Ethereum by 8x.

Stokes raised a proposal by OP Labs Engineer “protolambda” to expedite Ethereum’s scaling roadmap by implementing blob parameter only (BPO) forks. In a post by Protolambda, they explained, “BPO forks are simple Ethereum forks that only change two parameters: blob targets and blob limits. BPO forks give Ethereum flexibility to safely scale blobs in smaller, more regular increments and they give builders confidence that Ethereum will continuously grow its capacity.”

Prysm developer Terence Tsao cautioned that increasing blob throughput by 8x with PeerDAS could be “a little harder than we think” and will require more research and testing before developers can know for certain how best to roll out the sampling-related code changes. Beiko said in the Zoom chat that another possibility for supporting BPO forks could be to “move the blob target for validators to control” like how validators control the block gas limit.

Lightclient said that the discussion about BPO forks seemed premature as Pectra will already increase blob capacity to what the network can safely handle and encouraging ways to increase the blob limits beyond this could be unsafe. Dietrichs echoed Lightclient’s concerns. Nethermind developer Ben Adams said that unlike the block gas limit, changes to the blob gas limit may be more difficult for node operators to vote on and fine tune as each additional blob in a block carries up to 128kB of additional data.

Protolambda said that he welcomes continued feedback on his BPO fork idea.

Fusaka Fork Planning Process

Beiko asked developers for their thoughts about the Ethereum fork planning process, its strengths and weaknesses, and areas for improvement considering how planning for Pectra has gone and in preparation for planning the next upgrade, Fusaka. “As some of you may have noticed, people have opinions about All Core Devs and I think Pectra has been kind of a wild fork in terms of coordination and planning,” said Beiko. Stokes echoed Beiko’s sentiments about Pectra and said he is supportive of taking the time to “reflect” on the governance process and improve it for the Fusaka upgrade.

Besu developer Justin Florentine said that developers should clarify what they mean when they said that Pectra was a “wild” fork and offer more specific details on the hardships or difficulties they faced preparing for Pectra. Lodestar developer Gajinder Singh wrote in the Zoom chat, “It’s important to align on vision to have resonance in opinions and ACD process.” Dietrichs wrote in the chat, “I personally really think we made a premature call on maxeb [EIP 7251]. I think had we immediately prioritized peerdas, it could have been in this fork instead.”

Beiko said that he would create an Ethereum Magicians forum to continue the discussion on improvements to Ethereum governance and the ACD process. He encouraged client teams and the broader Ethereum community to chime in with their thoughts. Stokes reminded client teams about the Pectra testing call on Monday, January 27, and EF Researcher Piper Merriam reminded client teams in the Zoom chat that there are less than 100 days left before the self-imposed deadline of May 1, 2025, to remove pre-Merge history from clients.