Beam Chain "proving diversity"

Transcript

All right. Uh yeah. So thanks thanks for um getting me up here. Uh very excited to be here in K. And uh uh the funny bit is I was pronouncing it as KHN but then I learned that it is KN. So cool. Uh I'm Gajender uh from Ze and uh we have been working on experimenting with the beam protocol which is which might be reamemed as lean protocol. So I mean beam or lean whenever I refer just interchangeably think that it's the same thing.

All right. So uh what I'm going to dig deep into is anatomy of lean proving. Welcome Gim. And uh then we'll see that how proving is multi-dimensional and how at Zim uh that we have run experiments uh to do multiproving and what are learnings from that and then basically we'll have some exciting announcement juicy announcement relating to what uh we'll do and before that uh I want to get into what is the purpose of Ze. So Vizim was uh conceived when Justin presented his

vision for ZK Ethereum consensus and uh our sole purpose is to basically demonstrate uh the workings of uh that ZK consensus and we chose ZIG for it because ZIG is highly performant and uh Zigg uh basically it's it's quite versatile to produce target runtimes that you can prove in Zikvms. And uh our work is housed under block build organization in the repos and then there you will also find other libraries and other functionality that we have built under the same uh organization blog place and even though me and GM are

uh leading the team but we have uh a very good set of contributors that are emerging and are contributing at various initiatives that we are doing for beam and seam. All right. So again uh let's go a little bit into what our mission is because uh uh since the inception we have been on a mission to build out uh PC's and demonstrate again how we can bring all the parts together in ZK consensus by integrating ZKVMs and uh also seeding the ZIK community with the ZIG ecosystem with the the building blocks.

like SSD, uh some P2P libs, uh maybe hash signatures at some point and so that by the end of 2025 we can be beam ready when we expect the specs to be released and uh our mission is divided into two phase and phase one and phase two and we are 85% done on phase one and we have pulled some goals from phase two into phase one as well. So we'll can say that we are 10% done over there. Uh so now as one of the outcomes of what we have been doing. Uh so I'll dig deep into the anatomy of Z proving.

So the core of uh of uh proving is basically a guest program that is running inside a ZKVM and then you have a client that interacts with it and uh to produce the proof and then to verify the proof. So what exactly happens is that you have state and you have a block and then you give it to uh along with the guest program you give it to the ZKVMS which basically traces the computation and produce a proof. that can be uh disseminated over the network and then on the other side uh the peer will have uh the same guest program and ZKVM and they will verify it and if you

also transmit the state diff they can also create a port post state uh so depending upon what the P wants to do uh it can basically just follow along the chain or just verify the chain or even also uh uh build blocks. So uh now u let's try to see how this entire proving thing fits in a slot. And now I have taken here a 3second slot because that's what we are intending to do 3 second or 4 second in the beam/ lean protocol.

And yesterday also even in the beam day we had a good discussion about uh what slot length we should target. So in this particular slot there are three main uh things that are going on. There is producer that creates a block and then executes the block. So that it has a straight route which is just a commit to the block itself. That is what the final block is and then you transmit that block and then the peers will take that block execute it. uh if it's valid they will add it to their chain and if it's their head they will attest to it and then their aggregator is aggregating the signature and then the the signatures aggregated signatures are then added by the next block producer so

the cycle repeats. So if we add block proving to it and if the proving takes uh it's not real time it takes a lot of time then it's not really useful to the testers or to anyone else who's trying to follow the chain and wants the correct head at any particular point because they would still need to because the proof isn't available they would still need to execute the block uh like all times. So you have to have that the producer is able to prove the block in real time and if you look at uh how uh the blocks

are disseminated right so so here for example there are three three stages to the block production there are three things that are produced and transmitted so it's like three delta and each delta if you assume that computation power is not an issue you have good resources And there is minimal time that is being spent over there. So most of the time will be spent upon uh disseminating the things that you have produced on each of the step. And if you look at gossip sub the current average or maybe 90% of the nodes when they receive the message they receive the message in six hops. And if you think that okay you know per hop you have about 100 millisecond uh and uh then basically you have

multiplied by six but we are trying to figure out how to disseminate faster maybe in three hops two hops or three hops depending upon uh whether we will be able to apply some grid topology to the network or not but uh that is a question still far ahead but let's assume that we are able to do in three hops And then so each delta is like 3 * 100 + 200 * 200 milliseconds for uh just producing and doing uh the other chores that you need to do in that particular step. So you have 1.5 sec that is just uh uh you know spent just producing and disseminating the stuff you don't really

so the time for proving is 3 second minus 1.5 second but if you also have third parties basically if you have non-enshined proofs and there are other people who are taking the blocks and producing the proof and disseminating on the network now that three delta now becomes four delta so you actually have just 1 second to prove the block if you try if you are trying to do it in real time and basically this assumes that you know your proc production and everything else is super fast. Uh but if you have for example PBS in block production there are multiple hops that are going over there. So it's a very very tight schedule that we are talking about.

So, so the real question is can you do real time uh straight transition proving of the block which is basically maybe less than 1 second. So uh so block is basically composed of two things in Ethereum. There is execution and there is consensus. And for consensus definitely you can easily uh produce the proof in under one second because it's quite a small uh small computation that you need to prove but uh for execution there is a big question mark because even if uh we at the current gas prices even if we are able to produce at the current gas

