Post-Quantum Interop Call #21

Transcript

Well, we'll just give it another minute or two before we get started. Okay, let's get started. Uh, welcome

back. Welcome to 2026. Hope everyone had a really nice restful couple of weeks off. Um, this is call 21 in the PQ interrupt series. Uh, so yeah, we try to stick with the same kind of format structure each week. Uh we start off with client updates uh and we tend to go in reverse alphabetical order so we can uh pick on gadgeter to to lead us off. So uh Zoom team >> hi well hello everyone um uh very happy new year and yeah so uh the updates are that uh we basically stabilized and made

uh ZIM client a little bit more robust in terms of dealing with memory issues by handling some pruning uh both on uh the states that we were caching as well as the fork choice pruning that uh that we were earlier not doing and uh we also plan to to introduce a PR that actually does straight pruning as well. So uh that would be a spec PR and that uh is something that will require every client to implement because it's a consensus change and basically it's about pruning the justifications and that PR is something that we will put in this week.

Apart from that uh we put in PR for uh uh for aggregation of the attestations using leanvm and uh that PR has been merged. So we are assuming that most of the clients would be working on it and hopefully by next week I hope that most of the clients would be ready for DevNet 2 and uh then we are also planning for the next Devet where we will uh separate out the aggregator role. the current role is uh the current aggregator role is held by the proposer

itself. So we will have a separate aggregator role and then we'll start uh doing uh experimentation on the kind of P2P network that would s that would you know um that is best optimized uh for this uh for lean Ethereum. Uh so that is sort of the plan. Yeah. Fantastic, amazing update. Thanks, scheduler. Uh, REM team. >> Yeah. Um, so for us before the new year, we integrated the precursor PR for signature aggregation. Um, as for this week, we are working on obviously the

integrating the aggregation PR. Um, we are also working on the sync features so that our our nodes can catch up if they dropped off uh in the middle or if they started late. Um, as for state pruning, I think we just I think Kobe just asked in in the the one of the chat whether we can prune the states older than under 28 slots. Um, I think we went ahead and and applied this into uh already. Um, so just just a note on that. Um and on other stuff yeah there's um so the pro keys um the lean spec has been updated and the signatures generating before um the the change by Toma um the keys

uh would be incorrect so they have to be regenerated. Um so we just finished in um regenerating that and integrating that back into the test vectors. So hopefully starting from the last comment in the main branch in the inspect right now the test vector should be testable. Um so basically you should be able to to verify signatures generated from from the test vectors. Um and oh yeah and uh we also just did a refresh to lean road mapap website uh leanroadmap.org.

Um so a couple things we listed multi lean multisc benchmarks in there. Um I just like took it out from from the notistic repo. Um we listed out the deaf nets both um past and present and also updated a bit of the the resource listing. Um so that's uh that's posted our tweet and obviously that the website is is leanromap.org. >> Amazing. Thanks so much. Uh clean. Hey everyone and happy new year. Um yeah on our side uh yeah so yeah mostly was working on stabilizing uh devet 2 kind

of yeah we have uh clean working with other clean clients uh with aggregations already but yeah kind of need to ensure that everything works according to spec and then yeah I believe I don't know in the nearest future we might even start uh checking interrop so uh yeah stabilizing this in parallel trying to kind of make a version of clean which we would be able to uh use for networking analysis of the net 2. So that uh basically yeah we can configure uh basically we can replace the real cryptography with kind of fake cryptography because this is not something that matters a lot for

networking stuff. so that we can configure kind of the size of the aggregations [snorts] um yeah aggregation rates uh for signatures all of that stuff. So uh yeah working on this so that uh yeah we can check um yeah how the net 2 performs when we have a lot of nodes and this hopefully would kind of give some picture uh what yeah whether it makes sense to optimize uh anything on PTP layer um yeah other than that you have been working on some new just u improvements for the logging so that they are a bit more clear and easier to read Um and yeah and working on um memory

