Post-Quantum Interop Call #30

Transcript

Will Corcoran: Alright, good morning, all. Welcome to… this is PQ interrupt call number 30. Let's jump in with some client updates. Loom team.

Gajinder Singh: Hello, everyone. Hi, Bill. Yeah, so we have been working on stabilizing our client. We have… we identified a few issues with the way we were importing things in fork choice and processing. New and known payloads, so that is something that we fixed. And, we have also identif… we also identified a small issue in the spec, for finalization, in straight transition function, where basically, whenever new finalized slot was, discovered, it was… It was not then iteratively used, in the next, for deciding for the next finalizations in the same block. So the issue was that if you basically split up the votes among two blocks, it would… It would result in a different… Finalization, and and basically we wanted a behavior in which,

things would be more stable and consistent across blocks. So, we did a… we did an upstream PR for it, and if other clients have Seen it, please do implement it. Because otherwise it will result into consensus issues. Apart from that, we worked on, DevNet 3, runs, and, whatever issues Katya and Path had discovered, basically, they, They notified it to the teams. And, we have also improved… we have also improved Lean Quick Start. incorporated changes in the inquisitive for DevNet 3. On spec work, we have worked on DevNet 4, the PR is… Unsurance PR is out, and, so please give a review, I'm also reviewing it, as well as we put a DevNet 5 PR, which, we propose that we basically merge into DevNet 4 itself, so that, so the DevNet 5 PR was…

For separating out, the proposer and the tester key, which we will… we are proposing that we just do it as DevNet. Portage settles. Because otherwise, DevNet forwards changes are not so many. Yep, so we have been doing debuggings and figuring out stability issues and working a bit on spec work as well, so yeah.

Will Corcoran: Excellent. I'm gonna share my screen. Feel free to call anything out here. I've been screwing around with Claude Code myself, old dog, learning new tricks, trying to write some cron jobs to, like, highlight all the work that you all are doing, so this runs a weekly summary and just pulls in, like, all the PRs that have been merged, opened, most discussed. So I can leave this open, and I'd like to… maybe… Refine this as we go, but feel free to highlight any PRs that you want to talk about, and I can drop them into the chat. Loom team.

Shariq Naiyer: Sweet, sweet. Yeah, that looks pretty… that looks pretty good. On the REAM side, we… we have been aggressively debugging, what's happening in our DevNets. And, some of the issues we found, around consensus, as, as Gajinder pointed out, we initially matched the spec, but then, as Gajinder pointed out, that we would like to go for, the behavior that we had previously, we reverted that change. We were testing out check… we were having some issues with checkpoint sync, and, we found that the issue who was, initialize… we weren't initializing the Folk Choice store, or… if… we weren't initializing the FolkChoice store properly with some… with some configs that needed to be changed. So… so that has been… that has been updated, and as we can see in today's DevNet, I'm finding the clients to be fairly stable.

we're at, like, a thousand slots right now, 1,000 finalized slots, and, I'm expect… and if all clients have merged the, the… the spec change, like, 443, then, then I think… I think we'll have a pretty good DevNet today. As for… Apart from that, we added DevNet3 metrics, and we added additional testing. We added a CI that now runs for 3 hours, but it tests our client in relation to all other clients, I think… I think it's pretty beneficial to have that for now. Eventually we'll move that to, like, a nightly CI. As for… as for DevNet 4, we're reviewing the DevNet 4, spec PR. But… but yeah, beyond that, I don't think we've had much happen in DevNet 4 this week.

As for the spec side of things, we've pushed a PR for, we pushed a couple of PRs, O push to PR for changing the signature to, signature serialization to fixed bytes, from the, from the lean spec client, and I think in the lean spec as well, because all other clients were implementing fixed bytes, which was different from the spec, and we pushed to PR to, for the API spec test to test the folk choice endpoint as well. And… and yeah, yeah, that's all from our end.

