Post-Quantum Interop Call #4

Transcript

Paul, welcome to the weekly PQ interrupt call. 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 improving a series of devets focused on aggregating postquantum signatures. This breakout room also supports the longer term link consensus vision. Uh let's jump in. Um, oh, I know that we've got a kind of a the basic agenda. I saw that you added a a very nice uh comment underneath it with some detailed information that you like to go through uh regarding the 3SF mini implementation.

Um, we could start there if that works for you. >> Uh, yeah, sure. I can put uh my pull request here uh in the chat. Um so basically I think this uh is relevant to to Zoom and also if there's any other kind teams that are are are in this call. So, so basically um from ream side of things we just started uh trying to implement the 3SF mini into our client um and there were some discrepancies that we have to make uh against the 3SF mini that Vitalic wrote mainly so that it supports the u basically compatible with SSC and and serialization. Um

so for example like um some of the stuff like um there are some optional fields uh in 3SF mini in Python implementation uh there is no optional um field possible inside SSC so we had to remove that um as well as some other like for example like hashes that um use string in the original implementation um we changed it to bytes 32 and stuff like that um so if anyone is interested Ed. Um I think this uh yeah the PR is up. Feel free to comment in there.

Um yeah and I think this is quite important in terms of interop because we'll need to agree on all these fields along with uh their types uh in order to actually be able to interrop. Um, so yeah, I guess like my my message is is just that. Great. So if people could make a point to review that poll request, I don't know if anyone from Ze or Nimbus or uh Lantern or any other participating client teams are on the call want to ask any questions or have any comments or

anyone else? Uh yeah so Gajinder is the one who worked on our implementation of 3SF so I'm not very familiar with the details. Uh we implemented something like a few months ago. I mean he did. Um I know that our library supports optionals. So I think uh yeah we we would like to to keep it this way if uh if possible. Um I don't think it's a big deal to implement uh optionals these days. Although I know Ethan from from Nimbus is trying to to push for a different uh option now which is um uh stable containers.

Um but yeah, as far as I'm concerned uh I would like to stick to the to the spec as much as possible so that we uh we don't have you know I mean of course we're happy to discuss but I think option are not that hard to to to implement. So I'd rather have that than uh than you know jump through hoops to not to not do that. >> I see. Uh noted. I can have a look at optional and then give us uh give you our our feedback um sometime later.

Thanks K. Oh uh maybe a question for for Phipe uh if you're in the call. So I think your comment said that uh it should be using Ethereum types um which is used by execution specs. So I I'm wondering if that's like the kind of like direction that the consensus specs will also be moving towards that. Um uh plus I'm not so sure if there's any discrepancies. Um for example like um execution layer uses RLP for encoding right but consensus uh uses um SSC. So I'm not so sure if it's like fully

compatible um to use the Ethereum types for consensus specs. >> Yeah. Yeah, that comment was I mean where wherever it makes sense to um I think that library is still being built out as well and Sam would be a good contact there. Um, so yeah, if it makes sense to you. >> Sam Wilson. >> Sam Wilson. Yeah. >> Okay, cool.

Yeah. Oh, if you're not connected with Sam, I can put you in contact. >> Yes, please. So, so I guess the idea is to try to merge both like the consensus and execution into using the same uh Ethereum types library, right? >> Yeah. So, I think the goal um for them to create that u they moved that out of the execution specs into its own library and I think just when it makes sense to for uh both specs to use um the same types was my only comment. Um but obviously if it falls short of your use cases then um perhaps expanding on that library and adding the types there uh would be a

good a good first step and then importing those types into uh the link specs if that makes sense to you. >> Okay, sounds good. I'll I'll look into Ethereum types. >> Okay. Yeah. And I and I can get you in touch with Sam as well, I think. >> Great. Um, the other items that were on the call, one agenda and Barnabas, uh, we're going to provide an update. Neither of them are on the call, so we can carry that over to next week if need be. Uh, the other two, there was a follow-up discussion

that people, you know, I noted that people wanted to have regarding the DevNet zero spec. Um, some of the items that I believe were remain open for discussion were finalizing peer discovery, static peers, uh, block attestation inclusion, and we talked about the three SFF, uh, mini modifications, oh, and the placeholder snark data. Um I don't know if if O or uh Camille if maybe one of you had any thing that you wanted to discuss regarding peer discovery and this may have been uh already

finalized async. Yeah, I don't know. I basically also raised this concern I think on one of the calls that yeah, there is no clear uh understanding of how we're going to do this considering that there's no execution client. Um but yeah, basically we can just add everything in Genesis. I don't know uh all the peers or um yeah, if needed uh I I can try to think more about that. Yeah, maybe specify some help.

Okay. Um, and then placeholder snark data. Someone want to explain that to me, what's needed and how to resolve that conversation. >> Um, could you repeat Snark data? What's that? Um the same way that we're looking I guess for a proxy for pure discovery with no execution. Um I had another note that people were discussing uh the need for placeholder snark data.

>> Yeah. Um I don't know last time we raised this discussion I think uh Gajinder had some uh alternative uh opinion about that uh but yeah if we can yeah in my opinion yeah we can do this kind of placeholder um yeah how we can move forward to that >> okay um and then were there any other updates regarding the spec repo. Um, Leipe, I don't know, I had a note here.

You and M had a discussion regarding the Poseidon 2 progress. >> Uh, yes, sorry, what was the question? Um, I guess any updates on on setting up the the spec repo or any new anything that you needed to flag for people? >> No, no. I I think it's been proceeding pretty well. Um, uh, this the the Poseidon 2 subspec was, uh, merged and I I think maybe if anything Tomas would have a little bit

more to say about it, but I think it's, uh, it's in a pretty good spot to kind of hit the ground running. >> Okay. Um, any other items? I know, yeah, Tom and Gadinder are out today. Um, this may just be a short call. That was all I had on my agenda. Uh maybe getting back to the peer discovery topic just uh so do we want to have like a fixed peers participating in the devet or we want to kind of be able

to add new peers when we want or uh any assumptions that we have in that regard maybe any ideas um if it's just a fixed set of peers then Yeah, maybe just adding them uh from I don't know genesis block or some spec file um should be okay. >> I suppose the few moving parts for dead net zero the better. So yeah, plus one to fix.

>> Mhm. Okay. Yeah, that should be easy. Well, um, last call, but I think that this, uh, probably conclude this for this week. >> Great. Thank you all. I'll post the recording and notes shortly.

>> You guys, >> great.