aere-research/aips/aip22-conformance/README.md

AIP-22 conformance vectors

The corpus that section 9 of AIP-22 asks for: header and registry cases on which every client of chain 2800 must reach the same verdict, each case with the verdict the two existing clients reached on it. Published 2026-09-27. VECTORS.json is generated from the working corpus in one place; do not edit it by hand.

What a vector is

field	meaning
kind	one of the nine kinds listed in section 9
valid	true: a conforming client admits it; false: a conforming client refuses it
blocks	what is judged: for a header rule [parent, header] (a rule on the validator list or on an anchor needs the parent); block fields as eth_getBlockByNumber returns them
mutatedField	for a generated vector, the single field in which it differs from the vector it is derivedFrom
expectedReason, reasonTag	for an invalid vector, the reason a conforming client must refuse it for; refusing it for another reason does not conform
registryVector	for the registry kind: the manifest judged and the one before it
verdicts	what each client did: admitted or refused, the refusal text it wrote, the tag that text maps to, and conforms

When a vector changes something under the block hash (the anchor certificate, through the digest in vanityData), the header hash is recomputed from the header in its on-chain form, and the digest is re-bound, so that the vector fails only for the field it names. The kinds list at the top of VECTORS.json counts, per kind, the valid and invalid vectors and how many of them both clients judged conformingly.

Where the vectors come from

• Valid vectors are real blocks of the public testnet 28001, each read from the nodes of both clients and identical there (hash and extraData): the set translation at H_id, an anchor on the Falcon-512 grid, a hybrid anchor, a stage-5 header with its proposer seal, a registry epoch with a key rotation.
• Generated vectors are derived from them, one field each: every invalid one, and the short certificate cut to exactly K rows, which is valid.
• Registry vectors are the 19 shared vectors of the v3 registry forms (section 3; two valid epochs, seventeen refusals, one per refusal code).
• Equivocation pairs are the objects recorded on chain 28001 by the stage-6 drill, judged by the evidence contract through each client's EVM and Falcon-512 precompile (eth_call, no transaction).
• The certificate with a surplus scheme needed a seal that no node had made: on chain 28001, SLH-DSA-SHA2-128s is required only on its 128-block grid, so no anchor on the 32-block Falcon-512 grid carries one. It was made for this corpus on 2026-09-27: the SLH-DSA-SHA2-128s key of the testnet validator holding row 0 of the v3 epoch in force signed M(parent) of anchor 3,288,320, on that validator's own host, with the node's own classes; before the signature was kept, a real Falcon-512 seal of the same certificate was checked to verify over the same M (and not over a changed one), and the new signature to verify under row 0's published key (and not over a changed M). The provenance is inline in the vector (sealProvenance).

How the verdicts were reached

Each client's own rule classes were run on the vectors, in each client's test build (a Besu-derived and a Nethermind-derived client), with the published configuration of chain 28001: the v3 registry epochs, the anchor-interval and scheme schedules, the stage heights. The verdicts are those of the rules in the clients' source at the date; that the nodes of chain 28001 run those rules is shown separately, on the live chain, in the stage records of AIP-22. The two harnesses are not part of this directory.

A third client conforms on a vector when it admits a valid one, and refuses an invalid one for the reason in reasonTag.

Not yet in the corpus (2026-09-27)

Section 9 names nine kinds; eight are here. The ninth, a classical-only fork of 31 blocks, is not yet a static vector. Its behaviour was measured on a live rehearsal network, with a Besu-derived reader on 2026-09-23 and with readers of both clients on 2026-09-24 (recorded in AIP-22's stage record of 2026-09-27): a reader fed the fork follows it until the height of the next anchor, which the fork cannot certify, and moves to the anchored chain when it reaches it; with the anchor rule disarmed, the same reader stays on the fork. A static form needs the fork's blocks, which only a rehearsal network's keys can make, and a configuration other than chain 28001's.