Transactions, blocs et finalité

De la demande à l'enregistrement

Appuyer sur Envoyer déclenche une séquence en cinq étapes distinctes. Votre portefeuille construit une transaction décrivant ce qui doit changer. Vous l'autorisez par une signature produite avec votre clé privée. Le portefeuille la diffuse aux nœuds du réseau, qui la confrontent aux règles : la signature est-elle valide, le compte a-t-il assez, les frais suffisent-ils ? Un validateur ou un mineur inclut ensuite les transactions valides dans un bloc. Enfin, d'autres nœuds vérifient ce bloc et prolongent la chaîne par-dessus.

Seule la deuxième étape vous concerne, et elle est irréversible d'une manière que la plupart des interfaces ne soulignent pas. Une fois une signature valide diffusée, aucune partie du reste de la séquence ne redemande votre consentement. Tout ce que vous pouvez maîtriser se joue avant d'approuver.

Entre la diffusion et l'inclusion, une transaction attend dans une zone souvent appelée mempool. En période de congestion, la file s'allonge et les transactions offrant des frais plus élevés sont généralement retenues en premier. C'est pourquoi un transfert peut sembler bloqué : il n'est pas perdu, il fait la queue.

Confirmations et finalité ne sont pas la même chose

Une confirmation est la preuve qu'une transaction a été incluse dans un bloc. Chaque bloc supplémentaire construit au-dessus rend la réécriture de cet historique plus coûteuse, aussi les services attendent-ils souvent plusieurs confirmations avant de créditer un compte. Le nombre retenu est une politique de risque, pas une constante du protocole.

Certains réseaux ajoutent une finalité explicite : passé un point défini, le protocole considère un bloc comme acquis, et le renverser exigerait une attaque que les règles rendent prohibitivement coûteuse. D'autres n'offrent qu'une assurance probabiliste qui se renforce avec la profondeur. Aucune approche n'est universellement meilleure, mais la conséquence pratique diffère, et une règle apprise sur un réseau peut être fausse ailleurs.

L'énoncé général honnête est étroit : plus de profondeur signifie moins de risque de renversement, la profondeur requise dépend du réseau et de l'enjeu, et aucun réseau ne propose d'annulation par un service client après coup.

Lisez l'état avant de réagir

En attente, remplacée, échouée et confirmée sont quatre états différents appelant quatre réponses différentes. En attente signifie diffusée mais pas encore incluse — la réponse est généralement d'attendre, ou d'utiliser l'option de remplacement avec frais majorés si le portefeuille la propose. Remplacée signifie qu'une transaction ultérieure de même nonce a pris sa place. Échouée signifie que le réseau a traité la tentative et rejeté le résultat.

Un appel de contrat intelligent qui échoue peut tout de même consommer des frais. Cela surprend, mais découle du fonctionnement du réseau : les validateurs ont dépensé du calcul réel pour exécuter le code et constater qu'il annulait, et ce travail est payé quel que soit le résultat.

L'erreur la plus coûteuse à ce stade est d'envoyer deux fois le même paiement parce que le premier semblait sans effet. Avant de renvoyer quoi que ce soit, trouvez le hash de la transaction et consultez-le sur un explorateur du bon réseau. Un transfert simplement lent et un transfert réellement échoué se ressemblent dans une interface de portefeuille et diffèrent totalement sur la chaîne.

• Localisez le hash de la transaction avant toute conclusion.
• Vérifiez-le sur un explorateur du réseau réellement utilisé.
• Distinguez l'état du service de l'état du réseau — ils peuvent diverger.
• Ne renvoyez jamais avant de connaître l'état de la première tentative.

Ce que la chaîne montre, et ce qu'elle ne montre pas

Les explorateurs publics peuvent afficher adresses, montants, appels de contrats, frais, horodatages et états. Cela rend possible une vérification indépendante sans demander la permission à quiconque, ce qui est réellement précieux quand un service et un réseau divergent sur ce qui s'est passé.

Ce qu'un explorateur ne montre pas, c'est qui est qui. Il n'affiche pas de nom légal et ne peut pas dire si une adresse appartient à une personne, une entreprise ou un contrat. Mais l'activité peut souvent être reliée — par réutilisation d'adresses, par des services ayant vérifié une identité, par des publications ou par l'analyse des schémas de transactions. Public ne veut pas dire anonyme, et un enregistrement permanent aujourd'hui pourra être analysé demain avec de meilleurs outils.