P2P Networking Call #8

Transcript

Potuz: Hello, coating.

Gottfried Herold: Hello.

Potuz: Have you been following the… OpenAI stealing the Navier Stokes results.

Gottfried Herold: Yeah, I mean, I've been following it, I mean, I'm waiting for the dust to settle, I guess.

Potuz: It's…

Gottfried Herold: It's…

Potuz: the community is going crazy here. Yeah, everyone… everyone is, like, canceling… canceling OpenAI subscriptions, everyone is afraid of, like, losing all of their papers. It's crazy.

Gottfried Herold: Yeah, I mean, to be fair, I mean, I'm only using it for not-so-high-profile stuff, for copy editing so far, but yeah, and it was just joking today. I mean, maybe Alexandre Grotenthik was right, and we should just all go into the Ardennes and raise codes.

Potuz: It's just crazy. Yeah, I have been using it on a conjecture I have for the last 15 years, and it has been useful, but I switched to, like, having agents communicating with themselves, and now I kind of regret this. Everyone is… Breaking out. Oh, and I just got a message here that people are recording this on AI.

Gottfried Herold: Yeah.

Anton Nashatyrev: Hey, guys.

Yann Vonlanthen: Hello.

Kamil Salakhiev: Hello, everyone. Can you just give me a second, I will ping everyone, then we'll start in a minute.

Daniel Knopik: Brick microphone check, can you hear me?

Kamil Salakhiev: Yes, we can hear you, Daniel. Okay, great. Yeah, I think we have a quorum, so yeah, let's just get started. So, hello everyone. Welcome to P2P breakout call number 8. So, we have a pretty packed agenda today, so we'll start with client updates, and then Yeah, we will discuss, RowDAS proposal, by Caba, then… We discussed, his ETH Research post about faster Pablo broadcast, and then… Yeah, talk about the new EIP, about this Pablo broadcast, and then, yeah, We will give some updates on EIP2P. So yeah, let's get started. So… yeah, let's proceed with client updates. Yeah, maybe let's start with Prysm this time. Do we have anyone? March, maybe.

ashah: Yeah, so, good progress on the Prysm's side. The PR for partial columns for Gloas, I'll put it in the Zoom chat. is, ready to go. We're just waiting… it's fully reviewed, fully tested, we're just waiting for one of the PR to land, and then we'll merge this in our release branch. On… last time, I mentioned that Prysm is working on an overhaul and refactor of its peer scoring system, so that has also made a good progress. Here's the design… like, here's a doc explaining the changes we are making at a high level. also sort of a design doc, I put in the Zoom chat, and… Here's the PR for it, if anyone is interested. We… it's dev complete, we finished testing it on our Hoodi node for a week, it looks good.

No noticeable regressions, now we're gonna… it's gonna go through a round of review before we merge it to a release branch, but this PR changes how Prysm ranks PRs for pruning when it's at capacity in terms of max connection. it adds a lot of observability to RPC APIs and metrics into why… Prysm is disconnecting certain peers, why it's blacklisting or graylisting certain peers, what are the errors that is causing that? So yeah, like, the main overhaul is an overhaul of the scoring system, which decides how Prysm Prune spheres, and also a lot more observability and matrix. into why Prysm is disconnecting peers, banning peers, relisting peers, what are the gossip rejections that we are seeing for… across topics.

what are some invalid RPC responses we are seeing across, peers, it also allows us to filter at an agent level, like, you know, why are we banning Lighthouse peers, or why are we banning a certain Deco beers, etc. So, we gotta start an internal review of this PR tomorrow, and yeah, once this lands. Yeah, once the review is complete, we're gonna merge it to our release branch. And like I said, I've been testing it on my own Hoodi node with a lot of validators attached since a week, and it's looking good. Please go through the PR, please go to the design doc. I mean, PR, I don't know, yeah, please, like, please go through both if you have questions, and they're on Discord, Telegram, anything. Thank you.

Kamil Salakhiev: Nice. Yeah, looks good. Is there maybe any questions, ash about this? Okay, if not… cool, yeah, let's proceed with, Lighthouse. Maybe Daniel?

Daniel Knopik: Sure. So, from our side, actually, not too much to report. We fixed the… Incorrectly ordered fields, thanks, Arsh. We also… are, looking… to hopefully soon enable puzzles on all networks. I think there's just some nuance outstanding, but there isn't there. Yeah, and also, which is kind of related, which came up during ACDC last week, I… I basically asked. why the Gloas limit for columns is so high, it was, like, 8 point something megabytes. Which is, thousands of clubs, and… It seems it's now going to be replaced by a dynamic limit, so that's kind of, then I'm making a sense of, like, take the highest thing in the blob schedule and consider that the limit.

Which is… Makes more sense than, like, a really high limit. So, yeah, makes sense to check that out, probably, if… Yeah. should be adjusted, in your implementations, I guess. But yeah, otherwise than that, a lot of work on Waggle, so I've, started working on… Yeah, attestation broadcast, so it's also Quinn's proposal, using it, so that is ongoing. Yeah. Ash, you have your hand raised.

ashah: Sorry, just one quick question, Danielle. So, when do you think you'll have the… have the fix for the… group ID container in your Docker image, so, like, I want to do one more round of kurtosis testing and ensure the interrupt works fine before I turn it on in Lambda and DevNet 8, you know, so we don't end up breaking the DevNet.

Daniel Knopik: which Docker image? It's in Unstable, so it should be in unstable, I'm not sure what tag specifically you mean.

ashah: Yeah, like, so I'm saying that, you know, the group ID… We had a bug where the, right, we had the group ID, the order of the fields was reversed. Which would.

Daniel Knopik: That's merged, that's merged. So, I'm not sure what exact image you are building from, but, I mean, Definite 8 image is built from Unstable, so it should be on Definite 8, and it should be also on the corresponding Image, as far as I'm aware. Yeah, thanks for reporting that.

Kamil Salakhiev: Yeah, cool, nice. Thanks, Daniel. Anton, do we have anything from Teku, or… or Grandine?

Anton Nashatyrev: Yeah, hi, sorry, yeah, I have no, again, I have no information about Teku, I just know, like, lately you guys, were fixing some. vulnerabilities Yeah, that's probably it.

Kamil Salakhiev: I heard Teku was also working on partial messages, if I'm not mistaken. Do you know any updates on that, maybe?

Anton Nashatyrev: - no, to be honest.

Kamil Salakhiev: Maybe I am mistaken, maybe I'm confusing.

Anton Nashatyrev: I… at least I… yeah, at least I didn't, aware of it.

Kamil Salakhiev: Yeah, okay, no worries, thanks. Cool, yeah, let's proceed then… Yeah, do you have any other seals? If… Yeah, let's proceed with the EL site, Okay, Arsh, do you have a question, or you just did not lower your hand?

ashah: Sorry, I think it's an earlier hand, my bad.

Kamil Salakhiev: Okay, notice. Yeah, yeah, Caba, anything from GIF?

Csaba Kiraly: Not much update on… at least on my side. I was working on not only P2P and… and RowDAS and, segmented broadcast, so… We are making changes to this passport pool. I have a few branches on that, which are in plugless. And then, we are also making plugless with the protected pill pools. Which I mentioned in the last call, so the latency-based… Protection, but yeah, there's a… Proceeding on the appeal pass. But not yet merged.

Kamil Salakhiev: Okay, cool, thanks. Yeah, FLCL… Never mind.

Alexey Osipov: Hello. No news, related to Glamsterdam, as possible pool. We just have it, in master, and Did not update it, recently, but we are working on improvements, related to IPv6 support. Need a couple of pairs, and, we can call it, done. Potentially, yeah.

Kamil Salakhiev: Okay, thanks. Yeah, any other team that I missed? Okay, whoop. Yeah, then let's proceed with other topics, and yeah, let's start with RowDAS. Inshallah.

Csaba Kiraly: Let me share… Let me first find it and then share it. She is clean, hello. Yeah, so I have some slides, I will just go through them quickly. Yeah, so RowDAS, which is in the Heritage list, it's about distributed… globally construction. Which we don't have now. So, a quick history, behind it, let me just… Change my screen so that I see my own slides. Yeah, so, quick history behind this. So, the 4 DAS, which has… was 2 years ago, and then it had a version 2. It had a few things, but, what's interesting here is… is three features, which it introduced compared to… to PeerDAS. One was,

that we can do a distributed reconstruction in the network, and then there was, the block level, so the vertical coding, and then the subdinal sampling. And RowDAS is basically there to bring the first one to the mainnet. So, distributed reconstruction. PeerDAS also had a bunch of other things, bitmap-based messaging, structured segment IDs, et cetera, et cetera, and we have now the PSO messages in gossip sub, so what I was building for Ludas is kind of using that and building on top of that. So when I say distributed reconstruction. That kind of means two things. So one is the vertical distribution? And I typically introduced it in that direction. So that means what you have now is every supernet node has the duty to do the reconstruction, so it has the columns, and then it has to calculate

The thing that it has to calculate it for every single blob, that it doesn't have some card blobs. So they just repeat this work. And the aim of RowDAS in this regard, is to… to change that, change that by assigning duties, basically, to, to, to Sprints, and then they know which one is the duty, and they… they first act on that. So by this, they are distributing loading network. And the other one is the horizontal, distributed reconstruction. Which is more about, what ethereum should be. So, that's the, the supernodeless reconstruction. So you don't need, super nodes, but we have them, but you don't need them, and the protocol can still reconstruct, blobs… blob content in the… in the distribution, so making the distribution more robust, even if you don't have these data centers, super nodes which are supporting it.

