Localized slice

BFT consensus from scratch: replicas, quorums, and Byzantine faults

What Byzantine fault tolerance solves, why n ≥ 3f + 1 appears, and how to separate safety from liveness before reading HotStuff.

Translation status: reviewedSource language: Español

Several machines behaving as one

In State Machine Replication every correct replica applies the same operations in the same order. The BFT challenge is to achieve that even when part of the group lies, crashes, lags, or tries to sabotage the agreed order.

A crash is not Byzantine

A node with a crash fault simply goes silent. A Byzantine node can propose two blocks in the same view, vote differently to different groups, or delay messages on purpose. Tolerating arbitrary behaviour requires signatures, quorums, and verifiable voting rules.

  • Crash: the node stops responding or restarts.
  • Byzantine: the node may act arbitrarily, including equivocation.

The minimum arithmetic: n ≥ 3f + 1

Tolerating f Byzantine replicas needs at least 3f + 1 replicas and quorums of 2f + 1. Any two quorums intersect in at least f + 1 replicas, so the intersection always contains a correct replica: that is where safety lives. Liveness, by contrast, depends on partial-synchrony assumptions.

References

  1. [1]

    Castro and Liskov, Practical Byzantine Fault Tolerance (OSDI 1999)

    The first practical BFT system: state machine replication with 3f + 1 replicas.

  2. [2]

    Dwork, Lynch and Stockmeyer, Consensus in the Presence of Partial Synchrony (JACM 1988)

    Origin of the quorum bounds and the partial-synchrony model.

  3. [3]

    Yin et al., HotStuff: BFT Consensus in the Lens of Blockchain (2019)

    The protocol the series leads to: linear leader change and optimistic responsiveness.