Role of Non-Finality Testing in the Fusaka Upgrade

Non-finality testing has emerged as one of the most critical pre-fork validation processes for Ethereum’s upcoming Fusaka upgrade. By simulating unstable network conditions before mainnet deployment, developers can uncover client-specific vulnerabilities, validate recovery procedures, and ensure the network maintains resilience under stress.

This article explores the concept of non-finality, the phased testing strategy deployed in Fusaka Devnet-3, and why this process is essential for the success of the upgrade.

• Understanding Non-Finality in Ethereum
• Three Phases of Non-Finality Testing

Understanding Non-Finality in Ethereum

In Ethereum’s proof-of-stake consensus, finality occurs when blocks are confirmed beyond the point of being reverted without a massive shift in validator consensus. If validator participation drops below 66%, the network enters a non-final state, i.e., no new blocks can finalize until participation recovers.

Non-finality testing deliberately forces this condition to verify that consensus layer (CL) clients can detect, manage, and recover from it without jeopardizing network safety or liveness. This approach is vital for catching faults that might only emerge under real-world instability scenarios.

Three Phases of Non-Finality Testing

The Fusaka Devnet-3 non-finality tests, led by Nico Flaig, follow a three-phase strategy:

1. Validator Outages
   • Shut down at least one instance of each CL client, pushing participation below 66%.
   • Two variants: stopping only full nodes or only supernodes.
   • Maintain this state for one hour before restarting to measure recovery speed.
2. Network Bandwidth Throttling
   • Reduce bandwidth of ~30% of validators to 1 Mbps.
   • Simulates degraded internet conditions, causing erratic participation.
3. Network Splits and Merges
   • Partition the network into two independent chains, then merge them back.
   • Observe how clients reconcile divergent histories.
   • Tools used include Tyler’s Chaos Tool and Ansible-compatible scripts.

An example of these tests can be viewed in Slot 106243 on Dora.

Importance for the Fusaka Upgrade

The Fusaka upgrade introduces proto-danksharding and new blob transaction handling which adds complexity to both consensus and execution layers.
Non-finality testing ensures that:

• Clients recover gracefully after instability.
• Bugs specific to certain implementations are caught early.
• MEV and private mempool features are stress-tested under failure conditions.

In ACDC #162, developers such as Matthew Keil (Lodestar) stressed the need for spec freeze and full code merges before testing, while Parithosh Jayanthi confirmed that private mempool testing is already part of these non-finality runs.

Conclusion

Non-finality testing is a safety net that ensures Ethereum can recover from worst-case conditions without compromising security or stability. For the Fusaka upgrade, these tests will shape client readiness for September’s Holesky and Sepolia forks, and serve as the final safeguard before the targeted November 5, 2025 mainnet launch.

By simulating failure now, Ethereum’s core teams are ensuring a smoother, safer path forward for one of the network’s most significant scaling upgrades.

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