Ethereum All Core Developers Execution Call #205 Writeup
On February 13, 2025, Ethereum protocol developers met over Zoom for All Core Developers Execution (ACDE) Call #205. 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 #205, developers confirmed the Ethereum public testnet upgrades schedule. Client teams are on track to release software that activates the Pectra upgrade on Holesky and Sepolia on February 24 and March 5, respectively. Developers then discussed Beiko’s proposal to freeze the scope of the next Ethereum upgrade, Fusaka, by the time Pectra goes live on Ethereum mainnet. Assuming the public testnet upgrades go well, developers anticipate scheduling Pectra on Ethereum mainnet around April 8. Representatives of the Geth team were opposed to Beiko’s proposal, saying the timeline for freezing the scope of Fusaka was too hasty and one of the EIPs already included in Fusaka, EOF, should be excluded from the upgrade.
To appease Geth developers, Beiko suggested a longer timeline for developers to decide what EIPs should be included in Fusaka. Instead of two weeks, Beiko suggested a month for proposing new EIPs for the Fusaka fork. Also, to address concerns from the Geth team about having to organize their thoughts in advance of calls as a team, Beiko said that thoughts about the ideal Fusaka scope can be shared asynchronously by individuals on the Geth team, as opposed to from the Geth team as a collective.
Pectra Updates
EF Developer Operations Engineer Parithosh Jayanthi shared an update on the status of Pectra Devnet 6. He affirmed that the devnet is “doing really well” and the validator participation rate is near perfect.
Beiko asked if any client teams would not be ready to publish final software releases for Ethereum public testnet upgrades over the next 24 hours. There were no client teams that spoke up. So, Beiko reaffirmed the plan to upgrade Ethereum public testnets Holesky and Sepolia on February 24 and March 5, respectively. In preparation for these upgrades, he said that he would follow up asynchronously with teams to find a volunteer for deploying Pectra system contracts on both testnets.
EF DevOps Engineer “Pk910” said developers will also activate the Pectra upgrade sooner a few hours after the call on February 13 on the Ethereum Ephemery testnet. As background, Ephemery is an ephemeral Ethereum testnet that resets to its genesis block every month. All client releases except for the Grandine client are ready for testing on Ephemery.
Beiko reminded Pectra EIP authors to move their EIPs to “last call” on GitHub.
Fusaka Planning
In the Zoom chat, Geth developer Marius van der Wijden wrote, “PeerDAS, FOCIL, EOF, upper bounds for modexp, and that’s it for Fusaka.” To which, Jayanthi responded that from his understanding FOCIL is not as ready for implementation as PeerDAS and EOF.
Before diving into the Fusaka scope discussion further, Beiko raised a pull request by EF Testing Engineer Mario Vega. Vega has proposed making EELS, Ethereum execution layer code specifications written in Python, and EEST, Ethereum execution code specifications test cases, a requirement for any EIP scheduled for inclusion in a hard fork. “This poses a lot of improvements in the testing workflow,” said Vega.
Van der Wijden pushed back on Vega’s proposal saying that it could lead to a situation where the EELS team is “basically the arbiter of opinions” that can pick and choose which EIPs get included in a fork. EF Researcher Francesco D’Amato wrote in the Zoom chat, “You don’t need the EELS team to implement something in EELS.” Van der Wijden agreed but added that not every EIP author can write a Python implementation of their code change. He also said that he would be comfortable with Vega’s proposal if the EELS implementation could be an unmerged pull request (PR) to the EELS GitHub repository. This means that EELS maintainers cannot block EIP inclusion in an upgrade as any contributor can make a PR to the EELS public repo.
Besu developer Justin Florentine agreed with Van der Wijden’s reservations and his proposal to improve it by specifying that the EELS implementation can be an unmerged PR. He also recommended additional language to Vega’s proposal clarifying exceptions for when an EIP could be included in an upgrade even without an EELS implementation and EEST cases. Geth developer Guillaume Ballet said that making EELS and EEST a requirement could “potentially be a huge drag” on the EIP process and shared concerns about the bandwidth of the EELS team to assist EIP authors. “They're really understaffed,” said Ballet.
EF Researcher Peter Miller, who said he is on the EELS team at the EF, agreed with Ballet about his team being under-resourced. However, he expressed optimism that the new process coupled with faster fork timelines could help the EELS team get on top of their work by working proactively with client teams on EIPs that will be included in an upgrade. Vega agreed that the new EIP process should help developers ship EIPs faster and asked interested people on the call who want to help the EEST or EELS teams to reach out to himself or Miller or his other team members.
Beiko recommended that Vega start by incorporating the feedback from the call discussion into his PR. Developers should review the new PR draft and aim to finalize a version of it next week.
Pectra Retrospective
The Pectra Retrospective forum has been up for public comment for over 20 days. Beiko said the most common suggestion in the forum is to upgrade Ethereum faster. To do this, Beiko recommended trying to finalize the scope of an upgrade once the previous upgrade goes live on Ethereum mainnet. Since Pectra is close to being ready for mainnet activation, Beiko proposed freezing the scope of the next upgrade Fusaka to EOF and PeerDAS. This would enable developers to start work on Fusaka and in parallel, discuss the scope of the next hard fork, Glamsterdam.
A developer by the screen name “Dustin” noted that there are fixed costs to every Ethereum upgrade that do not derive from implementation or testing work. For example, the Ethereum ecosystem needs at least 30 days from the last public testnet upgrade to mainnet deployment. Public testnet upgrades alone take two to three weeks to complete. These fixed costs are not an issue when trying to cut the upgrade cadence from one year to six months. However, they do become problems when trying to upgrade Ethereum even faster than every six months.
EF Researcher Ansgar Dietrichs suggested that developers should consider shipping the Glamsterdam fork as soon as PeerDAS is ready, instead of coupling the activation of PeerDAS with EOF. Independent Ethereum developer Danno Ferrin asserted that he is confident that EOF will be ready to ship when PeerDAS is ready to ship. Nethermind developer Ben Adams recommended including two minor EIPs in Fusaka that will ensure that validators can safely increase the block gas limit. Beiko expressed concerns that including these EIPs could open the door to several more EIP inclusion in the upgrade. Adams emphasized that EIPs like EIP 7823, which set upper bounds for MODEXP, are bug fixes, not feature adds.
Geth developer Lightclient said that developers should not freeze the Fusaka fork as the current fork scope does not reflect what Ethereum’s important priorities are today. “I find it difficult to say, we’re just going to freeze the fork right now when that means that we’re not going to have any of these things that feel important today for two years. We can say we’re going to try and do these six-month forks, but the reality is it’s not going to happen, almost certainly. Even if we do eight-month forks, that’s 1.5 years minimum before we start seeing some of the stuff that feels important today, so it seems too early to totally freeze these things,” said Lightclient, adding, “I think that EOF on the EL does not really make much sense given where we are today. We’re also in this moment where zkEVMs are advancing rapidly and we don’t know what the end state is going to be. So, I don’t see a reason to make a massive change to the VM when we don’t know how zkEVMs are going to interplay with this in three years. I think we just need to let the dust settle a little bit. We need to try and figure out what EIPs fit best with the goals we want to have the next 12 months and then go from there.”
Beiko emphasized that to the extent developers spend extended time debating what goes into a fork, all code changes will be delayed from implementation. Lightclient pushed back saying developers shouldn’t prioritize upgrading Ethereum on a set cadence, they should prioritize shipping code changes that “matter”. Beiko reminded developers that there is still a month and a half before Pectra is activated on mainnet and asked what blockers there are to make that time sufficient to finalize the scope of Fusaka. Reth developer Roman Krasiuk said developers should try to finalize the scope of Fusaka as soon as possible. “We would never get to a faster pace if we don’t commit ahead of time to the scope,” said Krasiuk, adding, “When Pectra lands, we should not just keeping debating EIPs that are not ready.”
Prym developer “Potuz” recommended that EIP authors don’t wait for client teams or fork-scoping discussions to start implementing code. He emphasized the importance of parallelizing work and creating devnets for EIPs that developers think are important and shipping these EIPs as they become ready for mainnet “even if some clients are not ready.” Jayanthi pushed back on this comment saying that devnets have already been created for both PeerDAS and EOF and all client teams are participating in both devnets. Additional devnets can be created for other EIPs but “scoping is the issue.” Jayanthi emphasized there are bandwidth constraints on developers to create devnets for all EIPs and a scoping discussion that confirms which EIPs are ready for devnet testing is crucial to the fork testing process.
Nethermind developer Lukasz Rozmej said that in addition to a timeline for finalizing the scope of Fusaka, developers should plan out a timeline for finalizing the scope of Glamsterdam. Beiko proposed two weeks from this week’s call for proposing EIPs in Fusaka, two weeks thereafter for client teams to review EIPs and share asynchronously their thoughts on the ideal fork scope, and two weeks after that to finalize the fork scope. Lightclient said the timeline was too aggressive as developers are focused on shipping Pectra. Beiko conceded this and recommended then four weeks from this week’s call for proposing EIPs in Fusaka. This would push out the timeline for finalizing Fusaka scope to mid-April, ideally a few weeks after Pectra goes live on Ethereum mainnet.
Beiko’s proposed timeline for finalizing Fusaka scope is:
- March 13: Deadline for proposing EIPs in Fusaka.
- March 27: Client teams share their preferences for which EIPs should be considered for inclusion in Fusaka.
- April 10: Deadline for finalizing the scope of Fusaka.
Dietrich added that the caveat to Beiko’s timeline should be that PeerDAS code changes ship to Ethereum mainnet as soon as they are ready. There were no objections.
EOF Updates
Ferrin gave an update on the latest progress for EOF. Erigon developer Andrew Ashikhmin again questioned why EOF should be coupled with PeerDAS for implementation and recommended shipping PeerDAS earlier. Ferrin responded that there are fixed costs with upgrades on Ethereum and EOF will not delay PeerDAS from implementation. Beiko said that if EOF looks to potentially delay PeerDAS by more than a month, developers can revisit the discussion on decoupling the two code changes.
Ballet asked several questions all suggesting that EOF is not an upgrade that is ready or necessary for implementation in Fusaka. Dietrichs and Florentine pushed back on these sentiments in the Zoom chat. “The idea is EOF is a platform so that future EVM improvements are easier to ship. … It’s not that EOF is incomplete without them,” wrote Dietrichs. “I don’t understand [Guillaume]. That’s like asking ‘When will DAS be done?’” wrote Florentine.
Lightclient wrote several comments in the Zoom chat indicating that the Geth team’s view was to remove EOF from Fusaka. “We disagree that EOF should be shipped on mainnet at all,” and “We just said our PoV is for EOF to not be in the fork,” Lightclient wrote. Van der Wijden spoke up saying that the Geth team rarely communicates their thoughts as a collective. “We work mostly as individuals, and I don’t think we should force team members to ‘fall into the party line.’ In my opinion, we are here as individuals and should have our voices heard as individuals.” Van der Wijden later wrote that he is personally not opposed to EOF in Fusaka.
Krasiuk pointed out that developers have already debated the inclusion of EOF in Fusaka “multiple times” and that if the Geth team or individuals on the team want to reopen the discussion because they have new insights to share then the team or the individuals should present these cases in writing for review by other client teams over the next few weeks as Beiko suggested in his timeline for finalizing the scope of Fusaka. Florentine noted that the Geth team’s resistance to writing viewpoints out as a team and asynchronously from the ACD calls makes the governance process “harder on the rest of us.”
Validator Node Requirements
EF Applied Researcher Kevaundray Wedderburn shared updates on his efforts to formalize the requirements for operating an Ethereum validator. Wedderburn said all EL client teams are supportive of the idea of creating a flag that will enable local block builders to configure the maximum number of blobs they will include in a block. The idea was also presented to rollup teams at the most recent Rollcall meeting. Dietrichs said rollup teams view the flag as “mildly convenient” but reasonable for the benefit of helping local block builders stay performant on Ethereum. In response to a question by EF Protocol Support Team Member “Nixo”, Wedderburn clarified that this flag would only be used by validators that are not opting into using third-party block builders through MEV-Boost relays. Due to limited time on the call, Wedderburn said that he would raise the topic of local block-building requirements for discussion on the next 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.