Aller au contenu
Financial Context Wiki

Finalité d'une blockchain : preuves, hypothèses et couches de règlement

La finalité est l'assurance propre à un protocole qu'une décision ne sera pas remplacée sans violer ses hypothèses de sécurité ou déclencher une reprise exceptionnelle. Il faut distinguer validité, fork choice, preuve de finalité, seuils de panne, dépendances de couche et règlement applicatif.

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

La finalité est l’assurance propre à un protocole qu’une décision acceptée, telle qu’un bloc, un checkpoint ou un engagement d’état, ne sera pas remplacée sans violer les hypothèses de sécurité déclarées ou recourir à une reprise exceptionnelle. Ce n’est ni une propriété physique des octets d’une transaction ni simplement « la transaction a réussi ». Toute affirmation doit préciser l’objet, le réseau, la version du protocole, les preuves, le modèle de panne et de temps, le point de départ fiable et l’observateur.

Validité, canonicité et finalité sont différentes. Un bloc valide respecte les règles de transition d’état et d’autorisation. Le fork choice sélectionne la tête canonique actuelle parmi les candidats valides. La finalisation applique un prédicat supplémentaire, tel qu’un certificat de commit ou un checkpoint finalisé, à un ancêtre de cette tête. Une transaction peut réussir dans un bloc valide qui perd ensuite le fork choice ; une tête peut être canonique sans être finalisée ; et un événement finalisé sur la chaîne source peut encore échouer dans un pont, une plateforme ou une application.

Les systèmes à preuve de travail offrent généralement un règlement probabiliste plutôt qu’un bit explicite de finalité : plus le travail valide cumulé au-dessus d’un bloc augmente, plus son remplacement devient improbable et coûteux sous les hypothèses de puissance de hachage et de réseau. Un protocole BFT peut offrir une finalité déterministe conditionnelle : après un certificat de commit valide, deux décisions contradictoires ne peuvent être toutes deux commises si le poids fautif reste sous la limite démontrée. En PoS, elle peut aussi être responsable ou économique, car des votes contradictoires identifient le poids susceptible d’être slashed. Ces termes décrivent des preuves différentes.

Aucun protocole ne rend l’histoire absolument immuable. Compromission massive de clés, dépassement du seuil de panne, bug client, transition invalide acceptée par les implémentations, intervention de gouvernance ou reprise sociale peuvent franchir la limite du modèle. « Finalisé » doit donc signifier que la voie ordinaire de réorganisation ne peut remplacer cette décision sous ces hypothèses ; la reprise exceptionnelle et son autorité sont documentées séparément.

Comment analyser la finalité

  1. Nommer l’objet et la portée. Identifier transaction, bloc, checkpoint, racine d’état, message inter-chaînes ou retrait ; noter chaîne, réseau, couche, version, hauteur ou slot, hash et checkpoint de confiance.
  2. Vérifier la validité avant le statut. Réexécuter ou valider autrement la transition d’état et l’ascendance concernées. Selon les règles réelles, quorum, score de travail ou badge d’interface ne peuvent finaliser un objet invalide.
  3. Séparer sélection de tête et finalisation. Reconstruire le fork choice et le chemin canonique actuel, puis localiser l’ancêtre finalisé ou commis. Noter si l’objet est seulement observé, confirmé, justifié, sûr, commis ou finalisé.
  4. Reproduire les preuves. En PoW, vérifier en-têtes, cible et chainwork cumulé au-dessus du bloc. Pour un vote, vérifier éligibilité, instantané des poids, domaine du message, source et cible, hauteur, round, inégalité de quorum, signatures, verrous et ascendance du certificat.
  5. Énoncer les hypothèses de sûreté et de vivacité. Préciser poids byzantin ou hors ligne, synchronisme, délai, équivoque, compromission de clés, corrélation des clients, changement de membres, disponibilité du slashing et comportement en cas d’arrêt. Un arrêt peut préserver la sûreté tout en perdant la vivacité.
  6. Cartographier chaque couche de règlement. Suivre réception du séquenceur, exécution L2, publication des données, inclusion L1, finalité L1, fin de preuve ou litige, exécution du pont, crédit de la plateforme et action applicative. Des libellés semblables sur deux couches ne désignent pas nécessairement le même prédicat.
  7. Définir et surveiller une politique applicative. Fixer les preuves acceptables selon valeur et conséquence, interroger des nœuds indépendants, traiter réorganisations et alertes de finalité contradictoire, suspendre les actions irréversibles si les hypothèses échouent et consigner l’autorité de reprise.

Le nombre de confirmations est une observation, pas une règle universelle de finalité. Dans Bitcoin Core, confirmations dépend de la position du bloc dans la chaîne active, tandis que chainwork indique le travail attendu cumulé. Dans Ethereum, le choix de tête LMD-GHOST et la justification et finalisation Casper FFG sont des transitions distinctes. Dans CometBFT, un commit exige plus des deux tiers du pouvoir en precommit pour le même bloc, à la même hauteur et au même round. Chaque statut s’interprète dans son protocole.

Exemples chiffrés

1. Règlement probabiliste par preuve de travail

Le livre blanc Bitcoin modélise un attaquant de part de hachage q=0.10 qui tente de rattraper une chaîne honnête après une avance z=6. Sous ses hypothèses d’essais de hachage indépendants et de loi de Poisson, la probabilité calculée est :

P=0.0002428 = 0.02428%

Le résultat est faible, mais non nul, et ne constitue pas une garantie universelle de « six confirmations ». Une politique réelle considère valeur, chainwork observé, concentration du hachage, risque d’éclipse ou de partition, incitations de frais et crédibilité d’une part attaquante constante.

