Skip to content

Zero-Knowledge Proof Architecture

Feature Flag Required

ZK proof verification is gated behind the OPS_ZK_PROOFS feature flag and is not enabled by default. Contact your Lucid representative to enable it.

This document describes the zero-knowledge (ZK) proof architecture in the Lucid platform, enabling auditors to generate verifiable proofs of their computations without revealing sensitive data.

Overview

Zero-knowledge proofs allow auditors to prove that they performed a computation correctly without revealing the private inputs to that computation. This is particularly useful for:

  1. Privacy-Preserving Verification: Customers can receive AI Passports without raw data leaving their TEE
  2. Scalable Verification: ZK proofs are compact and fast to verify
  3. Cryptographic Guarantees: Mathematical proof that the computation was performed correctly

Architecture Diagram

flowchart TD
    subgraph Auditor["Auditor (TEE)"]
        A1["Private Data<br/>(not sent)"] --> A2["lucid-wasm-zk<br/>(WASM sandbox)"]
        A2 --> A3["ZK Proof<br/>(sent to verifier)"]
    end

    A3 -->|"Evidence with ZK Proof"| V1

    subgraph Verifier["Verifier"]
        V1["Circuit Registry<br/>(Database)"] --> V2["Verification Key<br/>(from DB)"]
        V2 --> V3["Verify Proof<br/>(lucid-wasm-zk)"]
    end

Implementation: WASM Module Architecture

ZK proof verification is implemented as a sandboxed WASM module. This provides:

  • Sandboxed execution: Proof verification runs inside a WASM sandbox with no filesystem, network, or syscall access
  • Deterministic builds: The .wasm binary has a reproducible hash for TEE attestation
  • Multi-language support: One compiled binary serves Python, Go, Node/TS, and other language SDKs via their native WASM runtimes
  • Minimal supply chain: Crypto dependencies (ark-groth16, ark-bn254) are compiled into the .wasm file -- no host-language dependencies

Python SDK

The Python SDK exposes ZK verification:

from lucid_auditor_sdk._wasm.zk import verify_groth16, verify_plonk

# Verify a Groth16 proof
result = verify_groth16(proof_bytes, verification_key_bytes, public_inputs)

Components

1. Schema Types (lucid-schemas)

The lucid-schemas package provides the core ZK-related types:

  • ZKProofSystem: Enum of supported proof systems (groth16, plonk, fflonk, stark)
  • ZKProofSchema: Schema for serializing ZK proofs
  • ZKCircuitMetadata: Schema for circuit registration metadata

The Evidence schema includes an optional zk_proof field:

class Evidence(BaseModel):
    # ... existing fields ...
    zk_proof: Optional[ZKProofSchema] = Field(
        None,
        description="Optional ZK proof attesting to the evidence computation."
    )

2. WASM ZK Module

The ZK module implements proof verification in sandboxed Rust/WASM:

  • verify_groth16: Groth16 proof verification (BN254 curve)
  • verify_plonk: PLONK proof verification
  • verify_fflonk: fflonk proof verification

The WASM module is consumed by the Python SDK:

Language Runtime Wrapper
Python wasmtime-py lucid_auditor_sdk._wasm.zk

3. Verifier Integration

The Lucid Verifier service provides ZK proof verification capabilities:

  • Circuit Registry: Database of registered circuit verification keys
  • Circuit Management API: REST endpoints for circuit registration and lookup
  • ZK Verification Service: Validates proofs during evidence submission (gated behind OPS_ZK_PROOFS feature flag)

See the Verifier API Reference for endpoint documentation.

Supported Proof Systems

System Setup Proof Size Verification Use Case
Groth16 Trusted ~200 bytes ~3ms Production, frequent proofs
PLONK Universal ~1KB ~10ms Flexibility, no trusted setup
fflonk Universal ~500 bytes ~5ms Balance of size and setup
STARK None ~50KB ~50ms Maximum transparency

Workflow

Circuit Registration

Before proofs can be verified, the circuit must be registered with the verifier:

POST /v1/zk/circuits
{
  "circuit_id": "pii-detector-v1",
  "circuit_name": "PII Detection Circuit",
  "version": "1.0.0",
  "proof_system": "groth16",
  "verification_key": "<base64-encoded>",
  "num_public_inputs": 3,
  "auditor_id": "pii-auditor@sha256:abc123"
}

Proof Generation (Auditor)

  1. Auditor computes claims using private inputs inside the TEE
  2. Auditor generates ZK proof via the WASM module attesting to the computation
  3. Auditor creates Evidence with zk_proof field populated

Proof Verification (Verifier)

When evidence is submitted to /v1/evidence/verify:

  1. Verifier checks if Evidence has zk_proof field
  2. If present, verifier looks up circuit verification key from registry
  3. Verifier validates proof using the lucid-wasm-zk module
  4. If valid, evidence is accepted; if invalid, request is rejected

API Reference

Circuit Management

Endpoint Method Description
/v1/zk/circuits POST Register a new circuit
/v1/zk/circuits/{id} GET Get circuit metadata
/v1/zk/circuits GET List circuits (filter by auditor, proof system)
/v1/zk/circuits/{id} DELETE Deactivate a circuit

Evidence Submission

The /v1/evidence/verify endpoint automatically handles ZK proofs when present in Evidence bundles. No API changes required.

Security Considerations

WASM Sandbox Isolation

ZK proof verification runs inside the same three-layer isolation model used by the receipt chain:

  1. TEE (AMD SEV-SNP): Protects from host OS, hypervisor, physical access
  2. Container (CoCo/kata-cc): Protects from other pods, K8s control plane
  3. WASM sandbox: Protects from the auditor itself -- no filesystem, no network, no syscalls

Trusted Setup (Groth16)

Groth16 requires a trusted setup ceremony. The setup_hash field in ZKCircuitRecord tracks which setup was used. Organizations should:

  1. Use well-known trusted setups (e.g., Powers of Tau)
  2. Verify setup hash matches expected value
  3. Consider PLONK/fflonk for applications requiring transparent setup

Circuit Versioning

Circuits should be versioned to ensure compatibility:

  • circuit_id: Unique identifier (e.g., "pii-detector-v1")
  • version: Semantic version (e.g., "1.0.0")

When updating a circuit, register a new version rather than modifying existing.

Binary Attestability

The ZK WASM binary has a deterministic hash from a reproducible build. This hash can be part of TEE attestation reports, so remote verifiers know exactly which ZK verification logic is running.

Backward Compatibility

The ZK proof feature is fully backward compatible:

  1. Evidence without zk_proof: Continue to use signature verification
  2. Evidence with zk_proof: Use ZK proof verification (takes precedence)
  3. Feature flag: ZK endpoints are gated behind the OPS_ZK_PROOFS feature flag

Future Enhancements

  1. Recursive Proofs: Aggregate multiple auditor proofs into a single proof
  2. On-chain Verification: Publish proofs to blockchain for public verifiability
  3. Custom Circuits: SDK tooling for building auditor-specific circuits
  4. Hardware Acceleration: GPU-based proving for faster proof generation