Session 4 - ZK Proofs Advanced Systems

Transcript

to this computer. >> Hello. >> Hello. Yes. >> Okay. >> Uh so let me put um just a message on the chat about the session that we are live and everything. Um Bes isn't it one hour later?

Sorry. Oh, >> sorry. I thought your quiz was 1 hour later. >> Yeah, I said so. >> Oh, okay. >> Okay. >> It should not be an issue. Yeah. >> Okay. Just you will pass first then. >> Uh oh. Yeah, I was first I guess already. So >> sir should not be an issue. >> Okay. Um >> we will start in 2 minutes. >> Yeah >> of course that's nice.

Tell everyone the link. >> H >> hello. Um, >> what? >> Uh, by the way, everyone please check Google Classroom um for the attendy and the reading. >> You you are a a teacher uh assistant. Wait.

Okay. S four. No, we are live to s after Monday's session. How are you people? I know that KZG was too intense, but for me actually like my brain still hurts.

Oh, Deisha here. Hi, guys. How are you? >> Hello. Welcome. Good. How are you? >> Good. Wait. Okay. So, I put on the ching. [Music] Okay. Let me pin it. Boom. All good.

Nice. All right. >> So, >> I created attendy. Please check Google Classroom. And how are you? >> I'm good. Thank you. So excited to be here. >> Huh? >> We going to ask so many question. So that's make you feel uncomfortable. >> Yeah. Yeah. Hopefully. >> Yeah. >> Um this is one of my favorite topics um like in the whole world. So >> yeah. Um, >> I constantly hear him about talking Mina. So, I'm so excited to listen. ZK snarks here right now.

>> It was before. >> Yeah, >> that's not fair com or not. >> Oh, no. A lot finished but still doing some projects. Yeah. >> Okay. Yeah. Yeah. With node 101. >> Um, yeah. >> Okay. Okay. Nice. So normally we will be around like 30 39 or 30 3 40 sorry um and um yeah so they will join the >> come after like 10 minutes or something like that few people come that way so >> we then I can start >> yeah and we are also

who is here um who will lead the the second part Um so yeah super excited to to have you both here. Um normally uh we have some courses with Mita uh but not this time. >> Today instructor Kunos he's from Node 101 and former Mina and Yan she's from Starknet Foundation. Today we're going to discuss ZK Snorts and ZK starts. So it is going to be awesome I think and news you can start whenever you feel comfortable >> of course um hello everyone first of all thank you very much for being here today um I will try doing my best today

explaining to you um I have some presentation material so I I'll share my screen um but honestly I thought this more like a workshop so please feel free to drop any questions between or you know you can um continue in a more free way so this is my presentation Um it's not great in terms of color team but yeah I did myself so that >> thank you. Um so first of all um so today's introduction to zk snacks u it's not non it's not formal so meaning that like this is not a fully mathematical introduction you won't describe how they work mathematically apparently you all here are more developer oriented so I guess you are looking more into how you

can use zk and how you can like I don't know um use it in the best way so that like your application can be stronger but we are not necessarily trying to understand all of the mathematical foundations um thus today is more going about at least my session more going to be about like how we can use ZK snarks and why they're important and what is the like most important property of a snark etc. Um so I hope it will be useful. Um these are my contacts. Uh feel free to reach anytime about anything. Um I don't mind. Um so first of all what is a snark? Um so zk snark it's this keywords and I color coded it so I hope you won't forget anymore. Uh so zk is your knowledge. Uh I guess you already know that so I won't explain

what is your knowledge. Uh S is saxent which is today's like main and first topic. N is non-interactive. Uh I guess you already know that but just as a small reminder non interactive means that prover and verifier uh contacts each other only one time. Prover creates something without talking to the verifier and then sends that and verifier can verify independently at any time as many times um they wish. So like there is no ongoing interaction. It's not like defy helman for instance def is an interactive protocol. Um zk snarks are non-interactive and arc is stands for argument of knowledge. Probably you didn't hear that before but basically it's a proof. So like I have a proof that I have some information and this

information is in some specific type. So I already know that you have an introduction to zk. So like from an example let's say I have a proof asserting that my input x is bigger than 15. That's a very simple proof example. I have this proof and it takes input X and it asserts that X is big being bigger than 15. Um it can also do uh like better and more logical stuff like it can assert a Merkel witness that my Merkel root is correct. Um it can assert that I don't know I have bigger than 18 years old. This is the classical example of you know ZK password etc. Um so these are standard stuff that we all know.

Today's most important concept to understand is saxentness and what is being saxent. So let's deep dive into saxent and what is saxent? Uh any questions still here by the way? Okay. So what is saxent? So um when we say something is saxent we basically mean that the proof is growing very very slowly. And what is the proof is growing very very slowly. This means that the proof's size is growing very very slowly and the proof's verification time is growing very very slowly. So that uh in respect to what by the way in respect to the computation size meaning that like let's say that I have creating a proof and I am creating a proof for like proving my age let's say I want to

do more instead of proving my age I want to prove my gender and I don't know my nationality where do I live like all of my previous resident addresses so I want to prove much more so my computation increased it says that even if I compro increase my computation the proof size and the proof verification type should grow much slower than the actual computation itself. Uh but it's not bounded. So that is very important growing very very slowly. It's important by the way mathematically we say it's like pol logarithmic meaning that uh it is much slower than linear but it is not bounded and I believe a very beautiful example is this function here which is 10^ 6* log log n. So as you know

logarithm is not a bounded function meaning that if I take logarithm of infinity that is infinity and I can basically find n as big as giving any logarithm that I wish. Thus logarithm of something does is not bounded is not bounded either. So log of login is not bounded either. By the way everyone here knows what is bounded right? So >> can you explain in a >> of course so I'll show the function. Um so this is my favorite site. Uh I'm kidding but it's really good. So let's say lo log x. So as you see lo log x is growing very very slowly. So if I do like going thousand log of thousand is three. Uh it is login base 10 you know.

And if I go like even bigger I don't know if um log of a million is six. So it is growing very very slowly. And practically you can say that hm I don't think log ever passes a certain limit. So you can actually you know put a imaginary line that the function will never pass and you will say that is my ascented so that this function is bounded. Bounded means that like there is this limit that the function value never passes. But this is not true for logarithm. Logarithm will pass any value. Let's say I want to pass this line right there. Um there's a better way of doing that line. So I'll do that.

I can create a different function. Let's say like y= 5. uh maybe five is too small. Let's say y equ= 100. So and I will zoom in. So as you see that's my asmtote. It's a constant line and it it doesn't pass there but it actually does x to the power of 100 actually y equals 100 line and I know that because like I can solve the logarithm equation. Um and since log x passes a certain value log of log x will pass as well. But log of log x will even grow much much much smaller. And by like slower I mean very very slow. Just to

get a comparison if you look to the 1 million log log x is smaller than one. And for this function to equal 1 you need x to equal 10 ^ of 10. And 10 ^ of 10 is a very big number. um to make a comparison like this function is um less than 2 for 10 to the 70. So let's say x= 10^ the 70 this function is less than two because 10 to the 100 makes two and number of atoms in the universe is around like 10 to the 75 10 to 78. Um so like even for number of atoms in the universe this function is still smaller than two but this function is not bound.

So there is no constant limit that this function is always slower from and I think that's a very good analogy that's an analogy by the way like that's not the exact formula of ck snacks or anything but that's a very good analogy of understanding success success doesn't mean being constant so it's not constant it's not bounded and there's no certain limit but for any practical reason you can assume it to be constant because my computation will never grow enough so that the computation itself passes a certain limitation does make sense still Okay, great. And a second important point. So two important points. One is said that it's not bounded. This is not constant. Very important. Second, it doesn't need to be small. Uh this is

a very um misunderstanding. When we say that something is constant or succent or compact or like any of these small worlds, people think of a small number. This doesn't need to be necessarily true. A function can be very big but still constant. Uh for instance a very simple example. This time I will draw myself. So let's say this is my graph. Uh and I am I will use white. So let's say I have this function and this is constant or like this is not constant but you know this is poly logarithmic.

So it never like it grows very very very slowly. It grows even slower and slower each day. So it's very slow. uh and this function seems also small. It it is growing small slowly and it's also small. Why? Because like here our value is 100 and we say 100 is small. But let's say I multiply this exact function with like 1 billion. Then this function becomes something like that. Now our function is not small. It's actually very big. And maybe my actual computation is this. So for a very very very long time my computation is actually slow um smaller than so my computation itself is faster than um the function's growth speed. So being

succinct doesn't imply being small it just means that after a certain point you will be smaller than a linear function. Um so if one of the functions is linear, a linear function is you know x and one of the functions is like logarithmic log x log x doesn't need to be smaller than x. If log x has a very big coefficient then up to a very big x it can actually be bigger than the linear function itself. That's why thinking zk proofs as efficient or as small doesn't make too much sense. And until very very recently and when I say very recently it's like 10 15 years maybe uh verifying zk proofs were really expensive and we didn't do it verifying zk proofs were succent like snucks are a very old concept snacks are

not new but even though snacks existed they weren't efficient snacks don't need to be succent only they also need to be efficient does this make sense um so I see a question on the chat fractal like one board kind of ble functions. Yeah, fractions are not functions to start with like they are not functions at least on XY because like they actually map multiple values to the same X. So um like it depends on your norm and I don't I'm not sure probably but yes probably they are not because they're I'm not sure but it's not important you can think of simpler functions you know you can you don't

need to go 2D just think of you know um what is a bounded function for instance um 1 /x uh + one is bounded this function will never ever pass sorry 1 /x + 1 uh is bounded. Uh this function will ever never pass one. Basically, you know, uh it starts from one and it's always like going slower and slower and it is bounded between zero and one. It can never pass one. It can never be slower than zero.

You know, you can just play around with functions. Just type in bounded functions. And you know, the site is amazing. As I said, just look the functions here. It's very cool. Now we can for instance look to the previous function I said sorry um x + one. Let's actually um go to the more logical domains. So by the way x is between zero and one. So we don't assume negative x values. So as you can see it's one here and never actually be zero. It can never pass the line. So forests.

Okay. So that was s being saxent. I think that was a good understanding of like why you know being saxent is important. Um and I just said that like okay before this part I want to mention something else. I just said that like until very recently snarks weren't efficient enough. This was two reasons. So once you create a proof there are some metrics that you want to know about. What are some metrics of proofs? Let's write them down. So for instance, the proof size. Proof size is the like size of the proof that I have for some certain computation.

It's in kilobytes, megabytes, I don't know. Um one second for the question. Sorry. So important stuff for proofs. So one is proof size. This is the verification time. Um one is generation time. um one is um generation memory complexity it can be something etc etc. So these are important stops for proofs. And when we say something is succent, we say that the sorry we say that the proof size and verification time are success.

Something can be success in verification time and not success in proof size or you know vice versa. But we us both. So just as a small note yes hat >> um I get the idea of bounded but I didn't understand the saxidness like are we saying bounded functions are suction >> no sin functions are growing very slowly they are like in mathematic we say pol logarithmic >> but they're not >> they are not bounded they are like logarithm >> okay >> logarithm is a very good example of a suent function it is growing very slowly and like it's not bounded >> so suent It means a function that grows really really slowly.

>> Yes. And this function is over proof size and verification time. >> Okay. >> So these two are the things that are growing very slowly. And in in respect to what? In respect to the proof's computation complexity. So you can think this as number of gates in the circuit. You can think like number of assertions we make in the proof. What the proof is proving to be correct. You know you can think more abstract as well. All these are correct. Okay. >> Yeah. Thank you. >> Any other question? It's okay. These are the important stuff for proofs and I just said that something being success is not something being efficient. And until very recently we didn't use ZK because of two reasons.

One is like we don't need that much privacy applications. One we will discuss more in detail later. So I'll pass one. Second, ZK wasn't efficient. Verifying something by just repeating computation was much more efficient. Let's say that you want to prove someone that like uh you have uh 100, you know, bank transfers and all these bank transfers check sum makes like I don't know $100,000. You want to prove this to someone. the other party repeating the computation is much much much faster than you generating a proof and then them verifying because like even if their verification is slightly more efficient it is slightly more efficient

and what you do is very very much more expensive so like it doesn't make the effort but with blockchain that changed because in blockchain we have like blockchain is basically a replicated state machine and this implies that we repeat the computation to make it trust Once you send a computation to Athearium, that computation is repeated 4,000 times for each single validator. That is why ZK rollups make sense because we need to repeat the computation so many times. That is why in blockchain ZK has a so meaningful use case because in ZK we have a lot of verifiers. In real life an information is verified once or twice or three

times. You know, you don't verify information 5,000 times. Let's say I want to like I want to buy a car and I want the other party to prove me something. They give me some document and I verify it for once because I am the party buying and they are the party selling. So I only need to verify it once. But if I'm doing this exact same thing on blockchain, it is verified on each single valator and also by every client that is downloading etc. So that's al something. But in the end verification on blockchain is much harder because there are so many parties verifying the same information. That is why being succinct is important because being succinct basically there's a limit that after that it will make sense to actually have a proof to verify some information

instead of just repeating the computation. Is it clear? >> Yes, please. >> I'm sorry. Um what do you mean by repeating computation? >> So what do we prove in proofs? Let's say I have this function f(x)= y. I want to make a proof of this. What does the proof says?" The proof basically says that I have the function f uh I run it with x and the result was y. This is what a proof says to be correct.

If it's a zk proof, I don't see x. I just see assertions. But like let's forget about ZK property because not all proofs are zk and zk is important only for privacy and zonology much bigger than privacy. Snarks are much bigger than privacy. Let me say like that or something can be only a snark like we say zk snark. There are also snarks that don't have privacy. So you know this is what this knowledge proof says and if I verify the proof I learn what verification tells me that sorry verification tells me that uh f(x) was y and what is a much simpler way of learning fx was y just running the function f >> that is proving by ver repeat

repetition. So like the always the simplest way of verifying something is just repeating the computation. So by definition is a verification is more expensive than repeating the computation then the verification is like does not worth the effort. So >> all right thank you. >> But that wasn't the case by the way verification is always more efficient but verification is not um more efficient with a certain like let's say that okay I will draw you something I think it will be much more clear. Let's say a prover and a verifier. I said that there are two scenarios. So in one scenario prover uses 10 seconds to compute the result and I use the exact same 10 seconds to verify their

computation that is verification by repetition. So I repeat the computation in the second scenario prover doesn't need 10 seconds they need like 10,000 seconds because they generate a zk proof and generating a zk proof is expensive and verifier needs like 9.9 seconds to verify. So this doesn't make too much sense. You know, verifier gain like 0.1 seconds and prover lost like 9,9 like 9,990 seconds. So it doesn't make sense. But let's say I have 1 million verifiers and only one prover then that makes sense. And in blockchain that is the case. In blockchain we have a lot of verifiers. Like in Athereum's case all valators need to verify. So we have 5,000 val verifiers.

Maybe I should sorry we have 5,000 letters and there's only one prover because there's only one rollup generator. So the prover size is always one. So it makes sense. Even like a small improvement in the verification cost worth the efforts. There's alo something called aggregation which we will talk about like in a minute. But even without aggregation knowledge proofs are important because they basically they have this moto you know prove once verify all everywhere and as many times as you like. So okay so I continue that is success and remember we were talking about zk

snarks. So we learned like zk snarks are zk they are saxent they are non interactive. So I sent the proof once and you can verify as many at times as you like. That's also why we have this moto you know prove once verify all and like fourth the argument of knowledge. There are proofs. So that we already knew. Um yes the okay I'm reading the question from chat sorry. So first question is what is the domain of a definition of the function? A function is sent over a domain right? So yeah like there our function is basically a circuit. So I guess you can think that like a like it should be defined over a field

and it should be like linear etc. So like there are those but we are computer scientists here. uh and in terms of the like way of looking of the computer science all functions that we have on computer science that we code can be created to be a zk proof and the saxin property is true for snarks um and snarks are touring complete so whatever you can do with a touring machine you can actually generate a snark for um so like that's not problem um is there a metric to know how any verifications a proof had like no because I can verify like on my local no

one learns that I verified something. Um yeah it makes more sense in blockchain because in blockchain the computation is more expensive because so even a small improvement in the computation costs is a huge improvement because computation is so so expensive like think like that let's say you are increasing a number's value by one so you have a counter and you're increasing your counter by one you have this number x you are doing x++ one you know doing this in your computer it's like one gate literally one computation you're increasing x value by one doing this on Athereum is like at least 5,000 computation because each world data needs to do and then they need to update their state. So they need to generate Merkel witnesses for their

state and Merkel witness is like 250 operations because it's on a Merkel map. It's a MLE tree on Ethereum's case. So I'm not sure for like I don't know for like tree but basically for only incrementing X by one you do like 50,000 operations or something on it instead of one. So it is very less like very more inefficient. I don't know. Okay, I passed this part. I think it will became clearer as we go along. So I will come to other parts. So this was ZK snarks and you will hear some rumors about other properties of ZK snarks that they have or they don't have. This is not true. ZK snarks can have any of these or maybe they don't have. They

