Ethereum Prepares for Fusaka Devnet 0 Launch on May 26

The Ethereum community is preparing for the launch of Fusaka Devnet-0, scheduled for May 26. This testnet is part of a broader initiative to stabilize and refine Ethereum's modular architecture, with a focus on key Ethereum Improvement Proposals (EIPs) such as EIP-7825 and EIP-7934. The 212th Ethereum All Core Developers Meeting (ACDE) highlighted the ongoing efforts to finalize the scope for Devnet 1 and align client teams on critical EIP implementations.

Devnet 7, currently active, is being used for basic stress testing of Ethereum’s data availability layer. However, many clients still lack functioning backfill capabilities, and validator custody is yet to be implemented across most of them. These limitations introduce risks of unstable or incomplete testing, prompting teams to ensure these capabilities are in place by Devnet 1 or, at the latest, Devnet 2.

The upcoming Fusaka Devnet 0 launch is a critical phase for evaluating the implementation of Fusaka EIPs. Compatibility testing across clients is in progress, with several clients already confirmed to be functional on both the consensus and execution layers. PeerDAS testing has also been initiated, using a new network partitioning tool from the Ethereum Foundation’s security team. This tool simulates isolated node environments to identify weaknesses in how clients handle partitioned networks. Early tests have already exposed failures, indicating that the testing mechanism is functioning as intended. Developers are now working to investigate and resolve the underlying causes of these failures to ensure PeerDAS resilience under adverse conditions.

The discussion around Fusaka Devnet 1 centered on finalizing which EIPs should be included in its scope. The intent is to avoid overwhelming client teams by spreading changes too broadly across multiple Devnets. By clearly assigning EIPs to specific Devnets, the community aims to streamline coordination, ensure consistency, and prevent fragmentation. Client teams such as Nethermind, Erigon, and Besu had already shared their input ahead of the call, identifying two priority EIPs for inclusion in Devnet 1: EIP-7825 (Transaction Gas Limit Cap) and EIP-7934 (RLP Block Size Limit).

EIP-7825 proposes introducing a cap on the gas allowed per transaction, aimed at preventing excessively large transactions that can hinder parallel execution and degrade performance. Proponents argued that limiting transaction size helps improve throughput, especially in future architectures that prioritize parallel processing and rollup-friendly batching. However, the proposal also sparked debate, with some contributors feeling that the EIP lacked clarity on the real target issue. Ultimately, the group aligned on including EIP-7825 in Devnet 1, agreeing that it provides a performance safeguard for the evolving Ethereum ecosystem.

EIP-7934 proposes placing an explicit cap on the size of RLP-encoded execution layer (EL) blocks, aligning them more closely with consensus layer (CL) constraints. Supporters of the EIP argued that making this constraint explicit improves predictability, avoids extreme block sizes, and reduces edge-case risks. Despite minor disagreements on cap size and enforcement methods, consensus was reached to include EIP-7934 in Devnet 1, reinforcing the need for tighter operational boundaries on block size.

The call also reviewed additional EIPs for Devnet 2, including EIP-7907 (Contract Code Size Limit Increase), EIP-7918 (Blob Base Fee Bounding), EIP-7212 (R1 Curve Precompile), and EIP-5920 (Pay Op Code). Each of these EIPs was discussed in detail, with varying levels of support and concern. For example, EIP-7907 received broad community interest but was deferred until further data is available. EIP-7918 received support from multiple client teams but was acknowledged as strategically nuanced. EIP-7212 was flagged as complex and potentially flawed, requiring a rewrite or clarification. EIP-5920 proved the most divisive, with no consensus reached on its inclusion.

A significant portion of the call focused on Ethereum’s testnet infrastructure, specifically how to manage risk and stability for developers deploying apps and protocols. Alon Muroch proposed a long-term vision for the Holesky (Hoodi) testnet to serve as a stable, mainnet-like staging environment that forks only when Ethereum mainnet does. The goal is to reduce developer disruptions caused by frequent or unexpected testnet forks, which can invalidate smart contracts or break integration pipelines. While some community members supported this approach, others raised concerns about maintaining “forever-running” testnets. The idea of community-maintained infrastructure was proposed, involving projects that already operate nodes for staking or integration testing. Developers agreed that having fewer, more predictable testnets with longer lifespans would improve the developer experience, especially if paired with clear guidance on forking sequences and risk levels.