为什么FacebookLibra的HotStuff共识算法不够安全？

在之前的文章中，我们讨论了区块链生态系统为解决拜占庭容错（BFT）问题而提出的其他解决方案。 在本文中，我们将讨论Hotstuff。

协议概述

每个参与者除了状态变量viewNumber（从1开始，存储其投票决定pre-commit的最高QC）之外，还在本地存储一个挂起命令树，以及prepareQC（从nil开始），lockedQC（从nil开始，存储它投票决定commit的最高QC）。 当“new-view”或回合开始时，公共函数将从当前参与者中确定领导者。 每个参与者将其prepareQC发送给领导者，当领导者接收到客户的操作请求m时，n个参与者将执行BFT协议的四个阶段。

HotStuff的关键创新

星形通信网络使HotStuff BFT / LibraBFT可以在降低通信复杂性但增加回合复杂性的情况下达成共识。值得注意的关键创新有以下几点：

1.HotStuff参与者通过p2p通道（星型拓扑通信网络）将签名的消息发送给领导者。

2.HotStuff使用阈值数字签名方案，可以在无论领导者是正确还是错误的情况下实现线性的身份验证器复杂性。

也许相关性最大的是：最初HotStuff论文提出用PaceMaker来实现轮次同步的功能，但是该论文缺少明确的实现细节。因此，我们可以看看LibraBFT是如何实现的：当参与者放弃回合r时，它将广播带有回合证书的超时消息。他们希望这能使所有（诚实的）参与者在传输延迟的范围内进入第r轮。收集到一定数量的参与者超时消息后，就会形成超时证书，并实现了轮次同步。

可信领导者的重要性

消息传播的重要性在HotStuff BFT协议的漏洞中特别突出，因为它缺少明确的决策消息传播过程。当领导者无法在HotStuff中可靠地广播决策消息时，就会出现问题。就如以下情形：

根据协议，负责人的任务是将路径扩展到（a0-> a1->…->-> b）。假设执行过程顺利进行，我们继续下一个视图v + 1。我们希望领导者将命令传播给所有参与者，这些参与者都应执行与扩展叶节点b和c关联的命令。 HotStuff BFT协议指出：“实际上，落后的接收者可以通过从其他副本中获取丢失的节点追上来。”这意味着，在视图v + 1结束时，落后的参与者可以获取与（a0-> a1->…->-> b-> c）相对应的prepareQC。

但是，试图追赶的参与者无法知道所有参与者是否实际执行了命令（即，领导者是否将节点b的命令传播给了每个人，一个节点或某个子集）。根据HotStuff BFT协议，树上的节点仅包含父节点的哈希值和client命令。结果，每个参与者维护的叶节点不包含有关命令是否已执行的信息。

最后，该分析表明，HotStuff的原始概述使网络上的参与者容易出现不一致的情况，因此必须要考虑将是否已执行给定命令包括在树节点中。

—-

编译者/作者：Sperax

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。