ERC4337 Frontrunningの探究

この記事は以下を翻訳したものになります。
Adventures in ERC4337 frontrunning

Ethereumの新しいトランザクションモデルに隠された工夫を見つけたら、支払ったgas feeをほぼ倍にして返してもらえる可能性があると想像してみてください。それが、ERC-4337のfrontrunningという、まさに新フロンティアです。

大学2年生のとき、Account Abstractionについてもっと知ろうと、ERC-4337の仕様書を読んでいました。ERC-4337では、スマートウォレットが署名する特別なトランザクションであるUserOperations（以下、UserOps）が導入されています。これらのトランザクションは、bundlerと呼ばれるアクターによってオンチェーンでリレーされます。UserOpsは署名済みなので、ERC-4337はスマートウォレットのコンテキスト内で実行する前に、スマートウォレットによる承認を検証します。
興味深いことに、スマートウォレットはオンチェーンリレーのgas feeを直接負担しません。代わりに、bundlerがgas feeを立て替え、UserOpの実行中にスマートウォレットがそれを返済する仕組みです。

UserOpsの仕組みを理解する

以下がUserOpの構造（バージョン0.6時点）です：

    struct UserOperation {
        address sender;
        uint256 nonce;
        bytes initCode;
        bytes callData;
        uint256 callGasLimit;
        uint256 verificationGasLimit;
        uint256 preVerificationGas;
        uint256 maxFeePerGas;
        uint256 maxPriorityFeePerGas;
        bytes paymasterAndData;
        bytes signature;
    }

注目すべきは、UserOpにはリレーに対する支払い額を示すmaxFeePerGasとmaxPriorityFeePerGasというフィールドが含まれている点です。
例えば、こちらのAAトランザクションを見てください。bundlerが支払ったのは0.0048 POLでしたが、返済されたのは0.0091 POLで、支払額のほぼ倍です！
AA bundleは、オンチェーンの混雑時にトランザクションが止まらないよう、gas feeを多めに支払うことがよくあります。しかし、過剰に支払うケースが多く、これが利益を得るチャンスを生んでいます。

私たちは、返済額よりも安くリレーされているUserOpsを見つけ、少しgas priceを上げてリレーし、返済額を受け取ります。すると、リレーにかかったコスト以上の金額を得られるのです。

この戦略を実行するには、元のbundlerが返済を受け取る前に私たちがUserOpを実行する必要があります。後に実行した方はトランザクションがrevertしてしまい、損失を出します。

この戦略を実現するには、4337 bundleがオンチェーンで送信されている必要があり、pendingトランザクションを確認できる環境が必要です。幸い、PolygonはAAの利用が活発で、mempoolも公開されています。

• 通常のfrontrunningとの違いは？
  通常のfrontrunningとは異なり、エンドユーザーやスマートウォレットに悪影響はありません。UserOperationは成功裏に実行されますが、bundlerが異なるだけです（これは4337の仕様で設計されたalt mempoolの本来の意図でもあります）。確かに元のbundlerはgas feeで損をしますが、理想的には、bundlerはUserOpに指定されたgas priceと同じ価格でEOA bundleを送るべきです。そうすれば、搾取の余地はなくなり、元のbundlerのトランザクションがrevertすることもなく、スマートウォレットは支払った分の実行速度を得られます。しかし、支払いが不足している場合、元のbundlerはfrontrunされる隙を残してしまいます。どちらにせよ、スマートウォレットは過剰に支払うことになります。

ボットの構築

