Post-Quantum Interop Call #15

Transcript

Good morning. I think a lot of people are probably in the same boat I'm in where I'm like, "Oh, there's a time change. The meeting starts now and not in an hour." I just dropped a note in the uh Discord chat. Maybe I'll give people a second. It seems like uh there was two different

meeting links. >> Oh yeah. >> So me and Lattis Laos and Unawit were all in a different call. >> Oh, >> where' the other link come? Uh, Google calendar is where I >> the one you shared with the like the placeholder for for the calendar instead of the official Google uh the official Ethereum calendar and apparently the link the Zoom link has changed. >> Sorry about that.

>> Anyway, O is O here already. I just sent him I just ping him. No problem. I actually thought you were traveling with us. So great, great to have you. >> That's later today. >> Nice. And all not takers also went to the old link, I assume.

Okay, great. Always see. >> Okay. Yeah, sorry about that. I'm not sure where that extra link came from. I'll track that down, get it tidied up. Um, great. Yeah, I I thought my biggest uh curveball was going to be the uh the daylight savings uh change and I heard an alarm go off and I was like, "Oh, I have an hour before call and then oh no, actually I don't have 10 minutes." Um all right, so let's uh I shared the uh issue link in the chat. um trying to be a little bit more diligent about summarizing what was done the week before and I'll carry that over week

after week so we can just keep building on it. But that's got a record of uh the client updates from last week. So let's go through maybe we'll just start with uh Zim. >> Hello everyone. I will let us Yeah. So uh we have been working uh so to integrate uh the aggregate uh signature changes. So that PR has been merged in ZIM. Uh we were also working on uh doing a spec PR to actually integrate the signature. That spec PR is out and is being reviewed and hopefully in a day or

two it will be merged and uh maybe by next week we would have integrated uh signatures as well. So it would be then time for devet one but uh and in prepar prep preparation of devet one uh we are also updating lean quick start uh so we have integrated hash cli that will uh generate uh uh generate the key pairs that will be allocated to different validators. So that has been integrated and uh then there is another PR by uh para which basically integrates anible as well as kubernetes into it. So I think uh we will soon be ready for

multi- uh machine deployments. uh and the way I think it would uh and we would even leverage that to make sure that the signature generation also happens in a distributed manner through all these machines like you have five machines you can use enroll both five machines to generate the signatures and then basically accumulate the key key pair through anible and that is what uh pathas PR will achieve over there and uh so this will basically that stage to devet one. Uh and once uh all other client teams are ready, we can try to go for it. Uh with regard to spec uh uh

spec test, we don't think we have moved much on it. But I think this week uh we will try to uh push spec test a little bit, integration of spec test a little bit more. Yeah. Yeah. Will I'll drop uh the P links into the chat in a bit. >> Great. Thanks very much. Hey, you got a question? >> Yes. So, um I'm wondering how are you going to organize um uh this interop script uh in terms of uh changing the specification? Uh so is there going to be some tags in that

script repository uh where we know uh which exact uh version of interop script matches to particular specification uh version uh >> yes so I think we can create devet uh branches onto the script so that uh that confusion is sort of resolved and yeah But generally I think once and once we are through a devet and you know these devet phases are so small and they are not so organized as of now just because of the reason that they are small and fast moving uh I mean there isn't really need to have okay saying that okay you know this

is a version that that cares for devet zero and this is a version that care for devet one unless the clients which are trying to catch up they would want that and in that case basically we can consider that and have the branches but as such as of now we don't see the requirement for it because when a particular devet is over so we quickly want to move to the next devet >> okay but for example like right now the the trunk uh of u trunk branch of uh uh integration script what exactly what exact specification version does it match is it also is it trying to match the the trunk of uh specification or what is the current for example what is

the current status >> right so current status is that uh uh yes the script is compatible with the devet zero but uh we'll soon move to devet one I think the script uh so additional step that has come to the script is that it generates the key pairs and even devet zero can use the same thing it it ignores the key pairs that will be allocated to to the nodes. uh but yes going forward we'll make sure that uh we generate a branch and tag it properly so that uh if somebody is targeting a particular devet then they go for it and

