Post-Quantum Interop Call #27

Transcript

We're recording. Gemini is taking notes. We're transcribing. Trying to minimize my mouse clicks a bit. Um, so we're going to give this a shot on Google Meets. So, uh, welcome. We're PQ interop call number 27. Um, we kind of have a a common flow that we're going through. Uh, we're going to be talking about DevNet 3. Um, so let's jump into client updates. If you could kind of give a sense of where you're at implementation, spec tests, uh, Docker delivery, interop, uh, for DevNet 3. Um, that would be great. Let's start with

Zam team. >> Hi Will. Hello everyone. Uh, yeah. So the update uh on our side is that we have been working on resolving some of the issues uh with regard to checkpoint syncing some of the issues that that are with regard to our DevNet 3PR. Uh and uh we are also getting lean quick start ready for DevNet 3. Uh so as as in all we are basically waiting for some other client to interrupt with us because things seem to be working on our end and uh we would be happy if some other client is out there which is ready and

we can start the interoping efforts uh to push this forward. >> Great. Thanks Kevin. Sure. Uh Ram team >> sweet sweet. Uh so I mean uh uh thank you Kender. We are we should be we should be ready to um interop. We should be ready to Oh my god, my my throat is being very weird right now. It's dried out. >> You're working hard.

>> You're working too hard. >> Too hard. Too hard. Uh so uh we should be ready to interrupt with another client. Uh however, I'm not sure if we'll finalize because uh we have inter uh inter we've implemented the spec uh completely. Uh I've gone through multiple times. I think we have everything in there. Uh however, our self- finalization tests are currently do not seem to pass. uh but with this new committee aggregation stuff there might may be something that the tests itself are not doing uh for us to reach finalization so I'm currently de debugging that and uh I think the current DevNet 3 docker image should be ready to start testing

uh like I mean for the first for tomorrow or day after it may not pass but like soon after that it may start passing uh and And then uh and uh on on the Devonet 2 side uh on the Devon 2 side we just saw yesterday we were reaching 13,000 slots. Uh I fixed some uh we fixed some minor stuff on on the log side. Some of our logs were uh slightly big. Uh so we fixed that and yeah so definitely uh we should we should be getting there within this week.

Awesome. Uh, cleaning team and Camille might be traveling. >> Yeah, I think he mentioned it was going to be AFK. Uh, Lantern. >> Yep. Thanks, Bill. Hi, everyone. Um, so yeah, on the DevNet 3 side, we have implement all the specs uh for community aggregation and the tests are passing. um and also ran a local test of four lantern nodes running dem 3 and could see justification finalization. So um yeah basically at the same um stage as Zen team we could uh release a DevNet 3

image uh to see if in job works. Uh on the DevNet 2 side um yeah just been fixing bugs um mainly related to uh the certificate that is used in quick protocol um being able to rotate that when when it expires. So fixing those kind of issues. Um also uh I know there was a comment in telegram about checkpoint sync testing. Uh so lantern indev 2 branch implements serving finalized and justified um states for checkpoint sync but it doesn't yet yet have a flag for like being able to checkpoint sync from

scratch but I have implemented that. Uh I will be releasing an updated image for DENA 2 uh so it can be tested. Um but yeah so I can release both DEA 2 and DENA 3 images uh for testing. But yeah that's my update. Thanks. >> Thanks. Uh >> hello. Um from our side uh we reduce memory usage during long syncs by offloading pending blocks to disk and improve the checkpoint sync code.

So we have checkpoint sync we have support for checkpoint sync in in our last docker image. Um we continue testing devet 3 implementation. We have a devet an internal devet with four is lambda nodes running and they are finalizing. Okay, including the net three changes. We wrote some documentation on checkpoint sync and consensus in our repo. So our next steps are review and polish the the code for the net 3 branch and we will work on a tool to simplify the uh the review of the net logs.

>> Thank you. >> Thanks Pablo. Uh Lighthouse. >> Thanks. Um yeah, apologies for like not being here in the probably one year, 1 month or something. Uh but yeah, I've been like I just finished some of my work from um uh the Glowas uh update. So I'm going to be start working on light uh lean chain and uh I was pro looks like it's uh it's like a better thing that if I start targeting definitely. So uh yeah I think

I'm going to start working on that and then uh release the release the image once it's done but yeah it's going to probably take some more time. Very cool. Thanks, Thomas. Uh, game team. All right. Uh, hello. Hello. Uh, on our own ends, yeah. uh on our own ends we've integrated um link uh with g uh with gin at the moment uh basically uh for block and attestation signing and of course

also uh for signature verification we also uh integrated lin metrics for devet one specification uh by by tomorrow we should have uh the PR for lin start so that we can start uh test for uh multiplines uh interup uh yeah so uh expect that PR uh by tomorrow and uh yeah basically that that is where we are at and then uh seeing how we can uh move to DevNet 2 uh and all that so yeah that's it from us yeah >> awesome thanks very much uh grand saw you on the call I believe

Yeah. Hi. Do do you hear me? >> Yep. How are yours? >> So, um yeah, we we did multiple fixes for Devet 2. So, likely it's uh it's working better now and it's more stable than it was before. And for Devet 3, there is still a lot of uh work for us. >> Awesome. Thank you. Um I don't believe anyone's from Nimbus here, but final call for client updates.

All right. Um so I guess moving forward to or maybe even backward to DevNet uh stability observability metrics. Um Kachcha you're usually uh on the ball with updates or or Partha I don't know if there's anything that you wanted to add in this section. >> Uh yes hello everyone. So first of all uh I'm sharing the link to the client's readings for devet 3 issues. So um I currently rely on the same tags uh the clients have for devet 2 like it will be devet 3 but if it changes if you have

