Fundamentals of Zero-Knowledge Proofs Full Course

Transcript

Hello and welcome to this fundamentals of zero knowledge proofs video where we will discuss what zero knowledge proofs are from a high level. So before we start I just want to explain to you that you can also go watch this course over on cipher updraft which I have linked down below. Ciphern updraft is a completely free educational platform for developers and web 3 professionals to be able to understand everything that you need to know about blockchains, zero knowledge proofs, defi and so much more. Cipher and updraft is really cool for three reasons. Number one, it's modular. So each of the lessons is broken down into videos which are much shorter so it's easier to come back to and save your place if you want to go have a break. Have you ever been on YouTube where you've gone away from a video or you wanted to go back and re-watch

something and you've forgotten or it hasn't saved the place that you were previously at. Instead of that you can just remember the name of the lesson that you were on and also Cipher Updraft will record your progress. The second reason which in my opinion is the biggest reason is that we have quizzes. Every couple of lessons you will have these quizzes created by the Cipher Updraft team to test your knowledge and it will really help solidify things. The third reason is that we have written lessons associated with the video lessons. So if you later want to come back and see what something that you learned was without having to re-watch the video, then you can read the written lessons. Or if you prefer to read knowledge rather than watch video, then you can do so. We also now have a search bar. If you just want to quickly search

some information, if you want to try out and have the really cool cipher updraft experience, then click the link down below. It is completely free. You will be required to sign up for a profile where you can just log in with Google or with your wallet or your email address, whatever you choose, but it is completely free. With that said, let's continue on with the video and I'll stop rambling. Hello and welcome to the newest course on Cipher Updraft, ZK fundamentals, or how I like to call it ZK fundies. This is going to be an extremely exciting course, so get ready. I hope you have a snack. I hope you have some water because this is going to be a great one.

It's a non-technical course. I'm going to walk you through a little bit in this lesson about what the course is about, who's it for, what are the prerequisites so that you're all set up and ready to get started. This course is only about an hour long, so you won't need too many breaks. If you want to take breaks, of course, take them. But if you want to do it all in one go, this course is short enough that you can just do that. The thing I will note is that it is extremely knowledge packed. It's quite dense with knowledge. So if you want to go away do some extra research, take some time to let the knowledge solidify then please feel free to do so. If you don't understand everything the first time that is completely normal. This knowledge took me a long time to get my

head around because there isn't too much information out there that is complete and actually tells you what zero knowledge proofs actually are and how they actually work. There is a lot of assumed knowledge. Anyway, I'm going to try and make this lesson as unrambly as possible. That is extremely difficult for me because I am a rambly person. So, let's get started. So, who is this course for? This course is for everyone and anyone. Anyone wanting to learn about zero knowledge proofs. It's for developers, non-technical people, BD, sales, marketing, aspiring ZK developers, people who already are developers. Maybe you're a solidity software engineer or you're a Python engineer and you just want to know a little bit more about zero knowledge

proofs. If you know absolutely nothing about zero knowledge proofs and you want to get started, then this is 100% the right place for you because we assume that you know nothing. So, as I said, this course assumes no prior knowledge of zero knowledge proofs. We're not really going to go into the math and we're not going to be doing any programming. There aren't really any prerequisites. However, I will assume that you have taken the blockchain basics course. If you haven't taken the blockchain basics course, then I will assume that you know what a blockchain is from a high level, how it works, such as hashing, things like that. the fact that blockchains are transparent and immutable. So if those things don't really mean anything to you, then I encourage you to go back and take that blockchain basics course, but there is no programming required. So you can just

get started straight away as long as you know high level what blockchain is. So why should you take this course? Why even bother at all? So zero knowledge proofs are the future because blockchains are inherently transparent by design. We need to be able to build privacy into systems so that everyone can't see everything at all times. There might be instances in which we want privacy which we will be going into in the course in a second. And in order to be able to build privacy into blockchain systems, we need a host of people who understand the fundamentals. And this is because we need people who can build cool projects and tech. We need people to audit that tech. We need people to promote and market the tech, sell the tech, etc. We need all roles to be skilled up enough to be able to understand zero knowledge proofs to be

able to fill these roles. So this course will hopefully equip you with the fundamentals in order to be able to get a job involving zero knowledge proofs or to expand your skill set. So what will you learn? This course is kind of like the zero knowledge proof equivalent of blockchain basics. So in blockchain basics we covered from a high level a non-technical overview of what blockchains are, how they work, what smart contracts are, etc. This is kind of like what zero knowledge proofs are, how zero knowledge proof systems work from a high level without going into any of the nitty-gritty details, without going into any of the scary math, without having to do any programming.

