ZK HACK III - Building On-chain Apps Off-chain Using RISC Zero

Transcript

foreign welcome everyone Thanks for attending uh this Workshop it's a bit different than what we build uh we realize once we got into this that really needed to make a series of workshops uh today we're gonna be focusing on building ZK apps with rust but first I want to kind of tell everybody a bit about yeah about risk zero and Tim yeah so just so people can wrap their head around you know what ZK VMS are and how River zero works the kind of two main approaches to writing programs in ZK you can take the sort of

direct path where you have some kind of language like circom or any of these other ones that feed into a compiler which then produces this sort of arithmetic circuit that you know then shove inputs into and a proof comes out so this is you know a very useful way to construct ZK circuits um but depending on what you're trying to accomplish it can be uh sometimes better to to make the circuit that you construct an actual VM so things that implement this kind of uh approach are things like maiden um [Music]

Cairo obviously and of course us so in this world uh you take your sort of language written you know in whatever your VM can understand that program that you write goes into a compiler which produces some kind of ir or Isa and that itself the program is an input into um the sort of VM circuit that you have just like another input so the circuit doesn't really change from program to program rather you have a program that's an input as well as sort of the actual data inputs those produce proofs next slide so the risk zero zkvm implements risk

five so risk five is a micro architecture it's an open source it's in standard micro architecture as opposed to say arm or x86 which are proprietary microarchitectures there are other examples of open microarchitectures like mips or semi-open um and then also you know there are sort of quasi-micro architectures like Blossom so we here at resero implemented a circuit that represents a risk-5 microprocessor now the cool thing about this is that you can use instead of making your own language and making up your own Isa and writing your own compiler you can use lvm and or GCC and in theory any language you want we've

initially focused on Rust support and trying to build up you know a really uh usable and sort of idiomatic way to build ZK programs in Rust and that's the focus of this Workshop that Tim and Jeremy are going to be uh walking you through there's a bunch of other stuff we'll be covering about risk five uh in in other workshops um and uh so next slide so I did want to highlight that we're in the middle of dumping uh we dumped a ton of code for version 1.0 so if you look at our main repository it's all there and we're in the process of running through some release candidates before we actually push this out the material

today was all built against the sort of current release that once we once you release the new release um uh sorry multiple people from the office um once you release uh version 10 there will be a couple changes that are going to be required um and we'll update the examples that people go through in this Workshop once that happens um and then lastly I did want to you know the the title of the of the session was building on chain uh apps on chain and I do want to mention that uh Tim next slide that uh yes uh the ability to do this will be coming to a chain uh near you

very soon um but we're not quite ready to announce anything today um and with that I'll hand things over to Jim thanks Brian um that's a great introduction to what we're trying to accomplish here with risk zero so hi everyone my name is Tim zero I'm a senior software engineer here at risk zero I also lead developer experience um at risk zero so I'm the person leading the work making sure all of you can understand how to write code using our code as best as possible and with me is Jeremy who I'm not sure if he's on the line yet Jeremy if you are do you want to introduce yourself

uh yes can you hear me yes yes hi so I'm Jeremy uh I am the chief scientist um I'm sort of the person who's most heavily involved in actually building the underlying uh sort of cryptographic systems that make the as your knowledge proof system work um uh and one of the co-founders of the company um so I'm mostly here to be able to help out or answer any questions that are you know highly technical or you know uh things along those lines so great thanks Jeremy for being with us um and let's just dive in so what are we trying to accomplish with this Workshop so is people at DK hack I think we're

generally coders of some sort and what I really want you to be walking away with is writing your own code I think everyone in this Workshop if you have at least a vague understanding of rust already you should leave this Workshop able to prove things in Rust to prove that you have executed a program and produced a certain result in Rusk using risk zero and zkbm um so this Workshop is going to be pretty heavily focused on coding um we're going to be going through a bunch of examples with me um we're going to have a exercise where you can write your own code we also have a place where you can follow along with the code I'm writing and write it on on

your own machine um as well as just looking at code um there certainly is also going to be General content explaining things if you're not a developer there is some content here for you but this is really focused on the practicalities of enabling all of you to write code and prove things prove that you executed that code using risk zero and in turn in what we want whatever sort of applications you are dreaming of we want you to be focused on your code what this Workshop is helping you to enable is that you can use risk zero as a tool and that in some ways that risk zero is another rust

crate that you're able to use amongst your other rest crates when you want to do proofing when you're working with this risk zero we want you to be writing Rest code we don't want you to have to learn the cryptography behind writing secure constraints we don't want you to think about the language properties of some ZK specific DSL that you haven't used anywhere else we want you to learn rust and use rest um as the devx lead it's my responsibility to help teach you stuff but I'm never as hard as I work at this as amazing a job as I do and I hope I end up doing a good job I'm never gonna be as good as the Rust book I'm never gonna have all the compilation support of Russ throws amazing

exceptions except that I will because this is in Rust you're using rust you write Russ code we're another rust crate we want you to be able to focus on your code not our language we also want you to focus on your code not supporting code if you have some sort of project where you need to prove something about Json we want you to just include the Json crate as a dependency um if you're looking at our final example from today where I'm going to be proving ZK Checkmate I'm going to be showing you a chest position and saying hey guess what I can prove that there's a made in this position I don't have to tell you what it is but there's a Checkmate and I can prove it I can

convince you of it without showing you the Checkmate and for that code I didn't want to have to write chest excuse me I didn't I don't want right off chest um and so I didn't right I used a test crate and you should be focusing on your unique problem that you are solving not all the utilities needed to build that and we think Russia can bring you that so what's on our agenda for today well as I mentioned there's going to be a bunch of code so we're going to go have examples one where you prove that you know a factorization of a number without actually revealing what it is um we're gonna prove that a password

meets some password criteria that has a special character without revealing what the password is just as hash okay and go through proving some properties of a Json file without actually revealing that Json file will have this chess example that I just talked about where we prove a Checkmate without revealing the Checkmate and I'm also going to um show you how to clone our template so you don't have to write the boilerplate code that's needed just to get the ball rolling um and along with that we're going to be explaining our architecture what sort of scenarios you're going to want to use risk zero in um we're also going to be talking about design principles when designing risk zero zkvm code um

one of the advantages of I don't have to teach you rust is that I can focus on design questions rather than just how I do it questions although by all means I will certainly also be focused on how I do it questions and there's going to be a section that's probably the least applicable to actually writing the code but I think it's really cool which is some how it works at the very end we'll explain a bit about how it works under the hood not a lot because two hours is not nearly enough time for that and this is focused on the code but there will be some explanation of what's going on so that's the plan for today um and I realize I can't check for questions very easily because I'm sharing my whole window I'm gonna just try and do this anyway oh goodness okay

if you want I can also pop up if I if they start to build up and read them would that help yeah maybe you know what I'll ask for questions you can also pop up if there's an urgent one but I'll ask for questions at times and if you could tell me that that would be super helpful perfect yeah so there is one I can please go ahead all right I'll I'll you mentioned writing rust is writing rust as is for crates that may have non-deterministic Imports input sources would it make sense to generate a proof over that execution um certainly you have to be careful about the non-deterministic input but absolutely you can I think Jeremy might be able to say more details about what

it takes to be working with non-deterministic yes I mean basically um whenever so that I think we'll get into this a little bit more detail but effectively when you read from the input of course anything coming from the anything that's being read by the rust uh is not I'm sorry the code is guaranteed to run correctly and you can determine which things you want to Output from the proof um anything you read from the host uh if you look at the system as a guest and a host uh is not of course a verifiable unless you verify it inside the guest this might be explained during the during the course of the presentation a little better and

and I think that if there's questions after that we can come back to it that sounds good to me any other questions at the moment okay um so right I'll start by saying sort of what happens with risk zero what is the what is risk versus zero zkvm at all and a bit about how it's architected so what is the reciproc KVM well as Brian mentioned a little it's a virtual machine um uh it's a verifiable zero knowledge virtual machine so by virtue of being a virtual machine um it runs code uh any if you have code that would execute on a physical risk five Circuit of the same architect same

specific versus lab architecture it's our virtual machine running it on the risk zero virtual machine is going to work in the same way um we have some extensions added to it to interact with the host to commit data to the receipt and I'll be talking about that stuff later um but fundamentally it acts just like an actual physical circuit would it runs that code um it's verifiable and zero knowledge which means it's not just that it runs the code it's not a bare virtual machine when you run the code it come it produces it comes with a receipt saying hey this code that I just ran I ran it and there's cryptographic data

