What a sync from genesis involves, and the one setting that a from-genesis follower needs and a validator does not.
Full sync, not snap sync
Full sync from block 0 is the mode that verifies the published history, and it is what the anchor requires: a node with the anchor rules armed refuses a lighter mode at startup.
Snap sync against a QBFT chain trusts a peer for the state and verifies far less. It is not a faster route to the same guarantee; it is a different guarantee.
Storage format is a local choice and not part of consensus.
Peering
Discovery needs a bootnode enode, and both discovery UDP and peer-to-peer TCP must be open in both directions. The node package explains how to obtain a current enode; a dedicated public bootnode does not exist yet, and that is stated in the package rather than implied.
The only proof that your peering works is your own net_peerCount. A non-zero count after a few minutes means discovery succeeded.
The genesis validator set, and the setting it forces
This is the part that surprises everyone who syncs from block 0, so it is worth reading before you start.
A node syncing from genesis starts into the genesis validator set, which is three validators with a quorum of two, not the nine of today. The anchor threshold guard refuses to arm a minimum of three or six seals against a set of three, so a from-genesis follower with the published schedule will not start at all without one more setting.
The published answer is a ceiling that lowers the effective seal-count floor to quorum(3) - 1 = 1, without editing the schedule. The exact property name is in the package.
State the consequence honestly, because it is a real weakening of one check. With that ceiling, the follower's seal-*count* requirement is 1 at every height rather than 3 or 6.
What is not weakened, and this is most of the check:
- every anchor must still carry a digest binding its certificate under the block hash
- seal indices must still be strictly increasing
- every carried seal is still Falcon-verified against the registry correct for that height
- eligibility in the parent's validator set is still enforced
Real anchor blocks carry between three and nine seals, so all of history imports cleanly. The seal-count floor is a proposer-liveness property relative to the current set, not a history-verification property.
A validator, which starts into the full set, does not set the ceiling.
When the sync is done
Compare your head to a public endpoint, and compare your block 0 hash to 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a before you trust either.
Sizing
Memory is the constraint, not CPU, and the requirement grows with the height. Read Requirements before starting a from-genesis sync; the heap table there is the difference between an import that finishes and one that stops.