DEVELOPER PERSPECTIVE | How to Become a Solo Ethereum Validator

Think about it for a sec,

A blockchain is just a large single database that is not owned by anyone but can be written to by anyone and anything written into it, cannot be deleted. You need to have a copy of the database on your computer if you are to write to that database. 

 

 

So, you’ve finally realized how much of a good investment becoming an Ethereum validator is and you’ve decided to give it a shot to see how much you can bag. 

Well, congrats first of all. That is a huge undertaking and I, on behalf of Ethereum community, thank you (for whatever reason you have to becoming a validator — earn block rewards, make Ethereum more decentralized etc) for your bold initiative.

 

 

In that same spirit of decentralization, we’ll be looking into how to be a solo validator or fancily known as to solo stake on Ethereum

 

 

We won’t look into other ways of staking like liquid staking, staking as a service or the likes. I mean come on, you’ve decided to be a validator, why not do it the cypherpunk way, huh.

 

 

Let’s get familiar with some words first:-

 

 

Ethereum is a Proof of Stake blockchain since “The Merge” happened back in 15th September 2022 transitioning Ethereum from Proof-of-Work (PoW) to Proof-of-Stake (PoS)

 

 

What this means is that how Ethereum achieves consensus changed completely. 

 

 

Remember how we said a blockchain is just a large single database on a bunch of computers, well, the state of that database has to be known by all the computers in the network at all times. Computers (nodes) participating in the network have to agree on what is the current state of the database, i.e achieve consensus!

Ethereum nodes don’t need to solve complex Mathematical problems to achieve consensus as was the case in PoW but rather, they lock up ether upfront essentially saying,

 

“Hey, I am willing to be a validator who will be adding blocks and verifying transactions and if I misbehave in any way while undertaking this task, you can take the ether I deposited upfront (my stake) as punishment for this misbehavior. If I behave properly, you reward me with newly created ether!”

 

 

When more than two thirds of the validators agree on the current state of the above said database, the blockchain state is considered finalized!

 

 

Why two thirds of all validators?

 

 

Imagine if we were to wait for all validators (at the time of writing, Ethereum has 1,031,682 active validators) in the network to agree on the state of the blockchain? The speed of the blockchain finalization would be very slow making Ethereum essentially unusable. The finalization speed of a blockchain is as fast as its slowest node and considering Ethereum is maximally decentralized (meaning it can be run on regular consumer hardware that is generally slower than institutional mega faster computers) we have to account for the slowest node. So two thirds doesn’t seem like a bad number to wait for after this not so compelling argument am I right … 😂😂😂

The security model of Ethereum can now be summarised as “Humans are rational creatures who want to make profits and will make rational decisions to realise those profits.They therefore will not misbehave because if they misbehave, the Ether they locked upfront (their stake), will be slashed!”

 

Achieving security via capitalism am I right?

 

First things first,

What the hell is an Ethereum node?

 

An Ethereum node is a computer running Ethereum software called an Ethereum client. That’s it. Trust me, that’s actually it. That’s as simply as it can get, no fancy big words, no nothing. That’s it! Ethereum nodes.

These nodes are what make up the Ethereum blockchain — A bunch of computers running similar software that can communicate to each other.

Anyone can run an Ethereum node but there is no financial benefit to oneself running one. Don’t get me wrong, there definitely are benefits of running a node (not to be confused with being a validator) like:-

1. Not needing to trust any other nodes in the network because you can verify all transaction data yourself — true cypherpunk nature of “Do not trust, verify!”
2. You can use dApps more securely and privately because you don’t have to leak your wallet addresses and wallet balances to intermediary sketchy nodes.
3. You can connect your Ethereum wallet directly to the RPC endpoint of your own Ethereum node. This gives you sole access and priority to get your transactions included instead of having to compete with everyone else via public RPC endpoints.
4. You enforce the consensus rules so you can’t be tricked into accepting blocks that don’t follow the rules in case of a black swan event where all nodes decide to collude. In such an unlikely black swan event, a social recovery can be performed by nodes by choosing to follow the honest chain
5. More nodes in the network results in a more diverse and robust network, making it harder for the entire network to fail or censor transactions.
6. Full nodes provide access to blockchain data for lightweight clients that depend on it (i.e. Light Clients). This helps users access and interact with Ethereum in a secure and decentralized manner without having to sync the full blockchain, unlocking a wider range of use cases.

By generating a specialised ‘magic’ signing key and staking 32 ETH into a smart contract linking to this key, you turn your Ethereum node into a validator.

Validators are ‘activated’ nodes that process the transactions of users and set them in stone (i.e., finalisation).

The validity of each transaction is voted on by all validators (sign attestations) in the Ethereum network and vouched for by their ETH staked. 

