Post-Quantum Interop Call #6

Transcript

So, welcome to PQ Interup. The goal of this call series is to serve as a touch point for researchers and client devs during the iterative process of developing, deploying, testing, and approving a series of devets focused on aggregating postquantum signatures. This breakout room supports the longerterm lean consensus vision. So, let's dive in. Um, we had a call yesterday talking about lean specs and just trying to get some best practices from people. Um, want to thank Felipe who's on the call and we met with them and some of the people from steel and uh, protocol security Sam

and Dan were also there. Um any I don't know any highle takeaways from any of the client uh devs or researchers that were on that call in terms of uh the like state of play moving forward. Uh I know that there was some conversation about uh trying to get I believe uh the types uh for the SSZ reformatted and it sound like maybe that was one dependency that Sam was going to work on and then another one was I believe related to 3SF. I know gadget or did you have any key takeaways or Tomas I know that

you're going to be have identified yourself as being kind of heavily involved in specifications. >> Yep I can add a few bits. Uh yeah so from yesterday's call uh so the main thing uh the main takeaway is that we will continue with the markdown specs and while we uh also uh more and more integrate uh python directly and for that uh o uh need the list implementation for uh for SSD types which uh I'm not sure uh who is basically taking that up and uh with

regard to the spec uh for definite zero we are already working on it and we can basically discuss uh it today with regard to uh 3SF mini uh basically I will so our current uh types the current PR that O has proposed already has 3SF mini types in it and uh what I will follow up with is basically uh the straight transition function to handle uh 3SF as well as uh to do u uh processing the header so that we have parent child linkages as well. So uh once so once uh so by end of this week

uh I will uh be able to do this PR but as such I in particular has already uh most of the stuff uh and then uh I'm not sure how much time reim will take for that uh so for lip tob part uh there are few things again on that uh uh lean inspect PR by O it's by O and once we basically sort of uh finalize things over there we can also start to uh work on interrop uh on gossip subub uh gossip subub we are taking version one because

uh we don't require any PS scoring as of now as noted in the PR itself apart from that I think uh with regard to genesis generation Uh so there have been lot many PRs by PK and thanks to him so we already know basically which parts to touch now uh and uh we have some uh insight into what we need to do even though uh those PRs will need to be redone because uh the uh specs have not been finalized uh but uh we will basically once we finalize the spec we'll basically propagate those changes to PKPR.

So with that regard uh uh I think we will fast cover up once we uh finalize the damn net zero specs. Another thing uh that I think we wanted to figure out was someone uh uh we want someone who wants to take the responsibility for doing Python specs uh uh for the uh steel uh kind of integration and uh I think we want someone dedicated over there. Uh so so apart from Toma being uh the responsible party because uh Toma volunteered to be the responsible party

for specs over overall but uh yeah if we basically close all these people and responsibilities I think we will be good. >> Great. Yeah, as you were talking, I pulled up uh just a project board. I started I added this this morning to the Lanthereum GitHub or. So, I tried to take the the readiness uh checklist that we arrived at last week and then also the conversation from the specification uh meeting yesterday and just try to enumerate like all of these little items that have been coming up. Um, you know, it would be great to get some of the

eyes of some of the more technically proficient people and the the people that are going to be contributing to this on this project board. I'm happy to add anyone to the org so that you can comment on it and we can assign these to people and start putting dates to these things um and laying out what these dependencies are so that uh you know we have like a a high level understanding of where we are in the the overall scheme of things perspective PR I think GitHub project can pull from multiple repos. I'd like to suggest we

include the actual PRs. Yeah. So within the uh description of these items, sorry, I'll share the link to this project board. You'll see the actual PRs. Um yeah, I'm trying to pull together like uh issues parent child you know like sub issues and trying to make this as kind of you know reflect the order of operations in which things need to be done. Um give some like understand the scope of work that we're working on. Uh oh that return oh I might need to make it public. Sorry about that.

Um, so yeah, I'll make it public after the call. I'm happy to share this while we talk if that's helpful. But, um, yeah, any thoughts on just like overall using a an artifact like this to drive things forward? Yeah, I think this is a great board and uh in the last Zoom call basically lets basically uh we had discussion with Lislas and uh basic and he was suggesting that maybe we also prioritize this or timeline this so that uh we can have a good idea of how so what what are the next steps for implementation and

