Post-Quantum Interop Call #14

Transcript

or we're at three after this is peu call number 15 I believe I'm correct anyway it was 14 or 15 I can't remember Um, let's start with some client updates. Uh, maybe Zen, you want to kick us off? Hey guys. Uh, so on Zim front, uh, we have been making good progress. Uh, we already implemented PR67.

So it's still under review but we are almost there. We have also uh worked on implementing uh the lean spec PR uh so that we can consume uh the test formats uh and that is also under review. Uh another PR that uh we are working on is integrating the signatures and uh there is another PR that we are working on uh which is uh basically syncing uh the parent chain. So these are the things that we are working on.

Uh apart from that uh uh one of the team members is working to uh uh to basically integrate uh uh integrate the sign uh the kpa generator to the lean quick start. Uh so I think we are making good progress on all the fronts. Excellent. Thanks, Gajer. Um, ring team.

>> Yeah. Um, similar front there. Um, so glad that the the the first like DevNet one specs PR is merged uh last week co-authored by Kajinder and and Great Papa. um was a was a big PR so glad that was uh merged. Um so we are implementing that. Similarly um we are uh also so there is one open PR right now for the signature container uh that's already in the lean spec. There's a bit more updates that needs to be done but uh feel free to review the structure there. I think the the structure is there but um like minor details like instead of like fixed values um referring to the X XMSS config stuff like that. Um and yeah um so I think the next uh next

part is like signature integration. Um and just to add on I have some concern around um the infrastructure for DevNet one. Um basically I think like we we it looks like we need curtosis or some form of that. Um we definitely can't do in a single machine environment like we did in DevNet Zero. Um, so yeah, I'm not so sure if if uh we have any kind of like updates there and um yeah, at least from from be team like Jun and and me can help out with the curttos stuff as well if there's work left to do.

Uh is ktos is running on a single machine or it allows us to kind of distribute on multiple uh entities? I think the point of ktosis is to have it uh I mean ktosis generally runs on single machine. Uh I'm not sure whether I have used ktosis to run it on multiple machines. Uh but in that sense uh I think lean quick start generally covers it. So if we are intending to go to a public devet for devet one I mean obviously after we have done some rounds of same machine testing then probably

kosis might not be the right tool. Uh I think we will need to integrate into some anible or something like that. Um question are you saying that the your lean quick start um works like it can do multiple machines as well? No, the start doesn't do multiple machines but uh we can integrate encry is integrated then it can spin up uh it can so we can basically add uh add uh

enable command to uh create uh the processes on different machines. Uh I'm not sure whether Ktosis is able to do it but we can get it done through lean quick start for sure. Oh, >> but uh what what we are targeting I I think initially we will just be targeting uh same machine for a couple of rounds right to make sure that we are we can all interrupt uh and consume each other's uh produced block and uh at a stations and uh then I think the next step could be that we can try to uh integrate

enible and uh create these processes onto multiple machines. Can that be DevNet two? >> Like have DevNet one just be focused on the aggregation in a single machine and DevNet 2 aggregation and factor in this uh multi- machine additional complexity that you're talking about. >> Yeah. So there is no aggregation indefinite one. Uh maybe you you're talking about something else but yes uh I guess we can do that. uh but I think it would be good idea to anyway start building the infrastructure to spin it on different machines. I don't think it would be that complicated once you have anible uh integrated machines and

basically anible configured to run commands on that because the way lean quick start works is that it basically takes the config from uh the supplied config that you have in validator config. So there is just one config that you have and then it's able to generate all the files that you need to start the clients and I think what what we just need to do is basically have the appropriate IP of the machines that will be linked to each of these nodes and uh I I think we should be able to spin the nodes using anible as well. So I don't think that it would be that great of an effort that we can actually start trying

it right now indefinite one. >> Um regarding the curttosis um personally I'm a fan of curttosis and all the docker based tools. So uh I'm quite suspicious about the uh shell script based tool. Uh so uh to my understanding link kickstart also supports docker but it's all written in shell script which think it's not scalable in my point of view. So um what if we bring Curtis's package uh in a in a couple of weeks and then we can discuss about the uh feasibility of those tools later on.

