Hotdry.
归档
ai-systems

Hyperliquid DEX反向工程：订单簿架构、清算机制与跨链桥接风险分析

通过智能合约逆向工程与链上数据分析，深入解析Hyperliquid DEX的链上订单簿架构、中心化清算机制、跨链桥接实现及其系统性风险。

引言：当 "完全链上" 遭遇闭源验证器

Hyperliquid 作为市值 300 亿美元的去中心化永续合约交易所，宣称实现了 "完全链上订单簿" 架构。然而，其闭源验证器二进制文件hl-node隐藏了令人不安的技术实现细节。通过逆向工程分析，我们发现了一个表面上链上透明、实则高度中心化的系统架构，其中订单簿匹配、清算机制和跨链桥接均存在系统性风险。

一、链上订单簿架构的技术实现

1.1 中央限价订单簿（CLOB）的链上实现

Hyperliquid 采用完全链上中央限价订单簿架构，每个可交易资产维护独立的订单簿状态。根据官方文档，订单价格必须为 tick size 的整数倍，数量为 lot size 的整数倍，匹配遵循严格的价格 - 时间优先级原则。这种设计理论上提供了与传统中心化交易所相同的订单簿体验，同时保持了链上透明度。

然而，逆向工程揭示了一个关键限制：所有用户交易必须通过 8 个未公开的广播地址进行提交。交易生命周期如下：

用户签名订单 → API包装为SignedActionWrapper → 验证器检查广播地址白名单 → 链上执行

如果用户直接向验证器提交交易，将被TxUnexpectedBroadcaster错误拒绝。这 8 个地址存储在链上状态中，可通过治理行动ModifyBroadcaster（变体 0x26）即时修改，且没有公开披露这些地址对应的实体。

1.2 订单簿数据结构与匹配引擎

从二进制分析中提取的订单簿数据结构显示，Hyperliquid 使用 BTreeMap 结构存储订单簿状态。每日交易量数据存储在嵌套的 BTreeMap 中，按天和用户地址进行索引：

struct DailyScaledVlms {
    day_to_user_vlm: BTreeMap<u32, BTreeMap<Address, UserVolume>>,
}

struct UserVolume {
    wei_scaled: u64,         // 永续交易量
    cross_scaled: u64,       // 交叉保证金交易量
    spot_add_scaled: u64,    // 现货添加交易量
    spot_cross_scaled: u64,  // 现货交叉交易量
}

匹配引擎集成在 HyperCore 共识层中，通过 HyperBFT 共识确保确定性执行。这种设计理论上消除了中心化匹配引擎的单点故障风险，但广播地址垄断实际上重新引入了中心化瓶颈。

二、清算机制的中心化风险

2.1 清算卡特尔与白名单特权

清算机制是 DeFi 协议安全的核心，但 Hyperliquid 的清算系统存在严重的中心化问题。二进制分析显示，清算权限仅限于allowed_liquidators白名单地址，这是一个存储在 Clearinghouse 结构中的HashSet<Address>。

正常交易需要支付 2.5-5 个基点的费用，而白名单清算者享受零费用特权。这种结构优势创造了清算卡特尔，只有少数特权地址能够参与清算竞争。更令人担忧的是，治理行动UserCanLiquidate（变体 0x1C）允许即时修改清算白名单。

2.2 清算触发与执行流程

当账户权益低于维持保证金（初始保证金的一半，范围 1.25% 至 16.7%）时触发清算。清算使用标记价格进行稳健触发，Clearinghouse 向订单簿发送市价单来平仓。对于大额头寸（>10 万美元 USDC），系统采用分阶段清算策略：初始仅清算 20%，随后 30 秒冷却期后再尝试清算剩余部分。

然而，这种看似合理的清算机制存在致命缺陷：如果 8 个广播地址同时离线或审查特定用户，用户将无法在清算前平仓或调整头寸。2025 年 7 月 29 日和 7 月 23 日的 API 服务器崩溃事件（分别持续 27-37 分钟和 37 分钟）证明了这种风险的实际存在。

2.3 后援清算与自动去杠杆化

当权益降至维持保证金的 2/3 以下时，后援清算机制启动，清算人金库（HLP 策略的一部分）接管头寸。如果其他机制失败且账户价值变为负数，系统触发自动去杠杆化（ADL），使用先前的预言机价格对水下交易者进行反向平仓。

三、跨链桥接实现与审查风险

3.1 桥接验证器集控制

跨链桥接是用户资产安全的关键基础设施，但 Hyperliquid 的桥接实现存在严重的审查风险。治理行动AllowedBridgeValidators（变体 0x11）允许即时修改桥接验证器集，每个验证器为 32 字节地址。

二进制分析显示，桥接状态写入函数sub_1E3F170直接修改 BTreeMap 中的提款记录，没有授权检查。如果单个实体控制≥67% 的投票权，可以在单个区块内替换所有桥接验证器。

3.2 提款审查与永久冻结

更令人担忧的是，验证器可以通过invalidateWithdrawals（变体 7）取消待处理提款。提款记录存储在桥接状态的 BTreeMap 中，每个提款桶最多包含 10,000 条记录。治理行动可以直接修改提款状态索引，实现永久性审查。

最极端的风险来自FreezeChain治理行动（变体 0x20），该行动接受高度参数并在指定区块高度永久冻结链。二进制分析确认不存在UnfreezeChain变体，冻结后需要手动操作员干预：停止验证器、删除/hyperliquid_data/freeze_abci_height文件、修补状态数据库并协调重启。

