Sandwich Attack Anatomy — Từ Mempool đến Execution

Trước khi hiểu sandwich attack, cần hiểu mempool (memory pool). Khi bạn submit một transaction trên Ethereum, nó không đi thẳng vào blockchain ngay lập tức. Nó được broadcast đến tất cả Ethereum node và nằm trong một hàng đợi gọi là mempool — chờ được validator chọn vào block tiếp theo.

Điểm quan trọng: mempool là public. Bất kỳ ai kết nối đến Ethereum node đều có thể xem tất cả pending transaction đang chờ — bao gồm thông tin về: địa chỉ gửi, địa chỉ nhận (contract), data của transaction (bao gồm swap amount và slippage tolerance), và gas price đặt. Đây chính là information mà sandwich bot khai thác.

Latency race trong mempool

MEV searcher đầu tư rất nhiều vào infrastructure để giảm latency: collocate server với Ethereum node lớn, dùng WebSocket subscription thay HTTP polling, optimize code để decision time dưới 1ms. Khi bạn submit transaction, bot có thể phát hiện và phân tích nó trong vòng 5–10ms — trước khi block mới được đào.

Dưới đây là cơ chế kỹ thuật đầy đủ của một sandwich attack điển hình trên Uniswap V2. Xem thêm: dữ liệu thực từ EigenPhi.

Tại sao thứ tự trong block có thể bị sắp xếp

Ethereum validator (người tạo block) có quyền chọn và sắp xếp bất kỳ transaction nào trong mempool vào block. Transaction có priority fee cao hơn thường được chọn trước — đây là cơ chế hợp lệ của protocol. Bot sandwich lợi dụng điều này bằng cách set priority fee cho front-run transaction cao hơn victim transaction một chút, đảm bảo execute trước.

Calldata decoding — Bot đọc swap của bạn thế nào

Khi bạn swap trên Uniswap, transaction data của bạn chứa calldata — encoded function call với các tham số: token path, amountIn, amountOutMin (minimum token nhận). AmountOutMin phản ánh trực tiếp slippage tolerance bạn set. Bot decode calldata để biết chính xác bạn sẵn sàng chịu slippage bao nhiêu — từ đó tính maximum front-run size mà vẫn để transaction của bạn pass.

Bot chỉ sandwich khi lợi nhuận dự kiến vượt gas cost. Hiểu logic này giúp bạn cài đặt slippage đúng để tránh bị target.

Ví dụ tính toán thực tế

Giả sử bạn swap $1,000 ETH → MEME với slippage 3% trên pool có $50,000 liquidity. Bot estimate: front-run $2,000 sẽ đẩy giá lên ~2.5%. Sau khi bạn swap, bot back-run và thu ~2.5% × $2,000 = $50 gross profit. Gas cost: 2 transaction × $15 = $30. Net profit: $20 — profitable, bot sandwich bạn.

Cùng scenario nhưng slippage của bạn là 0.5%: bot chỉ có thể front-run tối đa để giá tăng 0.5% — tức front-run nhỏ hơn, gross profit chỉ ~$10. Sau gas $30 → net profit âm → bot bỏ qua.

Bảng ước tính dựa trên gas cost ~$20–30/sandwich tại Ethereum mainnet. Thay đổi theo điều kiện thực tế.

Nếu bạn nghi ngờ đã bị sandwich, có thể xác nhận trực tiếp trên chain trong vài phút.

Bước 1: Kiểm tra execution price

So sánh quoted price lúc bạn confirm swap với execution price thực tế trong transaction receipt. Nếu bạn nhận token ít hơn đáng kể so với amount tối thiểu (gần đến amountOutMin), đây là dấu hiệu đầu tiên. Xem trên Etherscan: vào transaction hash → Token Transfers tab → xem chính xác bạn nhận bao nhiêu.

Bước 2: Xem block context

Từ transaction hash của bạn, click vào block number. Xem tất cả transaction trong block đó và tìm transaction trong cùng pool (same contract address) ngay trước và ngay sau tx của bạn. Nếu cả hai đến từ cùng một address (thường là smart contract) → bạn đã bị sandwich.

Bước 3: Dùng EigenPhi để xác nhận

Paste transaction hash vào EigenPhi.io — tool tự động phát hiện và visualize sandwich attack. Nó sẽ cho bạn thấy chính xác: bot address, profit của bot, và bạn mất bao nhiêu so với fair execution.

Tại sao Uniswap V2 dễ bị sandwich nhất

V2 dùng công thức x·y = k đơn giản — bot có thể tính chính xác price impact của mọi swap chỉ với hai số: reserve_x và reserve_y, đều public on-chain. Simulation của bot chỉ mất vài microsecond. V3 với concentrated liquidity phức tạp hơn vì price impact phụ thuộc vào vị trí giá hiện tại trong tick range, và có thể cross nhiều tick — simulation đòi hỏi nhiều computation hơn và có uncertainty cao hơn, làm giảm số bot sandwich profitable.

Cách 1: Giảm Slippage Tolerance (hiệu quả nhất)

Set slippage 0.5–1% thay vì default 3–5%. Với token stable hoặc high-liquidity, 0.5% đủ và transaction sẽ không fail. Với meme coin volatile, set 1% và retry nếu fail — vẫn tốt hơn bị sandwich nhiều lần. Chỉ tăng slippage khi thực sự cần thiết và làm từng bước nhỏ.

Cách 2: Flashbots Protect RPC

Đây là biện pháp kỹ thuật mạnh nhất. Transaction bypass public mempool hoàn toàn — bot không thể thấy nó trước khi include vào block. Setup MetaMask: Settings → Networks → Add Network → RPC URL: https://rpc.flashbots.net, Chain ID: 1. Hoặc dùng protect.flashbots.net để thêm tự động.

Cách 3: Dùng CoW Protocol (Coincidence of Wants)

CoW Protocol (cow.fi) dùng intent-based settlement — bạn sign một "intent to trade" thay vì transaction trực tiếp. Solver tìm counterparty phù hợp trước khi settle on-chain. Vì không có on-chain transaction cho đến khi match được tìm thấy, bot sandwich không có gì để front-run. CoW thường cho execution price tốt hơn cả Uniswap trực tiếp.

Cách 4: Private Transaction (MEV Blocker)

MEV Blocker là RPC tương tự Flashbots Protect nhưng thêm tính năng: nó broadcast transaction đến nhiều block builder đồng thời và chọn builder offer execution tốt nhất. Setup tương tự — thêm custom RPC vào MetaMask.