P2P Networking Call #2

Transcript

Kamil Salakhiev: Hey, Ron.

Mega | ethrex: Hello.

Daniel Knopik: Hello!

Kamil Salakhiev: Yeah, hey Daniel. Alright, maybe let's give another minute, and we can get started. Yeah, okay, yeah, let's get started. I think today, yeah, would be great, yeah, first touch on, via client updates, Then, yeah, we discussed on, sparse pool progress, and also kind of readiness.

For the upcoming, blob DevNets. And, Yeah, and if there are… If there is time, yeah, we can. I can just quickly do a heads up on, like, discuss the recent progress on Pq, interop, and, like, yeah, some shadow simulations there. Yeah, I don't think, like, we have many clients implement first today. Yeah, maybe, Daniel, you want to share any news from your side?

Daniel Knopik: Not much with regards to… partial messages for Gloas. But, we are… getting closer to the new Lighthouse release, which will support partial messages for Fulu. As well as some other things, Then, for sparse blob pool, so get blob V4, there's also not been… not a lot of progress, unfortunately, due to the lack of time, and… Yeah, important fixes. Finally… There is… the fact that we are going to, disable MPLEX by default in the next Lighthouse release. Yeah, Joao, do you want to say some… add something to that?

jxs: Hello? Nothing much to add. We spoke about at least. About this lots of times before. Yeah, we are deprecating it by default. Users who want to Enabled it, can still do it.

Kamil Salakhiev: Okay, good, thanks. Yeah, I don't see… don't think we have anyone from Prysm. Any other seals? Yeah, I see Anton, Anton, Maybe you have, I don't know, any updates on this? Yeah, hey.

Anton Nashatyrev: Yeah, hey, no, sorry, I have no updates on Facebook.

Kamil Salakhiev: Okay, okay. I heard, like, in Svalbard, we can discuss with your folks, like, there is some ongoing… progress regarding introducing Quick. Yeah, do you know any… anything on that? I mean, if Quick is supported, or not? I just remember the exact steps.

Anton Nashatyrev: I think it's a bit stale now. To be honest, I don't know the latest news, but I think it's not in progress.

Kamil Salakhiev: Okay, okay. Yeah, just maybe last question for you, sorry, not to mean to torture you with many things, but yeah, just glad to hear. Do you know, like, also, like, yeah, I know there is ongoing, active work on, cell-level deltas for… for Prysm and Lighthouse. Do you know, on the side, if anyone is working on that, or it's not a priority at the moment?

Anton Nashatyrev: No ideas.

Kamil Salakhiev: Okay, yeah. Okay. No worries. Good, right, yeah, I think if no one else from… Seal teams, yeah. Maybe, Chaba, do you want to give a quick update on Discovery P5 or other topics, or… on the guest side? Shall we feature?

Csaba Kiraly: So yeah, I was just trying to… Yeah, so this V5, now, all clients started to pass tests. They're not still passing water tests, but, we are lucky to have, at least every client can enable this V5 now. So, we're getting there. I still urge them to look into the failing tests. I will do the same at one point and distribute these out. That's going well. On our side… yeah, different ongoing works. One is the heat disposable pool, the other is, still, member-related, changes and, bill management. So, that's, that's still the branches, it's coming. I'm also surveying the network. Only Dispute 5 nodes are still there. Obviously, still quite a lot on the mainnet, so…

Let's see what the fuck is going to have done. That helps. I think that's all kind of in terms of many, many ongoing works in, expect to know. Changes.

Kamil Salakhiev: Okay, good. Yeah, thanks. Yeah, Yeah, since just we touched on Discovery 5v5, and yeah, we have… I invited Ithrex guys as well to join the image to discuss, some other stuff as well. Anyone from Ethrex, do you know, like, guys, is… anyone is working on Discovery V5 on your side, or…

Csaba Kiraly: Esx is the one passing both tests, so… Nice. Yeah, yeah, they're good on that. Plus, gas is passing on the test, and And the one is passing all tests. I have a few… extra tests in… And a blanch. I think it says… was… was failing one of those when I was checking, so… I will merge those point up to the beyond as well. Fix it. In general, we should increase also test coverage on this.

