ZK, Groth16, And RISC Zero Succinct

What this page explains#

Teach inline ZK as a covenant-adjacent proof verification path, while separating proof validity from whole state-transition validity. This page sits in ZK, Groth16, And RISC Zero Succinct. It gives the topic a plain-language handle first, then shows the working idea, the mechanism, the source trail, and any limits that still matter. This category separates proof verification from application validity. Groth16 and RISC Zero Succinct can verify selected statements, while covenant scripts, successor checks, source limits, and accepted evidence still carry separate responsibility.

The writing follows a simple Kaspa documentation pattern: answer the practical question first, then link outward for details. The closest public sources for this page are DOC-TOCCATA-INLINE-ZK, DOC-TOCCATA-COVENANT-STATE, DOC-TOCCATA-SCRIPT-PRICING, DOC-TOCCATA-BASED-APPS, RK-ZK-TAGS. Local notes can help choose what to explain, but public-facing references resolve to upstream websites, repositories, papers, release pages, or docs.

How to think about it#

The practical model starts by naming the layer that owns the topic: wallet use, node operation, consensus, transaction validation, Toccata script behavior, tooling, or research. From there, the page shows which public source can support the explanation and where the explanation becomes incomplete.

For ZK, Groth16, And RISC Zero Succinct, the model is built around these anchors: ZK verification proves only the encoded statement, not the whole application transition; Groth16 and RISC Zero Succinct need separate verifier, proof-format, public-input, and cost evidence; Proof output must be bound to covenant state, successor output, and accepted evidence before app claims close; Malformed, under-budget, wrong-verifier, and mismatched-binding cases remain part of the guide; Research and upstream verifier documentation are labeled separately from Kaspa implementation behavior. This model is useful, but it does not encode every constant, branch, error type, or edge case. Those details belong in the source path and the source notes.

How it works#

1. ZK verification proves only the encoded statement, not the whole application transition. RISC Zero Succinct material has a different shape from circuit-specific Groth16. The image ID, journal or digest, receipt/seal data, claim data, and verifier assumptions define what execution claim is being checked. The Kaspa-facing page must then connect that checked claim to script stack format, compute cost, covenant binding, negative cases, and accepted-state evidence.

2. Groth16 and RISC Zero Succinct need separate verifier, proof-format, public-input, and cost evidence. Proof verification consumes metered script work. The page has to connect verifier tags and proof sizes to pricing or mass evidence, then show how under-budget, malformed, or mismatched verifier inputs fail before accepted-state claims are made.

3. Proof output must be bound to covenant state, successor output, and accepted evidence before app claims close. Proof success is not accepted evidence. After local construction and script validation, the spend still needs transaction validation, mempool or block inclusion context, virtual-state acceptance, and an observable state surface such as UTXO or indexer evidence.

4. Malformed, under-budget, wrong-verifier, and mismatched-binding cases remain part of the guide. A proof output is useful only when the application binds it to the old state, new state, covenant ID or script context, and public input or journal. Without that binding, a valid proof may still be irrelevant to the UTXO transition being spent.

5. Research and upstream verifier documentation are labeled separately from Kaspa implementation behavior. RISC Zero Succinct material has a different shape from circuit-specific Groth16. The image ID, journal or digest, receipt/seal data, claim data, and verifier assumptions define what execution claim is being checked. The Kaspa-facing page must then connect that checked claim to script stack format, compute cost, covenant binding, negative cases, and accepted-state evidence.

This mechanism section separates proof verification from application validity. A verifier result still needs script binding, covenant checks, transaction validity, and accepted-state evidence before an app claim is closed.

How to check it#

When using this page for ZK material, separate proof verification from application validity. Check the verifier path, proof format, public inputs or journal, compute cost, covenant binding, failure cases, and accepted evidence before claiming a transition is valid.

Expanded Category Guide#

This category carries ZK material. It should separate proof-system background, verifier source paths, proof binding, script/precompile behavior, negative cases, and readiness evidence.

Use this category as a curated path. Start with the category README to understand the boundary, then read the mechanism pages, then follow source-path or open-gap pages for claims that need stronger evidence. If a page contains needs checking rows, keep those claims visibly unresolved until a reader reads the cited public source directly.

The category should not be treated as final authority by folder name alone. The authority comes from page Source Notes, Source Lists, public URLs, and the status labels attached to each claim.

Related Pages#

• zk-groth16-risczero
• 01-zk-first-contact-and-vocabulary

Topic pages#

• ZK First Contact And Vocabulary: ZK pages begin by defining proof, statement, prover, verifier, public input, witness, circuit, zkVM program, receipt, journal, tag, and precompile.
• Inline ZK Covenant Model: Inline ZK is best taught inside the covenant loop: current UTXO, proof, script verification, successor output.
• OpZkPrecompile Tags And Costs: Tags and costs are high-risk source claims because they decide which verifier runs and whether the transaction has enough budget.
• Groth16 Overview: Groth16 background explains circuits, witnesses, proving keys, verifying keys, proof bytes, public inputs, and trusted setup context.
• Groth16 Kaspa Verifier Source Path: The Kaspa Groth16 source path explains verifying key/proof data, public input arity, metering, parsing, and verification failure cases.
• RISC Zero Succinct Overview: RISC Zero Succinct pages explain zkVM receipts, image IDs, journal commitments, seals, and the difference between upstream concepts and Kaspa stack expectations.
• RISC Zero Succinct Kaspa Verifier Source Path: The RISC Zero Succinct source path is a verifier-specific review of image IDs, journal digest, seal, control proof, claim, and supported hash assumptions.
• Proof Binding To Covenant State: Proof binding connects verifier success to the covenant state transition the app actually cares about.
• Negative Cases And Failure Matrix: A failure matrix makes ZK safer by naming what must fail.
• Groth16 Transition Starter: The Groth16 starter is a draft implementation checklist for binding proof output to a covenant transition without citing local lab files as authority.
• RISC Zero Succinct Transition Starter: The RISC Zero starter is a conceptual checklist until a concrete public upstream recipe is verified, and it makes image ID, journal digest, receipt/seal, and verifier boundaries explicit.
• Testing Evidence And Readiness: Readiness labels prevent local proof output from being mistaken for production evidence.
• ZK Source Path And Review Playbook: The ZK review playbook turns a claim into source work: docs, KIP, tags, costs, verifier source, tests, releases, and claim labels.
• ZK FAQ And Misreadings: The ZK FAQ answers the mistakes that cause unsafe designs: valid proof is not whole transition validity, local proof output is not network readiness, and zkVM verification is not on-chain program execution.

Topic notes#

This category is accepted when the subpages explain the actual topics, not merely the source links. Each subpage carries public source IDs, claim labels, Open Questions, and a path from first contact into source review.