Skip to main content

Move to a new machine

Moving validators is safe if you follow one rule: the same key must never run in multiple validator clients, not even for a second. Prepare the new machine first, so your validators are offline only for the wait you choose (at least two epochs, about 13 minutes). A few missed attestations cost very little; a slashing costs far more.

Accept the downtime

Never start the new validator "just before" stopping the old one, and never run a failover copy. Most slashings happen exactly this way. See Avoid slashing.

Operating system
Service manager

The commands below use the users and paths from Run with systemd.

Before you begin​

  • The new machine meets the system requirements and has Prysm and an execution client installed.
  • Access to the keys on the old machine, or the original keystores and their password.
    • Your validator indices or public keys so that you can check them on a block explorer.

Move your validators​

  1. Sync the new node while the old one keeps validating. Start the execution client and beacon node on the new machine with checkpoint sync, without a validator client and without keys. Wait until Is my node healthy? shows it synced.

  2. Stop and disable the old validator, so nothing restarts it:

    sudo systemctl disable --now validator

    The old beacon node can keep running; it holds no keys.

  3. Check that the old validator is really off. Don't continue until all of these pass:

    • No process runs: this prints nothing:

      pgrep -af 'validator|prysm'
    • Nothing will restart it: this prints disabled:

      systemctl is-enabled validator

      No cron job or script starts it either.

    • If in doubt, unplug it. A machine you can't reach is a machine you can't prove is off.
  4. Export slashing protection from the old machine, now that it has stopped signing:

    sudo install -d -m 0700 -o validator -g validator /var/lib/ethereum/validator/export
    sudo -u validator /usr/local/bin/validator slashing-protection-history export \
    --datadir=/var/lib/ethereum/validator \
    --slashing-protection-export-dir=/var/lib/ethereum/validator/export

    This writes /var/lib/ethereum/validator/export/slashing_protection.json.

  5. Export the keys, then delete them from the old wallet. Use the original keystores, or export them to backup.zip in the export directory:

    sudo -u validator /usr/local/bin/validator accounts backup \
    --wallet-dir=/var/lib/ethereum/validator/wallet \
    --wallet-password-file=/var/lib/ethereum/validator/wallet-password.txt \
    --backup-dir=/var/lib/ethereum/validator/export

    sudo -u validator /usr/local/bin/validator accounts delete \
    --wallet-dir=/var/lib/ethereum/validator/wallet \
    --wallet-password-file=/var/lib/ethereum/validator/wallet-password.txt

    Select the keys you are moving. Afterward, this must not show them:

    sudo -u validator /usr/local/bin/validator accounts list \
    --wallet-dir=/var/lib/ethereum/validator/wallet \
    --wallet-password-file=/var/lib/ethereum/validator/wallet-password.txt

    Also delete the original keystore files from the old machine, and any VM snapshots or images that contain the keys: restoring one later would bring the validator back.

  6. Copy the files to the new machine over an encrypted channel (scp, an encrypted USB drive): slashing_protection.json, and the keystores or backup.zip. Unzip backup.zip into a folder of its own on the new machine. Delete any intermediate copies.

  7. Wait at least two epochs (about 13 minutes) after the old validator stopped. Then look up your validators on a block explorer: the latest epochs must show missed attestations. If they show attestations after you stopped the old validator, something is still signing. Stop and find it.

  8. Import slashing protection, then the keys, on the new machine with its validator stopped. <PATH_TO_KEYSTORES> is the folder holding the keystore-*.json files:

    sudo install -d -m 0700 -o validator -g validator /var/lib/ethereum/validator/import
    sudo cp <PATH_TO>/slashing_protection.json /var/lib/ethereum/validator/import/
    sudo cp -r <PATH_TO_KEYSTORES> /var/lib/ethereum/validator/import/keys
    sudo chown -R validator:validator /var/lib/ethereum/validator/import

    sudo -u validator /usr/local/bin/validator slashing-protection-history import \
    --datadir=/var/lib/ethereum/validator \
    --slashing-protection-json-file=/var/lib/ethereum/validator/import/slashing_protection.json

    sudo -u validator /usr/local/bin/validator accounts import \
    --keys-dir=/var/lib/ethereum/validator/import/keys \
    --wallet-dir=/var/lib/ethereum/validator/wallet \
    --wallet-password-file=/var/lib/ethereum/validator/wallet-password.txt

    sudo rm -r /var/lib/ethereum/validator/import
  9. Start the new validator:

    sudo systemctl enable --now validator

    The unit from Run with systemd already has your fee recipient, MEV-Boost settings and --enable-doppelganger.

    With doppelganger protection, before its first duty, the validator client asks the beacon node whether your keys attested in about the last two epochs. If they did, and its own slashing protection history shows no recent attestation for them, someone else signed: it exits instead of starting. It checks only once, so it's a last line of defense, not a replacement for step 7.

Check that it works​

  • The new validator logs this for each key:

    Validator activated

    Then:

    Submitted new attestations
  • With doppelganger protection, it first logs:

    Doppelganger check done

    If it exits with this instead, your keys are still active somewhere. Don't restart it: go back to step 3.

    Duplicate instances exists in the network for validator keys
  • A block explorer shows attestations again a few epochs after you started.

Follow the logs with:

sudo journalctl -fu validator

If the old machine is gone​

If it died and you can't export slashing protection: make sure it can never come back online with the keys (wipe or destroy the disk), wait until a block explorer shows several epochs of missed attestations, then import the keys on the new machine without slashing protection.