以太坊添加新節點

A. Quorum介紹

Quorum和以太坊的主要區別:

Quorum 的主要組件：

1,用其自己實現的基於投票機制的共識方式 來代替原來的 「Proof of work」 。
2,在原來無限制的P2P傳輸方式上增加了許可權功能。使得P2P傳輸只能在互相允許的節點間傳輸。
3, 修改區塊校驗邏輯使其能支持 private transaction。
4, Transaction 生成時支持 transaction 內容的替換。這個調整是為了能支持聯盟中的私有交易。

Constellation 模塊的主要職責是支持 private transaction。Constellation 由兩部分組成：Transaction Manager 和 Enclave。Transaction Manager 用來管理和傳遞私有消息，Enclave 用來對私有消息的加解密。

在私有交易中，Transaction Manager 會存儲私有交易的內容，並且會將這條私有交易內容與其他相關的 Transaction Manager 進行交互。同時它也會利用 Enclave 來加密或解密其收到的私有交易。

為了能更有效率的處理消息的加密與解密，Quorum 將這個功能單獨拉出並命名為 Enclave 模塊。Enclave 和 Transaction Manager 是一對一的關系。

在 Quorum 中有兩種交易類型，」Public Transaction」 和 「Privat Transaction」。在實際的交易中，這兩種類型都採用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基礎上添加了一個新的 「privateFor」 欄位。同時，針對一個 tx 類型的對象添加了一個新的方法 「IsPrivate」。用 「IsPrivate」 方法來判斷 Transaction是 public 還是 private，用 「privateFor」 來記錄 事務只有誰能查看。

Public Transaction 的機理和以太坊一致。Transaction中的交易內容能被鏈上的所有人訪問到。

Private Transaction 雖然被叫做 「Private」，但是在全網上也會出現與其相關的交易。只不過交易的明細只有與此交易有關系的成員才能訪問到。在全網上看到的交易內容是一段hash值，當你是交易的相關人員時，你就能利用這個hash值，然後通過 Transaction Manager 和 Enclave 來獲得這筆交易的正確內容。

Public Transaction的處理流程和以太坊的Transaction流程一致。Transaction 廣播全網後，被礦工打包到區塊中。節點收到區塊並校驗區塊中的 事務 信息。然後根據 Transaction信息更新本地的區塊

Private Transaction也會將 Transaction 廣播至全網。但是它的 Transaction payload已經從原來的真實內容替換為一個hash值。這個hash值是由Transaction Manager提供的。

有兩個共識機制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都採用了 QuorumChain。
從 2.0 版本開始，Quorum 廢棄了 QuorumChain 轉而只支持 Raft-based Consensus。

QuorumChain Consensus 是一個基於投票的共識演算法。其主要特點有：

相比較以太坊的POW，Raft-based 提供了更快更高效的區塊生成方式。相比 QuorumChain，Raft-based 不會產生空的區塊，而且在區塊的生成上比前者更有效率。

要想了解Raft-based Consensus，必須先了解Raft演算法

Raft演算法
Raft是一種一致性演算法，是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。這就意味著只要超過半數的大多數伺服器達成一致就可以了，假設有N台伺服器，N/2 +1 就超過半數，代表大多數了。
Raft的工作模式：
raft的工作模式是一個Leader和多個Follower模式，即我們通常說的領導者-追隨者模式。除了這兩種身份，還有Candidate身份。下面是身份的轉化示意圖

1，leader的選舉過程
raft初始狀態時所有server都處於Follower狀態，並且隨機睡眠一段時間，這個時間在0~1000ms之間。最先醒來的server A進入Candidate狀態，Candidate狀態的server A有權利發起投票，向其它所有server發出投票請求，請求其它server給它投票成為Leader。
2，Leader產生數據並同步給Follower
Leader產生數據，並向其它Follower節點發送數據添加請求。其它Follower收到數據添加請求後，判斷該append請求滿足接收條件（接收條件在後面安全保證問題3給出），如果滿足條件就將其添加到本地，並給Leader發送添加成功的response。Leader在收到大多數Follower添加成功的response後。提交後的log日誌就意味著已經被raft系統接受，並能應用到狀態機中了。

Leader具有絕對的數據產生權利，其它Follower上存在數據不全或者與Leader數據不一致的情況時，一切都以Leader上的數據為主，最終所有server上的日誌都會復製成與Leader一致的狀態。

