ZK Verification

Zero-knowledge proofs are the trust anchor of the vProgs architecture. Instead of re-executing computation on L1, nodes validate a compact cryptographic proof that computation was performed correctly. This page covers the three-tier ZK stack, KIP-16 verifier opcodes, and the full proof lifecycle from generation through finalization.

Why ZK Verification

In traditional smart contract platforms (e.g., EVM), every full node re-executes every transaction to verify correctness. This creates a fundamental bottleneck: throughput is limited by what a single node can execute.

vProgs eliminate this bottleneck:

Traditional (EVM):                    vProgs:
  User submits tx                      User submits tx
  Every node re-executes               Off-chain prover executes
  N nodes * M computation              1 prover * M computation
  = N*M total work                     + N nodes * O(1) verification
                                       = M + N total work

ZK verification reduces L1 verification to constant time regardless of the computation’s complexity. A proof attesting to a million state transitions is verified in the same time as a proof for a single transition.

Three-Tier ZK Stack

The ZK strategy was finalized by Yonatan Sompolinsky in January 2026, establishing three tiers optimized for different use cases:

Tier 1: Inline ZK Covenants (Noir / Groth16)

Inline ZK covenants are the lightest tier. The user generates a proof for their specific transaction and submits it as part of the transaction. No aggregation, no prover market – the user is the prover.

Ideal for: Signature schemes, time-locks, simple spending conditions, wallet-level ZK proofs.

TN12 status: The current OpZkPrecompile implementation (KIP-16) supports RISC Zero proofs (tags 0x20 and 0x21). Native Noir/Groth16 verification is the planned Tier 1 direction but is not yet in the TN12 opcode set. Noir circuits can run today inside a RISC Zero guest via recursive verification.

Tier 2: Based ZK Applications (RISC Zero / SP1)

Based ZK applications are the standard vProgs tier. External provers aggregate multiple user transactions into a single proof, amortizing the proving cost across many operations.

Ideal for: DeFi protocols, token systems, DAOs, any application with steady transaction flow.

Tier 3: Based ZK Rollups (Cairo)

Based ZK rollups handle the most complex case: applications where users themselves submit arbitrary logic (e.g., a DEX where users define custom trading strategies). Cairo’s Sierra bytecode uniquely provides provable metering and safety – the rollup can guarantee that user-submitted code terminates and consumes bounded resources.

Ideal for: General-purpose programmable environments, user-defined smart contracts within a vProg.

Stack Selection Rationale

                    Complexity / Flexibility
                    ========================>

  Tier 1 (Noir)          Tier 2 (RISC Zero/SP1)      Tier 3 (Cairo)
  +-----------+          +------------------+         +------------+
  | Fast      |          | General-purpose  |         | Arbitrary  |
  | Simple    |          | Aggregated       |         | User logic |
  | Per-user  |          | Prover market    |         | Metered    |
  +-----------+          +------------------+         +------------+
  ~1s mobile             10-30s                       Longer
  Per-txn                Per-batch                    Per-epoch

Key design decisions:

• Noir for inline ZK: Fast enough for per-transaction proving, even on mobile devices
• Cairo for rollups: Sierra bytecode uniquely provides provable metering and safety – essential for meta-apps where users submit arbitrary logic
• BLAKE3 over BLAKE2s: BLAKE3 is ~10x more costly in Cairo (BLAKE2s has a precompile), but ~40% better in SP1/RISC Zero. Since Tier 2 is the primary tier, BLAKE3 was chosen for KIP-21’s hash functions

KIP-16: ZK Verifier Opcodes

KIP-16 specifies the consensus-level bridge between covenants and vProgs, proposing opcodes for Kaspa’s script engine that verify ZK validity proofs directly on L1.

What KIP-16 Enables

