Everyone sees the world from the bell tower of their own village.
Blockchain technologies top the lists of 2017’s hot trends. Many companies already back their products with blockchain technologies. Competitors use different approaches to blockchain technologies, emphasizing different aspects and pitching them as features to their customers.
One of the major roles of those particular aspects of blockchain technologies is — “consensus”.
Blockchains are diverse and can be approached from a variety of perspectives.
In layman terms , a blockchain is a public, decentralized database, that keeps public records in an append-only fashion. Moreover, once added into the database (the blockchain) a record cannot be modified and it is very difficult to falsify entries. This last feature is called persistence. When an entry in the database (the blockchain) needs to be updated, a new record must be appended to the existing information. Finally, each of records can be viewed by any member of the public, allowing for any person to individually verify the authenticity of each transaction recorded for any single entry in the database (the blockchain). This transparency means that blockchains are auditable.
Figure 1 : CC-BY-3 Theymos from Bitcoin wiki vectorization: The main chain (black) consists of the longest series of blocks from the first (genesis) block (green) to the current block. Orphan blocks (purple) exist outside of the main chain.
But why bother with blockchains over traditional databases anyway? Blockchains become immediately appealing as soon as a database needs to be decentralized. An organization looking to avoid putting too much emphasis on a single potential point of failure and to create a generally more robust system for their information might find a blockchain database more appealing than a traditional one. A distributed database cannot be hacked, manipulated, or otherwise disrupted the way a database build on one single operator can be.
In addition, a traditional centralized database requires a user-controlled access system. That is to say, it requires a system directly operated by known and trustworthy individuals (whether that is a known person, organization, computer, or any other familiar operating unit). A blockchain, on the other hand, is operated by unknown and untrusted parties (that is to say, you cannot know if it is an individual person, an organization, a computer operating automatically, or whatever else — let alone know them well enough to trust their decisions and actions implicitly).
The lack of trust inherent in the blockchain system is particularly noteworthy to our topic of ‘consensus’. Because any entity, individual, or party can submit information to the blockchain (that is to say, try to add information to the database), it is necessary for the distributed operators of the blockchain to evaluate and agree on all addenda before they are permanently incorporated into the blockchain (the database). Because we cannot be sure of the author’s trustworthiness, it is vital that all new information must be reviewed and confirmed before being accepted. This review results in the ‘consensus’ we are examining here.
There are four main methods of finding consensus in a blockchain (and all distributed systems, for that matter): the practical byzantine fault tolerance algorithm (PBFT), the proof-of-work algorithm(PoW) ,the proof-of-stake algorithm (PoS), and the delegated proof-of-stake algorithm (DPoS).
The Practical Byzantine Fault Tolerance Algorithm (PBFT)was designed as a solution to a problem presented in the form of an allegory (source):
Imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement. The generals must decide on when to attack the city, but they need a strong majority of their army to attack at the same time. The generals must have an algorithm to guarantee that (a) all loyal generals decide upon the same plan of action, and (b) a small number of traitors cannot cause the loyal generals to adopt a bad plan. The loyal generals will all do what the algorithm says they should, but the traitors may do anything they wish. The algorithm must guarantee condition (a) regardless of what the traitors do. The loyal generals should not only reach agreement, but should agree upon a reasonable plan.
To clarify the allegory for our purposes: the ‘generals’ in the story are the parties participating in the distributed network running the blockchain (database) in question. The messengers they are sending back and forth are the means of communication across the network on which the blockchain is running. The collective goal of the “loyal generals” is to decide whether or not to accept a piece of information submitted to the blockchain (database) as valid or not. A valid piece of information would be, in our allegory, a correct opportunity to decide in favor of attack. Loyal generals, for their part, are faithful blockchain participants, who are interested in ensuring the integrity of the blockchain (database) and therefore ensuring that only correct information is accepted. The trecherous generals, on the other hand, would be any party seeking to falsify information on the blockchain (the database). Their potential motives are myriad — it could be an individual seeking to spend a BitCoin that she does not actually own or another person who wants to get out of contractual obligations as outlined in a smart contract he already signed and submitted.
Making comparisons between currencies and blockchain systems is often a bad idea. Why? Because they’re different solutions to different problems. All systems are based on their own security models. If we’re talking about decentralized systems, and keep that ‘decentralized’ idea front of mind, then the most important thing that’s worth mentioning is consensus. People also often claim that one kind of consensus is better than another — but here, again, there are different solutions which fit different situations. Even so, it’s clear that within one kind, there could be better or worse options. There’s been very little written about when it’s better to deploy a particular kind of consensus — which helps foster the misconception that you can take bitcoin’s or Ethereum’s codebase — and just use it for your own use-case? And there’s even less written about how to classify kinds of consensus.
In practice, this leads to situations when someone plans designing a national digital currency, they use a bitcoin fork as the template . In this case it’s not clear who the miners are, or why we even need them.
Let’s look at a different example. Some people call Ripple a centralized blockchain. In fact they’re right, in the case of a specific company which controls the validators network — although wrong when referring to the underlying technology.
Another example is a case of ‘private blockchains’ that community doesn’t like. People say that they are centralized, insecure, don’t differ in any way from MySQL etc. Yet again, in the majority of cases this isn’t fair — it’s just that the system-builder never explained the security model, and critics didn’t dig deeper.
Since the early days after the introduction of proof of work (PoW) in Satoshi Nakamoto white paper, there were many searches for a better alternative consensus mechanism for distributed ledgers. And, most of the effort has been spent on trying a different proof of stake (PoS) variants. With the search, the definition of “better consensus” was gradually shifting. Initially, it was a higher energy efficiency, then this criterion was accompanied by a higher transactional throughput (scalability). A couple of solutions was proposed, from a basic PoS found in original NXT to more performant variants as a delegated PoS (dPoS) found in Graphene-based blockchains (Bitshares, Steem, and, probably, EOS).
These two solved the issue of energy efficiency (and, scalability, as for the former one), however instantly introduced a number of issues not found in the original Bitcoin PoW. Namely, these were new types of attacks possible for the usual PoS and issue of centralization in the dPoS consensus. Thus, when talking about different consensus algorithms, we need to define criteria used to evaluate them.
Criteria of consensus algorithm efficiency:
First, proper consensus must be secure, i.e. be able to tolerate multiple Byzantine faults (deviations from the protocol by some nodes). Such faults should not lead to double spending, or be used to introduce successful “nothing at stake” attacks (both long- and short-ranged), and do not give possibilities for manipulating randomness used in selecting block creation leader — and etc. All of that, according to the groundbreaking work on consensus formal verification, can be mathematically reduced to some sort of “measurable probability of blockchain forks” and ability for the consensus mechanism to control that probability.
Second, proper consensus must be sustainable in time, meaning that participating nodes had sufficient incentives to continue operating the protocol.
Third, the consensus incentives must correspond to a Nash equilibrium,meaning that there should be no deviations from the protocol that lead to a higher economic advantage than the following protocol — even under conditions of coalitions in the system (refined, coalition-proof Nash equilibrium). This rise the bar so high, that even Bitcoin itself can’t afford such level of the consensus efficiency.
Having said that, practically none of the existing PoS protocols passes such criteria. If we lower the bar for the third one down to the level of “just a Nash equilibrium” (similar to Bitcoin), we still will filter off “simple PoS”, dPoS, all consensuses inheriting DLS and PBFT-based protocols (like Tendermint, Polkadot, Casper etc), which cannot resist more than 1/3 of Byzantine-faulty nodes (while Bitcoin may resist up to 1/2). The only one left here will be a recently introduced Ouroboros — provable-secure PoS protocol, which also surpasses Bitcoin PoW in terms of energy efficiency and transactional scalability.
Decentralization to rule them all:
But all of these criteria (first part, related to efficiency, and the second one with security and incentives thresholds) are not the final barrier. To understand why it is so, we need to analyse what we believe are the main value introduced in practice by Bitcoin: censorship resistance. The source of the censorship resistance is not only consensus liveness and Byzantine fault resistance but also the decentralised nature of the protocol: censors are (arguably) rational agents able to act contrary to economic incentives (analyzed by Nash equilibriums) and they can correspond to the signification part of the network (even majority of the nodes or users). Thus, the presence of censorship resistance takes not only all mentioned criteria but also decentralised qualities of the network that have to be maintained by consensus protocol in time. So, the last criterion will be an ability of the consensus to keep decentralised state and resist centralisation over the long periods. And, while Bitcoin is being criticised for mining centralization, it is nothing comparing to the level of centralization that any existing PoS bring.
Stakes of Centralization:
Why is PoS more prone to centralize with a time than even PoW with ASICs?
In general, centralization comes from the simple fact that those who have money earn more money (due to inflation/block rewards and transaction fees), and those who do not have — do not earn. This will always eventually create the oligopoly. The common counterargument to this statement is “you can buy hashing power (for PoW) or stake (for PoS) and become new independent mining/minting actor” — but the argument lasts only while cryptocurrency cap is low and liquidity is abundant. Try to buy a master node for Dash (master node require stake) these days — and Dash is not even so popular like Bitcoin.
So both PoW and PoS tend to centralize, but PoS does that faster (again, look to a Dash using mixing PoW+PoS model to mine). This happens mainly because PoW means spendings on hardware and electricity, while PoS spendings to maintain minting process are much lower. Remember “energy efficiency” praise to PoS? Here is another side of this coin: faster centralization. PoW miners have to update hardware, spending the most of their rewards, while PoS does not require it to that scale.
Ouroboros ? No. Hybrid:
So is there any ray of hope for the world of crypto? Or are we all going to end up with more and more centralized cryptocurrencies?
A lot of research on how we can overcome the limitations of modern PoW and PoS consensusesis going on . PoW needs to spend energy for maintaining decentralised state but does that on a useless work (still required to generate trustless randomness for selecting blockchain leader block). PoS gave higher throughput, but lower Byzantine tolerance and higher trend to a centralisation of the coins. What if we cross-bred them? Putting randomness aside of the stake or work. Rewarding not stake but useful work. Scaling through different layers of blockchain architecture.
Divide and Conquer:
State channels (like in Lightning Network) running parallel computing of useful (paid-for) jobs (like AI), putting a stake to prove its correctness. They get mining rewards, but need to maintain hardware and pay for electricity (no centralisation). But these nodes (miners) do not produce blocks (so no scaling limitations).
Other nodes, doing arbitration for failed jobs, earn reputation — inalienable thing, that can’t be solved or transferred (but can be lost).
In sidechains and root chain these high-reputation nodes sign blocks, earning block rewards. But these rewards come for reputation, and not in any proportion to their stake/coins in ownership! Thus, no centralisation happens here as well. This “proof of reputation” can be thought as a form of PoS, but lacks its main drawback: stake centralisation; why have all of its positive sides (throughput, energy efficiency, speed etc). And it has much higher Byzantine fault tolerance because the most of the nodes monitor blocks and according to the protocol can prove faults of the miners leaving them without reputation and stakes and gaining their place instead.
So, by dividing and combining, we get a new level of both decentralization quality and scalability.
There are numerous consensus mechanisms as depicted in Fig 2 .
At this point we shall try to explain what issue is solved by each consensus — in the plainest language that can be mustered.
1. Multisignature/Byzantine Fault Tolerance (BFT):
These algorithms are primarily used for achieving consensus among a limited group of people (In the case of multisignature between few participants — or in the case of BFT, between dozens of them, most usually equals). It makes sense to use BFT when all the parties in the process know each other, and the list of them doesn’t change often. One example would be voting among the inhabitants of a building on collectively-organized repairs.
Various computer scientists have outline a number of potential solutions to the Byzantine generals problem from the allegory. The practical byzantine fault tolerance algorithm (PBFT), which is used to establish consensus in blockchain systems, is only one of those potential solutions. Three examples of blockchains that rely on the PBFT for conses are Hyperledger, Stellar, and Ripple. Very roughly and without explaining the whole algorithm , what the PBFT does is as follows: Each ‘general’ maintains an internal state (ongoing specific information or status). When a ‘general’ receives a message, they use the message in conjunction with their internal state to run a computation or operation. This computation in turn tells that individual ‘general’ what to think about the message in question. Then, after reaching his individual decision about the new message, that ‘general’ shares that decision with all the other ‘generals’ in the system. A consensus decision is determined based on the total decisions submitted by all generals.
Among other considerations, this method of establishing consensus requires less effort than other methods. However, it comes at the cost of anonymity on the system.
Federated Byzantine Agreement (FBA), which was first introduced by Ripple, and then formally proven by Stellar, permits reaching consensus among large numbers of participants who don’t know each other personally, and in situations when the total number of participants may not even be known. Each participant extends to trust to only a limited (by number) group of other participants, and therefore achieves consensus only amongst a narrow circle. However, since each of these circles has some element of overlap with others, it’s possible to achieve overall consensus. There are not, however, many examples of such situations in real life — models might include sowing the seeds of revolution, when people spread the word mouth-to-mouth, and infect others with their enthusiasm.
2. Proof of work (PoW) owes its popularity to cryptocurrencies, and is certainly the most complicated to explain. In PoW, all of the participants remain anonymous, don’t extend trust to each other, and their total number is unlimited/unknown.
Imagine if team of warriors, instead of fighting with each other for trophies after each battle are comparing their weapons — and decisions would be taken on the basis of the comparison. So to define who deserves trophies warriors are challenging a goal — let’s say a dragon. Whoever has the greater fire-power will win most often — and thus will most often will take the reward. All of the participants will be working on building up their strength before battles — and this can lead to an ‘arms race’. Obviously, it’s possible for a part or section of the participants to opt to leave entirely, and set up their own separate squad (in other words, a ‘fork’).
The best-known method of reaching consensus on a blockchain is the proof-of-work (PoW) scheme, which is used by Bitcoin. In contrast to the solution in the PBFT, PoW does not require all parties on the network (all nodes) to submit their individual conclusions in order for a consensus to be reached. Rather, PoW is a system which uses a ‘hash function’ to create conditions under which a single participant is permitted to announce their conclusions about the submitted information, and those conclusions can then be independently verified by all other system participants. False conclusions are prevented by the parameters of the hash function, which ensure that false information will fail to compute in an acceptable way. (For more information, follow me here, or subscribe down below.) In the Bitcoin system specifically, the participant who publicly verified the information on behalf of the network is in turn rewarded for its participation (which is costly in real terms of energy cost and computing resources) with newly created (’mined’) Bitcoins. Therefore this process of searching for valid ‘hashes’ (solutions to the ‘hash function’ created by the message input), is known as ‘mining’. Incentivizing participation in the network ensures broad participation, which in turn ensures a more robust network and a safer blockchain (database).
This Bitcoin-style PoW scheme allows for easy, broad participation, which in turn ensures greater network stability with minimal requirements on each participant, allowing participants to remain for example anonymous.
3. Proof of Stake (PoS) — voting by stake (or by percentage of ownership)
A third variation on establishing consensus on blockchain systems is extremely similar to the aforementioned PoW system, however participation in the consensus-building process is restricted to parties identified as having a legitimate stake in the blockchain (e.g. individuals who own bitcoins or entities who have smart contracts saved in the same blockchain database).
This is very similar to voting among shareholders in a company — whoever holds the largest slice of the pie will get the most say on how decisions are made. The specific quorum for achieving consensus can vary depending on the company. Some may require a simple majority (51%), others might demand a two-thirds majority, and there could even be those who require a unanimous 100%.
This third variation, called proof-of-stake (PoS) algorithms replace the hash function calculation with a simple digital signature which proves ownership of the stake. The network selects an individual to approve new messages (that is to say, confirm the validity of new information submitted to the databse) based on their proportional stake in the network. In other words, instead of any individual attempting to calculate a value in order to be chosen to establish a consensus point, the network itself runs a lottery to decide who will announce the results, and system participants are exclusively and automatically entered into that lottery in direct proportion to their total stake in the network. As in the PoW system run by Bitcoin, the PoS system run by organizations such as Peercoin also provides an incentive to participation, which ensures broadest possible network participation and therefore the most robust network security possible. In the Peercoin system, the chosen party is rewarded with a new Peercoin in a process called ‘minting’ (rather than BitCoin’s ‘mining’).
This system, however, by rewarding those who already are most deeply involved in the network inherently creates an increasingly centralized system. This is inimical to a truly robust network. Therefore proponents of PoS systems have put forward a number of various modifications to help ensure the base for their networks remain as broad (and therefore secure) as possible.
4. Other consensuses in the class are PoI (proof of importance) and DPoS (delegated proof of stake, when small-scale shareholders choose a delegate as their representatives).
The final method of establishing consensus is perhaps the most centralized, however it counteracts the large stake holder power that PoS systems entail and enables the system to work much more quickly. This method, called a delegated proof-of-stake (DPoS) system works along the same lines as the PoS system, except that individuals choose an overarching entity to represent their portion of stake in the system. So imagine, each individual decides if entity 1, 2, or 3 (these could be, for example, computer servers, and are called ‘delegate nodes’ within a DPoS system) will ‘represent’ his or her individual stake in the system. This allows individuals with smaller stakes to team up to magnify their representation, thereby creating a mechanism to help balance out the power of large stake holders. This comes at the cost, however of greater network centralization. Bitshares is one company that employs a DPoS system.
If we try to classify all these forms of consensus, there are two primary criteria (but there could perhaps be other ways of classifying them), and these are (i) the anonymity of each validator, and (ii) lever of trust to a specific validator (more thoughts here).
Now it would make sense to compare systems within groups. Of course, there will also be some subgroups — but at least there won’t be utter confusion. While these four systems for establishing consensus are currently the most dominant, the field is still wide open to innovation. As blockchain systems continue to gain in popularity, they will also continue to grow in scale and complexity. Which of these four consensus building systems (if any) is best equipped to handle this ongoing expansion remains to be seen. Currently, companies choose a system for their product that best meets their (or their customer’s) needs for speed, efficiency, and security.
It is important to note, these systems differ not only in the details of the formation of their respective consensus-building communities, but importantly they differ in how they would handle potential attacks. This is, in fact, one of the clearest distinguishing features between the four consensus-building systems: the potential size of an attack on the system that could be easily managed. To return to the Byzantine general analogy I opened with, that is to say, each of these four system can cope with a different proportion of ‘treacherous generals’ before it begins to make bad choices.
