Steemit Cryptoacademy Week 13 Homework Submitted To Professor @alphafx| The Stellar Consensus Protocol| By @bukkyi4u

The Week 13 lecture on consensus algorithm by professor @alphafx was well-received equally I benefited in a very big way by learning about:

• Proof of work consensus algorithm
• Proof of stake consensus algorithm
• Delegated proof of stake
• Proof of activity, and so on.

In response to the homework task given for this week I will examine the Stellar Consensus Protocol.

INTRODUCTION

A ledger distributed future is a coinage that simply comes to mind when summarising the concept behind the Stellar Consensus Protocol. The current state of the global financial structure is a pathetic infrastructural mess of a closed system. The loopholes that have been created in these systems result in the gaps that slow down the rate of transactions across various zones and unnecessarily increase the inherent cost of it. Consequently, this hampers the growth of financial structures and create unsatisfied end-users. A bold step in solving this problem is creating a global financial structure that can come with the efficiencies associated with the internet structure itself while equally ensuring high-level accuracy in transactions.
The creation of a decentralized global financial system that would eliminate entry barriers and allow various cadres of participants who invariably contribute to the expansion of the system, even with meagre financial status, is a right step in the right direction. The low entry barrier ensures that a lot of people can now participate while also having to validate transactions without having to rely on any central body. However, the accomplishment of this necessitates the creation of the model Stellar Consensus Protocol.

THE STELLAR CONSENSUS PROTOCOL (SCP)

screen from medium

The stellar consensus protocol as a consensus mechanism that can function globally is provably very safe while equally flaunting four key features namely:

• Decentralized control
• Low latency
• Flexible trust, and
• Asymptotic security

Actually, not all consensus algorithm offer all these features at the same time.

MECHANISM	LOW LATENCY	DECENTRALIZED CONTROL	ASYMPTOTIC SECURITY	FLEXIBLE TRUST
Proof of work	no	yes	no	no
Byzantine agreement	yes	no	yes	yes
Proof of stake	probably	yes	probably	no
Tendermint	yes	yes	yes	no
Stellar consensus protocol	yes	yes	yes	yes

STELLAR CONSENSUS PROTOCOL OPERATIONAL MODEL: THE FEDERATED BYZANTINE AGREEMENT

The SCP adopts an entirely novel approach to the technology of consensus mechanism known and referred to as the Federated Byzantine agreement (FBA). This novelty comes with some interesting features:

Distributed Consensus

In this model nodes are positioned to replicate a particular state which could be a transaction ledger. This state would need to be authenticated periodically by the nodes. Usually, each update is uniquely identified by a slot whose content must be agreed upon by all the nodes. Consequently, all the nodes would have to reach an agreement that a particular update is safe and thereby externalize it or publish it to their own unique ledgers. Consensus is only reached when all the nodes externalize the same value of a slot.

Tolerating Byzantine Failure

There is a mechanism that makes it possible for consensus to be reached even when some nodes are not acting in accordance with the majority or experiencing Byzantine Failure. This sets up a mechanism that can ignore a few incorrect nodes and therefore would not have to rely on the entirety of the node structure of the system to validate a slot.

Federated Quorum Slices

screen from source

This distributed system makes use of the term Quorum to refer to the complete number of nodes that are required to reach an agreement. This results to the introduction of what is known as Quorum Slice by the Federated Byzantine Agreement. This quorum slice is the subset of the quorum itself which can convince a node over an agreement.

There are a few differences between the classic non-federated Byzantine agreement and the federated Byzantine agreement. In the federated Byzantine agreement consensus can be reached even in the case of Byzantine failure. However, the membership of each node must necessarily have been verified upfront.

Actually, the major difference between the federated Byzantine agreement and the Byzantine agreement is that each node in the Federated Byzantine agreement can decide on its own quorum slice. In the federated Byzantine agreement each node recognises no central body from where authoritative information must come. Instead they decide on which other node to trust. This decision can be based on an extrinsic criteria, for example, a node can decide to trust another node due to its reputation as a well established bank or trustworthy financial institution.

There is Quorum intersection when the different nodes agree over a particular decision while quorum disjoint is created when there is disagreement. For instance, when node A wants a cat but node B prefers a lion instead. Making good decisions or choices will be entirely left for each and every node. Therefore, it is necessary to ensure that the node produces correct decisions that lead to quorum intersection. Achieving this will require that each quorum slice will be very large and include a lot of nodes that are not ready to risk their reputation by lying.

WHAT COULD GO WRONG?

It is expected that each node must maintain liveliness and safety when selecting quorum slices. However, the system does not want to risk responsiveness for correctness.

