炒作退潮，從技術(shù)角度解讀Hyperliquid的橋合約、HyperEVM及其潛在問(wèn)題

作者：Shew，仙壤GodRealmX

近期廣受市場(chǎng)關(guān)注的Hyperliquid是最有影響力的鏈上訂單薄交易所之一，其TVL已超過(guò)20億美元，在被Messari評(píng)價(jià)為“鏈上Binance”的同時(shí)，甚至還把本已淡出大眾視角的Layer3、應(yīng)用鏈敘事重新拉回聚光燈下。憑借著Token上線一個(gè)月內(nèi)FDV拉至300億美元的輝煌成績(jī)，Hyperliquid獲得了從普通用戶到從業(yè)人員的廣泛關(guān)注，與此同時(shí)市面上也涌現(xiàn)出了大量關(guān)于Hyperliquid的研報(bào)，但這些文章基本聚焦于其在訂單簿產(chǎn)品功能和交易機(jī)制上的特點(diǎn)，沒(méi)有深入探究其背后的技術(shù)構(gòu)造以及安全隱患。

本文作者旨在補(bǔ)足這一空缺，單純從技術(shù)構(gòu)造與安全的角度來(lái)考察Hyperliquid，幫助更多人理解這一明星項(xiàng)目的結(jié)構(gòu)與原理。我們將從Hyperliquid跨鏈橋合約的構(gòu)造與隱患、HyperEVM與HyperL1雙鏈構(gòu)造兩大角度展開(kāi)闡述，幫助大家深入理解其背后的技術(shù)架構(gòu)與實(shí)現(xiàn)方式。

（目前Hyperliquid占用了Arbitrum上的USDC總供應(yīng)量的67%）

HyperLiquid跨鏈橋解析

由于HyperLiquid并沒(méi)有開(kāi)源核心組件，但是開(kāi)源了相關(guān)的橋合約，所以我們對(duì)橋合約方面的風(fēng)險(xiǎn)更為了解。Hyperliquid在Arbitrum上部署了一個(gè)橋合約，用來(lái)存儲(chǔ)用戶存入的USDC資產(chǎn)，我們可以在Bridge組件內(nèi)看到Hyperliquid節(jié)點(diǎn)的部分行為。

驗(yàn)證者集合

從節(jié)點(diǎn)身份劃分的角度來(lái)看，Hyperliquid有4組驗(yàn)證者，分別為hotValidatorSet、coldValidatorSet以及finalizers和lockers，對(duì)應(yīng)著不同的職能。其中hotValidatorSet用于響應(yīng)用戶的提款操作等高頻行為，一般使用熱錢(qián)包以隨時(shí)響應(yīng)Hyperliquid用戶的提款請(qǐng)求。

而coldValidatorSet主要用于修改系統(tǒng)配置，如改寫(xiě)hotValidatorSet或lockers等驗(yàn)證者集合的名單，或是處理橋合約的鎖定狀態(tài)，而且 coldValidatorSet 有權(quán)直接將某些提款請(qǐng)求無(wú)效化。

而lockers是一組有特殊權(quán)限的驗(yàn)證者，類(lèi)似于Layer2慣用的“安全委員會(huì)”，會(huì)在一些突發(fā)情況下用投票決定是否讓跨鏈橋暫停運(yùn)轉(zhuǎn)。目前Hyperliquid橋的lockers集合內(nèi)包含5個(gè)地址，只需要2個(gè)locker投票即可暫停橋合約的運(yùn)行。

至于finalizers其實(shí)也是一組特殊的驗(yàn)證者，主要用于確認(rèn)跨鏈橋的狀態(tài)變化，從合約層面來(lái)看主要確認(rèn)的就是用戶存款和提款。Hyperliquid的跨鏈橋使用“提交-確認(rèn)”機(jī)制，比如用戶發(fā)起提款后并不會(huì)被立即執(zhí)行，需要等待一段時(shí)間(這段時(shí)間被稱為爭(zhēng)議期)。等待爭(zhēng)議期結(jié)束后，finalizers內(nèi)的成員執(zhí)行提款交易，提款才可以被正常執(zhí)行。

