見出し画像

HyperEVMの設計と、HyperliquidL1との連携における制約、ユースケース検討【AIレポート】

まめだい

まめだいメモ

HyperEVMはHyperliquidのL1の状態を読み込んで注文ができますが、Atomicな処理ができません。つまりL1で成功しようと失敗しようとEVM側はtx successとなってしまいます。これがどのような制約をもたらすのかを考察してもらいました。


1. HyperEVMの技術仕様


アーキテクチャ: HyperEVMはHyperliquid独自のLayer1（L1）ブロックチェーン内に統合されたEVM（Ethereum Virtual Machine）互換のブロックチェーンです。Hyperliquidはデュアルチェーン構造を採用しており、一つは高性能な注文板（オーダーブック）専用のL1チェーン、もう一つがEVMスマートコントラクト用のチェーン（HyperEVM）です。両チェーンは共通のHyperBFTコンセンサス（LibraBFT由来のBFTアルゴリズム）によって同一の状態を共有しますが、実行環境は分離されています。この設計により、Hyperliquidノードはソフトウェアレベルで2つのブロックチェーンを並行稼働させ、各ノードが両チェーンのデータを保持しトランザクションを個別に処理します。L1チェーン（Hyperliquid L1）は許可制でHyperliquid独自のスポット及びパーペチュアル（無期限先物）注文板を稼働させ、高頻度取引に最適化された高速ブロック生成を行います。一方、EVMチェーン（HyperEVM）はパーミッションレスで誰でもスマートコントラクトをデプロイ可能な汎用ブロックチェーンです。L1のブロックタイムは非常に短く（高速最適化）設計されており、EVM側はやや遅いブロックタイムで動作しますが、両者のブロックは順序立てて実行されます。つまり、各EVMブロックは直前のL1ブロックの状態を読み取り、EVM内の処理結果に基づくアクションを次のL1ブロックに送信する、というシーケンシャルな実行モデルになっています。この一貫した順序により、異なるチェーン間でも状態の予測可能性と整合性を保っています。なお、テストネットではHyperEVMにデュアルブロック構造（高速ブロックと大容量ブロック）が導入されており、小さなトランザクションは約2秒間隔・ガスリミット100万の「高速ブロック」で処理し、複雑なトランザクションは約1分間隔・ガスリミット3000万の「スローブロック」で処理する仕組みも試験されています。これにより速度と処理容量のトレードオフを解消しようというアプローチが取られています。

スマートコントラクト実行環境: HyperEVMはEthereumと同様のEVM実行環境を提供し、Solidityなどで記述したコントラクトをデプロイできます。Ethereumの一般的な開発ツールやJSON-RPCインターフェースにも対応しており、MetamaskやHardhat等を用いた開発が可能です。実際、テストネットではChain ID=998のHyperEVMが公開され、Ethereum互換のJSON-RPCエンドポイントが提供されています。EVM上でのガス手数料支払いにはHyperliquidのネイティブトークンであるHYPEが使われます（EVM起動によりHYPEがガス用途として必要になる）。
HyperEVMの特徴は、Hyperliquid L1との緊密な連携を前提に拡張されている点です。EVM上のスマートコントラクトからL1の状態を直接読み取ったり、L1上の機能を呼び出すことができるように特別なインターフェースが用意されています。具体的には、プリコンパイル（Precompile）と呼ばれる特別なコントラクト群やシステムコールが実装されており、これを介してHyperliquidの注文板データやユーザー残高などL1側の情報にアクセスできます。プリコンパイルは特殊なアドレスに配置された組み込み機能で、Solidityからはコントラクト呼び出しのように扱えます。例えば、あるプリコンパイルを使えば、EVM実行中に特定ユーザーのパーペチュアル建玉やスポット残高を照会するといったことが可能で、これによってリアルタイムの市場データをスマートコントラクト内で直接利用できます（従来はオラクル経由で取り込む必要があったデータを、HyperEVMではネイティブに取得可能）。また逆に、EVM上のコントラクトからHyperliquid L1に対してアクションを送るには、イベントの発行を用います。HyperEVMには0x333...3333という特別なシステムコントラクトアドレスが予約されており、ここに対して特定の形式のイベントをEmit（発行）することで、例えば「注文を出す」「注文をキャンセルする」「清算を実行する」等のL1アクションをトリガーできます。このイベントはHyperBFTコンセンサスを介して次のL1ブロックに取り込まれ、対応するネイティブ機能が実行される仕組みです。要するに、HyperEVM上では**「L1を呼び出せるEVM」として、読み取り専用の呼び出しはプリコンパイル経由で即座に実現し、書き込みを伴う操作（注文発行など）はイベントキュー経由で次ブロック実行という形でシームレスにL1と結合されています。さらに、HyperEVM上で発行されたERC-20トークンとL1上のネイティブ資産は1:1で対応付けられており、同じ価値を持つとされています。例えばEVM上で発行されたUSDC（ERC-20）はL1のネイティブUSDC残高と連動し、どちらからでも利用可能です。このような資産の統一管理**により、EVM上のDeFiトークンもHyperliquidの高速取引市場で直接売買できる利点があります。