Kamil Salakhiev: Okay, good. Yeah, nice. Yeah, moving to the next thing, yeah, regarding the sparse blog post. Yeah, I believe, like, yeah, maybe both of you can also share more on that, but we have kind of, like, a GEF and Nethermind team actively implementing the EIP. Basically, the EAP state, well, it's ready, yeah, we, I think in May, immersed, some recent changes, from my side. Also, we finalized engine API changes, I can… Just share links to that if, or other teams, so, yeah. Sense. But yeah, I think EAP is pretty easy to find. It's AP870.

Yeah, I think, yeah, for us to kind of roll out that for the next Blob DevNet, we would need to… well, ideally to kind of have more clients to support that. In that regard, I'm kind of curious, on Ethrex guys' perspective, I mean, what are their priorities? do they have time to implement that, or they were already working on the Sparse Blow Pool integration? Yeah, maybe anyone from you guys?

Pablo Deymo: Yes, there is a… sub-team of integrates working on that. I don't know if Edgar is in here to explain the stages, but will you start implementing that?

Kamil Salakhiev: Okay, nice. Yeah, we will have, yeah, I asked to create a Sparse Boppoo channel in Eastern Discord. Yeah, so we can kind of coordinate there, kind of if there would be… I don't know, like, if you're ready, and yeah, we can kind of start some kurtosis tests and networks. Just ping us. One problem that I see at the moment is that we don't have CL that supports recent execution API changes. On that side, it would be great if, I don't know, Lighthouse, Prysm, or anyone else You kind of would also support that. Oh, great. Nice. Yeah, if you have a link, by the way, to your PR, yeah, I can check later, but yeah, we can also test that.

Yeah, we can… it would be great to kind of have CO, supporting that. For now, we just have, I don't know, our VIPE coded implementations of CO, just simply to test that it works. Yeah, nice. Thanks for sharing the PR link. Yeah… Other than that, we also need to… Hmm… introduce metrics, at least on CL side, it's easy. We just kind of have the same metrics that we have for the Get Blobs V3. Yeah, I created a… there is actually a repo. That it's covered with the Beacon metrics, and… I opened the PR for the… It's pretty straightforward, PR, just to have same… metrics that we have for GetBlobs v3, for Get Blops v4. Yeah, we can merge it really soon.

And, this would be notified. Utility, or of course, that the group changes.

Kasey Kirkham: Sorry, earlier you said that, you were looking for CL changes to help test, and I missed the beginning of the thread, so I think you're talking about for the sparse blob pool, you need to be notified. Yes.

Kamil Salakhiev: Yeah, hey, Casey. Yes, do you know, like, on Prysm's side, if there is a branch for that? Already.

Kasey Kirkham: Not that I'm aware of, but, that seems… is that basically the extent of it? Just notifying the EL, kind of whenever there's a custody group change?

Kamil Salakhiev: Yes, yes, basically, Fortress Update, a new version of that call, so that, yeah, we notify the custody set, and also Yeah, using Git Blobs v4 instead of GitBlox v3.

Kasey Kirkham: Okay. We might treat… we might do, like, two separate PRs for that, but yeah, that, I think, at least the four-choice updated, part seems small, and, Gitball's V4, I'd have to look at it, but probably also not a big deal.

Kamil Salakhiev: Okay. And I remember there was a hand raised, I think, Chabo, it was from you.

Csaba Kiraly: Yep, so to speak. Not the next phase, but, the phase after. Now we also have, direct support in root doses to limit bandwidths and not, delays. So…

Kamil Salakhiev: Sorry, support for what?

Csaba Kiraly: for limiting bandwidth on, in a Kurtosis testnet. So I, I had these, these scripts, external scripts, but Tally was not, now quoting it inside. decide, glutosis, so now we have… I don't remember what's the name of the tool, but anyway, Given this is bandwidth sensitive, we should, At one point, start testing this under damage constraints. Every lead is the first step, but It's, that's one of the things to do.

