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.

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.

Figure 1: Leslie Lamport's “Byzantine Generals Problem

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?
This will be part of my next post on blockchain.