在之前的文章中，我们讨论了区块链生态系统为解决拜占庭容错问题而提出的其他解决方案。在本文中，我们将讨论Hotstuff。协议概述
每个参与者除了状态变量viewNumber之外，还在本地存储一个挂起命令树，以及prepareQC，lockedQC。当“new-view”或回合开始时，公共函数将从当前参与者中确定领导者。每个参与者将其prepareQC发送给领导者，当领导者接收到客户的操作请求m时，n个参与者将执行BFT协议的四个阶段。HotStuff的关键创新
星形通信网络使HotStuffBFT/LibraBFT可以在降低通信复杂性但增加回合复杂性的情况下达成共识。值得注意的关键创新有以下几点：1.HotStuff参与者通过p2p通道将签名的消息发送给领导者。2.HotStuff使用阈值数字签名方案，可以在无论领导者是正确还是错误的情况下实现线性的身份验证器复杂性。也许相关性最大的是：最初HotStuff论文提出用PaceMaker来实现轮次同步的功能，但是该论文缺少明确的实现细节。因此，我们可以看看LibraBFT是如何实现的：当参与者放弃回合r时，它将广播带有回合证书的超时消息。他们希望这能使所有参与者在传输延迟的范围内进入第r轮。收集到一定数量的参与者超时消息后，就会形成超时证书，并实现了轮次同步。可信领导者的重要性
消息传播的重要性在HotStuffBFT协议的漏洞中特别突出，因为它缺少明确的决策消息传播过程。当领导者无法在HotStuff中可靠地广播决策消息时，就会出现问题。就如以下情形：根据协议，负责人的任务是将路径扩展到。假设执行过程顺利进行，我们继续下一个视图v+1。我们希望领导者将命令传播给所有参与者，这些参与者都应执行与扩展叶节点b和c关联的命令。HotStuffBFT协议指出：“实际上，落后的接收者可以通过从其他副本中获取丢失的节点追上来。”这意味着，在视图v+1结束时，落后的参与者可以获取与相对应的prepareQC。但是，试图追赶的参与者无法知道所有参与者是否实际执行了命令。根据HotStuffBFT协议，树上的节点仅包含父节点的哈希值和client命令。结果，每个参与者维护的叶节点不包含有关命令是否已执行的信息。最后，该分析表明，HotStuff的原始概述使网络上的参与者容易出现不一致的情况，因此必须要考虑将是否已执行给定命令包括在树节点中。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。