Ethereum researcher Luca Zanolini recently explained that the key to the network's continued operation during software glitches, network outages, or decreased validator participation lies in its separation of continuous block production and final confirmation into two separate processes. This allows on-chain transactions and block generation to continue even if final confirmation is briefly halted.
Block generation and confirmation are run separately.
Ethereum currently uses one mechanism to continuously generate new blocks and another mechanism to mark earlier blocks as irreversible final states. The former continues to advance along the chain supported by active validators, while the latter requires at least two-thirds of the active staking weight to participate in approval.
If this threshold is not met temporarily, final confirmation will be paused, but the network will not shut down. In May 2023, a client malfunction disrupted final confirmation twice within 24 hours. The first interruption lasted about 25 minutes, and the second nearly an hour, but blocks continued to be generated, and transactions did not stop.
The shutdown will affect lending and cross-chain operations.
Zanolini pointed out that if the underlying network were to completely shut down, it wouldn't just be ordinary transfers that would be affected. Lending protocols would be unable to perform liquidations, oracles would be unable to update prices, rollups would be unable to submit data or proofs, and cross-chain bridges would be unable to confirm new on-chain states.
He argues that a forced restart would place the recovery process in the hands of a small number of developers, node operators, and validators. These participants would need to locate the fault, coordinate the repair, and then push for network recovery. In contrast, Ethereum tends to continue producing blocks as long as an honest and online majority of validators can still communicate.
Offline staking will automatically depreciate.
At the final confirmation layer, Ethereum relies on validator signature voting to protect confirmed history. If validators have conflicting signatures on blocks or historical data, the protocol can enforce slashing based on verifiable evidence. Zanolini stated that the protocol only penalizes violations that can be proven.
In addition to forfeiture, the system also applies an automatic decay mechanism to offline staking. During the final confirmation pause, the weight represented by offline validators will gradually decrease until online validators regain sufficient weight to drive the final confirmation process to resume. This process does not require a hard fork or manual restart.
Further research aims for faster confirmation.
The article also mentions that if a single consensus client controls too high a staking ratio, network vulnerability will increase significantly. When a single client's share exceeds one-third, serious failures could threaten final confirmation; if the share continues to rise, it could also affect fork selection or even the risk of confirming erroneous histories.
The Ethereum Foundation's protocol consensus team is currently exploring ways to more clearly separate block creation from final confirmation. An update on May 11th mentioned that one of the next key focuses is shortening the final confirmation time. Currently, under normal circumstances, final confirmation typically requires about two epochs. Previous reports also indicated that Vitalik Buterin has supported a single-round final confirmation scheme called Minimmit.












