ZK Hack IV - Get Rusty with RISC Zero: Build your ZK Rust Application

Transcript

So yeah, we now have the risk zero workshop. The workshop is called get rusty with risk zero. Build your first well no maybe not first. Build your zk rust application. All right. Very cool. Take it away then. Okay. So hello everyone and welcome to uh ZK um risk zero workshop. get trusted with risk zero and build your CK Rust application. So today we have uh presenter our um CEO Brian Redford he will be presenting with us. Hi Brian.

Then I will be doing bit more uh I will continue a bit more of a workshop and then Hans our solutions engineer will uh present our latest uh Bonsai demo Bonsai pay. So um after after Brian present um uh presents a bit of like his part we there will be a Q&A session with Brian. Uh but let's uh first uh see what we are covering today. What's what's our plan? So um we start with introduction to risk zero and then we'll be looking at the two u products risk zero product ZKVM and bonsai. We'll start with ZKVM. will go

through ZK uh ZKVM architecture. Then uh uh then there will be a Q&A session with Brian. Then we'll go through I will run you through uh Risk Zero terminology and we'll look at the kind of most exciting features of ZKVM and things that make risk zero ZKVM stand out across uh different available zero knowledge virtual machines. Then we have a um architecture overview of our proof systems. Uh we'll go through a quick start. So I want to make sure that you guys who uh our audience developers um ready to start building. So after this quick start everyone will uh run u our

ZKVM um ZKVM and then they will generate proof zero knowledge proof on it. Then we have a break in around like 45 minutes. Um and then we dive into Bonsai our ZK proving uh service look what it is and where why we need it and when is it to use it and we go through bonsai pay walk through with our hands. So um um after each section I will pause for a bit so and have a quick look at the chat to make sure that all questions are answered. Uh but uh if there is some uh questions get too specific, I will uh I will um I won't read them loudly. I will

reply later um through Ziki discord channel or one of my uh colleagues Paul our Zik researcher or Hans uh they will be helping also answering questions. So uh and now please welcome uh Brian our CEO and co-founder of Risk Zero. Um thanks Arena. Uh thanks for putting this uh workshop together. Uh really excited to to get into it. All right. So risk zero when were we started? We were started in 2021 and I guess from my from our perspective we're focused on revolutionizing the internet by creating like the infrastructure and

tooling necessary for web3 developers around the globe to build zero knowledge software. We're doing this by bringing general purpose computing to the zero knowledge ecosystem which enables users to trust programs run anywhere while allowing developers to use the tools they already know and love. So while this is true, it's not technically true. We actually started in about 2020 and we started um you know we started by building a bunch of like building a proving system sort of from the ground up and then writing a bunch of circuits which we all know is very fun but also extraordinarily difficult and and kind of hard to maintain. So while we were, you know, experimenting with ZK, uh, we

came up with this notion that wouldn't it be great, you know, to program a ZK system if if you could actually just program it like any other microprocessor. So this how we got into Risio and how we decided to create this general purpose ZKVM. Next slide. So what does it even mean I guess to have a general purpose ZKVM and and what you know how does Ri approach that? So we took the open- source risk 5 micro architecture which was developed by a bunch of different uh teams out of Berkeley and the company SciFive and it's still very actively used and risk five cores are actually showing up in

all kinds of hardware uh in pretty much any system that you're going to buy these days there are little risk 5 cores everywhere. So risk 5 itself is like ARM or like x86. It's a description of how to program uh computer in a way that you can run any program. So the circuit that risk zero actually represents uh we actually have several circuits uh but the main one is this ZKVM. So it's a circuit that takes risk 5 instructions and proves the execution of them in zero knowledge. And it does this by using uh ZK starkbased system. So uh run the same circuit over and over and over again and build up

this this kind of trace over time that one you know when it's complete and you actually prove the entire trace you're proving the correct execution of this risk 5 program. uh I don't think we get into it too much but we do also have these sort of accelerator circuits which are useful and necessary for um things like uh cryptographic operations such as hashing and various signature algorithms. Um yeah, next slide. So what does using the ZKVM look like?

It actually you you really you write regular Rust code. There's a certain way that we tend to structure it. So there's a host and a guest and I think Arena will get into all of that, but it really is just Rust code and a standard compiler produces something called an ELF. This is just a way of wrapping um executable code and containing it in a format that um operating systems are able to interpret and and load. So you can think of the ZKVM as as its own little computer and it loads this this uh ELF binary into an exeutor which actually runs the program, figures out what you know should happen and creates this log that can then be

sent to the prover uh which then proves it and creates this succinct receipt that you can then um you know post on a blockchain or do anything else you want to do with it. Yeah. Next slide. H okay. Slightly different than the one online uh that I saw earlier, but that's fine. So yeah, but why is this important and and what can it do? Uh general purpose ZK is important because honestly like maintaining complex sets of circuits for complex state machines

over a very long period of time is very expensive and incredibly difficult. It might make sense uh to do this but uh for certain systems but we tend to think that it makes the most sense to focus for developers to focus on the actual state machines and the programs they're trying to prove. I think the work that we did with uh ZETH and that we're continuing to do with with optimism um really highlights this. you know, we took an entire uh EVM the that was largely coded by other people, modified it slightly, and and then we're able to prove um you know, a full we're able to create a full type zero ZK EVM in just

under a month. Um, and you know, this approach actually lets people modify the the EDM and continue to create, you know, validity proofs for it without needing to, you know, go back and reconstruct a bunch of circuits um to to create some modifications. So, I really see general purpose CK as creating uh a massively lower barrier of entry for developers in this space. and not just barrier entry but also decreasing the like full cost of of building innovative ZK systems over like a very long period of time.

