A bizarre dispute has broken out between two long-time friends, Penny and Victor. Victor, who is fully colorblind and sees the world in grayscale, has become increasingly suspicious that this “color” thing isn’t real at all — he sadly hasn’t been the same since he fell down a color-truther pipeline on TikTok.

Penny has grown increasingly frustrated with Victor’s stubbornness and outright refusal to believe her when she says color does in fact exist. The more Victor denies her claim, the more of a rift forms between what had once been an inseparable bond…

Luckily, Penny is a bit of a math wiz and has recently stumbled across an exciting new tool in the cryptography field, zero knowledge proofs.  After spending some time reading up on the topic, Penny, determined to repair her friendship, formulates a plan to use this new concept to reinstill Victor’s confidence in the existence of color.

Penny’s strategy unfolds in a series of three steps:

1. Setup: Penny takes two flowers of distinct colors — one red, and one blue — which she’ll use as props in the proof. There is one caveat: she does not want to reveal what the colors of the flowers actually are (don’t ask why).

2. Challenge: Penny asks Victor to hide the flowers behind his back, and for him to choose to either switch them between his hands or keep their positions unchanged. Then, Victor must ask Penny whether a switch has occurred.

3. Response & Verification: Because she can see color, Penny is obviously able to correctly say if a switch took place without revealing the actual colors of the flowers. After one round, Victor remains skeptical. What if Penny just got lucky? After all, there is a 50% chance she could’ve correctly guessed whether he switched the flowers. To test this, he repeatedly switches — or doesn't — the flowers, asking Penny to identify each change. After ~200 repetitions, the probability of Penny answering correctly by pure luck is less likely than picking a specific atom from all atoms in the universe. Victor is satisfied, admits color is real, and vows to delete his accounts on the online color-truther forums.

Voila – Penny has just completed what’s known as an interactive zero-knowledge proof. For those of you who have… zero knowledge on the topic…

a zero knowledge proof (ZKP from now on) is a way of proving a claim without revealing any additional details about the claim itself. All zero knowledge proofs must satisfy three key properties:

1. Completeness: If the prover (Penny) is honest, they will be able to convince the verifier (Victor) of their claim 100% of the time. In our example, this is true because Penny can genuinely see color.

2. Soundness: If the prover (Penny) was dishonest, it’s impossible to trick the verifier (Victor). In our example, as the number of challenge repetitions increases, the probability of tricking a verifier quickly approaches a value so astronomically low, that we practically refer to it as zero.

3. Zero Knowledge: The verifier (Victor) becomes convinced of the prover's (Penny’s) claim, but gains zero knowledge of anything they didn’t already know about it. In this scenario, while Victor is convinced of Penny’s claim, he remains clueless about the specific colors of each flower.

This understandably sounds a bit contrived, as this proof requires a colorblind person and physical flowers. What else can ZKPs prove?

As it turns out, quite a lot. In fact, a ZKP can be used to verify any computational problem in the NP set, which is a vast set of problems that, given an answer, can have its correctness verified relatively quickly by a computer. The extensive range of the NP set makes ZKPs incredibly general-purpose; applicable to nearly any problem a computer can be faced with.

This is still pretty abstract, so let’s look at a more concrete example. What if we applied this concept to something like our passwords? What if, instead of providing our actual password to log in, we submit a ZKP proving that we know our passwords, without actually entering them anywhere? This would be an exciting prospect, as it would be miles more secure than our current global standard of handling our sensitive passwords, and could even eliminate phishing (the most common cybercrime) overnight.

Understanding this (relatively) straightforward example will be beneficial for us going forward, as it’ll make it much easier to have some intuition to reason about how we might extend ZKPs to other areas.

Disclaimer: there’ll be some math ahead. It’s included to show exactly how the proofs generally work, but if math isn’t your thing, don’t worry about getting bogged down by the formulas. If you choose to skim or skip this next section, the one crucial takeaway is this:

We can emulate Penny’s strategy of introducing randomness to convince Victor of her claim, but instead of achieving this by randomly switching flowers, we’ll randomly switch variables around in a specific type of equation.

So what’s the actual procedure we need to follow to prove we know some general statement (like your password) without revealing it? Surely we can’t keep relying on switching physical flowers back and forth.

First, we need to understand a bit of mathematical background context: we’ll be taking advantage of a specific kind of problem in math known as the discrete logarithm problem, which can essentially be stated as the following:

Given a prime number p, an integer y, and an integer g, you cannot solve this equation for x, without guessing and checking numbers by brute force:

$y = g^x \bmod p$

Essentially, for complicated reasons we won’t get into, this equation cannot be simplified, and you can’t calculate x, even if you know g, y and p. (Side note: the mod operator is a modulus, or the remainder of a division)

For example, let’s say our discrete logarithm problem has prime p = 5, integer g = 3, and integer y = 1. If we want to find x, we literally have to guess until we find it.

$\text{x = 2} \rightarrow (3^2) \bmod 5 = 4 \text{ (wrong) } \ \text{x = 3} \rightarrow (3^3) \bmod 5 = 2 \text{ (wrong) } \ \text{x = 4} \rightarrow (3^4) \bmod 5 = 1 \text{ (bingo!)}$

In this example, g, p, and y are all small numbers, so we can feasibly find x, even just by guessing. However, if we chose a really big p, and a really big g, we’d need to guess so many numbers that even the world’s most advanced supercomputers would need thousands/millions of years to find it. But of course, if you chose x in the first place, you can instantly prove you know x by plugging it into the equation and verifying the result.

In the above equation, x is an integer, but it’s important to remember that to a computer, everything is ultimately represented by an integer. Therefore, if we’re able to use a ZKP to prove we know x without revealing x, we could directly apply that proof to any statement that a computer understands, since x could be our password, or any form of digital data at all for that matter.

To accomplish this, we’ll need to follow a process that looks quite similar to what we just observed between Penny and Victor. Here’s the proof’s structure:

The prover wants to prove that, given some known p, g and y values, they know an x that solves the discrete logarithm problem for those values. To begin, the prover generates a random integer r and computes the following:

This is also referred to as the commitment step, a cryptographic term that refers to committing a value in advance while concealing key information. Here, the commitment C conceals the random value r, as the verifier cannot compute r due to the discrete logarithm problem. C will later be used to ensure the integrity of the proof, specifically to confirm that r hasn't been altered.

To verify that the prover knows x without learning what x is, the verifier asks the prover for x+r. The prover responds, and the verifier still can’t deduce x, because r is random and concealed by C. However, the prover’s response to x+r can be used to prove they know x. This is because (if we revisit exponent simplification from school)...

$g^{x+r} \bmod p \ = (g^x \bmod p \cdot g^r \bmod p) \bmod p \ = y \cdot C \bmod p$

Equations aside, all this means is that if the prover's x+r response correctly fits into the equation y*C mod p (an expression only containing public values), then the prover must know x. Great!

Unfortunately, there is actually a way to cheat this process. A dishonest prover who does not know x could start the proof by committing to:

instead of the value they’re “supposed” to commit to, which again is:

Then, when the verifier asks for x+r, the dishonest prover answers by only providing r, which will fool the verifier when they plug that value into the equation to see if they can get y*C mod p, because…

$g^r \bmod p \ = y \cdot g^r / y \bmod p \ =y \cdot C \bmod p$

So, we need a way to be sure that the prover starts the proof with the commitment C that they’re “supposed” to. We could do this by making the verifier ask what r is in addition to x+r, but this would defeat the purpose of the ZKP, since the verifier would be able to deduce x!

We need something better, and for this, we can be clever and emulate Penny’s strategy: rather than have the verifier ask for x+r and r, we should have them ask for either x+r or r.

The reason we can pick one of x+r or r to ask for is because a dishonest prover can either prepare to provide x+r or r, but not both, meaning they’d have to guess which one to prepare for in advance. For example, if they want to prepare to provide r, in the first step they’d commit to the C value they’re supposed to:

$C = g^r \bmod p$

which allows them to respond correctly when asked for r, but then they’d be unable to provide any x+r value to satisfy this equation:

$g^{x+r} \bmod p = y \cdot C \bmod p$

Conversely, a dishonest prover could prepare to provide x+r by committing to this:

$C = g^r / y \bmod p$

allowing them to cheat a correct x+r value, but then they’d be unable to provide a valid r value.

Does this pattern look familiar? It should – just like in Penny’s example with colored flowers, a dishonest prover has a 1/2 chance of guessing whether the verifier will ask for r or x+r, but as this process continues, the likelihood of continuously fooling the verifier decreases exponentially. In contrast, an honest prover will correctly respond to every single round.

Let’s revisit our checklist to confirm that this is indeed a zero knowledge proof:

1. Is the proof complete? Yes, because an honest prover who knows x and selects r can always correctly provide r or x+r when challenged.

