EIP-7870: Hardware and Bandwidth Recommendations

Abstract

This proposal specifies hardware and bandwidth recommendations for different types of Ethereum nodes:

• Full nodes: Nodes that follow the tip of the chain without necessarily proposing blocks.
• Validators: Split into:
  • Attesters: Validators that validate and attest to blocks created by proposers.
  • Local block builders (Proposers): Validators that create blocks locally and broadcast them to the network.

The resource-intensive aspect for local block builders lies in creating the block and quickly broadcasting the data required for attesters to validate it in time.

We note that it may be possible to run a client with less than the recommended specifications, however benchmarks and decision-making will be made with respect to these recommendations.

Motivation

Clear system specifications are crucial for:

• Ensuring meaningful benchmark comparisons across different client implementations.
• Enabling informed decision-making about protocol upgrades and their resource usage implications.
• Providing clear guidance for node operators to ensure alignment with future network requirements.

Without a shared understanding of target hardware specifications:

• Benchmark results lose significance due to inconsistent testing environments.
• Decision-making becomes challenging for implementation choices, as performance characteristics are heavily hardware-dependent.
• Network participants lack clear guidance for hardware investments.

Specification

Roles and Their Recommended Specifications

Node operators typically run both an Execution Layer (EL) client and a Consensus Layer (CL) client on the same machine. The specifications below assume the combined resource usage of both.

Approximate single-thread (ST) and multi-thread (MT) PassMark CPU scores. For example, a PassMark ST rating of 3500 and an MT rating of 25000 typically corresponds to upper mid-range server CPUs circa 2024–2025.

Rationale

Storage

• Recommended: 4 TB NVMe M.2 drive with:
  • Sequential R/W: 7,000 MB/s
  • Random 4K R/W: Up to 1,000,000 IOPS
• Why NVMe over SATA?
  • NVMe drives have significantly higher throughput and lower latency than SATA SSDs.
  • Drives without DRAM (DRAMless) or with QLC flash are not advised, due to lower endurance and potentially lower sustained performance.
• On Endurance (TBW)
  • Running a node involves frequent writes (e.g., database updates, logs). Ensure that the SSD’s Total Bytes Written (TBW) rating is sufficient for multi-year operation.
• Capacity Considerations
  • As of January 2025, 2 TB can still work, but daily chain growth makes 4 TB more future-proof.
  • While EIP-4444 aims to reduce historical storage requirements, the timeline for EIP-4444 remains uncertain.

Memory

• Why 64 GB for Validators (Attesters / Local Block Builders)?
  • Running an Ethereum validator (both EL & CL clients) can be memory-intensive, with state cache dominating RAM usage.
  • Certain memory intensive client combinations have historically failed with 16 GB. It is possible to tune cache size in different clients to make it work, however we do not assume that the average user will do this.
  • Preliminary benchmarks highlighting zk-STARK memory usage suggest cryptographic operations can demand significant RAM.
  • Relative to total hardware costs, upgrading from 32 GB to 64 GB is a small price but can improve stability and is more future proof with regards to zk-STARKs.

CPU

• Single vs. Multi-thread Performance
  • Attesters and local block builders benefit from both high single-thread and multi-thread performance.

Bandwidth

Local Block Builders

• Recommended: 100 Mbps download, 50 Mbps upload.
• Rationale:
  • Distributing blocks is highly bandwidth-intensive.
  • If a builder cannot meet these speeds, they risk slower propagation and causing late blocks.
  • In extreme cases, a low-bandwidth node could propose partially full blocks or one that includes fewer blobs to mitigate slow broadcast.

Attesters

• Recommended: 50 Mbps download, 25 Mbps upload.
• Minimum tested: 15 Mbps (as per ethPandaOps simulations where 40% of the network had Gigabit connections and the other 60% had 15 Mbps upload).
  • However, real-world performance depends on peer network topology. A node with poor bandwidth could in theory quickly share data with a well-connected peer with good bandwidth which means that this peer could quickly seed the network.
• Rationale:
  • 25 Mbps was chosen as a buffer to account for these miscellaneous factors that are harder to predict.

Validators Using MEV-Boost

• Recommended: 50 Mbps download / 25 Mbps upload.
• Rationale:
  • Most MEV-relay interactions involve fetching bundles and block headers, which can be done within typical broadband speeds.
  • While the local validator will also share the block with its peers, the relay will do the same which reduces the need for local bandwidth.
  • However, there may be cases where your validator will still build a local block, such as if no MEV-relay responds or if the value of the MEV reward is lower than the minimum configuration set in MEV-Boost. In these circumstances, the recommendations for Local Block Builders would be relevant.

Full Nodes

• Recommended: 50 Mbps download / 15 Mbps upload.
• Rationale:
  • Full nodes currently participate in sampling and must track the chain tip, but are not as latency-sensitive as attesters or local block builders.
  • They can operate on lower bandwidth but risk being a slot or more behind the chain if bandwidth capacity is severely limited.

Quick Reference Summary

• Full Node

  • Storage: 4 TB NVMe
  • RAM: 32 GB
  • CPU: 4 cores / 8 threads (~1000 ST / ~3000 MT PassMark)
  • Bandwidth: 50 Mbps down / 15 Mbps up

• Attester

  • Storage: 4 TB NVMe
  • RAM: 64 GB
  • CPU: 8 cores / 16 threads (~3500 ST / ~25000 MT PassMark)
  • Bandwidth: 50 Mbps down / 25 Mbps up

• Local Block Builder

  • Storage: 4 TB NVMe
  • RAM: 64 GB
  • CPU: 8 cores / 16 threads (~3500 ST / ~25000 MT PassMark)
  • Bandwidth: 100 Mbps down / 50 Mbps up

Backwards Compatibility

This EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware recommendations.

Security Considerations

N/A

Copyright

Copyright and related rights waived via CC0.