that proves that I ran that exact code and it's zero knowledge in the sense that anything that isn't the code and that it doesn't explicitly publish is private data and there's and handing someone the receipt proving the execution tells them nothing about that private data that's that's what zero knowledge means in this context um so it's verifiable zero knowledge virtual machine that's what we have that's what we're working with um Russ compiles to it so you can prove to people that you have even if they don't trust you can prove no this rest code I really have run it and this really was the output I got from running it and they can know that it was not

manipulated by you in some way so what does the architecture look like well in some sense you have a standard virtual machine architecture where there's a host and a guest and the host emulates the guest the guest executes whatever it's being asked to execute because we're in the zero knowledge context the host can send the guest private data actually in general there's private communication allowed but in the straightforward examples the host sends the guests to private data um and that data does not show up in the receipt nothing is proven about it but what is proven is which code was executed on the data and the results of executing that code and I can see

something called a receipt the receipt comes back to the host so that's the proof that the computation was done the way it was intended to and the host is then able to send that receipt off to verifiers it can forward the receipt to Skeptics whoever whoever those things oh this person should know what I computed and I want to convince them I compute it Faithfully and so that goes off to the verifier what we'll talk about now so in the verifier end really we're sort of thinking about what's the architecture of the receipt on the verifier end all the verifier is going to do is look inspect the receipt and be like is I see the outputs and this is a

good proof it really was this code really was executed correctly so the receipt has two components the journal and the seal the journal is what contains the outputs of the program and these are public outputs if you write it to the journal anyone can see it so this is the part sort of the results that you are proving the seal side is the cryptographic information you need to uh then verify your needs to know that the proof was Faithfully executed it contains a bunch of cryptographic data it also includes a hash of the program um saying that this is the program that was proven the the prover didn't sneak in some other second program say hey I'm

proving the execution of this and actually they're proving some other program that's not possible because the seal contains this hash of the journal um but the action scare quotes because technically it's like a collection of hashes but essentially it's a hash we can think of it as Ashley will very much have the right idea and that's that's what happens our architecture so I promised that we would spend time looking at code um and so how how do we do everything we just did what's going to happen um here's code so in this example we're going to be looking at proving the factorization of a number so imagine you're someone and

you want you you have a number that you know is composite and you know how to factor it and you want other people to believe you that this is a composite number but you don't want other people to know how to factor this number um so this example will let you prove that to them um I'll mention at the bottom there's Source if you want to click the Fuller Source but I'm going to explain all the core components to this so here we're looking at at the moment the guest side cut we're looking at the code over here this is what's going to be proven and in this guess side code what are we doing well we are going to I guess down here is the core thing happening it's multiplying so the algorithm we're going to be using is

we're going to multiply two numbers and write their product to the receipt and so if we think about what we're trying to accomplish proving how to factor a number one way you can prove that is to say hey I computed this number that I want to show as composite the way I computed It Is by a product of two numbers and if it's a product of two numbers it has to be a composite number um so that's what we're going to do here we're going to prove this the product of two numbers and since we don't want to sh to share those numbers with anyone verifying this we're going to read them as private data from the host so we don't hard code the numbers into the code because the code is in the receipt instead we use this and read

um and read functionality from the reserves the KVM guest crate that lets us privately load the number from the host we do that for both numbers we're going to check that neither of them is one because if one of them you know you could say oh yes 47 is prime it's one time is is composite it's one times 47 like no that's not composite uh you need non-trivial factors for it to count as composite so we confirm that neither of them is one so we're not doing anything turkey here and then we compute the product of them um so we use this checked mole which is a rust function that um returns an error

when you overflow or that sort of error condition overflows what applies in this case um and so we we compute that we make sure there's no overflow that gives us the product and we and commit means writing the product to the receipt so by the end of this process what we have is a receipt that contains only the composite number and we have this source code that we can prove ran but this contains nothing about what the factors were zero knowledge part um and we know that we had to successfully run to get this product because if we tried to do something tricky this set thing's equal to one you know we used

one as one of the factors or if we overflowed in our multiplication it would have panicked and we can't have gotten to the commit let's look at what that looks like on the host side right that's the thing we are proving that shows how it gets proven so how are we going to do this on the host side well we privately picked two numbers the host no has the private data um and this doesn't show up in the proof so we can because it's the host side so we can privately pick our two numbers we're going to multiply them using the code we just saw so to do that we load the code we just saw and initialize approver based off of it that's what this code here does the risk 0 has a build script that builds code to a specific path and makes

constants saying where that is so here we're loading the code from where we built it then we're setting up approver this multiply ID is what we call the method ID it's the hash the thing I put in square coats earlier it's is the hash of the code that's going to go in the receipt we set up approver based around this code both the source and the hash we send it the two private numbers these add input functions send the two private factors and there's both this adding the input data and also this to VEC is serialization procedure so because we have a you know risk five architecture is fairly minimal

um and 32-bit based we sended data just as 32-bit words so we have to serialize our data into appropriate 32-bit words so that's what we have this helper function to serialize from a nicer type into um into the words that we need to be able to read it on the circuit and then we add that input we do that for both numbers and then here's where we ran that guess code we just saw we do that multiplication we get a composite number out we get a receipt that contains is the journal its composite number and a seal saying this was the result and this over here was the source code we used to get it

um when you're proving you don't actually have to verify the receipt you know you constructed it Faithfully um but we're doing it just to show that it verifies correctly and to demonstrate that look here's how you verify so here's how you verify you specify the hash that you're expecting from the source code and you just say hey verify this receipt and if the receipt is invalid if someone's trying to lie to you and making a fake receipt this will return an error instead of executing correctly um then so now we're imagining we're putting on our verifier hat in this part of the code you know in practice you'd probably be transmitting this in some way in like production examples but for

your basic use case where you're just doing development trying to figure out if your code Works we're just going to do the verifier and the same code as the host and print it to the screen so here we're going to read the journal right the journal contains that composite number we've computed so we read the journal we de-serialize from our u32 words um into the type we specified so if we're multiplying you 64s if you go look back over here we're multiplying u64s in there as well so we're expecting a u64.

um and then we can print it we can print hey I've read from the receipt that these are the factors and therefore we have a proof that these factors are known sorry I have in the receipt that this is a composite number whose factors I know and this is the receipt to prove it and so that's how proving works and I'm going to show you how this code works as well oops I have my previous example up per oh and I have never run this code so it's going to take a moment to compile um so while it's doing that oops questions at this stage if someone could read that to me that would be

wonderful perfect yes so there's four questions um one's going back about eight minutes so one is is the hash of the program the hash of source code or the hash of the risk five byte code it is the hash of the biker specifically the elf file um we use Jeremy do you want yeah no that's uh it it has a it's not a like a shot 256 of the L file it's kind of an unusual complicated hash for specific reasons for use in the zkp but yes it's basically the L file which means that if you want to verify it relative to source code you need a way to reproducibly build your source code to the elf so that you can um you know verify that

cool another question is is the best way to abort a computation if some assertion isn't valid to panic yeah um excuse me I'm going to talk about this a little more later but also yes because um well for one thing it's lightweight and the circuit is a small system but also because anytime you're running the guest there has to be a host as well and you can do your nice hit error handling over on the host side let's see where's my other side code oh yeah this is my host I code um so so right so in this line right here prover run unwrap so here this unwrap means there isn't nice error handling but if I had changed this to some sort

of expect then um when I had panicked you know let's say we ran into this case and I panicked when I panicked my error handling over here that ex this this would return an error value because it panicked and then my nice error handling over here could do whatever and not wanted and could present to the host a well-formatted error of whatever story and of course the VM panicking doesn't panic the uh host yes yes good point foreign another question is uh could you compile a rust compiler to risk five and run it on risk zero to prove some byte code

corresponds to a given source code so in theory the answer is yes uh in practice we need to add another feature for long running code uh because the running the risk the rust compiler is quite a huge program So currently it doesn't uh fit in the sort of small environment that our prover runs in however we do intend to uh we are currently working actively on support for what we call continuations where you can generate a very large proof by generating a bunch of smaller proofs and using recursion to roll up the results and actually at some point I think that one of the things we would like to be able to do is in fact offer a service of verifiable

compilation of code so so in theory absolutely in practice right now if you try it you will run out of Cycles and the last question on this batch uh rejoined a bit late can you quickly summarize the difference between the journal and receipt to get up to speed right so the journal is a portion of the receipt so the receipt has two components the Journal of the seal the journal is where you write the public outputs and the seal is the cryptographic information saying what code was run and proving that the receipt is valid cool okay thank you everyone great questions um right so that's a bit of how it works how you write code for it why why would

you use the risk zero zkbm they're actually sort of two parts to that question um part of it is why I use a zkvm at all and I'm going to start there so um in general not even thinking about dkvms at the moment just thinking about algorithms computer science problems it can sometimes be easier to check someone's work than it can be to redo their work and depending on the problem some problems are just sort of naturally like this so if we think of a graph Theory problem if we think of coloring a graph if I asked you to look at this graph on the on the left here and ask you hey is it possible to pick three colors color the nodes with those colors such that no

