Post-Quantum Interop Call #7

Transcript

Hi folks. >> Hey. Uh, I dropped the agenda in the chat and let's see here. I can share my screen if it's helpful to go over the project board. Um, so where do we want to dive in? Um, Gender O, either of you have updates on the uh, project board? I know you've been taking

a look at it. There's been a lot of work that's been merged. to also we just get an update on the specification >> right uh so I'll just begin with some uh uh some of my views so our uh so our aim is that uh by end of August we are we should be done on spec and O's initial container PR was merged and Then uh it is followed up by my straight transition function PR which uh uh which on which O and uh uh and June and I we we basically

had a discussion and uh it is it looks mostly good but we will definitely you know have a relook basically we'll iterate on it and Toma if you want to have a look at it uh then we can you can also have have a look at it and then maybe we can discuss it. there is some refinement that needs to be done in terms of uh some functions need to be defined uh that have been left out but most but 98% of it is covered right so so so you will be able to able to uh figure out the entire straight transition function we can go through it if we want at this

call uh and uh it has chaining and 3SF as the features uh one of the key points. So do we want to go go over it right now? >> Oh yeah, we can. Yeah. Yeah. >> All right. And before you started as you were given that overview uh before you went to you're working on STF what did you mention was working on?

>> Yeah. So, so basically uh I'm not sure what I was working on but we basically discussed uh the SDFPR and then I will be working on further working on cons uh the fork choice PR which again I will be discussing with O having some calls over it so that we can finalize that uh this is the plan and on the genesis tooling what we realized while talking was that we actually don't need E12 generator because generating genesis state is quite simple from the config itself. So each of the clients can generate uh the genesis state from the config. So what we actually need is ethereum genesis

generator which basically generates the client configs and even on the client config we'll generate just one kind of config uh uh uh so that you know every other client can just consume it because all the clients are starting from zero. So it doesn't make any sense to have client specific configs. So we can just do one config and that becomes a standard for all of the clients. Uh yeah. >> Excellent. Sorry. Yeah. Back to the the STF walkthrough. Sound great.

>> Yeah. So so just let me then uh continue with the overview plan. So the plan is that uh we have the tooling ready by five fifth September in the in that sense the genesis tooling ready by 5th se September where we are able to generate the configs that we need and uh uh in the meantime if uh someone can I think to or o can generate can work on the python code uh then if we have spec test by 12th September Then we can get ready for interop by 19th September. Basically pass all the

spec test by 19th September. uh so that by 26th September we can do a successful interrupt uh for DevNet zero and then u uh by 3rd October we will we should be able to have the tooling up by up for uh DevNet one and in that tooling as well what what we only need is that uh a list of uh public private key pairs for various validators and again we don't need the genesis generator because uh genesis can be generated by uh the clients uh using those config files. So

I will I will think of uh the public private key pairs as config files. So uh so that is the deadline we have and these are super strict deadlines so that uh uh in the interop we can actually try for actual client interop and uh so 3rd September is also the deadline to uh to basically implement uh all the specs that we need for dep for devet Yep, I will check that and let you know what I can do and what I cannot do. But I will definitely check that to start uh

implementing the Python stuff. >> Right. Cool. So with that, let's deep dive into the uh STF spec. All right. Uh I can't share while other participant is sharing also. Generally uh you know my zoom dies when I try to share. So it would be better uh if you can directly share. Well >> sure. Yeah. You want to drop the link?

Okay. Yep. Mhm. >> Yeah. We can go to files. Okay. Uh remind me is my screen still actively shared? Yeah, it looks like good. So you said you have files changed. Okay. Right. Uh so this is just the header that will generate uh autogenerate. Let's go down. Right. So what I have mentioned in the first section is what are the what are the uh features that we are going for.

If you can scroll a little bit up, right? So the features are chaining. Uh so let's scroll down and then uh 3SF mini justification and finalization. There will be uh no uh signatures. So basically it's empty signatures. There is no aggregation. There is roundroin prop uh proposals and there are simplified validators. Uh so that uh basically proposal and voting is a trusted process. uh because there is there are no signatures and uh there is even no validator structure in the state as well. So there is uh no deposit activation, withdrawal or slashing. Uh

