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

According to Hyperledger fabric v1.4

One of the most important of the platform’s differentiators is its support for pluggable consensus protocols that enable the platform to be more effectively customized to fit particular use cases and trust models. For instance, when deployed within a single enterprise, or operated by a trusted authority, fully byzantine fault tolerant consensus might be considered unnecessary and an excessive drag on performance and throughput. In situations such as that, a crash fault-tolerant (CFT) consensus protocol might be more than adequate whereas, in a multi-party, decentralized use case, a more traditional byzantine fault tolerant (BFT) consensus protocol might be required.

The ordering of transactions is delegated to a modular component for consensus that is logically decoupled from the peers that execute transactions and maintain the ledger. Specifically, the ordering service. Since consensus is modular, its implementation can be tailored to the trust assumption of a particular deployment or solution. This modular architecture allows the platform to rely on well-established toolkits for CFT (crash fault-tolerant) or BFT (byzantine fault-tolerant) ordering.

Fabric currently offers two CFT ordering service implementations.

1. The first is based on the etcd library of the Raft protocol.
2. The other is Kafka (which uses Zookeeper internally).

Answer 2

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.(It is defined by us).

Ordering phase will get the endorsed transaction and agrees that transaction to be committed to the ledger.(We can use any ordering service out of solo,Kafka and Raft).

Validation takes a block of ordered transactions and validates the correctness of the result.During validation peer will verify whether transaction(in blocks) sent by orderer is valid or not.

Answer 3

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