Front-running

O que é front-running?

Front-running é a prática de detectar a transação pendente de outra pessoa e enviar uma transação concorrente antes dela para obter vantagem financeira.

No mercado de criptomoedas, o front-running costuma ocorrer quando um bot automatizado observa uma transação antes de sua confirmação e envia a própria transação com maior chance de ser executada primeiro.

O invasor pode oferecer uma taxa de prioridade mais alta, enviar um pacote privado a um construtor de blocos, usar uma infraestrutura mais rápida ou negociar outra forma de ordenação de transações.

O front-running é mais comum em blockchains programáveis, nas quais transações pendentes podem revelar negociações lucrativas, liquidações, reivindicações de tokens, emissões de NFTs, leilões ou outras ações que dependem do tempo.

A transação da vítima ainda pode ser concluída, mas pode receber um preço pior, custar mais, resultar na perda de uma oportunidade ou falhar depois que o estado da blockchain mudar.

Front-running é uma forma de valor máximo extraível, geralmente chamado de MEV.

A documentação da Ethereum sobre valor máximo extraível descreve os front-runners generalizados como bots que monitoram transações pendentes e copiam oportunidades lucrativas oferecendo taxas mais altas.

Nem toda transação inserida antes de outra é maliciosa, pois as blockchains precisam de algum método para decidir quais transações pendentes entram em um bloco e em que ordem.

A questão central é se alguém usa conhecimento antecipado da transação de outro usuário para extrair valor dele ou capturar uma oportunidade que ele revelou.

Como funciona o front-running?

Um usuário de blockchain cria e assina uma transação que interage com uma carteira, token, aplicativo descentralizado ou contrato inteligente.

Em geral, o usuário envia a transação assinada a um nó por meio de um endpoint RPC (chamada de procedimento remoto).

O nó verifica condições básicas, como assinatura, nonce da conta, saldo disponível e formato da transação.

Após a validação, o nó pode inserir a transação em seu mempool local e compartilhá-la com outros nós.

Um mempool é um conjunto de transações pendentes que ainda não foram incluídas em um bloco confirmado.

O ciclo de vida de transações Proof of Stake da Ethereum explica que transações válidas normalmente são adicionadas a mempools locais e transmitidas pela rede da camada de execução.

Os bots de front-running monitoram esse fluxo e simulam transações pendentes para determinar se executar outra transação primeiro poderia gerar lucro.

Quando surge uma oportunidade lucrativa, o bot cria uma transação concorrente e tenta obter uma posição anterior no mesmo bloco ou em um bloco precedente.

O invasor pode aumentar a taxa de prioridade, usar conexões de baixa latência, enviar a transação diretamente a uma infraestrutura especializada ou agrupar várias transações em uma sequência ordenada.

Se a transação do invasor for executada primeiro, ela altera o estado da blockchain antes do processamento da transação da vítima.

Então, a transação da vítima interage com o estado modificado e pode gerar um resultado pior do que o esperado.

Um exemplo simples de front-running

Imagine que um usuário envie uma ordem de compra grande de tokens por meio de um pool de liquidez automatizado.

A transação pendente revela o par de tokens, o tamanho da negociação, o slippage máximo e outros detalhes de execução.

Um bot calcula que a compra elevará significativamente o preço do token no pool.

O bot compra o token antes que a transação do usuário seja executada.

A compra do usuário então eleva o preço e é concluída a uma taxa média menos favorável.

Depois, o bot pode vender os tokens pelo preço mais alto e ficar com a diferença após as taxas.

Quando o invasor negocia antes e depois da transação do usuário, a estratégia completa geralmente é chamada de sandwich attack.

A primeira transação do invasor é a etapa de front-running, enquanto a segunda é a etapa de back-running.

Front-running nos mercados tradicionais vs. cripto

O front-running nas finanças tradicionais geralmente envolve alguém negociando com base em informações confidenciais sobre uma ordem de cliente iminente.

O glossário de Futuros da CFTC define front-running em Futuros e opções de commodities como assumir uma posição com base em informações não públicas sobre uma transação iminente de outra pessoa.

O front-running em blockchain pode ser diferente porque as informações em um mempool público podem ser visíveis para muitos participantes da rede, em vez de serem conhecidas apenas por meio de uma relação confidencial.

Assim, um bot cripto pode agir com base em dados de transações visíveis publicamente, e não em informações de clientes obtidas indevidamente.

Essa diferença técnica não torna automaticamente toda estratégia de front-running em blockchain legal, justa ou aceitável.

O tratamento jurídico pode depender da jurisdição, do ativo, da relação entre os participantes, da origem das informações, das regras do mercado e da existência de fraude ou manipulação.

O significado de front-running em blockchain se concentra principalmente na visibilidade e na ordenação das transações, enquanto a definição tradicional enfatiza o uso indevido de informações antecipadas sobre ordens.

O que é um mempool?

Um mempool é uma área temporária de armazenamento de um nó para transações válidas que aguardam inclusão em um bloco.

Nem sempre existe um único mempool global perfeitamente sincronizado, pois cada nó pode receber transações diferentes em momentos distintos.

