This article will serve as a tool for exploring the complex topic of blockchain consensus. We will go into detail about a variety of consensus mechanisms and shed some light onto corresponding theories that assist in embellishing the mechanisms’ importance.
What are they exactly?
Blockchain gets its name from its prime function of being a chain of digital blocks. Information is stored inside these “blocks” and they are placed on a public database that is referred to as the “chain.” The digital information within these blocks are split into three parts:
- The blocks store the information surrounding a transaction, such as the date, the time, and the dollar amount.
- The blocks store information regarding the participants in the transaction. Instead of recording your actual name, your purchase is recorded without any identifying information, using something called a ‘digital signature’ that acts as a username.
- The information that is stored in the block will differentiate it from other blocks.
While this set-up creates a system that is void of corruption at the hands of a single source and ensures reliability that most other systems cannot guarantee, it simultaneously creates a major issue. That singular issue is the uncertainty surrounding how the decisions on the system are made and how anything gets done.
To understand where these questions come from, let’s think about a conventional centralized organization. All of the decisions on the system are made by a board or the singular leader of decision makers, unlike in a blockchain because there is no “leader” in a chain. In order for a decision to be made on the blockchain, they all need to come to a consensus, which is carried out by using ‘consensus mechanisms.’
From here, we can go over how exactly these specific mechanisms work, why they are of great significance, and what are some of the mechanisms that are used in cryptocurrencies.
A consensus is generally defined as an accepted opinion or decision among a group of people. To expand on this, Seeds for Change describes consensus decision making as:
“…a creative and dynamic way of reaching agreement between all members of a group. Instead of simply voting for an item and having the majority of the group getting their way, a group using consensus is committed to finding solutions that everyone actively supports, or at least can live with. This ensures that all opinions, ideas and concerns are taken into account.”
In more rudimentary terms, a consensus is a more dynamic and opinionated approach towards coming to an agreement. The most common method of voting is primarily concerned with settling for a majority rule without any consideration for the status and well-being of the minority party, whereas a consensus aims to make sure that an agreement that could benefit the entirety of the group is reached. If one were to look at this system through an idealistic perspective, it can be interpreted as a way for a group of people spread out across the globe to collectively build a more equal society.
A key method by which consensus decision making is accomplished is by using the aforementioned ‘consensus mechanisms,’ the objectives of which are:
- Agreement Seeking: The standard consensus mechanism should be able to garner as much agreement from the group as possible.
- Collaborative: All of the participants’ goals should be that they will be able to work alongside each other to achieve a final result that puts the group’s best interest above everything else.
- Cooperative: All of the participating individuals must not – and should not – put their own interests first and they must work together as a team rather than work independently.
- Egalitarian: A group that is trying to reach a consensus should function in a way that allows each and every vote to hold an equal amount of weight. To put simply, one person’s vote cannot be worth more or be more important than another person’s.
- Inclusive: The number of people that are involved in the consensus process should be as high as possible. In addition, it should not operate like regular voting where there are those who are apathetic towards voting because they are of the belief that their vote would hold no weight in the long run.
- Participatory: The consensus mechanism must work in such a way that everyone involved should actively participate in the overall procedure.
Having now defined what consensus mechanisms are and also established what their primary intents for use are, we can now start to look deeper into what certain mechanisms should be used for something like blockchain technology. First, we must introduce a concept that ties into that subject matter so that we can get a clear idea on what we are getting into.
Byzantine Generals Problem
Before the launch of Bitcoin, there had been numerous other versions of decentralized currency systems that ran on a peer-to-peer network. They all failed to reach the heights Bitcoin did due largely in part to the fact that they were unable to solve the biggest problem when reaching a consensus, which is called the “Byzantine Generals Problem” (also known as “Byzantine Fault”).
To properly explain this concept would require imagining a specific scenario. Let’s say there is a group of the titular Byzantine generals and they wish to attack and conquer a city. There are two unequivocal problems at hand:
- The distance between the generals and their armies are far apart, so this not only makes a centralized authority next to impossible but building a coordinated attack will prove itself to be a difficult task.
- The city itself already has a huge army and the only possible way they can win is if they attack at the same time.
If they wanted to assemble a successful enough coordination, the armies that reside on the left side of the castle would send a messenger to deliver a notice to the armies on the right side of the castle that tells them to attack in three days. There is always the possibility that the armies on the castle’s right side are not prepared for the date of that attack and say that it should take place in five days instead. They then send the messenger back to the armies on the castle’s left side to deliver the message, and with that, we encounter a clear-cut problem.
There are a lot of things that could negatively affect the messenger, both regarding his well-being and his trek(s). He could be captured, endangered, or killed and replaced with another messenger working for the targeted city. All of this, especially the latter, could potentially lead to the armies receiving tampered information that could result in an uncoordinated and haphazard attack that will in all likelihood end in defeat.
This entire hypothetical scenario contains a clear reference to blockchain, with the chain being a gigantic network and making the idea that we are supposed to trust it without question seem sketchy. There is no way of knowing for sure if the Ether from your wallet that you are sending to someone within the network will not be modified or meddled with in any way at some point to change the value.
What the generals in the imagined scenario need for their communicative system is a consensus mechanism, which can ensure that their army will be able to attack as a harmonious and organized unit despite the possible setbacks. From here, we can finally transition to a list of various consensus mechanisms that can assist in solving the Byzantine Generals Problem.
Mechanism #1 – Proof of Work
Satoshi Nakamoto, the mysterious figure behind the creation of Bitcoin, found a way to bypass this issue by formulating the ‘proof of work’ (PoW) protocol. To illustrate how it works, let’s apply it to the scenario that has been set up by the Byzantine General Problem.
Let’s assume that the army on the castle’s left side wants to send a message to the army on the right side to attack in four days. To properly carry this out, they will need to follow these imperative steps:
- First and foremost, they would attach a ‘nonce’ to the original message. In cryptography, a nonce is an arbitrary number of any value that can be used in cryptographic communication, but only once.
- Following that, they hash the text with the nonce attached and await to see the result. Let’s say, theoretically, that the armies have come to the conclusion that they will only share messages which, on hashing, will give a result that begins with 5 zeros. For those that are unaware, a hash is basically a function that converts an input of letters and numbers into an encrypted output of a fixed length. It is created using an algorithm and is also an essential component in blockchain management.
- If the conditions of the hash have been met, they will send the messenger off with the hash. If the conditions have not been satisfied, then they will keep on changing the value of the nonce at random until they eventually reach the desired result. This particular step is evidently incredibly time-consuming and tedious and requires a large amount of computation power.
- If the messenger ends up getting apprehended by the city and the message gets tampered with, then according to the properties of hash function, the value of the hash will get changed drastically. If the generals on the right side of the castle see the message and notice that it isn’t starting with the required amount of zeros, then they can just call off the impending attack.
With all this being said, there is a possible loophole in the operation; that being no hash function is 100% free of percussion. In this sense, if the city ends up obtaining the message and meddles with it, it is not entirely implausible for them to continuously change the nonce until they come up with the desired result that just so happens to have the required amount of zeros. As time-consuming as this may be, it is still a possibility, so to counteract this prospect, the generals will have to use strength in numbers.
Let’s speculate for a moment that rather than just one general on the castle’s left side sending messages over to one general on the castle’s right, there are actually three generals on the left side who have to send a message to the ones over on the right side. In order to properly execute this, they can create their own message and then hash the advancing message before attaching a nonce to the resulting hash, which they will hash again. This time around, they wish to be given a message that starts with 6 zeros.
This will be a time-consuming process, not unlike the others, however this time if the messenger were to end up getting caught by the city, the amount of time that would be needed to tamper with the advancing message and then find the interrelated nonce for the hash will be much more. This is something that will take a good long time to complete, perhaps years. So, instead of sending just one messenger, the generals will send multiple messengers, and by the time the city reaches the halfway point of the computation process, they will be attacked by the armies and annihilated.
In regards to this scenario, the generals on the right have the easier part of the operation, as their only duty is to attach the message with the appropriate nonce that will be given to them and determine whether or not the hash matches. Hashing a string is a simple task to do, and it is essentially the procedure behind PoW. The process behind discovering the nonce for the appropriate hash target should be a difficult and tedious undertaking, however, the process of inspecting the result to make sure that no malpractice has taken place should be quite simple.
As HedgeTrade writer, Josiah Swaim, explains, “The Proof-Of-Work protocol is used to prevent general spam and abuse of the resources of the network as well as attacks like a Denial of service attack while still being economical for honest participants or users.” In relation to blockchain, how the PoW protocol works can be summarized as the following:
- The miners figure out a series of cryptographic puzzles to ‘mine’ a block so that it can be added to the chain.
- This procedure requires a massive amount of energy from the individual and an equally large amount of computational usages. It should be noted that the puzzles have been purposefully designed to be hard, as well as taxing on the system.
- When a miner ends up solving a puzzle, they present their mined block to the network for authentication.
- Verifying whether or not the presented block belongs on the chain is a fairly uncomplicated task.
While the proof of work mechanism has proven itself to be the answer for a lot of questions when it comes to solving the Byzantine Generals Problem, there are still some issues pertaining to the protocol.
- First of all, proof of work is a very inefficient process due to the sheer amount of both power and energy that it consumes.
- Organizations and people that are fortunate enough to afford the faster and more powerful ASICs will usually have a better chance at mining than those less fortunate.
- This results in Bitcoin not being a system that is as decentralized as it aspires (and claims) to be, with an estimated 65% of the hashrate being divided among five mining pools.
- From a hypothetical standpoint, these larger mining pools can team up with each other if they wanted to.
Mechanism #2 – Proof of Stake
For a while, Ethereum has planned on transitioning from the PoW protocol to ‘proof of stake’ (PoS). Swaim writes that, unlike proof of work, “PoS doesn’t spend CPU or GPU cycles verifying hashes. Instead of miners, PoS blockchains have validators that serve the more or less same purpose. Instead of relying on huge amounts of power to incentivize the network, PoS consensus creates a greater asymmetry in favor of the defender (a node behaving in good faith to maintain an accurate blockchain) by relying more on penalties than PoW as a disincentive for bad behavior.”
Proof of stake will make the mining process into something virtual and will employ validators as replacements for miners. This is how this particular procedure will work:
- The validators will need to lock up a portion of their coins as stake.
- Following this, they will proceed to start validating the blocks, meaning that when they uncover a block that they believe can be added to the chain, they will verify it by placing a bet on it.
- Should the block get conjoined, the validators will then be given a reward that is correspondent to their bets.
The proof of stake protocol has proven to be a lot more mindful of resources than proof of work, where you will need to waste a good chunk of resources if you want to go through with the rules of conduct. It is essentially a waste of resources for the sake of wasting resources.
As expected, there is a flaw to PoS; one that can be described as more of a roadblock than anything else.
The developers at Ethereum have – as previously touched upon – had a plan to move from PoW to PoS. However, before they could forward with this plan, they, of course, have to take into consideration the most prominent shortcoming connected to PoS.
To explain this weak point accordingly, let us imagine a blue chain and a red chain that both branch out from the main chain itself. There is a glaring possibility in this set-up; that being that a miner with malicious intent could mine on the red chain and force a ‘hard fork.’ To provide a bit of context, a hard fork is a radical alteration to the protocol that makes blocks/transactions that were previously invalid credible (or vice-versa).
In the standard PoW system, this risk can be rendered less severe. Suppose that the aforementioned malicious miner wants to mine in the red chain and dedicates all of their hash power to it. They will not be able to get any other miner to join them on the new chain because everyone else will keep mining on the blue chain due to it being more profitable and less risky to mine on a longer chain.
At this point, keep in mind that the PoW protocol is expensive when it comes to using resources. It would generally make no sense for a miner to put so much resource to waste by employing it on a block that will be denied by the network. Therefore, splits in the chain are made avoidable in the PoW system because of the amount of money that the attacker would have to put to waste.
Things like this are made a little different when you introduce PoS to the equation. If you are the validator, you can easily place your money into both the red chain and the blue chain without any worry of receiving consequences. No matter the circumstances, you will always prevail and you will have nothing to lose in spite of any malicious intentions or actions on your part. This is what is commonly referred to as the “Nothing at Stake” problem.
In order to integrate the PoS consensus system, cryptocurrencies have to address this problem and Ethereum plans to go about doing this in such a way that adapts their ‘Casper protocol,’ which is the PoS custom that Ethereum is in favour of. CoinSutra writer, Sudhir Khatwani, states that introducing Casper, “…will enforce a specific form of proof-of-stake as proposed by Vlad Zamfir, a pioneer Ethereum developer.” What sets Casper apart from other PoS protocols is that it has implemented a process in which they can crack down on all malicious elements.
This is how, under Casper, the proof of stake will operate:
- The validators will wager a portion of their Ethers as stake.
- Following that, they will begin to validate the blocks, meaning that if they discover a block that they think can be included to the chain, then they will verify it by placing a bet on it.
- Should the block end up getting attached, then the validators will receive a reward that is proportionate to their bets.
- Be that as it may, if a validator were to act with malicious intent and try to pull a “Nothing at Stake,” they will automatically be apprehended and all of their stakes will end up getting slashed.
As you can clearly see, the Casper protocol is built to operate in a trustless system and be more ‘Byzantine Fault Tolerance’ (more on this later). Any user who attempts to act in the manner of a Byzantine will be punished almost immediately by having their stake cut off completely. This, above all else, is where Casper differs from most of the other PoS protocols, with malicious elements having a lot to lose and making any attempts for “Nothing at Stake” extremely futile.
By incorporating Casper and PoS, it will prove itself to be a crucial component in Ethereum’s aspiration to expand.
Mechanism #3 – Delegated Proof of Stake
Now we move forward from the basics of proof of stake to another form of it that is called ‘Delegated Proof of Stake’ (DPoS). EOS is utilizing this specific consensus mechanism as a means to increase the number of transactions per second to somewhere in the millions.
Any users who are in possession of tokens on a blockchain unified in the EOS software are able to select the block producers through an ongoing approval voting system. Anyone can participate in this block producer election and they will also be given the chance to generate blocks that correspond to the total votes that they receive relative to all of the other producers.
Here is how it works:
- The blocks are generated in rounds of 21.
- At the beginning of each round, 21 block producers are chosen. The top 20 are automatically picked while the 21st producer is chosen proportional to the number of votes that are relative to the other producers.
- The producers are then rearranged with the use of a pseudorandom number that is taken from the block time. This is carried out in order to ensure that a balance amongst the other producers is maintained.
- To make sure that regular block generation is preserved and the block time is kept at three seconds, the producers are punished for lack of participation by being removed from consideration. To be kept in consideration, a producer must manufacture at least one block every 24 hours.
The DPoS system is not capable of experiencing a fork because instead of competing to find blocks, the producers will actually have to comply with and work alongside each other. If a fork were to occur, the consensus will switch to the longest chain.
Moving on to the subject of confirming transactions, a DPoS blockchain usually has 100% block producer participation and a transaction is typically confirmed within 1.5 seconds from the time of the distribution by a certainty of 99.9%. The only way to have total certainty over the legitimacy of a transaction, a node will only need to wait for a ⅔ majority of the producers to reach a consensus.
In the event of a fork occurrence that was caused by carelessness or ill-mannered intentions, all of the nodes will not switch to a fork by default, which does not include any of the blocks that are not finalized by the ⅔ majority producers. Regardless of the length of the chain, this remains the same, with each block needing to gain the ⅔ approval in order to be considered part of the chain.
Due to the short block creation time, it is not impossible to warn the nodes of whether they are in the major or the minor chain in the span of nine seconds. The reason for this is straightforward, as the average time that transpires between each block is three seconds. If a node misses two chronological blocks, there is about a 95% chance that they are in a minority fork, but if a node misses three consecutive blocks, then there is a 99% chance that they are in a minority chain.
There is an additional feature in the EOS software called ‘Transaction as Proof of Stake’ (TAPOS), wherein every transaction in the system must have the hash of the most recent block header. What this does is…
- …it prevents transaction replay on other chains.
- …it alerts the network that a user and their stake are on a specific fork.
By doing these two things, it sets up prevention against validators who act with any malicious intent on other chains. Now this PoS protocol sounds like it is useful and efficient, however, there is a catch, much like with other seemingly perfect systems. According to the words of Ethereum co-founder, Vitalik Buterin, the delegated proof of stake system fails at the ‘Coordination Game theory.’
To better explain this, let’s take a look at this matrix:
As you can tell by this grid, there are two Nash equilibria: (A,A) and (B,B), both deviating from either of the states will not benefit them. The key idea of this game is to convince people to go from (A,A) to (B,B). If there is a small group that is involved, then it is a simple procedure where you can simply coordinate via phone messages or emails, but if a large group is involved in the game, then complications will arise.
The most basic difference between the coordination problem and a prisoner’s dilemma is that in the case of the prisoner, both of the players have to go with choosing (B,B) because that particular choice has a more satisfying pay-off even though, morally, (A,A) is a much better solution. In the coordination problem, the focus on the choice is not about the morality of the selection or even the pay-off but is really about the motivation for a person to move from one specific state to another.
There really is no reason for a huge group of people to change the way they do things.
A coordination game will ultimately fail when only the minority of the group changes their state and the majority do not, and vice versa. It is only a success when the majority of the group alters their state.
An example of this would be if we hypothetically wanted to change the language to something more symbol-based, like going from “Give me your number” to “#?” Speaking only in this language will result in failure because the majority will not understand what you are saying and you will be rejected from the conversation. However, if the majority is the one to shift to this language, then you yourself will be forced to shift to this language.
The DPoS system could utilize the coordination game theory to its detriment because there is the possibility of a certain situation being favoured by the block producers that is not in accordance with the nodes. As is, we can only speculate as to whether or not EOS will someday incorporate DPoS.
Mechanism #4 – Delegated Byzantine Fault Tolerance
“The consensus part of the Delegated Byzantine Fault Tolerance protocol occurs through a ‘gamified’ form of block verification among professional node operators. All of these professional nodes are appointed by ordinary notes through a delegated voting process. The professional node broadcasts its version of the blockchain to the network. If 66% of the other nodes agree with the information, consensus is achieved. Should this threshold not be met, a different professional node is appointed to broadcast its blockchain version until consensus can be established.”
There are two chief cases in which one of the participants might act in a malicious sort of manner:
- The speaker is the malicious one. If this is the case, then the speaker has sent a malignant message to two of the delegates and a more accurate message to one delegate. The majority rule can easily appease this scenario, as the two delegates will notice that their hash does not match up with the speaker while the other delegate will see that their hash is a perfect match. 2 of the 3 will disprove the proposal and a consensus will not be achieved.
- The malicious individual is one of the delegates. The speaker sends out the correct message, but one of the delegates decides to act in a nasty manner and states that their number does not match up to the speaker’s number. With that said, since 2 of the 3 delegates are not affiliated with the malicious intentions of the other delegate, they will approve the proposal since a 66% consensus will have been reached.
These four consensus mechanisms are the more common ones used by cryptocurrencies. That being said, there are several others that can potentially serve as alternatives to the ones listed, including:
- Proof of Burn – the idea that the miners show proof that they burned some coins (i.e. sending them to an “unspendable address”)
- Proof of Activity – a mixed approach that joins the the ‘proof of work’ and ‘proof of stake’ algorithms
- Proof of Elapsed Time – a mechanism that “prevents high resource utilization and high energy consumption”
- Proof of Capacity – allows the mining devices within the network to use their available hard drive space to dictate the mining rights