WO2019106186A1 - Plate-forme de tracabilite securisee de donnees - Google Patents

Plate-forme de tracabilite securisee de donnees Download PDF

Info

Publication number
WO2019106186A1
WO2019106186A1 PCT/EP2018/083221 EP2018083221W WO2019106186A1 WO 2019106186 A1 WO2019106186 A1 WO 2019106186A1 EP 2018083221 W EP2018083221 W EP 2018083221W WO 2019106186 A1 WO2019106186 A1 WO 2019106186A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
block
transaction
technical infrastructure
service
Prior art date
Application number
PCT/EP2018/083221
Other languages
English (en)
Inventor
Tobias Rene MAYER
Yacine KESSACI
Frédéric OBLE
Original Assignee
Worldline
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Worldline filed Critical Worldline
Publication of WO2019106186A1 publication Critical patent/WO2019106186A1/fr

Links

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

Definitions

  • the present invention relates to the field of data management, and more specifically to a platform for securing and monitoring the exchange of data.
  • Custom ads based on user profiles are an example.
  • vendors can offer machine learning (ML) calculation models, training data sets and ready-to-use machine learning models. And “consumers” buy this data for personal use.
  • Machine learning models and training data have some inherent value. Trained machine learning models create value by combining existing data from other vendors, that is, applying training datasets for a significant amount of time.
  • data providers must be rewarded if their data has been used to create a new data set that is sold on the platform, such as trained machine learning models.
  • simple reuse of data is a threat to intellectual property.
  • a dishonest user may, for example, slightly modify the data set (thereby bypassing the classical integrity checks) and propose the "new" dataset itself.
  • the present invention aims to overcome certain disadvantages of the prior art by providing a means for securing and managing the data exchange.
  • DTP agent-based data traceability platform
  • DTP data traceability platform
  • DPS data provisioning service
  • the database being used for storing data and keeping secure evidence of the exchange data, data ownership and transfer of ownership of data in data objects (DOs) to allow a user to access data sets (DOi , ..., DO n ) provided by d other users, and to propose a set of data accessible by another user
  • the data traceability platform is configured to set up a process by federation (FC) by adapting the blockchain technology (22), a voting module deciding the validity of a block in order to store the block in the database (2) during said process
  • the database being characterized in that it comprises a traceability layer comprising a set of modules whose execution allows the traceability of data, the data traceability platform being configured by implementing at least one prospective-retrospective model the blockchain technology for securely tracking the ownership
  • the voting module of each agent of the data traceability platform of a "DTP federation" during the consensus by federation (FC), proposes an individual vote on the validity, and the cumulative total of the votes determines the validity of the block, at least the size and the participants in the DTP federation, and the threshold of validity being configurable.
  • the blockchain technology is configured to include a prospective model whose implementation allows a service provider to provide computationally-oriented information, storing at least the assertions of an access-and-access approach. control (AC) as part of a transaction, thus containing purely forward-looking information on the calculation that specifies the actual logic executed.
  • AC access-and-access approach.
  • the blockchain technology is configured, via the data storage and logging functionality to maintain the processing information, to include a retrospective model whose implementation can capture at least the information pertaining to the data. annotations on data flows and transformations made on the data.
  • the blockchain technology is configured to understand the prospective-retrospective mixed model with the functionality of a distributed process management system (WMS), the implementation of said model allowing the combination of the pro and retrospectives for the monitoring of the calculation and the evaluation of the reliability of the calculation result, the prospective information being obtained by capturing or recording information describing the data processing process.
  • WMS distributed process management system
  • the distributed technical infrastructure includes at least one public key infrastructure (PKI) that allows asymmetric cryptographic tools to be used to secure the transactions of a set of data or data objects (DOs) and follow the property of a dataset.
  • PKI public key infrastructure
  • a unique public and private key is generated for the creation of an agent account, in order to enable said agent to use at least one asymmetric cryptographic tool of the public key infrastructure.
  • said unique public and private key also enables said agent to act as an active DTP entity, which is active in a machine that executes a DTP instance and is responsible for the actions of the instance using the digital signatures of all communications that use said private key.
  • the distributed technical infrastructure includes at least one access and control system (AC) that maintains access to available services and / or controls the creation of fraudulent services within the platform, while the access rights are specified by each service provider who creates access right evidence for the relevant user using the data management features of the blockchain.
  • AC access and control system
  • the AC system allows inter and intra-service traceability if appropriate assertions are provided by a service provider.
  • the service provider specifies, for a consumable digital service, using an interactive interface based on a web browser, provenance metadata that allows for inter-service and intra-service traceability, and less details about the calculation performed and the expected output data objects (DOs).
  • provenance metadata that allows for inter-service and intra-service traceability, and less details about the calculation performed and the expected output data objects (DOs).
  • the database is distributed with linear correction performance, optimized for write operations and designed to handle high workloads and parallel functionality.
  • the database is Apache Cassandra.
  • the database comprises at least one storage layer comprising at least one storage of groups of transactions, block queue storage, block chain storage, invalid block storage, and a data lake.
  • said storage layer comprises at least one set of modules: a transaction group module intended to process the transactions that enter the storage of transaction groups and will be stored in the blocks of the queue of blocks, a block queue module for processing the blocks which are not yet validated and which are submitted to the consensus for validation of the distributed blocks, a block chain module for processing the validated blocks, a block module an invalid block deposition module for processing blocks that have been validated as invalid during block validation by consensus by a block voting module, a storage management module for storing and processing additional entities that make part of the blocks and transactions, including the votes that are required for block voting, block statuses used to persist the result t a block validity vote, and extracted data lake (DLE) elements to improve performance because of their variable data size.
  • a transaction group module intended to process the transactions that enter the storage of transaction groups and will be stored in the blocks of the queue of blocks
  • a block queue module for processing the blocks which are not yet validated and which are submitted to the consensus for validation of the distributed blocks
  • a block chain module for processing the validated
  • the execution of the storage management module allows the storage of transaction groups at least to receive the incoming raw transactions, to verify the transactions using a deep validation algorithm, to affect the transactions. incoming transactions to a DTP agent through a selection strategy, and to add said verified transactions to the storage of transaction groups.
  • the deep validation makes it possible subsequently to validate arbitrary data by all the DTP architectural layers, thus validating the data possibly nested in depth, while the validation logic is provided by means of " validators "that performed validation in a semantically capsulated form optimized for concurrent execution.
  • the transaction group module identifies the verified transactions with a large margin using the assigned DTP agent that is responsible for running the transaction group module, creates blocks using transaction authorization, passes the blocks to be stored in the block queue, and deletes the used transactions from the storage of transaction groups.
  • the execution of the voting module makes it possible at least to check whether the "ID" of an agent is in a list of voters stored in the storage layer of the database, to execute a thorough validation process to determine the validity of a block, add a vote to the block corresponding to the result of the validation, and trigger or not a timer for each vote missing.
  • the storage layer comprises at least:
  • a Block Chain Block Cache which is a cache of a number of blocks, for which a decision has been made (stored in the blockchain or in the invalid block repository), that are kept in memory for performance reasons.
  • the cache memory is materialized as a size-limited queue (configuration parameter) that uses underlying HashMaps for efficient search of at least all block IDs (block identities), transaction IDs;
  • CBC Consensus Block Cache
  • PTC transaction cache
  • TLC transaction authorizations
  • the traceability layer comprises at least one "agents” module intended to store the traceability agent data model, a data object module (DO) intended to store the data model of the traceability objects.
  • traceability data DO
  • service module for storing the traceability service data model
  • transactions module for storing the traceability layer transactions.
  • the traceability entities are also identified by a "static ID" that does not change during an update and includes at least:
  • Agent Owner "agent_owner_id” (unique ID)
  • Agent "agentjd” (public key)
  • At least one of the following queries is taken into consideration for the traceability of the data in the traceability layer, which are carried out as database queries with the corresponding information:
  • the voting module having high performance and a parameterability functionality, allows:
  • the storage layer technology of the database is scaled by design to achieve a high total storage rate.
  • the parameterizable functionality of the distributed technical infrastructure is provided by a program and configuration files specific to the layers, each layer of said infrastructure being able to provide individual configurations.
  • the Data Provisioning Service keeps evidence of activity transparently to the user.
  • the Data Provisioning Service maintains the data delivery activity, which requires the indication of related metadata, such as references to the data sets used by the others.
  • the Data Provisioning Service maintains the complete history of a dataset by analyzing evidence and following the references within the metadata to allow tracking of the complete history of the dataset. 'a set of data, and to identify all the users who can contribute to its creation.
  • DPS Data Provisioning Service
  • the platform receives a request from a complex data analysis service using machine learning (ML) models and training data sets available on the platform to offer a machine learning analysis service.
  • ML machine learning
  • the system comprises:
  • a cryptographic hash of the script is generated, and the information relating to at least one iteration of the loop is stored in a transaction on the blockchain; the information is stored as metadata in the transaction.
  • the conditions concern the data received, and the property changes detected or generated by the computing resource; or the state of the block chain.
  • the database provides a means of identifying the processes related to the storage of the transaction group, the block queue, the blockchain and the depot of the invalid blocks, the management of the blocks, agents, data objects, services and transaction traceability.
  • the database storage and blockchain consensus processes each constitute a layer of the architecture that can be dropped, replaced or expanded with other features.
  • the data traceability platform comprises at least one estimation module, said module comprising at least one set of models and programs intended to estimate the contribution of different data sets for the creation of a data module. new set and thus to estimate a fair remuneration scale for the reuse of the dataset.
  • the set of models and programs comprises at least one Shapley value estimation model, said Shapley value estimating the value of a set of data and / or the relative contribution of data sets. input to the value of the resulting dataset.
  • the estimation module is used for the remuneration of each user who participated in the creation of the new data set according to the amount of participation.
  • FIG. 1 is a schematic representation of the elements of the distributed database (2).
  • FIGS. 2a, 2b, 2c and 2d are diagrammatic representations, respectively, of a data provider (3) which creates a service using the data traceability platform (1) (DTP), a data provider (3) that provides a service to a data consumer using the data traceability platform, and the process of tracing the use of data consumed using the data traceability platform; data traceability and platform utilization platform for estimating the relative contribution of the input data sets to the value of the resulting data set, according to one embodiment;
  • DTP data traceability platform (1)
  • FIG. 3 is a representation of tables containing the attributes relating to a data object, according to one embodiment
  • FIG. 4 is a representation of tables containing the attributes relating to a block, according to one embodiment
  • FIG. 5 is a representation of tables containing the attributes relating to the transaction group of the storage layer, according to one embodiment
  • FIG. 6 is a representation of tables containing the attributes relating to the block queue of the storage layer, according to one embodiment
  • FIGS. 7a and 7b are representations of tables containing attributes relating respectively to storage management and block voting, according to one embodiment
  • FIG. 8 is a representation of tables containing the attributes relating to the transactions in the storage layer, according to one embodiment
  • FIG. 9 is a representation of tables containing attributes relating to the "owner of an agent" of the traceability layer, according to one embodiment.
  • FIG. 10 is a representation of tables containing the attributes relating to an "agent" of the traceability layer, according to one embodiment
  • FIG. 11 is a representation of tables containing the attributes relating to the "services" of the traceability layer, according to one embodiment
  • FIG. 12 is a representation of tables containing the attributes relating to transactions of the traceability layer, according to one embodiment.
  • the present invention relates to a distributed technical infrastructure for tracking data.
  • the distributed technical infrastructure for a (DTP) based data traceability platform (1) system includes at least one layered architecture metadata base server (2) (FIG. 1) and computing resources, a data quality monitoring server, a management server for a data provisioning service (DPS), and a automatic polling machine, the database (2) being used for storing data and maintaining secure evidence of data exchange, data ownership and data transfer in data objects (DO ) to allow a user (4) to access data sets (DOi , ..., DOn) provided by other users, and to provide a set of data accessible by another user (4), and wherein the data traceability platform is configured to set up a consensus federation (FC) process by adapting the blockchain technology (22), a voting module determining the validity of a block to store the block in the database (2) during said process.
  • FC consensus federation
  • the database is characterized in that it comprises a traceability layer comprising a set of modules whose execution allows the traceability of the data, the data traceability platform being configured by implementing at least one pro / retrospective model or prospective-retrospective mixed or to follow securely the property of a set of data (DO) to be stored in the database (2)
  • the platform (1) (DTP) may comprise at least one set of layers and at least:
  • a central layer that maintains the layers of the platform (1) and allows all layers to access the controllers of the other layers.
  • a network layer that maintains a list of peers that are currently online. Thus, a higher layer can check if a peer and its services are currently online. The network layer does not know the upper layers. However, a network parameter "PeerProfile" is prepared with an agent and a signature field. This activates the link between a peer and a platform agent, and cryptographic integrity.
  • a template may be defined by a module or program or a set of programs to be run on at least one processor of the distributed technical infrastructure.
  • agent refers to the smallest autonomous entity of the platform (1) that proposes and / or uses the services of the platform (1).
  • Agent is further characterized by the following:
  • agent is a kind of software application that interacts with the platform (1) and includes the related communication logic and the collaborative protocol;
  • Agent an application
  • software logic such as a database daemon (2), a data analysis controller, a software agent
  • This logic can be integrated with embedded hardware (such as smart sensors).
  • Agent Machine The agent machine is the computer on which the agent application is running. For the sake of simplicity, we assume an agent application running on a dedicated machine. An agent machine can be linked to other machines to more efficiently serve the service (such as a massive data server cluster). These machines serve only as support for the execution of the agent's service, and are not directly connected to the platform.
  • Agent Legal Representative each agent has only one person who acts as legal representative, and who is responsible for 1) the agent's operations on platform (1) and 2) cash transfers. , like the payment of a service. For the sake of simplicity, we assume that these two responsibilities are assumed by one person, while several agent machines may have the same legal agent representative.
  • Platinum Agent (1) this is a special agent who works on behalf of the Platform Provider (1) (3, Figures 2a, 2b) and who focuses on the availability and accuracy of the service available. For example, it performs proof checks (for example, provenance metadata) and supports certain operations, such as data dissemination and caching.
  • proof checks for example, provenance metadata
  • service refers to a set of “operations” proposed by an agent, the “service provider (3, Figures 2a, 2b)" or the data provider, to another agent, the “service consumer”.
  • Service consumption refers to the fact that the consumer of a service (or the user of a service (4, Figures 2b, 2c), or a data consumer) uses a specific operation proposed by the service provider (3).
  • service or the user of a service (4, Figures 2b, 2c), or a data consumer
  • Some of the terms related to a service offered on the platform (1) are, for example and without limitation, the following:
  • the activity includes:
  • service metadata describes the service and the corresponding service activity. Specifically, it contains (if provided by the agent) detailed provenance metadata to enable the traceability of data objects as a service (such as processing scripts in source code for the creation of the data object).
  • service entry refers to data objects (own or from other services) used as input for the execution of a service operation by the service provider (3). In terms of programming languages, this represents the input parameters of a data processing method.
  • out of service refers to the result of the service activity that is transmitted to the service consumer. It includes at least one status code and usually one or more data objects as well.
  • service type defines the way services are run. Two ways are possible: - A "pull service", which is reactively executed. The consumer of a service issues a service call to a service provider (3) in order to consume the proposed service. The provider (3) performs the service activity and returns the service to the consumer.
  • the service consumer subscribes to a specific service by issuing a service call.
  • the service provider (3) performs the service and provides the service on the basis of an event or periodically.
  • data object refers to an entity that encapsulates data for an exchange between agents in the context of service entry or service exit.
  • the "data object origin” specifies how the data object was created. It usually refers to a service transaction and, thus, to a specific service / agent, where the actual creation is to be described through provenance metadata.
  • agents can also create a data object for the service entry (possibly using another data object and external resources). In this case, the agent should ideally provide the corresponding source metadata in the same manner as the service provider (3).
  • a data object can be one of the following "data object types":
  • Data object metadata describes the data object and its context. They contain, among other things, the type of object of data, the date and time of creation, the service responsible for creation, the service provider (3), the information on integrity and security (checksums, digital signatures, etc.), and the identification of the owner (see Figure 3).
  • the provenance indicates, from a point of view or a top-down approach, the possibility (or ability) to derive the data history over the calculation steps during processing, starting with the initial sources. Conversely, we consider traceability as having bottom-up characteristics, indicating the ability (or ability) to track relationships between data and data changes to determine provenance processes. Therefore, we consider traceability by indicating the technical aspects of data association, while provenance addresses the overall concept of determining provenance information (such as the processes of return to the initial creation of data).
  • a provenance system is, in general, characterized by at least three main characteristics: the orientation of the provenance, the model and the mechanisms of capture.
  • the direction of provenance can be data oriented or computationally oriented.
  • the source system captures information about the flow and transformation of the data.
  • the captured information is the details of the data transformation (data processing).
  • the provenance model used to capture the information is generally of two types: retrospective and prospective.
  • RPM retrospective model
  • annotations on data flow and transformation are recorded.
  • the retrospective model can retain annotations on the data and / or their processing.
  • PPM prospective model
  • offers a "recipe" a set of steps, a method, (7) that describes how to process the data.
  • a prospective model is generally treatment-oriented in order to easily repeat the same calculation.
  • the data traceability platform puts in place implement a retrospective model by automatically retaining the proofs of the interactions (the proofs of consumption of a service are for example preserved by means of the "transaction of traceability", which contains detailed information on the supplier, the consumer, the service, etc.), which are cryptographically secured to ensure data protection.
  • Capture mechanisms essentially used in a provenance system, are mechanisms that rely on processes and / or operating systems.
  • Process-based mechanisms are closely linked to process management systems (WMS).
  • WMS process management systems
  • Mechanisms that rely on processes record computational information from within an application, that is, they require a clean process to document computational tasks.
  • Mechanisms that rely on an operating system do not require any changes to the application itself. They use the features or features of an operating system (or environment through wrappers) to capture the data. Thus, the execution processes of an application are considered a black box, while the input and output can be captured.
  • a graphical representation is a common visualization and is used by mechanisms that rely on a process management system and an operating system. However, they present fundamentally different approaches.
  • Origin systems that rely on treatment are promising candidates, however.
  • an agent specifies the processing of data through assertions, and indicates with metadata the relationships with other sets of input data. It is also an organized and decentralized process management system that focuses on processing while also capturing processes. Adequate processing can then be verified through controls, with a particular set of data.
  • a block chain system (22) is adapted to provide several advantages in terms of provenance and traceability.
  • the blockchain (22) is not a conventional source system, but rather a type of distributed database (2).
  • the blockchain (22) is capable of securely storing information through cryptographic evidence without the need for a central (trusted) instance.
  • the blockchain (22) (see Figure 1) stores information as blocks, which are concatenated into a string and stored in a distributed manner. Each block has a reference to the previous block, which allows to cross the entire chain from the last block. Since new blocks can be added at the same time, "ramifications" can appear, and generate several last blocks. Only one string can be valid to guarantee a single last block, and is determined by a consensus protocol. Each block includes several transactions, which are secured with a asymmetric cryptography.
  • Each new transaction is validated by the owner of the current transaction, which creates a validated transaction chain.
  • the owner of a current transaction digitally signs a hash value of the new transaction.
  • the hash value uses the current transaction and the public key of the owner of the new transaction as input. It is important to note that the block chain (22) is devoid of state. The transactions stored in a block are the only existing state.
  • transaction generally refers to all messages exchanged to ensure the consumption of a service.
  • a transaction as for the databases (2), is either executed in full (successful consumption of the service, with all the related message exchanges), or in failure (no consumption of service).
  • hash refers to the value returned by a hash function.
  • a hash function is any function that can be used to map data of arbitrary size to fixed size data.
  • Hash table An example of use is a data structure called "hash table", widely used in computer software to quickly search for data.
  • Hash functions speed up search in a table or database (2) by detecting duplicate records in a large file.
  • They are also useful for cryptography.
  • a cryptographic hash function makes it easy to verify that some input data is mapped to a given hash value, but if the input data is unknown, it is deliberately difficult to reconstruct (or otherwise) it by knowing the hash value stored. This is used to guarantee the integrity of the transmitted data.
  • Creating a block capable of storing transactions in the blockchain (22) requires solving a certain puzzle Cryptographic.
  • this consists in finding certain nonce values (random or pseudo-random number intended to be used once) so that the hash value for the transactions to be stored starts with a group of zeros. This is also referred to as "mining"(Bitcoin); the miner is rewarded with bitcoins for his computation efforts.
  • a new block, if checked by other explorers, is then added to the block chain (22), which serves as the storage confirmation for the associated transactions.
  • a block is defined by a table (see Figure 4) that contains the following attributes (ID, timestamp, status, dm_version, payload, creator, voters, comment, signature, ID of the previous block)
  • the Federation Consensus (FC) of the present invention is very different from other block validity approaches, including the proof-of-operation approach which uses the calculation of a valid block through a "block mining” (by solving a puzzle), during which the validity of a block is verified individually by each user of the block chain.
  • the federation consensus of the present invention functions as a pure distributed system, in which the voting module of each data traceability platform agent (active entity of a traceability platform instance) data) of a "platform federation" (a subset of all available platform agents) proposes an individual vote on the validity, and the total ultimately accumulated votes determines the validity of the block.
  • Transactions also include transaction scripts that must be run smoothly in order to be accepted into a block.
  • the transaction scripts typically check the hash values and transaction signatures (represented by a specified transaction parameter "pay-to-pub-key-hash").
  • the scripting language used has almost 200 commands, called “opcodes”, which include support for cryptographic operations. This allows complex logic for storing transactions.
  • a blockchain (22) may also include at least one peer-to-peer (P2P) communication module that manages at least the distribution of blocks on the platform (1) and / or transactions.
  • P2P peer-to-peer
  • the above features may allow a blockchain (22) to be used as a distributed evidence management system for traceability of data.
  • the block chain (22) intrinsically performs proof management on a P2P system without the need for a trusted central instance.
  • traceability is naturally ensured through the chain architecture.
  • all transactions and the data they contain are automatically verifiable.
  • aspects such as the Consensus Protocol Algorithm and Mining Rewards should be based on informed decisions as they affect the overall stability and performance of the distributed platform.
  • the blockchain (22) can be characterized by the following:
  • the blockchain (22) aims to persist the classical data within the distributed blockchain (22).
  • the transaction format is usually modified to perform additional features (such as smart contracts).
  • retrospective provenance model A block chain (22) usually has a retrospective provenance model since the output (result) of some processing or other available data is stored.
  • Process-based capture mechanism The blockchain (22) relies on a process, since the actual application must persist the data within the chain (22).
  • persisting data we mean “storing” data in a persistent manner. In other words, save them so that they do not disappear when, for example, the processing process or program ends.
  • the distributed technical infrastructure includes at least one public key infrastructure (PKI) that allows asymmetric cryptographic tools to be used to secure transactions of a set of data or data objects (DOs) and track the property of a set of data.
  • PKI public key infrastructure
  • an agent must create a platform account to participate in the platform (1) and designate a legal representative, responsible for the actions of the agent, whose identity (ID) is verified .
  • a unique public and private key is generated for the agent to use at least one asymmetric cryptographic tool of the public key infrastructure.
  • said unique public and private key may also enable said agent to act as an active DTP entity, which is active in a machine that executes a DTP instance and is responsible for the actions of the instance at the same time. Assists digital signatures of all communications that use said private key.
  • the distributed technical infrastructure includes at least one Access Control System (AC) that maintains access to available services and / or controls the creation of fraudulent services within the platform.
  • AC Access Control System
  • each service provider (3) which creates a proof of access right for the user concerned using the data management functionalities blockchain (a document of proof is created with the "CREATE" transaction of the blockchain, whose data model indicates the current owner through a "c_owner” attribute or field, and is cryptographically secured by the digital signature service provider).
  • an agent Using the access and control system, an agent must specify in advance, through assertions, the services offered and the service activity performed. The assertions can then be checked after the service has been consumed and thus can detect any fraud specified above.
  • the assertions specify the service activity and verify the corresponding service rendered in relation to the assertions. If there is no match, access is not granted, and the service and the result are stored in a memory of the technical infrastructure to carry out additional verifications. "No access granted” means that the service itself is visible, but the consumption of this service will be refused.
  • data model refers to a model that documents and organizes data, how it is stored and accessed, and the relationships between different types of data.
  • the access and control system provides inter and intra-service traceability, since the service activity can be tracked in detail if appropriate assertions are provided by a service provider.
  • the service provider (3) specifies, using an interactive interface that is based on a web browser (and which creates data models that can be processed by the data traceability platform), provenance metadata that allows for cross-service and intra-service traceability.
  • the service providers (3) within the platform provide at least the details of the calculations performed and the expected output data objects.
  • inter-service traceability refers to the tracking of service orchestration (if any) and the use of external resources. This is done using a specification of the services used through the service provider during the creation of the service (such as an interactive service through a web browser user interface that creates usable data models by the data traceability platform), maintained in the correlated data models of the platform (for example, a service may indicate "other services used”). Since the data traceability platform is a private system, any user must accept the general conditions, which include the accuracy of the information indicated, thus representing a protection by law, the breach of which may be detected by the platform's data analysis processes and finally be subject to prosecution using also the traceability evidence stored on the data traceability platform.
  • Intra-service traceability refers to tracking how the service itself is executed, that is, service-related calculations and the creation of output data objects (including possible models / algorithms, input values, etc.).
  • the block chain (22) is adapted or configured to include a forward looking model whose implementation allows a service provider to provide computational-oriented information, storing at least the assertions of a forward-looking approach. access and control (AC) as part of a transaction, thus containing purely forward-looking information on the calculation that specifies the actual logic being executed (such as immediate calculation results that allow calculations to be tracked or statistically evaluated confidence level of results) and may have different levels of abstraction (eg, source code, work flow diagrams, pseudo code).
  • AC access and control
  • the blockchain system (22) is adapted or configured (or the blockchain or blockchain technology) to understand a retrospective model by taking advantage of the storage and logging functionality of notary functionality, that is, (cryptographic) evidence that the data has been provided or maintained with the integrated data management operations of the data traceability platform blockchain ( creation, update, transfer, deletion, activation, deactivation) in order to maintain the processing information.
  • the implementation of the retrospective model thus makes it possible to capture at least the information relating to the annotations on the data flows and the transformations carried out on the data.
  • the blockchain system (22) is adapted or configured to include a pro-retrospective or prospective-retrospective model blended with the functionality of a distributed process management system.
  • the implementation of this mixed prospective-retrospective model allows the combination of prospective and retrospective information, such as knowledge of the service execution logic and the results of intermediate calculations, in order to allow the follow-up of the calculations and to evaluate the reliability of the results.
  • the database (2) (DB) is designed to handle high workloads and parallel functionality. It is distributed with linear correction performance optimized for write operations, which represent the main operations of the targeted platform.
  • the database (2) can also support heterogeneous data, with which the unassigned data fields do not consume / reserve data.
  • the underlying database (2) is Apache Cassandra.
  • Said Cassandra Apache database (2) can provide at least one fault-tolerant consensus algorithm, such as, but not limited to, PAXOS, which guarantees the accuracy of distributed data replication and, thus, excellent consistency of data. the database (2).
  • the database (2) includes at least one storage layer and a traceability layer.
  • the storage layer comprises at least one set of modules: a transaction pool module (20) comprising the following attributes (see Figure 5) (ID, dm_version, payload, timestamp, operation, previous_tid, c_owner, f_owner, payload_properties, comment, data_other, data_dle, signature, responsible_agent) to process incoming transactions that will be stored in blocks in the block queue (21), a block queue module (21) including the following attributes (see Figure 6) (id, dm_version, payload, timestamps, transactions, creator, voters, comment, status, signature) to process the blocks that are not yet validated and that are the subject of the consensus by federation for the distributed validation of blocks, a blockchain module (id, dm_version, payload, timestamp, creator, voting, comment, status, signature, ID of the previous block) (see figure 4) to process the validated blocks, an invalid block deposition module (23) (including the same attributes as the block chain module) for processing blocks that have been
  • the transactions contained in the storage layer are defined in the tables illustrated in FIG. 8, which contain the following attributes (ID, dm_version, payload, t_index (transaction index, i.e. say storage index in corresponding block), payload, timestamp, operation, previous_tid (transaction ID), c_owner (current owner, that is the current owner of the public key), f_owner (respect the condition defined by the "current owner” field of the previous transaction, that is, a signature with the private key that corresponds to the public key of the current owner), "payload_properties", comment, data_other, signature, blockid, dle_count (data lake element).
  • data lake (24) refers to a large object-oriented storage directory that stores data in its native format until it is used.
  • the storage layer ( Figure 1) of the database (2) includes at least one transaction group storage (20), a block queue storage (21), a storage block chain (22), and invalid block storage and a data lake (24).
  • the incoming transactions are stored in the transaction group storage (20), which transactions are then processed by the transaction group module (20), which extracts and saves them as blocks in the transaction group.
  • the blocks stored in the block queue (21) are then subjected to block validation via federation consensus. Validation is done using the block voting module.
  • the block queue module (21) extracts the blocks that have been determined as validated and transmits them to the blockchain storage (22). Blocks that have been determined as invalid are passed to invalid block storage. In the latter case, all the transactions of said invalid block storage are copied, using the invalid block deposit module (23), to the transaction group, to have a second chance.
  • at least a portion of the incoming transactions are copied to the data lake (24).
  • the storage management module manages the incoming transactions.
  • the execution of the storage management module on the processor allows the transaction group storage (20) to at least receive the raw transactions, to verify the transactions using a deep validation algorithm, d. assign incoming transactions to a DTP agent through a selection strategy (randomized for workload distribution, for example), and add those verified transactions to the storage of the group of transactions (20). These verified transactions are indicated as "transactions", with a strong clearance.
  • the deep validation algorithm allows the arbitrary data to be subsequently validated by all the architectural layers of the data traceability platform, thereby validating the data possibly nested in depth, during validation logic is provided through "validators" that have performed validation in a semantically encapsulated form (such as cryptographic validity checks, data model consistency) optimized for concurrent execution (through hardware with multiple cores / multiple CPUs).
  • In-depth validation is used to validate any data from the traceability platform, and validators can be used and extended by individual applications running "above” the platform, thus serving as a validation routine for use general.
  • the transaction group module (20) identifies the verified transactions or transactions with a large margin using the assigned DTP agent that is responsible for executing the transaction group module. creates blocks using the transaction authorization, transmits the blocks to be stored in the block queue (21), and deletes transactions used from the transaction group storage (20).
  • the execution of the voting module at least makes it possible to check whether the "ID" of an agent (identity) is in a list of voters stored in the storage layer of the database, perform a thorough validation process to determine the validity of a block, add a vote to the block corresponding to the result of the validation, and trigger or not a timer for each vote missing.
  • the storage layer also includes at least:
  • the cache memory is materialized as a size-limited queue (configuration parameter) that uses underlying HashMaps for efficient search of all block IDs, transaction IDs, and so on.
  • a consensus block cache (CBC), which is analogous to the blockchain cache (22) and is used for blocks for which no decision has been made.
  • a transaction group cache (PTC), which stores transactions from the transaction group (20).
  • TLC transaction authorizations
  • the traceability layer includes at least one agent module for storing the traceability agent data model, a data object module (DO) for storing the data model of the traceability data objects (OD). ), a "service” module intended to store the data model of the traceability service, and a “transactions” module intended to store the transactions of the traceability layer.
  • agent module for storing the traceability agent data model
  • DO data object module
  • OD data model of the traceability data objects
  • service intended to store the data model of the traceability service
  • transactions intended to store the transactions of the traceability layer.
  • the traceability entities are also identified by a "static ID” that does not change during an update (such as when the agent owner's email address is changed) and is the following :
  • Agent Owner "agent_owner_id” (unique ID)
  • Agent "agentjd” (public key)
  • the above-mentioned “IDs” (hash of the data model) of the traceability layer entities (agent owner, agent, service, etc.) are used for the identification of a specific database entry. An update of the "Agent Owner”, “Agent”, and “Service” entities may cause a problem at first glance, since the hash changes. Therefore, a "static ID”, a unique universal identifier (UUID), or a public key is used as another unique identifier that does not change if the data model is updated (such as the phone number of the agent owner).
  • UUID unique universal identifier
  • public key is used as another unique identifier that does not change if the data model is updated (such as the phone number of the agent owner).
  • UUID refers to a 128-bit digit used to uniquely identify a certain object or entity on the Internet.
  • the "Agent Owner” entity includes at least one of the following attributes (see Figure 9): ID, dm_version, digest, agent_owner_id, assetjndex, payload, first_name, last_name, date of birth, address, phone number, e-mail, photo, comment, datajother, data_dle, dle_count, country, city, sblockjd, stransactionjd, stransaction_op, stimestamp, while sblockid, stransactionjd, stransaction_op and stimestamp attributes are related to transactions contained in the storage layer.
  • the "Agent” entity comprises at least one of the following attributes (see Figure 10): ID, dm_version, agent Jd, assetjndex, payload, agent_version, agent_owner, agent ype, agent_name, agent_picture, comment, data_other, data_dle, dle_count, sblockid, stransactionjd, stransaction_op, stimestamp, while the attributes sblockid, stransactionjd, stransaction_op and stimestamp are related to the transactions contained in the storage layer.
  • the "Service” entity comprises at least one of the following attributes (see Figure 11): ID, dm_version, assetjndex, payload, servicejd, served ce_version, provider_agent, description, result_description, result ype, input_param_descr, input_param ypes, output_do, used_servicejd, used_service_version, used_service_op, api_specification, is reachable, how, data_other, data_dle, dle_count, sblockjd, stransactionjd, stransaction_op, stimestamp, input_param_count, do_output_count, while the attributes sblockid, stransactionjd, stransaction_op and stimestamp are related to the transactions contained in the storage layer.
  • the transactions contained in the traceability layer comprise at least one of the following attributes (see FIG. 12): ID, dm_version, assetjndex, payload, provider_agent, consumer_agent, servicejd, served ce_version, service_op, input_param, output_do, resuit, how, data_other, data_dle, dle_count, sblockid, stransactionjd, stransaction_op, stimestamp, while the sblockid, stransactionjd, stransaction_op, and stimestamp attributes are related to the transactions in the layer storage.
  • the storage layer includes at least one set of modules that allow data storage and validation. To perform said operations, that is to say the storage and validation of the data, at least one set of requests is necessary. In order to achieve high performance for storing data and associated queries, the important data is held in memory, executing some type of slippery windows on the data that is going through the validation process. Thus, only data validation is important for the data model.
  • a data model that targets block-based validation may be considered. This means that requests for information related to a block must be processed efficiently. At least one of the following main queries is considered:
  • At least one of the following queries is considered for the traceability of the data in the traceability layer, which are performed as database queries with the corresponding information:
  • the voting module is characterized by high performance and parameterability functionality, since the vote can be adjusted to a small federation size, such as trusted DTP agents from the provider of the data traceability platform, with a reduced voting system time and corresponding reduced storage latencies, and since the vote can store instantly and does not require, due to its architectural design, a storage duration like other systems, and especially those that use a "proof of function" consensus (like Bitcoin, with its block mining).
  • a small federation size such as trusted DTP agents from the provider of the data traceability platform
  • the voting system time and corresponding reduced storage latencies since the vote can store instantly and does not require, due to its architectural design, a storage duration like other systems, and especially those that use a "proof of function" consensus (like Bitcoin, with its block mining).
  • the storage layer technology Align Cassandra database
  • the design of the voting module scales can scale (evolve) by its design, which makes it possible to obtain a high total storage rate.
  • the parameterizable functionality of the distributed technical infrastructure is provided by a program and layer-specific configuration files, each layer of said infrastructure being capable of providing individual configurations.
  • the distributed infrastructure comprises at least one set of tools that define the architectural configuration layers of the platform (1) without modifying any program stored in the memory of said platform.
  • the optimal layers can be chosen or replaced by other layers.
  • the storage is separated into a storage infrastructure (database (2)) and storage management (blockchain (22)) that have complete and independent configurations, which contributes to the large Setting capability (both for the platform architecture (1) and the layer-specific configuration).
  • the Data Provisioning Service maintains evidence of activity (providing data, accessing data) in a manner that is transparent to the user.
  • the Data Provisioning Service maintains the data delivery activity, which requires the indication of related metadata, such as the references to the used data sets of the others.
  • the Data Provisioning Service maintains the complete history of a dataset by analyzing the evidence and following the references within the metadata to allow tracking of the complete history. a set of data, and to identify all the users who can contribute to its creation. This is done by analyzing the data models stored in the storage layer, following their correlated information (for example, the traceability transaction stores information about the consumption of a service, with the provider / consumer agent, the service used, the input / output data model, etc.) and by creating a graphical data structure that represents the traceability of the data of all the entities of the platform (data object, service, agent, traceability transaction, etc.).
  • the Data Provisioning Service extends pure property (feature) functionality with operations (creation, update, transfer, deletion, deactivation, activation) to maintain the data sets. on the platform.
  • the platform (1) receives a request from a complex data analysis service that uses Machine Learning Models (MLs) and training data sets available on the platform. (1) to provide a machine learning analysis service.
  • MLs Machine Learning Models
  • the system includes:
  • a cryptographic hash (hash value) of the script is generated, and the information relating to at least one iteration of the loop is stored in a transaction on the blockchain (22). ); of Preferably, the information is stored as metadata in the transaction.
  • the conditions relate to the received data, and the property changes (by the "TRANSFER" block string storage operation, with c_owner defining the new owner) detected or generated by the computing resource; (or the state of the block chain (22)).
  • the database (2) provides a means for identifying processes related to the storage of the transaction group (20), the block queue (21), the blockchain ( 22) and the depositing of invalid blocks (23), block management, agents, data objects, services and transaction traceability. More specifically, all data models provide information about the sending agent and are cryptographically protected by means of signatures, the accuracy of which can be proven with the public key of the agent concerned, which is publicly known in its data model in the agent's database table, thus making all interactions with the database not only traceable, but also cryptographically secure.
  • the database itself is strictly "append-only" for reasons of traceability. For example, updates are done as an additional entry in the database (in reference to the previous state), and deletion on the database is not even implemented, but is detected (in case of dishonest behavior) due to cryptographic relationships.
  • Agents are the only active entities in the platform (1) (controlled by human users or software logic) that work on behalf of an agent owner, the human user (4) being legally responsible for actions of the agents he owns.
  • the validity of the blocks is determined by the verification of a set of "conditions of invalidity" (any state of invalidity gives rise to a block invalidity vote), and a configurable threshold of valid votes must be reached, after that each vote is cryptographically secured with a signature of the sending agent.
  • the database storage and consensus blockchain processes (22) each constitute a layer of the architecture that can be deleted, replaced or expanded with other features, such as, for example a layer of estimation of the value of the data.
  • the data traceability platform (1) comprises at least one estimation module comprising at least one set of models and programs for estimating the contribution of different data sets for the creation of data. a new set and thus to estimate a fair remuneration scale for the reuse of the dataset.
  • the set of templates and programs includes at least one Shapley value estimation model.
  • the value of Shapley can estimate the value of a dataset and / or the relative contribution of sets of input data to the value of the resulting dataset.
  • a set of original data can be shared on the platform (1) by a first user.
  • Said data set can be modified by a second user (4, FIG. 2c) (consumer of the data) or a third user (4) and reused on the platform.
  • the implementation of the traceability tools of the platform (1) of the present invention can make it possible to track the shared origin of the data sets, and each of their transformations. Said information is thus entered as an entry in the estimation module, which in turn delivers the contribution of each user (4) to the new data set (the set of data that results from all the transformations). see Figure 2d.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne 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, la base de données (2) étant 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 (DO1, …, 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 mettre en place un processus de consensus par fédération (FC), 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, la base de données comportant au moins une couche de traçabilité comprenant un ensemble de modules dont l'exécution permet la traçabilité des données, la plate-forme de traçabilité de données étant configurée en implémentant au moins un modèle prospectif-rétrospectif mixte 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).

Description

Plate-forme de traçabilité sécurisée de données
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 de formation 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 de formation 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 de formation 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, la base de données étant 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 est configurée 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, la base de données étant caractérisée en ce qu’elle comprend une couche de traçabilité comprenant un ensemble de modules dont l’exécution permet la traçabilité des données, la plate-forme de traçabilité de données étant configurée en implémentant au moins un modèle prospectif-rétrospectif la technologie de chaîne de blocs 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.
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 configurée pour comprendre un modèle prospectif dont l’implémentation permet à 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 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 dont l’implémentation permet de capturer au moins les informations relatives aux annotations sur les flux de données et les transformations effectuées sur les données.
Selon une autre particularité, la technologie de chaîne de blocs est configurée pour comprendre le modèle prospectif-rétrospectif mixte avec la fonctionnalité d’un système de gestion de processus distribué (WMS), l’implémentation dudit modèle permettant la combinaison des informations pro- et rétrospectives pour le suivi du calcul et l’évaluation de la fiabilité du résultat du calcul, les informations prospectives étant obtenu par capture ou enregistrement des informations décrivant le processus de traitement des données.
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 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 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 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 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 : « agentjd » (clé publique)
• Service : « servicejd » (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 de formation 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 DETAILLEE
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, la base de données (2) étant 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 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. La base de données est caractérisée en ce qu’elle comprend une couche de traçabilité comprenant un ensemble de modules dont l’exécution permet la traçabilité des données la plate-forme de traçabilité de données étant configurée en implémentant au moins un modèle pro-/rétrospectif ou prospectif-rétrospectif mixte ou 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)
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 plate forme (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. Un modèle peut être défini par un module ou programme ou un ensemble de programmes à exécuter sur au moins un processeur de l’infrastructure technique distribuée.
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 «top- down », 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 pseudo alé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 sous- ensemble 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 contracts »)
• 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 plate forme (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 ou configurée pour comprendre un modèle prospectif dont l’implémentation permet à 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é ou configuré (ou la chaîne de blocs ou la technologie de chaîne de blocs) 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). L’implémentation du modèle rétrospectif permet, ainsi, de capturer au moins les informations relatives aux annotations sur les flux de données et les transformations effectuées sur les données. Dans certains modes de réalisation, le système de chaîne de blocs (22) est adapté ou configuré pour comprendre un modèle pro-/rétrospectif ou prospectif-rétrospectif mixte avec la fonctionnalité d’un système de gestion de processus distribué. L’implémentation dudit modèle prospectif-rétrospectif mixte permet la combinaison des informations prospectives 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, votej n va I id_reaso n , 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, transactionjd, 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 plate forme 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 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 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 : « agentjd » (clé publique)
• Service : « servicejd » (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, assetjndex, charge utile, first_name, last_name, date de naissance, adresse, numéro de téléphone, e-mail, photo, commentaire, datajother, data_dle, dle_count, pays, ville, sblockjd, stransactionjd, stransaction_op, stimestamp, tandis que les attributs sblockid, stransactionjd, 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 Jd, assetjndex, charge utile, agent_version, agent_owner, agent ype, agent_name, agent_picture, commentaire, data_other, data_dle, dle_count, sblockid, stransactionjd, stransaction_op, stimestamp, tandis que les attributs sblockid, stransactionjd, 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, assetjndex, charge utile, servicejd, servi ce_version, provider_agent, description, result_description, result ype, input_param_descr, input_param ypes, « output_do », used_servicejd, used_service_version, used_service_op, api_specification, is raceable, comment, data_other, data_dle, dle_count, sblockjd, stransactionjd, stransaction_op, stimestamp, input_param_count, do_output_count, tandis que les attributs sblockid, stransactionjd, 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, assetjndex, charge utile, provider_agent, consumer_agent, servicejd, servi ce_version, service_op, input_param, output_do, resuit, comment, data_other, data_dle, dle_count, sblockid, stransactionjd, stransaction_op, stimestamp, tandis que les attributs sblockid, stransactionjd, 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 temps- systè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 de formation 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 plate- forme (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

REVENDICATIONS
1. 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, la base de données (2) étant 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 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, la base de données étant caractérisée en ce qu’elle comprend une couche de traçabilité comprenant un ensemble de modules dont l’exécution permet la traçabilité des données, la plate-forme de traçabilité de données étant configurée en implémentant au moins un modèle prospectif-rétrospectif mixte 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).
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 configurée pour comprendre un modèle prospectif dont l’implémentation permet à 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 dont l’implémentation permet de capturer au moins les informations relatives aux annotations sur les flux de données et les transformations effectuées sur les données.
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 le modèle prospectif-rétrospectif mixte avec la fonctionnalité d’un système de gestion de processus distribué, l’implémentation dudit modèle permettant la combinaison des informations prospectives et rétrospectives pour le suivi du calcul et l’évaluation de la fiabilité du résultat du calcul, les informations prospectives étant obtenu par capture ou enregistrement des informations décrivant le processus de traitement des données.
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.
10. Infrastructure technique distribuée selon les revendications 1 à 9, caractérisée en ce que le système AC permet une traçabilité inter- et intra- service si des assertions appropriées sont fournies par un prestataire de service (3).
11. Infrastructure technique distribuée selon les revendications 1 , 9 et 10, 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.
12. Infrastructure technique distribuée selon la revendication 1 , caractérisée en ce que la base de données (2) 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.
13. Infrastructure technique distribuée selon la revendication 1 , caractérisé en ce que la base de données (2) est Apache Cassandra.
14. Infrastructure technique distribuée selon la revendication 1 , 12 ou 13, 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).
15. Infrastructure technique distribuée selon les revendications 1 et 14, 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.
16. Infrastructure technique distribuée selon les revendications 1 , 14 et 15, 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).
17. Infrastructure technique distribuée selon la revendication 16, 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.
18. Infrastructure technique distribuée selon les revendications 1 , 14, 15 et 16, 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).
19. Infrastructure technique distribuée selon les revendications 1 , 14, 15, 16, et 18, caractérisée en ce que l’exécution du module de vote permet au moins de vérifier si G « 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.
20. Infrastructure technique distribuée selon les revendications 1 et 14, 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.
21. Infrastructure technique distribuée selon les revendications 1 et
14, 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é.
22. Infrastructure technique distribuée selon les revendications 1 , 14 et 21 , 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 :
• Propriétaire de l’agent (AgentOwner) :
« agent_owner_id » (ID unique)
• Agent : « agentjd » (clé publique)
• Service : « servicejd » (ID unique) +
« service_version »
23. Infrastructure technique distribuée selon les revendications 1 , 14,
15, 16, 18 et 20, 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 stockage
24. Infrastructure technique distribuée selon les revendications 1 , 14, 21 et 22, 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 :
• 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.
25. 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.
26. Infrastructure technique distribuée selon la revendication 25, caractérisée en ce que 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é.
27. Infrastructure technique distribuée selon les revendications 1 et 25, 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.
28. 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.
29. 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.
30. 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.
31. Infrastructure technique distribuée selon la revendication 1 , caractérisé en ce que 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.
32. Infrastructure technique distribuée selon la revendication 1 , caractérisé en ce que la plate-forme (1 ) 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 de formation disponibles sur la plate-forme (1 ) afin d’offrir un service d’analyse par apprentissage machine.
33. 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.
34. Infrastructure technique distribuée selon la revendication 1 à 32, 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.
35. Infrastructure technique distribuée selon la revendication 1 à 33, 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).
36. Infrastructure technique distribuée selon les revendications 1 à 34, 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.
37. Infrastructure technique distribuée selon la revendication 1 à 35, 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.
38. 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.
39. Infrastructure technique distribuée selon les revendications 1 et 37, caractérisée en ce que 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.
40. Infrastructure technique distribuée selon les revendications 1 , 37 et 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.
PCT/EP2018/083221 2017-11-30 2018-11-30 Plate-forme de tracabilite securisee de donnees WO2019106186A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1761423 2017-11-30
FR1761423A FR3074322B1 (fr) 2017-11-30 2017-11-30 Plate-forme de tracabilite securisee de donnees