2. Is the proof sound? Yes, because a dishonest prover’s chance of tricking the verifier approaches zero as the number of rounds increases.

3. Is the proof zero knowledge? Yes, because the verifier gains zero knowledge about the value of x, thanks to the discrete logarithm problem’s properties.

There we go! We have a generic interactive zero knowledge proof that allows a prover to prove they know any data value x, without disclosing it.

This is nice, but there’s actually an optimization we can make here. In the above proof, the prover and verifier communicate back and forth over many rounds, with each round having a 1/2 chance for a dishonest prover to guess correctly. Depending on how sure the verifier wants to be, it can take many rounds of challenges to complete the proof. What if, instead of many rounds with a 1/2 probability, we could condense this into a single round with a 1/N chance (a really big N) of a dishonest prover guessing correctly?

This is achievable through what’s known as Schnorr’s protocol. We’re going to be once again leveraging the guarantees of the discrete logarithm problem (i.e. you can only find x by guessing and checking), but this time we streamline the proof as follows:

Same as before. Given some publicly known integer g and prime p, the prover generates some random integer r and computes:

$C = g^r \bmod p$

This time, rather than randomly asking for either r or x+r, the verifier introduces a new element: they calculate their own random number z, send it to the prover and ask them one question — what is zx+r?

As it turns out, the following is true:

$g^{zx + r} \bmod p \ =\text{(many steps)} \ = C \cdot y^z \bmod p$

This is good for us because it means that once the prover provides zx+r, the verifier can plug it into the above equation, and if they get C*y^z mod p with C, y, z and p as public values, they can be sure that the prover knows x.

In the previous proof, the only way for a dishonest prover to pass a verifier’s challenge is to correctly guess if the verifier will ask x or x+r, and prepare a passing response. It is significantly harder for a dishonest prover to pass a verifier’s challenge in this proof, however, because it requires that they correctly guess the random value z picked by the verifier. If they somehow did guess z correctly, they could commit to a naughty C value:

$C = g^r / y ^ z \bmod p$

Then, when the verifier asks for zx+r, they’d respond with r, which would trick the verifier because…

$g^r \bmod p \ = g^r / y^z \bmod p \cdot y^z \ =C \cdot y^z \bmod p$

As you may notice, this is basically the same trick a dishonest prover could play in the previous proof to provide a passing x+r value. Luckily, we can eliminate this threat easily. In this proof, the probability for a dishonest prover to pass the challenge is no longer 1/2^n, but 1/z, so as long as we ensure that the set of values z could be is huge, 1/z can be near-zero just like 1/2^n, allowing us to comfortably end the proof in one single round.

Tired? Good, because we can push this even further. Thus far I’ve made sure to mention that this is an interactive zero knowledge proof, i.e. the prover and the verifier must actually communicate back and forth in real-time for the proof to work. This has natural drawbacks, such as it requires both parties to be online and connected at the same time, not to mention that if you want to prove the same thing to N people, you’d need N interactive proofs.

As you may have inferred, there is such a thing as a non-interactive zero knowledge proof, which allows the prover to generate one proof, which they can then distribute to an unlimited amount of verifiers, with no back-and-forth interaction needed.

The crux of the previous proof is that we rely on the verifier to challenge us with some random z value and ask us for zx+r. We still need this random z value in our non-interactive proof, but we don’t actually need the verifier to give it to us — we can generate z ourselves in a provably random and unbiased way, ensuring it was not hand-picked.

The non-interactive proof starts off in the same way as all the others:

The prover generates some random integer r and computes (you guessed it):

$C = g^r \bmod p$

Instead of waiting for the verifier to challenge us with a random z, we use a Fiat Shamir heuristic to generate it ourselves. This heuristic works by relying on a cryptographic hash function (like SHA256) as a “random oracle”.

The reasoning behind the Fiat Shamir heuristic is this: a hash function is deterministic, meaning it consistently produces the same output from the same input, but hash outputs are also completely unpredictable. So, we can assign z = Hash(C), a hash of the initial commitment C. Since C is based on a random r and cannot be changed once created, Hash(C) provides an unpredictable value that can be used as our random z.

The prover packages three values: (zx+r, C, and z) into a bundle, which acts a self-contained proof that can be sent to unlimited verifiers, who each only need to check two things:

$\text{1. } g^{zx + r} \bmod p = C \cdot y^z \bmod p \ \text{ , and 2. } Hash(C) = z$

If both hold, the proof that the prover knows x is considered valid, even though the verifier and prover didn’t have to interact directly!

