Post-Quantum Interop Call #34

Transcript

Pablo Deymo: Hello.

Shariq Naiyer: It appears that some people have gone to the other meeting. Let me… let me see if we can get them here.

Thomas Coratger: Hello?

Shariq Naiyer: Okay, Tomas.

Thomas Coratger: So, let's go. Mmm… Will had a conflict today, so he will not be able to join, but he will be able to join next week. So, for those who were not present, we had, like, this super cool Cannes event last week. So, we had, like, two dedicated days to lean, like, one piece mode day, where it was more about, like, execution side of things, and ZKVMs, and, yeah, the execution layer of Ethereum. On Saturday and on Sunday, we had this fourth mode event dedicated to consensus Layer. Where we had a bunch of post-quantum talks and, like, a round table around the DevNet that we are running, and all of this. All of that is currently processed by Will, the videos, the sounds, and all of the recordings, and everything.

We had super cool discussions, during the World Weeks. Around our DevNets, our experimentation, post-quantum signatures, post-quantum aggregation, and all of this. So, it has been super good learnings. the main… just, I am sitting a bit, like, the ground right now, like, the main things that we have learned during, these events. about our DevNets is that we are reaching a point where we have a huge number of client teams, some joining on a regular basis. And we have a bit of instability in the different DevNets that we are running due to this huge number of clients joining, and we are constantly debugging within clients, within the specs, so sometimes it is a bit difficult. So, we are… we have heard these comments, we have considered it, of course, we have discussed them, with external people and internally at EF.

We are processing all of this, and we will come with some potential solution. So I think that this tour… this… today we will be dedicating this… call to DevNet 4, and client updates, and everything. And we will have more, like, news in the coming weeks about all of this, stabilization things. My main takeaway right now Is that, what we should do is that we should, emphasize on tests and test suites. adding more tests and test vectors for client teams to have when they join the DevNets. They have to pass all of these tests so that we are sure that everything is on the same page, and we are all on the same experiment. That is one thing. And then, I think that now that we have recursive signature aggregation, we are reaching a point where we will have a bit more stability on the post-quantum new feature, because there will be much less invasive than we had before.

And so we'll be able to experiment, like, more on testings and the stability. So yeah, all that said, let's start with the client updates after all of these weeks, so maybe Zim?

Gajinder Singh: Thank you, Toma. Yeah, so on client updates, basically, we are preparing for DevNet4 readiness. We are mostly DevNet4 ready, apart from the latest chain that we also want regarding bounding the max attestations. And, once Anchal put up a spec PR and gets merged, and we merge it, and other clients… come to the same, spec. We are DevNet4 interoperady. Only in Quick Start, we are… We have also modified the hash key generation so that there are two keys that are generated for each of the valid data, and there will be a new PR put up. by Partha for Lean Quick Start, so that Lean Quick Start is DevNet4 compatible. So the idea is that all of our focus is now going to DevNet4 compatibility and stability, because,

There is a DevNet where we will also start testing the subnets, because that is what we decided, not to test the subnets, in the last DevNet, because there was… a subnet, subscription, spec PR as well, and I'm hopeful that in DevNet for all the clients would have, would implement it, or would have implemented it, as well as provide us a flag so that a subnet can be configured as an aggregator for subnet, or a list of subnets can be configured to aggregate for a particular aggregator in a client. So, with these changes, we… we are reading With these target changes in mind, we are adding Lean Quick Start, so that we can start DevNet4 interop.

And, And that's basically where we will now focus, to scale the validators as well, and to focus on stability.

Thomas Coratger: Cool. Yeah, thanks a lot for the updates. Rim?

Shariq Naiyer: Hi guys, so we also have been focusing on DevNet 4 readiness, and we've got the key separation PR implemented, we've got… We're working on implementing the new DevNet 4 branch in Dean Multisig. We have implemented it locally, and locally, ADEM finalizes itself right now. but we're gonna start testing with other clients as well, and we are actively looking out for new, new updates to the spec on, as Kajinder mentioned, and we would be… we'd be up to spec, and we should be ready to interop within the next few days. On the testing side, we have been… we have been making PRs to Hive, and we have been, looking into Hive for testing all the clients.

