Optimizing ZK-Rollups: Unlocking Cost-Effective Proving Infrastructure

Transcript

[Music] All right. Hi everyone. My name is Mosen. I am from zirkuit and I'm kickstarting this uh room's sessions uh with this talk optimizing zk roll-ups unlocking cost effective prover infrastructure.

So let me start by giving a little bit of context how zk rollups work and why the prover or proving infrastructure is actually important. So we have uh the base layer in our case Ethereum and Zirket sits in the middle. Um so from Ethereum you can bridge in your funds. You can um submit a transaction that's going to be included on Zirket layer. You can also interact with zirka directly and uh basically what zirket does similar to um the way zk rollups work uh it's going to submit the da so the list of transactions that were submitted on zirket is going to be passed to the base layer in this case ethereum it's going to derive from it to

you know guarantee the security characteristics that we expect from rollups and it also comes with this unique feature that only zirket has that's the SLS sequencer level uh security that utilizes AI to actually filter out um you know malicious transactions and prevent hacks before it actually happen. So how zk proofs come into the picture? In order to settle um a set of transactions on the base layer uh a proof need to be generated and with this proof we can tell the world in this case Ethereum that hey this batch of transactions that we processed um they are valid and we did everything correct and now this uh state of the chain is

finalized. So um from this point onward things are actually finalized and one consequence of that is that users can basically withdraw their funds from this stage onward. So that's one term that I want to actually make sure uh in this talk we cover it that's the finality and in this case with finality I refer to the finality after we have provided the proofs. So there is this settlement actually happening. Now what's the problem? So I'm going to talk about three kind of related problems here. So one most obvious one that a lot of people actually talk about is proving cost and proving cost I guess

a lot of people talk about the specialized hardware that we need. A lot of people talk about GPUs. There's also another angle to that to the provers. That's the onchain fees. So the fee that you have to pay to the base layer for the DA and for the verification there is also finality delay that is like a technical challenge here. If the proofs are slow if they don't come in in time that basically for the end users means they cannot withdraw their funds and if it this happens too often then Twitter is going to explode with a lot of mean comments about how bad the chain is things are slow. So this is going to erode the trust of the users and the another another angle of the problem is the dynamic nature of running ZK

roll-ups. So the workload um is dependent on the surge of the traffic. So the TPS can increase in the system something happens. So there is you know a new airdrop came out very exciting solution is deployed on the chain. So people want to use it and here opting for a constant design of the system is going to end up you know not efficient enough to handle the load or you're just over you know provisioning um with your prover capacity that you have. So you're going to burn basically money. So there's this dynamic nature that makes it more complicated. So if I were to put it in words what is the problem we are trying to solve? We want to ensure fast predictable finality at sustainable

cost. I mean we can burn a lot of money and make sure we have the finality and we can cover a lot of traffic but that's not what we want to do because at the end of the day the rollup needs to be sustainable. Um and this becomes more challenging with the dynamic nature of the problem. So in this talk I'm going to talk about if you walk away with one thing I would be very happy. Um the rollup cost is not only the prover time that's been something that a lot of people have been focusing on and that's great. Now we have faster provers but pro proving time is merely one parameter. There are more things that play a role here and a lot of design decisions like the TPS that you opt for the patch size hardware um

that's going to swing the cost and also latency and I told you finality is something that people expect to be constant. So if you have a lot of latency that's going to mean um you're going to hurt the users or the trust. So our solution we're going to use we're going to model the pipeline using Z3 constraint language. I'm going to show you some um some ways that we have done to in order to cope with this problem. So let me show you one one example pipeline. So this is one proving pipeline. You can have depending on the proof scheme that you are using which year we are talking um you may have different proving structure. So what is a lot the case in for ZK roll-ups you

have layered proving. So you put your transactions in a block. Uh those blocks need to be proved. Then you put those proved blocks inside a batch. You need to submit that batch as part of the DA to the L1 layer. And then you want to get all get enough of those batches and create a compression proof. And in this case you can see there is a lot of timing involved. So this is a typical scheduling problem. Uh how long should we wait actually to make sure that we are u you know making use of the entire capacity that we can put inside every prover that we have and not be underutilizing them. So there is one parameter here to optimize actually and

then depending on the dynamic nature of the transactions. If you have a lot of transactions you need to provision more provers. So based on the inbound of the transactions you have you probably need more hardware. So there is the need for scaling up and down and accordingly as I told you in the very beginning we need to submit the DA and then once the chain is you know we have the final proof we need to do the final verification L1 and doing the settlement. There are two important things here. So on the left I have finality. So in order for the chain to be compliant we need to conform to a certain finality. uh so some chains up for 1 hour 4 hour whatever number is your change finality time everything that happens in the proving pipeline

need to happen within the range of this finality and at the end of the day all these cost so there are different variables here I'm showing you on this slide is a bit overloaded everything should cost less than the amount that you're collecting from your users otherwise the rollup is not viable basically you're burning money so I try to based on the pip pipeline that I showed you. I have come up with some scenarios um to show you how much would it cost. So I have the steady scenario rollup is experiencing 0.1 TPS. Uh with the model that I showed you, this could cost around 74 grand. Uh I have another realistic example. This is based on um dynamic chain information

token generation event. So for that particular case, the traffic went up to 2.12 in TPS and that would mean with the design that I showed you around 100 grand. And I have another very exaggerated scenario here that the blob fee went crazy up at some point in the past. And on that very specific date if the price stayed at that amount that it was we would have paid 7.5 mil with the same TPS. So as you can see is not only the proving time this L1 cost would have meant the rollup has to bleed 7.5 mil in order to keep up with this very small

load of 0.1 TPS. Another case I have here is the surge when we have 100 transactions coming in and in that case um the rollup is going to cost 2.2 mil uh to actually do the complete end to- end proving. So what's our goal? Basically we are trying to pack more and pay less. Uh we want to in terms of L1 fees we want to do the verification as least as possible but still stay conformant. So do the finality for the DAS. We want to pack more compress as much as possible. Put more batches into one DA submission but still all of this optimization need to make sure that we don't miss the finality and hardware fee

is something that has been more looked at. So we want to make sure we allocate minimum resources but still compliant. So don't miss the finality. We shouldn't have a backlog of backlog of work that has not been processed. This is a typical very very typical optimization problem. So we have a set of parameters. There are different things that we can optimize for. Um and one way to do the optimization is basically constraint solvers. So what we do we collect inputs. There are some constants in our system. There are some dynamic variables also in the system that we have. We collect everything. there is some um technical limits that is about the implementation of the you know our

circuits and zk proofs. Uh then we have some constraints finality is a very obvious one the fees that we have to pay how much budget we have. So those are the constraints that we encode in the system we solve it and then we try to find the most optimized solution for that. So inputs to our system I talked about TPS transactions per second that we have what's the finality you want to have uh how much does it take um to do the proofs for different type layers of proofs you have what are the technical limits of your circuits of your ZK implementation how much does it cost one batch one verification in gas so those are things that are dependent to your very specific underlying ZK model that

you are ing everything has to be passed as input to the model and then the next step is basically building those constraints. So I told you everything should take less than the finality. So we model that the proving time and the waiting time that we have should be less than the finality. So that's something that we put in the constraint system. We have we have a capacity of the prover. So when you design or depending on the circuits that you're using certain number of you know blocks could be put inside certain number of transaction could be put inside a um block prover so there might be a technical limits on how many the same goes for batches and the same goes for compression proofs that you're doing and the costs how much does it cost for

DA it depends on how many DA submissions you do for the verification the same idea uh and at the end the machine cost would be the number of provers you need for the load that you're anticipating and you're passing as parameters to your model u times the cost of the machine that you're going to use based on the deal that you get um from the machine providers. So now I have modeled the system. Let me go back to the same table um with the same constants that I show that I showed you in the previous slides before. Um I'm going to do an optimization here.

And you see I have added two more columns. I have now batch epoch and compression epoch. Basically that's the wait time that I have introduced in my model to accommodate scheduling. So I'm going to wait before doing batching. I'm going to wait a bit. uh and that number how long I need to wait is defined by my constraint solver. The same thing goes for the compression and you can see with this tweak in the system by introducing this epoch doing the scheduling a little bit better the cost has dropped by 70%. So I went from 74 grand to 22k by introducing this optimization.

So I have a better slide that shows the cost reduction. So for token generation event you can see the cost was dropped by 53%. Uh in case of very exaggerated uh blob fee spike we dropped the cost by 71%. So that's we went from 7.5 mil to 2.2 mil and that's the minimum we could we have to pay if we are truthful with finality that we promised. So still with this cost reduction I'm giving exactly the same finality that I had in the first model just more optimized scheduling that I did here.

So now I have this um let me go back to this table. I have this optimization u proposed by Z3 solver is telling me hey you need to wait a bit longer before doing batches before doing compression you need to do it in this way and this is the minimal resources that you need in terms of hardware. How can I trust this? So now I'm if I take into account the surge case. So I need 1,245 just block provers, 30 batch provers and two compression provers. Provisioning this kind of machine that's going to cost a fortune and running it for a month to get the actual number is going

