Proteção contra replay por nonce

O que é proteção contra replay por nonce?

A proteção contra replay por nonce é um método de segurança que impede que uma transação, mensagem, autorização, permissão ou ação de contrato inteligente válida seja reutilizada mais de uma vez.Um nonce é um número ou valor exclusivo que deve ser usado apenas uma vez em um contexto específico.A proteção contra replay significa que, depois que a ação assinada é utilizada, a rede, carteira, contrato ou aplicativo rejeita a mesma ação assinada se alguém tentar enviá-la novamente.No setor cripto, a proteção contra replay por nonce é essencial porque as assinaturas digitais podem ser copiadas perfeitamente.Se um usuário assinar uma transação ou mensagem e o sistema não verificar se ela já foi usada, um invasor poderá conseguir reproduzir a mesma assinatura para repetir a ação.Essa repetição pode transferir fundos novamente, aprovar o gasto de tokens novamente, executar outra vez uma chamada de contrato inteligente, registrar outro voto, resgatar recompensas novamente ou ativar outra vez uma autorização.

A documentação de contas da Ethereum explica que uma conta Ethereum tem um campo de nonce e que apenas uma transação com determinado nonce pode ser executada por conta.

A mesma documentação afirma que isso protege contra ataques de replay nos quais transações assinadas são transmitidas e executadas repetidamente.Portanto, a proteção contra replay por nonce é uma das camadas básicas de segurança que permitem usar assinaturas blockchain para movimentar valor real.

Principais conclusões sobre a proteção contra replay por nonce

• A proteção contra replay por nonce impede que a mesma ação cripto assinada seja aceita mais de uma vez.
• Um nonce pode ser sequencial, aleatório, específico de domínio, conta ou contrato, ou baseado em faixas independentes.
• Contas de propriedade externa da Ethereum usam nonces sequenciais de transação para impedir a execução repetida de transações.
• A EIP-155 inclui o chain ID nos dados de transações assinadas para reduzir o risco de replay entre blockchains.
• Os dados tipados da EIP-712 ainda exigem proteção contra replay no nível do aplicativo, pois assinaturas tipadas podem ser enviadas mais de uma vez se os contratos não rejeitarem repetições.
• O permit ERC-2612 usa nonces de proprietário e prazos de validade para impedir que assinaturas de aprovação de tokens sejam reutilizadas indefinidamente.
• O ERC-3009 usa nonces aleatórios de 32 bytes e o estado de autorização para impedir transferências assinadas repetidas.
• Contas inteligentes ERC-4337 usam um design de nonce mais flexível para abstração de contas e fluxos de trabalho paralelos.
• A proteção contra replay também deve vincular as assinaturas à blockchain, ao contrato, à função, ao usuário, ao prazo e à ação pretendida corretos.
• Um design fraco de nonce pode levar a gasto duplo, aprovações repetidas, transações bloqueadas, danos causados por roubo de assinaturas, meta-transações com falha e ataques de replay cross-chain.

Por que os ataques de replay importam no setor cripto

Um ataque de replay ocorre quando alguém obtém uma ação assinada válida e a envia novamente em um local onde ela ainda é aceita.As assinaturas cripto não são como assinaturas manuscritas em papel, pois podem ser copiadas e retransmitidas exatamente.Se uma transação assinada for válida uma vez e o protocolo não a marcar como utilizada, ela poderá continuar sendo válida.Isso é perigoso porque as blockchains costumam tratar assinaturas válidas como autorização.Uma transferência reproduzida pode movimentar fundos novamente.Uma aprovação reproduzida pode renovar o poder de gastar tokens.Uma reivindicação reproduzida pode esvaziar um pool de recompensas.Um voto de governança reproduzido pode distorcer uma decisão se o contrato não registrar o estado da votação.Uma mensagem de bridge reproduzida pode emitir ou liberar ativos incorretamente.A proteção contra replay por nonce transforma uma assinatura reutilizável em uma autorização de uso único.

Como um nonce impede um replay

Um nonce impede um replay ao tornar cada ação assinada única e rastreável.Quando o usuário assina uma ação, o nonce é incluído nos dados assinados.Quando a ação é executada, o protocolo verifica se o nonce é válido e ainda não foi usado.Se a verificação for aprovada, a ação é executada e o nonce é consumido, incrementado ou marcado como utilizado.Se alguém tentar enviar novamente a mesma ação assinada, a verificação do nonce falhará.A assinatura ainda poderá ser matematicamente válida, mas o sistema a rejeitará porque o nonce já foi usado.Essa distinção é importante.A validade da assinatura comprova que o usuário autorizou uma mensagem.A atualidade do nonce comprova que a autorização ainda não foi utilizada.Um sistema seguro precisa dos dois elementos.

Nonces sequenciais

Um nonce sequencial é um contador que aumenta após cada ação aceita.As contas de propriedade externa da Ethereum usam esse modelo para transações comuns.Se uma conta estiver no nonce 10, a próxima transação válida dessa conta geralmente precisará usar o nonce 10.Depois que essa transação for incluída, a próxima transação válida precisará usar o nonce 11.Isso impede que duas transações diferentes com o mesmo nonce de conta sejam executadas.Também estabelece uma ordem, pois normalmente não é possível processar um nonce posterior antes que os nonces anteriores sejam preenchidos.Nonces sequenciais são simples e eficazes para transações comuns de contas.Podem ser inconvenientes em meta-transações, fluxos em lote, uso de vários dispositivos, sessões automatizadas e sistemas de abstração de contas.Por isso, alguns designs mais recentes usam nonces aleatórios, faixas de nonce ou mapeamentos de nonce específicos de aplicativos.

Nonces aleatórios

Um nonce aleatório é um valor exclusivo gerado aleatoriamente, em vez de ser obtido por contagem crescente.Nonces aleatórios são comuns em autorizações assinadas e sistemas de meta-transações que não exigem uma ordem rígida de transações.O ERC-3009 usa nonces de 32 bytes gerados aleatoriamente e exclusivos para o endereço do autorizador.