• A node would lack liveliness if it is blocked when trying to reach a decision thereby causing slowness
• A node would lack safety and become divergent if it externalizes values that are different from the ones externalized by other nodes
• A divergent state would result when nodes store information of externalized values that are quite irreconcilable. This state is more dangerous than the blocked state.

THE VOTE, ACCEPT AND CONFIRM FEDERATED SYSTEM OF VOTING

screen from stellar whitepaper

The FBA nodes utilise a federated form of voting system in trying to reach agreement. This can be illustrated in what I call the Transport Type Consensus

TRANSPORT TYPE CONSENSUS

Let us try to understand the process by which nodes decide on or vote over a particular statement thereby leading to cross-sectional agreement in the system. Let us use the illustration of a group of company workers deciding on the type of transportation they would want to adopt. In this case the nodes will be made to bear names of the workers while the transport type would act as the statements to be voted on.

James works in a mining company that gives its workers the option to choose the type of transport they would want to use to travel to the mining sites. Actually, it is not everyone that has to vote. However, when an accepted majority of workers have voted, a particular transport type is adopted. Solving this with the SCP would follow the process below.

Voting

Let us assume that James would prefer using a Hilux van to travel to the site. However, he does not want to conclude over it yet because he is waiting on the other coworkers to vote for him to know whether he would eventually go with their own decision. This voting, in particular, happens on the level of the node and acts as a preliminary one.

At this stage James votes on Hilux van but remains open to the option of accepting other choices eventually agreed upon by other workers and, however, undertakes not to change this individual choice at the moment. Understandably, he may decide to go with other options adopted by other workers in majority.

Acceptance

Slices are made to influence one another in a system known as quorum intersection. From the foregoing a path represents James initially voting for Hilux van ("voted Hilux van"). However do not forget that this preliminary vote is subject to change.

James as a node belongs to different quorum slices. Joseph, Kenneth and Jacob share quorum slices with James. Consequently, they can decide to block the path which represents James voting for Hilux van. This is known as we v-blocking. When all these three constitute a set of v-blocking nodes, which can be identified in all the slices where James belongs, the identification of these v-blocking nodes in all of James' slices eventually block James' decision on Hilux van. He is, therefore, made to accept a minibus, in line with the other three people.

However, James only accept the option if:

• He has never voted another option which contradicts mini bus
• Each member of the node that constitutes the v-blocking set claims to accept minibus or if each member of the quorums that include James himself either claim to accept minibuses or voted for it.

Ratification

Ratification happens when all the members of a quorum have voted over a particular statement. In such a situation we say that the quorum ratifies the statement. However, it should be noted that a node may not need to have necessarily voted a particular statement at the initial voting stage for it to be ratified. The node may have voted differently but due to the choices of the overwhelming majority he may decide to change his vote or the system may decide to ratify the overwhelming statement.

Confirmation Messages

screen from medium

Actually, this is the final stage of the voting process and would involve an agreement that is binding across the entire system. Nodes are made to exchange messages in form of confirmation messages. Once the required majority of nodes agree over a statement and it becomes a confirmation message, it is sent through out the system. This is such that all the other nodes that are active and responsive must necessarily have to accept this statement as a confirmation message. Subsequently, messages will be sent across board and will require nodes to confirm it.

THE SCP PROTOCOL

The Stellar Consensus Protocol comes in with the burden of carrying the distributed consensus. Actually, the system runs the risk of either losing liveliness or getting blocked in the process of distributing the consensus. Nevertheless, it should be noted that a decision could actually be left in a stalemate before the SCP comes in to resolve this and reach a state of agreement. The SCP works to reduce blocking and divergence. So, the protocol adopt a ballot-based attempt which neutralizes blocked messages if they get stuck in the process of voting.

The referendum known as ballot is the value associated to a particular statement. Before a value can be externalized a node has to commit the ballot which is linked to that value.

Commit Or Abort

All the nodes can either choose to commit or abort a particular value. In a situation whereby the coworkers get stuck on making a transport type decision, a neutralize option would be initiated. In this situation a transport type, say, minibuses could be neutralized and give workers less voting options.

Neutralizing minibuses would require the co-workers to send a message abort mini-buses. This now makes it possible for the co-workers to move on with the other choices. On the other hand, co-workers could ratify the value 'commit mini buses'. Then, the workers will reach an agreement on the value tied to the ballot which is 'minibuses'. In this way, the statement 'commit minibuses' becomes valid and will appear in the voting process. However, before 'commit minibuses' would appear, other options that are less than it in voting size would have been aborted.

CONCLUSION

In the SCP protocol, with the use of quorum intersection there is never room for blocked state for quorums that are intact. There is a regular sequence which makes it possible for all these intact quorums to reach a decision and commit a value. With the use of this SCP system, making decisions on financial or monetary values can be implemented into global financial structures. In this way, efficiency, speed and accountability can be accurately preserved.