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.
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.
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-dev-1
(devnet), 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.
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.
Seeds & Peers
Mainnet
Devnet
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:
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.
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:
Connect your Ledger to your Laptop / Desktop and open the Ledger Live.
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.
Install the Cosmos app on your Ledger through Ledger Live and then open it on your Ledger device.
To create a new wallet you run
./selfchaind keys add <key-name> --ledger
To check the address of the newly created wallet
./selfchaind keys show <key-name> -d
Fund this account with some SLF so it can pay for transaction fees.
Now you can send any transaction you want. Here I will show an example of sending some coins from one account to another.
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
.
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:
devnet:
self-dev-1
tesent:
self-test-1
mainnet:
self-1
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 intervalsnothing
: 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 intervalscustom
: 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
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.
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.
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.
To check on the status of syncing:
This will give output like this:
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
Last updated