Hyperliquidアーキテクチャ解説：セキュリティと分散化
なぜHyperliquidが2025-2026年に重要なのか
オンチェーンデリバティブは、ニッチなDeFiプロダクトから、主要なクリプト市場の基盤へと進化しました。2025年だけでも、パーペチュアルDEXの累計取引量は劇的に増加し、これはトレーダーがオンチェーンの透明性と自己管理を維持しながら、CEXのような執行をますます求めるようになっているという、より広範なシフトを反映しています。DefiLlamaベースのパーペチュアルDEX取引量トレンドをまとめたレポートは、このセグメントがどれほど急速に成長したかを強調しています。（cointelegraph.com）
Hyperliquidはこの変化の中心に位置しています。なぜなら、それは「単なるパーペチュアルアプリ」ではないからです。Hyperliquidは、オンチェーンのオーダーブックを非常に高いスループットで実行するために構築されたレイヤー1であり、HyperEVMを通じてその基盤を汎用スマートコントラクト環境に拡張しました。DefiLlamaのHyperliquidダッシュボードによると、Hyperliquidは数兆ドル規模の累計パーペチュアル取引量を達成しており、オンチャートレバレッジ取引の主要なプラットフォームとしての役割を裏付けています。（defillama.com）
この記事では、以下の2つの問いを念頭に置きながら、Hyperliquidのアーキテクチャを解説します。
- オンチェーンでありながら、なぜ高速なのか？
- セキュリティと分散化のトレードオフは、どこに残っているのか？
Hyperliquidを1つの図で理解する（メンタルモデル）
Hyperliquidは、BFTスタイルのPoSコンセンサスであるHyperBFTを実行するバリデーターセットによって保護された単一のブロックチェーンです。実行は2つのドメインに分かれています。
- HyperCore: 目的特化型金融プリミティブ（スポット＋パーペチュアルオーダーブック、証拠金、清算）
- HyperEVM: 同じL1内に構築されたEVM実行環境であり、同じコンセンサスセキュリティを継承しています。
Hyperliquid独自のドキュメントでは、この分割についてテクニカル概要で明確に説明しています。（hyperliquid.gitbook.io）
コンセンサス：HyperBFTと「BFTスタイルのファイナリティ」が意味するもの
HyperBFTはHotStuffにインスパイアされたPoSコンセンサス
Hyperliquidは、HyperBFT、「HotStuffコンセンサスのバリアント」によって保護されていると述べており、ブロック生成はステーク量に比例します。HyperCore概要を参照してください。（hyperliquid.gitbook.io）
「HotStuffファミリー」のコンセンサスが最適化しているもの（部分的同期下での応答性と効率性）の学術的な基準を知りたい場合は、元の論文HotStuff: BFT Consensus in the Lens of Blockchainを参照してください。（arxiv.org）
実践的なポイント: BFTスタイルのPoS（確率的ファイナリティではなく）は、オーダーブックDEXにとって魅力的です。なぜなら、トレーダーはボラティリティ中の決定論的な順序付けと高速なファイナリティを重視するからです。
クォーラム、ジェイリング、バリデーターエポック
Hyperliquidのステーキングドキュメントでは、古典的なBFTクォーラムの仮定を強調しています。クォーラムはステークの2/3超であり、安全性/ライブネスはクォーラムのステークが正直であることを前提としています。また、以下の点についても説明しています。
- コンセンサスは「ラウンド」で進行する
- バリデーターセットの変更はエポック（継続的ではない）で発生する
- パフォーマンスの低下に対するジェイリング（スラッシングとは異なる）
ステーキング（技術詳細）を参照してください。（hyperliquid.gitbook.io）
分散化にとってなぜ重要か: 「誰がステークを保有し、誰がバリデーターを実行し、セットが時間とともにどのように変化するか」は、単なるガバナンスではなく、チェーンのコアセキュリティモデルの一部です。
実行レイヤー：なぜHyperCoreは典型的なDEX設計とは異なるのか
完全オンチェーンオーダーブック（オフチェーンマッチングエンジンではない）
一般的なDEXのパターンは、オフチェーンオーダーブック＋オンチェーン決済（またはオンチェーンAMM）です。Hyperliquidは異なる立場をとっています。HyperCoreは、注文、キャンセル、取引、清算がオンチェーンで発生し、コンセンサスによって単一の整合性のある順序が生成されるように設計されています。
同社のドキュメントでは、HyperCoreが「オフチェーンオーダーブックの助けに依存しない」こと、そして証拠金とマッチングエンジンの状態がオンチェーンに含まれていることを強調しています。HyperCore概要を参照してください。（hyperliquid.gitbook.io）
レイテンシとスループットの目標
Hyperliquidは、コロケーションされたクライアントに対して非常に低いエンドツーエンドレイテンシを報告しており、メインネットのスループットは約20万注文/秒のオーダーです。これもHyperCore概要に記載されています。（hyperliquid.gitbook.io）
これはコアとなるアーキテクチャの賭けです。汎用チェーンを最初に構築するのではなく、Hyperliquidは基盤チェーンを金融メッセージのスループット（注文、キャンセル、清算）に最適化しました。
HyperEVM： 「別のチェーン」になることなくプログラマビリティを実現
HyperEVMはHyperBFTセキュリティを継承
Hyperliquidは、HyperEVMがスタンドアロンネットワークではないことを非常に明確にしています。「EVMブロックはHyperliquidの実行の一部として構築され、HyperBFTコンセンサスからすべてのセキュリティを継承しています。」HyperEVM（開発者向けドキュメント）を参照してください。（hyperliquid.gitbook.io）
同じドキュメントからの主要な運用詳細：
- メインネットチェーンID: 999
- EIP-1559対応（blobなしのCancunハードフォーク）
- HYPEはネイティブガスです
- 優先手数料もバーンされます（注目すべき設計選択）
HyperEVM（開発者向けドキュメント）を参照してください。（hyperliquid.gitbook.io）
デュアルブロックアーキテクチャ：ユーザー向けの小さなブロック、ビルダー向けの大きなブロック
HyperEVMは、高速な確認と大きなブロックサイズの間で単一の強制的なトレードオフを回避するために、デュアルブロックアーキテクチャを使用しています。Hyperliquidのドキュメントによると：
- 約1秒で200万ガスリミットの小さなブロック
- 約1分で3000万ガスリミットの大きなブロック
デュアルブロックアーキテクチャを参照してください。（hyperliquid.gitbook.io）
なぜ重要か: これは、HyperliquidがL1設計を実際の取引とアプリケーションの需要に合わせて調整している最も明確な例の1つです。トレーダーは迅速な確認を求め、DeFiビルダーはより重いコントラクト展開のためのスペースを求めています。
HyperCoreとHyperEVM間の資産移動方法
Hyperliquidは、クロスドメイン転送の特定のタイミングルールを説明しています（Core→EVMは次のEVMブロックまでキューイングされ、EVM→CoreはEVMブロックの直後に処理されます）。インタラクションタイミングを参照してください。（hyperliquid.gitbook.io）
また、Hyperliquidは、HYPEをHyperEVMに移動するための標準的なメカニズムを提供しています（特定のアドレスに送信）。HyperEVM（開発者向けドキュメント）を参照してください。（hyperliquid.gitbook.io）
例（ドキュメントより）：
HYPEをHyperCoreからHyperEVMに移動するには：
HYPEを0x2222222222222222222222222222222222222222に送信
セキュリティモデル：コンセンサスによって保護されるもの vs 「アプリケーションリスク」
Hyperliquidのセキュリティについて考えるための有用な方法は、以下の点を分離することです。
- コンセンサスセキュリティ（HyperBFTの正確性、クォーラムの仮定、バリデーターの挙動）
- 実行の正確性（HyperCoreのマッチング/証拠金ロジック、HyperEVMのEVMセマンティクス）
- ブリッジングと資産カストディパス（資金がどのように出入りするか、どのコントラクトに依存するか）
- オラクルとリスク管理（マークプライス、OIキャップ、清算の挙動）
リスク開示：L1リスク、オラクル操作、ブリッジリスク
Hyperliquid自身のリスクページでは、以下の点を挙げています。
- L1ダウンタイムリスク（新しいチェーンで、まだ十分にテストされていない）
- オラクル操作リスク（バリデーター管理のオラクル）
- スマートコントラクト/ブリッジリスク（ドキュメントではブリッジコントラクトへの依存を具体的に言及）
同ページでは、オープンインタレストキャップや、流動性の低い資産に対するオラクル価格から大きく離れた注文の制限などの軽減策も記載しています。（hyperliquid.gitbook.io）
バグバウンティ：セキュリティフィードバックループとして
Hyperliquidは、メインネットノード/APIの問題、および（テストネット上での）HyperEVMインタラクションサーフェスを対象とした公式のバグバウンティプログラムを実行しています。バグバウンティプログラムを参照してください。（hyperliquid.gitbook.io）
セキュリティについての教訓：急速に進化するDeFiインフラストラクチャにおいて、責任ある開示への継続的なインセンティブは選択肢ではなく、プロトコルの運用の一部です。
プロトコルレイヤーの組み込みマルチシグ（HyperCore）
注目すべき設計上の選択：HyperCoreは、スマートコントラクトウォレットパターンを必要とするのではなく、ネイティブマルチシグアクションを組み込みプリミティブとしてサポートしています。マルチシグ（HyperCore）を参照してください。（hyperliquid.gitbook.io）
ユーザーへの注意点: オペレーター、LP、または高額トレーディングを行う場合、マルチシグはシングルキーリスクを軽減できます。これは、クリプトにおいて最も一般的な障害モードの1つです。
分散化：Hyperliquidが強い点と、議論が残る点
分散化は単一の指標ではありません。Hyperliquidにとって、それは通常以下の点に集約されます。
- バリデーターの独立性とステーク分布
- コードの透明性（オープンソース vs クローズドコンポーネント）
- ガバナンスと緊急権限（バリデーターは実際には何ができるのか？）
「クローズドソースノード」とステーク集中に関する議論（2025年）
2025年初頭、Hyperliquidは、バリデーターの公平性、ステークの集中、そして当時ノードコードが完全にオープンソース化されていなかったという事実に関して、分散化を巡る公の精査に直面しました。CoinDeskは、分散化の強化計画やデリゲーションプログラムへの言及を含む、Hyperliquidの対応を報じました。CoinDesk報道を参照してください。（coindesk.com）
アーキテクチャにとってなぜ重要か: HotStuffスタイルのPoSチェーンは技術的に堅牢である可能性がありますが、分散化の認識は、バリデーターが独立して運用できるかどうか（ノードソフトウェアのレビューと実行を最小限の「ゲートキーピング」で行えるかを含む）によって大きく左右されます。
バリデーター介入：実世界のストレステスト
高名な市場インシデントの後、バリデーターがパーペチュアル市場を上場廃止し、ポジションを強制決済したことで、極限状態における「止められない」市場の限界に関する疑問が生じ、別の分散化に関する議論が浮上しました。Blockworksはこの出来事を報じ、分散化の制約を明らかにしたと論じました。Blockworks分析を参照してください。（blockworks.co）
これは、オンチェーントリバティブにおける主要な緊張関係を浮き彫りにしています。
- トレーダーは操作試行中の堅牢なリスク管理を要求します。
- DeFiユーザーは、信頼できる中立性と予測可能なルールを期待します。
健全な分散化の問い: 緊急措置はルールベースで、透明性があり、明確な正当性をもって統治されているか、それとも場当たり的か？その答えは、ユーザーがシステムを、変更不能なインフラストラクチャとして扱うか、管理された会場として扱うかに影響します。
「セキュリティ＋UX」：オンチェーンパーペチュアルの新たな戦場
2025年、オンチェーンパーペチュアルの取引量は記録的なレベルに達し、プラットフォーム間の競争は激化しました。市場構造は以下へとシフトしています。
- より優れた執行レイテンシ
- より深い流動性
- より明確なリスク管理
- カストディとアクセスに関するより強力な保証
これが、Hyperliquidのアーキテクチャが重要である理由です。それは、高性能取引を「後付け」されたものではなく、ファーストクラスのL1機能にすることを目指す試みだからです。
ユーザー（トレーダー、LP、ビルダー）のための実践的なチェックリスト
1）キーセキュリティを取引上の優位性の一部と見なす
キーを保護できなければ、パフォーマンスの向上はすべて無意味です。Hyperliquid独自のサポートドキュメントは、フィッシング対策と公式URLの確認を強調しています。サポートガイドを参照してください。（hyperliquid.gitbook.io）
2）マルチシグを使用する（少なくとも役割を分担する）
チームの場合、以下を分離することを検討してください。
- 取引オペレーターキー
- 財務管理キー
- コントラクトのデプロイ/管理者キー（HyperEVM上に構築する場合）
HyperCoreの組み込みマルチシグは、このための有用なプリミティブです。マルチシグ（HyperCore）を参照してください。（hyperliquid.gitbook.io）
3）レバレッジ使用前にオラクルと流動性のリスクを理解する
プロトコルのリスクページを読み、それを法的書類ではなく、取引前の必須のデューデリジェンスとして扱ってください。（hyperliquid.gitbook.io）
OneKeyがフィットする場所（オンチェーン速度に匹敵する自己管理）
Hyperliquidの進化（特にHyperEVM）は、単純なトレンドを強化しています。より深刻な取引とDeFi活動がオンチェーンに移行しているため、安全なトランザクション署名と運用上の安全性がより重要になっているのです。
OneKeyのようなハードウェアウォレットは、そのセキュリティスタックにおいて実用的なレイヤーとなり得ます。
- プライベートキーを日常のデバイスから隔離する
- 高頻度DeFi活動中のフィッシングとマルウェアの被害範囲を縮小する
- マルチアカウント運用セットアップ（取引と財務管理の分離）と良好に連携する
目標はユーザーを遅くすることではなく、「高速なオンチェーン金融」が現実世界の脅威モデルの下で存続可能にすることです。
最終的な考察：Hyperliquidのアーキテクチャは、統合されたオンチェーン金融への賭け
Hyperliquidのデザインは一貫しています。レイテンシに最適化されたHotStuffにインスパイアされたBFT PoSコンセンサス、特殊な金融実行エンジン（HyperCore）、そしてベースチェーンのパフォーマンスプロファイルを犠牲にすることなくコンポーザビリティをもたらすことを目指す、緊密に統合されたEVM環境（HyperEVM）です。HyperCore + HyperEVMを単一の統合システムとして記述したドキュメントは、スタック全体を理解するための鍵です。Hyperliquidについてを参照してください。（hyperliquid.gitbook.io）
同時に、2026年にHyperliquidについて行われる最も重要な会話は、DeFiインフラストラクチャ全般を定義するものと同じである可能性が高いです。
- 使用量が拡大するにつれて、分散化がどのように進化するか
- バリデーターの権限がどれだけ透明でルールに基づいたものになるか
- セキュリティプロセス（バウンティ、監査、インシデント対応）が成長にどれだけ追いつくか