私は資金が乏しく、Polygonのmempoolを監視するために自分専用のノードを運用するのもコストがかかりすぎる状況でした。
そこでBlockNativeが提供していたAAトランザクション用の「explorer」を発見しました。Polygonのpendingトランザクションを表示するもので、ブラウザのコンソールで調べたところ、彼らがmempool API（有料）を利用しており、APIキーがリクエスト内に漏洩していることが分かりました。現在そのexplorerは閉鎖されていますが、Wayback Machineでスナップショットが見られます：https://web.archive.org/web/20231201172934/https://4337.blocknative.com/
ネットワークリクエストを詳しく調べ、エンドポイントへの認証を行う一連のwebsocketメッセージを見つけ出し、ethers.jsを使ってこの戦略を実行する簡単なスクリプトを作成しました。
ネットワークリクエストを基に開発したもの

    const blocknative_url = `wss://api.blocknative.com/v0`;
    const initialPayload = {
      "timeStamp":"2024-04-04T17:30:59.026Z",
      "dappId":"87f7d1d2-00d5-4eea-b5a3-1c696177ab06",
      "version":"4.6.7",
      "appName":"unknown",
      "appVersion":"unknown",
      "blockchain":
        {"system":"ethereum",
        "network":"matic-main"
      },
      "categoryCode":"initialize",
      "eventCode":"checkDappId",
      "connectionId":"f4-2d7ff094-ed60-4851-96e8-0d52d0a26738"
    };    
    const watchPayload = {
      "timeStamp":"2024-04-04T17:30:59.026Z",
      "dappId":"87f7d1d2-00d5-4eea-b5a3-1c696177ab06",
      "version":"4.6.7",
      "appName":"unknown",
      "appVersion":"unknown",
      "blockchain": {
        "system":"ethereum",
        "network":"matic-main"
      },
      "eventCode":"accountAddress",
      "categoryCode":"watch",
      "account": {
        "address":"0x0576a174d229e3cfa37253523e645a78a0c91b57"
      }
    }
    
    const watchPayload2 = {
      "timeStamp":"2024-04-04T17:38:57.383Z",
      "dappId":"87f7d1d2-00d5-4eea-b5a3-1c696177ab06",
      "version":"4.6.7",
      "appName":"unknown",
      "appVersion":"unknown",
      "blockchain": {
        "system":"ethereum",
        "network":"matic-main"
      },
      "eventCode":"accountAddress",
      "categoryCode":"watch",
      "account": {
        "address":"0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789"
      }
    }

すぐに反応がありました：
https://x.com/0xKofi/status/1796509704278958086

いくつかのトリック

1. ターゲットのトランザクションと同じブロックに50％の確率でしか入れませんでした。frontrunトランザクションをできるだけ速く、広範囲に送信して、同じブロックに入る確率を上げたいと考えました。公開されているPolygonのRPCリストを集め、トランザクションを非同期でできるだけ多くのRPCに送信するようにしました。

   • Merkleが非常に役立ちました。彼らのトランザクション注入エンドポイントはPolygon向けに提供されており、これがしばらく私の秘密兵器でした。このエンドポイントはトランザクションを彼らのノードネットワークのmempoolに追加し、ピアにブロードキャストしてくれます。

2. トランザクションのnonceは連続かつ単調増加である必要があります。例えば、nonce 3とnonce 5のトランザクションを送信した場合、nonce 4のトランザクションがまだネットワークにないと、nonce 5のトランザクションはノードに取り込まれません。
   私は3秒ごとにトランザクションを送信していましたが、ネットワーク全体が私のトランザクションを順番通りに伝播する前に次のトランザクションを送ってしまうことがありました。同じブロック内で複数のトランザクションを送るスピードが速すぎて、ネットワークが順序を保てなかったのです。

   • 対策として、8つのアドレスをローテーションして使用しました。これにより、1アドレスあたりのトランザクション間隔が約3秒から約24秒に延び、十分な時間となりました。
   • それでも、チェーン上でgas priceが急上昇するとアドレスが詰まることがありました。例えば、30 gweiでトランザクションを送ったのに、gasが突然40 gweiに跳ね上がる場合です。この問題に対応するため、タイマーでアドレスが詰まっていないか定期的にチェックし、ネットワークが期待する次のnonceと私の内部カウンターが一致しているか確認しました。詰まったアドレスは無効化し、詰まりが解消するのを待ちました（後で、gas priceを上げた0 ETHの自己送金トランザクションで「詰まり解消」を実装しました！）。
   • 追加情報：https://x.com/norswap/status/1802165529567711303?s=46
     pendingトランザクションがある場合、次のnonceを取得するのは難しいですが、ethers.jsのpendingパラメータやalloy-rsの同等の機能のおかげで簡単に解決できました。

