Bảo Vệ MEV với Jito DontFront

Maximal Extractable Value (MEV) đề cập đến giá trị có thể được thu thập bằng cách sắp xếp lại, đưa vào, hoặc loại trừ các giao dịch trong một block. MEV không chỉ xuất hiện trên một chain duy nhất; đây là thuộc tính cơ bản của bất kỳ blockchain nào mà nhà sản xuất block kiểm soát thứ tự giao dịch. Một số dạng MEV, như arbitrage, giúp duy trì thị trường hiệu quả bằng cách điều chỉnh chênh lệch giá giữa các DEX. Các dạng khác, như tấn công sandwich, trích xuất giá trị trực tiếp từ người dùng. Đối với các nhà phát triển xây dựng ứng dụng DeFi, điều này có thể dẫn đến thực thi giao dịch kém hơn và mất lợi nhuận.

Hướng dẫn này tập trung vào các cuộc tấn công sandwich, một dạng MEV có hại phổ biến, và cách giảm thiểu chúng bằng tính năng dontfront của Jito.

Tài liệu đọc trước được đề xuất: Jito Bundles

MEV trên Solana

Kiến trúc của Solana đã giảm thiểu đáng kể diện tích bề mặt MEV so với các chain có mempool công khai. Các giao dịch được chuyển tiếp trực tiếp đến leader block sắp tới thay vì nằm trong một mempool chia sẻ, và các giao dịch chưa được xử lý sẽ hết hạn sau khoảng 150 block (~1 phút). Điều này thu hẹp đáng kể cửa sổ thời gian để searcher quan sát và hành động dựa trên các giao dịch đang chờ xử lý.

Tuy nhiên, việc khai thác MEV vẫn xảy ra. Các searcher với cơ sở hạ tầng được tối ưu hóa và kết nối validator trực tiếp có thể quan sát luồng giao dịch và phản ứng với nó. Phần lớn hoạt động MEV trên Solana là arbitrage nguyên tử: các bot điều chỉnh chênh lệch giá giữa các DEX trong một giao dịch duy nhất. Loại MEV này thường có lợi vì nó cải thiện tính nhất quán về giá trên các thị trường.

Loại có hại, tấn công sandwich, là điều mà các nhà phát triển cần chủ động bảo vệ.

Tấn Công Sandwich là gì?

Một cuộc tấn công sandwich xảy ra khi một searcher phát hiện lệnh swap đang chờ xử lý của bạn và khai thác thứ tự giao dịch:

1. Front-run: searcher mua token trước giao dịch của bạn, đẩy giá lên
2. Giao dịch của bạn thực thi ở mức giá tệ hơn dự kiến
3. Back-run: searcher bán token sau giao dịch của bạn, bỏ túi phần chênh lệch

Trên Solana, điều này có thể xảy ra thông qua Jito bundles. Một searcher gửi một bundle giao dịch như: [frontrun_tx, your_tx, backrun_tx], và block engine thực thi chúng nguyên tử theo thứ tự. Nạn nhân nhận được giá thực thi tệ hơn trong khi searcher hưởng lợi từ phần chênh lệch.

Cách DontFront Hoạt Động

DontFront là một tính năng của Jito block engine ngăn searcher đặt các giao dịch trước giao dịch của bạn trong một bundle.

Cơ chế hoạt động: thêm bất kỳ public key Solana hợp lệ nào bắt đầu bằng jitodontfront vào bất kỳ instruction nào trong giao dịch của bạn. Block engine nhận ra tiền tố này và thực thi một quy tắc: bất kỳ bundle nào chứa giao dịch của bạn phải đặt nó ở vị trí index 0.

Without dontfront:  [frontrun_tx, your_tx, backrun_tx]  ← sandwich possible
With dontfront:     [your_tx, ...]                       ← your tx must be first

Từng Bước Thực Hiện

1. Chọn một địa chỉ hợp lệ bắt đầu bằng jitodontfront (ví dụ: jitodontfront111111111111111111111111111111). Tài khoản không cần tồn tại trên chain; nó không bao giờ được đọc hoặc ghi. Bạn có thể xác minh một chuỗi là địa chỉ hợp lệ bằng cách sử dụng hàm assertIsAddress từ @solana/kit hoặc bạn có thể nhập địa chỉ vào Solana Explorer để xem nó có được phân giải không. Đây là ví dụ về một địa chỉ không hợp lệ.

2. Thêm nó làm tài khoản chỉ đọc, không phải signer vào bất kỳ instruction nào trong giao dịch của bạn. Đánh dấu chỉ đọc để tối ưu tốc độ landing. Hầu hết các chương trình (bao gồm cả System Program) bỏ qua các tài khoản thêm ngoài những gì chúng mong đợi.

3. Gửi qua Jito block engine:

   • sendTransaction: https://mainnet.block-engine.jito.wtf/api/v1/transactions
   • sendBundle: https://mainnet.block-engine.jito.wtf/api/v1/bundles

   Tài liệu: sendTransaction và sendBundle

4. Block engine phát hiện tiền tố jitodontfront và thực thi các quy tắc sắp xếp.

Điều Gì Xảy Ra tại Block Engine

Khi block engine thấy một giao dịch chứa tài khoản jitodontfront:

• Qua sendTransaction: giao dịch được bảo vệ. Không có bundle nào có thể đặt một giao dịch khác trước nó
• Qua sendBundle: giao dịch phải xuất hiện ở index 0, nếu không toàn bộ bundle sẽ bị từ chối

Các giao dịch và bundle không chứa tài khoản jitodontfront thì không bị ảnh hưởng.

Quy Tắc Sắp Xếp Bundle

Các quy tắc này áp dụng khi một giao dịch jitodontfront xuất hiện trong một bundle.

