Skip to content

Run a Block Producer Node Using Systemd

Introduction

One of Tanssi's core propositions is that it provides decentralized and trustless block producers (also referenced as sequencers or collators) for its appchains. Tanssi's runtime handles block production assignments to all the active appchains in the Tanssi ecosystem and Tanssi itself.

Each time, the assignment algorithm distributes the available block producers per session, assigning them to a random chain (Tanssi or appchain). Consequently, they would be producing blocks for the same appchain only for a relatively short period, increasing the overall security of the ecosystem.

To this end, Tanssi's binary file (the software used to run nodes) already has an embedded mechanism to switch block production automatically to the assigned chain without requiring the node operator to make any changes. The binary includes the logic to sync the new chain and produce blocks when the session changes. Consequently, block producers need to run the Tanssi binary file, and not that of the appchains (like full nodes).

In this guide, you'll learn how to spin up a Tanssi block producer to be part of the shared pool of sequencers using the latest stable binary file release and managing the service with Systemd on Linux systems.

The article follows the good practice of running the service with its own non-root account and granting that account write access to a specific directory. However, you can adapt this article's steps and instructions to your infrastructure configuration, preferences, and security policies.

Hardware Requirements

To run a block producer successfully, using top-of-the-line hardware is a must. Using subpar configurations might cause the node to lag behind, missing authoring rounds and their associated rewards.

Since the block production/import process is almost entirely single-threaded, a higher single-thread performance provides better results than a higher core count.

The following are some hardware recommendations that have performed well:

  • Recommended CPUs - Intel Xeon E-2386/2388 or Ryzen 9 5950x/5900x
  • Recommended NVMe - 1 TB NVMe
  • Recommended RAM - 32 GB RAM

Warning

You are responsible not only for your own stake but also the stake of your delegators. Monitoring your block producer performance and keeping it up to date and secured correctly is critical to maximizing rewards and building up your reputation.

Running Ports

As mentioned in the Introduction, block producer nodes will be assigned to produce blocks for any active appchain in the Tanssi ecosystem or the Tanssi protocol itself. To accomplish a successful block production, the node must be able to sync and participate in three different peer-to-peer (P2P) networks. This requires the following three ports to be open to incoming communications from any origin:

Network Port
Tanssi Chain 30333 (TCP)
Relay Chain 30334 (TCP)
Assigned Appchain 30335 (TCP)

Checking Prerequisites

To get started, you'll need access to a computer running an Ubuntu Linux OS and root privileges. You will also need:

  • Node binary file - the instructions in this guide execute the latest official stable tanssi-node release. However, you can build your own file compiling the source code

Download the Latest Release

To get started, download and make executable the latest binary release by running the following command:

Note

For better performance, it is recommended that you run the optimized binary versions for either Intel's Skylake or AMD's Zen3 architectures.

wget https://github.com/moondance-labs/tanssi/releases/download/v0.8.1/tanssi-node && \
chmod +x ./tanssi-node
wget https://github.com/moondance-labs/tanssi/releases/download/v0.8.1/tanssi-node-skylake -O tanssi-node && \
chmod +x ./tanssi-node
wget https://github.com/moondance-labs/tanssi/releases/download/v0.8.1/tanssi-node-znver3 -O tanssi-node && \
chmod +x ./tanssi-node

Setup the Systemd Service

Systemd is a management system for Linux systems that manages services (daemons in Unix-like systems jargon), starting them automatically when the computer starts or reboots, or restarting them upon unexpected failures.

The following commands configure a new account, the directory, and move the previously downloaded files to the right location.

Create a new account to run the service:

adduser tanssi_service --system --no-create-home

Create a directory to store the required files and data:

mkdir /var/lib/tanssi-data

Set the folder's ownership to the account that will run the service to ensure writing permission:

sudo chown -R tanssi_service /var/lib/tanssi-data

And finally, move the binary to the folder:

mv ./tanssi-node /var/lib/tanssi-data

Generate the Node Key

Starting from runtime 700 release, Tanssi block producer nodes don't generate the session keys automatically on start-up. To generate and store on disk the session keys that will be referenced on the start-up command, run the following command:

