Crypto Academy Week 13 - Homework Post for @alphafx
INTRODUCTION
Blockchain technology has been making waves in different aspects of life. With a network of nodes coordinating to achieve optimum results, there has to be some sort of consensus or agreement.
Normally, in centralized systems, data on a ledger is verified as correct by the trusted central authority. The case is different when it comes to decentralized ledgers where where anyone can add data and anyone can verify it. These validators can be untrusted. For this reason, there has to be a algorithm put in place to define how data is added and confirmed.
Every blockchain has a system that helps it attain this agreement and minimize faults in the system. This is called the Consensus Algorithm.
I already talked a bit about the Stellar in a different homework and now I would talk about its consensus algorithm. Let’s go...
Stellar
Before we talk about the stellar consensus protocol, let’s take a recap on Stellar.
Stellar is a decentralized payment protocol that facilitates the transfer of fiat and digital currencies across borders. It was developed by Jed McCaleb (cofounder or Ripple) and Joyce Kim with a utility token known as Lumen (XLM).
Thanks to Stellar, individuals can send funds across borders without a third party. The system makes cross border transactions cheap and swift unlike the expensive and slow centralized systems. These transactions are governed by a special consensus algorithm called the Stellar Consensus Protocol.
What is the Stellar Consensus Protocol?
The Stellar Consensus Protocol, or SCP for short, was initially described by Prof David Mazières in the Whitepaper.
It is described as a “Federated Byzantine Agreement protocol” seeking to solve the Byzantine Generals Problem of blockchains. Let me explain what I mean:
Byzantine Generals Problem
Imagine a battle scenario where an army general sends a message to another army general to retreat or attack. The message is sent through a messenger who is an imposter or traitor. The imposter can change the message passed. Another messenger comes from the same messenger but with the correct message. This situation causes a problem in consensus. How do they know who to trust? What should be done with so little time?
This is a problem similar with decentralized systems. There has to be an agreement amongst nodes before a transaction is verified. A single untrusted node can disrupt the whole system.
How the SCP tackles this problem
The SCP claims to provide the first fault-tolerant agreement system. As a Byzantine agreement system, the SCP is tolerant of so called “Byzantine faults”. This type of system helps to prevent double-spending errors by showing that a coin is not there after an initial withdrawal attempt. For example, Tim might decide to make a fraudulent move and withdraw the same coin on two different addresses. The SCP prevents this by what is known as Quorum.
A quorum is a network consisting of a number of trusted members that are able reach agreement and validate a transaction. A majority of the nodes in the quorum have to be in agreement for a transaction to be validated. This system prevents Tim from carrying out his fraudulent act.
But wait! SCP is not like regular Byzantine agreement protocols because it allows open membership. That is, anyone can join and leave. This can make Tim’s fraudulent transaction work when the validators are dishonest. For this reason, A Federated Byzantine System is required as it determines member nodes actively from the snapshots of membership given. The system introduces the concept of quorum slices which are a a subset of nodes that convince other unsure nodes to agree.
A Quorum slice is determined by the node involved. It’s like starting from a small group of trustees and adding their own trustees gradually. That is, from quorum slice to quorum slice to quorum slice and so on from a transitive closure of the original node.
The decentralized voting system of these nodes is made possible through what is called federated voting.
Federated voting
Federated voting is a process in which nodes try to agree to a statement. In this system, nodes choose from a value as an outcome that other nodes choose by sending and receive signals back and forth. Federated voting is completed in three process which are; voting, accepting and confirming.
A node casts a vote for a value and sends it message to the network. This node watches to see what other members of the network are broadcasting. If a good number of nodes are voting for the same value, then this node can go ahead and accept the value. If another quorum is accepting the same value, then it means that other quorums will eventually confirm the value and so the node deems it safe and confirm.
Sometimes a node might not find a quorum with the same vote. It can still accept a different value from a blocking set of different nodes from different quorum slices. This blocking set will block any value that is not what is accepted meaning that a quorum that contradicts that value can never be formed. This makes it certain for the node to acceptthe value. However, sometimes a blocking set might be a deceitful move to convince a node to accept a bad value. This is why their is another step of confirming as explained above.
How agreement is guaranteed
Quorum slices somehow have to reach other quorum slices in order to agree on an outcome. If a quorum slice A, comes up with an agreement, quorum slice B can never know about it if there isn’t some sort of communication. This is where the property of Quorum Intersection comes in.
Quorum intersection is a property of a system that exists when one node is being shared by two different quorums. A successful Federated Byzantine Agreement system has to have this quorum intersection for an agreement to be reached in the system.
The image above shows nodes of different independent quorum slices. These nodes cannot reach an agreement with another quorum because there is no intersection.
The picture above shows how a quorum intersection should look like. The node, N, is being shared by two different quorums. This property makes it possible for them to reach an agreement.
Safety and liveness
Safety and liveness are both properties of consensus systems. For a consensus system to be safe, its results have to be the same for two different players. For it to be live, it should always produce a result.
There is also a third property which is fault tolerance. With these three properties, a consensus algorithm can only adopt, at most, two of the properties as proven by the Fischer Lynch Paterson impossibility result.
The Stellar Consensus Protocol previously sacrificed safety for liveness and fault tolerance. This led to a consensus failure in 2014 causing a fork in the ledger. Stellar decided to create a new network that would prioritize safety and fault proof while sacrificing liveness. However, these properties are somehow all together adopted by the SCP.
As a Federated Byzantine Agreement system, the algorithm has to be free of Byzantine faults as I have explained above. What about safety and liveness?
The system ensures safety and liveness by conducting federated votes several times on several values until one makes it through the nomination phase and balloting phase.
The Nomination phase is the first stage of federated voting. This phase is carried out to determine statements that would be accepted and confirmed. These statements are nominees until the pass the confirmation stage where they become candidates.
Candidates move on to the balloting phase where they are assigned to a ballot. A quorum can then commit to the ballot after confirming other ballots as aborted.
The whole process involves a lot of technicality which is explained better here.
Key features
The SCP whitepaper describes the four key features of the SCP which I am going to mention below:
Decentralized control: There is no central control or delegation of power. Everyone is free to participate and be a validator.
Low Latency: The consensus process takes only a few seconds. Yes, everything I described above happens in a few seconds.
Flexible trust: Trust can be defined by different nodes. That is, nodes can choose other trusted nodes as they please.
Asymptotic security: A high computing power cannot be employed to attack the system because of the digital signatures and has families that the security is based on.
Behavior of nodes
Nodes can generally be classified as Well-behaved or Ill-behaved. Let’s talk about them a bit:
Ill-behaved
A node that does not follow protocol and behaves haphazardly is regarded as an ill-behaved node. These nodes suffer Byzantine failures in the sense that they do not choose sensible quorums, may have crashed or are maliciously manipulated. I’ll-behaved noses always fail because they do not enjoy safety and liveness.
Well-behaved
A node that chooses sensible quorums is said to be well-behaved. They follow the protocols stated by the system. These nodes can still fail however. Failed Well-behaved nodes are regarded as either Blocked or divergent.
Blocked nodes are nodes that do not enjoy liveness. These nodes wait for messages from ill-behaved nodes for agreement.
Divergent nodes are nodes that lack the safety property. These nodes have been poisoned by wrong messages from ill-behaved nodes and so produce a wrong output. This attack is way worse than that of blocked nodes.
Nodes that enjoy the properties of safety and liveness simultaneously and do not fail at all are considered as Correct.
Advantages of the SCP
Tackling Double spending: This consensus system tackles the issue of double spending as I explained in the case of Tim above.
Cheap and fast: As with what Stellar was built for, this consensus algorithm allows for cheap and fast transactions across borders.
Disadvantages of the SCP
No Reward system: The SCP does not incentivize good behaved nodes in the system.
No certainty on trusted nodes: It is impossible to know which nodes to trust. A bad quorum slice can be chosen and consensus will not be reached.
Comparing Proof of Work and SCP
Now, I would like to compare Stellar’s novel protocol with Bitcoin’s popular proof of work.
Similarities between SCP and Proof of Work
They are both decentralized.
They both prevent double spending.
They both employ hashes for validating transactions.
Differences between SCP and Proof of world
| Stellar Consensus Protocol | Proof of Work |
| It does not require a lot of hardware | It requires a great amount of hardware and energy |
| Coins cannot be minted | Coins can be minted |
| Fast transaction time | Slow transaction time |
| There is no waste of resources | Resources are constantly wasted in this |
| Consensus is reached by trusted nodes | It requires work to be done |
CONCLUSION
Consensus algorithms are long complicated concepts that define a blockchain behavior. Stellar’s Consensus Protocol is relatively easier compared to Proof of Work and proof of stake. As the years go by, more consensus protocols will arise to tackle different blockchain and real world problems.
Special thanks to @alphafx
Thank you very much! well presented and explained with original materials.
Task satisfactorily done
Thanks for participating
Thanks so much prof
It’s an honor