Ethereum All Core Developers Consensus Call #150 Writeup
On February 6, 2025, Ethereum developers met over Zoom for All Core Developers Consensus (ACDC) call #150. 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 #150, developers agreed to leave a 30-day buffer period between the last public testnet upgrade and mainnet upgrade to allow network stakeholders to have sufficient time to update their software. This means the earliest Pectra can activate on Ethereum mainnet, assuming public testnet launches happen smoothly, is early April; developers estimated April 8.
Pectra Devnet 6
Pectra Devnet 6 launched on Wednesday, February 5. So far, the devnet is running smoothly with no major issues. There is a minor issue regarding an incorrect API response in the Lighthouse client that developers said is an easy fix. EF Developer Operations Engineer Parithosh Jayanthi said MEV workflows are being tested on the devnet and so far, there are no bugs to report. Paul Harris, a blockchain protocol engineer at Consensys, commented on the meeting agenda final CL specifications are needed for cutting an updated release for Beacon API references. Stokes said that he could follow up on the status of CL specifications.
Mario Vega from the EF Testing team said that he is working on additional testing for EIP 7702, set EOA account code. Related to additional testing, Geth developer “Lightclient” highlighted a pending pull request for the EIP that requires review and feedback from other client teams.
Fork Scheduling
Then, developers discussed potential dates and times to activate Pectra on public testnets. Beiko commented on the meeting agenda three candidate timelines for upgrading Ethereum testnets and mainnet. The first requires client testnet releases by February 10 and would result in a hopeful mainnet activation by March 27. The second requires client testnet releases by February 13 and would result in a hopeful mainnet activation by April 8. Finally, the third requires client testnet releases by February 17 and would result in a hopeful mainnet activation by April 8. (The number of days between the Holesky and Sepolia upgrades for the third option is shortened such that the mainnet activation is the same for both the second and third candidate timelines.)
Client teams expressed preferences for the second option and were supportive of the suggestion by Derek Lee, Senior Product Manager at Offchain Labs, to incorporate a 30-day buffer period between the last testnet upgrade and mainnet upgrade. EF Security Researcher Fredrik Svantes wrote in the chat, “+30 days is definitely good from a security pov. I strongly support it.”
Beiko confirmed that client teams should have their releases for both the Holesky and Sepolia upgrades by February 13. He said the Ethereum Foundation could publish a blog post featuring these releases the next day on February 14 to notify the ecosystem about the scheduled testnet upgrade. He added that client teams should refrain from including any official mainnet upgrade configurations in the testnet releases until the time of the last testnet fork. Assuming all testnet forks happen smoothly, developers said they will decide on an official mainnet upgrade date and time on March 6.
PeerDAS
Jayanthi said that testing for PeerDAS has been happening mostly locally on clients and Kurtosis. These tests have been running smoothly so he said that he is trying to launch a multi-client PeerDAS devnet today. “I’m close, but it might happen a few hours after this call and I’ll post information on the PeerDAS testing channel but essentially, it’s exactly what we have on Kurtosis so it should be fine,” said Jayanthi. Once the devnet launches, developers will assess changes to PeerDAS specifications and implement fixes for another PeerDAS devnet thereafter.
Lighthouse developer Sean Anderson raised two design questions about PeerDAS. He floated the idea of moving the responsibility of building KZG proofs for blobs to the transaction sender, as opposed to the validator, i.e. the block builder. This could help alleviate computation bottlenecks in validators and scale the number of blobs that can be processed on the network. Secondly, Anderson raised the idea of blob parameter only (BPO) forks. For more context on BPO forks, refer to prior call notes on ACDC #149.
Stokes recalled that the concern about requiring transaction senders to compute blob proofs was introducing complexity into the EL. However, he said the idea should be researched further, and “if it helps scaling, I say we do it.” EF Researcher Francesco D’Amato noted that the idea was also discussed during last year’s Devcon conference and notes from that discussion have been recorded here. Generally, developers were agreeable to the idea.
On the topic of BPO forks, Stokes said that in theory, the PeerDAS upgrade should support an 8x increase in blob capacity. However, if it does not and developers require a more gradual increase to blob capacity post-PeerDAS, he said this should be when developers revisit the idea of BPO forks. For now, Stokes encouraged developers to keep working on finalizing PeerDAS specifications and implementations on devnets.
Validator Hardware and Bandwidth Requirements
EF Applied Researcher Kevaundray Wedderburn requested feedback on the impact of the max blobs flag to validator hardware and bandwidth requirements. He noted that with the flag, developers would not need to constrain the network to the bandwidth of local block builders. Nethermind developer Ahmad Bitar said he was supportive of the idea but stressed that a long-term solution for preserving the participation of “home stakers”, independent and non-professional entities and individuals, in block building was needed, which is why he has proposed the inclusion of enshrined proposer builder separation (ePBS) in Fusaka, the upgrade after Pectra. EF Researcher Ansgar Dietrichs countered Bitar’s point saying that there are “more minimally invasive change than ePBS” to help preserve local block building on Ethereum and that ePBS seemed “too complex” in his view for Fusaka.
On the topic of the max blobs flag, Prysm developer Terence Tsao said that the flag may impact how blob purchasers, primarily Layer-2 rollups (L2s), predict and calculate blob costs. Dietrichs said that he could bring up the topic of the flag on the next dedicated Rollcall meeting with L2 teams.
Pectra Retrospective
Stokes recommended that client teams start reviewing the EIPs that have been proposed for inclusion in Fusaka. He also recommended a review of the Pectra retrospectives thread on Ethereum Magicians. One of the takeaways from this thread that Stokes highlighted was the desire for developers to be “more disciplined” in fork scoping by trying to plan out the scope of forks farther in advance. EF Protocol Support Team Member “Nixo” noted in the Zoom chat that this sentiment runs contrary to how developers felt before Pectra when they decided to delay Verkle. Stokes surfaced the idea for developers to freeze the scope of Fusaka to PeerDAS and EOF and leave all other proposed EIPs for discussion in the context of the next fork after Fusaka, Glamsterdam.
Pectra Bug Bounty Attackathon
Lastly, Svantes said the EF will host a hackathon for Pectra geared towards security researchers and identifying bugs in client implementations. The hackathon bounty will award up to $2m to participants depending on the bugs found. The EF will share more details about this program once client releases for testnet upgrades have been published. Svanted said that client teams should prepare a one-pager highlighting the Pectra code changes in their client that security researchers participating in the hackathon can use to identify bugs. Svantes also encouraged teams to help spread the word about the hackathon once the program begins.
Beiko reminded Pectra EIP authors to update the status of their EIPs to “Last Call”. He also highlighted that Vega is working on a proposal to formally define new and stricter testing requirements for EIPs moving forward.
Wedderburn asked questions about the utility of the Engine API “getBlobsV1” RPC request. Prym developer “Potuz” affirmed the effectiveness of this request for improving local block builder performance and noted that the bottleneck for increasing blob scale is primarily due to the mempool. “Currently, it seems that all blobs fit in the mempool and your local node will have all of the blobs because they are being published publicly but definitely, this does not scale,” Potuz said. EF Researcher Dankrad Feist noted that blobs can be sent directly to a block builder to avoid bottlenecks from the mempool. Potuz agreed but noted that in this case, the getBlobs request loses utility.
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 [email protected]. ©Copyright Galaxy Digital Holdings LP 2025. All rights reserved.