Ethereum researcher Luca Zanolini says the network’s decade-long record of continuous block production is tied to one core design choice: block production and final settlement are handled separately. The chain can keep extending based on the validators that are online and communicating, while finality for older blocks still requires approval from at least two-thirds of the total active stake. If that threshold disappears, finality can stop for a period without shutting down block production.
Finality can pause while the chain keeps moving
The distinction became visible in May 2023, when client faults interrupted finality twice within 24 hours. The first disruption lasted about 25 minutes, and the second lasted close to one hour. Even so, blocks kept arriving, transactions remained available, and the network recovered without a coordinated restart.
Zanolini argues that a full base-layer halt would freeze far more than token transfers. Lending protocols would be unable to process liquidations. Oracles would stop updating prices. Rollups could not post data or proofs, and bridges could not confirm new state. Risk would keep accumulating while users had no on-chain way to respond. A forced restart would also concentrate recovery in a small set of developers, operators, and validators who would need to diagnose the fault, agree on a fix, and coordinate the network’s return.
Slashing and inactivity leaks are part of the recovery path
Ethereum’s finality layer protects settled history through signed validator votes. If validators sign conflicting blocks or attestations, the protocol can verify that evidence and apply slashing. As Zanolini put it, the protocol punishes only what it can prove.
When finality stays unavailable for more than four epochs, Ethereum can also trigger an inactivity leak. Offline validators gradually lose effective stake, and the penalty grows during a prolonged disruption. That shifts the voting balance until the validators still participating once again control enough stake to finalize the chain automatically. No hard fork is required. No manual reboot is needed. Block production continues while inactive stake is reduced.
Client concentration raises the risk of shared failures
Zanolini also pointed to a clear limit in this model: too much stake on one consensus client makes the system more fragile. If a single client controls more than one-third of stake, a major fault can threaten finality. Above one-half, fork choice can be distorted. Above two-thirds, a faulty client could help finalize an invalid history before operators have time to react.
The report referenced a separate episode after the Fusaka upgrade in December 2025, when a Prysm fault pushed validator participation down to about 75%. The network missed 41 epochs, and validators lost roughly 382 ETH in rewards. Other clients kept operating, and Ethereum avoided losing finality.
Research is now focused on faster settlement
The Ethereum Foundation’s Protocol Consensus team is studying how to draw a cleaner boundary between block production and finality. A research proposal published in March 2026 suggested using a sampled committee for faster block production, while a separate process would finalize the chain behind it. That setup would allow each system to use different timing and security parameters.
A May 11 update said Ethereum’s next phase of consensus work will focus on reducing finality time, which currently takes about two epochs under normal conditions. Separate reporting also said Vitalik Buterin has backed Minimmit, a proposed one-round finality design. The proposal could settle blocks faster, though its current form accepts lower formal fault tolerance than Casper FFG.
Zanolini’s explanation frames Ethereum’s resilience as a set of linked trade-offs rather than a single feature. Continuous block production preserves access to the chain. Finality protects settled history. Slashing prices provable misconduct. Inactivity penalties help restore finality automatically, and client diversity limits how far one software bug can spread across the validator set.