SNARGs Book Study Group - Week #5 with Ziyi Guan

Transcript

Hey, so smart. Hello guys, I'm I'm Z, and I'm a PhD student in Alessandro's group. So, today we're going to learn about Kilian's critical. And just to recap, let's see what we learned before the Christmas New Year break. So, the first lecture I'll give you an overview everything that like the background material and uh everything you're going to see in the sessions. And then previous sessions you learned about non-interactive arguments based on sigma protocols and zero-knowledge proofs.

And then just last time the last lecture before the break, you learned about commitment schemes. And in particular the Merkle commitment scheme is going to be the one that turns out to be very useful and important for us. So, I hope you guys still remember what I think it was Giacomo, what Giacomo talked about the Merkle commitment scheme. So, let's see what are SNARKs based on PCPs and why is it called the Kilian's protocol.

Basically previously as you might already noticed that previous chapter names used NARG instead of SNARG. Where this N stands for non-interactive and these are just arguments. But starting from this chapter, we're going to start looking at something similar, but with an actual extra letter S, which stands for succinct. So, previous non-interactive arguments we learned about are do not have succinctness,

meaning that the prover-to-verifier communication and the verifier time are not small enough. So, starting from this lecture, we're going to look at how to compile a succinct non-interactive argument from an information-theoretic proof system together with a commitment scheme. In particular, we're going to learn about Today, we're going to look at probabilistically checkable proofs and the Merkel commitment schemes.

So, to begin with, let's first look at what is or what are probabilistically checkable proofs. I think you learned about interactive proofs before. Just a brief recall on what are interactive proofs. IP It's a proof system with a prover and verifier. Let's say it's for a language L, and prover gets instance witness, verifier gets instance, and they communicate with each other.

Then, at the end, the verifier need to decide whether X is in the language or not. That's the basic IP model. And um Usually, we ask IP to satisfy completeness, which is saying that if X is in L, then verifier and also soundness, which is saying that if X is not in L, then with high probability, verifier reject.

So, that's just a brief recall of what uh you guys learned a few months a few months ago. Um today we're going to look at some another type of proof system that uh we call PCP, probabilistically checkable proof, that also consists of a prover and a verifier, where the prover has input instance and witness again. And the verifier has input the instance. And the goal is for the PCP verifier again to decide whether this instance is in the language or not.

But this time, instead of allowing prover and verifier to have interaction, like IP, this time, the prover is going to send a long string. But instead of the verifier instead of reading every single location in the string, it's going to uh choose some random locations. So, let's say that the verifier is going to sample some randomness row um from the set of all possible randomness, and this row is going to decide whether which locations the verifier look at. So, let's see for example, those are the locations that the

verifier want to look at. Then, this special string that the prover output, once in those that it gets the information on which positions the verifier wants to know the the value of, it just tells the verifier the values the corresponding value at your location. Does the model make sense to everyone? Okay. There's no question, I'll I'll just continue.

So, that's the basic model. Again, the prover's sent a relatively long string. It's normally it's poly- polynomial in terms of the size of X. And the verifier samples some randomness, and according to the randomness, verifier decide which locations in those strings the it wants to look at. And then this string then sends the corresponding values to the verifier. So, similar to the case for IP, we we require PCP to satisfy com- perfect completeness, which is saying again that if the instance is in language, or in other words, if instance witness pair is

in the relation, then for the honest prover, the verifier always accepts. And here, this notation on the on the super superscripts of the verifier, it means that the verifier has oracle access to pi. And oracle access just means what I draw here. It's verifier ask for the the the value of on those locations, and this pi here gives the answers to the verifier. I have a question about that. So, you mentioned that we know that our verifier is not going to read the whole string, and instead they're just going to sample it.

What controls how much of the string they can sample? Based on what you said so far, it seems like this still allows them to just read the whole string. Yeah, of course. There you can construct PCP where the verifier read the entire string, but but then later, like maybe 10 minutes later, we're going to see the connection of PCP with crypto. And then if if the verifier read the entire string, then it loses purpose because There's my I guess my my question is how do we uh how much of this thing that they read and if you're going to come to that later, totally fine. That's just my question.

We it's not that we restrict. So, for for example, maybe let me put it this way. So, let's say that I want to construct I don't know how to write anymore. Construct a PCP for our favorite MP from the language set. That's the goal. Then, I also I will specify that I want the query complexity which is just the the formal name for the number of locations that the verifier look at Q to be constant.

