Skip to content

SRQ2 Witness-Hiding Upgrade Plan v1

Status: design-and-measurement plan (direct-path rescue lane)
Scope: fixed confidential-transfer statement only

1) Goal

Convert the current SRQ2 specialized fixed-statement baseline from:

  • compact verifier-facing artifact that carries witness material

into:

  • compact verifier-facing artifact that hides witness material

without reopening:

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

2) Files Inspected

  • packages/zk-backend-mock/src/stark_rq_backend_v1.ts
  • packages/zk-backend-mock/src/stark_rq_relation_v1.ts
  • packages/zk-backend-mock/src/stark_rq_relation_witness_v1.ts
  • packages/zk-backend-mock/tests/stark_rq_backend_v1.test.js
  • docs/benchmarks/zk-backend-stark-rq-v1.json
  • spec/direct-path-minimum-private-relation-v1.md
  • spec/direct-path-proof-size-feasibility-v1.md
  • spec/specialized-fixed-statement-prover-design-v1.md
  • spec/wrapped-verifier-artifact-feasibility-v1.md
  • spec/proof-envelope-transcript-v1.md
  • packages/zk-boundary/src/proof_blob_v1.ts

3) Current SRQ2 Payload Audit

Current SRQ2 proof layout in stark_rq_backend_v1.ts:

  • header: SRQ2 tag + version + lane mask + witness length = 8 bytes
  • backendHook32 = 32 bytes
  • relationHash32 = 32 bytes
  • witnessHash32 = 32 bytes
  • relationWitnessBytes = 980 bytes
  • proofDigest32 = 32 bytes

Current committed proof size:

  • proof bytes: 1116
  • PB blob bytes with current encrypted payload + hints path: 2004

Observed size split:

  • raw witness carriage: 980 bytes
  • non-witness framing: 136 bytes

This means most of the current compactness comes from carrying a fixed, specialized witness bundle directly rather than from a witness-hiding proof system.

4) What Is Privacy-Sensitive and Must Leave the Artifact

The following current SRQ2 proof content is not acceptable for the final confidential path:

4.1 Must be removed entirely

  • relationWitnessBytes

Reason:

  • it directly serializes the confidential relation witness into the verifier-facing artifact
  • it includes sender/receiver key material, note leaves, nullifier material, receiver Merkle path data, and duplicate anchor fields

4.2 Must disappear in current form

  • witnessHash32
  • current relationHash32

Reason:

  • witnessHash32 is a verifier-visible hidden-witness alias
  • current relationHash32 is built from witness-derived evaluation material (sourceNoteHash32, receiverNoteHash32, note roots, nullifier roots), so it is also not the right long-term verifier-visible field in its current form

4.3 Should also disappear to save direct-path budget

  • backendHook32 inside the proof payload
  • laneMask
  • witnessLen

Reason:

  • backendHook32 is public and can be recomputed from PIv1 + PBv1 sections during verification
  • laneMask is fixed by the single fixed-statement profile
  • witnessLen exists only because the current proof literally embeds witness bytes

5) Narrowest Witness-Hiding Upgrade Strategy

Recommended narrow strategy:

  • keep SRW1 as a prover-only internal witness object
  • replace witness-carrying SRQ2 with a new fixed-statement witness-hiding proof payload
  • keep the same frozen public statement, the same PBv1 proof-artifact boundary, and the same host-validated shell boundary
  • do not widen PBv1, PIv1, or verifier ABI

5.1 Public inputs stay unchanged

The verifier continues to consume only the frozen public statement (shardId32, stateIn32, stateOut32, outputFingerprint32) plus the PBv1 PROOF artifact bytes. No additional verifier-visible inputs are introduced.

5.2 Prover-only witness stays internal

The internal relation witness continues to include the same fixed-statement private facts:

  • note ownership material
  • note inclusion path material
  • nullifier derivation material
  • receiver note creation material
  • sender change note creation material
  • committed-value conservation witness values
  • transition-consistency witness values

But those bytes must no longer be serialized into PROOF.

5.3 SRQ3-style replacement shape

The narrowest credible replacement is a same-statement witness-hiding proof object with a fixed verifier shape:

  1. proof header:
  2. proof tag
  3. proof version
  4. fixed statement profile id / encoding id
  5. optional public-only statement binding:
  6. derived only from public anchors and host-recomputable transcript inputs
  7. not from hidden witness aliases
  8. specialized witness-hiding proof object:
  9. commitment/opening/authentication bytes for the seven irreducible private facts
  10. fixed ordering and deterministic encoding
  11. final proof authenticator / transcript tail

