Skip to content

docs: clarify full node hardware requirements - #835

Open
yjkellyjoo wants to merge 2 commits into
masterfrom
fix/full-node-hw
Open

docs: clarify full node hardware requirements#835
yjkellyjoo wants to merge 2 commits into
masterfrom
fix/full-node-hw

Conversation

@yjkellyjoo

Copy link
Copy Markdown
Member

What does this PR resolve? 🚀

Corrects the documented full node hardware requirements and removes framing that made running a full node sound more demanding than it is.

  • Fixes the RAM figure: full nodes were documented as needing 8 GB; the actual ceiling is 500 MB, including while playing the redistribution game. The wrong figure appeared in three separate places.
  • Makes node-types.md the single source of truth for full node requirements. getting-started.md and faq.md now link to #full-node-specifications instead of carrying their own drifting copies.
  • Corrects the staking resource claim: the sampler was documented as having "high computational and memory requirements". It is CPU-bound, not memory-bound — 4 cores are sufficient.
  • Reframes the hardware bar across five pages: all three node types run on ordinary consumer hardware. The real differences for a full node are disk space, sustained bandwidth, and a funded blockchain connection.

Details 📝

The three copies of the full node spec had drifted apart (30 GB SSD vs. 20–30 GB NVMe), and the FAQ copy was the only one listing the on-chain funding requirements. Both lists are now merged into node-types.md under two groups — hardware, and blockchain/funding — so nothing was dropped in consolidation.

The :::warning above the full node spec list became an :::info placed below it. It previously primed readers to expect heavy requirements before showing them numbers that are anything but; it is guidance about staking, not a hazard.

Wording changes that followed from the corrected numbers:

  • staking.md — "resource intensive" → "CPU-intensive", with the 4-core figure and an explicit note that memory is not the constraint.
  • bee-api.md/rchash benchmarks "your node's processor is fast enough" rather than "hardware is sufficient", since CPU is what it measures.
  • node-types.md — dropped "requires more system resources" and "without the overhead of running a full node".
  • Vague phrasing like "practically any modern computer" replaced with the concrete specs plus a reference point (laptops, desktops, or a Raspberry Pi with an attached SSD).

getting-started.md also gains a ## Requirements parent heading, with software/hardware/network demoted beneath it — the FAQ's #requirements anchor now points there. Some headings in faq.md were promoted from ##### to ###, which had been nested under a question rather than under a section.

No pages were added, renamed, or deleted.

Verification

npm run build:check passes: 0 broken internal links, 0 broken links in the built HTML (7,731 checked), 0 external 404s. The new #full-node-specifications, #requirements and #node-types-overview anchors were confirmed present in the build output, and all inbound links to them resolve.

The link checker also reports 16 stale external redirects, 7 unverifiable URLs and 6 llms.txt gaps. All are pre-existing on master and unrelated to these lines, so they are deliberately left for a separate link-maintenance PR.

Checklist ✅

  • Merged latest master and resolved conflicts
  • npm run build succeeds
  • Links checked (npm run check:links) where relevant
  • static/llms.txt updated if pages were added / renamed / deleted
  • Content follows CODING.md conventions (Swarm vs swarm, ..)
  • Self-reviewed the diff
  • Commits are signed off (git commit -s)

- have `node-types.md` as the single source of truth of requirements and others refer to that

Signed-off-by: Yejin Kelly Joo <yejinkellyjoo@gmail.com>
- Document modest baseline requirements for all node modes
- explain the added disk, bandwidth, blockchain, and CPU needs for full
  nodes and staking.

Signed-off-by: Yejin Kelly Joo <yejinkellyjoo@gmail.com>
@yjkellyjoo yjkellyjoo self-assigned this Aug 14, 2026
@netlify

netlify Bot commented Aug 14, 2026

Copy link
Copy Markdown

Deploy Preview for test-twitter-preview-testing-3 ready!

Name Link
🔨 Latest commit 2e6e0e0
🔍 Latest deploy log https://app.netlify.com/projects/test-twitter-preview-testing-3/deploys/6a7ee49273d2b40008e98209
😎 Deploy Preview https://deploy-preview-835--test-twitter-preview-testing-3.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Comment on lines +482 to +483
For both anchor parameters, use the first 4 hex digits from your node's overlay address (which you can find from the `/addresses` endpoint).
For depth, use the current storage depth of your node from the `/status` endpoint (`storageRadius` value):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Would it make sense to recommend swarm-cli utility rchash command here?

- **Internet**: High-speed and stable connection.
- **RPC endpoint**: A connection to Gnosis Chain (see [setting the blockchain RPC endpoint](./configuration.md#setting-blockchain-rpc-endpoint)).
- **xDAI**: Minimum 0.1 xDAI for Gnosis Chain gas fees.
- **xBZZ**: 1 xBZZ for the initial chequebook deployment.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Wrong terminology.

1 xBZZ for the initial chequebook deposit.

Deployment only needs xDAI.

Also, funding the chequebook with xBZZ is optional.

If you intend to participate in the redistribution game to earn storage incentives, you should test your setup using [the `/rchash` endpoint](./bee-api.md#rchash) in order to ensure that your hardware is sufficient. Participation in the redistribution game requires a process with high computational and memory requirements, along with significant bandwidth usage.
:::info
Staking raises the CPU demand but not the memory demand.
Nodes selected for the redistribution game run the sampler process, which is CPU-bound and bandwidth-hungry; 4 cores are sufficient for it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is it really bandwidth hungry?

@crtahlin

Copy link
Copy Markdown
Collaborator

One caveat on the /rchash advice. Sampling time scales with how full the reserve is within radius: in my experience a node holding around 2M chunks (a practical lower bound) takes roughly half as long as one at around 4M (the upper bound). That is consistent with the code, since the sampler walks every chunk in radius. Crucially the operator cannot choose what they sample against — reserve occupancy at any given moment is a property of the network, not a setting — so an /rchash run only characterises the node against whatever the reserve happens to hold at that time. A comfortable result measured at 2M says little about the same node at 4M. Suggest the docs make clear that a single passing measurement is not a guarantee, and that operators should want real headroom rather than treat a marginal pass as sufficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants