--- title: "Finalité d'une blockchain : preuves, hypothèses et couches de règlement" description: "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." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Finalité d'une blockchain : preuves, hypothèses et couches de règlement > À 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 - [Confirmations de bloc](/fr/crypto/block-confirmation/) - [Réorganisations de chaîne](/fr/crypto/chain-reorg/) - [Mécanismes de consensus](/fr/crypto/consensus-mechanism/) - [Règles de choix de fork](/fr/crypto/fork-choice-rule/) - [Subjectivité faible](/fr/crypto/weak-subjectivity/) ## Sources - [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté le 2026-08-19) - [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consulté le 2026-08-19) - [Bitcoin Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project (consulté le 2026-08-19) - [Ethereum Proof-of-Stake Consensus](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (consulté le 2026-08-19) - [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consulté le 2026-08-19) - [Ethereum Proof-of-Stake Rewards and Penalties](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (consulté le 2026-08-19) - [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (consulté le 2026-08-19) - [OP Stack Derivation Specification](https://specs.optimism.io/protocol/derivation.html) - Optimism (consulté le 2026-08-19) Source: https://wiki.fcontext.com/fr/crypto/finality/index.mdx