Run Sonic Validator Node

Last updated 11 June 2024

Validator parameters

Minimum stake: 50,000 FTM
Maximum validator size: 15x the self-stake amount
Rewards: currently ~6% APR (Normal APR on self-stake + 15% of delegators' rewards). APR varies based on staked %. For up-to-date APR, check https://fantom.foundation/ftm-staking/

What you need to do?

Launch a server instance

You can run your validator node on a dedicated hardware (also called bare metal) or use a cloud provider. We recommend choosing one of the big cloud providers, e.g. Google GCP, or Amazon AWS.

Node hardware specifications

You need at least 4 vCPU and 32 GB of RAM to run the node software. We recommend to get ta least 1Gbps of redundant backbone connectivity to allow a stabe and uninterrupted network traffic flow. You will also need at least 1TB of local SSD/NVMe storage. Remotely connected storage systems, e.g. Amazon EBS, usually don't provide required latency and random access performance required by the node.

The Google GCP N2D instances with local SSD drives, or Amazon AWS i3en.xlarge with the instance storage match the minimal requirements.

We recommend going with Ubuntu LTS Server (64-bit) or a similar linux distribution.

Required storage capacity

1 TB of local SSD/NVMe storage is sufficient for a pruned DB either on validator or on no-history pruned dataset. 6 TB of local SSD/NVMe are needed if you'd like to run with a full size (non-pruned) datadir.

Here you can obtain the latest genesis file: https://download.fantom.network.

Network settings

The Sonic node requires both TCP and UDP network traffic to be allowed on port 5050 by default. A custom port can be used with --port <port> flag when run your node.

Install required development tools

You need the esential building tools and Go compiler version 1.21 or newer to build the Sonic client and bundled tools.

First, install the required build tools:

sudo apt-get install -y build-essential git

Install latest Go compiler from binary distribution:

sudo rm -rf /usr/local/go
wget https://go.dev/dl/go1.22.4.linux-amd64.tar.gz
sudo tar -xzf go1.22.4.linux-amd64.tar.gz -C /usr/local/
rm -f go1.22.4.linux-amd64.tar.gz

Setup Go language export paths:

sudo tee /etc/profile.d/golang.sh > /dev/null <<EOT
export GOROOT=/usr/local/go
export GOPATH=\$HOME/go
export PATH=\$PATH:\$GOROOT/bin:\$GOPATH/bin

EOT

source /etc/profile.d/golang.sh

Build the Sonic node software

Building the Sonic binary requires the essential software development tools and the Go language version 1.21 or newer to be available. Previous section contains basic steps to deploy the required applications on the recommended linux distribution. Please refer to your operating system manuals to install the development tools needed for this step.

Please check the latest release of the Sonic node and adjust your commands accordingly.

git clone https://github.com/Fantom-foundation/Sonic.git
cd Sonic
git fetch --tags && git checkout -b v1.2.1-c tags/v1.2.1-c
make all

You can confirm the Sonic release by executing the version subcommand on the created binary.

build/sonicd version

Optionaly, you may want to copy the Sonic node app and the tooling into the system wide bin folder to make it available without explicitely specifying the binary path.

sudo mv build/sonic* /usr/local/bin/

Prime the Sonic database

You need a valid state database to be able to participate in the network. The fastest ands easiest way is to use a genesis file. Please check the official repository, where new signed genesis files are published, and pick the latest one suitable for a validator node. You will need aproximately 50GB of storage space for the genesis file download.

Download the latest genesis file and the corresponding checksum:

wget https://files.fantom.network/mainnet-286540-validator.g
wget https://files.fantom.network/mainnet-286540-validator.g.md5

Check your download using the MD5 checksum file:

$ md5sum --check mainnet-286540-validator.g.md5
mainnet-286540-validator.g: OK

Use the Sonic tooling to prime state database using the downloaded genesis file. Refer to these steps to determine the amount of cache and memory consumption soft limit for your node. The --datadir flag should point to your local NVMe storage mount path. The --mode validator flag tells the tool to create a minimal required state database for your node.

GOMEMLIMIT=58GiB sonictool --datadir ~/.sonic --cache 25600 \
    genesis --mode validator mainnet-286540-validator.g

The Sonic tool creates a primed state database from the genesis file. The last step is a validation procedure. It confirms that the expected state was built successfully reaching the expected root hash. You can refer to the official repository to verify that the state hash is indeed correct.

StateDB imported successfully, stateRoot matches module=gossip-store
  index=82423909 root="d20a48…4849a1"

How to calculate cache size and memory consumption soft limit values?

The Sonic node utilises large amount of RAM to achieve great speed and responsivness. It should be the only user space application consuming your system resources.

$ grep MemTotal /proc/meminfo
MemTotal:       65641928 kB

Approximately 40% of the available RAM should be used as the --cache for both the sonictool and sonicd applications. The final value denominated in MiB. For example: 64000 MiB RAM * 40% = 25600 MiB
Approximately 90% of the available RAM should be used as the application memory consumption limit. This limit is controled by GOMEMLIMIT environment variable. The final value includes an abbreviated units. We recommend using GiB for simplicity. For example: 64 GiB RAM * 90% ≈ 58 GiB

Synchronise with the network

Your node database has been primed to a certain epoch in the past using a genesis file and the Sonic tool. Now you need to get the node up to the current state. To do it, your node needs to be started in the read-only mode and establish a connection with the network. Please make sure your firewall is configured correctly to allow such communication. The mount of memory dedicated to node cache and the memory consumption limit is discussed above.

GOMEMLIMIT=58GiB sonicd --datadir ~/.sonic --cache 25600 --mode validator

The Sonic node should start and connect with the network advancing the state by creating and processing new blocks. Please notice the age part of the log message, which tells you how far in the past these block are. The age should not exceed a couple of seconds once the node is fully synchronised.

Create a validator wallet

Your Fantom Sonic node is up and running in the read-only mode synchronising with the network. Now you need to create a wallet which will identify and control your validator account.

The Sonic tool does contain a utility function to create such wallet, but we strongly recommend to do it off the server and in a secure way. The best approach is to use one of the hardware wallets available on the market, or a trustworthy software wallet capable of sending transactions to the Fantom network.

Make sure to keep the validator wallet private and secure. Never share this wallet or the corresponding key with anyone. Safety of your validator funds depend on it.

sonictool --datadir ~/.sonic account new

Once your validator wallet is created, you need to put the initial amount of funds on it. The registration process involves placing these funds as a stake on your account. If you don't have the native FTM tokens available on the Fantom network account already, you may need to purchase them using one of the trading platforms.

Create a validator signing key

A Sonic validator node signs special type of messages broadcasted though the Fantom network. A sequence of these messages from the confirmed active validators is what allows the network to process transactions safely and securely. Your node needs a signing key to be able to participate. Use the Sonic tool to create this key on the server.

Please backup your consensus signing key safely. You may need to deploy it on a new server in case of a hardware or software failure.

The key cannot be used to access your funds, but it can be utilised to invoke a double-sign error, which is penalised. Please handle your validator key with a propper care.

Create the validator signing key on the node server:

sonictool --datadir ~/.sonic validator new

Follow the prompts and supply a secure password:

Notice the Public key part of the application output message starting with 0xc00472c4966b0213…. This is the public key used in the registration process in the next step to let the network know what key is going to be used by your node as its distinct signature.

By the way: The picture above demonstrates an output of the validator key creation. Your real public key and the path to the key file will be different.

Register your validator

The network needs be aware of your validator key to accept it. The registration process is done by invoking a smart contract called SFC. This contract is responsible for the management of stakes and related rewards.

You can find the SFC contract here: 0xFC00FACE00000000000000000000000000000000

You can use the Explorer to invoke the appropriate registration function called createValidator. You will need to include at least the minimal stake to be able to finish the registration. The "pubkey" field is going to contain the public key created in the previous step. Use the validator wallet key to sign the registration transaction.

If you want to interact with the SFC contract directly, please use the latest available ABI for the interface definition.

Once you registration is confirmed, you can use the Explorer to get the ID assigned to your validator. The SFC allows you to query this ID for your specific validator wallet using getValidatorID function.

Run your validator node

You are almost done. Now you need to restart your running node with the validator signing key unlocked. Please make sure your node is already synchronised with the network before proceeding.

Stop the Sonic application ad wait until the node to gracefully terminate:

pkill sonicd

The Sonic node may run for several minutes until it stops. Please make sure to never terminate it forcefully. If the Sonic node cannot properly close its persistent database, you will have to restore the database from a backup or a genesis file again.

Start the Sonic node again adding your validator public key and the validator ID. If you start your node in a non-interactive environment, for example as a Systemd service, you may need to add a path to the password file so the validator key can be unlocked. Alternatively, you can use a detached terminal (i.e. tmux) to run the node. In that case the node will ask for the password when started.

GOMEMLIMIT=58GiB sonicd \
    --datadir ~/.sonic \
    --cache 25600 \
    --mode validator \
    --validator.id <your validator ID> \
    --validator.pubkey <your public key, i.e. 0xc00472c4966b0213…> \
    --validator.password <path to a file with the public key password>

What to do next?

Congratulations! Your validator node is up and running. Now you may be wondering what to do next? You can find some useful hints below.

Validator name and logo on the Explorer

If you'd like to set up a name and logo for your node, please check following repository for additional information and guide.

https://github.com/block42-blockchain-company/fantom-staker-info.

Community and help

The important part of running a validator on Fantom network is the community.

We would really like our validators to get involved in the network future. Our wallets allow you to use your stake to vote for important changes in the network configuration and development. You can also check our Telegram channels for additional information about upcomming events, upgrades, and planed governance votes. And if you have any problems with the node, our awesome participants are ready to provide additional information and help.

Monitoring and health

Each validator is expected to actively maintain their node and participate on securing the network traffic, but accidents happen. If your node drops offline, the network Explorer will show its address as being in the maintenance mode. You can also check a simplified HTTP interface with a list of nodes which did not emit new consensus events recently.

https://explorer.fantom.network/staking

https://xapi.fantom.network/html/validators/down

No worries. If your node is not running properly for a short time period, nothing happens. You will not receive any rewards for the down time, but this is the only consequence. If your node is offline for more than 5 days, or if it's constantly dropping off the network, the guarding algorithm will suspend your validator wallet and the signing key in the SFC contract. In that case your will not be able to join again and the only option would be to withdraw your stake and start over.

PreviousSonic client NextRun Sonic API Node

Last updated 19 days ago