Discv5 Protocol - Technical Comments

Tags: p2p dht privacy-preserving-networks

This is an unfinished draft. The content may change considerably in thenear future!

This blog post is part of a series of articles with technical opinions and reviews about security, cryptographic protocols and P2P technology published online which I happen to find interesting.

What This document outlines the rationale behind the technical decision of discv5 - the network layer for the Ethereum 2.0 network which is meant to replace discv4. It focuses on requirements, vulnerabilities and solutions. One of Discv5’s goals is to improve on the Kademlia implementation flaws, such as network fragmentation. The protocol should also obfuscate the traffic, making it harder to perform system analysis and timing attacks trivially. Polluting the routine tables (through active attacks and/or implementation errors) seems to be one main concern, along with replay attacks (e.g. of NODES and PONGS messages). In short, the attack vectors are active routing table pollution, Sybil attacks and replay attacks.

UDP is used to make it easier to perform NAT hole-punching and NAT traversal. As opposed to IPFS, which relies on libp2p which is multiprotocol by design, discv5 only supports UDP transport. The reasoning is to maximize the communication success between peers and simplicity. In addition, other advantages are shot-and-fire and low overhead of UDP. Comments: Implementation simplicity in an advantage and discv5 is well defined protocol and not a networking library that needs to be flexible to be competitive. Thus, using only UDP is a good decision in this context.

Kademlia is used because of its simplicity, while providing an overlay network that scales with the number of participants and that supports peer discovery across the whole network.

More to read Main repo for specs and documentation Specs