So really the ZKVM lets you create programs that are maintainable uh and prove them in ZK easily and quickly. So uh now there is opportunity for anyone to ask a questions uh on the chat or on Q&A uh ask questions to our co Brian. Uh yeah so we can go in order um here see uh yeah so how is correct memory access proven? uh that we actually there's a a talk from ZK summit nine I think might be eight where we actually go into this and and there's

some material on our website but it it's actually like pretty uh you know it's a pretty long discussion but there's there's a lot of material about that it's pretty interesting and it's actually I would say um you know an active area of research everybody approaches it differently I think our next version of the circuit approaches it slightly differently and you know how exactly that works actually gets into this sort of continuation system that we have which lets a program be split up into many many chunks that can all be proven in parallel. Um, cool. Is the VM stateless more like co-processor? So I would say the VM is not stateless but you pass the state into it. So in

the context of building say say you wanted to build a ZKVM L2 the state would live you know on a blockchain as it normally does but then when you go to prove something you you know pass your inputs in and you get an output back so I guess in a sense it's it's stateless like we don't currently have a system that we provide to people to maintain state between um like executions of the ZKVM although there's a lot of really exciting possibil ilities there and I wouldn't be surprised if we you know eventually do release something that makes uh that makes more stateful programming simpler if that makes sense.

Let's see. Do I understand correctly? The zk part of a calculation faals b a return b. Can FA and the public slashshared part uh can be a I think that an amazing thing about ZK is that you can actually um yeah you can decide to share any of uh the inputs, the outputs or the program or you can choose to conceal all of those as long as you have a consistent way to you know build the program and communicate with other people what the program is supposed to do. So really you can you can any part of it can be public any part of it can be private.

See uh do we consider to create a sort of proof generation layer to interact with? So that's what Bonsai is. We'll be talking about it later. Um are there any future plans for enhancing the risk zero proving system such as incorporating alternative systems like snark lasso and jolt or others? Indeed, uh, we're constantly working on on improving the proving system. The current next version of the circuit we're actually we will be releasing as soon as it's stable enough to do that and it's uh quite a major leap forward and has an entire compiler infrastructure and uh yeah will be easier to incorporate different sort of lookup uh techniques. Uh I will say we already sort of incorporate alternative

systems like snarks in a sense. you can actually take any of our starks and um and sort of exchange the Stark for a GR 16 proof that you can post to Ethereum. So I think we also cover that in a little bit. See yes uh a circuit is always finite. However, the runtime of a normal program is not known priority. How do you solve this? Well, um, yes, circuits are always finite, but the way it interacts with the the input to the circuit is the actual set of instructions. And um, yeah, I mean, eventually it terminates or not. If it never terminates,

obviously you can't create a proof of of it not terminating. That's what I would say. Is there a known protocol and tooling to upgrade the ZK part of the proof to say H I don't think so uh exactly if you're trying to say you know if you're trying to reference um a prior program and say this next program sort of yeah I'm not sure exactly what that question is um but if you can clarify maybe we can answer more uh in more detail later.

See are there efficiency trade-offs for using general purpose ZKVM on different blockchains? Um, I mean there's always efficiency trade-offs I think in in every ZK proving system and uh, you know, it really depends on the use case and and what you're doing and how much efficiency matters and and all kinds of different things. So yes, there are trade-offs. Um, why the choice of Stark? Starks are very good at running the same uh sort of circuit over and over again. So basically they're most efficient for ZKVMs. Um and you know we're primarily as EKVM.

Ah see how why did we decide to use a smaller field? So I think we were sort of pioneers in using the baby bear like sub 32-bit fields. It's actually um the risk v is there's 64-bit versions and 32-bit versions. We support the 32-bit version, but the reason we focused on the smaller field is because we're focused on GPU acceleration. And um basically being able to fit everything inside 32 bits is usually a win on a GPU. Yeah, I think Riser is not aimed as a replacement to the EVM and I think Zth is a really good ex example. Sorry. The

question was, is Risero aimed as a VM on ETH L2s as a replacement to the EVM? Um, I think we'll see people using it to add general purpose functionality to Ethereum, but also um we'll see people using it for co-processing and and other applications that very much are, you know, the EVM. See, is it possible to use the ZKVM of RER in a small embedded system? I mean, possible, yes. Practical is really going to depend on on your use case. Um, I for one would love to see uh like a a small device that would let you scan

one's passport and sort of print out a QR code that you could scan and get like a a proof rodacted proof of something from your passport and it just have that program live on a tiny microcontroller. And that's probably possible because the latency demands are not super crazy. See, what applications outside of blockchain are you interested in for the rism? Um, it's interesting because I think blockchain can apply to so many different things. Uh generally speaking, the thing that I get most excited about these days is the combination of ZK identity for anti- syibble uh or let's just say like being able to

create a service with a set of users that uh it's much harder for people to sort of abuse the service and utilize the capability of ZK to let people you know prove um the correct execution of programs to create I guess I always think of it as like a public AWS or a cloud where people can actually create programs and have the programs kind of pay for themselves um indefinitely. So, I I saw there's some article in Hacker News that that Jeremy forwarded me where somebody was lamenting that, you know, you can't everybody's into like baking sourdough bread, but like making a making an app and having it exist in the same kind of context as that doesn't really work out.

So, I don't know. There's something I'm really excited about in the future. Uh, yes, basic full stack applications. I will let um I will let the solutions engineering people answer that. We have we certainly have um examples that show how to do that and then we have some full stack applications but the full stack application I think like bonsai pay is a bit more involved. Um is it feasible to develop a privacy preserving machine learning library utilizing risk zero? certainly possible feasible. I think that's uh it seems

like we're a couple years off from from those things being feasible in my mind. Period. Yeah. Can ris to compress previous state such can risk zero be used to compress previous state such that the size of a node is reduced? I think the answer is yes. H I don't think we will be sketching the uh sort of exchange between a consumer and user and the ZK provider. Uh the bonsai pay example actually goes through a lot of that actually. So yeah, maybe we will be see so many questions. I love it. How does it compare to a T?

