MEV-bescherming met Jito DontFront

Maximale Extraheerbare Waarde (MEV) verwijst naar de waarde die kan worden verkregen door transacties binnen een block te herordenen, op te nemen of uit te sluiten. MEV is niet uniek voor één chain; het is een fundamentele eigenschap van elke blockchain waarbij blockproducenten de transactievolgorde bepalen. Sommige vormen van MEV, zoals arbitrage, houden markten efficiënt door prijsverschillen tussen DEX's te corrigeren. Andere vormen, zoals sandwich-aanvallen, onttrekken waarde rechtstreeks aan gebruikers. Voor ontwikkelaars die DeFi-applicaties bouwen, kan dit resulteren in slechtere handelsuitvoering en gederfde winsten.

Deze gids richt zich op sandwich-aanvallen, een veelvoorkomende vorm van schadelijke MEV, en hoe deze te beperken met behulp van Jito's dontfront-functie.

Aanbevolen voorbereidende lectuur: Jito Bundles

MEV op Solana

De architectuur van Solana verkleint het MEV-oppervlak al in vergelijking met chains met publieke mempools. Transacties worden rechtstreeks doorgestuurd naar de aankomende block leider in plaats van in een gedeelde mempool te blijven staan, en onverwerkte transacties vervallen na ongeveer 150 blocks (~1 minuut). Dit verkleint het tijdvenster voor searchers aanzienlijk om in behandeling zijnde transacties te observeren en hierop te reageren.

Desondanks vindt MEV-extractie nog steeds plaats. Searchers met geoptimaliseerde infrastructuur en directe validator-verbindingen kunnen transactiestromen observeren en hierop reageren. Veel MEV-activiteit op Solana bestaat uit atomaire arbitrage: bots die prijsverschillen tussen DEX's corrigeren in één enkele transactie. Dit type MEV is over het algemeen voordelig, omdat het de prijsconsistentie tussen markten verbetert.

De schadelijke variant, sandwich-aanvallen, is waartegen ontwikkelaars zich actief moeten beschermen.

Wat is een Sandwich-aanval?

Een sandwich-aanval treedt op wanneer een searcher je aanstaande swap detecteert en misbruik maakt van de transactievolgorde:

1. Front-run: de searcher koopt het token vóór jouw trade, waardoor de prijs omhoog wordt gedreven
2. Jouw trade wordt uitgevoerd tegen een slechtere prijs dan verwacht
3. Back-run: de searcher verkoopt het token na jouw trade en strijkt het verschil op

Op Solana kan dit plaatsvinden via Jito-bundles. Een searcher dient een bundel transacties in zoals: [frontrun_tx, your_tx, backrun_tx], en de block engine voert deze atomisch in volgorde uit. Het slachtoffer krijgt een slechtere uitvoerprijs terwijl de searcher winst maakt op de spread.

Hoe DontFront Werkt

DontFront is een functie van de Jito block engine die voorkomt dat searchers transacties vóór die van jou in een bundel plaatsen.

Het mechanisme: voeg een geldig Solana-publieksleutel toe dat begint met jitodontfront aan een willekeurige instructie in je transactie. De block engine herkent dit voorvoegsel en handhaaft een regel: elke bundel die jouw transactie bevat, moet deze op index 0 plaatsen.

Without dontfront:  [frontrun_tx, your_tx, backrun_tx]  ← sandwich possible
With dontfront:     [your_tx, ...]                       ← your tx must be first

Stap voor Stap

1. Kies een geldig adres dat begint met jitodontfront (bijv. jitodontfront111111111111111111111111111111). Het account hoeft niet onchain te bestaan; het wordt nooit gelezen of beschreven. Je kunt verifiëren of een string een geldig adres is met behulp van de assertIsAddress-functie van @solana/kit, of je kunt het adres invoeren in Solana Explorer om te controleren of het wordt opgelost. Hier is een voorbeeld van een ongeldig adres.

2. Voeg het toe als een alleen-lezen, niet-ondertekend account aan een willekeurige instructie in je transactie. Markeer het als alleen-lezen voor optimale landingssnelheid. De meeste programma's (inclusief het System Program) negeren extra accounts buiten wat ze verwachten.

3. Dien in via de Jito block engine:

   • sendTransaction: https://mainnet.block-engine.jito.wtf/api/v1/transactions
   • sendBundle: https://mainnet.block-engine.jito.wtf/api/v1/bundles

   Documentatie: sendTransaction en sendBundle

4. De block engine detecteert het jitodontfront-voorvoegsel en handhaaft de volgordeRegels.

Wat er Gebeurt bij de Block Engine

Wanneer de block engine een transactie ziet die een jitodontfront-account bevat:

• Via sendTransaction: de transactie is beschermd. Geen enkele bundel kan een andere transactie ervóór plaatsen
• Via sendBundle: de transactie moet op index 0 staan, anders wordt de volledige bundel afgewezen

Transacties en bundels die geen jitodontfront-account bevatten, worden niet beïnvloed.

Bundelvolgorderegels

