Proof-of-Work is not a Consensus Protocol: Understanding the Basics of Blockchain Consensus
Blockchain and distributed computing are complex technologies consisting of a number of layers. Few people understand the underlying cryptography and distributed algorithms in details. And, to be honest, that’s fine. The nature of specialization means that different experts concentrate on different layers and the end-results should fit together nicely through agreed interfaces.
However, when it comes to consensus protocols, there are a number of half-truth and myth that need to be addressed. Understanding consensus is a pre-requisite for choosing the right blockchain platform and configuration for an application. Making the wrong choice can lead to inefficient and insecure setups.
Here are a number of incorrect statements about blockchain consensus that are repeated frequently:
- “Proof-of-Work is a consensus protocol.”
- “Blockchain consensus is secure as long no-one can control more than 50 % of the network.”
- “Blockchain consensus is inefficient and energy-consuming.”
- “Bitcoin was first in solving consensus in byzantine environments.”
So, let’s have a closer look at consensus and clear up some misunderstandings.
The Two Steps of Blockchain Consensus
Consensus protocols solve a classic problem in Computer Science: How can a number of equal participants agree on a global view of events? In blockchain terms, this means, agreeing on a specific order in which transactions are processed. The goal of blockchain consensus is to maintain the exact same copy of the history on all nodes.
In a centralized system, solving this issue is easy: a central coordinator can simply impose the transaction order. In a distributed system this is not possible, and a more complex mechanism is required.
The process for adding to the ledger in Blockchains consist of appending a new block to the distributed data structure. This involves two main steps, each with their own choice of algorithms: selection of the block proposer and consensus on the inclusion of the proposed block. The former involves deciding which node gets to generate the next block, the latter focuses on whether or not a new block is accepted into the blockchain data structure. Both steps are equally important and entirely different.
Block Proposer Selection Algorithms
The easiest way to choose the next block producer would simply be taking turns or choosing the next block producer randomly. In fact, taking turns is a very good choice in situations with a fixed number of authorized participants. This is usually the case of permissioned consortium blockchain used in enterprise setups.
However, such a scheme does not work in public blockchains, in which anyone can participate freely, such as Bitcoin or the public Ethereum network. Just like in a lottery, participants could just improve their chances significantly by obtaining a large number of tickets. If tickets were free or very cheap this could lead to the system being gamed. Such a scenario is known as a Sybil attack. Therefore a mechanism is required to attach an economic difficulty to the act of obtaining a ticket.
Proof-of-Work (PoW) is such a mechanism. So-called “mining” attaches a cost to participating in the block producer selection algorithm. It is okay for participants to obtain a lot of tickets, but they have to pay for improving their chances with computing power. Therefore, PoW is not a consensus algorithm at all, it is merely a Sybil-resistant tool for selecting the next block producer. This is important to understand, as PoW can be combined with a number of consensus algorithms. In fact, as we will find out in the next section, Bitcoin’s consensus algorithm is extremely simple and provides very weak guarantees.
Proof-of-stake (PoS) is a similar tool for selecting the next block producer. In this case, computing power is simply eliminated and economic wealth is taken to weight the lottery probabilities, based on the observation that computing power relies on economic power. The obvious advantage is the reduction in energy consumption that is associated with PoW.
Consensus Algorithms
The actual consensus algorithm in a blockchain system is executed after a block has been proposed by the chosen block producer. Participants have to reach an agreement on whether to include a block or not. Bitcoin and similar blockchains, including Ethereum, don’t really execute any particular algorithm to reach such an agreement. Instead, they choose a hands-off approach which simply allows temporary disagreements and establish a rule that the strongest chain wins, meaning the chain supported by the majority of the network’s computing power. Temporary forks are accepted and are indeed quite common. This form of consensus is sometimes termed Nakamoto consensus and has far-reaching consequences on the guarantees that can be provided by the network, as we will see in the next section.
Even before the invention of Bitcoin and blockchain systems, researchers in distributed systems had developed a number of consensus protocols that work quite differently. BFT consensus protocols execute a number of communication rounds between the participants of the network to vote on the inclusion of a block and reach a firm agreement.
It has been mathematically proven that this type of protocol can keep operating correctly as long as less than one-third of the participants act maliciously. The disadvantage of BFT consensus is that it scales badly, due to the communication overhead involved. For this reason, this type of protocol is mainly used in situations where the number of validators is limited and known in advance, such as in consortium blockchains or Proof-of-Authority chains (chains with a small number of authorized block producers).
Blockchain implementations of BFT consensus protocols include Istanbul BFT and Tendermint. In fact, the recent popularity of BFT consensus adapted to blockchain systems has led to renewed research interest in this classic field. Examples include the recent work on BFT consensus optimization by Sikoba Research.
Finality
The difference between Nakamoto consensus and BFT consensus affects finality. Finality relates to the guarantees that can be given on a block, and in consequence, the transactions within a block, being indefinitely included in the chain. Essentially, strong finality means the block will not be rejected in the future, resulting in the transactions being undone.
Nakamoto consensus only provides probabilistic finality. This means that the probability of a block being final increases with every additional block added to the chain but never reaches theoretical certainty. In Bitcoin, for example, we are generally advised to wait for 6 additional blocks for a transaction included in a block to be considered confirmed. This means that on average, a Bitcoin transaction is considered safe after approximately one hour, due to practicality-based heuristics, rather than strong protocol guarantees.
In contrast, BFT consensus protocols with voting rounds provide strong guarantees. Once a block has been voted to be included by a two-thirds majority, transactions can be considered safe. This means that blockchains using such a protocol can be much more agile and can provide transaction finality in a very short timeframe. However, as mentioned above, BFT consensus is only practically achievable with a relatively small number of validators (think hundreds, rather than thousands).
Finality also becomes important in blockchain interoperability and sharding solutions. The former focuses on interactions between different blockchains, the latter refers to splitting a blockchain up into smaller chunks for scalability reasons. In either case, communication has to happen across different chains. It would be very inconvenient for a transaction to be undone on one chain after it has already been transferred to other chains. A partial fix for this problem can be found in so-called finality gadgets, which layer a stronger finality layer on top of weaker consensus protocols. Casper FFG and GRANDPA are examples of such finality gadgets.
Delegated Proof-of-Stake
A very interesting and also often misunderstood compromise solution to blockchain consensus is Delegated Proof-of-Stake (dPoS). The dPoS approach uses a staking token as a voting mechanism to elect a reduced and fixed number of validators that execute a consensus protocol.
The implications of this are that block producer selection between the delegates can be simplified (at the expense of having to deal with delegate voting) and that the smaller set of validators can execute a very efficient consensus protocol. This means that dPoS can be used to combine the advantages of public blockchains and BFT consensus, bringing almost instant finality to open networks, in which all participants can participate to some degree.
Security in dPoS blockchain is the subject of ongoing research and is very closely linked to governance. Essentially, the challenge is to ensure that the voting of delegates is fair and mechanisms to prevent cartel formations are in place. It is important to note that dPoS should be seen as a configurable trade-off between decentralization and performance. On the extreme end of the spectrum, EOS reduces the number of validators to just 21 nodes to provide a very fast platform. Other systems, such as the recently launched Cosmos hub, place a lot of emphasis on security and try to achieve true decentralization.
Of course, cartel formation and centralization are real risks with dPoS. On the other hand, can PoW dominated by a handful of mining pools (located in places where electricity is cheap) be considered decentralized?
Conclusion
Consensus is not as straightforward as it appears. As with anything in Computer Science, trade-offs have to be made and there is no one ideal solution. While it is impossible for everyone to understand all the technical nuances of different consensus protocols, it is important to understand the basics of consensus before choosing a blockchain platform for a given application. This is particularly important in the face of the amount of misinformation and myths that have been published regarding the subject.
Are you building a blockchain-based application? Contact us, if you wish to speak about security or any other blockchain related topic.
