Hyperliquidの技術構造とセキュリティリスクの深掘り

最近注目を集めているHyperliquidは、最も影響力のあるオンチェーンオーダーブック取引所の一つであり、その総ロックアップバリューは20億ドルを超え、業界では「オンチェーン版の某有名な中央集権取引所」と評価されています。同時に、Layer3やアプリケーションチェーンに対する議論も再燃しています。ローンチから1ヶ月でプロジェクトの評価額が300億ドルに達するという素晴らしい成果を持つHyperliquidは広く注目を浴びています。現在、市場にはHyperliquidに関する多くの分析レポートがありますが、ほとんどは製品機能や取引メカニズムに集中しており、その技術アーキテクチャや潜在的なセキュリティリスクに関する深い分析が欠けています。

この記事は、この空白を埋めることを目的とし、純粋に技術と安全性の観点からHyperliquidを解析し、読者がこのスタープロジェクトの内部構造と原理をよりよく理解できるようにします。私たちは、Hyperliquidのクロスチェーンブリッジ契約の設計とリスク、そしてHyperEVMとHyperL1のデュアルチェーンアーキテクチャを重点的に分析し、その背後にある技術的実現方法について深く探討します。

! 誇大広告の引き潮と流れ、Hyperliquidのブリッジコントラクト、HyperEVMとその潜在的な問題の技術的解釈

Hyperliquidクロスチェーンブリッジ解析

Hyperliquidはそのコアコンポーネントをオープンソースにしていないが、関連するブリッジコントラクトはオープンソースにしているため、ブリッジコントラクトに関するリスクについてより多くの理解を得ることができる。HyperliquidはあるLayer2ネットワーク上にブリッジコントラクトを展開し、ユーザーが預け入れたUSDC資産を保存するために使用している。私たちはBridgeコンポーネントを通じてHyperliquidノードの一部の行動を観察することができる。

バリデーターセット

ノードの身分の観点から見ると、Hyperliquidには4つのバリデーターグループがあり、それぞれhotValidatorSet、coldValidatorSet、finalizers、lockersです。それぞれ異なる役割を担っています。hotValidatorSetは、ユーザーの高頻度の操作、例えば出金などに応じる役割を担い、通常はユーザーのリクエストに迅速に対応するためにホットウォレットを使用します。

coldValidatorSetは、他のバリデーターのセットのリストを更新したり、ブリッジコントラクトのロック状態を処理したりするなど、システム設定を変更するために主に使用され、特定の引き出しリクエストを直接無効にする権限を持っています。

lockersは、Layer2でよく見られる「セキュリティ委員会」に似た、特別な権限を持つバリデーターのグループです。緊急時には、クロスチェーンブリッジの運用を一時停止するかどうかを投票で決定できます。現在、Hyperliquidブリッジのlockersコレクションには5つのアドレスが含まれており、2つのlockerの投票があればブリッジ契約を一時停止できます。

ファイナライザーは、一群の特殊なバリデーターであり、主にクロスチェーンブリッジの状態変化を確認するために使用されます。例えば、ユーザーの入出金などの操作です。Hyperliquidのクロスチェーンブリッジは「提出-確認」メカニズムを採用しており、ユーザーが引き出しを開始した後、一定の「異議期間」を待つ必要があります。期間が満了した後、ファイナライザーが引き出し取引を実行します。

問題が発生した場合、例えばある出金申請がユーザーの実際の残高を超えた場合、Hyperliquidノードは争議期間中にロッカーによる投票でブリッジコントラクトを一時停止するか、coldValidatorSetによって問題の出金を無効にすることができます。

現在、Hyperliquidには4つのバリデーターノードしかないため、hotValidatorSetとcoldValidatorSetはそれぞれ4つのオンチェーンアドレスに対応しています。初期化時に、Hyperliquidは自動的にhotValidatorSet内のアドレスをロッカーおよびファイナライザーのメンバーとして登録し、coldValidatorSetは公式によって管理され、冷蔵ウォレットで鍵を保管します。

! 誇大広告の引き潮と流れ、Hyperliquidのブリッジ契約の技術的解釈、HyperEVMとその潜在的な問題

###預金

Hyperliquidのブリッジコントラクトは、EIP-2612のPermitメソッドに基づいてユーザーの預金を処理し、USDCの1種類の資産のみをサポートしています。従来のApprove-Transferモードと比較して、Permitはより簡潔で、大量操作が容易です。

ブリッジコントラクトは、batchedDepositWithPermit関数を使用して複数の入金を一括処理します。プロセスはシンプルで、資金の安全リスクはなく、主にPermitメソッドを利用してユーザーエクスペリエンスを最適化しています。

###引き出し

