From scaling rollups to private identity, ZK proofs are quietly rewriting what “onchain” can mean.
I still remember the first time I tried to explain “zero-knowledge proofs” to someone. They looked at me like I’d just made the term up: “Wait… you can prove something is true without showing the data?” Back then, even I wasn’t fully convinced. It sounded like marketing, a buzzword attached to every new L2 and privacy coin. But over the last year, something shifted. Zero-knowledge proofs (ZKPs) stopped being a niche cryptography trick and started showing up everywhere: rollups, identity, compliance, gaming, even machine learning.
If Layer 2 scaling was your first encounter with ZK in **Day 14: [Optimistic vs ZK Rollups](https://medium.com/coinmonks/layer-2-solutions-deep-dive-op…
From scaling rollups to private identity, ZK proofs are quietly rewriting what “onchain” can mean.
I still remember the first time I tried to explain “zero-knowledge proofs” to someone. They looked at me like I’d just made the term up: “Wait… you can prove something is true without showing the data?” Back then, even I wasn’t fully convinced. It sounded like marketing, a buzzword attached to every new L2 and privacy coin. But over the last year, something shifted. Zero-knowledge proofs (ZKPs) stopped being a niche cryptography trick and started showing up everywhere: rollups, identity, compliance, gaming, even machine learning.
If Layer 2 scaling was your first encounter with ZK in Day 14: Optimistic vs ZK Rollups, today is where we finally zoom in on the engine itself and see how “prove, don’t reveal” is becoming one of the most powerful primitives in Web3.
Quick Recap: What You Already Know From Day 14
On Day 14, we treated zero-knowledge proofs as part of the scaling story. You met ZK-rollups as the L2 that can prove a whole batch of transactions to Ethereum with a succinct proof, instead of posting every step onchain. We touched on the basic promise (“I can prove this state transition is valid without revealing every transaction”), the differences between zk-SNARKs, zk-STARKs, and PLONK at a high level, and zkSync-style rollups that use ZK to get faster finality and lower data costs compared to optimistic rollups.
We intentionally stayed at the rollup level and didn’t really ask what else you can prove without revealing the underlying data. Today is about that broader landscape.
This is day 38 Come hang out in Web3ForHumans on Telegram. Follow me on Medium | Twitter | Future
What Is a Zero-Knowledge Proof, Really?
A zero-knowledge proof is a protocol where a prover convinces a verifier that a statement is true, without revealing why it is true or any extra information. The classic intuition is the “Ali Baba’s Cave” story: imagine a circular cave with a locked door in the middle; your friend claims they know the secret word that opens the door, but you don’t want to know the word, you just want to know they really know it.
You send them into the cave, then at random you shout “come out from the left” or “come out from the right.” If they can always satisfy your random requests, you become statistically confident they must know the secret word, even though you never learn the word itself. That’s a zero-knowledge proof in plain language: convincing someone you know the answer, without revealing the answer.
In blockchains, the “cave” is a computation or a transaction set, the “secret word” is the private data or witness, and the proof is a small piece of math that says: “I ran this computation correctly on some hidden data, and the result satisfies these rules.”
ZK Beyond Rollups: Three Big Buckets
Rollups might be your first ZK use case, but not the last. Broadly, zero-knowledge proofs in Web3 fall into three buckets:
- Privacy for money
- Privacy for identity and access
- Verifiable compute
1. Privacy for Money: “I Paid You, But No One Sees How Much”
The first big “wow” moment for many people came from privacy coins and mixers. Zcash is the canonical example: it uses zk-SNARKs so that shielded transactions can be verified as valid without publicly revealing sender, receiver, or amount, while still enforcing that inputs equal outputs and no extra coins are created. In practice, that means you can have shielded balances where your address exists but nobody can see your holdings, and shielded transfers where the network is sure the transaction is valid but can’t see the details.
If you want a gentle overview, the Zcash site’s “What are zk‑SNARKs?”
Similar ideas show up in privacy pools and mixers, where multiple users deposit into a pool and later withdraw with a proof that they’re entitled to some coins from the pool, without revealing which deposit was theirs. This matters in 2026 for users in high-surveillance environments who need financial privacy, for funds that want to prove solvency without revealing exact positions, and for protocols that are exploring “compliance-friendly privacy” rather than fully transparent everything.
2. Privacy for Identity: “I’m Over 18, But You Don’t Need My Passport”
If privacy for money was the first wave, privacy for identity may be the next. Imagine being able to prove you are over 18, live in a specific country, or passed a KYC check with a regulated provider, without revealing your name, full address, or ID number to every dApp you touch. That’s the idea behind ZK credentials and verifiable proofs of attributes.
A typical pattern looks like this: a trusted issuer (such as a KYC provider, exchange, or university) issues you a credential; that credential is represented as a cryptographic commitment on or off chain; when a dApp needs to check a property (like “age ≥ 18” or “KYC-passed”), your wallet generates a ZK proof that the credential satisfies that property, and the verifier checks the proof and issuer’s key without seeing your raw personal data. This enables age-gated dApps, Sybil-resistant voting, and KYC-gated DeFi, all without turning every interaction into a full KYC form.
In short, ZK lets us unbundle who you are (private) from what you’re allowed to do (public and provable).
3. Verifiable Compute: “Trust the Output, Not the Server”
The third bucket is less about hiding data and more about trusting computation. Think about any offchain process: a price oracle computing a VWAP, a game engine resolving a complex match, or a machine learning model classifying transactions as risky. Today, you usually trust a service provider’s API or a committee that signs results.
With verifiable compute, the computation runs offchain, but alongside the result it produces a ZK proof that the program was executed correctly on some input. The chain or user verifies the proof in milliseconds without seeing the raw inputs or internal steps. This pattern is appearing in ZK oracle networks that prove their price calculations, ZK coprocessors that run heavy logic offchain but verify it onchain, and zkML experiments that prove a model was evaluated honestly without exposing weights or user data.
A Bit Deeper: SNARKs, STARKs, and Friends
When a protocol says “we use ZK,” under the hood they usually mean one or more concrete proof systems like zk-SNARKs, zk-STARKs, PLONK-style systems, or Bulletproofs. The main trade-offs revolve around:
- Proof size
- Verification speed
- Need for a trusted setup
- Security assumptions
- Developer ergonomics
zk-SNARKs give you tiny proofs and very fast verification, which is why they are widely used in Zcash and many ZK-rollups, but most constructions need a trusted setup ceremony to generate public parameters. zk-STARKs avoid trusted setup and offer post-quantum security at the cost of larger proof sizes, and are popular in ecosystems that prioritize transparency and long-term security. PLONK-style universal SNARKs aim to make it easier to support many applications from a single setup, which is attractive for developers who want flexibility across circuits.
As a builder, you usually don’t interact with elliptic curves directly; you interact with languages, compilers, and SDKs that hide the math and let you focus on describing the computation you want to prove.
ZK Developer Tooling: How Builders Actually Write Proofs
The ZK ecosystem has steadily been building developer frameworks that feel more like writing constraints in a DSL than hand-coding cryptography. For example, languages such as Circom let you describe circuits and constraints at a high level, then compile them into a constraint system and generate proofs using tools like snarkjs.
A very practical starting point is this Circom guide.
It walks through designing simple circuits, testing components, and connecting them into larger systems.
The typical journey for a Solidity or full-stack Web3 dev looks like this: start from existing circuits (like Merkle membership proofs or basic arithmetic checks), wire proofs into smart contracts that call on-chain verifiers, and only then move to designing custom circuits when you have specific privacy or compute needs. You don’t need to be a cryptographer to be ZK-literate, but ignoring ZK entirely will increasingly feel like ignoring ERC‑20 in 2018.
Why ZK Matters in 2026: Privacy, Compliance, and UX
ZK matters in 2026 because it sits at the intersection of three pressures: regulators want more compliance and transparency, users want more privacy and control, and protocols want to prove solvency and correctness without giving away sensitive information. Zero-knowledge proofs give you a way to prove you did the right thing (to regulators and counterparties) without exposing all the underlying data (for users and businesses), while also compressing heavy computation into small proofs that chains and rollups can verify cheaply.
This changes the privacy vs compliance debate: instead of choosing between total transparency and total opacity, you can prove specific compliance properties (age, jurisdiction, KYC status, collateralization ratios) without revealing personal identity or internal positions. That’s a very different way to think about “onchain” trust.
Challenges and Trade-Offs: ZK Isn’t Magic
It’s tempting to treat ZK as a magic wand, but there are real constraints. Proof generation can be expensive in both time and hardware, especially for complex circuits; verification is fast, but on-chain gas costs still matter, so circuit design and choice of proof system have direct impact on fees. Developer experience is also more demanding: you’re reasoning about constraints instead of straightforward imperative code, debugging can be harder, and the tooling is evolving quickly.
Some systems, especially older or SNARK-based ones, still rely on trusted setup ceremonies, where public parameters are generated via multi-party computation and must remain secret-immune for soundness; if these parameters were compromised, an attacker could in theory forge valid-looking proofs. This is why transparent systems (like many STARK designs) and universal setups are attracting interest. Even with ZK, you still need audits, threat modeling, and careful design, particularly when handling sensitive financial or identity data.
A Simple Developer Journey: Your First ZK-Powered dApp
To make all this concrete, imagine you want to build a “proof-of-age” dApp. A KYC provider verifies your ID once and issues you a credential; that credential is encoded as a cryptographic commitment, and when you visit a dApp, your wallet generates a ZK proof that the age field in the credential is at least 18. The smart contract verifies the proof using a verifier contract and the issuer’s public key; if it passes, you gain access, but the dApp never sees your name, full date of birth, or document number.
From the user’s perspective, it feels like “Connect wallet → Prove age → Enter.” From the builder’s perspective, you’ve combined identity, compliance, privacy, and cryptography without storing anyone’s passport in your database. This is what “Web3 with ZK” looks like in practice: not just faster rollups, but new UX and trust models where you can prove the right things while hiding the rest.
Key Takeaways
You first met ZK as a scaling tool in Day 14’s rollup deep dive; today we treated it as a general primitive for privacy, identity, and verifiable compute. Zero-knowledge proofs let you prove a statement is true without revealing the underlying data, which enables private money (shielded transfers and privacy pools), private identity (age and KYC proofs without doxxing), and verifiable offchain computation (oracles, zkML, and coprocessors).
Different proof systems such as SNARKs, STARKs, and PLONK balance proof size, speed, setup, and security, while evolving tooling like Circom and related stacks make ZK accessible to non-cryptographers. In 2026, ZK is increasingly how Web3 reconciles privacy, compliance, and performance without being forced to pick only one side.
What’s Next (Day 39 Preview)
Today we zoomed into the math engine behind a lot of what you’ve already seen. Tomorrow, we’ll switch layers again. On Day 39, we’ll move from “proving things privately” to “storing things reliably” with decentralized storage and IPFS—how content-addressed storage actually works, why “putting something on IPFS” is very different from “putting it on Ethereum,” and how this shapes the way we design frontends, NFTs, and data-heavy dApps.
Once you can both prove and store things in new ways, many of your default Web2 assumptions about where data lives and who can see it start to break.
Resources
If you want to go deeper into ZK proofs after today’s article, these are good next steps:
Zcash: What Are zk‑SNARKs? Gentle conceptual intro to zk‑SNARKs and how Zcash uses them for shielded transactions.
Zcash Protocol & Privacy Design (Gemini Cryptopedia) Overview of how Zcash structures its privacy features, shielded addresses, and zk‑SNARK usage.
Zero-Knowledge Proofs for Programmers (Cyfrin) A practical deep dive into ZK from a developer’s perspective, with examples and mental models.
Mastering Circom: Beginner’s Guide to ZK DSLs Step-by-step guide to writing your first circuits in Circom and generating proofs with snarkjs.
ZK + Identity / Compliance Use Cases Roundups and commentary on how ZK proofs are being used for identity, KYC, and compliance-friendly privacy.
Come hang out in Web3ForHumans on Telegram. Follow me on Medium | Twitter | Future