two adjacent nodes have the same color and I just showed you the graph on the left you could probably figure it out but take a bit of work if I showed you the graph on the right you still do need to check something you need to like look at the nodes and see if some of them are adjacent but it's easier it's easier to check work for this problem it's easier to check work than it is to redo work but that's not true for all problems like imagine a hash function depending on exactly what I mean by check your work it's either well oh this is the hash of you know ABC well that's checking the work just is redoing the work or if you mean oh this is the hash tell me what it's the hash of good luck with that right the whole

point of cash function is they're cryptographically secure against doing such things um so only some problems are like this um but with a provable zkvm Suddenly It's possible to check any algorithm just a general algorithm in constant time um with a provable zkvm all you need to do is look at the receipt and all you need to do for that is um well see that the seal is valid and see that the outputs are what you want the outputs to be um and that's not related to the code I guess I suddenly realize there's a slight Nuance you can verify that we're

seeing constant time but verifying that it matches the source code that the ash says it is you need to read the entire source code in reading code takes time um but beyond that uh verifying in constant time um right so what does that look like you have this hash function example well if you have a receipt if you ran a guest code that's just Shaw 256 this input if you ran that guess code what do you have at the end you have a receipt the receipt says this is the hash and the seal says I ran the sha-256 algorithm on private input and this is a zero knowledge proof that this hash is

the result I got so you know that this thing over in the receipt you don't know what it's a hash of but you do know it was computed by someone actually running shot 256 this isn't someone just keyboard mash the valid hash the valid hex characters this is this is actually a shot 256 output um and yeah yes I sort of led to this point already if uh private information is affecting the result if you're just sort of naively checking in that early graph Theory um example there's no way to check or redo uh the problem with private information because the result will be

different depending on the private information so if you don't have it you can't see if the result is right but the zero knowledge part of a ZK via means that back here the um this input it's still private but this output it's still proven you are still convinced you can check the work without revealing the private data um so and sort of a general principles this is the sort of reason you want to use a zkvm well why would you want to use the risk zero zkvm as Brian mentioned in the beginning you have a bunch of options here um yrs uh so risk zero I think it's really valuable that your

zero knowledge proofs be another resp crit you use not some new language you need to learn I think it's really convenient to just write rest code in the way any rest tutorial on the internet probably want to read the rest book but any rest tutorial on the internet can tell you how to write your s code great to get all the rest tooling great to use other crates today we're going to be seeing using the Json crate and uh chess crate whose name I'm blanking on because it's complicated but we're going to be using rest crates um and that's that's great to not have to reinvent code that other people have already worked on and sure you can have a great open source Community for

um your zero knowledge proving you see you're the heavy game and we certainly hope to have one and I know other people have great ones but I don't think anyone has the open source Community the size of rust and I don't think that's a very practical thing to expect I don't think you need it because we can just use rest um also we uh are using a risk 5 architecture it's an open architecture it's well supported well studied you can compile to it from a variety of places rust for example compiles to our risk five architecture we have compliance tests that we pass because it's an open architecture and it comes with compliance tests and also the risk risk five is nice because it's a good

extensible architecture and so we have some custom accelerators things like um doing finite field arithmetic fast because under the hood the ZK VM is based on finite field arithmetic and like no one pro no one said in instructions at architecture for the risk five circuit to be able to do fine I feel the arithmetic is a sort of primitive Behavior but for us it's easy so we can add an extension Forum we also have an extension for Shaw that we're going to be seeing today um so those are some reasons that I think there is zero to KVM is a great one to choose um and speaking of why you would choose it what could you do with this dkv I mean I said here's what you can do with

ckvm here's what you here's why you would choose ours there are a few answers there's well what have people done already for example um links are and you commend I'm sorry if I'm mispronouncing those um have a project proving the sum of near balances own Bolton Bailey has a metamath verifier for it has a project working on a man at verifier um to prove that a mathematical theorem is true without revealing what that proof is um Stark oracles has a Winterfell very verification run inside risk zero um so you can sort of recurse these zero knowledge systems if you want to where

curse is not quite the right word but you can stack the zero knowledge systems if you want to in this way but also there are all sorts of amazing future possibilities and some of these are limited on um performance Max Cycles as Jeremy was alluding to in an earlier question but there's some amazing ideas you can prove zkml you can prove machine learning output oh this machine Learning System I can prove that it thinks a picture with this hash is a or you could go through Bitcoin history and be like I can prove that there's a transaction for involving a thousand Bitcoins of this account somewhere somewhere out there out there we could have

um provable GCC this is uh sort of I think related to the question that came in earlier you can have if you're thinking about oh hmm is this binary this binary being given was it compiled from this source code you could have a provable GCC compilation you can sort of look at your source code supply chain and have some sort of certainty around that with with the provable compiler um you could also do a zero knowledge database thing maybe you have some database setup and you want to prove that you've transitioned from one that had one database to another into that transition um provably came from some particular

query you could have zero knowledge databases and again many of these aren't we'll run into cycle limits if you try and do them right now certainly GCC for example would hit many many times over the cycle limit um but we're working on that right so I think they're all sorts of exciting design possibilities many of which I haven't even dreamed of yet um okay actually this is probably a good point to ask if there are more questions so there was a question about the app like sort of what are the restrictions on the rust code and we're going to be covering that um in uh a little bit more detail later but uh currently you can use uh STD um uh although it's experimental it's a

bit experimental and it doesn't do all that like obviously if you try to open a file it will just Panic there's no files in the VM currently we do intend to provide more extensor support for that including potentially even um you know access to the host's file system through some mechanism and so on but that but right now it's a pretty Bare Bones uh but but we do support it specifically because a lot of other crates will import STD and fail if you don't so it's helpful to allow a wider range of available options although generally I still write no standard when I can get away with it it just saves a little on program size uh the the program the the the the the overall machine you're running on is fairly

small um Tim do you remember the specific number for the size of ram I think it's like 64 Megs or something like that a little complicated because we have different memory regions Frank gave me an answer like five different memory regions but effectively it's not you know you're not running on a modern you know super high performance machine you're running on a small you think of it like sort of embedded programming right if I was going to do some work on a Raspberry Pi or maybe even a little smaller than a Raspberry Pi more like uh but bigger than a microcontroller probably so you know it's a small machine you do have to be careful with your your speed um the other question was also sort of what's the sort of cost to how fast these things run um so I can basically on the 1-0 branch

which is still under RC on my MacBook I get about 50 000 cycles per second or uh instructions per second of risk five instructions on my MacBook um so there you know it's not extraordinarily fast uh but um you know usable for many types of applications uh one thing Jeremy when you're answering the questions just remember to read them out because for the video after we won't have any copy of them that is a good if you want to go for it go for it sure sure the question for that was what was the average amateurized overhead of running a program in the risk of the uh in the VM environment as opposed to direct execution um so uh

the the next question is uh maybe I missed it but what is the underlying execution layer on which risk zero is based uh so it's basically the risk five um instructions at architecture uh so basically the we emulate a uh a risk five computer um so risk five is a open standard uh Isa similar to like uh it's a little it's a it's a it's a risk uh architecture sort of like arm uh it's actually even simpler than arm um so specifically the rv32 I am uh instruction set one uh plus my custom extensions cool was that it for questions

oh yeah so there's another one more question popped up which is can you describe some challenges with Sisk um uh and so to answer that yeah fundamentally we have to make a arithmetic circuit that implements the entire full Isis support in order to allow us to use normal existing compiler tool chains like the existing uh rust tool chain to compile down to risk five um you know if we were to try to do that with x86 for example uh the instruction decoder alone would make the circuit massively larger um in fact we very carefully looked at all of the sort of execution environments we could use even webassembly as a significant amount of complexity over risk five risk five is a

very very small uh design in terms of the instruction set which is very helpful um I can feel the next one the question was I think the later question was about a layer two and I'll say like right now there we don't have sort of formal support for any particular chain you know we have there's been examples on near and and uh cosmom because you can very rapidly prior on those uh chains but we will be announcing a system um sometime in the near future that will uh let you uh execute these on any chain sorry yeah exciting stuff um

okay so with no more questions I want everyone here to have the opportunity to start um working with the code themselves on this next example is I'm still going to be showing you what the code is um but it's going to be an example you can follow along on your own system uh with the code I'm running so we have the zkvm rust template um we have a public template that you can it's a it's a GitHub style template and you can use it to start your own projects um so I'm going to go to this link shortly but let me tell you what's about uh what's gonna happen there so it's just a GitHub link you can clone the code normally if you want