So, we'll cover what they're used for, obviously, what they are, the types of zero knowledge proofs, the terminology associated with zero knowledge proof systems, and the foundations to start learning more. So in the future dot dot dot you might be able to learn how to build zero knowledge proof systems with code and how the math actually works. So who the heck even am I? Who am I? My name is Kieran Nightingale and I this is my formal introduction. I'm a lead instructor at Ciphern Updraft. I have left my social links here because I also do some YouTube tutorials. You might be able to see some sneak peeks over there if you go and follow. And those are my handles on Twitter. I don't have the e at the end. So it's just Kieran Nighting

gal because it didn't fit. But otherwise, most places I'm just Kieran Nightingal with no spaces, no dots, no nothing. And I've built more than 10 hours of content on siphon updraft, including some cryptography content such as Merkel trees in the advanced foundry course. And I also did some lessons in the blockchain basics course. I thought I would add here that I'm a physics grad at the University of Bath. I feel like this is just to give me some more credentials as to why I can talk about cryptography things like zero knowledge proofs, but it's also just a fun fact about me. I also love to run and gym and I also do a little bit of painting in my free time. Not that anyone asked.

For this course, you will need to be using this GitHub repo to be able to navigate around the course. So, in this repo, you will have all of the necessary links. You'll see some resources for this course such as how to find siphon updraft if you're watching this on YouTube and a list of all of the different lessons with some helpful links like helpful blog posts etc. The other thing I have included here is some AI agents. Now as I said this content is a little bit complex. We're not going to go into the nitty-gritty details but some things might seem a little bit abstract to you. So I encourage you to chat haha pun not intended with AI such as chatbt find I really like clawude but

any of these AI agents are going to be great at explain the concepts to you. So if you don't understand anything the best thing you can do is just chuck your question into one of these AIs and it will give you a fantastic answer in most instances. The other thing you can do is go to the cryptography stack exchange and this will be a great place for you to ask technical questions about zero knowledge producing cryptography in general. And then we also we have the GitHub discussions tab as with all the other courses on siphon updraft where you can ask questions where I or someone from the siphon team can answer your question directly. But make sure that you have asked your question to AI first or possibly made a question on cryptography stack exchange. So, with all of that said, let's finally get into

it and learn what the heck even are zero knowledge proofs. What if I could tell you that I could prove I could solve a Rubik's cube without showing you the solved cube? Impossible? Not with zero knowledge proofs. They are the mathematical equivalent of proving you know a secret without actually having to reveal it. Wow. Welcome to our journey into zero knowledge proofs. Today we are going to be diving into in my opinion one of cryptography's most interesting topics.

So whether you're interested in blockchain privacy, scalable computation, or just love elegant maths and cryptography like I do, then gather around and welcome. Zero knowledge proofs are transforming how we think about privacy and verification. And by the end, you will understand what they are from a high level and why I think they're really, really cool. Let's start with a very simple scenario. Imagine you have two friends. Let's call them, as we always do, Alice and Bob. Alice has discovered that she knows the solution to Bob's very complex puzzle. And she wants to convince Bob that she's solved it. However, she doesn't want to reveal her solution because anyone watching or Bob himself might claim the solution as

their own. And this is where zero knowledge proofs come in. They allow Alice, who we call the prover, to convince Bob, who we call the verifier, that Alice in fact knows the solution. And crucially, without revealing any information about the solution itself. The magic here is that Bob can be 100% convinced that Alice does know the correct answer, but gains zero additional knowledge about what the solution actually is. To create a little definition, a zero knowledge proof or ZKP is a cryptographic method that allows one party who we call the prover to convince another party called the verifier that they know some specific information without revealing that

information itself. Let's give a real world example. Let's say you are over 18 or over 21 and you want to enter a club. In order to prove your age, you would have to reveal your date of birth. What if there was a way to prove that you are over 18 or 21 without revealing your age or date of birth, without having to hand over any ID? In order for a zero knowledge proof to be valid, they must satisfy three fundamental properties. And we're going to go into these in a little bit more depth in a different video, but I'm going to summarize them now from a high level. The first one is completeness. If the statement is true, an honest prover must be able to convince the verifier. The second one is soundness. If the statement is false, no dishonest prover can convince an honest

verifier except with maybe a teeny weeny tiny probability, but we're going to ignore that for now. And third, and finally, of course, it must be zero knowledge. The verifier or anybody else for that matter must learn nothing except that the statement is true. There's a lot of different terminology that we're going to go into in a different video, but I just wanted to take you through a few of the use cases. Since blockchains are inherently transparent, we need a way to also include privacy of our data and information such as wallet balances, we need to enable scalability without compromising on security and to rollups and so much more. Zero knowledge proofs might sound like magic and they kind of are, but they're based on solid

