Episode 309 - ZK Jargon Decoder with Nico Mohnblatt

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. So, this week we are doing a bit of a special episode for you. In it, Nico from Geometry Research and I are doing the ZK Jargon Decoder episode. So, you know Nico as my sometimes co-host of the show.

The episode is is inspired by the ZK Jargon Decoder website that Nico created, as as well as a live session that we hosted to kick off ZK Hack. So, we decided to record a version of this for the show as well. The ZK Jargon Decoder is Nico's live document where he defines terms and concepts in ZK, and we cover some of these topics for this episode, and generally offer a bit of an intro to the field of zero knowledge. The thing that is a bit unusual about this one is that we actually used visuals, so slides and some graphs. So, while the ZK podcast is usually primarily an audio-only show,

uh you may want to head over to the YouTube channel to watch this one to really follow along. And while you're there, maybe you want to subscribe. We have other content from our events, as well as the ZK Study Club videos over there, so you might want to check it out. So, we aimed to be quite accessible to the folks who are earlier on in their ZK learning journey, um but in true form and classic form, we did a couple times go down the some sort of rabbit hole and went a little deeper than we meant to on some of the topics. Still, I'd say we continuously came back to higher-level concepts, and I would call this episode quite introductory.

So, yeah. Let us know what you think. If you like this and want us to do another session, leave some comments in the YouTube video or on Twitter. Now, before we kick off, Tanya will share a little bit about this week's sponsor. Launching soon, Namada is a proof-of-stake L1 blockchain focused on multi-chain asset-agnostic privacy via a unified set. Namada is natively interoperable with fast finality chains via IBC and with Ethereum using a trust-minimized bridge. Any compatible assets from these ecosystems, whether fungible or non-fungible, can join Namada's unified shielded set, effectively erasing the fragmentation of privacy sets that has limited multi-chain privacy guarantees in the past. By remaining within the shielded

set, users can utilize shielded actions to engage privately with applications on various chains, including Ethereum, Osmosis, and Celestia that are not natively private. Namada's unique incentivization is embodied in its shielded set rewards. These rewards function as a bootstrapping tool, rewarding multi-chain users who enhance the overall privacy of Namada participants. Follow Namada on Twitter @namada for more information, and join the community on Discord, discord.gg/namada. And now, here's our episode. Today, Nico and I are doing a special episode. It's called a ZK Jargon Decoder session. Um the goal of this is to bring up some terms that are often used in ZK

land and define them in plain English. Welcome Nico. Thanks Anna. So, I think most of the audience is familiar with you. Uh Nico is sometimes the co-host of the show, but I mean, I think the last time you actually introduced yourself was over a year ago. So, why don't we just quickly remind folks what you do? And maybe you can tell us a bit about Geometry Research. I am a cryptography researcher. Um so, I look into protocol designs, uh proof systems, how do we make them secure, um, analyzing other people's systems and make sure those are secure as well.

Um, and I guess building the latest and greatest in the crypto papers. Nice. Um, as in not the ones I write, but building other people's papers into code. Um, and so right now I work at Geometry Research, um, where this is kind of the research team that you might have known from Geometry. Mhm. but we are now spinning out into our own organization and opening up collaborations beyond the scope of what we had so far.

Amazing. So now let's talk about the ZK Jargon Decoder. This is an earlier project. Yeah. Like when did you first start creating the ZK Jargon Decoder? So this was a few months into, um, me starting at Geometry. Okay. Yeah. So what time frame is it? Has it been around for about a year or or under that? This would have been, I think around just before summer 2020. All right. not 2020. 2021. Okay.

Or 22. I don't know. Time is how long have you been here, Nico? Yeah, I I don't know. I Is this what happens when you work in ZK? I think so. Time Time stops. yeah. Making sense. I forgot. Anyway, whenever I joined Geometry, that was February of some year, and then just before summer of that year was when I did it. Got it, got it. Okay, let's tell people what the ZK Jargon Decoder kind of was originally. Now we're doing a ZK Jargon Decoder session, but it's kind of an extension on something that exists. So yeah, what is it? Yeah, so it was this collection of definitions for words that I often came across and often came across in different contexts and sometimes with different meanings.

So it was stuff like I would read through, oh, uh, documentation related to Zcash, and they talk about like, "Yeah, we have our private inputs, and we have our circuit, and we have our arithmetization, and we have our witness." And I was very confused, cuz then you start to try to map things like, "Okay, private inputs is part of the witness, but not necessarily." But then you go read someone else's documentation, and they say, "Yes, my witness is the private inputs. Anything else is something else." What about advice? And like all these things were very confusing. So, I decided to just like, all right, write them out, have a little reference guide for myself.

And eventually I thought, "You know what? This might be useful for others." And you published it as a website. Yeah. Yeah. Yeah. With with a very quiet like tweet saying like, "Oh, hey, I'm doing these definitions." And then Kobe retweeted it at the time. Yeah. God bless. And then I think we put it in ZK mesh, too, that month. So. Yeah. Yeah. Kind of went a little ZK viral, I guess. But um I thought of it when I first thought I thought of it as like a glossary of terms, but I know that you've you've kind of corrected me on that, where it's like it's not it's not a finished thing. It's like a live document, right?

Yeah, and I try to be careful about calling it a dictionary or glossary, because when you do that, people then expect everything to be exactly right and exactly perfect, like almost encyclopedic, which is not the goal here. I'm trying to be more informal, more practical. Yeah. Like yes, there there will be some weird edge cases where my definition doesn't really match uh the term, like especially if we're talking about like very mathy objects. Like if you ask me to define elliptic curves, you know, in a very practical way, um it won't be super precise. But at least we'll get a sense of what it means and how to talk about it.

And maybe that's why like even at the start of this interview, I we talked about or at the start of this episode, I've basically said um that it's kind of like in plain English, like in terms that people who might not be that deep in it or aren't studying it would still somehow be able to understand. It's not It's also not fully plain English. Like there is some assumption on your your understanding of math or your familiarity with some math concept, but usually it will be like either end of high school or beginning of an undergraduate degree kind of level.

Nice. For some additional context to folks joining us, we actually yesterday hosted and a kind of a live version of this session. We did it as part of ZK Hack 4 and it was really good, but also quite chaotic. Like originally we were going to actually use that version for this episode, but then we thought like after after the session we thought, "You know what? We were kind of trying to take questions from the audience. Also, the audience's questions about topics sometimes came later. So, it we ended up jumping around a lot from topic to topic. We thought, "Why don't we sit down and do this again kind of in a little bit more of a pre-planned way where we can go through these topics Yeah, a little bit more structured."

I mean, I had so much fun yesterday and it was amazing having so much audience participation, but it also meant for me that I sort of got caught into the the wind of it and like the whirlwind of like, "Oh my god, all these questions coming into chat like I have to be super quick with my answers." For sure. Um and I think I went for speed over clarity sometimes. Yeah, I also as as the kind of other person like you know, on stage with you, I was trying to like listen to your answers so that I could maybe ask another follow-up question, but I was also kind of managing a lot of these questions coming in. So, I was a bit distracted.