Raft的動態演示： http://thesecretlivesofdata.com/raft/

安全性保證，對於異常情況下Raft如何處理：

1，Leader選舉過程中，如果有兩個FollowerA和B同時醒來並發出投票請求怎麼辦？
在一次選舉過程中，一個Follower只能投一票，這就保證了FollowerA和B不可能同時得到大多數（一半以上）的投票。如果A或者B中其一幸運地得到了大多數投票，就能順利地成為Leader，Raft系統正常運行下去。但是A和B可能剛好都得到一半的投票，兩者都成為不了Leader。這時A和B繼續保持Candidate狀態，並且隨機睡眠一段時間，等待進入到下一個選舉周期。由於所有Follower都是隨機選擇睡眠時間，所以連續出現多個server競選的概率很低。
2，Leader掛了後，如何選舉出新的Leader？
Leader在正常運行時候，會周期性的向Follower節點發送數據的同步請求，同時也是起到一個心跳作用。Follower節點如果在一段時間之內（一般是2000ms左右）沒有收到數據同步請求，則認為Leader已經死了，於是進入到Candidate狀態，開始發起投票競選新的Leader，每個新的Leader產生後就是一個新的任期，每個任期都對應一個唯一的任期號term。這個term是單調遞增的，用來唯一標識一個Leader的任期。投票開始時，Candidate將自己的term加1，並在投票請求中帶上term；Follower只會接受任期號term比自己大的request_vote請求，並為之投票。 這條規則保證了只有最新的Candidate才有可能成為Leader。

3，Follower的數據的生效時間
Follower在收到一條添加數據請求後，是否立即保存並將其應用到狀態機中去？如果不是立即應用，那麼由什麼來決定該條日誌生效的時間？
首先會檢查這條數據同步請求的來源信息是否與本地保存的leader信息符合，包括leaderId和任期號term。檢查合法後就將日誌保存到本地中，並給Leader回復添加log成功，但是不會立即將其應用到本地狀態機。Leader收到大部分Follower添加log成功的回復後，就正式將這條日誌commit提交。Leader在隨後發出的心跳append_entires中會帶上已經提交日誌索引。Follower收到Leader發出的心跳append_entries後，就可以確認剛才的log已經被commit(提交)了，這個時候Follower才會把日誌應用到本地狀態機。下表即是append_entries請求的內容，其中leaderCommit即是Leader已經確認提交的最大日誌索引。Follower在收到Leader發出的append_entries後即可以通過leaderCommit欄位決定哪些日誌可以應用到狀態機。

4，向raft系統中添加新機器時，由於配置信息不可能在各個系統上同時達到同步狀態，總會有某些server先得到新機器的信息，有些server後得到新機器的信息。比如在raft系統中有三個server，在某個時間段中新增加了server4和server5這兩台機器。只有server3率先感知到了這兩台機器的添加。這個時候如果進行選舉，就有可能出現兩個Leader選舉成功。因為server3認為有3台server給它投了票，它就是Leader，而server1認為只要有2台server給它投票就是Leader了。raft怎麼解決這個問題呢？

產生這個問題的根本原因是，raft系統中有一部分機器使用了舊的配置，如server1和server2，有一部分使用新的配置，如server3。解決這個問題的方法是添加一個中間配置(Cold, Cnew)，這個中間配置的內容是舊的配置表Cold和新的配置Cnew。這個時候server3收到添加機器的消息後，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)來做決策。比如說server3在競選Leader的時候，不僅需要得到Cold中的大部分投票，還要得到Cnew中的大部分投票才能成為Leader。這樣就保證了server1和server2在使用Cold配置的情況下，還是只可能產生一個Leader。當所有server都獲得了添加機器的消息後，再統一切換到Cnew。raft實現中，將Cold，(Cold,Cnew)以及Cnew都當成一條普通的日誌。配置更改信息發送Leader後，由Leader先添加一條 (Cold, Cnew)日誌，並同步給其它Follower。當這條日誌(Cold, Cnew)提交後，再添加一條Cnew日誌同步給其它Follower，通過Cnew日誌將所有Follower的配置切換到最新。

Raft演算法和以太坊結合
所以為了連接以太坊節點和 Raft 共識，Quorum 採用了網路節點和 Raft 節點一對一的方式來實現 Raft-based 共識