sort of uh adopt a release process in which uh then we basically uh merge we basically release a whole uh devet and say that okay you know uh a new devet uh uh a new devet release has been made and this is what you are supposed to be using it and the main trunk can continue with the f further changes on top of it. So it might just be in flux but uh yeah it's a good idea to have uh released branches which people can basically pin to and use it.

>> Okay. Okay. Thanks. So yeah, in in the future if you can try to uh to make it more organized uh in terms of like matching particular specification version or so. >> Yeah, sounds good. Uh we will adopt the release process only in quick start uh from now on. So even definite one will have a release. So that way yeah it's a good idea. Thanks. Okay. Thanks. >> Excellent. Thank you. Um RE team.

>> Yeah. Um so for REM, um on the spec side, I think we reviewed most of the PRs on the lep spec already. Um and also submitted a few PRs which are already merged. Mostly are like small fixes or a few specific additional cases, test cases. Um and on the implementation side we merged a few PRs on hash basically the signature integrations. Uh we are working on integrating the attestations um processing from the specs also implementing signature integration. Um we are also updating our metrics um to follow lean metrics uh working with Katya on that. Um and uh Jun is also

working on a minimum curtosis package. Um I understand we already discussed this um last time but I think we are still curious to actually try it out. We are not actually forking the Ethereum package. Um we are actually creating a new one from scratch. Um obviously like we are still behind in features in terms of like comparing to seams lean quick start. Um but yeah I I guess like for now I think I feel like you know each client can kind of like create their own and maintain their own tools. I think that will help like each other go at our own speed. Um but yeah I think when when we are when we are ready to go with like definite one I think we can decide on the spot there. Um which tool do we want to use? Um, and I guess like one

follow-up question on that is uh I'm not so sure do we have any resources regarding like the resources for for the hosted DevNet if we have any infrastructure resources that we can use or is it like um like the client teams figure out their own. Could you >> if you could expand on what you need for resources? We could I could speak to DevOps or something if that's gonna solve your issues. >> Uh I don't have any specifications in mind, but yeah, like AWS resources something that we can run it run the DevNet with on the cloud. But um >> but yeah, in that case then I guess like

we can work between the the client teams and then we we can propose something. >> Yeah. I think it depends. >> Go ahead. >> Yeah, I think it's easy to approach Par or uh uh Barnavas and ask for some machines when we want to do a public devot. >> Okay. Yeah, I was going to say I could go I don't I never know if it's best to go through Pandops or through DevOps. Um, so if it's just kind of simple virtual machines that you're looking for, I can go through DevOps and u limit pandops involvement. I know they've

probably got their hands full with Kusaka and other things. Um, so yeah, if you could give me like a a few bullets in terms of what resources you need, types of environment, uh, specifications, uh, I can speak to both of them and figure out the best fit. Um, sorry. Was that did you have anything beyond that? >> No. No. So, so I think the action item there is like we probably have to figure out like the resource requirements that we need and then propose it to wherever has the resource.

>> Yeah, perfect. Uh, cool. No, they're very responsive. Um yeah, I think once we identify what's needed, um yeah, I can get an issue open and they executed on it pretty quickly. So, uh just let me know what you need. Um clean. Okay. Hey everyone. Um yeah, first uh we made some fixes to lip that we're using. Turns out that we had some issue with quick library uh which caused some issues when we try to simulate the network kind of shadow like of size for example uh 500 nodes or

1,000 nodes. Now it's fixed. So basically yeah we can spin up this uh size of the networks uh at least with clean for now but yeah in future maybe with other clients as well uh which is good. So we can test kind of like and figure out performance um uh requirements like in terms of uh network bandwidth, latency and so on. Um so yeah uh other than that yeah introducing changes required for the DevNet one. Um you're already testing uh uh the most recent uh changes uh for the uh signatures u uh aggregation that yeah basically was introduced in 67th p request uh to the spec and um also we finished with the

