Running Layer 1 nodes

In order to run an Ethereum node you will need to run 2 different clients at the same time: one Consensus Layer Client (Beacon Chain) and one Execution Layer Client.

Important

Unless otherwise specified, all commands should be run under the ethereum user account.

Quick Navigation

Hardware Requirements

Component

Minimum

Recommended

RAM

8 GB

16 GB

Storage

2 TB SSD

4 TB NVMe SSD

Network

10 Mbps

25+ Mbps

CPU

4 cores ARM64

8 cores ARM64

Getting Started

  1. Run and sync a Consensus Client (Beacon chain) using Checkpoint sync (it syncs in a few minutes).

  2. Wait for the Beacon Chain to get in sync.

  3. Run and sync an Execution Client.

Important

Erigon is the only Execution Layer client that includes a Light Consensus Layer Client (Caplin). You can run a full Ethereum node just by starting the Erigon service.

See below for further details.

Consensus Layer Nodes

The Consensus Layer node consists of two separate clients:

  • The Beacon Chain client

  • The Validator client

As stated above, for running a full Ethereum node you will need to start a Beacon Chain client and an Execution Layer client. The Beacon Chain is the one telling the Execution Layer client how to follow the head of the chain, so, without it, the Execution Client would be lost and it could not start the sync.

You need a synced Beacon Chain Client for the Execution Client sync to start. As we configured Checkpoint Sync by default in all clients, the Beacon Chain should be in sync in a few minutes.

Note

REMEMBER: Staking is NOT necessary for running a full Ethereum node. For this, you just need a synced Execution Client running along with a synced Consensus Layer Beacon Chain.

Beacon Chain

The Beacon Chain is a bridge between the Execution Layer and the Consensus Layer clients. It connects the Validator to the Execution Layer so the Validator can detect the 32 ETH deposit transaction (which contains the Validator public key).

The Beacon Chain also guides the Execution Client on how to follow the chain head.

In order to propose (create) blocks in Ethereum you need an Execution Client in sync running along with a Beacon Chain in sync and a Validator (the Beacon chain and the Validator are both part of the Consensus Layer Client).

Checkpoint Sync

All Consensus Layer clients are configured to use CheckPoint Sync by default that will get the Beacon Chain synced in just a few minutes.

Supported Clients

Ethereum on ARM supports the main Consensus Layer clients available.

Client

Official Binary

Language

Home

Lighthouse

Yes

Rust

lighthouse-book.sigmaprime.io

Prysm

Yes

Go

docs.prylabs.network

Nimbus

Yes

Nim

nimbus.team

Teku

Yes

Java

consensys.net

Lodestar

Yes

Typescript

lodestar.chainsafe.io

Grandine

Yes

Rust

grandine.io

Vouch

Yes

Go

vouch.io

Rust-based:

  • Lighthouse Production Ready

  • Grandine Production Ready

Go-based:

  • Prysm Production Ready

  • Vouch Production Ready Multi-node

Other Languages:

  • Nimbus (Nim) Production Ready

  • Teku (Java) Production Ready

  • Lodestar (TypeScript) Production Ready

Lighthouse Production Ready Rust

Lighthouse is a full CL client written in Rust.

Systemd Services

Home Directory

Config Files

Ports

lighthouse-beacon lighthouse-validator

/home/ethereum/.lighthouse

/etc/ethereum/lighthouse-beacon.conf /etc/ethereum/lighthouse-validator.conf

TCP/UDP: 9000

1.- Port forwarding

You need to open the 9000 port in your router (both UDP and TCP)

2.- Start the beacon chain

Under the ethereum account, run:

sudo systemctl start lighthouse-beacon

The Lighthouse client will start to sync the Beacon Chain. This may take just some minutes as Checkpoint sync is enabled by default.

The Lighthouse beacon chain is now started. Wait for it to get in sync. Choose an Execution Layer client and start it.

Prysm Production Ready Go

Prysm is a full Consensus Layer client written in Go.

Systemd Services

Home Directory

Config Files

Ports

prysm-beacon prysm-validator

/home/ethereum/.eth2

/etc/ethereum/prysm-beacon.conf /etc/ethereum/prysm-validator.conf

TCP: 13000, UDP: 12000

1.- Port forwarding

You need to open the 13000 (TCP) and 12000 (UDP) ports in your router/firewall