• L1 script can verify zero-knowledge validity proofs from external execution environments
• Combined with KIP-17 covenant opcodes, enables “ZK covenants” – UTXOs whose spending conditions include ZK proof verification
• External provers submit proofs; L1 validates cryptographically without re-execution
• Supports both Groth16 (Tier 1) and RISC Zero STARK (Tier 2) proof systems

ZK Covenant Pattern

A ZK covenant combines KIP-16 verification with KIP-17 state management:

ZK Covenant UTXO:
  spending conditions:
    1. Provide a valid ZK proof (KIP-16 verification)
    2. Proof attests to state transition f(old_state, action) -> new_state
    3. Output must carry new_state (KIP-17 state validation)
    4. Covenant ID must be preserved (KIP-20 lineage)

This pattern is the building block for all vProg-L1 interaction.

Proof Verification on TN12

Testnet-12 (reset February 9, 2026) includes ZK verify precompiles and opcodes for:

• Groth16 proofs – fast, small proofs for inline ZK covenants
• RISC Zero STARKs – general-purpose proofs for based ZK applications

Proof Lifecycle

Generation

The proof lifecycle begins with off-chain execution:

+-----------------+
| vProg State     |     1. Load current account states
| (accounts S_p)  |        from read set r(x)
+-----------------+
        |
        v
+-----------------+
| Execute Logic   |     2. Run vProg state transition function
| f(state, action)|        deterministically
+-----------------+
        |
        v
+-----------------+
| Execution Trace |     3. Record full execution trace
| (witness data)  |        for proof generation
+-----------------+
        |
        v
+-----------------+
| ZK Circuit      |     4. Compile trace into ZK circuit
| Compilation     |        (Noir, SP1/RiscZero, or Cairo)
+-----------------+
        |
        v
+-----------------+
| Proof Object    |     5. Generate proof object z_p^i:
| z_p^i           |        - ZK proof pi
|                 |        - State commitment C_p^t
|                 |        - Time reference t
+-----------------+

State Commitment Structure

The state commitment C_p^t within the proof object is a hierarchical Merkle root:

C_p^t = MerkleRoot(
  state_root_step_1,    <-- state of all accounts after step 1
  state_root_step_2,    <-- state of all accounts after step 2
  ...
  state_root_step_n     <-- state of all accounts after step n
)

This structure enables concise witnesses: compact Merkle inclusion proofs of any account state at any intermediate step. Concise witnesses are the mechanism enabling synchronous composability.

Submission

The proof is submitted to L1 via a transaction targeting the vProg’s L1 covenant:

1. Transaction includes the proof object in its payload
2. L1 script engine activates KIP-16 verifier opcodes
3. Proof is verified against the claimed state commitment
4. Sequencing commitment is updated via KIP-21

Anchoring

Once verified, the proof creates a trusted anchor point:

Unproven state chain:
  s1 -> s2 -> s3 -> s4 -> s5 -> s6 -> s7

After proof anchors at s4:
  [proven: s1..s4] -> s5 -> s6 -> s7
       ^
       |
  Anchor point -- all state up to s4
  is cryptographically guaranteed.
  Future proofs only need scope from s4 onward.

Anchoring enables:

• Scope reduction for future proofs
• State pruning of pre-anchor history
• Witness compression – the anchor state commitment replaces detailed history

Finalization

The proof transaction is ordered by DagKnight consensus and achieves instant finality. Once finalized:

• The state commitment is authoritative
• The lane tip hash in KIP-21 is updated
• Other vProgs can reference the proven state via concise witnesses

Proof Aggregation

For Tier 2 and Tier 3, provers aggregate multiple transactions into a single proof:

User tx_1 ----+
User tx_2 ----+----> Prover aggregates ----> Single ZK proof
User tx_3 ----+      N transitions             submitted to L1
User tx_4 ----+

Aggregation Benefits

• Amortized verification cost: L1 verifies one proof for N transactions
• Reduced on-chain footprint: One proof per batch instead of one per transaction
• Prover efficiency: Larger batches amortize fixed proving overhead
• User cost reduction: Verification gas is shared across batch participants