而一旦跨鏈橋出現(xiàn)問(wèn)題，比如某筆提款聲明要提走的資產(chǎn)大于該用戶實(shí)際擁有的資產(chǎn)余額，Hyperliquid節(jié)點(diǎn)就可以在爭(zhēng)議期內(nèi)使用lockers投票暫?？珂湗蚝霞s運(yùn)行，或者由 coldValidatorSet直接將有問(wèn)題的提款請(qǐng)求無(wú)效化。

目前Hyperliquid的只有4個(gè)驗(yàn)證者節(jié)點(diǎn)，所以hotValidatorSet和coldValidatorSet只對(duì)應(yīng)4個(gè)鏈上地址。Hyperliquid在初始化時(shí)，自動(dòng)將hotValidatorSet內(nèi)的地址注冊(cè)為 lockers和finalizers的成員，而coldValidatorSet為Hyperliquid官方自己控制，使用冷錢(qián)包來(lái)存儲(chǔ)密鑰。

存款

Hyperliquid的橋合約基于EIP-2612的Permit方法來(lái)處理用戶的存款操作，且橋合約內(nèi)只允許用戶存入U(xiǎn)SDC一種資產(chǎn)。Permit相比于傳統(tǒng)的Approve—Transfer模式更為簡(jiǎn)潔，也便于支持批量操作。

Hyperliquid的橋合約使用了batchedDepositWithPermit函數(shù)來(lái)批量處理多筆存款，這里的存款動(dòng)作較為簡(jiǎn)單，不存在資金安全風(fēng)險(xiǎn)，在處理流程上很簡(jiǎn)潔，只是使用了Permit方法來(lái)節(jié)優(yōu)化UX。

提款

相比于存款，提款是一個(gè)高度危險(xiǎn)的操作，所以提款邏輯會(huì)比存款復(fù)雜很多。當(dāng)用戶發(fā)起提款請(qǐng)求后，Hyperliquid節(jié)點(diǎn)會(huì)調(diào)用橋合約的batchedRequestWithdrawals函數(shù)。此時(shí)橋合約會(huì)要求每筆提款請(qǐng)求必須湊齊hotValidatorSet的2/3簽名權(quán)重，注意很多文檔在此處都描述為“集齊2/3的簽名”，但實(shí)際上橋合約檢查的是“2/3的簽名權(quán)重”。目前HyperLiquid只有4個(gè)權(quán)重相同的節(jié)點(diǎn)，所以檢查簽名權(quán)重和檢查簽名數(shù)量暫時(shí)一致，但在未來(lái)，HyperLiquid可能引入高權(quán)重的節(jié)點(diǎn)。

當(dāng)發(fā)起提款請(qǐng)求后，跨鏈橋不會(huì)立即將合約控制的USDC轉(zhuǎn)移出去，而是有一個(gè)“爭(zhēng)議期”，類(lèi)似于欺詐證明協(xié)議中的“挑戰(zhàn)期”。目前Hyperliquid橋合約的爭(zhēng)議期為200秒，在爭(zhēng)議期內(nèi)可能出現(xiàn)兩種情況：

1.lockers認(rèn)為目前的提款請(qǐng)求存在嚴(yán)重問(wèn)題，此時(shí)可以直接投票把合約暫停/凍結(jié)；

2.節(jié)點(diǎn)認(rèn)為部分提款行為存在問(wèn)題，此時(shí)coldValidatorSet 成員可以調(diào)用 invalidateWithdrawals函數(shù)，令該筆提款無(wú)效化。

如果爭(zhēng)議期內(nèi)沒(méi)有出現(xiàn)問(wèn)題，待爭(zhēng)議期結(jié)束后，finalizers內(nèi)的成員可以調(diào)用橋合約中的batchedFinalizeWithdrawals函數(shù)來(lái)敲定最終的狀態(tài)，該函數(shù)觸發(fā)后USDC才會(huì)被打到用戶在Arbitrum的錢(qián)包地址里。

所以從安全模型的角度來(lái)看，假如有惡意攻擊者想在Hyperliquid的提款流程中做手腳，就需要突破三道防線:

1.掌握hotValidatorSet內(nèi)的2/3簽名權(quán)重，換言之需要獲取一定數(shù)量的私鑰或是串謀；目前HyperLiquid只有4個(gè)驗(yàn)證者，被攻擊者控制或串謀的可能性不低；

