The Evolution of Ethereum's P2P Protocol Landscape

Transcript

Hi. Hello. So, I'm Chaba Chabakai from the Go Ethereum team. Uh, I will talk about the Ethereum protocol landscape, the peer-to-peer protocol landscape. I'm calling it landscape uh because depending on who I speak to, I see different views of what's in uh the peerto-peer protocol. So we have quite a number of complexity in the P2P protocol landscape. We have the E networking with its discovery dial sync and then the manpool and then we have the CR networking with again it's discovery dial sync and then it does the uh block diffusion theestations the attestation aggregation and the blob dispersal and then there's the connection between the two which is also part of this protocol

landscape I would call the engine API. So when uh then this all together should work on top of uh a number of uh things. So we have minimum node requirements, we have node heterogeneity and number of nodes and then on top of this we want to scale right. So when we scale any of these could become a bottleneck and uh that's a bit of problematic because often we just speak of one of these things and then it seems like super scaling uh but then one of the others comes a bottleneck. So let's see a little bit them one by one. So uh let's start with discovery.

Uh often we think discovery is slow. Uh discovery is finding other peers and that's sometimes a problem. Um so we do things about it. Uh we have solutions. We are moving uh for example in DL from discovery v4 to discovery v5 which is faster and uh this year was already starting with v5. Then we have something in in discovery uh v5 which is called topic search which we are not even using and we can enable. And then the last thing about discovery is that it's actually not slow. So there you can find a link uh I was crawling the whole network in 50 seconds. Uh so if you want to find peers you can you can find them fast.

Then there is dial connecting other peers uh very important in peer-to-peer networks. And if you are uh working on these clients, you often notice that uh you cannot connect because everyone is full. They just don't let you in. So uh dial is about uh making dial be possible. And we have a few solutions here. Uh we have problems here and then we have improvements. Problems in the sense that dial is slow that you see on the top. Uh that's the dial progress. And what you see on the bottom is is dial progress after a few changes. So solutions here are kind of changing how we manage the peer pool separating inbound and outbound peer pool. It's already there in all the clients and then we have to do things uh that are typically peer-to-peer. So you have to

drop peels, you have to score peels uh and you need kind of protected peer pools for the peels which are actually useful for you. So this is dial then there is sync. Uh so syncing means syncing state uh syncing the uh the block history. Uh but the important thing about sync is that there are kind of two different use cases. Sync when you are just one node starting up and that's what I call node sync and then there is sync when you sync because of some other event some external catastrophic event and that is everyone syncing. Uh and the second one is more of a problem. So the node n note sync is more of a user experience

problem. Uh how many time how much time you need to actually be part of the network sorry system sync is instead a more of a system level problem uh and it becomes a scaling problem. What if we scale the throughput and then your system syncs become uh much heavier and then we might get into a point that we cannot sync all the clients at the same time. uh we have ideas here too uh for solutions. So uh one thing that we can do here is what I call swarming sync. Uh so sync now is done in a way which is uh just linearly syncing typically. uh but you can do syncing in a way that uh the

syncing nodes are kind of forming a swarm kind of bit tolerant swarm uh uh bit to like so as is done there and there are the standard techniques there uh which were developed like 20 years ago uh which we can use so we can uh we have to send a sync state and that's already introduced in the network this was part of E69 uh with the block range extension and then we can add on top of this we can do peel exchange uh we can do uh peel chunk scheduling uh and these can improve sync speed. So we can do things about speed uh sync. Okay. So after this style of three different things let's see what we have next and let's take a bigger topic

the meool. So the meool uh first of all we have to know how the meool works and what's in the meool. So this is a uh a graph and it's just one day of samples. So don't take the percentages like super serious. Uh but this is one day of what's going through the man poolool. And on the left you see the ratio of transactions uh per type. On the right you see the same weighted by the size of the transactions. So by bytes. So what you see is that obviously blobs are the the big ones and type two transactions are the many ones.

And then this is another view. This is how many transactions of all the transactions that will make it to the block uh one of our a node is receiving. So this is how many you received of different types and then we see oh we only received 50%. But that's because only 50% was public. So uh the meool actually if you if I just switch back and forth a little bit you can see that my node is basically receiving everything that is public through the meool.

This is another view of the same thing. This is a distribution of how many nodes received a given transaction and what you see if you would if it the transaction itself would be on the left that would mean it's a transaction which no no one received and I was not putting the zo I was not putting in this chart the private transactions because we are not interested in those uh here from the meool perspective I was just putting those that were hitting the meool and once a transaction is hitting the meool everyone is seeing that transaction that's what you see in the right like a one there means everyone has seen the transaction action before it was getting into a blob. So we can basically say say that our meool is fully synced uh in uh currently this is another view of how the meool

