Sur Ethereum, le nonce d’une transaction sert à situer celle-ci dans la séquence du compte émetteur. Dans le fonctionnement ordinaire d’un compte externe, ou EOA, le nonce du compte correspond au compteur des transactions envoyées depuis ce compte. La transaction porte, elle aussi, un nonce : son numéro dans cette séquence.
Pour comprendre ce nonce de blockchain, trois repères sont essentiels : le compte concerné, la progression des numéros et le contexte dans lequel un compteur est consulté. Un nombre isolé explique peu de choses. Il faut également distinguer ce nonce de transaction du nonce de bloc rencontré dans les anciennes explications du minage d’Ethereum.
Quel compte et quelle séquence le nonce décrit-il ?
La documentation Ethereum sur les comptes présente le nonce, pour un compte externe, comme un compteur des transactions envoyées. Cette définition s’applique ici au parcours ordinaire des transactions d’un EOA. Elle ne constitue pas une règle universelle pour tous les types de comptes ni pour toutes les causes possibles de modification d’un nonce.
La documentation Ethereum sur les transactions décrit le champ nonce comme un compteur qui augmente séquentiellement et indique le numéro de transaction du compte. Les deux descriptions se complètent : l’une porte sur le compteur du compte, l’autre sur le numéro inscrit dans une transaction.
Gardez donc toujours l’émetteur à côté du nombre. Une mention telle que nonce 12 reste incomplète tant que le compte dont on examine la séquence n’est pas identifié. Pour organiser une lecture, notez par exemple le compte A, puis le nonce de la transaction étudiée. Cette présentation évite de détacher le numéro de son contexte.
Une progression séquentielle et une seule exécution par nonce
Dans ce parcours ordinaire, les numéros suivent une séquence croissante propre au compte. La documentation des comptes précise qu’une seule transaction portant un nonce donné peut être exécutée pour chaque compte. Elle rattache cette règle à la protection contre la répétition de l’exécution d’une transaction signée qui serait diffusée plusieurs fois.
Cette propriété doit conserver son périmètre. Elle ne démontre pas, à elle seule, une protection contre le rejeu entre réseaux, la finalité d’une transaction ou la réussite de l’opération prévue. Elle ne suffit pas non plus à expliquer les situations où plusieurs historiques de chaîne sont en concurrence.
Les passages utilisés ne détaillent pas les algorithmes d’admission, de rejet ou de classement des transactions en attente. La règle de séquence ne permet donc pas de prédire exactement le message qu’un logiciel affichera lorsqu’il reçoit une transaction donnée.
Un exemple entièrement hypothétique
Imaginons un relevé pédagogique du compte A avec trois transactions ordinaires portant les nonces 12, 13 et 14. Ces nombres inventés illustrent simplement la progression du compteur. Ils ne correspondent à aucun historique réel et ne constituent pas une consigne d’envoi.
Supposons ensuite que la transaction signée portant le nonce 13 soit diffusée à nouveau. Dans la séquence du compte A, la règle documentée d’exécution unique signifie que cette nouvelle diffusion ne permet pas de répéter son exécution avec le même nonce. L’exemple n’annonce rien sur la manière dont une application particulière traiterait ou afficherait cette diffusion.
Ce que demande eth_getTransactionCount
La méthode eth_getTransactionCount renvoie le nombre de transactions envoyées depuis une adresse. Sa requête comporte l’adresse et un paramètre de bloc. La documentation JSON-RPC d’Ethereum indique que ce second paramètre peut être un numéro de bloc ou une balise, notamment latest ou pending.
Dans l’exemple fourni par cette documentation, latest désigne l’état au dernier bloc. Il faut donc conserver le choix du bloc ou de la balise lorsqu’on relève un compteur, plutôt que de noter uniquement le résultat numérique.
Il s’agit d’une déduction à partir des paramètres documentés : puisque la méthode renvoie un compteur pour une adresse et accepte une sélection de bloc, ces deux éléments sont nécessaires pour interpréter sa réponse. Cette déduction n’implique pas que deux sélections différentes produisent obligatoirement deux nombres différents.
Pour prolonger l’exercice hypothétique, préparez deux lignes : compte A avec latest, puis compte A avec pending. Laissez les résultats vides. Avant même d’ajouter des valeurs, les intitulés rendent visible le contexte de chaque demande. Si des résultats sont ensuite comparés, leurs paramètres doivent rester associés aux nombres.
Ce que le paramètre pending ne permet pas d’établir ici
Le passage documentaire confirme que pending est une balise acceptée. Il ne définit toutefois pas la construction de l’état en attente et ne garantit pas que le résultat prend en compte toutes les transactions en attente du réseau. Cette explication ne fournit donc aucune garantie d’exhaustivité.
C’est une limite des éléments disponibles, et non une description du fonctionnement d’un fournisseur particulier. Pour expliquer précisément le contenu d’une réponse pending chez un prestataire, il faudrait des sources primaires supplémentaires et une vérification éditoriale.
Il serait également injustifié d’affirmer que les compteurs obtenus avec latest et pending doivent toujours différer. Leur soustraction ne peut pas être présentée, sur la seule base du passage fourni, comme un inventaire complet des transactions en attente. Le point établi reste plus précis : la méthode demande un compteur pour une adresse dans un contexte de bloc choisi.
Le nonce de transaction diffère du nonce historique de minage
La documentation historique de la preuve de travail d’Ethereum décrit une recherche par essais successifs : les mineurs cherchaient un nonce pour un bloc. Elle précise aussi qu’Ethereum a abandonné la preuve de travail en 2022 pour passer à la preuve d’enjeu. Cette explication du minage appartient donc à son histoire.
La distinction découle de deux fonctions documentées. Le nonce d’une transaction ordinaire d’EOA indique sa position dans la séquence du compte ; le nonce historique de minage était une valeur recherchée pour un bloc. Leur différence de rôle est une déduction de cette comparaison, et non une formulation directement extraite d’une seule source.
Lorsqu’un texte emploie le mot nonce, commencez par repérer l’objet décrit : une transaction rattachée à un compte ou un bloc dans une explication historique de preuve de travail. Cette simple lecture du contexte évite de confondre les deux mécanismes.
Une checklist pour interpréter un nonce sans surconclure
- Identifier le compte émetteur et vérifier que l’explication concerne le parcours ordinaire d’un EOA.
- Lire le nonce de transaction comme son numéro dans la séquence de ce compte.
- Garder la règle d’exécution unique dans ce périmètre, sans en déduire la réussite ou la finalité.
- Pour un compteur RPC, conserver l’adresse et le numéro de bloc ou la balise demandée.
- Ne pas attribuer au seul paramètre
pendingune garantie de visibilité exhaustive. - Replacer toute référence au minage d’Ethereum dans son contexte historique.
Pour compléter cette lecture du compteur avec celle d’un enregistrement de transaction, consultez notre guide pour lire une transaction Ethereum dans un explorateur de blocs. Le nonce reste ici un élément de séquence : son explication ne remplace pas l’examen des autres informations de la transaction.
Contenu pédagogique préparé avec l’aide de l’IA à partir de la documentation Ethereum fournie. L’attribution des sources ne constitue pas une garantie de sécurité ; les interprétations dépassant ces éléments nécessitent une vérification éditoriale.