Post-Quantum Interop Call #39

Transcript

Pablo Deymo: Hello, bro.

Thomas Coratger: Hello, everyone.

T. Wambsgans: Alright.

Yann Vonlanthen: Hello.

Thomas Coratger: So, let's get started. So, welcome to post-quantum interrupt number… 39? We will start with a client update. And then I would like to talk about different points, mainly DevNet 5, the pros and cons of going through 3S… still going through 3SF Mini, VS, switching to Goldfish. a bit of stabilization around LeanSpec. And a new repo that has just been created by Justine Traglia about, potentially outsourcing the cryptography spec, in LIN, LIN is a language in 4, in a specific repo. But first, let's start with client updates. So, Zeam.

Gajinder Singh: Thanks, Thoma. So we have been working on squishing the issues that we are seeing on running, multi-subnet, network with Zeam and other Clients are aggregator, and we are almost there, still working out on a few of the H cases, debugging them. We also plan to… so we are stable quite a bit as of now, and we also then plan to start scale, to start scaling the number of validators, so run our multi-client subnet and start scaling validators to 128, and then basically debug fix those issues. In the meantime, we have also been working on the DevNet device spec, I believe, the spec PR Will be up by tomorrow, most likely, if not today. And we have also been trying to identify… identify the mattresses that we need to add for the RAT in order to

In order to basically… Bring up if there are any performance issues that The nodes can see doing various… processing various, processing various horde paths, and that is something that we will also upstream to LeanSpec. If we find that relevant. So that's mostly our update.

Thomas Coratger: Okay, that's great, thank you. Ream?

Shariq Naiyer: How's it going, guys? So, we've been… we've been working on, adding the lean spec test to Hive, so that has been completed. I don't know if Colby is here, and if he… he would like to show something about it, but I believe… I believe all the other clients have… most of the other clients have integrated the, HiveSpec, the spec test runner in… and, all their, all their tests are… most of the tests are passing for most of the clients, so… so the Ream, ETH, Lambda, and Lean, from what I see, have integrated the HiveSpec runners. I urge the clients to integrate that, spec test runner as well. on a… we also added the endpoint for serving the checkpoint block and anchor block, as was added to the spec. On a different note, I have been, like, we have been running DevNets from the bottom up, and

So, I was running Zeam, Zeam, Ethlambda in two subnets. Ethlambda wasn't finalizing. I found the issue in Zeam, I've made a PR, and I built… I built, Zeam with… I built Zeam… a new image of Zeam with these fixes, and I've shared my findings, and we were able to finalize to about… let's see… about 4700 slots. It could have been my RAM that… that was capping out at this point, but we were… we were at head at 6900 slots, and so this was… this was fairly stable, so I've now added Grandinee to the mix. What I see is Grandinee's image is not ready, so I'll add someone else to the mix, and I'm going bottom up, so I… I'm at 3 clients right now.

I'm feeling comfortable with these 3 clients. I found an issue, I reported the issue, and I created a PR. I'm gonna go to 4 clients, 5 clients, and I believe we have, like, 8 clients in total, and we can be sure that 8 clients interop to each other well, and… So, Partha is going a top-up approach, where he's… a top-down approach, where he's running all the clients and seeing how they perform. I'm going bottom-up, so at some point, we'll converge, and we'll have… we'll have definite stability. So, I believe that's all from my end.

Thomas Coratger: Great, thanks a lot. Qlean.

Ruslan Tushov: Hello. We're looking into fixing Hive tests. Currently, that's all. Thank you. I meant, testing Qlean, under… when running under the tests.

Thomas Coratger: Okay, great. You, you mean, the… the test vectors from the lean spec, or other tests from Ive?

Ruslan Tushov: Sorry, hive tests, yes?

Thomas Coratger: Okay. Thank you, Lantern.

Mihir Faujdar: Yep. Hi, Thomas. Hi, everyone. So basically, last week, we were able to, integrate the new version of LibP2P, in Lantern. So, like, the whole purpose of that is to interrupt better at the gossip player. So this new library is compatible with the Shadow Simulator tool. And it can interrupt with Go and Go Lipidoppy and Rusty PDP, for some of the gossip tests. And basically, since then, I've been wor- like, the urgent priority right now is to, increase our Hive test coverage, so we're all green, and currently, just testing out the integration of the newlywi library, and yeah, hopefully it should, intro better with, certain clients like Qlean, and Gean. Yeah, I will post an update once the image is ready, in the Telegram chat. Thank you.

Thomas Coratger: That's great, thank you. Ethlambda?

