Skip to content

Specialized Fixed-Statement Prover Design v1 (TKT-P3-53)

Status: design memo (implementation-prep)
Scope: one fixed confidential-transfer statement only

1) Goal

Design a specialized prover path for the already-frozen minimized private relation so verifier-facing artifact size can plausibly fit BCH direct-path constraints without widening protocol boundaries.

This is design only. No runtime integration is introduced in this ticket.

1.1 Current backend2 baseline note

The current backend2 artifact measured in this repo is a specialized fixed-statement baseline, not a final confidential proof.

It remains useful because it measures a compact verifier-facing artifact shape under the frozen PIv1/PBv1 boundary. The current SRQ3 payload is witness-hiding in the narrow sense that it no longer carries encoded relation witness bytes directly, but it is still not the final confidential prover path. Current verification checks statement-bound artifact integrity for a committed relation object, not yet a production witness-hiding proof of the seven confidential relation facts.

2) Frozen Boundaries (Not Reopened)

This design preserves unchanged:

  • PIv1
  • PBv1 semantics
  • transcript commitment discipline
  • transport binding rules
  • OFm2/v2
  • tokenized continuation invariants
  • wallet recovery behavior
  • no public receiver marker rule
  • confidential amount mode
  • final verifier ABI rule: public inputs + proof artifact only
  • host/prover split from spec/direct-path-minimum-private-relation-v1.md

3) Public Input vs Private Witness Mapping

3.1 Public inputs (verifier-visible)

From frozen verifier ABI:

  • shardId32
  • stateIn32
  • stateOut32
  • outputFingerprint32
  • backend selector (backendId) in PBv1
  • proof artifact bytes in PBv1 PROOF section

3.2 Private witness (prover-only)

Specialized witness (fixed statement cardinality):

  • spent note ownership material (key/witness needed to authorize spend note)
  • spent note inclusion path material for pre-state root
  • nullifier derivation preimage material
  • receiver note private construction inputs
  • sender change note private construction inputs
  • confidential committed-value arithmetic witness values
  • deterministic transition wiring witness values linking spend/update results to stateOut32

3.3 Host-side forever (never prover obligations)

  • PIv1/PBv1 canonical parsing
  • transcript/transport binding verification
  • OFm2/v2 recomputation from real BCH outputs
  • tokenized continuation shell checks:
  • continuation index rule
  • fixed carrier sats profile
  • category/capability continuity
  • tokenCommitment == stateOut32
  • malformed carrier/section rejection

4) What the Specialized Prover Proves

For the fixed statement, the specialized prover proves exactly:

  1. note ownership
  2. note inclusion
  3. nullifier correctness
  4. receiver note creation
  5. sender change note creation
  6. committed-value conservation
  7. transition consistency to frozen public anchors (stateIn32, stateOut32, outputFingerprint32)

outputFingerprint32 is consumed as a public anchor binding confidential relation facts to host-validated output reality.
It is not a source of confidential amount semantics.

5) Why This Should Be Smaller Than Generic Backend Paths

Artifact-reduction logic in this specialized design:

  1. No transaction-shell validity proving inside prover.
  2. No transcript parsing/section-order proving inside prover.
  3. No OFm2/v2 recomputation proving inside prover.
  4. No tokenized continuation shell proving inside prover.
  5. Fixed cardinality (1 spend, 1 receiver, 1 sender change) removes generality overhead.
  6. Fixed relation lanes enable static verifier query shape instead of generalized VM-trace style openness.
  7. Prover complexity is intentionally shifted off-chain so verifier artifact can stay constrained.

In short: prove only confidential relation facts; keep shell/binding reality checks in host where they are already frozen.

6) Intended Verifier-Facing Artifact Shape (Inside PBv1)

PBv1 semantics remain unchanged; PROOF bytes are backend-family payload.

Specialized payload target shape (conceptual):

  1. proofHeader (version + fixed statement profile id + encoding id)
  2. fixed-count relation commitments (small, fixed vector)
  3. fixed-count opening bundle(s) for the specialized relation lanes
  4. verifier transcript terminal value for relation checks
  5. final proof authentication tail

What should never appear in verifier-facing artifact:

  • raw private witness values
  • full decoded note plaintexts
  • raw inclusion path arrays as transport payload
  • host-side shell validation outputs
  • witness-derived side channels under alternate names

7) Internal Prover-Only Encodings to Freeze Next

These are internal lock-ins for later implementation tickets and do not widen ABI:

  1. Inclusion path encoding:
  2. sibling ordering convention
  3. direction-bit ordering convention
  4. byte/field lifting order for path elements
  5. Committed-value arithmetic encoding:
  6. limb width
  7. limb ordering
  8. carry/borrow normalization rules
  9. Witness normalization:
  10. canonical byte-length/endianness for secret scalars and note fields
  11. normalization before relation evaluation
  12. Deterministic relation transcript-internal encoding:
  13. fixed lane ordering
  14. fixed commitment/opening ordering
  15. deterministic challenge derivation inputs

8) Direct-Path Size Targets This Design Optimizes For

  • ideal wallet-direct target: ~1 KB-class proof-carrier/unlock path
  • outer BCH direct-path ceiling: 10,000 unlock bytes per input
  • staged/aggregated region: any approach meaningfully depending on >10 KB direct carriage assumptions

This design treats 10 KB as outer limit, not primary success criterion.

9) Remaining Unknowns After This Design

  1. Whether a concrete specialized prover runtime can realize low artifact overhead for note inclusion + conservation lanes simultaneously.
  2. Concrete proof-size scaling once internal encodings are frozen and measured.
  3. Verifier arithmetic/hash cost once specialized openings are instantiated.
  4. Whether low-single-digit KB is achievable without wrapper/recursive compression.
  5. Whether wrapper/recursive compression is needed after specialized baseline measurement.

10) Honest Size-Outlook Judgment

Judgment for this design step:

  • sub-10 KB only (currently plausible)

Rationale:

  • The specialization strategy is credible for major size reduction versus generic paths.
  • There is not yet enough measured evidence to claim low-single-digit KB with high confidence.
  • Low-single-digit KB remains a target to test, not a design-stage guarantee.

11) Compatibility Reconciliation

This design remains compatible with:

  • transcript/proof-carrier discipline
  • transport binding compatibility
  • canonical fixture and corpus reuse
  • no disguised witness channels
  • outputFingerprint32 as public relation anchor only
  • visible BCH output sats not representing confidential transfer amount semantics

12) Acceptance Mapping (TKT-P3-53)

  • Specialized to fixed statement: Yes
  • No generic proving framework introduced: Yes
  • No protocol-boundary widening: Yes
  • Host/prover split preserved: Yes
  • Direct-path artifact minimization primary: Yes