Keynote: Distributed Real-Time Proving in ZisK by Jordi Baylina, ZisK

Transcript

Okay, our final keynote is Jordy uh from ZISK and he's going to be talking about ZISK and distributed real-time proving. Okay, welcome to the stage, Jordy. Thank you. >> So, hello everybody. I'm Jordina uh from Fisk. um going to go strike uh to the point I mean we have been when we started the project uh our main goal was to reduce latency that's how we started the all the this project and uh here is I think with this what would be more or less a

standard block u this is more or less where we are okay as you see uh when when a block is created u then there needs to be broadcast. I mean this is sent to the to the block proposer. This is broadcast. Then this signet and at some point we get the block and we can actually starting the the the proof time. Okay. Then we have the input generation. We have the executor the witness. Then we have a challenge phase. It's computing the challenge. Uh and then uh once we have this challenge then we have the second challenge and then we have the aggregation.

And finally we need to send this to west proof or to the network or whatever it is. Okay. So and this is you see that the uh the part I mean this uh especially the last two parts these are very parallelizable. So this is where you can reduce a lot and uh uh you can compress a lot just by putting more GPUs and of course there are some optimization spending. The main work uh currently is in the where I think we can still uh have a lot of margin to improve is all the all the part I mean every even from the beginning I mean all the initial states until probably until the executor itself this should be compressed I think here we can pipeline

a lot of things and there is a lot of work there so easily you can see that here we can still earn uh a couple of seconds uh there so this is very much the the an idea uh rough idea of where we are. Of course in the aggregation part there is still some optimizations that are pending but uh I mean currently uh well this is the the server I mean this is a cluster that we built in Jirona. Uh this is 16 GPUs running in parallel. Um and yeah this is the results that we get. I mean this this is with uh 24 GPUs in this case and this is uh six uh I mean this is the average

time of 647 but uh the interesting part is the second one I mean this is a time to proof this is from the from the time stamp of the block until we get the proof the proof of value so we are at at readying average of 9.6 6 seconds and uh 92% of them below uh 12 seconds. I mean this is at the end what we are trying uh to reduce and what we are trying to uh compress uh very much. I think we can go much better with the optimizations that we have. But uh yeah uh just um a comment on this um the GPU uh I mean we are combining GPUs and CPUs. Uh as you see there is this part of execution

there is a lot of part that's running in in CPU that uh uh you want to go fast. So these machines um they have a 5 gigahertz uh speed in the CPU and then have the 5090s okay and combining and coordinating them this a little bit the the trick all together okay so this is where we are but actually what I wanted to to explain now and I want to talk in this presentation is about um building the proof in a decentralized way. Um in order to do that I need to explain a little bit how I mean how the the the protocol I mean what's the coordination what happens so imagine that we have a a let's say a coordinator okay and then we

have a lot of workers uh in general running in different u CPUs and what messages you send so the coordinator starts a proof then of course it passes the input this can be up to 15 megabytes depending on the size of the block but this is all the information by the way this is a proof so It's seen I've seen a lot of the a lot of projects for example um going fast there is a big trick I send this 50 megabytes perfectly generated zero GPUs uh zero time free but the idea the full point of the systems is to compress this 50 megabytes to something that's uh smaller in our case is 250k okay so that's important to know that this is already a proofy there

so what you want to do is actually compress um you get this um input uh this 15 megab byes. Um uh of course this is distributed to all the to all the mean the block okay the the block header. So this is is is sended to the uh workers. The workers actually compute a challenge. A challenge is something very small u something that's around couple of kilobytes. Okay. This is then uh broadcast I mean send to the manager and send it back to all the computations. This is where all the computation actually happened. the the where the the subroof or the the the the the partial proof is generated and then all this this is about 300 kilobytes the

the proof and then this is um of course this is sent to one single uh aggregator that just collects the I mean if you have 24 GPUs you get collect 24 proof and you finally agree this is a very fast way but the important part here is to see that the traffic I mean if you see the quantity of megabytes of coordination that's here is very very very small. I mean workers don't talk each other uh too much. Okay. So this is very very useful because if these workers instead of being in a big cluster they are distributed uh the proof to build the time to build the proof would not would not change significantly significantly. It will be more more or less should be more or less

the same. And this is interesting uh because this allows to I mean this allows not only to build the proof uh c in a decentralized way but also if you replace the coordinator with consensus layer um you can build the proof in a not in a distributed manner. Okay. And I think this is important because um well we'll see later but one of the big problems of u having a big cluster that's running for example Ethereum is that what happen if this cluster stops you say okay you have many okay but what are the incentive to do there so I believe more in a way where the there are some incentive for the proof to be

built and this incentive goes to um let's say to validate I mean to validators to uh roles in the network that they have a single GPU okay there are something a domestic uh a domestic uh machine in there okay so how we embed um so who we will have a debate later I didn't when I when I when I pres when I submitted this presentation I didn't know that would be a debate about that but the idea is who we I mean who pays the proof what but it's not who pays the proof what are the incentives for the prover to be generated. Okay. So well there is one simple solution on that. Okay. Let's I mean it's like you

force you sell the validator if you submit the proof or or or you are forced to submit the proof and then you will get some reward for that. The same way that the validators get rewards for a testing or for proposing blocks they may receive some uh rewards for uh generating uh the proof. The problem of this simple protocol is um it's a pro there's a it's a problem that um so it can happen that one single provider uh generates uh the proof and all the maybe all the all the validators are getting from this proof because it's cheap it's free uh they're getting the proof but what happen if these