2.在爭(zhēng)議期內(nèi)，攻擊者應(yīng)避免自己的惡意交易被發(fā)現(xiàn)，一旦被發(fā)現(xiàn)很有可能使lockers出手鎖住合約。我們會(huì)在下文專門(mén)討論這部分。

3.獲取至少一個(gè)finalizers 成員的私鑰，讓自己的提款行為被最終確認(rèn)。目前 finalizers成員和hotValidatorSet成員基本一致，所以只要攻擊者滿足了上述條件1，就自動(dòng)滿足了條件3。

橋合約的鎖定

前面我們多次提到了Hyperliquid設(shè)置了一個(gè)鎖定跨鏈橋合約的功能。具體來(lái)說(shuō)，鎖定跨鏈橋需要lockers成員調(diào)用跨鏈橋合約中的voteEmergencyLock函數(shù)進(jìn)行投票，目前當(dāng)2名 lockers調(diào)用該函數(shù)給出投票后，跨鏈橋合約就會(huì)被鎖定并暫停運(yùn)轉(zhuǎn)。

但需要注意，HyperLiquid的跨鏈橋也提供了unvoteEmergencyLock函數(shù)，允許lockers成員撤回投票。而一旦跨鏈橋合約被成功鎖定，就只能通過(guò)名為emergencyUnlock的函數(shù)來(lái)解除鎖定，需要收集coldValidatorSet成員2/3以上的簽名權(quán)重。

emergencyUnlock 功能在解除鎖定的同時(shí)，也會(huì)輸入新的hotValidatorSet和 coldValidatorSet驗(yàn)證者地址集合，并且會(huì)立即更新。

驗(yàn)證者集合更新

相比于費(fèi)盡心思嘗試突破提款流程中的已有防線，一種更好的攻擊手段是直接使用 updateValidatorSet函數(shù)更新hotValidatorSet和coldValidatorSet驗(yàn)證者集合。這要求調(diào)用者必須給出所有hotValidatorSet成員的簽名，且該操作有200秒的爭(zhēng)議期。

當(dāng)爭(zhēng)議期結(jié)束后，需要finalizers成員調(diào)用finalizeValidatorSetUpdate函數(shù)，完成最終的狀態(tài)更新。

至此，我們已經(jīng)介紹了Hyperliquid跨鏈橋的大部分細(xì)節(jié)。本文沒(méi)有介紹lockers和 finalizers的更新邏輯，這兩者的更新都需要hotValidatorSet簽名，而將某一個(gè)成員移除則需要coldValidatorSet簽名。

總結(jié)下來(lái)，Hyperliquid的橋合約包含以下風(fēng)險(xiǎn)：

1.黑客控制了coldValidatorSet后可以無(wú)視任何阻攔來(lái)盜取用戶資產(chǎn)。因?yàn)閏oldValidatorSet擁有emergencyUnlock函數(shù)的操作權(quán)限，可以讓lockers對(duì)橋合約的鎖定動(dòng)作無(wú)效化，并且可以即時(shí)更新節(jié)點(diǎn)名單。目前Hyperliquid 只存在4個(gè)驗(yàn)證者節(jié)點(diǎn)，被盜取私鑰的可能性并不低；

2.finalizers拒絕對(duì)用戶的提款交易進(jìn)行最終確認(rèn)，展開(kāi)審查攻擊；種情況下用戶資產(chǎn)不會(huì)被盜，但可能無(wú)法從橋合約中提款；

3.lockers惡意定跨鏈橋，此時(shí)所有的提款交易都無(wú)法執(zhí)行，只能等coldValidatorSet解鎖；

HyperEVM與雙鏈交互架構(gòu)

為了讓訂單簿交易變的可編程化，比如引入隱私交易等需要智能合約來(lái)實(shí)現(xiàn)的場(chǎng)景，Hyperliquid推出了名為HyperEVM的方案。它相比于傳統(tǒng)的EVM有兩個(gè)特殊優(yōu)勢(shì)：一是HyperEVM可以讀取HyperLiquid的訂單簿狀態(tài)，二是HyperEVM內(nèi)的智能合約可以與Hyperliquid訂單簿系統(tǒng)交互，這大大擴(kuò)展了Hyperliquid的應(yīng)用場(chǎng)景。