一個Transaction完整流程
1，客戶端發起一筆 Transaction並通過 RPC 來呼叫節點。
2，節點通過以太坊的 P2P 協議將節點廣播給網路。
3，當前的 Raft leader 對應的以太坊節點收到了 Transaction後將它打包成區塊。
區塊被 編碼後傳遞給對應的 Raft leader。
leader 收到區塊後通過 Raft 演算法將區塊傳遞給 follower。這包括如下步驟：
3.1，leader 發送 AppendEntries 指令給 follower。
3.2，follower 收到這個包含區塊信息的指令後，返回確認回執給 leader。
3.3，leader 收到不少於指定數量的確認回執後，發送確認 append 的指令給 follower。
3.4，follower 收到確認 append 的指令後將區塊信息記錄到本地的 Raft log 上。
3.5，Raft 節點將區塊傳遞給對應的 Quorum 節點。Quorum 節點校驗區塊的合法性，如果合法則記錄到本地鏈上。

參考鏈接： http://blog.csdn.net/about_blockchain/article/details/78684901

B. 以太坊多節點私有鏈部署

假設兩台電腦A和B
要求：
1、兩台電腦要在一個網路中，能ping通
2、兩個節點使用相同的創世區塊文件
3、禁用ipc;同時使用參數--nodiscover
4、networkid要相同，埠號可以不同

1.4 搭建私有鏈
1.4.1 創建目錄和genesis.json文件
創建私有鏈根目錄./testnet
創建數據存儲目錄./testnet/data0
創建創世區塊配置文件./testnet/genesis.json

1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json

1.4.3 啟動私有節點

1.4.4 創建賬號
personal.newAccount()
1.4.5 查看賬號
eth.accounts
1.4.6 查看賬號余額
eth.getBalance(eth.accounts[0])
1.4.7 啟動&停止挖礦
啟動挖礦：
miner.start(1)
其中 start 的參數表示挖礦使用的線程數。第一次啟動挖礦會先生成挖礦所需的 DAG 文件，這個過程有點慢，等進度達到 100% 後，就會開始挖礦，此時屏幕會被挖礦信息刷屏。
停止挖礦，在 console 中輸入：
miner.stop()
挖到一個區塊會獎勵5個以太幣，挖礦所得的獎勵會進入礦工的賬戶，這個賬戶叫做 coinbase，默認情況下 coinbase 是本地賬戶中的第一個賬戶，可以通過 miner.setEtherbase() 將其他賬戶設置成 coinbase。

1.4.8 轉賬
目前，賬戶 0 已經挖到了 3 個塊的獎勵，賬戶 1 的余額還是0：

我們要從賬戶 0 向賬戶 1 轉賬，所以要先解鎖賬戶 0，才能發起交易：

發送交易，賬戶 0 -> 賬戶 1：

需要輸入密碼 123456

此時如果沒有挖礦，用 txpool.status 命令可以看到本地交易池中有一個待確認的交易，可以使用 eth.getBlock("pending", true).transactions 查看當前待確認交易。

使用 miner.start() 命令開始挖礦：
miner.start(1);admin.sleepBlocks(1);miner.stop();

新區塊挖出後，挖礦結束，查看賬戶 1 的余額，已經收到了賬戶 0 的以太幣：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')

用同樣的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json

啟動私有節點一,修改 rpcport 和port

可以通過 admin.addPeer() 方法連接到其他節點，兩個節點要要指定相同的 chainID。

假設有兩個節點：節點一和節點二，chainID 都是 1024，通過下面的步驟就可以從節點二連接到節點一。

首先要知道節點一的 enode 信息，在節點一的 JavaScript console 中執行下面的命令查看 enode 信息：

admin.nodeInfo.enode
" enode://@[::]:30303 "

然後在節點二的 JavaScript console 中執行 admin.addPeer()，就可以連接到節點一：

addPeer() 的參數就是節點一的 enode 信息，注意要把 enode 中的 [::] 替換成節點一的 IP 地址。連接成功後，節點一就會開始同步節點二的區塊，同步完成後，任意一個節點開始挖礦，另一個節點會自動同步區塊，向任意一個節點發送交易，另一個節點也會收到該筆交易。

通過 admin.peers 可以查看連接到的其他節點信息，通過 net.peerCount 可以查看已連接到的節點數量。