ZK multitasking is hard. But yeah, this time around we are just the two of us and we're going to be going over Some of the questions will be similar to what we did yesterday. So, there is a video out there. You're welcome to see both of them, but I I you don't need to. I think you can also just watch this one. Um some of them will be similar to that, but I know that there were a bunch of topics we didn't get to cover, and so we'll also be talking about those. So, why don't we kick off? Yeah. So, I think we're going to start where you start uh with the ZK jargon decoder on the website, which is The first question is like, what does it mean to prove when we say that word in ZK? What are we doing?

Yeah, and the reason I had that was I was writing up definitions without having this sort of intro, and I found that I needed this context to really explain things. Um and I couldn't have just one article where I put all the context and people go to as in if I just kept the one word one definition format. So, I thought, all right, let's have a bit of a broader thing. So, what does it mean to prove? I have slides still from yesterday. Um And so, what I started with was you know, in mathematics, a statement is either true or false.

And the game we want to play is to decide whether statements are true or not. Mhm. And to make things, you know, more more concrete, I was giving this example like statement one, the number 54 is even. So, that statement, you know, you can listen to it is simple, and we can very quickly decide whether it's true or not. Totally, cuz you're looking at one number and one rule, basically. Yeah. Yeah, yeah. And the nice thing is like the question, is it even? It doesn't matter how big the number is, you can solve that very easily. Like if I give you a number with 50 digits and it ends with a four, you can tell me, yeah, of course it's even. And you can prove it to me.

But if I give you this next statement, like statement number two, the number There, I'm going to read this out if you're listening to the podcast. 25,890,323 can be factored. So, can that be factored? So, if we look at it, you know, we have a few rules from high school that we remember like okay, it's not even, so we can't divide by two. Um we can probably add all these digits up, see if it's divisible by three, but it won't be. Um and I can tell you cuz I came up with this number, so I know how it's made.

Um and so this statement is actually hard to decide. If you look at it, the best way you have to figure out whether it's true or not is to try to come up with the numbers that make up 25,890,323. And that's basically just trial and error. Best you can do is trial and error. But the proving part of this, like is the proof then just like when you have those numbers, that's proof that you that it can be factored?

Exactly. That's like how you could prove. Yeah. Without having you do all the trial and error, I can convince you right now that this can be factored just by giving you the numbers. Yeah. So, my proof is all right, the numbers 4,567, so 4,567, and the number 5,669, when you multiply them together, you get this big 25 million number. Mhm. And yeah, feel free to take out your calculator, fact check me. Um so, my proof is these two numbers, and your work as someone verifying the proof is just multiplying them together and seeing if it matches.

This is a lot less work than doing the trial and error of factoring yourself. Yeah. Mhm. So, this is very nice, and this is what we call in complexity theory NP problems. So, problems where it's hard to solve it on your own, but if you're given a candidate solution, it's easy to check that the solution is right. So, that's what it means to prove, is to give this extra information that allows you to decide whether statement is true or not. So, here the proof is just these numbers and you can verify blah blah blah NP problems. There is a bit more jargon that's associated to these statements.

So, here you saw like our statement number two, the number 25 million blah blah blah can be factored. We could use it also as a fill-in-the-blank sentence, right? The number something can be factored. Mhm. And you can fill that with other somethings. And again, we can evaluate is the statement true or false. So, in that case, we have all this jargon here. So, the number 25 million 890,000 was a specific instance of the decision problem. Recall that the decision problem was deciding whether the statement is correct or not.

Mhm. 25 million was a specific instance. We could have different instances. Five would be a different instance. And that one you can tell me quite quickly. I cannot factor it. In our case, the proof or the witness was this list of two numbers. Mhm. And it witnesses the fact that the instance Yeah. made a satisfying statement, right? Made a true statement. Okay. So, that's why we call it a witness. It's like if we had the instance on its own, we can't judge it. But then we can call the witness to the bar. And once we have the witness, we know whether or not the instance is In this case, the witness is the proof, right? It is the

Okay. Yeah. And we'll see in a second why you might not want that. Like sometimes my witness is private. Or sometimes it's too long to be sent as a proof. Okay. That that kind of motivates the need for different proof systems, different ways of proving. Mhm. This is what we call the trivial proof system. I send you the witness, you check that it's correct. It's trivial because it is a proof, but I haven't done work, right? I've just sent you the witness and you decide. So, yeah, instance witness, very useful. These are the ones, relation, language, and predicate are jargon that you'll come across if you're reading more technical material.

Um I don't think we should cover it on air, but I do recommend that going through the article in the jargon decoder, and it's nicely explained, in my opinion. Well, I do want to Maybe I could just highlight the predicate, because I was going to ask you about like the factored I guess that's Yes. Is that the predicate? Like the the action, the thing that you're trying to prove is the predicate of the proof? So, exactly. We have that statement, the number 25 million, blah blah blah, can be factored. If I now make it into a fill-in-the-blank form, so the number something can be factored, this is no longer a statement, because until I fill that blank, I can't decide whether it's true or false.

True. Okay. So, these sort of fill-in-the-blank sentences, or almost form statements, we call those predicates. Hmm. Are predicates ever in the form of like a function? Yeah, absolutely. Well, this is a function, right? The number something can be factored, and I can fill up the something with whatever inputs I give to my function. Is Would it like the X would be the empty thing in a in a function example, and then everything else would be the predicate potentially? Yes. And the output would be true or false.

Cool. Yeah. But yeah, this brings us nicely to, since you were asking like, oh, uh there there's no ZK here, right? We're just sending the witness. Mhm. And you're absolutely right. This is the trivial proof system, and this is sometimes my uh witness is private, and I don't want to reveal it. Like if this were um let's say we're doing RSA, and these are like these factors have to stay secret. I don't want to prove it to you in this way. Um or what if, and this is a an example I took, my proof was super long.

And we have this Wikipedia article of like list of long mathematical proofs. Oh my god. Yeah, and some of these are like 500 pages, 200 pages, 250 pages. Um and this was one of the motivating examples actually for what we call proof systems. So, can we do better than sending the witness in full? And the answer is yes, otherwise you know I would be not doing this. Uh one way of doing this is having interactive proofs. And you can think of this as uh you know a detective, the verifier is the detective, and the prover is a suspect.

And so, the verifier is going to ask questions. Like, where were you on the night of the 15th? Can anyone corroborate your alibi? What color is your car? I don't And the prover is going to answer these questions one by one. And at the end, the verifier is just going to go through the answers and make sure that the prover kept her story straight. Yeah. But in this case, like the thing that's going back and forth is it's still the Is the witness going back and forth? No, it could be something else. So, you know when how we were talking about like 200-page-long proofs. Yeah.

