Reasonable Problem in HL Fabric configuration

Since Hyperledger is opensource community driven,   There are several reasonable problems that not to fit to one stand.  however this may give variety of options for the adapters who want to build their network upon use cases and deploy the blockchain. These reasonable problems can be categorized into different types ,  Below table shows all the reasonable problems. We will discuss them in detail.

I. Functionality

Some of the reasonable configurations will cause functionality problem for the network. Functionality problems may include absence, failure of  function or even crash of the network. The followings are some functionality reasonableness problems which may be caused in Fabric network.  

Docker Swarm vs Kubernetes

Since the container orchestration is the process of automating the deployment, management, scaling, networking, and availability of your containers, the demand for container orchestration has skyrocketed in the past few years and many of them were adopted for production too.

Docker swarm are more suitable for small scale to started with containers where k8s(kubernetes) are used  highly complex distributed networks and provides comprehensive enterprise-grade container, cluster management services and automated deployment. Meanwhile docker swarm not have advanced functionalities like built-in logging and monitoring.

Connection Profiles

A connection profile contains a description of a network view, expressed in a technical syntax. Its used at backend to App and the blockchain network representing the channel, organisations, etc. Profiles are created with static or dynamic gateways, Static needs more information than dynamic gateways because the latter can use service discovery to dynamically augment the information in a connection profile.

A static connection profile is normally created by an administrator who understands the network topology in detail and contain quite a lot of information, and an administrator needs to capture this in the corresponding connection profile. In contrast, dynamic profiles minimize the amount of definition required and therefore can be a better choice for developers who want to get going quickly.

Adoption of CouchDB vs LevelDB.

There are two types of state database for Fabric. The advantages of LevelDB is it has high performance and ease of maintenance. Meanwhile CouchDB can support rich query.  For the developers and administrators, they must choose the suited state database based on their real specific requirements and scenarios. Unreasonable choice of state database will cause low efficiency and limited functions.  

You still allowed to use your own Database like mysql/mariadb

Inconsistent parameters

There are many parameters in Fabric network configuration. Developers can pre-set and modify any parameters before they construct the whole network based on some parameters and  configuration files. In these parameters, some are correlated with each other. If there are inconsistency parameters, it will cause some problems in bootstrapping network constructing process.  

For example, the DOMAIN information must be consistent both in crypto-config.yaml file and docker-compose.yaml.


Above Fig.  shows the instance configurations in a specific Fabric network.  In this two Yaml files, the sub domain "" must be consistent otherwise there could be potential problems in the network.

The crypto-config.yaml calling the parameters as Domain  and Docker-compose file calling as Container_name / core_peer_id

Ordering Service

Consensus mechanism As we know, Fabric supports multiple consensus methods, Solo, Kafka and Raft.  Solo implementation is intended for test and only supports single orderer node and Raft are crash fault tolerant(CFT) ordering service with multiple nodes. However, there can be only single orderer Consensus Mechanism method in the network. Developers should be advised to use Raft ordering service in their network for the long term goal, Since other two get deprecated from 2.x

Parameter - hard-code vs dynamic

Developers may leave some parameters hardcoded in configuration files. The hardcoded parameter will cause difficulties in debugging and the experiments.

docker-compose-ca- key hardcoded

Above Fig shows an example of unreasonable hardcoded configuration and the reasonable one in a CA container. If the private key is changed, developer must modify the private key manually to fetch the new keys. whereas in the below fig. developers can set a variable name calling the file name through the parameter without modifying any information manually

docker-compose-ca - key not hardcoded- dynamic

II. Security

There are also some parameters which related with security of the whole network.

TLS - Transport Layer Security

It’s a kind of cryptographic protocol which is designed to provide transportation security in a computer network. TLS used for secure communication between entities, such as nodes and clients.

 In Fabric, user can turn on TLS for peer nodes, orderer nodes and peer CLI. Meanwhile, the related clients also must turn on TLS as well as the nodes which they communicate with. By default, TLS client authentication is turned off  both and will not verify the certificate of a client, for example another node, application, or the CLI, during TLS handshake. So from a secure perspective point of view, developers should turn on both TLS and TLS client authentication.

State database security

Since the CouchDB is implemented as a separate database process in the outside of peer. the network samples (Older versions), user name and password for the CouchDB container are all left empty. And that will be very insecure because everyone can access the state database, even modify the chaincode data value to cause the inconsistent of ledger data. so developers have to keep in midnd to configure the authentication information respectively for the peer container and CouchDB container

III. Performance

Some configuration parameters are related with performance of the whole network. Unreasonable setting will cause low efficiency.

Simple vs Complex chaincode endorsement policy

Endorsement policies defines the peers in specific organizations which must endorse the execution of a transaction proposal.

Simple chaincode endorsement policy will bring security problems. For example, when the policy is defined with  simple endorsement with ‘OR(ORG1, ORG2)’, users could choose any single peer from either ORG1 or ORG2.  Otherwise, specify a more complex endorsement policy with 'AND(ORG1, ORG2)' (such as requiring that one more organizations) which is safer because the adversary must invade all related peers .

Complex endorsement policy may cause low efficiency,consume more computing resource  because clients must collect all endorse results,commit, and validate from multiple peers to satisfy endorse policy.

BlockTime / BlockSize

They are the most important parameters related to network performance. BlockTime is the amount of time to wait before creating a block. BlockSize is the number of messages batched into a block.  If BlockTime is set too big, clients must wait a long time for every transaction in low pressure situation, although enough transactions can be batched into a block in high concurrency situation. Meanwhile if BlockTime is set too small, the situation goes to the contrary. Clients may not need to wait too long in the low pressure situation, but the ledger will be divided into more blocks in high concurrency situation. Otherwise, it will cause low efficiency especially for the network transmission.

For the high concurrency situation, big BlockSize will make more messages into a block, that will reduce the network cost to improve efficiency of network. As a contrast, for the situation with small BlockSize and low pressure, clients will wait for less messages to reach  BlockSize, that’s much easier and more quickly. For the high concurrency, just like the small BlockTime situation, the block will be divided into many smaller blocks, it’s very time-consuming for network transmission.

Think the effect on performance of BlockTime and BlockSize is also related with network load and network latency. However, too small or too big value should be unreasonable.


As the permissioned blockchain system, there are various types of components in Fabric. We focus on the reasonableness problems of Hyperledger Fabric framework. It’s difficult and time consuming to make sure that all the network configurations are reasonable and satisfied application requirements, even for the veterans who are familiar with Fabric. However, there is still many work to do about reasonableness problem.

The reason we focus on the static configuration is that once network is running, many configurations will be immutable or very difficult to be modified. Hence it can help people to understand their network more deeply, especially for the beginners and new developers/administrators of blockchain system.  Each pattern is corresponded to a specific reasonableness problem.

In coming days, will consider to focus on the dynamic configurations in fabric network reasonableness for newer versions

With consideration of  all reasonableness, I created a small automation script (dynamic) based on HLF version 1.4.3 and quick demo for your ref.

Sources  & inspired reading by