View Change

Origin: composes, a mechanism formalized by PBFT (1999) and adapted by HotStuff (2019); not a Solidus invention. Solidus status: testnet, live and tested against internal timeouts; never triggered by a genuinely adversarial leader.

A view change is what happens when a BFT network's current leader isn't doing its job, offline, slow, or deliberately withholding a proposal, and the rest of the committee needs to move on without them. Every round of BFT consensus has a designated leader (see Leader Election) responsible for proposing the next block. If that leader stays silent past a set timeout, the other validators can't just wait forever: a single unresponsive or malicious leader would otherwise be able to freeze the entire network. A view change is the escalation path: validators detect the timeout, signal it to each other, and once enough of them agree the leader has failed, the network advances to a new round with a new leader, without ever compromising the safety guarantees consensus already has.

Where it comes from

The concept was formalized for practical systems by Miguel Castro and Barbara Liskov's 1999 Practical BFT (PBFT) paper, where a "view" names a specific leader assignment and a "view change" is the protocol for replacing it. HotStuff, the protocol family Solidus's engine implements, reframes the same underlying problem around a simpler abstraction called a "pacemaker," introduced in the 2019 HotStuff paper by Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta, and Ittai Abraham. Solidus did not design either version.

How it works in Solidus's engine

Every validator runs a local Pacemaker that tracks the current round and a countdown deadline, starting at two seconds. If that deadline passes without a valid proposal or quorum certificate for the round, the validator broadcasts a TimeoutVote. Once enough timeout votes accumulate for the same round to meet quorum, they aggregate into a TimeoutCertificate (TC), carrying the highest quorum certificate any timing-out validator had seen, and the round advances. Crucially, each successive timeout doubles the wait (exponential backoff, capped at sixteen seconds), so a genuinely slow network gets more patience with each failed attempt, rather than the committee hammering itself with ever-faster timeout storms. A successful quorum certificate, by contrast, resets the timeout straight back to two seconds: the fast path stays fast.

Getting this right in the small details matters more than it sounds: an early version of the engine had a real liveness bug where transitioning from an idle network (no pending transactions, so no reason to keep producing blocks) back to an active one could leave a stale, already-expired deadline in place, triggering a spurious timeout-vote burst that raced a legitimate fresh proposal. That's a genuine example of how view-change timing can misfire in practice, described further under Safety vs Liveness, and it was found and fixed, not left as a live gap.

Check it yourself

The Pacemaker struct, its exponential-backoff logic, and the timeout-vote-to-certificate path are all visible in source in the public solidusnetwork/protocol repository's solidus-consensus crate, alongside tests that confirm a certificate genuinely requires quorum before it forms.

Related terms: Safety vs Liveness · Quorum Certificate · Fork Choice · HotStuff · BFT · Leader Election