don't need to have. Being snark does not imply the existence or the non-existence of any of the things here. First of all, absence of a trust setup. People will tell you that snarks need a trusted setup or the other way around. Snarks don't need a trust setup. Both are wrong. In like old snark setup systems, there was a trusted setup. Trust setup, I won't explain what's a trust setup, but we don't like a trust setup. So like having trust setup is something that is bad. And like previously snarks had but like I guess 10 years ago or something like we had snark proofs that didn't require trusted setup and new schemes they don't have. So you know that's old information people will say you other proof types can have can be more or less

efficient and snarks should be efficient to generate or not efficient to generate. This is not true either like snarks can be very efficient to generate or can be very less efficient to generate. like snarks don't tell you anything about proof generation efficiency or proof they just say that the verification will stay successent so they don't tell you any information about generation the snark keyword I mean postquantum security that's also a common misnowledge people will say snarks are not postquantum secure they are there are postquantum secure snark shims um and yeah like it doesn't really depend on uh your proof she depends on how you get zero knowledge

um or like soundness and you can have informationational theoretical soundness on snarks which is postquantum secure etc. Um so it's possible and finally recursion or aggregation we will explain uh what these two are but snarks can have recursion or they cannot have recursion like both is okay. Um having recursion or not having recursion is not a reason to be or not to be a snark. This is important to understand. Trust setup is not necessary. Yes, we don't need trust setup for snarks.

Snarks they don't define having a trusted setup. Uh you can check online to see like which was the first snark to not have a trusted setup etc. But yeah, we have a lot of them right now. So this is like no it was like that before. So that's why. Okay. So I continue. I will pass to a second chapter which is really important in terms of using zk snarks. So until here we explained what are zk snarks and what are their properties are or what are not their properties. Now we will pass to a concept that is quite important which is recursion and aggregation which is very important to understand because we use these two a lot. So this is the diagram that I did which I believe explains perfectly. In the left we have aggregation and the

right we have recursion. Aggregation is basically that you create a ZK proof that verifies two other proofs. So I have the proof one, I have the proof two and you verify these two proofs inside another proof. I just said that proofs are true complete. So you can do whatever you do on a computer on a proof. Thus verifying a proof is something that you do on a computer. Thus you can verify a proof in a proof. But this is not true for all proof she by the way. Like not all proof she have this or more appropriately have this in an efficient manner. For some proof she's aggregating proofs is like insanely expensive. Uh but in some new schemes u it's not and you can aggregate

proofs very efficiently. So let's say I have a proof that you know verifies I am older than 18 years old and I have a proof that verifying I am a male. I can combine these proof aggregate them and I will have a proof that verifies I am more than 18 years old and I'm a male. So that's an aggregate proof. And then recursion proof is that you again verify proofs inside another but you verify always the same proof. There's a base proof and then you always verify the exact same proof each time. So uh like a good example is blocks of a blockchain.

Each block is a proof of same type like they don't have the same inputs inputs they change but their verification key stays the same because the assertions that the proofs do are not different. Thus if you verify a proof inside another proof that becomes recursion because you always recurse the same proof. So these are not two different proofs. That's why I use the same color in recursion but there are two different colors here. Color coded uh never miss. So yes, that is the idea. Um, and by the way, a small information, maybe you didn't hear that before. Identity of a proof. So once I say like these two proofs are different, that is the verification key of a proof. And a verification key are the assertions in a

proof. Inputs, they don't change the verification key of a proof. And that makes sense. Like inputs should not change the identity of a proof. Yes. Alas. >> Yeah. Unice can you please um again explain the concept of recussion? I didn't got exactly uh what's the process? Why? Because the color coding scheme here you mentioned proof one proof two are two different proofs but while recursing again why it is the same proof one only. Can you please shed some light?

>> So when I say the same proof um I mean that assertions and computation is the same. So let me define a zk proof that takes like x as input and the proof will do two things. First it will assert that x is less than 100 and second it will output x + one. Okay that's a proof. I can recurse this proof inside each other. What is recursing the proof? I add another argument here. I say you know zk is the first argument. I verify and I don't get x as the argument. I verify ZKP and then I like set X equals ZKP.output

and then I assert this and output this one and then I just call ZKP over itself over and over again just like a recursive function and this basically allows me to like use the same proof to verify itself. This is not the same as aggregation because in aggregation the input that you get is not the same type of me in here. Input is the same type as ours. So that's why it works. >> Fair enough to >> of course uh in computer science that is composition and recursion. So arguation is composition, recursion is recursion.

No the name. Uh and probably you don't like it doesn't make too much sense to you right now. Um but in very old languages composite types were possible but recursive types didn't exist. So you know you created this class and the class uh like it had the right to have fields of like other classes but it wouldn't have a field of itself. So it wasn't possible to create this class of student that has a field. It's also student of type. So recursive type definition wasn't possible but composite types were possible. So it's a bit the same. Aggregation and recursion are different in that sense.

How many times I recursion? I can do as many times as I like. There's no limit. That is the most beautiful part. We said that ZK proofs are succent. Oo. And what happens if a ZK proof verifies itself? The verification becomes cheaper and cheaper. So you can actually combine as many proofs as you like to verify as efficiently as you like. So that is the most beautiful things about ZK proofs. I said that a ZK proof is logical to create after a certain input size. So if your input is so small and if your computation is very fast then you can just repeat the computation to verify. Let's say I have this function

and it just you know outputs x + one. If I want to make sure that x resulted in the correct way, I can just uh add one to x. But let's I say that I have 1 billion f functions for 1 million different f values. That would take 1 billion operations on my site. But with ZK I can create a proof for each functions and then I can aggregate them all so that I have a proof that is again verified in as short time as before. Maybe it was a long time but you know it's the same time for 1 billion functions. So that makes it make that and that point it makes sense. It is like rollups. If you have a rollup that only has one transaction per block it is

stupid. You can just send the transaction to the chain. So a rollup should have more transactions than L1 so that the rollup is efficient does make sense everyone understood or okay there's something on chat how do I measure efficiency him for instance like as I said zk proofs are succent So they are practically constant. What does it mean practically constant? So let's say you know I have this proofs and all GK proofs are verified in

in like more than 20 seconds. For a proof to be verified more than 30 seconds since it is sex it is like you know logarithmic you need the proof size to be like a billion times bigger. So basically all proofs are verified in less than 30 seconds we can say because that big of a proof is not possible. So verification is always constant most of the case it's practical constant. It's not constant. It can go infinity. It can take infinite time to verify a proof because it's not constant but it is growing so so so slowly that it is practically constant. It's just like log log x.

And the first question okay I explained that one aggregation recursion aggregation is uh verifying two different types of proof recursion is verifying yourself it's recursive functions over like agate functions okay any more questions here does it make sense the concept of argation equation and now the picture looks much better right okay I have two different proofs it verifies them I have the same proof verifying itself over and over again.

Okay, then you will pass to applications. So this was the concept of snarks. I were like I explained you all the important things about snucks. We discussed being succent. You know what is succent right? Now uh we explained it's not bounded. It's not constant but in practice it is constant. It doesn't pass a certain threshold because like input size cannot change the verification that much. So that's why you know in practice it is constant that's why we usually say that they are verified in constant time or you know constant uh size etc. One thing second we said that nothing here is required to be a snark or you know not like is required to not be a snark etc. So basically nothing here is a common

property of snarks. That's very important to understand. You first we didn't discuss the first parameter trust setups. I don't think that is the like a subject of this course. So I'll test that one. We discussed about efficiency and proof generation. So basically that is the time that it takes to generate the proof or the memory it takes to generate the proof etc. Um snarks they don't need to be efficient. They don't need to be not efficient. They can have anything. Postquantum security. We said that snarks can be postquantum secure. And finally we said that snarks can have efficient recursion or aggregation.

All proofs if they are complete they can um perform recursion aggregation because recursion aggregation is just some computation and if a proof can do any computation it can verify itself as well. Here recursion aggregation once we say that they are available in a proof sheet we mean that they are efficient to do they are not like billions of operations. So that's in practice they are possible that is very computer scientist of ours once we say that something exists we actually try meaning that it is you know very efficient to do or you know at least somehow efficient to do if something is very very expensive we just say that it's not possible you know because we don't do it okay now I want to explain in my last like

five to 10 minutes um some applications for snarks so as you know snucks are zk snucks have the property of zk So the first big bubble that we create using ZK is privacy applications and I want to talk about this because privacy applications or ZK are very misunderstood guys. ZK is not encryption. It's not encrypted computation. It doesn't give you privacy. It gives you like a very special type of privacy but it's not possible to do what you do with like encryption using ZK and using private applications with ZK is like something that's very complex and basically you

