超流动性中的集中控制

Hyperliquid 是一个备受瞩目的永续期货交易所，在 Web3 媒体上广受关注，交易量庞大。它自称是去中心化的，但正如很多时候一样，对于任何合理的「去中心化」定义而言，这都不是事实。该系统官方是闭源的，这本身就足以构成一个危险信号，毕竟它标榜自己是透明开放的。但我们甚至无需泄漏原始码就能看出，该团队对用户资金拥有完全独立的控制权。

我们无需深入研究托管其永续期货交易平台的「Hyperliquid L1」平台。只要查看几个原始码已公开的智慧合约，我们就能得出证明该团队完全控制该平台所需的一切资讯。通常情况下，这一切都围绕著该团队（且仅该团队）如何发动攻击以侵吞几乎所有用户资金。

现在我们开始吧。首先，我们会概述一下平台的工作原理，并重点介绍他们的桥接功能。然后，我们会提供一些数据，作为架构讨论和集中化讨论之间的桥梁。最后，我们会就法律方面的情况做一些简要说明。

超流动性的工作原理

虽然 Hyperliquid 的核心程式码是封闭原始码的，但我们可以透过Arbitrum存取其桥接合约，这让我们对 Hyperliquid 的工作原理有了很多了解。特别是，我们可以证明以下几点：

1. 这款桥接器不依赖零信任设计，实际上它根本不是无需信任的。
2. 设有纠纷解决机制。
3. 它不是有效期，因为有争议期。它也不是零开式设计。所以，它大概类似乐观汇总，或是属于某种乐观总结。
4. 安全性主要取决于保密性，因为争议解决期只有200秒。试想一下，这200秒是在必要时采取非常规措施以确保约60亿美元资金安全的时间。相较之下， Arbitrum和Optimism的争议解决期都约为一周。
5. Hyperliquid 团队积极管理此桥接器。
6. 所有提款申请都必须经过 Hyperliquid 团队的批准。
7. 闭源 Hyperliquid 链上的验证者集合与桥接器识别的验证者集合并不关联，或至少关联性不强。 Hyperliquid 在这方面经常滥用术语。

最后要注意的是，虽然200秒的申诉期听起来很短，但实际上外部人员根本无法使用申诉流程。如果没有衡量标准，你又能申诉什么呢？有些所谓的「技术」简直就是个笑话。

桥梁设计

我们只能看到 Hyperliquid 桥接器中Arbitrum端的程式码。因此，分析该产品最简单的方法就是观察Arbitrum端的运作。

当争议期发生变更时，桥接器会发出一个包含 newDisputePeriodSeconds 栏位的 ChangedDisputePeriodSeconds 事件。这表明存在争议期，并且可能存在某种争议解决流程。我们知道此争议期已强制执行，因为桥接器已发出一个错误代码为 4 的 FailedWithdrawal 事件。如果您查看程式码，您会在 getDisputePeriodErrorCode() 函数内部发现：

 bool enoughBlocksPassed = (curBlockNumber - blockNumber) * blockDurationMillis > 1000 * disputePeriodSeconds;
如果（!enoughBlocksPassed）{
返回 4；
 }

因此，错误代码为 4 的提现失败情况是指提现请求过快而被拒绝。争议期的存在表明该设计并非纯粹的零知识证明（ZK），因为如果提现由零知识证明所有权控制，则无需争议解决机制。虽然我们无法直接评论 Hyperliquid 本身的设计，但这强烈暗示它并非基于零知识证明的设计。

这座桥梁还有一套独特的纠纷解决程序，具体运作方式如下：

1. 提出提款申请后，争议期开始。
2. 管理员可以呼叫 invalidateWithdrawals() 来阻止待处理的提款。
3. 争议期结束后，任何仍有效的提款都可以进行。

这与其说是争端解决，不如说是一种粗暴的集中控制。用L2Beat 的术语来说，这是第 0 阶段。对于不熟悉 L2Beat 阶段划分术语的人来说，这意味著如果将 Hyperliquid 算作 L2 级别，L2Beat 会将其归类为集中式且带有「 辅助轮」的平台。

正如我们将在下文看到的，Hyperliquid 团队在链下运行这些流程，而且没有任何管理环节是自主的。虽然 Hyperliquid 的自动化是透过软体实现的，但其自动化方式与所有银行软体的自动化方式相同：都存在人工控制，并且幕后还有类似 Oz 的操作员。用 l2beat 的术语来说，这也是一个阶段 0 的特征。我们并非在此开辟新领域，而只是将广泛接受的框架和定义应用于一个包含许多熟悉组件的产品。

超液体是什么？

Hyperliquid 自称是 Layer-1 区块链。鉴于所有资产都来自Arbitrum上的单一桥接合约（Arbitrum 是以太坊 Layer-2 区块链），从某种意义上说，它属于 Layer-3。而我们从上面的分析可知，它既不是zk Rollup ，也不是 Validium。那么，它究竟是什么呢？

这使得我们的选择寥寥无几。它可能是一种乐观Rollup，或某种形式的等离子链，也可能是某种侧链。它也可能是由这些方案混合而成的。但请注意，虽然存在争议解决流程，但对于该机制如何运作或具体可以争议哪些内容，并没有公开的规范。

即使流程只是一个标准的乐观Rollup，除了团队之外，任何人也无法提出异议，所以这些都无关紧要。实际上，这只是一个完全由团队控制的0阶段三层区块链。该软体（再次强调，它大部分是闭源的）可能拥有类似Plasma、侧炼或其他类似技术的资料结构和函数名称，但实际上它只是一个托管多重签章系统，外加一些不必要的程式码。

从团队的角度来看，这些程式码或许是必要的，他们可能也对这些程式码感到非常自豪。但对外部观察者而言，这一切都无关紧要，因为这些代码都存在于一个封闭的生态系统中。当研究人员被迫猜测超流动性的某些部分是如何运作以进行分析时，就已经预示著问题的出现​​。但理论上，人们可以拥有一个自主的、去中心化的系统，而这个系统本身也是一个黑箱。使用者至少在机械层面上可以注册并接受他们既看不到也无法理解的流程结果。

诚然，对于期货交易所而言，此类合约的可执行性尚不明确，但起草文件却十分容易。然而，正如我们在此探讨的，我们可以看到管理人员对「黑箱」系统采取了管理措施。这就改变了局面。现在，举证责任在于这些管理人员，他们必须证明自己没有中央控制权。或者，就像本案一样，我们可以提供先发制人的证据来驳斥任何此类主张。

桥梁管理

我们可以看到 Hyperliquid 团队在桥接合约中呼叫了以下 5 个管理函数，这些函数的功能如其名称所示：

• changeDisputePeriodSeconds()
• 修改终结器()
• 修改锁定器()
• voteEmergencyLock() 会发出一个「Paused」事件
• emergencyUnlock() 会发出一个「Unpaused」事件

此桥接器也维护验证器集讯息，Hyperliquid 团队可以使用 `updateValidatorSet()` 和 `finalizeValidatorSetUpdate()` 函数对其进行操作。验证器集分别于 2023 年 12 月和 2024 年 10 月进行了维护。随后，在 2025 年 4 月 22 日，Hyperliquid 团队宣布将扩充验证器集，但并未发出对应的 `RequestedValidatorSetUpdate` 和 `FinalizedValidatorSetUpdate` 事件。

这意味著桥接器所知的验证者集合并未同时改变。数月过去，验证者集合仍未更新，证明 Hyperliquid 区块炼和桥接器之间验证者集合的（可信任）同步并非必要。公开声明中关于验证者集合的资讯与实际操作验证者集合的功能之间似乎存在差距。

这是一个明显的警示信号，表明这里滥用了术语。 Arbitrum所托管的桥合约有验证者集合，而Hyperliquid平台也有验证者集合。透过比较这两个集合的更新历史，我们可以发现它们并非完全相同。这里存在著两种不同的「验证者集合」概念。即使Hyperliquid声称它们是相同的，我们也可以自行发现它们并未保持同步。

团队批准提款

如果我们查看桥牌合约活动，会发现一系列如下函数呼叫：

• 批量存入（带许可）
• 批量请求提款()
• 批量完成提款()

存款流程会启动从存款人到桥接器的转帐。如果存款人帐户中有足够的资金，存款即可完成登记。这个工作流程很简单。

但提现流程就复杂得多。提现要成功，必须先提出申请，然后才能最终完成，而这两个步骤都需要足够数量的系统「验证者」签名。验证者清单由上文讨论过的桥接器管理功能控制。这些验证者就是我们已知与 Hyperliquid 区块链不同步的 Arbitrum 端验证者。

