Open in app

Sign in

Write

Sign in

Setup Ethereum 2.0 Validator Node with Lighthouse on Meddala, Goerli

Ryan Golash
Coinmonks
14 min readAug 13, 2020

--

Recent days have seen a lot of upwards movement in cryptocurrency prices due to increased interest in Defi. Ethereum is also leading this charge. Ethereum recently launched its phase 0 by going live with its first eth2.0 multi-client medella testnet, supported with eth1 testnet Goerli. To know more about Ethereum 2.0 roadmap, read here.

The objective of this article is to cover detailed steps to set up Ethereum 2.0 Beacon Node and Validator on the Ethereum 2.0 Medalla multi-client testnet using Sigma Prime Lighthouse client. It is based on the following systems:

What is Lighthouse?

Lighthouse, backed up Sigma Prime, an information security and software engineering firm, is one among nine chosen teams building Eth2.0 client. It is written in Rust with a heavy focus on speed and security and has received funding from the Ethereum Foundation, ConsenSys, and Vitalik Buterin.

Please note

  • This setup is certainly not easy, and you need a fair understanding of advanced Linux operating systems like firewall, SSH, user accounts, configure Linux services.
  • You are also expected to know how to set up Ethereum 1.0 full-node and understand core tenets of Blockchain and Ethereum, e.g. mnemonic, private/public keys, account address, metamask wallet, solidity contracts, and transactions.
  • It will take many hours to complete this entire setup, so keep patience.

Steps

  • Set up an Ethereum1.0 test node of Goerli testnet on our server and let it synch with testnet latest block
  • Install and configure the Lighthouse Beacon Node
  • The deposit contract
  • Generate and activate validator keys
  • Configure the Lighthouse Validator Client

Step 0 — Preparation

I have used one of the commodity server hosted on Digital Ocean. Technically, this setup can be done on Raspberry pi 4 as well. If the machine is supported by private/public subnet with VPC on AWS, the server security group needs to be set up with the following ports. However, for this setup, you need to do it using Linux firewall service ufw.

Update and upgrade the system

Security

By default, ufw is disabled, so before enabling it, you need to open

  • Port 22 for SSH connection,
  • Port 30303 TCP/UDP for Geth node to interact with its peer nodes,
  • Ports 9000/TCP and 9000/UDP to allow Lighthouse for P2P connections with peers for actions on the beacon node

Run the following ufw commands

The output should look like this.

Step 1 — Install and Run Go Ethereum Node

Install Go Ethereum

Since you have multiple systems to run in this server and all systems should run interruptedly, you need to set up these systems as Linux services. Any interruptions can lead to penality and slashing in the stake. Read here.

Run Go Ethereum as a Background Service

  • Create a no-home account goerli for the service to run under. You can’t log into the server using this account
  • Create the data directory for the Goerli chain. This is required for storing the Goerli node block data
  • Set directory permissions. The goerli account needs permission to modify the data directory
  • Create a systemd service file to store the service config. You will use the config file to tell systemd to run the geth process

Update the geth service configuration with the following code. Alternatively, you can pick commands from here.

