A Zero-Knowledge Proof (ZKP) is a cryptographic protocol that enables one party, designated the prover, to convince another party, designated the verifier, that a particular mathematical statement is true without disclosing any information beyond the bare fact that the statement is indeed true.

The concept originates from the foundational insight that knowledge and verification are fundamentally separable: it is possible to demonstrate possession of knowledge without transferring that knowledge.

In the context of blockchain technology and cryptocurrency, Zero-Knowledge Proofs have become one of the most transformative cryptographic primitives, enabling privacy-preserving transactions, scalable Layer 2 computation, verifiable off-chain processing, and identity systems that prove attributes without revealing underlying data.

The mathematical foundation of Zero-Knowledge Proofs rests on the theory of computational complexity and interactive proof systems. A proof system satisfies the zero-knowledge property if, for every possible verifier, including adversarial verifiers attempting to extract information, there exists a simulator that can produce a transcript indistinguishable from a real proof interaction without access to the prover’s secret witness.

This simulation model, introduced by Goldwasser, Micali, and Rackoff in their seminal 1985 paper, formalized the intuition that a proof reveals “nothing” by showing that whatever the verifier could compute from the proof interaction, it could also compute independently without any interaction.

The three essential properties are completeness (an honest prover can always convince an honest verifier of a true statement), soundness (no cheating prover can convince a verifier of a false statement except with negligible probability), and zero-knowledge (the verifier learns nothing beyond the truth of the statement).

In blockchain applications, Zero-Knowledge Proofs address the fundamental tension between transparency and privacy that characterizes public ledger systems. Bitcoin and Ethereum, by design, make all transaction data publicly visible, including amounts, addresses, and smart contract interactions, creating a permanent, auditable record that simultaneously exposes users to surveillance, front-running, and financial profiling. Zero-Knowledge Proofs address this by allowing users and systems to prove compliance, correctness, or possession without exposing the underlying data. A ZKP can prove that a transaction is valid (inputs equal outputs, no double-spending, sender has sufficient balance) without revealing who sent how much to whom.

Origin & History

1985: Shafi Goldwasser, Silvio Micali, and Charles Rackoff publish “The Knowledge Complexity of Interactive Proof-Systems,” introducing the formal definition of zero-knowledge proofs and establishing the theoretical foundations of the field. This paper contributed to Goldwasser and Micali receiving the Turing Award in 2012 for their work in cryptography.

1986: Oded Goldreich, Silvio Micali, and Avi Wigderson demonstrate that every problem in NP has a zero-knowledge proof, establishing the extraordinary generality of zero-knowledge: any statement that can be efficiently verified can also be proven in zero-knowledge. In the same period, Amos Fiat and Adi Shamir publish the Fiat-Shamir heuristic, transforming interactive proofs into non-interactive ones by replacing the verifier’s challenges with hash function outputs. This transformation became the standard technique for deploying ZKPs in non-interactive settings, including blockchain.

1988: Manuel Blum, Paul Feldman, and Silvio Micali introduce Non-Interactive Zero-Knowledge (NIZK) proofs using a common reference string model, removing the requirement for back-and-forth communication and laying groundwork for practical applications.

2012: Nir Bitansky, Ran Canetti, Alessandro Chiesa, and Eran Tromer formalize Succinct Non-Interactive Arguments of Knowledge (SNARKs), providing the theoretical basis for the compact proofs that would become central to blockchain privacy and scaling.

2013: The Pinocchio protocol, developed by Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova at Microsoft Research, demonstrates the first practical zk-SNARK construction efficient enough for real-world deployment, proving that general-purpose verifiable computation was feasible.

2014: The Zcash project (originally Zerocash) begins development, representing the first major deployment of zk-SNARKs in a cryptocurrency. The Zcash ceremony, coordinated by the Electric Coin Company, generates the first trusted setup parameters used in production, enabling fully shielded (private) cryptocurrency transactions.

2016: Jens Groth publishes the Groth16 proving system, which achieved the smallest proof sizes and fastest verification times of any pairing-based SNARK at the time. Groth16 became one of the most widely deployed SNARKs in production systems, used by Zcash, Tornado Cash, and numerous other protocols.

2018: Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev publish the zk-STARK construction, eliminating trusted setup requirements and providing post-quantum security. StarkWare Industries is founded to commercialize STARK technology for blockchain scaling.

2019: Ariel Gabizon, Zachary J. Williamson, and Oana Ciobotaru publish PLONK, introducing universal and updatable structured reference strings. PLONK’s custom gates and permutation arguments made it considerably more flexible than Groth16 for complex circuits, and it was rapidly adopted by projects including Aztec, zkSync, and Mina Protocol.

2020: Sean Bowe, Jack Grigg, and Daira Hopwood from the Electric Coin Company publish the Halo construction and subsequently Halo 2, achieving recursive proof composition without a trusted setup, a breakthrough that enabled proofs that verify other proofs, essential for incremental blockchain state verification.

2021: zkSync (Matter Labs) and StarkNet (StarkWare) launch as zk-rollup Layer 2 networks on Ethereum, using SNARKs and STARKs respectively to batch thousands of transactions into single proofs verified by Ethereum smart contracts. Competition among zk-rollup projects intensifies, positioning ZKPs as a leading scaling technology for Ethereum.

2022: Nova, by Kothapalli, Setty, and Tzialla, introduces folding schemes for efficient incremental verifiable computation, dramatically reducing the prover overhead for recursive proof systems. Polygon acquires the Hermez and Miden projects and announces Polygon zkEVM, a ZKP-based Ethereum Virtual Machine equivalent.

