區塊鏈底層平臺PlatONE的共識算法機制IBFT及其實現方法是怎樣的

本篇文章為大家展示了區塊鏈底層平臺PlatONE的共識算法機制IBFT及其實現方法是怎樣的，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

一、概述

由萬向區塊鏈和生態合作伙伴聯合打造的支持隱私計算的區塊鏈聯盟鏈“PlatONE”中的共識為高度優化的BFT類共識算法，其容錯率為1/3，在保留即時確認（instant finality）的關鍵特性的同時，極大地提高了去中心化的程度。共識可以保證上鏈的區塊是確定的，也就是說鏈不會出現分叉，同時每一個有效的區塊都會插入到鏈上。

PlatONE的共識支持超過100個共識節點。相對于其他一些常見的BFT共識，PlatONE 的共識的性能有顯著的提升。在10個共識節點的情況下，TPS接近1000。

PlatONE的共識運行的相關參數可以靈活地進行配置，并且PlatONE的共識中的共識節點集合可以靈活地進行更新。近期計劃支持共識的插件化，以及共識的可審計性等。

PlatONE共識是在 round 上進行的。在特定的 round 上，通過預先設置的策略選取一個出塊者節點。出塊者節點的選取策略目前支持兩種：round robin 和 sticky proposer。

出塊者節點提議區塊后，各共識節點進行共識。共識分三階段，其中后兩個階段為投票階段，用以保證 Safety。PlatONE 共識使用 round change 機制結合鎖定和解鎖機制來保證共識的的 liveness 。通過優化解鎖機制，解決了業界多個知名項目內存在的共識死鎖問題。

PlatONE 共識會為每一個鏈上的區塊生成共識證明，也就是對于該區塊的各共識節點的有效簽名，因而區塊可以進行自驗證，同時也能支持輕節點。

區塊中如果不包含交易，則稱為空區塊。PlatONE 目前支持不出空區塊，也就是上鏈的區塊中都含有交易。不出空區塊的機制可以有效地節省區塊鏈占用的存儲空間。

以下具體介紹 PlatONE 中的共識算法。

二、共識節點選取機制

• 節點的類型和狀態

節點分為共識節點（validator）和觀察員節點兩種類型。對于共識節點來說，存在兩種狀態：正常和隔離。只有處于正常狀態的共識節點才可以參與共識和打包區塊。

• 共識節點的選取機制

節點管理（NodeManager）系統合約設計用于存儲和管理節點信息。可以通過節點申請（NodeRegister）系統合約申請注冊共識節點，審核通過后，申請節點的類型會更新為共識節點，更新后的節點信息存儲在節點管理合約中，并且可被查詢。

管理員可以根據需要更新共識節點的狀態，來決定共識節點是否可以參加共識。

• 共識節點集合的獲取

鏈上每次產生新區塊后，節點管理合約中最新的節點信息都會被讀取，并且最新的共識節點集合會被保存下來，并被共識引擎讀取和使用。

三、共識流程

3.1. 正常流程

3.1.1. 定義

以下是一些重要術語或概念的定義。

• +2/3 表示"超過 2/3".

• NEW ROUND: 新的round中會確定一個新的區塊提議者（比如采用round robin算法），在新的round開始時，各共識節點等待接收PRE-PREPARE消息。

• PRE-PREPARED: validator節點接收到了PRE-PREPARE 消息，同時廣播PREPARE消息之后進入這種狀態。之后，validator節點等待并接收+2/3的PREPARE 或 COMMIT 消息。（注：有的validator節點因鎖定在提議區塊上，會在收到PRE-PREPARE 消息后直接廣播COMMIT 消息。因此，這里validator節點等待并接收PREPARE 或 COMMIT 消息）

• PREPARED: validator節點接收到了+2/3的PREPARE消息，同時廣播COMMIT消息之后進入這種狀態。之后，validator節點等待并接收+2/3的 COMMIT 消息。

• COMMITTED: validator節點接收到了+2/3的COMMIT 消息，進入到這種狀態。此時，可以將提議的區塊插入到區塊鏈上了

• FINAL COMMITTED: 新的區塊成功上鏈后，validator節點進入到這種狀態。此時，節點準備進入下一個round

• ROUND CHANGE: validator節點等待接收+2/3的、針對同一個提議round的ROUND CHANGE消息

3.1.2. 選取proposer的規則

• Round robin 算法（目前采用的）

• Sticky proposer

3.1.3. 共識流程（三階段協議）

共識流程由三個階段組成：PRE-PREPARE, PREPARE 和COMMIT，也稱為三階段協議。

• PRE-PREPARE階段: 每次進入到一個新的round時，就會開始三階段中的第一個階段，即PRE-PREPARE階段。在該階段中，Proposer（區塊提議者）節點生成一個提議區塊，并廣播給所有的validator節點。接著Proposer節點進入到PRE-PREPARED狀態。其他validator 節點接收到有效的 PRE-PREPARE 消息后進入到PRE-PREPARED 狀態。

• PREPARE階段: 在這一階段，validator 節點廣播PREPARE消息給其他validator 節點，并等待接收+2/3 的有效的 PREPARE 消息從而進入到PREPARED狀態。

• COMMIT階段: 在這一階段，validator 節點廣播COMMIT 消息給其他validator 節點，并等待接收+2/3 的有效的 COMMIT 消息從而進入到 COMMITTED 狀態。

以上三階段完成后，整個共識流程就成功完成了。

3.1.4. 狀態遷移:

下圖描述了PlatONE的共識流程的狀態遷移過程。

• NEW ROUND -> PRE-PREPARED: (對應于2.1.3節中的PRE-PREPARE階段)

• Proposer從txpool中收集交易。

• Proposer生成一個提議區塊并廣播給其他validator節點，接著就進入到PRE-PREPARED 狀態。

