run-node.sh folds the four manual steps (apply patches, build the fork, load the
registries, set BESU_OPTS) into a single deterministic, idempotent command. It
verifies the genesis sha256 and every registry against SHA256SUMS and refuses on
mismatch; applies patches 0001,0003,0004,0005 on a pristine upstream checkout
(0002 testnet excluded) with a reverse-apply idempotence check; builds with
installDist; starts a follower with the correct BESU_OPTS. It holds no key.
The registries a from-genesis follower needs were missing from this package, only
the code that reads them was here, so nobody outside could cross block 13,014,000.
Added them as public data (Falcon public keys, validator addresses, possession
proofs; no private material), byte-identical across three independent validators,
with SHA256SUMS and a provenance README. Secret gate passes.
Proven from a fresh git clone in WSL, as a stranger: built (BUILD SUCCESSFUL),
idempotent on re-run, started, loaded all three registries with verified
possession proofs, block-0 hash equals the network genesis, and synced from block
0 with zero anchor rejections and zero stateroot mismatches.
A real finding this test surfaced, fixed and documented: a from-genesis node
starts into the genesis validator set N=3, where the published seal schedule
(K=3 at 13,034,000, K=6 at 14,961,456) is unreachable, so PqAnchorThresholdGuard
refuses to start. The fix baked in is the guard's own documented remedy,
minSealsCeiling=1, which relaxes only the seal-count floor (a proposer-liveness
property) without weakening the PQ binding: every anchor still needs a valid
registry-verified Falcon seal. A validator does not set this.
Honest limit: crossing 13,014,000 was not reached in-session because the two
public bootnodes serve historical block bodies at only ~7 blk/s sustained (ETA
~19 days), and syncing bodies from validators would breach the read-only fleet
rule. The crossing rests on these registries being byte-identical to those in the
Aug 15 import proof that reached the live tip.
