Scaling & P2P | Csaba Kiraly - Ethereum Foundation

Up next we have Chaba from the core gas team. He will be talking about scaling and P2P on Ethereum.

Thank you.

Thank you. So yeah, I'm Chaba working on the guest team, but I'm also kind of working on the peer-to-p peeler implementation all over from ER to CL to lean. So yeah scaling uh we are scaling the R1 is scaling the R2 is scaling and we plan to continue this uh right uh and to do that we have this thing the peer-to-peer network that we also have to scale unfortunately or fortunately so for those who are just building on Ethereum uh Ethereum is one of those almost unique blockchains that are actually decentralized so we do tend to run on a beautiful network of 10,000 nodes and each one of these nodes is has an EL client and a CR client which are kind of on the same node between them they are communicating on this code engine API uh but yeah there's a network in between and when we are scaling we have to think of this network and how we scale that and I will be speaking of this so when you are thinking of this peer-to-peer network uh it's not just the peer-to-peer network. It's a bunch of pewable functions. Uh and actually we have two pew networks.

One for the E clients and one for the CL clients. And each one of them have their own uh nice little functions, discover nodes, uh manage the P sets, synchronize the data when you are starting it up and then for the EL it has to handle the meool, basically the life of the transactions before they are getting on chain. And then the CL has to uh handle the uh block diffusion at the station and the dispersal of blobs functions which are needed to actually make the consensus happen. So kind of after the the block has been produced life of the uh of the transactions. There are also a number of protocols.

So uh discovery v4 v5 def on the uh on the side. I'm not going into the details of this one. Uh just appreciate the complexity of the picture. And when we are scaling, we actually have to scale all of these. Now I won't be speaking of all of these.

I will be just speaking of a few uh starting with the CL uh and then going a little bit into the EL. So let's see blob scaling. So yeah, actually I almost two years ago I was publishing a uh a write up on on food which I was updating kind of a year ago. Uh which was a plan to uh get to 256 blobs and we are kind of following some parts of this plan. Obviously plans are changing so other parts are are not followed or changing.

Uh but some parts of this are already going. Uh so we have in this plan we have lip repair in the network which we have now we have seleaging uh we have block coding and then in the second version that I published uh there was also the get blocks an enhanced version of that and uh a random linear coding based sampling. So here you see with green the things that we are basically having now and with blue the things that we are kind of working on and then there's another white ones which are either happen or not. uh we will see based on how uh plans are changing. So a little bit about sellable messaging.

Uh sellable messaging uh is simply uh the fact that we are sending small messages which has uh actually a bunch of advantages. Uh it's an improvement on the on the podas concept that we have now where we are sending whole columns. So a bunch of blobs bundled together then cut into pieces and then these columns are being sent. Uh with cell messages we can uh do more actually we can do less in the sense that uh we have to use less bandwidth to achieve the same function and uh and we can speed up also the uh the diffusion. Then there are other functions which we don't do that.

Uh but what we do uh as we are planning to do now is to add uh low topics. So adding low topics means uh that uh the reconstruction uh which is happening in the network doesn't need super nodes. So what we have currently in the current system uh with pas is that whenever uh you need to reconstruct the blob uh the blobs from the coding then you have to be a super node which is kind of getting all the data and then only those can reconstruct. uh with this little trick we can go into something which is a partial reconstruction which is taking out of picture super nodes which is always nice in a peer-to-peer system even if we don't need it in the sense that we do have super nodes and then server messaging also allows other things which we are not doing yet and we are discussing whether to do things similar to this so the original plan was to do this second layer of lead solon coding and uh another plan that I was outlining there is to do another type of coding which is a random linear coding over the uh the blob content in a block which has advantages. It means sampling can be can use less samples.

It means reconstruction can be uh go easier from from the cells. Okay, that's about block diffusion but we also have the blocks. So let's see block diffusion. Now for block diffusion uh we are doing a bunch of things actually. Uh this is a presentation that I was doing in the lip p2p uh summit on in KHN.

Uh just a slide of it. If you want to see the details, you can go to the QR code. Uh we have this kind of I'm calling it low latency peer-to-peer toolbox. So we have a number of tools that we can use to make the diffusion faster so that then we can shrink the slot time, increase the bandwidth, uh increase the the block size, uh the block size and so on and so forth. Some of them we already did.

Those are the green ones again. So we have batch publishing which is helping us send out things fast. We have quick transport now. And then some of others we are working on. So the the segmentation and the encoded uh sending of the data as you coded sending is something that we are working on now.

Overlay optimizations is something on we are working on down and there are others which we are not working on currently. Okay that's for the CL. Now let's speak about the execution layer. So we could speak about discover management sync. Uh you can find my other presentations on that.

Uh I didn't put a QR code. Uh but the meool is is kind of I think the next horizon uh in many aspects. Uh because in the meool we have lots of work to do. So today if you look at the me pool you see basically this uh the figure is showing you take a transaction and based on how many nodes of the 10,000 has it in their uh in the me pool. Uh you put that transaction either on the right side or on the left side and you basically see that everyone is on the right side which means everyone has all the transactions.

Today the meool is basically fully synchronized among the nodes. If you look at it at a time scale of a slot. So if you would look at just when the uh uh the transaction was sent then obviously one node has it but then it quickly propagates and then everyone has it and that's very nice. We have it for the normal transactions we have it for the blobs. The only problem is that tomorrow this cannot be true because this would mean that everyone is handling the whole capacity of the network and that's not what we want.

That's not scaling. So we have to change this. uh we need nodes to have partial views for the bops and partial views for the transactions. So scaling uh the man pool it kind of means two things. On the left side I have the the typical what people think of we need to use less bandwidths and on the right side I have another more hidden thing uh that is typically coming up in scale scaling when you are designing a system to scale you should think of how it's working when you for some reason you don't have the capacity and you can design it in a way that it's basically has a harsh drop drop in throughut when when you are for some reason this happens there is an internet issue uh or you can design it that it still keeps uh niceoot.

You can think of this at the system level uh where the the whole system should have a superut or you can uh think of it at your nodes level. Your node has an issue. You happen to run it at home. We like those uh you happen to watch a movie which happens to be in 4K and then your node starts to suffer. Uh but you don't want it to drop to zero.

you want it to still work somehow anyway on the left side. So reducing bandwidths uh we did it already on the CL side. Build us was very nicely doing it making it much less and we have to do it also on the uh on on the ER side. Now so what we do on the side uh we have a few proposals there. Uh maybe the most important is pass poolool EIP870.

uh this is reducing the bandwidth in a similar fashion as we are reducing it to the CL somehow. Uh we are having only part of the nodes having the blobs and others are sampling it only. And then we have different shed designs um mostly on on research posts. uh we can think of the sharded blob pool which has different versions horizontal vertical and then uh you can also think of a sharded meool but it's not just the blob transactions the big ones uh but you are sharding the meool in the sense that not every transaction is going to everyone and you are organizing that in a nice fashion and then there's the question of can we really scale well uh uh the problem with scaling again is that uh it's it's nice how we operate with trying to find a limit which is a safe limit. Uh but the problem with this safe limits is is that you try to push them to the right.

The higher the higher the higher and uh and if you have these mechanisms then you can easy it's easier to push them to the right than uh if you don't have these mechanisms. So one of these is uh changing how the execution layer peerto-peer networking is working. It's EIP877. uh changing how we are announcing transactions. Currently we are not announcing just hashes basically and then if you are falling behind uh you cannot really catch up uh with the 8077 you have more information we are sending more data metadata and you can catch catch up uh you can also uh it's also useful to do actually partial state then there is EIP894 which is helping again uh when we have applied volatility it's helping to to use less bandwidths in those cases and then there is the the proposal of BP pool tickets uh which is uh again a nice solution to to reduce uh to to avoid congestion on the network.

Okay. Uh the meool is I said it's it's an important part because it's not just the scaling the meool will be important for for a few other things uh in the following year. Uh there is postquantum and we should handle that in meool. There's the zip proing and it has uh ramifications in the man poolool. There is a counter section uh new type of transactions which are harder to validate in in the meool.

Uh we should handle that. There will be fossil and uh it has its own ramifications to me. There's stateless partial state uh which very much related to meool because again how you know if a transaction is good or bad there's ws for that. And [snorts] then there are encrypted meools. So uh the meur will be I think quite an important part in the uh in the upcoming year.

Thank you. uh questions I think of the stage. But thank you