P2P Networking Call #6

Transcript

Kamil Salakhiev: Each other one.

Csaba Kiraly: Hey, hey. I'm still in a call, but… Well, let's hear them. Yeah, just…

Kamil Salakhiev: another call.

Csaba Kiraly: No, not a valid call. I just missed. Recalling a call center. So he'll be here soon.

Kamil Salakhiev: Yeah, let's wait maybe another minute or two for people to join. Hey, Hayden. Keeping, pinging the people.

Hey,

Aarsh Shah: Is Sukun gonna join today?

Kamil Salakhiev: I just pinged him. Yeah, he should join. You know, I asked him… Yeah, I asked him, like. Maybe, what, an hour ago? Yeah, he said… He wanted to join and re-talk about this… Worko. Anyways, I think, yeah, we can just get started, and then, yeah, people join. Yeah, yeah, today… yeah, let's do client updates. Yeah, when Sukun joins, yeah, you will briefly describe this Waggle idea, I think we will discuss it more, maybe, in future meetings. When, yeah, Joa and others, they all also join. Yeah, then… Yeah, this is not in the agenda, but yeah, if time permits, I can briefly maybe touch on some updates on this blobs idea. Anyways, yeah, let's get started, with client updates.

Yeah, Daniel, maybe start with prison? Oh, sorry, with Lighthouse.

Daniel Knopik: I can… I can also, start with Prysm.

Kamil Salakhiev: Yeah, yeah, sounds good. We should do this topic someday.

Daniel Knopik: Okay, okay, from Lighthouse side, we are now in the final review phase for… partial messages, partial data columns in Gloas. I hope it's merged, like, tomorrow, or the day after, so that's good. And, we also… have… prepared… The necessary changes for… sparse blob pool in definite 8, so FCU V4 adjustments and Get blobs V4 should be in those branches. And also, hopefully, soon, in Unstable. Yeah, I think that's pretty much it from our side.

Kamil Salakhiev: good things. Aarsh? Any prismatics?

Aarsh Shah: Sure, sure. So yeah, we're very close to… Merging the gloss partial columns over to the Glamsterdam DevNet 7 branch, and then… you know, we can start interrupt testing on the Gloas DevNet with Lighthouse. I did the interrupt testing on Kurtosis, and it looks green, which is great. I also had a call with Sukun… yeah, and, yeah, my next, target now is, to land the Get blobs V4. and fork choice updated V4 work that, you know, Bosul had raised a PR for. But I'm now gonna rebase all of that on the Glamsterdam DevNet 7 branch, because there's a lot that we need to add there for it to work seamlessly with partial columns. So that's, my… yeah, so Bosul will let you know when it's, you know, I've taken it to completion, tested it, etc, and I think we'll release it along with Gloas. No, actually, no, we can get it and develop before that. I'll keep you updated.

Yeah, and one more… yeah, I had a nice call with Sukun on Friday about Waggle. Personally, from Prysm, we are very excited about, the idea of Waggle, you know, basically… a gossip sub-library built specifically for Ethereum. That has first-class support for partial messages, EC-broadcast, and… doesn't have all the heavy control messages that gossip-sub has. You know, basically less code is better, and something that is more ETH-aware in terms of PubSub, that would really… that is a pretty good idea. So we were coming around to it, so I had a call with Sukun that, you know, we are very interested in working closely on the Go implementation to land it. Like, you know, we can pair up with Sukun and join teams and land the…

Go implementation, and of course, the spec. So yeah, when I'll… whenever he's up next, we'll… we'll… just… I'm just interested in understanding the… Consensus mechanism around it. Like, are all client teams on board? We can do it without a hard fork, for sure. Just be a bit trickier, because… Either the app layer speaks both Waggle and the old goal of P2PubSub. or we make Waggle inside, go B2BP, PubSub, and then… later get rid of everything we don't need, so it becomes Waggle. Only? Yeah, so there is a way to do it with a hard fork, without a hard fork. just wanted to… whenever we all meet next, along with Sukun, I think we should… Kind of get some consensus on how many teams are interested in shipping it, what the timeline's roughly.

look like? By when do you think we think we can have a spec, ready? You know, So yeah, yeah, let's do it in the next call, then. And daniel, I had a… I found a bug when doing Gloas testing for partial columns. I suspect you might have a similar bug in Lighthouse. Basically, if… the Get blobs v3 call and the has blobs call both return nothing. Like, basically, there's not a single… blob in your mempool. In that case, you should still push out Like, you know, a request bitmap of all ones, and an included bitmap of all zeros. To the peers, so they can send you all the columns. That you're looking for, if that makes sense.

Daniel Knopik: I thought this is handled properly, but I'll check it.

Aarsh Shah: Take a look.

Daniel Knopik: Yeah, because…

Aarsh Shah: I had missed it, and it, it was sometimes causing problems when Get blobs V3 and HES blobs both returned empty. Just to.

Daniel Knopik: Yeah, actually, Has blobs is not in the codebase right now. It's… Yeah, not, not actively utilized, so, Let's see. But… but I'll check, I'll check.

Aarsh Shah: Okay, sure.

Csaba Kiraly: What is the issue, Del? It is that you have to push out the message anyway, or…