works. Now so what you see here every single line is one specific transaction and you see the timeline of spreading the spreading in the meool uh down below what you see is uh the time before block inclusion. So if you take one example uh that was hitting the meur 12.5 seconds uh before uh before it was included in the block and then it was splitting and in 10 seconds 85% of the E network seen that transaction in the man pool so it is spreading fast this is not meant to be fast here we are not on the fast pass but it's it's sufficiently fast and even for the red ones for blobs you see that they are splitting fast

uh we can show this in Another view here I was putting everything with a start line of zero. So zero is when you were hitting the man poolool and then everything is is going relatively fast and then we can look at another view here. What we see is uh the blob transactions based on the size. So in a blob transaction you can have 0 to six one to six blobs and uh based on size they are splitting up the bigger ones are spreading slower but they are splitting quite fast again like in 2.5 seconds they are spreading in the m poolool okay uh so this is good uh but this is with today's traffic if you want to scale the meool then we have to do things so today we have this kind of globally synchronized meool

tomorrow we have to do something and uh Here what we can do is uh we can introduce what you call horizontal sharding. Horizontal meaning that uh we are sharding by transaction. So this transaction is stored in this part of the meool. That transaction goes to that part of the meool. And here we can do sharding based on transaction has based on uh sender address. There are different ideas here. And then we can do something like vertical sharding. Vertical sharding means and this is specifically for the blobs. The blobs are already segmented because they are already coded in the me pool and they are already having KCG proofs on each of these segments. So we can just send individual segments and then we can do even sampling in the

meool if we do this. So there are two kind of protocol improvement proposals there. I was giving them also numbers. Uh don't take those seriously. Uh we have to specify them. Uh but we can do things like notifying uh change the notifications adding standard less than nouns uh and then we can do horizontal sharding or we can do uh pural types transactions in the meool and then we can do the vertical sharding. Okay. And now we finished with the uh now we just have the engine API and the CL to go through. So let's see if we can make it uh see our block diffusion.

So uh we went to the man poolool the block was generated. This block has to be diffused and that's a very nice pebble problem. And this is actually a measurement we did two years ago uh when we were adding more and more blobs and uh actually it was before that when we wanted to add them. This was still with normal blocks and we wanted to see kind of how fast they are spreading in the network and so the curves are different size categories uh small blocks medium blocks large blocks if you want uh up to 1.5 megaby complexed and what you see is the timeline up to 4 seconds and and below after and you see that kind of with the

1.4 4 megabytes blocks the system started to have some issues. Below that everything is working in time and also consider that this is not counting like when it was released. So maybe the block was released later and then it was sent. So actually we are splitting it faster. It's just not sent uh at good time. So this was okayish uh but we are improving it that and here I was just putting uh kind of a low latency peer-to-peer toolbox that we are using. So we have a bunch of techniques here. Uh I'm not going into the details of these. Uh first one is segmentation. This is kind of a basic technique that we are using.

Uh when you are sending large messages over a peer network you have the store uh the store forward delay that is you have to receive the large message validate it and only then you can send it. The way out of that is that you are segmenting the message. you are making each one uh durable and then you can reduce this student forward delay. The second one is scheduling and prioritization and for this we develop techniques u the techniques also in literature. So these are kind of techniques known we just have to apply them uh just uh is is a big word there.

So we have to find ways to apply them well. Uh but for scheduling and prioritization we have techniques. Batch publishing is for example uh sending out uh intelligently not sending uh the copies in a in the wrong order. Uh then there is quick transport uh which is now mature enough to be introduced and we are introducing it and this gives us uh in independent streams and prioritization. Then there is the big question of encoding. So the use of coding as part of the peer-to-peer network. It's again something we are not yet using. uh but there are many examples how to do it. So we are doing that and then there are different choices evaluated for the coding that is used lead summon codes

fountain quotes random linear coding etc. And then there is network coding. Network coding uh again was developed in 2005 so it's uh quite long out there. Uh we can eventually use network coding random network coding to do in network recording. Finally with peer-to-peer networks there is always the idea of overly optimizations we have to take it carefully uh it's a easy way to partition the network actually uh but if if you do it carefully you can have performance gains uh with over optimizations which basically means why would you send the same message over the ocean back and forth many times if you can just send it once uh to actually

make it happen in in a distributed way is not that easy uh but you can find optimizations there. Okay. So now we sent our block. Uh we still have our blobs, right? So we have datability DOR dispersal and we have the sampling of data availability uh which is D here. I'm not going too much into the details. Uh we had a post on food uh two years ago I think now maybe no a year ago and a half.

uh and fdas. So pas is what we are introducing now. FDAS is a construct which is doing aiming for 256 props. It is doing a two-dimensional coding compared to the one-dimensional coding that we are using in podas. Uh it already has many low latency peer-to-peer elements in it. For example, cell level messaging. Uh I will speak a little bit about that. I also published an update on this post. So in the meantime, we started to use get blobs. Get blobs is basically passing blobs between uh the e and the cl removing uh an overhead that we had in the system which

is that the e client was getting the blobs and then the cl was getting the same bops uh on on a different pass. So gad gads is shortcutting that and there is a new a proposal to make that uh a better title integration uh with notifications flying between the L and CL and then there are different ways of changing the scheme basically the 2D coding uh instead of using lead sto uh to use zandominal coding or to use zandominal network coding there are a few uh options there uh that you can find in that blog post and I will definitely not have time to go into The part that I want to speak about is uh what we call cell level messaging. Uh

so cell level messaging is if you see it it's it's written there means that you are not just sending out large messages of columns like we do today in podas or entire rows like we do not do it currently. uh but you are considering the individual cell as a message. Cellular messaging is there because it has a bunch of advantages and here the picture is a bit complex because depending on where we introduce sellable messaging as part of the current per design or adding also other things it has different advantages but let me start with this this first one. So if we introduce it as part of the current

period design, if we introduce it as part of this design then we are getting basically reduced to forward delay because we are not sending intel columns but we are sending individual cells. Uh these are already proven they have the KCG commitments. Uh so we can actually do it. Uh this is not a critical now because now our col columns are small. We have six blobs. Uh that's like 12 kilobytes. We don't want to chop that. But if we would have 70 blobs then the column starts to be heavy and then you might want to chop it. So then it becomes critical or at least speeds up distribution. And then it allows another thing uh which is column deconstruction.

So now if we are in a situation when someone has half of the bops and someone else have have half of the blobs in their execution layer and they are getting the CL clients are getting it from the execution layer. One is sitting there with half of the blobs and the other is sitting there with half of the part of the blob, half of the column and they just cannot communicate. They have no way to share this information. Uh so cell level messaging is is one way to actually overcome this. We are developing also other solutions for this partial messages. Uh let's see which one we will introduce. Uh but that will overcome this problem. So we could we would be able to just reconstruct columns on the fly.

Then cell level messaging is also unlocking other things. So uh if we are also adding row topics so that means that the CL is communicating not just sending columns but also sending rows on that 2D structure. Then we get a very nice property uh which is we can also start reconstructing along the coding that was done in the blocks. If we just have load topics, this is just means that we can start to do it. Uh we are reducing the CL load. If you are a full node, a super node which is having all the columns, you don't have to put in the CPU to actually do all the reconstruction. Uh you can just reconstruct a few rows and start to

message those and you can divide the uh distribute the load in the network with this. uh if instead we introduce the 2D zone edure coding in the system we can do cell level sampling and there we are using the cells. Finally, if we are kind of getting to the full picture, we are introducing the 2D lead coding and the low topics. Then we get a very important property. Uh actually two of them. One is that we don't need super nodes anymore. Every single node will be able to to start deconstructing. You are getting cells and as soon as you are having the cells you can start reconstructing a single column or a single row. Even if you are not a super

node getting half of the columns as now in P does and with that we are getting an other important property which I call availability amplification which basically means that there are no situations when in the network you have kind of borderline available scenarios because those are the worst ones for us. uh in a borderline available scenario that is 60% of the blob of the full matrix is available there would be nodes voting for it there would be other nodes not voting for it uh the blob block at the end would not pass uh but it's inefficient because it was actually available it's much better for the system if we are repairing it and everyone can attest and then the block

was becomes actually part of the of the chain rather than doing the work and then throwing it away. So with all this uh we can get to a point where we finish our presentation. Uh thank you and questions. [Applause] Yeah, we don't stay too much time but if we have a little question. Yeah, I don't see the hands if if they're allowed. Yes, they come just quick. How does diffusion in the execution layer meool work? So diffusion

in the execution layer meool is uh is a pushpull pool. So it's we are pushing transactions if they are small we are pushing them and we are pushing them to a number of peels. The number is actually the square root of LPS and we are selecting them with a stable selection and the stable selection is based on the actual transaction sender address and we are doing this because we we want the nouns not to be have no nouns gaps. So we are sending it to someone and then uh those some transaction from the same sender is will travel on the same path. Okay. And this is the push and then there is also the pull p. So for big messages for blobs for example we are pulling okay

which is which is why saying it's it's not meant to be fast it's it's actually slow uh because you have to notify and then they are pulling. Yeah. Thank you. We don't have no more time but uh if you want to ask question feel free to thanks [Applause] [Music]