标签：error purpose gic spec unix send other ESS remove
本文章分上下两篇
devp2p是一种应用层网络协议，是在对等网络中节点与节点之间进行通信的重要协议。节点可以支持任意数量的增加，devp2p能处理双方支持的协商过的协议，并通过单个链接传递消息。
节点用过使用RLPx发送消息进行通信。节点可以在他们希望的任何TPC端口上自由地通告和接受连接，可以在其上侦听和简历连接的默认端口为30303.虽然TCP提供面向连接的介质，devp2p节点在数据包方面进行通信。RLPx提供发送和接受数据包的工具。
devp2p节点通过发现协议DHT找到对等体； (下篇便是围绕DHT协议编写应用程序)
使用RLP序列化格式对消息进行编码，可以在消息内编码许多不同类型的有效载荷。该“类型”总是由分组RLP的第一条目确定，被解释为整数。
devp2p通过基本有线协议支持任意子协议。每个协议都根据需要提供尽可能多的消息ID空间。所有这些协议必须今天地指定它们需要多少消息ID。在链接和接受Hello消息时，两个对等体都具有关于它们共享子协议（包括版本）的等效信息，并且能够对消息ID空间的组成形成共识。
假设消息ID从ID 0x10开始是紧凑的（0x00-0x10保留用于devp2p消息）并按字母顺序给予每个共享（等版本，相等名称）子协议。忽略未共享的子协议。如果多个版本由相同（等名）子协议共享，则数字上最高的胜利，其他则被忽略。
Hello 0x00 [p2pVersion: P, clientId: B, [[cap1: B_3, capVersion1: P], [cap2: B_3, capVersion2: P], ...], listenPort: P, nodeId: B_64] First packet sent over the connection, and sent once by both sides. No other messages may be sent until a Hello is received.
Disconnect 0x01 [reason: P] Inform the peer that a disconnection is imminent; if received, a peer should disconnect immediately. When sending, well-behaved hosts give their peers a fighting chance (read: wait 2 seconds) to disconnect to before disconnecting themselves.
Pong 0x03 [] Reply to peer‘s Ping packet.
This specification defines the Node Discovery protocol version 4, a Kademlia-like DHT that stores information about Ethereum nodes. The Kademlia structure was chosen because it yields a topology of low diameter.
Every node has a cryptographic identity, a key on the elliptic curve secp256k1. The public key of the node serves as its identifier or ‘node ID‘.
The ‘distance‘ between two node IDs is the bitwise exclusive or on the hashes of the public keys, taken as the number.
distance(n?, n?) = keccak256(n?) XOR keccak256(n?)
Nodes in the Discovery Protocol keep information about other nodes in their neighborhood. Neighbor nodes are stored in a routing table consisting of ‘k-buckets‘. For each 0 ≤ i < 256, every node keeps a k-bucket for nodes of distance between 2i and 2i+1 from itself.
The Node Discovery Protocol uses k = 16, i.e. every k-bucket contains up to 16 node entries. The entries are sorted by time last seen — least-recently seen node at the head, most-recently seen at the tail.
Whenever a new node N? is encountered, it can be inserted into the corresponding bucket. If the bucket contains less than k entries N? can simply be added as the first entry. If the bucket already contains k entries, the least recently seen node in the bucket, N?, needs to be revalidated by sending a ping packet. If no reply is received from N? it is considered dead, removed and N? added to the front of the bucket.
To prevent traffic amplification attacks, implementations must verify that the sender of a query participates in the discovery protocol. The sender of a packet is considered verified if it has sent a valid pong response with matching ping hash within the last 12 hours.
A ‘lookup‘ locates the k closest nodes to a node ID.
The lookup initiator starts by picking α closest nodes to the target it knows of. The initiator then sends concurrent FindNode packets to those nodes. α is a system-wide concurrency parameter, such as 3. In the recursive step, the initiator resends FindNode to nodes it has learned about from previous queries. Of the k nodes the initiator has heard of closest to the target, it picks α that it has not yet queried and resends FindNode to them. Nodes that fail to respond quickly are removed from consideration until and unless they do respond.
If a round of FindNode queries fails to return a node any closer than the closest already seen, the initiator resends the find node to all of the k closest nodes it has not already queried. The lookup terminates when the initiator has queried and gotten responses from the k closest nodes it has seen.
Node discovery messages are sent as UDP datagrams. The maximum size of any packet is 1280 bytes. packet = packet-header || packet-data Every packet starts with a header:
packet-header = hash || signature || packet-type
hash = keccak256(signature || packet-type || packet-data)
signature = sign(packet-type || packet-data)
The hash exists to make the packet format recognizable when running multiple protocols on the same UDP port. It serves no other purpose.
Every packet is signed by the node‘s identity key. The signature is encoded as a byte array of length 65 as the concatenation of the signature values r, s and the ‘recovery id‘ v.
The packet-type is a single byte defining the type of message. Valid packet types are listed below. Data after the header is specific to the packet type and is encoded as an RLP list. As per EIP-8, implementations should ignore any additional elements in the list as well as any extra data after the list.
packet-data = [version, from, to, expiration] version = 4 from = [sender-ip, sender-udp-port, sender-tcp-port] to = [recipient-ip, recipient-udp-port, 0] The expiration field is an absolute UNIX time stamp. Packets containing a time stamp that lies in the past are expired may not be processed.
When a ping packet is received, the recipient should reply with a pong packet. It may also consider the sender for addition into the node table.
If no communication with the sender has occurred within the last 12h, a ping should be sent in addition to pong in order to receive an endpoint proof.
packet-data = [to, ping-hash, expiration] Pong is the reply to ping.
ping-hash should be equal to hash of the corresponding ping packet. Implementations should ignore unsolicited pong packets that do not contain the hash of the most recent ping packet.
packet-data = [target, expiration] A FindNode packet requests information about nodes close to target. The target is a 65-byte secp256k1 public key. When FindNode is received, the recipient should reply with neighbors packets containing the closest 16 nodes to target found in its local table.
To guard against traffic amplification attacks, Neighbors replies should only be sent if the sender of FindNode has been verified by the endpoint proof procedure.
packet-data = [nodes, expiration] nodes = [[ip, udp-port, tcp-port, node-id], ... ] Neighbors is the reply to FindNode.
The Ethereum devp2p and discv4 protocol Part I
标签：error purpose gic spec unix send other ESS remove
原文地址：https://www.cnblogs.com/chenshouchang/p/10321266.html