how they will unfold. uh aim is to have uh signature devet uh by by beginning of October. So I think uh with that regard we'll basically work out the timelines and uh try to uh push and see how we can basically crunch this out. >> Excellent. Also, I think that I I need to take uh a closer look will at what you just share with the different items to like give

priority to some of them. For example, I think that the SS typing system will unlock further specification stuff. So, I need to take a look to assign priority and move forward on the spec. Yeah, >> sounds good. I'll share it again. It's public. Yeah, >> I think just to mention on that I don't think uh re and Z teams are basically blocked on Python SSD types because we are just coding it on uh independently as well. But uh what we will be requiring and where you know this will become sort of blocker is when we'll be we'll be requiring spec test uh because

before going into uh interrupt we would basically want to pass the spec test. how we do that on the beacon uh clients and uh I think that is where basically we'll start uh we'll basically start needing uh uh python uh uh generated spec test and so python generated uh uh containers as well >> and u may maybe a quick update on the specs. So I I had a little chat with Justin um Justin Tracia um after the call yesterday um and we are trying to figure it out. Um so Justin suggested I

should use the remmeralized library for now as a workaround with a note that um it's not it's no longer maintained. Um but at least I think it works. I think it works in my initial uh setup. So I think I'll I'll go ahead with that. And then uh the question about how to take those types into a more uh more maintainable uh repo then I that that's where I would love like the steel team to to at least like um advise how to work with that. But I guess for now with the reveralized library I I think I can work with the like coming up with the Python specs initially.

>> Amazing. So one of the things I think that came out from yesterday's call and was not addressed yesterday was uh uh who who is the person who will basically take ownership for the Python uh code and uh I think we didn't have an answer yesterday. So uh throwing out to the bigger form over here. Yeah, I think I I will take responsibility for like most of the Python code. We will start from from there and then we will check if we need further adjustment or like further expertise or stuff. But yeah,

let's just start from there. >> Yeah, let me know if this becomes too much of a burden. Um, my original thinking many months ago was to hire someone who would be dedicated to maintaining and evolving the Python specs. Um, and I guess that's still an option on the table if it's too much of a burden. >> Yeah. Yeah, I will check. Uh, for now it will be like let us say small items. So I I can manage this. Let us see when it grows what we need and if we need further adjustment

um maybe one quick question on the uh container. I think like the only big question left is around the signature. Um I initially put down as bytes 32 but um just for like ease of use but I guess there's been a few comments I think from from para and also uh I think a ginger is also you want to expand that into like more proper signature type as well. Um so I guess like one thing for me is do we want to actually mimic the actual PQ signature type right now while we are sort like where we want to test the the fork choice stuff first right do we want to include it right now or is that

something we want to keep it to just like bite 32 just to make sure that the fork choice interop works first and then for the next iteration when we have PQ6 then then we add that in um I'm quite I I'm Yeah, I don't have a strong opinion there. I think both way works, but I guess like the B32 would maybe help with confirming the the fork choice interop um easier. I guess I mean I don't see size having any uh basically you know any factor in basic in uh making interrop easy or difficult.

just you know once you get the block message and you d serialize it you will basically get uh the uh data uh as per your property properties right so I don't basically see any issue but uh what I would the reason I was pushing for was you know we as uh that uh for these things was that they help build clarity around uh around what we are trying to do as well as increasing uh the parameters for example. Uh so even though for uh byte study 2 is fine uh but but for example I was thinking was that maybe we have variable signature bytes which itself could be uh SSD

serialized uh bytes. So we so basically we can have uh we don't really need to uh uh you know finalize any format as of now. uh but we say that okay you know we will also leave the scope for changing the signature maybe at a later point and say that okay we'll keep 4,000 uh bytes uh for the signature and uh variable bytes for the signature and uh basically signature will be SSD merched uh uh SSD serialized signature over there uh so in that sense basically if the signature we basically have a signature container uh which is of some particular type today

and it changes tomorrow. Uh then our overall block structure and mechanism won't really change that much. Uh so that was my thinking. Uh so that basically you know we can freeze the format soon and we can have more visibility as well as uh people who are working uh on uh the signature stuff they they also get a head start. Okay, sounds good. So I guess it comes down to just pick a size that we want to go with, right? For now, >> we can basically keep it a variable list