so actually there is no validator cycle and each validator has a weight of one and uh yeah so this is that uh the genesis can be generated very easily. So if we go go to the genesis part. So generating genesis requires uh just two config variables which is genesis time and num validators. And uh we have a very simplified genesis generation function based on the lines of how beacon genesis is generated. We basically uh set the genesis time and num validators in the state as well as set the uh latest block header to an empty block header but with the body root of the hash tree root of

empty block body which is how we do it in the beacon as well and then the genesis block is basically you know empty block with state root set to the genesis state. Uh now we can go to the state transition function in the notable thing in the state transition function is that uh we are validating signatures outside uh outside. So in the beacon state transition signature validation is inside the state transition but here we are getting a flag from outside the state transition function that whether the signatures are valid or not. Uh but other things are uh similar to how beacon state transition works. So

basically we have first process slots which basically make sure that you are able uh so we we can uh so we fast forward it state to the pre-slot of pre-state of this particular slot which is what process slots does and then we process the block and uh the last step is basically validating that block state actually matches uh the straight root of the tree. So when we look at process slots, it's very similar to how Yes. Silus.

>> Uh yeah. Why the signature verification is outside? >> Yeah. B basically the signature verification is right now outside for the reasons uh uh so first of all we want state transition function to be light for the prover so so that you know uh there isn't much competition that is going on and second uh uh so the signatures for for the test stations it will be an aggregated signature and uh so basically we need to sort of figure out whether we can run it inside the prover itself itself uh that particular verification because it itself would be uh some sort of a ZKVM running to verify the signature.

So we need to figure that out figure that part out and uh and basically we want to keep the state transition functional light in that manner. Generally the way clients also implement is is that you know they just take the batch signatures in the block they batch it up and then they verify it. >> Uh okay so in in some sense it's kind of temporary outside because it's it's still not sold. Sorry.

>> I mean now it's temporary outside because we just want uh to have a good proving time, right? And once uh it will be figured out uh how exactly the signature aggregation will be done and how exactly the proving will be done likely it will change. it we can come back on this uh but in my opinion I think we should uh just keep it outside the main started state transition function because to keep it lighter but again I don't have a very hard stance as of now because I don't know that part totally fully but especially for uh blocks uh signature

validation for example uh you know that this is now a signature hash verification uh that will happen uh hash signature verification that will happen and it might be computationally intensive. So whether it's good for ZKVM whether it's right for ZKVM or ZKVMs can do it in a fast manner that we can directly have it inside uh I'm not sure about that but yes we can definitely come back on this. Thanks.

>> Cool. >> I think you're at the state route. >> Yeah. So this state root validation is also similar to how it happens in the beacon. Now coming to process slots. Uh so so the notable thing is that we we basically don't have any process epoch over here because there is no epoch transition. So we just process uh each of the slot and move state slot forward one by one. till we reach the pre-state of the current block. Uh so that is uh what is happening. Process slot is very similar to uh how it happens in uh in the beacon uh in the beacon consensus. Uh so basically if we

have latest block had a uh straight route as empty. Uh so basically we just fill it with uh the current the current state route which is the start of uh which is the pre-state uh for this particular block and uh basically this helps us establishing chaining. So so the next processes then we process the block and in block there are two things we process the block header and then we process the operations. Again in uh processing operations we have uh actually processing of the attestation/votes.

Uh that is the only feature we have right now. And in process block header we for we basically do similar things to uh how beacon uh consessors do process block header. uh so they you will notice that uh to verify the proposal index we are just uh doing the round draw in verification that you know uh block.slot modulo stateconfigum validators so that is a notable change over here uh and then the next line is where we establish the chaining that block.p parent root is hasht root of state dot latest block header. So this basic so so this establishes the chaining and uh coming

to the 3SF related changes. So uh so here uh in 3SF mini the genesis happens at slot one but uh we have kept genesis block at slot zero itself and uh block uh block one is the first block in 3sf mini block two is the first block. So basically you know we did some modifications to bring it back to how we how we do it how we are used to right now. Uh so if uh so there is this special uh treatment for that. If uh if uh the state was at genesis state then basically we update it as justified uh and it is finalized to the genesis uh

genesis root which is block.parent parent root because we have already established chaining at this point. And uh then what we do is basically we so since the uh now the parent uh so now the voting can happen till the parent uh so we basically update historical block hashes and justified slots. So just uh two basically you know uh we push parent into historical block hashes and justified slots we we either push true or false depending upon uh whether uh uh the parent is genesis or not because genesis is always justified and finalized.

Uh and then again just to uh if there were any empty slots between uh uh between the parent block and this particular block then we basically add empty hashes for those uh uh for those empty slots or in the historical block hash and also push push false for in that in the justified slots. So that uh to maintain the integrity of these two structures that we will use in 3SF mini and uh then the last bit is to update the latest block header which is how we do it in uh beacon consensus.

Uh then we can move to process operations which is where the main 3SF mini magic happens. Uh please scroll down. So we we process attestations uh we process vote by vote. So one thing to note is that uh in 3SF mini is that you know uh the state has flattened uh object of justifications. So there is a justification map in 3SF mini which basically is a map uh which is a map of uh of the roots to the array of validators that have justified it. Uh uh can you just scroll up back up?

So justifications is a map uh from root to the number to the validators that are that have justified it and basically we uh we go over the latest vote of each of the validators and see which roots they have justified and then try to see whether something has been justified more than two3 by the two-third of the validators. and we justify it and then we try to finalize the source of it. So, so basically then this in in the current state which is SSD state we have this flattered into uh into two structures which are justification roots and justifications validators I think uh but we reconstruct back in memory object

over here uh which is which we we are saying are justifications which map directly to the 3SF mini justifications and then there is this helper function get justification that that that does that. So for uh so that is the only notable thing uh which uh is sort of a departure from 3SF mini. Uh then for each of the votes we start processing it. Uh here again there is an additional condition that I added based upon uh ze experimentation.

uh so that uh if the target is already uh already justified as well then you don't process that vote. Uh but apart from that these are all uh the similar the the rest of uh these conditions are similar uh and these conditions are basically whether you want to process this word or not and uh and if for example this is and there is a vote that is not in justifications map then you basically populate uh that map with uh some uh false entries. So that you know it's like initialization and coming to the next step which is line 254

uh is where basically if the valid data is voting for some target root you basically flag it to true in your justifications map and uh then you count whether how many uh how many uh validators are voting for the target route and if twoird of the validators are voting for the target route basically you justify by uh that target and uh then you clear up your justifications map basically because we because justifications map get reflat reflattened back to the SS state. So you you don't really want to track justifications for the blocks that have

already been justified. Uh so we delete that and then we try to see whether you can finalize the source which is very similar to uh which is exactly how it happens in the 3SF mini and in the end then basically you know you reflatten back these justifications to the SS structures in the state. So get justification and set justifications are the helper functions that we still need to define and we'll fill it up. But uh rest of uh the straight transition function is uh done.

[Music] >> Amazing. like small questions uh not not about the content because I I listen to your presentation and I will go back to the HD stuff to really understand everything by by myself to compare with what I have understood there but uh first question where are you um at the review process do you all clients agreed on on this or is there some points where maybe there will be evolution and where you need to refine and have an agreement. And second question is uh did

you generated did you generate this code using Python and already tested it or you just wrote that into the MD stuff? >> Yeah. So uh with regard to modifications, I don't think there are any modifications that will be required. We'll just need to add uh the definitions for get justification and set justification so that you know we have all the help helper functions available uh so that uh clients can then uh code it up uh in the best uh form that that is suitable to their uh uh you know uh client language. But uh apart from that

I think uh everything is good. What I will also do is I will go and change zim code on basis of this particular PR and sort of reverify uh that in our code that you know everything is working good because uh there I I made some departures from how we implemented it in Zam as well. uh so there are some slight departures because I rearranged some bits over here but uh what I will do is I'll go back and sort of also verify in ze uh the correctness of this code and in that way you know we have uh we will basically have sort of one verification and maybe ream team can also do it in the meantime uh the second

thing second bit about uh uh python uh is that yeah so I basically put it together in the sense but I have not verified that if this will if all the syntax if there are no syntax errors in Python. Uh but mostly this should work work out and uh yeah O and June basically they they will they said that they would be helping me with uh the correctness uh of the Python syntax here.

>> Okay, understood. Thanks. >> Is there anything in containers to review Azure? >> Yeah, container is just this additional structure that was missing over there uh to add block header. But uh it's very straightforward. >> Very cool. That was great. I love listening to this. So now uh the followup to this will be uh the folk choice uh that me and O will sort of discuss and finalize

uh and then uh I think uh the spec wise definite zero spec will be done in devet one in fact uh the spec change would be quite small because all we did all we are we would be adding on top of that would be uh signatures uh and there is more figuring out over there than an actual then basically a very little change on the STF itself because uh uh so signature validation is where you know the things will come up and we'll introduce validators array in the state and sort of maintain it a bit but apart from that uh basically this will very simply translate to DevNet one spec

as well. >> And you had a due date of September 5th for the DevNet spec. >> Yeah. So yes, so we can do September 5th by for DevNet one spec if we can. Uh so so DevNet zero spec is end of this month. Uh for DevNet one we can have the due date of September 5th. so that you know parallel things can be done. Uh and for that basically if we can resolve few questions uh regarding uh key types uh I think that would be good. So so that is the only pending thing that I see over there apart from

the fact that okay you know what what are the exact byes for signatures and for public key. Uh so so those those are the questions I think that are open-ended. as of now. >> So could could you repeat the the questions >> the public key? >> Yeah. So so the questions uh that are so so basically we need two key types over here which is basically uh for which we have also discussed in postquantum group. Uh so one key type is for attestation and the other key type is for block signature and uh so so these are the two two key types that we need.

Now whether we'll have so what kind of scheme do we have to support these two key types and going forward maybe other key types that will come for signing other messages like slashing etc. uh so so these are the so this is one primary question uh that needs to be resolved and the second question that uh needs to be resolved is what were the exact bytes because when we say it's 3 KB so what what is the exact bite number uh that that we can calculate from the params that we have chosen uh not only for signature but also for for example public key that will enroll in the state itself

So, so that that was my second question in postquantum group uh that if public key for so basically the root the Merkel root of uh of uh the cash scheme uh so so what is the size for it if it's eight field elements or seven field elements okay we have over here >> yes so maybe maybe while we are on the screen Um so this is a PR I just opened this afternoon. Um basically uh changing the current the current current container specs uh contain only bytes 32 for block signatures and and vote signatures. Um what I changed here is to

make it more accurately represent um the the actual signature size using the parameters that I think it was Thomas that um merged the specs in for XMSSS. Um but there's still quite a bit of difference here. So I kind of like simplify it to just like three keys here. The path, randomness, and the hashes. Um but if we go look into like the actual XMSSS interface that Thomas merged, it's actually the structure is um right there. Right there actually the signature class signature there. Um got >> yeah the actual signature of like the actual structure of the path the the randomness and the ashes is actually a bit more complicated. uh you have a few inner um inner keys inside these like

paths and hashes um but I I chose to omit this because um for depth net zero we are not actually implementing the signature anyway so having something representing like I think this is like approximately close enough um I think there's a lot more to discuss about like how do we actually represent those um like inner structure inside um like something that's actually SSC um serializable um so I think that's still to be discussed in in def one >> so I have sort of feedback over here in the sense that I would not want a signature container over here because as such with regard to clients basically

you know this could just be some flat byes uh that can be dealt uh and this serialization deserialization can be dealt inside uh the signature library as well Because uh then basically uh block signature which is fixed amount of bytes and then uh aggregated signatures which are variable amount of bytes. It uh so basically the client does not really need to deal with them on the client level. And what we can do is we can sort of have uh uh basically a non-fixed signature size. That way basically you know we can just get away from thinking what is the exact signature size do we

need right now. We can say that okay you know we can have a max list bite list uh over here which basically says that okay max 4k by list we can keep for signature so uh kender's proposal is to just like maybe fatten the signature container entire Right. And then maybe just use like a vector of certain number of bytes like 4,000 bytes or something.

Is is that the proposal? Yep, that is the proposal. Otherwise, we'll basically at least need to differentiate between block signature and aggregated signature. Yeah, I guess like for me that's fine. Um like because this is basically just mock signature anyway. So fatten like ve like vectors sounds fine to me. Easier to implement as well. Yeah. Um I think there was someone else uh who also chimed in.