3. websocket mempool APIを利用したので、独自のノードを運用する必要はありませんでした。実は、Azureの無料クレジットを使ってPolygonノード（bor）を運用しようとしましたが、同期に膨大な時間がかかり断念しました。

ボットのバージョン2を構築

BlockNativeがサービスを終了してしまいました。BitqueryやAlchemyを使ってmempoolのwebsocketストリームを試しましたが、どちらもレイテンシーが高く、一部のトランザクションを拾えないことがありました。frontrunを送る頃にはすでに遅すぎることが多かったです。
結局、独自のノードを運用する必要がありました。そこで、Rustで書かれたモジュール性の高いEthereumノードであるrethの一部を組み合わせ、mempoolから新しいトランザクションを提供するwebsocketエンドポイントを追加しました。
ChainboundとMerkleに感謝します。両社ともrethを本番環境で使用しており、スタート方法について素晴らしいブログを提供してくれました。特に参考になったのは：

• [Merkle] Modifying reth to build the fastest transaction network on BSC and Polygon — ネットワーク専用ノードを立ち上げる手順を詳細に説明した素晴らしい資料です。
• [Chainbound] Diving into the Reth p2p stack — pendingトランザクションやピアからのリクエスト、ネットワークイベントのストリームを取得する方法を解説しています。

いくつか問題が発生しました：

1. ピアがGetBlockHeadersやGetBlockBodiesなどのデータを要求してきた場合、そのデータを返せなければ切断されてしまいます。

解決策

読者の課題として残しておきます。フルノードを運用したくない場合、必要なデータを取得して応答を作成できる別のソースはあるでしょうか？

2. Polygonノードとの接続が難しかったです。MerkleのDiscordサーバーでサポートを受け、ようやく正しい方向に導いてもらいました。実はPolygonは、Proof-of-Workのように新しいブロックをネットワーク全体にブロードキャストしています。rethのネットワークスタックをPoSに設定すると、これをプロトコル違反とみなし、ピアを切断してしまいます。PoWに戻すことで解決しました。

これらの問題を解決し、無事に稼働させることができました。
https://youtu.be/TednyincxUc

rethノードの性能が非常に高く、frontrunの勝率が80％以上に向上しました。

AWSの無料枠からHetznerに移行し、複数のrethネットワークノードを稼働させ、TypeScriptで書かれた同じ実行エンジンに転送するようにリファクタリングしました。

他の人との交流

BlockNativeがmempoolストリーミングAPIを廃止した後、代替手段を探している人が何人かいました。私は彼らに連絡し、ホスト型代替サービスの興味を集めました。
私がfrontrunしていたトランザクションの多くが、Piggybox NFTの転送に関連していることに気付きました。
Piggyboxの背後にあるチーム、EARN’Mに連絡し、彼らが使用しているbundlerサービスがgas feeを過剰に支払っていることを伝え、より良いbundlerを作成する提案をしましたが、サポートチームが私のメッセージをチームに転送した後、返信はありませんでした。

ボットのバージョン3（未完成）🦀

実行エンジンをTypeScriptからRustに移行する作業を始めました（alloy-rsが素晴らしい！）。実験ではクリティカルパスを3ms未満に短縮できましたが、プロトタイピングや実験の速度とシステムの信頼性の間でトレードオフが生じました。
Rustは確かに優れていましたが、新しいロジックを素早くテストしたり、リファクタリングしたりするのが難しく感じました。

競争との対峙

frontrunningには競争がつきものでした！2024年夏には、以下のアドレスを持つ別のsearcherと競合しました：

  "0xCd22C256E222529A29438406163Be3743d952cCD",
  "0xA3e411169d3e009C304820eD9ed9A2BBe47dC390",
  "0xbDAfc006073765c968FBEDc4F637EbE6e9df80fe",
  "0xe787dC2C6497A696C7B22f18b152ccB744Da5BFA",
  "0xbcaCb47747a7b241aE6319a2D8e10bDF20Ce6Ff8",
  "0x1742Bb58C2Eb72e9f0CAbd63283755c3a8fE8C66",
  "0x66D2445905586b6c06f86B41C0606aC850EdF324",
  "0xB495e75d17A55Fe05D5746ebD5Dd162fBE12E9d9",
  "0x239E68175459B80DbDF70E5876B83668d8A79110",
  "0x3d739955243086032bB532A29C4F9e7fb1a86793"

