Backend Direction Comparison v1

Status: comparison checkpoint (TKT-P3-69)
Scope: one fixed confidential-transfer statement only

1) Purpose

This memo compares the two currently committed backend-direction reference points under the same frozen fixed-statement boundary:

• the Groth16-backed SRQ3 runtime-validation scaffold
• the trustless-family prototype from TKT-P3-68

This is a measurement and decision memo only. It is not new implementation work. It is not semantic expansion.

2) Compared Paths

2.1 Groth16-backed SRQ3 scaffold

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

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

What it means:

• this path is truthfully backed by witness-hiding proof semantics for the completed fixed hidden relation
• it preserves the frozen verifier contract
• it remains runtime-validation only because the Groth16 sidecar does not satisfy the final trust-model / backend-family requirements

2.2 Trustless-family prototype

Source: docs/benchmarks/stark-rq-trustless-prototype-v1.json

• proofBytes = 496
• proofBlobBytes = 1384
• proveMs = 5365.806
• verifyMs = 3.345

What it means:

• this path stays under the same frozen SRQ3 / PIv1 / PBv1 boundary
• it preserves public-input-only + proof-artifact-only verification
• it does not yet prove hidden witness derivation of the completed fixed hidden relation
• it is therefore a trustless-family mechanics prototype, not a full-family success claim

3) Direct Comparison

3.1 Carriage size

Trustless prototype vs Groth16-backed scaffold:

• proofBytes: 496 vs 552
• proofBlobBytes: 1384 vs 1440

Interpretation:

• the trustless-family prototype does not regress direct-path carriage
• both paths remain comfortably inside the high-value direct-path range
• wrapping does not need to be reopened from a size perspective

3.2 Timing

Trustless prototype vs Groth16-backed scaffold:

• proveMs: 5365.806 vs 665559.338
• verifyMs: 3.345 vs 297.691

Interpretation:

• the trustless-family prototype is dramatically cheaper on the measured mechanics it currently covers
• that timing advantage is real, but it must not be over-read because the trustless prototype is still partial

3.3 Trust model and setup assumptions

Groth16-backed scaffold:

• setup-dependent
• runtime-validation only
• not an acceptable final backend-family answer under the strongest trustless goal

Trustless prototype:

• trustless / transparent mechanics direction
• aligned with the desired final trust model
• still provisional because the current prototype does not yet carry the full hidden-relation witness-hiding burden

3.4 BCH verifier-family fit

Groth16-backed scaffold:

• poor final BCH verifier-family fit because pairing-style verification remains the dominant concern

Trustless prototype:

• directionally aligned with the previously selected reduced-query transparent-family path
• still needs a deeper prototype before BCH verifier-family fit can be considered established

4) Ticket Questions

4.1 Does the current Groth16 development slice remain only a runtime-validation scaffold?

Yes.

This comparison strengthens that conclusion rather than weakening it. The small artifact size of the Groth16-backed scaffold remains useful evidence, but not a basis for final backend-family commitment.

4.2 Is the trustless-family direction now the leading next implementation path?

Yes.

This comparison makes the trustless-family direction the leading next implementation path because:

• it preserves the trustless / transparent target
• it preserves the frozen outer boundary
• it does not regress direct-path carriage
• its first measured mechanics prototype is materially cheaper than the Groth16-backed scaffold

4.3 Does direct-path BCH confidential transfer remain primary after the comparison?

Yes.

Both compared paths remain direct-path relevant on carriage size. Nothing in this comparison forces a pivot to staged carriage.

4.4 Should wrapping remain deferred?

Yes.

The trustless-family prototype improved carriage slightly rather than causing a size regression. There is still no measured reason to reopen wrapping.

4.5 What is the most honest next implementation direction?

The most honest next implementation direction is:

• a deeper trustless-family fixed-statement prototype that advances from transparent commitment/opening mechanics over the SRQ3 relation-public digest schedule toward witness-hiding proof semantics for the completed fixed hidden relation, while preserving the same frozen outer boundary

That next step should remain:

• fixed-statement only
• comparison-oriented
• non-generic
• explicit about what is still provisional

5) Direct-Path Ladder Placement

Groth16-backed SRQ3 scaffold:

• proofBytes = 552: ideal ~1 KB class
• proofBlobBytes = 1440: high-value ~1–2 KB range

Trustless-family prototype:

• proofBytes = 496: ideal ~1 KB class
• proofBlobBytes = 1384: high-value ~1–2 KB range

Conclusion:

• direct-path carriage remains strong in both compared paths
• the trustless-family prototype does not create a new carriage problem

6) Decision

Decision from this comparison:

1. Groth16 remains scaffold-only.
2. The trustless-family direction is now the leading next implementation path.
3. Direct-path BCH confidential transfer remains primary.
4. Wrapping remains deferred.
5. The next implementation ticket should deepen the trustless-family prototype rather than extending the Groth16 scaffold or reopening semantic expansion.

7) Validation Discipline

This ticket uses committed benchmark numbers only.

It does not claim:

• that the current trustless-family prototype is full-family success
• that the Groth16-backed scaffold has become deployable
• that merge-grade validation for a deeper trustless-family implementation is already satisfied

Fast-path validation was sufficient for this decision ticket because the question here is comparative direction, not finality. Any deeper trustless-family implementation ticket must still define its own merge-grade validation expectations explicitly.