In the ‘Smilo explained’ series we will explain the technology and choices that define the Smilo Platform in an accessible way. In this article of Smilo explained we are going to elaborate on Smilo’s consensus mechanism called the Smilo BFT+ protocol. This protocol ensures fully secure, scalable, quick, and sustainable transactions.
The blockchain core of Smilo platform contains several features which make it truly unique. These features have been implemented by using several advanced techniques and algorithms. One of these algorithms is our consensus mechanism which is based on the popular Byzantine fault tolerance (BFT) protocol.
Before elaborating on Smilo’s exclusive and improved consensus mechanism, we will explain why a blockchain needs a consensus mechanism, and we will elaborate on the standard BFT consensus protocol.
Every blockchain has at least one similar aspect known as the distributed ledger. A distributed ledger contains a record of all the previous transactions which have been conducted on the specific blockchain. It is known as a distributed ledger because the ledger is not stored in one central location. In fact, the ledger is stored across a network of computers around the world. For this system to work, it is very important that the network collectively agrees with the content of the ledger, and this is the job of the consensus mechanism.
The objective of a consensus mechanism is to confirm that the information being added to the ledger is valid. This ensures that the blockchain will always be up to date, which prevents double spending and other unreasonable behaviour.
Byzantine Fault Tolerance
In 1982, Leslie Lamport, Robert Shostak, and Marshall Pease published a paper named ‘The Byzantine Generals’ Problem’. This paper explained the solution for the ‘Two Generals’ Problem’ which was first published in 1975.
Two Generals’ Problem
In 1975 Akkoyunlu, Ekanadham and Huber describe a scenario where two divisions of the Byzantine army are located just outside an enemy city. Each division of the Byzantine army is commanded by its own general, and these generals can only communicate with each other through a messenger. After observing the enemy, they must decide upon a common plan of action.
The generals have to decide whether to attack the enemy, or retreat to their base. One of the generals might want to attack, while other prefer to retreat. However, it is critical that both generals agree on a common decision, since the separate divisions are not strong enough to attack the enemy on their own. A half hearted attack by one general would be worse than a coordinated attack or a coordinated retreat.
As it is impossible to know the true intention of one of the generals, they must adopt an algorithm to guarantee that they will decide upon the same plan of action.
This Two Generals’ Problem has been proven to be unsolvable, until 1982.
The Byzantine Generals’ Problem
In 1982, Leslie Lamport, Robert Shostak, and Marshall Pease published their paper named ‘The Byzantine Generals’ Problem’. In this paper, they changed the scenario to include more than two generals. This creates a new complication where one or more generals can act as a traitor in this situation. But how do we solve this problem? Well, first we agree that one of the generals is appointed as a commander, while the other generals are degraded to lieutenant’s.
To achieve consensus, the commander and every lieutenant must agree on the same result, so they either have to attack the enemy, or retreat to their base. It is intended as follows:
A commander has to send an order to his n-1 lieutenant meaning that:
- All loyal lieutenant’s will obey the same order.
- In case of a loyal commander, evert loyal lieutenant will obey the commanders order.
Even if the commander is considered as a traitor, the lieutenant’s still have to achieve consensus. This is done by taking a majority vote, and the result of the consensus will then be based on the majority of votes which the lieutenant’s observe.
Theorem: for any number of m, Algorithm OM(m) reaches consensus if there are more than 3m generals and at most 1m traitors.
This implies that the algorithm can reach consensus as long as 2/3 of the actors are honest. If the traitors are more than 1/3 of the actors, consensus is not reached. As a result of this, the armies do not coordinate their attack and the enemy wins the battle.
m = 0 → No traitors, each lieutenant is loyal.
m > 0 → Each lieutenant’s final choice comes from the majority of all lieutenant’s choices
Smilo BFT+ with Smilo’s Proof of Resources and Time
Smilo platform faces the same challenges, while adding a few extra. Smilo is an open and permissionless platform, meaning that every Smilo owner can either be a commander or a lieutenant. Considering this, the Smilo network will have to deal with thousands of actors, which could all be potential traitors.
As the network size increase, Smilo will have to able to scale proportionally. To accomplish this, we decided to structure our network. Click here to read more about the network.
Although we will always need more than 66% consensus with Smilo BFT+, a node will never add a block to his chain when this block has been declined. Moreover, even when more than 66% of the nodes approve a block, but Node A declined the block, Node A will not add the block to his chain, nor will the follow up blocks add this block to the chain.
All Smilo Clients (like the API, Full Wallets, etcetera) are able to verify both blocks and transactions, providing a two-factor authentication for light clients. Clients can validate if it is connected to “Good actors” or “Bad actors”, depending on the blockchain hash, and therefore decide to send a transaction to a Good or Bad actor.
Since Smilo BFT+ Blacklists ‘Bad actors’, each Bad Actor will become an orphan/bad chain (fork). Besides, considering the fact you need 10.000 Smilo to act as a node, an attacking entity needs to own an immense amount of Smilo to start with.
This makes Smilo 99.9% secure against sibling attacks. A real Sibling attack is therefore only possible with 100% “Bad actors”.
Demicoli, C. (2017, 10 juni). Byzantine Fault Tolerance. Retrieved on 17 August 2018, from https://blog.cdemi.io/byzantine-fault-tolerance/
Konstantopoulos, G. (2017, 1 december). Understanding Blockchain Fundamentals, Part 1: Byzantine Fault Tolerance. Retrieved on 17 August 2018, from https://medium.com/loom-network/understanding-blockchain-fundamentals-part-1-byzantine-fault-tolerance-245f46fe8419
Schumann, T. (2018, 5 april). Consensus Mechanisms Explained: PoW vs. PoS. Retrieved on 17 August 2018, from https://hackernoon.com/consensus-mechanisms-explained-pow-vs-pos-89951c66ae10
Be part of the Smilo hybrid blockchain movement!
Our resource partners,