Ethereum Staker Migration Guide — Migrating from Prysm to Nimbus

***** WARNING — This guide is not Merge Ready. Please do not use until it has been updated. Check my Merge-Ready guides here. *****

This is a step-by-step guide to migrate from the majority client, Prysm, to the minority client, Nimbus. This guide is part of a series of migration guides — see the introductory article here for more information.

Acknowledgements

Thanks go to the Prysm and Nimbus teams for their excellent work and for taking the time to review this guide. Thanks also go to the Ethereum Foundation for funding this work, and Danny Ryan for the original concept. Finally, thanks to all the staking enthusiasts who provide feedback, corrections, support, and donations.

Disclaimer

This article (the guide) is for informational purposes only and does not constitute professional advice. The author does not guarantee accuracy of the information in this article and the author is not responsible for any damages or losses incurred by following this article. A full disclaimer can be found at the bottom of this page — please read before continuing.

Assumptions

It is assumed you have followed the Guide to Staking on Ethereum 2.0 (Ubuntu/Prysm) to create your existing Prysm staking setup.

NOTE: If you have not used my guide to set up your Prysm validator DO NOT follow this guide. It is only intended to support those setups.

It is also assumed that you have sufficient free disk space on your Ubuntu server to perform the migration, currently around 50GB of free space.

To check how much space is available on your Ubuntu server use the following command.

$ df -h

Depending on where you store your data, the larger mount will be the one to look for. In this example there is 110GB of free space on the root mount (/).

If you don’t have sufficient disk space you can still perform the migration by simply deleting the Prysm data after syncing the Nimbus beacon chain, but it carries some risk if a roll-back is necessary.

In general, disk space is an important consideration for long-term staking. The longer you stake the more storage will be required. It may be possible to prune (or auto-prune) both the Execution Layer (Geth, etc.) and Consensus Layer clients (Prysm, Nimbus, etc.), but disk space requirements will continue to grow over time as the chain grows larger.

Support

For technical support please reach out to:

• The EthStaker community on Reddit or Discord. Knowledgeable and friendly community passionate about staking on Ethereum 2.0.
• The Nimbus client team Discord.

Overview

To migrate from Prysm to Nimbus the conceptual flow is:

• Gather (or regenerate) the validator keystore-m...json files
• Install the Nimbus client and fully sync the Nimbus beacon chain
• Stop and disable the Prysm services
• Export the Prysm validator slashing protection database
• Import the slashing protection database and staking validator keys into the Nimbus client
• Start the Nimbus client and confirm validation duties are active
• Delete the Prysm services, software, and data

Findings post migration are shared in the Client Analysis and Closing Remarks sections below.

Let’s get started!

***** WARNING — This guide is not Merge Ready. Please do not use until it has been updated. Check my Merge-Ready guides here. *****

Gather Staking Data

Before migrating it is necessary to gather the staking data file(s) that contain the validator keys. These are files named keystore-m...json. There should be one file for each validator you are running.

In the Guide to Staking on Ethereum 2.0 (Ubuntu/Prysm), it was recommended to place the keystore-m...json file(s) here: $HOME/eth2deposit-cli/validator_keys on your Ubuntu server. Check for them using these commands:

$ cd $HOME/eth2deposit-cli/validator_keys
$ ls

If the files are there continue on. If not, and you have them backed up elsewhere, copy them over to the Ubuntu server and place them into the $HOME/eth2deposit-cli/validator_keys location. You can do this using a USB drive (if your Ubuntu server is local), or via secure FTP (SFTP).

NOTE: If you no longer have access to your keystore-m...json files, see Appendix B —Regenerate Staking Data to recreate them before continuing on.

Migrate from Prysm to Nimbus

***** WARNING — This guide is not Merge Ready. Please do not use until it has been updated. Check my Merge-Ready guides here. *****

As part of the migration, the following sections include a set of instructions to install and configure the Nimbus client based on (but not the same as) the original Nimbus staking guide.

NOTE: It is important that you follow the steps here and not the original Nimbus guide as there are some critical differences. You are also encouraged to read through this guide without taking any action first, to familiarize yourself with the end-to-end process.

Summary

First install and sync the Nimbus beacon chain. Once the sync is complete disable the Prysm services, export the slashing protection database, import it into the Nimbus client as well as the validator keys, and restart the Nimbus client to begin validating. The final steps are to remove the Prysm installation. There are also instructions included to roll-back if things don’t go well.

