36 lines
4.5 KiB
Markdown
36 lines
4.5 KiB
Markdown
# AIP-22 conformance vectors
|
|
|
|
The corpus that section 9 of [AIP-22](../AIP-22.md) 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.
|