Byzantine Fault Tolerance Explained: How Blockchains Agree When Some Nodes Lie

What Byzantine Fault Tolerance Does

Every decentralized network faces the same core problem. Thousands of independent computers, run by strangers, have to agree on one shared history without a referee. Some of those computers will crash. Some will be slow. And some will lie, sending one message to half the network and a contradictory message to the other half. A system that survives all of that is Byzantine Fault Tolerant.

The name comes from a 1982 paper by Leslie Lamport, Robert Shostak, and Marshall Pease called "The Byzantine Generals Problem."^[1] Picture several generals surrounding a city. They can only communicate by messenger, and some generals may be traitors who send fake orders. The loyal generals still need to agree on a single plan, attack or retreat, or they lose. The paper proved when agreement is possible and when it is mathematically impossible.

The blockchain version is identical. Swap generals for validators and traitors for malicious nodes. A Byzantine fault is the worst kind of failure: not just a node going dark, but a node behaving arbitrarily, including lying in coordinated ways. Tolerating that is the highest bar in distributed systems, which is why "BFT" is shorthand for a network that is hard to break.

How Byzantine Fault Tolerance Works

The mechanics center on voting. Instead of competing to produce blocks the way Proof of Work miners do, a known set of validators vote on each proposed block, and a supermajority decides.

1. A Proposer Suggests a Block

In each round, one validator is selected to propose the next block. The selection is usually rotating or pseudo-random, so no single node controls the agenda. The proposer broadcasts its block to every other validator.

2. Validators Vote in Rounds

The other validators check the block and broadcast their votes. Classic PBFT does this in multiple phases (pre-prepare, prepare, commit) so that everyone can confirm not just the block but that everyone else saw the same block. This guards against a traitor showing different data to different peers.

3. The Two-Thirds Threshold

A block is committed only when more than two-thirds of the validator set signs off on it. This is the heart of BFT. With a 2/3 supermajority required, a network of size N can tolerate up to f faulty validators as long as N is greater than 3f. In plain terms, fewer than a third can be Byzantine before agreement is at risk.

4. Deterministic Finality

Once that supermajority commits, the block is final. Period. It cannot be reorganized or reversed by later blocks. This is "instant" or "deterministic" finality, and it is the defining feature traders care about. There is no waiting for confirmations to pile up.

Why More Than Two-Thirds

The 2/3 rule is not arbitrary. To stay both safe (no two honest nodes ever accept conflicting blocks) and live (the chain keeps making progress) while some nodes are faulty, the math forces the supermajority above two-thirds. Drop below it and a colluding third of validators can either halt the chain or, worse, finalize two conflicting versions of history.

From Theory to Practice: PBFT and Its Descendants

The 1982 paper proved BFT was possible but the early solutions were slow and assumed reliable timing. The breakthrough came in 1999, when Miguel Castro and Barbara Liskov published Practical Byzantine Fault Tolerance (PBFT).^[2] PBFT worked in realistic asynchronous networks and was efficient enough to use in production. Almost every BFT design in crypto traces back to it.

The catch with classic PBFT is communication cost. Every validator talks to every other validator, so message traffic grows with the square of the validator count. That works for dozens of nodes, not thousands. Modern protocols attack exactly this bottleneck:

• Tendermint (now CometBFT) streamlined PBFT for public PoS chains and powers the Cosmos ecosystem. It delivers single-block finality in a few seconds.^[3]
• HotStuff cut the communication rounds and made voting "linear" instead of quadratic, so the validator set can grow. It underpins Aptos and influenced many newer designs.^[4]
• Tower BFT is Solana's variant, layered on top of its Proof of History clock to reach agreement quickly at high throughput.

BFT Compared to Nakamoto Consensus

The trade is clear. BFT buys fast, irreversible finality and pays for it with a bounded, known validator set. Nakamoto consensus buys fully open participation and pays for it with slow, probabilistic settlement. For a wider map of designs (Nakamoto, BFT, DPoS, Proof of History, and more), see our guide to consensus mechanisms compared.

How BFT Relates to Proof of Stake

This is the part that confuses people. BFT and Proof of Stake are not competing mechanisms. They answer two different questions.

Proof of Stake answers "who is allowed to vote?" It uses staked capital to select and weight the validator set, and it uses slashing to punish cheaters. BFT answers "how do those chosen validators agree?" It runs the round-based voting that produces finality. Stack them together and you get the dominant architecture of modern chains: PoS for membership and economic security, BFT for ordering and finality.

That is exactly what Cosmos chains do with Tendermint, what Near does with its Nightshade design, and what Ethereum's Casper FFG finality gadget approximates on a larger validator set. So when a chain advertises "instant finality" and "Proof of Stake" in the same breath, a BFT voting layer is almost always doing the finality work.

Where Byzantine Fault Tolerance Is Used

Solana is the clearest high-throughput example: Tower BFT reaches agreement in roughly a second by leaning on Proof of History to pre-order transactions. Near shows the sharded approach, splitting the network while keeping BFT-style finality across shards. And the Cosmos ecosystem is where you see the textbook BFT-PoS combination running at scale.

The Tradeoffs and Risks

BFT's strengths and limits are two sides of one design choice: a known, bounded validator set.

• Strength: deterministic finality and strong safety. Once committed, a block is permanent, which is ideal for settlement, bridges, and anything that cannot tolerate reorgs.
• The scaling limit: classic all-to-all voting does not scale to thousands of validators without help. HotStuff-style designs ease this, but there is still pressure toward smaller sets than open PoW networks.
• The liveness risk: if more than a third of validators go offline at once, a strict BFT chain can halt entirely rather than fork. A stalled chain is safer than a split one, but a halt is still a real outage. Several BFT-based networks have paused block production after losing too many validators.
• The validator-set assumption: BFT only protects you if fewer than a third of validators collude. On a chain with a small or concentrated set, that assumption deserves scrutiny, not faith.

There is also a known impossibility result, FLP, which says no deterministic protocol can guarantee both safety and liveness in a fully asynchronous network with even one faulty node. BFT protocols handle this with timeouts and leader rotation, trading a little timing assumption for practical progress.

Combining BFT Knowledge with Other Pillars

BFT + Fundamentals

BFT sits underneath most of the consensus designs you will read about. Pair this with Proof of Stake to see how membership and finality fit together, and with consensus mechanisms compared for the full taxonomy.

BFT + On-Chain Analysis

On a BFT chain, validator participation is a live health metric. Approaching the one-third offline threshold is a genuine risk signal, since the chain can halt rather than degrade gracefully. Watching validator uptime is part of on-chain analysis.

BFT + News and Regulation

Because BFT chains depend on a bounded validator set, the geographic and corporate concentration of those validators is a regulatory surface. Pressure on a handful of large operators matters more here than on an anonymous PoW network.