Consensus Part 2: Three Algorithms for Not So Public Blockchains

0
831
consensus

In part 1 of this article, we looked at three algorithms commonly used in public blockchains to reach consensus amongst participating nodes. We have also previously talked about permissioned blockchains used by consortiums of companies for enterprise applications. Consensus protocols used in public blockchains, such as proof of work, are not necessarily the most suitable for these types of blockchains. Two reasons for this stand out:

  • Transaction confirmation is slow and unpredictable. Transactions will be included in blocks once a miner or validator decides to do so. This may take several seconds or minutes, depending on the blockchain. The reason for this is that public blockchains have to be optimized for scalability in terms of the number of nodes. Permissioned blockchains, however, often favor scalability in terms of transaction throughput.
  • Transaction Finality. We talk about transactions being confirmed when they are included in a block. In reality, block inclusion in systems, such as Bitcoin, may not be final. Proof of work and similar consensus protocols provide a probabilistic approach. The more blocks are added, the lower the chance a transaction is undone. This is why we are advised to wait for six confirmations before considering a Bitcoin transfer secure. Enterprise applications often require block finality, providing security that a transaction will not be undone.

In addition, consortium blockchains are less exposed to certain ways nodes may misbehave. Since participants have to be authenticated, are well-known, and have different motivations for the correct functioning of the system, certain protection mechanisms may be relaxed for some applications.

Therefore, there are a number of consensus algorithms optimized for permissioned blockchains. Let’s have a look at three common protocols.

Proof of Authority (PoA)

PoA is maybe the simplest consensus algorithm in use. It’s akin to a dictatorship, in that a number of nodes are “authorities” in charge of validating transactions. There is neither voting nor competition, the order and validity of transactions are simply imposed on the network by trusted nodes.

Image credit: Pexels

Although this may seem like no consensus at all, it can be surprisingly effective for some applications. There may be nodes in a consortium in which all participants trust and this trust may even have to be earned, as in a slight variation of the algorithm, Proof of Reputation.

All of this allows PoA to achieve consensus quickly.

Proof of Elapsed Time (PoET)

PoET is a protocol that chooses the generator of the next block randomly from a group of nodes based on a “sleep time.” Each node is assigned a random waiting period and the first node to reach the elapsed time gets to create the next node.

Image credit: Pixabay/nile

The algorithm was invented by Intel, which has specific trusted hardware to maintain fairness in the choice of random time periods and is used in the Hyperledger Sawtooth project.

As might be expected, PoET is similar to PoA, in terms of security and performance.

Practical Byzantine Fault Tolerance (PBFT)

Let’s move on to a real consensus protocol that can actually deal with misbehaving nodes. Surprisingly, the original PBFT protocol has been around for a long time, published in 1999, as a solution to Lamport’s famous Byzantine General Problem.

We will not go into detail of the problem nor the solution, but PBFT establishes a voting protocol based on a number of nodes participating in a finite state machine algorithm. The protocol is extremely fast, as long as the number of nodes is kept reasonably low. PBFT supports situations in less than one-third of the nodes are faulty or malicious.

Several adaptations are employed in current blockchain platforms, for example, the popular Istanbul BFT.

Final Thoughts

In this two-part article, we have only scratched the surface of consensus protocols. Many alternatives exist, and consensus is an active research field. The choice of protocol depends on the type of blockchain and application use case. As blockchain technology continues to grow, this area of the space will likely continue seeing innovation to achieve consensus.

  • Facebook
  • Twitter
  • Buffer
  • reddit
  • LinkedIn
Dr. Stefan Beyer

Dr. Stefan Beyer is editor-at-large at BlockTelegraph and a Blockchain consultant and smart contract auditor. He graduated from the University of Manchester in 2001 with a degree in Computer Science and obtained a Ph.D. in 2004 from the same university with the title “Dynamic Configuration of Embedded Operating Systems”. Since then he has worked in computer science research in distributed systems, fault tolerance, ubiquitous computing and cyber security. He is currently working as head of research and development for a medium-sized cyber security company in Spain.