Hyperliquidレビュー：高頻度・大規模・高レバレッジのオンチェーン・オーダーブックのための唯一のソリューション

原著者: Godot

最近、自分のトレード判断と保有資産を見直した。Hyperliquid $HYPE を見た。

アロップフェーズの間はこのプロジェクトを追っていたものの、私はそれをどちらかというと「陰謀グループ」のような視点で見ていた。たとえば、プロの高頻度取引プラットフォームに根ざしたチームが、親会社を使って収益性の高いプロジェクトを運営しており、資金調達なし、トークンのプレセールなし、トークン供給も非常に厳格に管理されている、といった具合だ。

要するに私は、初期供給が厳しく管理されたプロジェクト、高い FDV、価格の吊り上げ、その後のトークンアンロックを使った段階的な利益確定、というおなじみの枠組みで Hyperliquid を見ており、Hyperliquid が実際の利用を通じてプラットフォームを構築し得る可能性を見落としていた。その結果、私は早すぎる売却をしてしまった。

振り返ってみると、

Hyperliquid のプロダクト設計は、「order book」（より正確には CLOB、central limit order book）、「高頻度」、「大口サイズ」、「高レバレッジ」というキーワードを中心に組み立てられている。

そして最も重要なのは、Hyperliquid はこれらのキーワードを兼ね備えた唯一の DEX であるという点で、言ってみれば唯一の選択肢だ。

最も基本的なコンセンサス層から見ても、Hyperliquid は「高頻度」取引のニーズに合わせるために多くの改善と最適化を行っている。よりフォールトトレラントで、より非同期的な設計を採用しており、たとえば連続的な逐次処理では、現在のブロックハッシュが実行されるのを待たずにユーザー取引を継続的に順序付ける。また、1ブロック最終性も提供しており、各取引、注文キャンセル、清算を単一ブロック内で完了できる。

もちろん、「高頻度」のニーズに対応し、リアルタイム取引と清算を提供するための設計は他にも多い。リアルタイム性能、あるいはトランザクション遅延は、取引がリアルタイムで確認できるか、ロールバックリスクがあるか、実際の約定価格やスリッページ、MEV の機会、そしてより重要なこととして、極端にボラティリティの高い市場における清算価格や証拠金補填に影響する。

通常、ブロックチェーンは固定間隔でブロックを生成する。たとえば、Solana のブロック時間は約 400 ms、Ethereum メインネットは 12 秒である一方、Ethereum L2 では最終確定にはトランザクション結果をメインネットに投稿し、検証してもらう必要がある。おそらくこれが、Solana エコシステムのプロジェクトである Drift や、Starknet エコシステムの Paradex が、より名の通った機関投資家向けのバックグラウンドを持ちながらも、実際には Hyperliquid に後れを取っている理由だろう。

流動性については、Hyperliquid は HLP を使ってプロトコルのベース流動性層を構築し、「大口サイズ」の取引ニーズを満たしている。また、市場から資金を集めるために $HYPE も使っている。チームの売却益確保に加えて、HYPE には保険としての価値もある。もし Hyperliquid が問題に直面した場合、$HYPE を売却して損失を補填できるからだ。要するに、これはプロトコルの流動性と保険を両立させる 2 トークンモデルである。

さらに、@IOSGVC が述べたように、新たな LaunchPad としての HIP の価値は過小評価されている。HLP + HIP により、Hyperliquid はネイティブなブロックチェーンのベース流動性層になり得る。

以下が本題である、

HyperBFT Consensus Layer: 高頻度、高頻度、やっぱり高頻度！

------------------------

Hyperliquid の技術アーキテクチャの核心原理は、「高頻度取引」にサービスすることだ。4 つの単語「高頻度取引」を頭に焼き付けてほしい。後で複雑な技術用語に出会っても、まず「高頻度」という原則から考えれば、はるかに理解しやすくなる。

Hyperliquid の基盤コンセンサスである HyperBFT は、HotStuff と LibraBFT プロトコルをベースに改良されたもので、非同期 Byzantine fault-tolerant BFT を実装している。

「同期的」は、コンセンサスの中で固定の時間枠に依存して意思決定するようなものだ。厳密なブロック間隔があり、固定サイクルで待たなければならない Bitcoin は典型例である。「非同期的」は固定間隔を待つ必要がなく、実際のネットワーク条件に応じてブロック生成を調整できることを意味する。

「同期的」システムは TPS がより安定しており、プロトコル設計もよりシンプルにできる。シンプルさは時に安全性でもある。「非同期的」システムはより高速だが、ノードに問題が発生すると、そのノードのネットワーク状況が改善するまでブロック生成が停止する可能性がある。前サイクルの NFT ミント急増時に Solana が経験したダウンタイムや停止は、このためだった。

要するに、「同期的」は最悪のネットワーク条件下での可用性を確保し、下限を守る。「非同期的」は通常のネットワーク条件下でより高い性能を追求し、上限を目指す。

