Post-Quantum Interop Call #19

Transcript

Okay, we're I call 19 by my account. Um, welcome. Good to see everyone. So, let's jump in with some client updates for the week. Uh, Ze, you want to we tend to go in reverse alphabetical order. You want to kick us off? >> Yep. Uh, thanks, Will. So I think our update is that we were working on figuring out the lantern z issue and I think len figured out a fix. We did add reconnection uh mechanism. So basically an a reconnection mechanism but uh uh it was basically not succeeding because the

issue was something else. Uh so I think Nur was able to run uh the devet for a longer time but uh but I think it progressed for 3 4 hours and post that she started seeing issues. So we will still need to uh debug uh but the issues are coming up and try to fix them. uh but on the on parallel we have started already started working on the nible side of this so that uh we can start an nible devet on different nodes not really a local devet so that we can soon have a long running uh a longunning or a public uh devet uh that we can try to

run for a month. So, so the uh efforts are on on both areas and apu uh and apart from that Unchel uh has put up a PR to uh do the aggregation and we decided uh in the lean specs channel uh with other clients that uh we will use lean multisig right now because that is compatible with lean VM. So we will so we are doing two PRs. 1 PR is already up which will basically uh which have which pro which updates the containers uh as per the lean uh lean VM requirements because lean VM requires a common uh message hash over

which aggregation happens. Uh so there is that that is why there is a little bit of there is little bit of container changes uh from the earlier because we were signing messages earlier in with validated id inside and so we have pulled that pulled them out so that the message data is same across uh the attestations that we want to aggregate. So uh there is a PR that is working on uh and I think maybe by tomorrow we will be able to finalize that. So the first leg of the PR is uh to basically restructure everything uh so that we have aggregated attestations inside the block body not really attestations and

these attestations are aggregated on the on the attestation data. Uh and similarly there there is a little bit of restructuring on the block signatures. We have separated out the signatures field-wise. Basically, attestation signatures and uh proposal signature and attestation signatures will correspond to uh so it will be a list of the list right now but it will actually be a list of proof signatures and each of the proof signature will correspond to uh the aggregated attestation in the block body. Uh so the second leg of the PR will then integrate lean VM into this and uh will basically then introduce proof signature

uh inside a testation signature itself. So it will just become a list of attestation sign list of proof signatures and that will sort of uh bring us to devet 2. So I think uh the second we are we are hoping that uh second PR will also be up by end of this week and the first PR will be ready for review by tomorrow. >> Fantastic update. Thanks for all that detail.

Um team >> yeah um pretty similar. Uh so we've been working on integrating the multisc into uh ream codebase um uh basically stumble on the same compatibility issue between lean sick and lean multisc um so yeah like a gender mentioned so we'll be uh integrating the lean multisc uh signature scheme into our codebase and um while waiting for the the the lean spec PRs to to be reviewed and merged uh we are already going ahead imple implementing them in in ream client. Um then we have also integrated the latest

changes in leanmetrics. So that includes the PQ signature um signing and verification time into uh our repo our code base as well. Um but I think we are still facing some issues with some data. It's not showing. Um but I believe Ferin and Katya are working on that. Um we are also Yeah. And we'll also be integrating the lean view basically the web UI for monitoring the the our PQ interop chain. Um so we have that for Devet zero. So we'll probably have to to refresh that a bit and then integrate that into lean quick start as Kinder mentioned.

Um I think that's yeah that's all for you. >> Thanks. Um, clean. >> Uh, yeah. Hey everyone. Uh, yeah, I was out of the office most of the time for the past week. So, sorry if I was too slow to reply some chats. Yeah, nonetheless, uh, yeah, uh, we did some progress debugging. Yeah, we also had some issues with connectivity in clean. Um yeah we noticed like if some node was not accessible uh during the startup yeah clean uh in some situations yeah it might it could just keep this node and not try to reconnect to it. So yeah we just implemented reconnection mechanism for that. Um yeah also introduced a

metric for the number of connected peers. Um also did some experiments with uh shadow yet they still a bit roll and trying to kind of make them a bit more uh consistent. Um but yeah we can measured in the network of the size up to 256 nodes like how long it takes to propagate blocks and stationations. So like the data shows that basically the block propagation um yeah even in in the slowest setup like uh with 50 megabits per second network uh yeah it happens um in under a second for the 256 nodes and for the stations uh propagation is

less than well 90% of the peers can receive any random atist stationation in less than 200 milliseconds. So yeah, still we'll be doing some more simulations trying to kind of simulate larger networks but it takes some time. Um yeah, for 500 nodes it's like takes 3 hours to simulate. Um yeah uh overall that's all from our site. Thanks >> uh Ben. >> Uh yeah, so just one question from my side. I mean if you it seems like uh clients are now switching from lean sik to lean multisyc uh because of compatibility issues and I

think that's fine for now. Uh I would just suggest that we like in the future have some definite that is dedicated to to solve this issue like uh because right now as far as I know the the implementation of the signature scheme in lean multisync is not the one that we have analyzed and that where we are confident that it's secure. Um so it's kind of yeah I don't I don't know at some point we need to get back to the secure scheme you know so when uh time has passed and somehow lean multisig can actually aggregate signatures that come out of lean sig we should have maybe a definite that that checks this and like

moves back to lean sig uh for generating the signatures. Uh yeah, I think that's uh that's what we were planning and in our internal call, we talked about this. Uh lean is going to have uh we're not going to delete any lean stuff. We're going to keep both backends and uh in the future when uh lean VM is compatible with the signatures from leanig, we're going to do Yeah, exactly what you said. We're going to do a devet with uh >> Okay, that's great. Yeah, just >> just to make sure. Thank you.

>> Yeah. So on that front uh maybe I think this the dependency on us using uh lean sig I mean uh the dependencies on air I'm just trying to figure that out what what is that we need I mean who's the person who will deliver us this >> well I mean from my perspective uh lean sig will not change much maybe we will plug in a new encoding at some point. Um, but other than that, I would assume that lean multisig needs to change so that it can take as input signatures that come out of lean sig and prove them

>> or is it just a matter of developing a new guest program for the lean VM? Uh probably it's that and yeah just making sure that that is efficient enough but I mean yeah yeah so I don't see Emil here so I don't know if he'll be able to answer that but in two uh spots on telegram I can link Benedict if you want uh he mentioned the issues uh he has with integrating the current uh signature encoding scheme uh in like great depth. uh he said that it's too slow for ZKVMs and they're exploring other other encoding schemes that are closer to

>> we are doing that right now. So that's why I said the lean sig will not change except maybe the encoding scheme. Um and at when it when that changes then uh things may go more smoothly. But I if if I recall correctly there are other things that differ in his variant of XMSS versus the one that uh has proven security. >> Got it. And also I mean uh since we want to basically push this and uh push this stream. So who is who sort of responsible party for this streams which who can always give update for example in the vendor in a vendor day meetings

on how things are progressing on this side. I think we should have some person so that we can make tangible progress. >> That makes sense to have someone. I mean, as I'm not familiar with the details of the lean VM, I would probably be the wrong person for that. Um, I will of course do my best to make sure that we soon have a better encoding. Um, and yeah, we are working on that with Emil and like that thing will make progress, but like uh in the end the implementation of the lean VM, I I am for sure not the right guy for that.

Understood. Uh, thanks Benedict. Maybe when the when Emil is here next time, maybe we can sort of ask him as well. Uh, but in the meantime, will if you can sort of track this stream as well, that will be pretty nice. >> Yeah, I'll summarize this and communicate it async to Tamman, Emil, uh, and Justin who usually one of them is on this call, but just all three happen to have something going on today. Um, no a great discussion and thanks for flagging that Ben. Um, and yeah, we'll we'll make sure that we have clear representation of lean VM here each week so that you can track that gadget.

>> Uh, thanks. >> Yeah. Uh, lantern. >> Yep. Hi everyone. Um, so yeah, basically on our side uh we've just been preparing for the long running DevNet that's upcoming. Um so mainly just bug fixes. Um I guess the most pressing issue uh that was being faced as I mentioned the last call was um essentially when you run lean quick start um when you run it for like five or 10 minutes um basically lantern would get uh disconnected from the peers. Um and the reason why that was happening was because um uh there was some like the CP library that lantern is using uh it's using a quick

