ZK Hack Montréal: Risc Zero - Boundless On-chain Execution using Proven Off-chain Coprocessing

Transcript

[Music] [Music] well hello everybody I feel like I should be singing opera or something this is the most elaborate ornate place I've ever given a talk at it's amazing it's amazing so thank you so much ZK hack for hosting us it's wonderful to be here all right so I'm I want to survey the crowd before I get started who knows about Dragon Ball Z Dragon Ball Z who knows this thing who what is this thing somebody speak it say it what is it it's oh it's a Fusion Dance yeah yeah yeah so like these these two guys they

kick some serious ass and they kick like 10 times more ass when they come together and fuse their superpowers together right so here's kind of the premise of this talk is that with onchain and offchain superpowers we come together and can do things that are orders of magnitude more impactful and valuable so you know let's do a little Fusion Dance right I like it uh so the other survey I want to ask in the crowd because this is ZK hack and I've been following like the ZK podcast it's my favorite podcast I love it all the concepts are amazing the people who are on there are great half of it's over my head uh who here prescribes them or would describe themselves as a cryptographer I'd say like maybe a third

who is like interested in cryptography and more about like the backend the circuits and the math like in general yeah maybe like half or so okay and who's here like I want to do stuff with zero knowledge and the math is hard like can I just write programs please that looks about another half okay so that's that's a good split what I'd like to convince the cryptographers and the math heavy people of is that yes that is amazingly impactful and important context because you have the conceptual ability to understand how to design proving systems I'd like to convince you that instead of going straight to circuits and trying to describe what you're trying to do in an application in

circuits land and in the um complex constraint systems that you guys know well you can just write programs that describe generally what you would like your proof to be so if you can describe your proving system and write a little bit of rust we can give you and out of the box actually remarkably performant it turns out zero knowledge proving system so that's pretty cool you write rust you don't have to write circuits but you sure can all right ah maybe one more anecdote about this so I got been following this podcast for years it's wonderful and I was very interested in how I could get involved but I'm not a cryptographer this is the first time with zero knowledge virtual machines where an

average jail like me who kind of can do stuff with rust can actually write proving systems so I'd like to invite all of you guys to maybe experiment without with that concept this weekend it'll be fun so why risk zero right why would you want to use the system at all I think a few things come to mind in general this idea of verifiable computation so more than proving to you that I know something I can prove to you that I've executed a program and it has executed correctly just as if You' ran it yourself and inspected it all along the way right so you don't have to trust me me you can use this fancy Moon math to make sure that I did my job correctly and then in the context of blockchains like we were hearing about

earlier like this idea of scalability right that this magical notion that we can do stuff offchain and then prove to a theum that we did our job correctly whereas we don't have to trust anybody even a malicious party should not be able to fool us if we done our moon math well right uh so the idea here is we can unlock potentially bound execution environment that is attached to a very confined very expensive computer system so we can prove things for cheap that would very expensive otherwise or potentially Impossible on chain today and then one thing I don't know if you guys have used uh who's here has like done onchain transactions of

any kind yeah like everybody okay so you guys are blockchain like at least definitely have used it that's awesome um everything is public almost almost everything is public and um even if you're trying very hard to be private on a public network you can mess up pretty easily um in this with zero knowledge we really can have true privacy and not today but probably soon true formally what the cryptographers would agree is zero knowledge on chain which is pretty cool so in in these systems we're able to access this privacy with zero knowledge virtual machines and other constructions without having to do very particular work around designing this

constraint system and this proof system this is done for you you just have to write programs and explicitly not make things public and they won't be public so why risk zero well we're we are at a hackathon so let's you're going to work on us because we give you money I mean like that's at least part of it right so we got some great bounties um one is very subjective and our team wants to give the best according to risk Zero's team application uh a pretty big price so if you guys work on something that we find inspiring and cool could be anything you want you get some money for that and then this idea of a ZK co-processor right um and in this notion what we mean is what I

was talking about earlier expanding the capabilities of blockchains with a side process the co-processor that is a zero knowledge virtual machine so we get some great tools to enable you to do this and whatever the best like blockchain integration is that's probably qualifying for this and finally we've got a whole bunch 15 of these and judging by the size of the crowd that might be anybody who would like one if you do anything with us and integrate Us in the context of any product any project and submit for any Bounty um you're qualified for these as well so just let us know that you're using Us in some way that's not like I copy pasted the code and like it might be compiled out but like it's in there I

