RChain節點通訊機制

在介紹RChain的通訊機制以前，先簡單介紹一些以太坊的通訊機制，RChain是借鑑的以太坊的通訊機制，它包括如下幾個方面，以下詳細瞭解以太坊的通訊機制，能夠查看https://github.com/ethereum/devp2p/blob/master/rlpx.md

一、Nodes

每一個節點用一組信息來表明它所知道的其餘節點，這些信息包括每一個節點的連接信息以及表結構（好比鏈接這個節點的平均延遲）。每一個節點是經過它的加密公鑰來識別的，Kademlia的距離度量用的是256位散列（sha3/Keccak-25）的公鑰。

二、Distance Metric

假設有N0和N1兩個節點，節點的keys用K0和K1來標識，N₀和N_{1的距離是}K_0和K_{1的公共前綴的長度，它能夠經過簡單的查找K0 ^ K1操做的第一個bit（^是一個bit的XOR操做）。由於key是隨機指定的，和地理無關，所以一箇中國的節點，最近的一個鄰居節點是古巴的。}

三、Node Table

對於一個特定的節點N，它的對等節點是保存在一個表T當中。下圖的表中有256行數據，每一條記錄是N在上述的XOR操做的度量距離。表的最大記錄數是由一個全局的參數副本數k來定義的。在節點的新增和剔除當中有一些靈活的策略來保證副本數。

在N的整個生命週期當中，這個表T是會被修改。例如咱們喜歡基於延遲的路由，咱們會在表裏面慢慢積累這種信息。表T還能夠存儲除了表路由以外的數據，好比說信譽數據。

四、Routing

Kademlia是爲尋找明確的節點開發的（或者是持有特定的數據的節點），可是在以太坊裏面不是這樣的。但這是一個RChain能夠無償使用的有效想法。它的基於通道的網絡須要那些被挑選出來的我的節點。

Kademlia協議的查詢部分能夠保證N有一個很是良好的大量節點的全局視圖，它能夠確保咱們能夠在log2 n的時間內把特定的節點找出來，n是key的比特長度。

爲了減小節點的跳數，表能夠劃分紅一堆長度爲b比特的chunk，因此每一行表明在B位第i組的差別（而不是在每一個單位連續的不一樣）。

RLPx協議指定b=8，可是Go, Java, and Rust的以太坊客戶能夠設置b=1。客戶單和服務端使用不一樣的b值是沒有問題的。 

五、Discovery Protocol

RLPx協議遵循了Kademlia協議密切發現和維護已知節點列表的特色，可是Kademlia並不包括安全通訊。RLPx在這點上作了加強，它在第一次鏈接的時候增長了一個二階段握手協議。經過公鑰來交換，而且全部的通訊都是加密的。 

六、Bootstrapping

在大多數的P2P系統當中，至少要有一個節點H是已知的，咱們的節點N先和節點H握手（嘗試把本身添加到H的表T中），若是N像H查詢本身的公鑰，H將會給N返回離它最近的節點。而後N就能夠查詢那些新添加的節點的表去發現新的節點，來獲取整個網絡的全貌。

七、Maintaining Peers

對等列表T每一次收到遠程節點的消息的時候都有可能更新，這能夠經過週期性的PING/PONG來強制觸發。一般，維護對等列表的策略利用了文件共享統計數據的觀察結果，那些暫時保持活動的節點將保持更長的活動時間，所以保留響應的節點一般比替換它們要好。

RLPx並不試圖規定節點應該做爲直接鏈接節點維護區塊鏈的工做。這些一般是較少的，他們是根據測得的延遲或其餘特性選出來的。

八、總結

使用RLPx協議的Ethereumj（以太坊java客戶端），是一個網絡創建的最直接的途徑。RLP編碼方案能夠用Protocol Buffer代替，網絡維護協議的其他部分會變得更簡單。拿過來，而後進行二次開發。Kademlia的子集、RLPx、握手協議，提供全部須要的rchain網絡機制。若是直接通訊節點是從發現的節點列表中選擇，在P2P層均可以屏蔽從rchain節點代碼內部，沒有進一步的認證必要的機器。 

 

 

岑玉海

轉載請註明出處，謝謝！