Byzantine Fault Tolerance: Definition, Algorithms, and Significance for DLT Consensus

Definition

Byzantine fault tolerance (BFT) is the property of a distributed system that enables it to continue operating correctly and reaching consensus even when some of its participating nodes fail in arbitrary or malicious ways — including sending conflicting information to different parts of the network, selectively withholding messages, or coordinating with other faulty nodes to subvert the system. A system that achieves BFT can tolerate not only crash failures (nodes that simply stop responding) but also Byzantine failures (nodes that actively attempt to deceive or disrupt the network). In distributed ledger technology, BFT is a fundamental property that determines a network’s resilience against adversarial participants.

The Byzantine Generals Problem

The concept of Byzantine fault tolerance originates from the Byzantine Generals Problem, formulated by Leslie Lamport, Robert Shostak, and Marshall Pease in 1982. The problem describes a scenario in which several generals of the Byzantine army must coordinate an attack on a city. They can communicate only by messenger, and some of the generals may be traitors who send false messages to prevent the loyal generals from reaching agreement. The problem asks: how can the loyal generals reach consensus on a common plan of action despite the presence of traitors?

The authors proved that reaching consensus is impossible if one-third or more of the generals are traitors. Conversely, if fewer than one-third of the participants are faulty, consensus can be achieved through algorithms that ensure all honest participants agree on the same value. This one-third threshold is a fundamental limit of BFT systems and directly determines the fault tolerance properties of DLT consensus mechanisms based on BFT principles.

BFT in Distributed Ledger Technology

BFT is a critical property for DLT networks because the participants in a distributed ledger — validators, miners, or nodes — may be untrusted entities with potentially conflicting interests. A DLT consensus mechanism that achieves BFT can guarantee that the ledger remains consistent and accurate even if some validators attempt to manipulate transaction ordering, double-spend tokens, or disrupt network operations.

The relevance of BFT varies by network type. In permissionless networks with unknown and unbounded participants, achieving classical BFT is challenging because the total number of participants — and therefore the one-third threshold — is not known. Proof-of-work and proof-of-stake consensus mechanisms address this challenge through economic mechanisms (computational cost or staked capital) that make Byzantine behaviour expensive.

In permissioned networks with a known set of validators, classical BFT algorithms can be directly applied. The known validator set enables the calculation of the one-third threshold and the implementation of multi-round voting protocols that guarantee consensus among honest validators. This is why BFT-based consensus is prevalent in enterprise DLT networks and regulated financial market infrastructure, including Swiss institutional platforms.

Practical Byzantine Fault Tolerance (PBFT)

Practical Byzantine Fault Tolerance, introduced by Miguel Castro and Barbara Liskov in 1999, made BFT consensus computationally practical for real-world distributed systems. Prior BFT algorithms had theoretical significance but were too expensive for practical deployment. PBFT reduced the complexity to polynomial time, enabling BFT consensus in production systems.

PBFT operates through a three-phase protocol: pre-prepare, prepare, and commit. A designated leader (primary) proposes a value (such as a block of transactions) in the pre-prepare phase. Validators broadcast their agreement in the prepare phase, and once a sufficient number of prepare messages are received, they broadcast commit messages. When a validator receives enough commit messages (from at least 2f+1 nodes, where f is the maximum number of faulty nodes), the value is committed to the ledger.

PBFT provides deterministic finality — once a value is committed, it cannot be reverted, even if the leader node fails or is replaced. This property makes PBFT particularly suitable for financial market infrastructure, where the irrevocability of settlements is a regulatory requirement. SDX’s settlement finality, for example, relies on deterministic consensus that aligns with the settlement finality provisions of the Swiss Financial Market Infrastructure Act.

PBFT has a communication complexity of O(n^2), where n is the number of validators. This quadratic scaling limits the practical size of the validator set — typically to tens or at most a few hundred nodes — making PBFT more suitable for permissioned networks with a limited number of known validators than for large-scale permissionless networks.

BFT Variants in Modern DLT

Several variants and improvements of PBFT have been developed to address its scalability limitations and adapt its principles to different network environments.

Tendermint BFT combines BFT consensus with a proof-of-stake Sybil resistance mechanism, enabling BFT consensus in networks with larger validator sets than traditional PBFT can support. Tendermint is used in the Cosmos ecosystem and in numerous application-specific blockchains.

HotStuff introduces a linear communication complexity (O(n) per phase) by using a leader-based protocol with threshold signatures, enabling BFT consensus to scale to hundreds of validators. HotStuff and its derivatives are used in several modern blockchain networks and were the basis of Meta’s Libra/Diem consensus protocol.

Istanbul BFT (IBFT) is a PBFT variant designed for Enterprise Ethereum networks, providing deterministic finality for permissioned Ethereum deployments. IBFT is used in Hyperledger Besu and other Enterprise Ethereum platforms deployed by Swiss institutions.

Security Model

The security of a BFT system depends on the assumption that fewer than one-third of validators are Byzantine. If this threshold is exceeded — through collusion, compromise, or accumulated control — the system’s guarantees break down. A coalition of more than one-third of Byzantine validators could potentially prevent consensus (causing a liveness failure) or, in some variants, cause the network to commit conflicting values (causing a safety failure).

For Swiss institutional DLT networks, the BFT threshold directly influences validator governance. The selection, monitoring, and replacement of validators must be managed to ensure that the one-third threshold is never approached. Regulatory requirements for financial market infrastructure — including FINMA’s expectations for governance, access arrangements, and operational resilience — are designed in part to prevent the accumulation of Byzantine risk in the validator set.

Relationship to Finality

BFT consensus mechanisms provide deterministic finality, meaning that once a transaction is committed through the BFT protocol, it is permanently part of the ledger and cannot be reversed. This is in contrast to probabilistic finality in proof-of-work systems, where the probability of reversal decreases with each subsequent block but never reaches zero. For Swiss financial market infrastructure, where the FMIA requires settlement finality, BFT-based consensus is the preferred approach.

Donovan Vanderbilt is a contributing editor at ZUG DLT, covering distributed ledger technology law, regulation, and institutional adoption from Zurich. The Vanderbilt Portfolio AG provides research and analysis on Swiss digital asset infrastructure.