Migrating from a zkEVM to zkVM | Jan Gorzny | ETHWarsaw [4]

So hello everyone. My name is Yan. I'm a co-founder and technical lead at Zirket. And I'm proud to be talking to you about talking about how we migrated from a ZKVM. So an Ethereum virtual machine to a zero knowledge virtual machine without the E.

I think I said that right. Um so we don't want specialized circuits and I'm going to talk about this. Now I promised in my talk that it would be uh friendly to people who don't know what's going on and um to technical people near the end. I'm going to try to stay true to that mission in um the 30 minutes that I have. I see that's actually 25 minutes.

So, this might be a little fast, but let's get into it and see what happens. So, first the background. What's a zero knowledge proof? If you don't know, um I don't want this topic to be relegated only to side rooms and people not talking about on the main stage. So, I thought I'd reintroduce it very quickly.

A zero knowledge proof system is a way that a prover someone proving that they have some knowledge can convince someone a verifier that they have that knowledge without revealing of any of that knowledge. And this is some nice fancy math that's been around for a while but it's seen recent adoption in part due to web 3 large part. And if you don't understand what the proverifier is actually trying to do it's generating some math to convince someone doesn't matter. the real takeaways at this bottom slide bottom of the slide which is I know a valid input to a computation and the output and I can prove to you that I definitely computed it correctly. So I executed the thing that I want to do correctly and why do we care about this?

Well uh we'll use it for zero knowledge proofs and we're also going to be talking about snark. Sorry I have to introduce this very very quickly. If you do hear me talking about a zk snark zk snark is just a zero knowledge um argument of let me slow down and go to the slides. So a zik snark is just um something a proof system by which it's zero knowledge. So the person proving actually doesn't share any knowledge doesn't leak the secret that they were supposed to have.

It's succinct and this is very important. Um the proof is small. It's not interactive in the sense that the prover can give the proof to someone and then walk away. They can leave the stage. They can stop talking to a blockchain.

They can just leave. There's other definitions I'm sure um that they know something that they have an argument of knowledge that they know something. And what we're really going to care about here is succinct and non-interactive. Right? So we want a small proof.

It's always been sort of very important to get scaling to work uh on uh Ethereum and non-interactive so that we can generate a proof and not have to sort of argue with the person back and forth that we do know something and in fact most of the time we won't care about the zero knowledge we won't actually keep anything private. Zirket does not keep anything private and through all this math um to get the succinctness and non-interactive properties that we want as well as the others that we don't care about as much perhaps um we have to do some stuff and this usually introduces an overhead. A lot of the first um problems we have is that you need to redefine your computation or the thing you're trying to prove in a very specific domain specific language. So you suddenly have a huge bottleneck for developers to actually go and build out a system to do the thing that they want to do to prove to other people that they know some knowledge. They have to be very specialized.

They need to learn, you know, some part of the math. Maybe not all of it. Maybe some of it's in a math paper. Some of it is a little bit easier to understand, but they have to do something very extra. The upside is the tooling around this has gotten better over the years and at least they don't have to do all of it by themselves.

There's, you know, tooling that will give you the verifier code, for example, to do this as well, often in Solidity, which is very nice. Uh, even if they do all that though, you're probably going to need different hardware to run it, or at least uh it might not be the hardware that you expect. The requirements have gone down since a slide like this first appeared on one of my decks. But, um, you know, there's generally a barrier to getting these things to run in a very short period of time. And so you have hardware requirements going up or costs going up and this is also a problem.

And we can't necessarily solve both of these problems. But we can certainly talk about solving the first one by using a general purpose zero knowledge virtual machine. And that's what we're going to do. And to convince you that this is a worthwhile example, this is a sample I think from the Fibonacci circuit in Halo 2, which is the proof system that up until last week um Zirket was using to prove execution of of Ethereum blocks. And uh I don't really know what it's doing here.

at setting up some columns. There's a whole bunch. It's so big that I can't fit it on the slide. I don't think that's a surprise. Um, a lot of code can't fit on slides, but there there's a lot of verbosity in these domain specific languages.

And there's sort of a a way to think about your programs in these languages that becomes problematic. You need to start thinking about things as chips or circuits. You need to get them to sort of compile and be configured in nice ways. And that's not something that the average programmer might know how to do uh very easily. And then you have to, you know, define all these things of the constraints value to zero.

