Setting up a Celestia validator node
Validator nodes allow you to participate in consensus in the Celestia network.
Hardware requirements
The following hardware minimum requirements are recommended for running the validator node:
- Memory: 8 GB RAM
- CPU: 6 cores
- Disk: 500 GB SSD Storage
- Bandwidth: 1 Gbps for Download/100 Mbps for Upload
Setting up your validator node
The following tutorial is done on an Ubuntu Linux 20.04 (LTS) x64 instance machine.
Setup the dependencies
Follow the instructions on installing the dependencies here.
Install celestia-app
Follow the tutorial on installing celestia-app here.
Setup the P2P networks
Now we will setup the P2P Networks by cloning the networks repository:
cd $HOME
rm -rf networks
git clone https://github.com/celestiaorg/networks.git
To initialize the network pick a "node-name" that describes your
node. The --chain-id parameter we are using here is mocha
. Keep in
mind that this might change if a new testnet is deployed.
celestia-appd init "node-name" --chain-id mocha
Copy the genesis.json
file. For mocha we are using:
cp $HOME/networks/mocha/genesis.json $HOME/.celestia-app/config
Set seeds and peers:
SEEDS="some seeds"
PEERS="some peers"
sed -i -e 's|^seeds *=.*|seeds = "'$SEEDS'"|; s|^persistent_peers *=.*|persistent_peers = "'$PEERS'"|' $HOME/.celestia-app/config/config.toml
sed -i -e "s/^seed_mode *=.*/seed_mode = \"$SEED_MODE\"/" $HOME/.celestia-app/config/config.toml
Note: You can find more peers here.
Configure pruning
For lower disk space usage we recommend setting up pruning using the configurations below. You can change this to your own pruning configurations if you want:
PRUNING="custom"
PRUNING_KEEP_RECENT="100"
PRUNING_INTERVAL="10"
sed -i -e "s/^pruning *=.*/pruning = \"$PRUNING\"/" $HOME/.celestia-app/config/app.toml
sed -i -e "s/^pruning-keep-recent *=.*/pruning-keep-recent = \
\"$PRUNING_KEEP_RECENT\"/" $HOME/.celestia-app/config/app.toml
sed -i -e "s/^pruning-interval *=.*/pruning-interval = \
\"$PRUNING_INTERVAL\"/" $HOME/.celestia-app/config/app.toml
Syncing
By default, a consensus node will sync using block sync; that is request, validate and execute every block up to the head of the blockchain. This is the most secure mechanism yet the slowest (taking up to days depending on the height of the blockchain).
There are two alternatives for quicker syncing.
State sync
State sync uses light client verification to verify state snapshots from peers and then apply them. State sync relies on weak subjectivity; a trusted header (specifically the hash and height) must be provided. This can be found by querying a trusted RPC endpoint (/block). RPC endpoints are also required for retrieving light blocks. These can be found in the docs here under the respective networks or from the chain-registry.
In $HOME/.celestia-app/config/config.toml
, set
rpc_servers = ""
trust_height = 0
trust_hash = ""
to their respective fields. At least two different rpc endpoints should be provided. The more, the greater the chance of detecting any fraudulent behavior.
Once setup, you should be ready to start the node as normal. In the logs, you should
see: Discovering snapshots
. This may take a few minutes before snapshots are found
depending on the network topology.
Quick sync
Quick sync effectively downloads the entire data
directory from a third-party provider
meaning the node has all the application and blockchain state as the node it was
copied from.
Run the following command to quick-sync from a snapshot for mocha
:
cd $HOME
rm -rf ~/.celestia-app/data
mkdir -p ~/.celestia-app/data
SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \
egrep -o ">mocha.*tar" | tr -d ">")
wget -O - https://snaps.qubelabs.io/celestia/${SNAP_NAME} | tar xf - \
-C ~/.celestia-app/data/
Start the celestia-app
In order to start your validator node, run the following:
celestia-appd start
Follow the tutorial on setting up Celestia-App as a background process with SystemD here.
Wallet
Follow the tutorial on creating a wallet here.
Delegate stake to a validator
Create an environment variable for the address:
VALIDATOR_WALLET=<validator-wallet-name>
If you want to delegate more stake to any validator, including your own you
will need the celesvaloper
address of the validator in question. You can
either check it using the block explorer mentioned above or you can run the
command below to get the celesvaloper
of your local validator wallet in
case you want to delegate more to it:
celestia-appd keys show $VALIDATOR_WALLET --bech val -a
After entering the wallet passphrase you should see a similar output:
Enter keyring passphrase:
celesvaloper1q3v5cugc8cdpud87u4zwy0a74uxkk6u43cv6hd
To delegate tokens to the celestiavaloper
validator, as an
example you can run:
celestia-appd tx staking delegate \
celestiavaloper1q3v5cugc8cdpud87u4zwy0a74uxkk6u4q4gx4p 1000000utia \
--from=$VALIDATOR_WALLET --chain-id=mocha
If successful, you should see a similar output as:
code: 0
codespace: ""
data: ""
gas_used: "0"
gas_wanted: "0"
height: "0"
info: ""
logs: []
raw_log: '[]'
timestamp: ""
tx: null
txhash: <tx-hash>
You can check if the TX hash went through using the block explorer by
inputting the txhash
ID that was returned.
Deploy the celestia-node
This section describes part 2 of Celestia Validator Node setup: running a Celestia Bridge Node daemon.
Install celestia-node
You can follow the tutorial for installing celestia-node here
Initialize the bridge node
Run the following:
celestia bridge init --core.ip <ip-address>
NOTE: The
--core.ip
gRPC port defaults to 9090, so if you do not specify it in the command line, it will default to that port. You can add the port after the IP address or use the--core.grpc.port
flag to specify another port if you prefer.
If you need a list of RPC endpoints to connect to, you can check from the list here
Run the bridge node
Run the following:
celestia bridge start
Optional: start the bridge node with SystemD
Follow the tutorial on setting up the bridge node as a background process with SystemD here.
You have successfully set up a bridge node that is syncing with the network.
Setup QGB keys
This step helps get you prepared for when the Quantum Gravity Bridge is ready to be deployed. You would still need to go through this step before running a validator to configure 2 extra keys.
--evm-address
: This flag should contain a0x
EVM address. Here, you can add any Ethereum-based address to this flag. You can also modify it later if you decide to switch addresses.
You can set both the values to the above flags as environment variables:
EVM_ADDRESS=<EVM_ADDRESS>
Remember to add the values for your addresses in the above environment variables before setting them.
Run a validator node
After completing all the necessary steps, you are now ready to run a validator! In order to create your validator on-chain, follow the instructions below. Keep in mind that these steps are necessary ONLY if you want to participate in the consensus.
Pick a moniker
name of your choice! This is the validator name that will show
up on public dashboards and explorers. VALIDATOR_WALLET
must be the same you
defined previously. Parameter --min-self-delegation=1000000
defines the
amount of tokens that are self delegated from your validator wallet.
Now, connect to the network of your choice.
You have the following option of connecting to list of networks shown below:
Continuing the Validator tutorial, here are the steps to connect your validator to Mocha:
MONIKER="your_moniker"
VALIDATOR_WALLET="validator"
celestia-appd tx staking create-validator \
--amount=1000000utia \
--pubkey=$(celestia-appd tendermint show-validator) \
--moniker=$MONIKER \
--chain-id=mocha \
--commission-rate=0.1 \
--commission-max-rate=0.2 \
--commission-max-change-rate=0.01 \
--min-self-delegation=1000000 \
--from=$VALIDATOR_WALLET \
--evm-address=$EVM_ADDRESS \
--keyring-backend=test
You will be prompted to confirm the transaction:
confirm transaction before signing and broadcasting [y/N]: y
Inputting y
should provide an output similar to:
code: 0
codespace: ""
data: ""
gas_used: "0"
gas_wanted: "0"
height: "0"
info: ""
logs: []
raw_log: '[]'
timestamp: ""
tx: null
txhash: <tx-hash>
You should now be able to see your validator from a block explorer like here