We use bare metal servers running in secure data centres in multiple locations that are exclusively used to run our software. The servers are not part of any "cloud" provider.
We use a multi-layer design. The outer layer is beacon nodes, which store the state of the Ethereum chain and communicate with similar nodes around the world. Servers in this layer are redundant, and run one of a number of different software implementations to provide maximum reliability.
The middle layer is validator clients, which decide what and when to sign Ethereum blocks and attestations. Servers in this layer are redundant, and connect to one or more servers in the first layer to inform their decisions and to broadcast the results.
The third layer is signers, which secure private keys and manage the process of signing information provided by the validator clients. We provide a highly secure signing system, based on distributed key generation, to provide both security and resilience to attack or failure.
Layers are cleanly separated and communications between layers as well as to external entities is kept to a minimum.
We also employ various operational measures to keep server, validator and key security at the highest level.
Customers are expected to login using FIDO2 authentication methods. Typically this will mean that you will require an external hardware device (such as a Yubikey, Trezor or smartphone) which will securely hold your credentials and often require biometrics or other authentication to access them.
Our servers are located in data centers across the globe. The servers are designed to be interchangeable, allowing one to take over the workload of another if a particular server, data center, or jurisdiction becomes problematic.
Normal operations distribute validators across multiple servers. If you have a particular requirement for geographical location please contact us.
We have introduced a distributed signing facility to our validator infrastructure which uses built-in slashing protection on every relevant signing request. Account private keys are generated in a distributed fashion across a number of servers and are never instantiated anywhere in the infrastructure. Signing requests are actioned on an "m of n" threshold system, where any m of the n signers can provide a valid signature. Distributed key generation provides a high level of security, and threshold signing provides a high level of availability. Slashing protection ensures that it is not possible for there to be two different signatures for the same attestation or proposal, as well as refusing to sign any attestation that could cause slashing penalties to be invoked against the requesting validator.
For example, double voting is when a validator votes for two different blocks during the same epoch. This is broadly equivalent to a "double spend" in a Proof of Stake system and is severely punished by the network. In order to prevent this all Attestant validators must pass through the distributed signing facility which ensures that a validator can only sign one block during the epoch. In order for a slashing event to occur a majority of the signing servers would have to be compromised.
There are several other situations which can lead to slashing which require careful tracking of the validator behaviour, and this is built into the Attestant infrastructure.