issues. So basically just introducing uh persistent storage with pruning for states and uh uh blocks. So yeah, the new PR that Gender mentioned. Yeah, I think we'll need to check it out and maybe wait for this before we merge this PR. And yeah, I think that's all from us. Thanks. >> Thanks, Camille. Uh, lantern. >> Yep. Hi everyone. Happy New Year. Um, so from my side um basically preparing for DevNet 2. um basically started with um creating C bindings for the lean VM XMss uh repository multi lan multi repository

uh based on the DevNet 2 branch um and then start implementing the leanspec PRS merged um into into lantern for DevNet 2 um and as well as have reached the part where the spec tests are are passing um the signature tests I was waiting on the the right scheme to be working for in the lean spec, but I guess the ream team just gave us an update that it's working now. So, I'll just be uh working on fixing that uh in lantern. So, the tests are passing um and as well as been experimenting with uh request and response uh routes um in lantern. Um basically I

think two days ago in leanspec there were some changes um to remove um lean underscore um from the protocol ID. Uh so you now just have blocks by root. So I've just been implementing that as well. Um and I guess in terms of uh next chain next steps uh for DNET 2 is um trying to interrupt with other clients uh when they're ready. Um so yep that's our update. >> Thanks Mahair.

Uh Lighthouse. >> Thanks W. Um happy new year every everybody. Um so yeah on lighthouse part I've uh mostly spent my time uh like clearing out a lot of uh backlog that I had in code and uh like improving logging and then uh telemetry for us. Uh I had some like issues in DevNet one there um like there was a consensus bug in my uh in the code. So um I've fixed that and then uh I've also fixed the syncing issues. So I think I should be able to push out a image with that and

uh yeah I've al also started work on the aggregation uh signature aggregation part. So uh I think I'm lighthouse is probably on track for DevNet 2 as well. Oh uh there's uh one more thing I wanted to add. I I have posted a PR for uh dynamic val validator list uh but it's not completely required at this m moment but uh it would be nice to have >> great thanks mouse uh grandine just throwing out there see if uh the next two teams have anything that they want to provide an update on.

>> Yes. So, so uh we plan to open source the client sometime very soon, maybe next week or or something uh like this. And uh essentially working on uh on being fully compatible with upcoming DevNet. uh but yeah I think once open sourced it will be uh some cleanup and in integration stuff uh uh that is needed to be done so yeah I think we are focusing mostly on that now >> thanks

looking forward to that um and welcome to ETH lambda I don't know if anyone from the team is on that wants to provide a an intro or say any Um yeah, hello happy new year to all of you. I'm Thomas or Mega from the East Lando team. Um I can give you a like the current status of the client. We already have a working integration with me and quick start and we are currently parsing validator config files and dialing validators at startup. Um we also uh are currently receiving status requests from

other clients. Um and we are basically uh right now trying to catch up to the first two devets. Uh we are currently working on connecting to gossip and listening for new blocks as our first milestone. Great, welcome, Tom. Um, okay. So, that wraps up client updates as far as I can see. Um, let's jump to research and spec updates.

Uh, I don't know, Tama, Emil, Benedict, one of you has any updates or wants to kick us off. Um I can give a a brief update on the spec and stuff. So [clears throat] my goal now um at the beginning of the of this year is like to transform a like to add components to to the lin to try to build like a minimal Python client in order for the spec not just to to compile and to give like spec stuff but also maybe to [clears throat] be able to

run as a client. So I am trying to build a very minimal stuff next to the spec so that we can run the Python as a client. So for example I am building some very minimal peer-to-peer components um to be able to run this. I try to do that without any external um dependencies. So that's instead of using uh Python P2P for example or stuff like that I am trying to build a very minimal component so that afterwards if we want for example to tweak uh component to modify some algorithm to

check some stuff with regards to the postquantum aspect of the signature then we can easily modify component without worrying about external dependencies that should limit us. So I am trying to do that um a bit during the early days. We have also merged in the spec couple of PRs about like signature aggregation, cleaning up the the repo a bit by removing stuff that are not used anymore. Uh this kind of stuff. So that will be my goal um beginning of this year. Um on the cryptography side um Emil can give like an update on the on

the lin VM but uh yeah we are trying to improve the lin VM. I think that Emil did a great job of simplifying the the VM and and all of this stuff. So we are trying to move forward on this front to be able also to um include the lin VM as a minimal spec as well inside the lin spec as soon as possible. I don't know when it will be done but as soon as possible. >> Yes. >> Uh thank you. If you want I can continue if you want.

>> Yeah. Yeah please go on. Um so on my side I am working a lot on recursion. I am quite close that still some work remaining but um I am fully working 100% on on recussion right now uh about integrating UNVM in the Python spec uh Justin gave me this idea recently because uh currently to write the regression and the XMss program there is this high level uh ZK DSL that has been spec specially designed to make the highle program compile to the low-level lin ISA and Justin gave the idea that we

could potentially try to make this highle ZKDSL a subset of Python in order to be able to directly integrate um it to the uh specification written in Python. So in some sense the we we would use the same um Python source code both for the spec and to compile to the low-level line. I'm not a 100% sure um how easy it would be, but I just wanted to mention this idea because if we can make it work, it would be a very elegant elegant way to to conclude the

integration of LINVM into the specification. That's it for me. >> Very cool email. What's the DSL called? Not lean by chance. >> I don't know. Currently there is no official name. I don't know. >> Okay. Uh any other spec or research related updates? Cool. Uh maybe let's jump to metrics and observability. Um, and if someone could close the loop on where we're at with uh, DevNet one and kind of our,

uh, machines required for long running DevNet. >> Yes. Hello everyone. Um, happy new year. So, uh, I I can make a quick retrospective of DevNet one. Uh, at least uh, what I worked on these holidays. Um uh I want to wrap it into the hackmd uh but sorry didn't have much time so I will just share it in the chat uh quick item list. Uh so um I I found some issues for DevNet one and they share it with the teams. uh there were like memory and storage issues also request issues and finalization

issues and I've also noticed that um different clients have uh different genesis anchor blocks regarding target and source. So some clients um report that that they have zero target and source and others report that they have like um genesis uh block um source and anchor that potentially might cause um an issue with when starting the devnet. Uh so I'm still investigating this. Um we'll share the updates later.

So the next big issue is um syncing the lack of syncing but currently the clients are working on this. So uh when we don't have syncing it means uh we lose one or two clients and we fail with finalization. Um and for long ter um long-term devets uh we definitely need syncing so clients can jump off and on from the devet and that would make uh the devet stable and also for this we need u dynamic validators count because u if we start uh with five um validators five clients and later we lose two clients so uh we

don't have like enough votes uh at the station votes so all the devet fails. So these are the the issues with the devet and uh currently I'm waiting for new images from the clients they are working on on the fixes etc. and thank you for collaborative work. Uh the logs were were improved and the dashboard is also like moving forward and the plan from uh from the observability side is um to to deliver metrics for um aggregated signatures

and I shared the PRs um in the chat which need your attention. So I'd like uh nodes in for some stats reorgs and syncing. Uh this is would be nice to have for for dead net too. Um and I'm going to um to build the shared graphana dashboards for clients so they can also u see what happens on the template 2 site. to monitor their own nodes, compare with other nodes and um yeah, I guess that that's it. Maybe it will take one or two weeks for for managing this and we'll share the

updates later and probably we'll add graphana lock if it's possible with this setup so you can see the logs as well. Thank you. Thanks very much Kasha. Um any other updates? Just to add to the long running devets. I think uh so basically thanks a lot Katya and Partha for doing this and keeping the devets up and trying to run them again and again. uh so all the

issues that uh that you guys have sort of you know published and uh distributed among the teams and I I think you know we teams will continually work on it and improve it and we will see the stability increase but we will not stop going to DevNet 2 for example on the next week just to basically you know uh so so what will happen is that uh the longunning DevNet will now change into longrunning DevNet 2 next week onwards and we will continue debugging these issues on on the next version of it. uh so we will not basically wait for any of these uh

issues to finally resolve but uh our aim is to finally have a long running devnet and uh uh I think what we need really need to work on is basically make sure that finalization keeps progressing even when intermittently clients can have issues and they can also crash and they they they can come back up and for that we basically also need uh checkpoint sync and that is something that we are trying to add in Ze and then we will basically also raise a spec PR uh to uh to basically publish uh spec for the API uh to p uh to fetch the checkpoint state

and we will only focus on uh the finalized checkpoint state. So whatever finalized uh is with the clients and they will only serve that checkpoint state they don't need to serve anything more than that and that is what they will be serving as well. So uh we will keep the scope limited but make sure that you know we can restart the clients using checkpoint sync and then block by root uh request response should be able to help client sync up to the tip. Uh so this is the plan and uh again the focus is that uh even when client have the intermittent issues finalization keeps on progressing so we have a longunning

devet. Uh so with that regard uh we still have some hoops to jump uh to the point where we basically reach and say that okay you know we can have long devet. I think we have had the dev net run for a day when we start seeing these issues and uh as we fix more and more of uh these things we will be able to uh uh start uh elongating the length of uh elongating the life of the deveter Uh, Partha, with your note you dropped

in the chat, are you blocked on getting those additional machines? Is that something that you would need uh help with or you're just sort of giving us a heads up? >> Sorry, not blocked really. I just passed in information. I'll speak to E and Ops and yeah, work with the Kacha to get that ready. Great. Thanks. Okay. Um I think that's sort of the conclusion of the structured part of the program. I don't know if there's plenty of room here for open discussion items if anyone wants to table anything.

Yeah, I just want to add something more because Katya mentioned that uh not everyone not every team out there has uh has their sort of channel in which she can post issues. So we already have a channel for DevNet and uh I think every other client uh so whichever team member from the other clients are involved in fixing and ensuring longunning devet uh so they can join in and I katya or parur I can add them to this particular channel so that we have a good coordination over these things.

And the quick update from ream side. So share just mentioned in in the chat that um he managed to integrate the new um test vectors into ream and they are passing. So at least now we know the the linspec the signature the keys generated from linspec should be compatible uh with the rust based um insect codebase Should we use the depleted chat for um

metrics as well because like metrics are unified for all clients. Um I don't know if there is if makes sense to you know to make multiple chats maybe it's it will be enough like to do it in one chat so I can share metrics new metrics PRs etc. If if no objections,

yeah, let's get back to it in in the devlet chat. >> Yeah. >> Yeah. I guess like the same chat is fine because it's quite a small group and I guess like too many chat groups and we get lost. So I I would vote for for same chat until it gets like really messy. >> To be honest, I really miss Discord. I don't know how how you deal with the Telegram chats. But in the Discord when you see all the channels and you can make threads um um I don't know, for example, I have this PR and I can open a thread specifically for this PR and discuss it.

Um, that was actually quite helpful. I don't know. How do you feel about this? I'm happy to support whatever. Uh, yeah. I don't want to force people to have to work at a a specific way. Um, you know, so I'll just leave it to the team leads to determine uh where they're where they feel best working.

Um if no other topics just curious uh what other teams thinking uh should be the feature set for DevNet 3. Um yeah so Gajender mentioned something about regarding like PTP optimizations. There were also talks like maybe introducing recursive aggregation or decoupling um kind of the aggregator role from proposer. I don't know any ideas. >> Yeah, I think if lean VM is uh ready with recursive aggregation then we will definitely have recursive aggregation and apart from that uh separating out the aggregator role. So I think this is

sort of the main focus this should be the main focus for DevNet 3 and if there is any P2P optimizations that we can start looking for uh I mean for DevNet 3 let's freeze the scope to this and then maybe for DevNet 4 onwards we can start talking about uh P2B optimizations. Uh do you have any proposals out there Camil? I'm just thinking from that regard. I mean if we introduce recursive aggregation uh as I wrote in the chat like yeah it's we we need to think a bit how to kind of introduce this properly because if we just uh split kind of the

network into the subnets then it's not really compatible with existing consensus model because we kind of need we have the safe target in the third interval of the slot and it expects that every validator can observe of all signatures and if we split it into subnets then validators they can only observe kind of the signatures from their subnets which is less than two3 I mean for in general case um the in I just want to interject over here in my opinion I think uh uh so validators will listen to the aggregator aggregated signatures across everything across all

subnets and uh only the aggregators will basically listen to their own subnets for uh aggregating their signatures. So in that sense all validators should have signatures uh in in the fourth interval right. So in the third interval the aggregated signatures are supposed to be created and published. So uh every validator in my opinion should have most of the network view in the last interval.

Yes. Yes. That's the way uh but for that to work uh yeah we clearly need to kind of um yeah decouple the aggregator role from the proposer. So this is definitely from my opinion should be well in the closest DevNet or maybe I don't know the one after this if um >> yeah so I think this we want to do that in DevNet 3. So uh uh camel if you can sort of lead on this particular spec I think that would be really nice uh so that you know we can uh leverage your expertise on this.

>> Mhm. Okay. So just to clear to be clear so devet three we don't do recursive aggregation we only do kind of aggregator role separately right >> so we we can have we can have recursive indefinite tree I mean I don't see an issue I mean it's about the readiness of uh lean VM >> yeah it's just we yeah we can do this it's just a bit it's a bit more features like if we do this then we kind of need to have both um local aggregators and then global aggregators and there are so many aggregations.

So let's say let's say we don't have global aggregators. Global aggregator could just be the proposer right now. We have proposer who is doing you know all the aggregation. But now once the aggregator role is out there then the aggregators uh these specialized aggregators will aggregate on their subnet and if for example uh proposes that attestation data is same across different attestations it wants to pack and which are which are across different subnets then it can do a global aggregation as well. So I mean right now we can keep the glo global aggregation role with the proposer and uh in the uh uh in the devet tree basically we can

say that okay uh we can have recursive aggregation if the feature is available at that point and if not basically then it gets put pushed out to the next. >> Mhm. Yeah. And another question like what's the expected number of validators DE3 should handle because uh this also kind of uh defines like what should be the approach. I mean you one one way to try to go to 100 I guess now we can start looking at these numbers.

What is what is the what is the valid data set you think we should start up with? >> Yeah. Uh for that we we're really working hard trying yeah I'm trying to prepare this dev net 2 networking analysis to kind of make it clear uh how much we can scale. One thing we should keep in mind is that uh aggregation size is 800 kilobytes right now and um yeah that's basically increases the block size a lot. So the propagation can be really slow uh if we just yeah I I know that this is just temporary and yeah we are working on plent of optimization it's just the state >> I'm not sure to to understand where this

number of 800 kilobytes comes from because on the net two branch unless I'm mistaken the proof size is approximately something like 400 kilobytes or something like this. >> Okay. Yeah, maybe it's something on our side in clean because yeah, I just wrote a test and uh printed the size of the aggregation it was 800 kilobytes but maybe it's less uh um I'm just saying that as now we intro when we introduced the aggregation yeah the the block size has this aggregation and we cannot simply uh propagate to large number of participants the huge block um One way

to solve this if the block size is the problem and how much is the problem. Yeah, I will try to answer in the networking analysis is to work on uh things like rea coding broadcast on which Raul's team is also actively working on. Uh but yeah um then but then there will be a question like if we decide that yeah uh we need to optimize block propagation with regoding broadcast for example then um yeah when to introduce this or we might also need this not only for block propagation but also for aggregation propagation itself once we split uh the aggregator role and

proposer role uh because like the aggregator prepares the aggregation and it needs to be propagated also as soon as possible. Um anyway >> I think I think you would definitely be seeing 8 kilobytes block sizes because right now there could be either more than one station aggregated and and we al also have proposal signature which is separate. So I mean uh so it is I think uh very viable to see 8k kind of sizes just for signatures part of it even though one aggregated signature could be 4 kilobyte.

>> Mhm. Yeah. Um I mean Raul's team is testing for 2 megabytes blocks. Uh I mean they're testing the effect of coding broadcast uh on 2 megaby blocks I believe. I should double check on this. Um in our case we have smaller blocks and even smaller aggregations. Um >> so even though we are doing this analysis but I don't see a current issue in our current devet setup because uh what we are doing is it's all in a single data center and there is no speed or bandwidth coder between the machines.

So as such I in terms of our uh dev net uh expectation I think it won't really matter much but yes uh this is something that uh is definitely we need to figure out. >> Yeah. Yeah. We try not to ignore these things. I mean the real world bandwidth between nodes and latencies and even packet losses which is why yeah something like shadow is becoming really useful for that. So yeah, we when we do test we actually using real world bandwidth and latencies.

Um I mean ju just so that we're not suddenly realize that yeah this is the problem. So yeah we're trying to signal this as soon as possible. Um yeah just trying to kind of understand the picture whether we want to first do optimizations or introduce as much features as possible. uh because one approach could be just optimize uh just a single subnet as much as possible. Another approach could be introduce uh multiple sub I mean recursive aggregation things like this.

Um yeah just thinking out loud. Sorry. >> Right. Right. And for definitely camel. So there is uh an item for you. Then uh as we already discussed that you will basically propose a spec for uh subnet uh uh creation uh and uh uh subnet aggregation and then uh global aggregation by the validator by the proposer. So I think if we can start seeing some work on it then it would be it would be good even before basically you know we we start seeing DevNet 2 in action uh so that you know we can have a jump start

on uh what kind of issues that will come up and what what is so we have our thinking aligned uh on all the things that you mentioned >> okay and maybe also question slash kind of asking for opinion uh what is the expected number of aggregators uh once we kind of split the role of aggregator and uh proposer um I mean uh Justin was talking about like kind of having 10% of the nodes from the subnet to be to be having like an aggregator role uh is it still the case or we can just get started with something really small I mean as as small as just the single

aggregator or something like three aggregators maybe something similar to what we have in BLS aggregation. Um any thoughts on that? >> So again I think if it if we are trying to do it uh committee sizes then I mean maybe 128 uh committee size would be enough right? So we use the same thing but if we just have 100 validators then we can uh reduce the committee size as well right? So >> okay >> so in the end I think this size would basically mostly be dependent on uh how fast things can be aggregated and so how many aggregations can happen in a single interval and uh that could

basically dependent upon the efficiency of lean VM uh but if it's sufficiently efficient then I think having the committee size at 128 is should be fine Um, just to add to that, would would it matter as well the number of validators we have in the system? Because otherwise, like if you're only testing with like like 64 validators and we have like committee size of 128, then it's >> Yeah. Yeah. So, if we have 100 validators, then we'll need to lower the committee size. I think we can do it via config. Uh so we we will have this as a config variable that can be

provided uh in the validator config and the clients can do it. So but but yes that makes sense. Uh so if if the total number of validators are low then we can lower this committee size. to summarize a bit things um personally um from a research point of view I think that what is important in the next uh dev nets or like the next weeks or months is like um signature aggregation and it's recursive way because this is what we want to test with all of these dev nets the postquantum aspect of things. So [clears throat] as soon as

things are ready on the lin VM, we should try to integrate as soon as possible in the spec and so as soon as possible in the devet so that we are testing exactly what we want uh and we are integrating the postquantum features as soon as Then for me there is a second aspect that you discuss guys under the hood with all of the back and forth that we just had. It's a peer-to-peer layer because like the the postquantum objects are bigger and larger than BLS objects.

And so of course we will have like adjustment to make about the the postqu the peer-to-peer layer with like subnets committees and all of these a number of validators also probably like new peer-to-peer algorithm. I think that Camil you are an expert on this rul also in at the EF internally is working with his team on new peer-to-peer system. So I think that we can do [clears throat and cough] these two things in parallel. We don't need to do this right. We can right now we can do this as I think in channels in discussion and stuff. But I think that doing benchmarks and um doing

different experiment, trying different committee size, trying different number of validators, different number of aggregators could be something nice to have numbers uh even preliminary numbers. Uh my goal also by doing like self-contained spec uh with a peer-to-peer layer is that we can experiment with this. We can test new gossip sub algorithm. We can test other stuff than gossip sub. can test some new stuffs and so yeah I imagine that at least for beginning of 2026 then we have also like the fast finality track but this is another thing we we

