You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/wiki/EL/devp2p.md
+43-23
Original file line number
Diff line number
Diff line change
@@ -46,10 +46,10 @@ The reason behind this is that the information exchange requires a reliable conn
46
46
so they can be able to both confirm the connection before sending the data and have a way to ensure that the data is delivered in the correct order and without errors (or at least to have a way to detect and correct them),
47
47
while the discovery process does not require the reliable connection, since it is enough to let other knows that the node is available to communicate.
48
48
49
-
### Discovery
49
+
### Discv protocol (Discovery)
50
50
The process of how the nodes find each other in the network starts with [the hard-coded bootnodes listed in the specification](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go).
51
51
The bootnodes are nodes that are known by all the other nodes in the networks (both Mainnet and testnets), and they are used to bootstrap the discovery peers process.
52
-
Using the Kademlia DHT (Distributed Hash Table) algorithm, the nodes are able to find each other in the network by referring to a routing table where the bootnodes are listed.
52
+
Using the Kademlia-like DHT (Distributed Hash Table) algorithm, the nodes are able to find each other in the network by referring to a routing table where the bootnodes are listed.
53
53
The TLDR of the Kademlia is that it is a peer-to-peer protocol that enables nodes to find each other in the network by using a distributed hash table, as Leffew mentioned in his article (2019).
54
54
55
55
That is to say, the connection process starts with a PING-PONG game where the new node send a PING message to the bootnode, and the bootnode responds with a PONG hashed message.
@@ -58,6 +58,7 @@ so it can repeat the PING-PONG game with them and bond with them as well.
The PING/PONG game is better known as the wire subprotocol, and it includes the next specifications:
62
63
63
64
**PING packet structure**
@@ -107,37 +108,56 @@ Where ENR is the Ethereum Node Record, a standard format for connectivity for no
107
108
108
109
---
109
110
Currently, the execution clients are using the [Discv4 protocol](https://github.com/ethereum/devp2p/blob/master/discv4.md) for the discovery process, although it is planned to be migrated to [Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) in the future.
110
-
This Kademlia-like discovery protocol includes the routing table, which keeps information about other nodes in the neighbourhood consisting of *k-buckets* (where *k* is the number of nodes in the bucket, currently defined as 16).
111
+
This Kademlia-like protocol includes the routing table, which keeps information about other nodes in the neighbourhood consisting of *k-buckets* (where *k* is the number of nodes in the bucket, currently defined as 16).
111
112
Worth mentioning that all the table entries are sorted by *last seen/least-recently seen* at the head, and most-recently seen at the tail.
112
113
If one of the entities has not been responded to in 12 hours, it is removed from the table, and the next encounter node is added to the tail of the list.
113
114
115
+
### ENR: Ethereum Node Records
116
+
The ENR os a standard format for p2p connectivity, which was originally proposed in the [EIP-778](https://eips.ethereum.org/EIPS/eip-778).
117
+
A node record contains the node's network endpoints, such as the IP address and port, as well as the node's public key and the sequence number of the record.
114
118
119
+
The record content structure is as follows:
115
120
116
-
### ENR: Ethereum Node Records
117
-
* Standard format for connectivity for nodes
118
-
* Node's identity
119
-
* Object
120
-
* signature (hash)
121
-
* sequence number
122
-
* arbitrary key-value pairs
123
-
124
-
## DevP2P specs
125
-
* RLPx: encrypted and authenticated transport protocol (TCP based transport system for nodes communication)
| tcp6 | IPv6-specific TCP port, big endian integer |
130
+
| udp6 | IPv6-specific UDP port, big endian integer |
131
+
132
+
All the fields are optional, except for the `id` field, which is required. If no `tcp6`/`udp6` port are provided, the `tcp`/`udp` ports are used for both IPv4 and IPv6.
133
+
134
+
The node record is composed of a `signature`, which is the cryptographic signature of record contents, and a `seq` field, which is the sequence number of the record (a 64-bit unsigned integer).
135
+
#### Encoding
136
+
137
+
The record is encoded as an RLP list of `[signature, seq, k, v,...]` with a maximum size of 300 bytes.
138
+
Signed records are encoded as follows:
139
+
```
140
+
content = [seq, k, v, ...]
141
+
signature = sign(content)
142
+
record = [signature, seq, k, v, ...]
143
+
```
144
+
In addition to the RLP encoding, there is a textual representation of the record, which is a base64 encoding of the RLP encoding. It is prefixed with `enr:`.
145
+
i.e. `enr:-IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2_oxVtw0RW_QAdpzBQA8yWM0xOIN1ZHCCdl8` which contains the loopback address `127.0.0.1` and the UDP port 30303. The node ID is `a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7`.
146
+
147
+
Despite of the fact that the ENR is a standard format for p2p connectivity, it is not mandatory to use it in the Ethereum network. The nodes can use any other format to exchange the information about their connectivity.
148
+
There are two additional formats able to be understand by an Ethereum node: multiaddr and enode.
149
+
150
+
* The multiaddr was the original one. For example, the multiaddr for a node with a loopback IP listening on TCP port 30303 and node ID `a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7` is `/ip4/127.0.0.1/tcp/30303/a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7`.
151
+
* The enode is a more human-readable format. For example, the enode for the same node is `enode://a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7@127.0.0.1:30303?discport=30301`. It is a URL-like format describing the node ID encoded before de @ sign, the IP address, the TCP port and the UDP port specified as "discport".
0 commit comments