Acest lucru ar putea fi controversat, dar tranzacțiile tale ar trebui să poată lupta împotriva validatorilor de sandwiching rău intenționați. Am construit un program simplu pentru a face exact asta. Nu puteți ști în timpul rulării dacă alunecarea este o mișcare naturală a pieței sau un atac sandwich. Dar dacă swap-ul tău aterizează pe un validator rău intenționat cunoscut, ești practic garantat că vei fi prins până la derapajul maxim. Acest lucru vă permite să ripostați. ✅ Pe un validator de încredere? Tranzacția se desfășoară cu derapajul dorit (x%). ❌ Pe un validator rău intenționat? Derapajul tranzacției tale este ajustat (0%, o fracțiune de x%, orice vrei) În loc să reveniți, tranzacția poate reuși cu constrângeri mai stricte atunci când rulează într-o pădure mai întunecată. Când creați și semnați tranzacția, nu știți exact pe ce validator va ateriza, așa că logica care schimbă comportamentul trebuie să fie onchain. Deci, cum funcționează? Un program Solana nu poate accesa validatorul curent, dar poate accesa slotul curent. Programul preia o reprezentare compactă (14 octeți, dar poate fi redusă și mai mult) pentru a permite programului să verifice dacă liderul slotului este marcat ca fiind rău intenționat. Câteva moduri de a-l folosi: (1) Îl puteți introduce direct ca o simplă instrucțiune (<260 CU, dintre care cea mai mare parte este accesarea sistemului Clock). Revine la întregul tx când aterizează pe un validator rău intenționat (2) Îl puteți folosi pentru a înfășura routerul Jupiter v6. Acesta va apela programul Jupiter și va suprascrie dinamic valoarea "slippage", dar numai atunci când rulează pe un validator rău intenționat (3) Sunați-l direct prin CPI din propriul program Lista de validatori rău intenționați și sloturile lor viitoare pot fi obținute din viitorul nostru API Sandwiched[dot]me sau din propriile date. Rețineți că acest prototip este experimental. Nu este implementat pe lanț. Mi-ar plăcea să primesc feedback-ul tău și PR-urile sunt binevenite