Trust your competitor? How you can do that with a Hyperledger Fabric blockchain.
How can customers, suppliers, and competitors operating on a shared private blockchain network arrive at consensus about transactions? Why would they trust each other without a trusted middle-man? The consensus mechanisms used in Hyperledger Fabric provide some answers to these questions.
Unlike Bitcoin and Ethereum, Hyplerledger Fabric is a private permissioned blockchain framework for business use-cases. In such a blockchain a limited number of known nodes transact with each other. Often these nodes belong to companies with competing interests, such as suppliers and customers, or even competitors.
Recently such partners have started to form industry consortia in order to find out what blockchain technology can do for them. These consortia aim to save costs currently spent on trusted middle-men such as banks, clearing houses, or notaries. To cut those middle-men out, they want to process value transactions on a private permissioned blockchain. For more info why Hyperledger Fabric is considered a private permissioned blockchain, see here. For a short explanation video of how Hyperledger Fabric cuts out middle-men in practice, see here.
Hyperledger Fabric provides such industry consortia with an open-source blockchain framework they can tailor to their needs. However, in order to truly realize trust in such a system, arriving at consensus about transactions is highly critical. Thus, in the following, we will focus on the consensus mechanisms used by the Hyperledger Fabric framework.
Modularity
The Hyperledger Fabric project believes in the concept of modularity. Since its goal is to provide a platform template that can be tailored to use-case-specific requirements, different consensus mechanisms can be chosen for a private permissioned blockchain. Among those consensus mechanisms there are two main distinctions, namely Fault-tolerant consensus mechanisms and Byzantine-Fault-tolerant mechanisms. What does that mean?
Fault-tolerance (FT)
In a decentralized system, there are usually many nodes in a network. The system depends on the functioning of these nodes. Some systems completely break down, in case only a single node fails — for instance when it goes offline due to a power shortage. Such systems are NON-fault-tolerant. In contrast, a system that continues operating, despite single nodes failing, is considered Fault-tolerant.
However, a Fault-tolerant system does not ensure to function correctly in case a malicious node inserts faulty transactions. In such a case, nodes in the system would not be able to reach consensus about the system state. Consequently, the system would fail.
For example, a car-salesman could send a transaction allocating the ownership of a new car to the node of the customer {Car1; Node A}.
However, at the same time, the car-salesman would send a transaction allocating the ownership of the same car to himself to all other nodes in the network {Car1; Node D}. Thus, the car-salesman would send conflicting messages.
A Fault-tolerant system could not process such conflicting messages and would fail (e.g. stop working at all). In order to accept such malicious behavior and still arrive at consensus about the system state, the system would need to be Byzantine-Fault-tolerant.
Byzantine-Fault-tolerance (BFT)
Byzantine-Fault-tolerance is based on Leslie Lamport’s “Byzantine Generals Problem”. In a system of commander and lieutenants messages are exchanged about the battle strategy. Only if both lieutenants attack, they will win the battle. If only one attacks, he will loose. If both retreat, it’s fine as well, as both will survive.
In Fig. 1, the greyed out lieutenant 2 is the malicious node in the system. He tells lieutenant 1 that the commander told him to “retreat”. Thus, he passes on a faulty message. The same is the case in Fig. 2 where the commander is the faulty node.
Now, in a Byzantine-Fault-tolerant system, the system would still be able to function properly, although there are malicious nodes present that sent conflicting messages.
Consensus is usually achieved by exchanging many messages among all nodes and voting for the majority result. To continue the car-salesman example, a Byzantine-Fault-tolerant algorithm could tell nodes A, B, and C (similar to lieutenants) to exchange messages to tell each other what they “heard” from the salesman. Then they would accept the majority of messages they received. Consequently, all nodes could come to consensus that the car does not leave ownership. Even the customer (node A) would come to this conclusion, although the salesman tried to fool him. Thus, he would not transfer money.
Sounds great right? All problems solved? Not quite. As always, there are limitations to such a BFT-consensus algorithm.
The first one is that a Byzantine-Fault-tolerant consensus algorithm only works (creates consensus) as long as the number of malicious nodes is below the safety threshold of 1/3. In case 1/3 or more of all the nodes in the system are malicious, a BFT-consensus algorithm would not be able to create consensus among all nodes. Thus, a BFT-consensus algorithm could not create consensus in the example of the lieutenants and the general as the general represents 1/3 of all nodes.
The second limitation is the processing times of messages. As illustrated in the above example, a BFT-consensus algorithm requires intensive messaging and encryption between nodes in the network. The amount of messaging needed increases exponentially with the number of nodes in the network. This can result in long waiting times to validate transactions and is not efficient for larger networks with more than 20 nodes.
Now, how is this theoretical background put into practice by Hyperledger Fabric?
A range of consensus mechanisms
Now, back to Hyperledger Fabric. The Hyperledger Fabric framework is modular and provides the integration of different consensus mechanisms. These range from Fault-tolerant-mechanisms to Byzantine-Fault-tolerant-mechanisms. Industry consortia can choose which ones they prefer and thus tailor “their” Hyperledger Fabric blockchain to their specific needs.
But why would someone use a FT-mechanism when he can use BFT-mechanisms?
As everything related to consensus, BFT comes at a price. The price is transaction throughput. Namely, in order to ensure BFT, nodes in a system have to exchange high numbers of encrypted signatures and messages. This can slow down the processing of transactions.
Thus, if a system needs to process a very high number of transactions (>1000 tx/sec) and involves many nodes (>20), it currently cannot use BFT consensus mechanisms, but has to rely on FT consensus mechanisms.
The Kafka orderer
Hyperledger Fabric leaves this choice to the user. Out-of-the-box it comes with a FT mechanism, a so called centralized Kafka orderer. This orderer can efficiently order high numbers of transactions. It is composed of multiple virtual nodes forming a so called “Kafka cluster”. This decentralization makes the Kafka orderer tolerant to the failure of single nodes (e.g. through power shortages, software failures). Therefore it is considered Fault-tolerant.
However, the Kafka orderer is not Byzantine-Fault-tolerant as it can be compromised by a malicious node in the network. Consequently, a secure computing environment is necessary, both digital and physical security, as the orderer becomes a central point of weakness.
Why should I use such an orderer?
Such an orderer is sufficient if you have a Hyperledger Fabric blockchain and transact mostly in private channels with only a couple known participants, rather than in the main channel involving more participants. In such a setup the risk that single nodes in private channels will act maliciously is minimized.
Also if you need very high transaction throughput, >1000 tx/sec, a FT-tolerant consensus algorithm is preferable, as explained above.
However, in other set-ups, you might want to ensure that the system continues to work properly even if malicious nodes are present. Thus, you would want Byzantine-Fault-tolerant consensus mechanisms.
Pluggable BFT-consensus mechanisms
For BFT, Hyperledger Fabric does currently not provide its own BFT-algorithm. Rather users can integrate one of various existing BFT-protocols. To name a few, users could choose Practical-Byzantine-Fault-Tolerance, Tendermint, BFT-SMaRT, or Honey Badger.
All of these ensure the system keeps working as long as malicious nodes in the network do not exceed the safety threshold of 1/3. BFT-algorithms however, come at the expense of transaction throughput. Thus, for systems that need only a low number of transactions, <1000 tx/sec, and have few nodes (<20) in the network, BFT-algorithms can do the work efficiently.
But, how does Hyperledger Fabric scale then? Can it scale at all? To find out more about these questions, see here.
To see an overview of all articles, go here.
