Blockchain Consensus Algorithms: An Early Days Overview
That hooptie, my friends, is a Benz. What, you didn’t recognize it? Of course not. And that’s what the blockchain, or at least its consensus algorithms, looks like right now.
That’s right. It’s still early days for the blockchain and like that old Benz there are improvements to come before it looks like this:
This is particularly true of the blockchain’s consensus algorithm which is essential to how the blockchain functions and, by extension, its future.
When setting up your business on the blockchain there are numerous different consensus algorithms from which to choose. In previous posts we covered the Proof of Work consensus algorithm which is used on the Bitcoin blockchain and the Proof of Stake consensus algorithm.
But there are others to consider. Because it is early days what is here today may be gone tomorrow and the industry’s best practice may not even exist yet.
Here are a few other consensus algorithms that the “Blockchain for Business — An Introduction to Hyperledger Technologies” edX course briefly notes with some additional explanations.
Proof of Elapsed Time (PoET)
Here’s how the edX course describes PoET:
“Developed by Intel, the Proof of Elapsed Time consensus algorithm emulates the Bitcoin-style Proof of Work. Hyperledger’s Sawtooth implementation is an example of PoET at work. Instead of competing to solve the cryptographic challenge and mine the next block, as in the Bitcoin blockchain, the PoET consensus algorithm is a hybrid of a random lottery and first-come-first-serve basis. In PoET, each validator is given a random wait time…This ‘leader’ gets to create the next block on the chain.”
According to Amy Castor of Coindesk, the bonus of PoET is that it consumes far less electricity than Proof of Work. PoET also “uses a trusted execution environment (TEE)…to ensure blocks get produced in a random lottery fashion…”
The downside of PoET is that its users have to trust Intel. As Castor writes, “…and isn’t putting trust in third parties what we were trying to get away from with public blockchains?” Fair point.
Simplified Byzantine Fault Tolerance (SBFT)
Another consensus algorithm to consider is the SBFT. Here’s how the edX course describes it:
“The Simplified Byzantine Fault Tolerant consensus algorithm implements an adopted version of the Practical Byzantine Fault Tolerant (PBFT) algorithm, and seeks to provide significant improvements over Bitcoin’s Proof of Work consensus protocol. The basic idea involves a single validator who bundles proposed transactions and forms a new block. Note that, unlike the Bitcoin blockchain, the validator is a known party, given the permissioned nature of the ledger. Consensus is achieved as a result of a minimum number of other nodes in the network ratifying the new block. In order to be tolerant of a Byzantine fault, the number of nodes that must reach consensus is 2f+1 in a system containing 3f+1 nodes, where f is the number of faults in the system. For example, if we have 7 nodes in the system, then 5 of those nodes must agree if 2 of the nodes are acting in a faulty manner.”
This explanation assumes some knowledge and includes almost enough algebra to justify ninth grade math. To start, what is Byzantine fault tolerance? It goes back to what’s called the Byzantine Generals’ problem which is neither a problem solely for those in Byzantium or generals. Rather, it’s a communication problem that many of us still deal with when planning group events like weddings, meals, or votes in Congress. That is, can we get everyone to agree and to move forward in that agreement or are not all votes genuine or trusted? Here’s a more detailed description of the Byzantine Generals’ Problem:
“…a group of generals, each commanding a portion of the Byzantine army, encircle a city. These generals wish to formulate a plan for attacking the city. In its simplest form, the generals must only decide whether to attack or retreat. Some generals may prefer to attack, while others prefer to retreat. The important thing is that every general agrees on a common decision, for a halfhearted attack by a few generals would become a rout and be worse than a coordinated attack or a coordinated retreat.
“The problem is complicated by the presence of traitorous generals who may not only cast a vote for a sub-optimal strategy, they may do so selectively. For instance, if nine generals are voting, four of whom support attacking while four others are in favor of retreat, the ninth general may send a vote of retreat to those generals in favor of retreat, and a vote of attack to the rest. Those who received a retreat vote from the ninth general will retreat, while the rest will attack (which may not go well for the attackers). The problem is complicated further by the generals being physically separated and having to send their votes via messengers who may fail to deliver votes or may forge false votes.”
That’s how it worked in medieval times. But, I can hear you saying, today we have cellphones, SMS, and emoji! This is no longer a problem! Oh, but it is. Here’s an updated analogy for today:
“The typical mapping of this story onto computer systems is that the computers are the generals and their digital communication system links are the messengers.”
In other words, whether we are talking medieval messengers or digital communication systems, both have the potential to be faulty and both require a system to account for potential faultiness.
So is SBFT the perfect consensus algorithm system? Unfortunately, it too has its flaws. “Although the problem is formulated in the analogy as a decision-making and security problem, in electronics, it cannot be solved simply by cryptographic digital signatures, because failures like incorrect voltages can simply propagate through the encryption process. Thus, a component may appear functioning to one component and faulty to another, which prevents forming a consensus if the component is faulty or not.”
That being said, “Byzantine fault tolerance mechanisms use components that repeat an incoming message (or just its signature) to other recipients of that incoming message. All these mechanisms make the assumption that the act of repeating a message blocks the propagation of Byzantine symptoms. For systems that have a high degree of safety or security criticality, these assumptions must be proven to be true to an acceptable level of fault coverage. When providing proof through testing, one difficulty is creating a sufficiently wide range of signals with Byzantine symptoms.[35] Such testing likely will require specialized fault injectors.[36][37]”
In other words, how many times does one computer have to send a message to another computer to make sure that the message got through without being accidentally or intentionally interrupted? This is another way of saying, SBFT is susceptible to being hacked or acting erroneously. These are important factors to consider when choosing a consensus algorithm.
Proof of Authority (PoA)
And lastly, here’s how the edX course describes the PoA consensus algorithm:
“Proof-of-Authority (PoA) is a consensus algorithm which can be used for permissioned ledgers. It uses a set of ‘authorities’, which are designated nodes that are allowed to create new blocks and secure the ledger. Ledgers using PoA require sign-off by a majority of authorities in order for a block to be created.”
What the course neglects to mention is that there isn’t just one one kind of PoA consensus algorithm. As there are more than one kind of consensus algorithm, there are more than one kind of Proof of Authority consensus algorithm.
Also, unlike a public blockchain that is open to all users, a permissioned blockchain is only used by a set number of users. And, unless I misunderstand how PoA works, configuring which nodes are ‘authorities’ could become political. If I own one authorized node and you own another, but we need one more authorized node to form a majority, you might not like it if I authorize my dog’s node as the chances are my dog will side with me more than it will with you.
General Thoughts
As I noted at the beginning of this post, there are currently many different consensus algorithms out there as it is early days for the blockchain. Hopefully, in time, a few highly efficient and trustworthy best practices will come to the fore.
Till then, individuals and organizations that want to build on the blockchain will have to consider these consensus algorithm options, their pros and cons, and what their risk tolerance is.
Lastly, these are just the consensus algorithms that the edX course mentions. There are more. I won’t get into them now, but I look forward to doing a piece in the future when we all have a clearer idea of what’s real, what’s good, and what works.
Follow for more
For more posts about the Blockchain for Business — An Introduction to Hyperledger edX course, the Hyperledger blockchain, and the blockchain in general, follow me to get the latest.
