Celestia Blockspace Race Testnet: setting up a secure validator — sentry architecture for your infra
We wrote an article on how to set up sentries and validators on the same machine, but that specific use case is not a real mainnet scenario. So after participating in Celestia’s testnet we decided to write this article on how to set up a validator — sentry node architecture in Celestia (but could also valid for any other Cosmos networks), so it could help others with the task in the future.
First of all, you will have to set up all your nodes to be able to run the Celestia node daemon and configure them to connect to the Celestia Blockspacerace-0 testnet network.
For the installation you need to install go in your server. After that, you have to get Celestia’s source code and compile it.
sudo apt install make clang build-essentials jq
git clone https://github.com/celestiaorg/celestia-app.git
cd celestia-app/
APP_VERSION=v0.12.1
git checkout tags/$APP_VERSION -b $APP_VERSION
make install
Check that your binary has compiled correctly (should return the Celestia binary version)
celestia-appd version — long
You’re ready to connect to blockspacerace-0 network, so run the following command to init the node pointing to blockspacerace-0 network
export MONIKER=”YOUR_MONIKER”
celestia-appd init $MONIKER — chain-id blockspacerace-0
No you should download the genesis file corresponding to blockspacerace-0 network
git clone https://github.com/celestiaorg/networks.git
cp $HOME/networks/blockspacerace/genesis.json $HOME/.celestia-app/config
Now your node is good to start and get in sync with the chain, so start your node
celestia-appd start
That’s it for setting up a node, have in mind that you would have to repeat this process on each of the nodes that you’re running, in our case 4 nodes (3 sentries and 1 validator), so once you’re done continue with the guide.
For the validator you would need to create the validator on one of the nodes (should be synced to the network), for that you would need some blockspacerace-0 tokens.
First create the wallet that you would use to manage your validator.
celestia-appd keys add my-validator-wallet
Get the address of the wallet, visit Celestia Discord faucet channel for sending some blockspacerace-0 tesnet tokens to it. Once you have tokens on that wallet you can create your validator.
celestia-appd tx staking create-validator \
— from my-validator-wallet \
— amount 1000000000utia \
— min-self-delegation 1000000000utia \
— commission-rate 0.01 \
— commission-max-rate 0.1 \
— commission-max-change-rate 0.1 \
— pubkey “$(celestia-appd tendermint show-validator)” \
— chain-id blockspacerace-0
Now check that your validator has created successfully by checking the voting power, should be greater than 0.
celestia-appd status | jq .ValidatorInfo.VotingPower
Congratulations! your node is validating in the Celestia’s blockspacerace-0 network. Now that all nodes are running and in sync, let’s begin configuring our sentry-validator architecture.
To config the nodes you should edit their corresponding config.toml files located at (~/.celestia-app/config/config.toml) and set the corresponding configuration to each type (N sentry nodes and 1 validator).
For a mainnet setup composed of sentries and validator the configuration of your nodes should contain the following structure (replace the field values in the config file):
## Validator node configuration
pex = false
persistent_peers =list of sentry nodes
private_peer_ids =omitted
addr_book_strict =false## Sentry Node Configuration
pex =true
persistent_peers =validator node, and optionally other sentry nodes private_peer_ids = validator node id
addr_book_strict = false
As you may know, the way to specify a node is the following:
node_id@node_ip:p2p_port
By default the p2p port for Cosmos networks is 26656, and the tendemint node id can be obtained with the following command
celestia-appd tendermint show-node-id
To get your node ip execute the command
ip a
A valid example could be:
47a763c7c542db370f0a7e380d355f89c6f1115b@10.20.14.124:26656
If our setup nodes would have the following values (node ids and ip’s are not real, for the sake of simplicity of the guide):
Sentry 1: 111@1.1.1.1:26656
Sentry 2: 222@2.2.2.2:26656
Sentry 3: 333@3.3.3.3:26656
Validator: 444@4.4.4.4:26656
the setup configuration would actually look like this:
# Sentry 1 config (111@1.1.1.1:26656)
persistent_peers = “222@2.2.2.2:26656,333@3.3.3.3:26656,444@4.4.4.4:26656”
addr_book_strict = false
pex = true
private_peer_ids = “444”# Sentry 2 config (222@2.2.2.2:26656)
persistent_peers = “111@1.1.1.1:26656,333@3.3.3.3:26656,444@4.4.4.4:26656”
addr_book_strict = false
pex = true
private_peer_ids = “444”# Sentry 3 config (333@3.3.3.3:26656)
persistent_peers = “111@1.1.1.1:26656,222@2.2.2.2:26656,444@4.4.4.4:26656”
addr_book_strict = false
pex = true
private_peer_ids = “444”# Validator config (444@4.4.4.4:26656)
seeds = “”
persistent_peers = “111@1.1.1.1:26656,222@2.2.2.2:26656,333@3.3.3.3:26656”
addr_book_strict = false
pex = false
private_peer_ids = “”
As you may see, all the sentries have the pex value set to true, this makes the nodes try to discover and connect to nodes of the network, but not for the validator. The sentries are also set to have the validator as a private peer (private_peer_ids value), so the validator it isn’t gossipped to the rest of the network and remains anonymous.
Besides that, the validator is connected to all the sentries that will act as a proxy connection to the P2P network, and the sentries are connected to the validator, and optionally to other validators (as in this case).
Now is time to restart all of your nodes, so stop the daemon on each server and start it again
celestia-appd start
A good way to test that your validator is hidden from the network, is to check that the validator is only able to connect to the network when at least 1 sentry node is running and in sync. So set all your nodes working, and stop all the 3 sentries, and check that the validator node is not able to sync and sign blocks anymore, start 1 sentry node again and check that the validator syncs again and begins signing blocks too.
Also, don’t forget to set your security practices on all your nodes (firewall, ssh access, certificates, service unit file, etc.).
And that’s it! Hope it helps you set a better infrastructure for your Cosmos validators and mitigate those possible DDoS attacks.
For further info you can have a look at Cosmos forums on the topic, or just ask in Celestia validator communities Discord channels. And of course have a look at this interesting Cosmos DeFi project, Celestia.
