Ethereum’s weekly All Core Developer calls are a lot to keep up with, so this “Checkpoint” series aims for high-level updates roughly every 4-5 calls, depending on what’s happening in core development. See the previous update here.
tl;dr:
The past month centered on locking in the scope of the Fusaka upgrade and final Pectra deployment details. The Pectra upgrade ships on mainnet in just about a week, after which focus will shift to Fusaka testing and deciding what goes into the Glamsterdam upgrade (in other words, the ”scope” of the upgrade). A new All Core Developer (”ACD”) call structure will split testing and scoping into separate calls to parallelize and accelerate shipping upgrades.
Pectra
Mainnet client releases are out for the Pectra upgrade and it’s scheduled to go live on May 7th.
Since the last Checkpoint, Pectra went live on ethereum’s newest long-lived testnet, Hoodi. It went well, much to the relief of client devs and testing teams who were cautious to celebrate too soon after bumpy Holešky and Sepolia upgrades.
In response to these bumpy upgrades, guardrails were established in the forms of process formalization, expected timelines between testnet upgrades and mainnet upgrade scheduling, incident response roles, and configuration standardization.
Pectra’s main features are summarized on the ethereum.org Pectra page and a watch party will follow the fork going live.
History expiry
History expiry allows clients to stop storing pre-Merge history, easing hardware and network requirements. This does not require a hard fork. Clients are set to support pre-Merge history expiry on the Sepolia network by May 1st. Mainnet support is expected shortly after Pectra on mainnet.
Long-term history will still be available through archive nodes and the Portal network and client implementations will allow a user to optionally disable pruning.
Fusaka
The headliner of the Fusaka hard fork is PeerDAS and the broad scope has been finalized.
Outside the headlining EIP,
Not all of the CFI’d EIPs will necessarily make it into the fork (two of them, 7762 & 7918, are either/or). They’ll be added into the testing pipeline and moved to SFI if their implementation progresses smoothly without introducing excessive complications. Fusaka fork testing will have a number of devnets, then fork on testnets, before being scheduled for mainnet. Shipping PeerDAS is paramount!
PeerDAS
PeerDAS lets nodes verify blobs by sampling instead of needing the full payload, making room in bandwidth and storage requirements for other upgrades. This makes way for scaling – cryptographically secure sampling techniques means that we can scale without sacrificing ethereum’s decentralized validator set. Testing is ongoing, just having concluded its sixth devnet, with the seventh set to launch this week. Testing has been a collaborative effort between client teams, Ethereum Foundation teams, L2 core devs, and network tooling researchers.
EOF
EOF is a multi-EIP upgrade to the EVM. Because of a significant divide on opinions on if (and what version of) EOF should be implemented, it was removed from the Fusaka scope during the 28 Apr EOF “final decision” discussion. It may yet be proposed for future upgrades.
Debate centered around its complexity, long-term relevance, and the potential to add its features piecemeal instead. Critics argue that it could double maintenance costs (legacy + EOF) and needs more review from app layer devs.
Supporters and implementers acknowledge its imperfections, but argue that it’s needed to pay down tech debt, increase security, unlock compiler & gas-efficiency gains, and establish a cleaner foundation for future EVM evolution.
BPO forks
The third EIP SFI’d for Fusaka is the Blob Parameter Only (BPO) forks. This would allow preconfigured blob scaling between hard forks. Blob increases would be baked into clients and happen on a pre-defined schedule while being monitored for issues. This EIP has broad support and plays a significant role in accelerating scalability.
Process improvements
Pectra has tested the limits of the current All Core Devs process – this upgrade is the biggest fork in ethereum’s history by number of EIPs, and was even larger before it was split into two: it originally contained PeerDAS and EOF!
To improve the efficiency of this process, changes are taking shape that:
- Better parallelize upgrades so that the upgrade two forks ahead is already being scoped before the current fork goes live (for example, if we had the process down right now, the Glamsterdam fork scope would be finalized while Pectra is in its last stages and Fusaka implementation is ongoing)
- Split regular calls into “all core devs” testing and “all core devs” scoping. Testing calls would cover the current fork and scoping calls would deal with CFI’ing EIPs for the next fork
- Create a new call series that discusses longer-term goals and guides research directions. Ideally, this would lead to more agreement and less debate by the time scoping and then testing is ongoing.
Core devs are ambitiously targeting to fork to Fusaka, which focuses on scaling, by the end of 2025: doable but difficult. In my opinion, if it doesn’t ship by a few weeks prior to Devconnect, it won’t ship until February 2026 because of momentum lost over the holidays, so a “by EOY 2025” delivery would be by October.
The new process of splitting the ACD calls does seem promising to keep conversations on topic, bring in new voices, and minimize the problem of revisiting old conversations so calls aren’t bogged down by debates around scoping as has been the case with EOF. It also may mitigate any tendency to conflate short-term implementation plans with long-term research directions.
Despite some doom & gloom chatter in wider crypto circles, there’s a ton of momentum in ethereum core protocol development. The process is evolving, research is strong, and implementation is speeding up!
Relevant ACD calls
28.04.25: EOF discussion (timestamped)
24.04.25: ACDE #210 (EthMag)
17.04.25: ACDC #155 (EthMag)
10.04.25: ACDE #209 (EthMag)
03.04.25: ACDC #154 (EthMag)
27.03.25: ACDE #208 (EthMag)
