> For the complete documentation index, see [llms.txt](https://quantumwing.gitbook.io/quantumwing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quantumwing.gitbook.io/quantumwing/roadmap/zk-production.md).

# ZK Production Plan

Transparent ZK (STARK) roadmap for privacy, scalability and verification

## 📋 STATUS UPDATE - June 2026

**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](/quantumwing/advanced-features/zk-proofs.md) 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://quantumwing.gitbook.io/quantumwing/roadmap/zk-production.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.