Step 1 — Prepare the Migration

Add a firewall rule for the Nimbus client. Allows P2P connections with Nimbus peers for actions on the beacon node (port 9000).

NOTE: If you are hosting your Ubuntu instance locally your internet router may need to be configured to allow incoming traffic on port 9000 as well.

$ sudo ufw allow 9000
$ sudo ufw status

Check the screen shot below for reference. We will close the Prysm related ports during the clean up at the end.

Download Nimbus. Go here and identify the latest release. Be sure to get the release labelled “Latest”.

Copy the URL to the Linux amd64 file in the Assets section. Download the file to your server.

$ cd ~
$ sudo apt install curl
$ curl -LO https://github.com/status-im/nimbus-eth2/releases/download/v22.4.0/nimbus-eth2_Linux_amd64_22.4.0_039bece9.tar.gz

Extract the binary from the archive and copy to the /usr/local/bin directory.

$ tar xvf nimbus-eth2_Linux_amd64_22.4.0_039bece9.tar.gz
$ cd nimbus-eth2_Linux_amd64_22.4.0_039bece9
$ sudo cp build/nimbus_beacon_node /usr/local/bin

Clean up the downloaded and extracted files.

$ cd ~
$ sudo rm nimbus-eth2_Linux_amd64_22.4.0_039bece9.tar.gz
$ sudo rm -r nimbus-eth2_Linux_amd64_22.4.0_039bece9

Step 2 — Sync the Nimbus Beacon Chain

The Nimbus beacon chain will need to be synced against the current mainnet beacon chain state. This can take days, but we can speed it up using the Checkpoint Sync feature.

Create the data directory for Nimbus.

$ sudo mkdir -p /var/lib/nimbus

Apply read/write/execute permissions on the Nimbus data directory. This is enforced by the Nimbus Checkpoint Sync and wallet creation processes.

$ sudo chmod 700 /var/lib/nimbus

Manually run the Nimbus beacon chain with the Checkpoint Sync configuration.

NOTE: Contrary to the original Nimbus setup guide we are NOT importing the validator files yet. We will sync the beacon chain first and then import the files after we disable the Prysm client. DO NOT import the validator files otherwise you will be at risk of a slashing penalty.

You have two choices here. You can either use your Prysm beacon chain as the trusted source, or you can use a free Infura ETH2 endpoint.

• If you use the Prysm beacon chain some configuration changes and a Prysm client restart may be necessary. You should have sufficient free space (>50GB) to run both beacon chains side-by-side.
• If you use the Infura ETH2 endpoint, or you have insufficient disk space for the Prysm option, you will need to create an account on Infura and then create an ETH2 project.

The two methods are detailed below.

NOTE: You only need to choose ONE of the two methods below, either Prysm beacon chain, or Infura ETH2 endpoint. Fair warning: I had trouble getting the Prysm Beacon Chain Method working due to a serialization error during the operation. It is a known issue, and will be resolved in a future release.

Prysm Beacon Chain Method

If you’d prefer to use the Prysm beacon chain to do the Checkpoint Sync then follow the instructions below.

Edit the Prysm beacon chain config.

$ sudo nano /etc/systemd/system/prysmbeacon.service

Add the following flags at the end of the ExecStart line.

--enable-debug-rpc-endpoints --grpc-max-msg-size=65568081

--enable-debug-rpc-endpoints enables the beacon node debug APIs needed to access BeaconState.

--grpc-max-msg-size=65568081 allows a buffer of more than the default max message size which provides sufficient overhead for current mainnet state sizes.

The full config should look something like this:

[Unit]
Description=Prysm Eth2 Client Beacon Node
Wants=network-online.target
After=network-online.target
[Service]
User=prysmbeacon
Group=prysmbeacon
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/beacon-chain --datadir=/var/lib/prysm/beacon --http-web3provider=http://127.0.0.1:8545 --accept-terms-of-use --enable-debug-rpc-endpoints --grpc-max-msg-size=65568081
[Install]
WantedBy=multi-user.target

Press CTRL+x then ‘y’ then <enter> to save and exit.

Restart the service and check to make sure it’s running correctly.

$ sudo systemctl daemon-reload
$ sudo systemctl restart prysmbeacon
$ sudo systemctl status prysmbeacon