除了上面的方法，也可以在啟動節點的時候指定 --bootnodes 選項連接到其他節點。 bootnode 是一個輕量級的引導節點，方便聯盟鏈的搭建 下一節講 通過 bootnode 自動找到節點

參考： https://cloud.tencent.com/developer/article/1332424

C. geth以太坊客戶端輕節點模式啟動怎麼與全節點啟動的geth連接

一般來說，Undefined index就是自己編寫過程中出現了的的確確的寫法問題notice一般提示關於與執行代碼沒有直接關系的錯誤，但不要忘記，notice有時會返回一些多餘的錯誤信息

D. 可以用雲伺服器搭建以太坊私有鏈節點嗎

可以的，但是建議使用海外伺服器會比較好，另外伺服器的配置要中等或以上。

E. 什麼是區塊鏈擴容

擴容，是當某個容器或承載物不足以支撐或承載現有事物需求時，我們通過擴大容器的容量或承載物的體積來滿足日益增長的需求，從而緩解當前容器或承載物所受壓力的一種手段。
在比特幣誕生之初比特幣創始人中本聰並沒有特意限制區塊的大小，區塊最大可以達到32MB，當時平均每個區塊大小為1~2KB。
時比特幣用戶少，交易量也沒有那麼大，並不會造成區塊擁堵，然而2013年至今隨著比特幣價格的直線上升，用戶越來越多因此造成比特幣網路擁堵，用戶交易費用上升的問題逐漸涌現出來。
到現在，比特幣區塊鏈上最高時有幾十萬筆交易積壓，比特幣的平均交易費用比 2010 年 9 月上漲了 376 倍，每秒 7 筆交易的處理速度已經明顯無法滿足用戶需求，比特幣社區開始探索如何給比特幣「擴容」。
通過修改比特幣底層代碼，從而達到提高交易處理能力的目的。
比特幣擴容本身發展和設計方案有兩種，即第一層和第二層擴容技術。
· 第一層擴容技術即改進區塊鏈自身，把區塊鏈自身變得更快、容量變得更大，總的來說就是改變區塊鏈共識部分的內容。
· 第二層擴容技術目的是把計算移到鏈下，即通過側鏈的技術加以解決問題。
擴容協議及結局
擴容協議一般需要礦工們的支持，大致可以分為修改區塊大小、軟分叉、硬分叉、隔離見證等方式。
以比特幣舉例：
比特幣現在分裂成為大區塊Bitcoin Cash(BCH)和隔離見證。隔離見證現在是市場上公認的比特幣，而大區塊幣被冠名為比特現金。可以預見的往後的發展方向，比特幣將會以鏈下交易為主。包括閃電網路、側鏈。這兩個新東西目前不成熟，但是被很多人寄予厚望的。
比特幣將會大量發展隔離見證交易，並在隔離見證的基礎上做更多的衍生技術。最有可能是以技術推動比特幣往前發展。
比特現金將會以鏈上交易為主，重點發展貨幣功能，以降低交易摩擦為主要方式，以獲利更廣泛的鏈上用戶量為主要發展方向。
鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。

F. 2022以太坊節點數量

2022以太坊節點數量達到了2000多點，數量非常的穩定龐大，能夠體現出目前以太幣的強勢和利好，非常適合投資。

G. 以太坊硬分叉是什麼

硬分叉是一種不支持向後兼容的軟體升級方式。通常，這些情況發生在節點以與舊節點的規則沖突的方式添加新規則時。新節點只能與運行新版本的軟體節點進行交互。結果，區塊鏈發生了分裂，生產出兩個單獨的網路：一個按照舊規則運行，一個則按照新規則運行。節點在升級後變為藍色。之前的黃色節點拒絕藍色節點的連入，而藍色的節點之間可以相互連接。因此，現在有兩個網路並行運行。他們將繼續產生區塊和交易，但不再在同一區塊鏈上工作。在區塊鏈網路達到分叉區塊之前，所有節點都具有相同的區塊鏈（並且歷史記錄仍然存在），但是這之後它們將具有不同的區塊和交易。由於存在相同的歷史記錄，因此如果您在分叉之前持有代幣，那麼您將在這兩個網路上同時獲得代幣。假設在600,000區塊高度發生分叉時，您手裡有5 BTC。您可以選擇在區塊高度到達600,001時，在原始區塊鏈上將這5個代幣花費掉，但是在新產生的區塊鏈上並不會記錄這筆在600,001區塊高度的消費。假設加密方式沒有發生變化，那麼在新的分叉網路上您的私鑰中仍然會存在這5個代幣。 以太坊硬分叉的一個案例是2016 年 6 月 17 日，the DAO 合約上出現漏洞並被攻擊者乘虛而入，導致約三百六十萬 ETH 被盜取。根據該合約的設計，這些資金需要被凍結 28 天才能成功被轉移。如果沒有採取任何措施的話，黑客會擁有 ETH 總額的 4.4%。為解決這個問題，備受爭議的 EIP 779 被提出來，其目的在於修改攻擊者的鎖定合約。如此一來，ETH 持有者便可以從 the DAO 合約上提出其 ETH。7 月 20 日，以太坊大部分成員支持實行硬分叉，然而少數社區成員持反對意見，並決定實行硬分叉，分叉後的原鏈改名為以太坊經典 (Ethereum Classic)。

