Polkadot Consensus
Polkadot is a network with a relay chain which negotiates the passing of messages between many other parachains. It unites them all under a single consensus process; it also unites the hidden state of their message queues under this consensus process. You can build parachains by utilizing Substrate modules to implement a specific interface (in this way, a parachain is really just a WASM blob that implements a specific interface for message passing and block processing).
Polkadot separates the relay chain’s consensus into two parts:
- block production via BABE (Ouroboros-esque)
- 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 stay around ~100 blocks. The gap exists to allot time for the validity game (section 2.2) played by fishermen.
CAP Review
Daniel Abadi discusses the abuse of CAP to justify oversimplified tradeoffs:
- Problems with CAP, and Yahoo’s little known NoSQL system
- The dangers of conditional consistency guarantees
Systems that sacrifice consistency like BABE “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. Finality is the new condition for recognized consistency.