uh very different from a T in the sense that you know the ZKVM doesn't guarantee privacy of uh privacy from the party executing the the transaction. Uh it it can produce a proof of correct execution that masks inputs but the person executing the proof will always have access to the sort of state of the program and the inputs. Um so I actually think T's and ZK are totally complimentary. I think scroll just maybe put out a post about that a second ago. Um, so you know, running ZK things inside a T is just a way to add what lets you add the the privacy component in, but it gives you this sort of portable proof of correctness that's not dependent on on, you know, centralized

signature signing authorities like TE's are and not as compromisable um over the long term. I think Thor asked to what degree do we believe or do I believe that all Stark VM designs will converge on a relatively similar architecture? I don't know is is my answer. I think there's probably room for them to be different, but um I think the tools in which people use to create these kind of things will probably converge over time. That's my guess.

Um yes, can risk zero be used to create workflows on chain with privacy? Um where some of the components are private and some of the execution is public? The answer is yes, but you kind of have to. Getting back into this like T example, you'd want to run the private part either in a T or locally or via a sort of trusted proof uh provider that doesn't, you know, that doesn't keep logs of everything. um like bonsai. I think ZK identity would love to I think we'll probably have to save that for a different uh different uh time or actually Bonsai Pay gets into it a little bit. Um which benchmarks do we care most about

when comparing ZKVMs? That's a good question. Uh we've decided that we care the most about real world benchmarks. Um, sadly we haven't, you know, I don't think we've settled on a a set of use cases that are um, you know, that are most representative of what's interesting in the real world. I think we're starting to see the kinds of things that are like verifying jotss. We'll get into that with Bonsai Pay and then obviously, you know, building Merkel trees and things like that, but there's probably a lot more and I think that would be a fun thing for industry collectively to kind of uh, you know, agree on. So we could start thinking about comparing ZKVMs in a ser way.

Um all right is zero mainly aimed at generic offchain execution and proving onchain. I mean that's certainly something you can do with it and um and we're building tooling to make that easier. But I think getting back to the start, it's really aimed at at being a truly generic ZK uh proving system. Do we ex do we integrate with any proof acceleration systems as a service currently? Yes. Um that would be Bonsai which we built oursel. Um we will almost certainly be integrating with other people's systems and also extending the set of people who can run nodes for Bonsai in the future.

Ah, so let's see. You mentioned risk five chips, but can you run a risk zero program on a computer with an ARM? Yes, it's just a VM. So just like you can um sort of run an x86 program on an M2 uh MacBook um or you know you can run you can emulate ARM for mobile development. Um you know yeah you can run a risk five risk zero program on any architecture that it compiles on. Um, and then all right, last easy question. Will you all be at ETH Denver?

Many of us will. Yes. Excited uh to go back to the the rodeo there. Cool. Thanks for all the questions. Thank you so much, Brian. It was super super great. Thank you. So I will continue I will continue with a the terminology and but I believe Brian will be still here. So feel free to ask questions. Uh uh there is a my colleagues there there is a Paul and Hans who will be answering questions as well. So let's move to the

terminology. Sorry. So, uh, Brian just went through through ZKVM architecture, but let's let's look um how we call it within uh risk zero. So, we have uh guest is a program that is running uh inside KVM. So, this is actually that input program that you as a user send to the ZKVM. And uh we also have a host. So host is a system uh that uh runs the KVM and host emulates the guests. So um uh it like

reproduces the program. And then we have a prover. So prova is the portion of zkm uh that's uh uh verifies the uh correct execution and then approves this guest program. So it construct the proof and it also construct the receipt. So uh let's uh let's look again at this zvma architecture. So here we have this like guest code. This is the program that you send to the ZKVM. This is what you want to prove. Um and proof of this uh guest code will be

generated. Uh so this is your Rust code. So then uh you got this um it will be run on the compiler and generated executable ELF binary for you. And uh this is the host. So this is where you run the KVM. And um uh this is this part is a prover. So it validates and proves uh guest program and construct receipt. And uh uh you what you get out of ZKVM is receipt that uh uh that uh attest the valid execution pro. It's uh this is evidence of valid execution of gas program.

Uh so and then uh so uh how we uh how we do it. So we have this like host and host simulates the guest and sends private data to the guest uh to the uh ZK socket and then ZK socket uh execute code and can the result to receipt receipt uh uh return back to the host as a proof of the computation and then host can like forwards this receipt to verify for checks.

So and um so receipt um as we like so uh receipt contains like two parts. This is like receipt that validates the execution. It has a journal the portion of receipt that um uh contains like public output of ZK uh of um of this program that uh you you sent this like guest program uh that you sent to ZKVM um and the seal seal is the portion of receipt that keptly um uh attest the correction execution of the guest program. So basically seal is zk stark uh uh stark proof and it's generated by

this approver. So uh receipt uh has like two parts like journal which is like public output. So yeah be very careful what you uh commit to journal because it will be available to everyone who has a receipt and then seal this uh zero knowledge proof. Uh so basically it's a collection of harshes and um and uh yeah so this is uh our terminology. So we have uh uh so we have a guest uh that uh this is the program that uh you run uh you send to ZKVM to run and to validate and create ZK

proof of and you have the host the host actually run ZKVM um it's uh and also uh sends private data uh to ZKVM and this um and then there is receipt that is the object that contains uh zik proof of the val of the of the correct execution of running guest of your program and uh which is a journal and seal. So this is uh a couple of main um um main uh terminologies and definitions that we're going to use through this workshop.

Uh so let's um uh let's look a bit like under the hood. Uh so what's uh what's in the receipt? So uh this is like Zik Stark uh is a this is the part that is a seal like Ziki Stark. So since uh so Brian mentioned that we use uh Zika Starks and um uh the proven verifier. So we use like fry algorithm and deep ali with a familistic and to proof uh verify that execution trace uh satisfy this uh constraint appropriate constraints and uh this is execution trace um

