How to run a validator node?

For a quickstart setup, follow the instructions here on how to run a validator node. For a more detailed look into running Ternoa nodes, view our video below.

Make sure to fully read the guide before you start doing anything. To follow along during our workshop, the guide is here, and you can skip to 9:17 in the video to begin.

---

Getting the binary (node/client)

There are two ways to get the binary: from the GitHub repo or to build it.

The easiest approach is to directly get the binary from the Ternoa chain GitHub repo. From the GitHub repo website, click on the Releases link and find the latest release with a binary attached to it.

The second approach is to manually build the client. You can follow the how-to-build-this-repo guide to understand how to do it. My recommendation is if you are going to follow this method, make sure that you have at least a quad-core CPU otherwise it will take ages to build.

Whatever method you choose, make sure that once you have the binary you place it in the right directory. Usually, the place is usr/bin or /opt/ternoa.

---

Running the node

The key in correctly running the node is to use the right flags to connect to the right chain. Ternoa is currently running two networks, Ternoa Alphanet and Ternoa Mainnet, and depending if you want to deploy a test validator or a mainnet validator you need to pass either --chain alphanet or --chain mainnet, respectively.

Here is an example on what flags you can/should use:

/usr/bin/ternoa --name MyFirstNode --chain alphanet --base-path /opt/node-data --validator --state-cache-size 0 --execution wasm

Let's see what those flags do:

• name X - It sets the name of the validator node. X should be something unique.

• chain X - X can be either alphanet or mainnet. This tells the node which chain specification to use.

• base-path X - Defines where the blockchain data will be stored. If have an external disk attached, you that external disk for storing the data.

• validator - This runs the node in validator mode

• state-cache-size 0 - This fixes a bug that Substrate has.

• execution wasm - This runs the node in wasm mode. This is also used to fix a bug that is introduced in the Substrate's native runtime.

We recommend that you create a systemd service file that will run the node in the background and start it up on every restart. Instructions for that can be found in the linked workshop presentation here.

Once the node is running, it will be visible in the telemetry UI and it will take time to sync up

Alphanet Telemetry UI

Mainnet Telemetry UI

While it's syncing up, you can run the following command to generate the session keys:

$ curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 &> session_keys.txt
# The session keys will be stored inside the session_keys.txt file. Let’s printout that file.
$ cat session_keys.txt

The session keys are stored inside the "result" field. Make sure that you store it somewhere safe since it's going to be used in the next part of this guide.

To make sure that the session keys are properly inserted, stop the node and start it again. This is quite important to do because otherwise, the final steps in this guide might not work.