Post-Quantum Interop Call #42

Transcript

Thomas Coratger: Hello, everyone. Can you hear me? I mean, yeah.

Gajinder Singh: All good.

Thomas Coratger: Yeah, perfect. So, let's get started. So today we will talk about… we will make, like, the usual client updates. Then we will talk about, Maybe a bit more about, lean spec refactoring that we are doing right now. And maybe mentioning quickly, like, the recent posts that we posted beginning of the week on Eat Research. About Post Quantum public key registry, so that you guys are aware of what we are publishing and what we are doing. And, yeah, fine. I will give myself, like, a brief update on LeanVM, since Emil cannot join, today. So yeah, let's get started with client updates. Zeam, first.

Gajinder Singh: Thanks, Domo. So, we've been working on DevNet 4 scaling efforts, and I think now we have reached a point where we can say that on DevNet 4, for 64 nodes, we are able to have a smooth DevNet, apart from the fact that We have started seeing some issue, which does not seem to be related with the spec, but the P2P. Maybe Bata can talk more about it when he's giving the DevNet runs update. On DevNet5, we… We're able to interrupt with, Ethlambda, we tried interoping with Ream, we are, facing some issues. We… also made sure that Shadow Sims, we got, devNet5 image to run Shadow. So, I think Camille is… Doing some experiments on that.

So… so that's… that has been our update, and… We believe that we have been able to improve our aggregator performance quite a bit with a lot of optimizations and a lot of strategies that we, deployed, to make sure that we can aggregate in time and The aggregates are available to the nodes in time.

Thomas Coratger: Okay, great. Rim?

Shariq Naiyer: Hey guys. on the DevNet 4 front, we have been fixing issues that have been arising, that have been raised by Partha that… in the, DevNet 4 runs. We have implemented the DevNet 5 spec, and we are starting to test and drop with other clients. Some issues are being raised by the Zoom team that we are going to fix. On the high front, we have added a progress bar for the current tests that are being run at this moment, as well as we have split that out by DevNet 4 and DevNet 5 for clients. and on the spec front, we're adding, some text vectors for aggregation and proofs. That's all from the LinkedIn.

Thomas Coratger: Great, thanks a lot for… for the update. Clean. London?

Mihir Faujdar: Yep, hi Thomas, hi everyone. So, on the DevNet5 side, we have, police and image, and we've been able to interop with Ethlambda clients, based on our local testing, still, need to test with Zeam and REAM clients. On the DevNet4 side, we're, like, basically investigating an issue on the snappy decoding, and we'll provide an update once there's a fix available. Thanks.

Thomas Coratger: Thanks, that's great. It's Lambda?

Pablo Deymo: Hello, hello. So, we merged a fix for a clock discrepancy that we have. We implemented lean spec PR, the 802. To skip finalization advance for state finalized policies. We added the station aggregate coverage metric, For the Oscar? We bumped the LMCM version in our .NET 5 branch and shared some performance comparisons. And we are still, working on enabling, ZK dialogue. And we are currently looking into the slow and invalid agora right back. As part of reported on Telegram, we are spinning up our DevNet to reproduce that issue. That's it. Thank you.

Thomas Coratger: Great, thanks a lot. Guin?

Bankat | gean: Hello, everyone. So, just a quick update from the Gean side. So, over the past stretch, we've taken opportunity to do a bit of housekeeping on our own ends, and run some, performance checks before we build… begin building towards DevNet 5 at the moment. So, alongside that, we've been able to carry along some of the fixes for the issue… issues, Partha raised on the Telegram group. So, currently, we're just trying to validate some checks on our own end. Nothing is blocking us. Before, we just… reviewed our template for image. So, once that is done…

Kamshak Lucky| gean: Oh, zoom.

Bankat | gean: Good. So once that is done, I think we'll be rebuilding a new DevNet 4 image for Gean before we proceed to, DevNet 5 runs. So basically, that's just the update on the Gean side. Thank you.

Thomas Coratger: Great, thanks a lot. Grandine?

Mercy Boma Naps-Nkari: Hello, so we updated our tag, we had an… we started doing a profiler, and also we bumped the multi-sync, commit hash. We also made some changes on… lean spec, which has to do with PR781 and 802, I think. And also, The Snipey published side fingerprinting, and then the inboard pair, we included that in our current image tab. And we are currently testing DevNet 5 locally. Thank you.

Thomas Coratger: Great. Thanks, everyone, like, for the update. Did I miss anyone? Okay, cool, so… yeah, I think it would be a pretty quick call, since we didn't… evolved that much since last time. Just to give you a brief update on the… lean specification. I am trying to refactor it as much as I can before the end of the month, in order, like, to present that. Internally at DEF. So… I have made pretty nice progress there. I have removed a lot of used less stuff, I have simplified some tests, indeed, like, the RIM team have added, like, some… proof verification test in terms of test vectors, so I think that can help a lot to you guys as well.

We have done some splitting of concerns inside the spec. We have reordered a bit, like, the folders, we have, like. fine-tune a bit the documentation, and I am continuing to do this. We have also changed, like, the name of Type 1 and Type 2 messages to have, like, some… something more, like, readable and understandable. I have refactored also, like, the post-Saton spec as well, a bit, using some nice Python feature. If you look at… we are, like, a PR from Leo, who is in the Steel team, beginning of this week, in order to split the concern of the big spec file, because before that, the spec.py file was super huge. With pretty much all of the functions there, so we split it there, the concerns.

with different, mixing stuff that you can explore. I can link there, like, the… the PR, let me do that right now, so that you can split, like, you can see the split of this file as a concern. I am trying to… bid on top of that, to make something clear. I have tried to remove abbreviations as much as possible, so that we are very… even if sometimes this is more verbose, like, we are really, like. Easy to read in terms of specification, so pretty much no abbreviation and some stuff that are very explicit in terms of behavior. We have also simplified some folders to put more stuff into the containers file instead of splitting between folder 2.

to have something a bit more readable, and yeah, we have simplified some primitives, increased the test coverage, so that it's basically all. You can check the history of PRs, I am doing that, a lot right now, in order to simplify as much as I can. I have other PRs that will come. In terms of research, we continue doing continuous development, let's say, on Plonky3, where we are improving some performances, adding some small stuff, adding more tests, all of this. So… in terms of, research that is eats, in terms of, lean VM, so as I mentioned, like, Amit can join today. And so, he is working on a bunch of things right now to simplify the codebase, to simplify the compiler.

Hmm… improve some performances, measures, and all of this. Something that he wanted to share, and he told me to say, is that he's working on a branch that he will soon merge inside LeanVM to replace Rayon. So Rayon is a parallelization library that we have in Rust to parallelize things, so you can natively do some parallelization loops and stuff like this. With a custom thread pool. In order to stabilize… to stabilize the ZK analog syncs, that is a way to save memory, and so to increase the performance indirectly. So he's working on that, because previously he had some strange bugs and instabilities, depending on the architecture or depending on the run, and so he's working on this kind of custom thread pool to replace Rayon, and to have more stability with this memory stuff.

That's it in terms of LeanVM. Now, as I mentioned, like, at the beginning, we published, beginning of the week, an each research post. Let me check where this is… there. So, yeah, we have this EATH Research Post. So, that was quite long to publish, because we iterated a lot on this internally, to propose something that is pretty decent. So, maybe, since we have time, let me… Share my screen, so that you can see. Okay… Okay… Can you see my screen?

Shariq Naiyer: Yep.

Thomas Coratger: Perfect. So, yeah, we published this first, so I think this may be interesting for you, because, like, this concern directly, of course, like, the post-quantum efforts. So yeah, we have a bit of an intro there with a strawmap and that, but you know that. a part of context and stuff. This is decoupled into two parts, so in the first part, we have the foundation, so this was important in this post to present, like, the XMSS Signatures that you are all pretty familiar with, so… but in a very educative and didactic way, so that you can read the paper that is linked There, if you are interested into the cryptographic primitives and analysis and proofs, but if you want just a brief intro with some drawings and some explanation, this is there.

So, yeah, we introduced the XMSS paper, why we have chosen this one, why hash-based signatures and not something else. everything else. Then we present how XMSS works, so the principle of hash chains, the fact that we have multiple parallels hash chains for security. Why this prevent forgery? Then we have, like, the… we present the scaling to many-time signature, where we have the concept of a tree, of one-time signature. Then the… how do we sign, what is the process for signing, what is transmitted between, like, the… the prover and the verifier, then we present it a bit what should be registered, so this means that when we have, like, the event of the public key registry, what we should do.

What should be registers, so we have all of the size of things with explanation. Also the signatures, with explanation as well, of all of the parameters. The secret key, how do we try to save a bit of memory, by using, like, some kind of bottom tree plus top tree, so that we just store two of them, two of bottom tree, and then we Geanrate the other one on the fly. Then, we speak about, like, koala Bear and all of the field stuff, why, why we are choosing this, what is the advantage, and all of this. all of our production parameters. So, yeah, everything like this. all of the different parameters of XMSS, so the number of hash chains, the target sum, all of these, so that people can check that.

Yeah, also about the hash function, why we are using Poseidon one, why not another one? the… the parameters of Poseidon as well, Yeah, that's all. Then we present a bit of context about signature aggregation and VM, why we are choosing SNARKs for now. all of this, why we need to aggregate all of this. We say that the hash function is on a point design space, because in case Poseidon is broken, we should find, like, a replacement. So we propose some replacement there, especially it's Cheyenne Blake. We say that Poseidon has been subjected to recent attacks. And then we have these second parts about, like, the design consideration for the registry, so how we should be authorized to register.

what would be the cap of number of processing per block, and about the stray growth, all of this, so the different options. We present also the hash function of GDT. What does it mean? It means that in case Poseidon or or Poseidon in Geanral is broken, what should we do? So we propose to Geanrate a public key for different hash functions, so then the validators have the choice, and we can just switch from Poseidon to another hash function in case this is broken. Yeah, a couple of, MISC stuff, for serialization and theft. some practical consideration for the validators. So, for example, like, what we should expect in terms of memory for the validators and things like this.

Yeah, community tooling, and we have, like, this, also this final section about, like, open question and future work, so we draw a bunch of open questions. So that we can discuss with the community, such as, like, the hash functions, some fancy cryptographic proof about, like, XMSS standard model, VS, like, random oracle model. the finite field also, KoalaBear VS Goldilocks, VS something else, potentially. So, yeah. So this is very open in terms of discussion, so that you can check, and you can comment on this post. The goal of this was to, at the end, to have an EIP, And so right now, we have this post as a discussion starter, let us say, so that people can start to interact and to discuss. We already had, like, a couple of responses to the post, so feel free to check, feel free to read, feel free to post any answer.

So yeah, that's it in terms of feedback for this week. Do you have any specific other things to discuss? I guess that right now, we are in a position where we are consolidating everything from the feedback that I heard at the beginning of the talk. you are all, consolidating, debugging, trying to implement DevNet 5 for most of you, trying to interrupt with DevNet 5, so… yeah, I guess we are at this point, so yeah. Yeah, Camille?

Kamil Salakhiev: Yeah, hey everyone, just, want to get some alignment on, what is current priorities. So, I see that people… well, it seems to be implementing DevNet 5. Are we trying to implement DevNet 5, or are we trying to stabilize DevNet 4? I'm asking because, like, what I should be focused on for the.

Parthasarathy Ramanujam: Hello.

Kamil Salakhiev: tests. Currently, I'm using, yeah, DevNet 4 branches, but I hear that, yeah, Zeam and ETHLambda and maybe some other teams already have DevNet 5. Yeah, so I can switch from that.

Parthasarathy Ramanujam: So.

Kamil Salakhiev: Because in the.

Parthasarathy Ramanujam: That is probably one of… something that I wanted to raise as well. In the past two calls, we agreed that we have to set some, I mean, acceptance criteria for DevNet 4, but we never defined them. So I was hoping we could do that in this call. Before we start, testing DevNet 5 on the servers rather than on local machines. We still don't have stability on DevNet 4, so if everybody are in agreement that if we can probably say that a stable DevNet4 is something that runs and progresses well for at least 24 hours, is an acceptable acceptance criteria. And then probably we can work towards that, and then start testing the network. Is that agreeable to all teams?

Gajinder Singh: In my belief, I think DevNet 4, as such, I think we are stable enough, apart from the new issues that we are seeing, which does not seem to be related to DevNet 4, for the snappy encoding error that we are seeing, which is causing all the issues. And if we basically run in sanitized all Zoom, for example, all Zoom network, we, we, for example, are able to run for a long time. So we are also trying a mix of the clients to see where we don't see that snappy encoding issue, so that we can basically pinpoint the client from where it is originating from. But all that is not really, I think, is something that is different from spec. And in that sense, I would basically like us to just move to DevNet 5.

Spec, because right now, we have DevNet 5 implementation, and other clients also now have DevNet 5 implementation, and basically, it makes no sense to not shift towards DevNet 5 testing, because that is the spec that we want to target. And shows scale and stability on. So I don't see a reason why… why we should not move to .NET 5.

Kamil Salakhiev: Okay, yeah, for now, from what I see, so I've been, at least on my side, I've been testing, Yeah, the shadow branch of Zeam, I think it's DevNet 4. Yeah, I didn't try DevNet5 yet, branch. Yeah, but what I saw, I think I shared the link to the simulations in… In a channel. Basically 32 nodes, they work relatively stable. I mean, well, they finalize and everything. When I tried 64, they are not stable. I mean, they are… Yeah, we see that the chain is finalizing not every block. I mean, there are gaps, like, 20, 30 blocks sometimes. Yeah, that's only Zeam. For Qlean, I think it also was not super stable. I don't remember all details.

I'm trying to test more clients. Yeah, I kind of I-coded East Lambda support for the Shadow, because, yeah, for them to work in Shadow, we need to disable Gemma Lock, and, I think there might be some patch required for the P2P. Anyway, I can create a branch to Ethlambda if they want to take a look. Yeah, and that's… and that simulations, they do not have any artificial slips for the aggregation times, so they kind of ignore all the compute overhead that we have when we aggregate. signatures or snarks. So, in reality, yeah, the situation might be even worse. So, yeah, just saying that for 32 nodes, when we assume, like, aggregation is instant, yeah, at least for Zeam, yeah, we're good.

For more notes, yeah, it's getting worse. Yeah.

Gajinder Singh: Yeah, so I think scale… yes, so scale is definitely, one of the focus areas, and that is why, basically, we started scaling. But, again, I guess from… So, from what we started noting was that now the optimizations that we are trying to do, basically. Some of them are like, okay, you know. this optimization… optimization is not needed, because this won't happen in DevNet 5, right? So those… so now, to basically not… Do extra optimizations, which won't be needing in future, and not to, invest effort in something that is… that we are not targeting. I don't… I don't see any reason, so that is why I'm like, let's just… moved to DevNet 5Spec, and… Let's just… let's totally focus on that now.

Parthasarathy Ramanujam: Can we target at least one stable run of DevNet 4 before, probably switching over to DevNet 5? Because, I mean, if we have isolated that Lantern, is the one that is having the issue, then we could attempt to, probably achieve, finalization with other clients, and if that progresses, then we can switch over to DevNet 5. But having said that, we still have that concern with the servers that we are using for running these DevNets. If, I mean, DevNet Phi's hardware requirements are, I mean, more, or matches that of the aggregator configuration we are using in DevNet 4, then we need to procure new servers, or probably not run such a massive DevNet, probably just a single subnet DevNet 5 testing. That's another thing we'd have to agree on.

Thomas Coratger: Yeah, just a word, and…

Gajinder Singh: just confirm this, that the error is finally coming from over there or not. If it's not coming, then let's just move, right? If it's coming from a particular issue, and let's just move to… I mean, it shouldn't take too much time to confirm this particular thing.

Parthasarathy Ramanujam: Yeah, as of now, with our local testing, I've identified it's probably Lantern, but if other teams can run their own localized test as well, with each client, like how Anshal and I have been doing, it would be great, so that we ensure we have not missed something. And, because it occurs at random, I mean, I'd probably, give you an update as I was, like… I mean, what I've noticed over the past week is that the snappy issue during a snappy decode error, especially occurs on the gossip side, and it is not deterministic. It occurs at random times. Sometimes in the very first slot, sometimes after 100 slots is progressed, so I can't… really tell you when, or what causes this error. It's only just before this call, when we were running,

two, individual clients and testing it against them. Did I discover the problem happened when Zeeam was interacting with Lantern? But I don't know. I would probably request every team to run similar tests with their own clients being stable and compliant against other ones. Leave the, I mean, the DevNet running for at least 15-20 minutes, because it's not… we are not sure when exactly the error occurs. And if this stabilization or the finalization occurs, then maybe you can stop and retry with another client. So, that's one thing, and the other… I shared the aggregation metrics. Thanks for everyone who responded and added the necessary metrics there. It's much better I'm able to view for all teams, but one thing I would like to point out, that although eTlambda's timing appears a bit off.

If Lambda processes more aggregations than compared to other clients, so that's the reason why I've added a new metric there. If a particular client is missing an aggregation, we need to know what is causing that aggregation slot to be missed. So, that would help us determine where we are going wrong, or where the… what's the health of the network. I just needed to understand, is it because aggregators don't have enough attestations to aggregate, or there is a… it's still catching up or syncing, not synced up, so that would help us determine where we focus our efforts to improve and scale the network. So if you can implement those metrics, then let me know. I would probably use that in the next run, and yeah, and then once we agree on when we start testing DevNet5, we can start using that.

So that, that, that was my update as well. Thank you.

Gajinder Singh: So, as I understand, this particular part is not going to go away in DevNet 5, right? This particular mechanism is going to work in the same way, so all the things that you mentioned will just carry over there. And the only concern that I hear is that… of the machine configuration. And that is something, yes, that we can think and discuss. But I don't want to wait another week to start DevNet 5 testing. I just want to start it, like. On Friday itself. So, maybe… till Friday, we have some time to figure this out. If we can figure this out, then all good else, let's just move to DevNet 5 and start testing over there.

Thomas Coratger: Yeah, just a few words, and then maybe Mercy. Yeah… I agree, like, for me, this is really as you prefer, because this doesn't change anything, like, at least from my perspective. If you prefer, and you feel more comfortable going to DevN5, I agree, this is a good choice. Because at the end, the point where we want to stabilize a bit and consolidate is for DevNet 5, because this is where we will have, kind of. let's say, more realistic settings, because we will have, like, a single proof on-chain, and so if we want to present that to the community, for example, this is a much more realistic setting than having multiple proofs on-chain, because everyone knows that

Multiple proof on-chain for one block is not something that will be final design. So, this is much better to propose. So, yeah, this is also where I am consolidating the spec right now. I am iterating on DevNet 5. So, yeah, if you are already, this is totally fine for me to move like this, and we will… we don't plan to add new features to the spec. we are pretty stable in terms of the spec. I think that we are far from stable in terms of, Of, like, the spec being perfect, being beautiful, being usable, being compact as we want, being documented as we want, but in terms of feature, at least, we are pretty complete, so this is a good way to go.

Yeah, mercy.

Mercy Boma Naps-Nkari: Yeah, so Partha did mention about, running each client, running the DevNets individually, so we tried doing that on our internal servers, and we discovered that the difference in multi-sync commit hash is causing an error, so… which commit harsh are we supposed to focus on? Because, rim and, grinding is on the same commit hash. Ethlambda. is on a different committage. So, that also is… could contribute to the issue we are currently seeing. So how do we… which of the committers should we target?

Thomas Coratger: You mean in term… in term of suspect? Oh.

Mercy Boma Naps-Nkari: Yeah, the lean more to sing, the… what's it called? The… the Commit Hash. Remy's on, 5, 6…

Thomas Coratger: Six…

Mercy Boma Naps-Nkari: Grandine is on 566, then Eat Lamba is on, I think, 5EBA. thereabout.

Thomas Coratger: I think this has been, yeah, this has been bumped by Angel yesterday. You can find, like, the commit there. I think this is the right commit to target. This is the latest one, at least.

Anshal Shukla: Also, like, the issues that we were facing while trying to interrupt with Grandine were more on the P2P side. not on the lean multi-sync side. I'm not sure, if this is, like, the right There has been a separate conversation between R&D. That'd be cool.

Mercy Boma Naps-Nkari: Are you sorry. What did you say Grandine happened?

Anshal Shukla: Yeah, so, I think I tried interoping with Ream and Grandine, and there, the issue was more on the P2P side, not on the, aggregation side as such. So, like, I couldn't reach that stage itself, so, Can't comment there, but I think right now the issue is more on the P2C side, when I try to run, like, a single… like, a Zeam plus brand Zeam setup, but… I'm not… I'm not sure if this is something you were referring to when you said, so I'm not sure, but while doing these single… Like a… like, two, two client runs, I faced an issue, with Grandine on the P2P side. There were, like, a few errors, I can share them, but, like, it is just a basic run. I didn't even run it for, like.

5 minutes. That is…

Mercy Boma Naps-Nkari: That is what I'm saying. That issue is happening because of the multi-sync Commitage difference. I did run Zoom, grinding. There was no colonization, that was an issue, but it wasn't on the P2P front. then on… on… grinding rim works well, and then the other clients on the same commiss with us works well. But with Ethlambda, it was the same issue I had with Zeam. That's the same issue I'm saying.

Anshal Shukla: So that is what I'm trying to point out. Uma mentioned, like, I updated it to the latest commit pass yesterday on the lean spec. I'll look at.

Mercy Boma Naps-Nkari: Do you know… Sorry, let me get the message, Emil sent on the group chat, let me… so that I can point the committash I'm talking about.

Anshal Shukla: integral.

Thomas Coratger: Yeah, I think, like, the right commit is this one.

Gajinder Singh: I mean, on, can we basically just update this? I've not.

