Using Nethermind to Run a Validator in Eth2

Published in

Nethermind.eth

11 min readMay 25, 2020

Acknowledgements

When I first published this article in late May 2020, some early readers quickly pointed out some rather large errors that basically undermined the whole article. That sent me down a rabbit hole that got me in touch with numerous Eth2 client teams, led to me opening at least one GitHub issue and more. A bit more than a week later a large potion of the article has been revamped, and should work as intended. I wanted to take the time to thank MysticRyuujin and Butta.eth for their help, along with a big shoutout to the whole Lighthouse team. I spoke with at least three different members of the team over writing this article, and each one helped a ton. Thanks!

Introduction

In the Eth 2.0 paradigm, staking replaces mining. Staking involves locking up ether (currently 32 ETH) as a deposit, which confers the ability to be a ‘validator’, to validate new blocks which will then be added to the chain.

There are currently testnets designed to test and simulate the Eth 2.0 structure. Staking is accomplished by staking testnet Eth on the Goerli testnet. Most guides for getting set up on the Eth 2.0 testnets assume Geth as the client for staking ETH on Goerli. This is an exciting time. One of the goals of Eth 2.0 is to make validating accessible to anyone. This guide aims to explain how to use Nethermind to stake ETH on the Goerli testnet to facilitate becoming a validator.

This only things this guide assumes are a Linux-based operating system with Curl installed.

One word of warning before we get started: Eth2.0 is a constant state of flux. As such, the information here may not remain accurate. We’ll try to give resources which should reflect any change, and as with everything in crypto, don’t trust, verify.

Installing Nethermind

Nethermind client homepage: https://www.nethermind.io/client

Nethermind docs: https://nethermind.readthedocs.io/

To install Nethermind, go to the releases page, and download the latest version for your platform (though this guide will focus on Linux). Extract Nethermind from the zip:

unzip nethermind-linux-amd64–1.8.XX-XXXXXXX.zip -d nethermind

(The first XX is the version number. As of this writing 1.8.43 is the most recent. In the file name, this will be followed with a 7-character checksum, which is represented here by the following XXXXXXX. For 1.8.43, for example, the checksum is f28f4b7. Depending on where you download from, the date of upload may also be appended to the end of the filename. The only thing that really makes a difference is that you should download the most current stable release of Nethermind! Just having the most recent version oftentimes solves a number of technical issues.)

Keeping Nethermind Up-To-Date

The Eth2 space moves fast, and can potentially break things, too. Nethermind also moves at a quick clip, sometimes releasing a new version close to daily. I recommend checking and updating Nethermind as a part of a daily, or at least weekly, routine.

If you need to check which version of Nethrmind you’re running, go into the Nethermind directory, open up the CLI(./Nethermind.Cli), and type in

web3.clientVersion

which will output the version to the screen.

Check Nethermind’s releases page to see what the most recent release is. If there is a newer version available, update.

Updating is essentially the same as installing. Download the new package, and unzip it to the destination of your choice, overwriting the old Nethermind directory. I’ll copy over the command we used to unzip Nethermind from the Downloads folder, with the addition of a -o flag for overwriting:

unzip -o nethermind-linux-amd64–1.8.XX-XXXXXXX.zip-d nethermind

You should restart your node after updating so that the node is running the newer version of Nethermind.

Syncing Goerli

Inside the Nethermind directory, run Nethermind on the Goerli testnet:

./Nethermind.Runner --config goerli --JsonRpc.Enabled true

(Nethermind.Launcher provides additional options at startup, including asking which chain to sync with, and can be used alternatively. This guide whois solidity.devwill use Nethermind.Runner, which has the added advantage of being useful for automating this process by making a systemd script or the like.)

If you would like to use Nethermind in order to generate a wallet and an address on Goerli, you must also use another flag: --Init.EnableUnsecuredDevWallet true.

Goerli is a relatively new testnet, and Beam Sync is functional on Goerli, meaning that on a test run Goerli synced to the point state could be queried in under 15 minutes with a powerful CPU and RAM, and fully synced in about an hour. Slower machines may take longer.

The JsonRpc.Enabled flag is set to true in order to facilitate using Goerli faucets and sending the validator deposit. If there is nothing else broadcasting to port 8545 on your machine, this will allow Nethermind to broadcast on that port. Don’t forget to set the network in MetaMask to localhost:8545. (I don’t think this last step is necessary, but if you’re already running locally, there’s no reason to use Infura to query Goerli, which is what you’d be doing if you select Goerli from the dropdown menu.)

