详解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等密码算法进一步增加随机性；引入分组共识再次提升算法的可扩展性，以高效支持更多的验证节点加入，增加网络的安全性和容错性。