鼓励每位验证者候选人独立运行其运维体系，因为多样化的部署方式能够提升网络的韧性。验证者候选人应立即开始搭建工作，以确保能赶上主网上线。

​
密钥管理 - HSM

确保攻击者无法窃取验证者密钥是至关重要的。如果这种情况发生，委托给被攻陷验证者的全部质押都将面临风险。硬件安全模块是降低此类风险的重要策略。 HSM 模块必须支持 Hub 所需的 ed25519 签名。YubiHSM2 支持 ed25519，并且这里提供了一个 yubikey 库。YubiHSM 可以保护私钥，但无法在安全环境中确保它不会对同一个区块进行重复签名。 CometBFT 团队也在推进扩展我们的 Ledger Nano S 应用，以支持验证者签名。该应用可以存储最近的区块，从而缓解双重签名攻击。 随着更多密钥存储解决方案可用，我们会更新此页面。

​
哨兵节点（DDOS 防护）

验证者有责任确保网络能够承受拒绝服务攻击。 一种推荐的风险缓解方式，是让验证者精心规划其网络拓扑，采用所谓的哨兵节点架构。 验证者节点应仅连接到其信任的全节点，这些全节点要么由其自行运行，要么由其在线下社交关系中熟悉的其他验证者运行。验证者节点通常会部署在数据中心中。大多数数据中心都提供到主要云服务提供商网络的直连链路。验证者可以利用这些链路连接部署在云上的哨兵节点。这样可以将拒绝服务攻击的压力从验证者节点本身转移到其哨兵节点上，并且在缓解针对现有哨兵节点的攻击时，可能需要快速新增或启用新的哨兵节点。 哨兵节点可以快速部署，也可以更换其 IP 地址。由于到哨兵节点的链路位于私有 IP 空间中，基于互联网的攻击无法直接干扰这些链路。这将确保验证者的区块提案和投票始终能够传递到网络的其余部分。 要搭建你的哨兵节点架构，可以按照以下说明操作： 验证者节点应编辑其 config.toml： 
# 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
哨兵节点应编辑其 config.toml： 
# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
# Example ID: [email protected]:26656

private_peer_ids = "node_ids_of_private_peers"

​
环境变量

默认情况下，带有以下前缀的大写环境变量会覆盖对应的小写命令行标志：
  • GA（用于 Gaia 标志）
  • TM（用于 Tendermint/CometBFT 标志）
  • BC（用于 democli 或 basecli 标志）
例如，环境变量 GA_CHAIN_ID 会映射到命令行标志 --chain-id。请注意，虽然显式传入的命令行标志优先级高于环境变量，但环境变量的优先级又高于任何配置文件。因此，务必锁定你的运行环境，确保所有关键参数都通过 CLI 标志定义，或者阻止任何环境变量被修改。
Each validator candidate is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validator candidates should commence their setup phase now in order to be on time for launch.

​
Key Management - HSM

It is mission critical that an attacker cannot steal a validator’s key. If this is possible, it puts the entire stake delegated to the compromised validator at risk. Hardware security modules are an important strategy for mitigating this risk. HSM modules must support ed25519 signatures for the hub. The YubiHSM2 supports ed25519 and this yubikey library is available. The YubiHSM can protect a private key but cannot ensure in a secure setting that it won’t sign the same block twice. The CometBFT team is also working on extending our Ledger Nano S application to support validator signing. This app can store recent blocks and mitigate double signing attacks. We will update this page when more key storage solutions become available.

​
Sentry Nodes (DDOS Protection)

Validators are responsible for ensuring that the network can sustain denial of service attacks. One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture. Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links to the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator’s node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones. Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attack cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network. To setup your sentry node architecture you can follow the instructions below: Validators nodes should edit their config.toml: 
# 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
Sentry Nodes should edit their config.toml: 
# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
# Example ID: [email protected]:26656

private_peer_ids = "node_ids_of_private_peers"

​
Environment Variables

By default, uppercase environment variables with the following prefixes will replace lowercase command-line flags:
  • GA (for Gaia flags)
  • TM (for Tendermint/CometBFT flags)
  • BC (for democli or basecli flags)
For example, the environment variable GA_CHAIN_ID will map to the command line flag --chain-id. Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it’s imperative that you lock down your environment such that any critical parameters are defined as flags on the CLI or prevent modification of any environment variables.