can't do everything for instance I will give you like some very common misunderstandings first of all private voting people says you that like you can make a private voting application with CK and votes will be private. No, with CK it's impossible for you to make votes private. You can make voters private without using an encryption machine like FH or I don't know regular encryption also. Okay, you can't hide votes. It's not possible. You can hide voters.

There's a huge difference these two. So you can hide that I am voting but you can't not hide what I am voting for. For instance, that is the example with voting or with payment. Private payments are not possible with ZK. You can't implement a private payment protocol with ZK. You can implement a protocol that has public deposit cash is tornado cash is not a private payment protocol. It's a public deposit private withdrawal protocol. Your withdrawal is private. Um today we don't have enough time to talk about all ZK applications and how these look like. I just say these so that you know I don't like talk rubbish. Basically these are true what I'm saying here. So if you

have another opinion we can discuss later like in some other time. I'm just trying to give you some understanding of like why ZK is useful and why it is not. And it's not possible to do all privacy applications with ZK. ZK is for something very very very specific. There are some questions I see. Um h yes uh we can exactly we can hide who is changing the state but we cannot hide the state change yet that's a very very good summary exactly for instance private state is not possible it's just private updates that possible you know with public commitments you can also by the way have you know state committed in a public manner that's also possible

basically instead of having the entire state I just have you know the merkel root of the state etc. So that's a commitment if that makes sense. That's also possible to do. The case is proof and trust privacy. Yes, we have a proof of that information and with a proof of that information you cannot build all type applications. Um private messaging is also another like great case. If you want to hide messages from rest of the community, you need encryption. You can't do this with ZK.

ZK does not hide anything. ZK hides the input while public outputs are there. So you can have public assertions on private input. But if the input is private, it's private to everyone. If you want to make something, you know, shared information over a public channel or something, you need encryption. ZK mail as well. That's a good example. In ZK mail, we don't like hide our email. We basically hide our private key you know so that it's like no one knows our like password for instance to access emails but everyone sees that there's no ZK by way so ZK is in a privacy use case I don't think maybe ZK email is not the

great example it's more like in ZK email verify the computation was done but it's a public computation already so it's a public communication so it's a public proof there we don't need private inputs for ZK maill so yeah that That's the case. So this is very important to understand. Then you might ask then like why do we use ZK for privacy applications? This is not cool. I thought you know ZK was the next generation privacy. ZK is next generation privacy because they have an advantage. Oo ZK snarks are usually in parenthesis have information theoretical security or privacy not cryptographical.

What does it mean? In encryption, you hide an information by having a secret key. And this is like this, you know, since the beginning of time. And probably this won't change like with postquantum cryptography etc. Encryption methods they get better and better. But there is always a secret out there that we are hiding and if some party has the secret they can decrypt our output so that they learn the information. So nothing is secure right now. We don't have uh post like quantum computers.

That's why you know our Zoom meeting here is right now secure. But Zoom can just you know store these encrypted meetings on their database and decrypt later once there's a quantum computer or you know we say FH is postquantum latex based cryptography. Guys, at some point latex based cryptography will be broken like we are certain that it will be broken because it's just a hard problem and all hard problems will be solved eventually. I'm not sure about that by the way but I think it's possible to broke it like there there's a problem third. So I'm not sure but in that it's very possible that it will it will be broken. So if you are cryptographically making something private, you will lose the privacy at some point. But in ZK

proofs, it is information theoretically private. The proof does not contain your information. It doesn't hide it. It doesn't contain it. But very important, once you hide an information, the information is out there. We just cannot access it. In ZK proofs, the information does not exist. No one can reach like touch the information because it's not inside the proof. So that's why snacks and information theoretically proof secure. By the way, this is true for privacy not soundness. Uh there are also information theoretically sound zks but I think there are but like they are very rare.

So I but for privacy this is almost always true. Yeah, I think so as well. Yes, hash is a good example. Hash is not a perfect example because you know you can always get the pre image etc. Um but yeah, hash is a very good example. Even if you get an input from the hash, you don't know if the input was real. And if the input was just a secret key, you getting the input from the hash doesn't tell you anything because by looking at the input, you don't know if it is the right input or it's just another pre-image of that hash. And if you need that exact input, then it doesn't tell you anything.

And for instance, in the ZK vault case, you can actually hide waters until end of time. No one will ever know who where the waters are for. Okay. Uh I have a fun question below. So I thought that was fun. I don't know. Um so it asks let's say I have a recursive snark. Uh can it have cryptographically secure zk but not information theoretically? So basically let's say I have this theory that I say a recursive snark should always be information theoretically private. Am I right? Um so thinking about this I think that's can be a very advanced question but I will leave it here like if anyone wants to answer this I don't know you can um

reach to me after the session so that we discuss this. That's a question that I came up with. So I'm not sure if it is academic, but I think it's impossible to have the other way around. Um because it's succent. So basically the information that's contained is always going to zero. So that's why it's interesting. Um we have a comment on the chat, but I didn't understand. Maybe some more information would be nice. Um and yeah, that was about the privacy part of ZK Snacks. Any questions about privacy?

Okay. And again like if you want to discuss about this question you can just reach out to me later. And finally we have scalability applications. Um snugs are very useful for scalability because they are succent and again they are useful to use because they become smaller and smaller. not smaller and smaller. They like their growth becomes slower and slower as the input goes to bigger. So there is always a point that enough input will make the verification of a proof very efficient. So the verification's time complexity will be verification's total time will be much less than you know repeating the computation itself. there's always a

point. That's why rollups etc. they make a lot of sense because uh with CK you basically can verify as many information as you like at once. You get all the transactions happening on you know you will listen from stacknet in a bit or you know there scroll to secure app as well. You get all their transactions you create a single proof for all their transactions and you verify it and they are successent. Thus, the verification costs like always the same amount of money or you know time. It's expensive by the way. Like I know that scrolls verification takes like I don't know 5,000 or $15,000 per day. So you know that's very expensive guys. But if they

have enough transactions inside the proof that worth the efforts because it's constant. They always pay $5,000. They don't pay you know if the transaction count is less than 100 it's 5,000. If it's less than,000 it becomes six. No it's always $5,000. that why that's why it makes sense no information should be concerned that they are not contro yes we should be concerned because there's soundness can be broken so let's say I have a privacy protocol using zk quantum computers cannot um be an attack vector against my zk proof it can just be an attack vector for the soundness so yes and no let's say you have a rollup you don't need to uh worry for the old information you

have settled so But if Google has a quantum computer then yes you need to change your uh proving she so that they cannot create uh unound proofs. Soundness means that like the proof generated correctly and if you have a quantum computer you can create a proof that's not correct but you cannot decrypt information. By the way this is not a snark common property that is a possible snark property and it's usually true but not common. Snack just means success again of course.

So we also have other use cases but I think I am a bit over my time. So there are two applications for ZK that is nice and there also lightning network sorts. Um that's also very useful and logical to do with snarks. Um but yeah that final note is really important. ZK can never ever ever solve double spend problem. That's why we need blockchains. ZK can achieve trustlessness. It cannot achieve sensor resistant. it cannot solve double spent. There's no mathematical formal theory proving that at least not that I have seen any but I think it it's very easy to prove. So yeah ZK can never ever ever solve double spend and yeah that was my presentation um I hope it was useful.

>> It was really good. >> Hey thank you guys. Um >> thank you. It was so useful. Of course you have any questions you know also in our telegram group so that's text them and yeah >> yeah I share my telegram ant before again this was a very long introduction I know and I know there are a lot of properties there you don't uh the slices uh slides yeah I can send the slides uh my telegram is by g um so yeah basically the most important point to understand is that ziki is a very useful technology and there is a reason why we work on ZK so hard so much. ZK is useful. ZK is

logical. But there's also another important point. ZK is not like what you think it is. So that's why if you want to use ZK, you need to understand ZK very well. You cannot just add ZK to any application and it becomes private. You know, ZK doesn't work like that. Or it's the same for scalability. ZK doesn't make everything scale. You can use ZK to scale something very efficiently, but it's not always the case. And that's my conclusion. >> Thank you. Um, thank you guys again and I need to run. I I have something to do beforehand. So, uh, and I hope like Dana, you have an amazing presentation and I hope it was helpful. Um, >> we will continue with Gan and take care.

