P2P Networking Call #9

Transcript

Daniel Knopik: Hello!

Kamil Salakhiev: Hey, hey.

Matthew Keil: I…

Kamil Salakhiev: Yeah, hey, Mason. Yeah, let's wait… For another minute… or two. Happy to see Lodestar folks on the call.

cayman: Hello!

Matthew Keil: Yes, hello. We heard you were you were missing us before. It got back to us from several people that you were like, oh my god.

Kamil Salakhiev: Basically.

Matthew Keil: Lodestar guy, where are they?

Kamil Salakhiev: Yes, yes. Actually prepared something for you, but yeah, maybe show it later. Hope you find it useful. But yeah, not for you, but just for everyone.

Matthew Keil: Cool.

Kamil Salakhiev: Yeah, come more often, and then, yeah, thank you, enjoy it. Okay, good. Let's see… Let me just ping the guys who were supposed to join today. Mmm.

Okay, Yeah, I think… let's just… Yeah, give me another second. Some people weren't subscribing. Okay, good, I think others, yeah, they'll join later. Cool, yeah, nice, and welcome, everyone. I think it's P2P networking call number 9. Yes, so, as usual, yeah, let's just get started with client updates. Yeah, maybe start with, lighthouse.

Daniel Knopik: Yeah, sure. So… Actually, not too much to report. Of course, getting ready for the Sepolia fork yesterday. We are working on and reviewing. internal… Improvements like simplifying on a networking stack a bit. And addressing some… some issues. And finally, we are continuing work on our prototypes for 8411. And. Attestation bundling. Best one, Marco. João, anything to add?

jxs: No, no. Not at the moment.

Kamil Salakhiev: Nice, nice. Yeah, I think we'll… We can… yeah, if time permits, yeah, we'll… We'll try to discuss it for one one today. Yeah, so Also, actually, it would be great to bring this up, in Mumbai. I hope everyone is going to Devcon. So, yeah. Anyways, sorry, just, yeah, let's proceed. Yeah, let's proceed with Prysm updates. Anyone from Prysm? Maybe Ash or something?

ashah: Yeah. Sure, sure. Yeah. So all the partial columns work is merged. We've enabled it by default now for Fulu and Gloas. So, yeah, nothing remains to be done there, just observe how it works out on the… Glamsterdam devnet and be responsive if there are problems. None so far. And on the… on the… you know, last time I mentioned that in Prysm, we are doing a revamp of peer scoring and connectivity and observability of connectivity. So that work has been reviewed and approved. We are soaking it on our mainnet and Hoodi nodes right now. We'll keep soaking it for a week or so before we merge it. Looks good so far, and one of the major wins of that work is a lot more observability with matrix and RPC APIs into

what are the peers we are connected to? What are the bad responses they are sending? Why are their gossip messages getting rejected? How long have they been connected to us? What is their agent type, agent, etc? So, the next step is I'm gonna build a dashboard that Prysm users, you know, can just open to debug connectivity and see what's going on in terms of the PS they are connected to. And yeah, once that's built out. with my superior JS skills, sorry, Claude's superior JS skills, I'll demo it in the next P2P meeting. Yeah, that's it on the P2P side.

Kamil Salakhiev: Yeah, sounds good. Yeah, so Lodestar, do you guys also want to share anything?

Matthew Keil: Sure, made headway on, the P2P in order to get 1.3 in, and, partials will go soon, and then obviously still have some more work in order to bring it into Lodestar. We're not gonna get it turned on until after Gloas is live, though. So, still, that's gonna be the case for us, but we'll… we'll get it done before, you know, or should I say after… After we go live, mainnet.

Kamil Salakhiev: Okay, cool. Thank you. Do we have any other CL clients on the call? Yeah, if not… Yeah Anyone from EL, maybe Geth? I see Felix and Bosul.

Felix Lange: I'm not sure if we have, like, a big update right now. What do you mean?

Kamil Salakhiev: Okay.

Felix Lange: Just… reasonable updates.

Kamil Salakhiev: Yeah.

Felix Lange: Csaba always has updates.

Kamil Salakhiev: Yes.

Csaba Kiraly: Yeah, what? Yeah. I have published a post. I don't know if it was in this period. I think it was in this period. I published a post on the blob pool protection mechanisms that we are using. It's… it's kind of the… you can look at it as the peer scoring that we are using, but it's not a peer scoring. Half of it is already. In Geth, half of it is a PR. So, yeah, post went out on that. Other updates. I think we did a bunch of hardening this cycle. On sparse blob pools and many other things. Yeah, that's it.

Kamil Salakhiev: Okay, Any other EL on the call? Yeah, vlad, if you want to introduce yourself, I actually don't know the context, so I'm sorry. I maybe don't know everyone.

vlad | gattaca: Oh, hi. Yeah, I can introduce myself. Hello, everyone. I'm Vlad. I need to turn my camera on. Hold on. Hi, yeah, so… hello, I'm Vlad, I'm an engineer at Gattaca. We have been doing some work on some of the consensus-layer stuff, because we're interested in block propagation mostly. I don't really have anything to share today, so… I'm just here to, listen in, if that's alright.

Kamil Salakhiev: Yeah, sure, no pressure. Okay. Yes.

vlad | gattaca: Good.

Kamil Salakhiev: Yeah, let's maybe proceed with the agenda. Yeah, just… Briefly, I really wanted to… yeah, I'm not really sure, like, what exactly I wanted to speak about, but yeah, just mention about Sepolia upgrade. And, yeah, I got… I was just curious about doing some of this, X-ray style, networking group kind of profile. Based on, like, this X-ray thing that Raul built, I think, some time ago. Actually found some interesting stuff, maybe, and just wanted to quickly share a few… Don't mind. Give me a second. So, yeah, I think, Yeah, I just asked my agent to build this thing for actually multiple clients, not only for Prysm. thing. But, yeah, basically, this is Sepolia, this is, like, after yesterday's, Glamsterdam upgrade, that's how the bandwidth looks like.

Yeah, just few stuff that was… at least got my attention was that Yeah, maybe I was just understanding it wrongly about the… Yeah, I expected that execution payloads, they would be kind of propagated at some threshold, maybe 3 seconds or later, but yeah, it seems like it's fine, and most clients, they just propagate them right from the beginning of the slot. I mean. It seems like, yeah. as soon as… Builder, just receives the BeaconBlock, yeah, they just propagate without waiting for attestations, although I think it was discussed somewhere that, yeah, they could actually wait for some attestations to arrive, but it seems like this is not what's happening. But this is, again, Sepolia, this is still not Mainnet.

That's one thing. Another thing, yeah, basically, we have this. EIP from Sukun, which, yeah, hopefully gets through to Hegota about bundling attestations, and it actually optimizes attestations protocol, but actually, we… I think it would be great to also consider… I already wrote that to Sukun some time ago, but yeah, it's also, I think, might be interesting to consider applying this for payload, attestation messages as well, because, like, well. We subscribed to… In attestations topics, we subscribe, basically, for, I think, two subnets. And for payload attestations, yeah, I think we subscribe to a single global topic, that means we receive These messages every slot, and I think the mechanics are the same, so… Just maybe applying some partial messages, optimizations, or maybe WAGL, I think. But yeah, things like that to payload attestation messages also might make sense.

Yeah, just something that, yeah, probably we can consider also in future. Yes, sir. Who is… Building on Sepolia? Yeah, I'm not sure, who is building on Sepolia. Yeah, that's a good question. I'm not sure, like, whether we have the full builder pipeline there. I don't see actually much… Oh, actually, yeah, there are execution payload bid traffic there, so… At least… Yeah, the builders, they are not building privately, so they, yeah, there are some bids. Yeah.

Daniel Knopik: Like, I think builder IDs 1 and 3 are Sigma Primes, Bombora, and we are using, you know. Using the opportunity to actually provide some bids.

Kamil Salakhiev: Okay, cool. Yes, so… I did the same… actually, not me, my agent, of course. To build it on top of Lighthouse, but it's not properly configured, I don't know, like… I have this, Beacon Blocks by Range, track. For some reason, maybe it's just syncing. Yeah, which is why I don't want to stop for too long on Lighthouse. I actually did… Same thing for the Lodestar. And yeah, there are some Just stuff that worth attention here. I mean, it's expected, but yeah, since Lodestar doesn't support Partial messages, yeah, just. Yeah, data columns. Yeah, yeah, yeah. Data columns, sidecars, they usually… Yeah, these topics, they receive more bandwidth than… If we compare, for example, to Prysm, yeah, usually it's, like, much less.

But yeah, here we just can, yeah, can observe, like, how much it's… Different. Yeah, for example, if we get the same block, for example, 520… On Prysm, it's, like, 120 kilobytes, and in… Lodestar, it's, like, Okay, yeah, more than… Is it megabyte? Wow. Yeah, so, like, 10 times larger. Yeah, just, flagging that. And one more thing that I wanted to share… I'm just feeling that I'm doing Apple presentation with one meeting. Sir, give me a second. Mmm. Where is that? Yeah, I also asked agents to basically display Yeah, sorry, that's a lot of data, but yeah, I'll try to make it larger so that… yeah. One more thing, it looks like, IDONTWANT mechanism isn't really working very well, in case of Lodestar. Yeah, here, just…

I was just doing this, checking of execution payload messages. And, yeah, for example, if we fix, if we take some role. Yeah, I think it starts… sorry, yeah, that's… Yeah, this is Lighthouse. So we see, like, for example, this is the size of the message, and this is, like, how many copies we received. of that message. So, in case of Lighthouse, it was… sorry, I just did it before the call, so sorry, it did not render properly yet. And… So, yes, usually it's, like, 5 to… Well, sometimes 10 copies, but in case of Lodestar, it's, like, much larger. Sometimes I observe, like, 60 copies of the execution payload message. Sometimes it's like… I think I even saw 90. Oh yeah, it's 77.

Things like that. Yeah, just something… Worth flagging. Yeah, maybe you could check on jslipdp. Why this is happening, maybe it's just me, I don't know, But yeah, I think just receiving… message of size 150 kilobytes 61 times doesn't look right to me. I I I think I even asked my agent like to check what's happening, and it said, like, yeah, IDONTWANT mechanism doesn't work as expected. Maybe you can just check it. Oh, I actually do.

Matthew Keil: just fixed the IDONTWANTs in the latest release or two releases ago. So I'm wondering what version you're on. But there was a bug in the IDONTWANTs actually.

Kamil Salakhiev: Oh, okay. Yeah, I think I was running the version that I think was supposed to be used for Sepolia. I'm not sure.

Matthew Keil: Oh, it should already be in that. Yeah, I'll take a peek at that.

Kamil Salakhiev: Okay, okay. Yeah, I'll double check. Anyway, just flagging it here, not… yeah. Just in case. Alright, nice. Yeah, just… yeah, really wants to go through this, and yeah, with that, yeah, we can proceed with the next item in agenda. So, I think Felix wanted to speak about Service Discovery Project, right? If I'm not mistaken with the name. Okay.

Felix Lange: project.

Kamil Salakhiev: Yes.

Felix Lange: Yeah, so I can just, one second. So, just to explain a bit what is this project, this is kind of an old project. That we have been working on for quite. number of years. So in the original discv5. spec, there were some messages related to this topic mechanism, but these messages were never really implemented by any client, and it was kind of a leftover from when discv5 was initially developed. And, meanwhile, we worked on the… on the actual mechanism after this v. 5 had already launched, and we ultimately ended up creating a paper also together with data. Hop. So actually, they did most of the work on that. And

we recently concluded another project where we have now, I mean, as part of the like after the paper came out, there was a bit of quiet time. But then, recently, we have actually added this mechanism also into the spec, and this has replaced the original topic-related messages, and you can see them starting from here. These are kind of the… at the end of the message code space, so there's this REGTOPIC, REGCONFIRMATION, TOPICQUERY, TOPICNODES, messages. And these messages assist in a system that Helps nodes to register arbitrary identifiers under which they can then be located. And so this is kind of a long running. Feature request for… for the discovery that At the moment, you can perform a random walk in the network and then locate ENRs that may be matching your criteria, but you cannot really make a targeted search.

And so, with this mechanism, you can register arbitrary number of topics for each node, and the nodes can then be located under these identifiers. And these, notably, these identifiers don't have to be encoded into the ENR, so it's… it is fully decoupled from the ENR. So after you search for such identifier, you can still filter the results based on other criteria, like the ENR, or… but you… we have… basically, it just adds another index to the discovery that is different from the main node table, which is indexed by the node ID. So, I just wanted to present this because I've been talking about this on and off, also at various meetings, and people were always like, oh yeah, interesting, but what is this thing? And so I just wanted to highlight that this is in the spec right now, and we do feel like the spec is pretty much final.

At this point, so we could just go ahead and implement it. We do have an implementation in Geth, although it is not merged, so we are… it is still under evaluation by… Datahop, so we've been performing some large-scale test runs with this implementation, and still occasionally finding some smaller issues. They are also on the call, so if you have some questions after the Presentation, which will be over in A minute or so, we can just… talk a bit about it, like, what's the state of the evaluation, and so on. But, as part of this, we also did. add a lengthy section to the rationale that kind of explains the mechanism. So here you can. you, you, if you want, you can, you can read this. So this will, explain a bit more the mechanism and, like, how this actually works in practice.

Like what are the, what is the advertisement protocol, search protocol and so forth. And also has some common question answers. And, yeah, there's quite a few of them, and I think it might be interesting for some people to think about, especially for the CLs, because in the CLs, as far as I understand, there's often this need to join a specific group of other nodes, such as an attestation subnet, or whatever future subnets might be created. And so this mechanism could be used for that. The original purpose of this mechanism long ago, when we started working on this, was just to tell apart the testnet nodes from the mainnet nodes, because still, to this day, I mean, we are sharing the discovery between all the networks.

also, even with forks of ethereum. And this is a win in terms of security for the network, because more nodes in the DHT always means that there is a larger number of honest nodes also. But, it is a bit annoying, especially when another network is very popular, because it will degrade the search results, but also if you're looking for, like, a small testnet, then it will take a lot longer to find the peers, so this mechanism is supposed to help with this. I do have to highlight that for extreme cases where, for example, you have 5 nodes out of 15,000, which are related to a particular topic, this mechanism is not ideal, so it doesn't, like, fully scale.

In the sense that you won't have this amazing one-second discovery performance for Very small services, but for services that have Yeah, a couple hundred participants, then it will work pretty well. So it is actually… Possible to use this, and there is no limit, again, on the number of topics that can be registered, and each topic only adds some overhead, mostly on the… on the registering node side. So I mean, whenever a new top, like for every new topic that a node will register for, they have to perform additional work to put themselves in the index for that topic. So that does mean there is a practical limit to the number of topics you can register. Like, if you would spam, like, 50,000 topics from one node, then this node actually has to perform a bunch of work to…

To put itself into all of these. Positions in the index anyways that concludes my. presentation, and I'm happy to answer some questions.