execution trace uh this is uh happening within zkvm. This is like when the uh guest program the program the R code that you sent to CKVM has been like executed and then uh this is um uh basically um a table of um states. So each row represent a clock cycle and each call column represents a register and then um this execution trace is uh sent as input to the prover and prover proves that it's been ver uh that has been run correctly. So if we only needed to prove and check the correct execution

then we uh this is would be enough but we also need to generate a zero knowledge proof. So that's that's where uh we need to go a bit like further. Uh so we have uh uh this like trace as a witness. So um uh so we have to make sure that the initial state matches uh claim code uh the results uh claimed and there is a computational integrity. So each step must be uh what risk uh five processor would be and we encode the trace algebraically. So we uh so to make sure that the uh conditions become algebraic constraints and encode trace

uh is a weakness. So um another part that uh we wanted to uh to um to go over is um our new features that been released uh last year and uh we are super excited about it and this is um this is uh continuations and this is something that no one else uh actually um has in within their VMs.

within the KVM. So nobody else uh generated continuations. So uh it means that nobody else can uh generate proofs uh on like parallel clusters. So um before uh so before uh continuations came around there was uh sometime like limit how large was uh your program that you can send to ZKVM to validate and to generate ZK proof and um uh so now with the ZK uh ZK uh with this uh continuations it means that uh we can do very we can produce a proof of very

large uh program and uh the biggest that is done is a billion uh cycles. So but basically it's like how long our engineers conveyed to on the proof and um so uh before uh before uh continuations the maximum proof uh size was 16 million cycles and um now uh after continations it's around like 10 billion cycles and u this is uh that nobody body else is doing like the parro uh proven and this is by far the biggest differentiator of

uh risk zero KVM in comparison with others on the market. So you can actually dates improves and it's like really really fast. So and um so yeah this is very exciting and this opens quite large um new use cases that were not available before. So it's um uh so this is the main uh our differentiate and main advantage of ZKVMs and bonsai. So now we have continuations and uh also we can uh uh op um we can optimize our proofs to make it small to have it on

chain just like in a second you'll see how we do it. And um yeah so now all the pieces of our systems are in place. So it's you can uh you can take very large RS program and run it in G junior proof. uh you can also validate it on chain and we also introduced Docker that uh um uh so to make sure that uh you can run deterministic compil compilations and um yeah introduction of continuations just make uh and bonsai just like make the whole system like faster and uh um allows um very very large um programs to uh to be used as an input to ZKVM and to

generate ECK proofs of very very large programs. So um so this is um yeah now we have uh 10 billion cycles but um theoretical maximum is around like 100 trillion but uh yeah this is uh the the largest uh that we run and uh yeah very exciting very exciting times uh for sure. Uh so let's um let's go into uh our proof systems and uh learn a bit about what it is and the architecture of our proof systems.

So um so we uh architecture of our proven system at risk zero is very very similar to uh architectures of several other mature ZQVMs. Plus we have continuations which means that you can uh uh you can generate ZK proofs uh at very high speed and you can generate ZK proofs of very large uh uh programs and code and but our like so it's very similar to um polygon and zk sync but um but we have our like advantages. So uh let's let's look closer what's uh zkm. So in a normal um virtual machine uh

there is a process where you send program as an input and uh you send input data for this program. You send these two input parameters program and input data to the VM and VM runs it on this data input data and generate output. So all is uh all is correct. But for ZKVM, it's very very similar setup. So you have input uh program that you want to run uh emulate on ZKVM and uh you also send input data for this program and uh ZKVM runs it for you and produces not only output uh but also proof of running this um uh this uh um

uh this program on this data. So there is a proof uh of correct execution and uh this output of like journal and proof as a seal is a uh is inside one object that we call the receipt. Okay. And um uh so this is very similar to uh virtual machines to general general virtual machines and if you look closely to risk zero it's already like very generic um because you can u you can submit programs in rust. So this is uh also quite a

uh quite an advantage in comparison with other uh zero knowledge virtual machines. So let's look at the recursive proving that we have. So uh recursive proving is when you take several proofs and uh zk proofs and uh compress them into a single proof. So you aggregate proofs into a single proof and these orange objects on the on the uh on the slide is receipt right. So on the first layer here there are like four receipts that been generated by risk five circuit right. So four proofs and we take two of these receipts and um use

them as the input for our recussion circuit right and uh they produce another receipt. So you take four receipts and you send them as input to recussion circuit and you have uh output as a one receipt. So this is this way uh we can use a recussion to compress any amount of proofs into a single proof and note that uh the initial receives here uh they came from risk five circuit and they actually like uh two stark circuits here right so risk five is like our initial circuit that u uh that uh generates our proof of risk five

execution and then there is a separate recion circuit that uh that we use to compress our proofs uh our Zik Stark proofs and at the end it compresses into one uh stark proof. So the uh this is diagram of a single proof of risk five circuit and this is um this is the executor that and uh this is part is approver that's uh if you remember what Brian explained like at high level ZKVM architecture so executor takes a trace uh from uh from the binary

and generates uh And it's been like split into several uh several of parts and each part sent to the prover to generate uh risk five prover to generate a uh stark proof. Right? So uh we generate like several receipts and then we use a recion to compress uh those receipts into a single receipt. And then uh finally we use growth 16 uh circuit to uh compress um our receipt our stark receipt into something small enough that uh can be verified on chain.

So uh we use starks for all of these uh uh proofs. For the risk five um prover and for a cushion circuit we use starks and um the proof size for starks in our system is around 250 kilobytes. So the gas cost would be too large uh to verify it on chain. So that's why we added one more circuit here growth 16 so circuit uh to our stack which is a snark wrapper and this um growth uh 16 circuit produces like very tiny uh very little proof which is like snar proof. So

so there are like few layers of proving. So we have initially we run uh proofs to generate this uh six receipts using risk five right so and we also um use fry for those proofs so fry is a proof system that's uh uh very efficient for the uh recion and then we do uh recussion uh so we aggregate those uh receipts into a single receipt um all those like stark receipt into single receipt and then we use uh uh growth 16 circuit to generate a very small proof.

So every every recursive uh recussion uh circuit takes 250 uh star kilobyte stark receipt. So since it takes two receipts, it means that it has um it takes uh half a megabyte and then produces one single um one single 250 kilobyte receipt and our snark receipt is a 100 bytes. So it's quite a difference and um uh we so that's uh that's how we we generate this um uh this uh um this snark receipt. So also want to come back uh to the uh

recion uh that uh we use one second. So um we so here here you see that uh we uh we use we split our execution trace into several uh segments and we prove each of these segments right. So uh because of the um this continuations uh that are available now uh we how we do it we actually prove that each of these segments uh in parallel. So rather than proving uh generate uh zk stark proof for billion cycles of uh like of a large program, we get proof um uh for each of these segments and then

we input these proofs into recussion and uh in order to compress those proofs we use uh uh growth um uh growth 16 circuit to for single um for single rece to generate a single snark circuit. So if you want to learn a bit more about our proof um uh um about our proof systems and considerations that uh drove our um ZK researchers and the architecture decisions, I would highly recommend you watching Paul's presentation on approved systems. So you can find it here and I

will post it in the chat and uh yeah so this is in depth in depth um discussion around our proof systems around decentralization and how this uh can be scaled uh horizontally and uh how how long will it take to compute each proof. move and um yeah so I think there's one receipt is uh one uh receipt is missing so um there's supposed to be another another socket uh recursion socket here and then it generates receipt goes into this uh recursive socket so uh but do please watch

presentation so and um yeah we um now we'll move to example walk through all factors. But let me check first uh the questions to make sure that we are [Music] Hey Arena, I'm also going to jump up. We have a ton of questions over in the Q&A. I know some of your colleagues have been already answering them. So for you who've asked questions, you might want to just check the question and see if there's an answer. Um, do you want to take some of those questions?

Oh no. And the only reason I'm mentioning this is we have to be a little bit conscious on time because we had questions early on. We're thinking maybe we shouldn't take the break and instead we just kind of continue through. Okay. Yeah. Yeah. Okay. Yeah, let's do that. How do you want to do you want to do some of these questions? Is there anything in particular? Mhm. So there are uh there are some questions that um I think um I already replied so they already been answered. So yeah I will keep it then I will go through through the workshop to make sure that we are on time because that's good.

Yeah. Very cool. I want to make sure we we cover all the materials. Thanks. Thanks Anna. No problem. So let's go through our factors example and let's um make sure that you can see it. So here we have two uh two uh two codes. One is the guest guest uh program. This is what you want to run on ZKVM and the host. This is like prover on the host that um that will will be sending your input data to the prover and will actually run the proof.

So uh on this uh this program we um this is a factors program. So what what we actually doing we send two the two um two integers to the uh guest as a input data and then we run the prover. generate uh we generate the uh receipt and uh we get the receipt back from the from the prover and uh we are we print we print the number output from this journal and uh when when we run the prover we actually go into uh into this

um method guest program and here we read two integers uh this is a and uh and then we multiply it and we commit the product. So and this is product this is what we commit to the journal. So let's look closely into the guest program. So first of all we when when you write a program a guest program you need to import functions that uh need to be uh for iterating with the host environment. So this is done through risk zero zkVM guest environmental variable and then we have we need to read the objects from the host we need to read the data and then we need to also commit uh

through this environmental uh guest environment to the journal we we commit product that we computed and so please note that whatever you commit to the journal is a public. So be careful what information you want to commit. And then on the on the pro on the host side on the prover you pick like two random numbers. Then you set up the execute environment and this executive environment holds configuration details uh that uh inform how the guest environment is set up pro the guest code execution. So this is

where you also send your uh your input data for the program. Then you obtain default prover and prove the elf binary and return a receipt through running approver proof elf. And then this is where you actually run this uh guest program and then you obtain the output from the journal through receipt journal and then you can print the output and also uh verify the integrity of this receipt with a image ID.

So, uh this is this is how we uh this is how we um uh this is how the whole uh this is uh the whole ZKVM works. You just in the uh guest program you have the guest. This is uh the program that you will will be run on DKVM and the prover that uh will be uh will get the will be sending the data to your guest and the junior and will run your uh guest uh program through the prover and then you can can get back receipt um and receipt contain journal.

This is your public output. So since we are a bit um a bit uh running out of time, I will uh so let me know if you want to uh have like quick start with ZKVM and uh otherwise we we go quickly to uh to the bonsai and start our uh presentation about bonsai. [Music] Good.

Thank you. You doing this one or is this where we're bringing up your colleague? So, I will I will give a bit of like overview of bonsai and then this is where my colleague will uh will get on stage. So um but since we're a bit like running out of time, I want to make sure that we go through whole materials and uh if uh so can can people say if they would be interested to run ZKVM generate a project and run it locally? I think there's a few people that are one other thing Arena if you wanted you can always we can always uh have you jump back like for us the only sort of

cut off is at the 55 mark so that we can announce the puzzle but afterwards if you wanted to jump back on and sort of do any additional stuff you're welcome to do that. Okay. Okay. Let let me then go quickly through this uh ZKVM like quick start. Okay. and uh go to bonsai and then I'm just like h you're going to have a bit less time to present. Okay. So so guys uh come please here on this uh on this uh dev risk zero API zvm quick start and I will share my different page with the quick start. This is what you get

