Backend Family / Trust-Model Reassessment v1

Status: decision checkpoint (TKT-P3-67)
Scope: one fixed confidential-transfer statement only

1) Purpose

This memo reassesses backend-family direction after two things became true:

• the completed witness-hiding runtime slice proved the full fixed hidden relation under the frozen boundary
• SRQ3 was integrated honestly against that completed runtime slice

This is not a new semantic-expansion memo. This is not backend implementation work. It is a narrow reassessment of what the project should do next.

2) Measured Evidence

2.1 Completed hidden-runtime slice

From docs/benchmarks/stark-rq-hidden-runtime-v1.json:

• proofBytes = 192
• proofBlobBytes = 1080
• proveMs = 296200.109
• verifyMs = 215.09

Interpretation:

• the full fixed hidden relation can be proven under witness hiding without blowing up verifier-facing artifact size
• the runtime slice completed its semantic job
• proving cost became the main operational pressure inside the current development scaffold

2.2 SRQ3 integration against the completed runtime slice

From docs/benchmarks/zk-backend-stark-rq-v1.json:

• proofBytes = 552
• proofBlobBytes = 1440
• proveMs = 665559.338
• verifyMs = 297.691

Interpretation:

• truthful SRQ3 integration still preserves strong direct-path carriage
• SRQ3 is now honestly backed by witness-hiding proof semantics for the completed fixed hidden relation
• timing pressure rose materially after full integration

3) Direct-Path Status

The direct-path lane remains alive and primary.

Current ladder placement:

• ideal proof-carrier class: ~1 KB
• high-value PB range: ~1–2 KB
• conditional PB range: ~2–4 KB
• hard PBv1 problem: >4096 proof bytes
• outer BCH direct ceiling: 10,000 unlock bytes/input

Current measured placement:

• hidden runtime slice alone: 192 proof bytes, 1080 PB bytes
• integrated SRQ3: 552 proof bytes, 1440 PB bytes

Conclusion:

• compact verifier-facing carriage is no longer the primary unresolved question for this phase
• the direct-path rescue lane remains justified
• staged carriage should remain fallback, not primary

4) Groth16 Status After Measurement

4.1 Primary judgment

The current Groth16 sidecar remains a runtime-validation scaffold only.

There is no honest basis, from the current evidence, to treat it as the final backend-family answer.

4.2 Why it remains scaffold-only

• the current sidecar uses a deterministic development setup cache
• trusted-setup or setup-dependent families do not satisfy the strongest trustless target for the final BCH path
• pairing-SNARK-style verifier families remain a poor BCH fit because non-native verifier arithmetic is still the dominant kernel concern
• the measured carriage win does not erase the setup-assumption problem
• the measured timings do not justify normalizing the current scaffold as if it were deployable

4.3 Honest limited case for extending it further

There is one honest reason to extend the Groth16 scaffold further:

• temporary regression, benchmarking, and boundary-integration support while the next trustless-family prototype is built

That use is acceptable only if it is labeled explicitly as:

• runtime-validation only
• not final backend-family selection
• not final trust-model resolution

It should not receive new work that assumes deployability, finality, or long-term verifier-family commitment.

5) Tradeoff Ranking After Measurement

The dominant tradeoffs have changed.

5.1 No longer primary

Verifier-facing carriage size is no longer the top uncertainty for this phase.

Why:

• SRQ3 stayed at 552 proof bytes and 1440 PB bytes after full honest integration
• that remains comfortably direct-path relevant

5.2 Now primary

The most important tradeoffs now are:

1. trust model and setup assumptions
2. BCH verifier-family fit
3. proving time
4. verification time
5. carriage size

Explanation:

• trust model and setup assumptions are decisive because they determine whether the path can become an honest final confidential prover rather than a measurement scaffold
• BCH verifier-family fit matters because the final target is not merely off-chain proof generation, but a path that can inform a BCH-feasible verifier direction
• proving time is now the main operational pressure for iteration
• verification time matters, but it is currently secondary to the trust-model and verifier-family questions
• carriage size has already crossed from open risk into demonstrated strength for this fixed statement

6) Candidate-Family Reassessment

6.1 Primary next family direction

The primary next family to investigate remains:

• transparent or trustless reduced-query STARK/FRI-style verification specialized to the fixed confidential-transfer statement

Why this remains primary:

• it preserves the strongest trust-model target
• it aligns with the earlier verifier-family feasibility memo
• it avoids normalizing setup-dependent families as the final answer
• it is the most honest next step after the carriage question has been answered positively

6.2 Conditional fallback direction

The next fallback direction remains:

• hybrid or wrapped compression only if a later trustless-family prototype causes artifact-size regression that materially harms direct-path viability

Why this remains deferred:

• current carriage is already strong
• there is no size emergency to justify taking on wrapping complexity first
• wrapping should solve a measured artifact regression, not an imagined one

6.3 Benchmark-only direction

The following may still exist as comparison or scaffolding families, but should not be treated as the main deployable path:

• Groth16 / pairing-SNARK-style development slices
• other setup-dependent families whose main current value is measurement or scaffolding

Use case:

• compare artifact size and proving/verification behavior
• preserve regression baselines
• de-risk boundary integration

Not an acceptable finality claim:

• “proof bytes are small, therefore this family is the answer”

6.4 Fallback-only direction

The bespoke hash-heavy family remains fallback-only.

It should only move up if:

• the reduced-query transparent path fails BCH budget feasibility, and
• no simpler trustless-family direction preserves the frozen boundary

7) Answers To The Ticket Questions

7.1 Is the current Groth16 sidecar still only a runtime-validation scaffold?

Yes.

It should remain a runtime-validation scaffold only. Its only honest extension case is temporary benchmarking/regression support while a trustless-family prototype is being built.

7.2 Which backend-family candidates should be considered next?

Shortlist:

1. transparent fixed-statement reduced-query STARK/FRI-style path as the primary next candidate
2. hybrid or wrapped compression only as a conditional fallback if the transparent path regresses artifact size
3. Groth16 or other setup-dependent families only as measurement scaffolds, not as deployable direction
4. custom hash-heavy path only as fallback-of-last-resort

7.3 What tradeoff matters most now?

Most important:

• trust model
• setup assumptions
• verifier-family fit on BCH

Operational pressure to monitor:

• proving time

Less urgent than before:

• verifier-facing carriage size

7.4 Does direct-path BCH confidential transfer remain primary?

Yes.

The measurements justify keeping direct path primary. Nothing in the current evidence forces a pivot to staged carriage.

7.5 Should wrapping remain deferred unless a later backend change causes size regression?

Yes.

Wrapping remains deferred unless a later family change pushes artifact size out of the current high-value direct-path range or above the PBv1 pressure point.

7.6 What is the most honest next implementation direction?

The most honest next implementation direction is:

• prototype the smallest trustless fixed-statement verifier-family candidate under the same frozen SRQ3 / PIv1 / PBv1 boundary, using the current Groth16-backed path only as a comparison scaffold

That means:

• do not resume semantic expansion
• do not widen ABI
• do not treat Groth16 as the final answer
• do not jump to wrapping first

8) Validation Discipline

The project now needs a clearer split between iteration-speed validation and merge-grade/finality validation.

8.1 Fast-path validation for iteration

Acceptable for iteration:

• deterministic canonical fixture prove/verify on the current path
• committed benchmark regeneration
• artifact-integrity mutation checks
• relation-mutation smoke checks on the canonical fixture
• focused regressions on the integration boundary being changed

Why this is acceptable:

• the completed fixed-statement path is now expensive enough that full reproving suites can materially slow iteration
• fast-path validation keeps the loop honest without pretending full coverage happened

8.2 Full-path validation before merge-grade conclusion

Required before final merge-grade or architectural conclusion:

• full backend2 suite, including slow reproving paths
• corpus mutation coverage across the fixed canonical failure classes
• repeated benchmark runs where timing or size conclusions are being used for a decision
• host/runtime integration validation across the committed canonical fixture path
• explicit review of trust-model and setup assumptions for the candidate family being proposed next

Rule:

• “slow” may justify deferring some checks during iteration
• “slow” must not silently become “skipped” when drawing final conclusions

9) Recommendation

Recommendation:

• close the semantic-expansion phase here
• keep direct-path BCH confidential transfer as the primary path
• keep wrapping deferred
• keep the current Groth16 sidecar only as a runtime-validation scaffold
• move next to a trustless-family prototype decision/implementation step under the same frozen statement and verifier boundary

That is the most honest transition after the completed runtime-slice and SRQ3 integration measurements.