FR 3126831 A1 20230310 FR 2109204 A 20210903 Procédé de fourniture de service mis en œuvre par ordinateur dans une chaîne de blocs, nœud d’un réseau de chaîne de blocs et programme d’ordinateur correspondants. Le domaine de l'invention est celui de biens ou de services reposant sur une technologie de stockage décentralisé d’informations de type blockchain. Les infrastructures blockchain se sont enrichies de contrats intelligents. L’émergence de ces contrats intelligents ouvre de nouvelles applications aux blockchain, notamment dans le domaine de l’échange de services. Cependant, le manque de confidentialité des solutions reposant sur l’utilisation des contrats intelligent constitue un frein à leur développement. Afin de résoudre ce problème, l’invention s’appuie sur l’introduction d’un oracle capable de traiter des offres chiffrées sans avoir accès au contenu déchiffré de ces offres. Un oracle est un service tiers exécuté par plusieurs nœuds, interfaçant le réseau blockchain avec le monde. Un oracle peut remonter des informations externes vers un contrat intelligent, ou encore effectuer des calculs pour le compte du contrat intelligent afin diminuer les coûts de calcul de ce dernier. Les oracles sont des entités de confiances. . FIGURE 1 Procédé de fourniture de service mis en œuvre par ordinateur dans une chaîne de blocs, nœud d’un réseau de chaîne de blocs et programme d’ordinateur correspondants. Domaine de l'invention Le domaine de l'invention est celui des technologies mises en œuvre par ordinateur, et plus particulièrement, de l’échange de biens ou de services reposant sur une technologie de stockage décentralisé d’informations de type chaîne de blocs. Plus précisément, l'invention concerne un mécanisme, mis en œuvre par un ordinateur s’interfaçant avec au moins un nœud d’un réseau de chaîne de blocs exécutant un contrat intelligent (en anglais « smart contract »), pour la sélection et la mise en relation décentralisée d’un fournisseur de service et d’un client. Art antérieur et ses inconvénients La « blockchain », ou en français chaîne de blocs, est une technologie de stockage et de transmission d’informations transparente, sécurisée, et fonctionnant sans organe central de contrôle. Plus précisément, une chaîne de blocs est une base de données distribuée, qui contient l’historique de tous les échanges effectués entre ses utilisateurs depuis sa création : les informations envoyées par les utilisateurs et les échanges internes à la base de données sont vérifiés et groupés à intervalles de temps réguliers en blocs, formant ainsi une chaîne. L’ensemble est sécurisé par cryptographie. Plus précisément, les transactions effectuées entre les utilisateurs du réseau sont regroupées par blocs. Chaque bloc est validé par les nœuds du réseau, selon des techniques cryptographiques qui dépendent du type de blockchain . Une fois le bloc validé, il est horodaté et ajouté à la chaîne de blocs, à laquelle tous les utilisateurs ont accès. La transaction est alors visible pour l’ensemble des nœuds du réseau. Une fois ajouté à la chaîne, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l’authenticité et la sécurité du réseau. Il existe des chaînes de blocs publiques, ouvertes à tous, et des chaînes de blocs privées, ou de consortium, dont l’accès et l’utilisation sont limitées à un certain nombre d’acteurs définis à l’avance. Les premières chaînes de blocs ont trouvé des applications dans le domaine de la monnaie numérique, telle que le bitcoin, qui est un exemple de monnaie programmable. Cependant, le caractère décentralisé de la chaîne de blocs, couplé avec sa sécurité et sa transparence, laisse entrevoir des applications bien plus larges que le seul domaine monétaire. Les infrastructures de chaînes de blocs se sont ainsi récemment enrichies de contrats intelligents, ou « smart contracts », que l’on peut définir comme des programmes qui exécutent automatiquement les conditions et termes d’un contrat, sans nécessiter d’intervention humaine. En d’autres termes, un contrat intelligent est un programme informatique compilé qui porte un ensemble de caractéristiques lui permettant d’exécuter automatiquement et en autonomie au moins certaines des clauses spécifiques du contrat qu’il porte. L’émergence de ces contrats intelligents ouvre de nouvelles applications aux chaînes de blocs, notamment dans le domaine de l’échange de biens et de services. En effet, le recours aux places de marché (i.e. aux plateformes de mise en relation entre un fournisseur de service et un demandeur de service) pour la sous-traitance de tâches rencontre à ce jour un certain nombre de problématiques techniques, auxquelles l’infrastructure de chaîne de blocs, couplée à l’utilisation de contrats intelligents, pourrait aider à apporter des solutions efficaces : Parmi les problématiques techniques rencontrées, on peut citer par exemple : une problématique de manque de transparence dans la gestion des données et l’allocation des offres. En effet un seul acteur ne doit pas avoir le contrôle sur le protocole d’allocation des offres, et chaque fournisseur de service ayant soumis une offre doit pouvoir être considéré de la même manière lors de l’allocation des offres; un besoin de confidentialité : dans un contexte de compétition, les différentes offres de services proposées en réponse à un appel d’offres doivent être gardées secrètes vis à vis de l’ensemble des fournisseurs de service soumettant une offre de service. Par exemple, le prix, ou la capacité d’un camion, facteurs déterminants dans le choix d’allocation, ne peuvent être fournis de manière publique à une quelconque entité. Pour répondre à ces différentes problématiques, différentes solutions ont été envisagées. Cependant, même si ces différentes solutions de l’art antérieur sont intéressantes en ce qu’elles montrent l’intérêt de l’utilisation des chaînes de blocs et de contrats intelligents dans un contexte de mise en relation de fournisseurs de services et de clients, elles ne permettent pas de répondre à au moins certaines des problématiques mentionnées ci-avant et notamment la problématique de la confidentialité des offres. Il existe donc un besoin d'une technique de mise en relation de fournisseurs de services et de clients, ou de tâches et de ressources, qui ne présente pas l’ensemble des différents inconvénients de l’art antérieur, et qui vise à répondre à au moins certaines de ces différentes problématiques. L'invention répond à ce besoin en proposant un procédé mis en œuvre par un ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent, ledit procédé comprenant les étapes suivantes de : - réception d’offres de service chiffrées ; - déchiffrement des clés de chiffrement symétrique correspondant auxdites offres de services et enregistrées dans ladite chaîne de blocs, au moyen d’une clé de chiffrement privée dudit ordinateur, - déchiffrement desdites offres de service chiffrées au moyen desdites clés de chiffrement symétrique correspondantes, - identification d’au moins une offre de service satisfaisant au moins un critère de sélection de service, dite offre candidate, parmi les offres de service déchiffrées, - transmission, à destination du contrat intelligent, d’un identifiant d’au moins une offre candidate. Un tel procédé de traitement d’offres de service se caractérise par sa capacité à identifier au moins une offre de service d’un fournisseur de services répondant à un appel d’offres de manière autonome, objective, et confidentielle. Pour ce faire, le procédé décrit ci-dessus s’appuie sur la technologie des chaînes de blocs et sur l’introduction d’un oracle. Un oracle est un service tiers exécuté par un ou plusieurs nœuds, ci-après ordinateurs, interfaçant le réseau de chaîne de blocs avec le monde extérieur comme par exemple l’Internet. Un oracle peut remonter des informations externes vers un contrat intelligent, ou encore effectuer des calculs pour le compte du contrat intelligent afin de diminuer les coûts de calcul de ce dernier. Les oracles sont, par définition, des entités de confiances. Un tel procédé peut par exemple aider à diminuer les coûts de transaction en déléguant les tâches d’évaluation des offres de service à l’oracle. Cette délégation de l’évaluation des offres de service couplée à un double niveau de chiffrement des offres de service peut par exemple aider à garantir l’intégrité du processus d’évaluation des offres de service ainsi que la confidentialité de ces dernières puisqu’aucune entité n’a accès au contenu des offres de service. Ainsi, un tel procédé peut aider à offrir une solution intéressante à la problématique de manque de transparence souvent pointée du doigt dans le domaine de la gestion des données et l’allocation des offres. En effet, contrairement aux solutions de l’art antérieur dans lesquelles la mise en relation est souvent effectuée par des plateformes tierces, centralisées, souvent enclines à un manque de transparence vis à vis du stockage des informations des acteurs, la présente solution repose sur l’utilisation d’un contrat intelligent qui enregistre toutes ses actions dans la chaîne de bloc et sur l’utilisation d’un oracle qui n’accède pas au contenu sensible des offres traitées. La présente solution répond à au moins certains des besoins de confidentialité des parties grâce au chiffrement de leurs offres tout en offrant une gouvernance plus transparente grâce à la décentralisation offerte par la chaîne de blocs. Dans au moins certains modes de réalisation de la présente solution, l’identification d’au moins une offre candidate comprend, en outre, une détermination d’un vecteur binaire de comparaison des offres de service, une composante binaire dudit vecteur de comparaison des offres de service représentant un résultat d’une comparaison de deux offres de services entre elles. Le résultat des différentes comparaisons étant présenté sous forme binaire, cela contribue à maintenir la confidentialité des offres et de leur contenu. En effet, la seule information disponible est une information indiquant qui a remporté la comparaison contrairement aux approches de type « zero knowledge proof , » qui bien que préservant la confidentialité des offres de service sont limitées par le fait que la valeur des offres de services étudiées devient accessible sur le réseau de chaîne de blocs une fois les enchères clôturées. Dans certains cas de figure où le contenu des offres de service est chiffré selon un chiffrement homomorphe, le résultat binaire d’une comparaison de deux offres de service entre elles est obtenu en testant une égalité entre une offre de service testée et un extremum local déterminé en comparant l’offre de service testée et une autre offre de service. La présente solution peut aussi bien mettre en œuvre un chiffrement homomorphe partiel, c’est-à-dire qui ne s’applique qu’à certains types d’opérations mathématiques, qu’un chiffrement homomorphe total, c’est-à-dire qui s’applique à tout type d’opération mathématiques. Ainsi, en cryptographie, un chiffrement totalement homomorphe ( Fully Homomorphic Encryption ou FHE en anglais) est un chiffrement qui possède certaines caractéristiques algébriques qui le font commuter avec toutes les opérations mathématiques, c'est-à-dire que le déchiffrement du résultat par diverses opérations mathématiques, en particulier la multiplication et l’addition pour mettre en œuvre des fonctions comme la moyenne, le maximum ou le minimum par exemple, sur des données chiffrées donne le même résultat que cette opération mathématique sur des données non chiffrées ; cette propriété permet de confier des calculs à un agent externe, sans que les données ni les résultats ne soient accessibles à cet agent. Certains modes de réalisation peuvent en particulier mettre en œuvre un chiffrement homomorphe partiel s’appliquant notamment sur la multiplication et l’addition. Un chiffrement homomorphe peut permettre une évaluation aveugle des offres des nœuds d’un fournisseurs de services compétiteurs au sens où il n’est pas nécessaire d’avoir accès au contenu déchiffré des offres de service pour les évaluer. Cette technique peut permettre en effet d’effectuer des calculs sur des nombres chiffrés. Il devient donc possible de comparer des offres chiffrées dans un système d’allocation décentralisé géré par une chaîne de blocs. Ainsi, la présente solution ne présente pas les inconvénients d’approches de type enclaves de confiance. En effet, de telles enclaves de confiance consistent à proposer une enclave au sein de laquelle les offres de services soumises sont déchiffrées afin d’être évaluées et comparées. Le contrat intelligent fait le pont entre les nœuds d’un fournisseur de service, les nœuds de client ayant posté l’appel d’offres et l’enclave. Une limitation majeure de cette approche réside dans le fait qu’au sein de cette enclave il est possible d’accéder au contenu des offres de services en clair. Dans au moins certains modes de réalisation de la présente solution, une fois l’évaluation des offres de service dont le contenu est chiffré au moyen d’un chiffrement homomorphe effectuée, le procédé comprenant en outre : - une étape de transmission du vecteur binaire de comparaison des offres de service à destination d’un équipement en possession d’une clé de chiffrement homomorphe au moyen de laquelle le contenu des offres de service a été chiffré, - une étape de réception d’un vecteur binaire de comparaison d’offres de service déchiffré, - une étape de détermination d’un identifiant d’au moins une offre candidate. .Ainsi, tout en conservant la confidentialité des données, il est possible d’obtenir le résultat des différentes comparaisons effectuées. En effet, le contenu binaire du vecteur de comparaison donne des informations sur les offres maximales : la ième coordonnée du vecteur binaire de comparaison qui correspond à une offre maximale a une valeur non nulle. Dans au moins certains modes de réalisation de la présente solution, le procédé peut comprendre une transmission d’une clé de chiffrement publique correspondant à ladite clé publique à destination du contrat intelligent. L’invention concerne également un procédé mis en œuvre par un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs, ledit procédé comprenant : - transmission, à destination d’un ordinateur s’interfaçant avec ledit nœud, d’offres de service chiffrées selon des clés de chiffrement symétrique correspondantes enregistrées dans ladite chaîne de blocs, elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur, - réception d’un identifiant d’au moins une offre de service candidate, parmi les offres de service chiffrées transmises audit ordinateur, - sélection d’une offre de service parmi la dite au moins une offre candidate en fonction d’informations relatives à la dite au moins une offre candidate enregistrée dans ladite chaîne de blocs. Dans au moins certains modes de réalisation de la présente solution, en cas de pluralité d’offres candidates, l’offre sélectionnée est l’offre candidate présentant un horodatage d’enregistrement dans ladite chaîne de blocs le plus ancien. Ainsi, dans de tels modes de réalisation de la présente solution, lorsque plusieurs offres de services ont été identifiées comme répondant aux critères d’un appel d’offre, l’offre de service sélectionnée est celle qui a été soumise en premier. Dans au moins certains modes de réalisation de la présente solution, afin d’améliorer l’intégrité et la confidentialité du traitement des offres de service par l’oracle, une étape de permutation des offres de services est mise en œuvre par le contrat intelligent préalablement à la transmission des offres de service chiffrées à destination de l’oracle. Lorsque les offres de service ont été permutées en vue de leur traitement par l’oracle, le contrat intelligent met en œuvre, préalablement à l’étape de sélection d’une offre de service parmi les offres candidate, une étape de permutation inverse des offres de services afin de pouvoir identifier ces dernières. Ainsi, la présente solution, dans au moins certains de ses modes de réalisation, ne présente pas les inconvénients de l’approche de type « multi-party computing ». Pour rappel, une telle approche propose des comparaisons pair à pair : les fournisseurs de service proposant une offre de service comparent leurs offres de services chiffrées deux à deux, via des canaux privés. Ils révèlent ensuite le résultat de chacune des comparaisons au contrat intelligent grâce a des techniques de preuve à divulgation nulle de connaissance. Une limitation bien connue de cette approche « multi-party computing », et que ne présente pas la solution proposée par les inventeurs, réside dans le fait que le contrat intelligent est capable de reconstituer l’ordre des enchères (du plus au moins cher si les enchères sont sur un prix par exemple). Ce n’est pas le cas de l’oracle qui n’a pas accès à cette information. Ainsi, l’oracle évalue les offres de manière neutre. L’invention concerne également un ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent, ledit ordinateur comprenant au moins un processeur configuré pour : - recevoir des offres de service chiffrées ; - déchiffrer des clés de chiffrement symétrique correspondant auxdites offres de services et enregistrées dans ladite chaîne de blocs, au moyen d’une clé de chiffrement privée dudit ordinateur, - déchiffrer lesdites offres de service chiffrées au moyen desdites clés de chiffrement symétrique correspondantes, - identifier au moins une offre de service satisfaisant au moins un critère de sélection de service, dite offre candidate, parmi les offres de service déchiffrées, - transmettre, à destination du contrat intelligent, un identifiant d’au moins une offre candidate. L’invention a également pour objet un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs, ledit nœud comprenant au moins un processeur configuré pour : - transmettre, à destination d’un ordinateur s’interfaçant avec ledit nœud, des offres de service chiffrées selon des clés de chiffrement symétrique correspondantes enregistrées dans ladite chaîne de blocs, elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur, - recevoir un identifiant d’au moins une offre de service candidate, parmi les offres de service chiffrées transmises audit ordinateur, - sélectionner une offre de service parmi la dite au moins une offre candidate en fonction d’informations relatives à la dite au moins une offre candidate enregistrée dans ladite chaîne de blocs. L’invention concerne enfin des produits programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu’ils sont exécutés par un processeur. L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés selon l’invention tels que décrits ci-dessus. Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que les programmes d’ordinateur qu’il contient sont exécutables à distance. Le/les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés objets de l’invention précités. Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : : cette figure représente l’architecture d’un système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention, : cette figure représente un temps d’instanciation de la plateforme pour l’adapter par exemple au domaine d’application souhaité par l’utilisateur, : cette figure représente un diagramme séquentiel des étapes d’enregistrement et de traitement des ressources proposées par différents fournisseurs de biens ou de services, : cette figure représente un diagramme séquentiel des étapes de traitement des offres de services à transmettre cAES(cFHE(OS)) par l’oracle 1030 et le contrat intelligent SC 11, : cette figure représente un nœud du système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention, : cette figure représente un ordinateur du système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention. Description détaillée de modes de réalisation de l'invention Le principe général de l'invention repose sur l’utilisation d’une structure de chaînes de blocs, dans un réseau de communication, pour concevoir une plateforme de mise en relation de clients et de fournisseurs de service, aidant à une affectation décentralisée, transparente et/ou objective d’offres de service aux demandes de service formulées par les clients. Plus particulièrement, la présente solution repose sur la délégation de certaines opérations de traitement des offres de services soumises par des fournisseurs de service à un service tiers interfaçant la structure de la chaîne de blocs avec le monde extérieur comme par exemple l’Internet, afin de garantir la confidentialité et l’intégrité du processus de traitement des offres de service. Une telle plateforme correspond à un système de fourniture de service à base de chaîne de blocs décrit en référence à la . On présente désormais, en relation avec la , l’architecture d’un système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention. Un tel système peut comprendre un réseau de chaînes de blocs 100, également appelé par la suite réseau blockchain 100, comprenant une pluralité de nœuds N1 à N5 interconnectés les uns aux autres. La structure du nœud N1 est illustrée plus en détail. Chaque nœud N2 à N5 présente une architecture similaire à celle du nœud N1, bien que cela n’ait pas été détaillé, par souci de simplification, sur la . Dans la présente exemple illustré, le terme nœud se réfère exclusivement aux nœuds N1-N5 réseau de chaînes de blocs 100. Le terme nœud peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions. Plus généralement, un nœud Ni comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur, représentatif des instructions de code du contrat intelligent SC 11, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive avant d'être exécutées par le processeur de l'unité de traitement. Ainsi, dans certains modes de réalisation, le nœud N1 peut comprendre en outre : - une machine virtuelle Ethereum EVM 10, qui est l’environnement d’exécution des contrats intelligents dans Ethereum. On rappelle qu’Ethereum est un protocole d’échanges décentralisés permettant la création par les utilisateurs de contrats intelligents grâce à un langage Turing-complet ; - une zone de stockage de données STOR 12 ; - le code à octets (en anglais « bytecode ») du contrat intelligent SC 11, i.e. le code déterministe exécutable sur le réseau blockchain 100, dont les variables peuvent être stockées sur le réseau 100, et dont les fonctions peuvent être appelées. Le système dorsal (ou « backend ») de la plateforme de fourniture de service est ainsi décentralisé, et réside dans le contrat intelligent SC 11 implémentant un panel de fonctions nécessaires à la mise en relation de fournisseurs de service et de donneurs d’ordre. Comme on le verra plus en détail par la suite, ces fonctions qui peuvent être implémentées par le contrat intelligent SC 11 sont les suivantes : Register(), pour l’enregistrement de requêtes de services ou d’offres de service dans le réseau blockchain 100 ; Filter(), pour le filtrage des offres de service en fonction de critères de sélection de service listés dans une requête de service ; Sort(), pour le tri des offres de service répondant aux critères stipulés dans la requête de service ; generateContract(), pour l’établissement d’un contrat entre un fournisseur de service et un donneur d’ordre ; updateQoS(), pour l’enregistrement dans le réseau blockchain 100 d’une qualité de service correspondant à un service fourni. Les utilisateurs de la plateforme sont par exemple les nœuds fournisseurs de service 101 et des nœuds donneurs d’ordre, ou clients, 102. Ils peuvent interagir avec la plateforme via leur interface, ou frontend selon la terminologie anglaise. Des requêtes API (pour « Application Programming Interface », en français, interface de programmation d’application) permettent l’interaction entre les nœuds 101, 102 d’une part, et le contrat intelligent SC 11 déployé sur le réseau blockchain 100 d’autre part. Le dispositif client d’un donneur d’ordre 102 peut comprendre un module d’émission/réception RX/TX 1020, configuré pour émettre des requêtes de service à destination de la plateforme ainsi qu’une évaluation d’un service fourni, et pour recevoir des offres de service candidates, sélectionnées par la plateforme. Un tel dispositif client peut comprendre notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l’émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script). Le nœud fournisseur de service 101 comprend un module d’émission/réception RX/TX 1010, configuré pour émettre des offres de service à destination de la plateforme, et pour recevoir des contrats, établis par la plateforme lorsqu’une offre de service a été élue pour répondre à une requête de service d’un dispositif client 102. Un tel nœud fournisseur de service comprend notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l’émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script). Les transactions répertoriées et validées entre les nœuds fournisseurs de services 101 et les nœuds clients 102 peuvent être stockées sous forme de blocs dans les nœuds N1 à N5 de la chaîne de blocs 100. Des règles de consensus peuvent aider à limiter les nœuds malveillants, et à repérer les transactions invalidées. Des règles cryptographiques peuvent aider à assurer un pseudo-anonymat des transactions et des utilisateurs, et l’authenticité de l’historique de services des nœuds fournisseurs de services 101. Enfin, le système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention comprend en outre un oracle 1030. Un oracle 1030 est un service tiers exécuté par un ou plusieurs modules faisant appel à des API externes, ci-après ordinateurs, interfaçant avec le réseau de chaîne de blocs avec le monde extérieur comme par exemple l’Internet. Par souci de simplification, un seul ordinateur est représenté sur la . Un tel ordinateur 1030 peut comprendre : - au moins un processeur μPr capable d’exécuter au moins un programme pour la mise en œuvre du procédé selon un mode de réalisation de la présente solution ; - une zone de stockage de données STOR stockant ledit programme ainsi que diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur μPr ou encore des données intermédiaires de calculs effectués par le processeur μPr. La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser un nœud Ni et un oracle 1030, afin qu’ils effectuent les étapes du procédé détaillé ci-après, en relation avec les figures 2 à 6 (dans l’un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le nœud Ni ou l’oracle 1030 sont réalisés avec une machine de calcul reprogrammable, les programmes correspondants (c'est-à-dire les séquences d’instructions) pourront être stockés dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. Selon un mode de réalisation de l’invention, la plateforme de mise en relation se veut générique, en ce sens qu’elle ne s’inscrit pas dans un cas d’usage particulier, mais peut trouver des applications dans des domaines divers, tels que l’agriculture, la logistique maritime, la logistique de transport routier, les services à la personne, la production industrielle, l’énergie, etc. Comme illustré par la , il peut donc être nécessaire, avant que la plateforme ne devienne pleinement opérationnelle, de prévoir un temps d’instanciation de la plateforme pour l’adapter par exemple au domaine d’application souhaité. Notamment, l’ouverture du réseau de chaîne de bloc 100 peut être réglable à l’instanciation (de la chaîne de blocs publique aux chaînes de blocs permissionnées, et aux chaînes de blocs privées). Ainsi, cet utilisateur peut être un acteur privé dans le cas d’une chaîne de blocs privée, ou un consortium d’acteurs, dans le cas d’une chaîne de blocs de consortium. Par exemple, l’instanciation de la plateforme peut être réalisée par un consortium d’entreprises de transport, dans le cas d’une plateforme dédiée au transport de marchandises. La illustre ce temps d’instanciation par n une entité de régulation, que l’on pourrait noter en anglais « Field Authority » FA 20. Dans l’exemple donné ci-avant, cette entité de régulation FA 20 est le consortium d’entreprises de transport, qui se sont préalablement mises d’accord sur les paramètres d’instanciation de la plateforme. Ainsi, au cours d’une phase d’initialisation INIT 21 des règles de la plateforme, l’utilisateur mère FA 20 peut par exemple spécifier : - le corps de contrat légal attendu CONT 22, par exemple une lettre de voiture dans le cas d’un transport de marchandise. Ce corps de contrat CONT 22 est stocké dans le contrat intelligent SC 11. Il s’agit d’un contrat type, correspondant au type de fourniture de service auquel la plateforme va être dédiée, que l’on pourra noter par la suite C ; - l’ensemble P des critères de sélection objectifs CSEL 23 pouvant être choisis par les nœuds donneurs d’ordre 102 pour formuler une requête de service adressée à la plateforme. Les nœuds fournisseurs de service 101 devront renseigner ces différents critères de sélection lors de la proposition d’une ressource, ou offre de service, sur la plateforme de mise en relation. Par exemple, dans l’exemple d’une application logistique pour des entreprises de transport, les critères de sélection P peuvent comprendre : le poids du colis à livrer ; le volume du colis à livrer ; la zone géographique de prise en charge du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ; la zone géographique de livraison du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ; le type d’équipement utilisé pour la livraison ; le prix ; le temps qui s’écoule entre la prise en charge et la livraison du colis ; un identifiant du livreur (par exemple son IMSI pour « International Mobile Subscriber Identity »). Dans le mode de réalisation illustré, après finalisation de cette phase d’instanciation, la plateforme 100 est opérationnelle pour procéder à un enregistrement et un traitement des ressources proposées par différents nœuds fournisseurs de biens ou de services 101, comme illustré par le diagramme séquentiel de la . En effet, les nœuds fournisseurs de service 101 intéressés et autorisés par l’utilisateur mère FA 20 peuvent proposer leurs services à la plateforme, pour qu’ils soient référencés dans un catalogue de services enregistré dans la chaîne de blocs. Cet enregistrement des offres de service dans la chaîne de blocs peut aider à offrir une sécurisation forte pour les clients 102 potentiels, car elle leur garantit que les nœuds fournisseurs de service 101 ne puissent pas modifier les paramètres de l’offre de service qu’ils proposent (prix, délai, quantité, type d’équipement, etc.) après contractualisation. Ainsi, au cours d’une étape E1, une autorité de certification AutoCertif (différente ou pas de l’entité FA, selon les modes de réalisation) génère une première clé de chiffrement FHE permettant d’appliquer un chiffrement FHE partiellement homomorphe ou totalement homomorphe. Une telle clé de chiffrement FHE est unique et commune à l’ensemble des nœuds fournisseurs de service 101-1, 101-2 répondant à un appel d’offres donné. Un chiffrement homomorphe partiel est un chiffrement homomorphe qui ne s’applique qu’à certains types d’opérations mathématiques. Un chiffrement homomorphe total, quant à lui, s’applique à tout type d’opération mathématiques. Ainsi, un chiffrement totalement homomorphe ( Fully Homomorphic Encryption ou FHE en anglais) est un chiffrement qui possède certaines caractéristiques algébriques qui le font commuter avec toutes les opérations mathématiques, c'est-à-dire que le déchiffrement du résultat par diverses opérations mathématiques, en particulier la multiplication et l’addition pour mettre en œuvre des fonctions comme la moyenne, le maximum ou le minimum par exemple, sur des données chiffrées donne le même résultat que cette opération mathématique sur des données non chiffrées ; cette propriété permet de confier des calculs à un agent externe, sans que les données ni les résultats ne soient accessibles à cet agent. Dans la suite du document, il est fait l‘hypothèse par simplification que le chiffrement appliqué est un chiffrement homomorphe. Il est clair cependant que la présente demande peut également s’appliquer avec un chiffrement homomorphe partiel s’appliquant notamment sur la multiplication et l’addition. Une telle clé de chiffrement FHE est transmise aux différents nœuds fournisseurs de service 101-1, 101-2 au cours d’une étape E2. Parallèlement, l’oracle 1030 génère une paire de clés de chiffrement comprenant une clé de chiffrement publique RSAPub et une clé de chiffrement privée RSAPriv correspondante dans une étape E3. Ces clés de chiffrement RSAPub et RSAPub sont conforme à un chiffrement asymétrique tel qu’un chiffrement RSA pour « Rivest–Shamir–Adleman » du nom de ses créateurs. Au cours d’une étape E4, l’oracle 1030 transmet la clé de chiffrement publique RSAPub à. destination du contrat intelligent SC 11 qui la transmet à son tour aux nœuds fournisseurs de service 101-1, 101-2 dans une étape E5. Dans une étape E6, qui peut être préalable, concomitante ou postérieure à l’étape E5, chaque nœud fournisseur de service 101-1, 102-2, peut chiffrer une offre de service OS selon une méthode de chiffrement totalement homomorphe au moyen de la clé de chiffrement FHE. On obtient ainsi une première version chiffrée cFHE(OS) de l’offre de service OS. Une telle étape E6 peut être facultative. Chaque nœud fournisseurs de service 101-1, 101-2 peut chiffrer ensuite, dans une étape E7, la première version chiffrée cFHE(OS) de l’offre de service OS selon une méthode de chiffrement symétrique au moyen d’une clé de chiffrement symétrique AES propre à chaque nœud fournisseurs de service 101-1, 101-2. On obtient ainsi une deuxième version chiffrée cAES(cFHE(OS)) de l’offre de service OS, dite offre de service à transmettre à l’oracle cAES(cFHE(OS))Un exemple d’un tel chiffrement symétrique est le chiffrement AES pour « Advanced Encryption Standard ». Dans une étape E8, qui peut être préalable, concomitante ou postérieure à l’étape E6 et/ou à l’étape E7, chaque nœud fournisseur de service 101-1, 101-2 chiffre sa clé de chiffrement symétrique AES selon une méthode de chiffrement asymétrique au moyen de la clé de chiffrement publique RSAPub reçue au cours de l’étape E5. On obtient ainsi une version chiffrée RSAPub(AES) de la clé de chiffrement symétrique AES. Dans une étape E9, les nœuds fournisseurs de service 101-1, 101-2 adressent à la plateforme de mise en relation leurs offres de services à transmettre cAES(cFHE(OS)) accompagnées des versions chiffrées RSAPub(AES) de leurs clés de chiffrement symétriques AES respectives. Les offres de services à transmettre cAES(cFHE(OS)) et les versions chiffrées RSAPub(AES) de leurs clés de chiffrement symétriques AES respectives peuvent faire l’objet d’une transmission conjointe ou non. A réception, le contrat intelligent SC 11 peut enregistrer les offres reçues des nœuds fournisseurs de service 101-1 et 102-2, et les versions chiffrées des clés associées, dans la chaîne de blocs 100, au cours d’une étape E10. Une fois l’appel d’offres clôturé et l’ensemble des offres de services à transmettre enregistrées dans la chaîne de blocs 100, le contrat intelligent SC 11 délègue le traitement de ces offres de services à transmettre à l’oracle. Une telle délégation peut aider à réduire la charge de calcul dans le réseau blockchain et/ou le coût pour les nœuds fournisseurs de service 101-1, 101-2. Le traitement des offres de services à transmettre cAES(cFHE(OS)) par l’oracle 1030 et le contrat intelligent SC 11 est décrit plus en détails en référence à la . Dans une étape G1, le contrat intelligent SC 11 peut trier les profils des nœuds fournisseurs de services souhaitant soumettre une offre de service en fonction de données publiques enregistrées dans la chaîne de blocs. Le contrat intelligent SC 11 détermine par exemple les nœuds fournisseurs de services éligibles et leur envoie alors une requête leur demandant de fournir des données à caractère privé nécessaires pour discriminer (filtrer par exemple)leurs offres de services. Dans certains modes de réalisation, afin par exemple d’éviter que l’oracle 1030 puisse se servir de l’ordre de réception des offres de service à traiter et ainsi mettre en cause l’intégrité du processus de traitement, le contrat intelligent SC 11 peut permuter, dans une étape G2, l’ordre des offres de service préalablement à leur transmission à l’oracle 1030. Une telle étape G2 est optionnelle. Dans la suite du présent document, on fait l’hypothèse que les offres à transmettre cAES(cFHE(OS)) ont été permutées, ces offres à transmettre cAES(cFHE(OS)) ainsi permutées sont notées . Ainsi, l’offre OA correspond à l’offre à transmettre du nœud fournisseur de service 101-1 et l’offre OB correspond à l’offre à transmettre du nœud fournisseur de service 101-2. L’offre OA a par exemple été soumise en premier auprès du contrat intelligent SC 11 et est associée à au moins une donnée d’horodatage, telle qu’une date et un horaire de soumission, antérieur à la donnée d’horodatage associée à l’offre OB. Une fois les offres à transmettre permutées, le contrat intelligent SC 11 transmet ces offres à. destination de l’oracle 1030 dans une étape G3. Dans une première implémentation, les offres sont transmises avec des versions chiffrées RSAPub(AES) OA , RSAPub(AES) OB , des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres . Dans une deuxième implémentation, les offres et des versions chiffrées RSAPub(AES) OA , RSAPub(AES) OB , des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres .font l’objet de transmissions séparées. Dans cette deuxième implémentation, un premier n-upplet correspond à l’ensemble des offres et un second n-upplet correspond à l’ensemble versions chiffrées RSAPub(AES) OA , RSAPub(AES) OB , des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres . Le premier et le deuxième nu-upplet présentent par exemple tous deux le même ordonnancement afin de permettre l’association des offres et des versions chiffrées RSAPub(AES) OA , RSAPub(AES) OB , des clés de chiffrement symétriques AES correspondantes. A l’aide de la clé de chiffrement privée RSAPriv correspondant à la clé de chiffrement publique RSAPub, l’oracle 1030 peut déchiffrer les versions chiffrées RSAPub(AES) OA , RSAPub(AES) OB , des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres au cours d’une étape G4. On obtient alors des clés de chiffrement symétriques AES OA et AES OB correspondant à chacune des offres . Au cours d’une étape G5, l’oracle 1030 procède alors au déchiffrement des offres au moyen des clés de chiffrement symétriques AES OA et AES OB correspondantes. A l’issue de l’étape G5, on obtient les offres déchiffrées. Lorsque l’étape E6 a été mise en œuvre par les nœuds fournisseurs de service 101-1, 101-2, le contenu des offres ainsi déchiffrées correspond au contenu des offres de services OS chiffré au moyen de la clé FHE. Dans un tel cas de figure, l’oracle 1030 n’a accès qu’au contenu chiffré au moyen du chiffrement homomorphe des offres déchiffrées. L’oracle 1030 traite alors le contenu chiffré des offres déchiffrées préservant ainsi la confidentialité des offres de services OS. Une fois les offres déchiffrées, l’oracle 1030 peut identifier alors la ou les offres de service gagnante(s) parmi la liste des offres transmises par le contrat intelligent SC 11. Dans l’exemple qui nous concerne, la liste d’offres de service transmise est [ ], bien entendu cette liste peut comprendre plus de deux offres de service. Les indices respectifs associés aux offres de service afin de les identifier sont 0 et 1. Si l’oracle 1030 détermine que l’offre de service est l’offre gagnante, l’oracle 1030 renverra l’indice correspondant à cette offre , ici 0, au contrat intelligent SC 11. Si au contraire l’oracle 1030 détermine que l’offre de service est l’offre gagnante, l’oracle 1030 renverra l’indice correspondant à cette offre , ici 1. Pour cela, l’oracle peut par exemple mettre en œuvre deux algorithmes décrits ci-après. L’algorithme 1 peut par exemple être mis en œuvre pour générer un vecteur de comparaison des offres dit vecteur des argmax B. l’algorithme 2 peut par exemple être mis en œuvre pour déterminer la valeur d’une variable t utilisée dans l’algorithme 1 présenté en annexe. Dans une étape G6, l’oracle 1030 initialise l’algorithme 1.Dans l’exemple décrit, le contenu o des offres est chiffré au moyen de la clé FHE. Pour cela, l’oracle 1030 utilise les variables suivantes : la liste C des offres, Ci représente l’élément i du vecteur d’offres C (ci= C[i]). Dans l’algorithme 1 « != » signifie « ». L’oracle 1030 compare alors les différentes offres deux à deux. Ainsi, dans une étape G7, correspondant aux lignes 6 à 8 de l’algorithme 1, l’oracle 1030 détermine un maximum local entre une première offre C[i] et une deuxième offre . Une fois obtenue la valeur m correspondant au maximum local, l’oracle 1030 peut par exemple mettre en œuvre l’algorithme 2 afin de déterminer la valeur de la variable b à appliquer. Un tel algorithme 2 est également présenté en annexe. La fonction « testEquality » repose sur le petit théorème de Fermat. Pour deux variables chiffrées A et B, le petit théorème de Fermat indique que lorsque A!=B (tout comme dans l’algorithme 1, ici aussi « != » signifie « ».), alors (A-B)p-1 est congru à 1 mod p, donc t = 1- (A-B)p-1 vaut 0. Selon le petit théorème de Fermat, lorsque A=B, alors (A-B) vaut 0, t se voit affecter la valeur 1. Dans notre cas d’usage, on multiplie alors t par une variable c n correspondant au chiffré d’un entier naturel n où n est supérieur à 1 afin de mieux faire la différence entre 0 et 1. En effet, les calculs effectués sur des données chiffrées au moyen d’un chiffrement homomorphe tel qu’un chiffrement du type FHE engendrent du bruit lié aux techniques de chiffrement. Ainsi, l’oracle peut appliquer l’algorithme 2 aux variables C[i] et m . Si la variable C[i] est supérieure au maximum local m alors la variable b de l'algorithme 1 qui correspond à la variable t de l’algorithme 2prend la valeur c n . Si au contraire la variable C[i] est inférieure au maximum local m alors la variable b prend la valeur c 0 (le chiffré de 0). Le résultat de l’opération B[i]+ b est alors mémorisé comme étant une coordonnée du vecteur argmax B. L’étape G7 peut être exécutée jusqu’à ce que toutes les offres de services reçues aient été comparées deux à deux. A chaque occurrence, une valeur B [i]+b peut être mémorisée comme étant une coordonnée du vecteur argmax B. Un tel vecteur argmax B peut comprendre autant de coordonnées que le nombre de comparaisons d’offres à effectuer. Les coordonnées du vecteur argmax B ne peuvent prendre que deux valeurs : 0 ou B [i]+b . Dans un cas de figure où le contenu des offres est chiffré selon un chiffrement homomorphe, l’oracle 1030 peut transmettre, dans une étape G8, le vecteur argmax B obtenu à destination de l’autorité de certification AutoCertif ayant généré la clé de chiffrement FHE afin que l’autorité de certification AutoCertif puisse procéder au déchiffrement du vecteur argmax B. Une fois le vecteur argmax B déchiffré au moyen de la clé de chiffrement FHE, l’autorité de certification AutoCertif peut transmettre le vecteur argmax B déchiffré à l’oracle 1030 dans une étape G9. Une fois qu’il a accès à un vecteur argmax B déchiffré, l’oracle 1030 est en capacité de fournir au contrat intelligent SC 11 un identifiant d’une ou plusieurs offres gagnantes. Pour cela, l’oracle transmet par exemple le vecteur argmax déchiffré à destination du contrat intelligent SC 11 dans une étape G10. Si le contrat intelligent SC 11 a permuté les offres avant leur transmission à l’oracle 1030, alors il applique, dans une étape G11, une permutation inverse au vecteur argmax B afin de pouvoir identifier correctement la ou les offres de service gagnantes. Dans une étape G12, le contrat intelligent SC 11 peut déterminer le nombre d’offres de service gagnantes. Pour cela, le contrat intelligent SC 11 détermine par exemple si le vecteur argmax B comprend un ou plusieurs maxima globaux. Si le vecteur argmax B comprend un seul maximum global (e.g., B=[val_max, val_min, 0]), cela signifie qu’il n’y a qu’une seule offre de service gagnante. Le contrat intelligent SC 11 peut en informer alors le nœud fournisseur de service émetteur de l’offre de service gagnante et enregistrer le résultat dans la chaîne de blocs. Si le vecteur argmax B comprend plusieurs maxima globaux identiques (e.g., B=[val_max, 0, val_max]), cela signifie qu’il y a plusieurs offres de service gagnantes. Le contrat intelligent SC 11, peut sélectionner alors une offre de service parmi ces offres de service candidates, par exemple l’offre de service associée à une donnée d’horodatage la plus ancienne parmi l’ensembles des données d’horodatage associées aux différentes offres de service candidates. Le contrat intelligent SC 11 peut informer ensuite au moins certains des différents nœuds fournisseurs de service émetteurs des offres de service candidates de l’issue de l’appel d’offre à savoir le déclin de l’offre, ou l’acceptation de l’offre. Tous ces échanges sont enregistrés par le contrat intelligent SC 11 dans la chaîne de blocs. Dans un exemple de cas d’usage de la présente solution, il est supposé que trois sociétés de livraison, LA, LB et LC souhaitent participer à un appel d’offre. Les trois sociétés LA, LB et LC s’inscrivent à l’appel d’offre en amont via le contrat intelligent SC 11. Dans le cadre de cet appel d’offre, l’oracle 1030 génère un couple de cle privée RSAPriv/ clé publique RSAPub et met la clé publique RSAPub à disposition du contrat intelligent SC 11. Un demandeur de service demande un recrutement de livreur au contrat intelligent. Il souhaite une livraison longue distance de la ville v1 à la ville v2, avec un camion ayant une capacité minimale de 33m 3 . Il stipule la durée de l’appel d’offre égale à T=72h. Durant cette période T le contrat intelligent SC 11 trie les profils des sociétés de livraison LA, LB et LC sur la base de données publiques enregistrées telles que la disponibilité et la localisation. Le contrat intelligent SC 11 détermine que seules les sociétés LA et LB sont éligibles. Le contrat intelligent SC 11 envoie alors une requête aux sociétés LA et LB leur demandant de fournir des données à caractère privé nécessaires pour discriminer leurs offres telles que, par exemple, le prix, et la capacité disponible. Le contrat intelligent SC 11 envoie en parallèle une liste des adresses dans le réseau blockchain des sociétés LA et LB à l’autorité de certification AutoCertif. En réponse à cette requête, l’autorité de certification AutoCertif transmet la clé de chiffrement FHE aux sociétés LA et LB via le réseau blockchain. Par la suite, chacune des sociétés LA et LB demande au contrat intelligent SC 11 la cle publique RSAPub afin de chiffrer son offre de service. Puis, chacune des sociétés LA et LB chiffre chacun des éléments de son offre : le prix et la capacité, en appliquant séquentiellement le chiffrement homomorphe au moyen de la clé de chiffrement FHE puis le chiffrement symétrique au moyen de la clé de chiffrement AES. Les sociétés LA et LB chiffrent alors leur clé de chiffrement symétrique AES au moyen de la clé RSAPub. Les offres ainsi chiffrées et les clés de chiffrement AES chiffrée sont transmises au contrat intelligent SC 11 qui les enregistre dans la chaine de blocs. Le contrat intelligent SC 11 permute alors les offres chiffrées pour conserver la confidentialité de l’ordre des soumissions: il inverse donc les offres OA de la société LA et OB de la société LB. Il transmet ensuite les offres permutées à l’oracle 1030 et lui demande une comparaison des offres OA et OB. L’oracle 1030 utilise la cle privée RSAPriv pour déchiffrer chacun des éléments composant les offres reçues. Pour l’offre , on obtient [C(capacitéLA), C(prixLA)] où C=Chiffré. L’oracle 1030 calcule la moyenne chiffrée de : = (C(capacitéLA) + C(prixLA))/2. Il fait de même pour , puis applique l’algorithme de comparaison entre et . Supposons > , alors le vecteur argmax B retourné par l’oracle 1030 est [C(10),C(0)]. L’oracle 1030 envoie une demande de déchiffrement du vecteur argmax B à l’autorité de certification AutoCertif. L’autorité de certification AutoCertif renvoie alors à l’oracle 1030 un vecteur argmax B déchiffré, i.e., [10,0]. L’oracle 1030 retourne ce vecteur argmax déchiffré au contrat intelligent SC 11. Le contrat intelligent SC 11 applique une permutation inverse sur le vecteur argmax B déchiffré et identifie l’offre de la société LB comme étant l’offre gagnante. Le contrat intelligent SC 11 génère alors un contrat entre la société LB et le demandeur de service. En parallèle, il envoie une notification à la société LA pour la prévenir que son offre n’est pas retenue. Tous ces échanges sont enregistrés dans la chaîne de blocs. La représente un nœud N1-N5 appartenant à un réseau de chaîne de blocs apte à mettre en œuvre certaines étapes de la solution précédemment décrite. Un nœud N1-N5 peut comprendre au moins un processeur matériel 501, une unité de stockage 502 correspondant à la mémoire STOR 12 de la , une première interface 503, et au moins une deuxième interface de réseau 504 et une machine virtuelle Ethereum EVM 10 qui sont connectés entre eux au travers d’un bus 505. Bien entendu, les éléments constitutifs du nœud N1-N5 peuvent être connectés au moyen d’une connexion autre qu’un bus. Le processeur 501 commande les opérations du nœud N1-N5. L'unité de stockage 502 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 501, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 501, des données intermédiaires de calculs effectués par le processeur 501, etc. Le processeur 501 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 801 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci. L'unité de stockage 502 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 502 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture. L'interface 503 fournit une interface entre le nœud N1-N5 et un autre nœud N1-N5 du réseau de chaîne de blocs. L’interface réseau 504 fournit quant à elle une connexion entre le nœud N1-N5 et l’oracle 1030. La représente un ordinateur ou oracle 1030 apte à mettre en œuvre certaines étapes de la solution précédemment décrite. Un oracle 1030 peut comprendre au moins un processeur matériel 601 correspondant au processeur μPr de la , une unité de stockage 602 correspondant à la mémoire STOR de la , une première interface 603, et au moins une deuxième interface de réseau 604 qui sont connectés entre eux au travers d’un bus 605. Bien entendu, les éléments constitutifs de l’oracle 1030 peuvent être connectés au moyen d’une connexion autre qu’un bus. Le processeur 601 commande les opérations de l’oracle 1030. L'unité de stockage 602 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 601, et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 601, des données intermédiaires de calculs effectués par le processeur 601, etc. Le processeur 601 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 601 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci. L'unité de stockage 602 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 602 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi-conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto-optiques chargés dans une unité de lecture et d'écriture. L'interface 603 fournit une interface entre l’oracle 1030 et un autre ordinateur jouant également un rôle d’oracle. L’interface réseau 604 fournit quant à elle une connexion entre l’oracle 1030 et au moins un nœud N1_N5 du réseau de chaîne de blocs. ANNEXE Exemple d’algorithme 1 Exemple d’algorithme 2 Procédé mis en œuvre par un ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent, ledit procédé comprenant les étapes suivantes de : - réception d’offres de service chiffrées ; - déchiffrement des clés de chiffrement symétrique correspondant auxdites offres de services et enregistrées dans ladite chaîne de blocs, au moyen d’une clé de chiffrement privée dudit ordinateur, - déchiffrement desdites offres de service chiffrées au moyen desdites clés de chiffrement symétrique correspondantes, - identification d’au moins une offre de service satisfaisant au moins un critère de sélection de service, dite offre candidate, parmi les offres de service déchiffrées, - transmission, à destination du contrat intelligent, d’un identifiant d’au moins une offre candidate. Procédé de traitement d’offres de service selon la revendication 1 dans lequel l’identification d’au moins une offre candidate comprend, en outre, une détermination d’un vecteur binaire de comparaison des offres de service, une composante binaire dudit vecteur de comparaison des offres de service représentant un résultat d’une comparaison de deux offres de services entre elles. Procédé de traitement d’offres de service selon la revendication 2, le contenu des offres de service étant chiffré selon un chiffrement homomorphe, le résultat binaire d’une comparaison de deux offres de service entre elles est obtenu en testant une égalité entre une offre de service testée et un extremum local déterminé en comparant l’offre de service testée et une autre offre de service. Procédé de traitement d’offres de service selon la revendication 3 comprenant en outre : - une étape de transmission du vecteur binaire de comparaison des offres de service à destination d’un équipement en possession d’une clé de chiffrement homomorphe au moyen de laquelle le contenu des offres de service a été chiffré, - une étape de réception d’un vecteur binaire de comparaison d’offres de service déchiffré, - une étape de détermination d’un identifiant d’au moins une offre candidate. Procédé de traitement d’offres de service selon la revendication 1 comprenant, préalablement à la réception des offres de service chiffrées, une transmission d’une clé de chiffrement publique correspondant à ladite clé publique à destination du contrat intelligent. Procédé mis en œuvre par un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs, ledit procédé comprenant : - transmission, à destination d’un ordinateur s’interfaçant avec ledit nœud, d’offres de service chiffrées selon des clés de chiffrement symétrique correspondantes enregistrées dans ladite chaîne de blocs, elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur, - réception d’un identifiant d’au moins une offre de service candidate, parmi les offres de service chiffrées transmises audit ordinateur, - sélection d’une offre de service parmi la dite au moins une offre candidate en fonction d’informations relatives à la dite au moins une offre candidate enregistrée dans ladite chaîne de blocs. Procédé de fourniture de service selon la revendication 6 dans lequel l’offre sélectionnée est l’offre candidate présentant un horodatage d’enregistrement dans ladite chaîne de blocs le plus ancien. Procédé de fourniture de service selon la revendication 6 comprenant préalablement à la transmission des offres de service chiffrées à destination dudit ordinateur, une permutation des offres de services, et préalablement à la sélection d’une offre de service parmi la dite au moins une offre candidate, une permutation inverse des offres de services. Ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent, ledit ordinateur comprenant au moins un processeur configuré pour : - recevoir des offres de service chiffrées ; - déchiffrer des clés de chiffrement symétrique correspondant auxdites offres de services et enregistrées dans ladite chaîne de blocs, au moyen d’une clé de chiffrement privée dudit ordinateur,, - déchiffrer lesdites offres de service chiffrées au moyen desdites clés de chiffrement symétrique correspondantes, - identifier au moins une offre de service satisfaisant au moins un critère de sélection de service, dite offre candidate, parmi les offres de service déchiffrées, - transmettre, à destination du contrat intelligent, un identifiant d’au moins une offre candidate. Nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs, ledit nœud comprenant au moins un processeur configuré pour : - transmettre, à destination d’un ordinateur s’interfaçant avec ledit nœud, des offres de service chiffrées selon des clés de chiffrement symétrique correspondantes enregistrées dans ladite chaîne de blocs, elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur,, - recevoir un identifiant d’au moins une offre de service candidate, parmi les offres de service chiffrées transmises audit ordinateur, - sélectionner une offre de service parmi la dite au moins une offre candidate en fonction d’informations relatives à la dite au moins une offre candidate enregistrée dans ladite chaîne de blocs.