mathematics and cryptography. They provide a system in which we can have blockchain systems which also have an element of privacy and verification. And in the next few sections, we're going to take a little bit of a deeper look into what they are, how they work, all of the different terminology, snarks, starks, plunks, all of this information from a high level. So, I'll see you very shortly. There are two main types of zero knowledge proof. The first was an interactive proof closely followed by the non-interactive zero knowledge proof. Let's start with interactive proofs since they came first. Here there's a back and forth conversation between the two parties, the prover and the verifier. The most famous example is

the Alibaba cave, but for my example, I'm going to call it Patrick's cave. And I want to prove that I know the solution to his little cave puzzle. So Patrick says, "Here lies my cave. There are two entrances to this cave. Entrance A and entrance B. My cave inside is in fact circular. You can enter through entrance A and exit through entrance B. However, there's a catch. There is in fact a door that lies in the middle of this circular path with a combination code that only I, Patrick, know the Actually, I should be saying this in a lower voice. Only I, Patrick, know the solution to. You do not know the solution to this door

combination code. And then Kira says, "Ah, Patrick, you have forgotten. I am in fact a witch because I went to Hogwarts and I do know the solution to this combi code on that secret locked door. And Patrick says, "Prove it." And I say, "Okay, give me a puzzle and I will fix it and I will show you." And then Patrick says, "I know how to figure out if you know the solution. What I'm going to do is turn around. You are going to enter through an entrance. I don't know which one. And then I'm going to tell you which door to exit through."

So Patrick turns around. Kira enters through entrance A. Patrick says, "Exit through entrance B." She enters the combi code. She runs through and she exits through entrance B. Patrick is not convinced. He says, "How do I know you didn't just enter through entrance B and exit through entrance B?" And Kira says, "Ah, I guess it's a 50/50 chance. We'll have to repeat this a number of times until you are fully convinced that I do in fact know the combination code. So Patrick turns around again. Kira enters the cave. He turns back around to see that she has in fact entered the cave.

And he says, "Exit through entrance A, please." And then she exits through entrance A. He's still not convinced because there's 25% chance that she just went through the right side both times. So they repeat this again and again and again. And Kira gets it right every single time until finally Patrick says, "You know what, Kira? I am convinced you did go to Hogwarts and you are a witch because you do know my combination code. Either that or you saw it written in my EMV because I'm a loser and I write my private information in EMV files." And this is a tale as old as time. And it is in fact an example of an interactive zero knowledge proof. It's called interactive because there are multiple

rounds of communication between the prover who was Kira in my example and the verifier who was Patrick. But these types of proof are extremely timeconuming and these repeated interactions are not practical for blockchain applications because we need to maintain the state between the different rounds. So we'd have to store this information and only Patrick would be convinced that I do in fact know this combination code. If I wanted to prove to someone else I knew the combination code, they I would have to go through this whole process again of having to convince them with multiple rounds, which would be extremely timeconuming and annoying. And this is why we use non-interactive zero knowledge proofs where there is only one round of communication. And this involves sending a single message from the prover to the

verifier and contains all the necessary proof information. and the verifier can check the proof independently and they can be verified by multiple different people thus enabling trustless verification suitable for blockchain applications which we can integrate into smart contracts and decentralized protocols. One way I like to imagine non-interactive zero knowledge proofs is with the famous where's Wally example. This isn't really an example of a non-interactive zero knowledge proof since they're actually mathematical, so algorithmic funky math stuff, but they're a nice way to visualize what's going on. So, I have a where's Wally puzzle and I say I know the solution. I know exactly where Wally is, but I don't

want to tell you the solution. I don't want to tell you where Wally is. So, I could do a couple of things. I could photocopy the image. I could cut out Wallyy's head and give it to you and be like, "Hey, here's Wally's head." I could only do that if I knew where Wally was. The other thing I could do is get a really large piece of paper, so large that it you can't even see the underlying piece anymore. I could cut a little hole and then align it so that you could see I knew exactly where Wally was. And you would be fully convinced that I knew in fact where Wally was without revealing to you exactly where in the picture he in fact is. There are many different types of non-interactive zero knowledge proof including snarks, starks, bulletproofs, and these are actually umbrella terms. For instance,