think right do something with us yeah and you get some money so really leaning into that blockchain application space um who here does solidity development evm stuff yeah I see a few a few blockchains that are not solidity yeah I see a few I see a few more Yep so today we have first class like a lot of the world evm capabilities that we support and maintain ourselves and in this as an evm Dev if you're using risk zero um we can give you some superpowers that are impossible today so for example referring to historical State you know if you're trying to reason about how to like do a transaction all you have access to is the present state in the block that

you're trying to build on top of right well it turns out in this external environment I can prove that I know about some state that existed somewhere else on this chain or maybe a different chain and reason about this I can validate that that is true right so we'll get into some examples in this Workshop later about how I think this is a superpower power as well as um I come from the uh polka dot Universe in substrate got this concept of offchain workers right and this is like a an attached process that would expand the capabilities of your blockchain network in some way and your contracts but this is totally trusted by whoever's operating it and unfortunately a lot of the promise of like oh it's a side

process that can like run alongside my contracts but not actually use gas or something like this that's impossible in that construction but with ZK VMS it is true because I can prove to my system that whatever that offchain logic that the network doesn't know about actually went down correctly so that's pretty awesome and then boundless execution and in this sense there's a very tight limit of how much computation can fit ins inside the context of a block right and it turns out it's pretty small like if you get into it uh its Tinker toy level worth of compute is the ma maximum that you could fit into an ethereum block uh so if you want to go anywhere beyond that you must

reason about like chunking out whatever logic you want to do on chain inside a block and then like do the phase and then go to the next state and eventually arrive at where you want to go if you're able to describe this we have tooling that can do essentially an unlimited amount of computation that now fits into one very succinct proof that lands on chain and a verification of that actually is pretty cheap to to execute so so lots lots of cool stuff um and then I don't know if anybody here familiar with CK rollups right yeah youve heard the term this is kind of the end state of that boundless execution is I can put the entire operations of a network foreign to the blockchain that I'm on into

potentially just one single Groth 16 verification right which is kind of mind-blowing right is that all of that can be secured by one thing and we're hearing I think maybe later on about stuff like the bag layer the unification layer or whatever it might be where there's multiple different rollups that can all come and coales to a single proof it's pretty nuts so scalability you can get insane amounts of data and execution be valid validated by a single proof right uh also on that AG layer unification layer idea we see some really interesting constructions in Bridge world right who here knows about bridges or is used bridges of various kinds yes

this is one of the trickiest problems in web 3 I would say because there's so many ways it can go wrong and we've seen it blow up in a lot of people's faes I wouldn't say that ZK can solve this but we can do things like atomically compos transactions between different rollups that must uh complete together uh or otherwise both rollups cannot progress state right this kind of stuff is possible with this so it doesn't solve the problem of bridges but it makes it substantially less thorny all right so that's to get you inspired about some of the use cases we might be able to help you with um and in general then like how would you approach this this is a reasonably good diagram I think of the workflow that You' be

thinking about building a zkv m program with risk zero so you write some Rust code right this rust code is going to be compiled down along with whatever crates that you'd like to bring in which by the way we support something like 80 90% of the top 1,000 crates out of the box so you depend on it just like any normal rust code and it'll work in your program I'll show you later why that's cool it compiles for a risk 5 Target that's been slightly modified to be a risk zero zero knowledge risk five Target right as opposed to the native risk 5 architecture but it's actually only a few hundred lines difference in the whole tool chain it's very close you build with that tool chain to get this uh elf binary and is anybody familiar

with this as a concept the elf elf format yeah it's like this standard binary format targeting I think primarily Linux systems is that is that right does that sound right yes maybe so that binary then this object is what we put inside of this virtual machine construction right so we take this executable execute it and get an execution Trace right so this is all of the operations right and if I can zoom in on this let's see if I can you might recognize some of this oh no it's it's way too way too blurry all the register states of your actual machine right this is the actual

CPU and all the memory that you're accessing all the instructions that you're operating on this is the output that we then can feed subsequently into our proving system so this is what we've done at risk zero for every risk five instruction and all the possible ways that you can transition in a risk 5 virtual machine we've written a proof that you executed exactly as a real uh risk 5 standard machine would operate right so this virtual machine then we basically able to construct for any program a proof that all the uh clock ticks between each cycle and all the memory operations are correct they were executed correctly um and in this it might give you some hints for those who think about

