Kava Validator

  • Category: Validator
  • Network: Kava
  • Name: SG-1
  • Project URL: kava.io
  • Expected Reward Rate: 7-15%
  • Commission: 0%
  • Protection: 100% Soft Slash Protection

Kava Validator

Payout Frequency

Every block (~7 seconds)

Validator Address

kavavaloper1ppj7c8tqt2e3rzqtmztsmd6ea6u3nz6qggcp5e

CLI

Address


Stake with us


Our Validator Setup

As the validator setup we have chosen to use a 5-tier system of nodes, deployed over a range of servers.

The terminology can be taken from various sources, we deploy

  • Open RPC/API Nodes
  • Sentry Nodes
  • Relayer Nodes (experimental)
  • Validator Nodes
  • Backup Nodes

The open RPC/API nodes are designed for services to use. We are using those for our own services, but others can also choose to use them as the IP's are public and we have NGNIX SSL domain routing for them. They are recheable under a public domain aswell. As we scale, this infrastructure will also scale so we can initiate load-balancers in front of an army of open nodes for everyone to use.

The other four types of nodes play a crucial part in designing a top secure and high available validator network. The validator name is as our team SG-1.

Validator Architecture

On the architecture of the server setup, the sentry nodes are the first front. Those are connected to other nodes in the Cosmos / Kava ecosystem and gossip about newest transactions, blocks and updates. The IP of sentry are public. A minimum of 3 sentry nodes should be online all the time to mitigate and failure and ensure data integrity around all the sentry nodes.

The validator nodes are in direct contact with the sentry nodes. The IP of validator nodes is private, they have a carefully crafted firewall and whitelist IP connection range of the sentry nodes. Also the tenderming instance is only aware of the sentry nodes IP addresses. The validator node holds a private key generated by a KMS of our choice, where the passphrase is hold in a hardware wallet of our choice in a location that is known only to a few people. A minimum of 1 validator nodes should always be online.

Relayer nodes are still experimental in design and also for us. It should be carefully examined if they actually make the system more resilient and provide a reliable anti-DDOS protection or rather can be an additional fail-system where we have to be careful.

Backup nodes, for us usually limited to 1-2 per network, have a higher disk capacity than the other servers and act as creating backups. They shut down the gaiad for the time of taking the backup in an interval between 48 and 72 hours. So we always have a good state to use in case we need to deploy new servers and are quickly up-to-date with the blockchain.

With building this infrastructure, we keep in mind to distribute our servers splitted with own managed servers and servers hosted by different cloud providers. This enables us to scale geographically as well as in storage, computing and bandwith. Cost of a provider is not always the first indicator for us what to choose. But security, control, location and tools will always play a role in deciding which provider to choose.