Insights from block propagation in the Ethereum P2P network by Mikel Cortes (cortze) | Devcon SEA

[Music] hello everyone uh my name is Mikel I'm from prop laab and I'm just going to give you a small insights about the block propagation in the ethereum network so uh as some of you might already know um ethereum at least the consensus layer uses a l2p broadcasting protocol called gosip up to pretty much disseminate all the validator duties over the network um so these makes it like a really essential key component of the of the consensus uh spec because pretty much like the chain finality depends on whether these uh Duties are correctly propagated to the network and on time uh of course every node has to run it and it's even more essential on the scalability road map towards uh p d and full D so um in prob lab we are pretty much interested about metrics about uh protocols with the idea of trying to optimize them and making sure that everything is working as they should um and what we know is that uh these kind of uh Protocols are pretty much interfering with some external vectors like for example in terms of block propagation there are some things like time gamings that take a a big step into when blocks are propagated like some blog proposers are waiting a little more so that they can extract more benefit from the network mbb um but we know also that blog sizes take a lot of um they pretty much Define how fast are these blocks propagated over the network and of course like the topology of the network has also like a big impact on how much or how fast are these blocks propagating so gossip up in this sense is like an efficient and fast way of propagating blocks uh the idea is try to reduce like the block arrival time but it has some uh other extra features that try to bring more resilience to the propagation so in case like no one should be missing a message um and as I mentioned this is pretty much what makes it like a right solution towards uh things like pias or scaling to more or bigger blocks blocks um so it's not only that there are external limitations like gossip sub some minor soft limitations internally uh we know that spanning a new gossip sub topic like the new channels to disseminate like different messages um have many weird things it's kind of expected that there are going to be duplicates this is part of the resilience that it brings to the network uh the idea is that you spam a little bit so that you ensure that more people get the message not only one person uh and of course like these kind of uh duplicates have a huge impact in Bank width which I I I know that at the time like it's pretty much the constraints that we have to increase for example The Blob count um so yeah this pretty much guess even worse when we increase the blog size or the message size um so yeah in problem we've been pretty much over the last months analyzing how gossip sh is working uh which we've been monitoring like how gossip sh is doing um streaming all the events internally and we've pretty much defined like U we were able to identify how many duplicates are there happening in the network and what we saw is that for example for things like a Blog propagation uh 55% of the notes or the blogs are coming or are having at least three duplicates which we believe is the standard based on theoretical uh yeah basically the mathematics but the worst thing is that beyond that 55% line there are like some Edy cases where we receive almost eight times the same message um and this is something that we believe should be solvable and we pretty much also took the time to see like how much time does it take from the first time we see a message to the second time we receive the same message like the first duplicate how much time was it passing by and what would def find is that it's actually pretty good time to try to reduce it as much as we can so that pretty much also like um try to enforce like some other control messages within the gossip CH protocol like for example being able to say ERS that I already saw a message please don't send it to me which yeah it's still going on like many um consensus clients still have to implement it uh but yeah so yeah um we pretty much also collaborated with the the foundation and the uh e panda Ops Team uh we've put like um a website uh where we are streaming like when blogs arriving at each uh well at the centry notes that they are having and we believe that this is a core component like uh monitoring is really essential Leo was previously talking about like these things seem to be not like pretty like ah yeah it's cool we have a dashboard but the idea is that by having this Das dashboards we cannot only see how the protocol is performing now and ethereum is performing now but we also can predict or at least anticipate to when things are going wrong or for example when new version are rolling out we can compare to previous versions and we believe that this is a core component that we should keep in mind like try to improve metrics and try to improve monitoring so that we can understand how things work and how they should work so I'm a little bit overtime but this is the link to the website that we have uh it has way more graphics and more information about the uh yeah the blog propagation don't want to run over it and this is a bunch of Ed research post that we wrote like um there are many things in gosip shab and each of them pretty much has an its own blog post so yeah won't take much time from from the speakers thank you so much Mikel now it's time for q a i since questions are in I will ask you when did you start researching about this topic how long have you been on this topic do you mean me like personally or or in BL so yes you personally okay yeah um so I actually was working previously with Leo uh I did my PhD with him so I pretty much gone into ethereum and the lip2p layer with him which was I think like four years ago um so yeah it's been quite a while okay now we already have the first one can you expand about what you use to collect it your own tool or something else right good question uh I forgot to put the link here but we have an open source tool called Herms uh if anyone wants to know more feel free to reach out afterwards but it's pretty much like a l2p based event Tracer so we've implemented a it pretty much works like a light ethereum network node so it can open connections with ethereum nodes uh and can keep them connected so that we can trace all the internal logs and this is already open source so yeah feel free to reach out what do you dislike about liap P2P I'm not sure how how much can I say about this um we don't have we can go to the next one if you don't no it's it's okay like Li to be it's um it's pretty cool in the sense that there are many people working on it is quite mature but of course like all these P2P uh protocols it's hard to make them extremely optimal and there are many options around so sometimes it's just hard to reach consensus about which is the right way of increasing things or improving things so yeah I think that the mod modularity sometimes is kind of struggling with that like which is the right module to add like that I would say that that's a part that is harder for me to to follow okay um I think time is up y um so thank you so much for your time if people have questions he's around so you can ask him questions again thank you so much Mikel thank you