區塊鏈時代的拜占庭容錯：Tendermint (八)

時間 2019-11-07

原文原文鏈接

原文題目：《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》git

原文做者：Ethan Buchmangithub

本文爲節選web

性能和容錯算法

Tendermint被設計爲拜占庭容錯的狀態機複製算法。只要不超過總量的三分之一的驗證人是拜占庭節點，就能保證網絡的安全性，而且只要網絡消息最終獲得傳遞，即便對於gossiping提議的網絡同步性假設很弱，它也能保持運行。在發生此類故障時，Tendermint共識的落實不會影響安全性，它會對性能產生最小的影響，而且能夠快速恢復。能夠經過幾種關鍵的方式來評估Tendermint算法的性能。最明顯的衡量指標是塊提交時間，它是衡量最終延遲的指標，也是衡量交易吞吐量的網絡容量指標。咱們在網絡上收集每一個分佈在地球上的驗證人節點的測量值，其中驗證人的數量範圍是2的倍數，從2到64。docker

概覽數據庫

可使用https://github.com/tendermint/network_testing 上的代碼庫重現本章中的實驗。全部實驗都在t2.medium或c3.8xlarge的Amazon EC2實例上運行的docker容器中進行。 t2.medium有2個CPU和4GB RAM，c3.8xlarge有32個CPU和60GB RAM。實例分佈在七個數據中心，跨越五大洲。負責生成交易的第二個docker容器在每一個實例上運行。交易大小爲250字節（包括一些32或64字節的哈希和簽名的合理大小），而且構造爲可調試的方式，也便於快速生成指令，而且也包含了一些隨機性。所以，前導字節是表示該實例的交易編號和驗證人索引的Big-Endian編碼整數，從操做系統中隨機抽取尾隨的16字節，而且中間字節僅爲零。安全

網絡監控工具用於維護每一個驗證人節點的Tendermint RPC服務器的活躍websocket鏈接，並在第一次收到新的已提交塊時使用其本地時間做爲該塊的正式提交時間。首先在沒有監控的狀況下運行實驗，方法是複製驗證人節點中的全部數據進行分析，並使用提交塊的2/3驗證人節點的本地時間做爲提交時間。使用監控要快得多，適合在線監視，只要只有塊頭信息（而不是整個塊）經過websocket傳遞，就不會影響到結果。服務器

使用docker-machine工具能夠輕鬆管理遠程計算機上的Docker容器，而且網絡測試存儲庫提供了一些工具，這些工具利用Go語言的併發功能在多個遠程計算機上同時對docker容器執行操做。websocket

每一個驗證人節點直接相互鏈接，以免網絡拓撲的混淆影響。網絡

對於涉及崩潰故障或拜占庭行爲的實驗，故障節點的數量取決於Nfault = ⌊(N − 1)/3⌋，其中N是驗證人節點的總數。

吞吐量和延遲

本節描述了測量Tendermint在非對抗條件下（編者注：做者意指不考慮拜占庭節點等容錯的狀況）的原始性能的實驗，其中全部節點都在線並同步，而且沒有爲異步作出調整。也就是說，使用了極高的TimeoutPropose（10秒）參數，而且全部其餘超時參數都設置爲1毫秒。此外，全部mempool活動都被禁用（沒有交易的gossiping亦或在提交完成後的複檢），進程內的nil應用程序爲了繞過TMSP。

實驗基於驗證人集合運行，集合大小從2增長到64，塊大小從128到32768加倍。每一個驗證人節點都預先加載了交易。每一個實驗運行16個區塊。

從圖1中能夠看出，Tendermint每秒能夠輕鬆處理數千個交易，大約有一秒的出塊延遲，儘管每秒大約有一萬個交易處理容量限制。 16384個交易的塊大小約爲4 MB，而且網絡帶寬分析顯示每一個鏈接容易達到20MB / s以上，可是對日誌的分析代表，在達到高的區塊高度時，驗證人節點可能花費超過兩秒的時間來等待塊部件。此外，如圖2所示，單個數據中心的實驗代表，能夠實現更高的吞吐量，而在更好的機器上進行的實驗表現出更一致的性能，從而減輕了容量限制，如圖3所示。咱們將此容量限制的進一步調研留待將來的工做。

圖1：延遲-吞吐量權衡。較大的塊會致使交易吞吐量逐漸減小，最終容量約爲10,000 txs / s

圖2：單個節點的狀況。當消息不須要經過網絡時，Tendermint每秒能夠進行數萬次交易。

圖3：大型機。使用32個vCPU和60GB RAM，交易吞吐量隨塊大小線性增長，從而減輕了較小機器上的容量限制。

在後續的實驗中將注入各類形式的故障並呈現延遲統計。對於不一樣的TimeoutPropose值，以及塊大小爲2048個交易，每一個實驗運行的驗證人集合大小從4增長到32。

