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 eitherarchive
(which makes the node behave as a full node keeping all the state),archive-canonical
(which keeps only the state of finalized blocks), or anynumber
(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 eitherarchive
(which makes the node behave as a full node keeping all the blocks),archive-canonical
(which keeps only finalized blocks), or anynumber
(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
● 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
| Created: February 10, 2024