Development Updates: Zeam Client

Transcript

at 206. I'm sorry. Okay. Yeah, that's right. It is 206. We're going to get started in just a few seconds. So this afternoon we're going to have uh some dev updates from the three different teams that have actually started doing experiments uh and coding with the with the with the beam chain and then we're going to have two round tables. One on signature aggregation and the other one on reducing the the stop duration. Our first uh speaker here is Gadinda from Zim and I have a special trophy for him for making it today which is the VDF.

So there's only a hundred of those that have been manufactured. This is a one of 100 NFT. Cool. And um it works. It probably won't be used in in production, but it works. He's lazy. [Laughter] Okay. But soon, hopefully soon, we'll be running in production as well. Cool. U thanks Justin and very excited to be here. Great energy and uh let's uh get into it. So I'll talk a little bit about Zim and uh since uh Justin unveiled the ZK rails for Ethereum consensus vision

at Devcon uh we have been on a mission and uh then we'll talk about phase one of that mission and one of the outcomes of that mission which is Z multiprover and uh the fourth point is uh that we'll also talk about proving with 3SF because 3SF is something that uh we integrated into our uh STF function and then we'll make a very juicy announcement hopefully.

So all right uh so so the purpose of uh Z existence is that uh we wanted to develop a zig lean client beam client uh from the first principles itself because uh we felt that zig was a language which is highly performant and very versatile to build the target builds target uh guest programs uh that can be proven on zigvms And uh so that was one of the big motivation and all of our work you can find us on under blog organization and the zoom work particularly at blog bl/zim

and while uh me and game are the primary uh uh leads of this uh project we have a a very vibrant uh contributor community that is emerging Okay. And uh so let's talk about uh what we have been doing. So our mission uh for 2025 is to build a proof of concept to demonstrate uh uh the ZK rails in action and for that uh we will we have integrated uh uh ZKVMs uh at least one and we are working on many others

and while doing that uh we will be building uh various libraries that are relevant to ZK ecosystem and community. So that by end of the year when beam specs are released we are beam ready and our uh mission is divided into two phases and uh so let's look into what we have done in the phase one which is uh the first six months of 2025.

Uh so phase one uh so there are four pillars to phase one uh and one of them uh so these pillars are building uh building uh building the building blocks and libraries doing straight transition function proving and uh then basically building up uh the zinc client which does end to end proving as a devet and the last pillar is community uh so on building blocks we have implemented uh SSZ which is extendable and we basically aim to extend it with Poseidon 2. Now we are doing optimizations on it but that is not really the focus because uh first first we want to demonstrate the basic

concepts uh on P2P layer we have done some P2P glue but uh there is lot to be done over here especially with uh the P2P networking research that is ongoing and uh and when we will have more clarity on it then we'll see how we can contribute to it but for now we will just use Ethereum researchers are going to turn out over here and by using zig bindings on it. So uh in our estimation this is 80% done for phase one and then uh on uh straight transition proving we have achieved proving and verification with risk zero

and uh uh so basically one of so you need to have straight transition function uh but we went beyond a basic state transition function and pulled from our phase 2 goal and uh translated 3SF uh Vitali 3 SF ministry SF into state transition and we'll talk about it later and uh so we also uh did quite a work on powder which we are now denoting with openvm but uh uh there is still some work uh I mean this work needs to be restarted with uh powder dropping its port for zkm and uh GM mentioned about this in his morning presentation.

So for our phase one goal uh it was to basically at least have one ZKVM probing. So that is done but yes we are focused to get other ZKBMs working as well and uh for for the client which is the third pillar we have developed various modules and uh most notable of them is fork choice which is now 3SF fork choice again translated from vidaric's work and uh then one of the mod core modules uh is proving manager which we'll also talk about a a little bit later. And uh now the goal uh so there are two uh things that are pending for now which we are

focused to get it out which is having a multi-node in process uh devet where basically the chains are building out on basis of 3SF uh straight transition function and then the next step would be to make it a multi-node by having integration with the restly P2P. So again we think that we are 80% done over here and the last bit is community and we are having active u uh weekly calls we have active telegram annex group and we have uh contributors that are working on various uh uh initiatives like zigash

zig p2p and having pose to integrated with our s but uh yes but we are trying to make sure that uh we can get focused outcomes here as well and uh we want to collaborate with EPF EPF on that and start some initiatives there as well. So here uh again we are like 80% done. So outcomes of uh this are intended to be a multi- node net and basically have uh um multiszke proving multi-proving with uh different uh

zigvms and uh then we want to basically also integrate uh proc 2 into our SSD and sort of demonstrate how it will work and maybe also then do some benchmarking on it. But as GM mentioned in the morning, uh benchmarking is not that much of a concern right now because we are focused towards getting the functionality working first and uh we think that we'll be able to do it uh by end of July. So let's look into one of the outcomes uh of our work which is Z multiprover and this is something that you have

already seen uh but again to reiterate we have uh a basic client which basically needs to interact with ZKVMs and run the runtime uh produce proof and sort of verify it and for that basically you need uh you need to give it state input. You need to give it block that you want to prove and then the proof will be generated which will be transmitted over the network and the receiving nodes will also receive the state div and basically verify that in zkms and basically then the you you will be able to even address to the network.

