Moving a validator.
When you wish to move a validator, the most important part is that you do not cause yourself to get slashed. "Slashing" is a large penalty and a forced exit of the validator.
The first slashings on mainnet occurred because someone was running a validator in two places at once. Don't be that person.
Read the Ethereum PoS primer to understand how a validator can get slashed. The most common way is to simply run two copies of it at once.
When to move
When you absolutely have to. You incur an offline penalty of 3/4 of the reward you could have made in the same time. This means it is often better to take a day or several of downtime and work on getting the node back online, than risk slashing while moving validator keys.
That said, if you are down during non-finality, or are abandoning a node to start a new one elsewhere, you may need to know how to move your key(s) safely.
What you'll need
- Your signing keys in keystore-m JSON format, and the password for them
If you do not have these any more, you can recreate them with the
existing-mnemonic
workflow of deposit-cli,./ethd cmd run --rm deposit-cli-existing
in this project, or offline to be very secure.
- Ideally, an export of the slashing protection DB. If you are using Eth Docker,
./ethd keys delete
will export the slashing protection database. - A checklist, and diligence
Checklist
Are you positive you need to move? Can you take a day or a couple of downtime and bring your old node back up? If so, do that.
Assuming you must move the validator keys to a new client, here are the steps.
Bring down old client
First, you'll want to bring down the old client and make sure it can't come back up.
In the directory of the old client:
-
./ethd keys list
-
./ethd keys delete all
so you get the slashing protection database -
./ethd terminate
Verify
Verify that you removed the right client:
-
./ethd cmd run --rm validator
- confirm that it complains it cannot find its keys. If it still finds validator keys, do not proceed until you fixed that and it doesn't.For Nimbus and Teku, the command is
./ethd cmd run --rm consensus
instead - Look at https://beaconcha.in/ and verify that the validator(s) you just removed are now missing an attestation. Take a note of the epoch the last successful attestation was in.
- Verify that both machines are synchronized to time and are using NTP.
- Allow 15 minutes to go by and verify that the last successful attestation's epoch is now finalized. Only then take the next step.
Import keys into new client
- SCP (or USB sneaker-net) the keys to
.eth/validator_keys
in the project directory - Ideally, also copy
slashing_protection*.json
to.eth/validator_keys
- Verify once more that all your validator(s) have been down long enough to miss an attestion
- Verify once more that trying to start the validator on the old client has it complaining it can't find keys, so that there is no way it could run in two places.
- If you are absolutely positively sure that the old validator client cannot start attesting again and 15 minutes have passed / all validators' last successful attestation is in a finalized epoch, then and only then:
- Start the new client with
./ethd up
- Run
./ethd keys import
and import the keys
Variant: DR consensus client
You can keep a client fully synchronized without keys. No keys "ready to be imported" on the node, and no keys imported. That way, if and when you do need to move, you do not need to wait for initial sync.