What is Byzantine fault tolerance (BFT)?

These nodes can be unreliable due to network issues, software bugs, or even deliberate attacks. BFT systems guarantee that despite these challenges, all nodes agree on the same state and perform the same action, preventing inconsistent or erroneous behavior.

Here are some scenarios where BFT is applied:

• Blockchain technology, to ensure the consistency and security of transactions.
• Financial systems, to guarantee the integrity of financial transactions and prevent unauthorized access.
• Air traffic control, to provide reliable communication and safe operation in critical systems.What is the main concept behind practical Byzantine fault tolerance?

What is the main concept behind practical Byzantine fault tolerance?

Copy link

BFT relies on a core principle of majority consensus. All participants in the system must agree on the same outcome, even if some components fail or act maliciously. This concept is often realized through practical Byzantine fault tolerance (PBFT), a specific BFT algorithm.

PBFT works by:

• Data replication. Each participant receives and stores the same information.
• Multi-phase communication. In multiple rounds, participants exchange information and vote on proposed decisions.
• Fault detection and recovery. Mechanisms are in place to identify and handle faulty or malicious components.

This multi-phase process with excessive communication ensures several crucial things:

• Consistency. All nodes agree on the final decision (attack or retreat), even if some are faulty or malicious.
• Liveness. If a correct majority exists, the system eventually reaches a decision without getting stuck.
• Fault tolerance. The system can tolerate up to a certain number of faulty nodes (typically one-third) and still function correctly.

How does the Byzantine fault tolerance work?

Copy link

The multi-phase communication that PBFT uses unfolds through three ordered phases: pre-prepare, prepare, and commit. The classical algorithm, introduced by Castro and Liskov in 1999, remains the foundation that most modern BFT variants build on.

A client starts by sending a request to the designated primary (leader). The primary and replicas then move through the three phases: The primary and replicas then move through the three phases:

1. 1. Pre-prepare. The primary assigns a sequence number to the request and broadcasts a pre-prepare message to all backup replicas. This locks in the ordering that consensus will use.
2. 2. Prepare. Each replica that accepts the pre-prepare broadcasts a prepare message to every other replica. When a replica has collected 2f matching prepare messages from others (where f is the maximum number of faulty nodes the system tolerates), it considers the request "prepared." At this point replicas have agreed on the ordering but have not yet committed.
3. 3. Commit. Each replica broadcasts a commit message. When a replica has collected 2f+1 matching commit messages, it considers the request "committed" and executes it. The request is now finalized.
4. After the commit phase, replicas send their result back to the client. The client accepts the result once it receives f+1 matching replies from different replicas, which guarantees at least one honest replica has confirmed the same outcome.
5. View change. If replicas suspect the primary is faulty (missing messages, taking too long, sending contradictory pre-prepares), they trigger a view change protocol to elect a new primary. This keeps the system live even when the leader fails.

Different BFT algorithms differ in the details. Tendermint and CometBFT use a leader-based flow with pre-vote and pre-commit phases. HotStuff and its derivatives (DiemBFT, Aptos, Sui) introduce a chained pipeline that reduces the message complexity of classical PBFT. But the core structure of "propose → vote → commit" carries through all of them.

PBFT vs other consensus models

Copy link

BFT algorithms live inside a wider family of distributed consensus protocols. Understanding where PBFT sits helps clarify when it is the right choice and when a different approach fits better.

Crash-fault tolerant (CFT) protocols: Paxos and Raft. Paxos and Raft assume nodes may crash or become unreachable, but not that any node will actively lie. They can tolerate up to half of the nodes failing. Both are widely used inside data centers for coordinating a small number of trusted nodes (Kubernetes uses Raft in etcd; databases like CockroachDB use Raft). CFT protocols are simpler and faster than BFT, but they assume all nodes are honest.

PBFT and classical BFT. PBFT tolerates Byzantine faults, meaning nodes that behave arbitrarily, including lying, colluding, or sending contradictory messages. The cost is more communication (message complexity grows quadratically with node count) and a hard limit of tolerating fewer than one-third of nodes acting maliciously. PBFT works well with tens of nodes; scaling to hundreds or thousands requires optimizations.

HotStuff and modern BFT. HotStuff introduced a linear communication pattern that reduces the message complexity of classical PBFT. It is the basis for many current BFT algorithms, including those used in Aptos, Sui, and earlier Diem. Modern derivatives (DiemBFT, Narwhal-Bullshark, Mysticeti) push throughput significantly higher while keeping BFT guarantees.

Nakamoto consensus (Proof of Work). Bitcoin-style Proof of Work is not a BFT algorithm in the classical sense. It achieves probabilistic finality by making dishonest behavior economically expensive, not by explicit voting rounds. Nakamoto consensus scales to thousands of nodes but sacrifices immediate finality (transactions become "final" as more blocks are added on top) and consumes significant energy.

