ACDT#60: Call Minutes + Insights
The call re-evaluating the December 3 Fusaka mainnet activation date
Good evening,
Today, Ethereum client teams shared their readiness for upgrading Ethereum mainnet by December 3. Long story short, a shockingly large number of them are either not ready or have unclear status.
So, developers have agreed to re-evaluate the December 3 activation date on this Thursday’s All Core Developers (ACD) call after a few more days of leeway for client teams to work on their final Fusaka releases.
I hate to be the bearer of bad news, but the situation is unfortunate. Having already confirmed the upgrade date on last week’s ACD call, walking back the decision is likely to prove difficult for developers to do this Thursday.
On the other hand, moving forward with the December 3 date will mean they need to relax another guideline for upgrading Ethereum mainnet, the minimum period of 30 days between final client releases and the mainnet upgrade date.
Below, I share my takeaways on how developers are likely to move forward and what this means for Ethereum stakeholders.
But first, see my full summary of the latest Ethereum developer meeting, ACD Testing call #60.
Yours truly,
Christine D. Kim
(For background on the ACD governance process, refer to the Ethereum Governance 101 document in the ACD Toolkit.)
Fusaka Testing
The first blob parameter-only (BPO) hard fork is scheduled for activation on the Hoodi testnet this Wednesday, November 5, at 18:02 (UTC)/13:02 (ET).
All scheduled BPO forks have been successfully activated on the Sepolia testnet.
Prysm client developer Manu Nalepa shared a write-up about the node peering issue discovered last week in their client. He said that his team is working on a fix that will hopefully be ready for release sometime this week.
Lodestar client developer “nflaig” also reported an issue in their client that his team is working on a fix for. This issue results in incorrect KZG proofs and invalid blob-sidecars.
Ethereum Foundation (EF) Developer Operations Engineer Barnabas Busa questioned why the Lodestar bug was not caught sooner. Nflaig said there was a major refactoring of the Lodestar client for the Fusaka upgrade roughly one month ago, so it may be that testing of the new code was insufficient.
Nalepa said bad KZG proofs from the execution layer (EL) client via the “getblobs_v2” Engine API call will not be verified by the consensus layer (CL) clients, and could result in poor peering between CL nodes.
Teku client developer Enrico Del Fante confirmed that this behavior also occurs in Teku and likely in other CL clients, so it is important for EL clients to verify blob proofs before submitting them to the CL.
Busa asked if this is a critical issue that should delay the Fusaka mainnet timeline. Nalepa and Del Fante said it was not, as the worst-case result is poor peering between certain CL nodes.
Layer-1 Scaling
Nethermind client developer Kamil Chodala reported promising results from testing EL clients with a 100-million-gas block limit. Further testing is needed, but he noted that the feedback loop for evaluating client performance is getting faster.
EF Developer Operations Engineer Parithosh Jayanthi noted that the block gas limit could start rising on Ethereum mainnet as final client releases for Fusaka with a default block gas limit of 60 million get rolled out this week.
Nethermind client developer Ben Adams suggested that developers work on community outreach to notify ecosystem stakeholders about the new default block gas limit settings in Fusaka-ready client releases.
Glamsterdam
The first multi-client devnet for block-level access lists (BALs) has been delayed. EF Developer Operations Engineer Stefan Starflinger reported last week that the devnet was ready for launch.
This week, Starflinger shared that the Nethermind and Reth clients are ready for the devnet launch, but the status of the Geth and Besu clients remains unclear.
He added that as soon as Geth and Besu are ready, he will launch the devnet.
Geth client developer Jared Wasinger said Geth is ready for the BALs devnet launch.
EF Protocol Prototyping team member “Raxhvl” said a new batch of tests for BALs will be released shortly. It includes recent changes to BALs specifications, such as the changes to how coinbase addresses are tracked in the protocol.
EL clients will be re-run against the new batch of tests to assess their readiness for the first BALs devnet.
The next BALs breakout meeting is this Wednesday, November 5.
EF Testing (STEEL) team lead Mario Vega reported two new releases for consensus specifications, v1.6.0 and v1.6.0beta2. He requested all CL client teams to review these releases for their implementations of enshrined proposer builder separation (ePBS).
Busa said it would be ideal to have a BALs devnet running this week before the start of the Ethereum Devconnect conference and an ePBS devnet running sometime after the conference in late November.
Fusaka Mainnet Readiness
Busa asked about the readiness of Ethereum clients for the Fusaka mainnet upgrade planned for December 3, 2025.
Chodala reported unexpected regression in the Nethermind client during syncing. He said his team will release a minimal version of their client today and will likely have to release another version with a hot fix in the coming days.
Erigon client developer Andrew Ashikhmin said his team has already released a Fusaka mainnet-ready version of their client with the 60 million block gas limit set by default.
Reth client developer Dragan Rakita said his team will be ready with a release on Wednesday.
Del Fante reported that the Teku release is in progress and will be published later today.
Geth developer Marius van der Wijden said his team is working on their release, and it will be out late today or tomorrow.
Busa said that if client teams cannot have final releases out by this Wednesday, developers should consider rescheduling the Fusaka mainnet fork date.
Busa confirmed that the plan is to have all final client releases published in an EF blog post this Thursday, November 6.
EF Protocol Security Team Lead Fredrik Svantes reminded client teams to assign points of contact for the Fusaka mainnet fork that can be alerted in the event of any network emergencies during the upgrade.
Glamsterdam Testing Complexity Assessment Checklist
Vega shared that his team is preparing a checklist to assess the testing complexity of Glamsterdam EIPs. His team is starting with the EL-focused EIPs, but is open to suggestions on high-priority CL-focused EIPs to assess for testing complexity. As there are over 30 proposed Glamsterdam EIPs, Vegas asked client teams to reach out and suggest which Glamsterdam EIPs to prioritize for the checklist.
Nethermind client developer Lukasz Rozmej said his team will be ready to share their views on which Glamsterdam EIPs to prioritize in the upgrade by this Thursday’s ACD call.
Busa said it would be ideal if the larger client teams could signal their views on the Glamsterdam fork so that smaller client teams do not have to spend unnecessary time going through the entire proposed EIP list.
🌕 That’s all for my summary of ACDT #60. Continue reading for pointed takeaways on other Ethereum news and data analysis. 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 learn more, please visit my advisory services website:
(Quotes featured in this section may be edited slightly for grammar and clarity. For more information on the people quoted in this section, refer to the ACD Call Directory in the ACD Toolkit.)
Takeaway #1:
Due to a lack of client team readiness, developers may need to reschedule the Fusaka mainnet upgrade.
