diff --git a/EIPS/eip-7870.md b/EIPS/eip-7870.md new file mode 100644 index 00000000000000..a62e11604dade9 --- /dev/null +++ b/EIPS/eip-7870.md @@ -0,0 +1,118 @@ +--- +eip: 7870 +title: Hardware and Bandwidth Recommendations for Validators and Full Nodes +description: System recommendations for Validators and Full nodes +author: Parithosh Jayanthi (@parithosh), Kevaundray Wedderburn (@kevaundray), Josh Rudolf (@jrudolf), Dankrad Feist (@dankrad), Justin Traglia (@jtraglia), Ignacio Hagopian (@jsign), George Kadianakis (@asn-d6) +discussions-to: https://ethereum-magicians.org/t/hardware-and-bandwidth-recommendations-for-full-nodes-and-validators/22675 +status: Draft +type: Informational +created: 2025-01-26 +--- + +## Abstract + +This proposal specifies hardware and bandwidth recommendations for full nodes and validators. Validators are split into attesters and proposers. The resource-intensive aspect of block proposal lies in creating the block and broadcasting the data required for attesters to validate it. We use the term "local block builder" to further emphasize this separation. + +We note that you may be able 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 implementations +- Enabling informed decision-making about protocol upgrades and their resource usage implications +- Providing clear guidance for node operators with respect to the future + +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 + +### Recommended hardware and bandwidth specifications + +| Node type | Storage | RAM | CPU cores | CPU Single Thread/Multithread rating | Download/Upload speed | +| ------------------- | ------- | ---- | ------------------ | ------------------------------------ | --------------------- | +| Full node | 4TB | 32GB | 4 cores/8 threads | 1000 / 3000 | 50 Mbps / 15 Mbps | +| Attester | 4TB | 64GB | 8 cores/16 threads | 3500 / 25000 | 50 Mbps / 25 Mbps | +| Local block builder | 4TB | 64GB | 8 cores/16 threads | 3500 / 25000 | 100 Mbps / 50 Mbps | + +- The CPU rating is a measure of how powerful a particular CPU is for single and multithreaded respectively. All numbers referenced are normalized according to PassMark. + +## Rationale + +### Storage + +For storage, we recommend an SSD with the following metrics: + +- Sequential Reads: 7,000 MB/s +- Sequential Writes: 7,000 MB/s +- Random 4K Reads: Up to 1,000,000 IOPS +- Random 4K Writes: Up to 1,000,000 IOPS + +In particular, we recommend purchasing NVMe M.2 with DRAM cache and TLC flash for storage instead of SATA as NVMe has higher throughput. NVMe drives that are DRAMless or use QLC flash are not advised. + +As of January 2025, the storage requirements for all node types are dominated by the need to store block history. +A 2TB disk can be used; however, this is not recommended due to the rate of history growth and the uncertainty as to when EIP-4444 will be completed. + +### Memory + +Memory (RAM) is dominated by state cache. As of January 2025, it is possible to run a full node with 16GB of RAM, however this has been known to not work with all combinations of EL and CL clients in the past. + +On 32GB vs 64GB; 32GB works right now, however we recommend 64GB as [preliminary benchmarks](https://hackmd.io/@han/bench-hash-in-snark) have shown that zk-STARKS can consume a significant amount of memory and the difference in cost relative to the entire hardware setup for a validator is insignificant. + +### Bandwidth + +- Statista states that as of January 2024: + - The global average download for broadband is 92 Mbps and the global average upload is 43 Mbps. + - The global average download for mobile is 50 Mbps and 11 Mbps. +- GSMA report showing the state of mobile internet connectivity in 2024 shows that: + - The mobile upload speeds in Higher Income Countries (HIC) is about 18 Mbps. + - The global average mobile download is 48 Mbps. + +Although most users will be using fixed broadband as opposed to mobile broadband. We include the mobile broadband figures as a way to approximate lower bounds. + +#### Local block builders + +For validators that want to build blocks locally, we recommend global bandwidth figures inline with the global average for fixed broadband: 100 Mbps download and 50 Mbps upload. + +*If a block builder does not have the recommended bandwidth, we recommend that they build a block that is partially full and or one that includes fewer blobs.* + +#### Attesters + +For attesters, we recommend 50 Mbps download and 25 Mbps upload. + +The minimum value recorded to work as of January 2025 has been ~15 Mbps. This was recorded in simulations done by ethPandaOps where 40% of the network had Gigabit connections and the other 60% had 15 Mbps upload. + +The minimum value could be lower than this and is highly dependent on your network topology. +For example, if you are connected to peers who have gigabit connections, but you yourself have subpar bandwidth, it may be sufficient for you to only send your data to the first peer and in the time it takes you to send data to your mesh, the first peer might have seeded the network. + +The 25 Mbps was chosen as a buffer to account for these miscellaneous factors that are harder to predict. + +#### Validators using mev-boost + +The recommendation for validators using mev-boost is the same as the recommendations for attesters. + +#### Full nodes + +For full nodes, whom want to follow the tip of the chain, we recommend 50 Mbps download and 15 Mbps upload. + +Full nodes currently participate in sampling, however since they are not latency sensitive like attesters and local block builders, we can lower their recommended upload bandwidth. + +The recommended download speed is kept the same, so that they are able to follow the chain at the same speed as an attester. + +Note: A full node will still be able to operate at significantly lower bandwidth, however depending on how low they may be at least a slot behind the chain. + +## 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](../LICENSE.md).