There we go — that’s the last of the math I’ll put you through. What we have distilled here is a working non-interactive ZKP that allows us to prove we know anything (that can be represented as binary 1s and 0s) without revealing what it is.

The above math highlights the basic principles of ZKPs, but the overarching field of zero knowledge cryptography (proving things without revealing those things) is accelerating rapidly. Researchers are constantly pushing the space forward with new proving systems, efficiency gains, and clever cryptographic tricks.

In other words, there is a lot more complexity to the field and things quickly get way beyond the pay grade of a humble enthusiast such as myself. I am not able to speak on the moon math behind Groth16 proving systems, elliptic-curve pairings, KZG commitments, nor can I explain the nuances between a zk-SNARK vs a zk-STARK yet (it’s hard)!

So, let’s instead pivot and talk about what we might be able to accomplish with this new tool. The world we live in today does thankfully have some privacy & encryption capabilities, but there’s one big caveat: all private data still eventually needs to be revealed to someone (service providers, sources of authority, etc) so they can verify the data. Sounds obvious — but now, with ZKPs, this is actually no longer true, as ZKPs allow for validation of data without revealing the data itself.

This leads to one simple realization — our secrets online can now be truly secret in a way that was previously impossible. With enough care and creativity, we can use this realization to create systems that usher in a new era of online privacy and a new way of interacting online. This could, in turn, fundamentally shift the web’s power dynamic away from centralized sources, and towards individual users, as they’d be able to protect themselves and retain their autonomy in an unprecedented way.

The design space opened up by this new cryptographic primitive (truly secret secrets) is vast, limited by little else than our own creativity. People have lots of ideas, but for now, I want to explore a handful of them that are the most salient to me.

So, our old paradigm of privacy no longer needs to remain king: we now have the power to leave the days of secret sharing behind us. We can directly verify information amongst ourselves without revealing the info. Great! Now what can we do?

Let’s begin with an example we’ve already touched on — proving credentials (like passwords) without providing them.

Our current model of handling passwords is, frankly, absurdly insecure given how incredibly sensitive the information is. There are two main flaws:

1. Every time we type in a password and send it over the network, there’s a chance for a listening attacker to intercept the message.

2. Every service you have an account/password with must store a hashed (encrypted) version of your password in their own private database. If there is a malicious employee or an external hack (very possible), these encrypted passwords can be stolen and run through ever-improving password crackers, capable of Terahashes / sec (1 trillion password guesses per second).

This system worked reasonably fine in the 1980s, back when password cracking was infeasible since computers were about as powerful as a TI-84 calculator today. In today’s world of nearly infinite cloud computing power, though, it leaves us with a terrible security issue. For password management, we still live in the 1980s, building systems that jeopardize a great deal of our sensitive data.

A ZKP password protocol would neutralize both of these two major flaws:

1. Users would no longer send their passwords over the network, but merely a response to a challenge about the password, from which an attacker cannot derive the password itself.

2. Applications would no longer need to store hashed versions of users’ passwords in their databases, but rather registration values from which they can generate challenges for the user, removing the traditional target for password cracking.

Sounds great — indeed, the Secure Remote Password protocol, which implements this exactly, already exists. Sadly, we don’t seem to want to make a meaningful effort to do this, primarily due to inertia and the longstanding acceptance of the traditional password system as the way things have “always” been done.

Hopefully, though, we will eventually capitulate and migrate to this ZKP procedure, eliminating phishing (the single most common cybercrime) overnight, drastically reducing the incidence of cracked stolen passwords, and leaving attackers empty-handed with a massive electricity bill.

Time to get a little more creative. As AI becomes increasingly sophisticated, the proliferation of AI-generated media will become increasingly indistinguishable from authentic media. We’re already seeing glimpses of the havoc fake AI-generated media can wreak: scammers are using hyper-realistic human voices to steal funds and perpetrate identity theft, while realistic and provocative AI images can exacerbate the (already terrible) online misinformation levels to wild new heights.

In a world where it’s becoming harder and harder to tell what’s real online and what isn’t — how can we safeguard ourselves?

One practical way we could try to address this is by embedding signing keys in our hardware, turning it into attested hardware. Cameras, microphones — you name it — could be equipped with newly embedded chips that automatically attest to the authenticity of the content they capture. This would allow any piece of media, be it an image, audio clip or video, to be captured with verifiable authenticity by embedding metadata within it that proves properties such as (but not limited to):

• Device model and serial number

• Timestamp and geolocation data

