Jito DontFrontによるMEV対策

最大抽出可能価値（MEV）とは、ブロック内のトランザクションの並び替え、追加、または除外によって得られる価値を指します。MEVは特定のチェーンに固有のものではなく、ブロック生産者がトランザクションの順序を制御するあらゆるブロックチェーンに本質的に存在します。裁定取引のように、DEX間の価格差を修正することで市場の効率性を高めるMEVもあります。一方、サンドイッチ攻撃のように、ユーザーから直接価値を搾取するものもあります。DeFiアプリケーションを構築する開発者にとって、これはトレード実行の悪化や利益の損失を意味する可能性があります。

このガイドでは、有害なMEVの一般的な形態であるサンドイッチ攻撃と、Jitoのdontfront機能を使ってそれを軽減する方法に焦点を当てます。

推奨される事前学習: Jito Bundles

SolanaにおけるMEV

Solanaのアーキテクチャは、パブリックメモリプールを持つチェーンと比較して、MEVの攻撃対象領域をすでに縮小しています。トランザクションは共有メモリプールに滞留するのではなく、次のブロックリーダーに直接転送され、未処理のトランザクションはおよそ150ブロック（約1分）後に期限切れとなります。これにより、サーチャーが未確定トランザクションを観察して行動できる時間的余地が大幅に狭まります。

それでも、MEVの抽出は発生します。最適化されたインフラとvalidatorへの直接接続を持つサーチャーは、トランザクションの流れを観察してそれに反応することができます。Solana上のMEV活動の多くはアトミック裁定取引です。これは、単一のトランザクションでDEX間の価格差を修正するボットによるものです。このタイプのMEVは、市場全体の価格一貫性を向上させるため、一般的に有益とされています。

開発者が積極的に防御すべき有害なMEVは、サンドイッチ攻撃です。

サンドイッチ攻撃とは？

サンドイッチ攻撃は、サーチャーがあなたの保留中のスワップを検知し、トランザクションの順序を悪用することで発生します：

1. フロントラン：サーチャーがあなたのトレードより先にトークンを購入し、価格を引き上げます
2. あなたのトレードが実行される：予想より悪い価格で約定します
3. バックラン：サーチャーがあなたのトレードの後にトークンを売却し、その差額を手に入れます

Solanaでは、これはJitoバンドルを通じて発生する可能性があります。サーチャーは[frontrun_tx, your_tx, backrun_tx]のようなトランザクションのバンドルを送信し、ブロックエンジンはそれらを順番にアトミックに実行します。被害者はより悪い実行価格を受け取る一方で、サーチャーはそのスプレッドから利益を得ます。

DontFrontの仕組み

DontFrontは、Jitoブロックエンジンの機能であり、サーチャーがバンドル内であなたのトランザクションの前にトランザクションを配置することを防ぎます。

仕組み：jitodontfrontで始まる有効なSolanaの公開鍵を、トランザクション内の任意のinstructionsに追加します。ブロックエンジンはこのプレフィックスを認識し、あなたのトランザクションを含むバンドルはそれをインデックス0に配置しなければならないというルールを適用します。

Without dontfront:  [frontrun_tx, your_tx, backrun_tx]  ← sandwich possible
With dontfront:     [your_tx, ...]                       ← your tx must be first

ステップバイステップ

1. 有効なアドレスを選択する：jitodontfrontで始まるもの（例：jitodontfront111111111111111111111111111111）。アカウントはオンチェーンに存在する必要はなく、読み書きされることもありません。文字列が有効なアドレスであることは、@solana/kitのassertIsAddress関数を使って検証するか、Solana Explorerにそのアドレスをвходカして解決されるか確認することができます。無効なアドレスの例はこちらです。

2. 読み取り専用・非署名者アカウントとして追加する：トランザクション内の任意のinstructionsに追加します。最適なランディング速度のために読み取り専用としてマークしてください。（System Programを含む）ほとんどのプログラムは、想定外の余分なアカウントを無視します。

3. Jitoブロックエンジン経由で送信する：

   • sendTransaction: https://mainnet.block-engine.jito.wtf/api/v1/transactions
   • sendBundle: https://mainnet.block-engine.jito.wtf/api/v1/bundles

   ドキュメント： sendTransaction および sendBundle

4. ブロックエンジンがjitodontfrontプレフィックスを検出し、順序ルールを適用します。

ブロックエンジンでの処理

ブロックエンジンがjitodontfrontアカウントを含むトランザクションを検知した場合：

• sendTransaction経由：トランザクションは保護されます。いかなるバンドルもその前に別のトランザクションを配置することはできません
• sendBundle経由：トランザクションはインデックス0に配置される必要があり、そうでない場合はバンドル全体が拒否されます

jitodontfrontアカウントを含まないトランザクションおよびバンドルには影響しません。

バンドルの順序ルール

これらのルールは、jitodontfrontトランザクションがバンドル内に現れる場合に適用されます。

