Crypto Academy Week 13 - Homework Post for @alphafx

INTRODUCTION

For any system to function, there's a need for a working mechanism or protocol to run that system.

In decentralized systems, there's what is called a consensus algorithm or protocol. This is a clearly stated computer-implementable series of activities agreed upon by all agents in the system as the working principle that keeps the system running.

This post elaborates on one of such consensus protocols known as Stellar Consensus Protocol.

STELLAR CONSENSUS PROTOCOL (SCP)

The stellar consensus protocol is a kind of consensus known as the Federated Byzantine Agreement (FBA). In the FBA kind of consensus, decisions governing the system are made by the individual nodes on the network. The stellar consensus protocol was first mentioned and extensively described in a whitepaper by David Mazieres of the Stellar Development Foundation.

To understand the stellar consensus protocol, let's first look at agreement consensus.

AGREEMENT CONSENSUS

In an agreement consensus, at least, a majority of the nodes have to be satisfied with the outcome of any decision. In that case, the decision-making has to follow a process where each node is willing to wait on a particular decision until a majority is satisfied with that decision.

To explain this further, consider a transaction initiated by a man Ken, who needs to send coins to his friend Max. He collects Max's address which belongs to a blockchain employing agreement consensus and sends him a few coins. On this blockchain, to commit to the authenticity of this transaction, a node will have to wait for a majority of the nodes to confirm the transaction's authenticity and commit to it.

When the majority of the nodes commit to a particular decision on the network, such a decision becomes generally accepted by the network.

Now, back to Ken. In agreement consensus, the system has to be consistent with its results irrespective of whether there are miscommunication errors between the nodes or not. So if Ken's coin balance was agreed to be 10, except it has been agreed that Ken received coins, his coin balance should always be 10. This is called fault tolerance.

BYZANTINE AGREEMENT CONSENSUS

Asides from faults due to communication errors between nodes, there is a kind of fault where a node might willingly want to confirm a false transaction, maybe due to error or for malicious reasons. This type of fault is known as a Byzantine fault.

Agreement consensus that output consistent results irrespective of byzantine faults are said to be byzantine fault-tolerant. They are called the Byzantine agreement consensus.

FEDERATED BYZANTINE AGREEMENT CONSENSUS

Earlier, I mentioned a majority committing to a decision before it is accepted by the network in an agreement consensus.

Well, in decentralized systems where any member node can leave at will and new ones can join whenever, calculating the total number of nodes at any point in time and thus the minimum number required to make up a majority becomes quite tricky.

One way to resolve this is by employing what is called a federated system.

A federated system may not have a complete list of all the nodes on the network to know the total number and the number that makes a majority but it uses a decentralized method to enable an agreement to be reached by a majority of the nodes on the platform. This is possible through an activity called federated voting.

A Byzantine agreement consensus that employs this federated system is known as a federated Byzantine agreement consensus.

Recall that I said,

the stellar consensus protocol (SCP) is a kind of consensus known as the federated Byzantine agreement consensus (FBA).

I just explained what that means. Here's a quick reminder though

• Stellar consensus protocol is a kind of consensus that requires the majority of the nodes on the network to agree on a decision before it is passed on the network. So it is an agreement consensus.

• Agreement consensuses are usually fault-tolerant. When they can tolerate Byzantine faults (willful confirmation of wrong information by a node), they are said to be Byzantine agreement consensus. SCP is one.

• A federated system helps to navigate around the trick of having to determine when it's a majority on a decentralized system. If a Byzantine agreement employs this system, it is a federated Byzantine agreement consensus. SCP is one.

Now, we have understood what that means, let's see how SCP (stellar consensus protocol) works.

HOW STELLAR CONSENSUS PROTOCOL (SCP) WORKS

We've established SCP as a federated Byzantine agreement consensus that uses a decentralized method to bring the nodes to an agreement. This is how SCP works.

On a federated Byzantine agreement network, we already know that decisions are taken by the majority of the nodes.

Now, when this network is in a decentralized system, the set of nodes sufficient enough to make a decision on the network is called a Quorum. Each quorum is made up of smaller sets of nodes which are called Slices. This is true for an FBA.

