链上订单簿是什么？Hyperliquid 怎么用 HyperBFT 给订单单块最终性

把撮合引擎搬到 L1 上

大多数交易所型应用把订单簿放在链下数据库，链上只留结算痕迹。Hyperliquid 的选择相反：官方文档把它的 L1 描述为从头编写、为订单簿优化的区块链，永续合约和现货的下单、撤单、成交、清算全部作为链上状态机的一部分执行。这条链上不存在”撮合员”角色——订单匹配是共识节点共同执行的确定性逻辑，任何人可以在节点上复算同一本账。

HyperBFT 与单块最终性

共识层面，官方文档说明 Hyperliquid 使用自研的 HyperBFT，算法受 HotStuff 及其后继启发，共识与网络栈为订单簿需求重新设计。效果是所谓 one-block finality：一笔订单被某个区块纳入并敲定后，不存在同层级的重组窗口，交易结果不需要等待多轮确认叠加。这与以太坊的”先包含后敲定”两段式、以及 Rollup 的软确认分层都不同——它把最终性做进了每一块。对做市与清算系统而言，撮合结果与最终性在同一时刻到达，是这类应用选择独立 L1 而非通用链上订单簿合约的主要动因。

状态执行分成两个仓室

Hyperliquid 的状态执行分为 HyperCore 与 HyperEVM 两块。HyperCore 承载订单簿核心：官方文档写明当前支持每秒二十万量级的订单处理，并强调这个数字随节点软件优化持续提升——这是一个来自官方页面的当下口径，不是恒定规格。HyperEVM 则把以太坊式的通用智能合约平台带进同一条链，两者同属一个 L1、共享验证者集，但状态访问路径不同。核对吞吐量或功能边界这类动态数字时，应直接引用官方文档当时的表述并注明来源页面，而不是转述某个时刻的截图。

一笔订单在链上走过的路径

把用户视角的动作对应到共识视角，能看清这种架构与链下交易所的真实差异。下单、撤单在 Hyperliquid 中各自是一条链上动作，被某一块收集后由状态机按确定性规则撮合，成交与清算结果直接写进账户状态。链下交易所里”提交成功但撮合队列还没排到”的中间态在这里不存在——要么这一块撮合了，要么下一块见，而每一块都是最终块。官方文档在描述订单簿时也强调了这一点：每一笔下单、撤单、成交与清算都公开发生，最终性由 HyperBFT 逐块继承。

机制上的取舍

把订单簿放进共识意味着每一条撤单都要过一遍全网。收益是透明与可复算：清算顺序、资金费率、仓位变动都是公开状态，不存在”平台内部规则”黑箱。代价是链的通用资源与做市高频流量共享，任何 HyperEVM 上的合约开发者都在和每秒数十万笔的订单流竞争同一条链的处理能力。设计上是两个执行仓室隔离热点，但同一共识引擎的容量上限仍是全局约束。

怎么客观地读这个项目

评估任何”交易所公链”叙事时，值得分开三件事：撮合是否真的在共识内执行（可节点复算）、最终性模型是什么（是否单块敲定）、性能数字有无官方口径及版本说明。Hyperliquid 官方文档对前两项都有明确陈述，对第三项也标注了持续优化。把它与通用 L1 或 Rollup 对比时，比的应是各自订单簿应用在这三种架构下的约束，而不是笼统的快慢。

本文为机制说明，不构成投资建议；动态参数与吞吐口径以官方文档当前版本为准。