Deze regels zijn van toepassing wanneer een jitodontfront-transactie in een bundel voorkomt.

Toegestane Patronen

[tx_with_dontfront, tip]
[tx_with_dontfront, arbitrage, tip]
[tx_with_dontfront_signer1, tx_with_dontfront_signer1_and_signer2, tip]

Meerdere DontFront-transacties in Één Bundel

Meerdere dontfront-transacties in één bundel zijn toegestaan wanneer aan beide voorwaarden is voldaan:

1. Alle dontfront-transacties staan aaneengesloten aan het begin van de bundel
2. Elke dontfront-transactie deelt ten minste één ondertekenaar met de eerste dontfront-transactie

✅ [txA_df, txB_df, txC_df, arbitrage, tip]
   (contiguous at front, overlapping signers)

✅ [txA_df_signer1_signer2, txB_df_signer1_signer3, txC_df_signer2_signer4]
   (each shares a signer with txA)

Afgewezen Patronen

❌ [tip, tx_with_dontfront]
   → dontfront tx is not at index 0

❌ [txA_df_signer1, txB_df_signer2]
   → no overlapping signer between txA and txB

❌ [trade, tx_with_dontfront, arbitrage, tip]
   → dontfront tx is not at the front

Integratievoorbeelden

Voor een snel coderecept, zie de MEV-bescherming cookbook-vermelding.

TypeScript (@solana/kit)

Het basisidee is een hulpfunctie die het dontfront-account toevoegt aan een willekeurige instructie:

import {
  address,
  AccountRole,
  type Instruction,
  type Address
} from "@solana/kit";

const DONT_FRONT: Address = address(
  "jitodontfront111111111111111111111111111111"
);

function withDontFront(ix: Instruction): Instruction {
  return {
    ...ix,
    accounts: [
      ...(ix.accounts ?? []),
      { address: DONT_FRONT, role: AccountRole.READONLY }
    ]
  };
}

Dien vervolgens de ondertekende transactie in bij de Jito block engine in plaats van een standaard RPC-node. Gebruik altijd base64-codering. Base58 is verouderd in Jito's API.

const response = await fetch(
  "https://mainnet.block-engine.jito.wtf/api/v1/transactions",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "sendTransaction",
      params: [base64Tx, { encoding: "base64" }]
    })
  }
);

Beste Praktijken

DontFront is één beschermingslaag. Een robuuste MEV-mitigatiestrategie combineert meerder benaderingen:

Bescherming op Transactieniveau

• Stel strakke slippagetoleranties in. De meest effectieve verdediging tegen sandwich-aanvallen is het beperken van acceptabele slippage bij swaps. Een kleinere slippage-marge verkleint de winstmarge voor aanvallers, waardoor je transactie minder aantrekkelijk wordt om te sandwichen.

• Stel passende tips en prioriteitskosten in. Tijdens congestie verhogen hogere tips en prioriteitskosten de kans dat je transactie/bundel snel wordt verwerkt, waardoor het tijdvenster voor searchers om te handelen wordt verkleind. Zie Jito's documentatie over Tipbedragen voor meer informatie over het instellen van passende tips.

• Optimaliseer het gebruik van compute units. Elk block heeft een beperkt aantal compute units beschikbaar (en accounts hebben een beperkt aantal compute units beschikbaar per block). Om de kans te maximaliseren dat je transactie/bundel in een block wordt opgenomen, dien je je compute unit-gebruik te optimaliseren. Zie de Gids voor het Optimaliseren van Compute-gebruik op Solana voor details.

DontFront-specifiek

1. Markeer het dontfront-account als alleen-lezen. Schrijfbaar markeren werkt, maar alleen-lezen optimaliseert de landingssnelheid.

2. Gebruik een unieke dontfront pubkey per applicatie. Elke pubkey die begint met jitodontfront werkt. Het gebruik van een unieke variant (bijv. jitodontfront111111111111111111111111111123) stelt je in staat om gebruik per app te onderscheiden bij het inspecteren van onchain-data.

3. DontFront ondersteunt Address Lookup Tables. Het dontfront-account kan worden opgenomen via een ALT. Gebruik echter geen ALT's voor tip-accounts.

Beperkingen

• Alleen block engine. DontFront wordt gehandhaafd door de Jito block engine. Transacties die rechtstreeks worden ingediend bij validators (waarbij Jito wordt omzeild) zijn niet beschermd.

• Geen garantie. Uit Jito's documentatie: "Deze functie kan helpen sandwich-aanvallen te verminderen, maar biedt hier geen garantie voor en is geen oplossing voor alle variaties in transactievolgorde, inclusief volgorde uitgevoerd door derden."

• Alleen Mainnet/Testnet. Dit is een Jito block engine-functie. Het werkt niet op devnet of localhost.

Referenties

• Jito Docs: Sandwich-mitigatie
• Jito Docs: sendTransaction
• Jito Docs: sendBundle
• Jito Docs: Tip-accounts
• Jito Docs: Tipbedragen
• Tip Floor API
• @solana/kit op GitHub
• solana-sdk op crates.io