互換性: HyperEVMはEthereum互換性をフルサポートしており、SolidityやVyperといったスマートコントラクト言語、MetaMask等のウォレット、Truffle/Hardhatなどのツールチェーンがそのまま利用可能です。開発者にとっては、既存のEthereum上のDAppを移植したり、新規に構築する際も馴染みのある開発体験が得られます。EVMそのものの仕様は基本的にEthereum準拠ですが、上述の通りHyperliquid固有のプリコンパイルやシステムイベントといった拡張機能が追加されています。また、HyperliquidではHYPEトークンを中心に独自のトークン標準（HIP-1, HIP-2といった標準）も提案されており、これらはEthereumのERC規格と互換性を持たせつつHyperliquidの特性に合わせた設計になっています（例えばステーキング機能や高速決済を考慮）。コンセンサスメカニズムに関してはHyperBFTを採用しており、これはFacebook（現Meta）のLibraプロジェクト由来のHotStuffベースBFTを改良したものです。HyperBFTは1ブロックあたり1秒未満で確定（ファイナリティ）し、0.2秒程度の低レイテンシで処理できる高性能コンセンサスで、秒間数十万件ものトランザクション処理を可能にしています。HyperEVMもこの高速コンセンサスのもとで動くため、高スループットかつ高い信頼性を享受できます。

セキュリティと設計上の特徴: Hyperliquidの設計は、パフォーマンス最優先だが安全性とのバランスを取る点に特徴があります。L1チェーンはパーミッション制（許可されたバリデータのみがブロック生成）で運用されており、わずかな検証者グループ（Hyperliquid開発チームおよびコミュニティのステーキングによる選出など）によって管理されています。これは完全分散型とは言えないものの、取引所のコア機能である注文板の整合性と高速性を担保するための設計上のトレードオフです。一方でEVMチェーンは誰でも参加可能なパーミッションレス環境として開放されているため、コア部分（取引所部分）のセキュリティはある程度統制し、拡張部分（スマートコントラクト部分）はオープンにするという住み分けになっています。両チェーンはHyperBFTで結合されデータの一貫性が保たれるため、L1とEVM間で状態の不整合が生じにくいように設計されています。また、EVM側からL1側への操作はすべてイベントドリブンかつ非同期で行われ、EVMトランザクション自体のアトミシティ（不可分性）は維持しつつ、L1側への影響は後続のブロックで適用されるよう制御されています。この「部分的なアトミック性 (Partial Atomicity)」はHyperliquid固有のセキュリティ設計上のポイントであり、スマートコントラクトの暴走が直接L1を巻き込むことを避けつつ（例えばEVM上で意図しないイベントが発行されてもL1側で検証・制御できる）、同時に取引の最中にシステム不整合が起きないようになっています。さらに、HyperEVMではプリコンパイルやシステムコントラクトを通じてL1との橋渡しをしていますが、これらは通常のSolidityコントラクトでは記述困難な高度な処理（署名検証や特殊アルゴリズム）をネイティブコードで安全に提供する目的もあります。例えばEthereum標準でもecRecover（署名復元）がプリコンパイルとして提供されていますが、Hyperliquidではそれに加えL1データ読み出し等の独自機能をプリコンパイルで実装しています。これにより、開発者はセキュアにL1リソースへアクセスでき、重要な処理はHyperliquidの低レベル実装に任せることで安全性と効率を向上させています。なお、Hyperliquidのコア実装は現時点で完全にはオープンソース化されておらず、一部のスマートコントラクト（ブリッジなど）のみ公開されています。そのため詳細な実装検証には限界があるものの、コミュニティによるテストやサードパーティ監査が進められています。全体として、HyperEVMはEthereum互換の汎用性と、Hyperliquid L1の高速取引機能を組み合わせたハイブリッド設計となっており、従来のL1チェーンとは一線を画すコンセプトを持っています。

2. Hyperliquid L1との連携における制約（部分的なアトミシティの問題）