Mercy Boma Naps-Nkari: the issue I'm talking about, the… the… I just pasted the message I got, that Mew sent earlier on, on the Komi Hash, which is… 5, 6… something. That's the commit harsh I'm referring to.

Thomas Coratger: I think that we can… maybe we can sort that async on the group. For sure. Yeah.

Gajinder Singh: I think this is just a communication issue, right? So can we just maintain the commit hash that we are using on… Wherever is our DevNet specs page, so that… It's just straight to everyone. And so it is a PR that people will say that, okay. Yes, are we on this PR or not? I mean, it is as simple as that.

Thomas Coratger: I am pretty sure, like, Mercy, that the commit that is referred into the message that you put there, A66 something, it's a DevNet 4, commit, and then we had an even more recent new commit that was just done yesterday, that is 8FCBD something, and I think that should be the one for DevNet 5, but let's solve that async.

Shariq Naiyer: Amazing, amazing.

Parthasarathy Ramanujam: So, can I just check, those who have tested, the DevNet 5, image, does it work well with an 8-core, 16GB machine? Is that a sufficient configuration?

Gajinder Singh: And this is a normal validator, not an aggregator, right?

Parthasarathy Ramanujam: Correct. Now, I think we can reuse the existing validator configurations as it is, but the regular validator is what I'm asking. Instead of using a shared server, if we decide to go ahead with DevNetify testing, we could probably use one container per server, and… target maybe a 32-node DevNet, or DevNet 5 testing. Assuming, 8 gig… 8-core 16GB is sufficient enough machine to run the regular validator.

Gajinder Singh: I mean, 16 GB sounds more than enough. You are just wondering on how many cores is required.

Parthasarathy Ramanujam: Yeah, but I thought, the, I mean, aggregation for block production was time-consuming, or it took a lot of time. I don't know. I mean, I'm looking at Anshil, Kai, or anybody from Ethlambda, Sharik, since you guys tested DevNet 5.

Shariq Naiyer: So, I ran it on a single machine, but it's, like, it's M4 Max, I don't know how many cores it has, like, 36 gigs of RAM, so I don't think that's, like, super relevant. But I ran, 3 nodes, 3D nodes.

Parthasarathy Ramanujam: 3 nodes on the same machine, so assuming, each container had access to at least 10GB of memory, right?

Shariq Naiyer: Yep.

Parthasarathy Ramanujam: Okay. But it's more CPU-intensive, right? RAM really doesn't matter, or is RAM the… Major factor here.

Shariq Naiyer: Yeah, I agree with that, you would have to just run some tests and find out. dead.

Mihir Faujdar: Yep, I… I guess on the Definite 5 side, I also did testing on the M4 Mac chip, and basically, Docker application itself, it had 10GB of RAM. One thing I noticed that, when running for lantern noise, basically. when… like, basically, if it had 7 attestations to aggregate, it would run out of memory, so, I would see, like, those kinds of cases, but, I have been experimenting with the new, lean multi-seq commits, and have been noticing it improves, proof Geanration time. Which has been helping, but yeah, I'll have to do more testing.

Mercy Boma Naps-Nkari: So, on our own end, we are using 128GB, and then sometimes there's, like, a slow, the last round, the block production was slow. A little bit, but I still need to, like, do some testing and also update the multi-sync, the hash.

Parthasarathy Ramanujam: Okay. Thanks for that, Tim. Probably we have some information. We can give one a try once we've run another DevNet for one last run.

Gajinder Singh: There is something that can be done. While… when we basically, in the last, Interval of the previous slot, when we are… basically, we are accepting new votes into non-votes. that… That basically seems like a very light… Work, and even without that, basically, you can start aggregation On something that you think, will most likely show up. In the block, right? So… On optimistic levels, you can… you can do a multi… you can do, basically, Data, multi-payload aggregation, for the same administration data, right? So… so we… we have… actually have more than one… we have basically one interval to prepare for it. So this is something I think we can add in spec, as well as we can first test it out in clients, and

If this works well, then basically we can also add it in the spec, although this seems more like… a client optimization, then a spec optimization, but I basically leave it to Toma if he wants. Search and optimization in the spec.

Thomas Coratger: Yeah, let's see, after the consolidation a bit of the spec, we can… we can check for this kind of optimization to see if we want that. Anything else, like, to discuss for you guys? Okay, that's great. Then see you next week.

Shariq Naiyer: Amazing. Have a good one, guys.

Thomas Coratger: Bye-bye.

Mihir Faujdar: Thanks, everyone.

Gajinder Singh: Everyone.

Pablo Deymo: Highlight.

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