存款由使用者发起，无需Hyperliquid中心实体及其软体的配合。自系统上线以来，已有超过300个地址发起存款。另一方面，提款请求会集中处理，并由团队独家完成最终结算。截至2025年中期资料准备阶段，所有提款请求和最终结算均由4个Hyperliquid控制的地址负责，每个地址的提款请求次数约为20万次。这些地址是：

 | 位址 | 请求 | 最终确定 |
 |-------------------------------------------|---------|--------|
 |0x58e1b0e63c905d5982324fcd9108582623b8132e | 201,581 | 201,581 194,557|
 |0xef2364db5db6f5539aa0bc111771a94ee47637fc | 201,779 | 201,779 194,418|
 |0x263294039413b96d25e4173a5f7599f8b3801504 | 201,294 | 201,294 194,508|
 |0xda6816df552c3f9e0fb64979fb357800d690d79b | 200,921 | 200,921 195,196|

这些位址是由另一个显然由该团队控制的位址 0x1D4c01E15A637cB3cbaF86fFbb02E5A260D01fbc 新增为验证者的。所有这些都可以从公开管道获取，无需使用系统中任何闭源期货交易所的资讯。

我们知道这些地址一定都属于团队，因为这些地址记录了自上线以来处理的所有提现请求。这些地址并非在上线几周或几个月后，在所谓的逐步去中心化过程中添加的。这些地址就是全部。如果确实存在一个团队——而且显然存在——那么这些位址理应被视为 Hyperliquid 团队的一部分，因为它们是唯一设定过提现限制的位址。

只有当桥合约收到足够数量验证者的签名时，这些请求才会被接受。而目前的验证者集合，同样由团队关联的地址控制。团队控制的唯一限制是，管理更新会经历一个争议期，在此期间更改无法最终生效。这个争议期为200秒。如果团队决定擅自行动，理论上，在这200秒内，有人或许可以要求提现或试图提交使某些内容无效的请求。但实际上，这个过程也不对外开放。只有验证者才能阻止这种情况发生。再次强调，「争议」过程不过是一场闹剧，这一切都只是一场大规模的多重签名。

因此，我们现在知道提现功能完全由Arbitrum上的团队验证者位址控制。虽然上述分析已确凿地证明了这一点，但它并非完全隐藏。团队在 Hyperliquid 上的验证者位址是公开记录的，而且使用不同位址的相同名称在Arbitrum端也被公开标记​​为验证者：

• 0xef2364db5db6f5539aa0bc111771a94ee47637fc
• 0xda6816df552c3f9e0fb64979fb357800d690d79b
• 0x58e1b0e63c905d5982324fcd9108582623b8132e
• 0x263294039413b96d25e4173a5f7599f8b3801504

并且自从团队承认他们控制的地址成为唯一验证者以来，该系统一直在运作。

如上所述，存在争议期和争议解决流程。当管理员未取消任何提现请求时，请求和最终确认功能呼叫会贯穿整个流程。发起这些呼叫的位址是EOA（执行物件位址）。因此，这些呼叫要么是手动签名，要么是透过团队授权存取其私钥的链下流程签名，这进一步证明了Hyperliquid的运作既非完全自动化也非去中心化。它可能是自动化的——但这种自动化就像烤箱定时器一样：由人们设定、控制并且可以关闭。

请注意，这个审批步骤——即团队透过链下流程审批提现——显然容易受到 DDoS 攻击及类似攻击，而我们已知委托计划参与者使用的资料中心，这更增加了攻击的难度。虽然这并不能保证 Hyperliquid 也使用相同的资料中心，但这些资料中心无疑是攻击者首先会寻找的目标。正如团队在下文中讨论的 API 存取问题，我们知道这是一个真实存在的问题，而不仅仅是理论上的问题。

文件中提到系统运行在“日本东京”，这也为我们提供了资料中心位置的线索。检查提供的公网 IP 位址表明，该系统运行在东京的 AWS 或微软资料中心（或两者都有）。

2025年7月停电

2025年7月29日，Hyperliquid发生服务中断。团队透过Discord提供了有限的支援和资讯。其中一位创办人公开表态，明确表示他们知道自己是这个系统的运作者：

请注意，他们将API伺服器而非区块链节点视为问题的根源。由于您无法编译和运行自己的程式码来参与网络，因此这种区别并无实际意义。

值得注意的是，该团队经常进行此类控制：

让系统停机 10 分钟，其控制力与修复导致系统中断的根本问题不相上下。尤其当停机时间能让团队有机会修复软体问题时，这种控制力就更加显著了。有时你可能会觉得团队真的不了解他们所拥有的控制权。例如，许多 DEX 路由器赋予管理员足够的权限来瘫痪系统，即使许多开发人员似乎还没有意识到这一点。 Hyperliquid 则不然。这个团队深知自己拥有控制权，并且经常行使这种控制权。