Then, that's how I restrict the verifier's the the number of locations that the verifier to look at to be small. It it's it all boils down to um how your PCP is constructed. And since verifier here is not the adversary, verifier is going to honestly behave. And verifier is like us, it's not the adversary, then it will behave always how is is how we constructed it. Does that answer your question?

Yeah thanks. Okay. So, we were talking about completeness which is uh similar to to IP case and um on the other hand, for soundness, it's also as expected for any instance not in the language. And for any malicious PCP prover, notice that here we even allow unbounded malicious PCP prover. So, this is different from the case of argument. And in this case, no matter what this PCP adversary does, there is it cannot convince the PCP verifier with high probability.

This probability is bounded by epsilon PCP, and we call epsilon PCP to be the soundness error of the PCP string. Okay, and just briefly mentioned like 1 minute ago, for a given PCP, we're interested in several efficiency measures, and this can also show up in the construction of the SNARK in a second. So, the first one we care about is the alphabet, and we always use sigma to denote it. And sigma is the alphabet used to write the PCP string. So, remember that we have this long string, and let's say that it has length L, and it's the PCP string pi,

and sigma is just saying that pi is in sigma to the L. Every location contains a symbol in sigma, and there a total L of them. And Okay, this L already show up, but we we also give the name here. This is the L is the proof length. And the query complexity, which is Q as explained before, it's the number number of locations the PCP verifier reach, and it's according to the construction.

And randomness complexity R is the number of random bits used by PCP verifier. So, as I draw before in this VCP box, I asked the PCP verifier to sample some random string row, and according to this R definition, it's just a string from 0 1 to the R. It's a binary binary string of length R. Prover time, verifier time as usual, PP and VT are the time complexities, or if you're working with the circuit models, the size of the PCP prover-verifier.

And it's not written explicit anywhere, but all those like all those measures like sigma L, Q, R, they can all always be a function of X, which is the instance. So, the meaning of that is that So, let's see let's consider two instances. First instance is a string of length 10, and the second instance is a string of length 100. Then, of course, the prover time and verifier time and all the other efficiency measure should behave differently for those two X X1 and X2, because X2 is just way

larger than X1. So, that's why we say that those efficiency measures actually implicitly they are a function of the size of the of X. And then knowledge soundness is I think you've seen it before as well. Knowledge soundness is just a strengthening of soundness saying that in the case that So, this is a formal definition, but intuitively let's ignore this very difficult equation first. Intuitively, what the knowledge soundness error is saying that every time a malicious prover, an adversary convinces the verifier, then

with very high probability it must have a witness in mind. So, then formally knowledge soundness is saying that there exists a poly-time deterministic algorithm EPCP. This is what we call the extractor. Such that for every instance and every malicious prover P, let pi be the proof outputted by P. And in the case that verifier accept this pi given by the prover, then the extractor the probability that the extractor

doesn't successfully output a valid witness, this XW not in R means that of this invalid, this probability is very small. Bounded by kappa PCP and in normally in all the PCPs that we use today, it's it should be negligible in X in the size of X. And why do I say that knowledge soundness is a stronger notion of security than soundness? It's because if we know that PCP has knowledge soundness error kappa PCP, then it definitely has soundness error epsilon PCP that's less than kappa PCP. And this is because that notice that here we we

have this knowledge definition for every instance. And remember up there for soundness, we have X not in the language. So let's look at the case let's look at what happens if X is not in the language. If X is not in the language, then of course the extractor cannot output a witness because by definition a witness such that XW in R does not exist. And then the event that verifier accept is upper bounded by kappa PCP, which is required by the soundness notion of the PCP.

And one last security notion that we care about is zero knowledge. And in this in this chapter, we only care about zero knowledge against honest PCP verifier. And roughly what it is saying is that a PCP zero knowledge if after the verifier read everything it needs to read, it doesn't learn anything about this. So, the prover is able to convince the verifier without telling the verifier um what what's the what the actual witness is.

And formally, this zero knowledge notion is captured by a slightly technical concept called the PCP verifier's view. And it is defined to be first the randomness of the verifier, and also the corresponding queries and answers after running the PCP verifier given a particular proof string pi.

What this is saying is that let's recall how the PCP verifier behaves. So, this is PCP verifier, and it has oracle access to this proof string pi, an instance x. It first sample a random string and then it computes the set of queries they want to make, and then it actually makes the queries. So, verifier's view is just this three things.

And we say that PCP has honest verifier zero knowledge if there exist a polytime probabilistic algorithm S, which we call the simulator, such that for every X belonging R, S is able to simulate or reconstruct the view of PCP. And we the zero knowledge arrow here is ZPCP, which is the statistical distance between the distribution of the PCP verifier view and output of the simulator.

