Post-Quantum Interop Call #44

Transcript

Thomas Coratger: Hello, everyone. So, let's start… So today, I think that what we can do is, as usual, like, a client update, then… I will talk briefly about, like, lean spec simplification, I have moved quite fast on this, and I am preparing, like, now… between now and the end of the week, some slides. to share with the other, within the EF. about the progress that we recently had about the inspec, and the future of the inspect, maybe. So I am preparing that, with some… upcoming… upcoming simplification, but I think that we are pretty good right now.

So we can talk about this, and then we can finish with some DevNet 5 discussions around, like, maybe your debugging issues, or stability issues, or anything you feel is important. I have seen a couple of messages in the chat that we can discuss. I think that a couple of people are not there from the EF, because there is, like, some events around the world this week. But let's get started, with first client updates. So, the Zoom team first.

Gajinder Singh: Thanks, Tomar. Yeah, so we have been working on, DevNet5, making our client more stable, fixing issues that we are seeing across. We ran shadow sims in which we were getting stalled, so we fixed some issues around that. And then, while running, Zoom or normal… normal clients, on normal machines, we noticed that roof merging is taking a whole lot of time, so we tried to run on different machines, and we noticed that on a heavy machine like i7, But in Jen, we were able to get the proof merged, like, in the required amount of time, like, in .4 seconds or 0.5 seconds. So basically, we… we need to really, work on the efficiency of proof merging. We also intend to deep debug into scenarios

There, where splitting is required, and, measure its.

Thomas Coratger: when you mean proof merging, you mean when you have two proofs, and you aggregate the two proofs? This is what you mean?

Gajinder Singh: Yes, so… so the proposer, after basically, you know, it signs the block, it needs to aggregate the multi-message proof into the final block proof.

Thomas Coratger: So that's…

Gajinder Singh: That is a proof that I'm talking about, and…

Thomas Coratger: This is the aggregation layer, like, the recursive aggregation layer. Not when you… not when you produce a proof of row signatures, when you produce a proof from two proofs, right?

Gajinder Singh: Correct. So in recursive, right, so there is… there are two types, of things that are running, right? There is type 1 recursion, which is happening for… where the data message is same. And, we basically need to scale and see what are the metrics that are over there, but even before that, we need to basically make sure that We are able to prove, to, have a multi-message, block proof in the right amount of time, because otherwise, for example, the block proposal is getting pushed to the last interval. Of a particular slot, which basically means that everything is late for everybody, even though, people, even though nodes are able to attest and justifications are able to move, but everybody's voting late.

And, it might basically lead to instability in the network. So… so we… we basically noticed that on a machine like Core i7, Basically, which is… which is 20-core machine with 28 threads, you are able to produce that proof in time. And, so… so we need to basically work on that. And what we also already have started working on is what I discussed last time as well, is to also start type 1 aggregation beforehand, right? So, in the last interval of the previous slot. So if you know that you are a proposer, next lot, then you start early, and you start basically working on at least at least the type, at least the aggregate… aggregation of…

attestations, right? So… so we… we are working on those optimizations, and the PR is up, and we basically need to test it, debug it, and then we also need to, as I said, test and debug the split-proof mechanism, because If there is a movement on… On a, branch. Which is basically not the main branch, then we need to also include its At restrications on the main branch. So, we basically also need to figure out and test and run those scenarios. Apart from that, we are working on integrating ZigglyP2P, so there is that, track of work and debugging is also going on. So we have achieved some success in integrating a Ziggly P2P version, and we are figuring out what the issues are coming up on that.

And, so… so that we can basically then have a stable interop. It won't be a full Ziggly P2P, because we are only concerned about, what… is required in Zeam and Lean, Ethereum as of now. And we will basically keep adding the features as we go along. Apart from that, we also, updated our client with the spec improvement PRs that have been happening. So… Yeah, it's bus… been a busy week.

Thomas Coratger: Okay, great. Thanks a lot, Ream.

Shariq Naiyer: tweet. How's it going, guys? So, on the… on the Ream front, we have been keeping up to date with the spec, stability fixes that have been brought up. On the DevNet 5… on the DevNet 5 front, we're doing some local testing, but from what we find, it's, slightly more resource-intensive than DevNet 4. So we have been taking the time to… to run 24 validator deemed DevNets, and what we found… DevNet 4 DevNets, because I want to fix out some of the issues that we were having with excessive memory usage, like, finalization delays, justification delays, because we know, off the resources usage of DevNet 4, I want to fix these issues on Ream in DevNet 4 before we start, because, like, the… I would see sometimes that the RAM usage would grow up to, like, 28 GBs. So these are things I want to fix in DevNet 4 before we move over to DevNet 5. And yeah, that's what we have been… so, we put a new memory app

allocator, that has, that has, we've improved pruning. And we've improved, like, block processing times and minor fixes here and there that have improved the performance quite a bit. So I aim to be moving to DevNet 5, pretty soon now.

Thomas Coratger: Okay, great. Clean. London?

Mihir Faujdar: Yep, thanks, Thomas. Hi, everyone. So for last week, I found the likely root cause, for the snappy decoding error that was, being reported in Zeam, and have implemented, those fixes, and then published the image last week. And as well as added support for the aggregator skipped metric, that was… that'll be helpful for debugging. And for this week, I've just been, working on small optimizations for block building. Basically, in order to measure that, I've been running the DevNet locally with just, 3 other clients, with Lantern being the aggregator, but, on average, you know, it would take 0.9 seconds, so any improvements I add, outside of the… the cryptographic library, like, if I'm blowing optimization lantern, it's hard to measure, so basically I'm planning to test with larger number of valid… like, increasing the valid account and the nodes,

And, as well as, I'm still currently exploring pathways to speed up the aggregation duties. Thank you. Yep, this is for depth at 5, sorry.

Thomas Coratger: Okay, great. Eat Thunder.

Gajinder Singh: In DevNet… in DevNet 5, you are getting about, 0.9 seconds to do a block proposal?

Mihir Faujdar: Yes, basically the metric that I'm measuring Just one second… Yeah, so there's a… in Lean, we have, Lean metrics, we have lean block building. time seconds. So that's the metric I'm measuring, yeah.

Gajinder Singh: block building time could just be without the final block proof. So, does that include the final block proof, or not?

Mihir Faujdar: So currently it's just, so currently I have, you know, Zeam, Lambda, and Lantern. So those are the clients I'm running. This is for DevNet5. Basically, it measures the… so it basically starts the clock, And then it calls the, you know, the C leanVM bindings library. Which calls the function to, you know, create the… like, merge the proofs, and then basically return the bytes, and it stops the timer. I guess that's what the, lean block building time seconds is measuring.

Gajinder Singh: So, there are two kind of things that are happening. One is, basically, you are aggregating the aggregation, payloads, right? And the second thing is then you create a final block proof. So, does that include the final block proof or not?

Mihir Faujdar: No, it's only for block, block building, yeah. Yeah, so as I mentioned earlier, I'm still… So, like, primarily focus was block building. I am still currently exploring optimizations for just aggregator duty, yeah, which just includes the, you know, the single message aggregates, yeah.

Thomas Coratger: Okay, thanks, guys. Ethlambda.

Pablo Deymo: Hello, hello. We… we merged the Unified Support for Membrance. We align, fourth choice finality and aggregate validation, sync status heuristic with lean spec. Long Branch Sync now uses blocks by branch instead of one block at a time request. In the metric side, we implemented the cross-plane lean agroator skid total counter, attributes. They said? Missing aggravation by reason, sorry. That we talked last week. And we also started working on something related, or some kind of proposal for DevNet 6. We are implementing a Gloas prototype. To propose it for us. Maybe for W6, or for a future deadlines.

So that's it for our side. Thank you.

Thomas Coratger: Great, thank you. Gean?

bankat: Thank you. Hello, everyone. So, this week on DevNet 5, we focused on bringing Gean up to date with the latest lean spec changes. So, while most of those updates were more of documentation, improvements, and internal refactoring, I guess the review process helped us to identify and address a couple of areas where… our behavior could diverge from the specification. So, based on the review, we've now… Align those cases with the expected behavior. So, this will help to ensure that Gean remains consistent with other implementations, and reducing any risk of interoperability issues. So, for the leanVM side, everything is still stable, and we don't anticipate any impact from recent, reference implementation updates we've made.

So, looking ahead, immediate focus for DevNet 5 is to continue testing against the live, multi-client interop. while we keep tracking specification updates, and also stay aligned with development as we move forward. So that is it from Gean's side. Thank you.

Thomas Coratger: Great, Grandine?

Mercy Boma Naps-Nkari: Hi, good afternoon. I don't know if I'm huggable. Sorry, am I audible?

Thomas Coratger: Yeah, yeah, sure. Yeah, sure.

Mercy Boma Naps-Nkari: Sorry. So, last week, we bumped our gossips of MQFix, and then, we noticed some things while running the demo locally. For example, the… Oh. The, type 2 final block proof stack, like, it's up more than the, 4 second, time slot. So, we currently have, 30… 35% of builds, and then the fourth second slot budget on every block we proposed, which is pushing late, Proposals, and then… the finalization was sort of bumpy because of this, so I… although, Camille did mention that we need to look, sort of, like, look into, Bumping up the timing a little bit. I don't know what… that's another question I want to ask. If that is something we're trying to consider also.

