Consensus & Endorsement in Hyperledger Fabric
This article is second in the series of articles related to the Hyperledger Fabric. If you have not read my previous article, then here is the link. I would recommend that you should try to set up the “first-network” so that you can relate to the concepts in this article. My other recommendation is this Youtube video which is the best explanation of Bitcoin in 20 minutes.
In a discussion about Bitcoin, you are meant to come across the term — “Mining”, a.k.a. Proof of Work (PoW). What is mining, and why it is done — are the two question that you must ponder. Most importantly why it is done; because that is the heart of Blockchain. In summary, mining keeps all nodes in the Bitcoin network in sync. It enforces that the transactions are committed in the same order by all nodes, thus preventing someone from double spending. Watch that Youtube video for a detailed explanation.
While mining is specific to Bitcoin (and some other Blockchain frameworks), a more general term is Consensus. If you have some background in Distributed Systems, you might know that it’s a fundamental problem of making all nodes agree to a particular value or action. Here, we are dealing with transactions. Consensus helps us to determine whether to commit it or not, and it is the responsibility of Orderer Service Node to establish this Consensus.
Before going further, for those who are not much familiar with the Hyperledger Fabric architecture; a Node is a system (or more specifically docker container) running a specific service of the platform. We have three types of nodes in the landscape, Orderer (responsible for establishing consensus), Peer (hosts ledger and chaincode) and Client (used for submitting transactions).
Let’s recall that the participants in a Hyperledger Fabric network are not individual users, but entire Organizations. An organization hosts one more Peer nodes and Client nodes. Even though the transactions are submitted by the client node, but they are submitted on behalf of the entire Organization. Therefore, the validation process must make sure that the organization is not doing any mischief. Since it is a Blockchain network, we do not have a central authority for validation, but a policy called “Endorsement Policy”.
As the word suggests the Endorsement Policy defines which of the participants (Organizations) must endorse a transaction. To understand what endorsement means, consider an analogy. Let’s say you have to give $10 to someone called Bob, and there is a third person called John who is responsible for endorsing this transaction. Here, John makes sure that you had enough money to give to Bob, and you have actually given it to Bob.
Endorsers in the Hyperledger Fabric does a similar task. They make sure that before updating an asset, you have the correct state of the asset, and also none of the validations defined in the chaincode are stopping you from modifying that asset. Hyperledger Fabric allows us to make some complex combinations while selecting endorsers, like either of two participants, or both of two participants, or two of five participants, etc.
Once a transaction is endorsed by the relevant participants, Orderer Service Node comes into play. At this time, the client broadcast endorsed (signed) transaction to Orderer(s) in the channel. The Orderer does two things. Firstly, it verifies that the client has an appropriate role, which is required to modify the ledger. Once that is confirmed, Orderer collects the transaction into a block and broadcasts the block to the channel if it reaches a defined size or a defined amount of time has been elapsed.
You can argue that Orderer could be the single point of failure in the Hyperledger Fabric system. This may not be true, as we can have multiple Orderers in the network. Until version 1.2, there are two consensus mechanisms available, namely, SOLO and Kafka. SOLO is the simplest mechanism, which only broadcasts the transaction without establishing any real consensus. Clearly, it’s not recommended for production. On the other hand, Kafka uses a fault-tolerant distributed streaming platform called Apache Kafka. It also enables distributed ordering service, so that we can have multiple Orderer nodes to avoid a single point of failure.
I think describing Kafka based consensus will take a whole article. So that’s it for now. Stay tuned for more articles about the Hyperledger Fabric blockchain framework.