Implemented Pipeline: Two-Level Proving

The vProgs ZK framework (proposed March 2026, PRs in review) introduces a two-level proving architecture that maximizes parallelism in proof production:

Execute transactions (parallel)
        |
        v
+------------------------+
| Transaction Prover     |    Level 1: per-transaction proofs
| (one proof per tx,     |    generated on dedicated threads
|  via Backend trait)     |
+------------------------+
        |
        v
+------------------------+
| Batch Prover           |    Level 2: aggregates tx proofs
| (tx proofs + SMT proof |    + Sparse Merkle Tree proof
|  → single batch proof) |    → one state root transition proof
+------------------------+

At Level 1, the Transaction Prover receives serialized execution contexts via the ZK ABI wire format and submits them to a backend-specific prover. Each transaction is proven independently, enabling parallel proof generation.

At Level 2, the Batch Prover collects individual transaction proof artifacts, pairs them with an SMT proof covering the batch’s resources, and produces a single proof attesting to the entire batch’s state root transition. This is the proof that gets submitted to L1.

The Backend trait abstracts proof generation at both levels, so different zkVM backends can be swapped without changing the pipeline. RISC Zero is the first implemented backend (PR #32), with pre-compiled guest programs for both transaction processing and batch aggregation.

Proof Stitching

For cross-vProg atomic transactions, proofs from multiple vProgs can be “stitched” together:

vProg A proof: states sA_1 -> sA_2 (reads sB from vProg B)
vProg B proof: states sB_1 -> sB_2

Stitched proof: atomically verifies both transitions
  + cross-references sB state via concise witness

Proof stitching is a Phase 2 capability, dependent on the full synchronous composability specification.

Verification Cost Model

ZK verification on L1 is designed to be lightweight:

The total verification cost is independent of the complexity of the proven computation. A proof covering a million state transitions costs the same to verify as a proof covering ten.

Security Properties

Soundness

A valid ZK proof guarantees that the claimed state transition was computed correctly. There is no trust assumption on the prover – even a malicious prover cannot produce a valid proof for an incorrect transition.

Zero-Knowledge

The proof reveals nothing about the execution beyond the public inputs (old state commitment, new state commitment, anchoring data). Internal computation details, intermediate states, and private inputs remain hidden.

Non-Interactivity

All proof systems used (Groth16, RISC Zero STARKs, Cairo proofs) produce non-interactive proofs. The prover generates the proof independently; no interaction with the verifier is required.

Finality Guarantees

Unlike optimistic rollups (which require challenge periods), ZK proofs provide immediate finality. Once the proof is verified and the transaction is ordered by DagKnight, the state transition is final – no dispute window, no challenge games.

Hash Function Selection

KIP-21 specifies BLAKE3 with explicit domain separation tags for all cryptographic hashing. The selection involved tradeoffs across ZK stacks:

Since Tier 2 (RISC Zero/SP1) is the primary proving tier for most applications, BLAKE3’s superior performance in those stacks outweighed its higher cost in Cairo.

PoW Randomness for Guest Programs

A distinctive property of the vProgs architecture in the context of Proof-of-Work: the block hash provides an unpredictable, unbiasable random input that is revealed after transaction sequencing.

This gives guest programs native access to on-chain randomness without oracles or additional infrastructure – something traditionally hard to achieve in smart contract platforms. Applications that need verifiable randomness (gaming, lotteries, fair selection mechanisms) can consume the block hash directly within their ZK-proven execution.

Further Reading

• Execution Model – the off-chain execution that produces proofs, including the full ZK proving pipeline
• L1 Sequencing (KIP-21) – how proofs anchor into the commitment chain
• Covenant Stack – the KIP infrastructure including KIP-16
• Synchronous Composability – proof stitching and cross-vProg atomicity
• Proving Systems Analysis – detailed comparison of ZK backends
• KIP-16 specification – verifier opcode details