Designing for Change: The Modular Architecture of Zircuit Prover

Transcript

Hi everyone. Um I'm Igor. I'm the ROS engineer at um Zirket and today I'm going to share with you the module architecture of uh our module approver. So to get started um I'm going to start with uh who Zerg is and if you haven't heard about us uh some case then I'm going to talk about uh the the problem what led us to to uh to do this modular architecture in the first place. Then I'm going to talk about the the fast evolving um landscape of proving systems which is one of the reason why led us to do this in the first place. Then uh going to talk about the idea why uh uh behind the module architecture and uh

then they're going to go through in detail about the module architecture itself and then some closing thoughts. So who are we? So we are zerg and we are zk evm bu on hello 2 for now. Soon we're going to drop that E. We're going to become ZKVM. Uh we have tried to shop around for some uh implementations for that. But soon enough we're going to um we're going to drop the hello 2 and become ZKVM. Um we have the our main differentiator is secure at the sequel level. I'm happy to talk more about the ZKVM and this this after after the the talk. um we are secure native bridge and we have we are VM compatible and um all of that is brings we bring that together with the

modular architecture which is what I'm going to be sharing with you uh today so the problem so here I'm going to go with uh uh with an example just to highlight like what the problem is uh so let's uh imagine we have a proving pipeline uh and in the prover we have a few a few components Right? We have uh a witness mapping. We have uh ZKVM circuits proof system and aggregation scheme. Doesn't really matter who they are. But what I want to highlight is here these components are attached directly to the pipeline and for witness mappings is attached to the witness loading. Uh the ZKVM circuit is attached to Zik VM provers. The proof S to the

verifier and the aggregation scheme to the uh aggregation prover. And the problem here say I want to bring uh a new I want to update them two new components or I want to bring two new components to the system right and in this case I want to bring a new witness mapping and a new proof system right the problem with that with this architecture is that things start to break right the the all those change there you know the those components the I would say glue code uh you you find yourself not only updating the new system but also all the systems because all of those are tightly tightly coupled together So that becomes a problem.

So the problem right so zikk research advanced very very rapidly these days becoming obsolete in about 3 to six months you know uh we have a lot of um zkm if you look at zisk openvm all these days uh um god knows what's what's going to happen in the in next month or so uh so if you have a tightly coupled system or very tight shift and then you become obsolete very fast um and what exactly that you have a a very tight topology and you'll find yourself like trying to fix all this glucose and uh you by the time you finish you you're going to be very behind when um other things come out and that's where you where you are right you

instead of uh updating your current system you're always playing catchup instead of um working on top of them so before I go into the the actual modular approver. I just want to highlight how these uh systems are fast evolving. Uh so in 85 right we have the interactive zero knowledge pros come and then in the 90s non-interact zero knowledge and then in 2011 uh zk snarks 2013 pinoa protocol then grow 16 2016 bulletproof 18 zk starks blanc halo 2 2019 zkms and then 2021 blank 2 halo 2 2021 one and then

2022 plonish uh last year SP1 this year we have SP1 Turbo uh risk uh risk risk zero and then last week we had uh ZISK come up with something super cool so very fast and God knows what's going to happen next year right so if we don't have a modular uh architecture that can support you know u new proving systems uh which uh is going to we we're going to end up something like that, we end up like that kid trying to catch the ball when you're never going to be able to cuz uh it doesn't have the capabilities or the skills to do so. So, we want to avoid that. So, how can we um uh develop a module architecture, right?

Um that allows efficient integration, rap technology advancements without um minimizing while minimizing integration cost, right? That's what we are going after here. So the idea behind the idea behind uh the uh all of this is uh design for change right the design for change is instead of uh design for a specific a specific uh um technology you you want to design for something that's going to change in the future right it's going to change in the next two months three months you you don't know so you want to design with a change in mind uh something that's going to be uh easy to snap and snap out right uh uh you don't want to because just because you remove a component and introduce a new

component, you don't want to update the other components. You want to do exactly that. Uh snap in, snap out. Uh it's low coupling, low coupling and high cohesion meaning the components uh have specific responsibilities. They only do one thing, one thing alone and then there's no ambiguity on those uh on those components. And uh those components are extensible and scalable. system can scale or up or down depending on the inputs and you can actually uh customize uh how you you do that. Uh so that's the idea behind it. So now uh let's try to get this uh tight architecture and try to come up with something that uh a little bit more

flexible let's say. So let's start by removing all those uh breaking uh changes all the chains and now the idea is let's introduce like an abstraction layer right in this case we call the business logic now instead of attaching the components themselves to the pipeline we want to attach this business logic abstraction layer to the pipeline right so instead of uh you know the components being attached to the pipeline now we have the that abstraction layer so now instead said the the components is going to be following this abstraction layer we call trace because everything is in rust that uh where we do now and as long as those components follow the business logic the

pipeline should work since it that pipeline is attached to the business logic so now let's go into what that really means in the zer module architecture so the everything is module under the module approver we actually do have uh two assumptions the proof prover that you're trying to implement has uh can prove and can verify which is pretty much 99 or 100% of the provers today right so um uh the we make those assumptions and you know they have some components KVM VM doesn't really matter as long as it can prove it can verify uh the module approver support um that architecture and then we have the module orchestrator which is responsible for me

uh sending a message between those components maybe you have a prove maybe you have an aggregation layer maybe you uh you know sending those message to the L1 and that's responsibility of the module orchestrator maybe you want to store the intermediate components into database on the cloud and so that's responsibility of the orchestrator and uh we have this test framework which is not only a testing framework which can test the module approver and the module orchestrator and you can also uh measure CPU and memory uh that way you don't have to implement everything from scratch you can uh test things end to end or parts of the system with this um testing framework.

Cool. So, uh here I have an example where on the left we have uh something what we had before the tight uh couple uh system and on the right is an example what what it looks like uh now. So uh just for this example we have the same components there but again instead of those components being directly attached to the pipeline uh those components attached to this business logic which is uh I called traits because uh there's the interface uh used in rest and that's what's attached to the pipeline and the nice thing about this is that um as long as those components uh follow those traits right you implement or the maybe the the prover needs to prove, needs to

verify, you know, as long as you bring that component and you implement those traits for that. Uh, you can do exactly that. Just plug that in. You don't need to update anything else and and the P you shouldn't need to update glue code and all that and everything else um works good. And the good thing about that we don't instead of spending months and you know bringing a new component a new proving system we can spend a few weeks actually making that work and then the other weeks the other the other months actually uh optimizing the existing system and uh making it a little bit better instead of playing catchy up.

Now the modular orchestrator the module orchestrator is was um constructed with this uh dispatcher and collector paradigm uh where uh the dispatcher is this uh expects one input generates one output and the collector expects uh multiple inputs going to generate one or more uh output and they they do something with it and then generate something and then nice thing about this is we the message between them is all taken care of you. You just need to define where it's coming from, where it's going to, and you also you can define like uh uh where you want to store intermediate steps like maybe you want to store in memory or local storage or uh in the cloud and also that's

taking care for you which is pretty cool. So let's go through an example, right? So let's say I have an ex execution client maybe g be basu wrath doesn't really matter and this execution client is generating some blocks traces uh or data in this case and the first layer I have a layer of proof maybe you have secret proofs maybe as a KVM proof uh there and then after that goes to another que and I want to aggregate and I want to store the intermediate steps in the local database right so here the proof seems expects one input generators one output that becomes a dispatcher and the aggregation becomes a collection when you think about the about the

module orchestrator like that and similarly if I have another example here but in this case say I want to instead of uh aggregate right after proving I want to do a compression layer right uh which is kind of something what we do we have another compression layer there right now but uh this for simplicity say we have another example like this and instead of storing uh the intimidated steps in the local storage one is store in the cloud and similarly the the both of the proofs there they become um dispatchers since they expect one p generator is one output and uh and the and the aggregation there becomes a collector. So that's the the the idea and you'll see soon enough that the the

cues pretty much go away. you don't have to worry about implement that yourself because that's taken care of by the module orchestrator uh for you. So uh to go a little bit more detail on the dispatcher collector right so the dispatcher as I said before expects one input and one output and it has this processor which is takes the input it does something with the the the input right engineers an output we just happen to have a proof system and this something is actually the proof itself uh which is the executable can be a RO executable can be a binary can be anything it doesn't really care as long as it does something and the collector same And it you define the input define where it's going to the output uh

destination and instead of uh defining uh the executable or processor, you define a collection strategy, right? Like since you're getting multiple inputs, you want to put that into a chunk something, right? Maybe you want to collect based on number of inputs. Maybe you want to collect based on how much inputs your circus can support, right? Which is uh our case. And uh maybe you want your own custom strategy, right? And that yeah that's also supported and you can define that and again as long as you define your input and your output that's um that collects uh for you.

