Discv5 Explainer Series: #2
In our last discussion, we introduced the Discv5 protocol and explained how nodes manage their identity and their neighbours. By using an identity system, nodes are able to establish secure and verifiable connections with other nodes in the network. As we move forward, we'll dig deeper into how nodes find each other and communicate securely in this follow-up article. We'll examine the different types of messages and packets that are relayed in the network, how connections start, and how communication sessions are set up using Discv5. By the end of this article, you'll have a clear understanding of how nodes discover each other and communicate in a peer-to-peer manner.
Messages and Packets Overview
Messages
The Discv5 protocol supports various message types that nodes can send or receive. Each type of message has a matching pair: one for requesting something and one for responding to it. For example, a node can ask another node for its metadata (information about itself) and get an answer with the metadata. When a node receives a message, it uses a number called the message ID to identify what type of message it is. Then, it sends back the appropriate type of message. These messages play a crucial role in maintaining the network's connectivity, allowing nodes to locate suitable peers, share information, and synchronise data. The table below lists all the types of messages that Discv5 supports and their IDs.
| Message Type | Message ID | Description |
|---|---|---|
| PING Request | 1 | A message that is sent periodically to verify if the other node is still active. It also shares updated information about the sender's status and how to reach them. |
| PONG Response | 2 | A message sent back after receiving a PING request, confirming that the other node is working and sharing its own status and contact information. |
| FINDNODE Request | 3 | A message sent to locate other nodes that are a specific XOR distance away from the recipient node's ID, helping to establish and maintain connections within the network. |
| NODES Response | 4 | A message sent in reply to a FINDNODE or TOPICQUERY request, containing a list of nodes that meet the requester's criteria. By sharing this information, it strengthens connections, expands the network reach, and ultimately improves network discovery. |
| TALKREQ Request | 5 | A message sent with a particular set of rules for data sharing between nodes, tailored for a specific application or service. This allows nodes to connect and use different services offered by other nodes, making communication efficient and supporting a variety of applications within the network. |
| TALKRESP Response | 6 | A message sent as a reply to a TALKREQ message, providing the requested information or a simple acknowledgment if the receiving node doesn't support or recognise the requested communication rules. |
| REGTOPIC Request | 7 | A message sent to express interest in a specific discussion topic, requesting a ticket if available. This allows nodes to join communication channels focused on particular subjects, connecting them with other nodes that share similar interests and fostering topic-based interactions within the network. |
| TICKET Response | 8 | A message sent in reply to a REGTOPIC request, providing either a ticket and wait-time for registration or immediate registration confirmation. This manages topic sign-ups efficiently by organizing interested nodes, allowing them to join topic-based communication channels efficiently and maintaining an orderly network structure. |
| REGCONFIRMATION Response | 9 | A message sent after a successful topic registration, informing the requester about their registration status and sharing relevant details about the topic channel. This ensures that the nodes are aware of their participation in the topic-based communication channel. |
| TOPICQUERY Request | 10 | A message sent to search for nodes registered to a specific communication topic, helping nodes find others with similar interests. |
Packets
One of the key aspects of secure communication between nodes in the Ethereum network is how messages are encrypted and structured. The Discv5 protocol does not send messages as plain text; instead, it uses a shared session key to encrypt them. This session key is established through a handshake mechanism that we will explain later.
Secure communication within the Ethereum network relies on the proper use of packets to handle messages. These small units of data contain the essential information for maintaining encrypted and authenticated communication. The Discv5 protocol, in particular, uses specific packet structures to ensure that communication between nodes stays both secure and reliable.
Each packet in the Discv5 protocol has two main parts: a header and an optional encrypted and authenticated message. The header component contains an Authdata section which can have a variable size, depending on the packet type. In essence, the header provides the necessary information for the receiving node to correctly process and handle the packet. There are three main packet types in the Discv5 protocol:
- Ordinary message packet: This packet type securely sends encrypted and authenticated messages between nodes. In ordinary message packets, the Authdata section contains the source node ID, which identifies the sender and ensures the communication remains intact.
- WHOAREYOU packet: If the recipient of an ordinary message packet encounters issues with decryption or authentication, they can send a WHOAREYOU packet. These packets ask the sender for additional information to confirm their identity so they successfully decrypt or authenticate the content in the packet. In WHOAREYOU packets, the Authdata section has an ID nonce (a random value) and the requesting node's
**Seq**number, both essential for identity verification. - Handshake message packet: After a WHOAREYOU packet is sent, handshake message packets are used to set up a new session between nodes and securely transmit both the handshake-related data and the original encrypted/authenticated message. In handshake message packets, the Authdata section includes a fixed-size authdata-head component, an ID signature, a temporary public key, and, if needed, an optional node record. Together, these components ensure a secure and authenticated connection between nodes.
Now that we've covered the various message and packet types, it's important to understand how nodes actually relay packets to each other.
UDP Communication
In our previous blog, we discussed that a protocol is a set of rules for sending and receiving data across a network. The Discv5 protocol uses the User Datagram Protocol (UDP) to send packets between nodes. UDP is a simple and efficient way to send data without needing a dedicated connection, making it great for tasks like online gaming or streaming that need quick response times.
For more background, we will briefly explain how the internet protocol works. The Internet Protocol (IP) is the basis of the Internet Protocol Suite and plays an important role in moving data across networks worldwide. It works by giving a unique IP address to each device so they can exchange data packets. UDP and another protocol called the Transmission Control Protocol (TCP) are built on top of IP, providing different features for data transmission. IP is widely used in many applications, from web browsing and email services to file transfers and streaming, making it a key part of the modern internet structure.
UDP is all about speed and simplicity, while TCP focuses on reliable and connection-oriented data transfers. With TCP, devices first create a dedicated connection before exchanging data, which ensures that data packets are delivered reliably. However, this extra reliability can lead to slower response times and increased processing overhead.
For Ethereum's node discovery process, where the goal is to quickly find and communicate with other nodes in the network, UDP is a better choice. Although it doesn't guarantee that data packets will always be delivered or that data transmission will be reliable, UDP's speed and simplicity make it more suitable for this purpose.
Below are key points about UDP communication in Discv5, which nodes rely on for efficient and reliable communication:
- Packet size limits: Discv5 has maximum and minimum packet size limits to ensure efficient and reliable communication. The protocol is designed to handle most messages within these size constraints, preventing excessive data transfers that could slow down the network or lead to packet loss.
- Short timeouts: Low-latency communication is essential for maintaining an efficient network. As a result, short timeouts are placed on request/response interactions to ensure quick and smooth communication between nodes. These timeouts help prevent nodes from waiting indefinitely for responses and allow them to adapt to changing network conditions.
- Response destination: When a node sends a response to a request, the response is sent back to the original requester's address, ensuring that the communication loop is properly closed. This practice helps maintain the integrity of the communication process and allows nodes to keep track of their interactions with other nodes in the network.
Bootstrapping Process
When a node starts for the first time, it is preloaded with a list of known records (ENRs). These records provide the node with an initial set of nodes to connect to within the Ethereum network, serving as a starting point for discovering additional peers. To begin the node discovery process, the node sends a PING message to these known nodes, checking their status and availability.
The PING message serves as a lightweight way to determine if a node is active and reachable, helping to establish an efficient network topology. It is important to note that the nodes in the preloaded list may not always be online or available, so the discovery process is essential for maintaining a reliable and up-to-date network.
Before nodes can communicate securely using the Discv5 protocol, they must establish a shared set of session keys. This is achieved through a process called a handshake, which involves an authenticated key agreement protocol based on elliptic curve cryptography. The handshake is a series of steps that nodes follow to confirm each other's identity and create the necessary cryptographic keys for secure communication. The handshake is essential in Discv5 because it prevents unauthorised access to the messages exchanged between nodes, protects sensitive information, and ensures the reliability of their communication.
In the following section, we will detail the specifics of the handshake mechanism, explaining each step and its importance in maintaining secure communication .
Handshake Mechanism
Before two nodes can communicate, they must establish a secure session for exchanging information. The handshake process ensures that both nodes can trust each other, communicate securely, and verify each other's identities. This process is particularly important in decentralized networks, where nodes need to establish trust without relying on a central authority.
Initiating the Handshake
Suppose Node A wants to communicate with Node B, for instance, to send a FINDNODE message. First, Node A checks if it already has the session keys from previous interactions. If it has the session keys, Node A encrypts its request with those keys. If not, Node A initiates the handshake by sending a message packet with random content. This message serves as a signal to Node B that a new secure communication session needs to be established.
In response, Node B sends a challenge in the form of a WHOAREYOU packet, which includes a unique ID nonce value and the sequence number of Node A's record, if available. The nonce value helps Node A to trace the challenge back to the initial request packet, while the sequence number allows Node A to determine if it needs to send an updated record to Node B.
Responding to the Challenge
Upon receiving the challenge, Node A confirms that Node B is active and ready to engage in the handshake. Node A then resends the initial request as a handshake message packet containing three parts: an ID signature, a temporary public key, and its node record, if necessary.
The ID signature is created to prove that Node A controls the private key associated with its node record. This signature prevents the replay of the handshake, ensuring that each handshake is unique and secure.
The temporary public key is generated by Node A as part of the Diffie-Hellman key agreement, a cryptographic method that allows two parties to establish a shared secret over an insecure channel. This temporary key will be used by both nodes to derive the shared session keys for secure communication.
Deriving Session Keys
Node A and Node B derive new session keys using a Diffie-Hellman key agreement and the HKDF key derivation function, a method to extract and expand cryptographic keys. This process involves Node A generating a temporary private key and its corresponding public key while Node B uses its static private key. The combination of these keys allows both nodes to create a shared secret that will be the basis for the session keys.
The session keys are divided into initiator and recipient keys, ensuring that each node has a unique key for encrypting and decrypting messages. This enhances the security of the communication by preventing unauthorised access to the exchanged information.
Completing the Handshake
Node B receives the handshake message packet and verifies the ID signature against Node A's public key. After successful verification, Node B attempts to decrypt and authenticate the message using the newly derived session keys. If the decryption and authentication are successful, Node B considers the new session keys valid and replies to the message, for example, with a NODES message.
Finally, Node A receives the response message and authenticates/decrypts it using the new session keys. If this process is successful, both nodes have verified each other's identity and can now communicate securely using the established session keys.
This handshake process is vital for maintaining secure communication sessions between nodes in decentralized networks. It allows nodes to verify each other's identities, establish trust, and ensure that information exchange is more secure and reliable, even in the absence of a central authority.
Continue Reading
In this blog, we covered key aspects of Discv5's node communication like messages, packets, and UDP for efficient, reliable data exchange. We also discussed the bootstrapping process for new nodes to join the network and the secure handshake mechanism ensuring network integrity and security.
In our final post, we will discuss how topics are structured, the role they play in enhancing the discovery process, and how nodes manage their subscriptions. Here's the link to part three.
As always, we'd love to hear your thoughts on this series or any questions you may have. Feel free to share your comments below or reach out to us on social media. If you're interested in contributing to our C# implementation of Discv5, visit the official GitHub repository for more information.
If you're looking for more resources on Ethereum or blockchain technology, you can refer to the list provided in our first blog post.