Yeah, a bit about numbers. So… currently in the… in mainnet, we have more than 2,000 super nodes. It's kind of… They're coming from different… parts. Part of them is, is, is high custody, high custody. They were high custody. Part of them is high-stake notes, another one is… is Layer 2 notes, which needs the blobs. And then each one of them has to do with the construction. The construction is expensive because of the construction of the k commitments. It's like 160 milliseconds, ballpark number. And then you do it on every blob, let's say on 32 blobs, then you are spending a bunch of CPU time and everyone is spending it, and by distributing it among the nodes, you can just reduce that spend at the network level.

There is already something in PeerDAS, I was adding it to the specification, so it's… it has this kind of allowed random delay, and that can help mitigate this, but it's not to the level of kind of dedicated reconstruction. So what you have in RowDAS is basically everyone has a dedicated law. It's kind of the custody law, but it's not custody requirement. I didn't want to make it custody requirement, because that would change too many things, and that would be too big of a change, I guess. So, no custody law, just an add-on law. Which you should care about. And that kind of designates which… what you do first. And then you have the low topic, on which you can actually send out that data.

So you are super node, ID something, based on that, you know that you are responsible for, low… 58, and those 58 maps to blob number 3, and then there's a blob number 3, then you are reconstructing it. There's this mapping click, between blobs and… and those, where I'm keeping 128 lows, we can discuss that constant, it can be different. But the number of lows, and there is a mapping between, blocks in the block and loads, so that we are evening out load in the network, on the… On the longer term. So this is how… how the construction works. Basically, you have your, you're, you assigned. And then, that's kind of your duty, and you should, if you see that you have to deconstruct, you are deconstructing that, you are sharing, the result of that along the row, and then, if you still see that there's nothing else deconstructed, then you do reconstruct the other things.

And then, actually, other nodes can chip in even later. Yeah. So the… on the deconstruction node, this means basically the two others of magnitude, improvement. So instead of deconstructing everything, you are just reconstructing 128, if you have a supernode, 128… Of that, so you just spend much less CPU time doing this reconstruction work. And if the network has, enough nodes. Which we have, then everything that's deconstructed by this, by this, deconstruction. If the network doesn't have enough loads, or things are delayed, then the thing is falling back, basically, to what we have in PBS. So then you are falling back to deconstructing other things as well. And then there is one more fallback step, which is falling back to nodes are reconstructing without relying on zipper notes.

Okay. I tried to go fast, but feel free to ask. Yeah, so the whole thing is designed in a way that kind of the column pass distribution becomes the… stays the canonical distribution. And the low pass is just chipping in when things are not working. So, I was trying to design it in a way that, that the column pass Remains as performant as it was before. It's ballpark there, so I was measuring a few milliseconds up and down, measuring it over a bunch of network shapes and, network sizes and topologies, and the way, which is how it is implemented now, it… achieves this. So we are not giving up on… on the performance, what we have, to…

to make the lows work. In my first naive implementation, the lows were just basically doubling the, the, the data mount, and that's obviously not good, so… so I had to tune the implementation a lot, to do that. But I tuned it, and now I have that. Yeah, this is kind of… that's an interesting figure, but, testing that the low-wise deconstruction happens, actually, which PBS is not doing it, and RowDAS is doing it, so it is just testing if if there are the only notes… if there are no super nodes in the system, I was testing the reconstruction is working, and it's working. Depending on the number of nodes, the, the custody's distribution, etc, maybe not at the 64 limit, but, at 65, it does.

And then I was doing a bunch of measurements, I was writing under the tech, obviously it is not the kind of mapping up all the attacks, but trying to do a few things that can happen, evaluating under different scenarios, PeerDAS against RowDAS, without super nodes, with 10% of super nodes, with 20% of super nodes, in the network. And then evaluating, different sized consumptions. So, evaluating, basically how much CPU time is spent, and then, how much What was kind of the completion time, so the latency, and then the bytes sent on the network. With… with an… with… Piotas and Envy RowDAS, and the… the essence is that against Hardel, if under nasty situations, it's kind of degrading to PBS levels, but, but usually we are gaining a lot.

Yeah, in this call, I wanted to arrive to this slide. So, while I was doing it, I was doing a bunch of work on the partial message, implementation. So… Yeah, this is just kind of a list of, of things that I was porting from, from my earlier works and, from other works to, To pass some messages. And, things are about, how we are doing the announcements. How we are doing requests, whether we kind of handle the fact that we… We give comms a higher priority, Then, the, the phase available forwarding is… is what comes from the, from my, push-pull. Phases light up. And then, I did change how requests are working, so…

the goal EP2 implementations had a request policy where basically whenever there was an I want, and I have, went out, and I was working on changing that. And then… a few interesting changes. So adding things where you can… you understand, that a node is interested in a given cell. So, it's, it's not on your law, but it's… It's… It's having something that you have, because you have it on the column, something that you need, so you are kind of not… you are not on the same topic, but you know it needs it. And then, the default gossip-sub-messages filtering, so the kind of the default implementation is It's basically, I have the information, but I'm not telling you that I have this information, and I was flipping that over. I understand that you need this information, and I actually…

in the gossip, in the HerdBit-based gossip, I do send the information saying, you know, I have that cell that you need, if you want it, and then you can actually ask for it. Yeah, and then cost forwarding. So the implementation changes… quite specific. Which bring the performance to a good level. More or less, that's it. Yeah, let me stop here. it's in PLISMA, so you can add this RowDAS, and I mean, it's on my branch of PLISMA, obviously. So you can use RowDAS, and then you can run experiments with RowDAS. is, an implementation, which is definitely not, High-quality implementation, but it implements lots of the small tweaks. That are useful here. And I think I stop stop here.

And wait for questions.

Kamil Salakhiev: Nice. Thanks, Caba. Any questions? Okay, kasey.

Kasey Kirkham: Could you go back to the slide detailing the… changes to, Gossip Sub.

Csaba Kiraly: Absolutely. I'm not sharing it anymore, right? I think I still.

Kasey Kirkham: Or, yeah, if you could… if you could… if there's a way for you to share that in chat, I just wanted to look at… look at that a little more closely.

Csaba Kiraly: Yeah, I will also do that, it's just not online, so let me just go back now. This one, right?

Kasey Kirkham: Yes.

Csaba Kiraly: Yeah, so… Any specific you are interested in, or… or just want to see it? So the… the thing is, the… the way… I did a bunch of changes, both in the partial messages. and in the normal gossip sub, and then I was porting changes back and forth between the two. But the… the policy message changes I did, one… one of… So, yeah, so there were a few things that were important. The IHEVE The reaction to IH is definitely, important. And then, many things related to what we are announcing on a Herdbeit. So, the Herdbeit announcements is… is… goes… goes kind of with a very strict interpretation of Of what the others need.

And then we are not even contacting nodes, which… which are… Don't need something that we think They would, but we are… we are not looking at it the right way in the default implementation. So, I know what topics they are subscribed to, and based on that, I actually know that they need stuff that I have is just not… on the… on the topic that connects us. And then we were… we were skipping them in the… Indeed. In the… Right.

Kasey Kirkham: pushing the metadata to them if you weren't subscribed to a common topic?

Csaba Kiraly: Yeah, so I'm pushing metadata to them. If I have… Yeah, yeah. Right. I should make…

Kasey Kirkham: your knowledge of their subscriptions, based on their, ENR?

Csaba Kiraly: We actually have to make a drawing of that. But we were basically not… not pushing stuff, because they were kind of interested in the low dimension while we had it in the column dimension, but it was the same And it's the same cell, it's the same data. So I'm handling that kind of two-dimensional space in the…

Kasey Kirkham: Yeah, that makes sense. One thing I was curious about is if you could talk more about, this concept of phase-aware forwarding, and, like, what the… I guess… I'm guessing the phases are to do with the heartbeat, like, you have… Some notion of the number of cycle… heartbeat cycles within a slot.

Csaba Kiraly: No, no, no, so the phase will… I will speak about it in the next presentation, but I can only speak about it. It's… it's based on… the phase is based on… on basically seeing, how many have the thing. So if I see that something is diffused in the network, I switch phase. And the phase is basically how much I push and how much I pull, how much I advertise. So I start by aggressively pushing, actually not that aggressively, but I start by pushing, and then as I see that nodes tend to have that segment in the network, I switch to more and more of that advertisement and less and less pushing. And it's based on, on the feedback that I'm getting from, from, from advertisements. So, from bitmaps here, in the normal Valiant, it's from, from IHs.

And… and hardware BSI halves. And I don't want…

Kasey Kirkham: I see. So you're inferring that a reconstruction cycle, this amount of time is how long it's taking my peers to reconstruct a row, and now I should update my view?

Csaba Kiraly: Yeah, it's not even… so there's the deconstruction part, but even without the construction, if you just think of individual segments. Then if I see that something is already diffused in the network. If I would still push it, I would just generate duplicates with a high probability. So… Instead of pushing it, I announce. And then by announcing I, I reduced the duplicate count.

Kamil Salakhiev: Okay. May I ask to go to slide number 4? Just wanna check some numbers. Pretty quick. Yeah, I'm just reading, one blob recovery is 162 milliseconds.

Csaba Kiraly: Yep.

Kamil Salakhiev: This includes, kzgrew proofs, right?

Csaba Kiraly: Yeah, so that's, that's, together with the, with the calculation of the, the calculation of the, of the kzg proofs.

Kamil Salakhiev: Yeah, and I also think this, this is done per core, so I mean, this is like…

Csaba Kiraly: Yeah. Yeah, so it's a single call. So, so you can… and I was also doing work on… on optimizing this, going down to… 45 milliseconds. If you are not on single call. But you just need one, but that's a different work. But you can parallelize these. So it's not, it's not about, like, not about absolute time, it's about burning CPU and defining what's the minimum hardware requirement that you need. And you need a beefy machine. So if you don't want that you need a beefy machine, then we can do those things. And if you don't want to burn CPU on this, but maybe you want to use it for something else. Because another thing that we should, spend CP on, to name a few, soon we will have to proof stuff, and verify proofs and everything.

