ハイパーリキッド技術解説：ハイパーEVMとその潜在的問題点

By Shew, Fairy Loam GodRealmX

Hyperliquidは、20億ドル以上のTVLで、最も影響力のあるオンチェーンオーダーブック取引所の一つです。同時に "チェーンバイナンス "としてMessari評価で20億ドル以上、さらにはLayer3、スポットライトに戻ってアプリケーションチェーンの物語の公共の観点から色あせている。Hyperliquidは、トークンのローンチ後1ヶ月で300億ドルのFDVを達成したことで、一般ユーザーから実務者まで広く注目されるようになり、同時にHyperliquidに関する多くの研究レポートも市場に登場したが、これらの記事は基本的にオーダーブック製品の機能と取引メカニズムにおけるその特徴に焦点を当て、その背後にある技術的な構築とセキュリティリスクについては深く掘り下げていない。

この記事では、Hyperliquidを純粋に技術的な構築とセキュリティの観点から見ることで、このギャップを埋め、このスタープロジェクトの構造と原理をより多くの人に理解してもらうことを目指す。私たちは、Hyperliquidのクロスチェーン・ブリッジ契約の構築と隠れた危険性、HyperEVMとHyperL1デュアルチェーンの構築という2つの主要な観点からスタートし、技術的なアーキテクチャとその背後にある方法の実装を深く理解できるようにします。

()

HyperLiquid Cross-Chain Bridge Analysis<

HyperLiquidはコアコンポーネントをオープンソース化していませんが、関連するブリッジ契約をオープンソース化しているため、ブリッジ契約に関連するリスクをより認識しています。Hyperliquidは、ユーザーによって預託されたUSDC資産を保管するためにブリッジ契約を展開しており、ブリッジコンポーネント内のHyperliquidノードの動作の一部を見ることができます。

バリデータセット

ノードのIDセグメンテーションの観点から、Hyperliquidには4つのバリデータセットがあります。hotValidatorSet、coldValidatorSet、finalizersとlockersの4つのバリデータがあり、それぞれ異なる機能に対応している。hotValidatorSetは、ユーザーの引き出しのような高頻度の行動に対応するために使用され、通常、Hyperliquidユーザーの引き出し要求に対応できるようにホットウォレットで使用されます。

また、coldValidatorSetは主に、hotValidatorSetやlockersのバリデータのリストを書き換えたり、ブリッジ契約を処理するなど、システム構成を変更するために使用されます。また、coldValidatorSetは、特定の引き出し要求を直接無効にする権限を持っています。

そしてlockersはレイヤ2の通常の「安全委員会」に似た特権バリデータのセットで、予期せぬ状況でブリッジを一時停止するための投票を行います。緊急事態が発生した場合にブリッジを一時停止する。現在Hyperliquidブリッジのlockersコレクションはlockersを含んでいます。には5つのアドレスが含まれており、橋の契約を中断するために必要なロッカー票は2つだけです。。

に関してはfinalizersは、実際にはチェーンブリッジ全体の状態変化を確認するために使用される検証者の特別なセットであり、契約レベルから確認する主なものはユーザーの入出金です。Hyperliquidのクロスチェーンブリッジは、"Submit-Confirm"メカニズムを使用しています。たとえば、ユーザーが引き出しを開始しても、すぐに実行されるわけではなく、しばらく待つ必要があります。は一定期間待たなければならない（この期間を紛争期間と呼ぶ）。紛争期間が終了した後、ファイナライザのメンバーは、出金取引を実行し、出金は、ファイナライザのメンバーによって実行されることができる。普通に実行される。

また、クロスチェーンブリッジに問題が発生した場合、例えば引き出し資産がそのユーザーが実際に所有している資産の残高よりも多いという引き出しがあった場合、ハイパーリクイドノードはlockers投票を使って紛争期間中にクロスチェーンブリッジ契約を一時停止するか、coldValidIDATED投票によってクロスチェーンブリッジ契約を一時停止させることができます。code>coldValidatorSetで問題のある引き出し要求を直接無効にする。

現在Hyperliquidには4つのバリデーターノードしかないため、hotValidatorSetとcoldValidatorSetは4つのオンチェーンアドレスにしか対応しません。Hyperliquid は、初期化時に hotValidatorSet 内のアドレスを lockers および finalizers のメンバとして自動的に登録しますが、coldValidatorSet は、hotValidatorSet および coldValidatorSet のメンバとして自動的に登録されません。code>はHyperliquid自身によって公式に制御され、コールドウォレットを使用してキーを保存します。

入金

