深入探究Hyperliquid的技術構造與安全隱患

近期廣受關注的Hyperliquid是最有影響力的鏈上訂單簿交易所之一,其總鎖倉價值已超20億美元,被業內評價爲"鏈上版某知名中心化交易所",同時也重新引發了人們對Layer3和應用鏈的討論。憑藉上線一個月內項目估值達300億美元的亮眼表現,Hyperliquid獲得了廣泛關注。目前市場上已有不少關於Hyperliquid的分析報告,但多數集中在產品功能和交易機制方面,缺乏對其技術架構和潛在安全隱患的深入剖析。

本文旨在填補這一空白,純粹從技術和安全角度對Hyperliquid進行解析,幫助讀者更好地理解這一明星項目的內部構造和原理。我們將重點分析Hyperliquid跨鏈橋合約的設計與風險,以及HyperEVM與HyperL1的雙鏈架構,深入探討其背後的技術實現方式。

Hyperliquid跨鏈橋解析

由於Hyperliquid並未開源其核心組件,但開源了相關的橋合約,因此我們對橋合約方面的風險有更多了解。Hyperliquid在某Layer2網路上部署了一個橋合約,用於存儲用戶存入的USDC資產,我們可以通過Bridge組件觀察到Hyperliquid節點的部分行爲。

驗證者集合

從節點身分劃分來看,Hyperliquid有4組驗證者,分別是hotValidatorSet、coldValidatorSet以及finalizers和lockers,各自承擔不同職責。hotValidatorSet負責響應用戶的高頻操作如提款等,通常使用熱錢包以便及時處理用戶請求。

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的橋合約基於EIP-2612的Permit方法處理用戶存款,且僅支持USDC一種資產。相比傳統Approve-Transfer模式,Permit更爲簡潔,便於批量操作。

橋合約使用batchedDepositWithPermit函數批量處理多筆存款,流程簡單且無資金安全風險,主要是利用Permit方法優化用戶體驗。

提款

相較存款,提款是高風險操作,因此邏輯更爲復雜。用戶發起提款請求後,Hyperliquid節點調用橋合約的batchedRequestWithdrawals函數。此時要求每筆提款請求獲得hotValidatorSet的2/3籤名權重,注意是"2/3籤名權重"而非"2/3籤名數量"。目前Hyperliquid僅有4個權重相同的節點,故檢查籤名權重與籤名數量暫時一致,但未來可能引入高權重節點。

發起提款請求後,跨鏈橋不會立即轉移USDC,而是有200秒的"爭議期"。在此期間可能出現兩種情況:

1. lockers認爲提款請求存在嚴重問題,可直接投票凍結合約;

2. 節點認爲部分提款有問題,coldValidatorSet成員可調用invalidateWithdrawals函數使該筆提款無效。

若爭議期內無異常,期滿後finalizers成員可調用batchedFinalizeWithdrawals函數確認最終狀態,此時USDC才會轉入用戶在Layer2的錢包地址。

從安全模型角度看,惡意攻擊者若要在Hyperliquid提款流程中作惡,需突破三道防線:

1. 掌握hotValidatorSet的2/3籤名權重,即獲取足夠私鑰或串謀。目前僅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成員籤名,且有200秒爭議期。

爭議期結束後,需finalizers成員調用finalizeValidatorSetUpdate函數完成最終更新。

總結Hyperliquid橋合約存在以下風險:

1. 黑客控制coldValidatorSet後可無視阻攔盜取用戶資產。因coldValidatorSet擁有emergencyUnlock權限,可使lockers鎖定無效並即時更新節點名單。目前僅4個驗證者節點,私鑰被盜風險不低;

2. finalizers拒絕確認用戶提款交易,展開審查攻擊。此時用戶資產安全但可能無法提取;

3. lockers惡意鎖定跨鏈橋,阻止所有提款交易執行,只能等coldValidatorSet解鎖。