And notice that here, the simulator has only access to X. It doesn't have any access to W. Right, it doesn't know what is the witness. This means that if the simulator is able to simulate the PCP verifier's view, then it means that the kind of the null the simulator's knowledge about W kind of represents the PCP verifier's knowledge about W, which means that VPCP doesn't know anything about W after the interaction.

A- after it receives and queries the the the PCP string. I hope this makes sense. Uh feel free to call me anytime for question. But I think for today's session, I don't really want to focus on zero knowledge too much. I want to get more into the the security of Kilian's protocol. Basically, the big question I want to answer I want to raise and answer today is how to turn PCP into a SNARK.

So, I think according to to to my impression, the audience today is more interested in SNARK, the application of probabilistic proofs. But, now I've told you what PCP and what the model is, it doesn't really seem something related to SNARK because this oracle thing, this pi, how do you even implement it?

And this is because this oracle kind of access, let me maybe show you the picture. This type of oracle access, this proof string should be able to interact with the PCP verifier in an honest way. So, it's almost like this PCP prover commits to this string this proof string, pi, and is written in a stone that no one can change after the prover wrote it. And now the verifier is trying to access it. But, in practice, how do you actually implement it?

There's no good way to implement a PCP. So, that's why we started to consider turning PCP into a SNARK, and this is how the the short answer is what you learned last time, use Merkle commitment. We're able to extract a SNARK. Okay. This is the session is is a short detour for today's today's topic. This is more about next time Micalli's protocol.

And the state restoration game for PCP is not so much different from those for sigma protocols that you learned a few weeks ago. I The basic idea is as before. It's a state restoration. It's what's it useful useful for? It's for Fiat-Shamir transformation. Right? And then basically, Fiat-Shamir is letting the prover PCP prover to rerun verifier for

T times. And state restoration security is saying that even if you are given T chances no adversary can succeed. And state restoration game is just a mathematical way to capture this whole idea behind Fiat-Shamir. They're actually equivalent. So, I'll leave this to either offline reading or next time when Christie explain about the MiCARES

protocol. Cuz it's uh we don't have we don't have all the time and so it's not the most important thing for today. So, today we're going to learn about Kilian's protocol. So, this when you see 16 interactive arguments from PCPs they're always talking about Kilian's protocol. And Kilian's protocol takes an input PCP and a Merkle commitment and its output is not.

Actually, this should be a SNARK instead of SNARK because when PCP has knowledge, the resulting SNARK also have knowledge, so it preserves knowledge. Okay, let's look at the construction first. Do I need to give a very brief recap about Merkle commitment or everyone remembers what it is? Two two things. So, first, can you explain what you were just saying about the SNARK versus SNARK thing? Is it always a SNARK or is it like if the PCP has knowledge, then the SNARK also have

knowledge, making it a SNARK? It's Maybe let me write it. It's if PCP has knowledge, then Kilian PCP Merkle commitment has knowledge. Awesome, thanks. And then, to your other question, which was like should we review the Merkle commitments, my vote is yes, let's spend 5 minutes doing that. Okay sure. Basically, Merkle commitment is a commitment scheme and it has access to the random oracle. I'm not sure what is the notation that others uses for random

oracle. Let's say just for explicitness, let's put random oracle RO as random oracle. So, a commitment scheme is actually a vector commitment scheme, meaning that it takes a vector. Maybe for simplicity, let's take a vector of length four and they want to run it through Merkle commitments and get the commitment. And how does it work?

Merkle commitment is going to compute the random oracle hash for X1 and X2 and also the random oracle hash for X3, X4. And let this be Y1, this be Y2. Then they will set root to be the random oracle hash of Y1 and Y2. So, basically in a binary tree pattern, you just hash until you hash using the random oracle until you reach one single value at the end, and this is your commitment.

And re- Yes, it should be mentioned last time that Merkle commitment also allow for local openings. And what are local openings? Now, let's say Alice wants to open position two. Give me X2. And Bob wants to convince the verifier that uh Bob is going to give X2, the value two, to Alice, but they are not trusted.

Bob is not trusted to Alice, then therefore Bob has to send a proof saying that X2 is actually the value I committed using the Merkle commitment scheme that gives you this root value. So, what does Bob do? It send X2, and at the same time it also sent X1 and Y2. And X2, X1 and Y2 as proof.