max 4,000 bytes. [Music] >> Yeah, I don't have any object in there. So I mean uh Justin or Tomas your in input here would be uh nice because uh do we do we think that the signatures might change uh the parameterization or the signature scheme might change. In that case basically you know variable byte size signature we can go with or we can otherwise fix the signature and just go with the fixed bites.

I think that maybe Justin can had like further comment on that but I think that in the short medium term this will not change that much. The scheme that we have right now with the ashbased XMss, the last iteration we have with the top level encoding things seems really really good and for now we don't have like a better alternative. The set of parameter should maybe change but I'm not sure about this because like uh the one that we tested seems to be really really good. the one that I pushed as a P on the lines spec repo but in the long run I don't know because

we have also like other possible candidate like we have teams working on Falcon for example just to give an example but for now we are not considering switching over this but of course we cannot predict the two or three years future with high certainties so I would say short medium-term it will not change long run we would say we would change need to be checked maybe Justin you want have further comment on this >> yeah so I guess there's there's two types of signatures right there's the the leaf signatures which are the the xms and those I believe are expected to

be constant size so we can have a parameter which is just a number of of bytes and um it's possible there will like very small modifications at which case we can just change the the constant the parameter on the aggregatable aggregate signature uh which is a a snark proof. Uh this is actually not constant size unless we do more work to make it constant size. And so here I think the the most reasonable thing to do is just to make it variable size uh with with a max um and then we can uh we can go ahead and and compute

the worst case uh size and and have that as a as a parameter as well. Uh so basically what we can then do is that uh the block signature we can go with a fixed size for now O and maybe take uh I think it's three kilobytes or something uh with the current parameters. So maybe we can just use that number for now in the block signature.

>> Yes. Uh I dropped a note in the chat last week. I seem to remember an open discussion uh about the key distribution strategy. There was a debate over whether or not these should be regenerated and stored versus generated on demand. Uh just curious if that conversation had sort of reached a a consensus.

>> I think we can basically Mercy has a very good document on that that she can present. >> Okay. >> Yeah, we can discuss post that. >> Cool. Uh Mercy, you want to walk us through this? If you're speaking, you're muted. >> Oh, sorry. Good afternoon. Um, okay. So I did a little benchmark on okay I did one for each um single key generation and then a

batch key generation and the link I shared for the hack day is the result although there's some kind of like inconsistencies so I'm not really sure how to go about it. Yeah. >> So, one thing that I completely understand is you mentioned 4.2 keys per minute sustained. Um, my impression was that we would be generating about one hour's worth of keys every second or of that kind of order of magnitude. So, you know, hundreds of thousands or of

keys per second. What does the 4.2 keys per minute refer to? >> You may be muted to gain. Mercy if you're responding. >> It looks like she disconnected.

>> Oh, I see. >> But yeah, like generally speaking, we should be able to generate keys much much faster than uh than we consume them. And so I I think from my perspective the bottleneck for um you know just in time key generation is not performance it's it's standardization. Uh so Benedict kind of highlighted a couple things. The first one is that it hasn't been implemented in the Rust um library.

But secondly, that there's also no clear uh single way of of of doing it as a a design space. Um, so maybe what what needs to happen is uh is that we we sit down and agree on some sort of a standard, some sort of API um or for what is reasonable. I'm happy to suggest uh something, but it's also something that we could discuss uh during the Cambridge workshop if if it needs more polishing.

My hope is that it's a fairly small amount of work. Um, and you know, the fact it hasn't been implemented in the Rust library shouldn't shouldn't be a blocker. Basically my intuition is that uh if we if we have this uh hashed layer of the Merkel tree so we only have the top half uh which only is of size square root in terms of of of total storage we should be able to to

store it in I know off the top of my head like roughly let's say 100 kilobytes. Um and then the the the key generation should be e extremely fast. So um you know a few minutes maybe even a few seconds before you need to sign. You can just uh just in time regenerate the whole portion for for for the slots that you're about to sign. And you know, hopefully the the amount of time that's used for key generation is much much much shorter than the the amount of time that you that you

start regenerating the keys ahead of your your first slot. So yeah, I guess it's just a matter of of picking a few parameters and and standardizing them and writing an API for it. I think from the discussion we've had with Benedict, it's also a question of when do we uh like need this type of optimization. I think the whole discussion was picked up until we realized okay for devet zero like how much keys do we have to generate on a local local devet environment. So that was so the the initial bottleneck was like disk and rum in uh uh in this very