そして「フォールトトレランス」は、一部のノードが故障したり悪意ある振る舞いをしてもシステムが正常に動作し続けることを保証し、より厳しい条件下でも同じ基準を維持する。実際には、2/3+1 のノードが正常であれば十分である。

以上を踏まえると、Hyperliquid はトランザクションの順序付けとブロック生成において次のことを実現している。

最適化された非同期設計

コンセンサスアルゴリズム自体に同期的な時間スケールは組み込まれておらず、バリデータはあらかじめ設定された間隔を待つ必要がなく、最新状態に対して即座に投票できる。これは「楽観的フィードバック」である。

連続的な逐次処理

Hyperliquid は、現在のブロックハッシュが実行されるのを待たずに、取引の順序付けを継続できる。これは大きな技術的ブレークスルーであり、現在のブロックの処理が終わる前に次の取引バッチの処理を開始できる。

ここで比較が必要である、

従来の BFT フロー: ブロック N を提案 → コンセンサスを待つ → 実行完了 → ブロック N+1 が開始 |--------fixed time window--------|

HyperBFT フロー: ブロック N を提案 → 直ちにブロック N+1 の順序付けを開始 → 複数ブロックを並列処理 |---optimistic response, no fixed waiting---|

ここから、HyperBFT は実際には 3 つ目の性質、そしてもちろん要件を導き出します。それは

Validator communication standard

現在の validator は、ネットワーク内 validator の少なくとも 1/3（stake による重み付け）と 200 ms 以下の往復通信遅延を維持しなければなりません。これらの厳格な基準を満たせない validator は罰則の対象となります。

この 1/3 通信保証は、実際にはネットワーク速度の保証であり、ネットワークが fork しないことを確保しつつ、コンセンサスメカニズム自体はなお validator の 2/3 超の署名を必要とします。

言い換えれば、Hyperliquid のコンセンサスメカニズムでは、ネットワーク性能とコンセンサスの基本保証は、ある程度まで互いに「分離」されています。

これらの特性を組み合わせることで、200,000+ TPS、Ethereum の लगभग 100 倍、そして 0.2-second のトランザクション確認時間が実現されます。もちろん、実際の体験はウォレットやネットワーク速度の影響を受けますが、トランザクションは確認済みであり、それで十分です。

さらに、もう 1 つ極めて重要なものがあります。それは single-block finality です。

Single-block finality

つまり、すべてのトランザクション、注文キャンセル、そして清算は 1 つのブロック内で確定し、最終確認を受けます。トランザクションがブロックに含まれた瞬間に即座に final となり、トランザクションの安全性を確保するために複数ブロックの確認を待つ必要はありません。

Single-block finality は、特に bot や高頻度アルゴリズム取引にとって重要です。Finality とは、トランザクションの確認、不変性、そして並べ替えが起きないことを意味します。そうでなければ、MEV リスクが生じます。ボラティリティの高い局面では、清算が発生するかどうかを左右し得ます。さらに、裁定機会は確認遅延を考慮せずに正確に計算できます。

いくつかの人気 DEX と比べると、dYdX は Cosmos ベースで mainnet のコンセンサスを経る必要があり、Gmx は Arbitrum と Avalanche ベースです。Arb は L2 なので、finality には Ethereum mainnet の確認が必要であり、Avax の finality は約 1-2 秒です。Hyperliquid の「高頻度」優位性を実感できるでしょう。

HyperCore execution layer: The perpetual futures machine

--------------------

HyperCore は HyperBFT コンセンサスメカニズム上に構築された execution layer であり、注文板、注文マッチング、証拠金システム、清算メカニズム、native staking など、具体的な問題を担当しています。

HyperEVM とそのエコシステムもありますが、この記事は引き続き Hyperliquid 自体に焦点を当てるため、その部分は今のところ扱いません。

HLP: An attempt to balance large-scale trading and risk

----------------

HLP (Hyperliquidity Provider) は、マーケットメイクと清算のための Hyperliquid の準備基金です。HLP の核心は、大規模取引を処理することにあります。

HLP を理解する前に、まず Gmx の GLP と比較するとよいでしょう。

GLP は、パーペチュアル先物 DEX Gmx が導入した革新的な流動性提供メカニズムです。Gmx v1 では、GLP はプール型の流動性プールであり、ユーザーは GLP を購入してからプールにステークし、利回りを得ながらプロトコルに流動性を提供できました。

GLP の実際の価値は、BTC、ETH、UNI などのボラティリティの高い資産、および USDT、USDC、DAI などのステーブルコイン資産によって裏付けられており、その価格は変動します。

重要なのは、GLP が受動的なマーケットメイクであり、トレーダーのカウンターパーティとして機能することです。トレーダーがポジションを建てると、GLP は自動的に反対側のポジションの保有者になります。

したがって、GLP の収益性を支える前提、ひいては Gmx の存在を支える前提は、トレーダーは常に損失を出す、ということです。トレーダーの損失は、GLP をステークする人々の収益になります。

HLP's active market-making strategy

