Post-Quantum Interop Call #17

Transcript

Anyway, looks like people are getting into the right spot. Um, so been a pretty busy last couple weeks for a bunch of people traveling and whatnot. Thanks to Gadinger and everyone on this call for holding down the fort and continuing to move things forward and and host the calls and in my absence. Uh, so I really appreciate that and looking forward to getting caught up to speed and see where things are at. Um, maybe we can just start with client updates. Uh, Ze, do you guys want to start us off?

I will. Yeah, we can start off. And uh, so it seems like uh things were a bit slow because of Dev Connect. Uh but in the meantime uh we were working for uh lean quick start interrup uh for net one and sort of we took lean quick start to the point now where we can have the interrupt between different clients and uh right now z and dream is trying the interop and we are facing some issues over there but I think uh we should be able to resolve it pretty soon and uh uh then we should also be able to interrupt with other client times.

>> Yeah. And um for that's pretty similar I guess. So mostly prepare for devet one. Um last week we added support for like the latest genesis config validated registry and so on. Um I think our code is also up to date with all the lean spec changes including all the like the small refactors. Um and yeah so mostly I think we'll be just discussing uh debugging the interop issues that we are seeing with team right now.

>> Great. Uh lantern. >> Yep. Uh hi everyone. Uh so yeah I'm sort of in a similar situation. Uh I'm currently using lean quick start. Uh I'm basically being able to use lantern against zen. Um I've added support for uh lantern sem lantern command script and it will accept the config uh that l lean quick start is using. Um it's able to connect with ze. It's able to send votes via the gossip uh and receive blocks. Um and I'm just basically currently debugging issues where like the chain cannot finalize or uh like the state ends up diverging. Um so I'm just currently debugging those and um I will

be reaching out to the Zam team uh later this week uh with a PR uh for like the lantern integration. Um but yeah, that's basically what I've been working on. Yeah. >> Great. uh and clean. >> Yeah. Um or should I say that we also in the same situation? Yeah. Basically, we caught up with the spec uh recently. Um at least for the state of spec for the day before yesterday, I believe. Um yeah, so that we have hash sync and everything. Uh even updating for the most recent uh lining. Um yeah, also starting uh checking the interop. Uh

yeah, we will create a pull request to the link start I think in the nearest future. Yeah, we just uh uh yeah had some technical issues to create a docker uh once it's there. Yeah, we will open a pula so that it's easier also to test uh with clean for others. Uh yeah, currently I just locally tried to run it together with Zim but it didn't work. Uh I didn't have much time to debug the issues but yeah it's the environment for debugging is there. Um, so yeah, I was starting to the checks. What's going on? Thanks.

>> Okay. Um, I was trying to add a poll, my first poll in Zoom. I don't think it went successfully. Uh, I was going to ask currently at this time, you know, among the devs, it sounds like sort of a repeated theme in the feedback. I'm just trying to get a sense of u of where we're at with things. Uh in terms of the percent of cycles of you know the work contributed right now to the DevNet is it would you say that it's like 50% to DevNet related infrastructure that will be repeated and 50% to spec related like implementation of uh the signature aggregation and like the sort of um you know theme and the the features of the

DevNet um or like more than 50% going to infrastructure or less than just curious if we could do kind of maybe a quick around the horn in terms of like uh getting a sense of uh in aggregate like how much work is um going to like infrastructure versus uh the actual features of the devet. There is no like right or wrong answer. I'm just trying to get a sense of things. I mean if you mean by infra infrastructure is the interop uh configurations that we are trying to do for example in kickstart uh I think it's 15% of the total work whereas 85% is definitely going for spec and client

implementation >> okay sorry did you say 15 or 50 >> so 15% I would say for infrastructure and the 85% for client implementation and spec development. >> Okay, great. That's good to know. Yeah. Um, that helps a lot. Excellent. Um, so then maybe moving on to uh specs, speculated updates. Um, >> yeah, I can let's close maybe >> just very quickly before we go to to the

