What Are Zero Knowledge Proofs
Zero knowledge proofs are cryptographic proofs with an additional, almost paradoxical property: they let you prove something is true without revealing why it’s true or what underlying information makes it true.
You can prove you know a secret without revealing the secret. You can prove a computation was executed correctly without revealing the inputs. You can prove data satisfies certain conditions without revealing the data itself.
This sounds impossible. How can you convince someone of truth without showing them the evidence? But it’s mathematically sound, and it opens up entirely new possibilities for blockchain applications.
The Three Properties: Completeness, Soundness, Zero Knowledge
Every zero knowledge proof system has three fundamental properties:
Completeness means if the statement is true and both parties follow the protocol honestly, the verifier will be convinced. True claims produce valid proofs. This sounds obvious but it’s the foundation: the system has to actually work when used correctly.
Soundness means if the statement is false, no cheating prover can convince the verifier it’s true (except with negligible probability). You can’t fake proofs for false claims. This is critical for security: the proof system has to be robust against adversaries trying to create fraudulent proofs.
Zero Knowledge means the proof reveals nothing beyond the truth of the statement itself. The verifier learns that the claim is valid, but gains no additional information about the underlying data, the witness, or how the claim is satisfied.
These three properties are what make a proof “zero knowledge.” Combined with the properties we discussed in Part 2 (such as succinctness and efficient verification), ZK proofs become incredibly powerful for blockchain applications. But overall, everything still remains quite abstract. To understand how this actually works in practice, let’s look at some simple examples that build intuition before we dive into the real cryptographic systems.
Classic ZK Examples and Analogies
The classic example is the “Ali Baba cave” scenario.
Imagine a cave shaped like a ring with ONE entrance/exit at the front. Once you enter, the path immediately splits into two routes – left and right – that curve around. These two paths meet at the BACK of the ring, where there’s a locked door connecting them. So the cave layout looks like this from above: an entrance at the front, two curved paths forming a circle, and a door at the back connecting those paths.
You claim to know the password that opens the back door.
Here’s how you prove it without revealing the password:
The verifier watches you enter the cave but stays at the entrance where they CAN’T see which path (left or right) you chose. You randomly pick left or right and walk to the back door.
Now the verifier (still at the entrance) randomly shouts either “come out from the LEFT path!” or “come out from the RIGHT path!”
If you know the password: No problem. If you’re on the left and they call for right, you unlock the back door, walk through it, and come out the right side. You can always comply.
If you DON’T know the password: You’re stuck on whichever side you chose. You have a 50% chance they call for the side you’re already on (you get lucky, and simply walk back on the path you came), and 50% chance they call for the opposite side (you’re trapped and can’t comply).
Repeat this 20 times. If you come out the correct side every single time, the odds you just got lucky are 1 in a million.
Another intuitive example: Where’s Waldo puzzles.
You want to prove you found Waldo without revealing where he is. Put the page under a large board with a small window cut out. Show the verifier Waldo through the window. Now remove the board while they’re not looking. They saw Waldo, confirming you know where he is, but they have no idea where on the page he was located.
But here’s what’s important to understand: these are toy examples. They help build intuition, but real zero knowledge proof systems are much more complex. They’re based on advanced mathematics involving polynomial commitments, elliptic curves, and other cryptographic primitives. The intuition holds (proving without revealing), but the mechanisms are far more sophisticated.
How Real ZK Systems Work: Different Approaches
Real-world zero knowledge proof systems face a challenge that our toy examples don’t: they need to be practical for blockchain applications. That means they need to be efficient, they need to produce small proofs, and they need to work for complex computations, not just simple yes/no questions.
This has led to the development of different ZK proof systems, each with different trade-offs. Before we dive into the specific systems, we need to understand something crucial: not every application using “ZK proofs” actually needs the zero knowledge property.
Some applications need privacy. They’re using ZK proofs specifically to hide information while proving statements about it. Other applications don’t care about privacy at all (the data is already public), but they need the other properties we discussed in Part 2: succinctness and efficient verification.
This matters because different proof systems optimize for different things. Understanding what you actually need helps you choose the right approach. Let’s look at the two main categories of ZK proof systems that dominate blockchain applications today.
zk-SNARKs Explained
zk-SNARK stands for “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge.”
Let’s break down what that means:
Zero-Knowledge – reveals nothing beyond the validity of the statement
Succinct – the proof is small and verification is fast
Non-Interactive – no back-and-forth required, just one proof and one verification
Argument of Knowledge – the proof demonstrates the prover actually knows the witness (the information that makes the statement true), not just that such information exists
zk-SNARKs were the first practical ZK proof system widely deployed in blockchain applications. Zcash used them for private transactions. Many ZK rollups use SNARK-based systems.
The key characteristics of SNARKs:
Very small proofs – typically just a few hundred bytes regardless of the computation or data being proved. This is ideal for blockchain where every byte of on-chain data costs gas.
Fast verification – verifying a SNARK takes milliseconds and requires minimal computation. Perfect for smart contracts that need to verify proofs efficiently.
Trusted setup – most SNARK systems require a one-time setup ceremony that generates public parameters. This ceremony must be conducted carefully because if the secret randomness used during setup is compromised, someone could generate fake proofs. This is the main criticism of SNARKs.
Computational intensity – generating SNARK proofs requires significant computational resources. The prover does heavy cryptographic operations. This is the trade-off: cheap verification, expensive proving.
Different SNARK constructions exist (Groth16, PLONK, Marlin, and others) with different trade-offs around proof size, verification time, setup requirements, and proving time. But they all share the core properties: succinct, efficient verification, and typically requiring trusted setup.
zk-STARKs Explained
zk-STARK stands for “Zero-Knowledge Scalable Transparent Argument of Knowledge.” The key differences from SNARKs are “Scalable” and “Transparent.”
Transparent means no trusted setup required. The system parameters are generated using only public randomness. This eliminates the trusted setup vulnerability that concerns people about SNARKs. If you’re paranoid about someone compromising a setup ceremony, STARKs remove that attack vector entirely.
Scalable means proving time grows relatively slowly as the computation size increases. STARKs use different underlying mathematics (polynomial commitments over finite fields rather than elliptic curve cryptography) that make them more efficient for very large computations.
The trade-offs with STARKs:
Larger proofs – STARK proofs are significantly bigger than SNARK proofs, often 10-100x larger. This means more data to post on-chain and higher gas costs for verification.
Slower verification – verifying a STARK takes longer than verifying a SNARK, though still much faster than redoing the original computation.
Better scaling for huge computations – for very large computations, STARKs can actually be more efficient to generate than SNARKs. The proving time grows more gracefully.
Post-quantum security – STARKs are believed to be secure against quantum computers, while SNARK security relies on assumptions that quantum computers could break. This probably doesn’t matter near-term, but it’s a theoretical advantage.
No trusted setup – this is the big win. Many projects choose STARKs primarily to avoid trusted setup concerns, accepting the larger proof size as an acceptable trade-off.
Starknet and StarkEx use STARK-based systems. Other projects use SNARKs. The choice depends on which trade-offs matter more for your specific application.
Trade-offs Between Proof Systems
There’s no universally best ZK proof system. Different constructions optimize for different things, and the right choice depends on your priorities:
If you need the smallest possible proofs and cheapest on-chain verification, SNARKs like Groth16 are hard to beat. The proofs are tiny, verification is extremely fast, and many applications prioritize these factors above all else.
If you want to avoid trusted setup and don’t mind larger proofs, STARKs are compelling. The transparency property matters to some projects enough that they’ll accept higher verification costs.
If you need flexibility and updatable circuits, newer SNARK constructions like PLONK offer advantages over older systems like Groth16. You can update the proving system without redoing the entire trusted setup.
If you’re proving extremely large computations, STARKs’ better proving time scaling might outweigh their larger proof size.
Different projects make different choices based on these trade-offs. ZK rollups using SNARKs post smaller proofs on Ethereum, saving on data availability costs. Projects using STARKs emphasize security and transparency. Both approaches are valid depending on priorities.
The field is also evolving rapidly and new proof systems are being developed that try to capture the best of both worlds: small proofs without trusted setup, fast verification with good proving performance. The trade-offs keep shifting as the cryptography improves.
When Zero Knowledge Matters (and When It Doesn’t)
Here’s something that confuses people: most blockchain applications using “ZK proofs” aren’t actually using the zero knowledge property.
Think back to the three properties: completeness, soundness, and zero knowledge. Many applications only care about the first two. They need proofs that are correct and unforgeable. The zero knowledge property is nice to have, but it’s not why they’re using these proof systems.
The zero knowledge property matters when you need privacy or want to hide information. Use cases where zero knowledge is actually essential:
Private transactions – proving you have sufficient funds to make a payment without revealing your balance or transaction history. Zcash, Tornado Cash, and privacy-focused applications need zero knowledge.
Anonymous credentials – proving you’re over 18 or have a valid credential without revealing your identity or other personal information.
Privacy-preserving verification – proving on-chain behavior (you’re a DeFi expert, early adopter, or long-term holder) without revealing which wallet you own. This enables reward systems that can verify qualifications while maintaining complete privacy.
Confidential business logic – proving a computation was performed correctly without revealing proprietary algorithms or sensitive business data.
But many other applications don’t need or use the zero knowledge property:
ZK rollups – most rollups using ZK proofs aren’t hiding transaction data. They’re using proofs for succinctness and efficient verification. The underlying transactions are often public. The “ZK” in “ZK rollup” is mostly a historical naming convention at this point.
ZK bridges – proving that something happened on another chain doesn’t require hiding what happened. You just need efficient verification of cross-chain data.
Historical data processing – proving that blockchain data was processed correctly doesn’t require privacy. The blockchain data is already public. You’re using proofs for efficient verification of computation over large datasets.
The reason these systems use “ZK proof” technology varies based on which properties they need. Some need privacy and use the zero knowledge property actively. Others need succinctness and verifiability and don’t use the zero knowledge property at all, even though they’re using the same underlying proof systems.
Some systems even deliberately make proofs “non-zero-knowledge” by including additional information in the proof for transparency or debugging purposes. They’re still using SNARK or STARK proof systems, but they’re not actually achieving zero knowledge.
This is important because when you’re evaluating ZK technologies, you need to understand which properties you actually need. Privacy applications require zero knowledge. Scaling solutions care about succinctness and verification efficiency. Data infrastructure cares about correctness and cost. And some applications need multiple properties for different use cases.
The technology is versatile, and the same proof systems can be used for very different purposes depending on which properties you leverage.
ZK Properties in Practice: The Brevis Approach
Brevis exemplifies how ZK proof technology can be leveraged strategically for different properties depending on the use case.
When Privacy Matters: Social-to-Onchain Verification
Our Kaito partnership shows Brevis using the zero knowledge property for its intended purpose. The Brevis Yapper Leaderboard rewards influential voices based on both social contribution and on-chain behavior. But here’s the innovation: participants can prove they’re OGs, DeFi experts, or diamond hands holders without revealing which wallet belongs to which social identity.
The ZK proof verifies three things simultaneously:
- You own an Ethereum wallet that qualifies for the multiplier requirement
- Your Kaito account is associated with this specific Ethereum wallet
- The multiplier calculation is correct based on on-chain behavior
Nobody can see which wallet belongs to which Kaito account. Not Kaito, not Brevis, not anyone. The entire verification is end-to-end privacy-preserving. You get rewarded for your real on-chain contributions without doxxing your wallet.
This solves a problem that most reward systems face: you either stay private or get rewarded for your actual behavior. Privacy-preserving verification using zero knowledge lets you have both.
When Succinctness Matters: Historical Data Access
For Brevis’s ZK Data coprocessor work with protocols like PancakeSwap, Uniswap, Aave, or Beefy, the privacy property isn’t relevant. The data being processed is already public blockchain data. There’s nothing to hide.
What matters is proving that computations over this data were performed correctly, and doing it in a way that’s cheap to verify on-chain. A smart contract can’t efficiently access historical Ethereum data or process data from other chains. But it can efficiently verify a small proof that someone else accessed and processed that data correctly.
Here the key properties are:
Succinctness – Brevis generates small proofs regardless of how much data was processed. Processing 100,000 historical transactions produces a proof that’s a few kilobytes and costs a fixed, reasonable amount of gas to verify.
Soundness – the proof system ensures that false claims can’t be proven. If someone tries to generate a proof claiming they processed data a certain way when they didn’t, the proof will fail verification. The security is cryptographic, not trust-based.
Efficiency – verification is dramatically cheaper than redoing the computation. A smart contract can verify in milliseconds what would take hours to recompute.
The zero knowledge property is there because that’s how the proof system works, but it’s not being actively used. The data could be transparent and the system would work identically, because the data is already public anyway.
When Speed Matters: Real-Time Proving
The examples above show how different applications leverage ZK proofs, sometimes prioritizing privacy, sometimes prioritizing efficient verification of public data. But as we discussed in Part 1, proofs don’t only apply at the application level.
Recall how Ethereum’s architecture relies on about a million validators re-executing everything in each newly proposed block. This redundancy creates fundamental scalability and efficiency limitations. Every validator independently processes the same computations to maintain trustlessness.
Brevis also tackles this problem at the core blockchain infrastructure level through Pico zkVM and Pico Prism (we’ll explore these in depth in Parts 6 and 7). The breakthrough here is proving speed.
Most ZK systems take minutes or even hours to generate proofs for complex computations. But if you want to use proofs to verify blockchain execution itself, you need proofs generated fast enough to keep up with real-time block production. Otherwise, you’re always working with stale data.
Pico Prism achieves 99.6% coverage with proofs generated in under 12 seconds, 96.8% under 10 seconds, with an average proving time of 6.9 seconds.. This means generating proofs of block execution fast enough that they’re available almost immediately after each block is produced. The critical dimension isn’t just that the proofs are correct or succinct. It’s that they’re fast enough to verify the current state of the blockchain, not just historical snapshots.
This is critical as it addresses the scalability problem at its source. Instead of a million validators redundantly re-executing every transaction, one proving system can generate a proof of correct execution, and everyone else verifies that small proof. But this only works if the proof arrives in time to be useful for current blockchain state.
Real-time proving unlocks the possibility of using ZK proofs not just for individual applications, but for blockchain infrastructure itself, potentially allowing Ethereum validators to verify block correctness through proofs rather than re-execution.
Different Properties for Different Needs
This is the pattern you’ll see throughout production ZK systems: the same underlying technology serves different purposes depending on which properties you need. Brevis uses zero knowledge proofs for privacy when linking social and on-chain identities, succinctness and verifiability when processing historical blockchain data, and speed when applications need real-time proving of the latest blockchain state.
Understanding this distinction helps clarify what ZK technology actually unlocks. It’s not just about hiding information. It’s not just about efficient verification. It’s about having a versatile cryptographic tool that can serve multiple purposes depending on what your application needs.
Some use cases demand privacy, some demand efficient verification, and some, like Brevis’s approach, need both depending on the specific application. The technology is powerful because it’s flexible enough to serve all these needs.
Brevis Network© 2023 