Update "Getting started" part of the book #4938
Conversation
move how-to's to the how-to section
|
Can I get a review? |
| | Security | Light | **Full** | | ||
| | Disk usage | ~70GB | **<1MB** | | ||
| | Bandwidth | *TBD* | **TBD (low)** | | ||
| | Sync time | Days | **Seconds** | |
There was a problem hiding this comment.
Is it worth addressing usage of https://nimbus.guide/trusted-node-sync.html in the context of sync time?
It's true that even backfill (I hesitate to call it "backwards sync", because at some level the node is synced enough to perform validation duties immediately) to MIN_EPOCHS_FOR_BLOCK_REQUESTS might require days, though it should typically be more hours, since it's not rerunning actual state transitions and not going back to genesis, so this is not inaccurate as such.
Indeed, at some point the EF might start more strongly and explicitly recommending against (forwards) genesis sync, since it's before the weak subjectivity period, so I'm not sure how relevant this sort of "sync time" remains or will remain.
https://nimbus.guide/trusted-node-sync.html#delay-block-history-backfill though allows
to get started more quickly by delaying the backfill of the block history using the --backfill=false parameter. In this case, the beacon node will first sync to the current head so that it can start performing its duties, then backfill the blocks from the network.
So this summary is a bit incomplete.
There was a problem hiding this comment.
Is it worth addressing usage of https://nimbus.guide/trusted-node-sync.html in the context of sync time?
This is a page about the light client, so I'm not sure if we should go into details about "offtopic" stuff.
Would just changing 'Days' to 'Hours' be enough?
But we mention 'several days' in other places too (e.g. https://nimbus.guide/trusted-node-sync.html), so this needs to be unified.
There was a problem hiding this comment.
Well, to the extent any of this is off-topic for the light client discussion, having a summary table making that particular comparison already is.
But sure, changing "days" to "hours" consistently for this would be fine to start with.
|
|
||
| !!! info | ||
| Syncing an execution client may take hours or even days, depending on your hardware! | ||
| Syncing an execution client **may take hours or even days**, depending on your hardware! |
There was a problem hiding this comment.
One aspect that might be worth mentioning, or not -- it seems to be kind of folklore-ish knowledge not widely documented that I've found, though it might just be that I've not seen such documentation: there's a threshold IOPS (roughly) below which each different EL client simply won't finish syncing because it has no surplus I/O for the purpose.
Various people have tested/benchmarked this, and typical SSDs, both SATA and NVMe, are fine, but every so often someone comes to the Nimbus Discord server reporting a never-ending EL client sync, and it's typically with such low-end hardware or low-quality VPS hosting.
However, it's kind of a caveat that hopefully will be decreasingly relevant, and maybe a bit discouraging to present up-front given that it's both uncommon and not catastrophic. So I'm not sure here is the best place to document this.
There was a problem hiding this comment.
Is this something that should maybe go in https://nimbus.guide/hardware.html, where we mention minimal/recommended requirements?
There was a problem hiding this comment.
Addressing this (or not) in https://nimbus.guide/hardware.html (or not) can be another PR; no need to get everything in this one.
There was a problem hiding this comment.
Addressing this (or not) in https://nimbus.guide/hardware.html (or not) can be another PR; no need to get everything in this one.
Yes, I was/am planning to do that in a separate PR, as I wanted to keep this one concentrated only on the 'getting started' part of the guide.
Thanks for merging, this now unblocks my future PRs, built on top of this.
There was a problem hiding this comment.
Addressing this (or not) in https://nimbus.guide/hardware.html (or not) can be another PR; no need to get everything in this one.
Now addressed in #5059
Co-authored-by: tersec <tersec@users.noreply.github.com>
The "Getting started" quickstart guide should contain information on how to, well, quickly start with Nimbus (and not more) — the metrics and migration how-to guides are moved to the how-to section of the book, as that is more suited.
philosophy.mdis removed and its contents are part of the index page. This way the design goals (and Nimbus strengths) are immediately seen, and (IMO even more importantly) now when you click on the 'next' on the landing page, you're directly taken to the getting started with beacon node guide.Build prerequisites are now part of the "Prepare your machine" (
install.md), as this is cleaner, avoids duplication and unnecessary information (this is linked both from the 'getting started' guide and the 'build from source' how-to).The quickstart guide now offers both 'download binaries' (link to the binaries guide, instead of duplication) and 'build from source' options for installing Nimbus.
Other than those, several minor (cosmetic, if you will) fixes and improvements.
Here's a quick before/after screenshot:
