On 2026-09-05 the five properties a follower needs past blocks 17,047,600 and 17,225,968 were added to
RUN-A-NODE.md but not to run-node.sh, while the document already claimed the script set them. Our own
from-genesis import proof, built from the published revision, synced to block 17,047,400 and then
rejected every hybrid anchor 12,352 times: the v2 activation height stayed at Long.MAX_VALUE. Anyone
following this package could not pass 17,047,600.
Both blocks are now derived from the BESU_OPTS of the network's archive node, whose role is exactly a
follower's, with the two public reading nodes as witnesses that must agree on the anchor set; only the
signing keys are removed and the registry paths rewritten. Re-measured on the same node and database
after the fix: past 17,047,600 with zero rejections.
Founder approved publishing the network entry points. Both are public read hosts
outside the validator set, so their downtime cannot cost consensus, and their
addresses were already public through the services they serve. One runs Besu and
one runs Nethermind, so a new node's first two peers are two independent
implementations. run-node.sh uses both by default; --bootnode still overrides.
The mail path stays as fallback for the day both are down.
This closes the last gap between "one command plus an email" and one command.
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.
