Running an Initia Validator Node with good block signing performance.
How to effectively use remote signer to run an Initia validator node.
Initia Testnet Phase-3 has been running for a few weeks, nearing the end of testnet phases prior to mainnet launch. Cosmostation has been participating as a validator since Phase-1, and we’re extremely excited to take part in this journey alongside the vibrant developer and validator community. This blog post outlines a best-practice approach when it comes to improving validator node performance with the use of remote signer.
A validator’s responsibility
As a validator, setting up a node and syncing it to the latest block is one of the most basic tasks. Operating a validator node consists of many more complicated procedures and best practices to keep things running as performant and secure as possible.
Uptime is one of the most critical components of a validator node as it is responsible for keeping block signing active and ensuring the smooth operation of the blockchain.
In this post, we describe how an Initia validator node operator can optimize uptime effectively utilizing remote signer.
Validator Responsibility
In the Cosmos ecosystem, validators are responsible for signing blocks and participating in consensus. High uptime ensures that the validator node is available to sign blocks and participate in consensus rounds.
Uptime and Rewards
Validators with high uptime are more likely to be trusted by delegators and receive more staking rewards. Continuous participation in block signing and consensus leads to more rewards and a higher reputation within the network.
Current challenges of running an Initia validator node in Testnet Phase-3.
In order for a validator node to not miss block signing, keeping signing local is generally a good choice.
Normally you would keep the priv_validator_key.json file locally. However, there are some drawback to this:
- Loss of Key: Keeping the validator’s key in the server is not the best practice, as it may be lost or compromised anytime. This means that a node operator must invest tremendous effort in the security of the particular server where the keys are stored.
- Double Signing: Keeping the key locally may frequently cause risk of double signing to increase.
What is double signing?
Double signing occurs when a validating entity (private key) submits two signed messages for the same block. This can happen if a node operator or infrastructure provider optimizes their node configuration to prevent downtime by having a highly available backup entity running at the same time as a primary entity.
Using a remote signer as the solution
One of the best solutions is to use a remote signer. This way, we can keep the validator’s key separately and at the same time provide good block singing performance.
For this, we have used the third party tool horcrux.
The following documentation includes the full guide on migrating from a single validator instance to a signer cluster.
Our team also used the same tool to improve our block signing performance. But unfortunately, this was not enough. There was still the risk of downtime occuring anytime maintenance is in process (node data pruning with snapshot) or whenever peers in the region are not performant.
To handle this issue, we decided to run two validator nodes and connect them through horcrux.
./horcrux/config.yaml:signMode: threshold
thresholdMode:
threshold: 2
cosigners:
- shardID: 1
p2pAddr: tcp://111.22.33.44:11123
- shardID: 2
p2pAddr: tcp://111.22.33.44:11123
- shardID: 3
p2pAddr: tcp://111.22.33.44:11123
grpcTimeout: 100ms
raftTimeout: 100ms
chainNodes:
- privValAddr: tcp://112.12.13.14:11123
- privValAddr: tcp://113.32.33.34:11123
debugAddr: "0.0.0.0:11134"And similarly, those settings are set in validator nodes as following:
1. ./initiad-1/config/config.toml:
priv_validator_laddr = "112.12.13.14:11123"2. ./initiad-2/config/config.toml:
priv_validator_laddr = "113.32.33.34:11123"Results with metrics
If we look at the following Missing Block Grafana metrics for last 7 days we can see that, the maximum number of missed blocks are 4 blocks. And by this, we can be sure that our validator node never misses block signing in a large amount, and at the same time validator’s private key is safe apart from the node’s location.
Conclusion
With remote signer, we have been able to significantly improve our validator node’s performance. We’ve been participating in Initia Testnet Phase-3 without a hiccup, thanks to the vibrant community of developers and validators we are grateful to take on this journey with. If you’re a validator or developer in the ecosystem that needs assistance with validator operation, please reach out to Cosmostation at:
and business@cosmostation.io
About Cosmostation
Cosmostation is a Cosmos genesis validator and a key player in the Cosmos ecosystem, providing invaluable infrastructure legos essential for scaling and onboarding users onto blockchain networks. Through Mintscan, Cosmostation continues to drive the ethos of transparency and user-centric design, fostering a more insightful interaction with blockchain data across various networks. At Cosmostation, we bootstrap networks and onboard end-users.
Twitter: https://twitter.com/cosmostationvd
Website: https://www.cosmostation.io
Mintscan: https://www.mintscan.io
Email: business@cosmostation.io