2023 to 2024: The zk-rollup ecosystem matures further. zkSync Era, StarkNet, Polygon zkEVM, Scroll, Linea, and Taiko all launch mainnet or public testnet zk-rollups. Proof generation becomes increasingly parallelized with GPU and FPGA acceleration. Proof aggregation and shared proving emerge as active research areas, with projects proposing shared ZKP verification layers.

2025 to 2026: Zero-Knowledge Proofs become further embedded in mainstream blockchain infrastructure. Ethereum’s research roadmap continues incorporating ZKP-based “Verkle proofs” and related techniques for state management, and cross-chain ZKP bridges continue development toward more trustless interoperability between chains, alongside Ethereum’s own late-2025 Fusaka upgrade, which brought a different but related cryptographic scaling technique, Data Availability Sampling, into production for the network’s blob data.

“Zero-knowledge proofs are one of the single most under-hyped technologies, both in the blockchain space and beyond. They are going to be absolutely foundational to the way we think about privacy and verification in the digital world.” Vitalik Buterin, Ethereum co-founder, EthCC Paris, 2022.

In Simple Terms

The password analogy: imagine you need to prove to a website that you know your password, but instead of typing it in (which could be intercepted), you solve a special mathematical puzzle that can only be solved if you know the password. The website checks your puzzle answer and confirms you know the password without ever seeing the password itself. That is what a Zero-Knowledge Proof does: it proves you know something without showing what you know.

The Sudoku solution: you have solved a difficult Sudoku puzzle and want to prove it without showing your solution. You cover each row, column, and 3×3 box with cards, then let the verifier randomly pick any row, column, or box to inspect. They see that it contains the numbers 1 through 9 with no repeats. After enough random checks, they are convinced the entire solution is correct, but they never saw enough of the solution to reconstruct it.

Important: While Zero-Knowledge Proofs provide powerful privacy and verification capabilities, they are complex cryptographic systems that require careful implementation. Bugs in ZKP circuits (the mathematical description of the computation being proven) can create soundness vulnerabilities where false proofs are accepted. The security of many ZKP systems depends on cryptographic assumptions, such as discrete logarithm hardness or pairing assumptions, that could in principle be broken by sufficiently advanced quantum computers. Users relying on ZKP-based privacy should understand that the privacy guarantee is only as strong as the underlying cryptographic implementation, and that advances in cryptanalysis or quantum computing could affect security over time.

Key Technical Features

The Mathematical Foundation: Polynomial Commitments and Arithmetic Circuits

At the heart of modern Zero-Knowledge Proof systems lies the representation of computations as polynomial equations over finite fields. Any computation, including the verification of a blockchain transaction, the execution of a smart contract, or the validation of an identity attribute, can be expressed as an arithmetic circuit: a directed acyclic graph of addition and multiplication gates operating on elements of a finite field (integers modulo a prime).

The prover’s task is to demonstrate that they possess an assignment of values (a “witness”) to the circuit’s wires such that all gates are satisfied, without revealing the witness.

The transformation from computation to polynomial equations proceeds through arithmetization. The prover encodes the circuit’s wire values as coefficients or evaluation points of polynomials, and the circuit’s constraints become polynomial identity checks. For example, a multiplication gate a times b equals c becomes a polynomial constraint that must hold at specific evaluation points.

If the prover can demonstrate that these polynomial identities hold, evaluated at random challenge points provided by the verifier or derived via the Fiat-Shamir heuristic, the verifier is convinced that the underlying computation was performed correctly.

Polynomial commitment schemes are the mechanism by which the prover “commits” to a polynomial without revealing it, and later “opens” the commitment at specific points to prove evaluations. The KZG (Kate-Zaverucha-Goldberg) commitment scheme, based on elliptic curve pairings, is among the most widely used: the prover computes a single elliptic curve point as the commitment, and verification requires only a couple of pairing operations regardless of the polynomial’s degree.

This succinctness is what makes zk-SNARKs so compact. Alternative commitment schemes include FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity), used in STARKs, which relies on hash functions rather than pairings and provides transparency and post-quantum security at the cost of larger proof sizes.

How a zk-SNARK Proof Works (Step by Step)

1. Circuit compilation: The computation to be proven, for example “this transaction is valid,” is expressed as an arithmetic circuit, a series of addition and multiplication gates over a finite field. Specialized domain-specific languages, such as Circom, Noir, Leo, or Cairo, compile high-level programs into these circuits
2. Witness generation: The prover computes the full circuit, assigning concrete values to every wire (input, intermediate, and output). The witness includes both public inputs, visible to the verifier, such as a transaction hash, and private inputs, secret, such as the sender’s balance or private key
3. Arithmetization: The circuit and witness are transformed into a set of polynomial equations through a specific arithmetization scheme. In R1CS (Rank-1 Constraint System, used by Groth16), each gate becomes a specific type of constraint involving the witness vector and selector vectors. In PLONKish arithmetization, gates are encoded through selector polynomials, permutation arguments, and lookup tables
4. Polynomial commitment: The prover encodes the witness and constraint satisfaction into polynomials and commits to them using a polynomial commitment scheme, KZG for SNARKs or FRI for STARKs. These commitments are compact cryptographic objects, such as elliptic curve points or Merkle roots, that bind the prover to specific polynomials without revealing them
5. Challenge generation: Random evaluation points are generated, either through interaction with the verifier (interactive mode) or through the Fiat-Shamir heuristic (non-interactive mode, where challenges are derived by hashing the proof transcript so far)
6. Proof construction: The prover evaluates committed polynomials at the challenge points and provides opening proofs demonstrating that the evaluations are consistent with the commitments. The proof also includes quotient polynomials that demonstrate the polynomial identities hold across all constraint points
7. Verification: The verifier checks the proof by verifying polynomial commitment openings and checking that the polynomial identities hold at the random challenge points. For Groth16, this requires a small, fixed number of elliptic curve pairings; for PLONK, a few more pairing checks; for STARKs, hash function evaluations and Merkle path verifications. Verification is generally orders of magnitude faster than re-executing the computation

