Guide to Staking on Ethereum Testnet(Ubuntu/Prysm)
Last updated: 30 April, 2023
WARNING — do not use this guide for connecting to the Ethereum Mainnet. Mainnet guides are here.
This is a step-by-step guide to staking on the Ethereum Goerli test network via an Execution Client and the Prysm Consensus Client. It is based on the following technologies:
- Server: Ubuntu v20.04 (LTS) x64
- Execution Client: Besu / Erigon / Geth / Nethermind
- Consensus Client: Prysmatic Labs Prysm
- Crypto wallet: MetaMask
- Prometheus metrics
- Grafana dashboard
- Official multi-client public test network, Goerli
Warnings
This guide is written for the Goerli test network. DO NOT, under any circumstances, send mainnet ETH to the Goerli test network. You will lose it.
This guide SHOULD NOT be used for staking on the Ethereum mainnet. Guides that target the Ethereum mainnet can be found here.
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.
Acknowledgements
Thanks to the EthStaker Admins and Educators, the Ethereum Execution and Consensus Client teams, the Ethereum core developers and researchers, and the staking community for all of their amazing contributions, feedback, and support.
Support
For technical support please reach out to:
- The EthStaker community on Reddit or Discord. Knowledgeable and friendly community passionate about staking on Ethereum.
- The Prysm Consensus Client team Discord.
- The Besu / Erigon / Geth / Nethermind Execution Client team Discord.
Prerequisites
This guide assumes some knowledge of Ethereum, ETH, staking ETH, Linux, and MetaMask.
This guide also requires the following before getting started:
- Ubuntu server v20.04 (LTS) amd64 installed and running on a local computer or in the cloud. A locally running computer is encouraged for greater decentralization.
- MetaMask crypto wallet web browser extension installed and configured on a computer with a desktop (Mac, Windows, Linux, etc.) and a web browser (Brave, Safari, FireFox, etc.).
Requirements
In general the following are required for good staking performance. More information here and here.
- 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
NOTE: Check your available disk space. Even if you have a large SSD there are cases where Ubuntu reports only 200GB free. If this applies to you then refer to Appendix K — Expanding the Logical Volume.
Overview
The simplified diagram below illustrates the staking setup. The yellow boxes are the areas this guide covers.
The Consensus Client (formerly Eth2 client) is the software that provides the PoS consensus mechanism to the Execution Client. It includes the Beacon Chain Node and the Validator.
The Execution Client (formerly Eth1 client) is the software that is responsible for various Ethereum network operations such as selecting/executing transactions from the mempool.
NOTE: Both the Consensus Client and Execution Client are required in order to successfully stake.
The conceptual flow through the guide is:
- Generate the staking Validator Keys and Staking Deposit Data
- Prepare the Ubuntu Server (updates, firewall, security, etc.)
- Set up an Execution Client node and sync it with the Ethereum Blockchain (Goerli test network)
- Configure the Prysm Consensus Client and sync it with other Beacon Nodes
- Deposit Goerli test network ETH to activate staking Validator Keys
- Set up server monitoring via Prometheus metrics and a Grafana dashboard
Step 1 — Generate Staking Data
In order to participate in staking on the Goerli test network it is necessary to use a tool to generate data files based on the number of validators you’d like to fund and operate. Each validator will require a deposit of 32 Goerli test network ETH in order to activate it on the Goerli test network.
NOTE: The amount of Goerli test network ETH available per person is limited. Currently it is most practical to fund one to two validators at most.
Submission of the deposit to fund your validator(s) will happen later in this guide, after the staking software is setup. Instructions on acquiring Goerli test network ETH are included there.
Download the Deposit Tool (Staking Deposit CLI)
Go here to 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.
Modify the URL below to match the download link for the latest version.
$ cd ~
$ curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/v2.3.0/staking_deposit-cli-76ed782-linux-amd64.tar.gz
If on Windows, unzip the archive and go into the folder created. If on 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.
$ tar xvf staking_deposit-cli-76ed782-linux-amd64.tar.gz
$ cd staking_deposit-cli-76ed782-linux-amd64
There should be a binary file (executable) in the archive named deposit
.
Prepare to Run the Deposit Tool (Staking Deposit CLI)
The deposit tool generates a mnemonic key. This key must be handled securely to avoid any risk of it being exposed — not so important for a test network, but this is good time to practice for Mainnet. There are two options to proceed from here.
Option 1: Air-Gapped Machine (recommended) — Copy the binary file to a USB drive. Connect the drive to a fully air-gapped machine (never previously connected to a network or the internet). Copy the binary file to the air-gapped machine.
Option 2: Current Machine (not recommended) — Run from the current machine. An internet connection may be an opportunity to leak your mnemonic key. If a fully air-gapped machine isn’t available, disconnect the network/internet on the current machine before proceeding.
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 2 validators with the withdrawal address <YourWithdrawalAddress> use the commands below.
On Linux:
$ ./deposit new-mnemonic --num_validators 2 --chain goerli --eth1_withdrawal_address <YourWithdrawalAaddress>
On Windows:
deposit.exe new-mnemonic --num_validators 2 --chain goerli --eth1_withdrawal_address <YourWithdrawalAaddress>
Replace <YourWithdrawalAddress>
with a Goerli test network Ethereum address within your control.
NOTE: If you need Goerli test network ETH to fund your validator(s) you MUST set the withdrawal address to
0x4D496CcC28058B1D74B7a19541663E21154f9c84
. This is the official address for the EthStaker Goerli Bot. It will only allow you to preform 2 deposits per wallet address, so you should only create 2 validators (64 Goerli ETH). If you already have enough Goerli ETH then you can disregard this. Importantly, this instruction ONLY applies for testnet setups. For Mainnet you should use an address within your control. See the#cheap-goerli-validator
channel on the EthStaker Discord for more information.NOTE: Once set, the withdrawal address CANNOT be changed, so be ABSOLUTELY SURE that it is an address within your control and correctly specified. For example:
--eth1_withdrawal_address 0x4D496CcC28058B1D74B7a19541663E21154f9c84
NOTE: The flag
--eth1_withdrawal_address
allows you to specify a Goerli test network Ethereum address that your staking rewards in excess of 32 staked Goerli test network ETH will automatically be withdrawn to (once withdrawals are enabled). This will also be the address your 32 staked Goerli test network ETH will be withdrawn to if you exit the validator. More information here.NOTE: If you don’t set the
--eth1_withdrawal_address
flag at this time, you can set it later via a special process (known as converting the withdrawal credential from0x00
to0x01
) when you are ready to start withdrawing the staking rewards or when you want to exit the validator. If you don’t set the flag, staking rewards will not be automatically withdrawn and you will not be able to reclaim the 32 staked Goerli test network ETH upon exiting the validator until you convert the withdrawal credential.
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.
Notes about the files:
- 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. More information here.
Final Steps
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.
Step 2 — Connect to the Server
Using a SSH client, connect to your Ubuntu server. If you are logged in as root
then create a user-level account with admin privileges instead, since logging in as the root user is risky.
NOTE: If you are not logged in as
root
then skip this and go to Step 3.
Create a new user. Replace <yourusername>
with a username of your choice. You will asked to create a strong password and provide some other optional information.
# adduser <yourusername>
Grant admin rights to the new user by adding it to the sudo
group. This will allow the user to perform actions with superuser privileges by typing sudo
before commands.
# usermod -aG sudo <yourusername>
Optional: If you used SSH keys to connect to your Ubuntu instance via the root
user you will need to associate the new user with the root user’s SSH key data.
# rsync --archive --chown=<yourusername>:<yourusername> ~/.ssh /home/<yourusername>
Finally, log out of root
and log in as <yourusername>
.
Step 3 — Update the Server
Make sure your system is up to date with the latest software and security updates.
$ sudo apt -y update && sudo apt -y upgrade
$ sudo apt dist-upgrade && sudo apt autoremove
$ sudo reboot
Step 4 — Secure the Server
Security is important. This is not a comprehensive security guide, just some basic settings.
Modify the Default SSH Port
Port 22 is the default SSH port and a common attack vector. Change the SSH port to avoid this.
Choose a port number between 1024–49151 and run the following command to check it is not already in use.
$ sudo ss -tulpn | grep ':YourSSHPortNumber'
Example:
$ sudo ss -tulpn | grep ':6673'
A blank response indicates it is not in use, a red text response indicates it is in use: try a different port number.
If confirmed available, modify the default SSH port number by updating your server’s SSH config. Open the config file:
$ sudo nano /etc/ssh/sshd_config
Find or add (if not present) the line Port 22
in the file. Remove the #
(if present) and change the value as below.
Port YourSSHPortNumber
Check the screenshot below for reference.
Press <CTRL> + X then Y then <ENTER> to save and exit.
Restart the SSH service to reflect the changes.
$ sudo systemctl restart ssh
Remember to update your SSH client settings to reflect the new SSH port that you configured. Log out and log back in via SSH using YourSSHPortNumber
as the port number to make sure everything is working correctly.
Configure the Firewall
Ubuntu 20.04 servers can use the UFW firewall to restrict inbound traffic to the server. The firewall helps prevent unwanted connections to your server.
Install UFW
UFW should be installed by default. The following command will ensure it is.
$ sudo apt install ufw
Apply UFW Defaults
Explicitly apply the defaults: inbound traffic denied, outbound traffic allowed.
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
Allow SSH
Allow inbound traffic on YourSSHPortNumber
as set above. SSH requires the TCP protocol.
NOTE: If you are hosting your Ubuntu instance locally and would like to access your server remotely (not recommended for security reasons), your internet router may need to be configured to allow incoming traffic on port
YourSSHPortNumber
as well.
$ sudo ufw allow YourSSHPortNumber/tcp
Example:
$ sudo ufw allow 6673/tcp
Deny SSH Port 22
If you have changed the value of the SSH port then deny inbound traffic on the default port 22/TCP.
$ sudo ufw deny 22/tcp
Allow Execution Client Port 30303
Allow P2P connections with Execution Client peers (port 30303). This is a common port used by all of the Execution Clients described in this guide.
NOTE: If you are hosting your Ubuntu instance locally your internet router may need to be configured to allow incoming traffic on port 30303 as well.
$ sudo ufw allow 30303
Allow Prysm
Allows P2P connections with Consensus Client peers for actions on the Beacon Chain Node (ports 13000/TCP and 12000/UDP).
NOTE: If you are hosting your Ubuntu instance locally your internet router may need to be configured to allow incoming traffic on ports 13000/TCP and 12000/UDP as well.
$ sudo ufw allow 13000/tcp
$ sudo ufw allow 12000/udp
Allow Grafana
Allows incoming requests to the Grafana web server (port 3000/TCP).
NOTE: If you are hosting your Ubuntu instance locally and would like to access your Grafana dashboard remotely (not recommended for security reasons), your internet router may need to be configured to allow incoming traffic on port 3000 as well.
$ sudo ufw allow 3000/tcp
Enable the Firewall
Enable the firewall and verify the rules have been correctly configured.
$ sudo ufw enable
$ sudo ufw status numbered
Check the screenshot below for reference.
Log out and SSH back in again to confirm everything is working correctly.
Step 5 — Create a Swap Space
A swap space (a file on the disk used to store in-memory data when the system memory gets low) is used to guard against out-of-memory errors. It is particularly useful for clients that require large amounts of memory when syncing or running. More information here.
Confirm there is no swap space already configured.
$ free -h
Zeros on the Swap:
row indicate there is no swap space assigned.
NOTE: If you already have swap space assigned you can skip this step.
The recommended swap space size on disk is shown below. If you have 8GB RAM then use a swap space size of 3GB.
RAM Swap Size
8GB 3GB
12GB 3GB
16GB 4GB
24GB 5GB
32GB 6GB
64GB 8GB
128GB 11GB
Check for available disk space.
$ df -h
In the Mounted on
column locate the row with /
. The swap file will be created on that disk. Make sure it has sufficient space available.
Create the swap space. The value 3G
(3GB) below is for a server with 8GB RAM. Change the value based on the size you require. E.g. If your server has 16GB RAM, then use 4G
.
$ sudo fallocate -l 3G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
Verify the changes.
$ free -h
The swap space should now show.
Enable the swap space to persist after reboot.
$ sudo cp /etc/fstab /etc/fstab.bak
$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Configure the swap space.
$ sudo sysctl vm.swappiness=10
$ sudo sysctl vm.vfs_cache_pressure=50
Open the config file to configure the swap space.
$ sudo nano /etc/sysctl.conf
Add the following to the end of the file.
vm.swappiness=10
vm.vfs_cache_pressure = 50
Check the screenshot below for reference.
Press <CTRL> + X then Y then <ENTER> to save and exit.
The swap file is now configured. Monitor using the htop
command.
Step 6 — 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
Check the screenshot below for reference.
The NTP service
should be active
. If not then run:
$ sudo timedatectl set-ntp on
Step 7 — 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. More information here.
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.
Step 8 — Configure the Execution Client
An Execution Client is required for staking. This guide includes instructions for installing each of the four main Execution Clients. They are:
Each client has different characteristics. More information here.
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. See here for recommended specifications.
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.
Install the Execution Client — Besu
Install the Hyperledger Besu (or simply Besu) Execution Client by downloading the latest version.
Go here to get the Latest release of Besu.
In the Download links section 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://hyperledger.jfrog.io/artifactory/besu-binaries/besu/22.7.2/besu-22.7.2.tar.gz
Extract the files from the archive and copy to the /usr/local/bin
directory. The Besu service will run it from there. Modify the file name to match the downloaded version.
$ tar xvf besu-22.7.2.tar.gz
$ sudo cp -a besu-22.7.2 /usr/local/bin/besu
Clean up the files. Modify the file name to match the downloaded version.
$ rm besu-22.7.2.tar.gz
$ rm -r besu-22.7.2
Install the required prerequisites.
$ sudo apt -y install default-jre
$ sudo apt install -y libjemalloc-dev
Besu 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 besu
Create the data directory. This is required for storing the Ethereum blockchain data.
$ sudo mkdir -p /var/lib/besu
Set directory permissions. The besu user account needs permission to modify the data directory.
$ sudo chown -R besu:besu /var/lib/besu
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/besu.service
Paste the following service configuration into the file.
[Unit]
Description=Besu Execution Client (Goerli Test Network)
Wants=network-online.target
After=network-online.target[Service]
User=besu
Group=besu
Type=simple
Restart=always
RestartSec=5
Environment="JAVA_OPTS=-Xmx3g"
ExecStart=/usr/local/bin/besu/bin/besu \
--network=goerli \
--sync-mode=X_SNAP \
--data-path=/var/lib/besu \
--data-storage-format=BONSAI \
--engine-jwt-secret=/var/lib/jwtsecret/jwt.hex \
--metrics-enabled=true[Install]
WantedBy=multi-user.target
Notable flags:
Environment="JAVA_OPTS=-Xmx3g"
Sets the maximum Java heap size, which defines the maximum amount of memory the besu process can utilize. The value shown here is 3g (3 gigabytes of RAM). More information here.
--sync-mode=X_SNAP
The recommended method of syncing against the Ethereum blockchain when using the BONSAI data storage format. More information here.
--data-storage-format=BONSAI
A storage and lookup efficient method for managing blockchain data. More information here.
--engine-jwt-secret=/var/lib/jwtsecret/jwt.hex
The path to the shared secret authentication token that is required for communication between the Execution and Consensus clients.
--metrics-enabled=true
Enables the metrics output for Prometheus monitoring. More information here.
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 besu
$ sudo systemctl status besu
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 besu 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 besu
Check the screenshot below for reference.
Press <CTRL>+ C to exit (will not affect the besu service).
Enable the besu service to automatically start on reboot.
$ sudo systemctl enable besu
To check the sync status monitor the journal output. An example of synced output can be seen in Appendix I — Synced Client Output.
NOTE: It is necessary to follow a specific series of steps to update the Besu client software. See Appendix A — Updating Besu for further information.
Install the Execution Client — Erigon
Install the Erigon Execution Client by downloading and building the latest version.
NOTE: Erigon requires a minimum of 16GB RAM. More information here.
Erigon requires the Go programming language is installed.
Go here to get the latest release of Go. Be sure to select the Linux version by clicking on the Linux tab in the section Go install.
Right-click on the Download Go 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://go.dev/dl/go1.19.linux-amd64.tar.gz
Remove any older versions and then install Go. Modify the file name to match the downloaded version.
$ sudo rm -rf /usr/local/go
$ sudo tar -C /usr/local -xzf go1.19.linux-amd64.tar.gz
$ export PATH=$PATH:/usr/local/go/bin
$ source $HOME/.profile
Clean up the files. Modify the file name to match the downloaded version.
$ rm go1.19.linux-amd64.tar.gz
Install additional prerequisites.
$ sudo apt-get install -y build-essential
Go here to get the Latest release of Erigon.
In the Assets section 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://github.com/ledgerwatch/erigon/archive/refs/tags/v2022.09.01.tar.gz
Extract the files from the Erigon archive and build the Erigon client. Modify the file name to match the downloaded version.
$ tar xvf v2022.09.01.tar.gz
$ cd erigon-2022.09.01
$ make erigon
Copy to the /usr/local/bin
directory. The erigon service will run it from there.
$ cd ~
$ sudo cp -a erigon-2022.09.01 /usr/local/bin/erigon
Clean up the files. Modify the file name to match the downloaded version.
$ rm v2022.09.01.tar.gz
$ rm -r erigon-2022.09.01
Erigon 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 erigon
Create the data directory. This is required for storing the Ethereum blockchain data.
$ sudo mkdir -p /var/lib/erigon
Set directory permissions. The erigon user account needs permission to modify the data directory.
$ sudo chown -R erigon:erigon /var/lib/erigon
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/erigon.service
Paste the following service configuration into the file.
[Unit]
Description=Erigon Execution Client (Goerli Test Network)
After=network.target
Wants=network.target[Service]
User=erigon
Group=erigon
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/erigon/build/bin/erigon \
--chain=goerli \
--datadir=/var/lib/erigon \
--http.api=engine,eth,net \
--authrpc.jwtsecret=/var/lib/jwtsecret/jwt.hex \
--externalcl \
--private.api.addr= \
--metrics \
--prune.r.before=4367322 \
--prune htc[Install]
WantedBy=default.target
Notable flags:
To see information on flags use the following command:
$ /usr/local/bin/erigon/build/bin/./erigon --help
--authrpc.jwtsecret=/var/lib/jwtsecret/jwt.hex
The path to the shared secret authentication token that is required for communication between the Execution and Consensus clients.
--externalcl
Required flag to indicate the use of an external Consensus Client for validator duties.
--private.api.addr=
Disables the private RPC server. If required, remove the flag to enable it, but be sure to modify the port number by adding an extra flag --private.api.addr=127.0.0.1:9099
to avoid a conflict with Prometheus.
--prune.r.before=4367322
Prune blockchain receipts before the specified block. This is the deposit contract block for the network, as defined here.
--prune htc
Prune blockchain data for ( h )istory, ( t )ransaction lookups, and ( c )all traces.
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 erigon
$ sudo systemctl status erigon
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 erigon 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 erigon
Check the screenshot below for reference.
Press <CTRL>+ C to exit (will not affect the erigon service).
Enable the erigon service to automatically start on reboot.
$ sudo systemctl enable erigon
To check the sync status monitor the journal output. An example of synced output can be seen in Appendix I — Synced Client Output.
NOTE: It is necessary to follow a specific series of steps to update the Erigon client software. See Appendix B — Updating Erigon for further information.
Install the Geth Execution Client by downloading the latest version.
Go here 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.23-d901d853.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.23-d901d853.tar.gz
$ cd geth-linux-amd64-1.10.23-d901d853
$ 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.23-d901d853.tar.gz
$ rm -r geth-linux-amd64-1.10.23-d901d853
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
TimeoutStopSec=600
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
NOTE: The inclusion of
TimeoutStopSec=600
is to allow the Geth service sufficient time to write cached data to disk on shutdown. More information here.
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
To check the sync status monitor the journal output. An example of synced output can be seen in Appendix I — Synced Client Output.
NOTE: It is necessary to follow a specific series of steps to update the Geth client software. See Appendix C — Updating Geth for further information.
NOTE: It is possible to prune the Geth database to reduce its size on disk. See the guide for Pruning Geth here for further information.
Install the Execution Client — Nethermind
Install the Nethermind Execution Client by downloading the latest version.
Go here to get the Latest release of Nethermind.
In the Assets section copy the download link to the linux-amd64 zip file. Be sure to copy the correct link.
Download the archive using the commands below. Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://github.com/NethermindEth/nethermind/releases/download/1.14.1/nethermind-linux-amd64-1.14.1-1a32d45-20220907.zip
Extract the files from the archive and copy to the /usr/local/bin
directory. The nethermind service will run it from there. Modify the file name to match the downloaded version.
$ sudo apt-get install -y unzip
$ unzip nethermind-linux-amd64-1.14.1-1a32d45-20220907.zip -d nethermind
$ sudo cp -a nethermind /usr/local/bin/nethermind
Clean up the files. Modify the file name to match the downloaded version.
$ rm nethermind-linux-amd64-1.14.1-1a32d45-20220907.zip
$ rm -r nethermind
Install the required prerequisites.
$ sudo apt-get update
$ sudo apt-get install libsnappy-dev libc6-dev libc6 unzip -y
Nethermind 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 nethermind
Create the data directory. This is required for storing the Ethereum blockchain data.
$ sudo mkdir -p /var/lib/nethermind
Set directory permissions. The nethermind user account needs permission to modify the data directory and the binary directory (for logging).
$ sudo chown -R nethermind:nethermind /var/lib/nethermind
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/nethermind.service
Paste the following service configuration into the file.
[Unit]
Description=Nethermind Execution Client (Goerli Test Network)
After=network.target
Wants=network.target[Service]
User=nethermind
Group=nethermind
Type=simple
Restart=always
RestartSec=5
WorkingDirectory=/var/lib/nethermind
Environment="DOTNET_BUNDLE_EXTRACT_BASE_DIR=/var/lib/nethermind"
ExecStart=/usr/local/bin/nethermind/Nethermind.Runner \
--config goerli \
--datadir /var/lib/nethermind \
--Sync.SnapSync true \
--Sync.AncientBodiesBarrier 4367322 \
--Sync.AncientReceiptsBarrier 4367322 \
--JsonRpc.JwtSecretFile /var/lib/jwtsecret/jwt.hex \
--Metrics.Enabled true[Install]
WantedBy=default.target
Notable flags:
--SnapSync true
Enables both the SnapSync and FastSync features.
--Sync.AncientBodiesBarrier 4367322
and--Sync.AncientReceiptsBarrier 4367322
Define a minimum block to sync against. This is the deposit contract block for the network, as defined here.
--JsonRpc.JwtSecretFile /var/lib/jwtsecret/jwt.hex
The path to the JWT file that is required for authenticated communication between the Execution and Consensus clients.
--Metrics.Enabled true
Enables a ‘push’ style metrics capability that allows Grafana monitoring. It requires a Prometheus Pushgateway to function. See Appendix H — Install Prometheus Pushgateway for more information. If you aren’t planning to use Grafana monitoring then remove this flag or it will cause a non-fatal error.
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 nethermind
$ sudo systemctl status nethermind
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 nethermind 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 nethermind
Check the screenshot below for reference.
Press <CTRL>+ C to exit (will not affect the nethermind service).
Enable the nethermind service to automatically start on reboot.
$ sudo systemctl enable nethermind
To check the sync status monitor the journal output. An example of synced output can be seen in Appendix I — Synced Client Output.
NOTE: It is necessary to follow a specific series of steps to update the Nethermind client software. See Appendix D — Updating Nethermind for further information.
You should now have installed, configured, and run one of the Execution Clients above. Great job! Next we will configure the Consensus client.
Step 9 — Install the Prysm Consensus Client
The Prysm Consensus Client is made up of two binaries that provide the functionality of the beacon node and validator, respectively. This step will download and prepare the Prysm binaries.
First, go here and identify the Latest release. It is at the top of the page. For example:
In the Assets section (expand if necessary) copy the download links to the beacon-chain-v…-linux-amd64 file and the validator-v…-linux-amd64 file. Be sure to copy the correct links.
Download the binaries using the commands below. Modify the URL to match the copied download links.
$ cd ~
$ curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v4.0.1/beacon-chain-v4.0.1-linux-amd64$ curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v4.0.1/validator-v4.0.1-linux-amd64
Rename the files and make them executable. Copy them to the /usr/local/bin
directory. The Prysm services will run them from there. Modify the file names to match the downloaded version.
$ mv beacon-chain-v4.0.1-linux-amd64 beacon-chain
$ mv validator-v4.0.1-linux-amd64 validator$ chmod +x beacon-chain
$ chmod +x validator$ sudo cp beacon-chain /usr/local/bin
$ sudo cp validator /usr/local/bin
Clean up the files.
$ rm beacon-chain && rm validator
NOTE: It is necessary to follow a specific series of steps to update Prysm. See Appendix E — Updating Prysm for further information.
Step 10 — Import the Validator Keys
Configure the Prysm validator by importing the validator keys generated in Step 1.
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
If you are using SFTP and you get a permission denied error when copying the files, grant the login account access to the directory using the following command. Replace <yourusername>
with the login account username.
$ sudo chown -R <yourusername>:<yourusername> $HOME/staking-deposit-cli/validator_keys
Check the screenshot below for reference.
Import the Validator Keystore Files into Prysm
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. Change <yourusername>
to the logged in username.
$ sudo mkdir -p /var/lib/prysm/validator
$ sudo chown -R <yourusername>:<yourusername> /var/lib/prysm/validator
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/validator accounts import --keys-dir=$HOME/staking-deposit-cli/validator_keys --wallet-dir=/var/lib/prysm/validator --goerli
You will be presented with terms of use which you will need to accept to continue.
You will need to create a wallet password. This is different to the validator password you set in Step 1. Prysm will use this to decrypt the validator wallet. Back it up somewhere safe. You will need this later in this section and when configuring the validator.
You will need to provide the validator keys password. This is the password you set when you created the keys during Step 1.
If you enter it correctly the keys will be imported.
NOTE: If you have used different passwords for each of your validators you will get an error. Run the process multiple times, providing each of the different passwords until they are all imported. Use the
accounts list
command to verify. E.g./usr/local/bin/validator accounts list --wallet-dir=/var/lib/prysm/validator --goerli
Create a Wallet Password File
Create a file to store the wallet password so the Prysm validator service can access the wallet without you having to supply the password.
$ sudo nano /var/lib/prysm/validator/password.txt
Add your new wallet password to the file. Replace YourNewWalletPassword
with your password.
Check the screenshot below for reference.
Press <CTRL> + X then Y then <ENTER> to save and exit.
The import is complete and the wallet is now set up.
NOTE: It is necessary to follow a specific series of steps to add an additional validator. See Appendix F — Adding Validators for further information.
Step 11 — Configure the Beacon Node Service
In this step you will configure and run the Prysm 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 prysmbeacon
Set up the Directories and the Permissions
Create the data directory for the Prysm beacon node database and set permissions.
$ sudo mkdir -p /var/lib/prysm/beacon
$ sudo chown -R prysmbeacon:prysmbeacon /var/lib/prysm/beacon
Create and Configure the Service
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/prysmbeacon.service
Paste the following into the file.
[Unit]
Description=Prysm Consensus Client BN (Goerli Test Network)
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 \
--goerli \
--datadir=/var/lib/prysm/beacon \
--execution-endpoint=http://127.0.0.1:8551 \
--jwt-secret=/var/lib/jwtsecret/jwt.hex \
--suggested-fee-recipient=FeeRecipientAddress \
--enable-debug-rpc-endpoints \
--grpc-max-msg-size=65568081 \
--checkpoint-sync-url=CheckpointSyncURL \
--genesis-beacon-api-url=CheckpointSyncURL \
--accept-terms-of-use[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=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
NOTE: Be sure to set the two
CheckpointSyncURL
above to a valid checkpoint sync URL. See below for more information. For example:--checkpoint-sync-url=https://goerli.beaconstate.ethstaker.cc
and--genesis-beacon-api-url=https://goerli.beaconstate.ethstaker.cc
Notable flags:
--execution-endpoint=http://127.0.0.1:8551
The address of the Execution Client. Should be the same for all Execution Clients detailed in this guide.
--jwt-secret=/var/lib/jwtsecret/jwt.hex
The path to the JWT file that is required for authenticated communication between the Execution and Consensus clients.
--suggested-fee-recipient=FeeRecipientAddress
Validators can receive tips from user transactions. Provide an Ethereum address within your control to specify where the tips should go.
--enable-debug-rpc-endpoints
--grpc-max-msg-size=6568081
--checkpoint-sync-url
--genesis-beacon-api-url
Enables the Checkpoint Sync feature to greatly speed up the Beacon Chain Node sync. More information here. Provide a URL to a synced Beacon Chain Node for the sync. You can get one here. Make sure you choose a Goerli endpoint.
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 prysmbeacon
$ sudo systemctl status prysmbeacon
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 prysmbeacon 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 prysmbeacon
Check the screenshot below for reference.
NOTE: The Prysm 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 prysmbeacon
To check the sync status monitor the journal output. An example of synced output can be seen in Appendix I — Synced Client Output.
Step 12 — Configure the Validator Service
In this step you will configure and run the Prysm 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 prysmvalidator
In Step 10 the validator import process created the following directory: /var/lib/prysm/validator
. Set directory permissions so the prysmvalidator
account can modify that directory.
$ sudo chown -R prysmvalidator:prysmvalidator /var/lib/prysm/validator
Create and Configure the Service
Create a systemd service file to store the service config.
$ sudo nano /etc/systemd/system/prysmvalidator.service
Paste the following into the file.
[Unit]
Description=Prysm Consensus Client VC (Goerli Test Network)
Wants=network-online.target
After=network-online.target[Service]
User=prysmvalidator
Group=prysmvalidator
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/validator \
--datadir=/var/lib/prysm/validator \
--wallet-dir=/var/lib/prysm/validator \
--wallet-password-file=/var/lib/prysm/validator/password.txt \
--graffiti="<yourgraffiti>" \
--accept-terms-of-use[Install]
WantedBy=multi-user.target
Notable flags:
--graffiti “<yourgraffiti>"
Replace with your own graffiti string. For security and privacy reasons avoid information that can uniquely identify you. E.g. --graffiti="Validatooor"
.
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 prysmvalidator
$ sudo systemctl status prysmvalidator
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 prysmvalidator 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 prysmvalidator
Check the screenshot below for reference.
Enable the service to automatically start on reboot.
$ sudo systemctl enable prysmvalidator
To check the sync status monitor the journal output. An example of synced output can be seen in Appendix I — Synced Client Output.
You should now have installed, configured, and run the Prysm Consensus Client. Great job! Next we will perform the deposit to activate your validators on the network.
Step 13 — 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 2 validators you will need to have (2 x 32) = 64 Goerli test network ETH plus some extra to cover the gas fees.
There are two options to proceed from here:
Method 1 — You supply the Goerli ETH
If you have sufficient Goerli ETH to fund your validator(s) then move ahead to the Perform the Deposit section below and continue through the instructions.
Method 2 — The #cheap-goerli-validator Channel
This method will utilize a bot to complete the deposit on your behalf, limited to 2 validators per user/wallet for a small fee of 0.0001 Goerli ETH. Go to the EthStaker Discord and follow the instructions provided in the #cheap-goerli-validator channel to use the bot and complete the deposit.
NOTE: To avoid abuse, there is a 2–3 day waiting period for new discord members to use the bot.
Once the deposit is done resume this guide from Step 14.
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 Step 1.
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 Step 1. 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.
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.
A summary shows the number of validators and total amount of Goerli test network ETH required. Tick the boxes if you agree and click continue.
Click on Initiate All Transactions.
This will pop open multiple instances of MetaMask, each with a 32 Goerli test network ETH transaction request to the Prater (also Goerli) deposit contract. Confirm each transaction.
Once all the transactions have successfully completed you are done!
Congratulations are due!
That’s it. We have a functioning Execution and Consensus client and the staking deposit done. Once your deposit is active you will automatically begin staking and earning rewards. Congratulations: you are awesome!
NOTE: Once you are done participating in the test network it is considered good practice to exit your validators. See Appendix G — Exiting Validators.
Step 14 — Check the Status of Your Validators
Newly added validators can take a while (hours, days, or weeks) to activate. You can check the status of yours with these steps:
- Copy your MetaMask wallet address (the same one you used to make the deposit).
- Go here: https://goerli.beaconcha.in/
- Search for your key(s) using your wallet address.
Digging into a specific validator we see a Status section that provides an estimate until activation for each validator.
Step 15 — Monitoring: Install Prometheus
The Prometheus monitoring toolkit will be used to expose runtime data from the Execution and Consensus clients.
Go here to get the latest release of Prometheus.
Copy the download link to the linux-amd64.tar.gz file. Be sure to copy the correct link.
Download the archive using the commands below. Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://github.com/prometheus/prometheus/releases/download/v2.37.0/prometheus-2.37.0.linux-amd64.tar.gz
Extract the files from the archive and copy the two binaries to the /usr/local/bin
directory. The Prometheus service will run them from there. Modify the file name to match the downloaded version.
$ tar xvf prometheus-2.37.0.linux-amd64.tar.gz
$ sudo cp prometheus-2.37.0.linux-amd64/prometheus /usr/local/bin/
$ sudo cp prometheus-2.37.0.linux-amd64/promtool /usr/local/bin/
Copy the content files to the following locations. Modify the file name to match the downloaded version.
$ sudo cp -r prometheus-2.37.0.linux-amd64/consoles /etc/prometheus
$ sudo cp -r prometheus-2.37.0.linux-amd64/console_libraries /etc/prometheus
Clean up the files. Modify the file name to match the downloaded version.
$ rm prometheus-2.37.0.linux-amd64.tar.gz
$ rm -r prometheus-2.37.0.linux-amd64
Prometheus 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 prometheus
Create the data directory. This is required for storing the Ethereum blockchain data.
$ sudo mkdir -p /var/lib/prometheus
Create the config file. Prometheus uses a configuration file so it knows where to scrape the data from. We will set this up here.
Create a config file for editing.
$ sudo nano /etc/prometheus/prometheus.yml
Paste the following into the file. The config below includes settings for each of the Execution Clients. There is no need to modify these, but if you prefer you can remove the redundant lines. The structure and alignment are important and must be duplicated exactly.
NOTE: If you are using Erigon or Geth as your Execution Client you may need to remove the entry from the config for the other to avoid overlapping data sources.
global:
scrape_interval: 15s
scrape_configs:
- job_name: prometheus
static_configs:
- targets:
- localhost:9090
- job_name: node_exporter
static_configs:
- targets:
- localhost:9100
- job_name: prysm-beacon
static_configs:
- targets:
- localhost:8080
- job_name: prysm-validator
static_configs:
- targets:
- localhost:8081
- job_name: besu
metrics_path: /metrics
static_configs:
- targets:
- localhost:9545
- job_name: erigon
metrics_path: /debug/metrics/prometheus
static_configs:
- targets:
- localhost:6060
- job_name: geth
metrics_path: /debug/metrics/prometheus
static_configs:
- targets:
- localhost:6060
- job_name: nethermind
static_configs:
- targets:
- localhost:9091
Check the screenshot below for reference.
Press <CTRL> + X then Y then <ENTER> to save and exit.
Set directory permissions. The prometheus user account needs permission to modify the directories.
$ sudo chown -R prometheus:prometheus /etc/prometheus
$ sudo chown -R prometheus:prometheus /var/lib/prometheus
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/prometheus.service
Paste the following service configuration into the file.
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target[Service]
Type=simple
User=prometheus
Group=prometheus
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/prometheus \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.path=/var/lib/prometheus \
--web.console.templates=/etc/prometheus/consoles \
--web.console.libraries=/etc/prometheus/console_libraries[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 prometheus
$ sudo systemctl status prometheus
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 prometheus service).
Use the journal output to check for errors by running the following command.
$ sudo journalctl -fu prometheus
Check the screenshot below for reference.
Press <CTRL>+ C to exit (will not affect the prometheus service).
Enable the prometheus service to automatically start on reboot.
$ sudo systemctl enable prometheus
The service is now installed.
Step 16 — Monitoring: Install Node Exporter
The Node Exporter service exposes OS metrics for your Ubuntu server.
Go here to get the latest release of Node Exporter (not the Pre-release).
Copy the download link to the linux-amd64.tar.gz file. Be sure to copy the correct link.
Download the archive using the commands below. Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
Extract the files from the archive and copy the binary to the /usr/local/bin directory. The Node Exporter service will run them from there. Modify the file name to match the downloaded version.
$ tar xvf node_exporter-1.3.1.linux-amd64.tar.gz
$ sudo cp node_exporter-1.3.1.linux-amd64/node_exporter /usr/local/bin
Clean up the files. Modify the file name to match the downloaded version.
$ rm node_exporter-1.3.1.linux-amd64.tar.gz
$ rm -r node_exporter-1.3.1.linux-amd64
Node Exporter 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 node_exporter
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/node_exporter.service
Paste the following service configuration into the file.
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target[Service]
User=node_exporter
Group=node_exporter
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/node_exporter[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 node_exporter
$ sudo systemctl status node_exporter
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 node_exporter service).
Use the journal output to check for errors by running the following command.
$ sudo journalctl -fu node_exporter
Check the screenshot below for reference.
Press <CTRL>+ C to exit (will not affect the node_exporter service).
Enable the node_exporter service to automatically start on reboot.
$ sudo systemctl enable node_exporter
The service is now installed.
Step 17 — Monitoring: Install Grafana
Grafana provides reporting dashboard capability. Let’s install it and configure a dashboard.
Download the Grafana GPG key and add Grafana to the APT sources.
$ wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
$ sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
Refresh the apt cache.
$ sudo apt update
Make sure Grafana is installed from the repository.
$ apt-cache policy grafana
Output should look like this:
grafana:
Installed: (none)
Candidate: 9.0.5
Version table:
9.0.5 500
500 https://packages.grafana.com/oss/deb stable/main amd64
Packages
9.0.4 500
500 https://packages.grafana.com/oss/deb stable/main amd64
...
Verify the version at the top matches the latest version shown here. Then proceed with the installation.
$ sudo apt install -y grafana
Start the Grafana server and check the status to make sure it’s running correctly.
$ sudo systemctl start grafana-server
$ sudo systemctl status grafana-server
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 grafana-server service).
Use the journal output to check for errors by running the following command.
$ sudo journalctl -fu grafana-server
Check the screenshot below for reference.
Press <CTRL>+ C to exit (will not affect the grafana-server service).
Enable the grafana-server service to automatically start on reboot.
$ sudo systemctl enable grafana-server
Configure Grafana Login
Great job on getting this far! Now that you have everything up and running you can go to http://<yourserverip>:3000/
in a browser and the Grafana login screen should come up.
Enter admin
for the username and password. It will prompt you to change your password and you should definitely do that.
Configure the Grafana Data Source
Let’s configure a data source. Move your mouse over the gear icon at the bottom left of the left menu bar. A menu will pop-up — choose Data Sources. Alternatively navigate here: http://<yourserverip>:3000/datasources
Click on Add data source and then choose Prometheus. Enter http://localhost:9090
for the URL then click on Save and Test.
Step 18 — Monitoring: Add Grafana Dashboards
A Grafana dashboard is required to visualize the monitoring data.
In the Grafana website (http://<yourserverip>:3000
) on the left menu bar and click on Dashboards then Import.
The Import screen accepts a dashboard ID or raw JSON.
Execution Client Dashboard
The following codes reference dashboards for each execution client. Select the one that matches your setup.
Besu: 10273
Geth: 14053
or 15750
Erigon: Copy the data here.
Nethermind: Copy the data here.
On the Import screen, enter the ID in the first box (Besu or Geth), or paste the JSON text from the link (Erigon or Nethermind) for the desired client. You may also need to select the datasource (Prometheus).
Consensus Client Dashboard
On the Import screen, paste the JSON text from here. Rename it to Prysm.
You should be able to view the dashboard. At first you may not have sufficient data, but after everything gets going the data will populate.
Final Remarks and Recommended Next Steps
Thanks for the opportunity. Hopefully this guide was helpful for you.
Next steps
- Reboot your machine and make sure all services come back up
- Understand how to update the client and server software
- Use
htop
/df -h
/ncdu /
to monitor resources on the local machine - Review Appendix J — Manage Systemd Journal Logs to manage log size
- Get familiar with beaconcha.in so you can monitor your validators
- Use the beaconcha.in mobile app to monitor your validators
- Join the Ethstaker and Prysm Discord for important notifications
- Share feedback on Discord (Somer#0753), Twitter, or Reddit
- Help others with their setup on the Ethstaker Discord
- Share this guide with your friends!
- Tips appreciated:
— somer.eth (0x32B74B90407309F6637245292cd90347DE658A37)
— Gitcoin Grants
Further Reading
It is strongly recommended that you evaluate information from as many sources as possible. These are additional resources to help familiarize yourself with staking on Ethereum.
The author has not verified these resources. Use at your own risk.
- Ethereum Foundation
- Execution Client docs: Besu / Erigon / Geth / Nethermind
- Consensus Client docs: Lighthouse / Lodestar / Prysm / Nimbus / Teku
- CoinCashew Guides
- Metanull-Operator Guide
- Remy Roy EthStaker Guides
- ETH Docker Docs
Appendix A — Updating Besu
If you need to update to the latest version of Besu follow these steps.
Go here to get the Latest release of Besu. In the Download link section copy the download link to the tar.gz file. Be sure to copy the correct link.
Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://hyperledger.jfrog.io/artifactory/besu-binaries/besu/22.7.2/besu-22.7.2.tar.gz
Stop the Besu service.
$ sudo systemctl stop besu
Extract the files from the archive and copy to the /usr/local/bin
directory. Modify the file name to match the downloaded version.
$ tar xvf besu-22.7.2.tar.gz
$ sudo rm -r /usr/local/bin/besu # <-- Remove the old files
$ sudo cp -a besu-22.7.2 /usr/local/bin/besu
Restart the services and check for errors.
$ sudo systemctl start besu
$ sudo systemctl status besu # <-- Check for errors
$ sudo journalctl -fu besu # <-- Monitor
$ sudo journalctl -fu prysmbeacon # <-- Monitor
Clean up the files. Modify the file name to match the downloaded version.
$ cd ~
$ rm besu-22.7.2.tar.gz
$ rm -r besu-22.7.2
Appendix B — Updating Erigon
If you need to update to the latest version of Erigon follow these steps.
Go here to get the Latest release of Erigon. In the Assets section copy the download link to the tar.gz file. Be sure to copy the correct link.
Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://github.com/ledgerwatch/erigon/archive/refs/tags/v2022.09.01.tar.gz
Extract the files from the Erigon archive and build the Erigon client. Modify the file name to match the downloaded version.
$ tar xvf v2022.09.01.tar.gz
$ cd erigon-2022.09.01
$ make erigon
If you get the following error: /bin/sh: 1: go: not found
and you have previously installed go then run the following commands and try the make erigon
command again.
$ export PATH=$PATH:/usr/local/go/bin
$ source $HOME/.profile
Stop the Erigon service.
$ sudo systemctl stop erigon
Copy to the /usr/local/bin
directory. Modify the file name to match the downloaded version.
$ cd ~
$ sudo rm -r /usr/local/bin/erigon # <-- Remove the old files
$ sudo cp -a erigon-2022.09.01 /usr/local/bin/erigon
Restart Erigon and check for errors.
$ sudo systemctl start erigon
$ sudo systemctl status erigon # <-- Check for errors
$ sudo journalctl -fu erigon <-- Monitor
$ sudo journalctl -fu prysmbeacon # <-- Monitor
Clean up the files. Modify the file name to match the downloaded version.
$ rm v2022.09.01.tar.gz
$ rm -r erigon-2022.09.01
Appendix C — Updating Geth
If you need to update to the latest version of Geth follow these steps.
NOTE: If you installed Geth using an earlier version of this guide using PPA’s (Personal Package Archives) then skip ahead to the steps at the end of this Appendix instead.
First, go here and 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.
Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.10.23-d901d853.tar.gz
Stop the Geth service.
$ sudo systemctl stop geth
Extract the files from the archive and copy to the /usr/local/bin
directory. Modify the file name to match the downloaded version.
$ tar xvf geth-linux-amd64-1.10.23-d901d853.tar.gz
$ cd geth-linux-amd64-1.10.23-d901d853
$ sudo cp geth /usr/local/bin
Restart the services and check for errors.
$ sudo systemctl start geth
$ sudo systemctl status geth # <-- Check for errors
$ sudo journalctl -fu geth # <-- Monitor
$ sudo journalctl -fu prysmbeacon # <-- Monitor
Clean up the files. Modify the file name to match the downloaded version.
$ cd ~
$ rm geth-linux-amd64-1.10.23-d901d853.tar.gz
$ rm -r geth-linux-amd64-1.10.23-d901d853
OPTIONAL: If you are running Geth configured via a previous version of this guide using PPA’s (Personal Package Archives) then follow these steps instead.
$ sudo systemctl stop geth
$ sudo apt update && sudo apt upgrade
$ sudo systemctl start geth
$ sudo systemctl status geth # <-- Check for errors
$ sudo journalctl -fu geth # <-- Monitor
$ sudo journalctl -fu prysmbeacon # <-- Monitor
Appendix D — Updating Nethermind
If you need to update to the latest version of Nethermind follow these steps.
First, go here and identify the Latest release. In the Assets section copy the download link to the linux-amd64 zip file. Be sure to copy the correct link.
Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://github.com/NethermindEth/nethermind/releases/download/1.14.1/nethermind-linux-amd64-1.14.1-1a32d45-20220907.zip
Stop Nethermind service.
$ sudo systemctl stop nethermind
Extract the files from the archive and copy to the /usr/local/bin
directory. Modify the file name to match the downloaded version.
$ unzip nethermind-linux-amd64-1.14.1-1a32d45-20220907.zip -d nethermind
$ sudo rm -r /usr/local/bin/nethermind # <-- Remove the old files
$ sudo cp -a nethermind /usr/local/bin/nethermind
Restart the services and check for errors.
$ sudo systemctl start nethermind
$ sudo systemctl status nethermind # <-- Check for errors
$ sudo journalctl -fu nethermind # <-- Monitor
$ sudo journalctl -fu prysmbeacon # <-- Monitor
Clean up the files. Modify the file name to match the downloaded version.
$ cd ~
$ rm nethermind-linux-amd64-1.14.1-1a32d45-20220907.zip
$ rm -r nethermind
Appendix E — Updating Prysm
If you need to update to the latest version of Prysm follow these steps.
First, go here and identify the Latest release. In the assets section (expand if necessary) copy the download link to the beacon-chain-v…-linux-amd64 file and the validator-v…-linux-amd64 file. Be sure to copy the correct link.
Modify the URLs in the instructions below to match the download links for the latest version.
$ cd ~
$ curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v4.0.1/beacon-chain-v4.0.1-linux-amd64$ curl -LO https://github.com/prysmaticlabs/prysm/releases/download/v4.0.1/validator-v4.0.1-linux-amd64
Stop the Prysm client services.
$ sudo systemctl stop prysmvalidator
$ sudo systemctl stop prysmbeacon
Rename the files and make them executable. Copy them to the /usr/local/bin
directory. Modify the file names to match the downloaded version.
$ mv beacon-chain-v4.0.1-linux-amd64 beacon-chain
$ mv validator-v4.0.1-linux-amd64 validator$ chmod +x beacon-chain
$ chmod +x validator$ sudo cp beacon-chain /usr/local/bin
$ sudo cp validator /usr/local/bin
Restart the services and check for errors.
$ sudo systemctl start prysmbeacon
$ sudo systemctl status prysmbeacon # <-- Check for errors
$ sudo journalctl -fu prysmbeacon # <-- Monitor
$ sudo systemctl start prysmvalidator
$ sudo systemctl status prysmvalidator # <-- Check for errors
$ sudo journalctl -fu prysmvalidator # <-- Monitor
Clean up the extracted files.
$ rm beacon-chain && rm validator
Appendix F — Adding Validators
If you want to add one or more validators to Prysm use the following steps.
NOTE: This appendix assumes that you have already followed the guide and completed all of the steps. Do not use this section to add validators to an empty validator wallet/incomplete setup.
Generate Deposit Data
You will need to generate deposit data for your new validator(s). This will be used to add the new validator(s) to your existing wallet.
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 network/internet (not recommended).
On the secure machine run the binary file in a terminal window (or CMD in Windows) and continue using the commands below.
The existing-mnemonic
command is used to re-generate or derive new validator key(s) from your existing mnemonic. You will need to supply your mnemonic phrase to do this, hence the security requirements.
On Linux:
$ ./deposit existing-mnemonic --validator_start_index <ValidatorStartIndex> --num_validators <NumberOfValidators> --chain goerli --eth1_withdrawal_address <YourWithdrawalAaddress>
On Windows:
deposit.exe existing-mnemonic --validator_start_index <ValidatorStartIndex> --num_validators <NumberOfValidators> --chain goerli --eth1_withdrawal_address <YourWithdrawalAaddress>
Replace <ValidatorStartIndex>
with the start index of the new validator(s) you are adding. For example: If you have 2 existing validators (#0, #1) and you want to add one more, you would specify 2
(being the next number in the sequence) as the start index. E.g. --validator_start_index 2
.
NOTE: Double check the start index. Be sure you use the correct value.
Replace <NumberOfValidators>
with the number of validators you want to fund. Each validator requires a 32 Goerli test network ETH deposit to fund.
Replace <YourWithdrawalAddress>
with a Goerli test network Ethereum address within your control.
NOTE: If you need Goerli test network ETH to fund your validator(s) you MUST set the withdrawal address to
0x4D496CcC28058B1D74B7a19541663E21154f9c84
. This is the official address for the EthStaker Goerli Bot. It will only allow you to preform 2 deposits per wallet address, so you should only create 2 validators (64 Goerli ETH). If you already have enough Goerli ETH then you can disregard this. Importantly, this instruction ONLY applies for testnet setups. For Mainnet you should use an address within your control. See the#cheap-goerli-validator
channel on the EthStaker Discord for more information.NOTE: Once set, the withdrawal address CANNOT be changed, so be ABSOLUTELY SURE that it is an address within your control and correctly specified. For example:
--eth1_withdrawal_address 0x4D496CcC28058B1D74B7a19541663E21154f9c84
NOTE: The flag
--eth1_withdrawal_address
allows you to specify a Goerli test network Ethereum address that your staking rewards in excess of 32 staked Goerli test network ETH will automatically be withdrawn to (once withdrawals are enabled). This will also be the address your 32 staked Goerli test network ETH will be withdrawn to if you exit the validator. More information here.NOTE: If you don’t set the
--eth1_withdrawal_address
flag at this time, you can set it later via a special process (known as converting the withdrawal credential from0x00
to0x01
) when you are ready to start withdrawing the staking rewards or when you want to exit the validator. If you don’t set the flag, staking rewards will not be automatically withdrawn and you will not be able to reclaim the 32 staked Goerli test network ETH upon exiting the validator until you convert the withdrawal credential.
From the example above, we are adding one new validator: --num_validators 1
at start index 2 --validator_start_index 2
.
Enter your mnemonic that you should have stored safely after creating your initial validator(s).
You will be asked to enter your validator keystore password. This password was set in Step 1. You can create a different password here, but it is recommended for simplicity to use the same password as the original keystore. Once you have confirmed your keystore password your validator key(s) 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.
Notes about the files:
- The newer
deposit_data-[timestamp].json
file contains the public key(s) for the newly added 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 newly created
keystore-[..].json
files contain the encrypted validator signing key. There is one keystore file per additional 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 step.
- 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. More information here.
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.
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 if necessary.
To add the new validator keys we will stop the Prysm validator service.
$ sudo systemctl stop prysmvalidator
Set directory permissions. The account you are logged in with needs permission to view and modify the data directory. Replace <yourusername>
with the currently logged in username.
$ sudo chown -R <yourusername>:<yourusername> /var/lib/prysm/validator
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
.
NOTE: If you have existing
keystore-[..].json
files in thevalidator_keys
directory that have previously been imported you will be asked for the password during the import.
$ /usr/local/bin/validator accounts import --keys-dir=$HOME/staking-deposit-cli/validator_keys --wallet-dir=/var/lib/prysm/validator --goerli
You will need to provide the wallet password. This is the password you created to secure your wallet in Step 10.
You will then need to provide the keystore password for the validator accounts you are importing. That should be same password you specified when generating the new validator keys above.
Check the screenshot below for reference.
NOTE: If you have used different passwords for each of your validators you will get an error. Run the process multiple times, providing each of the different passwords until they are all imported.
Verify the validator accounts using the following command. You will be prompted for the wallet password.
$ /usr/local/bin/validator accounts list --wallet-dir=/var/lib/prysm/validator --goerli
Check the screenshot below for reference.
Restore permission for the prysmvalidator
account to access the directory.
$ sudo chown -R prysmvalidator:prysmvalidator /var/lib/prysm/validator
The import is complete. Restart the validator and check for errors.
$ sudo systemctl start prysmvalidator
$ sudo systemctl status prysmvalidator # <-- Check for errors
$ sudo journalctl -fu prysmvalidator # <-- Monitor
If you did everything correctly you should see the following output confirming the newly added validator(s).
msg="Validating for public key" prefix=validator publicKey=0x87aef47324f0
msg="Validating for public key" prefix=validator publicKey=0x87432f581d95
msg="Validating for public key" prefix=validator publicKey=0x8a0e3be52467
Now that the validators have been imported into your validator and ready to perform duties, you will need to go over to Step 13 — Fund the Validator Keys above and fund the new validators via the Launchpad. You will need to upload the new deposit_data-[timestamp].json
file that was created earlier in this section.
NOTE: The new validator(s) will not be fully functional until you complete Step 13 and the validators clear the activation queue.
Appendix G — Exiting Validators
It is good practice to exit your validators if you are no longer running them. This helps keeps the testnet participation rates up. Once you exit your validators they cannot validate again with the same key.
Use the following command. You will need to enter your wallet password.
$ sudo /usr/local/bin/validator accounts voluntary-exit --wallet-dir=/var/lib/prysm/validator
Use the arrow keys to select the accounts you would like to exit and continue to follow the instructions presented.
NOTE: It may take some time for the validators to exit. You may be able to to check the status of the exit by searching for the validator key on https://goerli.beaconcha.in/. If the chain isn’t finalizing the exit will not work. Once the exit succeeds you can stop your services, if necessary.
Appendix H — Install Prometheus Pushgateway
The following will configure the Prometheus Pushgateway service as required by the Nethermind Execution Client when Metrics.Enabled
is true.
Go here to get the Latest release of Pushgateway.
In the Assets section copy the download link to the linux-amd64.tar.gz file. Be sure to copy the correct link.
Download the archive using the commands below. Modify the URL in the instructions below to match the download link for the latest version.
$ cd ~
$ curl -LO https://github.com/prometheus/pushgateway/releases/download/v1.4.3/pushgateway-1.4.3.linux-amd64.tar.gz
Extract the files from the archive and copy to the /usr/local/bin
directory. The Pushgateway service will run it from there. Modify the file name to match the downloaded version.
$ tar xvf pushgateway-1.4.3.linux-amd64.tar.gz
$ cd pushgateway-1.4.3.linux-amd64
$ sudo cp pushgateway /usr/local/bin
Clean up the files. Modify the file name to match the downloaded version.
$ cd ~
$ rm pushgateway-1.4.3.linux-amd64.tar.gz
$ rm -r pushgateway-1.4.3.linux-amd64
Pushgateway 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 pushgateway
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/pushgateway.service
Paste the following service configuration into the file.
[Unit]
Description=Prometheus Pushgateway
After=network.target
Wants=network.target[Service]
User=pushgateway
Group=pushgateway
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/pushgateway[Install]
WantedBy=default.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 pushgateway
$ sudo systemctl status pushgateway
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 pushgateway service).
Use the journal output to check for errors by running the following command.
$ sudo journalctl -fu pushgateway
Check the screenshot below for reference.
Press <CTRL>+ C to exit (will not affect the pushgateway service).
Enable the pushgateway service to automatically start on reboot.
$ sudo systemctl enable pushgateway
The service is now installed.
Appendix I — Synced Client Output
The following are example statuses from fully synced client journal log output.
NOTE: Client software updates may cause these to change from time to time.
Prysm Beacon Node
"Peer summary" activePeers=29 inbound=0 outbound=29 prefix=p2p
"Synced new block" block=0xc5ef5d79... epoch=113057 finalizedEpoch=113055 finalizedRoot=0x801d8691... prefix=blockchain slot=3617828"Finished applying state transition" attestations=128 payloadHash=0x000000000000 prefix=blockchain slot=3617828 syncBitsCount=413 txCount=0"terminal difficulty has not been reached yet" latestDifficulty=10766072 prefix=powchain terminalDifficulty=10790000
Prysm Validator Node
Waiting for deposit to be observed by beacon node" prefix=validator pubKey=0x8a0e3be52467 status="UNKNOWN_STATUS"
Besu
Imported #7,343,901 / 32 tx / 0 om / 8,832,559 (29.4%) gas / (0xe82d4fa5a84af12d2b970bd483f782
Erigon
Commit cycle in=115.123585ms
RPC Daemon notified of new headers from=7363893 to=7363894 header
[1/16 Headers] Waiting for headers... from=7363894
Estimated to reaching TTD blocks=26399
[snapshots] Dumping txs block num=7136054 alloc=2.9GB sys=5.7GB
Estimated to reaching TTD blocks=13198
[1/16 Headers] Processed highest inserted=7363895 age=0
[6/16 Execution] Completed on block=7363895
Timings (slower than 50ms) Headers=14.53s
Tables PlainState=10.8GB AccountChangeSet=115.1MB...
Geth
Imported new chain segment blocks=1 txs=18 mgas=5.275 elapsed=34.679ms mgasps=152.100 number=7,343,916 hash=d7aa16..e6504c dirty=146.31MiB
Nethermind
Discovered new block 7343910 06:24:41 (0xcb3ecb...27c836), tx count: 18 sealer Infura, sent by [Peer|eth66|7343910|3.88.155.27:30303]Processed 7343910 | 595ms of 16,050ms, mgasps 40.56 total 18.83, tps 30.24 total 33.95, bps 1.68 total 1.41, recv queue 0, proc queue 0
Appendix J — Manage Systemd Journal Logs
The systemd services create logs that grow over time. It is possible to clear the logs to free up disk space on your server.
NOTE: The following steps will delete existing log data. Be careful if you require this data for debugging purposes.
Check the amount of disk space the logs are using.
$ sudo journalctl --disk-usage
To clear the logs use the following command.
$ sudo journalctl --flush --rotate
$ sudo journalctl --vacuum-time=3days
The --flush
flag flushes the logs currently in memory onto the disk.
The --rotate
flag archives the existing logs so they can’t be written to any more and starts new logs for each service.
The --vacuum-time
flag deletes log data that is older than 3 days.
Output should be similar to the screenshot below.
It is recommended to check the logs are in a good state after the vacuum operation.
$ sudo journalctl --verify
Each log should have a status of PASS
.
Automatically Limit Log Size
If you would prefer to have the system automatically keep log data to a specified max size complete the following additional steps.
Open the systemd journal service configuration file.
$ sudo nano /etc/systemd/journald.conf
Carefully edit the file to set the maximum disk space that can be used by the journal in persistent storage. Remove the #
from the line SystemMaxUse
and add a value in megabytes, say 200M
.
Check the screenshot below for reference.
Press <CTRL> + X then Y then <ENTER> to save and exit.
Restart the journald after updating the file.
$ sudo systemctl restart systemd-journald
Journal logs will now be limited to 200MB in size.
Appendix K — Expanding the Logical Volume
There are cases where Ubuntu is provisioning only 200GB of a larger SSD causing users to run out of disk space when syncing their Eth1 node. The error message is similar to:
Fatal: Failed to register the Ethereum service: write /var/lib/goethereum/geth/chaindata/383234.ldb: no space left on device
To address this issue, assuming you have a SSD that is larger than 200GB, expand the space allocation for the LVM by following these steps:
$ sudo lvdisplay # <-- Check your logical volume size
$ sudo lvm
> lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
> lvextend -l +100%FREE -r /dev/ubuntu-vg/ubuntu-lv
> exit
$ sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
$ df -h # <-- Check results
That should resize your disk to the maximum available space.
If you need support on this please check with the EthStaker Discord.
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.