You’ll know you’ve finished syncing when Nethermind starts mentioning “Processed”. Here’s a screenshot of the output of a synced Nethermind Goerli node:

Lighthouse

Lighthouse is Sigma Prime’s Eth2 client. It’s written in Rust, so you should jump over to rustup.rs for an easy installation guide. Just a warning, installing Rust can take time and computer resources.

Once you have Rust up and running, the next step is to clone and build the Lighthouse repo. The build (the third step shown) can take some time; the last time I ran it, it took more than half an hour.

git clone https://github.com/sigp/lighthouse.git
cd lighthouse
cargo build — release

Lighthouse by default runs on Witti, a multi-client testnet. You’ll need to clone the Witti repo, so from whichever directory you’d like to copy it type:

git clone https://github.com/goerli/witti

The first step is connecting the Beacon Node client to Goerli and syncing the chain. The following assumes Witti was cloned to the home directory, otherwise substitute the proper path:

lighthouse bn –http –testnet-dir ~/witti/lighthouse –eth1-endpoint http://127.0.0.1:8545

Note: If just typing lighthouse doesn’t work for you (meaning you get an error likebash: lighthouse: command not found, you may need to instead use ~/lighthouse/target/release/lighthouse any time the lighthouse command is mentioned.

Beacon Chain node syncing with Lighthouse

If you still have Nethermind outputting to a terminal, you should be seeing a number of RPC requests coming over:

Nethermind Goerli node during Beacon Chain sync

We’ll use Lighthouse to create a wallet for staking. Create a password file in a place of your choosing, which contains a password of your choice. I’ll call it password.txt here, and assume it’s in the home directory, and leave it to you to fill out the input differently as necessary. I’m also calling the wallet witti because that’s what they did in the Witti Lighthouse readme, which this part of this guide is based on, but you can feel free to name it whatever you please. Similarly, the home directory is chosen as the destination of the generated mnemonic file. This is not security advice, and if it would be, it would probably not be very good advice. It simply makes my job writing this a bit easier, and I hope a bit clearer to read and extrapolate what you need to do from.

lighthouse account_manager wallet create \
--name “witti” \
--passphrase-file ~/password.txt \
--testnet-dir ~/witti/lighthouse \
--mnemonic-output-path ~/menmonic.txt

This should generate your wallet. You should see your 12-word mnemonic on the screen, along with some advice as to what to do with it. I’m not putting in a screenshot, as some of that advice is to never share your mnemonic.

Next, we’ll generate a validator account.

lighthouse account_manager validator create \
--at-most 1 \
--testnet-dir ~/witti/lighthouse \
--wallet-name “witti” \
--wallet-passphrase ~/password.txt

There should be an output with a long hex number.

Now we need to make a deposit for our validator. There are two primary ways to do this, either using MetaMask or using the Nethermind CLI.

From MetaMask: You’ll need to connect MetaMask to your node by pulling the dropdown menu for selecting which chain your on and choosing localhost:8545, (If you’re using a different port, you’ll need to pick ‘Custom RPC’ and put in the port number.) You could also select Goerli from the menu, but why use Infura’s Goerli node when you have one sitting on your computer?

You’ll need at least 32 GoETH (Goerli Ether, which is test ETH and not worth anything) to deposit in order to become a validator. If you have a Twitter or Facebook account, you can use https://faucet.goerli.mudit.blog faucet. Enter in your MetaMask address, and follow the directions. It may take a little time for you to receive the GoETH (and for your node to receive the information), but it should be there in less than a minute.

In a web browser go to Lighthouse’s documentation. Click on the ‘upload’ button. The file Lighthouse needs should be in ~/.lighthouse/validators/0x..., or in other words, in a hidden folder called .lighthouse (note the . at the beginning) in the home directory. (You can right-click in most file managers to get an option to see hidden files and folders.) You’re looking for a file called eth1-deposit-data.rlp. Uploading this should generate a MetaMask transaction to send 32 GoETH to the validator contract on Goerli.

From the command line: First, you’ll need to launch the Goerli node with an additional flag:

--Init.EnableUnsecuredDevWallet true

From the Nethermind directory, launch the CLI (./Nethermind.Cli). Typing pesonal.listAccounts should give you a list of test accounts. If it doesn’t, the rest of this will most likely also not work, and I would recommend going the MetaMask route above. If it does, create a new account, replacing password with whatever your heart desires.

personal.newAccount(“password”)

Take note of the new address which is output by running this, and fund it using the faucet at https://faucet.goerli.mudit.blog (assuming you have a Twitter or Facebook account). You’ll need at least 32 GoETH (Goerli test Ether, not worth anything) in order to stake. You’ll also need to unlock the account from inside the Nethermind CLI:

personal.unlockAccount({your address}, “{your password}”)

As of this writing Lighthouse still needs an IPC endpoint in order to make a deposit from the command line, though I’m told a PR is already in the works for accepting an http endpoint. The following makes an educated guess about how to form the deposit:

lighthouse account_manager validator deposit \
--eth1-http http:127.0.0.1:8545 \
--from-address {put your address here without the 0x} \
--testnet-dir ~/witti/lighthouse \
--validator all

The beacon node should have been syncing this whole time. You may start up the validator client while the beacon chain is syncing, but it won’t do anything until sync is achieved. I would recommend waiting. When the client is finished syncing the beacon chain, its output will change to something more like this:

You need to leave the beacon chain client running even once it has synced. In a new terminal, this is what you should use to fire up the validator client:

lighthouse vc –auto-register –testnet-dir ~/witti/lighthouse

These flags are only needed the first time you run the validator, and the --auto-register can even make problems if it’s used afterwards, so if you need to restart the validator, simply use:

lighthouse vc

And that should be it! If you’ve made it this far, congratulations! You are running Beacon Chain and Validator clients, and are the cutting edge of the Eth2 frontier.

Some Notes

As of this writing there is no queue for a validator to start validating on Witti. This means that soon after starting up the validator, you should see output like:

Once in a bit, instead of this output you’ll either give a block attestation or publish a new block. I haven’t caught my client publishing a new block yet, but this is what publishing an attestation looks like:

Lighthouse Validator node publishing an attestation

An attestation is like voting for a proposed block. Publishing a new block is actually proposing a new block to the chain, and is significantly more rare.

A node that is offline will be penalized, though as of this writing (June 2020) only at a rate that would drain a 32 GoETH deposit over a year. Going offline here and there (upgrading, updating, or other necessities) is therefore expected.

Getting stuck is to be somewhat expected. Your setup may not mirror mine, and this is very early-stage software on a maybe beta-level platform which is pioneering new territory. Don’t be scared to ask for help! Client teams usually have a Discord, and while they may be on the other side of the world from you, are generally happy to help, and happy to hear feedback. Don’t be shy!

Other Clients

Lighthouse is certainly not the only Eth 2.0 client. You can use Nethermind to sync Goerli in collaboration with any Eth 2.0 client. This guide only picked Lighthouse as an example. We’ll link to a few other clients below.

As a note, you can, to the best of my understanding, run multiple Eth 2.0 clients at the same time. You may have to play with some of the defaults, such as which port the client is using, and you’ll have to make sure that your computer has the resources. You would only need one Goerli node for all of them, though.

Teku

Official Teku documentation: https://docs.teku.pegasys.tech

Witti Teku documentation: https://github.com/goerli/witti/tree/master/teku

Teku is a client written in Java by PegaSys, a spoke of ConsenSys. Follow the instructions for installing Teku (and the Java SDK, if necessary). Teku’s documentation assumes the use of the Besu client for syncing with Goerli, which can be skipped.

I have not yet tried connecting Teku to Nethermind, but believe that it should be possible. You’ll need to be able to generate a wallet and address through Nethermind (to my understanding), so make sure to run Nethermind with the --Init.EnableUnsecuredDevWallet flag.

Lodestar

Lodestar installation guide: https://github.com/ChainSafe/lodestar

I have not tried connecting Lodestar to Nethermind yet, but am under the impression that it should be feasible. Look out for documentation on the Witti website, which prove useful in attempting to do so.

Prysm

Official Prysm testnet instructions: https://prylabs.net/participate

Witti (Schlesi) Prysm documentation: https://github.com/goerli/witti/tree/master/prysm/README.md

Prysm runs their own cluster of Goerli nodes, and connect the Prysm client to them by default. There are also currently technical issues as of this writing that do not allow for Prysm to be connected to a Nethermind Goerli node. It is still one of the most well known clients for Eth2, so I felt I would be remiss if I didn’t say anything about them