Thank you so much prof @alphafx for another intriguing class. Hello everyone, welcome to my homework post on consensus protocols.

source

INTRODUCTION

Before going into the consensus protocol I would like to talk about, I would first of all, define consensus protocol.
Ethymologically, consensus comes from the word to agree. So simply put, a consensus can be said to be an agreement, It can also be referred to a decision made after a unanimous agreement among two or more people, while algorithm according to wikipedia can be defined as a process or set of rules to be followed in calculations or other problem-solving operations, especially by a computer.

CONSENSUS ALGORITHM

A consensus algorithm can be seen as a group of strategies that computers use in order to agree among themselves on what is authentic, in this case it applies to the blockchain.
The purpose is usually to bring the blockchain network to agreement on the state of the network.
Meaning that it helps answer these questions

1. Is the blockchain authentic/valid?
2. Which block is to be added next?
3. Who has the right to add another block and when does he add it?

All the above are important because in Blockchain there is a network of peers who you don't necessarily know or trust, therefore the need for a mathematical way to set up the system in order to all come to agreement and work together.
There are many types of Consensus Algorithms and they would be listed below:

• Proof of work
• Proof of stake
• Delegated proof of stake
• Proof of importance
• Proof of authority
• Proof of capacity
• Proof of burn
• Proof of activity
• Proof of existence
• Proof of weight
• Stellar consensus protocol
• Proof of elapsed time
• Proof of contribution
To mention but a few.
However, for the purpose of this post I would like to elaborate on the Stellar Consensus Protocol (SCP).

WHAT IS THE STELLAR CONSENSUS PROTOCOL?

The stellar consensus protocol (SCP), is the fundamental consensus algorithm/protocol of the stellar network. It works as a provably safe creation of Federated Byzantine Agreement. It also functions by allowing a Byzantine fault tolerance across its network, just like other crypto currencies with some clear-cut dissimilarities.

TECHNICAL WORDS EXPLAINED

BYZANTINE AGREEMENTS:

Byzantine agreements is the distribution of computing systems that allows them to come to an agreement, notwithstanding the inconsistent behaviour from some parts of the nodes in the network. It makes no assumptions on the behavior of nodes in the system.

PRACTICAL BYZANTINE FAULT TOLERANCE (pBFT):

This is the algorithm for Byzantine agreements and it reaches a consensus fast and efficiently while silmutaneously detaching consensus from resources usually financial stake in prove of stake and electricity in prove of work.
One of its major downsides is that it does not scale well and needs a large communication operating cost between all the participant nodes. Its a centaralized and closed membership system.
Furthermore, the system requires unanimous consensus of on the membership of the network in order to drastically reduce Sybil attacks.

FEDERATED BYZANTINE CONSENSUS:

This was introduced by the Stellar Consensus Protocol white paper and it to a large extent takes care of the Limitations of the Byzantine Agreement. This is done by fostering a consensus protocol which has the following features:

1. Decentralized control
2. Low latency
3. Flexible trust
4. Asymptomatic Security

The most visible consequence on the Federated byzantine agreement in comaparism to the Byzantine Agreement is that the initial is open to nodes joining in a permission-less order rather than via a closed permissioned membership list.

FBA comes to agreement on state updates using a unique slot where update dependencies between nodes are inferred. Nodes must agree on the slot update in each round of consensus. However, since the system is open to nodes joining and leaving the network at will, a majority-based quorum consensus mechanism will not work. Instead, the FBA in the SCP employs quorum slices that are subsets of quorums that are capable of convincing particular nodes of an agreement.
source

DIFFERENCES BETWEEN BYZANTINE AGREEMENT (BA) AND FEDERAL BYZANTINE AGREEMENT(FBA)

BYZANTINE AGREEMENT (BA)	FEDERAL BYZANTINE AGREEMENT (FBA)
Each node does not use its own quorum slice	Each node uses its individual quorum slices
Centralized Control	Open membership/decentralized control
Nodes do not make use of Quorum slices	Nodes make use of multiple quorum slices
Nodes cannot be programmed to trust external sources	Nodes can be programmed to trust quorum slices or external sources depending on their performance over a period of time

Quorum and Quorum Slices Explained

QUORUM:

A quorum can be seen as a collection of nodes, required to arrive at a consensus in a distributed system.
When the nodes want to reach a consensus, the nodes communicate with each other and agree that an update on the state of the nodes is valid when a required amount of nodes in agreement is achieved.

