The wallet now refreshes its light client specifications from this repository through the signed
config, so a wallet that never fell back no longer starts from the checkpoint its APK was built with.
That only helps if the checkpoint here is kept fresh.
light_client_specs.py --check-age DAYS reads the relay checkpoint's block number from light-client/,
compares it with the live head, and fails past DAYS. Code Quality runs it weekly with 60 days. The
README asks for the specifications to be regenerated before signing.
light-client/zagros.json and light-client/people-zagros.json are what the
wallet's embedded light client starts from.
The full specifications carry the raw genesis storage, about 3 MB each.
These carry only the genesis state root, which identifies the chain:
- The relay specification adds a checkpoint (lightSyncState) exported by
the relay node through sync_state_genSyncSpec. It is 7.3 KB.
- People has no checkpoint, because the relay chain's finality covers it.
It is 732 bytes.
Boot nodes put the /wss addresses on 443 first and keep the plain TCP ones.
scripts/light_client_specs.py writes both files. It checks every state root
by rebuilding the genesis header and comparing its hash with the chain's
genesis hash. A root with one byte changed is refused.
The checkpoint is a trust anchor: a client that starts from a false one can
follow a false chain. It reaches the wallet inside the APK or through
signed/targets.json, never from peers. Targets are re-signed (version 3,
689 files).
The secret scan lets through the four public chain-data keys these files
carry: stateRootHash, finalizedBlockHeader, babeEpochChanges and
grandpaAuthoritySet.