Skip to content

Verifier ABI and Host/Kernel Boundary v1

Status: draft freeze candidate for fixed-statement verifier path
Scope: one fixed confidential-transfer statement only

Normative boundary lock: - final verifier acceptance is defined by public inputs + proof artifact only - backend-1 witness-dependent verification is temporary scaffolding and is not normative for final verifier semantics - host/prover irreducible split is frozen in spec/direct-path-minimum-private-relation-v1.md

1) Public Verifier ABI (Must Stay Stable Through v1)

Public inputs (PI boundary): - shardId32 - stateIn32 - stateOut32 - outputFingerprint32 (OFm2/v2) - optional batch/fee digests exactly as already versioned

Proof carrier (PB boundary): - backendId - proof artifact bytes (backend-family specific) - transport sections (encrypted payload, hints) remain transport-visible artifacts, not verifier witness inputs

Verifier-side prohibition: - verifier must not require witness bytes or private witness-derived side channels - verifier must not require witness-derived aliases under alternate names (e.g. witness hash/constraint hash side channels)

2) Host Responsibilities (Must Remain Host)

  • parse and validate PI canonical encoding
  • parse and validate proof-carrier envelope structure
  • transcript envelope binding checks
  • tokenized continuation invariants:
  • continuation output index rule
  • fixed carrier sats rule
  • token category/capability continuity
  • token commitment equals stateOut32
  • OFm2/v2 recomputation from real outputs
  • malformed carrier and malformed section reject logic

Host does not perform algebraic proof relation verification.

3) Kernel Responsibilities (Must Remain Kernel)

  • algebraic verification for fixed statement proof relation
  • commitment/opening checks for selected verifier family
  • bounded query/opening verification path
  • final verifier success/failure decision based on public inputs + proof artifact only

For the fixed statement, prover/kernel relation facts are frozen to: - note ownership - note inclusion - nullifier correctness - receiver note creation - sender change note creation - committed-value conservation - transition consistency against stateIn32, stateOut32, and outputFingerprint32

outputFingerprint32 remains a public relation anchor only; it does not define confidential amount semantics.

Kernel must not depend on wallet or witness record data. Kernel must consume only the frozen public ABI fields and proof artifact bytes.

4) Must-Not-Require Rules

The verifier path must never require: - witness material for prove/verify acceptance - witness-derived verifier inputs hidden behind alternate field names - public receiver marker - public economic transfer amount in confidential-transition outputs - trusted indexing side channel

4.1 Provisional backend bridge (non-normative)

  • backend-1 witness replay exists only as transition scaffolding for off-chain constraint testing
  • backend-1 witness-dependent checks must never widen or redefine final verifier ABI fields
  • no backend-1 helper or report format is an authority for final on-chain verifier acceptance rules

5) Statement Drift Guardrails

These stay frozen: - fixed statement counts (1 spend, 1 receiver, 1 sender change) - committed-value conservation semantics - nullifier correctness semantics - note inclusion semantics - state transition consistency semantics - tokenized continuation + OFm2/v2 policy

No widening to multi-cell, batching, recursion, or aggregation in v1.

Destination this split protects: - full confidential send/receive - shielded amount - shielded receiver identity - tokenized continuation state cells - real ZK proof generated off chain - real proof verification on chain in BCH Cash Assembly path

6) Budget-Risk Placement

  • Host risk: parser/binding and output/token continuity checks
  • Kernel risk: arithmetic/query/opening verification cost
  • Shared risk: transcript/hash cost, proof-carrier byte pressure

Implementation requirement: - measure and gate byte/op/script budgets independently for host and kernel paths.

7) Acceptance Requirements for Next Steps

  • verifier path demonstrates public-input-only verification
  • mutation corpus includes malformed proof/carrier and binding failures
  • host/kernel split remains explicit, versioned, and test-locked

8) Stage-B Trustless Kernel Clarification

  • Stage-B on-chain kernel follow-through is scoped to backendId=2 with trustless profile TRQ1 (profile id 3) only.
  • Runtime-backed SRQ3 profile-2 remains comparison/scaffold infrastructure and is not part of the Stage-B on-chain kernel target.
  • Stage-B in this phase is structural:
  • kernel checks artifact/profile/version/reserved-byte structure
  • kernel checks statement-bind equality
  • kernel checks trustless proof-structure headers for TRQ1
  • Stage-B in this phase is explicitly not full algebraic on-chain verification of trustless arithmetic relations.

8.1 Stage-B TRQ1 Transport Rule (BCH VM constrained)

  • BCH VM stack-item maximum is 520 bytes, so a 1218-byte trustless SRQ3/TRQ1 proof cannot be pushed as a single stack item.
  • Stage-B kernel transport is therefore fixed to an ordered chunked shape:
  • expectedStatementBind32 (32 bytes)
  • proofChunk0 (406 bytes)
  • proofChunk1 (406 bytes)
  • proofChunk2 (406 bytes)
  • This is a transport/stack-shape rule only:
  • no ABI widening
  • no verifier-visible witness aliases
  • no host/public-shell drift
  • no verifier-semantic expansion
  • Verifier-visible semantics remain frozen to public inputs + proof artifact bytes; chunking is only how the same artifact is carried within BCH VM limits.