Aarsh Shah: Yeah, yeah, like, basically, if… Even if you have nothing, even if you have zero blobs. In your mempool, so the EL Get blobs call returns nothing. You should still push out a request. saying, I want all the blobs because I have nothing. Like, basically, I want all the columns because I want… I have nothing.

Csaba Kiraly: Yeah, so what's the semantics that, should the other side know that you need all, or is it getting it from your signaling? Because if it's getting it from your signaling, then… then that's the expected thing, right? You have to signal that you need.

Aarsh Shah: Yeah, yeah, so…

Csaba Kiraly: a little bit.

Aarsh Shah: Yeah, in Prysm, we were missing this branch, where when both get blobs and… So, if has blobs exist, you call has blobs. You push out the bitmap, you push out the request bitmap for the data columns, right? Then you call Get blobs V3. Ifs blobs doesn't exist. Then you call Get blobsv3, you update your request bitmap, and you push that out. But if both has blobs and GetBloves returns empty. because you have no blobs in your mempool. Even in that case, you need to push out a request bitmap of all ones, saying, I want All the data columns. And, I have nothing. So that edge case we were missing in Prysm.

Csaba Kiraly: Okay.

Aarsh Shah: Does that answer your question?

Csaba Kiraly: I think I got it, but yeah, I have to look into the details.

Kamil Salakhiev: Okay, yeah, thanks, Aarsh. Yeah, let's proceed with EL updates. Yeah, Bosul, anything on Sparse blobside?

Bosul Mun: Hi. On this past before. I'm working… on the… Oh, no. a partial Transaction size cap PR, so whatever PRs after first blob is merged in on Master. And… Also, the problem that occurred from handover. So I'm fixing some bugs related to sparse blob, and… also working on the QUIC listener, integrating the QUIC listener on the gap. I'm working on prototype of that proposal. Hmm… That's all from my side, but I guess Caba has more… More works. Thank you.

Kamil Salakhiev: Yeah, let's pass the mic to Caba.

Csaba Kiraly: Yes, so… sparse blob pool, I have… A few modifications. also… touching Get blobs before, so… I hope those will land today. the… the… the specification is asking for… for sending… I mean, the PeerDAS specification is asking for… for 41 bitmaps, but, we are currently in the implementation. We are focusing on… on the… first… 63 cells… 64… first 64 cells, and that creates a few edge cases that we are fixing now with Bosul in the codebase. So, yeah, I… My guess is that today there will be updates, and so if you are testing against it, and testing PeerDAS before fall, just expect that there will be changes today. If Today, if you would custody columns in the upper part, you could bump into issues.

So, yeah, anyway, fixes, I don't know. in branches. Blanches will be PRs soon, and then they will be merged. What was the question? I see a question popping up.

Kamil Salakhiev: Yeah, question… are there gonna be any spec change, or there is already?

Csaba Kiraly: So does… there are some discrepancies between the PeerDAS spec and the EIP implementation at the moment. So, I think… There will be spec qualifications, I think. But I think the… the direction I'm going with the implementation is more… is closer to the PeerDAS spec. What else? Yeah, that's for the… for the sparse blob pool. Then, other changes… Hmm… I have a new EIP called, Distributed Block Instruction, EIP 8C71. Which is… Basically, the old idea of using, those subnets and, and,

And sell our messaging with bitmaps. We have the machinery for that now. defined, model is implemented, so this is… this is proposed for… for Hegota, so I hope by the time we will have… everyone will have the… Partial messaging, up to speed. And then we can… we can use these columns to… to do, distributed deconstruction, with the aim of reducing the CPU load. on… so it's double aim, one is reducing the CPU load on… simple aim. One is reducing the CPU load on super nodes. The second one is making the construction more robust. And faster. And the third one is providing a mode in which we can reconstruct even without super nodes. So, yeah, the EIP is targeting these three gains, basically, bringing in…

a chunk of the, of the Fortas system. to the… to the definition. It's called RowDAS, let's see the discussions about it. Yeah, these are the updates that's come to my mind QUICly.

Kamil Salakhiev: Sounds good. Yeah, maybe we can, I don't know, go deeper into this RowDAS EIP, some call. Anyways… I'm just thinking, like, you know, also in the lights of this… lean DA ideas, like, we have, I think rows are also committed via Merkle trees there, and there is, like, row root there, so, I don't know, like, well, just curious… It would be interesting to see, like, what might be… The commitment scheme there. Maybe at the first iteration, it's still kzg, but in future. Yeah.

Csaba Kiraly: Yeah, let's leave the future for the future.

Kamil Salakhiev: Yeah, yeah.

Csaba Kiraly: Yeah, of course.

Kamil Salakhiev: kzzy.

Csaba Kiraly: then we can iterate, we can… we can change that, we can… we can definitely use Medical. It has its cost disadvantage, but we might… Want to do it for… for being post-quantum. That's…

Kamil Salakhiev: Yeah.

Csaba Kiraly: We can…

Kamil Salakhiev: Everything… everything gets a bit more expensive. sometimes not a bit, but I presume a lot more expensive with PQ.

Csaba Kiraly: Yeah, I think that ZK is… I mean, the aim is to keep that overhead low, but there will be overhead, there's no question.

