PlatON元網路Alaya於10月24日正式啟動，一經啟動，便贏得了使用者廣泛關注，作為全球下一代隱私計算架構與資料資產計算基礎設施的「先行示範區」，Alaya運用了怎樣的底層技術？如何支撐起未來大規模應用的部署？我們將分幾期內容詳解Alaya的底層技術。在Alaya中，我們提出了一種基於部分同步假設情形下的並行拜占庭容錯協議，解決區塊鏈共識效率的問題，基於此我們延展出了全新的共識協議，我們稱之為Giskard共識協議。這裡分析了PBFT，Tendermint，Hotstuff等共識協議，Giskard共識協議綜合了其優點，透過pipeline的方式完成區塊生成和確認的並行，在一個檢視視窗內可以出多個塊，並可以在O(n2)內完成檢視視窗切換，從而提高共識效率。按照分散式系統理論，分散式系統的網路模型分為三類：· 同步網路模型：節點所發出的訊息，在一個確定的時間內，肯定會到達目標節點· 非同步網路模型：節點所發出的訊息，不能確定一定會到達目標節點· 部分同步網路模型：節點發出的訊息，雖然會有延遲，但是最終會到達目標節點同步網路模型是十分理想的情況，非同步網路模型是更為貼近實際的模型，但據FLP不可能[1]原理，在非同步網路模型假定下，共識演算法不可能同時滿足安全性（safety）和活躍性（liveness）。目前的BFT類共識演算法多是基於部分同步網路模型假定。我們也是基於部分同步網路模型假定來進行討論。BFT共識協議一個分散式系統是由多個節點組成，節點之間需要網路傳送訊息通訊，根據它們遵循的協議在某個任務訊息達成共識並一致執行。這個過程中會出現很多型別的錯誤，但它們基本上可以分為兩大類。第一類錯誤是節點崩潰、網路故障、丟包等，這種錯誤型別的節點是沒有惡意的，屬於非拜占庭錯誤。第二類錯誤是節點可能是惡意的，不遵守協議規則。例如驗證者節點可以延遲或拒絕網路中的訊息、領導者可以提出無效塊、或者節點可以向不同的對等體傳送不同的訊息。在最壞的情況下，惡意節點可能會相互協作。這些被稱為拜占庭錯誤。考慮到這兩種錯誤，我們希望系統始終能夠保持兩個屬性：安全性(safety)和活躍性(liveness)。· 安全性：在以上兩類錯誤發生時，共識系統不能產生錯誤的結果。在區塊鏈的語義下，指的是不會產生雙重花費和分叉。· 活躍性：系統一直能持續產生提交，在區塊鏈的語義下，指的是共識會持續進行，不會卡住。假如一個區塊鏈系統的共識卡在了某個高度，那麼新的交易是沒有迴應的，也就是不滿足liveness。BFT(拜占庭容錯協議)是一種即使系統中存在惡意節點也能保證分散式系統的安全性和活躍性的協議。根據Lamport[2]的經典論文，所有BFT協議都有一個基本假設：節點總數大於3f時，惡意節點最大為f ，誠實節點可以達成一致的正確結果。PBFT實用拜占庭容錯演算法（PBFT[3]）是現實世界裡首批能夠同時處理第一類和第二類錯誤的拜占庭容錯協議之一，基於部分同步模型，解決了之前BFT類演算法效率不高的問題，將演算法複雜度由節點數的指數級降低到節點數的平方級，使得拜占庭容錯演算法在實際系統應用中變得可行。目前區塊鏈中使用的BFT類共識協議都可以認為是PBFT的變形，與PBFT一脈相承。1. 正常流程PBFT正常流程如下所示（圖1中C為客戶端，系統中有編號分別為0～3的四個節點，且節點3為拜占庭節點）:
正常流程為3階段協議：
· pre-prepare：主節點（Primary）廣播預準備訊息（Preprepare）到各副本節點（Replica)
· prepare：該階段是各個節點告訴其他節點我已經知道了這個訊息，一旦某個節點收到了 包含n-f 個prepare訊息（我們將使用QC也就是Quorum Certificate來指代，下同）則進入prepared狀態
· commit：該階段是各個節點以及知道其他節點知道了這個訊息，一旦某個節點收到了n-f 個commit訊息（QC）則進入committed狀態
2. 檢視切換流程
檢視切換（viewchange）是PBFT最為關鍵的設計，當主節點掛了（超時無響應）或者副本節點集體認為主節點是問題節點時，就會觸發ViewChange事件，開始viewchange階段。
此時，系統中的節點會廣播檢視切換請求，當某個節點收到足夠多的檢視切換請求後會傳送檢視切換確認給新的主節點。當新的主節點收到足夠多的檢視切換確認後開始下一檢視，每個檢視切換請求都要包含該節點達到prepared狀態序號的訊息。
在檢視切換過程中，我們需要確保提交的訊息序號在整個檢視更改中也是一致的。簡單來說，當一個訊息定序為n，且收到2f+1個prepare 訊息之後，在下個檢視中，依然會被分配序號為n，並重新開始正常流程。
如圖2所示，viewchange會有三個階段，分別是view-change，view-change-ack和new-view階段。從節點認為主節點有問題時，會向其它節點傳送view-change訊息，當前存活的節點編號最小的節點將成為新的主節點。當新的主節點收到2f個其它節點的view-change訊息，則證明有足夠多的節點認為主節點有問題，於是就會向其它節點廣播。
參考文獻
[1] M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of distributed consensus with one faulty process,”J. ACM, 1985.
[2] L. Lamport, R. Shostak, and M. Pease. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 4(3), 1982.
[3] M. Castro and B. Liskov. Practical byzantine fault tolerance. In OSDI,1999.
