表1 各種共識演算法比較
下面詳細講解一下上面表格中的內容。
Finality
Finality看起來和Safety, Consistency 很相似，又似乎有所不同，非常容易讓人困惑。
簡單的理解，你可以認為 Finality, Safety, Consistency是同義詞，即Finality=Safety=Consistency。
更深入理解，我認為Finality是一個綜合體，Finality>Safety>Consistency 。Consistency適用於所有分散式系統的，包括可信環境例如Hadoop和不可信環境例如Bitcoin； Safety適用於拜占庭環境下；Finality 是在區塊鏈這個場景下的術語，區塊鏈是拜占庭場景下的一個子集（拜占庭問題除了區塊鏈還有非區塊鏈的解決方案）。Consistency 是CAP理論中的C，更加general, 要求沒有Finality那麼多。Finality包含的含義比 Consistency更多更強。Finality包含了下面所有含義：
- 所有節點的資料應是一致的。客戶端發出一個讀操作到任意一個節點，得到的結果應該是一樣的。這個就是CAP裡所說的Consistency. 這個術語是適用於所有的分散式系統的，包括可信環境例如Hadoop和不可信環境例如Bitcoin。
- 所有節點要確保不進入互相沖突，分裂的狀態，即safety。這個術語是適用於 Byzantine fault tolerance這個領域的，在拜占庭這種開放環境裡，有惡意節點會廣播兩個互相沖突的訊息（例如雙花交易），導致全網所有節點陷入分裂狀態，達不成一直，這就破壞了Safety這個性質。所有拜占庭下的共識演算法，都需要處理好惡意節點的問題，保證全網的safety。
- 交易一旦進入區塊，應該不可撤銷，即 Immutability。在區塊鏈場景下，要保證Safety，不僅需要處理好惡意節點發出雙花交易這種問題，而且還要防止惡意節點撤銷已經打包進區塊的交易。因為區塊鏈是一個單連結串列，是一個線性結構，惡意節點理論上可以從舊的一個區塊出發，分叉處一個更長的新鏈，把自己已經發出去的交易全部撤銷掉，把自己的錢再花一遍（是另一種形式的雙花）
綜上，Finality=Consistency + Safety + Immutability。
Liveness
Liveness可以認為與CAP中的Availability等價。當網路出現partition時，比如海底光纜斷裂，將全球網際網路分割成兩個部分，整個區塊鏈系統是否能正常寫入新的交易？喜歡Finality的共識演算法，這時候會選擇無限等待，新的transaction無法寫入，直到海底光纜修復，兩邊的網際網路互通；喜歡Availabilty的共識演算法，這時候兩邊網路會獨立運作，資料分家了，兩邊的全節點中的資料變得不一致。
比如Tendermint就是這類，犧牲Liveness追求Deterministic Finality。假設海底光纜斷裂將網路分為兩邊，那麼每一邊都有一半的validator, 於是在vote和commit階段，每一邊的所有validator, 100%全部投票贊成某個proposal block，最多隻能收到50%的投票，達不到2/3，於是整個區塊鏈網路會無限等待，直到收集到2/3投票為止。在這個等待期間，無法出下一個塊，新的交易也無法寫入，整個網路陷入癱瘓。
比特幣在碰到這種網路分割的時候，兩部分的比特幣系統會繼續向前走，依舊可以寫入新的transaction, 產生新的區塊，當海底光纜修復後，兩邊網際網路連通後，再選擇合併。
在海底光纜沒斷之前，全球所有全節點的狀態是一致的，如下圖：
當海底光纜斷裂後，全球網路被分割為兩部分，兩個部分都會獨立出塊，這時候兩邊已經不一致了，但是兩邊各自是感知不到的，以為自己依舊是一條線性的區塊鏈，如下圖：
左邊和右邊，雖然依舊每10分鐘挖出一個新塊，但是左邊的 block07和右邊的block07，block hash 是不相等的。這時候比特幣網路還是available的，只是Finality破壞了。
當海底光纜修復後，這時候，兩邊互相同步block，會意識到出現了分叉，如下圖：
現在全球所有全節點的狀態，變成上圖，有分叉了，由於兩邊的高度都是8，無法決定哪個分叉是正確的，這時候，就看礦工支援哪邊了，哪邊的算力高，哪邊先出了新塊，那麼哪邊就勝出了，短的那條鏈會被拋棄，比如假設右邊搶先新出了一個塊，那麼右邊勝出，左邊分叉被拋棄，所有全節點中的資料又變成一條線性區塊鏈，達成一致了，如下圖：
其實即使海底光纜不斷，網路沒有partition, 也會經常發生兩個miner各自同時挖出一個新塊的情況，這時候就比拼誰運氣好，下一個新塊繼承哪一個分叉哪一個就勝出。也就說比特幣理論上永遠沒有一個確定性的一致性狀態，分叉隨時會在任意高度上出現，因此比特幣犧牲了一點Finality, 換取更強的Liveness。
Network Assumption
所有分散式共識演算法都對網路有一個隱含的假設前提。 先說一下網路的分類：
同步：訊息一定會在某個的時間T內被送達，這個上限(upper bound)的值T，是已知的常量，所有節點都是知道的。如果訊息在T時間內沒有送達，就不對這個訊息作指望了，節點認為該訊息已經丟失，不會繼續等它。所有節點都有條不紊的，每經過一個時間T，就往前進一步，非常整齊。
半同步：訊息一定會在某個的時間T內被送達，但這個T的值，不是固定的值，而是動態變化的，例如是根據網路狀況動態計算出來的。所有節點
非同步：訊息會在任意時間到達，可能很快，也可能很慢，總之沒有一個明確的上限(upper bound)甚至無限期延遲，無論多晚到達，節點都要接受並處理這個訊息，不能簡單的因為超時就丟棄訊息
比特幣對網路的假設就是網路是同步的，時間上限是10分鐘左右，一個Miner 挖出一個block後，向全網廣播，這時候整個比特幣系統，期望就是這個block 在10分鐘內會被所有線上的全節點full node收到，意思就是說每隔10分鐘，所有全節點都會整整齊齊地往前走一步，即往自己的區塊鏈尾部追加一個block。即使網速很快，例如3分鐘不到，這個新block已經被所有全節點收到了，比特幣還是會每隔10分鐘往前走一步(出一個新塊)。以太坊類似，不過時間上限是15秒。
Tendermint 在propose階段假設網路是半同步的，因為在這一步會有一個超時時間，如果超過時間還沒收到一個proposal新塊，那麼其他validator就會認為proposer節點已經掛了，於是出一個空塊，直到round-robin到下一個proposer。Tendermint在prevote和precommit都需要收集超過2/3的投票，是無限等待的，也就是在這兩個階段是假設網路是非同步的。最終，Tendermint對網路的要求是半同步的。
pBFT在pre-prepare, prepare, commit三個階段全部是非同步的，既然是非同步的，沒有超時機制，那怎麼往前進展呢？收集到了超過2/3就能繼續往前進。不過所有節點在收到一個客戶端的請求，都會啟動一個定時器，如果在某個時間內該請求還沒有執行完畢，就會觸發 View Change。View Change 這個部分是半同步的。
在這裡可以體會到Tendermint相比pBFT的簡化之處了。Tendermint 把超時機制挪動到了propose階段（相當於pBFT的pre-prepare階段），如果proposer在規定時間內，廣播出了一個proposal block，那麼就前進到下一步，如果超時了，也前進到下一步，不過這個是proposal block是一個空塊（空塊時也會完整走一遍pre-vote和pre-commit流程，不過block height不會自增1，相當於網路在空轉，一直到round-robin到下一個新的proposer節點，重新廣播新的proposal block）。也就是無論如何，propose階段都會往前進入到下一步。但是 Tendermint的pre-prepare是非同步的，有可能永遠卡主。pBFT把超時機制挪動到了View Change 這一部分，因此pBFT就多出來一個View Change 步驟，比 Tendermint複雜了一些。Tendermint透過提交空塊和round-robin更換proposer 節點, 而 pBFT則是透過 View Change 來更換primary節點。Tendermint消除了複雜的View Change這一步驟。
除了消除View Change這一點，Tendermint還在另一個地方有所簡化，Tendermint的所有資訊都儲存在blockchain裡。而pBFT是1999年提出來的，那時候還沒有blockchain這個東西，因此 pBFT的所有節點雖有有一致的資料，但資料是分散存放的。pBFT的每個節點的資料包括:
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.
Blockchain就是一個分散式資料庫，好比在MySQL這類DBMS資料庫沒出現之前，人們都是把資料寫入檔案然後存在硬碟上，發明出各種奇怪的檔案格式和組織方式。有了MySQL後，管理資料就方便多了。同理，Tendermint 把資料全部存入blockchain, pBFT沒有blockchain這樣一個分散式資料庫，所有節點需要自己在硬碟上管理資料，比如為了壓縮訊息日誌，丟棄老的訊息，節省硬碟空間，引入了checkpoint的概念。
Tendermint和pBFT關係類似於Raft和Paxos的關係，Tendermint是pBFT的簡化版，是針對blockchain這個場景下的簡化版pBFT
下圖是Tendermint的演算法流程圖：
下圖是pBFT的演算法流程圖：