HyperEVM與雙鏈交互架構

爲實現訂單簿交易的可編程化,如引入隱私交易等需智能合約支持的場景,Hyperliquid推出HyperEVM方案。它較傳統EVM有兩大優勢:可讀取Hyperliquid訂單簿狀態,且內部智能合約可與訂單簿系統交互,大幅拓展了應用場景。

例如,用戶若需保證掛單隱私性,可在HyperEVM上通過類似Tornado Cash的合約添加隱私層,再通過特定接口在Hyperliquid訂單簿系統觸發掛單。

Hyperliquid爲HyperEVM設計了特殊架構。考慮到定制化訂單簿系統性能遠超EVM環境,爲避免速度下降,Hyperliquid採用"雙鏈方案":每個節點同時運行兩條鏈,本地存儲兩鏈數據並分別處理交易。

Hyperliquid爲訂單簿系統設置專用鏈(HyperL1,許可制),同時增設EVM兼容鏈(HyperEVM,無許可)。兩鏈數據通過相同共識協議傳播,作爲統一狀態存在,但在不同環境中運行。HyperL1出塊速度快於HyperEVM,但區塊仍按序執行。EVM鏈上合約可讀取過往L1區塊數據,並向未來L1區塊寫入數據。

HyperL1和HyperEVM交互主要通過Precompiles和Events實現。

Precompiles

預編譯(Precompiles)將復雜操作直接在底層實現,用C/C++等語言處理Solidity不友好的計算。預編譯本質是特殊智能合約,其他合約可調用並獲取執行結果。目前原生EVM已用預編譯實現ecRecover指令(0x01地址)。

HyperEVM也增加了預編譯代碼,實現對Hyperliquid訂單簿系統狀態的讀取。已知一個預編譯地址爲0x0000000000000000000000000000000000000800,可讀取最近L1區塊內用戶永續合約倉位。

Events

HyperEVM向HyperL1寫入數據依賴Events實現。Events是EVM原生概念,允許合約向外部發送日志信息。如ERC-20轉帳時會拋出Transfer事件,便於監聽。許多跨鏈場景也用Events傳遞參數。

HyperLiquid節點監聽0x3333333333333333333333333333333333333333地址拋出的Events,根據信息獲知用戶意圖並轉化爲交易動作,寫入未來L1區塊。如該地址提供函數,調用時拋出IocOrder事件,L1出塊時節點檢索到新IocOrder事件就轉化爲L1內掛單操作。

HyperBFT

共識協議方面,Hyperliquid採用基於HotStuff衍生的HyperBFT協議。初期使用Tendermint算法,但效率低下,每階段需All-to-All消息交換,復雜度O(n²)。

爲達到中心化交易所速度,團隊開發HyperBFT並用Rust實現,理論上每秒可處理200萬筆訂單。HyperBFT中所有消息由Leader匯總廣播,免去節點間交換消息,大幅降低復雜度。

簡言之,HyperBFT是當前leader出塊,全體節點投票並將結果統一發給Leader,再輪換下一leader的共識協議。

開發者注意事項

1. 基於Precompiles的數據讀取機制較完善,但需注意msg.sender問題。用戶與L1系統合約交互間接觸發EVM交易時,EVM內msg.sender爲L1系統合約地址而非用戶地址。

2. EVM與L1交互存在非原子性問題。如用戶通過EVM在L1掛單但資產不足,交易失敗但調用函數時無錯誤提示。開發者需在EVM合約端處理掛單失敗情況,並設置資金收回函數。

3. EVM合約地址在L1需有映射帳戶。部署EVM合約後,需向L1映射地址轉少量USDC創建帳戶。

4. 注意特殊情況如代幣餘額。L1有特殊地址用於資產跨鏈,但跨鏈後EVM可能未及時出塊,用戶暫時無法讀取餘額。開發者應處理此類情況避免用戶恐慌。