One chosen value: competing proposers

Exact consensus evidence

Choose one value despite competing proposers

This lab runs a single-decision Paxos fixture with proposers P and Q and three acceptors. P uses ballot one and Q uses ballot two. A ballot number identifies a proposal attempt, not the value being decided. Each acceptor remembers its highest promise and its last accepted ballot/value pair. A proposer first requests promises, then issues an accept request after receiving two promises. When any promise reports an earlier accepted value, the proposer uses the value from the highest reported accepted ballot instead of blindly insisting on its original preference.

Control the competing schedule

Desired value P and Desired value Q choose integers from zero through ninety-nine. Start competing proposer enables Q; Q starts at tick sets its start from zero through twelve, while P always starts at zero. One-way message delay controls every scheduled delivery. Down acceptor removes one acceptor for the entire experiment or leaves all available. Split reachability lets P contact A and B and Q contact B and C; the overlap is B. Reverse same-tick delivery reverses message order within each delivery group, exposing sensitivity to scheduling without changing the safety rule. Every edit rebuilds and pauses the trace.

Watch a proposer adopt an earlier value

Keep defaults: P wants seven, Q wants nine, Q starts at tick eight and messages take one tick. P obtains promises, has seven accepted by a majority, and receives the acknowledgements. Q later learns about that accepted value through its promise responses. It issues ballot two with seven, despite initially wanting nine. Both learned certificates therefore contain seven. Inspect Q while its phase changes from preparing to accepting and compare desired value with issued value. A proposal number can increase while the chosen application value remains unchanged.

Change order and availability

Set Q start to zero. Its higher ballot can preempt P before P completes, and the default simultaneous-start fixture learns nine instead. This is not a claim that the largest initial desired value wins: values do not participate in ballot ordering. Turn off Q and take acceptor C down; P still has a majority of two. Enable split reachability and take B down: each proposer can contact only one acceptor, so neither learns a decision. The unfinished outcome is honest lack of progress, not a random fallback winner. This fixture makes one attempt per proposer and does not add retries or an eventual leader.

Distinguish accepted from learned

One acceptor recording a value is not yet a chosen decision. A value becomes chosen when a matching ballot/value has been accepted by a majority; the proposer learns this only after the corresponding acknowledgements arrive. The displayed learned certificates list actual acknowledged acceptors. A delay between acceptance and learning does not undo acceptance. Promises are monotonic, and an acceptor rejects an older ballot after promising a newer one. Read the delivered-message list and pending-message evidence together rather than assuming every sent request succeeded.

Inspect the trace and its boundaries

Play maps forty logical ticks to sixty inspection seconds. Pause holds the state; Next tick advances one; Restart rewinds; Speed changes viewing pace; Inspect time scrubs; Show final result reveals the horizon. Restore defaults resets inputs. Proposer panels show desired and issued values, promise responders and acknowledgement sets; acceptor panels show persistent protocol state. The model assumes fixed membership, unique ballot numbers, non-Byzantine messages and retained acceptor state. It does not implement a replicated log, Multi-Paxos leadership, client deduplication, crash recovery, storage writes or a live Java ADK integration. No proposer automatically retries, so safety does not imply eventual completion under every schedule.

Protocol reference: Leslie Lamport, Paxos Made Simple.