The ZK Chronicles: ZK in the Wild

This is it. It's the end of the road. We're finally here.

Throughout our journey together (heck, spanning over 20 articles), we've seen our fair share of interesting proving mechanisms, combining different techniques to cater for several use cases, and ultimately getting to the very frontier of verifiable computing.

And I mean, sure, there's always more to learn (again, I strongly recommend reading Justin Thaler's Proofs, Arguments, and Zero Knowledge if you want even stronger coverage, since we've skipped a few steps along the way). The ZK field moves incredibly fast, and ideas that were purely theoretical two years ago are running in production today.

On top of that, an entire new category of proving systems is being rebuilt from scratch to survive the quantum era.

At the very least, my hope is that by having explored some of the most influential protocols in the field, you guys (and myself) are prepared to understand whatever's coming next.

Knowing about these protocols is, however, only one side of the story. After all, these techniques would be pointless if we can't find applications for them!

So before we close the curtain on this series, I want us to spend this final article looking at some interesting applications for ZK. And in addition, we'll take a little peek into where things might be headed next.

Now, if I had to guess what comes to mind first when you hear "ZK applications", it'd be ZK rollups: they execute a big batch of blockchain transactions off-chain, and post the result to the base chain along with a single proof that it was all done correctly (we covered them in a previous article). Checking a proof is far cheaper than redoing all the work, so this is exactly where the succinctness we've been chasing pays off.

Funnily enough, most "ZK rollups" don't hide anything: transactions are public. They only care about succinctness, which is why "validity rollups" would be a more honest name. And by now, we know why that works: zero knowledge is always the optional extra on top of proving knowledge.

It's the application that made the most headlines, but it's also the most well-known one. So instead, I want to make the most of our time today, and for that we'll wander into some less charted territory.

Our final dance begins now!

Web Traffic

Let's look at something pretty much everyone has had to deal with: surfing the web.

Whenever you open a website, the URL very likely starts with https. That "s" comes from Transport Layer Security, or TLS for short, a protocol that establishes a symmetric encryption key (the session key) between the server and the client. HTTP traffic then travels encrypted inside the TLS session (which itself runs over TCP), and only those two can ever read it.

Formerly known as Secure Sockets Layer, or SSL.

As good as that sounds, it can become a problem, precisely because no one else can read the data.

Imagine we want to prove to somebody that we received a specific piece of data from a specific server. Just showing the data doesn't say where it came from. And it gets worse: the session key is a shared secret, so whatever the server can encrypt and authenticate with it, the client can too. A client could fabricate a perfectly valid-looking transcript of something the server never said, which means that showing the data (or even handing over the key) proves nothing.

But why would we want this? Because this would let us prove things about our data on a remote server, without sharing the data itself.

For example, suppose you're an Uber driver with two years of activity, with thousands of completed rides, a 4.9 rating, and consistent earnings.

You want a loan, but you have no traditional credit history. What you do have is your Uber track record. So you generate a proof that this data was served to you by Uber's servers, and present it to a DeFi lending protocol to unlock better terms, all without handing over your credentials, your full ride history, or anything beyond what the proof certifies.

So how do we get there?

zkTLS

zkTLS is the attempt to cater for exactly this: to turn a private TLS session into a verifiable statement. There are two main approaches, both involving a third party who vouches for the session without reading it:

• MPC-TLS, used by TLSNotary, uses multi-party computation to split the session key between the client (the prover) and a notary. Neither holds the full key, so the prover can't forge a server message on its own. The notary can later attest: "I was part of this session, so this transcript is genuine."
• The proxy approach, used by Reclaim Protocol, puts a proxy between you and the server to witness the encrypted traffic. You keep the key, and prove in ZK that the data the proxy saw decrypts to whatever you're claiming.

Click to zoom

Both approaches are valid, but of course, they have their pros and cons. For instance, the cryptography behind TLS (AES, ChaCha20, SHA-256) is expensive to prove in ZK (or at least that was the case until recently, when it comes to hashes like SHA-256), so MPC-TLS keeps it out of the circuit and makes the session heavier, while the proxy makes the proof heavier. And neither is trustless: if the notary or proxy colludes with the prover, they can still cook up a transcript. What we gain, really, is that no single party can fake it alone.

So where does the ZK come in? Once the transcript is attested, we can prove that some specific field belongs to the server's response (or satisfies some property) without revealing the full payload. This is selective disclosure, and it works as a private oracle: a way to feed certified real-world data into any application, like credit scores on a blockchain based on off-chain financial data, or social credentials without handing over full account details.

It's an intriguing direction for data privacy, but for now, it remains a cool and niche idea.

