Obol Network Node Setup and Become Validator(Geth Execution Client and Lighthouse Consensus Client)

18 min readAug 31, 2022

First of all we need to install Obol Network,follow these steps.

$sudo apt update && sudo apt upgrade -y

$sudo apt install make clang pkg-config libssl-dev libclang-dev build-essential git curl ntp jq llvm tmux htop screen unzip -y

$sudo apt install docker.io -y

$git clone https://github.com/docker/compose

$cd compose

$git checkout v2.6.1

$make

$cd

$mv compose/bin/docker-compose /usr/bin

$git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git

$chmod o+w charon-distributed-validator-node

$cd charon-distributed-validator-node

$docker run — rm -v “$(pwd):/opt/charon” obolnetwork/charon:v0.9.0 create enr

You will see creating enr key,need to copy this enr and should use on form.

1- CREATE TEAM

After this You need to join ceremony,For ceremony you need to create a team and should select one captain. The team can has minimum 4, maximum 20 members.

For creating team you need to follow these steps:

1-Captain and every team member should get in console

2-Need to generate new enr keys for every team member(You could face an error with old one)

$cd charon-distributed-validator-node

#You need to get in charon-distributred-validator-node

$sudo chmod -R 777 .charon

#Permisson to expand folder(Every team member should do.)

$docker run — rm -v “$(pwd):/opt/charon” obolnetwork/charon:v0.9.0 enr

#Generate new enr keys, every team member should send it to the team captain.

a) THINGS THAT TEAM CAPTAIN SHOULD DO

$cp .env.sample .env

#Captain need to create env

$nano .env.sample.env

#Captain need to get in and write here captain’s and team members’s enr address. CHARON_OPERATOR_ENRS=enr:-JG4QPtAzqYmB_KrexBQsBTWAyKaktKnwK, enr:-abcdefgasdf,enr:-txyzuybcsgjgg should look like this must seperate with comma.

After that, captain or one of the team member should enter the code according to the number of the team member.

$docker run — rm -v “$(pwd):/opt/charon” — env-file .env obolnetwork/charon:v0.9.0 create dkg — name=”Team name” — fee-recipient-address=”ERC-20 deposit address” — withdrawal-address=”ERC-20 deposit address” — threshold “Number of team member”

#You should enter a Team name, ERC-20 deposit address and write number to the after threshold.

#After you enter this code, a new json file which name is cluster-definition.json occurs in to the captain’s .charon folder.

#Team captain should send this file to the every team member and team members should drop this file into the .charon folder.

b) THINGS THAT EVERY TEAM MEMBER SHOULD DO

When every team member has the same cluster-definition.json file on theirs .charon folder you are ready to go! Everyone should enter this code same time(I suggest max 1 min to first entry to last) on console and wait for the peer.

$docker run — rm -v “$(pwd):/opt/charon” obolnetwork/charon:v0.9.0 dkg — p2p-bootnode-relay

#When everybody connected to each other you will see succes on the console, it takes 2–3 minutes.

There will be new .charon folder after this process. If you want to transfer your node you will be need this, so download and keep it!

c) ATHENA PUBLIC TESTNET VALIDATOR SUBMISSION

Team members should send theirs discord ID’s to the captain for the form.After team captain receive team member’s discord ID need to fill the Athena Public Testnet Validator Submission form correctly.

https://obol.typeform.com/AthenaTestnet

2- Guide to Staking on Ethereum (Ubuntu/Goerli/Lighthouse)

First of all you need one more VPS for goerli testnet, here it is requirements:

A relatively modern multi-core CPU
8GB RAM (16GB is better, and required in some cases)
An SSD (NVMe is better) of at least 1TB (2TB is recommended)
A stable internet connection with sufficient download speed and monthly data allowance

a) Download the Deposit Tool (Staking Deposit CLI)

Go there https://github.com/ethereum/staking-deposit-cli/releases and get the latest version of the staking deposit command line interface (CLI) tool.

In the Assets section locate the version matching the required platform. If Windows, right-click the link and download. If Linux, download the archive using the commands below.

$ cd ~

$ curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/v2.3.0/staking_deposit-cli-76ed782-linux-amd64.tar.gz

In Linux, unpack the tar archive using the commands below and go into the directory it creates.

Modify the file name to match the downloaded version.

$ sudo tar xvf staking_deposit-cli-76ed782-linux-amd64.tar.gz
$ cd staking_deposit-cli-76ed782-linux-amd64

Run the Deposit Tool (Staking Deposit CLI)

On the secure machine run the binary file in a terminal window (or CMD in Windows). For example, if you want to create 1 validator use the commands below.

$ sudo ./deposit new-mnemonic — num_validators 1 — chain goerli

Once you execute the above steps on your platform of choice and provide your language preferences you will be asked to create the validator keystore(s) password. Back it up somewhere safe. You will need this later to load the validator keys into the Consensus Client validator wallet.

Next, a seed phrase (mnemonic) will be generated. Back it up somewhere safe. This is CRITICAL. You will eventually use this to generate your withdrawal keys for your staked Goerli test network ETH or to add additional validators.

NOTE: If you lose the mnemonic you will not be able to withdraw your funds.

Once you have confirmed your mnemonic your validator keys will be created.

The validator key(s) and deposit data file are created at the specified location. The contents of the directory are shown below.

The deposit_data-[timestamp].json file contains the public key(s) for the validator(s) and information about the staking deposit. This file will be used to complete the Goerli test network ETH staking deposit process later in this guide.
The keystore-[..].json files contain the encrypted validator signing key. There is one keystore file per validator that you are funding. These will be imported into the Consensus Client validator wallet for use during validation operations.
You will copy the files over to your Ubuntu server (if not already there) later in this guide.
If you lose or accidentally delete the files it is possible to regenerate them using the Staking Deposit Tool and your mnemonic via the existing-mnemonic command.

Now that you have generated the deposit data and the keystore files, the validator password, and the mnemonic move on to set up the Ubuntu server.

DO NOT DEPOSIT any Goerli test network ETH at this moment.

It is important to complete and verify your staking setup first. If the Goerli test network ETH deposits become active and your staking setup is not ready, inactivity penalties will be deducted from your staked Goerli test network ETH balance.

Configure Timekeeping

Running validators against a blockchain requires accurate timekeeping in order to ensure proper synchronization with the blockchain network. Ubuntu has time synchronization built in and activated by default using the timedatectl systemd directive.

Verify it’s running correctly.

$ timedatectl

The NTP service should be active. If not then run:

$ sudo timedatectl set-ntp on

Generate Client Authentication Secret

On the server, communication between the Execution and Consensus clients is secured using a JSON Web Token (JWT) authentication scheme. The JWT is represented by a file that contains a randomly generated 32-byte hex string. The Execution and Consensus clients each make use of the file for message authentication.

Create a directory on the server to store the JWT file.

$ sudo mkdir -p /var/lib/jwtsecret

Generate the JWT file using the openssl cryptography software library.

$ openssl rand -hex 32 | sudo tee /var/lib/jwtsecret/jwt.hex > /dev/null

Use the following command to inspect the file with the hex string.

$ sudo nano /var/lib/jwtsecret/jwt.hex

Press <CTRL>+X to exit.

Later in the guide, the path to the jwt.hex file will be included in the configuration of both the Execution and Consensus client so they can authenticate incoming and outgoing messages.

Configure the Execution Client

Each client has different characteristics.

NOTE: It is only necessary to install and run ONE Execution Client from the four options above.

The client you choose is up to you, however, it is recommended in the interests of client diversity (and to avoid serious penalties if using a majority client which experiences a broadly impacting bug) that you select a minority client. Check here to determine the current distribution. For example, at the time the screenshot was taken below, Geth was the majority Execution Client so you should consider a different option.

NOTE: While this guide targets the Goerli test network, client diversity is still important to help with testing. It will also allow you practice running a minority client before moving to mainnet.

NOTE: Execution Clients require significant disk space for storage of Ethereum blockchain data.

The following instructions detail installation steps for each of the four Execution Clients. Remember: it is only necessary to install one. Skip past the other sections as necessary.

I explain only how to run Geth and the process only continues over Geth.

Install the Geth Execution Client by downloading the latest version.

Go https://geth.ethereum.org/downloads/ to get the Latest release of Geth.

Right-click on the Geth for Linux button and copy the download link to the tar.gz file. Be sure to copy the correct link.

Download the archive using the commands below. Modify the URL to match the download link for the latest version.

$ cd ~
$ curl -LO https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.10.21-67109427.tar.gz

Extract the files from the archive and copy to the /usr/local/bin directory. The geth service will run it from there. Modify the file name to match the downloaded version.

$ tar xvf geth-linux-amd64–1.10.21–67109427.tar.gz
$ cd geth-linux-amd64–1.10.21–67109427
$ sudo cp geth /usr/local/bin

Clean up the files. Modify the file name to match the downloaded version.

$ cd ~
$ rm geth-linux-amd64–1.10.21–67109427.tar.gz
$ rm -r geth-linux-amd64–1.10.21–67109427

Geth will be configured to run as a background service. Create an account for the service to run under. This type of account can’t log into the server.

$ sudo useradd — no-create-home — shell /bin/false geth

Create the data directory. This is required for storing the Ethereum blockchain data.

$ sudo mkdir -p /var/lib/geth

Set directory permissions. The geth user account needs permission to modify the data directory.

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

Create a systemd service config file to configure the service.

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

Paste the following service configuration into the file.

[Unit]
Description=Geth Execution Client (Goerli Test Network)
After=network.target
Wants=network.target[Service]
User=geth
Group=geth
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/geth \
— goerli \
— datadir /var/lib/geth \
— authrpc.jwtsecret /var/lib/jwtsecret/jwt.hex \
— metrics \
— metrics.addr 127.0.0.1[Install]
WantedBy=default.target

Notable flags:

— authrpc.jwtsecret /var/lib/jwtsecret/jwt.hex The path to the JWT file that is required for authenticated communication between the Execution and Consensus clients. Enables the Engine API RPC endpoint. Setting this will expose an authenticated HTTP endpoint (http://127.0.0.1:8551).

— metrics.addr 127.0.0.1 Enables the metrics HTTP server.

Check the screenshot below for reference.

Press <CTRL> + X then Y then <ENTER> to save and exit.

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

$ sudo systemctl daemon-reload
$ sudo systemctl start geth
$ sudo systemctl status geth

Check the screenshot below for reference. 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 geth service).

The sync will begin immediately. Use the journal output to follow the progress or check for errors by running the following command.

$ sudo journalctl -fu geth

Check the screenshot below for reference.

Press <CTRL>+ C to exit (will not affect the geth service).

Enable the geth service to automatically start on reboot.

$ sudo systemctl enable geth

Install the Lighthouse Consensus Client

I only guide for run Lighthouse Consensus Client, If you want to use another Consensus Client you can’t find in my guide.

The Lighthouse Consensus Client is a single binary which encapsulates the functionality of the beacon node and validator, run in separate instances. This step will download and prepare the Lighthouse binary.

First, go https://github.com/sigp/lighthouse/releases and identify the Latest release. It is at the top of the page. For example:

In the Binaries section copy the download link to the lighthouse-v…-x86_64-unknown-linux-gnu.tar.gz file. Be sure to copy the correct link.

Download the archive using the commands below. Modify the URL to match the download link for the latest version.

$ cd ~
$ curl -LO https://github.com/sigp/lighthouse/releases/download/v2.5.1/lighthouse-v2.5.1-x86_64-unknown-linux-gnu.tar.gz

Extract the files from the archive and copy to the /usr/local/bin directory. The Lighthouse service will run it from there. Modify the file name to match the downloaded version.

$ tar xvf lighthouse-v2.5.1-x86_64-unknown-linux-gnu.tar.gz
$ sudo cp lighthouse /usr/local/bin

Clean up the files. Modify the file name to match the downloaded version.

$ rm lighthouse-v2.5.1-x86_64-unknown-linux-gnu.tar.gz
$ rm lighthouse

Import the Validator Keys

Configure the Lighthouse validator by importing the validator keys generated in Run The Deposit Tool section.

Copy the Validator Keystore Files to the Server

If you generated the validator keystore-[..].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/staking-deposit-cli/validator_keys. Create the directories first using the following command, if necessary.

$ sudo mkdir -p $HOME/staking-deposit-cli/validator_keys

$ sudo chown -R root:root $HOME/staking-deposit-cli/validator_keys

Check the screenshot below for reference.

Create a directory to store the validator data and give the current user permission to access it. The current user needs access because they will be performing the import.

$ sudo mkdir -p /var/lib/lighthouse
$ sudo chown -R root:root /var/lib/lighthouse

Run the validator import process. You will need to provide the directory where the generated keystore-[..].json files are located. E.g. $HOME/staking-deposit-cli/validator_keys.

$ /usr/local/bin/lighthouse — network goerli account validator import — directory $HOME/staking-deposit-cli/validator_keys — datadir /var/lib/lighthouse

You will be asked to provide the password for the validator keys. This is the password you set when you created the keys during Run The Deposit Tool section.

You will be prompted to enter the password for each key, one-by-one. Be sure to provide the correct password each time because the validator will be running as a service and it needs to persist the password(s) to a file so it can access the key(s) at runtime.

NOTE: The validator data is saved in the following location created during the keystore import process: /var/lib/lighthouse/validators.

Check the screenshot below for reference.

Restore the system default permissions to the lighthouse directory.

$ sudo chown -R root:root /var/lib/lighthouse

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

Configure the Beacon Node Service

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

Set up the Account

Create an account for the service to run under. This type of account can’t log into the server.

$ sudo useradd — no-create-home — shell /bin/false lighthousebeacon

Set up the Directories and the Permissions

Create the data directory for the Lighthouse beacon node database and set permissions.

$ sudo mkdir -p /var/lib/lighthouse/beacon
$ sudo chown -R lighthousebeacon:lighthousebeacon /var/lib/lighthouse/Beacon

Create and Configure the Service

Create a systemd service config file to configure the service.

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

Paste the following into the file.

[Unit]
Description=Lighthouse Consensus Client BN (Goerli Test Network)
Wants=network-online.target
After=network-online.target[Service]
User=lighthousebeacon
Group=lighthousebeacon
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
— network goerli \
— datadir /var/lib/lighthouse \
— http \
— execution-endpoint http://localhost:8551 \
— execution-jwt /var/lib/jwtsecret/jwt.hex \
— checkpoint-sync-url https://goerli.checkpoint-sync.ethdevops.io \
— metrics[Install]
WantedBy=multi-user.target

Check the screenshot below for reference.

Press <CTRL> + X then Y then <ENTER> to save and exit.

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

$ sudo systemctl daemon-reload
$ sudo systemctl start lighthousebeacon
$ sudo systemctl status lighthousebeacon

Check the screenshot below for reference. 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 lighthousebeacon service).

The sync will begin immediately.

NOTE: In order to be able to stake both the Execution Client and the Consensus Client must be fully synced.

Use the journal output to follow the progress or check for errors by running the following command.

$ sudo journalctl -fu lighthousebeacon

Check the screenshot below for reference.

NOTE: The Lighthouse client will not attempt to perform validator duties without a connection to a fully synced Execution Client.

Enable the service to automatically start on reboot.

$ sudo systemctl enable lighthousebeacon

Configure the Validator Service

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

Set up the Validator Node Account and Directory

Create an account for the validator node to run under. This type of account can’t log into the server.

$ sudo useradd — no-create-home — shell /bin/false lighthousevalidator

In Import The Validator Keys section, the validator import process created the following directory: /var/lib/lighthouse/validators. Set directory permissions so the lighthousevalidator account can modify that directory.

$ sudo chown -R lighthousevalidator:lighthousevalidator /var/lib/lighthouse/validators

Create and Configure the Service

Create a systemd service file to store the service config.

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

Paste the following into the file.

