How Balloting is done on the Stellar Consensus Protocol utilized by Pi Network

A ballot is made up of the pairs: “counter,value,” where “counter” is an integer with a value that comes from the nomination process, and “value” is a contender. The node may decide to accept its own candidate or the candidate of a peer. In general, balloting involves conducting possibly several federated votes on statements related to ballots in an effort to repeatedly bring the network to consensus on a certain candidate in a particular ballot.

Vote counts keep account of the attempts made, and votes with higher counts are given preference over votes with lower counts. A new vote starts on ballot “counter+1, value” if ballot “counter, value” seems to be becoming stuck.

It is crucial to distinguish between values (such as the appropriate lunch order, such as pizza or salads), ballots (a counter-value pair), and assertions concerning ballots. There are numerous rounds of federated voting on such claims during a SCP round, notably these:

• Both “I commit to ballot B” and “I am ready to commit to ballot B” are acceptable.

A particular node considers itself to have gained consensus when it discovers a ballot B for which it can confirm (find a quorum accepting) the statement “I commit to ballot B.” It is now safe to take action based on the value in B, for example, to make that lunch reservation.

The value is externalized when this occurs. A node can be certain that every other node has externalized the same value or will externalize it eventually if a ballot is confirmed committed.

Although there are actually fewer actual protocol messages sent because each one encompasses a number of ballots, there are logically many more federated votes on assertions about numerous separate ballots. Thus, a single communication advances the status of numerous federated votes all at once, for example:

“I accept that ballots in the range <min,V> to <max,V> are committed.”

So what do “prepared” and “committed” mean?

A node decides to commit to a ballot when it believes that other nodes won’t commit to ballots with differing values. The preparation statement’s goal is to persuade you of this. A vote that states, “I am prepared to commit to ballot B,” means that the voter swears never to commit to a ballot that has a smaller counter than B. ⁶ The prepare vote is said to have “aborted” those inferior ballots, while “preparing” B.

Why does “I am willing to commit to ballot B” indicate that I guarantee never to commit to a ballot lower than B? It’s because “abort” is, according to SCP, the polar opposite of “commit.” A vote to prepare a ballot is implicitly also a vote to abort some other ballots, and as we discussed earlier, voting for something is a promise never to vote against it.

Any time a node wants to “commit” a vote, it must first locate a ballot that it can verify is ready. To put it another way, it uses federated voting on “I am prepared to commit to ballot B” for a number of possible ballots until it finds one that a majority of the group can agree on.

Where do the ballots for the prepared votes originate from? A node’s initial prepare vote is for 1,C>, where C is the composite candidate that was created during the nomination phase. Even if the ballots are prepared, the nomination process may result in extra candidates, so new ballots are created.

Peers may have alternative candidates in the meantime, and they may come together to create a blocking set that accepts “I am willing to commit to ballot B2,” persuading the node to agree. Finally, there is a timeout mechanism that, in the event that the present ballots appear to be stuck, triggers the start of new rounds of federated voting on new ballots with higher numbers.

A node will cast a fresh vote for “I commit to ballot B” once it locates a ballot B that it can verify is ready. This vote informs the node’s peers that it will never abort B. In reality, if ballot N,C> is represented by ballot B, then the vote I commit to ballot N,C>> is also implicitly a vote to prepare every ballot from N,C> through,C>. If other nodes receiving this message are still at previous stages of the protocol, the additional meaning helps them catch up.

At this point, it’s important to reiterate that they are asynchronous protocols. It’s not necessary for all of a node’s peers to send commit votes just because one of them is. Some may be voting on prepared comments even now, while others may have already externalized a value. No matter what phase it’s in, SCP describes how a node should respond to each sort of peer message.

Since the node has now vowed never to abort N,C>, perhaps N+1,C> or N+2,C> can be accepted or affirmed, or in any case, some vote with C in it and no other value. By the time a node is voting on commits, consensus is either C or not. This is insufficient, though, for the node to externalize C just yet. According to our safety hypotheses, a small number of Byzantine peers (less than a quorum) might be lying to the node. The node finally has the confidence to externalize C after accepting and thereafter verifying some ballot (or range of votes).

That’s all, then! The network is prepared to start afresh once it has reached consensus. This occurs roughly every 5 seconds in the Stellar payment network, requiring SCP’s safety and liveness guarantees.

SCP achieves this by utilizing numerous rounds of federated vote. Quorum slices, or groups of peers that each node has chosen to include in its own (subjective) quorum, are what allow for federated voting. Due to this setup, consensus can be reached even in networks with open membership and Byzantine failures.