Aller au contenu
Financial Context Wiki

Confirmations de bloc

Guide fondé sur la vérification de la profondeur de confirmation PoW, des états safe et finalized en PoS, du remplacement en mempool, des réorganisations et de la politique d'accréditation des dépôts.

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

Une confirmation de bloc est une affirmation propre à un observateur et à un protocole : une transaction est incluse dans un bloc de la chaîne canonique actuelle de cet observateur. La convention inclusive courante de Bitcoin Core compte le bloc contenant la transaction comme première confirmation. Pour une hauteur d’inclusion h et une hauteur de meilleure chaîne H, la profondeur vaut H - h + 1. Certains services n’affichent que les descendants sous la forme H - h ; la convention doit donc être précisée.

En Proof of Work, la profondeur réduit le risque de réorganisation sous des hypothèses explicites, sans créer de seuil magique de finalité absolue. Les systèmes Proof of Stake peuvent exposer des états natifs du protocole. Ethereum distingue latest, safe et finalized ; un nombre fixe de blocs, slots ou minutes ne remplace pas ces étiquettes. Détecté, crédité, négociable et retirable sont des états internes distincts de la plateforme, même après satisfaction du seuil de la chaîne.

Attente prévue
1.2 min
Gamme illustrative
54s - 1.5 min

Les résultats sont des approximations pédagogiques. Ils excluent les règles du site, les taxes, la latence, le comportement d'Oracle et d'autres paramètres spécifiques au protocole, sauf indication contraire.

Fonctionnement

  1. Fixez chaîne et réseau, actif, identifiant de transaction, nœud ou API, instant de l’observation, modèle de consensus et convention de comptage. Vérifiez destinataire, montant et éventuel memo ou tag avant de traiter un hachage correspondant comme le paiement prévu.
  2. Séparez signée, diffusée, acceptée dans le mempool local d’un nœud et propagée. Les mempools sont des vues de policy, pas une file de consensus mondiale. Vérifiez frais, ancêtres non confirmés, Replace-by-Fee ou remplacement avec le même nonce et dépenses conflictuelles.
  3. Vérifiez l’inclusion avec le hachage du bloc, sa hauteur, l’index de transaction et l’ascendance canonique, pas seulement la hauteur ou un badge d’explorateur. Sur une chaîne de comptes, contrôlez aussi statut du reçu, logs et changement d’état effectif ; une exécution incluse peut tout de même revert.
  4. Appliquez le modèle de consensus. En PoW, annoncez la convention, calculez la profondeur et comparez plusieurs vues de la meilleure chaîne et du travail cumulé. En PoS, interrogez les états natifs head, safe, justified ou finalized ; ne les déduisez pas d’une distance fixe en blocs ou slots.
  5. Suivez le cycle de vie avec des états explicites : créée, diffusée, acceptée dans le mempool local, incluse, profondeur canonique ou état safe/finalized, réorganisée, réincluse, remplacée ou conflictuelle. Une réorganisation ne garantit pas le retour de la transaction initiale dans chaque mempool.
  6. Tenez séparément le registre de la plateforme : observée, seuil réseau atteint, créditée, négociable et retirable. Appliquez sa policy actuelle selon l’actif, le réseau, le montant et l’incident ; maintenance, conformité et contrôle manuel peuvent ajouter des délais indépendants.
  7. Recoupez des nœuds ou fournisseurs indépendants et surveillez jusqu’à l’état requis. Consignez hachages, hauteurs, horodatages, étiquettes RPC et version de la policy ; simulez remplacement, réorganisation, retard de finalité, nœud obsolète, relais de bridge et panne de plateforme.

Exemples détaillés

  • Convention de comptage. Une transaction Bitcoin se trouve dans le bloc canonique h = 900,000 et la pointe de la meilleure chaîne est H = 900,005. La profondeur inclusive vaut 900,005 - 900,000 + 1 = 6 confirmations ; un affichage limité aux descendants indique 900,005 - 900,000 = 5. L’écart est terminologique si les deux observations portent sur le même hachage et la même ascendance.
  • Réorganisation et réinclusion. La transaction a d’abord 1 confirmation dans le bloc 900,000, puis ce bloc quitte la meilleure chaîne et la valeur revient à 0 si elle reste valide et sans conflit. Si elle est réincluse à 900,003 et que la pointe atteint 900,006, la profondeur inclusive vaut 900,006 - 900,003 + 1 = 4 confirmations. Si un conflit confirmé la remplace, Bitcoin Core peut signaler des confirmations négatives.
  • Les étiquettes PoS ne sont pas des nombres de blocs. Supposons qu’une transaction Ethereum se trouve dans le bloc d’exécution 20,000,000 et qu’un nœud signale latest = 20,000,020, safe = 20,000,012 et finalized = 19,999,980, tous sur la même ascendance. La profondeur latest numérique vaut 20,000,020 - 20,000,000 + 1 = 21 ; la transaction est safe, mais pas finalized. L’ascendance des hachages et les étiquettes de consensus sont indispensables ; les hauteurs ne suffisent pas.
  • Seuil de chaîne et crédit de plateforme. La policy exige 6 confirmations. Un dépôt dans le bloc 900,000 est à 5/6 quand la pointe vaut 900,004 et atteint 6/6 à 900,005. Si la plateforme applique ensuite une 15-minute compliance hold, admissibilité on-chain et heures de crédit, négociation ou retrait restent des états distincts ; cette retenue n’est pas une septième confirmation.

Risques

  • Examiner la mauvaise chaîne, le mauvais réseau ou actif.
  • Utiliser un hachage, destinataire, memo ou tag erroné.
  • Traiter une transaction signée mais non diffusée comme pending.
  • Traiter le mempool d’un nœud comme état global du réseau.
  • Manquer un rejet de policy, une éviction ou une non-propagation.
  • Ignorer un remplacement RBF, même nonce ou une dépense conflictuelle.
  • Mal interpréter ancêtres, descendants ou frais de package non confirmés.
  • Mélanger comptage inclusif et comptage des seuls descendants.
  • Faire confiance à un nœud obsolète, en synchronisation ou isolé.
  • Comparer des hauteurs sans vérifier hachages et ascendance.
  • Perdre des confirmations dans une courte réorganisation PoW.
  • Traiter une profondeur fixe comme sécurité absolue pour toute valeur et tout adversaire.
  • Confondre temps écoulé, slots, epochs et blocs produits.
  • Traiter un head block PoS comme safe.
  • Traiter un bloc safe comme finalized.
  • Manquer un retard de finalité pendant que des blocs sont encore produits.
  • Traiter une exécution incluse mais revertie comme succès applicatif.
  • Confondre logs de token ou UI d’explorateur avec l’état résultant.
  • Assimiler détection, crédit, négociation et autorisation de retrait.
  • Traiter la confirmation source comme achèvement du bridge, de l’émetteur ou du workflow de destination.

Idées reçues

  • Un hachage consultable ou une entrée du mempool local sont déjà confirmés.
  • Une convention et le seuil de six confirmations valent pour chaque chaîne, montant et service.
  • Des frais plus élevés accélèrent les blocs suivants ou la finalité PoS.
  • Un nombre fixe de blocs ou slots Ethereum équivaut à safe ou finalized.
  • Inclusion ou finalité garantit exécution correcte, bon destinataire, crédit de plateforme ou achèvement du bridge.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...