O padrão ERC-3009 define uma função de estado de autorização e eventos que registram se um nonce de autorização foi usado ou cancelado.

Esse modelo permite que várias autorizações assinadas independentes existam ao mesmo tempo.Ele evita o problema de um nonce sequencial pendente bloquear autorizações posteriores.A desvantagem é que o contrato precisa armazenar ou verificar os nonces aleatórios usados para impedir a repetição da mesma autorização.Nonces aleatórios exigem aleatoriedade robusta.Se um nonce for previsível ou reutilizado por acidente, a proteção contra replay poderá ser enfraquecida.

Nonces de conta

Um nonce de conta protege as transações da mesma conta.Em contas de propriedade externa, o nonce ajuda a tornar cada transação única e controla a ordem das transações.Se um usuário enviar duas transações com o mesmo nonce de conta, apenas uma poderá ser incluída segundo as regras normais.A outra poderá ser rejeitada, substituída ou permanecer inválida, dependendo da rede e do comportamento das taxas.Por isso, as carteiras controlam cuidadosamente o próximo nonce da conta.Se uma carteira usar um nonce baixo demais, a transação talvez já tenha sido consumida e falhe.Se uma carteira usar um nonce alto demais, a transação poderá aguardar até que os nonces anteriores ausentes sejam confirmados.Se um usuário transmitir uma transação de substituição com o mesmo nonce e uma taxa mais alta, ela poderá substituir a transação pendente anterior, dependendo da política do nó.Nonces de conta protegem contra replay, mas também criam questões práticas de gerenciamento de transações.Os usuários podem perceber essas questões como transações bloqueadas, filas pendentes, transações de substituição ou tentativas de cancelamento.

Proteção contra replay por chain ID

A proteção contra replay por chain ID impede que uma transação assinada para uma blockchain seja válida em outra blockchain que use um formato de transação semelhante.Isso se tornou especialmente importante após divisões de blockchains e a expansão de redes compatíveis com EVM.

A EIP-155 adicionou um chain ID aos dados de transações assinadas da Ethereum.

O objetivo é tornar uma transação válida em uma blockchain e inválida em outra que tenha um chain ID diferente.Sem essa proteção, uma transação transmitida em uma blockchain poderia ser copiada e enviada potencialmente em outra, caso a conta, o nonce e o formato da transação fossem compatíveis.A proteção contra replay por chain ID é diferente da proteção contra replay por nonce de conta.O nonce da conta impede que a mesma transação seja repetida na mesma blockchain.O chain ID ajuda a impedir que a mesma transação assinada seja usada em outra blockchain.Uma proteção contra replay robusta geralmente precisa dos dois.

Separação de domínio

Separação de domínio significa vincular uma assinatura a um contexto de assinatura específico.Esse contexto pode incluir o chain ID, o endereço do contrato, o nome do protocolo, a versão, o tipo de função, o endereço do usuário, o nonce e o prazo.

A EIP-712 define a assinatura de dados estruturados tipados e inclui campos de domínio como name, version, chainId e verifyingContract.

A separação de domínio ajuda a impedir que uma assinatura destinada a um aplicativo seja aceita por outro aplicativo.Por exemplo, um usuário pode querer assinar uma mensagem para um contrato específico em uma determinada blockchain.Se a assinatura não incluir a blockchain e o contrato verificador, outro contrato ou outra blockchain poderá interpretá-la como válida.Isso representa um risco de replay, pois a mesma assinatura pode circular entre contextos.Um nonce impede a reutilização dentro de um mesmo contexto.A separação de domínio ajuda a impedir o uso no contexto errado.Ambos os controles são necessários para assinaturas off-chain seguras.

Proteção contra replay em mensagens EIP-712

A EIP-712 facilita a compreensão de mensagens por carteiras e usuários, mas não torna automaticamente todas as mensagens assinadas de uso único.A seção de segurança da EIP-712 alerta que os aplicativos devem funcionar corretamente quando recebem a mesma mensagem assinada duas vezes.Isso significa que o contrato ou aplicativo precisa rejeitar mensagens assinadas repetidas ou tornar inofensiva a repetição da ação.Uma mensagem tipada pode incluir um nonce, mas esse nonce precisa ser verificado e consumido pelo contrato receptor.Uma mensagem tipada pode incluir um prazo, mas ele precisa ser aplicado on-chain.Uma mensagem tipada pode incluir um contrato verificador, mas o contrato precisa verificar corretamente o separador de domínio.Os dados tipados melhoram a clareza, mas não garantem, por si só, a proteção contra replay.A proteção contra replay depende do design completo.Um fluxo EIP-712 seguro usa em conjunto separação de domínio, rastreamento de nonce, validação de assinatura, vinculação à ação e verificação de prazo.A ausência de qualquer um desses elementos pode criar risco de replay.

Proteção contra replay em permit ERC-2612

O permit ERC-2612 permite que o proprietário de um token aprove o gasto de tokens por meio de uma mensagem assinada, em vez de uma transação de aprovação on-chain direta.Isso melhora a experiência do usuário porque outra parte pode enviar o permit assinado em nome do proprietário.

O padrão ERC-2612 exige uma função nonces e determina que o permit incremente o nonce do proprietário se for bem-sucedido.

O padrão também informa que o mapeamento nonces existe para proteção contra replay.Isso impede que a mesma assinatura de permit seja usada repetidamente.O ERC-2612 também inclui um parâmetro deadline.O prazo limita por quanto tempo o permit assinado permanece válido.Isso é importante porque um relayer que recebe um permit pode escolher quando enviá-lo antes do vencimento.Um prazo curto pode reduzir o risco de assinaturas antigas serem usadas posteriormente.Um permit sem tratamento adequado de nonce e prazo pode criar riscos graves para a aprovação de tokens.

Proteção contra replay no ERC-3009