when you run it. And let me just reshare it. [Music] I'll shut the whole window [Music] so you can see. All right. So when you when you when you scan this code, this is where you get right. So this is quick start. I will also copy

and paste it in the in the chat. So um this is a very easy and very fast way to uh get start with uh risk zero. So let's uh first uh start uh start with installing risk zero tool chain open also tool chain. So just copy like cargo install cargo install and uh then

oops sorry and then let's uh do cargo be install cargo risk zero Okay, it's easier to copy. So, you have some warnings which is fine. And then uh cargo reser install. So but before that please make sure that

you have installed Rust on your computer. There is a link here that let you to uh that uh goes directly to the rest. Um and then let's uh create a new project. So to create new project we use our uh risk zero tool and we need to pass um basically two names. One is the new project uh name of the project and another guest name. Guess name is a name of this program that you're running.

[Music] So let me copy this and run it here. Mhm. So this uh cargo risk zero now create created a template for us created a project template for us. So if you check als you have this my project that's been created. So I'll go inside my project and uh um create a couple of directories

and methods and it's already a granable. So if you go through this uh tutorial uh you can see that how the share um uh how you share data between host and guest. This is what we just like showed you how the host approver. So uh send the data to the guest and how guest read it and then how guest shares the results and generates receipt. So in order to do this, let's see how our uh project.

So this is the project that we just created. So we have host and this is uh uh host has so this template by default has like one parameter one uh integer that's been sent through execute environment to the guest and then this is a prover that we obtain and then we run uh prover runs uh uh proves and validates the computations uh guest computations and let's look at the guest guest. So here guest we have this is the guest in methods guest source main and uh

so this is like very simple to make sure that you guys all like running it. So it get it get back uh it commits back the same data and if you open on the main again the output is here it reads receipt journal and then you can verify and you can also run it. So let's let's print one line to make sure that we actually run it correctly that it's it's actually the data. So so output

from this save it. Don't forget to save it and then let's see how we can um how we can run it. So we run it through this uh cargo run release and we set developer mode to one. So this means that during the during the development of your um of your program, we recommend first to start with de developer mode. So it doesn't take quite a lot of time to actually to actually um uh generate zero

knowledge proof each time. It just it's it sends like dummy receipt. But then when you're actually ready when you run the test everything all your Rust is ready R code then set riskdef to one and you just see that uh it it takes it longer to run. So I will do so I will do in developer mode. Then you can see that for real proof generation just takes uh you just set this environment variable to one to

zero. So, it's like almost ready, almost done.

How are you guys doing? Does any of you have any uh problems while running this? Um, this program [Music] so the mode one is actually just making sure that the actual ZK snar snark uh proof is not generated. So it's it runs the program it's it's it but it doesn't generate this proof. So every time so this is good during like development right. So uh when you ready to run your

uh when you actually ready to run your rust code when you actually ready to generate um uh receipt to generate a proof then you set the mode to zero and you start it will just like take a bit longer to generate the proof. So that's why uh for this uh for this uh demo I'm running with developer mode and it's already a bit slows. I'm sorry. Usually it's like my laptop is a bit slow. So um while it's running, let's go and start uh start go uh let's go and look through uh Bonsai and then and then come back and check.

So, actually, Arena, just one quick, I just want to update you behind the scenes. We've made the decision that um you have like another four minutes and then we're going to take a break, do our launch of Puzzle F2 and then Hunts is going to come on after. Okay. You okay with that? Yes. Yes. I'm just because it's four minutes. It just I I think it would be too short and we really don't mind after. We just want to stick to the time in our schedule of the launch. Okay. Okay. Yeah, thanks. Perfect. Okay. So, I'll be back in about four minutes.

Okay. So, so what happen if you if you don't want to run uh ZKVM locally? This is one of the questions that people ask. Um so is there remote option? And yes, there is one. There is a bonsai. Bonsai is ZK proven as a service. So this is um where you just like send your uh your guest program to the service and it generates it for you and it's validated for you and generate is your knowledge proof for you. So we provide the whole infrastructure and this is ideal for like very heavy computations and for very fast proving. So and thanksfully to continuations that we have now we can uh provide these uh

these services. So you can play with it uh locally but it doesn't it doesn't generate the proofs. If you really want to do uh to run generate the proofs please uh use this QR code and please apply for bonsai API keys and the kind of the most exciting part that you can also uh do of chain computations. So let's look the bonsai architecture. So there is a two ways of uh calling bonsai. So what with bonsai you do you just like send your rust code that you want to run on bonsai. You don't need to worry about host anymore. So with this bonsai or you can send request uh

offchain. So how you do it? You send a request to uh bonsai relay rest api. So this is uh through offchain. This is through here. All you do you you can call uh request call back on bonsai relay contract through your user contract through your um ethereum contract or any contract. So bonsai relay uh what it does it sends the proof request to the bonsai proving service and uh we run the uh program off chain and then we prove that uh your code was executed and we generate the proof we generate like snark proof and we send it

back to to bonsai relay contract. So um bonai relay contracts verify the receipt and um then extracts uh journal from verify receipt and then send journal image ID in a call back to your application contract and um yeah so what's possible after you'll hear Hans presenting bonsai pay and that's it from me for now. Yeah, I'll share my screen. Um, and then we'll just go over pretty quickly. Uh, you know, generally this is kind of focused on like how you go about thinking about zero knowledge applications in a general

purpose sort of manner. Um, so before like you know you need to write circuits. It's kind of complex. It's it's not a trivial process and it really limits uh like what you can actually write uh with your programs. Um but now that we have this general purpose VM that can you know have verifiable computation just about anywhere you know you really unlock this whole world of of application development and uh ways to sort of incorporate zero knowledge into generalized programs whether it's onchain or offchain. So today we're just going to kind of talk about like the sort of theory that you should go about thinking about how to apply ZK to existing problems. And we're going to go

