Services

SNAPSHOTS

Snapshots enable a fresh node to enter the network by restoring application state from a backup file. Each snapshot comprises a compressed copy of the chain data directory. To maintain compact backup files, the snapshot server undergoes periodic state synchronization.

You need to have lz4 installed in order to extract the snapshot.

sudo apt update

sudo apt install snapd -y

sudo snap install lz4

Begin by stopping the Kava node so that we can replace the node data with the snapshot.

sudo service kava stop

Now we create a backup of the ‘priv_validator_state.json’ file, for a validator node this is critical as it indicates the last block you signed.

cp $HOME/.kava/data/priv_validator_state.json $HOME/.kava/priv_validator_state.json.backup

Make a backup of the data. We will restore this from our snapshot.

mv $HOME/.kava/data $HOME/.kava/data_bk

We can now download the snapshot and its contents

curl -L http://snapshots.staking4all.org/snapshots/kava/latest/kava.tar.lz4 | lz4 -dc - | tar -xf - -C $HOME/.kava

Now, it's crucial to reinsert the 'priv_validator_state.json' file to its original location to prevent the node from attempting to sign blocks that have already been signed.

cp $HOME/.kava/priv_validator_state.json.backup $HOME/.kava/data/priv_validator_state.json

You can now start your node.

sudo service kava start

sudo service kava status

Ensure that the node is syncing by reviewing the logs.

sudo journalctl -u kava -f

You can now remove the backup data, if for some reason it did not work you can revert to your original state by placing the content back.

rm -r $HOME/.kava/data_bk

rm $HOME/.kava/priv_validator_state.json.backup

STATESYNC

State Sync facilitates the integration of a new node into the network by downloading a recent snapshot of the application's state, rather than retrieving and processing all historical blocks. Given that the application state's size is typically much less than the cumulative size of the blocks, and restoring it is quicker than processing blocks, this method can significantly shorten the network synchronization time from days to mere minutes.

We begin by stopping the node.

sudo service kava stop

Backing up the content is advisable if you wish to revert changes.

cp $HOME/.kava/data/priv_validator_state.json $HOME/.kava/priv_validator_state.json.backup

mv $HOME/.kava/data $HOME/.kava/data_bk

Update the config.toml with the information it requires to state sync when starting.

SNAP_RPC="http://kava -rpc.staking4all.org"

LATEST_HEIGHT=$(curl -s $SNAP_RPC/block | jq -r .result.block.header.height); \

BLOCK_HEIGHT=$((LATEST_HEIGHT - 2000)); \

TRUST_HASH=$(curl -s "$SNAP_RPC/block?height=$BLOCK_HEIGHT" | jq -r .result.block_id.hash)

SNAP_RPC=$SNAP_RPC:13957

sed -i.bak -E "s|^(enable[[:space:]]+=[[:space:]]+).*$|\1true| ; \

s|^(rpc_servers[[:space:]]+=[[:space:]]+).*$|\1\"$SNAP_RPC,$SNAP_RPC\"| ; \

s|^(trust_height[[:space:]]+=[[:space:]]+).*$|\1$BLOCK_HEIGHT| ; \

s|^(trust_hash[[:space:]]+=[[:space:]]+).*$|\1\"$TRUST_HASH\"|" $HOME/.kava/config/config.toml

Place your ‘priv_validator_state.json’ back in the correct location.

mkdir $HOME/.kava/data

cp $HOME/.kava/priv_validator_state.json.backup $HOME/.kava/data/priv_validator_state.json

Start your node and make sure to monitor the logs. You should see it downloading from our state sync and then beginning to sync.

sudo service kava start

sudo journalctl -u kava -f

You can now remove the backup data, if for some reason it did not work you can revert to your original state by placing the content back.

rm -r $HOME/.kava/data_bk

rm $HOME/.kava/priv_validator_state.json.backup

SEED NODE

Utilizing 'persistent_peers' to synchronize your node is an option, but it may become unreliable over time as these peers may change or become outdated. It's advisable to restrict the use of 'persistent_peers' to those under your control to ensure reliability. For validator nodes, relying on outdated peers can result in decreased block signing efficiency and the potential for missed blocks.

A more efficient approach is to bootstrap your node using a seed node initially. By allowing the seed node to populate your 'addrbook.json', you can subsequently depend on this file for continued operations. This strategy not only alleviates the server's peer-to-peer workload but also mitigates the risk of missed blocks.

Here is Staking4All's seed node for Kava:

937d30cb67bb92479e648f904a91da9e6cfd0233@seeds.staking4all.org:13956

ADDRBOOK

Occasionally, node operators might encounter difficulties connecting with the broader network. These issues are frequently resolvable by using a reliable seed node or a roster of stable, persistent peers.

If these measures do not rectify the situation, you have the option to rely on our 'addrbook.json' file as a means to initiate your node's network connections.

To do this, halt your node, and follow the steps below to download and substitute your current 'addrbook.json', then reboot your node.

wget http://snapshots.staking4all.org/addrbook/kava/latest/addrbook.json

mv addrbook.json ~/.kava/config

Services

SNAPSHOTS

STATESYNC

RPC ENDPOINT

gRPC ENDPOINT

SEED NODE

ADDRBOOK