System requirements

This page lists what Grandine itself needs. A staking node also runs an execution client (EL) such as Geth or Nethermind on the same machine, and the execution client needs much more memory and disk than Grandine. Add its requirements to the figures below. See Sizing a full node.

Grandine requirements

These figures are estimates for Grandine on Mainnet, with the built-in validator client and the default storage mode. They include headroom for the operating system and for periods without finality, but are not yet backed by published measurements.

See Operating systems and architectures for the supported platforms.

Testnets such as Hoodi need less disk than Mainnet.

CPU

Grandine spreads its work across all CPU cores. More cores help most during the initial sync, when the node runs many validators, and when it subscribes to many subnets.

The official binaries use the portable build of the blst BLS library, so they also run on older x86-64 CPUs that lack the ADX instruction set extension.

Memory

On a healthy Mainnet, Grandine needs about 5 GB of memory. Grandine keeps the unfinalized part of the chain in memory, so memory use grows during a long period without finality. To measure how much memory Grandine really uses, and to limit it during non-finality, see Performance and memory tuning.

Disk usage by storage mode

Use an SSD, preferably NVMe. Grandine stores the finalized chain in an embedded libmdbx database, and how much it stores depends on the storage mode:

The retention windows come from the consensus specification and are the same on Mainnet and Hoodi. After the Gloas fork, the block window shrinks to 14,299 epochs (about 64 days).

Note: A new high-performance archive node is coming soon. See Back-sync and archive nodes.

Network

A beacon node keeps many peer connections and exchanges data with them continuously. Use a reliable connection without a monthly data cap, and open the peer-to-peer ports in your firewall:

• 9000 TCP and UDP, and 9001 UDP (QUIC), over IPv4
• 9050 TCP and UDP, and 9051 UDP (QUIC), over IPv6. These are used only when IPv6 is enabled with --listen-address-ipv6

See Networking and peers and Default ports and paths.

Time synchronization

Every duty in Ethereum is tied to a slot, so the system clock must be accurate. Run a time synchronization service such as chrony or systemd-timesyncd. A clock that drifts by even a second or two causes missed attestations, and peers reject messages from nodes whose clocks are far off.

When you need more

Some setups need more resources than the figures above:

• Many validators. A single Grandine node can run up to tens of thousands of validators. CPU use and network traffic grow with the number of validators, because the node subscribes to more attestation subnets and produces more messages.
• Supernodes. A node started with --supernode downloads and stores every data column, and --semi-supernode half of them. Both need noticeably more bandwidth and disk than a regular node. See PeerDAS and blob data.
• Archive nodes. An archive node needs much more disk, and benefits from a fast NVMe SSD for serving historical data. See Back-sync and archive nodes.
• All subnets. --subscribe-all-subnets increases CPU use and traffic.

Sizing a full node

To size the machine, add your execution client's requirements to Grandine's. The execution client usually needs most of the memory and disk. Check its documentation:

• Geth
• Nethermind
• Besu
• Erigon
• Reth

As a rough orientation, a Mainnet node that runs Grandine and a typical execution client is comfortable with:

Note: Execution clients now expire old chain history on a rolling basis, so their disk usage no longer grows without bound. A 2 TB disk is enough for a full node with a typical execution client. Archive nodes need much more.

When Grandine runs embedded in Nethermind, both clients share one process. Size the machine the same way: Nethermind's requirements plus Grandine's.

For reliability, a stable internet connection and an uninterruptible power supply (UPS) help a validator stay online.

Operating systems and architectures

Each release publishes these binaries, where VERSION is the Grandine version:

Each release also publishes Grandine embedded in Nethermind as one archive per platform, where NETHERMIND_VERSION is the bundled Nethermind version:

Docker images are published for linux/amd64 and linux/arm64. Linux is the most tested platform and the one this book assumes. See Pre-built binaries and Docker.