Quorum Certificate

Origin: composes, the core artifact of the HotStuff protocol family (2019), not a Solidus invention. Solidus status: testnet, real and enforced, at a four-node scale far short of the design target.

A quorum certificate, usually just "QC", is a compact, cryptographic proof that a supermajority of a validator committee agreed on a specific block. Instead of a block carrying hundreds of individual validator signatures (one per committee member who voted for it, which gets expensive to store and verify as a committee grows), a QC compresses all of those votes into roughly the size of a single signature plus a small bitmap saying who's included. Any observer, another validator, a light client, an outside auditor, can verify one QC and know, with cryptographic certainty, that at least two-thirds of the committee voted for that exact block, without needing to check each vote individually.

QCs are also what make consensus progress observable and chainable: in HotStuff, a chain of consecutive QCs, each one certifying the block that extended the previous QC's block, is literally what "finality" means (see that entry), and a validator's local highest_qc is what Fork Choice uses to decide which branch to build on.

Where it comes from

The QC construction is central to the HotStuff family, introduced in the 2019 paper "HotStuff: BFT Consensus in the Lens of Blockchain" by Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta, and Ittai Abraham. It's what gives HotStuff its defining efficiency advantage over older BFT protocols like PBFT, linear rather than quadratic message complexity, because a QC lets a leader summarize "the committee agreed" in one small object rather than relaying every individual vote to everyone. Solidus did not design this; it implements the published construction.

How a Solidus QC is built

A QuorumCertificate in Solidus's engine carries the hash of the block it certifies, the consensus round, a BLS-aggregated signature combining every voting validator's individual signature into one, and a bitvector marking exactly which committee members are included. Verification checks that the aggregate signature is genuinely valid over the block hash for the public keys the bitvector claims, and that enough validators (a two-thirds-plus quorum) actually signed. Once formed, a QC becomes a validator's new highest_qc if its round is higher than what that validator had seen before, the mechanism Fork Choice builds on directly.

The gap between design and what's running

QC formation, aggregation, and verification are real, live behavior on the public testnet, this isn't aspirational. What's aspirational is the scale: today's committee is four validators, run by the Solidus team itself, not the 21-out-of-a-100-validator-pool design the protocol specifies. A QC aggregating four signatures and a QC aggregating twenty-one prove the same kind of thing mathematically, but only one of those has actually run.

Check it yourself

The QuorumCertificate struct and its verification logic are visible in source in the public solidusnetwork/protocol repository's solidus-consensus crate. The same exhaustive TLA+ model check that underlies Fork Choice and Finality's safety claims, 963,033 states explored, zero violations, covers QC formation and chaining directly, and a stranger can re-run it against the exact spec checked in.

Related terms: HotStuff · Fork Choice · View Change · BLS Signature · Committee Election · Finality