don't need to discuss that right now and this is not a topic for the upcoming devet but for the beginning of the year I think that having these two tracks of postquantum and peer-to-peer could be like a a good stuff to manage and then of course we can check the the details I think in the different channels that we have but I think that this two stuff makes a lot of sense and we want always to prioritize the postquantum aspect so as soon as we have new stuff only in VM we should integrate them as soon as possible in the devness Yeah, cool. Um, yeah, let me also think

more about this and u yeah maybe propose how we can do um yeah the topology for the aggregation once we split well introduce a new role as aggregator. Yeah, I kind of see it's like the nodes they can signal they they are aggregators in kind of in ENR uh address. I mean have a record that I am an aggregator and yeah we can control it this way. Um yeah, thank you. A lot of thoughts.

>> I I I think that you your beam sim uh simulator tool could be quite useful in this context because here we just mentioned how many validators, how many aggregators we should have but I think that your beam sim simulator covers all of this because we can uh conduct experiment with different number of validators, different number of aggregators, different topologies and stuff. So we can still experimenting with this outside of the dev net I think.

>> Mhm. Mhm. Yeah. Um yeah it should be useful. I mean it's uh it's pretty um yeah it was developed long time before the dev nets. So some assumptions could be different but yeah we're kind of keeping up with this tool introducing new stuff like soon for example that yeah um lean P2P that was presented by Thomas in Cambridge. Um, yeah. Yeah, we need to rename.

Okay, thanks. >> Awesome. Great discussion. Uh, we got 10 minutes left. Any other items that people would like to table? >> Gotcha. >> Uh yeah, quick update on the s uh sync metrics. Um so I removed them from the current PR and wrapped into the issue.

Um so currently I would like to have a current slot metric. Uh you can leave your comments in the PR. This metric is in the one of the PRs I shared uh today. And um so we currently we can um identify the scene just by um checking the difference between current slot and head slot. uh it's like um just for for for for the beginning and uh whenever the clients will implement uh their syncing parts uh we can um improve sync metrics because the implementations are

may may be very different. Um why I want a current slot metric uh because just to be sure that um all the clients are on the same page. So technically I can just grab it from graphana and calculate but um it's better to have from the clients I guess. So thank you. Uh yeah and I also added um I know what we discussed uh the target uh safe target metric. Uh please take a look into it and uh give your comments as well. So this will help us

to to follow the target and to quickly investigate uh penalization failures. Okay, thanks Kasha. Um last thing I want to do is shill my shill an event. So yeah, this whole effort that we're all a part of, the PQ interop, this was kind of born out of some conversations at uh Beam Day last year, which was a a side event the day before ECC started in CAN and we're doing it again. Um so yeah, sign up if

you're interested in attending. I think it was a really successful event last year. Uh it's going to be a small intimate setting, 80 80 people. uh there will be panel discussions and presentations and uh hopefully like the next wave of uh work that's being worked on by this group and others will be discussed there or you know born at this event. So, I'll probably I'll probably show this the next couple weeks, but I'm I'm just looking forward to some warm weather right now.

All right. Um, great call, Mus. I'm not sure clean would be okay with separating out the lean sim just for devs devet sakes. I'm interested in contributing to both that and the network research. >> Anything you want to add there, Miles? >> Oh, yeah. I'm just um curious if uh clean would be okay pulling out the uh lean sim into a separate repository.

Uh yeah, I I would be interested in working on the networking research. I I've done some simulation on my part as well. So, uh it would be nice. >> Yeah, let me find and share it with you. so, you can check it out. But overall, in general, yeah, it's a C++ simulator using three library. Um yeah, so it might be a bit hard to read the code, but anyway, if you're curious, yeah, we can discuss. True. True. Okay. All right.

>> Yeah. Thanks. Okay, I think that might be the call. Thanks all. That felt really productive. Good to be back. Um, see you again next Wednesday.

>> Have a good one, guys. >> Thanks. >> Thank you. Bye. >> Have a good one. Bye. Bye.