If you did everything right, it should say active (running) in green text. If not then go back and repeat the steps to fix the problem. Press Q to quit (will not affect the Prysm service).

Finally, run the Trusted Node Sync using the Prysm beacon chain as the trusted node source.

$ cd /usr/local/bin
$ sudo nimbus_beacon_node trustedNodeSync --network=mainnet --data-dir=/var/lib/nimbus --trusted-node-url=http://localhost:3500

The --trusted-node-url flag is the default hostname and port for a locally installed Prysm beacon chain client. If you are connecting to a remote Prysm beacon chain or if you changed the default port, update the value accordingly.

Wait for the sync to complete before continuing.

Infura ETH2 Endpoint Method

If you’d prefer to use an Infura ETH2 endpoint to do the Checkpoint Sync then follow the instructions below.

Create a free Infura ETH2 project and use the https mainnet endpoint as the value for trustedNodeURL. To execute the Checkpoint Sync use the following commands.

$ cd /usr/local/bin
$ sudo nimbus_beacon_node trustedNodeSync --network=mainnet --data-dir=/var/lib/nimbus --trusted-node-url=InfuraProjectUrl --backfill=false

Replace InfuraProjectUrl with the mainnet https value from your Infrua ETH2 project, which you can get in project settings. For example:

$ sudo nimbus_beacon_node trustedNodeSync --network=mainnet --data-dir=/var/lib/nimbus --trusted-node-url=https://272GSCR2NRpg5n55qsSc4y5sMD8:4c9e4d691e34ge523456bb29f3e0332f@eth2-beacon-mainnet.infura.io --backfill=false

The flag --backfill=false prevents the Infura project from being inundated with requests causing your daily request quota to be exceeded. The backfill operation will automatically run once we start up the Nimbus client.

Wait for the sync to complete before continuing.

Screenshot below shows the output after a successful sync.

Step 3 — Configure the Nimbus Service

In this step you will configure and run Nimbus as a service so if the system restarts the process will automatically start back up again.

Create an account for the Nimbus client to run under.

$ sudo useradd --no-create-home --shell /bin/false nimbus

Set permissions so the nimbus account can access the data directory.

$ sudo chown -R nimbus:nimbus /var/lib/nimbus

Create a systemd service config file to configure the service.

$ sudo nano /etc/systemd/system/nimbus.service

Paste the following into the file.

[Unit]
Description=Nimbus Eth2 Client
Wants=network-online.target
After=network-online.target
[Service]
User=nimbus
Group=nimbus
Type=simple
Restart=always
RestartSec=5
WorkingDirectory=/var/lib/nimbus
Environment="ClientIP=$(curl -s v4.ident.me)"
ExecStart=/bin/bash -c '/usr/local/bin/nimbus_beacon_node --network=mainnet --data-dir=/var/lib/nimbus --web3-url=ws://127.0.0.1:8546 --nat=extip:${ClientIP} --graffiti="<yourgraffiti>" --log-level=INFO --log-file=/var/lib/nimbus/beacon_node.log'
[Install]
WantedBy=multi-user.target

Notable flags:

--web3-url Change the value if you are using a remote or third party Eth1 node. If you created the Eth1 node locally using GETH, no change is required.

--graffiti Change the value of <yourgraffiti> to something else of your choice. For privacy and security, avoid using personally identifiable data.

NOTE: The Nimbus client has a feature called Doppelganger Protection. This feature listens for 2 epochs when Nimbus starts up to ensure a validator with the same index is not attesting, thereby avoiding a slashing penalty. If you would like to disable this feature (not recommended), add the --doppelganger-detection=false flag to the end of the ExecStart line, before the last '.

Check the screen shot below for reference. Press CTRL+x then ‘y’ then <enter> to save and exit.

Reload systemd to reflect the changes.

$ sudo systemctl daemon-reload

Start the service and check to make sure it’s running correctly.

$ sudo systemctl start nimbus
$ sudo systemctl status nimbus

Check the screen shot below for reference.

If you did everything right, it should say active (running) in green text. If not then go back and repeat the steps to fix the problem. Press Q to quit (will not affect the nimbus service).

Enable the service to automatically start on reboot.

$ sudo systemctl enable nimbus

Now wait for the Nimbus beacon chain to sync. Since we did the Checkpoint Sync earlier this shouldn’t take long. You can check the progress by comparing the log output to the current chain data. Use the following command to inspect the Nimbus beacon chain log.