これらのアドレスはBundleBearのoperator registryにも記載されていません。
私がrethネットワークノードを構築した後、彼らはほとんどの活動を停止しました。
さらに最近、約1か月前（2025年4月～5月）に別のsearcher（仮にsearcher Bと呼びます）が活動を開始しました。彼らの実行能力は非常に高く、特にPolygon上のすべてのトランザクションを確実に拾い、競合するfrontrunを即座に出し抜く能力を持っています。

例えば、Alchemyが30 gweiでhandleOpsトランザクションを送信したとします。私は+1 weiでfrontrunを送り、searcher Bがさらに+2 weiでfrontrunを送ってきます。あるいは、searcher Bのfrontrun（+1 wei）が出てくるのを待って私が+2 weiで入札すると、searcher Bは即座に以下のどちらかを行います：

• gas priceを10％以上上乗せしてトランザクションを直接置き換え可能ならそうする
• それよりも安ければ、0 ETHの自己送金（キャンセル）でトランザクションを置き換え、+3 weiで再送信する

このsearcherと入札戦争になりましたが、彼らの優れたネットワークカバレッジにより、ほぼ毎回負けてしまいました：

received at 2025-05-10T20:29:11.688Z
{
  from: '0xF62298f2a58e07e914eCB711b0042762CA676565',
  gas_limit: '1072531',
  gas_price: 'null',
  hash: '0x21a62de3ca45fdea7f465fcf75586b7323904c6dce04f515f5e20988389ef1cb',
  input: '0x1fad948c0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000f62298f2a58e07e914ecb711b0042762ca67656500000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000b4fd6eed1f2584318719d8f38994da6150f8254b000000000000000000000000000000000000000000000000000000000000224b0000000000000000000000000000000000000000000000000000000000000160000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000b7476000000000000000000000000000000000000000000000000000000000000fd8b00000000000000000000000000000000000000000000000000000000000117480000000000000000000000000000000000000000000000000000000873a60cab0000000000000000000000000000000000000000000000000000000873a60b000000000000000000000000000000000000000000000000000000000000000de00000000000000000000000000000000000000000000000000000000000000e8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c2447e1da2a000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000001000000000000000000000000853f2c11774bb08031e7dea93803569bbe2058f800000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000ac4e9b5170f00000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001c06233b2cbd9028884a62c3dc11f8724cfc088fbcf248b23f4a4d5f582ca2097c43a597b99ffaced5b3e8f6152170aaf20b360f9bb07c3eb153c3277c915a2c4500000000000000000000000000000000000000000000000000000000000003400000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001b99e2d284d5523b1608957536f9ad3c016ea462ec216e225b9266357331802f3b0be38aab54571fd69cf511276808ac46436c32b2f6bec95600fef5168e710b110000000000000000000000006cbd9b41ba653d1909eb47fca266f1c160552eac0000000000000000000000000000000000000000000000000000000000000180000000000000000000000000a34b19863e7b1b58e707c3a6bfbaa62f0fcca97f000000000000000000000000853f2c11774bb08031e7dea93803569bbe2058f80000000000000000000000000000000000000000000000000000000002faf08000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001bbf01394aedb56ece4a4e2dcf21625fc094cec98609afe7ca517c3f254de4ae0e711906bc559368cb49c063d448c27e2e3ba03d85beee7841726385b0e4a7587f00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000009636f75727479617264000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000003be9fd0ac95830558a994402d3d061dbd221575c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c99596d604be8ac20f56bff80660f72827697f600000000000000000000000031d058b5e02c8b01c749e6844d86cdd3f2962cd700000000000000000000000000000000000000000000000000000000000002000000000000000000000000006cbd9b41ba653d1909eb47fca266f1c160552eac00000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000002faf0800000000000000000000000000000000000000000000000000000000000000000e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f00000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000009636f757274796172640000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000544b02fcb9800000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001c781c97a3374fb1ef72e23d25870880ab60a3ed62fc3b69dfa3623924d9818e35432b32360085f3499e22077d84f867bf1cd8b4b9d18590947dca89c326d581cb000000000000000000000000776023a4573bd972c4c3e2a76f611d3c2bef516e00000000000000000000000000000000000000000000000000000000000001800000000000000000000000003be9fd0ac95830558a994402d3d061dbd221575c00000000000000000000000031d058b5e02c8b01c749e6844d86cdd3f2962cd70000000000000000000000000000000000000000000000000000000002faf08000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001c92a3863e20512e3675fb613543a5b6af64fc47d531303eb627e8bb79140f26ea509206b45ad7bc354c55de4608f354f59d24c15e5e289fe1470f59dfb16d59ce0000000000000000000000000a01dcab35dfea3ef072d154c2403d64addc3fee000000000000000000000000000000000 to: '0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789',
  type: '2',
  value: '0'
}
Found competing frontrun for signature 0x77d45b941a0b57619771e5dbc33714e116095b845072a5bf58a4b6dac362a59871923bdfd504b07b62e2c3fdf59f237bf2e1953816680f2a022fa748e8e486d61b
Competitor outbid us, rebidding higher
finding wallet by address 0x8CDA72Cd622825DBAd9234186F15A3A1a4e7743C
total time 17

