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.
A from-genesis sync of a patches-only build stopped at block 9,189,161, the
futureEipsTime activation, with a stateroot mismatch. Two causes, one patch:
upstream bases futureEips on the unreleased amsterdam definition while chain
2800 isolates it on Osaka, and the fleet activates EIP-2935 history storage in
the same fork, one system state write per block that a build without this
patch never performs. With 0005 applied the same node, same data directory,
crossed the activation and keeps importing. The fleet's optional Block-STM
wiring is deliberately omitted and the omission is stated in the patch header.
Pristine d2032017, plain git apply of 0001+0003+0004, installDist exit 0 on
JDK 21, besu/v26.8-develop-d203201. Stated next to what it does not prove:
the import proof against the live chain is still owed.
The table carried the hash of an earlier derived export; the published file
has been the fleet's byte-for-byte genesis since the registry-binding commit.
The line-ending caveat is written next to it because that is exactly how the
wrong hash survives review on a Windows checkout.
The published line delivered the anchor (source and patch 0003) but had lost
the chain configuration: no genesis, no run recipe. The unpublished local line
had genesis.json, RUN-A-NODE.md and the measured claims, but predated the
anchor. This commit carries the package files onto the anchor line:
- genesis.json restored, byte for byte as the running nodes hold it
- RUN-A-NODE.md restored; the basefee-floor patch returns as 0004; the anchor
section states plainly that a build without patch 0003 has not been shown to
import headers past block 13,014,000, and that an import proof for a
patches-only build is the next thing this repository owes its reader
- bootnodes are deliberately NOT published: today's entry points are consensus
or origin hosts, and this project does not print its machines' addresses; a
dedicated bootnode host is the planned replacement, an enode is available by
mail until then