Then, you know, it's just… Let's not burn CPU well, you don't have to.

Kamil Salakhiev: Yeah, yeah, I just… I would be careful saying that 32 blobs takes 5.2 seconds, because in reality, I mean, we have more than one. CPU core, but…

Csaba Kiraly: In the light-up, I was detailing that, like.

Kamil Salakhiev: Yeah, yeah, okay.

Csaba Kiraly: Yeah, extensively, he died not. I didn't. But that's… that's CPU call time. It's not, 5.2 seconds of the 12-second slot.

Kamil Salakhiev: Yep, yep.

Csaba Kiraly: No clue that.

Kamil Salakhiev: Okay, good. Any other questions?

Csaba Kiraly: Oh, I didn't arrive today, did I? To my last slide. Wait, where did I put it? I lost my last slide. Yeah, so this one. Oh, I just jumped over it, basically, sorry. So, I was writing this whole thing, and then I, said, okay, but why do this whole complicated thingy? So we have these two objective side. Let me go back here… We have these two objectives. One is the… vertical distribution was the horizontal distribution, and I always wanted to do both. But if you just say, I don't want to do the horizontal, I don't care about supernodeless, we have super nodes. Just the vertical one. I can do the low assignment. And, and use, use the column topics to… To… to distribute the load.

So I have a reliant in which, I still call it RowDAS, but there are no laws. There's just a low assignment. There are no low topics. But we do low assignment. And that is this coordination, basically, of the construction duty between the supernodes. So, it was the last thing that came to my mind, so I left it to the end, in my light-up, and also… It's not in the EIP, and also, I've lost it in my slides. But this is what I call the duty sharded PBS. Which has no low topics. It has the assignments, And then, basically, what it does is… at one point, you have your low assignment, you are reconstructing that. If you don't have the columns, then you are deconstructing based on your LU assignment, and yet you are sharing that to the column distribution. To do that, you need this improved version of,

Of partial messages, because the, kind of, the current PowerShell Messages implementation is very much focused on the single source, sending out the, the bitmaps use case. And here, bitmaps are kind of popping up in the system, so… So you need a bit of… bit of tuning there. But basically, you get this… distributed super nodes deconstruction CPU saving property. But you still need super nodes. So that is this thing, and we can do this as a kind of a first stage of implementation. We just do the low assignment, and… we do the… The low-based deconstruction, and we sell it to the columns, and we are not doing… low topics. If people are afraid of the little topics.

Which are more complex than not having the world topics, that's for sure. Was that clear?

Kamil Salakhiev: Do you see?

Kasey Kirkham: Was this on top of… did you do this for Glow Ass, or, only for Fulu?

Csaba Kiraly: Pardon?

Kasey Kirkham: Was this, I'm just curious what… what point on… In Prysm, commit history you based this on?

Csaba Kiraly: This was, like, one week ago, developed Blanche.

Kasey Kirkham: Okay.

Csaba Kiraly: Yeah, I think one week or two weeks. I think I was debasing it at one point. I'm not entirely sure. I was debasing something, but I'm not sure it was this one.

Kasey Kirkham: I'm asking because I've been out sick, so things could have moved forward, but I know that, we had the… Arsh would know we had the Glowass stuff in a branch for a little bit on the DevNet branch. So some… some things might be drifted.

Csaba Kiraly: Yeah, so first I started to build it on the partial messages. Blanche, I think it was called like this. And then I think, in the meantime, that was merged into Development, and then I kind of migrated it to a developer. That's how I remember.

ashah: Yeah, like, I just shared a… link in the Zoom chat, Caba, that is the… Branch that has all the latest clue as partial columns work. And it is targeted… yeah, it's… it will soon be targeted against developed.

Csaba Kiraly: Let me see which one… Yeah, I didn't use this… this long name branch, and mine was partial messages, or something. I think… Thank you.

Kamil Salakhiev: Yeah, maybe just a last question, then. Oh, sorry, yeah.

Daniel Knopik: Oh, no, Connie, you can go ahead.

Kamil Salakhiev: No, just to have a quick one, just with regards to scoping. got it because there is an EIP that we VFI'd. so you made these 10 commits on top of goaliePTP, are they, like, mandatory for this EIP, or, like… We can just make some changes on CL. To make it work. I understand there is a fix, for I Want, I have, which is… I believe we should merge, and there are also a bunch of optimizations. like,

Csaba Kiraly: It is…

Kamil Salakhiev: I mean, that doesn't… Yeah.

Csaba Kiraly: When I went tired. And then, Yeah, I kind of… I was just going ahead with these changes, because these are protocore optimizations, That do not need… To be in the EIPI sync. But yeah, we can kind of evaluate one by one, what's… what's kind of needed, what's the price we pay if… if they are not there. I don't have the… Top of my head. I have the numbers for the… for the next one. But here I don't have the numbers, but I can… I kind of divide them one by one. I was a bit, you know, changing… many things, so… Most of them are generalization of the, of the current… code, which might not be the current code, as I learned. So the code that I have seen had been purpose-built for that specific use case, and if we are using it for other things, we need to generalize a little bit.

Daniel Knopik: So…

Kamil Salakhiev: Please, daniel?

Daniel Knopik: Yeah, so you need to make some adjustments to partial messages, if I got you, if I understood you correctly, like, on protocol level. I need to look into those, because I'm curious on what exactly they were, so I'm… I'll check that. But I'm curious, if, like, taking those, maybe, generalizations you applied to partial messages would, you know, also be good inspiration for, Waggle to support these, this use case, maybe. So I'm curious if you have Any thoughts about, using Waggle instead of partial messages for this?

Csaba Kiraly: Yeah, so… Absolutely, they could be, so these are, these are very genetic in the nature. partial messages we use as, kind of having the bitmaps. You can, you can see this. Having the bitmaps, having the structured, segment ID context, and so having the structured context, and what else? Being more pool available. D… in the next presentation, I was building out things without partial messages, and then comparing it with the partial messages, and on the partial messages, I couldn't email each the same performance, even if, in some sense, it should be better. So we do have to fight, kind of, these implementation differences at the moment. we have to separate, kind of, what's the technical changes that we want, the metadata that we are sending, who we are sending to, what's the underlying mechanism at the protocol level, and then how we are mapping it into this and that, and on top of REGO, maybe.

But I have to look into Waggle for that to be more specific.

Daniel Knopik: Yeah, yeah, RANDAO gives a bunch of more freedom, in my opinion, because it's… yeah.

Csaba Kiraly: I will do a… I'll do a better description of the… of the changes that I did, because it was a very… very fast description, so I will describe them one by one, and then… then it's… it's just much more specific.

Kasey Kirkham: Hey, sorry, if partial messages is the baseline you're comparing to, what is the alternative here? Just using more base, LibP2P without gossip sub?

Csaba Kiraly: Because of it.

Kasey Kirkham: the PT protocol, or…

Csaba Kiraly: Next word that I will present, will be, on, on fast, large message diffusion, and then I was using CBS lines. One was, I'm anticipating my slides. So one was just normal gossip sub, tuned and, and, abused. One was partial messages, and one was, the multi-topic, as we are doing it in DAS. So that's kind of the three baseline side, but that's kind of a different study, so I was not doing it for this heal, I was just building on top of partial messages implementation. Thanks. The partial messages with the bitmaps should be the light one in TLE. It's just, I think it's not yet there as, kind of, implementation maturity.

Kamil Salakhiev: Okay, I think it's time to move to the next presentation. I think you already covered some parts of it, but yeah. When fast payload broadcasts.

Csaba Kiraly: Oh, wait, I should switch presentations. Yeah, just let me… Find the other one. Almost that, just changing to single page? And then sharing. Okay. So… So the next one is about…

We can call it many names. I mean, the… The urgency is on segmented payload diffusion, is on fast payload diffusion, actually, so we just want the payload to go and be broadcasted and upload fast. But it is basically about large messages, in many sense. And… Kind of… this is the essence, in some sense. So… I was measuring things as we do it now. Visa one megabyte. payload. So, assuming a large block, and we can argue whether that's a good assumption or not, and we should do other things, but I was taking 1MB as the baseline number. And then checking how it would be, distributed. And I was taking… my baseline is when we have a home builder, and we have…

home nodes, so we don't have data center assistance. And what is data center is… so, I had notes which had 50 megabit uplink, and notes which had 1 gigabit uplink. And my goal is for things to work without the 1 gigabit uplink. Now, we have homes with 1 gigabit uplink, so… so we can argue which one is the right one. Anyway… So distributing a 1MB block, as we do it now, Without having a data center builder, the data center nodes helping, just the baseline by the minimum requirement specification nodes with 50Mbit uplink. What we are doing is slow. But you don't have that on the network, so it's not a problem in that sense. The problem is that our protocol is kind of not supporting our minimum requirements.

So if you, if you would do it, that's the, kind of the… do you see my EL?

Kamil Salakhiev: Yes.

Csaba Kiraly: my pointer. So this is a distribution from a 15 megabit uplink node to a Through 50 megabit uplink nodes, 100 megabit downlink. to the whole network, and you don't see the P50 is somewhere here, but it's here, but then the last node is getting it after 5 seconds, so it's super slow. And then if you are distributing from a faster node, then you are getting faster, and then if you're distributing from a faster node, and you have the 20% of the notes are fast notes, you are getting… everyone is getting it below 3 seconds. And yeah, that's kind of the deadline, the 3 seconds in EPBS that we have, so… so… In some sense, we would barely make it without declared minimum requirements, and that's not good.

