Hyperliquid技術解讀：橋合約、HyperEVM及其潛在問題
作者：Shew，仙壤GodRealmX
近期廣受市場關注的Hyperliquid是最有影響力的鏈上訂單薄交易所之一，其TVL已超過20億美元，在被Messari評價為“鏈上Binance”的同時，甚至還把本已淡出大眾視角的Layer3、應用鏈敘事重新拉回聚光燈下。憑借著Token上線一個月內FDV拉至300億美元的輝煌成績，Hyperliquid獲得了從普通用戶到從業人員的廣泛關注，與此同時市面上也涌現出了大量關于Hyperliquid的研報，但這些文章基本聚焦于其在訂單簿產品功能和交易機制上的特點，沒有深入探究其背后的技術構造以及安全隱患。
本文作者旨在補足這一空缺，單純從技術構造與安全的角度來考察Hyperliquid，幫助更多人理解這一明星項目的結構與原理。我們將從Hyperliquid跨鏈橋合約的構造與隱患、HyperEVM與HyperL1雙鏈構造兩大角度展開闡述，幫助大家深入理解其背后的技術架構與實現方式。
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的提款流程中做手腳，就需要突破三道防線:
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驗證者地址集合，并且會立即更新。
Precompiles
所謂的預編譯（Precompiles），說白了就是將一些在智能合約中不易實現、復雜度較高的操作直接挪到底層中實現，把對Solidity不友好、較為麻煩的計算流程挪到常規的智能合約外部去處理，這類預編譯代碼可以用C、C++等比Solidity更貼近設備底層的語言來實現。
預編譯的方式可以讓EVM支持更高級更復雜的功能，便于支持智能合約開發者的需求。在表現形式上，預編譯實質就是一組特殊的智能合約，其他智能合約可以直接調用這些特殊合約，傳入參數并獲得預編譯執行的返回結果。目前原生EVM內就通過預編譯的方式實現了ecRecover指令，可以在EVM內部檢查secp256k1簽名是否正確，而該指令就位于0x01地址內。
使用預編譯增加一些特殊功能是目前的主流做法，比如Base就增加了P256預編譯代碼來方便用戶進行WebAuth身份鑒權操作。
現在很多和跨鏈相關的場景都會使用Events來傳遞跨鏈參數，比如Arbitrum部署在Ethereum主網上的橋合約內，用戶就可以調用相關函數拋出事件在Arbitrum上觸發交易。
下圖展示了在非并行情況下的HyperBFT共識的消息傳遞方式，可以看到，所有的消息被Leader匯總并統一廣播，免去了節點之間自行交換消息的步驟，大幅降低了復雜度。
簡單來說，HyperBFT就是當前的leader出塊，全體節點參與投票并將投票結果統一發送給Leader，再讓下一個leader輪換的共識協議。實際上Hotstuff和Tendermint涉及的具體細節要復雜的多，本文受限于篇幅和側重點不在此贅述。
對開發者而言需要注意的要點
上述基于Precompiles的數據讀取機制是比較完美的，Solidity開發者讀取HyperL1狀態時不需要專門編寫相應的代碼，但是需要注意msg.sender的問題。與大部分Ethereum二層類似，HyperLiquid也允許用戶直接與HyperL1內的系統合約交互，間接觸發在HyperEVM鏈上的交易動作，此時如果智能合約在該交易內讀取msg.sender字段，會發現msg.sender對應的是HyperL1系統合約的地址，而不是最開始在HyperL1上發起交易的用戶地址。
而對于EVM與L1的交互，開發者需要注意一系列問題。第一個問題是交互的非原子性問題，假如用戶在HyperEVM上通過前述事件地址，間接在L1內掛單，但L1內并沒有充分的資產，那么該交易肯定會失敗，但用戶調用事件地址的函數時不會有錯誤返回提示。交互的非原子性問題可能導致用戶的資產受損。此時對于開發者而言，需要在EVM智能合約端手動處理掛單失敗的情況。而且EVM內的智能合約應該有用于最終資金收回的函數，避免用戶資產在L1內永遠無法提取出來。
其次，EVM對應的合約地址在L1內必須存在映射賬戶，當用戶在EVM內部署完成智能合約后，需要在L1內向映射地址轉入少量USDC，迫使L1為合約地址創建賬戶。該部分操作可能與HyperLiquid的底層共識相關，在Hyperliquid的文檔中有明確要求。
最后，開發者需要注意一些特殊情況，特別是Tokens的余額情況。HyperL1存在一個特殊地址用于資產轉移，但用戶將資產發送到該特殊地址時，資產就會從L1跨到HyperEVM鏈內。由于HyperLiquid節點實際上同時執行EVM鏈和L1鏈，可能在用戶轉移資產后HyperEVM仍許久未出塊，此時用戶在EVM鏈上無法讀到自己的余額。
簡單來說，此時的用戶資產卡在的跨鏈橋內，無論是在L1還是EVM鏈內都無法查詢，開發者構建的協議應當處理上述特殊情況，避免用戶產生恐慌情緒。
總結來看，HyperEVM類似于基于HyperliquidL1的二層，HyperEVM依賴于預編譯代碼讀取L1狀態，也依賴于Events來與HyperL1產生交互。L1也存在一些系統合約幫助用戶在HyperEVM內觸發交易，或是進行資產跨鏈。但與一般的Layer1——Layer2架構不同，Hyperliquid為HyperEVM提供了更高的互操作性。
參考資料
Hyperliquid:TheHyperoptimizedOrderBookL1
hyperliquid-dex/contracts
TheNot-So-DefinitiveguidetoHyperliquidPrecompiles.
WhatisthedifferencebetweenPBFT,Tendermint,HotStuff,andHotStuff-2?