Lightning Talk: Proof Orchestration in Rust: Scaling Proof Workflows by Mohsen Ahmadvand, Zircuit

Transcript

Proof orchestration and rust scaling proof workflows. Thanks very much. >> Thank you. >> Hi, I am Mosen and I'm going to talk about proof orchestration. So today we heard a lot about ZKVMs and how fast they become. We heard a lot of great news about how things are advancing. I was very excited to hear about that. This talk is going to be about how are we going to orchestrate the workflow. So we have this stream of blocks that are being generated very fast every 12 seconds right now and we want to generate proofs for them in a reliable way. So whatever happens from the moment that the block is created until it reaches the point to the um consensus layer to say this block is valid. Everything that happens in

between needs to be managed by a piece of software and that's basically the orchestrator that I'm going to talk about. So we've been at zerkit we've been working on orchestrators for some time. It's been a bit more than two years. We have been running our workflows or uh proving workflows inhouse and we have faced a bunch of challenges that we had to fix over time. And I'm just going to quickly go over that. So one of the challenges is basically being in time. Real time is not that important on L2. But when it comes to L1, we have this real real time requirement that is in place. It's going to be difficult to do everything in real time. The workflow has to be elastic. It has to scale dynamically with the needs.

So we heard about this gigantic blocks. Imagine if you have a lot of them that are being pushed at once or in a certain short period. Then you need a lot more provers to actually deal with those amount of blocks that are coming in. The third one is my favorite and that's why we all gathered here today is the innovation in the ZK space is moving very fast. Cool new stuff are coming in every day. So we need to build an orchestrator that can change with the pace that the space is moving. Um another thing that we have seen in the production system when we run the orchestrator in production is basically uh the failure that is happening any piece in the system can fail. So a good system a production system need to be able to deal with failures. And the last one is basically being able to run on

different hardware. So what are the requirements? I'm going to quickly go over that because of lack of time. We need something that can do any ZKVM or any prover that comes later. It has to be able to prioritize things when there is limited time. It needs to have built-in fail failover and be able to retry it. Nothing can be forgotten. So you cannot have a request for approving that is lost or forgotten. Uh it has to have distributed coordination, multi-et network, scale horizontally, vertically, redundancy, failover. It has to be able to time out when it's needed. It has to be able to report how the progress is going and it needs to do basically real-time proving. So what is the design? This is the part that I'm that I want everyone to take away from this talk. Basically what we have designed is

based on map reduce nothing new the architecture itself is well battle tested out there. So what what you need to do every piece of your proving uh pipeline has to become a dispatcher. So basically like map. So those shapes that you see over there those are my steps that my prover needs to um execute in order to compute a proof. Then for any step that needs to wait for other steps. So if you have a multi-step prover like the subblock idea that you heard from the SP1 talk those subblocks need to be merged back together and you need to compute a recursion proof over them. So that's where you basically need a collector to collect all the proofs that have been computed in the previous step.

You want to make a new message out of that and then you want to do an operation over that. So at the that's basically how the architecture work. Uh in order to fulfill the other requirements that I mentioned we worked on a basis of a message bus. So any communication that goes through this um workflow of provers needs to go through a message bus. This has to conform to a trait. Right now we have implemented in NATS but it could be implemented any messaging or gossip based protocol that you want to do we are implementing it in traits. Uh so what the message bus was needs to do needs to be able to route work and this could be inside the network you are running could be outside the network wherever you want to route it. So the message bus would be in charge of communication between all the

services you are running. And then at the bottom you have the workflow runner that decides what kind of workflow you want to execute. Let me just do a quick very quick example to take this whole this point home. Basically let's say I have the ZKVMX that has three steps. So I have a rectangle, I have a circle and I have a triangle. In order to compute the proof that I'm supposed to compute, I need to do rectangle and um circle first. So those two can be executed in parallel. So that's that's what I'm going to do. I'm basically going to put two dispatchers together. So I have a dispatcher that starts carrying out the rectangle, the dispatcher that does the circle. Then I would throw in a collector that waits for basically these two types of proof that I require. It would not finalize until the exact two

types exact types two types has received and then composes one message for me and forwards this message to the next component that is going to be my dispatcher and carrying out the final operation that in this case is a triangle operation. So as you can see I can basically with this flexible design that the orchestrator has I can uh design any for any workflow that I need for my proving pipelines. So let's take this basically to ETH proofs. We were looking at the ETH proofs pipeline. So there are uh multiple provers SP1 cyper cube this ris zero all different provers are running there we don't have visibility on exactly how this these BKVMs are being executed what kind of hardware they are using uh we hear about how many GPUs are used we don't know

exactly where they're being executed but we try to imagine how this could be executed if we were to use actually our orchestrator so the idea would be for any of those workflows that these provers have we need to design uh using the orchestrator the workflow that that I explained to you each piece of this operation could be executed on various hardware. So basically you could have a piece of your proving pipeline that sits on Kubernetes bare metal. You could have a piece of your operation that sits basically on AWS managed cluster or you could have your special hardware or a machine or a cluster that has so many GPUs thrown at at that. So even the internal steps of your prover could be broken down as long as all the pieces of the uh of the workflow can reach and

dial one another. um through the message bus that we have everything should be basically manageable. So in the case of running the entire prover pipeline that you have on the same machine it's going to be it's going to be much easier but still um the same idea. So the entire prover sits on one machine all pieces need to communicate. You break it down into dispatcher and collector and basically you have everything together. So for this very example of east proof's website we have put together a demo. You can scan the QR code that you can see on the screen. This takes you to the orchestrator that we have put together and you can try you can see how the demo works. We don't we haven't hooked it up with the uh provers in the background.

It's just mock provers but I'm going to show you how you can basically add any provers to this uh orchestrator that we have right now. The orchestrator the way it's it's working it expects an input that is has to be in JSON format an output. what what is the output of the step and basically if you conform if you put a binary inside the example that I showed you in the demo repository you would be able to um if you put your prover inside with this input and output format that I showed you the prover basically would be part of the orchestrator tool so what are the takeaways so what I showed you here is a universal proof orchestrator it can run any provers on any infrastructure uh and any hardware no limitation on the execution it is

battle tested We have been using this prover in production for a bit more than two years for running our L2 proving needs. Uh it has fall torrent at its core. God knows how many times we had to wake up on call to fix some issue that was in pipeline. So we have put all those lessons learned in into the design already. It scales automatically. Uh I showed you a mock uh demo of ETH proofs. You can scan the repository. You can take a look. Uh we what what is on the repository? We have open sourced the images. So the binaries of the orchestrator are are released. But we haven't released the source code. We plan to release the source code soon. Uh and we are seeking ecosystem collaboration. Thank you very much.

>> Thanks so much, Mosen. Uh final call for questions. I don't have any queued up. >> Very clear presentation. Thank you. >> Thank you. All right.