ACDC #166: Call Minutes + Insights

The call discussing a narrower scope for ePBS in Glamsterdam

Good evening,

The Fusaka testnet timeline blazes onwards after a successful Holesky testnet upgrade.

With increased confidence in the Fusaka timeline, Ethereum developers are shifting focus to Glamsterdam, where consensus on one of the code changes included in the upgrade is starting to falter.

See below my full call summary and key takeaways of All Core Developers Consensus (ACDC) #166.

Yours truly,

Christine D. Kim

---

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

Fusaka

• Fusaka Devnet-3 non-finality testing results are in. There were no issues re-stabilizing the network from a state of extended non-finality (i.e., reduced security).

• Developers successfully activated the Fusaka upgrade on Holesky on Wednesday, October 1. Due to a few missing updates in clients, there had been a brief drop in network participation after the upgrade. However, once clients were updated, the testnet recovered to a healthy participation rate of above 90%.

• Thereafter, Parithosh Jayanthi, Ethereum Foundation (EF) EthPandaOps Team Lead, stated that there had been a second temporary drop in network participation on Holesky. Developers are still investigating the cause of this incident.

• Besu client developer Ameziane Hamlat stated that he saw Besu nodes reduce in bandwidth usage by more than 50% following the upgrade on Holesky. He asked if this was noticed by other client teams. Jayanthi responded saying that analysis on all client node resource usage is ongoing, and that a report on this will be generated tomorrow, October 3.

• Alex Stokes, EF Protocol Coordination Co-Team Lead, reminded developers that the first blob parameter only (BPO) upgrade will occur on Holesky next week, on Tuesday, October 7.

• Stokes also stated he is actively working on the Fusaka upgrade readiness document, which will contain important information about point people and processes in the event of any major incidents or testnet failures leading up to the Fusaka upgrade on mainnet.

Glamsterdam

• Now that the final preparations for Fusaka are underway, Stokes stated that moving forward, the All Core Developers (ACD) calls will place a greater emphasis on discussing matters related to the next upgrade after Fusaka, called Glamsterdam.

• As a refresher, there are two Ethereum Improvement Proposals (EIPs) that developers are already working on for inclusion in Glamsterdam. They enshrined proposer builder separation (ePBS) and block-level access lists (BALs). More information about each can be read in this prior ACD After Hours newsletter.

• On the implementation progress for ePBS, Prysm developer “Potuz” stated that the specifications for the EIP have not changed, and client teams are working on stable branches for it. He added that there has been discussion on how to better enable trusted payments, such as payments through MEV-Boost, in the design.

• Nethermind researcher Lin Oshitani gave a presentation on why ePBS should be split into two EIPs: one that enables execution payload separation from the consensus block, and a second proposal that enables trustless payments. (Trustless payments refer to the in-protocol mechanism in ePBS that allows third-party block builders to submit bids directly to proposers, eliminating reliance on external relay software like MEV-Boost.)

• EF Protocol Architecture Researcher Ansgar Dietrichs, EF Protocol Prototyping Team Lead Toni Wahrstatter, Lighthouse client developer “Dapplion,” and a representative from Lido with the screen name “Greg K.,” were in favor of Oshitani’s proposal. Potuz was not.

• Dietrichs and Stokes acknowledged that the discussion on splitting ePBS into two EIPs needs more time. They recommended revisiting the discussion in a few weeks.

• Prysm developer Terence Tsao highlighted that next ePBS breakout meeting will happen on Friday, October 10.

Update to EIP-7723

• EF Protocol Support Team Member “Wolovim” shared an update on his proposal to update EIP-7723, a process document that defines the stages of network upgrade inclusion.

• Wolovim stated that his proposal now clarifies that every EIP proposed for inclusion in an upgrade must have a “point of contact,” rather than “champion,” for responding to inquiries about the proposal. Wolovim stated the new wording is meant to reduce confusion about the role and responsibilities of an EIP’s point person.

• Stokes said that if there are no objections to Wolovim’s proposal in the next 24 hours, this update to EIP-7732 will be finalized and merged.

Update to EIP-7870

• EF zkEVM Team Lead “kevaundray” proposed changing the status of EIP-7870, which specifies validator and full node hardware and bandwidth requirements, from “in review” to “live.” Live or living EIPs are EIPs that are designed to be updated continually over time as consensus about the information in the proposal changes.

H-Star Naming

• Former WeekinEthNews editor “abcoathup” has started a discussion thread to determine the upgrade name for the next upgrade after Glamsterdam. Abcoathup has proposed finalizing the name by the time Fusaka goes live on Ethereum mainnet. Stokes agreed with this proposal, stating that developers can opt for the most popular name proposed in the discussion thread.

---

🌻That’s all for my summary of ACDC #166. 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:

The Fusaka upgrade on the Holesky testnet was a success. With each successful testnet upgrade, the odds of a mainnet upgrade before the end of the year continue to climb higher.

On ACDC #166, Stokes summarized Wednesday’s Holesky testnet upgrade in the following way:

“In short, Holesky has gone well enough, and we’re going to keep moving forward.”

Next up is the first BPO hard fork, increasing the blob capacity on Holesky from a target/max of 6/9 to 10/15 blobs per block. This upgrade is scheduled to activate next Tuesday, October 7, at 1:20 UTC/21:20 ET.