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.
60 lines
3.1 KiB
Markdown
60 lines
3.1 KiB
Markdown
# 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.
|