預金と比較して、出金は高リスクの操作であり、そのためロジックはより複雑です。ユーザーが出金リクエストを開始すると、HyperliquidノードがブリッジコントラクトのbatchedRequestWithdrawals関数を呼び出します。この時、各出金リクエストはhotValidatorSetの2/3の署名重みを得る必要があり、注意すべきは「2/3の署名重み」であって「2/3の署名数」ではないということです。現在、Hyperliquidには同じ重みを持つ4つのノードしかないため、署名重みと署名数のチェックは一時的に一致していますが、将来的には高重みのノードが導入される可能性があります。

出金リクエストを開始した後、クロスチェーンブリッジはすぐにUSDCを転送せず、200秒の「異議申し立て期間」があります。この期間中に2つの事態が発生する可能性があります:

1. ロッカーは、出金リクエストに重大な問題があると見なした場合、契約を直接投票で凍結することができます。

2. ノードは一部の出金に問題があると考え、coldValidatorSetのメンバーはinvalidateWithdrawals関数を呼び出してその出金を無効にすることができます。

争議期間中に異常がなければ、期限後にfinalizersメンバーはbatchedFinalizeWithdrawals関数を呼び出して最終状態を確認できます。この時、USDCはユーザーのLayer2ウォレットアドレスに転送されます。

セキュリティモデルの観点から見ると、悪意のある攻撃者がHyperliquidの出金プロセスで悪事を働くためには、3つの防御線を突破する必要があります:

1. hotValidatorSetの2/3署名権限を掌握し、十分な秘密鍵を取得するか、共謀する必要があります。現在、検証者は4人しかおらず、制御または共謀の可能性は低くありません。

2. 争議期間中に悪意のある取引が発見されないようにしてください。さもなければ、ロッカーが契約をロックする可能性があります。

3. 少なくとも1つのfinalizersメンバーの秘密鍵を取得し、出金を確認します。現在、finalizersはhotValidatorSetメンバーと基本的に一致しており、条件1を満たせば条件3も満たすことができます。

! 誇大広告は衰えており、Hyperliquidのブリッジ契約、HyperEVMとその潜在的な問題は技術的な観点から説明されています

ブリッジコントラクトのロック

Hyperliquidは、クロスチェーンブリッジ契約をロックする機能を設定しました。具体的には、ロッカーのメンバーがvoteEmergencyLock関数を呼び出して投票する必要があります。現在、2名のロッカーが投票すれば、ブリッジ契約をロックして一時停止することができます。

注目すべきは、HyperliquidブリッジがunvoteEmergencyLock関数を提供していることで、ロッカーが投票を撤回できるようになっています。一度ブリッジコントラクトがロックされると、emergencyUnlock関数を介してのみ解除でき、coldValidatorSetメンバーの2/3以上の署名重みを集める必要があります。

emergencyUnlockは、hotValidatorSetバリデーターセットとcoldValidatorSetバリデーターのアドレスセットを同時にロック解除し、すぐに有効になります。

バリデーター集合の更新

引き出しプロセスの防御を突破するよりも、updateValidatorSet関数を直接使用してバリデーターセットを更新する方が、より効果的な攻撃手段です。これには、すべてのhotValidatorSetメンバーの署名が必要で、200秒の異議申し立て期間があります。

紛争期間が終了すると、ファイナライザー メンバーは finalizeValidatorSetUpdate 関数を呼び出して最終更新を完了します。

Hyperliquidブリッジ契約には以下のリスクがあります。

1. ハッカーがcoldValidatorSetを制御すると、ユーザー資産を盗むために障害を無視できる。coldValidatorSetはemergencyUnlock権限を持ち、lockersのロックを無効にしてノードリストを即座に更新できる。現在、バリデーターは4つのみで、秘密鍵が盗まれるリスクは低くない。

2. ファイナライザーはユーザーの出金取引の確認を拒否し、攻撃の調査を行います。この時、ユーザーの資産は安全ですが、引き出すことができない可能性があります;

3. ロッカーが悪意を持ってクロスチェーンブリッジをロックし、すべての引き出し取引の実行を妨げ、coldValidatorSetのロック解除を待つしかない。

! 誇大広告の衰退、Hyperliquidのブリッジ契約、HyperEVMとその潜在的な問題の技術的解釈

HyperEVMとデュアルチェーンインタラクションアーキテクチャ

注文書取引のプログラム化を実現するため、プライバシー取引などのスマートコントラクトのサポートが必要なシーンを導入するために、HyperliquidはHyperEVMソリューションを発表しました。これは、従来のEVMに比べて2つの大きな利点があります: Hyperliquidの注文書の状態を読み取ることができ、内部のスマートコントラクトが注文書システムと相互作用できるため、アプリケーションのシーンが大幅に拡大されます。

例えば、ユーザーが注文のプライバシーを保証する必要がある場合、HyperEVM上でTornado Cashのような契約を通じてプライバシーレイヤーを追加し、特定のインターフェースを介してHyperliquidオーダーブックシステムで注文をトリガーすることができます。

