Zero-Knowledge Proofs: Proving the Truth Without Revealing the Data

The Premise That You Must Tell to Prove

When we log in, we send our password to a server. The server compares it with the value it has stored and judges it to match. Underneath this procedure lies an old premise. It is the premise that to prove something, you must tell it.

This premise is everywhere in daily life. To buy alcohol, you must hand over an ID card, and the ID card includes not only your birth date but also your name, address, and number. To undergo a loan screening, you must hand over your income data in full. The only things the other party needs to know are "Is this person 19 years of age or older?" and "Does this person's income exceed the threshold?" Yet what we hand over is all the raw material for that judgment.

The handed-over data does not disappear once the judgment is over. It is stored, duplicated, and leaked. The method of sending a password to the server creates by itself one place where a leak can happen. Thus, attempts emerged to finish authentication without the logging-in side and the verifying side directly exchanging information. One proposal does most of the calculation in the user's browser, and the password is not revealed to the server at any point (arXiv:1911.09329 — preprint, not peer-reviewed).

There are two roles in such authentication. The prover is the side that holds a secret and tries to convince the other party that their claim is true, and the verifier is the side that tries to check that claim. In a login, the user is the prover, and the server is the verifier.

Generalizing this idea is zero-knowledge proof. A zero-knowledge proof (ZKP) is a cryptographic apparatus in which the prover convinces the verifier of the fact that they know a certain secret value, while revealing nothing about the secret itself (arXiv:2502.07063 — preprint, not peer-reviewed). The digital signature from "Keys and Locks — Why a Public Key Is Safe to Publish"—that is, a mark that only someone holding a private key can make and anyone can check as long as they have the public key—also shares a resemblance in that it shows one holds the private key without sending the private key. How the two actually connect will be seen later in the Fiat–Shamir transform.

Although the title uses the word "magic," zero-knowledge proofs are engineering built on probability and computational assumptions. A computational assumption is the assumption that "this computational problem cannot be solved within a realistic amount of time." Verification leaves behind a small but non-zero probability of failure. Security leans on computational assumptions, and if those assumptions change, the conclusion changes as well.

The studies cited here are mostly preprints, meaning versions made public before undergoing peer review. All figures are values measured by that paper at that time under those conditions.

The Big Picture — Redefining 'Proof'

Traditionally, a proof is a fixed piece of writing on paper. You follow it step by step to check if it is correct. Interactive proofs, which appeared in the 1980s, added back-and-forth exchanges and probability to this. An interactive proof is a proof in which a prover and a verifier exchange messages to convince the verifier, allowing a small but non-zero probability that a false proof passes verification (DOI: 10.1561/3300000030). Instead of writing everything down on paper to check, it mimics the way mathematicians convince each other through conversation.

An argument resembles an interactive proof, but allows for the existence of a 'proof' for a false statement, while making it require an unaffordable amount of computational power to find (DOI: 10.1561/3300000030). Classical results from the 1980s and 1990s showed that even astonishingly complex statements can, in principle, be verified efficiently. And in principle, any argument can be turned into a zero-knowledge one. This means a proof can be made to reveal nothing except the fact that it is valid. General-purpose zero-knowledge arguments moved from theory to practice in the decade leading up to that survey's publication in 2022.

Beneath this expansion lies a more fundamental shift in perspective. Randomness and proofs are not viewed as ideal entities, but as relative to the observer's capabilities. Therefore, if the shapes of random outcomes—that is, two probability distributions—cannot be distinguished by an efficient procedure, the two are treated as the same. Efficient means finishing within realistic time. The concept of a zero-knowledge proof—namely, "a convincing argument that reveals nothing except the fact that the claim is true"—is established upon this perspective (DOI: 10.1093/oso/9780198537748.003.0016). This rule that indistinguishable things are considered the same becomes the key that later defines "learned nothing."

Metaphors like the "Alibaba cave" provide intuition, but they are not actual protocols—procedures that determine the messages both sides will exchange and their order. If you hold only to the metaphor, you miss the definition.

The very first concrete example covered in textbooks is a protocol over the graph isomorphism problem. A graph is a drawing of dots connected by lines, and two graphs being isomorphic means the two drawings become identical if you just rename the dots. One introductory explainer lets you learn what the words prover, verifier, simulator to appear later, and zero-knowledge mean through this single concrete example (DOI: 10.59350/5bt3p-h4h88 — an introductory explainer article, not a journal paper).

Three Conditions

Three properties define a zero-knowledge proof protocol (DOI: 10.30837/rt.2025.3.222.05). A proposition here is a claim that is either true or false.

• Completeness is the property where, if the proposition is true and the prover is honest, the verifier is convinced.
• Soundness is the property where, if the proposition is false, the probability of a dishonest prover fooling the verifier is very small.
• Zero-knowledge is the property where the verifier learns nothing other than the fact that "the proposition is true."

The first two are intuitive. The third one is difficult. How to write "learns nothing" in the language of mathematics, and how to prove the fact that nothing was gained, are the problems.

Simulator — If You Can Make the Same Record Without a Secret

