Validators play a key role in maintaining network resilience, especially during denial-of-service (DoS) attacks. One of the most effective ways to protect a validator node is by using a sentry node architecture.

In this setup, validator nodes do not connect directly to the public P2P network. Instead, they connect only to a set of trusted full nodes called sentry nodes. These sentries act as a buffer between the validator and the rest of the network, absorbing public traffic and insulating the validator from direct exposure.

Validator nodes are usually hosted in secure data centers, which often have fast, private links to cloud environments. Validators can use these private connections to reach their sentry nodes, which are deployed in the cloud or other isolated environments. Since the public never sees the validator’s IP, attackers cannot target it directly.

Sentry nodes, by contrast, can be rotated, scaled, or assigned new IPs quickly to handle DoS threats. As long as the validator maintains stable, private connections to its sentries, its consensus participation—like proposing blocks and signing votes—remains uninterrupted, even during active attacks on the public network.

More details available in the Cosmos Hub docs:

🔗 Sentry Nodes (DDOS Protection)

​
Config setup for sentry-node architecture

To setup your sentry node architecture you can follow the instructions below:

Validators nodes should edit their config.toml:

# 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

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: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656

private_peer_ids = "node_ids_of_private_peers"