# ZK Production Plan

## 📋 STATUS UPDATE - October 2025

**Current Status:** ⏳ **FUTURE ENHANCEMENT** (Privacy zkVM not started)

**Important Distinction:**

* ✅ **Bridge ZK-STARK (Production-Ready):** Rust prover/verifier with strong test coverage (**120/120 tests**, +1 ignored). FFI integration operational (9900-byte proofs generated in production). On-chain verification hookup pending.
* 🔜 **Full ZK System (THIS ROADMAP):** Complete privacy layer with **REAL** zkVM, shielded pools, private transactions, and recursive proofs (e.g., Winterfell, Risc0). **NOT STARTED** - Post-Q1 2026 enhancement.

**What EXISTS Now:**

* ✅ Rust STARK components: constraints, FFT/LDE, DEEP-ALI/FRI prover, verifier (test suite passing)
* ✅ Commitment/transcript/Merkle plumbing
* ✅ Proof lifecycle (generation → verification → storage) on the Rust side
* ✅ Bridge FFI integration: Rust prover called from Go bridge (9900-byte proofs operational)
* ⏳ On-chain verifier: Smart contract verification hookup pending

**Bridge Context:**

* Security relies on **M-of-N Dilithium signatures** (5-of-7);
* ZK proofs provide gas optimization (batch verification) and stronger guarantees;
* STARK constraints/prover are real; remaining work is wiring proofs into bridge flows and on-chain verification.

**This roadmap** describes implementing **REAL** ZK system with cryptographic soundness.

**See Also:** [zk-proofs.md](https://quantumwing.gitbook.io/quantumwing/advanced-features/zk-proofs) for the current bridge ZK constraints/prover status.

***

## Vision

* Transparent ZK proofs (no trusted setup), post‑quantum friendly (hash‑based security).
* Recursion/aggregation for constant‑time on‑chain verification and fast sync.
* Private transactions and cross‑chain verification built directly into L1 (no extra layer required).

## Approach

* Proof system: STARK‑style zkVM (e.g., RISC‑V based) with receipt aggregation.
* Prover: off‑chain microservice (Rust) for circuit/VM execution and proof generation.
* Verifier: in‑protocol verification (Go) via FFI bindings; one verification per tx/batch/epoch.

## Scope (Phased)

1. ZK Core (Weeks 1–2)

* Select zkVM and integrate prover daemon (receipt generation APIs).
* Add Go verifier bindings (cgo) and minimal proof verification in block apply.
* Target: single proof verification in < 50 ms CPU, deterministic.

2. Private Transactions MVP (Weeks 3–4)

* State: `shielded_pool` module (Poseidon‑style Merkle tree, nullifier set).
* Tx type: `PrivateTx { proof, commitments, nullifiers, encOutputs }`.
* Validation: verify proof → update pool state atomically.
* Transport: reuse Kyber E2E for private payload distribution.

3. Aggregation & Epoch Proofs (Weeks 5–6)

* Aggregate per‑block/per‑tx proofs into epoch receipts (recursion/PCD).
* Verify one epoch proof on‑chain; amortize cost across N tx/blocks.
* Fast‑sync: newcomers verify latest epoch proof and catch up in O(1).

4. Cross‑Chain Verification (Weeks 7–8)

* State: `bridge/state` with verified remote root/header commitment.
* Tx type: `BridgeUpdate { proof, newRoot, range }` (batch header/signature/DA checks proved off‑chain).
* Tx type: `MessageInclusion { event, merklePath }` checked against verified root.

5. Hardening & UX (Weeks 9–12)

* Determinism, DOS limits, fee model, audit trail.
* Tooling: prover job queue, retries, metrics; testnets; production knobs.

## Performance Targets

* Verify: < 50 ms per proof (single), < 250 ms per epoch receipt.
* Proof size: single 100–500 KB; epoch 0.5–2 MB.
* Private tx: < 300 ms prover time (local dev; production with batching/parallelism).

## Security

* Hash‑based security for proofs; Dilithium for signatures; Kyber for transport E2E.
* State integrity: commitment roots and nullifier set updated only on valid proof.
* Audits: prover/verifier determinism, memory bounds, timing; cryptographic parameters (≥128‑bit quantum security).

## Integration Details

* Go verifier API: `zk.Verify(receipt, programID, inputs) error` (deterministic, constant‑time path).
* Prover API: `POST /prove { programID, inputs } → { receipt }` with job tracking.
* State modules: packaged under `pkg/zkp/` and `blockchain/state/shielded_pool/`.

## Rollout

* devnet → public testnet → opt‑in mainnet flag (`--enable-zk`), then default‑on.
* Feature flags: `--zk-aggregation`, `--zk-bridge`, `--zk-shielded-pool`.

## FAQ

* Why transparent ZK? Avoids trusted setup, aligns with long‑term PQ posture.
* Why zkVM? Faster iteration, complex logic support, clean recursion story.
* Why L1 integration? No extra trust layer; validators enforce proofs during block validation.