TheStellar Consensus Protocol 25 from each node without relying on timing to order the messages, since the network mayre-order messages. Afewdetailsoftheprotocolmeritexplanation.Thestatementsimpliedby PREPARE of the form “abort b¨ ∨ accept(abort b¨)” do not specify whether v is voting for or con- firming abort b¨. The distinction is unimportant for the definition of accept. Glossing over the distinction allows v to forget about old ballots it voted to commit (and hence cannot vote to abort), so long as it accepted an abort message for them. Indeed, the only time v modifies c when c ≠ 0 is to set it back to 0 after accepting abort for every ballot it is voting to commit in step 1 on the preceding page. Conversely, the only time v modifies c when c = 0 is to set it to a value c ≥ b in step 3. Because nodes never vote abort c for any c ≥ b, no past abort votes can conflict with commit c. Theorem 11 requires that nodes rebroadcast what they have accepted. It follows from the definition of prepare that the two highest incompatible ballots a node has accepted as prepared subsume all ballots the node has accepted as prepared. Hence, ¨ including p and p in every message ensures that nodes converge on ℎ—a confirmed prepared ballot. Note further that the ballots a node accepts as prepared must be a superset of the ballots the node confirms as prepared; hence, step 2 can never set ℎ such that ℎ ≁ c ≠ 0, as step 1 will set c ← 0 if the new ℎ is incompatible with the old c. ¨ ¨ At the time v sends an EXTERNALIZE message, it has accepted {commit b ∣ b ≳ c}. ¨ ¨ More importantly, however, it has confirmed {commit b ∣ c ≲ b ≲ ℎ}. v can assert its acceptance of confirmed statements without regard to Q(v), because it has already checked that one of its slices unanimously agrees; this explains the appearance of {{v}} in place of D for the second implicit CONFIRM message in the description of EXTERNALIZE. Eliminating D allows a single static EXTERNALIZE message to help other nodes catch up arbitrarily far in the future, even if quorum slices have changed significantly in the meantime. Only one RPC is needed to exchange ballot messages. The argument is the sender’s latest message and the return value is the receiver’s latest message. As with NOMI- NATE, if D or the values x in ballots are cryptographic hashes, then a separate RPC is needed to retrieve uncached hash preimages. 6.2.2. Timeouts and ballot updates. If all intact nodes start with the same ballot b, then steps 1 to 9 on the previous page are sufficient to confirm commit b and externalize value b.x. Unfortunately, if the ballot protocol starts before the nomination protocol hasconverged, nodes may start off with different values for z. If a ballot fails, or takes long enough that it may fail because of unresponsive nodes, then nodes must time out andtryagainwithahigherballot. For this reason, nodes employ a timer as follows: (a) A node v with ' ≠ EXTERNALIZE arms a timer whenever ∃S ⊆ M such that v v the set of senders U = {v ∣ m ∈ S } is a quorum, v ∈ U, and ∀m ∈ S, b .n ≥ b .n. m m v (b) If the timer fires, v updates its ballot by setting b ← ⟨b .n + 1,z ⟩. v v v Different nodes may start ballots at different times. However, condition (a) delays setting a timer at a node v that has gotten ahead of a quorum. Conversely, step 9 on the preceding page allows nodes that have fallen too far behind to catch up without waiting for timers. Taken together, these rules ensure that given long enough timers, intact nodes will spend time together on the same ballot; moreover, this time will grow proportionally to the timer duration. To ensure timeouts are long enough without pre- dicting latencies, an implementation can increase the timeout as a function of b.n. 6.3. Correctness AnSCPnodecannotvotetoconfirmcommitbuntilithasvotedtoconfirmabortforall lower-numberedincompatibleballots.Becauseawell-behavednodecannotaccept(and