Understanding Hyperledger Fabric — Gossip
Hyperledger Fabric is a distributed blockchain network where multiple components each keep their own copy of a shared ledger, the definitive history of all transactions. As new transactions occur, they must be distributed across the network, keeping all copies of the ledger in sync.
At a high level, the process looks like this:
- New transactions are submitted to the orderer (a.k.a. ordering service).
- The orderer creates a new block (containing the new transactions) on the blockchain.
- The orderer delivers the block to all peers.
The last step, delivery, is where gossip comes in. Even in a blockchain network with relatively few member organizations, there could still be a large number of peers. For example, a network that makes heavy use of IoT (Internet of Things) devices might need many peers to connect these devices to the network. Furthermore, the wider network of peers may have intermittent connectivity — some peers might not always be reachable from the orderer. It’s unnecessary stress for the orderer to have to deliver to every peer, and it may not even be possible in some situations.
What actually happens in Hyperledger Fabric is that the orderer only delivers new blocks to a single peer in each organization — the leader peer. Through a process called gossip, the peers themselves do the job of spreading the word to each other:
- A peer has a message that needs to be distributed to all other peers. For example, the leader peer has a new block for the blockchain.
- This peer sends the message to a predetermined number of (randomly selected) other peers.
- Each of those peers forwards the message to a predetermined number of other peers.
- And so on, until every peer has received the message.
The process above is called broadcast, and it’s used by Fabric’s gossip system to distribute multiple kinds of messages to all peers.
Membership Gossip
A key component of the gossip protocol is that each peer forwards messages to a random selection of the current peers in the network. This implies that each peer knows which peers are in the network so it can choose among them.
In Fabric, each peer periodically broadcasts a message message that indicates it’s still alive and connected to the network. Every peer maintains its own list of all the peers in the network — those that are “alive”, and those that are “dead”.
- When Peer A receives an “alive” message from Peer B, it marks Peer B as “alive”. According to Peer A, Peer B is part of the network.
- If after a while, Peer A hasn’t received an “alive” message from Peer B, it marks Peer B as “dead”. According to Peer A, Peer B is no longer part of the network.
Just in case Peer B isn’t actually dead, Peer A periodically attempts to connect to dead peers to see if they are actually alive. For example, it’s possible that network issues or failures on other peers prevented Peer B’s “alive” message from reaching Peer A. When Peer A contacts Peer B directly, it can see that Peer B is indeed still alive.
Bootstrapping
The process described above works only if a peer has a list of other peers to send “alive” messages to. So each peer is bootstrapped into the network with a bootstrap set of peers to start with.
Byzantine Fault Tolerance
Each peer signs its “alive” messages, which means a bad actor can’t trick the rest of the network by creating messages. All it can do is not forward a peer’s “alive” message. This isn’t much of a threat as long as other peers still forward the “alive” message.
Data Dissemination Gossip
As described earlier, the basics of data dissemination are simple. Each peer forwards new data to a randomly-selected subset of the peers it knows about. This process is called broadcast, and it’s a push-based way to move information through the network.
However, if a peer became disconnected from the network and reconnects later, it would’ve missed the broadcast process. In order to catch up with the rest of the network, it needs a pull-based mechanism to request the data it’s missing. In Hyperledger Fabric, peers periodically exchange both membership data (the list of peers, alive and dead) and ledger data (transaction blocks) with each other. This allows peers to stay up-to-date even if they miss the broadcast of an “alive” message or a new transaction block.
Conclusion
Hyperledger Fabric uses gossip between peers as a fault-tolerant and scalable mechanism for keeping all copies of the blockchain ledger in sync. It reduces the load on the orderer, which only needs to deliver blocks to a single peer per organization, and it allows peers to “catch up” to the current state after being disconnected.