Will Corcoran: Sure. Grandine team. I think your audio cut out, Russell.

Ruslan Tushov: Hello.

Will Corcoran: Perfect.

Ruslan Tushov: Can you hear me now?

Will Corcoran: Yep.

Ruslan Tushov: Okay, so, today… Someone… wrote in the chat about, fork choice P endpoint. We added, pull requests. Currently, it's under review. Also, we merged some remaining DevNet30 requests that were not merged into master. Also cut, helped us to find some crash, in our computerMD ghost head function. We'll check it later, and somehow, when we restart the docker, port becomes busy. It's, uses network host, from Linkwick Start. And we use Bustache for networking. didn't… Also, didn't find a solution yet.

Oh… Also, we are doing some… We're looking up into automating some interop tests, simple interop tests, which, for example, check that chain growth and finalizes and checks other metrics. Also, not restarts and syncing. But we're still cleaning it up, so not published yet. Thank you, that's all.

Will Corcoran: Great, thanks, Austin. And the… Chat Russellin was referring to is in the tooling channel of the main telegram group. If you're interested. mihir is… was not able to make it, I will post a message that he wrote, and I… Chat to… So… If you're interested in reviewing that, that PR… There you go. Grandine.

Shaaibu Suleiman: Yes, hello. Yeah, so for, what we've been able to do, we've implemented, persistent storage. We've chose to move forward with, BoltDB, and we've, implemented, that for persistent storage. And we have also actively started on, working on DevNet3, basically. We've, separated, both, signature aggregation from block production, basically, by introducing the aggregator rule, and of course, added, or introduced two more topics. For, propagation of both signed attestation and signed aggregated attestation, which are the requirements. For DEFNET3, alongside, you know, other requirements that we are actively working on. Right now. We have, a draft PR that is currently actively under review.

For DevNet 3, to see how we can facilitate, things and complete, DevNet 3. But, all things being equal, by the end of this week, we should, raise a PR on Lean Quick Start to participate, in… the multi-client, interop, and all that. So basically, that's that, that's that from us, Ajin. Thank you.

Will Corcoran: Amazing, thank you. EthLambda.

Pablo Deymo: Hello! We were working on the memory issues we had. We implemented a circular offer. to put a limit to the memory consumption. We also merged the beer with the pruning. We… We've implemented a new version of our… a framework. a concurrency for the actor model. We call it Spawn. It's a library of Lambda class, and so we moved to this new version, which is more ergonomic, written in Rust. We also put this, the usage of this framework in P2P module of EthLambda. We made some networking improvements to improve the resilience of the node. For example, excluding, failed peers, from block fetch.

from roughly retry. And we made some small changes we were doing in the spec to align to the Boolean spec, changing the naming of epoch to slow, and signing the station message to data. And, the last but not least, we implemented the pending lead metrics we have. Especially the Aggregator, we had, Depending there. So… That's it. Thank you.

Will Corcoran: Thank you. Any other client updates? All right. Moving on to specs, research.

Thomas Coratger: Hmm, yeah, This week, we haven't worked that much, on spec in order to let client teams, debug and adapt with DevNet 3. The good news on the spec is that, thanks to recent PR, it seems that we have interrupt between the lean spec in Python and other clients, at least Zim, for the other ones, I am not sure, so that is pretty good. We also added, with the PR of PARTA, yesterday, the metrics. in LeanSpec, in order to be able to integrate with Prometheus and LeanQuick Start stuff. Like, your other clients. On the research side, we worked a lot with, blonQ3 and LinVM, Emily can detail further the LinVM work, but basically, we worked this week to improve a lot the performance of Poseidon 1.