And you're doing this all over finite fields rather than the integers. And maybe you don't even know Rust. That's a whole another story. We can't really fix that one. Uh but it's a very difficult process.

And it's very very difficult if you're developing a complex system like uh a rollup or an Ethereum client. And so getting away from something that this ver that is this ver verbose into something that's simpler is going to benefit everyone. And if you do have to go down this route, what you do, and I'm showing this here because I'm going to change this image as we go through the talk, you have a program that you need to rewrite generally just once into this domain specific language version of it. Um, it'll generate a verifier for you. Typically, you only need to do that once and then you feed it inputs.

You execute the DSL version of the program as much as you want. Every time you do that, you get a proof that you can verify. So, this is fairly straightforward, but a lot of those arrows are hard to do, right? in particular, the rewrite stage is very very annoying for most people. Um, and then if you do that, the computation lift goes up.

As I said, it can be as high as 10,000x. This is old news, I think, but I still want to say it so that people know why we care about trying to optimize these things. Um, the complexity is very difficult. Then how do you be sure that you actually wrote it correctly? Because if it's that verbose, there's probably room for errors, there's probably bugs, and then it depends on the prover that you're using.

There's a whole bunch of things. You may also have to do other cryptographic things to get your system to work like a trusted setup where you go talk to people and get them to contribute randomness and hope that they throw it away. Um, and you should do it yourself, all of that. So, there's a lot of lot of challenges to getting ZK off the ground and it'd be really nice if we didn't have to do all of this in isolation. Why do I specifically care about this?

cuz I'm trying to build a zero knowledge rollup and while zirket has been existing for on mainet for a year u we also saw that that all of that maintenance to maintain that zero knowledge system was really painful it was kind of annoyance so we're a rollup so we're a layer 2 we're a blockchain we produce blocks that we get you know from transactions which either are deposits or from other people using our network directly we build some blocks and then we try to prove that we did not cheat right that that block was created in accordance with the execution engine we're using which we would really like to be the same as Ethereum because we're trying to make Ethereum go faster. And so the picture sort of looks like this. You get some transactions, you build some blocks, you prove it, and then you verify it. It's a little bit misleading because there's probably supposed to be an arrow from the batches back to the the prover so that the provers actually read from the D uh the layer one and prove the right blocks, not just some blocks. But then a smart contract says, okay, the proof is done and now the layer 2 sort of has all the nice properties you want.

Um, in general when anyone does this, uh, we don't usually care about zero knowledge. There are some privacy chains out there that are doing great work and they do care about that zero knowledge. We do not, so I will ignore that for the rest of the talk. Um, but the main challenge with this approach is getting that GE or Ethereum client, whatever you're using to actually be the thing proved. Um, so that's rather rather difficult.

But it's not just that, you also need to make sure that deposit transactions are read. So the state transition function of you building a new rollup actually is more than just GU. It's making sure that you didn't ignore deposits so that people are using your chain in the entirely correct complete way. But if you get all that once you verify our proof on chain within a single transaction, you don't need to wait days, right? You can get it right away.

So this is where we use zero knowledge in roll-ups. And if we go back to the picture, it sort of looks like this. So I take this EVM. This is oversimplified and not technically correct, but it gets the idea. I had to rewrite that into a ZK EVM.

So I had to do all that big verbose zero knowledge proof rewriting for a very complicated piece of software namely one that operates Ethereum and then every time I get some blocks maybe I'll call that a batch of blocks maybe it'll be a single block maybe it's a transaction depends how you want to prove things I shove it into my ZKVM and I get a proof and I verify it and things go very very well and so that doesn't sound so bad and if I've done all this work why do I care about switching now right seemed like it was a real pain to build out the code so why do Do I care? Well, some parts of me don't care. I think it's actually really nice. I have complete control over my circuits. I can optimize them, right?

I can do very, very cool things with GPUs and custom data valuations and Halo 2 in order to really get the maximum performance out of these systems. Uh, I think that's something that's very exciting and we have cryptographers on staff who are really excited to do that type of work. It's work that I don't necessarily understand anymore, but it's uh stuff that really pushes the limits of what both the hardware and the software is capable of doing. So, that's really nice, but unfortunately the downsides are really really bad. Um the upside get you a little bit more performance.