we can do that. Uh but I think it will be easy to also wrap the shell script fully in quick start in a docker itself. So I mean uh if that is the entire point but any case this uh script is to orch orchestralize containers right. So I'm not sure it actually needs to be that scalable but in any case we can wrap it up in a docker container as well. Uh maybe clean team Camila you have updates that you would like to touch on?

>> Um yeah maybe smoothly discussing also regarding the deployment. Uh yeah on on our side we were experimenting with shadow. Uh so we managed actually actually to spin up a network of 256 uh clean nodes of DevNet zero version. Um yeah we tried we're trying to scale it to like 1,000 nodes. Uh yeah so for 256 it actually works fine. for 512 we uh we noticed some I'm I'm not even sure like whether it's most likely it's issue on clean side uh but yeah for some reason the head stops

growing uh yeah we observed some issues with vote messages so trying to fix this um yeah maybe just temporarily yeah something like shadow might be a workar around but it's not a perfect thing I I for these kind of deployments because for example in shadow uh if we for example simulate signature signing or signature uh verification from the perspective of shadow it kind of happens instantaneously. So like it like pretends that it only took 0 milliseconds. Uh if we just take a time stamp before verification and after it it would return the same time stamp for

example. Uh that's kind of like how the shadow works because it's mostly was developed for networking. But anyway, um yeah, just trying to do some experiments there. Uh again, speaking about experiments, also we quickly just updated our beam chain simulator uh with WFR gossip because it was just not very complicated. Uh I can maybe even share uh the graph somewhere. Yeah, maybe after I stopped reporting. Um we noticed some minor improvement with WFR gossip comparing to gossip sub still uh not as performant as grid but yeah um was interesting to see that also I I contacted uh Thomas who is uh who was presenting link P2P in Cambridge uh he

said that it makes sense to also test the sum uh they recently published a new article so yeah we'll try to introduce this into be simulator simulator as well um and finally going through the clean itself. Uh yeah uh not much development uh for the past week. Uh yeah we just introduced a lot of metrics with the thanks from Katya. So uh yeah uh that's I think uh yeah that's I think only the only development item that we had during the week. Um yeah that's all from my side. Thanks.

>> Thanks Camil. Um may lantern update. >> Yeah, thanks Will. Uh hi everyone. So basically last week I was trying to work with shadow um like but last week I implemented uh gossip sub uh in cely pup and I was trying to uh get shadow running uh so I could like verify um like the interrop test for passing with go pe and rustly pup. Uh but it uh I ran into some uh issues building shadow on my computer because um I think it only supports Linux. So I tried using a Docker container but uh still had some dependency issues. So um because of time uh I actually ended up getting a

different route. Um so I ended up uh actually implementing uh the DevNet zero specs um and in in a actual dedicated repo. So um like the link I shared that's like the repo of lantern uh uh which is a C implementation. Um I think the core implementation is done. Basically at the moment I'm trying to use uh ream team's uh local pq devnet repo uh to run the devet zero locally and basically uh enable trace logs and iron out some of the connection issues that are happening. Um so I'm just making iterative progress there. Um basically once inrop is working um I'll

be uh focusing on implementing uh PR67 for devet one and um and then focusing on bindings for the uh the signature library. Um yeah that's that's pretty much the update from my side. Y >> thanks Mir. >> Yeah thanks. I just u u mir was mentioning that uh yeah he was struggling with running shadow um in his environment. Yeah we also went through that uh I I I tried everything that I could to actually test it on my MacBook but u even in docker or anywhere uh it was not working. So the only way

it was working is when we were testing this in IMD64 U Linux environment. Uh so yeah keep this in mind and al also uh for gossip sub yeah when you will be testing please also not check the configurations uh for the gossip sub that we have for the dev net zero because yeah in cambridge we were as you probably remember was struggling with mostly configuring coip sub properly on our side we also kind of had coip sub compatible with rustly pp for a very long time but when we actually try to interrupt with Zim and Rem. Uh yeah, there was some configurations issue

which we yeah needed to fix. Um I'm just saying that if if if something is working uh in uh interrupt test for lip, it's not like 100% sure that it will work in DevNet zero. So yeah, just keep in mind this configuration thing. >> Yep, sounds good. Thanks. Um and I guess just a follow up on that. Uh is the gossip sub configuration that is currently in uh lean spec um is that uh was that changed in Cambridge? Uh like u I can definitely look at the um the conf the configuration that was configuration parameters that we used in ream ze and clean and then use those rather than lean spec. But yeah

>> um I don't remember to be honest. Yeah. Yeah. Maybe you can check uh to be 100% sure like reim or clean. Uh >> okay. >> Some code here. >> But yeah, probably no changes. Yeah, >> O in chat. No changes as far as he knows to the Gossip sub spec. Um, speaking of specs, any updates on specs? Tamar, I saw you just merged a big PR yesterday, I believe. Test factors.

>> Yeah. Um, yeah, I can give like a a quick update. So, in general in the LINS spec, we merged like couple of small peers in the last week to fix some bugs and stuff. This is quite good because we can see a very nice dynamic with a lot of peoples from various client teams submitting some PRs to fix bug to rearrange stuff and all of this. Uh we have also a nice movement with small PRs being merged very frequently with small iteration. So that is good to see and also uh yeah yesterday I merged this very big PR from

Filipe. This is a very good work. So that now we have uh some test vectors uh inspired by uh the execution spec stuff and the consensus learning that we had in the past. Um if Filipe want to say a word this is he can but in briefly this is a way for client teams to consume these test vectors and have a very clear testing framework for them to test against the Python spec. Up to now we had just very basic Python tests that were not okay to be consumed by client teams. Now we have a much more structured way for client team to

consume the test. So now my work will be to uh use this framework for all the tests progressively. So for example I will first try to replace all of the four choice tests by uh their equivalent with test vectors and then of course we can iterate on the design there. uh if you have some concern comments improvement don't hesitate to submit issues or PRs on the repo but this is a very very good base the PR was very big and again that this learned from all of the past that we had in Ethereum with execution and consensus spec so that is very good very modern very pon pyonic and stuff so yeah this is a very good

work very good PR and I hope that from there we will be able to to iterate over there so If Felipe wants to say a word about this, please feel free to. The floor is yours. >> Yeah. Uh you covered it pretty well. Um I I implemented some some of the um framework that for for test uh vector generation that that we've learned from execution specs. And we actually just finished um merging uh the testing framework with the specs on the execution side. And so it looks very much like this. There was a lot of uh inspiration from this last week where we've been merging these PRs

or these uh repositories. And so yeah, uh setting it up as a package and uh if you haven't taken a look at the PR yet, I hope it's pretty straightforward. Uh, I think the UV workspace allows us to run these commands from the root and um, yeah, I I think this is like uh, a pretty solid base, but um, uh, it's it's definitely going to need to be built upon and and it'll it'll take a lot of contributions from everybody uh to kind of find the right test vectors uh, the right fixtures to generate and all that, but um, we have a yeah, we have a pretty solid base uh going there.

Fantastic. Nice work both of you. Um any other spec related or research related things? Yeah, I want to talk about uh PR 92 which is about uh which is the PR I think Von put up to uh basically structure the signature. My question is why do we need it? what are the benefits I think we get out of it because uh obviously this adds a little bit of tech depth into the entire thing and the breaking of the abstraction layer of you know uh the spec needing to know what the signature exactly look like.

>> Um so maybe I can uh answer that question. So uh to my understanding the signature generation is not deterministic in hash. So uh the randomness randomness value which is ro uh in the signature container is uh quite important to uh de in the debugging context I think. So uh yeah so >> right >> so signing in uh in hashtag is deterministic like we dandrandomized it with some PR >> okay

