# Verifiable Computing Extension — Research Note

Status: **RESEARCH**. This note describes a versioned extension point on
the receipt body that would allow a future implementation to bind
external computation proofs (ZKP, TEE attestation, or verifiable-compute
schemes) to a Decision Receipt. No such implementation ships today.

## Position

Signatrust today verifies **integrity and authenticity of recorded
evidence**. It does not, and today cannot, verify that a computation
that produced the recorded content was itself correct, that a specific
model was in fact executed, or that no side channel introduced hidden
information.

Verifiable computing (VC) schemes address a subset of those properties.
They typically produce a `proof` object that a verifier can check
against a `statement` (the claim being proved) using a `verifier_profile`
(algorithm, parameters, public parameters or common reference string).

This note defines a **minimal, versioned extension point** so that when
such a proof scheme is added later, it fits into the receipt body
without breaking existing bodies or existing verifiers.

## Proposed extension point

An optional array on `ReceiptBody`:

```jsonc
"computation_proofs": [
  {
    "proof_type":        "zkp" | "vc" | "tee_attestation" | "other",
    "scheme":            "e.g. groth16-bn254 | risc0-v1 | sgx-dcap | tdx | other",
    "statement_hash":    "sha256:…",           // sha256 of canonical statement
    "proof_hash":        "sha256:…",           // sha256 of the proof blob
    "verifier_profile":  "e.g. signatrust-vc-verifier-groth16-v1",
    "external_reference": "https://…/proof.bin"    // optional
  }
]
```

### Field semantics

| Field | Meaning |
|-------|---------|
| `proof_type` | High-level family of the proof (zero-knowledge, verifiable computing, hardware attestation, other). |
| `scheme` | Specific scheme identifier including curve / parameters. Not free-form marketing text. |
| `statement_hash` | Commitment to the canonical statement the proof addresses. The statement itself is held by the customer or an external repository. |
| `proof_hash` | Commitment to the proof blob. The blob itself is held externally. |
| `verifier_profile` | The verifier profile id that a future Signatrust verifier (or external tool) would need in order to check the proof. Absence of this profile in the verifier means the receipt-side check is limited to hash comparison, not proof soundness. |
| `external_reference` | Optional pointer to fetch the proof and statement. Not a trust anchor. |

### Signed body

The array is signed as part of the body. Absence of the field is the
default; the field is dropped by the canonicaliser rules and old bodies
remain byte-identical.

### Verifier semantics

A verifier that does **not** implement any VC scheme:

- Records the presence of `computation_proofs[]` in its output.
- Verifies each entry as a **hash-only** cross-reference: if the caller
  supplies the corresponding statement and proof blob, the verifier
  reports whether their hashes match. It does **not** verify soundness
  of the proof.
- Never labels the receipt as "computationally verified" on the basis of
  hashes alone.

A verifier that **does** implement a specific `scheme + verifier_profile`
pair:

- Runs the scheme-specific proof check.
- Reports the outcome as `computation_proof_valid: true|false|unknown`
  per entry, with the scheme name in the output.
- Reports `unknown` if the caller did not supply the required blob or
  the verifier lacks the necessary public parameters.

### Explicit non-claims

The following statements MUST NOT be made on the basis of
`computation_proofs[]` alone:

- "This receipt proves the model output was correct."
- "This receipt proves the specific model was executed."
- "This receipt proves no side-channel information was leaked."

The exact strength of the claim depends on the scheme, the statement,
the public parameters, and the verifier's implementation. Any per-scheme
guarantees must be described in that scheme's own documentation.

## Layering with existing fields

`computation_proofs[]` is **orthogonal** to:

- `decision.input_hash` / `output_hash`: hashes of what the issuer says
  entered and left the computation. A proof might bind these — but it
  is the specific `scheme` that decides.
- `attestations[]`: assertions by external parties. A TEE attestation
  might reasonably appear as either `computation_proofs` (structured
  proof) or as an Attestation Receipt (human-readable assertion),
  depending on how it is meant to be verified.

## Migration path

- **Today**: field is defined in DOCUMENTED status only; no server-side
  accept path is enabled.
- **Step 1**: extend the `ReceiptBody` type in `src/types.ts` behind a
  feature flag; keep it off by default. Add a passthrough at
  ingestion, no verifier logic.
- **Step 2**: implement a first `verifier_profile` for one specific
  scheme end-to-end, with a conformance test vector.
- **Step 3**: publish the verifier as a standalone package so that
  external evaluators can check the same proof without Signatrust's
  service being reachable.
- **Step 4**: expose scheme-specific verification in the offline
  verifier (`scripts/verify-offline.mjs`) as an opt-in flag.

Each step is a separate change with its own review. Skipping any step
would violate the "no production ZKP implementation" boundary.

## Non-goals

- No specific ZKP scheme is implemented in this pass.
- No PQC-adjacent proof scheme is implemented in this pass.
- No hardware attestation verifier is implemented in this pass.
- No claim of "verifiable AI" is made anywhere.