snarks encompass both goth 16 and plonk, but these are all just different types that work in different ways using different cryptographic methods. We will go into these and their differences a little bit later. By using non-interactive zero knowledge proofs, we have enabled lots of different use cases such as verifiably proving your identity or your age, proving your balance is above a certain threshold, verifiable computation in a blockchain, and so much more. Before we continue, I think it's important to define some terminology that's going to be used throughout this course and also future ZK courses on updraft. So, if you're going out into the wild to do your own research on ZK proofs, then you'll understand what these terms mean. I think it's important to point out here that although I am

going to define these terms, not everyone uses these keywords in exactly the same way. Sometimes it depends a little bit on the context and there is some disagreement on the exact definitions. So in some circumstances, there may be a little bit of variation. You're not going to find full consistency everywhere. Regardless, it's still important to understand what these keywords mean before you see them being used out in the wild and in order to understand what they mean depending on the different contexts. So the first key word is claim or statement and often these words are used interchangeably. A claim or statement is an assertion that something is true. In the context of zero knowledge proofs or ZKPS, it refers to the property being proven without revealing any additional information. An

example of such statement or claim is I know a number X such that X to the^ of 2 equals to 9. This is the statement or claim that the prover wants to prove to the verifier without revealing X. Another example could be, I am over some minimum age, therefore I can enter your adults only club. The prover needs to convince the verifier that they are over the minimum age without revealing their age or date of birth. So to summarize, the statement or claim is the thing that the prover is proving to the verifier that they know without revealing any additional information about what it is that they know. Next up, we have private and public inputs. An input is like a variable to your zero knowledge proof system. This is going to make a bit more

sense as we go on. So bear with me for a second. So in a zero knowledge proof system, inputs can be categorized two ways. First of all, private inputs. These are values in the system that are only known to the prover and not the verifier or anybody else. For example, passwords or secret keys. And these are part of something known as the witness, which we're going to define shortly. This is as usual most easily understood through an example. Let's return to our original examples. In the statement, I know X such that X to the^ of 2 equals to 9. X is an example of a private input. Or for the claim, I am above some certain age and therefore I can enter the club. Your age is an example of a private input. The second type of input is a public input. And as this sounds,

this is a value that's known by both the prover and the verifier. And it's used to check the proof's validity. This can include things like commitments, a public key, or a hash digest. But again, this is best explained using an example. The first example doesn't have a public input, but the second example could. I am above the threshold age and therefore I can enter your club. The public input could in fact be the minimum age 18 or 21 etc. This could be an example of a public input that's known by both the prover and the verifier. The next keyword is a constraint. This is a mathematical equation or condition that must be satisfied for the claim to be true. The constraints define the rules the inputs must follow to be valid.

Exactly how they expressed depends on the specific constraint system. I'm going to touch on this from a very high level. But don't worry too much about proving in constraint systems. Again, let's return to our examples. So for the claim I know X such that X to the^ of 2 equals to 9. The constraint could be assert that X ^ of 2 equals to 9. The specific structure of this constraint depends on the specific proving system. For example, in an R1 CS proving system, this could be broken down into intermediate steps where we first say that X * X equals to an intermediate value zed and then Z - 9 must be equal to zero. And this specific structure is used in the R1 CS proof system. And this is exactly the same as saying that X ^ of 2 equals to 9, but it's just broken

down into an intermediate step. Don't worry about this though because in most instances when we are writing constraints, this is abstracted away. So you don't need to know too much about this. I just wanted to touch on it very briefly. Let's return to our second example. I am over the minimum age and therefore I can enter the adults only club. The only constraint would be that we would require that the age is greater than or equal to the minimum age. So there are multiple types of constraint systems that dictate how these mathematical rules and assumptions are structured like plonkish constraint systems or R1Cs. But most of the time these differences are abstracted away.

For example, if you're writing your zero knowledge proof program using a language like noir or circom. Next key word is circuit which you might have heard already in the context of zero knowledge proofs. But what actually is a circuit? A circuit is a system of these constraints. So it's represented as a series of mathematical relationships and operations. The circuit defines how all of these constraints work together to verify the claim. So all of the constraints together need to pass to convince the verifier. Let's return to our second example. So for our first example, we could only have one constraint. So therefore, our circuit is in fact just this one constraint. In our second example, I am over the minimum age, therefore I can enter the club.

Perhaps we also want to have a maximum age. I am over this minimum age but below some maximum age. Therefore, we would have two different constraints. These two different constraints together would make up the circuit in this example. The next key word, which we've mentioned already very briefly, is a witness, which again you might have seen out in the wild when reading up on zero knowledge proofs. A witness is the set of secret values that allow a prover to demonstrate that a statement is true. It does include all of the private inputs, but it could also include intermediate values computed during proof generation.

