This tutorial will act as a starting point for those trying to understand the Hyperledger Fabric blockchain platform. Hyperledger Fabric is the infrastructure, protocol, and network for deployment, development, and application of the permissioned blockchain. It relies on a highly modular architecture, which is underpinned by interchangeable consensus protocol which allows immense scalability and flexibility for different use cases.
What’s a Blockchain?
To start with, let’s look into what a blockchain is.
A blockchain can be defined as a decentralized and immutable ledger used for recording transactions between two or more parties. It is broadly classified into a private and public blockchain.
Anyone with a computer system and an internet connection can be a part of the public blockchain network and participate in its transactions. This means that they can read, write to the ledger, and host their own node for processing the transactions. Public blockchains are fully decentralized, which means that no single entity or individual has control over the network.
In most cases, public blockchains use the “proof of work” (PoW) consensus protocol. In a PoW protocol, miners (blockchain nodes) compete against each other to mine a transaction and get rewarded for their work. Mining is a process of solving a “cryptographic puzzle” which requires a lot of computational power to solve, but when the solution is found it’s easy to prove the solution.
Contrary to public blockchains, we have permissioned/private blockchains where identities of the participants are known and are authorized before they can join the network and participate in the transactions. Hyperledger Fabric is a such a blockchain — a permissioned/private one.
A majority of blockchain systems follow execute-order paradigm, which requires all nodes to execute every single transaction. This means that each peer must execute each transaction, and these transactions must be deterministic.
The Hyperledger Fabric
Ethereum (a public, permissionless blockchain) and Quorum (private, permissioned blockchain based on Ethereum code) are based on execute-order architecture. Some of the limitations that this introduces are sequential execution of all transaction which directly affects transaction throughput. The main concept that differentiates Hyperledger Fabric from other blockchains is its execute-order-validate architecture. Transactions in Hyperledger Fabric do need not be executed by each peer.
We can define the endorsement policy that specifies which peer nodes have to execute the transaction and give their endorsement. This means that we can define a subset of peers to execute (endorse) a given transaction and satisfy the transaction’s endorsement policy. Therefore, this allows for parallel execution of transactions and directly boosts performances of the system. Hyperledger separates transaction flow in three distinct steps:
- Transaction Execution – running the smart contract code
- Ordering through a consensus protocol
- Transaction Validation
The Hyperledger Fabric architecture consists of the following five components:
- Ordering service
- Membership service provider
- Smart contracts
- Endorsing peers
Ordering service consists of orderer nodes that establish the order of all transactions. Batches of transactions are arranged and packaged into blocks that are later added to the blockchain. Orderer nodes then broadcast blocks to connected peers while peers which are not connected to the orderer node get blocks from other peers via gossip protocol.
Peers then validate broadcasted blocks from the orderer node and then submit it to the ledger. There are three interchangeable consensus protocols in Hyperledger Fabric Solo, Raft, and Kafka.
Solo consists of only one orderer node, and it should only be used for development and testing as it does not provide crash fault tolerance.
Raft, based on Raft protocol, implements a “leader and follower” model, where leader nodes are elected per channel. Raft is crash fault tolerant, which means that it can sustain the loss of the leader node. It is recommended to be used in production as it is easier to set up and manage as compared to Kafka.
Kafka provides crash fault tolerance. Hyperledger Fabric has adapted Apache Kafka as its ordering nodes. Similar to Raft, Kafka follows “leader and follower” model, where the leader is responsible for replicating messages to followers, and if a leader node goes down, there is the re-election of a new leader.
Membership Service Provider and Endorsing Peers
Membership service provider (MSP) is responsible for managing identities of all participants in the network (clients, peers, orderers).
Smart contract in Hyperledger Fabric domain is referred to as the chaincode. Chaincode is a program which implements some application logic and can be written in general purpose programming languages such as GoLang, Java, NodeJS. This allows easier and wider adoption by software developers in contrast to domain-specific programming languages.
Channels play an important role in Hyperledger Fabric as they provide a completely separate communication layer between participants. Channels also provide a way of sharing a network between multiple participants while maintaining data and communication privacy.
Members, peers, chaincode and orderer nodes define a channel. Before the execution of a transaction, we must specify the peers and channel it will be executed on. All transactions executed on a given channel must be executed by authenticated and authorized peers.
Hyperledger Fabric is one of the most mature and stable platforms for developing blockchain solutions that offers great performances with high transaction throughput, modular consensus protocols and Fabric is the first blockchain system that runs smart contracts written in general-purpose programming languages.
Transaction proposal and endorsement policy
In order to invoke a transaction, the client needs to send a message proposal to a set of endorsing peers. The client needs to be aware of endorsing peers and the endorsement policy of the chaincodes that is being invoked. The endorsement policy defines a set of peers that need to execute a given transaction proposal for the specified chaincode. For example, the endorsement policy can specify that all endorsing peers must execute a transaction proposal or only a subset of them. Endorsement policy is defined per chaincode instantiation.
When the endorsing peer receives a transaction proposal message, firstly he verifies the client’s signature and then simulates a transaction. In the process of simulation of transaction execution endorsing peer invokes specified chaincode to which the transaction is referred keeping in mind the copy of the state that peers locally holds. Result of transaction simulation is the computed read/write set. Read sets are keys on the ledger that were read during the transaction simulation process. Write set are the keys that are going to be modified by the transaction. Then this transaction proposal has to be endorsed by the peer, which means that the transaction proposal is cryptographically signed by the peer.
The client is waiting until it receives the required number of endorsements from peers. This required number is specified by the endorsing policy. When the endorsement policy is fulfilled, the transaction has been endorsed. An important note is that the transaction has not been committed to the ledger. The client then submits this to the ordering service. Ordering service delivers transactions to the peers. Peer validates endorsement against chaincode endorsing policy, then validates that read sets have not been violated. If everything is ok, the transaction is marked as valid and is committed to the ledger. If something was wrong transaction is invalid, gets rejected and does not affect state change.
Author: Lazar Lukic