Right? I can ask you oh um have you read X and Y paper that was related to the problem you're trying to solve? Yes, okay. Um do you know how to solve this problem? Yes. Are you aware of this theorem? Yes. Okay, with these things, I am pretty sure that your reasoning is fine. Hmm. But I don't need to read through 200 pages of proof. I see. So, you're but you're using like you're extracting something then from the predicate in a way, right? Or From Or are you extracting something just from the witness?

Kind of, yeah, from the witness. From the witness, okay. Yeah. That is if my interactive proof is not zero knowledge. That's the the beauty of zero knowledge proofs is we can have these interactive discussions where I'm convincing you that I know a witness or that a witness exists. Mhm. But I never say anything remotely linked to the witness. Yeah. That's what a zero knowledge proof is. Is we have this interaction or we can even do it non-interactively, but nothing I say reveals even an ounce of information about the witness. In the case so I'm going to throw back to a very old example for ZK is like the Where's Waldo example.

Like what are the different pieces of that one? Yeah. So It's interactive cuz there's like the person who's proving it to someone and there's person who's looking at the proof. I think it's a non-interactive proof, but you have a setup. So the setup is uh the we have the book with you know the the page that we're trying to solve. And I know that you have nothing else you like you don't hide little Waldos in your pocket or whatever. Mhm. That's our setup. And we also have uh a big sheet with a hole. Yeah. That's our setup. And then you as a prover, the only thing you do is you get behind that sheet and you place the book such that Waldo appears.

And then I as a verifier can look at that proof. So I can look at Waldo through the little peeping hole. So you just clarified that that's not interactive. I Yeah, I think it's non-interactive because there aren't back and forths going on. Oh yeah, okay. So in my the way I understood it was like an interaction between two parties, but you're saying like you actually the interactive proof has to have that like back and forth and back and forth. Yes. In kind of extra information for it to be called interactive. Yeah. In the same way um if you're speaking to someone, but they never answer you there are two parties involved, but it's kind of a a non-interactive conversation.

I guess yeah, what you're saying here is like the proving is just going one direction. Like the person verifying never sends anything back. Exactly. We say interactive when the verifier sends something back and the prover has to send something again. Got it. Okay, okay. Makes sense. Yeah. So that was one example. The nice thing about interactive proofs and what we do often is like we start with a problem, a big problem. We the proof is sent something, the verifier asks a question, and at the end of that we now have a similar problem, but it's a bit smaller.

Mhm. And we can keep making it smaller and smaller and smaller until it's easy to solve. So that's sort of logically why interaction is powerful cuz we could get to like get to smaller and smaller problems every time. The other way of sort of avoiding long proofs and lots of time to verify them is to have what we call probabilistic proofs. So this is a different approach and this is a kind of a all right, let's relax our requirements a bit. We no longer need to be 100% sure that the proof is correct.

Like I am willing to sometimes accept a proof that is wrong. So what I can do is either make sure that this probability is very small. Or if it's too big, we can repeat the proof a bunch of times. In the case then of a probabilistic proof, is your proof close to correct? Or is it Do you know what I mean? Like does it doesn't it sort of mean that the proof itself is slightly off? Um it doesn't have to be. It's more that it just means once in a while I will read a wrong proof, a completely wrong proof, and think that it's completely right.

It's not just a a closeness thing. It's really like sometimes the verifier gets unlucky. All right. And yeah, the nice thing about doing this is that we don't have to read the whole proof, right? Like I get to just read part of your proof and I get I then decide whether it's fine or not. And I guess is there's a sort of a threshold of probability that you accept? Like or is it like Yeah. you sort of said you could it's okay to, you know, accept a wrong proof once in a while, but like is that is that going to give you a percentage wrongness or percentage rightness somehow that you're aiming for?

Exactly. Yeah, yeah. So, some of the very old proofs used to have like a 50/50 chance. Okay. But, you would do it a bunch of times. Like, we'd repeat it like 20 times. Okay. So, for a cheating prover to win this 50/50 20 times is extremely unlikely. I think this is the billiard ball example. So, this is the one where you have the two balls. Okay. You put them behind your back and you're supposed to like what is something like you're proving I forget like one of them's blind, I think. But, anyway, I'm going to do I'm going to butcher this, but it's like there is It's always like like or okay, here's what it is. You're the blind friend, you put your like you have a red ball and a and a blue ball in your hands, but you

can't see them. But, you're asking your friend in front of you to prove to to to tell you if they're different. That's the whole thing. So, you put them behind your back and you pull out one and then you put it back behind your back and you switch it, you pull out another and the person is telling you it's red, it's blue, it's red, it's blue, it's blue, it's red, like Yeah. Okay, okay. So, they would only be able to keep track of the ball. Yeah, you do it enough times so that you know that they're different colors because your friend could never have predicted how many like when you switched it or didn't switch it behind your back.

Mhm. Yeah. I think that's the probabilistic proof right? Yeah yeah absolutely. Yeah. Yeah yeah. I think that that example taught me more about probabilistic proof than it did about zero knowledge, to be honest. Cuz it's a weird setup with the like blind friend and the yeah. Anyway. Yeah. Yeah, yeah, yeah, yeah. This But, yeah, so the other nice thing is we can combine both. Right? Like, if you recall interactive proofs and probabilistic proofs, we there's nothing that's excluding one like uh excluding them from working together.

Mhm. And so, what we can do is interactive proofs, where at every round of the proof, the prover says something, and the verifier only reads a small part of what the proof the prover said, and we repeat that. And that's what we call interactive oracle proofs, IOPs. Ah. Which is a very powerful tool, and most of our proof systems today are built on IOPs. So, you just mentioned here IOP, but we often hear polynomial IOP. Yeah.

Um should we maybe talk a little bit about polynomials? Yeah absolutely. A polynomial IOP is even a stricter requirement. So, now we're saying, all right, it's it is a conversation, interactive. Prover says stuff, verifier only reads some of the things that the prover has sent. Mhm. Um but, now we are restricting the prover even further to only be able to send polynomials. Okay. So, the prover sends polynomials, and the verifier gets to evaluate the polynomials at points where it likes.

So, this is sort of like in the in that back-and-forth part, that interaction, like the only the only format that will be accepted is this polynomial format. Yeah. Okay. Exactly. You're still probabilistic, you're still using an interactive setup, but it's just like the form of what's going back and forth is going to be polynomial. Yeah. So, why are we probabilistic? It's because the verifier is not going to look at the polynomials completely. The verifier is just going to evaluate the polynomial in maybe one, two, or three points, like a few points. Cool.

Why do we care about polynomials? Like, why do we like them? Uh it comes from this sort of fundamental like theorem of of algebra, I guess, which is if two polynomials of the same degree are just slightly different, like even one coefficient different, and you evaluate them at a random point, their evaluation is extremely unlikely to be the same. Mhm. So again, extremely unlikely. We get this probabilistic element, right?

