Protezione MEV con Jito DontFront

Il Maximal Extractable Value (MEV) si riferisce al valore che può essere catturato riordinando, includendo o escludendo transazioni all'interno di un blocco. Il MEV non è exclusivo di una singola chain; è una proprietà fondamentale di qualsiasi blockchain in cui i produttori di blocchi controllano l'ordinamento delle transazioni. Alcune forme di MEV, come l'arbitraggio, contribuiscono all'efficienza dei mercati correggendo le discrepanze di prezzo tra i DEX. Altre, come gli attacchi sandwich, estraggono valore direttamente dagli utenti. Per gli sviluppatori che realizzano applicazioni DeFi, questo può tradursi in un'esecuzione degli scambi peggiore e in perdite di profitto.

Questa guida si concentra sugli attacchi sandwich, una forma comune di MEV dannoso, e su come mitigarli utilizzando la funzionalità dontfront di Jito.

Lettura preliminare consigliata: Jito Bundles

MEV su Solana

L'architettura di Solana riduce già la superficie di attacco del MEV rispetto alle chain con mempool pubbliche. Le transazioni vengono inoltrate direttamente al prossimo leader del blocco anziché rimanere in una mempool condivisa, e le transazioni non elaborate scadono dopo circa 150 blocchi (~1 minuto). Questo restringe significativamente la finestra temporale in cui i searcher possono osservare e agire sulle transazioni in attesa.

Detto ciò, l'estrazione di MEV avviene comunque. I searcher con infrastrutture ottimizzate e connessioni dirette ai validator possono osservare il flusso delle transazioni e reagire ad esso. La maggior parte dell'attività MEV su Solana è arbitraggio atomico: bot che correggono le differenze di prezzo tra i DEX in un'unica transazione. Questo tipo di MEV è generalmente beneficio, poiché migliora la coerenza dei prezzi tra i mercati.

La varietà dannosa, gli attacchi sandwich, è quella contro cui gli sviluppatori dovrebbero attivamente proteggersi.

Cos'è un Attacco Sandwich?

Un attacco sandwich si verifica quando un searcher rileva il tuo swap in attesa e sfrutta l'ordinamento delle transazioni:

1. Front-run: il searcher acquista il token prima del tuo trade, facendo salire il prezzo
2. Il tuo trade viene eseguito a un prezzo peggiore del previsto
3. Back-run: il searcher vende il token dopo il tuo trade, intascando la differenza

Su Solana, questo può avvenire tramite Jito bundles. Un searcher invia un bundle di transazioni come: [frontrun_tx, your_tx, backrun_tx], e il block engine le esegue atomicamente nell'ordine indicato. La vittima ottiene un prezzo di esecuzione peggiore mentre il searcher profita dallo spread.

Come Funziona DontFront

DontFront è una funzionalità del block engine di Jito che impedisce ai searcher di inserire transazioni prima della tua in un bundle.

Il meccanismo: aggiungi qualsiasi chiave pubblica Solana valida che inizia con jitodontfront a qualsiasi istruzione nella tua transazione. Il block engine riconosce questo prefisso e applica una regola: qualsiasi bundle contenente la tua transazione deve posizionarla all'indice 0.

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

Passo dopo Passo

1. Scegli un indirizzo valido che inizia con jitodontfront (es., jitodontfront111111111111111111111111111111). L'account non deve esistere onchain; non viene mai letto né scritto. Puoi verificare che una stringa sia un indirizzo valido utilizzando la funzione assertIsAddress di @solana/kit, oppure puoi inserire l'indirizzo in Solana Explorer per verificare se viene risolto. Ecco un esempio di indirizzo non valido.

2. Aggiungilo come account di sola lettura e non firmatario a qualsiasi istruzione nella tua transazione. Contrassegnalo come di sola lettura per una velocità di atterraggio ottimale. La maggior parte dei programmi (incluso il System Program) ignora gli account aggiuntivi oltre quelli attesi.

3. Invia tramite il block engine di Jito:

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

   Documentazione: sendTransaction e sendBundle

