Confirmations et finalité Ethereum : vérifier le bloc, pas seulement Success

Une transaction incluse dans Ethereum peut afficher Success avant la finalisation du bloc qui la contient. Success décrit l’exécution ; les confirmations décrivent les blocs ajoutés après l’inclusion selon la convention de comptage de l’outil. La finalité est un état de consensus distinct. Vérifiez le bloc de la transaction et la chaîne finalisée du réseau au lieu de considérer ces indications comme interchangeables.

Ce guide concerne Ethereum Mainnet après son passage à la preuve d’enjeu. Les rollups, ponts, autres chaînes et services de garde ont des règles supplémentaires. Il s’agit d’une vérification en lecture seule d’une transaction existante, pas d’une recommandation d’envoyer, d’annuler ou de répéter un paiement.

Séparer inclusion, exécution et finalité

La référence des reçus JSON-RPC renvoie le numéro et le hachage du bloc contenant la transaction, ainsi que son statut d’exécution. Une transaction en attente n’a pas encore de reçu d’inclusion. Le statut 1, affiché sous la forme 0x1 dans le JSON-RPC brut, indique une exécution réussie ; 0 ou 0x0 indique un échec.

Aucune de ces valeurs n’est un indicateur de finalité. Une transaction dont l’exécution a été annulée peut appartenir à un bloc finalisé. À l’inverse, une exécution réussie peut se trouver dans un bloc récent qui n’est pas encore finalisé. Attendre la finalité ne rendra pas réussie une action annulée.

Observation	Ce qu’elle indique	Ce qu’elle ne détermine pas
Reçu associé à un bloc	Le fournisseur signale l’inclusion dans ce bloc	Si ce bloc est finalisé
Statut du reçu Success	L’exécution de premier niveau a réussi	La réception des jetons prévus ou la finalité
Nombre de confirmations	L’outil indique la profondeur depuis l’inclusion	Une règle universelle de finalité ou de crédit
La chaîne finalisée inclut le bloc	La finalité du consensus couvre ce bloc	La sécurité du contrat ou le crédit par une plateforme

Si la transaction est encore en attente, consultez le guide des transactions en attente avant d’envisager une autre action. Si elle a réussi mais que les jetons attendus manquent, le guide des preuves de transfert traite cette question distincte.

Ce qu’Ethereum entend par finalisé

L’explication de la preuve d’enjeu d’Ethereum décrit les votes des validateurs sur des points de contrôle. La finalité offre une garantie plus forte que la simple proximité du sommet actuel de la chaîne : revenir sur un bloc finalisé nécessiterait une défaillance majeure du consensus avec de lourdes conséquences économiques. Cela ne promet pas que chaque application ou actif du bloc soit sûr.

L’explication de la couche applicative par Ethereum Foundation distingue safe head et blocs finalisés. Safe est un état intermédiaire de confiance, pas un synonyme de finalized. L’API d’exécution expose les étiquettes de bloc latest, safe et finalized pour demander la tête correspondante.

Employez ces termes dans leur contexte Ethereum. Un rollup peut utiliser des mots similaires pour des étapes impliquant un séquenceur et une chaîne parente. N’appliquez pas la procédure Mainnet sans changement à un transfert par pont et ne supposez pas qu’une transaction finalisée sur la chaîne source termine l’action du côté destinataire.

Aucun délai d’attente fixe n’est promis ici. Un retard, un fournisseur obsolète ou un problème réseau peut faire d’un minuteur un mauvais substitut à la vérification de l’état réel. Si un service demande un nombre précis de confirmations ou une autre condition, consultez séparément ses exigences officielles actuelles.

Comparer la transaction à la chaîne finalisée

Commencez par un explorateur Ethereum familier ou un lecteur public de blocs, ouvert par un chemin de confiance. Certains explorateurs affichent directement la finalité ; d’autres ne donnent que les détails du bloc. Les noms de méthodes ci-dessous désignent des lectures publiques, pas des instructions pour exécuter une transaction ou connecter un portefeuille. Cette procédure a été vérifiée dans la documentation le 27 octobre 2026 ; elle n’a pas été testée sur un portefeuille réel pour cet article.