to be insane. Um so what we need to do we need to find a way to see if this optimization that the solver is telling us is going to be efficient or not. Is it going to um prevent any lags in the system or in other words guarantee the finality that we are after. To do that we have implemented a very simple simulator that takes all the parameters that the uh optimizer is spitting out and basically mimics the behavior of the pipeline that we have. So we have a block prover and compression prover.

Each one of them you know consumes some work. So we have created these cues of works. As transactions are coming in we you know put them in transaction pool. they're going to be picked up by the block prover and if the block provers that we have uh provisioned here are not enough then things are going to be um things are going to be slow because we start to create the lag in the system. So we have added some assertions in the list uh to make sure that if uh we have more work than the capacity that we have in the system to process it um then we can detect and say oh this is a lag. So basically the solver what the solver proposed to us is not going to be um working is not going to guarantee the

finality that we have. Mostly we use this simulator to debug the constraint system that we designed. But it's also an efficient way to basically optimize for different objectives. So we optimize for total cost, you can optimize for L1 fees, you can optimize for hardware cost. So depending on the angle that you're after, you can actually try different configuration optimize and optimize in different ways and then pass it to the simulator and see if the results that simulator is getting is the same as what the constraint solver told you about. So now how does it go back to the full picture that I presented to you? So in the very beginning I showed you this proving pipeline and I told you there is some

weight time that we need to decide on. There is a problem of scaling. how often should we scale and there's this problem of DA and verification. Uh so now with with the help of this optimization technique I can have this active agent in my system that watchs the inbound traffic of traffic of the system and based on the traffic basically sets those parameters. So I have weight parameters scheduling I have scaling up and down parameters and I have this uh interval of submitting uh transactions for the DA and for the verification. So those are different parameters that this agent is going to define. So there is this active agent that can fine-tune the system on the go

in order to ensure that we are paying the lowest possible costs and conform to finality and still be viable in practice. This is not going to be as easy as I said in the previous slide. So this means a rollup needs to have this active monitor and that's the chain monitor that looks at um the the current par the current parameters that system has the inbound traffic the blob fee gas ETH price all those things that play a role in the cost. It has to actively look at those things and then we pass those parameters to the optimizer and optimizers can decide on how many machines I need, what should be my scheduling parameters. But

what you pass into the chain monitor is very important here because if I pass you know one moment and in the next moment you know those parameters spike up the gas fee prediction is going to be difficult here. So rather than taking the exactly right moment of um the current parameters of the chain, we need to have a prediction component that looks at you know how much the price the price is going to be for the following batches that I'm going to create. So it's going to be a challenge to solve that is going to be a problem for the future. But deciding what should be those input to the Z3 solver is not a trivial problem actually. So to wrap it up, proving cost for roll-ups is not

trivial. Staying viable is also very difficult because you don't want to burn money. You actually want to make profit. It's not only about the prover time and the machines that you're using. There is this dynamic nature of TPS, L1 fees, machine costs that could make things very expensive. I showed you an example of blob feiking. Um, one way would be to tune the pipelines all the time to minimize the cost. I showed you this optimization technique based on Z3 solver and better scheduling that reduced the cost up to 70% still conforming to the finality that we initially had. Um, so an idea that also discussed very shortly was we need to

find a way to actually be able to dynamically fine-tune the system. That's it. Thank you. [Applause] Thank you very much. Uh we have uh some time like uh two three minutes for questions. Do you have any question? Don't be shy.

Okay. No, no questions. Thank you very much for our speaker. What are the challenges you find with dynamically updating parameters when fine-tuning the pipeline? Yeah, that's a very good question. So the problem is when you fine-tune the uh pipeline for proving. So in 1 second you may have you know surge of TPS. So you're going to say okay I'm going to need 1,000 provers to deal with this surge of TPS but that can very quickly drop. So from you know you may have a few blocks that has you know a surge of

TPS and then it can drop back. So in this case if you don't you know redo the tuning uh for the exactly at the right moment then you basically are overprovisioning. There's there is this challenge that you need to predict the load. You cannot pick one sample and based on that provision rather you have to look at the span of time and do the provisioning. Do you have any proof of concepts already for how you will predict this? Yes. So we have done some live benchmarking for our own proving uh pipeline.

Are you able to share a bit about how it works high level? I couldn't catch that. Sorry. Can you share how it works high level? So we are using it in a more constant way. So we are looking at the TPS that we had over time and then we anticipate you know what's going to be the TPS with this particular event. So we are using it more in a constant setup to provision the system. We are not using it dynamically but we can see that you know the number of provers that we allocate and the schedule that we have for doing the submissions is reducing the cost. Okay, thank you very much. We will wait for our next uh speaker.

[Applause] [Music]