I Okay, maybe maybe not. So yeah, so so this PR is still open in the lean specs uh repo. So anyone wants to like add their thoughts in feel free to. But I guess like I yeah I guess like a flattened bite vector is probably easier to implement just for def zero and then we can discuss the actual structure for definite one. >> Great. I I meant this for devet one because what what we were saying was that uh can we freeze specs for devet one by 5th September and uh basically to do that uh we can we can work for the

PRs on the first week of September for devet one spec because uh it's best to close out the spec early on uh and for that you know I think even for devet one we should go for you know flat bite as Well, because client doesn't need to know the actual internal structure of the signature and it is good in the sense that uh if for example signature scheme changes in some way or the tree height changes some way uh uh then basically client doesn't need to know anything about that.

Uh so Gadinder, this is the last call before the self-imposed DevNet zero spec is due 831. Uh are there any blockers that you want to discuss or or owe or or anyone else um areas of discussion topics or or things that you know unknowns that need to be resolved? Yeah, I think uh for DevNet zero there I don't see any blockers. Uh or what do you think?

>> Um on the client implementation I think we are good. Um I'm I'm saying this without actually asking the team but I guess like we're we're good. Um one of the concern we had was around the infrastructure for for running the devets. Um I I asked Gom yesterday and seems like he's taking care of that with E Panda Ops. Um so I'm basically like not doing anything at all and I think the the REM team is basically just standing by. If there's any help that you'd like um feel free to let us know but otherwise like we are we are not touching anything on the on the infrastructure side at all.

>> But you will still have to make sure that RE is Docker compatible. >> Yeah. Yeah. Yeah. Oh yeah, yeah, yeah. >> Uh yeah, I had a question regarding this except I just uh forget. Oh yeah. Uh where you guys supposed to get uh Dora to work? You guys being the rim team. Uh I I got this impression, but if it's not the case, uh is somebody is is somebody working on Dora?

Uh actually I was assigned to uh handle Dora but uh I'm uh not that much progress uh is on. So uh and I'm afraid that current Dora uh structure uh isn't fit well in our uh lean devet structure. So, uh, yeah. So, I'd like to, um, uh, I'd like to suggest that, uh, so do we really need Dora at EQ0 right now? >> I think we need at least something like forkmon something like that. So, so we know that uh

basically you know what folks are in the devet and whether the dev whether you know how many clients are agreeing or not. I think that would be pretty amazing to have if we can have that and forkmon might be a very simple tool consider to what >> uh yeah forkmon could be could do the could be good enough for now. Uh yeah, this is uh I mean is this not surprising what you're telling me? Dora is a is a beast. Uh it's it's a great piece of software. Uh but unfortunately it's very a lot of things are uh beacon chain specific. Um and I I had to deal with it with uh with my vocal stuff just adding

a few things. It's uh I mean you you have to find your way around. It's uh once you know it's not that hard but it's it's a bit um yeah it's a bit overwhelming. Uh yeah, if we can just get Forkman to work, I think it's good enough. Uh good question. Where is Forkman? I'm pretty sure that's uh Holy Man who did this. Okay. Uh if I if I find it, I will send it to you after this call. >> Great. Um yeah, there was a question earlier in the chat. Camille, you had noted a while back an interest in uh having a client participate in the

DevNet series. Just curious your current thinking on that and if you're planning to. >> Uh yeah, we do plan to do this. Yeah, unfortunately I cannot be super active as it's basically just two people working on that right now. Uh we're basically finishing up with some uh lip stuff. So just finished the sub integration and uh yeah integrating all of that stuff into the node itself. Uh so yeah there will be basically sub SSD and so on. Um so yeah we plan to do this uh but yeah with but resources are kind of limited but yeah uh the target it's still there to implement. Yeah.

One question that I had uh and I forgot to mention it anyway was that when we take hashtree root or any of the sort of hashing in Poseidon 2 so we are expecting the output as 32 bytes right of any hashing function that we'll use especially 2 in SS Z to I think maybe you you might be able to answer Come on, you're muted if you're

responding. >> Sorry, my my screen frozen. Yeah, your question where like if I if the the signature outputs are 32 bits, right? So can can you repeat your question because my >> no my my question was that uh in SS since we are replacing uh sh 56 hasher by poseidon 2 basically uh so so the output of the hasher remains 32 bytes right we need to check because these are field elements as the output Poseidon. So this is different from SHA. So we need to check

