ACDT#55: Call Minutes + Insights

The call preparing for the first Fusaka public testnet upgrade

Good evening,

Today, developers discussed final preparations for the forthcoming Holesky testnet upgrade. This will be the first of three public testnet upgrades in the lead-up to a hopeful mainnet upgrade in early December.

In today’s ACD After Hours newsletter, I explain why I am cautiously optimistic about the first testnet upgrade for Fusaka and an underrated way for Ethereum stakeholders to get involved in the Ethereum protocol development process early and with high impact.

But first, see below my full call summary of the latest Ethereum developer meeting, All Core Developers Testing #55.

Yours truly,

Christine D. Kim

---

Fusaka

• Fusaka Devnet-3 is undergoing a planned non-finality test that will last approximately two days. After two days of non-finality, nodes will reconnect to the devnet and be monitored to see if they can properly recover from the non-finality event.

• The Ethereum Foundation (EF) EthPandaOps team has launched a shadow fork of Holesky in advance of the Holesky testnet upgrade. The Erigon and Besu clients initially had issues with the Holesky shadow fork. Since the meeting, the issues have been resolved.

• As a reminder, the Holesky testnet upgrade is scheduled to activate on Wednesday, October 1, at 8:48 (UTC) / 4:48 (ET). Thereafter, the first blob parameter only (BPO) hard fork will occur on Holesky the following Tuesday, October 7, at 1:20 (UTC)/21:20 (ET).

• The full schedule for Fusaka testnet upgrades and test BPO forks can be found on the EF blog.

• There were four client teams that did not have testnet-ready releases as of the prior All Core Developers (ACD) call, ACDE #221. Since Thursday, all client teams have published testnet-ready releases.

• About the most recent Prysm release, Prysm developer James He noted that there are “ongoing issues” with the release, but it should still be fine for use on testnets.

• Mario Vega highlighted a few updates to test specifications for Fusaka:

  • Ethereum Execution Specifications Tests (EEST) v5.2.0 is ready for use. Only minor updates to exception messages in clients have been included in this release.

  • EEST v5.3.0 is pending and will include updates to BPO schedule parameters for use on testnets.

• There are two weeks left in the Fusaka bug bounty competition. For more details about the competition, please visit this link.

• EF Protocol Security Team Lead Fredrik Svantes reminded developers to update documents in accordance with the guidelines outlined in the Ethereum Protocol Upgrade Process. For example, one of the guidelines is the creation of an “Incident Response Plan,” which assigns a point of contact for each client team in case of unexpected issues during testnet upgrades. EF Protocol Coordination Co-Team Lead Alex Stokes said he would take the lead on updating relevant documents for the forthcoming testnet upgrades.

Block Gas Limit Increase

• Developers reconfirmed that all client teams should include a default block gas limit increase to 60 million gas in their mainnet-ready Fusaka releases.

• All execution layer (EL) client teams, including Besu, have affirmed that they will do this.

• EF STEEL Team Lead Mario Vega said the repository for client benchmarking tests will be restructured in accordance with this proposal by STEEL Team Member “danceratopz.” Vega also highlighted a new EEST test format to make the work of writing benchmarking tests easier for developers.

• EF Protocol Prototyping Researcher Jochem Brouwer shared that he is continuing to work on new tooling for benchmarking clients against “worst-case situations” where they need to process blocks that make large changes to blockchain state. Brouwer requested information from client teams about the most intensive mainnet situations that they would like to see tests created for.

• Vega inquired about the location and maintenance of these new tests once they’re developed. EF EthPandaOps Team Lead Parithosh Jayanthi suggested that they be maintained independently in a repository that can be integrated into existing test repositories, such as EEST.

Glamsterdam

• There is a new consensus specifications release, v1.6.0-beta.0, ready for use by client teams working on their Glamsterdam implementations.

• New test cases have been created for EIP 7928, Block-level Access Lists (BALs), addressing nuances in the handling of EIP 7702 transactions.

• EF Protocol Prototyping Team Lead Toni Wahrstatter said that developers are debating whether BALs should be implemented as a hash or Merkle Patricia Trie (MPT) root. BALs are currently implemented as hashes, but the argument for implementing them in a tree-like structure is outlined in this Ethereum Research post. Wahrstatter requested input on this change to EIP 7928 from interested stakeholders.

• Jayanthi said that once there are at least three client implementations of EIP 7928, the EthPandaOps team will proceed with creating the first devnet for BALs.

• EF Protocol Security Team Member Justin Traglia shared a brief recap of the latest breakout call on EIP 7732, enshrined proposer builder separation (ePBS). Traglia said work is ongoing for ePBS client implementations. The goal is to create the first devnet for ePBS by the end of October.

---

🌻That’s all for my summary of ACDT #55. Continue reading for pointed takeaways from the call, featuring direct quotes and additional context on key topics. 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:

---

Editor’s note: Some quotes featured in this section have been edited slightly for grammar and clarity.

Takeaway #1:

Based on the results of parallel testing for Fusaka, it is unclear how the Holesky upgrade will go.

On ACDT #55, developers discussed the results of their final preparations for the Holesky upgrade.

As discussed in my takeaways from All Core Developers Execution #221, developers are parallelizing testing efforts for Fusaka in unprecedented ways that shorten the potential timeline for upgrade activation on mainnet.

Rather than upgrading public testnets after all devnet testing is completed, developers are doing the two concurrently.

Ethereum Foundation (EF) EthPandaOps Team Lead Parithosh Jayanthi reported that another round of non-finality testing is ongoing on Fusaka Devnet-3. The results of this will not be known until after the Holesky upgrade goes live on Wednesday, October 1.

Jayanthi also reported that developers have successfully initiated a shadow fork of Holesky. The initial results of the shadow fork revealed issues in two clients, Erigon and Besu.

Jayanthi said:

“The network seems to be finalizing. We’re discussing with the Erigon team why their nodes [are] not able to keep up, but it was able to do the shadow fork, so it’s likely more peer-related than anything else, and Besu’s building blocks, but it’s building it without transaction inclusion, so they’ve also been informed.”