原作者：靈魂機器
原作者：靈魂機器
原作者：靈魂機器
算法核心流程
Tendermint 是Tendermint公司開源的的一個項目，是一個pBFT算法的變體，Tendermint和pBFT的關係類似於Raft和Paxos的關係，Tendermint是pBFT的簡化版。
算法核心流程
Tendermint 核心算法流程如下圖所示：
Tendermint算法先隨機選出一些節點作為Validators(怎麼選擇驗證節點？見後面的“如何選擇驗證節點”)，然後選擇其中一個validator作為proposer節點。 Proposer節點開始監聽並收集全網的所有交易，幾分鐘後，組裝一個新塊，並向全網廣播，這個就是proposal block。全網所有validator節點收到這個proposal block後，開始讀取這個block裡的所有交易，一一進行驗證，如果沒有問題，就發出一條pre-vote 投票消息，表示同意這個block，投一個肯定票，如果發現block裡有非法交易，則投一個反對票，這些投票消息會被廣播到所有validator節點，所以每個validator節點既會發出一個投票消息，又會收集別人的投票消息，當發現收集到的同意投票數量超過2/3時，就發出一個pre-commit 投票信息，這是第二階段的投票了，這是每個節點也在監聽並收集pre-commit的投票消息。當一個validator節點收集到的pre-commit 同意票數超過2/3時，說明這個block 是得到了大多數人統同意的，可以放心把這個block寫入本地的區塊鏈，追加到末尾，即完成commit。同時區塊高度增一，proposer節點索引也增1，進入下一輪(round), 開始提議新快。
上述描述的是90%時候的正常流程，即藍色箭頭表示的那個大循環。接下來說一下內圈那個紅色箭頭表示的小循環。大部分情況下，一個塊只需要一輪就可以完成確認，達成共識，但是有時候網絡狀態不好，經常發生超時，這時候就會進入內圈紅色流程了。由於每一輪(round)只有一個proposer有權力出塊，如果這個proposer掛了或者網絡不好超時了，怎麼辦？不可能大家永遠等待這個proposer啊，算法顯然不會設計的這麼蠢，存在一個明顯的單點故障（single point of failure）。在proposer節點propose階段，所有validator節點會啟動一個定時器，設置超時時間為T（這個T的值是根據網絡情況動態計算出來的），如果在這個時間內還沒有收到proposer節點發來的新塊，就認為這個proposer節點掛了，所有validator節點不會繼續等下去，會立刻在本機生成一個特殊結構的空塊，假裝這個空塊是從Proposer節點那裡收到的，這樣，無論如何，在時間T內，都會收到一個proposal區塊，要么是一個正常塊要么是一個空塊。然後接著對這個塊進行pre-vote投票和pre-commit投票。如果proposer掛了，絕大部分validator看到的都是一個空塊，因此空塊會獲得多數投票，進入commit階段。 commit空塊的時候，不會真的往區塊鏈寫入一個空塊，而是什麼都不寫，區塊高度不自增，保持不變，這樣相當於什麼也沒有乾，這一輪( round )是在空轉。這一輪轉完了，下一輪開始的時候會換下一個validator當proposer，這樣當前那個掛掉的proposer，就不會卡主整個網絡。
網絡通信複雜度
Tendermint 的網絡通信複雜度為O(n2)，因為在兩個投票階段，每個validator節點都需要收集超過2/3個投票消息，網絡發送的數據包數量是n2，因此網絡同心複雜度是O (n2)。在Proposal階段，新塊只需要被所有validator收到，網絡通信複雜度是O(n)。總的來說，是O(n2)。網絡通信複雜度為O(n2)，注定了Tendermint的節點數不會太多，太多的話網絡通信這一塊會成為瓶頸，因此Tendermint 適用於私有連和聯盟鏈，論文第17頁也指明了這一點： Tendermint is that solution, optimized for consortia, or inter-organizational logic 不過如果配合良好的分片Sharding機制，還是可以用於公有鏈的。這是後話了。
網絡假設
Tendermint對網絡的要求是，需要網絡是半同步的。 Tendermint在Propose階段，有一個超時機制，但是這個超時時間不是一個常量，是動態變化的，因此在這個階段，要求網絡是半同步的。在pre-vote階段和pre-commit兩個投票階段，對網絡沒有要求的，即網絡是異步的。因此，Tendermint對網絡要求是半同步的。
由於在pre-vote和pre-commit的投票階段，網絡是異步的，如果沒有收集到超過2/3的投票數，所有validator節點會無限期等待下去，因此，整個系統會卡住。 Tendermint在Liveness方面有所妥協，換取了更強的Finality。
舉個例子，如果在某一輪中proposer節點廣播出了一個新塊blockX，某個validator A節點沒有按時收到新塊，那麼該A就會在本機構造一個空塊，當做是從proposer收到的，發出一個pre-vote nil投票消息然後進入pre-vote循環，並啟動一個超時定時器，這時進入了紅色內圈循環，A開始監聽網絡並收集投票信息，
收集到了超過2/3的投票總數後，如果投給空塊的票數超過2/3，則發出pre-vote nil投給空塊，依舊留在紅色內圈；如果投給blockX的票數超過2/ 3，則發出pre-vote投給blockX，切換到藍色外圈；如果空塊和blockX各自的票數，都沒有超過2/3，那麼發出pre-vote nil 消息投票給空塊，進入pre-commit階段，依舊在紅色內圈。
Finality和Liveness
一旦A發出了pre-commit nil的投票消息，A還是留在紅色內圈循環，pre-commit流程與上麵類似。總而言之，紅色內圈的流程，需要假設網絡是半同步的。
Finality和Liveness
Tendermint的Finality是Deterministic 的，而比特幣的Finality是Probabilistic，Tendermint比比特幣具有更強的Finality。
但是在Liveness方面，例如在網絡發生分裂的時候，Tendermint理論上有可能卡住，任何新交易都無法寫入，而比特幣可以分裂成兩個分叉，各自獨立工作，新的交易可以繼續進行。
鎖機制
在上面的圖中，其實還隱含有一個鎖機制，沒有在圖中表現出來。舉個例子，有四個validator 節點，A,B,C,D, 在某個R輪，
在propose階段，proposer節點廣播出了新塊blockX
A的超時時間內沒有收到這個新塊，向外廣播pre-vote nil，B,C,D都收到了，向外廣播pre-vote投給blockX
現在四個節點進入了pre-commit階段，A處於紅色內圈，B,C,D處於藍色外圈
假設A由於自身網絡不好，又沒有在規定時間內收到超過2/3個對blockX的投票，於是只能發出pre-commit nil投票消息投給空塊
D收到了B和C的pre-vote消息，加上自己的，就超過了2/3了，於是D在本機區塊鏈裡commit了blockX
B和C網絡出現問題，收不到D在pre-commit消息，這是B和C只能看到2票投給了blockX，一票投給了空塊，全部不足2/3，於是B和C都只能commit空塊，高度不變，進人R+1輪，A也只能看到2票投給了blockX，一票投給了空塊，也只能commit空塊，高度不變，進人R+1輪
在R+1輪，由於新歡了一個proposer, 提議了新的區塊blockY，A,B,C 三個個可能會在達成共識，提交blockY，於是在同樣的高度，就有blockX和blockY兩個塊，產生了分叉。
Tendermint加上了鎖的機制，具體就是，在第7步，即使proposer出了新塊blockY，A,B,C只能被鎖定在第6步他們的pre-commit塊上，即A在第6步投給了空塊，那麼在第R+1輪，只能繼續投給空塊，B在第6步投給了blockX，那麼在新一輪，永遠只能投給blockX，C也是類似。這樣在R+1輪，就會有1票投給空塊，兩票投給blockX，最終達成共識blockX，A,B,C三人都會commit blockX，與D一致，沒有產生衝突。
Tendermint與pBFT比較
Tendermint和pBFT看起來非常類似，例如：
都屬於BFT類型的算法，最多容忍不超過1/3的惡意節點
都是三階段提交，Tendermint的propose->pre-vote->pre-commit三個階段，跟pBFT的三個階段，pre-prepare, prepare, commit 三階段是一一對應的
都在超時的時候，換掉proposer/primary
The state of each replica includes the state of the service, a message log containing messages the replica has accepted, and an integer denoting the replica’s current view.
不夠Tendermint相對於pBFT有兩處簡化。
Tendermint沒有pBFT那種View Change階段，Tendermint很巧妙的把超時的情況，跟普通情況融合成了統一的形式，都是propose->pre-vote->pre-commit 三階段，只是超時的時候新塊是一個特殊的空塊。切換proposer是通過提交commit空塊來觸發的，而pBFT是有一個單獨的view change過程來觸發primary輪換。
除了消除View Change這一點，Tendermint還在另一個地方有所簡化，Tendermint的所有信息都存儲在blockchain裡。因為pBFT是1999年提出來的，那時候還沒有blockchain這個東西(blockchain是2009年比特幣出現之後才有的)，因此pBFT的所有節點雖有有一致的數據，但數據是分散存放的。 pBFT的每個節點的數據包括:
Blockchain就是一個分佈式數據庫，好比在MySQL這類DBMS數據庫沒出現之前，人們都是把數據寫入文件然後存在硬盤上，發明出各種奇怪的文件格式和組織方式。有了MySQL後，管理數據就方便多了。同理，Tendermint 把數據全部存入blockchain, pBFT沒有blockchain這樣一個分佈式數據庫，所有全節點需要自己在硬盤上管理數據，比如為了壓縮消息日誌，丟棄老的消息，節省硬盤空間，引入了checkpoint的概念，光是數據管理這一塊就多了很多繁瑣的步驟。
Tendermint和pBFT關係類似於Raft和Paxos的關係，Tendermint是pBFT的簡化版，是針對blockchain這個場景下的簡化版pBFT 。
如何選擇驗證節點
首先，在創始區塊裡，可以靜態設置一組validator節點其次，當鏈啟動後，可以發送ValidatorUpdate消息，更新validator列表。見Validator Updates
這個地方文檔裡沒有講太多，看起來還是比較原始的，沒有Algorand 那種密碼抽籤類似的隨機抽樣算法。不過這個地方應該是可以隨時拓展的。
如何輪流換Proposer
選出來了一組validator節點後，全網所有validator節點都會存一份，比如放在一個循環數組裡。
一般一個區塊大部分情況下只需要一輪(round)就能產生，網絡不好的時候可能要多輪才能出一個塊。無論如何，每一輪都會有一個新的validator作為proposer, 輪換規則就是很簡單的依次遞增，第一輪，會選擇數組中第0個validator作為proposer, 第二輪選擇第1個validator,一次類推，到達最後一個後，重置為0，這樣無限循環。
然後開始共識算法，第0輪迴選擇位置為0的validator 作為proposer節點，第1輪選擇位置為1的validator, 第2輪選擇位置為2的validator作為proposer, 到達最後一個後在重置為0，無限循環。
Round-robin 策略太簡單了，容易被壞人預測到下一個validator是誰，於是可以提前佈局，對validator發起DDoS攻擊或別的攻擊，怎麼辦呢？ Tendermint的解決方法就是，把validator節點，全部放在Sentry Node後面，對外不暴露IP地址。
參考資料
Tendermint: Byzantine Fault Tolerance in the Age of Blockchains
Tendermint: Consensus without mining