The answer appears if you follow a simple round of conversation all the way through. The prover first sends a sealed envelope. The verifier randomly picks and asks one of two questions set in advance. When the prover answers, the verifier checks whether the answer matches the contents of the envelope. A prover who knows the secret gives the right answer no matter which question comes. A cheater who does not know the secret can prepare to fit only one question when sending the envelope. If that question comes, they pass; if the other question comes, they get caught.

When the conversation ends, the verifier is left with the envelope, the question they chose, and the answer they received. Now imagine a third party who knows nothing at all about the secret trying to make this record alone. They change the order. They decide on the question randomly beforehand, and then reverse-engineer an envelope and an answer that fit only that question. A person making the record can do what a cheater could not do in a real conversation. If you collect records made this way several times, even how many times a question appears and how the envelope and answer turn out form the same distribution as the records of a real conversation.

If you cannot tell records made without a secret apart from real records, the verifier learned nothing new from the real conversation. That is because you cannot learn anything from something that can be reproduced with materials you already have. The rule we saw earlier — "if you cannot tell them apart, they are the same" — is used here.

A view is everything the verifier saw while running the protocol, in other words, a record combining the messages sent and received and the random numbers they drew. A simulator is a hypothetical third party that produces this view alone without the secret. The person who rigged the record by changing the order in the previous scene is the simulator.

Zero-knowledge is defined like this: If for any verifier there is an efficient simulator that produces that view without the secret, the protocol is zero-knowledge. This must hold true even if the verifier tries to be clever in choosing questions. The reverse-engineering in the previous scene is a method that works when the verifier chooses questions truly at random, and dealing with verifiers who might be malicious requires additional machinery in the simulator.

Statistical distance is a value measuring how different two probability distributions are; the smaller it is, the harder it is to tell the two apart. One study dealing with a distributed environment shared by multiple computers defines "distributed statistical zero-knowledge" in a way that requires the view for each participating computer to be able to simulated within a negligible statistical distance (arXiv:2605.14015 — preprint not peer-reviewed). Research that adds zero-knowledge to Probabilistically Checkable Proofs (PCPs), which check a proof probabilistically by looking at only a few spots, also takes as a guarantee condition that if a verifier looks at only fixed spots of a proof, its view can be efficiently simulated up to a small statistical distance even if the verifier is malicious (DOI: 10.3390/e24070970).

The caveat "within a statistical distance" is where the grades of zero-knowledge diverge (DOI: 10.1155/2014/560484).

• Perfect zero-knowledge is when the view made by the simulator and the real view are completely identical.
• Statistical zero-knowledge is when the two are statistically indistinguishable.
• Computational zero-knowledge is when the two cannot be distinguished by efficient computation.

The perfect side is the strongest. When you encounter the word "zero-knowledge" in a paper, you must check which grade it is to know the strength of the guarantee.

Simulation is the foundation of the definition of zero knowledge and of security proofs, and how many times a protocol must exchange messages is also connected to how a simulator can be constructed (arXiv:2409.06317 — preprint not peer-reviewed). The crossroads is whether the simulator treats the verifier only as a black box — in other words, treating it by receiving questions, feeding in answers, and rewinding if necessary without looking inside the program. A round is a turn of sending and receiving a message once.

A quantum computer is a new kind of computer that uses the laws of physics for extremely small particles in calculations ("Keys and Locks"). In an environment where both the participants and communication are quantum, black-box simulated zero-knowledge where the number of rounds is limited to a fixed few is possible only for problems that quantum computers can efficiently decide on their own (arXiv:2409.06317 — preprint not peer-reviewed). This means it works only when answers come out even without a proof, which is why this kind of environment requires non-black-box simulation techniques or relaxed security notions.

Challenge, Response, and Repetition

The envelope, question, and answer in the simulator scene have formal names in actual protocols. The most widely used interactive structure has 3 steps, and a textbook example is the Schnorr protocol built on the discrete logarithm problem. The discrete logarithm problem is finding how many times a certain number was exponentiated by looking only at the result. It is an example of the one-way computation from "Keys and Locks — Why a Public Key Is Safe to Publish", a calculation that anyone can easily do in one direction but that is absurdly hard to reverse.

In the first step, the prover sends a commitment. A commitment is a device that sends a value in advance, like sealing it in an envelope, so it cannot be swapped later. If you swap it, it is revealed—like the sealing in "What Is A Blockchain — Why A Ledger With No One In Charge Holds Up"—and before you open it, like an envelope, the inside cannot be seen. In the second step, the verifier sends a randomly chosen question, which is a challenge. In the third step, the prover creates a response tailored to that challenge. The verifier checks whether the proof is valid using only this response, without learning the secret underlying it (DOI: 10.54254/2753-8818/14/20240870). This 3-step structure is called a sigma ($\Sigma$) protocol.

The random challenge is the core. Because the challenge is random, the prover cannot prepare the answer in advance. A fraudster who does not know the secret can prepare for only one challenge, as in the simulator scene, and gets caught when a different challenge comes. While luck has a chance of working once, repeating the same procedure many times makes the probability of passing every single time shrink drastically. Soundness is the property that keeps the probability of being fooled bounded to a small value, and repetition is the knob that lowers that probability.

