OFGP的共識機制是基于Raft上改進的算法，稱之為BFT RAFT算法（Byzantine Fault Tolerant Raft），簡稱為Braft算法。
Raft算法是基于leader選舉的一種協議。Raft有leader、follower和candidate三種角色，這些角色是可以相互轉換的。
通過加入BFT的改進，Braft可實現網關多個節點的一致性，同時也提供容錯性，包括一般性的網絡故障，如節點不能工作，以及拜占庭故障等。目前的設計是在節點數量為3f+1的網絡中，失效節點數為f，網絡仍然可以保持正確運行。
Braft節點也有跟raft類似的leader、follower、candidate三種角色，同時它把時間劃分為term，而不是系統時鐘。每個term期間從選舉leader開始，選出leader后進行請求消息同步。如果當前term沒有可用的leader，會進入新的term。
不同節點之間通過RPC進行通信，其中有兩個核心的RPC：RequestVote和AppendEntries。RequestVote RPC由candidate節點發送給其他節點，請求其他節點為自己投票。如果某個candidate節點獲得了多數票，則該candidate角色轉變為leader角色。AppendEntries PRC則是由leader節點發送給其他節點，一是提供心跳機制，證明其還在工作；另外就是用戶復制log。
Braft共識算法的核心之一是選舉leader，那么leader是如何選出來的？Braft的選舉跟raft算法類似，當leader宕機或廣播假消息，節點會對leader進行校驗，同時廣播校驗結果。當所有節點收集到其他節點發過來的異常校驗結果，一旦收集的節點數達到f+1，就會觸發leader的選舉。觸發leader選舉后，candidate開始向其他節點發送RequestVote RPC的投票請求，節點獲得足夠的票數（2f+1），candidate即可轉換成為leader角色。為驗證合法性，新leader當選后需要向其他節點展示自己的投票信息。
當leader選舉完成后，節點如何同步共識？Leader主要負責打包區塊并廣播出去。
區塊打包過程有三種狀態，一是廣播狀態，節點校驗本地term以及區塊高度，確認交易并廣播有效消息；二是驗證狀態，一旦驗證通過的節點數達到2f+1（總節點數為3f+1），則信息被確認為有效。最后是上鏈提交狀態。節點達成驗證狀態，被2f+1節點確認后，就可以廣播區塊上鏈，同時開始添加新區塊。
在Braft協議中，節點是動態加入或退出，但節點的加入或退出必須得到大多數節點的認可。
節點加入前需要設置引導節點，通過引導節點獲取所有節點信息。新節點向所有節點廣播自己的加入請求信息，leader收到加入請求后，會把下一個區塊設置為Reconfig類型，用于節點信息的變更；而其他節點收到加入請求后，會等待leader信息的Reconfig區塊。一旦Reconfig區塊共識達成，各節點把新節點信息加入到集群信息。同時，為了防止任意節點加入集群，新節點加入前需要在集群節點加上自己的host和pubkey信息，只有通過集群節點的校驗后才能發起加入請求。
節點的退出也需要通知其他節點。節點廣播退出請求后，leader會把下一個區塊設置為Reconfig類型，其他節點開始等待leader的Reconfig區塊。一旦Reconfig類型的區塊共識完成，各節點把該節點的標記為退出。
最后需要關注的一點是交易過程存在異常情況的處理：比如leader創建的交易輸入和輸出作弊、leader不發起交易、不同節點之間的全節點不完全同步、雙花、網絡異常（發送簽名失敗或交易上鏈失敗等）。OFGP針對這些異常情況，有自己的解決方案，這里不再詳述。
其他需要關注的點
在OFGP協議中需要客戶端，比如錢包來操作網關交易。用戶通過錢包可以完成充值和回兌的請求。充值本質上就是在主鏈上發起一筆交易。不過，在交易過程中，還需要用戶提供側鏈地址。此外，構造交易數據時，需要按照OFGP協議的數據格式填充相關的側鏈地址信息。
還有一點是關于私鑰管理。signer負責解鎖主鏈代幣及側鏈發幣的簽名。這里涉及到維護多重簽名地址的私鑰管理。為了兼顧安全和實用，OFGP采用了私鑰隔離加密存儲、私鑰生成及簽署服務獨立運行，并通過私鑰代理服務層對整體業務流程提供簽名數據輸出服務。
版權申明：本內容來自于互聯網，屬第三方匯集推薦平臺。本文的版權歸原作者所有，文章言論不代表鏈門戶的觀點，鏈門戶不承擔任何法律責任。如有侵權請聯系QQ：3341927519進行反饋。
