著者: シュー、GodRealmX
最近市場で広く注目を集めているハイパーリキッドは、最も影響力のあるオンチェーンオーダーブック取引所の1つで、そのTVLは20億ドルを超え、メッサーリからは「チェーン上のバイナンス」と評価されながらも、フェードアウトしている。レイヤ 3 とアプリケーション チェーンの物語が再び注目を集めています。 Tokenのローンチから1ヶ月以内にFDVを300億米ドルにまで引き上げるという輝かしい実績により、Hyperliquidは一般ユーザーから実務家まで幅広い注目を集めると同時に、Hyperliquidに関する多数の研究レポートが市場に出回りました。記事は基本的に注文書商品の機能や取引メカニズムに焦点を当てており、その背後にある技術的構造やセキュリティリスクについては掘り下げていません。
この記事の著者は、このスター プロジェクトの構造と原理をより多くの人が理解できるように、このギャップを埋め、純粋に技術的構造と安全性の観点から Hyperliquid を検証することを目的としています。誰もがその背後にある技術アーキテクチャと実装を理解できるように、Hyperliquid クロスチェーン ブリッジ コントラクトの構造と隠れた危険性、HyperEVM と HyperL1 の二重チェーン構造について詳しく説明します。
(Hyperliquid は現在、Arbitrum での USDC 供給総額の 67% を占めています)
HyperLiquid クロスチェーンブリッジ解析
HyperLiquid にはオープンソースのコア コンポーネントがありませんが、関連するブリッジ コントラクトがオープンソースであるため、ブリッジ コントラクトに関連するリスクをよりよく理解しています。 Hyperliquid は、ユーザーが預けた USDC アセットを保存するブリッジ コントラクトを Arbitrum に展開しました。Bridge コンポーネントで Hyperliquid ノードの動作の一部を確認できます。
バリデータセット
ノード ID 分割の観点から見ると、Hyperliquid には、さまざまな機能に対応する 4 つのバリデーター グループ (hotValidatorSet、coldValidatorSet、ファイナライザー、ロッカー) があります。その中で、hotValidatorSet は、ユーザーの出金操作などの高頻度の動作に応答するために使用され、一般に、ホット ウォレットは、Hyperliquid ユーザーの出金要求にいつでも応答するために使用されます。
coldValidatorSet は主に、hotValidatorSet やロッカーなどのバリデーター セットのリストの書き換え、ブリッジ コントラクトのロック状態の処理など、システム構成を変更するために使用され、coldValidatorSet は特定の出金リクエストを直接無効にする権利を持っています。
ロッカーは、レイヤー 2 で使用される「セキュリティ委員会」に似た、特別な許可を持つバリデーターのグループです。ロッカーは、緊急事態が発生した場合にクロスチェーン ブリッジの運用を一時停止するかどうかを投票で決定します。現在、Hyperliquid ブリッジのロッカー セットには 5 つのアドレスが含まれており、ブリッジ契約の運用を一時停止するために投票する必要があるのは 2 つのロッカーだけです。
ファイナライザーについては、実際には特別な検証者のグループであり、主にクロスチェーンブリッジのステータス変更を確認するために使用されます。契約の観点から見ると、主な確認はユーザーの入金と出金です。 Hyperliquid のクロスチェーン ブリッジは、「送信確認」メカニズムを使用します。たとえば、ユーザーが出金を開始した後、出金はすぐには実行されず、一定期間待機する必要があります (この期間は紛争期間と呼ばれます)。紛争期間が終了し、ファイナライザーのメンバーが出金取引を実行した後は、出金は通常どおり実行できます。
クロスチェーンブリッジに問題が発生すると、たとえば、特定の出金明細書に、出金対象の資産がユーザーが実際に所有する資産残高よりも大きいと記載されている場合、ハイパーリキッドノードはロッカーを使用して、クロスチェーンブリッジの運営を一時停止するよう投票することができます。紛争期間中にクロスチェーンブリッジ契約を変更するか、または coldValidatorSet を直接使用して、問題のある出金リクエストを無効にします。
現在、Hyperliquid にはバリデーター ノードが 4 つしかないため、hotValidatorSet と coldValidatorSet は 4 つのオンチェーン アドレスにのみ対応します。初期化中に、Hyperliquid はアドレスをロッカーとファイナライザーのメンバーとして hotValidatorSet に自動的に登録しますが、coldValidatorSet は Hyperliquid 自体によって正式に制御され、コールド ウォレットを使用してキーを保存します。
デポジット
Hyperliquid のブリッジ コントラクトは、EIP-2612 の Permit メソッドに基づいてユーザーの入金操作を処理し、ブリッジ コントラクトではユーザーが資産として USDC を入金することのみが許可されます。従来の承認-転送モードと比較して、許可はバッチ操作をサポートするのがより簡単で簡単です。
Hyperliquid のブリッジ コントラクトは、batchedDepositWithPermit 関数を使用して複数の入金をバッチ処理します。ここでの入金アクションは比較的単純で、資金セキュリティのリスクはなく、処理プロセスは UX を最適化するために Permit メソッドを使用するだけです。
お金を引き出す
入金と比較すると、出金は非常にリスクの高い操作であるため、出金のロジックは入金よりもはるかに複雑になります。ユーザーが出金リクエストを開始すると、Hyperliquid ノードはブリッジ コントラクトの batchedRequestWithdrawals 関数を呼び出します。現時点では、ブリッジ コントラクトでは、各出金リクエストで hotValidatorSet の署名の重みの 2/3 を収集する必要があることに注意してください。多くの文書ではここで「署名の 2/3 を収集する」と説明されていますが、実際にはブリッジ コントラクトでは「」がチェックされます。 2/3 シグネチャーウェイト」。現在、HyperLiquid には同じ重みを持つノードが 4 つしかないため、シグネチャの重みの確認とシグネチャの数の確認は一時的に同じになりますが、将来的には、HyperLiquid に重みの高いノードが導入される可能性があります。
出金リクエストが開始されると、クロスチェーンブリッジは契約によって管理されるUSDCをすぐには転送しませんが、不正防止プロトコルの「チャレンジ期間」と同様の「紛争期間」が発生します。 Hyperliquid ブリッジ契約の現在の紛争期間は 200 秒です。紛争期間中に、次の 2 つの状況が発生する可能性があります。
1. ロッカーは、現時点では、契約の一時停止/凍結を直接投票できると考えています。
2. ノードは、現時点で、一部の出金に問題があると判断し、coldValidatorSet メンバーは、invalidateWithdrawals 関数を呼び出して出金を無効にすることができます。
紛争期間中に問題がなかった場合、紛争期間終了後、ファイナライザーのメンバーはブリッジコントラクトのbatchedFinalizeWithdrawals関数を呼び出して、最終ステータスを確定できます。この関数がトリガーされた後にのみ、USDCがユーザーのウォレットアドレスに転送されます。アービトラムで。
したがって、セキュリティ モデルの観点から見ると、悪意のある攻撃者が Hyperliquid の出金プロセスを操作したい場合は、次の 3 つの防御線を突破する必要があります。
1. hotValidatorSet の署名の重みの 2/3 をマスターする。つまり、一定数の秘密鍵を取得するか、共謀する必要がある。現時点では HyperLiquid には 4 つのバリデーターしかなく、攻撃者によって制御されたり共謀されたりする可能性はありません。低い;
2. 紛争期間中、攻撃者は悪意のある取引が発見されるのを防ぐ必要があり、発見されるとロッカーが契約をロックする可能性があります。この部分については、以下で具体的に説明します。
3. 出金動作を最終的に確認できるように、少なくとも 1 人のファイナライザー メンバーの秘密キーを取得します。現時点では、ファイナライザーのメンバーと hotValidatorSet のメンバーは基本的に同じであるため、攻撃者が上記の条件 1 を満たしている限り、条件 3 は自動的に満たされます。
ブリッジ契約のロックイン
Hyperliquidがクロスチェーンブリッジコントラクトをロックする機能を設定したことは以前に何度も述べました。具体的には、クロスチェーンブリッジをロックするには、ロッカーメンバーがクロスチェーンブリッジコントラクトの voteEmergencyLock 関数を呼び出して投票する必要があります。現在、2 人のロッカーがこの関数を呼び出して投票すると、クロスチェーンブリッジコントラクトはロックされ、一時停止されます。
ただし、HyperLiquid のクロスチェーン ブリッジは、ロッカー メンバーが投票を取り消すことができる unvoteEmergencyLock 機能も提供していることに注意してください。クロスチェーン ブリッジ コントラクトが正常にロックされると、emergencyUnlock と呼ばれる関数を通じてのみロックを解除できます。この関数には、coldValidatorSet メンバーの署名の重みの 2/3 以上を収集する必要があります。
また、EmergencyUnlock 関数は、ロックを解除するときに新しい hotValidatorSet および coldValidatorSet バリデータ アドレス セットを入力し、すぐに更新されます。
バリデータセットの更新
撤退プロセスで既存の防御線を突破しようとするよりも、より良い攻撃方法は、updateValidatorSet 関数を直接使用して hotValidatorSet および coldValidatorSet バリデータ セットを更新することです。これには、呼び出し元がすべての hotValidatorSet メンバーに署名する必要があり、操作には 200 秒の紛争期間があります。
紛争期間が終了したら、ファイナライザーのメンバーは、finalizeValidatorSetUpdate 関数を呼び出して、最終ステータスの更新を完了する必要があります。
これまで、Hyperliquid クロスチェーン ブリッジの詳細のほとんどを紹介してきました。この記事では、ロッカーとファイナライザーの更新ロジックについては紹介しません。両方の更新には hotValidatorSet 署名が必要で、特定のメンバーの削除には coldValidatorSet 署名が必要です。
要約すると、Hyperliquid のブリッジ契約には次のリスクが含まれています。
1. ハッカーが coldValidatorSet を制御すると、あらゆる障害を無視してユーザー資産を盗むことができます。 coldValidatorSetはemergencyUnlock関数の操作権限を持っているため、ブリッジコントラクト上のロッカーのロック動作を無効化し、リアルタイムにノードリストを更新することができます。現在、Hyperliquid には検証ノードが 4 つしかなく、秘密鍵が盗まれる可能性は低くありません。
2.ファイナライザーはユーザーの出金取引の完了を拒否し、検閲攻撃を開始します。この場合、ユーザーの資産は盗まれませんが、ユーザーはブリッジ契約からお金を引き出すことができない可能性があります。
3. ロッカーは悪意を持ってクロスチェーン ブリッジをターゲットにします。現時点では、すべての出金トランザクションは実行できず、coldValidatorSet がロック解除されるまで待つことしかできません。
HyperEVM とデュアルチェーン対話アーキテクチャ
プライベート トランザクションやスマート コントラクトを必要とするその他のシナリオの導入など、オーダー ブック トランザクションをプログラム可能にするために、Hyperliquid は HyperEVM と呼ばれるソリューションを開始しました。これには、従来の EVM と比較して 2 つの特別な利点があります。1 つは、HyperEVM は HyperLiquid のオーダーブックのステータスを読み取ることができること、2 つ目は、HyperEVM のスマート コントラクトが Hyperliquid オーダーブック システムと対話できることです。これにより、Hyperliquid のアプリケーション シナリオが大幅に拡張されます。
簡単な例を挙げると、ユーザーが保留中の注文操作のプライバシーを確保する必要がある場合、Tornado Cash と同様のスマート コントラクトを通じて HyperEVM にプライバシー層を実装し、HyperLiquid のオーダーブック システムで保留中の注文アクションをトリガーできます。特定のインターフェイス。
HyperEVM を導入する前に、Hyperliquid が HyperEVM 用に用意した特別なアーキテクチャを導入する必要があります。 Hyperliquid はカスタマイズされた超高性能オーダーブック システムを備えているため、EVM 環境でのトランザクション処理速度は大幅に遅くなります。オーダーブック システムの速度低下を防ぐために、Hyperliquid は「デュアル チェーン ソリューション」を使用します。これにより、基本的に Hyperliquid ノード デバイスはソフトウェア レベルで 2 つのブロックチェーンを同時に実行でき、各ノードは 2 つのチェーンのデータをローカルに保存します。 2 つのチェーン上のトランザクションは別々に処理されます。
Hyperliquid は、カスタマイズされたオーダーブック システム用にチェーンを特別にセットアップし、EVM 互換チェーン (HyperEVM) も追加しました。これら 2 つのチェーンのデータは、同じコンセンサス プロトコルを通じてノード グループ間で分散され、統一された状態として存在しますが、異なる実行環境では別々に実行されます。オーダーブック専用チェーンを Hyperliquid L1 (L1) と呼びますが、これは許可型であり、HyperEVM に使用されるチェーンは HyperEVM (EVM) であり、許可なしであり、これらのコントラクトはプリコンパイルされたコードを通じて L1 の情報にアクセスできます。
Hyperliquid L1 のブロック生成速度は HyperEVM チェーンの速度よりも速いですが、これらのブロックは引き続き順番に実行されることに注意してください。 EVM チェーン上のコントラクトは、過去の L1 ブロックのデータを読み取り、将来の L1 ブロックにデータを書き込むことができます。以下に示すように:
HyperL1 と HyperEVM 間の相互作用を実現するために、Hyperliquid はプリコンパイルとイベントという 2 つの技術的手段を使用します。
プリコンパイル
いわゆるプリコンパイル (Precompile) とは、端的に言えば、スマート コントラクトにおける実装が難しく複雑性の高い一部の操作を下位層に直接移動し、Solidity にとって不親切でより複雑な計算プロセスを移動することです。通常のスマート コントラクトにとっては面倒な外部処理の場合、このタイプのプリコンパイル済みコードは、Solidity よりも基盤となるデバイスに近い C、C++、およびその他の言語で実装できます。
プリコンパイルされたメソッドにより、EVM はより高度で複雑な機能をサポートし、スマート コントラクト開発者のニーズを簡単にサポートできます。形式的には、プリコンパイルは本質的に一連の特殊なスマート コントラクトです。他のスマート コントラクトは、これらの特殊なコントラクトを直接呼び出し、パラメーターを渡し、プリコンパイルされた実行の戻り結果を取得できます。現在、ecRecover 命令はプリコンパイルを通じてネイティブ EVM に実装されており、EVM 内で secp256k1 署名が正しいかどうか、また命令が 0x01 アドレスに配置されているかどうかを確認できます。
現在、プリコンパイルを使用して特別な機能を追加することが主流となっています。たとえば、Base は、ユーザーが WebAuth ID 認証操作を実行しやすくするために、P256 プリコンパイル済みコードを追加しました。
(この画像はロールアップ コード Web サイトからのものです)
この現在の主流ソリューションに沿って、HyperEVM には、EVM が Hyperliquid オーダーブック システムのステータスを読み取れるようにするための一連のプリコンパイル済みコードも追加されています。現在知られている Hyperliquid のプリコンパイル済みコード アドレスは 0x00000000000000000000000000000000000800 です。このプリコンパイル済みアドレスは、最新の L1 ブロック内のユーザーの永久契約の位置を読み取ることができます。
イベント
HyperEVM は HyperL1 ブロックにデータを書き込むことができ、書き込み動作はイベントに依存することを上で説明しました。イベントは EVM のネイティブ概念であり、スマート コントラクトが実行中にログ情報を外部 (フロントエンド アプリケーションやリスナーなど) に送信できるようになり、外部がスマート コントラクトの実行ステータスを監視できるようになります。
たとえば、ユーザーがERC-20コントラクトのトークン転送機能を使用すると、コントラクトは転送に対応するイベントをスローするため、ブロックブラウザなどのフロントエンドアプリケーションはトークンの転送状況を知ることができます。これらのイベント情報はブロックに含まれており、イベント ログを監視および取得するための成熟したソリューションが多数あります。
現在、多くのクロスチェーン関連のシナリオでは、イベントを使用してクロスチェーン パラメーターを渡します。たとえば、Arbitrum はイーサリアム メイン ネットワークのブリッジ コントラクトにデプロイされており、ユーザーは関連する関数を呼び出してイベントをスローし、Arbitrum 上でトランザクションをトリガーできます。
既知の情報は、HyperLiquid ノードがリッスンすることを示しています
0x333333333333333333333333333333333333 (イベントアドレス) Events に含まれる情報を元にユーザーの意図を知り、これに応じて意図をトランザクションアクションに変換し、将来の Hyperliquid L1 ブロックに書き込みます。
たとえば、上記のイベント アドレスは関数を提供し、ユーザーがこの関数を呼び出すと、イベント アドレスは IocOrder という名前のイベントをスローします。 Hyper L1 ブロックが生成されると、HyperLiquid ノードはまず HyperEVM の最近のイベント アドレスによってスローされたイベントをクエリします。新しい IocOrder イベントが取得されると、それは Hyper L1 の保留中の注文操作に変換されます。
ハイパーBFT
コンセンサスプロトコルレベルでは、HyperliquidはHyperBFTと呼ばれるプロトコルを採用しています。これはHotStuffをベースにした派生方式です。現時点では、HutStuff-2 は最も複雑性の低い最新のコンセンサス プロトコルの 1 つです。
データによると、HyperLiquid は当初、Cosmos システムで使用されるデフォルトのコンセンサス アルゴリズムである Tendermint コンセンサス アルゴリズムを使用していましたが、このアルゴリズムは各段階で All-to-All メッセージ交換が必要であり、各ノードが に報告する必要があります。他のすべてのノードはメッセージを送信し、通信の複雑さは O(n²) です。ここで、n はノードの数です。
Tendermint を使用すると、Hyperliquid は 1 秒あたり最大 20,000 件の注文を処理できます。集中型取引所の速度を実現するために、HyperLiquid チームは HotStuff に基づいて HyperBFT アルゴリズムを開発し、Rust に実装しました。理論的には 1 秒あたり最大 200 万件の注文を処理できます。
以下の図は、非並列状況での HyperBFT コンセンサスのメッセージ配信方法を示しています。すべてのメッセージがリーダーによってまとめられ、均一にブロードキャストされるため、ノード間でメッセージを交換するステップがなくなり、複雑さが大幅に軽減されることがわかります。
簡単に言うと、HyperBFT は現在のリーダーがブロックを生成し、すべてのノードが投票に参加し、投票結果が一律にリーダーに送信され、次のリーダーがローテーションされるコンセンサス プロトコルです。実際、Hotstuff と Tendermint に関係する具体的な詳細はさらに複雑です。この記事では長さと焦点の制限があるため、ここでは詳しく説明しません。
開発者向けの注意点
前述のプリコンパイルに基づくデータ読み取りメカニズムは比較的完璧です。Solidity 開発者は、Hyper L1 ステータスを読み取るときに対応するコードを記述する必要はありませんが、msg.sender の問題に注意する必要があります。ほとんどの Ethereum の第 2 層と同様に、HyperLiquid では、ユーザーが Hyper L1 でシステム コントラクトと直接対話し、HyperEVM チェーン上で間接的にトランザクション アクションをトリガーすることもできます。このとき、スマート コントラクトがトランザクションの msg.sender フィールドを読み取ると、それが実行されます。 msg.sender は、HyperL1 で最初にトランザクションを開始したユーザーのアドレスではなく、HyperL1 システム コントラクトのアドレスに対応することがわかりました。
EVM と L1 の間の相互作用に関して、開発者は一連の問題に注意を払う必要があります。最初の問題は、ユーザーが HyperEVM 上の前述のイベント アドレスを通じて間接的に L1 に注文を出した場合、L1 に十分な資産がない場合、トランザクションは確実に失敗しますが、ユーザーはイベントアドレスを使用すると、エラーを返すプロンプトは表示されません。インタラクションの非アトミック性に関する問題により、ユーザーの資産が侵害される可能性があります。現時点では、開発者は EVM スマート コントラクト側で保留中の注文の失敗を手動で処理する必要があります。さらに、EVM のスマートコントラクトには、L1 でユーザー資産が決して引き出されないように、最終的な資金回収機能を持たせる必要があります。
次に、EVM に対応するコントラクト アドレスには、L1 にマッピング アカウントが必要です。ユーザーが EVM にスマート コントラクトを展開する場合、少量の USDC を L1 のマッピング アドレスに転送する必要があり、L1 にそのアカウントの作成を強制します。契約住所。操作のこの部分は、HyperLiquid の基礎となるコンセンサスに関連している可能性があり、これは Hyperliquid のドキュメントで明らかに要求されています。
最後に、開発者はいくつかの特殊な状況、特にトークンの残高に注意を払う必要があります。 Hyper L1 には資産転送用の特別なアドレスがありますが、ユーザーがこの特別なアドレスに資産を送信すると、資産は L1 から HyperEVM チェーンに転送されます。 HyperLiquid ノードは実際には EVM チェーンと L1 チェーンを同時に実行するため、ユーザーがアセットを転送した後、長期間 HyperEVM がブロックを生成していない可能性があります。このとき、ユーザーは自分のデータを読み取ることができません。 EVM チェーン上のバランスを調整します。
簡単に言うと、現時点ではユーザーの資産はクロスチェーン ブリッジでスタックしており、L1 チェーンでも EVM チェーンでもクエリを実行できません。開発者が構築したプロトコルは、ユーザーのパニックを避けるために上記の特殊な状況に対処する必要があります。
要約すると、HyperEVM は Hyperliquid L1 に基づく 2 番目のレイヤーに似ています。HyperEVM は、プリコンパイルされたコードに依存して L1 ステータスを読み取り、イベントにも依存して Hyper L1 と対話します。 L1 には、ユーザーが HyperEVM 内でトランザクションをトリガーしたり、クロスチェーン資産を実行したりできるようにするためのシステム契約もあります。ただし、一般的な Layer1-Layer2 アーキテクチャとは異なり、Hyperliquid は HyperEVM に高い相互運用性を提供します。
参考文献
Hyperliquid: 超最適化されたオーダーブック L1
ハイパーリキッドデックス/契約
Hyperliquid プリコンパイルに関する、それほど決定的ではないガイド。
PBFT、Tendermint、HotStuff、および HotStuff-2 の違いは何ですか?
