はじめに
SolanaのMEV（取引の並び順から生じる追加収益）を理解するには、まず「誰が何を送って、どこで選ばれ、誰にtipが配られるのか」を分けて見ます。MEVは、悪意ある取引順序の操作という意味だけではありません。
裁定（価格差を取る取引）や清算（担保割れポジションの強制決済）、混雑時の優先実行など、ブロック生成の前後で生じる価値を広く含みます。こうした機会を成立させる手段が、複数の取引をまとめて実行するbundleのatomic execution（まとめた取引が全部成立するか全部無効になる方式）です。
SolanaでこのMEVを大きく担うのがJitoの仕組みです。Jito-Solanaを使うバリデータはJito Block Engineに接続します。searcher(取引機会を探す参加者)やアプリケーションは、そこへbundleを送ります。bundleには採用を促すtipが付くことがあり、採用されたbundleのMEV収益をバリデータと委任者へどう分けるかは、設定しだいです。
この記事はMEVの仕組みを扱います。Jito-Solanaをクライアントとして比較する話はクライアントの記事、収益としてのMEVの見方（どう選ぶか）は選び方の記事にあります。
Jito-SolanaとBlock Engine
Jito-Solanaは Agave validator clientの最適化版です。バリデータはこのJito-Solanaを実行し、Jito Block Engineに接続します。
searcherやdApp、botなどは、Block Engineへトランザクションやbundleを送ります。account lockとは、同じ口座に触れる取引どうしがぶつかる状態のことです。Block Engineはbundleをシミュレーションし、tipやaccount lockの競合を見ながら、バリデータに渡す組み合わせを決めます。
この流れでは、通常のpriority fee、つまり混雑時に処理を早めるための追加手数料とは別に、Jito tipが発生します。priority feeはSolanaプロトコル上の手数料で、SIMD-0096の適用により100%がバリデータへ入る設計です。
Jito tipは、bundleが採用されるために支払うtipで、Jitoの支払い・分配プログラムを通じてバリデータと委任者へ配分されます。
Block Engineの利用には、手数料（Block Engine fee）が伴うこともあります。これはバリデータのMEV commission（取り分）と合わせて、委任者の受け取り額を左右する要素です。
金額の決まり方も違います。priority feeは、使う計算量とその単価で決まります。Jito tipは、searcherが提示する入札額そのものです。
利用者から見ると、priority feeとJito tipはどちらも「取引が通りやすくなる費用」に見えます。ただし、発生する場、金額の決まり方、分配先は同じではありません。
Bundleとは何か
bundleは最大5つのトランザクションをまとめたものです。bundle内のトランザクションは順番に実行され、atomicに扱われます。全部成功するか、全部失敗するかのどちらかです。裁定取引のように、複数の取引をまとめて成立させたい場面で使う手法です。
bundleどうしはtipの多さで競います。Block Engineはbundleをシミュレーションし、利益の高い組み合わせをバリデータへ送る仕組みです。Jito docsによると、account lockの重なりに応じて並列auction、つまり同時並行の入札を行います。その際、tipとCompute Unit(計算処理量の単位)の効率も見てbundleを選ぶとしています。
この仕組みは、Solanaの速いブロック生成と相性があります。ただし、バリデータの地理的な配置、Block Engineとの往復レイテンシ、leader slot(自分がブロックを作る順番)での処理能力が収益に効きます。JitoのFAQでは、Block Engineとのround-trip latencyがbundle inclusionに影響するとしています。
Tip Distribution Program
JitoのTip Distribution Programは、バリデータと委任者へMEVを配るためのプログラムです。Jito Foundationのdocsによると、バリデータクライアントは各epochごとに一意のTipDistributionAccountを作ります。epochは、報酬計算の一区切りです。
このkeyは、epochとvote account public key(バリデータが投票に使うアカウントの公開鍵)から決まります。そのepoch中のMEVチップが、このアカウントに集約される仕組みです。
epochが終わると、前epochの最後のslotをもとにsnapshotを取ります。このsnapshotから、各バリデータとstake アカウントへのclaim（請求して受け取る操作）の情報を集めます。この情報を、merkle tree、つまり請求内容を検証できる木構造にまとめる流れです。
そのrootをオンチェーンにアップロードすると、バリデータや委任者はMEVをclaimできます。第三者が代理でMEVをclaimする設計もあります。
委任者の立場では、実際の受け取りを左右するのは次の3点です。
- MEVチップが本当に委任者に配分される設定か
- claimが自動か手動か
- claim後に自動で再ステークされるか
インフレ報酬（新規発行分から受け取る基本報酬）はstake アカウントへ自動的に入ります。そのままactive stake(報酬計算に有効なステーク)として再委任されるのが基本です。MEVチップは、これとは別のclaimや分配フローになることがあります。表示APRにMEVを含める場合、この違いの説明がないと、利用者は「同じ種類の報酬」と受け取りがちです。
sandwich対策
MEVには、利用者に不利な形で取引順序を利用するパターンもあります。その代表がsandwich（標的の取引の前後に自分の取引を挟み、価格を不利に動かす手口）です。
Jito docsは、このsandwichへの対策として、jitodontfrontで始まるpublic keyをトランザクションに含める方法を挙げています。このアカウントを含むbundleは、対象のトランザクションがbundleの先頭にない限り、Block Engineに拒否されます。
このような仕組みがあるため、MEVを単に「追加利回り」とだけ扱うのは粗い見方です。どのBlock Engineを使い、どのポリシーでbundleを受け、利用者保護をどう扱うかで、MEVの性格は変わります。
MEVを構成要素に分ける
MEVは一括りにせず、次の要素に分けると仕組みが整理できます。選定でこれをどう使うかは選び方の記事にまとめています。
- Jito-Solanaの利用有無：Jito Block Engineに接続しているか
- MEVチップの分配：バリデータと委任者への配分設定
- 手数料：Block Engine feeやバリデータ側のMEV commission(取り分)
- claim方法：自動claim、手動claim、代理claimの有無
- 再ステーク：claim後に自動でstake アカウントへ戻るか
- レポート：epoch別、バリデータ別、stake アカウント別に追跡できるか
MEVは、Solanaのバリデータ報酬を語るうえで避けて通れない論点です。ただし安定収益ではなく、市場環境やDEX（分散型取引所）活動、清算量、Block Engineとの接続品質で大きく振れます。利回りの読み方やバリデータの選び方は、選び方の記事で扱います。