Điều này có thể gây tranh cãi, nhưng các giao dịch của bạn nên có khả năng chống lại các validator sandwich độc hại. Tôi đã xây dựng một chương trình đơn giản để làm điều đó. Bạn không thể biết trong thời gian thực liệu sự trượt giá là do biến động thị trường tự nhiên hay là một cuộc tấn công sandwich. Nhưng nếu giao dịch của bạn rơi vào một validator độc hại đã biết, bạn gần như chắc chắn sẽ bị sandwich đến mức trượt giá tối đa của bạn. Điều này cho phép bạn chống lại. ✅ Trên một validator đáng tin cậy? Giao dịch của bạn sẽ tiếp tục với mức trượt giá mong muốn của bạn (x%). ❌ Trên một validator độc hại? Mức trượt giá của giao dịch của bạn sẽ được điều chỉnh (0%, một phần nhỏ của x%, bất cứ điều gì bạn muốn) Thay vì chỉ hoàn tác, giao dịch của bạn có thể thành công với các ràng buộc chặt chẽ hơn khi hoạt động trong một khu rừng tối tăm hơn. Khi bạn tạo và ký giao dịch của mình, bạn không biết chính xác validator nào mà nó sẽ rơi vào, vì vậy logic thay đổi hành vi phải được thực hiện trên chuỗi. Vậy nó hoạt động như thế nào? Một chương trình Solana không thể truy cập validator hiện tại, nhưng nó có thể truy cập slot hiện tại. Chương trình nhận vào một đại diện gọn nhẹ (14 byte nhưng có thể giảm thêm) để cho phép chương trình kiểm tra xem người lãnh đạo của slot có bị đánh dấu là độc hại hay không. Một vài cách để sử dụng nó: (1) Bạn có thể chèn nó trực tiếp như một lệnh đơn giản (<260 CU, hầu hết là truy cập sysvar Clock). Hoàn tác toàn bộ giao dịch khi nó rơi vào một validator độc hại. (2) Bạn có thể sử dụng nó để bọc router Jupiter v6. Nó sẽ gọi chương trình Jupiter và động động ghi đè giá trị `slippage` nhưng chỉ khi nó chạy trên một validator độc hại. (3) Gọi nó trực tiếp qua CPI từ chương trình của riêng bạn. Danh sách các validator độc hại và các slot sắp tới của họ có thể được lấy từ API Sandwiched[dot]me sắp tới của chúng tôi hoặc từ dữ liệu của riêng bạn. Hãy nhớ rằng nguyên mẫu này là thử nghiệm. Nó chưa được triển khai trên chuỗi. Rất mong nhận được phản hồi của bạn và các PR luôn được chào đón.