both in plain text and in the proving context. That is, we have… we are… we have two targets of optimization. One is just hashing inputs using Poseidon 1, and the other one is proving hashes of Poseidon 1. So, we worked on both of these targets with various fields combinations, so baby bear, koala bear. Goldilocks and Merced 31, so we worked to improve the benchmark. to see how fast we can get, when compared to Poseidon 1, Poseidon 2, in order to have real comparison, and it appears that approximately, for the plain text comparison. We are only 1.8 slower than Poseidon 2, which is a pretty good news, because we thought it would be much worse. So yeah, this is pretty good news, and we worked a lot on this. If you are interested by all of this work, you can check all of the PR that we made on Prong History recently.

Yesterday, also, we released, Plonkies 3. 0.5, so that is a new release, with all of this changed inside. So, yeah, that is basically all on the research side. Emil, feel free to add anything about LeanVM that you want to add.

T. Wambsgans: I will… thank you. I will just add about DevNet4 that There is now a peer in LINSIG to include the new ZK-friendly encodings, and should be made very soon. I think Benedict Mainly, like, wrote some minor comments, but it should be good. And then, once this is merged, maybe today or in some days, like tomorrow, you know, we'll try to do the corresponding DevNet4 branch on Lin Multisig to have a recursive aggregation. with the official LINSIG repo. for DevNet 4. So, don't know if it's going to be ready in the next week, but, There is some progress, at least.

Will Corcoran: Awesome, thank you guys. Any other spec research-related updates? Or discussion topics, anyone would like to table.

Thomas Coratger: Just if you are interested, I think that, next week, this is the 20, I think. We have heatproof call number 8. focused on… on Poseidon. So, Justin organized this, but if you are interested, you can, you can just check it, and we'll have a bunch of discussions and presentations about all of the recent updates about Poseidon.

Gajinder Singh: So I have one discussion topic to bring up, which is basically, what is the P2P topography that we need Because now we will, soon be experimenting with greater than one subnet. And then… Basically, this question will come up, that what is our best topography. For connections for the mesh. That is good for us. Other thing that we also need to figure out is All the validators in the… In the… in particular subnet, they should be… they should be ignoring the gossip attestration messages that come to them, or they should just be not subscribing and flood publishing. So, what is the best P2P, strategy for… Spreading out, the signed attestration messages, so that… The aggregator can…

basically get most of them in a very short amount of hops. So this is something… I think we need to think even for… DevNet3, and apart from that, we also need to… See that whether the spec is, Compatible to having greater than one subnet, as well as basically, you know, how we configure it in Lean Quick Start. and how we distribute the validators among the nodes. So this is something I think, will be some… that some… will be a concern that I'll be looking into this week, but it is also… Good that other people can weigh in what they think about this.

Will Corcoran: Hi, Camille.

Kamil Salakhiev: Yeah, just my thoughts on that. Yeah, it's, I'm a bit… I would say, like, it's… it's not that simple. I mean, yeah, we have, like, grid, oh, sorry, not the grid, like, we use Gossip Self today. For stations propagation, yeah, some alternatives could be, like, grid or, you know, other kind of structured topology. I'm a bit, Yeah, I'm not kind of ready to say that, yeah, grid is kind of the best choice right now, because the… well, it's good for propagations, I mean, we did all the research, and yeah, for example, in Beam Simulator, but it has… Some privacy concerns, like we need to expose validators. basically, to be able to match validators' signing keys with their P2P keys and P2P addresses, which we want to avoid, because, yeah, we have certain privacy assumptions in existing Ethereum networks today, which we would like to keep.

So it's not as simple. I would say that also. Maybe the best… well, maybe, The… the… my… maybe the thing that… Yeah, from my perspective, I would rather focus not on attestation propagation optimization today, but rather on, things like… First… Well, blocks propagation and proofs propagation, because, like, we have Once we have… because that's a lot of data, like, each block, when we have a proof. it's at the very least 128 kilobytes. Each proof is 128 kilobytes, and if you have multiple aggregators, so each aggregator creates 128 kilobytes message. Which could be a lot in a large network. There are… there are some ongoing work in ETP2P with, Azure-coded broadcast, yeah, I think…