Pablo Deymo: Hello? Hello? We were working on integrating the full logarization. We will publish a new devnet 5 tag, talker image, later this week. We integrated, with, Hive's, new Spectre suite. And we are passing almost all of them. We added a new finalized blog endpoint for the checkpoint sync. Also, the tick interval metric and mesh peer count, from lean metrics. And we also updated the CLI option names. To match the… the linguistic start documentation. So, that's it, our update, and we will continue working on the devnet 5 spec spec and that related things. Thank you.

Thomas Coratger: Great, thank you, Gean.

Shaaibu Suleiman: Yes, hello. Yeah, so we've been running, devnet 4, and, alongside that, also. Fixing a couple of, Hive tests, on our own ends, to make sure they pass. We also integrated, the spec test, runner. We just released, a new image, not very long. And, also we've been looking at, your proposal for devnet 5, and all. So yeah, basically, that's it from our own ends. Thank you.

Thomas Coratger: Great, thank you. Lighthouse? Grandine.

Mercy Boma Naps-Nkari: Good afternoon. So, we're currently working on the CPU issue we had, and then we'll release an image on it, in a couple of hours. And then on the Hive test features, we will also, make a release. Although, we'll be defer… we will be failing, around 11 tests, that will be an intentional fail, due to, we don't have a DB yet, so if we kind of, like, silently lose every head vote race, it will… cause, the same CPU issue we are trying to solve, so… Out of all the tests, we are going to intentionally fill around 11 of it. Thank you.

Thomas Coratger: Amazing, Nimbus. Okay, did I miss anyone? Okay, great. So, from a research perspective, and, what I… we wanted to talk there, so I have, like, a couple of points. First, we were, like, in… in Rome, last week. some of us are still in Rome, for ZK event, so everything related to ZK Summit, ZK Proof, and OroCrypt. So… this has been mostly, like, presentation, discussion, and conferences around, like, ZK SNAR proof system, and PCS and cryptography. For more verification as well. Nothing really new on this end that you should be aware of, except the fact that LIN, as a language, is progressing quite fast.

there has been, like, a lot of presentation. especially from, like, the side of EVM ISM, with the assembly that you can then formal verify in Lean, and also there has been, like, a dedicated day to Arclib that is a library in Lean to a formal verification piece of cryptography. some stuff like this. Also, a huge focus on post-quantum with the presentation of Justine, about all of the post-quantum effort and natural atoms, for the quantum computer. So that is basically it. Then, we had a bunch of discussion around the spec and everything. So I think that this is good that DevNet 5 spec, PR is coming soon, as you mentioned, Gadjinder, because this will be, like, our main focus right now, especially the part related to, PQ, so the…

Recursive aggregation with a single proof posted on chain will be, like, our next focus. Then I think that for the 3SF Mini VS Goldfish, we should maybe wait a bit. if our 3SF Mini is pretty stable right now. Maybe we should just keep with it. It depends. If Goldfish simplifies things, then we should move to Goldfish, but if it complexifies things, then we should maybe not move, Right, right now. So, yes, that was basically it. Then, as we discussed last week, I hope that we can enter, after just this change. a phase of stabilization, where you guys can iterate over all of the tests, and all of the running DevNets, and the debugging stuff, stabilize a bit, like, all of the networking parts, the DB part, the Docker images, all of this.

Also, in the… in the specification. Up to now, we had a lot of different PRs coming from various points, and a lot of, a lot of new ones coming each day with a high velocity. Now I hope that we will enter a bit of a stabilization phase, where we can spend more time trying to think about all of the aspects of the spec. Trying to modernize it a bit more, trying to debug some potential existing failures that we have not seen before in the spec and all of this. Yeah, Gajinder, please?

Gajinder Singh: Yeah, I sort of agree with the plan that, after a single block proof, we should enter stabilization phase, but in my eyes, the stabilization phase should… also have execution as the integration, because then we can basically go to the larger community and say that, okay, the clients which are already there, they can start looking at the spec, they can start integrating and do it, because from what I understand, one of the hurdles that They have is that we don't have any execution integration, and once we have that, basically, you know, we will become full stack in the real sense that this is basically how we are. Proposing, to… to upgrade the consensus layer, right? So without execution, I think seeing… entering stabilization phase would be a bit immature, or in other words, I think that integration execution… integration of the execution is part of the stabilization phase itself.

Thomas Coratger: I see what you mean. I don't exactly know, because if this had, like, more complexity, and it will probably have, since this is, like, another integration, maybe this will introduce more bugs, both into the spec and into all of the clients. while… in fact, what I want to see is, like, an EVR simulation of the PQ signatures. And so, for example, we have never tested a DevNets. with, for example, 10K validators. We have never done that, and so I would love to see how the attestation propagates through the network, how the aggregation is going. and everything like that. Related to this, we had, like, the new framework that is LeanBench, that is now moved into the Lean Ethereum organization, so that we can see a bit more clearly all of the benchmark of all what we are doing. And so, all of that, just to say that,

what I would love to see is, like, for example, like, a DevNet training with 10K validators to see how the PQ is going. And I am not sure that.

Gajinder Singh: Who's that?

Thomas Coratger: we need execution. Not sure, right?

Gajinder Singh: Rush. Right, so increasing the validated account, that is already now sort of… the next, important thing for us. We are already planning to bump the validator count to 128 in DevNet for itself, and then basically go further than that. So, I think in DevNet 5, we will definitely go very aggressive on increasing the validator count. And I mean, so… so we will… we might have a longer testing DevNet life cycle for sure, but I think we need… Execution integration as part of our stabilization phase, so that We can basically say to other clients that, okay, come integrate with us, and we can, for example… do optional or mandatory proofs, right? So… so in that sense, I think the evolution towards the stabilization phase, in my eyes, will be basically to integrate the

current stack that is already out there. But yes, I do agree that the next step is definitely to increase the validated account, which is sort of already our emphasis going even into DevNet for itself.

Thomas Coratger: Maybe we should… we can discuss that async, but my guess is that we should have, like, a number in mind. And we want to simulate this number of validators, and before this hasn't been simulated, then we don't move further. For example, I know that you said the increasing number of validators, but maybe, for example, we should target, I don't know, 1K or 10K validators? And we do the simulation, and before we are there. we don't move further. So that's… because my fear, like, my sensation is that we will potentially have modification to be done, maybe on the cryptography side of things, to reduce the proof. That will be super difficult, but… Maybe that is something. Or maybe we will have modification to do on the peer-to-peer layer. For example, changing Gossip Sub, integrating SP2P broadcasts.

These kind of things, to maybe…

Gajinder Singh: get canceled.

Thomas Coratger: improve the value is, and so maybe we could do that before integrating the execution.

Gajinder Singh: So, I'll tell you my reason for asking an execution integration is because we can have, then, a full validator lifecycle, where the validator deposits can happen and exits can happen, and that way we'll be able to launch a public DevNet. So, it is sort of part of stabilization. itself. So, in that sense, I do agree with you. We basically first need to keep scaling the number of validators, and as a part of stabilization effort, you can call it phase two, we should basically do the integration and bring in the full validator lifecycle, where we end up launching a public devnet In the phase 2, right? So, I think without launching a public devnet, we won't be able to claim that we have stability.

Thomas Coratger: I agree. Yeah, definitely, I agree. Yeah, maybe we can discuss async in the group to have, like, more heads into it, to how many validators do we want before going to execution. Maybe this is a smaller number, And then, yeah, we can move to this kind of stuff. After, like, of course, we have, like, a couple of stuff to be feature-complete, we can add goldfish, maybe now, maybe later, I don't know, this is also to be discussed, I think, as a function of stability. For example, I don't want to introduce goldfish right now if it causes Hundreds of bug in each of your clients. this is a nonsense, because I prefer increasing the number of validators, see what's happened, instead of just adding goldfish and introducing thousands of bugs in each of your clients.

But, of course, like, if everything is okay… is going… is looking great, if we can have, like, a proper DevNet with no bug, with, like, 1K validators and all of these, then, of course we can progress, we can… develop the spec more, we can introduce goldfish, we can even introduce finality gadgets, we can experiment over different finality gadgets, even. we can do several stuff. We can also, like, see about how we can modify a bit, the P2P layer with the new East P2P repo by the team of Raul. We can also check other stuff, like, for example, what is the appropriate slot time? Is 4 seconds the right choice, or maybe another one, I don't know. Yeah, we can explore all of this stuff, of course, if everything is going right.

Gajinder Singh: Nope. Right, right. So, I totally agree with you. From… on ETH P2P, in ETH P2P, I… my understanding, what I got from from, the discussions we had at ACD was that It is a bit further away, so, I mean… I would basically wait for them to be ready, and before basically start introducing them, and that totally makes sense, so what… we can do… so 3SF for now is stable in sense of how it works and how clients are supposed to behave, and I believe that most of us now have an intuitive understanding of how it's behaving and what we should be doing. We have also solved various bugs in spec as well as in clients regarding that. So, in that sense.

