edfc637ebd
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. |
||
|---|---|---|
| .. | ||
| manifest-13014000.json | ||
| manifest-13600000.json | ||
| README.md | ||
| registru-2800-v2-13600000.properties | ||
| SHA256SUMS | ||
Falcon validator registries for chain 2800
These files are the public Falcon-512 validator registries that a node must hold to validate the
post-quantum certificate anchor (see ../anchor/README.md and ../RUN-A-NODE.md). Without them a
from-genesis node imports fine up to block 13,014,000, the first anchor, and then refuses every
anchor block, because the seal-validation rule cannot map a certificate's seal indices to validator
addresses. The refusal is deliberate and fail-closed: AERE-PQC-REG-BLOCK-01.
What is in a registry, and why it is safe to publish
Each entry binds a validator index to:
pk/ the row value: the validator's Falcon-512 public key..addr: the validator's chain-2800 account address (already public on-chain in every seal)..pop: a Falcon proof-of-possession, signed by that row's key. Proves someone holds the private key for this public key..claim: an ECDSA signature by the validator's own account. Proves the validator asked for this key, so that whoever writes the file cannot credit a seal to an index they do not control.
There is no private key material here. Falcon signing keys are never in this repository and are not on the same footing as these files on the hosts: the registries are world-readable, the signing keys are mode 600 and stay on the validators. The repository's secret gate passes on this directory (0 findings) precisely because every byte is public.
Files
| File | Bind height | Keys | Role |
|---|---|---|---|
manifest-13014000.json |
13,014,000 | 7 | the registry in force from the first anchor; carried in registry.history |
registru-2800-v2-13600000.properties |
13,600,000 | 9 | the nine-validator registry from the set expansion; carried in registry.history |
manifest-13600000.json |
13,600,000 | 9 | the head registry, passed as aere.falcon.manifest |
SHA256SUMS carries the digests. Verify after copying:
sha256sum -c SHA256SUMS
006b1b3fb814ed84622539160956263faca7c0b76585c22f2e8acb926c0bcb7f manifest-13014000.json
23736b7d4ba1d3213496f8b5a5f756d5c958b08efebdeb1329b24d7dfa45fb6e manifest-13600000.json
c9a215d294e106f69fb2f16e3af21f9787523969e4b7260a3098f4b2cf458059 registru-2800-v2-13600000.properties
Provenance
Fetched from the running fleet and cross-checked so that these are the bytes the network validates against, not a local rebuild. Each of the three files was read from three independent validator hosts and produced the same sha256 on all three. A registry is only meaningful if it is the one the chain was signed against; a fingerprint that agrees across three independently operated hosts is that evidence. The digests above are those agreed fingerprints.
How a node uses them
A following node wires the head registry through aere.falcon.manifest and the older registries
through aere.falcon.registry.history (comma-separated, never pruned: a node syncing from genesis
verifies every block ever produced, so every registry ever scheduled has to stay reachable forever).
run-node.sh in the parent directory does this for you. The exact flags are printed there and echoed
at start.