CAP Theorem in Blockchains

Blockchains are distributed systems, so the CAP theorem applies. But the tradeoffs look a bit different than in traditional databases.

Quick recap: CAP says during a network partition, you choose consistency (all nodes agree) or availability (nodes keep responding). Partition tolerance isn’t optional - networks fail.

Most blockchains lean AP - they prioritize availability and partition tolerance. Nodes keep accepting transactions even during network splits. Consistency is eventual: forks happen, and the longest chain wins. This is why Bitcoin transactions need multiple confirmations - you’re waiting for consistency to catch up.

The consensus mechanism determines the specifics:

Proof of Work (Bitcoin, etc.): Very partition tolerant. Nodes can work independently and the chain reconciles later. But “consistency” is probabilistic - a transaction is only final after enough blocks that a reorg is unlikely.

BFT-style consensus (Tendermint, etc.): Trades some availability for stronger consistency. Blocks are final once committed - no reorganizations. But the network can halt if too many validators are partitioned.

Proof of Stake variants: Somewhere in between, depending on the specific design. Some prioritize liveness (keep producing blocks), others prioritize safety (don’t finalize conflicting blocks).

The interesting thing is that blockchains can’t just pick CP or AP cleanly - they need to work across trust boundaries where nodes might be malicious, not just partitioned. So they add Byzantine fault tolerance on top of the CAP tradeoffs, which makes the design space more complex.