Post-Quantum Interop Call #47

Transcript

Thomas Coratger: Hello, everyone.

Shariq Naiyer: Hi, Tomas, how you.

Thomas Coratger: Yeah, fine. And you?

Shariq Naiyer: Nice. Very good, very good.

Thomas Coratger: So let's get started. So today we're going to just mention like team updates and a bit of the broker and improvement we have made over simulations. So let's get started with the team update, Zeam first.

Parthasarathy Ramanujam: Hey, since Gajendra is not there, I'm giving the update on behalf of Zeam. So, over the past week, we've been working on, the couple of, suggestions that were proposed both by, the Zeam team, ourselves, and ETH Lambda. We've released a new image, and we've been testing that out locally. We are yet to address all of the spec issues that were raised over the past week, which we'll be doing and hopefully releasing a new image later today or early tomorrow. Once that's done, we'll run another round of interrupt testing. And, keep you posted. Parallelly, I've also been running, long-running DevNet, on the servers. No issue has been identified apart from what was already raised last week.

Yeah, that's the update from Zeam's side. Thank you.

Thomas Coratger: Great, thanks. Ream?

Shariq Naiyer: All right. On the Ream side, we've also been experimenting with the optimizations proposed in both the documents by Lambda and Zeam. We found skipping the type 1 aggregation to have a drastic impact. And we tried the 8-second optimization, 8-second slots, which works as well. But… so I'm running a… currently running a DevNet on, I'm gonna share the link here. Here with Ream and Ethlambda, and we have the optimizations proposed, the skipping the, removing the proposers, moving the proposer signature and skipping the type one aggregation and the early bird optimization. And we find it to be running quite stable and quite like the head and finalization differences are quite low. It's 14 to 15 most of the time, but I don't think we have aligned on which path we want to take forward, so if we align on that on the call, we can push this into master.

on… on the, on the scaling side, Hetzner… Hetzner prices have gone up by quite a bit. They doubled their prices, and… They haven't approved us for additional servers. So we are looking into other options for hosting our DevNets. And on the Hive side, we saw that the Hive instance was getting full. So we restarted it and we are looking into better ways to improve its to like purge old historical data from it. That's all from the team side. And we are also trying to integrate with shadow fuzzer.

Thomas Coratger: Thanks. Qlean? Okay, London? Okay.

Mihir Faujdar: Yep. Thanks, Thomas. I have one So yeah, we've just been focusing on making the code base of Lantern more maintainable to just implementing refactorings and have just been testing a 5 node devnet on a single server. and have just been trying to resolve the interrupt issues. We noticed that we were still tracking an old commit for lean spec. And have recently, you know, updated, you know. or commit to the latest version. So thanks, Ethlambda, the team, for, suggesting the fix. But yeah, we're still debugGeang some additional issues, and we'll… post an update in the Telegram chat once we have a new image available. And as well as we found out that, the images that we were publishing, we were building images with cache enabled, in the Git workflow. So, basically, the optimization that we were working on

didn't actually translate unless the image was built on the server from source. But we've disabled that. And It should notice there should be no improvements in in the. aggregations and block building. So yeah, that's the update from our side. Thanks.

Thomas Coratger: Thank you. It's Lambda.

Pablo Deymo: Hello, hello. We continue running Interop DevNets and recently made our Grafana public, which shows metrics and logs of all the DevNets we run in our servers. We shared the link in the Telegram channel. We fixed a block building issue where we didn't necessarily include the best payload. We temporarily disable regression aggregation in the aggregator while we work on other aggregation optimizations. And we implemented an optimization for signature aggregation, where we now start aggregating during the attestation interval if we collect enough signatures. We're working on doing a second run of aggregation during the safe target computation interval. We also implemented the recent spec changes sharing the general channel. And we made some fixes to our Hive test driver, and we are currently passing all spec tests in Hive.

And we, in the ETH P2P RS front, we are adding fuzzing. To our library, to our port. We will share an image of his Lambda that we'll be able to run with his P2P soon. Thank you.

Thomas Coratger: Great, thanks. Gean? Grandine.

Mercy Boma Naps-Nkari: Hello. Good afternoon. So we worked on Ethlambda proposal on optimization, the option one and option 2, and then we also made some lean spec fixes. So we are currently testing locally to We'll release a new image once our local testing is done, and also release a shadow image for shadow testing also. Thank you. Bye.

Thomas Coratger: Great. So, on the side of spec, I didn't update that much on spec, just small fixes, especially the one No. as well, like, mentioned by some issues with formal verification. This was very helpful. I think this was done by Shuki or something, I think, if I remember correctly. So, yeah, this was very useful. some small bugs, and, like, this is the first time that I see some bugs, like, detected by formal verification, so that's cool. It allowed us, like, to… to fix some… some stuff that are either minor or… or medium, let us say. We also discussed with the content specification team about this repo, so we are extracting right now, SSZ specification that was done in LeanSpec into a specific repo that is currently under test within the official, like, consensus beacon spec.

with Justin Traglia and his team. And once that is okay, this will be transferred into the official Ethereum GitHub organization. And we will be able to import that directly into the spec. removing all of the SSZ code. So that is a good synergy that we have right now with the Content Respect team. So this is about the spec. About the cryptography, we are continuing working on binary fields. We are making several improvements, technical discussions, and stuff like this, especially on BN254 and on… on LeanVM binary, like, Emil, feel free to say a few words about your work.

T. Wambsgans: Yes, hello, everyone. So essentially, we can now do above 500 XMSS aggregated per second with scenario fields, and so like 3. That's it. Thanks.

Thomas Coratger: Yeah, great. And so we are also working on BN254 with Jim in order also to have like comparison with circuit-based approach. We are also making good progress there, so that's pretty much it. About like DevNet implementation, I think that the next logical step will be like to simulate with the two new improvements that I've been proposed last week by Zeam and And, it's Lambda. so, I think that all of you, most of you guys have experimented with that. So yeah, I think this is what we should do and observe some results with this. Yeah, Mercy.

Mercy Boma Naps-Nkari: Yeah, sorry, I have… I have a question for, Shariq, because the… during his update, he mentioned about the ZIM proposal. I was trying to understand which of the optimization did he… Is running currently with the link he shared.

Shariq Naiyer: We're skipping compaction, so skipping the type 1 application, and we're doing the early bird, early bird block building, and The third optimization that was shared by ETH Lambda, which is removing the block, the proposal signature from from the proof or something. Yeah. Yeah. So so those those 3, they're implemented in ETH Lambda as well as in Teams. So we're just testing it out against ETH Lambda.

Mercy Boma Naps-Nkari: Sorry, if I go, if lambda had 3 M optimization, which one did you skip?

Shariq Naiyer: No, we didn't skip any. We implemented all three, and that's the one I'm testing on the, on the metrics page that I sent.

Mercy Boma Naps-Nkari: Okay, what about the proposal from Zeam, the interval time increase? Did you, is that also part of it?

Shariq Naiyer: We done a quick test with it, but we haven't been running like large because that's like the last resort. So we are testing everything else out before we resolve to eight second slots.

Mercy Boma Naps-Nkari: Oh, okay, okay, thank you.

Thomas Coratger: So yeah, I haven't much else like to say. I think that this is important that you guys are experimenting with these optimizations. and to have, like, numbers. So, if I… like, just as an update, it's Lambda. I have seen that in the… in the Telegram channel, you mentioned that you did some experimentations. And you published some Grafana. I didn't have time to look at it. How many validators do you render these simulations with?

Mega | Lambda: We are running currently with I think 16 validators on.

Thomas Coratger: We'll get.

Mega | Lambda: And on 2 of our Devnets they are the each each one of those 16 node Devnets is running on a single server. So there's some CPU contention and such. We are also running, then… a single egg node devnet with only lambdas. That's one more like a smoke test. It's also a single subnet, that one. The 16 node evidence I mentioned before are, each runs in with… I think 4 subnets. Yeah. And, we are also running a fourth 7… a fourth DevNet with 32, only Lambda nodes, and four subnets, just to, like, see how it… goes with, the most extreme configuration. I think we, if we go to 64, which the like, the server doesn't have the resources, I think.

Thomas Coratger: Yes. Okay, and so what you guys think, are the blockers right now to scale a bit more the number of validators? Do you have an idea, or like, are the proposals that you made last week sufficient, or we need more?

Parthasarathy Ramanujam: Stop. I wanted clarity on this. What are we defining as the acceptance criteria here? Are we okay for justification and finalization to increase in bursts, sometimes up to 30 minutes, we don't have finality, and then suddenly it jumps up? Or do you… do we want a regular, I mean, increase. Say, there should be a finality every, say, for 12 seconds or some… I mean, 12 minutes or so. Because at the moment, Whatever optimizations we have done, we still have this Jump every 30 minutes, 45 minutes, sometimes even longer. So that's something we'd have to agree on.

Thomas Coratger: I think that we need some kind of stability, otherwise this is not realistic with what we want to show, but are you able, like, to… like, to find what are the root causes of these jumps. Is it some.

Parthasarathy Ramanujam: Yes.

Thomas Coratger: How do we have stuff, or like…

Parthasarathy Ramanujam: Hardware is definitely one of the causes. The other is most of the aggregates and block production gets delayed because of the configuration of the servers that we are running in. If you look at the logs right now, aggregates from most of the subnets are almost always delayed. So, I mean, although, justification and finalizations are happening, but they are always late.

Thomas Coratger: Okay. And so this is due to, like, the hardware plus the configuration of the server, right?

Parthasarathy Ramanujam: Yes.

Thomas Coratger: Okay. Anchal, yeah?

Anshal Shukla: Yeah, so I had added, one optimi- one workaround for this in the proposal doc that was shared earlier last week. So in that, like, right now, how we do finalization and justification is that we want to have a two-thirds majority, Aggregation… aggregated payload over a particular source of information. If we can, if we have, like, aggregate that already justifies something of a future slot. We don't add them to the aggregates that haven't been justified, but we have, like, a Suppose we have from A to B, and from A to C. So, A to B should have two-thirds of the votes, and A to proceed, but this can be additive. We don't add them, So, we can…

implement this, and this should improve, like, the time it takes to justify and finalize. But the only downside of this is that if we still don't finalize for… Long time, then calculating this will, have, like, huge memory allocations.

Thomas Coratger: Okay. Okay, yes, since. So… Yeah, Mercia?

Mercy Boma Naps-Nkari: Sorry. I wanted to ask, is there, like, a Zeam, node running somewhere with this optimization that we can actually see? Because it's more like a speculation, and then we need to, like, have a data to back this up.

Parthasarathy Ramanujam: We don't have an image ready yet for this, optimization. We'll release one and let you know once it's available. Excluding the, the longest slot, right? Everything else, I think is already merged to master, but we'll release an official invention later.

Thomas Coratger: Okay, so at least on my side, I haven't much to say more, like, next week, we will not have this call because we are, like, traveling and stuff. And. So, yeah, if this is okay to you guys, let us sync, like, everything async, and let's go back to this call in two weeks. Thanks a lot, guys. See you. Bye-bye.

T. Wambsgans: Bye bye.

Mihir Faujdar: It was.

Shariq Naiyer: Thank you, guys.

Pablo Deymo: My living.

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