over a specific problem that we solved and demoed with this application called Bonsai Pay. So zero applications, yep, many applications could benefit from zero knowledge for privacy, security, interoperability. We all know that. That's why we're here. Um they're really useful when zero knowledge is really useful when you just want to minimize trust, right? You have verifiable computation. You can write programs that are verifiable anywhere. So you can run it on sort of a trustless setup. Uh any machine that's that's sort of executing this binary, these ELF binaries is, you know, it's a trustless machine. You don't have to trust it. And general purpose zero knowledge sort of enables novel application development. And we'll see that in a second. So wait till the end to see a demo. Uh and we'll just go

through a quick video demo. But I'm just going to go over some some highle theory. And we're going to start with probably the most boring and uh annoying topic for a lot of developers and that is like authentication. Uh it's sort of a meme at this point that authentication is difficult. It's a pain in the butt. Um and it's really easy to screw up and that's still the case. This actually doesn't solve anything. Zero knowledge does not intrinsically imply sort of security or privacy, right? like you have to think about these things very carefully and you have to think about your problem sets very carefully in order to develop any sort of reasonable pro program in a secure way right so let's talk about OOTH 2 and open ID so what is OOTH 2 oath 2 is sort of the

pattern that you see on the internet widely used in web 2 to log in right sign in with Google sign in with Apple etc but there's another layer on top of OOTH 2 that a lot of applications have sort of centered around and that's this idea of Open ID connect. Open ID is is a this this sort of protocol that exists on open o on OOTH 2. Uh basically it defines a set of fields that allow uh providers to sort of provide identity or other sort of information in a compact and succinct form that is verifiable using public key cryptography. So this is you know uh you see this all the time whether it's sign in with Google or

Microsoft or Apple or Amazon or Twitch or whatever. A lot of people incorporate open ID on top of OOTH. Uh it enables clients to verify the identity. Uh so essentially you get a payload from like Amazon or Apple or Google and they sign this little payload. uh and you can verify that by looking at their public keys. So they they hold a secret key, they sign some payload, send it over to a web application or some other application and you can verify that and you know that's really cool and stuff.

So typically this flow looks like sign in with Google. It makes a request to you know Google. Uh we get back an access code. This is why it's so easy to screw up. There's a lot of steps here but you make a request to Google. You get back an access code. You make another post request to Google and you say, "Hey, I want some sort of token. I want I want to to get that identity of the person that just signed in." So you make another post request and then you get back this horrible looking string, but really this is just an encoded sort of payload with a signature. So we see three different color sections in this large payload. First section is the header. Second section is the actual payload and the third se

section is the signature that you can use to verify and this generally just kind of looks like this. Uh so you have this like signature in this case it's RS 256 signature. So RSA not going to talk about RSA or you know the pros and cons of it or the security implications of the internet relying on RSA. That's for another time. Uh it just exists and it's the backbone of the internet. And then you get this payload in the green that sort of corresponds to this encoded payload. That's really cool. Uh that's that's great and all. Um thanks for showing me all that's really useful. This is a ZK hack. But what can we do with that? So now that we have this general purpose machine, is there anything that we can actually do to use

login and traditional authentication protocols and enable that with ZK in maybe like onchain applications or other sort of verifiable computation sort of processes that you need? Well, yeah. Um, it matters because it's well established, right? enabling traditional O on onchain would be a huge UX improvement and you know turns out uh we can thanks to this awesome paper that was just put out last year called open pub key it's called augmenting open ID connect with user held signin keys so some very clever people were like hey what if we just like put a user sign a user signable key inside of this payload then that sort of tightly couples these

two things and you know we thought well user Signing keys are basically Ethereum, right? Like you have a public key and then you have your private key and you can do things with that, right? So what if instead of using this like sort of, you know, very uh niche kind of public signing key and we actually just used Ethereum addresses with that. So what do we do? We we kind of hack open ID connect in a way. Uh oh, I'm getting some stuff. Uh 10 and 10. Sorry, I'm getting a cool. Yeah. Uh cool. We do this technique called nuns hacking and

packing or that's the term that I like to use. Why do we call it that? Well, if we take a look I just did that. If we take a look at the previous slides, we can see that we make these requests to like Google or Amazon, right? But there's this field in here called a nuns, which is really a number only used once, right? We're only supposed to use it once. The the server that's that's you know serving the authentication should be checking these nonses and make sure that like that nuns is being isn't being reused within the same sort of session. So process looks very similar except in these requests we sort of provide a custom nuns. In this case, we decided

to go with the public key of your Ethereum account. So, you can see this Ethereum address in yellow, the nuns, and we make these requests. So, we get the access code back. We make another post request and we get this JWT. This is a JSON web token, that long string of text, the the header, payload, and signature. And it contains the nuns that we asked for. So this is really cool because it tightly couples their public key cryptography based on RSA or LCDSA other sort of signature schemes and it contains something that we ask for in this case a public key which is your public key that you can go and sign messages with or make transactions uh on a blockchain with.

And that's really important because it tightly couples these these two systems this web two world and this web 3. And that's really cool. That's really great and all. Um, but it's not that useful for blockchains yet. So, what do we do? Well, we validate this JSON web token inside of the ZKVM, which sounds like it should be a, you know, hugely complex thing because, you know, you'd have to write a custom RSA circuit and all of that, but not with risk zero because it's a generalized system. So we can use existing sort of tools and libraries to validate a JSON web token which is standard practice in most authentication right validating JSON web tokens is is is the bread and butter of of the internet. Uh and we can do that inside

of the ZKVM with fairly trivial code. Uh so like I said we validate the integrity of the JWT against the public providers or the private provers public keys and that looks like this. So we have this JSON web token, right? This this long string of horrible text that nobody likes to. Then we have some public keys that that Google or Amazon or Apple, they have on a well-known endpoint, right? They have these certificates, these signing certificates that they use to sign these these JWTs, meaning that they they have attested to the validity of that payload. And we just pass that in to the ZKVM. So we can see here with