$ sudo journalctl -fu nimbus.service

Watch for Slot start messages as described here. Compare them to the current slot on the beacon chain here. When they match they are in sync. There is also a progress indicator in the log output:

slot=3461864 epoch=108183 sync="21h14m (0.03%)

NOTE: In order to avoid downtime penalties, it is recommended you wait for the Nimbus beacon chain to fully sync before you continue.

Step 4 — Migrate the Client

***** WARNING — This guide is not Merge Ready. Please do not use until it has been updated. Check my Merge-Ready guides here. *****

Once the Nimbus beacon chain is in sync we are ready to do the migration. The first steps involve disabling the Prysm services.

Stop the Prysm validator service and disable it. Check the status output for Active: inactive (dead) to confirm. This is critical to avoid a slashing penalty.

$ sudo systemctl stop prysmvalidator
$ sudo systemctl disable prysmvalidator.service
$ sudo systemctl status prysmvalidator

Stop the Prysm beacon chain service and disable it. Check the status output for Active: inactive (dead) to confirm.

$ sudo systemctl stop prysmbeacon
$ sudo systemctl disable prysmbeacon.service
$ sudo systemctl status prysmbeacon

Make a note of the approximate time the services were stopped. We will use this later to ensure we are safe from a slashing penalty.

NOTE: At this point we are no longer validating and therefore subject to minor inactivity penalties. Don’t be tempted to rush the rest of this section. Follow each step carefully.

Stop the Nimbus beacon chain and confirm it is no longer running so we can make the necessary changes.

$ sudo systemctl stop nimbus
$ sudo systemctl status nimbus

The current logged in user needs access to the Nimbus and Prysm directories to perform the setup actions. Change <yourusername> to the logged in username.

$ sudo chown -R <yourusername>:<yourusername> /var/lib/prysm
$ sudo chown -R <yourusername>:<yourusername> /var/lib/nimbus

Export the Slashing Protection Database from Prysm. This contains a history of completed attestations which Nimbus can use to ensure it doesn’t attest in the same place, which would be a slashable offence. A slashing-protection.json file will be created in the export directory.

$ cd /usr/local/bin
$ validator slashing-protection-history export --datadir=/var/lib/prysm/validator --slashing-protection-export-dir=/var/lib/prysm

Check the screen shot below for reference.

Import the Prysm Slashing Protection Database file into the Nimbus client.

$ sudo nimbus_beacon_node slashingdb import /var/lib/prysm/slashing_protection.json

Check the screen shot below for reference.

Run the validator key import process. You will need to provide the directory where the generated keystore-m...json files are located. E.g. $HOME/eth2deposit-cli/validator_keys.

$ cd /usr/local/bin
$ nimbus_beacon_node deposits import --data-dir=/var/lib/nimbus $HOME/eth2deposit-cli/validator_keys

You will be asked to provide the password for the validator keys. This is the password you set when you created the keys.

NOTE: If you don’t know the password, you will need to generate the keys again using your seed mnemonic. Go to Appendix B — Regenerate Staking Data to do that and return here when done. You will need to rerun the import function above with the newly generated files.

Check the screen shot below for reference.

The import is complete and the wallet is now set up.

Restore directory permissions. The nimbus account needs permission to modify the data directory (/var/lib/nimbus).

$ sudo chown -R nimbus:nimbus /var/lib/nimbus
$ ls -dl /var/lib/nimbus

At this point we have:

• Created the Nimbus service and synced the Nimbus beacon chain
• Disabled the Prysm services
• Exported/imported the Prysm Slashing Protection Database
• Imported the validator keys into the Nimbus client

Next we will start up the Nimbus client and resume validation duties.

NOTE: To be absolutely safe, delay the start up for at least 15 minutes from the time the Prysm services were stopped.

Start the Nimbus service and check to make sure it’s running correctly.

$ sudo systemctl start nimbus
$ sudo systemctl status nimbus

Check the screen shot below for reference.

If you did everything right, it should say active (running) in green text. If not then go back and repeat the steps to fix the problem. Press Q to quit (will not affect the nimbus service).

The Nimbus validator will automatically start processing once the beacon chain has synced up again.

NOTE: Due to the Doppelganger Protection Nimbus listens for 2 epochs without attesting. That will delay the time it takes to see a successful attestation after starting up the client.