We've added Veeam, and we've added Zeeam, and we're adding tests, for these right now, and we will actively be adding more clients on there as well. I believe, yeah, I believe that's it.

Gajinder Singh: So, is this some fork or Hive that you are maintaining on your, on your fork?

Shariq Naiyer: Yeah, currently, we're pushing, We're pushing changes to our fork, but Colby is in talks with Felix to have it merged into Ethereum Hive.

Gajinder Singh: So, I… I think the way we should do Hive is basically, the… the backend orchestrator for Hive should be LeanSpec. So that, basically, LeanSpec is there, and every client needs to then Common compatibility with it, so… So is… so how are you doing that? Is that how it is being organized? Because currently, Hive runs with CATH, but instead of having a particular client over there, I think it would be preferable to orchestrate all the test cases. with a lean spec client. That's why we have it, I guess.

Kolby Moroz Liebl: Yeah, we can, for sure do that. I think in some certain cases, we'll probably want to write some, like, synthetic harnesses, It should be flexible to do anything we want, really, so… I… We could, we can look into, like, doing that.

Gajinder Singh: So, what… what is right now the… who is right now the orchestrator? So, basically, you know, they are interrupt tests, so… Who's the one who's running the test? Is it Rheem, Zim, or they are pluggable?

Kolby Moroz Liebl: Currently we're just writing basic, like, smoke tests, and we're going to start writing, those tests shortly.

Gajinder Singh: So right now, there is no orchestrator client, it's just… some API calls to a client, to an external client that we are testing, and That will do it, right? So this is how it is.

Kolby Moroz Liebl: Yeah. So, hopefully next week we have, the lean spec as the orchestrator.

Gajinder Singh: Okay, cool. I mean, it would be amazing if you guys can sort of arrange a presentation on it when you have made sufficient progress, so… That will be, you know, a really good thing for all of us.

Kolby Moroz Liebl: 100%.

Thomas Coratger: Okay, cool, guys. Islamdar?

Pablo Deymo: Yes. We are also making progress in .NET 4. We continued on these changes, we are polishing and testing. reviewing it before publishing our first DevNet 4 tag for Docker. Especially, we finished and we tested the dual-key validator types, the separation. Of attestation and proposal keys. And we also apply some fixes. to… the main goal? We fixed an infinite block reprocessing loop. During the final decision install, we also fixed the thing you post in the misspec, the station source diversions. to align to linear spec. And we fixed the oversized blocks during install recovery. We post that on the Telegram channel, and we receive,

a PR with a patch, you know, repo, I think it was from Grandine team, so thanks to them. And we were, running an internal deadline for many days. And we found an issue with week-long debnets. We were not advanced in the XMSS collaboration window, so we fixed that. And then, we also migrated, our code to our own library, lib SSL, which is no STD ready. And, I wanted to mention that we started with an initiative to write in… to formally verify some pieces of the… of the code. In… in lean form. So we started doing some experiments by the moment.

Thank you.

Thomas Coratger: pool, tooling?

Ruslan Tushov: Cooling?

Thomas Coratger: Yeah?

Ruslan Tushov: Beautiful. Hello. So, we… Also, I'll try to update to DevNet 4. Currently checking out the multi-sec. Bendings. A small question is, hash sicklee from… Quick start, does it already support Fusky again? case. Or… It resides in another branch. or fork.

T. Wambsgans: You were speaking about the fast key generation?

Ruslan Tushov: Yes, I tried running the… on DevNet 4 branch with new keys, and it rejected. Seems to reject.

T. Wambsgans: Because for linear multisig, I had to fork LinSig in order to make the key generation fast for the benchmarks, but it's not something that should impact you, like, it's only for linear multisig tests, should not impact anybody else, I believe.