Given that in a decentralized system, the total number and hence the majority number is difficult to find, each node has to choose a quorum slice and in some cases, slices to counter the effect of node failure.

When a node chooses a slice, it chooses a set of nodes that can convince it to make a decision (ie. a set of nodes it can trust).

<sup>Each node picks quorum slices in an FBA

src</sup>

It helps to consider quorum slices as a set of friends who have a trust relationship with each other. They get convinced when the other friends in the set make decisions.

Let's denote these friends as v₁, v₂, v₃, and v₄. Consider the trust relationship between these friends denoted by arrows in the diagram below.

<sup>Example of quorum slices

src</sup>

From the image above,

• v₁ directly trusts v₂ and v₃. This is one slice.

• v₂ directly trusts v₁, v₃, and v₄. This is another slice

• v₃ directly trusts v₁, v₂, and v₄. This is a third slice.

• v₄ directly trusts v₂, and v₃. This is a fourth slice.

Note that these are all single slices. Each friend has direct trust with only a set of persons not two.

Also, v₁ can't agree except v₂ and v₃ commits to the agreement. However, neither v₂ nor v₃ will commit to an agreement except v₄ is willing. Invariably, there is no quorum without all these nodes. They all make up a quorum.

Usually, nodes can have more than one slice and this is usually the case. This is in order to counter the impact of node failure. Also, nodes are to be well-behaved so as to select good and broad slices to make up good quorums.

A good quorum usually contains a node from another quorum, leading to a quorum intersection. This means that there's something in common between the two quorums and they are not contradictory.

<sup>Overlapping and non-overlapping quorums

src</sup>