So… Just have to let the cat out. So the… the… the thing that I did is I was running, a bunch of variants, of… S… So the baseline was that I was segmenting the message, and I just took a random number, segmented to 32, 32 kilobyte species. And then I was playing with different protocol implementations. So one is just a simple P2P segments and messages, with a few tweaks. That's the development A. one topic, and then B is, using PowerShell messages. So now the… the big one is called the message, and the small ones are called segments, and we have bitmaps. And then C is what we do in DAS, so this is, each segment has its own topic, assigned.

And then… and then I was also adding lead someone and coding. But the important thing is that all these improvements are here in this range. And around 1 second. a bit better, a bit worse, depending on the quality of the implementation, the reliant, and different factors. All of them are better than this. So, kind of the message is, let's just do something. And then, yeah, I think you all know this, so the whole problem is that, We are doing store and forward, and with a 1MB message, that means you're sending, and then the other is… Receiving, and then verifying, and then descending, and if you have multiple hops, what you have in a multi-hop network, in a mesh, then you're accumulating delay.

If you are segmenting your pipelining. If you can verify the segments. So… If… There's this asterisk that you can verify these segments, then you can go much faster and… Kind of here, you show that with different implementation, we can just go much faster. Okay. So, how we validate, these things. This is where, we were discussing a lot, with Kamil and Potuz and others, And basically, what we need is this, one field in the bid, which is the vector commitment, where we use a medical commitment. the root of that commitment, the commitment. So if… if we have… if you have that, Then when you, If it's in the bid, then it's in the Consensus block, and if it's in the Consensus block, when you receive the Consensus block, and you verify that it's fine, and you kind of install it, then it has the bid, and then it has this committed descriptor, and then when you receive a segment which has the proof, the medical proof.

Then you can verify that segment, and then that segment is good, and then you can forward it. Sue. this is what you need. What you basically need is that you have to figure out what to do when segments are live before the block arrives. So you have these two… I think I have it in the next slide, yeah. So you have these two solices, one is the… Is the, Proposal, sending out the consensus block. And then, that contains the bid, that contains the, the medical commitment, and then you have… the… The other side, which is the builder, If it's not self-built. But even if it's self-built, you have the builder which might send it out on a different topic, but it's typically also from a different place. You have the…

The payload, coming with the segments. And, I was playing, a little bit about how to handle this. And I came to this rule where you are not allowed to push a segment. If you don't know that the other one has the the consensus block. So… kind of this coupling between the Consensus block distribution and the… And the, the segment distribution. Well, there is a rule which basically doesn't allow you to do this push, when, If you don't know that the other one… others is ready to receive it. And, Even without these rules, things would work, you just have to buffer them all, but with this, we can reduce the buffering requirement, and I think the attack surface.

So that's one thing. But the other thing is… is… is… that I want to speak about… Is… is really just the… the networking machinery. So this is not the networking machinery, this is kind of the coupling between these two diffusions, which are starting, from From different points in the network. And then I was playing with different ideas, for example. topics which are sharing a topology, or one topic which are… with two types of messages. So there are different things that we can do there to couple these two distributions, one which is gating, the other. But even if we don't do this, things are working, so I'll take this as a side note. And let's go to this one.

So, as I said, I was adding, segments. But I was not just adding segments, but we have other techniques, so… I was… I was looking at what segmenting ads, and Valiant A means I just take a normal gossip sub, a normal topic. And I'm just… instead of sending out one message, I have now 32, smaller messages, each one having a small header which contains the medical proof, and maybe some Smaller to metadata. And if I just segment it, and just use the usual full mesh push that we were using for the whole message, we are already down to 1.7 seconds from 4 point something. Then if we use batch publishing. Which we all started to use already for a bunch of things. Then we are down to 1 second, and then we are… if we are adding face forwarding, which is the,

I'm just saying… I was speaking about, previously, that is, we are pushing… at the beginning, we are pushing and announcing, and then later we are switching to only announce. To free up bandwidth, basically. Then we are down even more. And then, as last, I have this discipline pool. This is changing the policy where whenever then I have arrived for the segment that I didn't have. I was just asking for it, even if I was asking for it from 5 other notes. Here I have, I'm asking it from… only from one. But that, is not that simple, because asking it only from one is opening an attack surface, because you could just declare having syncs, and then notes are asking only from you, and then they are waiting for a timeout. So I had to work on the discipline pool, quite a lot, to make it,

Smaller timeout and a rolling window, and so there are some delay… details to that to not make it. Have another amazing thing. Anyway, adding all these. VR. we are going down a lot, in time. And this is my ValiantA, which is using the normal gossip substrate, basically. And the… the change that it does, so it's not really doing any of the P2P changes, in many sands, it is using structured IDs. And then what I did… okay, I also played with, with, Azure Coding. I think we discussed it many times, edge recording is good, we like it. the essence is I'm not adding it in my baseline version, because this is the performance difference between the two, and some think that there is recording is difficult. So, if you don't think it's difficult, then let's just add it. If it…

if it seems to be the… the difficult part, then we can just keep it and we still have lots of gain. So… But if we have LG coding, then, it's cutting the distribution… tailor the distribution, so that's what we discussed many times. If you have… need every K of k segments, then if you have one This held omitted, or just left behind, because it's not, Because it's unlucky, then everyone has late completion. You can play with different scheduling rules to, to do that, so the scheduling rules which are balancing this, like, the DAS first scheduling, and I started to play with these. But coding is just a malaron solution to this. So… so we can do coding, and then we are… we are getting, performance gains, it becomes more resistance withholding, and… and all other kind of things, so it's… it's… it's good.

One more note for coding. First I was doing segmenting, and then coding, and then, Compressing the pieces, if they're compressible. And that gives you, with my assumptions around the compressibility of the block, That just gives you an unbalanced distribution, because you have these small segments which are compressible, and then you have the pallet segments which are not compressible, and that's not good. So, what I'm doing now is I'm having complex first, then segment and code variant, which is… Giving some advantages. Just a side note on, kind of, complexities which Azure Coding brings in. And then, last slide, very messy, and I'm working on preparing a write-up on this. But basically what I did, I was taking this baseline scenario, and taking my baseline solution, and then I started to change things. Change parameters, change,

reliance, change, whether I'm using coding or not using coding. So this is just… Different variants of A… My, my baseline variant, and their performance under one scenario, on a two-dimensional performance. scale, basically. This is how much bytes we use. This is how much time. We need to do the B99 of the diffusion. It looks interesting because there are huge differences between 0.9 and 1.3, but if you remember that the original was 4. Something, it just really doesn't matter, we just need to do something. But we can, I think, for us networking people, this is very important to kind of understand the details here, and fill out which one is the best, and which one is the most robust, and still good enough.

And I'm working on that. I don't have the figure for the compilation of the heel of the… ABC Valiant. Sorry, let me go back here. So I have the Avaliant, which is normal gossip sub, the B, which is using partial messages, the C, which is the multiple topics. They have structural differences, they have performance differences. But many of… I was measuring performance differences, but many of the differences are basically down to, like, which part is implemented how. So, by aligning implementations, we can also kind of align them to some extent. That's it. more or less, I think. Yep.

Kamil Salakhiev: Do you want to address some questions from chat, maybe? I think…

Csaba Kiraly: Absolutely.

Kamil Salakhiev: Yeah, I think, Raul, you were talking about this push-pull phase transition when you were saying that We have same thing in ETP2P broadcast. What's something?

Raúl Kripalani: Yeah, a lot of… a lot of this is already implemented in EP2P broadcast, and EP2BP broadcast is, specifically designed to be able to inject a nil coder, so literally you could just run this on top of EP2BP. Even if we ship it originally in… sorry, I mean, EP2BP, yeah, even if we, like, it originally ships in… as in Libby2P kind of, like, mechanism. on top of, like, B2BP rails or whatever, the simulations and kind of, like, the work, and… and I think the… that's… that's, like… there's a lot of this that has already been implemented, and it's been tested, and it's been benchmarked, and so on. So I feel like, ideally, we would not be, like, we would be kind of, like, you know, perhaps aligning a little bit more, and inventorizing.

But… but that's… that's totally fine. I'm happy to give a presentation specifically on this, and how ETHP2P has… like, how the chunking works, and how the preamble works, and how this, like, the parameters that are broadcast, and, like, the threshold. Specifically, what ETHP2P does is, you can configure a threshold, at which point, peers will start gossiping. And originally, kind of like, it's a two-phase protocol. It's like this diverged face and converge phase. In the diverge phase, peers are just chaotically dispatching chunks around, which in the case of this protocol that Caba presented, that you presented, Caba would not be coded chunks, would just be, the raw data. And then at one point, every peer locally decides when it begins, transmitting

That metadata and that gossip about their availability and what they request, and that is kind of like the converge phase. This is… I also posted a link to NetVis. We… like, there's extensive tooling here that we can actually use to visualize this protocol live, including gossip Sub, because gossip Sub has been instrumented, so we can actually look at and kind of, like. see what is the intuition, because it's great to see, like… in my… in, like, my work, personally, kind of, like, it's great to see the aggregator stats, but I personally, like, you know, feel it a lot more and kind of, like, get better intuition about, like, the edge cases and the tails and so on, once I start seeing

Like, how the graph arranges and the diffusion graph arranges under, like, different parameters and so on. We also did have a fuzzer, but, like, by the way, all of this work was kind of, like, a little bit interrupted when I left the foundation, but I'm really resuming it now, so that's why I'm, like, available if we want to connect again on this topic. There's also a fuzzer that is constantly in the background. I think it might still be active, actually. It's not public yet, because it's kind of still running. We kind of got interrupted. when I left, as I said, but… but that's a fuzzer, that's constantly fuzzing the parameter space and giving you results, and then those… the idea was to aggregate those results in a continuous basis, and over time accumulate, like, really good intuition of what parameters make sense.

And the simulations that we have conducted here are up until, I think, 2,000 nodes? 4,000 nodes, I think there were, in a shadow simulation. So it's… can be a very realistic, profile of the Ethereum mainnet. But yeah, just putting it out there. I know, I'm happy to, like, give another specific, like, presentation on, like, all of the inventory of stuff that, you know, we as, like, a peer-to-peer community can use.

Csaba Kiraly: Yeah, I think the… One thing that we should do is kind of compare these odds between frameworks. as a, as a sanity check. Then on the, on the, on the mechanics, I think we are, we are kind of aligned, so, I'm in the phase transition, I'm doing it as a transition, so I'm doing a smooth transition from, from push to pull. That was kind of the one I was lighting up in the… when I was publishing the PPPT, so I… I stick to that. But it can be a sharp transition as well, like, it's not that, I don't have any theoretical results or ideas to say one is better than the other,

Raúl Kripalani: And you said a shared trans… a shared transition?

Csaba Kiraly: So you have the two phases?

Raúl Kripalani: Bright, yeah.

Csaba Kiraly: In the, in the…

Raúl Kripalani: Are there… are they network-wide transitions, or are they local transitions?

Csaba Kiraly: So, so, if you check my post that I was playing. Is the idea of, of making, a continuous transition. Also, because… Yeah. It's not easy to have an indicator for that. But many politicals in the… due to health transition.

Raúl Kripalani: But yeah, it's gonna… yeah, it's, like, my intuition, at least what I saw when I worked with this, is, it smooths out over the network, so even if every peer locally has a particular threshold, because they receive chunks at different points in time, and they receive different chunks, because the first phase is designed to be stochastic, right? Then, like, they all will try… like, it will smoothen out in the network. So it's not going to be, like, an abrupt thing, But yeah, that was kind of, like, what I observed. The other thing…

Csaba Kiraly: The difference is that you need a transition, It should be based on local inflammation, and

Raúl Kripalani: Yeah, exactly.

Csaba Kiraly: And then you need a transition function, which can be a…

Raúl Kripalani: Yeah, number of chunks received, yeah.

Csaba Kiraly: Yeah, it's gonna be a step further.

Raúl Kripalani: Yeah, exactly, it could be you. Exactly, exactly.

Csaba Kiraly: Thanks, Pace quite a lot, I think.

Raúl Kripalani: The other thing that… I thought a lot about as well, and that it's already in… I think some ideas are implemented in EP2B, in case you want to take a look, is the parking of unauthenticat- or, chunks that we cannot yet authenticate because of the race condition that happens in the network. The idea is that, obviously, there's kind of, like, the top-level object that initiates the broadcast of a payload is the block the consensus block. Without that, you can't validate anything that comes in, because that's what contains the bit. So basically, this feeds into it, and in the meantime, you can park, like, a number of chunks and… or… kind of, like, decide what you do with that. And also, there's, like, some good heuristics that you can apply to, like, decide whether these chunks are possibly valid, and kind of, like, you know, classify them into, like.

Probably good, and, like, definitely bad, so…

Csaba Kiraly: Yeah, but that's where we should be very careful, actually, because that's… well, we have an attack surface, potentially. I think we can easily solve it, but that's where I was also with this kind of policy. So I was starting from the, you know, let's change little kind of things, where two messages are traveling on two different topics. But I was playing with the idea and exploring the, colluting, basically, of the two topics, because that, that allows me, if they are telling them… that allows me to install policies like the one I was describing, so that I should know that you have the… the gate, and I can only push to you, so I can only…

send larger amount of data, a whole segment, and in my case, it was set to be 32 kilobytes, if I know that. And if I push without that. I'm violating protocol, and you can drop me.

Raúl Kripalani: Yeah, right, yeah.

Csaba Kiraly: That's a powerful talent, basically, because without that, until you can push, you can't respond by these pushes, and…

Raúl Kripalani: Yeah, definitely. Just one more consideration that I think, like, as probably, like, some of this work on top of B2BP kind of, like, you know, goes further, I think one thing that will be noticed is the scheduling of chunks and the network, like, the mapping to kind of, like, the stream architecture is really important here. So, what ETHP2P does is it dispatches every chunk as a stream, as an independent stream, which also allows us to Interrupt chunks Or reject chunks without consuming them in the application, because of the way that the chunk is, like, laid out, and the data model of the chunk. There's also a header, so you can inspect the header, decide, do I still want this chunk as a receiver? And if not, just dispose of the stream, which just at the quick stack, wouldn't say…

even at the OS level, it would just, like, dispose of that frame. So that's one thing, and it's really beneficial, and it also, like, this particular mapping to stream architecture allows us to, like, be a lot smarter when we, like, are dealing with races, of when we're sending a chunk to a peer that then, like. simultaneously tells us that they already have it. This was, like, really traditionally really difficult in gossip sub, just because of, you know, the stream architecture, and it becomes way simpler once you… once you have per, per chunk streams, ethereal streams. And Quick makes that, like, free. It's not even cheap, it's free.

Csaba Kiraly: Yeah, yeah. Yeah.

Raúl Kripalani: Oops. But anyway…

Csaba Kiraly: One thing I have is the… so I have the structured ID, so that… so that you can interpret the,

Raúl Kripalani: Yup. Yeah, that's good, yeah.

Csaba Kiraly: That's kind of neat.

Raúl Kripalani: Oh, another thing we, we discussed, just, kind of, like, maybe to, to, to wrap at least my… my thoughts here, is the authentication scheme, so… and I actually… there's… there were, like, I think the Merkel, route was kind of, like, the preferred in the last… the last time we chatted. This would be, like, very easily… I think we have an EP2P right now, kind of like a global hash, and that's it, a hash of the chunk or a list of hash, something stupid, because it can be replaced, very easily. But yeah, the Merk path can be very easy to implement as well, so that would be a small addition to EP2B, but it's kind of like that part is… is just pluggable as well, so…

Csaba Kiraly: I have the medical implemented, but, it's like…

Raúl Kripalani: Yes.

Csaba Kiraly: It's, it's a placement, it's, like, for the other, I have it implemented with a, with a baseline. Yeah. Not the fast one. So, that's enough. Yes.

Raúl Kripalani: By the way, if you wanna… if you wanna experiment with EP2P, I'm very happy to onboard anybody. I know that I haven't, like, you know, things came happening at a very weird sequence, and, like, some of the work got interrupted, so I'm very happy to kind of, like, now that I'm resuming, to… to, like, give… A long session, or a context transfer to anybody that wants to collaborate as well on this.

Csaba Kiraly: Yeah, I think we… we should need… we should do this… this kind of close… Implementation. I… brainstorming. So I was… as I said, I was… I was doing a lot of close… close…

Raúl Kripalani: Yeah.

Csaba Kiraly: posting features from… from one to the other. I implemented it in… in… in normal one, and then I posted it to the… to the partial messages. with this transition, I had it on paper, then I printed one, then I figured out I needed it in the other one, and then just, just this.

Raúl Kripalani: Yep.

Csaba Kiraly: The other techniques transfer, the code as well.

Kamil Salakhiev: Okay, nice, yeah, if that's so, yeah, let's proceed with the next topic. Thanks a lot, Caba. I think you've been talking for almost an hour or so. Good work. Yeah, let's… so yeah, I just wanted briefly to bring up the EIP. It basically covers what? Caba just, presented, just let me try to… Yep. Oh, sorry. Oh, where is that? Where did it disappear? You can see them. Give me a second, I have this thing going, which really struggles things. Yep, can you see it now?

Yeah, great. So yeah, basically… Yeah, we're discussing that in one form or another for a very long time, but in the end of the day, we need to ship it somehow. So yeah, we basically started these discussions Well, I started, I mean, there was a proposal, as you know. to distribute blocks using some pure DAS machinery. Initially, we purified it to just be a part of Blocks in blobs proposal. We went through a lot of iterations just to, like, how to… just address some concerns, for example, like, not to do this kzidil proving on a critical path, and… yeah, just not to introduce too much complexities with, like, subscribing to all, dedicated common topics, even, like, with using partial messages. So, yeah, the idea is… and we will discuss politics, I think, tomorrow on ACD call, but yeah, just to have something concrete on top of which we can iterate.

Yeah, we decided just to submit this EIP, and propose to PFI for Hegota, kind of replace this already PFI proposal for blobs and blobs, and yeah, if ACD kind of allows us to do that, because, like, the deadline already passed, yeah, we'll do this. It's basically… it's… the EIP itself is kind of simple. The main idea is just, yeah, replace the execution payload topic with the execution payload chunks topic, where we're just basically segmenting the payload and distributing the chunks instead of the full message, and we're kind of gaining all these advantages that Cabo just presented. all this pipelining, and other stuff, so… But to be concrete here, yeah, I just listed some parameters, for example, like, we're splitting into 64 chunks. I chose 64 just because it's kind of the number that we have in pure DAS.

And in the future, like, if we would like to maybe iterate and Yeah, I should say, like, there is no error coding here, we are not, like, extending the message. Again, for simplicity, but I left it in open questions that, yeah, we might consider that. So anyways, so 64, just a number that we have in PIR DAS, and yeah, if we just want to iterate, yeah, I think it would be convenient. Then there will be some changes needed, as already Caba described, and yeah, we discussed before. Yeah, we're kind of extending the payload bid by introducing payload chunk's root, field. Yeah, we do that so that we, like, whenever we receive a chunk, we're actually able to…

Yeah, just, assuming we already have the bid, the signed bit, yeah, we can just, yeah, verify the Merco pass, which should be very cheap. And… yeah. By the way, yeah, we will… I will extend this EIP, I think, today, maybe early tomorrow. Yeah, there is a suggestion, and yeah, things already described, I think, by Caba briefly, like. Just to… Yeah, like, how… just addressing some cases, like, for example, when we receive chunks before we receive the bid. And, yeah, in that case, I think for today, like, when we execute… when we receive the execution payload, if I'm not mistaken, we just, do not propagate it, but we put it in a queue, and once we actually receive the bid… yeah, the Beacon block containing the bid, yeah, we kind of, like, consider this,

payload to be valid, and then, yeah, we actually can propagate it. That's… if I'm not mistaken, Prysma Lighthouse doing that. So basically, there would be the same logic, so we can basically just, yeah, if we receive a chunk, but we did not receive, like, some confirmations that this chunk is correct. I mean, like, we do not have the signed roots, so that means we didn't either receive the bid, or we can block containing the bid, and then, yeah, we just do not propagate them. Yeah, I will extend this EIP a bit later today. Yeah, the builder chunk method itself… will look like that. Yeah, in addition, there will be maybe a payload chunk route, yeah, it's not there, but it should appear later today. Just so that, yeah, we can verify the Pablo against the bid that we received previously.

Yeah, anything interesting here? I think, yeah, it's pretty straightforward. Yeah, we just contain… it contains the data itself, yeah, the index of the chunk, and inclusion proof, as well as the slot, and yeah. The BeaconBlock route. And, yeah, by the way, yeah, we are not, like, segmenting the only execution payload itself, but we're actually segmenting the execution payload envelope message, because, like, yeah, that's what goes into the execution payload topic today. It contains execution payload itself, plus, I think, execution requests and some other fields. And we'll need to modify the structure by removing, for example, BeaconBlockRoot, because well, at the moment. Because, yeah, we have this BeaconBlock root in the payload chunk, and yeah, in order to compute the payload chunk's root.

Yeah. It would kinda need to be… Well, I mean, yeah, the problem is, yeah, we might not be aware of BeaconBlockRoot at the moment. when we… Oh, yeah, I need to… I'm always, like, need to refresh myself about this chain of thoughts. But yeah, basically, at the moment of chunking the execution payload envelope, we might not be aware of the beacon block route. Because, like, the Beacon lock itself, like, we… the builder, did not observe it yet. So, yeah, we kind of need to remove this, field there, and… but it's fine, I mean, because, like, yeah, we… anyway, we'll attach it to, below chunk. Later. Yeah, basically, that's the EIP. Yeah, feel free to go and read it.

And, yeah, that sounds… Yeah, that's basically it. On top of that, yeah, as I said, like, the EIP itself is pretty simple. Actually, a few optimization strategies, for example, that Caba described, like, maybe push-pull phase transition, and some other stuff, like batching, yeah, I think we can… they could be just some kind of implementation details. So the protocol itself, could be as described. For example, in EIP, then, yeah, we can iterate on top of that, or just clients can iterate that, because this is not a consensus change, they can… yeah, so we can work on that. In parallel, so I don't think there should be an issue with that. Yeah, I think that's all I wanted to cover.

I see a bunch of discussions going…

Csaba Kiraly: Yeah, for the EIP, I think the main thing we need is the bid. Which is… which buys our life a lot, because… it just does.

Kamil Salakhiev: Yeah, ideally, if we had this bit change already in gloss, yeah, we would be able to, actually. start iterating that, or, I mean, start implementing that even, like, in parallel, without requiring any consens change. But yeah, then we kind of end up with mixed network situation, where, like, some peers they support. The segmented broadcast and others don't. So yeah, it's go- it's both… I don't know, maybe good and bad, yeah, anyways. At the end of the day, I think the cleanest solution is just have this EIP PFI'd, and then, yeah, considered for Hoodi. So, yeah. Let me just quickly go through some discussions, if I need to comment on something… Yeah. Yes, that's it. Yeah.

Yeah, in theory, it could be soup, by the way, yeah, exactly, like, maybe… Without, yeah, we can think about it, Like, if we decide to, like, for example, if it's not… PFI for Hegota, yeah, in theory, yeah… Yeah, we couldn't implement it, maybe, anyways, without… consensus change, it would be a bit more complicated, I think, and maybe, mmm… Yeah, so each chunk would need to… Contain the signature… For example.

Csaba Kiraly: Yeah, we can find ways, but it remains more attackable, I think, so at least… this is what I kind of arrive to, that, that the attack surface… So, basically, the buffering, that you have to do is more, because you have You missed that… that link. Yeah.

Kamil Salakhiev: In theory, I think it might work, and some peers, they, for example, they support segmented broadcasts, and others don't, and those who support, they can help others to kind of get the… once they, for example, reconstructed the payload, they just, yeah, propagate it to the payload topic.

Csaba Kiraly: We can… we could do… we could do the mixed mode, I think, and we could do it without the bid, change. Both of them would be… bad choices from the… from ACD, I think, in the sense that they would complicate and, and, implementation and… and make, the… It's less sufficient, and… Yeah, just… just less resistant for… For some reasons. Yep.

Kamil Salakhiev: Yeah, cool. Anyways, if no other questions here, we'll… bring this up tomorrow as well. We'll discuss less technical stuff and more politics, I believe, so… So yeah, let's leave politics for tomorrow. Good, yeah. So, if no other comments or questions, yeah, Raul, we can… yeah. forward with your presentation at EPIPI Progress.

Raúl Kripalani: Oh, do you see my… do you see my screen?

Csaba Kiraly: Yep.

Kamil Salakhiev: Yes.

Raúl Kripalani: Okay, cool. Alright, so I wanted to… I want to start integrating… well, I already started, but I want to integrate ETB into clients so that we can run DevNets, and we can run simulations with Prysm, for example, which is, you know. the thing… the most accessible one, given that ETH P2P is currently implemented in Go, but I… I'm a Rust person, so I would be very happy to implement it in Rust as well, with the help of my agents. So, the… what I wanted to present today was how we're going to make this happen. The key… the key point here is… well, it's… it's a design, so I'm very happy to, like, take… take input, and… and see, like, what other considerations I haven't thought about here. But basically, the idea is, given that the EL has already standardized on QUIC, and that

I think all clients by now are supporting QUIC, hopefully. At least, I know that the major wants to. the question is, how can we take a single quick endpoint and actually use it across EIP2P and BebP2P, and what is the stream dispatch policy, and kind of, like, what is the… Lifecycle policy for things like, for example, opening a transport or dialing, where does the stack need to behave depending on where the dial comes from, and so on. The design is actually really simple, and it is quite, I think, quite elegant. it is… it does have a few, kind of, like, cases that we need to consider, so… and I put this very, like, quickly to get… put this together very quickly.

So, I'm happy to kind of, like, after we've… I finalized this design, to kind of, like, give another… another update. But basically, the design targets for how we're going to do this is, first of all, we want to use a single quick transfer and endpoint for both, EIP2P and EIP2P. We want to make sure that every connection that arrives or that we make, through that transport can serve both ETH B2B2P and ETH B2P streams. We want to make sure that we remain fully backwards compatible, so that EIP2Bonly peers notice nothing, absolutely nothing. And we want to make sure that it's non-invasive for existing CL code, or, like, minimally and contained at specifically the networking layer and nothing else, right? So it shouldn't percolate back up into the application. So…

just to kind of give you an overview of how, for example, Prysm enables quick today, so we all know there's a host in the B2B that is fed options, and if enable QUIC, which is a flag in… a configuration flag if Prysm is enabled, which by default is true. then it adds the transport. Now, if you notice, qua… Prysm is never constructing the quick transport, and that is what needs to change here. So, what we need to do is, the application needs to own the transport and then inject it into both LIPI2P and ETHP2P. And we can add sugar so that it's, like, very, very simple, but kind of like the… the mechanics would be something like this. So, you have… this is ETHP2P, by the way, so this, you call… is already implemented, you get

the… you call newShared on the transport, with the node key, and so on, and the connection that you've already created, and then from the shared. transport, you take the ETH P2P view. And that you would pass through EP2P. And then you take the lip E2P view, which is, somewhere around here, because the code is a little bit verbose. Yeah, here. Should have probably put it in a variable at the top so it was easier to follow. You take that, and you use this lent transport. In the case of GoLIPI2P, the… there is… This option that already allows the application to inject a transport into the quick transport through this, like, weird, quick reuse thing. That exists, and it's a little bit unergonomic to use. If this bothers us, we can change it. But there's only, like, one tiny patch needed, which is already sitting in this branch. I haven't opened a PR for it, because it is…

built on the version of GoPTP that Prysm uses today. which is no longer, like, what exists on master and go B2BP, so it's… I don't think anybody's gonna care about this, but I can submit a patch, and I don't… I can't remember if there's a release like, a release branch for this lineage, or this… this… this old release, so I wouldn't know what the target would be of that PR. So it's just currently sitting, sitting there. And then, from the transport weekend, like, ETP2P can already, like, accept and dial, so… Now, how… what does this do behind the scenes? It solves the problem of… We can't just take a single quick transport and just give that raw transport to both stacks, because they're gonna collide and they're gonna conflict when they're listening, because they will both try to listen for connections, and then for every connection, they will try to accept streams.

So they're… they're gonna conflict, and they're gonna race with one another. So what we need to do is, we need to identify the capabilities of the remote host. And, route incoming streams to the right listener when we get incoming streams, right? So, just to kind of, like, set the stage for how this works, and this, like, dispatching, and routing works, it's actually very simple, and it's based on… on a few… on a few facts that all come together. So, first of all, every ETP2P peer will also be a B2P peer. It's an Ethereum client. Therefore, at the time that parts of EIP2P begin to be adopted, lipid will still be there, right? So, it's not like it's gonna be a swap, it's gonna be a progressive… it would be a progressive upgrade, right?

