{"id":17516,"date":"2026-02-22T00:30:36","date_gmt":"2026-02-22T00:30:36","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/02\/22\/checkpoint-2-apr-2025-ethereum-foundation-blog\/"},"modified":"2026-02-22T00:30:36","modified_gmt":"2026-02-22T00:30:36","slug":"checkpoint-2-apr-2025-ethereum-foundation-blog","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/02\/22\/checkpoint-2-apr-2025-ethereum-foundation-blog\/","title":{"rendered":"Checkpoint #2: Apr 2025 | Ethereum Foundation Blog"},"content":{"rendered":"


\n<\/p>\n

\n

Ethereum\u2019s weekly All Core Developer calls are a lot to keep up with, so this “Checkpoint<\/a>” series aims for high-level updates roughly every 4-5 calls, depending on what\u2019s happening in core development. See the previous update here<\/a>.<\/em><\/p>\n

\"\"<\/p>\n

<\/g><\/svg><\/a>tl;dr:<\/h2>\n

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<\/a> testing and deciding what goes into the Glamsterdam<\/a> upgrade (in other words, the \u201dscope\u201d of the upgrade). A new All Core Developer (\u201dACD\u201d) call structure will split testing and scoping into separate calls to parallelize and accelerate shipping upgrades.<\/p>\n

<\/g><\/svg><\/a>Pectra<\/h2>\n

Mainnet client releases are out for the Pectra upgrade and it\u2019s scheduled to go live<\/a> on May 7th<\/a>.<\/p>\n

Since the last Checkpoint, Pectra<\/a> went live on ethereum\u2019s newest long-lived testnet, Hoodi<\/a>. It went well, much to the relief of client devs and testing teams who were cautious<\/a> to celebrate too soon after bumpy<\/a> Hole\u0161ky and Sepolia upgrades.<\/p>\n

In response to these bumpy upgrades, guardrails were established in the forms of process formalization<\/a>, expected timelines between<\/a> testnet upgrades and mainnet upgrade scheduling, incident response roles<\/a>, and configuration standardization<\/a>.<\/p>\n

Pectra\u2019s main features are summarized on the ethereum.org Pectra page<\/a> and a watch party<\/a> will follow the fork going live.<\/p>\n

<\/g><\/svg><\/a>History expiry<\/h2>\n

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.<\/p>\n

Long-term history will still be available through archive nodes<\/a> and the Portal network<\/a> and client implementations will allow a user to optionally disable pruning.<\/p>\n

<\/g><\/svg><\/a>Fusaka<\/h2>\n

The headliner of the Fusaka hard fork<\/a> is PeerDAS<\/a> and the broad scope has been finalized.<\/p>\n

Outside the headlining EIP,<\/p>\n

Not all of the CFI\u2019d EIPs will necessarily make it into the fork (two of them, 7762<\/a> & 7918<\/a>, are either\/or). They\u2019ll 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!<\/p>\n

<\/g><\/svg><\/a>PeerDAS<\/h3>\n

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\u2019s decentralized validator set. Testing is ongoing, just having concluded its sixth devnet<\/a>, with the seventh set to launch this week. Testing has been a collaborative effort<\/a> between client teams, Ethereum Foundation teams, L2 core devs, and network tooling researchers.<\/p>\n

<\/g><\/svg><\/a>EOF<\/h3>\n

EOF<\/a> is a multi-EIP upgrade to the EVM. Because of a significant divide on opinions on if (and what version<\/a> of) EOF should be implemented, it was removed from the Fusaka scope during the 28 Apr EOF \u201cfinal decision\u201d discussion<\/a>. It may yet be proposed for future upgrades.<\/p>\n

Debate centered around its complexity<\/a>, long-term<\/a> 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.<\/p>\n

Supporters<\/a> and implementers acknowledge its imperfections, but argue that it\u2019s needed to pay down tech debt, increase security, unlock compiler & gas-efficiency gains, and establish a cleaner<\/a> foundation for future EVM evolution.<\/p>\n

<\/g><\/svg><\/a>BPO forks<\/h3>\n

The third EIP SFI\u2019d for Fusaka is the Blob Parameter Only<\/a> (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.<\/p>\n

<\/g><\/svg><\/a>Process improvements<\/h2>\n

Pectra has tested the limits of the current All Core Devs process – this upgrade is the biggest fork in ethereum\u2019s history by number of EIPs, and was even larger before it was split into two: it originally contained PeerDAS and EOF!<\/p>\n

\"\"<\/p>\n

To improve the efficiency of this process, changes are taking shape that:<\/p>\n