O ERC-3009 é um padrão de autorização de transferência de tokens por assinatura.Em vez de aprovar primeiro um spender, o detentor do token assina uma autorização para uma transferência específica.Em seguida, o contrato verifica a assinatura, o período de validade e o nonce antes de executar a transferência.O ERC-3009 usa um mapeamento authorizationState para rastrear se um nonce foi usado.O padrão marca o nonce como usado após uma autorização de transferência bem-sucedida.Isso impede que a mesma transferência assinada seja executada novamente.Algumas implementações do ERC-3009 também permitem cancelar autorizações.Ele inclui os campos validAfter e validBefore para definir quando a autorização é válida.Esse design é útil para fluxos de tokens sem gas ou encaminhados por relayers.Também mostra por que a proteção contra replay é mais do que um simples contador.Uma autorização segura deve ter um nonce exclusivo, um período de validade, um destinatário claro, um valor exato e um domínio correto.

Proteção contra replay em contas inteligentes ERC-4337

O ERC-4337 viabiliza a abstração de contas por meio de UserOperations e contas de contratos inteligentes.

O padrão ERC-4337 define o nonce de UserOperation como um parâmetro antirreplay.

Também exige que as assinaturas dependam do chain ID e do endereço EntryPoint para impedir replay cross-chain ou entre vários EntryPoints.O ERC-4337 usa um modelo de nonce semialeatorizado.O nonce pode ser tratado como uma combinação de chave e sequência.Isso permite que contas inteligentes ofereçam suporte a várias faixas de nonce.Por exemplo, uma carteira poderia usar uma faixa para transações comuns e outra para ações administrativas.Isso ajuda a abstração de contas a oferecer suporte a fluxos paralelos sem perder a proteção contra replay.O design é mais flexível do que um único nonce sequencial.Essa flexibilidade adicional também significa que os desenvolvedores de carteiras precisam gerenciar cuidadosamente as faixas de nonce.

Faixas de nonce

Uma faixa de nonce é um fluxo independente de valores de nonce.Em vez de obrigar todas as ações de uma conta a seguir uma única sequência, as faixas de nonce permitem que diferentes categorias de ações avancem separadamente.Isso é útil para contas inteligentes, chaves de sessão, pagamentos automatizados, assinaturas recorrentes, ações de recuperação, movimentos em jogos e carteiras com plugins.Por exemplo, um usuário poderia ter uma faixa para gastos diários e outra para operações de recuperação.Uma transação na faixa de recuperação não deveria bloquear uma transação na faixa de gastos diários.As faixas de nonce podem aumentar a flexibilidade e melhorar a experiência do usuário.Também podem criar complexidade se as carteiras não as exibirem com clareza.Se uma carteira assinar usando a faixa errada, a ação poderá falhar ou gerar uma ordem inesperada.Se um contrato não validar corretamente a faixa, a proteção contra replay poderá ficar incompleta.As faixas de nonce só são poderosas quando suas regras são fáceis de entender.

Proteção contra replay em contratos inteligentes

Os contratos inteligentes muitas vezes precisam de sua própria proteção contra replay por nonce, pois os nonces comuns de conta não protegem todas as autorizações no nível do contrato.Se um contrato aceitar uma assinatura, deverá decidir se ela já foi usada.Por exemplo, um contrato de resgate de airdrop pode usar um mapeamento para marcar que um usuário já reivindicou seus tokens.Um contrato de governança pode registrar se um eleitor já votou em uma proposta.Um contrato de permit pode armazenar um nonce para cada proprietário.Um contrato de bridge pode armazenar IDs de mensagens processadas.Um contrato de escrow no estilo marketplace pode armazenar hashes de ordens que foram executadas ou canceladas.Todas essas são formas de proteção contra replay.A estrutura de dados exata pode variar, mas o objetivo é o mesmo.O contrato precisa impedir que a mesma autorização provoque alterações repetidas de estado.

Proteção contra replay em bridges

Bridges precisam de uma proteção robusta contra replay porque movimentam valor ou mensagens entre blockchains.Uma mensagem de bridge pode informar que ativos foram bloqueados em uma blockchain e devem ser emitidos ou liberados em outra.Se a mesma mensagem de bridge puder ser processada duas vezes, a blockchain de destino poderá liberar ativos em excesso.A proteção contra replay em bridges costuma usar IDs de mensagens, chain IDs de origem e destino, endereços de contratos de origem, números de sequência e mapeamentos de mensagens processadas.O contrato de destino deve marcar cada mensagem válida como processada.Deve rejeitar a mesma mensagem se ela for enviada novamente.O risco de replay cross-chain é maior porque blockchains podem compartilhar formatos de endereço, símbolos de tokens e interfaces de contratos inteligentes.Uma bridge deve vincular cada mensagem à blockchain de origem, à blockchain de destino, ao contrato da bridge, ao remetente, ao destinatário, ao valor e ao nonce pretendidos.Uma proteção fraca contra replay em bridges pode causar erros de emissão, perda de fundos ou risco sistêmico de liquidez.

Proteção contra replay em meta-transações

Uma meta-transação é uma instrução assinada pelo usuário e enviada por outra parte.O usuário assina off-chain, e um relayer envia a transação on-chain.Isso pode facilitar o uso de aplicativos porque o usuário talvez não precise pagar o gas diretamente com o ativo nativo.Meta-transações exigem tratamento cuidadoso de nonces para evitar replay.Se a instrução assinada puder ser enviada mais de uma vez, o relayer ou um invasor poderá repetir a ação.Nonces sequenciais podem causar problemas quando os usuários assinam várias meta-transações em aplicativos diferentes ao mesmo tempo.Nonces aleatórios ou espaços de nonce separados por aplicativo podem reduzir essas colisões.Prazos podem reduzir o perigo de instruções assinadas antigas.A separação de domínio pode impedir que a assinatura de meta-transação de um aplicativo seja usada em outro.A segurança de meta-transações depende tanto da proteção contra replay quanto da verificação de assinaturas.

Proteção contra replay em mensagens de login de carteiras