>> a while ago it's like signatures are not unique but that's a different thing I'm not sure what you need like you can have like the scheme is deterministic but the signatures are not unique >> I'm not sure what you need Yeah, but I'm strongly against exposing details of how the signature looks like to to the outside. So, I think the signature should just be a some object that you don't care about how it looks inside. >> Okay. Uh, thanks for correcting me. Uh, uh, okay. Um yeah, then I yeah if if that's the case then I think we should collapse the the

signature structure back to bytes. Um but just quick update. So from from Benendix's answer um earlier today um the signature size is going to go down from 4,000 for down to down to 3,100 again because um originally I I yeah so so from the workshop we were kind of like expecting that the signature size will go up but uh since the the code there basically that the changes there are not there yet. So I think we'll we'll you know how to revert and go back to like 3,100 bytes.

>> So I think the right thing to be do to be done is that instead of having that as a bite vector of 4,000 uh we can just have it as a list of 4,000 which would basically allow for you know any of the other changes that can happen in near future. >> Yeah. on on that though, do we actually need that since like each change is a is a fork anyway and we're not Yeah, we're not building on previous signatures. So, I mean like previous blocks from past defense if you know what I mean, >> right? I mean, uh I'm just so I guess we can just have 3,000 byt vector as well.

So, I'm not really opposed to that. uh but I mean if there are many other changes coming in basically it would sort of decouple the spec and the signature library with that regard but I am fine with uh a fixed size 300 byt signature as well but in any case when we move to aggregation that would anyway change so yeah whatever is most convenient >> can I share the screen like one second I think.

Let me try to share >> first. >> Let me try to share this. So yeah, can you see the screen? >> Yep. >> I I think that um in in the XMSS uh folder inside the the lindspec in Python uh I didn't update with the last with the last stuff that we discussed after Cambridge. So there is a bit of tech depths when compared to the rest repo uh that here we have the status before cambridge but I guess Benedict please correct me if I am wrong but I guess that the signature object should be this

one at the end right >> where we have the pass the randomness and the hashes right >> yes I think so this is this is true uh I'm not sure if Like the rest of the spec needs to know these details. Like sure that the part that specifies how you verify signatures needs to know that but the >> the rest of the spec should just say verify signature and call this in a blackbox way without opening it up. Yeah.

Yeah. That's >> this is all goodation but yes uh I agree that rest of the spec can just uh delete as opaque bytes. Yeah, because in like in rust so that is equivalent that we have in rust we are exe execut ex exactly the same fields. So the path row and hashes but we have this um derivation of serialize and d serialize. So we can just transform that into bytes and this is okay right so we just need bytes at the end >> that's correct >> okay so

but I'm not sure that in fact like the the PR that you open the number 92 if this is not just basically like kind of a copy and paste of this right or some kind of of stuff related to this. No, because I think that you have exactly the same field inside what you mentioned in the in the in this PR, right? >> Yeah. So, so this this needs to be changed based on making it opaque. So, we won't have this structure anymore.

But um just for what it's worth um when we opened the PR we had this when we had this structure we had to to create a a mirror of it because this is not SSC compatible even even in the Yeah. So so that's why like we have that middle ground but then if we are treating it as opaque then we should get rid of the entire structure. >> Yeah. Yeah. Yeah. Okay. Yeah. Here you like in the repo I have put like the XMSS spec with all of the of the detail there to have like a mirror of the rest spec. But in the end you never need this like you can completely forget this this XMss folder almost like the only thing that we need to spec is the verifying of

the signature but the rest you can completely forgot like no need to take care about the hyper cube encoding details. The only reason why I have put like the XMSS spec is just for us to be able to run some small tests, be able to tweak a bit the parameters, check what we are doing. But as a client teams, you don't need this one. >> So you can just treat treat them opaque, >> Maybe maybe we can have this as a separate uh python uh uh library and something that perfect integrated in the spec.