spec thing. Uh, I think it would be great if Manash from Lighthouse could also give a quick update. I've talked to him last week at Defconnect. So maybe Mana take take the chance and give a >> give a quick update. >> Thanks very much. Yeah, great. >> Um, yeah. Hey guys. Um, so I I missed the client updates uh section, but um yeah, I I spoke with uh Lattis loss in um Burner series. Uh like I I did some grinding through uh Dev Connect and then like I was able to interrupt uh the current spec with Lighthouse. I haven't been able to like uh do it with other clients. I'm still

like working on it but um yeah the like lighthouse is currently like in dropping with itself. Uh I haven't posted it yet like all the implementation. Um, I'll probably like finish everything and then maybe post uh the ER to lighthouse which contains all the lighthouse consensus on the PNQ Telegram group just for like uh getting some eyes on it.

Thanks guys. Yeah, that that was mostly my update from my side. >> Great to hear. Thanks. >> Thank you. Um, any remaining client updates. >> Okay. Um, spec updates. I think Tamar, you wanted to start. >> Yeah, I can I can talk. Um, I I think that I have various elements in mind. Um the first one um is that I have just understood from your words uh in client updates um it seems that maybe you had

difficulties to keep up with the recent change in the lspec. So for me this is just like um refactoring uh regarding like uh the current status of the specs that we have to make things easier to read uh to make things cleaner to decouple properly the files uh to try to remove some duplicates. So this is just basic refactor. So if you want uh us to stop this kind of pier before we do devet one that is totally fine for me so that you can keep focus on the core uh stuff you are doing and not spread yourself among like various minor uh

updates. So if you want that you don't have to to answer it right now. You can think about it and we can discuss offline. But if you want uh us to stop working on these kind of small PRs until we reach devet one, this is totally fine. We can just keep up after that. Um on the spec, I found that recently it was a bit of a mess for you about serialization and derialization I of signatures. I have seen a bunch of peers from various people from various teams um to touch the signature size the number of byes and stuff. So that seems

a bit messy and I just discovered very recently that what you was you were doing is that you were uh doing like a serialization towards like via bin code and then from bin code to SSD because SSD was not natively available um on the lining repo directly on the linting repo directly. up to now we just had like a basic bin code derivation of sterilization and deserization and so it was if I understood correctly it was a bit of a mess for you. So when I discovered this um I directly implemented the SSD uh serialization in

the linig speaking about which like um will just dropped the link for two PRs in the linseig repo. So last last week, beginning of last week, Benedict just moved the repo from the old uh repository to this new one. So we will have now these two repositories that will exist together. The one of Benedict will be very close to the paper without any optimization and just uh something really representing the paper.

And the second one that's uh we'll just drop the link to will be dedicated to speed and uh Ethereum usage. So for example, we removed SHA and we removed a bunch of useless things and we implemented SIMD optimization techniques inside this. So this will be dedicated to speed and to Ethereum TLDDR is that for you client teams you should use this new repo and in the two PR I have just started implementing the SS after we merge the second PR SS should be complete uh on the rest. So you will be able to use the classical

um SSD encoding and decoding that you are used to. I for this implementation I just use the sig sigma prime implementation that is used by rest for example. Uh so very basic uh it seems that what you're using uh rim um so please the the first PR is mer the number 12 please when you have time just check the number 14 so it is a big a bit big because this concern a bunch of object we have to apply that to uh the secret keys and to the signatures and for everything to be SS compatible

possible and I have added a bunch of tests to be sure about what I am doing. So please check that the ideal situation like I mentioned in the channel yesterday is that for you rim team to just run a bunch of tests by plugging your repo to this branch to see if uh the everything is smooth or if you have like panics or errors or anything. Once this is done and after you review and the review of Benedict I will merge this and after that I will replace all of the serialization in the lean spec by this serialization. So this means that

everything that we have done to transform to beats and from bits to signature I will remove all of this and I will just replace by the simple SSD serialization that we have with tests to be sure that we are all on the same page. So that is um one point about devet one. I I I don't I don't know uh if I have two things in mind. So aer we continue like this for devet one everything is fine with this and uh we just continue and we can keep the full SSD stuff without bin code for devet 2 or you feel that this is too much of a nightmare for you. you have

many troubles. And so this means that we have to review and merge the number 14 PR as soon as possible for me to be able to to do the the lin equivalent as soon as possible for you guys to to be able to run on this. So that is up to you. For me, this change nothing. So just up to you client teams, what is the best solution for you? If all of the bugs are solved and right now you are you don't have any more issues with that I just recommend you to just keep asse otherwise uh I recommend that we switch