performance man that's that's kind of a an expensive operation to literally every clock cycle we need to do an entire another proving operation like function against um but it turns out it's surprisingly getting more and more efficient orders of magnitude over time that I've been here in just a few months and I think we've got another few orders of magnitude to go even before the end of the year so remarkably efficient for the complexity that's behind this cool part you don't have to reason about the Prov stuff at all you just have to reason about your program that becomes this binary like a normal compiler uh compilation run this inside of a quote quote Docker container whatever it might be this is your virtualized environment and it pops out this receipt so this

receipt object contains three things two of which are important cryptographically one of uh things that's attached to this it's just for you is uh some statistics and meditata around how the execution went how the proving went and then inside of this has a cryptographic seal so this is an attestation that your program actually executed all the way to completion with an exit code of zero so you success sucessfully completed your program if you're familiar that's the the normal exit code you ran you finished great as well as a journal and in this journal this is the output of the program that you would write to like standard output as you might normally with like a print line statement we have a specific call to explicitly commit something to this

output Journal so we have in that is now attested to by this cryptographic seal your program exited zero and whatever you explicitly said was happened inside of this black box this is the output of it so you could say for example my program will validate that I played a game of chess and the last move in this game of chess board that you know about right has a Checkmate there is a move that exists on this board that I could move to get a Checkmate might be easy to sus out but I don't have to show you the exact move I can prove to you in execution of a chess logic program a crate that I import from the external world that a move exists I make the move and I check that it's actually a

checkmate with this uh chess crate and yes I can prove that in as a matter of fact that program executed correctly this is a checkmate at the end of the game it's kind of cool so very high level understanding of how these things work and hopefully that's gives you some useful context we'll give you some more examples so I I want to pause there two seconds there's any questions about that no we'll have more questions at the end maybe so I want to wrap all that up we have this proving system we make some receipt the receipt is something that we can verify of correct execution and the outputs of that correct execution somewhere so if you want to land this on

chain we have to somehow communicate this to that Network right so the general construction that we provide for you is a Foundry template Has anyone used Foundry this is an ethereum Library looks like a few yes great great so uh we have a foundary based template where you're able to um compose a transaction that will U eventually land in a contract on chain that whatever arbitrary logic you might like and inside of this it has uh connected to some pre-published for you uh risk zero verifier contracts and essentially this is an assert statement you just put in a single line that says run the verification against that receipt object

that somebody else gave me out in the universe and if that pass passes the contract can progress and if it doesn't you should bail out right uh this app I like to call an orchestrator right this is the glue that will take that whole virtual machine operation and all that uh program that you'd like to verify it wraps it up and either runs it locally or by default you can use a proving service out in the cloud uh this cloud has I think uh one of the largest uh Google Cloud instances that we spin up for you for free for now uh uh uh where you can run your proofs very quickly so you run it out in the cloud it returns this receipt object to you and then you

with keys inside of this orchestrator are able to go ahead and submit a transaction on chain to that contract with that um receipt and actually finally verify it and your contract progresses however you'd like it to so does that that all kind of make sense thumbs up thumbs up yep good good good cool well so with all that gives you a very broad sense end to end right from inside out is to what we're doing now I kind want to go back outside in and have Sasha come up on stage my colleague at Arms who can tell you more about the code and actually how to dig into this Foundry template so with that I'll let you take it

[Applause] away hello everyone thank you very much nuke all right so nuke has done an excellent job in explaining why you might want to use ZK why you of course will use the risk zero ZK VM as your only option today and nothing else and he's done an excellent job there thanks nuke uh for my part of the presentation let's all put our blockchain developer hats on for the longest time this hat meant actually using hard hat thankfully you know best friends ended

with hard hat yeah I'll just give a rip for hard hat uh and we have Foundry now I'm just kidding of course hardat is pretty sick uh but Foundry integrates really well into anything that uses rust right um it doesn't work as well with my like developer hat metaphor because of rust we only do metal metaphors now but it does look pretty sick uh when you put it up so that looks pretty awesome every time you open The Foundry docks and you're greeted by that I'm like yes I am building something cool right um and yeah so it's because of rust that Foundry integrates very well into the rist zero ZK VM stack we love it so much that we wanted to make your lives the developers lives easier so we created what's called and youas introduced it already the risk zero Foundry