2.- Start the beacon chain

Under the ethereum account, run:

sudo systemctl start prysm-beacon

This will start to sync the Beacon Chain. This may take just some minutes as Checkpoint sync is enabled by default.

The Prysm beacon chain is now started. Wait for it to get in sync. Choose an Execution Layer client and start it.

Teku Production Ready Java

Teku is a full Consensus Layer client written in Java.

Systemd Services

Home Directory

Config File

Ports

teku-beacon teku-validator

/home/ethereum/.teku/beacon /home/ethereum/.teku/validator

/etc/ethereum/teku-beacon.conf /etc/ethereum/teku-validator.conf

TCP/UDP: 9000

1.- Port forwarding

You need to open the 9000 port (both UDP and TCP)

2.- Start the beacon chain

Under the ethereum account, run:

sudo systemctl start teku-beacon

The Teku beacon chain is now started. Wait for it to get in sync. Choose an Execution Layer client and start it.

Nimbus Production Ready Nim

Warning

From version 23.1.0, we upgraded Nimbus to run as 2 independent processes, 1 binary for the Beacon Chain and 1 binary for the validator (so 2 different services).

If you are using a prior release please upgrade and take into account that you need to run 2 Systemd services.

You need to stop the nimbus service before upgrading to 23.1.0

Nimbus is a full Consensus Layer client written in Nim.

Systemd Service

Home Directory

Config File

Ports

nimbus-beacon nimbus-validator

/home/ethereum/.nimbus-beacon /home/ethereum/.nimbus-validator

/etc/ethereum/nimbus-beacon.conf /etc/ethereum/nimbus-validator.conf

TCP/UDP: 9000

1.- Port forwarding

You need to open the 9000 port (both UDP and TCP)

2. Copy and paste your Ethereum Address for receiving tips and set the fee recipient flag:

sudo sed -i 's/changeme/0x1234567890abcdef1234567890abcdef12345678/' /etc/ethereum/nimbus-validator.conf

Replace 0x1234567890abcdef1234567890abcdef12345678 with your actual Ethereum address.

  1. Enable Checkpoint Sync.

We need to run a command manually before the Checkpoint Sync gets started:

nimbus_beacon_node trustedNodeSync --network=mainnet --data-dir=/home/ethereum/.nimbus-beacon --trusted-node-url=https://sync-mainnet.beaconcha.in --backfill=false

Wait for the command to finish.

  1. Start the Nimbus Beacon Chain service:

sudo systemctl start nimbus-beacon

The Nimbus Beacon Chain is now started. Wait for it to get in sync. Choose an Execution Layer client and start it.

Lodestar Production Ready TypeScript

Lodestar is a full Consensus Layer client written in Type Script.

Systemd Services

Home Directory

Config File

Ports

lodestar-beacon lodestar-validator

/home/ethereum/.lodestar

/etc/ethereum/lodestar-beacon.conf /etc/ethereum/lodestar-validator.conf

TCP/UDP: 9000

1.- Port forwarding

You need to open the 9000 port (both UDP and TCP)

2.- Start the beacon chain

Under the ethereum account, run:

sudo systemctl start lodestar-beacon

The Lodestar beacon chain is now started. Wait for it to get in sync. Choose an Execution Layer client and start it.

Grandine Production Ready Rust

Grandine is a full Consensus Layer client written in Rust.

Systemd Services

Home Directory

Config Files

Ports

grandine-beacon grandine-validator

/home/ethereum/.grandine

/etc/ethereum/grandine-beacon.conf /etc/ethereum/grandine-validator.conf

TCP/UDP: 9000

1.- Port forwarding

You need to open the 9000 (TCP/UDP) ports in your router/firewall

Warning

Currently, Grandine runs in one instance, so if you want to stake you will need to configure the Validator file config and run the grandine-validator service that will start both Beacon and Validator processes,.

2.- Start the beacon chain (if you want to run a validator, skip this step and go to staking section)

Under the ethereum account, run:

sudo systemctl start grandine-beacon

This will start to sync the Beacon Chain. This may take just some minutes as Checkpoint sync is enabled by default.

The Grandine beacon chain is now started. Wait for it to get in sync. Choose an Execution Layer client and start it.

Execution Layer nodes

The Execution Clients are the clients responsible for executing transactions and storing the blockchain global state among other operations.

Supported clients