And This strikes me as very similar to Merkle trees and obviously it is because of the name. So sorry, I I didn't mean to cut you off, but I'd be interested to hear what is the actual difference because it seems exactly It it's it's just Merkle tree. It's just called the Merkle commitment scheme in this book. So people usually refer to this as Merkle tree commitment, but they're the same thing. So let me just finish this and then Alice will just verify that random oracle hash of X1, X2 and Y2 is actually equal to the commitment.

And by the collision resistance nature of the random oracle, because random oracle is purely random, then this scheme is secure. And also one thing that's going to be useful for us is the extractability of Merkle commitment. Basically, extractability is that if I give you the entire query answer trace for this for constructing this tree. So what does that mean?

This commitment function, this commit function in order to get this final root value, going to compute it's going to query the random oracle with certain amount of queries. And now I give you the the entire trace of this queries this MC makes to the random oracle. Then I claim that there exists an algorithm E miracle commitment that given the trace and recover my

original original vector that I committed to. And why is that? It's also easy to see with this with this uh picture. So if now I give you a bunch of query answer trace meaning that I tell you that this MC function it queried X1 and X2 gets Y1, queries X3 X4 gets Y2 and then it queries Y1 Y2. Then by the order of the query and by the queries makes it's very clear to the extractor that X1 X2 X3 X4 are the things that I'm trying to commit. So that's what we

mean by extractability with respect to the query answer trace. And this is going to be very useful uh for us when trying to prove the security of the chameleon protocol. So that's I think that's enough review. But feel free to to stop me for any question. Is it saying that the the query answer trace is it saying that for I guess any proof you can extract the full list that was committed to? Uh yes, for now I I tell you if I tell you that this trace is all the queries made by this MC function to to get this root then by looking at that I can always get back

to the original vector. That's I committed. Oh thanks. Okay. So, now I think we're ready to look at Kilian's protocol. What is Kilian's protocol? Let me just write this here. Kilian's protocol takes a PCP and a Merkle commitment and it gives you a SNARK. And this is just the all the previous pages that I skipped are a more detailed explanation of Kilian's protocol, but here I'm just going to use this diagram and it's enough.

So, this is the SNARK prover and this is the SNARK verifier. And as always, the prover takes both the instance and the witness. The verifier only takes in the instance. And we start from the prover. What the prover does is the prover invokes the PCP prover with the same instance and witness, gets a PCP string. That's the PCP proof pi. And then it run the Merkle commitment with respect to this F, which is the random oracle, and send the commitment to the verifier.

And then what the verifier does is it sample a PCP randomness rho, which using I don't know. The notation we used before is say random binary string with R bits, and send this randomness to the argument prover. And then the argument prover run the PCP verifier using this instance X and the randomness rho. It computes the locations the queries the locations that the PCP verifier wants to look at, maybe the verifier using this randomness wants

to look at those locations, then it gives corresponding answers by looking at the proof pi. And at the same time for each location Q in Q provides the Merkle commitment Merkle tree root. And it sent the query set, the answers, and the individual proofs to the verifier. And the verifier first check if the Merkle tree proofs are correct using the the algorithm we just recapped. And then it check using those queries and answers given by the prover whether the PCP verifier accept.

So, this is just trying to turn a PCP into something that we can actually use and implement. Instead of having to send this as an oracle, which we don't know how to implement in reality we commit to this oracle. And relying on the security of this Merkle commitment scheme we're able to make sure that after the prover commit and send the root, it cannot change the values in those locations anymore.

So, that's roughly why this scheme is this protocol is secure. Does that make sense? Okay. So So, now we know the the protocol, it's very simple. And we also roughly know intuitively why this protocol is secure. I want to use the the rest of the time to actually go through a proof of security for the soundness of this argument system. The proof for knowledge soundness is almost exactly identical.

So, as I said before, Kilian can be viewed as a combination of PCP and Merkle tree. So, I am going to switch to Merkle tree from now on because apparently this is also what um they use in the book. Um therefore, it means that if I have an adversary for Kilian, then maybe I can switch change them into adversary for PCP and adversary for Merkle tree.

And in this case, by the security of PCP and the security of Merkle tree, I know that those two adversary cannot succeed with high probability, which means that this adversary for Kilian cannot succeed with high probability, which means that Kilian is secure. So, let's see how to work on this um intuition in a very formal way. This theorem 20.2.1 is just a very formal statement of what I just explained before.