舉一個(gè)簡(jiǎn)單例子，如果用戶需要保證掛單操作的隱私性，此時(shí)可以在HyperEVM上通過(guò)類(lèi)似Tornado Cash的智能合約套一層隱私，然后通過(guò)特定接口在HyperLiquid的訂單簿系統(tǒng)中觸發(fā)掛單動(dòng)作。

在介紹HyperEVM前，我們需要介紹Hyperliquid為HyperEVM準(zhǔn)備的特殊架構(gòu)。由于Hyperliquid有定制化的超高性能訂單薄系統(tǒng)，而EVM環(huán)境下的交易處理速度要慢很多。為了避免訂單簿系統(tǒng)工作速度變慢，Hyperliquid使用了“雙鏈方案”，實(shí)質(zhì)是讓Hyperliquid節(jié)點(diǎn)設(shè)備在軟件層面同時(shí)運(yùn)行兩條區(qū)塊鏈，每個(gè)節(jié)點(diǎn)都在本地存放兩條鏈的數(shù)據(jù)，對(duì)兩條鏈的交易分別進(jìn)行處理。

Hyperliquid為其定制化的訂單薄系統(tǒng)專門(mén)設(shè)置了一條鏈，同時(shí)增加了一條EVM兼容的鏈（HyperEVM）。這兩條鏈的數(shù)據(jù)在節(jié)點(diǎn)群體間通過(guò)相同的共識(shí)協(xié)議來(lái)傳播，作為一個(gè)統(tǒng)一的狀態(tài)來(lái)存在，但在不同的執(zhí)行環(huán)境中分別運(yùn)行。我們稱訂單薄專用鏈為Hyperliquid L1 (L1)，這條鏈?zhǔn)谴嬖谠S可制的；而用于HyperEVM 的鏈為HyperEVM（EVM），這條鏈?zhǔn)菬o(wú)許可的，任何人都可以部署合約，這些合約可以通過(guò)預(yù)編譯代碼來(lái)訪問(wèn)L1內(nèi)的信息。

需要注意的是Hyperliquid L1的出塊速度大于HyperEVM鏈，但這些區(qū)塊仍會(huì)按順序執(zhí)行。EVM 鏈上的合約可以讀取過(guò)往L1區(qū)塊內(nèi)的數(shù)據(jù)，并向未來(lái)的L1區(qū)塊寫(xiě)入數(shù)據(jù)。如下圖:

為了讓HyperL1和HyperEVM之間實(shí)現(xiàn)交互，Hyperliquid利用了Precompiles和Events兩種技術(shù)手段。

Precompiles

所謂的預(yù)編譯（Precompiles），說(shuō)白了就是將一些在智能合約中不易實(shí)現(xiàn)、復(fù)雜度較高的操作直接挪到底層中實(shí)現(xiàn)，把對(duì)Solidity不友好、較為麻煩的計(jì)算流程挪到常規(guī)的智能合約外部去處理，這類(lèi)預(yù)編譯代碼可以用C、C++等比Solidity更貼近設(shè)備底層的語(yǔ)言來(lái)實(shí)現(xiàn)。

預(yù)編譯的方式可以讓EVM支持更高級(jí)更復(fù)雜的功能，便于支持智能合約開(kāi)發(fā)者的需求。在表現(xiàn)形式上，預(yù)編譯實(shí)質(zhì)就是一組特殊的智能合約，其他智能合約可以直接調(diào)用這些特殊合約，傳入?yún)?shù)并獲得預(yù)編譯執(zhí)行的返回結(jié)果。目前原生EVM內(nèi)就通過(guò)預(yù)編譯的方式實(shí)現(xiàn)了ecRecover指令，可以在EVM內(nèi)部檢查secp256k1簽名是否正確，而該指令就位于0x01地址內(nèi)。

使用預(yù)編譯增加一些特殊功能是目前的主流做法，比如 Base 就增加了P256預(yù)編譯代碼來(lái)方便用戶進(jìn)行WebAuth身份鑒權(quán)操作。

（此圖來(lái)自?Rollup Codes?網(wǎng)站）

