ACDC #155: Call Minutes
The call where developers finalized the CFI list for Fusaka
Good evening,
Yesterday, Ethereum developers agreed to bump up EIP 7892, blob parameter only (BPO) hard forks, from a status of considered for inclusion (CFI) to scheduled for inclusion (SFI) in Fusaka. They also reconfirmed that EIP 7917, deterministic proposer lookahead, should be CFI'd for Fusaka.
Check out my post, "Figuring out Fusaka,” for a detailed explanation of what these statuses mean and a look at the full scope for Fusaka. (Note: Some of the information in the post is outdated because of the decisions made on the latest ACD call, so I’ve published a note marking relevant updates for reference here.)
Also, in an effort to make my call summaries more digestible and reader-friendly, I'm experimenting with a new structure. I detail the key decisions made on the latest ACD call up front and then highlight the parts of the call featuring notable discussions between developers. Let me know what you think of the structure. The ways to give feedback are shared at the end of today’s newsletter.
Without further ado, see below my full call summary for All Core Developers Consensus Call (ACDC) #155.
Yours Truly,
Christine D. Kim
Date and time: April 17, 2025, 14:00-15:30 UTC
Duration: 90 minutes
Key Decisions
Pectra Mainnet Incoming:
Developers are still on track to publish final client software releases for the Pectra upgrade on Ethereum mainnet by Monday, April 21.
The Ethereum Foundation (EF) will publish a blog post shortly thereafter on Wednesday, April 23, featuring these releases and announcing the scheduled Pectra mainnet activation date and time.
Pectra is expected to go live on mainnet Wednesday, May 7, at epoch 364032 at 10:05:11 UTC.
Fusaka CFI List Finalized:
Developers agreed to finalize the consensus-layer (CL) focused code changes they are considering for inclusion in Fusaka, the next planned upgrade after Pectra.
The only code change they agreed to CFI in Fusaka is EIP 7917, deterministic proposer lookahead.
They also agreed to advance EIP 7892, BPO forks, from a status of CFI to SFI.
All other proposed CL-focused EIPs for Fusaka have been rejected for this upgrade.
Notable Discussions
Implementing BPO forks as an array
Alex Stokes, EF Research Lead and Chair of the ACDC calls, shared updates on the implementation details for EIP 7892, BPO forks. He explained that developers plan to configure automated upgrades that only change blob parameters through an array of records in the CL. The array will detail the epoch number at which the upgrade should be activated and the corresponding value for the maximum and target blob counts per slot.
EF DevOps Engineer Barnabas Busa questioned how this array of records could be overridden in a worst-case scenario. EF DevOps Engineer Parithosh Jayanthi confirmed that if developers use an array, overrides require client teams to release software and node operators to upgrade to the new software versions. Alternatively, developers could implement EIP 7892 so that node operators can simply adjust a flag in their settings to halt future BPO forks if needed.
Nimbus client developer "Dustin" said he was not convinced about the idea of BPO forks in general. He asserted that if a BPO fork goes poorly on mainnet, there will be no quick and easy solution to roll back these upgrades in an emergency. However, to halt the BPO fork schedule a few months in advance if needed, Dustin said he is fine with the idea of using an array that would require client teams to ship a new software release.
Including BPO forks as a formality
Stokes noted that EIP 7892 is not formally included in Fusaka, even though developers are already working on the EIP for the upgrade. Thus, he suggested updating the status of the EIP to SFI. He said:
"This is maybe administrative at this point, but it sounds like we are going ahead and scheduling this BPO EIP for inclusion. Should we just go ahead and do that formally?"
Stoked also asked client teams if they would feel comfortable aiming to launch the first Fusaka developer-focused testnet, Fusaka Devnet 0, by May 20. Busa said this timeline largely depends on the readiness of EOF and execution layer (EL) client teams. He noted that it does not make sense for developers to launch Fusaka Devnet 0 with outdated implementations of EOF and developers should only launch the devnet if both the most updated versions of PeerDAS and EOF can be tested together on a devnet by May 20. Stokes agreed. He also said that he will SFI EIP 7892 as a formality. There were no objections.
Finalizing the Fusaka CFI List
Then, Stokes raised the topic of the broader CFI'd EIP list for Fusaka. He noted that developers should try to finalize the list on the call. Other than EIP 7892, which is now SFI'd for Fusaka, Stokes said the only other EIP developers wanted to consider for inclusion in the upgrade was EIP 7917, deterministic proposer lookahead. For background on this EIP, refer back to the call minutes for ACDC #154.
EF Researcher Ansgar Dietrichs expressed his support for CFI'ing EIP 7917. Lido DAO contributor Dmitry Gusakov supported CFI'ing EIP 7688, forward compatible consensus data structures. He explained that this EIP will benefit all applications that utilize Pectra features, specifically EIP 4788, beacon block root in the EVM. EIP 4788 reduces the trust assumptions needed to operate a decentralized staking application on Ethereum. About the motivation for EIP 7688 in Fusaka, Gusakov said:
"Currently, EigenLayer, Lido, and one more protocol, which I cannot remember by heart is actively using [EIP 4788] and there is like around 10 or more protocols who are currently working on implementing 4788 into their protocols and again, I want to point out that without 7688, they all will have to do some sort of a maintenance should beacon state change, which it most likely would in Fusaka. So, just want to point out again that by including 7688 into Fusaka we will save a lot of time and effort on the app layer for the app layer developers."
A Prysm client developer by the screen name "Radek" said that he is "mildly" against CFI'ing EIP 7917 because the EIP lacks testing. Stokes said that, based on his understanding, the CFI label refers to a "conditional approval that [an EIP] is worth looking at in more depth" for an upgrade. Tim Beiko, Ethereum Foundation Protocol Support and Chair of the ACDE Calls, wrote in the Zoom chat that the CFI labels refer to EIPs developers plan to include in an upgrade devnet. Beiko wrote:
"We should expect that not all CFI'd EIPs get eventually SFI'd."
Based on these understandings of the CFI label, Stokes recommended moving ahead with CFI'ing EIP 7917. Prysm developer "Potuz" expressed concerns about the complexity of this EIP saying that it will be "quite a big change" and the only EIP that changes the state of the CL, also called the Beacon Chain. Lighthouse developer "ETHDreamer" asked how prepared CL client teams are to make changes to beacon state.
Gusakov suggested SFI'ing both EIP 7917 and 7688 for the upgrade after Fusaka dubbed Glamsterdam. Stokes asked if delaying EIP 7917 to the fork after Fusaka would present problems for projects utilizing pre confirmations. Lin Oshitani, a researcher at Nethermind, responded saying:
"Without this EIP, what we are discussing right now is basically having a trusted oracle solution which would make sure that the lookout is available in the EVM. It will work and we can have pre confirmations but it is a hacky solution and also not ideal."
Stokes again suggested CFI'ing EIP 7917 and said that at the first sign of any complications related to its implementation that might delay other EIPs in Fusaka, developers can pull EIP 7917 out. There were no further comments or objections to Stokes' suggestion.
Finalizing the D(eclined)FI List
Stokes then asked about the inclusion of EIP 7688 into the CFI list. He caveated that developers should be wary about the inclusion of too many EIPs in Fusaka, saying:
"The obvious issue is we have this kitchen sink situation where we're like okay, we include this one, then we need this other one, and then it cascades which I think everyone is very aligned that we don't want to add a bunch of EIPs to Fusaka."
Lodestar client developers Phil Ngo and Gajinder Singh, as well as Barnabas Busa, expressed their support in the Zoom chat for the inclusion of EIP 7688 in the CFI list. Lighthouse developer Sean Anderson said Radek opposed the inclusion of EIP 7688.
ETHDreamer said that contrary to Gusakov's understanding, there are no code changes in Fusaka that will impact beacon state proofs, which means that there is no maintenance work that application developers will need to do if they utilize EIP 4788 after Pectra and EIP 7688 is not implemented in Fusaka. Teku developer Enrico Del Fante said that if developers are sure Fusaka does not negatively impact application developers, then EIP 7688 should be left out.
Stokes said developers will not be CFI'ing EIP 7688 and declining all other CL-focused EIPs proposed for inclusion in Fusaka. There were no objections to this decision.
That’s all for my summary on ACDC #155. If you made it this far into today’s post, well done! You are now officially caught up on the state of Ethereum protocol development and governance. Stay tuned for my insights on ACDC #155 coming out tomorrow.
In case you are not entirely exhausted by now, below are links for further reading on the topics discussed on ACDC #155:
Pectra Meta EIP featuring mainnet activation epoch and timestamp
EIP 7688 details, including the motivation and specification for the EIP
Discussion about changes to the Builder API in light of PeerDAS
Thank you for subscribing to ACD After Hours! If you like what you read, consider sharing it with a friend who might also enjoy the content.
I am actively sourcing feedback on the ACD After Hours newsletter. So, if today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by responding to the poll below or leaving a comment. Your feedback is appreciated!
Special thanks to Shinhye Kim for the graphics in this newsletter.