Finalité, forks et réorganisations

Pourquoi cette leçon revient sur la finalité

Le module 1 a présenté la finalité comme une question pratique : à quel moment un utilisateur ou une institution peut-il considérer qu’un transfert enregistré est réglé ? Cette leçon développe les mécanismes de consensus sous-jacents plutôt que de répéter cette perspective introductive. Une blockchain peut contenir des blocs récemment proposés dont la position est encore susceptible de changer. Des participants distincts peuvent temporairement construire sur des historiques valides différents, mais le protocole a besoin d’une règle pour converger vers une seule branche acceptée. La finalité décrit la force et la nature de la garantie qu’un historique donné restera accepté. Le choix de branche, les seuils de vote et l’accumulation de travail expliquent pourquoi le niveau de confiance évolue avec le temps.

Il est essentiel de distinguer une transaction observée, une transaction incluse et une transaction finalisée. Une transaction observée a été annoncée à une partie du réseau. Une transaction incluse apparaît dans un bloc proposé ou accepté. Une transaction finalisée est protégée par la condition de règlement la plus forte énoncée par le système, si celui-ci en définit une. Ces termes ne signifient pas que la banque, le tribunal, le registre ou l’organisme correspondant a achevé toutes les procédures externes. Même après la finalisation par le protocole, des corrections administratives ou des recours juridiques peuvent encore exister en dehors de la structure de données de la blockchain.

Ce qui crée un fork

Un fork se produit lorsque des blocs ou des historiques différents s’étendent à partir d’un point commun, ou lorsque des communautés adoptent des règles de protocole différentes. Il ne faut pas confondre ces situations. Un fork temporaire de blocs peut survenir naturellement, car les messages mettent du temps à se propager : deux blocs valides sont proposés à la même position avant que tous les nœuds aient connaissance des deux. Un fork de protocole peut également résulter de changements logiciels qui modifient les blocs que les participants considèrent comme valides. Dans ce dernier cas, les différences entre les ensembles de règles peuvent persister au lieu d’être résolues par la sélection ordinaire d’une branche. Une description destinée à la formation doit préciser le sens de « fork » qui est visé.

Une réorganisation, souvent abrégée en « reorg », se produit lorsqu’un nœud change la tête de chaîne qu’il a sélectionnée au profit d’une autre branche valide, conformément aux règles de choix de branche du protocole. Les blocs qui se trouvaient auparavant sur la branche sélectionnée peuvent ne plus en faire partie. Les transactions contenues dans ces blocs peuvent alors connaître plusieurs issues : certaines sont incluses à nouveau dans la branche de remplacement, certaines restent admissibles à une inclusion ultérieure, et certaines deviennent invalides en raison de transactions incompatibles ou d’un changement d’état. Une réorganisation ne signifie donc pas que toutes les transactions concernées disparaissent définitivement, et elle ne prouve pas nécessairement qu’une personne a attaqué le réseau.

Chronologie illustrative

Au temps un, les nœuds s’accordent sur le bloc P. Deux propositions, A1 et B1, sont ensuite construites sur P. Certains nœuds sélectionnent d’abord la branche passant par A1, parce qu’ils l’ont reçue en premier ou parce qu’elle répond temporairement aux critères locaux de choix de branche. Au temps deux, la branche passant par B1 acquiert un poids suffisant, défini par le protocole, pour devenir préférée. Les nœuds qui avaient sélectionné A1 se réorganisent vers la branche B. Ils annulent les changements d’état associés aux blocs retirés et appliquent les blocs de remplacement dans l’ordre approprié. Le traitement interne précis dépend du protocole, mais le résultat conceptuel est un nouvel historique canonique.

Confiance probabiliste dans la preuve de travail

Dans un réseau typique de preuve de travail, la quantité cumulée de travail valide qui soutient une branche augmente à mesure que de nouveaux blocs sont construits par-dessus. Une transaction gagne des confirmations lorsque des blocs sont ajoutés après celui qui la contient, bien que les conventions de comptage diffèrent ; certaines interfaces comptent son bloc initial comme la première confirmation. À mesure que le travail s’accumule, remplacer la branche contenant cette transaction devient généralement plus difficile, compte tenu des hypothèses relatives à la part du taux de hachage détenue par l’attaquant et au comportement des mineurs concurrents. Il s’agit d’une confiance probabiliste, et non d’une promesse mathématique explicite selon laquelle une annulation est impossible après un nombre exact de confirmations.