[Unit]
Description=Lighthouse Consensus Client VC (Goerli Test Network)
Wants=network-online.target
After=network-online.target[Service]
User=lighthousevalidator
Group=lighthousevalidator
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse vc \
— network goerli \
— datadir /var/lib/lighthouse \
— suggested-fee-recipient FeeRecipientAddress \
— graffiti “<yourgraffiti>”[Install]
WantedBy=multi-user.target

NOTE: Be sure to set the FeeRecipientAddress above to a valid Ethereum address within your control to receive the validator fees. For example: — suggested-fee-recipient 0xe2cA6BF16964kA9D7eEd9e03E53415D37bC25032

Check the screenshot below for reference.

Press <CTRL> + X then Y then <ENTER> to save and exit.

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

$ sudo systemctl daemon-reload
$ sudo systemctl start lighthousevalidator
$ sudo systemctl status lighthousevalidator

Check the screenshot below for reference. 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 lighthousevalidator service).

The sync will begin immediately.

NOTE: In order to be able to stake both the Execution Client and the Consensus Client must be fully synced.

Use the journal output to follow the progress or check for errors by running the following command.

$ sudo journalctl -fu lighthousevalidator

Check the screenshot below for reference.

Enable the service to automatically start on reboot.

$ sudo systemctl enable lighthousevalidator

Fund the Validator Keys

Now that the Consensus Client is up and running, to actually begin staking on the Goerli test network you will need to deposit Goerli test network ETH to fund your validators.

Get Goerli Test Network ETH

Each validator requires a deposit of 32 Goerli test network ETH. You will need a sufficient amount to fund each validator. For example if you plan to run 1 validators you will need to have 32 Goerli test network ETH plus some extra to cover the gas fees.

The two ways to get Goerli test network ETH are detailed below. Both methods require visiting a channel on the EthStaker Discord.

Method 1 — The #request-goerli-eth💸 Channel

This method requires BrightID verification (see #brightid-verification). Verified users can request 32.05 Goerli test network ETH to be sent to their MetaMask wallet every 28 days.

Method 2 — The #fund-prater-validator Channel

This method will utilize a bot to complete the deposit on your behalf, limited to one validator deposit every 6 hours. Continue following this guide below until the point where you upload your deposit_data-[timestamp].json file. Additional instructions are provided at that point.

Perform the Deposit

This step involves depositing the required amount of Goerli ETH to the Prater (also Goerli) staking contract. This is done in a web browser via the Ethereum Staking Launchpad website.

NOTE: You should wait until your Execution Client and Consensus Client have fully synced before proceeding with the deposit. If they have not and your validator(s) become active on the network you would be subject to inactivity penalties.

Go here: https://goerli.launchpad.ethereum.org/

Click on Become a Validator, click through the warning steps and continue through the screens until you get to the Generate Key Pairs section. Select the number of validators you are going to run. Choose a value that matches the number of validators you created in Run The Deposit Tool section.

Scroll down, check the box, and click continue.

You will be asked to upload the deposit_data-[timestamp].json file. You generated this file in Staking Deposit Tool section. You may need to copy the file to the computer you are running the Launchpad from. There are no security concerns copying the file. Browse or drag the file to upload and click continue.

At this point, if you are using Method 2 as described at the beginning of this step, head over to the #fund-prater-validator Discord channel now to complete the deposit.

NOTE: If you are using Method 2, this section is now complete. STOP here. Once you have requested the deposit to be made in Discord, return and resume the guide from the next step (Monitoring: Install Prometheus). Otherwise, it is assumed you have sufficient Goerli test network ETH in your MetaMask wallet to fund your validator(s). Continue.

Connect your wallet. Choose MetaMask, log in, select the Goerli Test Network from the dropdown. Select the account that contains your Goerli test network ETH and click Continue.

WARNING: Be absolutely 100% sure you have selected the Goerli Test Network in MetaMask. DO NOT sent Ethereum Mainnet ETH to any test network.

Your MetaMask account balance will be displayed. The site will allow you to continue if you have selected the Goerli Test Network and you have sufficient Goerli test network ETH balance.