Um and so we have this nice test. Essentially, if you give me two polynomials, to check that they are the same, I don't need to read the polynomial info. I can just evaluate them at a random point, see if that matches, and then I'll be like, "Sure, there's extreme confidence that these are the same polynomials." Cool. So that's why we like them so much. We keep talking about proofs here, but there is another kind of topic, which is like arguments. Yes. And I think we've defined proofs pretty well, but like what's an argument and Yeah.

are they different? How are they different? Yeah, yeah. The the famous SNARK. What's what's the arc in there? Oh yeah. So proofs versus arguments. Um and this is kind of it comes down to the security properties. So you know how I said like there's this probabilistic element, or even with a proof proof, like a classic non-interactive, non-probabilistic proof, like can you fool the verifier? Can you send something where the verifier is going to be like, "Yeah, I believe your proof is correct." but your proof wasn't.

Mhm. And so this is what proof versus argument comes down to is who are we protected against? So in the case of a proof, the adversary has unlimited computational power. So I'm I'm pro-protected against everyone and anyone. So a proof is like more it's like very like if it's correct, Yeah. this adversary could throw anything they want at it and there's no way for them to like break it or So the other way around, the adversary can throw as much power as they want. Okay, got it.

They will never be able to prove something that was not true. Yeah yeah yeah. The only way they could is if we're doing a probabilistic proof and the verifier got unlucky. Or if you did a probabilistic proof maybe where you like allow for very like you only need 60% guarantee or something. Yeah, but then we'd repeat that many, many times. Yeah, I know, exactly. So, that's what we're saying in a proof, the only way to fool a verifier is by getting lucky essentially is by having the probabilistic aspect of the proof fail. And that's why we also talk about like statistical soundness.

The only way to beat this is with statistics. Like are there standard probabilistic thresholds that we're using a lot or that like Yeah, like what is it? So, in the literature they say 1/3. Wait 1/3? 1/3 wrong. Okay, wow. That's higher than I'd expect. Um, because with 1/3 you can repeat many, many times until it gets to what we call something negligible. Oh, because it would keep getting smaller because you're 1/3, 1/3, 1/3. Okay.

In practice we like negligible probabilities. That is to say um, if we have some baseline security parameter that we start with um, the probability of you cheating is exponentially small. So, 1 over something exponential. So, this probability very quickly becomes tiny, tiny, tiny. Mhm. And this is what allows us to um, tailor our proof systems to different computational environments.

Let's say, so today we have a certain computational power, but in 50 years we're going to have a lot more. Mhm. Are our proof systems going to be broken then? Well, no, because the probability is a function of how much power the verifier has or how much power the setup has. Um so in 50 years we'll have much more power, but because these much more powerful verifiers will be out there, the provers will have to do a lot more as well. wow. Like the cheating provers will have to do a lot more. Got it. So that's what we mean by computational power. It's not like pure like instant power. Like, "Oh, if I have enough GPUs, I'll you know, break the proof."

It's more like we allow or don't allow asymmetries in the cheating prover and the verifier. In the case of the proof, you don't allow for asymmetry, right? We do. We do. allow for asymmetry. Okay. unlimited computational power. So no matter how much Like yeah, no matter how much power you have, you won't get anything better than the statistical probability of our probabilistic proof. Hm. Okay, now I want to hear what an argument is though. I think we need to hear the difference to to better understand that.

Yeah, absolutely. With an argument it's different. We say that the cheating prover, the adversary, is computationally bounded. Yeah. So it means there is no huge asymmetry between the prover and the verifier. There there can be to some degree an asymmetry. Like if I'm running a setup or an I'm the verifier, um and the adversary is, I don't know, some huge government agency. Not not I'm not naming names, but imagine right? Even then, we think that it should be fine because they are not exponentially stronger than I am. They're only like some polynomial stronger than I am.

I want to go back to those that example though of the verifier and the adversary kind of like as they both get more strong, they're equally more strong. Whereas in the argument, it's bounded. So if the verifier gets stronger, does the adversary stay less strong? Sorry, and maybe I got things confused a bit. With the argument, Mhm. we say the the adversary cannot be incredibly more powerful than the verifier. It can be more powerful, but not like exponentially more.

With a proof, we say it can be. So, in this case, it's the comparison to the verifier itself. Yeah exactly. Okay. Or to the setup. Okay. But I still Okay, so going back, so the proof Yes. the proof you have the power of the verifier, and then you have this unlimited power of the adversary, but you're saying it's so strong that it doesn't matter. Exactly. It'll still be correct because it's so good. The system is so strong that even though the adversary is also in infinitely powerful, it can't beat it.

But in the case of an argument, you're saying actually it's only as It's only strong as long as there's this bounded computational power. Exactly. It's not allowing for just like keep running it as much as you want. Here, it's like actually we're only going to let you run it three times, but this argument will stand. Yes exactly. only run it three times or something. I know it's not maybe rounds, but like as an example. No, no, but yeah, it it makes sense. Okay. I'll give you an example. If you really wanted to break um like a STARK, for example, you would need we've estimated somewhere around like 2 to the 90 or 2 to the 100 hashes.

Like that that is the number of hashes you need to do. And that is more than I guess the number of atoms in the universe or something. So, we've assumed that that kind of power is out of range of humanity today. But maybe in 20 years it won't be. Okay. But our proof systems are such Sorry, our arguments are such that we can tweak them and we can now require, all right, you're going to have to do 200 hashes, 2 to the 200 hashes. Mhm. And for that period of time it will be like just beyond what's reachable.

But then in this case our is a stark I mean, I guess it is. It's an argument. Yeah. Yeah, yeah. Which is the AR. Yeah. Yeah. Okay. So the K is actually of knowledge and we can talk about that as well. I actually I'll show you this little chart that we made for um the live session yesterday. This is like a a 2 by 2 matrix. So the the bottom axis is whether your adversary is bounded or not. So bottom left I have a computational adversary, so one that is bounded in its computation. And bottom right I have a statistical adversary, one that is unbounded.

And the property, the security property that we want to um uphold is to say if a verifier accepts a proof then the witness must have existed. This is what we call soundness. So I'll say it again. If the proof is accepted, then the witness existed. Mhm. And so that is where arguments and proof live. So argument, A R G, not A R K, A R G, gives you computational soundness. So soundness against an adversary that has limited power.

Okay. The proof gives you statistical soundness or people also like to call information theoretic soundness. And why statistical? Because the best way to beat it is with the statistics of the probabilistic proof. The soundness here though, just going back to it, so the witness exists but you don't know what it is necessarily, I guess. No, it just exists. It just exists in the world. There is a solution kind of there is a a proof. Okay. Coming back to our statements from the very beginning, if I give you a a 50-digit number that ends with a two and I ask you, can this be factored?

Well, you can very quickly answer yes. Yes, but I won't know Exactly. I won't know what it is. Yeah. So, in this case, if our proof system or our argument system is sound, you will be able to produce a valid proof. Okay. Or a valid argument. If I wanted you to really know the factorization of this big 50-digit number that ends with a two, I would need what we call knowledge soundness. So, it's a stronger property. And so, this is now in my 4x4 quadrant, bottom we had computational statistical, on the left we have soundness, and as we go up, knowledge soundness.