Proof of Stake variants. Most modern PoS chains use a BFT-style algorithm underneath for finality (Ethereum's Casper FFG, Cosmos's Tendermint/CometBFT, Algorand's Byzantine agreement). PoS becomes the mechanism for choosing who votes, and BFT is the mechanism for voting.

When to use which. CFT protocols (Paxos, Raft) fit closed environments where all nodes are trusted (databases, cluster management). BFT protocols fit open or partially trusted environments where some nodes may misbehave (blockchains, cross-organization systems, high-value financial infrastructure). Nakamoto consensus fits fully open, permissionless environments where node identity cannot be established at all.

For distributed consensus in general, the choice comes down to three factors: how many nodes need to participate, how trusted those nodes are, and whether the application can tolerate probabilistic finality or requires immediate certainty.

BFT in blockchain

Copy link

BFT algorithms underpin most modern high-performance blockchains, especially those built for financial applications or enterprise use. The reason is straightforward: BFT provides immediate deterministic finality, which is what regulated financial systems and enterprise applications need.

Where BFT shows up in blockchain. Cosmos and the broader Interchain ecosystem run on CometBFT (formerly Tendermint), a PBFT-derived algorithm optimized for blockchain workloads. Solana combines a BFT-style vote called Tower BFT with a novel Proof of History clock. Algorand uses a randomized Byzantine agreement protocol. Aptos and Sui use HotStuff-derived algorithms (DiemBFT, Mysticeti) with sub-second finality. Hedera Hashgraph uses an asynchronous BFT approach based on gossip and virtual voting. Ethereum's post-Merge finality gadget (Casper FFG) is a BFT algorithm layered on top of its Proof of Stake block proposal.

What BFT gives blockchain that Nakamoto consensus does not. Immediate finality: once a block is committed, it cannot be reverted, so applications do not need to wait for confirmations. Higher throughput: BFT chains routinely process thousands of transactions per second, compared to Bitcoin's roughly seven. Lower energy use: no mining involved. Predictable block times: BFT algorithms produce blocks at consistent intervals rather than the variable intervals of PoW.

What BFT costs blockchain. Smaller validator sets: classical BFT scales poorly beyond a few hundred nodes, so BFT chains have fewer validators than fully permissionless chains. Higher liveness requirements: if more than one-third of validators go offline or misbehave simultaneously, the chain halts rather than continuing with reduced security. More sensitive to network conditions: BFT algorithms are more affected by latency and network partitions than gossip-based approaches.

Practical implication. Byzantine fault tolerance blockchain designs suit financial settlement, cross-chain bridges, real-world asset tokenization, and enterprise consortia. They are less well-suited for maximally decentralized, censorship-resistant applications where the validator set needs to be very large and permissionless.

Why BFT matters for finality and reliability

Copy link

Two properties matter most in production distributed systems: finality (once a decision is made, it stays made) and reliability (the system keeps working when things go wrong). BFT is one of the few consensus approaches that guarantees both under adversarial conditions.

• Deterministic finality. In a BFT system, once a block or a transaction is committed, it cannot be reverted, even if a portion of the network fails or acts maliciously afterward. Compare this to Bitcoin's probabilistic finality, where a transaction is more likely to stay in the chain the more blocks are built on top of it, but is never technically irreversible. For financial settlement, custody, and any workflow where a "reversal" is not an acceptable outcome, deterministic finality is a hard requirement.
• Reliability under partial failure. BFT tolerates up to one-third of nodes acting arbitrarily (crashing, lying, colluding) and still produces correct outcomes. This threshold is a mathematical property, not a tuning parameter. Below one-third malicious nodes, the system is guaranteed to reach a correct decision. Above that threshold, no algorithm can provide guarantees, so any BFT-based system must be designed so that this threshold is protected structurally (through validator selection, staking economics, or governance).
• Where finality and reliability really matter. Payment systems and settlement layers, where reversing a committed transaction can cascade through dependent systems. Cross-chain bridges, where finality delays create arbitrage and attack windows. High-value custody, where probabilistic finality means the custodian never knows for certain whether a transfer is complete. Air traffic control, industrial control, and other safety-critical systems where distributed decisions must not diverge. Enterprise consortia where nodes belong to different organizations that do not fully trust each other but must reach agreement.
• Trade-offs to accept. BFT systems require enough nodes to detect and outvote misbehavior, but not so many that message complexity dominates performance. Practical validator sets range from tens to a few hundred nodes. BFT also requires reasonable network conditions; extremely high latency or long partitions cause the system to halt (preserving safety) rather than continue with reduced guarantees.

For teams designing systems that need to keep working correctly when part of the network fails or acts adversarially, BFT is the class of algorithms worth studying. It is one of the few tools that provides mathematical guarantees under those conditions.

Copy link