2. Justification et finalisation Ethereum

Prenons un chemin simplifié de checkpoints consécutifs avec solde effectif actif total 100. Des votes 67/100 reliant le checkpoint justifié C_0 à la cible C_1 atteignent au moins deux tiers et justifient C_1. Un lien ultérieur admissible de 67/100 de C_1 vers son enfant direct C_2 peut finaliser C_1 selon la règle Casper FFG applicable.

La tête peut dépasser C_2 tandis que sa partie récente reste non finalisée. Si le solde 34 est hors ligne, il ne reste que 66 et la finalisation immédiate s’arrête, même si fork choice et production continuent. Après plus de quatre epochs sans finalité, l’inactivity leak d’Ethereum pénalise la non-participation afin qu’une supermajorité active puisse finalement la rétablir.

3. Sûreté et vivacité de CometBFT

Soit un pouvoir total 100 et une exigence de >2/3 precommits pour le même bloc, à une hauteur et un round. Un pouvoir entier 67 suffit au commit. Deux ensembles de commit de 67 se recoupent sur au moins 67 + 67 - 100 = 34 de pouvoir. Si le poids byzantin est inférieur à un tiers et que les validateurs honnêtes suivent les verrous, deux commits contradictoires ne peuvent se former.

Si le poids 34 est indisponible, seul 66 peut voter et aucun commit ne se forme. Le protocole peut préserver la sûreté pendant l’arrêt de la finalité. « Aucun bloc finalisé contradictoire » et « les nouveaux blocs continuent d’être finalisés » sont deux garanties différentes.

4. Statuts OP Stack et délais de retrait

Un séquenceur OP Stack peut d’abord exposer un bloc L2 comme unsafe. Lorsqu’il est entièrement dérivable des données de la chaîne L1 canonique actuelle, le nœud rollup peut le marquer safe. Quand les entrées L1 correspondantes reçoivent un signal de finalité L1, le bloc L2 dérivé peut devenir finalized.

Ce statut concerne la dérivation depuis des entrées finalisées. Une sortie d’optimistic rollup ou un retrait L2 vers L1 suit un autre processus de preuve et de litige et peut n’être dit « finalisé » qu’après satisfaction de la condition de contestation. Une application qui confond confirmation du séquenceur, inclusion des données L1, finalité du consensus L1 et exécution du retrait peut libérer la valeur trop tôt.

Risques et erreurs d’examen

Définition et preuves

  • Qualifier de « final » toute exécution, reçu, confirmation, checkpoint ou badge réussi.
  • Omettre chaîne, réseau, version, hash de l’objet, hauteur ou slot, couche et observateur.
  • Prendre la tête de fork choice pour un ancêtre finalisé ou supposer que la finalisation sélectionne la tête la plus récente.
  • Compter blocs ou minutes sans valider ascendance, cibles, travail, votes ou certificats.
  • Comparer « deux confirmations » ou « dix minutes de finalité » entre protocoles aux preuves différentes.
  • Vérifier les signatures sans éligibilité, poids, domaine, source, cible, hauteur et round.
  • Confondre coût économique, preuve slashable et exécution réelle de la pénalité.
  • Présenter un risque probabiliste comme nul ou une sûreté déterministe conditionnelle comme irréversibilité absolue.

Défaillances du protocole et de l’exploitation

  • Dépasser le seuil byzantin, perdre le poids en ligne nécessaire à la vivacité ou masquer une partition.
  • Laisser les implémentations diverger sur validité, fork choice, transitions, arrondi du quorum ou ascendance du certificat.
  • Accepter votes, commits, checkpoints ou données de weak subjectivity périmés, rejoués ou d’un autre réseau.
  • Concentrer clés, stake, hachage, clients, relais, clouds ou vues RPC derrière des identités nominalement distinctes.
  • Supposer qu’inactivity leak, timeout ou changement de vue rétablit immédiatement et gratuitement la progression.
  • Ne pas alerter sur retard de finalité, certificats contradictoires, réorganisation profonde, équivoque ou racines divergentes.
  • Employer gouvernance d’urgence ou reprise sociale sans documenter autorité, coordination, version client et garanties touchées.

Inadéquation des couches et de l’application

  • Assimiler l’inclusion du séquenceur à la sûreté L2, publication L1, finalité L1, acceptation de preuve et retrait achevé.
  • Libérer les actifs pontés avant que l’événement source et la vérification propre au pont satisfassent la politique.
  • Créditer un dépôt ou exécuter un trade irréversible depuis le statut d’un seul RPC sans rapprochement indépendant.
  • Supposer que la finalité garantit vérité de l’oracle, correction du contrat, disponibilité des données, solvabilité ou règlement juridique.
  • Appliquer le même seuil fixe à toute valeur, contrepartie, incitation d’attaque et coût de reprise.

Idées reçues

  • Une transaction réussie est finale. Le succès ne décrit qu’une transition dans une histoire candidate ; canonicité et finalité exigent d’autres preuves.
  • Davantage de confirmations réduit exactement à zéro le risque PoW. La probabilité du modèle peut chuter fortement, mais reste conditionnelle et ne devient pas une impossibilité logique.
  • Deux tiers signifient toujours finalité. Inégalité, type de message, poids, hauteur, round, relation source-cible et règle de verrouillage dépendent du protocole.
  • La finalité garantit la progression du réseau. La sûreté peut subsister alors qu’une participation ou connectivité insuffisante empêche de nouvelles finalisations.
  • La finalité L1 achève toute action L2 ou de pont. Dérivation, preuve de validité ou de fraude, délai de contestation et exécution cible ajoutent des horloges et pannes propres.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...