Transcending Gossipsub

Transcript

Hello everyone and thanks for coming to my talk. I'm Daniel. I work at Sigma Prime uh on a consensus layer client called Lighthouse. Um yeah so uh thanks to Mikuel's excellent talk right now you have already maybe a rough idea of how the uh networking layer looks like right now and there's a short motivation still so gossip sub gossip sub is a generic publish subscribe protocol so basically any node can publish a message and it is forwarded through the work in order to uh let everyone know of this message and it's generic in a sense is that it's not

purpose built for Ethereum. So you can send basically anything over it. Uh it works by having each node form a mesh and being in a nodes mesh means that that node will forward everything it has immediately uh to you. So if I publish a message, I send it to my mesh. If I receive a message and find that it's valid, I also forward it to that mesh. Additionally, we randomly gossip. So, we tell random other nodes, this is the orange uh errors right there, uh that we have some messages and that those messages are available and other peers if the mesh fails them for some

reason uh can then request these messages. It's based on the P2P which is also a nice abstraction for all kinds of uh P2P protocols. So over the years gossip sub has grown quite a bit. So this slide might look familiar to Mikuel's just now. So in 2022 we introduced gossip sub 1.1 and this built in some uh scoring and this is nice because it mitigates some attack scenarios uh like a node just not forwarding anything and just basically leeching off the network without participating.

Then in 2024 we introduced go stop 1.2 two which introduced these I don't want messages and as Mikl also said they're basically there to prevent redundant traffic. So if I receive a large message that also takes a while to validate like a block I first send I don't want to my mesh pier so they don't send it to me again while I validate and finally forward that block. And last year uh gossip 1.3 was introduced which introduced these kind of optional protocol extensions.

Um partial messages for example uh there partial messages are uh nice because they yeah allow us to send only parts of of blobs or columns data columns and topic streams um are also helping with large messages because large messages take a while to send and small messages right now in gossip queue up behind it and especially in ETBS which is coming soon payloads are pretty large and are pretty much disseminated at the same time as validator attestations which are very important of course and we want to avoid this head of line blocking this is

called and back to partial messages. These large messages sometimes are already present in parts at nodes. This is the case for uh data columns where some cells of these columns are already uh available through the nodes execution layer client. Right? So seeing that I just spent like a quarter of my talk explaining the status quo, you see that this has grown quite a bit and we reach keep reaching these limits of gossip and then apply some some some small fix to make it viable again for our purpose. And at this point this has

grown quite complex and complexity is not really a desirable thing because nowadays in the age of AI and automated uh bug finding like if you've been uh paying attention there has been quite a few of those and also in some gossip sub uh implementations we have found them and fixed them all. is good but it's it's a bit scary and and if we keep applying these band-aids why not just build something from the ground up which suits our purpose and this is uh where we come to Waggle uh Waggle is a proposal by um by us like a small research group

contain um consisting of myself and uh my colleague at Sigma Prime Olivia and Sukun from uh EF networking team and it's a brand new protocol. It's also based on lip P2P. So it does not get rid of this this base layer because the base layer is is fine for now. There's like not much uh to optimize there compared to gossip. It's very light, right? So it's very easy to implement.

It's like three screen pages of of specs. And this is intentional because it allows us to fine-tune the actual dissemination strategies and it's basically the result of our learnings from partial messages. So we extracted the good bits from there and got rid of the complexity underneath. And here you again see these topic streams and like assuming these topic C messages are very large they can flow in parallel to other topic messages. So let's quickly get over how uh waggle works. Waggle defines only two messages.

So when I open a stream to a pier, I first send it the topic ID. So the what kind of message I'm interested in receiving from that pier and after that that pier sends us these this object pieces message. And this is already an improvement because this topic ID for example was previously sent with every message in gossip sub. So for small messages this is already like a large part of that message. And so this is you know the kind of drive by optimizations we gain from this.

Uh this object pieces message consists of three parts. The object ID which is kind of the identifier of the whole thing that we want to disseminate like a block. uh the object ID can be the block hash uh pieces metadata is some metadata about that block or about the dissemination of that block. For example, I can use it to tell my peer how many parts of that object I already have or what parts I explicitly want that note to send me. pieces is then just telling the other node about some pieces of that block and all the actual contents of these fields are application

defined. So you can use any encoding, you can use any uh yeah contents and especially the pieces are very abstract. So this can be literally a piece of some thing like by chopping it up into equal sized parts or it can be just a concept of a piece. For example, at aggregated in Ethereum and a piece can be just be some partial aggregation that can be later aggregated again together and therefore forming the whole object.

It can be any step of a multi-party computation basically and not only the data is application defined but also the whole dissemination strategy. So waggle does not impose on you to form a mesh. You can build something that forms a mesh. Uh but you can optimize for all kinds of message sizes, validation times, data predistribution. This is what I was talking about with data columns. You can account for some nodes already having some parts. In these cases, you probably don't want to push all your data eagerly, but more try to make these nodes request data they're missing from you.

You can uh account for bandwidth latency trade-offs. This is like a very common trade-off you have to make. And you can basically for important times critical messages be a bit more bandwidth inefficient but therefore uh allow for faster message dissemination. And finally gossip sub has a cache that is very fixed. So you have a fixed lifetime of messages that gossip remembers. And this is not ideal because in Ethereum you have slot times, right?

And some kinds of messages are just irrelevant at some point and can be then discarded from the cache making the cache more lean, right? So let's talk about how we plan to use Waggle in Higota. And a quick disclaimer, of course, this is all work in progress and might change at any time. However, there was this uh week a rough consensus from core devs to go ahead with this. So to use waggle with the following EIP in Higota uh but no no promises.

So uh first up is EIP 8411 by Camille and Java. The idea is that with EPBS we have separate payloads from the block and these can get quite large and of course we want to scale so we want to make transactions cheaper and with cheaper transactions also uh larger payloads come because we have more capacity right and the very basic idea is to take that payload and chop it up into 64 parts and the builder of that payload then commits to it in uh the sign bit by basically building a Merkel tree uh hashing at

each immediate intermediate layer. And this allows us to be sure that when we receive a chunk that this chunk is legitimate. It's not just spam or random traffic. We can verify it via a miracle proof. In this slide, it's just 64 chunks. But we can also do something smart and extend those 64 chunks by erasia encoding them. This would allow us to get only 50% of these extended chunks, which can be more efficient. It's a bit more effort, but [snorts] it's nice because we then we don't have to get every single chunk in order to proceed with processing the payload.

And as I told you, this was kind of the the pieces definition of the pieces, but we still have a dissemination strategy. And the question now for us to clarify until he go is how complex do we want to get with this? It could be something like this. It could also be something like ccast by by Shaba from the networking team. Um something like this would be that once a chunk becomes valid we push it to a certain number of peers for example eight or 10 which would kind of mirror gossip sub's mesh but in a ephemeral so non-permanent way right picking other peers every time and after some delay if we don't have

all the all the chunks we go to our nodes and request any that we are missing in order to get the full payload and if we still request them from a peer that does not serve it to us immediately uh we have time out and retry but yeah it's it's a it's a draft so let's see with what we go and the other EIP where we are looking to integrate wagle is EIP 8334 by zukun also from the EF networking team and the idea is that currently We send attestations from each validator in a committee one by one and that is very

redundant because this attestation data is for 99% of the nodes the same because they usually get the block on time and then sign the same data. So everyone signs it and we send the data and the signature over and over again. And this data is just redundant. So instead of sending an attestation right away, we bundle them. So we wait for a bit, see what attestations come in from other peers and then send only the data once and all the signatures of the peers we received that signature from uh

signatures for that data from at once. And this saves uh around 45 to 55 uh% of bandwidth. So that's already pretty good, right? So hopefully we we will implement this. But there's also some perspective in like AR and beyond. And there was a question just from Mikuel's talk with regards to PQ for example. But come to PQ, let's just migrate all the topics because having more stacks does not simplify stuff, right? So in HAR where we focus on these most important two EIPs where you have the most gains, we

introduce vagle but don't remove gossip sub and that's not good. We want to get rid of complexity. So for for I start it would be very good to just move all the other topics to Waggle. We can do something fancy for some. For others there's not much benefit to be had through Waggle alone. So we might just keep the general principle of gossip alive but just over Waggle. Yeah. PQ. So the thing with PQ is that aggregation of signatures will take quite a bit longer than with BLS and the aggregates will be larger. So this screenshot is from Camille's LENSIM

page where he has some simulations on how to disseminate uh aggregates and andations post PQ or or PQ post PQ doesn't really make sense. Anyway, at sessions are around 265 kilobytes in this simulation. And because this is not as small as previous signature or aggregates and because aggregation takes time, we need to do something smart here. We can have some kind of recursive scheme where we first send the partial aggregates which are

smaller and then do a final aggregation run by multiple aggregators something like this but this is still being uh discussed and as PQ cryptography is still moving quite fast and there's a lot of research still uh we don't have a definite plan for this right now yet but there's a lot of uh research going on. Finally, so there was also the question before um what do we do with lip P2P and def P2P and EP P2P and now Waggle why is there so many things so Waggle is on top of lip P2P so it's not a replacement for

lip but waggle does not necessarily need lip it just needs some layer that can negotiate a stream to other peers for you So if we wanted to, we could get rid of lip P2P and some redundancies that are associated with it. So lip P2P is an abstraction and every abstraction or most abstractions come with some form of cost like we need a generic way to set up connections etc. And this is yeah not really useful in our use case. So we could replace it with something you could call it if P2P and unify also the approaches taken in

the EL and CL. So the plan would be move all the topics on top of Waggle and then replace the P2P from underneath Waggle. So that's already basically it. So I've hope that I've given you a nice little overview of what Waggle is and how it works. and yeah, let's see where where it goes. Thank you. [snorts] >> All right, thank you so much, Daniel. Let's start with the first question. Um, are we trading bandwidth efficiency for lesser resilience/ redundancy when moving away from gossip sub? If so, is that fine?

>> Excellent question. So gossip sub 1.1 has some form of peer scoring right waggle will not have a built-in peer scoring but for each topic that we move to waggle we have we will have to define some rules for peers uh some some also some scoring mechanism and I don't think that we are really trading for resilience uh quite the opposite because again we are not using a generic thing that has one formula that fits all. We can really get into it and find uh the perfect [snorts] uh resilience mechanisms uh like cache sizes. Again, we can time

our caches, align our caches to slots and therefore make them less attackable. Um, so I don't think we're trading. Uh, but yeah, we have to take care that we don't quickly migrate to Waggle and disregard resilience, but keep it in mind when defining [sighs] on how to use Waggle. >> Let's stop. How did the name Waggle come to be? >> Excellent question. So, Jo, my colleague at Sigma Prime, [snorts] uh, made up the name Waggle, and it is inspired by the waggle dance that bees do to communicate with each other. Yeah.

>> All things start small and simple. Do we trade off any of the battle harden and lindy effort of gossip by switching to waggle? What's the risk? Hm. Yeah. Uh, good question. So, yeah, on one hand, Gossip is battle hardened and we definitely with our experience from Gossip need to take care that we also make sure that Waggle will be harmed in a similar similar way.

That being said, we are a bunch of, you know, motivated innovate researchers. We have now AI to also help us design it in a in a in a safe uh way. And so we are not rushing we're not rushing this. We are making sure that we are still resilient. >> Is there a way to terminate a topic? >> Terminate a topic? Yeah, you can just close the stream. That's like a very easy look. If you're no longer interested in the data from that pier or shutting down, you [snorts] unsubscribe from that topic by just yeah

>> people are placing busy questions. Let me jump to next one. Is there any reason someone shouldn't use Waggle? Can you replicate your gossip sub functionality to Waggle one to one? Yeah, there are plenty of reasons swman shouldn't use waggle. So waggle is inherently more effort because waggle is actually not that interesting, right? We leave the interesting part to the application and so vagle is pretty boring actually right so if you are fine with gossip sub's functionality if you are not that time critical uh you you just can still use gossip sub it's battle tested as the

previous question [snorts] uh said so yeah there are many reasons but if you want to squeeze every little bit of performance waggle can be a nice base abstraction very light abstraction to base you're thinking around for your different messages in your network. Can you replicate your GS sub functionality to wagle one to1? Uh yeah, I'd say so. >> Is the validity condition in 841 just a miracle proof verification or require more processing?

>> Yeah, it's just one miracle proof the data within the chunks. So the actual payload might of course be invalid. So we might have very like validate all the chunks and then come up with garbage. But that is not really the problem of the networking layer at this point because in that case the builder just you know they they committed to an invalid payload. So they apparently yeah their fault. >> Um I think maybe we can squeeze in one last question. gossip substic protocol for nonspecialized topics.

>> Uh for nonspecialized topics, so again kind of similar to my previous answer, if you don't need any special magic or some partiality of your data, feel free to keep using gossip. [snorts] Okay, that's it. Thank you so much, Daniel. Um, I think he already gave his workshop yesterday, but if you want to contact with him, the talk is recorded and he has re