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 theExecStart
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.
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’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.
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.
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.
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.
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 mainnetdeposit.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.