/var/lib/tanssi-data/tanssi-node key generate-node-key --file /var/lib/tanssi-data/node-key

Note

This step could be avoided using the --unsafe-force-node-key-generation parameter in the start-up command, although this is not the recommended practice.

Create the Systemd Service Configuration File

The next step is to create the Systemd configuration file.

You can create the file by running the following command:

sudo touch /etc/systemd/system/tanssi.service

Now you can open the file using your favorite text editor (vim, emacs, nano, etc) and add the configuration for the service, replacing the INSERT_YOUR_TANSSI_NODE_NAME and INSERT_YOUR_RELAY_NODE_NAME tags with a human-readable text in the --name flags. These names will come in handy for connecting the log entries and metrics with the node that generates them.

[Unit]
Description="Tanssi systemd service"
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=on-failure
RestartSec=10
User=tanssi_service
SyslogIdentifier=tanssi
SyslogFacility=local7
KillSignal=SIGHUP
ExecStart=/var/lib/tanssi-data/tanssi-node \
--chain=dancebox \
--name=INSERT_YOUR_TANSSI_NODE_NAME \
--sync=warp \
--base-path=/var/lib/tanssi-data/para \
--state-pruning=2000 \
--blocks-pruning=2000 \
--collator \
--database paritydb \
--telemetry-url='wss://telemetry.polkadot.io/submit/ 0' \
--node-key-file /var/lib/tanssi-data/node-key \
-- \
--name=INSERT_YOUR_BLOCK_PRODUCER_NODE_NAME \
--base-path=/var/lib/tanssi-data/container \
--telemetry-url='wss://telemetry.polkadot.io/submit/ 0' 
-- \
--chain=westend_moonbase_relay_testnet \
--name=INSERT_YOUR_RELAY_NODE_NAME \
--sync=fast \
--base-path=/var/lib/tanssi-data/relay \
--state-pruning=2000 \
--blocks-pruning=2000 \
--database paritydb \
--telemetry-url='wss://telemetry.polkadot.io/submit/ 0' 

[Install]
WantedBy=multi-user.target

Run Flags

The flags used in the ExecStart command can be adjusted according to your preferences and hardware configuration. The following ones are some of the most note-worthy:

  • --name INSERT_NAME - a human-readable name for this node
  • --rpc-port INSERT_PORT - specifies the JSON-RPC TCP port the node listens on
  • --unsafe-rpc-external - exposes the RPC service on all the interfaces
  • --state-pruning INSERT_STATE_PRUNING_TYPE - specifies when the Tanssi appchain state should be removed from the database. The pruning type can be either archive (which makes the node behave as a full node keeping all the state), archive-canonical (which keeps only the state of finalized blocks), or any number (representing the number of blocks whose states are kept)
  • --blocks-pruning INSERT_BLOCKS_PRUNING_TYPE - specifies how many blocks should be kept in the database. The pruning type can be either archive (which makes the node behave as a full node keeping all the blocks), archive-canonical (which keeps only finalized blocks), or any number (representing the amount of finalized blocks to keep)
  • --detailed-log-output - enables detailed log output

For a complete list of available flags, their description, and possible values, run the following command:

/var/lib/tanssi-data/tanssi-node  --help

Run the Service

Finally, enable the service and start it for the first time:

systemctl enable tanssi.service && \
systemctl start tanssi.service

You can verify that the service is up and running correctly running:

systemctl status tanssi.service
systemctl status appchain.service
● appchain.service - "Appchain systemd service"
   Loaded: loaded (/etc/systemd/system/appchain.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2024-02-18 18:16:40 EST; 14min ago
  Main PID: 4045278 (container-chain)
    Tasks: 44 (limit: 9462)
   Memory: 6.5G
   CGroup: /system.slice/appchain.service
           └─4045278 4045278 /var/lib/appchain-data/container-chain- ...

And check the logs, if needed, with the following command:

journalctl -f -u tanssi.service
Last update: August 12, 2024
| Created: February 10, 2024