>> Yeah. Yeah. My goal also was for example here if you check in the subspec you have SS and this is not good to have SSD inside the lean repo because this is just a separate stuff. Right now I keep that the here as convenient stuff because we frequently change the stuff and the the types and the way we are doing ponic things. So I just keep that for convenience. same for XMSS. But in the future, I agree that we will be able to create some subreo for small part of this stuff that are not meant to be in the in the final spec repo. Yeah.

any other spec related updates and or research? They just uh want to update that uh from Zam team will be doing a PR to add uh add the signing and verify the signature. So yeah, this is something on Zim's plate and we are working on it. >> You mean in in Zigg or in the Python repo?

>> In the specs. So that uh right now the PR61 had signatures which are zero bytes but we want to put in the uh actual signatures and verification over there. So so uh basically we will also implement it. So in both cases, yes, >> you have like uh again like in the XMSSS folder, you already have like the verify uh algorithm. So you don't need to reimplement it if this is your your point.

>> Right. Right. So we'll use it uh from uh what is already there. if uh uh so from the conversation that I heard that if that needs to be refreshed uh >> not sure about the verify I don't think that the verify function need to be refreshed don't think so >> but we'll also need to add uh the signing function as well because >> yeah the signing need to be refreshed not redone but refresh so we can check like the very last PRs of the rest repo and just mirror that in in the Python spec, but this is just a refresh, not a full read on.

>> Great. So, uh, who would be doing that? >> Yeah. >> All right, cool. >> Um, just double checking Kajinder. So the upcoming lean spec here are um that's that's going to just focus on just integrating the sign and verify function from the XMSS right and no other like changes >> to the like function. >> Yeah. So I think there will be two PRs where one Toma or someone else would basically refresh uh uh the XMSS code and if there is any refreshes to be made

and yeah the other PR would just be to use those and instead of now having zero signatures we will have actual signatures and uh do the actual verification. >> Yeah. Yeah. Of course I I can do the the refresh al so like there is no problem on that but yeah I I forgot to ask Benedict but I I wanted to check the amount of stuff that we will need to modify again in the future like to avoid doing many refresh but just one refresh.

So, but I think that right now we are quite stable on the change that we want to make ex accepting like the the new encoding scheme but this is not something that will be done very soon. So I think that in terms of new feature after Cambridge we are quite good. No. >> Yeah. Yeah. >> So we we don't even need differentship the current code is correct and accurate right. So if it works then basically you know refresh can come later on as well.

Yeah, also yeah, I think what is important is that the the interface like the API of it is consistent with uh with the Rust report like the change the API change that we made after this top tree top bottom tree traversal thing. >> Yeah, that is not done in the in this in the Python. We need to I need to do that. This is the only thing that I need to refresh.

Uh in the chat here is asking for the test vectors and lean spec will the SS snappy encoded objects be in scope for the future in the future for different message types such as those submitted via request response and gossip sub. I think the consensus specs only generates tests for SS and beacon chain state transition state transition functions. Let me check.

I I think just giving my two cents we should add because uh while deving for lots we had just come across few issues uh with decoding the request response messages. So I mean it would always be helpful to have a spec for it where everyone can just verify. >> Yeah, we can we can Yeah. Yeah. Yep. Sounds good. Yeah. Great. Um, Bo, I saw you closed a number of issues in the PM repo last night. Thank you. I don't know if there's any quick update that you wanted to give on on that.

>> Uh, yeah, sure. It's um it's very housekeeping. Um, nothing that we haven't talked about. Um, but if you guys want to have a look like there's a board that we used like some months ago to track of things. So I just went through all the tasks for PQNET zero and it looks like all of them are closed off. So so I I closed that milestone already. Um, and for PQNET ones um there were some stuff that were out of places so I just reorganized them. But yeah, so mainly again like if you look at the the lists in the board right now it's mostly just the signature specs.

um verifying the signature compatibility um test vectors um and then the rest is basically just the infrastructure stuff to to run the the dev one um yeah that's it shout out to O for the uh DevNet zero bootstrapping lean consensus summary that he put together um really nice little document Um, any other updates, questions?