死機故障

爲了評估遭受節點崩潰故障的網絡的性能，每隔三秒就會隨機選擇，中止並在三秒鐘後從新啓動Nfault個驗證者。

表1中的結果代表，此崩潰故障情形下的性能降低了約50％，而較大的TimeoutPropose值有助於減輕延遲。雖然平均延遲增長到大約兩秒，但中位數接近一秒，而且延遲可能高達十甚至二十秒，雖然極端狀況可高達七十秒。而將TimeoutPropose修改成略微的不肯定性能夠緩解這種極端延遲的可能性。

表1：崩潰 - 故障延遲統計信息。每三秒鐘，一次隨機選擇的Nfault個驗證者崩潰，並在三秒鐘後從新啓動。此崩潰重啓過程持續了200個塊。對於TimeoutPropose參數的不一樣值，每一個表都報告出塊延遲的最小值，最大值，平均值，中位值和第95百分位數(95th percentile)。

隨機網絡延遲

另外一種形式的故障，可能歸因於拜占庭行爲或網絡異步，是爲每次讀取和寫入網絡鏈接注入隨機延遲。在這個實驗中，在每次網絡鏈接的每次讀寫以前，驗證者的Nfault都會休眠X毫秒，其中X統一繪製在（0,3000）上。從表2中能夠看出，延遲與崩潰失敗狀況相似，但增長TimeoutPropose會產生相反的效果。因爲並不是全部驗證人節點都有錯誤，所以TimeoutPropose的小值容許快速跳過錯誤的驗證人節點。若是全部驗證人節點都受到網絡延遲的影響，則預期較大的Timeout-Propose值將減小延遲，由於不會有無錯誤的驗證人節點跳過，而且將提供更多時間來接收延遲的消息。

表2：隨機延遲延遲統計。 Nfault個驗證者設置爲在每次讀取和寫入以前注入隨機延遲，其中延遲時間在（0,3000）毫秒上均勻選擇。

拜占庭式的失敗

經過對狀態機的如下修改，能夠注入更明確的拜占庭故障：

相互矛盾的提案：在提出建議時，拜占庭驗證員會分別簽署兩個相互衝突的提案並進行廣播，同時進行投票前和預先提交，以分離其鏈接對等體的一半。
沒有nil票：拜占庭驗證者從不簽署一次空的投票（nil-vote）。
簽署每一個提案：拜占庭驗證者提交投票前和投票一看到它就會預先提交它看到的每一個提案。

總之，這些行爲明顯違反了雙重簽名和鎖定規則。但請注意，這種行爲主要是因爲衝突提案的廣播，以及最終提交其中一個提案。更復雜的拜占庭策略則有待後續的工做。

雖然說注入了拜占庭故障會致使許多系統徹底當即失效，但Tendermint保持了可觀的延遲，如表3所示。因爲這些故障與異步處理幾乎沒有關係，所以TimeoutPropose沒有真正可辨別的效果。性能也隨着更大的驗證者集合而降低，這多是處理拜占庭投票的一個想固然結果。

相關工做

本章節中的吞吐量實驗基準測試了PBFT實現的性能和稱爲HoneyBadgerBFT的新隨機BFT協議。在他們的結果中，PBFT在四個節點上每秒實現超過15,000次交易，但隨着節點數量的增長呈指數衰減，而HoneyBadgerBFT每秒可實現10,000到15,000次交易的比較均勻的性能。然而，HoneyBadgerBFT中的出塊延遲要高得多，對於大小爲8,16和32的驗證人集合，接近10秒，對於較大的驗證人集合則更接近10秒。

用於研究共識實現的衆所周知的工具是Jepsen （譯者注：JEPSEN - Distributed Systems Safety Analysis. http://jepsen.io.），它用於經過模擬多種形式的網絡分區來測試數據庫的一致性保證。使用Jepsen測試Tendermint仍然是將來工做中一個使人感到興奮的領域。

結論

做者和Jae Kwon編寫的Tendermint的實現很容易在全球分佈的機器上實現每秒數千個交易，最多64個節點，延遲大多在一到兩秒範圍內。這也使它與其餘解決方案競爭激烈，尤爲是區塊鏈的當前狀態，例如比特幣，支持每秒約7筆交易。此外，咱們的軟件實現體現出即便面對崩潰故障、消息延遲和故意的拜占庭故障等都是健壯的，在每一個方案中也可以保持每秒超過一千個交易。

表3：拜占庭故障延遲統計。拜占庭驗證人提出衝突的阻止，並在他們看到任何提案後當即對其進行投票。對於TimeoutPropose參數的不一樣值，每一個表都報告出塊延遲的最小值，最大值，平均值，中位值和第95百分位數。

至此，論文《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》中文譯名《區塊鏈時代的拜占庭容錯：Tendermint》系列的核心內容一共八篇譯文，所有推送完畢。