Cardano Foundation Shows How to Verify a Zero-Knowledge Proof on Cardano

A Cardano smart contract can check whether someone knows eight numbers that satisfy an equation without receiving the numbers themselves. The Cardano Foundation uses that example to introduce its new series on zero-knowledge proofs. The first tutorial follows the process from writing the equation as a set of constraints to generating the proof off-chain and verifying it in an Aiken test.

Eight Private Numbers, One Public Result

The example groups eight numbers into four pairs. The prover multiplies the two numbers in each pair and adds the four products. The sum must equal 100. That result is public, while the eight numbers remain private.

The tutorial expresses the calculation as five mathematical constraints. Four check the individual products, and the fifth checks that they add up to the public result. A valid proof establishes that the prover knows a set of numbers that satisfies those constraints without revealing which set they used.

How Aiken Checks a 192-Byte Groth16 Proof

The tutorial generates the proof off-chain. The Groth16 proof consists of three elliptic-curve points that occupy 192 bytes in the compressed BLS12-381 format used in the example. The verifier checks the proof against the public inputs and a verification key tied to the circuit.

The walkthrough ends with an Aiken test that uses the same BLS12-381 operations available to Plutus V3 scripts on Cardano mainnet. To make the example reproducible, the tutorial uses fixed, publicly known values for the normally secret part of the setup. In a production Groth16 setup, anyone who retains those secret setup values could forge proofs.

Why On-Chain Verification Matters for Cardano

Cardano developers can build a Groth16 verifier into an Aiken smart contract using existing Plutus V3 operations. An application can generate the proof off-chain, then pass it to the contract so the validator can decide whether a transaction satisfies a condition. The proof and any required public inputs are available to the validator, while the underlying private data can stay off-chain.

For a credential application, that division determines what a user needs to disclose. A contract could check whether a credential holder meets an age requirement without receiving their date of birth, provided the circuit and credential design enforce the claim being proved.

[NEWSBREAK]

What the Next Four Installments Will Cover

The second installment will show how to speed up proof generation and how production setup ceremonies work. It will also compare Groth16 with other proof systems and explore how zero-knowledge virtual machines can prove that a program ran correctly without requiring developers to design a circuit by hand.

The third installment will show how proofs of key ownership can be tied to Cardano addresses. The fourth will turn to selective disclosure. In one planned example, a credential holder proves they are at least 21 without revealing their date of birth or blockchain address.

The final installment will examine quantum-resistant proof systems, focusing on lattice-based approaches that could replace the elliptic-curve assumptions used in Groth16.