Le nombre de confirmations ne doit pas être dissocié du modèle de sécurité du réseau. Il importe de savoir si le nœud a entièrement validé les blocs concernés, si le réseau connaît des réorganisations inhabituelles et si un adversaire peut mobiliser des ressources informatiques considérables. Différents destinataires peuvent choisir des seuils opérationnels différents pour des actions présentant des risques différents. Un nombre normalisé peut être pratique pour des procédures internes, mais ce n’est pas une loi de la nature. L’article original sur Bitcoin présente ce modèle de chaîne fondé sur le travail ; le NIST IR 8202 explique également le consensus et les forks sans laisser entendre que les liens de hachage, à eux seuls, empêchent toute réorganisation.

Finalité explicite dans certains systèmes de preuve d’enjeu

Certains protocoles PoS ajoutent un processus dans lequel les validateurs attestent ou votent en faveur de points de contrôle et, après avoir atteint un seuil, marquent comme finalisé un historique antérieur. Un point de contrôle est une position spécialement identifiée dans la chaîne, utilisée pour les décisions de consensus. Dans la conception Casper FFG d’Ethereum, des points de contrôle justifiés reliés entre eux peuvent mener à la finalisation, sur la base d’un vote à la majorité qualifiée du poids de la mise. Un bloc finalisé est censé être extrêmement coûteux à annuler, car une finalisation contradictoire nécessiterait de graves violations des hypothèses et entraînerait des pénalités pour les validateurs concernés. D’autres réseaux PoS appliquent des seuils, des votes ou une terminologie différents ; certains n’offrent pas du tout de finalité explicite comparable.

La finalité explicite ne signifie pas qu’un appareil ou une institution peut cesser la surveillance après un message favorable. Un observateur a besoin de données exactes provenant d’un nœud, de comprendre la règle de finalité et de bénéficier d’une protection raisonnable contre les sources d’information malhonnêtes ou compromises. Lors d’un incident réseau, la finalisation peut s’interrompre alors que des blocs continuent d’être proposés, ou des clients logiciels peuvent temporairement être en désaccord sur l’état du réseau. Les opérateurs doivent distinguer « finalité retardée » de « historique précédemment finalisé annulé ». Le premier cas peut relever d’un problème de disponibilité ou de vivacité ; le second soulève une question sensiblement différente concernant les hypothèses de sûreté du protocole ou sa mise en œuvre.

Le choix de branche peut évoluer avant la finalité

Dans les conceptions qui combinent choix de branche et finalité des points de contrôle, la tête de la chaîne peut changer tandis que le dernier point de contrôle finalisé reste le même. Cette distinction est facile à manquer si un tableau de bord n’affiche que la hauteur du bloc le plus récent. La pointe préférée représente une vue opérationnelle de la progression récente ; le point de contrôle finalisé constitue une limite de consensus plus forte. Une transaction proche de la pointe peut être incluse sans être encore protégée par la finalisation. Pour une institution qui attend avant de mettre à jour un autre système, consigner les deux états peut éviter qu’une étape préliminaire du flux de travail soit prise pour un règlement achevé.

Les changements de règles du protocole constituent un phénomène distinct

Un soft fork resserre généralement les règles de validité d’une manière visant à préserver certaines propriétés de compatibilité pour les nœuds qui appliquent d’anciennes règles. Un hard fork introduit des changements qui ne sont pas rétrocompatibles au regard des règles de validation concernées. Ces descriptions simplifiées sont courantes, mais elles ne doivent pas servir à déduire l’issue de gouvernance de chaque mise à niveau. Les participants au réseau peuvent choisir des logiciels différents, les mineurs ou les validateurs peuvent exprimer leurs préférences, et les organisations peuvent communiquer avec leurs communautés. La compatibilité du protocole, la coordination de la communauté, les identifiants juridiques et la dénomination sur les marchés sont des questions différentes. Une mise à niveau controversée peut produire des historiques durables ; une mise à niveau courante peut ne pas en produire.

Les gestionnaires doivent éviter de considérer chaque élément étiqueté « fork » comme la preuve d’un incident de sécurité. Un changement technique peut être planifié, tandis qu’une branche concurrente de courte durée peut être attendue dans un réseau décentralisé. À l’inverse, une réorganisation profonde et inattendue peut justifier une enquête urgente. La première question à poser est de savoir ce qui a changé : l’ordre des blocs sous les mêmes règles, ou l’ensemble des règles que les participants acceptent. Ces différents changements appellent des réponses, des dossiers et des communications aux utilisateurs différents.

Surveillance et décisions institutionnelles

Un plan de surveillance opérationnelle peut suivre la tête de chaîne sélectionnée, la dernière hauteur ou le dernier slot entièrement validé, le point de contrôle finalisé le plus récent, le cas échéant, la profondeur des réorganisations observées, la participation des validateurs ou le travail du réseau, ainsi que les divergences entre sources d’information indépendantes. Le plan de surveillance doit définir précisément le sens de chaque indicateur. Il doit également distinguer les défaillances des logiciels clients des résultats du consensus. Une alerte indiquant « bloc remplacé » peut être courante dans certaines circonstances, alors que « point de contrôle finalisé annulé » signalerait un écart bien plus grave par rapport aux attentes dans les systèmes qui revendiquent cette propriété.

Par exemple, un organisme pourrait enregistrer les paiements entrants avant d’autoriser un service qui en dépend. Ses contrôles pourraient exiger qu’une transaction incluse soit observée de manière indépendante, que le réseau atteigne sa condition d’acceptation documentée et que le système conserve des preuves de l’état au moment de la décision. Si la transaction disparaît ensuite de l’historique sélectionné, le flux de travail doit prévoir un processus d’exception. La réponse appropriée dépend des pouvoirs juridiques de l’organisme, des accords contractuels et de sa tolérance au risque opérationnel ; le consensus fournit des éléments techniques, mais ne définit pas l’ensemble de la politique décisionnelle de l’institution.

Rectification des idées fausses courantes

Une chaîne liée par des hachages n’est pas automatiquement à l’abri d’une réorganisation. Une règle des « six confirmations » ne s’applique pas universellement à tous les réseaux ou à tous les cas d’usage. La finalité explicite n’équivaut pas à un résultat instantané et juridiquement irrévocable. Un fork ne crée pas toujours un actif ou un protocole distinct et permanent. Un explorateur de blocs est un service d’information, et non une garantie indépendante du consensus. Ces mises en garde sont importantes, car des termes qui semblent définitifs résument souvent des affirmations conditionnelles. Une explication utile nomme la chaîne, la règle de choix de branche, la règle de finalité, la méthode d’observation et toutes les hypothèses importantes.

Référence rapide

Ce que les apprenants doivent retenir

Le consensus doit résoudre les désaccords temporaires concernant des historiques de blocs valides concurrents. Une réorganisation décrit l’adoption, par un nœud, d’une autre branche acceptée et l’application de l’état correspondant. La preuve de travail offre généralement une confiance probabiliste croissante grâce à l’accumulation de travail ; certaines conceptions de preuve d’enjeu offrent une finalité économique explicite par le vote. Les forks causés par la production simultanée de blocs diffèrent des mises à niveau des règles du protocole. La question opérationnelle n’est pas simplement de savoir si une transaction apparaît à l’écran, mais quelle condition technique a été atteinte et ce que l’organisation peut faire de manière responsable avec ces éléments.

À retenir pour l’examen : Distinguez les forks causés par des blocs concurrents des forks liés aux règles du protocole ; expliquez les réorganisations et leurs effets sur l’état des transactions ; et comparez la confiance probabiliste à la finalité des points de contrôle définie par le protocole, sans présenter l’une ou l’autre comme une garantie juridique inconditionnelle.

Notes sur les sources

Références pertinentes : NIST IR 8202 (2018), Blockchain Technology Overview, sections consacrées au consensus et aux forks ; Satoshi Nakamoto (2008), Bitcoin: A Peer-to-Peer Electronic Cash System ; et la documentation d’Ethereum sur la preuve d’enjeu, le choix de branche et la finalité.