template just in case you've never seen GitHub before here you go here's what it looks like it's not too exciting but you simply clone this repo run a few commands to get started so we'll walk through through that Qui quickly uh I'm going to take it very high level because I don't know about you but if I see too much code on the screen I'll yada yada um so uh at RIS zero in the ZK VM I mean yuke and I have been talking about this uh when you first clone it it can be a little intimidating overwhelming there's a lot of folders there's like cargo structures within other cargo structures

and there's like 18 cargo tels there's a reason for that but we are trying to make it better so please do come ask us questions um so there'll be one folder called contracts that's that's an easy one to get there's your smart contract and in this Foundry template there'll be a smart contract called even number. soul that kind of gives away what it does but there's this kind of like cryptically named function called set which takes a uint and x uh this interesting thing called a seal which nuke mentioned before and does a couple of things right interestingly like when you look at this function if you didn't know the fact that the contract was called even number. soul you probably wouldn't know

what it does and that's the whole point cu the the computation is actually done offchain right so let's have a look a little further right so let's stick with verification that's pretty straightforward like in the sense of everyone here probably knows the idea that you have a ZK proof proof and you want to verify it so I'm going to run through it high level and then we'll go into detail about the the things a little bit better but nuke mentioned we have verifier contracts you can call verifier do verify here the verifier is instantiated as a mutable contract address and don't worry about that like it's a proxy address so even if we add more verification schemes or whatever the address will still be valid on that Network we support lots of networks l2s ethereum I think we even have salana

coming don't we so stuff like that so that's very exciting so you call verifier verify we have this interesting thing called a seal which I'll get on to in a second image ID and a hash of a journal now this journal is also encoded interesting and then we have this number equal x so clearly something is happening a verification is is happening of a proof and then a number variable is being updated to that input argument X okay well I don't know about you but that doesn't really explain too much at the moment so let's actually write what's happening in direct solidity uh with it being onchain right so very

similarly we have set much easier this time we don't have anything cryptic called a seal we just take a number X and we say hey divide it by two if there's no remainder uh then go ahead and update this number variable so we can see that this number variable is storing an even number it's not too exciting but it's it's a good hello world example right so what was the all the journal and seal about right let's go back to it so at first glance I mean we've definitely looks like we've complicated things because this is actually that's pretty straightforward right like and then we go to this nonsense with seals and journals I mean it sounds like we're working in like a medieval library or something right well thankfully we live in the 21st century post the discovery

of zero knowledge cryptography so just like our medieval ancestors lamented the lack of their ability to not take compute offchain uh we can liit that we have silly variable names like journal and seal but actually it's not so bad right like I know which choice I would take right so but these two functions carry out the same computation checking a number is even but that computation is not carried out in the same place so this one is in the evm on chain this one's in Risk zero ZK VM off chain so we can see that the function here like utilizes the zvm for checking a numbers even and requires this extra input argument called the seal so back to what nuke was talking about before you might see yeah it's a little

small but there's this little blue box here uh for the receipt in that corner so very simply put the seal is a ZK stock or ZK SN and it cryptographically attests to the correct execution of the guest program which nuke will get into more details later right but and this guest program is in fact the program running in in Rust in the zkm to check the parity or the evenness of X and generating a proof so we have the seal in this case we're dealing with an onchain environment so we're using a

snark it's a little bit smaller more efficient on chain for gas so let's go to the journal what is this journal why are we encoding something right the journal as nuk mentioned contains the public output of the computation so we have this program that checks for if a number is even and it's going to write something to the journal this journal you can call in Rust and say Hey I want to commit something to this journal uh if it's important to me right and you're going to that stuff will be checked so you you want to verify that that those Journal outputs are actually important and actually are do correspond to the running of the execution right we do have this like encode X thing here which always throws people a

lot I get a lot of questions when they start with The Foundry template um so we're taking this number X in the input of ail function and we'd like to make sure uh that this number X is actually the one that was checked to be even in the guest program there actually a little bit of a context Swift switch kind of like when you go from web 2 to web 3 programming you have to think about like I don't know um you're doing transactions to update State and there's no front running and weird stuff like that right in the a re-entrancy right that's like this context switch you go from web 2 to web 3 it's a little bit of a context switch here as well cuz if I uh wrote a program a guest program that didn't check an even number and sent it