validators stops or what's even the worst the worst question okay so say you have back up but then what are the incentives is to run a back up if you are not getting anything out of there. So you need to well it's designing a protocol that way is is is not uh that easy but definitively the structure of uh having uh building the proof in a decentralized and you have minimal bandwidth coordinations this helps. So what I want to show you here is an example of uh what a protocol I mean what a decentralizes I mean what a what a protocol could look like uh in order to uh in order to bre to build the proofs um um in a distributed manner.

Okay. So of course you need to have uh provers in the network the same way that you have validators. It can be the same validator. So you can have a new role. You put 32 ethers and then you are a prover. Prover means that you have a CPU with a GPU. So you have a let's say a gaming machine on there and you will get rewards uh for that. Okay. So the thing is that probably that randomly deterministic the same that we have these committees and that you are selected randomly you will be selected to do some work. Okay, this work would be this could be something like okay you are the chunk number uh 23 you need to do the chunk number 23 of uh of of the proof and this this proofing can be you

can you be can be the chunk 23 of the of a of a of a z proof and a chunk 23 of an SP1 proof or other proving systems in there. So you can have even a distributed way and of course maybe in this protocol you would not be the only one. It can be some redundancy that can be designed it in that. Okay. So once you assign what's the proof you have well maybe can divide it here in three steps. The first step is you generate this phase where you generate you can generate this challenge. Okay. Uh you generate this challenge and then you can have an incentive. Okay. If you are a prover, you you put the challenge and for the fact that you are putting the challenge, you get some reward. Of

course, you can you want to add also some reward to the validators in order to incentivize them to include your reward uh to include your reward. So you to include your challenge in the in the block or in the in the consensus. Okay. Um second stage is okay. All these challenges are are there should be there. um and uh um or the challenge should be computed. And then the second phase is okay, we have all these challenges and uh we uh generate uh we generate u mean which each one generates the the proof. Once you have the proof with very much the same you get some

reward if you are included maybe some penalty if you don't include it or or is uh u or it's an invalid uh s proof and of course the verifiers receive the the proof and in the last um in the last state um well probably all of them can aggregate the proofs and the interesting thing here in this step is that okay you probably get a reward for for submitting this final proof and this is all of them but you can also get a reward for you can also get a reward for your previous subroof being used in the last proof and for also reward for using somebody else proof on this proof. Okay. So the idea is that you can have um a system where I

mean uh you are incentivized to use the others one and uh uh uh uh in in order to to to get the proof. Of course it can be a if this it can be a u step 3B or 3C that this is you don't get an approving there you can extend the time period maybe with lower incentive uh so that uh uh you can you can create this is a simple example I'm not saying that this is perfect this is just an example of a protocol for generating a proof in a decentralized in a decentralized manner okay um of course you can com combine this proof I mean you can have maybe okay the one that's heading gets the proof and the other gets the I mean you can do incentive for central for a

verifier if you do meet the full proof and then this decentralized way of building uh the proof as I mentioned is I think this kind of protocols has a a lot of advantages is prepared for this decentralized uh way and I think that uh this is the way to go I think I don't I want to avoid having centralized um um actors with uh big uh clusters uh running that are necessary to run the the the network and that's very much what I wanted to talk about.

Thank you for listening and I'm up for questions. >> Thank you Jordy. Uh great lead into the panel discussion. So couple questions here uh very quickly. What do you think of Jolt? Well, Jol Jolt I mean I I'm not I have not like deep detail how it works. I know that's something about uh elliptic curves. Um need I mean I need to check but what I uh the thing when the few things that I read is that uh uh the interesting part of Jolt is this big lookup tables. I think this is something super interesting but uh with the starks we have this look up idea and uh we can do things very very very similar. So

when I see the results I will believe I mean I think it's great that there's people trying and we will see at this point there is nothing >> um a good lead into the next uh panel. So are you considering launching a token for the distributed proof generation? Right answer. Uh [applause] what challenges did you experience running an on at least setting up the onrem uh proving club? >> Sure. >> Well, we we it was fun. I mean the the first well a lot [snorts] of a lot of >> would you be willing to speak at an ethof's call on gray market GPU procurement? Look, I I just I I can tell you that uh as an as an anecdote, I mean, just as as a small story, but I I

booked all these um GPUs in Switzerland and I went to Jirona, I mean to went to Spain and I just took the FGO of my brother and uh when I was in the customs, I was just okay, I don't know what's going to happen when they [laughter] see me with all these uh things. So, I was a little bit scared on that. That's I mean this is we learn a lot of things about powering about ACS about electricity how to run how to manage uh we learned that the the the providers uh I mean the GPU providers are really bad the fact that Nvidia don't sells gaming machines to the big uh uh to the big load systems is is is bad uh it has been a real pain and

actually building the the best thing I mean is the the giron was run I mean we built it and was running perfect in the first very much in the in the first uh uh the going with the cloud having to I mean things running on I mean we saw clothes >> limiting the the power of the GPUs just to save some money there or uh um running on top of uh um dockers and I mean know very strange things that you don't have control sometimes I mean do your software is not uh Perfect. And you need to debug and you cannot trust us the hardware. This is a a pain. So we learned a lot on that and I think we got a very very very good experience.

>> Great. So stick around the stage. You're on the next panel. Um feel free to bring the chairs up. And so yeah, I'll give them a second to kind of swap that out. But I wanted to say some thanks. uh this is the last panel and this whole uh event has really been a group effort and required a lot of effort on behalf of a lot of people. So uh I'd first like to thank the dev connect uh team for putting up with a very stressed out um neurotic version of myself. Um, and also to all the dozen or so researchers that reviewed all the speaking applications and really like worked on synthesizing the agenda and making sure that they're

preient timely uh topics that you guys would all speak about. Specifically Sophia shout out really kind of helped crystallize the whole agenda and schedule. Um, and obviously all the speakers and the teams that there's a very very large uh ecosystemwide effort to put this together. Uh very pleased with how it came