uh yeah bindings implementation for the hashsek um so yeah we can also use that yeah we implemented c bindings so yeah if other teams like Lantern need to use them, they can also do this. Uh yeah, I think that's mostly it. Oh yeah, other than that, it's not directly related to the devets, but uh yeah, in our beam, we also introduced uh soon uh which was proposed by Thomas I think uh in Cambridge. Uh so we checked the got some interesting results in terms like uh it seems uh soon gossip sub works uh when we have like high bandwidth for example

200 megabits it actually performs twice faster than um uh just classic gossip u yeah still not as fast as grid topology but yeah definitely an improvement uh when we have like lower bandwidths the improvement is not that big but Still it's there is some improvement. Yeah, we'll run some more tests just to get some average results and yeah I might check later on that uh in the group. Uh yeah I think that's all from my side.

Thanks. >> Thanks K. Uh, Parth had a question about do we have a strategy for tagging each client version to match DevNet rel match a DevNet release that would help address Solius's earlier point especially in the lane quick start. Yeah, I think it's a good idea to sort of have release process client sidewide and uh when we are uh basically collecting the information spec information for a particular devet there we can also sort of have a docker tag or branch or you know the version release

mentioned over there. Great. Uh lantern Yep. Thanks, Will. Uh, hi everyone. Um, so basically since the last update, uh, been trying to interrupt indefinite zero. um basically have reached a point where it can receive uh messages from uh ream clean uh and ze and um basically the it can process gossip messages but when it has to uh run the state transition function uh there's some pending issues there so what I'm actually doing is I'm actually uh

working on integrating the JSON test consensus vectors that are that that were uh added by Thomas um last week. Um so basically if the if the client can process the test vectors correctly then hopefully it should be able to uh process the messages uh and sync up in DevN.0. Um and uh I guess like once that is working um we'll I'll I'll be happy to look into integrating the uh hashc bindings that Camille's clean team implemented. Um and um yep and as well as lean met lean metrics u as well. Um yep that's that's the update from my

side. >> Thanks mayir. Um so I guess just taking the pulse of all the client teams um we had identified you know in the abstract a few weeks ago mid November as being um a key date to try to ship DevNet one. Um I don't know maybe like just temperature check. Are we still feeling good about that? um is there a list of dependencies that need to get out of the way other than the DevNet environment and maybe just help me better understand

where we're at in terms of delivering that. So I think uh we are quite near to delivering that uh because once our uh signature integration PR spec PR is merged which we can target by Friday uh so then I think it's about just clients integrating it and uh if they have already worked on the previous uh uh signature aggregation as a list PR then uh this change should be incremental and smaller in terms of uh uh adding the signatures and validating them. Uh so Zam should be ready to uh go for interrupts. Uh we will

actually try to uh do Zim to Zam uh interop uh starting next week and uh we can actually do uh multiclient interrop maybe mid of next week as well. All right. Um, yeah, let's just go around the home. Uh, Re, how do you feel? >> Um, I probably need to check with our team members as well, but my guess is client single client implementation uh for reim could well, we could target for next week and maybe start doing some local interop testing. Um but to

actually do it like multi- machine or do actually any useful benchmark out of it I don't think that's feasible within next week from my my my gut feeling. So hopefully like maybe we can get like simple single machine interop next week but running actual benchmark or multi machines probably going to be after defcon connect I would say >> okay >> but but maybe maybe other team members might want to chime in. >> June confirms yeah >> that outline. Um, Camille, any thoughts from you?

>> Uh, yeah, in terms of kind of binary for clean for the DevNet one, I think we should be ready next week. U yeah, basically have Yeah, already testing new signature scheme and we have bindings ready. Shouldn't take long to kind of integrate all pieces together. Uh, yeah, once we have spec just to verify that uh, yeah, we kind of have the proper version of everything. But yeah, then uh we can probably start also testing local interrupts uh next week uh just as usual figure out if we had if we introduced any kind of incompatibilities between the clients uh all of that. Uh so yeah I I suppose like binary and docker uh yeah

should be ready next week from our side. >> Uh mayor. >> Yep. Um so basically we could achieve uh local interrop testing next week. Um and if uh we could also release Docker um images and um I guess if if those issues if those arise um are resolved then we should be able to join DevNet one. Um but yeah that's great. Um, so moving on, spec updates. Uh, Tamar, I saw another big post from you last

