Post-Quantum Interop Call #36

Transcript

Thomas Coratger: Hello, everyone.

Shariq Naiyer: Hello, Tomas, how you doing?

Thomas Coratger: Yeah, fine. I hope every… everyone is doing great as well.

Shaaibu Suleiman: Yeah, hello, Tomas.

Thomas Coratger: 8. So, yeah. Let's get started. First, with client updates. So, Zim? If no one is… if there, I can switch to another one and then go back. Maybe Rim?

Shariq Naiyer: Yeah, so we can go next. We've been… we've been working on adding more tests to… adding… we added Q-Lean, and Grandine, and one of the other clients added themselves to, Hive, and we've been working on stability in Hive, and, adding more tests to Hive. Apart from that, we've been working on, the test fixture… integrating the test fixtures into REAM, and then we're gonna figure out how to run text fixtures on all clients in Hive. And apart from that, we are just running, local devnets and debugging. Nothing, nothing too… too huge this week.

Thomas Coratger: Okay, Garrett, thank you. Yeah, I feel this is totally normal in the stage that we are right now. Cooling.

Ruslan Tushov: Hello. We added DevNet for metrics, updated exclusive topic, like 1, 2, 3, 4, 5, 6, 7, 8, and added aggregator switch API. And product support for data validators. Oh… Also, we are adding, for this tool, we are currently using Linux RawTest, building log scripts to build other clients locally. simplified it. That's all I think of.

Thomas Coratger: Great, thank you. Lantion?

Mihir Faujdar: Yep, thanks, Thomas. Hi, everyone. So yeah, basically, since last week, we've been working on adding new features in Lantern to align with the feature request in Telegram. So, added support for the new API aggregator role endpoint, as well as added support for additional DevNet 4 metrics, I've been running a local instance of DevNet 4 and uncovered a bug in Lantern today, but I've fixed that, and I've also released an updated image for DevNet 4 a few hours ago. And also, over the weekend, submitted a PR to Hive for adding, Devna for, support for Lantern. In the coming days, also, we'll be submitting a spec to… a PR to Lean spec for adding additional test fixtures for clients. Thanks.

Thomas Coratger: Great, thank you. East Lambda?

Pablo Deymo: We added the matrix, the missing matrix of 2004, We also moved the signature aggregation to another thread to avoid blocking other validators' duty on the aggregator. We also changed the target we were compiling to on Linux. With that, we improved the aggregator performance by, 3X. We added a new admin endpoint for the… switching the aggregator role. And we implemented a linear spec, the 595, on its lambda. And now we are working on improving how data routes for aggregator… for aggregation are chosen. Thank you.

Thomas Coratger: Great. Thanks a lot. Guin. No one from GIM?

Shaaibu Suleiman: Yeah.

Thomas Coratger: Mmm. Yeah, please go ahead.

Shaaibu Suleiman: Oh, yeah, yeah, hello, hello, everyone. Yeah, so what we've been able to do, so far, we raised a PR, on Hive. Even though, there are some cases we are, currently working on fixing. For that, and, some of the implementations we did on Gean was around, pending attestation, buffering, parallel signature verification. And, also some, implementation for, lean metrics, basically for, for the DevNet. And, yeah, so basically, those are, some of the things we've been doing, on June, I think from the last, update, basically. Yeah, thank you.

Thomas Coratger: Thanks a lot, great lighthouse. Okay, Grandin?

Mercy Boma Naps-Nkari: Good afternoon. So, Last week, we were able to implement, get grinding to start using, the Hive testing, and also we have currently have API for the runtime aggregator toggle API, and then some few cosmetic enhancement changes that has to do with parallelization. That's all for this week. Thank you.

Thomas Coratger: Great, thank you. Nimbus? Great, and Zim, maybe, since… We skipped.

Gajinder Singh: So, thanks. So our update is that we have been working on the network runs, identifying issues. Some of the issues are related to where we have aggressively, pruned our food choice, and on reorgs, basically, we then, reorgs happen where justified or finalized on that particular branch has not moved forward, and, So, because we have pruned, we are having some issues. With regard to processing that, so we did some fixes regarding that. A part of the… apart from that, we integrated Hive into our CI, so we have a daily Hive CI run, which basically gives us the status of Whether we are… All green, or whatever test we are failing. In terms of, DevNet 5, we, we have basically thought of ways in which to avoid, repacking of

The attestations, And, or… and also discussing with the meal how we can repack, how we can repack, so… so there… so there are two… two paths to that, and we can discuss about that later on. And we have also started thinking about, DevNet 6, where basically we would like to integrate execution and go towards, parity with the… and starts moving towards parity with the Beacon clients, so that, we can We can basically… Be ready for… For the L-star hard fork. or towards the end of this year, be ready for a public DevNet. So with that goal, we have been thinking about this. So that is all from our end.

