Every blockchain is a distributed database. And distributed databases, regardless of how they're designed, face a fundamental constraint that was formally described in the early 2000s: the CAP theorem. It's one of the cleaner frameworks for understanding why Bitcoin, Cosmos, and Ethereum make the architectural choices they do — and why those choices have real consequences.
The theorem states that a distributed system can only guarantee two of three properties at the same time:
Consistency: Every node in the network returns the same data. If you read from any node after a write, you get the most recent value — not a stale version, not an error, the latest state.
Availability: The system responds to every request. Some nodes can be down. The network can be struggling. But you'll get a response.
Partition Tolerance: The system keeps operating even when the network splits — when some nodes can't communicate with others. Messages get dropped. Nodes get isolated. The system continues.
The hard part: network partitions aren't theoretical. They happen. Cables fail, nodes go offline, routing glitches split groups of validators from each other. Because partition tolerance is effectively mandatory for any real distributed system, the practical choice collapses to a binary: when a partition occurs, do you prioritize Consistency or Availability?
That choice is what separates Bitcoin from Tendermint.
Bitcoin Chooses Availability
Bitcoin nodes will keep building blocks even during a network partition. If a segment of miners gets isolated from the rest of the network, that segment doesn't halt — it continues extending its local chain. Meanwhile, the other segment does the same. For the duration of the partition, two valid competing chains exist simultaneously.
That's a consistency violation. The network contains two different versions of truth at the same time.
When the partition heals, the longest chain rule (accumulated proof of work) resolves it: whichever branch has more work wins, the other gets discarded, and the losing branch's transactions return to the mempool. Order is restored, but not instantly, and not without the possibility that some transactions confirmed on the losing branch need re-processing.
This is what "probabilistic finality" looks like under the CAP lens. Bitcoin trades consistency for availability. The system stays live. Consistency emerges eventually, through reconciliation, not through a refusal to accept inconsistent state.
BFT Chains Choose Consistency
Cosmos (using Tendermint consensus) makes the opposite call. Before a block can be added to the chain, two-thirds of validators by stake must vote for it — in two rounds. If that quorum can't be reached because a partition has isolated a segment of validators, the chain doesn't produce blocks. It halts.
That halt is not a failure mode. It's the design. The chain would rather produce nothing than produce an inconsistent state that different validators disagree on.
In practice, Tendermint chains have paused block production during periods of validator connectivity issues. The chain comes back once quorum is restored. Users waiting for transactions during that window get no response — not a wrong response. That's the Consistency/Availability trade-off in action.
Ethereum Sits Between Both
Ethereum's post-Merge consensus is architecturally interesting here because it runs two mechanisms in parallel. LMD-GHOST handles fork choice on a slot-by-slot basis — it's probabilistic, stays live through connectivity issues, and leans toward Availability. Casper FFG adds BFT-derived checkpoint finality every two epochs (roughly every 12.8 minutes) — deterministic, and once a checkpoint finalizes, it can't be reversed without a large fraction of staked ETH being slashed.
The result is that Ethereum has different CAP properties depending on the time window. At the level of individual slots — seconds to minutes — it behaves closer to Bitcoin: available, probabilistically consistent, tolerant of forks. At the level of finalized checkpoints, it behaves closer to Tendermint: the protocol would sooner halt than allow two conflicting finalized epochs to coexist.
This isn't a perfect solution to the CAP trade-off. It's a hybrid that accepts both modes in different time windows.
A Clarification Worth Making
The "Consistency" in CAP refers to a specific technical property called linearizability — every operation appears to happen atomically, and every read returns the most recent write. This is different from the "Consistency" in ACID database transactions, which is about integrity rules and valid state transitions.
The distinction matters when people compare blockchains to traditional databases. A blockchain can maintain internal ACID-style consistency (no invalid state transitions, all rules enforced) while still being CAP-inconsistent in the linearizability sense (two nodes temporarily disagree about the current canonical chain). Conflating the two leads to confused arguments about whether blockchains are "consistent."
What's Changing
The CAP theorem itself won't change — it's proven mathematics. What changes is how blockchain designs navigate the constraints.
Ethereum's Single Slot Finality research aims to bring deterministic finality down from ~12.8 minutes to a single 12-second slot. If achieved, Ethereum's "AP window" collapses dramatically — the period during which the chain behaves probabilistically would shrink to near-zero. Whether this introduces new liveness risks at the validator coordination layer is one of the open engineering problems SSF is working through.
Worth knowing: Daniel Abadi's PACELC theorem (2012) extends the CAP framing. CAP only describes the trade-off during partitions. PACELC adds that even during normal operation, there's a trade-off between Latency and Consistency. Higher validator counts increase communication overhead; faster finality increases synchronization requirements. The two frameworks together give a more complete picture than CAP alone.
Confirmation and Invalidation
Confirmation: SSF achieving sub-slot finality without introducing new halt risk would suggest Ethereum can shift further toward CP territory while maintaining liveness. BFT chains sustaining long-term uptime with no partition-driven halts would validate the CP approach in practice.
Invalidation: a BFT chain maintaining liveness through a genuine partition while producing consistent state would challenge the theorem's predictions — highly unlikely absent an error in the underlying proof. A PoW chain achieving genuine linearizable consistency without finality mechanisms would require a different construction than currently exists.
Timing and Scope
Now: the trade-offs are live. Bitcoin is AP. Tendermint chains are CP. Ethereum is hybrid, with different CAP properties in different time windows. Later: SSF research may shift Ethereum's practical position on the spectrum.
This post covers the CAP theorem as a framework for understanding blockchain architecture decisions. It doesn't address the full PACELC extension, Cosmos validator set liveness data, or Ethereum's SSF specification in detail.
