《區塊鏈技術指南》筆記

對於多個服務節點，給定一系列操作，在約定協議的保障下，使得它們對處理結果達成「某種程度」的協同

傳統傳統分布式系統中討論一致性，往往是指在外部任意發起請求（如向多個節點傳送不同請求）的情況下，確保系統內大部分節點實際處理請求序列的一致，即對請求進行全域性排序

實際挑戰：

節點間網路通訊不完全可靠

節點處理請求的時間無法保障

同步呼叫課簡化操作，但擴充套件性低，拉低吞吐率

嚴格意義上共識演算法和上述的一致性不完全相同。一致性指多個副本對外呈現的狀態（如順序一致性、線性一致性）。而共識則特指分布式系統中多個節點之間對某個事情達成一致看法的過程，因此達成某種共識並不意味著就保障了一致性共識演算法解決的是分布式系統大部分節點對某個提案達成一致的過程實際挑戰：

如何提出乙個待共識的提案，如通過令牌傳遞等

如何讓多個節點達成共識

實際上上述兩點不好解決，因為系統中除了有「非拜占庭節點(不響應)」，還會有「拜占庭節點(可能偽造惡意響應)」

不允許拜占庭錯誤的叫做crash fault tolerance問題，允許的叫做byzantine fault tolerance問題，後者是區塊鏈的核心問題

bft問題的解決方案主要有兩類

pbft為代表的確定性系列演算法。一旦達成共識就不可逆轉

pow為代表的概率演算法，共識結果是臨時的，隨著時間推移，共識結果被推翻的概率越來越小而成為事實結果。

xft演算法：提供類似cft的處理響應速度，並能在大多數節點正常工作時提供bft保障

分布式系統的共識問題無通用解（flp不可能原理）

flp不可能原理：在網路可靠，但允許節點失效（即便只有乙個）的最小化非同步模型系統中，不存在乙個可以解決一致性問題的確定性共識演算法。所以不用浪費時間去試圖為非同步分布式系統設計面向任意場景的共識演算法。

二階段提交：

預提交：協調者發起提交某個事務的申請，各參與執行者需要嘗試進行提交並反饋是否能完成

正式提交：如果協調者得到所有執行者的成功答覆，則發出正式提交請求

三階段提交（paxos原型）：

嘗試預提交：協調者問執行者是否能提交，執行者只需要答覆無需執行

預提交：協調者檢查收到的答覆，如果全部為真，則發起提交事務請求，執行者執行並反饋

正式提交：如協調者如果得到所有執行者的成功答覆，則發出正式提交請求，如果成功完成則演算法執行成功

以上是兩種不同的解決拜占庭將軍問題的思路