Yeah, you can check Raul's recent tweets about that. The result looks good, so I would maybe… From my perspective, at least, I would first try to… somehow introduce this thing, I mean, first blocks propagation, maybe first, and then… Move propagation, or do this at the same time, using some recording strategies. That would be a good playground to kind of check the research that, yeah, the Networking team did, so just check it in practice.

Thomas Coratger: Do you think this is relevant to… and do you think we can do that soon, to integrate all of the effort of Raul and his team inside the LeanSpec and Lean DevNet, as I say? Everything related to broadcast, ESP2P, all of this?

Kamil Salakhiev: Wow, the soon… define soon. Yeah, Yeah, it would take some time, maybe… I don't know. I need to maybe hands-on on that a bit, to investigate a bit deeper how the propagation strategies were implemented in the benchmarks. That's Sukun from, yeah, networking team did. So, and then, yeah, we might think to introduce this… yeah, I'm trying to think, maybe, yeah, you can help me, guys, like, what should… where should we start, like, if we want to go with recorded broadcast, like, maybe start with proof propagation or blocks propagation improvements, So, I just want… I just want to add, you know, while we are…

Gajinder Singh: about blocks propagation, propagation. Currently, the topology is a star topology, everyone is connected to everyone. So, I mean, even before we start talking about and start researching about blocks propagation or proof propagation, we need to, for example. target some topology that… that we think is something that is good. And we can do that without introducing the discovery, because in Dean Quick Start, we know what all nodes are, and we can basically supply… we can create the topology by supplying them The, those particular boot nodes, so we can, on the script level itself. create the topology. So, question is, what is the topology that we are going for? And then we can basically talk about block propagation optimizations, and…

proof propagation optimizations, because right now at STAR, there is… everything is within single hop, so there is no…

Kamil Salakhiev: No. Yeah, just a correction, I… I don't think it's a start apology. Yes, you might have, like, maybe your clients, they connect to all the peers, they maintain connections to all the peers from the node's YAML. However, Gossip Sub has… Mesh size… I don't remember, 8, I believe. So, even though we maintain connections, even if your peer… even if your client connect… connects to all of the peers, which, by the way, in Clean, we did it in a way that at least we had a configuration so that we can connect only to a subset of peers, like, maybe 20 peers. Otherwise. shadow would just crash with too many connections and messages. So basically, even if your client connects to all the peers in the notes YAML, in your mesh, you only maintain… well, basically, you propagate messages only to 8 peers.

Which is your merch site, so it's not really a start apology, it's more like a gossip. Even today, so we don't have one hope. We have multiple hopes.

Gajinder Singh: Yeah, I mean, to go over that, we basically first need to increase our nodes. I mean, we are not there. So, one thing is to basically push our nodes number high, and then… Again, come back to what you're saying.

Kamil Salakhiev: Sorry, do what? With the notes.

Gajinder Singh: We need to push the nodes that are… that we spin up in our network, and then only we can measure What is the propagation time for block and proofs and… Do optimizations on top of that, on the lines that you are saying.

Kamil Salakhiev: Yeah, we did that with, clean, basically. We ran analysis under shadow, to check, like, the blocks propagation, blocks propagation, and the sessions propagation, and… Yeah, we need to rerun it, maybe, when… yeah, the issue was that when we had… because we were testing, I believe, with DevNet… I need to double-check… DevNet 2 or DevNet 3. Basically, the issue was that a single block could have multiple Proofs included in it, so the block size… have, like, could be, like, maybe, I don't know, up to 1MB, which is really a lot. So… if we're still doing that, maybe that's one thing that we should optimize, like, make sure that our block can only have single, snark in it, otherwise, yeah, it's…

Gajinder Singh: It is not possible to have a single snack in the block for the reason that, I mean, you will pack For example, signatures, which have different registration data, right? So…

