The Sentry Node Architecture is an infrastructure example for DDoS mitigation on Tendermint-based networks.
Secret Nodes (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 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 attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network.
For those implementing Sentries on Validators who already have Public IP exposed. Currently any peer, be it a validator or full node, is given 16 attempts with exponential backoff, which in total amounts to around 35 hours, to connect. If the node remains unreachable then it is automatically removed from the address book. An unreachable validator node is not gossiped across the network i.e. all other nodes will each try to connect to the unreachable validator node before removing it from their address book.
Log into your sentry node(s), and validator, then run the following commands to get the peer information:
Get node id
Save your peer information, be sure to remember which are for sentries and which is for your validator, you'll need it later:
To setup basic sentry node architecture you can follow the instructions below:
Sentry Nodes should edit their config.toml:
First follow the Full Node Guide
Edit the full nodes config file you want to use as a sentry node:
Proceed to add the peer id of your validator to the .secretd/config/config.toml:
Now proceed to restart your secret node with the following command.
You now have a sentry node running!
Validators nodes should add their sentry node peer information to their .secretd/config/config.toml:
Proceed to add the peer id of your sentry nodes to the persistent_peers list and set pex to false:
Now proceed to restart your secret node with the following command.
You're now running your validator behind a sentry node!
https://github.com/cosmos/gaia/blob/master/docs/validators/security.md
These pages go into detail for setting up infrastructure other than full nodes and validators.
Creating Archives nodes is not possible as this time. Please use the provided API Archive nodes in API Endpoints Mainnet (Secret-4) if you need access to an Archive.
An archive node keeps all the past blocks. An archive node makes it convenient to query the past state of the chain at any point in time. Finding out what an account's balance, stake size, etc at a certain block was, or which extrinsics resulted in a certain state change are fast operations when using an archive node. However, an archive node takes up a lot of disk space - nearly 2TB for secret-4 as of Feb 1, 2023.
More on hardware support here.
Note that syncing from scratch/following these instructions takes several weeks, since state-sync is not available for Archive Nodes.
To setup your archive node you can follow the instructions below:
secretdTo install secretd, please visit Install secretd.
Setup the node using the Running a Full Node guide. You should stop at the Set minimum-gas-price Parameter step.
Do NOT begin syncing yet!
secretdNow that you have registered the node with the latest version, install v1.2.0-archive.
Note that the secret-node system file is created in a previous step.
If everything above worked correctly, the following command will show your node streaming blocks (this is for debugging purposes only, kill this command anytime with Ctrl-C). It might take a while for blocks to start streaming, so grab some 🍿 while you wait!
You now have an Archive node running!
Syncing a node from scratch means that from time to time you'll need to perform an upgrade (at the block height that the upgrade was originally took place on mainnet).
You will need to use the designated archive-node binaries when available. For the rest of the upgrades, use the binaries for the respective version from the releases page.
As of the writing of these lines, the upgrade timing (in block-height) are:
v1.3.0 - block height 3,343,000 (binaries).
v1.4.0 - block height 5,309,200 (binaries).
v1.5.0 - block height 5,941,700 (binaries).
v1.6.0 - block height 6,537,300 (binaries).
For more detailed upgrade instructions, you can refer to the v1.5.0 upgrade instructions.
Note: Mantlemint is currently in beta. This means some of these instructions may not work as expected, or could be subject to change
Mantlemint is a fast core optimized for serving massive user queries. A mantlemint node will perform 3-4x more queries than a standard Secret Node.
Native query performance on RPC is slow and is not suitable for massive query handling, due to the inefficiencies introduced by IAVL tree. Mantlemint is running on fauxMerkleTree mode, basically removing the IAVL inefficiencies while using the same core to compute the same module outputs.
If you are looking to serve any kind of public node accepting varying degrees of end-user queries, it is recommended that you run a mantlemint instance alongside of your RPC. While mantlemint is indeed faster at resolving queries, due to the absence of IAVL tree and native tendermint, it cannot join p2p network by itself. Rather, you would have to relay finalized blocks to mantlemint, using RPC's websocket.
Mantlemint has been adapted for Secret Network from Terra.
Superior LCD performance
With the exception of Tendermint RPC/Transactions.
Super reliable and effective LCD response cache to prevent unnecessary computation for query resolving
Fully archival; historical states are available with ?height query parameter.
Fully synced RPC Node with Websockets available
To start a Mantlemint node, you'll need **** access to at least 1 running RPC node. Since Mantlemint cannot join p2p network by itself, it depends on RPC to receive recently proposed blocks. This RPC node should also have Websockets enabled. Websockets are how Mantlemint receives new blocks after it catches up to the current block.
1TB of storage (recommended SATA or NVMe SSD)
16 GB of RAM (recommended 32 GB)
2 available CPU cores (recommended 4 cores)
Mantlemint can only be ran as a full archive node. For this reason it requires a large amount of storage (as of August 2022 this is currently 450GB).
a. Clone the repository https://github.com/scrtlabs/mantlemint
b. If you haven't already, install golang
c. Run go build -mod=readonly -o build/mantlemint ./sync.go
If you don't want to compile yourself, you can just download the mantlemint executable built for Ubuntu 20.04
Install SGX the same way you would for a node, as described in the Node Setup section
secretd packageTo allow Mantlemint to sync blocks and run queries that contain encrypted data, we will need to register it.
This directory should be separate from other mantlemint instances or secretd instances
Create a config/app.toml file in your mantlemint directory, and set it with a similar app.toml file to what a secretd node uses
Example app.toml file:
To start mantlemint, we highly recommend using a snapshot. The earlier one starting from block 3340000. This will save having to switch out mantlemint binaries to account for network upgrades.
To download and unpack a snapshot, use the following command
Make sure the files are unpacked in your chosen mantlemint directory
Pro Tip: Currently Mantlemint is fully archival. That means snapshots are really large. This command will download and unpack the snapshot without having to use twice the storage amount
Now we are ready to run Mantlemint. It's slightly awkward to run as you have to set multiple environment variables, but they're fairly straightforward. An example run command would be -
That's it!