Byzantine Fault Tolerance

Consensus Updated May 2026

What is Byzantine Fault Tolerance?

Byzantine Fault Tolerance (BFT) is a property of distributed computing systems that allows them to continue functioning correctly even when some nodes fail or behave maliciously. The concept originates from the Byzantine Generals Problem, described by Leslie Lamport, Robert Shostak, and Marshall Pease in their landmark 1982 paper “The Byzantine Generals Problem.” In this thought experiment, a group of generals commanding different divisions of the Byzantine army must agree on a common battle plan—either attack or retreat—by communicating only via messengers. Some generals may be traitors who deliberately send contradictory messages to different divisions. The challenge is to find a protocol that ensures loyal generals reach consensus regardless of the traitors’ actions.

In the blockchain context, “Byzantine” behavior means any deviation from the protocol specification—not just crashing or going offline, but actively sending conflicting messages, proposing invalid blocks, or attempting to double-spend. This is a stronger failure model than “crash fault tolerance” (where nodes simply stop responding), and it is the realistic failure model for public blockchains where anonymous participants have financial incentives to cheat.

The mathematical result is elegant and has direct implications for blockchain design: a system can tolerate at most f Byzantine (faulty) nodes if it has 3f + 1 total nodes. This means you need at least a two-thirds honest supermajority to reach consensus. In concrete terms, if a blockchain has 100 validators, it can safely tolerate up to 33 malicious ones. If more than 33 are malicious, they can potentially prevent honest nodes from reaching consensus or cause safety violations (double spends).

How It Works

The f < n/3 Bound

The reason for the 3f + 1 requirement can be understood intuitively. Consider a scenario where a proposer sends different values to different validators (a classic Byzantine attack). If there are 3f + 1 validators and f are malicious:

Up to 2f + 1 honest validators exist
Each honest validator receives at most f + 1 messages agreeing with its own value (itself + up to f other honest validators)
But it also receives potentially f conflicting messages from Byzantine validators
With only 2f + 1 total agreeing messages possible from the honest set, the protocol needs careful message exchange to distinguish honest agreement from Byzantine confusion

This bound is information-theoretic—it does not depend on the specific algorithm, computing power, or economic incentives. It is a fundamental limit of what is achievable with deterministic consensus in asynchronous networks.

Practical BFT Implementations

PBFT (Practical Byzantine Fault Tolerance), introduced by Castro and Liskov in 1999, was the first practical BFT algorithm. It operates in three phases: pre-prepare, prepare, and commit. Each phase requires all-to-all message exchange, resulting in O(n²) communication complexity. PBFT was used by Hyperledger Fabric and early versions of Zilliqa but is too slow for public blockchains with thousands of validators due to its communication overhead.

Tendermint BFT (now CometBFT), created by Jae Kwon in 2014, is the most widely deployed BFT consensus protocol in public blockchains. It is used by the Cosmos ecosystem (Cosmos Hub, Osmosis, Celestia, Injective, and 200+ other chains). Tendermint uses a rotating proposer model with instant finality:

Propose: A designated proposer broadcasts a block
Pre-vote: Validators vote on whether they received the proposal
Pre-commit: Validators commit to the block if they saw >2/3 pre-votes
Commit: If >2/3 pre-commits are observed, the block is finalized

This process typically completes in ~1–3 seconds on Cosmos chains. The communication complexity is O(n) per round (not O(n²)), making it far more efficient than PBFT.

HotStuff BFT, developed at VMware Research and used by Meta’s Diem/Libra project (now adapted by Aptos and Sui), improves on PBFT by using a linear communication pattern with a three-phase protocol (prepare, pre-commit, commit) that achieves O(n) complexity. Its key innovation is a “leader-driven” approach where the leader collects votes in a pipelined fashion, reducing the number of message rounds.

Ethereum’s approach is notably different. Ethereum does not use classical BFT—it uses Casper FFG (Friendly Finality Gadget) combined with LMD GHOST (Latest Message Driven Greedy Heaviest Observed Subtree) for consensus. Casper provides finality through epoch-based checkpoint votes, while LMD GHOST selects the head of the chain. The system is BFT under the assumption that less than 1/3 of total stake is controlled by adversarial validators. If more than 1/3 are adversarial, the network cannot finalize but also cannot be safety-compromised (no conflicting checkpoints can be finalized). This property—liveness may fail but safety is maintained—is called “safe under asynchrony.”