So, both… so an ETH P2P peer will also be a P2P peer. a legacy B2Bonly peer will never advertise ETH B2B, so we know that it's legacy. Now, the LIPI2P handshake is pretty… the TLS handshake is pretty straightforward, and it's very easy to extract. It's a single file. I've extracted it into a single file, so it's very easy. And, the idea… well, this should not go here, this is part of the design, but the, the other fact is that Libby2P does not support unidirectional streams. And it doesn't have any API at the B2BP level to do that. All streams are bi-directional. And in quick. streams… the directionality of the stream is determined, or is signaled, by the ID of the stream.

So you apply a bit mask, and you know what kind of stream it is, and the Golet B2BP does this for you. QuickGo does this for you, so you don't need to do any of this parsing. But the point is that we know that if a unidirectional stream arrives, we know it's for EIP, but we don't want to depend only on that. Because, even though EP2P today only uses a unidirectional stream to prevent the… to deal with the simultaneous open problem at the stream level, But we don't want to deal with that. Like, we don't want to rely only on that. The most robust way is to actually peek at the first byte of every stream.

And they're gonna be structured exactly this way. So with… for libi2P, we're gonna have a UVARINT, which is a length-limited prefix pull-up protocol selector, and then after that, the next… the next byte is gonna be a slash, because that's how multi-stream select protocols, start. So then what we do is we reserve this character and say, well, the first effective payload, or the first effective byte of a stream, is a slash. then we know it's lip, and the slash is reserved, so it can never be used in a neat P2P. So that is at the… at the stream level, at the stream dispatching level. The other thing that we need to know is whether the other party supports… if we are an EF P2P peer, does the other party support, support EF P2P or not?

So with that, we're using, basically in the TLS 1.3 handshake, we advertise a new ELPN, We put it first, so that it takes precedence in the negotiation. And, both quick endpoints will agree on the first shared ALPM. So, if they both support ETH P2P, then that would be… A peer link, basically, that supports both stacks. if the… if we settle on Libby2P, then we know that we're just… it's just Libby2P, so… In the case of… in this one, in this case, in theIPI2P case, we take the raw quick connection and just get it to lip E2P, that's the end of it. In the case that we agree on ETHB2P, then we split the connection into two views.

So, we split it into the ETH P2P view, which will handle only ETH P2P streams. by the EF B2BP stack, And into the E2P view. which is then given to the B2B, And it, it is managed by the B2BP stack. So, just kind of, like, recapping, that's… The… the capability discovery? The other thing is the stream routing. So, already kind of, like, went through this, but… This is basically… What it looks like, so we look at the direction, if it's unidirectional, then we know it's EP2P. If it's bi-directional, then we evaluate, is it lip B2P or EP2P? If it contains the… if it starts with a slash after the U variant. And, yeah, this is how it all looks together. It is very simple in terms of code.

As I said, the slash is reserved, it's a reserved character, and then the… the… So this is kind of, like, when it… this is… describes… what I've described so far is the connection management, so the connection creation, right? Listening a connection, and listening for a stream, right? So these are the list… what I've described are kind of, like, the listening side, the inbound side. And I wanted to go through some other things that we need to make… that we need to do, to make sure that the whole solution is sound. So… on one end, The listening, the management of the life cycle of the listener. the Transport Listen. is gonna be called by both sides, so Libby2P will get a quick transport, and then it will call listen on that transport, it will get a quick listener, and then it will start listening for streams. I don't know if rust does something similar, and what the rust

do, but this is kind of, like, the thing that I'm familiar with, and it can be used kind of, like, as a point of reference. So, the idea here is… As soon as you get the first listen from one end. The shared transport is going to return an immediate listener, but it only begins actually listening on the underlying quick connection when both of them have attached, so that none… no side actually misses. any… any… any connections, any internet connections that might be for them. That's the way we remove The… the race, right? On the other side, we need to think about dials. So, both stacks are gonna dial. If Libby2P is dialing. then we're gonna do a handshake, we're gonna learn if the other party supports ETH B2B. If it does, we deliver the connection to both stacks.

If ETHP2P is dialing, this is the interesting case, because ETHP2P wants to establish a connection with a peer, and the peer… say the peer supports ETH P2P, we just split the connection, and we get the… we do the same thing, as here, we give it to the P2P, and also to ETHP2P. But if the peer does not support EF B2BP, we have an opportunity. we can still deliver the raw B2P connection, given that we've gone through the handshake, and we've established a connection, we can offer it to the B2P side. But, so far, I've implemented it as only best effort, so if the Libby2P side is backlogged, it will… we simply drop it, and that's it. Nothing happened.

Right? What do we do on connection close? Both of these tags can… might want to close their… their connection. So, closing only one side leaves the other one alive. And this is not implemented yet, but it's an idea. we could send an advisory to EP2P. We cannot do this with EIP2P, because, as we said, we want to… we don't wanna… don't wanna break APIs or impose new… new, requirements to clients. We want it to be completely transparent. So, but EP2P can get an advisory of, hey, this connection, It might, like, might be deprioritized or something like that, and then it can decide what it does. well, it can ask the application what it does, because that's the point of ETH B2BP as a design principle. It's not autonomous. It is always delegating to the application.

And, yeah, so the connection… otherwise, the connection closes when both views are released, on the connection. And then the last gauge that we need to think about is what happens when listener… listener close. So, you got a listener from Transport Listen, and now you close it. So, what we've… what I decided here, after kind of, like, playing with different designs, is that I'm going to take the simplest path. And that is, I'm gonna make… a listen from GoP2P. Sorry, from EIPIP. illegal, a close… illegal, and also from EFP to B. Why? Because… A… closing a listener. is not done dynamically. It is done… it is part of the client life cycle. Right? So, when a client is staring down, is shutting down, it's going to tear down all its services, and one of them is going to be networking, probably the first one that it turns down, that it, that it tears down.

So, the client actually controls the sequence, the shutdown sequence. So, what the client can do is just simply close the shared transport, And only then. send a close to the B2B and to EF B2B. Who will then go and close their listeners, and it's all clean. The other alternative added, in my opinion, a lot of complexity, because… and we have to think about, like, if you allow this, then the listener could be half closed, we need to detach the queue from the listener, and then… Like, you need to deal with, I've announced this capability, two other peers, peers are expecting something of me, but I'm really not listening. It just doesn't make sense, because it's never going to happen in reality at runtime, that you only want to close one part without closing the other. Or, also, what cannot happen, and what is not going to happen in reality.

is a re-listen. There's no… as far as I know, there is no… happening inside a ETH client, or any, like, circumstance, where they would want to close a listener, and then reopen it later. it just simply… simply doesn't… as far as I know, I'm not… I'm not aware, so… so let me know if, like, you know, if… if I… If I've got wrong information here, because that would be… that would be valuable. And finally, ideally, eventually, the transport, the connection, and the handshakes should… should also be shared with the EL. The EL has this, in the Deputy REPL, there is this effort to also standardize QUIC as a… or to introduce support for QUIC. The handshake works a little different there, because the EL wants to support, web transport connections, so, in some

And, and the… and the… and the extension, so the X509 extension that Libby2B uses to certify the peer's identity, to send a peer ID certificate, or to send a peer pump key certificate. Is not something that a… browser that a website could read, so it kind of, like. Yeah, it becomes a little bit tricky there, so they… they've gone a different way, and they are exchanging the peer certificate as a requirement on the first screen that each side opens, which I think is valid. But we just need to, like, figure out a compatibility, here, a compatibility path here, because LibI2P is, It's like, suddenly it's, like, doing the handshake this way. I think, the other thing that I was a little bit worried about is that…

with that approach is that it kind of, like, creates some weird states when it comes to quick resumption or connection resumption. So you might have exchanged a token, but then your certificate might change if your ENR… like, if your peer ID rotates, or something like that. Yeah, it becomes… it becomes a little bit tricky, so then you don't know what to do with a resumption token if you preserve it or you don't. Yeah, it's just kind of like some match cases that we need to think about. But yeah, it would be nice to converge efforts here. And that's… all from my side. I do want to say that I do have a branch, that I need to, like, continue working on for…

integrating EFP2P into Prysm, broadcast into Prysm. As far as I know, I think DevNet is working. For payload broadcast, it's already hooked into Glamsterdam, payload broadcast. So yeah, so yeah, so we could start testing this in a DevNet. And then, perhaps the other thing that I wanted to show… Like, something I've been putting together. CFI. Yeah. So, let me share my other screen, and I know that we're over, so bear with me, it's just one minute. I hope you're gonna like this. Right, so one thing has become apparent, and we have a lot of networking specs, and they're dispersed in a lot of places. So there's the W2P REPL, there is the Consensus specs, where the networking piece is in this fork-based

Incremental, kind of, like, thing, format. There are EIPs, there's… it's kind of, like, spread out in a number of places, so… what I wanted to do a while ago, and Felix and I aligned on this, was to create a single Single… a single site to view all of these specs, and we know that, you know, we're not going to shift specs to a single repo. Ideally, we would be having a unified repo, so there's the idea of creating networking specs as a unified repo, the… But we know we're not going to move content immediately, So the… so we can solve this with… At the app level. So the idea here is we create pages. Where we aggregate content from other sources, and we very clearly indicate, like, what content is aggregated from what source, and so on, so that we can view everything in a single place, and we can reason about the stack, about the whole stack in a single place.

And then, for specs, like, for example, EIP2P for newer specs, like EIP2P, and, Waggle, and, like, you know, Caba's broadcast, work as well, we can directly submit it and just incubate it inside the network specs repo, and just kind of, like, this can be our unified place to. evolve the networking stack of Ethereum as kind of like, you know, yes, two… two stacks that ideally, hopefully, should convert in the future, but the first step for that is kind of like, we need to start viewing these things as a single body, and not as kind of like, yeah, it's the rep over there, and another rep over there, and it's, like, super fragmented. I think the first step, towards, like, eventually unifying these things is to kind of, like, unify where they sit, and hopefully this is an… this is an effort, like, that… that people will like, in doing that.