HyperEVMとL1の連携で最も注意すべきは、EVM上のトランザクションとL1上のアクションが原子的（アトミック）に一体化していない点です。EVMスマートコントラクトからL1の機能をコール（実行要求）すること自体は可能ですが、その呼び出し結果を同一トランザクション内で確認し、条件次第でロールバック（失敗による取り消し）するといったことはできません。具体的に言うと、EVM上であるコントラクトがL1注文板に注文を出すイベントを発行したとします。このEVMトランザクション自体はHyperEVM内で即座に実行・確定しますが、その注文イベントを受け取ったL1側で実際に注文を板に載せる処理は次のL1ブロックで非同期的に行われます。その際、もし何らかの理由で注文が失敗（例えば残高不足や不正な注文値で拒否）したとしても、元のEVMトランザクションは巻き戻されずそのまま成功したものとして残るのです。つまり、EVMから見れば「L1に対する操作要求を投げた」事実だけが残り、その要求が実際に成功したか失敗したかは即座には分からないということになります。この挙動はHyperliquid設計上の「部分的アトミック性 (Partial Atomicity)」と呼ばれるもので、EVMとL1でトランザクションの不可分性が部分的にしか保証されていないことを意味します。

制約のポイントを整理すると以下の通りです:

  • 非同期実行: EVMコントラクトがL1の状態を読み取ることはできますが（これは前のL1ブロックまでの確定情報）、L1への書き込み（アクション実行）はイベントを介した次ブロック処理になるため、その結果は現在のEVMトランザクション中には反映されません。一種の「read then write later」のサイクルであり、リアルタイムに両者を同期させた処理はできません。

  • アトミックでない処理: EVM側ではトランザクションがアトミックに完結する一方、L1側の処理は独立しているためオールオアナッシング（全て成功か全て失敗か）の保証が跨るチェーン間では成立しません。例えばEthereumであれば、あるコントラクトから他のプロトコルを呼び出し一連の処理を行い、途中で失敗すれば全て巻き戻す、というアトミックなロールバックが可能ですが、HyperliquidではEVM→L1の跨がる処理でこれができないのです。

  • エラー伝播の不可: EVMからL1にイベントを送った後、そのイベント処理がL1側で失敗しても、そのエラーはEVMトランザクションに伝播しません。したがって、コントラクト開発者は「L1側で失敗したらEVM側も取り消す」といったロジックを組み込むことができず、事後的に対処するしかありません。この「呼び出し後に結果を確認して失敗させることができない」という制約が質問文で指摘されているポイントで、一度EVM上で成功したトランザクションは、後になってL1側の結果を見て取り消すことは不可能です。

  • 時間差による状態遷移: EVMが認識できるL1の状態は常に「ひとつ前のブロック時点の状態」までです。最新のL1状態は次のブロック生成まで確定しないため、EVMトランザクション内では若干古い情報に基づいて判断することになります。また、EVMから出した操作の効果は次のブロックまで反映されないため、一時的にL1とEVMでデータが噛み合わない瞬間も生じえます（例えば資産移動の直後、その反映待ちの間など）。Hyperliquidでは、EVMコントラクトからL1のシステムアドレス（0x222...2222）にトークンを転送することでL1残高にデポジットできますが、この残高更新は次のブロックでなされるため、ごく短い間「どちらのチェーンから見ても残高が減っている」ように見えるプリクレジット期間が生じると報告されています。このようにクロスチェーン間で状態反映にラグがある点も、開発上注意すべき制約です。

  • 呼び出し主体の違い: EVMコントラクトがL1アクションを実行すると、L1上ではそのコントラクトアドレスが直接行為者となります。つまり、元のユーザーではなくコントラクトが注文や清算を行ったことになるため、後でポジション整理や資金回収を行う際にはコントラクト自体にそうした権限やロジックを用意しておく必要があります。これも設計上考慮すべき点で、たとえば「コントラクトが開いたポジションを閉じる手段を用意する」「ユーザーがコントラクト経由で資産を引き出せるようにする」等の仕組みが求められます。

以上の制約により、HyperEVMとL1の間では完全なアトミック処理（不可分で同時に成功/失敗するトランザクション）が実現できません。これはシステム設計上意図的なものです。Hyperliquidは取引性能を確保するためコア部分を分離しつつ連携させる構造を取った結果、従来の単一チェーン上で享受できた「スマートコントラクト間の同期的なやりとりによる安全な複合取引」が一部制限されます。プロトコル設計者はこの部分的アトミック性を念頭に置き、「もしL1側が失敗したらどうリカバーするか」をあらかじめ決めた上でコントラクトロジックやユーザー体験を設計する必要があります。例えば、後述するユースケースのように注文発行や清算をスマートコントラクトから行う場合、失敗時に備えてタイムアウトや代替処理を用意する、ユーザーにリスクを通知する、といった工夫が求められます。

3. 考えられるユースケース（可能な応用例）


