By
George Spasov
January 10, 2020
8 Min Read
Before jumping into explaining consensus algorithm in blockchain, let’s refresh our blockchain knowledge and see what we covered in the previous parts:
What is Blockchain? Nodes & Blocks
What is Blockchain? Networks, Decentralisation & Relaying
What is Blockchain? Consensus, Cryptography and Crypto Economics
The blockchain is a network of computer-accountants called nodes. The nodes keep track of identical copies of a ledger. The ledger consists of transactions bundled in blocks. The blocks are linked together forming a chain – blockchain. The transactions are cryptographically signed by the person spending some of their balance. “People” in the ledger are identified by their public key (known as address), while transactions are signed via their private key. The public-private keys pair is known as a wallet.
There is no central node in the network, and all the nodes are equal. They all relay on each other information about the transactions happening and synchronize their copies of the ledger with each other. This communication process is called gossiping.
The goal of the network is to reach an agreement about the latest valid version of the ledger and synchronize their own copies in accordance with it. The nodes are given economic incentives to act correctly and guard the network, while also being given economical punishments for trying to fraud/cheat the system. This balance between incentives and punishments is known as crypto-economics.
The process of reaching consensus is known as consensus algorithm. The different consensus algorithms have different crypto-economic incentives and punishments.
In this article, we will be looking at the problem that the different consensus algorithms solve and how they differ.
A typical example illustrating the challenges a blockchain network is facing is the “Byzantium Generals Problem”. The example is very similar to the communicational challenge we outlined in the last article – the one with the emperor and the general.
The events of this problem take place around the city of Preslav – one of the strongest Bulgarian cities. We, the Romans, again have the goal of capturing the city. This time we have four armies that have surrounded the city. The forces inside Preslav are strong enough to hold any army by itself, but if the armies attack together, Preslav will fall.
You are the general of one of the armies (check this video), and you can talk with the other generals through messengers. You need to agree on the exact date and time of the attack, otherwise, you will fail. To put it simply, the four generals need to synchronize over the common decision – when to attack. Even in this early point, we can draw a similarity with our network of nodes, where the nodes need to reach consensus over common decision – what is the latest state of the ledger.
Several problematic scenarios can be outlined for our generals.
Problem #1: The dead messenger
Let’s say you try to send the “Attack at dawn” message, to all the other generals. What will be the result if one or multiple messengers get captured?
The intended receivers will never receive the news. Unbeknownst to them, the rest of the generals will attack and fail.
In order to “combat” this problem, you would ask them to send you back a confirmation message. Only once the sending general has received a return message, you can be sure to attack.
Well, this is a nice improvement, but what if the messenger bearing the return message is captured? The others will attack, you won’t – again resulting in failure.
Also, what if one of the generals cant attack tomorrow? You have to cancel the attack for the other generals too. Tons of problems coming out of this too.
To make matters worse – you are the central point of failure. The other generals can never know if you’ve sent messages to the other generals and what their response is. They are always risking a lot when attacking.
Luckily, batching messages (think transactions) together would help us here. Every messenger will go to all four generals gather their approvals, ask them to sign the message. Once a messenger comes to you, bearing signatures from all four generals you will be able to safely attack. Or will you?
Problem #2: Impostors
Imagine is the Bulgarians catching a messenger, and sending an impostor with a wrong date and time to every general. All will attack separately and fail.
As we saw in the last article, one possible solution for this problem is the asymmetric signatures that cannot be forged by the Bulgarians.
Problem #3: Traitors
The last grim scenario would be if one of the generals is a traitor and dis-synchronizes the others?
As outlined in the last article, the best way to combat this problem is to set up a mixture of incentives and punishments for this general.
One example would be for the emperor to promise a hefty reward if Preslav falls, and promise sever punishment if it does not. The traitor general would need to get so much money from the Bulgarians, in order to buy himself an army to defend from the wrath of the emperor.
Puzzle piece 18: Byzantine Generals Problem is a commonly referred scenario that asks the reader to make sure that multiple entities, which are separated by distance, reach full agreement before an action is taken. This scenario bears huge similarities to the problems blockchain networks are facing.
All of the problems above can cause complete failure of the mission. All of these also are true for our network of nodes. Imagine the generals are our nodes, and they try to synchronize over the state of the ledger, not the date and time of the attack.
In order for the network to be secure, the algorithms for reaching a consensus would need to account for all the possible problems above.
Let’s have an overview of the most popular consensus algorithms currently employed by the blockchain networks.
Byzantium Fault Tolerance, commonly referred to as BFT, is the simplest and most secure consensus algorithm pattern available out there.
The solutions to the problems outlined above were one implementation of BFT. To put it simply, this algorithm requires all actors in the network to sign off every message and distribute it to the rest of the network. Add to this a carefully designed crypto-economics like the incentives and punishments by the emperor and we will have one of the most secure consensus algorithm out there.
One might wonder, why other algorithms exist then? Similarly to the problem of relaying, outlined in the previous articles, this algorithm fails performance-wise with the growth of the number of nodes in the network.
BFT is better applicable for small networks, but it does not meet the real-world requirements when it comes to public networks like Bitcoin and Ethereum.
Puzzle piece 19: Byzantium Fault Tolerance, BFT, is a consensus algorithm pattern that involves all parties signing off all actions in the network. This algorithm is simple and secure but fails at scale.
Proof of authority, commonly referred to as PoA, is another consensus algorithm pattern. POA is a somewhat centralized consensus algorithm. All the nodes are submitting their transactions to be bundled and ordered to the “authority nodes”. The Authority nodes need to be publicly recognizable and have some reputation and authority to lose. For example, a POA-based blockchain network might elect a node run by the local police department as an “authority node”.
These algorithms are super fast at pretty much any scale but inherit all the problems of the centralization we’ve previously outlined. Generally, these algorithms are used in very special use cases where trust can be guaranteed by reputation, or for test purposes only.
Proof of Stake commonly referred to as PoS is a consensus algorithm pattern relying on staking money (mostly cryptocurrencies, a topic that we will get into in the next chapter). Here is a rough overview of the algorithm.
One node at random is chosen to propose a block. If all the transactions in the block are correct and are validated by a certain threshold of the rest of the nodes, the block proposer is given a reward.
If the block is found to be invalid, the block proposer stake is confiscated and given to the validators.
An important note here is that the chance for a node to propose a block is tied with the amount of funds you have at stake. The reasoning behind it is that nodes that have more stake have more to lose, therefore they will risk more to “lie”.
PoS is a very popular algorithm, especially with the newer blockchain networks. One of the cons of the algorithm is that it essentially means that “The rich will become richer”. The more stake you have, the bigger the chance you have to be chosen and get reward, therefore become even richer.
Puzzle piece 20: Proof of Stake, PoS, is a consensus algorithm pattern relying on nodes staking value and being monetary rewarded/punished for correct/incorrect behavior.
Proof of Work, commonly referred to as PoW, is the most widely used consensus algorithm pattern, at the moment of writing of this article. It is used by some of the biggest networks like Bitcoin and Ethereum.
It is somewhat similar to PoS, in terms of the nodes competing to be the block producer and the rest verifying the proposed block.
The competition in PoW is who can first apply a mathematical function, known as hashing, and produce a number. In case that after hashing, the number is above a certain threshold, the node retries by slightly tweaking one of the block parameters. This process is repeated until the resulting number is under the threshold. The process is known as “mining” and the nodes using the PoW algorithm to synchronize are known as “miners”.
In terms of crypto-economics, on one side the miners are incentivized via hefty reward for producing a valid block, on the other side, all the energy used to do the hashing acts as punishment if the block is found to be invalid.
One of the biggest arguments against PoW is the huge environmental footprint that it has. Millions of nodes around the world waste tons of energy in order for just one of them to be the “winner”.
Puzzle piece 21: Proof of Work, PoW, is a consensus algorithm pattern relying on nodes performing energy-expensive computations and being monetarily rewarded for correct behavior. Incorrect behavior is not directly punished, but the energy spent is deemed punishment.
As you’ve seen, most of consensus algorithms use money as incentive or punishment. The money, however, is normally not your regular bank-issued money, but brand new records in the ledger produced by the algorithm itself and given to the block producer. These currencies are governed by the blockchain network and secured cryptographically – hence the term cryptocurrencies and crypto economy.
In the next part, we will talk more about what are they and what nuances are there.
Useful links
