Consensus in Hyperledger Fabric

Most of the blockchain frameworks like Ethereum are permission-less frameworks with no trust among their peers. Thus, in order to validate the transactions, there is a need for consensus algorithms like proof of work, proof of elapsed time in Ethereum.

Hyperledger Fabric on the other hand is a permissioned network with a certificate authority that onboards every node with a specific digital certificate. Thus, the purpose of consensus algorithms in Hyperledger Fabric is completely different. Hyperledger Fabric follows a modular approach wherein different consensus techniques can be plugged in as per the requirement.

Currently, Hyperledger Fabric uses Solo and Kafka to reach consensus, which requires a node to validate a batch of transactions and add them as a new block to the blockchain.

Consensus Properties

• Safety - 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.
• Liveliness - Each non-faulty node will eventually receive every submitted transaction.

Consensus Algorithm Used in Hyperledger Fabric

• Solo - It is a Hyperledger Fabric ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node. It is not used in the production environment.
• Kafka - In Kafka, only the leader does the ordering and only the in-sync replicas can be voted as a 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 an agreement in the case of malicious or faulty nodes.

Consensus in Hyperledger Fabric Consists of Three Aspects That Includes

• Endorsement
• Ordering
• Validation

A more detailed explanation of the above three steps is mentioned in below transactional flow.

Transaction Flow for a Visual Representation of Consensus

• The client application requests a transaction.
• SDK application generates a transaction proposal and sends it to endorsing peers.
• Endorsing peers verify:
  • The transaction proposed is well in the form.
  • Not submitted before.
  • The signature is valid.
  • The client is authorized to perform the concerned operation.
• The transaction proposal inputs as arguments are passed to chain code or smart contract and further to SDK application.
• The application verifies the signature and compares the proposal responses to be the same.
• Application broadcasts the transaction containing read/write sets and signature to order service.
• Ordering peers prepare the block and transmit it to all the peers.
• Each peer appends the block to the chain, and for each valid transaction, the write sets are committed to the database.

Consensus encompasses more than simply agreeing upon the order of transactions, and this differentiation is highlighted in Hyperledger Fabric through its fundamental role in the entire transaction flow, from proposal and endorsement to ordering, validation and commitment. In a nutshell, consensus is defined as the full-circle verification of the correctness of a set of transactions comprising a block.