Repetition also has a delicate spot. If you run multiple rounds simultaneously all at once to reduce errors—in other words, if you attach them in parallel—zero-knowledge may not be maintained alongside it. There is a classical result that some protocols with black-box simulators have difficulty preserving zero-knowledge while reducing errors through such parallel composition, and this result has been generalized even to quantum simulator settings (arXiv:quant-ph/0607211 — preprint, not peer-reviewed). Soundness and zero-knowledge do not come together for free.

Proof of Knowledge and the Extractor

Showing that "a proposition is true" is different from showing that "I know the answer." A proof of knowledge is a proof that goes so far as to show that the prover actually knows the answer. The definition looks like a simulator and its twin. An extractor is a procedure that rewinds the prover, throws different challenges into the same envelope, and extracts the actual secret from those responses. If such an extractor exists, that prover must be considered to truly know the secret.

The room for a prover to pass verification even when the extractor fails to extract the secret is called the knowledge error. An analysis that keeps this value tightly bounded can hit dead ends or suffer ballooning losses depending on the extractor's sampling method, so a theoretical study notes that a new technique had to be brought in (DOI: 10.1007/s00145-025-09569-y).

From Interactive to Non-Interactive — Fiat–Shamir

Interactive protocols have a practical inconvenience. The verifier must send challenges on the spot. Because of this, they do not fit settings where a proof is created once and needs to be verified by anyone later. Digital signatures are like this, and so is a blockchain, a ledger shared among many with blocks chained together ("What Is a Blockchain — Why a Ledger With No One in Charge Holds Up").

This is where the Fiat–Shamir transform comes in. The Fiat–Shamir transform is a technique that removes interaction by replacing the random challenge the verifier must send with a value obtained by feeding the conversation so far into a hash function. A hash shrinks any text, no matter how long, into a single short value of fixed length, and changing even a single character results in a completely different value ("What Is a Blockchain — Why a Ledger With No One in Charge Holds Up"). Because the prover generates the challenge alone but cannot manipulate the hash output at will, this achieves an effect similar to a random challenge (DOI: 10.54254/2753-8818/14/20240870). This transform is famous as a technique that converts identification schemes into signature schemes (arXiv:1306.0315 — preprint, not peer-reviewed). The digital signatures and zero-knowledge proofs from the beginning of the primer meet right here.

This transform turns any public-coin interactive proof into a non-interactive one. A public-coin interactive proof is an interactive proof where the values sent by the verifier are simply random values thrown without any hidden calculations. The transformed proof inherits the main security properties of the original under the random oracle model. The random oracle model is a framework for analyzing security by assuming that the hash function is an ideal box that returns a completely random answer every time it is queried (DOI: 10.1007/s00145-023-09478-y).

This transform was originally devised for sigma protocols where messages go back and forth 3 times, but by around 2023 when that research came out, it was also being used in protocols with multiple rounds of communication. A price comes with this. Consider an attack where Q is the number of times the attacker queries the hash function and the protocol throws challenges $\mu$ times, meaning messages go back and forth $(2\mu+1)$ times. The security loss of such protocols generally grows on the scale of roughly Q^\mu (DOI: 10.1007/s00145-023-09478-y). This means that through the transformation, the attacker's room to cheat swells by that much.

Fortunately, it has been proven that in a broad class called special-sound, this loss grows only linearly with Q, meaning it grows in proportion to Q. Special-sound is a property where one can compute the secret by gathering just a few correct responses received for the same first message with different challenges. The same study also presents a negative result. If you repeat a typical protocol of this class in parallel beyond the number of rounds, there is an attack where the loss grows again to a scale proportional to Q^\mu (DOI: 10.1007/s00145-023-09478-y). The linear loss result was later extended to an even broader special-sound class (DOI: 10.1007/s00145-025-09569-y). Hidden behind the phrase "attached Fiat–Shamir" are conditions like these.

What we get this way is a non-interactive zero-knowledge proof. A non-interactive zero-knowledge proof (NIZK) is a zero-knowledge proof where the prover sends just a single message to the verifier. Thanks to having few rounds of communication, it is widely used as a component in various cryptographic protocols (DOI: 10.1155/2014/560484).

What Can Be Proved and What It Relies On

The claims that zero-knowledge proofs can handle are broad. The collection of problems whose answers can be quickly checked once given is called NP, and if a proposition belongs to NP, it can in principle be handled, with non-interactive zero-knowledge proofs for NP problems also having long been studied (DOI: 10.1155/2014/560484). The Goldreich–Micali–Wigderson protocol from the 1980s is a representative construction that demonstrated this generality over the graph coloring problem of coloring adjacent vertices so no two share a color. One preprint generalizes this protocol to serve as a starting point for signature schemes aimed at the post-quantum era (arXiv:2602.02689 — preprint not peer-reviewed).

Instead, constructions covering general NP and systems used in practice stand on computational assumptions. The assumption that one-way functions exist—functions that are easy to compute but hard to invert—is the foundation of modern cryptography, and zero-knowledge interactive proofs are a structure placed upon it (arXiv:cs/0111056 — preprint not peer-reviewed; arXiv:cs/0212055 — preprint not peer-reviewed). The materials used in actual implementations are discrete log proofs, homomorphic encryption, polynomial commitments, hash functions, and elliptic curves (DOI: 10.30837/rt.2025.3.222.05).