Groth16: A Compact Proof Standard

Groth16, published by Jens Groth in 2016, remains one of the standards for proof compactness. A Groth16 proof consists of exactly three elliptic curve group elements, totaling roughly 128 to 192 bytes depending on the curve.

Verification requires a small, fixed number of pairing operations plus a few group multiplications, taking roughly 1 to 3 milliseconds on modern hardware. This extreme succinctness makes Groth16 well suited to on-chain verification, where gas costs are proportional to proof size and verification computation.

The trade-off is that Groth16 requires a circuit-specific trusted setup: each unique circuit needs its own structured reference string generated through a multi-party computation ceremony. If all participants in the ceremony collude or their randomness is compromised, the resulting “toxic waste” could in principle be used to forge proofs.

The Zcash Powers of Tau ceremony and subsequent Hermez ceremony each involved many participants to ensure that at least one honest participant would make forgery effectively impossible. Despite this mitigation, the trusted setup requirement has motivated the search for transparent alternatives.

PLONK: Universal and Updatable Setup

PLONK changed the ZKP landscape by introducing a universal structured reference string: a single trusted setup that works for any circuit up to a maximum size. This means that one ceremony, which can be continually strengthened by additional participants, serves an entire ecosystem of circuits, eliminating the need for per-circuit ceremonies.

PLONK’s arithmetization uses a system of gate equations with selector polynomials, a copy constraint mechanism (a grand product argument) to enforce wire connections, and the ability to define custom gates for frequently occurring patterns.

PLONK’s proof size is larger than Groth16’s, roughly 400 to 900 bytes depending on the variant, and verification is somewhat slower, though still fast in absolute terms. The universality and updatability of the setup, combined with the flexibility of custom gates and lookup tables, made it a preferred system for complex blockchain applications. Variants, including versions with custom gates, plookup-style lookup tables, and improved batching, have been deployed across zkSync, Aztec, Polygon zkEVM, and Scroll.

Halo 2: Recursive Proofs Without a Trusted Setup

Halo 2, developed by the Zcash/Electric Coin Company team, achieved something previously considered a fundamental barrier: efficient recursive proof composition without any trusted setup. Recursive proof composition means a proof can verify another proof as part of its circuit, enabling a chain of proofs where each proof attests to the correctness of the previous one, compressing an arbitrary amount of computation into a single final proof.

The technical innovation in Halo involves an accumulation scheme for polynomial commitments based on the inner product argument. Rather than verifying each commitment fully, which would require pairings and thus a trusted setup, Halo “accumulates” commitment checks, deferring expensive verification to the end of the recursive chain.

This deferred verification is what enables trustless recursion. Halo 2 extended this with PLONKish arithmetization and lookup arguments, making it a fully featured proving system. Zcash adopted Halo 2 for its Orchard shielded pool, eliminating the trusted setup requirement that had been a persistent criticism since Zcash’s launch.

Nova and Folding Schemes: Efficient Incremental Computation

Nova, introduced in 2022, represents a significant shift in how recursive proofs are constructed. Instead of proving each step of an incremental computation fully and then recursively verifying the proof, Nova uses a folding scheme to “fold” two instances of a computation into one, reducing the prover work at each step from a full proof generation to a single group scalar multiplication. The resulting Incrementally Verifiable Computation (IVC) system has prover costs that are dramatically lower than traditional recursive SNARKs for computations with many repeated steps, such as processing blockchain transactions sequentially.

zk-STARKs: Transparency and Post-Quantum Security

zk-STARKs achieve their transparency (no trusted setup) and post-quantum security by replacing elliptic curve pairings with hash functions and algebraic coding theory. The core commitment scheme in STARKs is FRI, which tests whether a function is close to a low-degree polynomial by repeatedly “folding” the function, reducing its domain by half through random linear combinations, and checking consistency via Merkle trees. Because FRI relies only on collision-resistant hash functions, which are believed to resist quantum attacks, STARKs inherit post-quantum security.

Zero-Knowledge Virtual Machines (zkVMs and zkEVMs)

The ultimate ambition of ZKP technology in blockchain is the zero-knowledge virtual machine: a general-purpose computation environment where any program execution can be proven in zero-knowledge. A zkEVM (zero-knowledge Ethereum Virtual Machine) proves the correct execution of Ethereum smart contracts, enabling zk-rollups that are fully EVM-compatible. Different approaches exist along a compatibility spectrum:

• Type 1 (fully Ethereum-equivalent): Proves the actual Ethereum execution environment, including state tries and gas accounting, an aspirational target for many projects. Maximum compatibility but the highest prover costs
• Type 2 (fully EVM-equivalent): Proves EVM bytecode execution but with modified state management, as with Scroll and Polygon zkEVM. Nearly full compatibility with minor differences
• Type 3 (almost EVM-equivalent): Proves most EVM opcodes but modifies or removes some that are ZKP-unfriendly, such as certain precompiles. Faster proving, with minor compatibility gaps
• Type 4 (high-level language equivalent): Proves execution of code compiled from Solidity or Vyper to a ZKP-friendly instruction set, rather than proving EVM bytecode directly, as with zkSync Era. Fast proving, but contracts must be recompiled and may behave slightly differently at the bytecode level

General-purpose zkVMs beyond Ethereum include RISC Zero (proving RISC-V instruction execution), SP1 (also RISC-V based), and Miden VM (a STARK-based VM with a custom instruction set optimized for ZKP efficiency). These systems enable programs written in Rust, C, Go, or other languages that compile to RISC-V to be executed with a cryptographic proof of correctness.

Advantages & Disadvantages

Aspect	Advantage	Disadvantage
Privacy Preservation	Enables private transactions and computations on public blockchains; users can transact, prove identity attributes, and interact with smart contracts without revealing sensitive data to observers or validators	Privacy features can be misused for money laundering, sanctions evasion, and illicit finance; the 2022 OFAC sanctioning of Tornado Cash illustrated the regulatory risks that can attach to ZKP-based privacy tools
Scalability	zk-rollups compress thousands of transactions into a single proof verified on Layer 1, with leading platforms processing thousands of transactions per second while inheriting Ethereum’s security guarantees	Proof generation is computationally intensive; generating a SNARK proof for a complex circuit can take from minutes to hours on consumer hardware, requiring specialized infrastructure such as GPU clusters or FPGA accelerators for production systems
Security Model	Mathematical (cryptographic) security rather than purely economic security; unlike optimistic rollups, which rely on fraud proofs and challenge periods, zk-rollups provide much faster finality backed by mathematical certainty	The cryptographic assumptions underlying SNARKs, such as the discrete logarithm problem and various pairing assumptions, could in principle be broken by sufficiently powerful quantum computers, potentially affecting proofs generated under those assumptions
Trusted Setup Elimination	Modern systems, including STARKs, Halo 2, and Nova, have eliminated trusted setup requirements entirely, removing the risk of compromised ceremony parameters and the logistical burden of running MPC ceremonies	Systems that still require trusted setups, such as Groth16, depend on the integrity of the ceremony; if all participants collude or their randomness is compromised, forged proofs become theoretically possible without detection
Verification Efficiency	On-chain verification is fast and comparatively cheap; a Groth16 proof typically costs on the order of 200,000 to 300,000 gas on Ethereum, regardless of how complex the proven computation was	Circuit development is difficult; writing correct ZKP circuits requires deep expertise in finite field arithmetic, constraint systems, and cryptographic engineering, and bugs in circuits can be subtle and severe
Composability	ZKP-based systems are generally composable with existing blockchain infrastructure; zk-rollups settle on existing Layer 1 chains, ZKP identity systems integrate with existing DeFi protocols, and ZKP bridges connect existing chains	The ZKP ecosystem remains fairly fragmented; different proving systems, arithmetizations, and zkVM types create interoperability challenges
Data Compression	Validity proofs allow state diffs, rather than full transaction data, to be posted on-chain, reducing Layer 1 data costs compared with optimistic rollups that must post full transaction calldata	Proof sizes vary considerably; STARK proofs, for example, can run from tens to hundreds of kilobytes, which, while smaller than the raw transaction data they replace, still represents non-trivial on-chain cost that scales with proof complexity
Cross-Chain Verification	ZKPs enable more trustless cross-chain bridges by proving the state of one chain to a verifier contract on another chain, reducing reliance on trusted bridge operators or multi-sig committees	Cross-chain ZKP verification requires light client circuits for each source chain, which are complex to build, maintain, and audit, since each chain’s consensus mechanism and state structure must be encoded as a ZKP circuit
Regulatory Compliance	ZKPs can enable “compliance by design,” letting users prove regulatory compliance, such as KYC status or non-sanctioned jurisdiction, without revealing personal data, satisfying both privacy and regulatory goals	Regulatory uncertainty around ZKP privacy tools persists; the Tornado Cash precedent created a chilling effect, and regulators in multiple jurisdictions continue developing frameworks that could restrict or require additional disclosure in privacy-preserving systems

Risk Management

Circuit Soundness and Audit Requirements: The most critical risk in ZKP systems is circuit soundness, the possibility that a bug in the arithmetic circuit allows a prover to generate a valid-looking proof for a false statement. Unlike smart contract bugs, where the code is publicly readable in a familiar form, ZKP circuit bugs can be extraordinarily subtle because they often involve constraint under-specification: a circuit might fail to constrain a wire value, allowing the prover to insert arbitrary values that satisfy the proof but correspond to invalid transactions. Researchers, including teams focused on Ethereum’s privacy and scaling roadmap, have documented multiple classes of circuit vulnerabilities, including missing constraints, incorrect range checks, and arithmetic overflow in finite field operations. Users should only interact with ZKP systems whose circuits have been audited by specialized ZKP auditing firms and, ideally, have undergone formal verification.