これに対して、HLP は能動的なマーケットメイク戦略であり、中心機能はマーケットメイク（取引の買値・売値を提示し、カウンターパーティを提供し、スプレッドと手数料を得ること）と清算（ユーザーの清算済みポジションを引き継ぐこと）です。HLP はユーザーのカウンターパーティとなって流動性を提供しますが、単なるカウンターパーティではありません。

HLP は 3 つの sub-vault で構成されています。2 つはマーケットメイクに特化した vault（Vault A と Vault B）で、1 つは清算専用の vault（Liquidator vault）です（基本的には JELLY 事件後に放棄されました）。

Vault A と Vault B は主なマーケットメイクエンジンとして機能し、継続的に買い注文と売り注文を出します。プラットフォーム上の大半の注文に対する主要なカウンターパーティとして、トレーダーがポジションを建てると、Hyperliquid はその注文のマッチングを優先します。HLP が注文板上で反対注文を即座に見つけられない場合は、カウンターパーティとして機能し、十分な流動性を確保し、スリッページを抑えます。

HLP は清算にも自動的に参加し、ユーザーが強制清算されたポジションを引き継いでから市場でそれを解消し、スプレッドを獲得します。

しかし、2025 年 3 月の ETH whale 事件と $JELLY 事件では、Hyperliquid はいくつかのシステム的脆弱性を露呈しました。

2025 年 3 月 12 日、ある whale が最大 50x のレバレッジで ETH のロングポジションを建て、初期証拠金は 4.3 million USDC、総額は $340 million でした。

問題は、そのポジションがどのようにクローズされたかでした。whale は取引でクローズすることを選ばず、その場合は非常に大きなスリッページが発生するからです。代わりに、未実現利益を引き出した後、残りのポジションを清算されるようにしました。流動性提供者として、HLP は whale のカウンターパーティとなりました。whale が清算された後、HLP はすでに損失を出しているロングポジションを引き継ぎました。その後の ETH 価格の変動により、リスクにさらされ、損失を被りました。

JELLY 事件は、「short squeeze」とオラクル操作を組み合わせた典型例であり、流動性の低い資産を直接標的にしたものでした。攻撃者は JELLY の低い流動性を悪用して価格を押し上げ、Hyperliquid 上でショートの清算を引き起こし、HLP に極めて不利な価格で清算させました。その後、価格急騰から利益を得ました。

これら2つの事件の後、HyperliquidはCEXsで一般的に見られるリスク管理策を採用せざるを得なくなった。具体的には、清算ボールトの配分上限を設定すること（単一の清算イベントでHLPが負担できる最大損失を制限する）、ADL (Auto-Deleveraging) メカニズムの導入、そして建玉の動的上限の設定であり、特に時価総額の低いトークンについては、同様の操作的な出来事が再発するのを防ぐため、より厳格な管理が行われている。

これは必要な妥協だ。つまり、リスク管理フレームワークとのバランスを取るために、「大規模」と「高レバレッジ」の特徴の一部を手放すことだ。

そしてこの2つの事件から見ると、Hyperliquidは取引のカウンターパーティーではあるものの、ヘッジはしていないようだ。図が示すように、HLPの中核的役割は注文板の空白を埋め、ユーザーの注文が即座に約定できるようにすることだ。しかし、HLP自身のポジションエクスポージャーは、裸のままである可能性が高い。

幸い、ポジションサイズは大きくない。これは大半の注文がマッチングを通じて吸収できることを示しており、またHyperliquidの高頻度戦略が機能していることも示している。つまり、高頻度トレーダーが十分に存在し、重要なのは、彼らが互いのカウンターパーティーとしても十分に機能しているため、HLPのエクスポージャーが減っていることだ。言い換えれば、ループは閉じたと言える。

見たか？この設計は、すべての要素が不可欠で、極めて密接に結びついているだろう？

さらに、HLPの清算価格は現在価格からまだかなり離れている。一方で、相殺するポジションのおかげでファンディングレートを得ており、HLPの収益源の一つになっている。

Hyperliquidの次はどうなるのか？ HIP-1 トークン上場メカニズム？

----------------------------------

HIP-1はDutch auction型のトークン上場メカニズムで、透明性の高いプロセスとアルゴリズムによる価格設定を備えている。Dutch auctionは「下降価格オークション」とも呼ばれ、より高い開始価格から始まり、その後、価格は時間とともに直線的に（または事前に設定されたルールに従って）下がっていく。

HIP-1は通常31時間続く。誰も入札しなければ、オークションの開始価格は500 HYPE、または10,000 USDCのような、あらかじめ定められたより低い水準にリセットされる。前回のオークションが成功していた場合、今回の開始価格は通常、前回のオークションで成立した価格の2倍になる。最初のオークションは$HYPEで決済されていたが、最新情報によると、現在は主に$USDCで決済されている。

現在の問題は、市場がHIP-1を通じて発行されたトークンにほとんど関心を示しておらず、取引量もほぼないことだ。Hyperliquidには新しいトークンへの需要を刺激する起爆剤が必要である。

もしそれが本当にできれば、それはオンチェーン版Binance Alphaになるだろう。

---

Original source: Godot’s X post