 Should I use this? Okay. Hi guys. So I'm Felix. I work for Ethereum Foundation on the Go Ethereum client. And my role there is mainly bug fixing and feature development, but I guess there is a lot less time for new features lately. And my passion in this project has always been, you know, like taking care of the way that nodes talk to each other. And this is also what I'm talking about today. So, DeathP2P came into existence, I guess, about three years ago. And at the time, the vision was to, as you can read there, provide a lightweight abstraction layer that provides low level algorithms, protocols and services in a transparent framework. So, you know, like it was a pretty grand vision. In 2017 though, DeathP2P is just this thing that you need to implement to talk to the Ethereum blockchain. And it's part of all known Ethereum implementations. So all of the six, seven implementations that are live on the network have an implementation of DeathP2P and all of the stuff that's in it. And there have been very few actual protocol changes since 2014. So if you wanted to, you could count them on one hand, basically. DeathP2P has a bunch of elements to it. So the first one is the node discovery protocol, which is a way of finding other nodes to talk to. Then there is the RLPX transport protocol, which is what it's spoken on the TCP connections between nodes. And finally, there's an application layer protocol that sits on top of the RLPX transport protocol. And this one is somewhat confusingly also called DeathP2P. So both the overall system and this particular protocol are called DeathP2P. Let me just walk you through the protocol that's in use on the network today. And then maybe we'll come to the part that can actually be improved about this. So this dark circle there, that's us. So that's where node that wants to connect to the Ethereum network. So how do we do that? So we'll join the DHT first. And the DHT is basically the part that is this thing where you can find the other nodes that are on the network. Yeah, so there are some other nodes. They're also registered there. And then basically we walked the DHT at random to find someone to connect to. And then we try to establish a TCP connection to them. And the TCP connection might actually fail, so this happens quite a lot because it might no longer be live or it might be too busy handling other connections. But let's just assume that it works this time. So once the connection is established, we exchange capabilities with the other side. So basically, this is now the part where like the DEF PDP application layer kicks in. And in this particular case, we see that the shared capabilities or there's just one shared capability and it's the ETH capability in version 63. So now once ETH version 63 is running, we can exchange information about the blockchain that we're both on. And once that matches, we have a new peer. Yeah, so that's the current system. And it's not super efficient. And well, there's a whole bunch of details that I haven't really talked about, but I guess you kind of get the idea. So what can be improved about this though? So first of all, it's kind of annoying that there are so many round trips just to figure out whether someone is on the right blockchain. I mean, I guess that's kind of obvious. And then it would be really nice to just sort of know that like before even connecting maybe. And then another issue is that the whole system is basically frozen. So making any change to any of the protocols requires like really tight coordination, requires implementation consensus. And any change that we make needs to be backwards compatible. And to achieve upgrades at all, what we've done in the past is we've made all the upgrades backwards compatible and we've tied them to Ethereum mainnet hard forks because well, everyone has to upgrade their node anyways. And then once the hard fork is successfully launched, we can start phasing out the old stuff and just only speak the new protocol. But hard forks don't happen all that often and we'd rather make changes on an accelerated schedule, but it's really not that possible. And then finally, because node discovery only relates information about the RLPX protocol, there's really not, there's like any sort of room for experimentation because, well, we're essentially stuck with RLPX and the crypto system that it uses. So improving these things is the node discovery version five effort. And with node discovery version five, we want to make two changes in particular. Or rather we want to achieve two things in particular. So the first one is, we'd rather be able to find nodes more efficiently. And then the second one is, we'd rather know more about those nodes before we even connect. So the first part of our solution to these issues is called ENR, which stands for Ethereum node records. So earlier in the V4 overview, you saw that the DHT holds all those E node addresses and an E node address is really just a public key and IP address in two ports. Ethereum node records can hold arbitrary information about a node, so that's the main difference. So this arbitrary information, that can be information about the capabilities of the node. It can be information about other transport protocols spoken by the node. It can be initial key material for those transports, anything really. As long as it fits into 300 bytes, we're basically like almost anything can be relayed there. And the limitation of 300 bytes is important because ENR is a separate format, a separate spec even, and it's not at all connected to the DHT. So you can relay those records through any other means if you want to, including say a DNS record or something like that. And then finally, node records are signed and also versioned. So if you have two versions of a record that describe the same node, you can determine which one is newer, for example. And we think that ENR is a good solution for the transport agility problem because again, information about arbitrary transports can be relayed through this protocol. And well, yeah, because there's just a lot more room to put information about anything. So we still need implementation consensus though because in order to be able to talk to everyone, everyone kind of has to agree on what the language is that they're speaking to, that they're using when speaking to each other. And it is very likely that for a considerable amount of time the lowest common denominator will be RLPX. But eventually once ENR is launched, we can actually try out different transports, find a viable alternative, and then maybe at the end of 2020, delete RLPX. So in order to get ENR launched though, we need to upgrade the discovery protocol. This is something that needs to happen once and it will be a backwards incompatible upgrade. So likely the way this will work is that the Discovery version 5 DHT will be a totally separate DHT that will run in parallel to the current system. And because this is kind of a unique opportunity for us, in addition to just including support for ENR, we want to make a bunch of other changes to the protocol. In particular, one problem that the V4 Discovery protocol has is its reliance on absolute time. So maybe some of you have actually experienced this. So if your clock is off, let's say by two minutes, you won't really be able to connect to the network. And we've worked around this by alerting users when their clock seems off, but that's a really ugly workaround. And you know, like we might just fix it in the protocol this time. And then with many of the nodes in the DHT, you'll find that the information that's listed there isn't very accurate. So you might not be able to connect to this node at all, even though it's listed there. And in V5, we want to introduce this concept of endpoint proofs where the DHT ensures that if a node's record is listed in the DHT, there's a pretty fair chance that you'll be able to connect to it. And then finally, we have another improvement, which can be considered an extension of the DHT protocol. And this one is about finding nodes more efficiently. So in a classical DHT, so to say, the DHT is an index of nodes by their public key. And it maps public keys to node endpoints. But, well, so the nodes, in the DHT, though, they're not in any kind of useful order. So you'll find an Ethereum mainnet node next to an Ethereum classic node next to a node that doesn't really participate in the Ethereum blockchain at all. And there's a lot of different ways of knowing about just the nodes that you care about. And, contrasting that, the topic index that we have in mind is sort of like an index of all the nodes by the topic or the service that they are providing. I don't have a lot of time today to really go into the detail of how this works, but I can give you an overview of the design constraints that we set when making this protocol. So the first big constraint that we had is that we don't want to split up the DHT because with DHTs, bigger is better, right? I mean, fundamentally, the security of a DHT depends on the number of participants in it. So you would want to, like, always have a very large number of participants. And another design constraint we had is that these topics kind of have to scale to an arbitrary number of participants. So there might be topics that everyone is advertising, like everyone who's in the whole network. But then, on the other hand, there might also be topics that are very small and only advertised by, let's say, five or six different nodes. And these topics shouldn't really compete with the other participants. So you should be able to resolve both equally quickly. And then finally, with all of these systems, there's always, like, the danger of, you know, people spamming it with, like, arbitrary registrations that nobody ever cares about. And those particular registrations should not drown out, you know, the actual useful ones that you really want to see. And to combat many of these attacks, the topic advertisement protocol includes this thing called advertisement inertia. So this is really just, you know, an artificial delay enforced by the protocol before a certain registration for a topic can go live. And we feel that, you know, in addition to maybe reducing misuse of the, in addition to, you know, combating these attacks, this also reduces the, you know, misuse of the topic index. Because fundamentally, topics are meant to be used for announcing big decisions like way ahead of time. And those big decisions can be something like which blockchain you're on, or which chart of the blockchain you're on, or, well, you know, things like that. And not so much, like, let's say, the URL of a video chat that, you know, you're just starting. So there's a, you know, we really want those things to be used, you know, like for facts that will have, you know, a bit of a bigger meaning. So to recap, the Node Discovery version five is about finding nodes more efficiently and knowing more about those nodes before we connect. A prototype of the system, although without the ENR, has been in use by the Get Like client since early 2000s. We're still working on the EIPs, so nothing is published yet. But once it is, we will have, like, a separate spec for ENR, a document that goes into detail about, you know, like, the semantics of the topic advertisement protocol, and finally, a description of the actual wire protocol that's spoken via UDP. But there is really nothing set in stone yet, so if you feel like in any way there's a certain change that absolutely has to be made or a certain feature that should really be included or not included, just come talk to us. That's it.