HyperEVMによってEthereum互換のスマートコントラクト機能とHyperliquidの高速注文板が統合されたことで、新旧様々なDeFiおよびトレーディングのユースケースが考えられます。

  • 一般的なDeFi機能:
    レンディング（貸借プロトコル）: AaveやCompoundのような貸借プロトコルをHyperEVM上に実装できます。ユーザーは資産を預けて利息を稼ぎ、他のユーザーはそれを借り入れることができます。Hyperliquidの特徴を活かす点として、担保評価や清算にL1のリアルタイム価格データを利用できることが挙げられます。プリコンパイルを通じてHyperliquidのスポット価格や指数価格をオンチェーンで取得できるため、例えばETH担保にUSDCを借りる場合も外部オラクルを介さずHyperliquid取引所の価格を参照して担保価値を判断できます。これにより清算ラインの精緻化や価格乖離リスクの低減が期待できます。また、借りた資産や預けた資産をそのままHyperliquidの注文板で取引できるため、ユーザーは貸借ポジションをヘッジしたり、預けた資産をすぐに売却するといった行動もワンストップで可能になります。さらにHYPEトークンを絡めれば、HYPEを担保に入れて別の資産を借り入れる、あるいは逆にHYPEを借りて運用するといった形でHyperliquidエコシステム内の資本効率を高めることもできます。特にHYPEはガス代支払いにも使われるため、貸借市場での流動性が高まればエコシステム全体の安定性向上にもつながるでしょう。

    1. AMM（自動マーケットメイカー）型DEX: UniswapのようなAMM方式の分散型取引所も実装可能です。Hyperliquid L1自体はオーダーブック型DEXですが、HyperEVM上にプール型のAMMを構築すれば、流動性提供者（LP）がプールに資産を預けて市場メイキングし、スワップ手数料を稼ぐことができます。特に、まだL1のオーダーブックに上場していないトークンについて、AMMがキャッチアップする形で取引市場を提供することも考えられます。また、AMMの価格曲線とHyperliquidのオーダーブックが並存することで裁定機会が生まれ、市場の効率性が向上する可能性もあります。例えば、あるトークンがAMMでは割安だがオーダーブック上では高値で買われている場合、アービトラージャーがAMMで買ってオーダーブックで売ることで価格差が解消されるといった現象が期待できます。さらにHyperliquidのオーダーブック情報は常に取得できるため、AMMのスマートコントラクトがバックエンドでプライシングの参考にオーダーブック最良気配を参照するといった高度な設計も可能です（ただし参照のみでAMM内で自動調整する場合、フロントランニング等に注意が必要です）。基本的にはEthereum上の既存AMMと同様の機能を持ちますが、Hyperliquid上で動かすことで低手数料・高速決済のメリットを受けられ、さらに取引成立後すぐにHyperliquidの他市場でヘッジするといった高度なLP戦略も実装できます。

    2. ステーブルコイン発行（CDP方式）: MakerDAOのように、担保をロックしてステーブルコインを発行するプロトコルも構築可能です。ユーザーはETHやBTC等をHyperEVM上のコントラクトに担保として預け、例えばUSDにペッグしたステーブルコインをミント（発行）できます。こうしたCDP（Collateralized Debt Position）型のステーブルコインは、Hyperliquidのインフラを活用することでより堅牢になります。担保価値の算定にL1のマーケット価格を使えるのはもちろん、清算時にはHyperliquidのオーダーブックに担保資産を売却して債務返済に充てることもできます。たとえばETH担保が清算トリガーにかかった場合、スマートコントラクトが自動的にETHをHyperliquidのスポット市場で売却し、得たUSDCで借入債務（ステーブルコイン）を回収するといったフローが考えられます。通常、こうした清算売却にはDEXでのスワップやオークションが用いられますが、Hyperliquidでは厚い板（深い流動性）に直接流すことで迅速かつ有利な価格で清算できる可能性があります。ただし前述の通り完全な原子性はないため、清算フローは段階的に設計する必要があります（詳細は後述の制約セクションで解説）。いずれにせよ、オンチェーンで独自のステーブルコイン発行や銀行機能を実現しつつ、それをHyperliquidの取引所と連携させることで、よりダイナミックかつ効率的なマネーマーケットが構築できるでしょう。

  • 無期限先物取引所の機能を活用したユースケース:
    Hyperliquid L1は既に高機能な無期限先物（パーペチュアル）DEXとして、中央集権型取引所（CEX）並みの多彩な注文タイプやリスク管理を提供しています。例えばクロスマージンによるポジション管理、最大50倍のレバレッジ、テイクプロフィット・ストップロス注文などがサポートされています。スマートコントラクトはこれらL1の機能と組み合わせることで、従来にはない取引ロジックやサービスを実現できます。

    1. クロスマージンの活用: 複数のパーペチュアル銘柄間で証拠金を共有するクロスマージン機能は、通常個人ユーザーのアカウント単位で提供されています。HyperEVMコントラクトは独立したアカウントとしてL1に認識されるため、一つのコントラクトで複数市場のポジションを持てば自動的にクロスマージンで管理されます。これを利用して投資ファンドや共同運用ボルトのようなスマートコントラクトを作ることが可能です。ユーザーはそのコントラクトに資金を預け、コントラクトが預かった資金を元手にHyperliquidの様々な無期限先物市場で取引を行います。例えば、あるコントラクトがBTC-PERPとETH-PERPでそれぞれポジションを取りヘッジ戦略を実行する場合、片方の利益がもう片方の損失を埋める形で証拠金が自動調整（クロスマージン効果）され、全体として清算リスクを下げられます。利益や損失はコントラクト内で計算され、出資者は持分に応じて配分を受けます。このようなオンチェーンファンドやコピー取引ボルトは既にHyperliquidが提供を予定している「バルト（Vault）」機能とも合致します。Hyperliquidのボルトでは、誰でも資金を預けてプロトレーダーの戦略に乗ることができ、ボルトの運用者（トレーダー）は成功報酬の一部を得る仕組みが紹介されています。スマートコントラクトによるクロスマージン活用は、ユーザーが直接取引するだけでなく集合知や高度な戦略をオンチェーンで共有する道を開き、個々のトレーダーでは難しい複雑なポートフォリオ運用を実現します。

    2. オンチェーン清算とセキュリティ監視: Hyperliquid L1では清算エンジンがオンチェーンで動作していると推測されます（詳細な実装は非公開ですが、HyperBFT下で注文処理と同時に清算判定が行われている可能性があります）。スマートコントラクト開発者にとっては、この清算機能を補完・強化するユースケースが考えられます。例えば、清算執行ボットをスマートコントラクトとして実装し、誰でも参加できる形にすることが可能です。具体的には、あるコントラクトが定期的に（もしくはトリガーイベントに応じて）L1上の全ユーザーポジションをプリコンパイル経由でチェックし、清算基準を満たすポジションがあればそのアドレスに対して清算アクションのイベントを発行する、というものです。これにより、本来Validatorや特定参加者だけが行っている清算作業をパーミッションレスに担えるようになります。清算執行に成功した際に報酬を支払う仕組み（例: 清算ペナルティの一部をインセンティブとして付与）を組み込めば、チェーン上で清算人ネットワークを構築することもできます。もっとも、Hyperliquidでは清算関連の処理はかなり最適化・自動化されている可能性が高く、スマートコントラクトで介入する余地は限定的かもしれません。しかし類似のアイディアとして、保険プールや安全モジュールを構築し、急激な暴落で清算が追いつかない場合に備えてオンチェーンで補填する、といったユースケースも考えられます。これはDeFi保険や清算補助金庫のような仕組みで、Hyperliquidの価格フィードと連動して自動発動するような契約を作ることができます。

    3. 流動性プールによる板へのマーケットメイク: オーダーブック型取引所ではマーケットメイカーが板に注文を並べることで流動性を提供します。Hyperliquidでは誰でもAPIやEVMイベントを通じて注文を出せますが、個人が常時板を監視し注文を更新するのは困難です。そこで、スマートコントラクト制御の自動マーケットメイカー（注文板版）を構築することが有用です。ユーザーはそのコントラクトに資金を提供し、コントラクトはプログラムされたアルゴリズムに従ってHyperliquidの板に指値注文を継続的に出します。例えば現在価格を中心に、一定間隔で買い注文と売り注文を配置し、約定したら即座に次の注文を差し込む、といったレンジマーケットメイク戦略をスマートコントラクトで実装できます。これにより、LPは取引手数料やスプレッド収益を得ることができます。従来のAMMプールと異なり価格曲線に従うのではなく、柔軟なアルゴリズム（階段注文、グリッドトレーディング等）を組める点が利点です。Hyperliquidチームが提唱するボルト戦略の中にも、高頻度のマーケットメイクや超高レバレッジアカウントの効率的清算といった言及があり、まさにスマートコントラクトによる自動取引戦略の実装が期待されています。これらは一般ユーザーが間接的にマーケットメイクに参加し利益を得る手段となり、市場の厚みにも貢献します。

  • Hyperliquid L1との相互運用で実現する独自ユースケース:
    HyperEVMとL1の密接な連携によって、新たに生まれる複合型のDeFi/取引プロダクトも考えられます。

    1. スポット＆パーペチュアル連携の新金融商品: スマートコントラクトでスポット市場とパーペチュアル市場の両方にアクセスできる強みを活かし、例えばベーシストレード（現物買い＋先物売りによる無リスク金利獲得）をオンチェーンで実行・トークン化することが可能です。コントラクトがUSDCを借りてBTC現物を購入し、同時にBTC無期限先物を売ることで資金調達コストと先物資金率の差を狙う、といった戦略を組み、それを表すトークンを発行して流通させることもできます。類似のコンセプトとして、イールドストラテジーやマーケットニュートラル戦略のVaultトークンを発行し、ユーザーがそれを購入するだけで高度な取引戦略に乗れるようなサービスも考えられます。Hyperliquidのオンチェーン流動性と低遅延なら、こうした戦略のリバランスやポジション管理も高頻度で行え、CeFi顔負けの複雑な商品を非託管環境で提供できるでしょう。

    2. ヘッジングと合成資産: 外部のDeFiプロジェクトがHyperliquidをヘッジ目的に利用するケースも出てきています。例としてEthena Labsが挙げられます。EthenaはオンチェーンでUSDと価値連動する資産（ステーブル資産）を発行するプロジェクトですが、その裏付けとしてETHの価格変動リスクをヘッジする必要があります。従来は中央取引所で先物を売る等していましたが、Hyperliquid統合後は自前のスマートコントラクトからHyperliquidの無期限先物を部分的に利用してヘッジすることで、システムのレジリエンス（耐障害性）向上とカウンターパーティリスク低減が期待できると報告されています。このように、合成資産の裏付けにHyperliquidのパーペチュアルを活用することで、完全オンチェーンで安定資産を作ることができます。さらに発展させれば、コモディティや株式指数などの価格に連動する合成資産を発行し、そのヘッジをHyperliquid上で行うことで、従来オラクル頼みだった合成資産の仕組みをよりリアルタイムかつ安全に構築することも可能です（Hyperliquid上に例えば「金先物」「原油先物」に相当する市場を開設すれば、オンチェーンでコモディティ価格連動トークンを作成可能）。

    3. 高度な条件付注文や自動執行: Hyperliquid自体も指値、逆指値、TWAP、スケール注文等様々な注文タイプを提供していますが、スマートコントラクトを用いればさらに柔軟な条件でトレードを自動化できます。例えばトリガー条件を複数組み合わせた注文執行（ある通貨がある価格に達し、かつ別の市場が特定の状況なら注文実行）や、ポートフォリオ全体のバランスに応じた動的注文量調整など、ユーザーごとにカスタムロジックを組むこともできます。さらに、オンチェーンでオーダーブックに介入できる特性を利用し、他のチェーンや市場との分散型アービトラージBotをコントラクト化することも考えられます（例: Ethereum上のDEXで安く買い、Hyperliquidで高く売る）。この場合、取引の一部はHyperliquid外になるためブリッジ経由の資産移動なども絡み難易度は上がりますが、少なくともHyperliquid内に閉じた形であれば高速で完結するでしょう。いずれにせよ、「取引所の板」に直接プログラム的アクセスができる環境は非常にユニークで、これまでオフチェーンで行われていた高頻度取引戦略やアルゴリズムトレーディングの一部をオンチェーンに乗せることが可能になります。これは単なるDeFiの枠を超え、トレーディング領域でのイノベーションを促進するでしょう。