to this function here if the proof is valid it's still going to update the number it doesn't it doesn't know that it's checking for an even number right like so that's an interesting thing to keep in mind right like if it if the proof is valid the verifier verifies the proof against the seal in the journal the number is going to be updated I don't know maybe the rust program just just like adds two numbers together and sends that over right but you might think it's even number so just keep that in mind right like that's actually a lot of context in the zvm so we actually ABI encode this number here on chain the reason we're doing that is to as you see in the next line we're passing through that journal into the verification and what that means is when it actually gets

verified against the seal it will check okay does this journal look like the same one that the seal is actually matched against and that way you can check that everything is going smoothly it's really as simple as that in like a quick note in most of your examples I would hope that you're not just checking if one number is even uh otherwise we're not giving you that sweet Bounty cache but like a reconstruction of the journal is not always feasible like it can be quite expensive you probably have much more complex stuff than just one number to send through and so most real world applications including those hopefully build over the next few days will not not need to recreate the journal on chain you might just want to decode some

Journal information on chain just to do some sanity checks maybe with a require statement or something like that but if you have any questions please feel free to find me and yuke we have a booth down there as well for the whole three days so I've mentioned very briefly verification it's a very important step because that's basically all you doing on chain now right is is verifying here so verification is handled by risk Z's verification contract which as I mentioned you can find deployed across many chains in our application contract the verification contract address is instantiated at deploy time as I mentioned and it takes the seal or the proof the image ID and the hash of a journal so we've been through the seal

we've been through the journal the image ID is very straightforward uh it's a kind of like a hash of the elf binary just to make sure that you're running the right guest program um and it's autogenerated for you like we handled that in our build tool chain in fact there's even a solidity file that's automatically generated so that you can actually import it uh directly into a solidity contract as if it was a variable or library from another solidity contract it's just like a long hash one final thing to note for the verifier is you might notice that it's not a require statement it's just a do verify so uh you if you try to put require verify. verify and then some non-true statement in the string it' actually complain because verify actually reverts automatically it's not

particularly clear unless you read the verification contract so you can just leave it as verify. verify and don't worry we can trust it on our side the contracts are open source you can have a look we Bubble Up the errors through evm reverts uh so when you're testing in production sorry testing in testnet for example using tenderly or whatever you can see the error messages in case anything has gone wrong with your proof verification all right that was a lot of words uh and for checking an even number you may be uh very right to say well that seems a bit complicated doesn't it we have a seal we have a journal we have all these things uh and the right question to be like doesn't it seem like a little Overkill and indeed for an even

number it is a bit Overkill right you realistically want to take something more interesting off chain right the evm as limited as it is can handle one even number right I I was when I was writing this presentation I was thinking well how many n even numbers can it handle you know like just as a just as an interesting Benchmark right I thought how expensive can G really be in the gas block limit right so I wrote a little contract and test in Foundry with this nice little gas report feature and I was like all right it can't be that bad right surely can surely can handle it's pretty bad uh at a thousand numbers you're already reaching 23 million gas uh basically this is a super unoptimized

I'm sure if you're like some Mega God at Ule in assembly I'm sure you could probably get that down I'm just taking uh an array and checking each number in order uh if it's even keeping it and pushing it to another array if it's not moving on to the next number so testing a thousand numbers is a pretty legitimate like condition in programs right that's not so complicated uh I think back to my personal laptop 10 years ago probably could do that in like nanc and so paying 900 bucks for that I'm all right thanks Food For Thought H yeah so guess is expensive so you got to take that compute off chain the app so rather confusingly we have well we have two easy parts we have the

app contract that I just talked about with the even number. soul if you send a number to it with a proof that that number is even that number variable will be updated fine and it will verify that with the rero verifier we have Bonsai is basically like proving API you can ask hey I have this guest program I want the prove to be generated you don't have to faf around with like your machine taking 4 or whatever if it's a slow one uh you can just ask Bonsai it will request and send the proof and then you can uh put that on chain that's all good and and great but actually the most important in all this is this middleware that sits in the middle of this it's called the app rather annoyingly we have like three names for

