• <option id="cacee"><noscript id="cacee"></noscript></option>
  • <table id="cacee"><noscript id="cacee"></noscript></table>
  • <td id="cacee"></td>
  • <option id="cacee"></option>
  • <table id="cacee"></table>
  • <option id="cacee"><option id="cacee"></option></option>
  • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
    <option id="cacee"><option id="cacee"></option></option>
     找回密碼
     立即注冊

    掃一掃,登錄網站

    首頁 百科 查看內容
    • 9734
    • 0
    • 分享到

    OFGP:開源網關協議實現跨鏈價值流通

    2018-11-1 10:26

    來源: 藍狐筆記

    OFGP的獨有共識機制:Braft


    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進行反饋。
    相關新聞
    發表評論

    請先 注冊/登錄 后參與評論

      回頂部
    • <option id="cacee"><noscript id="cacee"></noscript></option>
    • <table id="cacee"><noscript id="cacee"></noscript></table>
    • <td id="cacee"></td>
    • <option id="cacee"></option>
    • <table id="cacee"></table>
    • <option id="cacee"><option id="cacee"></option></option>
    • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
      <option id="cacee"><option id="cacee"></option></option>
      妖精视频