early exploration phase and then later on okay how much how much disc like the more we get into like second third fourth iterations um this this trick as you mentioned should should be applied and optim applied and optimized for. So like my my hunch currently is that uh it's worth an optimization to uh to further explore and and find right par parameters for but I guess not necessarily as we sprint to uh to to definite zero rights.

Uh, Mercy, I don't know if there's anything that you wanted to add. I know that you sort of had some network connection issues. >> Yeah, sorry. Um, I wanted to answer the question Justin asked. So, um, the 4.2 two keys is that I generated the batch of 10 keys with lifetime of two over 11 and then the total time for batch was 144 seconds. Then the average time per case was 4 14 42 seconds I guess. Then to find out how many keys that fit in a minute will be 16 seconds divided by 14.42 42 seconds sp which is 4.16 keys which now

add rounded up to 4.12 keys per minute. >> I guess there's there's something wrong with the benchmark because it should it it seems like the numbers are off by several orders of magnitude and Jun is saying in the chat that maybe you're running it with the deaf profile. Maybe you're also running it on just one thread as opposed to multiple threads. I don't know. Uh so I think uh if you modify the uh the original rep of hash uh it will be great if you can share your repository

as a GitHub because uh so that we can see how the optimizations uh is happened and running your benchmark. I didn't get that last part. >> June, could you repeat that last part? >> Uh, sorry. Uh, what did you say? >> Uh, I think the part about uh sharing the GitHub so it could be replicated.

>> Uh, yeah. Yeah. So I think there are some changes uh uh changes in the repository hash signature. So uh I think so I'm just guessing from the screenshots you uh posted on the hackmd but uh it will be much better if we can see uh some modifi modification uh in code. Um, okay. Yeah, I will share the link. But if there was a recent push on the hashing group, I wasn't aware of it. So, I was just making use of the one I had locally.

Okay. >> Great. Um, were there any other items that people wanted to go over? I know that we received some of the I don't know, Gary, you touched on it earlier, but the work from PK 910 uh late last week. I don't know if anyone wants to review that or say anything more about that. Oh, I know you've got a couple of PRs in flight in the specs repo. I don't know if there's anything that you want

to call attention to there. Just something just to finish about like the benchmark. I think that uh from the screenshot that I can see in the AKMD, I think that you run the cargo run without CPU native like if you if you I I will share in the chat the the comment but I I think that this slow down a lot because otherwise there is no paralization flag so that when you run the repo it's automatically doing multistra trading and no secret trading.

But I think that you should do that instead of doing simply cargo run to be tested and to be defined offline. But just a just a hint. Um and I also noticed the uh Mercy I think you're running on a browser IDE or something. So maybe the hardware >> that you're running on is probably very limited. >> Yeah, I'm using Git Pod. I can't really run it on my laptop per se. >> Yeah. So, or maybe at least like if if you could figure out like what's the hardware specs of the instance that you're running on, then that's probably

useful too. Okay. Um, anything else?

>> All right. Um, I think One one thing >> maybe worth discussing the timeline. Uh I think we originally mentioned about like end of August but I think like probably we can pro I'm not so sure I need to ask the the team whether we're comfortable with like having all the specs implemented by end of this month and maybe like we could start our own like local network or single client network maybe sometime in early September. So maybe like the the like refine target for a interopet without PQC just the fork choice stuff

maybe midepptember I guess not so sure. Yeah, Zim would be okay with that timeline. And so if that say if the goal is to have that up by September 9th, September 15th, whatever it is, uh you want to have that live for 10 days. Are we thinking that before they get together in early October that there would be time for uh improvements to like a DevNet one or that do we how do we want to

consider that uh get together in the timing of this? >> Maybe we do devet one in the interop. Sounds good. Um, yeah, feel free to DM me if you want access to the project board that I created. Um, you might need to get added to the to the repo to be able to edit and uh modify it, add issues, but I don't know. I think it'd be a useful tool.

happy to maintain it. Um, but yeah, I'll just need some feedback in order to get it uh kind of validated from everyone's point of view and know that we're starting from a from a good starting point that people agree upon. Great. Well, have a nice rest of your day or Thanks, Will. Thank Thank you.

>> Thank you. Bye.