Gajinder Singh: So, Ruslan, I guess, Patha, can you check with Raslan what the issue is with Lane Quickstart, whether… why are we rejecting the keys?

Parthasarathy Ramanujam: Yeah, Rustin, I'll get in touch with you after this one.

Ruslan Tushov: Thank you. And also, we found some bug in Kulim, currently on DevNet 3, by using the tests I mentioned before. But soon it should migrate to Hive. We'll try to integrate it. Thank you. That's all.

Thomas Coratger: Cool, lantern.

Mihir Faujdar: Thanks. Hi, everyone. So on the DevNet3 side, we've been running a local DevNet, and been working on implementing improvements for memory in Lantern. So, mostly, impro- like, fixes for quick, the P2P, and as well as adding support for pruning, fork choice dates that are older than finalized. And on the DevNet4 side, there's partial work done for PR496. Also, I will be Bringing those improvements, for memory from DevNet3 to Demo 4 branch for Lantern. So should, should expect to be ready sometime this week. And on the LeanSpec side, I've been submitting, PRs for adding justification test vectors for client interop. So thanks for the feedback, Thomas and Earl. I'll also be submitting more PRs in the coming days for adding

finalization test vectors. I'll just need to check if there's been enough coverage for justification. test vectors before adding finalization ones. So yep, that's the update from my side. Thanks.

Thomas Coratger: cool lighthouse? Anyone? Okay, again?

Shaaibu Suleiman: Yeah, hello, hello. Yeah, hello, hello. Yeah, so, from our site here, at Grandine. Most of the work we've been doing, is around stabilizing, EFNET3, stabilizing gene, on EFNET3, basically. And for that, we've been, making some updates around the networking side, specifically, the gossip, the gossip swap, layer. And also, the backfill, backfill scene, basically for missing blocks, and also. like, batching requests in terms of, you know, requesting for, multiple blocks. So, basically. Those are some of the work we've been, doing on Grandine to stabilize it for EFNET3. And also, we started, taking a look at, the specifications, for EFNET4, so that As soon as, we are done stabilizing, most of the work on stabilizing gene for EFNET3, we can…

accelerate, the development also, for DevNet 4. So, yeah, basically does it, from our own ends. Thank you.

Thomas Coratger: Thanks a lot, Nimbus. Okay, did I miss anyone? I don't think.

mercynaps: grinding. Good afternoon.

Thomas Coratger: I think I, called… okay, Grandine, yeah, sure.

mercynaps: Yeah, so, this week, so we kind of recently merged the PR to help split block production so that the SMSS runs outside the right lock, more like an improvement. And also, we put out a PR to fix the bulk Kai caught in the spec for produce attestation data. And then on DevNet4 status, we are currently working on the PR, so… so we should be able to… I should be able to put up the PR by the end of the week. That is if, there is no other changes in the spec itself. Thank you.

Thomas Coratger: Perfect. Thanks. Anyone else? Okay, perfect. So, let me give, like, a brief update on the spec and research side. First, so on the spec, we have merged this big PR, about, switching to Poseidon 1 from Poseidon 2 for security reasons. And to the new ZK-friendly encoding for the XMSS signature scheme. instead of the top of the IPR cube 1, so that this is friendly to signature aggregation in LinVM. And we have also merged recursive signature aggregation, all of that into one big PR. So, now I think that we have, recursive aggregation, meaning that more or less. we are done with a post-quantum feature. All of what we will add will be, like, stabilization, improvement in terms of speed, performance, maintainability, and all of this, but…

More or less, we have what we wanted to have. Modulo, some minor tweaks, but not major ones. That's why I have started to check about test coverage. Because in my mind, like, we have, like, two kinds of tests right now. We have, like, the Pi test. That are unit tests. They are super practical to test specific, part of a single function without having a big setup. So that you can test, for example, like, dozens of configurations for justification, or finalization, or anything else. Without having to set up a full node or something like this. That is important, but for, client teams. This is super important to have also test vectors. That's why… This is not taken into account into test coverage, because our test coverage tool only covers, like, the PyTest.

