docs: clarify full node hardware requirements - #835
Conversation
- 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>
✅ Deploy Preview for test-twitter-preview-testing-3 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| 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): |
There was a problem hiding this comment.
Would it make sense to recommend swarm-cli utility rchash command here?
There was a problem hiding this comment.
absolutely!
a3946ed added swarm-cli utility rchash alongside the API usage into tabs
| - **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. |
There was a problem hiding this comment.
Wrong terminology.
1 xBZZ for the initial chequebook deposit.
Deployment only needs xDAI.
Also, funding the chequebook with xBZZ is optional.
There was a problem hiding this comment.
17a7b09 dropped xBZZ from full node chequebook requirements
| 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. |
There was a problem hiding this comment.
Is it really bandwidth hungry?
There was a problem hiding this comment.
You're right, it's not, it's rather disk I/O heavy.
4e86b25 corrected it.
|
One caveat on the |
crtahlin
left a comment
crtahlin
left a comment
There was a problem hiding this comment.
Approving.
- The RAM correction is right, and the consolidation works: after this change exactly one RAM figure remains anywhere in the docs (
node-types.md), with no stale 8 GB left behind. - All three new anchors (
#full-node-specifications,#node-types-overview,#requirements) resolve in the built preview. awesome-lintis clean — the only warnings are the five that already exist onmaster.- The "4 cores" figure is well grounded:
pkg/storer/sample.gorunsmax(4, runtime.NumCPU())workers.
Two points already raised by @Cafe137 that I'd echo, both verified against Bee source:
- Chequebook funding —
--swap-initial-depositdefaults to0(cmd/bee/cmd/cmd.go) andpkg/settlement/swap/chequebook/init.goonly requires xBZZ ≥ that deposit, so with defaults no xBZZ is needed; deployment costs xDAI gas only. Worth listing the xBZZ as an optional deposit. - Sampler bandwidth —
pkg/storer/sample.goimports no networking or retrieval package; it iterates the local reserve and skips chunks that fail to load rather than fetching them. It is local disk I/O plus CPU, so "bandwidth-hungry" is worth dropping.
Neither blocks this PR. Separately, the /rchash advice has a gap that predates this change — see my comment above (#issuecomment-5292852749) on sampling time depending on reserve occupancy.
Description generated with help of AI.
xBZZ is not required to deploy a chequebook. Deploying the contract costs xDAI gas only, and the initial xBZZ deposit is optional: `swap-initial-deposit` defaults to `0`, and the chequebook init path only requires xBZZ to be greater than or equal to that deposit. The claim also contradicted two existing pages, which already document the deployment as xDAI-only: - fund-your-node.md lists "Chequebook Deployment" as < 0.001 xDAI and no xBZZ. - configuration.md describes the deposit as optional and defaulting to zero. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yejin Kelly Joo <yejinkellyjoo@gmail.com>
The sampler was described as "bandwidth-hungry", and the /rchash troubleshooting advice named RAM as a main bottleneck. Neither holds: pkg/storer/sample.go imports no networking or retrieval package and reads chunks from the local chunk store, skipping any that fail to load. It never fetches from the network. What it does do is walk every chunk in radius, so the real constraints are processor speed and disk I/O. This is also why the specifications call for an SSD rather than an HDD. - node-types.md: describe staking as raising CPU demand and disk I/O. - bee-api.md: name disk and processor as the bottlenecks in the slow results warning, and drop the "consider more RAM" advice, which contradicted the corrected 500 MB figure. - staking.md: note that a slow disk can also cause a sampler timeout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yejin Kelly Joo <yejinkellyjoo@gmail.com>
`swarm-cli utility rchash` needs no arguments: it reads the node's overlay address and committed depth and derives the anchor and depth parameters itself. The raw endpoint requires assembling both by hand, so the CLI is the better default. The API form stays fully documented in a second tab. Also corrects the depth guidance to use `committedDepth` rather than `storageRadius`, matching what swarm-cli passes. The two are equal unless `reserve-capacity-doubling` is set, in which case benchmarking at `storageRadius` measures a smaller sample than the node actually has to produce. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yejin Kelly Joo <yejinkellyjoo@gmail.com>
Sampling time scales with how full the reserve is within radius, since the sampler walks every chunk in radius. Reserve occupancy follows network conditions and is not something an operator can choose, so a node measured against a half-full reserve can take roughly twice as long once the reserve approaches the default capacity of ~4M chunks. A marginal pass under the 360 second ceiling therefore says little about the same node later. Operators should look for real headroom rather than treating a single passing measurement as sufficient. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yejin Kelly Joo <yejinkellyjoo@gmail.com>
@crtahlin Thanks for the comment. |
3 participants
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.
node-types.mdthe single source of truth for full node requirements.getting-started.mdandfaq.mdnow link to#full-node-specificationsinstead of carrying their own drifting copies.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.mdunder two groups — hardware, and blockchain/funding — so nothing was dropped in consolidation.The
:::warningabove the full node spec list became an:::infoplaced 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—/rchashbenchmarks "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".getting-started.mdalso gains a## Requirementsparent heading, with software/hardware/network demoted beneath it — the FAQ's#requirementsanchor now points there. Some headings infaq.mdwere 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:checkpasses: 0 broken internal links, 0 broken links in the built HTML (7,731 checked), 0 external 404s. The new#full-node-specifications,#requirementsand#node-types-overviewanchors 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
masterand unrelated to these lines, so they are deliberately left for a separate link-maintenance PR.Checklist ✅
masterand resolved conflictsnpm run buildsucceedsnpm run check:links) where relevantstatic/llms.txtupdated if pages were added / renamed / deletedSwarmvsswarm, ..)git commit -s)