Kamil Salakhiev: I don't think it is possible to have a single proof in the block, but…

Gajinder Singh: What we can do is maybe target… for, For the aggregator, right? So… so that that particular thing can get delivered in a single packet.

Kamil Salakhiev: You mean aggregate? Well, how is it? Well, so you're saying that, yeah, we're not worried that our block size could Could be, like, I don't know, megabyte.

Gajinder Singh: I'm saying that.

Kamil Salakhiev: Because for me, this is a bit of a concern.

Gajinder Singh: never come below to the point where you have a single data packet, right? You can put it in a single data packet and optimize it. It will definitely get broken into multiple packets, because there will be multiple proofs, at least we might support, like. four different… Attestation, data, in… in our attestations, right? So we might support… support that. But… Again, and then we'll have a different proof for the block signature. itself, right? So… so we… we might not be able to… limit the block size to a point where basically we can transmit in a single packet, unless the proof size is, like, very small. But it is possible that with the aggregators, we might be able to do that, because they only need to transmit

a single proof, and along with that, estration data. So there… there we definitely have the space for optimization, where we can compress the proof. To a size where it gets transmitted in a single bucket.

Kamil Salakhiev: Hmm… Okay, a question, like, do we have, like, upper limit for a number of proofs that could be included in a single block. Basically, the question is, do we have an upper limit for a block size today? Or it could be… Infant, due to the number of Proofs, could be unlimited.

Gajinder Singh: So, yeah, I mean… We will have… we will have… we will definitely need to have, for example, a size Of four different attestation data that can be packed, and different registration data directly maps to different proofs. in the signatures, in that signatures, right? So, because we are not aggregating across different messages. So… so that is… that… that directly maps over there, unless we come to a point where we are aggregating across different messages, but… Then we can also independently verify the signature across… Signature. against these particular, you know, independent messages, so… Maybe we can also think about that, if that can be done, if, Because we… because Emil did provide us an API to… Aggregate, against two different messages, and…

We have not really thought… thought it through in the sense that We came up with a different solution for the proposer signature and attestration signature, but aggregating across different messages for attestations, right? So that is something that… One can think and see that, if that can work, then basically It is possible to have just one Proof signature in the… in the block.

Anshal Shukla: Virginia, even without that, for a particular attestation data, if I am a validator and I'm not an aggregator, and I receive multiple aggregates which… which basically cover a different set of validators, so for a single attestation data as well, I'll have to include, like, multiple, proofs.

Gajinder Singh: So basically, we are in… in… In a configuration where the proposal will always aggregate.

Anshal Shukla: If we get into that configuration, then yeah, we won't need it. Then… and along with that, if we have, like, multiple message aggregation, then we'll be able to basically aggregate over multiple attestations and produce a single proof, but in the current configuration. We'll have multiple proofs, even for a single attestation data, even after recursive aggregation.

Kamil Salakhiev: Is it even possible, from LinVM perspective to kind of… I don't know, have multiple aggregations for… I mean, different aggregations created on top of different messages, and then kind of merge them into a single.

T. Wambsgans: Yes. symbol, I believe. I believe… Everything is possible, you see there. If you can phrase it, we can prove it, yes.

Gajinder Singh: I mean, it's not difficult. Basically, the verification against the independent messages. If that is possible, then this approach can be taken.

Kamil Salakhiev: Hmm, cool. Yeah, maybe that's something that we can introduce in some upcoming DevNet. I mean, aggregating from multiple Well, multiple messages-based aggregations.

T. Wambsgans: Yeah.

Gajinder Singh: Yes, sir.

Kamil Salakhiev: Yeah, Yamil, please go ahead.

T. Wambsgans: No, I mean, I believe it's very… easy compared to everything else to add… if it's… if I understand correctly, we only need the possibility to have different messages, is that correct?

