ACDC #165: Call Minutes + Insights

The call confirming the Fusaka testnet timeline and BPO hard fork values

Good evening,

Today’s All Core Developers Consensus (ACDC) call was an important one where developers confirmed the schedule for public testnet upgrades and the blob-parameter-only (BPO) hard fork schedule for Fusaka.

Developers reached a decision on both matters surprisingly easily, without the need for extended discussion.

Despite continued setbacks in testing, developers are relentlessly pursuing a timeline that activates Fusaka on Ethereum mainnet by the end of this year, and with the decisions made on ACDC #165, nothing short of a catastrophic event during the next few months of testing will change this timeline.

Below is my full call summary and key takeaways of ACDC #165.

Yours truly,

Christine D. Kim

---

(For background on the ACD governance process, refer to the Ethereum Governance 101 document in the ACD Toolkit.)

Fusaka Devnets

• Fusaka Devnet-3 is stable. Client teams are continuing to issue fixes to their software on this devnet. No new testing has been conducted on Devnet-3, as recent testing efforts have been focused on Fusaka Devnet-5.

• Fusaka Devnet-5 is also stable. However, earlier this week, multiple client bugs and node misconfigurations were identified on the devnet, causing the window of opportunity to gather data on blob parameter only (BPO) values to shrink.

• Although the analysis on Devnet-5 did not go as planned, Ethereum Foundation (EF) Developer Operations Engineer “samcm” shared conclusions based on the data gathered during the roughly 12-hour window when Devnet-5 was stable. Samcm’s analysis can be read in full here. It suggests setting a target/maximum of 10/15 and 14/21 blobs per block for the first and second BPO hard forks.

• EF Developer Operations Engineer Barnabas Busa added that his team, the EthPandaOps team, will launch Fusaka Devnet-6 in a few weeks to reconfirm these values.

• Busa highlighted that there is a bug in the Prysm client on Devnet-5 actively being investigated by developers. The bug appears to be triggered by a high blob count on the devnet, resulting in a high rate of orphaned blocks.

• The current list of known bugs in clients is recorded here.

• EF Protocol Security Researcher Justin Traglia highlighted that a bug in the “ckzg” library has been fixed. There is a new version of the library, v2.1.3, now available on Github. Due to concerns about this version’s dependencies on recent changes in the “blst” library, Traglia said he will cut another release for the ckzg library that does not require any updates to blst libraries in clients.

Fusaka Timeline

• Developers agreed to the following timeline for the Fusaka upgrade rollout on testnets and Ethereum mainnet:

  • October 1: Holesky upgrade

  • October 14: Sepolia upgrade

  • October 28: Hoodi upgrade

  • December 3: Mainnet upgrade

• The precise epoch numbers, timestamps, and BPO hard fork schedule for each upgrade are detailed here.

• Developers also confirmed that client teams should bundle their releases for the testnet upgrades initially. However, any updates thereafter made to releases nearer to the mainnet activation date can be published at client teams’ discretion.

• Busa said that the EF EthPandaOps team plans to run shadow forks of all testnets in advance of the testnet upgrades. Client teams confirmed they will have updated releases for shadow fork testing by next Thursday, September 25.

Glamsterdam

• There is a community discussion thread on Ethereum Magicians about the naming of the consensus layer (CL) upgrade after Glamsterdam.

• There is a community discussion thread on Ethereum Magicians about the naming of the new testnet that will replace the Sepolia testnet. EF Developer Operations Engineer Parithosh Jayanthi stressed that the deprecation of Sepolia is not imminent, and developers will give the Ethereum community plenty of time to prepare for the testnet deprecation. The expected launch date for the new testnet replacing Sepolia is March 2026.

• About testing for the Glamsterdam upgrade headliners, which are enshrined proposer builder separation (ePBS) and block level access lists (BALs), Busa proposed separating the initial testing for these on devnets. Testing for BALs on a multi-client devnet is currently blocked by ePBS. Given that the first ePBS devnet will not be ready until next month, Busa recommended using the Prysm client’s implementation of BALs to get the BALs Devnet-0 started as early as next week. Developers agreed that this should be fine, provided the two headliner implementations are merged as soon as a minimum viable version of ePBS is available for testing alongside BALs on a devnet.

---

🌻That’s all for my summary of ACDC #165. Continue reading for pointed takeaways on other Ethereum news that caught my attention over the past week. To read the rest of the newsletter, make sure you are signed up for a premium subscription:

🌻New to the ACD calls and want to learn more about Ethereum protocol development? Explore the ACD Toolkit, which is included with a premium subscription. It contains evergreen resources and materials that teach you the fundamentals of tracking the evolution of Ethereum like a pro:

🌻I also offer professional consultations on Ethereum protocol development and governance. If you’d like to book a meeting with me to get tailored insights into the evolution of Ethereum for your business or portfolio, please use my Calendly scheduling page:

---

Takeaway #1:

By finalizing the Fusaka timeline at this stage in the upgrade testing process, Ethereum developers have increased the difficulty and risk associated with any further delays to shipping the upgrade.

There was surprisingly little pushback and discussion about the Fusaka timeline on All Core Developers Consensus (ACDC) call #165.

Part of this may be because the Ethereum Foundation (EF) Protocol Coordination Co-Team Lead and Chair of the ACDC, Alex Stokes, said he had already confirmed the timeline with each of the client teams in advance of the call.

The one minor concern raised about the Fusaka timeline was shared by Nimbus client developer “Dustin,” who said: