Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Proof testing

Proof testing covers how scenarios generate, verify, tamper with, and bind proofs — and what those checks mean given the current adapter.

The prover adapter boundary

crates/adapters/prover implements scenario-core’s ProofProviderService / VerifierService contracts. Today it is a deterministic fixture double: generation names the proof fixture the operation declares and binds the proof to the statement’s public inputs via a fingerprint; verification recomputes that fingerprint from the request and reports a stable reason (tampered-proof, malformed-proof, input-binding-mismatch, state-binding-mismatch, wrong-circuit, unknown-proof) when the fixture posture or the binding disagrees.

This is not cryptographic verification. Packs built on the double exercise orchestration and binding semantics. Wiring crucible-prover behind the same contracts makes the same scenarios real verification checks without changing them.

What the packs exercise

  • Valid proofs — a transfer’s generated proof verifies against its statement before the transfer executes (flows, conformance).
  • Invalid / tampered / malformed proofs — negative pack: each posture fails verification with the specific reason.
  • Public-input mutation — adversarial pack: changing a bound input invalidates the proof; permuting inputs does not change the verdict.
  • Stale proofs — adversarial pack: a proof generated against state A is refused after the state moves to B.
  • Version compatibility — crates/compatibility: a proof verifies against the same circuit version, is refused as wrong-circuit against a different version, and identical statements produce deterministic artifacts.
  • Replay protection — regression pack pins the fixed behavior: duplicate content under a new id is refused.

Privacy

Proof public inputs carry only public protocol values (token, sender, recipient, circuit). scenario-core rejects at definition time any GenerateProof step whose public inputs name a confidential field (amount/witness/secret/…), so confidential values never cross the proof interface.