Verifier Family Feasibility v1 (Fixed Statement, BCH)¶
Status: decision record (selection gate), pre-commit
Scope: one fixed confidential-transfer statement only
1) Fixed Statement Scope (Non-Expandable in v1)¶
- one spend note
- one receiver note
- one sender change note
- committed-value conservation
- nullifier correctness
- note inclusion
- state transition consistency
- tokenized continuation output binding
- no batching
- no recursion
- no aggregation
- no generalized multi-cell support
No protocol object changes are allowed by this selection memo.
2) Verifier-First Candidate Matrix¶
All estimates are engineering ranges for first BCH-feasible integration and must be validated by kernel prototype measurement.
| Family | Proof Size Estimate (v1) | Verifier Input Shape | On-Chain Arithmetic Burden | On-Chain Hash Burden | Likely CashAssembly Pain Points | Public-Input-Only Verification Natural? | Setup Assumptions | BCH Fit |
|---|---|---|---|---|---|---|---|---|
| Pairing SNARK-style (Groth16/PLONK-KZG family) | sub-kilobyte to few KB (family-dependent) | curve points + public inputs | very high (pairing/MSM heavy, non-native) | low-medium | pairing and curve arithmetic in script dominate feasibility risk | yes | trusted or universal (variant dependent) | poor |
| STARK/FRI-style, reduced-query verifier profile | ~40 KB to ~120 KB target range | commitments + transcript challenges + bounded openings + public inputs | medium | high | proof-carrier bytes and transcript/hash cost concentration | yes | transparent | best initial fit |
| Hybrid incremental path (compression/wrap-first) | can be lower than raw STARK if successful | compressed artifact + commitments + public inputs | medium-high | medium-high | complexity and architecture risk before baseline verifier measurement | potentially | mixed | conditional fallback |
| Custom hash-heavy fallback | highly variable, often large | hash commitments + custom openings + public inputs | medium | very high | byte/hash explosion and bespoke verifier maintenance burden | yes | transparent | fallback only |
3) Selection¶
Selected family for v1 path: STARK/FRI-style with a reduced-query verifier profile tuned for BCH kernel constraints.
Why this wins verifier-first: - avoids non-native pairing primitives - preserves public-input-only verifier interface in final path - aligns with host transcript/binding machinery already frozen - keeps setup trust assumptions simple (transparent)
Assumption this selection makes explicit: - this is not a generic off-the-shelf verifier profile; - it requires a custom reduced-query verifier configuration that is BCH-budget aware.
4) Rejection Reasons (One Sentence Each)¶
- Pairing SNARK path: rejected because verifier arithmetic primitive mismatch (pairings/MSM) is the dominant BCH blocker even with attractive proof bytes.
- Hybrid path: rejected as first choice because it adds architecture complexity before proving base verifier feasibility on BCH.
- Custom hash-heavy fallback: rejected as primary because it tends to push excessive hash and byte pressure on-chain without clear interoperability benefit.
5) BCH Budget Pressure Assessment¶
Primary pressure axes: - proof bytes in proof carrier / unlock path - unlocking bytecode and script size growth - op count in bounded verification loops - arithmetic complexity in kernel checks - transcript and Merkle hashing costs
Pressure concentration: - host-side pressure: parsing, canonical binding, tokenized continuation/output checks - kernel-side pressure: algebraic opening checks, query verification, transcript-dependent validation
6) First De-Risking Prototype (Required Before Family Lock)¶
Prototype goal: - validate/falsify reduced-query STARK/FRI verifier feasibility on BCH for fixed statement boundary.
Smallest experiment: - one fixed transcript lane - one commitment/opening lane - one bounded query path - public-input-only verifier entrypoint (no witness input)
Success criteria: - public-input + proof-only verification executes in BCH VM harness - measured script/op/byte metrics fit a provisional envelope - mutation cases fail deterministically
Failure interpretation: - if this minimal lane fails budget targets, raw selected path is not viable without significant proof-carrier/ABI adjustments.
Fallback if failure: - move to hybrid incremental fallback only if it preserves fixed statement, fixed public ABI, and public-input-only verifier semantics.
7) Required Guardrails¶
- do not reintroduce public-value shell semantics
- do not require public receiver marker
- do not allow verifier-side witness dependence
- do not drift fixed statement scope