Ethereum on ARM supports all available Execution Layer clients.

Execution Layer Supported Clients

Client

Official Binary

Language

Home

Geth

Yes

Go

geth.ethereum.org

Nethermind

Yes

.NET

nethermind.io

Erigon

Yes

Go

github.com/ledgerwatch/erigon

Hyperledger Besu

Yes

Java

hyperledger.org

EthRex

Yes

Rust

ethrex.io

Reth

Yes

Rust

paradigmxyz.github.io

Snap Sync (Fast):

  • Geth Production Ready 12-18h sync

  • Nethermind Production Ready 12-18h sync

  • Hyperledger Besu Production Ready 18-24h sync

  • EthRex Testing 12-18h sync

Execution Sync (Slower, Archive-capable):

  • Reth Production Ready 3-5 days sync

  • Erigon Production Ready 4-6 days sync Built-in CL

Syncing Strategies and Times

One of the most frequently asked questions is: “How long does it take to sync?”. The answer depends heavily on the client you choose, specifically because different clients use different syncing technologies.

Execution Layer (L1) Clients — Sync Types & Times (approx. on Rock 5B / RPi5)

Client

Sync Type

Approx. Sync Time

Archive Node?

Geth

Snap Sync

12–18 Hours

No (Full Pruned)

Nethermind

Snap Sync

12–18 Hours

No (Full Pruned)

Hyperledger Besu

Fast / Snap Sync

18–24 Hours

No (Full Pruned)

Reth

Execution / Pipeline

3–5 Days

No (Full Pruned)

Erigon

Execution / Staged

4–6 Days

No (Full Pruned)

EthRex

Snap Sync

12–18 Hours

No (Full Pruned)

Note

The comparison above assumes all clients are configured as Full Nodes (pruned state).

Why are Reth and Erigon “slower” to sync?

It comes down to Snap Sync vs Execution Sync:

  • Snap Sync (Geth, Nethermind, Besu): The client downloads the latest “snapshot” of the blockchain state directly from peers. It trusts the Proof-of-Stake consensus to verify the chain head and then just fills in the data. This avoids re-calculating the entire history of the chain, making it significantly faster and less CPU intensive initially.

  • Execution Sync (Reth, Erigon): These clients download the raw block data and re-execute every single transaction from the Genesis block (or a check point) to the current head. This requires massive CPU computation and I/O operations because your little ARM board is effectively re-playing the entire history of Ethereum.

The Benefit: While slower to sync, Reth/Erigon result in a highly optimized database structure that is often faster for RPC queries and, importantly, they run as Archive Nodes by default (keeping all historical data) with very efficient disk usage compared to a Geth Archive node.

Warning

Remember that you need to run a synced Consensus Layer client before starting the Execution Layer client (unless you use Erigon and you are not going to stake)

Geth Production Ready Go

Geth is the most used EL client. It is developed by the Ethereum Foundation team and the performance on ARM64 devices is outstanding. It is capable of syncing the whole blockchain in less than 1 day on a Raspberry Pi 5 with 16 GB RAM and in less that 1 day on the Radxa Rock 5B.

Systemd Service

Home Directory

Config File

Ports

geth

/home/ethereum/.geth

/etc/ethereum/geth.conf

TCP/UDP: 30303

You can start the client by running:

sudo systemctl start geth

For further info of how the node is doing you can use Systemd journal:

sudo journalctl -u geth -f

Nethermind Production Ready .NET

Nethermind is a .NET enterprise-friendly full Execution Layer client.

Systemd Service

Home Directory

Config File

Ports

nethermind

/home/ethereum/.nethermind

/opt/nethermind/configs/mainnet.json

TCP/UDP: 30303

In order to start the client run:

sudo systemctl start nethermind

Hyperledger Besu Production Ready Java

Systemd Service

Home Directory

Config File

Ports

besu

/home/ethereum/.besu

/etc/ethereum/besu.conf

TCP/UDP: 30303

In order to start the client run:

sudo systemctl start besu

EthRex Testing Rust

EthRex is a lightweight, performant, and modular Ethereum execution client powering next-gen L1 and L2 solutions.

Systemd Service

Home Directory

Config File

Ports

ethrex

/home/ethereum/.ethrex

/etc/ethereum/ethrex.conf

TCP/UDP: 30303

In order to start the client run:

sudo systemctl start ethrex

