How to run an Ethereum node after the merge

Published in

Truebit

5 min readOct 11, 2022

Overview

After the merge, Ethereum nodes comprise an execution client and a consensus client; both are needed to run a full Ethereum node and include some caveats. This article will cover the node detail structure after the merge, node selection depending on the specific use, options for sync, and how to check the sync state.

Ethereum node and clients

An Ethereum node is a computer running the software client connected to other computers with the same Ethereum software, creating a p2p network that verifies data against the protocol rules and keeps the network secure.

Post merge Ethereum main parts:

Execution client: Listens to new transactions broadcasted in the network and executes them in the Ethereum virtual machine (EVM) and holds the latest state and database of all current Ethereum data.

Consensus client: contain the Beacon Node that implements the proof of stake (POS) consensus algorithm, enabling the network to achieve agreement based on validated data from the execution client. The validator client is part of the consensus, handling the network synchronization, drawing consensus, and performing several other low-level functions. The role of validators is to stake ETH to perform block proposals, and attestations are an equally critical component of the Ethereum beacon chain.

Bacon chain

Beacon Block

Ethereum Clients types

Nodes

Full Node

The full node stores blockchain data (although this is periodically pruned, so a full node does not store all state data back to genesis). Participates in block validation and verifies all blocks and states.

Light Node

The light node was the most common mode in Ethereum 1 among applications running inside the node. After the merge, this option is not yet available, and some experimental clients are working to provide a solution. To speed up the syncing and reduce the storage size, some clients offer Optimistic sync, which imports the block even though it has not validated its execution payload. The other option is Checkpoint sync which speeds up the initial sync by beginning the syncing from a recently finalized checkpoint.

Checkpoints:

Ethereum 1 had a block time around 14s. After the merge, the Beacon Chain has a tempo divided into slots (12 seconds) and epochs (32 slots). Every Epoch last 6.4 minutes, and the first slot in each epoch is a checkpoint.

Epochs | Mainnet Beacon Chain (Phase 0) Ethereum 2.0 Explorer (beaconscan.com)

Archive Node

Stores everything kept in the full node and builds an archive of historical states. It is needed if you want to query something like an account balance at block #4,000,000, or simply and reliably test your transactions set without mining them using tracing. Syncing this node could take several weeks and 4 TB of storage.

Running a node according to the requirements.

Two types of nodes (block-producing and non-block-producing). Both nodes will create and maintain two databases, one for client execution with all the transactions and interaction with the EVM, and the other database for consensus (beacon chain).

Validator (block-producing)

This node requires all the major components like Execution client and Consensus client with the client validator. To activate the validator is necessary to stake ETH into a smart contract in Ethereum. This staked ETH then acts as collateral that can be destroyed if the validator behaves dishonestly or lazily. The node should stay up and working 24x7 and avoid any downtime that could cost part of the stake.

Non-block-producing

This type of node is used to install Ethereum applications that fully comply with decentralization. The ability for anyone to run their node is critical to maintaining the Ethereum network’s decentralization. To install a non-block-producing, consensus and execution clients are required without the validator client.

Execution clients

Consensus clients

Lighthouse: written in Rust
Nimbus: written in Nim
Prysm: written in Go
Teku: written in Java
Lodestar: written in Typescript

Node Synchronization

After the merge, a node sync means both clients, execution, and consensus doing the sync. For example, we will consider using Geth for execution and Prysm for consensus.

How to check the sync state of your node

curl http://localhost:3500/eth/v1/node/syncing | jq

This node has finished the consensus sync and is still syncing execution.