四、预言机系统的单点故障

4.1 单一预言机更新地址

衍生品交易所的生命线是价格预言机，但 Hyperliquid 的预言机系统存在单点故障风险。oracle_updater字段是一个单一特权地址，控制所有市场的价格馈送。这不是多重签名，也不是去中心化预言机网络，而是一个钱包的私钥。

治理行动SetOracle（Hip3Deploy 变体 2）允许即时设置任意价格。分析显示，当should_validate参数为 false 时，预言机价格直接写入状态，没有任何检查。验证器仅检查速率限制（≥100ms 测试网或≥400ms 生产环境）、时间戳有效范围、无未来时间戳和无重复时间戳，但不检查价格幅度、价格偏差、验证器签名或授权。

4.2 治理绕过与操纵风险

即使oracle_updater地址保持诚实，治理也可以绕过所有安全检查。治理行动包括：

  • OverrideMaxSignedDistancesFromOracle：将偏差限制设置为任意值
  • OverrideIsolatedSpotDistances和OverrideIsolatedExternalDistances：将隔离保证金清算阈值降至零
  • OverrideFundingImpactUsd：将资金费率影响设置为零

2025 年 3 月 26 日的 JELLYJELLY 事件证明了这种风险的实际性。交易员通过操纵外部市场价格扭曲预言机馈送，迫使自清算，HLP 吸收了 1200 万美元的未实现损失。Hyperliquid 的回应是单方面下架 JELLYJELLY，将预言机价格覆盖为 0.0095 美元（相对于 0.50 美元市场价格），并以验证器选择的价格强制结算所有头寸。

五、隐藏的借贷协议与系统性风险

5.1 BOLE 借贷协议

逆向工程发现了一个完全部署但未公开的借贷协议，内部代号 "BOLE"。该协议包含完整的借 / 贷 / 还 / 提操作、利率曲线、治理控制的储备参数和集成清算基础设施。

治理行动SetBole（变体 0x50）控制系统配置。API 端点allBorrowLendReserveStates和borrowLendUserState返回实时生产数据，显示 USDC 池有超过 100 万美元的供应和活跃借款。

5.2 系统性风险放大

隐藏的借贷协议创造了未披露的系统性风险。用户可能不知道他们的交易对手可能通过内部借贷系统进行杠杆操作。如果 BOLE 抵押品与永续保证金计算集成，用户可以：

  1. 向 BOLE 池供应代币 A
  2. 以 50% 的 LTV 借入 USDC
  3. 使用借入的 USDC 交易永续合约
  4. 有效地将现货持仓杠杆化为永续风险敞口

这种设计在市场崩溃时可能触发级联效应：代币 A 价格下跌触发 BOLE 清算，强制 USDC 还款，永续头寸清算，跨系统级联。

六、工程化监控参数与风险缓解策略

6.1 关键监控指标

对于在 Hyperliquid 上部署资金的机构和个人，建议监控以下关键指标：

  1. 广播地址状态：定期检查 8 个广播地址的在线状态和交易提交延迟
  2. 清算白名单变化：监控allowed_liquidators集合的治理修改
  3. 预言机更新频率：跟踪oracle_updater地址的价格更新异常
  4. 桥接验证器集：监控桥接验证器集的治理修改
  5. 治理提案透明度：验证治理提案内容与实际执行的一致性

6.2 风险缓解策略

  1. 头寸分散：避免在单一资产上过度集中风险敞口
  2. 杠杆限制：即使在允许的最高杠杆下，也应保持保守的杠杆比率
  3. 实时监控：部署自动化监控系统，检测异常清算和价格操纵
  4. 退出策略：制定明确的退出策略，包括在广播地址离线时的应急计划
  5. 治理参与：积极参与治理投票，推动去中心化改进

6.3 技术改进建议

从工程角度，Hyperliquid 需要以下改进：

  1. 开源验证器代码：消除逆向工程必要性，建立透明信任
  2. 广播地址去中心化：实现真正的多提议者机制，消除单点故障
  3. 清算权限开放：向所有用户开放清算权限，消除卡特尔
  4. 预言机去中心化：采用多重签名或去中心化预言机网络
  5. 治理时间锁：为破坏性治理行动引入时间延迟

结论：透明度的代价与 DeFi 的未来

Hyperliquid 的案例揭示了 DeFi 领域的一个根本矛盾：技术复杂性与透明度需求之间的紧张关系。虽然链上订单簿架构在理论上提供了透明度，但闭源验证器、中心化控制点和隐藏功能破坏了这种透明度的价值。

正如逆向工程分析所揭示的，Hyperliquid 结合了中心化交易所的控制能力与去中心化协议的缺乏监管保护。用户面临中心化风险（8 个广播地址、清算白名单、单一预言机更新者）而没有中心化交易所的监管保障，同时承担去中心化协议的复杂性而没有完全的去中心化好处。

对于 DeFi 生态系统的长期健康发展，透明度和可验证性必须成为核心设计原则。闭源区块链违背了 "代码即法律" 的基本理念，而隐藏的治理能力和中心化控制点破坏了用户信任。只有通过完全开源、透明设计和真正的去中心化，DeFi 才能实现其承诺的金融民主化愿景。

资料来源：

  1. Reverse Engineering Hyperliquid - https://blog.can.ac/2025/12/20/reverse-engineering-hyperliquid/
  2. Hyperliquid Order Book Documentation - https://hyperliquid.gitbook.io/hyperliquid-docs/trading/order-book
查看归档