WebsiteTwitter

Node Setup Guide

Set up a Self Chain node

Hardware requirements

For running a node and full node we recommend the following hardware resources:

  • 4 or 8 cores CPU

  • 16GB RAM

  • 100GB Disk Storage

The current hardware requirements are set considering the estimated growth over the period ending in Q4-2024.

100 GB of storage will last for approximately three months. You’ll need a dynamic strategy to manage your storage capacity effectively.

Installation

Download the latest binary file from the release page.

Add the binary to the system path and open a new terminal to verify that you can run the CLI commands.

selfchaind --help

General Configuration

Make sure to walk through the basic setup and configuration. Operators will need to initialize selfchaind, download the Genesis file for self-1 (mainnet) or self-test-1 (testnet), and set persistent peers and/or seeds for the startup.

Chain Initialization

By default selfchaind init command creates the ~/.selfchain directory with subfolders config and data. In the /config directory, the most important files for configuration are app.toml and config.toml. You can override the location via the —home param.

# Create an env variable that points to the HOME location
export $SELF_CHAIN_HOME=~/.selfchain

# Moniker will be the name of the validator and it will be displayed on the blockchain explorer
selfchaind init <moniker>

# Or if you want a custom location
selfchaind init <moniker> --home $SELF_CHAIN_HOME

Genesis

Now you can download the genesis file for the network of your choice and replace the one that was created during the chain initialization.

# Download the mainnet genesis 
wget -O $SELF_CHAIN_HOME/config/genesis.json https://gist.githubusercontent.com/pratikbin/656a18f371e7a970afd63e2da2890c81/raw/3876268b2d07ce65aece8455c67f98cf557c6e40/selfchain-mainnet-self-1.json
# Download the testnet genesis 
wget -O $SELF_CHAIN_HOME/config/genesis.json  https://raw.githubusercontent.com/selfchainxyz/selfchain-genesis/refs/heads/main/networks/testnet/genesis.json

Seeds & Peers

Mainnet

# Comma separated list of seed nodes to connect to
seeds="b307b56b94bd3a02fcad5b6904464a391e13cf48@128.199.33.181:26656,71b8d630e7c3e31f2743fda68e6d3ac64f41cece@209.97.174.97:26656,6ae10267d8581414b37553655be22297b2f92087@174.138.25.159:26656,9512a59cf93b987aff830148421a514cacb8a1b8@170.64.141.15:26656"

# Comma separated list of nodes to keep persistent connections to
persistent_peers="b307b56b94bd3a02fcad5b6904464a391e13cf48@128.199.33.181:26656,71b8d630e7c3e31f2743fda68e6d3ac64f41cece@209.97.174.97:26656,6ae10267d8581414b37553655be22297b2f92087@174.138.25.159:26656,9512a59cf93b987aff830148421a514cacb8a1b8@170.64.141.15:26656"

Testnet

# Comma separated list of seed nodes to connect to
seeds = "190873258f75876f635e362565f481e06abe1cc0@165.232.125.66:26656,0fc2f5ac7289ebde2d4ef83c77bf6eb6eed11d99@165.22.24.236:26656,df3d2bf1b93c000eb1a3340cb1157da18b9fbc37@165.232.125.66:26656"

# Comma separated list of nodes to keep persistent connections to
persistent_peers = "190873258f75876f635e362565f481e06abe1cc0@165.232.125.66:26656,0fc2f5ac7289ebde2d4ef83c77bf6eb6eed11d99@165.22.24.236:26656,df3d2bf1b93c000eb1a3340cb1157da18b9fbc37@165.232.125.66:26656"

Open the $SELF_CHAIN_HOME/config/config.toml update seeds and persistent_peers values.

Keys

The priv_validator_key.json is the consensus key i.e. the key that the validator will be using to sign blocks. Note, this is not the validator operation key i.e. the key which we will use to sign the gentx transaction or any other transaction related to validator management.

This key must not be stored on the local disk. When we want to use it to, for example, sign the gentx (see below) transaction or later to update some of the validator params, we would recover it from the mnemonic key, use the CLI to send the transaction and then delete it from the disk. Alternatively, we can import the wallet into the browser extension (Keplr) or even Ledger Nano and use some other dApp that will abstract away the creation and signing of the aforementioned transactions.