um but you can also use the GitHub template feature which is going to give you a clean history um and it's not going to point you to the template repository as a remote so this is useful for standing up your own projects you don't like try and submit PRS to the template code which we are definitely not going to accept uh if it's your own project rather than fixes to the template so let's go through that um what's happening to make that happen so here we go I'll just show you how this works you can use the use this template uh this is probably not large enough for you to see one moment let me make this bigger uh hopefully that's more actually probably even bigger hopefully that's enough room for the UI

um let me make this full screen as well uh so I'm gonna click the use this template button create a new repository again if you don't actually want to create a repository on GitHub you can instead follow along by cloning in sort of the traditional manner um and I'm perfectly happy sending this to my own personal uh GitHub account but you could put this in a group account if you wanted um ZK hack demo actually three demo because I might be back here again um that would be cool um I'm gonna make this public because I'm telling everyone about it and create repository from template think about it

making a new GitHub repository for a project should only take a few seconds according to GitHub and indeed it did and now this is Standalone repository history is just one initial commit and we can um clone it in the usual way uh whoops I don't I'll be in this directory right now you can clone it in the usual uh right cloning in the usual way means type git clone there we go we can clone in the usual way you might want to size of that oh I definitely want to make this bigger thank you Brian and then just real quick for the two questions that people asked um one there's one question uh about

um Jeremy X you can take both of these yeah certainly the question was uh um could you added more detail about uh to this distinction you've made in circom nor Etc you're compiling a circuit for a given program uh but for risk 0 VM you generate a circuit for the VM it sounds like the circuit doesn't vary per program is that accurate and the answer is yes it's accurate um the circuit is um just implements the risk 5 VM and then we basically pass the program as input to that circuit uh so the circuit is you never recompile in circuits um

and then um yeah with regard to the road map um actually Redford do you want to take the road yeah so yeah I'll take this other so one elaboration on the prior distinction we do support accelerator circuits and we're not really getting into that that's going to be a uh even later workshop on how to build those because that part's not open source yet but in that case the circuit or like SKU you're running on might differ based on which accelerators are attached to your risk 5 circuit um as far as languages other than C plus plus and rest absolutely uh go is is very much on our roadmap although we would certainly love Community Support on that um where you can find our roadmap right

now is nowhere however we are doing off-site next week and one of our key sort of outputs from that is going to be a fairly detailed roadmap including um you know what kind of things we're hoping to work on what kind of things to help on all this stuff so we're going to really start trying to engage the open source Community um in the very new feature in a much more transparent way awesome so just just to answer a couple more questions that have popped up um one question is uh how many constraints in this monolithic circuit it is a single circuit or a collection of smaller circuits with recursion in the back end so the answer is it is currently a single circuit um we do have recursion support and

we're going to be using that for doing the continuations mechanism I mentioned earlier that allows us to run much larger programs but right now it's a single circuit um it is a stark based system um we are using about 200 some columns and there are order 15 000 constraints roughly um the uh and uh so hopefully that that helps um and the constraints uh the next question one of the other questions was is uh how are the constraints defined in Risk zero and in the our circuit is being a stark it's roughly uh air although we have a internal compiler

that actually generates that error from a higher level language currently that compiler is not open sourced but we intend to also open source that circuit compiler as well great um right so if no more questions I'm going to get into letting writing code that you can follow along with so you can see how to program a code from from our template by following along with me I also I think at the end of me going through this we'll take a bit of a break and that will get opportunity for people

if they've been following along but didn't catch what I was typing and hit a bug or something like that we'll have a chance to fix that or take questions or anything like that so the plan is sort of at the end of this we're going to do our break so um as I had mentioned I'm just going to re-show this before uh since it was from before the questions I um went to oh I guess this went away um I went to the risk zero rest starter repository here is the link um is this pasted in chat because if not I should definitely paste it in chat I'm gonna paste that in the chat

okay um so went to the risk zero starter repository you could clone this in the traditional sense if you don't want to put up a new repository on GitHub but it's easiest for creating new projects to do this create a new repository therefore that way you don't have the um history associated with it um so I did that and then I in in that repository I in the standard way cloned it cloned it with this coming and I'm gonna hide these I cloned that with this command Okay so with those sort of Basics out of the way um I will say we can I'm going to enter

the directory I cloned this into which I cloned into ZK hack3 demo um and now just before I get started I'm going to run cargo run this it's a blank temp cargo run with a hyphen R parameter because you want to compile for release because while it does make the compilation a little longer it makes the execution substantially faster and that can add up um and it's going to take a bit to do first time compilation and then once it actually runs it's going to do nothing the template is a blank template for you to be able to fill out so this code

doesn't actually do anything yet um so while that's compiling I'm going to start talking about how you use this template how you fill it out so there's a readme section explaining this and we're not going to go through all of it because I'm just going to tell you but a key point is there are to Do's scattered throughout the project you can search for to do and it tells you where you need to make changes to turn this into an actual project um and then the rest of the remain sort of says some places you should expect to Do's tells you things like hey be sure to check the get ignore file and make sure it matches what you want to be Etc rewrite this readme that's what um so let's go look at sort of the core functionality so when I showed you the

factors example earlier there was guest code that was the first thing I showed you and that lives in methods guest Source bin in sort of your standard layout in the way the the templates laid out and here's that guest file so this is one of the files we'll be editing and the other file we're editing is going to be the host code I'm going to close these messages it's going to be the host side code which is in host source mean for the template let me say the two we're going to be doing oops sorry I'm trying to move come on there we go I'm trying to move the you're sharing your entire screen message which was in my way um right so let's look at the guest code

first that's what we started with with factors that's what we you're going to start with here oh and I didn't say what project we're gonna do that was an oversight um so what are we trying to accomplish um let's write a password Checker um let's say you know passwords you often have the your password must contain one uppercase letter one lowercase letter one symbol uh this is not I believe nist actually recommends against this but it's a very common thing so let's try doing it and let's try writing a password Checker so that we never actually have to share our password with anyone we can instead share a receipt and that receipts us here's the hash of my password that's all you need is my hash and

because I ran this in the zkvm I have a proof that it meets your password condition I'm going to have a proof that it includes a special character if that's the condition we're going to check for um and so that's our goal um right okay now I can come back to the code and say let's actually implement this code okay so the very first line in the guest code and the template says Hey rename this file the file name should be what you're trying to accomplish um so we're going to rename it rename it from method name and I'm going to go ahead and rename this to um we're checking the password so password Checker so I'm going to rename this too

um oh and I deleted the message a little quickly but it said you also need to change a constant in the source so I'm about in the host side so I'm about to go to the host side over here in the host side it said I need to change a constant and the host side has it to do right at the top telling you the same thing change change these constants to what you just named your method so instead of method Name ID I've now named it and it's now PW check ID PW check W Checker I'm going to rename this PW check you know but you check ID PW check ID and PW check path and rest naming conventions say these should be all caps

so even though I wrote um this file name in lowercase our build script is going to convert that to uppercase and creating these um constants so I use all caps here um I'm going to copy these since I made these changes I need to change them elsewhere in the file as well the ID shows up in two places so I change that here and here you can also use command F to find all the places you need to change this here and here okay first Do's are done just follow the instructions um then oh I want to point out before I keep going this is now finished routing

and as promised it did nothing if you are following Along on your own example um and you hit a problem here um you can let us know I'm a little surprised but you can let us know and I can take a break at some point to help with that we can talk about it uh sort of during the break let me come back to the guest code so I came back to the gas code that's pwcheck.rs um it mentions the standard support is experimental um it generally does work um but it is a little experimental and actually when in the chess example there's a slight bug in 0.11 that we're going to run into it will be fine we have a workaround but I actually want to

use string so I'm going to remove the no standard um and okay let's think about what we want to do we want to receive a password privately confirm that it contains a standard character or a I'm sorry a special character and return the hash by writing it into committing it into the receipt so first we need to load the password so that password is going to be a string um and you do need to explicitly specify the type because there's no type inference across the host guest boundary um and EV um uh and read gets you gets you the first if there's more than

one input you can see the first input being provided by the host we do need this n and that is in the risk zero ckvm guest correct so we add that as well um we are implementing Our Guest code already okay now we need to check that this contains a special character so if um so okay what we're going to do I'm going to Loop over all the characters in The String check whether or not it is a special character um and if it is gay and gray snap Flags saying Yep this is fine and if not I won't and in the end regressing of that flag is said or not so let's set up a

flag so let is okay equal false and then for character and PW cars um we're going to check oh this needs to be mutable let mute is okay equals false um we're gonna check um if the character is I think it is ASCII special I ran through this code earlier I think it's it's asking special compiler will complain if I'm wrong about that um then is okay equals true

