Protection MEV avec Jito DontFront

La valeur maximale extractible (MEV) désigne la valeur pouvant être captée en réordonnant, incluant ou excluant des transactions au sein d'un bloc. Le MEV n'est pas propre à une seule chaîne ; c'est une propriété fondamentale de toute blockchain où les producteurs de blocs contrôlent l'ordre des transactions. Certaines formes de MEV, comme l'arbitrage, contribuent à l'efficacité des marchés en corrigeant les écarts de prix entre les DEX. D'autres, comme les attaques sandwich, extraient de la valeur directement des utilisateurs. Pour les développeurs qui créent des applications DeFi, cela peut se traduire par une moins bonne exécution des échanges et des profits perdus.

Ce guide se concentre sur les attaques sandwich, une forme courante de MEV nuisible, et sur la façon de les atténuer grâce à la fonctionnalité dontfront de Jito.

Lecture préalable recommandée : Jito Bundles

MEV sur Solana

L'architecture de Solana réduit déjà la surface d'exposition au MEV par rapport aux chaînes dotées de mempools publics. Les transactions sont transmises directement au prochain producteur de blocs plutôt que d'attendre dans un mempool partagé, et les transactions non traitées expirent après environ 150 blocs (~1 minute). Cela réduit considérablement la fenêtre dont disposent les chercheurs pour observer les transactions en attente et y réagir.

Cela dit, l'extraction de MEV se produit tout de même. Des chercheurs disposant d'une infrastructure optimisée et de connexions directes aux validator peuvent observer le flux de transactions et y répondre. Une grande partie de l'activité MEV sur Solana est de l'arbitrage atomique : des bots qui corrigent les différences de prix entre les DEX en une seule transaction. Ce type de MEV est généralement bénéfique, car il améliore la cohérence des prix entre les marchés.

La variante nuisible, les attaques sandwich, est celle contre laquelle les développeurs doivent activement se protéger.

Qu'est-ce qu'une attaque sandwich ?

Une attaque sandwich se produit lorsqu'un chercheur détecte votre échange en attente et exploite l'ordre des transactions :

1. Front-run : le chercheur achète le jeton avant votre échange, faisant monter le prix
2. Votre échange s'exécute à un prix moins favorable qu'attendu
3. Back-run : le chercheur vend le jeton après votre échange, empochant la différence

Sur Solana, cela peut se produire via les bundles Jito. Un chercheur soumet un bundle de transactions du type : [frontrun_tx, your_tx, backrun_tx], et le moteur de blocs les exécute atomiquement dans l'ordre. La victime obtient un prix d'exécution moins favorable tandis que le chercheur empoche le spread.

Comment fonctionne DontFront

DontFront est une fonctionnalité du moteur de blocs Jito qui empêche les chercheurs de placer des transactions avant la vôtre dans un bundle.

Le mécanisme : ajoutez n'importe quelle clé publique Solana valide commençant par jitodontfront à n'importe quelle instruction de votre transaction. Le moteur de blocs reconnaît ce préfixe et applique une règle : tout bundle contenant votre transaction doit la placer à l'index 0.

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

Étape par étape

1. Choisissez une adresse valide commençant par jitodontfront (ex. : jitodontfront111111111111111111111111111111). Le compte n'a pas besoin d'exister onchain ; il n'est jamais lu ni écrit. Vous pouvez vérifier qu'une chaîne est une adresse valide en utilisant la fonction assertIsAddress de @solana/kit, ou en saisissant l'adresse dans Solana Explorer pour voir si elle se résout. Voici un exemple d'adresse invalide.

2. Ajoutez-la comme compte en lecture seule, sans signataire à n'importe quelle instruction de votre transaction. Marquez-la en lecture seule pour une vitesse d'atterrissage optimale. La plupart des programmes (y compris le System Program) ignorent les comptes supplémentaires au-delà de ceux qu'ils attendent.

3. Soumettez via le moteur de blocs Jito :

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

   Docs : sendTransaction et sendBundle

4. Le moteur de blocs détecte le préfixe jitodontfront et applique les règles d'ordonnancement.

