Le problème de la double dépense et les registres distribués

Pourquoi un paiement numérique nécessite un historique partagé

Un fichier numérique peut être copié sans supprimer l’original. C’est utile pour les documents et les photographies, mais cela pose un problème si le fichier est censé représenter une valeur rare. Imaginez qu’un compte ne puisse dépenser une unité qu’une seule fois. Si deux instructions incompatibles revendiquent cette même unité, le simple fait de confirmer que chacune semble authentique ne permet pas de déterminer laquelle doit être retenue. C’est le problème de la double dépense : la possibilité d’utiliser une même valeur disponible dans plusieurs transactions conflictuelles. Le problème concerne la cohérence des enregistrements, et pas nécessairement le vol ou la fraude délibérée ; deux transactions peuvent entrer en conflit par accident, par exemple lorsqu’un logiciel retransmet un paiement avec des paramètres différents.

Dans un système de paiement conventionnel, un opérateur de registre autorisé détermine généralement l’ordre dans lequel les instructions sont traitées. L’opérateur vérifie l’état du compte, rejette toute instruction qui dépasserait le solde disponible et tient le registre officiel. Un registre distribué, en revanche, conserve des enregistrements sur plusieurs ordinateurs, souvent exploités par différentes parties. Ces ordinateurs sont généralement appelés des nœuds. S’ils peuvent recevoir les messages dans des ordres différents, ils ont besoin d’un moyen de s’accorder sur les transactions valides et sur un ordre compatible entre ces transactions. Ce problème d’accord est le point de départ du consensus blockchain.

Exemple de transactions conflictuelles

Supposons qu’un registre indique qu’une sortie d’une valeur de dix unités n’a pas été dépensée. Le détenteur envoie la transaction A, qui attribue cette sortie au destinataire Un. Avant que tous les participants du réseau aient traité A, le détenteur diffuse également la transaction B, qui attribue cette même sortie au destinataire Deux. Chaque transaction peut être correctement formée sur le plan syntaxique, mais toutes deux ne peuvent pas prendre effet en tant que dépenses distinctes de la sortie initiale. Différents nœuds peuvent recevoir A et B dans des ordres opposés en raison de retards du réseau. Un réseau qui accepterait simplement le premier message reçu par chaque ordinateur risquerait de conserver des historiques incohérents.

Une conception fiable distingue donc deux décisions. La validation détermine si une transaction proposée respecte les règles du protocole, compte tenu d’un état particulier du registre. Le consensus détermine quel historique les participants considèrent comme accepté lorsque des propositions apparemment valides sont en concurrence. Dès que le registre accepte A, B entre en conflit avec l’état qui en résulte et ne devrait pas être également acceptée comme dépense de cette même sortie. Les détails diffèrent entre les systèmes qui suivent des sorties non dépensées distinctes et ceux qui gèrent des soldes de comptes et des compteurs de transactions. Le principe commun est qu’une transition d’état ne peut pas consommer deux fois la même autorisation de dépense.

L’ordre compte autant que l’authenticité

L’autorisation n’est qu’un élément de la décision. Une signature peut indiquer qu’une instruction a été autorisée selon le schéma cryptographique applicable, mais elle ne prouve pas à elle seule que les fonds sont toujours disponibles au moment du traitement de l’instruction. De même, un horodatage fourni par un expéditeur n’établit pas nécessairement l’ordre officiel du réseau. Les modules suivants abordent en profondeur les clés et les signatures. Pour l’instant, retenez cette distinction : une transaction doit être à la fois autorisée et compatible avec l’état accepté du registre. Le consensus fournit une base commune permettant d’évaluer cet état sur différents ordinateurs indépendants.

Ce qui caractérise un registre distribué

Un registre distribué est un ensemble partagé d’enregistrements répliqués, synchronisés ou coordonnés d’une autre manière entre plusieurs participants. Les nœuds ne stockent pas nécessairement des informations identiques à chaque instant. Certains peuvent être temporairement hors ligne, d’autres recevoir les messages lentement, et d’autres encore conserver des copies spécialisées ou des vues partielles. L’important est que les règles permettent aux nœuds participants de converger vers un état ou un historique cohérent, dans le cadre des hypothèses du système. Une blockchain est une forme de registre distribué dans laquelle les enregistrements sont regroupés en blocs ordonnés reliés cryptographiquement. Tous les registres distribués n’utilisent pas de blocs, et toutes les blockchains ne sont pas ouvertes à une participation sans restriction.

La conception d’un réseau détermine également qui peut proposer des mises à jour, qui peut les vérifier et quels messages contribuent au consensus. Les réseaux ouverts et sans permission admettent généralement des participants sans qu’un administrateur les inscrive individuellement. Les réseaux avec permission peuvent identifier les validateurs et appliquer des règles de gouvernance concernant l’adhésion. Les deux types doivent toutefois résoudre des problèmes de coordination, même si les menaces, les exigences de performance et les formes de responsabilité diffèrent. Le rapport interinstitutionnel NIST 8202, Blockchain Technology Overview, décrit les blockchains comme des registres distribués et détectables en cas de falsification, tandis que la norme ISO 23257:2022 propose une architecture de référence pour les blockchains et les autres systèmes de registres distribués.

L’accord n’est pas la vérité