If you pick the wrong assumption, the protocol collapses too. Graph isomorphism, which was used for the concept explanation earlier, is a good example. There is an analysis that while it is ideal for teaching, the graph isomorphism problem is easily solved for many types of graphs, making it inappropriate as a basis for practical zero-knowledge authentication (DOI: 10.12794/metadc12076 — thesis). Examples that show a concept and bases that are secure in practice are different.

Succinctness, and What Is Traded Away

The property that rules practical work is succinctness. Succinctness is the property where the size of the proof and the verification time are much smaller than the size of the witness—that is, the original secret material backing up the claim. The verifying side does not redo the original calculation and instead checks only a short proof. Thanks to this property, applications such as computation outsourcing, anonymous credentials, signature aggregation, and blockchain protocols have opened up (DOI: 10.20868/upm.thesis.91808 — doctoral dissertation).

zk-SNARKs, zk-STARKs, and Bulletproofs are the names of representative families of such non-interactive zero-knowledge proofs. There are multiple axes along which these families are compared. They are proof size, prover time, verifier time, memory, and setup assumptions (arXiv:2408.00243 — peer-reviewed preprint). Line them up by a single "which is faster," and the rest of the axes get obscured.

An empirical comparison shows how these axes actually pull in different directions. When running public reference implementations on a consumer ARM computer, zk-SNARKs (Groth16) made proofs faster and smaller in size, but verification was slower and required a trusted setup. zk-STARKs produced larger proofs and slower generation, but verification was fast, used a transparent method requiring no setup, and targeted post-quantum security (arXiv:2512.10020 — peer-reviewed preprint). Which side's costs to reduce—the maker's or the checker's—and whether to trust a setup diverge across families.

These results do not form a universal hierarchy. In a systematic review of 41 papers published from 2015 to April 2023, even protocols in the same family showed real-world performance differences of up to several orders of magnitude depending on the implementation. Because security analysis methodologies also varied widely, a definitive comparison itself was impossible, and the authors noted establishing a common benchmark as a future task (DOI: 10.1002/spy2.401). Performance figures in this field depend heavily not only on the protocol but also on the implementation and experimental conditions. When you encounter "our method is N% faster" in a paper, that is the cue to check the experimental conditions before that N.

The Fork in the Road Called Trusted Setup

The most efficient zk-SNARKs often rely on a one-time trusted setup. A trusted setup is a procedure where public parameters are generated once using a secret value before launching the system, and it relies on believing that the secret value was discarded. These public parameters are often called the "Powers of Tau" string. If the secret value $\tau$ used here leaks, an attacker can forge false proofs, and the soundness of all zk-SNARK systems built on that string collapses all at once (arXiv:2503.04549 — peer-reviewed preprint).

This is why decentralized ceremonies where multiple participants contribute shared randomness were devised, and research to lower the cost of participation continues. One study reports that by reducing the expensive cryptographic operations that must be processed on a ledger to a fixed number per contributor, they made it possible to hold a ceremony for parameters about 16 times larger than existing on-chain methods (arXiv:2503.04549 — peer-reviewed preprint).

The alternative is the transparent family, which needs no setup, and the price is efficiency. Transparent argument systems have historically been inefficient, with larger proof sizes than the trusted setup family. Even in 2025, when that paper came out, research continued to shrink transparent proofs. That paper reports that in a transparent setup, they reduced a core component of the proof to group elements—specifically 10 basic pieces making up the proof—a reduction of about 85%, creating what the authors believe is the shortest construction in a transparent setup (DOI: 10.62056/anudy76bm). The setup problem is a choice of what you give up and what you get.

Where It Is Used

• Blockchain privacy: The privacy guarantee of the cryptocurrency Zcash relies entirely on its zk-SNARK construction (arXiv:2008.00881 — preprint not peer-reviewed).
• Scaling (zk-rollups): A method where transactions are processed outside the original blockchain—that is, the main chain—and proof that the transaction data and its execution are correct is left on the main chain (arXiv:2410.12210 — preprint not peer-reviewed). The performance of such systems is frequently tied to the efficiency of the underlying zero-knowledge proof mechanism. A study analyzing a rollup built in the Hardhat development environment pinpointed that bottleneck (arXiv:2503.22709 — preprint not peer-reviewed).
• Identity and credentials: For credentials given by a trustworthy issuer, one proves only a proposition without revealing any of the contents to the verifier (arXiv:1907.09579 — preprint not peer-reviewed). A framework using zk-STARKs to prove only "18 years of age or older" has also been proposed (arXiv:2510.09715 — preprint not peer-reviewed). This addresses the ID card problem from the bullet point at the top.
• Electronic voting: For voting protocols in board-level elections, a design has been proposed that moves heavy tallying computations off the chain and verifies their correctness with zk-SNARKs. It achieves scalability while preserving a dispute-free property that requires no separate challenge step to check whether the administrator rigged the tally (arXiv:2203.03363 — preprint not peer-reviewed). What needs to be checked in voting connects to "If We Voted on a Blockchain, Nobody Could Tamper With It".
• Verifiable machine learning (ZKML): An attempt to prove that training, inference, and testing were performed as claimed without revealing the data or model parameters (DOI: 10.1007/s10462-026-11557-y).
• Outside the blockchain: A protocol combining commitments and zk-SNARKs for nuclear disarmament verification has been proposed, confirming compliance with treaty constraints without invasive physical inspections while keeping sensitive warhead information secret (arXiv:2507.20074 — preprint not peer-reviewed).
• A deck of cards: Several protocols have been designed to prove, using only physical tools without a computer, that one knows the solution to a puzzle (DOI: 10.1007/s00354-024-00267-0; arXiv:2603.01393 — preprint not peer-reviewed). This is an example showing that zero-knowledge is a concept that holds up even without computers.