A latência da rede, as configurações dos nós, o roteamento privado, a substituição de transações e as conexões entre pares podem gerar visões locais diferentes.

As transações pendentes costumam revelar o remetente, o destinatário, o valor transferido, as configurações de gas e a chamada codificada ao contrato inteligente.

A documentação de transações da Ethereum explica como os dados da transação identificam a função do contrato e os argumentos que o usuário pretende executar.

Essa transparência permite que os nós validem e simulem transações, mas também possibilita que bots estudem as intenções dos usuários antes da confirmação.

Uma transação enviada por uma rota privada pode evitar o mempool público, embora se torne visível depois de incluída em um bloco.

Como a ordenação de transações possibilita o front-running

Um bloco contém transações em uma sequência específica porque os resultados dos contratos inteligentes podem depender do estado criado por transações anteriores.

Uma compra de token executada primeiro pode obter um preço melhor do que uma compra idêntica executada algumas posições depois.

Uma liquidação concluída primeiro pode receber uma recompensa que deixa de estar disponível para a transação seguinte.

Uma emissão limitada de NFT pode se esgotar antes que todas as solicitações pendentes sejam processadas.

Por isso, os construtores de blocos têm poder de ordenação com valor econômico.

Eles podem incluir, excluir, atrasar e organizar transações dentro dos limites do protocolo e do tamanho do bloco.

Os searchers identificam oportunidades lucrativas de ordenação e podem oferecer parte do lucro esperado ao construtor.

O front-running existe porque a ordem das transações tem valor sempre que duas ou mais ações concorrem por um estado de blockchain que pode mudar.

Taxas de prioridade e lances de gas

Os usuários podem anexar taxas de prioridade para incentivar a inclusão mais rápida de transações em redes que usam ordenação baseada em taxas.

O modelo de taxas da Ethereum separa a taxa-base determinada pelo protocolo da taxa de prioridade opcional paga ao proponente do bloco.

A especificação EIP-1559 observa que os produtores de blocos têm incentivo econômico para preferir transações que ofereçam prêmios de gas maiores.

Um front-runner pode enviar uma transação concorrente com uma taxa de prioridade superior à da transação observada.

Historicamente, esse comportamento gerou leilões de gas prioritário, nos quais vários bots aumentavam repetidamente as taxas enquanto concorriam pela mesma oportunidade.

Taxas mais altas não garantem execução antecipada, pois a construção moderna de blocos também pode envolver fluxo privado de ordens, pacotes, lances de construtores e regras específicas de cada aplicativo.

O usuário não deve presumir que aumentar apenas a taxa de gas oferece proteção contra front-running.

O que é MEV?

Valor máximo extraível é o valor que pode ser obtido ao incluir, excluir ou ordenar estrategicamente transações em blocos.

Front-running é uma forma de MEV porque o invasor lucra ao inserir uma transação antes da ação de outro usuário.

O MEV também inclui back-running, sandwich attacks, liquidações, arbitragem e algumas formas de censura ou atraso de transações.

Algumas formas de MEV podem melhorar a eficiência do mercado ao corrigir diferenças de preço ou realizar liquidações necessárias.

Outras prejudicam diretamente a execução do usuário ou criam riscos de segurança e centralização.

O efeito ético e econômico depende da origem do lucro e de haver ou não prejuízo a outro participante.

Uma arbitragem que alinha dois mercados depois de uma negociação pode ser diferente de um sandwich attack que faz intencionalmente o usuário receber o pior preço permitido pela transação.

Quem pratica front-running em cripto?

Um searcher é uma pessoa ou sistema automatizado que identifica oportunidades lucrativas de ordenação de transações.

Normalmente, os searchers operam softwares que monitoram transações pendentes, simulam mudanças no estado da blockchain, calculam despesas e enviam pacotes lucrativos.

Um construtor de blocos reúne transações em um bloco candidato e pode selecionar combinações que gerem o maior pagamento total.

Um validador ou proponente de bloco é responsável por propor um bloco válido conforme as regras de consenso da rede.

Algumas redes combinam essas funções de forma mais direta, enquanto outras separam o sequenciamento de transações, a construção de blocos e sua proposição.

Usuários comuns também podem praticar front-running manualmente quando observam uma ação pública e enviam uma transação concorrente, embora os sistemas automatizados geralmente tenham grande vantagem de velocidade.

Front-running generalizado

Um front-runner generalizado não precisa entender a finalidade comercial exata de cada aplicativo descentralizado que monitora.

O bot pode simular uma transação pendente e determinar se copiá-la com detalhes modificados do remetente geraria lucro.

Se a simulação for lucrativa, o bot tenta executar primeiro a ação copiada.

Essa estratégia pode visar oportunidades de arbitragem recém-descobertas, reivindicações de tokens, funções vulneráveis de contratos e outras oportunidades reveladas por transações pendentes.

Bots generalizados podem tornar perigosa a divulgação pública de chamadas lucrativas a contratos, pois uma transação copiada pode chegar primeiro à blockchain.

Os desenvolvedores nunca devem inserir segredos valiosos diretamente nos dados da transação e presumir que permanecerão ocultos até a execução.

