Switch to Besu as EL client for your Rocketpool minipool node

Prerequisites

This article is intended for Rocketpool node operators who currently have a operating node running Geth, if you want to get started with running a minipool (16 ETH validator), have a read here first.

Why you should switch to a minority client

To put it in simple terms — switching to a minority client for your node helps the Ethereum network achieve a healthy client diversity and make it more resilient to client specific bugs and exploits, you’re helping the Ethereum community!

You can read more on the topic:

The need for client diversity

Current client diversity chart on the execution layer

Incident in the past

If you’re reading this article and own a node, chances are you’re running geth — the most popular EL client by far, in this article we’ll walk through the steps to safely switch off Geth, delete local data, spin up a new Hyperledger Besu node on your machine and connect your CL client running in the Rocketpool stack.

Running in the Bonsai Trie mode, Besu uses roughly the same amount of disk space as a regularly pruned Geth node — you won’t need to manually Prune however.

We recommend always going for a 2TB SSD set up for your rocketpool node.

Prepare your node for the swtich

The first thing you’ll want to do is make sure you have a backup EL client — Infura is the only one supported, it’s free and highly available, it’ll act as the interim client.

If you don’t yet have it set up, first head to https://infura.io/ to sign up and grab the project ID, then run

rocketpool service config

On your node to start the config wizard and follow the prompts there to set up fallback EL client.

Say goodbye to Geth

We’ll start by stopping Geth’s container running and making sure that our fallback Infura is configured correctly.

Run

rocketpool service stop eth1

To stop the Geth container

And wait about 30 seconds then run

rocketpool service logs eth1-fallback

To check Infura logs — you should see requests going through.

Double check your Cl client logs with

rocketpool service logs eth2

To make sure it’s still attesting correctly.

Next we’ll delete the Geth local database.

Run

docker volume ls

You should see `rocketpool_eth1clientdata`, run docker volume rm rocketpool_eth1clientdata to delete the data volume locally.

From there we’ll tell Rocketpool that we’re going to have an externally managed Eth1 client and not to start up any Geth instances when the stack restarts.

Run rocketpool serivce config and select Externally Managed for EL client and save — while we’re here also make sure you put in the correct IP address and port for the machine.

Note that you should use the local machine’s LAN IP address, rather than 127.0.0.1 since the CL client will be querying from within a docker network, read more about it here.

You should be able to verify that no Eth1 config still exist under ~/.rocketpool/runtime

Finally run df -h to confirm that you have freed up a couple hundred GB of space and is ready to go!

Start Besu

(For any Besu related question, you can receive active support here on the Hyperledger Discord)

Now we start syncing Besu.

First we’ll create a local data directory — run mkdir /home/<username>/.rocketpool/besudata

Then start Besu in a docker daemon with

docker run -d --restart always \
        -p 8545:8545 \
        -p 30303:30303 \
        -p 9545:9545 \
        --mount type=bind,source=/home/<username>/.rocketpool/besudata,target=/var/lib/besu  \
        hyperledger/besu:latest \
        --data-storage-format=BONSAI \
        --rpc-http-enabled \
        --data-path=/var/lib/besu \
        --metrics-enabled=true \
        --metrics-host=0.0.0.0 \
        --host-allowlist=127.0.0.1,0.0.0.0,<localLANaddress>

Make sure you replace <username> with your machine username and<localLANaddress> with your actual ip address.

This will start a Besu node running in the Bonsai data storage format in fast-sync mode.

You can follow your node’s logs to make sure everything is running smoothly, use docker ps to find the container id and docker logs -f <id> to see logs.

A full sync can take a few days, be sure to check in every once in a while to make sure everything is running smoothly!

To wrap up

While you wait for Besu to sync up, check your CL client logs again using rocketpool service logs eth2 , you should be able to see your CL client querying Besu successfully but using the fallback instead because Besu is not yet up to sync.