Це може бути суперечливим, але ваші транзакції повинні мати можливість дати відсіч шкідливим валідаторам. Я створив просту програму саме для цього. Під час виконання ви не можете знати, чи є прослизання природним рухом ринку чи сендвіч-атакою. Але якщо ваш своп потрапить на відомий шкідливий валідатор, ви практично гарантовано будете затиснуті до свого максимального прослизання. Це дає змогу дати відсіч. ✅ На довіреному валідаторі? Ваша транзакція протікає з бажаним прослизанням (x%). ❌ На шкідливому валідаторі? Прослизання вашої транзакції коригується (0%, деяка частка x%, все, що ви хочете) Замість того, щоб просто скасувати, ваша транзакція може бути успішною з більш жорсткими обмеженнями під час роботи в темному лісі. Коли ви створюєте та підписуєте свою транзакцію, ви не знаєте точно, на який валідатор вона потрапить, тому логіка, що зміни поведінки мають бути ончейн. Отже, як це працює? Програма Solana не може отримати доступ до поточного валідатора, але може отримати доступ до поточного слота. Програма приймає компактне представлення (14 байт, але може бути додатково зменшено), щоб дозволити програмі перевірити, чи не позначено лідер слота як шкідливий. Кілька способів його використання: (1) Ви можете вставити його безпосередньо як просту інструкцію (<260 CU, більша частина якої - це доступ до системи Clock). Скасовує весь tx, коли він потрапляє на шкідливий валідатор (2) Ви можете використовувати його для обгортання маршрутизатора Jupiter v6. Він викличе програму Jupiter і динамічно перевизначить значення «прослизання», але лише тоді, коли він працює на шкідливому валідаторі (3) Викличте його безпосередньо через CPI з вашої власної програми Список шкідливих валідаторів та їхні майбутні слоти можна отримати з нашого майбутнього API Sandwiched[dot]me або з ваших власних даних. Майте на увазі, що цей прототип є експериментальним. Він не розгортається в мережі. Буду радий отримати ваш відгук і PR вітається