Challenges of Building an EVM Equivalent ZK Rollup on the OP-Stack | Martin Derka | ETHTaipei 2024

thank you very much all right uh as said my name is Martin I'm the co-founder and Technical lead at zerit uh it's a great pleasure to be here great honor to speak right after Carl because I'll be picking a little bit uh at his and optimism lab's work uh this talk is going to be about abusing it's actually going to be about abusing the out of the op stack to do something that it wasn't meant to really do and it's to build a zero knowledge rollup uh so we did that that rollup is called circuit uh and we usually say that zerit is a novel evm equivalent zero knowledge rollup uh that focuses on security and brings more security ai ai powered security to the sequencing protocol so today I want zerit to be something different uh I want zerit to be a zero knowledge rollup that is built on something unexpected and that's the op stack op here stands for optimistic right so we are actually marrying two technologies that are not really meant to work together and this talk is about the challenges that this entails just in case you know you wanted to do something similar so that you know what you are getting into so little bit of you know recap uh we distinguish between two families of rups right we have the optimistic rollups and we have the zero knowledge rups in optimistic rollups or in both the families of rups uh we have some actor called sequencer the role of the sequencer is to collect transactions either from the users or from the L1 then take those transactions somehow order them into the sequence so that blocks can be formed so the sequencer essentially forms your uh layer to blockchain then we have another actor uh that's the state proposer so State proposer every once in a while takes a look at the uh State root of the blockchain that is formed that's your Layer Two it's going to take this state root and it's somehow going to record it on on to uh L1 inside of some kind of smart contract right and then in the case of optimistic rollups we have another role that's the Challenger in here and the role of the Challenger is to be watching those uh outputs that the state proposer records on L1 and if it uh notices that something was done wrong you know the way how Carl was describing that he's producing those uh dishonest outputs it is supposed to provide a proof that this was was actually done wrong and that would result in uh you know rolling back the state right and the Challenger it has some window of opportunity to do so that's the seven days so anything that is younger than seven days cannot be considered uh fully fully final everything is older than 7even days means that it's final because the Challenger no longer has the opportunity to come and say hey uh this is wrong we're going to roll it back right so you reach the finality after 7 Days on the other hand with the zero knowledge roll UPS uh we are proceeding a little bit differently again we have some role or actor called the sequencer it collects the transactions but before giving you know the state proposer the opportunity to grab the state and submit it onto L1 we need one intermediate step that's called proving so you know before the state proposal comes uh we grab the state we give it to some actor called the prover and the role of the prover is to produce suin mathematical proof that transition function of the blockchain was applied properly that this state is in fact valid and give that together with the state to the uh proposer who submits it onto L1 on L1 instead of just submitting it and you know letting the state sit and wait for a challenge we have a smart contract and the role of the smart contract is to verify that the proof is in fact valid and only if it is valid to accept it and include it in the state what you get for this extra work proving is immediate finality right you have the mathematical proof that this uh state is actually correct so this is the distinction and difference between a zero knowledge rollup and an optimistic R now imagine that you actually want to build a zero knowledge rollup there is whole bunch of teams working on on some kind of rollup out there out out there right now so you probably won't be starting from scratch right you will be looking at what other people did how they did it and you don't want to reinvent the ve so uh you will be starting from something and what you will probably find is that you will need two basic things you will need the note infrastructure and then you will need some form of a ZK evm or some form of theover right so for the node infrastructure you have this fantastic framework pioneered by the optimistic Labs called the op framework and that framework is going to give you the sequencer it's going to give you the Batcher right that's the guy that is is uh taking a look at transactions somehow compiling them together and at some point submitting them to the data availability layer that's called the or that's what the acronym da stands for in here then you will get some smart contracts those are the contracts that you are submitting the stuff to that reside onto on L1 you will get the bridge and you also need something that will be maintaining that layer two chain for you right so you will get some version of gu or L2 gu and then if you want to actually get a zero knowledge rollup you will need that zero knowledge Machinery so you will need to generate the zero knowledge proofs again as I said there's a whole bunch of teams working on such stuff out there and one thing that you might find are the circuits or ZK evm provided or developed by the Privacy scaling Explorations based on Halo 2 so inside of there you will find a whole bunch of op codes uh split into some uh individual circuits that prove various statements about uh the transition function and out of that you can actually generate the smart contract that will be capable of verifying those uh those proofs for you on chain well so it seems that this is simple right you just like plug these things together and it will work well this talk is about the fact that this is not as simple as it sounds so once you start diving deeper you will realize that inside of the node infrastructure uh the sequencer actually needs some special privileges for injecting transactions so that the entire optimistic protocol or the op stack uh can work then you will find that the Batcher and data availability doesn't really you know tie directly into the stuff that the circuits and zero that the circuits provide you those are the zero knowledge proofs you will also realize that the smart contracts and the bridge are not as modular as you would like them to be and once you start making changes it's going to be a little bit difficult and you will realize that the GU itself for managing the state of that L2 was and needs to be changed which is going to come eventually and bite you in the butt on the side of the zero knowledge proofs as I said you will get whole bunch of implementations for the op code that actually implement the uh ZK evm but you will not necessarily get the pre-compiled out of that I will speak about that a little bit later then you will realize that those uh individual circuits are not necessarily connected together so there might be some coherency missing and when you want to generate your verifier that's actually you know not such a simple task it entails a few few steps and it might not be as quick as you think that it will be and even when you have these two things somehow together there is a whole bunch of other stuff that is still missing right so you will require some infrastructure uh there will be some documentation hiccups in the process you will need some front sense and if you want to do good engineering work you will also require tests so in the rest of the talk oh sad that it's a little bit broken uh on the slide uh I will be talking about these uh topics a little bit in detail and I will be going through them as those individual challenges so um let's talk about the first one when the op stack was being developed and architected the authors very clearly needed to make some you know decisions architectural decisions right so these somehow represent problems the first problem is that the sequencer injects transactions into the chain so the op stack it actually has two types of transactions that need to be injected one is so-called system transactions I'll be talking about those on a separate Slide the next one are so-called deposit transactions the deposit transactions are the ones that we use to bring some assets from L1 onto L2 well none of these transactions are actually paid or paid in the evm equivalent way so for system transactions uh again to be covered them a little bit later the system would need to pay G but you are the system right your sequencer is the system so somehow you're going to make up gas for yourself and uh pay it immediately back but hang on the evm doesn't just let you make up gas or you know fund an account with artificial gas that is an invalid operation and that is something that the proofs that you're trying to generate should fail on right so this is not cool with us uh same thing we have the deposit transactions the deposit transactions they're actually submitted on L1 they you know Bridge those assets that may be eth that may be nfts that may be erc20 tokens but the point is they are submitted and paid for on L1 and on L2 that should just happen through the privilege of a sequencer to insert those transactions again they are not paid on L2 so your circuits will need to complain about that and you will need to change the circuit so that they are not uh you know even equivalent uh in this sense and then you have whole bunch of services that suddenly you know before they were optimistic right so they didn't have to worry about any kind of proving any kind of proofs flying around any kind of data related to that uh well now they do so the Bater needs to know the proposer needs to know that it's no longer proposing just a state in some transactions but it also has some uh zero knowledge proof with it the data availability might need to be changed a little bit so that you know all the data that you need to reference in inside of your proof during the verification uh is available and uh therefore can be somehow uh checked during the verification process so in general these Services they were not designed for zero knowledge integration uh there is you know various frequency uh in which they are supposed to act and do something and interfaces generally do not match you will have to change that the frequency will hinder you in terms of performance and then the interfaces they just need to be adapted then you will get the smart contracts so I said the smart contracts are not as modular as you would like them to be a great example of that is the bridge so when I was talking about the zero knowledge rollups versus optimistic rollups um we said that in the optimistic rollups we have S day of waiting for finality in zero knowledge rollups the finality is achieved immediately so when you are withdrawing from a optimistic rollup through the Canon canonical Bridge you need to initiate your withdrawal then you have to wait 7 days and then you have to complete the withdrawal this is not necessary in the zero knowledge rollups the moment your state is rolled up together with the proof that's the moment when you can start completing the withdrawal so there is a whole step that is kind of you know skipped uh and you will want to implement that in your smart contract so you will want to remove that window uh of waiting for for 7 Days Well turns out that the op stag actually comes with a whole bunch of quality of life tools uh that's called the optimism SDK those quality of life tools they serve the purposes of checking the status of the blockchain so you know is this given block final and like hardcore final or can it ever be rolled back and as soon as you start modifying the smart contracts you will realize that those are actually very closely coupled uh with the SDK so you will have to start modifying the SDK as well then you will learn that g itself that's the component that is managing the state uh of that L2 chain uh for you was changed as well right uh it was changed because it needs to support some optimistic uh operations right now such as inserting the transaction but then once you start modifying it so that it can support your zero knowledge rollup you are starting to bring in new and new features that you know was were not there yet and where you end up is that you end up merging a few Stacks together right and this is definitely not trivial and it's specifically not trivial once you realize that that gu that is part of the op stack is actually used both for communication with L1 and for communication or maintaining the state of L2 that you need to run some zero knowledge proofs on so the optimism team they're actually doing a great job keeping up with the development of G right we had the Denon update last week and they already are supporting these transactions this is this is fantastic this is exactly what we want but this is exactly what we want when it comes to the communication with L1 when it comes to the maintaining of state of L2 you realize that you suddenly have that close coupling together with the circuits and so you kind of sort of want your L2 gu to be frozen in space and time because if it is not you will need to be upgrading uh your prover all the time whenever there is some update uh with gu unfortunately in the op stack there is only one gu it's used as a dependency on both so for example when you are rederiving that state how Carl was saying it's actually deserializing some transactions from L1 into the same data structure that uh are used to actually produce traces uh for the zero knowledge machinery and so on so this you know is a little bit of a problem then I was talking about the deposit transactions so those are the transactions that we use to bridge uh assets such as eth right so I already said that those transactions are paid on L1 not on L2 the way how it works is that you show up to L1 you say hey I want to bridge some amount of eth so you send that eth to the bridge and then on top of that the system is going to burn some extra gas for you and that's going to signify that you have paid the due that you would normally pay on L2 because you cannot pay anything on on L2 you don't have any eth there yet right so that wouldn't make sense so those are the problems with uh payments uh and I already touched on that a little bit but those are not the only problems that uh relate to the deposit transactions so the problem with these deposit transactions are that in the op stack they're actually not included in the state of any smart contract and they are not included in the state of the blockchain in the sense that would be accessible to Smart contracts specifically the verifiers when they need that right what happens is actually when you bridge uh the stack is going to emit some events those events are going to be read and detected on L2 and then the sequencer is going to inject those artificial transactions well guess what we need to do in the zero knowledge setting we have to make sure that the sequencer didn't make it up right that it didn't inject some transactions because it has the Privileges to inject them so once your proof comes you would somehow like to reference those transactions from the verifier contract but as I just said that is not possible because all that you have available are those events or some call data that is available in some kind of an address so you have to engineer for that and you have to somehow reflect it in your uh Zer know circuits and again get itself it does require changes it does does require the ne the the ability for the sequencer to insert some transactions that is not uh in general evm equivalent so it is going to further complicate your circuits suddenly you will realize that those beautiful evm fully equivalent circuits provided to you by the PSC repo no longer work you will need to change them and divert away from evm not that not something that you would normally expect cool so uh back to the smart contracts so at some point you know throughout your life cycle you will realize that you want to change them because you know you have started with some design but it's no longer no longer good enough you know maybe if you swap the proving system a little bit uh you would be able to generate your zero knowledge proofs in a faster way and you might start making more and more modifications well everywhere you touch those smart contracts you will realize that there is some very close coupling and that there is no single interface that you know would constitute a zero knowledge rollup or an optimistic rollup that you would just need to implement and everything would suddenly work right so you will find yourself in the struggle of modifying those smart contracts all the time and modifying everything that ties to them uh which I already mentioned is for example the SDK plus the other services that are part of the rollup itself then if you if you start with the op stack as you currently find it in the repo uh you will find that it contains some Legacy code the situation here you know has definitely improved the repo has been cleaned up quite a bit but the point here is one thing that we all love about the op stack is this is that it is Battle tested right there is mayet out there it has been running for some time uh we know that this thing actually works well because there is a mayet out there and because optimism also evolved they went through some migrations of the state some upgrades some improvements and so on so you will find a lot of code that actually relates to backwards compatibility uh which is important for optimism and rollups you know that are upgrading but it's not necessary for the rollups that are just started right you will probably not going through two or three upgrades just so that you can start your rollup fresh from zero uh you will want to start with the most up toate code finally as I said bridging is not zero knowledge feature complete that's not surprising at all again we are abusing the optimistic stack in here and trying to do uh some zero knowledge stuff right so what you would specifically want to uh you know have more with respect to uh bridging is the ability to make some statements and claims about uh the amount of e that was bridged right you will have to somehow prove that the sequencer didn't make up how much it should be issued to this you know given uh account on L2 cool so system transactions that's the second type of transaction that is inherently uh necessary inside of the op stack what do they do here up there you can see what they do they actually take some values from L1 such as the block number such as the timestamp such as the base fee and so on and they record them into a smart contract on L2 this is a design choice that was done by the optimism team uh you could philosophically debate whether this is the best design choice but definitely this happens it definitely also happens in an every single block of L2 so every single block of L2 will take a look at L1 uh the block time the default block time of the op stack is currently uh 2 seconds you know all the rollups out there do some sort of a similar time be 3 seconds be 5 Seconds be 4 seconds doesn't matter it certainly moves much much much faster then these values change because L1 moves slower right so you are several times repeatedly recording the same values over and over into a smart contract on top of that you know you're not paying for it right I already mentioned that several times but um on top of that these are transactions so you actually need to generate some of those zero knowledge proofs for that you need to post this data on to your data availability layer and you need to verify the proofs so that all increases the operation cost and eventually it will increase the cost for transaction for the user right so you sort of need to engineer against that and consider some alternate designs otherwise this is going to be uh General problem so here I'm on slide 15 and so far I haven't told you anything about the challenges that relate to the zero knowledge proofs we were just through the you know note infrastructure right so yes you will get your ZK evm through you know some repository that you might find online uh be it maybe the one from the PSC be it a different one but what you will learn once you start you know implementing and Maring things together is that uh you didn't get everything that you need you have some op codes that are implemented right you will get whole bunch of circuits it's something like eight of them that are ready to prove some individual claims but that's about it so the op codes themselves they will be implementing the evm but evm is not everything that you know is currently available on uh ethereum uh specifically what you will not get are the pre-compiled so pre-compiled are some smart contracts uh that are included on pretty addresses ethereum currently has nine of them so addresses uh one up until nine and those are let's say some uh you know more complicated cryptographic functions that would normally cause a lot of uh computing power uh to to uh produce and they would be expensive for gas so therefore you know what we are doing on ethereum is introducing smart contracts that they actually Implement these features and we price them a little bit differently so you will not get the pre-compiled because not all of these precompilers are zero knowledge friendly and you would have hard time generating zero knowled proves for that so you will have to address it somehow and you know uh if you want more functionality or more precompiled that somehow has to be addressed as well and you will have to develop more and more you might find yourself diverting from the evm equivalency more than you would uh originally and visual then I said that you will get those individual circuits right so let's say that you have eight circuits that are uh capable of very quickly proving some small claims about your transition function and the transition of the state well you don't want to be posting all those individual proofs on chain 8 times right every single posting every single transaction every single verification is going to cost you gas so before you do that you will want to aggregate them somehow right so take those eight proofs and produce a different proof that proves all of them at the same time well that is easier said than done because while yes you can do this there actually aggregation systems out there you you know just by the fact that you've merged eight proofs together will not really get a proof of one claim that you want it to prove specifically what will be for example missing is the data coherency you will not uh for free get the fact that all of these eight proofs that you've just merged together were produced using exactly the same inputs right again you will have to somehow engineer for that and you have to reflect it in your code uh in general you might also have to make some changes to your gu because uh you know not everything in ethereum specifically the uh hashing function catch hack is zero knowledge friendly you know there are other functions and other things that might uh be a little bit more efficient for you in terms of uh performance so finally once you've covered all your angles you have the node INR structure and you have your zero knowledge uh evm uh this still doesn't mean that you have a full rollup right you need to run this somewhere and you have to make sure that everything is operated in some reliable manner so you will need to orchestrate the uh blockchain and the approver generation and the state proposer into some pipeline so you will need some infrastructure then depending on how exactly you have designed your uh zero knowledge evm you you may need some specific Hardware that allows you to produce these proofs uh in a effective manner or the other way around if you have already you know purchased some hardware and you are bound to operating on certain infrastructure you might actually completely need to redesign your zero knowledge uh evm so that you know you can operate on the given Hardware now if you want to do good engineering work it doesn't end with code itself right there is whole bunch of other stuff and artifacts that you might need to produce so I'm calling it nice to have but it's actually not nice to have they these things are necessary for you know well-developed systems so you will need to test your code but you will not only need to test your code you will also need to test your zero knowledge circuits now imagine that you're trying to produce unit tests or integration test for something where a single run lasts for 20 minutes or 30 minutes and it's just a single run and it might require expensive Ware and GPU and and something else right this is not an easy thing to overcome because you will suddenly need to you know employ a lot of mocking and and various Advanced testing techniques but if you're mocking out the generation of your proofs well what are you really testing in here you know so this is definitely a challenging problem you will be struggling a little bit with the documentation because you you know as I said the system had some evolution in the past right so you will be finding documentation that is obsolete you will be finding Fe features that are not really documented anywhere and you will somehow have to deal with it and fix it for your system and in the end you will also need some web to components right because people will not be interacting directly with your sequencer or directly with the smart contract they will want interfaces they will want block explorers and so on and finally even once you have that well you will need to operate it right software itself doesn't constitute you know an operating uh system so you will need to deploy it somewhere you will be running a whole bunch of services and you will need to keep consistent simply make sure that all of these services are up and that your chain is not down because one of these Services is not progressing or is is is slow so I'm getting a signal that uh I'm out of time so I will skip this slide in general if you want to have a rollup that you know has some future you will need to also think about the future so you will need to make some cryptography improvements uh that relate to the generating of zero knowledge proofs and performance you might also think about some new features that your rollup uh uh wants to have but that's it for my talk so just to quickly summarize op stack it's a fantastic starting point it's you know one of the best Frameworks that exist out there that is generally available if you want to build a rollup I can heavily recommend it but be aware that it's a starting point you will need to make some changes uh you will need to do a lot of research especially if you want to produce a zero knowledge roll up but you know nothing in here that I have mentioned is not something that you know you couldn't overcome and then uh part of what I wanted to talk about is some security stuff but I will not have time for that at all so thank you for the attention uh if there are any questions if we have time for questions I will be happy to take them otherwise thank you [Applause]