Dette kan være kontroversielt, men transaksjonene dine bør kunne slå tilbake mot ondsinnede sandwich-validatorer. Jeg bygde et enkelt program for å gjøre akkurat det. Du kan ikke vite på kjøretid om glidning er naturlig markedsbevegelse eller et sandwichangrep. Men hvis byttet ditt lander på en kjent ondsinnet validator, er du praktisk talt garantert å bli klemt opp til maksimal glidning. Dette lar deg slå tilbake. ✅ På en klarert validator? Transaksjonen fortsetter med ønsket glidning (x%). ❌ På en ondsinnet validator? Transaksjonens glidning justeres (0 %, en brøkdel av x%, alt du vil) I stedet for bare å gå tilbake, kan transaksjonen din lykkes med strammere begrensninger når du kjører i en mørkere skog. Når du oppretter og signerer transaksjonen din, vet du ikke nøyaktig hvilken validator den vil lande på, så logikk at endringsatferd må være på kjeden. Så hvordan fungerer det? Et Solana-program kan ikke få tilgang til gjeldende validator, men det kan få tilgang til gjeldende spor. Programmet tar inn en kompakt representasjon (14 byte, men kan reduseres ytterligere) for å la programmet sjekke om sporets leder er flagget som ondsinnet. Noen måter å bruke det på: (1) Du kan sette den inn direkte som en enkel instruksjon (<260 CU, hvorav det meste er tilgang til klokkesysvaret). Tilbakestiller hele tx når den lander på en ondsinnet validator (2) Du kan bruke den til å pakke inn Jupiter v6-ruteren. Den vil kalle Jupiter-programmet og dynamisk overstyre 'glidning'-verdien, men bare når den kjører på en ondsinnet validator (3) Kall det direkte via KPI fra ditt eget program Listen over ondsinnede validatorer og deres kommende spilleautomater kan hentes fra vår kommende Sandwiched[dot]me API eller fra dine egne data. Husk at denne prototypen er eksperimentell. Den distribueres ikke på kjeden. Vil gjerne ha tilbakemeldinger og PR-er er velkomne