Espresso 近日披露了 HotShot 共识协议的一次关键重构，目标直指终局延迟。按照其说明，旧版 HotShot 采用链式 HotStuff 提交规则，区块即便在当前视图拿到法定多数投票，也不能立刻终局，还要等待后续视图继续打包证书，最终才能满足提交条件。这种结构让单个区块的终局，不只取决于本轮投票速度，还取决于后续领导者是否持续在线并正常响应。
HotShot 属于 HotStuff 体系，采用基于节点轮换的领导者模式，核心逻辑是投票加证书确认，而不是最长链规则或委员会抽样方案。Espresso 表示，这种「一个区块的终局依赖后续领导者活性」的耦合结构，正是 HotShot 实现亚秒级终局的主要障碍，因此要解决问题，不能只在实现层做优化，而要直接改写提交规则。
旧版链式提交的阻塞点
在旧版 HotShot 中，视图 v 提出的区块即便已经集齐法定多数投票，也不会马上终局。该区块对应的证书需要被打包进视图 v+1 的提案中，而视图 v+1 的证书又要继续进入视图 v+2，原始区块才算真正提交。
这套链式机制经过充分论证，也有较多研究支持。它的优点是可以把法定多数证书的开销分摊到多个区块中，让共识流程与消息通信形成紧凑流水线：每个视图只产生一次提案和一轮投票，循环推进。
问题也很直接。区块何时终局，不只看它自己这一轮投票完成得多快，还要看后续多个视图能否顺利推进。如果后续领导者响应慢、离线，或者出现拜占庭恶意行为，整条提交链上等待终局的区块都会被卡住，即便这些区块本身已经拿到了所需投票。
新方案：两轮投票在同一视图内完成终局
新版协议把终局过程收回到同一个视图内完成，用两轮连续的全网互投，替代旧方案中「领导者汇总一轮投票，再跨多个视图链式提交」的模式。
- 领导者先提出区块，并利用纠删码把区块拆成多个小块，分发给所有验证节点；
- 验证节点收到分片后，不再把投票发给下一轮领导者，而是向所有其他验证节点广播第一轮投票；
- 任意节点只要收集到法定多数第一轮投票，就可以自行生成证书 1，锁定该区块，并立即广播第二轮投票；
- 任意节点收集到法定多数第二轮投票后，生成证书 2，区块正式终局。
Espresso 将这套结构与 PBFT 等经典 BFT 协议的两阶段提交逻辑对应起来：第一轮预备投票用于锁定取值，第二轮提交投票用于完成终局。这样可以保证诚实验证节点构成的法定多数，不会同时锁定两个互相冲突的区块。
新版与旧版的关键差别，不在于是否采用两轮逻辑，而在于两轮投票放在什么位置。旧版把相关逻辑拆散到不同视图中，每个视图都有独立领导者和独立提案，因此每一处都可能形成阻塞点；新版则把两轮投票都放进当前提案所在视图。区块能否终局，只取决于验证节点是否对它完成投票，不再受后续任何领导者状态影响。
消息模式从领导者汇总改为全网互投
这次重构的另一项结构性变化，是消息交互方式的调整。
旧协议采用线性的领导者汇总模式。验证节点把投票发送给单一领导者，由领导者汇总后生成证书；而证书还要等到被打包进领导者下一次提案后，其他节点才能看到。它的带宽开销较低，每轮消息复杂度为 O(n)，但代价是引入了单点延迟和活性风险：负责汇总投票的领导者必须诚实、在线且响应足够快，否则整轮流程就会停住。
新版协议改为全网互投。每个验证节点都向其余所有节点广播投票，任何节点只要观察到法定多数投票，就能独立组装证书。消息复杂度因此上升到 O(n²)，但投票汇总这个瓶颈被拿掉，由单点节点故障触发的一类活性失效问题也随之消失。
在这种模式下，旧协议中专门处理阻塞问题的视图同步子协议也不再需要。因为节点即便错过部分投票，只要后来收到其他节点组装好的证书，仍然可以完成决策；只有在领导者确实离线或作恶时，才需要依靠简单的超时证书处理。
文中还提到，在约 100 个验证节点的规模下，投票报文本身很小，O(n²) 的消息开销仍然可控。这是针对 HotShot 当前验证节点规模做出的取舍。如果验证节点数量再提升一个数量级以上，则需要配套优化，例如委员会抽样、聚合签名或分层投票转发。Espresso 将这部分视为网络去中心化路线中的扩容问题，与本次聚焦的终局延迟优化分开处理。
数据可用性改造：移除 DA 委员会
旧版方案中，HotShot 需要一个专门的数据可用性（DA）委员会。在共识投票开始前，DA 委员会先接收区块负载、投票并出具 DA 证书。其设计初衷，是在领导者截留数据时，提供一条比单纯依赖 VID 重建区块更快的兜底路径。
新版协议则完全依托 VID 处理数据可用性，原因是区块重建速度已经明显提升。按照文中描述，领导者会按质押权重，利用纠删码为每个验证节点生成分片；验证节点只有拿到属于自己的分片，才会发起第一轮投票。
这意味着，只要集齐法定多数第一轮投票，本身就足以证明网络中存在可用于重建区块的分片集合。如果三分之二质押份额的节点完成投票，就代表三分之二质押份额持有对应分片，而纠删码保证这些分片足以还原完整区块。
在这套设计下，DA 委员会被彻底移除，省去了一整轮投票和负载分发流程。数据可用性不再需要单独协商，而是直接嵌入终局路径中。
与以太坊 Gasper 和 CometBFT 的取舍差异
以太坊 Gasper
文中将 HotShot 与以太坊的 Gasper 机制作了对比。Gasper 由 LMD-GHOST 分叉选择和 Casper FFG 终局机制组成，其设计面向的是远大于 HotShot 的验证节点规模，并明确支持普通质押用户使用配置一般的硬件和低带宽运行。它的终局依托纪元边界检查点，而不是逐区块出具证书。
在这种设计下，以太坊的终局时间以分钟计，而不是毫秒。原因包括固定出块时隙、数万验证节点的大规模签名聚合，以及终局组件叠加在分叉选择规则之上，而不是采用统一的 BFT 提交链路。文中认为，这不是设计缺陷，而是不同目标下的合理权衡：以太坊优先考虑验证节点参与度和抗审查能力，而不是结算延迟。HotShot 的验证节点规模可控，且基于质押机制，从一开始就定位为快速完成数据终局，因此处在另一组取舍空间中。
CometBFT
对于基于 Tendermint 的公链共识引擎 CometBFT，文中指出，它已经可以实现单区块快速终局，采用的也是「领导者提案、验证节点投票」的轮次结构，包含预投票和预提交两类投票，与新旧版 HotShot 同属两阶段 BFT 提交体系。
新版 HotShot 与 CometBFT 的核心差异，在于投票承载的内容。CometBFT 每一轮广播和投票的对象是完整区块；新版 HotShot 广播的是纠删码分片，投票本身同时承担数据可用性证明的作用。按照文中说法，这一点很关键，因为 HotShot 需要同时为大量独立下游链处理区块终局，数据可用性保障必须独立于任意一条下游链的区块大小。
另外，CometBFT 每一轮仍然是线性、以领导者为中心的消息模式；HotShot 则转向全网互投，目的就是把「依赖下一个领导者」这一环节从关键路径中移除。
改造后的目标：更快终局，安全边界不变
按照 Espresso 的总结，重构后的 HotShot 具备几项直接特征：区块终局只取决于对该区块投票的验证节点，不再受后续领导者影响；数据可用性由达成终局的同一法定多数投票从数学上保证，不需要额外协商；新的消息模式以更高带宽开销为代价，换掉了一整类活性瓶颈。
Espresso 认为，正是这组设计组合，让亚秒级终局成为可能，同时没有削弱 HotShot 原有的 BFT 安全保证。协议仍可容忍少于 1/3 质押份额的恶意节点，也不会出现两个冲突区块同时拿到两份证书的情况。
