Sandwich Attack

What is a sandwich attack, and how does it differ from ordinary front-running?

A sandwich attack is a specific form of MEV (Miner/Maximal Extractable Value) extraction: the attacker spots a large decentralized exchange (DEX) transaction sitting in the mempool awaiting confirmation, predicts it will push the price in a particular direction, and front-runs it by submitting a same-direction transaction first (pushing the price up ahead of time). Once the victim's transaction executes at a worse price, the attacker immediately submits a reverse transaction to close the position and lock in profit. The victim's transaction ends up sandwiched between the attacker's two transactions — hence the name.

Ordinary front-running just means the attacker completes a same-direction trade ahead of the victim. A sandwich attack combines front-running with a follow-up close, requiring the attacker to execute two transactions within the same block (or an extremely short window) — a more well-defined technique with a more explicit profit mechanism.

サンドイッチ攻撃はなぜ存在し、どんなメカニズムがそれを利益に結びつけているのですか？

サンドイッチ攻撃が可能になる根本的な理由は、Ethereumなどの公開チェーンでは、取引がブロックに組み込まれる前に一時的に公開のmempoolに滞在し、誰でもこれら未確認の取引内容を見ることができるという点にある。この取引情報の透明性（本来はネットワークノードが取引を検証できるようにするためのもの）が、意図せず攻撃者に他者がこれから実行しようとしている取引を「事前に見る」ことを可能にし、ブロックビルダー（マイナーやバリデーター）がより高いガス代を提示する取引を優先的に処理する仕組みを利用して、被害者の取引の前後に割り込むことを可能にしている。

AMM（自動マーケットメーカー）型DEXの価格メカニズムもこの問題を増幅させる——取引量が大きいほど価格へのスリッページの影響も大きくなり、大口取引の被害者ほど「うまみ」も大きくなることを意味する。これがサンドイッチ攻撃が特に大口のswap取引に集中する理由でもある。

サンドイッチ攻撃は実際どのように実行され、攻撃者には何が必要ですか？

攻撃者は通常、mempool内の未確認取引を継続的に監視する自動化エージェントシステムを運用し、アルゴリズムでどの取引が規模とスリッページ設定の点で攻撃に値するかをリアルタイムで判断する（スリッページ許容度が緩く設定されている取引ほど、攻撃の余地が大きい）。条件に合致すると判断すると、エージェントは前置取引と後置取引の2つを同時に組み立て、被害者の取引よりも高いガス代を支払うことで、自分の前置取引がブロックビルダーによって優先的に組み込まれるようにする。

近年、単純にガス代を競り上げるだけのフロントランニングはコストが上昇し、他のMEVボットとの競争に敗れやすくなったため、多くの攻撃者はプライベートトランザクションプールサービス（Flashbotsのようなインフラなど）を利用する方向にシフトしている。これによりブロックビルダーと直接取引順序を交渉でき、公開mempoolで他のエージェントと価格競争する必要がなくなり、攻撃はよりステルス性が高く、成功も安定するようになった。

一般ユーザーへの実際の影響は何ですか？攻撃を受ける確率を下げるにはどうすればよいですか？

DEXでswapを実行する際にサンドイッチ攻撃に遭った場合、実際の影響としては約定価格が想定よりも悪化する——その差額がそのまま攻撃者の利益となる。取引インターフェース上では通常「この損失は攻撃によるものだ」とはわからず、単なる通常の市場スリッページと誤解されやすい。

攻撃を受ける確率を下げる実用的な方法には、スリッページ許容度を合理的な範囲にできるだけ近づけて設定すること（取引失敗を恐れて広く設定しすぎない）、MEV保護機構を備えた取引ルート（プライベートトランザクションプールを経由して送信し、公開mempoolでの露出を避けるなど）を使用すること、流動性の薄い取引ペアでの大口swapを避けること（スリッページの余地が大きいほど狙われやすい）が含まれる。現在、多くの主流ウォレットとDEXフロントエンドには既に一部のMEV保護オプションが組み込まれており、取引前に有効になっているか確認する価値がある。