链式提交存在的痛点
Espresso 的共识协议 HotShot，一直属于 HotStuff 体系：基于节点轮换的领导者模式，核心逻辑是简单的投票 + 证书确认机制，而非其他公链采用的最长链规则或者委员会抽样方案。
旧版 HotShot 采用 链式 HotStuff ：在视图 v 中提出的区块，即便集齐法定多数投票，也不会立刻达成终局。它的证书必须被打包进视图 v+1 的提案中，而视图 v+1 自身的证书，又需要打包进视图 v+2，原始区块才算满足协议的提交规则。
这套设计经过充分论证、已有大量研究。链式机制可以将法定多数证书的开销分摊到多个区块，让共识流程与消息通信形成紧凑、统一的流水线：每个视图只产生一次提案、一轮投票，循环往复。 代价就是延迟：一个区块何时终局，取决于后续多少个视图能顺利完成，而不只是它自身投票轮次的速度。如果后续的领导者响应缓慢、离线或者存在拜占庭恶意行为，这条提交链上所有排队的区块都会被卡住 — — 哪怕这些区块本身已经集齐了所需的全部投票。
该协议的核心目标，是为众多下游链快速完成数据终局。而这种 “一个区块的终局依赖后续领导者活性” 的耦合结构，正是 HotShot 实现亚秒级终局的最大阻碍。想要解决这个问题，不能只优化上层实现，必须重新设计提交规则本身。
重构方案：两轮投票，同一视图内完成终局
新版协议在 同一个视图 内完成终局，采用两轮连续的全网互投，替代旧方案里 “领导者汇总一轮投票 + 跨多视图链式提交” 的模式。
1. 领导者提出区块，利用纠删码将区块拆分为多个小块，分发至所有验证节点；
2. 验证节点收到分片后，向 所有其他验证节点广播第一轮投票 ，而不是发给下一轮领导者；
3. 任意节点收集到法定多数第一轮投票后，自行生成 证书 1 ，锁定该区块，并立刻广播第二轮投票；
4. 任意节点收集到法定多数第二轮投票后，生成 证书 2 ，区块正式达成终局。
来源：吴说区块链
本文由 GTokenTool 摘编，版权归原作者所有；内容仅供参考，不构成投资建议。