Kamil Salakhiev: Yeah. Okay, nice, thanks. Yeah, FOCIL, anything you want to share about Nethermind updates? Oh, we cannot hear you if you're speaking. Still cannot hear you. Okay, yeah, Yeah, let's have only updating chat. Snap 2, Sparse on DevNet. Alright, nice. Yeah, I'm just curious, in general, in the light of these, partial messages and partial pool updates. Does it make sense to start conversations around the next BPO efforts, or it's too early, maybe we should just…

observe, like, the… Well, this partial post is not on the mainnet. I think for the partial messages. some nodes already on domain, if I'm not mistaken. But anyway… If anyone has any thoughts on that, Because I think the last BPO of fork was somewhere around January, if I'm not mistaken. And… Well, everyone is just so focused with Glamsterdam, and maybe that's not, the… reverse right now. Okay, yeah, maybe. Let's get back… a bit later for these conversations. Yeah, let's proceed with Waggle protocol. Yes, Sukun, do you wanna… We started?

Sukun Tarachandani: Sure, yeah. So… The issue is that, yeah, everyone who might have an opinion, I've already talked about the protocol with them. So, I'm not sure if this is new information for a new one, but sure, I will go through Thanks, QUICly. I am audible, right?

Daniel Knopik: Yep.

Sukun Tarachandani: Yeah, so the aim of the protocol, broadly, is that this is gossip sub B2, And, like, if you read the gossip-sub specs, the aim was that it should be a baseline protocol for PubSub, on which you can build your own nicer PubSub protocol, more fancier protocol. But the problem was that it either did not offer the correct primitives, like topic streams, or… as we saw partial messages, or it offered some primitives which were just not working, at least for Ethereum, like a message ID, which is very closely tied to the set of bytes and, like, the hash of it. like, the scene cache and everything, which makes things very difficult to override. And, so, we have started moving away from these sorts of limitations by partial messages and topic streams.

And the idea is that, okay, at this point, yeah, basically we start with a clean slate and put Roughly have a protocol which is equivalent to partial messages and topic streams, but without the burden of… One backwards compatibility, and two… some of the other things which we felt went wrong with gossip-sub, so I'll just very QUICly go through them. Yeah, so one thing, just at the start, this is, like, very orthogonal to what your connection to the peer is. Like, it really does not matter if your connection is a QUIC connection, TCP connection, carrier pigeons, multi-stream select, edge 3 streams. Like, whatever you give, like, a broadcast protocol can work with any connection, right? Yeah.

So, like, we can run this on lib P2P, and then when we get ETH P2P with a fancier protocol select, we can just move to those connections. Like, this protocol has nothing to do with The transport that the peer is talking to us on. So, some things that we want to, like, have in Waggle and, like, fix in Waggle, like, the details of the spec car and the specs link. please, like, engage there, and we will keep on, like, iterating. These are very… this is a very early spec, we'll keep on iterating, but yeah, that's the place for discussion. The other thing I'd like to also say is that we can move this spec discussion to data P2P if people want to, like, break away from lib P2P sort of thing. Yeah. So QUICly, basically, yeah, the idea is message semantics should be in the application, like, think of aggregates, I feel that's, like, the best example.

Currently, there are 16 aggregators who send only 2 or 3 distinct aggregates among them. But for gossip sub, these are 16 distinct messages, and there is no easy way to hack the message ID function to make them as 2 or 3 distinct messages only. You will end up sending all the 16 distinct messages, because on the wire, they are distinct, as the selection proof of the aggregators is distinct. The other part is peer scoring. This is also something that application needs to control, because different applications have different requirements, and in general, application also wants to do a lot of cross-topic peer scoring, basically. So, like, yeah, it's roughly… this should be in the application. To the question that, are we losing out on the fact that if gossip-sub has this handcrafted application scoring logic over theirs.

My opinion of it is that if that logic is so important, we should provide it as a library, not as a framework that you opt into. So it should be, like, a library that you can use if you want, otherwise, like, discard, but the ownership of the thing should be completely in the application. More contentious, consider removing a fixed mesh, and just forward to a random peerset. I do think we can make this work, like, this is what EC-broadcast also does, it has no fixed peer set, and peers just randomly push. The only problem is that you need to ensure that you have a sufficient set of peers, so that you are eventually picked by that peer's random broadcasting logic.

Yeah, basically, yeah, the biggest reason why we are doing this, because, like, the performance, I expect, will be equivalent to this sort of thing, with topic streams plus partial messages that gossip gives us. But the biggest reason is that once we moved to Waggle, we would have dropped a lot of code. And, like, it would have simplified a lot of the codebase that we have currently. This does… make the upgrade path slightly difficult, but I don't think this change that we need to upgrade, which is tune the mesh size of gossip-sub, basically application needs to tell the gossip-sub that change your topic, attestation topics D value to 8, to 6, to 12, whatever it wants to. It is a small change for gossip-sub. I can't imagine why other people's change would be large on this specific thing.

And yeah, of course, like, one of the reasons why we want this is that, yeah, basically. We have a… there are a bunch of places where we have a large message, where the chunks of the message are meaningful, and we can verify them independently, and we can… like, distribute them independently. We see this with attestations, where, strictly speaking, it's… they are all separate messages, but we can still combine them and look at it as a single message. Same way for data columns. In principle, you can run EC broadcast on top of this thing, and, like, yeah, so also get the benefits. And, like, yeah, the whole point is that if you think of a baseline broadcast protocol, there are only… there is only so much design space there. Like, if you say message semantics in the application, what you want is a way to make topic

topic streams to the peer, and these streams should ideally be of two types. One is, like, the exact data that you're sending, and the other is control, which is, like, your state of that message, or your state of that slot that you're syncing with the peer. And I think we can get there, yeah. So, the specs are here… I will, yeah, now take questions. I hope that did not take too much time, because I think everyone has this context already. Yeah, shout us.

Aarsh Shah: I have a question. So, I discussed this with Casey… You know, when we met up internally, and… Why do we need topic streams at all? What does topic mean in this world? So, we are just designing a PubSub library that is specific for ETH. Now, all our PubSub semantics right now is either pushed to everyone. That you are connected to, like, blocks? Or it's request response. Like, data columns where, you know, we can use partial messages and have, like, these bitmaps. Are you in attestations? So, if it boils down to either send it to everyone, or send a request and get a response. In that world, why do you need this topic abstraction or per-topic stream? Because

At the ENR layer, you already know which peers can offer which topics, right? You know which peers custody which data columns, their attnets, their syncnets. So, when I get an ENR record and I connect to that peer, I kind of already know what they're offering, what messages they'll be able to give me if I send them a request. In the request response world. So, can we, like, design this such that there is just one stream, one topic to rule them all? You still need to score per topic.

Sukun Tarachandani: So…

Aarsh Shah: Yeah, you get what I'm saying? Like, what is…

Sukun Tarachandani: I get your point, but the whole reason why you want different streams is that those messages have different priorities. So if I'm sending the… a block to the peer and a attestation to the same peer, I don't want them to be head offline blocked with each other, I want them to travel parallel so that the peer gets the attestation in parallel to the block. Does it make sense? Like, if…

Kasey Kirkham: Could you…

Sukun Tarachandani: Yeah.

Kasey Kirkham: inside of a single stream, I guess, how does the multi-stream, you know, semantics, enable that? And remember that we're talking about, like, in a QUIC model as well, right?

Sukun Tarachandani: Yeah, yeah, so in the… that's my point, basically, that… so you want to send a block to the same peer and the attestation to the same peer. You don't want the attestation to wait for the block to be transmitted completely. So, you basically send the attestation on a different stream, that's… sort of what QUIC streams offer you. So your attestation will reach the pier in parallel with the block.

Kasey Kirkham: I guess I don't know where, I don't… does the application ever convey the relative priority of the streams?

Sukun Tarachandani: You can convey, but it's round robin, so it also works that way. Yeah, it works fine with that. But you can convey the priority that is actually in master in go-quic, and we'll start using it soon. Yeah, but you can convey. It's actually, yeah, so… so the rust-QUIC ecosystem is much nicer, they can convey it today, and they can get done with it. Yeah, unfortunately, QUIC Go and even the Go and QUIC did not have it yet, but now they have it, so we can do this.

Kasey Kirkham: Okay, yeah, that makes a lot more sense. Yeah, and I suppose that the, that the stream is, essentially just, an abstraction, you know, it's essentially a field on the, on the messages, So, so, so there's not really any costs to it.

Sukun Tarachandani: Yeah, basically it's, It's entirely at the QUIC layer, so yeah, there's really no cost to it, in the sense, if you are sending on the same stream, your frames will still contain stream ID 3 or 4 or whatever. Now they will con… like, different frames will contain different stream IDs, so there would… there won't be a wire cost to it over the other things. Having said that, a separate design where you say, if you want a stream per message, that also makes sense, and we can consider it.

Kasey Kirkham: Yeah, I did think, you know, I wonder if there could be some benefit to, Combining certain messages, Yeah, maybe… I guess you'd have to look in detail at the sizes of all these messages, But yeah, I think… I think I'm gonna have to go rethink that… that point, based on what you just said. I didn't realize there was any way to control prioritization, so that actually is pretty important.

Sukun Tarachandani: M… Yeah, yeah, I can share the QUICCo thing here, but yeah, now there is priorities in QUICCo, so we can do that. And the Rust ecosystem definitely has priorities. Caba?

Csaba Kiraly: Yeah, so yeah. Yeah, I wanted to speak about the fixed mesh versus random forwarding a little bit.

Sukun Tarachandani: Oh, oh yeah, sure, go ahead.

Csaba Kiraly: Yeah, so one of the… data-flow routing is working very well for some applications, like streaming. What you lose there, typically, is… So there's two things. One is… is the… SP scolding becomes… Much less tight, because you don't have the symmetric relations, and that's a usual… difficulty with… With random forwarding-based schemes. And, yeah, the other one is… I don't remember what was the other one, but, but, scrolling is, is definitely one, something which… which we should be prepared. If, if we go with the building, then we should be prepared to, to handle that, to zync that a little bit, because the… The mesh has… has this advantage, that you have these symmetric relations, you have,

the… you are getting… a constant feed of information from the LLP, then it just… it's just the title loop. The other thing that we have, for example, in the Mun pool, is the… is the sequentiality that you are using… losing withding, typically. So that depends on the application, but for example, in the case of the mempool with the noses, it's something, that matters, and that's why we are not doing RANO for voting, but we are doing, Kind of, A systematic choice based on some little bit of the message, that being the… the original… Sendal, of the transaction. So… Yeah, just, if we go and evaluate those two, just keep in mind that there are these two things, which…

Which would suffer if we don't have the fixed mesh. Otherwise, I'm a big fan of the wording.

Sukun Tarachandani: Yeah, cool, thanks. So… Yeah, this is something that will definitely depend on simulations, whether this is working for us or not. Like, it… in terms of implementation, it is just so simple and nice, so if we can make the circuit, it would be really great.

Kamil Salakhiev: Sukun… this thing should not live in libp2p at all, I mean, it just could be built on top, right? So there shouldn't…

Sukun Tarachandani: So, it will all… yeah, the API will certainly be… add peer PLIT, comma connection, whatever connection you give, whatever PRIT you give, and completely independent from the P2P. So you can give it a raw QUIC connection, you can give it a TCP connection, whatever connection, as long as you can open a stream on it, that's fine, yeah.

Kamil Salakhiev: Yeah, nice. Maybe we should specify that in…

Sukun Tarachandani: Vesh? Yeah, that's why I mentioned the specs bit, that we can move the discussion to… Entire B2B. To FOCIL, yeah, my point is on… the fact is that HTTP3 has a RFC which says this is how stream priorities should be for HTTP3. What QUIC stacks do is they just expose that same API for QUIC streams as well. Let me find the RFC chat QUICly. But the priority is simply stream.setPriety. That's led by EIP, sorry. So… the thing is that there is no… Priority RFC for QUIC, so everyone, like, chooses their favorite API, sort of, and most people settle on the HTTP one, because it's at least somewhat standard.

This one, yeah. That is it. So, but this is all… very heavily work in progress. Like, it would have been nice if Raul and other CLs were here. Like, I have talked… already talked to, like, Prysm and Lighthouse is definitely on board. They are the ones drafting it. So, yeah, I… I would like to understand what other CLs need here to be more convinced of this.

Daniel Knopik: Maybe they'll be here next time.

Sukun Tarachandani: I mean, okay, yeah, that is the… brute force method of individually calling them. We can try that. Yeah.

Kamil Salakhiev: Yeah, I'm curious, like, what also the update path could be. I think Aarsh mentioned that we might Have, like, backwards compatibility somehow. But I don't really see, I mean, how… Some people…

Sukun Tarachandani: Just if they are.

Kamil Salakhiev: only support Waggle, they might… I mean, do they… I mean, do they, like, have both… do they use both gossip Sub and… this Waggle at the same time for some period of time, or how it's gonna look?

Sukun Tarachandani: Yeah, so the plan is that, basically, via the ENR, we know whether the peer supports Waggle or not. If they support Waggle, you talk to them on Waggle. If they… yeah, if they don't support Waggle and you support Waggle, you talk to them on gossip sub. The problem with this plan in, like, this fashion is that you will end up increasing your bandwidth usage, because now you have a set of Waggle users and a set of gossip sub users, both using, like, if we set the same forward multipliers, a D of 8, basically, right? So you've sort of doubled your networking requirement for that topic. So it would be nice if we can somehow just reduce the gossip sub topic mesh size.

like, yeah, pass this information to gossip-sub that, okay, I have a few Waggle peers, so I would prefer having fewer gossip-sub peers.

Kamil Salakhiev: Hmm.

Sukun Tarachandani: This one…

Csaba Kiraly: SC.

Sukun Tarachandani: I hear.

Csaba Kiraly: Yeah, that sounds messy, because it also interacts with peace calling and all kind of… You know, the cyclical. syncs, what's with the RPCs, which still go with the… with the higher degree. Because they don't support this, or do we make them contribute less? So… Yeah, that won't be an easy ride.

Sukun Tarachandani: I didn't see, I mean… I'm not sure if we can do anything else here, is the thing. Like, this is also what partial messages does, by the way. Like, it's still…

Csaba Kiraly: I see…

Sukun Tarachandani: it under gossip sub, but it is exactly what partial messages is doing currently.

Csaba Kiraly: Yeah, but this is a bigger change. For real, I think we need… a good… Implementation first from someone, then lots of testing. On… with that single implementation, and ironing out everything, and then basically switch over the other one.

Sukun Tarachandani: Hmm… okay.

Kamil Salakhiev: So… so more like a hard fork. Is that what you say?

Csaba Kiraly: Yeah, more like I thought, but also before that we need… we need one implementation to be, High quality and tested in lots of distributed settings. Nothing about interoperability, just the actual protocol design. Gives the performance advantages, and… Has no, Shortcomings, or backsides, or whatever. Yeah, I think we should go that way.

Kamil Salakhiev: Yeah, Sir Casey?

Kasey Kirkham: I had kind of, like, a question about QUIC, So, when you're… tweaking priority, you're messing with, is it, like, max data? And I was just wondering, I assume if the sender is ignoring that. Ignoring your flow control signals, I guess. we'll go QUIC, just terminate them, or, is there enough, information bubbling up to go to the BTP to integrate that into peer scoring?

Sukun Tarachandani: I'm sorry, I missed that question. Can you repeat?

Kasey Kirkham: Yeah, just, like, thinking more about the premise of, like, using, QUIC to manage, like, head of line blocking and prioritization, I'm just wondering, if you have, like, a misbehaving peer, does libptp have access to the information about how the peer is, ignoring the prioritization signals so that it can downscore them?

Sukun Tarachandani: Good question. I will have to check.

Kasey Kirkham: Because I'm guessing go-quic probably just, like, terminates the connection or something, you know, and then they, like… Connect again. And then it's, like, outside the scope of… or the view of, Lib ETP, you know?

Sukun Tarachandani: I think so, yeah, possibly.

Kasey Kirkham: Okay.

Sukun Tarachandani: That's it, like… In terms… you can only control priorities on the send side, basically. Yeah, what a peer does, basically, you generally can't control on the priorities then. Because you want to send two pieces to the peer, and you don't want one to wait for the other, which, like, has a higher priority than the other, say. So… Basically, on the send side, you control whether message A has a higher priority or message B. we can… We do… we can inform the peer of our priority, and if they don't… Prioritize. Maybe we can detect it, but yeah, I'm not sure if the details of go-quic offers this API.

Kasey Kirkham: Okay, yeah, we can follow up.

Sukun Tarachandani: Yep. Oh, yeah, good point on the score.

Kamil Salakhiev: Okay, nice. Yeah, I think we definitely need to discuss more about that. Yeah, maybe we can… yeah, I can QUICly touch on some updates on… Why is that, Aarsh? I can put a touch.

Aarsh Shah: Bye, Ben.

Kamil Salakhiev: I guess it's just recognition of the, whatever. Some feature, yeah. Yeah, we can QUICly touch on, blobs and blobs. Yeah, just had some new input, maybe, I don't know, people would be curious to… Learning about, like, Yeah. So basically… Yeah, the initial idea was that… yeah, I kind of presented this on ACDC, I'm not gonna repeat it too much, but… Yeah, basically, we could, like, kind of, like, reuse the existing column subnet topics to, also distribute execution payloads, and we can kind of use partial messages for that, so that appears only, like, signal that… For some topics, they're only interested in the first, like, n rows that correspond to execution payloads. Yeah, kind of… There was a feedback that, yeah, we might actually need to split

these two, kind of, topics, I mean, not to… Have, not to reuse column subnets for execution payloads, but rather introduce a new set of topics. And there also was some… some new input. I guess it's kinda… if we do that, what we can is, yeah, we can optimize, actually, some stuff, because, like, for column subnets, today we use KZG. And we use that for multiple reasons, so we can, like. check not only that an individual cell corresponds to KZG Commitment, but also, like, we're ensuring that Basically, a recording was done correctly, all the properties. And if we think more about that, we actually don't need that for… execution payload, because if we do that, I mean, builder would need to, once it encodes the data into subnet… well, into columns, then extends them, basically wasting some time for, calculation of all of these

KZG proofs, and… Yeah, that's kinda like… I don't know, around 100 milliseconds or more. Yeah, what we can do, and it's actually… Very aligned with several staff. Is instead just do… Merkle root commitments, and… Yeah, basically, like, for each column, we have column root, and then for each route, we also, like, put them into some global payload route, and this payload route can go into Payload beat, and… And then the message, the payload partial data column sidecar, would look like, basically very similar to data column sidecars, but we don't use kzg proofs, but we use Kennedy's Merkel proofs. So, yeah. And… this kind of makes sense from multiple perspectives. I mean, yeah, first it's cheaper. I mean, builder would not need to kind of spend so much time for this KZG proofs calculation.

And also… If you're paying attention, there was recently a proposal about Lindia. And, basically the idea there is… Yeah, we're replacing kzg commitments because they're not post-quantum secure. We've… Merkle root commitments. plus… There will be a snark. Which is LeanVM proof. And the… Yeah, I spoke with authors of this… Eth research post, basically. So, the message actually is gonna be. Well, what would go into the sidecar message, in that case for Lyndia? is actually exactly what I described here, because, like, yeah, we're doing this… We're doing, actually, two things here. We're doing… Column? commitment via Merkle, and also raw commitment. But the raw commitment is only needed for snarks, and, kind of for ensuring that, well, basically, error recording was done correctly.

We don and yeah, for data columns, we will… only include, basically, this Merko Proof. Instead of KZG proof today. Because, like, if we… Yeah, if our Validator has the… The snark? If it has the… this global route, And then it has the… Merko tree, path, basically this Merko proof. Then it can prove that, well, individual cell was Properly, well, committed and verified this cell. So what I'm saying is basically. If we go into… if we actually use for… if we actually use payload commitment, well, this Merkle commitment, for payloads today. It's gonna be a very easy path for us in future when we switch to Lindia. And, Yeah, and it also brings, like, other advantages, which I mentioned, like, no, these expensive KZG proofs calculations.

This actually could be a good foundation for in future work, because, like, this is actually how, column subnets for data is gonna look like. So, yeah, it's kind of… so when we have mandatory proofs and we only, like, need to custody But we don't need, like, the full execution payload, well, we don't need to subscribe to all execution payload column subnets anymore. Yeah, basically, data columns, they will use exactly the same mechanism. Yeah, what I'm saying here is, like, yeah, we can… yeah, because, like, people… there is a question, like, why not just use a z broadcast here? And it might be a good fit here, but… We… if we use, like. if you broadcast, like, some arrests, whatever, like.

Instead of this columns mechanism. Yeah, we will introduce it, but we will replace it once we have mandatory proofs and ZK EVMs. And, yeah. kind of, like, reading a bit more of what's going on in Lindia land and, like, Hmm, yeah, where are we going? From my perspective, it kind of makes sense the most, to be honest. Yeah, basically, that's all I had. Yeah, if… Yeah, I will update the EIP. Yeah, maybe gather some more feedback. With that idea, not yet, anyway. Just wanted to share. some update on that, so ERC people have some thoughts. Yeah, Daniel?

Daniel Knopik: So, if I understood you correctly, you do not want to erasure encode the… Payload.

Kamil Salakhiev: We do it… yeah, we do it… we basically do the same as we do for blobs today. We basically represent our… Payload in blobs, then we extend it. And then, yeah, we do this multiple tree commitment instead of KZG.

Daniel Knopik: Alright, Okay.

Kamil Salakhiev: Yeah, sorry, I missed it. There are other questions. 3 is not proving our rust extensions correct. Yeah, it's… it is not proving our rust extension's correctness. But I think we don't need this, because… Yeah, we cannot, when we receive individual columns, we cannot ensure that, basically, error coding was done correctly, and these column cells, they actually correspond to properly extended blobs. Not blobs, but payloads, in that case. But we don't need this, because, if, eventually this… Column data is garbage. then… Yeah, PTC members, they will not be able to reconstruct, and then they will not basically commit that, well, they, they absorb the payload, it is valid. So… you know, we don't need that in my… I think, like, we… which is why… because we have… exactly because, like, we have this PTC members protection.

Csaba Kiraly: Yeah, so for the full payload, I don't think we need it. But… If we do this… with the argument that then we will need it for sampling. For the sampling, we will need that correctness. No, for sampling…

Kamil Salakhiev: Sampling will… will not… yeah. For some reason.

Csaba Kiraly: So that…

Kamil Salakhiev: Yes, something will be needed when we have mandatory proofs.

Csaba Kiraly: Thank you.

Kamil Salakhiev: EVMs, and basically, yeah, and we need to kind of… we'll be putting this, execution payload into custody columns. Yeah, then we need sampling, and the sampling and recording coding will be proved via snark. So, we're not bothering with that much now, but… The interesting thing is that if we do this Merkle commitment. then the message will look exactly, actually, how it's gonna look like in Lindia. Already. And then, yeah, future transition will be super easy. Interesting. Daniel, I see your hand, saw your hand.

Daniel Knopik: Yeah, yeah, never mind.

Kamil Salakhiev: Okay. Merkle for those two. Yeah, in Lindia, we do Merkle 3… Yeah, with Merkle on top of Rose as well. But this is only needed for the snark. I mean, I don't want to, like, misinterpret like, what… how Lindia works? but yeah, I spoke to… towel and long, and they said, like, yeah, basically for… the commit… I mean, for the proof that goes into this column sidecar message, yeah, we only need the Merkle proof that goes via this, column I would say, like, via this proof that goes to… proofs for columns, yeah, we don't need, like, the proof for rows in the… in this proof. I mean, in the data column. So, I'll spacing a little bit.

It's because… Yes, for s… For cell-level splitting? Actually, yeah, speaking of that, yeah, with this approach, with Merkle commitment, we can also do Partial messages. Because, like, one option could be just, yeah, we signed the whole column. But yeah, we cannot then… we cannot, if we receive just individual cells, yeah, we cannot ensure that they are valid.

Csaba Kiraly: So…

Kamil Salakhiev: Yeah.

Csaba Kiraly: Yeah, my understanding is that one of the underlying assumptions is that you basically prove the correspondence between the the different Merkle. proofs via ZKPs. And that's… that's why you can do things, but that's not cheap. So… so you don't have the… the symmetry and the homomorphism of the KZG. you are using Merkle sleeves, but then you don't have the homologue properties. You have different things on those and columns, and you have to prove, a few things. For example, the correspondence of the two, you have to prove Yeah, and just… a few things needs ZKPs there, and let's see how the costs play out. I think it's… it's… a bit more expensive than just playing with KZG, so we will.

Kamil Salakhiev: Yeah, well, it is expensive.

Csaba Kiraly: We want to tell, and we have to play it out, basically, what are the prices and what other adoptions exist.

Kamil Salakhiev: Yeah, well… well, the good thing is, like, we only need a single snark proof plus this global route that goes into BID eventually. This is some… Bright future. But the bad thing is this LeanVM proof is, like, between 128 to 512 kilobytes, depending on the exact scheme that… will be used. And that…

Csaba Kiraly: They're just dead…

Kamil Salakhiev: Much more than… acted. Yeah.

Csaba Kiraly: If it's operating on a large amount of data, it's… it's proportionally expensive.

Kamil Salakhiev: Dude, exactly. Yeah, yeah. Yeah, there's also, like, this thing called… yeah, they're measuring in the post also, like, the performance, like, how much how long it basically takes to come up with the snark for different sizes of data, depending on different parameters. But yeah. Anyways…

