P2P Networking Call #7

Transcript

Kamil Salakhiev: Hey, Daniel. Hey, Jiaheng.

Jiaheng Li: Hello.

Daniel Knopik: Hey.

Kamil Salakhiev: Yeah, let's wait for others. Hey, Raul.

Raúl Kripalani: Nope. Stop.

Anton Nashatyrev: Hey, guys.

Kamil Salakhiev: Yeah, everyone. Absolutely. Alright, I think we… Ready? So, yeah, let's get started. Yeah, as usual, yeah, welcome everyone. So… Yeah, today we have, debut clients updates, and also, yeah, Jiaheng will speak about his work on gossip-sub, so yeah, should be good. an interesting photo, and hopefully. Yeah, let's start with client updates. So, yeah, maybe with Prysm this time.

Nope. Who do we have from Prysm's side? Maybe Casey?

Kasey Kirkham: First up here.

Kamil Salakhiev: Pars also here, yeah.

ashah: Yeah, so… On the partial column side, just our Gloas partial column work is dev-complete. We've tested… done interop testing with, Lighthouse on… Gloas, it looks good. Now we're just in the process of rebasing it against our other GLAS work, and I'm hoping this week or next week, we'll land it in the developed branch. So… And the other important workstream that we've started now is revamping peer scoring in Prysm. You know, there have been some issues lately With peer… Prysm disconnecting peers on Glamsterdam 78 because of some… problems in… in how Prysm does gossip-sub-scoring, and there's a… And, Yeah, it's basically time to revamp and refactor the entire peer scoring layer in Prysm, so that's what I'm working on.

The idea is to make peer scoring more observable, have a nice audit trail, make it easy to debug why we are banning or disconnecting certain peers, why we are bumping up or down the score of certain peers, so it should be easy to introspect and simplify the algorithm a little bit. My goal is to… yeah. My goal is to have a design… like, I'm in… right now in the process of… writing a lot of code and testing it on Hoodi and… Yeah, I'm hoping to have a design doc ready once I'm done with this dev phase, so that it's easy for other people to understand the changes that we are making, and I'll… I'm hoping… I'll definitely have it ready before our next P2P call. So I'll share it with everyone here if they're interested to just take a look.

Yeah, that's it on… on Prysm's side. I'd like to know if you have questions.

Kamil Salakhiev: Okay, interesting. Thanks, Marge. Yeah, let's proceed with Lighthouse, daniel?

Daniel Knopik: Yeah, no big news, but we are considering enable partial columns on mainnet with our next release. I think I posted about that in the channel already, but yeah. Beyond that, yeah, just some… research, around Waggle. I've been thinking about possible API, for it. And miscellaneous, smaller, other stuff.

Kamil Salakhiev: Okay, good, thanks. Yeah, Anton, do you have to share anything, maybe from tech side?

Anton Nashatyrev: Yeah, no, no, sorry, I'm not aware of any major, things and tickle.

Kamil Salakhiev: Okay, no problems. Okay, yeah, let's proceed maybe with EL subdates. Geth? I don't know, Cabo, do you want to speak?

Csaba Kiraly: Yeah, so… One guess, I was working a lot on, on Spa's pool, last week. the… we did a few changes to how we are doing Galisial recovery, And not using Azure when we not needed, so we were speeding up a bunch of operations. The previous implementation, we sometimes were doing recovery when we had all the systematic cells, so we could just basically Copy them together, and have the blob, so that's fixed. And then, there is another one, which is, typical lead sermon zk, which is… If you have the systematic cells, you are not doing recovery, but you are encoding, so that also brings down operations from… 50 milliseconds to 4 milliseconds. So lots of speedup in… in that, and also fixed…