Kamil Salakhiev: Okay. Yeah, I'm just thinking of, like, yeah, how we can use it. I was thinking about, like, kind of limitations that we would have, If we run Kurtosis… I just… like, when we need to kind of run this tool, I mean, Kurtosis with kind of limiting bandwidth and putting latencies, versus using shadow simulations.

Csaba Kiraly: Yeah, that's a different, yeah. It's a bit different game. The way I was using it was… with my scripts is, I was running, in a loop is different, actually, I wasn't even learning in Tulum. I was doing one LAN, Is, scaling the bandwidth, slowly down. And then, so doing the LAMP, which is the available bandwidths, and then, just monitoring analytics. So that's what I'm planning to do also here.

Kamil Salakhiev: Mhmes,

Csaba Kiraly: I do externally running it with different vendors constraints, or does the lab. checks. constitutes change. This is more for… Let's put interoperability more for some clients, more of a few clients' tests.

Kamil Salakhiev: Yeah, I remember Marco was recently kind of doing, shadow simulations for, like. I think around 1,000 nodes for cell-level deltas. So, I mean, that's… yeah.

Csaba Kiraly: Yeah, the problem is… The problem with shadow simulators is that the bandwidth model and the TCP model and, yeah, if we are doing it quick, you are a bit better, because you don't have TCP models with the feeling, but still… Slightly less realistic, I think. than the Kurtosis, so there was also with Kurtosis has a lot network, with these kids. different Doppler containers, so they are supposed to be… they are not localhost communicating, so it should be relatively realistic, to the point that I'm is doing it. School. Yeah. Basically, both have the quirks, so I see. We kind of have to lap posts. more confident, and, just gain more confidence by… by having different frameworks, checking stuff.

Before we go on, like, running, test this with ourselves. blah, blah, blah. I think that's expensive, this is cheap.

Kamil Salakhiev: Okay. Yeah, just… Another thing, just to keep in mind when we can run Kurtosis networks, I mean, every node, they can compete for the same CPU resource. So if there are some heavy operations, so… Yeah, they might.

Csaba Kiraly: Yeah, yeah.

Kamil Salakhiev: Things don't.

Csaba Kiraly: You should be mitigate it. Let's just… You should just run it well under the boundaries of the… I was using it for 5 more than 10 more than the switch, which is still 5. Excuse me. That much, that you have to go over the television a little bit. You should be careful with this guy as well.

Kamil Salakhiev: Yeah, okay.

Csaba Kiraly: You can also use it, like, like, you make the shadows, like, where you can scale the numbers, and you, you kind of verify the, the lower number size. Global size points of that with Kurtosis. So you got the confidence in, kind of, at least on the… on the part of the curve where you… where you can still run it from kurtosis, you are getting the same results from Kurtosis and from shadow. Then you have Some confidence that you are not doing success together. Is there any one way of using it.

Kamil Salakhiev: Yeah. Yeah, okay, good. Yeah, just getting back to, the sparse bull pool discussion, so, yeah, yeah, please, on the outside, if anyone has a branch, I mean, Prysm, Lighthouse, telco, please ping us, yeah, then we can signal. It's kind of, like, another thing we need to kind of be ready. for the… yeah, kind of deploying that on blob. Blob.nets, or in Glamsterdam devnets, when… I think there were some issues with blobs recently, and they're not there, if I'm not mistaken. Just checking that. Yeah, yeah, Casey?

Kasey Kirkham: Priority question about… express blob pool. Are we trying to treat this similar to partial messages, where it's, between forks, incremental rollout, or is this a Hego to… Pork.

Kamil Salakhiev: Yeah, it's not, like, a consensus change, so it could be done between forks, actually, so we don't need, like, every client to be, to support that. But yeah, we kinda need at least one CO to start testing that.

Kasey Kirkham: Yeah, I'm asking because, we might have to just prioritize against, partial messages, support in Gloas, so we'll keep that kind of top, top priority, and, once that's in a good spot, we can do a couple of these, As far as small pool changes.

Kamil Salakhiev: Yeah, yeah, I mean, yeah, it's… at once… in some sense, it's kind of straightforward change. On the other side, yeah, we kind of need to introduce metrics, also on the old side, that… a bit of work, yeah, maybe Bosu can elaborate on that, like, there are some nuances on how to implement, for example. I think we had a discussion recently with Felix, so, for example, when we support Bob, both get blobs v3 and… get blobs before, it kinda gets challenging to… Keep both of them performant, so… yeah, ELs, they kind of need to think of how to maybe introduce some kind of smart caching system, so, yeah, to, like, predict, which version. CL uses, something like that. Yeah, Boso, maybe, can you elaborate on this? Maybe some other implementation details that you'd like to share, maybe, to other ELs regarding Sparse Blotpool implementations, if you…

Like, what you've been up to recently.

Bosul Mun: away.

Kamil Salakhiev: Okay.

Bosul Mun: Before… before this, question, I have a question to Casey, so… you want to prioritize saliva delta, because it's for Lois.

Kasey Kirkham: No, I was, I was just clarifying, trying to clarify how quickly we are trying to get Sparse Blob Pool out. I think partial messages is… still higher priority, and obviously, like, we'll have points where we can context switch and do some sparse blob pool work. I'm not saying partial messages has to be all the way done first, just kind of clarifying that I think partial messages is the higher priority thing to get moved through the pipeline.

Bosul Mun: I see. Okay. And about the… the cache? So, CAS is currently working on local cache, and… I… So, so the problem is that when you have sparse bopoo. we have to recover blobs when GetBloves V3 is called. So it's technically possible, for CL to code get blobsP3 to sparsePopul, and in that case, we have to calculate recover jobs on demand, and it will take some time, so… We are trying to solve this, by implementing a cache that we can, preload and compute the blobs that Is that… that are likely to be included in short period. And this is also related to the…

pass blobs that will be introduced in Cell about Delta, and, in that case, we can use that pass blob signal as, Cache load signal, and also compute the… to pre-compute the things we will need in the future. I will… I think we should specify this problem in the EIP. I will also work on that.

Kamil Salakhiev: Hmm. Okay.

Bosul Mun: for this meeting. Yeah, so this… so this is… how we will handle this problem, and I think it's important for other clients to be aware of this.

Csaba Kiraly: So, I was thinking… Can't we… Be in a different opposition mode when we are… connected to CL, which is not supporting it. Yes, yes.

Bosul Mun: Yeah, so we are… Yes?

Csaba Kiraly: Yeah, and I was just thinking maybe we should… Like, not being spars, proper position mode when the CL is not up to speed. Let me… we just avoid the problem, maybe.

Bosul Mun: But that… in that case, our band-based consumption will be bounded by how many CLs implemented, or using that block tree, and… So, my approach is… Getting… those signals from CLs, like, they're, engine API capabilities, or, The method they are calling, and… Pre-compute. If it's needed.

Csaba Kiraly: Okay, yeah, yeah, it might be better to be the dynamic. I was just thinking that we can have a shortcut. if… We just say, you have to have an update CL and DL to benefit from this.

Bosul Mun: I think that direction also makes sense, because if we are running for special mode, and CL is… that don't have, doesn't have, GAPLOS B4, and if they are pulling that gap plus B3 only, then they will see a lot of, gloves missing. So, in that case, increasing some… increasing the patch probability Can be also a solution. I will think about this.

Csaba Kiraly: Yeah, yeah.

Kamil Salakhiev: Daniel?

Daniel Knopik: Yeah, Boswell, you, briefly mentioned that you were going to use has blobs as signal to warm up the cache. I… currently, I'm in my… in my draft branch, I call has blobs, wait for it to return, and then call get blobs. Should I keep it that way, or would it be better if I start both calls in parallel?

Bosul Mun: I was assuming that has blobs is pulled before GetBloves? And there would be enough time for us to com… Preload or compute the blobs. Fee for gap gloves is called.