Again going a little bit uh deeper into it. Let's look into the anatomy of the guest program. So you have three components for it which is uh uh which makes a guest program which uh there is an instruction set on which ZKVMs are you can think of that you know circuits are based the brewing circuits are based and then there are proof systems uh and then the third is uh the runtimes which is uh the straight transition functions that uh various third party suppliers would provide to a client or the client itself can come up Uh so we have quite a good uh diversity over uh the instruction sets and uh

major being risk five and uh if you look at it proofs you you will also see MIPS in action. Uh so other uh other instruction sets are EVM, Petra, Cairo, Maiden and all of them are they are different uh ZKVMs who are targeting these instruction sets. On proof systems you have uh binas and plunk 3 as a viable proof systems but uh uh it seems that binas need some more work to make it performant. So most of the proof systems are blank3 but we also are seeing some custom uh backends that ZKVMs are developing like SP1 hyper cube

and then you have the runtime providers uh which most of the ZKVMs might provide a default runtime and then you will have players like uh Zim coming into the picture and providing the runtimes uh to various clients to do the proving and verification. So now let's look at how uh Z multiproving actually happens. So you have a guest program and uh but it's basically not just a guest program. It's made up of a runtime which uh which basically for us is risk 5 uh code that is compiled and that risk 5 code is basically straight transition

function that we have written and with some runtime glue but it also needs an infocation glue uh which works which is to work with that particular ZKVM. So this is where uh multigrewing comes in and this is where uh games work comes comes in which he mentioned in the morning that uh it conceptually it's simple but uh you have to figure out how to hook it all up to make it work and then uh in Zim you have for example multiple different run uh guest programs and you have multiple different ZKVMs that are out there.

And they are all coordinated by something we call proving manager and uh so so that proving manager takes a pre-strait it takes a block and it takes proving opts and then basically it selects or it can do a multi selection as well. It selects whatever ZKVM you want to prove on and then picks that particular runtime, generates the execution trace uh commits and then gives you proof and something that again you can run back onto the verification chain like this.

So as you can see over here this is our manager which basically takes the state block and proving ops and what it does is basically serializes that input that it receives and sort of set uh provides it to the invocation glue which then loads that uh to the ZKVM and uh so this is and that Then that invocation rule then starts up the uh runtime uh in the ZKVM itself and the runtime has uh receives that in inputs from ZKVM. It d serializes it and then

it runs the straight transition function and uh then you have uh out then you basically commit to the output and you have proofs. So uh here uh you replace this openvm with powder but uh this is essentially what you saw earlier as well. So we have uh achieved proving and verification with zero and uh now our task is to move to the next one. uh we did uh uh devote a lot of work uh to powder but uh it is now has it has basically gone down uh our priority list and most probably we'll either be doing picker

picking up with SP1 or with ZISK and uh coming to the second part uh which is the state transition function so what we did was we pulled from our phase two goals And we decided that okay you know this looks uh 3SF looks quite exciting. So we translated with Alex mini 3SF into Zim and for that basically we came up with SSD containers for that uh and then uh translated uh the straight transition function as well as implemented the fork choice.

So the containers for uh SSD containers for 3SF looks something like there is a checkpoint to which there is no epoch now. So there is root and a slot and then there is a vote. What is on a head target and swords and all of them are basically uh the slot root checkpoints and uh you have block beam block uh we have block body where basically you have a series of these votes they are not aggregated as of now and then you have state where you track uh latest justified latest finalized and what roots are being justified and who is justifying them. So uh the roots that have not yet been justified but uh are

in content are candidates for justification. And then uh you then we have an apply transition. Uh this this is our apply transition function which is just like how you do it in beacon consensus. You have process slots. Basically you roll the state to the current uh slot uh and then you process the block and in process block basically you make sure that uh you process the block header uh the blocks parent matches with what states last uh uh block block header is. So, so you do that to make

sure that you know you establish that this is a chain and then uh you do process operations which is where we apply the votes and in the end basically you verify that uh uh the that the straight route that you get is same as the root uh that is in the block and that basically sort of validates your uh straight transition function. So looking at uh how we apply the words there is a bit of uh uh difference from Vitalik's uh implementation because his implementation is about uh uh starting

the uh starting the slot the genesis slot at slot one. Uh so this is something that we did that okay you know uh we we we start the uh slot keep the genesis slot at slot zero and this is some of the modifications that we did and uh that is the other work that we translated and uh basically we wrote up some scenarios to prove and that is something that you can just go to Zim repo and execute and uh it will do this particular scenario coding for you.

So, uh coming back to our mission, we are uh like you know 85% complete on phase one and a little bit on phase two as well. But we are here to make an exciting announcement that uh with all the incredible acceleration that has happened in the ZKVM space, we have sort of updated our target to a more ambitious one and we'll basically do integration which is okay I mean it's not really that ambitious but we will also implement delayed execution to it because we want to do full block proving with EL and CL and this is uh and with that we want to

prove that how link we want to demonstrate how link clients will work without E because the receiving client will not have any E attached to it and will be able to attach to the network without having any ear yeah that's [Applause] Thank you, Gage. I didn't realize that you were doing this big announcement. Any questions for Gajer? I'm just curious, have you benchmarked any of the proofs yet? Like how big are they?

So all that is happening at uh I think uh so that work is pretty cut out for that we will benchmark our state transition functions. Any other questions? Okay, thank you so much. [Applause]