Raúl Kripalani: as.

Kamil Salakhiev: Prabhu.

Raúl Kripalani: So I do… yeah, I do have a hand here. So, for the consensus layer, and specifically the topics that nodes would want to discover and kind of, like, join and search and find members of, and so on. Really, I think… this seems to me a little bit heavy-handed, because… Really, the information is already contained in the peer ID, and it's a, like, any membership that you need to find. is… is in the E… is either in the ENR, because it's mutable, so in the case of syncnets, or it's actually just the result of a pure function over the peer ID. So… you don't really need the notion of membership, of topic membership, because the assumption is that discv5 is already cheap enough that you can run it very, very cheaply.

As a background service, specifically, ideally in periods of quiescence, so when you're not doing anything else. To kind of, like, discover the network and keep a view of the network, and it's very efficient to keep a full view of the network, at least with the size of the network today. It's, like, I think last time I measured it, it was, like, 7 or 8 megabytes or something like that, if you kept all ENRs in memory. So really, you can find… peers. the peers that you need from their ENRs with the CGC and the peer ID, if what you're looking are for specific column subnets, or if what you're looking for are, to join an attestation subnet, the next expected attestation subnet, when you're… when you're gonna… when you're gonna rotate.

or you need to attest, then you already have that information from the PRIDs. And it's… it's a result of the PRID, the function over the PRID, and if I remember correctly, the slot or something else, the slot number, or the epoch, probably the epoch. Yeah, so I think, again, I definitely see the advantage of having top service discovery as a baseline protocol feature here, because it does enable a lot more, like, you know, you can have Other things that are currently, overlay services, kind of like things that… are third-party services that are not running in the Ethereum network. You can actually have them running on the Ethereum network if you're capable of discovering them, but specifically for the objects and kind of, like, the propagation… I guess the CL…

needs and the protocol needs, I… I would just, like, keep it simple, honestly, because I think it's… it's even more advantageous to… to do it that way.

Felix Lange: Yeah. So I have some points about this. So first of all, this mechanism is specifically to reduce the algorithmic complexity of searching for the peers. So it's more like a fundamental Fundamental solution to this problem. Yeah, my second point is that if we want to really make every node crawl the entire network all the time to keep an up-to-date view, then I think that's also not ideal, because that will not scale in the long term. I do think we should strive to make the protocol such that it can support arbitrary network sizes in theory, even if we do not have this network size today. And then, finally, the point is that it is currently very cheap to store all the ENRs, because the ENRs are very small, but we will, in the future.

see if this is still the case, especially as we move toward post-quantum ENRs. So we have to… we cannot always assume that it will be that cheap to keep everything. And I wouldn't wanna…

Raúl Kripalani: Yeah, definitely. I think post-quantum is a good point there. I think there is this kind of, like. unresolved topic that at least while I was at EF, we didn't… we didn't have a good answer for, which is. Given that network traffic is generally ephemeral, and we specifically separate the network identity from the node identity, which is persistent, right, or the consensus identity. We specifically… there should be… there were some… there are some leakages introduced by Pyrrhodas, but those were, like. those were bad. Hopefully, they will get removed at some point from the protocol, but, like, the invariant that we used to hold in the past was that the peer ID and the consensus identity would never be linked.

So really, if you kind of, like… and that would allow you to rotate the PRID very frequently, right? So really, and we're not doing any, like. any encrypt… encryption, or kind of, like, secret communications. We… we might do in the future, right? But for now, there's no secret communication that you might wanna, like, you know, you might want to save and then go back and decrypt in the future, or whatever. Like, that's not the case, so I don't… But there might be legitimate, like, there's probably a missing information here, but there might be, not for post… to sign ENRs with post-quantum signatures, but I guess information that needs to get embedded somehow to prove something about that, like the post-quantum identity of something else, and maybe that thing is large. Because right now, if I remember correctly, the system is sized for 300 bytes cap, right, on the ENR?

Felix Lange: Yeah, there is this issue that they are fundamentally were designed in a different time when we just.

Raúl Kripalani: Zoom.

Felix Lange: that ECDSA would be lasting a lot longer.

Raúl Kripalani: Yeah.

Felix Lange: However, this… I just wanted to mention that basically, I don't want to build on this assumption that the entire network work view is so cheap. We can still keep large network view in all the clients, but fundamentally, it's also a bit about this… With the service discovery, we do have this goal that you should be able to enumerate all participants of a topic. And this is something which. You can… you have to crawl the entire DHT to make this.

Raúl Kripalani: Yeah, but my point is… so, let me… let me just rewind for a second. Like, I think I missed… I missed to say this. My point is that the DHD in itself does not churn that frequently that you would need to, like, crawl the entire network. The deltas between… like, once you crawl once. the… the assumption is that with the current size of the network, and there I totally, like, I totally agree with you, I think, like, if there is a chance that, you know, the network itself might increase, but I don't know, I, like. I personally, I haven't seen this work out, because it is the scaling assumptions of the core network. Those were one of the reasons that, you know, back in the day when I introduced Libby2P, because it was like, yeah, maybe browsers will join, and, like, mobile devices will join the core network, and all these things will join the core network. And if you look at every single architectural principle in systems design, this is…

probably not the right architecture, where you actually want to have an edge network that is specialized for these devices. But, like, that's a different story. But if we expect the core network will grow, then yeah, I agree, like, you know, it makes sense to… more sense to have topic discovery there. and the other… what was the other point I wanted to make? Oh I can't remember now, it was the second point, but I can't remember. Anyway, this is good, yeah. Generally, I agree that this is a good capability to have in any networking protocol. Oh yeah, the… sorry, the second point that I wanted to make was precisely that, that, like, once you do the first crawl.

Then, like, subsequently updating your network view is cheap. Should be cheap. But, anyway. just because of the construction of the Dhc.

Felix Lange: I see. Yeah, okay, so thank you for your points. I am still curious if anyone else has any questions about this. I mean, this, like I was saying before, this is currently in the spec. And we did it this way because. The previous thing was also in the spec. We didn't implement it, so we felt like it's just okay to update this instead of making some kind of new release, because it is just… Related to these message codes that are anyways not being used. We did in the most recent project with Datahop also. Work on the incremental deployment of this feature, so it can work, even if not the entire network supports this at the start.

It's not super ideal, but it does work, and the way it works is that, anyway, this thing builds, like, an overlay on top of the network, so it uses tables which are derived from the main node table, but then these tables are also somewhat self-maintaining, so it means Once you have found some number of nodes which are participating in the service discovery protocol, it can kind of bootstrap itself from that. And so it means. We can just introduce this feature incrementally and not all nodes have to be updated to support this. Right from the start. Yeah, are there any questions about the mechanism itself, or, like. I mean. Yeah. Maybe also something about the implementation complexity.

Could talk about that as well.

Kamil Salakhiev: Maybe you can share a link and people can, yeah, dive in. So.

Felix Lange: It is in the current spec. I mean, I can share the link, but it's like this link is.

Kamil Salakhiev: Okay.

Felix Lange: Just the spec. It's just integrated into the documents as they are now. Regarding the implementation, we do have it like… We do have the implementation here, which is in progress. So. In this… branch, we have the main implementation, and actually the core logic of the protocol is contained in a separate package, but this package is not related to the… not related to the network like this doesn't implement the net, the network packets related to this. It only implements the data structures and algorithms related to it. And it's just, it's not that much code, I have to say. So we have like some implementation of the search algorithm, implementation of the registration algorithm, and then we have an implementation of what we call the add cache.

here it's called the topic table. These terms have somewhat been used somewhat interchangeably. So this is like this, the index store that each node will run to maintain these like service. entries. Yeah. And so maybe something to mention about this. I can share this this link, I guess. So something to note note about this is that we have designed this thing so that the resource overhead on the node in terms of the storage is constant, so there is… everything is bounded, statically. So, for example, there's no… In order to participate in this protocol, you don't have to store arbitrary amounts of entries, but every node has a limited size index table that they store these entries in. And so that also means the overall system does have a limit

of entries. So there can only be so many active registrations at the same time. So it is not infinitely scalable. However, it is very scalable, because the way we did it is, I think, in the current implementation, we have a limit of something like 10,000 entries per Not 100% sure where this is. There's some kind of constant somewhere that says, like, what's the size of this? service table. And so if you think about it like every new node joining the network brings in additional capacity for like 10,000 or more service entries that can be stored. So that means there's we… it would take us a while, I think, to actually reach such, this limit. And also, there is nothing in the protocol that assumes

a specific limit there, so it can also be tweaked after the fact, and it will just increase the capacity of the network. There's no requirement for all nodes to share the same cache size limit. And as Raul said, it is quite cheap to keep such number of ENRs right now, so we could start out with like a really we could just, like, see over time what is a good limit, but it doesn't cost a lot of resources to participate in this. I kind of wanted to mention this. And yeah. Anyways, I will share the link to the implementation. It might be a more interesting link, and maybe also the other link, and then…

Kamil Salakhiev: Okay, nice. Yeah, let's… I guess, yeah, let's proceed. Yeah, just trying to be mindful with time. Yeah, we also wanted to discuss. Decouple consensus simulations that I think, Sukun was recently working on. Yes, Sukun, are you ready to share that?

Sukun Tarachandani: Oh, hi, am I audible?

Daniel Knopik: Yeah. You are.

Kamil Salakhiev: Sorry.

Daniel Knopik: Pardon?

Kamil Salakhiev: Yeah, we can hear you. Yeah, we can see your screen.

Sukun Tarachandani: Yeah, so the simulations are actually scheduled for tomorrow, and I am in like this last minute stretch for a lot of fixes. But I can share some Shadow simulations. And, yeah, I'm trying to reconcile my numbers with Anton's simulation, who is not here on the call, as I see. But yeah, so, previously, what we had simulated on, like, this thousand-node subnet was, this first. strategy for aggregating attestations. So, for background, the idea in decoupled consensus is that. We want to have 8 slots per round, and so justification takes 8 slots for, rather than 32 slots, and so finality will be 16 slots, basically. After a block is published, it will be final after 16 slots, and justified after 8.

And the idea is that we now have two votes, One is a finality vote. And the other is a goldfish vote, which just keeps your chain moving forward. And the idea is that you don't have to work… basically, your finality vote does not… serve two purposes, which it currently does. Like, it works with this LMD course thing, where you move down from the justified block to C, which is, like, the heaviest chain. So now, we basically split the votes into two, and the finality vote is strictly for finality, and the goldfish vote is for, determining what the head of your chain is. It still works down from the justified point, but both the votes are separate.

So what we are planning to simulate tomorrow on a 500-node cluster is that, So, like, the biggest change, when you do fire, try to reduce the epoch length from 32 to… 8 is that we have a lot more votes. Okay, so what we have simulated here is that we have 2,500 attesters per subnet. And, to give you a comparison, right now on mainnet, it's 500 attesters per subnet, roughly, like, 450 or something. And so, if you're, like, a home node, and you run your beacon node at home, and you subscribe to two subnets, you would be handling roughly 1,000 attestations, every slot, right now. And so, we have increased this, basically, to 5,000. So, this load is roughly 5,000.

And we are simulating it slightly higher than what we expect the number to go on mainnet if… when we do decoupled consensus. So, when we actually do decoupled consensus, this number would not be 2500, it would be 2000, like, 4 times 500. If there are questions, please jump in. I'm not actually tracking anything here. So yeah, the three, things that we plan to simulate tomorrow are that one is basically this. Simple idea that you just publish your votes at slot start. Everyone publishes their finality votes at slot start. Other traffic flows in parallel to finality votes. The other is that we… in a committee, we basically say that the first X percentage of the committee votes in the first second, then in the second second, third second. This would require a certain amount of gossips of effort from our side, because currently, once you receive a vote, you just forward it. Now.

Nodes, basically, Beacon nodes are expected to hold these votes before forwarding if they receive it early, or, like, just drop it if they think their queues are getting full, etc. And basically, we keep a couple of seconds for, like, the whole pub… flow to finish, and publish aggregates at 9 seconds, so it is still one 9-second aggregate. And the other is that we basically say that We have 3 committees per slot. on a single subnet. So the first 4-second is dedicated to the first committee, the second 4-second to the second committee, and the third 4-second to the third committee. And then, basically, you get 3 aggregates out of this, but the nicer property here is that, your slot roughly looks the same at any point in time. You have.

some Oh. some attestations flowing in, and some aggregate traffic flowing in, and so we can, like, sort of get an equalized slot across the whole thing. And the good news is that. in simulations, and also, like, when we ran it on the thousand-node thing. Net-net, the whole thing works. But there is this slight problem with the… this setup, where we publish FFG votes right at the start, in, like, the first one. And the problem is that the goldfish votes, they're reaching on time, they're taking 3 seconds, roughly, and, like, slightly more than 3 seconds. Which is basically competing a lot with the, and the reason that they are taking this much time is that they are competing a lot with these FFG attestation votes.

And the point is that we don't have currently a good Prioritizing mechanism between two different topics. Or how to do it, because they also serve different measures, so they are actually sending Messages on… potentially different connections, like my Goldfish mesh peer may not be my FFG mesh peer, right? So, even if you use QUIC stream priorities to say, Goldfish is a higher priority vote than FFG, it might not work, because one peer is only talking to me about Goldfish, and the other peer is only talking to me about FFG. And, like, off-the-shelf stream priorities in QUIC only work on a single connection. So… and basically, yeah, that is the reason why we are trying to split these votes across the slot, or, like, try the second part of the committee.

This other style, where we have three committees. So, yeah, as you can see, like, this green is the three-committee view, and this orange band, right at the bottom for FFG votes, is the staggered published view, where basically every second we receive something. So, like, in terms of the plot, it looks like. the P50 is at the middle of the mark, which is to be expected, because at every second, a few people publish here, like, as you can see. And you can see the three committees being published here. So, but yeah, the, good thing here is that this goldfish vote, if I can zoom in… yeah. So, this goldfish vote actually does get much faster in both these different variants, one for

staggered publishing, and therefore having multiple committees. So that's all that I have right now. I'm integrating the… a tracer for GossipSub to measure the IHAVE/IWANT traffic also, so we can see if we can tweak that and get some improvement out of it. And I would also like to make X-ray work off the shelf with Shadow. I don't think there's currently support, but maybe I think it can just trivially work. Yeah, so… and I plan to run it on, like, a real subnet tomorrow, so I'll have better visualizations for that data maybe in the next call. Yeah, so this is what I have for data. Any questions? can talk about.

Kamil Salakhiev: Yeah, I think there are… Please, no questions in the chat. Yeah, overall looks good. So these Shadow simulations, how many nodes again did you run? Could you elaborate yourself?