Front-running por deslocamento

O front-running por deslocamento ocorre quando um invasor copia ou substitui a ação de um usuário e a conclui primeiro.

A transação posterior da vítima pode falhar porque a oportunidade já não existe.

Os exemplos incluem reivindicar uma recompensa, registrar um nome, emitir um ativo limitado, aceitar uma oferta ou concluir uma liquidação.

O lucro do invasor vem de deslocar o usuário original, e não de alterar o preço que esse usuário recebe.

Estruturas de contratos inteligentes que seguem a regra de quem chega primeiro ficam especialmente expostas quando as informações necessárias aparecem no mempool público.

Front-running por inserção

O front-running por inserção coloca a transação de um invasor antes da transação de uma vítima, permitindo que a transação da vítima seja executada depois.

O invasor altera intencionalmente o estado de uma forma que torna a execução da vítima mais lucrativa para ele.

O sandwich attack é a forma mais conhecida de front-running por inserção.

O invasor compra primeiro, permite que a vítima movimente o mercado e vende logo depois.

Em geral, a vítima recebe um preço próximo ao pior nível permitido pela configuração de slippage da transação.

Supressão e atraso de transações

A supressão envolve impedir, atrasar ou superar o lance de outra transação para que um invasor conclua uma ação primeiro.

Um invasor pode enviar muitas transações com taxas altas, explorar uma regra de sequenciamento ou trabalhar com uma infraestrutura capaz de excluir temporariamente a vítima.

A supressão difere da simples cópia porque seu objetivo é impedir que a transação original alcance a posição necessária a tempo.

Essa estratégia pode afetar leilões, reivindicações com prazo limitado, ações de governança e disputas por liquidações.

Redes e aplicativos podem reduzir o risco de supressão com regras de ordenação justa, garantias de inclusão e projetos que não atribuam todo o valor à primeira transação.

Sandwich attacks

Um sandwich attack envolve a negociação da vítima com uma transação antes dela e outra depois.

A transação de front-running movimenta o preço do pool contra a vítima.

A negociação da vítima é então executada e movimenta o preço ainda mais na mesma direção.

A transação de back-running do invasor reverte a posição original e captura um lucro.

A vítima sofre um slippage adicional que não teria ocorrido sem as negociações do invasor.

O ataque só é possível quando a transação da vítima permite movimento de preço suficiente para que toda a sequência continue válida e lucrativa.

Limites de slippage menores podem reduzir o valor que pode ser extraído, embora um limite excessivamente rigoroso possa fazer a transação falhar durante a volatilidade normal.

Front-running vs. back-running

Front-running insere uma transação antes de uma transação-alvo.

Back-running insere uma transação imediatamente depois de uma transação-alvo ou em uma posição estratégica posterior.

Um operador de back-running pode aproveitar uma oportunidade de arbitragem criada por uma negociação concluída de um usuário sem alterar o preço que o usuário já recebeu.

Um front-runner altera o estado antes da execução do usuário e pode piorar diretamente o resultado.

Um sandwich attack combina os dois métodos em torno da mesma vítima.

O back-running ainda pode causar congestionamento ou concentrar lucros, mas costuma ser considerado menos prejudicial ao usuário-alvo do que o front-running deliberado.

Front-running vs. arbitragem

A arbitragem tenta lucrar com diferenças de preço entre mercados ou pools de liquidez.

Um searcher pode fazer arbitragem depois que uma negociação de usuário cria uma nova diferença de preço.

Essa arbitragem de back-running pode ajudar a restaurar preços de mercado consistentes.

A arbitragem por front-running ocorre antes da transação observada e altera o resultado recebido pelo usuário original.

A distinção depende da ordem das transações e da origem do lucro, não de o invasor chamar ou não a estratégia de arbitragem.

Uma estratégia pode incluir tanto uma correção de preço que melhora a eficiência quanto uma extração prejudicial de valor de um usuário.

Front-running em trocas de tokens

As trocas de tokens são alvos comuns porque as transações pendentes revelam a direção da negociação, o tamanho e a tolerância a slippage.

Trocas grandes em pools com liquidez limitada geram maior impacto no preço e mais lucro potencial para os invasores.

Um bot pode simular a negociação e calcular a maior ordem de front-running que ainda permita a conclusão da transação da vítima.

O bot pode então escolher um tamanho que leve a vítima para perto do valor mínimo de saída aceito.

Os usuários devem conferir tanto o impacto estimado no preço quanto as configurações de slippage antes de aprovar uma troca.

Uma cotação favorável exibida na tela não garante a mesma execução quando a transação permanece pendente em um mempool público.

Front-running em liquidações

Protocolos de empréstimo cripto podem permitir que usuários externos paguem dívidas que se tornaram arriscadas e recebam uma recompensa de liquidação.

Vários bots podem detectar a mesma posição sujeita a liquidação e disputar para concluir a ação primeiro.

Um bot que observa a transação pendente de outro liquidante pode enviar a mesma liquidação com incentivos de ordenação mais fortes.

A transação do liquidante original pode então falhar porque a posição já foi processada.