Blockchain privacy and rollups have systems actually deployed and running. Verifiable machine learning is an evolving area where circuit expressiveness limits, high proof generation costs, and deployment complexity remain the primary bottlenecks (arXiv:2502.18535 — preprint not peer-reviewed). Nuclear disarmament verification has reached implementations following actual treaty constraints, but it is not a case used in actual treaty operations.

Five Common Misconceptions

The first misconception is "If it's zero-knowledge, it's anonymous." What zero-knowledge proofs hide is the content contained within the proof, not who submitted that proof, when, or from where. A study outlining privacy risks in permissionless blockchains—which anyone is free to join without permission—lists paths unrelated to proof content, such as transaction linking, transaction metadata, on-chain data analysis, and RPC issues. It then positions zero-knowledge proofs, ring signatures, and stealth addresses as solutions for some of them (arXiv:2305.01038 — preprint before peer review). A 2018 literature review diagnosed that blockchain privacy still has a long way to go before it can be trusted, adding that the field is evolving very rapidly (arXiv:1809.10642 — preprint before peer review).

Excessive anonymity also causes problems. In a fully anonymous account system, multiple accounts can be opened without verification, muddying activity. Starting from this issue, a study proposes "trusted anonymity," which binds accounts and credentials showing one is a real person one-to-one using zero-knowledge proofs and linkable ring signatures, while hiding the correspondence between them (arXiv:2301.02102 — preprint before peer review). Privacy and accountability are separate axes, and zero-knowledge proofs are a tool for designing the space between them.

The second misconception is "It's safe because it's mathematically proven." Many people regard SNARKs as "just math" and presuppose that what is proven is also correct in practice. A study that collected and classified 141 vulnerabilities in actual implementations directly refutes that presupposition (arXiv:2402.15293 — preprint before peer review). The same goes for the circuit side, where the computation to be proven is transcribed. When fuzzing—which bombards widely used libraries with random inputs—was applied, it surfaced 10 new bugs confirmed by developers (arXiv:2504.14881 — preprint before peer review), and 12 zero-day bugs that caused deployed zk-rollups to fail transaction finalization were discovered and fixed (arXiv:2410.12210 — preprint before peer review).

This gap stems from the architecture. According to a study investigating over 40 zk-SNARK schemes and 11 general-purpose libraries together, academic interest is skewed toward proof systems, whereas the bottleneck in the industrial field lies on the constraint system side—translating programs into a bundle of equations that can be proven (arXiv:2502.02387 — preprint before peer review). There is always a gap between theorems on paper, compiled circuits, and deployed code.

The third misconception is "Trusted setup is a formal procedure." As seen earlier, if setup secrets leak, fake proofs become possible (arXiv:2503.04549 — preprint before peer review). Who performed the setup and whether those secrets were truly discarded are social trust issues outside the protocol. Transparent families eliminate precisely this problem while trading off efficiency (DOI: 10.62056/anudy76bm). When evaluating a system, "Is there a trusted setup?" is an item to check before performance tables.

The fourth misconception is "Proofs are cheap because they are short." Fast verification and cheap proof generation are different stories. Generating proofs is still expensive, and two types of heavy computations—multiscalar multiplication (MSM) and number-theoretic transform (NTT)—dominate execution time. There is also research that moved this bottleneck onto AI accelerators, boosting number-theoretic transform throughput up to 10 times compared to comparison targets (arXiv:2604.17808 — preprint before peer review). Whether a prover can run in polynomial time to begin with—that is, time that grows only as much as can be handled even when the input gets large—is a property that must be demanded separately. Only when the prover is polynomial-time and the verifier takes time roughly proportional to the input size do real-world computing entities actually enjoy the benefits of interactive proofs (DOI: 10.1561/0400000084). High proof cost being cited as a representative bottleneck in verifiable machine learning is for the same reason (arXiv:2502.18535 — preprint before peer review).

The fifth misconception is "Quantum computer stories are all the same story." It differs by family. Families relying on elliptic curve and discrete logarithm assumptions and those relying on hash functions have different standing in the face of quantum threats. One empirical comparison also classifies zk-STARKs as transparent and post-quantum secure (arXiv:2512.10020 — preprint before peer review). The possibility of quantum vulnerability is already on the priority task list for this field (DOI: 10.30837/rt.2025.3.222.05). Quantum threats to cryptography overall are addressed in "Will Quantum Computers Really Break All Encryption?".