Muitos aplicativos cripto pedem que os usuários assinem uma mensagem para comprovar que controlam uma carteira.Isso é comum em logins, vinculação de contas, atualizações de perfil e autenticação off-chain.Uma assinatura de login deve incluir um nonce ou desafio gerado pelo servidor.Após um login bem-sucedido, o servidor deve marcar esse desafio como utilizado.Sempre que possível, a mensagem também deve incluir o domínio, a blockchain, a data de emissão, a data de expiração e a ação pretendida.Se uma mensagem de login não incluir um desafio novo, um invasor poderá reproduzir uma assinatura antiga para se passar pelo usuário.Se uma mensagem de login não incluir o domínio correto, uma assinatura de um site poderá ser usada em outro.O login com carteira costuma ocorrer off-chain, mas a proteção contra replay continua sendo importante.Uma assinatura que comprova o controle de uma carteira não deve se tornar uma senha reutilizável permanente.As assinaturas de login mais seguras são específicas, recentes, limitadas e legíveis por humanos.

Proteção contra replay em governança

Sistemas de governança precisam de proteção contra replay porque votos e delegações não devem ser contados mais vezes do que o previsto.Um contrato de votação pode armazenar se um endereço já votou em uma proposta.Um contrato de delegação por assinatura pode usar nonces para impedir que a mesma assinatura de delegação seja usada repetidamente.Um sistema de execução de propostas pode marcar uma proposta como executada após uma execução bem-sucedida.A proteção contra replay também é importante entre blockchains quando decisões de governança são replicadas em várias redes.Uma mensagem de governança assinada para uma blockchain não deve ser executada automaticamente em outra, a menos que isso seja explicitamente previsto.Falhas de proteção contra replay em governança podem ser graves, pois podem alterar parâmetros do protocolo, movimentar fundos do tesouro, atualizar contratos ou modificar controles de risco.Contratos de governança bem projetados usam cuidadosamente IDs de propostas, chain IDs, endereços de contratos, períodos de votação, nonces e estados de execução.Um voto só deve poder ser alterado se o sistema permitir intencionalmente mudanças antes do prazo.Mesmo nesse caso, as regras de contagem final precisam ser claras.

Proteção contra replay em airdrops e resgates

Contratos de resgate de airdrop e recompensas costumam usar proteção contra replay para impedir que os usuários resgatem mais de uma vez.Um sistema simples de resgate pode armazenar um mapeamento de endereços elegíveis que já resgataram.Um airdrop Merkle pode verificar a prova do usuário e, em seguida, marcar o endereço ou índice de resgate como utilizado.Uma reivindicação de recompensa baseada em assinatura pode incluir nonce, ID de resgate, ID de campanha, prazo e endereço do usuário.Sem proteção contra replay, uma prova de resgate válida poderia ser reutilizada até que o pool se esgotasse.A proteção contra replay também deve considerar a separação entre campanhas.Uma assinatura de resgate da Campanha A não deve funcionar na Campanha B.Um resgate em uma blockchain não deve funcionar em outra, a menos que isso tenha sido previsto no design.Um resgate de um token não deve autorizar outro token.Um bom design de resgate vincula a prova ao usuário, à campanha, à blockchain, ao token, ao valor e ao nonce corretos.

Proteção contra replay e prazos

Um prazo é um limite de tempo para uma autorização assinada.Prazos não substituem nonces, mas reduzem o período em que uma assinatura roubada ou atrasada pode ser usada.O permit ERC-2612 usa um campo deadline.O ERC-3009 usa os campos validAfter e validBefore.As UserOperations ERC-4337 podem incluir intervalos de validade por meio de dados de validação.Um prazo é especialmente útil quando o usuário fornece uma assinatura a um relayer ou aplicativo que pode escolher quando enviá-la.Sem prazo, uma autorização assinada antiga pode permanecer utilizável por muito mais tempo do que o usuário esperava.Com um prazo, a assinatura se torna inválida após um período definido.Prazos curtos podem aumentar a segurança, mas também gerar mais transações com falha se a rede estiver congestionada.O melhor prazo depende do valor, do risco, da urgência e do tempo de liquidação esperado da ação.

Proteção contra replay e idempotência

Idempotência significa que repetir uma ação produz o mesmo efeito final que executá-la uma única vez.A EIP-712 observa que os aplicativos devem rejeitar mensagens assinadas repetidas ou tornar idempotente a ação autorizada.Por exemplo, definir duas vezes o nome de perfil de um usuário com o mesmo valor pode ser inofensivo.Transferir 100 tokens duas vezes não é inofensivo.Aprovar um spender duas vezes pode ou não ser prejudicial, dependendo do valor e da permissão atual.Votar duas vezes em uma proposta de governança pode ser prejudicial se os dois votos forem contabilizados.Resgatar recompensas duas vezes é prejudicial se o usuário receber recompensas duplicadas.Os desenvolvedores devem decidir se a execução repetida deve ser rejeitada ou tornada inofensiva.A maioria das ações que movimentam valor deve rejeitar execuções repetidas.A idempotência pode ser útil em atualizações de estado de baixo risco, mas não deve ser usada sem cuidado em ações financeiras.

Proteção contra replay e vinculação da assinatura

Uma assinatura deve estar vinculada à ação exata que o usuário pretende realizar.Isso significa que a mensagem assinada deve incluir destinatário, valor, token, contrato, chain ID, finalidade da função, nonce, prazo e quaisquer parâmetros importantes.Se uma assinatura autorizar apenas uma ação vaga, um invasor poderá reutilizá-la em um contexto mais amplo.Se uma assinatura incluir apenas um número, mas não o endereço do token, ela poderá ser interpretada como referente ao token errado.Se uma assinatura incluir apenas um destino, mas não um chain ID, ela poderá ser reproduzida em outra blockchain.Se uma assinatura incluir apenas o endereço do usuário, mas não o endereço do contrato, outro contrato poderá aceitá-la.A proteção contra replay é mais robusta quando a assinatura tem escopo restrito.Uma assinatura de escopo restrito especifica exatamente o que é permitido, sem autorizar nada além disso.Uma assinatura ampla cria espaço para replay, uso indevido e confusão do usuário.As carteiras devem exibir esses detalhes com clareza antes de o usuário assinar.