Bid War History for signature 0x77d45b941a0b57619771e5dbc33714e116095b845072a5bf58a4b6dac362a59871923bdfd504b07b62e2c3fdf59f237bf2e1953816680f2a022fa748e8e486d61b
Timestamp			Incoming	Outgoing
------------------------------------------------------------
2025-05-10T20:29:09.438Z	30000000005	0xcf1253b8bf239abff622d90f5bf552955fd0d94ba920f10afb34a6baa474751e	30000000012	0x3c26c4c3a05cdcb8af812506c061c546cda9b3e5bde4598e12caa8052b1b628f
2025-05-10T20:29:09.766Z	33003000005	0xb0cd45bb8d05a8f6cf9c4e1ae631dd343a3b915366f73c25a52dc64eca507d1f	39603600006	0x97dd62e12ed7acf3146b7b54b96e4a7617f36d5cbd73d320bfa28e4b0a19949e
2025-05-10T20:29:10.128Z	39603600011	0xbd6ca5401fcc65478eda6f888f00d7a3d4c996a314db362212f1229975f2284f	47524320013	0xc8427e501138aba66199d8e3b2924c995e3854c4b1050c658417c3069f71fb76
2025-05-10T20:29:10.541Z	47524320018	0x4652e72cda40a3336df49870aa5a8e3383cc9098230b033ce19290a6a3405c53	57029184021	0x549c563dad56f2fa09154bd5fda6d08b5c54c418e6a094ffe6d3d5cbf2943084
2025-05-10T20:29:10.921Z	57029184026	0x99afdd8f6b9b8c9345837bce28b7ef0cfd00574950973df297f9dc348ddf46b4	68435020831	0x396da589345b5b962085741cf70e3bc11af3a994b7fc4b7f25e8c7ec0a9e069d
2025-05-10T20:29:11.256Z	68435020836	0x37be6c5c8961a34330785f885c0ead2415531bcd58bc17f0768d05cd31905f36	82122025003	0x8123d8a5c3a46eb560c0ad7d36b673ccdbeebd3737d810431728051a605a100e
2025-05-10T20:29:11.706Z	82122025008	0x21a62de3ca45fdea7f465fcf75586b7323904c6dce04f515f5e20988389ef1cb	98546430009	0xfea480c7e4fca87782f6a551e52ffb16cb01842130f8f87055b9c77f05bc0962

このsearcherと何度かやり取りしました：

1. 彼らが4337コールを見つけている方法が気になりました。私はPolygonのentrypointにすべてのコールを転送するだけのコントラクトを作成し、トランザクションをこのプロキシコントラクトに送信するようにしました。

   • Searcher Bは数時間、私のトランザクションを拾えませんでした。彼らのトランザクションが見えたときに一貫して上回ることができました。しかし、約8時間後、彼らはシステムをアップグレードし、プロキシコントラクトへのすべてのトランザクションを拾えるようになりました。

