炒作退潮，從技術角度解讀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提供了更高的互操作性。

參考資料

Hyperliquid: The Hyperoptimized Order Book L1

hyperliquid-dex/contracts

The Not-So-Definitive guide to Hyperliquid Precompiles.

What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。