4. Il block engine rileva il prefisso jitodontfront e applica le regole di ordinamento.

Cosa Avviene nel Block Engine

Quando il block engine rileva una transazione contenente un account jitodontfront:

• Tramite sendTransaction: la transazione è protetta. Nessun bundle può inserire un'altra transazione prima di essa
• Tramite sendBundle: la transazione deve apparire all'indice 0, altrimenti l'intero bundle viene rifiutato

Le transazioni e i bundle che non contengono un account jitodontfront non sono interessati.

Regole di Ordinamento dei Bundle

Queste regole si applicano quando una transazione jitodontfront compare in un bundle.

Pattern Consentiti

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

Più Transazioni DontFront in un Singolo Bundle

Più transazioni dontfront in un singolo bundle sono consentite quando entrambe le condizioni sono soddisfatte:

1. Tutte le transazioni dontfront sono contigue all'inizio del bundle
2. Ogni transazione dontfront condivide almeno un firmatario con la prima transazione 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)

Pattern Rifiutati

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

Esempi di Integrazione

Per una ricetta di codice rapida, consulta la voce del cookbook sulla Protezione MEV.

TypeScript (@solana/kit)

L'idea fondamentale è un helper che aggiunge l'account dontfront a qualsiasi istruzione:

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

Successivamente, invia la transazione firmata al block engine di Jito anziché a un nodo RPC standard. Utilizza sempre la codifica base64. Il Base58 è deprecato nelle API di 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" }]
    })
  }
);

Best Practice

DontFront è un livello di protezione. Una strategia robusta di mitigazione del MEV combina molteplici approcci:

Protezione a Livello di Transazione

• Imposta tolleranze di slippage ridotte. La difesa più efficace contro gli attacchi sandwich è limitare lo slippage accettabile sugli swap. Una finestra di slippage più piccola riduce il margine di profitto disponibile per gli attaccanti, rendendo la tua transazione meno appetibile per un attacco sandwich.

• Imposta tip e commissioni di priorità adeguate. Durante la congestione, tip e commissioni di priorità più elevate aumentano la probabilità che la tua transazione/bundle venga inclusa rapidamente, riducendo la finestra temporale per i searcher. Consulta la documentazione di Jito sugli Importi dei Tip per maggiori dettagli su come impostare tip appropriati.

• Ottimizza l'utilizzo delle compute unit. Ogni blocco ha un numero limitato di compute unit disponibili (e gli account hanno un numero limitato di compute unit disponibili per blocco). Per massimizzare la probabilità che la tua transazione/bundle venga inclusa in un blocco, dovresti ottimizzare l'utilizzo delle compute unit. Consulta la guida Come Ottimizzare l'Utilizzo di Compute su Solana per i dettagli.

Specifico per DontFront

1. Contrassegna l'account dontfront come di sola lettura. La marcatura come scrivibile funziona ma quella di sola lettura ottimizza la velocità di atterraggio.

2. Usa un pubkey dontfront unico per applicazione. Qualsiasi pubkey che inizia con jitodontfront funziona. Usare una variante unica (es., jitodontfront111111111111111111111111111123) ti permette di distinguere l'utilizzo per app quando si ispezionano i dati onchain.

3. DontFront supporta le Address Lookup Table. L'account dontfront può essere incluso tramite una ALT. Non usare però le ALT per gli account dei tip.

Limitazioni

• Solo block engine. DontFront è applicato dal block engine di Jito. Le transazioni inviate direttamente ai validator (aggirando Jito) non sono protette.

• Non è una garanzia. Dalla documentazione di Jito: "Questa funzionalità può contribuire a ridurre gli attacchi sandwich ma non garantisce di farlo e non è una soluzione per tutte le variazioni nell'ordinamento delle transazioni, incluso qualsiasi ordinamento effettuato da terze parti."

• Solo Mainnet/Testnet. Questa è una funzionalità del block engine di Jito. Non funziona su devnet o localhost.

Riferimenti

• 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