深入解析Hyperliquid:技術架構與潛在風險

Hyperliquid作爲一個備受關注的鏈上訂單簿交易所,其技術架構和安全性值得深入探討。本文將從跨鏈橋合約結構、HyperEVM與HyperL1雙鏈架構兩個角度,對Hyperliquid的技術實現進行分析。

Hyperliquid跨鏈橋分析

Hyperliquid在Arbitrum上部署了一個橋合約來存儲用戶的USDC資產。該橋合約包含四組驗證者:hotValidatorSet、coldValidatorSet、finalizers和lockers,分別負責不同的職能。

驗證者機制

• hotValidatorSet:處理高頻操作如用戶提款
• coldValidatorSet:修改系統配置,可無效化提款請求
• lockers:可投票暫停橋合約運行
• finalizers:確認跨鏈橋狀態變化

目前Hyperliquid只有4個驗證者節點,hotValidatorSet和coldValidatorSet各對應4個地址。

存款流程

橋合約使用EIP-2612的Permit方法處理存款,只允許存入USDC。batchedDepositWithPermit函數可批量處理多筆存款,流程較爲簡單。

提款流程

提款請求需滿足以下條件:

1. 獲得hotValidatorSet的2/3籤名權重
2. 經過200秒爭議期
3. 由finalizers成員最終確認

在爭議期內,lockers可投票暫停橋合約,coldValidatorSet可無效化提款請求。

橋合約鎖定機制

2名lockers投票即可鎖定橋合約。解鎖需要coldValidatorSet的2/3籤名權重,同時可更新驗證者地址。

驗證者更新

updateValidatorSet函數可更新hotValidatorSet和coldValidatorSet,需要所有hotValidatorSet成員籤名,並經過200秒爭議期。

潛在風險

1. coldValidatorSet被控制可繞過所有防線盜取用戶資產
2. finalizers可能拒絕確認提款交易
3. lockers可能惡意鎖定橋合約

HyperEVM與雙鏈架構

Hyperliquid採用"雙鏈方案",同時運行兩條鏈:

1. Hyperliquid L1:專用於訂單簿系統,許可制
2. HyperEVM:EVM兼容鏈,無許可

兩鏈通過相同共識協議傳播數據,但在不同執行環境運行。HyperEVM可讀取L1狀態並向L1寫入數據。

Precompiles

HyperEVM通過預編譯代碼讀取L1狀態。已知的預編譯地址0x800可讀取最近L1區塊的用戶永續合約倉位。

Events

HyperEVM通過Events向L1寫入數據。L1節點監聽特定地址(0x3333...3333)的Events,將用戶意圖轉化爲L1交易。

HyperBFT共識

Hyperliquid採用基於HotStuff的HyperBFT共識算法,理論上每秒可處理200萬筆訂單。

開發注意事項

1. msg.sender可能是L1系統合約地址
2. EVM與L1交互非原子性可能導致資產損失
3. EVM合約地址需在L1有映射帳戶
4. 資產跨鏈時可能出現暫時無法查詢餘額的情況

總體而言,HyperEVM類似於基於Hyperliquid L1的二層,但提供了更高的互操作性。