Mesmo que as filas no supermercado ou nos pontos de venda onde você paga suas contas de serviços públicos sejam coisa do passado, alguns de nós sabem como é quando alguém pula na fila.  Para a frente da fila, isso é. Especialmente, se for porque a conta deles é muito mais valiosa em comparação com as outras que estão na fila. Claramente, isso não deve ser um critério quando se trata de agilidade no atendimento.  Agora, esse negócio de ser movido para a frente da fila também ocorre nos contratos inteligentes da Ethereum. Também conhecido como erro frontrunning, cujo nome foi obtido de um fenômeno semelhante do mercado de ações, as transações de contratos inteligentes que pagam taxas de gás mais altas tendem a ser mais favorecidas do que aquelas que não pagam.  Quebrando a vulnerabilidade de front-running  Logo de cara, essa vulnerabilidade não ocorre devido a programação defeituosa, mas faz uso da maneira como as transações são ordenadas e adicionadas a um bloco do 'mempool'.   Além dos usuários regulares que procuram ganhar dinheiro rápido, os mineradores tendem a lucrar com essa transação e é por isso que eles são os mais propensos a observar essas transações antes de serem adicionadas a um bloco. Na verdade, quando o fazem, eles enviam uma transação própria por uma recompensa financeira injusta, que acaba sendo adicionada a um bloco e não ao que foi enviado primeiro.  O que se deve ter em mente aqui é que as transações que foram cometidas com um preço de gás mais alto tendem a ser processadas primeiro em comparação com outras. Tendo essa preferência em mente, o invasor pode alterar o resultado de eventos como leilões, negociações ou ofertas iniciais de moedas a seu favor simplesmente pagando taxas de gás mais altas.  Vejamos este exemplo comum para entender como funciona a vulnerabilidade frontrunning:   Neste exemplo, temos três atores: Naman, Kaavya e Aishwarya. Naman primeiro implanta o desafio de Hashing como um contrato inteligente para os outros dois resolverem. Quem resolver este quebra-cabeça de hash receberá 10 ether como recompensa.   Agora, Kaavya encontra a solução de hash primeiro e a envia com 10 Gwei como taxas de gás, de seu próprio contrato inteligente:   Por outro lado, Aishwarya encontra a resposta um pouco mais tarde e passa a resposta correta para seu contrato inteligente com 100 Gwei como taxas de gás.   Por pagar taxas de gás mais altas, em vez de Kaavya receber a recompensa de 10 Ether, Aishwarya a recebe, conforme mostrado abaixo:   Simplificando, este é o erro de frontrunning ou de ordem de transação, pois processa as transações com base no valor da taxa de gás.  Em outras palavras, mesmo que Kaavya tenha enviado sua resposta antes de Aishwarya, ela não receberá nada por seus esforços, conforme mostrado abaixo:   Como esse 'pulo na fila' de Aishwarya não agradará Kaavya ou qualquer outra pessoa, algumas medidas preventivas devem ser consideradas para nosso código de contrato inteligente.  3 maneiras de lidar com a vulnerabilidade Frontrunning  Agora, existem correções que podem evitar essa perda. Em outras palavras, devemos ser capazes de bloquear uma transação como aquela que deve receber os 10 Ether.   Método 1: Contador de transações  Usar um contador de transações é uma das maneiras mais simples de impedir que outra pessoa receba a recompensa por qualquer outro meio.  Como você pode ver no código adicionado abaixo, foi adicionado um contador de transações que bloqueia a transação confirmada pela pessoa que concluiu o desafio de hash primeiro. Como apenas o primeiro a fazê-lo deve obter a recompensa, informamos a todos os participantes que adicionem o valor 0 junto com sua solução.   Como o valor atual de txCounter será zero para a primeira solução apresentada, ele fica bloqueado. Em outras palavras, e como no exemplo acima, Kaavya inserirá sua solução, bem como o valor de zero, para receber sua recompensa de 10 Ether .   Se outra pessoa fizer isso, a solução não será aceita, pois o contador de transações foi incrementado para um valor maior que um. A essa altura, toda a recompensa de 10 Ether, que deveria ir para Kaavya, será transferida corretamente para ela.   Método 2: Definir limites de gás  Agora, com esse método, o foco é definir um limite de gás para todas as transações. Ambos, um limite inferior e um limite superior, se necessário.  Como você deve se lembrar, as transações são ordenadas com base em quanto as taxas de gás foram pagas por essa transação. Embora isso possa não eliminar totalmente essa ordem, certamente a reduz em grande parte.  Se você observar o código abaixo, todas as transações que pagam gasolina no valor de 1 ou menos serão concluídas, mas aquelas que tentam furar a fila pagando mais gasolina não, graças ao modificador gasThrottle. Nesse caso, 1 Wei ou Gwei pode ser o custo padrão de processamento dessa transação e é tudo o que será permitido.   Portanto, se todas as transações não variarem tanto no gás em virtude desse acelerador, não haverá a questão de dar preferência a determinadas transações. Embora haja vantagens em tal abordagem, a taxa de gás paga deve mudar no futuro.  O que é alto hoje será baixo em alguns anos, então Naman deve estar atento a isso o tempo todo. Ou então, Aish pode aproveitar essas mudanças de valores apenas esperando um pouco.   Método 3: A Abordagem de Envio Submarino  Agora, embora as duas abordagens anteriores possam funcionar para situações mais simples, elas nunca abordam realmente a causa raiz da vulnerabilidade inicial: divulgação completa das informações da transação para mineradores e outros usuários mal-intencionados.  Deve ser óbvio que, enquanto essas duas partes tiverem acesso às informações de cada transação, a chance de jogar o sistema persistirá. Claramente, é necessário um método pelo qual essas informações sensíveis ao tempo devem ser ocultadas e que nos leva à abordagem de envio submarino, implementada como parte da biblioteca de contratos inteligentes   .  LibSubmarine  Quando alguém usa essa abordagem, eles ocultam as informações da transação de forma que os mineradores ou usuários comuns não possam realmente tirar vantagem. A criptografia desempenha um papel importante na proteção dessas informações, que, com base no critério do proprietário, podem ser reveladas quando adicionadas a um bloco.  Dito isso, mesmo que essa abordagem não seja perfeita, o nível de proteção que ela oferece é muito melhor em comparação com os outros métodos, devido à sua disposição de abordar o verdadeiro motivo pelo qual o front-running ocorre - tanto no mundo real quanto na blockchain.  Outras estratégias para contornar a vulnerabilidade Frontrunning  Claro, as estratégias discutidas na seção anterior não são as únicas que protegem os contratos inteligentes da vulnerabilidade 'front-running'.  Com cadeias laterais, a ordenação ocorre fora da cadeia enquanto a liquidação ocorre nela. Com essas duas etapas ocorrendo em plataformas diferentes, isso não apenas traz benefícios para maior rendimento, mas também impede que mineradores ou usuários regulares obtenham as informações necessárias para explorar a vulnerabilidade frontrunning.   Outra estratégia, mesmo que de natureza teórica, envolve randomizar a ordem das transações para uma rodada específica que foi confirmada em um esquema de revelação de confirmação. Isso é aplicado usando a lógica de contrato inteligente. Os pioneiros não chegarão à linha de frente com essa abordagem porque o pedido é determinado pelo contrato inteligente mencionado acima.  Por fim, outra abordagem envolve a implementação do   , no qual os usuários resolvem funções de atraso verificáveis para aquele valor-t tão importante que determina quem recebe o pedido. Como resultado, ao ser capaz de se afastar do sistema de ordem aleatória que a maioria dos blockchains usa, a possibilidade de ataques frontrunning também é reduzida. protocolo injetivo

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch

Como resolver a vulnerabilidade Frontrunning em contratos inteligentes

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Uma breve introdução à teoria do cérebro de Boltzmann

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Uma breve introdução à teoria do cérebro de Boltzmann

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps