Twenty-two algorithms and protocols, thirteen production systems, ten phases — this article compresses all of it into one reference table and a decision framework, so that the entire journey from article 1.1 through article 10.3 becomes something you can scan in minutes rather than reread in full. This is deliberately the most reference-oriented article in the series: less narrative, more lookup table, designed to be the page you return to when choosing between algorithms for a real system rather than learning any of them for the first time.
The master table
| Algorithm | Fault model | Node count | Leader? | Distinctive mechanism | Article |
|---|---|---|---|---|---|
| Paxos / Multi-Paxos | Crash | 2f+1 | Stable (amortized) | Phase 1/2 promise-and-accept, majority overlap | 5.1-5.3 |
| Viewstamped Replication | Crash | 2f+1 | Stable | Independently-derived views/primary, same safety core | 5.4 |
| Raft | Crash | 2f+1 | Stable | Decomposition for understandability, log matching | 5.5-5.6 |
| Zab | Crash | 2f+1 | Stable | Structural FIFO client order via zxids | 5.7 |
| PBFT | Byzantine | 3f+1 | Rotating (view change) | All-to-all pre-prepare/prepare/commit | 6.2 |
| HotStuff | Byzantine | 3f+1 | Rotating (pipelined) | Threshold-signature aggregation, three-chain commit | 6.3 |
| Tendermint | Byzantine | 3f+1 | Rotating (round-based) | Immediate deterministic finality, slashing | 6.4 |
| Narwhal/Bullshark | Byzantine | 3f+1 | None for dissemination | DAG mempool separated from ordering | 6.5 |
| EPaxos | Crash | 2f+1 (larger fast quorum) | None (per-command) | Dependency-graph ordering | 7.1 |
| Flexible Paxos | Crash | Q1∩Q2≠∅, asymmetric | Stable | Quorums need only intersect, not both be majorities | 7.2 |
| Fast/Generalized Paxos | Crash | 2f+1 | Fast rounds skip leader | Commutativity, one-round-trip fast rounds | 7.3 |
| Cheap/Compartmentalized Paxos | Crash | f+1 main + f standby / decomposed | Stable | Idle standbys; role decomposition for scaling | 7.4 |
| Atlas | Crash | Near-majority fast quorum | None (per-command) | Flexible Paxos applied to EPaxos's setting | 7.5 |
| Caesar | Crash | 2f+1-ish | None (per-command) | Proactive ordering certificates | 7.6 |
| OmniPaxos | Crash | 2f+1 | Stable, decoupled election | Production-engineered library, first-class reconfiguration | 7.7 |
| Matchmaker Paxos | Crash | 2f+1 | Stable | Dedicated matchmaker role for safe reconfiguration | 7.8 |
| PigPaxos | Crash | 2f+1 | Stable | Gossip-relay fan-out instead of direct leader broadcast | 7.8 |
| BPaxos | Crash | 2f+1 | Decoupled ordering/dissemination | Narwhal-style separation, crash-fault setting | 7.8 |
| Rabia | Crash | 2f+1 | None per-round | Randomization to simplify, not just to escape FLP | 7.8 |
| QuePaxa | Crash (adversarial-network-robust) | 2f+1 | Fast-path leader, no timeout dependency | Randomized async core, hedging delays, bandit tuning | 10.2 |
Fig 1 — Every Phase 7 variant, plus QuePaxa, mapped onto exactly which convenience assumption it relaxes.
Reading the table's patterns, not just its rows
Beyond looking up any single algorithm, the table rewards reading across it for patterns this series has built up piece by piece. Notice that the node-count column is almost entirely either 2f+1 or 3f+1 — there is no algorithm in this entire series' coverage that finds some clever way around article 6.1's proven threshold; the Byzantine/crash-fault boundary is a hard line every single entry respects, regardless of how sophisticated its other optimizations are. Notice, too, that the "leader?" column shows a genuine spread — stable, rotating, per-command-none, and QuePaxa's hybrid fast-path-with-fallback — but that every single entry, without exception, still relies on the same majority-overlap safety mechanism from article 3.3 underneath whatever leadership structure it uses on top. The table's real lesson isn't found in any one row; it's found in what stays constant across every row despite twenty different surface-level designs: majority overlap for safety, a small number of genuinely distinct fault-tolerance thresholds, and liveness as the dimension nearly every innovation actually targets.
A decision framework, distilled
Rather than a flowchart (which tends to oversimplify genuinely contextual decisions into false certainty), here's the actual sequence of questions this series' own material supports asking, in order, when choosing among this table's entries for a real system:
- Do you need Byzantine tolerance? If any participant might be actively malicious or compromised (open/permissionless networks, adversarial multi-party settings) — go to the Phase 6 family (PBFT, HotStuff, Tendermint, Narwhal/Bullshark) and accept the 3f+1 node-count floor (article 6.1). If all participants are operated by one trusted organization, crash-fault tolerance (2f+1) is sufficient and considerably cheaper.
- Is understandability/operational maturity your top priority? Raft (5.5-5.6), wrapped by a production system like etcd (8.1), remains the most battle-tested, most widely-documented, easiest-to-hire-for choice — the default this series would recommend absent a specific reason to deviate.
- Is your workload latency-sensitive with low real contention, spread across a wide area? Consider EPaxos-family leaderless designs (7.1, 7.5, 7.6) — but only if you've confirmed genuine low contention; under high contention, their advantage shrinks or reverses relative to a well-placed Raft leader (article 9.5's leader-placement discussion).
- Are you fighting adversarial WAN jitter or DoS-style conditions specifically? QuePaxa (10.2) targets exactly this, at the cost of real implementation complexity — appropriate for Meerkat-scale (10.3) deployments, likely overkill for a single-datacenter cluster.
- Is reconfiguration frequency or safety your main operational pain point? OmniPaxos (7.7) and Matchmaker Paxos (7.8) specifically prioritize this.
- Is throughput at very large validator/replica counts the bottleneck? HotStuff (6.3) for Byzantine settings, PigPaxos or BPaxos (7.8) for crash-fault settings — both directly targeting the fan-out cost this series traced from article 6.2 through 9.2.
FAQ
Why isn't there a single "best" algorithm at the top of this table?
Because, as this series has demonstrated repeatedly since Phase 7, there genuinely isn't one — every entry optimizes a specific axis (understandability, latency, throughput, cost, adversarial robustness) at some honest cost on another. A ranked "best to worst" list would misrepresent the actual shape of this research area.
Which algorithms in this table are most commonly seen in real production systems today?
Raft (via etcd, Consul, CockroachDB, TiDB, YugabyteDB) and Multi-Paxos (via Spanner, Chubby) dominate real-world deployment by a wide margin, per Phase 8-9's coverage; the Phase 6 BFT family dominates blockchain and consortium settings; the more specialized Phase 7 variants and QuePaxa remain comparatively rare in production outside of research-adjacent deployments like Meerkat.
Should this table be treated as exhaustive?
No — it covers every algorithm this series chose to include, which is itself a curated, not exhaustive, subset of a much larger research literature. Article 10.6 (open problems) and the broader field continue producing new variants; treat this table as a snapshot grounded in this series' coverage, not a permanent, closed reference.
Takeaways
- This series' twenty algorithms/protocols compress into one master table, comparable directly on fault model, node count, leader structure, and distinctive mechanism.
- Every Phase 7 variant, plus QuePaxa, maps cleanly onto which of Multi-Paxos's bundled convenience assumptions it relaxes — fixed leader, total order, symmetric quorums, uniform cost, and (QuePaxa's addition) timeout-based liveness.
- The decision framework is a sequence of honest questions about your actual constraints (Byzantine tolerance needed? Understandability priority? Contention level? Adversarial network conditions? Reconfiguration frequency? Scale?) — not a ranked list.
- No algorithm in this table is simply "better" than the others in general — each is the right answer for a specific, nameable set of constraints, the central, repeated lesson of this entire series.
References & further reading
- cvam.sight — Consensus Algorithms series hub — every article this master table summarizes, linked directly.
- cvam.sight — Consensus 10.1: How to Read a Consensus Paper — the framework this table's decision process directly extends.