Aside from the Proof of Work and Proof of Stake blockchain consensus algorithms, there are others to consider. Needless to say, it is early days not only for the blockchain, but for its consensus algorithms. In other words, 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)
Here's how the edX course describes SBFT:
"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.
The practical example would be that of ByzCoin, which seeks to make key improvements over the original Bitcoin protocol. Addressing the challenge around scalability due to high latency, ByzCoin transactions are irreversibly committed to the blockchain within seconds. The added advantage is the communication trees to '(...) optimize transaction commitments and verification under normal operations.' (2016 Kudelski Security report).”
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 who are 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? But here's a more detailed description of the Byzantine Generals' Problem:
"Byzantine refers to the Byzantine Generals' Problem, an agreement problem (described by Leslie Lamport, Robert Shostak and Marshall Pease in their 1982 paper, "The Byzantine Generals Problem")[1] in which 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.
"Byzantine fault tolerance can be achieved if the loyal (non-faulty) generals have a majority agreement on their strategy. Note that there can be a default vote value given to missing messages. For example, missing messages can be given the value <Null>. Further, if the agreement is that the <Null> votes are in the majority, a pre-assigned default strategy can be used (e.g., retreat).
"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.”
So is this 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 asking, how susceptible is SBFT 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 is no 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 sister's node as the chances are my sister will side with me more than she 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 leading practices will come to the fore. Till then, individuals and organizations that want to build on the blockchain will have to think about all these consensus algorithm options and which is the best for them.
Lastly, these are just the consensus algorithms that the course mentions. There are more. I won't get into it 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.
Comments
Post a Comment