Stellar Consensus Protocol (SCP) is the consensus protocol implemented in the Stellar Network. It utilizes blockchain to make financial services accessible worldwide. Consensus is the agreement achieved by validators on a certain data in a network. In the cryptocurrency space, these validators are the nodes or a computer where the cryptocurrency software is running. In a group of validators, there are often misbehaving or untrusted nodes. A protocol must be put in place to reach a consensus that the data in a ledger are valid despite the presence of misbehaving nodes. There are various consensus protocols that are already in use in blockchains such as Proof of Work, which is currently utilized by Bitcoin and Ethereum. While Proof of Work uses a central authority to reach a consensus, Stellar Consensus Protocol is designed for decentralized networks. That means, a consensus can be reached even in the absence of a central authority.
Federated Byzantine Agreement
Distributed computing networks are far from perfect. Errors like slow or disrupted communication links, misbehaving nodes (such as those that give false information and nodes that do not respond), exist. To keep the network intact, a network must be fault tolerant. The Byzantine Agreement is a system in a distributed network where a consensus is reached despite the errors and the presence of corrupted nodes. The Byzantine Agreement implements Byzantine Fault Tolerance in a closed system where no restrictions are set on the behavior of the nodes, yet the network is kept secured and a consensus is reached on the data that is true.
A Federated Byzantine Agreement (FBA) is an adaptation of a Byzantine Agreement in an open membership system where members or nodes can join and leave without the permission of any central authority. The SCP is the first implementation of FBA which was idealized in 2015 by Professor David Mazières.
Quorum Slices, Quorums and Quorum Intersections
Quorums and quorum slices are at the core of SCP. Consensus is essentially built on trust among the members of the quorums. As described in the SCP whitepaper, a quorum is a set of nodes sufficient to reach an agreement while a quorum slice is a set of nodes sufficient to convince another node of a statement’s validity. Since SCP does not impose restrictions on a node’s behavior, the nodes are free to choose which nodes to trust. If Node A chooses to trust Nodes B and C, they will form a quorum slice. If B and C accept a certain value, then A will also accept the same value to come up with a consensus within that quorum slice. Similarly, nodes B and C can choose which nodes to trust and form their respective quorum slices. These quorum slices will collectively form a quorum. Let’s call this quorum, Quorum 1.
Suppose node A chooses to also trust nodes G and H, and G and H will branch out to quorum slices with other nodes they trust. They will then form another quorum, which we will call Quorum 2. Node A is now shared between Quorum 1 and Quorum 2 and is referred to as the quorum intersection in SCP. Node A, or the quorum intersection, will therefore affect the internal agreement of Quorums 1 and 2. Quorum intersections are an essential structure in SCP or in any other consensus protocol because without these intersections, it would be impossible to come up with a unified agreement in a distributed network.
SCP utilizes the Federated Voting method for the quorums to reach a consensus by disregarding a fraction of the nodes, usually the ill-behaved ones, and push the majority forward to agreeing to a value that is true. Federated Voting consists of three phases:
Voting. In the voting phase, a node votes for a statement that it believes is true and it will not vote for any other contradicting statements. However, the application layer above the federated voting, which in this case is the SCP, defines what ‘contradicting’ statements. This leaves the possibility open for the node to vote for another non-contradictory statement. As an example, if node A votes for statement X, it is not allowed to vote for statement not-X. But it can still vote for any other statements so long as it is not against the definition of ‘contradictory statements’ defined in the application layer of the SCP. Therefore, node A can also vote for the non-contradictory statement Y. Statement X and Y will be considered as two separate votes in the SCP network.
Acceptance. Once the nodes have voted for a specific statement, it’s time for them to choose which statement to accept. The nodes will listen to the statement accepted by its peers or the nodes they trust. If the nodes in Node A’s slice accepted statement Y as true, Node A will also accept statement Y even if it initially voted for statement X.
Confirmation. In the confirmation stage, the nodes confirm the statement network wide. The node looks at the statement accepted by a quorum of nodes. If a node has accepted a statement and sees that the statement is also accepted by the quorum, the node then confirms or externalizes this statement to the network. Federated voting will eventually assert the network to confirm the same statement.
Nomination and Balloting
In SCP, the statements to be voted for undergo two sub-protocols—nomination and balloting. Federated voting is the underlying mechanism of these two sub-protocols.
The goal of the nomination phase is to confirm the nomination of some value or candidate. Ill-behaved nodes are expected to divert from the value that is true and well-behaved nodes intend to abort or remove the candidates nominated by the ill-behaved nodes. In the nomination phase, federated voting takes place numerous times until the number of candidates have been reduced to what the quorums believed to be valid.
The final stage before the consensus reaches an agreement is the balloting phase. The candidates from the nomination phase will again undergo numerous federated voting processes. In this stage, nodes can either commit or abort a ballot. The candidates are paired with a counter which tracks the number of attempts the candidate has been voted for by the nodes for the network to reach a consensus. Ballots with higher counters take precedence over those with lower counters. If a ballot gets stuck, this ballot is aborted, and a new vote begins on another candidate with a higher counter. The process of aborting or removing invalid candidates continue, further reducing the number of candidates. Conversely, nodes continue to commit to valid candidates until a consensus is achieved.
It is important for any consensus system to maintain safety and liveness in a network. Safety is achieved when nodes externalize a value that does not contradict with the values externalized by the other nodes while liveness is exhibited when nodes do not get stuck as they go through the path of reaching a consensus. SCP’s implementation of federated voting guarantees safety and liveness in a network. The SCP white paper describes its four key features:
Decentralized. Validators or nodes are free to join and leave the network as they please without the need for a permission from a central authority.
Flexible Trust. No restrictions are imposed on the nodes on which nodes to trust.
Low Latency. Consensus is reached in a matter of seconds, faster than most, if not all, consensus protocols.
Asymptotic Security – network protection is guaranteed even against high computing power.
The SCP is the first implementation of FBA and is also the first probably safe consensus protocol for decentralized networks. What was discussed in this article is a broader view of the SCP and its principles. For a more detailed explanation of SCP, you can check this link.