Ir para o conteúdo
Financial Context Wiki

Namespaces de nonce em cripto

Guia prático sobre nonces de contas Ethereum, nonces de aplicação contra replay, faixas key-sequence do ERC-4337 e nonces de busca em cabeçalhos Proof of Work.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Nonce é um valor cujo significado vem de um namespace específico do protocolo. Nem sempre é aleatório ou um valor universal “usado uma vez”. No Ethereum, o nonce de estado de uma conta de propriedade externa ordena e valida as transações daquele remetente. Um contrato pode manter nonces de aplicação separados no storage para permits ou intenções assinadas. Smart accounts ERC-4337 podem usar um nonce estruturado de UserOperation com faixas paralelas de chave e sequência. No Proof of Work do Bitcoin, o nonce do cabeçalho é um campo de busca limitado usado para testar hashes candidatos.

Esses valores não são intercambiáveis. Um nonce de conta Ethereum não protege uma assinatura arbitrária de dados tipados se a aplicação não validar seu próprio domínio e campo contra replay. Um nonce de cabeçalho PoW não ordena transações de contas. O mesmo número usado por remetentes, contratos, chains ou faixas diferentes representa estados distintos.

Como funciona

  1. Identifique o namespace antes de ler o número: transação EOA, estado de conta contratual, storage de aplicação, UserOperation ERC-4337 ou cabeçalho PoW específico. Fixe chain ID, fork e versão, conta ou owner, contrato verificador e domínio, EntryPoint ou formato do cabeçalho conforme aplicável.
  2. Leia o estado autoritativo com block tag explícito. Separe o nonce canônico da EOA da contagem pending do provedor, o valor nonces(owner) da aplicação, a chave e sequência ERC-4337 e o contador local de busca do minerador. Concordância entre RPCs não substitui a verificação de recibo e estado canônicos.
  3. Construa a linhagem assinada. Registre remetente ou owner, chain e domínio, nonce, payload, deadline, contrato verificador, hash da transação ou mensagem e cada substituição. Em transações Ethereum, regras de domínio como EIP-155 complementam o nonce; sozinho, ele não fornece proteção completa contra replay entre chains.
  4. Aloque na faixa correta. Coordene signatários EOA simultâneos para atribuir cada sequência canônica uma única vez; preserve gaps e linhagem de substituição com o mesmo nonce. Em uma aplicação ou smart account, siga as regras atômicas de verificação e incremento e de faixas do contrato, em vez de presumir um contador global.
  5. Envie sob as regras de admissão corretas. Políticas pending e de substituição do execution client são locais; bundlers ERC-4337 validam objetos UserOperation segundo EntryPoint e conta; uma assinatura EIP-712 ou permit pode ser retransmitida dentro da transação de outra pessoa. Nenhuma aceitação local prova inclusão canônica.
  6. Acompanhe o resultado completo. Diferencie rejeitada, pending, queued, substituída, incluída com sucesso, incluída com status = 0, removida por reorganização e finalizada. Uma transação Ethereum incluída avança o nonce do remetente mesmo quando a EVM reverte; o nonce de aplicação atualizado dentro da chamada revertida também volta atrás.
  7. Reconcilie antes de tentar novamente. Verifique recibo canônico, hash do bloco, nonce do remetente, storage da aplicação, evento ou recibo ERC-4337 e finalidade. Em PoW, verifique cabeçalho completo e target, não apenas nonce; se o campo finito se esgotar, mineradores alteram outros dados que afetam o cabeçalho para criar novo espaço de busca.

Exemplos resolvidos

  • Revert incluído consome o nonce EOA. O nonce canônico do remetente é 12. Uma transação de nonce 12 é incluída com status = 0, usa 50,000 gas a 30 gwei e custa 50,000 * 30 gwei = 0.0015 ETH. As mudanças do contrato revertem, mas o nonce canônico passa a 13. Se uma reorganização remover o bloco, ele pode voltar a 12; a carteira deve conferir toda a linhagem.
  • Nonces de aplicação e relayer são separados. Um owner tem nonce EOA 18; um token ERC-2612 informa nonces(owner) = 7; o nonce EOA do relayer é 42. Um permit bem-sucedido consome o nonce de aplicação 7, tornando-o 8; a inclusão leva o nonce do relayer a 43 e mantém o nonce do owner em 18. Se toda a chamada reverter, o relayer ainda passa a 43, mas o storage do token retorna a 7.
  • Faixas ERC-4337. Sob a expressão didática nonce = (key << 64) | sequence, chave 5 e sequência 9 resultam em 5 * 2^64 + 9 = 92,233,720,368,547,758,089; sequência 10 resulta em 92,233,720,368,547,758,090. A chave independente 6, sequência 0, resulta em 110,680,464,442,257,309,696. O uso paralelo ainda depende da validação da smart account e é separado do nonce EOA do bundler.
  • Nonce de busca PoW. O nonce do cabeçalho Bitcoin tem 32 bits, portanto existem 2^32 = 4,294,967,296 candidatos numéricos. A hipotéticos 100 TH/s, percorrer esse espaço leva 4,294,967,296 / 100,000,000,000,000 = 0.00004294967296 seconds = 42.94967296 microseconds. Mineradores alteram extraNonce da coinbase, horário ou conjunto de transações para mudar a raiz de Merkle e obter novos cabeçalhos; esse campo não é estado contra replay de contas.

Riscos

  • Confundir namespaces EOA, contrato, aplicação, ERC-4337 e PoW.
  • Ler o nonce da chain, fork, contrato ou EntryPoint errados.
  • Usar resposta RPC desatualizada, incoerente ou maliciosa.
  • Signatários simultâneos alocarem o mesmo nonce EOA.
  • Um gap de nonce bloquear candidatas locais posteriores.
  • Tratar o nonce pending do provedor como estado canônico.
  • Esquecer que um revert incluído consome nonce EOA e gas.
  • Não restaurar nonce e linhagem após uma reorganização.
  • Uma substituição não cumprir a política de comissão do nó.
  • Presumir que a substituição apagou globalmente a transação antiga.
  • Correlacionar números iguais de remetentes ou domínios diferentes.
  • Omitir chain ID ou outro separador de domínio exigido.
  • Não verificar e incrementar atomicamente um nonce de aplicação.
  • Owner, deadline, domain separator ou token ERC-2612 incorretos.
  • Replay de assinatura entre chain, contrato ou versão.
  • Interpretar nonce de conta contratual como contador genérico de chamadas.
  • Empacotar chave ou largura de sequência ERC-4337 erradas.
  • Misturar nonce EOA do bundler e nonce UserOperation da smart account.
  • Upgrade de proxy ou colisão de storage alterar o nonce da aplicação.
  • Tratar nonce PoW finito como autorização, estado contra replay ou prova isolada.

Equívocos comuns

  • Todo campo chamado nonce tem o mesmo significado e é usado globalmente uma vez.
  • Um nonce maior torna a transação mais segura, rápida ou final.
  • Uma transação Ethereum que reverte não consome o nonce do remetente.
  • Um nonce sozinho impede todo replay entre chains, contratos e mensagens tipadas.
  • Toda smart account ERC-4337 tem um contador linear idêntico ao nonce EOA.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...