Ethereum has defined a comprehensive-looking protocol for node discovery and routing. It is described in the RLPx specification, and it is in some sense presented as an extension of RLP, Ethereum's serialization format. For node discovery and for routing, RLPx uses a subset of the Kademlia protocol (see Maymounkov & Mazières, described in Wikipedia), a distributed hash table developed for peer-to-peer file sharing networks. In particular, Ethereum's discovery protocol omits the STORE and FIND_VALUE RPCs, and simply uses the rest of the DHT to accumulate information about peers.
| Table of Contents |
|---|
Nodes
Each node represents the other nodes it knows about by some chunk of useful information. This can include data used for connecting to the node as well as any metric information not otherwise represented by the table structure (such as average latency to that node). A node is identified by its cryptographic public key, and for reasons1 the 256-bit hash (sha3/Keccak-256) of the public key is used for the Kademlia distance metric.
...
RLPx does not attempt to prescribe which nodes should be used as directly connect peers for the work of maintaining the blockchain. Those are typically fewer and chosen based on measured latency or other characteristics.
Summary
Using the RLPx system in EthereumJ, the Java Ethereum client, is likely the most straightforward way to get a network built. The RLP encoding scheme could be removed in favor of Protocol Buffers with some effort, but the rest of the network maintenance protocol would be more easily . . . borrowed . . . than developed. The Kademlia subset, along with of RLPx, along with the handshake protocol, provide all the required mechanisms of an RChain network. If peers for direct communication are chosen from the discovery peer list, the entirety of the peer-to-peer layer could be hidden from the RChain node code proper, with no further authentication machinery necessary.
...