Um So, knowledge soundness says, not only the witness exists, the prover also knows it. Yeah. And so, that's where the ARK happens. ARK means argument of knowledge. So, argument, computational, bounded adversary of knowledge, knowledge soundness. And we also have proof of knowledge, which is statistical, unbounded adversary, and knowledge soundness. So, the N in SNARK Yeah. is in the knowledge soundness computational realm. Exactly. So, in a SNARK, the prover always knows the correct answer?

Yeah. In a SNARK, yeah, absolutely. Okay. In a STARK, is it also argument of knowledge at the end of it? Yeah. Yeah, yeah. Okay. So, it also falls in that quadrant. So, SNARK, the S is uh succinct, and STARK it's scalable. Oh yeah. But then the ARK is the same. It's argument of knowledge. Got it. In previous presentations and stuff, we have sometimes heard people refer to like SNARGs with a G. Yeah. Are there systems that we know today, like ZK-SNARK systems, or is it like we kind of put them under the ZK-SNARK umbrella, but they're actually soundness and computational, or is everything that we're working on in that knowledge soundness computational realm?

Yeah, we we are usually in the knowledge soundness computational realm. It's It would actually be quite dangerous in a way to have just a SNARK um because it really provides you with a foot gun. Because sometimes statements do need knowledge soundness. So, if I'm asking you to prove that you know uh the private key for a wallet, I need that knowledge. Mhm. I need you to know it because every wallet has a private key. So, the fact that the private key exists doesn't mean anything to me.

True true. So, if you give me a SNARK, that there is a private key for a wallet, that doesn't mean anything. Yeah. So, yeah, we we work pretty much exclusively, at least uh in in the Web3 space, exclusively with SNARKs or STARKs or NARKs. In this knowledge soundness realm. But then, okay, just going back, if you look at the definition of a zero knowledge proof, you have the completeness, soundness, and zero knowledge. Yep. This soundness that we have is the equivalent, right? It's the same It's that soundness. But how come a ZKP can just have soundness, but you're saying like everything we have to do has to be in this knowledge soundness place?

So, it comes from And this is why I like to show this chart or this is why I'm happy I made this chart. Yeah. It's because we do abuse language a bit. And often, you know, we we talk about SNARK proofs. Like, what do I mean by SNARK proof? Like, SNARK already means argument of knowledge. Yeah. Um so, it's just we we sort of abuse language and we say proof for any thing that we send in this way. We say ZK proof, we omit the of knowledge even though it's important. Like, it's it's a bit tricky. But it makes sense that we we can't speak in paper English all the time. We we have to use common English to to express ourselves.

Does the knowledge soundness only exist for kind of the SNARK world? Like, where Like, you know, with those three that I listed completeness soundness and zero knowledge, that's in that like fundamental definition of zero knowledge. Zero knowledge proof, yeah. Yeah. So then where where kind of does the knowledge soundness term come from? I'm not entirely sure. I think it came from this need of proving statements where sometimes the witness always exists and what's important is whether or not the proven you it knows that, okay. Yeah. All right, so it it's from this world then probably. It's from the SNARK world.

Yes absolutely. Okay okay. Yeah, and there's this funny sort of thing like how can I be zero knowledge but also knowledge sound? Like how can I make a proof that reveals nothing about the witness but yet convinces you that I know it? Like there's this this crazy duality. Yeah. What is a proof system? So so far we've talked about a proof but not the thing that we often like, you know, when you hear about Plonck, it's a proof system. Or maybe it's not a proof actually, maybe it's an argument of knowledge system.

Yeah, technically it's technically Plonck is an argument system. Okay. And what do we mean by system? We just mean argument or proof we like to use to refer to the the actual proof, the thing that can be verified. Whereas the whole system, like what is the algorithm for proving? What is the algorithm for verifying? What kind of setup do I need? That together forms the system. Okay. So I sort of mentioned this earlier, the polynomial IOP. Um there's kind of a bigger question there which is like we're looking at this you know proof system or argument system but then we hear about polynomials, polynomial commitments, um polynomial IOPs. Maybe we can talk a

little bit about like what pieces go into these systems. Um actually, while we're still on this chart, I do have IOP and polynomial IOP in here. They are in the sort of statistical realm. So they're in the realm where where the prover has unlimited power and we can design them to either have soundness or knowledge soundness. And you'll see that as we said, we also have SNARKs and STARKs. But maybe people here already know that you can from an IOP get a SNARK. Yeah. From a polynomial IOP get a SNARK. Uh so how does that happen? Why do we have this thing that is statistical and then move into the computational land?

Yeah, that's interesting. Yeah, so that is sort of the this little Wait, let me bring up the whiteboard. This little expression that we see all the time like PIOP plus polynomial commitment scheme. I'll abbreviate this as PCS equals a SNARK. Mhm. And maybe people have seen this on slides with uh you know, a a nice little blender. They show you that you can blend both and get a SNARK. Those are Dan Boneh's. Like that's his stock slide for the polynomial IOP and the polynomial commitment scheme.

Yeah. Nice. So we've already talked about why we like polynomials. So hopefully that gave you motivation for why we have polynomial IOPs. But then the question is how do we make this real? Cuz we said all right, the prover sends a polynomial. What does that mean? And the verifier doesn't look at it, just evaluates it in one point. How do we do that? So in theory, we have what we call these oracles. So right, I send you an oracle. And an oracle is kind of like a little black box. And uh you can ask it questions like, "Hey, evaluate what's inside the black box at five." And it's going to give me an answer.

Okay. But these things don't exist in real life. So how do we mimic these oracles? We commit to polynomials. So polynomial commitment scheme is something where you can commit and it gives you a commitment. And then with the commitment Sorry, you can also evaluate. So it gives you an evaluation. Mhm. And then you can sort of verify. So the verifier can I say all right, I want to verify that this commitment All right, I'll just write com for

commitment. Mhm. evaluated at Oops, sorry. Whiteboard playing tricks on me. Evaluated at the point that I asked for my evaluation. And the evaluation that the prover gave me I want to verify whether this is true or false. Yeah. Something you just said though, so the oracle is sort of this like unknown it's like we're mimicking it. We're using the polynomial commitment scheme as a As a want to be oracle, as a make-believe oracle.

Is it a make-believe oracle or is it like a format, something that you're running something through? I like to think of it as a make-believe oracle. Okay. Like instead of sending you this black box that can magically evaluate the polynomial, I am sending you a commitment. Okay. And there's no magical evaluation. You have to ask me for the evaluation. I'll give it to you. And then from the commitment, the evaluation, you can check whether it's true or false. This is interesting to me cuz like the O being connected to the polynomial commitment scheme is not the first time I'm putting that together that that's what that's trying to do. I've known those two parts. I mean, we learned about that in the whiteboard session, but I don't know if in the ZK whiteboard

