作者:Shew,仙壤GodRealmX
近期廣受市場關(guān)注的Hyperliquid是最有影響力的鏈上訂單薄交易所之一,其TVL已超過20億美元,在被Messari評價為“鏈上Binance”的同時,甚至還把本已淡出大眾視角的Layer3、應(yīng)用鏈敘事重新拉回聚光燈下。憑借著Token上線一個月內(nèi)FDV拉至300億美元的輝煌成績,Hyperliquid獲得了從普通用戶到從業(yè)人員的廣泛關(guān)注,與此同時市面上也涌現(xiàn)出了大量關(guān)于Hyperliquid的研報,但這些文章基本聚焦于其在訂單簿產(chǎn)品功能和交易機制上的特點,沒有深入探究其背后的技術(shù)構(gòu)造以及安全隱患。
本文作者旨在補足這一空缺,單純從技術(shù)構(gòu)造與安全的角度來考察Hyperliquid,幫助更多人理解這一明星項目的結(jié)構(gòu)與原理。我們將從Hyperliquid跨鏈橋合約的構(gòu)造與隱患、HyperEVM與HyperL1雙鏈構(gòu)造兩大角度展開闡述,幫助大家深入理解其背后的技術(shù)架構(gòu)與實現(xiàn)方式。
finalizers其實也是一組特殊的驗證者,主要用于確認(rèn)跨鏈橋的狀態(tài)變化,從合約層面來看主要確認(rèn)的就是用戶存款和提款。Hyperliquid的跨鏈橋使用“提交-確認(rèn)”機制,比如用戶發(fā)起提款后并不會被立即執(zhí)行,需要等待一段時間(這段時間被稱為爭議期)。等待爭議期結(jié)束后,finalizers內(nèi)的成員執(zhí)行提款交易,提款才可以被正常執(zhí)行。
而一旦跨鏈橋出現(xiàn)問題,比如某筆提款聲明要提走的資產(chǎn)大于該用戶實際擁有的資產(chǎn)余額,Hyperliquid節(jié)點就可以在爭議期內(nèi)使用lockers投票暫?珂湗蚝霞s運行,或者由coldValidatorSet直接將有問題的提款請求無效化。
目前Hyperliquid的只有4個驗證者節(jié)點,所以hotValidatorSet和coldValidatorSet只對應(yīng)4個鏈上地址。Hyperliquid在初始化時,自動將hotValidatorSet內(nèi)的地址注冊為lockers和finalizers的成員,而coldValidatorSet為Hyperliquid官方自己控制,使用冷錢包來存儲密鑰。
存款
Hyperliquid的橋合約基于EIP-2612的Permit方法來處理用戶的存款操作,且橋合約內(nèi)只允許用戶存入USDC一種資產(chǎn)。Permit相比于傳統(tǒng)的Approve—Transfer模式更為簡潔,也便于支持批量操作。
Hyperliquid的橋合約使用了batchedDepositWithPermit函數(shù)來批量處理多筆存款,這里的存款動作較為簡單,不存在資金安全風(fēng)險,在處理流程上很簡潔,只是使用了Permit方法來節(jié)優(yōu)化UX。
假如有惡意攻擊者想在Hyperliquid的提款流程中做手腳,就需要突破三道防線:
1.掌握hotValidatorSet內(nèi)的2/3簽名權(quán)重,換言之需要獲取一定數(shù)量的私鑰或是串謀;目前HyperLiquid只有4個驗證者,被攻擊者控制或串謀的可能性不低;
2.在爭議期內(nèi),攻擊者應(yīng)避免自己的惡意交易被發(fā)現(xiàn),一旦被發(fā)現(xiàn)很有可能使lockers出手鎖住合約。我們會在下文專門討論這部分。
3.獲取至少一個finalizers成員的私鑰,讓自己的提款行為被最終確認(rèn)。目前finalizers成員和hotValidatorSet成員基本一致,所以只要攻擊者滿足了上述條件1,就自動滿足了條件3。
橋合約的鎖定
前面我們多次提到了Hyperliquid設(shè)置了一個鎖定跨鏈橋合約的功能。具體來說,鎖定跨鏈橋需要lockers成員調(diào)用跨鏈橋合約中的voteEmergencyLock函數(shù)進行投票,目前當(dāng)2名lockers調(diào)用該函數(shù)給出投票后,跨鏈橋合約就會被鎖定并暫停運轉(zhuǎn)。
但需要注意,HyperLiquid的跨鏈橋也提供了unvoteEmergencyLock函數(shù),允許lockers成員撤回投票。而一旦跨鏈橋合約被成功鎖定,就只能通過名為emergencyUnlock的函數(shù)來解除鎖定,需要收集coldValidatorSet成員2/3以上的簽名權(quán)重。
emergencyUnlock功能在解除鎖定的同時,也會輸入新的hotValidatorSet和coldValidatorSet驗證者地址集合,并且會立即更新。
Precompiles
所謂的預(yù)編譯(Precompiles),說白了就是將一些在智能合約中不易實現(xiàn)、復(fù)雜度較高的操作直接挪到底層中實現(xiàn),把對Solidity不友好、較為麻煩的計算流程挪到常規(guī)的智能合約外部去處理,這類預(yù)編譯代碼可以用C、C++等比Solidity更貼近設(shè)備底層的語言來實現(xiàn)。
預(yù)編譯的方式可以讓EVM支持更高級更復(fù)雜的功能,便于支持智能合約開發(fā)者的需求。在表現(xiàn)形式上,預(yù)編譯實質(zhì)就是一組特殊的智能合約,其他智能合約可以直接調(diào)用這些特殊合約,傳入?yún)?shù)并獲得預(yù)編譯執(zhí)行的返回結(jié)果。目前原生EVM內(nèi)就通過預(yù)編譯的方式實現(xiàn)了ecRecover指令,可以在EVM內(nèi)部檢查secp256k1簽名是否正確,而該指令就位于0x01地址內(nèi)。
使用預(yù)編譯增加一些特殊功能是目前的主流做法,比如Base就增加了P256預(yù)編譯代碼來方便用戶進行WebAuth身份鑒權(quán)操作。
現(xiàn)在很多和跨鏈相關(guān)的場景都會使用Events來傳遞跨鏈參數(shù),比如Arbitrum部署在Ethereum主網(wǎng)上的橋合約內(nèi),用戶就可以調(diào)用相關(guān)函數(shù)拋出事件在Arbitrum上觸發(fā)交易。
下圖展示了在非并行情況下的HyperBFT共識的消息傳遞方式,可以看到,所有的消息被Leader匯總并統(tǒng)一廣播,免去了節(jié)點之間自行交換消息的步驟,大幅降低了復(fù)雜度。
簡單來說,HyperBFT就是當(dāng)前的leader出塊,全體節(jié)點參與投票并將投票結(jié)果統(tǒng)一發(fā)送給Leader,再讓下一個leader輪換的共識協(xié)議。實際上Hotstuff和Tendermint涉及的具體細(xì)節(jié)要復(fù)雜的多,本文受限于篇幅和側(cè)重點不在此贅述。
對開發(fā)者而言需要注意的要點
上述基于Precompiles的數(shù)據(jù)讀取機制是比較完美的,Solidity開發(fā)者讀取HyperL1狀態(tài)時不需要專門編寫相應(yīng)的代碼,但是需要注意msg.sender的問題。與大部分Ethereum二層類似,HyperLiquid也允許用戶直接與HyperL1內(nèi)的系統(tǒng)合約交互,間接觸發(fā)在HyperEVM鏈上的交易動作,此時如果智能合約在該交易內(nèi)讀取msg.sender字段,會發(fā)現(xiàn)msg.sender對應(yīng)的是HyperL1系統(tǒng)合約的地址,而不是最開始在HyperL1上發(fā)起交易的用戶地址。
而對于EVM與L1的交互,開發(fā)者需要注意一系列問題。第一個問題是交互的非原子性問題,假如用戶在HyperEVM上通過前述事件地址,間接在L1內(nèi)掛單,但L1內(nèi)并沒有充分的資產(chǎn),那么該交易肯定會失敗,但用戶調(diào)用事件地址的函數(shù)時不會有錯誤返回提示。交互的非原子性問題可能導(dǎo)致用戶的資產(chǎn)受損。此時對于開發(fā)者而言,需要在EVM智能合約端手動處理掛單失敗的情況。而且EVM內(nèi)的智能合約應(yīng)該有用于最終資金收回的函數(shù),避免用戶資產(chǎn)在L1內(nèi)永遠(yuǎn)無法提取出來。
其次,EVM對應(yīng)的合約地址在L1內(nèi)必須存在映射賬戶,當(dāng)用戶在EVM內(nèi)部署完成智能合約后,需要在L1內(nèi)向映射地址轉(zhuǎn)入少量USDC,迫使L1為合約地址創(chuàng)建賬戶。該部分操作可能與HyperLiquid的底層共識相關(guān),在Hyperliquid的文檔中有明確要求。
最后,開發(fā)者需要注意一些特殊情況,特別是Tokens的余額情況。HyperL1存在一個特殊地址用于資產(chǎn)轉(zhuǎn)移,但用戶將資產(chǎn)發(fā)送到該特殊地址時,資產(chǎn)就會從L1跨到HyperEVM鏈內(nèi)。由于HyperLiquid節(jié)點實際上同時執(zhí)行EVM鏈和L1鏈,可能在用戶轉(zhuǎn)移資產(chǎn)后HyperEVM仍許久未出塊,此時用戶在EVM鏈上無法讀到自己的余額。
簡單來說,此時的用戶資產(chǎn)卡在的跨鏈橋內(nèi),無論是在L1還是EVM鏈內(nèi)都無法查詢,開發(fā)者構(gòu)建的協(xié)議應(yīng)當(dāng)處理上述特殊情況,避免用戶產(chǎn)生恐慌情緒。
總結(jié)來看,HyperEVM類似于基于HyperliquidL1的二層,HyperEVM依賴于預(yù)編譯代碼讀取L1狀態(tài),也依賴于Events來與HyperL1產(chǎn)生交互。L1也存在一些系統(tǒng)合約幫助用戶在HyperEVM內(nèi)觸發(fā)交易,或是進行資產(chǎn)跨鏈。但與一般的Layer1——Layer2架構(gòu)不同,Hyperliquid為HyperEVM提供了更高的互操作性。
參考資料
Hyperliquid:TheHyperoptimizedOrderBookL1
hyperliquid-dex/contracts
TheNot-So-DefinitiveguidetoHyperliquidPrecompiles.
WhatisthedifferencebetweenPBFT,Tendermint,HotStuff,andHotStuff-2?
免責(zé)聲明:Hyperliquid技術(shù)解讀:橋合約、HyperEVM及其潛在問題文章轉(zhuǎn)發(fā)自互聯(lián)網(wǎng),版權(quán)歸其所有。
文章內(nèi)容不代表本站立場和任何投資暗示。加密貨幣市場極其波動,風(fēng)險很高,可能不適合所有投資者。在投資加密貨幣之前,請確保自己充分了解市場和投資的風(fēng)險,并考慮自己的財務(wù)狀況和風(fēng)險承受能力。此外,請遵循您所在國家的法律法規(guī),以及遵守交易所和錢包提供商的規(guī)定。對于任何因使用加密貨幣所造成的投資損失或其他損失,本站不承擔(dān)任何責(zé)任。
Copyright © 2021.Company 元宇宙YITB.COM All rights reserved.元宇宙YITB.COM