This is a step-by-step guide to staking on the Ethereum mainnet via Reth Execution Client and the Lighthouse Consensus Client. It is based on the following technologies:
- Server: Ubuntu v20.04 (LTS) x64
- Execution Client: Paradigm's Reth
- Consensus Client: Sigma Prime Lighthouse
This guide is a fork and slight adaptation of Somer Esat guide here so that it works with the new Reth Execution Client. It is intended for stakers familiar with Somer Esat style staking setup who want to try out Reth Execution Client. It also relies heavily on info you can find in the Reth Book here
Staking requires a deposit of 32 ETH + gas fees. This guide includes instructions to safely deposit your ETH for staking on the Ethereum mainnet using official methods. DO NOT send ETH anywhere without knowing what you are doing.
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. Further, this is a fork of orginal author's work and uses an experimental execution client in Alpha stage. Proceed with extreme caution.
Thanks to Somer Esat for creating the vast majority of this guide, the EthStaker Admins and Educators, the Ethereum Execution and Consensus Client teams, the Ethereum core developers and researchers, and the Ethereum staking community for all of their amazing contributions, feedback, and support.
For technical support reach out to:
- The EthStaker community on Reddit or Discord. Knowledgeable and friendly community passionate about staking on Ethereum.
- The Lighthouse Consensus Client team Discord.
- The Reth Execution Client team Discord.
This guide assumes some knowledge of Ethereum, ETH, staking ETH, Linux, and Browser Wallet.
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. Ethereum browser wallet (Metamask etc) installed and configured on a computer with a desktop (Mac, Windows, Linux, etc.) and a web browser (Brave, Safari, FireFox, etc.).
If moving from a testnet setup to a mainnet setup it is strongly recommended that you start on fresh (newly installed) server instance. This guide has not been tested for migration scenarios and does not guarantee success if you are using an existing server instance with previously installed testnet software.
In general the following are required for good staking performance. More information here and here.
- A relatively modern multi-core CPU.
- 16GB RAM (32GB is better, and required in some cases).
- An SSD (NVMe is better) of at least 1TB (2TB is strongly recommended).
- A stable internet connection with sufficient download speed and monthly data allowance.
For fastest sync of reth full node on remote machine the reth book recommends using https://latitude.sh bare metal cloud provider of s2.small.x86 type (with RAID0 selected). It really does perform great synching mainnet quickly (though it's never going to be as cheap as running with local hardware at home).
As demand grows for staking, the queue to register new validators increases. Based on various factors, the Ethereum PoS network allows a fixed number validators to join per day. Depending on demand it might be mins, hours, days, weeks, or even months until your deposit becomes active and eligible for validation duties. This means once you queue your validator to join the network (by depositing your 32 ETH) it won’t be eligible to participate in staking or to earn staking rewards until it has activated.
NOTE: As stated at the beginning of this guide, DO NOT deposit your ETH without understanding what you are doing. DO NOT send your ETH to the Ethereum deposit contract without following the instructions in this guide.
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 Execution Client and the Consensus Client are required to stake.
The conceptual flow through the guide is:
- Generate the staking Deposit Data and Validator Keystore(s)
- Prepare the Ubuntu Server (updates, firewall, security, etc.)
- Set up a Reth Execution Client node
- Set up the Lighthouse Consensus Client
- Wait for Execution and Consensus Clients to fully sync
- Deposit 32 ETH to activate the staking Validator(s) Let’s get started!
In order to participate in staking it is necessary to use a tool to generate data files based on the number of validators you’d like to fund and operate.
NOTE: If you have already generated your staking Deposit Data and Validator Key(s) you can skip this step.
Each validator will require a deposit of 32 ETH in order to activate it on the Ethereum mainnet. You should have sufficient ETH in your MetaMask wallet to fund each validator. For example if you plan to run 2 validators you will need to have (32 x 2) = 64 ETH plus some extra to cover the gas fees. The ETH deposit will happen later in the guide after everything else is up and running.
The Staking Deposit CLI is a stand-alone tool that can be run on either Windows or Linux. Besides staking data files, it generates a mnemonic which is sensitive, so there are some security best practices discussed below.
Go here to get the Latest version of the Staking Deposit CLI (command line interface) 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.7.0/staking_deposit-cli-fdab65d-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 after renaming it.
Modify the file name to match the downloaded version.
$ tar xvf staking_deposit-cli-fdab65d-linux-amd64.tar.gz
$ mv staking_deposit-cli-fdab65d-linux-amd64 staking-deposit-cli
$ rm staking_deposit-cli-fdab65d-linux-amd64.tar.gz # <-- Clean up
$ cd staking-deposit-cli
There should be a binary file (executable) in the archive named deposit.
The Staking Deposit CLI tool generates a mnemonic key. It is used to generate the staking data and (eventually) the withdrawal key(s) as well. This mnemonic must be handled securely to avoid any risk of it being exposed. There are different ways to proceed; two options are provided below.
Option 1: Air-Gapped Machine (recommended) — Copy the deposit binary file to a USB drive. Connect the drive to a fully air-gapped machine (never previously connected to a network or the internet) and 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.
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 use the commands below.
On Linux:
$ sudo ./deposit new-mnemonic --num_validators 2 --chain mainnet --eth1_withdrawal_address <YourWithdrawalAddress>
On Windows:
deposit.exe new-mnemonic --num_validators 2 --chain mainnet --eth1_withdrawal_address <YourWithdrawalAddress>
Replace YourWithdrawalAddress with an Ethereum address within your control.
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 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
NOTE: The flag --eth1_withdrawal_address allows you to specify an Ethereum address that your staking rewards in excess of 32 staked ETH will automatically be withdrawn to (once withdrawals are enabled). This will also be the address your 32 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 from 0x00 to 0x01) 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 in excess of 32 ETH will not be automatically withdrawn and you will not be able to reclaim the 32 ETH deposit upon exiting the validator until you convert the withdrawal credential.
Once you execute the above steps on your platform of choice, confirm your withdrawal address, 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 import the validator(s) into the Consensus Client.
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 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(s) will be created.
The validator(s) and deposit data file are created at the specified location. The contents of the directory are shown below.
Notes on 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 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 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 CLI tool and your mnemonic via the existing-mnemonic command. More information here.
Now that you have generated the deposit data, keystore file(s), validator password, and the mnemonic move on to set up the Ubuntu server.
DO NOT DEPOSIT any ETH at this moment.
It is important to complete and verify your staking setup first. If your ETH deposits become active and your staking setup is not ready, inactivity penalties will be deducted from your staked ETH balance.
Using a SSH client, connect to your Ubuntu server. If you are logged in as root (usually denoted in this format: root@YourServerName:~#) 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 (usually denoted in this format: YourUserName@YourServerName:~$) 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> .
Make sure the 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
Security is important. This is not a comprehensive security guide, just some basic settings.
Port 22 is the default SSH port and a common attack vector. Change the SSH port to avoid this.
NOTE: if you must use port 22 you can skip this part (not recommended). Sometimes reconfiguring the default ssh port is annoying and if you're on e.g. testnet then it's not worth the hassle.
Choose a port number between 1024–49151 and run the following command to check is not already in use.
$ sudo ss -tulpn | grep ':YourSSHPortNumber'
Example:
$ sudo ss -tulpn | grep ':6673'
A blank response indicates not in use, a red text response indicates it is in use: try a different port.
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.
Port <YourSSHPortNumber>
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.
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.
UFW should be installed by default. The following command will ensure it is.
$ sudo apt install ufw
Explicitly apply the defaults: inbound traffic denied, outbound traffic allowed.
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
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
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 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
Allows P2P connections with Consensus Client peers for actions on the Beacon Chain Node (port 9000).
NOTE: If you are hosting your Ubuntu instance locally your internet router may need to be configured to allow incoming traffic on port 9000 as well.
$ sudo ufw allow 9000
Enable the firewall and verify the rules have been correctly configured.
$ sudo ufw enable
$ sudo ufw status numbered
Check the screen shot below for reference.
Log out and SSH back in again to confirm everything is working correctly.
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, at the cost of some disk space. It is particularly useful for clients that require large amounts of memory when syncing or running. More information here.
NOTE: This step should be considered optional. Disk space is at a premium and while having the swap can be useful, it comes at the cost of multiple gigabytes of storage. The advantage is that it may prevent out of memory (OOM) incidents, especially if using the Erigon Execution Client.
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
Press <CTRL> + X then Y then <ENTER> to save and exit.
The swap file is now configured. You can monitor using the htop command (Press <CTRL> + C to exit.)
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
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 the Execution and Consensus clients so they can authenticate incoming and outgoing messages.
See Reth Book here for more detailed info all about the reth client.
Install rust language
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Verify rust installation
$ source $HOME/.cargo/env
$ cargo version
The cargo version command should print a version for example cargo 1.68.2
Install reth dependencies for Ubuntu:
$ sudo apt-get install libclang-dev pkg-config build-essential
Finally, build reth:
$ git clone https://github.com/paradigmxyz/reth
$ cd reth
$ cargo install --locked --path bin/reth --bin reth
Compilation will take some time (around 10 minutes).
First create the data directory. This is required for storing the Ethereum blockchain data.
$ sudo mkdir -p /home/datadir/reth
Set directory permissions. Your user account <yourusername> needs permission to modify the data directory.
In the steps below, replate <yourusername> with the user name you chose in Step 2
$ sudo chown -R <yourusername>:<yourusername> /home/datadir/reth
Create a systemd service config file to configure the service.
$ sudo nano /etc/systemd/system/reth.service
Paste the following service configuration into the file.
[Unit]
Description=Reth Execution Client (Mainnet)
After=network.target
Wants=network.target
[Service]
User=<yourusername>
Group=<yourusername>
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
ExecStart=/home/<yourusername>/.cargo/bin/reth node \
--full \
--datadir /home/datadir/reth \
--authrpc.jwtsecret /var/lib/jwtsecret/jwt.hex \
--http
[Install]
WantedBy=default.target
NOTE: Remember to fill in <yourusername> with the user you set in Step 2 in the file above (it appears in three places)
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).
--full this specifies syncing a pruned full node. If you want to sync an archive node, remove this line in the service file.
--datadir /home/datadir/reth this is the directory where historical blockchain data gets stored (bulk of disk usage). I changed the directory here from the usual /var/lib/reth pattern in Somer Esat guides because NVMe with RAID0 on latitude.sh will mount the disk to the /home directory so if you want to use the NVMe disk space, you'll need to put the datadir somewhere in the /home directory (not /var/lib)
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 reth
$ sudo systemctl status reth
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 reth service).
Use the journal output to follow the progress or check for errors by running the following command.
$ sudo journalctl -fu reth
Press <CTRL>+ C to exit (will not affect the reth service)
NOTE: The reth execution client sync will NOT begin immediately, you may see error about needing a consesnus client. You'll need to configure and start the beaconchain service (next steps below) before reth will actually start syncing
Enable the reth service to automatically start on reboot.
$ sudo systemctl enable reth
You should now have installed, configured, and run the Reth Execution client. Great job! Reth should be running and waiting to find a Consensus cleint to start it's sync. Next we will configure the Consensus client.
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 here and identify the Latest release. It is at the top of the page.
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.
NOTE: There are two types of binaries — portable and non-portable. The difference is explained here. Portable works on a broader set of hardware but comes with a 20% performance cost.
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/v4.5.0/lighthouse-v4.5.0-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-v4.5.0-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-v4.5.0-x86_64-unknown-linux-gnu.tar.gz
$ rm lighthouse
NOTE: It is necessary to follow a specific series of steps to update Lighthouse.
Configure the Lighthouse 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
Create a directory to store the validator data.
$ sudo mkdir -p /home/datadir/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.
$ sudo /usr/local/bin/lighthouse --network mainnet account validator import --directory $HOME/staking-deposit-cli/validator_keys --datadir /home/datadir/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 Step 1.
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: /home/datadir/lighthouse/validators.
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.
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.
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 /home/datadir/lighthouse/beacon
$ sudo chown -R lighthousebeacon:lighthousebeacon /home/datadir/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 (Mainnet)
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 mainnet \
--datadir /home/datadir/lighthouse \
--http \
--execution-endpoint http://127.0.0.1:8551 \
--execution-jwt /var/lib/jwtsecret/jwt.hex \
--checkpoint-sync-url CheckpointSyncURL
[Install]
WantedBy=multi-user.target
NOTE: Be sure to set the CheckpointSyncURL above to a valid checkpoint sync URL. See below for more information.
Notable flags:
bn subcommand instructs the lighthouse binary to run as a beacon node.
--prune-payloads (Not shown above). This is a flag to set the pruning status on the Lighthouse database. When peers request blocks from Lighthouse it can either get them from the Lighthouse database or the EC. Getting from EC is overhead for the EC which can cause problems if performance is an issue. Using --prune-payloads false will allow peers to get blocks from the Lighthouse database, avoiding the extra call to the EC. Conversely you can save disk space by pruning using --prune-payloads true. More information here.
--http Exposes an http endpoint which is used by the validator client to connect to the beacon node.
--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.
--execution-jwt /var/lib/jwtsecret/jwt.hex The path to the JWT file that is required for authenticated communication between the Execution and Consensus clients.
--checkpoint-sync-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.
--logfile-max-number X and --logfile-max-size Y (Optional, not shown above). Add these flags to adjust log file settings. Max number is number of log files, and max size is the size of each log file. Default requires 1GB of storage for logs. To reduce this to 50MB, for example, use the following settings: --logfile-max-number 2 and --logfile-max-size 25.
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 shortly.
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
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
Your cleints (the beacon node and the reth node) should now both be running and syncing. The reth sync will take a while. You can monitor progress now with:
$ sudo journalctl -fu reth
You should see sync making progress!
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 Step 10 the validator import process created the following directory: /home/datadir/lighthouse/validators. Set directory permissions so the lighthousevalidator account can modify that directory.
$ sudo chown -R lighthousevalidator:lighthousevalidator /home/datadir/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 (Mainnet)
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 mainnet \
--datadir /home/datadir/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 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
Notable flags:
vc subcommand instructs the lighthouse binary to run as a validator node.
--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.
--graffiti “<yourgraffiti>" Replace with your own graffiti string (max 32 characters). 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 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
You should now have installed, configured, and run the Lighthouse Consensus Client. Great job! Next we will perform the deposit to activate your validators on the network.
Now that the Consensus Client is up and running, to actually begin staking on the Ethereum network you will need to deposit ETH to fund your validators.
NOTE: If you have already submitted your staking deposits you can skip this step.
This step involves depositing the required amount of ETH to the Ethereum deposit contract. DO NOT SEND ETH TO THE DEPOSIT CONTRACT. Rather, this is done in a web browser running your MetaMask (or other) wallet via the Ethereum 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://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 if you agree, 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 (or one of the other supported wallets), log in, select the account where you have your ETH and click Continue.
Your MetaMask balance will be displayed. The site will allow you to continue if you have selected Mainnet and you have sufficient ETH balance.
A summary shows the number of validators and total amount of ETH required. Tick the boxes if you agree and click continue.
If you are ready to deposit click on Initiate All Transactions.
This will pop open MetaMask (or one of the other supported wallets) where you can confirm each transaction.
Once all the transactions have successfully completed you are done!
Congratulations you have deposited your stake!
Newly added validators can take a while to activate. You can check the status of your keys with these steps:
Copy your MetaMask (or other) wallet address used to make the deposit. Go here: https://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.
That’s it. You now 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. Probably a good time to get a fresh beverage and hydrate.
Congratulations: You are officially an Ethereum Staker!
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, or ncdu / to monitor resources on the local machine
- Get familiar with beaconcha.in so you can monitor your validators
- Use the beaconcha.in mobile app to monitor your validators
- Check my testnet guides for details on setting up Grafana monitoring
- Join the Ethstaker and and Lighthouse Discord for important notifications
- Share feedback on Discord (somer112), Twitter, or Reddit
- Help others on the EthStaker Discord or EthStaker Reddit
- Share this guide with your friends!
- Tips appreciated: somer.eth ( and kassandra.eth :) )
(see Somer Esat Appendices for further info)