limits if even if we are able to produce uh in proof in less than 1 second we don't know you know we are all trying to go for giga gas. So we don't know that might happen. So so the right uh uh way to do it would be just in time state transition proving which is basically you know you have a delayed execution proving right. So you don't produce you don't prove that particular block in execution but you pro you prove the parent. So in delayed execution you don't execute uh uh so the peers are not meant to execute uh the execution part of the block at that at

the same slot but the parent should be executed and available so that you can verify that the straight truth uh that is coming in the u in the uh execution header you can match it with the parent one. So, so if you have that if the uh if execution is delayed so you have all this time that is available for proving the parent as well. So you don't execute and prove the current uh execution execution uh payload but you prove you execute and prove the parent. So that way you have now almost 3 seconds or whatever the slot duration would be available to produce the proof.

And when you add various uh ZKVMs third party producing the proofs, we get into the dimension of multiple kind of proofs that are being produced and disseminated into the network. And this is sort of what our emphasis has been in the last few months in Ze that how to do multipproving and uh then there are clients which will just pick one of the proofs and they will have basically have an integrated ZKVM corresponding ZKVM and they will just pick the corresponding proof and then they will use it uh to validate the block and the juicy about this is that the

pier doesn't need any e connected to it which gives us lean clients because you get the proof for the entire block both consensus and the parent execution payload which is how things will happen in delayed execution. So with that you will get lean clients and even with APS things are not going to change that much so the story is still going to remain the same. So let's now dig a little bit into proving diversity.

So you have so the basic building block of proving or the basic component that you need for proving is the guest program that you will run in ZKVM and it is composed of three main things. One is instruction set uh second is proof system and third is runtime. So you have quite a large uh diversity in the instruction sets. Uh so basically you know we have risk five we have myips already working and producing proofs in uh on e proofs website. If you go basically you can see all the data. So we have two working instruction sets already but then there are other

instruction sets like EVM uh some ZKVMs are trying to just directly target EVM and then there's spectra Maiden Cairo valida and but we don't have so much diversity on the proof systems because uh most there are two major proof systems over there like binas and plunky 3 but most of the zkvms are working on plunky 3 because binas is not turning out to be that performant. uh maybe things might change in future but uh what is also happening is that all the ZKVMs to target uh to they are chasing the performance and in that they are also developing custom backends and

proof systems like SP1 hyper cube and then the third uh component is the runtimes basically which is state transition functions and here uh most of the ZKVMs might provide a default state transition ition function that might come with them and here the new players like Zam will shine through providing these runtimes that are integrated with various ZKVMs. So the first two components basically that is what your ZKVM is deciding and then the third is a runtime paired with the ZKVM that your client might decide or might give you the option to configure for.

And looking at it proofs uh you can see that there are various ZKVMs which are trying a combination of instruction set uh that are there and uh and and although I think in ETH proofs right now two of them are integrated right now but many many others have plan to integrate with ETH proofs and it proofs is sort of uh the place it's sort of out to beat for these ZKVMs And uh from that we can see how ready the ZKVMs are for the ecosystem.

Okay, let's get further into multiproving. So in Zim you have multi you have this uh Z multiprover and again it takes a guest program and the guest program is uh uh guest program is consu uh is uh constituted uh by its runtime which for example might be compiled to a target uh instruction set risk five or whatever that is for ze right now it's risk five and then you have some runtime glue an invocation glue that is very specific to the ZKVM that you are trying to prove with and you have multiple such uh guest

programs which are basically compiled according to various ZKVMs that you have. So in Zim we have these multiple gas programs that are built and are available to the proving manager and the proving manager will basically take the straight. It takes a straight it takes the block executed block and it takes some proving opts that you can basically select uh which ZKVM and which guest program you want to prove with or you can just also do a multi select. And here you can see uh our interface where you call into proof transition which basically serializes uh this data to give it give it to ZKVM and calls the invocation glue which is

this and then it goes into the runtime glue where you get the inputs from the ZKVM and then you des serialize them and run the straight transition and then commit to the outputs and uh so our work in our work we have successfully run this cycle with risk zero and we have also devoted quite a bit of effort into powder which is now deprecated. So that line is sort of now replaced by openvm because powder is now openvm and uh uh but now we are right now targeting this as the next step.

Uh so coming to the juicy part of this talk so with all the acceleration that has happened that has happened. Uh so we have basically sort of uh updated our target to a more ambitious one and our phase 2 mission is to have an E integration which is all right. I mean it's okay everyone everyone can do it it's not really a big deal but with delayed execution that hasn't happened yet in the Ethereum ecosystem. So that is one of the EIPs that is being championed for Glamsterdam. But here we are saying that okay you know we'll go after it to do full block proving as we have talked

about in our uh talk with a zig invocable guest and this will give us demonstration of a lean client where there is no e. All right thank you. [Applause] So do you have any question for Arley? Have you thought about proving D protocols? Which protocols? DAG based where you have a DAG of blocks and some of them are uh parallel. So not it's not a sequence of uh of blocks that uh fit into a single chain all the time. So so basically I mean uh what you're really saying is that what kind of state transition function that we are proving right? No, I'm saying suppose that

suppose you have blocks that are created concurrently and they're order ordered later. Um you would need to assign the approver of each block before you know the total order. Have you thought about this direction at all? We haven't thought about it because we are focused on what Ethereum uh path for that is. But essentially even if that would be there uh you would first prove each of the individual bundles for example and then you would prove the order right. So at some point you will have to order them up and prove the order as well. So if you have a recurs recursive proof I think that uh you will be able to solve that problem.

Another question we have time for one more. All good. Okay. All right. Thank you. Thank you man.