Publications (1)

Publication Number Publication Date
WO2019106186A1 true WO2019106186A1 (fr) 2019-06-06

Family

ID=62143240

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/083221 WO2019106186A1 (fr) 2017-11-30 2018-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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021082757A1 (fr) * 2019-10-29 2021-05-06 深圳前海微众银行股份有限公司 Procédé et appareil de traitement de données basés sur un système de chaîne de blocs
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

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111563103B (zh) * 2020-04-28 2022-05-20 厦门市美亚柏科信息股份有限公司 一种用于数据血缘检测方法和系统
CN111737352B (zh) * 2020-06-23 2021-12-21 四川长虹电器股份有限公司 一种基于区块链的供应链信息协同管理方法

Citations (2)

* Cited by examiner, † Cited by third party
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021082757A1 (fr) * 2019-10-29 2021-05-06 深圳前海微众银行股份有限公司 Procédé et appareil de traitement de données basés sur un système de chaîne de blocs
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
WO2021234618A1 (fr) 2020-05-20 2021-11-25 Cleverdist Sa Procédé et système de commande du partage de flux de données échangés entre de multiples organisations

Also Published As

Publication number Publication date
FR3074322A1 (fr) 2019-05-31
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
US11709819B2 (en) Validating test results using a blockchain network
Wilkinson et al. Metadisk a blockchain-based decentralized file storage application
US20180357683A1 (en) Rating data management
US20200162266A1 (en) Facilitating analytic services for provenance of digital documents
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
Tarekegn et al. Big data: security issues, challenges and future scope
US12002039B2 (en) Database system public trust ledger multi-owner token architecture
Nazir et al. Cloud computing applications: a review
US11954094B2 (en) Database system public trust ledger architecture
CN115769206A (zh) 密码化数据录入区块链数据结构
Shrestha et al. User data sharing frameworks: a blockchain-based incentive solution
TW202139127A (zh) 用於與區塊鏈相關聯之服務平台之運算服務
US20230362010A1 (en) Systems and methods for predicting communication account identities across decentralized applications
Lee et al. SPChain: A smart and private blockchain-enabled framework for combining GDPR-compliant digital assets management with AI models
Umekwudo et al. Blockchain technology for mobile applications recommendation systems
US20240062169A1 (en) Nonfungible token path synthesis with social sharing
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
FR3091369A1 (fr) Plateforme de sécurisation de données

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18836460

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18836460

Country of ref document: EP

Kind code of ref document: A1