The verifier recomputes public anchors and host-visible transcript commitments locally, then checks only the witness-hiding proof object.

5.4 Why this is narrower than wrapping first

This strategy preserves the same fixed statement and only replaces the proof core.

It does not:

  • introduce staged carriage
  • introduce wrapper-of-wrapper complexity
  • reopen statement design
  • require transport changes

So it is the smallest honest path from compact witness-carrying baseline to compact witness-hiding baseline.

6) What Verifier-Visible Fields Must Remain

Verifier-visible fields that remain acceptable:

  • backendId in PBv1
  • proof tag/version/profile metadata
  • fixed witness-hiding proof bytes
  • final proof authentication bytes

Verifier-visible fields that should not remain as standalone payload items:

  • raw witness bytes
  • witness hashes
  • witness-derived relation hashes in current SRQ2 form
  • duplicate public inputs that verifier can recompute from PIv1/PBv1

7) Expected Artifact-Size Impact

7.1 Byte budget released by removing the current baseline fields

Current bytes that can disappear or be absorbed into the new proof transcript:

  • relationWitnessBytes: 980
  • witnessHash32: 32
  • current relationHash32: 32
  • backendHook32 payload copy: 32
  • laneMask: 1
  • witnessLen: 2

Total reclaimable budget: approximately 1079 bytes

That reclaimed budget is what the witness-hiding proof core must fit inside if we want to stay near the current high-value direct-path range.

7.2 Direct-path ladder for the replacement proof

With slim proof framing, the witness-hiding proof core likely lands in one of these zones:

  • ~1–2 KB total proof bytes:
  • still high-value direct-path range
  • strongest outcome for this upgrade path
  • ~2–4 KB total proof bytes:
  • still conditionally direct-path relevant
  • worth continuing, but now under meaningful PBv1 pressure
  • >4096 proof bytes:
  • fails current PBv1 proof cap
  • no longer a meaningful direct-path candidate without a different boundary

7.3 PB blob implications with current transport path

Current proof blob delta above proof bytes is 888 bytes:

  • 136 bytes of PB header + section table
  • 618 bytes encrypted payload
  • 134 bytes hints

So a witness-hiding proof of:

  • 1.5 KB implies a blob near 2.4 KB
  • 3.0 KB implies a blob near 3.9 KB
  • 4.0 KB implies a blob near 4.9 KB

That still preserves direct-path relevance only if the proof section itself remains under 4096 bytes and the resulting unlock path stays meaningfully inside the BCH direct envelope.

8) Honest Judgment

Judgment: conditionally direct-path relevant

Why:

  • the current artifact exposes almost 1 KB of witness bytes directly, so witness-hiding does not start from zero budget headroom
  • the host/prover split is still doing useful work by keeping shell and transport validation out of the proof core
  • but there is no measured evidence yet that the witness-hiding proof core will stay in the ~1–2 KB range

More explicit view:

  • ~1–2 KB still looks credibly reachable enough to justify implementation
  • ~2–4 KB remains viable but conditional
  • above 4096 proof bytes should be treated as a direct-path failure under current frozen PBv1

Recommendation: implementation now

Exact next ticket to create:

  • TKT-P3-58 — Prototype a witness-hiding SRQ3 artifact for the fixed confidential-transfer statement

That ticket should:

  • keep the frozen statement and host/prover split unchanged
  • replace raw relationWitnessBytes in the verifier-facing artifact
  • remove current witness-visible alias fields from the payload
  • measure proof bytes immediately against this ladder:
  • ideal: ~1 KB class
  • high-value: ~1–2 KB
  • conditional: ~2–4 KB
  • hard PBv1 problem: >4096 proof bytes
  • outer BCH direct ceiling: 10,000 unlock bytes/input

What should not happen next:

  • wrapping first
  • staged carriage work
  • generic proving framework work

Those only become relevant after the first witness-hiding specialized baseline is actually measured.

10) Acceptance Mapping

  • Exact current privacy-sensitive payload identified: Yes
  • Narrowest witness-hiding replacement path stated: Yes
  • Frozen protocol boundary preserved: Yes
  • Direct-path ladder kept explicit: Yes
  • Next step recommendation explicit: Yes (implementation now)