This is… still, like, I haven't published it because I need to work on the content and kind of, like, the sources and everything, but the idea is that you can view the entirety of the networking protocols here. I deliberately didn't, like, strongly separate between execution and consensus. it's kind of, like, all one… one thing, it's not, like, top-level separation, but I did add filters. So if you do, for example, if you go into execution, then you'll see the stuff that is only relevant to execution. And similarly with Consensus. For some things, like, for example, that are cross-layer. I actually just, like, my preference was to just kind of, like. for us to be able to understand the whole flow of how things are actually moving through the… through the network, through the Ethereum network, no matter which stack it is, it's great to kind of, like, have just a page and a section on data availability, and all of the… like, all of the objects.

regardless of where they sit, and then the content itself can tell you. So this is kind of, like, the top-level classification. The top-level taxonomy. So you would be having fundamentals here, with kind of like, you know, the basics that are shared between both both pieces… both parts, then a definition of the… of the stacks, right? There's a bug there. Reopened my closed nodes on the tree. The… Yeah, the definition of a stack, and the fundamentals of each stack, and so on. And then I deliberately separated protocols from features. And this might be a little bit controversial, but… For example, gossip should be defined first, or in my opinion, should be defined first as a protocol.

And then, you should be having objects, Right? that are… Handled by the Ethereum protocol. with the exact flow, that then kind of, like, references and says, this flows over Gossip Sub, and this is the topic definition, and, like, whatever, right? So… so yeah, I've separated these things. I'm very happy to take feedback. This was kind of, like, a first flush, and… well, not flush, first flush, this has been, like, the third version of, like, how I wanted to, like, I've pivoted a bunch of times on, like, what the taxonomy should be here, but this is what I eventually ended up, like, really liking as I saw it, kind of, like, you know, take form. So yeah, very curious about, like, first… first thought.

This is unreleased yet, so hopefully I'll release it this week, and people can start paying with a B0 of this. But yeah, very curious for first thoughts, if people are still… Still a week.

Kamil Salakhiev: Yeah, nice. Thanks, Raul. Yeah, maybe you can start by addressing some questions from chat. I see Anton is asking if we can just upgrade EIP to what if PTP provides? G… U direction, you need the rooms…

Raúl Kripalani: Yeah, no, I mean, that's one… one thing. So, ETP2P is quite native, so it does not put any abstractions in between… in the middle. So it basically… you can get, like, all of the congestion control stats, and you can decide to route smartly Across… across peers. You get datagrams as well, which Libby2B does not expose. Of course, it can be exposed, but this, like, that's the problem. It's a lot of work to, like, you know, for a feature that only Ethereum needs, if you need to snake it through, now, all of the Libby2B implementations, right? So, it does not expose datagrams, which, you know, are very nice, for example, for attestations. And… so that's at the transport level, right?

at the… there's more, right? There is, zero RTT, which Libby2BP does not trans… also exposed nicely. We can add these things in the B2B, but the question is, do you want to work on B2B, or do we want to work on Ethereum networking, right? Because, like, we anyway need to… add these to the transport support. So if now we need to add it to a transport support, and then also to, like, another layer, and then we need to, like, come to consensus in another community about that, when it's just us that need… that needs this, then, like, you know, is it a good Good, investment of time, that's kind of, like, the thinking. So, yeah, zero RTT, session presumption is really nice. You can, like, discover all peers.

all peers in the network, handshake with them, and then save a resumption token, and then send a message to that peer without having to renegotiate or re-handhake. That's really nice, and it's very nice for, like, things like when you become a builder, when you… sorry, when you're the builder, when you're a proposer, like. when there comes a time where you need to, like, really fan out to a lot of peers, then you… like, you want to do it on the spot at that moment. There's a lot of flexibility once you start using what Quick gives you without it being blocked by, like, this middle layer, right? And then there is, the whole set of, like, discovery, and peering side of things as well, and protocol awareness, so the idea is that you, as a client, you tell ETH B2B

When a slot starts and when a slot ends, and then all of the object propagation that happens within a slot. Just like all of the caches are cleared at that point in time, when the slot ends, because this propagation is no longer relevant, there is… when the SLOD ends, right, then you fall back to RPCs if you need to fetch that data. So… That's kind of, like, you know, this session… this, like, time window demarcation, right? Is… is a… and then the scoping of things under it. It's kind of, like, really valuable for a… Protocol to have. which Libby2B doesn't give you, and, like, we've had many problems with caches in the past, and lifetime of caches, and, like, repropagation. We just had… like, Prysm took, like, 6 months to resolve something like that in… in… when attestation- when aggregates were bleeding through from one slot to another, right? And that's because you…

It's, like, yeah, a window, you configure it for 30 seconds, right? And, like, you're still bleeding through to the next slot. So that's another thing, the discovery as well, and the discovery view. So you discover very rapidly all peers in the network, and then, like, save assumption tokens for them, and then connect when you need to change your attestation, your ad nets, and so on, very quickly. Like, there's a lot. I'm happy to give another presentation. I think you might have missed Anton the… the, the 3-hour session that we had in Svalbard. So that could have been useful, but I'm happy to give a dedicated presentation of this. more, like, on… on this, I know it's, like, very dense, because it's kind of like a feature dump, and, like, you look at that, and it's like, holy crap, that's… there's a lot to build here, but really, it's not… it's not that…

And my view is, like, really not that complicated. Yeah, Dataground Streams, the PR for it, yeah. Since when? That PR? Yeah, a year ago. I mean, if somebody wants to push that through in the B2B, be my guest. Like, I… you know? happy to do that, and then, like, get all other implementations, you know, in line with that, and then, like, figure out how you want to use it, but I think it's… Honestly, I think… I think it's… I'd rather focus on what Ethereum needs than on kind of, like, you know, exposing APIs through, like, middle layers. But there's many other things, like multi-path as well, but, once you… once you get access to… to the… to the connection, it's… like, that's just so much.

Quicken itself is… is… is a very nice… Protocol suite, honestly.

Kamil Salakhiev: Okay… Yannis, anything else? Any other questions? The book is not… Cool, yeah, nice. Yeah, if nothing else… yeah, let's just… yeah, I guess, yeah, we'll have, like, more discussions in future about that. It's like… I feel like we have many directions, I mean, it's P2P, WAGO, so it's like, you might think, like, whether we want them coexist, whether, like, we prefer one or another, so there will be… I mean, these new protocols, as we… for example, this Sukun attestation protocol, or for example, this segmented broadcast, like. Yeah, considering… they are scheduled for Hegota, like, how exactly they will be implemented, whether we stick to gossip-sub or something new.

Like, yeah, yeah, kind of curious also, like, how… how to eventually… Turns out to be, like, yeah, what exactly we will adopt. Nice.

Raúl Kripalani: Yeah, I mean, I do want to say that my understanding is that Hegota is, like, 15 months out. Is that right?

Kamil Salakhiev: Yeah, somewhere next year, considering… yeah, no one knows exactly when it's to be shipped, but yeah.

Raúl Kripalani: Yeah.

Kamil Salakhiev: Maybe tentatively, maybe third or fourth quarter next year.

Raúl Kripalani: Yeah. The other point that I want to bring up is that a lot of… like, it depends on the clients, but I am… the one that I'm most familiar with is, as I say, Prysm. And Prysm is an interesting one, because it has had to work around a lot of Gole B2BP quirks. by adding its own, like, peer manager, scoring, and so on. So really, it's kind of like already using GoLit P2P as purely the transport, because all of this… some of the… gossip-sub is an exception there, right? But… gossip-sub is, like, we know it's extremely complex for what we need anyway, and, like, we're fighting it all the time. So then the question… and we already specialize in gossip sub for… let's add this mechanism here, because we want attestations to propagate this way, so now, because we're using gossip sub, we need to add this mechanism in gossip sub, and spend a year working on a particular mechanism, right?

Because, like, and make it, like, super andergic, because we need to expose it through this, like, very particular API and way of doing things. I think it's just, honestly, like, you know, having taken a fresh view, like, this was harder for me in the EF. But, like, seeing a fresh view, I think, honestly, it's just… you know that time could be spent on actually building the stuff that really matters. I really want to see a really good reconciliation protocols, because we're talking about Bitmap swapping and, like, you know, bitmap, and kind of, like, pushing and pulling, depending on, you know, presence of particular or advertisement of particular payloads, or partial payloads, and so on. Really, like, what matters there is the reconciliation protocol. It's not so much the format of the bitmap when it's sent. Like, what matters is, like, given

10 peers, and given, like, all of your… your current rate of receive… of receive, right? Your receive rate, your transmit rate to each of these peers, your RTT to each of these peers, what they're sending you, like. is this information outdated? Like, all the speculative of, like, let me… that's what really matters, and I think we're spending the time in the wrong place. When we are, like, you know, working to, like, adapt specific APIs that were pre-existing to, like, the stuff that we need, and nobody else needs, because nobody else is gonna adopt it. Yeah, it's just kind of like, sorry for the rant, it's like, I see us building and building and building on something that, like, you know, is gonna take us a lot of time, because it's proven to take a lot of time to just simply use that, evolve that stack.

I think, like, I… yeah, we should just be thinking bigger, and, like, be a little bit more braver. Yeah. Anyway, I was not… I was not there.

Kamil Salakhiev: Okay. Yeah, excited. Future-like. how eventually, like, look like. Okay, nice, thanks, everyone. If no other questions, yeah, yeah, let's wrap up here, it was almost 2 hours, so thanks to everyone who seated at the end of the… the end of the meeting, so… Cool, yeah, see you in two weeks. Bye.

Pablo Deymo: to you, like.

Csaba Kiraly: Goodbye.

Bosul Mun: Hi, Yanni.

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