Consensus: keep agreement separate from progress

For one consensus instance, agreement means that two decisions cannot select different values. Validity constrains decisions to acceptable proposed values under the chosen specification; a server cannot invent an unrelated command. A replicated state machine extends the idea to indexed log positions, then applies the agreed commands in order. Two replicas can have different uncommitted suffixes temporarily. That is different from applying different committed commands at the same position, which violates the state-machine safety contract.

The fault model matters to every sentence in that contract. A crash-stop node stops taking steps; a crash-recovery node can return with specified durable information intact. Network messages may be delayed, duplicated, reordered, or lost, while the protocol authenticates identities and assumes participants follow its rules. Arbitrary forged votes, disk corruption presented as valid state, and malicious equivocation are outside ordinary crash-fault Paxos or Raft. Increasing a majority count does not silently convert these algorithms into Byzantine-fault-tolerant protocols.

A safe protocol can stop making progress when too many replicas cannot communicate. In a fully asynchronous system, a long delay cannot be distinguished reliably from a stopped participant. Deterministic consensus cannot guarantee termination in every admissible asynchronous execution with a possible crash. Practical protocols therefore describe eventual communication and scheduling assumptions, stable leadership, randomized choices, or timing conditions for progress. A timeout is evidence for trying a new election, not proof that the old machine no longer executes.

With a fixed group and ordinary majority voting, tolerating f unavailable replicas while retaining a majority requires at least 2f+1 replicas. The surviving replicas must also be able to exchange and durably process the necessary messages. A count of powered-on machines is insufficient if the network splits them into mutually unreachable groups or their storage stops completing writes. Safety should survive arbitrarily slow messages within the fault model; an availability target additionally depends on the deployment's latency, repair, and failure behavior.

Define exactly what an acknowledgement promises. A response that only means the leader buffered a proposal is weaker than confirmation that a command was committed and applied with its result recorded. If a client times out, the command might have committed before the response was lost. Retrying without a stable request identity can execute an application action twice even when the log itself is perfectly agreed. The client protocol therefore needs deduplication or another explicit retry contract, not a slogan about consensus making everything exactly once.

Use the reliability lab to check the limited arithmetic. Choose Reset, explicitly set both replica count to five and unavailable count to two, predict the majority result, then Play or Step. For a separate comparison choose Reset again and explicitly set five and three. The first has three available replicas and the second two. The diagram does not know which replicas communicate, which entries they retain, or whether votes obey the protocol. A displayed majority is a necessary count for this design's progress, not a certificate that a decision is safe.