Check the Nimbus log to confirm.

$ sudo journalctl -fu nimbus.service

The messages in the log should go from:

...Syncing in progress; skipping validator duties for now...
...Doppelganger detection active - skipping validator duties while observing activity on the network...

to

...Attestation sent...

You can check the status of your validator(s) via beaconcha.in. Simply search for your validator public key(s) / index(es) or search using your MetaMask (or other) wallet address. It may be a while before the data appears on the site. The migration may typically require at least 4 missed attestations, but once the validation starts up it will show normal behavior.

That’s it! You’ve successfully migrated to the Nimbus client!

If you use any monitoring solutions you may need to adjust them for Nimbus.

NOTE: If something goes immediately wrong, or after waiting a while (at least 30 mins) the Nimbus client is not attesting correctly, you can roll back to the Prysm client. See Appendix A — Emergency Rollback.

Step 5— Post Migration Clean Up

Now that your Nimbus client is successfully validating we can clean up the Prysm client and data.

NOTE: Do not do this step until you are sure your Nimbus client is working properly. If it is not, you will need the original Prysm software/data to roll back. See Appendix A — Emergency Rollback.

Delete the Prysm binary files.

$ cd /usr/local/bin
$ sudo rm beacon-chain && sudo rm validator

Delete Prysm config and data directory.

$ cd ~
$ sudo rm /etc/systemd/system/prysmbeacon.service
$ sudo rm /etc/systemd/system/prysmvalidator.service
$ sudo rm -r /var/lib/prysm

Remove the Prysm firewall ports. Remove these from your internet router configuration as well, if you set them up there.

$ sudo ufw delete allow 13000/tcp
$ sudo ufw delete allow 12000/udp

Remove the Prysm user accounts.

$ sudo deluser prysmbeacon
$ sudo deluser prysmvalidator

That should be everything. Congratulations, and happy staking!

Client Analysis

Having run both Prysm and Nimbus clients, the following remarks and data comparisons are a window into my experience. All opinions shared here are the author’s and are not representative of any other individual or organization.

In the context of these guides, the Nimbus client is a simpler setup than Prysm. The main reason for this is a single binary file is required. A single file means a single system user, systemd service, and service configuration. By contrast, Prysm uses separate binaries for the validator and the beacon chain. There are some other meaningful differences that I explore in the Closing Remarks section below.

The client footprint meaningfully differs between Prysm and Nimbus. Using the client configuration specified in my Prysm and Nimbus guides, the following charts show a comparison between the two clients running over a 7 day period. Each client had exclusive use of the server during the 7 days, and all required syncs had been completed prior to the recorded 7 day period.

Server Specs

• Ubuntu 20.04 LTS
• Intel(R) Xeon(R) CPU E5–2650 v4 @ 2.20GHz
• 160GB SSD
• 8GB RAM

CPU

CPU usage for Prysm and Nimbus is shown below.

Prysm 7 Day CPU Usage

Nimbus 7 Day CPU Usage

Nimbus was consistently lower in CPU usage over the period. Perhaps due in part to the single binary implementation (one service running vs. two for Prysm). Nimbus is also generally considered to be the ‘lighter’ client of the available set. Prysm’s CPU usage is also far more spiky.

The cause of the spike during 4/19 on the Nimbus chart is unknown.

Load

Load (1 min, 5 min, 15 min) for Prysm and Nimbus is shown below. Light purple is 1 min, blue is 5 min, dark purple is 15 min.

Prysm 7 Day Load

Nimbus 7 Day Load

Prysm’s average sits between 05. and 1.0. Nimbus by comparison, is fairly consistently between 0.4 and 0.5, meaning that given the same hardware, Nimbus requires fewer resources. Both are well within the range of tolerable by the server however, which has 4 virtual CPU cores and therefore, in theory, could easily handle a sustained load slightly below 4.0.

Memory

Memory usage for Prysm and Nimbus is shown below.

Prysm 7 Day Memory Usage

Nimbus 7 Day Memory Usage

This one looks clear cut — Nimbus requires significantly less, around 4x less memory than Prysm. Recall the server has 8GB RAM. However, it’s possible that memory usage here doesn’t accurately indicate actual usage. Also we see an increase in usage over time with both clients, Nimbus having the greater increase.

After discussion with the Nimbus team, they let me know it is expected behavior for the Nimbus client to increase in memory usage over time due to the memory allocator strategy of the Nim language. Eventually usage will reach a high point and remain there.