any updates for this please comment on this issues. So which which images you prepare for the three regarding uh the metrics I open the PR for the three metrics. So please uh check it uh try to implement. So um whatever comments you have please leave your comments because it's like the first implementation so needs your attention. Um so it's mostly based on the committee aggregation PR and if you need anything else please let me know and currently we are testing uh checkpoint sync. So uh yesterday I was trying to find some working combination

of clients and um I found it for four clients currently. So we are testing Zim at the moment with the checkpoint sync. Um as soon as we fix it, make it work. Uh we will uh switch to it lambda testing and if lantern is ready we also then I need to restart it and test the lantern as well. Uh so that's it from my side uh for reim I um yeah I sent in the re channel uh in my notes uh about the latest image. I hope Shahik you have seen this.

>> Oh yeah. >> Yeah. So uh whenever I will restart the devnet so I probably um uh add uh ring again and uh lantern but currently we're still having um the devet fin the finalized devnet and it's already almost 24 hours so that's a good news uh I even don't want to stop it so trying to keep it live. Uh, okay. Just follow uh I wonder if uh new client Jim uh sorry if I pronounce it miscre but are you in the tooling uh channel? Um are you

following? If not, please please join. Um that's it for my side. Thank you. >> Yeah, thank you. We'll do that. Great. um specifications research lanm signature aggregation. Uh yeah I can briefly talk about this. So um this week I have continue working on the spec and the book right now um I have um interrupt test passing uh locally so between just linspec node and

itself. Uh so we have couple of tests for this. I need to work on the sync u on the sync stuff. For now this seems a bit flaky but uh yeah I need I need to continue on this but this seem it seems that the networking part and um everything related to for choice and everything is pretty pretty stable because I didn't have um anything weird at least in the test. Um and so I wrote also like a part of the book a bit related to the 3SF mini. I will publish that on the repo soon so

that new people can just read about it and be a bit informed about our consensious rules. Um yeah uh as research point we also discussed um the fact of modernizing the actual beacon spec uh how to merge with with linspec um and I also started to think about um pub key postquantum registry. Uh I will start probably soon to write a draft of a of a post um and yeah couple of podcasts that we made about a research topic um various stuff and everything. So yeah

that is basically me I update email feel free to update on the linvm side. >> Yeah thank you. Hello everyone. Um I have finally finished the recursive aggregation stuff. We've sent you in the in the chat a link to a test where there is the API available. It's not the the the official in XMss for now, but at least there is the API. And in the previous call, I explained that maybe um you would use something like a Merkel tree of the P keys of the atesters. But actually um the most efficient approach was to simply like not use this merry

but when you aggregate like when you want to verify an aggregated signature you basically field the list of the public keys and that's it. So it's the most trivial way you can think of and uh yes that's mostly it and a bunch of optimizations working in progress but the important part is this recursive aggregation uh yes stuff. Thank you. >> Awesome. Thanks to my email.

Uh any other topics in the research tech realm? Uh if not um I I have a question uh regarding the specs on the >> on the signature container. Um so so last week I added the SSC test vectors into the leanspec. um and try to implement those vectors uh inside ream. And it turned out that um currently the the signatures that are being serialized from the lean spec is is basically like

a structure signatures with like variable list like of the the path and hashes. And while all all other clients including ream before trying out these vectors are basically using the fix byes um I think Kobe also had an issue open uh in the inspec some time ago as well um but it's not concluded yet I'm just want to raise it here which way do we actually want to go like if it's fixed bytes then that's like what everyone what every client is doing um but It's not what's in the specs.

>> Um, yeah, I see. >> Yeah, I I basically like was trying to align lantern with the spec. So I have also implemented in lantern so that it could serialize the signature container such that like it doesn't it basically makes it variable rather than fixed size. Um but I have also added as a fallback um if there are payloads being received that have serializing the container as fixed size that it can also handle those payloads. Um so yeah I think I reached out to the ZM team regarding this uh and I was also unsure which approach we should take. Yeah,

>> personally both are fine to me. I if I understand correctly your point um you mean like the SSization of the of the signature container in the case of all the client is fixed because all of the dimensions of all the fields are known at compile time because everything depends on constant but in the spec we are not doing that we are doing variable size things instead. This is this is what you mean. And so when you try to derialize or to serialize spec signature container, you don't arrive at the same result as a rim signature container. I

am right. >> Yeah, exactly. Yeah. >> Yeah. Uh yeah, both are fine to me. We can check that. Uh yeah, I guess we can check that async. But uh yeah. Okay. Yeah, I can check. But probably I I think that if all the clients are doing um fixed size and I think that the fixed size stuff is a bit cheaper in terms of sizing and stuff. Uh so maybe fixed size is the right approach in this case.

I will check. So I think what O is mentioning over here is that if for example I look at the signature class the link that over and uh look at the hashes. So you have basically interpreted hashes are list of vector of FP and then the limit for it right. So I think what O is trying to say is that instead of list it should be just vector and that should uh just give you a fixed size serialization. Uh so so the so the question is that why do you need to be variable in the spec? I didn't get that part. No, I think that we don't need I think that we don't need

I think this was just like a bad choice or like something that we don't need. I think >> Got it. Got it. So I can we can just update it on the spec I guess. >> Yeah, if if I I remember correctly, I think it was to do with the test and prod config in the spec that you have to support both like the shorter >> um >> Yes. But I think that since now we have this um like this constant setup at the root of the repo, we can still do the same. I guess I think I need to check everything. Yeah.

>> Okay, cool. I'll I'll talk to you offline about this. Um I'll revert green back to fix size. Great. Any other open discussion items? Okay. Um,

I guess we can call it a call. Thanks everyone. >> Thank you everyone.