H. Docker 搭建以太坊私有鏈

首先需要安裝 Docker，Docker 的安裝和使用可以參看阮一峰老師的 《Docker 入門教程》 。
Ethereum 官方是支持 docker 的，可以參看 官方文檔 。

centOS

其中 -v /home/linshan/works/block-chain/ethereum:/root 是把我們當前的 ethereum 目錄，掛到了docker 的 /root 下。
在 Windows 環境下使用 -v /home/linshan/works/block-chain/ethereum:/root 不能啟動容器，原因不明，所以在 Windows 下先不要使用目錄掛載。

各欄位具體用途參看 官方文檔 。
Windows
Windows 不必創建 start-ethereum.sh 文件， genesis.json 也可以在 Docker 容器啟動後創建。

centOS

Windows

運行成功後執行

進入 docker 容器命令行
因為 Windows 沒有掛載共享目錄，所以 root 目錄下沒有 genesis.json 文件，我們要在這裏手動創建 genesis.json 文件，內容要和 centOS 的一致。

data 用來存放區塊數據

geth 的參數參看 以太坊客戶端Geth命令用法-參數詳解

啟動私有節點後進入 geth 命令行執行：

輸出的內容就是節點信息，我們在手動連接節點是會用到，注意要把「0.0.0.0「換成你自己的IP，然後將這個信息發送給其他節點。手動連接節點有兩種方式：

當然不管使用哪種方法連接節點都要保證創世區塊文件 genesis.json 一致，還有在啟動時 networkid 也要一致。

至此以太坊私有鏈已搭建完畢。

geth命令

docker命令

I. 以太坊無法連接節點

把你的TCP/IP協議設置成自動獲取狀態試試,方法:右鍵網上鄰居-屬性- 右鍵"本地連接"屬性-雙擊"Internet 協議 TCP/IP"-改為自動獲取

IPX/SPX協議，IPX是NetWare最底層的協議，它只負責數據在網路中的移動，並不保證數據是否傳輸成功，也不提供糾錯服務。IPX在負責數據傳送時，如果接收節點在同一網段內，就直接按該節點的ID將數據傳給它；如果接收節點是遠程的（不在同一網段內，或位於不同的區域網中），數據將交給NetWare伺服器或路由器中的網路ID，繼續數據的下一步傳輸。SPX在整個協議中負責對所傳輸的數據進行無差錯處理，所以我們將IPX/SPX也叫做「Novell的協議集」。

J. 以太坊源碼分析--p2p節點發現

節點發現功能主要涉及 Server Table udp 這幾個數據結構，它們有獨自的事件響應循環，節點發現功能便是它們互相協作完成的。其中，每個以太坊客戶端啟動後都會在本地運行一個 Server ，並將網路拓撲中相鄰的節點視為 Node ，而 Table 是 Node 的容器， udp 則是負責維持底層的連接。下面重點描述它們中重要的欄位和事件循環處理的關鍵部分。

PrivateKey - 本節點的私鑰，用於與其他節點建立時的握手協商
Protocols - 支持的所有上層協議
StaticNodes - 預設的靜態 Peer ，節點啟動時會首先去向它們發起連接，建立鄰居關系
newTransport - 下層傳輸層實現，定義握手過程中的數據加密解密方式，默認的傳輸層實現是用 newRLPX() 創建的 rlpx ，這不是本文的重點
ntab - 典型實現是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 與其他節點建立連接時的握手信息，包含本地節點的版本號以及支持的上層協議
addpeer － 連接握手完成後，連接過程通過這個通道通知 Server

