Polkadot separates the relay chain’s consensus into two parts:

  1. block production via babe (ouroboros-esque)
  2. finality via grandpa (ghost for trees)

Babe prioritizes availability and partition-tolerance (AP), while Grandpa prioritizes consistency and availability (CA).

This separation between block production and finality isn’t just designed to defy the CAP tradeoff – it’s necessary for the shared security model used in Polkadot.

The gap between block production and finality is intended to hover around ~100 blocks. Kusama has shown that this may be difficult to maintain, but it is a testnet.

Regardless, the 100 block gap exists to allot time for the validity game (section 2.2) played by fishermen.

The burden of proof is on Polkadot to demonstrate that shared security is worth the additional complexity. There are virtues to simple mechanisms like rhododendron which achieve instant finality in a byzantine fault tolerant way, even if they can’t support the shared security model of Polkadot’s multi-chain vision.

If a blockchain can discover its own model to incentivize security, it might consider implementing a sovereign chain with substrate that uses rhododendron for consensus. There’s something to be said about the maintainability of simple algorithms like tendermint

CAP

Daniel Abadi discusses the abuse of CAP to justify oversimplified tradeoffs:

  1. Problems with CAP, and Yahoo’s little known NoSQL system
  2. The dangers of conditional consistency guarantees

Systems that sacrifice consistency like Babe (AP) “tend to do so all the time, not just when there is a network partition” (problems with CAP).

Separating block production from finality means that people won’t treat block production as a probabilistic measure of transaction inclusion. Exchanges and other actors will wait until finality for assurance of transaction inclusion. As soon as this behavior is established, finality is no longer considered a virtue, but instead becomes something that is just expected, taken for granted.

Babe is only useful if users consider the produced blocks to be consistent, but finality will almost immediately become the new condition for recognized consistency. This means that while calling babe “a block production algorithm” is technically correct, babe is just the beginning of the grandpa consensus algorithm which is what really decides transaction ordering and inclusion.

Grandpa is the bottleneck for transaction processing and grandpa’s complexity poses a challenge – among other things, it requires additional syncing, frequent reorgs of the statedb, and confusing authority set changes. Some of these adjectives are subjective because I still get confused when they’re discused. I have a lot to learn, but I also think a lot of this stuff hasn’t been completely “figured out” yet.