2.5 Tendermint
Tendermint[3]為⼀種拜占庭錯誤容忍的複製狀態機，且假設是 partial synchrony 的環境
6，其參考了 [6] 與 [10]。它的概念是每個共識的回合之中根據預先定好的規則，選出 稱作 proposer 的節點由 proposer 負責提案這⼀回合要達成的共識(例如⼀個含有若⼲個 交易的區塊)，再由其他節點投票決定是否採⽤此共識，必須超過三分之⼆的節點投票 通過才能達成共識。但因為可能有錯誤或惡意的節點存在，共識可能要幾回合後才能 達成。每個回合會執⾏以下的步驟，如圖 2.5。
1. Propose：Proposer 在此階段提出⼀個 Proposal，並廣播給其他節點。
2. Prevote：每個節點會透過傳遞 Prevote 訊息，告訴其他節點⾃⼰收到的 Proposal資訊。
3. Precommit：如果節點收到超過 2/3 以上的 Prevote，都投給同⼀個
Proposal，則代表該 Proposal 得到認可，傳遞 Precommit 訊息給其他節點，
代表準備提交。
4. Commit：如果節點收到超過 2/3 以上的 Precommit，都投給同⼀個
Proposal，表⽰有 2/3 以上的節點已經準備提交 Proposal，該節點就會進⾏
提交動作。
Tendermint與 PBFT 有許多相似的部分，其對於區塊的共識⼀樣是進⾏兩次的投 票階段來確認。兩個演算法主要的不同在於 Tendermint 利⽤了 Lock 的概念與 PoLC (Proof-of-Lock-Change) 來維護系統的安全性（safety）與活性（liveness）。節點在
6
網路延遲有⼀個上限，但是該上限無法得知，但訊息保證會在時間到上限之內到達。來⾃於
[12] 。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Prevote某個區塊之後會進⼊ Lock 狀態，代表其之後只能繼續將 Prevote 投給該 Lock 住的區塊。但是如果節點可能拿到錯誤的區塊，如果沒有⼀個機制讓節點能夠改變它 的選擇，可能會影響安全性。當收到的區塊包含 PoLC，即代表該區塊有⾄少 2/3 以上 的節點同意該區塊的正確性（2/3 以上的 Prevote），也代表這個區塊在當前⾼度是⼤
部份節點的選擇。所以當有節點已經進⼊ Lock 在某⼀區塊，但是在看到包含 PoLC 的 區塊，必須改變其 Lock 的狀態，⽀持包含 PoLC 的區塊。
(圖⽚來源：https://tendermint.com/intro/consensus-overview)
Figure 2.5 Tendermint 共識流程圖
‧
Proposer，由其建⽴與廣播⼀個區塊後，當其他節點收到區塊後可以進⼊ Vote 階段，
即是以投票來表⽰⾃⼰收到的區塊是哪⼀個。最後每個節點蒐集完節點之間的訊息投 票之後進⾏檢驗，如果有超過三分之⼆的票投給同⼀個區塊，則進⾏提交；如果沒 有，但是有超過三分之⼀的票投給同⼀個區塊，下⼀個 Proposer 可以提出
VotingInstruction，讓其他節點投給此區塊；如果沒有任何區塊得到超過三分之⼀的 票，則下⼀位 Proposer 可以重新建⽴⼀個新的區塊。與 Tendermint 的差別在於，
Hydrachain經過第⼀階段的投票過後，會直接檢查投票結果，即⽐ Tendermint 少了⼀
個投票階段。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
有收到超過三分之⼆以上的票在同⼀個區塊，並不會提交任何區塊，⽽且對於節點
4，其收到的⿊⾊區塊的票還⽐紅⾊區塊的多，造成之後有可能會提交與紅區塊不同的 區塊。如此結果可能會造成區塊鏈的安全性，即節點提交出不同的區塊，導致分⽀出 現，⽽分⽀出現也造成共識節點分散，也威脅到了整個網路的活性。
也由於 Hydrachain 可能會發⽣安全性與持續性的問題，所以我們對其演算法進⾏
改進，最後改進為相似於 Tendermint 的演算法。
Figure 2.6 Hydrachain 演算法⼤綱
Figure 2.5描述 Hydrachain 演算法的⼤綱
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 2.7 Hydrachain 可能導致之共識問題
2.6 Istanbul BFT
Istanbul BFT為另⼀個實作拜占庭容錯演算法於 Go-Ethereum 的區塊鏈平台，其拜 占庭容錯演算法同樣參考了[6]，也參考了 Tendermint。其共識演算法步驟如 2.8 所
⽰，基本上與 PBFT 相似，會經過三個階段為⼀回的步驟進⾏共識，分別是 Pre-Prepared、Prepared、Committed。與 PBFT 不同的地⽅在於 Istanbul BFT 沒有 view-change的概念，⽽是當回合共識失敗時，會直接開始⼀個新的回合，並提出新的區 塊，且每個回合的 Proposer 也是輪流替換。由於每個回合並不會參考其他回合的共識
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
結果，所以如果有區塊在 Pre-prepared 有達到共識，但是沒有在該回合進⾏ Commit，
則該區塊就會被捨棄，浪費了其共識結果。
另外 Istanbul BFT 也參考了 Go-Ethereum 另⼀個共識⽅式 Clique，利⽤ Clique 機 制中將區塊鏈可以做共識的名單記錄在區塊上，可以進⾏未來進⾏新增或修改的動 作。
（圖⽚來源：https://github.com/ethereum/EIPs/issues/650）
Figure 2.8 Istanbul BFT 共識流程圖
‧
● Validator：能夠參與共識的節點我們稱為 Validator。
● Vote：Vote 為⼀種訊息，在共識期間節點之間會互相廣播 Vote。此外分為兩種型
‧
合所要進⾏共識的區塊，我們稱 Proposer 其所需提出的訊息為 Proposal。Proposal 有兩種型態 NewBlock 與 VotingInstruction。我們以 ProposalX, H, R, u(B)
表⽰此‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
■ Quorum(LocksetPrecommit, H, R’, u
)
不存在。3.2 共識流程
每次 R 的共識的流程主要分為四個階段分別是：
1. Propose 2. Prevote 3. Precommit 4. Commit
圖三描述出四個流程之間的順序與關係。以下我們分別解釋每個節點在這四個階段需 要進⾏的規則與步驟。
Figure 4.1 共識流程圖
‧
3.2.1 Propose
Propose 是每個回合開始的第⼀步驟，每次回合開始時都會從 Validators 選出⼀位 Proposer 來提出 Proposal。因為 Proposer 所提出的 Proposal 與區塊關係到整個共識結 果，可以說是在整個共識過程中很重要的決定，我們以 Round-Robin 的⽅式讓
Validators循環擔任 Proposer，才不會讓提出 Proposal 的權⼒掌握在某⼀個 Validator ⼿ 上。由於每次回合開始時，每個 Validators 都會知道這個回合是哪⼀個 Validator 當 Proposer，所以也可以防⽌⾮ Validators 提出其他 Proposal 混淆。
3.2.2 Prevote
Prevote 階段是各節點之間確認區塊正確性的投票階段。每個節點依照收到的 Proposal 進⾏投票。
對於節點 u 在第 H ⾼度、第 R 回合會遵守以下規則：
‧
3.2.3 Precommit
Precommit 階段是各節點透過上⼀個步驟的投票結果，判斷各節點收到的 Propoal 與區 塊是否相同並且透過廣播 VotePrecommit, H, R, u
(B)
將結果告知其他節點。‧
3.2.4 Commit
Commit 階段是各節點根據上⼀個步驟的投票結果，判斷是否可以進⾏提交區塊的動 作。
對於節點 u 在第 H ⾼度、第 R 回合會遵守以下規則:
• 收集 Precommit 直到 LocksetPrecommit, H, R, u合法。
• 等待直到 TimeoutPrecommit的時間，讓 LocksetPrecommit, H, R, u蒐集更多
Precommit
。• 如果存在 Quorum(LocksetPrecommit, H, R, u
) = B
，則提交區塊 B ⾄區塊鏈上完成⾼度 H 的共識。
• 如果 Quorum(LocksetPrecommit, H, R, u
)
不存在，則進⼊第⼀階段 Propose 且令回 合為 R+1。3.3 Timeout
共識中的 Timeout 會隨著 R 的增加進⾏指數型成⾧其成⾧公式為：
Timeout
X, R= Timeout
X* TimeoutFactor
R其中 X 為 Propose、Prevote 或 PrecommitTimeoutX則為每個 timeout 在 R=0 的起始值。
此⽬的為讓整個網論在傳遞訊息時可能的延遲不會成⾧的⽐ Timeout 時間還快，讓整 體網路可以處於 partial synchrony 的環境。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
假設網路中有 F 個節點為拜占庭錯誤節點且整個網路有 N = 3F+1 個節點。當某⼀
節點在第四步驟成功提交⼀個區塊 B 時代表他已經收到⾄少 2F+1 個 Precommit 投給
B，也代表⾄少 F+1 個誠實節點已經有 Quorum(LocksetPrevote
) = B
的共識。在這個狀況 下如果有令⼀個區塊 B’被提交成功代表有另外 F+1 個誠實節點有Quorum(Lockset
Prevote) = B’
，那整個網路就會與先前的假設 N = 3F+1 產⽣⽭盾。3.5 活性（Liveness）
假設有⅓ N 以上的節點存在不同的 Quorum(LocksetPrevote
)
，則 Proposer 所提出的Proposal
VotingInstruction, H, R, u(B)
會指⽰收到此訊息的節點投給其區塊，讓整個網路的Prevotes
收斂⾄其中該區塊。‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第四章 系統架構
本論⽂透過詳盡研究以太坊提供的開放源碼與徹底理解 Hydrachain 共識演算法，採⽤
重構(Refactoring)的⼿法，就以太坊的架構與演算法的特性實作出模組化的共識引擎。
再依實作過程的發現，反饋與修正現有的共識演算法。並設計效能評估實驗，執⾏效 能評估實驗蒐集實驗數據，檢討實作或架構，進⾏必要的精進步驟以推出具 BFT-like 共識引擎的以太坊版本。⽬前以太坊有許多實作版本，本研究選擇 Golang 版本，稱為 Go Ethereum (geth)，是⽬前實作最完善也最多⼈使⽤的版本 ，以下提到的以太坊即指 Go-Ethereum。
4.1 以太坊基本架構
‧
NetWork。其中 BlockChain 實作區塊鏈的核⼼技術包含區塊、區塊鏈、交易與它們的 驗證機制，以及狀態資料庫等實現區塊鏈主要功能的部份。
由於原本以太坊就是以 PoW 為主，包含其共識⽅法、驗證機制原本是分布在不同 的模組底下，包含 Blockchain 模組與 Miner 模組。在 1.6 版本以後，開發⼈員新增了⼀
個 Consensus 模組，讓開發⼈員可以實作不同的共識機制。此模組包含了⼀個共識機 制介⾯，開發⼈員透過實作該介⾯所定義的函式，可以與其他模組溝通。當區塊要進
⾏驗證，或是如何取得共識的內容皆會在此模組底下。 Blockchain 模組或是 Miner 模 組可以透過呼叫共識引擎的介⾯取得該共識機制的演算法。⽬前此模組包含⼯作量證 明機制（ethash）與 Clique。Clique 為⼀種透過授權⽅式進⾏的共識機制，主要⽤於以 太坊的公有測試網路。NetWork 處理節點與節點之間的訊息包括如何傳遞交易、區塊 如何與其他節點同步等。除了上述核⼼架構之外以太坊最重要的⼀項技術即是可以透 過 EVM(Ethereum Virtual Machine) 執⾏智能合約，以便鏈上每個節點執⾏相同程式得 到相同結果，提供使⽤者以智能合約建⽴去中⼼化的應⽤程式。
我們的主要⽬標在於取代以太坊中的⼯作量證明共識機制，改⽤⽐較適合聯盟鏈 需求的 BFT-like 共識演算法。但有鑒於不同類型（偏同步與⾮同步）的 BFT-like 算法 有不同的優缺點，我們透過將 BFT-like 共識演算法實作於 Consensus 模組，建⽴⼀個 新的共識引擎，最⼩化對其他模組的影響。
‧
的 BlockProposal Hash、Height、Round，也包含 Validator 的簽章。l PrecommitVote：當進⾏ Precommit 階段時需要傳遞的訊息結構，表⽰該節 點已經準備進⼊ Commit 階段，PrecommitVote 包含該節點所要提交的 Proposal Hash、Height、Round，也包含 Validator 的簽章。
l Lockset：儲存 Vote 的結構，包含多個 Vote，每個回合會有⼀個 Lockset 去
‧
l PrecommitLockset：儲存 PrecommitVote 的結構，包含多個 Vote，每個回合 會有⼀個 Lockset 去儲存 PrecommitVote。Lockset 也要負責判斷其是否包含 Quorum。
l BlockProposal：BlockProposal 包含⼀個要進⾏共識的區塊、當前進⾏的共 識 Height 與 Round。BlockProposal 可能會包含⼀個 Lockset 或
PrecommitLockset，以證明⾃⼰所提出的 BlockProposal 是合法的。
l VotingInstruction：VotingInstruction 包含⼀個要進⾏共識的區塊、當前進⾏
的共識 Height 與 Round，且也包含⼀個 Quorum 的 Lockset 以證明此區塊已 經經過超過 2/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。