Reducing PeerDAS Bandwidth Requirements - Daniel Knopik

Transcript

Hey everyone. I'm Daniel. I'm working on Lighthouse and my talk is going to be about reducing PR as bandwidth requirements. Um so first a quick question, who here is running an Ethereum node? Anyone? Okay, and who is running an Ethereum node from home? Nice. Cool. Awesome. Um So I I'm pretty lucky that earlier just had his talk so I can keep the introduction a bit short. So we have these blobs initially during uh Dencun and Electra times.

Um every node had to store and broadcast full blobs, which was actually, you know, a lot of traffic and uh kept the uh blob limit pretty low. And now we move to PR as with Fusaka. So again, we now extend the blobs so that uh if some part of the blob goes missing, we can reconstruct it and through that we can allow nodes to only store slices of all the blobs called columns.

And this is pretty good. And yeah. However, we have the possibility to optimize a bit because every Ethereum node has an uh consensus layer node and execution layer node. And the execution layer uh client has a mempool of all pending transactions including blob transactions. So when a new block arrives, a lot of the blobs in that block are actually already present uh at the local node. And that's nice because we already have some of the data that we need to store. So, in this example, we have already the

data for blob one and blob three, but blob two we don't have in our local mempool. This can be because we've just haven't seen it yet or because it's actually included from a private transaction from a MEV builder. So, after we receive the block, we are going to receive uh the data columns. And what's happening now is that we have some redundant traffic because we already have some of the blob data locally, but we receive full columns. So, the cells So, we call them cells because blobs are the rows and the columns are the columns. So, the cells marked in red here uh is traffic that we receive and

send, but which is already known throughout the network. So, this is uh where we can optimize with uh partial messages and uh partial data columns. So, with this new uh protocol, nodes can now communicate between each other and basically tell the other node, "Hey, I got these blobs and I need these blobs. Uh what do you need?" And after negotiating this, they send only the parts that the other party is missing, saving a bunch of data and the bandwidth uh in the process.

And another nice thing about this is that it's backwards compatible. So, in this network, each circle is a node. Green nodes are partial message enabled. Red nodes do not support partial messages yet. So, at first, everyone is still using full messages, but as more nodes in the network support partial partial messages messages, more and more traffic in the network uh uses this more efficient uh protocol. At some point, hopefully, all of the nodes will support partial messages partial messages.

And yeah, and being backwards compatible means that we are also not bound to a certain fork. So, looking at the timeline here, first we had full blobs, then data columns, and we are not tied to Gleansburg so Gleansburg is hopefully releasing pretty soon, but if not if there's a some delays or something, we can still go ahead with partial messages once we have done all our final tests. And this is also nice because we can gather some data from mainnet how this affects or how much bandwidth we actually save in practice.

And this might inform core devs about potential future uh blobs per block increases. But if you paid attention during Leo's talk, uh you know that it's actually not that urgent to increase the block count. You might ask yourself why though? And yeah, here once again a visualization. It's a bit blurry, but uh again here's a green line. The green line is the target and you see the actual usage in the white area below. It's the same thing Leo showed you. Demand actually goes down right now.

There's no need to increase, but there's still a reason to do this thing. Um home stakers benefit from it. So, residential connections often suffer from some bandwidth limitations and that's not not nice. So, I think home stakers would be the parties that most benefit from this new feature. And in the description of this talk, I promised some numbers like how much bandwidth we will be actually save. And first of all, disclaimer, it's it's really really hard. It's basically looking into a crystal ball. We run some simulations, but simulating mainnet is very hard.

There are like 10,000 nodes. Conditions are varying all the time. So, yeah. Take everything I will say with a, you know, pinch of salt. Um and also the numbers I'm going to show you are not to be seen as absolute numbers, but more like a relative comparison between scenarios. All right. So, first um in a reference network with only full columns in my test, uh it was like hovering around 750 kilobytes per second of uh column traffic.

Uh this is roughly equivalent to uh uh 20 uh blobs per slot. And if we use partial messages now, it actually goes down to around 250. So, uh not the difference to scale. Um and 250 is like a third of 750, which is nice. Um right. And as you as I told you, we actually can have mixed networks, so only some nodes supporting partial messages. And in my tests, uh this one is a bit complicated, but the uh top two lines represent the traffic for the full

column only uh nodes and the lower lines is representing the partial enabled nodes. Which again are having around uh 350, so that's of course higher than uh the 250 for the fully partial network, because these net nodes still need to talk to the full column only nodes, but it's already a pretty good improvement. Right. Uh the lines in the middle represent send traffic, but during preparation uh to the talk, I noticed there's a slight bug in the calculations, so disregard those for now.

Yeah. And that's actually already it. I hope that if you are running a partial home node, you consider running this as soon as it's available. I expect that we will ship a release in the coming months. Um if you have any questions, feel free to ask or get in touch. Thank you. >> Thank you for the time.