I had maybe we'll start a section of the call will learns in public and I can just like ask all my questions that uh I'm confused about. Um, some of the tooling I would just love to like get a little better sense of if someone could kind of like left curve for me. Okay, we talked about crytosis, anible, lean, quick start and shadow the network simulator. Like how do I understand better as someone that's not technical like when these are being used? What the is there a desired path? Are we currently using one and the goal is to like try to graduate to another set or are they used for different uh types of analysis and simulation?

I can maybe briefly tell about shadow just to start. Uh yeah it's useful when we need to kind of model the uh networks with different latency bandwidth or uh simulate packet losses u and have just reproducible uh environment so that yeah every time we have basically the same uh tests I mean this even the hashes of the blocks will be the same every time. So it's useful sometimes to just if we had some bug to kind of reproduce exactly the scenario that led to this bug. Uh yeah, but it's kind of uh it's it's it's it's

realistic in network sense but not super realistic in terms of performance as I said like for example I don't know snark verification or signature verification uh would look like kind of inst instantaneous operation like kind of would kind of from shadow perspective it will happen like just in zero millconds Uh so yeah just to keep that this in mind. So it's most of networking tests. >> Thanks.

>> I guess like yeah I guess I can add to the like anible stuff. So basically like when we like when we look back at defet zero right what we what we wanted to test is basically having three clients talk to each other and you know no signatures or anything like that. So it doesn't really take a lot of resources or performance from your laptop. So we were able to do it on a on a single laptop, right? And by doing it in a single laptop, it's easy because you can just basically like write some simple script say that hey spin up you know two Zam clients, two ream clients, two clean clients and you know basically make it talk to each other within the same machine. Now the thing gets more complicated when we want to get into testing a distributed

system. And what that means is that when you start to want to test having different machines that might be close together or might be distributed across the globe and you want them to talk to each other then before you're actually able to test you have to set up the machine right you have to set up the OS right Macs or Linux or whatever then you have to install all the software you have to download the code and so on and so on and configure everything right before you can start it up and so in order to do that usually if you're going to do it manually then you can imagine that that's going to be like really painful work because then some machines break down some machines don't. So the way that

a more natural way to do it these days is um if I think they call they used to call it infrastructure as as code. So basically you turn all this in infrastructure provisioning into code and then you basically automate them so that you know you have a maybe a single machine that coordinates everything right. um orchestrating all this um and anti is one of the tool that you use to set up machines um so basically install the OS install all the programs that you need and um I think that's the limitation of anible that is mostly to configure the machine but if you want to actually like run the nodes and set all the parameters in there and make sure that they they spin up at roughly the same time spin down at roughly the same

time and all that then you need another coordination tool. Um usually that is um Kubernetes in you know the non Ethereum non-crypto world um but because like there are some specific behaviors that you want from running a a a blockchain service. So curtosis is kind of a develop to to do exactly that. So it would actually like generate the I yeah it would help coordinate you know key generation setting up all the clients and actually making sure that all of them uh have the same genesis so that they all run at the same time.

So in short anible is like the the typical way to set up the machines across like multiple machines and then you have curtosis which actually coordinates setting up an actual like test net. That is what lean quick start already does. And if you add enible to it, that is what it would actually do. Or you can also integrate uh shadow on it. Uh but I mean this is not really a uh debate between courses or not. I find kosis to be a bit heavy and clunky. But I think uh that is generally useful uh when we have execution clients until we don't have execution clients till the

point we have execution clients I think uh doing spending time into ktosis is like uh you know not required but uh sure I guess at some point we'll have to jump for sure. >> Amazing. Thank you all very much. That was really helpful. All right, I will I will try to come armed with one naive left curve question I need answered each week.

That'll be our our little learning session for me. All right. Uh, anything else? Cool. Enjoy the rest of your day and thanks for joining. Thanks a lot guys. Byebye. Take it. Bye.