Giới thiệu

Các sàn giao dịch phi tập trung (DEX) dựa vào dự trữ Token để xác định giá hoán đổi, cho phép giao dịch Không cần cho phép , nhưng cũng vô tình tạo ra cơ hội MEV. Vì kẻ tấn công có thể sắp xếp lại, chèn hoặc xóa các giao dịch xung quanh các giao dịch Sàn phi tập trung (DEX) , chúng có thể khai thác sự chênh lệch giá tạm thời để kiếm lời thông qua các cuộc tấn công chênh lệch giá hoặc tấn công xen kẽ.

Tại sao tìm kiếm MEV lại chậm như vậy hiện nay?

Tìm kiếm MEV là một vấn đề tối ưu hóa: với một mempool và một môi trường Sàn phi tập trung (DEX) , chúng ta muốn đánh giá hàng nghìn, đôi khi là hàng triệu gói giao dịch có thể có và chọn gói có lợi nhuận cao nhất.

Để chẩn đoán các điểm nghẽn, chúng tôi đã xem lại bảy ví dụ MEV về chênh lệch giá trong lịch sử (xem Phụ lục) bằng hai công cụ hiện đại:

• Foundry, Máy ảo Ethereum (EVM) phía CPU nhanh nhất trong Rust
• Lanturn, một công cụ tìm kiếm MEV trong TypeScrip

Môi trường:

• Intel i7
• RTX3090Ti 24G
• Ổ cứng thể rắn 1T
• Ubuntu 22.04

Chúng tôi đã chạy lại 1.000 lần cho mỗi công cụ và đo lường cách thời gian được phân chia thành ba giai đoạn chính:

1. Phân nhánh từ trạng thái mạng chính
2. Tạo các gói đầu vào
3. Thực hiện hợp đồng thông minh

hình ảnh 1542×618 56,9 KB

Phát hiện của chúng tôi phù hợp với nghiên cứu trước đây: việc tạo đầu vào khá đơn giản (<1%), nhưng việc thực thi Máy ảo Ethereum (EVM) và phân nhánh lại chiếm ưu thế về độ trễ đầu cuối. Foundry chi tiêu:

• 80,89% thời gian phân nhánh (27,87 ms)
• 18,82% khi thực hiện hoán đổi (6,49 ms)

Lanturn thậm chí còn hoạt động kém hơn: tốc độ thực thi Máy ảo Ethereum (EVM) chậm hơn 17,8 lần và tốc độ phân nhánh chậm hơn 1,98 lần so với Foundry, mặc dù có đa luồng.

Tóm Short: Tìm kiếm MEV bị giới hạn bởi tốc độ thực thi của CPU và CPU không thể khám phá không gian tìm kiếm đủ nhanh.

Biên dịch MEV Bot thành mã GPU

Để thoát khỏi tình trạng tắc nghẽn CPU này, chúng tôi sử dụng GPU:

1. Viết bot MEV trong Solidity (ví dụ: bộ định tuyến thực hiện phân xử đa bước nhảy)
2. Biên dịch hợp đồng thông minh sang LLVM IR bằng mau
3. Tạo mã PTX (lắp ráp CUDA) bằng cách sử dụng phần phụ trợ LLVM
4. Thực thi nó một cách tự nhiên trên Threads GPU

Đây là bot Solidity mà chúng tôi sử dụng làm ví dụ chạy thử. Trình xử lý dự phòng của nó sẽ phân tích cú pháp một định dạng byte nén mô tả các lần hoán đổi, xác định loại Sàn phi tập trung (DEX) và gọi hàm swap() chính xác:

 // 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);}}

Sau khi biên dịch sang PTX, bot này sẽ trở thành mã GPU thực thi. Thay vì đánh giá từng gói một như CPU, chúng tôi khởi chạy hàng chục nghìn Threads, mỗi luồng kiểm tra một gói ứng viên khác nhau.

Thuật toán di truyền song song: Tìm kiếm hàng nghìn bó cùng một lúc

Thuật toán di truyền song song (GA) được sử dụng để tìm kiếm các bó trên GPU. Mỗi luồng GPU đại diện cho một cá thể (tức là một bó) trong quần thể. Ở mỗi thế hệ, thuật toán thực hiện:

hình ảnh 1292×308 27,8 KB

1. Lựa chọn – chọn các gói lợi nhuận cao nhất
2. Sự giao thoa – kết hợp chúng lại thành các bó mới như con cái
3. Đột biến – điều chỉnh DEX, mã thông báo hoặc thứ tự để có được các gói mới dưới dạng bất biến
4. Đánh giá – chạy bot MEV với các gói bất biến trên GPU

Quy trình làm việc này cho phép chúng tôi khám phá không gian tìm kiếm rộng lớn cực kỳ nhanh chóng. Nhiều quần thể có thể được đánh giá đồng thời, cho phép phạm vi tìm kiếm rộng và sâu.

Kết quả hiệu suất

Bảng: Các cơ hội MEV mới được xác định trong các khối quý 1 năm 2025

Qua các thử nghiệm, chúng tôi đạt được 3,3 triệu–5,1 triệu Số lượng giao dịch trên mỗi giây, vượt trội hơn Lanturn khoảng 100.000 lần. Dựa trên dữ liệu thực tế từ quý 1 năm 2025, hệ thống đã phát hiện ra các cơ hội MEV trải dài từ 2 đến 14 giao dịch, mang lại lợi nhuận khai thác 1,1 triệu đô la.

Chi phí thời gian chạy: Nhẹ và ổn định

hình ảnh 680×498 40,4 KB

MEVISOR giới thiệu hai loại chi phí chung: chi phí khởi động nguội và chi phí chung cho mỗi lần tìm kiếm.

Tăng cường lạnh (một lần)

Trước khi tìm kiếm, GPU phải tải bot PTX và khởi tạo bộ nhớ.
Quá trình này mất 7,03 giây nhưng chỉ diễn ra một lần và được phân bổ cho tất cả các lần tìm kiếm trong tương lai.

Chi phí thời gian chạy

Chi phí thời gian chạy chính là tải ảnh chụp nhanh trạng thái Sàn phi tập trung (DEX) vào bộ nhớ GPU.

Khi chúng tôi mở rộng quy mô từ 64 lên 540 nhóm Sàn phi tập trung (DEX) :

• Độ trễ tải vẫn ổn định ở mức ~0,30 giây
• Sử dụng bộ nhớ GPU tăng tuyến tính (774 MB → 1,58 GB)

Ngay cả với hàng trăm DEX, MEVISOR vẫn nằm trong giới hạn VRAM của GPU thông thường và duy trì chi phí thấp, có thể dự đoán được.

Phụ lục

Ví dụ về động lực