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

Prover integration

The prover adapter (crates/adapters/prover) is the surface for proof generation and verification. It implements scenario-core’s ProofProviderService and VerifierService contracts in two ways.

The deterministic fixture double (posture scenarios)

FixtureProver is backed by proof fixtures whose posture (valid / invalid / tampered / malformed) drives outcomes, and binds each proof to its statement via a fingerprint over the public inputs and optional state digest. Verification recomputes the fingerprint from the request and reports a stable reason when it disagrees or the posture says the proof is bad. Circuit-version checks are modeled: a request pinning a different version is refused as wrong-circuit.

Negative and adversarial scenarios need a prover that can emit an invalid, tampered, or malformed proof on demand; only the double can do that, so posture scenarios keep running against it.

The real adapter (crucible-prover service machinery)

RealProver replaces the double behind the same contracts wherever the scenario must exercise the prover’s actual pipeline. It depends on the crucible-prover repository (pinned revision) and runs requests through ProverService:

  • canonical ABI-complete requests per protocol operation (crucible-prover’s own fixtures, the same request vocabulary its tests and canaries use),
  • preflight validation — a request missing circuit-ABI private or public names is rejected before any backend runs,
  • provider dispatch and versioned ProofEnvelope assembly,
  • a mandatory local verification round-trip: a proof that fails its own round-trip is never handed onward,
  • the real verification-key digest from the produced envelope.

The registered provider is crucible-prover’s deterministic mock backend, so the real pipeline runs hermetically in CI — exactly the backend crucible-prover’s own default CI uses.

Neither adapter is a cryptographic prover. The fixture double exercises orchestration and binding semantics; the real adapter exercises the genuine prover service contract (request validation, envelope assembly, round-trip verification, precise failure reasons). Proofs produced by either must never be described as cryptographically valid (spec §53); the repository’s docs, PR template, and report labels all say so.

Real-crypto separation

Runs over the fixture double and the real (mock-backend) adapter are both mock validation. The test-vectors corpus labels proof behavior expectations (valid/invalid/tampered/malformed fixtures) as fixture-driven. When real UltraHonk/bb proving is exercised (in crucible-prover’s dedicated CI), the same adversarial mutations (proof tampering, public-input mutation, wrong circuit, stale state) run against real verification. Wiring real UltraHonk behind these same contracts would make the conformance pack real behavior vs an independent oracle — the remaining step after the simulator ledger is unified through a real adapter.

Boundary

No proving logic is implemented in this repository (spec §3). Proof requests carry only public inputs; scenario-core rejects any GenerateProof step whose public inputs name a confidential field, so witnesses never cross this interface.