Proteção contra replay e phishing

A proteção contra replay por nonce não consegue proteger totalmente os usuários contra phishing.Se um usuário assinar uma mensagem maliciosa com um nonce válido, o invasor poderá usá-la uma vez.O nonce pode impedir a reutilização, mas o primeiro uso ainda pode ser prejudicial.Por exemplo, um site de phishing pode pedir ao usuário que assine um permit que autoriza o gasto de tokens.O permit pode incluir nonce e prazo válidos.Depois que for enviado, o invasor ainda poderá usar essa autorização válida uma vez.A proteção contra replay impede duplicações, não intenções maliciosas.Os usuários ainda precisam revisar o que estão assinando.As carteiras ainda precisam exibir alertas claros e legíveis por humanos.Os contratos ainda precisam limitar as assinaturas a ações específicas.

Proteção contra replay e front-running

Front-running ocorre quando outra parte vê uma transação ou assinatura e envia sua própria transação primeiro.A proteção contra replay por nonce pode limitar os danos, pois permite que a assinatura seja usada apenas uma vez.No entanto, ela nem sempre impede que um participante antecipado seja o primeiro a usar a assinatura.O ERC-2612 observa que outra parte pode executar front-running em uma chamada de permit antes que a parte pretendida a envie, embora o efeito final da aprovação possa ser o mesmo para o signatário.O ERC-3009 inclui receiveWithAuthorization para reduzir certos problemas de front-running, garantindo que o beneficiário corresponda ao chamador.Isso mostra que a proteção contra replay e a proteção contra front-running são relacionadas, mas diferentes.Um nonce impede a execução repetida.Os controles contra front-running determinam quem pode enviar ou se beneficiar da primeira execução.Assinaturas de alto valor devem incluir vinculação ao destinatário, prazos e intenção específica da função.Os desenvolvedores não devem presumir que verificações de nonce, por si só, resolvem todos os ataques ao mempool.

Proteção contra reutilização entre contratos

O replay entre contratos ocorre quando uma assinatura destinada a um contrato é aceita por outro contrato.Isso pode acontecer se os dados assinados não incluírem o endereço do contrato verificador.A separação de domínio da EIP-712 ajuda a reduzir esse risco ao incluir verifyingContract no domínio.O ERC-2612 recomenda um separador de domínio exclusivo para o contrato e a blockchain.O replay entre contratos também pode ocorrer quando vários contratos usam o mesmo esquema de assinatura sem incluir um domínio específico para cada contrato.Por exemplo, dois contratos de token poderiam aceitar a mesma mensagem semelhante a um permit se os dados assinados fossem genéricos demais.O usuário pode pretender aprovar um token, mas a mesma assinatura pode ser interpretada por outro token.Por isso, é essencial vincular a assinatura ao endereço do contrato.Uma assinatura válida não deve circular livremente entre contratos.Ela deve pertencer a um único domínio de verificação específico.

Proteção contra reutilização cross-chain

O replay cross-chain ocorre quando uma transação ou mensagem assinada para uma blockchain é aceita em outra.A EIP-155 reduz esse risco em transações no estilo Ethereum ao adicionar o chain ID ao hash da transação assinada.Os dados tipados da EIP-712 também oferecem suporte ao chainId no domínio da assinatura.O replay cross-chain ainda pode ocorrer em mensagens no nível do aplicativo se os dados assinados omitirem o chain ID.Por exemplo, uma assinatura de bridge, DAO, permit de token ou login deve especificar a blockchain pretendida quando o contexto da rede for relevante.Chain IDs são especialmente importantes em redes compatíveis com EVM, pois endereços e códigos de contratos podem parecer semelhantes em diferentes redes.Um usuário pode controlar o mesmo endereço em várias blockchains.Um contrato pode ser implantado no mesmo endereço em várias blockchains por meio de implantação determinística.Sem a vinculação à blockchain, uma assinatura pode ser perigosamente reutilizável em diferentes redes.Designs seguros deixam explícita a blockchain.

Proteção contra replay e substituição de transações

A substituição de transação ocorre quando um usuário transmite uma nova transação com o mesmo nonce de conta e uma taxa mais alta para substituir uma transação pendente.Isso não é, por si só, um ataque de replay.É uma técnica normal de gerenciamento de transações em muitos fluxos de trabalho no estilo Ethereum.O ponto principal é que apenas uma transação com aquele nonce pode ser executada no final.Um usuário pode substituir uma transação lenta por uma versão mais rápida.Um usuário pode enviar uma transação de valor zero para si mesmo, usando o mesmo nonce, para cancelar uma transação pendente.A transação de substituição precisa cumprir as regras de aumento de taxas da rede para ser aceita pelos nós.A proteção contra replay por nonce é o que torna a substituição possível.O nonce obriga a rede a escolher uma transação para aquela posição.Os usuários devem ter cuidado, pois substituir o nonce errado pode cancelar ou substituir uma ação que ainda queriam executar.

Proteção contra replay e transações bloqueadas

Uma transação pode ficar bloqueada quando uma transação com taxa baixa permanece pendente.Se ela usar o próximo nonce exigido, transações posteriores da mesma conta também poderão ficar aguardando.Esse é um efeito colateral de nonces sequenciais.Em condições normais de ordenação, a conta não pode pular o nonce ausente.O usuário talvez precise acelerar ou cancelar a transação bloqueada enviando uma substituta com o mesmo nonce.As carteiras geralmente gerenciam isso automaticamente, mas a configuração manual de nonce pode causar confusão.Se o usuário definir um nonce alto demais, a transação poderá não ser confirmada até que os nonces anteriores sejam preenchidos.Se o usuário definir um nonce baixo demais, a transação poderá falhar porque esse nonce já foi usado.A proteção contra replay por nonce protege a conta, mas também exige cuidado com a sequência de transações.Usuários avançados devem entender o estado dos nonces antes de editar manualmente os nonces de transação.