The soundness of the argument is upper bounded by the soundness of PCP and the error probability of the Merkle tree. And the I think um okay, I'm actually not sure, but usually when we do this kind of transformation, we take an adversary for the resulting scheme and we try to uh construct adversaries for the underlying crypto or information theoretic objects. We usually call this proof approach as security reduction.

Meaning that going from Kilian, we reduce its security to its underlying components, which in this case is the PCP and the Merkle tree. And how formally how does it work? Given a fixed instance X and a fixed malicious argument prover P for the for Kilian's protocol, we can transform it into a corresponding malicious PCP prover.

And in written in very formal proof probability statement, it's saying that sample the random oracle, the probability that the prover, the malicious prover that I fixed for Kilian, convinces the verifier can be upper bounded by the probability that the PCP prover constructed from the malicious prover. There's a typo here.

This should be the malicious prover with the little tilde. So, this is the PCP prover we constructed from the malicious prover for the argument. Sample the PCP randomness. This prover convinces the verifier. This probability and by definition, if this is a PCP prover, we know that this part is upper bounded by the PCP soundness error. Plus some overhead. In this case, it's the Merkle tree.

So, now that's formally how things work, but the only question left is how do we construct this PCP prover? And this is the algorithm. Here, it looks very long, it's actually easy. We just need to remember a few things. So, as I said, I think 10 minutes ago, Merkle commitment has a very special and useful feature, which is the extractability.

In the sense that if you are if you're given a trace, then there exists an extractor that can tells you what is the vector that's being committed for. And let's say that's this Merkle dot extract is just my Merkle tree extraction extractor. And now given the malicious prover P, again typo here, I want to construct a PCP prover. What I do is I run the argument prover. So, this is the first step. Run the argument prover.

And what the argument prover is going to do is that it's going to query the random oracle. Remember Remember how Kilian's protocol works, right? It's going to first compute the PCP string. And call the random oracle to construct a Merkle commitment to build this PCP string. So, when I run the argument prover, I myself as the PCP prover, recall that the PCP prover is unbounded by definition.

Um Because PCP is secure even against unbounded prover. So, I can simulate the oracle S until the prover gives me a commitment CRT. And as I explained before, let TR trace be the query answer trace for the execution of this malicious prover argument prover. And why is this query answer trace useful? Because this query answer trace just contains all questions those this prover ask to the random oracle

that results in this commitment root. And by this extractor algorithm, I know that from this root I'm able to get the string pi that I committed to at the beginning. It's just this simple algorithm that I explained a few minutes ago that from the root and the each queries here, you can go back to the original vector, which in this case the PCP string.

And then the PCP prover just output this pi extracted by the Merkle tree extractor. In fact, the running time of the PCP prover is not that bad. It's just the running time of the argument prover, simulation of the random oracle, and the running time of the Merkle tree extractor. Okay, and why So, now we see the construction of the PCP adversary from the argument adversary, how does the magic happen?

Why is it what why does this construction give us what we want? So, let's see. This is the probability we want to bound. So, again, given adversary, we want to bound the probability that this argument adversary successfully convinced the argument verifier. And by definition of Kilian's protocol, this angle bracket, meaning the interaction between argument prover and argument verifier, is equivalent to the fact that the PCP verifier underneath accept and the Merkle tree check function accept.

Where this Q and A and proof are given by the argument adversary. This equality is just by construction of the Kilian's protocol. And now, recall that the goal is to do security reduction, meaning that reduce arg soundness to PCP soundness. Here, we we don't have PCP. Although syntactically we do have PCP verifier showing up, but everything that we've been running and working with they're still in argument regime. So, we have to introduce something that allow us to invoke PCP soundness. So, what do we do?

In this case, we introduce We introduce the PCP adversary we just constructed, this one, to the picture. Now, let's look at this probability event. It has event one, event two. Both of them needs to be true. Now, by the law of total probability, I can add another event.

In this case, this event three is true, and in this case event three is false. And if I sum these two probability by law of total probability, those two are equal. This and that. And now let's look more carefully at what is this event. This new event I add is now I just introduce a PCP string. Notice that these two lines is exactly the execution of the PCP adversary we have in this page.

Here. And now I ask the PCP adversary to give me a pi according to the argument adversary and I run the rest of the experiment just as usual. Now the event I add is that this pi extracted by the Merkle tree extractor given query set Q is equal to exactly A, which is the answer given by the prover. And the complement of this event is of course the answers given by pi, the one extracted from Merkle tree extractor, is not equal to the answer given