The downside is you need a lot more um staff and that's really really problematic because when you start to go to change these circuits there's always a need to make sure you didn't break soundness or that they're still optimized or that they're still doing what you want and you have to sort of change things all over again. And then if you do all that as I mentioned there's no way or very few ways to detect um bugs or to check correctness. Formal verification is catching up but it's still slow. um especially when people were using different proof systems, you know, maybe your proof system didn't have the right tooling, but you were already sort of locked in or you didn't want to change. Nonetheless, there's there's challenges.

And then, you know, how do you actually optimize it? It it can be done, but it is is challenging. And then if you care about privacy, you got to make sure you didn't accidentally leak some knowledge, right? So, on a rollup, that wasn't too concerning for us, but it is a concern in general. And it's a real concern uh over the last so many years in the space, right?

the execution engine of Ethereum has updated. It will continue to update for Saka. Will hopefully come sometime later this year uh you know maybe by Dev Connect in Argentina. But the last one that we were really annoyed with um was uh Osaka. No, Prague.

Yeah, one of these uh Cancun introduced op codes. When we went live, we didn't have support for those up codes. We had to change it. And then Prague went live. We didn't have support right away.

We were like a week behind it. But the amount of effort to get the engineers to support these op codes was through the roof. Like several of them for several weeks or several months depending on the specific allocations. and to to allocate that many resources just to say that we're EVM equivalent or EVM compatible um which is perhaps more accurate and and a little bit weaker um is is really annoying from a a leadership point of view and it's not good for the community because we've all been asking for these releases to come more quickly so we get cool new stuff on Ethereum and if everyone has to do that type of resource spending to be just at par with Ethereum no one's going to be able to beat Ethereum and I I do think there's a lot of interest in getting rollups that do more than just EVM. Uh I don't know what those things are, but I think that would be really cool, but most teams are very scared of not saying they're EVM equivalent or not not being compatible with the EVM.

So this is going to continue to happen. We needed to figure out a way to do this. And when we started to see that lift, we thought maybe we shouldn't be building out our custom circuits. And thankfully, everyone else was on the same page with us. In fact, you know, they probably had the idea first.

I'm not trying to claim we were first uh with this idea. We didn't build the ZKVMs I'm going to talk to you about later today. So, of course, we didn't have the idea first, but um what if we didn't need to have the specific thing we were trying to prove um be rewritten in a in a DSL, but we could take a virtual machine that can compute anything and put that in the DSL. What if we could just do that once? Then we could feed as input Ethereum clients.

And this is the story you probably heard, but I'll say it again here just for completeness. Um, if we could do that, that would be really, really good because now I can take my inputs and make them Ethereum and then that I can change whenever I want with Ethereum because if Ethereum is going to do a hard fork, clearly they they have the code to do that. And then we're good. And uh, in this case, we can target a language that everyone knows or at least more people know or at least is easy to prove. One of these could be risk 5 or risk v.

Uh, and then the inputs to that VM can just be in Rust. So I said we can't fix the REST issue. Oh well, at least Rust is more popular than Halo 2 specifically. And now the developers just need to write um the input to that and they don't need to understand the DSL which is really really cool. So they don't need to worry about finite fields or having an inverse to an element or anything like this.

Great. And now they exist um over the last several years they become really really popular. Um a couple that I have been following more closely than others are risk zero. I don't know why it's so pixelated. Uh SP1 Joel Hermes sorry.

There's there's a bunch out there and they're becoming really really performant. And so now if they're open source and thankfully a lot of them are, we can actually use them and use them to replace our own ZKVM. And if we could do that, the system will look something like this. You take your ISA, your virtual machine that you no longer sort of need to maintain as a role developer. You just assume that there's a nice instruction set architecture.

You write um that in a zero knowledge domain area. So over here you have a ZK virtual machine and then you put as input whatever you want. And we'll see later that I'm going to put in my state transition function for a rollup in there. And now we're really good because I can change the inputs as much as I want without changing more or less the rest of the bottom of the picture. And in particular, if I have a rollup, it might look something like this.

