Hyperledger Fabric Essentials
The guideline here described will serve as a focal point for those trying to grasp the Hyperledger Fabric Blockchain platform. Hyperledger Fabric is the framework, decorum, and system for distribution, development, and submission of the permissioned blockchain. It depends on on an extremely segmental architecture, which is underpinned by interchangeable consensus protocol which allows immense scalability and flexibility for different use cases.
What’s a Blockchain?
To begin with, let’s dive right into what the term blockchain stands for.
A blockchain can be pinpointed as a distributed and immutable record utilized for storing transactions between two or more parties. It is widely categorized into a private and public blockchain.
Basically anyone with a computer and an internet connection can be a part of the public blockchain network and partake 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.
In contrast to public blockchains, there are permissioned/private blockchains where participant’s IDs are visible and are certified before they can join the system and play a part 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 both built on execute-order architecture. Some of the restrictions that this brings together are sequential execution of all transaction which directly impacts 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.
Endorsement policy specifies which peer nodes have to execute the transaction and give their endorsement. A subset of peers can, therefore, execute (endorse) a given transaction and fulfill the transaction’s endorsement policy. This permits parallel execution of transactions and openly boosts performances of the system. Hyperledger separates transaction flow in three distinct steps:
1. Transaction Execution — running the smart contract code
2. Ordering through a consensus protocol
3. Transaction Validation
The Hyperledger Fabric architecture consists of the following five components:
1. Ordering service
2. Membership service provider
4. Endorsing peers
5. Channels
Ordering Service
Ordering service entails ‘orderer’ nodes that form the order of all transactions. Transaction clusters are arranged and wrapped into blocks that are later added to the blockchain. Orderer nodes then transmit blocks to associated peers while peers which are not associated to the orderer node get blocks from other peers via gossip protocol.
Afterwards, peers certify transmitted blocks from the orderer node and then submit it to the record. There are 3 interchangeable consensus protocols in Hyperledger Fabric Solo, Raft, and Kafka.
Solo includes only one orderer node, and it is exclusively used for development and testing as it does not deliver crash fault tolerance.
Raft, based on Raft protocol, gears 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.
Smart contract and Chaincode
Smart contract in Hyperledger Fabric domain is referred to as the chaincode. Chaincode is a software package which gears some application logic and can be written in general purpose programming languages such as GoLang, Java, NodeJS. This further empowers easier and wider adoption by software developers in contrary to domain-specific programming languages.
Chaincodes are executed in a containerized environment, in Docker containers, which gives isolates it from other chaincodes and peers.
Channels
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 all form a channel. Right before transaction’s execution, the peers and channels upon which the transaction will be executed on must be stated. All transactions executed on a given channel must be executed by authenticated and authorized peers.
In order to execute a transaction on a channel, peers must be associated on the channel and also be valid and authorized by the membership service provider.
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.
Transaction simulation
When the endorsing peer obtains 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.
Ordering
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. Importantly, the note is that the transaction has not yet 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 debased. If everything is fine, the transaction is set as valid and is committed to the ledger. If something was wrong transaction is invalid, it gets rejected and does not affect state change.
Conclusion
Hyperledger Fabric is one of the most developed and constant networks for developing blockchain solutions that offers great performances with high transaction throughput, modular consensus protocols. Hyperledger Fabric is the first blockchain structure that runs smart contracts written in general-purpose programming languages.
