FISCO-BCOS 應用於區塊鏈的多節點並行拜占庭容錯共識算法
看了下微眾平台的wiki共識知識 學習下 （）內是自己的思考 參考： https://github.com/FISCO-BCOS/Wiki/tree/master/
問題與動機：PBFT是一種可用的拜占庭容錯算法，但是由於該算法的三個階段是串行執行，存在共識效率低的問題
提出的算法內容：
區塊鏈節點的角色有兩種，分別是“領導節點”和“隨從節點”。
- 領導節點：負責對交易進行打包成塊，把塊廣播給其他節點，通過共識過程對塊中所有交易進行確認，從而使得區塊鏈的區塊高度不斷增加。
- 隨從節點：負責接收從領導節點發送來的區塊，對區塊中的交易進行確認，所有交易都確認完畢就對該塊進行簽名驗證，從而使共識達成。
（其實這里和主備節點一樣）
角色變遷
在本算法中，節點的角色不是固定不變的，隨着時間遷移節點角色也會進行變遷。 區塊鏈網絡由一個個節點組成，假設一共有N個節點，對節點從0,1,2...N-1進行編號，每個節點對應一個唯一的Idx(i)。一個節點的角色判斷通過公式 （h+v）%N 來決定，其中h是區塊鏈當前塊高度，v是當前視圖
（這里關注2點：引入區塊高度做考慮，隨時間遷移會變）
共識過程
共識過程就是區塊鏈網絡對一批交易進行確認，並達到全網一致的過程。共識過程分為以下幾個階段：
- 選舉領導：通過3.2描述的算法推選出一個領導，有別於其他基於投票選舉領導的算法，在本專利中是通過共識計算選出合適的領導，這種方式具有更高的效率。
- 打包驗證交易：選舉出的領導節點，將會一批交易進行打包驗證，組成一個區塊，區塊的產生也就由領導節點負責。
- 簽名投票：隨從節點對領導節點發送來的區塊，進行每一筆交易確認驗證，全部通過之后發送對該塊的一個投票簽名。
- 落盤投票：所有節點在收到2/3以上節點的簽名投票之后，廣播落盤投票。
- 落盤提交：所有節點在收到2/3以上節點額落盤投票之后，把該塊進行落盤存儲。
（看到這里其實和PBFT沒有差別，流程沒有改變）
異常處理機制
在3.3的描述的共識過程幾個階段，每個階段都有可能因為出現錯誤、超時或者故意作惡等各種原因致使無法順利進入下一個階段，從而使共識無法達成。本專利引入異常處理機制解決這種問題。
把一次共識共識的全過程定義為一個視圖，所有階段需要在同一個視圖下完成。
當一個節點完成塊h的落盤存儲之后，意味着它就需要開始塊h+1的共識過程，此時會對塊h+1的共識設置一個超時器，當到達超時還未完成共識過程就會引起視圖切換過程。視圖切換的過程首先是將自己的視圖v++，然后把v全網廣播告知所有節點，如果收到2/3以上節點都有相同的視圖v切換請求，就順利切換到下一個視圖。
（這里描述的與下圖有區別，視圖切換v++的順序位置不同？）
並行機制
在3.3介紹的共識過程中，打包驗證交易和驗證交易分別是領導節點和隨從節點對交易進行確認的操作，這是整個共識過程中最耗時的環節（即多輪全廣播）。從圖中可以看出，打包驗證交易和驗證交易是串行執行的，首先要由領導節點完成打包驗證交易，隨從節點的驗證交易才能開始進行，假設交易確認耗時為T，其他過程總耗時為T’，那么整個共識的耗時就為2*T+T’。本專利對交易確認機制提出並行化的改進設計，整體共識耗時降為T+T’，大大提高了共識效率。
（並行設計細節很少，其實講的和變的就只是主節點驗證交易的時機，將其放在從節點驗證交易的時間段，實施並行）
（改動很少，全文講了這么多，其實和PBFT沒多少差別，只是最后改了下主節點驗證交易的時機，讓該步並行了）
（開始提出的問題是PBFT三個階段是串行的，然而本方法針對於這個問題實質還是沒有解決）
------------------------------------------------------------------------------
又看了該wiki下的漫談共識機制內容：
PBFT的記賬者在初始階段就是相對固定的，聯盟鏈里可以根據不同的場景來選擇記賬者，如機構之間線下協商、線上配置，也可以引入DPoS的思想，先通過一些選舉策略選出一批記賬者，但這樣在聯盟鏈里可能帶來額外的復雜性，如果商業場景需要，可以在既有基礎上開發PBFT-dPos。
（這個其實自己也早就考慮過，不過是考慮協議層，怎么通過環節來實施投票選舉，這里說的是可以靠線下解決投票問題，線上直接配置。因此動態性支持也很重要）
所以我們的實現是可動態配置式的記賬者列表，在具備共同利益的的聯盟鏈網絡里，所有或大部分機構都參與記賬，大家一起維護商業利益，如果某個機構在記賬過程中犯錯、作弊、或者不工作，都可以通過少數服從多數容錯，然后進行事后追責，保護大家的利益。
BFT算法的過程是一次提案，幾步提交，在這個過程中有復雜的狀態機維護的細節。起始時可按一些簡單的規則，如輪次機制，讓某一個機構的某一個節點在某個區塊高度上，成為議長，得到記賬權，然后進行記賬提案，其他節點對提案進行數據驗證（驗證簽名，驗證交易數據，驗證合約計算結果等），覺得都ok之后，返回一個簽名確認，議長收集大家的簽名，達到一定的數量后，認為達成少數服從多數的效果，則將記賬結果廣播出去，大家在將記賬結果存下來之前，還可以再進行一次投票和計票，確認大多數人都收妥了記賬數據並無異議，再將記賬數據存下來，開始下一輪。
（這里其實就是兩階段提交）
每次投票都有數字簽名，可以抗抵賴，不會投了票不認。
（這里使用的是簽名機制，場景下能否使用MAC優化？）
所以，PBFT相對公鏈的各種共識，可以理解成特定的已知身份的團隊內的快速達成一致的一種高效算法，特定團隊的形成也是至關重要的，所以會有PBFT-Auth(經過驗證的記賬人), PBFT-PoS,PBFT-DPoS等多種變化。是否需要在投票和容錯的部分進行常場景性的優化（如帶加權系數的投票，容錯由1/3改為1/2或者改為0容錯等等），要看場景需求，目前來看，保證有一個相對簡單，運行穩定的PBFT算法是首要的。
（這里講到PBFT與公鏈算法的變種，還有權重思想，和場景下的不同容錯需求，其實是對其模型做改變）
聯盟鏈還可以采用一種共識算法Raft，簡單的說可以理解成大家選出一個記賬者，如果它穩定運行沒有掛掉，就由他記賬，大家無條件接受他的記賬結果，相信他是誠實的，如果他掛掉了，那么大家是可以通過超時或網絡探測感知，然后快速啟動一輪投票，來選出一個新的記賬者，然后繼續無條件的等它記賬，這樣就達成了容錯性。
Raft適合用於專注解決可用性（保持系統穩定運行），追求相對較高效率（比優化后的PBFT大致高20~50%的效率）的場景，基本忽略欺詐可能，且對交易延時要求可以放寬（等待多次確認）。
為了在速度和抗欺詐之間獲得平衡，也有出現PBFT-Raft混用的共識，比如讓一個記賬者固定出塊，其他人極少輪次的投票，或者進行快速的后置檢測，如果發現Raft的記賬者在作惡，立刻回滾沖正，並踢掉並懲罰作惡的記賬者等等，這就有一些場景化的需求需要考慮了。
（混用是怎么用？可以自適應切換從Raft到PBFT嗎？要增加錯誤檢測識別能力，增加回滾機制，增加動態剔除機制）
共識算法的研究是很有意思的課題，我們也看到共識算法的選擇和演進，隱約和人類社會的不同階段是對應得上的。算法其實是社會里人和財產的關系在計算機世界的一種映射，研究共識算法，不僅是需要研究計算機理論（圖靈機時代，其實計算機也能體現人性），也要去深刻的理解社會學，經濟學，心理學，博弈論。
（共識是區塊鏈底層項目的一個靈魂與創新點，尤其是公鏈那種，聯盟鏈可以適用BFT，BFT的優化其實從PBFT下來做了快20年了，當然現在區塊鏈場景是新的。這些其它的考慮很重要，尤其是在沒有准入機制的開放場景。為什么需要共識，因為相互之間不可信，需要協議來規范，不管基於投票還是算力還是經濟利益，容錯總是存在上界的。權衡是設計特性場景下共識所需要考慮的，容錯能力與性能，CAP中的CA。另外，共識中的激勵其實很重要也很有效，區塊鏈助力了所有參與者貢獻者得到應有的分配和權益，激勵引導節點遵守協議，雖然公鏈上需要更多考慮，聯盟鏈也不能忽視）
-------------------------------------------------------------------------------------------------
看了下白皮書共識部分：
然后，我們對耗時較高，有次數冗余的計算過程進行了精簡，通過關鍵路徑優化，重復計算結果進行緩存等方式減少了共識過程中的每一步的耗時。
同時，我們對網絡健康度、節點存活等因素進行檢測，當發現有的記賬節點無法服務時，快速切換到下一個記賬節點，避免出現全體節點出現空等待的狀況。
最后，我們考慮到金融交易的場景常常有高峰期和空閑期的特點，在空閑期系統沒有交易流量的時候，共識機制進入心跳狀態，只維護網絡的健康狀態，不產生包含交易數為0的空區塊數據，避免不必要的存儲浪費，以及避免空區塊的同步流量和時間消耗。
（考慮高峰和低谷，這里是根據時間窗口出塊嗎？然后自適應變化窗口？）
相比RAFT論文提及的算法，我們還針對網絡抖動、網絡延遲以及網絡分區孤島異常情況進行一系列優化，使RAFT共識算法能夠滿足更極端的網絡環境。該RAFT算法具有N/2的容錯能力，只要一半以上節點就可以正常服務。
為了使聯盟鏈網絡具有更高的擴展性，RAFT共識算法結合智能合約支持節點動態增加和退出網絡，這也是該RAFT算法的一大亮點。
（結合智能合約的細節？）
國密算法改造
動機：國密算法自主可控
計划采用SM（公私鑰密碼算法，可實現數字簽名），SM3（摘要算法），SM4（對稱密碼算法）等幾個國密算法，對區塊鏈平台里牽涉到密碼的模塊全面進行改造升級
同時，我們也將引入基於國密的硬件加密機制，包括USBkey、加密機、智能卡等，以滿足各種金融場景需求。
（這里提到2點，國密改造，因為是國內的平台，基於國密硬件，國外是TPM可信平台模塊，國內也有自己的可信計算芯片和標准TCM可信密碼模塊）
另外還有多CA用於多中心認證