May 11th, 2026 "DON'T FUCK UP!" This taxonomy of approaches for keeping ordered or shared state across realized distributed systems explains how multiple participants can be accommodated, while not breaking things. Though at basis, it's all just gliders, really. Here, look what Conway did: 1 2 3 4 --> 1 +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ | | O | | | O | | O | | | | O | | O | | | | | O | | +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ | | | O | | | O | O | | O | | O | | | O | O | | | | O | +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ | O | O | O | | | O | | | | O | O | | O | O | | | O | O | O | +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ +---+---+---+ ================================================================================ The seven branches below are largely orthogonal: a realized system is a tuple of coordinates across them, not a single leaf in any one tree. #2 collapses to "n/a" whenever #1 is anything other than "pin order." #6 and #7 are bookkeeping primitives used by the higher layers. ================================================================================ THE SEVEN BRANCHES ================================================================================ #1 Coordination strategy Do you try to agree on a global order at all, and if not, what shape does the problem take instead? #2 Order-pinning mechanism When you do try to pin a single global order, how is the order actually decided? (Only meaningful when #1 = pin order.) #3 Failure model assumed What kinds of bad behavior must the protocol survive? #4 Membership and Sybil resistance Who is allowed to participate, and how is open participation rate-limited if it's allowed? #5 Target consistency model What guarantee is the protocol trying to provide to its clients? #6 Causality and time primitives used What bookkeeping does the system use to track happens-before? #7 Failure detection primitives used How does the system decide a peer is dead? ================================================================================ #1 COORDINATION STRATEGY ================================================================================ [#1 coordination strategy] | +-- pin a strict global order | | | +-- (see #2 for how the order gets pinned) | +-- accumulate weight, let the heaviest history win | | | +-- Bitcoin / Nakamoto PoW | +-- GHOST | +-- chain-based PoS (pre-finality) | +-- repeated random sampling, metastable convergence | | | +-- Avalanche family | +-- sampling-based DAG consensus | +-- skip ordering entirely (no global order needed) | +-- single-source authoritative replication | | (one writer is the authority; consumers just want an efficient | | copy) | | | +-- rsync (rolling-checksum block diff) | +-- ZFS send / recv (snapshot block diff) | +-- DNS AXFR / IXFR (full and incremental zone transfer) | +-- MySQL binlog / Postgres streaming replication (log shipping) | +-- distro mirror sync | +-- web origin to CDN pull | +-- RPKI Repository Delta Protocol (RRDP) (full history replicated | as op-based journal in segments) | +-- CRDT family | | | +-- state-based (CvRDT) | +-- op-based (CmRDT) | +-- delta-state | | | +-- counters: G-Counter, PN-Counter | +-- sets: G-Set, 2P-Set, OR-Set, LWW-Set | +-- registers: LWW-Register, MV-Register | +-- maps: OR-Map, LWW-Map | +-- sequences: RGA, LSEQ, Logoot, Treedoc, WOOT, Yjs, Automerge | | | +-- production: Riak, Redis CRDB, AntidoteDB, Akka Distributed Data | +-- signed-object Merkle replication | | (single-authority per resource, append-only; content-addressed | | + Merkle diff) | | | +-- Erik Synchronisation (RPKI) | +-- Certificate Transparency / Trillian | +-- Sigstore Rekor | +-- TUF (signed-manifest hierarchy, not a strict hash tree) | +-- pure content delivery | | (content-addressed; replication is fetch-by-hash; coordination | | semantics reside above the wire protocol) | | | +-- static content distribution (no shared mutable state) | | | | | +-- IPFS | | +-- BitTorrent v2 (BEP-52) | | | +-- shared-history multi-writer DAG (DVCS family) | | (content-addressed DAG with explicit parent pointers as | | causality; merge is first-class, often manual or heuristic) | | | +-- Git (snapshot-based, 3-way merge) | +-- Mercurial (snapshot-based, similar model) | +-- Fossil (self-contained; includes wiki and tickets) | +-- Bazaar | +-- Darcs (patch-theory-based; patches often commute) | +-- Pijul (CRDT-based patches; automatic merge) | +-- anti-entropy / gossip repair | | | +-- Cassandra Merkle repair | +-- Riak read-repair, hinted handoff | +-- SWIM, HyParView, Plumtree | +-- epidemic broadcast trees | +-- operational transformation (OT) | | | +-- Google Docs | +-- ShareJS | +-- Etherpad | +-- CALM / monotonic logic (theory layer) | +-- Bloom language +-- "if your program is monotonic, no coordination is needed." ================================================================================ #2 ORDER-PINNING MECHANISM ================================================================================ [#2 order-pinning mechanism] | +-- sequencer-based | | | +-- token-passing | | | | | +-- Totem | | +-- Chang-Maxemchuk | | +-- Train protocol | | +-- Isis ABCAST (sequencer mode) | | | +-- single designated sequencer | | | +-- Amoeba sequencer | +-- Kafka controller | +-- leader proposes + quorum constrains | | | +-- crash-only | | | | | +-- Paxos / Multi-Paxos | | +-- Raft | | +-- VSR (Viewstamped Replication) | | +-- Zab (ZooKeeper) | | | +-- Byzantine: multi-phase quorum voting | | | | | +-- PBFT | | +-- IBFT | | +-- Tendermint | | | +-- Byzantine: QC-compressed (linear view-change) | | | +-- HotStuff | +-- DiemBFT / LibraBFT | +-- modern PoS BFT finality layers | +-- federated subjective quorum | | | +-- Stellar SCP | +-- Ripple UNL-based consensus | +-- DAG-derived total order | +-- Hashgraph +-- Narwhal-Bullshark +-- Mysticeti +-- Aleph +-- IOTA Coordicide ================================================================================ #3 FAILURE MODEL ASSUMED ================================================================================ [#3 failure model] | +-- crash-stop / crash-recovery | | | +-- Paxos, Raft, VSR, Zab | +-- Totem (in benign mode) | +-- chain replication, CRAQ | +-- omission / partial-sync (theoretical flavor) | | | +-- formal characterization of most BFT protocols | +-- Byzantine | +-- PBFT, IBFT, Tendermint +-- HotStuff, DiemBFT, modern PoS finality +-- Bitcoin (open Byzantine + economic disincentive) +-- Avalanche family +-- Stellar SCP +-- Erik Synchronisation (handled via client-side relay rotation) ================================================================================ #4 MEMBERSHIP AND SYBIL RESISTANCE ================================================================================ [#4 membership / Sybil resistance] | +-- closed permissioned | | | +-- classic Raft, Paxos, etcd, ZooKeeper clusters | +-- consortium PBFT | +-- elected committee | | | +-- DPoS (EOS-style) | +-- witness systems | +-- federated subjective sets | | | +-- Stellar SCP | +-- Ripple UNL | +-- Erik Synchronisation (relay set is federated; trust is per-CA, not | per-relay) | +-- open permissionless | +-- PoW | | | +-- Bitcoin | +-- Litecoin | +-- PoS | | | +-- Ethereum | +-- Cardano | +-- Cosmos public chains | +-- PoA / hybrid | +-- enterprise consortium overlays ================================================================================ #5 TARGET CONSISTENCY MODEL ================================================================================ [#5 target consistency model] | +-- linearizable | | | +-- Spanner | +-- etcd | +-- ZooKeeper | +-- Raft (with linearizable reads) | +-- sequentially consistent | | | +-- most single-leader replicated systems | +-- causal+ (causal + convergent conflict resolution) | | | +-- COPS | +-- Eiger | +-- causal | | | +-- Bayou | +-- Cure | +-- strong eventual (deterministic merge / SEC) | | | +-- CRDTs (any flavor) | +-- Riak DT | +-- Erik Synchronisation (per issuer) | +-- eventual (no merge guarantee) | +-- Dynamo without DVV / CRDT +-- DNS +-- BGP +-- gossip-only systems ================================================================================ #6 CAUSALITY AND TIME PRIMITIVES ================================================================================ [#6 causality / time primitives] | +-- Lamport timestamps | | | +-- logical time only, no detection of concurrency | +-- vector / version vectors | | | +-- Dynamo origin | +-- pre-modern Cassandra | +-- RPKI / Erik Synchronisation (one slot per CA, single-writer-per-slot; | LLW using manifestNumber + thisUpdate) | +-- dotted version vectors (DVV) | | | +-- modern Riak | +-- hybrid logical clocks (HLC) | | | +-- CockroachDB | +-- YugabyteDB | +-- synchronized physical clocks | | | +-- Spanner (TrueTime) | +-- VDF / proof-of-history | +-- Solana ================================================================================ #7 FAILURE DETECTION ================================================================================ [#7 failure detection] | +-- heartbeat / timeout | | | +-- classic Raft / Paxos leader-election timeouts | +-- ZK session timeouts | +-- accrual | | | +-- Phi accrual (Cassandra, Akka) | +-- gossip-based membership | +-- SWIM +-- HyParView +-- Plumtree ================================================================================ HOW REAL SYSTEMS MAP ACROSS THE SEVEN ================================================================================ Raft cluster #1 pin order #2 leader + quorum, crash-only #3 crash-stop #4 closed permissioned #5 linearizable #6 none (term + log index suffice internally) #7 heartbeat / timeout Bitcoin #1 chain weight #2 n/a #3 Byzantine, open #4 open permissionless / PoW #5 eventual (probabilistic finality) #6 none (block height + timestamp) #7 n/a (gossip + reorg) Erik Synchronisation #1 skip ordering (signed-object Merkle replication) #2 n/a #3 Byzantine via relay rotation #4 federated relays, per-CA authority #5 strong eventual (per issuer) #6 version vector indexed by CA (manifestNumber + thisUpdate) #7 n/a (HTTP-level retry, switch relay) Cassandra #1 skip ordering (anti-entropy + LWW or CRDT) #2 n/a #3 crash with quorum-based tolerance #4 closed or elected #5 tunable; typically eventual or strong eventual #6 vector clocks historically; cell timestamps now #7 Phi accrual Spanner #1 pin order #2 leader + quorum (Paxos per shard), crash #3 crash-stop #4 closed #5 linearizable / external consistency #6 TrueTime (synchronized physical clocks) #7 heartbeat Solana #1 pin order with VDF assist #2 leader + quorum (Tower BFT) over PoH stream #3 Byzantine #4 open permissionless / PoS #5 eventual then BFT-finalized #6 VDF / proof-of-history #7 gossip Yjs / Automerge (collaborative editor) #1 skip ordering (CRDT) #2 n/a #3 Byzantine-tolerant only insofar as data is signed #4 open or closed (transport-dependent) #5 strong eventual #6 Lamport-style or vector clocks (per CRDT design) #7 n/a (transport-level) ================================================================================ AUTHORS / ERRORS / OMISSIONS / BLAME ================================================================================ Anton Kapela Job Snijders