Brevet FR3090156A1 — publié le 20200619

Description Titre de l'invention : REGISTRE DISTRIBUÉ [0001] La spécification concerne de façon générale le stockage distribué de données et spé- cifiquement un système et un procédé pour tenir à jour un registre distribué. [0002] Divers systèmes, tels que ceux qui sont configurés pour conserver des données de voyage (p. ex. le statut d'un vol, la réservation, les données d'enregistrement, les données d'identification du passager, et d'autres) sont implémentés par une pluralité d'entités distinctes, chacune stockant des sous-ensembles distincts du volume total de données exploitées dans le système. Typiquement, aucune entité seule n'exerce de contrôle sur le volume total de données. Les sous-ensembles susmentionnés peuvent cependant se chevaucher les uns avec les autres à divers degrés et une synchronisation entre les entités peut donc être nécessaire. Une telle synchronisation peut-être réalisée via des requêtes et. des réponses bidirectionnelles entre chaque paire d'entités ou via des exportations en masse et des importations subséquentes pour transférer les données entre entités. Les mécanismes susmentionnés peuvent être chronophages, intensifs sur le plan informatique, ou les deux. [0003] Un aspect de la spécification fournit un dispositif informatique pour implémenter un noeud client d'un registre distribué, le dispositif informatique comprenant : une mémoire stockant (i) un registre distribué définissant une pluralité d'enregistrements, chacun contenant un ensemble de valeurs ; (ii) une pondération de vote local correspondant au noeud client et (iii) des pondérations de votes distants pour une pluralité de noeuds clients distants ; un processeur connecté à la mémoire, le processeur étant configuré pour : obtenir une mise à jour proposée pour un enregistrement du registre distribué ; générer un vote local pour appliquer ou rejeter la mise à jour proposée et transmettre le vote local aux noeuds clients distants ; recevoir des votes distants pour appliquer ou rejeter la mise à jour proposée des noeuds clients distants ; déterminer s'il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) des votes distants et des pondérations correspondantes des votes distants ; et selon la détermination, appliquer la mise à jour proposée pour le registre distribué ou rejeter la mise à jour proposée. [0004] Selon un autre aspect du dispositif informatique, la mise à jour proposée est associée à un type actuel de transaction d'une pluralité de types de transaction ; le processeur étant par ailleurs configure pour : stocker une pluralité de pondérations de votes locaux en mémoire, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à un type respectif parmi les types de transactions ; mettre en oeuvre la détermination sur la base d'une des pondérations des votes locaux et des autres pondérations de votes locaux correspondant au type actuel de transaction associé 2 à la mise à jour proposée. [0005] Selon un autre aspect du dispositif informatique, la mise à jour proposée est associée à une valeur actuelle de l'ensemble des valeurs ; le processeur étant par ailleurs configuré pour : stocker une pluralité d'autres pondérations de votes locaux en mémoire, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à une valeur respective de l'ensemble des valeurs ; et mettre en oeuvre la détermination sur la base d'une des pondérations de votes locaux et des autres pondérations de votes locaux correspondant à la valeur actuelle associée à la mise à jour proposée. [0006] Selon un autre aspect du dispositif informatique, le processeur est configuré pour obtenir la mise à jour proposée en générant la mise à jour proposée. [0007] Selon un autre aspect du dispositif informatique, le processeur est configuré en réponse à la génération de la mise à jour proposée, pour transmettre la mise à jour proposée aux noeuds clients distants. [0008] Selon un autre aspect du dispositif informatique, le processeur est configuré pour obtenir la mise à jour proposée en recevant la mise à jour proposée de l'un des noeuds clients distants. [0009] Selon un autre aspect du dispositif informatique, le processeur est configuré pour générer le vote local en récupérant des données privées distinctes du registre distribué et en évaluant la mise à jour proposée sur la base des données privées. [0010] Selon un autre aspect du dispositif informatique, le processeur est configuré pour générer le vote local par ailleurs en : identifiant un sous-ensemble des valeurs affectées par la mise à jour proposée ; et sur la base du sous-ensemble en déterminant s'il faut générer le vote local ou un vote blanc local. [0011] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configuré pour : stocker une liste d'attente de mises à jour proposées en mémoire ; en réponse à l'obtention de la mise à jour proposée, placer la mise à jour proposée dans la file d'attente pour synchronisation avec les noeuds clients distants ; et pour sortir la mise à jour proposée de la file d'attente et déterminer s'il faut permettre la mise à jour proposée en réponse à la réception des votes distants de tous les clients distants. [0012] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configuré pour : lorsqu'un vote distant manquant d'un des clients distants n'est pas reçu dans un délai de temporisation, conserver la mise à jour proposée, le vote local et les votes distants reçus dans la file d'attente pour une synchronisation subséquente avec ledit un des clients distants. [0013] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configuré pour : avant de placer la mise à jour proposée dans la file d'attente, déterminer quel vote distant manquant correspond à une pondération de vote distant 3 suffisante pour altérer la détermination qu'il faut, ou non, permettre la mise à jour proposée. [0014] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configure pour : en réponse au placement de la mise à jour proposée dans la file d'attente, mettre en oeuvre une détermination initiale pour déterminer s'il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération de vote local, et (ii) des votes distants reçus et des pondérations correspondantes de votes distants ; selon la détermination initiale, appliquer la mise à jour proposée au registre distribué ou rejeter la mise à jour proposée et conserver la mise à jour proposée dans la file d'attente ; et en réponse à la réception du vote distant manquant, mettre en oeuvre la détermination pour déterminer s'il faut permettre la mise à jour proposée et, lorsque la détermination est en conflit avec la détermination initiale, inverser un résultat de la détermination initiale. [0015] Selon un autre aspect, un procédé pour tenir à jour un registre distribué au niveau d'un noeud client est fourni, le procédé incluant : le stockage d'un registre distribué définissant une pluralité d'enregistrements, chacun contenant un ensemble de valeurs ; le stockage (i) d'une pondération de vote local correspondant au noeud client et (ii) des pondérations de votes distants respectifs pour une pluralité de noeuds clients distants ; l'obtention d'une mise à jour proposée pour un enregistrement du registre distribué; la génération d'un vote local pour appliquer ou rejeter la mise à jour proposée et la transmission du vote local aux noeuds clients distants la réception de votes distants pour appliquer ou rejeter la mise à jour proposée des noeuds clients distants ; la détermination s'il faut permettre, ou non, la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) des votes distants et des pondérations correspondantes de votes distants et, selon la détermination, l'application de la mise à jour proposée pour le registre distribué ou le rejet de la mise à jour proposée. [0016] Selon un autre aspect du procédé, la mise à jour proposée est associée à un type actuel de transaction d'une pluralité de types de transactions ; le procédé comprenant par ailleurs : le stockage d'une pluralité d'autres pondérations de votes locaux, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à des types respectifs parmi les types de transactions et la mise en oeuvre de la détermination sur la base d'une des pondérations de votes locaux et des autres pondérations de votes locaux correspondant au type actuel de transaction associé à la mise à jour proposée. [0017] Selon un autre aspect du procédé, la mise à jour proposée est associée à une valeur actuelle de l'ensemble des valeurs le procédé comprenant par ailleurs : le stockage d'une pluralité d'autres pondérations de votes locaux, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à des valeurs res- pectives de l'ensemble des valeurs ; et la mise en oeuvre de la détermination sur la base d'une des pondérations de votes locaux et des autres pondérations de votes locaux correspondant à la valeur actuelle associée à la mise à jour proposée. [0018] Selon un autre aspect du procédé, l'obtention de la mise à jour proposée comprend la génération de la mise à jour proposée au noeud client. [0019] Selon un autre aspect du procédé, le procédé comprend par ailleurs, en réponse à la génération de la mise à jour proposée, la transmission de la mise à jour proposée aux noeuds clients distants. [0020] Selon un autre aspect du procédé, l'obtention de la mise à jour proposée comprend la réception de la mise à jour proposée de l'un des noeuds clients distants. [0021] Selon un autre aspect du procédé, la génération du vote local comprend la récu- pération de données privées distinctes du registre distribué et l'évaluation de la mise à jour proposée sur la base des données privées. [0022] Selon un autre aspect du procédé, la génération du vote local comprend par ailleurs : l'identification d'un sous-ensemble des valeurs affectées par la mise à jour proposée ; et sur la base du sous-ensemble, la détermination s'il faut générer le vote local ou un vote blanc local. [0023] Selon un autre aspect du procédé, le procédé comprend par ailleurs : le stockage d'une liste d'attente de mises à jour proposées ; en réponse à l'obtention de la mise à jour proposée, le placement de la mise à jour proposée dans la file d'attente pour synchronisation avec les noeuds clients distants ; et le retrait de la mise à jour proposée de la file d'attente et la détermination de permettre la mise à jour proposée en réponse à la réception des votes distants de tous les clients distants. [0024] Selon un autre aspect du procédé, le procédé comprend par ailleurs : lorsqu'un vote distant manquant d'un des clients distants n'est pas reçu dans un délai de temporisation, la conservation de la mise à jour proposée, du vote local et des votes distants reçus dans la file d'attente pour une synchronisation subséquente avec ledit un des clients distants. [0025] Selon un autre aspect du procédé, le procédé comprend par ailleurs : avant de placer la mise à jour proposée dans la file d'attente, la détermination que le vote distant manquant correspond à une pondération de vote distant suffisante pour altérer la détermination de permettre ou non la mise à jour proposée. [0026] Selon un autre aspect du procédé, le procédé comprend par ailleurs : en réponse au placement de la mise à jour proposée dans la file d'attente, la mise en oeuvre d'une détermination initiale pour déterminer s'il faut permettre la mise à jour proposée sur la base (i) du vote local et la pondération de vote local, et (ii) des votes distants reçus et des pondérations correspondantes des votes distants ; selon la détermination initiale, l'application de la mise à jour proposée au registre distribué ou le rejet de la mise à jour proposée et la conservation de la mise à jour proposée dans la file d'attente ; et en réponse à la réception du vote distant manquant, la mise en oeuvre de la détermination pour déterminer s'il faut permettre la mise à jour proposée et, lorsque la détermination est en conflit avec la détermination initiale, l'inversion d'un résultat de la détermination initiale. [0027] Selon un autre aspect, il est fourni un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en oeuvre les étapes du procédé selon l'un quelconque des aspects définis ci-dessus lorsque ledit programme fonctionne sur un ordinateur. [0028] Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles : [0029] [fig.1] décrit un système pour tenir à jour un registre distribué; [0030] [fig.2] décrit un procédé pour tenir à jour un registre distribué; [0031] [fig.3À] décrit une mise en oeuvre du procédé de la Fig. 2; [0032] [fig.313] décrit une mise en oeuvre du procédé de la Fig. 2; [0033] [fig.3C] décrit une mise en oeuvre du procédé de la Fig. 2; [0034] [fig.4À] décrit une autre une mise en oeuvre du procédé de la Fig. 2; [0035] [fig.413] décrit une autre mise en oeuvre du procédé de la Fig. 2; [0036] [fig.4C] décrit une autre mise en oeuvre du procédé de la Fig. 2; [0037] [fig.5À] décrit une autre mise en oeuvre du procédé de la Fig. 2; [0038] [fig.513] décrit une autre mise en oeuvre du procédé de la Fig. 2; [0039] [fig.5C] décrit une autre mise en oeuvre du procédé de la Fig. 2; et [0040] [fig.6] décrit un procédé de récupération suite à une défaillance au niveau d'un des noeuds dans le système de la Fig. 1. [0041] Fig. 1 décrit un système 100 pour tenir à jour un registre distribué (également appelé technologie de registre distribué, ou DLT). Le système 100 inclut un réseau 104 implémenté sous forme d'une quelconque combinaison appropriée de réseaux locaux et de zone étendue (p. ex. incluant l'Intemet), reliant une pluralité de serveurs 108 (également appelés noeuds 108 dans les présentes) lesquels sont illustrés par trois exemples 108-1, 108-2 et 108-3. Les serveurs108 n'ont pas besoin d'être implémentés comme des serveurs individuels 108, mais plutôt sont représentés comme des serveurs individuels 108 dans le but de clarifier l'illustration. Par exemple, chaque serveur 108 peut être implémenté sous forme de sous-système incluant un ou plusieurs autres réseaux, une pluralité de serveurs et d'autres dispositifs informatiques (non illustrés). [0042] Chaque noeud 108 est typiquement, mais pas nécessairement, exploité par une entité distincte. Dans les exemples discutés ci-dessous, le système 100 est configuré pour tenir à jour un registre distribué contenant des données de voyage (p. ex. des réservations de vol, des enregistrements de passagers, un suivi des plaintes des clients, 6 entre autres). Cependant, il sera apparent pour les hommes de métier que les principes d'exploitation implémentés par le système 100 puissent être appliqués à une large variété d'autres types de données gérés par toute combinaison pertinente d'entités. Dans le présent exemple, le noeud 108-1 est exploité par une compagnie aérienne alors que le noeud 108-2 est exploité par une entité génératrice de profils de clients et que le noeud 108-3 est exploité par une entité de gestion des plaintes. [0043] Ainsi que noté ci-dessus, les noeuds 108 sont configurés pour tenir à jour un registre distribué contenant des données de voyage. Par conséquent, chaque noeud 108 conserve une copie locale 112-1, 112-2, 112-3 du registre distribué (collectivement appelé simplement le registre 112). Chaque noeud 108 peut initier des mises à jour du registre 112 et les noeuds 108 sont configurés pour implémenter un mécanisme de consensus basé sur le vote pour déterminer s'il faut appliquer ou rejeter (c.-à-d. supprimer) chaque mise à jour proposée au registre 112. Cependant comme cela fera l'objet d'une discussion ci-dessous, par contraste aux mécanismes conventionnels de consensus basés sur le vote, une pondération de vote distincte peut être affectée à chaque noeud 108, donnant plus ou moins d'influence au noeud 108 que les autres noeuds 108 concernant l'acceptation des mises à jour du registre 112. [0044] Chaque noeud 108 peut aussi stocker des données qui sont conservées en dehors du registre 112 et résident donc seulement sur un noeud 108. Par exemple, le noeud 108-1 (p. ex. exploité par une compagnie aérienne dans le présent exemple) peut contenir des listes des membres d'équipage en opération pour chacun d'une pluralité de vols alors qu'aucun des noeuds 108-2 et 108-3 ne contient de telles informations concernant équipage. Divers autres types de données peuvent être conservés à l'intérieur ou à l'extérieur du registre 112, incluant par exemple, le statut d'embarquement des passagers enregistrés pour un vol donné. Les données conservées en dehors du registre 112 (c.-à-d. les données qui sont accédées uniquement par un seul noeud 108) sont aussi désignées comme données privées dans les présentes. Dans certains modes de réalisation, les données privées peuvent en fait être conservées à l'intérieur du registre 112 avec un accès restreint à un sous-ensemble des noeuds 108 via l'encryption de portions du registre 112. Dans le présent exemple, les données privées sont illustrées comme étant conservées séparément du registre 112. Par conséquent, le noeud 108-1 maintient un dépôt privé 116, le noeud 108-2 maintient un dépôt privé 120 et le noeud 108-3 maintient un dépôt privé 124. La pondération de vote affectée à un noeud donné 108 peut dépendre du contenu des données privées conservées par ce noeud 108. [0045] Avant de détailler la fonctionnalité implémentée par les noeuds 108 du système 100 pour tenir à jour le registre 112, certains composants internes des noeuds 108-1 seront expliqués en supposant que les noeuds 108-2 et 108-3 incluent des composants 7 équivalents (bien qu'ils ne soient pas nécessairement identiques). [0046] Le noeud 108-1 inclut au moins un processeur 128, tel qu'une unité de traitement central (CPU) ou autre. Le processeur 128 est relié à une mémoire 132 implémentée comme un support non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire [RAM], mémoires à lecture seule [ROM], mémoires programmables à lecture seule effaçables électriquement [EEPROM], mémoires flash, stockage informatique magnétique, et ainsi de suite). Le processeur 128 et la mémoire 132 sont généralement compris d'un ou de plusieurs circuits intégrés (Ifs). [0047] Le processeur 128 est aussi relié à une interface de communication 136 qui permet au noeud 108-1 de communiquer avec les autres dispositifs informatiques du système 100 (incluant les noeuds 108-2 et 108-3) via le réseau 104. L'interface de commu- nications 136 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d'interface de réseau [NT1Cs] des unités de radio, et autres) pour communiquer via le réseau 104. Les composants spécifiques de l'interface de communications 136 sont sélectionnés en fonction de la nature du réseau 104. Le noeud 108-1 peut aussi inclure des dispositifs d'entrée et de sortie connectés au processeur 128, tels que des claviers, des souris, des écrans, et autres (non illustrés). [0048] Les composants du noeud 108-1 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, le noeud 108-1 inclut une pluralité de processeurs qui peuvent partager la mémoire 132 et l'interface de communications 136, ou qui ont chacun des interfaces de communications et des mémoires associées distinctes. [0049] La mémoire 132 stocke la copie locale 112-1 du registre 112 mentionné ci-dessus ainsi que le dépôt de données privées 116. La mémoire 132 stocke aussi une pluralité d'instructions de programmation lisibles par ordinateur, exécutables par le processeur 128 sous forme d'applications variées incluant l'application cliente de registre distribué 140-1 et l'application génératrice de votes 144. Les hommes de métier comprendront que le processeur 128 exécute les instructions des ap- plications 140-1 et 144 (et toutes autres applications pertinentes) afin de mettre en oeuvre des actions diverses définies par les instructions contenues dans les présentes. Dans la description ci-dessous, le processeur 128 et, de façon plus générale, le noeud 108-1 sont censés être configurés pour mettre en oeuvre ces actions. On comprendra qu'ils sont configurés ainsi via l'exécution (par le processeur 128) des instructions des applications stockées dans la mémoire 132. Les noeuds 108-2 et 108-3 stockent des applications clientes de registre distribué 140-2 et 140-3 ainsi que des applications génératrices de votes 148 et 152, respectivement. 8 [0050] L'exécution des applications clientes 140, comme cela sera expliqué ci-dessous, configure chaque noeud 108 respectif pour échanger des mises à jour proposées au registre 112 avec les autres noeuds, coordonne aussi l'échange des votes avec les autres noeuds et gère l'application des changements au registre 112 (p. ex. lorsque les votes échangés entre les noeuds 108 indiquent qu'une mise à jour proposée doit être appliquée au registre 112). Les votes eux-mêmes sont générés à chaque noeud 108 via l'exécution de l'application génératrice de votes correspondante. Par conséquent le noeud 108-2, par exemple, exécute l'application génératrice de votes 148 pour générer des votes (pour l'acceptation ou le rejet d'une mise à jour). Ainsi qu'indiqué par les numéros de référence appliqués aux applications génératrices de votes 144, 148 et 152, par comparaison aux applications clientes 140, la fonctionnalité des applications clientes 140 est en substance identique à chaque noeud alors que la fonctionnalité implémentée par l'application génératrice de votes 144 n'a pas besoin d'être identique à celle des applications 148 et 152. En d'autres ternies, les noeuds 108 implémentent chacun un processus commun (dicté par les applications 140) pour échanger les mises à jour proposées et les votes pour ces mises à jour, mais implémentent chacun des algorithmes distincts pour déterminer les votes actuels. La génération de vote au niveau de chaque noeud 108 peut donc reposer au moins en partie sur les données privées du noeud 108 et peut être mise en oeuvre selon des algorithmes qui ne sont pas connus des autres noeuds 108. [0051] Faisant maintenant référence à la FIG. 2, certains aspects d'exploitation du système 100 seront décrits de façon plus détaillée. Spécifiquement, la FIG. 2 illustre un procédé 200 pour tenir à jour le registre 112. Le procédé 200 sera décrit conjointement avec sa mise en oeuvre dans le système 100 et spécifiquement par chacun des noeuds 108 via l'exécution des applications clientes de DLT 140 et les applications génératrices de votes 144, 148 et 152. C'est-à-dire que le procédé 200 est mis en oeuvre parallèlement par chaque noeud 108 dans le système 100. [0052] Au bloc 205, le noeud 108 est configuré pour stocker des identifiants de noeuds et des pondérations de vote pour chaque noeud 108 dans le système 100. Ainsi, le noeud 108-1 stocke les identifiants du noeud et les pondérations de vote à la fois pour lui-même (désignée comme pondération de vote local) et pour les noeuds 108-2 et 108-3 (désignées comme pondérations de votes distants). Les identifiants de noeuds peuvent inclure des adresses de réseau (p. ex. toute combinaison pertinente d'adresses IP, de nombre de ports, d'identifiants de domaine et d'autres), ou tout autre identifiant pertinent pour établir des communications avec les noeuds 108 sur le réseau 104. Les pondérations de vote, comme cela sera expliqué ci-dessous, définissent le degré d'influence que chaque noeud 108 a sur les décisions d'appliquer ou de rejeter des mises à jour proposées au registre 112. Le tableau 1 illustre un exemple d'ensemble 9 d'identifiants de noeuds et de pondérations de votes correspondantes. [0053] Identifiants de noeuds et pondérations de votes exemplaires : [0054] [Tableaux 1] ID noeud Pondération de vote 108-1 40% 108-2 45% 108-3 15% [0055] Comme on le voit maintenant, chaque noeud 108 stocke les données ci-dessus. Les identifiants de noeuds et les pondérations de vote, tels qu'ils sont stockés à chaque noeud 108 peuvent contenir des indications concernant quel enregistrement représente des données locales et quels noeuds représentent des données distantes. Les pondérations de vote sont exprimées ci-dessus sous forme de pourcentage, mais peuvent être exprimées sous divers autres formats dans d'autres exemples. [0056] Les pondérations de votes et les identifiants de noeuds sont échangés par les noeuds 108 au cours du déploiement du système 100. Les pondérations de votes sont prédéfinies et sont généralement statiques (bien que dans certains cas il peut-être souhaitable de reconfigurer le système 100, par exemple pour déployer un noeud additionnel 108 nécessitant une mise à jour des pondérations de votes). Les pondérations de vote peuvent être sélectionnées selon un quelconque critère parmi une large variété de critères. Par exemple, une pondération de vote plus importante peut être affectée à un noeud 108 en fonction de l'ampleur des données privées stockées par ce noeud. Dans d'autres modes de réalisation, plusieurs pondérations de vote peuvent être affectées à chaque noeud. Chaque pondération de vote pour un noeud donné peut correspondre à un type de mises à jour de la DLT 112. Par exemple, pour des insertions de nouvelles données dans la DLT 112, un noeud donné peut avoir une première pondération alors que pour éditer des données existantes dans la DLT 112, le même noeud peut avoir une seconde pondération différente de la première pondération. Dans d'autres exemples, les pondérations distinctes affectées à un noeud donné peuvent correspondre à des champs particuliers, des valeurs, ou d'autres éléments de ce genre dans la DLT 112. Par exemple, un noeud exploité par une compagnie aérienne peut avoir une première pondération pour un usage lié à des mises à jour quelconques d'horaires de vol définies dans la DLT 112 et une deuxième pondération (p. ex. une pondération moins importante) pour un usage lié à des mises à jour quelconques des informations de contact pour un passager. [0057] Au bloc 210, le noeud 108 est configuré pour déterminer si une défaillance locale est survenue pouvant nécessiter un processus de rétablissement pour obtenir des mises à jour au registre 112 qui n'ont pas été reçues. Une défaillance locale, telle qu'elle est désignée dans les présentes, est une quelconque condition ou ensemble de conditions empêchant un noeud 108 d'échanger des données avec les autres noeuds 108. Ainsi, une perte de connectivité, un temps d'arrêt planifié ou non planifié (p. ex. pour la maintenance), entre autres, sont tous des exemples d'une défaillance locale. En bref, suite à une défaillance locale le noeud 108 est configure pour récupérer des mises à jour effectuées parmi les autres noeuds 108 au cours de la défaillance locale et pour évaluer les mises à jour selon un procédé qui sera expliqué ci-dessous en se référant à la FIG. 6. [0058] Lorsque la détermination au bloc 210 est négative, la mise en oeuvre du procédé 200 avance au bloc 215. Au bloc 215, le noeud 108 est configure pour obtenir une mise à jour proposée au registre et pour stocker la mise à jour proposée dans une file d'attente (p. ex. dans la mémoire 132) dans l'attente d'un traitement supplémentaire. L'obtention d'une mise à jour proposée inclut soit de recevoir la mise à jour proposée d'un autre noeud 108 via un quelconque mécanisme pertinent de synchronisation de DLT (implémenté par l'application cliente 140), soit de générer la mise à jour localement (auquel cas la mise à jour proposée est aussi transmise aux autres noeuds 108 pour réception lors des mises en oeuvre parallèles du bloc 215 dans ces noeuds 108). [0059] Au bloc 215, le noeud 108 est aussi configure pour générer un vote local cor- respondant à la mise à jour proposée. La génération d'un vote local par chaque noeud 108, ainsi que noté précédemment peut être mise en oeuvre selon un quelconque critère pertinent qui n'a pas besoin d'être partagé entre les noeuds 108. [0060] Au bloc 220, le noeud 108 est configuré pour transmettre le vote local généré au bloc 215 aux autres noeuds 108 et pour recevoir des votes (désignés comme votes distants) relatifs à la mise à jour proposée obtenue au bloc 215, des autres noeuds 108. C'est-à-dire que les autres noeuds 108 ayant aussi obtenu la mise à jour proposée via les mises en oeuvre respectives du bloc 215 sont aussi configurés pour générer des votes locaux et transmettre les votes locaux via les mises en oeuvre respectives du bloc 220. Les FIGS. 3A et 3B illustrent des mises en oeuvre exemplaires des blocs 215 et 220. Spécifiquement, la FIG. 3A illustre une mise à jour proposée 300 provenant du noeud 108-3, telle qu'une mise à jour proposée pour enregistrer une plainte relative au service d'un vol lié à un enregistrement donné de passager (p. ex., défini par un nom de passager ou un autre identifiant approprié). La mise à jour proposée 300 est propagée aux noeuds 108-1 et 108-2 comme indiqué par les lignes en pointillés. [0061] La FIG. 3B illustre la génération et l'échange de votes au bloc 220. Spécifiquement, chaque noeud 108 génère un vote respectif 304-1, 304-2, et 304-3 et transmet le vote 304 aux deux autres noeuds 108. Par exemple, le vote 304-3 est censé être affirmatif (parce que le noeud 108-3 a initié la mise à jour proposée. Cependant, les 11 votes 304-1 et 304-2 sont négatifs dans le présent exemple. Par exemple, le noeud 108-1 peut être configure pour déterminer si le nom de passager associé à la mise à jour proposée est associé à la réservation d'un vol. Lorsque la détermination est négative, le noeud 108-1 peut être configure pour voter contre l'application de la mise à jour (p. ex. parce qu'une plainte relative au service de vol n'est vraisemblablement pas valide lorsque le passager correspondant n'a réservé aucun vol). Cependant, le vote 304-2 généré par le noeud 108-2 est également négatif dans le présent exemple. Par exemple, le noeud 108-2 peut être configure pour déterminer si le nom de passager associé à la mise à jour proposée est enregistré sur un vol quelconque. Étant donné que le passager n'a réservé aucun vol, la détermination est négative. [0062] Faisant référence à nouveau à la FIG. 2 au bloc 225, suite à un laps de temps prédéfini, chaque noeud 108 est configure sur la base du vote local généré au bloc 215 et des votes distants reçus au bloc 220 afin de déterminer s'il faut permettre la mise à jour proposée. La détermination au bloc 225 comprend de faire la synthèse des votes en faveur de l'application de la mise à jour et des votes contre l'application de la mise à jour, pondérés selon les pondérations de votes décrites en lien avec le bloc 205 et de déterminer si la majorité du vote pondéré est d'appliquer ou de rejeter la mise à jour proposée. Le tableau 2 ci-dessous illustre un résultat exemplaire de la mise à jour mentionnée ci-dessus en lien avec les PICS. 3A et 3B. [0063] Votes et résultats exemplaires [0064] [Tableaux2] ID noeud Pondération de vote Vote Résultat 108-1 40 % Rejeter 85/100 Rejet 108-2 45 % Rejeter 108-3 15% Approuver [0065] Comme on le constate ci-dessus, la majorité du vote pondéré est de rejeter la mise à jour proposée. Bien que les trois noeuds 108 aient généré des votes pour rejeter ou approuver la mise à jour proposée dans l'exemple ci-dessus, dans d'autres exemples un troisième type de vote peut être généré par un ou plusieurs noeuds 108. En particulier, l'algorithme de génération de vote appliqué à un noeud 108 peut spécifier que le noeud 108 manque d'informations suffisantes pour générer un vote pour appliquer ou rejeter des mises à jour de certains enregistrements ou de champs du registre. Par exemple, le noeud 108-3 peut manquer d'informations suffisantes permettant de voter l'application ou le rejet de mises à jour des prix des vols dans le registre 112. L'application 152 peut donc spécifier que pour les mises à jour du champ, relatif au prix, d'un enregistrement définissant un vol, le noeud 108-3 générera un vote 12 d'abstention (également appelé vote blanc). Le vote pondéré dans de telles conditions omet la pondération du noeud 108-3 et est donc évalué à un poids total de 85 plutôt que 100. [0066] Au bloc 230, chaque noeud 108 est configure pour déterminer si des votes sont manquants. C'est-à-dire que chaque noeud 108 est configure pour déterminer si les votes distants reçus au bloc 220 représentent un ensemble complet de votes. Lorsque l'enregistrement des votes assemblé à partir des blocs 215 et 220 est incomplet, indiquant qu'un ou plusieurs votes n'ont pas été reçus pendant le laps de temps mentionné ci-dessus (p. ex. un ou plusieurs noeuds 108 ont subi une défaillance), la mise en oeuvre du procédé 200 avance au bloc 240 détaillé ci-dessous. Cependant dans le présent exemple, des votes ont été reçus de chaque noeud 108 et la détermination au bloc 230 est par conséquent négative (c.-à-d. qu'aucun vote n'est manquant quand la détermination est faite au bloc 225). Le noeud 108 avance donc au bloc 235 où la mise à jour proposée est appliquée au registre 112, ou rejetée selon le résultat du bloc 225. Dans le présent exemple, en se référant à la FIG. 3B, le résultat du bloc 225 est que la mise à jour proposée est rejetée. Par conséquent, la mise à jour proposée 300 est sortie de la liste d'attente à chaque noeud 108 et les copies locales 112 du registre restent inchangées. Dans d'autres exemples, les copies locales 112 du registre 112 sont mises à jour pour stocker la mise à jour proposée avec une indication que la mise à jour proposée a été rejetée. Par conséquent, le registre 112 conserve un historique de toutes les mises à jour proposées y compris celles qui ont été rejetées. Chaque noeud revient ensuite au bloc 210. [0067] Comme noté ci-dessus, lorsque la détermination au bloc 230 est affirmative, indiquant que des votes n'ont pas été reçus de tous les noeuds 108 au cours du laps de temps mentionné en lien avec le bloc 225, chaque noeud 108 avance au bloc 240. Comme on le verra maintenant, bien que le procédé 200 soit décrit ci-dessus comme étant mis en oeuvre parallèlement par chaque noeud 108, une détermination affirmative au bloc 230 indique typiquement qu'un ou plusieurs noeuds 108 ont subi une défaillance et ces noeuds 108 ne peuvent donc pas mettre en oeuvre le procédé 200 (p. ex. parce qu'ils n'ont pas reçu la mise à jour au bloc 215). [0068] Au bloc 240, chacun des noeuds restants 108 (c.-à-d. ceux qui n'ont pas été affectés par une défaillance) est configuré pour déterminer, sur la base des votes reçus aux blocs 215 et 220, si le résultat déterminé au bloc 225 est incertain. Un résultat incertain est un résultat qui pourrait être inversé par un vote manquant, si le vote manquant était présent. Par exemple, le tableau 3 liste un ensemble de votes dans lequel aucun vote n'a été reçu en provenance du noeud 108-3. Cependant, puisque les noeuds 108-1 et 108-2 qui ensemble représentent 85 % du vote total pondéré ont tous deux généré des votes locaux favorables à l'application de la mise à jour proposée, la détermination par 13 les noeuds 108-1 et 108-2 au bloc 225 (d'appliquer la mise à jour) n'est pas incertaine parce qu'aucun vote du noeud 108-3 ne pourrait altérer la détermination du bloc 225. [0069] Votes et résultats exemplaires [0070] [Tableaux3] ID noeud Pondération de vote Vote Résultat 108-1 40 % Approuver Approuver 85/85 108-2 45 % Approuver 108-3 15% NIA [0071] La détermination au bloc 240 est donc négative dans le présent exemple et les noeuds 108-1 et 108-2 avancent chacun au bloc 235 comme indiqué ci-dessus. Les FIGS. 4A-4C illustrent le processus ci-dessus. En particulier, la FIG. 4A décrit une mise à jour proposée 400 générée par le noeud 108-1. Cependant, le noeud 108-3 n'est pas connecté au réseau 104 et par conséquent ne reçoit pas la mise à jour proposée 400. Par conséquent, comme le montre la FIG. 4B, les noeuds 108-1 et 108-2 échangent des votes 404-1 et 404-2, mais aucun vote n'est reçu du noeud 108-3. Finalement, comme le montre la FIG. 4C, les copies locales 112-1 et 112-2 du registre 112 sont mises à jour (apparaissant sous 112-1* et 112-2*) et la mise à jour proposée 400 est sortie de la liste d'attente aux noeuds 108-1 et 108-2, mais la copie locale 112-3 du noeud 108-3 reste inchangée. [0072] Un autre exemple est illustré dans FIGS. 5A-5C. En particulier, comme le montre la FIG. 5A, une mise à jour proposée 500 provenant du noeud 108-1 ne parvient pas au noeud 108-3. Les noeuds 108-1 et 108-2 stockent donc la mise à jour proposée 500 dans leurs files d'attente respectives et échangent les votes 504-1 et 504-2, mais aucun vote n'est reçu du noeud 108-3. Le tableau 4 montre des votes et des pondérations de votes exemplaires correspondant aux FIGS. 5A-5B. En particulier, la pondération de vote correspondant au noeud 108-3 est 45 %, alors que le poids affecté au noeud 108-2 n'est que 15 %. Par conséquent, à la suite d'une détermination affirmative au bloc 230, la détermination au bloc 240 pour chacun des noeuds 108-1 et 108-2 est affirmative. C'est-à-dire que le résultat montré ci-dessous (rejetant la mise à jour proposée 500 parce que la majorité du vote pondéré disponible est de rejeter la mise à jour) est incertain, car le poids correspondant au noeud 108-3 est suffisant pour altérer la détermination au bloc 225 si un vote du noeud 108-3 était disponible. [0073] Votes et résultats exemplaires [0074] 14 [Tablcaux4] ID noeud Pondération de vote Vote Résultat 108-1 40 % Rejeter Rejeter 40/55 108-2 15% Approuver 108-3 45 % N/A [0075] Les noeuds 108-1 et 108-2 avancent donc au bloc 245. Au bloc 245, les noeuds 108-1 et 108-2 sont néanmoins configurés pour appliquer ou rejeter la mise à jour proposée 500 selon la détermination au bloc 225 (c.-à-d. que dans le présent exemple, la mise à jour proposée 500 est rejetée). Comme le montre la FIG. 5C, les copies locales 112-1 et 112-2 restent inchangées. Cependant, la mise à jour proposée 500 est maintenue dans la file d'attente ainsi que les votes reçus au bloc 215 et 220. Les noeuds 108-1 et 108-2 peuvent ensuite être configurés pour continuer à traiter d'autres mises à jour en retournant au bloc 210. Cependant, les noeuds 108-1 et 108-2 aussi, parallèlement à ces autres mises à jour proposées, avancent au bloc 250 dans l'attente d'une résolution du résultat incertain identifié au bloc 240. La nature de la résolution est dépendante du vote généré par le noeud 108-3 lui-même et sera détaillée ci-dessous. [0076] Lorsque la détermination au bloc 210 est affirmative, indiquant qu'un noeud 108 a eu une défaillance récente (p. ex. le noeud 108 peut faire une détermination affirmative au bloc 210 en réponse au rétablissement de la connectivité avec le réseau 104), le noeud 108 procède à la mise en oeuvre du procédé 600 montré dans la FIG. 6. En bref, la mise en oeuvre du procédé 600 permet au noeud 108 ayant subi une défaillance de récupérer toutes les mises à jour du registre 112 qui ont eu lieu pendant la défaillance et de déterminer s'il faut modifier une quelconque des mises à jour susmentionnées via un vote rétroactif. C'est-à-dire que le procédé 600 permet au noeud 108 doté d'une pondération de vote suffisante pour altérer une mise à jour antérieure (c.-à-d. avec une pondération de vote suffisante pour rendre une mise à jour antérieure incertaine) de réévaluer la mise à jour et, si nécessaire, d'inverser la détermination faite au bloc 225 par les autres noeuds 108 en l'absence du vote du présent noeud. [0077] En continuant avec l'exemple ci-dessus dans lequel le noeud 108-3 a été déconnecté du réseau 104, au bloc 605, il est supposé que le noeud 108-3 a rétabli la connectivité avec le réseau 104. Le noeud 108-3 est confieuré au bloc 605 pour recevoir et appliquer des mises à jour faites au dépôt 112 au cours de la défaillance. Par exemple, le noeud 108-3 peut transmettre une requête aux noeuds 108-1 et 108-2 contenant un horodatage de la transaction la plus récente dans la copie locale 112-3 du registre ou toutes autres données pertinentes pour indiquer la durée pendant laquelle le noeud 108-3 était hors ligne. En réponse à cette reconnexion, le noeud 108-3 est configuré pour obtenir une copie actualisée du registre 1 1 2 pour stockage comme copie locale 112-3. La copie locale 1 1 2-3 est donc mise à jour pour inclure des enregistrements de toutes les mises à jour qui ont été proposées (qu'elles aient été acceptées ou rejetées) pendant le laps de temps où le noeud 108-3 était déconnecté. Par conséquent dans le présent exemple, bien qu'aucune mise à jour n'ait été appliquée (comme indiqué ci-dessus en lien avec la FIG. SC), la copie actuelle du registre 112 indique que la mise à jour proposée 500 a été évaluée et rejetée pendant que le noeud 108-3 était déconnecté. La mise à jour proposée 500 est donc également retenue dans les files d'attente à chacun des noeuds 108-1 et 108-2. [0078] Au bloc 610, le noeud 108-3 est configuré pour déterminer si la copie actuelle du registre 1 1 2 (c.-à-d. telle qu'elle est reflétée dans la copie locale 112-3) contient une quelconque des mises à jour traitées sous la forme de mises à jour proposées appliquées ou rejetées ayant fait l'objet d'un vote pendant le laps de temps où le noeud 108-3 était déconnecté. La détermination au bloc 610 peut inclure une détermination des résultats incertains d'une quelconque de ces mises à jour. Lorsque la détermination au bloc 610 est négative, indiquant, soit qu'aucune mise à jour non traitée n'est présente (c.-à-d. qu'il n'y avait pas d'activité dans le registre 112 pendant le laps de temps où le noeud 108-3 était déconnecté), soit que les mises à jour qui sont survenues pendant la défaillance n'étaient pas incertaines (c.-à-d. qu'elles ne pouvaient pas être changées par le vote du noeud qui a subi la défaillance), la mise en oeuvre du processus 600 est achevée et le noeud 108-3 retourne au bloc 210. Cependant, lorsque la détermination au bloc 610 est affirmative, comme dans l'exemple du noeud 108-3 mentionné ci-dessus, la mise en oeuvre du procédé 600 se poursuit au bloc 615. [0079] Au bloc 615, le noeud 108-3 est configuré pour ajouter chaque mise à jour non traitée dans le registre 112, dans une file d'attente locale et pour générer un vote local pour chaque mise à jour proposée représentée dans la file d'attente. La file d'attente peut être traitée, par exemple, par ordre chronologique en commençant avec la plus ancienne mise à jour non traitée. C'est-à-dire que lorsque la file d'attente contient plus d'une seule mise à jour proposée (qui selon la discussion précédente est une évidence, ont en fait déjà été appliquées au registre 112 ou rejetées aux noeuds 108-1 et 108-2), le noeud 108-3 est configuré pour générer des votes locaux pour chaque mise à jour proposée dans la file d'attente. La mise en oeuvre de la portion restante du procédé 600 est donc répétée pour chaque mise à jour non traitée dans la file d'attente. [0080] En réponse à la génération d'un vote local pour une mise à jour non traitée, le noeud 108 ayant subi une défaillance est configuré au bloc 620 pour déterminer si le vote local généré au bloc 615 est lié à une mise à jour non traitée dont dépendent d'autres mises à jour non traitées. À titre d'exemple de conflit de dépendance entre les mises à jour non traitée (c.-à-d. celles qui sont dans la file d'attente du noeud 108-3), 16 durant le laps de temps où le noeud du 108-3 était déconnecté, une première mise à jour peut être appliquée au registre 112 pour insérer une réservation de vol pour un passager donné et une deuxième mise à jour peut par la suite être appliquée au registre pour stocker un indicateur d'enregistrement de bagages pour la réservation de vol (p. ex. indiquant que le passager a payé pour un bagage enregistré). Le noeud 108-3 peut être configure pour déterminer, suite à une génération au bloc 615 d'un vote local pour rejeter la réservation de vol, que l'indicateur de bagage enregistré est dépendant de la réservation de vol. En d'autres termes, en transmettant simplement un vote local pour rejeter la réservation de vol, il pourrait en résulter une incohérence dans le registre 112 qui indiquerait un paiement de bagage enregistré pour une réservation de vol non existante. Dans un tel scénario, la détermination au bloc 620 est affirmative. [0081] Suite à une détermination affirmative au bloc 620, au bloc 625 le noeud 108-3 est configure pour générer une mise à jour proposée ou une autre action pertinente pour résoudre le conflit détecté au bloc 620. Par exemple, le noeud 108-3 peut être configure pour récupérer la mise à jour non traitée qui est en conflit avec la mise à jour non traitée actuelle et pour générer un vote au bloc 615 pour cette mise à jour. En continuant avec l'exemple ci-dessus, le noeud 108-3 peut donc être configure pour générer un vote local pour l'enregistrement de bagages enregistres avant d'envoyer le vote local pour la réservation de vol, traitant de cc fait les mises à jour conflictuelles par ordre chronologique inverse. Dans d'autres exemples, le noeud 108-3 peut être configure pour générer une autre mise à jour proposée pour circulation entre les noeuds 108 et un traitement via le procédé 200 comme expliqué ci-dessus. Certains conflits détectés au bloc 620 peuvent nécessiter l'intervention d'un opérateur pour une résolution et la mise en oeuvre du bloc 625 peut donc inclure la réception de données entrées définissant une mise à jour proposée. [0082] En réponse à la génération d'une mise à jour proposée au bloc 625 d'une déter- mination négative au bloc 620, au bloc 630 le noeud 108-3 est configure pour envoyer le vote local généré au bloc 615 (et, le cas échéant, toutes les mises à jour proposées ou autres actions générées au bloc 625) aux autres noeuds 108-1 et 108-3, pour traitement au bloc 250. [0083] Au bloc 250, chaque noeud 108 est configure pour déterminer si le vote manquant précédemment (c.-à-d. le vote local généré au bloc 615 par le noeud 108-3) modifie le résultat actuellement reflété dans le registre 112 (c.-à-d. le résultat produit via la mise en oeuvre antérieure du bloc 225). Lorsque la détermination au bloc 250 est négative, chaque noeud 108 poursuit au bloc 255 et retire la mise à jour proposée de la file d'attente respective. Ainsi, si le noeud 108-3 génère un vote pour rejeter la mise à jour proposée 500 au bloc 615, la détermination au bloc 250 (telle qu'elle est mise en oeuvre par chacun des noeuds 108-1. 108-2, 108-3 maintenant que l'enregistrement du vote 17 complet est disponible) est négative, et chaque noeud du 108 met en oeuvre le bloc 250, en retirant la mise à jour proposée 500 de leurs files d'attente respectives. Les noeuds 108 reviennent ensuite au bloc 210. [0084] D'autre part, quand la détermination au bloc 250 est affirmative, la mise en oeuvre du procédé 200 à chaque noeud 108 avance au bloc 260. Par exemple, si le noeud 108-3 génère un vote en faveur de l'application de la mise à jour proposée 500 au bloc 615 (qui est par la suite envoyée aux noeuds 108-1 et 108-2 au bloc 630), l'enregistrement complet du vote correspondant à la mise à jour proposée 500 est montré dans le tableau 5 ci-dessous. [0085] Votes et résultats exemplaires [0086] [Tableaux5] ID noeud Pondération de vote Vote Résultat 108-1 40 % Rejeter Approuver 60/100 108-2 15 % Approuver 108-3 45 % Approuver [0087] Comme on le voit ci-dessus, avec l'addition du vote génére au bloc 615 par le noeud 108-3, le résultat est altéré passant d'une décision de rejeter la mise à jour proposée 500 à une décision d'approuver (c.-à-d. d'appliquer) la mise à jour proposée 500. La détermination au bloc 250 étant affirmative, chaque noeud 108 met donc en oeuvre le bloc 260 auquel la mise à jour proposée est réappliquée (si elle avait été rejetée au bloc 225) ou inversée (si elle avait été appliquée au bloc 225). [0088] En d'autres termes, au bloc 260 chaque noeud 108 est configuré pour inverser le résultat de la détermination au bloc 225 comme le reflète actuellement le registre 112. Ainsi dans cet exemple, dans lequel la mise à jour proposée 500 a été rejetée (c.-à-d. qu'elle n'a pas été appliquée au registre), au bloc 260 chacun des noeuds 108-1, 108-2 et 108-3 est configuré pour appliquer la mise à jour proposée 500 au registre 112. Autrement, lorsque la mise à jour proposée a été précédemment appliquée, chaque noeud 108 est configuré pour appliquer l'inversion de la mise à jour (p. ex. lorsqu'une affectation de siège a été appliquée au registre 112, chaque noeud 108 est configuré pour supprimer l'affectation du siège). Les noeuds 108 peuvent être configurés pour mettre en oeuvre la réapplication de façon indépendante. Dans d'autres exemples, le noeud 108-3 peut être configuré pour transmettre une instruction de réévaluation ou de réapplication aux noeuds 108-2 et 108-3 avec le vote local envoyé au bloc 630. L'instruction de réévaluation contient la mise à jour proposée 500 ainsi que l'enregistrement de vote complet. montré ci-dessus dans le tableau 5. Dans chaque im- 18 plémentation, les noeuds 108-1 et 108-2 ne génèrent pas de votes additionnels en lien avec la réévaluation ou la mise à jour proposée 500. Au lieu de cela, les votes générés précédemment aux blocs 215 et 220 sont utilisés. Faisant référence à la FIG. 2 au bloc 260, les noeuds 108-1 108-2 et 108-3 sont donc configurés pour appliquer la mise à jour proposée 500 au registre 112. Les noeuds 108-1, 108-2 et 108-3 sont donc configurés pour éliminer la mise à jour proposée 500 de leurs files d'attente respectives au bloc 255 et reviennent au bloc 210. [0089] Les hommes de métier apprécieront que dans certains modes de réalisation, la fonc- tionnalité des applications 140, 144, 148 et 152 puisse être implémentée en utilisant du matériel préprogramrné ou des éléments micrologiciels (p. ex. des circuits intégrés spécifiques aux applications [ASICs], des mémoires à lecture seule programmables et effaçables électriquement [EEPROMs, etc.] ou d'autres composants associés. [0090] La portée ne pourrait être limitée aux modes de réalisation exposés dans les exemples ci-dessus, mais doit recevoir l'interprétation la plus large conformément à la description dans sa globalité. 19 [Revendication 1] [Revendication 2] [Revendication 3]