Ethereum All Core Developers Consensus Call #151 Writeup
On February 20, 2025, Ethereum developers met over Zoom for All Core Developers Consensus (ACDC) call #151. 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 #151, developers discussed client teams’ readiness for the Pectra upgrade on the Holesky testnet and the next steps for PeerDAS Devnet 5. Developers also agreed to finalize EIP 7872, max blob flag for local builders, and EIP 7870, hardware and bandwidth recommendations for validators and full nodes.
Pectra Devnet 6
EF Developer Operations Engineer “Pk910” said all updated clients on Pectra Devnet 6 are running smoothly and the network is stable. EF Security Researcher Justin Traglia added that testing for the MEV workflow on the devnet is also going well. Traglia noted that there is an issue with the Flashbots builder that the Flashbots team is resolving.
EF Testing Engineer Mario Vega said all Pectra system contracts have been deployed on Holesky, Sepolia, and Ethereum mainnet. The addresses for these system contracts have also been added to the respective Pectra EIP documents as well for reference.
Prysm developer “Radek” shared that the Prysm client ran into two issues on Pectra Devnet 6 related to attestation aggregations under EIP 7549, move committee index outside attestation. He asked other developers on the call about how their clients handle the removal of attestation. Teku developer Enrico del Fante said that their client implements a conversion of the attestations for this. Radek said that he would look into Teku’s codebase for more information.
Radek added that the differences in strategy for handling attestations in EIP 7549 across clients could result in bugs on the Holesky testnet. Grandine developer Saulius Grigaitis proposed testing clients on another devnet before Holesky. Pk910 said that his team is working on a shadow fork of Ethereum mainnet as a next step for testing Pectra. However, he was unsure about whether the shadow fork would happen before or after the Pectra upgrade on Holesky. Stokes asked if client teams were comfortable with moving ahead with the upgrade on Holesky even without additional client testing. There were no objections.
PeerDAS Devnet 5
EF Applied Researcher Kevaundray Wedderburn said there are changes to PeerDAS that client teams want to implement for PeerDAS Devnet 5 that will affect the execution layer (EL). Additionally, client teams plan on removing EOF from EL code temporarily so that PeerDAS changes can be tested in isolation.
Geth developer Marius van der Wijden said that for EOF, developers will likely add another transaction type but to do so, consensus is needed on whether PeerDAS will also require a new transaction type and if so, what number the PeerDAS transaction type will take to avoid overlap with the EOF transaction type. He recommended raising this topic for discussion on next week’s ACD call, which is focused on EL code changes.
Stokes highlighted an update to PeerDAS design such that proof computation for blobs is outsourced from the CL to the EL. This update requires a change to EIP 7549. Stokes said the design does not necessitate a new transaction type for PeerDAS, only a new network-level wrapper for blob proofs. Prysm developer Terence Tsao recommended bringing up this topic for discussion on the next Rollcall. Stokes added that developers could also discuss this topic on next week’s ACD call.
Stokes then highlighted a new document called the “PeerDAS readiness checklist”. It is a tool to help developers track their progress on PeerDAS.
Blob Count Increase in Fusaka
Developers discussed their strategy for increasing blob capacity in Fusaka. Stokes said current research and development for PeerDAS is being worked on with a maximum blob limit of 12. In theory, developers aim to 8x the blob capacity limits set by Pectra, which means they are targeting a maximum blob limit of up to 48 or 50 blobs. Stokes asked if developers should update Fusaka specifications with the theoretical maximum blob limit of 50 and how they should go about increasing blob capacity to this limit in Fusaka.
Lighthouse developer Mark Mackey (“EthDreamer”) raised the suggestion of blob parameter-only (BPO) forks. The idea of BPO forks was first raised on ACDC #149. Mackey explained that BPO forks are upgrades to Ethereum that only change the target and max blob limits, and optionally the base fee update fraction. “If we could make these parameters much more flexible, we can avoid all the boilerplate code that comes with doing a standard hard fork,” said Mackey.
Nethermind developer Ben Adams and EF Researcher Ansgar Dietrichs recommended using BPO forks as a strategy for increasing the blob capacity only if developers are unable to immediately increase the maximum blob capacity to 50 in Fusaka. “It’s a nice idea and if it’s needed, we can do it, but we should try really hard to not need it in the first place,” echoed Stokes. Mackey noted that increasing blob capacity gradually through BPO forks could mean that developers ship PeerDAS faster since they can ship the upgrade with more conservative blob limits. Stokes said that developers should try to gather more data for now on feasible blob limit increases in Fusaka and revisit the topic of BPO forks later as needed.
Stokes noted that the PeerDAS breakout meetings will have alternating meeting times to accommodate more time zones. The PeerDAS breakout meeting this week will be at 10 AM UTC and the one after that at 2 PM UTC.
EIP 7872 and EIP 7870
Ethereum developers agreed to finalize two EIPs, both of which do not require a hard fork to implement. The first is EIP 7872, max blob flag for local builders, which will allow resource-constrained validators to configure blob limits below the network-wide limits enforced by the protocol. Prysm developer “Potuz” questioned the utility of this flag considering upcoming code changes like PeerDAS. The EIP author, Kevaundray Wedderburn, called for finalization of this EIP and said that he would reach out to EL client teams about their timeline for implementing the flag, which can be done asynchronously by the teams. There were no objections.
The second EIP developers agreed to finalize is EIP 7870, hardware and bandwidth recommendations for validators and full nodes. EF Protocol Support Team Member Nixo Rokish said the recommendations should be based on when a person can recoup the costs of operating hardware as a validator node operator. “So, based on what the current rewards are, we make sure that any validator who is buying recommended hardware can make up the costs of that hardware within six to twelve months,” said Rokish. EF Researcher Dankrad Feist was opposed to this suggestion, saying that the profitability of validators will almost certainly be driven to near zero due to the persistence of liquid staking solutions.
“The main problem is that liquid staking basically removes almost all costs of staking because you can keep your token liquid and so on. So, if you have enough liquidity, then at some point, people might be happy to even [stake] for just 0.5% returns. It’s not something that will happen immediately but in five to ten years, you can imagine that happens,” said Feist. Nixo said she was not aware developers are planning and optimizing for a state where nearly all of the ETH supply becomes staked due to the growing adoption of liquid staking.
Wedderburn, who is also the author of EIP 7870, asked if the USD amount of hardware costs would suffice for this document. Wedderburn had estimated this at roughly USD 1,000. Nixo recommended adjusting the dollar amount for dollar inflation over time. Dietrichs emphasized that the Ethereum protocol is changing “rapidly” such that frequent changes to this EIP will likely be needed. Stokes agreed and said developers should not spend time on the details of this EIP given “there’s a lot of uncertainty.” He said, “We just try to do our best right now and just iterate as we go. So, let’s not spend too much time just going through every last detail.” Stokes said developers should finalize the EIP a week from now.
As a closing reminder to all participants on the call, Stokes said the Holesky Pectra upgrade is scheduled for activation on Monday, February 24, 21:55 UTC.
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.