serving, spas-Bapur, so we had… Optimizations in the… So whenever, you are basically… needing… More than 64 columns, 64 or more columns. Then on the vial, we would send the systematic, so the first 64. But then we were not able to serve, actually, the, the custodied columns, because you had the first 64, and you might need something else. And this was… was distorting the network side, so serving on the network, and also serving Towards before, so I was fixing that. Now the new version is… is basically recovering on the fly, stalling the full, as it's recorded. version on disk. It is not modifying how… what's happening on the network, so bandwidth-wise is still the same, but it's storing the full, and then it's serving fast, both to network and GetRePS v4.

So these should be in. Then, by doing this work, I was also looking into the… because I was doing these changes in the ELS recording, I was checking what the underlying libels are doing. So what to know there is that we have… we… by default, we are operating with GoCzG, but we also have a… way to operate with ZKZG. And, both Go KZG and ZKZG is not just KZG, but it's also the lead sermon encoding, so it's… it's GoCG lead sermon and zkZG lead sermon over the BNS curve. So I was looking into those and, found… A number of ways to… Speed those up, Speedups are huge on GoKZG. We are speaking of… full-time speed increases in some cases. ZKZG is much less, because it already had some of the things that I was putting to go kzg.

no KZG has an edge in some cases, because it's parallelizing in itself, so if you have just one blob to deal with, and you have the CPU resources to parallelize, then Go KZG, the operations which take 14 millisecond Go KZG and 200 on, on, ZKZG, This vanishes, disadvantage vanishes if you have, like, 8 blobs to work on in parallel, and you have 8 CPU cores, because then you can parallelize the other way. Anyway, a bunch of implements there, In PRs, not in production, definitely. So that's that. Then what else? The protected pillippers is now on… on… on, Master? I think it's also now in our last studies, but, so it means that our PLs are now checking the quality of pills and protecting some of them from being dubbed.

So that's… Good. And then… yeah. And then I did, a bunch of… Exploratory work on… Going back to the topic of sending things fast over the gossip sub, and related things. So I was doing a huge exploration on fast block diffusion. Exploring the design space, working with… the PLISP code base, exploring, what if we do a really simple segmentation? What if we do, ledger coding? What if we do multiple topics, topics per segment, and so on and so forth? What if we do batch publishing? What if we do. Push, lazy, and non-lazy. So, push and pull, basically. So, exploring all these kind of things, and I'm preparing a Bright upon diffs.

Having left, if anyone is interested, ping me and I can share. where I am with that. Yeah, but things are looking good, in the sense that it seems we can Speed up, block diffusion with the primitives we have, quite a lot compared to what we are doing today. That's it.

Kamil Salakhiev: Okay, thanks, Caba. Yeah, I think you pretty much covered almost everything, I think, I guess. I don't know, Bosul, do you want to add anything, or are we good?

Bosul Mun: I think Trevor imagined most of it. We have some security issues, referred from AI, and… I, I, I'm planning to… summarize this, and one of them is, what Caba mentioned. The peer can… force us to compute, recover, or compute cells and blobs by recasting multiple, get transactions. Messages on the… like, including that, I will make some… some document that… summarizes those. Yes, thank you.

Kamil Salakhiev: Good. Thank you. Flcl, would you like to report for another mind? Oh, I guess your mic is not working again.

Alexey Osipov: Can you hear me?

Kamil Salakhiev: Now, your fear.

Alexey Osipov: If you're asking about status, so… Oh, we're… Trying to improve IPv6, support, across, the stack. Well, we are trying to merge sparse and Snap2, hope it will appear in Master soon, in days. What bills? I really won't try to include a boot node release, in the next, the Mind release, but maybe it will be… Available is, as an official emission soon, later. Yup. What, what, what, what?

Kamil Salakhiev: Okay, great. Yeah, any other, client that I missed? Okay, great, if… Nothing else? Yeah, let's proceed with presentation, so… Yeah, Jiaheng, if you, Here, yeah, we can get started.

Jiaheng Li: Yep. Thank you. And I will share my slides. Yeah, can you see it?

Kamil Salakhiev: Yep.

