Comment une transaction est-elle vérifiée sur un réseau de cryptomonnaie ? Sur Ethereum, plusieurs questions se succèdent : quel compte a autorisé l’opération, quel résultat produit son exécution, dans quel bloc elle est incluse et comment le réseau parvient à un accord. Le mot « vérifiée » peut désigner des étapes différentes.
Cette distinction devient essentielle lorsqu’un contrat échoue : une transaction peut figurer dans un bloc validé tout en ayant échoué pendant son exécution. À l’inverse, une exécution réussie ne suffit pas à démontrer que tous les objectifs de l’utilisateur ont été atteints. L’explication suivante concerne les transactions Ethereum ordinaires ; elle ne constitue ni un modèle universel des cryptomonnaies ni un inventaire complet des règles de validation.
1. La signature établit l’autorisation du compte
Une transaction Ethereum ordinaire porte une signature produite avec la clé privée de l’émetteur. Cette signature authentifie une autorisation liée à cette clé. Le champ from désigne l’adresse de l’émetteur dans la présentation habituelle d’une transaction.
Il faut interpréter cette autorisation dans son périmètre : elle ne démontre pas l’identité civile d’une personne, sa compréhension de l’opération ou son accord avec le résultat finalement obtenu. L’authentification du compte et l’appréciation du résultat répondent à des questions distinctes.
La transaction comporte également un nonce, compteur qui augmente séquentiellement et indique le numéro de transaction du compte. Cette définition permet de comprendre le rôle du champ, sans décrire toutes les règles de contrôle du nonce ou de remplacement d’une transaction en attente.
Ces éléments sont présentés dans la documentation Ethereum sur les transactions. Leur attribution à une source ne transforme pas la signature en garantie générale de sécurité ou de réussite.
2. Diffuser une transaction et l’exécuter sont deux étapes
Le cycle de vie décrit par Ethereum commence par la diffusion de la transaction sur le réseau et son ajout à un ensemble de transactions en attente. Cette présentation simplifiée ne garantit ni sa réception par chaque nœud ni son inclusion future.
Le client d’exécution traite les transactions diffusées dans la machine virtuelle Ethereum, ou EVM. L’exécution détermine ce que produisent les instructions selon les règles applicables. L’inclusion désigne leur inscription dans un bloc validé. Pour figurer dans la chaîne, une transaction doit être incluse dans un tel bloc ; cette exigence ne constitue pas une promesse d’inclusion.
La réexécution permet aussi de reconstruire l’état de la chaîne. Lors d’une synchronisation complète, ou full sync, un nœud régénère progressivement cet état en exécutant chaque bloc depuis le bloc initial. Il ne se contente donc pas de reprendre un résultat annoncé.
Cette dernière description concerne précisément la synchronisation complète. D’autres modes peuvent partir de points de contrôle de confiance ou traiter autrement l’historique. La documentation sur les nœuds et les clients explique ces rôles ; elle ne permet pas d’affirmer que chaque nœud rejoue systématiquement toute l’histoire.
3. Le consensus dépasse la validation d’un seul nœud
Sur Ethereum, le client de consensus met en œuvre un mécanisme de preuve d’enjeu permettant au réseau de parvenir à un accord à partir des données validées par le client d’exécution. La validation de l’exécution et l’accord du réseau sont donc liés, mais remplissent des fonctions distinctes.
Le cycle de vie distingue également l’inclusion dans un bloc des étapes ultérieures de justification et de finalisation. Ces termes ne sont pas des synonymes de première apparition dans un bloc. Cette description ne fixe aucun délai garanti et ne justifie pas une progression inconditionnelle.
On peut en déduire une limite précise : puisque la validation d’exécution fournit les données nécessaires à l’accord du réseau et que la finalisation constitue une étape distincte, le résultat local d’un seul nœud ne suffit pas à établir la finalité du réseau. Il s’agit d’une déduction fondée sur cette séparation des rôles, sans affirmation sur un seuil de vote ou un délai.
Lorsqu’une explication annonce qu’une transaction est validée, demandez-vous donc quelle étape elle décrit : le traitement local, l’inclusion ou un stade ultérieur du consensus.
4. Le statut d’exécution se lit séparément de l’inclusion
Dans les reçus Ethereum comportant un champ status, la valeur 1 indique une exécution réussie et la valeur 0 une exécution échouée. Le champ blockNumber indique le bloc contenant la transaction ; il ne démontre pas, à lui seul, sa finalité.
La documentation JSON-RPC d’Ethereum définit ces champs. Elle distingue aussi les reçus antérieurs à Byzantium, qui indiquent une racine d’état à la place du statut. La lecture du champ status doit conserver cette limite historique.
Une déduction découle de ces définitions : puisqu’un reçu identifie un bloc contenant la transaction tout en pouvant signaler un échec, l’inclusion dans un bloc validé n’implique pas une exécution réussie. L’acceptation par le protocole et le résultat de l’exécution ne sont pas équivalents.
Une autre limite découle du caractère binaire du statut : celui-ci décrit la réussite ou l’échec de l’exécution, sans comparer le résultat à tous les objectifs personnels de l’utilisateur. Pour établir qu’un résultat particulier a été obtenu, il faut des éléments concernant ce résultat.
Pour comprendre séparément comment ces informations sont présentées, consultez notre guide pour lire une transaction Ethereum dans un explorateur de blocs.
5. REVERT annule les changements de l’exécution concernée
L’instruction REVERT interrompt l’exécution EVM concernée, la considère comme échouée et annule ses changements d’état. Le périmètre est essentiel : cette règle ne permet pas d’affirmer que tout le gas, tous les frais, les effets sur le nonce ou les effets extérieurs sont restaurés.
Un REVERT exécuté normalement ne consomme pas tout le gas restant. Cela ne signifie pas que le calcul précédent était gratuit ou que le gas déjà consommé est restitué. Si le gas restant ne couvre pas le coût de REVERT, ou si la pile contient trop peu d’éléments, l’instruction se comporte comme une exception de manque de gas et consomme tout le gas du contexte d’exécution concerné.
L’EIP-140, qui spécifie REVERT, décrit également le signal d’échec renvoyé au contrat appelant lorsqu’un contrat appelé effectue un REVERT.
La déduction reste limitée : puisque l’annulation concerne l’exécution appelée et que l’appelant reçoit un signal d’échec, ce seul REVERT ne démontre pas l’annulation de tous les effets de l’appelant. Son comportement ultérieur et le résultat global de la transaction nécessitent des éléments supplémentaires.
6. Un exemple hypothétique et une liste de contrôle
Exemple entièrement hypothétique : Maya autorise une transaction Ethereum ordinaire destinée à exécuter une opération dans un contrat. La transaction est diffusée, puis incluse dans un bloc validé. Son reçu indique le bloc, mais porte un statut 0. Ces informations sont compatibles : l’inclusion est établie dans le bloc indiqué, tandis que l’exécution a échoué.
Supposons que l’exécution concernée ait utilisé REVERT. Ses changements d’état sont annulés dans ce périmètre, avec les réserves sur le gas expliquées plus haut. Dans une autre version de cet exemple, un statut 1 indiquerait une exécution réussie, sans démontrer à lui seul que tout le résultat espéré par Maya a été obtenu.
Pour évaluer une explication de la vérification, utilisez cette liste de contrôle :
- Identifier le réseau et limiter les conclusions présentées ici à Ethereum.
- Distinguer l’autorisation par signature des preuves concernant le résultat.
- Séparer diffusion, inclusion dans un bloc et étapes ultérieures du consensus.
- Interpréter le statut d’exécution indépendamment du numéro de bloc.
- Limiter l’annulation par REVERT à l’exécution concernée, avec ses exceptions relatives au gas.
- Rechercher les éléments établissant le résultat précis attendu.
Contenu pédagogique préparé avec l’aide de l’IA. Les affirmations et leur correspondance avec les sources restent soumises à une vérification éditoriale indépendante.