Consensus in Hyperledger Fabric

Hyperledger Fabric is a blockchain created by IBM and Digital Asset. Hyperledger Fabric (Fabric) is a permissioned blockchain. Fabric uses deterministic consensus algorithm, any block that is validated is guaranteed to be final. There is no forking in Fabric.

To update the ledger, there is a three phases process. In the first phase, application sends transactions to the peers (peer nodes), which then invoke smart contract to propose ledger update and approve the results. The peers return the proposed update to the application. There is no actual update in this phase.

In the second phase, application sends approved transactions to the orderers (ordering nodes). The orderers may re-order the transactions, then package transactions into blocks that are sent to peers. The blocks generated by the orderers are final.

The first role of an ordering node is to package proposed ledger updates. In this example, application A1 sends a transaction T1 endorsed by peers E1 and E2 to the orderer O1. In parallel, Application A2 sends transaction T2 endorsed by peer E1 to the orderer O1. O1 packages transaction T1 from application A1 and transaction T2 from application A2 together with other transactions from other applications in the network into block B2. We can see that in B2, the transaction order is T1,T2,T3,T4,T6,T5 — which may not be the order in which these transactions arrived at the orderer!

In the third phase, peers receive the blocks. Peers validate each transaction in the blocks. Invalid transactions are kept in the block, but they do not get to update the ledger.

In Fabric version 1.4.1, RAFT is used as the ordering service. RAFT protocol is crash fault tolerance (CFT), not Byzantine fault tolerance (BFT). RAFT can function as long as more than 50% of the nodes are up and running. The quorum in RAFT means there is a minimum number of nodes to confirm the order of transactions. The 50% is the quorum number. Below that, no new entries is created in ledger.

RAFT adopts leader-follower model. A leader is selected per channel, and its decisions are copied by the followers. Each channel runs a separate instance of RAFT protocol.

When orderer validation is completed, the transactions are ordered, packaged into blocks, consented, and distributed to peers. This corresponds to the second phase of the ledger update process.