Hyperliquidのブリッジ契約は、ユーザーからの入金を処理するEIP-2612のPermit方式に基づいており、ブリッジ契約内でユーザーがUSDCを入金することのみを許可しています。Permitは、従来のApprove-Transferモデルよりもシンプルなアプローチで、バッチ操作のサポートが容易です。

Hyperliquidのブリッジ契約は、batchedDepositWithPermit関数を使用して、複数の入金をバッチ処理します。これは、資金のセキュリティに対するリスクを伴わない、比較的単純な入金操作で、処理も非常に簡単です。

出金

出金は入金に比べて非常にリスクの高い操作なので、出金ロジックは入金よりもはるかに複雑になります。ユーザーが出金リクエストを開始すると、Hyperliquidノードはブリッジ契約のbatchedRequestWithdrawals関数を呼び出す。この時点で、ブリッジ契約は各出金要求を完了しなければならないhotValididContestWithDrawalsbatchedRequestWithDrawals。「と説明されているが、ブリッジ契約では実際に「2/3の署名の重み」をチェックしている。現在HyperLiquidには同じ重さのノードが4つしかないので、署名の重さをチェックすることと署名の数をチェックすることは今のところ同じですが、将来HyperLiquidはより高い重さのノードを導入するかもしれません。

引き出し要求が開始されると、クロスチェーンブリッジは契約管理USDCを即座に転送せず、代わりに""USDCが"争議期間"があり、Proof of Fraudプロトコルにおける "チャレンジ期間 "に似ています。現在、Hyperliquid Bridgeでは「挑戦期間」となっている。現在、Hyperliquidブリッジ契約には200秒のチャレンジ期間があり、その間に2つのシナリオが起こり得ます:

1.ロッカーが現在の引き出し要求に重大な問題があると考え、その時点で契約の一時停止/凍結に投票できる;

2.ロッカーが現在の引き出し要求に重大な問題があると考え、その時点で契約の一時停止/凍結に投票できる。

2.ノードはいくつかの引き出しに問題があると考え、その時点でcoldValidatorSetメンバーはinvalidateWithdrawals関数を呼び出して引き出しを無効にすることができる。code>ブリッジ契約内のメンバーはbatchedFinalizeWithdrawals関数を呼び出すことができる。の後にトリガーされます。

つまり、セキュリティモデルの観点からは、もし悪意のある攻撃者がHyperliquidの引き出しプロセスを改ざんしようとした場合、それはだろう。3つの防衛ラインを突破する必要がある:

1.hotValidatorSet内の署名の重みの2/3を手に入れる。

2.紛争期間中、攻撃者は悪意のある取引が検知されることを避けなければならない。一度検知されると、lockersが契約をロックするために介入する可能性が非常に高い。このセクションについては後述する。

3.出金を確定させるために、finalizersメンバーの少なくとも一人の秘密鍵を入手する。現在のところ、finalizersメンバとhotValidatorSetメンバは本質的に同じなので、攻撃者が上記の条件1を満たす限り、条件3は自動的に満たされます。

ブリッジ契約のロック

Hyperliquidがクロスチェーンのブリッジ契約をロックする機能を設定していることは、先ほど何度か触れました。具体的には、クロスチェーンブリッジをロックするには、lockersメンバーがクロスチェーンブリッジ契約を呼び出す必要があります。strong>voteEmergencyLock関数で投票する、。現在、2つのロッカーがその関数を呼び出すと、はを与えます。投票、クロスチェーンブリッジ契約はロックされ、中断されます。

しかし、HyperLiquidのクロスチェーンブリッジは、unvoteEmergencyLock関数も提供しており、lockersメンバーが投票を取り下げることができることに注意してください。また、クロスチェーンブリッジのコントラクトが一度ロックに成功すると、emergencyUnlockという関数によってのみロックを解除することができます。この関数は、coldValidatorSetメンバーの署名の重みの2/3以上を集める必要があります。

ロックを解除する間、emergencyUnlock関数は、新しいhotValidatorSetとcoldValidatorSetも入力します。code>バリデータ・アドレス・セットを入力し、それらは直ちに更新されます。

ValidatorSet Updates

撤退プロセスですでに配置されている防御を突破しようとする手間をかけるよりも、updateValidatorSet関数を直接使用してホットバリデータセットを更新する方がよい攻撃です。hotValidatorSetとcoldValidatorSetバリデータセットを更新することです。これは、呼び出し元がすべてのhotValidatorSetメンバのシグネチャを与えることを必要とし、操作には200秒の論争期間があります。

