Zero-Knowledge Proofs
- Chapter 15: Zero-Knowledge Proofs
Chapter 15: Zero-Knowledge Proofs
“In cryptography, a zero-knowledge proof is a method by which one party can prove to another party that a given statement is true, without conveying any information apart from the fact that the statement is indeed true.”
Shafi Goldwasser, Silvio Micali, and Charles Rackoff, “The Knowledge Complexity of Interactive Proof Systems” (1985)^1^
Introduction
Zero-knowledge proofs let one party prove that a statement is true without revealing any information beyond the truth of the statement itself. For privacy, this changes what verification requires. Traditional verification demands disclosure. Zero-knowledge verification avoids that demand.
This chapter examines how zero-knowledge proofs work and what they enable, along with their limitations. The technology remains complex, but its privacy implications are simple: verification without routine surveillance can become possible.
For a first pass, three comparison points are enough: proof size, trusted setup, and the practical cost of proving and verification. The later taxonomy separates constructions by how they answer those three questions.
15.1 The Verification Dilemma
Traditional Verification Requires Disclosure
Consider common verification scenarios. Identity checks expose identifying documents, so the verifier sees name, address, photo, document numbers, and more data than the verification requires. Age checks for alcohol purchases expose the exact birthdate and name when the merchant needs only confirmation of being over 21. Professional qualification checks expose issuing institution, dates, grades, and other credentials on the same document. Creditworthiness checks reveal income sources, spending patterns, account balances, and transaction history.
In each case, verification reveals more information than logically necessary for the verification’s purpose.
The Privacy Cost
This over-disclosure has costs. Each verification adds to databases, and over time, entities accumulate complete profiles from individually minor disclosures. More data creates more targets; data breaches expose information that privacy-preserving verification would never have collected. Disclosed data enables inferences, and knowing someone’s birthdate and zip code often suffices to uniquely identify them. Verifiers accumulate information while individuals cannot audit how it is used, creating systematic power imbalance.
The Fundamental Dilemma
Verification requires information, but providing information destroys privacy. Traditional systems force a choice between participating in verification-requiring activities or maintaining privacy.
Zero-knowledge proofs resolve this dilemma by separating what is proven from what is revealed.
15.2 The ZK Concept: Proving Without Revealing
Interactive Proofs
The original zero-knowledge concept involves interactive protocols.^1^ A prover wants to convince a verifier of a statement without revealing underlying information. They engage in a protocol where the verifier poses challenges and the prover responds.
The tunnel analogy illustrates the concept. Picture a horseshoe-shaped tunnel with both ends opening onto the same clearing. Deep inside, where the two paths meet, sits a number-locked door. Alice claims she knows the combination. Bob stands in the clearing where he can see both tunnel exits but cannot see inside. Alice enters while Bob looks away. Bob then calls out “come out the left exit” or “come out the right exit.” If Alice knows the combination, she can always comply, unlocking the door if necessary. If she does not, she is trapped on whichever side she entered and has only a 50% chance of guessing correctly. After twenty successful rounds, Bob is certain Alice knows the combination, yet he never learned what it is.
In that exchange, Bob learns only that Alice knows the secret and not the secret itself.
Non-Interactive Proofs
Modern applications typically use non-interactive zero-knowledge proofs (NIZKs). Instead of a back-and-forth protocol, the prover generates a single proof that anyone can verify.
Non-interactivity enables practical applications: proofs can be attached to transactions or stored on blockchains, and they can be verified by multiple parties without prover involvement.
Formal Properties
Zero-knowledge proof systems have three properties.^2^ Completeness means that if the statement is true, an honest prover can convince an honest verifier. Soundness means that if the statement is false, no cheating prover can convince an honest verifier except with negligible probability. Zero-knowledge means the verifier learns nothing beyond the truth of the statement; even after seeing the proof, the verifier cannot extract additional information. Soundness and zero-knowledge are in tension: strong soundness requires the proof to “contain” something about the statement; zero-knowledge requires the proof to reveal nothing. Cryptographic constructions achieve both properties through mathematical techniques that seem almost magical.
15.3 Types: SNARKs, STARKs, Bulletproofs
Different zero-knowledge proof systems make different tradeoffs. The main constructions in current use are:
SNARKs
Succinct Non-interactive Arguments of Knowledge (SNARKs) are proof systems whose proof size and verification cost grow sublinearly, typically polylogarithmically, in the size of the computation being proved.^3^ A SNARK can certify a computation of millions of steps with a proof of a few hundred bytes that verifies in milliseconds. This succinctness property is what makes blockchain rollups and shielded transactions possible: a single constant-size proof can stand in for an arbitrarily complex computation, so the verifier’s work stays tiny no matter how large the proven computation gets. Practical Groth16 SNARKs produce proofs around 200 bytes; more recent constructions trade proof size for other properties including transparency and post-quantum security.
Traditional SNARKs require a “trusted setup”: generating initial parameters through a ceremony that, if compromised, would allow fake proofs. Transparent SNARKs now exist that eliminate this requirement. Systems like Spartan^18^ and Plonky2^19^ achieve SNARK-like properties without trusted setup, using different cryptographic techniques. The tradeoff is typically somewhat larger proofs or slower proving times compared to trusted-setup SNARKs.
Most widely deployed SNARK systems rely on cryptographic assumptions vulnerable to quantum computing attacks. Zcash uses SNARKs for shielded transactions.^4^
STARKs
Scalable Transparent Arguments of Knowledge (STARKs) eliminate the trusted setup requirement.^5^ STARKs offer transparency (no trusted setup), rely on minimal cryptographic assumptions (hash functions), are generally regarded as post-quantum, and scale well to large computations. The tradeoff: they produce larger proofs (tens to hundreds of kilobytes) and involve more complex verification.
StarkWare uses STARKs for Ethereum scaling solutions.
Bulletproofs
Bulletproofs are designed for range proofs and similar applications.^6^ They require no trusted setup and produce moderate proof sizes, making them efficient for range proofs (proving a value is in a range without revealing it). Verification is slower than SNARKs, and their use is narrower than that of SNARKs or STARKs.
Monero uses Bulletproofs, and now Bulletproofs+, primarily for range proofs inside confidential transactions.
Choosing Among Constructions
The constructions differ across several dimensions. Traditional SNARKs produce tiny proofs (around 300 bytes) with fast verification but require a trusted setup and are not quantum-safe; transparent SNARKs eliminate the trusted setup at some cost to proof size or proving time. STARKs avoid the trusted setup and are generally regarded as post-quantum but generate much larger proofs (around 100 kilobytes) with moderate verification speed. Bulletproofs occupy a middle ground with medium-sized proofs (around 2 kilobytes) and no trusted setup, though verification is slower and they lack quantum resistance.
The right choice depends on application requirements. Blockchain base layers typically favor small proofs such as SNARKs, applications requiring post-quantum security lean toward STARKs, and confidential-transaction range proofs often use Bulletproofs.
15.4 Applications: Zcash, Rollups, Identity
Private Cryptocurrency: Zcash
Zcash implements shielded transactions using SNARKs.^7^ Users can transact with both counterparties hidden and the amount concealed. The blockchain records that a valid transaction occurred without revealing its details.
The proof shows that input coins exist and are unspent, that the sender possesses the spending keys, and that input and output values balance without double-spending. It does this without revealing which coins are spent or who receives funds, and without exposing the amount transferred.
Zcash shows zero-knowledge proofs deployed at scale in adversarial conditions. Shielded adoption remains partial, and transparent or selectively transparent usage still limits privacy in practice.^4^ Many exchanges require transparent addresses for deposits and withdrawals, undermining the privacy benefits. The shielding technology works, but network effects and regulatory pressure limit its use.
Zcash also shows the risks of complex cryptography and the need for ongoing maintenance. In 2019, a vulnerability was discovered in the original Sprout proving system that could have allowed undetectable inflation. The bug existed since launch; no exploitation was detected, and the Sapling upgrade (deployed in 2018) had already fixed it before the vulnerability was publicly disclosed. The Zcash team’s practice of deploying cryptographic upgrades allowed the fix to precede public knowledge of the bug. The discovery showed that even carefully designed systems can harbor critical bugs, making active protocol development essential. Zcash continues to undergo upgrades; the protocol is actively maintained and improved.
Blockchain Scalability: Validity Rollups
Zero-knowledge proofs enable “rollups” that scale blockchain throughput.^8^ A rollup executes many transactions off-chain, then posts a proof to the main chain that all executions were valid.
The main chain verifies only the proof, not the individual transactions. This compresses many transactions into one proof while letting the main chain validate correctness and preserve data availability so transaction data can still be reconstructed.
Systems such as StarkNet and zkSync use this approach for Ethereum scaling.
Identity and Credentials
Zero-knowledge proofs enable privacy-preserving identity verification. The core insight is that most verification situations require proving a property, not revealing the underlying data: a bar needs to know you are over 21, not your exact birthdate, and a lender needs to know you can repay, not your complete financial history. A service needs to know you are a licensed professional, not your home address.
Traditional verification bundles necessary proof with unnecessary disclosure. Showing a driver’s license to prove age reveals name, address, birthdate, driver’s license number, and photo. Each of these data points creates risk: identity theft, targeted harassment, and database breach exposure. The verification accomplished its purpose; the disclosure exceeded its purpose.
Zero-knowledge credentials invert this relationship. Age verification allows proving that age exceeds a threshold without revealing birthdate; the proof shows “birthdate < (today - 21 years)” without exposing the birthdate itself. In a well-designed system, the verifier learns what they need (legal age confirmed) and not the surrounding personal data. Credential verification allows proving possession of a valid credential (degree, license, membership) without revealing identifying details; the verifier learns the credential is valid without learning who holds it. An employer can verify professional licensure without learning the candidate’s home address or when they obtained the license. Selective disclosure allows proving only specific properties from a rich credential containing many attributes; from a driver’s license, one can prove only “state of residence” without revealing personal identifying details.
Several projects are implementing these concepts. Polygon ID (now Privado ID) enables issuance and verification of credentials where holders can generate zero-knowledge proofs showing credential properties.^9^ A credential holder can prove group membership or age qualification, and can also show possession of a valid license, without revealing the credential itself or their identity. The system separates the credential, which contains rich data, from the proof, which reveals only what the verifier needs.
zkPass takes a different approach, enabling zero-knowledge proofs from existing Web2 documents.^10^ Users can prove properties from driver’s licenses and utility bills, as well as financial records, without uploading those documents to a third party. The proof generation happens on the user’s device; the verifier receives only the proof, not the underlying document. This bridges the gap between existing identity infrastructure and zero-knowledge verification.
Current know-your-customer (KYC) requirements force users to surrender full identity documents to every service requiring verification. Each disclosure creates a database that can be breached or subpoenaed, then misused. Zero-knowledge KYC (ZK-KYC) offers an alternative: prove compliance without repeated downstream disclosure. A user could prove “identity verified by licensed institution” without revealing the identity itself to downstream services. The compliance requirement is met downstream without recreating full identity databases at each service.
This remains largely speculative as deployed regulation. Regulators accustomed to full disclosure may resist verification methods they cannot inspect. But the technical capability exists to satisfy regulatory purposes while minimizing privacy invasion. Whether regulators will accept ZK-KYC depends on policy choices, not technical limitations.
The privacy implications extend beyond individual transactions. Identity verification currently creates complete profiles as a side effect. Each age check and credential presentation, along with address verification, adds to dossiers that follow individuals across contexts. Zero-knowledge verification sharply limits this accumulation. Each proof reveals only what that specific verification requires, leaving far less data to aggregate across contexts.
Not all projects in this space equally prioritize privacy. Worldcoin, now World,^11^ uses zero-knowledge proofs to verify “unique human” status while still depending on biometric enrollment. Current project materials say the biometric pipeline is designed to avoid a centralized biometric database, but the system still depends on trust in the surrounding hardware, operators, and enrollment design. The technology enables privacy; whether implementations provide privacy depends on the full system design.
ZK over Government-Issued Documents
The largest deployment of zero-knowledge identity attestation in 2025 runs on existing government-issued travel documents. The ICAO 9303 biometric passport standard places a signed NFC chip in roughly 1.8 billion passports worldwide. The chip contains the holder’s name, date of birth, nationality, and document number, each signed by the issuing country’s certificate authority. The signature is ordinarily verified by border-control equipment. A zero-knowledge circuit over the same signature lets a mobile device prove specific attributes from the chip without revealing the chip’s full contents or the holder’s identity.
Self (self.xyz, formerly Proof of Passport) is the flagship production deployment, using on-device NFC scanning with a ZK circuit over the Document Security Object to produce proofs of age, nationality, or sanctions-list non-membership; the project reports over one hundred million verifications across its deployments, including integrations with Google and with blockchain-based applications that accept the attestation as a sybil-resistance primitive. Comparable constructions run on the Aztec L2 (zkPassport), on Russia’s anti-Putin referendum infrastructure (Rarimo’s Freedom Tool), and against India’s Aadhaar records (Anon Aadhaar).^12^
The approach uses the state’s existing identity infrastructure against its surveillance uses. The government signed the document to authenticate the holder at border control; the ZK circuit over the signature uses the authentication without the identification, which is exactly the separation this chapter has been arguing zero-knowledge makes available. The countermove available to the state is to restructure document issuance: change signature schemes, shorten certificate lifetimes, or add attestation requirements the circuit cannot satisfy without revealing more than it currently does. The approach works today because hundreds of millions of existing documents are already in circulation with signatures the circuits can verify, and that installed base cannot be recalled quickly.
Privacy Pass and Anonymous Credentials at Scale
Privacy Pass is the IETF-standardized anonymous credential protocol (RFCs 9576 and 9577) that ships in iOS 16 and later as Apple Private Access Tokens.^13^ The construction is a blind signature over an attestation: an identity provider (Apple) attests that a device is a real user and not a bot, and a verifier (Cloudflare or Fastly) accepts the attestation without learning which device the attestation covers. The blind signature prevents the verifier from linking across requests. The attestation covers device integrity at a single moment, not the user’s identity, behavior, or persistent activity.
Apple Private Access Tokens are active on hundreds of millions of Apple devices and are accepted by Cloudflare in place of CAPTCHAs on a significant fraction of the web. No prior anonymous-credential deployment has approached this scale. The unlinkability the blind signature provides against the verifier is real, and the attestation the system depends on is issued by a single corporation whose participation is what makes the scale possible. Mass deployment of anonymous credentials arrived through a centralized attester, not around one.
ZK Privacy Pools on Smart-Contract Chains
Shielded pools on smart-contract chains have moved from research to production since 2023. Railgun operates across Ethereum, BSC, Polygon, and Arbitrum as an opt-in privacy pool using Groth16 SNARKs.^14^ Aztec Network operates as a private-by-default L2 where the execution environment itself preserves privacy, with selective disclosure controlled by each user. Privacy Pools, proposed by Buterin and co-authors in 2023, extend Tornado Cash’s deposit-mixer architecture with association sets: a user proves membership in a subset of the pool’s deposits that excludes deposits the user wishes to exclude on compliance grounds, and the proof reveals nothing about which deposit in the approved subset is the user’s.^15^ The 0xbow.io deployment is the production reference.
The three designs differ in how much privacy they default to and in how privacy interacts with compliance pressure. Railgun is an opt-in pool that users must choose to shield. Aztec is shielded by default. Privacy Pools are the design that most directly addresses the Tornado Cash criticism: privacy without opacity to a specific list of excluded deposits, with the exclusion list chosen by the user and not by any single authority. The construction shows that the zero-knowledge primitive can be used to distinguish criminal use from legitimate use without a central authority making the distinction, which is a property the older privacy-pool designs did not claim.
Current vs. Speculative Applications
Currently deployed and working applications include Zcash shielded transactions and rollup-based scaling of Ethereum and similar platforms. Zero-knowledge-based identity and attestation tooling has moved during the last two years from demonstration into production for several specific patterns. Group-membership attestation, which lets a participant prove membership in a registered group without revealing which member they are, has been deployed at conference-scale events for ticketing, voting, and access control; Semaphore and Zupass are the deployed examples of this pattern. OAuth-backed wallet creation has been deployed on at least one mainnet blockchain through zkLogin, which lets a user derive a wallet from an existing Google or Apple account login without the account provider learning which wallet was derived. Zero-knowledge selective disclosure over standard verifiable credentials has been implemented for narrow deployments including age-gate attestations and professional-license verification.^16^
Universal verifiable computation and zero-knowledge voting at scale, along with full privacy-preserving compliance systems, remain speculative in the book’s sense that their practical constraints still rule out broad deployment. The pattern that has moved into production in every case is the narrow one, where a specific statement is attested under a specific trust model with specific performance. The pattern that remains research is the general-purpose one. The direction of movement is what matters for the book’s framework: the category of production deployments is expanding, the performance envelope is widening, and the primitives the research community developed a decade ago are now carrying real load.
The technology is real and deployed in important applications, but maturity differs sharply by use case. A reader deciding whether to rely on a specific zero-knowledge system for a specific purpose should evaluate the maturity of that specific system, not the maturity of the field as a whole.
15.5 Economic Implications: Verification as Service
Once proof can be separated from disclosure, verification itself becomes a distinct service. Complex proofs require substantial computation to generate even though verification is fast, which opens room for specialized proving infrastructure. The privacy tradeoff is that a prover that sees the witness can reintroduce the trust problem the proof was meant to narrow; verification markets fit the book’s framework only when witness handling stays local, is split across multiple parties, or is protected by hardware that keeps the prover from extracting the underlying data. Where those conditions hold, zero-knowledge systems can reduce verification costs across the economy: compliance without exposure of business details, verifiable credentials without fraud-checking overhead, aggregate statistics without routine dossier building. The gains are narrow today and directional over time, verification need not always mean surveillance.
15.6 Limitations
Trusted Setup Requirements
Many SNARK constructions require a “trusted setup”: an initial ceremony generating parameters that all future proofs and verifications use. If the ceremony is compromised (someone retains the “toxic waste” used to generate parameters), they can create fake proofs that verify correctly.
Trusted setups come in several varieties with different tradeoffs. Per-circuit setups, as used in Zcash’s original Sprout system, require a new ceremony for each application or circuit change; any modification to the computation being proved requires discarding the old parameters and running a new trusted setup. Universal setups, as in systems like PLONK^20^ and Marlin,^21^ generate parameters that work for any circuit up to a certain size; one ceremony can serve many applications, though the ceremony itself remains a trust assumption. Transparent setups eliminate the requirement entirely: STARKs and some newer SNARKs like Spartan^18^ derive their parameters from public randomness, requiring no ceremony and leaving no toxic waste that could be retained.
Mitigations for systems requiring trusted setup include multi-party computation ceremonies where only one participant needs to be honest and Powers of Tau ceremonies with thousands of participants. But applications with strict trust requirements may prefer transparent constructions despite their larger proofs.
The trusted setup is a real limitation that responsible implementations take seriously.
Computational Intensity
Proof generation is computationally expensive. Simple proofs take seconds; complex proofs can take minutes or hours. This limits applications where latency matters.
Verification is fast (often milliseconds), but generation is the bottleneck. Hardware acceleration (GPUs, FPGAs, ASICs) can help but does not eliminate the fundamental computational cost.
Implementation Complexity
Zero-knowledge proof systems are mathematically sophisticated, and implementation bugs can destroy the security properties the mathematics is supposed to guarantee. A soundness failure lets invalid proofs verify, which means forged statements pass as true; a zero-knowledge failure leaks information through the proof itself, which defeats the privacy the system exists to provide. Subtle implementation errors of both kinds have affected deployed systems, often undetected for years before being discovered.
Auditing is correspondingly hard. Few engineers can competently review ZK implementations at the level needed to catch these bugs, and the scarcity of qualified reviewers concentrates trust in a small community whose time is itself a bottleneck on how many systems can be meaningfully examined.
What ZK Proofs Cannot Solve
Chapter 14 examined what cryptography cannot solve in general: endpoint security, metadata exposure, physical coercion, key authenticity. Zero-knowledge proofs inherit these limitations and add ZK-specific constraints.
The most significant is the garbage-in-garbage-out problem, often called the oracle problem. A zero-knowledge proof verifies that a computation was performed correctly on given inputs. It says nothing about whether those inputs were true. An application that claims “this loan is collateralized” using a ZK proof has proven only that the computation was done correctly on the price data it received; if that data was stale or manipulated, or false, the proof is meaningless. No amount of cryptographic sophistication can bridge the gap between “correctly computed” and “true.” Proving you processed oracle data correctly does not prove the oracle provided accurate data. This limitation is fundamental: ZK proofs verify computation, not reality.
Zero-knowledge adds complexity that may be unnecessary. When the verification problem does not require hiding information, simpler cryptographic tools suffice. Adding ZK machinery where it is not needed increases attack surface and implementation difficulty without corresponding benefit.
Chapter Summary
Zero-knowledge proofs separate verification from disclosure. Completeness, soundness, and zero-knowledge together ensure that true statements can be proven, false statements cannot, and the proof reveals nothing beyond the truth of the statement, the verifier learns what they need without access to the underlying data. The primitive resolves the verification dilemma that otherwise forces a choice between participation and privacy. Different constructions make different tradeoffs. SNARKs produce tiny proofs with fast verification but traditionally require trusted setup and are vulnerable to quantum attack; transparent SNARKs eliminate the setup at some cost to proof size or proving time. STARKs also avoid trusted setup and provide quantum resistance but produce much larger proofs. Bulletproofs occupy a middle ground suited to range proofs. Application requirements determine the appropriate choice.
Production deployment has reached specific patterns. Zcash shielded transactions and validity rollups for blockchain scaling are operational. Group-membership attestation through Semaphore and Zupass runs at conference-scale events, Sui’s zkLogin derives wallets from OAuth logins without the provider learning the derivation, and W3C Verifiable Credentials support selective disclosure in narrow age-gate and professional-licensing deployments. Zero-knowledge circuits over ICAO 9303 passport signatures, through Self and related projects, carry hundreds of millions of verifications using identity infrastructure the state itself issued. Privacy Pass ships as Apple Private Access Tokens on hundreds of millions of iOS devices. Railgun, Aztec, and Privacy Pools carry shielded transactions on smart-contract chains, with association-set constructions addressing the compliance concerns that older pool designs did not.
Universal verifiable computation and zero-knowledge KYC at broad economic scale remain speculative. The oracle problem constrains every application that depends on external data: a ZK proof verifies that computation was performed correctly on given inputs, not that the inputs were true. The category of production deployments is expanding, the performance envelope is widening, and the primitives developed in the research community a decade ago now carry real load, but maturity differs sharply by use case, and a reader evaluating any specific system should evaluate that system, not the field as a whole. The communication-layer and monetary-layer privacy that ZK proofs complement belong to Chapters 17 and 20 respectively.^17^
Endnotes
^1^ Shafi Goldwasser, Silvio Micali, and Charles Rackoff, “The Knowledge Complexity of Interactive Proof Systems,” SIAM Journal on Computing 18, no. 1 (1989): 186-208.
^2^ For accessible introduction to zero-knowledge proofs, see Matthew Green, “Zero Knowledge Proofs: An Illustrated Primer,” A Few Thoughts on Cryptographic Engineering (2014).
^3^ Jens Groth, “On the Size of Pairing-Based Non-interactive Arguments,” Advances in Cryptology: EUROCRYPT 2016 (2016): 305-326.
^4^ Zcash, https://z.cash, is a privacy-preserving cryptocurrency launched in October 2016 and derived from the Zerocash protocol described in Eli Ben-Sasson et al., “Zerocash: Decentralized Anonymous Payments from Bitcoin,” IEEE Symposium on Security and Privacy (2014), https://eprint.iacr.org/2014/349. Zcash shielded transactions use zk-SNARKs (originally BCTV14, later Groth16, now Halo 2 since the 2022 NU5 upgrade which removed the trusted setup) to prove transaction validity without revealing sender, receiver, or amount. The protocol is developed by the Electric Coin Company (https://z.cash) with the Zcash Foundation (https://zfnd.org) as an independent public-interest counterpart. For the broader design space of privacy-preserving cryptocurrencies, Monero (https://www.getmonero.org) takes a different approach: ring signatures and stealth addresses provide its anonymity guarantees; see Shen Noether et al., “Ring Confidential Transactions,” Ledger 1 (2016), https://ledgerjournal.org/ojs/ledger/article/view/34. Mimblewimble (implemented in Grin and Beam) and CoinJoin-based approaches on Bitcoin (Wasabi, JoinMarket) are the other main families.
^5^ Eli Ben-Sasson et al., “Scalable, Transparent, and Post-Quantum Secure Computational Integrity,” CRYPTO 2018 (2018).
^6^ Benedikt Bünz et al., “Bulletproofs: Short Proofs for Confidential Transactions and More,” IEEE Symposium on Security and Privacy (2018): 315-334.
^7^ Zerocash protocol: see note 4 above for the full citation and Zcash deployment details.
^8^ For rollup designs, see Vitalik Buterin, “An Incomplete Guide to Rollups,” Ethereum Blog (2021). The two largest ZK-rollup deployments on Ethereum are StarkNet (https://www.starknet.io/, developed by StarkWare) and zkSync (https://zksync.io/, developed by Matter Labs); both use validity proofs to compress large batches of transactions into a single on-chain proof. StarkNet documentation at https://www.starknet.io/; zkSync documentation at https://zksync.io/. Both use validity proofs to compress large numbers of transactions into a single on-chain proof.
^9^ Polygon ID (rebranded as Privado ID) documentation at https://docs.privado.id/. See also “Introducing Polygon ID, Zero-Knowledge Identity for Web3,” Polygon Technology Blog (2022), and Identity Foundation, “Guest Blog: Polygon ID: Verifiable Credentials Meet Web3.”
^10^ zkPass documentation at https://docs.zkpass.org/. zkPass uses Three-Party TLS (3P-TLS) and Multi-Party Computation to enable zero-knowledge proofs from HTTPS website data without exposing raw documents.
^11^ Worldcoin (rebranded as World, https://world.org/) uses iris-scan biometric enrollment to issue World ID, a zero-knowledge proof of unique human status. Sam Altman founded the project; Tools for Humanity is the operating entity. The privacy model depends on trust in the Orb hardware and the enrollment operator; technical architecture at https://whitepaper.worldcoin.org/. For critical analysis, see the data-protection investigations by Spanish (AEPD) and Kenyan regulators in 2023-2024.
^12^ Self (formerly Proof of Passport), zkPassport, Rarimo, and Anon Aadhaar use zero-knowledge circuits over ICAO 9303 passport NFC signatures and Aadhaar RSA signatures to produce selective-disclosure identity attestations from government-issued credentials; Rarimo’s Freedom Tool ran a production deployment for a Russian-opposition referendum in 2024. Self Protocol (formerly Proof of Passport), https://self.xyz/, with source at https://github.com/selfxyz. zkPassport, https://zkpassport.id/. Rarimo and Freedom Tool, https://rarimo.com/ and https://freedomtool.org/. Anon Aadhaar, a Privacy and Scaling Explorations project, https://pse.dev/projects/anon-aadhaar, with source at https://github.com/anon-aadhaar. ICAO Doc 9303 Machine Readable Travel Documents specification, https://www.icao.int/publications/Documents/9303_p11_cons_en.pdf. For the broader category of ZK attestation over existing signatures, see the academic line starting from Jens Groth, Rafail Ostrovsky, and Amit Sahai, “Perfect Non-Interactive Zero Knowledge for NP,” EUROCRYPT 2006, and continuing through Noir, Circom, and the proof-system developer toolchains cited in note 16.
^13^ Privacy Pass (IETF RFCs 9576 and 9577) is the anonymous-credential standard, and Apple Private Access Tokens are the single largest production deployment; the architecture’s scale depends on Apple acting as centralized attester. RFC 9576 (Privacy Pass Architectural Framework), Alex Davidson, Jana Iyengar, Christopher A. Wood, https://datatracker.ietf.org/doc/rfc9576/. RFC 9577 (Privacy Pass Issuance Protocols), Steven Valdez, https://datatracker.ietf.org/doc/rfc9577/. Apple Private Access Tokens documentation at https://developer.apple.com/documentation/authenticationservices/privacy_access_tokens, with Cloudflare integration documented at https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/. The earlier Cloudflare Privacy Pass research at https://blog.cloudflare.com/privacy-pass-v3/ and Alex Davidson, Ian Goldberg, Nick Sullivan, George Tankersley, and Filippo Valsorda, “Privacy Pass: Bypassing Internet Challenges Anonymously,” PoPETs 2018, no. 3 (2018).
^14^ Railgun documentation at https://railgun.org/, with the protocol specification at https://docs.railgun.org/. Aztec Network documentation at https://aztec.network/, with the Noir privacy-first programming language at https://noir-lang.org/. For the comparison with Zcash’s shielded-pool architecture examined in note 4, see Aztec’s “Private Execution Environment” documentation at https://docs.aztec.network/aztec/concepts/.
^15^ Vitalik Buterin, Ameen Soleimani, Jacob Illum, Matthias Nadler, Fabian Schär, and Ameen Soleimani, “Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium” (2023), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4563364, introduces the association-set construction. The 0xbow deployment is at https://0xbow.io/, with source at https://github.com/0xbow-io. For the Tornado Cash predecessor that Privacy Pools is a response to, see Van Loon v. Department of the Treasury, 122 F.4th 549 (5th Cir. 2024), and Chapter 13 for the legal-phase analysis the construction intersects with.
^16^ Semaphore (group-membership proofs) and Zupass (event-scale ticketing/credentials) are the deployed examples of zk-based group attestation; Sui’s zkLogin lets users derive wallets from OAuth login without the OAuth provider learning the derivation; verifiable-credential selective disclosure is in narrow production for age-gate and professional-license use cases. Semaphore, https://semaphore.pse.dev/, with source at https://github.com/semaphore-protocol/semaphore. Zupass (PCD framework), https://pcd.dev/ and https://zupass.org/. Mina PCD / Proof-Carrying Data documentation at https://pcd.dev/docs. zkLogin on Sui, https://docs.sui.io/concepts/cryptography/zklogin, with specification at https://sui.io/zklogin. World Wide Web Consortium Verifiable Credentials Data Model, https://www.w3.org/TR/vc-data-model/. ISO/IEC 18013-5 mobile driver’s license standard, https://www.iso.org/standard/69084.html. On age-gate and professional-license attestation deployments, see Privado ID, https://docs.privado.id/, and the eIDAS 2.0 European Digital Identity Wallet reference implementation at https://github.com/eu-digital-identity-wallet.
^18^ Srinath Setty, “Spartan: Efficient and General-Purpose zkSNARKs without Trusted Setup,” Advances in Cryptology: CRYPTO 2020 (2020): 704-737, https://eprint.iacr.org/2019/550. Spartan uses the sum-check protocol over multilinear extensions to achieve transparent SNARKs with no trusted setup and no toxic waste; security rests on the discrete-logarithm assumption in a group of prime order. The proving complexity is O(n log n) for arithmetic circuits of size n. Spartan is the foundation for Microsoft’s Nova folding-scheme prover (https://github.com/microsoft/Nova) and influenced subsequent transparent SNARK designs.
^19^ Polygon Zero Team, “Plonky2: Fast Recursive Arguments with PLONK and FRI” (2022), https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/plonky2.pdf. Plonky2 combines PLONK’s universal-setup arithmetization with FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity) as the polynomial commitment scheme, eliminating the elliptic-curve pairings that conventional SNARKs require. The result is a transparent SNARK with recursive proof composition times under 170 milliseconds on consumer hardware; Polygon uses it as the proving backend for its zkEVM and other scaling infrastructure. FRI’s hash-function-only assumptions make Plonky2 plausibly post-quantum, though formal post-quantum security proofs for the full construction remain an open research question.
^20^ Ariel Gabizon, Zachary J. Williamson, and Oana Ciobanu, “PLONK: Permutations over Lagrange-Bases for Oecumenical Noninteractive Arguments of Knowledge,” IACR ePrint 2019/953 (2019), https://eprint.iacr.org/2019/953. PLONK introduced a universal and updateable structured reference string: a single trusted setup ceremony produces parameters usable by any arithmetic circuit up to a given size, and the parameters can be updated by additional participants without rerunning the ceremony from scratch. This made universal-setup SNARKs practical for ecosystems like Ethereum, where many independent applications share proving infrastructure; PLONK arithmetization is now the basis for Halo 2, UltraPLONK, and numerous zkEVM backends.
^21^ Alothman Zac, Mary Maller, and Pratyush Mishra, “Marlin: Preprocessing zkSNARKs with Universal and Updatable SRS,” Advances in Cryptology: EUROCRYPT 2020 (2020): 738-768, https://eprint.iacr.org/2019/1047. Marlin generalizes the universal-setup approach of PLONK using a different arithmetization (R1CS over a universal SRS based on polynomial commitments) and provides the first formal proof of knowledge-soundness for a universal preprocessing zkSNARK. The construction underlies the Aleo blockchain’s Leo programming language and the snarkVM execution environment, which use Marlin as their proving backend for general-purpose private computation.
^17^ Further reading on zero-knowledge proofs. The foundational papers are Shafi Goldwasser, Silvio Micali, and Charles Rackoff, “The Knowledge Complexity of Interactive Proof-Systems,” SIAM Journal on Computing 18, no. 1 (1989): 186–208 (originally STOC 1985), https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf; and Oded Goldreich, Silvio Micali, and Avi Wigderson, “Proofs That Yield Nothing But Their Validity” (1991), which extended ZK to all of NP. For the textbook treatment, Oded Goldreich, Foundations of Cryptography: Volume 1, Basic Tools (Cambridge University Press, 2001), chapter 4, and Volume 2, Basic Applications (2004), chapter 4, are the canonical references. Jonathan Katz and Yehuda Lindell, Introduction to Modern Cryptography, 3rd ed. (CRC Press, 2020), covers ZK at the graduate-course level. For the practitioner side, Justin Thaler, Proofs, Arguments, and Zero-Knowledge (Now Publishers, 2023), https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.pdf, is the modern reference on SNARK/STARK construction. Matthew Green’s “Zero Knowledge Proofs: An Illustrated Primer” at https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/ is the best accessible explanation. For SNARKs specifically, the zkSNARK series by Vitalik Buterin at https://vitalik.eth.limo/general/2016/12/10/qap.html is practitioner-friendly. The 0xPARC curriculum at https://0xparc.org is a community resource for learning ZK programming hands-on. On the practical tooling, Circom (https://docs.circom.io), Halo 2 (https://zcash.github.io/halo2/), arkworks-rs (https://github.com/arkworks-rs), and Nova (https://github.com/microsoft/Nova) are the reference implementations for SNARK development; for STARKs, StarkWare’s Cairo (https://www.cairo-lang.org) is the primary public toolkit. On the identity-and-credentials side, the W3C Verifiable Credentials Data Model (https://www.w3.org/TR/vc-data-model/) and Hyperledger AnonCreds (https://github.com/hyperledger/anoncreds-spec) define the standards that much ZK identity work targets.
<- Previous: Cryptographic Foundations |
-> Next: Computing on Secrets |The Praxeology of Privacy – third edition. New chapters publish daily at 1600 UTC.
Highlights (1)
Zcash shows zero-knowledge proofs deployed at scale in adversarial conditions. Shielded adoption remains partial, and transparent or selectively transparent usage still limits privacy in practice.^4^ Many exchanges require transparent addresses for deposits and withdrawals, undermining the privacy benefits. The shielding technology works, but network effects and regulatory pressure limit its use.
More from The Praxeology of Privacy
Write a comment