aere-network/aere-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

AIP-22 erratum, section 9: conformance vectors are to be published (none yet); the stage proofs on 28001 are the two clients checked against each other on a live chain

Browse Source
This commit is contained in:
Aere Network 2026-09-25 01:32:33 +03:00
parent cd0b36af8d
commit c40c52d3b6
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
aips/AIP-22.md
View File

@ -181,7 +181,7 @@ Per block: the hash chain (one keccak of the header, already done), the proposer
### 9. Cross-client determinism and conformance
Both clients of chain 2800 MUST: compute the same `id` from the same key; load, hash and refuse the same v3 registries; translate the set identically at `H_id`; order the validator list identically; accept and refuse the same anchors under the same scheme-interval schedule and thresholds; roll back the same provisional tail on the same anchor; verify the same equivocation objects. Conformance vectors are published with the reference implementation: a v3 registry with rotation, a set translation at a fixed height, a Falcon-only anchor, a hybrid anchor, a short certificate, a certificate with a surplus scheme, a proposer seal, an equivocation pair, a classical-only fork of 31 blocks; each invalid vector is refused by both clients for its stated reason (the lesson of AIP-20: a negative vector differs from the valid one in exactly one field, and the refusal names the field).
Both clients of chain 2800 MUST: compute the same `id` from the same key; load, hash and refuse the same v3 registries; translate the set identically at `H_id`; order the validator list identically; accept and refuse the same anchors under the same scheme-interval schedule and thresholds; roll back the same provisional tail on the same anchor; verify the same equivocation objects. Conformance vectors are to be published with the reference implementation (not yet published at 2026-09-24; the stage proofs on chain 28001 so far are the two clients checked against each other on a live chain, which is not the same deliverable): a v3 registry with rotation, a set translation at a fixed height, a Falcon-only anchor, a hybrid anchor, a short certificate, a certificate with a surplus scheme, a proposer seal, an equivocation pair, a classical-only fork of 31 blocks; each invalid vector is refused by both clients for its stated reason (the lesson of AIP-20: a negative vector differs from the valid one in exactly one field, and the refusal names the field).
## Rationale
@ -282,6 +282,7 @@ Two refinements to the text above, recorded rather than silently applied: the Me
## Errata
- 2026-09-24, Backwards Compatibility: the text said that ECDSA-quorum light clients need another path "after `H_fin`". Read in their guest program (`verify_finality` in the QBFT finality crate of the ZK light client), they stop earlier, at `H_id`, because the set they match seals against becomes a list of `id`s there. Corrected in place; nothing else in the section changes.
- 2026-09-24, section 9: the text said that conformance vectors "are published" with the reference implementation. No AIP-22 vector corpus is published yet; the sentence now says they are to be, and says what has been done instead (both clients checked against each other on chain 28001 at every stage).
## Post-Acceptance Outcome Record