Trusted Setup Risks and Mitigation: For systems using trusted setups, such as Groth16 or the original PLONK, the integrity of the setup ceremony is a single point of failure. If the “toxic waste,” the secret randomness used during the ceremony, is reconstructable, an attacker could in principle forge proofs, creating tokens from nothing, spending funds they do not own, or generating false identity proofs. Mitigation strategies include multi-party computation ceremonies with many participants (where only one honest participant is needed for security), perpetual “powers of tau” ceremonies that continually strengthen the setup, and migration to transparent systems, such as STARKs or Halo 2, that eliminate the setup entirely. Users should verify that any trusted-setup-based system they interact with conducted a sufficiently large and well-documented ceremony.

Implementation Vulnerabilities: Even if the mathematical proof system is sound, implementation bugs in the prover, verifier, or surrounding infrastructure can create exploitable vulnerabilities. Notable incidents include a documented Zcash inflation bug, where a flaw in circuit verification could have allowed undetectable token creation had it been discovered by a malicious party first, and various bugs discovered in circuit implementations through bug bounty programs over the years. The complexity of ZKP implementations, involving finite field arithmetic, elliptic curve operations, polynomial evaluation, and hash functions, creates a large attack surface. Defense strategies include formal verification of critical circuits, extensive fuzzing and property-based testing, multiple independent implementations for consensus-critical verification, and conservative deployment with gradual rollout.

Quantum Computing Threats: Pairing-based SNARKs, including Groth16 and PLONK with KZG commitments, rely on the hardness of the discrete logarithm problem on elliptic curves, which would be efficiently solvable by Shor’s algorithm on a sufficiently large quantum computer. While current quantum computers remain far from the scale needed for this, commonly cited estimates suggest thousands of logical qubits would be required for breaking 256-bit elliptic curves, translating into a much larger number of physical qubits at today’s error rates, the long-term risk is taken seriously by the field. STARKs and hash-based commitment schemes are considered quantum-resistant, and the ongoing shift toward STARK-based and lattice-based proof systems provides a migration path. Users holding assets protected by pairing-based ZKPs should keep an eye on quantum computing progress and be prepared to migrate to post-quantum alternatives if and when that becomes necessary.

Privacy Limitations and Metadata Leakage: ZKPs protect the content of computations but do not inherently protect metadata. On-chain ZKP verification reveals that a proof was submitted, including the timing, the smart contract interacted with, the gas paid, and the transaction’s position in a block. For privacy-focused applications, such as shielded transactions or identity proofs, this metadata can leak significant information. Anonymity set size is crucial: if only a small number of users use a shielded pool, transaction graph analysis can potentially deanonymize users despite the underlying cryptographic privacy. Users should consider using ZKP privacy tools with large anonymity sets, timing obfuscation, and metadata-minimizing relay networks.

Cultural Relevance

Zero-Knowledge Proofs have transcended their origins as a purely theoretical construct in complexity theory to become one of the more culturally significant technologies in the blockchain ecosystem. The term “ZK” has entered the common lexicon of cryptocurrency discourse: “ZK-rollup,” “ZK-proof,” “ZK-EVM,” and “ZK-bridge” are everyday vocabulary in Ethereum developer communities, and “ZK” has become a branding prefix signaling technological sophistication and cryptographic rigor. The 2021 to 2024 period saw a “ZK gold rush,” where numerous projects added “ZK” to their names, leading to community debates about “ZK-washing,” the practice of claiming ZK properties without actually implementing zero-knowledge proofs.

The cultural significance of ZKPs in crypto extends beyond technology into philosophy. The cypherpunk movement, articulated in Eric Hughes’ 1993 manifesto arguing that privacy is necessary for an open society in the electronic age, finds one of its most powerful technical embodiments in Zero-Knowledge Proofs. ZKPs realize much of the cypherpunk aspiration for provable privacy: the ability to participate fully in digital systems without surrendering informational autonomy. This philosophical alignment has made ZKP researchers and developers influential figures within the crypto community, including people like Eli Ben-Sasson (StarkWare), Vitalik Buterin (who has extensively championed ZKPs), Barry Whitehat (associated with the Semaphore protocol and Privacy and Scaling Explorations), and members of the Zcash team such as Zooko Wilcox, Sean Bowe, and Daira Hopwood.

A “ZK winter to ZK summer” narrative, in which years of largely theoretical research from roughly 2016 to 2020 were followed by an explosion of practical deployment from 2021 onward, has become something of a template for how the crypto community understands technology maturation. The view that “ZKPs will help solve Ethereum’s scaling problem” became one of the stronger consensus positions in the Ethereum community, with Vitalik Buterin arguing that zk-rollups would likely win out over optimistic rollups in the long run. This conviction has driven substantial venture funding to ZKP projects, attracted cryptography researchers from academia into crypto startups, and established ZKP expertise as one of the more valuable specializations in blockchain engineering.

Within the academic cryptography community, the blockchain industry’s demand for practical ZKP systems has created a notable feedback loop: industry funding supports academic research, which produces new proof systems, which are rapidly productized by startups, which generate revenue that funds further research. Conferences and workshops focused specifically on ZK research have become important venues where academic cryptographers and blockchain engineers collaborate, and the pace of innovation, from Groth16 to PLONK to Halo 2 to Nova within about seven years, reflects the intensity of this collaboration.

