Some recommendations on security of the host, general operation, and key security.
Do not run two validator clients with the same validator keys imported at the same time
You'd get yourself slashed, and no-one wants that. Protecting you from this is a work in progress. Choose one client, and one client only, and run that.
The bare metal installation guide
by /u/SomerEsat has excellent notes on Linux host security. Running
is highly recommended, time matters to validators. Note the ports
you will need to open in
ufw depend on the client you choose.
execution client: 30303 tcp/udp, forwarded to your server
consensus client: 9000 tcp/udp, forwarded to your server
grafana/web UI: 443 tcp, forwarded to your server, assuming you are using the reverse proxy.
The grafana port is insecure http:// if no reverse proxy is in use, and should then only be access locally. An SSH tunnel is also a great option if you do not want to use the reverse proxy.
You likely want to wait to deposit your ETH until you can see in the logs that the execution client (e.g. geth) is synchronized and the consensus client is fully synchronized. This takes hours on testnet and could take days on mainnet.
If you deposit before your client stack is fully synchronized and running, you risk getting penalized for being offline. The offline penalty during the first 5 months of mainnet will be roughly 0.13% of your deposit per week.
Wallet and key security
The security of the wallet mnemonic you create is critical. If it is compromised, you will lose your balance. Please make sure you understand Ethereum staking before you use this project.
When you create the deposit and keystore files, write down your wallet mnemonic and choose a cryptographically strong password for your keystores. Something long and not used anywhere else, ideally randomized by a generator.
.eth/validator_keys will contain the
files created by staking-deposit-cli.
deposit_data-TIMESTAMP.json for your initial deposit. After that, it can be disposed of.
keystore-m_ID.json files to import your validator secret keys into the validator client
instance of the client you are running. These files need to be secured when you are done
with the initial import.
Validator Key Security
keystore-m_ID.json files have to be stored securely outside of this server. Offline
is best, on media that cannot be remotely compromised. Keep the password(s) for
these files secure as well, for example in a local (not cloud-connected) password vault
on a PC that is not on the network, or at the very least not used for online access.
Once you have the keystore files secure and they've been imported to the validator client container
on your server, you should delete them from the
These files will be needed in case you need to restore your validator(s).
An attacker with access to these files could slash your validator(s) or threaten to slash your validator(s).
For more on validator key security, read this article: https://www.attestant.io/posts/protecting-validator-keys/
Withdrawal Key Security
When you ran staking-deposit-cli, a 24-word mnemonic was created. This mnemonic is used for Ethereum validator exits and withdrawals. It must be securely kept offline. Without this mnemonic, unless you set a withdrawal address via
--execution_address, there is no way to withdraw your funds.
Precise methods are beyond this README, but consider something as simple as a sheet of paper kept in a fireproof envelope in a safe, or one of the steel mnemonic safeguards that are available.
Test your mnemonic before you deposit, so you know that you will be able to withdraw funds in future.
An attacker with access to your mnemonic can drain your funds, if no withdrawal address was set during key generation. If one was set, they can't get the validator funds, but can cause a "slashing", a penalty of around 1.1 ETH and forced exit of the validator.
For more on withdrawal key security, read this article: https://www.attestant.io/posts/protecting-withdrawal-keys/
Testing your mnemonic can be as simple as typing it into deposit-cli with
existing-mnemonic, then comparing the public key(s) of the resulting keystore-m signing key files to the public keys you know your validator(s) to have. The safest way to do this is offline, on a machine that will never be connected to Internet and will be wiped after use.