QUORUM SLICES:

On the other hand quorum slices are a sub collection of a quorum that have the ability of convincing certain nodes of the consensus, implying that a node can depend on a multiple collection of nodes asserting statements.

Having understood the above, it must be noted that the BA requires that all its nodes accept the same slices, rather than looking for sources of trusted information for themselves. On the other hand, the FBA depends on individual nodes in order to choose their own set of quorum slices, which in turn allows for an organic and more decentralized forming of quorums which depend on individual decisions, therefore the name Federated.

SAFETY AND LIVENESS IN THE FBA

Before discussing safety and liveliness in the FBA protocol, there is a need to understand the following:

1. QUORUM INTERSECTION

Quorums can be said to intersect, when they share a node. Good quorums usually share nodes which in turn forms overlapping quorums.
The nodes are responsible for making sure that their selection of quorum slices do not violate quorum intersection and demands that nodes select slices that are conventional and lead to large quorums.

2. Disjoint QUORUMS

Quorums can be said to be disjoint quorums, when they do not intersect. These quorums are usually known as bad quorums that can lead to contradictory statements which can undermine the consensus.

For a proper slice selection to be ensured, nodes require the balancing of safety and liveness.
Nodes can be said to lack safety, when the externalize values that contradict other nodes.
On the other hand, Liveness is said to be lacked when nodes are blocked on the way to a consensus.

Federated voting model plays a major position in the nodes coming to agreement on a statement.

FEDERATED VOTING
This is the method by which the Stellar Consensus Protocol come to a consensus on statements made by the participants.
Generally, there are two sets of messages that are exchanged between nodes, and the two message rounds are subdivided into agreement state of unknown, accepted and confirmed.

Prominently, the voting in a federated environment needs to accommodate open membership, that makes the process more complicated than a closed system.
It usually comprise of 4 phases which are:

1. Initial Voting
2. Acceptance
3. Ratification
4. Confirmation.

The voting process is complex, but Stellar provides certain good resources on how to map it out in a more effective way. They provide a "Galactic Consensus" graphic for a more wider overview and also a useful blog post.

Having carefully explained the above technical terminologies we are now fully set to understand the Stellar Consensus Protocol.

STELLAR CONSENSUS PROTOCOL (SCP):

The Stellar Consensus Protocol is the implementation of the earlier explained FBA which has been designed in order to drastically reduce the occurrences of blocked agreements and also neutralizing them using a ballot system.
The Stellar Consensus Protocol is majorly made up of two basic sub-protocols, namely:

1. The nomination protocol: It produces candidate values for each consensus slot. Finally, all nodes can specifically generate a convergence value for all slots. But the time at which the convergence occurs cannot be known so malicious nodes may have the ability to reset the nomination process .

2. The Ballot Protocol: This is executed the moment nodes agree that the nomination protocol has converged.
   In this system, a ballot is attached to the candidate value, and the node must commit or abort the value attached to that ballot. Nodes can abort certain votes and move on to another in order to avoid agreement blocking. On the contrary, nodes can vote in order to commit a ballot, that externalizes the value attached with the ballot to the consensus slot.

STRENGTH AND LIMITATIONS OF THE STELLAR CONSENSUS PROTOCOL:

STRENGTH	LIMITATIONS
• Given quorum intersection, there are usually no blocked state in the Stellar Consensus Protocol.	Safety can only be guaranteed if nodes choose adequate quorum slices
• Bad nodes can be bypassed through a dispensible set mechanism where good nodes can approve statements without the co-operation of befouled/bad nodes.	Issues in the security of federated system such as widely trusted nodes taking advantage of their positions for unethical executions is possible.
• The consensus cannot be undermined by befouled nodes
• Specific scenarios such as split votes can be handled by the nomination and ballot protocol due to the fact that they contain some highly complex details.
• The way the Stellar Consensus Protocol treats each slot independently is at a high level, similar to single slot consensus in Paxos, with many instances.

CONCLUSION

The Stellar Consensus Protocol is provably the first safe consensus protocol which has the ability to provide decentralized control, flexible trust, low latency and asymptotic security.
Other forms of consensus all come with trade-offs, but the Stellar Consensus Protocol maintains a high level of effectiveness for coming to a consensus quickly in a permissionless, distributed network without doing away with its safety.

Thank you so much prof @alphafx for this educating lecture.