Skip to content

docs(installation): mention blob storage CPU and disk impact #9320

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
0xghost42 wants to merge 1 commit into
base: unstable
Choose a base branch
from
+12 −1
Open

docs(installation): mention blob storage CPU and disk impact #9320

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 12 additions & 1 deletion book/src/installation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,4 +34,15 @@ After [The Merge](https://ethereum.org/en/roadmap/merge/) on 15<sup>th</sup> Sep

> *Note: 16 GB RAM is becoming rather limited due to the increased resources required. 16 GB RAM would likely result in out of memory errors in the case of a spike in computing demand (e.g., caused by a bug) or during periods of non-finality of the beacon chain. Users with 16 GB RAM also have a limited choice when it comes to selecting an execution client, which does not help with the [client diversity](https://clientdiversity.org/). We therefore recommend users to have at least 32 GB RAM for long term health of the node, while also giving users the flexibility to change client should the thought arise.

Last update: April 2023
### Blob storage considerations

The system requirements above cover a default beacon node with a modest validator workload. Running with full blob retention — and especially as a [supernode archive](./advanced_blobs.md) — significantly increases both CPU and storage demands.

If you intend to store blob history beyond the rolling retention window, or if you plan to run with `--supernode` or `--semi-supernode`, plan for:
Copy link
Copy Markdown
Member

@chong-he chong-he May 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the proper term is "data availability window", we can say this and then add in a bracket (18 days) for clarity


- **CPU:** a faster single-core clock (around 5 GHz) helps keep up with blob verification under load.
Copy link
Copy Markdown
Member

@chong-he chong-he May 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if it is a good idea to put 5 GHz here.

From the data here: https://browser.geekbench.com/processor-benchmarks, the base speed is all < 5 GHz. While it can be overclocked, but I don't think staking operators will tend to do this.

For simplicity we can just remove the number here

- **Storage:** several TiB of fast SSD space. Storing the full set of data columns as a supernode, or running with `--prune-blobs false`, can require multiple TiB of additional storage on top of the standard beacon node database.

See the [Blobs](./advanced_blobs.md) page for the supported retention modes, the `--prune-blobs` and `--blob-prune-margin-epochs` flags, and detailed notes on supernode sizing.

Last update: May 2026
Loading