Hyperliquid 技术解读：桥合约、HyperEVM 及其潜在问题

作者：Shew，仙壤 GodRealmX 近期广受市场关注的 Hyperliquid 是最有影响力的链上订单薄交易所之一，其 TVL 已超过 20 亿美元，在被 Messari 评价为“链上 Binance”的同时，甚至还把本已淡出大众视角的 Layer3、应用链叙事重新拉回聚光灯下。凭借着 Token 上线一个月内 FDV 拉至 300 亿美元的辉煌成绩，Hyperliquid 获得了从普通用户到从业人员的广泛关注，与此同时市面上也涌现出了大量关于 Hyperliquid 的研报，但这些文章基本聚焦于其在订单簿产品功能和交易机制上的特点，没有深入探究其背后的技术构造以及安全隐患。 本文作者旨在补足这一空缺，单纯从技术构造与安全的角度来考察 Hyperliquid，帮助更多人理解这一明星项目的结构与原理。我们将从 Hyperliquid 跨链桥合约的构造与隐患、HyperEVM 与 HyperL1 双链构造两大角度展开阐述，帮助大家深入理解其背后的技术架构与实现方式。 （目前 Hyperliquid 占用了 Arbitrum 上的 USDC 总供应量的 67%） HyperLiquid 跨链桥解析 由于HyperLiquid 并没有开源核心组件，但是开源了相关的桥合约，所以我们对桥合约方面的风险更为了解。Hyperliquid 在 Arbitrum 上部署了一个桥合约，用来存储用户存入的 USDC 资产，我们可以在 Bridge 组件内看到 Hyperliquid 节点的部分行为。 验证者集合 从节点身份划分的角度来看，Hyperliquid 有 4 组验证者，分别为 hotValidatorSet 、 coldValidatorSet 以及 finalizers 和 lockers ，对应着不同的职能。其中 hotValidatorSet 用于响应用户的提款操作等高频行为，一般使用热钱包以随时响应 Hyperliquid 用户的提款请求。 而 coldValidatorSet 主要用于修改系统配置，如改写 hotValidatorSet 或 lockers 等验证者集合的名单，或是处理桥合约的锁定状态，而且 coldValidatorSet 有权直接将某些提款请求无效化。 而 lockers 是一组有特殊权限的验证者，类似于 Layer2 惯用的“安全委员会”，会在一些突发情况下用投票决定是否让跨链桥暂停运转。目前Hyperliquid桥的lockers 集合内包含5 个地址，只需要 2 个 locker 投票即可暂停桥合约的运行。 至于 finalizers 其实也是一组特殊的验证者，主要用于确认跨链桥的状态变化，从合约层面来看主要确认的就是用户存款和提款。Hyperliquid 的跨链桥使用“提交 - 确认”机制，比如用户发起提款后并不会被立即执行，需要等待一段时间 ( 这段时间被称为争议期 )。等待争议期结束后，finalizers内的成员执行提款交易，提款才可以被正常执行。 而一旦跨链桥出现问题，比如某笔提款声明要提走的资产大于该用户实际拥有的资产余额，Hyperliquid 节点就可以在争议期内使用 lockers 投票暂停跨链桥合约运行，或者由 coldValidatorSet 直接将有问题的提款请求无效化。 目前 Hyperliquid 的只有 4 个验证者节点，所以 hotValidatorSet 和 coldValidatorSet 只对应 4 个链上地址。Hyperliquid 在初始化时，自动将 hotValidatorSet 内的地址注册为 lockers 和 finalizers 的成员，而 coldValidatorSet 为 Hyperliquid 官方自己控制，使用冷钱包来存储密钥。 存款 Hyperliquid 的桥合约基于 EIP-2612 的 Permit 方法来处理用户的存款操作，且桥合约内只允许用户存入 USDC 一种资产。Permit 相比于传统的 Approve—Transfer 模式更为简洁，也便于支持批量操作。 Hyperliquid 的桥合约使用了 batchedDepositWithPermit 函数来批量处理多笔存款，这里的存款动作较为简单，不存在资金安全风险，在处理流程上很简洁，只是使用了 Permit 方法来节优化 UX。

提款