Because validators are processing and vouching for transactions of users, they are rewarded for performing their jobs well and penalized when they misbehave. If validators are found to be dishonest, malicious or grossly negligent, they will have their stake slashed for up to the entire amount and expelled from the network.

This incentivises validators to be and remain honest.

So how do you solo stake on Ethereum?

 

You need to stake 32 ETH for you to become a validator on Ethereum, 32 ETH is equivalent to Ksh. 13,998,370.65 at the time of writing where 1 ETH = Ksh. 437,449.08 — how much is 1 ETH when you’re reading this?

 

 

How did they even arrive at the 32 ETH requirement? It is ingrained into the code that computers run (client software) to participate on the Ethereum blockchain

You then need to run specific client software to become a validator. Below are examples of the software to run:-

1. Prysm (https://prysmaticlabs.com/)
2. Lighthouse (https://lighthouse-book.sigmaprime.io/)
3. Teku (https://consensys.io/teku)
4. Nimbus (https://nimbus.team/)
5. Lodestar (https://lodestar.chainsafe.io/)

The above software to run are collectively called Consensus Layer software because they are the ones which achieve consensus on Ethereum — decide on the state of the blockchain

Now that you know what client software to run and you have 32 ETH, you are ready to earn those sweet sweet block rewards right? Well, yes, but as usual, the devil is in the details. Let’s see how this can easily become a very complex task.

 

 

Solo Staking

Solo staking involves fully running your own node and you fully receiving block rewards without sharing them with anyone else.

Minimum hardware requirements for you to solo stake are:-

1. CPU: Quad core
2. RAM: 32GB
3. Storage: 2TB NVME SSD, >500 read IOPS, >1700 write IOPS, non-QLC (consider 4TB NVME SSD, >5000 read IOPS, >1700 write IOPS, non-QLC if you want a no stress setup)
4. Network requirements (Check with your ISP):
   1. Volume: Uncapped or at least 2TB per month
   2. Speeds: At least 500mb/s shared – Your validator node needs at least 10mb/s of dedicated internet speed
   3. IP address: Static if possible
5. Power: Uninterruptible power supply (UPS)

The hardware requirements may seem daunting at first but have you seen Solana’s hardware requirements?

 

 

Remember our food for thought:

“A blockchain is just a large single database that is not owned by anyone but can be written to by anyone and anything written into it, cannot be deleted. You need to have a copy of the database on your computer if you are to write to that database”

 

 

Yeah, let’s stick with that and see how each hardware component affects performance.

 

 

Component	Impact on performance
CPU	– Affects block execution speed (4s limit) – Will miss attestations (votes) and block proposals if this is too slow
RAM	– Services will shutdown/restart abruptly if the device runs out of memory, causing you to lose data. This can lead to database corruption, and in the worst case, require you to resync your validator node from scratch missing attestations for 2 to 3 days in the meantime – As the Ethereum network grows with more activity (e.g, more addresses, smart contracts and transactions), there will be an increasing demand on your node’s memory to maintain the chain state and propagate transactions to other nodes.
Storage	– Read and write speeds (IOPS) are the main bottleneck for block execution speeds
Network	– Affects latency on receiving/sending blocks, which affects overall block execution speed (4s limit) – Although not compulsory, having a static IP address improves discoverability by other nodes in the network and prevents issues of low peer count – Some ISPs also prevent port forwarding (for remote access to your node) if you don’t  have a static IP address
Power	– Sudden power disruptions, e.g lightning, power trips will cause your node to shutdown uncleanly, causing you to lose data. This can lead to database corruption and in the worst case, require you to resync your validator node from scratch missing attestations for 2 to 3 days in the meantime.

 

 

Remember when we said that you need to run a consensus layer client like Lighthouse, well, you also need to run an execution layer client.

What even is an execution layer client? I’m glad you asked…

An execution layer client in Ethereum is the software that executes smart contracts and transactions. This is where your favourite dApps like aave, uniswap and that favourite meme coin of yours that you’re waiting for it to moon are executed. This execution layer is what makes up the Ethereum Virtual Machine(EVM)

Examples of execution layer clients include:-

• geth
• reth
• nethermind
• besu
• erigon

 

NB: Improve Ethereum’s resilience by using a minority execution client. What happens if a black swan event happens and geth, which has a market share of around 55% at the time of writing— meaning more than half of Ethereum execution clients run geth — has a critical bug? Does this mean that Ethereum will cripple? 

 

Block validation goes something like this:-

1. Execute smart contracts on the EVM. Made possible because the validator is running an execution layer client like reth
2. That execution changes the state of the blockchain
3. The changes have to be communicated across the entire chain — remember our one big database — so that a consensus is reached upon and all nodes agree on what the state of the chain is at that moment. This means that the execution layer has to somehow communicate with the consensus layer 

 

 

Let’s take an example of setting up reth (execution layer client) with Lighthouse (a consensus layer client).

 

The below steps from here assume that you have a basic grip of working around the Linux environment, yes, including typing commands on the terminal that you copied from StackOverflow without understanding what they exactly do but hey, they work.

 

ls -al | grep | xxd | echo -n

Oh, you didn’t understand a thing I just typed?

If ls -al | grep | xxd | echo -n looks like Mandarin to you, it’s time to dust off those books and brush up on your Linux commands. No need to be a guru like me (yes, I use Arch BTW), but come on, at least learn your cd from your rm -rf /!

We will be working on a machine with Ubuntu installed on it.

We first need to create a JSON Web Token (JWT) that will allow the execution layer software (reth) and the consensus layer software (Lighthouse) to communicate with each other.

 

Run the following commands one line at a time to create a directory called jwtsecret and generate the JWT file jwt.hex inside the directory jwtsecret

> sudo mkdir -p /var/lib/jwtsecret

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

We will be pointing the configuration files of the execution and consensus clients to this JWT file (jwt.hex) later.

 

Download reth and configure the service

Download the latest version of reth here (https://github.com/paradigmxyz/reth/releases) and its digital signature (.asc) file for verifying the checksum to ensure that the downloaded file has not been tampered with.

 

 

> curl -LO https://github.com/paradigmxyz/reth/releases/download/v1.0.0/reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz

> curl -LO https://github.com/paradigmxyz/reth/releases/download/v1.0.0/reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz.asc

 

 

Run the checksum verification as below

> gpg –keyserver keyserver.ubuntu.com –recv-keys 50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E

 

 

> gpg –verify reth-v0.1.0-alpha.23-x86_64-unknown-linux-gnu.tar.gz.asc reth-v0.1.0-alpha.23-x86_64-unknown-linux-gnu.tar.gz

 

 

Expected output: Verify output of the checksum verification

“`

gpg: Signature made Mon 24 Jun 2024 01:33:15 PM EAT

gpg:   using EDDSA key 50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E

gpg: Good signature from “Georgios Konstantopoulos (Reth signing key for 2024 and on) <[email protected]>” [unknown]

gpg: WARNING: This key is not certified with a trusted signature!

gpg:    There is no indication that the signature belongs to the owner.

 

 

Primary key fingerprint: 50FB 7CC5 5B2E 8AFA 59FE  03B7 AA5E D56A 7FBF 253E

“`

Verify the release signing key (–recv-keys) here (https://reth.rs/installation/binaries.html#signature-verification)

 

If the checksum is verified, extract the files and move them into (/usr/local/bin) directory.

Then clean up the working directory.

“`

> tar xvf reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz

> sudo cp reth /usr/local/bin

> rm -r reth reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz.asc reth-v1.0.0-aarch64-unknown-linux-gnu.tar.gz

“`

Create an account called `reth` without server access for reth(the execution layer software) to run as a background service. This type of user account will not have root access so it restricts potential attackers to only the reth service in the unlikely event that attackers manage to infiltrate via a compromised client update.

> sudo useradd –no-create-home –shell /bin/false reth

 

 

Create a directory for reth (the execution layer software) to store the blockchain data of the execution layer. Then set the owner of this directory to reth (the user account) so that this user can read and write to the directory.

> sudo mkdir -p /var/lib/reth

> sudo chown -R reth:reth /var/lib/reth

 

 

Create a systemd configuration file for the reth service to run in the background.

 

 

> sudo vi /etc/systemd/system/reth.service

 

 

Paste the configuration parameters below into the file:

 

 

“`

[Unit]

Description=Reth Execution Client (Holesky)

After=network.target

Wants=network.target

 

 

[Service]

User=reth

Group=reth

Type=simple

Restart=always

RestartSec=5

ExecStart=/usr/local/bin/reth node \

  –chain holesky \

  –datadir=/var/lib/reth \

  –log.file.directory=/var/lib/reth/logs \

  –authrpc.jwtsecret=/var/lib/jwtsecret/jwt.hex \

  –full \

  –port 30304 \

  –http \

  –http.api eth,web3,net,txpool,debug,trace \

  –http.addr <Internal_IP_address> \

  –http.port 8547 \

  –ws \

  –ws.addr <Internal_IP_address> \

  –ws.port 8548 \

  –metrics 127.0.0.1:6060

  

[Install]

WantedBy=default.target

“`

Once you’re done, save with ESC → ENTER → :wq → ENTER

Understand and review your configuration summary and amend if needed.

reth configuration summary:

1. –chain: Run the on the Holesky testnet
2. –datadir: The directory for reth to store the blockchain data of the execution layer
3. –log.file.directory: The path to put log files in
4. –authrpc.jwtsecret: The directory pointing to the JWT secret we generated earlier (jwt.hex)
5. –full: Run a full node.
6. –port: Sets the port used for peer-to-peer communication. Remember that nodes have to communicate to each other on the network. Default to port number 30303.
7. –http: Enables the HTTP-RPC service on http and websocket. This is so that DVT clients such as the Diva service can connect to your execution client 
8. –http.api: RPC modules to be configured for the HTTP server.
9. –http.addr: Sets the IP address to connect to the JSON RPC service. Use the internal IP address of your device here (check by running `ip a`)  e.g. 192.168.x.x. Defaults to 127.0.0.1 otherwise
10. –http.port: Sets the port to connect to the HTTP-RPC service that will be used by the DVT services. You may choose any unused port number but remember to allow incoming connections into your chosen port in your firewall (ufw) rules. Defaults to 8545.
11. –ws: ws=Websocket. Enable the WS-RPC server. This is so that DVT clients can connect to your execution client.
12. –ws.addr: Websocket server address to listen on. Used by DVT clients.
13. –ws.port: Websocket server port to listen on. Used by DVT clients.
14. –metrics: Enable monitoring metrics on the Reth service.

 

 

Start reth

Reload the systemd daemon to register the changes made, start reth and check its status to make sure its running.

> sudo systemctl daemon-reload

> sudo systemctl start reth.service

> sudo systemctl status reth.service

Expected output: The output should say reth is “active (running)”. Press CTRL+C to exit and reth will continue to run. It should take around 6 hours for reth to sync on the Holesky testnet.

 

 

Use the following command to check the logs of reth’s syncing process. Watch out for any warnings or errors.

> sudo apt install ccze -y

> sudo journalctl -fu reth -o cat | ccze -A

 

 

Expected output

Press CTRL+C to exit.

See here(https://geth.ethereum.org/docs/fundamentals/logs) for more details on how to interpret and understand reth journalctl logs

 

 

If the reth service is running smoothly, we can now enable it to fire up automatically when rebooting our node.

> sudo systemctl enable reth.service

 

 

Expected output:

> Created symlink /etc/systemd/system/default.target.wants/reth.service → /etc/systemd/system/reth.service.

 

 

reth documentation: https://reth.rs/

 

 

Set up and configure consensus layer client.

The steps will look oddly familiar and more or like the same as for setting up the execution layer client discussed above

Download the latest version of Lighthouse here (https://github.com/sigp/lighthouse/releases) and run the checksum verification process to ensure that the downloaded file has not been tampered with.

> curl -LO https://github.com/sigp/lighthouse/releases/download/v5.2.1/lighthouse-v5.2.1-x86_64-unknown-linux-gnu.tar.gz

> curl -LO https://github.com/sigp/lighthouse/releases/download/v5.2.1/lighthouse-v5.2.1-x86_64-unknown-linux-gnu.tar.gz.asc

 

 

Run the checksum verification process.

> gpg –keyserver keyserver.ubuntu.com –recv-keys 15E66D941F697E28F49381F426416DC3F30674B0

 

 

> gpg –verify lighthouse-v5.1.3-x86_64-unknown-linux-gnu.tar.gz.asc lighthouse-v5.1.3-x86_64-unknown-linux-gnu.tar.gz

Verify the release signing key (–recv-keys) in the first command above in the releases page here (https://lighthouse-book.sigmaprime.io/).

Expected output: Verify output of the checksum verification.

“`

gpg: Signature made Mon 24 Jun 2024 01:40:15 PM EAT

gpg:                using RSA key 15E66D941F697E28F49381F426416DC3F30674B0

gpg: Good signature from “Sigma Prime <[email protected]>” [unknown]

gpg: WARNING: This key is not certified with a trusted signature!

gpg:          There is no indication that the signature belongs to the owner.

 

 

Primary key fingerprint: 15E6 6D94 1F69 7E28 F493  81F4 2641 6DC3 F306 74B0

“`

If the checksum is verified, extract the files and move them into (/usr/local/bin) directory. Then clean up the working directory

 

 

> tar xvf lighthouse-v5.1.3-x86_64-unknown-linux-gnu.tar.gz

> sudo cp lighthouse /usr/local/bin

> rm -r lighthouse*

 

 

NOTE: We will be running the consensus client and validator client of Lighthouse as separate services so that there is more flexibility to configure a failover node for maximum uptime when you decide it is needed.

 

Create an account (lighthouse) without server access for the Lighthouse Consensus Client and Validator Client to run as a background service. This type of user account will not have root access so it restricts potential attackers to only the Lighthouse Consensus Client and Validator Client services in the unlikely event that they manage to infiltrate via a compromised client update.

 

 

> sudo useradd –no-create-home –shell /bin/false lighthousebeacon

Create a directory for Lighthouse to store the blockchain and validator data of the Consensus layer.

Move the `validator_keys` directory into this folder. Then set the owner of this directory to the `lighthouse` so that this user can read and write to the directory.

> sudo mkdir -p /var/lib/lighthouse_beacon

> sudo chown -R lighthousebeacon:lighthousebeacon /var/lib/lighthouse_beacon

 

 

> sudo chmod 700 /var/lib/lighthouse_beacon

If there are no errors, create a systemd configuration file for the Lighthouse Consensus Client service to run in the background.

 

 

> sudo vi /etc/systemd/system/lighthousebeacon.service

Paste the configuration parameters below into the file:

“`

[Unit]

 

 

Description=Lighthouse Beacon Node (Holesky)

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 holesky \

 –datadir /var/lib/lighthouse_beacon \

 –execution-endpoint http://127.0.0.1:8551 \

 –execution-jwt /var/lib/jwtsecret/jwt.hex \

 –checkpoint-sync-url=https://holesky.beaconstate.ethstaker.cc/ \

 –metrics \

 –metrics-port 8009 \

 –validator-monitor-auto \

 –port 9001 \

 –http \

 –http-port 5051 \

 –http-address <Internal_IP_address> \

 –builder http://127.0.0.1:18550 

 

 

[Install]

 

 

WantedBy=multi-user.target

 

 

“`

Once you’re done, save with ESC → ENTER → :wq → ENTER

Understand and review your configuration summary and amend if needed.

Lighthouse Consensus Client configuration summary:

–network: Run the Consensus Client service on the ETH Holesky testnet

–datadir: Specify the directory for Lighthouse to store data related to the consensus client

–execution-endpoint: URL to connect to the execution layer client

–execution-jwt: File path to locate the JWT secret we generated earlier

–checkpoint-sync-url: Enables nearly instant syncing of the Consensus Client by pointing to one of the checkpoint sync URLs here – https://eth-clients.github.io/checkpoint-sync-endpoints/

–metrics: Enable monitoring of Consensus Client metrics

–metrics-port: Port to connect to the metrics server. Used by Prometheus & Grafana for monitoring.

–validator-monitor-auto: Provides additional logging and metrics for locally controlled validators

–port: Sets the port for peer-to-peer communication. Defaults to 9000.

–http: Allows the validator client to connect to this consensus client. Also allows monitoring endpoints to pull metrics from this service

–http-port: Sets the port to connect to the consensus client

–http-address: Sets the IP address to connect to the REST API of the consensus client that will be used by the DVT clients. Use the internal IP address of your device here (check by running ip a) – e.g. 192.168.x.x. Defaults to 127.0.0.1 otherwise

–builder: URL to connect to external builders (e.g. MEV relays)

 

 

Start the Lighthouse consensus client

Reload systemd to register the changes made, start the Lighthouse Consensus Client service and check its status to make sure its running.

 

 

> sudo systemctl daemon-reload

> sudo systemctl start lighthousebeacon.service

> sudo systemctl status lighthousebeacon.service

 

 

Expected output: The output should say Lighthouse Consensus Client is “active (running)”. Press CTRL+C to exit and Lighthouse Consensus Client will continue to run. It should take just a few minutes for Lighthouse to sync on Holesky.

Use the following command to check the logs of Lighthouse Consensus Client’s syncing process. Watch out for any warnings or errors.

 

 

> sudo journalctl -fu lighthousebeacon -o cat | ccze -A

Expected output:

Press CTRL +C to exit monitoring.

If the Lighthouse Consensus Client service is running smoothly, we can now enable it to fire up automatically when rebooting the node.

 

 

> sudo systemctl enable lighthousebeacon.service

 

 

Verify the initial state roots (checkpoint sync)

1. Go to https://holesky.beaconcha.in/ on your browser and search for the slot number (slot).
2. Verify the Block Root and State Root with your journalctl output
3. journalctl output

 

 

Lighthouse documentation is found at (https://lighthouse-book.sigmaprime.io/intro.html)

 

Validator Key Generation

A validator key refers to the cryptographic keys used by validators on Ethereum. These keys are crucial for validators to perform their duties, including proposing and attesting(fancy word for voting) to blocks. There are two primary types of keys associated with validators:

1. Validator Key (or Signing Key):
   • This key is used for signing attestations (fancy word for votes) and proposing blocks.
   • It ensures that a validator can prove its actions and maintain the integrity of the validation process.
   • It is a hot key, meaning it needs to be online and operational to participate in the consensus process.
2. Withdrawal Key:
   • This key is used for managing and withdrawing the validator’s staked funds.
   • When you want to withdraw your staked ETH and those sweet sweet block rewards that you’ve gotten after you’ve done consensus for a while, you use this key
   • It is a cold key, meaning it is meant to be kept offline to enhance security and is only used when needed to withdraw or move the staked assets.

So how do you generate these 2 keys? I’m glad you asked because we are going to generate them in a very cyperpunk way. Brace yourself…

It is advised that you generate these 2 keys using an air-gapped machine, i.e a machine that has never touched the public internet before!

Get a cheap Raspberry Pi if you can — it retails for less than $100 USD

If a Raspberry Pi or a new machine isn’t an option for you, download a fresh new OS, I recommend Tail OS here. Boot Tail OS live on a USB stick, generate the validator keys, copy the keys on the USB stick and you’re good to go.

Whichever way you choose to generate the validator keys, make sure that you are in a safe environment (e.g. home or office) with a trusted WiFi network. Make sure to also physically block all camera devices – e.g. laptop cameras, Webcams, people standing behind you during this process. Turn off all internet and wireless connection (e.g. Ethernet, WiFi, Bluetooth) before proceeding with the key generation step which we’ll see in a few.

That’s some serious privacy precautions am I right…You don’t even protect your wallet seed phrase that way lol 😂😂😂. Let alone seed phrase, I don’t think there is anything in your life that you take such precautions when generating. The level of privacy adhered to indicates that if you loose or your keys are compromised in any way, you’re done for!

For security reasons, we are going to showcase how to work with a live OS (Tail OS) on a USB stick

Why Tail OS?

I mean there is a reason why Edward Snowden recommends it! You don’t know who the lad is?

Look it up.

 

Download the latest version of the Ethereum validator deposit key generation binary file from here (https://github.com/ethereum/staking-deposit-cli/releases) and verify the checksum of the downloaded zipped file.

> curl -LO https://github.com/ethereum/staking-deposit-cli/releases/download/v2.7.0/staking_deposit-cli-fdab65d-linux-amd64.tar.gz

> echo “ac3151843d681c92ae75567a88fbe0e040d53c21368cc1ed1a8c3d9fb29f2a3a staking_deposit-cli-fdab65d-linux-amd64.tar.gz | sha256sum –check”

Expected output:

“`

staking_deposit-cli-fdab65d-linux-amd64.tar.gz: OK

“`

After the checksum verification, extract the contents of the downloaded zipped file and change directory into the extracted folder.

> tar xvf staking_deposit-cli-fdab65d-linux-amd64.tar.gz

> cd staking_deposit-cli-fdab65d-linux-amd64

 

Generate your validator signing keys

 

BEFORE PROCEEDING TO THE NEXT STEP

• TURN OFF YOUR ETHERNET, WIFI, AND BLUETOOTH ACCESS
• PHYSICALLY COVER ALL CAMERA DEVICES, e.g. PHONES, WEBCAMS, LAPTOP CAMERAS, PEOPLE STANDING BEHIND YOU

 

I cannot stress this enough, protect your keys! Hold onto them like you HODL that BTC!

 

Run the following command to generate your validator keys. Replace <number> with the number of validators you want to set up and <YourWithdrawalAddress> with your actual withdrawal address

> ./deposit new-mnemonic –num_validators <number> –chain holesky –eth1_withdrawal_address <YourWithdrawalAaddress>

 

 

for <YourWithdrawalAddress> use a secure non-custodial Ethereum wallet address that you own, e.g cold wallet address, SAFE multi-sig address. Not none of that CEX wallet, no! Don’t use that. Use a non-custodial wallet!

You will be prompted to key in the following. Select as fitting to you.

1. Choose your language (for the session)

1. Confirm your execution address (your withdrawal address)

1. Choose the language of your mnemonic word list (seed phrase)

1. Create a password to encrypt your validator signing keystores

1. Confirm password created in step 4

 

 

Expected Output:

Next, your mnemonic word list will be generated. Write it down on a piece of paper or notebook –Never store this online or on any device that is connected to the internet.

Expected output:

Press any key once you have written your mnemonic down and the tool will prompt you to key in your mnemonic in the same order to verify that you have recorded it correctly.

If you typed in your mnemonic correctly, you will be greeted by an ASCII art of a Rhino!

Expected output:

There will be 2 files generated.

1. A keystore-m_<timestamp>.json file: This is your validator signing keystore that your validator node will use to sign attestations. Keep this file extremely secure.

1. A deposit_data-<timestamp>.json: This is the file that links your ETH deposit to your validator. You will only use this once, during the deposit process.

Store both files on a new USB drive by copying the entire staking-deposit-cli folder into it. After that, remove the original copy by running:

> sudo rm -r $HOME/staking-deposit-cli/validator_keys

 

Restart your host device (e.g. working laptop) and remove the OS-on-a-stick. There will not be any persistent memory stored on it.

 

 

Add validator key to the Node

Now that we have our validator signing keystore, we will need to place it in our validator node itself so that the node can sign attestations and propose blocks.

Plug in the USB drive with your validator signing keystores into your node device. Once the USB drive is plugged in, we will need to identify it. On the terminal of your node, run:

> lsblk

 

Expected output:

Look for your USB drive in the output list. It will take a name similar to the screenshot above, i.e. sdx.

After you find it, you can proceed to mount your USB drive onto the /media folder.

> sudo mount /dev/sda1 /media

 

Note: Replace sda1 with the actual name of your USB drive.

You will now be able to access your USB drive via the terminal by going into the /media folder.

Go into your USB drive and copy your validator signing keystore into the HOME directory of your node.

> cd /media/staking-deposit-cli

> sudo cp -r validator_keys ~

 

Unmount and eject your USB drive.

> cd

> sudo umount /media

 

Now you need to create a plain text password file for your validator node to decrypt your validator signing keystores.

First let’s print and copy the file name of your validator signing keystore.

 

 

> cd ~/validator_keys

> ls

 

With the validator_signing_keystore_file_name copied, create the password file.

> sudo vi <validator_signing_keystore_file_name>.txt

 

Type in the password you used when generating your validator keys in the earlier step. Then save and exit the file with ESC → ENTER → :wq → ENTER

1. Depositing 32 ETH into your validator

 

 

Now listen to me very closely here. This is the step where you send the 32 ETH to become a validator. You send the 32 ETH to a smart contract on Ethereum. The smart contract is called Beacon Deposit Contract at the address `0x00000000219ab540356cBB839Cbe05303d7705Fa` on mainnet.

Now hold your horses there, you just don’t send your 32 ETH to the Beacon Deposit Contract directly like how you would send ETH to another wallet, you MUST, I repeat MUST send the 32 ETH via the official Ethereum Launchpad (http://launchpad.ethereum.org/)

If you send the 32 ETH directly without using the official Ethereum Launchpad, it will result in a failed transaction!

Double even triple check the Beacon Deposit Contract from multiple sources including Ethereum Foundation (https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/), EthHub (https://ethhub.io/) and EtherScan (https://etherscan.io/) to make sure that address is actually `0x00000000219ab540356cBB839Cbe05303d7705Fa`

Crypto is a land of many scams so be extra careful here.

Since we’ve been working on a testnet so far, holesky, we’ll continue to be a validator on the testnet

Instead of using the official Ethereum Launchpad (http://launchpad.ethereum.org/), we’ll be using a testnet launchpad (https://holesky.launchpad.ethstaker.cc/)

Where do you get 32 testnet ETH?

1. First, go to https://holesky-faucet.pk910.de/ and try minting the full 32 testnet ETH.

• If successful, skip to the next section
• If not, just mint the amount that you can and continue following the steps.

1. Join the discord server here – https://discord.gg/ethstaker

1. Join the #cheap-holesky-validator channel

1. Type “/cheap-holeskysky-deposit <your ETH address> ” in the text box and press enter

1. Click on the link generated (ie. the Signer.is text shown below)

 

1. Connect your Metamask wallet and sign the message
2. Copy the URL and paste it in the Enter Signature box.

 

 

Reviewing mandatory disclaimers

Next, go to https://holesky.launchpad.ethstaker.cc/ on your browser and click on “Become a validator”

 

 

Click through and read all disclaimers carefully.

It is not the usual “Accept Terms and Conditions” without actually reading them. So read and understand them.

 

Continue clicking through until you reach the “Upload deposit data” section. Don’t worry about the “Choose client” and “Generate keys” sections as you would already have dealt with those if you followed this guide in order.

 

 

 

 

Making the deposit

Upload your deposit_data-<timestamp>.json file you generated during the earlier section of the guide into the box above and click through until you see the following page.

Here you will need to check all disclaimer boxes before you can proceed. But before that, make sure you are not being phished by clicking on “Learn here how to do it safely” as highlighted above.

You will be brought to a page where you can reveal the address of the Ethereum Beacon Deposit Contract. Check that the address displayed in your wallet is the same before you execute the transaction approval.

 

 

The checks you perform above will point you to the deposit contract address for Mainnet. The deposit contract address on Holesky is:

0x4242424242424242424242424242424242424242

 

 

Once you are ready, click on “Send Deposit” and follow the instructions on Metamask or your other wallets.

Once your transaction goes through, you will be able to click on the external links highlighted in yellow to track the activation progress and performance of your validator. Bookmark these links so that you can come back to them easily.

 

 

Don’t panic if it doesn’t show up initially! Give it some time to update itself 🙂

 

 

Congratulations! You are now a proud contributor to the decentralisation of the Ethereum network. Pretty cool, eyy!

 

 

Exiting your validator

At some point during a normal validator’s lifecycle, you will want to exit and potentially obtain your balance back, your stake (32 ETH) plus the rewards accrued during your time being a validator, assuming you have a withdrawal address associated with your validator – which if you’ve been following through this post, you clearly have, isn’t it? You don’t remember?

Remember the 2 keys on “generating validator keys” step? Yes, those are the ones I am talking about.

 

 

If for some other reason you want to voluntary exit from being a validator, which I am not sure why you would. Aren’t the block rewards not enough for you? What, want to be a validator on Solana instead?

Whatever your reason for exiting is, the below are the steps.

Each consensus client has it’s way of exiting and since we’ve been using Lighthouse as our consensus client, below are the steps:-

A validator may chose to voluntarily stop performing duties (proposing blocks and attesting to blocks) by submitting a voluntary exit message to the beacon chain.

A validator can initiate a voluntary exit provided that the validator is currently active, has not been slashed (fancy way of saying has not penalized for misbehaving) and has been active for at least 256 epochs (~27 hours) since it has been activated.

 

 

NOTE: After initiating a voluntary exit, the validator will have to keep performing duties until it has successfully exited to avoid penalties.

 

 

It takes a minimum of 5 epochs (32 minutes) for a validator to exit after initiating a voluntary exit. This number can be higher depending on how many other validators are queued to exit!

 

 

Initiating a Voluntary Exit

In order to initiate an exit, users can use the lighthouse account validator exit command.

• The –keystore flag is used to specify the path to the EIP-2335 voting keystore for the validator. The path should point directly to the validator key .json file, not the folder containing the .json file.
• The –beacon-node flag is used to specify a beacon chain HTTP endpoint that conforms to the Beacon Node API specifications. That beacon node will be used to validate and propagate the voluntary exit. The default value for this flag is http://localhost:5052.
• The –network flag is used to specify the network (default is mainnet).
• The –password-file flag is used to specify the path to the file containing the password for the voting keystore. If this flag is not provided, the user will be prompted to enter the password.

After validating the password, the user will be prompted to enter a special exit phrase as a final confirmation after which the voluntary exit will be published to the beacon chain.

The exit phrase is the following:

 

Exit my validator

 

Below is an example for initiating a voluntary exit on the Holesky testnet.

“`

$ lighthouse –network holesky account validator exit –keystore /path/to/keystore –beacon-node http://localhost:5052

 

 

Running account manager for Holesky network

validator-dir path: ~/.lighthouse/holesky/validators

 

 

Enter the keystore password for validator in 0xabcd

 

 

Password is correct

 

 

Publishing a voluntary exit for validator 0xabcd

 

 

WARNING: WARNING: THIS IS AN IRREVERSIBLE OPERATION

 

 

PLEASE VISIT https://lighthouse-book.sigmaprime.io/voluntary-exit.html

TO MAKE SURE YOU UNDERSTAND THE IMPLICATIONS OF A VOLUNTARY EXIT.

 

 

Enter the exit phrase from the above URL to confirm the voluntary exit:

Exit my validator

 

Successfully published voluntary exit for validator 0xabcd

Voluntary exit has been accepted into the beacon chain, but not yet finalized. Finalization may take several minutes or longer. Before finalization there is a low probability that the exit may be reverted.

Current epoch: 29946, Exit epoch: 29951, Withdrawable epoch: 30207

Please keep your validator running till exit epoch

Exit epoch in approximately 1920 secs

“`

 

 

Full withdrawal of staked funds

After the Capella upgrade on 12th April 2023, if a user initiates a voluntary exit, they will receive the full staked funds to the withdrawal address, provided that the validator has withdrawal credentials of type 0x01. For more information on how fund withdrawal works, please visit Ethereum.org website.

 

 

Different consensus clients have different but somehow similar exiting procedures which can be found below:-

Prsym – (https://docs.prylabs.network/docs/wallet/exiting-a-validator)

Nimbus – (https://nimbus.guide/voluntary-exit.html)

Lodestar – (https://chainsafe.github.io/lodestar/run/validator-management/validator-cli#validator-voluntary-exit)

Teku – (https://docs.teku.consensys.net/HowTo/Voluntary-Exit)

 

 

 

 

This post was a mixture of testnet links and contexts and mainnet ones. Why?

Well, I don’t have 32 ETH with me lying around with me. So, adapt this text with reference to the chain (whether testnet or mainnet) you want to be a validator on!

 

 

Well, this was a long one!

You’ve read exactly 6,309 words which is exactly 40,289 characters of my rumbling showing you exactly how to solo stake.

I hope that your expectations when you first dived into this post have been met and you can now successfully set up a solo validator.

See you on the other side of the chain where we ponder if EigenLayer is the future of Ethereum settlements or not while we make fun of Solana for always being offline and Cardano’s boasts of academic papers which are….well, that’s a story for another day!

 

 

 

Follow us on X  for the latest posts and updates

Join and interact with our Telegram community

___________________________________________

___________________________________________