MEV-Schutz mit Jito DontFront

Maximal Extractable Value (MEV) bezeichnet den Wert, der durch Umordnung, Aufnahme oder Ausschluss von Transaktionen innerhalb eines Blocks erfasst werden kann. MEV ist nicht auf eine einzelne Chain beschränkt; es ist eine grundlegende Eigenschaft jeder Blockchain, bei der Block-Produzenten die Transaktionsreihenfolge kontrollieren. Einige Formen von MEV, wie Arbitrage, tragen zur Markteffizienz bei, indem sie Preisunterschiede zwischen DEXs ausgleichen. Andere, wie Sandwich-Angriffe, entziehen den Nutzern direkt Wert. Für Entwickler, die DeFi-Anwendungen erstellen, kann dies zu schlechterer Handelsausführung und entgangenen Gewinnen führen.

Dieser Leitfaden konzentriert sich auf Sandwich-Angriffe, eine verbreitete Form schädlicher MEV-Extraktion, und darauf, wie diese mithilfe von Jitos dontfront-Funktion gemindert werden können.

Empfohlene Vorkenntnisse: Jito Bundles

MEV auf Solana

Die Architektur von Solana reduziert die MEV-Angriffsfläche im Vergleich zu Chains mit öffentlichen Mempools bereits erheblich. Transaktionen werden direkt an den bevorstehenden Block-Leader weitergeleitet, anstatt in einem gemeinsamen Mempool zu verweilen, und unverarbeitete Transaktionen laufen nach etwa 150 Blöcken (~1 Minute) ab. Dies schränkt das Zeitfenster für Searcher, ausstehende Transaktionen zu beobachten und darauf zu reagieren, erheblich ein.

Dennoch findet MEV-Extraktion weiterhin statt. Searcher mit optimierter Infrastruktur und direkten Validator-Verbindungen können Transaktionsflüsse beobachten und darauf reagieren. Ein Großteil der MEV-Aktivität auf Solana ist atomare Arbitrage: Bots, die Preisunterschiede zwischen DEXs in einer einzigen Transaktion ausgleichen. Diese Art von MEV ist im Allgemeinen vorteilhaft, da sie die Preiskonsistenz über Märkte hinweg verbessert.

Die schädliche Variante, Sandwich-Angriffe, ist es, gegen die Entwickler aktiv schützen sollten.

Was ist ein Sandwich-Angriff?

Ein Sandwich-Angriff tritt auf, wenn ein Searcher Ihren ausstehenden Swap erkennt und die Transaktionsreihenfolge ausnutzt:

1. Front-run: Der Searcher kauft den Token vor Ihrem Trade und treibt damit den Preis in die Höhe
2. Ihr Trade wird ausgeführt zu einem schlechteren Preis als erwartet
3. Back-run: Der Searcher verkauft den Token nach Ihrem Trade und steckt die Differenz ein

Auf Solana kann dies über Jito-Bundles geschehen. Ein Searcher sendet ein Bundle von Transaktionen wie: [frontrun_tx, your_tx, backrun_tx], und die Block-Engine führt diese atomisch in dieser Reihenfolge aus. Das Opfer erhält einen schlechteren Ausführungspreis, während der Searcher von der Spanne profitiert.

Wie DontFront funktioniert

DontFront ist eine Funktion der Jito-Block-Engine, die verhindert, dass Searcher Transaktionen vor Ihre in einem Bundle setzen.

Der Mechanismus: Fügen Sie einen beliebigen gültigen öffentlichen Solana-Schlüssel, der mit jitodontfront beginnt, zu einer beliebigen Anweisung in Ihrer Transaktion hinzu. Die Block-Engine erkennt dieses Präfix und erzwingt eine Regel: Jedes Bundle, das Ihre Transaktion enthält, muss sie an Index 0 platzieren.

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

Schritt für Schritt

1. Wählen Sie eine gültige Adresse beginning with jitodontfront (z. B. jitodontfront111111111111111111111111111111). Das Konto muss nicht onchain existieren; es wird niemals gelesen oder beschrieben. Sie können überprüfen, ob ein String eine gültige Adresse ist, indem Sie die assertIsAddress-Funktion aus @solana/kit verwenden, oder indem Sie die Adresse im Solana Explorer eingeben, um zu sehen, ob sie aufgelöst wird. Hier ist ein Beispiel einer ungültigen Adresse.

2. Fügen Sie es als schreibgeschütztes, nicht signierendes Konten zu einer beliebigen Anweisung in Ihrer Transaktion hinzu. Markieren Sie es als schreibgeschützt für optimale Landing-Geschwindigkeit. Die meisten Programme (einschließlich System Program) ignorieren zusätzliche Konten über das hinaus, was sie erwarten.

3. Über die Jito-Block-Engine einreichen:

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

   Dokumentation: sendTransaction und sendBundle

