在介绍RChain的通信机制之前，先简单介绍一些以太坊的通信机制，它包括以下几个方面，如下详细了解以太坊的通信机制，可以查看https://github.com/ethereum/devp2p/blob/master/rlpx.md
1、Nodes
每个节点用一组信息来代表它所知道的其他节点，这些信息包括每个节点的连接信息以及表结构（比如连接这个节点的平均延迟）。每个节点是通过它的加密公钥来识别的，Kademlia的距离度量用的是256位散列（sha3/Keccak-25）的公钥。
2、Distance Metric
假设有N0和N1两个节点，节点的keys用K0和K1来标识，N0和N1的距离是K0和K1的公共前缀的长度，它可以通过简单的查找K0 ^ K1操作的第一个bit（^是一个bit的XOR操作）。因为key是随机指定的，和地理无关，因此一个中国的节点，最近的一个邻居节点是古巴的。
3、Node Table
对于一个特定的节点N，它的对等节点是保存在一个表T当中。下图的表中有256行数据，每一条记录是N在上述的XOR操作的度量距离。表的最大记录数是由一个全局的参数副本数k来定义的。在节点的新增和剔除当中有一些灵活的策略来保证副本数。
在N的整个生命周期当中，这个表T是会被修改。例如我们喜欢基于延迟的路由，我们会在表里面慢慢积累这种信息。表T还可以存储除了表路由之外的数据，比如说信誉数据。
4、Routing
Kademlia是为寻找明确的节点开发的（或者是持有特定的数据的节点），但是在以太坊里面不是这样的。但这是一个RChain可以免费使用的有效想法。它的基于通道的网络需要那些被挑选出来的个人节点。
Kademlia协议的查询部分可以保证N有一个非常良好的大量节点的全局视图，它可以确保我们可以在log2 n的时间内把特定的节点找出来，n是key的比特长度。
为了减少节点的跳数，表可以划分成一堆长度为b比特的chunk，所以每一行代表在B位第i组的差异（而不是在每个单位连续的不同）。
RLPx协议指定b=8，但是Go, Java, and Rust的以太坊客户可以设置b=1。客户单和服务端使用不同的b值是没有问题的。
5、Discovery Protocol
RLPx协议遵循了Kademlia协议密切发现和维护已知节点列表的特点，但是Kademlia并不包括安全通信。RLPx在这点上做了增强，它在第一次连接的时候增加了一个二阶段握手协议。通过公钥来交换，并且所有的通信都是加密的。
6、Bootstrapping
在大多数的P2P系统当中，至少要有一个节点H是已知的，我们的节点N先和节点H握手（尝试把自己添加到H的表T中），如果N像H查询自己的公钥，H将会给N返回离它最近的节点。然后N就可以查询那些新添加的节点的表去发现新的节点，来获取整个网络的全貌。
7、Maintaining Peers
对等列表T每一次收到远程节点的消息的时候都有可能更新，这可以通过周期性的PING/PONG来强制触发。通常，维护对等列表的策略利用了文件共享统计数据的观察结果，那些暂时保持活动的节点将保持更长的活动时间，因此保留响应的节点通常比替换它们要好。
RLPx并不试图规定节点应该作为直接连接节点维护区块链的工作。这些通常是较少的，他们是根据测得的延迟或其他特性选出来的。
8、总结
使用RLPx协议的Ethereumj（以太坊java客户端），是一个网络建立的最直接的途径。RLP编码方案可以用proto buffer代替，网络维护协议的其余部分会变得更简单。拿过来，然后进行二次开发。Kademlia的子集、RLPx、握手协议，提供所有需要的rchain网络机制。如果直接通信节点是从发现的节点列表中选择，在P2P层都可以屏蔽从rchain节点代码内部，没有进一步的认证必要的机器。