Gajinder Singh: So when we say that we need possibility to aggregate different messages, what it really means is that if I have the proof. And I used, for example, poor messages to aggregate. So if I have the proof, I can directly validate against Message 1 without requiring message 2, message 3, message 4, because… Yes. Then I can say that over. If we can do that, then definitely we can use this, because then it is like just having an independent signature for this particular message, and… Oh, yeah.

T. Wambsgans: I believe we can do… we can do that, yes. Basically, what is… we can have an, I think, an kind of an arbitrary number of messages, with… and potentially, In the beginning, there is only one message, and then you can add the other messages on top of this, and yes.

Gajinder Singh: So, if we can basically use the same… Signature to validate different messages, then definitely it's possible that,

T. Wambsgans: Sorry, sorry, you mean, sorry, you mean… Different… sorry, one signature, for different messages, That's okay, I didn't understand.

Gajinder Singh: we aggregate… so we aggregate proofs across different messages to get one final aggregated proof, right? So, this proof is now… we can independently validate against message 1 without needing message 2, message 3, message 4, let's say, and then can independently validate against message 2. So if we can do that, then basically it's like. This is the final proof that you can just reuse for message 1 and similarly, message 2. And so it acts like a normal, proof.

T. Wambsgans: Okay, so you want to, you want to weigh… So basically, you want a single SNARC proof that contains allegations across multiple messages, but you want to be able to verify it for message 1 if you don't know message 2, is that correct?

Gajinder Singh: Yes, I mean, somehow it can still be done, because I can… I can create a specialized proof for message 1 by saying that, okay, message 2, message C, message 4 hash was this, and I can just put it… push it in the specialized message, one proof, right? So I can… so I can create… if I can create such a specialized message one proof very easily from the aggregated message, then… I can basically see it as an independent… Message 1 signature, that can just… That can be validated to say that, okay, you know, these validators voted for this particular message one. And then I can basically use it, use it as… As I can then… the other block proposals can basically aggregate it further, right? So, there can be recursive aggregation on top of it.

And can be packed into a block. I just need to make sure that I can independently verify them, which I think… It is possible if… I just… even, you know, back the message 2, message 3, message 4 hash, along with the proof itself, so that I can say that, okay, this message once proof is… This aggregated proof plus Concatination of the hashes of the other messages.

T. Wambsgans: I'm not sure to follow entirely, but maybe we can continue this chat After the call, but intuitively, if you can write it… yeah, if you can express it. We should be able to make it work, in some sense.

Gajinder Singh: Yeah, I think we'll be able to make it work. Yeah, we'll continue after.

Anshal Shukla: But, do we even need to independently verify it with each of the messages? Because in the block, we'll have all the, all the attestation messages and a single proof, so we should be able to, we'll have, like, all the four messages, and we'll just need to… Verify that the aggregate is basically An aggregate of all the… these four messages itself. So, along with attestation data, we'll be storing, like, the participation bits to which each attestation was signed, and Basically, with that, we can reconstruct the whole thing.

Gajinder Singh: I mean, it's always better if you can recursively pack the proof with other proofs that might come up, right? So… But yes, let's…

Anshal Shukla: sort of inspect and see whether we actually need it? Yeah, yeah, I mean, like, we'll be recursively constructing a single proof, but we'll still have, like, the attestation data for… all these different messages. So, suppose we have 4 different attestation data. So, for each attestation data, I believe we'll be storing the participation bits who have… basically the validators who have signed to that particular attestation data. And that… all of that will be packed in a block, along with the single proof. So… Right, that's fine.

Gajinder Singh: when I am just talking about one particular registration data, let's say that it's message 1, I want to forget about message 2, message 3, and message 4, right? So… I don't want to carry them together, or if I can basically carry them again, together with the… proof itself, that basically makes it possible for me to say that, okay, you know, I have an independent proof To validate for message 1.

Anshal Shukla: Hmm. Got it. Okay.