Các Mẫu Được Cho Phép

[tx_with_dontfront, tip]
[tx_with_dontfront, arbitrage, tip]
[tx_with_dontfront_signer1, tx_with_dontfront_signer1_and_signer2, tip]

Nhiều Giao Dịch DontFront trong Một Bundle

Nhiều giao dịch dontfront trong một bundle đều được cho phép khi cả hai điều kiện đều được đáp ứng:

1. Tất cả các giao dịch dontfront liền kề ở đầu của bundle
2. Mỗi giao dịch dontfront chia sẻ ít nhất một signer với giao dịch dontfront đầu tiên

✅ [txA_df, txB_df, txC_df, arbitrage, tip]
   (contiguous at front, overlapping signers)

✅ [txA_df_signer1_signer2, txB_df_signer1_signer3, txC_df_signer2_signer4]
   (each shares a signer with txA)

Các Mẫu Bị Từ Chối

❌ [tip, tx_with_dontfront]
   → dontfront tx is not at index 0

❌ [txA_df_signer1, txB_df_signer2]
   → no overlapping signer between txA and txB

❌ [trade, tx_with_dontfront, arbitrage, tip]
   → dontfront tx is not at the front

Ví Dụ Tích Hợp

Để có công thức code nhanh, hãy xem mục cookbook về Bảo Vệ MEV.

TypeScript (@solana/kit)

Ý tưởng cốt lõi là một helper thêm tài khoản dontfront vào bất kỳ instruction nào:

import {
  address,
  AccountRole,
  type Instruction,
  type Address
} from "@solana/kit";

const DONT_FRONT: Address = address(
  "jitodontfront111111111111111111111111111111"
);

function withDontFront(ix: Instruction): Instruction {
  return {
    ...ix,
    accounts: [
      ...(ix.accounts ?? []),
      { address: DONT_FRONT, role: AccountRole.READONLY }
    ]
  };
}

Sau đó gửi giao dịch đã ký đến Jito block engine thay vì một node RPC thông thường. Luôn sử dụng mã hóa base64. Base58 đã bị ngừng sử dụng trong API của Jito.

const response = await fetch(
  "https://mainnet.block-engine.jito.wtf/api/v1/transactions",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "sendTransaction",
      params: [base64Tx, { encoding: "base64" }]
    })
  }
);

Các Thực Hành Tốt Nhất

DontFront là một lớp bảo vệ. Một chiến lược giảm thiểu MEV toàn diện kết hợp nhiều phương pháp tiếp cận:

Bảo Vệ Ở Cấp Độ Giao Dịch

• Đặt ngưỡng slippage chặt chẽ. Biện pháp phòng thủ hiệu quả nhất chống lại các cuộc tấn công sandwich là giới hạn slippage chấp nhận được trên các lệnh swap. Cửa sổ slippage nhỏ hơn làm giảm biên lợi nhuận có sẵn cho kẻ tấn công, khiến giao dịch của bạn kém hấp dẫn hơn để sandwich.

• Đặt tip và phí ưu tiên phù hợp. Trong thời điểm tắc nghẽn, tip và phí ưu tiên cao hơn làm tăng khả năng giao dịch/bundle của bạn được xử lý nhanh chóng, thu hẹp cửa sổ thời gian để searcher hành động. Xem tài liệu của Jito về Tip Amounts để biết thêm chi tiết về cách đặt tip phù hợp.

• Tối ưu hóa mức sử dụng compute unit. Mỗi block có một số lượng compute unit hạn chế (và các tài khoản có số lượng compute unit hạn chế cho mỗi block). Để tối đa hóa khả năng giao dịch/bundle của bạn được đưa vào một block, bạn nên tối ưu hóa mức sử dụng compute unit. Xem hướng dẫn Cách Tối Ưu Hóa Sử Dụng Compute trên Solana để biết chi tiết.

Dành Riêng cho DontFront

1. Đánh dấu tài khoản dontfront là chỉ đọc. Đánh dấu có thể ghi vẫn hoạt động nhưng chỉ đọc tối ưu hóa tốc độ landing.

2. Sử dụng một pubkey dontfront duy nhất cho mỗi ứng dụng. Bất kỳ pubkey nào bắt đầu bằng jitodontfront đều hoạt động. Sử dụng một biến thể duy nhất (ví dụ: jitodontfront111111111111111111111111111123) giúp bạn phân biệt mức sử dụng theo từng ứng dụng khi kiểm tra dữ liệu onchain.

3. DontFront hỗ trợ Address Lookup Tables. Tài khoản dontfront có thể được đưa vào thông qua một ALT. Nhưng không sử dụng ALT cho các tài khoản tip.

Giới Hạn

• Chỉ dành cho block engine. DontFront được thực thi bởi Jito block engine. Các giao dịch gửi trực tiếp đến validator (bỏ qua Jito) không được bảo vệ.

• Không phải đảm bảo tuyệt đối. Từ tài liệu của Jito: "Tính năng này có thể giúp giảm thiểu tấn công sandwich nhưng không được đảm bảo làm như vậy và không phải là giải pháp cho tất cả các biến thể trong thứ tự giao dịch, bao gồm bất kỳ thứ tự nào do bên thứ ba thực hiện."

• Chỉ dành cho Mainnet/Testnet. Đây là tính năng của Jito block engine. Nó không hoạt động trên devnet hoặc localhost.

Tài Liệu Tham Khảo

• Tài liệu Jito: Sandwich Mitigation
• Tài liệu Jito: sendTransaction
• Tài liệu Jito: sendBundle
• Tài liệu Jito: Tip Accounts
• Tài liệu Jito: Tip Amounts
• Tip Floor API
• @solana/kit trên GitHub
• solana-sdk trên crates.io