So, just all of the information that the prover needs in order to prove that their initial statement is true. The witness must satisfy the constraints of the circuit to ensure that the claim is valid. In some instances, such in Vitalix's QAP's blog, the witness refers to the assignments of the variables in the circuit. For example, for the claim I know X, such as this X to the^ of 2= to 9, the witness could be X. But in some examples it could include intermediate calculations such as x to the^ of two. Finally, now that we have defined all these other terms, let's redefine the prover and the verifier using these terminology so that we get used to things. So the prover as we said before is the entity that generates a proof by demonstrating knowledge of the witness while satisfying the circuit constraints. The prover does not reveal

the witness but still convinces the verifier of proof of computation and this enables them to prove that the statement was initially correct. So they can prove that their inputs satisfied the constraints and then they can prove that this computation was successfully performed. The verifier checks whether the proof is valid given the proof and inputs. The verifier runs a verification algorithm to confirm whether the prover's claim is true without revealing any additional information. This verification could be done offchain or a verification smart contract could be generated in order to verify the proof onchain by anyone. So that was just a whistle stop tour on different ZK terminology. If you found any of this

confusing, don't worry too much. Just make sure that you keep reading blogs, keep watching videos, re-watch this video in order to get familiar with this terminology because it is difficult. There's a lot of nuance here. So the more you surround yourself with the information, the easier you're going to find things. There is one final piece of terminology that I want to define and that is the trusted setup. This is going to be a little bit longer as there's a bit more information you need to know here. So in the next video we are going to go into the trusted setup from a high level. What is the trusted setup? The trusted setup is a crucial step in certain ZKP systems, particularly in snarks like groth 16 and plon which are examples of specific types of snark. Understanding

what the trusted setup is from a high level is essential for grasping how these proofs remain secure and efficient. And by understanding what the trusted setup is, it enables you to be able to understand comparisons between different ZKP systems like different snarks and also starks. So what actually is the trusted setup? To quote Vitalik, a trust is setup ceremony is a procedure that is done once to generate some data that must be used every time some cryptographic protocol is run. So a person or a group of people have to create some secret to generate this data. Once the data has been generated, the secrets must be destroyed. It is the initial step in generating a zero knowledge proof where cryptographic

parameters are created. These parameters must be securely generated as any compromise could jeopardize the security of the entire system. There are some key concepts associated with the trusted setup that I'm going to walk through now. Initially, we have something which is referred to as toxic waste. During the trusted setup, random values are generated. If these values are leaked or compromised, an attacker could forge invalid proofs that would pass verification in order to maintain security. These random values must be securely destroyed. Next, common reference string or CRS. This is a set of public parameters that both the prover and the verifier use in the proof

generation and verification process. And this is the cryptographic parameter that is created during the trusted setup. Next, we have structured reference string or SRS. And this is a specific type of CRS, but instead it contains structured data, data with a specific format. For example, elliptic curve points. So points on elliptic curve where these points are derived from a secret value. For example, you could generate a secret value towel. This is an example of toxic waste. And the SRS would be some generator point, a point on the elliptic curve used to generate the other points with different powers of this towel. You don't need to know what this generator point is. You just need to know that the SRS is structured

data and in some instances uses this secret toxic waste value TOA which we're going to return to shortly. Next, we have multi-party computation or MPC. This is used in lots of different instances, but specifically we're referring to MPC in the context of zero knowledge proofs. And this is a security enhancing process where multiple parties sequentially contribute to creating a final parameter such as Tao. Each participant receives the current parameter, their own secret transformation. They contribute a tiny bit of randomness and then they pass on this parameter. They then destroy their contribution. The security comes from the fact to reconstruct the final random value, it would require all participants

to keep their secret. So that means that even if there's only one honest party that destroys their contribution, the secret cannot be reconstructed and the system remains secure regardless of whether some parties were malicious and kept their contribution. Think of this a bit like a chain of locks. If one person in the chain destroys their key, the full chain can never be unlocked. Even if everybody else kept their keys, there would still be one lock. We've touched on briefly one specific type of trusted setup, and that is the powers of tow. And this is used specifically in snarks like groth 16 and plonk. The powers of towel is a series of elliptic curve points generated using a multi-party computation. It's called the powers of

towel because each of these elliptic curve points are created by some secret times the generator point. So to the 0 or 1 * g is the first elliptic curve point. Tao to the 1 * g is the second one. Ta to the 2 * g is the third one and then so on. Crucially, by using a multi-party computation, no one ever needs to know TOAO. There is a separate multi-party computation that happens for each elliptic curve point, which you'll be able to see in the graphic here. So, pause if you want to understand how this works. But essentially, each person is contributing their own randomness, their own value of tow, which all collectively come together to create this towel, which cannot be calculated unless you have every single person in the

