优化延迟
以下建议仅供参考，是一个非全面性的起点。它们不构成交易建议，也不保证任何延迟或交易结果。
优化读取延迟（接收市场数据）
- 对可靠的对等节点（例如 Hyper Foundation 非验证节点）运行一个非验证节点。
- 运行节点时加上
--disable-output-file-buffering，以便在区块执行完成后立即获得输出 - 使用足够规格的机器运行节点，至少 32 个逻辑核心、128 GB 内存和 500 MB/s 的磁盘吞吐量。增加核心数可以降低延迟，因为区块的执行会更快。
- 利用节点输出在本地构建订单簿及其他交易所状态，节点数据比 API 更快、更细粒度。参见 https://github.com/hyperliquid-dex/order_book_server，其中示例了如何在运行节点的同一台机器上构建订单簿。该仓库不再积极维护。建议 fork 该仓库或从头实现，以纳入 ALO 优先费等细节或其他边界情况。
- 节点上的
--batch-by-block会等到区块结束才写入数据。上面的订单簿服务器示例利用这一点来简化逻辑，但进一步的优化可以包括关闭该标志并以其他方式推断区块边界。 - 对延迟敏感的用户可能会发现
split_client_blocks: true很有用，它会在交易被纳入 client block 之前先流式传输待提交的交易。这可以在读取输入时带来 70-150ms 的延迟改善。如节点仓库文档所述，这是到执行的最快交易输入，甚至在 L1 执行之前就已广播。更快的输入数据的代价是执行结果尚不可用。不过，对于下单这类简单操作，消费方可以流式地为所有用户估算账户价值，从而以合理的准确度预测执行结果。 - Foundation 非验证节点是正常运行时间和延迟方面最优的非验证节点之一。延迟敏感用户的接入详情见这里。
- 读取优先费是从网络读取原始数据的最快方式。更多细节见这里。
优化写入延迟（发送订单和撤单）
- 撤单应使用 fast 标志发送。fast 标志没有任何缺点，只是 fast 撤单不能用于撤销触发订单。
- 写入优先费是向网络发送订单的最快方式。更多细节见这里。
- Hyperliquid 的执行逻辑旨在保护 Maker 免受毒性订单流的影响，从而让终端用户即使在剧烈波动中也能看到紧密的价差和充足的流动性。这一效应的主要驱动因素是：在时刻
t发送的撤单和 ALO 订单几乎总是在时刻t发送的 IOC 和 GTC 订单之前执行。这种优先排序跨越多个区块。次要效应是每个 L1 区块只包含少数几个共识捆绑（bundle）。在每个捆绑内，ALO 和撤单先于其他交易执行。 - Hyperliquid 上的端到端延迟与中心化撮合引擎不可直接类比，因为订单簿完全在链上。端到端延迟包括到达 API 服务器的时间、内存池（mempool）打包时间和提交时间（在流水线化的 HyperBFT 共识中通常为 2 个区块）。交易的先后顺序的噪声远小于端到端延迟所显示的程度。虽然撤单或 ALO 订单可能显示约 380ms 的端到端延迟，但用户应该能够以发送时间之间 <10ms 的偏差运行实验，并在 L1 上看到可预测的排序。
- 希望降低端到端写入延迟的用户（例如为了预测将被提交的交易顺序），可以从非验证节点的 split client block 中读取这些交易（参见上面的读取延迟部分）。这种方式不包含交易的执行结果。