Front Running e Ataque Sanduíche Explicados

Índice:

1. Como as transações são adicionadas à blockchain?
2. Ataques de Front Running
3. Exemplo de Ataque de Front Running
4. Ataque Sanduíche
5. Mitigação
6. Referências

Como as transações são adicionadas à blockchain?

Antes de entender a vulnerabilidade, vamos primeiro entender alguns termos e como as transações são submetidas à blockchain.

Portanto, quando o usuário envia transações para o nó, ele não é adicionado instantaneamente a um bloco. Antes de verificar a transação, essas transações não mineradas são mantidas em uma espécie de sala de espera chamada Mempool.

O termo “mempool” é uma contração de “memory” e “pool” e é usado para descrever a área de armazenamento de um nó onde as transações validadas ficam, esperando para serem mineradas e adicionadas à blockchain.

Os mineradores incluem transações válidas no bloco, mas não há garantia de que serão ordenadas da mesma forma que foram enviadas. Esses mineradores executam transações com base em taxas. Os mineradores podem escolher as transações do mempool para serem incluídas no bloco e aquelas com uma taxa mais alta têm maior probabilidade de serem escolhidas primeiro. Quanto mais altas as taxas, mais rapidamente as transações são processadas.

Front Running:

Os ataques front-running aproveitam o processo pelo qual as transações são adicionadas ao livro-razão distribuído da blockchain.

Um ataque front-running ocorre quando um usuário mal-intencionado observa uma transação depois que um usuário a transmite e está esperando na mempool. O invasor então envia sua própria transação com o objetivo de obter algum lucro com taxas de gás mais altas. Isso fará com que a transação do invasor seja executada antes dos usuários. Normalmente, um minerador ou bot colocará sua própria transação imediatamente antes da transação pendente.

Vamos entender o Front Running com um exemplo prático:

Suponha que haja um jogo de perguntas e respostas, onde 2 usuários podem participar do jogo pagando $50 cada. Quem enviar a resposta correta primeiro recebe $100 como recompensa.

Agora, Alice e Bob participam do jogo.

1. Alice sabe a resposta para a pergunta dada, mas Bob não sabe.
2. Alice apresentou a resposta correta pagando 15 gwei como taxas.
3. Enquanto isso, Bob monitora a mempool em busca da resposta de Alice. Depois de encontrar a transação de Alice com a resposta, Bob envia a mesma, mas com taxas de gás mais altas (50 gwei).
4. Agora, o que acontecerá é que o Minerador solicitará a transação de Bob antes de Alice, pois Bob pagou taxas mais altas. Como resultado, Alice perde o jogo e Bob ganha o jogo ganhando $100, apesar de não saber a resposta.

Ataque Sanduíche

Um ataque sanduíche é uma forma de front-running, que visa principalmente protocolos e serviços financeiros descentralizados.

Um ataque sanduíche envolve colocar as transações de um usuário entre duas transações. Essas duas transações estão antes e depois da transação do usuário (daí o nome sanduíche), gerando uma perda para o usuário e um ganho para o invasor.

Em um ataque sanduíche, um invasor primeiro vai monitorar as transações pendentes na mempool. Em seguida, ele encontrará a transação do usuário e fará duas negociações, uma antes da transação pendente da vítima (front-running) e outra ordem de negociação logo após (back-running). A transação pendente da vítima ficará entre as duas novas ordens de negociação criadas pelo invasor. O objetivo de colocar essas duas ordens e transações pendentes em torno é manipular os preços dos ativos.

Vamos supor que Bob está trocando ETH por MATIC de um pool da Uniswap. Agora, um invasor monitora a transação de Bob verificando verificando a mempool e, quando encontra a transação, imediatamente coloca duas ordens.

1ª Transação do atacante: Trocar ETH por MATIC pagando taxas de gás mais altas
2ª Transação do atacante: Trocando de volta MATIC por ETH pagando taxas de gás mais baixas

1. Primeiro, o invasor executará a mesma transação de swap de Alice (trocando ETH por MATIC), assim, aumentando o preço do MATIC.
2. Agora, depois que o preço é aumentado, a transação de Alice é executada e ela acaba pagando mais ETH por MATIC com maior derrapagem de preço.
3. Assim que a transação da vítima for executada, o invasor trocará seu MATIC de volta para ETH e obterá lucro.

Como prevenir esses ataques?

1. Mantenha a derrapagem (slippage) máxima baixa: mantenha a derrapagem máxima baixa, em torno de 0,5% a 2%, para afastar quem faz front running. Ao fazer um pedido grande, mantenha a derrapagem em nível baixo. Quem faz front running quer que você mantenha a derrapagem alta, então é melhor fazer exatamente o contrário.
2. Contador de transações: em muitos, se não na maioria dos casos, o objetivo do invasor é enviar discretamente uma transação antes que a transação da vítima seja executada. Portanto, para evitar isso, você pode utilizar um contador de transações em seu contrato inteligente. Sempre que uma transação de modificação de estado ocorrer em seu contrato inteligente, incremente um contador de transação universal em um.
3. Colocar ordens fora da cadeia (off-chain): Colocar ordens fora da cadeia implicam duas etapas: ordem (criada, é claro, fora da blockchain) e liquidação (feita na blockchain). Quem está implementando a solução de ordens tem a liberdade de escolher entre uma enorme lista de plataformas potenciais para construir. Eles podem aproveitar os recursos desses sistemas que as blockchains podem não ter, como mensagens com carimbo de data/hora (timestamp), mensagens gratuitas e maior rendimento.
4. Limite o preço do gás: esse método para mitigar o front-running também requer muito pouca sobrecarga (o que economiza custos de gás para seus usuários). No Solidity, pode-se fazer um modificador chamado gasThrottle, que verifica se o custo do gás para a transação que faz a chamada da função (via tx.gasPrice) é menor ou igual a algum valor que chamaremos de MAX_GAS_PRICE.

Confira este artigo para obter medidas detalhadas de prevenção contra ataques de front-running.

Esse artigo é uma tradução feita por @bananlabs. Você pode encontrar o artigo original aqui