The Tornado Cash sanctions of August 2022, when the U.S. Treasury’s Office of Foreign Assets Control added the Tornado Cash smart contracts to its sanctions list, became a defining cultural moment for the ZKP community. The sanctions effectively criminalized interaction with an open-source privacy tool, sparking debate about the legitimacy of on-chain privacy, the classification of code as speech, and the tension between financial surveillance and individual privacy rights. The subsequent prosecution of a Tornado Cash developer in the Netherlands intensified these debates and galvanized parts of the ZKP community around the principle that privacy is not inherently criminal. The incident has shaped the design philosophy of subsequent ZKP privacy projects, which increasingly incorporate selective compliance mechanisms, such as proving non-sanctioned-list membership, alongside transaction privacy.

Real-World Examples

Zcash Shielded Transactions: Pioneering Private Cryptocurrency

Scenario: Bitcoin and other early cryptocurrencies operate on fully transparent ledgers where all transaction amounts, sender addresses, and recipient addresses are publicly visible. Financial privacy advocates and institutional users needed a cryptocurrency where transactions could be cryptographically verified as valid without revealing any transaction details to the public.

Implementation: Zcash deployed zk-SNARKs, initially using the Sprout circuit, later upgrading to Sapling with Groth16, and most recently Orchard with Halo 2, to enable “shielded” transactions. In a shielded transaction, the sender, recipient, and amount are all encrypted on-chain. A zk-SNARK proof attached to the transaction proves that the sender possesses the private key for the input notes, the input notes exist in the commitment tree and have not been spent, the sum of inputs equals the sum of outputs plus the fee, and no double-spending has occurred, all without revealing any of these values. The Sapling upgrade substantially reduced proof generation time compared to Sprout, and Halo 2 (Orchard) eliminated the trusted setup requirement entirely.

Outcome: Zcash demonstrated the production viability of ZKPs for cryptocurrency privacy, processing a large number of shielded transactions since its 2016 launch. The Zcash ceremonies became widely referenced models for trusted setup best practices. While shielded adoption has historically remained a fraction of total Zcash transactions, due to computational overhead and exchange preferences for transparent addresses, the protocol proved that cryptographic privacy at scale was technically achievable and set a template for many subsequent ZKP privacy implementations in blockchain.

zkSync Era: Scaling Ethereum with Zero-Knowledge Rollups

Scenario: Ethereum’s Layer 1 throughput and gas costs during periods of high demand made the network impractical for many everyday uses, including micropayments, gaming transactions, and high-frequency DeFi interactions. The blockchain trilemma, the tension between scalability, security, and decentralization, called for a solution that could increase throughput without sacrificing Ethereum’s security guarantees.

Implementation: zkSync Era, developed by Matter Labs, launched a Type 4 zkEVM rollup that compiles Solidity and Vyper smart contracts to a custom ZKP-friendly instruction set and generates SNARK proofs attesting to the correct execution of batches of transactions. Thousands of transactions are executed off-chain, a state diff is computed, and a SNARK proof of correct execution is posted to an Ethereum smart contract, which verifies the proof and applies the state diff, inheriting Ethereum’s security for the entire batch.

Outcome: zkSync Era processed a very large number of transactions in its early years of mainnet operation, at throughput and cost levels far better than Ethereum L1 alone. The system demonstrated that ZKP-based scaling could support complex DeFi and NFT applications while maintaining Ethereum-level security. The launch helped catalyze competition among zk-rollup projects and established ZKPs as a primary technology in Ethereum’s long-term scaling roadmap.

Worldcoin: Biometric Proof of Personhood

Scenario: Sybil attacks, the creation of multiple fake identities, undermine democratic governance mechanisms, fair token distributions, and universal basic income proposals in the Web3 ecosystem. Traditional identity verification requires revealing personal information, while pseudonymous blockchain addresses allow largely unlimited identity creation. A solution was needed that could prove unique personhood without compromising identity privacy.

Implementation: Worldcoin developed the World ID system, which uses iris scanning, via a custom hardware device called the Orb, to create a unique biometric identifier for each person, then generates a Zero-Knowledge Proof, using the Semaphore protocol based on Groth16, that proves “this person is a unique registered human” without revealing which specific iris scan they registered with. The ZKP is designed to ensure that the same person cannot register twice, preventing Sybil attacks, while ensuring that no verifier can link a proof back to a specific biometric template.

Outcome: Worldcoin enrolled millions of verified unique humans in the years following its launch, creating one of the larger ZKP-based identity systems in the world. The project demonstrated that ZKPs could bridge biometric identity and blockchain privacy, though it also sparked significant debate about biometric data collection, consent in developing nations, and the centralization risks of hardware-dependent identity systems. Several governance and airdrop protocols integrated World ID verification, establishing proof of personhood as a notable use case for ZKPs beyond financial privacy.

Polygon zkEVM: Type 2 EVM Equivalence with Zero-Knowledge Proofs

Scenario: Ethereum developers needed a scaling solution that was fully compatible with existing Ethereum smart contracts, allowing deployment of the same Solidity bytecode without recompilation or modification, while providing the security guarantees of validity proofs rather than the delayed finality of optimistic rollups. Achieving byte-level EVM equivalence with ZKP verification was considered one of the harder technical challenges in blockchain engineering.

Implementation: Polygon zkEVM built a Type 2 zkEVM that proves the correct execution of actual EVM bytecode using a custom proof system combining SNARK and STARK elements. The system uses a multi-polynomial commitment approach where different aspects of EVM execution are proven by separate specialized circuits, and a recursive aggregation proof combines them into a single on-chain verification.

