Polkadot wave card chain: verifier node cloud deployment tutorial

Polkadot has the vision of a heterogeneous multi-chain framework that connects multiple parallel chains and implements Dapp and smart contracts on a blockchain x system to seamlessly trade data and assets across other chains.

My first exercise was to deploy the Polkadot Verification Node as a dockerized cloud instance. I call it "Hello World of the Polkadot framework." In the connection and synchronization verifier nodes of the Polkadot "Krumme Lenke Test Network" (which reflects the project's POC-2 status), the existing 1.5 million blocks are synchronized for several hours.

In the screenshot below, you can see my node "clb-polkadancer", which is connected to 24 peer nodes, processes a new block every 5 seconds, and adds it to its local blockchain. (Telemetry user interface).

Note that this article describes the instantiation of the polkadot validator node on Docker. To convert it to a fully trusted polkadot certifier node, the node actively participates in the Equity Proof (POS) negotiation process – additional steps are required and will be covered in another blog post.

The certifier is one of the four basic roles of maintaining a polkadot network. The other three roles are;

  • Collector
  • Nominee
  • Fishermen

The four roles and their interactions are described in the white paper as follows:

The role of the certifier depends on whether there is a high enough margin deposit, although we allow other guarantors to designate one or more certifiers to be agents, so the certifier's partial margin may not necessarily be owned by the certifier itself, but Owned by these nominees.

So what is the main task of the verifier?

The verifier must run a relay chain client implementation with high availability and bandwidth. In each block, the node must be prepared to accept the role of approving the new block on the specified chain. This process involves receiving, verifying, and republishing candidate blocks.

There are two new concepts that introduce "relay chains" and "parallel chains" and are the core concepts in polkadot. Let's try to explain them quickly with a summary of the white paper:

Polkadot provides a basic "relay chain" on which to host a large number of verifiable, globally consistent dynamic data structures in parallel. We call these data structures parallel.

Therefore, our validator nodes are part of the relay chain, receiving blocks, and if the blocks belong to our managed parallel chain, they are validated in a parallel chain database that is packaged and fully synchronized. If the block belongs to a parallel chain that is not in our range, then

The validator node will assign a task to a third party in another parallel chain called a collator .

If you wish to be nominated as an approved verification node, you must ensure that the node is running 7×24 in order to keep pace with the development of the global parallel chain. Otherwise, the fishermen will find this bad behavior and punish them, and may kick you out of the role of consensus verifier.

As shown in the figure below, a new block is processed approximately every 5 seconds with a propagation time of 502 milliseconds. Your node must be prepared to process and propagate such requests in a timely manner.

Prepare the validator Dockerfile

All of my cloud projects (whether Java-based Bot or Meteor Node.js-based front ends) I run in a Docker container. This allows me to standardize and automate deployment and runtime configuration and tuning.

Polkadot has provided its own Docker Image "chevdor / polkadot", which is based on "phusion / baseimage: 0.10.1", which maps to the latest Ubuntu version 18.04.

Jelastic PaaS does not provide Ubuntu 18.04, so I changed the Dockerfile to Ubuntu 16.04 based and supported by Docker Hub called "talfco / clb-polkadot";

Configuring the Validator Docker instance

In Hidora PaaS, I created a new Docker Environment "polkadotDocker" and loaded my clb-polkadot Docker image from Docker Hub.

The initial instance configuration for the resynchronization phase is 4-5 cloudlets, which are converted to CPUs between 1.6 GHz and 2.0 GHz with 512 MB to 640 MB of memory.

I configured the Polkadot database directory to be kept on the server's local file system so that our full parallel chain database will not be lost after redeploying the new docker image.

Finally, I added the -name'clb polkadancer' parameter to the entry point.

Run verification node

I started the instance and the log file shows the progress of the synchronization.

Create a copy of the parallel chain DB

As a first step, the Validator node must build a complete parachain DB on the local node.

As can be seen in the screenshot below, the chain build phase is completed at approximately 14:30, using almost all CPUs. When completed, CPU usage drops to 200-250 MHz. To build a complete parallel chain of approximately 5 million blocks, it takes 6 hours of processing time. The overall disk consumption is approximately 5 GB.

Once the complete parallel chain is loaded, you can reconfigure the instance. The first instance of the test configuration included 2 cloudlets, which were converted to 256 MB RAM and 800 MHz CPU.

Cloudlets adjustment

An evaluation of the runtime statistics shows that our node's RAM limit (256 MB for 2 Cloudlets) is always the highest, which results in additional dynamic Cloudlets charges, which is sub-optimal.

Finally: don't forget to open port 30333

As you can see in this screenshot, some nodes are only connected to half of the parallel chain nodes (24).

This article reprints the public number: Blockchain Research Laboratory-Haina College will focus on: blockchain technology, product community, economic model and other comprehensive knowledge system output. Feel free to contact the author WeChat: csschan1120