To może być kontrowersyjne, ale twoje transakcje powinny być w stanie bronić się przed złośliwymi walidatorami sandwiching. Zbudowałem prosty program, który robi dokładnie to. Nie możesz wiedzieć w czasie rzeczywistym, czy slippage to naturalny ruch rynkowy, czy atak sandwich. Ale jeśli twoja wymiana trafi na znanego złośliwego walidatora, praktycznie gwarantujesz sobie, że zostaniesz zsandwiched do maksymalnego slippage. To pozwala ci się bronić. ✅ Na zaufanym walidatorze? Twoja transakcja przebiega z pożądanym slippage (x%). ❌ Na złośliwym walidatorze? Slippage twojej transakcji jest dostosowywany (0%, jakaś frakcja x%, cokolwiek chcesz) Zamiast po prostu cofać, twoja transakcja może zakończyć się sukcesem z ściślejszymi ograniczeniami, gdy działa w ciemniejszym lesie. Kiedy tworzysz i podpisujesz swoją transakcję, nie wiesz dokładnie, na którym walidatorze wyląduje, więc logika zmieniająca zachowanie musi być on-chain. Jak to działa? Program Solana nie może uzyskać dostępu do aktualnego walidatora, ale może uzyskać dostęp do aktualnego slotu. Program przyjmuje skompaktowaną reprezentację (14 bajtów, ale można ją jeszcze bardziej zredukować), aby umożliwić programowi sprawdzenie, czy lider slotu jest oznaczony jako złośliwy. Kilka sposobów na jego użycie: (1) Możesz go wstawić bezpośrednio jako prostą instrukcję (<260 CU, z czego większość to dostęp do sysvar Clock). Cofnie całą transakcję, gdy wyląduje na złośliwym walidatorze. (2) Możesz go użyć do owinięcia routera Jupiter v6. Wywoła program Jupiter i dynamicznie nadpisze wartość `slippage`, ale tylko wtedy, gdy działa na złośliwym walidatorze. (3) Wywołaj go bezpośrednio za pomocą CPI z własnego programu. Lista złośliwych walidatorów i ich nadchodzących slotów może być pozyskiwana z naszego nadchodzącego API Sandwiched[dot]me lub z własnych danych. Pamiętaj, że ten prototyp jest eksperymentalny. Nie jest wdrożony on-chain. Chciałbym poznać twoje opinie, a PR-y są mile widziane.