Hyperledger fabric is a popular choice for enterprise use cases and a top blockchain protocol for private permissioned blockchain implementation. But, unlike the public blockchain networks like Ethereum, setting up a Hyperledger Fabric blockchain network is a complicated task. It requires execution of calculated decisions beforehand, some of which are permanent and cannot be altered. It is crucial for your network/application performance and even breaks the purpose of using blockchain itself. All these challenges call for a proper evaluation of various factors before you start deploying hyperledger fabric in blockchain network.
In this article, I have discussed some of these factors to evaluate the fabric network configuration, strategy, tools, and steps for deploying your blockchain hyperledger fabric.
1. Hyperledger Fabric in the Blockchain Network: Network Configuration
Multiple factors control the decisions involved in configuring a hyperledger fabric network. While designing your hyperledger fabric network, you have to be extra careful about the tradeoffs of those factors.
The hyperledger fabric in the blockchain network will not exist in any meaningful sense unless and until organizations contribute the resources that form it. Moreover, the network should not depend on any individual organization. Even if a single organization remains in the network, it should continue to exist without depending on which organization comes and goes. Thus, this is an essential attribute for the network to be decentralized. Here are some component-level decisions one has to take while building a fabric network:
- Peer & Orderer nodes – The hyperledger fabric blockchain network is built from the nodes owned and contributed by the different organizations. More nodes ensure high availability, but it increases infrastructure costs.
- Certification Authority (CA) – It is recommended to use a separate CA for each organization. One might decide to use this CA to function as an intermediate CA, which is associated with the root CA, or as the root CA itself. In the production environment, have a TLS CA to generate the TLS certificate and enable the Transport Layer Security for the nodes. Deploy the TLS CA before the enrolment CA.
- Channels – Organizations belonging to the same channel share an identical copy of the ledger; they collectively collaborate to manage the shared ledger associated with that channel. Also, organizations within the channel can create private data collections, allowing a defined subset of organizations on a medium to endorse, commit, or query private data without having to create a separate channel. You can choose what’s best suited for your use case, having private data collections or more channels to ensure privacy and isolation for certain transactions.
- Database type – Fabric provides the option to use CouchDB or LevelDB to store the ledger state data. When speed is the priority, LevelDB is better suited, but when it is required to perform rich query operations on the data, one should go with CouchDB. There are restrictions on keys and values imposed by CouchDB, and what’s valid for CouchDB may not be accurate for LevelDB. For this reason, channels should not have peers using both CouchDB and LevelDB.
- Container orchestration – Various processes continuously run to serve the hyperledger fabric blockchain network. These processes could be CouchDB, peer, orderer, gRPC communications, logging, chain code, etc. One can decide to have all these processes in an individual container or combine some into a single one.
- Chaincode deployment method – Fabric provides built-in support for building and deploying chaincode. Still, if a custom builds and run is required, it can also be done using External Builders and Launchers, and there is also an option for running chaincode as an external service. In external chaincodes, instead of building and launching the chaincode on every peer, the chaincode runs as a service whose lifecycle is managed outside of Fabric.
Each organization will have its own infrastructure for the production environment to run these network components. Based on the use case, requirements, and the above points, the organization can choose which blockchain network components they need to own and manage within their network infrastructure.
Learn more about Use Cases of Blockchain Across Industries
2. Hyperledger Fabric in the Blockchain Network: Setting up non-production environments
To develop the hyperledger fabric smart contracts and client applications, replicating a multi-org, distributed network setup is very much necessary to test the app and contract in a production-like environment. But having these multiple org network components in different clusters will complicate things for the development environment.
We can have a single cluster network setup where namespaces can logically separate the components of each org. Every org will have a dedicated namespace, and all the hyperledger fabric network components for that organization will be part of that namespace. In this way, we are replicating multi org distributed network setup, which is also more development and cost-friendly.
Apart from the development environment, we may also want a different/isolated environment for tests, stages, etc. We can have a shared ecosystem where all these environments can exist simultaneously. To achieve this co-existing setup, we can have separate fabric network channels for each development stage. Having independent channels ensures that the data/source for the development environment is isolated from the test environment because a different channel creates a separate ledger in itself. So with this approach, we will have multiple channels consisting of the same hyperledger fabric network components (peer, orderer, and CA). This way, we can save on the infrastructure cost by sharing the network components for all of these environments.
3. Hyperledger Fabric in the Blockchain Network: Component deployment and management tools
Properly configuring and deploying hyperledger fabric to Kubernetes is not a trivial task, and it is also just one part of the puzzle. Populating the Fabric network regarding channels and chain code is also as important as launching the hyperledger fabric network in the blockchain. In the article, I’ll talk about the readily available helm charts that greatly simplify and automate the earlier tasks.
Another way to launch a hyperledger fabric network in the blockchain is by using the hlf-operator. It is a Kubernetes plugin that provides a declarative way of creating hyperledger fabric components. The operator has a wide variety of features that helps in the end-to-end deployment and management of hyperledger fabric network components. The hlf-operator has particular, abstract, and imperative commands, saves a lot of initial bootstrapping, and makes the fabric component deployment task easier.
4. Hyperledger Fabric in the Blockchain Network: Using Helm Charts
Packaged charts for deploying fabric nodes and CA are available in the ArtifactHub, distributed community Helm Chart repository. These charts are very much configurable and easy to use, the documentation is well, and it’s also properly maintained. Following hyperledger fabric network in the blockchain component charts are available:
- hlf-ca – hlf-ca is a Certificate Authority node for hyperledger fabric. The installed CA can act as a root CA or an intermediate CA. An intermediate CA’s parent can be a Root CA or an intermediate.
- hlf-ord – hlf-ord is an Orderer node responsible for “consensus” among the fabric nodes. The Orderer can be installed as either a solo orderer (for development), a Kafka orderer (for crash fault-tolerant consensus), or a draft orderer (etc. to maintain the state and raft, which is a leader/follower type consensus algorithm).
- hlf-peer – hlf-peer is the Peer node responsible for endorsing transactions and recording them on the fabric blockchain.
- hlf-CouchDB – The fabric Peer can either use a goleveldb or a CouchDB database for holding the ledger data. hlf-CouchDB chart utilizes a modified version of CouchDB suitable for hyperledger fabric applications.
These charts are forked from the one by AID: Tech and are currently not directly associated with them or the hyperledger fabric network project.
Although these charts provide many configuration options, it is possible in some cases you may have to modify the chart source to make it applicable to your needs. For example, you may want to use an external storage service to store your node’s certificates and keys and pull these confidential data while deploying the nodes. To achieve this, you’ll have to add a configuration file in the charts template, which will be of the ‘ExternalSecret’ kind, and do the necessary changes in deployment.yaml and the values.yaml file.
As discussed earlier, there is a possibility to have an entire hyperledger fabric blockchain network in a single cluster by logically separating every organization’s network components with namespaces. With a few simple modifications, charts can use these charts to deploy nodes, DB, and CA for multiple organizations. One possible change could be to have every orgs configuration in a separate value-orgname.yaml file, which can be referred to when deploying the hyperledger fabric network component of that particular organization.
These readily available charts will help you in component deployment; now, in fabric network setup, we will interact with these deployed components to create identities, register and join channels, install chaincode on peers and then approve their usage on channels, etc. The step-by-step instructions to complete these tasks are finely documented on hyperledger fabric docs.
Different organizational component administrators must do most of these tasks multiple times. This can be easily automated using scripts, so one doesn’t have to repeat the same set of instructions over and over again. Running these scripts will require many additional data, for example – organization/peer/orderer admin MSP, genesis block for channel creation, chaincode source for installing/deploying chaincode, etc. It will be efficient to have custom Helm Charts to deploy temporary containers for each task. The task scripts will be encapsulated inside the corresponding temporary container, with the required additional data inputs. Once the task is performed completely, we can delete its container. This helm chart encapsulation will abstract many details and simplify the process.
Steps to setup components and the hyperledger fabric in the blockchain network
In this section, I’ll give an overview of the steps involved in setting up components and establishing the hyperledger fabric blockchain network. All the steps below can be developed using a Helm Chart or hlf-operator, but the explanation of the actions in this article is a bit more inclined toward the Helm Chart usage.
Bootstrap
You can see in the Helm Chart docs that it has some prerequisites, which expect some Kubernetes secrets and configmaps to be available in the cluster namespaces. Before deploying any network component, those can be made available in the bootstrap step.
Setup CA
At the very beginning, the CA server needs to be available so that we can create MSPs for various hyperledger fabric network components. It is recommended to deploy at least two CAs in a production network, one for the enrollment purpose and another for the TLS certificates. The enrollment CA will be used to generate enrollment identities for users, org, nodes, etc. The TLS CA will produce TLS certificates for secure communication between the components.
The registered users are stored in a database by the Fabric CA server. The chart mentioned above is configured to use an in-memory sqlite3 database. To use an external database (Postgres or MySQL), you can enable and configure the external database section in values.yaml of the hlf-ca chart.
Use CA to create MSPs
Once the CA server is set up, you can generate certificates for the identities and components related to the organization (represented as MSP). It can be done by using fabic-ca-client cli. With the proper credentials, fabric-ca-client binary lets you interact with the CA server so you can register and enroll ids, revoke certificates, and so much more.
As mentioned before, there are multiple orgs and many components for each org, so you’ll be running similar commands over and over to create MSPs. Automate this task by using shell scripts, and it can be encapsulated inside a ca-client Helm Chart. This client chart will need all the credentials and certificates to communicate with the CA server.
If you decide to use an external secret service to store the certificates, this should be the right time to move the generated certificates to the external storage.
Start CouchDB services
Fabric peer nodes can use LevelDB or CouchDB to store the ledger data. LevelDB is the default key-value state database embedded in the peer process. On the other hand, CouchDB is an alternative external state database.
You should use CouchDB if your use case requires rich query operations on ledger data. Start the CouchDB service before starting the peer node, so it can be configured to be used by the peer node.
Generate Genesis Block
If you are using fabric v2.2, it is a must to have the orderer system channel. The organizations with permission to create channels are listed in the orderer system channel and are maintained by the orderer admins. Before starting the orderer node, this channel’s genesis block must be included in the node configuration.
From the fabric v2.4, system channels have been made optional, and it does not require to be added to the system channel genesis block in the node configuration. You can directly start with generating a genesis block for the application channel.
In both cases, the genesis block will later be submitted to the orderer in the channel join request. The genesis block is created once by any of the organizations, and then it is shared with other orgs out of the band. After receiving the genesis block, the other channel members can inspect the channel configuration and ensure that they agree to it.
Create the genesis block using the configtxgen tool; check out Channel Configuration (configtx) to learn about the tool.
Deploy peers and ordering nodes
After gathering certificates and MSP’s you’re almost ready to deploy your nodes; one remaining step is to customize the configuration files. The configuration files are called core.yaml and orderer.yaml for peer and orderer. Find the sample configuration files in the sampleconfig directory of Hyperledger Fabric.
After core.yaml and orderer.yaml has been configured and your deployment backend is ready, you can start the peer and orderer node by installing the Helm Chart in your cluster.
Join channel
The orders and peers must join the channel of the participating consortium organizations.
Orderers can join the channel by using the osnadmin binary. The osnadmin channel command allows administrators to perform channel-related operations on an orderer, such as joining a channel, listing the channels an orderer has entered and removing a channel. The orderer admin user can perform this task by executing “osnadmin channel join” command.
Similarly, peer administrators can use peer binary to join the channel. The “peer channel” command allows administrators to perform channel-related operations on a peer, such as joining a channel or listing the channel to which a peer is joined.
Install chaincode on peer nodes
In this step, you have to package the chaincode and install it into the peer nodes. Chaincode must be packaged in a tar file before it is installed on the peer. Packaging can be done by using fabric peer binary.
The packaged chaincode is then installed on the peers that will execute and endorse the transaction. The installation is done by using the peer administrator’s identity using peer cli. After installation, the peer builds the chaincode and returns if there is an error. If one organization has multiple peers, it is recommended to package the chaincode once and install the same package to all the peers. Also, in each peer node, chaincode is to be installed once, and it can be deployed to multiple channels in case it’s required.
After successful installation, it returns a chaincode package identifier. This identifier is used while deploying the chaincode on the channel. Later, the identifier can be fetched using the ‘peer lifecycle chaincode queryinstalled’ command.
If you’ve decided to use chaincode as an external service, follow this Chaincode as an external service documentation to get the detailed deployment instructions for external chaincode.
Deploy chaincode on the channel
You have already installed chaincode on peer nodes; the next step is to get the approval of organizations on the chaincode definition so that chaincode can be used on the channel.
The chaincode definition is to be approved by the member organizations for it to be used by a particular channel. Once the organization administrator approves the chaincode definition, it is distributed across all the peers. This approval process must be done only once, even if the organization has multiple peers.
For approving the chaincode definition, the administrator will need the package identifier of the chaincode, which can be fetched by ‘peer lifecycle chaincode queryinstalled’ command, after getting the package identifier administrator can use ‘peer lifecycle chaincode approveformyorg’ command to approve the chaincode definition.
Any one of the member organizations can commit the chaincode definition on the channel after getting adequate approvals from the members. The peer cli has checkcommitreadiness command, which helps to check whether there are sufficient approvals available and committing the chaincode definition will be successful. If adequate approvals are there, then any of the org administrators can use “peer lifecycle chaincode commit” command to commit the chaincode definition on the channel.
Know more about Top Blockchain Technologies
Final words
This article explored network configuration considerations, an approach to set up a non-prod environment, tools, and steps to deploy the hyperledger fabric blockchain network. I hope this article gave you a better understanding of designing and deploying the same.
Once the hyperledger fabric blockchain network is up and running, you must take regular data backup of various network components. Taking backup is always a good practice because it saves you from unexpected crashes/errors/natural disasters and human errors. Learn more about Hyperledger Fabric data backup in our upcoming article.
With a track record of building 180+ tech products over the last 20 years, we’re here to help startups use blockchain technologies to solve real-world issues like privacy, decentralization of trust and scalability. Explore more on our Blockchain Development Page for details.
