Post-Quantum Interop Call #11
Post-Quantum Interop Call · 24 Sept 2025 · 26:51
Post-Quantum Interop Call #11, held on 24 September 2025. These weekly calls bring client teams together to coordinate on post-quantum cryptography for Ethereum, including devnets and interoperability testing.
Topics
From Post-Quantum Interop Call, hosted by Ethereum Foundation.
Transcript
Hello everyone. Okay. How's everyone doing? Um, welcome.
We're on call 11 and I think, you know, I think we're starting to hit our stride with these. So, let's just start with some client updates. Um maybe Gadinder someone from the Zam team you want to lead us off. I believe last week you were talking about genesis generation tool being ready and local intera with Okay. >> Hey guys. So uh with regard to Genesis generation tool I think it has been ready and uh uh we have been able to consume its format and start our nodes.
uh in terms of uh Ze so we are right now trying to integrate the spec test uh on which we want to discuss uh uh with other people as well. So what is the best format to have the spec test? Uh and uh as such we are mostly ready for interop if ream is also ready. Uh and uh I do have uh I do have a proposal for a change which might not be a big change but in fact could be a simplification which is that uh uh so for signatures right uh we have a test station uh signed vote as well. So we can perhaps uh just have one signature
on the block level which could aggregate all the other sign signatures as well. So in that way uh the input to for example to our prover will can become small and that is one of the things that we noticed that uh uh that the since the input to the prover to our prover has increased. So uh it has it is sort of bringing up other issues apart from the fact that it is taking more cycles and more time to prove uh the straight transition. So I think if we can just move all the signatures in one total block signature it should be it it will be good for uh for generating the proofs.
Uh could you uh open a PR for uh the change so that we can discuss on the PR? >> Yep. Sounds good. We'll open up here. >> Uh, yep. So, yeah. So, I think uh rim team can also get some updates. So, uh last week we did some optimizations on memory. Uh so we use this database uh for our uh uh our lin node and uh for our local environment and also some
docker compos script uh we are able to observe some finalizations and definitely going well. So uh I think yeah uh for just the rim part we are almost ready for intra as well and the one uh so uh for the genesis generators output is also ready. So I think the format is also yep uh we are following the common formats as well. So I guess uh the spec uh if the spec test is ready um we are trying to integrate that test in our codebase as soon as possible.
That's that that's the one thing we are um uh remaining and also uh uh our our one of our member Shahik uh will uh take some metrics uh on the rim side and we are preparing initial proposal for limb metrics. That's it. >> Uh, I can carry on from there. Let me just stream my screen real quick. Uh, I did see Katya's latest PR which uh actually formalizes a lot of stuff I'm going to show. Uh, but let me go to desktop share.
Uh, it's okay. Okay, now I should be able to uh I'm going to have to reopen my to share me open my Zoom to share. Give me one second, guys. >> Uh, so maybe for the metrics we can discuss later about after those updates. >> Yeah. Um, Camille, maybe we could go to the Wayne update first and then uh circle back to metrics. Yeah, sure. Uh yeah, we have a good progress with u integrations. So yeah, we implemented fork uh uh fork choice and uh we just one or two bugs away from actually working uh networking and
everything. Yeah, just uh so yeah, 3SF uh and yeah, communications and all these messages they are implemented. Yeah, just some troubleshooting. Yeah, I believe by the end of the week uh yeah, we should be also ready. Uh so we might uh what admitting is yeah we're currently storing everything in memory so yeah we need to introduce persistent storage which we already have but yeah we're just not using it and also yeah we have u uh prime integration uh so yeah matrix uh um is so basically introducing matrix should be really fast um yeah once we have everything else working Um yes I think that's mostly it from our
side. Thanks. Yeah we were also by the way thanks Gajender for sharing the um spec generation tool. Uh yeah we updating our spec which we used previously to this spec format. It's yeah should be also relatively quick. So yeah, by the end of the week we should have uh everything ready in terms of uh running prototype and yeah we should start we should and then yeah we're just working on some optimizations introducing storage all the stuff but we can already start testing basically I think. Yeah thanks.
>> Um were there any other client updates? So maybe we can I think I want to try to structure this where we go client updates and then specification updates and then kind of discussion topics. Um I'll try to be a little more structured in the way I issue or format the issues. But yeah, so before we go back to metrics and that could also be a reoccurring area. Um were there any specification updates that we should cover or specification related discussion topics?
Great. Um, so yeah, Sheree, let's uh talk about metrics. I think you had an update there. >> Yeah, definitely. Okay, I'm going to share my screen here. And uh can you guys see my screen now? >> Yes, we can. So uh I I got a head start on uh creating a proposal for the initial metrics that each client should track. Uh Kartia has previously linked the beacon interrop metrics. So uh uh I created this doc that says what we have what we in re have right now what the beacon interrop metrics are and what what we can have uh relative to the beacon interrop metric for lean. Uh uh I I started with uh so in le in re we
currently have the lean finalized slot, the lean justified slot, the lean head slot and the block proposal time uh in so I I read through the beacon metrics and I believe I some of them we can we can straight up go ahead and uh and move over to lean but some of them have epochs. I I'm not I don't think we're tracking epoch based stuff anymore. And we'll go to uh finalized slot, justified slot and previously justified slot. So these these are the these are the metrics I propose uh as our initial metrics. Uh what I have seen is Kartia made a PR uh recently uh just like this morning if not like 10 15 minutes ago
that does formalize a lot of that stuff. So uh reading that PR that might change some of this stuff. Uh but yeah these these are the initial metrics I propose. >> Thanks Shereik. Uh so we will basically review this uh and uh come back if there is anything that needs to be added or changed. >> Amazing. I'm going to link this in the chat right away and in the >> Yeah. and Katcha uh if you could drop the PR there and I see you have your hand raised.
>> Yeah. Hello everyone. So uh I have an open issue for discussing this uh picking matrix and draft PR. So I think we we we just need to uh to join with Shik and uh make it in kind of one one PR or etc. Feel free to add this notes to this GitHub issue Sherik. So yeah and we can track um definitely I just kind of copied the metrics from the beacon chain and it's still draft and it's still in work um because some of the metrics are not relevant. So currently I'm cleaning up them as well. So here
where we can collaborate with Shereik and um cut off the unnecessary metrics. So um so let's just collap share async. >> Amazing. Let's do that. Thank you Kadia. uh this issue is for like um existing beacon metrics and I opened another issue I don't know if it's uh overlapping or not another issue specifically for devet zero metrics maybe we need something or we already have something uh so we can just
standardize um uh for devet zero specifically so yeah you're still sharing the screen uh sharing Sweet. Great. Well, thanks. Sorry. Gotcha. Um, are there any other discussion items that anyone would like to floor?
I think we can uh start uh doing the spec work on uh the signature bit now because uh once this is done I don't uh I don't see uh basically many challenges towards uh getting the signature integrated apart from just you know the integration challenges most likely which I'm hoping will be less uh because we are going to use the same library bindings over the same library. So we can perhaps start working on it. I believe Tomma is already working on it. So maybe we can have some insight into it.
Did you have your hand raised in regards to the spec or from earlier? >> Oh, sorry. >> No, no, that's fine. Uh Pam, did you have anything that you wanted to add on the signature spec? >> Um I think that right now the signature spec is uh is feature complete. Uh so there are all the types in place all the test to confirm that the spec is okay and all the function implemented with all the API. So yeah we can yeah both the Python and the rest are are okay. So yeah.
>> Yeah. So with with regard to uh the spec with regard to the lean chain, I mean uh that is uh again tying into the previous uh thing that I mentioned that we would want to also aggregate all the uh block signatures for example sign board signatures into uh into one final block signature. So I guess you know we we should basically now think about uh a lean signatures back in that respect as well. So I will do the PR and then we can have discussion on it.
>> Yeah. Yeah. Yeah. We can mock that for the moment. But of course like the missing pieces here is like the full scheme for signature aggregation including the minimal VM and including the proof system but that is completely another topic and that is the most difficult one. So we don't have even an answer yet on how to do this. So we are actively looking into this with the postquantum team with Emil with a bunch of other people. So yeah for for now we can just mock things but not run that in DevNet production right now.
>> And when do you think we could have some sort of an aggregation uh spec going on going? I don't know like yeah I don't know for for now like we have a minimal VM but the minimal VM is huge so we we cannot spec it's like a bit more than 10k lines of code in Rust. So this is very hard to spec and even if I wanted to spec this it include also like the the PCS that is another like more thousand lines of code and even with that we don't have the performance
numbers right now. So this is work in progress. We are quite confident that it will work but this is work in progress and yeah >> so sounds good. will basically then mock the block signature as such and uh that it's working and uh >> yeah yeah yeah for now we just we can just mock and we we can't do anything else than mocking or yeah finding some arrangement but we can't do the real aggregation at least for All right. Great.
>> So just just to just to uh you know re uh uh resay what uh we just reconfirm. So, DevNet one will have for example uh signed votes. Uh it will not have any aggregation and it and it will also not have basically the block signature because we want to do block signature as an aggregated signature. So it will still be zero bytes. >> Yeah. Something like that. Yeah. Yeah.
Or we can maybe think about how to mock something in order to have like kind of a fake aggregation but we will not be able to do the real aggregation here. >> I mean you can sorry >> I think we didn't hear you well. >> You can always Okay. Can you hear me now? Still a little garbled. Benedict, may I try again?
>> Yes, better now. >> Okay, my headphones. Um, yeah. So, you can always concatenate things for aggregation like trivial aggregation is always just to concatenate things. Why not do that as a mock? >> Yeah, we with small number of validators, we can definitely try that. But if we have like thousand validators for example and then each signature is like 3 kilobytes I think the size of aggregation would be larger than the expected size of aggregation once we have snarks.
Yes, sure. Yeah, >> that is true. But I guess that was the that was like expected, right? Because we said there's one definite in between having no signature having the full aggregation thing. So it was expected that we will have where we don't have aggregation yet. >> Yeah, it makes sense because I mean till we don't have aggregation anyway, we are going to put all those signatures in the block. So we can definitely concat all the signatures in one single signature field. I don't see a challenge in that as such.
The sizes won't of the sign block won't uh really change Or what we can do is basically we can for example for the block when we have a message and a signature. So instead of signature we can right now have signatures which basically means that the first it is an array of signature with the first signature being uh it is a list of signatures with the first signature being uh block signature and
then basically rest of the signatures uh being from that estations. I think uh this would also sort of work for now, but it would still achieve uh the separation that we want to have All right. Any other topics?
Um, so it sounds like uh several of us are going to be on the road next week traveling to Cambridge. Uh, and then the following week, um, there will, uh, I guess by Wednesday, yeah, there will probably be people traveling back. I'm going to be at, uh, another retreat. So, we may not be having this call for two weeks. Um, so that we have the opportunity to actually do the interop. I'm sure that there'll be a lot of like sync and async work happening within those two weeks. Um, and I I think that by the time we get back, uh, we'll we'll have some real uh maybe some proof of
concept, uh, a DevNet show, a lot of work, uh, to reflect on, and of course, all of these, uh, IRL sessions are going to be recorded, and I'm going to do what I can to get those published, uh, as quickly as possible. So if you're not able to be there, we can certainly have a a debrief so that everyone that's not able to make it there personally uh and the people that are, we can reflect back on what we learned and uh any open discussion items and and uh really make the most of that time together. >> But yeah, we've got a very packed agenda coming together. excited to share it with you all. And uh yeah, I look
forward to seeing a lot of you in person. And other than that, I will uh send out the invite for uh when we return. I believe it'll be October 15th will be the next call. >> All right. >> Thank you very much. >> Oh, go ahead. >> Sorry. Yeah. Um, I guess Manish from Lighthouse also wanted to give a quick update. >> Oh, I'm sorry. Hey, Moss. >> Oh, yeah. Uh, I'm so sorry I couldn't raise my hand uh cuz I'm joining in from a phone. Uh, >> but yeah. Um, just a small update from my side. It's not that huge. Uh I've just like um started some uh like the uh
the client is like running right now but uh I've just added all the containers and I don't have any chaining right now. Um I've started the lib2p node as well. So uh I I think when you guys are gone for like 2 weeks I'm going to be heads down working and trying to finish my implementation. Um I I just like wanted a few resources like uh confirm on few processes that uh the lean spec on the repository right now that's like uh devet zero complete and also uh if there is an e uh pandops like the um ktosis configuration file if that's available
uh that would be nice for me to do local devnets. So uh yeah these are a few like resources that would be uh nice to have. >> Yes. So uh to respond to the spec yes we are definite zero complete but I will do a a PR which I will share and uh to change how signatures are bundled right now. So there could be a small change with regard to ktosis. So basically we are right now going without ktosis. Maybe we'll just write a simple tool to spin it up. We have a genesis generator that generates uh that generates uh various config files that you need and it is also very
quite simple in that sense that it will you know uh so everything is fixed that the secret key for your lily P2P instance is fixed uh all the uh peers are pre-generated uh so so in that regard it will be easy to consume and set up your node uh so we can basically share that and uh yeah so whatever changes are there we can basically coordinate and uh I will also add you to uh the lean inspect dev group that we have uh and uh yeah I will also add Camil I think uh he's also missing from there so you should be on top of things with regard to that
>> yeah that sounds pretty nice thanks Yep. Uh that's mostly from my side. >> All right. Um thanks for the update, Manus. Uh Gavender, I don't know if I'm in that chat. If you could add me to that too, that'd be great. The wings there.
All right. Thank you all and I'll talk to you soon. I'll post the minutes to this call later on and the recording. >> Thanks. Well, >> thanks. Thank you. Bye. >> Thank you. >> Thank you. Well, bye. Bye, everybody. >> Have a good night, guys. >> Bye.