Jiaheng Li: Okay, thank you. Okay, I'm Jiaheng, I'm a master's student at ETH Zurich, and we worked on this project with Anton also at ETH Zurich, Yann and our professor. We were studying about the security of P2P networks, and specifically the liveness of gossiping protocols. Yep. Yeah, so P2P network serves as a communication layer for the large decentralized systems, such as Ethereum, and gossip protocols are there to spread the messages BNs those systems. And, for example, for the Consensus of the ethereum. While the consensus mechanism itself has been extensively studied by the community, the underlying gossip layer has been far less rigorously understood. And the analysis of the consensus mechanism assumes a timely delivery of the underlying gossip layer, so the security study of the underlying gossip protocols is also important.

So, we can model the network as a graph with nodes and links between peers. And gossiping is a problem to spread the message published by some notes to the others in this graph. And the most naive method is flooding, that every node forwards everything they received to every other peers, and this is robust because it utilizes every edge in the network, but it could be highly redundant, because many of the forwarding could be duplicates. There are many practical optimizations to this, trying to reduce the redundancy by selectively forwarding the messages. They may select which messages they may forward, or, like, which peers they forward to. And the question here is, are these optimizations really secure under an adversary scenario?

So one possible object… objective of the adversary could be to break the liveness of the gossiping. So, if the… adversary targets one node, they may try to cut all the fresh messages to this node, so that no new messages could be delivered to that. Or if they targeted the full network, they could cause a partition of the network. So… so, like, they could not proceed with the message forwarding. And one adversary strategy here is to utilize the previously mentioned selection mechanism of optimization. So, because the mechanism will try to select which which nodes they talk to, or which messages they forward. The adversary may manage to occupy all of these, so that the honest links will be filtered out, and all the preserved ones are controlled by the adversary, actually.

And we want to study whether this could happen. So, we study two concrete gossiping protocols, DOC, which is designed to be used for common BFT, and also gossip-sub, which is used by Ethereum. For Doc, we identified a pretty practical attack with only one physical node required, running a few instances, and the adversary result could be all the forwarding routes being disabled, which means no one in this network is forwarding any messages. So message could only reach their direct neighbors. And in addition, we find the DAC protocol itself is not, like, safe in theory, that we find a counterexample, even without an adversary, that the connectivity may not be secured. And for gossip sub, it is more robust, and we assume a geometrical model for the latency, and also some other assumptions. And under these assumptions, it may still be possible for the adversary to cause

To cause a separation of the constant fraction of the network with a constant number of adversary nodes, plus the advantage on latency, targeting the main mechanism. Well, for the additional mechanisms, like the off-bound quota, it requires some additional requirements, and I have… I want mechanism is not considered here. So let's move to the technical part of the doc. So, reminds the goal of the gossiping algorithm is to try to reduce redundancy in this forwarding, and, like. Ideally, one potential goal could be to get something like a spending tree, because that is the most efficient way to get connectivity. And the… the method of doc to achieve this is root filtering. So it… when it finds one root is duplicate, it will filter it out, and that root will not be used again.

So, a root here is a basic forwarding unit for an intermediate node U. A root is a pair from P2 to T that U will forward messages it received from P2 to another neighbor T. And… And if T finds this route to be duplicate, if T receives a duplicate method from U2, and it will ask U2 to filter this route out, so next time, U2 will not forward this. forward via this redundant routes. So, for example, if S1 published some message here, and it could be propagated like this. And… but also, U2 will also try to propagate this message from… it's received from P2 to T, but this one is duplicate, and T will find this to be duplicate, and this root will be filtered out by U2.

So next… so next time, YouTube will not forward messages from P2 to T. if… If someone publishes some other message, this… this duplicate message will not be there again. And there is also a redundancy control mechanism, which allows some duplicates for robustness, and it will adjust the… the filtering to make the… A redundancy level between a range, but we see this mechanism does not make much difference here. And… We study from the adversary's perspective, and we find an adversary construction that the adversary may be able to filter out any route in the network. For example, if the adversary targets a route F to P to T, and they themselves could also control, like, one node in the network. They could publish one message M itself, and they can deliberately control the latency to S and to T to make sure that this message first reached T directly, and then…

that it can also reach T where this route asks P to T later. And in this case, this route will be redundant, and it will be filtered out. And this could be achieved by the adversary deliberately control the latencies and publish its own message. And the redundancy control mechanism could also be addressed with some additional messages involved here. So, if the adversary repeats this. this attack per route for… for one target node. It could filter out all the… forwarding those to that target, and then that target will be separated, that no one will forward any messages to it. And they could even repeat this per node throughout the network, and the result is the full network will be disconnected, that no one will forward any messages.

And also, while the theoretical aim of the… of dog is… of the root filtering of stock is to get something like a spanning tree, but we find this is not really the case in theory, and we also identify a small counterexample even without adversary notes. So, in this RANDA 5 nodes. If M… if they will publish a method M1, it could be propagated like this, and as a result, these two routes will be redundant and filtered out. The same could happen again if one published some messages. And so far, it's still working, but… If we put it together, we could see all the four routes are filtered out. And if node 2 publish another method now.

Nether of 0 and 1 will forward this message, because all of the two routes are filtered out, and basically the network is not connected at this time, even without an active adversary here. So, to summarize for Doc, we identified an adversary attack that only requires a constant number of attackers, and the result could be all the forwarding routes are disabled in the network, and no one is forwarding any message. The only thing is the message could only reach their direct neighbor of the publisher. And the adversary can even maintain this separation indefinitely with some additional methods. And we implemented this. attack, and simulate it with Shadow, and in a small… in a small, like, in a small network, and the result is all the routes are filtered.

So the resulting network is not connected. And let's move to the second part of the gossip sub. So gossip sub is another, gossiping protocol. Our model is, like, it's… It maintains a mesh that each node has around a constant number of deep peers, and it will… maintain this level of degree that's between 6 and 12, for example, if it has less If it has fewer peers than this range, it will try to get some new peers, and if it has more peers than this range, it will try to remove some to the mesh. And in the mesh, a node will forward everything that they received to the other mesh peers. And when the node tries to remove some peers, it needs to select the subset of peers that it wants to preserve. This is done by a mix of mechanisms.

So it's… they may select the top four So let me select four of them by score, so it will preserve the top four by the local peer scoring, and the others may be selected randomly. And there are also additional mechanisms here, the outbound connection quota. And a simplified model of peer scoring is the first message delivery. It's, like, measuring how useful and how good a peer is to a target node locally. So, this score is basically how many new messages that peer could deliver to me, and they are the first one, so it is useful. And this mechanism is more robust than DOC, so we need to assume some model for the adversarial analysis. So we assume the…

honest nodes are in points on a, like, square, or, like, on a plane, and to approximate the geographical latency, we assume the latency between two nodes is the Euclidean distance of those two points, and we assume the message's originates from All the sources uniformly. And we also assume the adversary may control a small number of K adversary notes also in this square, and we assume they can have a slight benefit in the latency, that they, for example, only have 80% of latency. Of the regular one. And this may be achieved by, for example, using some low-latency satellite network, which is not widely used by the full network. And there are additional assumptions required to address the Auton quota, and this could also be extended to consider some dense clusters, like data centers.

So, again, the adversary goal is to separate the network or separate the node. What it could do is to occupy all of the 8 mesh positions of one target node. Well, four of them are selected randomly, and the other four are selected by score. For the random one, it may be easier as long as the attacker has enough, like, IP addresses or identities that they can… repeatedly grabbed you to make a new connection to you, and you will be oversubscribed. It will try to remove some peers, and it will resample those four peers among all, and the adversary could repeatedly do this until they control all of the four positions here. And… The other four of them will be selected by a peer score, which will be the focus of our study.

And there is also the additional outbound quota that each node will maintain at least two outbound connections selected by themselves, which cannot be Manipulated by the inbound connections, and we will consider this later. So, the key here to take over the four score-based positions is to get high peer scores, and for the first message delivery, it means the adversary need to control more messages delivered to one target U. So we could compare the two propagation rules, the regular one, via honest PRP, or via the… the adversary network. Like, remind they have a slightly better latency here. And we… And with when comparing the two latencies, we could find the adversary may control some rate of all the messages to one node, and if it controls a sufficiently large rate, then it may manage to occupy all the positions and cause a separation of U.

And with a constant threshold here, and if we assume the nodes are distributed uniformly, the probability of this being satisfied is a constant, independent of the actual number of nodes in the old network. So the sufficient condition of this is the message control rate is over this ratio. If the adversary can't control this many messages, it could make, for example, 4 adversary connections to a target U, and each of them can deliver a lot of new messages, which is higher than the than the capability of any other honest peers. And as a result, these… these honest peers will be removed based on score, and all the score-based positions will be controlled by the adversary. And this could also be…

extended to target one single link instead of fully separated a node U, and that is substantially easier than achieving this rate for the… for all the, like, against all the honest peers. So, we did some simulation of this… of this probability that when… Thus, the adversary could control this… the enough ratio of all the honest messages. And we… we did this sampling with a thousand nodes, but the converge number should be independent of the… number of samples. So we could see if we target to get over 4 or 5 of the all messages for the adversary, they could achieve this on 40% of all the nodes, which means they could basically separate 40% of the network.

And if the target is only one single link, it means that over 99% of all the links may be Vulnerable to be removed by the attacker with the same method. And this rate could even be boosted by doing this attack iteratively, because once the adversary separates one node, it can also get their messages as fresh messages to earn higher peer score on the other nodes for free. They don't need even to win the race of the latency there. They… this could boost the original… 40%, rate probability to a much higher one, but, like, this is just an extra, we don't consider this as a core analysis. And… And yeah, that's for the main mechanism, which is the peer scoring. We also consider the outbound connection quota in the selection, that each node U

will maintain at least two self-selected outbound PRP, and this could not be manipulated by, for example, the adversary made a lot of connections to you. That will not kick this link out, because only these are outbound connections, so they will also be… so they will always be preserved by the… Ultimately, connection quota. However, this is still addressable. Because an outbound connection at this side is an inbound connection on the other side, so the adversary may still target this link on the other… on the inbound side with the same method, so they still have a high probability of removing this link. And once this link is removed, you will redraw another outbound link uniformly from a candidate's pool.

And if the adversary controls a small rate in this candidate pool, then there is still a constant probability of succeed. for the adversary to take over. So… A remind, in the simulation, the adversary have a 99% probability of chance to remove a uniformly random link in the network. If they also consist of 1% of the candidates in the replacement pool, then there is a constant probability for it to finally take over all the two outbound connections. So, to summarize for gossip-sub, it is more robust, but under these assumptions, the adversary may still be able to cause a constant fraction of the nodes to be separated from the mesh, with a constant number, for example, 100 nodes in the network.

And plus the, for example, 80% latency advantage. To address the ultimate corner, there is additional assumptions, so instead of 100 nodes, they also need to consist of 1% of all the identities in the replacement pool. But the I have, I want mechanism here is not considered, and it's also probably more robust in this scenario, because the adversary with this method has no way to alter it. Because, like, they don't do this. A selection based on heuristics. And, yeah. So, to conclude, we started to… two gossiping protocols, dog and gossip stuff. Dog is more vulnerable, that adversary could cause the full network to be separated, and there is also even a replica counterexample without adversary. gossip sub is more robust, but still under some assumptions, the adversity is possible to cause a constant fraction of separation with a small number of nodes, while the I have, I want mechanism is not addressed here.

And that's how it works, thank you.

Kamil Salakhiev: Okay, yeah, thank you. Any questions? Yeah, I see we have a lot of discussions in chat. Other thing. Questions there were mostly addressed.

Csaba Kiraly: I would have a question.

Kamil Salakhiev: Okay. You have trouble?

Csaba Kiraly: Yeah, I just didn't miss the part, whether you have a published paper on this or not, that's one.

Jiaheng Li: No, this is, like, a semester project I just finished.

Csaba Kiraly: The other part is, did you evaluate time horizon for which an adversary has to play this game until it gets into position. Well, so basically.

Jiaheng Li: Yep.

Csaba Kiraly: My understanding is that your adversary has to play the good guy for quite long, and the question is, how long is this? Until it's basically paying, Please.

Jiaheng Li: Yes.

Csaba Kiraly: As a good pill, serving.

Jiaheng Li: Yay.

Csaba Kiraly: Like, because your adversary is busy leading the network, so… Yeah.

Jiaheng Li: Yeah. Yeah, yeah, so for that, the adversary need to deliver a lot of fresh messages so that they could get a high peer score. If we only consider the first message delivery peer scoring, it could be, like. a few minutes, based on the default, Ethereum configuration of the peer scoring, like, based on the ZK parameters. If they have, like, the threshold is, like, 4 over 5. If they could control, like, 6 over 7 of the… the race, they could gradually get a higher peer score than any other honest node, another honest peer, and with the default decay parameters, this process could be a few minutes, like 3 minutes or something. Well, if we also consider some other…

Some other, like, metrics in the peer scoring, especially the timing in mesh 1, this could be longer, because the target one may have a long time in the mesh, so the adversary needs to gradually, gradually also accumulated on this factor until they could kick everyone out. But this is only for the initial attack. For the… once they get their positions, the later joined nodes will not have an initial advantage on the peer scoring, and that could be pretty quick, like… A thousandth of a second, or something like that.

Csaba Kiraly: Yeah, I was listening.

Jiaheng Li: We didn't… yeah, but we didn't do… do the, like, we didn't run this in the reality, it is just calculation based on the default parameters we get from the REPL.

Csaba Kiraly: But this is for the baseline, but then if you go into the… into the outbound. Yeah. The place is running with 70 peels, so until you are kicking them out, one by one, and making sure all 74s, or half of it falls on your, You're concerning.

Jiaheng Li: Yes.

Csaba Kiraly: That will take things… And peeling is not as this slow in this network, so it's not like,

Jiaheng Li: Yes, this one will be… take longer, because they need to do this repeatedly, and for example, if they consens 1%, they need to kick a new link out, like, 100 times. And, well, the good thing here is each time that their target is not a… appear initially there, but a newly grafted one, so that could be faster than the few minutes one, it could be, like, 10 seconds each time, and you will expect to do this, like, a hundred times, or something like that.

Kamil Salakhiev: Hey, Mikel, I saw your hand raised.

Mikel Cortes: Yep, yeah, just a small comment, like, sometimes… We focus on, kind of, raising up issues on protocols when messages get broadcasted to the entire network. Just want to make the emphasis that, at least for the… for Ethereum. only if you just delay it by 4 seconds, that's already critical. Like, beyond those 4 seconds, for example, of luck. You can just create noise in the network, and it's already as harmful as not seeing the block at all. So, it's probably worth saying it again. And also, yeah, like, I would like to, like, like to know, or… I would like to have clear ideas of how many notes would you like to, or would you need to

Like, you mentioned 1% of the network. But also, like, we have to keep in mind that there are correlations between IPs, like, there are… like, decisions when you're building your Pierce peer store. It prevents you to, I don't know, overlap IPs and some other stuff that are also taken into account.

Jiaheng Li: Yeah. So, first one, for… for our study, we… like, we don't really, like, involve, like, the 4-second thing. The method we do is try to cause separation, because, like, I think causing delay is, like, another… will be another method, because, like, we just manually… like. core for us is to manipulate the peer score to get them to kick it out. So, we… like, we don't really… have a way to only easier manipulate the delay here. And then for your question about the number of nodes, there are two parts. The first part is to get high peer scores. For this, it's like a constant number of nulls, so if we have 100 nodes uniformly separated in the space, then it will be able to separate 40% of

all the nodes in the network, that's for the targeting the main peer scoring, and the 1% is for the additional outbound quota, and this one does not require some geographical distribution. Like, you could even have, like, 1% of all the… identities on one machine, if you can, like, have that many IPs or… anything about identities. So… so the… so, like, there are 100 nodes need to be physically distributed in the space, and the 1% identities is… could be, like, virtual ones, only needs… the only goal is to pop in in the replacement pool.

Kamil Salakhiev: Raul?

Raúl Kripalani: Yeah, so one fault handling technique that I've been meaning to experiment with for a while is… Basically, doing statistical, correlation on your… previous, Delivery rates and delivery latencies, and adjusting for whatever your whatever is happening right now, right? So this is, like Mikel was saying, the protocol is strictly timed, and we expect to receive specific payloads at specific points in time, so you don't even have to wait for an actual fault, delivery fault, to happen. You can actually just start detecting a trend. Which indicates that, you know, if you consistently see blocks arriving at a particular point in time, or a particular, a particular offset from the slot start, of course, this depends on, the actual block.

publishing time, which we know, is subject to timing games and so on. So maybe blobs is not, like, specifically the best, example of this, in terms of, like. you know, perceive latency from the slot start, but attestations definitely are. For blocks, for example, if you start seeing a miss, an actual miss, a binary miss, within the deadline, you know that you have to refresh your mesh, so… or kind of like your peer set, right? So I think, there are very simple mechanisms that are kind of like small feedback loops that the protocol creates for us, and that puts them… we can… we just have to kind of, like, you know, connect the dots. And… and I think these could, like, mechanisms like this could definitely…

allow you to detect when you are in a pathological condition and take a mitigation, on the spot. And… things like… it's a little bit harder with Libby2B right now, but with… with quick, going forward and zero RTT, you could have, very quick ways, so… Pun not intended, to start a connection, to kind of, like, maintain a broad view of the network and decide to peer, with… or, like, bond, or kind of, like, graft a connection with a peer that you have a session resumption token with. And you can just kind of, like, you know, when you're in this pathological place, you can just, like, reestablish, resume connections with other peers, and just get out of it.

So I think, like, probably these fault handling techniques are good for us to think about more generally, and probably experiment with.

Jiaheng Li: Yeah, yeah, yeah, that's kind of, like, smart detection is what we didn't take into account, and yes, I think they will be better than the original one, like, currently what we considered is only the default thing in the gossip sub, that they have some mechanism that if a current peer score is too low, or… or something, or, like, you are, like, delivering, like, too… too few messages, then it will see.

Raúl Kripalani: Yeah.

Jiaheng Li: They see you at an anniversary, but that's why.

Raúl Kripalani: Yeah.

Jiaheng Li: you to move on the lowest level.

Raúl Kripalani: Problem, yeah.

Jiaheng Li: proper, yeah.

Raúl Kripalani: Yeah.

Jiaheng Li: I think…

Raúl Kripalani: And the problem with Gossip Sub is that it does peer Y scoring, right? But it does not ever evaluate its own health, like, the health of the self-node, which is really what we care about here. And it's hard to… Like, do this in any other protocol than just, like, a peer-to-peer network, because any other peer-to-peer, or kind of like, you know, non… like, non-predictable peer-to-peer networks, because you generally just don't know what to expect, but in a strictly timed protocol, like… ethereum, you know what to expect, so you can definitely detect any divergence and react to it.

Jiaheng Li: Yep. Thank you.

Kamil Salakhiev: Caba? Caba, you're muted if you're speaking?

Csaba Kiraly: I'm a bit skeptical about the, kind of, the statistics-based evaluation. the way you were describing it, Raul? because of… It's… it's…

Jiaheng Li: Sorry, can I repeat? I didn't hear the first sentence.

Csaba Kiraly: I'm saying, I was saying about… about the effectiveness of the… of the statistical evaluation of the…

Jiaheng Li: Yeah.

Csaba Kiraly: That, that Zahor was describing. Yeah, thank you.

Raúl Kripalani: It sounds… he's responding to my guide.

Csaba Kiraly: Wait for that one to the end.

Raúl Kripalani: on the slide.

Csaba Kiraly: Well, because I think you would… you would have a hard time differentiating between, like, general network-level issues from… from you being attacked, from… there's so many scenarios that you would… you would see noise. easily. Plus. Yeah, plus your kind of statistical variation could be bad attacked because it's known.

Jiaheng Li: Yeah, this one is only based on the theoretical model, it's not… it's not, like, in any real network, it's only… geometrical model.

Csaba Kiraly: I was speaking about what Zelle was saying about the, kind of…

Raúl Kripalani: I mean, there's… there's a bunch of… for sure, it's not as simple as, like, you know, if I stop receiving messages, they're kind of, like, it deviates. You do have to, like, be aware of your links data, so you could potentially be pinging, or, like, you know, conducting network diagnostics against, hosts that are not even Ethereum, right, to know if your network is healthy and your reachability is healthy in the first place. So there's, like, a lot of correlations that we can do. To become, like, More resilient, and ultimately it's about… Simple, simple, simple connections that we can do, right?

Csaba Kiraly: So I think the idea which we could explore there, is… that I was playing with, for the DAS distribution, actually, is the… I was calling the idea the secret body. So you would… You would basically have one secret body with which you, which, unfortunately, you have to trust it, but that's solvable in many instances. And… and then you would have comparable statistics, hidden from… to the outside world. Which would allow you to identify if you are under the tech. So that's kind of the direction I would… if you, if you are interested.

Raúl Kripalani: Yeah, that's… that's… I mean, that's one thing. I mean, the problem with picking one buddy is that you either have to trust the buddy, or you could pick the wrong buddy, and… and, like, they could be malicious in themselves. So that's… yeah, so that's the problem of, like, picking one party. Like, there's definitely a lot to explore here, a lot of ideas to explore. The other thing while we're on this, maybe, is another interesting idea is kind of, like, the opposite of this, which is not just for inbounds, but for outbounds. Specifically, when you're signing attestations and emitting attestations, you could be constantly measuring how quickly they land on chain, or even if they don't land… if they land on chain or not.

And… and that would give you kind of, like, a sense of your outbound… like, the quality of your outbound mesh, for the time that you are, That you're gonna be attesting on a particular subred. Of course, these rotate very quickly, so maybe it doesn't make a lot of sense.

Csaba Kiraly: That's kind of also the… so the feedback loop that we are using in the EL now is feedback from Consensus. So we are… we are measuring quality on things which… which get on-chain, and… and… and we can use the same…

Raúl Kripalani: There's a bunch of feedback loops in the protocol that we need to close at the networking.

Csaba Kiraly: Glad you.

Raúl Kripalani: Steph, you're good.

Csaba Kiraly: I'll be… I mean, we have easier ones, but also fewer ones. On the CR, we have many of them, and maybe more noisy, but I think we can find feedback loops which are protecting you by feeding back from concerns. Yep, yo.

Kamil Salakhiev: Alright, yeah, any other questions? Okay, if not, then, yeah, thanks, Jiaheng.

Jiaheng Li: Thank you.

Kamil Salakhiev: patients. Good discussions. Yeah, any other discussion items we have for today, if anyone wants to bring up anything? Right, nice. Yeah, I think… If not, yeah, we can, just drop up here, so then, yeah, thanks everyone for joining. See you in two weeks.

Anton Nashatyrev: Yeah, thanks.

Daniel Knopik: Yeah, bye. Thanks for the presentation.

Yann Vonlanthen: Bye-bye. That's so cool. Looks like this one.

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