DocumentsWhat comes next

Commission brief: a zero-knowledge proof that a label is the band of its document

5 min readSource commission-zk.mdsha256 59759829c7547d04…

Status: not commissioned. No cryptographer or firm has been engaged and no budget has been set. This is the brief we would send. Mirror will not hand-roll this proof; until a reviewed implementation exists, every verdict keeps stating asserts.label_equals_value_band: "not_proven_here".

1. The gap this closes#

Two banks' banders each commit a band label for the same shipment. The operator compares those commitments. It never sees a value, a band or a salt.

What the verdict proves today:

  • the committed labels agree, or they do not;
  • which member signed each label;
  • that the label a bander committed matches the document its trade platform signed at booking (mirror-origin) — but only when someone opens it at audit, after the fact.

What no verdict proves at the moment it is signed: that the label is the band of the value in that signed document. A bander that commits a false label is caught with certainty at the first opening, but not before the clear.

A zero-knowledge proof attached to each leg would move that from audit time to verdict time, without revealing the value, the document, the salt or the band.

2. The relation to prove#

Notation:

  • H is SHA-256.
  • ‖ is byte concatenation.
  • lp(x) is len(x) ‖ ":" ‖ x, with the length as decimal ASCII.
  • Every string is ASCII.

Public inputs (per leg)

InputWhat it is
C_oThe origin commitment, "o:" ‖ hex(H(lp(ρ) ‖ lp("mirror:origin:v1") ‖ lp(canon(doc)))). It is signed ES256 by a ratified origination key at booking; that signature is verified outside the proof.
EThe ratified corridor edges, a sorted list of positive decimals. The parties hold the table; the operator holds ratified edges by design.
tThe ratified tolerance, an integer from 0 to 6.
{c_b}The leg's published commitment set, c_b = hex(H(σ ‖ ":" ‖ dec(b))), for every band b in the window below.
ctxA binding context: the leg's shipment_ref (an opaque locator commitment), its role, and the corridor reference. A proof must not transplant onto another leg.

Private witness

WitnessWhat it is
doc{ value, unit_qty, currency, basis, terms_hash }, the figures the trade platform booked. canon is Mirror's canonical JSON (recursively sorted keys; decimals as their shortest exact string).
ρThe 256-bit document salt, kept with the document in the trade platform.
σThe per-shipment corridor salt, HMAC-SHA256(K_corridor, "mirror:" ‖ ref). It may be supplied as a witness directly.

Statement. There exist doc, ρ and σ such that all of the following hold:

  1. C_o opens to doc under ρ, as defined above.
  2. β = bandOf(doc.value, doc.unit_qty, E), in exact decimal: β is the number of edges e in ascending order for which value / unit_qty > e, stopping at the first that fails. Each comparison is the integer cross-multiplication v·10^(s_e+s_q) > e·q·10^(s_v) over decimal mantissas and scales. No floating point; 2065.84 / 17 must band exactly as 121.52.
  3. The published set {c_b} is exactly { H(σ ‖ ":" ‖ dec(b)) : b ∈ [max(0, β−t), β+t] }, in ascending order. If the corridor sets edge_margin, the near-edge extension in mirror-kernel.commitLeg also applies. Supporting it is optional in a first version, but it must be declared.
  4. The proof is bound to ctx.

The reference semantics are the functions bandOf and commitLeg in kernel/mirror-kernel.js, and originCommitment in kernel/mirror-origin.js. When prose and code disagree, the code wins, and the disagreement is a finding.

3. Constraints#

  • No trusted setup is strongly preferred: a transparent system. A universal setup is acceptable only with a public, multi-party ceremony transcript that no single party, including Mirror, controls.
  • The prover runs inside the bank, beside the bander, on commodity servers. It has no network and no GPU requirement. The bank's figures never leave its perimeter, not even to a proving service.
  • The verifier runs anywhere, offline: in a browser (the console and the examiner pack) and in Node (the operator and the bander), as JavaScript or WebAssembly, with no network calls. A proof that fails to verify makes the leg undetermined, never a pass.
  • Hash choice:
    • Proving against the deployed SHA-256 commitments is preferred.
    • If that is prohibitive, propose a v2 commitment, for example a circuit-friendly hash over fixed-width fields. Say how it is bound alongside v1 at booking, and give a migration path.
    • Any hash must have published cryptanalysis we can cite.
  • Mirror adds nothing that looks like judgement:
    • The proof yields one bit per leg: proven or not.
    • No score, no probability, no ranking, no filing decision.
    • The operator must not need any secret or witness data to verify.

4. Acceptance criteria#

  1. A specification: the relation, the proof system, the encoding of exact decimals, and a security argument for soundness and zero-knowledge.
  2. An independent review: a second cryptographer who did not write the implementation reviews the specification and the code. The report is published.
  3. Differential testing against the kernel. On a published corpus, the prover accepts exactly the legs that commitLeg produces from the signed document, and nothing else. The corpus includes values sitting exactly on an edge, the first and last bands, tolerance 0 to 6, and decimal scales up to 12 places.
  4. Negative tests that must fail:
    • a label off by one band;
    • a value altered from the signed document;
    • a salt that is not the corridor's;
    • substituted edges;
    • a widened tolerance;
    • a proof moved to another leg, role or shipment;
    • a malleated proof.
  5. Measured performance: prover time, verifier time and proof size, measured and reported on stated hardware. These are reported numbers, not targets we assert today.
  6. Fail-closed integration:
    • asserts.label_equals_value_band becomes "proven" only when every judged leg carries a verifying proof;
    • anything else leaves "not_proven_here";
    • a verifier error is undetermined.
  7. Licensing that lets the verifier ship inside Mirror's published, offline verification kit.

5. Deliverables#

  • The specification and the review report.
  • Circuit or AIR source, with build instructions that reproduce the verification key.
  • A prover command-line tool the bander can call offline.
  • A verifier in JavaScript or WebAssembly, with an integration note for mirror-leg and mirror-assertion.
  • Test vectors, positive and negative, in the format of /conformance-vectors.json.
  • Benchmarks, with the hardware stated.

6. What the proof will not do#

  • It will not make a document true. A platform that books a false document gets a correctly proven false label. Only an independent witness on the price or the goods (mirror-bulletin, the independence gate) answers that.
  • It will not price anything. There is no oracle and no computed price table, before or after.
  • It will not make the operator's comparison zero-knowledge or MPC. The comparison stays equality of salted commitments, and the verdict record keeps saying so.

7. How a proposal is judged#

In order:

  1. soundness argument and reviewability;
  2. no trusted setup;
  3. fidelity to the deployed exact-decimal semantics;
  4. verifier size and speed offline;
  5. prover cost inside a bank.

A proposal that asks for the operator to hold witness data, or for a single party to run a setup, is out of scope, whatever its performance.