論争期間が終わると、finalizers メンバは最終的な状態更新を完了するために finalizeValidatorSetUpdate 関数を呼び出す必要があります。

この時点で、Hyperliquidクロスリンク・ブリッジの詳細のほとんどをカバーしました。この記事では、lockersとfinalizersの更新ロジックはカバーしていません。これらの両方は、更新のためにhotValidatorSetシグネチャを必要とし、メンバーを削除するためにcoldValidatorSetシグネチャを必要とします。シグネチャを使用します。

要約すると、Hyperliquidのブリッジ契約には以下のリスクが含まれています:

。>1.coldValidatorSetをコントロールするハッカーは、ブロックに関係なくユーザー資産を盗むことができます。coldValidatorSet は emergencyUnlock 関数にアクセスできるので、ブリッジ コントラクト上の lockers のロック動作を無効にし、その場でノード リストを更新できます。現在Hyperliquidには4つのバリデータノードしかなく、秘密鍵が盗まれる可能性は低くない。

2.ファイナライザはユーザーの引き出し取引の最終確認を拒否し、検閲攻撃を仕掛ける。

3.ロッカーが悪意を持ってクロスチェーンブリッジを設定する。この場合、すべての引き出しトランザクションは実行できず、coldValidatorSetが完了するまで待たなければならない。

HyperEVM and Dual Chain Interaction Architecture

Dual Chain Interaction Architecture

オーダーブック取引をプログラム可能にするために、coldValidatorSetが完了するのを待たなければなりません。Hyperliquidは、プライバシー取引の導入や、スマートコントラクトの実装を必要とするその他のシナリオなど、オーダーブック取引をプログラム可能にするため、HyperEVMソリューションを導入しました。

簡単な例を挙げると、ユーザーが保留中の注文操作のプライバシーを確保する必要がある場合、この時点では、プライバシーのレイヤーのTornado Cashセットと同様のスマートコントラクトを通じてHyperEVM内にいることができ、その後、HyperLiquidのオーダーブックシステム内の特定のインターフェースを通じて、保留中の注文操作をトリガーすることができます。

HyperEVMを紹介する前に、HyperliquidがHyperEVMのために用意した特別なアーキテクチャを紹介する必要がある。Hyperliquidはカスタマイズされた超高性能のオーダーブックシステムを持っており、EVM環境でのトランザクション処理速度はかなり遅い。そのため、Hyperliquidは「デュアル・チェーニング・ソリューション」を使用しています。

Hyperliquidは1つのチェーンをカスタマイズしたオーダーブックシステムに専用し、EVM互換チェーン（HyperEVM）を追加する。これら2つのチェーンからのデータは、同じコンセンサス・プロトコルを介してノード・グループ間で伝播され、統一された状態として存在するが、異なる実行環境では別々に動作する。我々は、次数の薄い専用チェーンをハイパーリキッドL1(L1)と呼ぶ。HyperEVM(EVM)はライセンスフリーで、誰でもコンパイル済みのコードを介してL1内の情報にアクセスできるコントラクトを展開できる。

HyperliquidのL1は、HyperEVMチェーンよりも速いブロックアウト速度を持っていますが、これらのブロックは依然として逐次的に実行されることに注意することが重要です。以下:

HyperL1とHyperL1とHyperEVMが相互作用するために、Hyperliquidはプリコンパイルとイベントを利用します。

プリコンパイル

いわゆるプリコンパイルは、単にコンパイルであり、スマートコントラクトで実装するのは容易ではなく、より複雑です。いわゆるプリコンパイルとは、スマートコントラクトで実装するのが容易ではなく、複雑度が高い処理の一部を直接実装の底辺に移動させることであり、Solidityになじみがなく、扱いが面倒な計算処理を通常のスマートコントラクトの外部に移動させることであり、このようなプリコンパイルコードは、CやC++など、Solidityよりも底辺に近い言語で実装することができます。

プリコンパイルアプローチにより、EVMはより高度で複雑な機能をサポートできるようになり、スマートコントラクト開発者のニーズをサポートしやすくなります。プリコンパイルは基本的に、他のスマートコントラクトから直接呼び出され、パラメータを渡し、プリコンパイルされた実行結果を得ることができる特別なスマートコントラクトのセットです。ecRecoverディレクティブは現在、プリコンパイルによってネイティブEVM内に実装されており、0x01アドレスにあるEVM内のsecp256k1署名の正しさをチェックすることができます。

WebAuth 認証を容易にするために P256 プリコンパイルコードを追加する Base のように、特別な機能を追加するためにプリコンパイルを使用することは、現在では一般的です。

（この画像は