First, you need to create the operation keys. Such a key is not meant to stay on the node when it runs, it is meant to be used at certain junctures only. Nonetheless, you are going to create them by running the containers

To create the operation key you should run the following command:

# Enter a strong password when prompted
selfchaind keys --home $SELF_CHAIN_HOME --keyring-backend file --keyring-dir keys add <key_name>

# The result will look similar to the below
Enter keyring passphrase:
Re-enter keyring passphrase:

- address: self17kyky3r4vs5q3nvqsg9fpnsxuzfh48vr2kq2j3
  name: finney
  pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Awee/jSrnBmL9csEVaFUfO/bgS60YkBi/fQrP1jxddcp"}'
  type: local


**Important** write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.

goat random fever cart struggle bitter frown three files also tennis invest frozen tribe post mirror slot ill tenant arctic alcohol render bag blade

The above will create the operation key and will store it in keys/keyring a folder. You should not keep this key on the disk. Delete the keyring folder when you have finished all the operations needed. You can always restore the key using the mnemonic.

selfchaind keys add <key_name> \
--recover \
--keyring-backend file --keyring-dir $SELF_CHAIN_HOME/keys

Important to write this mnemonic phrase in a safe place. It is the only way to recover your account if you ever forget your password.

Add Keys with Ledger (only for Ledger users)

For those who want to run the node on a personal computer and a Ledger, follow the steps to create the operation keys:

  1. Connect your Ledger to your Laptop / Desktop and open the Ledger Live.

  2. Ensure you install the latest Ledger Live version and the latest Ledger Nano firmware. Ledger Live will have a notification on the header telling you if your version is outdated.

  3. Install the Cosmos app on your Ledger through Ledger Live and then open it on your Ledger device.

  4. To create a new wallet you run ./selfchaind keys add <key-name> --ledger

  5. To check the address of the newly created wallet ./selfchaind keys show <key-name> -d

  6. Fund this account with some SLF so it can pay for transaction fees.

  7. Now you can send any transaction you want. Here I will show an example of sending some coins from one account to another.

selfchaind tx bank send  <ledger_wallet_address_from_above> <destination address> 1000uslf \
--node https://rpc.selfchain.io:26657  \
--gas="auto" \
--gas-prices="0.5uslf" \
--gas-adjustment="1.5" \
--chain-id self-1 \
--broadcast-mode sync \
--ledger

If you want to add additional wallets then you can use the --index flag ./selfchaind keys add <key-name> --ledger --index 1

Denomination and Minimum Gas

A full node keeps unconfirmed transactions in its mempool. In order to protect it from spam, it is better to set a minimum-gas-prices that the transaction must meet in order to be accepted in the node's mempool. This parameter can be set in $SELF_CHAIN_HOME/config/app.toml.

# The minimum gas prices a validator is willing to accept for processing a
# transaction. A transaction's fees must meet the minimum of any denomination
# specified in this config (e.g. 0.25token1;0.0001token2).
minimum-gas-prices = "0.005uslf"

We also need to update the denomination. On Selfchain, the accepted denom-to-suggest is uslf, where 1slf = 1.000.000uslf.

In addition to that we need to update the network id client.toml file.

The network ids for each network are as follows:

  • testnet: self-test-1

  • mainnet: self-1

# Note you can also manually open these files and update the corresponding values
sed -Ei '' 's/([0-9]+)stake/\1uslf/g' $SELF_CHAIN_HOME/config/app.toml
sed -i  '' 's/"uatom"/"uslf"/g' $SELF_CHAIN_HOME/config/app.toml
sed -Ei '' 's/^chain-id = .*$/chain-id = "self-1"/g' $SELF_CHAIN_HOME/config/client.toml

Ledger Pruning

There are four strategies for pruning the state. These strategies apply only to the state and do not apply to block storage. A node operator may want to consider custom pruning if node storage is a concern or if there is an interest in running an archive node.

