RChain節點通信機制（上）
在介紹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節點代碼內部，沒有進一步的認證必要的機器。
RChain節點通信機制（上）