Search…
⌃K

Securing your validator

Even though this page attempts to cover some good practices when setting up a validator, it is not meant to be an absolute guide for creating an iron-clad validator but rather a starting point.

Rationale

As a validator, you are one of the key enablers of block production and consensus, and you need to maintain your reputation in eyes of the nominators. To that end, a validator node has to maintain:
  • high availability: for uninterrupted operation
  • high security, especially with regard to its session keys: if a malicious actor managed to access the keys, they would be able to commit slashable behavior on behalf of the validator

High availability

Even though, in contrast to a lot of chains, the Aleph Zero chain does not punish downtime by slashing, it is still in your best interest to be online as much as possible for two main reasons:
  • you are not getting rewards for the time you are offline
  • your nominators will notice that your node is not reliable and will choose to nominate another validator.
Some recommendations are quite trivial but important nonetheless:
  • run on good quality hardware and prefer bare metal to VM-s
  • ensure stable and fast internet connection
  • make sure you have plenty of disk space (or monitor it regularly if you want to provision it on demand)
While it may seem like a good idea to introduce redundancy (i.e. run more than one node as the same validator), it is not a good idea:
  • you will need to somehow share the session keys between the nodes and that may expose them
  • you may be slashed for equivocation if both nodes are taking part in the consensus at the same time

Security

As mentioned above, you need to keep your keys a secret and the best way to start is to follow standard security practices:
  • setup a firewall and only expose to the outside world the ports you really need (in case of the validator node it is usually the port 30333 for libp2p protocol and a port for SSH access)
  • you may want to change the SSH port to something less obvious than 22
  • disable password authentication in SSH and only use key-based authentication
  • for the safest setup, you may consider turning SSH off altogether (if you have physical access to the machine)
  • avoid using the root account

Monitoring

We suggest monitoring your nodes using a combination of three methods:
  • Grafana: for setting up your own dashboards with detailed metrics
  • Telemetry: for publicly sharing basic statistics about your node
  • Logs: for manually monitoring the health of your node
Grafana
It is recommended to setup monitoring and alerts for your node using the standard Prometheus metrics (by default exposed by Aleph Node on port 9615). The recommended tool for digesting the metrics is Grafana and for convenience we've made the config template available here.
Telemetry
The telemetry is enabled by default in the dockerised setup. If you want to disable it (which we strongly advise against), go to your env/validator config file and set TELEMETRY_ENABLED=false.
If the telemetry is enabled, you will be able to monitor your node's performance here.
If you're building the node from source and running a plain binary, you will need to supply the --telemetry-url 'wss://telemetry.polkadot.io/submit/ 1' option when you run the node.
Logs
The text logs from the node can provide useful information when something is wrong. You may want to keep an eye out for:
  • various error messages
  • lack of messages about finalization or importing
  • your node being behind on finalization for prolonged periods of time