sessions, I should say, I don't know that I ever really understood how the two of them work together. I feel like I just learned them independently. Huh. Well, I am glad this helps. But yes, this is why we have these commitment schemes is to replace this oracle. The thing is, we know how to make efficient commitment schemes against bounded adversaries. Okay. And so this is why when we combine a polynomial IOP with a PCS that only works for bounded adversaries, we get something that is an argument.

I see. Okay, cuz yeah, in that sort of quadrant uh image that you had the polynomial IOPs, they live in the proof category. Yes. But when you use them in a SNARK, you're moving them then into the argument or computational category. Absolutely. Are they like a little less strong then because you're moving them that way? Yeah. Yeah, yeah, definitely. We we now have we can't use these against adversaries that have unlimited power. Okay. The other thing I want to point out we use a polynomial commitment scheme to replace the O in PIOP, the oracle.

Mhm. And that's what gives us the argument part of the SNARK. But how do we get the the knowledge part? And this comes from another property of the polynomial commitment scheme, which is is it extractable? From a commitment is it possible to extract the polynomial? If we had access to whoever committed. Like this is this knowledge uh what was it? Soundness. It's like that you could actually know the answer, not just know that there is an answer.

Yes. And it comes down to the fact like all right, if you Anna have produced a commitment to polynomial is it just because the polynomial existed or is it because you really knew the polynomial? Mhm. And that's this extractability property. In the case of a SNARK, you do need to know it, right? So you do like yeah. Yeah, absolutely. So yeah, hopefully that kind of explains. Cool. Okay, one follow-up question here though. Um the polynomial in PIOP and PCS PCS Yes.

are all of the ways that we're making snarks, are they actually always using polynomials? Because I understood fry as not being like really in that category that you couldn't put it under polynomial commitment scheme and yet it's it is often used in that exact role in snark like constructions or starks. Or maybe it's not it wait actually one quick clarification in starks is fry the pcs? So that's that's the funny thing.

Um At first it wasn't. And that's not how it was described. Okay. And then we slowly introduce new techniques and we realized ah this is actually also a polynomial iop plus some kind of commitment scheme. And I'm sort of going to explain a bit more but the way you constructed a a stark in the original like stark paper you don't send polynomial, you send um code code words from error correcting codes. So this is sort of another branch of mathematics. It's you can use polynomials as error correcting codes.

Uh but there are other codes. Um so the prover would be sending code words. So p sends code word. And v would send you know challenges. And p would send more code words. And at the end you have this protocol called ali ali to sort of check that these code words were somehow meaningful with respect to the problem that we had sort of how we would use our polynomial iop. Mhm. And then so this was part one and part two is they used fry.

And fry is fast read Solomon interactive oracle proof of proximity. So the read Solomon is these code words. These are actually RS codewords, Reed Solomon codewords. And Fry was just here to check that did the prover actually send Reed Solomon codewords? So, in the same way with our polynomial IOP, we had this polynomial protocol where the prover sends polynomials and we then define stuff. And then we check did the prover actually send polynomials? With the original Stark paper, we would send these RS codewords and then we would check did the prover actually send codewords?

But then what happened in I think it's 2018 2019, you have this deep technique. And this deep Ali protocol, which deep stands for domain extension for the elimination of pretenders. It's one of those, you know, fun acronyms. Yeah. Um and what that meant was all right, we have these RS codewords. And these are actually they're kind of the same as polynomials. They are polynomials but evaluated over a specific number of points. Mhm.

And with deep what you could do is sort of extract a polynomial from this codeword and evaluate it somewhere else. So, this starts to sound again like a polynomial IOP. I send something that allows you to evaluate the polynomial. Mhm. And then how do I check that you did send codewords? Well, we use Fry. So, this is where the Stark as soon as you introduce this deep technique and this deep Ali protocol, you start actually behaving like a polynomial IOP. And as long as you have some way of extracting the underlying polynomial, you again have some way of compiling your PIOP into an argument of knowledge.

But why did we hear more about like deep Fry? Is deep Fry deep Ali plus Fry? So, you could also say deep Ali plus deep Fry. Okay. You can apply the same technique to Fry. But it turned out that it didn't give you that much gains. Okay. Uh you did a lot more work but didn't get much more security. Mhm. So, we scratched the deep on the deep fry side. But, for the deep Ali part, it gave you a lot more security. So, in this case though, are you saying like on the stark front, the research showed that like if you made it deep Ali, then fry was actually able to work together with it. And that's why people then said, "Oh, maybe we can also start incorporating them into the original snark constructions." Like why why does fry move into the PCS side of things?

Yeah. Cuz you're saying deep Ali is like the PIOP. There's a small link between deep Ali and fry, which is that we no longer apply fry directly to the prover's messages. We apply them to something computed from the prover's messages. Okay. So, where previously with Ali and fry, the verifier would say like probabilistic proof. With every message you sent me, I want, you know, the the fifth little element in that message for all the proofs you sent me. That would have been classic fry. Now, with deep Ali and fry, the verifier says, "I want the fifth element, but what I'm going to do is I'm going to add something to it and then divide something.

And now, only then am I going to run fry." And so, it's this extra bit of work that we realized, "Ah, if we incorporate that extra bit of work with fry, it is now a polynomial commitment scheme." Okay. And it's that in between because like all that got ported back to snarks is the fry part, right? Like deep Ali is not in plonk, right? No. No. No. Yeah. But, deep Ali made us realize that, "Hey, these Reed-Solomon based protocols aren't so different from PIOPs." Okay. Yeah. Interesting.

It's where the pattern matching happened, I guess, in a way. Yeah. Yeah. Yeah. Here fry is being used with that this addition to almost emulate Yeah. Can I say it's emulating a a polynomial commitment scheme or is it a polynomial commitment scheme? So, the the other subtlety, why people like refrain from saying FRI is a polynomial commitment scheme, Mhm. is because, like we said, FRI, the I in FRI, stands for IOPP. Oh my gosh. is the same as before, interactive oracle proof, Yeah.

P is proximity. Mhm. And it turns out that if we are very close to a polynomial, then there is only one. But if we're somewhat far, but not too far, then there are multiple polynomials that I'm close to. Uh does that make sense? No. Okay. Uh What What's wrong with multiple? Or is it good to have multiple? Well, there's nothing wrong with it, actually. And that's that's what we realized. As long as the list of multiple polynomials is small enough Okay. that you can read through them and understand which one was the actual witness, then we're good.

Okay. So, you want a low number, and the problem is the further you get away, there's a lot, but if you keep the proximity low, then you can use it in that context. Exactly. And that's where the trade-off comes in. To keep the proximity low, the verifier needs to do more work. Cool. By the way, now I'm really curious. What is the word FRI then? FRI is an acronym of an acronym. I know it's an acronym, but it's like it should actually be like FRI IOPP. Oh Yeah, wait. So, FRIOPP. Uh no, just FRIOPP. Okay.

