01.The Problem Statement
Consensus is the act of getting a group of unreliable processes to agree on a single value despite crashes, network partitions, and arbitrary message delays. The FLP impossibility result tells us we cannot guarantee termination in a fully asynchronous network, so every practical protocol trades one property to recover another.
Most production systems target the partially synchronous model: messages may be delayed arbitrarily, but eventually the network behaves. Under that assumption, both safety and liveness become achievable with a quorum-based approach.
02.Paxos, Raft, and the Leader Lineage
Paxos established the template: a proposer collects promises from a majority of acceptors, then broadcasts the chosen value. Raft repackaged the same correctness argument with a clearer state machine and explicit leader election, which is why most modern systems choose Raft when they need a replicated log.
// simplified Raft AppendEntries
type AppendEntries struct {
Term uint64
LeaderID string
PrevLogIndex uint64
PrevLogTerm uint64
Entries []LogEntry
CommitIndex uint64
}
func (n *Node) Handle(msg AppendEntries) Reply {
if msg.Term < n.currentTerm { return Reject(n.currentTerm) }
n.resetElectionTimer()
return n.appendIfConsistent(msg)
}03.Byzantine and Leaderless Variants
PBFT, Tendermint, and HotStuff extend the quorum model to tolerate malicious nodes by requiring a two-thirds supermajority and signed messages at every step. Leaderless protocols such as EPaxos and Generalized Paxos remove the throughput bottleneck of a single coordinator at the cost of more complex conflict detection.
For Meridian we default to Raft per shard and reserve HotStuff-style commits for the cross-region settlement path where Byzantine assumptions matter.