>> Byebye, Ron. >> Byebye. >> Thank you so much. >> Welcome, Gan. Now, we're going to continue with Starks >> and we have tutor. So, yeah, floor is yours. Um so I know that the previous session was like a bit much so I'll try to cover um different things related to stocks in just like maybe half an hour. I prepared a presentation for 45 minutes to an hour but I think it'll be way too overwhelming and then you'll just forget everything and just bunch stuff up together. So I'll try to just cover like an umbrella of uh what starks are just the thought process behind how starks

were created and um what I'll do is I'll just put some key instances here and there that will either make you curious to explore STS uh and starket or you'll just end up having a lot of questions um either or which is a good scenario right in a learning journey. So um I'll start with uh a small let me just share my screen. Um I have absolutely missed every mathematical component that is associated with this because I think starks are extremely complicated just to understand from a mathematical standpoint right um and that's why I try to condense as much information as possible uh into this and also my role

has changed quite a bit. working a lot with startups now that are working on starknet. So a lot of this that I'm doing is from muscle memory that I've already done. Um I also did prepare um a document for questionnaires uh and then just some intro and stuff that uh I'll share in the in the chat. So if you have any questions don't hesitate to put them over there. It could be just about anything. Um, just from like zero knowledge proofs to starknet or or whatnot and I'm happy to answer them or get them answered in case it's you know too complex and I just don't have the answers. Okay. So I'll quickly run through what is proving how does it work. It seems to me that most of this

has been covered in the last previous sessions right. So um I just wanted to add this so there is some context to like what is happening and then we'll go to stark proofs um what is Cairo and then what actually how does actually sts get proved in Ethereum and then how can you think about proving them elsewhere in any other environment right so quick context about uh proving right so um this is a process in which a prover wishes to execute a computation and convince a verifier that the result is correct right and as Ununus mentioned in his previous talk non-interactive proving is what is um you know the most important element in um everything right so snarks kind of introduce that so

that's why you have the scalable non-interactive um you know argument of knowledge and then with starks you have slightly one more um one more addition oh sorry snarks you have succent and we are we are scalable so scalable transparent arguments of knowledge right so the s&t are slightly different um we have scalable able in our system because we have created something that will help you scale the proofs instead of doing individual proofs for every single scenario. We have created something that will help you uh generate proofs in the most common um you know way possible. So uh that's why you have the scalability part and that's why starknet uh and stark proofs were created to uh make sure that proofs can scale and then you

have the transparency element which is um you know the non-interactive element uh exists but with starks the aim was to make it more transparent so that's why it is you know STAs and uh that's what I'll be talking about. So here the verifier doesn't actually have to execute the program but is able to uh know that the you know that the computation is happening correctly. So that's what is proving all about and how does it happen. All of these other elements are actually the how part of what proving is. Uh so the first step that you go through is called arithmetization and that is why we were talking a lot about when subsidness there is you know log x the polomial and all of that because when you're all of when you're dealing with all of these

proof systems what you're essentially dealing with at the underlying is polomials right so you take a computational problem and you need to convert it into an algebraic form so a lot of times you might come across this uh keyword called air which is algebraic intermediate representation it is something that is used in stark proofs as well but generally used in a lot of proving systems which means that you need to have some sort of intermediate representation in an algebraic manner right um which is what you sort of take and you know perform the mathematical operations on top of and then you know you're able to do all of this non-interactive kind of you know proving so you um you take the computational problem that is given to you you convert

it into an algebraic form right and uh this algebraic form is actually essentially representing your program operations, the logical steps and all of that. These are being represented as polomials over finite fields. We are not going to go through anything about finite fields and all of that. Uh but this is uh you will find this in abstract algebra. Not very interesting but when if you read it like three four times you will eventually get it right. And then what what what we are doing is we are capturing a behavior of a program right mathematically that's all we are doing. And initially when we generate that let's say we call it the expected polomial right that we expect this a particular program to work a certain way

uh once uh and then once the program u goes through this uh a sequence of states or steps right so uh that is your execution trace execution trace is actually something uh common that you would find even in other programming languages. So any program that you write um at the underlying it is actually going to a hardware and then it is being u you know steps of that program are actually being stored in a register right. So you see register values this particular register is currently you know some hexadesimal value 0x 0. So if you have actually tried to break a program and see inside of it um you will you would have seen some of these things and then if you have studied computer

science then there is also u the hardware part of it that you will you know we digital science where you understand how registers work and how values keep moving from one register to another things like that right so the execution trace is not like a log of every instruction executed right the register values the memory accesses etc at each So this execution trace is also turned into a polomial. So this is let's say this is your execution polomial right. So you have your initial problem statement you have an expected polomial and then you have your execution trace that your program actually goes through and let's call it the execution polomial. Right? Um on top of this what happens is there is um so any correct

run of this expected program will generate an execution trace that all fall on this expected polomial right. So the way you are checking whether the expected polomial is actually similar to your execution polomial is by checking if the points that we mentioned like this this is a polomial so the polomial will go through different points in the graph. So you're actually checking that this all of these points actually do they fall on the expected polomial. So the prover uh convinces has to convince the verifier that all points of the execution trace fall on the expected polomial. But how do you do that without checking all of these points right? So

there are going to be like uh there are going to be like lots of points that are going to be part of this polomial. Right? Imagine a polomial going through your entire sort of graph. Right? uh there are going to be so many points in this. So what you do is the answer is you end up checking some random points right as a verifier I'll end up checking some random points and that is your that is called your error uh error correcting codes right all of these are by the way just your straightforward concepts that you can find in communications and you know uh digital uh computation and all of that. So ECC which is a set of techniques um when you actually use to transmit data and telecommunication it allows you to detect and correct errors right in this in this context we don't

need to correct errors because what we want to prove is that um we as a verifier I just want to randomly check some points right which is that non-interactive part and I want to make sure that okay these random points are falling on the polomial so I'm happy that you know what they said the program will do the program is actually doing that. So this prover is able to prove uh this statement to me right. So what this ECC does is it will if there are errors it detects these errors and it amplifies these errors. Right? So that is why if you make a mistake even if you make the smallest mistake right um in in telling that I will do this but you're actually not doing that then that small mistake will flare up right and that is the job

of ECC's which is to the smallest mistake it will highlight and it will sort of um you know um so that the end result is you are able to check randomly whe whether the execution polinomial and the expected polinomial are the same Okay. And this helps that the this helps the verifier to not have to retrieve and analyze the ECC output because the ECC will tell you where the mistakes are like it will highlight the errors, right? And they verifier will sample a few parts and check for errors, right?

Um so this is just this this is a kind of summary. I think you were already familiar that this was this was happening but I just wanted to share all of this with you so you know what is the exact process like of actual proving that happens um irrespective of stark proofs or snark proofs some of these things are common right like you have the arithmetization you have the um execution trace and different things happening just the way the proofs are generated just the arithmetization part will be diff will be different, right? Um and then um probably the way the execution trace is generated. So the execution trace is nothing but a matrix. Sorry for the uh

disturbance. The execution trace is nothing but like it's like a matrix, right? So um you have uh all of these instructions and stuff and just the format of the way these things are generated is different uh because of the underlying um let's say mathematical elements that we are choosing to do these things like sometimes we may use a particular type of function right like um one of the examples was was log x as one of the uh functions right um I don't really know if snarks what function snarks are using but you you you could use an um elliptic curve, right? You could use an elliptic curve function to do uh so the polomial function that you choose will differ from proof to proof

um largely because of the way uh those proofs function and things like that. But this is like just the overall context of how you are able to successfully do a proverifier thing. Right? With this let's try to understand um how star proofs work. This is always a fun slide. So um the creator of Stark Cruise uh is Ellie Wasassoon. uh he is currently the CEO of Starkware and um um yeah and pretty cool um really um amazing research that went behind uh all of all of all of Stark proofs right and uh the idea is simple right um from a mathematical perspective if you look at

it if I had a 1 million degree polomial and if I could prove to you that I know 1 million values of x where it goes to zero right so that's like your logic Correct. Uh but you wouldn't have to calculate the polomial and on each of the 1 million points. Right? So basically what you're saying is the probability percentage of me uh being able to check that this um using random values. For example, as a verifier, me will use some random values and check whether what your statement is true or not. Right? And the probability of that uh the truth being really high and me as a verifier being convinced is possible with star proofs, right? And this of

course the whole point is to save time. Um so this was the basis of like the way the star proofs kind of came together. Um they are a family of cryptographic proof systems that can be used for privacy and scalability. I don't want to emphasize too much on privacy which is ironic because this session is about CK privacy but as Ununice mentioned rightly um doing privacy related stuff on um especially on stark net which is where a lot of stark proofs currently are being generated verified on Ethereum at the moment. Um it is very very difficult right um and a lot of times like he mentioned privacy is an exaggerated

