 Hi guys, so yeah, I'm Felix. I work for a theorem foundation I'm one of the maintainers of Goi theorem, and I'm also the maintainer of the deaf PDP specifications so in This talk, I'm just gonna you know talk about Things that happened around that PDP in 2018 So yeah, I get to answer this question every year. So What's deaf PDP? Well, it's a peer-to-peer networking stack and It's basically it's a system that if there are nodes used to talk to each other over the network so and it has all the things that PDP networking stacks usually have so it has a system for finding nodes on the internet and It has an encrypted transfer protocol that you even heard about a bit earlier It's not the best, but it does have one and this is the protocol that the nodes actually use once they are exchanging data I think the important thing to know about deaf PDP mostly is that it's an integrated networking stack so all the components work together in a predefined way and This is great because it means that The system has certain properties that we can rely on and it's actually much easier to evaluate the security this way because if Well, if you know how exactly this stuff is going to be used then it's it's it's easy to reason about So there are around 10 implementations of deaf PDP right now so you can see them listed here Most of these implement like most of the deaf PDP implementations are part of some kind of a theorem blockchain client But it's not all blockchains So there is there are some implementations that are incomplete or they're just a library that implement a certain part of it and The FPP isn't just useful the blockchain. It's also used By other projects like the swarm distributed file system most of the offshoots of the swarm file system also use it and Even the status messenger app use it for a long time But I'm not sure whether they're still using it or whether they switch to something else by now Yeah, so apart from these implementations that are just you know speaking the protocol There are a couple of tools around Specifically what we have is a couple of DHT crawlers some of them open source some of them not so the most famous one is ethanoats.org which you can visit and check stats and Basically, so a DHT crawler explores the node discovery system to see which nodes are around and then it lists those on the web page and Then finally for networking nerds This year consensus has released wire shock to sectors for the protocols And I'm actually really happy about that because it means it's much easier now to debug issues with a protocol Because I can just load it up in wire shock and see what is the note doing and it Labels all the packets that are being sent on the wire by name and things like that. So this is a really helpful thing alright Let's talk about the live network for a bit So we're still alive, I guess We have around 12,000 Ethereum mainnet nodes just like last year at least that's what ethanoats says and The number of DHT participants is actually quite a bit higher because When you look at ethanoats what you what you see on the front page is if there are mainnet nodes Which ethanoats has decided that you know this node is part of the mainnet But actually in the discovery you'll find a bunch more nodes that are doing all kinds of stuff like there are other blockchains Which which have somehow imported the FB2P there. There's there are swarm nodes There are all kinds of nodes listed there so you can actually find a lot more nodes than just those Oh Right, I forgot something Yeah, actually we haven't In 2018 there haven't been any new attacks. So this is why I'm also happy about that So and in general, we're not seeing a lot of network level attacks So most of the attacks on a theorem have been on the consensus protocol level But on on the network level we haven't actually seen Any malicious activity as far as we know at least in 2018 so there wasn't was not like a major network disruption but What we did see was that there was a research paper was published in the beginning of the year by Researchers at the University of Boston where they explored the possibility of an eclipse attack on the Ethereum discovery network but fortunately for us this This was disclosed responsibly through the bounty program so they Sent the paper to us a month in advance and we could actually read it before it was published and we could mitigate the issues And I'll talk a bit about that later So, yeah, this is now the section where we talk about, you know, what happened in terms of development in 2018 So the first new thing is actually kind kind of old so all the specs were rewritten and if you Read the old spec, it was just one document Maybe you'll understand why so it was really hard to read. It was incomplete at times You couldn't really figure figure out what what the semantics of the protocol were Half of the document was stuff that never got implemented. It was just a big bunch of I don't know notes basically so Yeah, I'm a bit proud to say that, you know, the specs are now much more readable and they're up to date Yeah, just in general, I've split up the specs into into into multiple parts. So I feel like it should it should all be a lot nicer now and We have a test suit now. So This is something that I'm very excited about Frank Has joined the Goi theorem team very recently and he has created a peer-to-peer networking test suit based on the Hive tool So Hive is a tool that we use for testing the consensus between clients and it's also a It's also used for testing the RPC interface to to to the to the clients. So now we can test the peer-to-peer networking as well and Gaff parity Eleph and a theorem J are hooked up to this test suit and Trinity is being added Well, it's you know been being added since a couple months now So I think it's gonna be done any any second but yeah, it it will eventually also be there and Really like adding a client to to Hive isn't all that hard. So it's I think this is a huge success So in guess what what's happened in death so In the beginning of the year we were we were really busy implementing the mitigation for the for the eclipse attack and Basically the way the attack works is that a note can be surrounded on the discovery level with attacker nodes and it won't be able to Find any any kind of honest node because all all all it will know about is like these these these attackers that were spawned specifically to to to bring us note down and the way we approached the mitigation was to introduce IP limits on the connectivity and So basically you you can you have to have like a a nice looking IP address to connect Yeah, something like that and and we also We reworked how the discovery tables work so that the table can't be overrun by attackers so easily and Then later in the year We've introduced support for E&R throughout the goal P2P code base I'll have something about E&R later if that doesn't mean anything to you. It's fine and And we've modularized the discovery code in general so we're now ready to actually plug in different pure discovery mechanisms and This is massively gonna help With adoption of some of the new changes But most of the changes to the P2P code base haven't had any kind of immediate impact on the connectivity So, you know as a user of gath, you're not gonna like see I don't know any improvements basically It's so yeah, it's basically it's mostly been prep work and then as Gion mentioned we've done this experiment to run to run def P2P applications on lip P2P so Since you already talked about it so much I'm just gonna skip it now. So it was I Think the experiment was Successful and we have a pretty pretty clear roadmap now of how to integrate the P2P into the whole def P2P thing Okay, so There are some ongoing changes to the to the to the low-level protocols. So independent of any actual implementation and Yeah, so what I've done this year is to just I've published three EAP drafts The first one is EAP 778. That's ethereum node records and this is kind of at the heart of it So ethereum node records are a new concept. It's like a small document format about with node metadata It's a bit like business cards for for nodes and in those business cards The nodes can declare transport capabilities and application capabilities and all these kinds of things And then they can be relayed through some medium and then up next we have this EAP 868, which is a tiny specification that integrates node records into the existing discovery protocol. So this one's really short and Then finally we have something new which is the last item and that one is a Entirely new mechanism for discovering nodes based on on DNS. So it basically allows you to find Node records behind a certain DNS name and it's totally independent of the of the distributed hash table So yeah E&R so what's that about? So I'll maybe I'll it's when people look at the E&R specification They can sometimes while they come back to me and they say well, what can I use this for? I mean, this is like, you know, there are almost no details in the EAP about, you know potential users And and it's it's it's a document format. I mean, how does it relate to? to to to the grand scheme of things so the thing about E&R is that it's more like it's like a medium for negotiating all kinds of capabilities that nodes have and It can be a bit hard to imagine like which capabilities are actually worth negotiating between nodes So I'll just have a couple examples for for for you guys now so the one of the things that Makes me excited about E&R is that it gives us the option to switch to a zero round trip and encryption scheme so if two nodes learn about each other in some discovery system What what the discovery system can do for them is it can relay key material which can be used to Pre-compute secrets for a connection and this is actually really nice because it means that As soon as a connection between those two nodes is created The the nodes can start sending data that's relevant to the application pretty much within the first byte because Because most of the secrets that are needed to to encrypt their communication already pre-computed before the connection was even created and Yeah, so I feel like this is this is a pretty useful feature But what we need for that obviously is a way to like relay this initial key material and this is where where you know it can help The second thing is well transport options. So this is something that also makes sense to to negotiate up front because like Guillaume told you we have this ambitious plan to use some of the lip PDP Transport offerings in In our deaf PDP stack, but in order to make this work Well, if you have a note that speaks lip PDP and have and you have another that wants to talk to it That other note means to know whether the PDP is supported And this isn't really something you just sort of try and you can poke the note and then see it Well, it's not responding, but that just takes super long and the right solution here is to just know that this note is capable of speaking a PDP and So for these kinds of things, it's obviously very useful if the note can declare up front in in some kind of system that it's compatible with with With with with whatever transport you want to speak and then finally there's another thing which is negotiating prices. So What kind of prices well so in systems like the Ethereum like client or swarm you have something called an incentive system So in an incentive system on the network level, there are clients and there are servers and the clients pay the servers for whatever bandwidth they they're using and Well that bandwidth comes at a certain price and If you have an incentive system set up then there's a market for servers obviously because some servers are going to have one price and other servers going to offer another price and As a client you want to connect to servers that are sort of like in your price range, right? I mean, you don't have an infinite budget you You need you need a server that that gives you like the most how do you say bang for the buck? I guess and so To make this work if you if you can already know upfront that a certain server for say swarm can offer you data at a Certain price that can influence your your your connectivity decisions as a client So you're obviously going to prefer the the servers that are you know match your your price expectations, right? and Let's just go and look a bit at how the DNS discovery works because this is like the the the new thing So the DNS discovery is a bit different from the others because it doesn't it doesn't talk about improving any existing protocol it's a totally new protocol and We've come up with this scheme because we want a replacement for bootstrap node lists So in most clients what you'll find is there is a there's a hard-coded list of bootstrap nodes We usually is not that long and these nodes are the initial entry point into the network So when you want to talk to the theorem blockchain, you've got to start somewhere So you got to find someone who's on that blockchain more or less talk to them first and then find all the others who are also you know into this thing and These maintaining these lists is you know annoying because when if we want to add a node to it then we can just put in a source code people can Download some release a new release of the client and then they'll have it but we'd rather much rather have a List that's dynamic that can be updated on the fly and the list that's like very very long right so we you know for initial entry points You'd better give people some some options. So What we envision for DNS discovery is a system that can dynamically with the help of the distributed hash table create a massive list of nodes that have a certain uptime and that have certain capabilities like Let's say like a big list of main of mainnet nodes Well, then we compile them into a certain format and publish that at some DNS provider and Well, and then clients would be able to find them there and Well, that's DNS discovery for you. All right, and there is one more feature So the thing is the the system also includes a certain it's a bit like a web of trust So one node list can actually refer to another node list using the DNS name of the list and the public key And this means that well certain lists can sort of authorize each other and we can we can group them into metalists and things like that right so Yeah, the eeps so Ethereum node records is implemented in go Python and JavaScript so far The extension is implemented in go but isn't isn't merged in the master branch And no discovery via DNS is implemented in go in Python, but the deployer tool that that moves it to Moves it to it to a DNS provider isn't really done yet Right, and now I had just have two more minutes. I guess more or less. It says to there So I'm just I look at this clock And so I'll just talk about a bit about what's next so we have an ongoing discussion with the sharding team the the theorem research team about how we can how we can join the efforts because The Ethereum sharding right now the networking is based on lipid up So I feel this is a good decision with lipid up because it gives them a lot of options to try out But obviously like I myself want to like feed my improvements that I'm working on You know on the fund the Ethereum Foundation payroll I want to you know feed those improvements into the sharding so I feel like the things that that that we're doing here to to improve depth PDP these things can actually benefit sharding in the long run, but Right now there isn't much overlap But like I said, we have an ongoing discussion and then the biggest challenge that sharding faces is just that they need a system where Peers can can can be switched really quickly and we're trying to make that work Right, I'm gonna skip this part and I'm gonna just quickly say before I have to go that There's a big plan for 2019 to offer depth PDP as a web assembly module So that you guys if you ever want to use depth PDP you don't have to use go or like another good implementation But probably that's gonna be go because it's the best. Yeah But yeah, so this is a plan that we have and Thanks