Brevet FR3145624A1 — publié le 20240809

Il est décrit un procédé de détermination d’un consensus au sein d’un ensemble de nœuds formant un réseau pair-à-pair de gestion d’une chaîne de blocs, le procédé comprenant la mise en œuvre, au niveau d’un nœud du réseau, des étapes suivantes: Calcul d’un score associé à chaque nœud, Sélection du nœud présentant le score le plus élevé, réception d’au moins un bloc généré par un nœud candidat et, lorsque le nœud candidat est le nœud sélectionné, la vérification de la validité du bloc, lorsque le bloc reçu est valide, envoi aux autres nœuds du réseau d’une notification identifiant le bloc reçu comme prochain bloc de la chaîne de bloc, réception de notifications émises par les autres nœuds du réseau, chaque notification identifiant un bloc sélectionné par un nœud respectif et, ajout à la chaîne de blocs du bloc identifié par une majorité des notifications reçues. Figure de l’abrégé : Figure 1 Détermination d’un consensus pour l’ajout d’un bloc à une chaîne de blocs La présente divulgation concerne un procédé de détermination d’un consensus pour l’ajout d’un bloc dans une chaîne de blocs. Les technologies de registres distribués constituent une alternative aux structures centralisées reposant sur une entité de confiance. Dans une structure distribuée, un ensemble de systèmes informatiques sont connectés les uns aux autres au sein d’un réseau pair à pair, permettant la répartition des tâches de traitement des données entre les différents nœuds du réseau. L’entité de confiance est remplacée, dans une telle structure, par un algorithme de consensus qui garantit que les informations stockées et les données générées par chaque nœud sont identiques. Tous les nœuds du réseau maintiennent localement une copie identique d’un registre distribué. Dans le cas d’une chaîne de bloc, un nouveau bloc, représentant un ensemble de données vérifiées et regroupées ensemble, est proposé par un nœud du réseau, et ce nouveau bloc doit faire l’objet d’un consensus, défini par l’algorithme de consensus mis en œuvre par l’ensemble des nœuds, pour être ajouté à la chaîne de blocs stockée par chaque nœud. Un algorithme de consensus classique repose sur la fourniture d’une preuve de travail. Plusieurs nœuds en compétition pour la production du prochain bloc cherchent à résoudre un problème complexe requérant un temps de traitement et des ressources de calcul élevées. Le premier nœud ayant résolu le problème produit le bloc et reçoit une récompense associée. Ce type d’algorithme de consensus a été fortement critiqué du fait de la consommation énergétique qu’il requiert, et de la faible latence qu’il permet, c’est-à-dire du faible rythme de production des blocs. On connaît également de la publication de Xiaoyu Zhu et al. « An Improved Proof-of-Trust Consensus Algorithm for Credible Crowdsourcing Blockchain Services”, un algorithme de consensus, ci-après noté IPoT dans lequel un candidat à la production d’un bloc présente un score de réputation calculée sur la base d’interactions passées avec d’autres nœuds. Le nœud producteur du prochain bloc est sélectionné aléatoirement sur la base d’une formule probabiliste basée sur un horodatage et une signature de l’en-tête du bloc actuel. Cet algorithme de consensus présente une consommation énergétique réduite par rapport à un consensus de type preuve de travail. De plus, la sélection probabiliste d’un nœud producteur de bloc rend imprévisible la connaissance du futur producteur de bloc, ce qui augmente la sécurité de l’algorithme. En revanche, elle permet aussi l’apparition de fourches dans la chaîne de blocs, c’est-à-dire l’apparition de deux blocs générés à la suite d’un même bloc initial. En effet, plusieurs nœuds peuvent satisfaire la formule de sélection, car les nœuds sont distribués et décident de manière indépendante. En outre, des nœuds peuvent être désynchronisés et possiblement utiliser des en-têtes de bloc différents et donc des paramètres de sélection différents. Le protocole prévoit une phase de vérification qui permet de valider le bloc généré, cependant l’article ne traite pas du cas où plusieurs blocs sont générés au cours du même tour. Dans un tel cas, il est nécessaire de prévoir un mécanisme supplémentaire pour supprimer les blocs générés en doublons et donc résoudre les fourches ainsi produites pour maintenir une chaîne linéaire, un tel mécanisme affectant directement les performances de l’algorithme. De plus, dans un consensus probabiliste, la probabilité d’apparition de fourches augmente avec la taille du réseau, ce qui affecte directement l’évolutivité (en anglais scalabilitity) de l’algorithme, et donc sa performance et la cohérence de la chaîne de blocs obtenue. Résumé La présente divulgation vient améliorer la situation. En particulier, un but de l’invention est de proposer un algorithme de consensus sécurisé, évolutif et efficace en ressources. Un but de l’invention est notamment de proposer un algorithme de consensus qui soit moins consommateur en ressources qu’un protocole de travail, mais qui ne produise pas de fourches dans la chaîne de blocs obtenue. Il est proposé un procédé de détermination d’un consensus au sein d’un ensemble de nœuds formant un réseau pair-à-pair de gestion d’une chaîne de blocs, pour l’ajout d’un nouveau bloc à la chaîne de blocs, le procédé étant mis en œuvre par un nœud du réseau pair-à-pair, le nœud étant mis en œuvre par un système informatique comprenant au moins un processeur et une mémoire stockant une liste de nœuds actifs, une valeur de réputation actuelle associée à chaque nœud actif, et une copie respective de la chaîne de blocs, le procédé comprenant : Le calcul d’un score associé à chaque nœud actif de la liste, à partir de la valeur de réputation actuelle du nœud actif et d’un montant de dépôt engagé par le nœud actif, La sélection du nœud producteur du prochain bloc, ce nœud présentant le score le plus élevé parmi les scores calculés, la réception d’au moins un bloc généré par un nœud candidat à l’ajout d’un nouveau bloc à la chaîne de blocs, et, lorsque le nœud candidat est le nœud sélectionné comme producteur du prochain bloc, la vérification de la validité du bloc, lorsque le bloc reçu est valide, l’envoi aux autres nœuds actifs du réseau d’une notification identifiant le bloc reçu comme prochain bloc de la chaîne de bloc, La réception d’une pluralité de notifications émises respectivement par les autres nœuds actifs du réseau, chaque notification identifiant un bloc sélectionné par un autre nœud actif du réseau et, L’ajout à la chaîne de blocs du bloc identifié par une majorité des notifications reçues. Dans des modes de réalisation, le procédé comprend, si le bloc généré est considéré invalide par une majorité des nœuds actifs du réseau, la suppression du nœud candidat ayant généré le bloc invalide de la liste des nœuds actifs. Dans des modes de réalisation, le procédé comprend en outre la redistribution du montant de dépôt aux autres nœuds actifs du réseau. Dans des modes de réalisation Procédé selon l’une des revendications précédentes, comprenant la suppression d’un nœud actif de la liste des nœuds actifs lorsque la réputation du nœud est inférieure à un seuil déterminé. Dans des modes de réalisation, chaque nœud actif définit un montant de garantie qui doit être compris entre des montants de garantie minimal et maximal déterminés, et le procédé comprend la suppression d’un nœud actif de la liste de nœuds actifs lorsque le montant de garantie déposé par le noeud est inférieur au montant de garantie minimal. Dans des modes de réalisation, chaque nœud actif définit un montant de garantie qui doit être compris entre des montants de garantie minimal et maximal déterminés, et le score d’un nœud actif est calculé à partir : d’un ratio entre la valeur de garantie définie par le noeud et la valeur de garantie maximale, et d’un ratio entre le montant de dépôt du noeud et la valeur de garantie. Dans des modes de réalisation, le score d’un nœud est une combinaison linéaire de la valeur de réputation actuelle, du ratio entre la valeur de garantie définie par le noeud et la valeur de garantie maximale, et du ratio entre le montant de dépôt du nœud et la valeur de garantie. Dans des modes de réalisation, le calcul du score d’un nœud tient en outre compte d’un taux de génération de bloc qui décroît avec le nombre de blocs ajoutés à la chaîne de blocs par le nœud pendant une période déterminée. Dans des modes de réalisation, chaque nœud est en outre configuré mettre en œuvre au moins une application d’interaction d’achat de produit ou de service hors de la chaîne de blocs, pour calculer une valeur de confiance associée à une interaction d’achat ayant eu lieu hors de la chaîne de blocs, chaque nœud étant en outre configuré pour calculer la valeur de réputation actuelle d’un nœud en fonction de : une valeur de réputation précédente, et la valeur de confiance associée à la dernière interaction d’achat ayant impliqué le nœud. Dans des modes de réalisation, chaque nœud est configuré pour calculer la valeur de réputation actuelle d’un participant par mise en œuvre d’un algorithme de type contrat intelligent. Selon un autre objet, il est décrit un produit programme d’ordinateur, comprenant des instructions de code pour la mise en œuvre du procédé selon l’une des revendications qui précède, quand il est exécuté par un ordinateur. Selon un autre objet, il est décrit un terminal informatique comprenant au moins un processeur et une mémoire, et étant connectés à un ensemble d’autres terminaux informatiques pour former un réseau pair à pair de gestion d’une chaîne de blocs, la mémoire du terminal informatique stockant une liste de nœuds dits actifs, une valeur de réputation actuelle associée à chaque nœud actif, et une copie respective de la chaîne de blocs, le terminal informatique étant configuré pour mettre en œuvre le procédé selon la description qui précède. Selon un autre objet, il est décrit un système informatique distribué comprenant un ensemble de terminaux informatiques connectés entre eux de manière à former un réseau pair-à-pair, chaque terminal informatique comprenant au moins un processeur et une mémoire et formant un nœud dudit réseau, le système étant caractérisé en ce que chaque terminal est configuré pour mettre en œuvre le procédé selon la description qui précède. L’algorithme de consensus proposé, basé sur une preuve de garantie et de réputation avec une méthode de notation pour la sélection du prochain nœud producteur de bloc, réduit les ressources de calcul nécessaires aux nœuds pour sa mise en œuvre et donc la consommation d’énergie associée. La méthode de calcul du score assure une équité entre les nœuds et résout un problème de monopolisation qui a lieu fréquemment dans des algorithmes de consensus de type preuve d’enjeu. Le procédé proposé permet en outre de réaliser une sélection déterministe du prochain nœud producteur de bloc d’une chaîne de blocs. Un et un seul nœud, celui avec le score le plus élevé, est sélectionné à chaque tour. La phase de vérification et de validation de ce protocole est plus rapide et plus efficace que l’art antérieur. Ainsi, l’évolutivité et la consistance globales de l’algorithme sont meilleures. Le score est basé à la fois sur un dépôt de garantie et sur une réputation du nœud, ce qui minimise les risques de nœuds malveillants puisqu’un bloc invalide ou une mauvaise réputation entraîne l’éviction d’un nœud de la liste des nœuds producteurs. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 représente schématiquement un système informatique distribué selon un mode de réalisation. Fig. 2 représente schématiquement la structure d’un nœud. Fig. 3 représente schématiquement un protocole de transaction commerciale pouvant être mis en œuvre entre deux nœuds du réseau. [Fig. 4] représente schématiquement un algorithme de consensus mis en œuvre par les nœuds du réseau pair à pair selon un mode de réalisation. Fig. 5a représente un exemple de courbe de croissance idéale d’un participant normal. [Fig. 5b] représente un exemple de courbe de croissance d’un participant malveillant. [Fig. 6] représente une évolution comparée de la latence de la mise en œuvre de différents algorithmes de consensus en fonction du nombre de nœuds. [Fig. 7] représente une évolution comparée du débit de différents algorithmes de consensus en fonction du nombre de nœuds. En référence à la , on a représenté l’architecture d’un système informatique distribué 1 selon un mode de réalisation. Ce système informatique comprend un ensemble de terminaux informatiques 10 connectés en réseau pair-à-pair 11, chaque terminal informatique 10 formant un nœud du réseau. Le réseau pair-à-pair permet à une pluralité de participants P d’interagir avec les autres participants, chaque participant possédant un terminal informatique respectif. Au sein du réseau, chaque nœud est connecté à au moins un autre nœud du réseau, par exemple au moyen d’une connexion à distance. Chaque terminal informatique peut à cet égard être configuré pour pouvoir se connecter à un réseau de communication sans-fil, par exemple un réseau de type Wi-Fi, 4G, 5G, etc. Chaque terminal informatique peut être par exemple un ordinateur ou un téléphone connecté (smartphone). Dans la suite, le terme « nœud » du réseau correspond à un équipement informatique connecté à au moins un autre terminal informatique du réseau et configuré pour mettre en œuvre les algorithmes permettant le fonctionnement du réseau pair-à-pair, et en particulier l’algorithme de consensus décrit ci-après. Le terme « participant » désigne un humain utilisant l’équipement informatique formant un nœud. De façon connue en soit, la chaîne de blocs est une base de données qui contient un historique de tous les échanges effectués entre les nœuds 10 du réseau depuis sa création, et qui est structurée en une succession de blocs, dont chaque bloc est relié au précédent de façon à former une chaîne. Chaque bloc comprend typiquement un identifiant de bloc, un élément permettant d’identifier le bloc précédent, et qui peut notamment être un hachage de l’identifiant du bloc précédent, et une consignation d’un ensemble de transactions réalisées au sein du réseau. Le terme « transaction » désigne ici une information ou une action entreprise par un nœud du réseau et qui est communiquée, sous forme chiffrée et signée par l’expéditeur, aux autres nœuds. Elle n’implique pas nécessairement de caractère réciproque, c’est-à-dire de réponse ou d’action réciproquement commise par un autre nœud du réseau. Tous les nœuds 10 du réseau maintiennent conjointement une chaîne de blocs BC commune en exécutant l’algorithme de consensus décrit ci-après pour la mettre à jour. Ainsi chaque nœud 10 du réseau comprend au moins un calculateur et une mémoire stockant une copie respective de la chaîne de blocs. Le ou les calculateurs d’un terminal informatique peuvent comprendre un ou plusieurs processeurs ou microprocesseurs (CPU), et/ou un ou plusieurs processeurs graphiques (GPU). La mémoire du nœud comprend au moins une mémoire non volatile ou mémoire morte par exemple de type ROM et une mémoire volatile ou mémoire vive telle qu’une mémoire RAM. Certains participants, et donc certains nœuds 12 du réseau, ont un rôle d’administrateur. Les administrateurs gèrent notamment l’arrivée ou la sortie de participants dans le réseau. En particulier, les nœuds administrateurs peuvent ajouter ou supprimer des nœuds 10 au réseau. Un participant ne peut rejoindre le réseau qu’après vérification de son identité par un administrateur, par exemple par la vérification d’un document d’identité du participant, incluant par exemple une capture d’image(s) de visage et la mise en œuvre d’une authentification entre la ou les images capturées et une ou plusieurs images de visage stockées dans le document d’identité. De fait, il n’est pas possible de créer plusieurs nœuds correspondant à un même participant. Comme décrit plus en détails ci-après, l’algorithme de consensus qui est mis en œuvre par les nœuds 10 du réseau 11 pour ajouter un nouveau bloc à la chaîne de blocs BC tient compte de la réputation des participants opérant les nœuds dans le monde réel, c’est-à-dire hors de la chaîne de bloc. A cet égard, chaque terminal informatique 10 mettant en œuvre un nœud est également configuré pour prendre part à des interactions commerciales dans le monde réel, une interaction commerciale comprenant la fourniture d’un produit ou d’un service dans le monde réel en contrepartie d’une somme d’argent, cette somme d’argent étant versée dans une cryptomonnaie, c’est-à-dire dans la monnaie échangée au sein de la chaîne de blocs. Comme décrit plus en détails ci-après, la réputation d’un participant correspondant à un nœud est mise à jour en fonction du déroulement d’interactions commerciales mises en œuvre hors de la chaîne de bloc. Pour réaliser le procédé de vérification qu’un service ou un produit a été correctement fourni lors d’une transaction hors de la chaîne de bloc, chaque nœud est configuré pour mettre en œuvre un module de vérification 20, qui peut par exemple employer des réseaux Oracle décentralisés (Decentralized Oracle Networks ou DONs), qui permettent la création de contrats intelligents hybrides, c’est-à-dire combinant des données externes et internes à la chaîne de blocs pour relier le fonctionnement de la chaîne de blocs avec des évènements intervenant hors de celle-ci. En référence à la , on a représenté schématiquement la structure d’un nœud. Chaque nœud est configuré pour pouvoir mettre en œuvre les modules fonctionnels suivants : Le module de vérification 20 décrit précédemment. Ce module est configuré pour vérifier et évaluer que la fourniture d’un produit ou d’un service dans le monde réel a effectivement eu lieu. Ce module est adapté pour vérifier immédiatement les interactions commerciales réalisées et également assurer un suivi de la qualité de ces interactions commerciales au cours du temps. Le module de vérification récupère des informations relatives à une interaction commerciale auprès d’un nœud 10 intervenant en tant qu’acheteur B de la transaction, et d’un nœud 10 intervenant en tant que vendeur S de la transaction, et d’un contrôleur indépendant ; vérifie la cohérence des informations collectées et produit un certificat qui peut être compris par tous les nœuds sur la base de la vérification effectuée. En fonction de la nature de la transaction, le contrôleur indépendant peut être un dispositif électronique autonome connecté avec une interface dédiée permettant l’acquisition des informations pertinentes D relatives à un certain type d’interaction commerciale (par exemple un compteur électrique intelligent avec une interface pour envoyer des informations relatives à la quantité d'énergie reçue), ou une entité physique indépendante ad hoc, comme par exemple un livreur dans un point relais avec un téléphone portable ou une tablette tactile pour scanner un QRCode porté par le produit objet de la transaction. La nature des informations collectées dépend de la nature de la transaction. Elle peut comprendre par exemple un indicateur booléen confirmant que la transaction a eu lieu ou non, un indicateur de l’état d’un produit livré, d’un délai de livraison, etc. Un module 21 de mise en œuvre de contrats intelligents (également dénommés « smart contracts » en anglais), c’est-à-dire de programmes automatiques déterministes et immuables (i.e. non modifiables) permettant la mise en œuvre de façon automatique de certaines actions si les conditions nécessaires à leur mise en œuvre sont vérifiées. Un contrat intelligent peut par exemple être mis en œuvre sous la forme d’un script executable et d’un modèle de données stocké dans la chaîne de blocs sous la forme d’un arbre de hashage de Merkle. Ce module met en œuvre l’ensemble du processus d’échange et contient trois sous-modules principaux : exécution des transactions commerciales 210, réputation 211 et garantie 212. Ces processus sont décrits plus en détails ci-après. Un module de communication 22 entre les nœuds à l’aide de protocoles P2P ou pair-à-pair. Chaque nœud doit être connecté à au moins un autre nœud du réseau pour que le réseau soit fonctionnel. Un module de cœur 23 comprenant tous les composants d’un client d’une chaîne de blocs, en particulier un module d’exécution 230 de l’algorithme de consensus décrit ci-après, qui permet de vérifier les transactions d’un bloc d’une chaîne de blocs, générer et valider un bloc. Le module de cœur 23 comprend également un module de stockage local 231 des informations relatives à la chaîne de blocs, et une machine virtuelle 232. Le module de vérification 20 a une interface externe spécifique pour la récupération des informations relatives D aux interactions commerciales hors chaîne de blocs comme indiqué ci-avant. Le module de vérification 20 communique avec le module 21 de mise en œuvre des contrats intelligents. En particulier, le module de vérification 20 fournit au module 21 les certificats qui sont issus de la vérification des transactions hors chaîne de blocs. Le module 21 et le module 23 de cœur interagissent pour permettre la mise en œuvre de l’algorithme de consensus à partir des valeurs de réputation et de garantie et actualiser ces valeurs après la mise en œuvre de l’algorithme de consensus. Enfin le module 22 de communication établit une communication avec les autres nœuds du réseau pour permettre la mise en œuvre de l’algorithme de consensus. En référence à la on a représenté un exemple de procédé d’interaction commerciale mis en œuvre entre deux nœuds 10 du réseau comprenant un acheteur B et un vendeur S, le procédé impliquant la fourniture d’un produit ou d’un service dans le monde réel par le vendeur S, c’est-à-dire hors chaîne de blocs, en contrepartie d’une somme d’argent fournie par l’acheteur B, le versement étant réalisé dans la chaîne de blocs. Comme décrit plus en détails ci-après, le procédé d’interaction commerciale comporte la génération d’un ensemble de transactions qui sont enregistrées dans la chaîne de blocs BC. Chaque nouveau participant doit s’inscrire auprès des nœuds 12 agissant en tant qu’administrateurs. Une fois l’inscription réalisée, chaque nœud est associé à un porte-monnaie numérique qui peut être rempli par conversion de monnaie hors chaîne de blocs en monnaie équivalente dans la chaîne de blocs. La structure générale d’une transaction réalisée dans la chaîne de blocs est la suivante : où « Flag » indique le type de transaction, H(T x ) est le hachage d’une donnée T x qui dépend de la transaction, Sig T est la signature de la personne qui initie la transaction et Montant est le montant de la somme que la personne qui initie la transaction a versé pour initier la transaction. Toutes les transactions générées sont chiffrées, signées et envoyées au réseau 11 par le module de communication du nœud du participant initiant la transaction. A l’étape S10 un vendeur S souhaitant mettre en vente un nouveau produit ou service génère une transaction qui inclut le prix du service ou du produit et une proportion de garantie Q que le vendeur récupère si le service ou le produit est rejeté par l’acheteur B à la réception. En effet, le procédé comprenant ensuite une étape de vérification du produit ou du service par l’acheteur, ce dernier peut rejeter le produit ou le service reçu. Pour protéger les vendeurs de rejets trop nombreux ou infondés de la part des acheteurs, les vendeurs fixent la proportion de garantie Q qui est le montant transféré de l’acheteur au vendeur en cas de rejet du service ou du produit. La proportion de garantie Q est une part du montant du produit ou du service considéré. Les vendeurs doivent donc déterminer une valeur de Q qui soit un compromis entre un Q trop bas, qui protège faiblement le vendeur contre le risque de rejet par l’acheteur, et un Q trop haut, qui dissuade l’acheteur. La transaction est ensuite envoyée à tous les nœuds au sein du réseau pour vérification. Si la transaction est validée, elle est stockée T10 dans la chaîne de blocs BC et l’ensemble des produits et services disponibles à la vente pour le nœud vendeur est mise à jour. Un nœud acheteur B peut ensuite choisir un produit ou un service qui lui convient et génère une transaction B10 visant à réaliser un achat, qui contient une identification du produit ou du service acheté. Cette transaction est envoyée à tous les nœuds du réseau pour vérification et, si elle est validée, elle est stockée dans la chaîne de blocs T11. A l’étape S11 un vendeur accepte la proposition d’un acheteur et génère une transaction comprenant l’identification de l’ordre d’achat qui a été accepté. Cette transaction est envoyée à tous les nœuds du réseau pour vérification et, si elle est validée, elle est stockée dans la chaîne de blocs T12. Le procédé comprend ensuite une étape de dépôt d’un acompte D B11 par l’acheteur (flèche Y sur la ). La transaction d’acompte T13 comprend l’identifiant de l’acheteur et du vendeur et le montant de l’acompte D. Cette transaction est enregistrée dans la chaîne de blocs pour prouver que l’acheteur a effectivement payé un acompte pour l’ordre d’achat correspondant. Alternativement, si le vendeur ne reçoit pas de confirmation du dépôt de l’acompte après un certain temps, l’ordre d’achat est rejeté (flèche N). Le procédé comprend ensuite l’étape de fourniture S12 du produit ou du service ayant fait l’objet de l’ordre d’achat, cette fourniture ayant lieu hors de la chaîne de bloc. On a également représenté sur la par B12 la réception du produit ou du service par l’acheteur B. Des preuves de la remise du produit ou de la réalisation du service sont récupérées T14 comme mentionné ci-avant par les modules de vérification des nœuds du réseau correspondants aux participants S et B de la transaction pour vérifier et valider que la fourniture du produit ou service a bien eu lieu, et les modules génèrent un certificat qui est également enregistré dans la chaîne de blocs au moyen d’une transaction de validation d’un ordre d’achat qui est établie à partir de l’identifiant de l’ordre d’achat et du certificat généré. On a représenté par une flèche Y en sortie de l’étape T14 le cas où la fourniture du produit ou service a eu lieu, et par la flèche N le cas où elle n’a pas eu lieu. La suite du procédé peut comprendre, dans le cas où le vendeur n’a pas fourni le service ou le produit, la restitution de l’acompte à l’acheteur et la mise à jour de la réputation du vendeur comme décrit plus en détails ci-après. Ceci fait l’objet d’une transaction T15 enregistrée dans la chaîne de blocs. Alternativement, dans le cas où le produit ou le service a été correctement fourni mais que l’acheteur ne l’accepte pas (flèche N après étape B13 d’acceptation du service), l’acompte peut être restitué en étant réparti entre l’acheteur et le vendeur selon une règle préalablement déterminée, et la réputation de l’acheteur peut être mise à jour. Ceci fait également l’objet d’une transaction enregistrée dans la chaîne de blocs T16. Selon encore une autre possibilité, le vendeur a correctement fourni le produit ou le service et l’acheteur l’a accepté, et l’acompte est transféré à l’acheteur, et la réputation de l’acheteur et du vendeur est mise à jour T17. Dans tous les cas, une transaction est enregistrée dans la chaîne de blocs identifiant la part de l’acompte restitué et le destinataire de la restitution de l’acompte, ainsi que la mise à jour de la réputation de l’un ou des deux participants à l’interaction commerciale. Le versement du montant restitué à l’acheteur et/ou au vendeur est mis en œuvre par implémentation d’un programme de type contrat intelligent par les modules 21 des nœuds respectifs correspondant à l’acheteur et au vendeur. On va maintenant décrire un mode de réalisation pour le calcul de la réputation d’un nœud du réseau. La réputation est calculée à partir de valeurs de confiance attribuées à l’acheteur et/ou au vendeur après chaque interaction commerciale. La valeur de confiance associée à un vendeur après une interaction commerciale i dans le monde réel est fournie par : Où représente la valeur de confiance subjective et représente la valeur de confiance objective, et est un coefficient de pondération entre les deux. De préférence, est choisi de manière à donner plus de poids à la valeur de confiance objective. La valeur de confiance subjective représente directement l’opinion de l’acheteur à propos du vendeur et est avantageusement calculée en mettant en œuvre une logique de confiance subjective telle que décrite dans les publications suivantes : J. Audun et al. “Trust Network Analysis with Subjective Logic”, in Dobbie, G. Estivill-Castro, V (Eds.) Conference Proceedings of the Twenty-Ninth Australasian Computer Science Conference (ACSW 2006), Australian Computer Society, CD Rom, pp. 85-94. J. Keng et al., « Towards secure blockchain-enabled Internet of vehicles : Optimizing consensus management using reputation and contract theory”, 2018, arXiv:1809.08387. Quand un acheteur B interagit avec un vendeur S, une opinion notée est fournie pour exprimer la confiance de l’acheteur b dans la fiabilité du vendeur s, où t, d et u représentent respectivement la confiance, la défiance, et l’incertitude, respectivement ; vérifient t+d+u=1, t,d,u sont inclus dans [0,1] et sont définis comme suit : Et la valeur de après la i ème interaction est : Où m et n sont respectivement le nombre d’interactions d’achat valides et invalides entre b et s, I f représente la fréquence d’interaction, plus celle-ci est élevée et plus l’incertitude est faible. est un coefficient de pondération de l’incertitude. La valeur de confiance objective dépend des résultats du processus de vérification mis en œuvre lors du procédé d’achat décrit ci-avant et des métriques utilisées lors de ce processus, qui dépendent de l’objet de la transaction. Où C est un booléen indiquant la présence (C=1) ou l’absence du certificat (C=0) émis pour une transaction valide, Pj sont des paramètres d’évaluation supplémentaires, qui varient en fonction du type de transaction considéré, et est un coefficient de pondération associé à Pj. Comme le certificat est généré à partir de preuves objectives de la fourniture du produit ou de la réalisation du service, on peut tenir compte de façon plus importante de la confiance objective en un nœud en donnant plus de poids au certificat. La combinaison des valeurs de confiance objective et subjective fournit une valeur globale de confiance du vendeur à la i ème interaction. Le même modèle est utilisé pour calculer la valeur de confiance de l’acheteur. La valeur de confiance associée à un nœud après une interaction i est ensuite utilisée pour mettre à jour une réputation du nœud. Chaque nœud du réseau est associé à une valeur de réputation initiale R init , cette valeur étant considérée comme un seuil inférieur que la réputation de chaque nœud ne doit pas franchir. Dans le cas où la réputation devient inférieure à cette valeur initiale, le participant associé au nœud est considéré comme non crédible par les autres participants du système, qui refuseront d’intéragir à lui dans une interaction commerciale ultérieure. Par conséquent, il devient pour lui très difficile de revenir à une valeur de réputation supérieure à R init . La réputation d’un ou plusieurs nœuds est donc mise à jour après une interaction commerciale ayant eu lieu dans le monde réel, hors de la chaîne de bloc, et ayant impliqué le nœud (i.e. en tant qu’acheteur ou vendeur). Le seul moyen de faire augmenter la valeur de réputation est de réaliser des interactions valides d’achat/vente de produit ou de services hors de la chaîne de blocs. La réputation associée à un nœud impliqué dans une interaction d’achat i est mise à jour comme suit : Où R i-1 représente la réputation à l’issue de la précédente interaction i-1, est une fonction de pondération prenant N b et T i comme entrées (Ti est la valeur de confiance associée au nœud à l’issue de la transaction i, que le nœud soit vendeur ou acheteur), où N b est le nombre de blocs ajoutés à la chaîne de blocs depuis que le nœud considéré a rejoint le réseau. L’avantage de cette formule est que le facteur de pondération utilisé est variable. Il s’agit d’une fonction sigmoïde qui est positivement corrélée à N b et T i , de sorte que plus un nœud reste longtemps dans le réseau, plus il est probable qu’il améliore sa réputation s’il se comporte honnêtement lors des interactions d’achat/vente. Un exemple de courbe de réputation d’un nœud honnête en fonction du temps est représenté en figure 5a, avec le protocole selon l’invention noté PoGR. La courbe IPoT correspond à la courbe de réputation d’un participant honnête selon le protocole IPoT de la publication de Zhu et al. Mentionnée ci-avant. est la valeur maximum du coefficient de pondération, qui peut seulement être atteinte lorsque N b devient très élevé. De plus, la fonction de pondération dépend non seulement de N b , mais aussi du score de confiance T i calculé à la dernière interaction, de sorte qu’un comportement malhonnête représenté par un score T i bas dans la dernière interaction aura un impact direct sur le score de réputation. A cet égard, une courbe de réputation d’un nœud malhonnête en fonction du temps est représentée en en étant comparée entre le protocole PoGR selon l’invention et le protocole IPoT de la publication de Zhu et al. En référence à la , on va maintenant décrire un algorithme de consensus, cet algorithme étant mis en œuvre par tous les nœuds du réseau intervenant dans le stockage et la mise à jour de la chaîne de blocs. Cet algorithme de consensus est basé sur une preuve de garantie et de réputation, avec une méthode de notation pour la sélection du nœud BP producteur du prochain bloc ajouté à la chaîne de blocs. Pour pouvoir mettre en œuvre l’algorithme de consensus et donc, pour un nœud, être impliqué dans la gestion et la mise à jour de la chaîne de blocs, chaque nœud doit initialement générer deux transactions TXG B , qui fixe un montant de garantie G B engagé par le noeud, et TXG p , qui définit un montant de dépôt G p , qui est une partie du montant de garantie G b et qui correspond à un risque consenti par le nœud. En effet, G p correspond à une somme d’argent, prélevée du montant de garantie G b , qui est perdue par le nœud quand celui-ci a généré un bloc invalide. La somme d’argent G p est transférée et répartie aux autres nœuds. Le montant de garantie GB doit être compris entre des valeurs G min et G max prédéfinies et fixées par les administrateurs, et le montant de dépôt G p est compris entre G min et le montant de garantie G b . Les transactions TXG B et TXG p sont vérifiées et stockées dans la chaîne de blocs, par la mise en œuvre de l’algorithme de consensus par les autres nœuds du réseau déjà impliqués dans la gestion de la chaîne de blocs. Le nœud ne peut mettre en œuvre l’algorithme de consensus que si les deux conditions suivantes sont vérifiées : Les transactions TXG b et TXG P sont valides, et La réputation du nœud est supérieure à R min où R min > R init est la valeur minimale qu’un participant doit avoir pour pouvoir opérer un nœud et participer au consensus. Chaque nœud participant à l’algorithme de consensus stocke une liste de nœuds actifs, c’est-à-dire une liste de nœuds mettant en œuvre l’algorithme de consensus, et le score de réputation associé à chaque nœud. Cette liste est mise à jour après l’ajout de chaque nouveau bloc à la chaîne de blocs. Si la réputation du nœud devient inférieure à R min ou si le montant de garantie Gb engagé par le nœud devient inférieur à G min , alors le nœud est automatiquement supprimé de la liste des nœuds actifs par le nœud qui met en œuvre l’algorithme de consensus. De plus, un administrateur peut exclure le nœud du réseau et empêcher un retour futur du nœud en bloquant un identifiant du noeud, par exemple son adresse blockchain, i.e. sa clé publique. Un administrateur peut également interdire à un participant de générer un nouveau nœud en bloquant son adresse. Les deux fonctionnalités sont assurées à l’aide d’un contrait intelligent qui définit les droits et les rôles de chaque participant. L’algorithme de consensus comprend, pour chaque nœud qui l’exécute, le calcul d’un score associé à chaque nœud actif de la liste, à partir de la valeur de réputation actuelle du nœud et du montant de dépôt engagé par le nœud. Le score tient également compte du montant de garantie engagé par le nœud. Dans un mode de réalisation, le score est une combinaison linéaire de trois paramètres : la réputation du nœud, un facteur G = G B /G Max qui est le ratio entre le montant de garantie du nœud et le montant maximum pouvant être engagé, et qui représente donc la proportion du montant maximal que le nœud bloque en tant que solde de garantie, et un facteur E=G P /G B qui représente le risque pris par le participant, puisque plus le montant de dépôt est proche du montant de garantie, et plus le risque pour le nœud d’être supprimé de la liste des nœuds actifs en cas de bloc invalide est élevé. Selon un exemple, le score S n associé à un nœud n est calculé selon la formule suivante : est un taux de génération de bloc initialement égal à 1, et qui décroit exponentiellement avec le nombre de blocs générés par le nœud n et qui ont été ajoutés à la chaîne de blocs pendant un cycle B c . B c est une durée exprimée en nombre de blocs ajoutés à la chaîne de blocs depuis la génération d’un bloc par le nœud n considéré. Bc correspond à une période durant laquelle un nœud ne doit pas générer de bloc pour pouvoir récupérer un taux de 100%. Par exemple, si Bc =5, et qu’un noeud n génère un nouveau bloc, le nœud ne récupère un taux de génération de 100% qu’après l’ajout à la chaîne de blocs de cinq blocs générés par d’autres nœuds du réseau. En d’autres termes, ne revient à la valeur de 1 après la génération par le nœud n d’un bloc, que quand le nœud considéré n ne génère aucun des cinq blocs suivants. De plus, continue de décroître exponentiellement en fonction du nombre de blocs générés par le nœud n pendant cette période. Une fois un score calculé pour chacun des nœuds actifs, chaque nœud mettant en œuvre l’algorithme de consensus sélectionne, comme nœud BP producteur du prochain bloc à ajouter à la chaîne de blocs, le nœud dont le score est le plus élevé. L’étape C20 sur la représente le calcul du score de chaque nœud et la sélection du nœud BP. Elle est suivie de la génération C21 d’un bloc à ajouter à la chaîne de blocs par un ou plusieurs nœuds candidats, et donc par la réception C10 par un nœud (ou chaque nœud du réseau) du ou des blocs générés. Pour l’ajout d’un nouveau bloc à la chaîne de blocs BC, lorsqu’un nœud reçoit au cours d’une étape C10 un bloc généré par un autre nœud n du réseau, il vérifie au cours d’une étape C11 que le bloc a été généré par le nœud BP sélectionné comme producteur du prochain bloc ajouté à la chaîne. Si tel n’est pas le cas (flèche N), alors le bloc est conservé C12 pour une itération ultérieure de l’algorithme. Lorsque le bloc provient effectivement (flèche Y) du nœud sélectionné comme producteur du prochain bloc BP ajouté à la chaîne, alors le nœud ayant reçu le bloc vérifie la validité du bloc C13, c’est-à-dire la validité de l’ensemble des transactions inscrites dans le bloc. Le nœud mettant en œuvre l’algorithme de consensus envoie ensuite C13 aux autres nœuds du réseau une notification indiquant le résultat de la vérification de la validité du bloc. Si le bloc est valide (C13a), la notification identifie donc ce bloc comme le prochain bloc à ajouter à la chaîne de blocs, puisqu’il a fait l’objet d’une sélection sur le nœud producteur de bloc puis d’une vérification sur la validité du bloc. Comme le même algorithme est mis en œuvre par tous les nœuds, le nœud ayant envoyé la notification reçoit aussi C14 des notifications équivalentes émises par les autres nœuds, identifiant un bloc vérifié comme valide, et correspondant à un nœud sélectionné comme producteur BP du prochain bloc à ajouter à la chaîne de blocs, comme prochain bloc à ajouter à la chaîne de blocs. Suite à la réception des notifications, le nœud ajoute C15 à sa copie respective de la chaîne de bloc le bloc qui a été identifié à la majorité des notifications reçues, c’est-à-dire qui a été identifié dans un nombre de notifications supérieur ou égal à N+1/2 où N est le nombre de nœuds du réseau mettant en œuvre l’algorithme de consensus. L’algorithme suppose donc un consensus sur l’identité du nœud producteur de bloc et sur le caractère valide du bloc. Si en revanche le bloc n’est pas valide (C13b), la notification envoyée aux autres nœuds du réseau identifie le bloc comme invalide. Le nœud peut recevoir de façon similaire des notifications C15 émises par les autres nœuds, identifiant un bloc comme invalide. Lorsqu’une majorité de notifications désigne un bloc comme invalide, alors le nœud supprime le nœud ayant produit le bloc de la liste des nœuds actifs C16. Puisque tous les nœuds mettent en œuvre le même algorithme de consensus, le nœud est ainsi supprimé de la liste des nœuds actifs de tous les nœuds. Le montant de dépôt Gp engagé par le nœud est alors transféré et réparti aux autres participants. Un nœud administrateur du réseau, disposant d’informations d’identifications du participant humain correspondant au nœud, peut également empêcher le participant de générer un nouveau nœud ultérieurement. Par exemple, la génération d’un nœud peut être conditionné A défaut d’une majorité de notifications identifiant un même bloc comme invalide (flèche N à la sortie du bloc C14), le protocole est réitéré C20 avec la génération C21 par un ou plusieurs nœuds 10 du réseau d’un nouveau bloc à ajouter à la chaîne de blocs, et la réception par les nœuds mettant en œuvre l’algorithme de consensus du ou des blocs (C10). L’algorithme proposé est sécurisé vis-à-vis de nombreux types d’attaques. Par exemple, un participant malveillant qui exploite un nœud et tente de générer un bloc invalide, c’est-à-dire qui comprend au moins une transaction invalide, verra son nœud immédiatement supprimé après vérification par les autres nœuds du réseau, et perdra en outre son montant de dépôt Gp. L’algorithme assure également une équité entre les nœuds grâce au taux de génération de nœud qui intervient dans le calcul du score d’un nœud, de sorte que même si un nœud a un solde de garantie élevé il n’a pas de certitude de parvenir à ajouter un nouveau bloc à la chaîne de bloc, le taux de génération de nœud étant favorable aux nœuds n’ayant pas encore ajouté de bloc à la chaîne de bloc. Des simulations comparées ont été mises en œuvre avec un cluster de huit terminaux informatiques dont les caractéristiques sont données dans le tableau 1 ci-après. Les algorithmes comparés ont été évalués par le programme Hyperledger Caliper d’évaluation des performances d’algorithmes de chaînes de blocs pour tester et comparer les performances de différentes solutions telles que la latence et le débit. Les configurations suivantes ont été adoptées : « Permissioning Smart Contract » de Consensys pour le module de gestion des droits, « Hyperledger Besu » pour le module de gestion des échanges et « Web3js » pour l’interaction des applications clientes avec le module de gestion des droits. Matériel informatique Nombre Intel® Core i7-6820HQ CPU@ 2.70GHz x 8; 16GiB 3 Intel® Core i7-8700 CPU@ 3.20GHz x 12; RAM 16GiB 1 Intel® Core i7-4710MQ CPU@ 2.50GHz x 8; 16GiB 1 Intel® Core i7-4800MQ CPU@ 2.70GHz x 8; 32GiB 1 Intel® Core i7-6500 CPU@ 2.50GHz x 4; 16GiB 1 Intel® Core i7-6700HQ CPU@ 2.60GHz x 8; 16GiB 1 La représente une comparaison de l’évolution de la latence de l’algorithme en fonction du nombre de nœuds, entre l’algorithme présenté ci-avant, et noté PoGR dans la figure, et deux autres protocoles : Ethach (algorithme basé sur une preuve de travail d’Ethereum) et Clique (algorithme basé sur une preuve d’autorité d’Ethereum). La latence désigne la différence de temps en secondes entre la soumission et l’achèvement d’une transaction, une transaction étant achevée une fois qu’elle a été vérifiée et enregistrée dans la chaîne de blocs. La représente une comparaison de l’évolution du débit de l’algorithme en fonction du nombre de nœuds, le débit étant évalué en un nombre de transactions enregistrées par seconde. On peut observer que l’algorithme présenté ci-avant dépasse les performances d’un algorithme basé sur une preuve de travail. De plus, en ajoutant des nœuds au réseau, les résultats montent que le débit de l’algorithme basé sur un preuve de travail augmente pour atteindre un pic mais diminue une fois ce pic atteint, contrairement au débit du protocole PoGR décrit dans la présente, qui reste stable puisque le protocole ne dépend pas du nombre de nœuds. De plus, comparé à un algorithme basé sur une preuve d’autorité, aucune différence de performance significative n’a pu être observée dans le cas d’un petit réseau. Cela est dû à la configuration expérimentale où tous les nœuds produisent des blocs dans une période fixe. Cependant, lorsque la taille du réseau dépasse un certain seuil (en l’occurrence 12 nœuds), le débit du protocole Clique commence à diminuer. Le débit du protocole selon l’invention reste meilleur que celui de Clique et d’Ethach. Cela est justifié par le fait que dans Clique, la probabilité de génération de fourches dans la chaîne de blocs augmente avec le nombre de valideurs, ce qui n’est pas le cas dans le protocole selon l’invention. Procédé de détermination d’un consensus au sein d’un ensemble de nœuds formant un réseau pair-à-pair de gestion d’une chaîne de blocs, pour l’ajout d’un nouveau bloc à la chaîne de blocs, le procédé étant mis en œuvre par un nœud du réseau pair-à-pair (11), le nœud étant mis en œuvre par un système informatique (10) comprenant au moins un processeur et une mémoire stockant une liste de nœuds actifs, une valeur de réputation actuelle associée à chaque nœud actif, et une copie respective de la chaîne de blocs, le procédé comprenant : Le calcul d’un score (C20) associé à chaque nœud actif de la liste, à partir de la valeur de réputation actuelle du nœud actif et d’un montant de dépôt (Gp) engagé par le nœud actif, La sélection du nœud producteur du prochain bloc, ce nœud présentant le score le plus élevé parmi les scores calculés, la réception (C10) d’au moins un bloc généré par un nœud candidat à l’ajout d’un nouveau bloc à la chaîne de blocs, et, lorsque le nœud candidat est le nœud sélectionné comme producteur du prochain bloc, la vérification de la validité du bloc, lorsque le bloc reçu est valide, l’envoi (C13) aux autres nœuds actifs du réseau d’une notification identifiant le bloc reçu comme prochain bloc de la chaîne de bloc, La réception (C14) d’une pluralité de notifications émises respectivement par les autres nœuds actifs du réseau, chaque notification identifiant un bloc sélectionné par un autre nœud actif du réseau et, L’ajout (C15) à la chaîne de blocs du bloc identifié par une majorité des notifications reçues. Procédé selon la revendication 1, comprenant, si le bloc généré est considéré invalide par une majorité des nœuds actifs du réseau, la suppression (C16) du nœud candidat ayant généré le bloc invalide de la liste des nœuds actifs. Procédé selon la revendication 2, comprenant en outre la réception d’une part du montant de dépôt déposé par le nœud supprimé. Procédé selon l’une des revendications précédentes, comprenant la suppression d’un nœud actif de la liste des nœuds actifs lorsque la réputation du nœud est inférieure à un seuil déterminé. Procédé selon l’une des revendications précédentes, dans lequel chaque nœud actif définit un montant de garantie (G B ) qui doit être compris entre des montants de garantie minimal et maximal déterminés, et le procédé comprend la suppression d’un nœud actif de la liste de nœuds actifs lorsque le montant de garantie (G B ) déposé par le noeud est inférieur au montant de garantie minimal. Procédé selon l’une des revendications précédentes, dans lequel chaque nœud actif définit un montant de garantie (G B ) qui doit être compris entre des montants de garantie minimal et maximal déterminés, et le score d’un nœud actif est calculé à partir : d’un ratio entre la valeur de garantie définie par le noeud et la valeur de garantie maximale (G B /G max ), et d’un ratio entre le montant de dépôt du nœud et la valeur de garantie (G P /G B ). Procédé selon la revendication précédente, dans lequel le score d’un nœud est une combinaison linéaire de la valeur de réputation actuelle, du ratio entre la valeur de garantie définie par le noeud et la valeur de garantie maximale, et du ratio entre le montant de dépôt du noeud et la valeur de garantie. Procédé selon l’une quelconque des revendications précédentes, dans lequel le calcul du score d’un nœud tient en outre compte d’un taux de génération de bloc qui décroît avec le nombre de blocs ajoutés à la chaîne de blocs par le nœud pendant une période déterminée. Procédé selon l’une des revendications précédentes, dans lequel chaque nœud est en outre configuré mettre en œuvre au moins une application d’interaction d’achat de produit ou de service hors de la chaîne de blocs, pour calculer une valeur de confiance associée à une interaction d’achat ayant eu lieu hors de la chaîne de blocs, chaque nœud étant en outre configuré pour calculer la valeur de réputation actuelle d’un nœud en fonction de : une valeur de réputation précédente, et la valeur de confiance associée à la dernière interaction d’achat ayant impliqué le nœud. Procédé selon la revendication précédente, dans lequel chaque nœud est configuré pour calculer la valeur de réputation actuelle d’un partipant par mise en œuvre d’un algorithme de type contrat intelligent. Produit programme d’ordinateur, comprenant des instructions de code pour la mise en œuvre du procédé selon l’une des revendications qui précède, quand il est exécuté par un ordinateur. Terminal informatique (10) comprenant au moins un processeur et une mémoire, et étant connectés à un ensemble d’autres terminaux informatiques pour former un réseau pair à pair (11) de gestion d’une chaîne de blocs, la mémoire du terminal informatique stockant une liste de nœuds dits actifs, une valeur de réputation actuelle associée à chaque nœud actif, et une copie respective de la chaîne de blocs, le terminal informatique étant configuré pour mettre en œuvre le procédé selon l’une des revendications 1 à 10. Système informatique distribué (1) comprenant un ensemble de terminaux informatiques (10) connectés entre eux de manière à former un réseau pair-à-pair (11), chaque terminal informatique comprenant au moins un processeur et une mémoire et formant un nœud dudit réseau, le système étant caractérisé en ce que chaque terminal est configuré pour mettre en œuvre le procédé selon l’une des revendications 1 à 10.