Skip to main content

Validator Security

It is recommended that each validator operate independently to increase the network's resilience. Candidates for the validator should set aside adequate time to ensure a secure validator launch.

You can discover the best techniques for running a validator safely without compromising block sign performance in this section. This covers details on how to protect your private keys, manage a cluster of nodes with remote access, reduce the chance of double signing, and help the network's DDOS defenses by using sentry nodes.

A validator security checklist is also included to help you assess the security measures in place at a validator right now.

Horcrux​

Horcrux, a multi-party-computation (MPC) signing service for Tendermint nodes, enhances the security and availability of your validator infrastructure. It provides:

  • Consists of a cluster of signer nodes in place of a remote signer, offering fault tolerance and High Availability (HA) for block signing.
  • Use threshold Ed25519 signatures to secure your validator private key by distributing it among several private signer nodes.
  • Increase availability and security without affecting block sign performance.

To upgrade your validator infrastructure using Horcrux, refer to the documentation here.

Hardware HSM​

It is essential that a validator's key cannot be stolen by an attacker. This raises the possibility of losing the entire stake given to the compromised validator. The use of hardware security modules is a crucial risk-reduction tactic.

For Humans.ai, HSM modules must support ed25519 signatures. ed25519 is supported by the YubiHSM 2, which may be used with this YubiKey library.

info

🚨 IMPORTANT: The YubiHSM can safeguard a private key, but it cannot guarantee that it won't sign the same block twice in a secure environment.

Tendermint KMS​

YubiHSM2 and Ledger Nano are two examples of Hardware Security Modules (HSMs) that are supported by the signature service Tendermint KMS. In addition to offering defense-in-depth for online validator signing keys, double signing protection, and serving as a central signature service that can be used when operating numerous validators in various Cosmos Zones, it is designed to be deployed alongside Cosmos Validators, ideally on distinct physical hosts.

Learn how to set up a Tendermint KMS Key Management System for Humans.ai here.

Sentry Nodes (DDOS Protection)​

The task of validators is to make sure the network can withstand denial-of-service assaults. Validators are advised to carefully design their network topology in a so-called sentry node architecture to reduce these hazards.

Only full nodes that validator nodes trust, either because they run them themselves or because they are operated by other validators they are familiar with socially, should be connected. Usually, a validator node operates in a data center. Most data centers offer direct connections to the networks of the largest cloud service providers. These links allow the validator to communicate with cloud-based sentry nodes. It may be necessary to spin up or activate new sentry nodes in order to minimize assaults on already-existing ones because this transfers the load of denial-of-service attacks from the validator's node to its sentry nodes.

Sentry nodes can swiftly alter their IP addresses or spin up. An internet-based attack cannot directly affect the sentry nodes because their links are in private IP space. This will guarantee that votes and proposals for validator blocks always reach the rest of the network.

tip

On the forum, you may read more about Sentry Nodes.

You can use the steps below to build up your sentry node architecture:

Edit your config.toml, validator nodes:

# Comma separated list of nodes to keep persistent connections to
# Do not add private peers to this list if you don't want them advertised
persistent_peers =[list of sentry nodes]

# Set true to enable the peer-exchange reactor
pex = false

Editing config.toml is advised for Sentry Nodes:

# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
# Example ID: 4f27af0cead27979e1fc3dac57d03df3c7c88bcd@181.67.123.125:26656

private_peer_ids = "node_ids_of_private_peers"

Validator Backup​

Backing up your validator's private key is critical. In the event of a disaster, it is the only way to restore your validator. A Tendermint Key, which is a special key used to sign consensus votes, serves as the validator's private key.

Note that if you are using Tendermint's "software sign" (the default signature method), your Tendermint key is available at:

~/.humansd/config/priv_validator_key.json

Then take these actions:

  1. Make a backup of the 'json' file (or the entire 'config' folder) that was previously specified.
  2. Create a backup of the wallet with the self-deleting feature. Wallet backup using the Humans.ai Daemon is described in [./../../protocol/concepts/key-management].

To view the corresponding public key for your validator:

humansd tendermint show-validator

To view the corresponding bech32 address for your validator:

humansd tendermint show-address

You can also use hardware, such as YubiHSM2, to keep your Tendermint Key considerably more securely.

Environment Variables​

By default, uppercase environment variables with the following prefixes will replace lowercase command-line flags:

  • HUMANS (for Humans flags)
  • TM (for Tendermint flags)
  • BC (for democli or basecli flags)

For instance, the command line flag --chain-id will correspond to the environment variable HUMANS_CHAIN_ID. Be aware that environment variables will take precedence over any of your configuration files, despite the fact that explicit command-line flags will always take precedence over environment variables. Because of this, you must secure your environment so that any crucial variables are defined as flags on the binary or that no environment variables can be changed.