A transação malsucedida ainda pode consumir gas se for incluída e revertida.

A concorrência por liquidações pode ajudar a manter a solvência do protocolo, mas também criar uma disputa agressiva de front-running entre searchers.

Front-running em emissões de NFTs e reivindicações de tokens

Emissões limitadas de NFTs e reivindicações de tokens podem criar oportunidades valiosas por ordem de chegada.

Uma transação de emissão pendente pode revelar a função do contrato e os parâmetros necessários antes da confirmação.

Um bot pode copiar a transação, aumentar o incentivo de ordenação e adquirir primeiro o item limitado.

Um código secreto público nos dados de uma transação deixa de ser secreto quando a transação entra em um mempool visível.

Sistemas de commit-reveal, listas de permissões assinadas, alocação aleatória e limites por endereço podem oferecer proteção melhor do que uma senha revelada publicamente.

Front-running em leilões

Um leilão aberto em blockchain pode revelar todos os lances antes do encerramento do período de ofertas.

Um participante pode observar o lance vencedor atual e enviar um lance um pouco maior imediatamente antes do prazo final.

Esse comportamento pode ser permitido pelas regras do leilão, mas criar vantagens injustas para bots de baixa latência.

Estruturas de lances fechados e commit-reveal ocultam os valores dos lances até o fim da fase de compromisso.

Os desenvolvedores precisam incluir penalidades ou prazos claros para reduzir o risco de os vencedores se recusarem a revelar lances desfavoráveis.

Front-running em atualizações de oráculos

Os contratos inteligentes frequentemente usam oráculos para obter preços de criptoativos e outros dados externos.

Uma atualização de oráculo pendente pode revelar que o preço de referência de um contrato está prestes a mudar.

Um invasor pode enviar uma transação antes da atualização, enquanto o aplicativo ainda usa informações desatualizadas.

O invasor também pode abrir uma posição para aproveitar uma liquidação ou pagamento que se torne disponível logo após a atualização.

Os aplicativos devem validar a atualidade dos preços, usar regras de atualização adequadas e evitar projetos que garantam lucro em torno de mudanças previsíveis nos oráculos.

Uma segurança robusta de oráculos exige mais do que ocultar transações, pois a qualidade dos dados e a lógica dos contratos também importam.

Front-running em transações de governança

As transações de governança on-chain podem revelar votos, mudanças de delegação, execução de propostas e ações do tesouro antes da confirmação.

Um participante pode reagir a um voto pendente tomando empréstimos, comprando, delegando ou transferindo tokens de governança.

Um invasor também pode tentar executar uma proposta antes que uma transação defensiva altere as condições exigidas.

Regras de snapshot, atrasos de votação, períodos de quórum e execução com bloqueio temporal podem reduzir as vantagens de ordenação de transações de última hora.

Os sistemas de governança devem definir quando o poder de voto é medido, em vez de depender apenas de qual transação é executada primeiro.

Como o front-running afeta os usuários

O front-running pode fazer com que os usuários recebam menos tokens, paguem mais por um ativo, percam uma recompensa ou deixem passar uma oportunidade com prazo limitado.

Uma transação deslocada pode falhar e ainda consumir uma taxa de rede.

A extração repetida de valor pode tornar os aplicativos descentralizados mais caros e menos previsíveis para os participantes comuns.

Os usuários podem reagir transferindo as transações para canais privados, reduzindo a transparência do mercado público de transações.

Searchers profissionais de grande porte podem obter vantagens com dados mais rápidos, simulações melhores, relações diretas com construtores e mais capital.

Essas vantagens podem concentrar o poder econômico mesmo quando qualquer pessoa continua podendo usar a blockchain subjacente.

Front-running e centralização de blockchain

O MEV lucrativo pode recompensar organizações com a melhor infraestrutura, algoritmos, fluxo privado de ordens e conexões com construtores.

Validadores menores podem ter dificuldade para obter receita equivalente construindo blocos de forma independente.

Essa pressão pode favorecer construtores de blocos especializados e relações concentradas de roteamento de transações.

A documentação de MEV da Ethereum observa que o acesso desigual ao MEV pode gerar economias de escala e aumentar a pressão por centralização.

O fluxo privado de ordens pode proteger transações individuais, mas também tornar menos visível e menos permissionless uma parte importante da atividade do mercado.

Por isso, os projetistas de redes precisam equilibrar a proteção dos usuários, o acesso transparente, a resistência à censura e a construção eficiente de blocos.

Separação entre proponente e construtor

A separação entre proponente e construtor divide a construção de blocos da responsabilidade do validador de propor um bloco.

Construtores especializados montam blocos candidatos e concorrem oferecendo pagamentos ao proponente selecionado.

O proponente pode escolher uma oferta sem identificar de forma independente todas as oportunidades de MEV.

O roteiro da Ethereum para separação entre proponente e construtor explica que separar essas funções pode distribuir a receita de MEV de forma mais ampla entre os validadores e reduzir parte da pressão por centralização.

A separação entre proponente e construtor não elimina o front-running, pois os construtores ainda podem ordenar transações e receber pacotes de searchers.

Seu principal objetivo é alterar a estrutura de mercado em torno da construção de blocos e reduzir a necessidade de cada validador operar sistemas avançados de MEV.

MEV-Boost e pacotes privados

MEV-Boost é um middleware de código aberto que permite que validadores da Ethereum recebam blocos de um mercado competitivo de construtores.

Os searchers podem enviar pacotes cuja ordem interna de transações precisa ser preservada para que a estratégia funcione.

Os construtores combinam pacotes de transações e outros fluxos de ordens em blocos completos.

Pacotes privados podem impedir que uma estratégia lucrativa seja copiada no mempool público.

Também podem permitir que searchers especifiquem uma execução condicional, como incluir um grupo de transações apenas quando todas as etapas forem bem-sucedidas.

Sistemas de pacotes privados reduzem algumas formas de concorrência no mempool público, mas introduzem questões de confiança, relays, construtores e centralização.

Como os usuários podem reduzir o risco de front-running

Os usuários podem reduzir o risco de front-running limitando o movimento de preço desfavorável que uma transação aceitará.

Uma troca deve incluir um valor mínimo de saída ou máximo de entrada significativo, aplicado pelo contrato inteligente.

Os usuários devem analisar o impacto no preço e a liquidez disponível antes de enviar uma negociação grande.

Dividir uma negociação grande em transações menores pode reduzir o impacto individual no preço, embora aumente as taxas e não garanta proteção.

Uma rota de transação privada pode manter o conteúdo da transação fora do mempool público até a inclusão em um bloco.

Os usuários também podem escolher aplicativos que ofereçam leilões em lote, fluxo de ordens protegido, preços limite ou execução baseada em intenções.

Transações muito sensíveis ao tempo não devem conter segredos visíveis publicamente que outra conta possa reutilizar.

Todo método de proteção envolve concessões relacionadas à velocidade de execução, confiança, privacidade, taxas e possibilidade de atraso da transação.

Proteção contra slippage

A tolerância a slippage define o quanto o preço executado pode se afastar do preço cotado antes que uma transação falhe.

Uma tolerância ampla dá ao invasor mais espaço para movimentar o preço e manter válida a negociação da vítima.

Uma tolerância estreita reduz o possível lucro do sandwich attack, mas pode causar falhas durante a volatilidade normal ou em condições de baixa liquidez.

Os usuários devem definir o slippage de acordo com o ativo, a profundidade do pool, o tamanho da negociação e as condições atuais do mercado.

Um aplicativo deve aplicar o limite de slippage on-chain, em vez de depender apenas de um aviso visual na interface.

Campos como saída mínima, entrada máxima e prazo da transação devem estar visíveis e compreensíveis antes da assinatura pela carteira.

Envio de transações privadas

O envio privado encaminha uma transação a construtores ou relays selecionados sem transmiti-la pela rede pública comum de mempool.

Como os bots públicos não conseguem ver antecipadamente a transação completa, as estratégias comuns de front-running e sandwich attack ficam mais difíceis.

A documentação do Flashbots Protect descreve um mempool privado projetado para ocultar transações enviadas de bots de front-running e sandwich attacks.

O roteamento privado não torna a transação invisível a todos, pois a infraestrutura selecionada ainda pode receber seu conteúdo.

Os usuários devem considerar quais construtores ou searchers recebem os dados, quais configurações de privacidade se aplicam e se a rota pode censurar ou atrasar transações.

Uma transação privada também pode exigir um processo diferente para cancelamento ou gestão de nonce em comparação com uma transação pública comum.

Ordens limite e negociação baseada em intenções

Uma ordem limite define o pior preço de execução aceitável, em vez de aceitar qualquer preço dentro de uma faixa ampla de slippage.

Uma intenção descreve o resultado desejado pelo usuário e permite que solvers concorrentes determinem como alcançá-lo.

A concorrência entre solvers pode melhorar a execução quando o sistema os impede de explorar a intenção divulgada pelo usuário.

A liquidação em lote pode processar várias ordens em conjunto, a um preço comum de equilíbrio, reduzindo a vantagem de inserir uma transação imediatamente antes de outra.

Esses sistemas ainda exigem regras que tratem de acesso de solvers, visibilidade dos dados, falhas, censura e garantias de liquidação.

A palavra “protegido” não deve ser interpretada como promessa de que nenhuma forma de MEV ou execução desfavorável seja possível.

Sistemas de commit-reveal

Um sistema de commit-reveal divide uma ação em um compromisso oculto e uma divulgação posterior.

Durante a etapa de compromisso, o usuário publica um hash criptográfico da ação secreta e de um valor aleatório.

O hash comprova que o usuário escolheu a ação sem revelar seu conteúdo.

Na etapa de divulgação, o usuário publica as informações originais para que o contrato possa verificar se correspondem ao compromisso.

Essa estrutura pode proteger leilões, votações, reivindicações e outros aplicativos contra cópia direta.

Sistemas de commit-reveal introduzem transações adicionais, atrasos, problemas quando as informações não são reveladas e mais complexidade para o usuário.

O contrato precisa impedir que invasores copiem um valor revelado e o associem a outra conta.

Mempools criptografados

Um mempool criptografado oculta o conteúdo das transações enquanto elas aguardam ordenação.

Os construtores podem se comprometer com uma ordem sem conhecer as ações exatas contidas nas transações criptografadas.

As transações são descriptografadas depois que a decisão de ordenação chega à etapa necessária.

Essa abordagem pode reduzir front-running e sandwich attacks, mantendo uma via pública para inclusão de transações.

Mempools criptografados exigem liberação segura de chaves, resistência a conluios, recuperação confiável e atrasos de processamento aceitáveis.

Eles não oferecem privacidade permanente às transações, pois o conteúdo normalmente se torna público durante a execução.

Pesquisas atuais sobre front-running na Ethereum

Em julho de 2026, várias Propostas de Melhoria da Ethereum exploravam proteção contra front-running no nível do protocolo, mas não devem ser descritas como recursos ativos da mainnet.

O EIP-8105 em versão preliminar propõe um mempool criptografado que manteria o conteúdo das transações oculto até a inclusão e a descriptografia posterior.

O EIP-8184 em versão preliminar propõe um fluxo público de commit antes da divulgação para transações criptografadas sensíveis a MEV.

O EIP-8209 em versão preliminar propõe quadros de transação de compromisso e divulgação que atrasam a exposição dos dados de execução.

Essas propostas exploram diferentes concessões relacionadas a criptografia, provedores de chaves, atraso de inclusão, vazamento de informações e complexidade do protocolo.

Como estão em versão preliminar, desenvolvedores e usuários não devem presumir que as transações comuns já recebem automaticamente essas proteções.

Como os desenvolvedores podem reduzir o front-running

Os desenvolvedores devem identificar todas as funções de contrato cujo resultado depende da ordem das transações.

Trocas e compras de tokens devem aplicar on-chain condições de saída mínima, entrada máxima e expiração.

Os leilões podem usar lances fechados, liquidação em lote ou mecanismos de commit-reveal em vez de simples lances públicos por ordem de chegada.

Emissões limitadas e reivindicações podem usar provas de elegibilidade assinadas, alocação aleatória ou períodos de reivindicação que reduzam as vantagens de velocidade.

Aplicativos que usam oráculos devem rejeitar dados desatualizados e evitar transições previsíveis de estado que criem lucros garantidos.

Os sistemas de liquidação podem usar leilões ou incentivos distribuídos, em vez de conceder toda a oportunidade ao primeiro bot.

Os desenvolvedores devem testar contratos com diversas ordenações de transações, em vez de presumir que as chamadas serão executadas na ordem em que os usuários as enviarem.

Qualquer segredo necessário para executar um contrato deve permanecer off-chain até uma etapa segura de divulgação.

Por que projetos baseados em ordem de chegada são arriscados

Um contrato baseado em ordem de chegada concede valor à primeira transação válida incluída.

As blockchains públicas não garantem que o primeiro usuário a clicar em um botão será o primeiro cuja transação será incluída.

Latência da rede, taxas de prioridade, seleção de construtores, pacotes privados e capacidade do bloco afetam a ordenação.

Os bots podem observar usuários comuns e reagir mais rápido do que a maioria das pessoas consegue manualmente.

Por isso, sistemas de alto valor baseados em ordem de chegada acabam se tornando disputas por infraestrutura e ordenação de transações, em vez de oferecer verdadeira justiça cronológica.

Seleção aleatória, processamento em lote ou períodos de elegibilidade podem gerar resultados mais justos quando a ordem exata de chegada não é economicamente necessária.

Como detectar front-running

O front-running pode ser investigado examinando a ordem das transações confirmadas dentro de um bloco.

Um explorador de blockchain mostra o número do bloco, a posição, o remetente, o destinatário, as configurações de taxa e os registros de eventos de cada transação.

Um analista pode comparar a ação que a vítima esperava realizar com as transações imediatamente anteriores e posteriores.

Um padrão de sandwich frequentemente contém uma compra do invasor, uma compra da vítima na mesma direção e uma venda do invasor na direção oposta.

O analista deve calcular o lucro total do invasor depois das taxas de gas, pagamentos ao construtor e mudanças no preço do token.

Apenas uma sincronização temporal semelhante não comprova intenção maliciosa, pois traders independentes podem reagir às mesmas informações de mercado.

Observações do mempool, rastreamentos de execução, relações entre endereços, padrões repetidos e pacotes de transações podem fornecer evidências mais fortes.

Sinais de um possível sandwich attack

O usuário recebe um preço de execução muito pior do que a cotação anterior à transação, mas dentro do limite de slippage selecionado.

Uma transação de outro endereço compra o mesmo token imediatamente antes da transação do usuário, no mesmo bloco.

O mesmo endereço, ou um endereço relacionado, vende o token logo após a transação do usuário.

As duas negociações do invasor parecem dimensionadas para maximizar a extração sem fazer a transação da vítima ser revertida.

A sequência gera um resultado líquido positivo para o invasor depois de todas as despesas de transação.

Uma sequência isolada pode ser acidental, mas padrões repetidos envolvendo muitos usuários fornecem evidências mais fortes de uma estratégia automatizada.

