Commit Graph
2 Commits
Author SHA1 Message Date
SatoshiQaziMuhammed 35feb5afe0 Fail the weekly run when the light client checkpoint is stale (#79)
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.
2026-11-03 08:09:44 +04:00
SatoshiQaziMuhammed eb00e49a52 Add light client chain specifications for Zagros (#78)
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.
2026-11-03 00:00:54 +04:00