it um this is why they've hired developer relations recently right so I mean like so you you might I'm going to also refer to it as the publisher because it does publish the proof on chain but it does more than that uh and annoyingly the source code is named publisher. RS but we're working on it so the main end purpose of this app or the publisher is to publish a proof to your application contract as we saw with that verifier right it takes that seal as the input argument which is the which is the uh proof in practice this means just sending a transaction on chain with the required arguments as we saw so calling that set function in the even number. and so what the app is going to do is you're going to request from the

Bonsai API that this guest program needs to be proven it's going to go ahead run that generate the proof send that back through the middleware and that's going to be uh then like relayed on chain using the using the app now this is all within The Foundry template by the way like it's like a full endtoend application including this app including the call to Bonsai including the ethereum side so you clone that you're ready to go like a full you don't have to worry about it too much so the easiest way to understand what the is doing on the ethereum side of things is to look at the CLI so you run this as kind of like a back end right it's a running service and you see there's P publisher there uh and there's a chain ID that's just like anvils one I think or something or maybe SEO I never

remember the chain IDs uh and you can yeso because of the RPC URL and you can see like we have this contract the even number contract and there's actually the number we want to check if it's even or not right so I want to send approve to this chain ID using this RPC URL calling on this contract trct with this input right all right now we get some Rust don't be scared it's going to be all right uh the really easy thing that like rust sorry excuse me rist zero does with rust is it does really make uh a like it's got very good dock strings in RIS zero so if you hover over any of those yellow things you'll get fantastic dock strings that explain everything um in this case we mentioned the receipt before that little blue box

in the corner so that receipt is going to contain the journal and the seal and the publisher the app is is going to need that in order to actually send that onchain to the even number. soul contract so I I usually just barely even read the code and just hover over the stuff till I get it so the if you hover over uh default Pro object there you'll get these fantastic proving options pinch for very good devx uh the Bonsai prover so basically you might be wondering well we're talking to Bonsai but I don't see any call to Bonsai here and in fact if you read the full code there there is no call to Bonsai It's all abstracted under the hood if you want to use Bonsai you just set the environment variables of the Bonsai API URL and your API key you can speak to me

and yuke if you need an API key we'll be glad to hook you up we'll be at the booth you go and it'll be automatically used like that would just be all used for you like you don't have to worry about it you don't have to fuf around with sdks or anything you'll just talk to Bonsai and then send it over which is really cool once you have that receipt you want the seal you want the journal so so much medieval library terming today so we get the seal we get the journal and then we we decode that journal just as I was talking about uh we want to actually have a look at what that X was that was committed the actual number that we want to check and finally we use like alloy and all those other things just standard interfaces for generating the call data

to call uh to call the even number. soul contract from straight from rust so if you've used ether's JS before or something it's very similar um so the call data here is generated from an interface in you can see it all in the publisher. RS and you just want to call this even number contract with the set call uh which remember the function is called set give it X give it seal those are the input arguments and we're ready to go okay thank you for listening to me that was long and I appreciate explaining like four different files is not probably not the most interesting thing to see on screens but you've all done great thank you very much so in the summary we've used used r z KVM for an onchain app we've carried out this

computation of chain in this case an even number so that's The Foundry template we cloned it we got started we kind of run it all even with the app CLI and saw how it works in The Foundry template there's very good readmes there's a readme called deployment guide which if you walk through that you can run it locally on Anvil and it's basically like a hello world you'll get every step yeah and we learned that gas is expensive so if you didn't know already gas is expensive I mean of course by the way my number numbers were for L1 I know no one's going to be crazy enough to check a thousand even numbers on L1 but I mean this stuff does add up overall right like uh and also just kind of goes to show how limited the compute is and to summarize with the publisher

the app we've seen that the importance of the publisher is like the main orchestrator requesting the proof from Bonsai interacting with the application contract we have here on the left and yeah being the like back end of offloading the computation from the evm over to risk zeros ckvm cool well that was a lot obviously you're all going to be hacking very soon uh no G commits no G pushes before seven right no one's doing that good uh do not copy and P the uh the next inspiration you'll have but we've had obviously quite a few Builders using r z KVM and we're very grateful for your feedback by the way on that note one very quickly come roast us right like if something

doesn't work the dogs suck that's what we're here for right to make it as easy as possible uh so please don't don't don't hold back we need as much feedback as possible um and so first just for some inspiration we had we have Andrew here who's going to come on he is a winner for one of our hackathons at e Denver so he's going to come on and talk about his winning project ZK snake thank you for listening everyone yeah thank you Sasha very much for introduction uh zik snake is a project is a proof of concept for verifiable gaming so the question is why do you even want to verify gaming on chain well to begin with you want to

