Zig SNARKification

Transcript

Yeah. So, uh, Gageer and I are working on um on the Zim client, which is a Zig Zigg beam client. Yeah. Thanks for making it, Gageender. It was quite uh quite difficult indeed. Um, and so as part of this work, there are basically two components. uh you have the client that with the network connection you know producing block downloading blocks and you also have the proving side which is about running a guest uh sorry a guest uh sorry a guest client inside the EVM uh and this uh we've wrote our own uh guest program and this is what I'm going to talk about during this this presentation uh as a disclaimer I had a presentation about this a very similar

topic at protocolberg two two weeks ago So, uh, I learned that the video was published yesterday. So, if you if you watched it, there's going to be a bit of a, you know, redundancy, but there's still there's still some some new stuff. Um, so yeah, what is the guest program u? Well, the structure is very simple. You have the if you want the business logic, the state transition function. Uh, and you have the runtime, which is where I guess the most interesting part of this talk will will be about. And then you have the ZKVM which is the one thing that executes the program and will uh you know take samples uh build a polomial or do all the fancy proving

stuff. Um but yeah like the the biggest challenge is to build a state transition pro function program as an elf that runs into the ZKVM. And what you have to understand is that those ekvms except re zero I love what you guys are doing uh is very much like an embedded target which means that many languages will not be able to to really work into this uh unless they have some kind of Linux emulation layer. Once again good job resero um and uh yeah so you have to basically emulate the OS and the lip C. Uh and this is what the runtime is doing.

So uh in order to build a guest program you you you only have or you really have two options. Either you take the stock SDK that is provided to you by the Zikvm which is typically written in Rust and you also have the Rust runtime. If you want to use a different language like Zigg, uh you can build your own uh STF but still somehow linked to the uh to the Rust runtime which is uh which can be challenging especially when it's not really available. Uh so sorry for saying that again but ReZero does it right. Uh everybody else that I interacted with does not. Um so so yeah basically uh if you want to use a different language

right now your only option is to also rewrite the runtime and this is what we did. Um I think for the short term or at least we see our mission also to to evaluate how good those ZKVMs really are in terms of programmer programmer experience. So for us it's a no-brainer. We have to to do the z runtime. We have more control. uh we also have a more streamlined process where we just write an independent STF and then uh we have code spec sorry EKVM specific code but uh yeah that's that's the the burden we're taking and the role uh the reason why we bother with all this is uh to provide I mean there's many reasons really but I would say the most

consensual one is uh is runtime diversity we want to uh show if we're proving a runtime like a single runtime and there are bugs in it, you're proving the bugs. So, being able to to find issues and we are finding a lot of issues. Um, it's quite it's quite useful to yeah to to take a slightly different path to to get there. Um, so I'm going to go very summarize the the program flow. Um, and know we have once again the state transition function which is code that we don't that we write once.

And then we have this ZKVM specific code in yellow. Um, which is like I said the the interesting part of having of having this. We don't have to write an abstraction layer. We just have our specific code. We swap it and uh and we we can build many programs in one go. Um, so yeah, the idea is that the program starts in the boot code. It does the initialization. It gets to the state transition function. Then it gets the input which typically will be a block that you want to prove and the state and things like this. Uh goes back to the state transition function. Does a lot of sys calls like hashing for example or committing to values and then does more thing in the in the state transition

function. And finally I should have said halt instead of exit. It calls the last system call and the program terminates. Um what do we cover so far? So that's one of the things that is different from protocol. Um we have re zero support. We are able to prove everything end to end. Um in protocolberg I used to have CO uh we decided to drop it because it's just not production ready at this time. Uh so we have the code saved for when uh when they they have uh something um functional, but currently it's just not worth our time. Um we have powder. Um, we have the the guest program, we have the the prover. Uh, there's a lot of

