介紹

去中心化交易所 (DEX) 依靠代幣儲備來確定交易價格，從而實現無需許可的交易，但也無意中引入了市場漏洞利用 (MEV) 的機會。由於攻擊者可以重新排序、插入或刪除 DEX 交易周圍的交易，他們可以利用暫時的價格差異，透過套利或夾心攻擊來牟利。

為什麼如今MEV搜尋速度如此緩慢？

MEV 搜尋是一個最佳化問題：給定一個記憶體池和一個 DEX 環境，我們希望評估成千上萬，有時甚至是數百萬個可能的交易包，並選擇最有利可圖的交易包。

為了診斷瓶頸，我們使用兩種最先進的工具重現了七個歷史套利 MEV 範例（見附錄）：

• Foundry 是 Rust 中最快的 CPU 端 EVM。
• Lanturn，一個用 TypeScript 寫的 MEV 搜尋器。

環境：

• 英特爾 i7
• RTX3090Ti 24G
• 1T固態硬碟
• Ubuntu 22.04

我們對每種工具進行了 1000 次回放，並測量了時間在三個主要階段的分配情況：

1. 從主網態分叉
2. 產生輸入包
3. 執行智能合約

圖片尺寸：1542×618，大小：56.9 KB

我們的研究結果與先前的研究相符：輸入產生過程微不足道（<1%），但EVM執行和分支過程才是端到端延遲的主要來源。代工廠支出：

• 80.89%的時間用於分叉（27.87 毫秒）
• 執行交換操作耗時18.82% （6.49 毫秒）

Lanturn 的效能較差：儘管採用了多執行緒技術，但其 EVM 執行速度比 Foundry慢 17.8 倍，分叉速度慢 1.98 倍。

簡而言之：MEV 搜尋受限於 CPU 執行速度，而 CPU 根本無法快速探索搜尋空間。

將 MEV Bot 編譯為 GPU 程式碼

為了突破 CPU 瓶頸，我們使用 GPU：

1. 用 Solidity 編寫 MEV 機器人（例如，執行多跳套利的路由器）。
2. 使用mau將智能合約編譯為 LLVM IR。
3. 使用LLVM 後端產生 PTX 程式碼（CUDA 彙編）
4. 在 GPU 執行緒上原生執行

這是我們用作運行範例的 Solidity 機器人。它的備用處理程序會解析描述交換的壓縮位元組格式，確定 DEX 類型，並呼叫正確的swap()函數：

 // SPDX-License-Identifier: UNLICENSEDpragma solidity 0.7.6;import "./libraries/uniswapv2/UniswapV2Pair.sol";import "./libraries/uniswapv3/UniswapV3Pair.sol";import "./libraries/sushiswap/SushiswapPair.sol";import "./libraries/pancakeswap/PancakeswapPair.sol";contract MEV {fallback(bytes calldata data) external payable returns (bytes memory) {uint256 amount = abi.decode(data[:32], (uint256));uint32 swap_len = uint32(abi.decode(data[32:], (bytes4)));uint32[] memory swap_vec = new uint32[](swap_len);uint32[] memory token_vec = new uint32[](swap_len);uint32 calldata_size = uint32(data.length);uint32 swaps_buf_size = (calldata_size - 32 - 4) / 2;for (uint32 i = 0; i < swap_len; i++) {swap_vec[i] = uint32(abi.decode(data[36 + i * 4:], (bytes4)));uint256 token_word = abi.decode(data[36 + swaps_buf_size + 32 * (i / 8):], (uint256));token_vec[i] = uint32(token_word >> (256 - 32 * (i % 8 + 1)));}for (uint32 i = 0; i < swap_len; i++) {bool reversed = token_vec[i] > token_vec[(i + 1) % swap_len];uint32 swap_u32 = swap_vec[i];uint8 dex_type = uint8(swap_u32 >> 24);address dex = address(swap_u32 & 0xFFFFFF);if (dex_type == 1) {amount = UniswapV2Pair(dex).swap(reversed, amount);} else if (dex_type == 2) {amount = UniswapV3Pair(dex).swap(reversed, amount)} else if (dex_type == 3) {amount = SushiswapPair(dex).swap(reversed, amount);} else if (dex_type == 4) {amount = PancakeswapPair(dex).swap(reversed, amount);} else if (dex_type == 5) {continue;}}return abi.encodePacked(amount);}}

編譯成 PTX 格式後，機器人就變成了可執行的 GPU 程式碼。與 CPU 一次評估一個軟體包不同，我們會啟動數萬個線程，每個線程測試一個不同的候選軟體包。

平行遺傳演算法：同時搜尋數千個捆綁包

平行遺傳演算法 (GA) 用於在 GPU 上搜尋捆綁包。每個 GPU 執行緒代表族群中的一個個體（即一個捆綁包）。在每一代中，演算法執行以下操作：

圖片尺寸：1292×308，大小：27.8 KB

1. 選擇－選擇利潤最高的套餐
2. 交叉－將它們重新組合成新的子代基因組
3. 變異－調整去中心化交易所、代幣或排序方式，以獲得新的捆綁包作為不變式。
4. 評估－在GPU上運行有不變束的MEV機器人

這種工作流程使我們能夠以極快的速度探索廣闊的搜尋空間。它可以同時評估多個種群，從而實現廣泛而深入的搜尋覆蓋。

績效結果

表格：2025 年第一季確定的新 MEV 機遇

在各項實驗中，我們實現了每秒 330 萬至 510 萬筆交易的處理速度，比 Lanturn 的效能高出約 10 萬倍。基於 2025 年第一季的真實數據，該系統發現了 2 至 14 筆交易的 MEV 機會，可提取利潤達 110 萬美元。

運轉時開銷：輕量級且穩定

圖片尺寸：680×498，大小：40.4 KB

MEVISOR 引入了兩種類型的開銷：冷啟動開銷和每次搜尋開銷。

冷啟動（一次性）

搜尋之前，GPU 必須載入 PTX 機器人並初始化記憶體。
這需要 7.03 秒，但只會發生一次，並且會在以後的所有搜尋中分攤。

運行時開銷

主要的運行時開銷是將 DEX 狀態快照載入到 GPU 記憶體中。

隨著我們將 DEX 池從 64 個擴展到 540 個：

• 載入延遲穩定在約 0.30 秒。
• GPU記憶體使用量線性成長（774 MB → 1.58 GB）

即使有數百個 DEX，MEVISOR 也能輕鬆保持在普通 GPU 的 VRAM 限制以下，並保持低、可預測的開銷。

附錄

動機範例