Aug 10, 2026 · 57 min · 13 segments
How can you prove that something is true without revealing why it is true? That question gave rise to zero-knowledge proofs, one of the most important breakthroughs in modern cryptography. What…
Shafi GoldwasserGuest
Tim RoughgardenHost
Justin ThalerGuest
So there is another proof system which came a few years after us, but we got published at the same time because we got rejected all the time, called Arthur-Merlin proofs.

But it was a, a simpler notion, both that it wasn't considering lots of rounds, and second of all, that it didn't talk about privacy, and third of all, that Arthur was just someone who was tossing coins, where for zero-knowledge, often the verifier tosses coins maybe, but then they send a message where the prover doesn't know what the coins are, and that's, in a sense, is a, is the power of the verifier.

Much of the, as far as I understand, the applications are more that the prover knows something that the verifier doesn't.

So for example, I prove that I know a password, or I prove that I've signed a contract, and I, I have the signature key.

So it's not so much that it's necessarily that some theorem is correct, but it is that I know the proof of that theorem.

Another thing is that, okay, let's say it started with zero-knowledge interactive proofs.

There were all the complexity theory people who didn't care about privacy, who got very excited about this idea that this interaction allows you to prove harder and harder statements which correspond to a more and more complexity classes from standard complexity theory.

And then, uh, it went even in a much more interesting direction where people said, "Okay, do we actually need interaction?" And it turned out that, uh, it is possible to sort of take a standard non-interactive proof, like just a standard proof, no zero-knowledge, no randomness, no nothing, and to rewrite it in a different sort of in a using some sort of error-correcting code so that now if there was an error in the original proof, the standard classical math type proof, uh, there would be lots of errors in the new one.

And the reason that that was good was it, it meant that you could sort of just probe this proof in a random location, and you would land on an error if there was any error at all.

You know, that opened a whole, um, new dimension to sort of find a new notion of a proof where you could do local checks, you could just poke it in a random place, and you can talk about how much you read, which is a lot less than reading the entire proof, and what is the probability of error.

And, and I think, you know, it was an object that was easier to study for traditional combinatorialists, computer scientists, and so forth.

And that actually leads to SNARKs, right? Because you've got this long proof.

It's too long, okay? And, uh, if you wanna really talk back in the world of applications, where is that long proof sitting? You know, it doesn't sit anywhere.

You'd like to be able to somehow compress it and send it and still have the verifier be able to poke in it and find the error.

And now we go to this world where we have hash functions, and we have these Merkle trees, very complex hash functions where these proofs can be compressed, and yet you're able to kind of poke at them and discover an error with high probability if there was an error in the original uncompressed version.

So there is another proof system which came a few years after us, but we got published at the same time because we got rejected all the time, called Arthur-Merlin proofs.

But it was a, a simpler notion, both that it wasn't considering lots of rounds, and second of all, that it didn't talk about privacy, and third of all, that Arthur was just someone who was tossing coins, where for zero-knowledge, often the verifier tosses coins maybe, but then they send a message where the prover doesn't know what the coins are, and that's, in a sense, is a, is the power of the verifier.

Much of the, as far as I understand, the applications are more that the prover knows something that the verifier doesn't.

So for example, I prove that I know a password, or I prove that I've signed a contract, and I, I have the signature key.

So it's not so much that it's necessarily that some theorem is correct, but it is that I know the proof of that theorem.

Another thing is that, okay, let's say it started with zero-knowledge interactive proofs.

There were all the complexity theory people who didn't care about privacy, who got very excited about this idea that this interaction allows you to prove harder and harder statements which correspond to a more and more complexity classes from standard complexity theory.

And then, uh, it went even in a much more interesting direction where people said, "Okay, do we actually need interaction?" And it turned out that, uh, it is possible to sort of take a standard non-interactive proof, like just a standard proof, no zero-knowledge, no randomness, no nothing, and to rewrite it in a different sort of in a using some sort of error-correcting code so that now if there was an error in the original proof, the standard classical math type proof, uh, there would be lots of errors in the new one.

And the reason that that was good was it, it meant that you could sort of just probe this proof in a random location, and you would land on an error if there was any error at all.

You know, that opened a whole, um, new dimension to sort of find a new notion of a proof where you could do local checks, you could just poke it in a random place, and you can talk about how much you read, which is a lot less than reading the entire proof, and what is the probability of error.

And, and I think, you know, it was an object that was easier to study for traditional combinatorialists, computer scientists, and so forth.

And that actually leads to SNARKs, right? Because you've got this long proof.

It's too long, okay? And, uh, if you wanna really talk back in the world of applications, where is that long proof sitting? You know, it doesn't sit anywhere.

You'd like to be able to somehow compress it and send it and still have the verifier be able to poke in it and find the error.

And now we go to this world where we have hash functions, and we have these Merkle trees, very complex hash functions where these proofs can be compressed, and yet you're able to kind of poke at them and discover an error with high probability if there was an error in the original uncompressed version.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.