與這種目前的主流方案一致，HyperEVM 也增加了一系列的預(yù)編譯代碼來(lái)實(shí)現(xiàn)EVM對(duì) Hyperliquid訂單薄系統(tǒng)狀態(tài)的讀取。目前已知的一個(gè)Hyperliquid的預(yù)編譯代碼地址是0x0000000000000000000000000000000000000800，該預(yù)編譯地址可以讀取最近一個(gè)L1區(qū)塊內(nèi)的用戶的永續(xù)合約的倉(cāng)位情況。

Events

我們?cè)谏衔奶岬紿yperEVM可以向HyperL1區(qū)塊內(nèi)寫(xiě)入數(shù)據(jù)，寫(xiě)入行為就是依賴于Events實(shí)現(xiàn)的。Events是EVM內(nèi)的原生概念，它允許智能合約在執(zhí)行過(guò)程中向外部（如前端應(yīng)用或監(jiān)聽(tīng)器）發(fā)送日志信息，便于外界監(jiān)聽(tīng)智能合約的運(yùn)行情況。

比如在用戶使用ERC-20合約的代幣轉(zhuǎn)賬功能時(shí)，合約會(huì)拋出Transfer相對(duì)應(yīng)的Event，以便于區(qū)塊瀏覽器等前端應(yīng)用獲知代幣轉(zhuǎn)賬情況。這些Events信息會(huì)被包含在區(qū)塊內(nèi)，而監(jiān)聽(tīng)和檢索Events日志都存在大量的成熟方案。

現(xiàn)在很多和跨鏈相關(guān)的場(chǎng)景都會(huì)使用Events來(lái)傳遞跨鏈參數(shù)，比如Arbitrum部署在以太坊主網(wǎng)上的橋合約內(nèi)，用戶就可以調(diào)用相關(guān)函數(shù)拋出事件在Arbitrum上觸發(fā)交易。

已知的信息表明，HyperLiquid節(jié)點(diǎn)會(huì)監(jiān)聽(tīng)

0x3333333333333333333333333333333333333333(事件地址)拋出的Events，根據(jù)Events包含的信息獲知用戶意圖，并據(jù)此將意圖轉(zhuǎn)化為交易動(dòng)作，寫(xiě)入未來(lái)的Hyperliquid L1區(qū)塊中。

比如，上述事件地址會(huì)提供一個(gè)函數(shù)，當(dāng)用戶調(diào)用此函數(shù)時(shí)，事件地址會(huì)拋出名為IocOrder的Event。在Hyper L1區(qū)塊產(chǎn)生時(shí)，HyperLiquid節(jié)點(diǎn)會(huì)先查詢最近HyperEVM內(nèi)事件地址拋出的Events，當(dāng)檢索到新的IocOrder事件時(shí)，就會(huì)將其轉(zhuǎn)化為在Hyper L1內(nèi)的掛單操作。

HyperBFT

在共識(shí)協(xié)議層面，Hyperliquid采用了名為HyperBFT的協(xié)議，這是一種基于HotStuff的衍生方法。目前HutStuff-2已經(jīng)是最新的復(fù)雜度最低的幾種共識(shí)協(xié)議之一。

根據(jù)資料顯示，在最初HyperLiquid使用了Tendermint共識(shí)算法，是Cosmos系統(tǒng)內(nèi)默認(rèn)使用的共識(shí)算法，但該算法效率較低，每個(gè)階段都需要All-to-All的消息交換，每個(gè)節(jié)點(diǎn)都要向所有其他節(jié)點(diǎn)發(fā)送消息，通信復(fù)雜度為O(n2)，其中n是節(jié)點(diǎn)的數(shù)量。

如果采用Tendermint，Hyperliquid每秒最多能處理20,000筆訂單。為了達(dá)到中心化交易所的速度，HyperLiquid團(tuán)隊(duì)基于HotStuff開(kāi)發(fā)了HyperBFT算法，并將其用Rust 實(shí)現(xiàn)，理論上每秒最多可處理200萬(wàn)筆訂單。

下圖展示了在非并行情況下的HyperBFT共識(shí)的消息傳遞方式，可以看到，所有的消息被Leader匯總并統(tǒng)一廣播，免去了節(jié)點(diǎn)之間自行交換消息的步驟，大幅降低了復(fù)雜度。