And that's about as far as we'll go with web traffic. Let's move on to our next topic.

ZK meets AI

AI is clearly the winner for the "buzzword of the moment" award, and it seems to be popping up everywhere nowadays.

Like, it almost feels like anything that doesn't have some AI stamped on it is outdated.

There's certainly a myriad of applications for it, and the technology keeps evolving at a vertiginous pace. But in almost every case, we have to make a concession: unless we're willing to train our own models, we have no choice but to trust the models themselves and their operators.

What does this mean in practice? For one, we must trust that the model they claim to be running is the one actually running (there's the famous case of Builder.ai, which reportedly relied mostly on human engineers behind the scenes), that it was run honestly, and that your data stayed private in the process.

What to do then? Well, as the co-founder of Scroll once put it:

AI is the sword, ZK is the shieldAI is the sword, ZK is the shield

Meaning that ZK might have something to say about these problems!

Verifiable Inference

Let's start with one of those things we usually take for granted: how do we know an LLM was executed correctly on a specific input?

This is where zkML (ZK Machine Learning) comes in: it generates a proof that the computations performed by something like a neural network were executed correctly.

Which sounds reminiscent of our pass through zkVMs!

The appeal is obvious. Imagine a medical AI that gives a diagnosis for a patient: you could prove the diagnosis was correctly calculated without ever revealing the patient's data. And the proof can be bound to a commitment to the model's weights, so the operator can't quietly swap in a different model (or no model at all). Which rules out cases like Builder.ai's.

Alas, getting there is easier said than done. The main challenge is arithmetization: neural networks are full of non-linear activation functions (ReLU, softmax, sigmoids), which are painful to express as polynomial constraints. Even ReLU involves range checks and conditional logic, and we must do this for every neuron, so constraint counts become prohibitive really quickly.

One promising approach is to use lookup tables: precompute the activation function over a bounded input range, and prove that each activation output belongs to the table.

EZKL is probably the most mature zkML framework today. It takes a model in ONNX format (the standard interchange for neural networks), compiles it to a circuit, and generates proofs with GPU acceleration.

We must be honest about the current state of things though. Research like zkLLM has managed to prove inference for a 13B-parameter model, but it takes minutes per proof and serious hardware, so proving LLMs at production scale is not yet practical. In the meantime, the practical competitors are trusted execution environments (TEEs, hardware-based secure enclaves) and optimistic schemes (assume the result is right unless someone challenges it), which trade some of the cryptographic guarantees for speed.

But the path is set, and given how fast the field is moving, I wouldn't be surprised to see zkML become practical in the next few years!

Private Inference

zkML proves that a model ran correctly, but what about the inputs? If you're feeding sensitive data to an AI, how do you know it's not being stored somewhere, and used for purposes you don't consent to?

This calls for a tool that complements ZK in many cases: fully homomorphic encryption, or FHE for short. Instead of sending plaintext inputs, you send ciphertext. The model runs homomorphically on it, meaning that it operates directly on the encrypted data and returns an encrypted result, so the operator never sees your data. As a refresher, this means that operating first and then encrypting gives the same result as encrypting first and then operating.

Click to zoom

FHE supports additions and multiplications, and that's enough to build circuits over encrypted data. Add a ZK proof on top, and we get something extremely powerful: proof that an encrypted computation was performed correctly, without revealing any of the inputs, outputs, or anything in between. This could unlock things like:

• An AI company proving their model ran correctly on your encrypted medical records.
• A credit scoring agency computing your score from your encrypted bank history and proving the result, without you handing over raw transactions.
• A government service verifying your benefit eligibility from encrypted tax records, proving the decision was correct without accessing your income data.

If it sounds too good to be true, it's because it kinda is. FHE is computationally expensive (although it has seen sizable performance gains in recent years), and combining it with ZK compounds the cost, especially when dealing with large computations like LLMs'. So this is still largely in research.

AI is really just one example, too. Smart contracts could consume the results of private off-chain computation, or hold encrypted balances: users keep their balances on a public blockchain, but since they're encrypted, nobody can tell how many assets they hold. The most active team building this infrastructure is Zama, with open-source FHE tooling like fhEVM, an Ethereum-compatible VM running over encrypted state, and ongoing exploration of ZK layers to make FHE computations auditable on-chain.

FHE is a very deep subject, deep enough to warrant its own series. We might get there in the future, but for now, think of zkFHE as the frontier where two major privacy tools converge: FHE keeps computation private, and ZK makes it verifiable.

Zama has even proposed the HTTPZ protocol, which would extend web traffic itself: instead of a TLS session where the server sees your plaintext request, the client sends encrypted inputs and the server computes homomorphically, with a ZK layer proving it did so correctly. So who knows? We might see the internet itself being restructured around this technology someday!

Proving You Belong

There's one very useful primitive (or shape, if you will) that keeps popping up in applied ZK: prove you belong to a set, without revealing which member you are.

Proving that allows you to take actions gated only to the group. But if people can do things privately, then how do we know they don't do things twice?

The answer is that they leave behind a one-time tag, that marks that they have already taken said action. That tag is called a nullifier: a one-time serial number, derived from your secret identity, that looks random and can't be traced back to you. And it's one of the most recurring ideas in applied ZK.

But what is it useful for exactly? Let's see what it can buy us.

Spent At Most Once

Private payments were among the first battle-tested ZK applications in the wild. Blockchains are public by design, so the trick is to record commitments to transfers rather than the transfers themselves, and then use ZK proofs to force two invariants: no coins created from thin air, and each coin spent at most once.

That second invariant is exactly what nullifiers are for. When you spend a coin, you publish its nullifier, derived from the coin and your secret key. Everybody keeps track of the nullifiers seen so far and rejects repeats, yet nothing connects a nullifier to the commitment it came from.

Zcash pioneered this, and it has gone through three generations of its shielded protocol, each with its own proving system: Sprout used BCTV14, Sapling used Groth16, and Orchard uses Halo 2, which gets rid of the trusted setup by leaning on inner product arguments.

One Person, One Vote

We then have Semaphore, developed by the Ethereum Privacy and Scaling Explorations team, which takes the same idea and applies it to anonymous signaling. A group (say, eligible voters) is a Merkle tree of identity commitments. You prove you're a leaf in that tree, without revealing which one, and attach a nullifier tied to a specific scope, like a particular poll. So you can vote once per poll, yet nobody can link your votes across polls. It's essentially a programmable version of ring signatures, and it backs several on-chain governance experiments.

World applies this to a harder problem: proving you're a unique human. It scans your iris to establish that, and then lets you prove "I'm a verified unique human" to any application, without revealing your iris scan, your identity, or even which ID is yours. Its nullifiers are specific to each combination of user, app and action: so an app can ensure that you only claim something once, but two different apps can't tell they're talking to the same person.

Curious stuff: biometric data as the root of trust, with ZK as the privacy layer on top. Some think it's controversial, but the tech side of things surely is nice.

A Ring VRF

Now let me show you an example that brings together a bunch of things from this series, and comes from a place I'm quite fond of: Polkadot's JAM.

As in many blockchains, a block author must be chosen for every slot. But if everyone knew the next author well in advance, that validator would become a juicy target for a DoS attack: knock it offline, and the slot is wasted.

The solution, called Safrole, has validators submit tickets ahead of time, which determine who gets to author future slots. The catch is that tickets must be anonymous: each one comes with a proof that it was produced by some eligible validator, without saying which. And the tool for the job is the ring VRF. Let's take it apart piece by piece, starting with the VRF.

A verifiable random function is, in essence, a random number generator tied to your secret key. You feed it a public input, and it gives you back a random-looking number, along with a proof that it was computed honestly.

Click to zoom

Two properties matter here:

• It's unpredictable: nobody can guess the output without your secret key.
• It's deterministic: the same key and the same input always give the same output, so you can't keep re-rolling until you like the result.

Under the hood, the output is just $Z = [d]H$, where $d$ is your secret key and $H$ is the input hashed to a curve point. In Safrole, the input is derived from the epoch's randomness, and the output is what a validator uses as their ticket.

But there's a problem: checking a VRF proof requires your public key, which reveals who you are, and that's precisely what we want to avoid. So we need to do two more things, namely:

1. We need to hide the key. For this, a Pedersen VRF replaces your public key with a Pedersen commitment to your secret key, which we can picture as a sealed envelope. And by this point, you know the drill: you can prove, in zero knowledge, that you know the opening to said commitment. Plus, since the blinding factors are fresh every time, the envelope doesn't point to any particular validator.
2. We then need to prove the envelope belongs to a ring. The "ring" is just the list of eligible validators' public keys. A SNARK shows that the sealed key is tied to one of the keys in the list, without saying which. It's like proving you're on the guest list without pointing at your name.

The verifier is left knowing only that "some validator in the ring produced this output", and nothing else.

At least, that's the idea. However, our requirements hide an engineering challenge - one that we've met before in our endeavors. You see, to tie the envelope (a curve point) to the keys in the ring, the SNARK has to do elliptic curve arithmetic inside the circuit. And that brings back the field mismatch problem we had during our discussion on recursion: with an arbitrary curve, point coordinates live in a different field than the one the circuit works over.

Back then, a cycle of curves was our way out. But here, we don't need the full cycle! A curve whose base field is the circuit's field is enough. That's where Bandersnatch comes in: it's a curve built over the scalar field of BLS12-381, so its arithmetic is "native" to SNARKs over that curve.

This kind of curve is called an embedded curve.

Nullifiers show up again here, in disguise. Remember, a VRF is deterministic: the same key and the same input always give the same output, while different inputs give outputs that look completely unrelated.

So if you think of the input as a context, then we can say that within any one context, a validator always produces the same tag. Switch the context however, and the same validators produce new tags that cannot be linked together.

In short: the output of the ring VRF is the nullifier itself!

The same trick has uses beyond block production, too. Polkadot's People registry, for example, relies on it to give each person one pseudonym (an alias) per context, for proof of personhood: stable inside a context, but unlinkable across them.

ZK reaches into many other areas, but covering all of them in full detail would stretch this article too long. So here are a few more notable mentions, which I'll leave for you to investigate if you so wish!

• Private API access (zkAPI): How do you pay for an AI model without tying every prompt to your identity? Announced in October 2026 by the Ethereum Foundation and the Open Anonymity Project, zkAPI builds on a design by Davide Crapis and Vitalik Buterin, whose research proposal uses a ZK-STARK. You deposit funds once, then prove in ZK that you have credit in some deposit to get a temporary API key with a spending cap, and a nullifier per spend keeps credit from being used twice. Only your identity as a payer is hidden though (prompts and your IP can still give you away), and it's still experimental.
• Age verification: Proving you're over 18 shouldn't mean handing over a document with your name, address and birthday. Google's open-source Longfellow ZK lets you prove statements about a digital credential (like a mobile driver's license), such as "the holder is over 18", without revealing anything else. It's drawing interest from European age verification and digital identity wallet projects.
• Proof of provenance: As AI-generated content becomes indistinguishable from real photographs, we'd like to know where an image came from. The C2PA standard lets cameras sign images (no ZK involved), but the signature breaks as soon as the image is edited. ZK research (PhotoProof, ZK-IMG, VerITAS) proves that a published image is the result of permitted edits, like cropping or resizing, applied to a signed original, without revealing the original, though it's still heavy. And remember: a signature only proves a camera signed some pixels, not that they depict reality (someone can always photograph a screen).

