Zero-Knowledge Proofs: A Deep Dive

The core ZK intuition

A zero-knowledge proof is a cryptographic protocol where a prover convinces a verifier that a statement is true, without revealing any information beyond the fact that the statement is true. The classic illustration: imagine you want to prove to a colorblind friend that two balls are different colors, without telling them which is which. You show them the balls, they put them behind their back and either switch or do not switch, then show them again. If you can always correctly identify whether they switched, you have proved the balls are distinguishable — but you have revealed nothing about which color is which.

In the digital version, the 'statement' is a mathematical relation: 'I know a value x such that f(x) = y', where y is public and x is secret. A ZK proof convinces the verifier that such an x exists without revealing x itself.

Completeness, soundness, and zero-knowledge

A formal ZK proof system has three properties. Completeness: if the prover knows a valid witness, they can always convince the verifier. Soundness: if the prover does not know a valid witness, they cannot convince the verifier (except with negligible probability). Zero-knowledge: the proof reveals nothing beyond the truth of the statement — a simulator that does not know the witness can produce proofs indistinguishable from real ones.

These three properties together make ZKPs useful for privacy-preserving authentication, selective disclosure, and anonymous credentials — you prove you know something without revealing what you know.

SNARKs: succinct proofs with trusted setup

zk-SNARKs (Succinct Non-interactive ARguments of Knowledge) are the most widely deployed class of ZK proofs. 'Succinct' means the proof is small (hundreds of bytes) and fast to verify (milliseconds), regardless of the complexity of the underlying computation. 'Non-interactive' means the proof is a single message from prover to verifier, with no back-and-forth.

The tradeoff is a 'trusted setup': generating SNARK parameters requires a multi-party computation ceremony where participants must keep their random inputs secret. If all participants collude, they can forge proofs. Modern ceremonies (like Zcash's Powers of Tau) involve hundreds of participants, making collusion practically impossible, but the requirement remains a philosophical concern.

SNARKs are used by Zcash, many Ethereum Layer 2 rollups (zkSync, Polygon zkEVM), and early versions of Midnight's proof system.

STARKs: transparent but larger

zk-STARKs (Scalable Transparent ARguments of Knowledge) eliminate the trusted setup requirement — they use only publicly verifiable randomness, making them 'transparent'. STARKs are also post-quantum secure, as they rely on hash functions rather than elliptic curve assumptions.

The tradeoff: STARK proofs are significantly larger than SNARK proofs (kilobytes vs. hundreds of bytes) and somewhat slower to verify. As hardware and algorithms improve, the size gap is narrowing. STARKs are used by StarkNet (Ethereum L2) and are being explored for future Midnight proof systems.

How Midnight uses ZK proofs

Midnight uses ZK proofs pervasively. Every transaction on Midnight that involves shielded (private) state includes a ZK proof that the state transition was computed correctly. The Compact compiler takes a contract definition and outputs an arithmetic circuit that can be proved in zero knowledge.

When a user submits a Midnight transaction, their local device (via the Midnight SDK) generates the proof using their private witness data. This client-side proof generation is computationally intensive — it can take several seconds on a standard laptop. The resulting proof is attached to the transaction and verified by Midnight nodes, which can do so quickly thanks to the succinct property of the underlying proof system.

Real-world examples of ZK selective disclosure

Age verification without revealing birthdate: A government-issued credential contains your full date of birth. A ZK proof scheme lets you prove 'I am over 18' to any service, with the service verifying a cryptographic proof against the credential's public key — without seeing your actual birthdate or any other personal information.

KYC without data sharing: A user undergoes KYC with one provider and receives a signed credential. They can prove to a DeFi protocol that they are KYC-verified (and in what jurisdiction) without the protocol ever receiving their personal data — the personal data stays with the user, and only the proof is shared.

Confidential transaction amounts: A payment system can prove that Alice paid Bob the correct amount, and that Alice had sufficient balance, without revealing the amounts to anyone except Alice and Bob. Zcash pioneered this use case; Midnight applies similar techniques to smart contract interactions.

Current limitations and tradeoffs

Client-side proof generation is slow. On current hardware, generating a ZK proof for a moderate-complexity Midnight contract takes 5-30 seconds. This creates latency that many consumer applications find unacceptable. Hardware acceleration (GPU/ASIC provers) and algorithmic improvements are active research areas expected to reduce this significantly by 2027.

Circuit complexity limits what can be proved. Not all programs compile efficiently to ZK circuits. Recursion, dynamic loops, and certain data structure operations are expensive or impractical in current ZK systems. Compact's design constrains the contract model to match what ZK circuits can efficiently represent.

The trusted setup concern, while practically mitigated by large ceremonies, remains a conceptual limitation of SNARK-based systems. Projects that require the strongest transparency guarantees may prefer STARK-based alternatives despite the size and verification cost.