• Settings of the device at the time of capture

• Depth sensor data, allowing us to verify that the media comes from an authentic 3D scene, and is not just a picture of a picture (relevant for images/video)

• Other sensor data, like ambient temperature, light conditions, even air quality or humidity at the time of capture

In fact, Sony has already started implementing this into their cameras. This is a step in the right direction, to be sure — but this approach taken by Sony presents pretty significant challenges, like the fact that it isn’t privacy preserving whatsoever, and that everything falls apart the second you make any modification to the captured media. That is to say, the moment you resize an attested image, or trim an attested audio file, its original digital signature is immediately invalidated, rendering the whole process largely ineffective, as it only works on the original raw data.

The real world demands flexibility in its ability to edit raw media (via techniques like grayscaling, blurring, splicing, etc) for both stylistic and practical purposes, which is where ZKPs offer us an interesting solution. With ZKPs, we can ensure the validity of an edited image or audio file without revealing its original content, ensuring privacy and security.

For example, we could take an image captured by an attested camera (like Sony’s Alpha 7 IV), and use a ZKP-enabled image editing software that generates a proof for each edit, asserting that the image has been edited, and that it’s legitimately derived from an authentic, signed original. This proof would be embedded in the image’s metadata, verifiable by anyone to ensure its authenticity, while simultaneously preserving the privacy of the original data.

This isn’t just a theoretical possibility, either. Recent experiments demonstrate the feasibility of generating ZKPs for 30-Megabyte images in less than a second. These proofs are remarkably compact, adding a measly 400 bytes to the edited image, and can be verified almost instantaneously by, say, a web browser.

And of course, this technology isn't limited to images alone — it can be done for other media types like audio and video. Doing this for huge video files that can reach hundreds of GB+ remains a challenge, but promisingly, the efficiency of generating and verifying ZKPs is rapidly improving, so it’s not crazy to think that this will be feasible in the near future.

So hopefully, the upcoming and existing AI-powered trust crisis can be thwarted to some degree by ZKP technology, so long as we move to putting signing keys in our hardware as a new standard, and create some clever ZKP-enabled editing software, and socially accept the valid proofs as a way to discern authenticity.

Many blockchain advocates laud their transparency and full “auditability” as a huge plus; something to generally be celebrated. It’s true that on most blockchains (like Ethereum and Bitcoin), literally every single thing that has ever happened in the network, including all existing accounts and their balances, is fully visible to anyone who cares to look. This is great and is exactly why blockchains were made in the first place right?

No — this is not a great thing, and while blockchains do have characteristics worth being excited about (digital permanence and leaderless consensus), this is not one of them. Ironically, there is a common trope that Bitcoin is good for anonymous payments, but the truth is quite the opposite — all transactions are publicly visible within the network, and while Bitcoin addresses are pseudonymous, it’s an absolute breeze for any mildly sophisticated actor to map a Bitcoin address to an individual, making Bitcoin a horrible option for people who want private payments.

In fact, the fully open nature of blockchains is actually a great argument to not use them. After all, why would you, as a reasonable person, be comfortable with broadcasting the full scope of all of your private data for the whole world to see?

Most blockchains today are public, not because there’s some magic rule stating that blockchains have to be completely open and fully public, but because implementing privacy on them is hard, and it was simplest for early blockchains to just skip that part back when they were first created.

To illustrate why it’s hard, consider first how “privacy” is implemented on most apps today. When you use Instagram for instance, the reason you cannot view other people’s private profiles is because Instagram owns all of that data, and is (understandably) withholding data pertaining to other accounts’ sensitive information from you. From the POV of Instagram, though, all activity is fully visible, and no privacy exists.

If you’ve read my other article on why blockchains are powerful:

then you’ll know that I unironically believe “““web3””” should happen, and that blockchains like Ethereum allow us to build apps that wrap around autonomous protocols (both non-financial and financial) that inherently have no single entity with the power to dictate its state.

Unfortunately, however, this property leaves blockchains with a privacy paradox: if nobody controls a blockchain protocol, and nobody has the power to withhold any of its data… how can we have privacy between individual users? How can we implement privacy on something like Ethereum without compromising its unique characteristics of leaderless consensus and digital permanence?

Of course, I’m gonna say the answer is ZKPs, but to illustrate why: let’s consider a straightforward scenario, where someone wants to implement a social graph protocol as public digital infrastructure on Ethereum (like Farcaster and Lens, which are early attempts of this).

