ACDC #154: Call Minutes
The call where developers delayed Pectra by a week
Good evening,
Today, Ethereum developers agreed to push back the Pectra mainnet activation date from April 30 to May 7. They also agreed to strongly consider two new consensus layer (CL) focused EIPs in Fusaka, the next upgrade after Pectra.
You can find the full call summary for the latest All Core Developers (ACD) call, ACDC #154, below.
Yours Truly,
Christine D. Kim
Date and time: April 3, 2025, 14:00-15:30 UTC
Duration: 90 minutes
Hoodi Updates
Ethereum Foundation (EF) Developer Operations Engineer Parithosh Jayanthi said an initial round of testing on Pectra features has been completed on the Hoodi testnet. “Pk910”, also a EF DevOps Engineer, noted that he was surprised at how long it takes for the network to process validator “top up” deposits, which are deposits of staked ETH to the balance of an existing active validator. Pk910 said:
“There is another restriction that limits the number of [top up] deposit requests per epoch to 16, and that basically leads to a reduced amount of ETH that is entering the validator set to a maximum of 16 ETH per epoch if you have a lot of top up deposits.”
Pk910 asked consensus layer (CL) developers on the call whether this design was intentional. EF Research Co-lead and Chair of the ACDC calls Alex Stokes confirmed that it was and that developers did not expect a high volume of top up deposits to occur on Ethereum mainnet. Pk910 shared concerns about a potential attack vector where a malicious actor could keep topping up validators at zero cost and backlog the validator deposit queue. Stokes said Consensys Lead Researcher Mikhail Kalinin had been looking into this concern and asked if Kalinin was on the call. Kalinin was not. Stokes said that he would follow up asynchronously on this matter after the call.
Stokes asked client teams about testing related to the performance of validator attestation aggregations on Hoodi. Terence Tsao, a Prysm client developer at Offchain Labs, shared analysis on how the latest version of the Prysm client packs attestations into a block. He noted that all clients pack attestations slightly differently and asked if other client teams had additional analysis to share. Enrico Del Fante, a Teku developer at Consensys, shared analysis on the Teku client and how it differs from Prysm. He noted that his team will run more experiments to test the performance of their client when it comes to attestation packing.
Jayanthi said that all basic validator activities related to EIP 7251, increase the MAX_EFFECTIVE_BALANCE, have been tested on Hoodi and seem to work fine so far on the testnet.
Stokes reminded developers that testing for non-finality events are ongoing on the Holesky testnet.
Pectra Mainnet Timing
On last week’s All Core Developers (ACD) call, ACDE #208, developers agreed to tenatively scheduled Pectra mainnet activation for April 30. In light of ongoing testing efforts on Hoodi and Holesky, Stokes asked call participants if they wanted to change this date. Del Fante wrote in the Zoom chat that his preference is for “mid-May”. Sean Anderson, a Lighthouse developer at Sigma Prime, said that his team is advocating for a mainnet activation date on May 7. Del Fante clarified in the Zoom chat that May 7 also works for his team. Representatives from the Erigon and Lodestar client teams also agreed with this proposed date.
Tim Beiko, who is part of the EF Protocol Support team and also chairs the ACDE calls, chimed in to clarify that a mainnet Pectra activation date on May 7 would mean that client teams should have their final releases for the upgrade ready to go at the latest by April 21. Beiko can then create an Ethereum Foundation blog post announcing the scheduled upgrade on mainnet that features final client releases. This would give Ethereum node operators at least two weeks to upgrade their software in time for the upgrade. Beiko noted that April 21, Easter Monday, is a major holiday for some people. There were no objections to the proposed deadline for final client releases.
PeerDAS Updates
Then, Stokes shared updates on blob scaling efforts. He noted that client teams are busy with implementing new PeerDAS specifications for PeerDAS Devnet 6 and fixing any outstanding bugs from PeerDAS Devnet 5.
Stokes also shared his proposal for incrementally raising the blob target and max limits after the Fusaka upgrade in an automated fashion. The idea for an incremental and automated increase to blob capacity is not new and was initially raised by “Protolambda”, an engineer at OP Labs, on ACDC #149. Over the months, it appears consensus has been growing for the idea among developers. The proposal by Stokes shared on the call outlines a specific schedule for “Blob Parameter Only” (BPO) forks after Fusaka. The idea for BPO forks has been formalized as an Ethereum Improvement Proposal (EIP) with the EIP number 7892 by “ETHDreamer”, a Lighthouse developer at Sigma Prime.
Stokes said that his proposal to double the blob capacity every 2 months after the Fusaka upgrade can be adjusted after further testing of PeerDAS on devnets. He said developers do not need to set a schedule for BPO forks immediately but wanted to raise it on the call for everyone’s awareness.
EF Researcher Ansgar Dietrichs said that he is in favor of BPO forks but developers should be careful about setting the maximum blob capacity beyond what developers have already tested and know is safe on devnets. A call participant by the screen name “Kasey” added that developers should schedule a rollback of a BPO fork shortly after they are activated on mainnet to ensure that the rollback mechanism for BPO forks work in production and can be executed without issue.
Stokes highlighted a comment from Ethereum co-founder Vitalik Buterin offering alternative strategies for activating BPO forks such as through the consensus of validators, as opposed to developers. Unsurprisingly, developers were not keen about the idea of giving control over blob scaling to validators. Roman Krasiuk, a Reth developer at Paradigm, said in the Zoom chat this would create “coordination overhead.” Dietrichs expressed concerns about complexity. Stokes said validators are not as attentive as developers to the protocol.
About the implementation of EIP 7892, ETHDreamer said he expected the work from client teams to be “fairly easy” and “simple”. “Dustin”, a Nimbus developer at Status, commented on the implementation work that would likely be needed for the EIP from the perspective of the Nimbus client. Dustin said:
It’s not a terribly difficult software engineering exercise but it would look a little alien in the codebase but it’s fine.
EF DevOps Engineer Barnabas Busa asked if EIP 7892 could be implemented in Fusaka without delaying the upgrade. ETHDreamer responded yes.
Trent Van Epps from the EF chimed in to flag comments by “Dapplion”, a Lighthouse developer at Sigma Prime, in the Zoom chat about increasing the buffer time between final client releases and Pectra activation on mainnet. This was not a suggestion to change the mainnet activation date of May 7, only to pull up the deadline for final client releases.
Stokes asked developers if they should move the deadline earlier to allow more time for node operators to prepare for the upgrade. Beiko said that for the last two Ethereum upgrades, Dencun and Shapella, the buffer period was just over two weeks but that he did not have a strong opinion about increasing it to three weeks for Pectra.
Del Fante said developers could increase the buffer to three weeks, meaning client teams would only have roughly 10 days from the call date to prepare final releases, because any additional changes to these releases are likely to be non-critical and optional for users. He said:
At the end, what we have now is still okay. We are just working on improvements on the attestation pool that can anyways be shifted a little bit later and we can definitely provide an early version with what we have now that is fully Pectra compatible.
Beiko pushed back on changing the links to client releases in the Pectra mainnet announcement post after publishing. Del Fante clarified that optional client releases would not warrant changes or updates to the announcement post. Busa said an additional week to test final client releases may be beneficial from a testing perspective. Jayanthi said this testing can be done on a rolling basis as client teams become ready with their updated software.
Stokes said client teams should keep the May 7 mainnet activation date and release client versions as soon as ready. If all client releases are ready before April 21, then the announcement post can be published sooner. There were no further comments on this topic.
Fusaka Scoping Discussion
Stokes kicked off the discussion for scoping out Fusaka, the next Ethereum upgrade after Pectra, by stating that from his perspective there is consensus on including PeerDAS and BPO forks in Fulu, the CL-focused side of the Fusaka upgrade.
ETHDreamer proposed the inclusion of EIP 7917, deterministic proposer lookahead. He emphasized this EIP as an important protocol change for supporting preconfirmations and based rollups on Ethereum. He added that the EIP is a relatively small change that he expects client teams to implement easily. ETHDreamer pointed to a GitHub document outlining what changes to code EIP 7917 requires in the Lighthouse client.
About the motivation for EIP 7917, Dapplion added:
Preconfs are really important for the protocol to have based and native rollups that are at parity with more scalable L1s and centralized sequencers. Therefore, this [EIP] materially advances the [Ethereum] roadmap.
“Potuz”, a Prysm developer at Offchain Labs, expressed concerns in the Zoom chat about how this EIP could setback research on Single Secret Leader Election (SSLE).
In support of the EIP, EF Researcher Justin Drake said:
In the case of improving [based rollup] latency, my hope was that we didn’t need any hard fork. Turns out, I was wrong. We do need a small one and my hope is that the size of the fork relative to the outsized benefits that we could get … makes this proposition very attractive to me. Now, one thing that was mentioned is around the timelines for adoption. Adoption can only happen after we’ve actually shipped it and built it and I think having this change will significantly shorten the timeline for [based rollup] adoption.
Another EIP raised for consideration in Pectra is EIP 7808, fork choice enforced inclusion lists (FOCIL). Stokes briefly mentioned EIP 7808 but noted that there is “pretty unanimous consensus” to delay this EIP to a future fork.
EF Researcher Anders Elowsson presented EIP 7918, blob base fee bounded by execution cost. This EIP adjusts the blob fee mechanism to reduce blob fee volatility and help further scale blob capacity. Given that the EIP primarily suggests changes to the execution layer (EL), Stokes recommended that Elowsson raise this proposal for consideration on next week’s ACDE call.
Gajinder Singh, a Lodestar and EthereumJS developer at g11tech, proposed EIP 7898, uncouple execution payload from beacon block. This would enable the CL to receive larger sized blocks from the EL by parallelizing components of block processing. Some developers raised concerns about the complexity of this EIP.
Stokes highlighted EIP 7688, forward compatible consensus data structures, as another EIP proposed for inclusion in Fusaka. Tsao proposed a deprecation of mplex in favor of yamux as the multiplexing protocol supported by all CL clients. Potuz raised EIP 7732, enshrined proposer builder separation (ePBS), for inclusion in Fusaka but retracted it after confirming that developers do intend to ship Fusaka by the end of the year.
Stokes asked developers which of the EIPs mentioned on the call should be advanced for more serious consideration in Fusaka. Beiko stressed that all CL-focused EIPs, aside from PeerDAS, are labelled as “proposed for inclusion” or PFI. The next stage is to advance a subset to “considered for inclusion” or CFI and only advance a subset of CFI’d EIPs to “scheduled for inclusion” or SFI once PeerDAS is further along in its implementation on devnets. This way Beiko said developers can iteratively increase the size of upgrade devnets and avoid making the same mistake they made with Pectra by overcommitting to too many EIPs for an upgrade.
There was some pushback in the Zoom chat about these labels for EIPs. Kasey said that in his view the CFI label is “too 1 dimensional” and called for more defined distinctions between the status of EIPs for an upgrade.
Stokes asked if EIP 7917 should be CFI’d. Potuz expressed concerns about the EIP’s inclusion due to insufficient time for review. Saulius Grigaitis, CTO of Grandine, expressed his support for the EIP. Stokes said that since there are no objections to labelling EIP 7917 as CFI, developers will do that.
Stokes asked if EIP 7688 should be CFI’d or tabled. Representatives from the Teku and Lodestar client teams shared that they have no strong opinions about the EIP but that they have implemented the proposal already and would not be opposed to its inclusion in Fusaka. Stokes refrained from making any decision about this EIP.
Stokes asked if EIP 7892 should be CFI’d. There were no responses on the call. Stokes said that he would assume the silence as an agreement to CFI EIP 7892.
Stokes asked if developers wanted to discuss any other EIP for Fusaka. There were no responses.
EIP 7922
Then, Stokes gave the floor to EF Researcher Mike Neuder to present EIP 7922, dynamic exit queue rate limit. Stokes explained that this is not an EIP specifically for Fusaka. Neuder clarified that the EIP could be included in the upgrade if there is sufficient consensus for it but that this is not critical or likely given the expected timeline for the upgrade.
EIP 7922 introduces greater flexibility to the rate at which validators can exit Ethereum. At present, the rate of exits is limited to 16 validators per epoch. This EIP introduces a dynamic validator churn limit based on historical or past validator exit activity within a rolling window of time. Mallesh Pai, Principal Researcher at Consensys and a co-author on EIP 7922, explained this mechanism could help speed up validator exits by 8x without negatively impacting network security.
Neuder pointed to two other related proposals that would also help optimize validator operations. The first is a proposal to process full and partial validator withdrawals through separate queues. The second is a mechanism for validators to move forward in the exit queue through attaching an optional fee to their exit requests. At present, the exit queue is ordered on a first come first serve basis.
Neuder directed call participants to the dedicated Ethresearch post for further discussion on the EIP and related topics. He also encouraged people to reach out to him directly with questions or feedback.
That’s all for my summary on ACDC #154. You are now officially caught up on the state of Ethereum protocol development and governance. Below are links for further reading on some of the topics discussed on today’s ACD call.