and then once we've checked every character we're gonna see um if uh it's not okay well we don't want to generate a receipt so to prove that um there is a special character we want to panic if there isn't a special character whoops we panic um and then I said we wanted to put the hash in the uh in the receipt so we use infomit for that but first we need to compute the hash and for Shaw we have a built-in accelerator you could in principle compute Shaw naively but the performance would be bad so we have a

built-in accelerator for that so that's the Sha functionality um and so to compute the receipt we say let digest equal Shaw digest u8 Heights I think something like that it will complain if I'm wrong digest u8 bytes of um the password and Shaw needs it in u8 so we get it as bytes the rest function to turn your string into the bytes that encode it um and then we want to put that in the receipt and N commit is how you put

something in the receipt okay and I would sort of like to test this but if we try and well we're going to get an error definitely because we haven't passed anything to the guest we're not looking at the receipt but we are running the guest code so um okay to just run that see if we get an informative error if we did uh um oh yep informative error said I didn't use the word use up here thank you rest let's try that again this is why we test early even if ASCII special I thought I knew that name

is speed maybe if that's not it we're going to look this up online okay um we're gonna go look this up so uh oh nope let me use whatever Firefox is um rest characters is asking punctuation okay yes ASCII punctuation make you rest this is a real developer experience this

is how it looks to write code live okay let me make this terminal a little bit bigger so I can read the error better uh let's digest you eight slice not digest you eight bites sure okay so that is optimistic that we're going to run into problems now with the host not actually providing the data the guest needs to run correctly given how long it's taking to compile um okay so let's go back over to the host side yeah okay so this compiled successfully and then it panicked

um unexpected end to the deserialization it tried to deserialize um an input that was not provided so let's go over to the host side and see how to provide input um so on the prover we're just going to say prover dot add you can put input of and well uh we want to provide some passwords so okay you need to provide a password first sorry let's set that up let password uh be string from password

and make sure to include a special character excellent password choice right there um so we're gonna add an input of this password and I'll make I mentioned this a while ago once you also need to serialize into um u32 uh words and we have a helper function for that that's in fact included in the comment up here it's this two back so add input to vac uh the password unwrap unwrap I think some of these might need to be borrows but that's okay we'll work that out uh in compilation um and we're in to do Implement

communication with the guest here that's what we just did we sent over the information um whoops cancel save and now we can run yeah right this is what's needed this is what's needed as I said I thought there were some virus missing all right and we got a warning about from slice but this ran and it ran successfully we have in fact at this

point since we provided the private input and we've written this code we have proven that um we provided a password that did include a special punctuation and in fact if I take this exclamation mark out we will see that since there is down here on line 22 there's a verify step we'll see that we get a problem it panicked at an explicit panic and we get an error message about well the code should prove unless you had an error or you overflowed the cycle count um so that's good right we really do have a proof um and now the sort of last Finishing Touch is to see what the hash is to sort of

work out what the verification side looks like so here we have the receipt we verified the receipt but we haven't actually looked in the journal yet and so we're going to use the um from slice deserialization to read into the journal let me say left the shaw digest which is a fat digest type equal from slice of receipt.get the journal VEC I think both of these need an unwrap I'm going to print the line that we proved this hash

can you have came from a password with special characters digest and um this digest is the shaw digest type that works with um our custom Shaw accelerator so we need to include that use risk zero zkp zero knowledge prover is where the algorithm lives I think it's of course uh digest and because we need to use sha and we need to use the ZK Peak rate that's not included by default in the demo so I add it to the cargo file cargo file just in the host directory

over here and it's the same version as the zkvm and this will hopefully run let's see what um bugs it says I have oh okay right um hyphen not underscore um there's a problem in from slayo I need to borrow stuff but oh um I think I left my password without a special character in it so that's why it didn't work I was trying to prove something false it doesn't like that I didn't click save

it again and there you go if you've been following along which admittedly I was going a little fast for following along but maybe I hopefully you did um hopefully you could if not I'll help you catch up we have proven a password with this hash uh has special characters this is the password but the receipt doesn't tell you that you only know that because you're looking at the host source code um is this an opportunity I'm going to take questions um we can about the code or about things in general you can also stretch your legs take a bit of a break yeah questions so I'm just going to answer some of the

questions that came up one of them was about how easy would be to add metering gas metering to the VM and how would we imagine that working the answer is that some of that will be sort of worked out when we get to sort of putting this onto more blockchain use cases but generally the nice thing is is that one instruction cycle is a very straightforward way to meter the most of the time spent is in actually doing the proving and the proving is more or less linear with the number of instruction Cycles so in this case the gas would literally be just number of risk V instructions run more or less um and then the other question that was uh the journal could for example also store multiple digests and the answer is

yes the journal is just effectively it's a free-form serialization buffer and you can serialize whatever you want to the journal um so you could put up multiple digests you could put out um you know you could you could in fact put the entire string and I think in our chess example we're going to put like the chess board into the uh Journal um so so so you know and we're gonna I'm sorry just interrupt because I know example we're going to have an upcoming example where I show a design pattern for having structured output if you just write multiple things to the journal you have to know how many bytes they each take and read out the appropriate bytes in each thing if there's more than one um but you can create an object that you

know each entry in the object is an output you expect and that's an easier design pattern to code uh safely with and there's going to be an example of that on the Json example sorry to interrupt Jeremy no it's good I think I think that's everything okay great um do people have questions about the code or are we just on break at this point Anna did you say you wanted to make some sort of networking yes so this is actually a question to you and to the audience I mean it sort of seems like you're on a roll so I don't know should we pull out like people away or should

we stay here we can do a networking at the end Maybe would that be better for folks I don't know if I know people really like it because like you can also get to meet people and they get to talk directly to you and stuff but um yeah why don't we do that if you're if you're okay with it I think it's great and then uh we'll do the launch of puzzle three and then we can do a little networking at the end I think you do have some more questions well one is can you add your tumult file t-o-m-l I know this can you add to your tummel file what what did you add to your

tomophyle and will this code be posted after the session um I certainly can post this code after the session there is absolutely um I will publish this to that GitHub repo you saw me clone um and in addition to that um there is separately this will be helpful for a separate reason we have a nice password Checker example that's not just coded off the top of my head and does things like salts the password which is probably something you should do if you're actually working with the password um so there's a more full-fledged example there but I know if you've been following along you probably want to see the actual exact example I did and I will be posting that um after the

session is complete foreign great I'm gonna dive back into it then so um now that we've ran some code what are some design principles you want to take into account when we're writing this code for a zkvm um so first of all I want to mention that zero knowledge means zero X for knowledge if you actually just don't commit anything to the journal for example and just hand someone the receipt don't tell them anything just hand them the receipt all they're going to know is I am holding a cryptographic proof that

some code I mean they know the hash but that's not very helpful they know that some code was run that's sort of it um that's not super useful so what you actually do with your handsome University is you put something in the journal like for example the hash of the password and you tell them what code was used um and that they can check against the hash so it's so zero knowledge in practice means zero extra knowledge everything you deliberately publish is secured and everything you don't deliberately published there's no information about um and so when you're thinking about how to design

um these zero knowledge programs that you're going to be running in our ckvm you want to think about what you want to secure and keep private and what you want to securely and provably publish if you're doing it in the guest it's going to be secure either way but you want to know is it securely public everyone can look at it but there's a proof that it is what it is or do you want it to just be private and no information is shared about it so things like secret information your password for example the previous example secret information or other sort of internal data you probably want to use the zero knowledge functionality and keep that private between the host and the guest um and conversely things like hashes so

that you know you wouldn't know if I hadn't at the very end included the hash of the password well for one thing the person I'm handing this to isn't going to know how to check my password in the future but like they don't know if I'm switching things up if you don't include a hash you can just say oh yeah I totally have a password that includes a special character and just pass a special character string in and then use something else as your password and there's nothing to verify because you don't have the hash of that so you often are including hashes of important data you're proving things about even if the data itself is private the code is going to be securely published because you have that method ID that hash that can can be checked against the code um and just public data in general you

tend to want to securely publish so that's a design consideration um I also want to think about keeping the guest code relatively simple because the risk Drive architecture we're using is small it's lightweight as Jeremy mentioned earlier you want to be treating it a bit like an embed system so like don't put your UI in the guest you want to separate the component that's producing data from the component that's rendering the data to your users and that's you know often a good design pattern anyway but you really want in the guest you want what can be proven and in the chess example there's um a string at the end representing the position of the test board and that

string uses something called fan it's a chess term fan which is a way of writing the state of a chess game um and that I mean maybe if you're good at chess that's easy to read I don't know I do not find it easy to read um and so the chess library I'm using also has a rendering software that turns that into like a pretty ASCII art of the chessboard that's uh more readable at least to me um so you so the fan since you produced it in the guest um is going to be that's enough information like what you produce in the guest that's the only stuff that will be secured so you do need to secure whatever data it actually needs to be proven that does need to go in the guest