And, after discussion with the Prysm team, they let me know that the Go runtime doesn’t reclaim freed memory unless the OS needs it. Because of this, Prysm might give a higher than expected value for memory usage if it’s not required elsewhere.

Disk I/O

Disk I/O for Prysm and Nimbus is shown below. Green line is read and yellow line is write.

Prysm 7 Day Disk I/O

Nimbus 7 Day Disk I/O

There is a clear winner here. Nimbus has a significantly lower volume of data written to disk over the 7 days. This could be due to efficiency in the format of the data being transacted, but that is just a guess.

Disk Usage

Disk usage for Prysm and Nimbus is shown below.

Prysm 7 Day Disk Usage

Nimbus 7 Day Disk Usage

This follows on from the previous section. A lower Disk I/O over a fixed period of time for Nimbus translates into fewer data on disk. As disk usage requirements continue to increase, this could be a meaningful difference to stakers.

Bandwidth

Network bandwidth for Prysm and Nimbus is shown below. Yellow line is inbound data, orange line is outbound data.

Prysm 7 Day Bandwidth Usage

Nimbus 7 Day Bandwidth Usage

This one is interesting. Both Prysm and Nimbus have around 1.5 Mb/s outbound data. However Nimbus has significantly more inbound data. I’m not sure what the reason for this is. Given Nimbus’s smaller disk footprint, it is clearly not storing the data, so it may be operational data held in memory and then discarded, but that’s just a guess. In terms of cost of use, Nimbus requires a greater amount of network bandwidth overall. I reached out to the Nimbus team about this and they are investigating.

Closing Remarks

Overall the migration from Prysm to Nimbus was reasonably straightforward. Some personal remarks about my experience migrating are below.

The Checkpoint Sync option offered by Nimbus allowed the use of either the Prysm beacon chain or an Infura ETH2 project to fast-track the Nimbus beacon chain sync. I had trouble getting the sync to work with the Prysm source. I kept getting a serialization error due to a known issue to be resolved in a future release. The Infura approach worked just fine. This feature probably saved a day or two of syncing time.

Exporting / importing the slashing protection data made me feel safer, but not safe enough to forego waiting for 15 mins before starting up the Nimbus validator. If the EF provides me with a ‘disposable’ validator I’m happy to give it a try!

The doppelganger protection baked into Nimbus is a neat feature, and shows consideration by the team for helping stakers avoid being slashed.

It felt good to move from two systemd services to one. It felt less risky and easier to manage. Client updates will now be easier as well.

I found the documentation and discord support for Prysm was far greater in volume and availability, but I had no problem finding information and support for my Nimbus related questions.

I don’t use Prometheus/Grafana to monitor my clients so I can’t speak to the quality and availability of the metrics and pre-configured dashboards between the two clients. For those who are wondering, I use beaconcha.in’s mobile application to monitor the performance of my validator.

It’s clear that Nimbus is a lighter client overall. The data shows that, but it also felt lighter, too. It was fast to start and stop the client. The journal output is clear and well formed and the information therein is succinct.

During the past 7 days, I had zero missed attestations and zero proposals (not too surprising). The optimal inclusion distance was consistently 0 and I had no blips, alerts, or errors arise. The same was true for the Prysm client, in the 7 days prior to migrating to Nimbus. The client teams really do an excellent job.

So far in the limited time I have been using it, Nimbus has been excellent and it absolutely feels like a viable alternative to Prysm for a staking consensus client.

Thanks for the opportunity. Hopefully this guide was helpful for you.

Appendix A — Emergency Rollback

If the migration fails for any reason, one quick way to roll back the changes with minimal downtime is to revert back to the Prysm client, assuming you haven’t already removed it.

NOTE: This is step is only to be used if there are obvious errors or issues with the Nimbus client setup. It can take up to 30 mins for the Nimbus validator to reflect successful attestations in the journal or on Beaconcha.in. If there are no other issues beyond the validator not starting up, give it some time first, before deciding to roll back.

The steps involved are to fully disable and remove the Nimbus client and then restart the Prysm client.

Stop the Nimbus service and disable it. Check the status output for Active: inactive (dead) to confirm.

$ sudo systemctl stop nimbus
$ sudo systemctl disable nimbus.service
$ sudo systemctl status nimbus