And much, much more!

That will be all for us today on the applications side of things. But before we go, there's one more thing we need to talk about.

Not so much about where ZK is today, but about what the ecosystem needs to prepare for.

The Quantum Horizon

It's no coincidence that everything we've built in this series rests on the shoulders of some assumptions around the computational hardness of some problems.

That's just how most of cryptography operates: we find a problem that's really hard to solve, but very easy to verify given the right conditions.

Problems such as the discrete logarithm problem have been a fundamental cornerstone in our efforts to build ZK proofs.

Now, imagine that for some magical reason, those assumptions turned out to be weaker than expected. That is, if there's a way to easily solve these problems which we thought to be extremely hard, then everything would crumble to the ground! Secret keys could be reverse-engineered, toxic waste values could be recovered, and in general, every security guarantee we thought to be unbreakable would be shattered.

Well, I have some bad news then: that kind of magic does exist.

Yup. Quantum computers are a breed of machines with some very strange capabilities that allow them to run algorithms that wouldn't even make sense in classical computers. And while this has the potential to push human knowledge in ways we may not even yet fathom, it's a double-edged sword, because it also has the potential to crack some of these hard problems we have built most cryptography upon.

For us, this means that an attacker running a quantum computer could forge valid proofs for certain protocols. So if this technology exists, every proof becomes suspicious.