以上のように、HyperEVM上ではEthereumで考えられるほぼすべてのDeFiアプリケーションが展開可能であり、さらにHyperliquid L1とのネイティブ連携によって**「取引所機能」と「スマートコントラクトロジック」の融合**が実現します。他チェーンでは得られない深い流動性や高速執行環境を直接利用できるため、新しい金融Primitive（基礎構造）が登場する余地があります。例えばVault戦略やヘッジファンド的プロトコル、リアルタイム清算システムなど、CeFiの持つ柔軟性とDeFiの持つ透明性を兼ね備えたユースケースが期待されています。

4. 制約により難しい/不可能なユースケース


前述の部分的アトミック性の制約により、慎重な設計を要する、または現実的に困難と思われるユースケースも存在します。この章では、「Atomicな処理ができない」ことが及ぼす影響を中心に、どんなユースケースが難しいか、そして考え得る代替策について述べます。

  • アトミックな裁定取引やスワップ: 最も影響が大きいのは、複数のアクションを一括実行し、いずれか一つでも失敗したら全て取り消すといったタイプの取引です。典型例がアービトラージ（裁定取引）やフラッシュローンを絡めたスワップです。Ethereum DeFiでは、例えばあるトークンをDEX Aで買ってDEX Bで売る2段階を1つのトランザクションで行い、途中で想定利益が出なければトランザクションをリバートする、といった原子的処理が可能でした。しかしHyperliquidの環境では、片方がEVM内（例えばHyperEVM上のAMM）でもう片方がL1の注文板、といったケースで同時に実行・同時に完了させることができません。EVM側のスワップは即座に完了しますが、L1側の売却注文は次ブロックに持ち越され、その結果が不確実だからです。仮にAMMで買ったのに注文板での売却が失敗すれば、一方だけ実行され損失が出る可能性があります。このため、リスクなく価格差だけ抜き取るような瞬間的裁定取引は困難です。同様に、フラッシュローン（無担保の即時借入）を用いて複数の取引機会を一括実行し、最後にローンを返済する、といった一連の処理も、途中でHyperliquidの板取引が絡むと失敗時にロールバックできないため実現しにくくなります。つまり**「同期的な一括処理によるノーリスク取引」が原理的にできない**点で、トレーダーはオフチェーンリスク管理や段階的実行を余儀なくされます。結果として、Hyperliquid上では従来Ethereumで見られたようなMEV的フラッシュボットの動き方（同ブロック内での機会追求）は限定的となるでしょう。もっとも、Hyperliquid自体が高頻度取引向けに設計されているため、裁定機会自体が小さく短命である可能性もあり、この点の実害は限定的かもしれません。

  • 即時性を要する複合DeFiトランザクション: DeFiでは複数プロトコルを組み合わせた複雑なトランザクションがよくあります。例えば「ユーザーが担保を預け入れ、その場でステーブルコインを借り、そのステーブルコインで別の資産を購入する」など、一連の操作を一度のトランザクションで行えば中間ステップでの価格変動リスクを消せます。しかしHyperliquid環境で、途中にL1注文板での取引が挟まる場合、一括処理ができません。上記の例で言えば、「担保預入（EVM内）→ステーブルコイン借入（EVM内）→資産購入（L1上の現物取引）」という流れになりますが、資産購入が次ブロックに持ち越されるため、借りたステーブルコインをすぐ運用できず一旦ブロックを跨いで保有することになり、市場変動リスクを負う時間差が生じます。また、購入が失敗すればユーザーはステーブルコインの借入だけが残ってしまい、借金を負ったままになります。これを防ぐために、プロトコル側で予め「もし購入に失敗したら○○ブロック以内に自動返済する」等の救済処理を設ける必要があります。要するに、本来一連で完結すべき処理を分割して扱わざるを得ないため、その間の市場リスクや失敗時の処理が新たな課題となります。分割実行中に価格が変動すれば期待結果が得られないことも考えられ、設計者はユーザーにそれを周知し納得してもらう必要もあるでしょう。

  • クロスチェーン原子的スワップ（アトミックスワップ）の困難: 一般に異なるチェーン間の原子的スワップ（例えばBitcoinとEthereumのアトミックスワップ）は難しい課題ですが、Hyperliquid内でもL1資産とEVM資産のアトミックスワップは容易ではありません。HyperliquidではL1とEVMが統合状態を保つとはいえ実行レイヤーは別なので、本質的にはクロスチェーン取引に近い状況です。例えばユーザーAが持つL1上のBTC（ネイティブラップされた資産）とユーザーBが持つEVM上のERC-20 USDCを原子的に交換することを考えると、仲介となるスマートコントラクトは片方の送金を受け取りもう片方の送金を指示することになりますが、後者（L1側送金）は次ブロックになります。途中で相手が送金を取り消す（EVM側ならトランザクションをリバートする）余地があるため、信頼のない当事者間での安全な同時交換は難しくなります。代替としては、**Hash-Time-Locked-Contract（HTLC）**のような仕組みを使って二段階で交換する方法がありますが、それでもチェーンを跨ぐ以上完全に同時ではなく時間差のリスクを伴います。Hyperliquid内であれば最終的に共通のコンセンサスで落ち着くため理論上解決策は考えられますが、少なくともEVM単体で完結する原子的スワップと比べ格段に実装・利用が複雑になるでしょう。

  • DeFiプロトコル間の即時な組み合わせ: Ethereumでは「マッシュアップ」的に、あるコントラクトから他のDeFiコントラクトを呼び出し、それがさらに別のプロトコルを呼ぶといった深いコンポーザビリティが可能で、これらが一つのトランザクションにネストして実行されます。HyperEVM上でもEVM内のコントラクト同士であれば同様に組み合わせ可能ですが、間にL1操作が入ると同じやり方は通用しません。例えば、あるコントラクトAが内部で「まずUniswap的DEXでスワップし、そのトークンでHyperliquidのパーペチュアルをロングし、その結果に応じてさらに別の処理をする」みたいなロジックを記述しても、パーペチュアルのロング（L1注文板での建玉）は即時完了しないため、後続の処理に必要な情報（例えばポジションの成立可否や取得量）がその場で得られません。このように異なる環境に跨るとコントラクト間のシームレスなやりとりが阻害されるため、従来可能だった複雑なDeFiロジックの一部は簡単には再現できません。特に、即時にフィードバックを得てループを回すようなロジック（例: 最適利率を求めて複数プロトコル間で資金を移動するyield aggregatorなど）は、L1操作部分だけ別取引に切り離して対応する必要があります。

  • 代替手段や回避策: 以上のような制約に対して、開発者は以下のような工夫や回避策を検討できます:
    (a) 二段階実行（オプティミスティックな設計）: 跨る処理を**フェーズ1（準備）とフェーズ2（確定）**に分ける方式です。フェーズ1ではEVM内で必要資源をロックしたりフラグを立てたりしておき、L1でのアクションを発行します。フェーズ2では次のブロック以降、L1の結果を確認してから改めてEVM側で残りの処理を行います。例えば前述の担保清算のケースでは、まず清算開始フラグを立て対象担保を凍結、L1に売却注文イベントを出す（これがフェーズ1）。次のブロックで売却結果を確認し、得られた金額を債務返済に充て不足があれば債務残高を記録する（フェーズ2）といった具合です。このように設計すれば、完全に同期的ではないものの論理的一貫性を保った処理が可能です。ただしユーザーから見るとプロトコル内の状態が2ブロックに跨って変化するため分かりづらく、また途中で失敗した場合の扱い（例えば売却失敗なら担保凍結を解除する等）も慎重に実装しなければなりません。ある意味、楽観的ロールアップが非同期メッセージで状態更新する手法に似ています。

    1. (b) オフチェーン連携（キーパーの活用）: 完全にオンチェーンだけで対処しようとせず、信頼できるオフチェーンエージェント（キーパーやボット）に補助させる方法です。例えば、コントラクトはあくまでイベント発行まで行い、結果の確認やフォローアップ処理は予めプログラムされたオフチェーンボットが検知してトリガーします。清算の例で言えば、清算注文を出した後、独立したボットが次のブロックでその注文が通ったか確認し、通っていなければ再度注文イベントを出す、通っていれば担保解除処理のトランザクションをコントラクトに発行する、といった流れです。これは厳密にはオンチェーン完結ではありませんが、非中央集権的なネットワーク（複数のボットが競合参加する等）を構築すれば信頼を分散させることができます。KeeperDAOやGelato Networkのような仕組みを組み合わせることで、Hyperliquid上でも自動執行エコシステムを作れるかもしれません。

    2. (c) インセンティブと保険メカニズム: 非同期処理に伴うリスクを軽減するため、プロトコル側でインセンティブや保険を用意することも考えられます。例えば「清算が遅延・失敗して損失が出た場合、プロトコルの保険基金から補填する」「L1注文が滑っても影響が小さくなるよう常に余剰担保を確保させる」「裁定取引を行うユーザーには失敗時のコストをカバーするため予め保証料を課し、成功時にそれを払い戻す」といった工夫です。要は、失敗したときの痛手を和らげたり、成功させるためのコストをあらかじめ内包する形で設計します。これによってユーザーは多少のコスト超過や時間遅延が起きても安全に利用でき、開発者も完全な原子性がない前提でパラメータを調整できます。

    3. (d) 単一環境への閉じ込み: 根本的解決にはなりませんが、どうしても即時性が要求される部分はできるだけL1またはEVMどちらか一方の環境内で完結させることも検討すべきです。例えば高速な資産スワップが必要な場合、一旦HyperEVM上で完結するAMMで交換を済ませ、その後ゆっくりとL1板で希望の資産配分に調整するといった手順にするなどです。あるいは、Hyperliquidが許す範囲でL1側のAPI直投稿（オフチェーンシグナルを用いた即時注文）を活用し、スマートコントラクトを介さずユーザー自身が並行して操作する、といったUX上の工夫もあるでしょう。これはユースケースというより運用上の工夫ですが、要件に応じて適材適所で環境を選ぶことが重要になります。