concept um in terms of people don't really understand what are the things that can be private and that cannot be private especially in this case because uh starknet in itself is a public blockchain right um which is built on the concept of stock proofs and such and when you have a public blockchain then you know and saying that you will have privacy you will be able to easily build privacy focused stuff around that is not very it's sort of you know contradictory right because a public blockchain is meant to have data which is extremely public uh but scalability yes so um as Yun mentioned uh in his presentation as well right you can have scenarios where you can use zk zk proofs to scale and

this is one of the scenarios where you can use stark proofs to scale your operations right and that's why starknet is uh its biggest strength in is being a rollup, right? So being a ZK rollup that rolls up transactions to um Ethereum and gets a bunch of transactions verified in one shot using the computation proofs. So what does it do is that start proof statement saying that a computation was executed correctly. That's what it does to Ethereum, right? You do a bunch of transactions, you bundle them together, you um send them to Ethereum and you say that all of these transactions were done correctly. And think of all of these transactions come together as you know a polomial and uh you sort of as a as Ethereum as a verifier is trying to

verify randomly by checking a few transactions or you know just just for analogy um that whether some of these are correct or not and even if there is a small mistake your ECC will kind of blow that up and then you know verifier is satisfied with a higher probability that yes uh these proofs are make sense and we move forward Right? So some of these simple statements that you can think of is like the thousandth number in Fibonacci sequence is X. Right? Uh and then I have signed a 100 bank transactions that are I have 100 signed bank transactions that are valid. So things like this, right? Just some sort of computation and the verification time for this. So the main thing about GK

proofs being having strength in being rollups is that the verification time is exponentially smaller than naive computation. If the verification time to verify a bunch of proofs is larger then this whole scalability thing just you know falls on its own. So why does it matter? I think all of this already familiar that you know we have distributed computing we move from being uh able to do uncentralized servers to advocating for decentralization. So the way blockchains do u help decentralized value transfers computational proof um helps prove that code execution was correct. Right. So you do things um you even though uh you are things are

naturally happening with integrity right so u you're doing the right thing even when no one is watching that's the whole concept of blockchain right and that's what computational proofs uh do to code execution so um this has also been covered um but I want to emphasize that with uh starks one of the major reasons that starks were created was to um you know make sure that the blockchain speed blockchains become more and more scalable. Um we started with the stark zk proofs with blockchain of course because there is a kind of application that works here but um there is also more that you can do uh especially uh as it becomes better and better uh

you can work with zk proofs on doing lot of scalable stuff right you can also have privacy elements but it will be slightly more complex than it is right now it seems like Right. Um okay. So now the so we have seen a bit of context. We have seen what are stark proofs. Uh the next question is how right? So um zk snarks you use you write uh circuit right to prove. So you what you do what you end up doing is that you end up writing for every kind of proof scenario you will end up writing a circuit for that right. Um so you you will be writing your circuit in some circuit based programming language. you will feed that circuit and your circuit is

very specific to a particular uh problem statement, right? And the how for stark proofs is a little bit more different, right? So with stark proofs, we went one step ahead and created something called as Cairo. uh now Cairo and stark proofs are very uh closely related because what we wanted to do was we wanted to make sure that this provable computation um can be done in a scalable format right so you for example in this scenario where you have to rely on stark proofs for pro provable computation that means your code has to be expressed in the form of polomials right so finding the right polomial for a program is a timeconuming it requires specific skills

so this is exactly what you're doing when you're writing those circuits for snarks, you're actually trying to find the right kind of logic. So you write a specific circuit for a specific program, right? That's what you're doing. You're trying to actually find a polomial that fits. But here what we we did was we instead created something which is more for flexibility, right? Like how you can execute any kind of computations on CPUs, right? Um whereas you build asex which are for specific uh uh like application specific designs right so application spec so that's what asex are that they are very very application specific and they are very hard to

design similar to how you design your uh circuit right so they are not generalpurpose circuit whereas CPUs are more general purpose right they're cheaper they're vastly available and they're easy to program for and you can have a single you know architecture for multiple purposes. So here you have efficiency versus flexibility and we have moved more towards flexibility. So in so just quickly I will quickly go through this like what this would look like. So if you would have to build a stack manually just like you build an asich right you will have to design the trace uh in terms of uh figuring out how the trace would look like. As I mentioned the trace is nothing but the trace needs to

be represented in the form of a matrix. So you see this is like your sort of matrix you know so you have to design how many columns will be there um you know how would you um uh how what would each cell mean right and then you have to add constraints onto this there is a lot of manual optimization uh you know how many how much trace space can you have and then what will be the prover time what would be the memory and things like that right so this can get very complex very fast and if you try this doing this parallelly in snarks as You can see that as you try to build circuit as you try to build circuit for more and more complex problems um the circuit themselves become very very complex right because at the end of the day the

circuit will have a lot of simple things like node gates they will have um you know and gates they will have simple gates that you're actually just putting together as a circuit right and when you're doing a complex logic this can become very complex very um very quick and after that you would need to have like you know um you would need to create the right kind of uh tools. So these are like your physical tools right. So you will have some um FPJs for example how um how you use that uh you know gate arrays for uh uh performing logic things and all of that right so uh in this case what we what you would be doing is that uh you would have to try to make generalpurpose arithmetic uh so

algebraic intermediate representations that can be connected to other algebraic intermediate representations. So like all of this just says that oh this is like going to get complex over a period of time and then you need a programming language as well for these things right um and um all of this is like um you know um until step three it's a very complex life and this is where Cairo comes into picture. Cairo actually is nothing but CPU AIR0 right and uh that is shortened to Cairo and uh all of this I have already explained to give you context. So CPU for your you know um like your general purpose for all of general purpose computations. AIR is

your um you know uh algebraic intermediate representation and zero stands for the like the the first like the zeroth a kind of like a common one right. So you have one AIR, one verifier, right? So what you're going to do is you're going to build we we have built a common um a common AIR or a common C uh implementation which is like one common circuit. Um think about this as a common circuit which will be able to prove any logic that is sent to this circuit. Right? So that is the biggest if somewhat anything distinguishable from other proof systems is this that

one of the most complex things about writing these um or using these proof systems is writing the circuit logic itself and what Stark Stark where early on uh has done very beautifully is to create this generalpurpose programming language where you feel like you're just writing a program you're just you know you just have to write a logic and internally that program translates into a general purpose circuit that is able to create stock proofs for you and that's the power of like why star proofs are there are lots of other things like you know I think ununice also mentioned like postquantum security that we talk about that stark proofs are by default

postquantum secure you know they are more efficient and proof size and all of that but for me feels like this is one of the biggest standouts being able to have a general purpose programming language that can actually create uh you know proofs for you right off the bat. very interesting, very different and somewhat I would say extremely innovative, right? And it takes a lot to a general purpose circuit, right? Um and uh that is what Cairo is for, right? It stands for CPU AI or zero. Uh it's a universal machine um Turing complete and u you actually pay for you know only what actually runs. So you pay for the amount of computation and stuff. Um and

you can build as complex as a logic into this right um and um yeah so there's some like comparisons and stuff so of efficiency uh but this is the most interesting thing right so kairo is a highle language um it is very similar to rust and it compiles to something called as safe intermediate representation all of these steps now I think you have some more context why this is happening is because you have to create algebraic representations. you have to make sure that the language compiles into you know this general purpose polomial uh that you can actually test right so that's why kairo program compiles into a safe

intermediate representation called sierra um and then you know even if a program fails there is a proof that is generated and that proof is invalid so invalid proof is generated so you are able to know that this program failed and uh the sequencers are always compensated just fine um and uh you know so this chyrop program gets gets genu generates a safe intermediate representation then it generates a cyro assembly which then creates a validity proof. So we call we don't call them zk proofs because they're actually not zero knowledge. They're not completely zero knowledge, right? Uh but they are um you can validate whether something happened the way it was supposed to happen. Your

completely zero knowledge requires you to have hidden parameters which is that one piece which is missing and I mentioned that's also because darknet is a public blockchain right. So instead of zk proofs we call them validity proofs. Uh we have question in >> there are questions uh sorry okay >> uh the matrix is for the coefficients of the polomial or for something else um so uh circuit is your choice of polomial um I would say the the circuit itself is more like are you um are you asking in this case specifically for starknet because for starks we don't we don't have to write the

circuit for starks. Um this is like there is like a generalpurpose polomial that they have chosen and uh Cairo builds on top of that generalpurpose polomial. So that generalpurpose polinomial is is able to validate as many scenarios as possible. So maximum number of for maximum number of scenarios uh you can generate a proof using that general purpose polomial. So uh in this case we don't actually have to write the circuit but we have built chosen that or built that general purpose polomial in in that way. So for star that is the tool uh for the mat uh the matrix is for the coefficients of