Gajinder Singh: Basically, it makes the thought process easier of how we can process and aggregate, further aggregate these messages. But I think it should be possible.

Anshal Shukla: Yeah.

Kamil Salakhiev: Huh.

T. Wambsgans: Yeah.

Kamil Salakhiev: Oh, sorry, yeah.

T. Wambsgans: Josephine… Not entirely sure to understand, but from what I understand, yeah, I also agree that it should be possible, yes. Please come in.

Kamil Salakhiev: Yeah, my… just another concern is that, Yeah, it still would be great to have some kind of limit, maybe, of number of proofs that we might… that we need to aggregate in such a way, because I believe we still have a target aggregation rate for proofs is, like, maybe 10 SNARCs per second, maybe Emil can correct me, and maybe there are improvements for that estimate already. But yeah, if we're talking… it's kind of a significant time. from the… Yeah, consensus, critical path perspective, that, yeah, we need to optimize.

Gajinder Singh: So, I think it will automatically be limited by the fact that when, you know, When… when the network sees new block, and most of the network confirms it, basically, it will result into a new attestation data as a head vote, right? So… In that sense, obviously, I think automatically it will come to a point where, you know, you won't keep on regulatively aggregating the same Same proof, right? So…

Kamil Salakhiev: Hmm… So it's not, like, only block proposals' responsibility to aggregate all these proofs for different messages, but it will be done recursively? Is that what you're saying?

Gajinder Singh: No, proposer… so, a test… anyone can do it, right? Aggregators generally will aggregate only fresh proofs, so it's a proposal responsibility to recursively aggregate I mean, aggregators can also do it, nothing is stopping the aggregators to not… Recursively aggregate and, make a better… And produce a better aggregate, right? So, if that particular registration data is still in play, But… the way I see it, most of the aggregators will consume new proofs, and the proposer will recursively aggregate them in a consensus where, you know, we see that the head is flowing, and the finalization is flowing, and all that, right? So, whenever there is new attestation data, new New proofs are gonna come, which means that there is a new head that the network recognizes.

So if most of the network sees some… sees a block, definitely… New proofs will automatically come into the picture.

Kamil Salakhiev: Yeah, it would be great to have it written down somewhere, yeah, I need to… Think of, like… Yeah, maybe there are some attacks possible. Anyway, anyway. Yeah, I mean, if you think this might work, that would be great if we could use this approach to just have a single Eventually, maybe a single just… just a single proof in a block. That's the first way we can optimize. I mean, this is kind of low-hang fruit. We can basically do that to reduce block size. And then, in parallel, yeah, we might start working, I mean, yeah, maybe I should draft some… maybe have some kind of… write up about how we can introduce Reasure Code broadcast, just kind of investigate what's been going on,

from the P2P team, research, and yeah, how… what's the best way to put it into… Into the leans perk in some way. Yeah, let me think about this. Yeah, I'll try to share something.

Will Corcoran: Excellent. Any other spec or research-related discussion items? Metrics and observability. Anything that you would like to… Able for this week.

Katya Riazantseva: Yeah, hello everyone. So, currently I'm running DevNet3 on all the 9, servers, so, Currently, we lost Zim, but it's because of the old image. I don't have an updated image yet. As soon as I have it, I will replace Loom with a new one. And I had to stop Grandin. I think no one on the call from Grandin's team, but they have memory leaks, so I will notify them in the chat. For all the teams, currently, what I need, is API and metrics flags updates, so please, in the tooling, response to my message, what, what flags, clients have, because we are refactoring Lean Quick Start, so we need this, link point and for metrics. That's it, thank you.

Will Corcoran: Excellent. Any other… Discussion topics. Great. Well, that felt like a really productive call, as usual. I will see you again in a week.

Shariq Naiyer: Have it going, guys.

Katya Riazantseva: Right?

Anshal Shukla: Hi, everyone.

Pablo Deymo: I wrote.

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