I think, yes, we should not touch consensus, till we scale to a big number of validators, and I will even say till we also integrate execution, because once we have this integration, then basically we will be able to do a public DevNets, and that point, I guess, would be better suited to… test out different consensus mechanisms that we might want to plug in, and different gadgets that we might want to plug in, because we want to get closer to Real network conditions as much as possible. And, yeah, so… so that way, I think public… Testnet would be a higher priority, and then we can definitely go towards the heartbeat.

Thomas Coratger: I agree, this sounds like a plan. I will review, like, in priority, like, the new DevNet 5 spec PR, once this is done, of course. That will be my top priority. Also, I wanted, like, maybe, Emil, you can give a word about LeanVM, and maybe your start and stuff that you have learned at ZKProof and all of this, so, yeah.

T. Wambsgans: Hi, yeah. I've been trying to make it work on Goldilocks, because it would be ideal for a bunch of reasons. It's another prime field. But the performance is, like, more than 2x worth, so for now, we stick with Cole Albert. But ideally, in the future. should be better if we can switch to Goldilocks for security, and better to addicity, and a bunch of other reasons. And also, I'm… so, right now, the DevNet5 branch on Lin Multisig should be usable. And I'm clueless if everything is available to be used properly with the new Type 1, Type 2. API, so please let me know if there is anything missing. I can add any function that you need to make your life easier.

That's it for me, thanks.

Thomas Coratger: Great, yeah, I guess that we will see these details for DevNet 5 once we have, like, the DevNet 5 PR. On the specs, since we will need for this to bump the bindings, we will see if everything is working as expected. I wanted also, like, to give a word about, this new repository that is called Cryptographic Specs, that I have shared in the issue. This is just for now, like, a placeholder. There is nothing inside, but in fact, this is something that has been set up by Justine Traglia. I'm sure you're all familiar with him, but he's the one who is leading, like, the Beacon consensus specification effort right now. So this is a lean for a repository, basically, in order, like, to… to try to start an effort about speccing out the cryptography in lean.

Why? Because Lean is this super cool form of verification language where you can formally verify things in order to, like, ensure that your software has no bugs. As long as you have, like, written down the specification properly in that equation with the mass. But the idea there, basically, is to extract, maybe… this is still ongoing discussion, so I am not sure that this will happen at all, but… I wanted to update you about this. So, here the point is to maybe outsource the cryptographic stuff, so, for example, SSD, for example, Poseidon. or XMSS, or in the future, LeanVM, into this kind of specification, and then create bindings in Python that are also in the same repository.

to, to be available to use directly in any Python repo. So that, for example, this will let us use these bindings inside the spec, and so technically, we could remove Poseidon, or SSZ, or XMSS, from the Python spec, because we will just use the bindings that we are sure are secure due to formal verification of LIN. So, yeah, that is a nice effort. We don't know right now if this will happen or not, how… in which time frame, what will be, like, the focus, who will do that, and all of this, but we are still discussing that internally at DEF, and this is definitely a possibility. From my perspective, obviously, like, this is super cool.

Because now we will have, like, a proper formal specification of all of those cryptographic pieces. And we can remove a lot of lines of code in Python, of course, because we will remove all of the tests and all of the specification in general, because we just use bindings from an external source that we are sure is secure due to formal verification. So yeah, that is also another piece of news, so that is basically it. Maybe, Katya or Porta, do you want to add some stuff about metrics, if you have stuff in mind, or anything?

Parthasarathy Ramanujam: Nothing specific, actually. So, as Kajinder already reported, we ran multi… two, subnet DevNet for past couple of days. There has been a few crashes, and aggregation still continues to be a problem, for a few clients. And I've been… I haven't, collated the metrics completely, but I've noticed, in few cases, the aggregations do not complete within a slot interval. They take probably up to 3 to 4 seconds. So I'm still investigating what is the cause, and is this across the board, or only for specific clients? So, I'll share more details once I have a finalized… I mean, I finished the analysis.

Thomas Coratger: Okay, great. Anything else that we missed, or anything? Okay, great, guys. Then, next step will be, like, the DevNet 5 PR in the spec. So that will be great. And, then we can discuss directly on the spec, and then we will try to enter this kind of, Stabilization slash, scaling the number of validators face. So, yeah, see you around. Thanks a lot, guys, for attending the call. Bye-bye, see you next week.

Shariq Naiyer: You guys have a good one.

T. Wambsgans: Bye.

Pablo Deymo: My wife is you?

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