Lessons Learned from Fusaka Devnet 4

Ethereum’s Fusaka Devnet-4 began with smooth progress but hit turbulence during later test phases, prompting developers to address critical bugs and improve network diversity before moving forward. The ACDE #218 call highlighted these challenges, set clear readiness criteria for Devnet-5, and reinforced the importance of specification alignment and minority-client inclusion to ensure a stable upgrade path.

• Devnet-4 Progress & Challenges
• New RPC Method for Configuration Transparency
• Devnet-5 Planning & Readiness Criteria

Devnet-4 Progress & Challenges

Fusaka Devnet-4 completed BPO 1–2 without major issues but ran into problems during BPO 3. The Erigon client computed blob-fees incorrectly, causing it to fork away from other EL clients.

While fixes were merged into Geth and others, Erigon’s investigation continues. On the CL side, Lighthouse and Nimbus struggled with peer discovery due to boot-node homogeneity, prompting a shift from Lighthouse+Geth to Prysm+Geth pairings for half the nodes.

No mass validator slashing is expected thanks to a mainnet-like super-node topology, but peer connectivity and client-level fixes remain priorities. A key divergence in fork-boundary parameter handling emerged where some clients used the parent block’s constants for base-fee update fraction calculations, while others used the current block’s.

This mismatch contributed to the network split. Developers agreed to standardise on current-block parameters for all future forks, updating relevant EIPs and creating static tests to ensure all clients follow the same logic.

New RPC Method for Configuration Transparency

To prevent configuration mismatches, EL clients will implement a new JSON-RPC method, eth_getChainConfig, exposing static fork-ID settings for verification before launches. Modeled after a CL counterpart, this feature will help developers quickly detect and fix inconsistencies.

The method is now a prerequisite for Devnet-5, ensuring that all participating nodes are aligned on configuration data before network rollout. Devnet-5 will launch only after Devnet-4 finalises cleanly.

Devnet-5 Planning & Readiness Criteria

Planned improvements include greater minority-client representation, i.e., Grandine, Erigon, and Lodestar collectively at 3–5% to surface bugs in less common clients, while maintaining realistic proportions for Lighthouse and Prysm.

Before launch, four conditions must be met:

• resolution of all Devnet-4 bugs.
• passing static tests for fork-boundary rules.
• implementation of the new RPC.
• proven peer discovery/sync stability in a diversified boot-node environment.

Conclusion

Fusaka Devnet-4’s challenges underscored the importance of technical consistency, configuration visibility, and inclusive client testing in Ethereum’s upgrade process. By resolving these issues before Devnet-5, developers aim to secure a smoother, more predictable path to the Fusaka mainnet launch, strengthening both protocol resilience and community confidence in Ethereum’s evolution.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

Related Articles

1. EIPs Included in Fusaka Devnet 2: What to Expect?
2. Ethereum Prepares Validator Custody Rollout with Fusaka Devnet 2
3. Ethereum Considers 45 Million Gas Limit for Fusaka Upgrade
4. History Expiry Moves Forward in Ethereum’s Fusaka Upgrade
5. A Closer Look at What’s Coming in Fusaka Devnet 2