🛠 Zero Knowledge Proof (ZKP) Basics & dApp - Jacob Caban-Tomski

foreign [Applause] [Music] how's it going my name is Jacob cabantomsky I'm a member of the privacy and scaling Explorations group at the ethereum foundation and today we're going to go over some zero knowledge proof Basics and we're going to go over a template d-app project that uses zero knowledge proofs so kind of go over all the things we're going to cover today we're going to set up the template Repository we're going to go over very high level kind of how zero knowledge proofs work specifically non-interactive zero knowledge proofs we're going to go through a single Ed DSA signature demo time permitting we'll also go through a modification of that to handle multiple Ed DSA signatures and then I'll cover some additional resources for follow-up if you want to learn more and then finally we should have a good amount of time at the end for any questions people might have so um first for the template I'm going to be going through today we're going to just go over some of the kind of setup instructions um this is called zkp app boilerplate it is a uh app that some colleagues of mine have made um you can find it at github.com at privacy scaling Explorations zkp app boilerplate you can choose either to just clone it directly or there also is a useless template if you want to have something you can directly commit to on GitHub or show off um as far as the dependencies go um like kind of a standard D app it does use the node.js ecosystem and hard hat for all of that it also uses yarn and yarn workspaces for kind of managing everything in there it does also require your machine rust and cercom 2. those last two which are there are links to those on the main readme for installing uh take a little bit of time to download and run especially on kind of the local network here um what you get with that boilerplate is going to be a kind of react web app you're going to get the proof verification contract in a very simple um eddsa DSA um a mouthful circom circuit that you can kind of mess around with all right what are zero knowledge proofs so in a general kind of a setup for that we have a prover and a verifier um and so generally the proverb is going to be the person who generates the proof and the verifier is going to be the person who checks it and so in order for the prover to generate that proof it's going to provide a number of public and private signals as well as with the kind of proof itself to generate a proof that it's going to use to send to the verifier we're then going to send from that prover to the verifier that proof plus all the public signals but none of the product signals in for that and then finally the verifier is going to check whether that proof is valid using those public signals and that proof so basically we're just going to generate it transmit it and then verify that proof this is also known as a non-interactive proof in some zero knowledge proofs there is kind of a back and forth where the verifier will ask questions of the prover that it has to answer successfully this requires kind of a lot of chatting and so it has been simplified down to kind of this three-step process um as far as how that looks from those two different entities the prover and the verifier they kind of have a different view into what's going on inside of that proof um in this case for the prover which is going to be the D app actually generating it you're going to have your public and private inputs which in this case are just going to be numbers A and B there's going to be a check inside of the circuit in this case it's very simple a times b equals c and there's going to be an output at the end of the proof which is just going to be that result C um so essentially the prover has kind of that full global view over everything that's going on for the verifier it does not know any of the private inputs that are going into that and so we're just going to know the public inputs in this case a it's going to know the outputs and it's going to know the check that's kind of that's being run so in this case it knows nothing about B for this simplified example it would be pretty easy for someone to figure out the private inputs so if you had an output of C say six and a input a of 2 input B of 3 well you know six divided by two is three but in more kind of complex examples it's going to be more difficult for the verifier to kind of reverse engineer or figure out what those private inputs are for this demo app uh what we're going to have is we're going to have the d-app connect to the browser wallet it has a prover inside of it that's going to use to generate those proofs we're going to submit them as an actual F transaction to a ZK app contract so we're going to have that proof plus those public signals as the data inside of that transaction and then finally um and submit that to an RPC endpoint or a node and inside of the evm that ZK app contract is going to talk to our verifier contract which will be generated from those circuits and it will basically just return a simple Boolean saying whether it was successful or not cool so let's go ahead and dive in to that example for this case let's go ahead and just start with the repo I already have most of the dependencies installed so you normally would just have the as I said rust cercom and then you're going to also just do a normal yarn install to download all the npm dependencies you then to compile all the resources in the repo we'll just call yarn build this is going to compile and transpile all of the circuits for circom it's going to um generate that solidity code it's also going to compile all of the solidity contracts as well so right now this can also take a little bit of time uh this I think on average for me takes between about 40 seconds to a minute on this older laptop right here you can see it's uh generating uh the actual circuit um one thing we're also not going to go over in this is going through the actual um as part of generating those circuits you'll generally have a setup ceremony to generate kind of trust for that proof that's kind of all abstracted away inside of this project but you can certainly dig into it to see more how that was happening there yes sir we're going to get into that right after this so we finished that step and so let's go right into what is the circuit so I'm going to go through this repo and in general um there's going to be as I mentioned kind of the different components we have the actual app up here which is going to be the actual web app that's run we have the circuits and then we have the sorry the contracts and the circuits the circuits being the lowest level one and so let's go ahead and dive in right away to that main.certcom can everyone see this okay cool so in this sample code we have here and let me scroll down a little bit we're using starcom2 we are bringing in a library we are using um the circom lib has a EDSA Poseidon verifier which is what's going to actually verify those signatures that we send in and so we're going to talk about let's go to this template and I will go down a little bit okay so inside of our sample we have all of our signal inputs there's going to be they're split into public and private in the comments we'll get into how we actually Define what's public and private at the bottom of the template the first input is going to be M which is the message that we're signing ax and a y are the public key and that's going to be the two components of that and then private we're going to have the signature and then the R8 in X and Y are essentially components of that signature as well we're going to instantiate as a component that verifier here enable it and then we're going to pass through all of those inputs to this verifier for uh to be enabled um if for even a more simple circuit you can go to something um like CK Rebel and one of the simpler circuits you can do um is just doing that multiplication like I mentioned in that first example which would just be a star B output C um for this one though we're going to be demoing with those um signatures in there so we have this sample okay and then finally um for our main we're going to Define our public components which are m a x and a y and we're going to instantiate that sample down below so this is a very simple single signature verification circuit what this actually is going to generate when we run that transpile is a bunch of additional assets including some js code and some kind of lower level bytes for that circuit what the actual verification contract looks like is pretty complicated it's going to have a library built in which is going to be doing all of the pairing cryptography that's going to be involved in the proof General verification so you can see a lot of that here and then I'm not going to spend too much time on this but feel free to dig into it later and then we actually have the verifying contract and the important part of this one is going to be this proof the proof is going to have um three components a b and c which are just going to be points from that pairing cryptography inside of it and then we're going to have the actual verify function so this is what's going to end up being called to verify the proof that we pass in as well as all of the public inputs signals that we're going to pass into there as well um since this is a generated file uh you should not modify this directly because your changes will get overwritten on the Next Generation and this just ensures that the proof is valid as well so that kind of covers the circuit and then what we're going into as far as generating on the solidity side that we're going to use to verify that so now let's actually go into the demo app that we're going to use to kind of show this off and for that you just run after you've kind of set everything up and built you do yarn demo um you do need an address to kind of bootstrap this process for me um what I've done is I've actually loaded in the hard hat account at uh number zero and just loaded that inside of metamask you also need to reset your transactions to make sure that the nonsense that you're using in that wallet match up with your newly started kind of hard hat node for that you can also use another address just make sure you transfer some ethereum to it so it has gas to pay for the local network do and this is just a note once again to reset um that uh those hard head or sorry those metamask accounts so this is going to do a bunch of different steps there uh let me see if there's anything else I'll jump into before that so this demo app contained within it basically has a bunch of different components it will um deploy the contracts for you through the interface it will have a way to generate the signature that you need to pass in as that public signal and then finally we'll be able to generate that proof and submit the contract there so um let's go ahead yep starting up there hmm how's everyone's hackathon going thus far good bad nice oh we're waiting on that I can talk a little bit about this which I think is helpful this is a zkreple.