Le consensus peut établir qu’un ensemble de nœuds a accepté un enregistrement particulier, mais il ne peut pas prouver que chaque affirmation concernant le monde réel contenue dans cet enregistrement est vraie. Si un document indique qu’un conteneur est arrivé hier, le registre peut conserver la date à laquelle cette déclaration a été enregistrée et la manière dont elle a été approuvée ; il ne peut pas inspecter le conteneur physique. De même, l’enregistrement de revendications de propriété ne résout pas à lui seul la question du droit juridique sous-jacent. Pour les employés du secteur juridique et du secteur public, cette distinction permet d’éviter de croire à tort qu’une base de données répliquée constitue automatiquement une preuve fiable d’événements survenus en dehors du réseau.

Ce que les nœuds peuvent vérifier indépendamment

Un nœud de validation complet applique l’ensemble des règles du réseau aux mises à jour proposées, plutôt que de faire confiance au proposant. Il peut souvent vérifier si un bloc respecte la structure requise, si les transactions suivent les règles de transition d’état et si l’historique proposé est correctement relié. Il ne peut pas vérifier de manière indépendante les faits provenant d’organisations externes, à moins que le protocole ne prévoie un autre moyen fiable de les établir. Un observateur peut constater que plusieurs nœuds sont d’accord sans voir qu’ils se sont tous appuyés sur le même rapport externe erroné. L’accord entre ordinateurs et la vérification indépendante de faits physiques sont deux contrôles différents.

Objectifs de conception et compromis inévitables

L’accord distribué doit tenir compte des retards de transmission, des partitions temporaires du réseau et des participants qui envoient des messages erronés ou contradictoires. Une partition du réseau se produit lorsque des groupes de nœuds ne peuvent pas communiquer normalement entre eux. Un participant défaillant ou malveillant peut proposer des données invalides, retenir des messages ou envoyer des affirmations différentes à différents pairs. Les mécanismes de consensus établissent des règles permettant de poursuivre les opérations malgré certaines de ces conditions, mais aucun mécanisme ne garantit la continuité des opérations dans tous les scénarios de panne. Une conception doit reposer sur des hypothèses concernant la connectivité, le comportement des participants, les ressources disponibles et les délais acceptables.

Trois objectifs pratiques aident à structurer les évaluations. La cohérence signifie que les participants n’acceptent pas indéfiniment des historiques officiels incompatibles. La disponibilité signifie que les utilisateurs légitimes peuvent encore soumettre et traiter des enregistrements lorsque le système fonctionne comme prévu. La vérifiabilité signifie que les opérateurs peuvent expliquer pourquoi une transition d’état a été acceptée et reproduire les contrôles pertinents. Ces objectifs dépendent de l’architecture et de la gouvernance, et pas du seul mot blockchain. Les affirmations selon lesquelles un registre serait simplement « décentralisé », « immuable » ou « instantané » sont incomplètes si elles ne précisent pas qui valide, quelles conditions de défaillance sont supposées et à quel moment une entrée est considérée comme définitive.

Scénario institutionnel détaillé

Prenons le cas d’un organisme public qui coordonne la délivrance de permis électroniques avec d’autres organismes. Deux bureaux soumettent des mises à jour contradictoires concernant le statut d’un permis. Un registre partagé peut les aider à s’accorder sur la séquence enregistrée des modifications autorisées et à conserver une piste d’audit des conflits rejetés. Il ne peut toutefois pas déterminer quel bureau disposait de l’autorité juridique de fond, à moins que cette autorité ne soit énoncée dans des politiques documentées et des règles d’autorisation applicables. Les concepteurs doivent déterminer si des institutions connues exploiteront les nœuds, ce qui se passera si un opérateur est indisponible et quelle institution peut corriger une déclaration erronée par une nouvelle entrée visible.

Dans ce scénario, une base de données standard administrée conformément à un accord clair pourrait également convenir. La valeur du consensus distribué augmente lorsque des opérateurs indépendants ont réellement besoin d’un état partagé sans dépendre d’un seul organisme chargé des mises à jour. Il est plus difficile de justifier les coûts opérationnels supplémentaires lorsqu’une seule autorité contrôle déjà toutes les décisions. ISO 22739:2024, Blockchain and distributed ledger technologies — Vocabulary, est une référence utile pour harmoniser la terminologie, mais ne remplace pas l’examen des hypothèses de confiance réelles de la conception.

Référence rapide

Ce que les apprenants doivent retenir

Le problème de la double dépense explique pourquoi copier une valeur représentée numériquement n’équivaut pas à la dépenser valablement. Les systèmes distribués traitent ce problème au moyen de la validation et d’un accord sur une séquence ou un état partagé. Le consensus détermine quels enregistrements concurrents le réseau accepte ; il ne prouve pas la véracité de tous les faits mentionnés dans ces enregistrements et n’élimine pas toutes les défaillances opérationnelles. Dans les leçons suivantes, nous examinerons les structures de données et les règles qui rendent cette coordination possible, plutôt que de revenir sur les catégories générales d’actifs présentées dans le Module 1.

Point essentiel pour l’examen : Expliquez pourquoi l’authenticité à elle seule ne peut pas empêcher une double dépense ; distinguez la validation du consensus et reconnaissez qu’une blockchain est un type de registre distribué, et non un synonyme de toutes les bases de données partagées.

Notes sur les sources

Références pertinentes : NIST IR 8202 (2018), Blockchain Technology Overview ; ISO 22739:2024, Blockchain and distributed ledger technologies — Vocabulary ; et ISO 23257:2022, Blockchain and distributed ledger technologies — Reference architecture.