But we have to take into account also, like, the test vectors that client teams have to pass. That's why we have opened a bunch of PRs. about this, and I will provide also more issues to guide, over missing test vectors, so that we can add much more test vectors. to cover much more various scenarios to avoid bugs, during, like, interrupt. Me here, like, has done a great job on this, submitting a couple of PRs in the past days about this, and we had a bunch of new… External and known contributors. About all of this, so that is super good news. We are increasing test coverage, that is cool. So, we will continue that way, simplifying a bit the spec where we can. I have seen a couple of place where we could, like, simplify.

For example, I have started, like, beginning of this week to work on the aggregate, because if you checked a couple of days before, like, you had an aggregate method in a couple of places in the codebase, which is pretty bad. And we can improve that a bit. so, I will work on this when I have time. So that is stability, and then I think that we will need some kind of tooling, but we will discuss that with Will and internal coordinators within the EF, and also outside, in order, like, to have some kind of tools where we have a recap of all of the clients and all of the tests that we have. to see… what tests

Are okay for which client, so that we can have a visual recap of all the tests passed by all of the clients. before interrupting, so that we avoid a bit of noise around DevNets. So, that is something that we will work on. Other than that, on the research front, like, Emil can elaborate further, but we have, like, continued working on, some optimizations and some integration. We almost completed the integration of WEIR, so our polynomial commitment scheme, into Plonkey 3. This is almost done, we have just a last PR. That is ongoing review right now, and will be merged in a couple of days, probably. So that we will have that fully integrated into Bronki3 framework, and so that's… that's it. Emil, if you want to add some stuff about LeanVM.

T. Wambsgans: Thank you, yes, I'm just… I'm currently trying to make the pre-parameters and the tweaks efficient with the precompile, so I'm running some experiments on how to integrate both with the recompiles. That's it.

Thomas Coratger: Cool. maybe some updates on metrics and stuff. I have seen in the chat that Katya can't join, maybe Bata, can you give, like, an update on all of this?

Parthasarathy Ramanujam: Yeah, thanks so much. So, Katya has been running multiple DevNets over the past week. One is a larger DevNet, which involves all clients, and one, I believe, is a shorter, I mean, a smaller DevNet with just a specified number of clients. I believe she won… Was looking to identify certain edge cases that have come up in the… larger DevNet. I believe she'd be reaching out to teams whenever she discovers something there. I have been having a chat with Panda DevOps to determine what would be an ideal configuration for DevNet 4 if we decide to scale to a large number of validators. Something I've heard from, Barnabas that, on, the current Beacon DevNet, they were able to scale up to 5,000 validators on a single machine, running just 8 cores, 16GB RAM.

But that might not be relevant in our case, because from what we've noticed, running two, clients as the function has been aggregated itself, is too much for the configuration that we are presently running. So, I'd be running some, experiments, today, tomorrow, to determine what would be an ideal configuration, and then accordingly, first start off, with a smaller, probably 100, client, DevNet, or DevNet4, and then, take that as, I mean, account for that, and then decide how we can scale up to a larger DevNet. Yeah, that's my update.

Thomas Coratger: Order. like, any other important items and stuff? Again, like, I think that we still have, like, important items to discuss about, like, DevNet stability, clients, like, new clients joining, on a regular basis and all of this, but let's wait for Will and all of, all of this stuff that should be processed from the CAN events, so that we will be able to discuss that in a calm situation when we'll come back. Other than that, anything else to be discussed there? Okay, then perfect, guys, like, that's been super, like, concise and straight-to-the-point discussion. Let's see you next week.

T. Wambsgans: Right?

Thomas Coratger: Bye-bye.

Unnawut Leepaisalsuwanna: Thank you.

Mihir Faujdar: Thanks, Irvine, bye.

KaydenML: Right.

Pablo Deymo: See you, bud.

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