É possível impedir completamente o front-running?

Nenhum método isolado impede todas as formas de front-running em todas as arquiteturas de blockchain.

O roteamento privado protege o conteúdo das transações do mempool público, mas pode revelá-lo a intermediários selecionados.

Estruturas de commit-reveal impedem a cópia direta, mas acrescentam atrasos e exigem que os usuários concluam uma segunda etapa.

Mempools criptografados reduzem a exposição de informações, mas criam desafios criptográficos e de gestão de chaves.

Leilões em lote reduzem as vantagens de ordenação dentro de um lote, mas ainda precisam de regras justas para a inclusão dos lotes.

Um slippage rigoroso protege o preço de execução, mas pode aumentar o número de transações que falham.

Em geral, uma proteção eficaz combina controles para o usuário, design do aplicativo, roteamento privado, ordenação justa e pesquisa no nível do protocolo.

Front-running é ilegal?

A legalidade do front-running depende da jurisdição, do mercado, do ativo, da relação entre as partes e da conduta específica em questão.

Em muitos ambientes financeiros regulamentados, é proibido praticar front-running tradicional com base em informações confidenciais sobre ordens de clientes.

O front-running em blockchain pode usar informações visíveis em um mempool público, o que gera questões jurídicas e factuais diferentes.

A conduta ainda pode levantar questões relacionadas a fraude, manipulação, práticas enganosas, deveres fiduciários, informações confidenciais ou regras de mercado.

O fato de um contrato inteligente permitir uma transação não comprova que todas as formas de uso dessa transação sejam legais.

Usuários e desenvolvedores envolvidos em estratégias de alto valor devem buscar orientação jurídica qualificada para as jurisdições em que atuam.

Golpes de front-running

Golpistas frequentemente anunciam supostos bots de front-running que prometem lucros garantidos com criptomoedas.

O contrato inteligente fornecido pode enviar diretamente ao golpista os ativos depositados pelo usuário.

Um tutorial falso pode pedir à vítima que cole um endereço secreto de carteira no código do contrato ou financie uma conta controlada pelo invasor.

Alguns esquemas afirmam que um depósito maior permitirá ao bot superar mais transações e obter retornos mais altos.

Estratégias reais de MEV exigem infraestrutura avançada, simulação confiável, capital, controles de risco e concorrência com searchers profissionais.

Nenhum script público pode garantir lucros com front-running após considerar taxas, transações malsucedidas, mudanças de mercado e concorrência.

Os usuários nunca devem revelar uma frase de recuperação ou chave privada para instalar, ativar ou financiar um bot de negociação.

Riscos enfrentados por front-runners

Uma transação de front-running pode falhar quando a transação-alvo é cancelada, substituída, atrasada ou enviada por uma rota privada.

Outro bot pode superar a oferta do invasor ou conseguir uma posição melhor no bloco.

A vítima pode usar um limite de slippage que torna o ataque não lucrativo.

Movimentos rápidos do mercado podem transformar o inventário temporário do invasor em prejuízo.

Taxas de gas e pagamentos aos construtores podem consumir o lucro esperado.

Contratos maliciosos podem atrair bots de propósito e fazer com que transações copiadas resultem em perdas.

Riscos jurídicos, operacionais, reputacionais e de contraparte também podem afetar organizações envolvidas em estratégias de ordenação de transações.

Perguntas frequentes

O que é front-running em termos simples?

Front-running significa ver a transação cripto pendente de outro usuário e enviar uma transação concorrente antes dela para obter vantagem.

Por que o front-running é possível em blockchains?

Ele é possível porque transações pendentes podem revelar as intenções dos usuários antes que um construtor de blocos determine a ordem final de execução.

O que é um mempool?

Um mempool é o conjunto de transações pendentes válidas de um nó que ainda não foram incluídas em um bloco confirmado.

Existe um único mempool global?

Não. Cada nó pode ter uma visão diferente das transações pendentes devido à latência, às conexões entre pares, às configurações e ao roteamento privado.

O que é um bot de front-running?

Um bot de front-running é um software automatizado que monitora transações pendentes e tenta executar ações lucrativas antes delas.

O que é um front-runner generalizado?

Um front-runner generalizado simula transações pendentes e copia chamadas lucrativas a contratos sem precisar de uma estratégia desenvolvida para cada aplicativo.

Front-running é o mesmo que MEV?

Front-running é uma categoria de MEV, que também inclui back-running, arbitragem, liquidações, sandwich attacks e outras estratégias de ordenação.

O que é um sandwich attack?

Um sandwich attack coloca uma negociação antes da transação de uma vítima e outra depois, para lucrar com o movimento de preço resultante.

Qual é a diferença entre front-running e back-running?

O front-running é executado antes da transação-alvo, enquanto o back-running é executado depois dela.

Arbitragem é o mesmo que front-running?

Não. A arbitragem pode ocorrer sem prejudicar uma transação pendente específica, enquanto o front-running usa conhecimento antecipado da transação para obter uma posição anterior.

O front-running pode afetar trocas de tokens?

