Once your beacon node is running, the next step is to set up a validator.
Nimbus doesn't require setting up a separate validator client process — the beacon node can itself perform validator duties. This is a simple, safe and efficient way to get started.
Separate validator client
While not needed, advanced users may want to use a separate validator client instead.
To start validating, you need to do these three steps, explained in more detail below:
- Make a deposit for your validator.
- Import your validator keys into Nimbus.
- Start performing validator duties by restarting the node.
1. Make a deposit for your validator
To make a deposit, you will need to generate keys then submit a deposit transaction to the execution chain.
The process of setting up a validator is also documented at the Ethereum launchpad site:
Before running your validator on Mainnet, you can (and should) verify that your setup works as expected by running it on the Prater testnet.
1. Download the deposit tool
Start by downloading and unpacking the deposit tool provided by the Ethereum Foundation:
# Enter the nimbus folder cd nimbus-eth2 # Make sure to get the latest version from the download page wget https://github.com/ethereum/staking-deposit-cli/releases/download/v2.2.0/staking_deposit-cli-9ab0b05-linux-amd64.tar.gz # Unpack the archive tar xvf staking_deposit-cli-9ab0b05-linux-amd64.tar.gz --strip-components 2
2. Generate keys
You can increase the security of this process by downloading a Live Linux image. To do so, copy
deposit to a USB stick, boot into the live image, and run the tool from inside the image.
Make sure you don't enable Wi-Fi and unplug any Ethernet cables when using this process.
The deposit tool generates a seed phrase, and uses this to create validator and withdrawal keys.
If you lose you seed phrase and your withdrawal key, your funds will be lost forever!
3. Make the deposit
Once created, the keys are used to create a deposit transaction on the Ethereum execution chain. Follow the instructions here to upload the deposit data.
If you are making a mainnet deposit make sure you verify that the deposit contract you are interacting with is the correct one.
You should verify that the address is indeed: 0x00000000219ab540356cBB839Cbe05303d7705Fa
Once you send off your transaction(s), before your validator starts producing blocks and attestations, there are two waiting periods.
First, you wait for the beacon chain to recognize the block containing the deposit. This usually takes around 13 hours. Then, you wait in the queue for validator activation.
Getting through the queue may take a few hours or days (assuming the chain is finalizing).
No validators are accepted into the validator set while the chain isn't finalizing.
Pending Validators metric on the beaconcha.in will give you the size of the queue.
With the keys created, you're ready for the next step: importing your validator keys.
2. Import your validator keys
systemd service file users will want to follow the service file guide instead!
By finishing the first step, you will have a
validator_keys folder containing several
.json files in the
We'll import the signing key of each validator to the data directory using the
deposits import command:
You'll be asked to enter the password you used when creating your keystore(s).
On success, a message will be printed that your keys have been imported:
NOT is short for
NOTICE and not not :)
After importing keys, it is time to restart the node and check that the keys have been picked up by the beacon node.
All the keys
You can read more about the different types of keys here — the
deposits import command will import the signing key only.
validator_keys folder is stored elsewhere, you can pass its location to the import command:
/path/to/keys with the full pathname of where the
validator_keys directory is found.
Optimized import for a large number of validators
If you plan to use a large number of validators (e.g. more than 100) on a single beacon node or a validator client, you might benefit from running the
deposits import command with the option
This will force Nimbus to use the same password and random salt value when encrypting all of the imported keystores which will later enable it to load the large number of validator keys almost instantly.
The theoretical downside of using this approach is that it makes the brute-force cracking of all imported keystores computationally equivalent to cracking just one of them.
Nevertheless, the security parameters used by Ethereum are such that cracking even a single keystore is considered computationally infeasible with current hardware.
If you come across an error, make sure that:
- You are using the correct data directory.
systemdusers, look for the
--data-diroption in the
- You are running the command as the correct user.
systemdusers, look for the
User=option in the
.service. Assuming the user is called
nimbus, prefix all commands with:
sudo -u nimbus.
- Permissions for the data directory are wrong. See folder permissions for how to fix this.
3. Start validating
Once your keys have been imported, it is time to configure a fee recipient and restart the beacon node to start validating.
1. Choose a fee recipient
The fee recipient is an Ethereum address that receives transaction fees from the blocks that your validators produce. You can set up a separate address or reuse the address from which you funded your deposits.
2. (Re)start the node
Ctrl-c to stop the beacon node if it's running, then use the same command as before to run it again, this time adding the
--suggested-fee-recipient option in addition to
3. Check the logs
Your beacon node will launch and connect your validator to the beacon chain network.
To check that keys were imported correctly, look for
Local validator attached in the logs:
Congratulations! Your node is now ready to perform validator duties and earning a small amount of ETH every 6.4 minutes in return for keeping the Ethereum network secure! Depending on when the deposit was made, it may take a while before the first attestation is sent — this is normal.