the little elf. Uh this is this would like correspond to what's inside of an elf binary that is passed to the ZKVM. And we run this on the bonsai proving service to expedite that process of proving. And we get back this awesome uh little receipt contains the seal contains the digest of the actual uh payload itself and contains the journal and whatever we choose to write out. We choose to write out nuns. You should probably also write out the expiration and issue date because you can't do that inside of the VM. It's a it's a virtual machine and you know you'd have to trust the host if you want this sort of system clock. So you just don't do that. So you write it out for other people to check.

But the important part is we pass out that nuns in the journal. That's public. And once again this tightly couples these two systems. You say oh great Hans you have a you have a seal now you have a receipt. Well that's cool. But like we mentioned earlier, you can validate this onchain. So we can do snark validation on chain. So we have this we have this receipt, we throw it into a smart contract and we use a verifier contract, a groth 16 verifier contract and we just verify the payload that is signed. we verify this uh this seal that contains the proof of

the validity of the JSON web token from the authentication protocol that we've logged in with. So we've we've essentially tied web 2 and web 3 together and enabled onchain transactions to to correspond to a given user who's logged in by tightly coupling these security models. Pass that into a groth 16 verifier. Oh, it's so good. Uh, we can now do things onchain using web two. That's crazy. Uh, the potential for UX improvement here is massive. Whether it's smart contract wallets, identity verification, access control, etc. Uh, these are all we have the it's possible now. We can do

it. It's the the problem is solved. Thank you. Risk zero. So here is like some horrible looking ex uh horrible looking sort of sequence diagram of what you would do. You'd have this application. You sign in blah blah blah get the token validate the JWT get the proof back send it to Athereum. Cool. We've enabled traditional web authentication on blockchains. That's that's kind of that's kind of a big deal. Um uh we've tightly coupled the identity of the person by using their Ethereum address inside of that nuns. We've tightly coupled that to the identity from the identity provider and we've essentially unlocked

trustlessly ver verifiable authentication on blockchains. Like I was saying, it's a relatively simple architecture to actually implement and we can see that um with the demo at the end of this slide, but like I said, this enables a whole lot of things in blockchains, right? Traditional and familiar login methods for DAPs. Uh that's a huge one. If we want sort of UX improvements, which the blockchain world so desperately needs, uh this is this is probably a very viable path of doing that. So it works well with payments, wallets, account abstraction if that's ever really adopted.

Uh you can do things like smart contract access control, right? Like sometimes you'll write a method in a smart contract that you say, "Oh, only the owner can do this or only certain roles can do this." Well, now you can have a new access control method where it's says only people that are logged in with Google can do this or only people with this email address can do this or this domain can do this or this issuer can do this. It's also very important for identity verification. If you think of identity platforms, traditional identity platforms for KYC or something like they still follow this pattern. In fact, there's open ID providers that that follow this pattern where we can sort of nuns pack and maybe make uh say an identity NFT, right?

So, there's tons of applications that we can do here. So, with with all of this, you know, what does this actually look like? Well, it looks like a traditional web application or DAP uh where you connect your wallet and you perform some action onchain using this proof. So, what does this look like? Let's just watch quick video of Bonsai Pay. It was a demo that we released a few months ago uh prior to Istanbul. Uh it is now offline but uh the repo is still available at github.comriszeroamples. You should be able to go fork that repo if you want. Uh keep in mind that there are still security implications about this, right? Like you need to carefully consider authentication and security when you do this. But for the most part, it looks like this.

So we have this application. It exists on a website. You go connect your wallet. Pretty standard. And then you have this field and you say, "Hey, I want to send money to say somebody else, somebody with this email address." In this case, it's myself. Pay attention to the connected wallet address. I'm going to send some ETH to them. And this is going to send Sam to an escrow contract that only Hans MRTN atgmail will be able to claim if he logs in. So now I go I've sent this this ETH uh any second now.

And we come back as you know Alice or something some other user and I and Alice has this this email hans martingmail.com goes and signs in. Looks pretty standard. You sign in with Google. Hey welcome Hans Martin. Let's prove that you actually own that identity connected to that wallet. So now we're proving it. In reality, it takes a bit longer. It's about 10 million cycles. So that was sped up a little bit. But now we can use that proof to actually claim this ETH off of this contract. Only identified by that by that email address, right? So only the person that can log in with that email address can claim this ETH.

And that's generally what it looks like. So once again, this kind of opens up tons of possibilities for application development. Uh you're no longer restricted by the engineering requirements or developer talent that you have to write complicated circuits for say RSA. I'm not sure if you'd even want to do that. Uh but you can. And it it's this new world of sort of generalizable ZK that just is immensely powerful in in the broad space of things. So, we're excited to to see what, you know, developers and people alike sort of use ZK systems for because it's so generalizable. Uh, you know, there's so many novel applications that we can't even think of. Um, but that's what I'd like to leave you with. Check

out the repos, check out the docs, check out the reads. Uh, there's a ton of helpful info in info in there. Hit us up on Discord. Um, we're there. Awesome. And it was a pleasure. Very cool. Thank you, Hans. I think this event is about to shut down. So, I wanted to just make sure that we get to say thank you. Thank you to the whole risk zero team for coming out. What a great workshop. Thanks to everyone on the questions. I know there's someone who's work like trying to work with some of one of your tools is asking for some help in the chat. And by the way, for anyone in the chat, if you have further questions, head over to the ZKHack Discord. There's a Zika hack channel.

There will be a lot of chatter around puzzles and stuff, but I'm sure there's going to be some risk zero folks over there too who can direct you to the right channels. So yeah, thanks everybody for coming out. CK Hack 4 session two, it's a wrap. Cheers.