The ZK Chronicles: ZK in the Wild

We're finally here! The end of the road.

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 part 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.

Our final dance begins now!

Web Traffic

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

Whenever you open a website in your browser, it's very likely that the URL starts with https. We don't need to go into full detail about what that means though; all you have to know is that https is a protocol for transferring documents, and we're really interested in the "s" more than anything else here. That "s" comes from yet another protocol which sort of supercharges the standard http, called Transport Layer Security, or TLS for short.

Formerly known as Secure Sockets Layer, or SSL.

Long story short, TLS establishes a symmetric encryption key (called a session key) between the sender (server) and the receiver (client). This allows the sender to encrypt the data being sent, which travels encrypted, and then gets decrypted by the receiver. And this means that only the sender and the receiver can ever read the data.

And as good as that sounds, there's an unexpected issue around it: no one else can read the data.

Why would that matter though? I mean, TLS succeeds at exactly fulfilling that purpose! The whole point is that a third party watching an encrypted communication is not able to understand what's going on!

Okay, allow me then to propose a situation. Imagine we want to prove to somebody that we have received a specific piece of data from a specific server. Think about it for a second: if the receiver just shows the information, how do we know where it came from? And since the communication is encrypted, we can't even pin it to a particular message exchanged by the sender and receiver!

Framed like this, it sounds like an interesting problem... but I'm gonna take a guess here and say you're still wondering why would that be useful at all!

As it so happens, the applications are broader than they might seem at first glance. And this is especially true when you don't need to share the actual information that was transmitted!

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

Now suppose you want to apply for a loan, but you have no traditional credit history. You however have your Uber track record, and that might qualify you for a loan. So one thing you could try is to generate a proof that Uber's servers attested to your activity, and maybe you can present it to a DeFi lending protocol to unlock better terms, all without handing over your account credentials, your full ride history, or anything beyond what the proof certifies.

zkTLS is the attempt to cater for this: to turn a private TLS session into a verifiable statement.

Perhaps the cleanest approach to date is MPC-TLS, used by TLSNotary. This works by adding a third and new role into the mix, called the notary, whose job is to co-witness the session and later attest that the transcript is genuine. That is, their job is not to read the contents, but to guarantee they weren't fabricated.

The core idea revolves around using multi-party computation, splitting the TLS session key between two parties: the prover (which is essentially the client, who receives information from the server), and the notary. Neither holds the full session key, so the notary can later attest: "I was part of this session, so the prover could not have forged this transcript."

Click to zoom

An alternative is the proxy approach, used by Reclaim Protocol: a proxy sits between you and the server and verifies commitments to the TLS session without seeing plaintext. Simpler to deploy, but requires trusting the proxy.

So where does the ZK come in, you may wonder? That's the interesting part! If we build this correctly, then we could use this attestation to prove that some specific field belongs to the server's response - or even that some field satisfies some property - without having to reveal the full payload!

This is called selective disclosure, and essentially acts as a private oracle: a way to feed certified real-world data into any application, without revealing the actual information. It can enable things like credit scores on a blockchain based on off-chain financial data, or proving social credentials (like followers, ratings, history, etc.) without handing over full account details.

Which is kind of a wild thing to say, considering entire digital economies have been built around data!

But let's not get ahead of ourselves. As nice as it sounds, there are some complications to this matter: for one, the cryptography behind TLS (RSA signatures, HMAC) is expensive to prove directly in ZK, so most current deployments lean heavily on MPC to keep the heavy cryptography out of the circuit. On top of that, because of the threat of quantum computers, TLS itself will most likely need to be updated, which in turn requires an update to this notary layer.

The direction is clear though, and it's definitely an intriguing concept to pursue for data privacy, so I think we might see more of this in the future. For now, it remains a cool but niche idea.

zkVPNs

And since we're on the topic of web traffic, there's another gadget that many of you have probably used in the past: a VPN!

Traditional VPNs work by routing your traffic through a middleman server. Instead of your request going directly to the destination, it goes through the VPN provider first. What this achieves is effectively hiding your IP address from the destination, and encrypting your traffic so your ISP can't see what you're looking at.

So they won't know what kind of memes (or other weird things) you indulge into.

Click to zoom

