Zero-Knowledge Proof

Zero-knowledge proof refers to cryptographic methods that allow one party (the prover) to demonstrate to another party (the verifier) that a statement is true without revealing any additional information beyond the fact that the statement is true.

In the context of blockchain transactions, like those on Zcash, this is primarily achieved using a specific type of Zero-Knowledge Proof (ZKP) called zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) or more modern versions like Halo 2. Cardano is actively integrating ZKC, often using similar technology.

Zero-knowledge proof

The Core Idea: Proof Without Exposure.

Imagine a transaction where a user wants to prove two things:

• They own the private keys corresponding to an address holding funds.
• The transaction logic is valid (e.g., input >= output, no double spending, etc.).

In a transparent blockchain (like Bitcoin), you prove this by revealing the input addresses, the amount, and the destination address. With ZKC, you prove it by generating a cryptographic proof that verifies these conditions without revealing the actual addresses or amounts.

How it Works: A Programmer’s Perspective

The process involves a complex series of mathematical transformations to convert the transaction logic into a verifiable, non-interactive proof.

1. Arithmetization (The Circuit) – The first step is to transform the entire logic of the transaction’s validity rules into a single mathematical problem, often represented as a system of polynomial equations or a Rank-1 Constraint System (R1CS). This representation is called a circuit.
   • Input Data: The secret information (e.g., the amount being sent, the old balance, the private keys) is known as the witness. The public information (e.g., the hash of the transaction, the commitment to the new balance) is the public input.
   • Conversion: Every logical operation in the transaction’s validation rules (if (old_balance >= amount_sent)) is converted into an equivalent set of polynomial equations or constraints.
   • Output: The circuit is essentially a deterministic program that outputs a boolean (valid/invalid) based on the inputs, but it’s expressed entirely in algebraic terms.
2. Proof Generation (The Prover) – The Prover (the sender of the transaction) takes the witness (private data) and the public inputs and computes the necessary cryptographic proof using the circuit.
   • The Prover uses complex polynomial algebra and elliptic curve cryptography to generate a short, non-interactive proof. This proof is a sequence of numbers (often just a few hundred bytes).
   • Key Property: The generated proof is mathematically sound only if the secret witness satisfies all the constraints defined in the circuit (i.e., the transaction rules were followed).
   • In Zcash, for a shielded transaction, the proof generation process involves:
     • Proving that the note being spent exists and has not been spent before.
     • Proving that the user knows the spending key for that note.
     • Proving that the input value equals the output value (funds are conserved).
     • Crucially, all this is proven without revealing the input note, the amount, or the addresses.
3. Proof Verification (The Verifier) – The Verifier (a node on the network) receives the public transaction data and the generated proof.
   • The Verifier does not need the original secret witness.
   • The Verifier uses a public verification key and the public inputs to run a short, efficient cryptographic check on the proof.
   • Output: The check simply returns True or False.
   • True means: “The Prover followed all the rules of the circuit, and the transaction is valid.”False means: “The proof is invalid, which implies the transaction logic was violated.”