相比于存款，提款是一个高度危险的操作，所以提款逻辑会比存款复杂很多。当用户发起提款请求后，Hyperliquid 节点会调用桥合约的batchedRequestWithdrawals函数。此时桥合约会要求每笔提款请求必须凑齐hotValidatorSet的2/3签名权重，注意很多文档在此处都描述为“集齐 2/3 的签名”，但实际上桥合约检查的是“2/3 的签名权重”。目前 HyperLiquid 只有 4 个权重相同的节点，所以检查签名权重和检查签名数量暂时一致，但在未来，HyperLiquid 可能引入高权重的节点。

当发起提款请求后，跨链桥不会立即将合约控制的USDC 转移出去，而是有一个“争议期”，类似于欺诈证明协议中的“挑战期”。目前 Hyperliquid 桥合约的争议期为 200 秒，在争议期内可能出现两种情况： 1.lockers 认为目前的提款请求存在严重问题，此时可以直接投票把合约暂停 / 冻结； 2.节点认为部分提款行为存在问题，此时 coldValidatorSet 成员可以调用 invalidateWithdrawals 函数，令该笔提款无效化。 如果争议期内没有出现问题，待争议期结束后，finalizers内的成员可以调用桥合约中的batchedFinalizeWithdrawals 函数来敲定最终的状态，该函数触发后 USDC 才会被打到用户在 Arbitrum 的钱包地址里。 所以从安全模型的角度来看，假如有恶意攻击者想在 Hyperliquid 的提款流程中做手脚，就需要突破三道防线: 1.掌握 hotValidatorSet 内的 2/3 签名权重，换言之需要获取一定数量的私钥或是串谋；目前 HyperLiquid 只有 4 个验证者，被攻击者控制或串谋的可能性不低； 2.在争议期内，攻击者应避免自己的恶意交易被发现，一旦被发现很有可能使 lockers 出手锁住合约。我们会在下文专门讨论这部分。 3.获取至少一个 finalizers 成员的私钥，让自己的提款行为被最终确认。目前 finalizers 成员和 hotValidatorSet 成员基本一致，所以只要攻击者满足了上述条件 1，就自动满足了条件 3。 桥合约的锁定 前面我们多次提到了 Hyperliquid 设置了一个锁定跨链桥合约的功能。具体来说，锁定跨链桥需要lockers 成员调用跨链桥合约中的voteEmergencyLock函数进行投票，目前当 2 名 lockers调用该函数给出投票后，跨链桥合约就会被锁定并暂停运转。 但需要注意，HyperLiquid 的跨链桥也提供了 unvoteEmergencyLock 函数，允许 lockers 成员撤回投票。而一旦跨链桥合约被成功锁定，就只能通过名为 emergencyUnlock 的函数来解除锁定，需要收集 coldValidatorSet 成员 2/3 以上的签名权重。 emergencyUnlock 功能在解除锁定的同时，也会输入新的 hotValidatorSet 和 coldValidatorSet 验证者地址集合，并且会立即更新。

验证者集合更新

相比于费尽心思尝试突破提款流程中的已有防线，一种更好的攻击手段是直接使用 updateValidatorSet函数更新hotValidatorSet和coldValidatorSet验证者集合。这要求调用者必须给出所有hotValidatorSet成员的签名，且该操作有 200 秒的争议期。