4. Die Block-Engine erkennt das jitodontfront-Präfix und erzwingt die Reihenfolgeregeln.

Was in der Block-Engine passiert

Wenn die Block-Engine eine Transaktion mit einem jitodontfront-Konten erkennt:

• Über sendTransaction: Die Transaktion ist geschützt. Kein Bundle kann eine andere Transaktion davor platzieren
• Über sendBundle: Die Transaktion muss an Index 0 erscheinen, sonst wird das gesamte Bundle abgelehnt

Transaktionen und Bundles, die kein jitodontfront-Konten enthalten, sind nicht betroffen.

Bundle-Reihenfolgeregeln

Diese Regeln gelten, wenn eine jitodontfront-Transaktion in einem Bundle vorkommt.

Erlaubte Muster

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

Mehrere DontFront-Transaktionen in einem Bundle

Mehrere dontfront-Transaktionen in einem einzigen Bundle sind erlaubt, wenn beide Bedingungen erfüllt sind:

1. Alle dontfront-Transaktionen befinden sich zusammenhängend am Anfang des Bundles
2. Jede dontfront-Transaktion teilt mindestens einen Signer mit der ersten dontfront-Transaktion

✅ [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)

Abgelehnte Muster

❌ [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

Integrationsbeispiele

Für ein schnelles Code-Rezept, siehe den MEV-Schutz-Cookbook-Eintrag.

TypeScript (@solana/kit)

Die Grundidee ist ein Hilfsmittel, das das dontfront-Konten an eine beliebige Anweisung anhängt:

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 }
    ]
  };
}

Senden Sie anschließend die signierte Transaktion an die Jito-Block-Engine statt an einen Standard-RPC-Knoten. Verwenden Sie stets Base64-Kodierung. Base58 ist in Jitos API veraltet.

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" }]
    })
  }
);

Best Practices

DontFront ist eine Schutzschicht. Eine robuste MEV-Minderungsstrategie kombiniert mehrere Ansätze:

Schutz auf Transaktionsebene

• Setzen Sie enge Slippage-Toleranzen. Die einzeln wirksamste Schutzmaßnahme gegen Sandwich-Angriffe ist die Begrenzung der akzeptablen Slippage bei Swaps. Ein kleineres Slippage-Fenster verringert die für Angreifer verfügbare Gewinnspanne und macht Ihre Transaktion weniger attraktiv für Sandwich-Angriffe.

• Setzen Sie angemessene Tips und priority fees. Bei Netzwerküberlastung erhöhen höhere Tips und priority fees die Wahrscheinlichkeit, dass Ihre Transaktion bzw. Ihr Bundle schnell landet, und reduzieren das Zeitfenster für Searcher. Weitere Informationen zum Festlegen angemessener Tips finden Sie in Jitos Dokumentation zu Tip Amounts.

• Optimieren Sie die Compute-Unit-Nutzung. Jeder Block verfügt über eine begrenzte Anzahl von Compute Units (und Konten haben eine begrenzte Anzahl von Compute Units pro Block). Um die Wahrscheinlichkeit zu maximieren, dass Ihre Transaktion bzw. Ihr Bundle in einen Block aufgenommen wird, sollten Sie Ihre Compute-Unit-Nutzung optimieren. Weitere Informationen finden Sie im Leitfaden How to Optimize Compute Usage on Solana.

DontFront-spezifisch

1. Markieren Sie das dontfront-Konten als schreibgeschützt. Eine beschreibbare Markierung funktioniert ebenfalls, aber schreibgeschützt optimiert die Landing-Geschwindigkeit.

2. Verwenden Sie einen eindeutigen dontfront-pubkey pro Anwendung. Jeder pubkey, der mit jitodontfront beginnt, funktioniert. Die Verwendung einer eindeutigen Variante (z. B. jitodontfront111111111111111111111111111123) ermöglicht es Ihnen, die Nutzung pro App zu unterscheiden, wenn Sie onchain-Daten untersuchen.

3. DontFront unterstützt Address Lookup Tables. Das dontfront-Konten kann über eine ALT eingebunden werden. Verwenden Sie jedoch keine ALTs für Tip-Konten.

Einschränkungen

• Nur Block-Engine. DontFront wird von der Jito-Block-Engine durchgesetzt. Transaktionen, die direkt an Validatoren übermittelt werden (unter Umgehung von Jito), sind nicht geschützt.

• Keine Garantie. Aus Jitos Dokumentation: „Diese Funktion kann dazu beitragen, Sandwich-Angriffe zu reduzieren, ist jedoch keine Garantie dafür und keine Lösung für alle Variationen in der Transaktionsreihenfolge, einschließlich jeglicher Reihenfolge durch Dritte.“

• Nur Mainnet/Testnet. Dies ist eine Funktion der Jito-Block-Engine. Sie funktioniert nicht auf Devnet oder Localhost.

Referenzen

• 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