Like the I in FRI is like the shortened version of IOPP. That's amazing. So, it's a yeah, FRIOPP. But I think FRI is a better But yeah, just one thing, um when you said what's the problem of having a list, Mhm. when we talk about a polynomial commitment scheme, I want to make sure that you only committed to one polynomial. I want to make sure that you're bound to a single polynomial. Mhm. Whereas, actually, what we need to make this knowledge sound proof, is I don't care whether it was just one or multiple polynomials, as long as I can recover which polynomial was the witness.

And that's the the small subtlety of why people say, "Yes, you can use FRI as a polynomial commitment scheme, but actually in these FRI-based argument systems, we don't. We are a bit more relaxed." It's because we don't care about binding you to a single polynomial, but we do care about being able to extract the one that was the witness. This is very much in the weeds, by the way. Yeah, we got more in the weeds than we meant to. I actually want to bring us a little bit out. We have another topic that we wanted to cover in this particular ZK jargon session. Um and that's all about circuits.

Mhm. So, so far we've been talking about like mathy polynomial commitments and like all of this yeah, polynomials generally. And then, you know, we hear about circuits. Mhm. I think it would be kind of interesting to try to understand like how do those things connect? Yeah. And what is a circuit? So, people like to have this divide of front end and back end of a SNARK. Mhm. Uh so, back end is everything we've been talking about so far, like what is your polynomial IOP? What is your polynomial commitment scheme? And then, front end is how do I go from a real-world problem to something, some polynomial, something that I can prove with my back end.

And so, if we were to draw this out, we'd have real-world problem. And somehow we convert that into a circuit. And we'll see in a second what that is and why we do that and why it is that we can. And then, from circuit, we go to something. So, I put a question mark there. Um and this something we decide. And then, this something we feed into back end. And now we can make our proof. Real-world problem to circuit to something to back end. Okay. Yeah. And this something we'll see in a second that you get to choose, kind of.

What is a circuit? I'll bring up actually the entry that I have in the decoder. A circuit looks like this. Ooh. Yeah, it's like a a little collection of additions and multiplications. They have an order and they have wires going into them and out of them. So, in this example, I I wrote, you know, a little relation up here, Y equals 5 X0 + 3 * X1 + X2. And then I write that as a circuit.

Mhm. So, I have Y equals, so I have Y on one side and on the other side I'll have some things flowing in, the X0s to X2. And you can see that inside my circuit I have these gates, addition and multiplication, and I have these hardcoded numbers cuz sometimes that's useful. The values that these wires can take are usually elements of a finite field and that's a whole other topic. Um the simple terms is these are numbers from zero to some big prime number.

Mhm. And when we get to the big prime, we loop back to zero. Like a fixed number. Exactly. So, there's only a fixed number of things. Or we can do it small numbers as well. We could have people who have studied maybe electrical engineering or computer science will be familiar with uh binary circuits. So, circuits where the wires can only be zero or one. Yeah. Yeah. So, here we allow zero up to some big prime. Got it. And the question like why are we so obsessed with these? Um Like why why this this little diagram? Like what's This was something that bugged me for a while, actually.

Why are we obsessed with these? That's great. But we are, right? Like circuit circuit circuit. Yeah yeah yeah. And it's because we have this result from complexity theory which is any provable statement. So, any If you recall like our very first slide, what is it to prove? It's the statements where solving it yourself is hard, but if you're given an answer, you can check it quickly. Any of these statements can be expressed as a circuit. So, this is why if I go back to my whiteboard, this link here is possible.

It's because circuits are what we call NP-complete. Okay. That is any problem that's in NP which is problems that accept a proof can be expressed as a circuit. Is the back end NP-complete? Yes absolutely. Okay. The back end actually can do much more than proving NP statements. Often we have uh back ends that can prove stronger types of problems. But we don't even know how to deal with those.

So, the circuit is a little bit It's a bit weaker than the back end. Okay, okay. Interesting. Yeah, yeah. Absolutely. Um and then circuits, we still have to go from, you know, these nice little diagrams of gates and numbers and wires into polynomials. And this is where you have a choice, and this is what people call the arithmetization. Ah. And this is one that I find a bit confusing cuz arithmetization can be understood as the process of going from real world problem to back end. Mhm. But sometimes we also use it for this inter- intermediate step between circuit and back end.

Interesting. And examples here we have, you know, R1CS Air Yeah. Plonk. And we can talk about this. That was exactly what I was about to ask was the R1CS. When you show that circuit on the other page, I mean when people have shown me what an R1CS circuit looks like, it looks like that. Yeah. Kind of. It has like the, you know, in inputs outputs. Something happening in inside. Mhm.

There's also a system called Air, which you just listed, which doesn't look like that. Doesn't look like this circuit. Yeah. But it's still a circuit. It is a translation of a circuit, yeah. A different one. Okay. And Plonk does look like that when you draw it, but it has something else, right? Yeah, so Plonk is also a translation of a circuit, but a different one. I mean, the big difference, right, is the gates. Yeah. The mapping from Plonk to circuit is a lot faster. Okay.

So, Plonk is kind of like a table where, let's say our gates only have two inputs and one output. So, left input, right input, and output. So, with Plonk, you write left, right, out. You say, is it on or off? Or you say, what value goes into it? Like five, seven, and 12. And I'm going to say, you also get to choose what kind of gate it is. So, here I'm going to say it's an addition gate. Then I'm going to have another gate that takes in 12, uh 10, and outputs 120. And I'm going to say it's a multiplication gate.

So, Plonk is a table of gates one by one, literally. Unordered one by one gates. And then, they have this thing that they call the copy constraints, where you can say, all right, this value 12 is actually the same as that value 12. Like, my gates are connected. I see. Okay. So, Plonk is very much like translating from circuit to Plonk is easy. You take gate by gates, and then you wire them together, and you're done. Interesting. With Air, you're not allowed to do these copy constraints. You're not allowed to wire things. So, you have to be a bit more careful. But, you also define circuits in this way.

Is Plonk R1CS? Plonk is not R1CS. R1CS is a a different format. Yeah, so in R1CS, can you not make those connections? No. R1CS works differently. R1CS kind of um So, you have three matrices, A, B, and C. A represents all the left inputs to your circuit. B represents all the right inputs. Mhm. And C represents all the outputs. And we say that you also have like this um I call it the menu. Like it's it's a vector Z which is literally a menu of all your variables.

Okay. It is all the inputs. So, if we go back to the circuit, the vector Z is going to be all the wires actually. So, we're going to have the variables, we're going to have these intermediate wires. Mhm. And we're also going to have the output. So, you have this menu Z. And I'll show you in a second why I call it the menu. And we say AZ, so A applied to the menu multiplied by B applied to the menu equals the output applied to the menu. Okay. And why do I call it the menu? Like why do I keep doing this? So, if we look here, we can sort of write it out. We have these built-in numbers five and three.