Okay. So next uh yes let's take a closer look at this example. So I just wanted to simplify this right. This is the very first example. So this becomes something like this. Right? And here I purposely removed the the the cues because uh you don't have to worry about that as long as you define where it's coming from. In this case the the proofs there the input are coming from the execution client and from the collector is coming from the dispatcher. As long uh as long as you define where it's coming to uh the message bus takes care for you, right?

You don't have to worry about implement your own system or anything like that. And again the storage maybe you want to store that the intermediate steps memory local storage cloud or doesn't matter that's also taking care for you. And similarly the second example is going to be very similar but instead it's going to have two layers of proving right the proof compression then aggregation and again the message buzz and storage uh all there handling the orchestr orchestrator handling uh for you. Uh and uh for our use case we have right now we have a few layers of that for our current case but soon we're going to be zkm and I think it's going to be just one layer of proving maybe one layer of

aggregation but we still working on that cool so just to and then how is this any better than what we had before right so just to highlight a little bit more so again let's say on the left we have this tightly coupled system and we want to modify two of the systems right if we do right? Things start to break. Then you have to update your witness mapping. Then you have to update some of the pipelines uh here and there, then you find yourself like spending a lot of time updating this glue code. But on the right, if you do exactly the same, right, uh you want to update the proof system, maybe the aggregation scheme, you have to do exactly that. As long as those uh components follow the business log, the traits the abstraction layer

then um you don't have to worry about anything else. Everything just fall into into place. And uh maybe I'm running out of time I believe so I going to go quick on this one. Uh so the testing framework is configurable, modular, automated and the nice thing about this one is have a built-in uh capabilities meaning you can use the same testing framework to uh run like uh how much memory is using or how much CPU and that way you can test different topologies to see like which one works best for you, which one is faster, which one aggregates more, which I guess which one is going to give you more uh TPS or faster uh uh finalization time I guess. And you can use the same

framework for for both. So if you want to put it all together. So right. So let's say tomorrow there's a new pro system I want to bring it in. Right. So I use the uh choose the pro system first, right? Then I use the modular approver to uh implement the abstraction layer first like uh the the the prover and the verifier mostly. And then uh I use the orchestrator to to come up with a topology. Right? Maybe I want to have a proving uh proving layer. Then of a couple compression or then aggregation. Then again you can choose however you want there and then you can use the test framework to test different topologies see which one is faster if which one is uh works best for your use

case and then using that you choose your best topology and and ship it. So uh some closing thoughts. So um you want to actually scale collectors because when you think about uh collection strategies right like you want to collect based on number of inputs maybe you want to collect based on you have your own use case uh it's not that easy to uh abstract away this collection strategy and um uh decentralize uh if if you will uh because how do you deal with like multiple collectors receiving the same input? You don't want multiple collectors doing the duplicate work and you don't want them to you know uh messing up with each collector and yeah so it becomes a little bit hard to think

when you want to scale collectors. Uh we want to learn our hardware through dispatch collect paradigm and facilitate u distributed proving as you can imagine we have some clients that has a little some more powerful machines. They can uh run the approval for us and uh that way uh we can um um not run everything in house and you can have like proof of proof instead of proof of work if you if you will. So uh some takeaways you know it's very hard to um keep up with Zika research right uh they come and go very fast that's why we have this module architecture uh so so we found a way to to to abstract away

uh the proving system and orchestration which makes us a little bit more agile when it uh uh adopting a new uh a new proving system and we just happen to have uh we just happen to have to roll up and Um, and the the nice thing about dispatch collect you can use for anything as long as you have an executable or you know uh something that collects and just happen to have a a proven system that way. And that's it. I think I have a couple questions. One minute one minute. One or two minutes to for questions.

Oh, sorry. you moving from Halo 2. Oh, well these days the buzz word is KVMs, right? And also to uh Halo 2 uh whenever there's a new um something that we need to modify the circuits is really painful and deploy and debugging circuits is very painful. Uh and so it's just going to make us more agile and um and faster also like we I think are we looking to SP1 risk risk zero and uh once we move there all we need to worry is um uh worry about is the actual orchestration because the proving system is pretty much like a rust program right instead of worrying about circuits. So that's become much easier to uh to

maintain as opposed to circuits themselves. Okay, thank you. You can please continue outside if you have more questions. We're out of time. Thank you.