Outcome: Polygon zkEVM launched on Ethereum mainnet in March 2023, becoming one of the first production Type 2 zkEVMs. The system demonstrated that near-perfect EVM equivalence was achievable with ZKP proving, with the large majority of Ethereum smart contracts deployable without modification. Several DeFi protocols deployed on Polygon zkEVM, and proof generation time improved substantially through successive protocol upgrades, validating the Type 2 zkEVM approach and influencing the design of competing implementations.

Comparison Table

Feature	zk-SNARKs (Groth16/PLONK)	zk-STARKs	Optimistic Rollups	Trusted Execution Environments (TEEs)
Proof Size	Very small: Groth16 roughly 128 to 192 bytes, PLONK roughly 400 to 900 bytes; minimal on-chain footprint	Large: commonly tens to a couple hundred kilobytes per proof; still much smaller than the raw transaction data it replaces	No validity proof required; full transaction data posted on-chain as calldata	No cryptographic proof; attestation quotes from hardware provide comparatively weaker guarantees
Verification Time	Extremely fast, typically single-digit milliseconds; roughly constant regardless of computation size	Moderate, and scales with computation size due to FRI verification, though still generally fast	No immediate verification; a multi-day challenge period applies for fraud proofs, delaying withdrawals	Minimal verification of hardware attestation; no mathematical proof of correct execution
Trusted Setup	Groth16 requires a circuit-specific ceremony; PLONK uses a universal, updatable setup; both carry some risk of toxic waste compromise	None required (transparent); relies only on hash functions and public randomness	None required; security is based on economic incentives via the fraud proof game	Trusts the hardware manufacturer; carries supply chain and side-channel attack risks
Quantum Resistance	No; pairing-based schemes could be broken by Shor’s algorithm, requiring migration to post-quantum alternatives	Yes; hash-based commitments resist known quantum attacks	Not directly applicable; depends on the underlying chain’s own quantum resistance	No; hardware security modules could be compromised by quantum-enabled side-channel attacks
Prover Cost	High; requires FFTs and multi-scalar multiplications over elliptic curves	Very high for small computations, but scales more efficiently for very large circuits	Low; no proof generation required, since the sequencer only executes and batches transactions	Low; computation runs in a hardware enclave at near-native performance, with no cryptographic proof generation
Privacy Capability	Full zero-knowledge; proofs reveal nothing about the witness	Full zero-knowledge when configured as ZK-STARKs; similar privacy capabilities to SNARKs	No inherent privacy; all transaction data is posted publicly as calldata on Layer 1	Partial; data is encrypted during computation, but trust is placed in the hardware manufacturer rather than mathematics
Finality	Immediate once the proof is verified on-chain	Immediate, similar to SNARKs, since on-chain proof verification provides instant mathematical finality	Delayed, typically around a week, before withdrawals are finalized, though bridges can offer faster exits with added liquidity risk	Immediate but weaker; attestation is verified instantly, but security depends on hardware assumptions rather than cryptographic proofs

Related Terms

• zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge): A family of proof systems producing extremely compact proofs with fast verification, used in Zcash, Tornado Cash, and most zk-rollups; characterized by succinctness but historically requiring trusted setups
• zk-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge): A proof system family using hash-based commitments (FRI) to achieve transparency and post-quantum security at the cost of larger proof sizes; developed by Eli Ben-Sasson and deployed by StarkWare
• zk-Rollup: A Layer 2 scaling solution that executes transactions off-chain and posts validity proofs (SNARKs or STARKs) to Layer 1, inheriting the base layer’s security while achieving much higher throughput and lower costs
• Arithmetic Circuit: The mathematical representation of a computation as a directed acyclic graph of addition and multiplication gates over a finite field; the fundamental structure that ZKP systems prove statements about
• Trusted Setup: A one-time cryptographic ceremony that generates public parameters needed by certain SNARK systems; compromise of the ceremony’s secret randomness enables proof forgery
• Polynomial Commitment Scheme: A cryptographic primitive allowing a prover to commit to a polynomial and later prove evaluations at specific points; KZG (pairing-based) and FRI (hash-based) are two of the dominant schemes underlying modern ZKPs
• Fiat-Shamir Heuristic: A technique for converting interactive proof protocols into non-interactive ones by replacing the verifier’s random challenges with hash function outputs, enabling ZKPs to be verified without real-time interaction
• Recursive Proof Composition: The technique of creating a proof that verifies another proof within its circuit, enabling chains of proofs that compress arbitrary amounts of computation; achieved without a trusted setup by Halo 2, and with minimal cost by Nova’s folding schemes
• R1CS (Rank-1 Constraint System): An arithmetization format that represents circuit constraints as rank-1 quadratic equations over vectors; used by Groth16, Marlin, and Nova
• PLONKish Arithmetization: The constraint system format used by PLONK and its variants, featuring selector polynomials, custom gates, permutation arguments, and lookup tables for flexible circuit design
• Cairo (Programming Language): A programming language designed for writing provable programs, used by StarkNet to compile smart contracts into a representation that can be proven with STARKs
• Circom: A domain-specific language for defining arithmetic circuits, widely used in the Ethereum ZKP ecosystem for writing circuits that compile to R1CS constraints for Groth16 and PLONK provers

FAQ

Q: What is the difference between a zk-SNARK and a zk-STARK? The two main differences are the trusted setup and the underlying cryptographic assumptions. zk-SNARKs, specifically pairing-based ones like Groth16 and PLONK with KZG, require a trusted setup ceremony and rely on elliptic curve assumptions that are vulnerable to quantum computers. They produce very small proofs with fast verification. zk-STARKs require no trusted setup and rely on hash functions believed to be quantum-resistant. They produce larger proofs with slower, though still fast, verification. In practice, the choice between SNARKs and STARKs involves trade-offs between proof size (on-chain cost), prover performance, quantum resistance, and trust assumptions. Many modern systems use hybrid approaches, for example generating a STARK proof and then wrapping it in a SNARK for cheaper on-chain verification.

