Switch to a new client
This document provides guidance on moving from Prysm to a new consensus-layer client like Teku, Lighthouse, or Nimbus.
The following best practices will help minimize the risk of slashing while migrating between clients:
- Never run more than a single validator process with the same keys loaded
- Maintain and utilize slashing protection
- Accept downtime as part of a successful migration
#Step 1: Sync the beacon node
Regardless of which client you are switching to, the first step of the process will be to sync the beacon node. This may take some time to complete. Some clients offer a feature known as "checkpoint sync" which allows you to sync a node within a few minutes. Without this, the process may take several hours to a few days.
Installation documentation links for each client can be found below:
#Step 2: Stop and Disable Prysm
Ensuring you stop and disable Prysm is critical to avoiding slashing events before proceeding further.
Disabling Prysm prevents it from automatically starting up again after a reboot.
Remove Prysm's validator keys as an added protection by following these instructions above.
#Step 3: Export slashing protection history
Ensure that you stop Prysm before exporting slashing protection in order to capture all validator actions.
We have a section dedicated to exporting and importing slashing protection history here. Follow the steps regarding exporting slashing protection history.
#Step 4: Update port forwarding
This step is not required for nodes which are running on a virtual public cloud, but keep in mind - nodes will be required to run a an execution client locally post merge!
By default, Prysm uses TCP/13000 and UDP/12000. Remove those two rules and replace them with the appropriate port forwards for the client you are switching to. The process will be very similar to the steps laid out here.
Teku, Nimbus, and Lighthouse all use port 9000 for both TCP and UDP.
#Step 5: Import Validator Keys
To minimise slashing risk, wait until at least 1 full epoch has elapsed between stopping prysm and importing your validator keys, approximately 6.5 minutes, before proceeding. The inactivity leak cost is negligible compared to the cost of getting slashed.
Once that amount of time has passed, import your validator keys into the respective validator client you wish to run.
#Step 6: Import Slashing Protection History
Follow your new clients' instructions regarding importing slashing protection history.
#Step 7: Start the New Validator
Ensure your beacon node is fully synced with the network by checking your clients logs prior to starting your validator. Once it is fully synced, start the validator.
Search a block explorer like https://beaconcha.in/ with your validator's public key to confirm that your validator is now active!