library as an external one and so we had to make some changes to the quick library so that um when it's receiving keep alive ping messages those listener threads don't crash. Um but um after that fix was implemented um in my local testings uh the connections were appearing much more stable um and I think I did receive confirmation from the Zam team uh the connections were looking better and as well as Katya so um and as well today I um created a PR uh which had which has been merged in lean quickart for providing a pre-built docker image um and as well as um added support for two new metrics uh PQ metrics um in

lantern um but yeah uh that's the update from my side >> thanks man here um and then lighthouse >> yeah uh hey guys um like update from my side is um I was able to interrupt with all the other clients uh this week and uh yeah I've been working on like adding all the um metrics to our implementation as well so that uh uh I can also like uh participate in the long running DevNet.

Um yeah but uh that was an interrupt. Yeah, thanks. >> Thanks M. Uh and any last call for client updates? I don't know if uh Grandian or any other one anyone else is here that would like to provide a client update. Okay. Um I guess moving forward to spec updates and metric updates. Is there anything are there any open PRs that people would like to discuss? They're looking up I see. Gotcha. You've got uh

PR6 and 13 and 15 that you wanted to talk about. >> Yeah. Yeah. Hello everyone. Uh so currently yes uh the PQ signature metrics uh PR has been merged. Um it's in the agenda. So all the PR is in the agenda. Um and uh currently um I would like to know from the clients I added um a PR for peer connections which can check the peer connections and connect and disconnect events. So probably would be useful for uh DevNet for long long running DevNet. Um I also added there um labels which may be a little bit

complicated for implementing now. So currently we we may have simplified version without uh labels for example. It depends on your implementation and your libraries. So uh please take a look um give me a feedback um in the telegram or we may even open a thread in the discord which is preferable. Um just let me know um your thoughts on this. And uh also uh I added uh this source label for uh fork choice statistications metrics. Um uh so it's based on the um on the specs uh like is from block or

not. Uh so um if no objections on it uh I will merge it on Friday and uh feel free to implement it as well. And I would like to also know about any needs for u maybe devet one metrics or devet two already like um aggregated signatures maybe or anything else regarded uh VMs or if if you have any ideas for now. If not, feel free to tag me in the chat or open an issue in the free form or if you want to suggest any PR, feel free to

open the draft PR as well. Thanks. Here quick mention about uh re so I posted in the chat. Uh I can see your Pygy signature metrics. Um and currently uh the interrop dashboard is available for all the clients. I will share the link in the chat. So if you run uh link quick start, you can already use it and check your clients.

Thank you. Uh, and then Gadinder, I saw that you started a conversation with Barnabas last week regarding the hardware requirements for the longunning DevNet. Is there anything that you want to provide an update with that? And Barnabas, welcome to the call. I'll see you there. Yeah, I think Barnavas already shared the machines and uh Paka is sort of setting up uh his anible PR on it and uh so we will basically test it and run it and sort of finalize the encable PR as well as uh you know start the longunning dev uh

if we don't see any issues uh yeah so that is what we are focusing on uh apart from that uh as I mentioned in in our update itel has already put up a PR uh for uh for basically aggregating the signatures and uh we are basically it is not final yet. So you can take an early look but uh I think by tomorrow uh so most of the feedback will be addressed and then other teams can also add their feedback on it.

Great. Uh, any other spec related updates or discussion topics? any other blockers or open PRs uh open discussion topics that people have.

Uh I wonder if it's going to be worthwhile to make the SE spec comply with like lean multiG or do we do this definite of the spec before we uh go we go towards multisig >> uh sorry what is the question again? Uh I wonder if the spec should implement the uh the uh signature scheme and the uh the flow that we're going to follow with lean multisigg. Should the spec also be updated with this or uh we leave the spec out of this one?

>> Uh so PR 231 is the spec PR. Uh but I think what you are asking is should we also change the signature scheme in the spec? I think we'll have to because otherwise the CI will not pass. Uh so in that regard maybe we will just do Python bindings and uh basically complete the spec in the short term and try to you know move back to leanig Mus.

Yeah, I just have a clarification uh followup. This um uh multisigg is going to be used in the longunning devet or are we waiting like is it for devet 2? >> Uh it is for devet 2. >> Okay, thank you. Or we can probably update uh the devet to MD to reflect this as well.

>> Sure. >> Okay. Um, yep. I think that might cover us for this week. >> Thanks all. >> Amazing. Have a good one, guys. Thank you. Bye. Bye, everyone. Thank you everyone. Bye.