Proteção contra replay e chaves de sessão

Chaves de sessão são chaves de uso limitado que podem autorizar determinadas ações por um período de tempo.São úteis para jogos, assinaturas recorrentes, estratégias automatizadas e carteiras de abstração de contas.Chaves de sessão precisam de uma proteção robusta contra replay por nonce porque podem assinar muitas ações pequenas.Uma autorização de chave de sessão deve incluir limites como funções permitidas, limites de gastos, contratos de destino, prazo de validade, chain ID e regras de nonce.Sem proteção contra replay por nonce, um invasor que capture uma assinatura de chave de sessão poderá reproduzi-la repetidamente.Sem limites para as ações, uma chave de sessão pode se tornar poderosa demais.Faixas de nonce podem ajudar a separar as ações da chave de sessão das ações da carteira principal.Isso pode melhorar a experiência do usuário e preservar a proteção contra replay.As chaves de sessão devem ser fáceis de revogar.Seu escopo também deve ser suficientemente restrito para limitar os danos de um replay.

Proteção contra replay e carteiras multisig

Carteiras multisig também precisam de proteção contra replay.Uma transação multisig costuma ter um nonce interno que acompanha as ações executadas pela carteira.Os signatários aprovam um hash de transação específico que inclui o nonce da carteira e os detalhes da ação.Depois que a multisig executa a transação, o nonce avança ou o hash da transação é marcado como executado.Isso impede que o mesmo conjunto de assinaturas seja usado novamente para executar a mesma ação duas vezes.A proteção contra replay de multisig deve vincular as assinaturas ao endereço da carteira, ao chain ID, ao endereço de destino, ao valor, aos dados, ao tipo de operação e ao nonce.Se uma carteira multisig for implantada em várias blockchains, a proteção contra replay cross-chain se torna especialmente importante.Os signatários devem confirmar a blockchain e o endereço da carteira antes de aprovar.Uma assinatura multisig não deve ser considerada segura apenas porque foi assinada por várias pessoas.O conteúdo assinado ainda precisa ser específico e resistente a replay.

Proteção contra replay e oráculos

Sistemas de oráculos podem assinar atualizações de preços, atestações de dados, relatórios de reservas, resultados de aleatoriedade ou mensagens cross-chain.Esses pacotes de dados assinados precisam de proteção contra replay.Uma atualização de preço desatualizada não deve ser aceita para sempre.Um resultado de aleatoriedade não deve ser reutilizado em outra rodada de um jogo.Uma atestação de reservas não deve ser reproduzida depois de expirar.Quando apropriado, uma mensagem de oráculo deve incluir ID do feed, ID da rodada, registro de data e hora, número de sequência, chain ID e contrato de destino.Os contratos devem rejeitar mensagens de oráculo antigas ou já utilizadas.A proteção contra replay é essencial porque contratos inteligentes podem agir automaticamente com base em dados de oráculos.Se dados antigos puderem ser reproduzidos, liquidações, resgates, emissões ou pagamentos poderão estar incorretos.A atualidade dos dados dos oráculos e o controle de nonce fazem parte da segurança dos contratos inteligentes.Assinaturas corretas não bastam se os dados estiverem desatualizados ou forem reutilizados.

Proteção contra replay e aprovações de tokens

As aprovações de tokens estão entre as áreas mais sensíveis à proteção contra replay.Uma aprovação on-chain comum usa o nonce da transação da conta e atualiza o estado da permissão de gasto.Um permit assinado usa um nonce no nível do contrato e um prazo para autorizar uma aprovação sem uma transação direta do proprietário.Se uma assinatura de permit puder ser reproduzida, um spender poderá recuperar uma permissão de gasto depois que o usuário acreditar que a aprovação foi removida.Se o permit omitir o spender, o token, o valor, o nonce, o prazo ou o domínio, a assinatura poderá ser usada indevidamente.Os usuários devem tratar aprovações assinadas como autorizações financeiras sérias.As carteiras devem exibir claramente o spender, o token, o valor, o prazo e o aplicativo.Os contratos devem rejeitar imediatamente nonces de permit já utilizados.Os aplicativos devem evitar pedir aprovações ilimitadas, a menos que isso seja absolutamente necessário.Um design de aprovação resistente a replay reduz uma das formas mais comuns de ataque para esvaziar carteiras.

Proteção contra replay e atualizações de contratos inteligentes

Contratos atualizáveis criam considerações adicionais sobre replay.Se um contrato for atualizado, assinaturas antigas ainda poderão ser válidas, a menos que a versão do domínio, a lógica de nonce ou as regras de validação sejam alteradas.A EIP-712 inclui um campo de versão no domínio de assinatura por esse motivo.Uma atualização importante de contrato deve considerar se autorizações antigas continuarão seguras.Se as assinaturas antigas não devem funcionar após uma atualização, o contrato talvez precise de uma nova versão de domínio ou de um método para invalidar nonces.Se as assinaturas antigas devem continuar funcionando, a atualização precisa preservar corretamente o estado dos nonces.Se o estado dos nonces não for migrado corretamente, assinaturas antigas poderão ser reproduzidas ou assinaturas válidas poderão deixar de funcionar.Os planos de atualização devem incluir migração de assinaturas, mudanças de domínio, estrutura de armazenamento de nonces e comunicação aos usuários.A proteção contra replay não é apenas uma questão do momento da implantação.Ela precisa continuar funcionando durante atualizações e migrações.

Proteção contra replay e forks

