Consensus lets distributed participants agree on an ordered system state even when messages are delayed, dropped, modified, or participants fail. It is useful when eventual consistency is not enough: replicas must agree on leadership and on which database changes become committed. section 12.1.1
A consensus protocol addresses several practical decisions:
- Leader election chooses which replica takes over after a failure. section 12.1.1
- Pending changes become committed only after enough participants agree, making committed updates difficult to lose. section 12.1.1
- Byzantine fault-tolerant protocols aim to prevent contradictory histories, or forks, when participants may misbehave. section 12.1.2
- Protocol families make different participation tradeoffs: BFT uses a known participant set, while Nakamoto consensus uses proof of work for permissionless participation. section 12.5
Ordering a pizza across unreliable networks
If everyone is in one room, the majority preference is easy to identify. Across a network, delayed, dropped, intercepted, or modified messages make agreement harder; consensus supplies the additional protocol needed to choose one shared decision. The same pattern applies to replicas agreeing on a database update. section 12.1.1
Paxos, published in 1989, and Raft, published in 2013, are well-known consensus algorithms. In cryptocurrency systems, BFT protocols avoid proof-of-work’s heavy electricity overhead, while Bitcoin uses proof of work to select the next transaction block. section 12.1.1 section 12.3.5