dev this is kind of an online editor you can use to modify circuits um in this case you can actually like test and Define everything inside of here and it allows you to actually run the circuits you can change the inputs here as well so for example if I wanted to say get 100 as an output or let's just say 120. let's see if that'll run yep and so we can see here um we have uh the difference uh parameters that we passed in the generated assets from that the hash that we're using for this Poseidon hash components and then finally importantly that input output which is 120 which was what we expect from 10 times 12. all right you're still spinning up there we go okay so to start off this is going to connect to your local wallet it also supports wallet connect if you're using um a different device I'm going to go ahead and just connect that hard hat account here next we're going to deploy the verifier so that's going to be that generated contract that we had um and that will be a transaction as you can tell my hard hat network is extremely busy right now uh handling all of these transactions and then finally we're going to deploy the ZK app contract all right so we've deployed it we've connected um let's look at actually that verifier contract to just kind of go over what's inside of that um so this is our verification contract we have an interface that we're going to use for that verify proof function that we're going to pass through and then um for the actual ZK app we have defined that proof structure we have a there's the verifier that we're going to connect to and then here's just a simple list of records that we're going to store after each signature verification the actual call we're going to do into this contract is record which we're going to pass in those public signals once again that message and then the two components of the public key and then the proof which is then going to call verify and then if that is successful we will just add to that records variable inside of the contract um for the verify we wrap that generated verifier contract in that interface call verify proof and then we just get a simple result did it work or did it not work and then finally to kind of see updates on whether it succeeded we have a total records uh that will check on the actual demo app itself which is going to be this highlighted uh amount right here let me Zoom this in a little bit so first we're going to create that local signature um and so that was pretty quick what this is doing on the front end inside of a react app is going to be using the sign EDSA signature here which is going to be using a local component to kind of generate that signature normally in ethereum for eoa accounts you're going to use an EC DSA kind of cryptography which is going to be very similar to Ed DSA the major difference from what I've seen is that eddsa does not use a random nonsense part of the signature so the signature should be deterministic for any given public key and message um otherwise they're very similar with some differences in the curves and some of the other things they're using so we went ahead and generated that signature we're now going to create a local proof with that public input and signals um and as you can see we kind of uh enabled that there so now we have our public signals that um and we also had our private signals which is the signature and the components of that signature and then we are going to and now we have the proof and now we're going to submit those as an actual transaction with the public signals and the proof to that ZK app contract and there we go so it was verified and confirmed we have our records updated um so we now have one record inside of there I could uh potentially I don't think there's anything preventing me from sending the same proof again since this doesn't verify that there's any sort of um confirmation for that yeah that is kind of that basic uh d-app example running through that and then um let me also show real quick just what it looks like inside of the app for that submission for the send transaction and so let's see here yep so we generated the proof and set it here into the state variable we're passing it through the actual call we're going to have to send the transaction is going to be just like any other kind of contract interaction so in this case we're going to go to our ZK app contract we're going to connect our signer so we can do a write to that and then we're going to call the record with those public signals and the proof um once again the components of that record are going to be the public signals the message and the public key components and the proof with those a b and c components that were generated um in that build step and so yeah that is our kind of very minimal basic functioning ZK app boilerplates are there any questions yes so these the signal is actually creating the signature so we're taking a um let me go into that real quick so we're going to grab our account that we've connected and use that as our private key very secure obviously and then using the the public key that we generate off of that using that signing signature that signal that's input um inside of the set for this that is going to be our actual input that's the signal is that actual signature along with the um the public key or sorry not the signature uh for generating the proof the signature is one of the private components that we're passing in so to go back once again to our circuits here so we've just generated the signature which is this input s and we also pass these other components in the R8 which are derived from that signature this message is just going to be I let me find that is going to be the simple constant just one two three four and hex so that will be the M components that we're passing in here and then for ax and a y is going to be that public key does that make sense so yeah when we go to actually generate that proof right we do not need a private key but we're only providing as our public inputs that message and the public Keys our private inputs in this case it's a bit contrived but it's the signature essentially that we're doing is the private input so when we in that d-app are generating that proof we are going to have both of those components the signature the mess and then the message the private key when the verifier in the contract is running it is only going to be able to see the message and the public key for that public input it cannot see the actual signature itself that we've used to sign it but it knows it exists and it verifies via the kind of underlying cryptography and math in that proof that that output is correct cool yes sir why do you need in the first place to generate the signature locally but you don't need the private key inside of the proof to actually verify that um that signature because you already have the components you need to verify the public key the signature and the message um in this case you probably could not you could generate an ecdsa signature but you could not generate that Ed DSA signature for that we actually have to go and use the um the JavaScript uh code that we generated from that build step um inside of our clients and I can dive into that real quick as well so that's going to be inside of this sine component and then this hook has been set so we can just more conveniently use it so we have this from our circuit Library and then inside of there is where we're going to actually init the signer with a private key um and then we're going to use that component once again here to actually sign that message cool James yes eventually if you are using a um say more account abstraction you will have the ability to generate different signatures that you could use from a wall natively cool yes [Music] so that is a bit outside of the scope of what I'm going to cover here um the uh the general um thing that I'm not covering here that you would bring in is something called a nullifier and essentially you have a um internal State managed by say like a Merkle tree and you use that nullifier to essentially like claim or burn ownership when you're moving those assets around that's what um like for example Z cash uses for transferring those different assets um I would probably look more into examples that are doing that kind of more asset transfer based thing there are also um our group which I'll bring up a link at the end to our website we have a number of projects that build on top of this technology for anonymous social media applications um asset transfers within say like a ZK or optimistic roll-up um and that would probably be a good place to start to kind of investigate that more I think there's also been some other talks that dig in more to that more asset or kind of nullifier based circuitry but for this we're just going to cover and for my own knowledge personally um just kind of this higher level basic circuit yep yes yeah so the verifier is only checking the verifier only has access to these top three components you as the prover or in this case the D app has those private components but the verifier doesn't have access to those um through how the mat once again a bit above my understanding um the cryptography and Mathematics involved in that verification process allow for the verifier to like be sure that given those public inputs and the output that comes out at the end that c um that it is a valid um proof and that those were valid inputs for that proof does that make sense no yes so yeah inside of that check for that proof that is what is actually I'm going to run inside of that uh that verifier component we brought in that is what is actually going to check that that private signature input um in this kind of abstracted form matches the inputted message and public key you can do um a lot of things one of the bigger ones as um gentleman over here mentioned is being able to kind of privately swap assets is a big use case um you can do uh things where I've seen examples where you may as say like a bank be able to have someone verify who they are by passing in say their social security number date of birth in a pin as private inputs and having a circuit that um runs to verify that they are the correct person without revealing those private inputs so I think in a lot of cases um the big two ones that are kind of always mentioned are going to be scalability and privacy there's going to be a lot less data for some larger computations that you pass from these proofs and these signals into your actual verification say on chain in the evm versus if you were to directly run all the computation yourself to check those in a contract and say like normal solidity code and then obviously the other big component is going to be privacy so if you have inputs you do not want to reveal to anyone else any case where you might be able to use those would be potentially a good use case to use azkp yes cool um I think I have roughly about two minutes left so I'm going to jump right to the end I am going to skip over um kind of that multiple example um for the zero knowledge proofs um but if you want to check it out on this repo there's actually a branch already set up for this you can ignore those wonderful errors uh you can actually just go and there's a tutorial um in that readme and a branch for that that you can check out that modifies the circuit so now instead of just doing one of these signatures and messages and I'm sorry one of these kind of payloads it now can do in this case we're setting it to three but you can see here how you can kind of expand upon some of those simpler examples and build them out into kind of bigger use cases finally uh a couple other things if you want to look for some additional resources um ethereum org has a really good overview of zero knowledge proofs and the further reading has some really good deep dives into the actual technicals of what math and cryptography are being used to generate these proofs and verify them the circum docs are really good if you want to learn more about writing circuits and the different components you can put into those um sir com lib which I showed with that sign verifier has a lot of templates and Primitives you can use when building circuits I showed off the um kind of online circum editor you can mess around with things and our group also has a um a bunch of zkjs lives in ZK kits that you can use in your kind of scripts servers or front-end applications along those lines if you want to learn more about us and some of the applications and things we build you can find us at appliedzkp.org and then uh finally um if you have any questions about this project or anything lck related you can jump into our PSE Discord and we have a question a channel called got a question you can also find that Discord on that applied zkp website and I believe I'm out of time oh one last question sure you're welcome cool awesome thanks everyone [Applause]