Ethereum All Core Developers Execution Call #207 Writeup
On March 13, 2025, Ethereum protocol developers met over Zoom for All Core Developers Execution (ACDE) Call #207. This week, the call was chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko. The ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum.
On ACDE #207, developers agreed to launch a new long-lived Ethereum test network called Hoodi. Hoodi will be configured to mimic Ethereum mainnet as closely as possible and launch with a validator set that is similar in size and stake distribution as Ethereum mainnet. Developers agreed to launch Hoodi on Monday, March 17, and activate the Pectra upgrade 10 days after on Wednesday, March 26.
If the Pectra upgrade on Hoodi goes smoothly and there are no major bugs discovered in clients, developers may proceed to pick a mainnet activation date for the Pectra upgrade as early as 30 days from the Hoodi testnet upgrade date. Developers are now estimating the earliest Pectra could go live on Ethereum mainnet is late April or early May.
Holesky Path Forward
EF Developer Operations Engineer Parithosh Jayanthi shared an update on the Holesky testnet status. After roughly 2 weeks of prolonged non-finalization, the testnet reached finalization on Monday, March 10. Finalization is a state of heightened security for Ethereum and Ethereum testnets. They also function as checkpoints that help nodes sync to Ethereum and correctly validate the same head of the chain.
Due to the prolonged period of non-finality, there are roughly 1 million validators that need to be processed through the Holesky exit queue. This will take roughly 1.5 years for the network to fully process due to the validator churn limit which caps the maximum number of validator exits per epoch to 8. Until the backlog of validator exits is resolved, infrastructure providers on Holesky such as staking pools like Lido will not be able to test new validator exits.
So, Jayanthi proposed four possible solutions to address the testing needs of infrastructure providers.
Set up a new third Ethereum testnet called Hoodi for infrastructure providers.
Use Pectra Devnet 6 as a third testnet until June.
Launch a short-lived Holesky shadow fork for testing purposes only until Pectra goes live on Ethereum mainnet.
Hard fork the original Holesky testnet to empty out the validator exit queue.
Jayanthi stressed that none of these options would abandon Holesky for testing purposes entirely. He also noted that there is a proposal to shorten the lifespan of public Ethereum testnets from five years to three.
Beiko said that from his survey of Ethereum stakeholders, most are supportive of Jayanthi’s first recommendation, the creation of a new public testnet. Ivan A. Metrikin, VP of Engineering at Lido, said that his team prefers the fourth option because all of Lido’s smart contracts, tooling, and various integrations with other applications are all set up on Holesky already and it would take multiple weeks for the Lido team to re-deploy everything on a new testnet.
It was difficult for developers to gauge how complicated coordinating a hard fork to empty the validator queue on Holesky would be because there was minimal representation from consensus layer (CL) client teams on this ACD call. Therefore, developers agreed to table the discussion on Jayanthi’s fourth recommendation to next Monday’s testing call and encourage CL developers in the meanwhile to join Monday’s call for further discussion.
Jayanthi recommended developers proceed with launching a new testnet, Hoodi, irrespective of the decision-making process for a hard fork on Holesky because in any case developers will need a new Ethereum testnet. Hoodi will be needed as the testing grounds for infrastructure providers if the exit queue on Holesky is not dealt with but if developers do hard fork Holesky and initiate an irregular state change to empty the exit queue on Holesky, client software for the testnet will have deviated extensively from mainnet parameters and thus, developers will need to deprecate it shortly after Pectra goes live on mainnet.
Beiko agreed and recommended that developers move forward with launching Hoodi and discuss on Monday’s testing call, the feasibility of upgrading Holesky to empty the exit queue.
About Hoodi, Jayanthi asked developers if they preferred the testnet’s validator set size to be bigger, similar, or smaller than the size of mainnet. In Jayanthi's view, Hoodi could maintain a smaller validator set size than mainnet and be the testnet primarily geared for external Ethereum stakeholders to test their infrastructure, whilst Holesky could be maintained as the testnet for Ethereum protocol developers to test the limits of network stability and security.
A few developers including a developer by the screen name “Dustin” and Grandine developer Saulius Grigaitis pushed back on a testnet that would be smaller than mainnet. Jayanthi recommended then to launch Hoodi with as similar parameters, configurations, and validator set size to mainnet as possible to ensure the best testing grounds for mainnet deployments.
Beiko recommended apps start migrating their infrastructure to Hoodi once the testnet is live. He affirmed that with or without a hard fork on Holesky, Holesky will not be the main testnet for apps and smart contract developers to test their mainnet deployments long-term as Holesky will either be deprecated shortly after Pectra or used by protocol developers as a testing environment for stress testing Ethereum’s security and liveness.
About the parameters for launching Hoodi, Jayanthi said that the testnet could go live with a genesis state post Dencun upgrade. The testnet could also have pre-configured settings to activate the Pectra upgrade one week after launch. Jayanthi recommended working out the specifics for coordinating these testnet parameters offline on the Ethereum R&D Discord.
Pectra Mainnet Timeline
Beiko asked what client teams want to see in terms of testing before scheduling the Pectra upgrade on Ethereum mainnet.
EF Developer Operations Engineer Barnabas Busa said that he wants to see the Pectra upgrade go live on Hoodi “without pain” first. Teku developer Enrico Del Fante said he would like to see the Pectra upgrade live on “a big network like Holesky” with more than 95% participation from validators so that developers can double check validator behavior such as attestation aggregations. Metrikin said redeploying Lido’s infrastructure to test Pectra on a new testnet like Hoodi will take a month or a month and half.
Prysm developer “Potuz” emphasized that developers should double check the functionality of the slasher before moving to deploy Pectra on mainnet. He said that he is worried the slasher did not work properly through the Holesky testnet failure and this software must be fixed before upgrading Ethereum mainnet. As background, slasher is the name of the software that can detect slashable events from validators and report them to the protocol for additional rewards. It is an optional piece of software that beacon node operators can run in addition to their validator software.
A developer by the screen name “spencer-tb” added that he would like to see all EL client teams passing hive tests and a re-review of Pectra tests to ensure full test coverage of all Pectra EIPs.
EF Researcher Carl Beekhuizen said that developers should not waste time trying to upgrade Holesky just to speed up the Pectra mainnet timeline. “I personally feel like we’re optimizing for the wrong thing here and that’s to get to mainnet as soon as possible, which obviously is great, but I think another very important resource here is client [developer] time and attention. If we are having to wait for Lido, etc., to deploy things, client devs can be working on upcoming forks, and more specifically, PeerDAS, which brings much bigger gains further down the line,” said Beekhuizen.
Several call participants, such as Geth developer Marius van der Wijden, Jayanthi, and Beiko, were in favor of the idea of only focusing on the new testnet launch and not proceeding with a hard fork on Holesky. Metrikin reminded developers that this would mean delay to Pectra mainnet activation to allow for his team to sufficiently test Pectra features on Hoodi. Potuz asked if developers could speed up this process for testing by re-deploying smart contracts live on Holesky at Hoodi genesis. Van der Wijden said this is not possible as EL clients cannot import large amounts of data into the genesis state of a network.
About supporting apps like Lido with testing infrastructure beyond Hoodi, van der Wijden said, “We are not going to go to mainnet before [Lido has] tested their stuff but I also don’t think we like need to spin up another network, spin up a shadow fork for them to test, and spend like hundreds of thousands of dollars for that. We just do this network [Hoodi]. Everyone can maybe chill for a bit, maybe work on their client. I think there’s a lot of client improvements that can be done that this Holesky incident kind of showed. Especially in Geth, we have a bunch of things that we would like to do that we don’t have the time for if we’re always going after the next hard fork and so we should just schedule Hoodi and then work on the other stuff.”
Nethermind developer Ahmad Bitar added that replicating state from Holesky on Hoodi will not solve all the testing needs for application developers as there are other dependencies and tooling that apps rely on outside of contract code. Beiko asked how much time client teams would want before Pectra is activated on Hoodi. He asked whether client teams would want additional time to prepare new client releases for Pectra on Hoodi. The consensus among call participants was to launch the testnet on Monday and then activate Pectra 10 days later on Wednesday, March 26.
The EF DevOps team will initially operate all validators on behalf of client teams and migrate the keys for operating these validators as client teams become ready with infrastructure to support Hoodi. Busa wrote in the Zoom chat, “1.2m validator keys, 50k validator keys per staking provider, 50k validator keys per client team. So approx. 5-10 machines per client team/staking providers.” Beiko said developers can coordinate specifics for Hoodi testnet ETH faucets asynchronously from the call.
System Contract Calls Error Handling
Erigon developer Andrew Ashikhmin highlighted a change that is needed to Pectra specifications. The change would codify how validators should behave in the event a system contract transaction fails or reverts for any reason, such as insufficient gas. A developer by the screen name “Felix” affirmed that the behavior by validators should be to treat the block in which the transaction is contained as invalid. Spencer-tb also raised the need for developers to settle on the ABI decoding matter impacting EIP 6110 raised on ACDC #152. Beiko recommended moving both discussions related to Pectra specifications to next Monday’s testing call.
PeerDAS
Beiko raised an update to PeerDAS specifications proposed by Felix and an accompanying change to the proposal which would update RPC and Engine API definitions accordingly. Beiko said that developers should try to review these updates asynchronously and finalize them soon.
Next, Beiko mentioned that there has been discussion among developers to proceed with PeerDAS testing independently of EOF. EF Ipsilon team lead Danno Ferrin said that disabling EOF on Fusaka devnets for testing PeerDAS independently of EOF is a simple change but requires work. Beiko recommended tabling the discussion on this for a few weeks until Ferrin has more updates.
Fusaka Fork Deadlines
On the topic of scoping out the Fusaka fork, Beiko recommended readjusting the deadlines for Fusaka scoping discussions considering the recent delays to Pectra mainnet activation. He recommended March 24 as the deadline to propose EIPs for Fusaka and two weeks thereafter on March 31 as the deadline for client teams to submit proposals for the subset of EIPs that should be included in the Fusaka fork. “Hopefully, this means that on the All Core Devs on April 3 and 10 we are able to finalize the scope,” said Beiko. Besu developer Justin Florentine was in favor of Beiko’s proposal.
Beiko also said that EIP authors should open a pull request to the Fusaka meta EIP, EIP 7607, on GitHub to ensure review of their EIP for the Fusaka upgrade. He stressed that due to limited time on the ACD calls, not all EIPs can be presented on the calls so EIP authors should share as much information as possible about their proposals asynchronously from the ACD calls. Beiko then added that it would be helpful if client teams could share their views on EIPs that should be declined for inclusion (DFI) from Fusaka in advance in addition to what they view as the list of EIPs that should be included in the fork. This way developers do not waste time discussing EIPs that most client teams do not think should go into the fork.
EIP-4444 Progress Updates
Beiko highlighted that there is a workshop on the Portal Network happening this week. The Portal Network is an alternative network for servicing historical block data that has been pruned from Ethereum nodes. Felix shared color on a pull request to the Ethereum execution API that will create a distinct error message when a user is requesting any data from a node that has been pruned. Client teams agreed on a prior ACD call to start pruning data from Ethereum nodes by May 1, 2025.
Beiko mentioned that there are two EIP presentations that developers did not have time to discuss on the call. He highlighted the links to these presentation slides in the call agenda. He also noted that there was an agenda item to discuss stateless clients that developers did not have time to discuss. Beiko said he would follow up with the point person on stateless clients for information on where developers can discuss this topic asynchronously.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsement of any of the stablecoins mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned, hedged and sold or may own, hedge and sell investments in some of the digital assets and protocols discussed in this document. Affiliates of Galaxy Digital may also lend to some of the protocols discussed in this document, the underlying collateral of which could be the native token subject to liquidation in the event of a margin call or closeout. The economic result of closing out the protocol loan could directly conflict with other Galaxy affiliates that hold investments in, and support, such token. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email contact@galaxydigital.io. ©Copyright Galaxy Digital Holdings LP 2025. All rights reserved.