Um fork de blockchain pode criar risco de replay se os dois lados do fork aceitarem o mesmo formato de transação e o mesmo estado.Se os usuários mantiverem as mesmas chaves privadas e os mesmos estados de conta nas duas blockchains, uma transação em um dos forks poderá ser reproduzida no outro, a menos que as proteções sejam diferentes.A proteção por chain ID da EIP-155 foi projetada para reduzir esse risco em transações da Ethereum.No entanto, assinaturas no nível do aplicativo ainda precisam de vinculação à blockchain.Um permit, voto de governança, mensagem de bridge ou ordem off-chain assinados antes ou depois de um fork podem se comportar de forma inesperada se o contexto da blockchain não estiver claro.Os usuários devem ter cautela durante forks e divisões de blockchains.Carteiras e aplicativos devem atualizar corretamente os chain IDs e os separadores de domínio.Os contratos devem evitar armazenar em cache chain IDs de maneiras que criem risco de replay após uma divisão, a menos que o design trate disso de forma segura.A proteção contra replay em forks é uma questão de protocolo e de aplicativo.As duas camadas precisam ser consideradas.

Benefícios da proteção contra replay por nonce

O primeiro benefício é a autorização de uso único.Uma ação assinada pode ser consumida uma vez e rejeitada depois.O segundo benefício é a exclusividade das transações.Transações da mesma conta podem ser diferenciadas por valores de nonce.O terceiro benefício é a ordenação.Nonces sequenciais ajudam a definir a ordem válida das transações de uma conta.O quarto benefício é a segurança cross-chain quando combinada com chain IDs.As assinaturas podem ser vinculadas à rede pretendida.O quinto benefício é uma segurança melhor para contratos inteligentes.Os contratos podem impedir a repetição de permits, resgates, votos, transferências e mensagens de bridge.O sexto benefício é uma experiência mais segura para o usuário.As carteiras podem detectar com mais confiabilidade ações pendentes, transações bloqueadas e transações de substituição.

Riscos e limitações da proteção contra replay por nonce

A primeira limitação é que a proteção por nonce não impede o primeiro uso malicioso de uma mensagem assinada.Se um usuário assinar uma autorização prejudicial, o nonce impedirá apenas usos repetidos após a primeira execução.A segunda limitação é a complexidade do gerenciamento de transações.Nonces sequenciais podem bloquear transações e filas.A terceira limitação é o custo de armazenamento.Contratos que armazenam nonces aleatórios utilizados podem aumentar o uso de armazenamento on-chain.A quarta limitação é o risco de implementação.A ausência de uma verificação de nonce pode permitir o replay de assinaturas.A quinta limitação é a complexidade entre domínios.Um nonce pode proteger um contrato, mas não outro contrato ou outra blockchain.A sexta limitação é o risco de atualização.O estado dos nonces pode ser comprometido durante migrações de contratos se não for tratado com cuidado.

Erros comuns na proteção contra replay por nonce

Um erro comum é verificar uma assinatura sem verificar o nonce.Outro erro é verificar o nonce, mas esquecer de incrementá-lo ou marcá-lo como usado.Um terceiro erro é usar um nonce global para todos os usuários em vez de nonces individuais.Um quarto erro é omitir o chain ID dos dados assinados.Um quinto erro é omitir dos dados tipados o endereço do contrato verificador.Um sexto erro é aceitar assinaturas sem prazo de validade.Um sétimo erro é permitir que o mesmo nonce seja usado em diferentes tipos de ação.Um oitavo erro é não migrar o armazenamento de nonces durante atualizações.Um nono erro é usar nonces aleatórios previsíveis.Um décimo erro é presumir que a EIP-712 impede automaticamente todos os ataques de replay.

Boas práticas para desenvolvedores

Inclua um nonce em toda autorização off-chain capaz de alterar valor ou estado.Rastreie nonces por signatário, e não globalmente, a menos que o design exija claramente uma sequência global.Incremente o nonce ou marque-o como usado antes ou durante a execução, de forma que esse controle não possa ser contornado.Inclua o chain ID no domínio assinado quando o contexto da blockchain for relevante.Inclua o endereço do contrato verificador no domínio assinado.Inclua na mensagem assinada a intenção exata da função, o destinatário, o valor, o token, o prazo e os parâmetros relevantes.Use prazos ou períodos de validade para assinaturas encaminhadas por relayers.Separe os espaços de nonce para fluxos de trabalho não relacionados quando a execução paralela for necessária.Emita eventos quando autorizações forem usadas ou canceladas.Teste tentativas de replay, assinaturas cross-chain, atualizações de contratos, cancelamentos e caminhos de execução com falha antes da implantação.

Boas práticas para carteiras e aplicativos

Antes da assinatura, mostre aos usuários a blockchain, o contrato, o spender, o valor, o prazo, o contexto do nonce e o tipo de ação.Avise os usuários quando uma assinatura conceder poder de gasto ou uma autorização de longa duração.Use desafios de login novos para autenticação de carteiras.Marque os desafios de autenticação como utilizados após o login.Evite pedir que os usuários assinem mensagens vagas ou difíceis de ler.Quando possível, use dados tipados EIP-712 para assinaturas estruturadas.Gerencie os nonces de transações bloqueadas com opções claras para acelerar e cancelar.Não oculte dos usuários o funcionamento da substituição de transações.Ofereça suporte a faixas de nonce de abstração de contas somente quando a interface puder explicá-las com segurança.Proteja os usuários contra solicitações de assinatura antigas, expiradas ou referentes à blockchain errada.

Boas práticas para usuários

Leia os avisos da carteira antes de assinar qualquer mensagem ou transação.Confira a blockchain antes de assinar.Confira o contrato ou aplicativo que está solicitando a assinatura.Em aprovações no estilo permit, confira o token, o spender, o valor e o prazo.Rejeite assinaturas vagas, ilimitadas ou sem relação com a ação que você está realizando.Não assine mensagens de login de domínios suspeitos.Não presuma que um nonce torna segura uma assinatura maliciosa.Quando for prático, use carteiras de hardware ou multisig para saldos elevados.Revogue aprovações de tokens desnecessárias quando apropriado.Tenha cuidado ao configurar nonces manualmente, a menos que entenda o estado das transações pendentes.

