P2P Networking Call #4

Transcript

Kamil Salakhiev: Everyone.

Alexey Osipov: Okay.

Matheus Franco: Oh, hello.

Kamil Salakhiev: Matthaus, I think we did not meet before, so… You will speak about spread today, right?

Matheus Franco: Yes, hey? Nice to meet you. Exactly.

Kamil Salakhiev: Okay, nice, nice. Yeah, I think we'll start with client updates, and then, yeah, proceed with Strut.

Matheus Franco: Okay.

Kamil Salakhiev: Okay.

Okay, yeah, let's get started. I think. Cool. Yeah, today's plan is, yeah, quickly have client updates, and then… Proceed with your presentation from Matthaus, who speak about spread, an improvement for privacy. In Gossip Sub, yeah, we also planned some other sessions, but yeah, they were… Decided to have them, next time. Yeah, with that, yeah, maybe start with client updates. Yeah, Daniel, maybe anything from Lighthouse? Alright.

Daniel Knopik: Nothing in particular. We've been, working on some more fixes and are going to… Put out a release, likely tomorrow. Umm. There's also… I think some of you already saw it in the Cell Level Data House channel on Discord, but… We've been seeing some really nice numbers now that usage has been ramping up. By now, like, on some notes, traffic has basically halved, and that's not even with, like, full rollout of Python images, as only Lighthouse has released yet, so…

Kamil Salakhiev: Okay.

Daniel Knopik: I'm pretty happy with these results. And, I might put out a blog post at some point with some more details. No.

Kamil Salakhiev: A bit nic.

Daniel Knopik: Okay, cool.

Kamil Salakhiev: Is that, observation from Hoodi, or from Mainnet?

Daniel Knopik: That's… that's what he…

Kamil Salakhiev: Okay, cool. Yeah, I did not check recently, but yeah, I think it's, like, 150 notes out of 2,000. That support partial messages, so…

Daniel Knopik: Yeah, I have a feeling that most of these nodes are super nodes, so they're… a bit more, you know, a bit more present than the other notes. So I guess that's…

Kamil Salakhiev: Yeah, I imagine.

Daniel Knopik: one one factor.

Kamil Salakhiev: Okay, nice. Yeah, I'm not sure, I don't think we have anyone from… Prysm? Okay. And… Yeah, if not, yeah, Bossel, maybe anything from Guest side? How is the progress with sparse blobs? I…

Bosul Mun: First Whipple PR for Geth is marched just today to the master. And I'm working on some subsequent PRs. Including test, the test won't be merged. Very soon. It will be merged after… Other clients have implementation to prevent, the test… like, breaking the test success we have right now in Hive, And… And also, some protection mechanism. will… we merged. I'm working on that. And also I opened a Pr. On prism repo. Oh. to implement Purchase updated before, and… get blocked before, and it is being getting reviewed. Oh, yes.

Thank you.

Kamil Salakhiev: Okay, thanks. Nice, nice. Yeah. Do you know, like, are we planning to roll it out for Devnet 7? In Amsterdam. This is true. I think we do, if it's nurse and master. Yeah, I think so. In Glamsterdam DevNet 7, we expect to have part of the post, right? Or it's already launched.

Bosul Mun: optionally.

Kamil Salakhiev: Optional, okay, nice. Cool, nice, yeah, don't see other clients, so yeah, maybe just… yeah, let's proceed with Spread from Mattel's.

Alexey Osipov: Can talk from Azerbaijan's side, if that's interesting.

Kamil Salakhiev: Oh, sorry. Yeah, please.

Alexey Osipov: Yeah, next time we'll rename to input. Yes, it's in my… Picture. So, we are just, switching to test, to… of sparse blob pool. We are aware of, small update of, soft limits, so we included it. in, the feature branch. We, have not yet, merged, but, before, we worked a lot on, our implementation disk V5 and V4. Oh. And now it should work better. It includes now a fork hash of Work next. Which is helpful to… like, To decline notes earlier, if they belong to different network, As for… as far as the blob pool. I hope next week we will be able to review it, and probably manage to.

And, enable it on DevNet 7. Another stuff is, Topics. Quite an interesting… Stuff that may, speed up, eDiscovery in small networks, and actually some L2s even interested in that. As far as I remember, so, not sure if you guys discussed this, topic. Topics here. But yeah. And what is the state of that?

Kamil Salakhiev: Yeah, I'm not sure I'm in the context where I can read more about that.

Alexey Osipov: Yeah, disk P5 for, Disk P5, okay. Yeah, disk P5 topics.

Kamil Salakhiev: Yeah, unfortunately, we don't have Chabot who… yeah, he would… Definitely be the best person to comment on that. But… yeah.

Alexey Osipov: That's it from my side, yeah.

Kamil Salakhiev: Okay, thanks. Cool, yeah, any other clients? I assume no. So yeah, let's proceed with Mateo's presentation then.

Matheus Franco: Oh, hello! Can you hear me? Well, let me just one second. I just here, because my microphone from the computer is not that good.

Kamil Salakhiev: Okay, yeah, we… yeah, we can hear you.

Matheus Franco: Okay, great. Alright. Wait. Let me share screen. All right. Right. Okay. Okay, you can see this one, right? Just to confirm.

Kamil Salakhiev: Yes.

Matheus Franco: Great. So thanks for having me. what I'm going to show you today is spread. I know some here already know what all of this is about. I have talked with some people about it before. But for the ones who don't know spread, but like since then also we got very good updates and new results. So spread is a gossip sub extension that replaces the dissemination mechanism of gossip subs, and gives you 2 things that people usually treat as opposites which are sender, anonymity, and low latency. So just to to to say, this is a joint work from me, from Diogo Cardozo and Rodrigo Rodriguez at the University of Lisbon. and was founded by the Ssv network Dow.

and we already have everything public. I, if research post the spec Pr. And the implementation Pr. As well. So let me set up this stage. First, st gossip protocols give us a handful of properties we care about like performance dissemination needs to be fast, a few seconds budget, and it has to stay reliable and robust as notes churn. And the second is anonymity, the long-standing intuition that because a message takes a diffusive multi-hop path. The layer would hide it automatically, We would hide the one that the peer who originally sent it. And the problem is, anonymity is this one property actually, that doesn't come for free at all. Even though it is possible to be conquered at some level, and the academic, the academic state of art for it is the Dundelion++ protocol.

which may or which you all know. It starts with a a random walk, so it forwards the message to a single peer period of time. So on number server, whenever it receives it. it cannot tell if it is receiving from the choose from from the from the actual source. The peer could just be a relay. Of course, that's the same for gossip, sir. here, by doing a single random walk that you only that has a that you keep a fun out of one. You can actually provide this guarantee with proven and everything. The the bad part of it is that this costs severely on latency, and The community has already looked at it in the past, and it seems that dandelion is infeasible for the consensus layer of activity.

And here's the uncomfortable part about gossip serves that if you simply changes the if you simply change the fan out from one to 6 or 12, or whatever. then this intuition doesn't doesn't hold anymore. And you all have seen these papers, and we have also done it as well, experimentally, with just a handful of passive listeners doing nothing but just taking notes on who were the first peers that forwarded a certain message. You can map the validators to their IP addresses very quickly and with very high confidence. and that's enough to to target them with a dos attack. We try to force them to miss duties, blocks. incur penalties, and so on, and all of that without needing any type of privileged access, or without attacking the consensus protocol, or even getting to be identified.

So… Also, meanwhile, another issue is that the timing budget for the consensus protocol is also shrinking, as you all know. times as lot. Times are expected to be reduced from 12 s to 6, or whatever now or near it. And now, with the ePBS, the individual duties as well, they are They they need to be executed also faster. So we are heading towards a scenario that needs both stronger anonymity and also better performance, all at the same time. So… That's exactly our goal. The goal of spread to raise the bar on anonymity while still improving the dissemination speed. And. to re to emphasize this. And it's not like giving up a little bit of speed to buy some privacy.

Indeed, the fact is that gossip sub is also not optimized for efficiency today. So this actually gave us a path, a room to to win. on both dimensions, both at anonymity and efficiency at the same time. So now going to the protocol, how do we do? The key insight is that these two goals… of anonymity and and efficiency. They only really fight. If you picture the network as a flat space with every node equally far from from the other, or without you being able to know any information about the peers, and that's already proven in some papers, like the natural trade-off of them. But of course this is not the case in in the network. Real nodes pile up in some few dense regions across the globe.

And that's exactly what we take as as caveat that we try to split the problem along the geography of the network. So, following down the line, we keep a probabilistic random walk, but we run it only inside a nearby region. where each extra hop that you do hides a little bit more the source. but also costs almost nothing in terms of performance. And then you do a worldwide, efficient, smartly chosen hops. to carry the message to other regions. And, by the way, as soon as I say region, you immediately get the feeling of clusters. And that's exactly what we we build as a primitive of spread. So suppose you have peers scattered across the world like through the Us. East, Us. West, Europe, Asia, and so on.

To figure out what is the cluster for a certain peer, every peer constantly pings each other and a lightweight coordinate system called Vivaldi. turns these round Rrts into positions that estimate distance. So you can imagine it like your peer stores the list of known peers, and with it it ha! It holds a virtual coordinate. such that the heuristics is that the distance from you today's video coordinate mimics or is proportional to the RRT. and after a few iterations we've already settled on a good position for each peer with diminishing results. Then. from the perspective of a single node, what we do to keep all of this decentralized without a central authority. We simply take a percentage of all the peers we know.

We we take the closest ones, and we define this as our interact cluster. and everything else is outside is what we call the inter closer, or simply outside, if you if you wish. So every node does that independently, and while everyone does this, you will have the picture, even though decentralized, of the regions that you would expect to be built. Actually, there is a another split that we do on the outside peers. Some peers we call the stepping stones. which are the closest outside peers on a given direction. and the other peers. that are a bit far away. They are called the occluded peers, which means that there is another outside peers that is closer in this direction, and you can simply compute

the directions by by by computing the because sign similarity of the of the vectors. And and this is how we try to do a long hop through between regions without having to waste Doing the most expensive call. and trying to do pop intermediate ones. before I show you an example. This is the the whole algorithm. on every message. Instead of getting the mesh of peers as gossip sub does, we get the entire set of peers. and and we run 2 2 procedures. One is the intra cluster that decides whether you will keep doing a local a sorry, a random walk, or if you, if you branch out, and the second procedure decides, if you will fire the intercommunication system.

The protocol is parameterized in 4 parameters that controls the fan out and the Bernoulli probabilities for each procedure. So as an example, let's say that a node in Europe wants to publish a message. at the beginning it falls to just one random neighbor in its cluster. Then this neighbor sends to another one, and so on and so forth. And this is all cheap, and because everyone is very close to each other, like few milliseconds away. And it is, but it is very important, because that's exactly when you create anonymity for the message. and then at some time, instead of just sending to one neighbor, one peer may also fun out, as I said in the end algorithm, and it can do what we call the cobra walk instead of sending to one peer. It sends to this fun out of parameter.

This is just to speed up. the local coverage on on this question. Then also, eventually, once the inter cluster Bernoulli coin fires. you know, makes a a directed hop to other nearby regions. Now, a few practical things about spread, because this matters a lot for adoption. We already implemented it as this opt-in feature and this protocol extension in Basub sub. and the condition for running it is that It only turns on when both peers support it. So But vanilla peers that do not support spread. They just ignore the marker that exists in the handshake and in the message little part above. And then you can have mixed networks that run at sometimes. spread. or gossip serve as as as wanted.

and we built it only in one of the implementations, only in the goal. The P. To P. Pub. Sub. and we then evaluated it, using the simulator that Marco created the simnet. using a real Internet. latency data set. So to the evaluation here, the X axis is the latency, and the Y axis is the attacker accuracy. So higher here means worse. Gossip Sub is quick. in some sense, but it lacks anonymity, and then the line plus plus is private, but restored. The thing to see here about spread is that spread is not actually a single dot in this in a certain region. It's actually a whole spectrum or region, if you may. that you can populate by by tuning the 4 parameters.

So you can slide both towards speed or towards towards privacy. And crucially, what is, I think, the most important for us is that spread is not just the line between gossips and then the line. for an equivalent setting regarding fun out. Sorry expected fun out per peer. It pushes the line both left and down a little bit. So you can get better latency and better anonymity at the same time. Here in this, in this experiment, we just picked one balanced configuration that of this spectrum. On the left you have the anonymity chart. in which you have the attacker accusing the Y-axis, and In the X-axis you have how much of the network the adversary controls and spread is in origin. It sits below gossip sub and above the underline, and it actually, depending on the configuration, can be anywhere in this in this region.