• 每一個validator節點接收到滿足如下條件的PRE-PREPARE 消息后，進入到PRE-PREPARED狀態：

• 提議區塊來自于有效的proposer節點。

• 區塊頭有效

• 提議區塊的sequence（高度）和round和validator節點的當前狀態一致。

• Validator節點廣播PREPARE 消息給其他validator節點。

• PRE-PREPARED -> PREPARED: (對應于2.1.3節中的PREPARE階段)

• Validator接收到+2/3 的有效的 PREPARE 消息，從而進入到PREPARED狀態。有效的消息需要滿足如下條件：

• sequence 和 round 相一致

• 區塊哈希一致

• 消息來自于已知的validator節點

• Validator 節點在進入到PREPARED狀態后，廣播COMMIT消息。

• PREPARED -> COMMITTED: (對應于2.1.3節中的COMMIT階段)

• Validator接收到+2/3 的有效的COMMIT 消息，從而進入到COMMITTED 狀態。有效的消息需要滿足如下條件：

• sequence 和 round 相一致

• 區塊哈希一致

• 消息來自于已知的validator節點

• COMMITTED -> FINAL COMMITTED:

• Validator節點將+2/3的commitment簽名（committed seal）添加到區塊頭的extraData字段中，并嘗試將區塊插入到區塊鏈中。

• 區塊上鏈成功后，Validator節點進入到FINAL COMMITTED 狀態。

• FINAL COMMITTED -> NEW ROUND:

• 各Validator節點選取出一個新的proposer節點，并啟動一個新的round定時器。

3.2. Round change 機制

以下三種條件都會觸發ROUND CHANGE:

• Round change定時器超時觸發

• 無效的PREPREPARE消息

• 區塊上鏈失敗

3.2.1. round change 的流程

• 當一個validator節點檢測到以上round change觸發條件之一滿足時，將會廣播ROUND CHANGE消息，其中包含要變更到的目標round數值，同時等待接收來自其他validator節點的ROUND CHANGE消息。目標round的數值基于以下條件選取：

• 如果validator節點已經從其他peer節點接收到了 ROUND CHANGE 消息，則從所有數量達到F + 1 的ROUND CHANGE 消息中包含的round數值中選取出最大的那個數值

• 否則，將目標round的數值設置為：當前的round數值+1

• 任何時候，如果一個validator節點接收到了F + 1 條含有相同的目標round數值的 ROUND CHANGE 消息，就會將該round數值和其自己的進行比較。如果接收到的數值更大，validator節點就再次廣播ROUND CHANGE 消息，而消息中的round數值和接收到的相同。

• 一旦validator節點接收到了2F + 1 條帶有相同round數值的 ROUND CHANGE 消息，則結束round change循環，確定出新的proposer節點，之后進入到NEW ROUND狀態。

• 觸發validator節點退出round change循環的另外一個條件是其通過p2p同步機制同步到驗證后的區塊。

3.3. 區塊鎖定機制

• 鎖定區塊的觸發條件

節點鎖定在區塊B、round number R 的含義是指，當前節點只能對區塊B的信息投commit票 。當一個節點收到了+2/3個對區塊B的PREPARE投票后，進入PREPARED狀態。此時，節點被鎖定，等待接收其他節點的commit投票信息，鎖定的round即當前round；

• 鎖定區塊的機制

除了共識起始階段，當收到更高區塊的同步數據時，或當前高度成功產生區塊并達成共識時，鎖定被狀態重置為非鎖定狀態，并開始新一輪對更高區塊共識。如未能在鎖定期間收到+2/3個指定round和區塊的commit投票，則觸發ROUND CHANGE。并且，在特定場景下，原有鎖定解鎖機制還會出現死鎖的情況，我們在代碼層面也優化了相關的解鎖實現。具體可參考「2. 對Istanbul鎖定解鎖機制的優化」。

3.4. Consensus proof 目前的存儲機制

區塊上鏈前，每個validator節點需要收集2F + 1個committed seal以構成一個consensus proof（共識證明）。一旦validator節點接收到足夠的committed seal，就會將其存儲于區塊頭的extraData字段中IstabulExtra結構中CommittedSeal 字段中，并重新計算extraData字段，然后將區塊插入到區塊鏈中。

Committed seal計算過程如下：

• Committed seal的計算:

每個validator節點使用其私鑰對區塊哈希級聯上commit消息代碼COMMIT_MSG_CODE的結果進行簽名，得到簽名即為Committed seal：

• Committed seal: SignECDSA(Keccak256(CONCAT(Hash, COMMIT_MSG_CODE)), PrivateKey)

• CONCAT(Hash, COMMIT_MSG_CODE): 將區塊哈希和commit消息代碼COMMIT_MSG_CODE 進行級聯

• PrivateKey: 進行簽名的validator節點的私鑰

• 上面提到的extraData是區塊頭的一個字段，其數據組成為：EXTRA_VANITY | ISTANBUL_EXTRA，其中|用以表示分隔EXTRA_VANITY和ISTANBUL_EXTRA的固定的索引（不是一個實際的分隔字符）。

• IstabulExtra結構的類型定義如下：

  type IstanbulExtra struct {
  Validators    []common.Address    //Validator addresses
  Seal          []byte          //Proposer seal 65 bytes
  CommittedSeal [][]byte            //Committed seal, 65 * len(Validators) bytes
  }

其中，各字段的含義如下： + Validators：參與共識的各validator節點的列表 + Seal：Proposer 節點對區塊的簽名，長度為65字節 + CommittedSeal：用于存儲validator節點收集到的committed seal列表。

上述內容就是區塊鏈底層平臺PlatONE的共識算法機制IBFT及其實現方法是怎樣的，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。