Q: How do Zero-Knowledge Proofs enable blockchain scaling? ZKPs enable scaling through zk-rollups. A rollup operator executes thousands of transactions off-chain, computes the resulting state changes, and generates a ZKP proving that all transactions were executed correctly. This single proof is posted to the Layer 1 blockchain along with the state diff. The Layer 1 smart contract verifies the proof, which takes roughly the same amount of computation regardless of how many transactions were in the batch, and applies the state changes. This means Layer 1 only needs to verify one proof instead of re-executing thousands of transactions, achieving a large throughput improvement while inheriting the base layer’s security guarantees.

Q: What is a trusted setup, and why is it controversial? A trusted setup is a one-time ceremony that generates the cryptographic parameters, called a structured reference string, needed by certain SNARK proof systems. During the ceremony, random secret values, sometimes called “toxic waste,” are used to compute the parameters. If anyone can reconstruct these secret values, they could in principle forge proofs, creating fake transactions, minting tokens from nothing, or generating false identity proofs, all of which would be accepted as valid by the verifier. The concern stems from the fact that security relies on the irretrievable destruction of these secrets. Multi-party computation ceremonies mitigate this by having many participants contribute randomness, since only one honest participant is needed to ensure security. However, the trusted setup remains a philosophical concern for systems aspiring to full trustlessness, which is why newer systems like STARKs and Halo 2 eliminate it entirely.

Q: Can Zero-Knowledge Proofs be used for identity verification without revealing personal data? Yes, this is one of the more powerful applications. Using ZKP-based identity systems, you can prove specific attributes about yourself without revealing the underlying data. For example, you can prove you are over 18 without revealing your birthdate, prove you have completed KYC without revealing your name or passport number, prove you are not on a sanctions list without revealing your identity, or prove you are an accredited investor without revealing your net worth. The DeFi protocol or service receives a cryptographic proof that the claim is true and can verify it on-chain, but never learns the underlying personal data. This can enable regulatory compliance and privacy at the same time.

Q: What is recursive proof composition and why does it matter? Recursive proof composition is the ability for a ZKP to verify another ZKP within its circuit, essentially a proof that checks another proof. This creates a chain where each proof attests to the correctness of all previous proofs, compressing an arbitrary amount of computation into a single, constant-size final proof. For blockchains, this is significant: instead of verifying a new proof for each batch of transactions, a recursive system can generate a proof that says the previous proof was valid and the new batch of transactions is also correct, accumulating a chain’s history into one proof. Some protocols use this approach to maintain a roughly constant-size blockchain regardless of chain length. Nova’s folding schemes make this recursion dramatically cheaper by “folding” computation instances rather than generating full proofs at each step.

Q: How much does it cost to verify a Zero-Knowledge Proof on Ethereum? On-chain verification costs vary by proof system. A Groth16 proof verification commonly costs on the order of a few hundred thousand gas on Ethereum. PLONK verification tends to cost somewhat more. STARK verification is generally more expensive due to the larger proof size, which is why many STARK-based systems wrap their proofs in a final SNARK for cheaper on-chain verification. In a zk-rollup context, this verification cost is amortized across all transactions in the batch, so the effective per-transaction verification cost can be very small when batches contain thousands of transactions. Ethereum’s EIP-4844 blob transactions, and the subsequent Fusaka-era blob capacity increases, have further reduced the cost of posting the state diffs that accompany these proofs.

Q: Are Zero-Knowledge Proofs truly “zero knowledge” in practice? The mathematical zero-knowledge property guarantees that the proof reveals nothing about the secret witness beyond the truth of the proven statement. However, in practice, several factors can leak information. The fact that a proof was submitted is itself public metadata; an observer knows that someone made a transaction at a specific time. Anonymity set size matters, since if only a small number of people use a shielded pool, transaction graph analysis can narrow down participants. Side-channel attacks on proof generation, such as timing or power consumption analysis, can leak information about the witness. The public inputs to the proof, which are visible by design, may reveal more than intended if the circuit is not carefully designed. For maximum privacy, ZKP-based systems should be combined with large anonymity sets, timing obfuscation, and careful circuit design that minimizes public inputs.

Sources

• Goldwasser, S., Micali, S., and Rackoff, C., “The Knowledge Complexity of Interactive Proof-Systems”
• Groth, J., “On the Size of Pairing-Based Non-Interactive Arguments” (Groth16)
• Gabizon, A., Williamson, Z., and Ciobotaru, O., “PLONK,”
• Ben-Sasson, E., Bentov, I., Horesh, Y., and Riabzev, M., “Scalable, Transparent, and Post-Quantum Secure Computational Integrity” (STARKs)
• Bowe, S., Grigg, J., and Hopwood, D., “Recursive Proof Composition without a Trusted Setup” (Halo)
• Kothapalli, A., Setty, S., and Tzialla, I., “Nova: Recursive Zero-Knowledge Arguments from Folding Schemes,”
• Ethereum Foundation, “Zero-Knowledge Proofs,” ethereum.org
• Buterin, V., “An Incomplete Guide to Rollups,” vitalik.eth.limo