so producing the relevant data that's in the guess but rendering it well as long as anyone can see that the rendering is a faithful rendition like if you really want to check you can go look at that fan and inspect it and be like okay this string really does match this pretty render check chess board as long as you can do that you really should be putting that UI in the host side um also this came up earlier it's fine to panic in the guest panicking the guest does not panic the host all your nice error handling for that Panic goes in the host so you can simplify the guest code down and just terminate abruptly if you're in a situation where you want to if if you're trying to prove something you don't want to be able to

prove if you're in the oh I'm trying to factor this number using a one scenario or o this password that I want to prove has special characters it had no special characters just panic um do your error handling over in the host side and in general be thinking about this sort of like an embedded system right there's limited memory um the rv32im architecture we use does not have native float instructions that doesn't mean you can't use floats but it's not native float support so they're pretty slow um those sort of considerations and let's dive right back into the code so here I'm gonna post this link into the chats that people can once again

follow along and here I'm actually going to let people where where's the chat it's on this window over here I'm going to post this into the chat so people can follow along because here um here we're gonna have an exercise at this point you've gone through doing doing code with me I'm going to walk you a little bit through the Json example um and so if you go into that examples repository I linked which is here let's see our best examples and if you go into you clone this right in in your uh in your standard way of cloning clone this and if you go into the Json directory so

this has a bunch of examples and we're going to be going through the Json example so navigate in your ID or terminal wherever you want to navigating to the Json directory and we are going to be modifying this code I'm going to be walking you through how this code works and then I'm going to have a problem that you can do on your own to modify this code um and so let me go back to the presentation right navigating to that directory the Json directory and confirm that your example Works once you're in that directory cargo run Dash r um and as everyone gets set up with this um I'm gonna go look at the code and explain what it's doing so that you're going to be able to modify it so let me close

the code I made get uh let me quickly commit what I did so I don't sometimes I have to delete it uh um and let me step over into the Json examples right so just as with the code we were working I walked you through with the password Checker we have both guest code and methods guests and methods oops methods guest I did not go to the right place methods guest source search Json so what this code is doing is it is going to use a Json library

with an external Json Library it's going to receive a string that's Json data it is going to Hash the string and ultimately commit that hash we'll get to that in a moment okay hash that string and commit it um it's also going to parse the string that's the Json string parse it as a Json as Json data and it's going to use this Json Library it's going to look in the field critical data it's going to interpret that field as a u32 um and it's going to put that data into the receipt right these these two things

the data and the hash are the outputs and I'm going to jointly commit those into the receipt this is the pattern I mentioned earlier about multiple outputs I'll come back to that because what's the point of this program well this is a proof that the Json file that has this hash contains a field named critical data and it proves what the value of that critical data field is without actually revealing the entire Json file so you can this gives us a way to have this sort of partial access provable partial access to a Json file we're not sharing everything about it but you can nevertheless convince someone this Json file that has this hash it really does contain this particular field with this

particular value um coming back since I sort of skipped over it a little there's this outputs structure so there's actually a third file of relevance here it's just in Json core um and there's just a structure that holds multiple outputs so it's easier to uh it's a better more ergonomic to handle them on both the host and guest side um and we use RDA serialization um Library it has uh deserialized and serialized traits that we Implement for this and that's going to let the guest or the host and guess code

um translate this u32 and this digest into the u32 words that's necessary to do the transform foreign and then over on the host side that's here in host Source main over on the host side we are opening the Json file there's a Json file in the Resources directory I guess I will point to that as well here we have just root res directory there's an example Json file here's the example Json file um and it's going to uh read this Json file into a string this is from whoops I guess not this file oh this is

just a file I'm just gonna read it into a string and that string we're going to hand over to the prover in the same way we did in the last example We Run The prover we verify that the receipt was correct um and then we read the rest we read the journal out of the receipt and then we deserialize the journal into this outputs object that we were just looking at over over in the core directory this outputs object and then um we print we print the contents of the output the outputs.hash and outputs.data came from this output directory and we print a nice string so if we uh CD uh

what is this CD or zero rest example CD Json I'm going to the director I told you to go to if if you cargo run Dash r as I had mentioned earlier um we should get a nice pretty printed output saying that hey here's the hash and it contains the field critical data oh and the value is 47. they've proven that that field is 40 . um questions on understanding this Json code before I ask you to modify it four questions in general in fact okay so let me talk about your the

problem I'm posing to you that's where I take we're a little short on time we're going to take maybe eight minutes um and I want you to modify the Json example to instead compare two Json files confirm that they share the same critical data value but don't reveal what that value is um so that's your problem and cool we can take questions or just give you a bit of time to work yeah Tim just so you know too uh you actually have 40 minutes so you have quite a bit of time um am I trying to leave a bit of time

for networking at the end of that uh not because basically at in 40 minutes what we're going to do is we're jump on on screen and puzzle T3 quite briefly talk about the next sessions and then we can Network after or we could Network a little bit before it's kind of up to you okay great so I would say like if you want to use the 40 minutes go for it but if you end a little early we'll probably use it for now we're not sure I I can totally use the 400 40 minutes so I will do that thank you so um a question popped up which was we will be covering verification of the proof by a third party um so I don't know that we're going to specifically talk about it but what's notable is that the examples at the end of the host code we call verify and so

the only difference if it was a third party which by the way some of the examples like the password checking example have separate cli's that generate a proof and verify the proof for example um is that what you would do is you would take the receipt that was generated you would serialize it send it to the third party and then the third party would deserialize that receipt and call the same um uh verify uh on the receipt that we're calling here um so so what it looks like for someone else to verify it is mostly just calling the verifier on the receipt which we sort of show in the same program in in the real world you send it somewhere else what's notable by the way is the verifier is fairly small and in the for

for example new RC release the verifier is uh we can actually compile to wasm people have been running the verifier for example on near as an example so uh yes so the other question was do proofs depend on the risk zero VM version and the answer is yes we actually are working on sort of improving our versioning story um so the the um long term there will probably be the the proofs will be specific to the version which at some point we would like to sort of have the proofs themselves have

a semantic versioning and to sort of make sure that they last for a long time uh currently it's pretty active development uh uh and then also So eventually you'll have the version of the proof system then you will have the specific risk 5 circuit you are running because um the currently we only have one risk 5 circuit which includes two two accelerators but at some point we will probably allow people to have custom accelerators so you might have like the the the the the stock risk five circuit or the risk 5 circuit with the elliptic curve accelerator which will be a different circuit um if you're using a lot of elliptic curves or the risk five circuit with you

know some custom accelerator and then there'll be the actual method you're running the specific code you're running um So So eventually a proof will depend on all of those um things and we'll hopefully provide a more specific versioning story for it next question which is a very good question is is there a solidity implementation of the verifier and the answer is currently no um and actually says also you mentioned the wasm verifier can the same down for proof generation So currently proof generation is is fairly computation expensive and generally you would not imagine running the proof generation on chain you would simply do the proof verification on chain um so uh so like I mentioned we do work

from Wows them and you can run that on change solidity verifier we do not currently have a solidity verifier yet one of the big issues is the proof size is fairly large and so in order to reduce gas costs I think that our current plan is rather than to directly verify the proof on say ethereum we would actually wrap the verification of the proof in a proof system that has like a like a a snark based proof system that has a smaller proof size and then do the verification of that on uh ethereum but we will be describing more sort of our process to roll this out so that you can verify proofs on a wide range of chains

um sort of when we get closer to the launch of the the proof Network working on um and uh the uh sorry uh it says could you uh please switch another time to the slides for the task description oh yeah could you go back to that yeah yeah thank you good question nice um and then the another question is if proof depends on the VM version does that mean the verifier needs to run the VM to verify the proofs uh so no um the verifier never runs the VM um but the verifier does the VM consists of a bunch of time steps

in each time step implements a set of these polynomial constraints and that uh that core polynomial constraint set is checked inside the verifier so there's a there's a sort of um uh so so in that in in that sense the verifier depends on the circuit but it doesn't actually execute the circuit it simply uses the constraint set that the circuit has to do some additional math I think we cover very very vaguely how the proof system works under the hood but it's actually quite a long detailed topic of com of discussion if you have a sort of a bunch of materials on our website that go into that at a more deep level as well

I'm gonna give maybe two or three more minutes to work on the exercise foreign foreign

so that I have enough time to explain what's going on um my cursor is weird there we go um so right what needs to happen so if we're going to be comparing two examp two Json files we need to send to Json files to [Music] um over to the guest so I'm just going to copy the file reading code I'm not actually going to read a different file since we're trying to prove they have the same value um which will be a little boring is the thing to be proven but you know there's there's no reason I can't do that so I'm just going to uh give new names to these

