Hyperliquid 如何构建 HyperBFT 以支持每秒 20 万+ 订单

摘要：Hyperliquid 开发了 HyperBFT 共识算法，支持每秒 20 万订单。HyperBFT 基于 Hotstuff 协议，采用乐观执行和乐观响应两大改进。乐观执行允许在区块最终确定前执行交易，显著减少区块时间；乐观响应根据网络条件调整共识速度，提高吞吐量。虽然 HyperBFT 的代码和规范尚未公开，但其设计展示了 Hyperliquid 在高性能区块链应用中的创新。

如果你查看 Hyperliquid L1 的浏览器，你会注意到平均每秒会生成大约十几个区块，每个区块包含数百笔交易。这是相当令人印象深刻的性能，对于像链上永久合约交易所这样快节奏、高吞吐量的应用来说，这是绝对必要的。

那么，Hyperliquid 是如何构建一个能够支持这种速度——在高峰时每秒高达 20 万订单的 L1 的呢？继续阅读，了解我们所知道的关于 HyperBFT，即新的 Hyperliquid L1 共识算法的介绍。

BFT 这个，BFT 那个

首先，一些背景知识。HyperBFT 或 CometBFT（另一种继承 Tendermint 的流行共识算法）中的 BFT 代表拜占庭容错（Byzantine Fault Tolerance）。

虽然这个名字听起来很复杂，但简而言之，这是一种即使网络的一部分失败（或不可信）也能继续运行的软件。通常，BFT 共识算法的基准是，只要参与的机器中不到三分之一失败，网络就能继续运行。

容错实际上是去中心化区块链网络的一个相当标准的属性，所以这并不是 HyperBFT 特殊的地方。使 HyperBFT 与众不同的是其特定的功能和设计选择，我们将在接下来的内容中探讨。

什么是 HyperBFT？

HyperBFT 是 Hyperliquid 团队基于 Hotstuff 从头开始构建的共识算法，Hotstuff 是 2018 年实现容错的早期协议及其后续改进。值得注意的是，@Monad_xyz 的共识算法（仍在开发中）也是基于 Hotstuff 的，能够实现并行执行。

Hyperliquid 团队声称 HyperBFT 本身能够支持每秒高达 200 万订单（我们不确定他们如何区分订单和交易）。然而，在这个吞吐量下，执行成为瓶颈，所以 20 万订单/秒是他们对网络性能的现实目标。

HyperBFT 如何为高性能而构建？

HyperBFT 如何实现比 Hyperliquid 之前使用的普通 Tendermint 高出十倍的吞吐量呢？

我们知道它带来了两个重大改进：乐观执行和乐观响应。

乐观执行意味着区块中的交易可以在共识层最终确定区块之前执行。这意味着一旦区块被提议，验证者就会在共识过程的同时开始执行区块中的交易。

相比之下，其他共识算法要求验证者在区块初步达成共识（基于初步检查）后再最终确定区块，然后才开始执行交易。

如果我们将共识期称为 P，执行期称为 Q，乐观执行将区块时间从 P+Q 减少到仅仅是 max(P, Q)——即两个期间中较长的那个。举个例子，@SeiNetwork 团队的一次（非常历史性的）负载测试将 P 设为 600 毫秒，Q 设为 300 毫秒，这意味着乐观执行可以将区块时间减少三分之一（感谢 The Interchain Foundation）。理论上，乐观执行可以将区块时间减少一半。

乐观响应是 HyperBFT 自豪的第二个性能特性。这意味着共识能够根据网络条件扩展，而不是受到任意（悲观）超时的限制。用 @chameleon_jeff 的话来说，“区块的生成速度与验证者法定人数的通信速度一样快。”

这与 CometBFT 形成了鲜明对比，在 CometBFT 中，验证者在收到 2/3 或更多的预投票和预提交后，仍需等待 timeout_prevote 和 timeout_precommit 秒（默认 1 秒）。此外，CometBFT 在每个区块之间实施 timeout_commit，无论网络性能如何。

这些秒数累积起来，使得快速区块时间变得不可能。乐观响应解决了这个问题，可能以牺牲一些去中心化为代价（因为共识通常会在低延迟、高性能的机器之间形成），但这与网络吞吐量的提高直接成正比。

我们还知道 HyperBFT 的什么？

目前，还不多。HyperBFT 的代码或规范尚未公开，但尽管如此，看到 Hyperliquid 团队通过乐观的方法设计共识所能实现的性能还是很有趣的。

翻译：老码农不上班
原文链接：https://x.com/abhiii53/status/1818664662679888079