now um so that was my first point something that I wanted to to do in the spec. Secondly, in the spec, I feel that now the test vectors are too slow to run even after all of the updates we have made. I think on the CI right now it takes like three or four minutes because we have to generate the keys and even if we have a caching system that reuse the keys and stuff, this still is too long because we have like less than 30 test I think and I I think it is too long and not friendly to run on a local computer because even for for one single test it is about one minute because the fact

that you generate one test or multiple test doesn't change the fact that you have to generate the key. So I have to think about this after serialization but I have to think about this probably the best solution would be to pre-generate the keys store them into a JSON file or something and just read the JSON file. It will be much much faster and so it will be much more friendly to debugging and test running locally. Um so that are my two main points that I have on the spec. So first the SSD. So please guys um review the PRs in Rust.

Um uh no it will be no for for so while we are this and with the comments that I made about like LINC compatibility it will be removed with SSD. Everything will be smooth and compatible. So yeah, no problem anymore with SSD with that. So my second point was about like slowness of the of the test. So I I will try to make it them faster after we solve SSD. And I had a third point to raise. It was about um the lean VM. I think that Emil is in this call.

>> Yes. >> Um yeah. And so as far as I understand as you have raised in the in the group you have worked a bit to make uh things compatible uh with the with the client teams so that for devet to they will be able to interoperate and call your lean VM to aggregate signature. So the floor is yours maybe just to to explain. Yeah. >> Uh thank you. I don't know to what extent it is really compatible because as explained in the previous call um due to the nonzk friendliness of the encoding currently implemented it's it's not the same XMss. So but I have what

I've done is a file in which I have put all the relevant um structures and functions that enables you to uh sign verify uh aggregate sign and aggregate verify signatures and also generates secret and public keys. But I have no idea what format like if you want the signature to be a bunch of bytes or if you want it to be a vector of collabor field elements. I don't know. So if someone has feedback on what is required that would be appreciated.

Yeah, please. Like, >> wasn't the plan last week that we sorry, wasn't the plan last week or last meeting that we use the scheme that is currently in the lean sick and we just do a naive aggregation of the of the randomness and then the rest is is proven. So, what you now said sounds like you just have another signature scheme. No, >> not build on definite one. Yeah. Okay. I didn't have time to do this, but I will definitely do it. But also, I don't know to what extent it's easier if I do everything in a a single crate or if I create a branch in the linse repository

and also I would have >> I mean ideally it should be a I don't know it should be a new crate that uses the lean thing as a black box. Yeah, I recommend that as well because um so so first about your the scheme that you just described it is not like something that you should do right now because for DevNet one we will not have aggregation and so this is a topic for DevNet 2. So this is not for tomorrow. Um, and for the crates, um, I would recommend also like to just create a a small crate in the linig repo because when you will upgrade with new performance things and it seems that you

have new performance updates that should arrive very soon, then if you do a separate branch that it will not take into account this new performance optimization. So that is probably better to have a crate that can be updated as long as you update performance I guess. >> Okay. Okay. Okay. Okay. Okay. Okay. I will do this. Okay. But so so okay. So to be it's not like extremely urgent. Okay. Okay. Thanks. >> Yeah. I I don't know you client teams if you have like um a sense on when you will start to to be interested by this.

In any case, I think that Emil just uh dropped the link of his work in the in the LIN dev channel that we have on Telegram so that you can maybe just start to check and uh see what is okay, what is wrong, what you can call or not. But yeah, maybe this should be useful for you first to check this and second to give maybe Emil a timeline of when you want to start looking at this. Um I think to my at one point you

mentioned not for tomorrow is the like that brings us to the next topic about uh the DevNet one schedule. Sorry if I missed this is the schedule for that to go live tomorrow or SAS I also see you have your hand up. >> So just a one note that is also working on on the lean client which is still very early days. So we are not giving updates but uh uh for this signature library uh the note would be that uh we have our own SSD library.

