Most of the blockchain frameworks like Ethereum are permission-less framework with no trust among the 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 where in different consensus technique can be plugged in as per the requirement.
Currently, Hyperledger Fabric uses Solo and Kafka to reach consensus, which require a node to validate a batch of transactions and add them as a new block to the blockchain.
- 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 production environment.
- Kafka – 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.
Consensus in Hyperledger Fabric Consists of Three Aspects That Includes:
More detailed explanation of the above three steps are mentioned in below transactional flow.
Transaction Flow for a Visual Representation of Consensus:
- Client application request a transaction.
- SDK application generates a transaction proposal and sends to endorsing peers.
- Endorsing peers verify:
- The transaction proposed is well in form
- Not submitted before
- Signature is valid
- The client is authorized to perform the concerned operation.
- The transaction proposal inputs as argument are passed to chaincode or smart contract and further to SDK application.
- The application verifies the signature and compares the proposal responses to be same.
- Application broadcast the transaction containing read/write sets and signature to ordering service.
- Ordering peers prepares 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.