Skip to main content

Run a Validator

Learn how to run a validator node.

Prerequisite Readings

PickUp a chain id

You specify the network you want to join by setting the genesis file and seeds. If you need more information about past networks, check our glitter-chain-config.

Testnet Chain IDDescriptiondownload urlconfig urlStatus
glitter_12001-4glitter_12001-4 Testnetreleaseglitter_12000-4Stale
note

When executing commands in this document, ${chainID} represents the chain ID and needs to be replaced with the chain ID of the network you want to install.

Install glitter-chaind

wget https://storage.googleapis.com/glitter-web3/glitter_${chainID}.zip  && unzip glitter_${chainID}.zip
cd glitter_${chainID}
cp glitter-chaind /usr/bin/

Initialize Node

We need to initialize the node to create all the necessary validator and node configuration files:

By default, the init command creates your ~/.glitter-chain (i.e $HOME) directory with subfolders config/ and data/. In the config directory, the most important files for configuration are app.toml and config.toml.if you want run glitter-chaind in a specified directory you should run command with --home $YOUR_DIRECTORY and specify GLITTER_CHAIN_NODE_HOME like export GLITTER_CHAIN_NODE_HOME=$YOUR_DIRECTORY

The simpler way is make symbolic link mkdir -p $YOUR_DIRECTORY/.glitter-chain && ln -s $YOUR_DIRECTORY/.glitter-chain $HOME/.glitter-chain

mkdir -p  $YOUR_DIRECTORY/.glitter-chain
ln -s $YOUR_DIRECTORY/.glitter-chain $HOME/.glitter-chain
glitter-chaind init <your_custom_moniker> --chain-id ${chainID}
warning

Monikers can contain only ASCII characters. Using Unicode characters will render your node unreachable.

Modify config

Copy The Genesis File

Check the genesis.json file from the genesis.json and copy it over to the config directory: ~/.glitter-chain/config/genesis.json. This is a genesis file with the chain-id and genesis accounts balances.

git clone https://github.com/glitternetwork/glitter-chain-config.git
cd glitter-chain-config
cp glitter_${chainID}/genesis.json ~/.glitter-chain/config/

Then verify the correctness of the genesis configuration file:

glitter-chaind validate-genesis

Add Seed Nodes

Your node needs to know how to find peers. You'll need to add healthy seed nodes to $HOME/.glitter-chain/config/config.toml. The glitter-chain-config repo contains links to some seed nodes.

Edit the file located in ~/.glitter-chain/config/config.toml and the seeds to the following:

#######################################################
### P2P Configuration Options ###
#######################################################
[p2p]

# ...

# Comma separated list of seed nodes to connect to
seeds = "<node-id>@<ip>:<p2p port>"

You can use the following code to get seeds from the repo and add it to your config:

SEEDS=`cat glitter_${chainID}/seeds.txt | awk 'NR==1' | paste -s -d, -`
sed -i.bak -e "s/^seeds =.*/seeds = \"$SEEDS\"/" ~/.glitter-chain/config/config.toml
note

For more information on seeds and peers, you can the Tendermint P2P documentation.

Add Persistent Peers

We can set the persistent_peers field in ~/.glitter-chain/config/config.toml to specify peers that your node will maintain persistent connections with. You can retrieve them from the list of available peers on the glitter-chain config repo.

You can get a random 10 entries from the peers.txt file in the PEERS variable by running the following command:

PEERS=`cat glitter_${chainID}/peers.txt | sort -R | head -n 10 | awk 'NR==1' | paste -s -d, -`

Use sed to include them into the configuration. You can also add them manually:

sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PEERS\"/" ~/.glitter-chain/config/config.toml

Prometheus Metrics

You can set prometheus to true in the configuration file ~/.glitter-chain/config/config.toml

#######################################################
### Instrumentation Configuration Options ###
#######################################################
[instrumentation]

# When true, Prometheus metrics are served under /metrics on
# PrometheusListenAddr.
# Check out the documentation for the list of available metrics.
prometheus = true