Sukun Tarachandani: I'm running 100 nodes, basically. So, the way it runs is that you have 20% as super nodes, and 80% as home nodes. And, home nodes only have 1 to 2 validators, 1 to 3 in my case, and the rest, all the validators are on super nodes. So, in terms of simulation, this load is basically what you would expect on mainnet for home nodes, but super nodes have slightly low… lower node… load. Now what is… happening is, at least in the measurements, if I, like, split the data by supernode versus home node, most of the supernodes are fine, like, they receive data very quickly, and there's also this one behavior that I'm observing and, like, I'm trying to track down why this is happening, is that

Actually, over time, super nodes connect to themselves, and they cut out, like, the low-scoring home nodes because of this optimistic mesh shuffling that we have. And so, like, most of these towards the 99 percentile or max sort of numbers that you see are for home nodes, basically. And just to repeat, like, the reason for this sort of config is that this load is less for supernodes as they would expect on mainnet, because supernodes, in addition to the two subnets, also serve aggregator duties on other subnets. Like… Home nodes are also supposed to serve aggregator duties, but on an average, supernodes have so many validators that they are just generally running aggregator duty on at least one subnet somewhere else.

Except for the two subnets that they are long-term subscribed to. But yeah, intuitively, we expect, like, the home nodes to be the limit endpoint and not the supernodes.

Kamil Salakhiev: Okay, cool, exciting. Yeah, it would be very interesting to see, the results of the… Simulation. I think this is like real simulation. It's not like Shadow, right? It's like with real. Yeah.

Sukun Tarachandani: Yeah, so it's on Cloud Run, and we ran it on the 50-node thing today. Everything, like, I mean, there were a couple of hiccups, but we have fixed it. So yeah, I think tomorrow it should be fine. You can just run it.

Kamil Salakhiev: Cool, nice. Okay, Yeah, if no other questions, so yeah, let's proceed. Thanks, Kun.

Sukun Tarachandani: And yeah, I, I'll try to make X-ray work with Shadow and like maybe just raise a PR or something.

Kamil Salakhiev: Yeah, good, good. Okay, nice, oh, Yann, did you want to say something?

Yann Vonlanthen: No, I was just wondering… If, maybe quickly, if you have intuitions, or if people have, like, ways on how to deal with, like, what is the. the safety factor that is needed, right? Like, is there, like, some way to deal with this? Like, how to add… how to make sure that's, you know, translate from… from devnets to… to Mainnet? Is there, like, some factor that you usually use, or something like this?

Csaba Kiraly: So there are a few things there. One is the… is the scaling, and… The scanning behavior that you… that you should check. Just a number of notes, and that's typically very good with… An issue? But the second one is more critical, in which, what You want to be safe against network outages, bandwidth limitations, network partitioning. And so on and so forth. So that's… that's more of a… of a detailed, analysis of scenarios, either in simulation or thinking through whether they can create issues. I did a boss. So typically you should. You should go through these these scenarios which would Create issues, and then… Yeah. I don't think you can say multiply by 5, and then you're fine.

Yann Vonlanthen: But is it, for example, for churn, is there some…

Csaba Kiraly: Lalitha. Yep.

Yann Vonlanthen: Sorry, I think you're cutting out a bit for me.

Csaba Kiraly: For churn… you I mean, my approach is usually to… to… Simulate it to some extreme that you are happy with, saying that's extreme, and if you survive that, then you are… You're happy. Not trying to… to say. Yeah, so the good thing in simulations that you cannot do on devnets is that you can explore these dimensions and understand how they are degrading. Maybe understand the joint effect of two. Problems at the same time. And be it that I'm… understanding of what could be an issue. And then you can look at that, and you can say, like, okay, but that will not happen.

For churn specifically, the current stack is very bad in building connections. So that's where, we will… improve, Later, but that's, in some sense, what's gonna be the problem, certainly. The plumber, Ms. Chan is… Is that not suddenly slow to ramp up? discovery, connectivity, etc. We have analyzed it quite a lot. The idea is to improve it, it's just not the… Number one topic, I think.

Yann Vonlanthen: Makes sense, thanks.

Sukun Tarachandani: All right. On this…

Kamil Salakhiev: Yeah, sorry.

Sukun Tarachandani: Yeah, I just wanted to… so, on this, like, what we have planned here is that We try to get the load same for every node. Like, of course, like, yeah, this thing does not account for churn and these sorts of, like, security things. And then, basically. Now, if the load on every node is the same, we measure the 95 percentile latency, and then we basically try to say that, okay, if a topic which has N nodes takes this much time for 95 percentile latency, if it had 2 N nodes, it would take, like. some more time, basically, in that sense. Like, one that would… so, A10 nodes would be one hop more than N nodes, like, in terms of the graph diameter.

I think…

Csaba Kiraly: Yes.

Sukun Tarachandani: Like the scaling we would like to plan or what we were planning for, like does that make sense?

Csaba Kiraly: Yeah, but I don't think you should be worried about it, actually. So the scaling, like, or… It's just how the system is built, it should not be a problem, and then… Simulations that we have done never run into that problem, so… It's just, the way… Build diffusion is made. That's the list of your bodies. It's, it's… If it is done for one thing, it's for scaling, so the… the… The problem is kind of the opposite. The thing that was… that was also highlighting, P2P systems are made to scale to millions of nodes, and we don't have a million nodes, we have 10,000. So you can do optimizations which are. Which are based on the fact that you assume that you don't have more than 10,000 nodes.

Maybe don't put it at 10,000, because it's a bit sharp, because we have 12,000, but you can kind of… do that. So, you know, I'm… putting the whole network in memory, because it's just 20,000 nodes, and these kind of things. And those can help in syncs. They will not help in diffusion a lot, so… Because that's just done well by the usual peer-to-peer machinery.

Sukun Tarachandani: Okay, thanks.

Kamil Salakhiev: Alright, I think the last topic in agenda for today, it could be super fast, or it could be long, which is why I put it in the end, is 8411. It's not some particular… Thing to discuss, but yeah, overall, just want to bring up the current state of it. Yeah, it's just… yeah, we have… the… Yeah, where was that script? So yeah, we have the EIP, it's currently already merged in EIP's repo, so… Yeah, we made it… Sorry, not CFI, PFI to Hegota. Basically… yeah, the state of the EIP is the same as, yeah, we described, more or less the same, like, we described in one of the previous calls. So we're just chunking the payload into basically 64 chunks, and then, yeah, propagate it, and yeah, we've also made some changes to the…

payload bid, so that we include the chunks root, so that's… that's basically the 90% of the EIP of 25, maybe. Yes, so we have, some teams, supporting that, some teams actually not really supporting this EIP. Yeah. Yeah, just would be great to… yeah, since we have. some representatives from, yeah, Lighthouse, Prysm, Lodestar, just to get maybe the opinions of. What people think, like, what are their concerns, if they're not… if they're thinking, yeah, it should not be… in Hegota. Yeah, the idea is the… it's kind of, like, the same, because, like, yeah, we just want to… Be prepared, when… Yeah, well, the gas limit raises, yeah, the. Payload size grows, and potentially the slots get shorter, yeah, stuff like that.

Okay, yeah, Matthew.

Matthew Keil: So, I have a question on the data that was used in order to drive the quote-unquote necessity of the feature. And is it something that is being data-driven, or is it, like you just mentioned, it's, you know, in preparation that something might Absolutely. You know, they're ready for block, you know, gas limit to increase, or so we're ready, but, like, it's… Do you know what I'm saying?

Csaba Kiraly: What kind of data?

Matthew Keil: Well, so, after talking with Nico, we were doing some discussion about this internally, just trying to understand what our stance was as a team, and… He had basically mentioned that there really wasn't any issue on the devnets with even very, very large, payloads being delivered timely. And that's the part that I'm… that's why I'm asking, like, what was… You know, what is driving the… the… you know, the impetus in order to include this in, say, H versus waiting to see mainnet data to understand what, you know, just what timelines look like. Once we, you know, once we are on the net.

Csaba Kiraly: So the testnets don't really have form builders. As far as I know. Maybe I'm wrong on that, but I think the testnets which have scale and home builders and network issues, I don't think it's a combination that we have, and we want a network which survives. Scale. and homebuilders. And the network, which is not the best in the evening, So… Between data centers. So that… The testnets are not… really where we want data points from for these things. Mainnet is definitely something we want data points from, but even there, you don't see Some of the issues, because of the noise, and you definitely don't see the… the 200. mil. Blocks and… the BALs together, going through an ad hoc, which has, in the meantime, a few other EIPs, which I'm adding traffic, and

maybe the blobs start to scale, and so you just… you just don't have those data points. It is data-driven in the sense of… Block sizes, because we have an idea of what will be the block sizes of bandwidths, with. There's an asterisk there, because I was running simulations intentionally. One… one blanch of the simulations intentionally with low band. Yes. You can look at it different ways. One is a network under stress. is Ethereum as a protocol, not Ethereum as a deployment. Because you can… argue that, the fact that we have all these nice data center notes today might not be tomorrow. Or data center nodes contributing all that bandwidth. Hannes Pettine. So. So I think, but there's just one part of the simulations where I was putting every single node on a 50 megabit per sec uplink.

Most of my simulations… I can show the slides. Most of our simulations are running on. on… so I have a branch where it's a data center builder with 1 gigabit, and 20% of nodes are 1 gigabit. And another… Line of simulations where it's a home builder with 50 megabits uplink. And consider it as it should be the residual uplink after all the other duties. So. That might even be too much. And then I have still the 20% of. of data, one gigabit nodes. I call them data centers. There will also be a home node, which has worked a bit. It can be one of those. So these are just the data points, basically, in the, in the big space of what's possible.

But on the other hand, we want a protocol which is handling what's possible, and not just what's today.

Matthew Keil: And I do agree with that. Like, I am very aspirational when thinking about Where we want to be, and where I feel like the protocols, you know, the best direction. And, you know, and please cayman stop me if, if I… if I say anything incorrect. And, you know, so we talked about this quite a lot, and I think we are in agreement that the features seem sound, it doesn't seem… you know, while I think there is complexity in doing the implementation, it doesn't strike me as anything that is you know wildly outside of what's possible you know it's it seems pretty straightforward it's just a matter of doing it kind of thing. You know, we do…

at least, and I don't want to say we, I'll say I, but I, you know, I'm kind of carrying this message, and again, Cayman's here as well, he can speak to it. You know, I do… The only thing that I'm concerned with is… The… It's really critical in order to ship H quickly because I, J, and K are existentially important, and… There's so much stuff. that I think are nice-to-haves, and that are important for not only the health of the protocol, but for the ideal that I think that brings us all here. And… to me, this is kind of where the rubber hits the road. It's not that… it's not that I don't support the feature, and I think it is a good feature.

but… I think the complexity that it adds, just because it's the invariance and the timing of all the different things that come into play when it comes to how different objects arrive, how do you cache things. cash, you know, you know, clearing out cash and cash expiry, and, you know, just some of those details from an implementation standpoint that… are… They're… they just take time in order to go through all the invariants, and they're… they're difficult in order to… to, you know, to nail down the specifics. And this is where I think what's going to happen is we're going to get into a situation where there's going to be a lot of edge cases that I think are going to be… just won't become apparent until you build it and run it. And this is why I asked the question about the…

The… you know, the data that drove this is that you know, when there is a real need, I think spending the time in order to go through the invariants to make sure that we have it rock solid, I think is worth it. But when you get to a situation where we might have interaction with the bowels, and there might be a situation where, you know, we get to 200 million gas, and we could be, increasing the blobs further, and you know, there's a couple of very big ifs there that, like, while I agree they are likely and possible, we don't really have a lot of… of surety that a lot of these things are And this is exactly, like, I think it's fine to delay it to ISTAR,

And then… but I don't think we should even try to really attempt it in H, unless we are sure, sure, sure we've got all the rest of the stuff that is nailed down. Like, I don't… and I have a feeling that short slots is gonna be pushed hard, hard, hard, and I have a feeling that a lot of these other bits and pieces are gonna be pushed hard, hard, hard, and if there's any risk that we're gonna be dragging out the fork anywhere past June, which I think is critical. I just… I… without seeing mainnet data. Like, if we get to February or March, and we realize that, oh man. the payloads are not propagating timely, then I think it starts to become, you know, we start to talk about this. But trying to implement it and get everybody on board before that, and do the working groups and the… I mean, there's just so much other stuff.

that go into implementing a feature. It feels like it's a premature optimization for something that might be necessary, but without data, it's hard in order to Say it is necessary. Sorry, that was a long ramble.

Csaba Kiraly: Yeah,

Kamil Salakhiev: Yep.

Csaba Kiraly: like, to sound the points. So, yeah, I think we are seeing the same kind of pressure on the various HIJK, whatever. We see the STOMAP, we have an idea, you have an idea, I have an idea of what we're going to do. If you see that, you also see… the block, the BAL, you will see the PQ, signatures coming in, because it concerns the block. You will see as zk proofs coming in, you will see all these kind of big chunks of data that we have to propagate. And it will be the same machinery that we will have to do for that. So… One might argue we will do it when we have 5 of these, and then we are really…

in trouble, and then we will do it, but I think it's better to… To have it already… to start doing it now on the one big message, which we have now. You mentioned quick slots, that's just my personal view, but I would… Let her do the technology that blinks us. The possibility to be quick. Then the… than the quick… than the parameter change. So, I…

Matthew Keil: Agree. Like, I agree too. Do you know what I mean?

Csaba Kiraly: And I feel, like, in my view, this is technology that allows us to be quick. Then, Yeah, a few other points, yeah. I… I think we are speaking of C, of considering it. And… I think the same arguments would hold until. So the thing is, we will not see these problems coming up on the testnet. I think if the problem's coming up, if the props are scaling, if bandwidth is limited, if we start to have trouble, we will have trouble on the mainnet. And it's… I agree. So, so I will start preparing in the sense of having the technology, having the headroom, and not stretching, all the parameters until we realize that we have a

a mainnet that is not able to scale, to the point where, all the DOMIS parameters can go in a cycle. For blobs to go up, you need… One financial invention, and they are ramping up in a week. or… Yeah, so I… I don't see that, as a… I I think.

Matthew Keil: there's… Like, there's the other side of this, and I think this is something I've seen with a lot of people pushing for H, and, you know, I don't know how this plays in, but it feels like there is this sentiment that if it doesn't happen in H, it's not gonna happen for 3 years, kind of thing. I've heard that come up in so many different discussions.

Csaba Kiraly: Mike.

Matthew Keil: But it's almost.

Kamil Salakhiev: Like, it's almost true, because, like, H star comes, like. when? Maybe December next year, or… We're discussing the thing that's supposed to…

Matthew Keil: It needs to be June.

Kamil Salakhiev: Okay, it's June, hopefully, but you never know.

Matthew Keil: Yes!

Kamil Salakhiev: You never know.

Csaba Kiraly: That's true for many things, for example, built on non-post-quantum primitives, or many things where we think that we will have a a far superior design. Segmenting large messages is something which is in networking. literature since the 60s or something like that. So, it's not, it's not something that, you know, we'll, we will, we will figure out that there's something much better we can do. We should have segmented these messages a long time ago, and we are just catching up.

