65 lines
3.5 KiB
Markdown
65 lines
3.5 KiB
Markdown
# live-conformance/sink-energy — sink decode energy
|
||
|
||
The corpus of [`extensions/sink-energy.md`](../../extensions/sink-energy.md) §9: decode
|
||
tables, segment receipts and their chains, and session receipts with their per-hop split,
|
||
each with the outcome a verifier gives it; and, under `tables/`, the measured decode tables
|
||
of the reference sinks, each with its readings and its procedure.
|
||
|
||
**Equivalence.** For each case, a conforming verifier given the case's `record`, the
|
||
`readings` file (or none, when `null`), the `tables` it holds, the `segments` it holds and the
|
||
hop records it holds (`hops`, by digest, from the top-level `hops`) reaches the outcome the
|
||
case states (§7): `accept`, or the first reason §7 refuses it with. For `subject` `chain` the
|
||
record is `null`, and the case is the stream of receipts in `segments`, in segment order:
|
||
each receipt is verified (§7 steps 1–5) and then the chain (§5.3); the outcome is the first
|
||
receipt's refusal, or `segment_chain_broken`, or `accept`. An accepted case states the
|
||
`identity` of its record (for a chain, of its last receipt). A verifier that reaches another
|
||
outcome does not conform.
|
||
|
||
Each measured table under `tables/<sink>/` is accepted with its `readings.json` held:
|
||
`table.json` is the record, `readings.json` the readings file whose SHA-256 is its
|
||
`readings_sha256`, and `procedure.txt` the procedure text whose SHA-256 is its
|
||
`procedure_sha256`.
|
||
|
||
**Provenance.** The cases are generated here: `wai_sink_energy_vectors gen` writes
|
||
`vectors.json` from values written in code and keys derived from fixed seeds (each key is
|
||
SHA-256 of the corpus's fixed label and the key's name), and Ed25519 signing is
|
||
deterministic (RFC 8032), so the file is the same bytes on every machine. The bracket
|
||
values, figures and estimator inputs of the cases are synthetic constants chosen to exercise
|
||
the rules, and were measured by nothing. The measured tables are not synthetic: each was
|
||
taken by `wai_sink_table` on the sink its `machine` names, on the date its `measured`
|
||
states, and its readings are the counter readings it took. They are signed with the
|
||
corpus's fixed-seed table key, which names the corpus, not a machine.
|
||
|
||
## Layout
|
||
|
||
`vectors.json`:
|
||
|
||
```
|
||
{ "wai_sink_energy_corpus": 1,
|
||
"keys": { "<name>": "<public key, hex>" }, informative
|
||
"hops": { "<digest, hex>": "<per-hop record WMH1, hex>" },
|
||
"cases": [ { "name": string,
|
||
"subject": "table" | "segment" | "chain" | "session",
|
||
"record": object | null,
|
||
"readings": object | null,
|
||
"tables": [ object ],
|
||
"segments": [ object ],
|
||
"hops": [ "<digest, hex>" ],
|
||
"expect": "accept" | "<reason>",
|
||
"identity": "<hex>" | null } ] }
|
||
```
|
||
|
||
- A `table` case's `record` is a decode table, and `readings` its readings file where the
|
||
verifier holds it.
|
||
- A `segment` case's `record` is one segment receipt, verified on its own (no chain), with
|
||
the decode tables in `tables`.
|
||
- A `chain` case's `segments` are one stream's receipts in segment order, with the decode
|
||
tables in `tables`.
|
||
- A `session` case's `record` is a session receipt, `segments` the session's segment
|
||
receipts (every stream's, each stream in segment order), `tables` the decode tables they
|
||
name, and `hops` the digests of the per-hop records the verifier holds.
|
||
|
||
The hop records are live-metering's `WMH1` (live-metering §3), each of its own room, read as
|
||
that extension's §3.6 reads them.
|
||
|
||
`tables/<sink>/table.json`, `readings.json`, `procedure.txt`: the measured tables (§4).
|