prevent cheating sometimes there were a couple of instances for example of Minecraft speedr Runners where they would touch up the odds so that they spawn new structures the loot in the chests becomes better and stuff so you want to have a verification of the code you want to have a verification of the score you want to have a verification of a speedrun time and so on and so forth ZK snake is a proof of concept where I and my team at East Denver be verified the snake game so you have a risk zero snark proof that you obtained a certain score in a snake game how it is done is that we just firstly the user plays the game in the browser and then we replay

the game inside of risk zero virtual machine uh there is a link to ZK snake Source here but uh I'll show you the demo right now okay yeah no that's wrong one sec technical difficulties okay there we go okay so as you can see we play just a regular game of snake the snake eats a bunch of like food and stuff and well

accidentally we crashed now we can click the mint button to which will start the pro process I will explain a little bit more in details what happens afterwards but in this case the user just clicks the M button and in a couple of minutes they will receive an nft saying that they obtained the certain score so like in this case somebody obtained a score say of 12 uh or 13 or yeah a lot of a lot of plays where at the game and this is publicly on openc test net now what is actually happening how is this all achieved once again I want to return to

the uh Sasha's publisher template we have the app this is what I was hosting and the app would read the onchain snake game data this game would be sent to Bonsai for verification it would be run inside of risk zero virtual machine afterwards Bonsai would return back the the seal and the journal in my case the journal was the score that was obtained in the snake game and the seal well just a snark proof afterwards this would be be sent on chain to the mint contract that would mint an nft only if the score that user obtained is

valid um yeah this is basic overview so of of the ZK snake now the question is why why do you care why do you want to like um oh I I've mentioned that you want to like have the you want to prevent cheating you want to prevent uh people maliciously publishing code uh also this can serve as an inspiration because there is a cool thing called Bevy a game engine written in Rust you can potentially write a more complex game and prove it inside of risk zero uh by the way going to mention continuing the like the thing that started in '90s Doom is proven Doom

is proven yeah in Risk zero um okay in this case I'm going to pass it back to Nuke to Contin with a things that you can do with risk [Applause] zero good job man exactly so that's really inspiring uh I don't know about you guys but being able to like have a leader board that says screw you I got this game score and I won't tell you how like that sounds fun to me like a verifiable leaderboard and hey I can like award prizes that are potentially valuable on chain to you and you can't cheat cheat anti-che engines there's a lot of cool stuff that ZK games can do right um so but we can do

more than just like prove that you did something offchain we can also do kind of the inverse we can look onchain and do some interesting logic and reasoning about that and do proofs potentially back on chain or out to The Wider world that doesn't have access to a particular evm so here with the steel Library we use alloy has anyone heard of alloy used alloy here yeah it's it's a rather newer library that allows you to communicate with evm networks in Rust right um so we wrap that in our ZK VM and the you know I guess metallurgical joke here is we make steel out of iron and and I guess the ZK stuff or whatever but it it gives you this idea that trusted offchain

worker that co-processor where we're able to actually reason about stuff that the evm cannot do like historical state or view calls in general so I won't get into the details today but tomorrow I promise I'll show you how to do this um the example that I do is basically composing two different first class examples that we maintain uh one of which is an erc20 balance and the statement that you make with this proof is that I know at a particular block hash on this network a erc20 contract has a balance of x amount for this Con uh for this user or excuse me account right so for example I could say that

you know you hold 20 dogecoins uh that I created on this year C20 contract what it does not say in that example though is anything about the ownership of this I prove nothing about whose account I'm reasoning about so we extend this with an ecdsa signature that you ver verify a signature was generated by the prover themselves that is associated with that address so now the statement becomes I own this balance on a particular EDM Network which I think is a more compelling statement in a lot of use cases like token gating and things like this so I'll show you how to do that tomorrow come tomorrow so then I want to wrap up uh and give you some little bit

