runnin nodes: reth

reth is new node software from Paradigm written in Rust! if you want to run a node, it’s shiny and new. before this i looked at another cool node written in Rust called Akula! it has a pretty cool name but the development efforts have been refocused on Erigon!

the differences between erigon and reth is not something an operator is concerned by. they are both great choices because they are written in modern languages, easy to install on different hardware, and in some cases the only practical solution to chains with high performance demands like Polygon and Binance Chain.

setting up reth

installing Rust on any kind of machine is pretty easy with rustup.rs to get cargo! you will also want git installed on the machine which you better have! i see the repo is using a Makefile which i’ll use for this incase the build process changes in the future.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup default nightly
# now you have cargo!
git clone https://github.com/paradigm/reth
cd reth

installing reth

the great developers maintaining tools at Paradigm draw inspiration from the ease of Rustup for their Foundry Solidity development kit, but we are still in the alpha so time will tell if this is simplified further. to make the lovely chug of cargo output will begin

make install

go do something else, maybe setup sccache if you find yourself using Rust a lot is one idea.

once the package is built through make install, a new reth binary will appearing in your default cargo binary path. if this is a new installation, the default is located at ~/.cargo/bin/reth. i’ve had good success running reth with normal user privileges, so i’ll keep it there and use it to setup a systemd service.

setting up reth

to actually use reth, for now you will need an additional consensus layer. the developers have stated they weren’t interested in adding this, if you’re interested in a complete solution to both problems you might consider setting up erigon instead. it depends on your use case, so a modular node is another tool in the box. it wouldn’t surprise me to see one added eventually. i’ve summarized how to setup lighthouse over here eventually.

once you have lighthouse started, you’re ready to get reth started. systemd is a great choice for running the service, and for good hygiene you might consider creating a separate user to run it with useradd. here is the file i use.

[Unit]
Description=reth node - sepolia
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/home/reth/.cargo/bin/reth node --chain sepolia --ws --ws.addr 0.0.0.0 --ws.port 48545 --ws.origins '*' --http --http.addr 0.0.0.0 --http.port 48545
User=reth

[Install]
WantedBy=multi-user.target

to start the node i then use the classic

sudo systemctl enable --now reth-sepolia

you can then monitor the progress of the sync with at any time. you’ll need it!

journalctl -u reth-sepolia

debugging the node

you’ll probably run into a problem where the node has an error it cannot resolve on it’s own while syncing. reth has a lot of helpful debugging commands you can use to unwind or reset stages, which i highly recommend using since resetting a single stage will save large amounts of time compared to nuking the database on error which is tempting but futile.

typically things will stop syncing, you’ll use journalctl to look for a key indicator as to what is failing. the merkle stage is a common hangup for me. here is an example of what you can run to reset it.

to unwind you can use this command, which tries to roll back all stages but isn’t a silver bullet

~/.cargo/bin/reth stage unwind --chain sepolia num-blocks 150

in the majority of cases where that doesn’t solve the problem, i find i spend less time sifting through logs if i just drop the offending stage and resync, such as with

~/.cargo/bin/reth stage drop merkle --chain sepolia

you can list more information about stages by using the reth stage command with any arguments!