night. I don't know, maybe if we could start off by just giving a a TLDDR on >> Yeah, of course. like um in the last week we since we mer like the P from Filipe about the test vectors we have tried to add like as many new test vectors as possible. So what we did is that we deprecated a lot of old test uh to make test vectors happen like everywhere at least as many places as possible.

And so we moved quite fast in the last week by merging more small peers rather than bigger peers that we had in the past. So this was a very good movement with a lot of reviews, a lot of people uh participating in the spec from the different teams, not just not just me or EF people but a lot of different people participating in the spec. Uh fixing some bugs, some small bugs, bigger one and um and yeah, a very good movement of new test added and stuff. So yeah, I'm quite happy with the movement that we have right now with

the spec. I hope that we will continue like that. Uh as just mentioned, we have like um a new PR that should be merged about signature aggregation. So that we should be complete on this part soon. And yeah, as I just mentioned, we have this um this new stuff of opening very small issues to track some new problems and move forward on this. I think that right now we have a couple of open issues. Most of them are already assigned. So this is a very good sign of uh people wanting to participate in the spec. So yeah, very good movement and I hope that this will continue like this in the

future. That's great. That's nice to hear like the the shared ownership and interest in Um any other specreated updates or discussion topics. I think uh it is right time to start figuring out what is the what are the P2P uh optimizations that uh we want to plan for it. So if there is any rework that is out there with regard to that uh

I it's time to sort of uh dig into it and uh also to share it as well. Yeah, for PPR optimizations there are multiple directions. First like the gossip part, how do we actually propagate signature or sorry stations and another thing is uh once we got the uh the aggregation uh well uh yeah first we should figure out like what how aggregation is going to look like whether it's like 128 kilobytes or something else and then yeah how do we distribute them to uh

everyone yeah in Cambridge we discussed that we might use ar coding for that. Actually Raul in today's uh P2P call uh later I think in in an hour so uh should discuss that some updates that he was working on. Uh yeah yeah yeah we should just decide I don't know whether we we want to experiment with uh uh kind of advanced gossiping or u honestly I would start with uh this kind of aggregation uh propagation strate strategy whether we use reg coding or anything else.

Oh yeah, I'll share with you the link. I was asking if there's any updates on DK aggregation research and timeline. So to plan for DevNet 2 and onwards I can I can briefly like uh speak about this. So on the signature scheme

uh we are pretty okay meaning that we have an implementation working. Uh we still have work to do on the encoding scheme. I think that Benedict and Dimitri are thinking about this even if this is probably like a long-term research stuff but yes they are thinking about how to have like a proper encoding scheme to have something that is efficient small and friendly to ZK. Um then on the aggregation side of things meaning that once we have the scheme how to aggregate signatures and be able to post a single proof on chain.

This is still an ongoing area of research. Um Emil is working full-time right now on uh the LINV VM. So doing some benchmark doing some improvements. Um as mentioned by uh will this Friday Emil will will present some lean VM benchmark stuff. If you are interested into that like you also have like um lin multic uh GitHub repo where you have a nice readme with some benchmarks uh and the current numbers compared to what is expected. So, so you can just check that to to see a bit more

about the numbers. But TLDDR is that um right now Emil is working on the XMSS signature aggregation not yet on the recussion part of the process uh meaning recursively aggregate proof of previous signature aggregation. Um this is very tricky because this is a ZKVM topic. So involving a lot of mass, a lot of code optimization, a lot of very low-level tricks. This is a like kind of a 10 person working group working on that. Uh some are full-time, other are part-time,

other are external people. But this is a very complex topic. So I cannot really answer with a with a deadline. uh but all that I can say is that we are we are doing our max to to be able to to reach the target numbers but like with the current numbers that we have uh with the work of Emil on the lin VM I guess that's at least even if we don't have like the recussion we still have a function that is able to to prove some signatures So this means no recussion probably not a very performant one and

