區塊鍊知識系列 - Raft 共識

Raft算法由斯坦福大學的Diego Ongaro和John Ousterhout于2014年在論文《In Search of anUnderstandable Consensus Algorithm》中提出。Raft算法面向對多個決策達成一緻的問題，分解了Leader選舉、日志複制和安全方面的考慮，并通過限制減少了不确定性的狀态空間。

典型的過程包括以下兩個主要階段：

• Leader選舉：開始所有節點都是Follower，在随機逾時發生後未收到來自Leader或Candidate消息，則轉變角色為Candidate，提出選舉請求。最近選舉階段（Term）中得票超過一半者被選為Leader；如果未選出，随機逾時後進入新的階段重試。
  • Leader負責從用戶端接收log，并分發到其他節點
• 同步日志：Leader會找到系統中日志最新的記錄，并強制所有的Follower來重新整理到這個記錄，資料的同步是單向的。
  • 此處日志并非是指輸出消息，而是各種事件的發生記錄。

共識算法以Raft為基礎的區塊鍊:

• Hyperledger Fabric
• Quorum : 企業級以太坊
• R3 Corda

Raft 概念

日志條目（Log entry）。 Raft 排序服務中的主要工作單元是一個“日志條目”，該項的完整序列稱為“日志”。如果大多數成員（換句話說是一個法定人數）同意條目及其順序，則我們認為條目是一緻的，然後将日志複制到不同排序節點上。

共識者集合（Consenter set）。主動參與給定通道的共識機制并接收該通道的日志副本的排序節點。這可以是所有可用的節點（在單個叢集中或在多個叢集中為系統通道提供服務），也可以是這些節點的一個子集。

有限狀态機（Finite-State Machine，FSM）。Raft 中的每個排序節點都有一個 FSM，它們共同用于確定各個排序節點中的日志序列是确定（以相同的順序編寫）。

法定人數（Quorum）。描述需要确認提案的最小同意人數。對于每個共識者集合，這是大多數節點。在具有五個節點的叢集中，必須有三個節點可用，才能有一個法定人數。如果節點的法定人數因任何原因不可用，則排序服務叢集對于通道上的讀和寫操作都不可用，并且不能送出任何新日志。

上司者（Leader）。這并不是一個新概念，正如我們所說，Kafka 也使用了上司者，但是在任何給定的時間，通道的共識者集合都選擇一個節點作為上司者，這一點非常重要（我們稍後将在 Raft 中描述這是如何發生的）。上司者負責接收新的日志條目，将它們複制到跟随者的排序節點，并在認為送出了某個條目時進行管理。這不是一種特殊類型的排序節點。它隻是排序節點在某些時候可能扮演的角色，而不是由客觀環境決定的其他角色。

跟随者（Follower）。再次強調，這不是一個新概念，但是了解跟随者的關鍵是跟随者從上司者那裡接收日志并複制它們，確定日志保持一緻。我們将在關于上司者選舉的部分中看到，跟随者也會收到來自上司者的“心跳”消息。如果上司者在一段可配置的時間内停止發送這些消息，跟随者将發起一次上司者選舉，它們中的一個将當選為新的上司者。

Raft 是如何選舉上司者的

盡管選舉上司者的過程發生在排序節點的内部過程中，但是值得注意一下這個過程是如何工作的。

節點總是處于以下三種狀态之一：跟随者、候選人或上司者。所有節點最初都是作為跟随者開始的。在這種狀态下，他們可以接受來自上司者的日志條目（如果其中一個已經當選），或者為上司者投票。如果在一段時間内沒有接收到日志條目或心跳（例如，5秒），節點将自己提升到候選狀态。在候選狀态中，節點從其他節點請求選票。如果候選人獲得法定人數的選票，那麼他就被提升為上司者。上司者必須接受新的日志條目并将其複制到跟随者。

往期精彩回顧:

區塊鍊知識系列

密碼學系列

零知識證明系列

共識系列

公鍊調研系列

比特币系列

以太坊系列

EOS系列

Filecoin系列

聯盟鍊系列

Fabric系列

智能合約系列

Token系列