Matthew Keil: And this is the part that I tend to agree that if it was critical and we really were that worried, that maybe we probably could have done it in ePBS as part of the original design. And the thing that really, I think, my real worry, what's driving my hesitance is the… what Kamil just said, is, like, it's, you know, H is coming in December, and, like, if that happens, that means we won't get to, an L fork, where we're PQ, until 2031. You know.

Kamil Salakhiev: Do you know what to meet?

Matthew Keil: Yeah. Is really… that's the risk. And, like, in order to prevent that, you have to limit scope. No matter how… like, everything's important.

Kamil Salakhiev: Yeah, as Csaba said, and I already said that also, like, yeah, we're building the machinery which we will reuse. Like, not implementing this segmented broadcast now, we will have to implement it for PQ stuff anyways. I mean, these LeanVM proofs, they have sized, like, 300 kilobytes. And it's not like we have one of them, we have, like, many of them, so we have to optimize. We were already, like, discussing, like, how to Well, do the stuff so that we're not fetching the same proof. for the same… from the same subnet twice, things like that. But these all things that we're discussing internally already, it's built on top of, basically, this EIP. this EIP is already, like, yeah, we do hear every… everyone, like, we're trying not to… you have a lot of ideas, like, how to optimize it, and so on, but for now, it's just… the simplest thing is just segmenting the messages, like.

for example, splitting it to 64 chunks, that's already, like, decreases latency 3 times. And the changes, yeah, we really try to make it as simple as possible, so there is no erasure coding, for now, at least. There is no.

Matthew Keil: next thing I was gonna bring up is, like, and then you, like, so once you decrease things, then you add erasure coding, and, like, really, arguably, like, granted, we haven't scaled blobs yet, but at the same time, like, the amount of bandwidth that we're using for… for PeerDAS versus what we would have done with the base blobs. is, like, I think a net negative, where we are today than if we were still using blobs. And I think that Like, the vision that we're gonna scale to, you know, to much larger blob counts. I agree that that's a very real possibility, but it's not true today. And this is the part that, like, I worry about with this, is that we may need it in the future, and, like, but maybe the right time is when we're starting to do the proofs propagations.

that we start to do that. You know what I mean, and we can actually test proof propagations with partial.

Kamil Salakhiev: Yeah. Yeah. Yeah. I just don't wanna end up in situation where we need to introduce this, yeah, fast broadcast at the same time to the payload and also for the proofs and for everything. Then.

Matthew Keil: why.

Kamil Salakhiev: much… it would be much more complicated discussion, because, like, we'll come up with so many designs. Here, we already built machinery, we would test it… not test, but yeah, we actually have it implemented, and then on top, yeah, it would be much easier to actually have this proof propagation and other stuff where we need large messages. Yeah.

Csaba Kiraly: On the blob. So for the blobs. We can argue why there's no demand, there's a different change of strategy, etc. Here for the payload, I think we are quite sure that there's a reason we are increasing the CAS. We, we, we, we are… even if not sure, we hope it will be used, and we think it will be used, and we are building a system where it can be used, so I don't think we should build with the idea that, yeah. It will… maybe no one will use it, so… Let's hope. You know what?

Matthew Keil: you.

Csaba Kiraly: So, yeah, just to go, so now we are increasing to 200. Do you think we will increase in habitat? If we would increase in Hegota, that, let's say, double, then we would have double the size, plus the BALs, plus whatever comes in Hegota on the PQ front, which we managed to anticipate somehow. And then we start to, to feel the pain. So, I'm… I would strongly argue for doing at least the minimum, the segmentation and the batch publishing, which everyone has already, and that brings your delay and, down a lot. And then I have… you will see a post from me. I can show the slide on, kind of, what kind of gains you get from different techniques, and that's obviously much more complex than what we want to add here. Here, the thing is, let's agree on doing the minimum, and then we see.

by Hegota. How much appetite we have to add something more.

Matthew Keil: You know, that's actually, I'm curious about thoughts on this, and it's something that you brought up, Kamil, and also I think was accentuated by what you had mentioned, Csaba, is The, you know, we're gonna be needing to probably do this, paradigm when it comes to payloads. We're gonna have to use this paradigm when it comes to proofs, like, execution proofs. We're probably gonna have to do some kind of paradigm. We're gonna, you know, we're gonna have some kind of… drastic data increase when we go to PQ signatures, because they're much larger, and… You know, but, like… building the feature now without the… oh my god, there's a 5-inch spider on the ground, I apologize. I'm in Thailand right now. The idea that, like. being able to do the research on having these very large data points.

Or very large objects that are going across the network, and being able to get the data points of doing all of those things at once, and then… then being able to use that to inform the decisions of, like, how do we actually break up traffic, or how do we Schedule the traffic within a slot when all of the things are happening at one time. Like. That to me, and that's literally we're talking about at the Eiffel. You know, we're starting to really see the fruits of the of the, the research when it comes to execution proofs and… and… Oh my god, go away! And the, and, and the very large signatures and stuff like that. I'm sorry, I'm just, I'm still talking and paying attention to this thing, it's like a monster. And, like, how can we, like, how can we say that we're really…

like, we're sure everything works together without testing it together. And that, to me, is like… it's not that I don't think it's not a good feature, I think it is. Like, I think that's where I started. I think it's really a great paradigm, and I do agree that we're probably going to have to do something similar to this when we get to having all of this additional traffic on the P2P. Layer. But maybe it's worth looking at it, and we're talking 6 months away. Hopefully, if we can keep age short. Like that to me is like the that's a big if, but like that is the thing that I think drives should be the focus that drives us for the next.

2 or 3 years. Yeah, sorry to sorry to rant, but I I I do feel strongly about it.

Kamil Salakhiev: Yeah, Raul?

Raúl Kripalani: Yeah, so if I may just add my view here, I think networking in general has a big advantage that we've been underutilizing, which is Generally speaking, it is way easier to upgrade, because you don't require the entire network to upgrade in lockstep. You can negotiate things on demand, and you can negotiate specific capabilities that you're going to use, so as long as a particular protocol doesn't require, like… it doesn't… like, the key risk is in rolling out any kind of, like, upgrade to the network is the partitioning, right? Like, the split brain is one of the major risks. And I think this is the one top… or there's a bunch of them, but, like, you know, if we're… if I were to simplify, then creating, like, having a way, like, a really good way, investing and testing and simulating all of the pathological scenarios that could lead to these things.

breaking down, I think, would put us in a much better kind of, like, mental position to actually ship network upgrades in a waste more continuous way, because right now we're kind of, like, thinking about… generally, we're still staying in the mindset of, like, keeping them aligned to fork boundaries. It's just really funny. It's just really funny watching you. I hope you're okay. Still… I don't hear, but… Yeah, it's, okay. Yeah, so, as I was saying, I think, in general, I wouldn't… block on, like, trying to find the perfect mechanism that is gonna work for every possible future workload that might go into the network, because some of those workloads are still, like, in the research pipeline, in the prototyping pipeline, and we just don't have that information. If we gate on those, then we're just gonna…

like, be hit by a bus at one point, and I think in general, networking Should have a continuous… Drive? To optimize and create headroom, and just become more efficient, because we can actually afford to roll out changes on a continuous basis. And we're just under-utilizing that advantage, I think. So the question here is kind of like, if you unpack why, it's because of the risk factor, right? So, if you solve the risk factor, then you kind of, like, create the framework in which you can, like, put new candidates. for networking, like, tweaks and, like, you know, optimizations on the pipeline, just kind of like, you know, really evaluate them through the framework of stability and risk and so on.

And just, like, be really confident to roll out these things progressively, because… yeah, it's… and we don't… we don't actually need full client… synchronization to roll out one of these network upgrades, right? We've done… we've done it time and time again in the past. with IDONTWANTs and partial messages and so on. We've demonstrated that we don't need all clients to synchronize and roll out at the same time. Similarly in the EL. So, yeah, I think we just should lean into Let's ship something, and I think segmented, you know, segmented propagation is actually a pragmatic choice, and I think it makes sense. It creates more headroom, and also, it helped it helps us… it might change, and it's probably gonna change, right? Going forward, but it just creates…

immediate headroom. And it Tests an idea, which might not be the final idea, because several payloads are going to require ratio coding, so, like, that will go on top of chunking, which is, like, called segmentation here, but kind of like, you know, it just tests the splitting part of a… of… protocols that are… or proposals that are larger in the scope that they include, where one of the pieces is segmentation. So it kind of, like, helps us grease the wheels as well, and I think it's just worth, pursuing it. It just creates more headroom. I think it, like, boils down to creating more headroom and optimizing on the wire.

Csaba Kiraly: And just to. more points that came to my mind along the lines. One is… that this EIP… so one critical element of this EIP, Is that it is an unlock? Because it has the consensus change that we need, which is the change to the bid. And. We can build it in a way, like, I'm not… Pushing for that idea, but… but we can be at the debate that you can just use one segment. And then you don't have segmentation. But you have the unlock. So… so, in my Reliant, basically, the segmentation is parameterized, and that goes into the commitment. That allows you to just use one segment, if you are really… want to be in a situation where you can still emulate what we have now. But we would have the unlock. So, while I would like to…

As a fight, and I hope you want to see a fight, is because the EIP is giving us that small consensus change, which we need then to do the What Sarah was saying, then we can iterate on the networking size. The other point that I would add, which I see missing from the data sometimes, is that networking And many other parts of the system are in co-design. So… I think you don't know how many times researchers come to me asking for numbers. Okay, but how fast you can send it? Okay, but, what we can handle, And I can answer those things if I have… if I know the tools that I have at hand. And if we are holding back on these, we are holding back on those as well. So… I would…

Raúl Kripalani: Yeah.

Csaba Kiraly: I would not want that.

Raúl Kripalani: Yeah, just for the sake of discussion, just to reply on this point, Trevor, I totally agree. I think we… historically, what I've seen is that, yeah, we try to make consensus and network payloads compact to the point that they express only and nothing more than what the strict, like, minimal set of the functionality of the current state of the system requires, and nothing more, right? And I think that that might be a mistake, because as you say, there's, like, small… just a 32-byte field on a payload that, like, goes out every 8 seconds. Like, it's nothing, and it helps unlock A whole, like, dimension of propagation, broadcast, and so on, that otherwise we would have to wait for, like, the next fork, which, you know.

is not always guaranteed when it's gonna come. So, and then, like, we're missing the forest for the trees when we do this, because to save 32 bytes, we're actually, like, you know, blocking ourselves from a whole propagation, like, set of techniques that we're just not able to use that require a commitment ahead of time, or something like that, for, like, a sidecar payload or something, right? And it is part of the consensus, it is part of the protocol, so it's never going to break correctness, right, to send that data. So it's just, like, you know, the small levers like this that I think in general, we can design for, with some, like, systems design taste.

That, yeah, that help us… be much faster in shipping and experimenting with things.

Csaba Kiraly: Two quick thoughts on that. I see the hands. One is that… Yes, if you get any successful protocol, you see this pattern, basically. even outside of networking, just look at MPEG encoding. It's a whole story of generalization of encoding, so that you can use these features, but also networking, you can, you can track that. But there is another side to it, which is worth saying, is that, if we are adding these small fields. That's adding… it's not about complexity, but because of the… security criticality or consensus criticality of the chain, you have to be careful not to introduce things which Then… allowing to… To basically… Lead to folks, so… so we should.

Raúl Kripalani: Yeah, so that… yeah. Yeah, but that's my point, right? Like, if you're able… so… If you're… if you're calculating something to then… So, for example, a hash, right? Your… it cannot be reversed, right? Well, not… not yet. It cannot be reversed. But, like, in the calculation, you… you might have a input value that It has to be correct to lead to that hash. And expressing that input value and externalizing it in a payload can then unlock another thing. So it's, like, you're not breaking correctness. You have to, in that particular case, because you're not introducing a new degree of freedom, right? Because it's implicit in the formalization of the system that this value can only be this thing. So, that's what I mean to say, right? It's like, I'm not talking about, like, adding fields just because, I'm talking about those things that can… that

can only have, like, they cannot simply are stable in a way that they cannot break correctness, but, like, it's a little bit of a systems rant here. I'll back up.

Kamil Salakhiev: I would like to give a word to João because he had his hand raised for a long time.

jxs: No worries, thank you, Kamil. But just to second on what Raul saw, told with regards to IDONTWANT and all the other network features that we've been releasing from Lighthouse's side, and that we will proceed as equal with 8411 and also the attestation broadcast, as in, we will try them, and we will implement them. With… on Lighthouse, with retrocompatibility to the network, even if they are not accepted.

Kamil Salakhiev: So basically, what you're saying is that even… In the world, even if 8411 is not the part of Hegota, like, Lighthouse is committed to work on that. Yes. In a way that it's basically… Yeah, for example, optional, yeah.

Daniel Knopik: Yeah, of course we, do not intend to do this in, like, a harmful way, and invite everyone to join us. I think, the Prysm guy sounded interesting, I saw a thumbs up from Vlad. But yeah, just to, because like with partial messages, the feedback was that we didn't involve clients, you know, enough, other clients enough. and Just… yeah, that's why we are saying this upfront right now, like, we have the capacity to do this, and this is, like, it's entirely technically easy… it's easily possible to do this, like, as an optional feature, so yeah, we intend to… Work on this, anyway.

Kamil Salakhiev: Yeah, okay. Yeah, it is possible to design it in an optional way. Yeah, I would like really to… if possible, it would be great to avoid that, of course, but yeah, I think this, in general, for the networking. Yeah, it will be beneficial even if some nodes support that, because, like, if some peers propagate the payload faster, then once they reconstruct that, they can actually help others. But yeah, it's… Overall, yeah, it would be much, much better if we just, yeah, avoid that and everyone, yeah, receive the payload. In a fair manner, so basically they get it at the same time. Yeah.

Csaba Kiraly: Yeah, but even… Why we can do it if… if we miss the… The bid out. We are doing it in a much less, optimal way, so… That's, That's an unlock which would be nice to have. Even then…

Kamil Salakhiev: I don't know. Yeah. I don't want to go too much into discussions how to make it optional, like, from technical perspective. I think it is possible, but yeah, it's not… Super elegant solution, but yeah, it is possible, yeah. The most. Oh, goodness! Alright. Yeah, any other thoughts on that? I think those are good solutions. Alright, yeah, I think, yeah, we can continue chatting about that async. You'll have Discord channel. I think, yeah, it will be raised on one of the upcoming ACDC calls, so… But yeah. Anyway, feel free to bring this up if you have any other concerns, questions, whatever, about the EIP.

Alright, any other questions before we wrap up for today? Okay, cool. If not, yeah. It was a great call. Thanks everyone who participated, and see you in two weeks!

Daniel Knopik: See ya, bye bye.

Matthew Keil: Bye. Have a great. Thank you.

Kamil Salakhiev: Bye.

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