許可されるパターン

[tx_with_dontfront, tip]
[tx_with_dontfront, arbitrage, tip]
[tx_with_dontfront_signer1, tx_with_dontfront_signer1_and_signer2, tip]

1つのバンドル内の複数のDontFrontトランザクション

単一バンドル内の複数のdontfrontトランザクションは、両方の条件が満たされた場合に許可されます：

1. すべてのdontfrontトランザクションがバンドルの先頭に連続して配置されている
2. 各dontfrontトランザクションが、最初のdontfrontトランザクションと少なくとも1人の署名者を共有している

✅ [txA_df, txB_df, txC_df, arbitrage, tip]
   (contiguous at front, overlapping signers)

✅ [txA_df_signer1_signer2, txB_df_signer1_signer3, txC_df_signer2_signer4]
   (each shares a signer with txA)

拒否されるパターン

❌ [tip, tx_with_dontfront]
   → dontfront tx is not at index 0

❌ [txA_df_signer1, txB_df_signer2]
   → no overlapping signer between txA and txB

❌ [trade, tx_with_dontfront, arbitrage, tip]
   → dontfront tx is not at the front

統合例

簡単なコードレシピについては、 MEV対策クックブックエントリを参照してください。

TypeScript（@solana/kit）

核心的なアイデアは、任意のinstructionsにdontfrontアカウントを追加するヘルパーです：

import {
  address,
  AccountRole,
  type Instruction,
  type Address
} from "@solana/kit";

const DONT_FRONT: Address = address(
  "jitodontfront111111111111111111111111111111"
);

function withDontFront(ix: Instruction): Instruction {
  return {
    ...ix,
    accounts: [
      ...(ix.accounts ?? []),
      { address: DONT_FRONT, role: AccountRole.READONLY }
    ]
  };
}

次に、署名済みトランザクションを標準のRPCノードではなくJitoブロックエンジンに送信します。常にbase64エンコーディングを使用してください。Base58はJitoのAPIでは非推奨です。

const response = await fetch(
  "https://mainnet.block-engine.jito.wtf/api/v1/transactions",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "sendTransaction",
      params: [base64Tx, { encoding: "base64" }]
    })
  }
);

ベストプラクティス

DontFrontは保護の一層です。堅牢なMEV軽減戦略は複数のアプローチを組み合わせます：

トランザクションレベルの保護

• スリッページ許容値を厳しく設定する。 サンドイッチ攻撃に対する最も効果的な防御策は、スワップにおける許容スリッページを制限することです。スリッページ幅を小さくすることで攻撃者が得られる利益の余地が減り、あなたのトランザクションがサンドイッチ攻撃の対象として魅力的でなくなります。

• 適切なチップと優先手数料を設定する。 混雑時には、チップと優先手数料を高く設定することでトランザクション/バンドルが迅速にランディングする可能性が高まり、サーチャーが行動できる時間的余地を狭めます。適切なチップの設定方法については、Jitoのチップ金額に関するドキュメントをご覧ください。

• コンピュートユニットの使用を最適化する。 各ブロックには利用可能なコンピュートユニットの上限があります（アカウントにもブロックあたりの上限があります）。トランザクション/バンドルがブロックに含まれる可能性を最大化するために、コンピュートユニットの使用を最適化すべきです。詳細については、Solanaでのコンピュートユニット使用最適化方法ガイドをご覧ください。

DontFront固有の設定

1. dontfrontアカウントを読み取り専用としてマークする。 書き込み可能としてのマークも機能しますが、読み取り専用の方がランディング速度を最適化します。

2. アプリケーションごとに固有のdontfront pubkeyを使用する。 jitodontfrontで始まるpubkeyであれば何でも機能します。固有のバリアント（例：jitodontfront111111111111111111111111111123）を使用することで、オンチェーンデータを調査する際にアプリごとの使用状況を区別できます。

3. DontFrontはアドレスルックアップテーブルをサポートしています。 dontfrontアカウントはALT経由で含めることができます。ただし、チップアカウントにはALTを使用しないでください。

制限事項

• ブロックエンジンのみ。 DontFrontはJitoブロックエンジンによって適用されます。validator（Jitoをバイパス）に直接送信されたトランザクションは保護されません。

• 保証ではありません。 Jitoのドキュメントより：「この機能はサンドイッチ攻撃の軽減に役立つ可能性がありますが、それを保証するものではなく、サードパーティが行うものを含む、トランザクション順序のすべての変動に対する解決策でもありません。」

• メインネット/テストネットのみ。 これはJitoブロックエンジンの機能です。devnetまたはlocalhostでは動作しません。

参考資料

• Jitoドキュメント：サンドイッチ対策
• Jitoドキュメント：sendTransaction
• Jitoドキュメント：sendBundle
• Jitoドキュメント：チップアカウント
• Jitoドキュメント：チップ金額
• Tip Floor API
• @solana/kit（GitHub）
• solana-sdk（crates.io）