Daniel Knopik: Okay, I mean, yeah. I think there is not much time between has blobs returning and Lighthouse then calling, get blobs, so… just noting that, but… Other events, otherwise, sounds good.

Bosul Mun: Huh? Do you know how much time… how much duration we will have, like, roughly?

Daniel Knopik: Between the two calls?

Bosul Mun: Yes.

Daniel Knopik: it's… it's called right after. I think there's, like. I can measure, but it… It'll be, like, in the… Between Lighthouse seeing the call return and Lighthouse issuing the next call will be, like, microseconds or something.

Bosul Mun: I see, I see.

Daniel Knopik: Oh, a few milliseconds, I don't know. I'll check.

Bosul Mun: Okay.

Kamil Salakhiev: Okay, Casey?

Kasey Kirkham: On Prysm, we've also talked about possibly calling them concurrently, so that we can more quickly determine if we don't have a blob, and we can, for partial message purposes, send out our bitmap faster, when we just don't have a particular blob. So from the EL point of view, They would be almost at the same time, but it could be either or order. So I'm wondering if that would be okay.

Bosul Mun: I, it's Felix, so I, I was… I was just curious, though, regarding this, this, HasBlobs call, so we were building on this assumption somehow that, there would be some time passing between the has blobs and the get blobs call, because that would be… Like, it would just be good for, like, in order to make… for this caching thing to make any sense, it obviously would be nice to know, like, which blobs you will need. return from get blobs, like, as early as possible. So that's why we were somehow assuming that you would know somehow earlier, you know, which blobs you would be calling has blobs on, and then later, when you actually need those blobs, you can

We would have them preloaded or something.

Kasey Kirkham: Right.

Bosul Mun: If you call them at the same time, it doesn't really make any sense, it just…

Daniel Knopik: I mean, originally, Hasblobs was conceived because, get blobs took a long time, and… All partial message. activity going, going, going outward was blocked on, on, on this, because we don't want to request any, any cells while, we are unsure what we have locally, so… we… we thought about has blobs, in order to At least figure out quickly what we can request from other peers. Until… while we wait for the slower get blobs call. And, this was, like, a interop thing, and we said, if it turns out that the performance issues, can be… can be fixed to a degree that we are happy with it, has blows basically becomes obsolete. Because… Yeah, knowing as early as possible which blobs we have is good, but having the blobs as well, so we call both at the same time as soon as we become aware of the KZG commitments.

Bosul Mun: Yeah, I mean, mostly with has blobs, it's good, because we… we can serve it kind of from memory, we don't need to load anything, we just… we can just tell… tell right away what's… what's there, so I think that has an advantage. So it will still be faster with has blobs, I think.

Daniel Knopik: Great.

Kasey Kirkham: Yeah, so the… the… Expanding a little bit more on the concurrent calls, the eel is trying to do two things when it makes these calls. One is to determine what bitmap to send out to its peers, and the other is to get the cells from the EL so that it can populate, our partial message data structure, so that we can avoid verifying proofs on incoming cells that we're getting from peers, if we do already have them. So that's kind of why it's useful to be able to call both of these methods at the same time. But yeah, if we have a fast GetBlobs V4 query, then, That's… that's kind of the… optimal, solution. But it seems like HasBlobs's always going to be faster, so for partial message purposes, being able to have that fast path in parallel will let us get the bitmap out faster, and that's ultimately going to result in,

Messages propagating faster.

Raúl Kripalani: Yeah, so one thing that worries me about this design, and I… I mentioned it, I think in Svalbard, is that it breaks the atomicity guarantee of GetBlob, so right now, when the CL asks the EL, it can… basically, there is just one request, and the EL is technically locking the internal, or freezing the view, or, like, acquiring a lock, and just… returning a coherent response, a consistent response, but the problem is that when you split this over two requests, unless you batch them over JSON RPC, but then you need to represent the whole batch, or make an assumption that the whole batch needs to be atomic, so that's… that's another problem. You can actually have some… some drift between the has blobs and the get blobs. Technically, I know it… the chance is tiny, but it's still there, so it's a correctness problem.

