Eternal Royalty


How the ETH 2.0 Validator Nodes will be setup
The first step in the setup process is ensuring the private keys are stored safely to ensure that we always have access to the Validator Nodes. We have a system in place to ensure the keys are stored in cold storage as well as contingencies in place in the case of any members demise.
We will use the Eternal Royalty owner wallet to create the Validator Nodes. This wallet is a cold storage wallet with contingencies for anyone's demise.
We aim to have multiple servers: one cloud server as well as one local server to ensure maximum up-time and rewards. We will first setup the cloud server and ensure functionality before setting up a local backup server in the case of any down time from the cloud server.
The cloud server provider we have chosen is Linode. We made this decision for multiple reasons. The primary reason being that our expertise lie with Linode and therefore, allows more freedom in what we can do with the server compared to other providers. Another reason being we are aware that a lot of 'solo stakers' are using AWS as a cloud provider for their server and using AWS would mean the network would be more centralised.

Cloud Server Hardware

  • CPU: 32 cores
  • RAM: 64GB
  • Storage: 1280GB + 2000GB
  • OS: Debian

Local Server Hardware

  • CPU: 64 cores
  • RAM: 256GB
  • Storage: 10TB
  • OS: Debian (VM)
We will be using Debian server as the OS (Operating System) on both servers. This is because it is lightweight as well as being trialled and tested. We will also use Docker on both instances to make the management of each node easier. We will be using the eth-docker container provided by eth-educators on GitHub as this is also trialled and tested. Another benefit of using Docker containers to manage the Validator Nodes is the ease of backup and restarting in case of any issues.
We will be using Besu for our ETH 1.0 client as it is important to ensure decentralisation even with software. Also this ensures interoperability with the ETH 2.0 client that we will be using.
We will be using Teku for the ETH 2.0 client for the same reasons mentioned above.
We are keeping up to date with the latest staking updates to ensure that slashing (penalised by the network) doesn't occur. We know of instances where Validators were penalised for sharing a key with multiple Validator Nodes. We are cautious to any slashing that may happen.