Note

EthRex is new in Ethereum on ARM ecosystem, and still under testing

Reth Production Ready Rust

Reth (Rust Ethereum) is an Ethereum execution client implementation that focuses on friendliness, modularity, and speed.

Systemd Service

Home Directory

Config File

Ports

reth

/home/ethereum/.reth

/etc/ethereum/reth.conf

TCP/UDP: 30303

In order to start the client run:

sudo systemctl start reth
Advanced: Full vs Archive Node Configuration

By default, Reth runs as an Archive Node, storing all historical states. This requires significantly more disk space.

If you wish to run a Full Node (pruned state) to save disk space, you must enable the full node mode.

To do this, edit the configuration file for your network (e.g., /etc/ethereum/reth.conf for Mainnet) and add the --full flag to the ARGS variable.

Example:

ARGS="node ... --full"

After saving the file, restart the service:

sudo systemctl restart reth

Erigon Production Ready Go Built-in CL

Systemd Service

Home Directory

Config File

Ports

erigon

/home/ethereum/.erigon

/etc/ethereum/erigon.conf

TCP/UDP: 30303

Note

Erigon Setup Options

Erigon 3 includes Caplin, its own consensus layer. Choose your setup:

🎯 Simple Setup (Recommended)

  • Use built-in Caplin consensus layer

  • Service: erigon

  • Use when: Running a full node without external CL client

  • Advantages: Single service, simpler configuration

🔧 Advanced Setup

  • Use external consensus layer client

  • Service: erigon-externalcl

  • Use when: You need compatibility with external CL clients

  • Advantages: More flexibility, can use any CL client

In order to start the client run:

sudo systemctl start erigon

Note

Erigon includes Caplin, its own consensus layer, and by default runs as a full Ethereum node without requiring a separate consensus layer client.

Warning

Erigon 3 introduces a major change to Erigon’s architecture. Erigon is now configured to use Caplin as its consensus layer by default. Users who wish to use an external consensus layer must explicitly configure Erigon to do so using the erigon-externalcl service. This is a breaking change and requires manual configuration.

Caplin Consensus Layer

Erigon has integrated Caplin, its own consensus layer, directly into the client. This means that for most users, running a full Ethereum node is as simple as starting the erigon service. The need for a separate beacon node client is eliminated in the default configuration.

`erigon-externalcl` Service

For advanced use cases or when compatibility with external consensus layer clients is required, EoA provides the erigon-externalcl service. This service allows Erigon to operate with a separate consensus client.

Upgrade Notes

Due to the significant changes to Erigon’s architecture, a manual upgrade process is necessary. You can use the new provided config or update yours according to the Erigon documentation.

Further Information

For complete details on Erigon configuration, usage, and troubleshooting, please refer to the official Erigon documentation: [https://docs.erigon.tech]

Staking

For instructions on how to set up a validator and stake your ETH, please refer to the Solo Staking guide.

My beacon chain won’t sync

Possible causes:

  • Checkpoint sync endpoint is down

  • Firewall blocking ports

  • Insufficient peers

Solutions:

  • Check logs: sudo journalctl -u [service-name] -f

  • Verify port forwarding is configured correctly

  • Try alternative checkpoint sync endpoint

  • Ensure system time is synchronized

Execution client stuck at “Waiting for beacon node”

Cause: Beacon chain is not synced yet

Solution: Wait for beacon chain to complete checkpoint sync (usually 5-10 minutes). Check beacon chain logs to verify it’s syncing.

Validator not attesting

Possible causes:

  • Validator keys not imported correctly

  • Fee recipient not set

  • Beacon chain not connected to execution client

Solutions:

  • Verify keys are imported: check validator client logs

  • Confirm fee recipient is set in config file

  • Ensure both beacon chain and execution client are running and synced

  • Check JWT token is correctly configured

High memory usage

Cause: Some clients require significant RAM, especially during initial sync

Solutions:

  • Ensure you meet minimum hardware requirements (16GB RAM recommended)

  • Consider using a lighter client combination

  • Monitor with: htop or free -h

  • Restart services if memory leak suspected

Disk space running out

Solutions:

  • Check current usage: df -h

  • For Reth: enable full node mode (pruned) instead of archive

  • Ensure you have at least 2TB SSD (4TB recommended)

  • Monitor growth rate and plan upgrades accordingly