Umbrella Validator Overview
The Role of a Delegator
The ultimate purpose of the Atom is a utility token used to secure the Cosmos Hub. Therefore, it is the duty of every Atom holder to delegate to validators that will maximize the security of the network. This means two-fold: A) the delegator must choose a validator that maximizes decentralization of the network and B) the delegator must choose a validator that is secure.
Why does decentralization matter?
The ultimate security of the Cosmos Hub depends on having a diverse set of validators. When a small number of validators grow too big, the network is more likely to be halted due to downtime and more easily attacked by a set of malicious actors. Having a large number of smaller validators is advantageous because it diversifies the network’s geographical footprint as well as design architecture. If all validators are located in San Francisco or if all validators use the same hardware architecture, it increases the chance for the network to go down.
Maximizing for decentralization is easy — a delegator can look at any explorer and simply delegate to the smallest validator. However, delegating to an insecure validator makes the network less secure as well. An insecure validator is less resistant to attacks such as DDoS and hacking attempts and is more likely to be down or slashed.
Therefore, the delegator must choose a good balance between security and decentralization. How does a delegator do this? Unfortunately, this requires a little bit of research on the delegators’ end. The delegator must read security documents posted by validators and ensure sufficient diversification in both design as well as other factors such as geography. Of course validator also need to openly supply information about their operations to delegators. The purpose of this document is to showcase Umbrella’s security such that delegators can choose to decide if delegating to Umbrella is right for their Atoms as well as the network.
High-level Validator Setup
One of the main methods we use to secure our validator is restricting access to the physical validator. The more restrictive it is to access the validator, the harder it is for a potential attacker to cause problems or gain access.
The Validator
Our validator server has no direct access to the broader internet. It only has a connection to a private network. All ports and all SSH access is locked down except for very specific whitelisted local IP addresses. The whitelisted connections are only comprised of a handful of private and public sentry nodes.
Sentry Network
Our sentries are connected to the broader internet. However, all ports are disabled except the ones necessary for peering with sentries/validators. SSH access is enabled only for a limited number of whitelisted IP addresses. We have sentries in multiple cloud providers to maximize coverage and redundancy. We have infrastructure in place to spin up a new public sentry node if any one is under a DDoS attack. To also combat censorship and other attacks, we utilize private sentries (also known as relay nodes), which are only accessible to a private set of validators.
Monitoring and Alerting
We have a robust, multi-sourced monitoring and alerting system that detects when our validator is not signing blocks. We do not rely on any of our own validator or sentry node for our monitoring system. We specifically designed our system such that we would still receive alerts when all of our sentry nodes go down at once. To achieve this, we utilize redundant public full nodes to supply information about our validator’s activity.
