Proteção contra MEV com Jito DontFront

O Valor Máximo Extraível (MEV) refere-se ao valor que pode ser capturado ao reordenar, incluir ou excluir transações dentro de um bloco. O MEV não é exclusivo de nenhuma cadeia; é uma propriedade fundamental de qualquer blockchain onde os produtores de blocos controlam a ordenação das transações. Algumas formas de MEV, como arbitragem, ajudam a manter os mercados eficientes ao corrigir discrepâncias de preços entre DEXs. Outras, como ataques sandwich, extraem valor diretamente dos utilizadores. Para os programadores que desenvolvem aplicações DeFi, isso pode significar uma execução de negociações pior e perda de lucros.

Este guia foca-se nos ataques sandwich, uma forma comum de MEV prejudicial, e em como mitigá-los usando a funcionalidade dontfront do Jito.

Leitura prévia recomendada: Jito Bundles

MEV no Solana

A arquitetura do Solana já reduz a superfície de ataque do MEV em comparação com cadeias com mempools públicas. As transações são encaminhadas diretamente para o lidêr de bloco seguinte, em vez de ficarem numa mempool partilhada, e as transações não processadas expiram após aproximadamente 150 blocos (~1 minuto). Isso reduz significativamente a janela de oportunidade para que os searchers observem e atuem sobre transações pendentes.

Dito isto, a extração de MEV ainda ocorre. Searchers com infraestrutura otimizada e ligações diretas a validator podem observar o fluxo de transações e reagir ao mesmo. Grande parte da atividade de MEV no Solana é arbitragem atómica: bots que corrigem diferenças de preços entre DEXs numa única transação. Este tipo de MEV é genericamente benéfico, pois melhora a consistência de preços entre mercados.

A variedade prejudicial, os ataques sandwich, é contra a qual os programadores devem proteger-se ativamente.

O que é um Ataque Sandwich?

Um ataque sandwich ocorre quando um searcher deteta o seu swap pendente e explora a ordenação das transações:

1. Front-run: o searcher compra o token antes da sua negociação, fazendo subir o preço
2. A sua negociação é executada a um preço pior do que o esperado
3. Back-run: o searcher vende o token após a sua negociação, embolsando a diferença

No Solana, isto pode acontecer através de Jito bundles. Um searcher submete um bundle de transações como: [frontrun_tx, your_tx, backrun_tx], e o block engine executa-as atomicamente por ordem. A vítima obtém um preço de execução pior, enquanto o searcher lucra com o spread.

Como o DontFront Funciona

O DontFront é uma funcionalidade do Jito block engine que impede os searchers de colocar transações antes da sua num bundle.

O mecanismo: adicione qualquer chave pública Solana válida que comece com jitodontfront a qualquer instrução na sua transação. O block engine reconhece este prefixo e aplica uma regra: qualquer bundle que contenha a sua transação deve colocá-la no índice 0.

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

Passo a Passo

1. Escolha um endereço válido que comece com jitodontfront (por ex., jitodontfront111111111111111111111111111111). A conta não precisa de existir onchain; nunca é lida nem escrita. Pode verificar se uma string é um endereço válido usando a função assertIsAddress do @solana/kit, ou pode introduzir o endereço no Solana Explorer para ver se é resolvido. Aqui está um exemplo de um endereço inválido.

2. Adicione-o como conta somente de leitura e sem assinatura a qualquer instrução na sua transação. Marque-o como somente de leitura para uma velocidade de aterragem otimizada. A maioria dos programas (incluindo o System Program) ignora contas extra além do que esperam.

3. Submeta através do Jito block engine:

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

   Documentação: sendTransaction e sendBundle

4. O block engine deteta o prefixo jitodontfront e aplica as regras de ordenação.

O que Acontece no Block Engine

Quando o block engine deteta uma transação que contém uma conta jitodontfront:

• Via sendTransaction: a transação fica protegida. Nenhum bundle pode colocar outra transação antes dela
• Via sendBundle: a transação deve aparecer no índice 0, caso contrário o bundle inteiro é rejeitado

As transações e bundles que não contêm uma conta jitodontfront não são afetados.

Regras de Ordenação de Bundles

Estas regras aplicam-se quando uma transação jitodontfront aparece num bundle.

Padrões Permitidos

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

Múltiplas Transações DontFront num Único Bundle

São permitidas múltiplas transações dontfront num único bundle quando ambas as condições são satisfeitas:

1. Todas as transações dontfront estão contíguas no início do bundle
2. Cada transação dontfront partilha pelo menos um assinante com a primeira transação 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)

Padrões Rejeitados

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

Exemplos de Integração

Para uma receita de código rápida, consulte a entrada do cookbook de Proteção MEV.

TypeScript (@solana/kit)

A ideia central é um auxiliar que anexa a conta dontfront a qualquer instrução:

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

De seguida, submeta a transação assinada para o Jito block engine em vez de um nó RPC padrão. Use sempre codificação base64. O Base58 está obsoleto na API do 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" }]
    })
  }
);

Boas Práticas

O DontFront é uma camada de proteção. Uma estratégia robusta de mitigação de MEV combina múltiplas abordagens:

Proteção ao Nível da Transação

• Defina tolerâncias de slippage reduzidas. A defesa mais eficaz contra ataques sandwich é limitar o slippage aceitável nos swaps. Uma janela de slippage menor reduz a margem de lucro disponível para os atacantes, tornando a sua transação menos atrativa para sandwich.

• Defina tips e taxas de prioridade adequadas. Durante períodos de congestionamento, tips e taxas de prioridade mais elevadas aumentam a probabilidade de a sua transação/bundle ser processada rapidamente, reduzindo a janela de oportunidade para os searchers agirem. Consulte a documentação do Jito sobre Montantes de Tips para mais detalhes sobre como definir tips adequados.

• Otimize o uso de unidades de computação. Cada bloco tem um número limitado de unidades de computação disponíveis (e as contas têm um número limitado de unidades de computação disponíveis por bloco). Para maximizar a probabilidade de a sua transação/bundle ser incluída num bloco, deve otimizar o uso das suas unidades de computação. Consulte o guia Como Otimizar o Uso de Computação no Solana para mais detalhes.

Específico do DontFront

1. Marque a conta dontfront como somente de leitura. A marcação como gravável funciona, mas somente de leitura otimiza a velocidade de aterragem.

2. Use um pubkey dontfront único por aplicação. Qualquer pubkey que comece com jitodontfront funciona. Usar uma variante única (por ex., jitodontfront111111111111111111111111111123) permite distinguir o uso por aplicação ao inspecionar dados onchain.

3. O DontFront suporta Address Lookup Tables. A conta dontfront pode ser incluída através de uma ALT. Mas não use ALTs para contas de tips.

Limitações

• Apenas no block engine. O DontFront é aplicado pelo Jito block engine. As transações submetidas diretamente a validators (contornando o Jito) não estão protegidas.

• Sem garantia. Da documentação do Jito: "Esta funcionalidade pode ajudar a reduzir os ataques sandwich, mas não garante fazê-lo e não é uma solução para todas as variações na ordenação de transações, incluindo qualquer ordenação realizada por terceiros."

• Apenas Mainnet/Testnet. Esta é uma funcionalidade do Jito block engine. Não funciona na devnet ou em localhost.

Referências

• 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