# Address to listen for Prometheus collector(s) connections
prometheus_listen_addr = ":26660"

Start The chain

glitter-chaind start --pruning=nothing --trace  --log_level info --minimum-gas-prices=1agli --json-rpc.api eth,txpool,personal,net,debug,web3 --api.enable

we can also add a config file /etc/systemd/system/glitter-chaind.service and then use systemctl start glitter-chaind to start the testnet

[Unit]
Description=glitter-chaind
Requires=network-online.target
After=network-online.target

[Service]
Restart=on-failure
User=root
Group=root
PermissionsStartOnly=true
ExecStart=/usr/bin/glitter-chaind start --pruning=nothing --log_level info --minimum-gas-prices=1agli --json-rpc.api eth,txpool,personal,net,debug,web3 --api.enable
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGTERM
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=glitter-chaind.log
LimitNOFILE=4096
[Install]
WantedBy=multi-user.target

Node Check

We can determine if the node is functioning properly by checking the height of the latest block.

curl http://localhost:1317/cosmos/base/tendermint/v1beta1/blocks/latest

Create Your Validator

Your node consensus public key can be used to create a new validator by staking AGLI tokens. You can find your validator pubkey by running:

glitter-chaind tendermint show-validator

[!WARNING] Never create your mainnet validator keys using a test keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the eth_sendTransaction JSON-RPC endpoint.

Ref: Security Advisory: Insecurely configured geth can make funds remotely accessible

To create your validator on testnet, just use the following command:

glitter-chaind tx staking create-validator \
--amount=100000000agli \
--pubkey=$(glitter-chaind tendermint show-validator) \
--moniker="choose a moniker" \
--chain-id=<chain_id> \
--commission-rate="0.05" \
--commission-max-rate="0.10" \
--commission-max-change-rate="0.01" \
--min-self-delegation="1000000" \
--gas="1000000" \
--gas-prices="1agli" \
--from=<key_name>
note

When specifying commission parameters, the commission-max-change-rate is used to measure % point change over the commission-rate. E.g. 1% to 2% is a 100% rate increase, but only 1 percentage point.

note

Min-self-delegation is a strictly positive integer that represents the minimum amount of self-delegated voting power your validator must always have. A min-self-delegation of 1000000 means your validator will never have a self-delegation lower than 1000000agli

You can confirm that you are in the validator set by using a third party explorer.

Edit Validator Description

You can edit your validator's public description. This info is to identify your validator, and will be relied on by delegators to decide which validators to stake to. Make sure to provide input for every flag below. If a flag is not included in the command the field will default to empty (--moniker defaults to the machine name) if the field has never been set or remain the same if it has been set in the past.

The <key_name> specifies which validator you are editing. If you choose to not include certain flags, remember that the --from flag must be included to identify the validator to update.

The --identity can be used as to verify identity with systems like keybase or UPort. When using with keybase --identity should be populated with a 16-digit string that is generated with a keybase.io account. It's a cryptographically secure method of verifying your identity across multiple online networks. The keybase API allows us to retrieve your keybase avatar. This is how you can add a logo to your validator profile.

glitter-chaind tx staking edit-validator
--moniker="choose a moniker" \
--website="https://glitter-chain.org" \
--identity=6A0D65E29A4CBC8E \
--details="To infinity and beyond!" \
--chain-id=<chain_id> \
--gas="auto" \
--gas-prices="1agli" \
--from=<key_name> \
--commission-rate="0.10"

Note: The commission-rate value must adhere to the following invariants:

  • Must be between 0 and the validator's commission-max-rate
  • Must not exceed the validator's commission-max-change-rate which is maximum % point change rate per day. In other words, a validator can only change its commission once per day and within commission-max-change-rate bounds.

View Validator Description

View the validator's information with this command:

glitter-chaind query staking validator <account_name>

Track Validator Signing Information

In order to keep track of a validator's signatures in the past you can do so by using the signing-info command:

glitter-chaind query slashing signing-info <validator-pubkey>\
--chain-id=<chain_id>

Unjail Validator

When a validator is "jailed" for downtime, you must submit an Unjail transaction from the operator account in order to be able to get block proposer rewards again (depends on the zone fee distribution).

glitter-chaind tx slashing unjail \
--from=<key_name> \
--chain-id=<chain_id>

Confirm Your Validator is Running

Your validator is active if the following command returns anything:

glitter-chaind query tendermint-validator-set | grep "$(glitter-chaind tendermint show-address)"

You should now see your validator in one of Glitter-chain explorers. You are looking for the bech32 encoded address in the ~/.glitter-chaind/config/priv_validator.json file.

Upgrading Your Node

note

These instructions are for full nodes that have ran on previous versions of and would like to upgrade to the latest testnet version.

Reset Data

note

If the version <new_version> you are upgrading to is not breaking from the previous one, you should not reset the data. If this is the case you can skip to Restart

First, remove the outdated files and reset the data.

rm $HOME/.glitter-chaind/config/addrbook.json
rm $HOME/.glitter-chaind/config/genesis.json
glitter-chaind tendermint unsafe-reset-all

Your node is now in a pristine state while keeping the original priv_validator.json and config.toml. If you had any sentry nodes or full nodes setup before, your node will still try to connect to them, but may fail if they haven't also been upgraded.

warning

Make sure that every node has a unique priv_validator.json. Do not copy the priv_validator.json from an old node to multiple new nodes. Running two nodes with the same priv_validator.json will cause you to double sign.

Restart

To restart your node, just type:

glitter-chaind start --pruning=nothing --trace  --log_level info --minimum-gas-prices=0agli --json-rpc.api eth,txpool,personal,net,debug,web3 --api.enable

Save Chain ID

After start glitter-chaind node,we can do some query,we recommend saving the testnet chain-id into your 's client.toml. This will make it so you do not have to manually pass in the chain-id flag for every CLI command.

note

See the official chain IDs from above.

glitter-chaind config chain-id glitter_${chainID}

Get Node ID

glitter-chaind tendermint show-node-id

Halting Your Validator

When attempting to perform routine maintenance or planning for an upcoming coordinated upgrade, it can be useful to have your validator systematically and gracefully halt. You can achieve this by either setting the halt-height to the height at which you want your node to shutdown or by passing the --halt-height flag to glitter-chaind. The node will shutdown with a zero exit code at that given height after committing the block.

Common Problems

Problem 1: My validator has voting_power: 0

Your validator has become jailed. Validators get jailed, i.e. get removed from the active validator set, if they do not vote on 500 of the last 10000 blocks, or if they double sign.

If you got jailed for downtime, you can get your voting power back to your validator. First, if glitter-chaind is not running, start it up again:

glitter-chaind start

Wait for your full node to catch up to the latest block. Then, you can unjail your validator

Lastly, check your validator again to see if your voting power is back.

glitter-chaind status

You may notice that your voting power is less than it used to be. That's because you got slashed for downtime!

Problem 2: My node crashes because of too many open files

The default number of files Linux can open (per-process) is 1024. glitter-chaind is known to open more than 1024 files. This causes the process to crash. A quick fix is to run ulimit -n 4096 (increase the number of open files allowed) and then restart the process with glitter-chaind start. If you are using systemd or another process manager to launch glitter-chaind this may require some configuration at that level. A sample systemd file to fix this issue is below:

[Unit]
Description=glitter-chaind
Requires=network-online.target
After=network-online.target

[Service]
Restart=on-failure
User=root
Group=root
PermissionsStartOnly=true
ExecStart=/usr/bin/glitter-chaind start --pruning=nothing --trace --log_level info --minimum-gas-prices=1agli --json-rpc.api eth,txpool,personal,net,debug,web3 --api.enable
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGTERM
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=glitter-chaind.log
LimitNOFILE=4096
[Install]
WantedBy=multi-user.target