or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
On Hardware Requirements For Validators
Summary
Introduction
This document aims to establish a standardized definition of "commodity hardware", or at the least, recommend hardware specifications that we believe to be suitable for validating on Ethereum mainnet.
A clear hardware specification is crucial for:
Without a shared understanding of target hardware specifications:
Organization
Market Analysis
Current Consumer CPU Trends
In order to estimate what popular CPUs people are buying, we did a brief search for popular CPU choices and listed their characteristics. These are not necessarily the most updated models.
High performance Consumer Market
Mid-Range Consumer Market
Existing Staking Community
Recommended Hardware
Overall, we recommend a setup with:
CPU rationale
We substantiate the choice of 8 cores, with the steam hardware survey reference. The majority of CPUs here have either six or eight cores. One can view the steam dataset as being biased towards the low/median end of the gaming market.
The CPU rating scores were decided by looking at the high end CPUs on CPU benchmarks that had sixteen or less cores alongside the current consumer trends analysis done above and finding a rough average that we thought were reasonable.
Storage rationale
The 4TB of storage is due to current history and state growth.
Memory rationale
The 64GB of memory was chosen for two reasons:
Prebuilt
NUC
We recommend the ASUS NUC 14 Pro from the NUC series:
*This seems to be the closest NUC model to match the desire to have 8 cores.
Minisforum UM790 Pro
We recommend the Minisforum UM790 Pro with modifications:
Build Your Own
Below, we list out average prices for the main components needed, if you were to build your own server. The total cost is approximately $1000.
CPU
For 8 cores and 16 threads, the average price for a CPU will be $300-400
Storage
Memory
Motherboard
Role-Specific Requirements
Attesters
Currently there is no meaningful role separation between an attester and a proposer. Hence the hardware requirements for an attester would follow the same hardware requirements as a proposer.
If there was a meaningful separation, then an attester would be run with weaker hardware since they would no longer need to propose.
Aggregators
An aggregator aggregates BLS signatures. With the introduction of post quantum signatures, the job of the aggregator may become more computationally intensive.
There is also currently no meaningful separation between an aggregator and a proposer.
We believe that our recommended hardware requirements satisfies the desired hardware requirements for an aggregator if they were to be separated, so no meaningful changes would need to be done either way.
Proposers
Proposers are assumed to not be powerful enough to compete with centralized block builders, neither is this a goal.
Key points about proposer requirements:
Centralized Block Builder
While out of scope for this document, we note some responsibilities:
Stateless Client
Once we have full statelessness, we envision that validators themselves can be stateless.
This:
The stateless verification procedure fits within our recommended hardware requirements, verification is cheap. We also note that our recommended hardware requirements work both for verkle tries and binary trees with stark proofs. The latter requires more benchmarks using traditional hashes.
Miscellaneous changes
Raising the gas limit
Raising the gas limit increases the rate of history growth, which effects the storage requirements. The analysis from paradigm suggests that without any changes, we have 2 to 3 years before we exceed 2TB. This does not include the storage requirements from the consensus layer(CL) however, Pari from DevOps notes that with the CL we have less than six months before we reach the 2TB limit.
Given that the recommended storage space is 4TB, and we plan to implement EIP-4444 in at most two years. This storage requirement should not pose any issues, even in the case that we double the gas limit.
If a user plans to stay at 2TB, then this may be sufficient, given pre-merge files are pruned in less than six months which frees up ~500GB and 4444 is implemented within a year.
Raising the blob limit
As noted in the paradigm post, the additions of blobs, have reduced the history growth caused by the rollup users, since they have switched from calldata to blob data.
It's unclear whether rollups are switching between calldata and blob data currently, which means that it is unclear as to whether raising the blob limit will affect history growth any further.
Increasing validator count
This section will be handwaved the most since it has a lot of path dependencies with Orbit, 3SF and MaxEB.
We know that for SSF, the validator set needs to be reduced, so at the very least, the bump in hardware specifications should be sufficient enough for any aggregation that happens in SSF.
Acknowledgements
With contributions from Parithosh Jayanthi, Kevaundray Wedderburn, Josh Rudolf, Dankrad Feist, Justin Traglia, Ignacio Hagopian and George Kadianakis. We would also like to thank the external reviewers for their feedback: Nixorokish, Yorick Downe, Rémy Roy, Ben Adams, Vitalik Buterin, Lightclient, Andrew Ashikhmin, Marek Moraczyński, Potuz, Joe Clapis, Haurog, Francis(Base), Jimmy(Lighthouse) and Nico Flaig. Feedback does not imply endorsement of this document.