1. Fixer l’identité de la transaction. Notez Ethereum Mainnet et le hachage complet de la transaction. Lisez son reçu et relevez le numéro et le hachage du bloc qui la contient, ainsi que le statut d’exécution. Un reçu indisponible reste un cas non résolu ; vérifiez le réseau et le fournisseur avant de parler d’échec.
2. Lire l’état de finalité signalé. Utilisez l’indication de bloc documentée de l’explorateur. Dans un lecteur JSON-RPC, eth_getBlockByNumber avec finalized demande la tête finalisée actuelle. Conservez le numéro de bloc renvoyé et l’heure d’observation. Les lectures non prises en charge ou échouées restent non vérifiées.
3. Comparer l’identité du bloc et sa hauteur. Si la tête finalisée est inférieure au bloc de la transaction, cette observation ne couvre pas encore la transaction. Si elle a atteint ou dépassé cette hauteur, relisez le bloc canonique à la hauteur d’inclusion et comparez son hachage à celui du bloc dans le reçu. Utilisez un fournisseur cohérent et à jour, et revérifiez le reçu si les hachages diffèrent.
4. Garder les limites du résultat explicites. Un bloc contenant la transaction qui correspond au reçu, à la tête finalisée ou derrière elle, étaye la finalité sur cette chaîne signalée. Un fournisseur obsolète ou incohérent peut encore donner des données trompeuses. Conservez les divergences et consultez le statut officiel ou l’assistance du fournisseur au lieu de forcer une réponse à partir d’instantanés mélangés.
5. Vérifier séparément l’exigence de l’application. Établissez ce qu’a réellement fait la transaction et si le service destinataire l’a créditée selon ses propres règles. N’envoyez pas un second paiement simplement parce qu’une galerie ou une page de dépôt ne s’est pas actualisée.

La documentation de recherche de blocs fournit le numéro et le hachage du bloc. La hauteur seule ne suffit pas lorsque les données divergent : deux blocs différents peuvent occuper la même hauteur lors d’une réorganisation de chaîne. Conservez le hachage avec le numéro afin que la comparaison identifie le bloc qui contenait la transaction.

Lire prudemment un nombre de confirmations changeant

Supposons qu’un reçu hypothétique place une transaction dans le bloc 100, tandis qu’un lecteur indique une tête finalisée à 98. La transaction peut déjà afficher Success, mais cette observation de la tête finalisée ne couvre pas le bloc 100. Si une lecture cohérente ultérieure indique la tête finalisée 102, vérifiez que le bloc canonique à 100 possède toujours le hachage du reçu avant de noter le bloc de la transaction comme couvert.

Ces numéros de bloc volontairement petits constituent une illustration inventée, pas une observation actuelle de Mainnet. Ils ne prédisent pas la durée nécessaire à la finalité et ne définissent pas de seuil de dépôt. Le nombre de confirmations affiché peut suivre une convention qui inclut le bloc contenant la transaction ; lisez la définition de l’outil avant de comparer les nombres de deux interfaces.

Une réorganisation peut déplacer une transaction dans un autre bloc ou la priver de sa précédente trace d’inclusion. Conservez le hachage d’origine, actualisez son reçu et comparez les données actuelles. Un changement de nombre ne prouve pas, à lui seul, que vous devez renvoyer le paiement. Une ancienne notification de portefeuille ne prime pas non plus sur un relevé de bloc plus récent.

Terminer par un relevé de bloc daté

Conservez ensemble le réseau, le hachage de transaction, le numéro et le hachage du bloc qui la contient, le statut d’exécution, la tête finalisée observée et l’heure de vérification. Indiquez si les données étaient cohérentes et si la finalité était directement signalée par l’explorateur ou déduite de la comparaison des blocs ci-dessus.

La finalité ne prouve pas que le bon jeton a atteint le bon destinataire, qu’un contrat est fiable ou qu’un service de garde a terminé sa propre comptabilité. Un écart de solde du portefeuille peut aussi être un problème d’affichage, de couverture ou de prix après la finalisation d’une transaction.

Aucune signature, autorisation ou phrase de récupération n’est nécessaire pour ces données publiques. Si un site en demande simplement pour afficher les confirmations ou la finalité, arrêtez ce parcours. Le résultat doit être un état observé précis avec ses limites, pas une promesse universelle selon laquelle une pastille verte signifie que toutes les parties du paiement sont terminées.