So I would not, bifurcate this. If anything, I would just have get blobs return two responses, or stream two responses, and this is… this is possible. This is, I think… There's an extension to the JSON RPC standard or something like that, that basically just returns, a multi-part response, so to speak. So you can maybe return the mask of what's available and what's not, as a first, unit, and then the actual get blobs payload as a second unit. Because, just to be clear, the EL does not make any guarantees, continued guarantees about availability in the blog pool, and unless you lock that availability in some way, there is Technically the possibility that the EL will decide to drop a blob that it previously told you it had, between the time it told you it had it and the time you actually requested it get blobs.

Kamil Salakhiev: Yeah, we discussed that with Marco yesterday, actually. What we need, actually, is, I think, if we decide that, yeah, we need… has blobs, well, I think we need, and yeah, we need to specify that in engine API PR, and yeah, we should kind of specify, like, if EL reported that the blob is available. For how long it can, well, ECL can make assumptions for how long this blob will be available. And I think the fair assumption would be, like, so. For this slot, when has blob returned true. Yeah, the blob should be available, and for the next slot, yeah, the blob can be already included, so it might not be there. Maybe… Yeah. Justifying that would help.

Raúl Kripalani: That's… I think that's a pragmatic solution. In that case, what I would do is definitely rename the method. It should not be called has blobs, because it implies, no side effects. That name implies no side effects, and this is side-effecting. So, I would not… this is mutating state, so I would not call it has blobs any longer. Maybe, like, lock blobs, or, I don't know, prepare blobs, or something like that, I don't know.

Bosul Mun: Hi. So… How about this? I… After the, the Celebrate Delta meeting, So, I… it is possible to pin those blobs in cache. We already integrated that into the cache implementation, but… It is still possible that The gloves that we had available is not… actually, included in the cap gloves, because There can be some… this corruption or something. So… because available blobs only looks to the lookup, and… don't actually check whether we can decode, read those blobs from the disk, and return in as a response. So I… I… we… so… Guests will try best to serve… to make this, property

satisfied, but I still think there should be some mechanism to recover from this situation on CL.

Raúl Kripalani: Wait, but this… this sounds to me… Oh, okay. This is a consistency trap, right? Because… a problem like this would be an internal error in Geth, or, like, the EL, I don't… no finger-pointingeth, but, but just any EL, right? Because the memory view, or… Like, the internal state would not be synced with… the, with the durable state, right? Is that what you're saying? So basically, it could be that the blob is corrupted on disk, so you think you have it, but then when you return it, like. It's corrupted, so it's either there's some bad bite there, or something else, like, what do you… is that what you're saying that could happen?

Bosul Mun: No, but we are talking about the same thing that you are talking about. There is a time difference between hand blocks and gap blocks, and thus there can be inconsistencies in the mempool.

Raúl Kripalani: Yeah.

Bosul Mun: over these inconsistencies with the cache, but then it's the question… I mean, it's totally possible for us to do that, but then the question is, should the CL really 100% rely on it? But Daniel already answered it in the chat here. It's… there is not this assumption in the CL, at least not in Lighthouse right now, that what is marked as available in has blobs must match 100% what's returned in get blobs. It's just an optimization for them to… prefetch more things, or deliver more things on the P2P layer while waiting for the response. So I think that's good. I mean, we can make it as perfect as possible, and yeah, if there's an internal error, we can always just fail the call or something.

But, yeah, we just wanted to highlight the same thing you highlighted, which is that there is this discrepancy between the two calls, and they are not fully atomic with each other, because they are two… taking a snapshot of the mempool at different times.

Raúl Kripalani: Yeah, yep. Daniel, is this failure, like, recovery path, or kind of, like, inconsistency recovery path, part of the spec already? Because it feels like it should be, if… You know, we're relying on this to… like, on this dance, then we should have a section that says what to do when, we get fewer… we get, like, a… we don't get the full set of blobs that we expected, because that would trigger another path. in… to request those cells, right? In partial messages.

Daniel Knopik: Do you… do you mean in the partial messages spec?

