數字貨幣交易所繫統開發(海外版)丨數字貨幣交易所開發(原始碼版)

xiaofufu發表於2023-02-21

共識模組主要由幾個元件組成,世代epoch、提案訊息快取服務msgcache、共識訊息處理引擎engine、共識訊息驗證器verifier、提案訊息儲存服務forest、投票處理器voter、共識活務pacemaker、wal儲存wal、節點間共識資訊同步服務compensator、各模組相互配合實現maxbft流水線共識演演算法。

epoch:共識執行過程中由一個個epoch組成,每個epoch包含一組共識節點、在預定的檢視範圍內由這些共識節點生成提案、投票共識資訊、驅動共識執行;每個epoch的最後一個提案初始化下一個epoch的資訊,當前epoch最後一個提案被提交上鍊後觸發世代切換

msgcache:開發詳細I35原始碼7O98案例O7I8  檢查網路中接收的提案訊息是否缺失祖先提案,快取缺失祖先提案的訊息、並觸發請求獲取缺失的提案

engine:處理世代內接收到的共識訊息

verifier:實現了共識訊息的提案、投票驗證規則

forest:快取驗證過的提案資訊、並維護共識的各種QC狀態genericQC、lockedQC、finalQC

voter:快取驗證過的投票資訊、實現提案的投票規則

pacemaker:共識活務,使用接收到的QC、提案、超時資訊,推進節點的共識狀態

wal:在共識過程中儲存驗證過的共識訊息

compensator: 共識內部的同步服務,傳送、處理獲取缺失提案的請求

hotstuff-投票處理
6.5.2. pacemaker 狀態推進機制
pacemaker 提供了共識演演算法的活性,當某次共識view共識未達成一致、或共識訊息處理完成後,使用相應的結果推進pacemaker維護的節點共識狀態、並設定相應的超時器;因此共識的狀態由兩種資訊推動:

共識資訊:提案、投票組成的QC資訊;當檢視V+1的follower接受檢視V的提案後,使用提案資訊驅動pacemaker進入V+1的共識狀態,當檢視V+1的Leader接受檢視V的提案後,設定超時器、進入投票收集階段,使用投票聚合的QC資訊驅動pacemaker進入V+1的共識狀態

超時資訊:超時器有等待提案、等待投票兩種型別,當節點進入一個新檢視後,設定接受提案型別的超時器,當節點作為檢視proposal.View+1的Leader時,接受提案proposal後進入投票超時階段;無論何種超時時間被觸發都將驅動pacemaker進入下一個新檢視

超時時間在[MaxBFTRoundTimeoutMill, MaxBFTMaxTimeoutMill] 範圍內波動,透過最新提交的提案檢視finalView與當前設定超時的檢視currView確定當前超時型別的時間;演演算法為:timeOut = currView - finaView <= 4? MaxBFTRoundTimeoutMill : MaxBFTRoundTimeoutMill + MaxBFTRoundTimeoutIntervalMill * (currView - finalView - 4)

公示中常量為4的原因:一個區塊的提交需要滿足three-chain規則(即當前區塊後接三個子孫塊v+1, v+2, v+3),又因實現中設定超時器時滿足three-chain的提案還未被提交(即finalView還未更新),因此正常無超時情況下currView - finalView 最大的間隔應為4

6.5.3. epoch 切換機制
epoch機制為maxbft共識演演算法提供了增刪共識節點的功能,每個epoch建立時基於當前鏈配置合約chainconfig的共識節點狀態初始化該epoch參與共識的節點資訊,當前epoch的最後一個提案建立下一個epoch的狀態,當最後一個提案被提交後觸發epoch切換,同時丟棄當前epoch在該提案後的所有生成的子孫塊,由於epoch切換屬於耗時的重量型操作,基於效能與功能的trade-off,因此每個epoch預分配一定數量的執行檢視,僅在當前epoch的檢視執行結束時,才基於最新的鏈配置生成下一個epoch的資訊;epoch執行期間配置交易導致鏈配置變更不會立即反應在共識的epoch配置中。

6.5.4. 配置引數
MaxBFTRoundTimeoutMill:共識狀態初始超時時間;示例:”5000”

MaxBFTRoundTimeoutIntervalMill:每次超時後下一輪共識增加的delta時間;示例:”2000”

MaxBFTMaxTimeoutMill:超時時間上限;示例:”15000”

MaxBftViewNumsPerEpoch:每個世代的執行的檢視數量;示例:”50”

6.6. DPoS
DPoS(Delegated Proof of Stake)委託權益證明共識演演算法,類似於公司董事會制度,在DPoS共識制度下,會選出一定數量的節點,來負責生成、驗證區塊。節點的選舉根據節點質押的權益來進行,被選出來的節點代表其他所有的節點進行小範圍共識出塊。正常生產區塊的節點可以獲得額外的權益激勵,但如果節點不履行生產區塊的職責,或者作惡,會被剔除出去,並且依據事先設定的懲罰規則進行懲罰(如扣除質押的部分權益)。

DPoS共識是由DPoS委託質押演演算法、TBFT拜占庭共識演演算法組合實現的;DPoS委託質押演演算法負責節點的權益質押、驗證人集合的選舉、激勵、懲罰這些操作,TBFT共識演演算法負責對Proposer生成的區塊進行驗證,保證大多數驗證者節點對區塊達成一致;

chainmaker【v1.2.0+版本】的DPoS共識實現是基於證書體系構建的,所以新節點準備參與共識過程時,除了DPoS共識自身所需的權益質押,還需要使用證書體系的管理機制(即:系統配置合約的操作),將新節點新增到網路中。

DPoS共識中,設定指定數量區塊的區塊構成一個世代,每個世代包含一批從候選人中依據質押的權益選舉出來的驗證者,作為世代的驗證者集合,每個驗證者輪流作為Proposer進行出塊,其它不出塊的驗證者對Proposer生成的區塊進行TBFT共識,保證大多數驗證者對該區塊達成一致,每個世代的最後一個區塊選舉下一個世代的驗證者集合,並將選舉結果寫入區塊以便其它驗證者節點進行校驗。因此在區塊鏈上存在三種節點:普通節點、候選人節點、驗證人節點;普通節點透過質押一定數量的權益資產,成為候選人節點,每個世代的最後一個區塊,依據候選人質押的權益,選舉一批節點作為下一個世代的驗證者集合。

candidates
Note

【chainmaker v1.2.0】的DPoS共識僅支援levelDB儲存引擎

【chainmaker v1.2.0】未實現區塊激勵、作惡懲罰,僅支援共識節點的增刪、質押/解質押功能


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69956839/viewspace-2936090/,如需轉載,請註明出處,否則將追究法律責任。

相關文章