簡(jiǎn)單來(lái)說(shuō)，HyperBFT 就是當(dāng)前的leader出塊，全體節(jié)點(diǎn)參與投票并將投票結(jié)果統(tǒng)一發(fā)送給Leader，再讓下一個(gè)leader輪換的共識(shí)協(xié)議。實(shí)際上Hotstuff和Tendermint涉及的具體細(xì)節(jié)要復(fù)雜的多，本文受限于篇幅和側(cè)重點(diǎn)不在此贅述。

對(duì)開(kāi)發(fā)者而言需要注意的要點(diǎn)

上述基于Precompiles的數(shù)據(jù)讀取機(jī)制是比較完美的，Solidity開(kāi)發(fā)者讀取Hyper L1狀態(tài)時(shí)不需要專門(mén)編寫(xiě)相應(yīng)的代碼，但是需要注意msg.sender的問(wèn)題。與大部分以太坊二層類(lèi)似，HyperLiquid 也允許用戶直接與Hyper L1內(nèi)的系統(tǒng)合約交互，間接觸發(fā)在HyperEVM鏈上的交易動(dòng)作，此時(shí)如果智能合約在該交易內(nèi)讀取msg.sender字段，會(huì)發(fā)現(xiàn)msg.sender對(duì)應(yīng)的是HyperL1系統(tǒng)合約的地址，而不是最開(kāi)始在HyperL1上發(fā)起交易的用戶地址。

而對(duì)于EVM與L1的交互，開(kāi)發(fā)者需要注意一系列問(wèn)題。第一個(gè)問(wèn)題是交互的非原子性問(wèn)題，假如用戶在HyperEVM上通過(guò)前述事件地址，間接在L1內(nèi)掛單，但L1內(nèi)并沒(méi)有充分的資產(chǎn)，那么該交易肯定會(huì)失敗，但用戶調(diào)用事件地址的函數(shù)時(shí)不會(huì)有錯(cuò)誤返回提示。交互的非原子性問(wèn)題可能導(dǎo)致用戶的資產(chǎn)受損。此時(shí)對(duì)于開(kāi)發(fā)者而言，需要在EVM智能合約端手動(dòng)處理掛單失敗的情況。而且EVM內(nèi)的智能合約應(yīng)該有用于最終資金收回的函數(shù)，避免用戶資產(chǎn)在L1內(nèi)永遠(yuǎn)無(wú)法提取出來(lái)。

其次，EVM對(duì)應(yīng)的合約地址在L1內(nèi)必須存在映射賬戶，當(dāng)用戶在EVM內(nèi)部署完成智能合約后，需要在L1內(nèi)向映射地址轉(zhuǎn)入少量USDC，迫使L1為合約地址創(chuàng)建賬戶。該部分操作可能與 HyperLiquid的底層共識(shí)相關(guān)，在Hyperliquid的文檔中有明確要求。

最后，開(kāi)發(fā)者需要注意一些特殊情況，特別是代幣的余額情況。Hyper L1存在一個(gè)特殊地址用于資產(chǎn)轉(zhuǎn)移，但用戶將資產(chǎn)發(fā)送到該特殊地址時(shí)，資產(chǎn)就會(huì)從L1跨到HyperEVM鏈內(nèi)。由于 HyperLiquid節(jié)點(diǎn)實(shí)際上同時(shí)執(zhí)行EVM鏈和L1鏈，可能在用戶轉(zhuǎn)移資產(chǎn)后HyperEVM仍許久未出塊，此時(shí)用戶在EVM鏈上無(wú)法讀到自己的余額。

簡(jiǎn)單來(lái)說(shuō)，此時(shí)的用戶資產(chǎn)卡在的跨鏈橋內(nèi)，無(wú)論是在L1還是EVM鏈內(nèi)都無(wú)法查詢，開(kāi)發(fā)者構(gòu)建的協(xié)議應(yīng)當(dāng)處理上述特殊情況，避免用戶產(chǎn)生恐慌情緒。

總結(jié)來(lái)看，HyperEVM類(lèi)似于基于Hyperliquid L1的二層，HyperEVM依賴于預(yù)編譯代碼讀取L1 狀態(tài)，也依賴于Events來(lái)與Hyper L1產(chǎn)生交互。L1也存在一些系統(tǒng)合約幫助用戶在HyperEVM內(nèi)觸發(fā)交易，或是進(jìn)行資產(chǎn)跨鏈。但與一般的Layer1——Layer2架構(gòu)不同，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?