Raúl Kripalani: Yeah, because my understanding is that what we're doing is we use has blobs to then fire the lists, the one lists, to our peers before we actually get the data and we can reconcile, which kind of, like, saves some round-tripping, which is good. But then, like, if we have… not signal that we need something, and then it turns out that we need it because the EL was not able to provide it, for example, then that would… that would be a failure recovery path, right?

Daniel Knopik: So, in the metadata, we have two bitmaps. One is the… I have. Basically, and the other one is the, requests, bit, bitmap, it's called. And… So if the… if gath tells me that it has certain, blobs, then I don't set my I have bit list, because I treat the calls as, you know. as their own thing. And, however, I request all the blobs that Geth claims to not have. So that others can already send me those, blobs, if they have them. If Gethnaw gives me blobs that they previously claimed not to have, that's not a problem, because either Piers already sent them, that's fine, or Piers will send them, yeah, that's a bit of wasted traffic, but that's not a problem. The other case, where some blob disappears.

It's also fine, because as soon as GetBlob returns, I just request all the remaining blobs that… Our, you know, left.

Raúl Kripalani: Did you say that you… that we populate, the I want… sorry, the I have part with… the initial response from Geth, with the… with the response from has blobs?

Daniel Knopik: Yeah, I said, we don't do that.

Raúl Kripalani: We don't do that.

Daniel Knopik: I don't do that.

Raúl Kripalani: Yeah, it would be a scoring, yeah, then it could turn into a scoring problem. If we said we had something, and then we retracted from that, like, yeah, okay, cool. Yeah, yeah, sounds good. Yeah, maybe we need to, like, I don't know what the current state of the spec is, but it might be worth adding, like, a node or an implementer's node around this or something.

Daniel Knopik: Sorry? Yeah.

Raúl Kripalani: Sorry, I was just saying that I don't know what the current state of the spec is right now, but it might be worth adding an implementer's note around this specific case.

Daniel Knopik: The spec was always a bit light around the exact flow of get blobs as well, and how that immediately translates to a published message. Was very focused on… on the actual validation of incoming partials, and, but not really around the EL calls. So yeah, it's not really explicit that these two calls are not atomic, With, respect to each other. it's kind of implied, but yeah, implementer's node sounds good somewhere. Maybe… maybe I can… Or, yeah, Michael, I'm not sure if he has time, but yeah, sounds good.

Kamil Salakhiev: Chabba?

Csaba Kiraly: Yeah, I wasn't… part of the sparse blob pool discussion, but I still think the… streaming version, which, where you just simply send over the… What ideas did you have would be better. Like, the… It's like I was… kind of going in that direction, sometimes around GitOps VC, before there was, VC. And I just still think that that would be the right direction, so you just notify the CL amount drops that you have. Without… Making guitar requested spawns. I remember that I was looking at purchasing that DC at the time, and… for the protocol, that would be supported. For the implementation, so I don't know if that part's implemented or not. Anyway… I think it would just, in general, work better if… if you would… see, I would have this stream of…

drops that are there in the element, and then just do the get core when it wants to get something. Rather than playing this… is… when should I ask whether you have it or not kind of game? Just feels that much will. It's smart. That's… Because I don't know what to say.

Kamil Salakhiev: Yeah. Okay. Yeah, if nothing… On that, nothing more. Yeah, I think just… Just as an action item, yeah, like, when NECL, yeah, introduced support for the… Whoa. for the Sparse blog post, please ping on Discord channel, yeah, we should create this channel, like, today, I think. Yeah, then we can signal, for the readiness for the next blob.net, depending on cost, like, on… how many ELs support that, so I see that, yeah, Geth is active, Nethermind should be good, and the ethrex also has APR. Yeah. Nice. Okay, Chab, I think you have your hand raised, but you just didn't lower it. Oh, good, nice.