Thomas Coratger: That's great. So yeah, I think that we are okay with client updates. Please let me know if I have missed anyone. Mmm… Otherwise, I think that's… This is time for spec updates. I will maybe just share briefly my screen to show you, like, a new PR that I have done. so let me share. I think that right now, on the spec, I have done, like, I have added a bunch of tests, so you can see some PRs with, with test vectors. So that is important for the client to test their stuff and be able to pass all of them. I think that I have, checked most of the part of the spec, including also some networking response, and some SSD as well, and some signatures, and some post-aidon as well, to be sure that everyone is on the same page, and that everyone passes the same test.

I am also, working on this proposal, that is a proposal from Leo, who is, like, content to speakers at DEF for the Beacon spec. And basically, he proposed, these documents, So that you can check. But basically, this is a modernization proposal, let's say, for all of the spec, consensus, execution, or lean. in order to play with a fork mechanism, and to play with the inherent type of, of Python. So basically, what you… what is proposed to be done is that you have, like, a fork protocol with a bunch of methods, whatever we can call them. no importance for this, but this is just, like, a class protocol, and then you, you do a linear end system for all of the devnets, or all of the forks in the future.

So, where you have, like, the first DevNet that implement this fork protocol with a given way of processing block and a given way of state transitioning and all of this. And then, if you go to a DevNet one, for example, you have just a simple system of inherents for DevNet 1, from DevNet 0, so… And with that, you can have, like, a couple of benefits, such as you don't need to re-implement methods that don't change, you can just have the small change, and you have sub-spec capabilities. such as, for example, some experiment, like PQ-capable, where you can have, like, a subset of the spec. that's just implement PQ capable, for example, and so you can distinguish in your spec version that is PQ and a version that is not PQ.

And you can have also experiment for EAPs and stuff like that. So, that is a pretty nice way of doing things. That's why, we gave a shot to implement this. This is not merged. This is supposed to be merged, I hope, soon. So, what I have done is that I have started with DevNet 4 only, not the previous DevNet, so otherwise this is a mess, just to go back to the DevNet 0, DevNet 1, and all of this. And I have started with this. And so, basically, I have created here, not here, there, in the Lean spec, SRC lean spec, the forks folder, when I have put DevNet 4 and a skeleton for DevNet 5.

So, in DevNet 4, I have implemented exactly what I mentioned. So, you can see this in DevNet 4, that is based on the base fork, and I have implemented, for example, this small method, so that the name of the fork. or the version of the fork, and all of this. And I have the same for DevNet 5 that inherits from DevNet 4. And so, I have… this is just, for example… for now, this is just a migration, meaning that I have migrated, basically, all of the things that we had previously in containers and stuff into this. So, as you can see there, this is just a migration. So, no worries, nothing changed, no comments, nothing changed, just a migration of files.

from the SRC lean spec to SRC lean spec fork DevNet 4. So, I have migrated all of the containers there. So that this has the first benefit of benefishing of the inherent system of Python, and the second benefit is that right now, if you check in DevNet 4, We have all of the things that are consensus critical there. And nothing else. So this is in DevNet 4 folder, right there, you have more or less, what is right now in the Beacon spec. And outside of the fourth folder, you still have the classical subspec folder that you all know, probably. Where you have everything else that is not consensus critical, such as the networking, the storage, the syncing, the genesis, the API, and all of this. So this is not officially part

Of the critic part of the spec, but this still is part of the spec. And so, I think that we will be able to merge that pretty soon. We are, like, in, we are checking with the consensus spec team within ZF, and I will also share you the… more broadly when this is ready for a review between the client teams, but I think that this is a pretty good idea. So, yeah, I wanted to present that. On the rest of the spec, we have just added some tests and nothing else, so nothing changed. Yeah, Gajinder, please go ahead.

Gajinder Singh: Yeah, so it's great work, Thoma, but one thing I want to say over here is that if we are basically saying this, doing this with regard to merging and beacon specs, I think that is a great step. So that we can start showing up there. But I would be hesitant to, right now, start having forks right now on our Lean Ethereum, so that we… so the clients don't need to add the forking mechanism And the fork upgrade mechanism, because anyway, we will not be testing that. for a long while, and even when we will be testing, we'll basically be testing, transitioning from something from a beacon for… to, to L-star, or something, that kind of a… of a hard for whenever we are ready. So, in that sense, I would be… I would basically want to have this

structure in Lean Ethereum as well as in client, so that they are fork-ready, but At the same time, avoiding any forking in the devnets, or basically testing that, or any of the testnets that we'll come up with.

Thomas Coratger: Yeah, okay. So yeah, I agree, definitely. This is what I said internally in the discussion with the consensus spec team. Why? Because right now, we are moving at a very fast pace first, so that is the first reason, so that we have, like. one DevNet a month, almost. So this means that at the end of the year, we will have, like, more or less 10 devnets, let us say. So that means, like… 10 inherent systems to maintain in the specs, so that is a bit… Much… So that is the first problem for me, and maybe this is not appropriate right now to have this, because we are just experimenting, and the second problem is that as we experiment, we discover bugs in previous devnets.

And so this is a bit tricky to manage both of the current devnets and the previous devnets that we don't care that much anymore about. So, there are, like, these two problems, so probably that… In the current stages. This doesn't make sense to have, like, multiple inherent systems, so maybe a possibility is that we continue with the commit number in the file that we have right now. Even if we have in the spec the inerrant system, this is just a preparation step for the integration with the existing spec right now, and not something that we will use on a day-to-day basis for our DevNet experiment, because we will just call our system right now DevNet, and that's all.

So that is also a possibility, and so that we will just implement Kay fork. and then inherits, L star fork from k fork, so that we start from there. This is also a possibility.

Gajinder Singh: Yeah, so with that regard, what we can do is not have DevNet 4 as a folk name, maybe have a lean as a folk name, or, you know, whatever it is. Yeah, correct.

Thomas Coratger: Correct.

Gajinder Singh: That we want to keep, and DevNet 4, DevNet 5, they are basically our internal iterations, and on all these… if we are basically also bringing in the fork infrastructure, all the… clients at any particular definite, they will be at Lean Fork itself. So, with regard.

Thomas Coratger: Correct.

Gajinder Singh: On internal thing, we are at Lean Fork, but yes, we are doing iterations of it.

Thomas Coratger: Correct, correct. We can… we could rename what I call, DevNet 4 to Lean Fork, and, just go from there. Correct.

Gajinder Singh: Yep, that would be great.

Thomas Coratger: So, yeah. Other than that, so that is, like, a spec update. This is still in reflection, and I don't want you to spend much time on it before we have at least reached a soft agreement internally within EF. Within the teams. Also, so that is one piece of news, Second piece of news is all of the progress that we have made recently on the cryptography. We have continued to merge some PRs on Lean sig, Lean multi-sig as well. Emil will talk about this. and also on Plonky3. We have, like, an ongoing work with Onyers that is working with us to try to see how to adapt Lean VM to the Bitcoin people with the Bitcoin hash function.

That is an ongoing work. We have also some sum check optimization, currently ongoing for Merge inside Plonky3. We have also still the big PR of we're waiting for, like, approval to be merged on Plonky3, and we have also a couple of other PRs in Plonky3 to add functionalities of Lean VM inside Plonky 3 as well. To maintain this, so yeah, and Emil, feel free to talk about Lean VM advancement.

T. Wambsgans: Hello everyone, thank you. Yes, basically, working on reversing the variables in the sum checks. Previously, it was X1, X2, X3, until XN, and now it will be XN, XN-1, XT until X1. Which has the advantage of being more padding-friendly, and even if it's natively implemented not packing-friendly, it turns out that by bit-reversing chunks of data, you can't… you can make it, at the same time, padding-friendly and packing-friendly. And that's it. Thanks.

Thomas Coratger: Great. Also, I think that last week, we had this discussion with the RIM team, presented this super nice Hive tooling for showing the test for each client. Maybe, do we have an update on this? I have… for this, I have set up, like, a new channel in the PQ discussion on Telegram, dedicating to testing Why? Because now that we have all of these new test vectors in the stack, I would love to have, like, some kind of tooling or some visualization To show… What tests all of the client paths? So, do we have maybe an update on this?

Shariq Naiyer: So, the next things… the next thing that's being worked on on the Hive test is checkpoint sync texts on all clients. So we create a checkpoint sync, and we… we try to sync, a client with that checkpoint sync. However, this is not in the repo, on the Hive UI yet. Once it is, we'll, we'll put a text in the testing chart, and we'll create an announcement.

Thomas Coratger: Cool. That makes sense. So great, thank you. So this is something that I wanted to discuss. Then metrics, maybe, with Katya? Do we have some news, some stuff to share? Or someone else, if Katya is not there, of course. So, yeah, okay, that's… that's… this part seems okay. So, maybe what we could do is to continue, all of the devnets. For testing, debugging, moving forward, during the next week. So that, next week we can discuss maybe DevNet 5. staff to start implementing some DevNet 5 updates. In, in the spec. Mmm… So, yeah, that would be my proposal, because I think that from all of the summaries that we had today from all of the client teams, it seems that we are in a phase of debugging and running clients, so maybe it would be bad to mix up