more tidbits of like why I think risk zero special um developer productivity is the name of the game here so as Sasha pointed out very rightly I think our devx sucks and uh please tell us how it sucks thank you for being Crash Test Dummies it's it's a job that is important we can figure out how to make this better for everybody if you let us know how it's bad right um but in that I think we are already doing really good stuff if you can write rust mostly you can be very productive in our stuff very quickly you don't have to reason about the circuits we've done that for you you reason about the business logic that you want to implement in that there's the top 1,000 crates are tested nightly to

make sure that they're compatible with our zkm and I think something like 80% of these guys are compatible directly the primary breakage comes around any CIS calls because you're in a very sandboxed virtual machine you can't talk to the network directly and you can't talk to file I out directly you have to emulate this we don't provide this for you out of the box yet right we might eventually give you some interfaces and some hooks but for now that's the primary thing you can't do uh but really I want to emphasize the point finally that ZK dsls right what can be really hard in there like branchy logic and things like conditionals um those can be really Breaky and hard to get right but it's trivial in a zkm you

just write a for Loop right it's pretty cool uh some other superpowers uh so this idea of boundless execution well it turns out that we can do some fancy magic for you in the background that uh we use proof recursion so we take that execution trace and we break it up into different we call them segments and we prove each of those in parallel and then lift and join these all together in recursive proofs to a single proof in the end and because of this you really your execution Trace can be effectively as long as you'd like and the requirements to run this proof scale roughly linearly or you can execute like a single thread of this with a fixed set of memory for a very long time or throw it at a GPU with

a chunk ton of uh vram and run it very very fast parallel right so this allows some really powerful unlimited program execution and as well with that recursion property we can do I like to call proof setion all right we can take a proof and verify it and then put that in another proof that verifies that receipt object right and actually we have an accelerated version of this so it's not uh it's even more performant than you might expect where you can take a proof for example from your client side environment we don't have an example yet but I want one and send that off to Bonsai out in the cloud that runs a much more

sophisticated harder proof and then amounts to a proof that we might land on chain right so you could do like private side or privacy preserving client side proofs that get batched into some defi uh swaps with a bunch of people and then lands on chain is like okay this is the new state balance for everybody so that kind of is possible all right and then like we really emphasized here I think there's some things that were impossible or impractical before that are trivial or like pretty cheap today that we can do with evm so we'd love to see that that's why we put some bouny specifically on this kind of stuff before you really dig in though there's some uh words of

caution and we'll go over these again in the workshop um you want to really be careful with versions one of the worst devx things that we've run into is if you mismatch versions anywhere in like the six different places because the convoluted structure of this whole Foundry template you might run into problems that are kind of buggy so check your versions are all right for the risk zero tooling and dependencies because it's important keep your guess minimal although it's cheap and you have unlimited computation it's not very uh efficient to put everything in the evm like uh was mentioned our ZK Doom example uh like our hat is it's the Doom logo I don't know if you notice uh so this we run the entire game logic and

the graphics and everything in the zvm but we progress like I think 10 or 20 frames into the game and then cut off and it takes like an hour on a GPU cluster to run so like don't do that uh put only what you need in the guest to prove what you would like the statements that you would like to be proven in general that's all you want in there it's a hackathon though so like this is why we have a cloud computer so that your hackathon project can be expensive to run but like we'll we'll do it for you why not uh when you're experimenting always always always use Dev mode so one thing that we W want to make apparent and I'm pushing to get the default is that the only thing you're doing in testing is execution right no proof you entirely

mock or skip the proving step because that's the expensive part the ex execution though must be because this is how the proof system works identical to the proof being correct right so if you write a program that's good it's our problem if the proving step is broken so you get the execution right and you can assume that the proof should work if it doesn't come find me cuz I got a report to the the the uh Galaxy brains back home H if you need to use a uh Bonsai we'll give you an API key don't abuse it please it's it's a powerful computer for you to use for free and join our Discord so there's a Discord for ZK hack will be in there and monitoring the risk zero

Channel specifically but also we've got our own dedicated server and we'll do office hours there I'll be hanging out if you guys want to talk shop um and do a dedicated Forum where we can answer more specific questions and have our core team answer some of those more nitty-gritty things that are over my head so yeah I guess I'll leave you with this last closing thought is you really don't have to know these crypto details but you are designing a cryptographic system right understanding how your system can be abused and the adversaries that are out there in the world that want to try and break whatever kind of things you're building that still exists so you don't have to get the crypto moon maath right but you still need to build your cryptographic system correctly so with that dig in dive deep guys and

thank you [Applause]