even above gossip sub, as we will see. And on the right you have the performance which shows the stretch cumulative distribution function. and spreads curve, while being a bit better than gossip, serving anonymity is the furthest left and the fastest of the 3 curves. And more recently, we analyzed even better configurations of spread, and we listed two here. One that is totally optimized for performance, so let's say you don't care at all about anonymity. You only care about performance, and this one is in in green. and the other one that keeps It's still the anonymity that you can have in gossip. So yeah. is shown in blue. But so here we also try to optimize the best we can for performance while keeping

the privacy of of gossip sub untouched in some sense. It's actually even a bit better in gossip sub here. has 38%. And this configuration has around 30% of attacker accuracy for 10% of attackers in the network. The bars here are how much. each configuration improve on each metric. both stretches and latencies on the average value and the 95 and 99th percentile against gossips. and you can see that it cuts the mean stretch and latency by around 20 to 30%. and it improves considerably the tail behavior, which is exactly one of the very weak points of of gossip subs. And that's it. The most I would say the most important thing we are looking for right now is

Actually, to get attention to it, and more eyes to it, and maybe to motivate its implementation, adoption, and most important, feedback. So please help us spread it. Thank you.

Kamil Salakhiev: I don't know too bad. Cool, cool, nice. Yeah, any questions from anyone. Yeah. 5, 10, 30. Okay, Jan is asking… How the privacy metric is defined. No, you muted Matos.

Matheus Franco: Sorry. Yeah, thank you. That's a an excellent question. And this is something that we have as a future work to improve. There are, I would say, two ways to do it right now. One is to go to a formal mathematical proof. And there is such a path. I think in 2,018, 2,022. No, 2,022 and 2,024. There are 2 very important papers that define anonymity for gossip protocols using information theory, and it goes all the way to differential privacy and well established proof. approved results. And, for example, one of the papers prove the, you know. some anonymity, some anonymity values for dandelion. While, for example, it proves that that gossip subs gossip sub cannot cannot be anonymous.

So you have this path which we are trying also to to run. Oh… on one track. For we want to prove that. depending on the configuration that you put in spread. You have really some anonym, some mathematical anonymity. Of course, you can soon spread not to have any, as we have shown. This is one. This is a bit harder one, and what you get as output is just the the parameters of the differential privacy, which means something theoretically, but means less in terms of of real world. Let's say. and the other path that that we took in the paper is to evaluate it against well-known attacks. So what we what we did is use ping.

a fraction of the network as curious notes. These curious notes. They report everything they receive like every time they receive a message. and they coordinate this with a central authority or a single process that collects all of this information and tries. And now the goal here is to estimate. Who is the source? for a certain message, right? And here is, of course, where you can have a great diversity of attacks. We used the lowest estimated one, so for a certain message ID, who is the first peer that sent this message. And it is a very simple one, yet it is one of the most powerful ones, surprisingly. We tried many, many other different attacks, and it simply gets down to the same results. Actually, some more sophisticated ones tend to be actually even worse.

Then then this lowest estimated one. But yeah, you you don't have here a default. Sorry a ground truth. as you would have in the form of mathematical evaluation. And so there's also like room for creativity to build up new attacks. And so but we try to concentrate the attacks to be blind. on the app level. So, for example, there is a paper, I think, from 2,023 on the anonymity of gossip sub and ethereum, and the attack used the assignments of validators to subnets. In order to… to… to try to de-anonymize the the validator. And in that case you don't even need to do anything about the the communication layer at all. You just need topic assignment and consensus layer and sorry scene messages in topics and consensus layer. And then you can perform the attack. We try to avoid this kind of app layer layer dependencies.

Kamil Salakhiev: Oh. So maybe it's worth kind of defining who is the attacker here. In my understanding is, like, we have this set of, as you call them, curious nodes, and they kind of collude with each other, and so, like, whoever first observes The message, some… or some message ID, maybe, and they… use that information to kind of detect who is the origin of the message. Is that correct intuition? Yep. Okay, so basically, does it mean that the higher the fan out. Of the, like, the origin node. The easier it's to detect or de-anonymize it.

Matheus Franco: Exactly. And yeah, yeah, yeah, you can. Actually, the the very bad news here is that As soon as you have a fan out of 2, you cannot prove anonymity mathematically. So you you do need a probabilistic random walk in the beginning, either way, to have anonymity. But yeah, that's exactly exactly. I mean. Since… Long initial, low final paths. Mmhmm. We don't have analysis about censorship. But the curious things, the curious thing about spread is that even though you start Slowly, let's say. So in the beginning. you only touch on few notes because you're not. You don't have this big funnel that you send to several peers at once. Right?

Gottfried Herold: Yeah, exactly, yeah.

Matheus Franco: Huh?

Gottfried Herold: Yep.

Matheus Franco: But on the other hand, the protocol terminates faster than GossipSub, and that's what we saw in the latency average and the percentiles. the gossip server has really has a problem with the tail behavior on understanding. If a peer has received a message or not, even because it is blinded, of course, to to this. But but it is a very interesting. Yeah, sorry.

Gottfried Herold: Yeah, no, I was just wondering, sort of, if you have some note that just claimed to, sort of, participate and just… I don't know, don't… just don't And just sort of… I mean…

Matheus Franco: You you do have. You do have some robustness mechanisms from it, and that's also something that don't rely on. I used, you'd have, you can… and also whatsapp also have have it so like regarding this, you you can have other paths. But that's a… an interesting… an interesting look. censorship. We should definitely look at it. Yeah, but we haven't had any experimentation or thoughts honestly about this yet.

Kamil Salakhiev: Okay, Felix?

Felix Lange: Yeah, I was also just going to say this seems like a pretty key weakness of the scheme, because if I understand it correctly, it does reduce the redundancy that you usually have in Gossip Sub, from propagating the message to multiple peers. in the start. So if it doesn't make it sort of like, is that a real possibility that, like some transmissions of messages, might actually just fail.

Matheus Franco: Just just to be sure you were asking if the if if the propagation can stop at some point, and then you lose robustness of it. Is that what you're saying?

Felix Lange: Yep.

Matheus Franco: Okay, So there are again. I I think it goes on the on the similar methods that you can that I have for it. First is the… is a repropagation of the message, and then it pretty much goes backwards a little bit on bandwidth, as you raised. Okay. But I think I think this is yeah. Actually, this is. The most common… common used one for dandelion. For example, you, you just repropagate the message after some, some, some time. And you also, for improving, dissemination here, because you, you send to, to, to, that, that few peers, actually, you repropagate it once you receive it back. for some number of times. So actually, bandwidth is not that, unfortunately, is not that that is not improved.

Considerably. And… even because you have the you have here a a chance, even though small of propagating with a hyphen out, and then repropagating it with a hyphen out, if if necessary. But I… But I think it. on my opinion, what what I have seen in experiments, even though we didn't focus much on this aspect. is that the mechanism that the gossip currently have has sorry already fulfills most of the problems. So within.

Kamil Salakhiev: Yeah, maybe we'd be curious just to measure that. I mean, just pretend that we have this portion of nodes that are actually malicious, and they do not propagate, and then, like, how much We slow down the propagation of messages. Yeah, that would be an interesting direction. Oh.

Matheus Franco: Yes, yes.

Kamil Salakhiev: Yeah, it seems like the main concern so far. Okay, Raul.

Raúl Kripalani: So one aspect that is worth considering here is the properties inherent in the data itself. Right? So if we're using this to propagate attestations or anything. Like, or any mechanism that would imply creating some form of, like, a stable, or over time forming some form of a stable route, or something like that, or kind of, like, have some form of, like, multi-hop relay, or some circuit of some kind. Any kind of scheme that relies on, like, some stability of past behavior over time, perceived past behavior of other peers over time, really marries well with attestations, because we have a natural feedback loop in the protocol, right? I keep saying this in several venues, and we keep

I think underusing this property that we have. Like, it's great to build generic protocols, but it's worth looking into, like, specifically how we would use them to propagate specific objects. And when we do that, we realize that a given peer A sends with the level of consolidation in the network and the level of kind of like validator to node placement on the network is probably going to send more than one attestation per slot like more. Probably that's very likely right? So that node could potentially decide to send and route different attestations across different routes or different fan outs or different peers. So as to kind of, like, test and probe different pots, for the same

payload that is sent at the same point in time. And therefore, the interesting bit here is that in 90-something, 99, 98% of the cases, the attestation will land on the next block. So if you send an attestation and you see it land and you track the path or you track the fanout peers, and you see it consistently landing on chain in a timely fashion, you can make some assumptions about the stability of that route. And this feedback loop is really interesting because we have so many in the protocol that we're not really leveraging in our designs. So this is one of those. Even in the worst case scenario where you have an exceptional case where the attestation didn't land or landed the next slot.

The protocol is designed to handle I think it's the current parameters. This was changed recently, but I think the current parameters is up to 32 slots of delay in a given attestation. So you are not going to be penalized. or I can't remember, like the cryptoeconomic details, and how much the the reward function decays with with lateness. But if I remember correctly, it's either 0 or not, or or very little in a way that it makes sense to use this this this feedback loop to actually like, you know, and take the risk of maybe one or 2 attestations while you're constantly probing the network for quality, one or 2 attestations in a blue moon. might not land, and you might not even get penalized for just, like, you know, a tiny bit. You won't get penalized, you will probably, like, have your reward, like,

I guess, diminished by a little bit. So that would be an interesting thing to consider, Mateusz, I think, and this is a It's a property inherent in the data, so we should use it.

Matheus Franco: Yeah, definitely. Yeah, it's… always interesting to see. what insights from the app level you can you can bring to the protocol. And this is actually one that suits spread very well, because actually on going back to the attack thing. the best… The best action is to Do nothing. in the sense that if you communicate again with the same peer that you already talked to, then you are giving less information in some sense. And… I remember that one of some related work to dandelion actually use this kind of of fixed structure that you try to build in the network, and so to to try to have more privacy on the long run. And there's actually something that

would be very good to have in even in spread, and we actually think thought about it. But the example. And and we noticed, okay, this depends on the app level. And you need to understand. something about it, or you need to build something extra. But the example you gave about Ethereum is exactly the type of thing we were…

Raúl Kripalani: Yeah. So just to be clear from the, like, if we, like, I'm not a fan of this, like, protocol app duality, but I understand that, you know, some designs are born in the protocol and then, like, figured out, the adoption is figured out at the app layer. I think we should close this loop as soon as possible. This is what B2B is trying to do as well, and one of the design principles, right? But the thing is, with this, the protocol does not need to be concerned with the app-level mechanics, right? All it needs to do is expose some, some API such that the app level can inform of whether, like, some payload that it's sent through

the broadcast mechanism. This broadcast mechanism was then confirmed right? So it's kind of like a confirmation think of it as a as like a maybe a confirmation process, right as a 2 step process. I send something, and then later I confirmed, if I confirm like I add weight to that, send right? Basically. So if you're tracking the weight of peers based on who you sent what your initial hop was, and you track it over over time, and then you have the protocol just telling you, hey? This send succeeded this send. was not seen in the network or something like that, then, like, from the protocol perspective, you only need to think about the scoring, the mathematics, the peer selection, the probing, right? But you don't need to care about how you're actually getting this feedback loop delivered.

Because, anyway, the the clients consensus layer clients are tracking this. So it's literally just a simple callback.

Matheus Franco: Exactly. Yes, it's yeah. It's information for free. That that may be very helpful here. Yeah, I don't, couldn't agree more.

Raúl Kripalani: Ambient information. Yeah.

Kamil Salakhiev: Cool, nice. Any other questions? Okay, cool. okay. 8. Yeah, just not a question, but yeah, just general thought. It's like, yeah, we're moving into a world where we have, like, large messages, and we might consider using things like ECBroadcast, which, like, huge fan out in the beginning, and we have, like, message ID, which kind of identifies all the chunks from Recorded data. And In that world, it feels like it would be very easy to conduct these kind of attacks. To de-anonymize whoever, like, the origin of the node, so it's like, if we want to have aggregator. And you want to, like, improve privacy of aggregators who… and aggregators in PQ world would be, like, of size 128 kilobytes, or even larger, maybe 512.

And then we do this kind of techniques with like large fan out of small chunks with like some message ID, then it's very easy to de-anonymize these aggregators. that's… I don't know, just something that comes to mind. And in that sense. of Yeah, we can either think of something, like, how to protect them, or just give up on maybe privacy for some… some, like, messages, some propagations, like, yeah, disaggregations, for example, and just assume that, okay, aggregators should be, like. The… some specific node that is protected from… well, can protect itself from those attacks. Yep. but yeah, for something like attestation propagation, yeah. Problem, yeah, from my opinion, yeah, makes sense to… Implement, yeah, something like spread, maybe.

Cool, nice, I see some comments in the chat. Is it about question? Okay. All right, thanks. If no other questions, yeah, thanks a lot, Matthias. It was super interesting. Yeah, let's stay in touch and… Yeah, if no other questions, I guess we can wrap up. Okay, cool. Then, thanks for joining. See you in 2 weeks. Bye.

Bosul Mun: Bye.

Matheus Franco: Bye, Ry.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.