FR3074322A1 - Plate-forme de tracabilite securisee de donnees - Google Patents
Plate-forme de tracabilite securisee de donnees Download PDFInfo
- Publication number
- FR3074322A1 FR3074322A1 FR1761423A FR1761423A FR3074322A1 FR 3074322 A1 FR3074322 A1 FR 3074322A1 FR 1761423 A FR1761423 A FR 1761423A FR 1761423 A FR1761423 A FR 1761423A FR 3074322 A1 FR3074322 A1 FR 3074322A1
- Authority
- FR
- France
- Prior art keywords
- data
- block
- service
- transaction
- agent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 50
- 230000008569 process Effects 0.000 claims abstract description 49
- 238000005516 engineering process Methods 0.000 claims abstract description 14
- 238000012544 monitoring process Methods 0.000 claims abstract description 12
- 238000010200 validation analysis Methods 0.000 claims description 34
- 238000004364 calculation method Methods 0.000 claims description 26
- 238000013499 data model Methods 0.000 claims description 24
- 238000007726 management method Methods 0.000 claims description 24
- 238000012545 processing Methods 0.000 claims description 19
- 230000000694 effects Effects 0.000 claims description 15
- 238000010801 machine learning Methods 0.000 claims description 15
- 230000009471 action Effects 0.000 claims description 14
- 238000013515 script Methods 0.000 claims description 11
- 238000004422 calculation algorithm Methods 0.000 claims description 8
- 238000013459 approach Methods 0.000 claims description 7
- 238000013475 authorization Methods 0.000 claims description 7
- 238000013461 design Methods 0.000 claims description 7
- 238000012546 transfer Methods 0.000 claims description 7
- 125000000174 L-prolyl group Chemical group [H]N1C([H])([H])C([H])([H])C([H])([H])[C@@]1([H])C(*)=O 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 5
- 238000004891 communication Methods 0.000 claims description 5
- 238000007405 data analysis Methods 0.000 claims description 5
- 238000013523 data management Methods 0.000 claims description 5
- 238000004458 analytical method Methods 0.000 claims description 4
- 238000000151 deposition Methods 0.000 claims description 4
- 230000002452 interceptive effect Effects 0.000 claims description 4
- 230000003068 static effect Effects 0.000 claims description 4
- 238000012937 correction Methods 0.000 claims description 3
- 238000013500 data storage Methods 0.000 claims description 3
- 238000011156 evaluation Methods 0.000 claims description 3
- 230000001186 cumulative effect Effects 0.000 claims description 2
- 238000013497 data interchange Methods 0.000 claims 1
- 238000012423 maintenance Methods 0.000 claims 1
- 230000000875 corresponding effect Effects 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 8
- 238000005065 mining Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000009466 transformation Effects 0.000 description 4
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 230000002596 correlated effect Effects 0.000 description 2
- 238000012517 data analytics Methods 0.000 description 2
- 238000013502 data validation Methods 0.000 description 2
- 230000009849 deactivation Effects 0.000 description 2
- 230000008021 deposition Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 238000012549 training Methods 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- 108091028043 Nucleic acid sequence Proteins 0.000 description 1
- 238000001994 activation Methods 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013481 data capture Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
L'invention concerne une infrastructure technique distribuée destinée à un système de plate-forme de traçabilité de données basé sur des agents (DTP) comprenant au moins un serveur de base de métadonnées à architecture en couches et à ressources de calcul, un serveur de surveillance de la qualité des données, un serveur de gestion pour un service d'approvisionnement en données (DPS), et une machine d'interrogation automatique, caractérisée en ce que la base de données est utilisée pour stocker des données et conserver des preuves sécurisées de l'échange de données, de la propriété des données et du transfert de propriété des données dans des objets de données (DO) afin de permettre à un utilisateur d'accéder à des ensembles de données (DO1,...,DOn) fournis par d'autres utilisateurs, et de proposer un ensemble de données accessible par un autre utilisateur, et dans laquelle la plate-forme de traçabilité de données adapte la technologie de chaîne de blocs pour le suivi sécurisé de la propriété d'un ensemble de données (DO) à stocker dans la base de données, et met en place un processus de consensus par fédération, au cours duquel un module de vote décide de la validité d'un bloc afin de stocker le bloc dans la base de données.
Description
DOMAINE DE L’INVENTION
La présente invention concerne le domaine de la gestion des données, et plus précisément une plate-forme de sécurisation et de suivi de l’échange de données.
CONTEXTE DE L’INVENTION
La prolifération intensive de la technologie numérique engendre la création d’une énorme quantité de données. Chaque donnée possède une certaine valeur inhérente, ce qui fait des données un bien qui fait l’objet de transactions.
Les publicités personnalisées sur la base de profils d’utilisateurs constituent un exemple. Par exemple, sur une plate-forme commerciale d’analyse de données, des « fournisseurs » peuvent proposer des modèles de calcul d’apprentissage machine (ML), des ensembles de données d’ apprentissage et des modèles d’apprentissage machine « prêts à utiliser », et les « consommateurs » achètent ces données à des fins personnelles. Les modèles d’apprentissage machine et les données d’apprentisssage présentent une certaine valeur inhérente. Les modèles d’apprentissage machine entraînés créent une certaine valeur en combinant les données existantes d’autres fournisseurs, c’est-à-dire en appliquant des ensembles de données d’apprentissage pendant une durée significative.
Par exemple, les fournisseurs de données doivent être récompensés si leurs données ont été utilisées pour créer un nouvel ensemble de données qui est vendu sur la plate-forme, comme les modèles d’apprentissage machine formés. Cependant, la simple réutilisation des données constitue une menace pour la propriété intellectuelle. Un utilisateur malhonnête peut, par exemple, légèrement modifier l’ensemble de données (contournant ainsi les contrôles d’intégrité classiques) et proposer le « nouvel » ensemble de données par lui-même.
DESCRIPTION GENERALE DE L’INVENTION
La présente invention a pour but de pallier certains inconvénients de l’art antérieur en proposant un moyen de sécurisation et de gestion de l’échange de données.
Cet but est atteint par une infrastructure technique distribuée destinée à un système de plate-forme de traçabilité de données basé sur des agents (DTP) comprenant au moins un serveur de base de métadonnées à architecture en couches et à ressources de calcul, un serveur de surveillance de la qualité des données, un serveur de gestion pour un service d’approvisionnement en données (DPS), et une machine d’interrogation automatique, caractérisée en ce que la base de données est utilisée pour stocker des données et conserver des preuves sécurisées de l’échange de données, de la propriété des données et du transfert de propriété des données dans des objets de données (DO) afin de permettre à un utilisateur d’accéder à des ensembles de données (DOi„ .,DOn) fournis par d’autres utilisateurs, et de proposer un ensemble de données accessible par un autre utilisateur, et dans laquelle la plate-forme de traçabilité de données adapte la technologie de chaîne de blocs pour le suivi sécurisé de la propriété d’un ensemble de données (DO) à stocker dans la base de données, et met en place un processus de consensus par fédération (FC), au cours duquel un module de vote décide de la validité d’un bloc afin de stocker le bloc dans la base de données.
Selon une autre particularité, le module de vote de chaque agent de la plate-forme de traçabilité de données d’une « fédération DTP », pendant le consensus par fédération (FC), propose un vote individuel sur la validité, et le total cumulé des votes détermine la validité du bloc, au moins la taille et les participants à la fédération DTP, et le seuil de validité étant paramétrables.
Selon une autre particularité, la technologie de chaîne de blocs est adaptée pour comprendre un modèle prospectif permettant à un prestataire de service de fournir des informations orientées calcul, en stockant au moins les assertions d’une approche d’accès et de contrôle (AC) dans le cadre d’une transaction, contenant ainsi des informations purement prospectives sur le calcul qui spécifie la logique réelle exécutée.
Selon une autre particularité, la technologie de chaîne de blocs est adaptée pour comprendre un modèle rétrospectif en tirant profit de la fonctionnalité de stockage et de consignation des données afin de maintenir les informations de traitement.
Selon une autre particularité, la technologie de chaîne de blocs est adaptée pour comprendre un modèle pro-/rétrospectif mixte avec la fonctionnalité d’un système de gestion de processus distribué (WMS), les informations pro- et rétrospectives étant combinées afin de permettre le suivi du calcul et d’évaluer la fiabilité du résultat du calcul.
Selon une autre particularité, l’infrastructure technique distribuée comprend au moins une infrastructure de clés publiques (PKI) qui permet d’utiliser des outils cryptographiques asymétriques pour sécuriser les transactions d’un ensemble de données ou d’objets de données (DO) et suivre la propriété d’un ensemble de données.
Selon une autre particularité, une clé publique et privée unique est générée pour la création d’un compte d’agent, afin de permettre audit agent d’utiliser au moins un outil cryptographique asymétrique de l’infrastructure de clés publiques.
Selon une autre particularité, ladite clé publique et privée unique permet également audit agent d’agir comme une entité DTP active, qui est active dans une machine qui exécute une instance DTP et qui est responsable des actions de l’instance à l’aide des signatures numériques de toutes les communications qui utilisent ladite clé privée.
Selon une autre particularité, l’infrastructure technique distribuée comprend au moins un système d’accès et de contrôle (AC) qui maintient l’accès aux services disponibles et/ou qui contrôlent la création de services frauduleux au sein de la plate-forme, tandis que les droits d’accès sont spécifiés par chaque prestataire de service qui crée une preuve de droit d’accès pour l’utilisateur concerné à l’aide des fonctionnalités de gestion des données de la chaîne de blocs.
Selon une autre particularité, le système AC permet une traçabilité inter- et intra-service si des assertions appropriées sont fournies par un prestataire de service.
Selon une autre particularité, le prestataire de service spécifie, pour un service numérique consommable, à l’aide d’une interface interactive basée sur un navigateur Web, des métadonnées de provenance qui permettent une traçabilité inter-service et intra-service, et au moins des détails à propos du calcul effectué et des objets de données (DO)de sortie prévus.
Selon une autre particularité, la base de données est distribuée avec des performances de correction linéaire, optimisées pour les opérations d’écriture et conçues pour gérer les charges de travail élevées et les fonctionnalités en parallèle.
Selon une autre particularité, la base de données est Apache Cassandra.
Selon une autre particularité, la base de données comprend au moins une couche de stockage comprenant au moins un stockage de groupes de transactions, un stockage de file d’attente de blocs, un stockage de chaîne de blocs, un stockage de blocs invalides, et un lac de données.
Selon une autre particularité, ladite couche de stockage comprend au moins un ensemble de modules : un module de groupe de transactions destiné à traiter les transactions qui entrent dans le stockage de groupes de transactions et vont être stockées dans les blocs de la file d’attente de blocs, un module de file d’attente de blocs destiné à traiter les blocs qui ne sont pas encore validés et qui sont soumis au consensus pour la validation des blocs distribués, un module de chaîne à blocs destiné à traiter les blocs validés, un module de dépôt de blocs invalides destiné à traiter les blocs qui ont été validés comme étant invalides pendant la validation de blocs par consensus par un module de vote de blocs, un module de gestion de stockage destiné à stocker et à traiter des entités supplémentaires qui font partie des blocs et des transactions, notamment les votes qui sont requis pour le vote de blocs, des statuts de blocs utilisés pour persister le résultat d’un vote de validité de blocs, et d’éléments de lac de données (DLE)extraits pour améliorer les performances en raison de leur taille de données variable.
Selon une autre particularité, l’exécution du module de gestion du stockage permet au stockage de groupes de transactions au moins de recevoir les transactions brutes entrantes, de vérifier les transactions à l’aide d’un algorithme de validation approfondie, d’affecter les transactions entrantes à un agent DTP par le biais d’une stratégie de sélection, et d’ajouter lesdites transactions vérifiées au stockage de groupes de transactions.
Selon une autre particularité, la validation approfondie (DV) permet de valider par la suite des données arbitraires par toutes les couches architecturales DTP, en validant ainsi les données éventuellement imbriquées en profondeur, pendant que la logique de validation est fournie par le biais de « validateurs » qui ont exécuté la validation sous une forme sémantiquement capsulée optimisée pour une exécution simultanée.
Selon une autre particularité, le module de groupes de transactions identifie les transactions vérifiées avec une marge importante à l’aide de l’agent DTP assigné qui est responsable de l’exécution du module de groupes de transactions, crée des blocs en utilisant l’autorisation des transactions, transmet les blocs à stocker dans la file d’attente de blocs, et supprime les transactions utilisées du stockage de groupes de transactions.
Selon une autre particularité, l’exécution du module de vote permet au moins de vérifier si l’« ID » d’un agent se trouve dans une liste de votants stockée dans la couche de stockage de la base de données, d’exécuter un processus de validation approfondie pour déterminer la validité d’un bloc, d’ajouter un vote au bloc correspondant au résultat de la validation, et de déclencher ou non une minuterie pour chaque vote manquant.
Selon une autre particularité, la couche de stockage comprend au moins :
• une liste des agents et des services qui existent sur la plateforme. Lesdits agents et services ont été créés et stockés dans un bloc qui a été validé. Ladite liste tient compte de tous les états créés, désactivés et supprimés.
• Une mémoire cache de blocs de chaîne à blocs (BBC), qui est une mémoire cache d’un certain nombre de blocs, pour lesquels une décision a été prise (stockés dans la chaîne de blocs ou dans le dépôt de blocs invalides), qui sont conservés en mémoire pour des raisons de performances. Ladite mémoire cache est matérialisée comme une file d’attente limitée en taille (paramètre de configuration) qui utilise des HashMaps sousjacents pour une recherche efficace d’au moins tous les ID de blocs (identités de blocs), ID de transactions ;
• une mémoire cache de blocs de consensus (CBC), qui est analogue à la mémoire cache de chaîne de blocs et qui est utilisée pour les blocs pour lesquels aucune décision n’a été prise;
• une liste de vote, conservée par chaque agent, qui comprend les blocs pour lesquels un vote est exigé par l’agent correspondant, c’est-à-dire lorsque l’ID de l’agent a été ajouté à la liste des « agents votants » du bloc (ID des agents qui doivent fournir un vote), mais qu’aucun vote n’a encore été fourni ;
• une mémoire cache de transactions (PTC), qui conserve les transactions issues du groupe de transactions ;
• une liste d’autorisations de transaction (TLC). Ladite liste contient au moins les informations suivantes afin de décider si une transaction peut être ajoutée à un bloc destiné à être stocké :
- une transaction précédente (le cas échéant) est stockée dans un bloc validé
- un agent émetteur d’une transaction n’est pas placé sur liste noire
- toutes les données (DLE, agent, etc.) sont disponibles dans le système afin de procéder à leur vérification.
Selon une autre particularité, la couche de traçabilité comprend au moins un module « agents » destiné à stocker le modèle de données d’agent de traçabilité, un module d’objets de données (DO) destiné à stocker le modèle de données des objets de données de traçabilité (DO), un module « service » destiné à stocker le modèle de données du service de traçabilité, et un module « transactions » destiné à stocker les transactions de la couche de traçabilité.
Selon une autre particularité, les entités de traçabilité sont également identifiées par un « ID statique » qui ne change pas pendant une mise à jour et comprend au moins :
• Propriétaire de l’agent (AgentOwner) : « agent_owner_id » (ID unique) • Agent : « agent_id » (clé publique) • Service : « service_id » (ID unique) + « service_version »
Selon une autre particularité, dans la couche de stockage, au moins l’une des requêtes suivantes est prise en considération pour garantir le traitement efficace des informations liées à un bloc :
• Obtention des blocs par ID ;
• Obtention de l’heure de création des blocs ;
• Obtention des transactions du stockage par ID de bloc ;
• Obtention des informations de statut par ID de bloc ;
• Obtention des votes par ID de bloc ;
• Obtention du DLE par ID de transaction du stockage
Selon une autre particularité, au moins l’une des requêtes suivantes est prise en considération pour la traçabilité des données dans la couche de traçabilité, qui sont réalisées en tant que requêtes de base de données avec les informations correspondantes :
• Obtention de la transaction à tracer par ID d’objet de donnée ;
• Obtention de la transaction à tracer par ID de service ;
• Obtention des agents par ID de transaction à tracer ;
• Obtention des services par ID de transaction à tracer ;
• Obtention des agents par ID de propriétaire d’agent ;
• Obtention des services par ID de service.
Selon une autre particularité, le module de vote ayant des performances élevées et une fonctionnalité de paramétrabilité, permet :
• d’ajuster le vote selon une taille de fédération réduite, avec un temps-système de vote réduit et des latences de stockage correspondantes réduites, • de stocker instantanément le vote sans que la conception architecturale exige une durée de stockage minimale.
Selon une autre particularité, la technologie de couche de stockage de la base de données se met à l’échelle par sa conception pour obtenir un débit de stockage total élevé.
Selon une autre particularité, la fonctionnalité de paramétrabilité de l’infrastructure technique distribuée est assurée par un programme et des fichiers de configuration propres aux couches, chaque couche de ladite infrastructure étant apte à fournir des configurations individuelles.
Selon une autre particularité, le service d’approvisionnement en données (DPS) conserve des preuves d’activité de manière transparente pour l’utilisateur.
Selon une autre particularité, le service d’approvisionnement en données (DPS) maintient l’activité de fourniture de données, qui requiert d’indiquer les métadonnées connexes, comme les références aux ensembles de données utilisés des autres.
Selon une autre particularité, le service d’approvisionnement en données (DPS) conserve l’historique complet d’un ensemble de données en analysant les preuves et en suivant les références au sein des métadonnées afin de permettre le suivi de l’historique complet d’un ensemble de données, et d’identifier tous les utilisateurs qui peuvent contribuer à sa création.
Selon une autre particularité, le service d’approvisionnement en données (DPS) étend la fonctionnalité de propriété pure avec des opérations destinées à maintenir les ensembles de données sur la plate-forme.
Selon une autre particularité, la plate-forme reçoit une requête en provenance d’un service d’analyse de données complexes utilisant des modèles d’apprentissage machine (ML) et des ensembles de données d’apprentissage disponibles sur la plate-forme afin d’offrir un service d’analyse par apprentissage machine.
Selon une autre particularité, le système comprend :
• une chaîne de blocs ; et • une ressource de calcul prévue pour exécuter une boucle de sorte que l’exécution de la boucle soit influencée par l’état de la chaîne à blocs, la boucle étant mise en œuvre à l’aide d’un script, afin de conserver un décompte d’un ou plusieurs votes pour la validation des blocs liée au consensus, ou pour les décisions de validité des blocs, et un statut de bloc correspondant généré pour ou associé au bloc extrait de la file d’attente de blocs ; et un ensemble de conditions d’invalidité définies par la fédération afin de déterminer la validité des blocs, et validées par chaque agent qui participe à un vote sont évaluées et au moins une action est menée sur la base du résultat de l’évaluation ; ladite action comprenant au moins :
- faire qu’au moins une transaction soit écrite dans le volume de chaîne de blocs de la base de données ; et/ou
- faire qu’une action hors chaîne de blocs soit exécutée.
Selon une autre particularité, pour chaque itération de la boucle, un hachage cryptographique du script est généré, et les informations relatives à au moins une itération de la boucle sont stockées dans une transaction sur la chaîne de blocs ; les informations étant stockées sous la forme de métadonnées dans la transaction.
Selon une autre particularité, les conditions concernent les données reçues, et les changements de propriété détectés ou générés par la ressource de calcul ; ou l’état de la chaîne de blocs.
Selon une autre particularité, la base de données offre un moyen d’identification des processus liés au stockage du groupe de transactions, à la file d’attente de blocs, à la chaîne de blocs et au dépôt des blocs invalides, à la gestion des blocs, aux agents, aux objets de données, aux services et à la traçabilité des transactions.
Selon une autre particularité, les processus de stockage de la base de données et de consensus par chaîne à blocs constituent chacun une couche de l’architecture qui peut être supprimée, remplacée ou étendue avec d’autres caractéristiques.
Selon une autre particularité, la plate-forme de traçabilité des données comprend au moins un module d’estimation, ledit module comprenant au moins un ensemble de modèles et de programmes destinés à estimer la contribution de différents ensembles de données pour la création d’un nouvel ensemble et, ainsi, à estimer un barème de rémunération équitable pour la réutilisation de l’ensemble de données.
Selon une autre particularité, l’ensemble de modèles et de programmes comprend au moins un modèle d’estimation de valeur de Shapley, ladite valeur de Shapley estimant la valeur d’un ensemble de données et/ou la contribution relative d’ensembles de données d’entrée à la valeur de l’ensemble de données résultant.
Selon une autre particularité, le module d’estimation est utilisé pour la rémunération de chaque utilisateur qui a participé à la création du nouvel ensemble de données selon le montant de la participation.
BRÈVE DESCRIPTION DES DESSINS
D’autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels :
- La figure 1 est une représentation schématique des éléments de la base de données distribuée (2).
- Les figures 2a, 2b, 2c et 2d sont des représentations schématiques, respectivement, d’un fournisseur de données (3) qui crée un service à l’aide de la plate-forme de traçabilité de données (1) (DTP), d’un fournisseur de données (3) qui fournit un service à un consommateur de données à l’aide de la plate-forme de traçabilité de données, et du processus de traçabilité de l’utilisation des données consommées à l’aide de la plate-forme de traçabilité de données et de l’utilisation de la plate-forme pour estimer la contribution relative des ensembles de données d’entrée à la valeur de l’ensemble de données résultant, selon un mode de réalisation ;
- La figure 3 est une représentation de tableaux contenant les attributs relatifs à un objet de données, selon un mode de réalisation ;
- La figure 4 est une représentation de tableaux contenant les attributs relatifs à un bloc, selon un mode de réalisation ;
- La figure 5 est une représentation de tableaux contenant les attributs relatifs au groupe de transactions de la couche de stockage, selon un mode de réalisation ;
- La figure 6 est une représentation de tableaux contenant les attributs relatifs à la file d’attente de blocs de la couche de stockage, selon un mode de réalisation ;
- Les figures 7a et 7b sont des représentations de tableaux contenant des attributs relatifs respectivement à la gestion de stockage et au vote de blocs, selon un mode de réalisation
- La figure 8 est une représentation de tableaux contenant les attributs relatifs aux transactions dans la couche de stockage, selon un mode de réalisation ;
- La figure 9 est une représentation de tableaux contenant les attributs relatifs au « propriétaire d’un agent » de la couche de traçabilité, selon un mode de réalisation ;
- La figure 10 est une représentation de tableaux contenant les attributs relatifs à un « agent » de la couche de traçabilité, selon un mode de réalisation ;
- La figure 11 est une représentation de tableaux contenant les attributs relatifs aux « services » de la couche de traçabilité, selon un mode de réalisation ;
- La figure 12 est une représentation de tableaux contenant les attributs relatifs aux transactions de la couche de traçabilité, selon un mode de réalisation.
DESCRIPTION DÉTAILLÉE
La présente invention concerne une infrastructure technique distribuée qui permet de suivre des données.
Dans certains modes de réalisation, l’infrastructure technique distribuée destinée à un système de plate-forme (1) de traçabilité de données basé sur des(DTP) comprend au moins un serveur de base de métadonnées (2) à architecture en couches (figure 1) et à ressources de calcul, un serveur de surveillance de la qualité des données, un serveur de gestion pour un service d’approvisionnement en données (DPS), et une machine d’interrogation automatique, et est caractérisée en ce que la base de données (2) est utilisée pour stocker des données et conserver des preuves sécurisées de l’échange de données, de la propriété des données et du transfert de propriété des données dans des objets de données (DO) afin de permettre à un utilisateur (4) d’accéder à des ensembles de données (DOi.. DOn) fournis par d’autres utilisateurs, et de proposer un ensemble de données accessible par un autre utilisateur (4), et dans laquelle la plateforme de traçabilité de données (1) adapte la technologie de chaîne de blocs (22) pour le suivi sécurisé de la propriété d’un ensemble de données (DO) à stocker dans la base de données (2), et met en place un processus de consensus par fédération (FC), au cours duquel un module de vote décide de la validité d’un bloc afin de stocker le bloc dans la base de données (2).
La plate-forme (1) (DTP) peut comprendre au moins un ensemble de couches et au moins :
• une couche centrale qui maintient les couches de la plateforme (1) et permet à toutes les couches d’accéder aux contrôleurs des autres couches.
• une couche réseau qui conserve une liste des pairs qui sont actuellement en ligne. Ainsi, une couche plus élevée peut vérifier si un pair et ses services sont actuellement en ligne. La couche réseau ne connaît pas les couches supérieures. Cependant, un paramètre réseau « PeerProfile » est préparé avec un agent et un champ de signature. Cela active le lien entre un pair et un agent de la plate-forme, et l’intégrité cryptographique.
Avant d’aller plus loin dans la description de la présente invention, certains des termes utilisés ou qui peuvent être utilisés doivent être définis.
Le terme « agent » désigne la plus petite entité autonome de la plate-forme (1) qui propose et/ou utilise les services de la plate-forme (1). Le terme « Agent » est en outre caractérisé par ce qui suit :
• « Application d’agent » : techniquement, l’agent est une sorte d’application logicielle qui interagit avec la plate-forme (1) et comprend la logique de communication connexe et le protocole collaboratif ;
• « Opérateur d’agent » : un agent (une application) peut être contrôlé par une personne, une logique logicielle (comme un démon de base de données (2), un contrôleur d’analyse de données, un agent logiciel) ou une intelligence artificielle qui interagit avec l’application d’agent. Cette logique peut être intégrée à un matériel embarquée (comme des capteurs intelligents).
• « Machine d’agent » : la machine d’agent est l’ordinateur sur lequel est exécutée l’application d’agent. Pour des raisons de simplicité, nous supposons une application d’agent exécutée sur une machine dédiée. Une machine d’agent peut être reliée à d’autres machines afin de proposer plus efficacement le service (comme un cluster de serveurs d’analyse de données massives). Ces machines servent uniquement de support pour l’exécution du service de l’agent, et ne sont pas directement reliées à la plate-forme.
• « Représentant légal d’agent » : chaque agent possède une seule et unique personne qui fait office de représentant légal, et qui est responsable 1) des opérations de l’agent sur la plate-forme (1) et 2) des transferts monétaires, comme le paiement d’un service. Pour des raisons de simplicité, nous supposons que ces deux responsabilités sont assumées par une seule personne, tandis que plusieurs machines d’agents peuvent avoir le même représentant légal d’agent.
• « Agent de plate-forme (1) » : il s’agit d’un agent spécial qui travaille pour le compte du fournisseur de la plate-forme (1) (3, figures 2a, 2b) et qui se concentre sur la disponibilité et l’exactitude du service disponible. Ainsi, il effectue des vérifications de preuves (métadonnées de provenance, par exemple) et prend en charge certaines opérations, comme la dissémination et la mise en cache des données.
Le terme « service » désigne un ensemble « d’opérations » proposées par un agent, le « prestataire de service (3, figures 2a, 2b) » ou le fournisseur de données, à un autre agent, le « consommateur du service ». Une « consommation de service » désigne le fait que le consommateur d’un service (ou l’utilisateur d’un service (4, figures 2b, 2c), ou un consommateur de données) utilise une opération spécifique proposée par le prestataire de service (3). Dans ce qui suit, si cela n’est pas explicitement mentionné, nous utilisons le terme « service » de manière interchangeable avec le terme « opération (service) ».
Certains des termes liés à un service proposé sur la plate-forme (1) sont, par exemple et sans limitation, les suivants :
• Un « appel de service », qui désigne la requête ou demande, par un agent, de la consommation d’un service proposé par un fournisseur (3).
• Une « activité de service », qui désigne l’activité réalisée par un prestataire de service (3) pour exécuter un service spécifique (et pour laquelle un consommateur peut payer des frais). L’activité comprend :
- soit la mise à disposition d’un objet de données préparé à l’avance ;
- soit la mise à disposition d’un objet de données créé à la demande par un certain traitement (en prenant en compte des objets de données d’entrée ou des ressources externes) ; soit
- le traitement des données sans délivrer d’objet de données en guise de service (comme la remise d’une réputation, la modification des droits de contrôle d’accès).
• Le terme « métadonnées de service » décrit le service et l’activité de service correspondante. Plus particulièrement, il contient (s’il est fourni par l’agent) des métadonnées de provenance détaillées afin de permettre la traçabilité des objets de données en guise de service (comme le traitement des scripts dans un code source pour la création de l’objet de données).
• Le terme « entrée de service » désigne les objets de données (propres ou issus d’autres services) utilisés comme entrée pour l’exécution d’une opération de service par le prestataire de service (3). En termes de langages de programmation, cela représente les paramètres d’entrée d’un procédé de traitement de données.
• Le terme « sortie de service » désigne le résultat de l’activité de service qui est transmis au consommateur du service. Il comprend au moins un code de statut et généralement un ou plusieurs objets de données également.
• « type de service » définit la manière dont les services sont exécutés. Deux manières sont possibles :
- Un « service pull », qui est exécuté de manière réactive. Le consommateur d’un service émet un appel de service vers un prestataire de service (3) afin de consommer le service proposé. Le prestataire (3) exécute l’activité de service et renvoie le service au consommateur.
- Un « service push », qui est exécuté de manière proactive. Le consommateur du service s’abonne à un service spécifique en émettant un appel de service. Le prestataire de service (3) exécute le service et fournit le service sur la base d'un évènement ou de manière périodique.
Le terme « objet de données » (DO) désigne une entité qui encapsule des données pour un échange entre les agents dans le contexte de l’entrée de service ou de la sortie de service. L’« origine de l’objet de données » (voir les métadonnées d’objet de données) spécifie la manière dont l’objet de données a été créé. Elle se rapporte généralement à une transaction de service et, ainsi, à un service/un agent spécifique, où la création réelle doit être décrite par le biais des métadonnées de provenance. Cependant, des agents peuvent également créer un objet de données pour l’entrée de service (éventuellement à l’aide d’un autre objet de données et de ressources externes). Dans ce cas, l’agent doit idéalement fournir les métadonnées de provenance correspondantes de la même manière que le prestataire de service (3).
Un objet de données peut être l’un des « types d’objet de données » suivants :
• Un « ensemble de valeurs » • Un « ensemble de données » • Un « flux de données » • Des « données génériques »
Des « métadonnées d’objet de données » décrivent l’objet de données et son contexte. Elles contiennent, entre autres, le type d’objet de données, la date et l’heure de création, le service responsable de la création, le prestataire de service (3), les informations sur l’intégrité et la sécurité (sommes de contrôle, signatures numériques, etc.), et l’identification du propriétaire (voir la figure 3).
La provenance indique, d’un point de vue ou une approche «topdown », la possibilité (ou capacité) de dériver l’historique des données au fil des étapes de calcul pendant le traitement, en commençant par les sources initiales. À l’inverse, nous considérons la traçabilité comme présentant des caractéristiques ascendantes ou « bottom-up », indiquant la possibilité (ou capacité) de suivre les relations entre les données et les changements de données afin de déterminer les processus de provenance. Par conséquent, nous considérons la traçabilité en indiquant les aspects techniques de l’association de données, tandis que la provenance aborde le concept global de détermination des informations de provenance (comme les processus de retour à la création initiale des données).
Un système de provenance est, en général, caractérisé par au moins trois caractéristiques principales : l’orientation de la provenance, le modèle et les mécanismes de capture.
L’orientation de la provenance peut être orientée données ou orientée calculs. Dans le premier cas, le système de provenance capture des informations sur le flux et la transformation des données. Dans le second cas, qui correspond à l’orientation calculs, les informations capturées sont les détails de la transformation des données (traitement des données).
Dans le système de provenance, le modèle de provenance utilisé pour capturer les informations est en général de deux types : rétrospectif et prospectif. Dans un modèle rétrospectif (RPM), les annotations sur le flux et la transformation des données sont enregistrées. Le modèle rétrospectif peut conserver les annotations sur les données et/ou leur traitement. À l’inverse, le modèle prospectif (PPM) offre une « recette » (un ensemble d’étapes, une méthode, ...) qui décrit comment traiter les données. Ainsi, un modèle prospectif est généralement axé sur le traitement afin de pouvoir répéter facilement le même calcul. La plate-forme de traçabilité de données met en œuvre un modèle rétrospectif en conservant automatiquement les preuves des interactions (les preuves de consommation d’un service sont par exemple conservées par le biais de la « transaction de traçabilité », qui contient des informations détaillées sur le fournisseur, le consommateur, le service, etc.), qui sont sécurisées de manière cryptographique pour garantir la protection des données.
Les mécanismes de capture, essentiellement utilisés dans un système de provenance, sont des mécanismes qui reposent sur des processus et/ou un système d’exploitation.
En ce qui concerne les mécanismes qui reposent sur des processus, ceux-ci sont étroitement liés à des systèmes de gestion de processus (WMS). Ainsi, les informations de provenance indiquent les liens entre les entrées et les sorties des calculs, qui déterminent un processus.
Les mécanismes qui reposent sur des processus enregistrent les informations de calcul depuis l’intérieur d’une application, c’est-à-dire qu’ils nécessitent un processus propre pour documenter les tâches de calcul.
Les mécanismes qui reposent sur un système d’exploitation (également désignés « capture environnementale ») n’ont besoin d’aucune modification sur l’application elle-même. Ils utilisent les fonctionnalités ou caractéristiques d’un système d’exploitation (ou un environnement par le biais de wrappers) pour capturer les données. Ainsi, les processus d’exécution d’une application sont considérés comme une boîte noire, tandis que l’entrée et la sortie peuvent être capturées. Une représentation graphique est une visualisation courante et est utilisée par les mécanismes qui reposent sur un système de gestion de processus et un système d’exploitation. Cependant, ils présentent des approches fondamentalement différentes.
De nombreux systèmes de provenance comprennent au moins l’une des caractéristiques principales décrites ci-dessus, comme par exemple, et sans limitation, Sumatra, Taverna ou Vistrails. Les systèmes les plus courants reposent sur des processus, et visent des calculs reproductibles et, ainsi, des données clairement traçables. En règle générale, ils spécifient le calcul à l’avance, tout en enregistrant rétrospectivement des informations supplémentaires. Cependant, aucun des systèmes ne convient pour être directement appliqué pour la traçabilité des données. Les systèmes de gestion de processus sont trop axés sur la gestion centrale et sur les processus eux-mêmes, c’est-à-dire qu’ils spécifient les processus (ou l’orchestration du service) à l’avance. Les systèmes dont la capture de données repose sur un système d’exploitation sont hors sujet, étant donné qu’ils brisent l’hypothèse de surveillance.
Les systèmes de provenance qui reposent sur un traitement constituent des candidats prometteurs, cependant. Dans ces systèmes, un agent spécifie le traitement des données par le biais d’assertions, et indique avec des métadonnées les relations avec les autres ensembles de données d’entrée. Cela correspond également à un système de gestion de processus organisé et décentralisé, axé sur le traitement tout en capturant également les processus. Le traitement adéquat peut ensuite être vérifié par le biais de contrôles, avec un ensemble de données particulier.
Dans la présente invention, un système à chaîne de blocs (22) est adapté afin d’offrir plusieurs avantages en termes de provenance et de traçabilité.
La chaîne de blocs (22) n’est pas un système de provenance classique, mais plutôt un type de base de données distribuée (2). La chaîne de blocs (22) est capable de stocker des informations de manière sécurisée par le biais de preuves cryptographiques, sans avoir besoin d’une instance centrale (de confiance). La chaîne de blocs (22) (voir la figure 1) stocke les informations sous forme de blocs, qui sont concaténés en une chaîne et stockés de manière distribuée. Chaque bloc possède une référence au bloc précédent, ce qui permet de traverser l’intégralité de la chaîne depuis le dernier bloc. Étant donné que de nouveaux blocs peuvent être ajoutés en même temps, des « ramifications » peuvent apparaître, et engendrer plusieurs derniers blocs. Une seule chaîne peut être valide pour garantir un dernier bloc unique, et est déterminée par un protocole de consensus. Chaque bloc comprend plusieurs transactions, qui sont sécurisées avec une cryptographie asymétrique. Chaque nouvelle transaction est validée par le propriétaire de la transaction actuelle, ce qui crée ainsi une chaîne de transactions validées. En guise de preuve de validité, le propriétaire d’une transaction en cours signe numériquement une valeur de hachage de la nouvelle transaction. La valeur de hachage utilise la transaction actuelle et la clé publique du propriétaire de la nouvelle transaction comme entrée. Il est important de noter que la chaîne de blocs (22) est dépourvue d’état. Les transactions stockées dans un bloc sont le seul état existant.
Le terme « transaction » désigne généralement tous les messages échangés pour assurer la consommation d’un service. Une transaction, comme pour les bases de données (2), est soit exécutée en entier (consommation réussie du service, avec tous les échanges de messages connexes), soit en échec (aucune consommation de service).
Le terme « hachage » désigne la valeur renvoyée par une fonction de hachage. Une fonction de hachage est n’importe quelle fonction qui peut être utilisée pour mapper des données de taille arbitraire par rapport à des données de taille fixe.
Un exemple d’utilisation est une structure de données appelée « table de hachage », largement utilisée dans les logiciels informatiques pour rechercher rapidement des données. Les fonctions de hachage accélèrent la recherche dans une table ou une base de données (2) en détectant les enregistrements en double dans un fichier de grande taille. Exemple : recherche de tronçons similaires dans des séquences ADN. Elles sont également utiles pour la cryptographie. Une fonction de hachage cryptographique permet de vérifier facilement que certaines données d’entrée sont mappées par rapport à une valeur de hachage donnée, mais si les données d’entrée sont inconnues, il est délibérément difficile de les reconstruire (ou autre) en connaissant la valeur de hachage stockée. Celle-ci est utilisée pour garantir l’intégrité des données transmises.
La création d’un bloc capable de stocker des transactions dans la chaîne de blocs (22) nécessite la résolution d’un certain puzzle cryptographique. Généralement, comme par exemple dans Bitcoin, cela consiste à trouver certaines valeurs nonce (nombre aléatoire ou pseudoaléatoire destiné à être utilisé une seule fois) de sorte que la valeur de hachage pour les transactions à stocker commence par un groupe de zéros. Cela est également désigné « minage » (Bitcoin); le mineur est récompensé avec des bitcoins pour ses efforts de calcul. Un nouveau bloc, s’il est vérifié par d’autres explorateurs, est ensuite ajouté à la chaîne à blocs (22), qui sert de confirmation de stockage pour les transactions associées.
Par mineur, on entend une personne qui dispose d'au moins d’une architecture matérielle et logicielle pour mettre en œuvre le procédé de minage ci-dessus.
Dans certains modes de réalisation, un bloc est défini par une table (voir figure 4) qui contient les attributs suivants (ID, horodatage, statut, dm_version, charge utile, créateur, votants, commentaire, signature, ID du bloc précédent)
Il doit être compris que le consensus par fédération (FC) de la présente invention est très différent des autres approches de validité des blocs, et notamment de l’approche « preuve de fonctionnement » qui utilise le calcul d’un bloc valide par le biais d’un « minage de bloc » (en résolvant un puzzle), au cours duquel la validité d’un bloc est vérifiée individuellement par chaque utilisateur de la chaîne à blocs. Au lieu de cela, le consensus par fédération de la présente invention fonctionne comme un pur système distribué, dans lequel le module de vote de chaque agent de plate-forme de traçabilité des données (entité active d’une instance de plate-forme de traçabilité de données) d’une « fédération de plate-forme » (un sousensemble de tous les agents de plate-forme disponibles) propose un vote individuel sur la validité, et le total finalement cumulé des votes détermine la validité du bloc. Les différences significatives résident en outre dans la possibilité de paramétrage, et notamment de la taille réelle de la fédération DTP et des participants, et du seuil de validité.
Les transactions comprennent en outre des scripts de transactions qui doivent être exécutés sans problème afin d’être acceptés dans un bloc. Lesdits scripts de transactions vérifient généralement les valeurs de hachage et les signatures des transactions (représentées par un paramètre indiqué transaction « pay-to-pub-key-hash »). Cependant, le langage de script utilisé offre quasiment 200 commandes, appelées « codes opération » (opcodes), qui comprennent une prise en charge des opérations cryptographiques. Cela permet une logique complexe pour le stockage des transactions.
Dans une chaîne de blocs (22), il n’existe aucune notion inhérente d’identités ou de comptes individuels qui « possèdent » une transaction. Dans une chaîne de blocs, la propriété désigne simplement le fait de connaître une clé privée qui est capable d’effectuer une signature qui récupère la transaction.
En plus des caractéristiques technologiques susmentionnées intégrées à une chaîne de blocs (22), comme les transactions et les scripts qui concernent le format et les scripts d’une transaction, c’est-à-dire la manière dont une transaction est techniquement spécifiée et son exactitude est validée, un protocole de consensus qui spécifie la chaîne qui sera considérée comme valide lorsque plusieurs blocs sont valides en termes de puzzle cryptographique, une fonctionnalité de minage de blocs qui spécifie un puzzle cryptographique adéquat afin de trouver un identifiant de bloc valide (ID) et qui peut également gérer les récompenses appropriées pour les explorateurs pour leurs efforts de calcul, une chaîne de blocs (22) peut également comprendre au moins un module de communication peer-to-peer (P2P) qui gère au moins la distribution des blocs sur la plate-forme (1) et/ou les transactions.
Les caractéristiques susmentionnées peuvent permettre à une chaîne de blocs (22) d’être utilisée comme un système de gestion de preuves distribué pour la traçabilité des données. En fait, la chaîne à blocs (22) exécute intrinsèquement une gestion de preuve sur un système P2P sans avoir besoin d’une instance centrale de confiance. De plus, la traçabilité est naturellement assurée par le biais de l’architecture à chaîne. De plus, toutes les transactions et les données qu’elles contiennent sont automatiquement vérifiables. Cependant, les aspects tels que l’algorithme du protocole de consensus et les récompenses liées au minage doivent reposer sur des décisions éclairées, étant donné qu’ils affectent la stabilité et les performances globales de la plate-forme distribuée.
En ce qui concerne le système de provenance, en règle générale, la chaîne de blocs (22) peut être caractérisée par ce qui suit :
• informations de capture orientées données : la chaîne de blocs (22) vise à persister les données classiques au sein de la chaîne de blocs distribuée (22). Cependant, le format des transactions est généralement modifié afin d’exécuter des fonctionnalités supplémentaires (comme des contrats intelligents, ou « smart contracte ») • modèle de provenance rétrospectif : une chaîne de blocs (22) possède généralement un modèle de provenance rétrospectif étant donné que la sortie (résultat) de certains traitements ou d’autres données disponibles sont stockées.
• mécanisme de capture reposant sur un processus : la chaîne de blocs (22) repose sur un processus, étant donné que l’application réelle doit persister les données au sein de la chaîne (22).
Par « persister » des données, on entend « stocker » des données d’une de manière persistante. Autrement dit, de les sauvegarder afin qu’elles ne disparaissent pas lorsque, par exemple, le processus ou le programme de traitement se termine.
Dans certains modes de réalisation, l’infrastructure technique distribuée comprend au moins une infrastructure de clés publiques (PKI) qui permet d’utiliser des outils cryptographiques asymétriques pour sécuriser les transactions d’un ensemble de données ou d’objets de données (DO) et suivre la propriété d’un ensemble de données.
Dans certains modes de réalisation, un agent doit créer un compte de plate-forme pour pouvoir participer à la plate-forme (1) et désigner un représentant légal, responsable des actions de l’agent, dont l’identité (ID) est vérifiée. Pendant la création du compte, une clé publique et privée unique est générée pour l’agent afin de pouvoir utiliser au moins un outil cryptographique asymétrique de l’infrastructure de clés publiques. Dans certains modes de réalisation, ladite clé publique et privée unique peut également permettre audit agent d’agir comme une entité DTP active, qui est active dans une machine qui exécute une instance DTP et qui est responsable des actions de l’instance à l’aide des signatures numériques de toutes les communications qui utilisent ladite clé privée.
Dans certains modes de réalisation, l’infrastructure technique distribuée comprend au moins un système d’accès et de contrôle (AC) qui maintient l’accès aux services disponibles et/ou qui contrôlent la création de services frauduleux au sein de la plate-forme, tandis que les droits d’accès sont spécifiés par chaque prestataire de service (3) qui crée une preuve de droit d’accès pour l’utilisateur concerné à l’aide des fonctionnalités de gestion des données à chaîne de blocs (un document de preuve est créé avec la transaction « CREATE » de la chaîne de blocs, dont le modèle de données indique le propriétaire actuel par le biais d’un attribut ou d’un champ « c_owner », et est sécurisé de manière cryptographique par la signature numérique du prestataire de service). À l’aide du système d’accès et de contrôle, un agent doit spécifier à l’avance, par le biais d’assertions, les services proposés et l’activité de service menée. Les assertions peuvent ensuite être contrôlées après la consommation du service et, ainsi, peuvent détecter les éventuelles fraudes spécifiées ci-dessus. En effet, les assertions spécifient l’activité de service et vérifient le service rendu correspondant par rapport aux assertions. En cas d’absence de correspondance, l’accès n’est pas accordé, et le service et le résultat sont stockés dans une mémoire de l’infrastructure technique afin de procéder à des vérifications complémentaires. « Aucun accès accordé » signifie que le service lui-même est visible, mais que la consommation de ce service sera refusée.
L’expression « modèle de données » désigne un modèle qui documente et organise les données, la manière dont elles sont stockées et accédées, et les relations entre les différents types de données.
Dans certains modes de réalisation, le système d’accès et de contrôle permet une traçabilité inter- et intra-service, étant donné que l’activité de service peut être suivie en détail si des assertions appropriées sont fournies par un prestataire de service. Pour chaque service numérique consommable (et les objets de données de sortie proposés par le biais d’un service), le prestataire de service (3) spécifie, à l’aide d’une interface interactive qui repose sur un navigateur Web (et qui crée les modèles de données qui peuvent être traités par la plate-forme de traçabilité des données), des métadonnées de provenance qui permettent la traçabilité inter-service et intra-service. Les prestataires de services (3), au sein de la plate-forme, fournissent au moins les détails des calculs effectués et des objets de données de sortie prévus.
Le terme « traçabilité inter-service » désigne le suivi de l’orchestration du service (le cas échéant) et de l’utilisation de ressources externes. Cela s’effectue à l’aide d’une spécification des services utilisés par le biais du prestataire de service pendant la création du service (comme un service interactif par le biais d’une interface utilisateur à navigateur Web qui crée des modèles de données utilisables par la plate-forme de traçabilité des données), conservée dans les modèles de données corrélés de la plateforme (par exemple, un service peut indiquer « autres services utilisés »). Étant donné que la plate-forme de traçabilité des données est un système privé, n’importe quel utilisateur doit accepter les conditions générales, qui comprennent l’exactitude des informations indiquées, représentant ainsi une protection par la loi, dont le non-respect peut être détecté par les processus d’analyse des données de la plate-forme et faire finalement l’objet de poursuites judiciaires en utilisant également les preuves de traçabilité stockées sur la plate-forme de traçabilité des données.
L’expression « traçabilité intra-service » désigne le suivi de la manière dont le service lui-même est exécuté, c’est-à-dire des calculs liés à un service et de la création des objets de données de sortie (y compris les éventuels modèles/algorithmes, valeurs d’entrée, etc.).
Dans certains modes de réalisation, la chaîne à blocs (22) est adaptée pour comprendre un modèle prospectif permettant à un prestataire de service de fournir des informations orientées calcul, en stockant au moins les assertions d’une approche d’accès et de contrôle (AC) dans le cadre d’une transaction, contenant ainsi des informations purement prospectives sur le calcul qui spécifie la logique réelle exécutée (comme des résultats de calcul immédiats qui permettent de suivre les calculs ou d’évaluer statistiquement le niveau de confiance des résultats) et qui peuvent avoir des niveaux d'abstraction différents (par exemple, code source, diagrammes de flux de travail, pseudo-code).
Dans certains modes de réalisation, le système de chaîne à blocs (22) est adapté pour comprendre un modèle rétrospectif en tirant profit de la fonctionnalité de stockage et de consignation des données (notary functionality), c’est-à-dire de preuves (cryptographiques) selon lesquelles les données ont été fournies ou conservées avec les opérations de gestion des données intégrées de la chaîne de blocs de la plate-forme de traçabilité de données (création, mise à jour, transfert, suppression, activation, désactivation) afin de maintenir les informations de traitement. Cela comprend des informations sur la logique réellement exécutée avant l’exécution elle-même (par exemple utilisation d'autres services lors du calcul, résultats de calcul).
Dans certains modes de réalisation, le système de chaîne de blocs (22) est adapté pour comprendre un modèle pro-/rétrospectif avec la fonctionnalité d’un système de gestion de processus distribué. Cela est rendu possible en combinant les informations pro- et rétrospectives, comme par exemple les connaissances sur la logique d’exécution du service et les résultats des calculs intermédiaires, afin de permettre le suivi des calculs et d’évaluer la fiabilité des résultats.
Dans certains modes de réalisation, la base de données (2) (DB) est conçue pour gérer les charges de travail élevées et les fonctionnalités en parallèle. Elle est distribuée avec des performances de correction linéaire optimisées pour les opérations d’écriture, qui représentent les principales opérations de la plate-forme ciblée. Ladite base de données (2) peut également prendre en charge des données hétérogènes, avec lesquelles les champs de données non affectés ne consomment/ne réservent pas de données. De préférence, la base de données sous-jacente (2) est Apache Cassandra. Ladite base de données (2) Apache Cassandra peut fournir au moins un algorithme de consensus insensible aux défaillances, comme par exemple, et sans limitation, PAXOS, qui garantit l’exactitude de la réplication de données distribuée et, ainsi, une excellente cohérence de la base de données (2).
Dans certains modes de réalisation, la base de données (2) comprend au moins une couche de stockage et une couche de traçabilité.
La couche de stockage comprend au moins un ensemble de modules : un module de groupe de transactions (transaction pool) (20) comprenant les attributs suivants (voir figure 5) (ID, dm_version, charge utile, horodatage, opération, previous_tid, c_owner, f_owner, payload_properties, commentaire, data_other, data_dle, signature, responsible_agent) pour traiter les transactions entrantes qui vont être stockées dans des blocs dans la file d’attente de blocs (21), un module de file d’attente de blocs (21) comprenant les attributs suivants (voir figure 6) (id, dm_version, charge utile, horodatage, transactions, créateur, votants, commentaire, statut, signature) pour traiter les blocs qui ne sont pas encore validés et qui font l’objet du consensus par fédération pour la validation distribuée des blocs, un module de chaîne à blocs (id, dm_version, charge utile, horodatage, créateur, votants, commentaire, statut, signature, ID du bloc précédent) (voir figure 4) pour traiter les blocs validés, un module de dépôt de blocs invalides (23) (comprenant les mêmes attributs que le module de chaîne à blocs) pour traiter les blocs qui ont été validés comme étant invalides pendant la validation des blocs par consensus par fédération par un module de vote de blocs comprenant les attributs suivants (voir figure 7b) (ID, dm_version, charge utile, voter_pubkey (clé publique), horodatage (timestamp), current_blockid, Id du bloc précédent, is_valid, vote_invalid_reason, signature), un module de gestion du stockage comprenant au moins les attributs suivants (voir figure 7a) (ID, horodatage, statut, previous_blockid, node_pubkey, signature, type, dm_version, transaction_id, indices, couche, data_dle_data_meta, data_other, data_dle_count) pour stocker et traiter les entités supplémentaires qui font partie des blocs et des transactions , notamment les votes requis pour le vote de blocs, des statuts de bloc utilisés pour conserver le résultat d’un vote de validité de blocs et d’éléments de lac de données (24) (DLE) extraits pour améliorer les performances en raison de leur taille de données variable, qui peut être importante.
Dans certains modes de réalisation, les transactions contenues dans la couche de stockage sont définies dans des tables illustrées sur la figure 8, qui contiennent les attributs suivants (ID, dm_version, charge utile, t_index (indice de transaction, c’est-à-dire l’indice de stockage dans le bloc correspondant), charge utile, horodatage, opération, previous_tid (ID de transaction), c_owner (propriétaire actuel, c’est-à-dire le propriétaire actuel de la clé publique), f_owner (respect de la condition définie par le champ « propriétaire actuel » de la transaction précédente, c’est-à-dire une signature avec la clé privée qui correspond à la clé publique du propriétaire actuel), « payload_properties », commentaire, data_other, signature, blockid, dle_count (élément de lac de données).
Le terme « lac de données » (24) désigne un répertoire de stockage de grande taille orienté objet qui conserve les données dans leur format natif jusqu’à ce qu’elles soient utilisées.
Dans certains modes de réalisation, la couche de stockage (figure 1) de la base de données (2) comprend au moins un stockage de groupe de transactions (20), un stockage de file d’attente de blocs (21), un stockage de chaîne de blocs (22), et stockage de blocs invalides et un lac de données (24).
Dans certains modes de réalisation, les transactions entrantes sont stockées dans le stockage de groupes de transactions (20), lesdites transactions étant ensuite traitées par le module de groupe de transactions (20), qui les extrait et les enregistre sous forme de blocs dans la file d’attente de blocs (21). Les blocs stockés dans la file d’attente de blocs (21) sont ensuite soumis à une validation de bloc via un consensus par fédération. La validation est effectuée à l’aide du module de vote de blocs. Le module de file d’attente de blocs (21) extrait les blocs qui ont été déterminés comme validés et les transmet au stockage de chaîne de blocs (22). Les blocs qui ont été déterminés comme invalides sont transmis au stockage de blocs invalides. Dans ce dernier cas, toutes les transactions dudit stockage de blocs invalides sont copiées, à l’aide du module de dépôt de blocs invalides (23), vers le groupe de transactions, pour avoir une seconde chance. Dans certains modes de réalisation, au moins une partie des transactions entrantes est copiée dans le lac de données (24).
Dans certains modes de réalisation, le module de gestion du stockage gère les transactions entrantes. En effet, l’exécution du module de gestion du stockage sur le processeur permet au stockage de groupe de transactions (20) au moins de recevoir les transactions brutes, de vérifier les transactions à l’aide d’un algorithme de validation approfondie, d’affecter les transactions entrantes à un agent DTP par le biais d’une stratégie de sélection (randomisée pour la répartition de la charge de travail, par exemple), et d’ajouter lesdites transactions vérifiées au stockage du groupe de transactions (20). Lesdites transactions vérifiées sont indiquées « transactions », avec une forte autorisation (strong clearance).
Dans certains modes de réalisation, l’algorithme de validation approfondie (DV) permet de valider par la suite les données arbitraires par toutes les couches architecturales de la plate-forme de traçabilité des données, en validant ainsi les données éventuellement imbriquées en profondeur, pendant que la logique de validation est fournie par le biais de « validateurs » qui ont exécuté la validation sous une forme sémantiquement capsulée (comme des contrôles de validité cryptographiques, la cohérence du modèle de données) optimisée pour une exécution simultanée (par le biais d’un matériel à plusieurs noyaux/plusieurs CPU). La validation approfondie est utilisée pour valider n’importe quelles données de la plateforme de traçabilité, et les validateurs peuvent être utilisés et étendus par des applications individuelles exécutées « au dessus » de la plate-forme, servant ainsi de routine de validation à usage général.
Dans certains modes de réalisation, le module de groupe de transactions (20) identifie les transactions vérifiées ou les transactions avec une marge importante à l’aide de l’agent DTP assigné qui est responsable de l’exécution du module de groupes de transactions, crée des blocs en utilisant l’autorisation des transactions, transmet les blocs à stocker dans la file d’attente de blocs (21), et supprime les transactions utilisées du stockage de groupe de transactions (20).
Dans certains modes de réalisation, l’exécution du module de vote permet au moins de vérifier si l’« ID » d’un agent (identité) se trouve dans une liste de votants stockée dans la couche de stockage de la base de données, d’exécuter un processus de validation approfondie pour déterminer la validité d’un bloc, d’ajouter un vote au bloc correspondant au résultat de la validation, et de déclencher ou non une minuterie pour chaque vote manquant.
La couche de stockage comprend également au moins :
• une liste des agents et des services qui existent sur la plateforme. Lesdits agents et services ont été créés et stockés dans un bloc qui a été validé. Ladite liste tient compte de tous les états créés, désactivés et supprimés.
• une mémoire cache (BBC) de blocs de chaîne de blocs (22), qui est une mémoire cache d’un certain nombre de blocs pour lesquels une décision a été prise (stockés dans la chaîne de blocs (22) ou dans le dépôt de blocs invalides (23)) qui sont conservés en mémoire pour des raisons de performances. Ladite mémoire cache est matérialisée comme une file d’attente limitée en taille (paramètre de configuration) qui utilise des HashMaps sous-jacents pour une recherche efficace de tous les ID de blocs (identité de blocs), ID de transactions, etc.
• une mémoire cache de blocs de consensus (CBC), qui est analogue à la mémoire cache de chaîne de blocs (22) et qui est utilisée pour les blocs pour lesquels aucune décision n’a été prise.
• une liste de vote, conservée par chaque agent, qui comprend les blocs pour lesquels un vote est exigé par l’agent correspondant, c’est-à-dire lorsque l’ID de l’agent a été ajouté à la liste des « agents votants » du bloc (ID des agents qui doivent fournir un vote), mais qu’aucun vote n’a encore été fourni ;
• une mémoire cache de groupe de transactions (PTC), qui conserve les transactions issues du groupe de transactions (20).
• une liste d’autorisations de transaction (TLC). Ladite liste contient au moins les informations suivantes afin de décider si une transaction peut être ajoutée à un bloc destiné à être stocké :
- une transaction précédente (le cas échéant) est stockée dans un bloc validé
- un agent émetteur d’une transaction n’est pas placé sur liste noire
- toutes les données (DLE, agent, etc.) sont disponibles dans le système afin de procéder à leur vérification.
La couche de traçabilité comprend au moins un module « agents » destiné à stocker le modèle de données d’agent de traçabilité, un module d’objets de données (DO) destiné à stocker le modèle de données des objets de données de traçabilité (DO), un module « service » destiné à stocker le modèle de données du service de traçabilité, et un module « transactions » destiné à stocker les transactions de la couche de traçabilité.
Toutes les entités fournissent la valeur de hachage du modèle de données sous la forme d’un ID unique dans le champ « ID ». Cela suffit particulièrement pour les objets de données et les transactions des entités de traçabilité, qui sont toujours uniques dans le système (les mises à niveau vers un objet de données deviennent une entrée de base de données distincte). Dans certains modes de réalisation, les entités de traçabilité sont également identifiées par un « ID statique » qui ne change pas pendant une mise à jour (comme en cas de changement de l’adresse e-mail du propriétaire d’un agent) et sont les suivantes :
• Propriétaire de l’agent (AgentOwner): « agent_owner_id » (ID unique) • Agent : « agent_id » (clé publique) • Service : « service_id » (ID unique) + « service_version »
Les « ID » susmentionnés (hachage du modèle de données) des entités de la couche de traçabilité (Propriétaire de l’agent, agent, service, etc.) sont utilisés pour l’identification d’une entrée de base de données spécifique. Une mise à jour des entités « Propriétaire de l’agent », « Agent » et « Service » peut provoquer un problème à première vue, étant donné que le hachage change. Par conséquent, un « ID statique », un identifiant universel unique (UUID) ou une clé publique est utilisé(e) comme autre identifiant unique qui ne change pas en cas de mise à jour du modèle de données (comme le numéro de téléphone du propriétaire de l’agent).
Le terme « UUID » désigne un chiffre à 128 bits utilisé pour identifier de manière unique un certain objet ou une certaine entité sur Internet.
Dans certains modes de réalisation, l’entité « Propriétaire de l’agent » comprend au moins l’un des attributs suivants (voir figure 9) : ID, dm_version, digest, agent_owner_id, asset_index, charge utile, first_name, last_name, date de naissance, adresse, numéro de téléphone, e-mail, photo, commentaire, data_other, data_dle, dle_count, pays, ville, sblock_id, stransaction_id, stransaction_op, stimestamp, tandis que les attributs sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux transactions contenues dans la couche de stockage.
Dans certains modes de réalisation, l’entité « Agent » comprend au moins l’un des attributs suivants (voir figure 10) : ID, dm_version, agent_id, asset_index, charge utile, agent_version, agent_owner, agent_type, agent_name, agent_picture, commentaire, data_other, data_dle, dle_count, sblockid, stransaction_id, stransaction_op, stimestamp, tandis que les attributs sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux transactions contenues dans la couche de stockage.
Dans certains modes de réalisation, l’entité « Service » comprend au moins l’un des attributs suivants (voir figure 11): ID, dm_version, asset_index, charge utile, service_id, service_version, provider_agent, description, result_description, result_type, input_param_descr, input_param_types, « output_do », used_service_id, used_service_version, used_service_op, api_specification, is_traceable, comment, data_other, data_dle, dle_count, sblock_id, stransaction_id, stransaction_op, stimestamp, input_param_count, do_output_count, tandis que les attributs sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux transactions contenues dans la couche de stockage.
Dans certains modes de réalisation, les transactions contenues dans la couche de traçabilité comprennent au moins l’un des attributs suivants (voir figure 12) : ID, dm_version, asset_index, charge utile, provider_agent, consumer_agent, service_id, service_version, service_op, input_param, output_do, resuit, comment, data_other, data_dle, dle_count, sblockid, stransaction_id, stransaction_op, stimestamp, tandis que les attributs sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux transactions contenues dans la couche de stockage.
La couche de stockage comprend au moins un ensemble de modules qui permettent le stockage et la validation des données. Pour effectuer lesdites opérations, c’est-à-dire le stockage et la validation des données, au moins un ensemble de requêtes est nécessaire. Afin d’obtenir des performances élevées pour le stockage des données et les requêtes qui y sont associées, les données importantes sont conservées en mémoire, en exécutant un certain type de fenêtres glissantes sur les données qui sont en train de subir le processus de validation. Ainsi, seule la validation des données est importante pour le modèle de données.
Dans certains modes de réalisation, pour obtenir des performances élevées, un modèle de données qui cible une validation qui repose sur des blocs peut être pris en considération. Cela signifie que les demandes d’informations liées à un bloc doivent être traitées efficacement. Au moins l’une des principales requêtes suivantes est prise en considération :
• Obtention des blocs par ID ;
• Obtention de l’heure de création des blocs ;
• Obtention des transactions du stockage par ID de bloc ;
• Obtention des informations de statut par ID de bloc ;
• Obtention des votes par ID de bloc ;
• Obtention du DLE par ID de transaction du stockage
Dans certains modes de réalisation, au moins l’une des requêtes suivantes est prise en considération pour la traçabilité des données dans la couche de traçabilité, qui sont réalisées en tant que requêtes de base de données avec les informations correspondantes :
• Obtention de la transaction à tracer par ID d’objet de donnée ;
• Obtention de la transaction à tracer par ID de service ;
• Obtention des agents par ID de transaction à tracer ;
• Obtention des services par ID de transaction à tracer • Obtention des agents par ID de propriétaire d’agent ;
• Obtention des services par ID de service.
Les requêtes sur la couche de traçabilité ne sont pas urgentes (critiques en terme de temps).
Dans certains modes de réalisation, le module de vote est caractérisé par des performances élevées et une fonctionnalité de paramétrabilité, étant donné que le vote peut être ajusté selon une taille de fédération réduite, comme par exemple celle d’agents DTP de confiance du fournisseur de la plate-forme de traçabilité de données, avec un tempssystème de vote réduit et des latences de stockage correspondantes réduites, et étant donné que le vote peut stocker instantanément et ne nécessite pas, en raison de sa conception architecturale, une durée de stockage minimum comme les autres systèmes, et plus particulièrement ceux qui utilisent un consensus à « preuve de fonctionnement » (comme Bitcoin, avec son minage de blocs). De plus, la technologie de couche de stockage (base de données Apache Cassandra), aussi bien que la conception du module de vote se met à l’échelle (évolue), peut se mettre à l’échelle (évoluer) par sa conception, ce qui permet d’obtenir un débit de stockage total élevé.
Dans certains modes de réalisation, la fonctionnalité de paramétrabilité de l’infrastructure technique distribuée est assurée par un programme et des fichiers de configuration propres aux couches, chaque couche de ladite infrastructure pouvant fournir des configurations individuelles. En effet, l’infrastructure distribuée comprend au moins un ensemble d’outils qui permettent de définir les couches architecturales de configuration de la plate-forme (1) sans modifier un quelconque programme stocké dans la mémoire de ladite plate-forme. Ainsi, les couches optimales peuvent être choisies ou remplacées par d’autres couches. Dans certains modes de réalisation, le stockage est séparé en une infrastructure de stockage (base de données (2)) et une gestion du stockage (chaîne de blocs (22)) qui possèdent des configurations complètes et indépendantes, ce qui contribue à la grande capacité de paramétrage (à la fois pour l’architecture de la plate-forme (1) et la configuration propre à la couche).
Dans certains modes de réalisation, le service d’approvisionnement en de données (DPS) conserve des preuves d’activité (fourniture de données, accès aux données) de manière transparente pour l’utilisateur.
Dans certains modes de réalisation, le service d’approvisionnement en données (DPS) maintient l’activité de fourniture de données, qui requiert d’indiquer les métadonnées connexes, comme les références aux ensembles de données utilisés des autres.
Dans certains modes de réalisation, le service d’approvisionnement en données (DPS) conserve l’historique complet d’un ensemble de données en analysant les preuves et en suivant les références au sein des métadonnées afin de permettre le suivi de l’historique complet d’un ensemble de données, et d’identifier tous les utilisateurs qui peuvent contribuer à sa création. Cela est effectué en analysant les modèles de données stockés dans la couche de stockage, en suivant leurs informations corrélées (par exemple, la transaction de traçabilité stocke des informations sur la consommation d’un service, avec l’agent du fournisseur/du consommateur, le service utilisé, le modèle de données d’entrée/de sortie, etc.) et en créant une structure de données graphique qui représente la traçabilité des données de toutes les entités de la plate-forme (objet de données, service, agent, transaction de traçabilité, etc.).
Dans certains modes de réalisation, le service d’approvisionnement en données (DPS) étend la fonctionnalité (caractéristique) de propriété pure avec des opérations (création, mise à jour, transfert, suppression, désactivation, activation) destinées à maintenir les ensembles de données sur la plate-forme.
Dans certains modes de réalisation, la plate-forme (1) reçoit une requête en provenance d’un service d’analyse de données complexes qui utilise des modèles d’apprentissage machine (ML) et des ensembles de données d’apprentissage disponibles sur la plate-forme (1) afin d’offrir un service d’analyse par apprentissage machine.
Dans certains modes de réalisation, le système comprend :
• une chaîne de blocs (22 ) ; et • une ressource de calcul prévue pour exécuter une boucle de sorte que l’exécution de la boucle soit influencée par l’état de la chaîne de blocs (22), la boucle étant mise en œuvre à l’aide d’un script, afin de conserver un décompte d’un ou plusieurs votes pour la validation des blocs liée au consensus, la validité des blocs ou les décisions de validité des blocs, et un statut de bloc correspondant généré pour ou associé au bloc extrait de la file d’attente de blocs (21) ; et un ensemble de conditions d’invalidité définies par la fédération afin de déterminer la validité des blocs (et validées par chaque agent qui participe à un vote) sont évaluées et au moins une action est menée sur la base du résultat de l’évaluation ; ladite action comprenant au moins:
- faire qu’au moins une transaction soit écrite dans le volume de la chaîne de blocs (22) de la base de données (2) ; et/ou
- faire qu’une action hors chaîne de blocs (22) soit exécutée.
Dans certains modes de réalisation, pour chaque itération de la boucle, un hachage cryptographique (valeur de hachage) du script est généré, et les informations relatives à au moins une itération de la boucle sont stockées dans une transaction sur la chaîne de blocs (22) ; de préférence, les informations sont stockées sous la forme de métadonnées dans la transaction.
Dans certains modes de réalisation, les conditions concernent les données reçues, et les changements de propriété (par l’opération de stockage de chaîne à blocs « TRANSFER », avec c_owner définissant le nouveau propriétaire) détectés ou générés par la ressource de calcul ; (ou l’état de la chaîne de blocs (22)).
Dans certains modes de réalisation, la base de données (2) offre un moyen d’identification des processus liés au stockage du groupe de transactions (20), à la file d’attente de blocs (21), à la chaîne de blocs (22) et au dépôt des blocs invalides (23), à la gestion des blocs, aux agents, aux objets de données, aux services et à la traçabilité des transactions. Plus spécifiquement, tous les modèles de données fournissent des informations sur l’agent émetteur et sont protégés de manière cryptographique par le biais de signatures, dont l’exactitude peut être prouvée avec la clé publique de l’agent concerné, qui est connue publiquement dans son modèle de données dans la table de base de données de l’agent, rendant ainsi toutes les interactions avec la base de données non seulement traçables, mais également sécurisées de manière cryptographique. La base de données elle-même est strictement « append-only » (à ajout seulement) pour des raisons de traçabilité. Par exemple, les mises à jour sont réalisées sous la forme d’une entrée supplémentaire de la base de données (en référence à l’état précédent), et la suppression sur la base de données n’est même pas mise en œuvre, mais est détectée (en cas de comportement malhonnête) en raison des relations cryptographiques.
Les agents sont les seules entités actives de la plate-forme (1) (contrôlées par des utilisateurs humains ou une logique logicielle) qui travaillent pour le compte d’un propriétaire d’agent, l’utilisateur humain (4) étant légalement responsable des actions des agents qu’il possède. La validité des blocs est déterminée par la vérification d’un ensemble de « conditions d’invalidité » (tout état d’invalidité engendre un vote d’invalidité de bloc), et un seuil paramétrable de votes valides doit être atteint, après quoi chaque vote est sécurisé de manière cryptographique avec une signature de l’agent émetteur.
Dans certains modes de réalisation, les processus de stockage de la base de données et de consensus par chaîne de blocs (22) constituent chacun une couche de l’architecture qui peut être supprimée, remplacée ou étendue avec d’autres caractéristiques, comme par exemple une couche d’estimation de la valeur des données.
Dans certains modes de réalisation, la plate-forme de traçabilité des données (1) comprend au moins un module d’estimation comprenant au moins un ensemble de modèles et de programmes destinés à estimer la contribution de différents ensembles de données pour la création d’un nouvel ensemble et, ainsi, à estimer un barème de rémunération équitable pour la réutilisation de l’ensemble de données.
Dans certains modes de réalisation, l’ensemble de modèles et de programmes comprend au moins un modèle d’estimation de valeur de Shapley. La valeur de Shapley peut estimer la valeur d’un ensemble de données et/ou la contribution relative d’ensembles de données d’entrée à la valeur de l’ensemble de données résultant. Par exemple, et de manière non limitative, un ensemble de données d’origine peut être partagé sur la plateforme (1) par un premier utilisateur. Ledit ensemble de données peut être modifié par un second utilisateur (4, figure 2c) (consommateur des données) ou un troisième utilisateur (4) et réutilisé sur la plate-forme. La mise en œuvre des outils de traçabilité de la plate-forme (1) de la présente invention peut permettre de suivre la provenance partagée des ensembles de données, et chacune de leurs transformations. Lesdites informations sont ainsi saisies sous la forme d’une entrée dans le module d’estimation, qui délivre à son tour la contribution de chaque utilisateur (4) au nouvel ensemble de données (l’ensemble de données qui résulte de toutes les transformations), voir la figure 2d.
Lesdits résultats peuvent être utilisés pour la rémunération de chaque utilisateur (4) qui a participé à la création du nouvel ensemble de données selon le montant de la participation.
La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. L’homme de métier comprendra que les caractéristiques techniques d’un mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d’un autre mode de réalisation à moins que l’inverse ne soit explicitement mentionné ou qu’il ne soit évident que ces caractéristiques sont incompatibles ou que la combinaison ne fournisse pas une solution à au moins un des problèmes techniques mentionnés dans la présente demande. De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l’inverse ne soit explicitement mentionné.
Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la protection demandée, et l'invention ne doit pas être limitée aux détails donnés ci-dessus.
Claims (39)
- REVENDICATIONS1. Infrastructure technique distribuée destinée à un système de plate-forme (1) de traçabilité de données basé sur des agents (DTP) comprenant au moins un serveur de base de métadonnées (2) à architecture en couches et à ressources de calcul, un serveur de surveillance de la qualité des données, un serveur de gestion pour un service d’approvisionnement en données (DPS), et une machine d’interrogation automatique, caractérisée en ce que la base de données (2) est utilisée pour stocker des données et conserver des preuves sécurisées de l’échange de données, de la propriété des données et du transfert de propriété des données dans des objets de données (DO) afin de permettre à un utilisateur (4) d’accéder à des ensembles de données (DOi.... DOn) fournis par d’autres utilisateurs, et de proposer un ensemble de données accessible par un autre utilisateur (4), et dans laquelle la plate-forme de traçabilité de données est configurée pour suivre de manière sécurisée la propriété d’un ensemble de données (DO) à stocker dans la base de données (2) et pour mettre en place un processus de consensus par fédération (FC) en adaptant la technologie de chaîne de blocs (22), un module de vote décidant de la validité d’un bloc afin de stocker le bloc dans la base de données (2) au cours dudit processus.
- 2. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que le module de vote de chaque agent de la plate-forme de traçabilité de données d’une « fédération DTP », pendant le consensus par fédération (FC), propose un vote individuel sur la validité, et le total cumulé des votes détermine la validité du bloc, au moins la taille et les participants à la fédération DTP et le seuil de validité étant paramétrables.
- 3. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que la technologie de chaîne de blocs (22) est adaptée pour comprendre un modèle prospectif permettant à un prestataire de service de fournir des informations orientées calcul, en stockant au moins les assertions d’une approche d’accès et de contrôle (AC) dans le cadre d’une transaction, contenant ainsi des informations purement prospectives sur le calcul qui spécifie la logique réelle exécutée.
- 4. Infrastructure technique distribuée selon les revendications 1 à 3, caractérisée en ce que la technologie de chaîne de blocs (22) est configurée, via la fonctionnalité de stockage et de consignation des données afin de maintenir les informations de traitement, pour comprendre un modèle rétrospectif.
- 5. Infrastructure technique distribuée selon les revendications 1 à 4, caractérisée en ce que la technologie de chaîne de blocs (22) est configurée pour comprendre un modèle pro-/rétrospectif mixte avec la fonctionnalité d’un système de gestion de processus distribué, la combinaison des informations pro- et rétrospectives permettant le suivi du calcul et l’évaluation de la fiabilité du résultat du calcul.
- 6. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce qu’elle comprend au moins une infrastructure de clés publiques (PKI) qui permet d’utiliser des outils cryptographiques asymétriques pour sécuriser les transactions d’un ensemble de données ou d’objets de données (DO) et suivre la propriété d’un ensemble de données.
- 7. Infrastructure technique distribuée selon la revendication 6, caractérisée en ce qu’une clé publique et privée unique est générée pour la création d’un compte d’agent, afin de permettre audit agent d’utiliser au moins un outil cryptographique asymétrique de l’infrastructure de clés publiques.
- 8. Infrastructure technique distribuée selon la revendication 7, caractérisée en ce que ladite clé publique et privée unique permet également audit agent d’agir comme une entité DTP active, qui est active dans une machine qui exécute une instance DTP et qui est responsable des actions de l’instance à l’aide des signatures numériques de toutes les communications qui utilisent ladite clé privée.
- 9. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce qu’elle comprend au moins un système d’accès et de contrôle (AC) qui maintient l’accès aux services disponibles et/ou qui contrôlent la création de services frauduleux au sein de la plate-forme, tandis que les droits d’accès sont spécifiés par chaque prestataire de service (3) qui crée une preuve de droit d’accès pour l’utilisateur concerné à l’aide des fonctionnalités de gestion des données de la chaîne de blocs, ledit système AC permettant une traçabilité inter- et intra-service si des assertions appropriées sont fournies par un prestataire de service (3).
- 10. Infrastructure technique distribuée selon la revendication 9, caractérisée en ce que le prestataire de service (3) spécifie, pour un service numérique consommable, à l’aide d’une interface interactive basée sur un navigateur Web, des métadonnées de provenance qui permettent une traçabilité inter-service et intra-service, et au moins des détails à propos du calcul effectué et des objets de données (DO) de sortie prévus.
- 11. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que la base de données (2) est conçue pour gérer les charges de travail élevées et les fonctionnalités en parallèle, ladite base étant distribuée avec des performances de correction linéaire, optimisées pour les opérations d’écriture.
- 12. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que la base de données (2) est Apache Cassandra.
- 13. Infrastructure technique distribuée selon la revendication 1 ou 11 ou 12, caractérisée en ce que la base de données (2) comprend au moins une couche de stockage comprenant au moins un stockage de groupe de transactions (20), un stockage de file d’attente de blocs (21), un stockage de chaîne de blocs (22), un stockage de blocs invalides, et un lac de données (24).
- 14. Infrastructure technique distribuée selon les revendications 1 et 13, caractérisée en ce que ladite couche de stockage comprend au moins un ensemble de modules : un module de groupe de transactions (20) destiné à traiter les transactions qui entrent dans le stockage de groupe de transactions (20) et vont être stockées dans les blocs de la file d’attente de blocs (21), un module de file d’attente de blocs (21) destiné à traiter les blocs qui ne sont pas encore validés et qui sont soumis au consensus pour la validation des blocs distribués, un module de chaîne à blocs (22) destiné à traiter les blocs validés, un module de dépôt de blocs invalides (23) destiné à traiter les blocs qui ont été validés comme étant invalides pendant la validation de blocs par consensus par un module de vote de blocs, un module de gestion de stockage destiné à stocker et à traiter des entités supplémentaires qui font partie des blocs et des transactions, notamment les votes qui sont requis pour le vote de blocs, des statuts de blocs utilisés pour persister le résultat d’un vote de validité de blocs et d’éléments de lac de données (DLE) (24) extraits pour améliorer les performances en raison de leur taille de données variable.
- 15. Infrastructure technique distribuée selon la revendication 14, caractérisée en ce que l’exécution du module de gestion du stockage permet au stockage de groupes de transactions (20) au moins de recevoir les transactions brutes entrantes, de vérifier les transactions à l’aide d’un algorithme de validation approfondie, d’affecter les transactions entrantes à un agent DTP par le biais d’une stratégie de sélection, et d’ajouter lesdites transactions vérifiées au stockage de groupes de transactions (20).
- 16. Infrastructure technique distribuée selon la revendication 15, caractérisée en ce que l’algorithme de validation approfondie (DV) permet de valider par la suite des données arbitraires par toutes les couches architecturales DTP, en validant ainsi les données éventuellement imbriquées en profondeur, pendant que la logique de validation est fournie par le biais de « validateurs » qui ont exécuté la validation sous une forme sémantiquement capsulée optimisée pour une exécution simultanée.
- 17. Infrastructure technique distribuée selon les revendications 14 et 15, caractérisée en ce que le module de groupes de transactions (20) identifie les transactions vérifiées à l’aide de l’agent DTP assigné qui est responsable de l’exécution du module de groupes de transactions, crée des blocs en utilisant l’autorisation des transactions, transmet les blocs à stocker dans la file d’attente de blocs (21), et supprime les transactions utilisées du stockage de groupes de transactions (20).
- 18. Infrastructure technique distribuée selon les revendications 1 à 17, caractérisée en ce que l’exécution du module de vote permet au moins de vérifier si I’ « ID » (identité) d’un agent se trouve dans une liste de votants stockée dans la couche de stockage de la base de données, d’exécuter un processus de validation approfondie pour déterminer la validité d’un bloc, d’ajouter un vote au bloc correspondant au résultat de la validation, et de déclencher ou non une minuterie pour chaque vote manquant.
- 19. Infrastructure technique distribuée selon les revendications 1 et 13, caractérisée en ce que la couche de stockage comprend au moins :• une liste des agents et des services qui existent sur la plate-forme. Lesdits agents et services ont été créés et stockés dans un bloc qui a été validé. Ladite liste tient compte de tous les états créés, désactivés et supprimés.• une mémoire cache (BBC) de blocs de chaîne de blocs (22), qui est une mémoire cache d’un certain nombre de blocs, pour lesquels une décision a été prise (stockés dans la chaîne de blocs (22) ou dans le dépôt de blocs invalides (23)), qui sont conservés en mémoire pour des raisons de performances. Ladite mémoire cache est matérialisée comme une file d’attente limitée en taille (paramètre de configuration) qui utilise des HashMaps sous-jacents pour une recherche efficace d’au moins tous les ID de blocs (identités de blocs), ID de transactions • une mémoire cache de blocs de consensus (CBC), qui est analogue à la mémoire cache de chaîne de blocs (22) et qui est utilisée pour les blocs pour lesquels aucune décision n’a été prise.• une liste de vote, conservée par chaque agent, qui comprend les blocs pour lesquels un vote est exigé par l’agent correspondant, c’est-à-dire lorsque l’ID de l’agent a été ajouté à la liste des « agents votants » du bloc (ID des agents qui doivent fournir un vote), mais qu’aucun vote n’a encore été fourni ;• une mémoire cache de groupes de transactions (PTC), qui conserve les transactions issues du groupe de transactions (20).• une liste d’autorisations de transaction (TLC). Ladite liste contient au moins les informations suivantes afin de décider si une transaction peut être ajoutée à un bloc destiné à être stocké :une transaction précédente (le cas échéant) est stockée dans un bloc validé- un agent émetteur d’une transaction n’est pas placé sur liste noire toutes les données (DLE, agent, etc.) sont disponibles dans le système afin de procéder à leur vérification.
- 20. Infrastructure technique distribuée selon les revendications 1 et 13, caractérisée en ce que la couche de traçabilité comprend au moins un module « agents » destiné à stocker le modèle de données d’agent de traçabilité, un module d’objets de données (DO) destiné à stocker le modèle de données des objets de données de traçabilité (DO), un module « service » destiné à stocker le modèle de données du service de traçabilité, et un module « transactions » destiné à stocker les transactions de la couche de traçabilité.
- 21. Infrastructure technique distribuée selon la revendication 20, caractérisée en ce que les entités de traçabilité sont également identifiées par un « ID statique » qui ne change pas pendant une mise à jour et comprend au moins :5 · Propriétaire de l’agent (AgentOwner) :« agent_owner_id » (ID unique) • Agent : « agent_id » (clé publique) • Service : « service_id » (ID unique) + « service_version »10
- 22. Infrastructure technique distribuée selon la revendication 19, caractérisée en ce que, dans la couche de stockage, au moins l’une des requêtes suivantes est prise en considération pour garantir le traitement efficace des informations liées à un bloc :• Obtention des blocs par ID ;• Obtention de l’heure de création des blocs ;• Obtention des transactions du stockage par ID de bloc ;• Obtention des informations de statut par ID de bloc ;• Obtention des votes par ID de bloc ;• Obtention du DLE par ID de transaction du stockage20
- 23. Infrastructure technique distribuée selon les revendications 20 et21, caractérisée en ce que les requêtes suivantes sont prises en considération pour la traçabilité des données dans la couche de traçabilité, qui sont réalisées en tant que requêtes de base de données avec les informations correspondantes :25 · Obtention de la transaction à tracer par ID d’objet de donnée ;• Obtention de la transaction à tracer par ID de service ;• Obtention des agents par ID de transaction à tracer;• Obtention des services par ID de transaction à tracer ;• Obtention des agents par ID de propriétaire d’agent ;• Obtention des services par ID de service.
- 24. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le module de vote, ayant des performances élevées et une fonctionnalité de paramétrabilité, permet:• d’ajuster le vote selon une taille de fédération réduite, avec un temps-système de vote réduit et des latences de stockage correspondantes réduites, • de stocker instantanément le vote sans que la conception architecturale exige une durée de stockage minimale.
- 25. Infrastructure technique distribuée selon la revendication 24, caractérisée en ce que la technologie de couche de stockage de la base de données est configurée pour mettre à l’échelle sa conception architecturale et obtenir un débit de stockage total élevé.
- 26. Infrastructure technique distribuée selon les revendications 1 et 24, caractérisée en ce que la fonctionnalité de paramétrabilité de l’infrastructure technique distribuée est assurée par un programme et des fichiers de configuration propres aux couches, chaque couche de ladite infrastructure étant apte à fournir des configurations individuelles.
- 27. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le service d’approvisionnement en données (DPS) conserve des preuves d’activité de manière transparente pour l’utilisateur.
- 28. Infrastructure technique distribuée selon les revendications 1 et 28, caractérisé en ce que le service d’approvisionnement en données (DPS) maintient l’activité de fourniture de données, qui requiert d’indiquer les métadonnées connexes comme les références aux ensembles de données utilisés des autres.
- 29. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le service d’approvisionnement en données (DPS) conserve l'historique complet d’un ensemble de données en analysant les preuves et en suivant les références au sein des métadonnées afin de permettre le suivi de l’historique complet d’un ensemble de données, et d’identifier tous les utilisateurs qui peuvent contribuer à sa création.
- 30. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le service d’approvisionnement en données (DPS) est configuré pour étendre la fonctionnalité de propriété pure via des opérations de maintien d’ensembles de données sur la plate-forme.
- 31. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que la plate-forme (1) est configurée pour recevoir une requête en provenance d’un service d’analyse de données complexes, ledit service d’analyse utilisant des modèles d’apprentissage machine (ML) et des ensembles de données d’apprentissage disponibles sur la plate-forme (1) afin d’offrir un service d’analyse par apprentissage machine.
- 32. Infrastructure technique distribuée selon la revendication 5, caractérisé en ce que le système comprend :• une chaîne de blocs (22) ; et • une ressource de calcul prévue pour exécuter une boucle de sorte que l’exécution de la boucle soit influencée par l’état de la chaîne de blocs (22), la boucle étant mise en œuvre à l’aide d’un script, afin de conserver un décompte d’un ou plusieurs votes pour la validation des blocs liée au consensus, la validité des blocs ou les décisions de validité des blocs, et un statut de bloc correspondant généré pour ou associé au bloc extrait de la file d’attente de blocs (21) ; et un ensemble de conditions d’invalidité définies par la fédération afin de déterminer la validité des blocs, et validées par chaque agent qui participe à un vote sont évaluées et au moins une action est menée sur la base du résultat de l’évaluation ; ladite action comprenant au moins:- faire qu’au moins une transaction soit écrite dans le volume de chaîne de blocs (22) de la base de données (2) ; et/ou- faire qu’une action hors chaîne de blocs soit exécutée.
- 33. Infrastructure technique distribuée selon la revendication 1 à 31, caractérisé en ce que, pour chaque itération de la boucle, un hachage cryptographique du script est généré, et les informations relatives à au moins une itération de la boucle sont stockées dans une transaction sur la chaîne de blocs (22), les informations étant stockées sous la forme de métadonnées dans la transaction.
- 34. Infrastructure technique distribuée selon la revendication 1 à 32, caractérisé en ce que les conditions concernent les données reçues, et les changements de propriété détectés ou générés par la ressource de calcul ; ou l’état de la chaîne de blocs (22).
- 35. Infrastructure technique distribuée selon les revendications 1 à 33, caractérisée en ce que la base de données (2) offre un moyen d’identification des processus liés au stockage du groupe de transactions (20), à la file d’attente de blocs (21), à la chaîne de blocs (22) et au dépôt des blocs invalides (23), à la gestion des blocs, aux agents, aux objets de données, aux services et à la traçabilité des transactions.
- 36. Infrastructure technique distribuée selon la revendication 1 à 34, caractérisé en ce que les processus de stockage de la base de données (2) et de consensus par chaîne de blocs (22) constituent chacun une couche de l’architecture qui peut être supprimée, remplacée ou étendue avec d’autres caractéristiques.
- 37. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que la plate-forme de traçabilité des données comprend au moins un module d’estimation, ledit module comprenant au moins un ensemble de modèles et de programmes destinés à estimer la contribution de différents ensembles de données pour la création d’un nouvel ensemble et, ainsi, à estimer un barème de rémunération équitable pour la réutilisation de l’ensemble de données.
- 38. Infrastructure technique distribuée selon la revendication 37, caractérisée en ce que l’ensemble de modèles et de programmes du module5 d’estimation comprend au moins un modèle d’estimation de valeur de Shapley, ladite valeur de Shapley estimant la valeur d’un ensemble de données et/ou la contribution relative d’ensembles de données d’entrée à la valeur de l’ensemble de données résultant.
- 39. Infrastructure technique distribuée selon les revendications 37 et10 38, caractérisée en ce que le module d’estimation est utilisé pour la rémunération de chaque utilisateur (4) qui a participé à la création du nouvel ensemble de données selon le montant de la participation.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1761423A FR3074322B1 (fr) | 2017-11-30 | 2017-11-30 | Plate-forme de tracabilite securisee de donnees |
| PCT/EP2018/083221 WO2019106186A1 (fr) | 2017-11-30 | 2018-11-30 | Plate-forme de tracabilite securisee de donnees |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1761423A FR3074322B1 (fr) | 2017-11-30 | 2017-11-30 | Plate-forme de tracabilite securisee de donnees |
| FR1761423 | 2017-11-30 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3074322A1 true FR3074322A1 (fr) | 2019-05-31 |
| FR3074322B1 FR3074322B1 (fr) | 2021-04-16 |
Family
ID=62143240
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1761423A Active FR3074322B1 (fr) | 2017-11-30 | 2017-11-30 | Plate-forme de tracabilite securisee de donnees |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3074322B1 (fr) |
| WO (1) | WO2019106186A1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111563103A (zh) * | 2020-04-28 | 2020-08-21 | 厦门市美亚柏科信息股份有限公司 | 一种用于数据血缘检测方法和系统 |
| CN111737352A (zh) * | 2020-06-23 | 2020-10-02 | 四川长虹电器股份有限公司 | 一种基于区块链的供应链信息协同管理方法 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110855761B (zh) * | 2019-10-29 | 2021-09-21 | 深圳前海微众银行股份有限公司 | 一种基于区块链系统的数据处理方法及装置 |
| EP3913485A1 (fr) | 2020-05-20 | 2021-11-24 | Cleverdist SA | Procédé et plate-forme informatique permettant de commander le partage de flux de données échangés entre plusieurs organisations |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017109140A1 (fr) * | 2015-12-22 | 2017-06-29 | Bigchaindb Gmbh | Système de base de données orienté vers les actifs, inviolable et décentralisé et procédé d'enregistrement d'une transaction |
| US20170323392A1 (en) * | 2016-05-05 | 2017-11-09 | Lance Kasper | Consensus system for manipulation resistant digital record keeping |
-
2017
- 2017-11-30 FR FR1761423A patent/FR3074322B1/fr active Active
-
2018
- 2018-11-30 WO PCT/EP2018/083221 patent/WO2019106186A1/fr active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017109140A1 (fr) * | 2015-12-22 | 2017-06-29 | Bigchaindb Gmbh | Système de base de données orienté vers les actifs, inviolable et décentralisé et procédé d'enregistrement d'une transaction |
| US20170323392A1 (en) * | 2016-05-05 | 2017-11-09 | Lance Kasper | Consensus system for manipulation resistant digital record keeping |
Non-Patent Citations (2)
| Title |
|---|
| ANONYMOUS: "The Apache Software Foundation Announces Apache Cassandra Release 0.6 : The Apache Software Foundation Blog", 13 April 2010 (2010-04-13), XP055505814, Retrieved from the Internet <URL:https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces3> [retrieved on 20180910] * |
| TRENT MCCONAGHY ET AL: "BigchainDB: A Scalable Blockchain Database", 8 June 2016 (2016-06-08), XP055340139, Retrieved from the Internet <URL:https://www.bigchaindb.com/whitepaper/bigchaindb-whitepaper.pdf> [retrieved on 20180909] * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111563103A (zh) * | 2020-04-28 | 2020-08-21 | 厦门市美亚柏科信息股份有限公司 | 一种用于数据血缘检测方法和系统 |
| CN111563103B (zh) * | 2020-04-28 | 2022-05-20 | 厦门市美亚柏科信息股份有限公司 | 一种用于数据血缘检测方法和系统 |
| CN111737352A (zh) * | 2020-06-23 | 2020-10-02 | 四川长虹电器股份有限公司 | 一种基于区块链的供应链信息协同管理方法 |
| CN111737352B (zh) * | 2020-06-23 | 2021-12-21 | 四川长虹电器股份有限公司 | 一种基于区块链的供应链信息协同管理方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2019106186A1 (fr) | 2019-06-06 |
| FR3074322B1 (fr) | 2021-04-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11875400B2 (en) | Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (DLT) | |
| Shrestha et al. | A blockchain platform for user data sharing ensuring user control and incentives | |
| US11632238B2 (en) | Traceability of edits to digital documents via distributed ledgers | |
| US11876910B2 (en) | Systems, methods, and apparatuses for implementing a multi tenant blockchain platform for managing Einstein platform decisions using distributed ledger technology (DLT) | |
| US11709819B2 (en) | Validating test results using a blockchain network | |
| US20200162266A1 (en) | Facilitating analytic services for provenance of digital documents | |
| Wilkinson et al. | Metadisk a blockchain-based decentralized file storage application | |
| US9229997B1 (en) | Embeddable cloud analytics | |
| Zeng et al. | An IoT and Blockchain‐based approach for the smart water management system in agriculture | |
| WO2019106186A1 (fr) | Plate-forme de tracabilite securisee de donnees | |
| US20200143242A1 (en) | System and method for creating and providing crime intelligence based on crowdsourced information stored on a blockchain | |
| US11954094B2 (en) | Database system public trust ledger architecture | |
| Nazir et al. | Cloud computing applications: a review | |
| CN115769206A (zh) | 密码化数据录入区块链数据结构 | |
| US10162876B1 (en) | Embeddable cloud analytics | |
| Umekwudo et al. | Blockchain technology for mobile applications recommendation systems | |
| US11880372B2 (en) | Distributed metadata definition and storage in a database system for public trust ledger smart contracts | |
| US20230368185A1 (en) | Public trust ledger smart contract token transfer in a database system | |
| US11989726B2 (en) | Database system public trust ledger token creation and exchange | |
| US20230085481A1 (en) | Database system public trust token redeem architecture using wallets | |
| US20220027260A1 (en) | Automatically capturing weather data during engineering tests | |
| Desai | New recordkeeping on the block: An assessment of 2 blockchain-based recordkeeping systems | |
| US11792136B1 (en) | Systems and methods for blockchain network optimization | |
| US20230367766A1 (en) | Environmental impact tracking in public trust ledger actions via a database system | |
| US20230328098A1 (en) | Systems and methods for identifying patterns in blockchain activities |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLSC | Publication of the preliminary search report |
Effective date: 20190531 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |