Aller au contenu
Financial Context Wiki

Espaces de noms des nonces en crypto

Guide pratique des nonces de comptes Ethereum, des nonces applicatifs anti-rejeu, des lanes key-sequence ERC-4337 et des nonces de recherche des en-têtes Proof of Work.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un nonce est une valeur dont le sens provient d’un espace de noms précis du protocole. Ce n’est pas toujours un nombre aléatoire ni une valeur universelle « utilisée une seule fois ». Sur Ethereum, le nonce d’état d’un compte externe ordonne et valide les transactions de cet émetteur. Un contrat peut tenir des nonces applicatifs distincts dans son stockage pour des permits ou des intentions signées. Les smart accounts ERC-4337 peuvent employer un nonce structuré de UserOperation avec des lanes parallèles de clé et séquence. Dans le Proof of Work de Bitcoin, le nonce de l’en-tête est un champ de recherche borné servant à tester des hash candidats.

Ces valeurs ne sont pas interchangeables. Le nonce d’un compte Ethereum ne protège pas une signature arbitraire de données typées si l’application ne vérifie pas son propre domaine et son champ anti-rejeu. Un nonce d’en-tête PoW n’ordonne pas les transactions de comptes. La même valeur numérique utilisée par d’autres émetteurs, contrats, chaînes ou lanes décrit un état différent.

Fonctionnement

  1. Identifiez l’espace de noms avant de lire le nombre : transaction EOA, état d’un compte de contrat, stockage applicatif, UserOperation ERC-4337 ou en-tête PoW nommé. Fixez ID de chaîne, fork et version, compte ou owner, contrat vérificateur et domaine, EntryPoint ou format d’en-tête.
  2. Lisez l’état faisant autorité avec un block tag explicite. Séparez nonce EOA canonique, compteur pending du fournisseur, valeur applicative nonces(owner), clé et séquence ERC-4337 et compteur local de recherche du mineur. L’accord de plusieurs RPC ne remplace pas la vérification du reçu et de l’état canoniques.
  3. Constituez la filiation signée : émetteur ou owner, chaîne et domaine, nonce, payload, deadline, contrat vérificateur, hash de transaction ou de message et chaque remplacement. Pour les transactions Ethereum, les règles de domaine comme EIP-155 complètent le nonce ; celui-ci seul ne protège pas entièrement du rejeu cross-chain.
  4. Allouez dans la bonne lane. Coordonnez les signataires EOA concurrents pour n’attribuer chaque séquence canonique qu’une fois ; conservez gaps et filiation des remplacements de même nonce. Pour une application ou un smart account, suivez les règles atomiques de vérification, d’incrément et de lanes du contrat, pas un compteur global supposé.
  5. Soumettez selon les bonnes règles d’admission. Les politiques pending et de remplacement des execution clients sont locales ; les bundlers ERC-4337 valident les objets UserOperation selon EntryPoint et le compte ; une signature EIP-712 ou permit peut être relayée dans la transaction d’un tiers. Aucune acceptation locale ne prouve l’inclusion canonique.
  6. Suivez l’issue complète : rejetée, pending, queued, remplacée, incluse avec succès, incluse avec status = 0, retirée par réorganisation ou finalisée. Une transaction Ethereum incluse avance le nonce de l’émetteur même si l’EVM exécute un revert ; le nonce applicatif modifié dans l’appel est alors restauré.
  7. Rapprochez avant tout nouvel essai. Vérifiez reçu canonique, hash du bloc, nonce de l’émetteur, stockage applicatif, événement ou reçu ERC-4337 et finalité. Pour PoW, vérifiez l’en-tête complet et la target, pas seulement le nonce ; une fois le champ fini épuisé, les mineurs modifient d’autres données qui affectent l’en-tête.

Exemples détaillés

  • Un revert inclus consomme le nonce EOA. Le nonce canonique de l’émetteur est 12. Une transaction de nonce 12 est incluse avec status = 0, consomme 50,000 gas à 30 gwei et coûte 50,000 * 30 gwei = 0.0015 ETH. Les changements du contrat sont restaurés, mais le nonce canonique passe à 13. Si une réorganisation retire ce bloc, il peut revenir à 12 ; le portefeuille doit revérifier toute la filiation.
  • Nonces applicatif et du relayer séparés. Un owner a un nonce EOA de 18 ; un token ERC-2612 renvoie nonces(owner) = 7 ; le nonce EOA du relayer est 42. Un permit réussi consomme le nonce applicatif 7, qui devient 8 ; l’inclusion porte le nonce du relayer à 43 et laisse celui de l’owner à 18. Si tout l’appel exécute un revert, le relayer passe néanmoins à 43, mais le stockage du token revient à 7.
  • Lanes ERC-4337. Selon l’expression pédagogique nonce = (key << 64) | sequence, la clé 5 et la séquence 9 donnent 5 * 2^64 + 9 = 92,233,720,368,547,758,089 ; la séquence 10 donne 92,233,720,368,547,758,090. La clé indépendante 6, séquence 0, donne 110,680,464,442,257,309,696. Le parallélisme dépend toujours de la validation du smart account et reste distinct du nonce EOA du bundler.
  • Nonce de recherche PoW. Le nonce de l’en-tête Bitcoin comporte 32 bits, soit 2^32 = 4,294,967,296 candidats numériques. À un débit hypothétique de 100 TH/s, parcourir cet espace prend 4,294,967,296 / 100,000,000,000,000 = 0.00004294967296 seconds = 42.94967296 microseconds. Les mineurs changent l’extraNonce de la coinbase, le temps ou l’ensemble des transactions pour modifier la racine de Merkle et obtenir de nouveaux en-têtes ; ce champ n’est pas l’état anti-rejeu d’un compte.

Risques

  • Confusion des espaces EOA, contrat, application, ERC-4337 et PoW.
  • Lecture du nonce sur la mauvaise chaîne, le mauvais fork, contrat ou EntryPoint.
  • Réponse RPC obsolète, incohérente ou malveillante.
  • Attribution du même nonce EOA par des signataires concurrents.
  • Blocage de candidates locales ultérieures par un gap de nonce.
  • Traitement du nonce pending d’un fournisseur comme état canonique.
  • Oubli qu’un revert inclus consomme nonce EOA et gas.
  • Non-restauration du nonce et de la filiation après réorganisation.
  • Remplacement de même nonce ne satisfaisant pas la politique de frais.
  • Hypothèse que le remplacement a supprimé globalement l’originale.
  • Corrélation de valeurs égales issues d’émetteurs ou domaines différents.
  • Omission de l’ID de chaîne ou d’un autre séparateur de domaine requis.
  • Défaut de vérification et d’incrément atomiques du nonce applicatif.
  • Owner, deadline, domain separator ou token ERC-2612 erroné.
  • Rejeu d’une signature entre chaîne, contrat ou version.
  • Nonce d’un compte de contrat interprété comme compteur générique d’appels.
  • Mauvais empaquetage de la clé ou largeur de séquence ERC-4337.
  • Confusion du nonce EOA du bundler et du nonce UserOperation du smart account.
  • Mise à niveau de proxy ou collision de stockage modifiant le comportement.
  • Nonce PoW fini traité comme autorisation, état anti-rejeu ou preuve isolée.

Idées reçues courantes

  • Tout champ nommé nonce signifie la même chose et n’est utilisé qu’une fois globalement.
  • Un nonce supérieur rend une transaction plus sûre, rapide ou finale.
  • Une transaction Ethereum qui exécute un revert ne consomme pas le nonce de l’émetteur.
  • Un nonce seul empêche tout rejeu entre chaînes, contrats et messages typés.
  • Tout smart account ERC-4337 possède un compteur linéaire identique au nonce EOA.

Sujets associés

Sources

Navigation

Rechercher dans le wiki...