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'ordonnancement 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 exécution des trades dégradée et des profits perdus.

Ce guide se concentre sur les attaques sandwich, une forme courante de MEV nuisible, et sur la manière 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 leader de bloc 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 néanmoins. Les chercheurs dotés 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 consiste en de l'arbitrage atomique : des bots qui corrigent les différences de prix entre 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 prémunir.

Qu'est-ce qu'une attaque sandwich ?

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

1. Front-run : le chercheur achète le token avant votre trade, faisant monter le prix
2. Votre trade s'exécute à un prix moins favorable que prévu
3. Back-run : le chercheur revend le token après votre trade, empochant la différence

Sur Solana, cela peut se produire via les bundles Jito. Un chercheur soumet un bundle de transactions de la forme : [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 profite de l'écart.

Fonctionnement de 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 (p. 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 et non signataire à n'importe quelle instruction de votre transaction. Marquez-la en lecture seule pour une vitesse d'inclusion optimale. La plupart des programmes (y compris le System Program) ignorent les comptes supplémentaires au-delà de ce 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

   Documentation : 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 l'ensemble du bundle 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.

Schémas 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 même bundle sont autorisées lorsque les deux conditions suivantes sont remplies :

1. Toutes les transactions dontfront sont contiguës au début 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)

Schémas 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 du cookbook sur la protection MEV.

TypeScript (@solana/kit)

L'idée centrale est un helper 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 swaps. 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 pourboires et frais de priorité appropriés. En période de congestion, des pourboires et 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 de pourboire pour plus de détails sur la façon de définir des pourboires 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 unités de calcul 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'inclusion.

2. Utilisez un pubkey dontfront unique par application. N'importe quel pubkey commençant par jitodontfront fonctionne. L'utilisation d'une variante unique (p. ex., jitodontfront111111111111111111111111111123) vous permet de distinguer l'usage 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 pourboire.

Limitations

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

• Pas une garantie. D'après la documentation de Jito : « Cette fonctionnalité peut aider à 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

• Documentation Jito : atténuation des attaques sandwich
• Documentation Jito : sendTransaction
• Documentation Jito : sendBundle
• Documentation Jito : comptes de pourboire
• Documentation Jito : montants de pourboire
• API Tip Floor
• @solana/kit sur GitHub
• solana-sdk sur crates.io