Running a Validator Node and Bonding CAPS

Overview

Usually when people talk about being a validator they don't know that this is actually a three step process. The first step is to run a node in the validator mode, the second step is to generate session keys and the third step is to bond CAPS and to use our session keys in order to register our validator node.

In general going from the first to the last step isn't a difficult task and it can be done in 10 minutes. Just because this can be done really quick it doesn't mean anyone can do it. In the paragraph Before you start I have listed all the things that a person needs to know or needs to do before he can start this journey.

Before you start

Makes sure that you are conformable with using a terminal(console) and that you already have experience in debuging terminal errors. Besides knowing how to use the terminal it's also important to know how to manage virtual machines. Your node for testing superposes can be tested on your local machine but for doing anything more critical it's important to have the node running on a VM that has a high up-time.

If you have never used a terminal before or your struggle with it then this might not be something for you since you will encounter a lot of challenges that might cause more issues and problems.

Having said that, make sure that you have already compiled the project (in release mode) before and that you have the Ternoa binary ready to be used. There are instructions on how to do that for Ubuntu, Fedora and Arch in the readme file or in the dockerimages. If you are running a different Linux flavor or a different OS you will need to figure out yourself what dependencies to install in order to build the project.

Using the right flags

Once you have your binary ready, make sure that you place it in the right directory. For testing purposes it can be anywhere and for production environments it makes sense to place them inside /usr/bin/ or on a separate disk like /block/. In my case the root folder of my binary is /home/marko/Projects/test/. In the same folder I have created another folder which is going to stored the data that the node will produce. In a production environment you would want to store that data on a separate disk.

With the binary in the right place and with node-data folder ready, we can start our node by executing the binary with the following command and flags:

./ternoa --name MyRunningNode --validator -d ./node-data/ --chain alphanet

Let's go over those flags to see what they do:

• --name MyRunningNode: This sets the name of the node. This name will be visible in the telemetry data. Depending on what chain has been chosen, the node will be visible either here or here.
• --validator: This makes the node eligible to produce and finalize blocks. This also tells the node be in a archive mode which means it will store all the blocks instead of keeping only a few of them.
• -d ./node-data/: This tells the node to store the blockchain and blockchain related data inside the ./node-data/ folder. Besides storing all the blocks and the latest state, this folder will contains all the private keys that the node will generate.
• --chain alphanet: The last piece of information is to select a network which the node will connect. In this case alphanet is chosen but if you want to connect to Mainnet you would write mainnet.

Once you start the node you will immediately see that it starts to sync all the blocks. This can take a while (the duration depends on your connection and machine speed) but generally it should be under 12 hours. On the telemetry you should see your node in gray and the block number should be increasing just like in my case:

It's important to know if you plan to run multiple nodes that you in no case copy the node-data from one node to the other one. You could theoretically copy just the chain database from one node to speed up the sync process for other nodes but that is discouraged and there is a chance that by copying the whole node-data folder you will also copy the private keys of first node and put in danger your other nodes. Every single node needs to have it's own private keys and if you decide to share them the system will penalize you.

Having said that, congratulations to you because you are now officially running a validator node. Does this makes you a validator? Ehmm, not yet.

Generating the session keys

I am not going to go into too much details on what are the sessions keys and why do we need them but it's good to know that some math operations like building and finalizing blocks require us to provide a private key to do it. There are couple of those math operations that need that kind of input and all those private keys mashed up together we call session keys.

To generate all those private keys we just need to have our node up and running and we need to execute the following command:

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933

The output of this command is a JSON formatted data that includes our session keys inside the result field. This output should be stored somewhere safe since it will be used later. Example of the command output:

{"jsonrpc":"2.0","result":"0x497804e4cd969a3c99d1a475e66a7f31c98fc7fc92a55bc0807a7146dc305688fac684581c33c1c35b315fbcf56d5b1b6ab5b7e14183c4e2c817d97904c4420eee64168d476aece50b8a9335647df7afcb37930e336ed48c3ceb71ca0ea151208e396798021accbb4559afb461bbc0783a153d8947ea9f32bf547e7c1e9ebc16","id":1}

Besides this output we can cd into /node-data/chains/alphanet-live/keystore/ and see for ourselves that those keys are really generated and stored.

One more step and we are done. The next part is done via Polkadot JS APPS UI so we don't need to use the terminal anymore (unless you use W3M 😄 )