issues with the verifier. So, I started working on fixing this in powder and powder announced that they were discontinuing their risk by VM. So, this line is going to drop very soon. Um, and then we started looking into ZISK. uh and the interest of ZISK I mean we're especially interested in ZISK because it's a risk 564 target which uh is also I'm also looking into building GU uh for for a ZKVM target. So um so it's quite interesting to have a risk 564 target because GU will not compile to a risk 32 target.

Um SP1 we also started but communication is a bit slow there. So uh currently it's on the kind of the back burner and then we have uh the three remaining um ZKVMs we want to look at uh OpenVM uh simply because we hope we can reuse some of the powder code to to put it in there. So powder wants to become integrated into ZKVMs sorry into open VM. So hopefully the the work will be will be fast on this front. And then there's ZK myths. The only reason is also because it's not it's a new architecture. Uh and I'm also in the back of my mind I have how am I going to compile G for as a guest client. So that's also a way to investigate this.

And then uh there's um powder is um is maintaining their wasm uh their wasm uh VM. So we want to to look into this uh afterwards. Um yeah. So I was saying um when we want to build the the ZKVM so we we build all the guest programs in one go and here you can see u maybe if I explain here um we have some rust glue and I'm going to explain what this is later but uh we we first build the the rust glue to connect to the ZKVM. So here we have powder and uh and rezero and then we build the the ZKVM the guest program. So we we build

them all in one go and it's all u it's all the the same state transition function. We just change the the tiny the tiny glue that uh that is there to to connect to the ZKVM. So we can uh we can basically have a future where we have a multi-rover. We receive one block. We do all the proving with all the the ZKVMs and then uh we can produce those those blocks. Um yeah. So, how do like what does the client look like? Well, uh I I forgot the legend again. In in yellow, you've got you've got what's written in ZigG and in orange you've got what's written in Rust. And so, you have the classic client code. So, the networking, the

state management, you receive the block, you do the tree uh computation, the hashing, everything. And then when you need to do the proving you have to go through a rust glue into the the ZKVM prover that will kickstart the runtime execute the state transition function come back with the proof. This goes over the network and then it comes back in another client into uh over the rose glue to the to the verifier and I think um what would really improve is if we could come up with a standard interface.

So we had a a discussion about this at the interop in Berlin two weeks ago. Um yeah basic basically the writing this this glue um and the runtime is a lot of uh duplicated code and in the case of rust it's even worse because rust is a compiler I mean so is zig to be fair but uh uh we don't have this problem directly but when we have to build some rust glue each zkvm has their requirement for a version of the compiler so currently we're quite fine but I assume that when we start supporting provers in many many ZKVMs, we're going to have an issue of compiling every glue bit with a

different version of the compiler. So, this is something that would be extremely useful to to have verification libs that are either in C or go uh or Java, why not? uh so that every client could just uh not have this problem of building some rose blue uh with many different uh compilers. Uh otherwise yeah what zero did provide a runtime loop that you can link into a C program would be awesome and um and yeah that's uh that's pretty much it. Um, so yeah, I don't have any uh numbers yet because it makes no s like we don't really have a spec uh a finalized spec. So we, you

know, we didn't really um we didn't really uh want to benchmark to the the execution itself. It makes no sense because we we don't know what we're we're doing in terms of business logic. Um but yeah, for example, from powder, it takes about four seconds to to uh do um like just update the state and and recomputee the the tree. So if you're uh if you're interested in numbers, I can always uh run the program and tell you how much it takes. But this is not uh I think this is not the right time to to provide the numbers. Um yeah, that's pretty much it.

[Applause] How complex is the runtime? Um, the runtime is I mean conceptually very simple. Uh, in principle it's like the devil is in the details. Excuse me. So, uh, what's complex is figuring out what the ZKVM does under the hood. So you have to go and read the code, the Rust code and realize, oh, this VM does it this way, but this other VM does it the other way. Um, yeah. So the the runtime itself is not complex.

It's just maintaining multiple versions of it. Okay, lunch time. [Applause]