In this article, we’re going to tackle one of the most advanced and unique blockchain platforms – Hyperledger Fabric. This platform allows you to create private networks, adjusting them to the needs of your project or business.
We’ll discuss the network’s functionality, strengths, and weaknesses. For a practical task, we’ll configure and deploy a basic network and then add custom business logic. After that, we’ll compare our solution with other similar implementations based on different platforms.
This article will be useful for both businesses and developers who want more information about Hyperledger Fabric and its use cases.
It’s difficult to compare Hyperledger Fabric to any other blockchain network like Bitcoin or Ethereum. Unlike most other networks, Hyperledger isn’t intended for public use.
In fact, there’s no such thing as the Hyperledger mainnet. Hyperledger is a platform for developing custom networks to suit your needs.
You may want to build a custom network for your project for a number of reasons:
- You need functionality that isn’t available in any existing network.
- Each of your tasks or customers is unique and requires special treatment within the platform.
- You need to secure your data or keep some of it private.
- You want to control access to your network.
Apart from the opportunity to adjust a private blockchain to your specific needs, you can also benefit from the absence of commission and independence from external factors such as miners and price movements.
Industries and projects such as the following will benefit from Hyperledger Fabric:
- Logistics (supply chain management)
- Finance (audits and accounting)
- Medical records
- Distributed databases for managing the electrical grid
- Educational platforms
However, Hyperledger Fabric is designed for field-specific private networks with explicit access restrictions and data ownership, so it won’t work for use cases such as:
- Currency exchange and transfer
- Public auctions, elections, etc.
All of these use cases require a truly decentralized network that provides all users with equal rights to ensure fair conditions – for example, to eliminate the chance of vote rigging.
Hyperledger Fabric is a blockchain platform aimed at creating private business-focused networks. Initially developed by Digital Asset and IBM, Fabric is one of the Hyperledger projects hosted by the Linux Foundation.
Hyperledger Fabric provides developers with an opportunity to build solid applications with a modular architecture. It uses container technology to host an analog of smart contracts, called chaincode.
Key features of the Hyperledger blockchain platform include:
- Tamper-resistant records of all state transitions
- Tools for managing identities with a Membership Service Provider (MSP)
- Efficient processing of transactions without any mining overhead
- Chaincode functionality to add custom logic that can be invoked by specific transactions
- Modular design to allow for advanced network customization
Although conventional blockchain networks require consensus protocols like Proof of Work to validate transactions and secure the network, they still allow unknown actors to participate. Members of a Hyperledger Fabric network enroll through a trusted MSP.
The focus on a single private application and strict membership control allows a Hyperledger Fabric network to reduce consensus overhead: eliminating extra mining accelerates block creation, which leads to faster transaction approval.
In Hyperledger, a consensus is simply a verification of a set of transactions in a block. A consensus also includes endorsement policies to make sure each participating organization agrees on the transaction.
Both Hyperledger Fabric and the Graphene Framework are designed for creating custom blockchain networks. They provide critical components – data storage, consensus algorithms, and networking – allowing you to focus on the things that are essential for your project.
However, there are a couple of differences between Hyperledger Fabric and Graphene.
The key difference is that Graphene was designed as a source code framework. To create your own blockchain network using Graphene, you have to fork its source code, edit it, and compile it. This is useful if you want to change the core components of the network, such as the consensus algorithm. However, you also have to edit the source code if you’re going to add any kind of custom logic to the network.
On the other hand, Hyperledger’s core components were not intended to be heavily customized. Chaincode provides an easy way of adding custom functionality. With features such as access separation through channels, endorsement policies, and built-in membership control, Hyperledger is definitely the best option for business applications.
Let’s explore the basic elements of the Hyperledger network architecture before building our own solution based on the Hyperledger Fabric blockchain. This will give us a better understanding of how the platform performs and what makes Hyperledger Fabric so special.
Organizations are the main actors in a Hyperledger Fabric network. In most cases, multiple organizations come together as a consortium to form the network. Their permissions are determined by a set of policies, which are agreed by the consortium when configuring the new network.
In Hyperledger, chaincode is the equivalent to smart contracts. Its functionality is similar to any other smart contract implementation: users can create and upload custom business logic that works with on-chain data. Chaincode runs on different peers and in different channels. Not every peer is required to run chaincode in order to access the ledger.
Chaincode has some unique features. For instance, Hyperledger Fabric allows for managing users’ access to the network. Certain smart contracts (or their functions) may have restricted access. Moreover, since access restriction is integrated into the network, you don’t have to rely on the smart contract developer to ensure that the contract’s functions are safe.
Another great feature is the native runtime for chaincode. Chaincode is written in Go and works as a separate program on the peer node. This ensures extremely high efficiency when compared to networks with virtual machines (Ethereum, EOS).
5 Security Tips for Writing Smart Contracts
Orderers are the backbone of the network. They form the ordering service, which is a communication fabric that guarantees fair transaction delivery. Ordering service can include a single node, used for development or testing purposes. It can also be a complex system of nodes with a defined fault tolerance.
An ordering service provides a shared communication channel to clients and peers, offering a broadcast service for messages containing transactions. Orderers are responsible for ensuring atomic delivery of all messages or consensus of transactions within each channel.
The network is mostly represented by a set of peer nodes, or simply peers. Peers are one of the key elements of the network, as they take part in almost every aspect of it. Each organization may have one or several peers to suit their needs.
Each peer keeps a local copy of the ledger for each channel and may run chaincode instances locally. Thus, peer nodes are responsible for providing client applications with access to the ledger and the chaincode of their channels.
A channel is a dedicated line of communication between several peers. It’s a logical structure formed by a combination of peer nodes.
All interactions with channels are done through peers. Network clients may broadcast messages on a channel to deliver them to all peers within that channel. Channels support atomic delivery of all messages. In other words, they output the same messages to all connected peers, so the peers receive messages in the same order.
This atomic communication is also called a total-order broadcast, atomic broadcast, or consensus in the context of distributed systems. The communicated messages are candidate transactions for inclusion in the blockchain state.
Each channel has its own independent blockchain state with a completely independent ledger. So we get as many separate blockchains as there are channels. If a peer accesses multiple channels, it will have a separate copy of the ledger for each channel.
There are various types of policies in Hyperledger Fabric, from simple ones like access to administrative functions, channel creation, and chaincode instantiation to complex endorsement (validation) policies that define which peers should confirm each specific transaction.
Policies are agreed by the consortium when the network is originally configured. Network policies can change over time, subject to agreement by all organizations in the consortium.
Now that you know the basic concepts behind Hyperledger Fabric, we can move on to creating our own private network.
Let’s create a basic network to see how all of these concepts fit together. First, we have to define the organizations to be part of the network. To do this, we can use the
cryptogen tool, which is bundled with the network’s binaries.
cryptogen takes a configuration file that defines each organization and its members and creates the necessary certificates for each member. Our configuration file contains definitions for three organizations, two peers, and one orderer:
Certificates and other cryptographical material for organizations can be generated like this:
Then, we can configure the basic network. To deploy the configurations to the network, we have to perform configuration transactions to send the data. At first, we have to create configuration transactions that define basic parameters for the network.
In total, we’ll need to make four transactions:
- A genesis block transaction
- A transaction to create a channel
- Two transactions to introduce an anchor peer for each of the two organizations within the new channel
To create configuration transactions, we can use the
configtxgen tool, which is bundled with Hyperledger. Similar to
configtxgen accepts a configuration file. Using
configtxgen, you can prepare transactions like these:
Once these transactions have been performed, we can launch the network.
The Hyperledger Fabric repository contains examples of both configuration files and Docker files to help you get started. For this tutorial, let’s use the basic network example from the Hyperledger GitHub repository.
This particular example starts a network with two peers in a single channel. It launches a separate Docker container for each of the peers.
To start all of the nodes within the network, we use these commands:
Now we can send transactions in order to configure the network. We’ll use a single container that can connect to each of the nodes since it has every certificate that we generated. This container is used just for convenience.
To sum up, we’ve created a few containers for our network:
- One orderer service (orderer.example.com)
- Four peers: two peers for each organization (peerX.orgY.example.com)
- A convenience client container (cli) to make it easy to access our peers
In the real world, these actions would be done separately by each organization:
Tezos Blockchain and Smart Contract Overview
Once you have a full network running, you can start adding chaincode to your application. The main difference between chaincode in Hyperledger and smart contracts in Ethereum or EOS is that with chaincode we can configure who exactly can execute a smart contract, since Hyperledger Fabric is a permissioned blockchain.
Another difference is that chaincode runs separately on the peer’s machine itself, without any of the overhead a virtual machine introduces. These factors make chaincode in Hyperledger more secure and efficient than smart contracts on any other platform.
Let’s create an example chaincode program for our network. We’re going to create a simple delivery system. The basic functionality of the chaincode will be:
- Creating delivery orders (for users)
- Accepting orders and picking them up (for couriers)
- Receiving payments for successfully completing deliveries (for couriers)
- Creating a dispute and receiving a refund (for users)
Another part of this chaincode system is a simple token implementation to keep track of payments. The token will be included with the rest of the chaincode and will feature three functions:
- Mint – for the owner to create new tokens
- Transfer – for users to transfer tokens
- Get balance – to get a user’s balance
With these simple requirements in mind, we can start creating the chaincode itself. First of all, we have to implement two lifecycle functions:
Init function is responsible for initializing the chaincode. This function is executed every time the chaincode is instantiated or updated in a channel.
Usually, it would create some basic data structures, set up initial balances, etc. However, since this function is called with each update to the chaincode, it has to be changed with every update so that it won’t override the current state of the ledger.
The second function,
Invoke, is called each time you refer to the chaincode. It’s responsible for selecting the action to perform, for example, transferring tokens or placing an order.
Let’s implement both functions. For the
Init function, we set up the token parameters and fetch the contract creator’s (owner’s) address. Also,
Invoke simply reads arguments and invokes an appropriate action.
Init function, you can see two interesting uses of the chaincode API:
- Retrieving a user’s address
- Storing it as the owner of the chaincode
There are no addresses in the Hyperledger network in the same sense as they exist in Ethereum or Bitcoin. You can use any identification method you like in Hyperledger Fabric.
The simplest is the built-in certificate authentication. We can use the certificate domain as the address since the MSP makes sure that each organization has a unique domain. In the end, the implementation for extracting information from a caller’s certificate to use it as the address looks like this:
After handling all of this data, we have to store it permanently in the ledger. We can use the Hyperledger key-value storage to do that. Both keys and values are completely arbitrary, and once written, they persist forever within the ledger. For example, to store and retrieve balances of users’ tokens, we need to do this:
At this point, we can define some data structures for function arguments and storage. Using Golang’s built-in JSON marshaling, we can store all of the data as JSON values and parse them as needed.
For example, when implementing delivery order placement functionality, we have to use two structures: one to receive as the parameter, the second to store delivery data in the ledger.
Once this functionality is implemented, we add an appropriate call from the
Invoke function so that users can actually execute the new code.
The rest of the functions are implemented in a similar way. At this point, you can focus on adding meaningful business logic and expanding the functionality. While the Hyperledger API for chaincode provides even more advanced tools, the ones described here are enough to get you started with building useful contracts.
For example, using the delivery data structure, token functionality, and owner’s address that we stored earlier, we can easily add a function for the owner to resolve a dispute between a courier and a customer:
Deploying the chaincode is very simple. First, we switch to a connected Docker container:
Then we run our deployed chaincode:
Let’s take a look back at our network configuration example. There are two organizations that both run an orderer. Each has a peer within a single channel. There’s a single chaincode running on this channel.
This configuration is far from a real-world scenario. In real life, we may have to deal with far more actors involved in network governance, much more complicated access policies, and probably some inter-channel communications between organizations.
We can improve the example network by adding extra organizations, introducing new channels between them, and deploying separate instances of the chaincode in the new channels.
Another simplification in our network is that the Hyperledger Fabric deployment happens on a single machine. Although you would still use Docker for deploying a real network, a more advanced script with proper separation of peers and orderers would be required.
However, other than the scale and deployment methods, our network and its functionality are fairly realistic. So it serves to demonstrate Hyperledger’s capabilities.
Of course, Hyperledger Fabric isn’t the only network that allows for the creation of custom on-chain business logic. Let’s compare our sample implementation to similar solutions based on different networks.
While comparing, we’ll mostly take into consideration the following factors:
- Effectiveness (based on performance and scalability)
- Development costs
- Ease of use
Usually, the go-to choice for creating any kind of application using blockchain technology is the Ethereum network. However, in this particular case, it may not be up to the task. The core logic of our sample application (creating delivery orders, paying for completed orders, handling refunds, etc.) is trivial to implement using smart contracts on Ethereum.
However, the basic Ethereum network applies Proof of Work consensus, which means that transaction processing takes a lot of time and energy. On the other hand, consensus in Hyperledger is much more efficient with a custom algorithm.
Some Ethereum implementations allow for adding Proof of Authority consensus as a plug-in consensus algorithm. However, it comes with the downside of increased production costs, as a new smart contract would have to be implemented for the permissioned functionality, which is present in Hyperledger Fabric by default. This would increase system complexity and lead to potential attack vectors and vulnerabilities.
Another good contender is EOS. It was originally based on the Graphene platform, adding smart contract functionality based on WebAssembly (WASM). EOS features performance similar to Hyperledger thanks to its Delegated Byzantine Fault Tolerance (dBFT) consensus algorithm.
However, just like Ethereum, EOS lacks permissioning features, which would have to be implemented manually. Also, EOS is limited in performance and functionality by its WASM virtual machine, while Hyperledger can leverage native performance with advanced functionality of the Go programming language.
Considering these factors, Hyperledger Fabric is the best choice over other more conventional networks. What Hyperledger lacks in decentralization it makes up for in flexibility, performance, and advanced features.
In this article, we highlighted major strengths and weaknesses of Hyperledger Fabric, briefly described the concept of the network’s architecture, and created a simple private network.
Hyperledger has unique functionality compared to other popular blockchains. Its permissioned nature, great access control, and scalability make Hyperledger Fabric probably the best choice for building a dedicated blockchain network.
At Apriorit, we use many technologies and tools, and we’re open to projects of any complexity. Our seasoned specialists are ready to develop an advanced blockchain-driven solution for your project.