详解 Giskard 共识算法的优化思路

PlatON 的 Giskard 共识协议由概率性权益证明 PPoS( PlatON proof of stake ) 和 Giskard 拜占庭容错协议-Giskard BFT( Giskard Byzantine Fault Tolerance ) 组成。PPoS 使用质押、委托、随机选取的形式选出参与共识的验证节点，Giskard BFT 使用类 BFT 算法实现区块的生产和验证。

本次专题，我们会做两期技术科普。第一期简单介绍 PPoS 共识和 BFT 理论，并分析 PBFT 算法特性。第二期将重点分析 Giskard BFT 借鉴 PBFT、Tendermint、Hotstuff 等共识协议的演进之路。

在上期文章中，我们介绍了 PPoS 共识和 BFT 理论，并以 PBFT 算法在区块链共识的应用为例，详细分析了 PBFT 的共识流程和视图切换流程。

本期，我们将介绍 PBFT 存在的一些问题和瓶颈，之后详解 Giskard BFT 借鉴 PBFT、Tendermint、HotStuff 等共识协议的演进之路，详细分析 Giskard BFT 的优化思路。

PBFT 存在的问题

通过对 PBFT 共识流程三阶段的详细分析，可以看到消息传输的开销很大。系统在尝试达成状态共识时，涉及到 n 个节点都需要广播消息到 n-1 个其它节点，因此算法通信复杂度达到 O(n²)，在节点数目为 1000 的情况下所需要交换的通信量为 1,000,000。有实验得出当节点数量超过 20 时，算法的性能会急剧下降。

另外，在 PBFT 选举 Leader 的过程中，有可能经过多轮交互，选举出的 Leader 一直长时间运行，直到 Leader 节点出现故障才发起视图切换流程。但在区块链系统中，视图 view 表示一个共识单元，共识过程由一个接一个的 view 组成，每个 view 中由一个确定的提议人来主导共识协议，产生区块，其余验证人对区块进行投票签名达成共识。因为节点产生区块与利益相关（如记账权，区块奖励等），因此需要频繁地更换出块节点，也就是需要频繁地切换视图 view，这势必会带来巨大的网络资源消耗。

Giskard BFT 共识优化

所以我们基于 BFT 协议，结合区块链的特性，主要围绕着以下几点进行协议优化，设计了 Giskard BFT 。

_ view-change 流程优化_

所有的 BFT 协议都通过 view-change 来更换主节点。PBFT，SBFT 等协议具有独立的 view-change 流程，当主节点出问题后才触发。而在 Tendermint、HotStuff 等协议中没有显式的 view-change 流程、view-change 流程合入正常流程中，因此提高了 view-change 的效率，将 view-change 的通信复杂度降低。

Giskard BFT 也是基于 view 的的共识协议，为降低通讯复杂度，Giskard BFT 也没有显式的 view change 流程，而是把这个流程和正常出块流程结合。Giskard BFT 约定每个提议节点在本视图内连续产生 10 个区块，并且每个区块都达成 QC （Quorum Certificate，表示节点收到针对该区块的 2*f+1 个签名）状态后，则自动切换到下一个 view ，不需要单独的 view-change 投票流程。

下图是显式的 ViewChange 流程，可以看到它并没有类似 PBFT 中的 view-change-ack 和 new-view 阶段，这两个流程被后续的 prepareQC(n) 进行代替。

Giskard BFT viewchange 投票流程

总结一下，view-change 流程优化的两个重点：

不需要显式的 view change 流程，减少投票动作。

没有 view-change-ack 和 new-view 阶段，而是结合区块链特性，由后续的 prepareQC(n) 对新的 view 进行「间接」确认。

_ 应用 BLS 聚合签名_

为了进一步减少消息通讯量，我们采用了聚合签名技术。业界主流的聚合签名方案是 BLS 聚合签名。BLS 聚合签名是在 BLS 签名方案基础上的扩展方案。

在 Giskard BFT 中，我们把针对 block 和 view-change 消息的多个节点签名聚合成一个签名，可以简单地理解为：把多个节点的一段很长的签名「压缩」为一个签名。这种做法极大地降低了通讯量，对提高协议的通信效率也起到了很大的作用。

_ 区块生产和验证并行化_

此处优化是 Giskard BFT 的独到创新之处。这里的并行指的是：区块生产和区块验证的并行化。

上文提到，Giskard BFT 是基于视图 view 的共识协议，每个提议节点在本视图内连续产生 10 个区块，并行流程如下：

提议节点在一个 view 内可以连续提议多个区块，下一个区块的产生不用等上一个区块达到 QC 状态。

验证人在接收上一个区块投票的同时，可以并行执行下个区块的交易。

这种做法极大提高出块速度，也提高了系统的共识性能。

引进 pipeline 方式对区块进行确认

在传统 BFT 主导的区块链系统中，每个区块的共识通常都需要经历明确的 Pre-Commit 和 Commit 阶段才最终确认：

Pre-Commit ：当节点收到 2*f+1 个 Prepare 投票时会广播 Pre-Commit，Pre-Commit 可以看作对 Prepare 阶段的确认。

Commit ：当收到 2*f+1 个 Pre-Commit 投票时，表明所有节点对指定消息达成一致，提交到本地磁盘。

Giskard BFT 中的每个区块只有 Prepare 投票，没有明确的 Pre-Commit 和 Commit 阶段，那么区块如何达到最终的确认呢？Giskard BFT 可看作 Pipeline 版本的 BFT ，每个 prepareQC 都是对前面区块更高阶段的确认。

Giskard BFT 的区块确认流程

如图所示 prepareQC(2) 作为 Block(1) 的 Pre-Commit 阶段 prepareQC(3) 作为 Block(1) 的 Commit 阶段，Block(2) 的 Pre-Commit 阶段。

简单来说，就是「省略」了 PBFT 的 Commit 阶段，这里读者可能有疑虑：前文不是明确给出结论，必须通过三阶段消息才能达成一致性？其实 Giskard BFT 不是真的没有 Commit 阶段，而是结合区块链特性，将下一个区块的 QC 状态作为上一个区块的 Commit 间接确认。

Giskard BFT 结合区块链的链式结构，引进 pipeline 方式对区块进行确认，使得协议变得简洁而优美，能够很好地进行流程化作业，提高了协议的性能，另外也对协议的可扩展性留足了设计空间。

结语

目前，应用了 Giskard 共识协议的 PlatON 测试网、主网和 Alaya 网络都已经长时间稳定、高效运行，它的安全性（safety）和活跃性（liveness）得到了充分的验证，同时 Giskard 共识对解决系统过于中心化，降低网络通信复杂度、消息复杂度，提升共识效率以及整个区块链的交易处理性能所起到的作用毋庸置疑。

在后期的协议版本中，我们将继续深入优化：验证人的选取不仅采用 VRF，还计划结合可验证秘密分享 PVSS、BLS 等密码算法进一步增加随机性；引入分组共识再次提升算法的可扩展性，以高效支持更多的验证节点加入，增加网络的安全性和容错性。