Csaba Kiraly: That's also not cheap is kzg, so we are choosing between expensive and very expensive. compared to that, the… yeah, so we have a few, I think, a few options on the table.

Kamil Salakhiev: Yeah,

Csaba Kiraly: I think we have to, kind of, Map it out nicely.

Kamil Salakhiev: Yeah, main point is being, like, we… Yeah, we kind of need this segmentation for the payload. In my opinion. Yeah, we kind of need to come up with the exact scheme. I mean, yeah, this is still, like, some proposals, ideas, so yeah, definitely, like, the opinion of client scheme and everyone else kind of matters. I'm not saying, like, we don't need EC-broadcast, I'm just saying that if we introduce, for example, EC-broadcast for payload. It will be then replaced by the kind of similar mechanism, because the payload will eventually go into column subnets. But AC broadcast still kind of need it for things like, I don't know, maybe linear proofs propagation, or… Some other heavy data.

That, yeah, that is not basically… cannot be put into this column structure.

Csaba Kiraly: Yeah, I think one of the… One of the questions is how much Teams are eager to… To do segmentation, and… And get the benefits of not doing the stolen folder that we are doing now. Because… I think it kind of was so… Decides how much… how much you push on this? I think it would be really good to… To find a way, a glean a way to do the segmentation, at least. As soon as possible, and… The closest fork we can, because we are suffering from the delay of the… of the large message diffusion in… in different parts of the… of the system.

Kamil Salakhiev: Yeah. I was asking about, like. General segmentation for any kind of message or for the payload.

Csaba Kiraly: But the… the big one that we have at the moment is a payload, so… so I think that's the, like… That's what we should address. But we are also introducing new ones, obviously. But I think it's the payload where we know that we would gain a lot from segmentation, and there are different ways of achieving it. And basically, just the question is how much teams would be eager to jump on a scheme that we… device, to get… lower delays.

Kamil Salakhiev: Right. Yeah, just speaking of, like, how much effort would be required implementing that, there is no EL changes, which is a good thing. This whole thing could be done on CL, purely. Because, yeah, we're basically changing the bit structure, we… Introducing new topics. And other than that, yeah, basically, yeah, getting the execution table from EL and just segmenting it into columns, and then propagate. Yeah, sukun will be talking about the second. to compute the proofs described in India, right? Oh, I need to check in our school. Yeah, there is… it's research post, if someone could QUICly find it.

Csaba Kiraly: Mostly hardware which was used in that post is something like 16 or 32 cores. machine, so… and there's a large amount of lamp, so I think we should carefully look into those numbers.

Kasey Kirkham: Yeah, when I've looked at some of these, like, Poseidon-type schemes in the past, it's, like, yeah, very, very CPU-intensive, takes… takes a lot of time. So, if it's something that's happening, you know, on the slot. network deadline, that… but I guess we don't really need to actually do those proofs, kind of to Caba's original point, in order to use it for, distribution, just for, DA, and we don't need to do DA on the execution payload, because we can prove it.

Kamil Salakhiev: Yeah, we don't need now. But eventually, Yeah, we might. Searching for another day. Yes.

Csaba Kiraly: Yeah, but that is definitely a question about, how this… Interests with self-building in the future, if you would have to do that for the blog that you build.

Kasey Kirkham: Yeah, the premise is that, like, an advantage of this is that it's gonna slip right into this future scheme, and… but then the future scheme is, like. You know, questionable in its, Practicality, in terms of time, then… then it might be worth… Making sure we have the right projection for how that gets optimized.

Kamil Salakhiev: Hmm. Right. Yeah, one concern could be, I mean, if the execution payload goes into good data columns, and they are committed via this snark proof. Then the builder, yeah, kind of has this delay. Which is bad, but… I don't know, maybe there will be some more discussion throughout that future.

Kasey Kirkham: Yeah, I feel it.

Kamil Salakhiev: I mean, just doing the.

Csaba Kiraly: That's true, that'll be.

Kamil Salakhiev: Yeah, yeah. Maybe they can just, yeah, commit via Merkle in the beginning, and then… create… I mean, and then start propagating the beat, whatever, and… after… Yeah, just, and the snark goes after that. I don't know.

Csaba Kiraly: I'm looking into the direction of mixed schemes, where you are not… doing the… The post-continue. resistant part for the… for the Lloyd short time stem distribution, and you're kind of delaying The part where you need. the Beaconis. On a different timeline, but… Not sure how that works, just it's… Yeah, definitely. It's a general technique, to use cheaper encryption from FLM keys for short-term things, and then put another envelope on top, basically. For the longer term. So that's the direction I'm trying to explore.

Kamil Salakhiev: Nice. Yeah, I think we need to kind of consolidate our efforts, because, there will also be this EIP about, Lindia, sometime… at some point of time. Yeah, also, like, just ensure that… You already wrote us, Caba, also. Aligned with all of that.

Csaba Kiraly: Yep.

Kamil Salakhiev: Yeah, just kind of, like, putting everything together. Makes sense. Alright, I think that's all we have. For today, unless there are any other questions or topics? If not, yeah, then thanks everyone for joining. See you in two weeks.

Daniel Knopik: A…

Kamil Salakhiev: Bye.

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