This is oversimplified. We're going to put the EVM from down here up into the inputs of the program and suddenly we're in good shape. The L2 blocks there is a little bit inaccurate. There needs to be L1's to drive where data went and things like this, but more or less this is what it looks like. you give me the EVM and the thing that's was supposed to compute and I can convince you that it computed that thing correctly.

Because of all of this, my life gets a lot easier. A lot of other people's lives may not get quite so easy, but you know, they're interested in this. Uh, but we can share the load, right? We can now have a community effort to make sure that the Zeke uh VMs that we're using are correct, have been set up correctly, and are optimized. If I am using a ZKVM that other roll-ups are using, we're all incentivized to make this really good and fast because we can share the the results and get it all done together.

Um, rather than just me having direct ownership over my circuits where I might break something. I don't want that, but it might. Uh, you can also standardize and compare results a lot quicker. When the first time we came out with uh optimizations to our Halo 2 system, it was very difficult to convince other people that we did something because uh if the other Halo 2 circuits were a little bit different, people would would ask questions and and not see an improvement. Um even if they were there, this time we can be very standardized, right?

We can say, "Okay, if you can prove this specific Ethereum block faster, that's it. You're faster. It's a lot easier this way." And now uh the greatest part for me um and probably a lot of people is that the developers who want to prove something no longer need to know this thing. The downside is customization might be harder.

A lot of the ZKVMs have open source software for the VM but not necessarily the provers. So the provers might be a little bit slow unless you pay them or maybe there's a way you can make it faster yourself but it isn't an issue. Uh and then you know you if might have problems with other applications of ZK. If you're trying to do something on a phone maybe the VM is still a little bit too powerful. can't do that.

You got to rewrite something from scratch. Nonetheless, uh probably not an issue for a rollup. The next one though is how do we actually use it? I built all this framework to get migration to get Halo 2 working on a on a rollup. How do I actually go over to um a CKVM?

Thankfully for us, it wasn't too hard and I'll try to tell you exactly why that was. I only have 10 minutes left, so it's going to be kind of fast. We had two questions. We said first, how do we actually do this? We made a lot of changes in circuits specific architecture to make sure that the Halo 2 provers we decided to use would actually be reasonably competitive.

I don't think we ever won the race for fastest block time as much as we wanted to. I don't think we ever got close. Uh I think we got close maybe but we didn't win. We made some changes. And then how do we how do we fix that?

And then second which ZKVM because I showed you a slide with at least four GitHubs. There's probably another four that are very close to that and then there's probably another four that are more obscure but also still very performant and I bet there'll be another four by the end of the year. So what do we do to answer the first one? We can say oh we actually had good planning. There's two main issues here.

Uh one is for a lot of the Halo 2 circuits what we had talked about in the past was changing out the KSC based um state try for Poseidon. This allowed us to prove blocks in the Halo 2 um proof system a lot quicker than if we didn't do that. But it would have made a lot of changes in a lot of other places and we saw it was so damaging and we thought that this would actually be effective as a strategy the CKVM strategy that we actually just added it. So we actually had dual state routes being uh pushed out and I gave a talk about this in Denver. Uh so that was pretty good.

And we also thought we should have modular prover architecture so I don't have vendor lock in with anyone. So I can prove you know my Halo 2 proofs on a different proof system whether that's Halo 2 or something else uh on different hardware on different clouds on things like this. Luckily, both of those are very valuable. Um, they're both able to help us right now. So, now that I have dual state routes, I can actually disable the one now that's ZK friendly for Halo 2 and go back to my Kessac one.

Makes me very much closer to Ethereum, which I'm very happy about. And uh, this modular design also means I don't have vendor lock and I'll talk a little bit more about that. So, that's specific stuff. Generally, if you're just forking the OP stack, all of that goes away. You don't need to worry about that except maybe pro building out the prover pipeline.

That modularity is something we probably want to build out you know if you're going to do this and we are seriously going to consider uh open sourcing that but we still have other things we need to open source before we get to the modular part but talk to me if you have questions. So the more interesting question then is which ZKVM and this is what we found. Uh we found that the best way to do it was actually to optimize for time to market not necessarily best performance. Now that's not to say we're going to pick a very slow prover. Um, the goal was not to pick one that proved in hours, but if something proved in 5 minutes or 5 minutes and 15 seconds, I didn't care.

