MEV-bescherming met Jito DontFront

Maximal Extractable Value (MEV) verwijst naar de waarde die kan worden verkregen door transacties binnen een blok te herordenen, op te nemen of uit te sluiten. MEV is niet uniek voor één bepaalde chain; het is een fundamentele eigenschap van elke blockchain waarbij blokproducenten de transactievolgorde bepalen. Sommige vormen van MEV, zoals arbitrage, houden markten efficiënt door prijsverschillen tussen DEX's te corrigeren. Andere, zoals sandwich-aanvallen, onttrekken waarde rechtstreeks aan gebruikers. Voor ontwikkelaars die DeFi-applicaties bouwen, kan dit leiden tot slechtere trade-uitvoering en gederfde winst.

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

Aanbevolen voorkennis: Jito Bundles

MEV op Solana

De architectuur van Solana verkleint het MEV-aanvalsoppervlak al ten opzichte van chains met publieke mempools. Transacties worden rechtstreeks doorgestuurd naar de aankomende blok- leider in plaats van in een gedeelde mempool te staan, en onverwerkte transacties verlopen na ongeveer 150 blokken (~1 minuut). Dit verkleint het tijdsvenster aanzienlijk waarbinnen zoekers lopende transacties kunnen waarnemen en erop kunnen reageren.

Dat gezegd hebbende, vindt MEV-extractie nog steeds plaats. Zoekers met geoptimaliseerde infrastructuur en directe validator-verbindingen kunnen transactiestromen observeren en erop reageren. Veel van de 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 over markten heen verbetert.

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

Wat is een Sandwich-aanval?

Een sandwich-aanval vindt plaats wanneer een zoeker jouw lopende swap detecteert en de transactievolgorde misbruikt:

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

Op Solana kan dit plaatsvinden via Jito bundles. Een zoeker dient een bundel transacties in zoals: [frontrun_tx, your_tx, backrun_tx], en de blokengine voert ze atomisch in volgorde uit. Het slachtoffer krijgt een slechtere uitvoeringsprijs terwijl de zoeker winst maakt op de spread.

Hoe DontFront Werkt

DontFront is een functie van de Jito-blokengine die voorkomt dat zoekers transacties vóór die van jou plaatsen in een bundel.

Het mechanisme: voeg een willekeurige geldige Solana-openbare sleutel die begint met jitodontfront toe aan een instructie in jouw transactie. De blokengine herkent dit voorvoegsel en legt een regel op: 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 uitgelezen of beschreven. Je kunt controleren of een string een geldig adres is met de assertIsAddress-functie van @solana/kit, of je kunt het adres invoeren in Solana Explorer om te zien of het wordt omgezet. Hier is een voorbeeld van een ongeldig adres.

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

3. Verzend via de Jito-blokengine:

   • 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 blokengine detecteert het jitodontfront-voorvoegsel en handhaaft de volgorderegels.

Wat er Gebeurt bij de Blokengine

Wanneer de blokengine 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 gelden 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 minstens éé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 kernidee is een hulpfunctie die het dontfront-account toevoegt aan een 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 }
    ]
  };
}

Verzend vervolgens de ondertekende transactie naar de Jito-blokengine 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" }]
    })
  }
);

Aanbevolen Werkwijzen

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

Bescherming op Transactieniveau

• Stel strikte slippage-toleranties in. De meest effectieve verdediging tegen sandwich-aanvallen is het beperken van acceptabele slippage bij swaps. Een kleiner slippage- venster verkleint de winstmarge voor aanvallers, waardoor jouw transactie minder aantrekkelijk wordt voor een sandwich-aanval.

• Stel passende fooien en prioriteitskosten in. Tijdens congestie vergroten hogere fooien en prioriteitskosten de kans dat jouw transactie/bundel snel landt, waardoor het tijdsvenster voor zoekers om te handelen wordt verkleind. Zie Jito's documentatie over Fooibedragen voor meer informatie over het instellen van passende fooien.

• Optimaliseer het gebruik van compute units. Elk blok heeft een beperkt aantal compute units beschikbaar (en accounts hebben een beperkt aantal compute units beschikbaar per blok). Om de kans te maximaliseren dat jouw transactie/bundel wordt opgenomen in een blok, moet je het gebruik van compute units optimaliseren. Zie de Handleiding voor het optimaliseren van compute-gebruik op Solana voor meer informatie.

DontFront-specifiek

1. Markeer het dontfront-account als alleen-lezen. Beschrijfbaar markeren werkt ook, 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 onderscheid te maken per app bij het inspecteren van onchain-gegevens.

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

Beperkingen

• Alleen blokengine. DontFront wordt gehandhaafd door de Jito-blokengine. Transacties die rechtstreeks naar validators worden verzonden (waarbij Jito wordt omzeild) zijn niet beschermd.

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

• Alleen mainnet/testnet. Dit is een functie van de Jito-blokengine. Het werkt niet op devnet of localhost.

Referenties

• Jito Docs: Sandwich Mitigation
• Jito Docs: sendTransaction
• Jito Docs: sendBundle
• Jito Docs: Tip Accounts
• Jito Docs: Tip Amounts
• Tip Floor API
• @solana/kit on GitHub
• solana-sdk on crates.io