The simplification that "Everything breaks when quantum computers arrive" is also incorrect. Taking the Fiat–Shamir transform as an example, a 2013 study stated that proving the security of this transform in the quantum random oracle model appears difficult. It showed that if the underlying identification scheme is secure against active attackers who directly meddle in the conversation and the prover's first message is independent of secrets, a black-box extractor cannot exist. The same paper also presents cases where modifying the protocol first revives the result (arXiv:1306.0315 — preprint before peer review). A 2019 follow-up study presented a generic reduction for 3-round sigma protocols, showing that soundness and proof-of-knowledge properties are preserved even under quantum attacks, while pointing out that some claims in the literature were incorrect (arXiv:1902.07556 — preprint before peer review). When models and assumptions change, conclusions change too. To answer "Is it secure against quantum?", one must ask "In which model, under what assumptions" together.

The literature this article draws upon is skewed toward concepts, surveys, and implementation analyses. There are more risks in practice that theoretical literature does not cover well, such as side channels where secrets leak through ancillary signals like execution time, or new leaks that arise during the process of optimizing implementations. The list covered here is not the sum total of all risks.

To Go Deeper

This is the bare minimum foundation for opening a paper in this field. Reduced to three sentences, it is this. First, zero-knowledge proofs are the result of expanding the concept of a "proof" into interaction and probability, and they are engineering built on top of computational assumptions. Second, their core definition is the simulator — if you can generate the verifier's view without the secret, the verifier has learned nothing new. Third, choices in practice are trade-offs across multiple axes: setup assumptions, proof size, prover cost, and security assumptions.

Here are further readings by category.

• Overall landscape: A survey that ties together five approaches, from interactive proofs to zero-knowledge arguments, into a single framework (DOI: 10.1561/3300000030). To see where the concepts started, look at the 1990 classic survey (DOI: 10.1093/oso/9780198537748.003.0016).
• If you want to browse applications: A survey that categorizes uses inside and outside of blockchain and provides a comparison table (arXiv:2408.00243 — preprint, not peer-reviewed). The theoretical landscape of the non-interactive family is at (DOI: 10.1155/2014/560484).
• If you want to build one yourself: An investigation that measures and compares 25 general-purpose frameworks and even releases the execution environment (arXiv:2502.07063 — preprint, not peer-reviewed), and a walkthrough that follows the internals of zk-SNARKs without prior knowledge (arXiv:1906.07221 — preprint, not peer-reviewed).
• If you want to use them safely: A classification of 141 real-world vulnerabilities (arXiv:2402.15293 — preprint, not peer-reviewed), and a summary of the gap between theory and practice (arXiv:2502.02387 — preprint, not peer-reviewed).
• To go deeper into theory: A report organizing 128 papers on the theoretical foundations of verifiable computation (arXiv:2308.15191 — preprint, not peer-reviewed).

When you open a paper in this field, there are five premises to check before the performance tables. ① Is it interactive or non-interactive? ② Is the setup trusted or transparent? ③ Is zero-knowledge perfect, statistical, or computational? ④ What computational assumption does it rest on (discrete log, lattice, hash)? ⑤ Is the adversary classical or quantum? Once you confirm these five answers, what the theorems and experiments that follow are claiming becomes clear. Comparing premises before comparing numbers is what separates someone who reads this field from someone who just copies conclusions.

---

Source Papers