how to do this. I'm not exactly sure how to how to manage this. But everything in Poseidon are field elements. So basically coal labia elements. But of course then we can transform that into into bytes. >> Yeah, I think this is one of the open questions for DevNet zero I guess. Yep. >> Or or do you think that we should move Poseidon 2 to DevNet one and uh just continue devet zero sha?

We can do this as well. This is this is not a problem like in any case like sh is also implemented for the signature as well. So we could even choose sha for the signature. This is not a problem. The final choice would be pos. But if this is a broker then we can go to the sh route. >> Yeah, I I guess for now for SS we can just do short of 56 and uh the reason to go to Prooseidon for that would be to basically make the proving cycles faster. Uh but then that is something that we can tackle later on.

>> Exactly. Yeah. This is your main objective. All right. Uh so I'll just summarize that we have decided to use uh SH 256 in SSZ uh right now and maybe we'll update it later on and at some later DevNet. Uh, great.

Um, I think that was all that I had on my agenda. Uh, Justin, I saw that the call next Friday is on the multi-IG spec. Is there anything that you wanted to ask for from the group? Uh, or if you have everything that you need for that call? >> Nope. I think we're good. Uh, I think mostly going to be Emil and Tomar presenting. Um, and it's a fairly self-contained subspec. So, all good.

>> Uh, Gil, >> uh, yeah, I have two topics I would like to discuss. Hopefully, they're super fast. Uh, one of them is just a confirmation. Um, so I talked to PK about the Genesis PK and or Phillip from from Eastbender Ops about the Genesis generator. Um, and he was just telling me, you know, I I just need a number of because it's roundroin. Um, I just need I don't need the signature uh the signatures at all. Uh, I don't need a tool to to dump the signatures. uh I just need to know uh the number of uh the number of validators and that will be good enough. Um is that still I just

wanted to confirm that this is still the the picture we have uh like this is still what we want to do for for the the definite zero because if that's the case uh then the tool is more or less ready and there's no extra work for us to to achieve. Um yeah can can someone confirm this or uh just uh point me to the right direction so that I can get that to work with uh with Philillip. So on this uh me and O we agreed that we don't even need need uh genesis generator in the sense that we don't need a genesis sz file because >> uh the two config variables that we need

for genesis are genesis time and num validators and that is something uh that we can just pick from the config and >> generate the genesis on fly inside our clients as itself. So in that sense we don't actually genesis generator even for devet one as well >> because why why do we even need genesis generator on beacon genesis because >> the genesis itself is very deterministic and very config based. So >> in that sense we actually don't need a genesis generator anywhere.

uh well we kind of do in whole curtosis uh system to to use curtosis uh but it can be just an empty file or you know I mean we don't have to it can just be a binary that does nothing that that's fine um yeah I just wanted to confirm that we don't need to go through this process of taking in all the transactions to to do the genesis basically but it seems to to be the case yeah uh the second question is about graphana so I have a task uh on my end to like Like O said before, uh I have a task on task on my side to to deal with uh well to to to deal with this problem on uh along with with ETH vendor ops. Uh I want to create an issue. So I already

asked uh people for their GitHub account so that they can the GitHub handles so that they can be given access. Uh the question is that of the dashboard. So from what I understand uh they they are going to run the or devops actually not ETH panel ops devops is going to run uh the graphana instances. We just need to connect to connect to it. Um I just need to figure out if that thing that Mercy has done uh in uh in our current repo is good enough for everybody. So there's a YML file uh I'm sorry I'm on mobile I can't copy paste it but uh there's a YML file that uh corresponds to the gra to

the graphite dashboard and I would want to give it to ETH printer ops or sorry to devops actually and uh they can uh they can actually you know they can run this dashboard. Um, I just want to know if this is something we uh we have on, you know, just on the Zoom side or if uh if Rem would also be interested in uh in adding something. So yeah, I just basically need Mercy and other people from REM to agree on the dashboard and tell me uh that this is what uh you know this is what we want

