Espresso 全新性能基准背后的共识机制变革：从链式提交到单视图终局 - - HotShot 重构之路

链式提交存在的痛点

Espresso 的共识协议 HotShot，一直属于 HotStuff 体系：基于节点轮换的领导者模式，核心逻辑是简单的投票 + 证书确认机制，而非其他公链采用的最长链规则或者委员会抽样方案。

旧版 HotShot 采用链式 HotStuff：在视图 v 中提出的区块，即便集齐法定多数投票，也不会立刻达成终局。它的证书必须被打包进视图 v+1 的提案中，而视图 v+1 自身的证书，又需要打包进视图 v+2，原始区块才算满足协议的提交规则。

这套设计经过充分论证、已有大量研究。链式机制可以将法定多数证书的开销分摊到多个区块，让共识流程与消息通信形成紧凑、统一的流水线：每个视图只产生一次提案、一轮投票，循环往复。 代价就是延迟：一个区块何时终局，取决于后续多少个视图能顺利完成，而不只是它自身投票轮次的速度。如果后续的领导者响应缓慢、离线或者存在拜占庭恶意行为，这条提交链上所有排队的区块都会被卡住 — — 哪怕这些区块本身已经集齐了所需的全部投票。

该协议的核心目标，是为众多下游链快速完成数据终局。而这种 “一个区块的终局依赖后续领导者活性” 的耦合结构，正是 HotShot 实现亚秒级终局的最大阻碍。想要解决这个问题，不能只优化上层实现，必须重新设计提交规则本身。

重构方案：两轮投票，同一视图内完成终局

新版协议在同一个视图内完成终局，采用两轮连续的全网互投，替代旧方案里 “领导者汇总一轮投票 + 跨多视图链式提交” 的模式。

1. 领导者提出区块，利用纠删码将区块拆分为多个小块，分发至所有验证节点；

2. 验证节点收到分片后，向所有其他验证节点广播第一轮投票，而不是发给下一轮领导者；

3. 任意节点收集到法定多数第一轮投票后，自行生成证书 1，锁定该区块，并立刻广播第二轮投票；

4. 任意节点收集到法定多数第二轮投票后，生成证书 2，区块正式达成终局。

这套结构和 PBFT 等经典 BFT 协议的两阶段提交逻辑一致：一轮预备投票锁定取值，一轮提交投票完成终局；以此保证诚实验证节点的法定多数，不可能同时锁定两个相互冲突的区块。 关键区别在于这套两轮机制的摆放位置：旧版方案中，对应的两轮逻辑分散在不同视图，每个视图都有独立领导者、独立提案，每一处都存在阻塞风险；新版方案两轮投票全部在当前提案视图内完成。区块能否终局，只取决于验证节点对它的投票，和后续任何领导者的状态无关。

全网互投 vs 领导者汇总投票

另一项结构性改动是消息交互模式。 旧协议采用线性的领导者汇总模式：验证节点把投票发给单一领导者，由领导者汇总投票生成证书；证书只有被打包进领导者的下一次提案后，全网其余节点才能看到。这种方式带宽开销低，每轮消息复杂度为 O (n)，但引入了单点延迟与活性风险：汇总投票的领导者必须诚实、在线、响应迅速，否则整轮流程卡住。

新版协议采用全网互投：每个验证节点向其余所有节点广播投票，节点只要观测到法定多数投票，就可以独立组装证书。消息复杂度上升到 O (n²)，但彻底消除了投票汇总瓶颈，去掉了一类由单点节点故障引发的活性失效问题。 同时，旧协议专门用来处理这类阻塞问题的视图同步子协议也不再需要。在全网互投、节点可独立组装证书的模式下，错过部分投票的节点，只要收到别人组装好的证书，就能完成决策；仅当领导者确实离线或作恶时，依靠简单的超时证书即可处理。

在约 100 个验证节点的规模下，投票报文很小，O (n²) 的消息开销完全可控。这是适配 HotShot 当前验证节点规模的取舍；如果验证节点数量提升一个数量级以上，则需要配套方案优化，比如委员会抽样、聚合签名、分层投票转发等。我们将其视作网络去中心化路线中的扩容问题，和本次聚焦的终局延迟优化相互独立。

数据可用性：提升效率，取消数据可用性委员会

旧版方案需要一个专门的数据可用性（DA）委员会：在共识投票启动之前，先接收区块负载、投票并出具 DA 证书。这套机制的初衷是提供一条更快的兜底路径，防止领导者截留数据时，只能依靠 VID（信息分发方案）重建区块。

新版协议完全依托 VID 实现数据可用性，核心原因是区块重建速度大幅提升：领导者按照质押权重，通过纠删码为每个验证节点生成分片。验证节点只有拿到属于自己的分片，才会发起第一轮投票。 这就意味着：集齐法定多数第一轮投票，本身就可以证明全网存在可用于重建区块的分片集合。如果三分之二质押份额节点完成投票，就代表三分之二质押份额持有对应分片；而纠删码保证，这些分片足以还原完整区块。 DA 委员会被彻底移除，省去了一整轮投票与负载分发流程。

和其他已上线共识协议的对比

以太坊 Gasper（LMD-GHOST 分叉选择 + Casper FFG 终局机制）

它的设计取舍面向另一个方向：验证节点规模远大于 HotShot，明确支持普通质押用户使用配置一般的硬件、低带宽运行；终局依托纪元边界检查点实现，而非逐区块出具证书。 这些设计决定了以太坊终局耗时以分钟计，而非毫秒：固定出块时隙、数万验证节点的大规模签名聚合、终局组件叠加在分叉选择规则之上，而非一套统一的 BFT 提交链路。这并不是设计缺陷，而是一套合理的权衡 — — 优先最大化验证节点参与度、抗审查能力，而非结算延迟。HotShot 的验证节点规模可控、基于质押机制，从设计之初就定位为快速完成数据终局，处在取舍空间的另一位置。

CometBFT（基于 Tendermint 的公链共识引擎）

CometBFT 已经可以实现单区块快速终局，采用 “领导者提案、验证节点投票” 的轮次结构，包含预投票、预提交两类投票，和新旧版 HotShot 同源，都属于两阶段 BFT 提交体系。 新版 HotShot 和 CometBFT 的核心差异，在于投票承载的内容：CometBFT 每一轮广播、投票的对象是完整区块；新版 HotShot 广播纠删码分片，投票本身就充当数据可用性证明。这点至关重要：HotShot 同时为大量独立下游链处理区块终局，数据可用性保障需要独立于任意一条下游链的区块大小。 另外 CometBFT 每一轮依旧是线性、以领导者为中心的消息模式；HotShot 转向全网互投，目的就是把 “依赖下一个领导者” 这个环节从关键路径上剔除。

最终收益：极速终局，安全保障不变

改造后的共识协议具备这些特性：区块终局仅取决于对它投票的验证节点，不受后续领导者影响；数据可用性由达成终局的同一法定多数投票从数学层面保证，不再需要单独协商；新的消息模式以带宽开销为代价，消除一整类活性瓶颈。

正是这套组合设计，让亚秒级终局成为可能，同时没有削弱 HotShot 一贯的 BFT 安全保证：协议依旧可以容忍少于 1/3 质押份额的恶意节点，不存在两个冲突区块同时拿到两份证书的情况。