Consensus of Hyperledger Fabric

Question

I'm new with Hyperledger Fabric. I'm reading with the document of Fabric latest version, but I'm not clear with consensus of Fabric. What is the consensus that Fabric used? And how does it work? Please explain.

Answer 1

I am assuming that you know the basics of consensus in the Blockchain context. Hyperledger Fabric's consensus can be treated as a special case of the same, may be a power-packed one. It kind of checks the transaction during multiple phases to ensure the permission, order and correctness of changes which are getting written to ledger.

In Fabric, when you are executing a transaction, if not in error, you would want this transaction to commit to the ledger, ie, to write the transaction into a block in the ledger in the right order. And then the same to be consistently synchronized across all participants in the network, through a collaborative process. So this process which ensures correctness in order and data synchronization - is called consensus

HLF Standard definition is

The process of keeping the ledger transactions synchronized across the network – to ensure that ledgers update only when transactions are approved by the appropriate participants, and that when ledgers do update, they update with the same transactions in the same order – is called consensus

This is done across the entire transaction cycle in the following ways

1. When you are submitting the transactions, i.e, when you invoke a function in the smart contract, the Client SDK which you are using has to send that transaction proposal to the endorsers ( specific to that smart contract in the specific channel ) This transaction proposal is takes the user’s cryptographic credentials to produce a unique signature
2. Endorsing peers do their share of checks, like proposal is valid, user who has attempted the transaction has the privilege for the same in that channel etc . And then they would simulate the transaction - and creates a response and R/W set. This is sent as proposal response which comes back to SDK.
3. SDK accumulates them and checks them and then sends them out to the orderer. Orderer will order the transaction as per time and creates a block and sends the block out to all the peers in the relevant channel
4. Peers who receive the block starts inspecting each transaction in the block (using Validation System Chaincode), to see endorsement is done for all of them & r/w set is proper ( MVCC check). Depending on the checks, the transactions may be marked valid or invalid

So once all the checks are ok, the transaction is marked valid and current state is updated, and finally the blocks is written and events are generated accordingly. This way the consensus is accomplished over multiple stages in Hyperledger fabric. I think you would understand better if you refer to this link below Hyperledger Fabric Transaction Flow