Key Factors to Consider When Choosing a Blockchain Consensus Protocol
DISCLAIMER: In October 2020 PegaSys was renamed to Quorum.
This post was authored by David Hyland-Wood, with input from Roberto Saltini, Franck Cassez, and Joanne Fuller.
A blockchain consultant walks into a conference room. “Can you give us a blockchain?” she is asked.
“Sure. What kind do you want?”
The conversation immediately stops. The customer often has little or no idea. Worse, they may have a firm opinion about using a particular blockchain that will not satisfy their business requirements. Consulting can be hard.
The current array of blockchain choices is overwhelming. Do you want to use one of the public blockchains such as Bitcoin, Ethereum, Ethereum Classic, Dfinity? Do you want to build an enterprise blockchain using blockchain clients such as Hyperledger Besu, Quorum, or Dragonchain? Do you want a digital identity platform such as Veres One? Maybe your business requirements will encourage you to use a distributed ledger technology that is not quite what most would call a blockchain, such as Hyperledger Fabric or Ripple.
To make matters worse, many blockchain clients support multiple algorithms to establish consensus on the next block to add to the chain. The Blockchain Consensus Encyclopedia lists 77 consensus protocols, which illustrates just how much experimentation the industry is currently doing. Many more consensus protocols exist that are not yet listed.
Choosing a blockchain consensus protocol is a challenge in managing complexity. This post can help you navigate the evolving landscape.
At the highest level, the steps you need to take are:
- Choose a blockchain type
- Limit your choices of blockchains
- Finally, choose a consensus algorithm
Karl Würst and Arthur Gervais gave us a nice guide to Step 1 in their short paper Do you need a blockchain? Their useful flowchart is shown below in Figure 1. Financial services companies and many other enterprises choose the path outlined in red, ending up with a private, permissioned blockchain. A blockchain is “private” if it is operated by an organisation or consortium that does not want the public to view their transactions on the Internet, and “permissioned” if it requires user accounts and can assign different permissions to those users.
Step 2 is to limit your choice of blockchains. If you choose a private, permissioned blockchain for enterprise use, you might reasonably choose to use a blockchain that complies with the relatively new Enterprise Ethereum Client Specification from the Enterprise Ethereum Alliance. Enterprise Ethereum is, as its name suggests, a vendor-neutral specification that dictates how an Ethereum blockchain client can be made to satisfy common enterprise business requirements.
Kaleido offers to help you set up three types of Ethereum blockchain clients on the Amazon Web Services or Microsoft Azure cloud networks: Geth (the original Ethereum client), Quorum from JP Morgan, or Hyperledger Besu originally built by PegaSys.
It is finally time for Step 3. Which of the several consensus protocols should you choose? Naturally, there is no single answer to that question. The one you choose should be the one that best satisfies your business requirements.
Here are some of the many factors that can go into a consensus protocol choice:
- How fast do blocks need to be written to the chain? Consensus formation takes some time; the faster the consensus, the less the trust guarantees (and vice versa). This classic engineering trade-off is at the heart of consensus algorithms.
- What kind of network do you have? (e.g. Can it guarantee message delivery within a known time-bound (i.e. it is synchronous)? Does it guarantee message delivery but the time-bound is unknown(i.e. it is partially synchronous)? Is message delivery guaranteed only after an initial period where messages may be lost (i.e. eventually synchronous)? Or is message delivery not guaranteed at all (i.e. asynchronous)?. The Internet does not itself guarantee message delivery and is generally considered to be eventually synchronous.
- How many miners, writers, or validators do you anticipate needing? These special blockchain nodes are the ones which will select blocks to write to the chain.
- How “final” does a block need to be? Banks and other financial institutions most often expect any transactions to be immediately final (that is, they cannot be rolled back). Some consensus protocols treat block decisions to be conditional on future actions (as with Bitcoin and the public Ethereum mainnet). In others, blocks may eventually be final but are not immediately so.
- How much do you trust the nodes/operators? Are you trying to protect your blockchain from nodes that might crash, nodes that might actively attempt to hack the blockchain, or both?
In practice, existing enterprise blockchain users are less concerned about how fast blocks are written to a chain. This is partially self-selecting as users are limiting themselves to the capabilities of the technology. Some are demanding higher throughput in block creation, which is driving work in consensus protocols.
Network types vary greatly. Expensive high-speed networks within a single data center may be reliable and even synchronous, whereas those transacting across the Internet will have a very different set of expectations.
Similarly, the expectation of the number of miners, writers, or validators on a blockchain will vary greatly with exact business requirements. Existing enterprise users seem to expect each member of a business consortium to operate at least one such node in order to be deemed fully participatory. This can be a limitation on the consensus protocol choice in practice because the message traffic between such nodes often grows quadratically; too many nodes can slow a blockchain to a halt. Limiting the number of miners, writers, or validators is often necessary.
Regulatory requirements placed upon banks and other financial institutions have driven an expectation that enterprise blockchains should implement immediate block finality (also called settlement finality in the financial industry).
The last consideration is one of the most important: How much do you trust the nodes and their operators? If you want a blockchain that can stand up against a concerted attack by some of its own nodes (as the large public blockchains do), this is known as being Byzantine fault-tolerant (BFT) after the philosophical thought experiment called the Byzantine Generals Problem.
We can now summarize the consensus protocols offered by Geth, Quorum, and Besu to see how they compare against the above criteria. The consensus protocols implemented by all three enterprise blockchain clients are shown in Table 1.
Table 1. Some Enterprise Ethereum clients and their consensus protocols
Clique and Raft offer relatively simple and quick consensus in a trusting network environment. Neither is Byzantine fault tolerant.
You might select Clique if you specifically wanted to use Geth as a blockchain client, or if you wanted to create a heterogenous blockchain that could use a mixture of the Geth and Besu clients.
You might select Raft if you specifically wanted to use the Quorum client, or if you wanted a slightly faster consensus formation on a trusting network than IBFT would provide.
IBFT and IBFT 2.0 are Byzantine fault tolerant (the “I” stands for Istanbul, a play on the Byzantium reference that is otherwise meaningless). That is, they can continue to operate in a blockchain where up to one third of the nodes are doing something nasty, such as crashing or actively attempting to stop consensus formation.
IBFT 2.0 is a newer version of IBFT that strengthens the conditions under which it can put up with bad nodes, and allows it to be safely used on eventually synchronous networks. PegaSys implemented IBFT 2.0 in Besu to produce a more stable and reliable Enterprise Ethereum client. You would choose IBFT 2.0 if you have any concerns about the network or the cybersecurity of the various node operators
This post was a very brief introduction to the complexities inherent in blockchain consensus protocol selection. Hopefully it gave you a feel for the decision-making process, and may have even guided those of you using an Enterprise Ethereum blockchain. If you’re interested in using Hyperledger Besu or PegaSys Plus, reach out to us!
