Ethereum All Core Developers Consensus Call #153 Writeup
On March 20, 2025, Ethereum developers met over Zoom for All Core Developers Consensus (ACDC) call #153. 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 #153, developers reconfirmed the plan for Pectra testing. Developers plan on upgrading the newly launched Hoodi testnet on Wednesday, March 26. Developers agreed to postpone setting a mainnet date for Pectra until they see how the upgrade on Hoodi goes and further testing of Pectra features on Hoodi.
They discussed the plan for history expiry given recent delays to Pectra mainnet activation. Developers acknowledged that the initial plan to drop pre-Merge history data from clients by May 1, 2025, is dependent on the activation of EIP 6110 in Pectra. Given that Pectra is not likely to go live on mainnet until after May, developers discussed other strategies to move forward with history expiry. They did not reach consensus on a new plan for history expiry and agreed to bring up the topic again on next week’s developer call.
Developers shared updates on the status of PeerDAS testing and open questions about PeerDAS design. Finally, developers discussed the inclusion of EIP 7688 in the Fusaka upgrade. Stokes said until client teams are farther along in their implementations of PeerDAS developers should not begin work on any more CL-focused EIPs for Fusaka.
Pectra Testing
Developers launched a new Ethereum public testnet called Hoodi on Monday, March 17. They have scheduled the Pectra upgrade on Hoodi to activate on Wednesday, March 26 at epoch 2048 or 14:37 UTC. Lodestar, Besu, Nethermind, and Lighthouse client teams have published updated releases that can be run on Hoodi. Teku, Reth, and Geth teams are still working on their releases for Hoodi.
Mario Havel, who is part of the Ethereum Foundation Protocol Support Team, has published a detailed post-mortem of the Holesky and Sepolia testnet incidents. Stokes asked developers to review the documents and consider ways to streamline and improve developers’ incident response efforts.
Then, Stokes highlighted a comment by Andrew Coathup, former editor of WeekInEthNews, suggesting potential dates of Pectra mainnet activation. Several call participants such as EF Researcher Justin Traglia, Consensys Engineer Paul Harris, EF DevOps Engineer Barnabas Busa, and EF Researcher Fredrik Svantes were in favor of postponing a decision on a date for Pectra mainnet activation until further testing for Pectra on Hoodi is completed. Stokes agreed with this sentiment.
History Expiry
Stokes asked developers about the plan for history expiry. He noted EIP 6110 in Pectra changes the process of validator deposit and verification such that it may not be possible for developers to safely remove deposit history from Ethereum until after Pectra is activated on Ethereum. One recommendation shared in the call was to drop history from Ethereum by the agreed May 1 deadline but only for block history before the launch of the validator deposit contract. Geth developer “Lightclient” pushed back on this recommendation saying that this strategy may unnecessarily complicate Ethereum as developers would then need to create new workarounds for sourcing this data after May 1 but before Pectra activation on mainnet and then again post Pectra mainnet activation. Stokes agreed that in his view it seemed simpler to move the May 1 deadline to a deadline after Pectra mainnet activation.
EF Protocol Support Lead Tim Beiko said developers should ensure that any history expiry efforts are well-tested on an Ethereum testnet before they are implemented on mainnet. EF DevOps Engineer Parithosh Jayanthi noted that the only Ethereum public testnet with pre-Merge upgrade history for testing history expiry is the Sepolia testnet. A developer by the screen name “Nishant” said he knows of client teams like Nethermind that are already testing history expiry on Sepolia. Geth developer Felix Lange emphasized that history expiry will mainly impact client functionality and should not have large ramifications on networking or overall protocol stability. Lange added that for client teams to finalize their plans for history expiry they need to reach consensus about the versioning of the Ethereum Wire Protocol, which facilitates communication between Ethereum nodes.
Jayanthi recommended using the May 1 deadline as the deadline for all clients to activate history expiry on the Sepolia testnet. Then, once Pectra is live on mainnet, developers can pick a new date for rolling out history expiry on mainnet as well. Stokes said that he would add history expiry as a topic for discussion on next week’s call for wider discussion with EL-focused developers.
Pectra Devnet 6
Developers are testing a higher block gas limit on Pectra Devnet 6. Busa said that developers have raised the limit to 60m gas on the devnet and so far, are only seeing issues with the Geth and Lighthouse client pair. Busa noted that initially, all nodes operating on 8GB of RAM struggled to perform with the limit increase so all nodes on the devnet are running with 16GB of RAM. He asked the Geth and Lighthouse teams to investigate the issues on Pectra Devnet 6.
PeerDAS
Developers shared a variety of updates related to client implementations and testing for PeerDAS. The overall sentiment shared by the EF DevOps team was the need for more client team attention and resources to PeerDAS development. Stokes highlighted a minor PeerDAS specifications change proposed by Traglia for review by client teams. Developers also discussed the design for validator custody, which refers to the data validators are required to download and verify. In the current PeerDAS specifications, validator custody which is measured by the number of data “columns” scales with the number of validators. However, there are events such as validator consolidations where the number of validators under the control of a node operator can change rapidly. Developers discussed changes to the custody refresh rate for validators to account for these events. Stokes said that for now the PeerDAS specifications should be left untouched and client teams can make a note in their implementations about how they handle the impact of dynamic changes in the number of validators on validator custody.
EIP-7688
Stokes announced that EIP 7688, forward compatible consensus data structures, has been proposed for inclusion in the Fusaka upgrade. Dmitriy Gusakov, Tech Lead for the Lido DAO, explained that EIP 7688 is an important code change for any application that will make use of EIP 4788. EIP 4788 is an EIP that will be activated in the Pectra upgrade that enables smart contract to verify CL data, said Gusakov. While this unlocks many use cases for minimizing the amount of trust needed to stake on Ethereum through a smart contract, it does introduce the risk of forcing applications to issue upgrades alongside Ethereum network-wide upgrades. Gusakov said EIP 7688 addresses this risk so that changes to the data structure of the CL can be contained and prevented from impacting applications like Lido, Rocketpool, and any others utilizing the features of EIP 4788. He also added that EIP 7688 is not an EIP that would create large overhead for client teams in terms of implementation and testing.
Nixo Rokish, who is part of the EF Protocol Support team, shared a comment from the Rocketpool team that echoed Gusakov’s comments about EIP 7688. Nimbus developer Etan Kissling, who championed the inclusion of stable containers in the Pectra upgrade, said that EIP 7688 has the added benefit of potentially helping developers reduce the Beacon Chain state size. Developers will be able to delete obsolete parts of the Beacon state such as additional voting on validator deposits without concern about these actions reindexing Beacon state data.
Stokes noted that this is an EIP that could positively impact not only staking pools but restaking protocols like EigenLayer and Layer-2 rollups. However, he said that developers should focus on implementing PeerDAS for Fusaka first before adding any new CL-focused EIPs into the upgrade. Kissling wrote in the Zoom chat that developers should include EIP 7688 in the Glamsterdam upgrade if not for Fusaka.
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.