Cool, nice, yeah, anything else? Any other, discussions from anyone? Yeah, if not, I just can really quick, do an update of, like, what's going on in, like, lean theorems between drop, like, universe, what's going on there. Yeah, we've been, like, Itrox guys can aware, but yeah, we're already working on… DevNet4 and, like, trying to make more stable networks there. One issue was… Scaling is that, yeah, we just… DevNets were really small. And, basically the challenge that we have there, comparing, like, to existing Ethereum, is that, yeah, the signatures Becoming larger instead of, like, 200 bytes, messages, we have, like, 1.5 kilobytes, at least. That's the goal, per signature. At the moment, we have 2.5 kilobytes per message, and instead of… and we cannot aggregate them.

just as easy and, like, as fast as we do that for BLS signature, so it kind of, like, takes… 1,000 signatures per second for aggregation, and, like, then another when we have SNARKs, we need to aggregate them with a rate of 10 signatures per second, and the resulting snark is, like, 128 kilobytes of size. And then, yeah, this SNARK is included into block, so basically, yeah, we just wanted to… Check how it's, gonna work on… peak pillar, so, yeah, I've been working with the Zoom team and, yeah, Also, we'll be trying to… integrate more clients soon. Basically, we have these… Further, if I can open it. It's… it's currently on my server, but yeah, we will redeploy it on, well, elsewhere soon.

Basically, yeah, we've been running this, Yeah, the fazer is just as… we have two sets of nodes. We have either 32 nodes or 64 nodes, so we were… yeah, we did not go higher, for the reasons I'll explain later. Just assigning randomly nodes for different regions, and assigning them random bandwidth, and… basically, then, each block would ha- would have, at very least, one SSNARK, in… in it, sometimes it's more, and, that's already kind of… well, basically, the block size is at very least, well, current SNARK size is 256 kilobytes, so at the very least it's 256 kilobytes. That's only CL, that's only Bitcoin block, so we don't have any kind of… Yeah, EL payload there, so… Yeah, so the propagation was,

Even for 32 noses, that's already kinda… Like, around, Like, 500 milliseconds for 32 nodes. And, yeah, and the network was kind of relatively stable, but when we were switching for the higher amount of notes, like, 64, yeah, things already started to… Look more messy. So we see that finalization, for example, is not as stable, so we are kind of… we're not finalizing every block, but we have these gaps. When blocks are not… finalized in time. Yeah, we're using 3SF here, it's not, like, existing consensus from Ethereum. And, yeah, we see that, well, basically, the larger the block sizes, the larger… well, the slower is the latency for propagation. Yeah, sometimes it was, like, actually the… the slot time there was around 4 seconds, and sometimes the block propagation for… yeah, was actually around this slot time, which is bad. That's just… yeah, we were testing, like, the assumptions of,

yeah, how much we can scale with existing P2P networking. And by the way, here we also for now, we just ignored the fact that, yeah, we also have to take into account that aggregation is slow. Yeah, we… I think Zeam and some other clients, they will be introducing these flags to kind of put artificial, sleep for the time when we need to aggregate. So that the simulation is kind of more, kind of more realistic. Yes, so, yeah, just… the goal of this father is just, yeah, so we'll be testing both stability and also how the network behaves, like, for these size of signatures and aggregations. We'll be able to kind of, like, test different combinations of clients.

And, yeah. that's kind of it, so yeah, if any… yeah, it's just… we would deploy it elsewhere, but yeah, if anyone wants to take a look deeper, yeah, I can share the link, in the chat. And the code is… Charlene Shadow Fazer… Yeah, you can also take a look if you want. Yeah, that's just kind of what's going on on PQ end. But yeah, there will be, like, future dev nets, or things might change. And also, yeah, the PQ team is actually working on, kind of, reducing the sizes of signatures and speeding up the aggregation. So yeah, things might change. In future. Okay, good. I think that's all that we had in agenda for today. Yeah, any other topics that anyone wants to bring up?

Okay, nice. If not, then yeah, thanks everyone for joining. Thanks, see you in two weeks. Okay,

Daniel Knopik: Bye-bye!

Kasey Kirkham: Thank you.

Pablo Deymo: Do you mind?

Anton Nashatyrev: Bye-bye.

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