Sim. Os bots podem movimentar o preço de um pool de liquidez antes de uma troca e fazer com que o usuário receba menos tokens.

O front-running pode afetar emissões de NFTs?

Sim. Bots podem copiar transações de emissão pendentes e obter NFTs limitados antes dos usuários originais.

O front-running pode afetar liquidações?

Sim. Bots frequentemente concorrem para concluir primeiro liquidações lucrativas em protocolos de empréstimo.

O front-running pode afetar a governança?

Sim. Votos pendentes e transações de execução podem revelar ações que outros participantes tentam antecipar ou bloquear.

Pagar mais gas impede o front-running?

Não. Uma taxa de prioridade mais alta pode melhorar a velocidade de inclusão, mas não garante proteção contra pacotes privados ou construtores especializados.

Um slippage baixo impede sandwich attacks?

Um slippage baixo reduz o lucro disponível, mas não elimina todos os ataques e pode fazer a transação falhar durante movimentos normais de preço.

O que é o envio privado de transações?

O envio privado encaminha uma transação a uma infraestrutura selecionada sem transmitir primeiro todo o seu conteúdo pelo mempool público.

As transações privadas são completamente privadas?

Não. Construtores ou relays selecionados podem ver a transação, e seu conteúdo normalmente se torna público após a inclusão em um bloco.

O que é um sistema de commit-reveal?

Um sistema de commit-reveal permite que o usuário comprove o compromisso com uma informação oculta e a revele apenas em uma etapa posterior.

O que é um mempool criptografado?

Um mempool criptografado oculta o conteúdo das transações até que a decisão de ordenação seja confirmada ou outra condição de descriptografia seja atendida.

A Ethereum já tem um mempool criptografado na mainnet?

Não. Em julho de 2026, os sistemas de mempool criptografado no nível do protocolo continuavam sendo propostas de pesquisa, e não recursos padrão de transações da mainnet da Ethereum.

O que é separação entre proponente e construtor?

A separação entre proponente e construtor permite que construtores especializados montem blocos enquanto validadores selecionam e propõem blocos candidatos.

A separação entre proponente e construtor elimina o front-running?

Não. Ela altera a estrutura da produção de blocos, mas não impede que construtores e searchers ordenem transações para obter MEV.

Como posso identificar um sandwich attack?

Procure uma negociação do invasor antes da sua troca e outra negociação do mesmo invasor, na direção oposta, depois dela e no mesmo bloco.

Um explorador de blockchain pode comprovar front-running?

Um explorador de blockchain pode revelar a ordem e os resultados das transações, mas provar a intenção pode exigir dados do mempool, rastreamentos de execução e padrões repetidos.

Todo front-running é lucrativo?

Não. Os invasores podem perder dinheiro por causa de transações malsucedidas, concorrência, taxas, mudanças de preço e contratos enganosos.

Os bots de front-running têm lucro garantido?

Não. Alegações de lucro garantido com bots são enganosas e frequentemente estão ligadas a golpes.

Front-running é ilegal?

A legalidade depende da jurisdição, da origem das informações, das regras do mercado, das relações entre as partes, do ativo e da conduta exata.

Os desenvolvedores podem projetar contratos resistentes ao front-running?

Sim. Os desenvolvedores podem usar aplicação de limites de slippage, liquidação em lote, sistemas de commit-reveal, alocação aleatória, oráculos robustos e métodos de execução privada.

Qual é a melhor proteção contra front-running?

A proteção prática mais robusta combina limites de slippage cuidadosamente definidos, um aplicativo adequado, roteamento privado e regras de transação que não recompensem vantagens simples de ordenação.

Conclusão

Front-running é o uso de conhecimento antecipado sobre uma transação de criptomoeda pendente para inserir outra transação antes dela e obter benefício financeiro.

Ele é possibilitado por transações pendentes visíveis, pela ordenação de transações com valor econômico, pela concorrência de taxas e pelo estado programável da blockchain.

Entre as formas comuns estão o deslocamento, sandwich attacks, disputas por liquidações, cópia de emissões de NFTs, lances em leilões e estratégias relacionadas a oráculos.

O front-running faz parte do MEV, mas nem toda forma de MEV prejudica os usuários da mesma maneira.

Searchers, construtores, validadores, relays, carteiras e desenvolvedores de aplicativos influenciam a forma como as transações são observadas e ordenadas.

Os usuários podem reduzir a exposição com configurações razoáveis de slippage, envio privado de transações, execução baseada em limites e análise cuidadosa do impacto no preço.

Os desenvolvedores podem reduzir as oportunidades subjacentes com sistemas de commit-reveal, leilões em lote, alocação aleatória, design seguro de oráculos e limites de execução on-chain.

Mempools criptografados e formatos de transação com compromisso antes da divulgação continuam sendo áreas importantes de pesquisa na Ethereum em julho de 2026.

Nenhuma proteção é perfeita, pois cada abordagem envolve concessões relacionadas a confiança, atraso, privacidade, resistência à censura, taxas e complexidade.

Entender o front-running ajuda os usuários de cripto a avaliar melhor a execução de transações e evitar golpes que prometem lucros fáceis com supostos bots de MEV.