BFT Thresholds in Practice

Protocol	BFT Model	Honest Majority Required	Finality	Communication Complexity
Tendermint (CometBFT)	Classical BFT	2/3	Instant (~1-3 sec)	O(n)
Ethereum (Casper FFG)	Partial BFT	2/3 of stake	~12.8 min (epoch)	O(n)
PBFT	Classical BFT	2/3	Deterministic	O(n²)
HotStuff	Classical BFT	2/3	3 rounds	O(n)
Avalanche (Snowball)	Probabilistic BFT	~2/3	Sub-second	O(k log n), sampling

Real-World Examples

Cosmos Hub uses Tendermint BFT with ~180 active validators. In February 2023, the Cosmos community experienced a real-world BFT incident when a proposal to reduce the validator set from 180 to 100 was debated. The incident highlighted that even with BFT guarantees, social governance decisions can affect the security parameter (more validators = higher decentralization but slower consensus).

Ethereum’s Merge (September 2022) transitioned from PoW to PoS, making BFT security assumptions explicit. The Beacon Chain currently has ~900,000 validators. The 1/3 attack threshold means an attacker would need to control over ~300,000 validators (over 10 million ETH at ~32 ETH per validator). As of early 2025, the total staked ETH exceeds 30 million, making this economically infeasible.

Aptos uses the AptosBFT consensus protocol (derived from HotStuff/DiemBFT) with approximately 100 validators. Its pipelined BFT design allows it to achieve 160,000+ TPS in controlled benchmarks, though real-world throughput is closer to several thousand TPS.

Key Risks / Considerations

Censorship: BFT guarantees liveness and safety but not censorship resistance. A 1/3 coalition could censor transactions by refusing to include them in proposed blocks, even though they cannot finalize conflicting blocks.
Nothing-at-stake: In naive PoS implementations, validators might vote on multiple chain forks simultaneously since doing so costs nothing. Ethereum addresses this through slashing conditions that penalize equivocation (voting for two conflicting checkpoints).
Long-range attacks: An adversary who once controlled >1/3 of stake could attempt to create an alternate history from a past state. Solutions include weak subjectivity (trusted checkpoints) and finality gadgets.
Communication overhead: Classical BFT with thousands of validators is impractical due to O(n²) message complexity. This is why many BFT systems limit their validator sets (Cosmos: ~180, Aptos: ~100, BNB Chain: 21).

Frequently Asked Questions

Q: Is Bitcoin Byzantine Fault Tolerant? A: Bitcoin is NOT BFT in the classical sense. It uses Nakamoto Consensus (longest chain rule), which provides probabilistic rather than deterministic finality. Bitcoin can tolerate up to 50% hashpower being adversarial for safety (no double spends in the confirmed chain) but has no deterministic finality—there’s always a non-zero probability of a chain reorganization, regardless of how many confirmations you wait.

Q: What happens if exactly 1/3 of validators are malicious? A: The safety threshold is strict: the system can tolerate fewer than 1/3 Byzantine nodes. If exactly 1/3 are malicious, safety is not guaranteed—the malicious nodes can potentially prevent consensus from being reached (liveness failure) or, in the worst case, cause a safety violation depending on the protocol’s exact behavior at the boundary.

Q: Why don’t all blockchains use BFT? A: BFT requires identity and accountability—you must know who the validators are to slash malicious behavior. This limits the validator set size. Nakamoto-style PoW consensus (like Bitcoin) works with permissionless, anonymous miners. The trade-off is that Nakamoto consensus provides probabilistic finality rather than deterministic finality.

Q: What is the relationship between BFT and the blockchain trilemma? A: BFT protocols directly demonstrate the trilemma. To achieve BFT safety and deterministic finality, most implementations limit their validator sets, reducing decentralization. Ethereum’s approach of combining BFT finality (Casper) with LMD GHOST head selection is an attempt to get the best of both worlds—probabilistic availability with eventual BFT finality.