在介绍 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 节点代码内部, 没有进一步的认证必要的机器.
来源: https://www.cnblogs.com/cenyuhai/p/8409478.html