區塊鏈系統可以歸結為如下圖所示的六層架構模型，自下而上分別是資料層、網路層、共識層、激勵層、合約層和應用層。部分割槽塊鏈應用並不完整地包含這六層結構，但是資料層、網路層和共識層可以說是構建所有區塊鏈應用的必要因素。
目前，大部分的區塊鏈應用都是採用整體的設計方法，就是說，這些區塊鏈應用實現成單一的程式，一個程式實現了區塊鏈各層的所有功能，包括P2P連線，交易資料的處理和廣播，共識達成，具體的應用功能實現等等。
例如比特幣，一整套程式碼就實現了所有比特幣的功能。從軟體工程的角度來看，這種非模組化的設計是不合理的，這會使程式碼複用變得困難，程式碼的分支管理也變得複雜，同時還限制的區塊鏈應用開發使用的語言。
針對這個問題，Tendermint對區塊鏈的功能模組進行解耦，將共識和P2P部分從具體的區塊鏈應用狀態細節中分離出來，以適用各種分散式應用。
Tendermint由兩部分組成：區塊鏈共識引擎和通用的應用程式介面。
1. 共識引擎被稱為Tendermint Core，用於確保同一個交易在不同機器上記錄的順序相同。
2. 通用的應用程式介面也被稱為應用區塊連結口（Application Blockchain Interface，ABCI），其作用是使交易可以用任何程式語言進行處理。
Tendermint Core透過ABCI介面與應用層進行互動，應用程式可以用任何語言編寫，開發者可以很方便地開發自己的區塊鏈應用。
Tendermint Core
Tendermint Core實現區塊鏈大部分功能，包括：共識演算法，RPC，資料庫，同步，P2P等等。本節主要介紹Tendermint共識演算法。
Tendermint共識演算法
Tendermint使用一種基於拜占庭容錯（BFT）的共識演算法，其工作模式類似於迴圈投票機制。參與Tendermint共識過程的角色主要有兩個：
· Validator（驗證者）：網路中的節點，可參與共識過程中的投票，不同的驗證者在投票過程可能具備不同的投票權重（vote power）。
· Proposer（提議人）：Tendermint使用一種確定的非阻塞輪詢選擇演算法從validators中選出proposer，該演算法根據validators的投票權重所佔比例來選擇proposer，投票權重越大的validator被選為proposer的頻率越高。
Tendermint區塊鏈是透過基於round（回合）的機制來確定下一個區塊。每個round由三個過程組成：propose（提議），prevote（預投票）和precommit（預提交）。
理想情況下，鏈上的區塊生成狀態如下：
NewHeight -> (Propose -> Prevote -> Precommit) -> Commit -> NewHeight ->...
其中，NewHeight為區塊被全網接受後，區塊高度+1。Propose -> Prevote -> Precommit為一個round，這裡加括號表示在某一區塊高度成功提交一個區塊可能需要多個round，也就是說，一個round可能無法成功地提交區塊。
區塊鏈處於某一區塊高度時，為決定出下一區塊，系統會進入如上圖所示的共識過程。
第一階段為propose階段，在該階段由系統選出的proposer提議將某一交易區塊作為鏈上的下一區塊，並將該提議廣播出去。接下來需要進入兩個投票階段：prevote和precommit。在prevote階段，對於proposer提議的區塊，若validator驗證為有效區塊，那麼validator會對其進行prevote；相反，若為無效區塊或者validator沒有及時收到提議的區塊，那麼validators的prevote為空（Nil）。
在precommit階段，若validator收到該區塊超過2/3的prevote，那麼validator會對區塊進行precommit；反之，則precommit為Nil。
上圖中有一對夫婦在跳polka（波卡）舞，validator做的事情就像在跳polka舞。當超過2/3的validators對提議的區塊進行了prevote，可以稱為一個Polka。每次precommit必須由同一round的Polka證明。
在precommit階段的最後，每個節點需要作出決定。若節點收到了超過2/3的precommit，那麼節點進入commit階段；否則，節點繼續進入下一round的propose階段。
因此，系統處於propose階段是由兩種條件驅動，一種是區塊被提交到鏈上後重新提交新的區塊，新的區塊高度+1；另一種是區塊提交失敗後重啟round，此時區塊高度不變。
此時，我們可以分析在共識過程中為什麼成功提交一個區塊可能需要多個round，原因有以下幾點：
· 選出的proposer不線上；
· proposer提議的區塊無效；
· proposer提議的區塊沒有及時傳播出去；
· 提議的區塊有效，但在到達Precommit階段前，validator節點沒有及時收到超過2/3的prevote。或者是，prevote超過2/3可以進入下一狀態，卻出現至少有一個validator投了Nil票或惡意投票；
· 提議的區塊有效，並且prevote超過了2/3，但是validator節點沒有收到超過2/3的precommit。
每個round開始期間，若validators在一個timeout時間內沒有收到提議，validators將透過投票來決定是否跳過當前的proposer。這種對超時的依賴使得Tendermint是一種弱同步協議，而不是一種非同步協議。但是，每個round在收到提議之後，就進入完全非同步模式，validators只能在取得超過2/3的共識後才能繼續往前。
Tendermint共識演算法可以容忍1/3以內的節點錯誤，這個錯誤包括節點離線和節點作惡。
在拜占庭節點數少於節點總數的1/3時，為了避免出現在同一區塊高度不同round分別提交兩個不同區塊的情況，Tendermint引入了鎖機制。Validators會被鎖定在其最近precommit的區塊上。當收到區塊超過2/3的prevote後，validators為該區塊進行precommit，validator即鎖定在該區塊上了。Validators節點每次最多隻能鎖定一個區塊，且只能prevote他們被鎖定的區塊，這樣可以阻止validators在上一round中precommit一個區塊，在下一round中又prevote另一個區塊，從而避免出現在同一區塊高度提交兩個不同區塊的情況。Validators只有看到更高round（相對於其當前被鎖定區塊的round數）的polka才能解鎖，該polka包括收到超過2/3的prevote或Nil prevote兩種型別的polka。
因此，如果拜占庭節點數少於1/3，基於Tendermint的區塊鏈永遠不會分叉。
上面說到，大部分的區塊鏈應用都是採用整體的設計方法，就是說，這些區塊鏈應用實現成單一的程式，一個程式實現了區塊鏈各層的所有功能，包括P2P連線，交易資料的處理和廣播，共識達成，具體的應用功能實現等等。
例如比特幣，一整套程式碼就實現了所有比特幣的功能。從軟體工程的角度來看，這種非模組化的設計是不合理的，這會使程式碼複用變得困難，程式碼的分支管理也變得複雜，同時還限制的區塊鏈應用開發使用的語言。
針對這個問題，Tendermint對區塊鏈的功能模組進行解耦，將共識和P2P部分從具體的區塊鏈應用狀態細節中分離出來，以適用各種分散式應用。
Tendermint由兩部分組成：區塊鏈共識引擎和通用的應用程式介面。
1. 共識引擎被稱為Tendermint Core，用於確保同一個交易在不同機器上記錄的順序相同。
2. 通用的應用程式介面也被稱為應用區塊連結口（Application Blockchain Interface，ABCI），其作用是使交易可以用任何程式語言進行處理。
Tendermint Core透過ABCI介面與應用層進行互動，應用程式可以用任何語言編寫，開發者可以很方便地開發自己的區塊鏈應用。
ABCI（Application Blockchain Interface）
Tendermint Core透過一個滿足ABCI標準的socket協議與應用程式進行互動。
ABCI 包含3 種訊息型別：DeliverTx訊息，CheckTx訊息和commit訊息。Tendermint Core將訊息傳送給應用，應用根據訊息進行相應的回覆。
DeliverTx 訊息是應用的主要工作流程。鏈上的每筆交易都透過這個訊息進行傳送。應用基於當前狀態、應用協議和交易的加密證書，驗證接收到 DeliverTx 訊息的每筆交易。然後，驗證後的交易會更新應用狀態。
CheckTx 訊息類似於 DeliverTx，但它僅用於驗證交易。Tendermint Core 的記憶體池首先使用 CheckTx 檢驗交易的有效性，並且只將有效交易廣播給其他節點。
Commit 訊息用於通知應用程式計算當前應用狀態的加密保證（cryptographic commitment），該加密保證會被放入下一個區塊頭部。
一個應用可能與多個ABCI socket 連線。Tendermint Core 給應用程式建立了三個 ABCI 連線：一個用於記憶體池廣播時的交易驗證，一個用於區塊提議時的共識引擎，還有一個用於查詢應用狀態。
總結
本文主要介紹了Tendermint共識演算法和ABCI介面。Tendermint是基於BFT的共識演算法，在錯誤節點不超過1/3的情況下，Tendermint保證安全永遠不會被破壞，系統不會在同一區塊高度提交衝突的區塊。
因此，區塊鏈永遠不會分叉。但是每個投票環節都需要得到超過2/3的validators的投票，在現實世界中有很大可能性系統真的會停止執行，這個問題還需要對應的解決方法。
更多區塊鏈資訊：www.qukuaiwang.com.cn/news