The --goerli the flag is to run the Göerli test network, and the --http flag is to expose an endpoint (http://localhost:8545) that the beacon chain will connect to. --bootnodes flag to statically link chosen peer nodes to our geth node. This is to avoid any ongoing discovery for its peer. The List is taken from here. Please note that it is updated regularly.

Reload systemd to reflect the changes and start the service and check to make sure it’s running correctly.

This shows the node has started. It will take a few hours or even days to synch fully with Goerli blockchain. For me, it had to synch over 3 million blocks.

Step 2 — Build Lighthouse

Install Dependencies

Lighthouse is built on Rust. Follow the prompts to install.

Since Rust modifies the PATH variable, you will need to log out and back in again, or you may get a command not found error when trying to compile.

Some packages (git, gcc, g++, make, cmake, etc.) are also required.

Build Lighthouse

Now dependencies are installed, you should now build Lighthouse client. The Lighthouse build produces a lighthouse binary. The same binary is used to run the Beacon node as well as validator client.

Clone the Lighthouse core repository, use ‘make’ to compile the Lighthouse binary and move the binary to the bin folder.

It will take a while to build it. So keep patience.

Step 3 — Configure the Beacon Node

You will run the beacon node as a service, so if the system restarts, the process will automatically start back up again.

Run the Beacon Node as a Background Service

  • Create a no-home account lighthousebeacon for the service to run under
  • Create the data directory for the lighthouse beacon node to store beacon node data
  • Set directory permissions. The lighthousebeacon account needs permission to modify the data directory
  • Create/Use a fresh Ethereum1.0 Address using Metamask wallet on your favourite browser extension and copy the graffiti string by pressing Lighthouse orange icon at the left. In our case the address is ‘0xFa55bEacf4d07839e1B84B6E56f002402fe2eB94’
  • Get the POAP (Proof of Attendance Protocol) badge for your beacon node client from here. This is a graffiti which can be put up on your explorer block as proof that you participated during this test phase.
Graffiti for POAP
  • Create a systemd service file to store the service config. You will use the config file to tell systemd to run the lighthousebeacon process

Update the lighthousebeacon service configuration with the following code

and replace copied graffiti string at ` — graffiti <abcdefg12345saf>` and save the file. Alternatively, you can pick commands from here.

Reload systemd to reflect the changes and start the service and check to make sure it’s running correctly.

Let the Beacon node sync with its latest state. `est_time` shows the ETA. Below state shows that the Beacon Node is fully synced.

Step 4 — Put validator stake with the Medalla

Get Goerli Staking ETH

  1. Ask Goerli Testnet faucet for 32 ETH
  2. If you are planning on running multiple validators, you can ask for 32 ETH x number of validators.

Once the Goerli ETH appears in your MetaMask wallet, continue to the next step.

Staking Goerli ETH

Follow the steps given below to install ‘eth2deposit’ script and run it with the given commands

Alternatively, you can pick commands from here.

You can check the staking transaction on goerli testnet. Whoever is coming from the background of Ethereum1.0 can easily understand that this is the Solidity contract Medella BeaconContractor which needs to be sent 32 ‘Goerli’ ETH before it can become validator for the Beacon Chain. This 32 ETHs are staking amount and probably can not be retrieved?

Generate Validator Data

Go to the official Eth2 LaunchPad and follow the instructions. If everything works correctly, validator key files (keystore-m JSON files) will be generated — once for each validator requested. Back them up!

Drop the generated deposit-data-[timestamp].json

Eventually, you should see such a screen.

Validator Info | Medalla Beacon Chain (Phase 0) Ethereum 2.0 Explorer

Waiting for Deposit Inclusion (~ up to 4.09 hrs more) A total deposit of 32 Eth was sent to the ETH_1 Beacon Contract…

beaconscan.com

Now you have reached a very interesting stage. The below image shows the 32 ETHs are already deposited; however, you may not become validator immediately even when you start the validator client process now. The picture shows that it might take 5.08 hrs max; however, it entirely depends upon the length of the validator queue. Every epoch four validators get activated. So if there are over 5000 in the queue, it might take ~ 5 days more or less.

Meddala Validator
Meddala Validator

Read this excerpts from here to understand the technicalities of it.

A validator deposits by sending a transaction that calls a function on the deposit contract on the eth1 chain. A deposit specifies:

  • The public key corresponding to the private key that will be used to sign messages
  • The withdrawal credentials (hash of the public key that will be used to withdraw funds once the validator is done validating)
  • The deposit amount

These values are all signed by the signing key. The goal of having separate signing and withdrawal keys is to allow the more dangerous withdrawal key to be kept more securely (offline, not shared with any staking pools, etc) while the signing key is used to actively sign a message every epoch.

Step 5 — Configure the Lighthouse Validator Client

You will run the validator client as a service so if the system restarts the process will automatically start back up again.

Run Validator Client as a Background Service

  • Create a no-home account lighthousevalidator for the service to run under
  • Create the data directory for the lighthouse validator client to store beacon node data
  • Set directory permissions. The lighthousevalidator account needs permission to modify the data directory
  • Create a systemd service file to store the service config. You will use the config file to tell systemd to run the lighthousevalidator process

Update the lighthousevalidator service configuration with following code

Alternatively, you can pick the text from here.

Reload systemd to reflect the changes and start the service and check to make sure it’s running correctly. For me, it showed below messages. That means, my beacon-node service is not synced yet. So I had to wait.

Later, I saw these messages. At the time of writing this article, I am still getting this message. That means I am still in the queue.

To understand the logic of activation, read below from here

The validator immediately joins the validator registry but is at first inactive. The validator becomes active after 𝑁≥4N≥4 epochs; the minimum of 4 is there to ensure the RANDAO is not manipulable, and 𝑁N may exceed 4 if too many validators try to join at the same time. If the active validator set has size |𝑉||V|, a maximum of 𝑚𝑎𝑥(4,|𝑉|65536)max(4,|V|65536) validators can join per epoch; if more validators try to join, they are put in a queue and processed as quickly as possible.

Acknowledgements

While I understand the nitty-gritty of ethereum 1.0 technologies, this is my first experiment on ethereum 2.0 tech stack.

This guide is based on information I pulled together from various online resources and some article from the medium, mentioned below. I have improved that article as per my experience. Thank you, all to come through thus far!!

Additionally,

Ethereum team recommended a specific set of metrics which every beacon node client should expose. Taking it forward, Prometheus metrics and Grafana dashboard tools can be configured to better monitor the state of the machine as well as lighthouse validator state.

Lighthouse gives a repository on how to use these tools. You can check set of dashboards here. I have configured Summary to view metrics with Graffana.

I will cover it in the next article. Till then Bye!! Happy Learning!! :-)

References:

For technical questions and error, you can connect with Lighthouse Discord server.

Also, Read

Ethereum
Meddala
Lighthouse
Goerli
Eth2

--

--

Ryan Golash
Coinmonks

Written by Ryan Golash

30 Followers

AWS Tech/Principal Engineer/Artificial Intelligence

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams