What can Ethereum learn from other networks?
Devcon 8 · 4 Nov 2026 · 10:39
Networking researcher and ProbeLab founder Yiannis Psaras asks what Ethereum's peer-to-peer layer can learn from other networks, drawing on monitoring of more than ten of them. The talk recommends simplifying a setup where every node runs two clients on two networks, moving to a QUIC-only stack, and modernizing GossipSub.
Speakers
Topics
From Devcon 8, hosted by Ethereum Foundation.
Transcript
[music] Thank you everyone. Uh thanks for staying so late. Um so yeah uh a lightning talk, a summarizing talk about um what Ethereum can learn from other peer-to-peer networks. Um so basically it's going to be a mild critique as well as a set of recommendations from from our team. Um, but who is our team and why should you kind of listen to us? Um, we've been around since 2022. Um, well, in the area before, but uh we've been kind of mapping the decentralized web since 2022. Uh, we've got more than uh 10 networks monitored publicly. If you
go to probab.io uh our website and several others um monitored not publicly. Um we have uh experience with every kind of kind of protocol or protocol structure in the peer-to-peer stack uh from DHDs to message broadcasting protocols, pubs sub, gossip sub and you know all of that uh as well as uh lately collecting more than 11 billion data points per month um from our tooling that runs 24/7 um to monitor those networks. So um we kind of have been working in the area for quite a while and we have assisted quite a few teams with optimizations they can do um to their protocol stack to their peer-to-peer protocol stack. So
how does Ethereum peerto-peer look like today? Um as you probably already know there are two uh every node has got to run two clients which means two stacks um and join two networks. This is the execution layer and then uh the consensus layer uh as well which basically means you you've got to have um two of everything which means um things are a little more complicated but you also have to maintain all of the uh all of the protocols uh listed in this uh on this slide. Uh which makes it a little you know um not very not very efficient if we can put it this way. Uh so how can we improve it? I mean there
are several ways but I've just some um kind of collected here uh top of mind thoughts that um we've been discussing with with our team. Um there are several others and I'm very happy to talk about them separately. Um so removing complexity is always a wise choice I would say. Uh remove also legacy code that doesn't need to be there. Um so as I said uh just in the previous slide one node two clients two networks two of everything. Um a unifi unification of a start of the stack is um I guess a wise choice. I've heard that there is a um well yeah there is a third stock being proposed and worked on as of um uh I
think Argentina last year uh which is the ETH B2P stock. uh I'm not yeah I'm not very much up to date as to you know whether this is going on and to each extent but I would say uh would rather unify what we have rather than add a new one um there are examples like uh silver the new uh consensus layer client which is lip spec compatible compliant as well as um polar light P2P move which um basically you know took out lots of the complexity so we and take examples from there. Uh there is a talk by my uh colleague uh Mikuel tomorrow at Lotus Stage 3 to give more details about that.
Another kind of u um kind of mild critique perhaps talk but uh with more details on this one. Um so quick uh it has it's well known the benefits of of quick are well known that we don't need to go through them again. um the zero RT and faster connections is a clear winner uh here but as well as other things like encrypted uh TLS messages and and so on. Uh so the recommendation here is that there should be a quick only stack. I mean quick is supported by several clients. We know that uh but you know having um a TCP fallback is something that I would argue is not necessarily needed. Um and of course reduces
maintenance effort, right? So um um kind of uh two stones with uh two birds with one stone. Um a final one uh in terms of improvements um so there is this kind of famous gossip sub protocol uh which is used to propagate messages in the network. So um messages and blocks and everything that's how uh the blockchain is basically uh advancing. It has been designed a few years ago uh in 2020 uh in fact uh by some of our team back at you at um at protocol labs at that time.
Uh now okay it needs a little bit of mo modernization um it needs new features and um it's working well it's battle tested all these years so you know larger signatures and you know more proofs will mean more stress to the network. So we'll need to see if gossip if gossip subop is going to be able to support this especially for homestakers that are kind of more bandwidth restricted. Um there are some proposals already in the works and some of them ready. The spread um uh extension which uh adds to latency improvements and privacy uh and waggle uh at the same time uh which is a more lightweight broadcasting uh transport um
as well as optimum RLNC based broadcast. So there are examples out there that we can learn from um and improve like you know give a a faceelift if if I can put it that way to gossip up to uh be up to date with latest developments. Um we're running a peerto-peer hub community hub upstairs. Uh so you can uh you know this summary talk can be extended and we can uh we can chat more there if you want to come along. Uh there are very interesting talks uh scheduled for every day. Uh so yeah summary of the summary simplify the stack quick only transport and uh modern modern broadcast mechanisms. Uh that's it from me. Thank you very much. Here's
the contact details and here's how you can reach problem.io to find out all the uh dashboards we have. >> Beautiful. Thank you very much Jiannis. [applause] Now we do have a bit of time for questions. So opening it up. Oh, I forgot to I think that No, you're closer. You'll make my life easier. >> Nice catch. Thanks for the save. >> Um, yeah. Hi. I'm I'm just wondering what your thoughts are about how we could simplify the protocol because so I work on a client team.
>> Yeah. >> And I don't think anybody's got the energy for the simplification because that's got its own migration cost. >> It does. >> Yeah. Um yeah, this is true is uh one I mean you know is one of these investments that you do and they don't pay off until quite a bit later you know so that that's my take at least. So there needs to be some push now to uh simplify and unify things but then the reduction in effort that you know you're going to save by maintaining several things is eventually going to pay off I would argue. Uh yeah, but I I presume you're talking about simplifying to li because we'd have to go to one,
>> right? Or >> I I Yeah. Yeah. Yeah. >> I I that's what I would choose. Yes. Um you know, there is the discify. >> Yeah. So I'm I'm asking for a maint from a m maintainers perspective. I don't really care which one. Right. I I agree with you. >> It would be better if we got to one. Yeah. Yeah. >> It's just there's a lot of people who've got in um >> different opinions. >> Different opinions. Yeah. So, it's kind of like I'm just wondering whether you've got any thoughts about how you >> ah that's that's where the the question was going like how can we pick one like from a community?
>> How do we make sure people I mean we could pick one by all deciding to do one thing and it's the all deciding to do one thing is the difficult bit of the process. >> I know. I know. Yeah. I don't have any >> It's a social not a technical problem. >> Yeah. Exactly. Exactly. I now got the question. Yes. Um yeah, it's not easy. I don't know. But I think um I don't know. It's easy to say that you we can go for something that is um you know battle tested and has got the features the the the least effort I I would say the least effort path and >> everyone should be convinced then right because everyone would have to do less work to get to that stage.
>> No, but different people have got different opinions about what least effort is. That's >> fair enough. Fair enough. Yeah. Yeah. No, I understand. It's very difficult. >> Just tell them they're all wrong. >> Yeah. >> Everybody telling everybody else >> voting then maybe. I don't know. >> Yeah, maybe. [laughter] >> Next question. >> Um, which network does it the most elegantly? Would you say like, "Oh, look at these guys. They're doing it so well." you didn't u mention like the name is it but some all tell one which one is it I'm curious >> right difficult question uh I I wouldn't have one to pick to be honest uh I like
the polka dot move that went to the light P2P thing because uh it's a good effort and maybe others should you know it should become even a lito version that is going to be a light P2P thing um getting rid of all the baggage that has been hanging from there for for all these years Um yeah but I wouldn't have a network to say okay that's the the one and only example >> maybe maybe should become that that you know make the wise choices so that others look up to you and say okay look >> right okay so okay so >> diplomatic answer I don't know >> yeah but no but so they're all they have all have their own quirks huh there's no
one like clear like oh they're so good >> yes yes cool >> that's my opinion Great. Any more questions for the crowd? >> [music]