Build A Minimal Quorum Network
Setting up a minimal Quorum network with Raft consensus for developing using Docker
The Aim of this Article
The main aim of this article is to show how to set up and dockerize a simple Quorum permissioned network for developing. Our goal is to minimize the needed resources and time by the developer, by using only 3 nodes and the Raft algorithm. Besides that, we provide the full source code on our GitHub repository.
To follow the setup steps you need to install Docker and Docker Compose (version 3.6). We consider rudimentary knowledge of Docker a requirement for appreciating this article.
What is Quorum and what makes it important?
Quorum is an open-sourced permissioned Blockchain Platform, which is built based on the Ethereum technology. By combining the innovation of the Ethereum community and features that support enterprise needs, Quorum aims to achieve a trusted technology that puts blockchain to work for business.
Not only because of the support by JP Morgan and Microsoft, but also due to its useful features, Quorum can be considered one of the preferred Blockchain platforms for enterprises. The most known feature of Quorum is the enabling of private transactions. However, Quorum has more to offer like network and peer permissions management, better performance, developer support, and — maybe the most underrated feature — a pluggable consensus algorithm. At the time of writing, Quorum supports two major consensus mechanisms, IBFT (fault-tolerant consensus) and Raft (crash-tolerant consensus). Even more consensus mechanisms will be implemented in future releases. IBFT and Raft lead to faster consensus and provide immediate transaction finality, which makes them a suitable choice for business’s needs.
Problem statement
As we tried to set up a local quorum network to test if our application is also compatible with Quorum, we started with the 7-nodes example provided on the Quorum repository on GitHub. That example provides two methods to run your local network, either you use Vagrant or Docker. Docker was our choice because we already had more experience using it. The long troubleshooting list and time needed to set up the network using Vagrant made the decision even easier.
However, running that example with Docker also brought up some issues. The docker-compose file starts 15 Docker containers, 7 containers for the nodes, 7 containers for the transaction managers and 1 container for the example. All those containers must be run simultaneously, which results in a high demand of memory and CPU resources and may not suit a development environment.
To test that setup, run the example using Docker
git clone https://github.com/jpmorganchase/quorum-examples
cd quorum-examples
docker-compose up -d
The minimal setup
So, let us start with implementing the docker-compose file:
First, we must set the configuration fragments, which will be used in all nodes. Those reusable fragments start with the x-
character sequence and can be merged in the services using the YAML merge Type <<
At line 4 we define the Docker image that will be pulled from the public Docker Hub repository, at the time of writing this article the current version is 2.3.0. After that, lines 6 and 7 define the exposed ports 21000 for the node client and 50400 for the raft communication between the nodes. The node client in Quorum that will run and manage the node on the containers is Geth, which is a GoLang implementation of the Ethereum protocol. At line 8, we set up a simple healthcheck, which checks the health of the container every 4 seconds by running a command inside it, on the given port 8545. Later when we start the containers we will notice the message (healthy/unhealthy) in the STATUS column, we can also get the container health with the command:
docker inspect — format=’{{json .State.Health}}’ <container-name>
At line 16 we have the entrypoint, below that are the scripts that will run after the container start, like first copying necessary resources (node files and genesis block file) from the host to the container, set some variables and also starting Geth at line 33. Notice that the following additional arguments are needed in addition to the default Geth configuration to enable Quorum specific features.
--permissioned \
--rpcapi ..,..,..,..,..,quorum,raft\
--raft \
--raftport 50400 \
As we mentioned before, Quorum supports two consensus algorithms IBFT or Raft, Raft was our choice. According to the following performance evaluation in this article, Raft performs slightly better at higher input transaction rates, the block time can be set for less than 1 second, and also the minimal required number of Nodes is 3.
Now we need to define the Services :
The code above shows only the service of the first container. As we see in line 3 we use the above-defined quorum configuration. At line 6 we make the first node available at port 22000 by mapping the port 8545 (see Geth argument: rpcport) to 22000. For persistent data, Docker data volumes are set at line 8 and 9. It is also important to set PRIVATE_CONFIG to ignore at line 11 because we are not using the privacy feature of Quorum (which needs the transaction manager component). Line 13 sets the Docker network on which the container will run, and that network is defined at line 16. The services of the second and third containers are similar. The complete version of the compose file can be found here.
Running the network
At this point, we are done and have a local quorum network, which can be started by the following commands:
git clone https://github.com/51nodes/quorum-local-raft-network.git
cd quorum-local-raft-network
docker-compose up -d
To check if the containers are healthy and running use the command:docker ps
To use the console of the node client Geth of the first node:
docker exec -it quorum-local-raft-network_node1_1 geth attach /qdata/dd/geth.ipc
To test the network using Remix set the following environment variable before starting the containers:
export QUORUM_GETH_ARGS="--rpccorsdomain https://remix.ethereum.org"
To connect remix to your local network, you need to change the environment under ‘Deploy and Transactions’ to Web3 Provider, and set the endpoint of one of the nodes:
51nodes GmbH based in Stuttgart is a provider of crypto economy solutions.
51nodes supports companies and other organizations in realizing their Blockchain projects. 51nodes offers technical consulting and implementation with a focus on smart contracts, decentralized apps (DApps), integration of Blockchain with industry applications, and tokenization of assets.