and uh yeah right quadriium uh I haven't really been in contact with them. So if someone can send them my way because there's also the the question of building the the image the docker image. So uh I did this for uh for Rem and Zim. Uh yeah, I don't have any contact that I can think of at Quadriium. So >> yeah. Yeah, I'm here. You can contact me. Uh yeah, it's I don't know. We can maybe on Telegram. >> Yeah, actually uh do you know how to find me because I have no idea how to Oh, yeah. On the PQ test thing.

>> I can Yeah, I'll ping you. I can find you. >> Okay, excellent. uh yeah so I can also help with this but right so uh we have this uh this format this dashboard uh that I don't want it that I don't want to manage in inside the zoom repository uh so we can put it in a different repository if it's zoom specific but I think it would make sense to uh to agree on the dashboard thing and um and we could all uh yeah I I could go to to devops and say hey this is what we need to build add those people run this instance We're going to send uh to send data to it and uh yeah that would be uh so the ball is in uh every team court to get back to me on

this uh so that we can uh we can agree and I can finally create the the dashboards >> and this is something we want in place for devet zero correct >> exactly well and further devets but yes it's uh it's specifically for devet zero >> okay great Um, so yeah, that excellent. Um, I'll add something to the project board. I don't know if if anyone has immediate thoughts that they want to add to Giam's request uh or if you can just go ahead and provide those YAML.

>> Uh, yeah. So on the graphana uh reim has like we we have our own template uh dashboard template right now but it's it's very minimal like it's show only showing the the head slots justified slots finalized slots and some metrics uh on like the time it takes to initialize a block the time it takes to compute the state route to process all the votes inside the block um and that's basically it. Um, so I I think we have some rough idea of what we want to track, what we want to track. Um, but I guess like not so sure what's the best format like if if you if you already have like a template or

something or or a YAML config, something for us to review. Um, I'm I'm happy to review those as well. >> I mean to be fair, >> yeah, I'm also not sure what we have. Uh but that's why I say like I would like to agree on this so that I can go and create one dashboard. Ultimately we can have as many dashboards as clients but it would be nice to to be able to to check uh I mean I don't know like for uh when we do forks in uh you know in the E land uh we like to compare all how the the the clients are are behaving to make sure there's nothing funky going on with the fork someone falling off the rails and doing this kind of things. So uh yeah um

we I mean okay now there's an issue we can we can agree on what we want we can uh just pull that and uh and see uh you know either the lowest common denominator but at least get the infrastructure started so that we can uh we can monitor what's going on during the the test net and see if something goes wrong. >> Great. Um, yeah, if we could kind of go through the rest of these and make sure that we have ownership for the remaining DevNet zero uh critical path tasks. That'd be great.

Um, O, I think you sort of eyeballed that we're, you know, deficient on assignees. Is there anything that jumps out at you or do you kick us off? Yes. So, so actually um I assigned stuff that I I'm taking ownership of the rest. I think like some of them probably can be close, right? The the one to do with Genesis state or I'm not so sure like the number seven there.

>> Yeah, Genesis state issues are mostly Ze owned. But number seven, we we we decided with over we don't even need because uh this is just pure config and uh clients will be able to just generate a genesis on the fly. So we can in fact close genesis uh this particular to generate SSD genesis. Uh yes. So we we basically need to figure out Ethereum Genesis generator which basically generates the config files that the clients will be able to use to uh read the config and uh so there are three three files I think they

are so these are the files I'm not sure now there are three or four so uh one file is the config file uh and the second file was genesis SS file but we don't need it anymore and the third file file. I think we need is uh the pier uh enr file and uh I think this is pianr. I think this is this is what we need so that we can start uh start the clients in ktosis for devet one. Then uh we'll have an

additional step over here which will be to generate uh uh for example 100 uh key pairs which will be used uh to enroll them in Genesis but for definite zero that that is what we need. >> Who who can own this? This is owned by GM. >> I just Yeah, technically it's PK, but yeah, I'm following that.

>> Okay, I'll note that. Okay. Um >> and then the Ethereum package for KTOS is also owned by Zim. You can assign it to me. >> Okay. >> Or can set up the Docker image builder.

>> I think uh uh GM is already working on this. Uh yeah, it's more I mean it's done. Um it's done except for quadrum, but we're we're looking we're talking about this. So yeah, I think we could um we could close this and when quadrum is ready to go, we will add it. It's just Yeah, it's just a five minute. >> Yeah. So one missing item over there is basically having the CLI to generate the uh PQ key pairs. So that is that is something that we also need uh to add to docker image builder as well.