Uh so there may be some um some inconveniences uh if the uh signature library will be uh kind of connected or or locked into lighthouse library. >> Yeah. Yeah, I understand your point. >> Yeah. Okay. So just keep keep in mind that maybe >> yeah I think it should be discussed with Benedict Benedict I don't know if maybe as you you didn't review that yet maybe you don't have a full sense of this but in summary

I I use the Ethereum SSD library that is provided by the Sigma prime folks and so I integrate this directly into the linseig repo but if you guys have to use your own SSD library. That means that we will have to to put the fields inside the signature public so that you can access them and implement your own SSD, right? Uh you could also just uh export a function which just gives us like >> the bytes as well which is what like ELS like >> I mean wasn't that okay maybe I mean I'm not an expert on rust and serialization

but like wasn't that the initial thing that we had like all the types were kind of they had serialized and d serialize already. Yeah, but you said there's some sort of problem with bin code or something which I don't know. >> Yeah. Yeah. Because in fact, yeah, the initial stuff that we had was bin code serialization. So you just derive serialize and dialize for from S crates. >> Yeah, exactly. >> Yeah, it's automatically transform your signature object into a bunch of bites for example. But this use a very specific uh format of Russ that is bin code with a bunch of specific stuff. And

at the end what client teams were doing is that they were doing from the signature to to to bytes via bind code and then from this to SS because at the end they just want SSD to work and nothing else. And if we had to replicate the bin code serialization format in Python, this was a nightmare because the field uh was serialized using mongomery form. And so this means that we will had to add like mongomery form into python.

In summary, this was a mess. Um and at the end, what they just want is SS. So I found it more convenience uh to implement SS derivation as well in complements to the traditional third theization so that you guys can can play with it. But yeah, we can for granting TLDDR is that we will find a way to expose you the proper bites so that you can interpret via any SS library that you have in mind. Yeah.

And yeah, if you can give uh before we talk about like devet one and stuff as we'll just mention if in the telegram group you can give a sense you don't have to do that now but in the coming days or weeks to give a sense of the timeline for email to check the compatibility ility with the LINVM. I think it could help him to to check this uh when needed. >> All right. Um yeah, and thanks for migrating over that or creating that

lean sig repo within the the lean the lean Ethereum org. Um, so now I guess let's maybe just get a better sense of of where we're at in the path to uh shipping DevNet one. Do people have a date in mind or a percentage that they can assign to uh completeness in terms of having all the specs implemented that we're hoping to feature in DevNet one?

Uh Ree is I think Re and Ze already. I'm not sure about the other clients. We're mostly just like fixing interop bugs right now. Uh maybe clean lantern lighthouse grandine if you have any thoughts. Yeah, for clean I would say we very close to start uh fixing interrupt bugs or already starting >> um yep uh from from our side as well uh just resolving intro bugs um and uh yeah

we'll reach out to the zen team uh with the PR uh for integrating lant into quick start yeah >> and then sorry lighthouse I don't Yeah, go ahead. >> Yep. Um, yeah. Uh, right now like I'm in dropping with Lighthouse, but uh I'm going to try to do an interrop with other clients as well. Uh, but since I've not done like and drop with other clients, I just um I'm not sure if I'm spec compliant for DevNet one. So I just wanted to know what's an exact spec for uh DevNet one so that I can like crossverify if I have implemented everything uh since maybe I might have

missed uh the exact call where like the net one specs were like confirmed. Yeah. And for grand we actually have a bit different flow. We I think the code base is is a bit immature. Uh however we we started to to debuck it by doing interrupt. So technically we are doing interrupt but I think we are behind the some other teams that that are doing interrupt now.

We have also maybe I think uh we can drop another uh MD file like we had for devet zero uh to provide for the spec for net one and various images and branches that are relevant. And so yeah, we should we should come up with that and maybe me or can do this VR. >> Yeah, that'd be great. I think that we we started sort of months ago, you know, with I think Katia pasted a link to the ETH bandops style, you know, one pager for DevNet. Personally, I would love to

get back to that and would be, you know, more than willing to help maintain it. I think getting it started at this point is going to be uh a pretty heavy lift for me. I I just don't have the context, but um yeah. Oh, if you could get that started um and open a PR in the PM repo of the lean Ethereum org, uh that would be fantastic. And then you can rely on me to like I'm getting in the habit of of keeping the the weekly meeting issue uh you know full of PRs or that's kind of the the goal that I have for myself and so I can

