前面的内容中，我们分析了BFT共识协议的问题，以及几种主流的优化BFT共识协议，这些BFT共识协议在降低通信复杂度和出块效率方面都取得了不错的研究成果，但仍存在一些改进空间。
· PBFT较之于之前的BFT算法虽更实用，但因受制于O（n³）的视图切换开销，在扩展性方面存在很大的问题。
· Tendermint将round change和正常流程合并，简化了视图切换逻辑，将视图切换的通信复杂度降低为O(n²)，但需要等待一个比较大的网络时延来保证活跃性。同时Tendermint仍然是串行出块和确认，一个区块的投票需要等上一个区块commit完成才能开始。
· EOS的BFT-DPOS共识协议中，区块生产者可以连续产生若干区块，同时区块采用并行确认，提高了出块速度。使用BFT协议确认出块，但仅适用于强同步的通信模型。
· HotStuff创新地提出了基于leader节点的、三阶段提交的BFT共识协议，吸收了Tendermint的优点，将viewchange和正常流程合并，并将viewchange的通信复杂度降至线性。同时通过简化消息类型，可以以pipeline的方式确认区块。但引入了新的投票阶段也会增加通信复杂度，同时一个视图窗口只确认一个区块，这无疑需要耗费较多的通信复杂度在视图切换上。此外，基于Leader节点收集投票的星状拓扑结构，比较适合于Libra这种网络环境良好的联盟链，在弱网环境中比较容易受单点故障影响，造成较大的leader节点切换开销。
因此，我们提出了Giskard共识协议，在以上共识协议的基础上进行进一步的优化，可以极大地降低通信复杂度，并且提高出块效率。
Giskard共识协议概述
Giskard共识协议基于部分同步网状通信模型，提出了一个三阶段共识的并行拜占庭容错协议。网状的通信模型更适合公网的弱网环境，在Alaya上已经使用了该协议作为共识算法。
Giskard共识协议的正常流程和Hotstuff类似，分为prepare，pre-comit，commit和decide几个阶段。但Giskard还作了关键的改进：在一个视图窗口内可以连续提议多个区块，下一个区块的产生不用等上一个区块达到QC；而且各个节点可以在接收上一个区块投票的同时，并行执行下个区块的交易，以pipeline的方式对区块进行投票确认，从而极大提高了出块速度。
Giskard共识协议有自适配的视图切换机制：在一个视图窗口内，节点接收到足够多的区块以及赞成票（超过2/3的节点投票，也就是 QC）时，会自动进行窗口切换，切换到下一个窗口，无需进行viewchange投票。只有时间窗口超时后，节点才会启动viewchange流程，并且在viewchange阶段引入了和Hotstuff一样的二阶段锁定投票规则，同时使用BLS聚合签名，可以在O(n²)的通信复杂度内完成视图窗口切换。
根据上面的讨论，Giskard共识协议只在正常流程之外才会进行viewchange，因此相比HotStuff会有更少的视图切换开销。
接下来先给出Giskard共识协议共识中涉及的相关概念及其含义说明，便于之后对Giskard共识协议进行详细介绍。
Giskard共识协议相关术语：
提议人(Proposer)：Giskard共识协议中负责出块的节点
T： 时间窗口，每个提议人只能在自己的时间窗口进行出块
N： 共识节点总数
f： 拜占庭节点最大数量
足够多赞成票： 表示为至少收到N-f张赞成票
验证人(Validator)： 共识节点中非提议人节点
视图(View)： 当前提议人的时间窗口可以产生区块的时间范围
ViewNumber： 每个时间窗口的序号，随着时间窗口递增
HighestQCBlock： 本地最高的N-f 个PrepareVote区块
ProposalIndex： 提议人的索引号
ValidatorIndex： 验证人的索引号
PrepareBlock： 提议的区块消息，主要包含区块（Block），提议人索引号
PrepareVote： 验证人对提议区块的Prepare投票，每个验证人需要执行区块后才发送PrepareVote。主要包含ViewNumber, 区块hash, 区块高度，验证人索引号（ValidatorIndex）
ViewChange： 当时间窗口超时，提议人的区块没有都收集N-f个PrepareVote，则会向下一个提议人发送ViewChange。ViewChange包含提议人索引号（ValidatorIndex），最高确认区块（HighestQCBlock）
锁(Lock)： 对指定块高进行锁定
Timeout： 超时（时间窗口到期可以看作提议人的超时时间）
法定： 最大被允许
同一个View： 两个View的ViewNumber相等，可以成为同一个View
BLS签名
目前业界采用的聚合签名方案主要是BLS聚合签名。BLS聚合签名是在BLS签名方案基础上的扩展方案。Boneh-Lynn-Shacham（BLS）签名方案是Dan Boneh，Ben Lynn, Hovav Shacham[9]于2001年提出的。BLS签名目前在许多区块链项目如Dfinity、Filecoin、Libra中都得到了运用。BLS聚合签名可以把多个签名简化为1个聚合签名，对于提高BFT共识协议中的通信效率至关重要。
值得注意的是，BLS聚合签名的方法是有漏洞的。一种被称为rogue public key的攻击可以使得攻击者有机会在获得其他签名者的公钥和标准BLS签名信息之后，能够操纵聚合签名的输出结果。
对这个攻击的一种最直接的防御措施是，参与BLS聚合签名的人都需要先证明各自确实掌握了BLS私钥信息，并事先注册。这一过程可以通过使用一种简单高效的零知识证明技术（Schnorr非交互式零知识证明协议）完成。参与者在进行聚合签名之前，需要给出零知识证明，证明其持有公钥信息的同时，确实掌握了该公钥对应的私钥信息。