Bảo Vệ MEV với Jito DontFront

Maximal Extractable Value (MEV) đề cập đến giá trị có thể được thu lấy bằng cách sắp xếp lại, thêm vào, hoặc loại trừ các giao dịch trong một khối. MEV không phải là đặc thù của bất kỳ chuỗi nào; đây là thuộc tính cơ bản của bất kỳ blockchain nào mà người tạo khối kiểm soát thứ tự giao dịch. Một số dạng MEV, như kinh doanh chênh lệch giá, giúp thị trường hoạt động hiệu quả bằng cách điều chỉnh sự chênh lệch giá trên các DEX. Các dạng khác, như tấn công sandwich, trực tiếp rút giá trị 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 việc 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.

Đọc trước được khuyến nghị: Jito Bundles

MEV trên Solana

Kiến trúc của Solana đã giúp thu hẹp bề mặt tấn công MEV so với các chuỗi có mempool công khai. Các giao dịch được chuyển tiếp trực tiếp đến leader khối tiếp theo thay vì nằm trong một mempool chung, và các giao dịch chưa được xử lý hết hạn sau khoảng 150 khối (~1 phút). Điều này thu hẹp đáng kể khoảng thời gian để các searcher quan sát và hành động đối với 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 tối ưu 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à kinh doanh chênh lệch giá nguyên tử: các bot điều chỉnh sự chênh lệch giá giữa các DEX trong một giao dịch duy nhất. Loại MEV này nhìn chung 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ệ chống lại.

Tấn Công Sandwich Là Gì?

Tấn công sandwich xảy ra khi một searcher phát hiện giao dịch hoán đổi đang chờ 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 cao
2. Giao dịch của bạn được 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 kiếm 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ế: 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ó ở 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 chuỗi; nó không bao giờ được đọc hoặc ghi vào. 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ó phân giải được không. Đây là ví dụ về một địa chỉ không hợp lệ.

2. Thêm nó như một tài khoản chỉ đọc, không ký vào bất kỳ instruction nào trong giao dịch của bạn. Đánh dấu chỉ đọc để có tốc độ xác nhận tối ưu. 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 duy nhất đượ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 đều liên tiếp ở đầu bundle
2. Mỗi giao dịch dontfront chia sẻ ít nhất một người ký 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 MEV Protection trong cookbook.

TypeScript (@solana/kit)

Ý tưởng cốt lõi là một hàm trợ giúp 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 nút RPC tiêu chuẩn. Luôn sử dụng mã hóa base64. Base58 đã bị deprecated 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 giao dịch hoán đổi. 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 để tấn công sandwich.

• Đặt tip và phí ưu tiên phù hợp. Trong thời gian tắc nghẽn, tip và phí ưu tiên cao hơn sẽ tăng khả năng giao dịch/bundle của bạn được xác nhận nhanh chóng, thu hẹp cửa sổ để 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 việc sử dụng compute unit. Mỗi khối có số lượng compute unit giới hạn (và các tài khoản có số lượng compute unit giới hạn mỗi khối). Để đảm bảo khả năng giao dịch/bundle của bạn được đưa vào một khối là tối đa, bạn nên tối ưu hóa việc sử dụng compute unit. Xem hướng dẫn How to Optimize Compute Usage on 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 độ xác nhận.

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) cho phé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 qua một ALT. Nhưng không sử dụng ALT cho các tài khoản tip.

Hạn Chế

• 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 tấn công sandwich nhưng không được đảm bảo và không phải là giải pháp cho mọi biến thể trong việc sắp xếp thứ tự giao dịch, bao gồm bất kỳ sắp xếp nào được thực hiện bởi bên thứ ba."

• 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

• Jito Docs: Sandwich Mitigation
• Jito Docs: sendTransaction
• Jito Docs: sendBundle
• Jito Docs: Tip Accounts
• Jito Docs: Tip Amounts
• Tip Floor API
• @solana/kit on GitHub
• solana-sdk on crates.io