• "Proofs, Arguments, and Zero-Knowledge," Foundations and Trends in Privacy and Security (2022) — DOI: 10.1561/3300000030 — Conceptual extension of interactive proofs and arguments (interaction + non-zero error probability), where any argument can in principle be transformed into zero-knowledge. An integrated survey of five approaches.
• "Randomness, Interactive Proofs, and Zero-Knowledge - A Survey," The Universal Turing Machine: A Half-Century Survey (1990) — DOI: 10.1093/oso/9780198537748.003.0016 — Redefining randomness and proofs as concepts relative to an observer's capabilities. Zero-knowledge = a convincing argument that reveals nothing other than the validity of the statement.
• "Zero Knowledge Proofs — A Primer" (2016) — DOI: 10.59350/5bt3p-h4h88 — An introductory commentary familiarizing readers with the terms prover, verifier, simulator, and zero-knowledge using the graph isomorphism problem. An explanatory article rather than an academic journal paper.
• "Zero-knowledge proof protocols: theoretical foundations and applications in modern cryptography," Radiotekhnika (2025) — DOI: 10.30837/rt.2025.3.222.05 — Completeness, soundness, and zero-knowledge property, interactive/non-interactive classification, mathematical ingredients (discrete logarithms, polynomial commitments, elliptic curves), and challenges (scalability, trusted setup, quantum).
• "Distributed Statistical Zero-Knowledge Proofs via Sumcheck" (2026) — arXiv:2605.14015 — Definition of distributed statistical zero-knowledge requiring that each node's view can be simulated within a negligible statistical distance. Preprint prior to peer review.
• "Shielding Probabilistically Checkable Proofs: Zero-Knowledge PCPs from Leakage Resilience," Entropy (2022) — DOI: 10.3390/e24070970 — Guarantee condition for ZK-PCPs requiring that a malicious verifier's view can be efficiently simulated up to a small statistical distance.
• "The Black-Box Simulation Barrier Persists in a Fully Quantum World" (2024) — arXiv:2409.06317 — Simulation as the foundation of zero-knowledge definitions and security proofs. Impossibility of constant-round black-box simulation zero-knowledge in a fully quantum setting. Preprint prior to peer review.
• "Examining Schnorr's protocol in the context of zero-knowledge proofs," Theoretical and Natural Science (2023) — DOI: 10.54254/2753-8818/14/20240870 — Three-step structure of commitment → random challenge → response, verifier confirming validity without knowing the secret, and making it non-interactive using a hash function.
• "On parallel composition of zero-knowledge proofs with black-box quantum simulators" (2006) — arXiv:quant-ph/0607211 — Result showing that parallel composition aimed at reducing soundness error is difficult to reconcile with zero-knowledge property under black-box simulators. Preprint prior to peer review.
• "The Fiat–Shamir Transformation of Special-Sound Interactive Proofs," Journal of Cryptology (2026) — DOI: 10.1007/s00145-025-09569-y — Knowledge error and extractor-based analysis. Loss in the special-sound class is linear in the number of queries and independent of the number of rounds.
• "Fiat–Shamir Transformation of Multi-Round Interactive Proofs (Extended Version)," Journal of Cryptology (2023) — DOI: 10.1007/s00145-023-09478-y — Non-interactivity of public-coin interactive proofs and the random oracle model. Multi-round Q^μ security loss and the linear loss of special-sound.
• "A Survey of Noninteractive Zero Knowledge Proof System and Its Applications," The Scientific World Journal (2014) — DOI: 10.1155/2014/560484 — NIZK = a single message. NIZK for NP problems, statistical and perfect zero-knowledge, and connection to zaps.
• "Eidolon: A Post-Quantum Signature Scheme Based on k-Colorability" (2026) — arXiv:2602.02689 — Generalization of the Goldreich–Micali–Wigderson zero-knowledge protocol + Fiat–Shamir transformation + Merkle commitment. Preprint prior to peer review.
• "Some Facets of Complexity Theory and Cryptography: A Five-Lectures Tutorial" (2001) — arXiv:cs/0111056 — One-way functions (easy to compute, hard to invert), zero-knowledge protocols, and interactive proof systems. Preprint prior to peer review.
• "Mathematical foundations of modern cryptography: computational complexity perspective" (2002) — arXiv:cs/0212055 — Computational complexity foundations of encryption, pseudorandomness, zero-knowledge interactive proofs, and multi-party protocols. Preprint prior to peer review.
• "An investigation into graph isomorphism based zero-knowledge proofs" — DOI: 10.12794/metadc12076 — Analysis showing that graph isomorphism is easily solved for many graph types, making it unsuitable as a practical ZKP foundation. Dissertation.
• "Cryptography for a Verifiable World: Foundations and Applications of Succinct Proof Systems" — DOI: 10.20868/upm.thesis.91808 — Definition of succinctness (proof size and verification time being much smaller than the witness) and the application landscape. Ph.D. dissertation.
• "A Survey on the Applications of Zero-Knowledge Proofs" (2024) — arXiv:2408.00243 — Comparison criteria (proof size, prover/verifier time, memory, setup assumptions) and classification of applications inside and outside blockchain. Preprint prior to peer review.
• "A Comparative Analysis of zk-SNARKs and zk-STARKs: Theory and Practice" (2025) — arXiv:2512.10020 — Real-world measurements on the ARM platform. SNARKs feature fast proof generation and small size but slow verification and require a trusted setup, whereas STARKs are the opposite and are transparent and post-quantum oriented. Preprint prior to peer review.
• "Systematic review: Comparing zk-SNARK, zk-STARK, and bulletproof protocols for privacy-preserving authentication," Security and Privacy (2024) — DOI: 10.1002/spy2.401 — Review of 41 papers. Real-world performance among implementations differs by up to several orders of magnitude, and security analysis methodologies vary widely, preventing definitive comparison.
• "Lite-PoT: Practical Powers-of-Tau Setup Ceremony" (2025) — arXiv:2503.04549 — Leakage of the trusted setup secret τ enables false proofs and undermines the soundness of all zk-SNARKs built upon it. Preprint prior to peer review.
• "Improved Constant-Sized Polynomial Commitment Schemes Without Trusted Setup," IACR Communications in Cryptology (2025) — DOI: 10.62056/anudy76bm — Top-performing arguments rely on a trusted setup, while the transparent family has historically been inefficient (disadvantaged in proof size).
• "Demystifying the Role of zk-SNARKs in Zcash" (2020) — arXiv:2008.00881 — Zcash's privacy guarantees depend entirely on the zk-SNARK construction. Preprint prior to peer review.
• "Analyzing Performance Bottlenecks in Zero-Knowledge Proof Based Rollups on Ethereum" (2025) — arXiv:2503.22709 — Performance of zk-rollups is constrained by the efficiency of the ZKP mechanism. Preprint prior to peer review.
• "ZKlaims: Privacy-preserving Attribute-based Credentials using Non-interactive Zero-knowledge Techniques" (2019) — arXiv:1907.09579 — SNARK-based credentials. Proving only propositions without revealing contents, and non-interactive presentation. Preprint prior to peer review.
• "A Scalable, Privacy-Preserving Decentralized Identity and Verifiable Data Sharing Framework based on Zero-Knowledge Proofs" (2025) — arXiv:2510.09715 — Proving conditions such as "age 18 or older" using zk-STARKs. Large proof size but no trusted setup and post-quantum secure. Preprint prior to peer review.
• "Dispute-free Scalable Open Vote Network using zk-SNARKs" (2022) — arXiv:2203.03363 — Verifying off-chain aggregation calculation accuracy with zk-SNARKs to achieve both scalability and dispute-free properties. Preprint prior to peer review.
• "A survey of zero-knowledge proof based verifiable machine learning," Artificial Intelligence Review (2026) — DOI: 10.1007/s10462-026-11557-y — Three categories of verifiable training, inference, and testing, along with implementation challenges and commercialization trends.
• "A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning" (2025) — arXiv:2502.18535 — Circuit expressive power limitations, high proof costs, and deployment complexity as the main bottlenecks. Preprint prior to peer review.
• "Cryptographic Data Exchange for Nuclear Warheads" (2025) — arXiv:2507.20074 — Commitment + zkSNARKs used to verify treaty compliance without invasive inspections while keeping warhead information confidential. Preprint prior to peer review.
• "NP-Completeness and Physical Zero-Knowledge Proofs for Sumplete, a Puzzle Generated by ChatGPT," New Generation Computing (2024) — DOI: 10.1007/s00354-024-00267-0 — A protocol proving knowledge of puzzle solutions using only physical cards.
• "NP-Completeness and Physical Zero-Knowledge Proof of Hotaru Beam" (2026) — arXiv:2603.01393 — Zero-knowledge proofs implementable with physical tools. Preprint prior to peer review.
• "Exploring the Privacy Concerns in Permissionless Blockchain Networks and Potential Solutions" (2023) — arXiv:2305.01038 — A list of privacy risks unrelated to content, such as transaction linking, transaction metadata, and on-chain analysis. Preprint prior to peer review.
• "Privacy in Blockchain Systems" (2018) — arXiv:1809.10642 — Literature review concluding that blockchain privacy has not yet reached a reliable level. Preprint prior to peer review.
• "Linking Souls to Humans: Blockchain Accounts with Credible Anonymity for Web 3.0 Decentralized Identity" (2023) — arXiv:2301.02102 — The issue where fully anonymous account systems allow the creation of multiple accounts without authentication to obscure activity. Preprint prior to peer review.
• "SoK: What don't we know? Understanding Security Vulnerabilities in SNARKs" (2024) — arXiv:2402.15293 — Rebuttal to the premise of viewing SNARKs as "just math." Classification of 141 real-world vulnerabilities. Preprint prior to peer review.
• "Towards Fuzzing Zero-Knowledge Proof Circuits (Short Paper)" (2025) — arXiv:2504.14881 — 10 new bugs identified and confirmed by developers through fuzzing widely used ZKP circuit libraries. Preprint prior to peer review.
• "fAmulet: Finding Finalization Failure Bugs in Polygon zkRollup" (2024) — arXiv:2410.12210 — Discovery and patch of 12 zero-day bugs causing finalization failures in deployed zk-rollups. Preprint prior to peer review.
• "SoK: Understanding zk-SNARKs: The Gap Between Research and Practice" (2025) — arXiv:2502.02387 — Diagnosis of the gap where academia sees proof systems as the bottleneck, whereas industry sees constraint systems as the bottleneck. Preprint prior to peer review.
• "Enabling AI ASICs for Zero Knowledge Proof" (2026) — arXiv:2604.17808 — Proof generation costs remain high, with MSM and NTT dominating execution time. Preprint prior to peer review.
• "On Doubly-Efficient Interactive Proof Systems," Foundations and Trends in Theoretical Computer Science (2018) — DOI: 10.1561/0400000084 — Provers must run in polynomial time and verifiers in nearly linear time for real-world computing entities to reap the benefits of interactive proofs.
• "The Fiat-Shamir Transformation in a Quantum World" (2013) — arXiv:1306.0315 — Security proofs for Fiat–Shamir appear difficult in the quantum random oracle model, and black-box extractors may not exist. Preprint prior to peer review.
• "Security of the Fiat-Shamir Transformation in the Quantum Random-Oracle Model" (2019) — arXiv:1902.07556 — Showing through general reductions that soundness and proof-of-knowledge properties are preserved even under quantum attacks, refuting certain claims in existing literature. Preprint prior to peer review.
• "Zero-Knowledge Proof Frameworks: A Systematic Survey" (2025) — arXiv:2502.07063 — Definition of ZKPs, usability and empirical performance measurements of 25 general-purpose frameworks, and public release of execution environments. Preprint prior to peer review.
• "Why and How zk-SNARK Works" (2019) — arXiv:1906.07221 — Internal walkthrough of zk-SNARKs using examples without prior knowledge. Preprint prior to peer review.
• "State of the Art Report: Verified Computation" (2023) — arXiv:2308.15191 — Theoretical foundations and practice of verifiable computation synthesized across 128 papers and over 4,000 pages. Preprint prior to peer review.
• "Zero Knowledge Proof based authentication protocol using graph isomorphism" (2019) — arXiv:1911.09329 — Authentication without direct information exchange between the claimant and verifier. A structure that does not reveal passwords to the server. Preprint prior to peer review.