just like keep reconciling that with the the DevNet one pager as we go. So I would be more than happy to like uh really sort of lead on that ritual. I think it's just a matter of of getting it started. uh from a for dev. One completion in addition to successful interop and chain finalizing we should have metrics collected based on baseline hardware or sorry should we have metrics collected based on some baseline hardware and specs as well. I assume we want to start

tracking some performance. Uh yes and that could be a good segue into Katcha talking about metric metrics. Kaja >> uh yes hello everyone. So uh the updates about metrics. This is why I asked about the the one resource for DevNet one. So uh not to lose anything uh I would like to start already to add um some DevNet one metrics but uh I still can't um get the metrics from all clients all three clients. So currently I can see already um state transition metrics from Zim. Uh

sorry I just got back yesterday from dev connect. So um I can see state transition metrics from ZIM and there is um we have a discussion about fork choice metrics um which Zim uh probably could look into. There is some issue with the gossip and blocks attestations. So and I would like to know the status from uh from clients. So uh are the metrics definite metrics uh definite zero metrics maybe merged already or we can collaborate on this?

>> Uh someone on our team merged them. Uh I think you should like run and check if it meets your uh like standards but we're basically using your guys's dashboard in our in our internal tooling and our team members said it works. So let us know. Yeah, sure, sure. Thank you. Okay, so until the next call, I'm going to check to check all the three clients. I want to see them on one dashboard and uh I will keep you updated and we'll look into DevNet one as soon as um I have some maybe updates, new PR for DevNet one and I copied the wish list from the rim team so I can start

working on this. Thank you. And one question about attistations. So there are attestations from the block and from gossip. Um do we want to split them on the metric side? We can add label let's say let's say block and gossip just toident identify them where they come from. So if that makes sense um please feel free to let me know maybe in the telegram group or and I wonder if requestp also expected to be added later or we are just on

gossip because in this case um request metric will also I mean label will also be added but we can add it later. Currently, we have the param in the verification function in the specs is block or something like that. Uh but maybe it's not the one case. It can be block or gossip or later recresp. So it can be three options later. Yeah, I think uh we should have different labels and one of the label that as you mentioned is the total you know the normal uh network gossip attestation that is there and then gossip block at a

stationation and uh I don't know whether there is any use for request blocks attestations because uh I mean if uh uh client is you know pulling blocks and processing them I I don't know what we want uh uh get out from there. So in my eyes there are two uh sort of you know labels that should exist for test stations which is just network attestations and the other is gossip block test stations.

>> Yes, got it. Okay, thank you. Um so as soon as I have three teams on the dashboards um I can try to uh to add labels. I will keep you updated. Thank you. >> Thanks, Kasha. Um, any other discussion items? So, oh, I appreciate your offering to prepare the one pager by the end of the week or so. And yeah, I will that'll be a great resource for us to

have and and one that I will take pride in maintaining moving forward. Um, so is there a target date that we want to have for DevNet one? Should we say by a week from today that we're celebrating it on the next call? I guess that's a little hard to determine just cuz it like depends on how quick we can like finish testing like interop bugs between clients. But I think we should have a good answer next

call if we're ready or not. >> That is sounds like a great plan. So yeah, the goal for next week is to just yeah, really get full visibility on interop bugs and and d-risk a timeline. Um have the one pager pulled together and um yeah really >> and we can also start looking at uh uh the lean VM API I think I mean shared uh and uh then we can basically also think about how we'll integrate that. It looks simple enough from the first looks of it, but uh yes, I think that is something that we can also tackle out in

the next call. >> Fantastic. Uh is there anything that would be blocking anyone's ability to move on those things or make significant progress on those things that we can talk about right now for the last 20 minutes? Are there any other just open discussion items that may be orthogonal to those items that people would like to discuss?

All right. Um, tomorrow is a US holiday, so I'm going to be uh probably offline. Um, but if you're into celebrating Thanksgiving, have a great Thanksgiving. Otherwise, have a great Thursday. Uh, we'll see you next week. >> Bye. >> Thanks everyone. Bye. Thank you. Bye >> everyone.