It was a little bit different. Uh, when you get to realtime proving on Ethereum, this will matter a lot and you need everything to come under 12 seconds for a rollup which has a delay period of not 12 seconds. I am less concerned about this. And so what we did was we found Kona, SP1, some partners, and we put our own code into this. And so I'm going to talk to you a little bit about what we changed and how we did it and why we did that.

keeping in mind that we optimize for go to market time. So first uh these three things or four things are critical and you may have seen them before. Um a lot of them make up what would normally be called op succinct if we didn't make modifications but we did make modifications so I won't call it op succinct but ops succinct is typically Kona SP1 the prover and a prover network namely the succinct prover and we took all of these things and we modified them to make them work for us. Kona is the state transition function for um optimism based roll-ups and we were optimism based. We forked their code.

We started building on that. We tried to make circuits work there. SP1 is a state-of-the-art Rusk uh Rust uh ZKVM which will prove any inputs in Rust if you can get it to compile and all that the usual conditions and the approver network. Uh we do want to do some stuff inhouse but it was easier to also talk to some people and then the changes. So let me get into it.

So as I said, optimism built out Kona as a way to measure or to to record or prove the state transition of the OP stack chains. So not only building blocks correctly, that you know the EVM didn't do a a bad addition or something like this, but also that deposits in L1 blocks were correctly read and included in the chain. um that the op node is actually proposing those block those deposits inside the the L2 blocks and that the L2 block is being correct built correctly and so it was designed as a fault proof system so that they could prove whenever there's a challenge very quickly who is wrong on optimism we are aiming we are a zero knowledge rollup we're aiming to be a zero knowledge rollup so we wanted to prove every single block so this part needed to change a little bit and we'll talk about that in a couple of slides nonetheless we're standing on the shoulders of giants OP succinct came packaged with SP1. We found that this was more performant in our own experiments than other alternatives. Um, and it also has a nice set of other options that we can change.

So, if we want to go potentially uh quantum resistant, maybe we can use the built-in Stark some way. I think the proof size might be too big to do that out of the box, but you get a whole bunch of really cool stuff out of using SP1. Um, their use of pre-con files is very important, very uh performant, and we got it to work. And then we went with partners. And the biggest question I'll probably get is why didn't we use a sync?

Uh and that's mostly because uh Cyny gave us um optionality for different ZKVMs. Although we trust the SP1 improver if we want to change because we suddenly care about having the absolute most performant one or because there's a bug somewhere or for whatever reason, we wanted to go with a third party that would actually allow us to have that flexibility with great ease. And uh they provide an ICVM API infrastructure. So we just send them the things we want to approve. They come back with a proof.

We're happy. And so what did we have to change? Well, we had to change uh a lot of things. Uh first Kona was built for fraud proofs. We wanted to be validity proof.

So we had to make sure it proved every single block rather than just when things were challenged. Um other code bases started down this route like Kyua. We found it was easier and more performant to modify Kona in the ways we cared about. Uh Zirket also has its own specific functionality. we had to change that and put that into the state transition function.

Um so if you get a quarantine transaction, you need to deal with that. Um OBS succinct also out of the box talks to the prover network at succinct notary. So we had to change that. That also means we have great modularity and we can switch back and forth whenever we want. And then there's other changes that we're about to release which we haven't which is including uh stuff to derive DA in a more optimal fashion.

So uh reducing the amount of things we have to prove number of cycles. So we switch we picked SP1 and that actually went live last Monday. Yeah, it's been live for two weeks now. So uh Zirk is actually now proving every block. We're using SP1.

It's very great times. If we look back at the picture, what did it end up looking like? Something like this. We have the SP1 ZKVM. We have our EVM and Kona which will then read data from the L1 block.

So the the batches from the sequencer will go into there. The deposit transactions obviously go into there. Anything else is there. We prove that that is executed correctly. We verify that on chain and now we have a proof that we are a ZK rollup.

For the actual migration, um there was a lot of practice and I'm running out of time so I don't have a lot of time to to say too much about it, but essentially we picked a hard fork time sometime last Monday. We set up a new sequencer to take over as soon as that block hit and then we deprecated the old one at the same time. Um so going forward from that block forward, every L2 block has a SP1 proof attached to it. We're proving every single block. Um, we did wait for the old prover pipeline to finish because we had some stuff pending.

