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进行反馈。
