Ethereum All Core Developers Consensus Call #152 Writeup
On March 6, 2025, Ethereum developers met over Zoom for All Core Developers Consensus (ACDC) call #152. The call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. The ACDC calls are a biweekly meeting series where developers discuss and coordinate changes to Ethereum's consensus layer (CL), also known as the Beacon Chain.
On ACDC #152, developers agreed on a new strategy for testing Pectra in light of how the Holesky and Sepolia upgrades went. Developers will continue to work on restoring Holesky to a stable state, which they estimate will take roughly three weeks, and in the meanwhile will launch a shadow fork of Holesky, which will inherit the exact same state and on-chain environment as the original public testnet.
Holesky Status and Recovery
The strategy to propel the Holesky testnet into a state of finalization decided on the prior ACD call, ACDE #206, did not go according to plan. Holesky remains in a state of prolonged non-finalization. Lighthouse developer Sean Anderson shared that his team has implemented enough mitigations to their client to ensure Lighthouse nodes on Holesky can work through long periods of non-finalization. However, he added there are bigger fixes and features that they are still working on to address more “fundamental issues” about their client.
A developer by the screen name “Manu” created an analysis for estimating when Holesky will reach a state of finalization. He estimated that finality should be reached by March 28. “We don’t really want to go to mainnet until different users and different stakeholders and things can test out the new features that we have in Pectra and right now they can’t really do that. Holesky was the place to do that and Holesky is not really useable right now,” said Stokes.
EF Developer Operations Engineer Parithosh Jayanthi shared a document detailing the paths forward for Pectra testing in light of the Holesky testnet failure. Jayanthi asked on the call if developers wanted to continue using Holesky as a public Ethereum testnet once the testnet has finalized or replace Holesky entirely with a new network. The broad consensus reached on the call was to restore Holesky for long-term use.
Lido DAO contributor Ivan Metrikin stressed that it is “critical” to the Lido development team for testing Pectra that Holesky works. “Without Holesky finalizing, we’ll have a very hard time like almost impossible to test Pectra related changes to the protocol but also to test whatever integration we have with other protocols that use Lido,” said Metrikin.
Stokes asked if the Lido team could adequately test Pectra features and integrations on a clone, that is shadow fork, of the Holesky testnet. Jayanthi highlighted that at the smart contract level, the applications would look exactly the same as what is deployed on Holesky. He added that he could also ensure that the shadow fork is backed by the same number of validators with a similar client diversity as the existing Holesky testnet.
Metrikin said that a shadow fork of Holesky would be adequate then for Lido’s testing needs. Jayanthi said his team could get this new testnet up and running next week. Stokes said developers should get the shadow fork running soon so that testing can move forward for Pectra and not create any delays to the upgrade. Prysm developer “Potuz” shared concerns that the number and distribution of nodes on the shadow fork may not be adequate for testing Pectra’s impact on Ethereum’s networking layer. Jayanthi pushed back on Potuz’s concerns saying that the Holesky testnet is roughly 10 times smaller in terms of the number of nodes than Ethereum mainnet and the shadow fork could be spun up by the same number of nodes as Holesky, about 1,000 nodes.
A developer by the screen name “Radek” said that he is worried about users abandoning the Holesky testnet in favor of the interim shadow fork. Stokes said that developers can commit to shutting down the shadow fork once Holesky is stable again to address this concern. Metrikin said his team can focus on both in the short-term, testing Pectra on the shadow fork and working on restoring Lido’s functionality on Holesky.
Mario Havel, who works for the EF, shared a reminder in the Zoom chat that the Ephemery testnet is still running and has Pectra activated so it can be used for testing small validator set ups in the interim as well.
Pectra Devnet-7 Updates
Developers launched Pectra Devnet 7 in between the Holesky testnet failure and the Sepolia upgrade. Jayanthi shared that Devnet 7 has the same validator size as Ethereum mainnet, which is a metric not to be confused with the number of nodes on Ethereum. Though the validator set of Pectra Devnet 7 is geographically distributed, the testnet does not feature a vibrant testing environment for applications as it does not feature the same smart contracts and apps as what has been deployed on Holesky. Jayanthi said he would prefer to take the devnet down and focus resources on the Holesky shadow fork.
“The shadow fork will become a testnet for Pectra and then Holesky can become the testnet for Fusaka because it will probably be as healthy as Holesky was before the accident by the time that we move on to the next hard fork,” said Radek.
Developers reaffirmed their intention to create a clone or shadow fork of Holesky and keep it running until the original Holesky testnet is stable and reaches a state of finalization. As Radek notes above, it may not be feasible for developers to rely on Holesky at all for Pectra testing as the testnet is estimated to take roughly three weeks to finalize.
EF Researcher Ansgar Dietrichs stressed that Pectra should not delay preparations for Fusaka, which contains the blob scaling upgrade PeerDAS. He wrote in the Zoom chat that Fusaka mainnet activation sometime in Q3 2025 is “a realistic target”.
A developer by the screen name “Sacha” said developers should consider a longer-lived shadow fork of Holesky as additional testing infrastructure for Ethereum. However, he said that this is a discussion that developers can postpone until Holesky is restored. Jayanthi reconfirmed that both Pectra Devnet 7 and the Mekong testnet will be deprecated over the next few days. There were no objections to this on the call.
Sepolia Review
Developers upgraded the Sepolia testnet on Wednesday, March 5. There was a bug discovered in clients that caused Sepolia validators to produce empty blocks. The bug was resolved within a matter of hours after Pectra activation and the Sepolia testnet has since recovered fully from the incident. Stokes said the testnet is “the healthiest I’ve ever seen it”.
Mario Vega, who works as part of the EF’s testing team, raised a proposal to update EIP 6110, supply validator deposits on chain, to ensure consistency in implementation between clients for Pectra. It is a proposal by EthereumJS developer Jochem Brouwer. Vega stressed that developers should reach a decision quickly on this proposal as its inclusion in Pectra would require updates to Pectra test cases.
There was pushback to Brouwer’s proposal from multiple developers on the call. Nethermind developer Ahmad Bitar said, “I don’t understand why we’re discussing implementation details… Implementation mechanisms are always the choice of a client. Saying that using a specific library can then lead to this library breaking or whatever, this is not a reasoning that we usually use to choose implementations. Every client is always free to choose whatever implementation is suitable for a precompile.”
Geth developer Marius van der Wijden responded to this comment saying that the issue was not stemming from the use of different libraries but rather the desire to implement a test case for which all clients will fail if they do not hardcode and spec out the “parse_deposit_data” feature of EIP 6110. Stokes recommended moving the discussion on EIP 6110 off the call for the sake of time and encouraged developers to try and reach a decision about the Brouwer’s proposal by the next ACD call.
Pectra Mainnet Timing
Stokes said that developers will discuss the timing for Pectra mainnet activation after seeing how the Holesky shadow fork and Holesky restoration efforts proceed.
Van der Wijden shared a brief update on two issues identified in Pectra BLS precompiles through the ongoing Pectra bug bounty competition. The first issue was a matter of “weirdly written” specifications, said Van Der Wijden. This has since been corrected. The second issue, also corrected, was related to evmone, a C++ implementation of the EVM. Both issues were found through fuzzing and additional test cases have been created in light of them.
Mikhail Kalinin, an Ethereum developer at Consensys, highlighted an issue identified about EIP 7002, execution layer triggerable withdrawal, through the bounty competition that he is investigating. “There is a griefing vector in the fee mechanism but first of all, there is no DOS vector in it. The logic here is that the model of attack would be how much it will cost for an attacker to block the withdrawal functionality for a certain period of time,” said Kalinin.
Kalinin said that his opinion is to keep the EIP unchanged for now, which Stokes was also in favor of this to avoid further delays to Pectra. Potuz recommended more analysis on the hypothetical griefing scenarios. Stokes said he would find someone to take a look.
PeerDAS Devnet Updates
Manu shared an update on PeerDAS Devnet 5. The devnet has been running for 2 weeks and all clients are performing well on the network. There is 100% participation. However, all the nodes are “supernodes” meaning there is data sharding occurring on the devnet.
EF Developer Operations Engineer Barnabas Busa suggested launching a new PeerDAS devnet next week. Anderson requested feedback on two open pull requests to PeerDAS specifications impacting the execution layer. Stokes said he would make sure these are on the agenda for next week’s ACD call.
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.