because I think I need to at least some of them I need to interact with more than once um so we're going to read a second file we're going to add that as a second input two um then okay I'm going to come back to the rest of the host code later once I finish the guest over on the guest side now we're thinking I'm just sort of thinking in the order stuff goes in where first you read the files in the host then you run the guest code then you process what the guess code did so over on this side we're going to have to read twice beta 1 data two um we're gonna have to digest the Sha twice um hash two

we don't want to Output the data at any point but we do need both both datas and then if uh data is not equal data too panic well don't you want to read the actual value you don't want to just compare that oh oh oh you were right thank you Jeremy um and I believe what was the value I was reading critical data right okay all of this

back yeah we're not proving the Json files they're equal improving the specific field is equal thank you for that correction I would have had the wrong answer I'm sure many people in this call can relate to not doing that quite right we'll have to unwrap them both otherwise they could both be empty um you are correct I had I had done this ahead of time and then failed to commit my result if you saw me looking in the git history briefly well the example was going on I was like wait where's where's the commit oh it doesn't exist

um so right I had the answer key and then I can use it hash and hash two are going to be our two outputs so we I modified the output structure um because we're sending two hashes instead of sending some of the data um right we're sending two hashes and um then all it needs to happen still is back on the host side which is over here um and we're going to at this point we actually do have the receipt that's correct but we're not going to be outputting the right pretty printed data the Json files with these hashes

share critical data that's not the best English sentence but that's okay um I'll put hash and hash two and now we'll see if cargo thinks I got it right as well or if I made mistakes oh dear okay what did I do wrong oh um so over in the guest code I'm not using the Json Library correctly expecting string found Json value oh uh no that's okay

data two actually you forgot data 2.2 equals parts of data two yep thank you by the way this is actually interesting to note that um one of the interesting things is that this makes it much easier to write zero knowledge proofs but bugs in your guest code mean that you might not be proving to think you think you think you are so much like smart contracts uh the guest code in particular is important to audit very carefully uh because uh you know certainly um if the security bugs that can exist because there are unexpected code paths in the guest code are

certainly non non-zero although luckily it's a lot easier to audit then say an arithmetic circuit um because you know you can actually read rust code fairly straightforwardly and so there you go and I will be posting this solution uh publicly as well um if people want to check against it or check your work um does anyone have any questions from having done their own code from what I just explained hearing no immediate questions I am going to move on so how does this work so this part of the talk I mentioned at the very beginning we really want to focus on the practicalities of coding

okay there's one question which was which I'm not sure I actually understand which is uh do you have any solidity exporter for the verifier contract uh uh so the answer is I mean at this point really we don't have anything that does anything with solidity um so in terms of what we are intending to do we do uh plan to make uh a mechanism for running the verifier on chains that use uh solidity or particularly on the evm um for ethereum we don't currently have that um and we also have been even considering making support for running solidity contracts on risk five there are existing solidity compilers that do

backend lvm which backends to risk five uh but you know we so we could add solidity language support similar to the way we've added rough support but we have not yet done that either so hopefully that answers the question cool so I mentioned at the beginning we're focused on the practicalities of the code and this section you don't actually need to know this to know how to write code for um the risks zeros ekvm but I think I think it's cool I think probably many of you want to understand at least a bit how it works under the hood what's going on cryptographically um fundamentally to if I'd spend the entire two hours trying to explain it that wouldn't be enough time so I'm also

going to be giving some links to educational material other resources at the end because there's a lot but I do want to give at least a bit of an overview as to what's happening so okay let's talk about when the host is emulating the guests and the guest is executing code what is happening when that happens in addition to just like running the VM what what's the stuff that's also making the proof work and making the receipt work so um right just as the VA as the VM I think I've actually talked about most of the slide already we chose risk five it's open it's lightweight it compiles from rust um it's all ready sorry for the extraneous

slide um but what's happening cryptographically while you're running over the VM because it's not just a virtual machine the prover is keeping track of the state of the VM at all times in something that's called an execution trace and the execution Trace is this giant table where each row is a clock cycle so when I say it keeps track at all times every single cycle it knows well what does it know it knows what's in the columns and every column is a register well every register is a column at least um it's actually more than that there's some additional columns that do things like handle memory but if we're just to simplify we're thinking every row is a

clock cycle every column is a register so you know the exact state of this risk five circuit at every single clock cycle for program execution um and I want to quickly say if all we cared about was proving correct execution we would be done right like we've simulated the entire computer or the entire entire circuit at this point uh we know exactly it's state at all times and we can just check yep the beginning is what it should be and match the code oh yep the end is what it should be it put the right results in the right places yep every step was a legal risk five transition we're good uh this is not a good idea though the

verified performance is terrible like you're running a simulator not some sort of uh more condensed thing and it's the exact opposite of zero knowledge you're running a simulator you know exactly what's happening at every single time step this is not achieving the other goals of of our zkvm so right I just talked about why verifying the trace would be enough like this was sufficient because we know the initial state it matches we know the results they match and there's computational Integrity every step is what an actual physical risk 5 circuit would have done at that step um and we encode this using algebra the those conditions I just mentioned and

these three bullets those become algebraic constraints um and that you know the binary zeros and one encoding we turn those into field elements and that encoded Trace is something called a witness to the algebraic constraints meaning it is something it is the the algebraic encoding of the execution Trace um satisfies every single one of the algebraic constraints and so Witnesses this right here is a solution to all the constraints it has the right initial state it has the right results it has computational Integrity all these constraints are satisfied since that's called being a witness so okay we've encoded things into

algebra so we can start doing cryptographic math on it um and is that what goes in the seal no so what's going to go in the seal actually let me remind myself what my future slide is right um so the seal needs to have the zero knowledge proof and we actually haven't we haven't solved the this is a simulation it's zero knowledge and it's the exact opposite of zero knowledge none of that has happened yet we've just encoded it as algebra what is going to go into the seal is a ZK Stark a scalable transparent argument of knowledge that's what Stark stands for um and how is this related to that execution Trace that I just mentioned um

well so the it's related in the cryptography the proof over and verifier are going to be doing we are going to prove and verify the execution phrase sasifies appropriate constraints like I sort of described Loosely could just be done by looking at the algebra but instead of proving them by having to look at the entire algebraic encoding of the algebra of the constraints we are going to use fry and deepali with a shotu implementation of this Fiat Shamir heuristics so frying deepali without fiatrimir are um an interactive Oracle proof where what happens is you spot check um the execution Trace instead of saying

hey I'm gonna check that every single constraint is met at every single place you are the verifier the person who wants to know that this is correct is going to randomly spot check um various places for the constraints to hold and if they hold in a bunch of places there's you know that was chosen randomly without the proof of having input that's good evidence that the whole thing is correct uh more specifically I think one thing that's important to note is that before that spot checking is done the thing is encoded into an RS code which is an error correcting code such that if there's even a single error then about three-fourths of the entire

thing will be in error um and so what you're doing is you're effectively amplifying the error and then spot checking and so you can very quickly spot check a small number of places and detect an error anywhere and that's sort of part of the underlying magic I don't want to go into too much detail um but yeah yeah that's good that honestly should have been in this slide so thank you for adding that Jeremy yeah so that's those reads that read Solomon code word that reads element encoding that Jeremy mentioned um that create that makes any error be like most of it's an error um we've we actually have didn't make it into my slides at all but we actually have a video about how that works uh sort of the basics of reinstallment encoding um on our YouTube channel which is

linked to the end of these slides right so you're going to be spot checking and because you have this error amplification if you do even just one spot check you probably find the error and if you do a ton of spot checks you're really you become cryptographically likely to find the error um and and then uh when you add the fioshimir heuristic to this process um that means that uses um what the x that uses everything you've already done what the execution Trace was everything you've already done um to to uh

generate to ran to generate the random points you are checking and so the prover doesn't have control over that it uses attached to use the shot too to figure out where where those random values are um I use this cryptographically secure random generation based on that shot 2 algorithm and so that makes it non-interactive you don't have to when I hand you a receipt the receipt isn't about the verifier coming back and talking to me and being like hey is this point correct is this point correct is this point correct um it's a it's it's a non-interactive process because of the Fiat heuristic um that was a very high level summary of what's going on there's a lot of um

rather thorough cryptography um so if you're curious we very much invite you to learn more um our website has a section explaining the technology we use we have an ongoing or zero Study Club series um the playlist on our YouTube channel also this is a pretty long URL uh the sides have it linked um but also we will show you I'll link the YouTube channel at the end and you can navigate to our playlist from there so that's an ongoing Series so we do have recordings of the previous zero Study Club meetings but also these are open public online meetings you are welcome to attend um and see them live as we as we put out