>> So I'll close that or I'll consider it done for now. Uh plan the reference spec tests. Sorry mercy. uh put the reference >> the CLI is it the same thing that I did. >> Sorry, Gender. I wanted to No, the CLA you're talking about is it the same CLI thing wrapper that I did? >> Yes, this is the same CLI which I asked I asked you that you know generate 100 keys or something like that.

I I have that also in mind about the the CLI to discuss with Benedict is right now on on on early days but to see as this is something that you will all need as a client if this is something that we can add to the rest repo of the signature so that you can just call the CLI from there and don't have to do that on your own. So I I I will check with Benedict once he comes back to from holidays. Anyway, I don't have merging rights on this repo. So, I need him to check.

>> Uh, so I >> client global so that you know we can generate uh public keys to enroll in the genesis state. So we need as global as well as we might might need uh some sort of programmatic invocation by the clients where the clients would uh clients would want to generate private keys uh for some validators based on you know whatever is the starting seed. So right >> I think both both of the forms will be required.

Uh Gaja just wondering would the key store uh the EIP that we are working on would that make sense here or rather than having a CLI tool that would generate uh this plain text which is likely to have issues later on. >> I mean unlike BS keys the key generation of postquantum is quite time consuming and it would be quite uh expensive if keys are leaked right. So >> yeah I so I'm assuming all of uh these keys start with some particular seed which is what we will >> uh for example encode in the BLI key store right so uh in the key store extended key store

>> uh that we basically coordinated on uh but I think what we require for DevNet one purposes is that uh uh a list of uh keys that are gen a list of public keys that are that are generated uh uh for validators and then you know either they are sort of referenced to a private uh the secret directory or to the as well as to the seed that the secret key uh the seed that was used for the secret key generation. So I think uh that is that is the only important information that we need right now both for genesis purposes as well as you know client

basically reading up uh uh their assigned uh validator ids and keys and basically then uh uh you then uh initializing their uh uh key in memory using uh using already pre-generated data file. the pre-generated secret uh directory. So, so I think this would work fine for now, but we should definitely evolve it uh uh to to that particular key store format.

>> All right, let's take up this discussion on the key store separately. U this is fine for me. Thank you. Super >> uh it looks I don't know it seems like the rest of the things that don't have owners right now are can be discussed next next week after the the spec is done. But um what from the time that the spec is done till the time that we're launching DevNet zero, what's the anticipated you know kind of float date within there?

So we were thinking that uh you know uh if the spec is done by end of this month and if we can have when when can we have test cases built on it. I think that would sort of uh be a critical milestone because once we have the test cases then we can check our clients against it. Changing our current for example Z to the current definite zero spec is not hard. It can be done in a week. Uh so the question is that uh maybe can when can we get some reference test because then we'll give one week for

reference test and then next week we can try for inter um and then the devet you know I tried to create at the start of this process like a eth panda opsesque uh devnet spec like one cheater. Is this something that we want to update, you know, going into the, you know, the end of the month and try to maintain these from DevNet to DevNet? Is there a a better process to be able to capture like in a you know, a single index like format? Hey, this is all the specs that were encapsulated in this

DevNet. These are the the tests, you know, the success criteria, so on so forth. Um, I think we can trim a lot of these. For example, like the the top part there about like networking and gossip and stuff. I think that's already part of the lean specs. Okay. >> Um, I guess there's a bit of like project management stuff that's like in the middle. I think those parts can also become part of the board.

so I guess overall I think we can try to kind of like split these into their proper places and um and and and close this one down. I I think >> Okay, >> sounds good. >> All right. Uh, we're a minute or two over. Any parting thoughts? All right, great call. Uh, yeah, Gazender, I really like the format of walking through the spec. That helps me a lot. If people enjoy doing that, I would look forward to u, you know, having a having a section or two that we

go through each call. uh just uh kind of helped get everyone really familiarized with uh not just the details but like you know the the taxonomy of the spec and you know what's where and um yeah I thought it was great. >> Excellent. Amazing. >> See you all. >> Yep. >> Thanks guys. Amazing.