Thomas Coratger: Sorry, can you repeat the end of your point?

Mercy Boma Naps-Nkari: So, I was trying to say, while running the DevNet5, we noticed some things with, the type 2, proofs. It's sort of like… eats up some time, so finalization is a lot of, sort of bumpy. It doesn't happen… The… on the normal way it should happen, so… I'm asking, do we kind of, like, bump the timing a little bit? Because Camille did mention about it last week. he did say, we need to look into bumping either the 800MX or the 4 seconds time slot.

Thomas Coratger: like, I am not sure, but the gender, is it not related to the problem you mentioned when you say that this is kind of type 2 proof? take a long time to… to be aggregated.

Gajinder Singh: It is the same problem, and Either we bump up the specs. of the machine to something like, Core i7, which is, I mean. On a very high site… on a very high site, or we improve the efficiency of type 2 proofs, or we basically increase So we will have to increase the slot all the way to 12 seconds, because on a normal machine, it is taking, like, 2.6 seconds of Type, 2… Proof… proofing, and if we basically say that, we will just… so if neither the optimization and nor… The hardware bump is to be expected, then we will have to bump up The time to 12-second slot. But I think, I'm assuming that there is a lot of optimization juice that can be squeezed out.

For the type, 2 proof, and since Type 1 can also, start In the previous interval, typhoon aggregation can also start in the previous interval itself. So, that will give a whole lot of breathing space for type 2 proof. But again, it is currently at 2.5, 2.6 seconds, and… Squeezing it to less than 0.8 second, On a normal… machine is, I'm assuming. It's going to be hard as…

Thomas Coratger: Yeah, please, mercy.

Mercy Boma Naps-Nkari: Yeah, okay, I just wanted to also mention that we are actually not doing the it's, as a station park entrance, we were only going with 4, because that was the reason why we had to, like, reduce this to… instead of 8, we went with 4. But, the deadline is still, like, the proof is still, like, surpassing the deadline, so… Just wanted to add to that.

Gajinder Singh: So, I think the primary question is that, what kind of… speedup slash optimization do we expect in Type 2? Proving. So, I guess that would basically tell us what path to follow on.

Thomas Coratger: I think Amy is not here, because he's at some event right now, but I think that he's the one, With the most answers about this topic. I don't know exactly, the margin that we have in terms of improvement, but I think that, for example, this is not a 2X. If you expect a 2X, this will not be a 2X. so yeah, we should probably ask him. Also, this is important, like, the branch that we are using right now, I think this is the branch of the proven, like, XMSS. which is the EV XMSS, but right now is working on some smaller XMSS signature. And so, this may improve as well. our results, yeah? But we have no proof for now.

So yeah, this is something that we can discuss async. I heard you, like, we have a couple of staff to discuss, either increasing the machine requirements, or maybe increasing the time, For a slot inside the spec, or maybe, Having a better efficiency on the proof. So, yeah. Let me note to that point, and we can discuss that async. But yes. I will post a message async on the channel so that Emil can see it later. Mmm… about, like, some follow-up discussions. So, let me first, talk a bit about the spec and our research client update and stuff like this. Spec update, sorry.

So, as mentioned, and I have worked a lot on the lean spec simplification. Because we want to showcase that to… to some people, and so I am preparing right now some slides. After polishing a bit the spec, I think that I am… now this is quite polished, and so… I am able to prepare some slides to showcase what we are doing. I have done, like, a couple of audits of the spec, trying myself to find bugs, plus some agents, plus some other stuff, plus some testing, plus some other… some other tunings. So that I think that right now, this is pretty much ready. even if we can improve it a lot, I feel like for, let's say,

a project where we have a small number of people interacting with. This is pretty cool. So, I will prepare some slides. I can share the slides later this week or beginning of next week with you on the channel, so that you can see what we are discussing. But mostly I have conducting, like, some… audits about the Python aspect of the spec. For example, if we can use any standard library function instead of 10 lines of code, then I have replaced that. or if some functions are unused, or useless, or badly typed, I have removed that as well. sometimes we had big blocks of documentation that we generated on the fly with AI and stuff like this. I have tried to make this…

quite condensate in order to be readable and everything like this, while keeping all of the details of the papers and the justifications and stuff. I have also tried to add more… more tests, so that you guys can consume these tests and be sure that all of your things are correct. We had, like, quite a, also strong past weeks with the Plonky3, because in Plonky3, we merged, like, a couple of different stuff. We received also some… bugs reports or stuff like this from external people, so we solved a lot of them within Weir and outside of WEIR. Right now, also, we merged yesterday the skeleton of, multilinear proving system within Plonky3, because before, we just had a univariate fry-based