by the argument adversary. So now I claim that actually we already get what we want. So this first line is upper bounded by epsilon PCP X. The PCP submission error. Why? If we Which color should I use? Maybe this one. If we ignore this line then these two line is equivalent event wise to the probability that the PCP given pi X row is equal to one.

Why is that? Because we know that pi queried at locations inside the set Q is equal to A. We also know that VPCP given this randomness, it's only going to So, if this is my PCP string and those are the set Q, then my verifier is only going to look at those locations. It's not going to look at other locations. Then the fact that pi give the same answer is A here means that if I just give my PCP verifier oracle access to pi and the same randomness, it's going to be one.

And in this case, I can rewrite this probability to be probability V pi PCP X row equal to one under the experiment that under the experiment that pi is from PPCP, which is constructed from the argument prover row from 01 to the R. And now even syntactically, this match perfectly with the PCP soundness definition. So, it's upper bounded by epsilon PCP.

The first line we're able to bind bondage by epsilon PCP. And now, let's look at the second line. So, what is the second line? Second line is that this Merkle extract algorithm give you a pi that's different from what's the prover actually give. Which means that the prover commits to a string pi and it runs the Merkle Merkle commitment scheme to get to root with some Korean sir trace.

And now, if extractor fails to give whatever the prover gives. Which means that either the prover is able to open one location that's different from what it actually committed to, or extractor fails to give you the correct to give you the correct vector underlying. In any case, this event is bounded by the security of the Merkle tree. So that complete the proof and give us the theorem here.

Epsilon argument is upper bounded by epsilon PCP and the Merkle tree arrow. So, that's almost everything I want to cover today. I mentioned that So, in this session, it's a almost the same proof, but it's what we call the adaptive soundness, meaning that here, instead of the the difference that we allow Adaptive means that we allow the adversary to choose instance.

So, recall that previously in non-adaptive soundness, we fix the instance X not in the language outside. But now, in adaptive soundness, we we allow the argument adversary to choose the instance inside the prover of the inside the six experiment. For example, if it were adaptive soundness here, the prover is going to output X as well. But that it's it's easy to show that adaptive soundness implies non-adaptive soundness.

But for the case of Kilian, it doesn't really make a difference. As you can see, the proof almost is almost identical, except that now you just have more things to keep track of inside your probability statement. And then for knowledge soundness, I think I really encourage you to read this paragraph, but after reading this paragraph, you would just see that the security analysis for knowledge soundness and soundness for Kilian's protocol is almost identical.

And this also has been a very active area of research. At least me personally, I'm curious on whether there is a much simpler way to analyze the soundness of Kilian's protocol that's significantly different from knowledge soundness, and whether there in some case, for some PCPs, there would be a gap between soundness and knowledge soundness. And for zero knowledge, okay, there is actually one thing I want to say about zero knowledge. So, I am not sure if

it was mentioned in previous lectures. Zero knowledge has two different definition. There is honest verifier and malicious verifier. If you've never heard about malicious verifier, it's it's okay. I just want to emphasize that there is a difference. And for Kilian, we know that if PCP has honest verifier zero knowledge, then Kilian PCP Merkle tree also has honest verifier zero knowledge.

But for malicious verifier, it's not the case. And in fact, it was proven that by Barak Lindo I think 2008, if you are interested, I can send the link to this paper later. But it's proven that for constant All right. round argument, malicious verifier zero knowledge and proof of knowledge, which is just what we call is knowledge soundness,

cannot coexist. So e if a constant round argument has malicious verifier zero knowledge, then it cannot have proof of knowledge. Or it cannot have negligible knowledge soundness error. And vice versa, if a constant round argument have negligible knowledge error, then it cannot be malicious verifier zero knowledge. So, there is this gap between honest verifier zero knowledge and malicious verifier zero knowledge. And I just want to mention that. And that's basically it for today. Next time, you're going to learn about how to So, today we focus on interactive argument, meaning that here, Kilian's protocol,

it has some back and forth between the prover and verifier. Uh but in practice, people care more about the non-interactive version of it. Uh so, next time you're going to learn about how to transform this interactive argument into a non-interactive argument. So, I hope you enjoyed it. And I guess Okay. And feel free to to ask questions later and Someone's typing a question in the chat. Let's wait until they they Someone's typing in the chat that may be a question. So, hang for that.

Okay. Sure. And yeah, I think people are always welcome to ask in the Snow Script Discord channel. I think you and your team are pretty attentive to questions there as well. Okay. He has stopped typing in there. Well, I think we can call it. Thanks again. Okay. I think then thank you and um maybe see you in later sessions. Sounds good. Thanks. Bye.