multi-party computations contribution. The trusted setup could also include something called a polomial commitment. And this is a cryptographic method that allows you to commit to a specific polomial while keeping the coefficients of this polomial secret. And this allows you to prove properties of this polomial later. Different proving systems use different commitment schemes. For example, one type of specific polomial commitment scheme is the K z commitment. Essentially a polinomial commitment is a way to say this is the polomial that I am going to be using without revealing the coefficients of said polomial. Let's go through some trusted setup examples.

And here we're specifically going to be focusing on snarks as they require a trusted setup. So trusted setups can either be circuit specific meaning that they need to be regenerated for every specific circuit or universal meaning they can be reused for different circuits. So groth 16 is an example of where the trusted setup needs to be circuit specific. It is a two-phase setup. The first phase is the powers of tow phase where a general purpose SRS is generated for circuits up to a certain size. This part is not circuit specific and can be reused. This is where the powers of tow are used to generate these elliptic curve points. Then we have the circuit specific phase where the parameters from the first phase are

combined with the circuits constraints to generate a proving key which is used to generate the proofs and a verification key which of course is used to verify the proof and this is specific to the specific circuit. So this part of the process needs to be repeated for every new circuit. The plon trusted setup is an example of a universal setup where it is not circuit specific. It uses a universal and adaptable SRS, meaning multiple circuits can reuse the same setup as long as they fit within a certain size constraint. Again, we use the powers of tow process to generate an SRS, which is then used for a polomial commitment. Plon systems commonly use a KZG commitment scheme where polomials are committed using the powers of tow

and evaluated at a certain challenge point. So to conclude the trusted setup is a foundational concept in zero knowledge proofs specifically in snarks. It introduces an initial trust assumption but by using techniques like multi-party computations and universal setups we can mitigate these risks. Next let's go through some use cases of zero knowledge proofs and where they are being used already today in blockchains. There is another important and somewhat confusing distinction I want to make. Zero knowledge proof of knowledge versus zero knowledge proof of computation. In our previous video, we introduced terms like circuits and other zero knowledge proof terminology. Despite the name, zero knowledge proofs aren't always just

about proving knowledge of some secret. More often, they're used to prove correct computation. Prove that I correctly computed these constraints and therefore know the valid inputs. When we talk about zero knowledge proofs, there's a subtle but important distinction to understand. The term zero knowledge refers to the privacy property, the fact that you're revealing nothing beyond the validity of the statement being proven. But what exactly are we proving? So, thus far, we've assumed that we are proving knowledge of some secret. But in most instances, we're not actually proving knowledge of a secret, but rather we're proving the computation was performed correctly, and thus we know the secret inputs. So by creating a proof of computation, we

indirectly create a proof of knowledge of the private inputs. So we're kind of wrapping up this proof of knowledge into a proof of computation. Going back to our previous example, that our age is above some minimum age. Instead of proving the actual age, we are proving that our age is more than some minimum age 18. We're proving that we performed this computation correctly. Therefore, we must have had the inputs which satisfied the constraints. That's why we use terms like circuits. These represent the computational steps being verified.

A circuit is essentially a mathematical representation of a computation with inputs, operations, outputs, etc. The mathematics of the ZK proof was developed to prove the original statement. My age is above some minimum age without revealing the value. So whilst yes, ZKPs can be used to prove knowledge of a secret, really what you're doing is proving valid computation and therefore knowledge of a secret. Let's go into a little bit more detail for those three requirements for a zero knowledge proof. First, completeness. If the statement is valid, the proof must always be able to convince the verifier if they have knowledge of the witness.

This is a common case for bugs in zero knowledge proofs in which the code that defines this zero knowledge proof is such that a valid input will not produce a successful zero knowledge proof that passes verification. An example of this could be I am over 18 and so even though I'm over 18, I do not pass the zero knowledge proof and I cannot convince the verifier. Going back to Alice and Bob, if Alice is honest and follows the protocol, she should be able to convince Bob. The second one is soundness. So, it must be practically impossible to convince the verifier and trick them with an invalid witness. If I'm not over 18, it must be impossible to convince them that I am over 18. Well, 99.9999999%

impossible. If the prover doesn't know the information, they can't trick the verifier into thinking that they do. This is another common cause for bugs in zero knowledge proof systems in which invalid inputs produce successful proofs that pass verification. And third and finally, zero knowledge. The verifier must learn absolutely nothing about the solution. Only the prover must be able to know the solution to the problem. They cannot extract this data out of the proof itself. And this is again another cause for bugs in zero knowledge proof systems in which this input data is in fact leaked. But through using things like snarks and starks which are types of zero knowledge proof systems that