Sounds great on paper, right?

As always though, there's a catch. There's always a catch. In this case, the fine print is that you're not actually gaining privacy - you're just moving the trust, because the VPN provider sees everything. So you essentially go from trusting your ISP, to trusting some company that pinky-promises not to log your activity.

Which may or may not matter to you, depending on how much you value your privacy!

One older idea to circumvent this is mixnets, which operate by routing packets through a sequence of nodes, with each node knowing only its predecessor and successor. Each node collects packets from multiple senders, shuffles them, and re-encrypts them before passing them along, so an observer watching the network can't correlate incoming and outgoing packets by timing or order. This is what we call mixing: breaking the linkability between "packet entered here" and "packet left there."

This means that no single node can see the full path. And while it works, the problem is accountability: how do you know the mix nodes are actually mixing, and not just logging everything or dropping packets selectively?

And that's where ZK comes in. Nym builds a mixnet where each node generates a ZK proof that it handled its packets correctly: that it received the right inputs, applied the mixing operation honestly, and forwarded the right outputs. Crucially, it does so without revealing the packet contents or the routing path. The proofs are lightweight enough to attach to each packet hop without messing up latency.

The result is a network where you get verifiable privacy: not "trust us, we don't log," but "here's a proof we mixed correctly". Nodes are incentivized to participate and penalized if they can't produce valid proofs, turning the economic layer into an enforcement mechanism for honest routing.

The ZK circuit here is relatively simple: it's not proving a complex computation, just that a specific permutation was applied to a specific set of inputs. The deployment context is what makes it interesting: proofs running at network speed, per-packet, across thousands of nodes.

It's even more of a niche use case compared to zkTLS, but it helps cement an idea worth saying out loud: ZK isn't just for blockchains. Anywhere you need to prove that a protocol was followed without revealing what was communicated, ZK is a candidate tool.

And it's in this same spirit that we 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 a myriad of applications, 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 not even running a model), 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, and ZK is the shieldAI is the sword, and 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? In other words, how do we know the output is correct, even if we don't know the internals of the model?

This is where zkML (ZK Machine Learning) comes in, to try to do a bit better than plain blind trust. The idea is quite simple, really: generate 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: you could use AI to do all sorts of things, and provide proof that whatever the AI spits out is the actual result. For instance, imagine a medical AI that can give a diagnosis for a patient. You could feed it the data, get a meaningful result, and prove the diagnosis is correctly calculated without ever revealing the patient's data!

If we get creative, we could come up with a plethora of applications of this kind. But getting there is easier said than done!

The main challenge is arithmetization. Neural networks in particular are full of non-linear activation functions (ReLU, softmax, or even sigmoids), which are pretty painful to express as polynomial constraints. Even a function as simple as ReLU involves range checks and conditional logic, and we must do this for every neuron - so the costs stack up and constraint counts become prohibitive really quickly.

Which doesn't mean that we can't do anything about it! One promising approach is to use lookup tables: we just precompute the activation function over a bounded input range, and prove that each activation output belongs to a 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.

Once again though, despite this being quite promising, we must be honest about the current state of things: zkML is currently practical only for small models, with a few tens of millions of parameters at most. Proving the inference of something like a GPT remains well out of reach. But the path is set, and given how fast the field is moving, I wouldn't be surprised to see this become practical in the few years!

I guess we'll just have to wait and see.

Private Inference

Let's kick it up a notch then: zkML tries to prove that a model ran correctly (and that's useful in its own right), but what about the inputs? I mean, if you're feeding some 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 is a different kind of problem, and a different kind of beast altogether, as it requires a tool that is complementary to ZK in many cases: fully homomorphic encryption, or FHE for short.

It works like this: instead of sending plaintext inputs, you send encrypted data (ciphertext). The model then runs homomorphically on the ciphertext (meaning it operates on the encrypted data), and returns an encrypted result, so the operator never sees the original data in plaintext! We can then use a ZK proof for the inference process, and that closes the loop for both privacy and correctness!

This could unlock very interesting possibilities, for instance:

• An AI company could prove their model ran correctly on your encrypted medical records.
• A credit scoring agency could compute your score from your encrypted bank history and prove the result, without you ever handing over your raw transactions.
• A government service could verify your eligibility for a benefit using your encrypted tax records, proving the decision was made correctly without accessing your actual income data.