当争议期结束后，需要 finalizers 成员调用 finalizeValidatorSetUpdate 函数，完成最终的状态更新。 至此，我们已经介绍了 Hyperliquid 跨链桥的大部分细节。本文没有介绍 lockers 和 finalizers 的更新逻辑，这两者的更新都需要 hotValidatorSet 签名，而将某一个成员移除则需要 coldValidatorSet 签名。 总结下来，Hyperliquid 的桥合约包含以下风险： 1.黑客控制了coldValidatorSet 后可以无视任何阻拦来盗取用户资产。因为 coldValidatorSet 拥有 emergencyUnlock 函数的操作权限，可以让 lockers 对桥合约的锁定动作无效化，并且可以即时更新节点名单。目前 Hyperliquid 只存在 4 个验证者节点，被盗取私钥的可能性并不低； 2.finalizers 拒绝对用户的提款交易进行最终确认，展开审查攻击；种情况下用户资产不会被盗，但可能无法从桥合约中提款； 3.lockers 恶意定跨链桥，此时所有的提款交易都无法执行，只能等 coldValidatorSet 解锁； HyperEVM 与双链交互架构 为了让订单簿交易变的可编程化，比如引入隐私交易等需要智能合约来实现的场景，Hyperliquid 推出了名为HyperEVM 的方案。它相比于传统的 EVM 有两个特殊优势：一是 HyperEVM 可以读取 HyperLiquid 的订单簿状态，二是 HyperEVM 内的智能合约可以与 Hyperliquid 订单簿系统交互，这大大扩展了 Hyperliquid 的应用场景。 举一个简单例子，如果用户需要保证挂单操作的隐私性，此时可以在 HyperEVM 上通过类似 Tornado Cash 的智能合约套一层隐私，然后通过特定接口在 HyperLiquid 的订单簿系统中触发挂单动作。 在介绍 HyperEVM 前，我们需要介绍 Hyperliquid 为 HyperEVM 准备的特殊架构。由于 Hyperliquid 有定制化的超高性能订单薄系统，而 EVM 环境下的交易处理速度要慢很多。为了避免订单簿系统工作速度变慢，Hyperliquid 使用了“双链方案”，实质是让Hyperliquid节点设备在软件层面同时运行两条区块链，每个节点都在本地存放两条链的数据，对两条链的交易分别进行处理。 Hyperliquid 为其定制化的订单薄系统专门设置了一条链，同时增加了一条 EVM 兼容的链（HyperEVM）。这两条链的数据在节点群体间通过相同的共识协议来传播，作为一个统一的状态来存在，但在不同的执行环境中分别运行。我们称订单薄专用链为 Hyperliquid L1 (L1)，这条链是存在许可制的；而用于HyperEVM 的链为 HyperEVM（EVM），这条链是无许可的，任何人都可以部署合约，这些合约可以通过预编译代码来访问 L1 内的信息。 需要注意的是 Hyperliquid L1 的出块速度大于 HyperEVM 链，但这些区块仍会按顺序执行。EVM 链上的合约可以读取过往 L1 区块内的数据，并向未来的 L1 区块写入数据。如下图: 为了让 HyperL1 和 HyperEVM 之间实现交互，Hyperliquid 利用了 Precompiles 和 Events 两种技术手段。 Precompiles 所谓的预编译（Precompiles），说白了就是将一些在智能合约中不易实现、复杂度较高的操作直接挪到底层中实现，把对 Solidity 不友好、较为麻烦的计算流程挪到常规的智能合约外部去处理，这类预编译代码可以用 C、C++ 等比 Solidity 更贴近设备底层的语言来实现。 预编译的方式可以让 EVM 支持更高级更复杂的功能，便于支持智能合约开发者的需求。在表现形式上，预编译实质就是一组特殊的智能合约，其他智能合约可以直接调用这些特殊合约，传入参数并获得预编译执行的返回结果。目前原生 EVM 内就通过预编译的方式实现了 ecRecover 指令，可以在 EVM 内部检查 secp256k1 签名是否正确，而该指令就位于 0x01 地址内。 使用预编译增加一些特殊功能是目前的主流做法，比如 Base 就增加了 P256 预编译代码来方便用户进行 WebAuth 身份鉴权操作。 （此图来自 Rollup Codes 网站） 与这种目前的主流方案一致，HyperEVM 也增加了一系列的预编译代码来实现 EVM 对 Hyperliquid 订单薄系统状态的读取。目前已知的一个 Hyperliquid 的预编译代码地址是 0x0000000000000000000000000000000000000800 ，该预编译地址可以读取最近一个 L1 区块内的用户的永续合约的仓位情况。

Events

我们在上文提到 HyperEVM 可以向 HyperL1 区块内写入数据，写入行为就是依赖于 Events 实现的。Events 是 EVM 内的原生概念，它允许智能合约在执行过程中向外部（如前端应用或监听器）发送日志信息，便于外界监听智能合约的运行情况。

比如在用户使用 ERC-20 合约的代币转账功能时，合约会抛出Transfer相对应的 Event，以便于区块浏览器等前端应用获知代币转账情况。这些 Events 信息会被包含在区块内，而监听和检索 Events 日志都存在大量的成熟方案。

