Crash Fault Tolerance (CFT)

A CFT protocol guarantees safety (all non-faulty nodes agree on the same value/order) and liveness (the system continues to make progress) as long as a majority of nodes are non-faulty. The classic threshold is f < N/2, meaning the system can tolerate fewer than half of its N nodes crashing. This is less stringent than Byzantine Fault Tolerance (BFT), which assumes nodes can act arbitrarily.

Paxos is the seminal CFT consensus algorithm, introduced by Leslie Lamport. It operates in phases (Prepare/Promise, Accept/Accepted) to achieve agreement on a single value among a set of nodes, even if some crash. Its complexity led to more practical derivatives. Key concepts include:

• Proposers, Acceptors, and Learners as distinct roles.
• Quorums of acceptors to ensure progress.
• Consensus on a single log entry, requiring multiple instances for a sequence (Multi-Paxos).

CFT protocols are ideal for permissioned or consortium blockchains where all participants are known and trusted not to be malicious (e.g., enterprise supply chains, interbank settlements). They offer higher throughput and lower latency than BFT protocols. Examples include:

• Hyperledger Fabric's initial ordering service (now supports BFT).
• The consensus layer in distributed databases like Google Spanner (uses Paxos variants).
• Quorum (an Ethereum fork) with its Raft-based consensus.

The critical limitation of CFT is its trust assumption: it cannot tolerate Byzantine (arbitrary) faults, such as a node sending conflicting messages or lying. In adversarial environments like public, permissionless blockchains (e.g., Bitcoin, Ethereum), BFT protocols (Practical Byzantine Fault Tolerance, Nakamoto Consensus) are required. CFT's f < N/2 crash fault model is a strict subset of BFT's f < N/3 byzantine fault model.

CFT algorithms like Raft and Paxos are designed for environments where nodes are trusted but may become unavailable. They assume nodes fail only by crashing (stopping) and do not send arbitrary, conflicting messages. This makes them simpler and faster than Byzantine Fault Tolerant (BFT) protocols but unsuitable for adversarial, permissionless networks.

The primary security limitation of CFT is its vulnerability to Byzantine faults. In a decentralized blockchain context, a malicious validator can:

• Send contradictory messages to different nodes (equivocation).
• Censor or reorder transactions.
• Propose invalid blocks. CFT consensus cannot distinguish these malicious acts from network delays, leading to potential safety violations like double-spending.

CFT is appropriately used in permissioned blockchain systems where all participants are known and vetted entities (e.g., enterprise consortia, private ledgers). Examples include:

• Hyperledger Fabric (which can use Raft for ordering).
• Internal settlement systems between trusted financial institutions. The security model relies on legal and procedural controls off-chain to ensure node operators are not malicious.

CFT protocols offer superior throughput and finality latency compared to BFT protocols because they require fewer message exchanges and simpler validation logic. For instance, Raft can achieve consensus in the time of a single round-trip message. However, this performance gain comes at the direct cost of decentralization security, making it a clear trade-off for system designers.

• Byzantine Fault Tolerance (BFT): Tolerates up to f malicious nodes out of 3f+1 total (e.g., Tendermint, PBFT). Required for public, permissionless chains.
• Nakamoto Consensus (Proof-of-Work): Tolerates an adversary with less than 50% of hashrate, achieving probabilistic finality through longest-chain rule. CFT sits apart, offering deterministic finality but only in a non-adversarial setting.

The guarantee that a committed transaction is irreversible and will not be reverted. In CFT systems, finality is typically deterministic and immediate once consensus is reached among the non-faulty nodes, as there is no threat of equivocation or conflicting blocks. This contrasts with probabilistic finality in Nakamoto Consensus (e.g., Bitcoin), where assurance increases with each subsequent block. CFT's strong finality is critical for high-throughput financial systems and state machine replication where consistency is paramount.

A key distinction in blockchain network design that dictates the appropriate fault tolerance model.

• Permissioned Networks: Use known, vetted participants. CFT is often sufficient here, as the threat model assumes crashes, not malice. Examples include enterprise consortium chains (Hyperledger Fabric, Corda).
• Permissionless Networks: Allow anonymous participation. They require BFT or similar robust models (e.g., Proof-of-Work) to withstand Sybil attacks and Byzantine actors. Examples include Bitcoin and Ethereum. Choosing the wrong model for the network type is a critical security failure.

The two fundamental guarantees of a consensus protocol, often in tension.

• Safety: The guarantee that nothing bad happens (e.g., no two correct nodes decide on different values). CFT protocols prioritize safety; they will halt progress rather than risk inconsistency.
• Liveness: The guarantee that something good eventually happens (e.g., requests are eventually processed). The FLP Impossibility result proves that in an asynchronous network, no deterministic protocol can achieve both safety and liveness in the presence of even a single crash fault. CFT protocols use mechanisms like leader election and timeouts to provide liveness in practice.