第四章 系統架構
4.3 共識模組架構
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
共識，只收到新的區塊卻沒收到該區塊的證明，該節點必須向其他節點要求它看到的 區塊證明，如果的確收到該區塊的證明，則可以將之提交⾄區塊鏈，反之則驗證失 敗。
4.3 共識模組架構
本章節介紹我們實作拜占庭容錯共識的架構與機制。如圖 3.3，共識模組底下包含處理 訊息的 message handler、同步訊息的 synchronizer、與三個主要做共識的模組，
ConsensusManager、HeightManager 與 RoundManager。
‧
引擎需要交換彼此的資訊才能完成共識，所以在引擎中加⼊此 message handler。由於 以太坊在原本使⽤共式引擎的基礎上也有⾃⼰定義的通訊協定，所以此 message 執⾏共識，必須先與其他節點同步到最新狀態，所以需要 Synchronizer 進⾏這動作。透過來⾃其他節點的資訊，判斷⽬前共識進⾏到何階段，
每當有新的區塊需要共識時，區塊會經過三個主要結構完成共識，分別是
ConsensusManager、HeightManager、RoundManager，共識引擎在收到需要共識的區塊 與資訊後，會將區塊交給這三個模組進⾏共識。底下我們介紹這三個共識模組如何完 成共識與其流程，圖 3.3 描述上述幾個模組的互動流程。
• ConsensusManager：
主要功能是管理 HeightManager，以及區塊鏈本⾝與資料庫的各種資訊。
ConsensusManager也負責處理與其他節點交換的各種資訊，再將收到的資訊向下 交給 HeightManager 處理，同時也要將需要廣播的資訊交給 message handler。另外
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
需要傳遞的訊息需要簽章，也是交給 ConsensusManager 執⾏。ConsensusManager 也會判斷該節點的共識是否落後，如果有落後的情況發⽣，會呼叫 Synchronizer，
進⾏同步。
• HeightManager：
此模組主要功能是處理某⼀個⾼度的共識，透過管理⼀或多個 RoundManager 與 其他節點進⾏共識。HeightManager 也要處理來⾃於 ConsensusManager 的訊息，
將訊息交給對應的 RoundManager，或是蒐集各 RoundManager 的資訊，再交給
ConsensusManager廣播或簽章。每個 HeightManager 只負責⼀個⾼度的區塊共 識，當其負責的⾼度共識完成時，ConsensusManager 就會等下⼀個⾼度的共識開 始，在建⽴另⼀個 HeightManager。
• RoundManager：
每個⾼度會需要⼀到多個回合，HeightManager 會建⽴⼀到多個 RoundManager 來 進⾏共識。RoundManager 會蒐集來⾃ HeightManager 的訊息，經過判斷後再廣播 該回合的票 （詳細演算法會在第四章介紹）。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 3.3 共識引擎模組關係
我們透過上⾯提到的幾個模組，完成整個引擎的架構。當到⼀個新的⾼度時，以 太坊會透過 miner 模組建⽴⼀個新的區塊，將其傳給 ConsensusManager 開始做共識。
Consensus建⽴該區塊的⾼度的 HeightManager 與 RoundManager 後就可以透過 message handler與其他節點溝通。如果在其間有節點落後，可以透過 Synchornizer 與 message
handler傳遞落後的訊息，讓該節點達到相同的⾼度，以繼續共識。當有共識完成時，
以太坊會發出通知告訴其他節點有新的區塊產⽣，以太坊會呼叫共識引擎判斷該區塊 是法合法，這時由於 BFT 共識引擎必須將該區塊的證明也廣播給其他節點，讓其他節 點也可以驗證該區塊，並將其提交到⾃⼰的區塊鏈上。