HyperliquidはHyperEVMのために特別なアーキテクチャを設計しました。カスタマイズされたオーダーブックシステムのパフォーマンスがEVM環境を大きく上回ることを考慮し、速度低下を避けるために、Hyperliquidは「デュアルチェーンアプローチ」を採用しています：各ノードは同時に2つのチェーンを実行し、ローカルに2つのチェーンのデータを保存し、それぞれの取引を処理します。

Hyperliquidは注文簿システムのために専用チェーン(HyperL1を設定し、許可制)、同時にEVM互換チェーン(HyperEVMを追加し、無許可)です。二つのチェーンのデータは同じコンセンサスプロトコルを通じて伝播し、統一された状態として存在しますが、異なる環境で動作します。HyperL1のブロック生成速度はHyperEVMよりも速いですが、ブロックは依然として順序通りに実行されます。EVMチェーン上の契約は過去のL1ブロックデータを読み取り、未来のL1ブロックにデータを書き込むことができます。

HyperL1 と HyperEVM の相互作用は、主にプリコンパイルとイベントを通じて実装されます。

! 誇大広告の衰退、Hyperliquidのブリッジ契約、HyperEVMとその潜在的な問題の技術的解釈

プレコンパイル

プレコンパイル(Precompiles)は、複雑な操作を直接底層で実装し、C/C++などの言語でSolidityに不向きな計算を処理します。プレコンパイルは本質的には特殊なスマートコントラクトであり、他のコントラクトが呼び出して実行結果を取得できます。現在、ネイティブEVMはプレコンパイルを使用してecRecover命令(0x01アドレス)を実装しています。

HyperEVMはプリコンパイルコードを追加し、Hyperliquid注文簿システムの状態を読み取ることを実現しました。既知のプリコンパイルアドレスは0x0000000000000000000000000000000000000800で、最近のL1ブロック内のユーザーの永久契約ポジションを読み取ることができます。

イベント

HyperEVMはHyperL1へのデータ書き込みにEventsを使用します。EventsはEVMのネイティブな概念で、コントラクトが外部にログ情報を送信することを可能にします。例えば、ERC-20の送金時にはTransferイベントが発生し、リスニングを容易にします。多くのクロスチェーンシナリオでも、Eventsを使用してパラメータを伝達します。

HyperLiquidノードは、0x3333333333333333333333333333333333333333アドレスが発生させるEventsをリスニングし、情報に基づいてユーザーの意図を把握し、取引アクションに変換し、将来のL1ブロックに書き込みます。もしそのアドレスが関数を提供し、呼び出し時にIocOrderイベントを発生させる場合、L1のブロック作成時にノードが新しいIocOrderイベントを検出すると、それをL1内の掛け注文操作に変換します。

! 誇大広告は衰えており、Hyperliquidのブリッジ契約、HyperEVMとその潜在的な問題は技術的な観点から説明されています

ハイパーBFT

コンセンサスプロトコルに関して、HyperliquidはHotStuffに基づいたHyperBFTプロトコルを採用しています。初期にはTendermintアルゴリズムを使用しましたが、効率が悪く、各ステージで全てのノード間でメッセージ交換が必要で、複雑度はO(n²)です。

中央集権型取引所の速度を達成するために、チームはHyperBFTを開発し、Rustで実装しました。理論的には、毎秒200万件の注文を処理できます。HyperBFTでは、すべてのメッセージがリーダーによって集約されて放送され、ノード間のメッセージ交換を省略し、複雑さを大幅に減少させます。

簡単に言えば、HyperBFTは現在のリーダーがブロックを生成し、全ノードが投票を行い、その結果をリーダーに一元的に送信し、次のリーダーのコンセンサスプロトコルをローテーションするものです。

! 誇大広告の引き潮、Hyperliquidのブリッジコントラクト、HyperEVMとその潜在的な問題の技術的解釈

開発者向けの考慮事項

1. Precompilesに基づくデータ読み取りメカニズムは比較的整っているが、msg.senderの問題に注意が必要である。ユーザーがL1システムのコントラクトとインタラクションを行い、間接的にEVMトランザクションを引き起こすとき、EVM内のmsg.senderはユーザーアドレスではなくL1システムコントラクトのアドレスである。

2. EVMとL1のインタラクションには非原子性の問題があります。ユーザーがEVMを介してL1に注文を出しましたが、資産が不足している場合、取引は失敗しますが、関数呼び出し時にエラーメッセージは表示されません。開発者はEVMコントラクト側で注文失敗の状況を処理し、資金回収関数を設定する必要があります。

3. EVMコントラクトアドレスはL1にマッピングアカウントを持つ必要があります。EVMコントラクトをデプロイした後、L1マッピングアドレスに少量のUSDCを転送してアカウントを作成する必要があります。

4. 特殊な状況に注意してください、例えばトークンの残高。L1には資産のクロスチェーン用の特別なアドレスがありますが、クロスチェーン後にEVMがブロックを即時に生成しない可能性があるため、ユーザーは一時的に残高を読み取ることができません。開発者はこのような状況に対処し、ユーザーのパニックを避けるべきです。