文章介绍了Espresso的HotShot共识协议，该协议专为Rollups设计，旨在提高高吞吐量和快速最终性。HotShot基于HotStuff BFT协议，并扩展到了去中心化的“权益证明”设置，以补充以太坊的动态可用性。文章还探讨了乐观响应与动态可用性之间的权衡，并解释了HotShot如何在网络条件有利时实现高性能，并在最坏情况下回退到高弹性的低吞吐量路径。
Espresso 是一个协调层，它使 Rollups 能够在以太坊分散的 L2 生态系统中无缝互操作，为用户提供统一的体验，而不会牺牲速度或可扩展性。
Espresso 的核心是 Espresso Network，它由我们设计的一种共识协议提供支持，该协议优先考虑高吞吐量和快速最终性（即乐观响应性）。这个协议称为 HotShot，基于 HotStuff BFT 协议。
我们开发 HotShot 是为了弥补以太坊共识协议（Casper）固有的权衡，Casper 在悲观条件下优先考虑活性（即动态可用性），而不是在乐观条件下优先考虑响应性。
与 Espresso Network 集成的 Rollups 使用 HotShot 作为共享的真理源，提供交易排序和数据可用性的预确认，从而实现快速高效的跨 Rollup 互操作性。
Espresso Network 围绕单一的去中心化权益证明安全模型设计，该模型支撑了 HotShot 和我们称为 Tiramisu 的数据可用性机制，进一步提升了性能。
我们的 Americano 测试网刚刚发布，它实现了 HotShot 的第一个版本。
乐观响应性与动态可用性
乐观响应性，也被称为快速最终性，指的是协议在网络允许的情况下尽可能快地确认交易的能力。当网络条件最佳时，确认几乎是瞬间完成的。这与根据最坏网络条件设置确认延迟的协议，或交易最终性只能概率性实现的协议不同。
动态可用性是中本聪最长链共识协议的标志性成就，它指的是协议在参与节点不稳定的情况下仍能保持活性的能力，即使在任何给定时刻大多数节点都处于离线状态。
共识协议必须在乐观响应性和动态可用性之间做出选择——这两种特性是不兼容的。迄今为止，包括 Tendermint 和 Casper 在内的大多数实用 BFT 协议都无法同时实现这两种特性。
HotShot 将 HotStuff 扩展到去中心化的“权益证明”环境中，弥补了以太坊的动态可用性，同时保持了高吞吐量和乐观响应性。
Web2 性能与 Web3 安全性
像 HotShot 这样具有乐观响应性的共识协议能够展示高吞吐量，因为它们可以利用更类似于 Web2 网络内部使用的架构。
共识系统的可扩展性通过吞吐量和延迟来衡量。
- 吞吐量通过系统每单位时间（例如，每秒）可以最终确定的数据字节数来衡量。这比每秒交易数（TPS）更精确，因为它考虑了跨交易中包含的数据大小和复杂性的变化。
- 延迟是指交易提交后到最终确定所需的平均时间。
共识协议的主要可扩展性挑战是在保持去中心化和合理低延迟的同时，实现尽可能高的吞吐量。
共识，或者说状态机复制，不仅涉及所有参与节点就如何对交易排序达成一致，还涉及节点就整个网络状态达成一致（或者至少就一个可以重放以重建网络状态的交易日志达成一致）。虽然理论上这两个功能可以分离，并且参与每个功能的节点的数量和/或身份可以是不同的，但在一个去中心化系统中，这两个功能都相当庞大且多样化。因此，任何去中心化区块链的核心都是通过一种在所有参与协议的节点之间以弹性方式传播信息的机制。
弹性通信协议（例如，点对点 gossip）是去中心化区块链比传统的“Web2”交易系统吞吐量低得多的原因之一，尤其是在参与网络的节点之间极端多样化的情况下。典型的“Web2”架构利用星型网络配置，即所有流量通过一个或多个指定的高带宽服务器进行路由。这在大多数参与节点带宽远低于这些中央服务器的网络中优化了通信（特别是广播速率），但它对拜占庭式腐败的抵抗力较差。
像 HotShot 这样具有乐观响应性的共识协议的主要优势是在网络条件有利时表现更好。这类协议甚至可以利用典型的“Web2”架构，乐观地实现极高的吞吐量，而在最坏情况下，则退回到基于 gossip 的高弹性路径，此时吞吐量较低。 从这个意义上说，乐观响应性协议有可能实现两全其美：Web2 性能与 Web3 安全性。
即使在我们最初的 Americano 测试网实现 中，HotShot 也已经展示了乐观响应性的可扩展性优势。随着我们扩展 HotShot，利用 SNARKs、可验证信息分发（VID）和其他技术，它将能够在悲观条件下（即唯一可用的通信通道是低吞吐量的 gossip 协议时）持续保持高吞吐量。
了解更多关于我们的第一个测试网 Americano 和我们未来计划的信息，请阅读这里。
