What does Byzantine fault tolerance tolerate?

Byzantine faults include arbitrary or malicious behavior, such as sending conflicting messages to different participants. Byzantine fault tolerance (BFT) seeks agreement among correct participants under specified fault and network assumptions.

The Tendermint Core 0.34 documentation describes its model using a bound of less than one third Byzantine voting power. That bound is not a universal promise for every blockchain.

Two goals need separate checks: safety means correct participants do not confirm conflicting results; liveness means processing can continue under the stated conditions. Also check whether the fault bound counts nodes or voting power, and what the protocol assumes about message delays.

A two-thirds quorum is not a two-thirds attack threshold

Suppose four nodes need three votes to confirm. Any two three-vote groups share at least two members. If at most one member is faulty, the intersection contains an honest member. Protocol rules restricting honest support for conflicting outcomes help protect agreement. Requiring three votes does not mean tolerating three malicious nodes.

In classic Practical Byzantine Fault Tolerance (PBFT), n = 3f + 1 replicas tolerate at most f Byzantine faults, with relevant quorums of 2f + 1. A quorum is a group meeting the protocol's voting requirement. Progress also requires eventual timely communication. This relationship is not an unconditional guarantee for every BFT protocol.

An attack comparison must identify the failure: stopped progress, a reorganization before finality, or conflicting final outcomes. Stake-weighted systems count voting power, not simply machines. The inequality 66.67% > 51% is not a security ranking across different models.

Sources and further reading