proving system within Plonky3 only, and no multilinear stuff, end-to-end. We just had WIR, which is only the PCS, but not the world proving system with the constraints and stuff like this. So yesterday, we had the skeleton for this, and we are incrementally, pushing this into Plonky3 so that we will be able to have this kind of… multi-linear proving backend a little bit like LeanVM within Project 3. Regarding leanVM, Amy is not there, as mentioned, but he's working on continuous improvements and thinking about maybe the future of proving system and stuff like this. With different branches, different source of optimization, different steps. That we are discussing right now internally. So yeah, that is all about the research topic and stuff like this.

So yeah, this is pretty much all what I have in my plate right now. I think that we have discussed a couple of stuff about DevNet 5, So, if I understand correctly, the principal stuff that we should have in mind for DevNet 5 is proof… Timing. If I understand correctly. you observed, you guys, that doing the DevNets in DevNet 5, like, the fact of generating proofs takes a huge amount of time, and so we should find a solution about this. Either, like, bumping a bit, the slot time, or using fancier machine, or squeezing some juice within the proof constriction, but we should find some stuff there. So yeah, if there is anything else to discuss, Mega, yeah, yeah.

Mega | Lambda: Yeah, it's just… I just wanted to get into attention that I think you, Toma, already mentioned this in Telegram, but we got PR from Lambda on the spec, changing the block building algorithm. We made this, I think, already on DevNet 4. I think it's relevant for DevNet 5, for the, this, problem you're mentioning, the… well, I think every… everyone saw that, Type 2, or our agent in general, when proposing the blocks, is taking too long. Part of the block building algorithm, the change of the block building algorithm, basically. splits the… changes the way that the blog building is structured. We basically have, like, a… A simulated state from which we score the different attestations, and we pick

the best one each time. I think with that, we can maybe cap, from the block building side, the amount of attestation data that we include in the block. Also, taking into account if any of those attestation data is needed proofs to be compacted, like with type 1 aggregation. and take all of that into account when building a block to minimize the amount of time we perform migration during block building. I think that's something that needs to be explored also. And we look…

Thomas Coratger: PR791, correct?

Mega | Lambda: Yeah, we, like, the algorithm, the current algorithm doesn't have into account the… all of this. It just takes into account justification and finality. And the PR doesn't, the… the… the… it's mostly for clients to, like, see the structure and see if it's… if it works for them. It's maybe a little too complex for the… for the spec. I don't think it… it needs to be merged. But, I think…

Thomas Coratger: Yeah.

Mega | Lambda: Might be useful for clients to…

Thomas Coratger: Yeah, that was a bit my point, when I have seen the PR, yeah, indeed, I think that this is useful for the client, I agree. Because I have seen this new structure, but I was a bit afraid of merging this into the spec, because it had a bunch of complexity into the spec, and as we are trying to simplify a lot the spec, it adds… A lot of complexity, but maybe, yeah, we can flag this. In some sort, so that you, you client teams can explore this idea. And maybe we can check if we merge it or not in the spec, not sure, but… Yeah, maybe first you client teams can explore this idea.

Mega | Lambda: Yeah, I just wanted to get the PR invitations on client teams. Client teams can take a look.

Gajinder Singh: Yeah, I think it's worthwhile to take a look, but again, as Thomas said, that you might want spec to be a little easier slash cleaner, and all these optimizations Can basically sit at clients… in the clients. And, I think what we basically need is that, basically, for any node. To prioritize its work, and then have a timeout have strict timeouts when basically it will say that, okay, you know, I can… I can't do it, I can only do 4, or I can only do four… two right now, and make sure that the block proposal goes through. So, we need… we need all these kind of strategies. That will make a client… an efficient client. And, yeah, these strategies could be a bit…

difficult slash complicated for the spec, because spec should be cleaner, in my opinion. But as such, yes, it's a good idea to spread this knowledge around. And, we, as a team, also have some strategies, and we'll also share it, or improve this PR, or maybe we can keep this, block building as a separate optimized function, right? We can have a name as optimized block building in the spec itself, so that This knowledge is there to share, as well as… The normal spec reads simpler.

Mega | Lambda: Yeah, that's a weird idea, I think.

Thomas Coratger: Yeah, I agree. Mmm… Yeah, I, I definitely agree. Anything else to discuss, to mention, or, like, yeah. Okay, perfect, guys. Then, see you next week, and we can discuss all of that async.

Parthasarathy Ramanujam: Thank you.

Gajinder Singh: Alright, guys.

Mihir Faujdar: Thanks so much.

Shariq Naiyer: Alright, have a good one.

Leo Lara: Bye, bye, bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.