have been thoroughly written about and built into systems that you can use as developers. You do not need to write them from scratch yourself. For instance, by using Noir or Circom, you can create these zero knowledge proofs without having to worry about exposing your inputs. So, we've covered how ZKPs are used. How do we actually create one? How are they actually used in applications? In this video, we're going to go through step by step how we use ZKPs practically, breaking it down into the front end and backend components, as they're sometimes referred to, and what this means.

Generally speaking, a ZKP system comprises of two components, the front end and the back end. The front end is the constraint system. It's responsible for defining the problem. Mathematically, this is your circuit and includes the computations needed to generate and verify your proof. And typically, these circuits are written using a language such as circum or noir. We'll come back to this shortly. Then we have the backend. And this takes your constraint written in, for example, noir or circum. It takes your circuit and generates the cryptographic proofs that can then be verified without revealing the underlying data. But this sounds a little bit up in the air, still a little bit abstract. So let's break this down into steps. Let's start in the front

end. So the first step is actually arithmetization. This term sounds scary, but all it means is breaking your problem down into a mathematical form. So for instance, with our example of a minimum age to enter a club, and I want to prove that I'm above this minimum age, it's simply boiling this problem down into the age being greater than or equal to the minimum age. And this process is referred to as arithmetization. So representing the problem itself as a circuit consisting of those constraints that must be satisfied where a collection of constraints together is the circuit which is written with your language like noir circum or cairo and these languages are examples of domainspecific languages or DSLs and these languages allow us to

describe the circuits efficiently and abstract away a lot of the complexity which is why you don't need to understand in depth how ZKP math works and things like R1 CS and different constraint systems. Instead, you can just understand how the DSL that you're using works. And this is because a lot of these languages compile into ACIR, which is an intermediate representation, which is then processed by the proving back end to create the proofs and verify those proofs. Cir is a bit of an outlier here as it compiles directly to R1CS constraints, but you don't need to worry too much about that. Once the circuit has been compiled, the prover needs to generate the witness using their inputs.

Usually, these inputs are inputed into a file and then the witness is generated using the intermediate calculations required to create the proof. From now on, we will be in the back end. Next, we need to generate the proof. The witness is then used to create a proof of execution. And of course, this is done without revealing any of that sensitive information. This allows the prover to demonstrate knowledge of the correct solution to the circuit without revealing those actual values. So the proving back end processes the circuit representation that your DSL processed your circuits into. So whether that's ACIR or R1CS as with circum it processes this representation and uses the witness to generate a cryptographic proof. And then finally verification. So the

verifier checks the proof against the constraints to ensure that the prover does have knowledge of the correct values. If everything checks out, then the proof is considered valid. The backend can also be used to generate a smart contract, which can also be used to verify the proof as well. If you wanted your proof verification to be on chain, which in my opinion is super cool by allowing you to generate or verify a smart contract and deploying it on chain, it allows anyone to verify the proof of course without revealing any of the underlying data. And this is key for things like private transactions or scalable rollup solutions. So to summarize this video, in practice, ZKPs involve arithmetizing the problem into a circuit using languages like Noir, CIRCOM, and Cairo. Then using a backend to generate a proof and then verify that

proof either off-chain or onchain using a generated verifier smart contract. And that's everything you need to know about practical ZKPs from a high level and uses the witness. Let's go through some real world applications and some use cases of zero knowledge proofs to understand why they are so useful and therefore pretty cool. So by now hopefully you have an understanding from a high level how ZKPs work and what they are. But where do they actually get used? So zero knowledge proofs actually have a wide range of use cases both within blockchain systems and outside. They can be used for any sort of privacy preserving application. For instance, authentication, proving that you have the right credentials without having to

reveal your credentials. Think private login or private identity. ZK KYC, prove you are who you say you are without having to reveal your government identity. Now, the list of possible use cases outside of blockchains is massive, but I'm going to focus on zero knowledge proofs within blockchains and their use cases there. So in blockchains in general ZK proofs can solve two major problems that is scalability and privacy. While the inherent transparency of blockchain systems provides many benefits which by the way we cover in blockchain basics. So if you haven't watched that then I encourage you to do so. There are many instances where we do in fact want privacy. Maybe I don't want to reveal my exact wallet balance and