Delete Nimbus binary, config, and data directory.

$ sudo rm /usr/local/bin/nimbus_beacon_node
$ sudo rm /etc/systemd/system/nimbus.service
$ sudo rm -r /var/lib/nimbus

Delete Nimbus firewall config and confirm. Remove this from your internet router configuration as well, if you set it up there.

$ sudo ufw deny 9000
$ sudo ufw status

Delete the Nimbus user.

$ sudo deluser nimbus

Reapply the Prysm directory permissions.

$ sudo chown -R prysmbeacon:prysmbeacon /var/lib/prysm/beacon
$ sudo chmod 700 /var/lib/prysm/beacon
$ sudo chown -R prysmvalidator:prysmvalidator /var/lib/prysm/validator
$ sudo chmod 700 /var/lib/prysm/validator

Reenable the Prysm services.

$ sudo systemctl enable prysmbeacon.service
$ sudo systemctl daemon-reload
$ sudo systemctl start prysmbeacon
$ sudo systemctl status prysmbeacon
$ sudo systemctl enable prysmvalidator.service
$ sudo systemctl daemon-reload
$ sudo systemctl start prysmvalidator
$ sudo systemctl status prysmvalidator

Monitor the Prysm services.

$ sudo journalctl -fu prysmbeacon.service
$ sudo journalctl -fu prysmvalidator.service

You should now be back to where you started.

Appendix B — Regenerate Staking Data

If you don’t have a backup of your staking data (keystore-m...json) files and they are not on your Ubuntu server, you can generate them again.

Go here to get the “Latest release” of the deposit command line interface (CLI) app.

Transfer the binary to a USB stick and copy to an air-gapped machine for safety (recommended), or if not available, copy to a machine that is not connected to the net (not recommended).

When ready, run the file in a terminal window (or CMD in Windows) to continue using the commands below.

The existing-mnemonic command is used to re-generate the staking data from your existing mnemonic. You will need to supply your mnemonic phrase to do this, hence the security requirements.

On Linux/Mac:

./deposit existing-mnemonic --validator_start_index <ValidatorStartIndex> --num_validators <NumberOfValidators> --chain mainnet

On Windows:

deposit.exe existing-mnemonic --validator_start_index <ValidatorStartIndex> --num_validators <NumberOfValidators> --chain mainnet

Replace <ValidatorStartIndex> with the start index of the validator you would like to generate keystore-m...json file for. For example: If you have 2 existing validators (#0, #1) and you want to generate keystore-m...json files for each, you would run each command separately as follows.

On Linux/Mac:

./deposit existing-mnemonic --validator_start_index 0 --num_validators 1 --chain mainnet
./deposit existing-mnemonic --validator_start_index 1 --num_validators 1 --chain mainnet

On Windows:

deposit.exe existing-mnemonic --validator_start_index 0 --num_validators 1 --chain mainnet
deposit.exe existing-mnemonic --validator_start_index 1 --num_validators 1 --chain mainnet

Each time you will need to enter your mnemonic and a password for the generated keystore-m...json file. It is recommended you use the same password for each file, and keep a note of it for use when importing into the Nimbus client.

NOTE: The newly generated file will be different in name and contents to your original file with the exception of the validator public key.

Finally, if you generated the validator keystore-m...json file(s) on a machine other than your Ubuntu server you will need to copy the file(s) over to your home directory. You can do this using a USB drive (if your server is local), or via secure FTP (SFTP).

Place the files here: $HOME/eth2deposit-cli/validator_keys. Create the directories if necessary.

You can now continue with the guide from the section heading Migrate from Prysm to Nimbus.

Full Disclaimer

This article (the guide) is for informational purposes only and does not constitute professional advice. The author does not warrant or guarantee the accuracy, integrity, quality, completeness, currency, or validity of any information in this article. All information herein is provided “as is” without warranty of any kind and is subject to change at any time without notice. The author disclaims all express, implied, and statutory warranties of any kind, including warranties as to accuracy, timeliness, completeness, or fitness of the information in this article for any particular purpose. The author is not responsible for any direct, indirect, incidental, consequential or any other damages arising out of or in connection with the use of this article or in reliance on the information available on this article. This includes any personal injury, business interruption, loss of use, lost data, lost profits, or any other pecuniary loss, whether in an action of contract, negligence, or other misuse, even if the author has been informed of the possibility.