Q: “does blockchain fork happen in fabric??”

A: No.

First of all, let’s start with the question. Blockchain fork is not one of the most cleanly defined terms out there, but let us go with the meaning of forks in Bitcoin blockchain. Fabrc on it’s own is supposed to mean “Hyperledger Fabric” which is the official term for the project. Link to the project site.

At this point, I am going to assume passing familiarity of Hyperledger Fabric and Bitcoin and continue from there.

A fork occurs on the Bitcoin blockchain when the exact block at some blockheight h is different at different nodes.

What does this mean?

Blocks are generated by miners and forwarded to the full-nodes, the main participants of the Bitcoin network that each maintain a copy of the Bitcoin blockchain. As blocks are generated probabilistically and the connecting network is flaky in the normal case (as it tends to be in internet scale network with connections in flux, packets being dropped or delayed by large time durations), it is possible for 2 blocks to be generated around the same time, both vying for the blockheight h. In the presence of an ideal network (basically impossible; more specifically, if the network were to support Atomic Broadcast), the block generated first would be recieved by all full-nodes, and they would reject the next block.

As reality does not support this, different nodes are going to accept different blocks for height h.

But, then the ledger is out of sync!

Yes, it is. This is a fork.

How do we solve this?

The mechanism that Bitcoin uses to solve this is that miners (and full-nodes) are supposed (meaning incentivized) to use the longer chain that they have knowledge of. This brings everyone onto a single point of view eventually. The “eventually” is probablistically 6 in the current state, which means once a block has 6 blocks after it, it is more or less settled in stone.

So, after all of this, does something like this occur in Hyperledger Fabric?

No. When a node (committer/endorser) sees a block at height h, it is guaranteed to be correct/the only possible block at height h.

How come?

In Fabric, the Ordering Service is the sub-system that is tasked with putting together a block of transactions. Then the ordering service transmits the block to all nodes.

So…, ordering service is like a miner.

Yes, the members of the ordering service, called orderers are kind of like miners in Bitcoin. They serve the same function.

So, when using miners, forks can happen but with ordering service, it does not. How?

Miners are participating in Proof of Work. PoW achieves consensus probabilistically as talked about above. The ordering service talked about in Hyperledger Fabric is a pluggable module, meaning you can use any existing consensus protocol. The ones currently being used (Solo, Kafka (CFT) and PBFT) achieve consensus deterministically. This basically comes from the design of these protocols and Distributed Systems theory.

So why not use this ordering service in Bitcoin instead of mining, if it does not have forks?

As mentioned above you can plug-in any one of the available consensus protocols for use as the ordering service. Each protocol has it’s own strengths and weaknesses; you can choose one that best suits the needs of the particular blockchain network or applications expected to run on the network.

These protocols do not however fulfil the most important goal of PoW, complete permissionless, meaning you need to pre specify the participants in the Ordering service. As this is fundamental to Bitcoin (that anybody can join the network at any time), these protocols cannot be really used in place of PoW and retain the core Bitcoin properties.

So, what is the worst that can happen to the blockchain, on multiple nodes, in Fabric?

Yes, the worst that can happen, on multiple nodes (meaning committer nodes) in Hyperledger Fabric is that a node may fall behind others. How can it fall behind?

1. Maybe it is a slow node that processes transactions (meaning the validation step before commit after recieving a block), slower than the other nodes on the chain. So, if everyone has committed block 10, but this node is still on block 8.

2. Maybe some blocks never reach the node at all. So, the node processed upto block 8 but never received block 9 and 10 whereas other nodes did. Meaning, some kind of network problem.

But this is not a big problem.

How is this not a big problem? The ledger is out of sync.

Yes it is. But the idea is that all nodes will catch up to the ledger eventually. Let us examine the 2 cases above.

1. From the point of view of the slow node, only 8 blocks form the blockchain. When this node endorses a transaction (meaning vouches for the correctness of a transaction) and when the transaction is sent to the orderer, the transaction will still be a part of block 11. Wether the transaction succeeds or fails (depending on if there where transaction related to the same asset/data in the blocks ⁹⁄₁₀), it is going to happen at all nodes in block 11. End of the day, all nodes are in sync.

2. When this node recives the next block 11, it does some basic santiy check. First, we have the block number, and that itself clearly indicates a gap in it’s blockchain. So it recovers this by gossiping with other nodes to obtain the missing blocks. How can it trust this block? The block is signed by the Ordering Service and this cannot be forged by the other peers. Secondsly, we also have the previous block hash that points the previous blocks on the chain. It can then easily verify if the 9 and 10th blocks fit in the chain based on the hash contained in the 11th block.

Closing words

So, in total, the Hyperledger Fabric blockchain cannot fork. This writeup purposely omits details of the complete working of Fabric, the ordering service options, endorsement etc. Do read the Fabric documentation to know more about these.