# Notes on Discv5

References:
* [Discv5- service discovery for Eth p2p by Michal Krol](https://youtu.be/o17ly2hej9w)

Explanation about the underlying process when a new node joins into the Ethereum system(underlying Distributed Hash Table).

**Bootstrap node:**
These are the hard coded nodes to which the new node talks to, these nodes are hard-coded into the ethereum code base

**Ethereum Ecosystem**

Not only Ethereum main-net
* Multiple Ethereum forks
* Several test-nets(Rinkeby, Ropsten)
* Alternative cryptocurrencies(Pirl, Musicoin)
* Additional Applications(iExec, Swarm)

Around 4000 applications
Large differences in popularity

Let's refer them to as Eth applications
The vision is to create a common entry point for many p2p apps

> why can't we have a new DHT per app?

Security reason was stated here

Discv4
* Service discovery v4
* Uses a brute force approach
1. find nodes using random walks
2. Handshakes with encountered nodes to obtain their supported application

* Problems with efficiency
1. Long time to discover peers for unpopular applications
2. Large overhead


**Ethereum DHT**
* Based on Kademlia, there are some minor tweaks
* Each node is uniquely identified by its randomly generated nodeID
* A nodeID in Ethereum is a 256-bit marshaled version of node's public key
* Keys used to secure point-to-point connections between nodes A data item stored in the DHT is found by its key(a hash of the data itself)
* The distance between two IDs is expressed as the length of the common prefix (in bits)
* Each node has peers
* Peers are stored in a routing table
* Routing table organized in fixed-size buckets based on the distance from the node

**Design goals**

* Protocol that allows nodes using the same application to discover each other
* Application advertised under "topics"
* based on existing infrastructure
1. Fast
2. Low overhead
3. Fair (Load balance, No discrimination agains unpopular topics)
4. Robust with network dynamics
5. Secure