The Ultimate Guide to Consensus in Hyperledger Fabric

What is a Consensus algorithm?

In general, a consensus algorithm is a process in computer science used to achieve agreement on a single data value among distributed processes or systems. Consensus algorithms are designed to achieve reliability in a network involving multiple unreliable nodes. Solving that issue – known as the consensus problem – is important in distributed computing and multi-agent systems.

Consensus in Hyperledger Fabric

The consensus in Hyperledger Fabric network is a process where the nodes in the network provide a guaranteed ordering of the transaction and validating those block of transactions that need to be committed to the ledger. Consensus must ensure the following in the network:

• Confirms the correctness of all transactions in a proposed block, according to endorsement and consensus policies.

• Agrees on order and correctness and hence on results of execution (implies agreement on global state).

• Interfaces and depends on smart-contract layer to verify correctness of an ordered set of transactions in a block.

Consensus Properties

Consensus must satisfy two properties to guarantee agreement among nodes: safety and liveness.

Safety means that each node is guaranteed the same sequence of inputs and results in the same output on each node. When the nodes receive an identical series of transactions, the same state changes will occur on each node. The algorithm must behave identical to a single node system that executes each transaction atomically one at a time.

Liveness means that each non-faulty node will eventually receive every submitted transaction, assuming that communication does not fail.

The voting-based Consensus

There are two main types of Consensus. Hyperledger makes use of the permissioned voting-based consensus from the pool of other consensus named the lottery-based consensus. The operating assumption for Hyperledger developers is that business blockchain networks will operate in an environment of partial trust. Thus, the voting-based algorithms are advantageous in that they provide low-latency finality. When a majority of nodes validates a transaction or block, consensus exists and finality occurs. Because voting-based algorithms typically require nodes to transfer messages to each of the other nodes on the network, the more nodes that exist on the network, the more time it takes to reach consensus. This results in a trade-off between scalability and speed.

Consensus in Hyperledger Fabric is broken out into 3 phases: Endorsement, Ordering, and Validation.

• Endorsement is driven by policy (m out of n signatures) upon which participants endorse a transaction.
• Ordering phase will get the endorsed transaction and agrees to the orgder to be committed to the ledger.
• Validation takes a block of ordered transactions and validates the correctness of the result.

TRANSACTION FLOW IN HYPERLEDGER FABRIC

Multiple ordering plugins are being developed currently, including BFT Smart, Simplified Byzantine Fault Tolerance (SBFT), Honey Badger of BFT, etc. For Fabric v1, Apache Kafka is provided out-of-the-box as a reference implementation. The application use-cases and its fault tolerance model should determine which plugin to use.

Byzantine Fault Tolerance

In a blockchain network, every non-malicious entity has the same blockchain state. The implication for Hyperledger Fabric is that the orderer service should be jointly controlled by the network's members using a BFT algorithm that resists malicious activities by bad actors. It's insufficient for one organization to control the orderer, because that organization itself may not be trustworthy. After all, one of the motivations to use blockchain is so that organizations can cooperate while only partially trusting one another.

Kafka in Hyperledger Fabric Ordering Service

In Kafka, only the leader does the ordering and only the in-sync replicas can be voted as leader. This provides crash fault-tolerance and finality happens in a matter of seconds. While Kafka is crash fault tolerant, it is not Byzantine fault tolerant, which prevents the system from reaching agreement in the case of malicious or faulty nodes.

In addition to the multitude of endorsement, validity and versioning checks that take place, there are also ongoing identity verifications happening in all directions of the transaction flow. Access control lists are implemented on hierarchal layers of the network (ordering service down to channels), and payloads are repeatedly signed, verified and authenticated as a transaction proposal passes through the different architectural components. To conclude, consensus is not merely limited to the agreed upon order of a batch of transactions, but rather, it is an overarching characterization that is achieved as a byproduct of the ongoing verifications that take place during a transaction's journey from proposal to commitment.