Zircuit: Challenges of Building an EVM Equivalent ZK Rollup on the OP-Stack | Jan Gorzny - Zircuit

hello everyone presenting this topic is for zerit challenges of building an evm equivalent ZK rollup on the op stack this is is John gorney he's the technical lead for zerit here you go great hi thanks for the intro happy to be here at e Denver for uh for my second talk uh maybe you have seen something similar earlier in the week here uh maybe you've seen something similar at um Dev connect in able maybe this is all new uh either way I hope you enjoy it and I hope um you see the at least slight changes that have uh Gone on between previous iterations and this one uh as mentioned my name is yon gorney I am Tech lead and co-founder at zerit and I'm here to talk to you about um what we were doing uh without you know saying so much what the end result is there will be some of that but really um some of the challenges we experienced when we were uh building this thing which uh started off on the op stack which I'll talk about a little bit obviously the whole talk won't be about op or anything like that but uh it is important to have a good understanding so before I get going I realized the the more often I give this talk uh the less likely this slide is necessary but uh the next slide will introduce zero knowledge rollups and I think it's really important to understand both of the systems uh at the same time because the essence of the talk is essentially we're trying to put proofs where proofs don't really belong and that's a lot of challenges but in order to understand where those challenges come from you need to understand where you're putting them and what you're putting them onto so what we're starting to put them onto as a starting point because we didn't want to reinvent the wheel was something called the op stack which is the code base that um optimism currently uh has for their optimistic rollup so what is an optimistic rollup if you seen the last talk you probably have a rough idea or uh but essentially it's it's a layer two Network where you have a sequencer a sequencer produces some blocks uh it does some stuff that um gets us a nice State output you know proposes a state submits it to the layer one and uh if no one says hey that's a bad State Route everyone sort of says yep that's a good State Route and let's keep going uh if someone does say you know oh that's a bad State Route then um there are people in the system who are at least in principle can uh come and say ah don't don't use that State Route that's not valid here's um some evidence or or fraud proof that suggests actually that's not a very good State Route and then some things will happen you know that there'll be some some reorgs or reversions out of that uh and essentially at the end of day you'll get a nice consistent state so essentially there's this long period of time that says you know challenge or not challenge a state route and otherwise if no one challenges we're all good and that's nice it's a very nice system it's got a good design uh the little downside though is you got to wait this long period of time and so we were looking at this and thought well you know maybe we can do better for sure uh certainly we're not the only ones to think of this uh but what happens if we wanted to take this Challenger and this this fraud proof system out of this otherwise pretty decent piece of software and put in a a zero knowledge proof system because uh we had heard over and over again that the op stack is so modular and you know it's just ready to to do all these things and we said well let's try it let's see what will happen and what we end ended up wanting to build was something that you know zero knowledgeable up it's it's pretty straightforward you've probably seen descriptions of these elsewhere if not you know I'll go over very quickly but um what we want to do is is essentially take out that Challenger from the last slide and put in this thing called approver so instead of uh generating blocks and putting a state route on chain and saying challenge me if I'm wrong we're going to say here it is and also here's a proof that says this is absolutely correct right and the idea is to be sure that something is correct as soon as hits the L1 so if it's not reorg out uh you actually have mathematical certainty that no one cheated you everything has gone right and as a result you don't need to wait a very long period of time you have a much smaller um finality period whatever that means I won't go into too many details uh and you get this really nice other alternative to an optimistic rollup and so what we wanted to do was go from this to this on the op stack specifically and what we really wanted to do is you know do this without necessarily sacrificing and without Reinventing all of the reals so what we did was we we did this um it's still ongoing it's intestin I'll talk to you more about that at the end but essentially we built this thing and it's called zerit and essentially it's a battle tested um combination of all the best stuff that's out there without sacrificing all the compatibility or uh concerns that developers would have on a zero knowledge rollup so in particular we're going to use all the Great Tech that other people have built customize it make it better improve it do all of our cool custom tricks but then also make sure it's a nice seamless development experience for the end um developer and for the users so we wanted to come up with something that uh doesn't necessarily make it easier because we've cut corners or because um you know we've traded off the familiar tooling everyone is currently using or on board with so the end result is zerit um it's zge rollup that is evm uh compatible and uh I'll tell you now about you know how we got to where we got and in particular um how the op stack played a part in this uh essentially we had been looking at the stack and some other things and doing a whole bunch of research and we thought you know there's some really cool ideas out there there's uh you know Tech techniques that that people are trying there's other techniques people aren't trying there are approaches that we wanted to try and um not necessarily you know able to convince other people to try it or you know we thought it was a really good idea so we wanted to play around with it we we're doing all this research that you know what why don't we just try to build one of these things and we did and then we sort of looked around at what the ecosystem sort of seems to be needing or wanting maybe uh and that was a little bit more of a focus on security because we honestly believe that security can go a little more than just a well-engineered product right we can do more to protect users on the system than just be bug free obviously we do want to be bug-free and that's you know something we're striving for and all of that uh but maybe especially while these systems are centralized or while they're growing we can do more to protect the users that build on the chain and so this is um the ideas we sort of combined and the end result is Zer which is starting off on the op stack building not necessarily or and definitely not actually on the super chain but still using the core infrastructure pieces okay so let's let's go into a little bit more technical about the challenges and the sort of non- Reinventing the wheel attitude that we had um we did also have a bunch of customizations which I'll talk to you about but like I said there's no point in you know doing things that's already been done so we took a look around and we said okay what is a zero knowledge rup well we need some infrastructure and we need some zero knowledge proofs and we need to be able to glue these together uh and so we look towards the optimism side of things for the infrastructure because they had a pretty clean code base it was pretty interesting they do were doing good development it's all open it's a very good license uh and we get some things very very you know easily and they work reasonably well uh things like a sequencer which you need to order transactions things like batchers and data availability Solutions which you need not necessarily the ones you need for a zero knowledge rollup but still something that you need to get started in addition you get smart contracts and the forks of gu that you need which are really nice I'll talk to you about some of the struggles but then we also needed a zero knowledge proof system and while I've got a PhD and I love doing this by hand if other people have done some work we should be inspired and take uh take advantage of it so we looked around and you know people like PSE and others who are open source had nice implementations of particular components or particular Parts uh but not necessarily the whole picture or not necessarily the whole optimized picture so you might look at a particular set of Open Source uh circuits for for a set of op codes and it might be pretty practical it might work but it might not be the best pro generation time or it might not be you know supporting the features that you want or or anything like this and so we started on these things but we certainly didn't finish there and and the rest of the talk is in part to convince you that actually it's not as simple as just forking two two uh repos and saying ah there we're going to work together now when we're done we have a zero knowledge roll up in fact there's a ton of other work the ton of work comes from these main areas of challenge first the node infrastructure that we get from optimism is not necessarily the one that's ready for prime time um it has a lot of really cool stuff but it also does some stuff that optimism uh has decided to do for either good reasons or bad reasons uh and isn't necessarily equipped for ZK prime time so we'll talk a little bit more but some of the high level things are things called system transactions if you look at an optimism block every block has a system transaction that updates the time of the L1 some gas prices some other things uh and injects it into the L2 block so that the L2 State can be updated this is a pretty nice solution there but when you're in a zero knowledge system that means you're now proving a bunch of transactions that are effectively just doing things to update your internal State can we do better can we do differently the answer may be no the answer may be yes something that we're going to explore and something we're working on certainly we don't necessarily have to follow their exact lead um other things are also great and helpful the Bacher and the da you need that every rollup should be publishing data somewhere but they're not built for zero knowledge rollups your your rollups might want to publish data in a way that's more ZKA friendly uh not you know the way the optimistic things do and then we'll talk a little bit more about gu and some smart contracts later on the proof side you have things that are you know like I said existing but not necessarily optimized you have individual circuits but no way to aggregate them so you might be able to prove them but maybe not on the hardware you want so you have to get in there and really change how these things are aggregated or built together or composed or otherwise engineered in order to make them work and things like the verifier really want to be optimized so that you do it very quick uh and then of course there's a whole bunch of other things a sequencer and a set of CK circuits is not a rollup a rollup is much more than that it's a whole functioning Network and um there's a whole bunch of things that are going on behind the scenes for all these rollups that people just generally don't talk about you need Pro pipeline so unless you have an open place Pro Marketplace uh you need to build that you know you need front ends you need backends support and a bunch of things you need documentation uh and you need testing one of the things we found was certainly testing is lacking in a lot of these areas and then even if they're not getting them to work on two different Stacks is a real pain so there's a whole bunch of things that you need to do to get from just what's out there to something that you can be proud of on your on your rollup because um you can't just glue them together and expect it to work so we'll dive into some of those uh right now and uh as the title says you know we're going to talk about the op stack so I'll pick on them a bit but honestly it is a very good starting point and shout out to the team they are doing great stuff um but essentially the main problem with the op infrastructure although it's open and very nice is that it's not ready for ZK Prim it is very good at a bunch of other things namely optimistic rollups um but not necessarily for ZK so there's a couple reasons for this I've already talked a little bit about these uh this notion of of system level transactions where you have transactions injected into every layer of two block which now suddenly you have to prove if things are expensive to prove on zero knowledge uh systems you certainly don't want to be doing extra if you don't have to so a block every 2 seconds uh which is what optimism does with a system transaction and every one of those can start adding up you know it's not necessarily going to be the biggest cost in your system but you start thinking why did they do this and can you do better and these are the questions that this project really started to to sort of question and try to answer differently other things of course um are built without ZK in mind because they're not a ZK roller uh the baters don't talk to the verifiers in terms of you the data being posted and is it the right inputs to your circuit uh because if something goes wrong on an optimistic rollup someone just gets slashed you can point the finger and say that guy didn't do it right here's why uh oh bad uh on a zero knowledge system you actually need these components to talk to each other so you need to build this engineering or sorry engineer this this component to make these systems talk to each other in a way that doesn't introduce extra trust uh and other areas of change are are you know some of it are engineering and some of it are are just different designs uh but some things like the smart contracts they're pretty good the bridge is pretty solid uh but the verifier you know the logic is very embedded on the on the fraud proof system or the the time outes into the bridging not so clean for for when you're putting in a zero knowledge proof system and then there's other things that you know really sound like a really good idea on paper like um embedding gu dependencies everywhere so that you look like gu you act like gu you look like the layer one uh that sounds really really good but then you look at zero knowledge systems and you say actually what I really wanted my gu is not shot 256 for hashes because that's expensive I want to switch it to Poseidon uh but only in some areas cuz maybe I need to interpret L1 blocks with shot 256 but WR L2 blocks with Poseidon um and if that dependency is too tightly coupled it's going to get very difficult turns out that's at least partially the case and it's kind of a pain to disentangle that so there's a whole bunch of things that need to change on the engineering side um other things you know again not me meant for ZK deposit transactions uh are the transactions that bring assets from L1 namely ethereum onto the L2 and in optimism if you cheat someone points the finger you get slashed you know that's bad but that's how the system works like bad in the sense that you'll go you know you're not supposed to be doing that um but the system works like that and it's totally fine on a zero knowledge system you can't just invent money out of nowhere uh you need to have a mathematical proof or some other way of checking with the L1 that actually this happened because no one can point the finger and effectively take any action with you obviously if someone did that you know you could go on their Twitter and say hey don't do that but the system would have already gotten away with action and there's no technical limitations unless there's a social consensus to fix it so we have to add all of this functionality onto the optimism snack we have to do things like make sure that the inboxes uh and outboxes of deposits and corresponding withdrawals also understand that extra data needs to come from extra places and extra things need to be changed uh and they have to tie all together so this adds some work this add some overhead um not necessarily you know a decade's worth of work but it's definitely non-trivial um the smart contracts again these are part of the systems that will need to be changed they're some of the most important uh they're pretty good but again not necessarily ready for ZK um they're not necessarily as modular as you want if you look at how you do uh withdrawals and optimism it's a two-stage withdrawal where you prove an inclusion and then you finalize it or vice versa and um you know that's nice but actually you don't need that in the ZK rollup you can change it despite that um the op stack has built it right into the sort of standard way of doing things I can't blame them that's what they're their system is going to do but it's not necessarily what ZK people would want um some of these points are getting a little bit less relevant um containing Legacy code they've actually done a lot to clean up that code base it's been very good but there is still a lot of references to sort of v0 um or at least there used to be uh where you know a lot of the contracts are based on the initial deployment of the op stack which has since been migrated to newer versions uh so some of this you can ignore very easily some of this you want to engineer out because you want your attack surface to always be as small as possible uh and then again again this this onboarding and offboarding is also missing so I'm going to try to catch up with my proposed time here and go a little quicker um but beyond you know the op stack once you get all the op stack Parts in in in uh the way that you want them and you sort of get your optimistic stack uh in a row you then have to bring in zero knowledge proofs and this becomes challenging for another reasons um there's no one out there as far as we know that has a nice open source representation of of things that just like automatically works out of the out of the box with the op stack so you have to do things differently right if you're using circuits that someone built um they may not be using the same version of the GU there might not be op codes that are fully supported optimism does a really good job of keeping up with the latest uh gu updates other people building circuits may not necessarily be doing that so you also have to pay a special attention to yourself to make sure that this happens and it does work and even if you get all the op codes you want as I've mentioned aggregating things putting these pieces together super challenging super um interesting because you can do it in very different ways in order to a differentiate yourself but B just perform better or have your requirements met um I'll pick on to the system transactions one last time here uh this is one of the things where the provs actually have a really hard time because you have a system transaction um that is a transaction that the system itself is trying to do to itself just to update state in some nice way but you don't want people paying for that because it's a system update it's right it's like the op stack telling the op stack here's the time on L1 um that's not something users should be paying for so you say okay I don't charge people for that or you know I don't check a signature for that either it's free or I'm just going to ignore this uh but how do you do that in a circuit well you still have to make one of those changes or find another solution uh in which case your circuits now start to look less and less like the evm you wanted to build at the beginning or you add more and more overhead to sort of skirt this problem um so there's actually a lot of challenges and these might not be unique to the op stack uh and they may not be something we can totally remove in circuit but it would be really great if we could at least explore different design spaces and maybe either reduce their frequency or do it in another unique way uh of course as I said sequencers and circuits do not a rollup make uh appr pipelines don't exist so even if you do have a nice set of circuits and you just do have a nice op stack node getting them to talk to each other you know takes some time take some data provs generally need block traces uh which can be fairly large uh and then they need to pass this information you need to control what blocks you're proving if you have batch proofs you got to do something differently than if you don't have batch proofs etc etc uh and you know things like mentation and testing also all need to be updated so they're consistent so that at the very least you know what you're doing but also so your developers know what you're doing there's a whole bunch of other things we can do in our This research space cryptographic improvements are always very valuable we have some we're going to keep doing some we're going to have more I hope the next time I give this talk I can give this very explicit um notion of what we've actually been doing for custom stuff but it's going to range from MSM to aggregation and everything else um and then we can also do things like security and I'll spend the last two minutes talking about security um because we believe that actually one of the really cool things about having your own rollup uh is to be able to add security to places where you can't otherwise add security because it's not your system uh and we in particular believe that if you're running a a sequencer with all these special roles anyways especially before it's decentralized maybe it can do some good right what you could do is add some level of security embedded into the sequencing protocol so that uh your security of your daap users isn't just based on their smart contract um ability to be non-reentrant or non bug you know don't have bugs in it and you can involve the sequencer to do something very unique and very cool uh so for example you could have it look at transactions in the mempool and if something's sort of bad whatever that means you could put into quarantine for a little bit and maybe it'll come back later and maybe it won't um that's probably not for everyone and some people might not like that but the reality is this might save a lot of money especially as these systems grow uh and evolve so I don't know what happened with my slides there cuz I didn't hit the click um um I still have a minute so I don't know what's going on here um but yeah that's that's most of it I don't see the RO all right and you don't see this right maybe it's the HDMI connection all I'm we're back all right so in the last minute sorry guys technical difficulties I must have stepped on something uh for the road map Zira's coming along we've been working up for a while we are super stoked to have launched our main net at or sorry our test net at devc connect and we're hoping to go main net sometime later this year but for now check it out try around play around with it if you have ideas for research and you want to collaborate please let us know if you think we've done something wrong with the op stack and there's easier ways to do something also let us know uh you know interested in all of these directions I also would like to see what you think Security on the rollup should look like and if there's ways we can help you so please you know come check it out uh otherwise you know hopefully go live when it's ready we're not going to go too fast break things but we uh do want to go reasonably fast either way if you're building a z rollup on the op stack it's not as easy as it looks it's not just forking something and saying put a ZK system in there but research can overcome all of these problems and can actually at the end of day get you a really functional nice rooll up and you can do some really cool stuff with it and then you can do even more cool stuff with that it's very unique the result at least the first time we've tried this is called circuit and we're happy to have you part of this ecosystem if you're interested please reach out here and we've got some staking things for uh points thanks