什么是共識演算法

共識機制(consensus)是所有區塊鏈專案中最基礎最根本的成份之一，從簡單方便理解的角度來說，可以理解為一種能夠保證保持網路中所有賬本(ledger)或節點交易的同步和記錄一致的機制，就是共識機制，

共識演算法各有不同，各有側重點且各有利弊，在一個分布式網路結構中會有各種各樣的例外情況，譬如惰性節點，主機崩潰，無回應和最惡劣的惡意節點，有的演算法對惡意節點的攻擊有比較強的防御例如PBFT((Practical Byzantine Fault Tolerance)就能在最多三分之一的節點腐化后依然保持出賬結果一致，而有的在低延時和高吞吐量方面表現極佳，但總的來說，所有共識演算法都有一個共同點，就是只會在交易雙方都確認后才進行更新，同時在賬本更新時，交易雙方能夠在賬本中的相同位置，更新一個相同的交易資訊，

Hyperldger Fabric的不同

Hyperledger Fabric與其他區塊鏈系統最大的不同體現在私有和許可，與開放無需許可的網路系統允許未知身份的參與者加入網路不同（需要通過PoW等演算法來保證交易有效并維護網路的安全），Hyperledger Fabric通過Membership Service Provider(MSP)來登記所有的成員，且很多聯盟鏈產品都選用此開源平臺作為基石，

Hyperledger Fabric也提供了多個可拔插選項，賬本資料可被存盤為多種格式，共識機制可被接入或者斷開，同時支持多種不同的MSP，

Hyperledger Fabric提供了建立channel的功能，這允許參與者為交易新建一個單獨的賬本，當網路中的一些參與者是競爭對手時，這個功能變得尤為重要，因為這些參與者并不希望所有的交易資訊——比如提供給部分客戶的特定價格資訊——都對網路中所有參與者公開，只有在同一個channel中的參與者，才會擁有該channel中的賬本，而其他不在此channel中的參與者則看不到這個賬本，

Fabric中的共識演算法之Raft

每種共識機制都有它的用武之地，在聯盟鏈的環境下，節點的加入都是經過審核和批準的，所以大大降低了惡意節點的風險，即只有在這種環境下Raft才能使用，因為它是不能防范惡意節點攻擊的，類似的演算法還有Kafka，Zookeeper和大名鼎鼎的Paxos，PBFT的數學模型論證了若有n個惡意節點，那么系統必須至少包含3n+1個節點來保證結果一致，那么就意味著整個系統更加復雜，而Raft則是在有n個節點發生非拜占庭故障，譬如宕機，網路中斷，系統崩潰無回應師，系統僅需要2n+1個節點即能保障順利運行，大大降低了網路復雜度和部署成本，所以在聯盟鏈這樣一個惡意節點存在可能性很小的生產環境下才能使用Raft，

節點狀態

跟隨狀態(follower)：初始情況下，所有的節點都處于跟隨狀態，也就是都是跟隨節點，一旦某個跟隨節點沒有正常通信，它就轉換為候選狀態（Candidate），也就是成為一個候選節點，跟隨節點的日志可以被主導節點重寫，
候選狀態(candidate)：處于候選狀態的節點會發起選舉，如果它收到集群中大多數成員的投票認可，就轉換為主導狀態，
主導狀態(leader)：處理客戶端請求并確保所有的跟隨節點具有相同的日志副本，主導節點不可以重寫其自身的日志，

任期(Term) 是一個單調遞增的整數值，用來標識主導節點的管理周期，每個任期都從選舉開始，直到下一個任期之前，

如果候選節點發現已經選出了主導節點，它就會退回到跟隨狀態，同樣，如果主導節點發現另一個主導節點的任期（Term）值更高，它也會退回到跟隨狀態，

主導節點的選舉

整個選舉通訊是建立在心跳機制之上的，當一個節點啟動后是自動變為初始狀態即跟隨者，當follower能從leader或者candidate那里接受到有效的心跳資訊就會一直維持在跟隨狀態中，而leader也會一直周期性的給所有跟隨節點發送心跳資訊來維持主導地位，當某個跟隨節點在一段時間內沒有收到心跳訊息時，就發生選舉超時事件，該節點就認為目前沒有主導節點并發起選舉來選出新的主導節點，

當一個跟隨節點發起選舉時，它會遞增其任期term并且將狀態變化為candidater，然后首先給自己投一票，同時向其他節點發送請求投票的訊息(RequestVote RPC訊息)，

而候選節點會一直維持候選狀態直到出現以下情況：

此節點勝出成為主導節點，
其他節點勝出成為主導節點，
沒有節點勝出，

若該節點收到大部分節點的投票認可，就可以勝出選舉，那么該節點就轉換到主導狀態成為新的主導節點（每個節點只能投一票），

若同時也有其他節點宣布自己是主導節點并有更高的任期值，那么任期值高的節點成為新的主導節點，

如果多個候選節點的得票情況相同，那么沒有勝出節點，要避免出現這種情況，可以重新初始化選舉并確保每個節點的選舉超時時長是隨機的，以避免跟隨節點同時進入候選狀態，

日志復制

每個節點都包含一個保存狀態的狀態機，而當一旦選出主導節點，leader就開始處理客戶端的請求，請求中包含有狀態機需要執行的復制命令，主導節點將命令追加到自己的日志中，然后并行發送AppendEntriesRPC訊息給所有跟隨節點復制這個新的日志項，當新的日志項被安全復制后，主導節點會在自身的狀態機上執行這個日志項里的命令，并將結果回傳給客戶端，

如果跟隨節點崩潰、運行緩慢或網路發生丟包問題，主導節點會無限重試發送AppendEntries RPC訊息（即使它已經向客戶端回傳了回應結果），直到所有的跟隨節點最終得到一致的日志副本，

當發送AppendEntries RPC訊息時，主導節點會同時發送新日志項的前序日志項的序號和任期值，如果跟隨節點在自身日志中沒有發現相同的序號和任期值，就會拒絕新的日志項，因此如果pendEntries成功回傳，主導節點就知道跟隨節點的日志與自己是完全一致的，當出現不一致情況時，主導節點強制跟隨節點復制自己的日志，

OSN(Ordering Service Node)的Raft排序實作

每個OSN都有其自己的Raft復制狀態機來提交日志，客戶端利用Broadcast RPC發送交易提議后，Raft排序節點基于共識生成新的區塊，當對等節點發送Deliver RPC時，將區塊發送給對等節點，

其作業流程如下：

交易請求應當自動發送通道的當前主導節點，
主導節點檢查交易驗證的配置序列號是否與當前配置序列號一致，如果不一致的話則執行驗證，并在驗證失敗后駁回交易，
通過驗證后，主導節點將收到的交易傳入區塊切割模塊的Ordered方法，創建候選區塊
如果產生了新的區塊，主導排序節點將其應用于本地的Raft有限狀態機（FSM）
有限狀態機將嘗試復制到足夠數量的排序節點，以便提交區塊
區塊被寫入接收節點的本地賬本

每個通道(channel)都會運行Raft協議的單獨實體，換句話說，有N個通道的網路，就有N個Raft集群，每個Raft集群都有自己的主導排序節點，

Raft和PBFT的對比

RAFT和PBFT的對比
對于 raft 演算法，核心共識程序是日志復制這個程序，這個程序分兩個階段，一個是日志記錄，一個是提交資料，兩個程序都只需要領導者發送訊息給跟隨者節點，跟隨者節點回傳訊息給領導者節點即可完成，跟隨者節點之間是無需溝通的，所以如果集群總節點數為 n，對于日志記錄階段，通信次數為 n-1，對于提交資料階段，通信次數也為 n-1，總通信次數為 2n-2，因此raft演算法復雜度為O（n），

轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/296670.html

標籤：區塊鏈

上一篇：以太坊系列 - Web3.js

下一篇：NFT科普 | 淺談NFT投資邏輯與生態布局