Back to Blog
Education

ZK Proofs Explained for Developers

By DEOS Team

Zero-knowledge proofs sound like magic. Prove you know something without revealing what you know. It seems impossible until you understand the mechanics.

This is a developer's guide to ZK proofs—focused on intuition and practical application, not mathematical rigor.

The Core Idea

A zero-knowledge proof lets you prove a statement is true without revealing why it's true.

Example: Prove you know the password to a system without revealing the password.

Example: Prove a computation produced a specific result without revealing the inputs.

Example: Prove you're over 21 without revealing your actual age.

The proof is convincing—a verifier can be certain the statement is true. But the proof reveals nothing beyond the truth of the statement.

The Players

Every ZK proof system has three roles:

Prover: Knows the secret (the "witness") and wants to prove something about it.

Verifier: Wants to be convinced the statement is true, without learning the secret.

Statement: The claim being proven (e.g., "I know a password that hashes to X").

How It Works (Intuitively)

Imagine proving you can solve a maze without showing your solution:

  1. You solve the maze and memorize the path
  2. The verifier picks random checkpoints
  3. You prove you can get from any checkpoint to any other
  4. After enough checkpoints, the verifier is convinced you know the full path
  5. But they never see the actual path

This is the essence of ZK: convince through randomized challenges that you could only answer if you knew the secret.

Types of ZK Proofs

Interactive vs Non-Interactive

Interactive: Prover and verifier exchange messages. Each challenge requires a response.

Non-interactive: Prover generates a single proof that anyone can verify. More practical for most applications.

SNARKs and STARKs

SNARKs (Succinct Non-interactive ARguments of Knowledge):

  • Very small proofs (hundreds of bytes)
  • Fast verification
  • Require trusted setup (someone generates initial parameters)
  • Currently more mature

STARKs (Scalable Transparent ARguments of Knowledge):

  • Larger proofs (tens of kilobytes)
  • No trusted setup (transparent)
  • Quantum-resistant
  • Scaling better for large computations

Practical Applications

Blockchain Scaling

Prove thousands of transactions are valid with a single small proof. Verify on-chain without re-executing everything.

Privacy Coins

Prove a transaction is valid (inputs = outputs, sender has funds) without revealing sender, receiver, or amount.

Authentication

Prove you know a password/key without transmitting it. The server verifies the proof, not the secret.

Compliance

Prove you meet regulatory requirements without revealing underlying data. "I'm compliant" without showing your books.

Verifiable Computation

Prove a computation was performed correctly. The verifier doesn't re-run the computation—they verify the proof.

ZK for Developers

The Circuit Model

Most ZK systems require expressing computation as an "arithmetic circuit"—a series of addition and multiplication operations over a finite field.

// Simple example: prove you know x such that x^2 = y
circuit Square {
  input x (private)  // the secret
  input y (public)   // the public value

  x * x === y        // constraint
}

The prover knows x, the verifier knows only y. The proof convinces the verifier that the prover knows an x that squares to y.

The Challenge

Converting arbitrary programs to circuits is hard:

  • Loops need to be unrolled
  • Conditionals become constraints
  • Memory access patterns must be predictable
  • Efficiency varies wildly based on the computation

This is why most ZK applications are constrained to specific computations.

The Frontier

Active research is making circuits more expressive:

  • zkVMs that can prove execution of arbitrary programs
  • Recursion allowing proofs to verify other proofs
  • Hardware acceleration making proof generation faster
  • Better compilers from high-level languages to circuits

ZK at DEOS

DEOS takes a different approach:

  1. Deterministic execution captures everything needed to replay a program
  2. The replay is expressible as a circuit (input this value, check the output)
  3. The proof shows that the claimed output matches what the program actually produces

We're not proving arbitrary computation in a circuit. We're proving that our deterministic replay is faithful to the original execution.

This is more tractable than general-purpose zkVMs because:

  • The structure is fixed (replay recorded syscalls)
  • The operations are predictable (inject values, verify outputs)
  • The computation is already captured (we're proving replay, not original execution)

Getting Started

If you want to experiment with ZK:

  • Circom/SnarkJS: JavaScript-based, good for learning
  • Noir: Rust-like language, developer-friendly
  • Risc0: zkVM for Rust programs
  • SP1: Another Rust zkVM, different tradeoffs

Start simple. Prove you know a preimage of a hash. Then work up to more complex statements.

The Takeaway

ZK proofs let you prove statements without revealing secrets. They're moving from cryptography research to production systems.

For DEOS, ZK enables the final piece: not just recording execution, but proving it happened correctly. Deterministic execution plus ZK proofs equals verifiable computation.

More on how we use ZK at DEOS in future posts.