除了状态变量viewNumber(从1开始，存储它投票给预提交的最高QC)、prepareQC(从nil开始)、lockedQC(从nil开始，存储它投票给提交的最高QC)之外，每个参与者在本地存储一个挂起命令树。当“新观点”或“新一轮”开始时，公共功能从当前参与者中确定领导者。
每个参与者将其预先的QC发送给领导者，当领导者收到客户的操作请求m时，n个参与者执行BFT协议的4个阶段。
HotStuff的关键创新来自以前的解决方案
星型通信网络允许HotStuff BFT/LibraBFT在降低通信复杂度的同时提高整体复杂度，从而达到一致。需要注意的关键创新是:
1.HotStuff参与者在p2p信道（星型拓扑通信网络）中向领导参与者发送签名消息。
2.使用门限数字签名方案，无论领导者是正确的还是错误的，HotStuff都能实现线性验证器的复杂度。
也许最相关的是：PaceMaker是最初的HotStuff论文提出的实现轮同步的功能，但该文件缺乏明确的实现细节。
因此，我们可以看看LibraBFT是如何实现它的：当一个参与者放弃一轮时，它就会用循环入口证书广播一个超时消息。
他们希望这能使所有(诚实的)参与者在传输延迟的范围内将r轮起来。收集参与者超时消息的仲裁后，将形成超时证书，并实现轮同步。
可靠领导者的重要性
HotStuff BFT协议的漏洞特别强调了消息传播的重要性，因为它缺乏一个明确的决策消息传播过程。当领导者不能可靠地在HotStuff中广播决定消息时，麻烦就出现了。考虑以下场景：
根据协议，领导者的任务是将路径扩展到(a0 -> a1 -> … -> at -> b)。假设执行过程没有任何问题，我们继续下一个视图v+1。
我们期望领导者将命令传播给所有参与者，所有参与者都应该执行与扩展叶节点b和c相关的命令。
HotStuff BFT协议规定“在实践中，落后的接收者可以通过从其他副本中提取丢失的节点来赶上。”这意味着，在视图v+1结束时，落后的参与者可以获取对应于(a0 -> a1 -> … -> at -> b -> c).的prepareQC。
然而，这个试图追赶的参与者无法知道是否所有的参与者都实际执行了这些命令（即，领导者是否将节点b的命令传播给每个人、1个节点或某个子集）。
根据HotStuff BFT协议，树上的节点只包含父节点的哈希值和客户端命令。因此，由每个参与者维护的叶节点不包含有关命令是否已执行的信息。
最后，本分析证明了HotStuff的最初概述使网络上的参与者容易受到不一致性的影响。这里的教训是，考虑是否在树节点本身中执行了一个给定的命令是很重要的。