Now, if it sounds too good to be true, it's probably because it kinda is. This is a topic that's still largely in research: FHE is computationally expensive (although it has seen sizable gains in performance in the past few years), and combining it with ZK compounds the cost.

But if it can be done practically, the applications will definitely be there waiting for the big breakthrough.

Encrypted Computation

But we need not content ourselves with only that. Why not take it a step further?

You see, to "operate homomorphically" in the context of FHE really means that we can perform two operations homomorphically, like addition and multiplication. In other words (and as a refresher), this means that whether we operate on the unencrypted data first and then encrypt, or do it the other way around, makes no difference on the encrypted result.

Click to zoom

Read that again. Additions and multiplications. If we can do those, then we can build circuits that can process encrypted data! And we also know ZK can help us prove that a computation was done correctly, so if we put those together, we get something extremely powerful: the ability to prove that an encrypted computation was performed correctly, without revealing any of the inputs, outputs, or anything in between.

This opens up a whole world of possibilities, of which AI inference was really just an example. For instance, smart contracts could consume the results of private off-chain computation with cryptographic guarantees of correctness to update their states. A simple example of this is encrypted balances, where users still use a public blockchain to hold their balances, but since they are encrypted in the ledger, then nobody can understand how many assets they hold!

The most active team building the infrastructure to make this vision a reality is Zama. They build open-source FHE tooling (including fhEVM, an Ethereum-compatible VM running over encrypted state), and are actively exploring ZK proof 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 cryptographic privacy tools converge: FHE keeps computation private, and ZK makes it verifiable.

Again though, it's important to note that the engineering challenge is still steep. But both fields are advancing fast enough that their intersection is becoming a serious research area.

Finally, I also want to mention that FHE goes further than attestation, and it has the potential to restructure the trust model entirely. Zama has also proposed the HTTPZ protocol to extend web traffic itself: instead of a standard TLS session where the server sees your plaintext request, the client sends encrypted inputs and the server computes homomorphically, returning a response the server never saw in plaintext. A ZK layer on top could then prove the server computed correctly on ciphertext, closing the loop on both privacy and verifiability.

So who knows? We might see the internet itself being restructured around this technology someday!

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 transactions: Blockchains are public by design, but private payments were among the first battle-tested ZK applications in the wild. The trick is to record commitments to the transfers rather than the actual transfers, and then use ZK proofs to force two invariants: no coins created from thin air, and each coin is spent at most once. Zcash pioneered this using Groth16, and other projects have explored this approach since.
• Private voting: Semaphore, developed by the Ethereum Privacy and Scaling Explorations team, is a ZK protocol for anonymous signaling. You prove that you're a member of a group (for example, of eligible voters, token holders, or verified humans) without revealing which member you are. You cast a signal (a vote, a message) that's publicly verifiable as coming from the group, but not linkable to you. It's essentially programmable ring signatures, and acts as the backbone of several on-chain governance experiments.
• Proof of identity: Worldcoin scans your iris to establish that you're a unique human, then uses Semaphore-style ZK proofs to let you prove "I am a verified unique human" to any application, all without revealing your iris scan, your identity, or even which ID is yours. It's a curious application: biometric data as the root of trust, ZK as the privacy layer on top.
• Proof of provenance: As AI-generated content becomes indistinguishable from real photographs and video, ZK can certify that an image was taken by a real device, at a real time, without tampering. With this, we can prove that something wasn't produced by a model, without revealing information like the photographer's identity. The C2PA standard is moving in this direction.

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 - and even if it doesn't now, an attacker could collect transcripts today and break them retroactively once the technology is available!

Usually referred to as "harvest now, decrypt later", even though in this case, it would be more accurate to say "harvest now, break 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 (SHA-3, Keccak, Poseidon), 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.

SNARKs, on the other hand, don't have the same luxury. But that doesn't mean SNARKs are 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 still larger than their elliptic-curve equivalents, and lattice assumptions are younger (roughly 25 years of scrutiny versus over 50 for hash functions). But the progress is real, and is likely to only keep accelerating.

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.

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!

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!