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

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:

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

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

wget https://github.com/moondance-labs/tanssi/releases/download/v0.6.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

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' 
-- \
--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

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

journalctl -f -u tanssi.service