Zero-Knowledge Proofs address a fundamental challenge that has existed since the birth of public blockchains: how can a decentralised network verify that the rules are being followed, without making all data public?
When Satoshi Nakamoto launched Bitcoin in 2008, the goal was to create a trustless, decentralised payment system. The solution was a public ledger, the blockchain where every transaction is visible to anyone in the world. This transparency prevents fraud and double spending because no one can quietly alter the record.
However, this same transparency is also a major weakness. In Bitcoin, every wallet address and every transaction amount is public. While wallet addresses are pseudonymous (they do not directly show your real name), researchers have shown that advanced analysis can often link addresses back to real identities. This is not just a Bitcoin problem. Ethereum, the world’s most popular smart contract platform, is also fully transparent. Every smart contract interaction, every token transfer, and every wallet balance can be seen by anyone.
For businesses, this is a serious problem. A company using a blockchain to manage supply chain records or financial settlements does not want competitors to see all its transaction details. For individuals, a transparent blockchain means that financial history, which is normally private, becomes completely public.
Zero-Knowledge Proofs (ZKPs) offer a solution. First described in a landmark 1989 paper by Goldwasser, Micali, and Rackoff, ZKPs allow a prover to convince a verifier that a statement is true without revealing anything else. Applied to blockchain, ZKPs can allow transactions to be verified as valid without revealing the sender, receiver, or amount. Let’s explore how ZKPs achieve this, and how they are being used in real open source blockchain projects today.
What are Zero-Knowledge Proofs?
The basic idea
A Zero-Knowledge Proof is a cryptographic method by which one party (called the prover) can prove to another party (called the verifier) that a certain statement is true, without revealing any information beyond the fact that the statement is indeed true.
A simple way to understand this is through the classic Ali Baba’s Cave example, made famous by cryptographer JeanJacques Quisquater in 1990. Imagine a cave shaped like a ring, with a magic door in the middle that only opens with a secret password. A prover wants to convince a verifier that they know the password, without telling the verifier what the password really is. The prover enters the cave and chooses one of the two paths. The verifier then shouts which path the prover should come out from. If the prover knows the password, they can always come out from the correct path. After many rounds, the verifier becomes convinced the prover knows the password — without ever learning what it is.
Three core properties
Every valid ZKP must satisfy three mathematical properties:
- Completeness: If the statement is true, an honest prover can always convince an honest verifier.
- Soundness: If the statement is false, no dishonest prover can trick the verifier into accepting it, except with a very small (negligible) probability.
- Zero knowledge: The verifier learns absolutely nothing from the proof except that the statement is true. No extra information leaks out.
Interactive vs non-interactive ZKPs
The original ZKPs described by Goldwasser, Micali, and Rackoff in 1989 were interactive. This means the prover and verifier had to communicate back and forth many times. While theoretically solid, interactive proofs are not practical for blockchains, where transactions are stored permanently and must be verifiable by anyone at any time — not just the original two parties.
To solve this, Blum et al introduced Non-Interactive Zero-Knowledge Proofs (NIZKPs). In a non-interactive proof, the prover creates a single piece of evidence (the proof) that can be verified by anyone, at any time, without any further communication. This is essential for blockchain use, where the proof is stored onchain and must be checked by many different nodes.
The privacy problem in open source blockchains
Public blockchains like Bitcoin and Ethereum are designed to be fully transparent. Every transaction is broadcast to the entire network and recorded permanently. While this openness ensures that no single party can manipulate the record, it creates a serious conflict with the need for financial and data privacy.
Despite the pseudonymous nature of blockchain addresses, research has shown that advanced blockchain analytics can often deanonymize users. By correlating onchain transaction data with offchain information, such as exchange records, IP addresses, or social media activity, analysts can often identify who is behind a wallet address. This means that a user’s entire transaction history, which might span years, can be exposed.
For enterprise use cases, this problem is even more serious. Supply chain tracking, healthcare data, financial settlements, and voting systems all require a level of confidentiality that a fully transparent blockchain cannot provide. The challenge is to allow anyone to verify that the rules are being followed — for example, that no coins are being created out of thin air without revealing the specific details of each transaction.
ZKPs directly address this challenge. They allow a blockchain node to verify that a transaction is valid (for example, that the sender has enough funds) without seeing the actual wallet balances or transaction amounts.
Types of Zero-Knowledge Proofs used in blockchain
Several different types of ZKP have been developed over the years, each with different tradeoffs between proof size, generation speed, verification speed, and security assumptions. The three most important types for blockchain applications are zkSNARKs, zkSTARKs, and Bulletproofs.
zkSNARKs (ZeroKnowledge Succinct NonInteractive Arguments of Knowledge): zkSNARKs are the most widely used type of ZKP in blockchain today. The key properties of zkSNARKs are captured in their name: they are Zero-Knowledge (no information is revealed), succinct (the proof is very small and fast to verify), non-interactive (no back and forth communication is needed), and an argument of knowledge (the prover must actually know the secret to generate a valid proof).
The main strength of zkSNARKs is that they produce very small proof sizes and can be verified in milliseconds, which is critical for a blockchain where many nodes need to verify proofs quickly. A benchmark study by ElHajj and Roelink (2024) found that zkSNARKs produced the smallest proofs among the three major ZKP types.
However, zkSNARKs have one important weakness: they require a one-time trusted setup. During this setup phase, a set of public parameters (called a Common Reference String, or CRS) must be generated. If the secret randomness used in this setup is ever known by an attacker, they could create fake proofs that appear valid, potentially counterfeiting tokens or stealing funds. This is often called the toxic waste problem.
To reduce this risk, many projects use a MultiParty Computation (MPC) ceremony, where many independent parties each contribute to the setup. As long as even one participant destroys their share of the secret, the system remains safe. Zcash’s Sapling upgrade involved 87 participants in such a ceremony.
Key use cases: Zcash (shielded transactions), Ethereum zkrollups (Polygon zkEVM, zkSync), StarkWare
zkSTARKs (ZeroKnowledge Scalable Transparent Arguments of Knowledge): zkSTARKs were introduced in a 2018 paper by Eli BenSasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev as an alternative to zkSNARKs. The ‘T’ in STARK stands for ‘transparent’, meaning all the parameters are publicly verifiable and no secret ceremony is needed.
Instead of relying on elliptic curve cryptography (as SNARKs do), STARKs use collision-resistant hash functions. This makes them potentially secure against quantum computers, which are expected to eventually be able to break elliptic curve-based systems. This is a significant long-term advantage.
The downside of zkSTARKs is that they produce much larger proofs than SNARKs. The benchmark study by ElHajj and Roelink found that zkSTARKs generated the largest proofs, which means more storage and higher onchain gas costs. However, they were also the fastest in terms of proof generation and verification time.
Key use cases: StarkEx (used by dYdX and Immutable X), StarkNet
Bulletproofs: Bulletproofs were introduced in 2018 by Bünz, Bootle, Boneh, Poelstra, Wuille, and Maxwell. They are a type of non-interactive ZKP that does not require a trusted setup. The name comes from the fact that they are short (like a bullet) — significantly more compact than older proof systems.
Bulletproofs are particularly efficient for range proofs, which are used to prove that a number falls within a certain range (for example, that a transaction amount is positive and not too large) without revealing the exact number. Monero uses Bulletproofs to enable confidential transactions, which hide transaction amounts. Their adoption reduced transaction data size by up to 80%.
The main drawback of Bulletproofs is that they are slower to verify than both SNARKs and STARKs.
Key use cases: Monero (confidential transactions), Grin
Here’s a summary of the key trade-offs between the three main ZKP types.
- zkSNARKs: Smallest proof size, fast verification, requires trusted setup, vulnerable to quantum attacks.
- zkSTARKs: Largest proof size, fastest generation, no trusted setup, postquantum secure.
- Bulletproofs: Medium proof size, no trusted setup, slowest verification, best for range proofs.
How ZKPs are applied in open source blockchains
Private transactions: The Zcash example: Zcash is the most well-known example of a public blockchain using ZKPs for transaction privacy. It was built directly on the Zerocash protocol, published in 2014 by BenSasson, Chiesa, Garman, Green, Miers, Tromer, and Virza. The paper proposed using zkSNARKs to create a cryptocurrency where transactions are valid but fully private — the sender, receiver, and amount are all hidden behind a cryptographic proof.
In Zcash, users can choose between transparent transactions (similar to Bitcoin) and shielded transactions (fully private). When a shielded transaction is made, a zkSNARK proof is generated that proves the sender has enough funds to make the payment, without revealing the actual balance. It also proves that the transaction outputs are valid (no new coins are created). The network nodes verify this proof without ever seeing the underlying data.
Zcash’s Sapling upgrade in 2018 dramatically improved performance, reducing memory requirements by 97% and proof generation time by 81%, making private transactions practical on mobile devices.
Scalability through ZKRollups: ZKPs are also being used to solve Ethereum’s scalability problem through a technology called ZKRollups. A rollup takes many transactions offchain, processes them in batches, and then uses a ZKP to prove that all transactions in the batch were processed correctly. Only the proof (and a small amount of state data) is submitted to Ethereum’s main chain.
This provides two benefits at once: scalability (many transactions are compressed into one onchain proof) and privacy (the details of individual transactions are not visible on the main chain). Projects like zkSync, Polygon zkEVM, and StarkNet are leading this space.
As noted in a 2024 survey by Mohanty et al, ZKPs enable blockchains to shift from collective to singular computation with networkwide verification, a fundamental change in how distributed systems handle trust.
Private identity and authentication: ZKPs are also being used for privacy — preserving identity verification on blockchains. The traditional way to prove your identity online requires you to share personal data, name, date of birth, national ID with every service you use. This creates massive privacy risks, as every service becomes a potential point of data breach.
With ZKPs, a user can prove they meet a requirement; for example, that they are over 18 years old, or that their credit score is above a certain threshold without revealing the underlying data. The proof is generated from verified credentials stored on the blockchain and can be checked by any verifier.
Zhou et al (2024) conducted an extensive survey of ZKPbased identity sharing systems and found that combining blockchain with ZKP technology provides both decentralised management of identity and strong privacy guarantees, addressing the vulnerability of traditional identity systems to data breaches and identity theft.
Privacy in smart contracts: Ethereum’s smart contracts are fully transparent. Anyone can see the code, the inputs, and the outputs. For many business use cases — such as sealed bid auctions, private voting, or confidential financial agreements — this is unacceptable.
ZKPs allow smart contracts to verify that computations were done correctly without revealing the inputs. For example, in a private auction, a ZKP could prove that the winning bid is the highest one, without revealing what any of the bids actually were. The computation is done offchain, and only the proof is submitted to the smart contract.
Zhang et al (2024) demonstrated a data trading security scheme that combines ZKPs with smart contracts on a blockchain, showing that it is possible to verify the fairness and correctness of a data transaction without any party revealing their private data to the other.
Challenges and limitations
Despite their power, ZKPs are not a perfect solution. Several significant challenges remain.
Computational cost: Generating a ZKP is computationally intensive. Even with modern hardware, creating a zkSNARK proof can take several seconds for complex computations. While verification is fast, the cost of proof generation is still a barrier for widespread adoption, especially on mobile devices or low power systems.
Trusted setup risk (for SNARKs): As discussed, zkSNARKs require a trusted setup ceremony. If this ceremony is compromised — for example, if a participant in the MPC ceremony saves their secret instead of destroying it — the entire security of the system is at risk. An attacker with the toxic waste from the setup could create unlimited counterfeit tokens without detection.
Implementation vulnerabilities: Even when the underlying mathematics of a ZKP is sound, implementation bugs can introduce serious vulnerabilities. A 2024 analysis of ZKP systems by Tang et al found multiple vulnerability classes in real world ZKP implementations, including under constrained circuits, which can allow a prover to generate valid looking proofs for false statements.
This makes security auditing of ZKP-based systems extremely important and complex. Unlike regular software bugs, ZKP vulnerabilities can be subtle and mathematically non-obvious.
Quantum computing threat: zkSNARKs rely on the hardness of elliptic curve discrete logarithm problems. Quantum computers, if they become sufficiently powerful, could solve these problems efficiently and break SNARK-based systems. zkSTARKs, which use hash-based cryptography, are considered post-quantum secure, but they have their own trade-offs in proof size and cost.
Complexity of development: Writing ZKP circuits is much harder than writing regular code. Developers must think in terms of arithmetic circuits, constraint systems, and field elements — concepts that are far removed from everyday programming. This limits the number of developers who can build ZKP-based applications and increases the risk of bugs.
Future directions
Research into ZKPs is advancing rapidly. Several promising directions are being actively explored.
- Recursive proofs: Systems like Halo 2 allow a ZKP to verify another ZKP, enabling highly efficient chains of computation that could dramatically reduce the cost of complex privacy-preserving applications.
- Post-quantum ZKPs: Researchers are working on proof systems that are secure against quantum computers without sacrificing too much performance.
- zkEVM (Zero-Knowledge Ethereum Virtual Machine): Projects are building systems that can prove the correct execution of any Ethereum smart contract using ZKPs, which would enable full privacy and scalability on Ethereum without changing the developer experience.
- ZKbased machine learning: Researchers are exploring how ZKPs can be used to prove that a machine learning model was trained correctly on private data, without revealing the training data or the model weights.
- Standardised ZKP auditing: As ZKP systems become more widely deployed, the community is developing standard frameworks for auditing ZKP circuits and contracts to catch vulnerabilities before deployment.
By allowing proofs of truth without disclosure of data, ZKPs enable private transactions, private smart contract execution, private identity verification, and scalable computation on public blockchains. Technologies like zkSNARKs, zkSTARKs, and Bulletproofs each offer different trade-offs, and the right choice depends on the specific requirements of the application.
Significant challenges remain, including computational costs, the risk of trusted setup compromise, implementation vulnerabilities, and the long-term threat of quantum computing. However, research is advancing rapidly, and ZKPs are already being used in production systems like Zcash, zkSync, StarkNet, and Monero.
As open source blockchain ecosystems continue to mature, ZKPs will play an increasingly central role in making these systems both transparent and private — a combination that was once considered impossible but is now becoming a practical reality.