团队的大部分链下基础设施在服务中断期间仍在运作。我们可以看到，即使 API 出现问题，提现审批仍在继续：

这揭示了该团队利用其控制权操纵交易的简单方法。如果API对所有用户都失效，那么该团队完全可以自行关闭API，然后进行交易。透过控制交易权限和提款审批，该团队可以操纵Hyperliquid平台上的市场，将所有已提交的抵押品据为己有，而Arbitrum方却无需承担任何可疑行为。由于Hyperliquid平台是闭源且不透明的，外部人员甚至可能无法重现并证实此类事件的真相。

如果该团队精心策划了这次“攻击”，目的是将抵押品转移到期货交易所内由其控制的地址，那么整个事件看起来可能就像是一次大规模的交易，伴随著一些引人注目的反洗钱行动，然后少数赢家从一个去中心化系统中提取了他们的利润。而目前没有任何纠纷解决机制可以阻止这种情况发生。

中央控制

这确立了团队的完全中心化控制。值得注意的是，无需根据 Hyperliquid 平台区块链的去中心化程度（或缺乏去中心化）来更新验证者集合。为什么？因为 Hyperliquid 团队有能力主动阻止提现，所以方法是使其无效。当然，团队无论如何都必须在链下启动所有剩余「有效」请求的审批。因此，系统的闭源部分也无需纳入讨论，即可建立团队的完全独立控制。该系统的运作方式使得团队能够对其自身桥两端的资金行使完全独立的控制权。

增加一个攻击途径——例如，由于平台的非 Arbitrum 部分是闭源的，并且完全由团队控制，他们也可以透过操纵市场来窃取用户资产——对这里的「去中心化」没有帮助。

综上所述：

1. 在 Hyperliquid 的整个生命周期中，只有 4 个团队控制的位址批准了所有提款请求。
2. 只有经过团队批准的验证者才能对 Hyperliquid 进行更改或对待处理的操作提出异议。
3. 团队可以随时有效地更改验证器集，可能存在一段短暂的延迟期，在此期间，除了团队之外的任何人都无法进行任何更改。
4. 该团队可以随意透过多种方式窃取所有用户存入的资金，目前约为 60 亿美元。

Hyperliquid 会介绍他们的验证者集合，并报告一组验证者的指标。其他方也会讨论如何成为 Hyperliquid 的验证者。甚至还有一个类似 Hyperliquid 验证者产业协会的组织。但所有这些都与 Hyperliquid 的闭源区块链有关，而不是与持有所有实际资金的Arbitrum平台有关。 Hyperliquid 使用「验证者」一词来指称两种不同的意义，并且没有谨慎地区分它们。

愤世嫉俗者可能会说，他们小心翼翼地将两者混淆。下次他们再搞这种骗局时，我们建议他们至少应该协调流程中公开可见部分（即Arbitrum上的验证器集）的变更与私有部分的变更，即使从技术上讲，这样做并没有什么必要。这样的协调能更好地维持去中心化的假象。

目前来看，我们可以将托管 Hyperliquid 永续期货交易所的闭源区块链上的验证，与Arbitrum智能合约的中心化验证者集合的验证区分开来。一旦你了解了系统的运作方式，你就能将它们区分开来。所有这些噪音充其量只是为了转移人们对系统运作方式的注意力。

团队也承认他们对系统的其他部分拥有控制权，甚至愿意为因团队问题造成的损失提供退款。如果Arbitrum上由该团队控制的一小部分地址就能完全独立地控制该项目约60亿美元的USDC存款，那么该团队为何认为这些问题尤为重要，这一点尚不清楚。善意固然可贵，但它也可能是一种认罪。尤其当这种善意与暴露出另一个攻击途径的事件有关时，更是如此。

整个系统似乎都在新加坡运营，因为根据 Hyperliquid Labs 自身的文件，该公司是开发实体，并且是一家在新加坡注册的公司。同一实体代表 Hyperliquid 签署了提交给美国商品期货交易委员会 (CFTC) 的意见书：

所以这家公司打算透过一个中央平台，为全球客户提供无需KYC验证的杠杆交易，并托管客户资金。有意思。

《超流动性中的集中控制》一文最初发表于 Medium 上的ChainArgos ，人们正在那里通过突出显示和回应这篇文章来继续讨论。