2. トランザクションがプロキシされることをどうやって知ったのか？すべてのアドレスへのトランザクションのcall traceを調べていたのか？私が使うとしたらどんなトリックがあるか考えました。もしかしてhandleOpsのfunction selectorを探しているのではないか？そこで、プロキシコントラクトを作成し、プロキシする前にfunction selectorを付加し、プロキシへのcalldataからfunction selectorを省略しました。すると、searcher Bは再びそれを拾えなくなりました。

   • しかし、これも数時間で修正されてしまいました。

今では、彼らはすべてのトランザクションのtraceを調べているか、私のすべてのアドレスをリスト化し、新しくデプロイするプロキシコントラクトや送信するトランザクションを監視しているのだと思います。
Searcher Bへ：おめでとうございます！あなたが勝ちました。 ぜひ連絡を取って、さらに話をしたいです。正直、このレベルでのスキルと時間を投資できるなら、もっと稼げる別のことをした方がいいはずです。PolygonでのUserOpsの数には上限があり、この戦略の総利益にも限界があります。
私自身、この時間を使って面接の準備をしっかりしていれば、大手トレーディングファームの最終面接に合格して、大きなサインオンボーナスを得られたかもしれません。それでも、この冒険は価値あるものでした😄。

この分野の今後の展望

• Porto by Ithica
  0xKofiに感謝！BundleBearはEIP-7702や4337の採用状況を追跡する素晴らしいリソースです。私は毎週チェックしていました。彼らの分析はコミュニティにとって今後も非常に役立つでしょう。
  0xKofiは2024年9月に4337 frontrunningについて素晴らしい記事を公開しました：https://web.archive.org/web/20241012214743/https://www.bundlebear.com/posts/polygon-mev
  ずっとあなたと話したかったです。Xで何度か返信しました😄

• FastLaneはfrontrunningがvalidatorの収益を生むことに気付き、frontrunningを止めるのではなく、誰でもbundleをfrontrunできるようにインフラを構築しました。彼らのPFLプロトコルにエンドポイントを追加し、bundler向けにrevert保護を提供しつつ、トランザクションを2ブロック遅らせて公開するspeedbumpを設けました。これにより、すべてのUserOpsが公開され、どのbundlerもfrontrunを試みることができ、validatorの収益を最大化しつつ、bundlerのrevert問題を解決します。

FastLaneのThogardがMEVと4337の交差点について語っています。ぜひ聞いてみてください：
#43 - Alex Watts: Reopening The Mempool: Disrupting Monopolized Private MEV Orderflow - Scraping Bits | Podcast on Spotify

• FastLaneは現在、Monad上でAAインフラに取り組んでいます。彼らのbundlerサービスと統合されたLSTがあります。こちらをチェックしてください：4337-bundler-paymaster-script

• Pimlicoはfrontrunning対策として以下の方法を試しました：

  • Polygonでプライベートリレーを探しましたが、proposer-builder-separation（PBS）がないため、ブロックビルダーにプライベートでトランザクションを送信する方法がありません。MerkleやBloxrouteを試しましたが、どちらも公開mempoolにブロードキャストするだけでした。
  • FastLaneの条件付きエンドポイントを使った実験も行いましたが、validatorのカバレッジが彼らのユースケースに十分でないことが分かりました。
  • 現在、良い解決策を見つけました！EntryPointがpaymasterデータを伴う場合、Paymasterコントラクトを呼び出し、EOAアドレスのチェックが行われます。これによりfrontrunningが防止され、試みてもrevertします。例はこちら：トランザクション例。
    

スマートウォレットが主流になれば、UserOpsはbundlerのgas feeの過払いだけでなく、さらに多くの種類のMEVを生み出すでしょう。例えば、DEXでの大規模なトレードやレンディングプロトコルでの過剰借入を行うUserOpを考えてみてください。bundlerはこれらのMEVを捕捉するよう進化する必要があるでしょうし、searcherはUserOps内の内部コールによるbackrunや清算を捕捉するよう進化するかもしれません。このオーダーフローは非常に価値のあるものになるでしょう。
この分野が進化するにつれて、新たな搾取の隙間や戦略の改良の余地が常に生まれます。手を汚す覚悟がある人には、mempoolには常に次のチャンスが待っています。