the polomial this I'm not so sure um I have an example of how the matrix is generated. I will I will try to find that and I will I will share it with you. there is some information into the matrix but I don't really know if it is the exact polinomial coefficient or if it is something else. >> Oh yeah it was just related to the step one that you mentioned that we have to choose the coefficients of the matrix. So um you mentioned four steps and I'm and I was asking about the step one. >> Oh the first which is the arithmetization right?

>> Yes and you you talk about the matrix at that point. or here right assigning a one um yeah I think it is uh but I'm not I'm not 100% sure I will I will check and I will um I will tell you I have an I have a sample matrix itself for star proof mathematics so I'll check in that and I can share with you >> okay thanks and you mentioned the generic polomial what's its expression >> um I don't have it I I'll I'll share share that with you. It's all all of this I have in the mathematics part which I have >> completely sorry.

>> All right. Thank you. >> No worries. >> Uh but uh if you could can you put your questions on the on the dock that I shared. So I'll make sure to answer all your questions even if I don't have the answer right now or I can copy paste it later as well. No worries. Um yeah so basically I want to summarize by saying that Cairo is a high level language which is inspired by Rust again and >> I'm so sorry for a second I think also has a question >> okay yeah let's go >> yeah just wanted to confirm whether sequencer is equal to a validator or those are two different aspects

>> no I will I will I have a um I have a diagram for that what a sequencer is but sequencer is something that produces blocks I will shortly share an architecture diagram as well that will help make it clear. >> Works. Yeah. Nice. >> Okay. Nice. So, yeah, this is like a simple summary. Um, all you have to do using Cairo is that you can you just need to write the logic without having to worry about the math behind it and uh um you know it it all happens in the background. That's why also I'm not that worried. Okay. So now the last section that I wanted to cover uh was um how do you prove starks on Ethereum? Um this is

very simple, very straightforward and this is where I think some of that architecture u diagram will come into picture. A lot of this this presentation is very tightly coupled with starknet right um and you would see this not because starknet is the only entity that uses starks by the way. There are also other um other folks in the ecosystem that are using stark proofs themselves. But this is very closely tied to starknet because right now starknet is that platform which is producing maximum number of stock proofs right uh in the most efficient way possible. So for me to draw any parallels it makes sense to uh talk about how um starket works in

collaboration with Ethereum otherwise it is very difficult for me to explain. I didn't want to keep this presentation very tightly coupled but if I don't do this I have no other option but to go only into the mathematics of star proofs which is very extremely complex. Okay. So um how do you so when you think about like when you're proving something um right on uh other blockchains for example snarks and stuff like I mentioned you have to generate your circuit for that particular problem statement uh and then um you you write a verifier contract and then you send the proof uh to that contract and it kind of verifies for you right so in this context the verifier contract let's say

is deployed on Ethereum uh and then you um you know generate a circuit wherever right so you generate your proof on client side and all of that I don't know if any of you all have had any hands-on workshops with snarks but you can generate a snark proof client side you can um you know generate the proof send it to a solidity contract verify a contract um which is deployed on Ethereum and it will you know um verify the proof for you but in this case um you don't have to generate a circuit like I already mentioned because you just need to write your Cairo program and it will uh transpile into uh the Sierra. And do you need to write a verifier contract? No, because we already have deployed contracts on

Ethereum, verify contracts on Ethereum. Um and you also actually don't even need to send a proof to Ethereum. All of this is already being done by Starknet, right? Um and uh what starknet is is actually it is so the the only circuit that you need or the only program that you need is to write a cyro program right it's verifier is already written deployed and audited on Ethereum and the Cairo language will compile uh to these instructions executed executable by the CPU and uh um correct execution of program will generate a proof understandable by the verifier. So what you do is when you write logic and you

put it you write your logic in cyro program right you put it on you deploy your cyro contract on starknet it will generate the proofs for you send it to ethereum and the ethereum's verifier contract which is already deployed on it verifies that proof and um you know say okay good to go so there's one circuit to rule them all this is what I mentioned by a general purpose circuit right so um how does this happen. Um your starknet in itself is a kairo program. So you deploy and execute a smart you deploying and executing a smart contract on starknet is actually a part of a bigger starket workload.

Right? So we have this prover called sharp which I will talk about uh and uh uh sharp is the one which is uh which is constantly generating stock proofs and sending it to uh sends it to ethereum and the verifier on ethereum verifies these proofs right so any kairo program that you deploy is actually part of starknet's workload itself and this workload is um sort of you know part of a bigger proof so the recursive proofs that he had shown Ununice had shown in his uh image earlier uh is what goes here, right? So you take a proof, you send it and then um you again recurse over multiple proofs and then you send

the final um sort of smaller trace kind of thing to uh Ethereum. So this is where you this is somewhat significant in talking about the other things. I won't spend too much time on this but the way it works is um you send your trans whatever transactions happen on starknet right you have uh the starknet OS uh which is your sequencer sequencer is an element which will take the transactions and then uh create uh make them into blocks right which is what ethereum does for you and one of the things that is happening right now in starknet is that we are trying to decentralize this sequencer right right now we are running the starknet

sequencer But we are slowly moving towards decentralizing. We had a recent update um that had uh you know this ability to so now when will decentralization happen when anyone is able to take and run this darknet OS themselves right so there are lots of different oss and then you know it's decentralized you send the transactions it is picked up by one of the sequences you create a block um from there you get this execution trace right which we me mentioned earlier which will go to the prover called sharp uh so you get the program so this is where you get the whole you know uh looping of the proofs you take the execution trace you send it to the prover uh the prover generates the proofs and sends it to verifier. So

here is where you can see the two different entities. You see one entity which is the proof generation entity. Think of this as just proofs being generated anywhere. Right? In snark case you will be able to generate client side proofs u maybe on your system or something right and in case of starks you are actually you have the sequencer that is uh we have the prover itself called shar which is generating the proofs. Sorry. Okay. Um so there are some other elements as well to this uh which you don't really need to know right now uh because you know we are then it becomes a little bit more in-depth stuff but this is what a general this star proves this is how they are being generated at the moment

in at a large scale okay uh okay this is fine so sharp uh is a is the shared prover So, SH ARP what it does is it aggregates Cairo jobs um and that is how the cost of verification for each job is like you know uh becomes very less otherwise imagine us as darknet we right now we are bearing the cost of generating all the proofs right but the only way we can reduce the cost is by having recurring proofs um so the jobs can be starknet blocks we also have another service called starkx so workloads from there or any other arbitrary cyro programs that

you decide to generate proofs on your machine let's say right and you want to send it to sharp directly you can do that as well uh we recently released this very u so sharp is one of the provers that has been battle tested for a few years now but we recently released a very very um um very fast prover called stew right and uh it is open source it is a staff prover designed for client side proof generation on real world devices. So if you want to generate proofs on laptops, you want to generate proofs on mobile and all of that, um it's this two is like your go-to prover and uh there's recent benchmarks that you know it has outperformed the established ZKVMs um

like risk zero and all of that SP1 also there is some figures around that uh and this is built on an interesting protocol called circle stack. So all of these are just enhancement of your stockproof protocol. Um and uh you here they use the Mercen Prime field M31. Um I won't go too deep into it but because of this we have certain performance gains in STO uh which are unavailable in existing star constructions like SH uh we also had another one stone prover right so this is like the new prover and this two prover is actually very interesting because not just darknet but there are a lot of other ecosystems as well that are interested in kind of experimenting and playing around with it. um in the doc

that I shared I've shared some documentation around this so that might be good to read and uh yeah so you I showed you in the previous uh architecture diagram so this pack registry has got to do with ethereum that uh how does ethereum know that bunch of these transactions have been verified that is where your fact registry comes into picture right it updates these information that is coming from uh uh from this from um the proof systems if the proofs are valid then they saved in the fact registry. So that's how Ethereum knows that something was executed. So when we say this is a layer 2, that is how we use the layer 1 where the layer 1 knows that yes x amount of things happen on layer 2 and I

have the proof of that and the stacknet OS or the sequencer is is also a kyro program that describes a blockchain network and what constitutes a valid state transition. So when transactions come to this sequencer, it has to make blocks out of it, right? So uh that this OS itself will determine whether a particular state transition is valid or not and uh this running this allows you to run the network and generate a proof you did. So like I mentioned recently we have sort of expanded on this whole decentralized sequencer stuff. So very interesting things that are coming up and uh the smart the staff network smart contracts will query the fact registry uh for the tpple uh in case it wants let's say what