with DevNet 5, it would create confusion, so maybe we could just wait for next week and try to start discussing that async on the DevNet 5 channel, in Telegram in the meantime. So yeah, that would be my point. We wanted also…

Gajinder Singh: I can give some developer updates, Patho, if you're there.

Thomas Coratger: Of course. I think I have seen him, but maybe… Okay, no problem.

Gajinder Singh: All he messages is Michael's not working.

Thomas Coratger: Yeah, yeah, no problem.

Gajinder Singh: So, I think I can just add in a line that we are still doing one subnet testing, and we have not moved to multiple subnet testing, and that will… is a priority now. So that all clients can be aggregator on their own subnet, and in this way, all clients' aggregator function can be tested simultaneously, and also can also be tested that when the client go down… goes down those set of That subnet validated attestation's not showing up in the block. And basically then also test whether we are able to stop the finality and resume it whenever The aggregator is up, and I think for that purposes, we, got that API endpoint added, where we can dynamically

start on or off the aggregator function of a particular client. So, I think with, regard to this particular scenario, we will Be able to quickly uncover issues and move towards a stability where all of the client's aggregator functions are being simultaneously tested.

Thomas Coratger: Yeah, I agree. So… what we… let us do the following, like, let us work on DevNet 4 stability, and let us discuss async on DevNet 5 channel Intelligram to have a precise list of features. That we want to add for DevNet 5. To discuss that next week. I think that, also we plan to discuss, can, debrief I don't know, Will, if you have some stuff, like, to add to this. I think that the main point that we discussed in CAN was, like, DevNet stability. That's why we emphasize so much on new tests in the past couple of days and weeks. We have added really a lot of tests, so please add all of them in your…

in your devnets for each client. I think this can also help us to surface potential bug in the spec, because if I have, like, a test that passes in the spec, and this doesn't pass in any of the clients, this means that there is a problem in the spec, of course. So, please add all of the tests and check with the spec. I think that right now we have, like, enough testing to suffice most of the bugs. I have tried to play with AI, in order, like, to find the super complex scenarios of testing, maybe I am missing some of them, of course, because testing is a huge job, but I think that right now we can cover most of the big issues, I guess, so yeah. Maybe, Will, you want to add something?

Will Corcoran: No, yeah, I think really my main takeaways from Fort Mode were, yeah, like you said, increased testing and DevNet stability, you know, really trying to right-size the number of clients that are participating in the devnets and, like, having some type of, proof of work, if you will, before, like, getting added to a DevNet, just to, like, lessen the burden on Partha and Katya and other people that are, like, doing a lot of the, stability and observability work. And the last part was kind of more looking forward, really leaning in on the co-design components of this with Signature schemes and aggregation times, but pairing that with P2P design, different topology design, and, working with, Jan from Consensus, on this decoupled consensus, and, you know, maybe trying to, have this be a sandbox for, like, that quantum heartbeat, concept.

Thomas Coratger: Yeah, perfect. I totally agree. I think that's why, about the first point you mentioned, that's why we would like to have this visualization tool in order to be able to check via, like. A simple check, which client is passing which test, and which client is not passing which test, so that we can easily see what clients are able to interrupt and what are not… which one are not capable of. I think this is super important, and yeah, for the rest, I think this is, like, R&D, and yeah, let's discuss that async on the Telegram channel, and maybe next week. Yeah, it will. Please feel free.

Will Corcoran: Yeah, the last thing I was gonna add is just, the actual Fort Mode recordings, they're nearly ready to go. We had to… the audio quality wasn't great, just because of the shape of the room and recording from an iPhone, so sent it to the… amplification team to work on improving the audio and adding some captions to it. So, just waiting for that to get back so that it's actually useful for people, and hope to have that posted here in the next couple days.

Shariq Naiyer: Nice.

Thomas Coratger: Great, I have just seen that Katya joined the call, maybe want to share some updates about metrics and stuff? Okay, no problem. Let's do that next week. So, I think that we are okay with everything. If there is no more to add, let us meet some next day, and async on Telegram. Thanks a lot, everyone. See you, bye-bye.

T. Wambsgans: Bye.

Mihir Faujdar: Thanks, everybody.

Gajinder Singh: Wrong.

Shariq Naiyer: Guys, bye. Bye, please.

Anshal Shukla: state.

Will Corcoran: Alright, thank you.

Katya Riazantseva: I guess.

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