or study Club material um and while we have some ideas for the upcoming study clubs if there's parts of our system you want to understand better we absolutely are taking ideas for things we should cover in the study Club so feel free to make suggestions to us now one thing I would like to mention really quickly is that the fundamentally most of this sort of cryptographic process that we're doing for this zero knowledge proofs is not something that we have invented um uh this is basically ZK Stark's uh it's the same underlying cryptographic system that starkware uses that Maiden uses the main Innovation is sort of in terms of both the efficiency with which our prover and verifier do that uh cryptographic uh process as well as of

course the risk 5 circuit and the risk 5 VM of course so that you can run arbitrary rust code but you know so I do think that we are trying to help the world understand how these cryptographic systems work under the hood but but uh you know as a cryptographer whenever I hear someone's doing some kind of new uh cryptography I get a little nervous so I just wanted to clarify that uh yeah we're very much using existing materials or standing on uh soldiers of cryptographic giants here um and actually that's a very good addition and how fence to be a good transition to my third bullet which is it's not just our own educational resources right um right here as this part of the ZK hack series the

Whiteboard sessions are really informative there was there's one on zkvms that I thought was a very good session for example it was like number seven maybe I forget which one it was but there's one on on ZK VMS in general that's Apple quill to ours but applies more or less applicable to ours but applies to the CK VMS generally um and there's other good General background that's helpful for how CK things work for more than just us and we really are using yeah this this Stark so how do I go backwards yeah the Starks that's what's in our seal is as Jeremy said stuff that's developed by others well well worked out in a series of papers by

um Ellie Benson and others um and and other contributions as well um but yeah we're using technology other people are using as well for the security um and with that I want to dive back into code this is going to be another example um where I'm showing you something rather than you following along because it's the most complex example I'm going to show you a zero knowledge Checkmate I'm going to prove that um oops I clicked the link and actually I just want to go to uh the chest example in here we're going to prove that a chest position has a Checkmate without revealing what the

Checkmate is so we can do that with zero knowledge because um sorry I'm trying to talk and navigate between directories at the same time and that doesn't really work um yeah it really doesn't work CD chess cargo red okay there we go um so we're going to be proving that there's a Checkmate and without revealing what the Checkmate is and we can do that with zero knowledge proofs because what we're going to do is we're going to load privately a board State and a move with that move being a Checkmate um and we're going to commit what the initial board state was but we're not going to commit what the move was so

going back to our design principle of letting make public and private we made the board state public the initial board State not the ending State I mean the initial board state public so you can check so people say yes this is the position we are checking for checking for a check made in we're not going to make the move public because that's the thing I'm trying to keep private we don't want we don't want someone to see our Checkmate I mean it's chess you look for a while and if you know the rules of Chess you eventually figure it out especially because it's a mate in just one move to make the examples simple um but nevertheless you know here's the board there's a Checkmate for it I ran this code um as we're going to see momentarily

um and he that really does prove that there's a Checkmate here um but you know if you haven't found it yet you don't necessarily know what the mating move is um now if you do know chess you probably do this is the scholars mate it's actually pretty famous um but nevertheless uh there's a Checkmate here and we haven't shared what it is so let's go look at how this chest proofing code works so the first thing I want to point out is I didn't write the um the chess code here the we're using this shakmenti is the name of the library we're using it's one of the

common um rust chess libraries um and it um it's it's not my code so I don't have to figure out how to make chesswork so over here actually I'll show you this before explaining the code too much more detail so there's this I mentioned actually I think I mentioned much earlier in this presentation there's something called fans um if someone's two people's name notation something called fends that's used to denote the state of a chess game and this is what a Fen looks like and you can translate between it and this board in fact what I have highlighted in this board I'm showing at the bottom of the

screen they are the same chest position there's actually a little more detail up here um it tells you white is moving that's over here it also tells you who's allowed to Castle it tells you whether there's on passant happening it tells you what move of the game is going on um so so there's some additional chest details then just what's rendered here and this is what we're going to be securing and you can I mentioned in design principles you should have your UI over on the host side we have the night this nice rendering is happening way down to the bottom because it's somewhere down here um right this when we render when we just use this colon question this restitution

or the debug output when we render the board just using that debug output it pretty prints it and we're doing this over on the host side it's we don't have this entire board is not what's being committed if we go chase this code backwards a little it's the committed stable it's just a string and that string is uh ultimately if we walk through the entire code the string ultimately comes from this position of the board um so that was that's an example of how you want to do your UI separation that principle I was mentioning earlier um but okay let me back up and explain everything that's happening let's go

look at the guest side I just wanted to dive in a little on that point since I made it earlier so let's look at the guess side code what's happening on the guest side so we read a move we read the state of the board we commit the initial state of the board before we made a move and that's how the people reading um our receipt know okay when you have a Checkmate it really is starting from this position that's how they know what position is starting from and that's the only thing we're going to be writing into the receipt then um we're going to we're going to use our chess library we're going to take our initial State we're going to convert it into a fan we're going to set up create a setup function for the board which is part

about the chess library Works we're going to create the actual chest position from this setup we have to tell it that we're using the normal rules of Chess that's part of how the library works similarly the move the move is also a string it uses with test sand which is another chess thing called stands for simplified algebraic notation I believe simple algebraic notation something like that um and the library comes with the ability to parse this so we parse the move and then we say from this chest position we play the move and produce a new chest position and we assert that the position is a Checkmate and by having this assertion at the end if we don't have a Checkmate we're going

to panic here and so the fact that we don't panic means that we really do have a checkmate um and over on the host side we essentially just need to get the relevant data to the guest and then pretty print the results so we have a command line this this example comes with a command line interface oh I scrolled up and I want to show you something I mentioned early on I mentioned that standard support is a little bit experimental there's actually a bug in 0.11 to have to deal with alignment issues on strings I'm pretty sure it's fixed in the current version although I haven't updated this example to the current version I guess it could

still be broken I do think it's fixed though there's a workaround I just wanted to mention yeah it really is a bit experimental you will occasionally hit bugs come talk to us we're on Discord we're on GitHub talk to us if you had issues open issues if you had issues um okay back to my explanation so right just set up a command line interface and pretty print things um so here we have a command line interface we put together a nice inputs object so we don't have to pass multiple separate things um we add our inputs we prove the result we uh interpret what we committed as um a chessboard I actually have this assert that says that what I sent to the

guest is the same thing the guests committed which we proved in the guest that you know if we look at the guess side code the inputs is the thing we committed so this is not necessary for security this is just sort of my standard oh I wrote two things that are the same I should add an assertion because it's a good coding practice but this is not there's no security here asserts on the host side don't provide security I wanted to say that um and then we just we started from a string so again we have to render this into an entire chest position using the library let me come back and we have the board and it proves it's the Checkmate and if it wasn't a Checkmate if we pass in some um different move

which I can do from the command line it will be mad at me um yeah assertion failed it's not a Checkmate so we really did prove it's a checkmate questions just by the way I'd like to really point out that one of the big values of the using risk zero as your proof system is chess is complicated uh verifying you know the the correctness of a move and the the whole state of the board and like all of these things and we can just import a library and do that um and uh I think that that's sort of the big value is that we are leveraging the entire existing ecosystem of rust uh

inside of your knowledge proofs and so I think that the um you know as an example of the person who's proving the the proof of um reserves on near um actually just Imports a bunch of near crates and uses that to walk over the nearest merkelized data structure right um re-implementing code for complicated things like that is a large task and so if you're using a custom language or a student knowledge proof system that forces you to start from zero for everything you just can't develop nearly as fast so I think that you know this is a good sort of medium complexity example of how you're we can really Leverage The state of libraries this is more complex than previous examples but what we're

doing with risk 5 isn't more complex than what we did in Json um I mean I guess we have two inputs and two outputs instead of one of the inputs but nevertheless like this is not actually it was two in Json as well this isn't more complicated than the Json and the risk 5 side it's more complicated on the chess side and we're just using a library for that questions um have we addressed all the questions

at this point you're also welcome to come talk to us in the networking stuff afterwards so there's one other question of whether the prover runs in wasm I believe um and the answer is I don't think it currently does nothing technically would prevent that uh I think we just uh currently we have some like GPU acceleration support and a number of other things that um probably will cause it to not compile and was them but if you turn to that off and did it purely on CPU it should be possible to build a proven running wasm which I think has actually a lot of use cases like on the web case if I wanted my web browser to generate a proof that would be reasonable and feasible for small sizes of proofs so we probably should actually add some support but uh we don't currently have it on approver we do have

it on the verifier in in release candidate three or whatever it is now so we're very close to 1-0 we're doing the release candidates right now we're at 0.11 so thank you everyone for coming we really appreciate you being here [Music]