# ZK Proofs Explained

A beginner-friendly explanation of Zero-Knowledge proofs and how ZK-Provenance uses them.

## What is a Zero-Knowledge Proof?

A Zero-Knowledge proof (ZKP) is a cryptographic method that allows one party (the **prover**) to prove to another party (the **verifier**) that a statement is true — **without revealing any information beyond the truth of the statement itself**.

### Simple Analogy

Imagine you want to prove you know the password to a door — without saying the password out loud.

* **Old way:** Say the password → Verifier hears it → Privacy violated
* **ZK way:** Perform a cryptographic dance → Verifier is convinced → Password stays secret

### The Three Properties

Every ZK proof satisfies three properties:

| Property           | Meaning                                                                     |
| ------------------ | --------------------------------------------------------------------------- |
| **Completeness**   | If the statement is true, an honest prover can always convince the verifier |
| **Soundness**      | A dishonest prover cannot convince the verifier of a false statement        |
| **Zero-Knowledge** | The verifier learns nothing beyond the truth of the statement               |

## Groth16 — The Proving System

ZK-Provenance uses **Groth16** — the most battle-tested ZK-SNARK construction in production.

**SNARK** = Succinct Non-interactive ARgument of Knowledge

* **Succinct:** Proof is tiny (288 bytes) regardless of computation size
* **Non-interactive:** No back-and-forth between prover and verifier
* **Argument of Knowledge:** Prover demonstrably knows the secret

### Why Groth16?

| Feature       | Groth16       | Other Systems |
| ------------- | ------------- | ------------- |
| Proof size    | 288 bytes ✅   | 1KB-100KB     |
| Verify time   | <1ms ✅        | 10-100ms      |
| Proving time  | 1-3 seconds ✅ | Similar       |
| Battle-tested | Yes ✅         | Varies        |

## BN254 Curve

Groth16 operates over the **BN254** elliptic curve (also called alt\_bn128).

```
Field size: 254 bits
Security level: ~128 bits
Prime: 21888242871839275222246405745257275088548364400416034343698204186575808495617
```

BN254 is natively supported by Solana via ZK syscalls — enabling sub-millisecond on-chain verification.

## How ZK-Provenance Uses ZK Proofs

Our circuit proves the following statement:

> "I know a document `data` and a nonce such that:
>
> 1. `Poseidon(data, nonce) = commitment` (public)
> 2. The commitment is in the Merkle tree with root `R` (public)
> 3. The timestamp is between `t_min` and `t_max` (public)
> 4. The compliance policy `P` was applied (public)"

The verifier sees: commitment, Merkle root, timestamp range, policy hash. The verifier does NOT see: your actual data, nonce, or Merkle path.

## Trusted Setup

Groth16 requires a **trusted setup ceremony** — a one-time process to generate proving and verification keys.

ZK-Provenance uses the **Powers of Tau** ceremony by Hermez Network (2^12 constraints) — a public, community-verified ceremony with thousands of participants.

> If even one participant in the ceremony was honest, the setup is secure.


---

# Agent Instructions: 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 current page URL with the `ask` query parameter:

```
GET https://docs.zkprovenance.io/core-concepts/zk-proofs-explained.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.