How Hyperledger Fabric Blockchain Works? Key Concepts Explained!
The goal of this blog post is to describe key concepts of how Hyperledger Fabric blockchain works so that you can get a basic understanding of how to use it for your blockchain applications.
What is Hyperledger Fabric?
Hyperledger Fabric — hosted under Linux Foundation — is a private, permissioned and open source blockchain solution. Private means that blockchain networks are not publicly accessible and only invited parties can join the network. Permissioned means each party is clearly identified and every transaction is authenticated, authorized, validated and tracked. You can run Fabric networks on-premise or use Blockchain as a Service platforms to maintain the ledger infrastructure for you.
Once a network is created between multiple parties they can use this network to share valuable data between each other. Notice that if your blockchain application does not interact with multiple parties then Hyperledger Fabric’s blockchain solution is useless. This is because the goal of the Fabric blockchain network is to enforce trust between more than one party, organization or organization unit.
Organizations
An organization in Hyperledger Fabric corresponds to a real organization, company, political party, etc. Each organization in Fabric has to dispose of a Public Key Infrastructure (PKI) which has to be comprised of a Certificate Authority (CA) and possibly even an Intermediate Certificate Authority (ICA) that will issue digital certificates for the organizations identities (e.g. users, client applications, peers, orderers). Those then use them to authenticate themselves in the messages they exchange within the networks.
Hyperledger Fabric comes with a default CA service but It is not necessary to use the default service for your PKI management. You may use any already existing PKI that your organization has. Another option is to utilize HashiCorp Vault or other solutions to issue public-private key pairs for your organization. The only important thing is to create the keys and certificates in the supported format — signing keys must be in the ECDSA format. The RSA format is not currently supported.
Membership Service Provider (MSP)
In Fabric, an organization is identified by its MSP. In Hyperledger Fabric Network each organization is identified by its Membership Service Provider identification (MSP ID). To be accurate, an organization can be comprised of one or multiple MSPs but for most cases, and for the sake of simplicity, you will probably use a single MSP to represent an organization. An MSP is formed by an instance of a PKI infrastructure which is then able to issue certificates for the MSP.
Peers
A peer is a node running on the Hyperledger Fabric peer binary. Each organization is supposed to have peers to host ledgers and smart contracts. Every channel (network) has its own data in a separate ledger stored on peers. And every channel is supposed to have one or more smart contracts (chaincodes). Multiple versions of a chaincode can be installed and stored on organizational peers and can be instantiated into one or multiple channels. Applications connect to peers to query (get) or invoke (put) data into ledgers. For query, only peers are contacted.
For invoke, first the peers are contacted and return responses, then the transaction is created and sent to the ordering service for ordering — which is passed and then committed to the ledger.
Anchor Peer
An anchor peer is a peer role in a channel that can be discovered by all other peers across all organizations. If your organization does not have an anchor peer, your peers will only be able to see your internal organization peers. If there are no anchor peers in a channel (network), each organizations peers will not be able to learn about other organizations peers participating in the channel. Only peers internal to each organization will learn about each other. Thanks to your organizational anchor peer, all your other (even non-anchor) peers in a channel will be able to see all other organizations peers regardless if they have or do not have their own anchor peer. If an organization does not have an anchor peer in a channel and a new peer is joined to the channel, the organization might not be able to learn about this new peer.
Lets give you an example how it works. Let’s say you have a channel with 3 organizations named Alice, Bob and Eva. Only Alice will have an anchor peer in the channel. In that case:
- All of Alice’s peers will see its own peers and all peers of Bob and Eva that are joined to the channel.
- All of Bob’s peers will see its own peers and all peers of Alice.
- All of Eva’s peers will see its own peers and all peers of Alice.
Ordering Service
The ordering service can be comprised of one or multiple orderer nodes. An orderer is a node running the Hyperledger Fabric orderer binary. As the name implies, an ordering service does transaction ordering but only for chaincode invoke requests. The ordering service supports multi tenancy, meaning that one orderer service can order transactions for multiple channels.
Consortium
The ordering service is configured by the so-called “orderer system channel” where the consortium is defined. A consortium is a list of organizations that are allowed to create channels.
Consensus
A consensus is an agreement about the order of transactions between individual ordering service nodes. Hyperledger Fabric currently supports 3 different mechanisms or implementations of consensus — SOLO, Kafka, and Raft. And for production networks SOLO and Kafka is definitely not recommended. SOLO does not provide neither high availability (HA), nor decentralization. Kafka does provide HA but not decentralization, while Raft provides both.
Only Raft allows you to have an ordering service comprised of nodes from different organizations which results in the distributed ordering service. Raft is based on the crash fault tolerant (CFT) consensus mechanism and functions as a leader with followers. In every channel a leader is elected and its decisions are replicated by the followers.
Blockchain Networks (Channels)
A channel is a Hyperledger Fabric blockchain network. The network is not publicly available but rather only invited organizations can join the network. Each channel has its own ledger and thus is a totally separated network. Data between channel members are shared through the channel but not between channels. It is possible to communicate between channels but this has to be specifically managed through applications or smart contracts. Otherwise, by design there is a complete data separation between channels.
Data in the channel is shared and visible to all participants. That means that all members of a channel have the same set of data stored in their own peers in the channel’s ledger. At the end, this is what forms the decentralized blockchain network where each member stores its own data on its own peers, in turn being able to verify and validate shared data at any given time. Through this you will not be dependent on somebody else’s service.
Each channel has its own configuration where MSPs and its certificates are placed and identify each member of the channel.
Private Data
By default all data in a channel is shared between all channel parties. Private data collections enable you to keep a portion of data private without having to create a separate channel. This feature comes in handy when price, for example, is supposed to be visible only between two parties and the rest of the transactions are shared between all channel members.
Smart Contract (Chaincode)
In Hyperledger Fabric terms, a smart contract is a piece of code (written in Go, node.js, or Java) enforcing contract processing between parties. Chaincode is a packaged smart contract code prepared for installation. Essentially, a smart contract lies within a chaincode package.
In general, the smart contract is where automation of processes between organizations comes into place. Smart contracts work with data on the blockchain to typically automate business as well as workflows. Most of smart contract automation is written in a way that if something happens it triggers a different action that will be automatically written to the ledger. An example of smart contract automation can be tracking an SLA, and if it is breached it will automatically commit a discount to the ledger for the provided IT service. A different example can be how within elections a smart contract automatically commits a winner on the ledger when all the votes are counted. Of course more actions or chain of actions can be implemented.
Deployment Process
The deployment process follows simple steps. After you have developed your smart contract, you can package it and install it on peers in a channel. Installation is basically only the process of moving the chaincode to the peers. No smart contract runs yet at this stage. Installing a chaincode is not channel dependent. It is only after the chaincode is instantiated in a channel that the smart contract runs for that particular network.
If a running smart contract needs to be updated it is simply a matter of installing the new chaincode to peers and upgrading them to the current version, in the same channel, with the new one.
Operationally, chaincode is started and managed by a peer and typically runs in a separate Docker container.
Blockchain Applications
Not all applications are suitable for a private blockchain. It is necessary to first answer the question if a private blockchain and Hyperledger Fabric specifically is right for your use case. Once that is clear, you should define what data is suitable to store on the chain and what data to store off the chain. After these prerequisites are solved you can start your blockchain application development or extend your existing application with blockchain. Without solving these two problems and having clear answers it will be a waste of your programming time.
Using SDK
Hyperledger makes it easy for developers who write applications in Go, Python, Node.js or Java to interact with Fabric ledgers, as it supports Software Development Kits (SDKs). Developers simply import these SDKs into their application and provide a configuration that contains information like MSP, TLS certificates, peers and ordering service endpoints and channels.
Once your SDK is setup you can start to query chaincodes or invoke ledgers from your application.
This concludes the summary on how Hyperledger Fabric works from a practical point of view. You can read more KompiTech posts on our blog.