There's also a retroactive angle, though it's subtler than it sounds. Simply collecting proofs today doesn't let anyone forge anything later: many SNARKs are perfectly zero knowledge, and Pedersen commitments are perfectly hiding, so there's nothing to recover from them. The real risks are that encrypted data harvested today (think shielded notes, or TLS handshakes) could be decrypted once the technology is available, and that an attacker could forge a history that systems would accept as valid old state.

The first one is usually referred to as "harvest now, decrypt later".

It's quite a dire prospect, I know. So here's a little piece of good news for a change: not all hope is lost!

Post-Quantum Resistance

Some of the cryptography we already use and love is actually quantum resistant (or post-quantum resistant, as it's also referred to). Hash-based systems happen to resist quantum attacks quite well, because hash functions offer no algebraic foothold whatsoever for quantum algorithms to exploit.

For example, Shor's algorithm can solve the discrete logarithm problem in polynomial time by finding hidden periodicities in mathematical structures. But hash functions are designed to look essentially random, so there's no equation to solve, nor periodicity to find.

The best a quantum attacker can do is brute-force. There are some ways to accelerate this with quantum computers (Grover's algorithm), but the gains in performance are not that substantial. So yeah, it's annoying, but manageable!

That means that STARKs (or FRI-based systems in general), which rely entirely on collision-resistant hash functions (like Keccak or SHA-256), are already quantum secure. And that's one of the reasons the STARK family of protocols and its surrounding ecosystem has been growing so aggressively: because it's not just a matter of performance, but also hedging against the quantum future.

There's a catch though: a system is only as post-quantum as its weakest layer. STARK proofs are big, so verifying them directly on a network like Ethereum gets expensive, and a common trick is to wrap them in a Groth16 proof, which is tiny and cheap to verify. But Groth16 is pairing-based, so wrapping a STARK with it brings the quantum weakness right back in.

Elliptic-curve and pairing-based SNARKs, in contrast with their hash-based cousins, don't have the same luxury. But that doesn't mean they're completely ruled out - it just means we need to look for other alternatives!

At the time of writing this, the leading direction seems to be lattice-based cryptography.

I've talked about rings and lattices previously, so you might want to check that out if you're curious!

Lattice problems like learning with errors (LWE) and module SIS are believed to be hard enough to be quantum-resistant, and on top of that, they are built upon a rich algebraic structure that could support commitment schemes and proving systems.

To name a couple of recent efforts, there's LatticeFold, a lattice-based folding scheme similar to Nova, and then there's Greyhound for lattice-based polynomial commitments.

Needless to say, this is still very green. Proof sizes are larger than their elliptic-curve equivalents, and lattice assumptions have fewer decades of scrutiny behind them than hash functions. But the progress is real, and the broader industry is already moving: in 2024, NIST published its first post-quantum standards, two of them lattice-based (ML-KEM and ML-DSA) and one hash-based (SLH-DSA). Which lines up nicely with what we just discussed.

Concretely, Zcash (Groth16 and Halo 2 both rely on elliptic curves) and the ring VRF we saw earlier (which relies on elliptic curves and pairings) fall on the vulnerable side. The zkAPI proposal's STARK, on the other hand, would hold up much better, although the Ethereum deposits and signatures around it would still need their own upgrade.

In short then, we're likely to see hash-based systems as the near-term safe default, and lattice-based systems as the longer-term bet.

Ethereum itself is leaning into the hash-based side of this bet. The Ethereum Foundation's post-quantum roadmap proposes replacing validator signatures with a hash-based scheme (leanXMSS), and using SNARK-based aggregation (through a minimal zkVM) to make up for their larger size. And Justin Drake announced that the Foundation is abandoning Poseidon for L1 in favor of standard hashes like SHA or BLAKE, because SNARKs have gotten much better at proving them. In his words, "the key was not SNARK-friendly hashes, but hash-friendly SNARKs". Keep in mind that this is a plan and not a shipped change, and there's no fixed date for it.

But who knows? Maybe there are even better framings to discover. What I do know is I'm definitely excited to see where all of this goes!

Summary

And that's a wrap!

It's been a hell of a ride, hasn't it? I hope it has been as rewarding for you as it has been for me, my dear reader. We went through a hella lot of content, so my most sincere wish is to have been able to dispel some of the mysticism around ZK for you.

I know this series has helped me do that for myself, at the very least!

Looking back at the applications we've covered, they mostly fall into three patterns:

• Prove a computation: rollups, zkML and zkFHE all ask "was this program run correctly?".
• Prove you belong: Zcash, Semaphore, World, ring VRFs and zkAPI all say "I'm in this set", and leave a nullifier behind.
• Prove where something came from: zkTLS and image provenance certify the origin of some data.

Different clothes, same premise.

ZK is not magic, but I reckon it can be hard to get a grasp on.

It might help to always remember the basic premise, and then focus on the details: remember that it's all about proving knowledge of certain information, and ZK is a nice touch on top of that which may or may not be relevant. And we can also view this through the lens of verifiable computing, where the stuff we want to prove is just that some computation's result is correct!

The field is still young. Many of the modern techniques didn't exist three years ago, and applications like zkML are only now mutating from a research curiosity to a real possible application.

What's most important is to understand the foundations upon which all of that is built. And I think that after going through these articles, we should be fluent enough to not get lost in the details.

Or not get too lost, at least!

That's all folks! As always, it's been my pleasure. Thanks for reading, and I'll see you on our next adventure!