We wanted to prove what was left and then we just proceeded. So that was sort of it going very very fast. On the technical side um I won't go through too much of it but there was uh a lot of changes. A lot of our code base from optimism had to change. The one I think is most important is first we disabled our CK try no longer need it.

And second we no longer have this notion of a circuit capacity checker. So us and scroll and some others when we were using Hill 2 based server uh provers couldn't prove every transaction. Sometimes pre-ompiles would have too many calls to them and our provers just couldn't handle it. And so suddenly that's gone and now we're really really happy about that. We also added a new pre-ompile uh P265 P256 verify and then we upgraded a whole bunch of things from optimism because they had also been chugging along and doing development.

We changed the proposer. I'm running out of time so I'm not going to talk about the smart contract changes. A lot of stuff changed. As a takeaway, I want to talk a little bit about the performance. And these numbers are not 100% accurate, but they're a really good indication of why we're also excited to do this, even if developer time wasn't my main concern.

And that is about a 10x speed up if we have GPUs. Um, these numbers were not necessarily the best we could do, but with the Halo 2 prover, we were getting around 20 minutes with or without GPUs, and you had to fill this big table and prove everything. on SP1 because you actually only prove the execution of the cycles you use, you can be a lot more efficient. And on an empty block, you can get down to two minutes. Uh for us, uh a full one might still take 6 minutes.

On the next slide, you'll see that actually real blocks take only about 2 minutes. So we have a little bit of work to get our prover up to, you know, the very most performant one that we can compete with. This is from ETH proof. So these are real blocks that a version of an SP1 prover. 2 minutes is about accurate, even if it's not empty.

And if you get GPUs, it's going to go down even more. But this is not my work, so I don't want to talk about this. Just noting that now we're all working towards the same goal. We have this idea of real-time proving coming. So if we get to 12 seconds, that's really, really huge.

We can use that as well. Everyone can now build on a couple key prover technologies and everyone can win. Some challenges, uh, some of the API needed to be changed. Um, the trusted setup from SP1, we have no reason to doubt, but we might do another one ourselves just so we know we're the honest actor in it. we didn't participate.

If you did, then that's good. Uh, and although we do love the ability to um say that everyone can optimize, it was nice owning our own stuff because we could make direct changes and now we we'll have to, you know, talk to other people and make sure that everyone's on the same page. No CCC I talked about. I'm out of time, so I'm going to skip the slide. Uh, future direction, more ZKVMs.

Hopefully SP1 never has a bug, but if they do, we want to be able to use a different ZKVM. We want to optimize it regardless of whether that's their approver or our approver. We want to do that. And we also want to consider things like ref. That's it.

I'm out of time, so I'll stop there. I think do I have time for questions or

Thank you.

No. Okay. Thanks.

I think we have time for one short question. Anyone? I know this is a lot of ZK, which is not that easy on the brain. But yeah, if nobody wants to ask question, I have some questions. Um maybe the one I'm most curious about how do you think about the security of the prover that you're using for example how important for you is the audits the formal verification of SP1 because these are your users and now you're kind of outsourcing so how do you

this is by far the the most uh scary part of of going down this route is before um I was fully accountable for my circuits it was mine and if I broke them I knew who to blame. Now I have to, you know, try to convince someone else that they've actually got a bug if if I think there is one. Um, obviously if I have one that I can replicate, it's it's very easy to do that. Uh, but this is this is very very concerning from the point of view of like what if there's something subtle and no one's got it. And so we will take some ownership of our own like version of it and we will talk to to people maintaining the code to make sure that it's um, you know, getting all the treatment it deserves.

But I think the easiest remedy for now is to say, you know, have a backup ZKVM in case it goes wrong and prove that that is effective. The reality is I'm open to suggestions for doing better. Um, we, you know, we can get the code audited ourselves to we can do uh formal verification of that for everyone, but I think that should be a community effort and I don't think we're going to be the only one using SP1. So if you're using SP1, you want to improve the security of it, you know, come talk to me, too. I'm happy to try to figure out how that looks or you know tell me that I shouldn't be using and then I will change it out as quickly as I can.

But uh it it has it has been worked. So we're taking a very pragmatic approach.

All right. Thank you very much.