Introduction to Nethermind Discovery Protocol
When we talk generally about networks, most of the time we are referring to client-server structure. However, if we are looking at blockchains such as Ethereum, we need to take a different approach.
Blockchains were built with the mindset of bringing power back to the people with a decentralised peer-to-peer (P2P) network. While in the client-server approach the server sets the rules and without it the network would not exist, a P2P network is built with many computers (nodes) communicating with each other all while having the same permissions.
However, before a node starts to send and receive information to/from other nodes, they have to get to know each other. This is where Discovery Protocol comes into play.
In short, a discovery protocol is used to find and retrieve information about nodes in the network. It is based on Kademlia distributed hash table which is used in other P2P networks like BitTorrent or Skype.
Discovery Protocol uses messages such as:
Ping — check to see if the node (to whom we send it) is alive
Pong — reply to Ping (hey, I’m alive)
FindNode — request information about nodes close to the receiver of the message (can you tell me about your neighbours?)
Neighbours — reply to FindNode, returns a set of informations about closest nodes to sender
Let’s say that you are a computer that wants to join an Ethereum P2P network. First of all you’ll need to know at least one node that is already participating in the network and send a FindNode message to it in order to get information about other nodes on the network. To simplify this process, Ethereum Clients have hard-coded some bootnodes’ ip.
BUT NOT SO FAST!
Solid Ethereum clients (such as Nethermind) protect against spoofing attacks and won’t allow to send Neighbours after only receiving FindNode messages.
If you haven’t heard of a spoofing attack before, it happens when a node falsely tells a node that it is another node on the network, expecting to receive a Neighbours message in return. The receiver of the message then sends this big chunk of data to the unfortunate spoofed ip address which can lead to a DoS attack.
Now let’s see how Discovery Protocol works in Nethermind with Goerli testnet:
Everything starts in goerli.json chain spec. There on lines 55–62 we have some of the bootnodes to this network to which we should send our first Ping messages.
There is a lot going on before we send first Ping message to our bootnodes, but in the interest of simplicity we will skip it and instead focus on DiscoveryApp.cs, DiscoveryManager.cs and NodeLifecycleManager.cs.
When DiscoveryApp.cs is created, our User Datagram Protocol (UDP) channel is initialized, enabling us to send and receive messages on this protocol as well as start talking to bootnodes — sending first Ping and FindNode messages.
DiscoveryManager.cs, in short, takes all of the incoming messages and looks at what type of devp2p message is that and decides what should be done.
Last but certainly not least is NodeLifecycleManager.cs. This class manages all messages processing.
As you can see below, right after the first Neighbours messages come from bootnodes, the process of discovering a network begins and the ability to talk to other nodes on it becomes available.
Of course there is much more in Nethermind’s discovery module, but that’s something we can dive into at a later time — stay tuned!
In the meantime, check out our docs: https://docs.nethermind.io/nethermind/
— — — —
Keep up to date with all the latest Nethermind news by following us on our socials:
- Newsletter Signup: http://nethermind.io/newsletter
- Twitter — https://twitter.com/nethermindeth
- LinkedIn — https://www.linkedin.com/company/nethermind
- GitHub: https://github.com/NethermindEth/nethermind
- Discord — https://discord.gg/XUz8Bd
- Gitter — https://gitter.im/nethermindeth/nethermind
- Email — hello@nethermind.io
