FBFT

FBFT 简要流程

在 PBFT 一文中，提到了 PBFT 的缺点——网络复杂度高（O(n^2)）,一旦节点数量变多，网络复杂度会变得异常的高，不适合节点多的区块链。

F（Fast）BFT 则是试图将其降至O(n)。降低的思路也非常清晰，在PBFT中是由各个节点同时对外广播自己签名后的信息，在FBFT中各个节点则是将信息统一发送给Leader，由Leader整合后再发换给节点们，由此降低了复杂度。

img.png

简单的步骤如下：

  1. Announce 阶段，leader 打包区块，广播给所有的 Validator 节点；
  2. Prepare 阶段，Validator 验证消息并对区块哈希进行签名，将签名包统一发送给 leader节点，leader 节点收集到 2/3 个签名包之后，做聚合签名，广播给其他节点；
  3. Commit 阶段，Validator 验证收集到的聚合签名包，验证通过后将 commit 包转发给leader节点，leader 收集到 2/3 的 commit 签名包后，聚合签名后广播给其他节点，节点校验通过后执行交易并提交区块。

其中涉及了一个数学工具：BLS（Boneh–Lynn–Shacham）多重签名，起到了聚合签名的作用：

1）s1 = 加密（m1，p1），加密s2 = （m2，p2），加密s3 = （m3，p3）；

2）s = s1+s2+s3，（m1，m2，m3）=解密（s，pk1，pk2，pk3）

视图切换

基于BFT的共识的一个缺点是，如果leader是拜占庭节点，可能会导致共识停滞。

PBFT算法中针对此问题的解决方案是在共识之上增加额外的视图切换协议，能够在共识停滞时切换leader。PBFT中的视图切换在传统分布式系统环境下运作良好，但在更复杂的区块链空间中并不一定特别优秀。特别地，在PBFT中，视图切换依赖超时机制，在该机制下计时器根据共识进展实时情况触发。如果节点始终在线并与共识进度同步，则这种方式有效。然而，在现实世界情况下这并不成立，因为节点可能长时间宕机或由于机器崩溃重新启动，这将使节点具有不一致的视图ID，并无法在视图切换过程中取得进展。

我们通过使用基于本地时钟而非假设节点活跃性完全同步化的改进版本视图切换协议来解决这个问题。具体来说，与其根据共识实际进展设置validator节点的视图ID不如根据最后成功提交区块时间戳经过时间计算出该ID。当然，在时间计算中没有全局时钟可供依赖。每个validator将使用自己本地时钟进行计算即可。只要超过2/3以上validator保持相对准确、未漂移数秒内部本地时钟即可达到目标。

此项协议允许validator定期将其本地时钟与NTP时间进行同步。

此次优化使我们所采用的视图切换协议完全强大和功能齐备, 只要超过2/3以上非拜占庭节点在线, 就可以保证 FBFT 共享存活性. 此外, BLS 聚合签名也被应用到了 视图切换协议 中以减少网络通信成本, 使其成为一个非常高效率的流程。