We have the X0s, X1, X2. And we have the output Y. And we also have some intermediate wires, so I'm going to call them W1, W2. So, if I go back to my whiteboard, I've now written out my menu. And what I can do is with my matrix, sorry, I'm going to rewrite this on the side. By the way, this is a bit not super clean because I'm kind of making it up as I go. But there is a great episode of the whiteboard series where Mary Mallard does this and she shows you how to use our 1CS matrices.

Mhm. And it makes a lot more sense. So, if you're familiar with how we multiply a matrix with a vector So, in this case the menu is the vector? Yeah, the menu is the vector and the matrix will be selecting things. I see. So, when we multiply a matrix by a vector, I do this times this plus this times this. Like I move down it that way. So, I work along the rows of the matrix and down the vector. Yep. And so, if I say, well, I want the first variable, so I put a one on five and zeros everywhere else I have now selected just this first variable from my menu.

By putting in numbers in here, are you kind of defining the shape of what the R1CS looks like? Yeah, I'm deciding, all right, for the first gate which ones of my menu variables go into it. Mhm. So, if I this was my A matrix, this would be my first gate left input. What is the A though again? The A is the input? Yeah, A is left inputs, B is right inputs, and C is out. Okay, cuz like the R1CS will have lots of these circuits or these not circuits, but the the input output input output.

Yeah. So, here you're sort of saying here are the different kinds of inputs we have at different points. Then for first input, here's the types of inputs for the second input, but like they're matching I guess here does it show us the ordering like the bottom to the top of one of those circuits that you just showed? So, recall how Plonk needed to say like this 12 is the same 12 that was here and there. Mhm. R1CS doesn't need to do that because I am always picking the same part of the menu.

If I want two gates to use the same intermediate value. So, for example, in our circuit here I have this output of this multiplication and the other output of the multiplication have to go to Y. Mhm. So, I could say this corresponds to what I called here W1, W2, and Y. So, I am going to somewhere have a constraint that involves W1 on the left. Doesn't involve W2 on the right. I'll have my B matrix that does involve W2 on the right and not W1 on the left. And they've been selected.

I see. And so, it's like they'll match up in a way like cuz like each one of those elements are represented in that graphic that you just showed. And if it has two inputs, then the A and the B will both show up kind of in the correct line. Exactly. Can I see that again, actually? Can we flip back to the Yeah. the circuit again? Okay, so the inputs and outputs, the X Y like the X1 is an input in this case, the menu. Yeah. And if you head back, do you also have each of the like multiply?

So what do you mean the multiply? There's add and like in the case of the circuit, there's actually the multiply. Yeah. So in this case, you have to multiply everything or you have to add everything or can you actually have variations on what you're doing? So this is where R1CS is a bit tricky as a mental model or like if I if I were to print out the R1CS that is equivalent to the circuit, it would take me a bit of time to read through it because I can add variables with just one matrix.

I don't need this AZ, BZ, C to get addition. Okay. I only need it for multiplication. Oh. Yeah, because like we said, matrix vector multiplication, we have row of the matrix, vec and the vector and we match elements one by one and we keep adding them. So we do like in this example, 1 * 5 + 3 * 0 + 0 * X0, etc. So the addition side of it is happening within this and then the multiplication is between them.

Between them, exactly. And this is why you'll hear things like in Groth16, like addition is free. We we are getting in the weeds again. I'm sorry. Yeah, exactly. And I actually I'm not I'm not able to follow it too closely. Um maybe we should wrap up with just a last question and definition is Yeah. constraints. So I think we've done good like we've done good on the R1CS air I mean it's so funny because like Plonk and air air we just sort of like hand waved, but R1CS Yes, R1CS I got into the weeds a bit, but it is a good segue into what is a constraint.

Okay, good. What is a constraint then? So, maybe you've already sort of seen, but in Plonk we said every row of our table is a single gate. And we say that's one constraint, and then we also have the copy constraints on top. So, all these elements that I wired together, that's an extra constraint. So, this two-row table with one copy constraint has a total of 2 + 1 three constraints. Great. With Air, every row can apply multiple constraints.

Okay. So, that's also a thing. And with R1CS, it depends what proof system you're in. Oh. In some proof systems, what matters is how long is your menu. Okay. In other proof systems, what matters is how many non-zero elements you have in the A, B, and C matrices. Hm. But usually when people say constraints, they will just count the rows of the matrix, which can be a bit misleading. How are constraints actually depicted though, because I've seen them depicted more like mathematical lines. Like they look they don't look like circuits. They don't look like matrices either, at least the way I've seen them.

Yeah. So, usually we're saying here are a bunch of variables. Some of them are inputs, some of them are outputs. Mhm. How do they relate to each other? In R1CS, the constraint is we are only allowed to use something that is square. Or we're only allowed to use one multiplication essentially. So, that is one constraint. In Plonk-ish type of stuff, the constraint can be anything we want, because like we said, we can define the gates as we want them to be. Hm. Um So, a constraint is one of those terms that I am very hesitant about writing into the to the dark decoder, because it's it is hard to decode, and it is Yeah.

depending on what system you're in, it has a very different meaning and has very different implications for efficiency. Got it. Cool. Well, Nico, I think we've reached the end of our questions for this particular ZK jargon decoder session. It was our first time I mean, this and yesterday was our first time trying this format. Mhm. I think it I mean, I want to sort of throw it out to the audience. If you liked this and might want us to do another one of these, we're obviously still working out the format, but I feel like having some sort of like video or I don't know, like presentation component in addition to the actual ZK jargon decoder might be useful.

I also do very much recommend that folks watch the ZK whiteboard sessions, which we've mentioned a couple times through this because I almost think like watching the ZK whiteboard sessions or listening to this episode or potentially watching it on YouTube, I think would be potentially something good to do together. Yeah. Yeah, and and we're kind of describing these things in slightly different ways. Some of the definitions are a bit more clear, I think. Exactly. I was going to say it requires a lot of patience to sit through things that you think you know and that you probably do know, but sometimes the person speaking will have like a small bit of insight or a a different way of conceptualizing the same thing and suddenly it might shine a different

light and you might understand something differently. At least I I know I've It's been useful for me. I've learned a lot from relearning material I knew, but it's so hard to get into the mental space of like, all right, let me sit through what a polynomial IOP is for the 50th time. Also, actually, Nico, if people want to contribute or like, yeah, like you're doing a lot of this on your own, but I I wonder if people want to join in. Is there ways for them to help out? Yeah, probably the easiest way, so if you go to the website itself, uh top right corner there's a little like GitHub icon. You can click there and we can start collaborating there. Maybe open some issues or some PRs. Like, happy to keep this collaborative.

Cool. The things that helps the most is if people send in suggestions or things that they really want to learn about. Sounds good. Cool. Nico, thanks so much for coming on. Thanks for having me on. So, I want to say thank you to the podcast team, Rachel, Henrik, Jonas, and Tanya, and to our listeners. Thanks for listening.