← Back to Academy
Cryptography · Foundations

Zero-Knowledge Proof (ZKP) Theory

⏱ ~4 hours 📚 Theory + Math Beginner

Introduction to Zero-Knowledge Proofs

A zero-knowledge proof (ZKP) is a cryptographic method that allows one party — the prover — to convince another party — the verifier — that a statement is true, without revealing any information beyond the truth of the statement itself.

The concept was introduced by Goldwasser, Micali, and Rackoff in their landmark 1985 paper "The Knowledge Complexity of Interactive Proof Systems." It sounds paradoxical at first: how can you prove something without revealing why it is true? The answer lies in the mathematics of probability and computational hardness.

The classic example — the cave: Imagine a circular cave with a magic door in the middle requiring a secret password. Alice wants to prove to Bob she knows the password, without revealing it. Bob waits outside; Alice enters from either path. Bob shouts which path to exit from. If Alice knows the password, she always exits correctly. After 20 rounds, the probability of guessing correctly every time without knowing the password is 1 in 2²⁰ — less than one in a million. Bob is convinced. Alice revealed nothing about the password.

The Three Core Properties

Every valid zero-knowledge proof system must satisfy three properties:

✅ Completeness

If the statement is true and both prover and verifier follow the protocol honestly, the verifier will be convinced. An honest prover can always prove a true statement.

🔒 Soundness

If the statement is false, no cheating prover can convince an honest verifier (except with negligible probability). False statements cannot be proven.

👁️ Zero-Knowledge

If the statement is true, the verifier learns nothing beyond the fact that it is true. No information about the witness (the secret) is leaked.

📐 Succinctness (bonus)

In SNARKs, proofs are short — a few hundred bytes — regardless of the complexity of the computation being proven. Verification is fast even for enormous computations.

Interactive vs Non-Interactive Proofs

The original ZKP constructions were interactive — the prover and verifier exchange multiple rounds of messages (as in the cave example). This is impractical for IoT: a device cannot engage in a live protocol with a blockchain.

The breakthrough was the Fiat-Shamir heuristic, which transforms interactive proofs into non-interactive ones by replacing the verifier's random challenges with a cryptographic hash. The prover generates the entire proof alone, once. Any verifier can check it at any time without interacting with the prover.

This non-interactive property is essential for FidesInnova: an IoT device generates its proof, sends it to the blockchain, and anyone in the world can verify it years later — without the device being online.

zk-SNARKs Explained

A zk-SNARK (Zero-Knowledge Succinct Non-interactive ARgument of Knowledge) is a specific type of non-interactive ZKP with two additional properties:

  • Succinct — the proof is tiny (hundreds of bytes) regardless of computation size
  • Argument of Knowledge — the prover must actually know the secret witness; it cannot exist without the prover knowing it

zk-SNARKs require a trusted setup — a one-time ceremony that generates public proving and verification keys. The FidesInnova platform uses a pre-computed trusted setup for its circuit. The ceremony output is public and auditable.

The proving and verification keys: The proving key (large, megabytes) is used by the device to generate proofs. The verification key (small, kilobytes) is used by anyone to verify a proof. Only the proving key needs to be on the device.

The Groth16 Proof System

FidesInnova uses the Groth16 zk-SNARK construction (introduced by Jens Groth in 2016) because it produces the smallest, fastest-to-verify proofs of any production-ready zk-SNARK system.

Groth16 proof generation involves three stages:

1

Witness Generation

The prover computes all intermediate values in the computation — the inputs, outputs, and every value produced along the way. This "witness" is the secret that will never be revealed.

2

R1CS Satisfaction

The computation is encoded as a Rank-1 Constraint System — a set of equations that the witness must satisfy. The prover checks that their witness satisfies all constraints.

3

Proof Construction

Using the proving key and the witness, the prover constructs three elliptic curve points (A, B, C) that together form the Groth16 proof (~200 bytes). This involves polynomial evaluations on the BN-128 elliptic curve.

Verification checks a pairing equation over the three proof points using the verification key. On the FidesInnova blockchain, this takes approximately 19 milliseconds.

Arithmetic Circuits: Encoding Computation for ZKP

To generate a ZKP for a computation, that computation must first be expressed as an arithmetic circuit — a graph of addition and multiplication gates over a finite field.

FidesInnova uses the Circom circuit language to define the firmware verification circuit. The circuit encodes: "Given a firmware hash H and sensor reading R, verify that running firmware H on input data produces output R." The circuit is compiled once and the resulting R1CS is used for all subsequent proof generation on devices.

// Simplified Circom circuit example
pragma circom 2.0.0;

template SensorVerification() {
  signal input firmwareHash;
  signal input sensorReading;
  signal input timestamp;
  signal output valid;

  // Constraint: output equals hash(firmware || reading || timestamp)
  valid <== Poseidon([firmwareHash, sensorReading, timestamp]);
}

component main = SensorVerification();

How FidesInnova Applies ZKP to IoT

In the FidesInnova framework, the IoT device (zk-Device) runs the SnarkJS or the native C++/Rust ZKP library embedded in its firmware. At each measurement cycle:

  1. The device takes a sensor reading (e.g., temperature = 22.4°C)
  2. The ZKP library generates a witness from the firmware hash, reading, and timestamp
  3. A Groth16 proof is computed (~694ms on typical ESP32-class hardware)
  4. The proof (200 bytes) and the reading are sent via MQTT to the FidesInnova Node
  5. The Node submits the proof to the blockchain for permanent storage

Any verifier — now or years later — can retrieve the proof from the blockchain and check it against the public verification key. If the check passes, they know with mathematical certainty that the device ran the correct firmware and the reading is authentic.

Reading Proofs in the FidesInnova Explorer

The FidesInnova ZKP Explorer displays all submitted proofs. Each proof record shows:

  • Proof ID — unique identifier for the proof on the blockchain
  • Device ID — the registered device that generated the proof
  • Block number — which blockchain block the proof is anchored in
  • Timestamp — when the proof was submitted
  • Verification status — whether the proof passes the on-chain verifier
  • Proof data — the three elliptic curve points (A, B, C) of the Groth16 proof
Try it: Visit explorer.fidesinnova.io and inspect a live proof. The verification status shows "Valid" when the pairing equation is satisfied. This check is done by the blockchain's on-chain verifier contract — no human needed.

Next Course

Consensus Algorithms & D2PoS →

What You Will Learn

  • Understand what zero-knowledge proofs are and why they matter for IoT
  • Learn the three core properties: completeness, soundness, zero-knowledge
  • Understand how zk-SNARKs and Groth16 work at a conceptual level
  • Learn how arithmetic circuits encode computation for ZKP
  • Understand how FidesInnova applies ZKP to firmware verification
  • Read and interpret ZKP proofs in the FidesInnova Explorer

Course Contents

🤖
AI Learning Assistant

Ask any question about this course topic

Ask AI ↗