まとめると、HyperliquidのHyperEVMは画期的なデュアルチェーン構造により高速取引所とスマートコントラクトの融合を実現しましたが、その一方でクロス環境間のトランザクションには従来にない非同期性と不確実性が伴います。多くのユースケースは工夫次第で実現可能ですが、「即時に結果を得られなければ成立しない」種類の取引やプロトコルはそのままの形では動かせないことに注意が必要です。Atomicな処理ができないという制約は、DeFiにおけるコンポーザビリティ（組み合わせ可能性）に一部制限を課すものの、逆に言えばこれまで不可能だった伝統的金融レベルの非同期取引をオンチェーンに持ち込む挑戦とも言えます。開発者はこの制約を理解した上で適切な設計パターンを採用し、安全性とユーザビリティを確保することが求められるでしょう。参考資料やドキュメントも限られている中、現在コミュニティで知見が蓄積されつつあります。Hyperliquidは今後公式ドキュメントの拡充や機能改善も予定しているため、最新情報を追いながら最適なユースケースを模索していく必要があります。既存のDeFiプロトコルの中には早くもHyperliquid対応を計画しているものもあり、新たな金融イノベーションの舞台としてHyperEVMが重要な役割を果たすことは間違いないでしょう。

いいなと思ったら応援しよう！