happens if the sequencer crashes or you know there is an issue here. Uh that's where your uh fact registry comes into as a backup where you um you know query and see okay whether these transactions happen successfully or not. Yeah. So and then you kind of you know loop back into updating the latest state of starket. Um so the way proof systems work on starknet is that smart contract execution is included in a starknet job. Uh and this is included in the prover and the proof the sharp itself runs offchain. So you can actually run your own prover right uh but they are sent to ethereum to verify and the verification generates facts on chain that can be used by any smart contracts and the state of staffer is managed by this. So

when something goes down, you can pick back the state of uh starknet from here. How many times does a starket verifier verifies one proof? Uh starknet verifier will not verify the proof. The verifier lies on ethereum. So it will uh ethereum verifier verifies the proof. I believe it only verifies it once. So um you so it is as simple as just sending a proof to your solidity smart contract, right? And the smart contract will uh uh verify that uh verify that whether this proof is valid or not. Right? And it will just add it to the fact registry if it is valid. If you are saying how many times does this a action happen? Uh how often does this happen? I believe that might

be is that the question intended question like how many proofs go within a minute or something. Uh does starket have a test net to learn Cairo and test in all the starket stack? Yes. Yes, we have a test net. Uh it's called Seapoleia. Uh but if you want to play around with mainet as well is super cheap. So you can you can also do that.

Uh but yeah, that's actually all I had for today. uh if you are interested I can show you um some so I wanted to show this image I don't know if this is seen but it's a very interesting thing about execution trace and how they work um let me also share this on the engine b it seems um it's very fun I think Karolina because you have uh more security experience, I think you will you will enjoy this. This is like how you explore the execution trace

analysis and stuff in that context. Um I also shared some stuff over here some hello world example to start. Yes, I will I will add that actually. This is a hello world example. I will add that in the doc. Um so the the interesting thing about um uh Snarknet is that you can also actually verify ST snark proofs on starket. Um it is super interesting and um super somewhat out of my current depth of expertise but um there is lot of interesting stuff happening on this

where um you can basically verify noir zk proofs on starknet. So there is an SDK u that so there's an SDK that's released called Gaga uh that can do that for you. So you can actually um verify snark proofs on starknet. Um very interesting stuff, right? So you can actually so what this means is that you can use Cairo to also um verify a snark proof or I would assume that Cairo is so some sort of general purpose circuit that you uh take a snark proof which is a specialized circuit. um you build a proof of of that and then verify that that's it's very interesting. Um I don't

really know how more about the the the technical uh elements behind this uh because I haven't worked with noir so much but basically when you you can kind of you compile your noir code using garaga and it will uh automatically produce a noir prover and a noir verifier contract written in Cairo. And now that your both uh uh prover and verifier contracts are written in kairo, you can actually you know immediately deploy this on starknet. What this means is you sort of um you know you can move this proof verification to starket. The the whole thing about I think the whole idea of this is to have significantly

lower transaction fees and faster processing. That's it. There is really apart from this from an advantage perspective there is nothing much to much to it. Uh you can make your onchain life much much easier as compared to you know having to pay hefty amount of fees and you know waiting for certain amount of time and things like that. uh it right now it is very fast also because the sequencer is centralized right but when it becomes more and more decentralized of course it will become little bit slow but ideally not not as much because the amount of transactions that you'll be verifying also will be a bunch right instead of verifying one after the other so these are like I feel

certain really good advantages when it comes to like rollups validity rollups uh but from a privacy context I didn't add anything much because like I mentioned And it's very hard to do privacy stuff on a public blockchain like starknet. And you can do things like using this uh you know um Garaga SDK and you generate snark proofs. In this case they have given noir as an example but you can pretty much generate snark in any even like robust or what the basic the most basic circuit language right and then use that to verify that on stark. So there in your snark proof itself you might be able to add some level of privacy. Um right while writing the circuit you can hide certain parameters

and such but other than that the moment you go on a public blockchain that state change is almost immediately visible right so you will have to hide it right at your proof level and things like that and then you have no control once it goes on a public blockchain. So your parameters are anyway visible. That's why we don't also encourage people building that much privacy stuff. Um like I think one example that you know showed that is happening right now on starket is these mixers right. Um you are able to deposit publicly but you can withdraw privately right so there is some level of privacy that you can ensure but it's not too much and even to do this is like super complex. Um you can't you can't do that easily. So this

is I think one of the use cases that people are working on. We have a project called Typhoon that is building this privacy mixer. Uh but other than that anything else like all of this private voting and uh and stuff like that STAX doing privacy with STS is very very difficult very very difficult even mathematically very difficult. So if you do want to build something privacy related and you still want to leverage starket for the lower fees and faster processing fees uh sorry shorter processing time then I suggest to go the Gaga route which is you take Garaga SDK you generate your see at the end of the day anyway you're going to generate proof on client side if you want it to be private right so you can generate

client side proofs and then um send it to you know use one of these SDKs send it to starknet it'll be quick and cheap for you. So you have to do the privacy elements um yourself. Uh other than that I don't see any other um significant privacy um related stuff. But um yeah uh interesting interesting tech you should definitely explore and if you have any questions uh feel free to keep adding on to the doc just at any point in time also if you have any questions like even just like really basic stuff how does this work? How does that work? or if you get stuck somewhere, just add the doc.

Uh I'll make sure to keep looking at it frequently and uh you know, make sure to respond. I'll add some examples that you can explore and stuff. So yeah, super cool. >> Perfect. Thank you, G. It was amazing. >> Yeah. Okay. I I think I finished tried to finish it in 30 minutes because I have a habit of speaking more. >> No, no, no. G floor is yours and we love to hear you. So do we have any other questions that since Gan is here you want to ask?

>> Yeah. Uh is it because stark proofs are interactive and the verifier verifies only once? Um this is a good question. So the stark proofs the thing is there are there are ways to do interactive stark proofs and there are ways to do non-interactive st proofs as well. Um but because this is a so my understanding is this right that because this is a general purpose circuit you don't need to verify it multiple times like when you are verifying a specific circuit then you are trying to make sure that it is giving you that certain output like you're saying x + y is equal to 5 right so you're trying to do like x= 2 y= 3 and then y x= 2 3 and

y= 2 so you're trying to put as many things as possible to get convinced with 100% that okay like this person is saying x + y is equal to 5 but this works if you are running a specific circuit but in a general purpose circuit my feeling is this that general purpose circuit is optimized to verify and even the verification that will happen even though the contract verifies once I think that once verification itself will have x uh x number of random um random input because any verification essentially means that you are satisfied with higher probability and higher

randomness that this is successful like this is valid what you are saying is valid so in a even even though operationally the verification happens once I think that once itself will include this whole process of doing it multip multiple times. This is this is what is my my thought and I'm not 100% sure about this but I feel like this would be the process in n even in snarks like when you're doing non-interactive even though you're verifying multiple number of uh inputs for randomness that whole thing is captured in just one one block of

code which is we are calling it verify once like even if you do a snark circuit deploy it on a solidity verifier you just run the verification once. So that I would assume that it generates random points and does it in one block. It's my thought but I I'll share. Yeah. Uh oh there is uh more questions. Learning this is difficult. What advice do you give us to help? Um I would say just build apps like it has been for me it has been one of the most useful ways to learn right even if you're building a small app. Hello world app like you know just start somewhere small and don't go too deep into the mathematics of it

right like I'll tell you honestly I've been in the stark ecosystem for 3 years and even to date I can't explain stark fools properly okay I think sometimes I feel like none of my teammates have that confidence but because I'm a woman I feel even less confident right and I feel the only person who can talk about star cru's 100% confidence is Ellie okay so it is it is okay you don't but that doesn't mean like I'm not confident of building on starknet or I'm not confident of advising other people to build on stagnet in fact I built that profile over years so uh don't be don't be uh scared to start because you feel it is complex uh start with things that are small and ask questions ask a lot of questions I feel like this is one of the

things people lack a lot um and earlier I I have also seen like you know I and if you just uh feel like you have a safe space to ask questions that's it ask even if it's very basic like very small or you don't understand even how hello world program is working it's fine just ask questions I think this is the best thing right and um it's okay some days you'll find it hard but just got to push through and just you'll come be better on the other side for sure are there any questions I think >> not. Thank you for your time and it was

amazing and if you have any other questions uh you can use our telegram group and it's make everything more interactive. We can also join the conversation and thank you very much again like I appreciate. >> Awesome. Thanks for having me. Yeah. Thanks everyone. Yeah. >> Have a good one. >> Bye bye. Take care all of you. Yeah. Thanks. >> Bye. Bye. >> Bye. Thanks.