therefore be vulnerable to attack. Or maybe I have a private vault or a savings smart contract and I don't want people to know the balance of this smart contract. By using zero knowledge proofs, we can prove knowledge of something without actually having to reveal it. In blockchain systems, zero knowledge proofs enable both private data in a transparent system but also provable computation which helps with scalability. First, let's focus on the scalability part. And this of course leads on to L2 rollup solutions where zero knowledge proofs are used to verify state changes and therefore improve scalability of L1's like Ethereum.

Again, this was covered in blockchain basics. So I'm going to do a very quick recap of rollups and why and how zero knowledge proofs enable this scalable solution. So ZK sync era is an example of an L2 rollup that uses ZK proofs. So transactions are actually batched offchain and then this data is bundled together and then this bundle of transaction data is then submitted to the L1 for verification. So what they do is they generate a ZK proof that proves the state changes for these bundle of transactions. So instead of having to submit all of the transaction data to Ethereum or the L1, only the proof and the transaction bundle are actually submitted which drastically decreases gas fees. So actually the transaction information is still transparent. ZK

proofs are not being used for privacy. They are purely being used to prove the state changes and prove that transaction inclusion in order to improve scalability and reduce those gas fees. And sometimes these types of roll-ups are not actually referred to as ZK roll-ups. They're referred to as succinct roll-ups where the transaction data is not kept a secret. There are some instances of private state roll-ups where ZK proofs are both used to improve scalability and prove computation but also for private state such as addresses, balances, etc. An example of one of these types of solutions is Aztec. So moving on from rollups, we can also use ZK proofs to privacy preserve in our onchain transactions on existing chains like Ethereum. So some

applications have been built already that use ZK proofs to keep information secret. One such example was Tornado Cash which used ZK proofs to mix different users funds allowing people to withdraw anonymously. They did this by breaking the chain between the sender and the receiver using ZK proofs for privacy. We can also enable things like private airdrops, private onchain voting where you can't see what address voted for what and so much more. ZK proofs are also being explored for identity verification in web 3 projects like Polygon ID that allow users to prove aspects of their identity without exposing any unnecessary details. And this is great for things like onchain KYC without you having to reveal any

confidential information on chain. We've talked about introducing privacy and also scalability to existing chains. What about privacy first blockchains? Some L1's are built where privacy is at its core. Zcash is a famous example of such an L1. It was launched in 2016 and uses zero knowledge proofs to enable fully private transactions where users can choose between transparent and shielded transactions. And this is in fact one of the first examples of a largecale application which uses zero knowledge proofs in blockchains. So it's a pretty famous one, hence why I've included it here. And the final example that I want to draw to your attention is bringing web data onchain but privately.

So let's say I wanted to prove something about some private web data like my bank balance but I didn't want that information to be public transparent onchain but I still wanted to bring that information or proof of that information on chain and the way you can do this is actually using solution by chain link called deco which is an acronym for data enabled computation oracle which allows you to as I said prove things about private web data on chain without revealing the actual data and this enables you to do things like bring proof of bank details or bank balances on chain or verify your age from an official document without revealing your date of birth and then bringing that proof onchain in a decentralized way by using the decentralized oracle network.

This enables us to connect traditional web services with blockchains in a privacy preserving way. Currently, you can only use Deco in a sandbox environment, but I encourage you to play around with it if you're interested. So to summarize, whether it's scaling Ethereum, enabling private transactions, or proving your identity without giving up your privacy, we have no doubt that zero knowledge proofs are the future and are going to play a critical role in the evolution of blockchains with the need to balance transparency with privacy. And in the final part of this crash course, we are going to go through from a high level how we can use zero knowledge proofs in practice. How would someone go about building a zero knowledge proof into their application and how does this work?

So you have now got to the end of this course of zero knowledge fundamentals. So hopefully you now understand what a zero knowledge proof is. The difference between interactive and non-interactive zero knowledge proofs. So the rounds of communication the zk terminology such as provers verifiers trusted setups circuits constraints claims statements and more. Hopefully you understand the fact that zero knowledge proofs have to have zero knowledge and what that means completeness and succinctness. And then we have seen some example ZK projects and how ZK projects are actually structured. Now of course if you have any questions please drop them in the GitHub discussions tab associated with this course or ask your favorite AI agent because this knowledge is going to

take a little bit of time to really solidify and now you have the foundations that you need to be able to learn more to be able to go and build your own ZK projects or learn more in depth how the math works. So stay tuned. Thank you so much for watching. If you have enjoyed this course, then please let us know on Twitter by tagging meing gal or @ciphon updraft or both and let us know that you have finished this course and that you enjoyed it. And if you have any feedback then please let us know and I will see you very shortly in the next one. Goodbye.