Ce qui se passe au niveau du moteur de blocs

Lorsque le moteur de blocs détecte une transaction contenant un compte jitodontfront :

• Via sendTransaction : la transaction est protégée. Aucun bundle ne peut placer une autre transaction avant elle
• Via sendBundle : la transaction doit apparaître à l'index 0, sinon le bundle entier est rejeté

Les transactions et bundles ne contenant pas de compte jitodontfront ne sont pas affectés.

Règles d'ordonnancement des bundles

Ces règles s'appliquent lorsqu'une transaction jitodontfront apparaît dans un bundle.

Patterns autorisés

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

Plusieurs transactions DontFront dans un même bundle

Plusieurs transactions dontfront dans un seul bundle sont autorisées lorsque les deux conditions sont remplies :

1. Toutes les transactions dontfront sont contiguës en tête du bundle
2. Chaque transaction dontfront partage au moins un signataire avec la première transaction dontfront

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

Patterns rejetés

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

Exemples d'intégration

Pour une recette de code rapide, consultez l'entrée MEV Protection du cookbook.

TypeScript (@solana/kit)

L'idée centrale est un assistant qui ajoute le compte dontfront à n'importe quelle instruction :

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

Ensuite, soumettez la transaction signée au moteur de blocs Jito plutôt qu'à un nœud RPC standard. Utilisez toujours l'encodage base64. Le base58 est déprécié dans l'API de Jito.

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

Bonnes pratiques

DontFront est une couche de protection parmi d'autres. Une stratégie robuste d'atténuation du MEV combine plusieurs approches :

Protection au niveau de la transaction

• Définissez des tolérances de slippage strictes. La défense la plus efficace contre les attaques sandwich consiste à limiter le slippage acceptable sur les échanges. Une fenêtre de slippage plus étroite réduit la marge bénéficiaire disponible pour les attaquants, rendant votre transaction moins attractive pour un sandwich.

• Définissez des tips et des frais de priorité appropriés. En période de congestion, des tips et des frais de priorité plus élevés augmentent la probabilité que votre transaction/bundle soit inclus rapidement, réduisant ainsi la fenêtre d'action des chercheurs. Consultez la documentation de Jito sur les montants des tips pour plus de détails sur la façon de définir des tips appropriés.

• Optimisez l'utilisation des unités de calcul. Chaque bloc dispose d'un nombre limité d'unités de calcul disponibles (et les comptes ont un nombre limité d'unités de calcul disponibles par bloc). Pour maximiser la probabilité que votre transaction/bundle soit inclus dans un bloc, vous devez optimiser votre utilisation des unités de calcul. Consultez le guide Comment optimiser l'utilisation des calculs sur Solana pour plus de détails.

Spécifique à DontFront

1. Marquez le compte dontfront en lecture seule. Le marquage en écriture fonctionne, mais la lecture seule optimise la vitesse d'atterrissage.

2. Utilisez un pubkey dontfront unique par application. N'importe quel pubkey commençant par jitodontfront fonctionne. L'utilisation d'une variante unique (ex. : jitodontfront111111111111111111111111111123) vous permet de distinguer l'utilisation par application lors de l'inspection des données onchain.

3. DontFront prend en charge les Address Lookup Tables. Le compte dontfront peut être inclus via une ALT. Mais n'utilisez pas les ALT pour les comptes de tip.

Limitations

• Moteur de blocs uniquement. DontFront est appliqué par le moteur de blocs Jito. Les transactions soumises directement aux validator (en contournant Jito) ne sont pas protégées.

• Pas une garantie. D'après la documentation de Jito : "Cette fonctionnalité peut contribuer à réduire les attaques sandwich, mais n'est pas garantie de le faire et ne constitue pas une solution pour toutes les variations d'ordonnancement des transactions, y compris tout ordonnancement effectué par des tiers."

• Mainnet/Testnet uniquement. Il s'agit d'une fonctionnalité du moteur de blocs Jito. Elle ne fonctionne pas sur devnet ou localhost.

Références

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