If quorums have no nodes in common, it means that quorums are making contradicting decisions. This is usually the case when quorum slices are not broad enough or the nodes are not interested in maintaining a good reputation (ie. don't care much about giving inconsistent information).

This lack of nodes in common in quorums (quorum intersection) can discredit the consensus.

Before I talk about the agreement process, let me briefly summarize the quorums and quorum slices.

• Decisions on a federated Byzantine agreement consensus are made by a set of nodes called a quorum.

• Each quorum consists of a smaller set of nodes called slices. It helps to consider each slice as a 'circle of friends'.

• Each node must select its own slice wisely. I can say, each node must select its own friends, wisely.

• A good slice contains more nodes, and these nodes should be concerned about a good reputation. I can say, each node should have a lot of well-behaved friends.

• Good slices make up good quorums. Good quorums have nodes in common, this is called quorum intersection.

• Quorums intersection makes the decisions made more representative of the majority of the active and safe nodes.

THE AGREEMENT PROCESS

This is all about how these nodes in their slices and in quorums agree and commit to decisions. It involves 4 processes, which are

INITIAL VOTING

Here, each node states its preferences. What their preferred position is and what position they are opened to accepting if other nodes their slices accept.

Example: Vanessa wants hamburgers but she wouldn't mind taking pizza if her friends want it.

ACCEPTANCE

All the statements are collected and arranged according to preferences. The most common preference is accepted.

Example: Vanessa finds out all her friends want or are open to pizza. Since though she didn't insist on pizza but was open to it, she automatically agrees, same with other friends open to pizza.

RATIFICATION

Every node in all the slices making up the quorum accepts the most common preference and it is adopted by the quorum as its preference.

Example: Vanessa and all her friends accept pizza as their general order. That's a whole lot of pizza btw.

CONFIRMATION

Confirmation messages are sent from each node throughout the system about the accepted preference. This can also cause more nodes not in the quorum to adopt the preference.

Example: Vanessa and her friends inform the rest of the class of their pizza choice. Some people in the class are even interested and request pizza too.

^src

STELLAR CONSENSUS PROTOCOL's CONTINGENCY PLAN

Now, all things are not always equal, right? On decentralized systems too. There could be cases where some nodes are not responding (blockage) or some are just against pizza and would prefer not having lunch (divergence) while the rest of the class does.

The stellar consensus protocol has a contingency plan that minimizes this blockage or divergence in the agreement process. It uses a ballot system for its agreement process.

Preferences are not just made arbitrarily, the options are instead voted/agreed on before preferences on the agreed options are made. So, if agreeing on a particular preference becomes an issue, the nodes can agree to void that preference and carry.

If more preferences are problematic and consequently voided, the last preference standing gets accepted.

Note that when there are good quorums, blockages are not possible for nodes that are committed to their slices. This is because they will always find a way of reaching an agreement.

Also, if a node is committed to a slice or slices consisting of bad nodes (unresponsive, inconsistent, or fraudulent nodes) the other nodes in the system label them befouled nodes and go ahead to ratify decisions if these nodes are blocking or inconsistent.

In addition to the ballot protocol, stellar consensus protocol has another sub-protocol known as nomination protocol. For more on these, please consult SCP's whitepaper

ADVANTAGES OF STELLAR CONSENSUS PROTOCOL

LOW LATENCY:

This is all about the speed of reaching an agreement. It's as fast as reputable transaction speeds in today's top payments system. Consensus is reached in a matter of seconds.

DECENTRALIZED CONTROL:

The nodes are in control in this consensus, all of them. No one approves and no one disapproves of anyone. The system allows bypassing of befouled nodes for the purpose of reaching a consensus.

FLEXIBLE TRUST:

Nodes get to select their quorum slices or committee of friends if you like. In the slices, decisions have to be reached unanimously and where nodes are keen on reputation, they keep each other honest.

ASYMPTOTIC SECURITY:

Each statement of preference by nodes is digitally signed with public and private keys which are set to frustrate malicious users with high computing power. Each statement is untampered.

STELLAR CONSENSUS PROTOCOL Vs PROOF OF WORK

Stellar consensus protocol compares favorably against other payment-facilitating consensuses like Proof of Work. Here is how stellar consensus protocol compares with Proof of Work.

Stellar Consensus Protocol	Proof of Work
Requires minimal budget for participation	Require a very high budget for participation
Requires relatively low computing power	Requires high computing power.
Consists of nodes working together	Consists of nodes competing against each other
Mining is not obtainable	Mining is obtainable
Low latency, up to 1,000 transactions per second	High latency. Bitcoin has about 4.6 tps, while Ethereum does 20 tps
Flexible trust amongst nodes	competition amongst miner nodes

STELLAR CONSENSUS PROTOCOL Vs PROOF OF STAKE

Proof of Stake seems like an upgrade on Proof of Work, especially as regards the amount of energy consumed. Here is how Proof of Stake compares with Stellar Consensus Protocol.

Stellar Consensus Protocol	Proof of Stake
Mining not obtainable	Mining obtainable
Asymptotic security	Security breach if a node has 51% of coins
Low latency	No guarantee of low latency
Agreement system is used in this consensus	Activities are carried out in this consensus

USE CASE OF THE STELLAR CONSENSUS PROTOCOL

The stellar consensus protocol is used by Stellar, a payment technology just like Ripple. One major difference between Stellar and Ripple is that, while Ripple is a closed system, Stellar is open source. Both share striking similarities, however, including the fact that Stellar's founder, Jed McCaleb, co-founded Ripple.

Stellar is mainly used for money remittances and for facilitating access to bank loans. Being a payment technology, Stellar differs from Bitcoin in its consensus protocol. With its coin - Lumens, Stellar conducts cross-border money remittances.

Lumens has stories of its own. The coin grew by a whopping 34,900% in 2017 before falling 77% in 2018. In 2021, it has appreciated by 226% and is currently a crypto asset to have one's eyes on.

Lumen is not a mining-based cryptocurrency. It currently has about 22.5 billion units in circulation with a maximum supply of 50 billion. All of this was created at the beginning of the project by the stellar development foundation.

Thanks to the stellar consensus protocol, Stellar boasts fast transaction speeds, with up to 1,000 transactions per second. The protocol's cost-effectiveness also small budget organizations to participate in the network making the Stellar project quite attractive.

CONCLUSION

Stellar consensus protocol is a kind of FBA (federated Byzantine agreement) consensus. It is a Byzantine fault-tolerant consensus (BFT) and can reach consensus via agreement and in a decentralized manner. Its ballot system allows the consensus to be reached irrespective of blockages and inconsistency.

Consensus in the stellar consensus protocol is reached by an agreement by the majority of the nodes. Also, the protocol's decentralized control and flexible trust differentiate it from most other consensus algorithms.

Thanks for reading.

Cc:
@alphafx