Fabric中的RAFT共識算法

• 什麼是共識算法
• • Hyperldger Fabric的不同
  • Fabric中的共識算法之Raft
  • • 節點狀态
    • 主導節點的選舉
    • 日志複制
  • OSN(Ordering Service Node)的Raft排序實作
  • Raft和PBFT的對比

什麼是共識算法

共識機制(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。

節點狀态

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

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

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

主導節點的選舉

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

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

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

1. 此節點勝出成為主導節點。
2. 其他節點勝出成為主導節點。
3. 沒有節點勝出。

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

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

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

日志複制

每個節點都包含一個儲存狀态的狀态機，而當一旦選出主導節點，leader就開始處理用戶端的請求。請求中包含有狀态機需要執行的複制指令。主導節點将指令追加到自己的日志中，然後并行發送AppendEntriesRPC消息給所有跟随節點複制這個新的日志項。當新的日志項被安全複制後，主導節點會在自身的狀态機上執行這個日志項裡的指令，并将結果傳回給用戶端。

如果跟随節點崩潰、運作緩慢或網絡發生丢包問題，主導節點會無限重試發送AppendEntries RPC消息（即使它已經向用戶端傳回了響應結果），直到所有的跟随節點最終得到一緻的日志副本。

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

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

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

其工作流程如下：

1. 交易請求應當自動發送通道的目前主導節點。
2. 主導節點檢查交易驗證的配置序列号是否與目前配置序列号一緻，如果不一緻的 話則執行驗證，并在驗證失敗後駁回交易。
3. 通過驗證後，主導節點将收到的交易傳入區塊切割子產品的Ordered方法，建立候選區塊
4. 如果産生了新的區塊，主導排序節點将其應用于本地的Raft有限狀态機（FSM）
5. 有限狀态機将嘗試複制到足夠數量的排序節點，以便送出區塊
6. 區塊被寫入接收節點的本地賬本

每個通道(channel)都會運作Raft協定的單獨執行個體。換句話說，有N個通道的網絡，就有N個Raft叢集，每個Raft叢集都有自己的主導排序節點。

Raft和PBFT的對比

對于 raft 算法，核心共識過程是日志複制這個過程，這個過程分兩個階段，一個是日志記錄，一個是送出資料。兩個過程都隻需要上司者發送消息給跟随者節點，跟随者節點傳回消息給上司者節點即可完成，跟随者節點之間是無需溝通的。是以如果叢集總節點數為 n，對于日志記錄階段，通信次數為 n-1，對于送出資料階段，通信次數也為 n-1，總通信次數為 2n-2，是以raft算法複雜度為O（n）。