Skip to content

View-Change Protocol

Leader-handoff (view-change) protocol — instantiates Assumption-Bounded Distributed Agreement

Hands leadership from a suspected-faulty leader to a fresh one without ever losing or contradicting a decision the old leader may already have committed — trading a brief, visible pause for an unbroken safety guarantee.

When the current leader (the primary, or view) is suspected faulty, progress has to move to a new one — but doing that carelessly can erase or fork a decision the old leader had already committed. View-Change Protocol is the safety-preserving handoff. Before a new view is allowed to propose anything, it gathers from a quorum the evidence of every value that might already have been decided, and forces the incoming leader to re-adopt that safe set first — so nothing past the commitment boundary is dropped or contradicted. Its defining move is that the change is gated on a safety proof, not a mere vote: the system may go visibly undecided (a pause) until enough view-change evidence is assembled, but it will never let a new leader build on a state that could contradict a committed decision. Safety across the discontinuity is unconditional; liveness is deliberately suspended and then restored once the new view stabilizes. Where leader election picks who leads next, view-change guarantees what survives the switch.

Example

A Byzantine-fault-tolerant ordering service sequences interbank settlement instructions across replicas run by different institutions, tolerating f faulty replicas out of n ≥ 3f + 1. The current primary begins misbehaving — equivocating about the order, or simply going silent mid-batch. Replicas that time out on it broadcast VIEW-CHANGE messages, each carrying the highest prepared certificates it holds — cryptographic proof of which settlement orders may already have been committed. The designated next primary for view v+1 waits for a quorum (2f + 1) of these messages, computes from them the set of orders that could have committed, and re-proposes exactly those in the new view before accepting any new instruction. Settlement finalization pauses for a moment — no new orders complete while the change is in flight — but every order that might already have been committed under the old primary is carried forward intact. The service never double-orders a settlement and never loses a committed one.[1]

How it works

  • Stop following on suspicion. When a quorum suspects the leader, replicas abandon the current view rather than keep accepting its proposals — refusing to extend a possibly-faulty history.
  • Carry the evidence, not just the vote. Each replica contributes its highest prepared/committed certificates, so the handoff transfers what was decided, not merely who is next.
  • Re-adopt before proposing. The new leader must gather a quorum of that evidence and re-propose every value that could have committed — a whole-set generalization of Paxos's "adopt the highest accepted value."
  • Prefer a safe pause to unsafe progress. Until the safe set is assembled and re-adopted, the system stays undecided; it never trades the safety invariant for a faster restart.

Tuning parameters

  • View-change quorum / evidence threshold — how much prepared-state evidence the new leader must collect (2f + 1 under a Byzantine budget). A higher bar is safer but slower to assemble, lengthening the pause.
  • Trigger sensitivity — how readily suspicion escalates to a full view change. Twitchy triggers cause thrashing between views (and can be provoked by an adversary to starve progress); sluggish ones tolerate a bad leader too long.
  • New-view validation strictness — whether followers independently re-verify the incoming leader's carried-forward set. Re-verification defends against a Byzantine new leader; trusting it is faster but weaker.
  • View-timeout growth — how the timeout for each successive view lengthens, so that eventually some view outlasts a spell of asynchrony and succeeds — the protocol's route to liveness under partial synchrony.

When it helps, and when it misleads

Its strength is that it is what makes leader-based agreement fault-tolerant at all: without a safe handoff, a single bad leader freezes the system or forks it. View-change preserves every committed decision across the very moment — a leadership discontinuity — when decisions are most easily lost.

Its subtleties are sharp. A view-change is a liveness pause, not a safety risk — the system is correctly undecided while the change completes — and the temptation under pressure is to "recover faster" by cutting the pause short. An adversary or a flapping detector can force repeated view changes that starve progress, a pure liveness attack. And if the carried-forward evidence is computed wrong, a committed decision can be silently lost — the single most dangerous bug in the family. The classic misuse is letting the new leader accept new work before it has gathered and re-adopted the safe set, which can drop or fork a committed value. The discipline is absolute: no new view proposes anything until it has proven it preserved everything past the commitment boundary, and view timeouts grow so asynchrony cannot block every view forever.

How it implements the components

  • safety_liveness_contract — it enforces the archetype's core deal at its riskiest instant: safety is preserved unconditionally across the leadership change, while liveness is deliberately suspended (a visible pause) until a safe new view can be proven.
  • commitment_boundary — it defends the commitment boundary across the handoff: any value that might have crossed it under the old leader is carried into the new view intact, so the boundary is never rolled back or forked (it protects the boundary rather than creating it).

It does not choose which candidate becomes the new leader or advance the term counter (round_epoch_and_leadership_state, decision_authority_boundary → Term/Epoch Leader Election), decide whom to suspect (failure_detector → Heartbeat and Suspicion Detector), or replicate the steady-state log (state_consistency_guard → Raft-Style Replicated-Log Protocol).

Notes

The safety-versus-liveness asymmetry is the whole point: a view-change pause is correct behaviour, not a defect, and teams that "fix" the pause with an unsafe shortcut forfeit the guarantee the protocol exists to give. The clean division of labour with its closest sibling: Term/Epoch Leader Election decides who leads next; view-change guarantees the what — the committed decisions — survives the change.

References

[1] The view-change sub-protocol of PBFT (Castro and Liskov) replaces a suspected-faulty primary while preserving safety by having replicas transfer their highest prepared certificates, from which the new primary reconstructs a safe starting state before proposing. Later leader-based BFT protocols such as Tendermint and HotStuff use the same carry-forward principle. ↩