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 ports 30333 and 30343 for libp2p protocol/validator network, 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 these 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
Last updated