This could be cool, as the protocol could be wrapped by many independent software clients who’d share the same underlying social graph, allowing them to interoperate while still implementing their own custom features on top. To give a more concrete example, this Ethereum social graph protocol would let social apps build on top of it and interoperate in exactly the same way that email clients like Gmail and Outlook are like custom “apps” that all build on top of the SMTP protocol, which allows them to interoperate while maintaining their own special features.

This would be a nice anti-monopolistic force because users of clients that implement the social graph protocol could easily port existing followings elsewhere if a single client decides to mistreat them. Conversely, if you don’t like how today’s social apps behave, your options are to abandon your graph entirely, or begrudgingly stick around. I’m digressing, so see my other article for more detailed rambling about why blockchain protocols could be beneficial.

However, there’s a glaring problem with this hypothetical social graph protocol as it stands: it’s totally impossible to implement privacy features like say, allowing users to set their “following” to private. This is because in an Ethereum social graph protocol, adding and removing followers would be represented by a change to the Ethereum’s overall state, and Ethereum’s decentralized consensus comes from the fact that state changes get propagated to everyone in the network, who each updates their state copy under one key condition: the state change must follow the protocol rules.

This is where we run into trouble. Sure, we could just encrypt the parts of the social graph protocol state pertaining to everyone’s following list, such that each list could only be decrypted with the specific user’s private key, but then it would be impossible for changes to the encrypted state to be verified by the rest of the network. And if our social app doesn’t allow for privacy, that’s kind of a non-starter, so we’re stuck in a catch-22.

Luckily, we can have it both ways with ZKPs — we can simply submit a ZKP proving that the state change we made followed protocol rules, without submitting the unencrypted state change itself!

Taking the social graph protocol as an example, say that Alice wants to follow Bob on this protocol. When she clicks “follow”, a ZKP would be submitted to Ethereum asserting that “the encrypted state of Alice’s following list was abc123, then Alice made a valid change to follow someone, and now the encrypted state is xyz456” while exposing zero knowledge on the new follower. That ZKP would then get propagated to everyone else in the network, who’d update their copies of Alice’s encrypted state upon verifying that proof is valid.

Voila — we have a simple example of how we might implement privacy features on a blockchain app. Public blockchains are a bug, not a feature, and is a massive issue holding blockchain applications back from being useful for real people. Luckily, ZKPs are how we patch a fix, which is why ZKPs have understandably become a massive part of the blockchain design space, something that will only continue as time goes on.

There are other cool things ZKPs let us do that I didn’t touch on in depth because this post is getting too long, such as:

• Verifiable AI & ML model outputs: OpenAI could use ZKPs to prove to users that some ChatGPT response really did come from GPT4 and not GPT3, while keeping their special sauce of the model weights private

• Preserving the privacy of data during AI model training and inference, e.g:

  • Training AI models on sensitive medical data without revealing sensitive information about the patients themselves using ZKPs

  • Allowing AI models to provide responses while keeping the sensitive info of an input encrypted with ZKPs (such as when a model evaluates sensitive patient test results)

• Private payments: protocols like ZCash use ZKPs to enable truly private payments on encrypted transaction data and are considered technically superior to non-ZK alternatives like Monero

• Princeton researchers designed a protocol using ZKPs that can prove an object is not a nuclear weapon without revealing its contents

• ZKPs can be used to prove vote decisions without revealing info about the voters

• ZKPs can be used to prove you do indeed have a girlfriend who goes to another school without revealing who she is

The possibilities seem endless, and we could go on and on with the brainstorming. But that’s it, for now. It turns out that the simple realization that we don’t need to share secrets anymore has some pretty cool secondary effects.

What makes cryptography special is the inherent asymmetrical power balance that comes with it. It can be described as a "defensive" technology, creating scenarios where successful attacks are nearly impossible, but defense is near certain. For example, it’s trivially easy to make a cryptographic key that likely couldn’t be cracked even if all the world’s superpowers teamed up (a good quote).

ZKPs epitomize this dynamic by fundamentally altering the interaction between knowledge and verification. In a digital world dominated by entities that aggregate and control information, ZKPs level the playing field, allowing “smaller” entities like individual users to securely interact with larger systems without surrendering autonomy.

Thanks to those who made it all the way through! Hopefully in the years/decades to come, we’ll see some cool things built using ZKPs. The field is growing rapidly, and there's seemingly always more to uncover, with each new discovery potentially paving the way for new possibilities. We are just scratching the surface of what's possible, and the journey ahead will likely be exciting and unpredictable.