Proof Generation & Verification

Acceso’s ZK infrastructure enables privacy-preserving computation inside the platform. Clients prove statements about data without revealing the data itself.

You call stable APIs. Acceso owns the proving engines, circuit versions, and execution safety.

Clients interact with proof generation via high-level APIs without managing cryptographic tooling.

What this layer does

This layer provides three capabilities:

• Proof generation: produce a proof from private + public inputs.

• Proof verification: validate a proof against a circuit and public inputs.

• Circuit lifecycle: version, enable, and deprecate circuits safely.

Key concepts

• Circuit: the statement being proven, plus a versioned contract.

• Private inputs: secrets used during proving. Never returned.

• Public inputs / public signals: values safe to reveal and verify.

• Proof artifact: bytes that bind circuit version + public values.

End-to-end workflow

1

Select a circuit (the statement) and version

A circuit defines what can be proven. Examples include membership, balance bounds, or predicate checks.

The circuit choice also defines:

• Required private inputs.

• Required public inputs (or public signals).

• Constraint system and proof system parameters.

2

Submit inputs (private + public)

Inputs are validated before any cryptographic work starts. This prevents malformed computations and ambiguity.

Validation typically enforces:

• Type and range constraints.

• Canonical encoding rules.

• Circuit-specific input arity and formatting.

3

Generate the proof in an isolated environment

Proof generation runs in isolated execution environments. Private inputs stay inside the execution boundary.

Output is a proof artifact that binds:

• The circuit identifier and version.

• The public inputs (or derived public signals).

• The proof bytes.

4

Verify the proof (deterministic decision)

Verification checks the submitted artifact against:

• The circuit definition.

• The expected public inputs.

• The proof’s internal consistency.

The result is deterministic. It returns a clear success or failure state.

API-level semantics

Proof generation

Inputs and safety checks

Generation accepts circuit-scoped inputs. Inputs are treated as secrets by default.

Common checks:

• Circuit/version exists and is enabled.

• Input schema matches the circuit contract.

• Input values are within safe bounds.

• Request size and compute budgets are enforced.

Output artifact (example shape)

{
  "circuit_id": "membership_v1",
  "circuit_version": "1.2.0",
  "public_inputs": {
    "root": "0x...",
    "nullifier": "0x..."
  },
  "proof": "0x...",
  "public_signals": ["0x...", "0x..."],
  "created_at": "2025-12-18T12:34:56Z"
}

Acceso returns verifiable artifacts. Clients do not manage proving tooling.

Proof verification

Circuit management

Implementation notes (for operators)

• Proof generation is compute-heavy and queue-friendly.

• Verification is cheaper and optimized for low-latency paths.

• All secret handling should assume hostile logs and metrics sinks.