signed/root.2.json carries the root drafted in docs/root-signing/proposals (threshold 2 of
3 new sr25519 holders, five years, targets key unchanged) with two signatures from the
previous root's keys and two from the new ones, all valid under the "substrate" context
that installed wallets check. Wallets already follow signed/root.N.json, so they move to
the new root on their next config refresh.
The consumed proposal is removed; the CI check runs with no proposals present.
Regenerated with light_client_specs.py: the relay checkpoint moves from block 538187 to 543420. The id,
genesis state root and boot nodes are unchanged, and so is the People specification. Wallets keep a
fetched specification only for a later checkpoint of the same chain, so this reaches every wallet that
fetches it. targets.json is re-signed as version 4.
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.
* feat(config): sign the served config files
signed/targets.json gives the sha256 of every JSON file the wallet may
fetch, signed with an Ed25519 targets key. signed/root.json names that
key and three sr25519 root keys (wallet accounts), two of which can
replace it; the wallet will ship this first root.
scripts/signed_config.py writes the root, signs the targets list and
checks it. Code Quality now refuses a tree whose served files do not
match the signed list, and runs weekly so an expiring signature shows a
month ahead.
* fix(config): sign the test fixtures and follow published roots
The wallet refuses any JSON file from this repository that the signed
list does not give, and its instrumented tests read tests/, so those
files are signed too.
A root after the first is written to signed/root.N.json, where the
wallet looks for it; sign and check use the newest published root.
SatoshiQaziMuhammed