Server 的監聽循環，啟動底層監聽socket，當收到連接請求時，Accept後調用 setupConn() 開始連接建立過程

Server的主要事件處理和功能實現循環

Node 唯一表示網路上的一個節點

IP - IP地址
UDP/TCP - 連接使用的UDP/TCP埠號
ID - 以太坊網路中唯一標識一個節點，本質上是一個橢圓曲線公鑰(PublicKey)，與 Server 的 PrivateKey 對應。一個節點的IP地址不一定是固定的，但ID是唯一的。
sha - 用於節點間的距離計算

Table 主要用來管理與本節點與其他節點的連接的建立更新刪除

bucket - 所有 peer 按與本節點的距離遠近放在不同的桶(bucket)中，詳見之後的 節點維護
refreshReq - 更新 Table 請求通道

Table 的主要事件循環，主要負責控制 refresh 和 revalidate 過程。
refresh.C - 定時(30s)啟動Peer刷新過程的定時器
refreshReq - 接收其他線程投遞到 Table 的 刷新Peer連接 的通知，當收到該通知時啟動更新，詳見之後的 更新鄰居關系
revalidate.C - 定時重新檢查以連接節點的有效性的定時器，詳見之後的 探活檢測

udp 負責節點間通信的底層消息控制，是 Table 運行的 Kademlia 協議的底層組件

conn - 底層監聽埠的連接
addpending － udp 用來接收 pending 的channel。使用場景為：當我們向其他節點發送數據包後(packet)後可能會期待收到它的回復，pending用來記錄一次這種還沒有到來的回復。舉個例子，當我們發送ping包時，總是期待對方回復pong包。這時就可以將構造一個pending結構，其中包含期待接收的pong包的信息以及對應的callback函數，將這個pengding投遞到udp的這個channel。 udp 在收到匹配的pong後，執行預設的callback。
gotreply - udp 用來接收其他節點回復的通道，配合上面的addpending，收到回復後，遍歷已有的pending鏈表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一個 Table

udp 的處理循環，負責控制消息的向上遞交和收發控制

udp 的底層接受數據包循環，負責接收其他節點的 packet

以太坊使用 Kademlia 分布式路由存儲協議來進行網路拓撲維護，了解該協議建議先閱讀 易懂分布式 。更權威的資料可以查看 wiki 。總的來說該協議：

源碼中由 Table 結構保存所有 bucket ， bucket 結構如下

節點可以在 entries 和 replacements 互相轉化，一個 entries 節點如果 Validate 失敗，那麼它會被原本將一個原本在 replacements 數組的節點替換。

有效性檢測就是利用 ping 消息進行探活操作。 Table.loop() 啟動了一個定時器（0~10s），定期隨機選擇一個bucket，向其 entries 中末尾的節點發送 ping 消息，如果對方回應了 pong ，則探活成功。

Table.loop() 會定期（定時器超時）或不定期（收到refreshReq）地進行更新鄰居關系（發現新鄰居），兩者都調用 doRefresh() 方法，該方法對在網路上查找離自身和三個隨機節點最近的若干個節點。

Table 的 lookup() 方法用來實現節點查找目標節點，它的實現就是 Kademlia 協議，通過節點間的接力，一步一步接近目標。

當一個節點啟動後，它會首先向配置的靜態節點發起連接，發起連接的過程稱為 Dial ，源碼中通過創建 dialTask 跟蹤這個過程

dialTask表示一次向其他節點主動發起連接的任務

在 Server 啟動時，會調用 newDialState() 根據預配置的 StaticNodes 初始化一批 dialTask ， 並在 Server.run() 方法中，啟動這些這些任務。

Dial 過程需要知道目標節點( dest )的IP地址，如果不知道的話，就要先使用 recolve() 解析出目標的IP地址，怎麼解析？就是先要用藉助 Kademlia 協議在網路中查找目標節點。

當得到目標節點的IP後，下一步便是建立連接，這是通過 dialTask.dial() 建立連接

連接建立的握手過程分為兩個階段，在在 SetupConn() 中實現
第一階段為 ECDH密鑰建立 ：

第二階段為協議握手,互相交換支持的上層協議

如果兩次握手都通過，dialTask將向 Server 的 addpeer 通道發送 peer 的信息