现在很多和跨链相关的场景都会使用 Events来传递跨链参数，比如 Arbitrum 部署在以太坊主网上的桥合约内，用户就可以调用相关函数抛出事件在 Arbitrum 上触发交易。 已知的信息表明，HyperLiquid 节点会监听 0x3333333333333333333333333333333333333333   ( 事件地址 ) 抛出的 Events，根据 Events 包含的信息获知用户意图，并据此将意图转化为交易动作，写入未来的 Hyperliquid L1 区块中。 比如，上述事件地址会提供一个函数，当用户调用此函数时，事件地址会抛出名为 IocOrder 的 Event。在 Hyper L1 区块产生时，HyperLiquid 节点会先查询最近 HyperEVM 内事件地址抛出的 Events，当检索到新的 IocOrder 事件时，就会将其转化为在 Hyper L1 内的挂单操作。 HyperBFT 在共识协议层面，Hyperliquid 采用了名为 HyperBFT的协议，这是一种基于 HotStuff 的衍生方法。目前 HutStuff-2 已经是最新的复杂度最低的几种共识协议之一。 根据 资料 显示，在最初 HyperLiquid 使用了 Tendermint 共识算法，是 Cosmos 系统内默认使用的共识算法，但该算法效率较低，每个阶段都需要 All-to-All 的消息交换，每个节点都要向所有其他节点发送消息，通信复杂度为O(n²)，其中n是节点的数量。 如果采用 Tendermint，Hyperliquid 每秒最多能处理 20,000 笔订单。为了达到中心化交易所的速度，HyperLiquid 团队基于 HotStuff 开发了 HyperBFT 算法，并将其用 Rust 实现，理论上每秒最多可处理 200 万笔订单。 下图展示了在非并行情况下的 HyperBFT 共识的消息传递方式，可以看到，所有的消息被 Leader 汇总并统一广播，免去了节点之间自行交换消息的步骤，大幅降低了复杂度。 简单来说，HyperBFT 就是当前的 leader 出块，全体节点参与投票并将投票结果统一发送给 Leader，再让下一个 leader 轮换的共识协议。实际上 Hotstuff 和 Tendermint 涉及的具体细节要复杂的多，本文受限于篇幅和侧重点不在此赘述。 对开发者而言需要注意的要点 上述基于 Precompiles 的数据读取机制是比较完美的，Solidity 开发者读取 Hyper L1 状态时不需要专门编写相应的代码，但是需要注意 msg.sender 的问题。与大部分以太坊二层类似，HyperLiquid 也允许用户直接与 Hyper L1 内的系统合约交互，间接触发在 HyperEVM 链上的交易动作，此时如果智能合约在该交易内读取 msg.sender 字段，会发现 msg.sender 对应的是 HyperL1 系统合约的地址，而不是最开始在 HyperL1 上发起交易的用户地址。 而对于 EVM与L1 的交互，开发者需要注意一系列问题。第一个问题是交互的非原子性问题，假如用户在 HyperEVM 上通过前述事件地址，间接在 L1 内挂单，但 L1 内并没有充分的资产，那么该交易肯定会失败，但用户调用事件地址的函数时不会有错误返回提示。交互的非原子性问题可能导致用户的资产受损。此时对于开发者而言，需要在 EVM 智能合约端手动处理挂单失败的情况。而且 EVM 内的智能合约应该有用于最终资金收回的函数，避免用户资产在 L1 内永远无法提取出来。 其次，EVM 对应的合约地址在 L1 内必须存在映射账户，当用户在 EVM 内部署完成智能合约后，需要在 L1 内向映射地址转入少量 USDC，迫使 L1 为合约地址创建账户。该部分操作可能与 HyperLiquid 的底层共识相关，在 Hyperliquid 的文档中有明确要求。 最后，开发者需要注意一些特殊情况，特别是代币的余额情况。Hyper L1 存在一个特殊地址用于资产转移，但用户将资产发送到该特殊地址时，资产就会从 L1 跨到 HyperEVM 链内。由于 HyperLiquid 节点实际上同时执行 EVM 链和 L1 链，可能在用户转移资产后 HyperEVM 仍许久未出块，此时用户在 EVM 链上无法读到自己的余额。 简单来说，此时的用户资产卡在的跨链桥内，无论是在 L1 还是 EVM 链内都无法查询，开发者构建的协议应当处理上述特殊情况，避免用户产生恐慌情绪。 总结来看，HyperEVM 类似于基于Hyperliquid L1的二层，HyperEVM 依赖于预编译代码读取 L1 状态，也依赖于 Events 来与 Hyper L1产生交互。L1 也存在一些系统合约帮助用户在HyperEVM 内触发交易，或是进行资产跨链。但与一般的 Layer1——Layer2 架构不同，Hyperliquid 为 HyperEVM 提供了更高的互操作性。 参考资料

1. Hyperliquid: The Hyperoptimized Order Book L1
2. hyperliquid-dex/contracts
3. The Not-So-Definitive guide to Hyperliquid Precompiles.
4. What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?