超流動性中的集中控制

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 ，人們正在那裡通過突出顯示和回應這篇文章來繼續討論。