To set pruning, adjust the pruning parameter in the $SELF_CHAIN_HOME/config/app.toml file. The following pruning state settings are available:

  • default: the last 100 states are kept in addition to every 500th state; pruning at 10 block intervals

  • nothing: All historic states will be saved, and nothing will be deleted (i.e. archiving node)

  • everything: all saved states will be deleted, storing only the current state; pruning at 10 block intervals

  • custom: allow pruning options to be manually specified through 'pruning-keep-recent', 'pruning-keep-every', and 'pruning-interval'

By default, every node is in default mode which is the recommended setting for most environments. If a node operator wants to change their node's pruning strategy then this must be done before the node is initialized.

In $SELF_CHAIN_HOME/config/app.toml

# default: The last 100 states are kept in addition to every 500th state; pruning at 10-block intervals
# nothing: All historic states will be saved, and nothing will be deleted (i.e. archiving node)
# everything: all saved states will be deleted, storing only the current state; pruning at 10 block intervals
# custom: allow pruning options to be manually specified through 'pruning-keep-recent', 'pruning-keep-every', and 'pruning-interval'
pruning = "custom"

# These are applied if and only if the pruning strategy is custom.
pruning-keep-recent = "10"
pruning-keep-every = "1000"
pruning-interval = "10"

API and gRPC

By default, the REST API is disabled. To enable the REST API, edit the $SELF_CHAIN_HOME/config/app.toml file, and set enable to true in the [api] section.

###############################################################################
###                           API Configuration                             ###
###############################################################################
[api]
# Enable defines if the API server should be enabled.
enable = true
# Swagger defines if swagger documentation should automatically be registered.
swagger = true
# Address defines the API server to listen on.
address = "tcp://0.0.0.0:1317"

By default, gRPC is enabled on port 9090. The $SELF_CHAIN_HOME/config/app.toml file is where changes can be made in the gRPC section. To disable the gRPC endpoint, set enable it to false. To change the port, use the address parameter.

###############################################################################
###                           gRPC Configuration                            ###
###############################################################################
[grpc]
# Enable defines if the gRPC server should be enabled.
enable = true
# Address defines the gRPC server address to bind to.
address = "0.0.0.0:9090"

Sync Options

There are two ways to sync a Testnet node, Fastsync, and State Sync.

  • Fast Sync syncs the chain from Genesis by downloading blocks in parallel and then verifying them.

  • State Sync will look for snapshots from peers at a trusted height and then verify a minimal set of snapshot chunks against the network.

Cosmovisor Setup (Optional)

Cosmovisor is a process manager that monitors the governance module for incoming chain upgrade proposals. When a proposal is approved, Cosmovisor can automatically download the new binary, stop the chain binary when it hits the upgrade height, switch to the new binary, and restart the daemon. Cosmovisor can be used with either Fast Sync or State Sync.

For more details check the instructions here.

Running the Node

To start the validator you should run the start command.

# nohup will run the command in the background and will emit the logs to the local selfchain.out file
nohup selfchaind start --x-crisis-skip-assert-invariants --home $SELF_CHAIN_HOME >> selfchain.out 2>&1 &

# To view the logs
tail -f selfchain.out

To check on the status of syncing:​

selfchaind status

This will give output like this:

{
 "latest_block_hash": "920E4D32F02CFF8064D26DD7D34C65DC623F4026C65C192BBCD7DBF19AFB5630",
 "latest_app_hash": "442E7E55982109D9F73467EA0E374312B402AE620DEC81CB3441E949ED0D0A29",
 "latest_block_height": "2437",
 "latest_block_time": "2022-05-25T23:07:36.752766828Z",
 "earliest_block_hash": "9D2AF876309BB9174604004A813DCFEE94F4947B08C5BB4C1A042F318488851E",
 "earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
 "earliest_block_height": "1",
 "earliest_block_time": "2022-05-25T17:00:00Z",
 "catching_up": true
}

The main thing to watch is that the block height is increasing. Once you are caught up with the chain, catching_up will become false. At that point, you can start using your node to create a validator.

Stopping the Node

# To stop the validator you can simply kill the process
pkill -f -e -c selfchaind
PreviousNodes & ValidatorsNextNode Configuration FAQs

Last updated