probably so we will not be able to aggregate like millions of signatures together but at least we have like a starting point with some reasonable number let's let us say >> yeah agreed with that. Um so basically we can do the first layer of aggregation without the recursion and uh maybe that's that that I think the performance is is good enough to have a a death net with a single layer of of recursion and uh hopefully early next year we will have uh we'll have the full recursion implemented.

>> Yeah. And if needed for you as a client teams uh if you have like some question on like the future DevNet or some interrogation how to do that maybe Emil can also participate in one of these meetings that we have right now on Wednesday uh to introduce you just what is the function that you you should use uh how to import the lin VM library uh is there like a function that is suitable for you. Does it need some modification or some trait on the LINVM side of things? So all all of these technical question about how to use LINVM.

Uh yeah, maybe we can just invite Emil and let him speak about how to use his work. >> Thanks very much for that update. Um, yeah. So, it sounds like aggregation with no recursion is what we'll be working to implement before the end of the year and then sometime early next year is when we'll be able to start to get a better sense of when recursion will fall into the fold. Um, I mean, I think it sounds like there's also a lot of experimentation around the P2P layer.

So there's plenty of opportunities for additional dev nets between aggregation and recursion of just looking at the impact of different uh tweaks to the P2P perhaps um you know while keeping aggregation consistent and before adding in the additional layer of of recursion potentially. and then I guess

any other research related updates. It's um there's there's a bunch of progress that that's being made uh in the background, a bunch of papers that are that are being written uh on on XMSS on on pedon. Um there's also uh for lean VM um this direction of uh exploring uh open VM style modularity. So um you know one of the big advantages that we have with lin VM is that we can move extremely fast because you know we

don't actually have uh you know real work a real real world uh workloads um and it's a very small code base. So um just just last week we made a a massive performance breakthrough incorporating something called GKR. Um and it's possible that we'll we'll be making another breakthrough both in terms of modularity and simplicity but also performance with this uh with this openVM approach. So um things are progressing very fast from a research standpoint.

Uh but again like all of this should be a black box from the point of view of of the devs who who should just be calling the the library and uh and and and and just having the aggregation uh be be done by that library. So, before I forget, I really hope everyone shows up next week because I think we're going to have some uh surprises and maybe a special little thing to to

share with you all. Um, which will be fun. But I guess just so it doesn't get lost um if someone could provide me with the list of requirements specifications uh you know needed you know from DevOps pan ops um sooner than later I can get the the wheels moving on that so that that doesn't end up being a blocker for you all. Um so if anyone can provide that to me that would be great. Slightly off topic. Can anyone do a explain it to me like I'm five on how this works? I just saw it a

few days ago. This is actually I believe um the main topic of Ethofru's call 6 which is this Friday at 2 p.m. UTC. So Ben and Angus will be there uh giving a presentation. I cannot explain that to you like I'm five. I could I would listen to one but um yeah that that will be one of the main topics. So uh there's going to be four different speakers talking about uh uh proximity prize related topics including that.

Yeah. So there's been a lot of research breakthroughs on on that specific topic called proximity gaps which is basically the foundations from a information theoretic standpoint of of the the hashbased snarks that we're working with. Um a lot of the industry is leaning on these these open conjectures. Um and uh we probably don't want to be leaning on these conjectures for for Ethereum layer one. And so we're putting a lot of effort to try and and close them off and that's going to lift all boats. And we've made progress both on improving the attacks. So the conjecture has actually been shown to be uh at

least slightly invalid and validated. Um and on the other side we also have much better uh provable results which will be shared and arguably both results are are breakthrough results and uh I guess it's it it's part of the fact that it's such an important topic nowadays because the whole industry seems to be moving in the direction of of hashbased knocks and uh yeah a bunch of of these ideas actually originated from from Cambridge.

So, um, you know, there's a little bit of latency, but, uh, the the fruits of of of Cambridge are starting to bear. >> Okay. Um, any other open topics that people would like the floor? Um, if not, we can call it a call.

>> All right. >> Thank you, Will. Thanks, guys. >> Yeah. Talk to you soon. Take care. Thank you, dude. Bye. Thanks, Will. Bye. Thank you.