Quando a proteção contra replay por nonce é mais importante

A proteção contra replay por nonce é mais importante quando assinaturas autorizam movimentação de valor.É importante para transações blockchain comuns.É importante para aprovações por permit.É importante para transferências de tokens sem gas.É importante para mensagens de bridge.É importante para votos e delegações de governança.É importante para resgates de airdrops e recompensas.É importante para desafios de login com carteira.É importante para transações multisig e UserOperations de abstração de contas.É importante em qualquer situação em que uma assinatura copiada possa causar efeitos repetidos ou indesejados.

Proteção contra replay por nonce em uma frase

A proteção contra replay por nonce usa valores de nonce exclusivos, rastreados e vinculados ao contexto para garantir que uma transação, mensagem ou autorização cripto assinada seja executada apenas uma vez na blockchain, no contrato e no contexto de aplicativo pretendidos.

Perguntas frequentes

O que significa proteção contra replay por nonce?

Proteção contra replay por nonce significa impedir que a mesma ação cripto assinada seja aceita mais de uma vez por meio da verificação e do consumo de um nonce exclusivo.

O que é um nonce no setor cripto?

Um nonce é um número ou valor exclusivo usado uma vez em um contexto específico para tornar única uma transação, mensagem ou autorização.

O que é um ataque de replay?

Um ataque de replay ocorre quando alguém copia uma ação assinada válida e a envia novamente para repetir ou usar indevidamente a autorização.

Como a Ethereum usa nonces?

As contas Ethereum usam um contador de nonce para que apenas uma transação com determinado nonce possa ser executada por conta.

O que é proteção contra replay por chain ID?

A proteção contra replay por chain ID vincula uma transação ou mensagem a uma blockchain específica para impedir que ela seja facilmente reutilizada em outra rede.

A EIP-712 impede automaticamente ataques de replay?

Não. A EIP-712 estrutura dados assinados, mas os aplicativos ainda precisam de verificações de nonce, prazos e separação de domínio correta.

Por que permits precisam de nonces?

Permits precisam de nonces para impedir que a mesma aprovação de token assinada seja enviada repetidamente.

Qual é a diferença entre nonce e prazo?

Um nonce torna uma assinatura de uso único, enquanto um prazo limita por quanto tempo ela permanece válida.

A proteção contra replay pode impedir phishing?

Não. A proteção contra replay pode impedir usos repetidos, mas não o primeiro uso prejudicial se o usuário assinar uma autorização maliciosa.

O que acontece se um nonce for reutilizado?

Se o tratamento do nonce funcionar corretamente, a segunda tentativa deve falhar. Porém, se o sistema tiver um design inadequado, a reutilização do nonce pode causar problemas de replay ou falhas de transação.

Por que contratos inteligentes precisam de suas próprias verificações de nonce?

Contratos inteligentes precisam de verificações de nonce porque os nonces comuns de conta não protegem automaticamente assinaturas off-chain, permits, resgates, votos ou mensagens de bridge.

Qual é o design mais seguro de proteção contra replay?

O design mais seguro combina nonces por signatário, chain ID, contrato verificador, detalhes exatos da ação, prazo, rastreamento do estado de uso e validação cuidadosa da assinatura.

Conclusão

A proteção contra replay por nonce é uma das bases de segurança menos visíveis das criptomoedas.Ela garante que uma assinatura válida não se torne um cheque em branco reutilizável.Uma assinatura blockchain comprova que uma chave privada aprovou uma mensagem, mas não comprova automaticamente que a aprovação é recente, ainda não foi utilizada ou está limitada a uma única execução.Um nonce acrescenta essa camada de atualidade.Quando o nonce é verificado e consumido corretamente, a mesma ação assinada não pode ser executada novamente.Isso protege transações comuns, permits de tokens, transferências sem gas, operações de contas inteligentes, aprovações multisig, mensagens de bridge, votos de governança, desafios de login, resgates de recompensas e muitos outros fluxos cripto.A proteção moderna contra replay envolve mais do que um contador.Ela costuma combinar nonces de conta, nonces no nível do contrato, IDs de autorização aleatórios, chain IDs, endereços de contratos verificadores, prazos, períodos de validade, faixas de nonce e mapeamentos de mensagens processadas.Cada camada resolve um tipo diferente de problema de replay.Nonces de conta impedem transações repetidas da mesma conta na mesma blockchain.Chain IDs impedem que transações sejam copiadas entre blockchains.Nonces de contrato impedem que mensagens assinadas sejam reutilizadas em aplicativos.Prazos impedem que assinaturas antigas continuem válidas para sempre.A separação de domínio impede que assinaturas sejam usadas no contrato ou aplicativo errado.Faixas de nonce permitem que contas inteligentes ofereçam suporte a fluxos de trabalho paralelos sem perder a proteção contra replay.Os riscos são graves quando esses controles não existem.Uma assinatura vulnerável a replay pode esvaziar fundos, repetir uma aprovação, duplicar um resgate, executar duas vezes uma mensagem de bridge ou distorcer a governança.Mesmo com proteção por nonce, os usuários ainda podem ser vítimas de phishing se assinarem uma autorização maliciosa uma única vez.Por isso, a proteção contra replay deve ser combinada com avisos claros na carteira, escopo restrito das assinaturas, design robusto de contratos e comportamento cuidadoso dos usuários.Para desenvolvedores, a regra é simples.Toda assinatura capaz de movimentar valor ou alterar um estado importante precisa de nonce, domínio e uma regra clara de consumo.Para carteiras, a regra é mostrar aos usuários exatamente o que estão autorizando antes de assinarem.Para usuários, a regra é tratar cada assinatura como uma ação real, não como uma confirmação inofensiva.A proteção contra replay por nonce não torna as criptomoedas livres de riscos.Ela torna prática a autorização assinada ao garantir que uma aprovação corresponda a um único uso pretendido, em um único contexto pretendido, e não a um número ilimitado de reproduções futuras.