Quorum Certificate (QC)

A cryptographically aggregated proof that 2f+1 of 3f+1 validators voted for the same value at the same view, forming the atomic unit of agreement in chained-BFT consensus.

Practical example

In HotStuff, a leader collects 2f+1 partial BLS signatures over (view, block_hash), aggregates them into one constant-size QC, and embeds that QC inside the next proposed block's header — so certifying block n at the same time implicitly re-certifies the entire chain of prior QCs back to genesis.

A QC is constructed by aggregating individual validator signatures (or partial signatures under a threshold signature scheme like BLS) over a specific (view, block_hash) pair. Once a leader or any node collects 2f+1 matching votes out of 3f+1 total voting power, it aggregates them into a single QC object. Critically, the QC itself becomes the payload carried in the next proposal — this is the basis of chained BFT designs where a block at height n embeds the QC for height n-1, forming a cryptographic chain that implicitly certifies the entire prefix without re-verifying every prior vote.

The engineering payoff is message complexity. Classical PBFT-style protocols require O(n^2) messages per consensus round because every node broadcasts its vote to every other node during the commit phase. QCs collapse this to O(n): nodes send votes only to the leader, the leader aggregates and rebroadcasts a single certificate. This is why HotStuff and its derivatives (used in Diem/Libra, Aptos, Celo) are the substrate of choice for large validator sets where PBFT’s quadratic blowup becomes untenable past a few dozen nodes.

Locking and Safety: A node that observes a QC for a value at view v is obligated to “lock” on that value — it cannot vote for a conflicting value at any view <= v unless it later sees a QC proving the lock was safely released. This lock is what prevents two conflicting QCs from ever forming at the same height, even across leader failures.
View-Change / Liveness: When a leader fails to produce a QC within a timeout, replicas broadcast a timeout message carrying their highest known QC. A Timeout Certificate (TC) — itself a quorum of timeout votes — advances the view. The new leader must justify its proposal using the highest QC seen across the TC, otherwise correct replicas will refuse to vote, stalling progress by design (safety over liveness).
Equivocation Handling: A malicious leader can attempt to build two conflicting QCs by partitioning votes. The 2f+1 threshold against a 3f+1 total mathematically guarantees any two quorums intersect in at least one honest node, so a rational honest replica will never sign two conflicting proposals for the same view — this is the intersection property that gives QCs their safety guarantee, not just efficiency.

Operationally, QC verification cost dominates validator CPU budgets at scale, which is why threshold/BLS aggregate signatures (constant-size regardless of quorum size) are preferred over signature lists — verifying a QC becomes a single pairing check instead of n ECDSA verifications. Systems exposing QCs externally (e.g., light clients, cross-chain bridges) treat them as the minimal trust anchor: possession of a valid QC for a header is sufficient proof of finality without replaying the full consensus history, making QC design a direct lever on light-client bandwidth and bridge security assumptions.