Background

Blockchain has gained lot of traction through bitcoin (and other cryptocurrencies.) It generated a lot of interest from technologists on applications of blockchain in areas other than payments. So much that entreprises took strong notice and started thinking how they can make use of this new technology for themselves. Hyperledger Fabric was born by one such effort by IBM.

What are we trying to achieve in primer?

It’s a simple walkthrough of the most important aspects of hyperledger fabric as a permissioned blockchain. This article is meant for both developers and managers who want to understand Hyperledger Fabric and start generating ideas on how it could be beneficial to your business case. This is not a developer overview.

Prerequisites for understanding this primer

A basic knowledge of what distributed ledgers mean and an interest in what blockchain technology can do. Check out this link to get a better understanding on distributed ledgers.

Why was Hyperledger Fabric developed?

A prerequisite for public blockchain is that, all data needs to be accessible publicly. Unlimited copies of the same data are maintained in the network. Anyone can join the network and become a participant and create their own copies of the data. Confidentiality is maintained by making the data intelligible only to certain participants whenever needed. This is a necessary prerequisite for achieving the level of proclaimed security (transparency, trust, availability, fault tolerance to hardware failures and malicious attacks on individual nodes). Hyperledger Fabric, on the other hand, allows for permissioned and private blockchain network, where, sensitive data can be protected from the public, yet, exchanged only between trusted entities. In permissioned blockchain, the owner has the privilege to decide on the users and organisations that take part in a particular transaction.

Why do we need private blockchains?

Public blockchains allow for anonymous users to take part in the consensus process; a process involving read and write operations. This allows for anonymous entities to create valid blocks and commit them to the ledger. Anonymous participants, however, are not suitable for all applications. For example, imagine a record for legal purposes: maintaining of land ownership records. Here, regulations enforce that the identity of every participant (be it a seller, buyer, surveyor or lender) needs not only to be known, but also to be validated as legitimate. Anonymous parties aren’t allowed to create a transaction.
This is when a private blockchain comes into play. In this type, the blockchain consists of organizations that have some amount of trust already established among themselves, but want to simulate the trust provided by an unbiased middleman. The distributed ledgers are only available to the the participants of the network and cannot be viewed by public. Hyperledger Fabric provides the tools and techniques to achieve such a system. In order to learn more about the difference between public and private blockchain, check out this link

Block – Basically, a block consists of a bunch of transactions. In Hyperledger Fabric, the orderers package a bunch of transactions into a block, and unlike other blockchains, a transaction cannot be part of multiple blocks. There is no particular order in which these transactions are stored, but, the order is maintained strictly. Once, written to a block, the transactions are immutable. Each block consists of the hash generated for the current block as well as the hash of the previous block. In the above figure, Block B1 is linked to block B0 and block B2 is linked to block B1. Block B0 refers to the genesis block which is the first block that contains the configuration details such as ordering services.
Ledger – The modifications to the states of the ledger are stored within blocks. A collection of these blocks is called the ledger. Each participating peer maintains a copy of the same ledger. These ledgers contain all the blocks that have been added since the time the network was created. Each block on the ledger consists of information regarding the transaction as well as the hash of the previous block. This hash is later used while endorsing a transaction.

Chain – The chain consists of transactions logs that are stored on every peer. These logs consist of the hash linked blocks that are present in the ledgers. When peers receive new blocks of transactions from the orderer, they validate it and upon reaching consensus for a valid transaction, they append it to the current chain maintained on their systems. The above figure represents a blockchain B that contains 3 blocks(0,1 and 2) along with the transactions T.
State – This refers to the state of the blockchain which is stored as a key value pair. Any changes to the blockchain is a change to this state and is recorded and stored here. The state of a blockchain is a versioned key-value store which refers to the data stored. These states are manipulated by the chaincode. The state is stored persistently and changes to it are recorded. The ledgers keep track of all the successful state changes. States are only maintained by peers.
Transactions – Any exchange of assets on the network takes place through transactions. There are two types of transactions. Deploy transactions are the ones that take a chaincode program as a parameter and install a chaincode on the channel. The other types is the Invoke transactions which refer to a function of the previously installed chaincode and take the parameters for that function.
Committing Transactions – Every peer acts as a Committer, where in, a copy of the valid transaction is stored on their local copy of the ledger . Before any transaction is committed, the peers validate the transactions and mark them as valid or invalid. The transactions are committed to the local copy of the ledger stored by each of the peers after reaching consensus.
Endorsing Transactions – Some peers are named as Endorsers for certain transactions as per the Endorsing Policies. Such peers must execute the chaincode and return a proposal response to the client application. The proposal response includes information such as the signature that proves that the transaction was executed by this peer, the chaincode execution response, events as well as the result of the transaction. The Endorsement Policy specifies the peers that must execute the transactions as well as specify the combination of the endorsements required. A transaction must be acknowledged as valid by the endorsement policy before it can be committed.

Channels – In the Hyperledger Fabric network, a user can specify the participants of every type of transaction. Each such configuration is called a channel. A channel can exist between a subset of organizations in a network. The ledger details are specific to each channel, thus, peers on each channel have copies of the blocks that only belong to that channel. Presently, inter channel communication is only partially supported. The above diagram represents a channel C connecting an application A1 to an orderer O1 to a peer P2 .
Peers – Nodes refer to all types of participants of a blockchain network. This includes orderers, endorsers and committers. The nodes that perform transactions and commit them are called peers. These peers maintain the ledgers and can optionally act as endorsers as well. An organization can contain multiple peers. Endorsement policy determines the peers that will take part in validating a transaction. A peer responsible for endorsing transactions is called Endorser and every peer acts as a Committer.
Anchor Peers – Anchor peers are special peers that bear the responsibility of communicating with other Anchor Peers outside the organization. While, peers inside an organisation communicate freely, anchor peers are the gateway through which communication with peers outside the organisation is facilitated.
Orderer/Ordering-service-node – This node has the responsibility of placing the orders for transactions as well as broadcasting the same to all the participating nodes.

Membership Service Provider (MSP) – In order to allow for private and permissioned blockchain system, Hyperledger Fabric ensures that the participants enroll themselves via the MSP. This way, the identity of the participants is known to the entire network. While performing any transaction, the identity of the required organization can be looked up from the MSP. The above figure represents MSP at these local and global levels. The MSPs for oraganisation 1(ORG1) is ORG1.MSP and that for the other organization(ORG2) is ORG2.MSP. The trust domain of each peer is defined by the local MSP, where as on the channel, the MSPs are added to the channel’s configuration as depicted above.

Consensus – This is the process that ensures that a transaction is valid before committing it to the ledger and the ledger in all the participating peer is updated to the same transaction in the same order. Before committing a transaction, Hyperledger Fabric makes sure that the endorsing policy is met for that transaction. The system chaincodes ensure that enough number of peers are endorsing the transaction as well. Versioning of the ledger is also done to ensure that all the ledgers of all the peers are in the same state, thus, preventing the compromise of data integrity and allow for the manipulation of variables.

Chaincode (Smart Contract) – Chaincode contains to the business logic that describes the terms that were agreed upon for the transaction. Usually, it contains the logic for interaction with the ledgers such as writing to it and querying from it. An external application interacts with this chaincode to perform any transactions with the blockchain. Smart contracts not only contain the logic to encapsulate data but can also be used to execute certain operations automatically.