Distributed Consensus: From 2PC to Blockchain

A unified tour of how distributed systems agree on a single value — from classic 2PC through Paxos, Raft, PBFT, and Nakamoto-style blockchain consensus.

Consensus is the foundational problem of distributed computing: how do N processes agree on a single value even when some of them fail? The answer determines the consistency guarantees, availability, and fault model of every distributed system in this course.

FLP Impossibility (Fischer, Lynch, Paterson 1985)

In a purely asynchronous distributed system — where there are no timing bounds on message delivery or process speed — it is impossible to deterministically solve consensus if even one process may crash.

The proof shows that any protocol can always be driven into a "bivalent" configuration (where both 0 and 1 outcomes remain reachable) by an adversarial scheduler, preventing termination.

In practice we break one assumption: we use timeouts (Paxos, Raft) — which violate pure asynchrony by introducing weak timing assumptions — or randomization (Ben-Or) to circumvent the impossibility. Blockchains use probabilistic finality rather than deterministic termination.

Protocol Comparison

Six major consensus protocols spanning crash fault tolerance (CFT), Byzantine fault tolerance (BFT), and Nakamoto/blockchain consensus.

2PCCFT
Atomic commit
Fault model:Crash (coordinator)
Messages:O(N)
Leader:Yes
Used in:Databases (MySQL, Postgres distributed txns)
PaxosCFT
SMR
Fault model:Crash (f < N/2)
Messages:O(N²)
Leader:Yes
Used in:Chubby, ZooKeeper
RaftCFT
SMR
Fault model:Crash (f < N/2)
Messages:O(N)
Leader:Yes
Used in:etcd, CockroachDB, TiKV
PBFTBFT
BFT
Fault model:Byzantine (f < N/3)
Messages:O(N²)
Leader:Yes
Used in:Hyperledger Fabric
PoWNakamoto
Nakamoto consensus
Fault model:Byzantine (f < 50% hash)
Messages:O(N)
Leader:No (probabilistic)
Used in:Bitcoin, Litecoin
PoSNakamoto
Nakamoto-style
Fault model:Byzantine (f < 33% stake)
Messages:O(N)
Leader:No (stochastic)
Used in:Ethereum 2.0, Cardano
Consensus protocol comparison — scroll horizontally on mobile
ProtocolTypeFault ModelMsg ComplexityLeader?Used In
2PCAtomic commitCrash (coordinator)O(N)YesDatabases (MySQL, Postgres distributed txns)
PaxosSMRCrash (f < N/2)O(N²)YesChubby, ZooKeeper
RaftSMRCrash (f < N/2)O(N)Yesetcd, CockroachDB, TiKV
PBFTBFTByzantine (f < N/3)O(N²)YesHyperledger Fabric
PoWNakamoto consensusByzantine (f < 50% hash)O(N)No (probabilistic)Bitcoin, Litecoin
PoSNakamoto-styleByzantine (f < 33% stake)O(N)No (stochastic)Ethereum 2.0, Cardano

Interactive: Minimum Replicas by Fault Tolerance

Fault Tolerance Calculator
Tolerate f =1faulty nodes
CFT (Paxos / Raft)
3
replicas needed (2f+1)
quorum = 2/3
BFT (PBFT)
4
replicas needed (3f+1)
quorum = 3/4
PoW (Bitcoin)
> 50%
honest hash power required
no fixed node count
Why 3f+1 for BFT? Quorums must overlap in at least f+1 nodes to guarantee at least one honest node is in every pair of quorums.

CAP Theorem

Every consensus protocol makes a trade-off between consistency and availability under network partition. Crash-fault-tolerant protocols (Paxos, Raft) are CP. Nakamoto consensus (Bitcoin) is more nuanced: it provides eventual consistency (AP-like) but requires honest majority of hash power.

CAP Theorem — Interactive Triangle

Click a zone (CP, AP, or CA) to see which systems live there and why.

CPAPCACConsistencyAAvailabilityPPartition Tol.BigtableDynamoRDBMS
Click a zone (CP, AP, CA) or the colored triangle sectors to explore
# CAP Theorem (Brewer 2000, formally proved 2002)
In any distributed system, during a network partition (P),
you must choose between Consistency (C) and Availability (A).
Note: Partitions are inevitable in real networks →
every distributed system is either CP or AP (not CA).

Deep Dives

Consensus Exam Questions

Key questions on the fundamentals — FLP impossibility, 2PC vs Paxos, quorums.