Running in production¶
DOS Exposure and Mitigation¶
The core of the Tendermint peer-to-peer system is
MaxPacketMsgPayloadSize, which is the maximum packet size
and bounded send & receive queues. One can impose restrictions on send &
receive rate per connection (
Endpoints returning multiple entries are limited by default to return 30 elements (100 max).
Rate-limiting and authentication are another key aspects to help protect against DOS attacks. While in the future we may implement these features, for now, validators are supposed to use external tools like NGINX or traefik to achieve the same things.
Each Tendermint instance has a standard /health RPC endpoint, which responds with 200 (OK) if everything is fine and 500 (or no response) - if something is wrong.
Other useful endpoints include mentioned earlier /status, /net_info and /validators.
We have a small tool, called tm-monitor, which outputs information from the endpoints above plus some statistics.
Each Minter instance has a standard /api/status endpoint, which responds with 200 (OK) if everything is fine and 500 (or no response) - if something is wrong.
What happens when my app dies?¶
You are supposed to run Tendermint and Minter under a process supervisor (like systemd or runit). It will ensure Tendermint and Minter is always running (despite possible errors).
We catch SIGINT and SIGTERM and try to clean up nicely. For other signals we use the default behaviour in Go: Default behavior of signals in Go programs.
Processor and Memory¶
Minimal requirements are:
- 2GB RAM
- 100GB of disk space
- 1.4 GHz 2v CPU
SSD disks are preferable for high transaction throughput.
- 4GB RAM
- 200GB SSD
- x64 2.0 GHz 4v CPU
Tendermint and Minter can be compiled for a wide range of operating systems thanks to Go language. List of $OS/$ARCH pairs.
While we do not favor any operation system, more secure and stable Linux server distributions (like Centos) should be preferred over desktop operation systems (like Mac OS).