EIP-7870 Recommended node hardware and bandwidth specifications (Hardware and Bandwidth Recommendations)

No call decision · Networking & nodes · EIP status Living · created 2025-01-26

A guidance document that lays out, by role, the storage, memory, CPU and internet connection speed that are good for an Ethereum full node and validator (attester, local block builder) to have. It is an Informational EIP that does not change the protocol.

Why it is needed

Ethereum nodes often run an execution layer (EL) client and a consensus layer (CL) client together on one computer. Until now, however, there was no shared standard for which computer to use as the baseline when measuring and judging performance. Without a standard, three problems arise. First, if each client measures performance in a different environment, benchmark results cannot be compared with each other. Second, it is hard to judge how much more node resources a protocol upgrade uses, because performance characteristics depend heavily on hardware. Third, node operators cannot tell which hardware to invest in to meet the network's future requirements. This EIP tries to solve all three problems by writing the recommended specifications for each role in one place. The source states that clients can be run on hardware below the recommended specifications, but benchmarks and decision making are based on these recommended specifications.

What changes

Today

After EIP-7870

Who is affected

In depth

The three node roles

The source divides nodes into three roles. A full node (Full node) follows the tip of the chain without proposing blocks itself. A validator (Validator) is further split in two. An attester is a validator that verifies and attests to blocks built by the proposer, and a local block builder (Local block builder, Proposer) is a validator that builds blocks itself and propagates them to the network. A local block builder needs many resources both to build blocks and to quickly distribute the data attesters need to verify within the time limit. The source stresses that clients may run on hardware below the recommended specifications, but benchmarks and decision making are based on these recommended specifications.

Recommended specifications table by role

Node operators usually run an execution layer (EL) client and a consensus layer (CL) client on the same computer, so the figures in the table assume the combined resource usage of both. A full node needs a 4 TB NVMe, 32 GB of memory, 4 cores and 8 threads (PassMark about 1000 ST / 3000 MT), and 50 Mbps download / 15 Mbps upload. An attester needs a 4 TB NVMe, 64 GB of memory, 8 cores and 16 threads (about 3500 ST / 25000 MT), and 50 Mbps / 25 Mbps. A local block builder has the same storage, memory and CPU as an attester, and only the bandwidth is higher at 100 Mbps / 50 Mbps. ST and MT are the single-thread and multi-thread scores of the PassMark CPU benchmark. The source adds that ST 3500 and MT 25000 correspond to a mid-to-high-end server CPU around 2024 to 2025.

Storage: 4 TB NVMe and IOPS targets

The recommendation is a 4 TB NVMe M.2 drive. It requires about 2000 MB/s or more for sequential read/write, about 50,000 or more random 4K read IOPS, and about 15,000 or more random 4K write IOPS. The source gives ways to measure sequential performance (--bs=1M --rw=readwrite) and random 4K performance (--bs=4k --readwrite=randrw --rwmixread=75) yourself with the fio command. NVMe is chosen over SATA because its throughput is much higher and its latency is lower. DRAMless drives and QLC flash are not recommended, because their endurance and sustained performance can be lower. Nodes write often because of database updates and logs, so the source says to check that the SSD's total bytes written (TBW) is enough for several years of operation. As of January 2025, 2 TB still works for capacity, but the chain grows every day, so 4 TB is expected to last longer. It notes that the timing of history expiry, which aims to reduce the burden of storing old data, is uncertain.

Memory: why 64 GB is recommended for validators

There are four reasons for recommending 64 GB for validators (attester and local block builder). First, running EL and CL clients together uses a lot of memory, and the state cache takes up most of the RAM usage. Second, some memory-heavy client combinations have actually failed at 16 GB. They can be run by tuning cache sizes per client, but the source does not assume the average user will tune them that way. Third, preliminary benchmarks on zk-STARK memory usage show that cryptographic operations can require substantial RAM. Fourth, relative to the total hardware cost, the cost of going from 32 GB to 64 GB is small, but it improves stability and also helps prepare for zk-STARKs. A full node stays at 32 GB.

CPU: both single-thread and multi-thread

The CPU section of the source is short. It says attesters and local block builders benefit when both single-thread and multi-thread performance are high. The table recommends 8 cores and 16 threads with PassMark about 3500 ST / 25000 MT for both roles, and 4 cores and 8 threads with about 1000 ST / 3000 MT for a full node. It sets the baseline by giving the PassMark single-thread (ST) and multi-thread (MT) scores alongside the core and thread counts, not just the counts. A footnote in the source explains that ST 3500 and MT 25000 are at the level of a mid-to-high-end server CPU around 2024 to 2025.

Bandwidth: Rationale by role and with MEV-Boost

A local block builder needs 100 Mbps download and 50 Mbps upload. Publishing a block uses a lot of bandwidth. If speed falls short, propagation is delayed and the node risks producing a late block. In extreme cases, a node with low bandwidth may propose blocks that are less full or include fewer blobs to avoid slow propagation. An attester needs 50 Mbps / 25 Mbps. In ethPandaOps simulations, with 40% of the network on gigabit and 60% on 15 Mbps upload, the tests went down to 15 Mbps. Real performance depends on the peer network structure and is hard to predict, so 25 Mbps was chosen to leave headroom for unpredictable factors. A validator using MEV-Boost also needs 50 Mbps / 25 Mbps, because communication with the relay is limited to receiving bundles and block headers, and the relay also propagates the block. However, if the relay does not respond or the MEV reward is lower than the minimum set in MEV-Boost, the validator builds a local block itself, and the local block builder recommendation applies then. A full node needs 50 Mbps / 15 Mbps. It takes part in sampling and follows the chain tip, but it is less sensitive to latency. If bandwidth is severely lacking, the node can fall behind by more than one slot.

No protocol change, a recommendation for future EIPs

This EIP is of the Informational type, so it does not change the protocol and has no compatibility issues. Instead, it recommends that future EIPs include an assessment of how they affect these hardware recommendations. In other words, a new proposal should state at the proposal stage whether it demands more storage, memory, CPU, or bandwidth. The security considerations are listed as not applicable (N/A). The copyright is waived under CC0.

Status: kept as a living document, updated with each fork

The status in the source is Living. This means the document is not finalized once and left alone but is updated continuously, so the figures in the table may change in the future. The call records show discussion at AMA #14 on 08.29 and ACDT #97 on 09.21, but no decision was made. At ACDT #100 on 10.12, it was decided that the hardware recommendation EIP-7870 will not be split into a new EIP for each fork. It will be kept as a single living document and updated by appending per-fork history. The decision is meant to reduce confusion when users look for the specification. The figures on this page are copied from the source as written in January 2025, so for later updates it is best to check the source.

Original EIP · ← EIPs