EP4681108A1 - Procédé et dispositif de vérification d'au moins une donnée obtenue depuis un service de fourniture de données - Google Patents

Procédé et dispositif de vérification d'au moins une donnée obtenue depuis un service de fourniture de données

Info

Publication number
EP4681108A1
EP4681108A1 EP24709401.4A EP24709401A EP4681108A1 EP 4681108 A1 EP4681108 A1 EP 4681108A1 EP 24709401 A EP24709401 A EP 24709401A EP 4681108 A1 EP4681108 A1 EP 4681108A1
Authority
EP
European Patent Office
Prior art keywords
data
result
command
service
blockchain
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24709401.4A
Other languages
German (de)
English (en)
Inventor
Julien HATIN
Valentin ANDRE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4681108A1 publication Critical patent/EP4681108A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • the invention relates to the general field of telecommunications networks, and more specifically to blockchain technology.
  • a blockchain is a trusted execution system that guarantees, for example, the integrity and transparency of the execution of a process.
  • the blockchain forms a distributed database whose users play an active role in its updating. It securely stores, in several connected/chained data blocks, the history of all transactions carried out by users. It is also accessible by each user without any intermediary. Thus, each user has the possibility of verifying the data that constitutes it and therefore its validity.
  • Smart contracts on blockchains enable, for example, the management of the execution of process tasks and the allocation of these tasks in a decentralized and reliable manner.
  • the aim of these smart contracts is to digitalize physical processes by replacing paper contracts with computer code.
  • some smart contracts may need data external to the blockchain.
  • the blockchain cannot access data stored outside its network.
  • the smart contract has the possibility of using the services of an “oracle” which has the ability to add data from the outside world within a blockchain.
  • Oracles provide a lot of data such as temperatures, sports results, schedules, etc. Depending on the information provided by the Oracles, the smart contract will execute or not.
  • the invention makes it possible to check the information/data provided by a data supply service.
  • the method obtains a command issued, for example by a user, to a data supply service and one or more data (first data) corresponding to the result (first result) of the execution of the command by the service. It also obtains a second result of execution of the command (the command being able to be executed by the method itself) then verifies the data obtained from the service for example via a comparison of the results of execution of the command. If they are identical then the data provided by the service are considered to be verified.
  • a method as described above is characterized in that said service provides a blockchain with data external to said blockchain and in that said command is obtained from a first smart contract registered in said blockchain and said at least one first data item is obtained from a second smart contract registered in said blockchain.
  • this embodiment makes it possible to control the information/data provided by a data provision service external to a blockchain such as an oracle.
  • a data provision service external to a blockchain such as an oracle.
  • this embodiment proposes a new role associated with the management of a blockchain; that of oracle data verifier.
  • the invention makes it possible to verify the result (i.e. data) obtained following the execution of a command by an oracle and its completeness.
  • the method obtains from a first smart contract registered in the blockchain an order issued by a user to a first oracle.
  • the method also obtains the result of the execution of the order by the first oracle for example from a second smart contract.
  • the first and second smart contracts are one and the same smart contract.
  • the command can be obtained from the first smart contract and from the user of the blockchain.
  • This embodiment makes it possible to compare the requests obtained and to ensure that the request to be processed by the method, i.e. issued by the first user to the oracle, is indeed the correct one.
  • the method then obtains a second result of the command execution, for example from a second oracle. Then, the method checks the first result for example by comparing it to the second result. If they are identical then the data provided by the service (i.e. the first oracle) is considered valid.
  • the method can itself execute the command, in which case the method can be considered as the second oracle.
  • a method as described above is characterized in that said verification step corresponds to a comparison of said at least one first data item with said second result and when the result of said comparison is negative a request for validity of all or part of said second result is sent to a third smart contract registered in said blockchain.
  • This embodiment makes it possible to validate all or part of the second execution result of the order with a smart contract (third smart contract within the meaning of the invention) registered in the blockchain. Since a smart contract cannot be altered over time, all of the tests carried out by the third smart contract on the second execution result can be considered as certified. Thus, the result of these tests makes it possible to certify the validity of all or part of the second execution result of the order.
  • a smart contract third smart contract within the meaning of the invention
  • the invention makes it possible to ensure the validity of the information/data provided by a data provision service of a blockchain.
  • the method obtains for example from a first user registered in a blockchain a request for information/data (query within the meaning of the invention) issued to a first oracle (data provision service within the meaning of the invention).
  • the request comprises at least one command to be executed by the oracle and a first time stamp indicating for example the date of issue or creation of the request/query.
  • the method then obtains the result of the execution of the command by the oracle.
  • the result is for example obtained from a smart contract registered in the blockchain.
  • the method then obtains all or part of a second result of execution of the command, for example via a second user of the blockchain such as a second oracle.
  • the response includes one or more data with for each data obtained an electronic signature and a second associated time stamp.
  • the data when the command is a SQL (Structure Query Language) type query, the data may correspond to one or more records in a database (one or more rows in the database).
  • the second timestamp may then correspond to information on the chronology of the writing of the data in the database, such as the index of the database when it is only accessible in writing (no deletion of record/data/row in the database) or to a timestamp of the data itself.
  • the electronic signature may correspond to the electronic signature of the entity that feeds the database.
  • the method verifies the validity of the data received by performing several tests.
  • the first test consists of verifying that the signature associated with a piece of data is valid. Obviously, this assumes that the method has cryptographic key(s) (private and/or public) allowing this verification.
  • the second test aims to verify that the data received is indeed prior to the creation or issue of the query. To do this, the method verifies that the query timestamp is indeed after the timestamps of the data. Finally, the method also verifies that the data received corresponds to a valid response to the query. In the case where the data received corresponds to one or more rows of a database, the method verifies that all of the data corresponds to a possible result of executing the SQL command.
  • a command is a computer instruction allowing the execution of an order, an action or a series of orders and actions.
  • An electronic signature is a sequence of characters used to authenticate the author of data (for example, the entity that added data to a database) and to guarantee its authenticity.
  • An electronic signature can also guarantee the inalterability of the data once it has been signed by the entity that holds/shares it.
  • most existing digital signature procedures are based on asymmetric cryptography such as the RSA algorithm.
  • a method as described above is characterized in that the verification step is followed by a step of issuing a notification of validity of said at least one piece of data.
  • This embodiment makes it possible to inform/notify a user of the blockchain (oracle or not) of the validity or invalidity of the data obtained.
  • a method as described above is characterized in that said verification step is preceded by a step of obtaining (E20) a parameter whose value corresponds to a financial amount and in that when the result of said verification is positive all or part of the value of said parameter is sent (E120, E121) to a user of said blockchain.
  • This embodiment makes it possible to remunerate a user (for example a second oracle) of the blockchain when the latter provides/finds valid data (i.e. data that corresponds to all or part of a possible result of execution of the command) not transmitted by the oracle.
  • the method obtains, for example from the first oracle, a parameter whose value corresponds to a financial amount.
  • the value of the parameter can correspond to an amount denominated in a currency of a country, to a defined number of tokens of a cryptocurrency or more generally to any market value (for example calculation tokens of a computer server).
  • the parameter can be assimilated to a deposit/escrow granted by the oracle in the event of an error by the latter. When an error is proven, all or part of the deposit is returned to the user (for example on one of their smart contracts) who detected the error, i.e. to the user who provided the process with valid data not transmitted by the oracle.
  • module may correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.).
  • the invention also relates to a computer program comprising instructions for implementing the verification and/or validation method described above according to any of the particular embodiments described above, when said program is executed by a processor.
  • the method can be implemented in various ways, in particular in hard-wired form or in software form.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the recording media mentioned above can be any entity or device capable of storing the program.
  • the medium can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard disk.
  • the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention can in particular be downloaded on a network such as the Internet.
  • This verification device and the computer program implementing the verification method have characteristics and advantages similar to those described previously in relation to the verification method.
  • the computer program implementing the validation method has characteristics and advantages similar to those described previously in relation to the validation method.
  • the environment represented in comprises a blockchain BC and a database BDD.
  • the environment also comprises two terminals O and BH belonging to users of the blockchain capable of providing the blockchain with data external to the blockchain.
  • the terminal O belongs for example to an oracle.
  • the terminal BH integrates a verification device capable of implementing the verification method and can also belong to an oracle.
  • the environment further comprises a terminal S belonging to a user of the blockchain BC.
  • the BC blockchain and/or a smart contract registered in the BC blockchain is capable of implementing the validation process.
  • the O, S and BH terminals are, for example, smartphone-type terminals (smartphone in English), tablets, servers, connected televisions, connected objects, on-board computers in cars, personal computers or any other terminal capable of communicating (sending and/or receiving requests) using state-of-the-art technologies, for example via an IP network (100), the network being able to be private or public.
  • smartphone-type terminals smart phone in English
  • tablets tablets
  • servers connected televisions
  • connected objects connected objects
  • on-board computers in cars personal computers or any other terminal capable of communicating (sending and/or receiving requests) using state-of-the-art technologies, for example via an IP network (100), the network being able to be private or public.
  • IP network 100
  • the BC blockchain can be hosted by one or more computer servers.
  • the device DISP configured to implement the verification method according to a particular embodiment of the invention.
  • the device DISP has the conventional architecture of a computer, and notably comprises a memory MEM, a processing unit UT, equipped for example with a processor PROC, and controlled by the computer program PG stored in memory MEM.
  • the computer program PG comprises instructions for implementing the steps of the verification method as described later in support of the , when the program is executed by the processor PROC.
  • the code instructions of the computer program PG are for example loaded into a memory before being executed by the processor PROC.
  • the processor PROC of the processing unit UT notably implements the steps of the verification method according to any one of the particular embodiments described in relation to the and according to the instructions of the PG computer program.
  • the DISP device comprises a first obtaining module OBT1 capable of obtaining an order issued to a data supply service such as for example an oracle of a blockchain.
  • the order can be obtained from a user of the blockchain or from a smart contract registered in the blockchain.
  • the DISP device also includes a second OBT2 obtaining module capable of obtaining at least one piece of data corresponding to a result of execution of the command by the data supply service.
  • the DISP device also comprises a third obtaining module OBT3 capable of obtaining a second result of execution of said command.
  • the second result is for example obtained by the DISP device following the execution of the command by the verification method.
  • the DISP device further comprises a verification module VERIF of the data(s) obtained via the OBT2 module.
  • the verification is for example carried out by comparing the data(s) with the second result obtained via the OBT3 module.
  • step E30 the oracle O sends to a smart contract SC V a parameter whose value corresponds to a financial amount, for example a number of tokens of a cryptographic currency, a number of tokens offering credits for using the blockchain BC or an amount denominated in an official currency of a country (Euro, Dollars, etc.).
  • the oracle O transfers a sum of money to the smart contract SC V .
  • This money can be seen as a deposit granted by the oracle O allowing for example to guarantee a certain quality of service / execution of action(s) on its part.
  • the deposit can be used to compensate the client and/or remunerate the actor who detected the error.
  • the parameter is received by the smart contract SC V in step E20.
  • the smart contract SC V obtains from a client's terminal S an order whose recipient is the oracle O (not shown).
  • the smart contract SC V also obtains a first timestamp associated with the received order. This timestamp corresponds for example to the date on which the order was received by the SC smart contract V and/or a block number of the BC blockchain associated with the order.
  • the time stamp may correspond to the date of creation of the order and/or issuance by the terminal S.
  • the order is obtained from a smart contract of the client (SC C ).
  • the order is for example obtained via or following the reception of an event broadcast within the blockchain indicating the issuance, by the smart contract of the client, of the order to the oracle O.
  • the smart contract SC V relays the command obtained from the client's terminal S or from the smart contract SC C to the oracle and the terminal BH.
  • the command is obtained by the terminal BH via or following the reception of an event broadcast within the blockchain indicating the issue of the command to the oracle O.
  • the command is obtained by the oracle O and the terminal BH respectively in steps E31 and E41.
  • the oracle executes the command.
  • the command is for example capable of obtaining a set of lines from a table stored in a digital storage space such as a file, a database BDD, etc.
  • the command may correspond to a query carried out in a computer language of the SQL, NoSQL, OQL, Prolog type or to a list of filtering parameters making it possible to obtain, from the database BDD, one or more records (i.e. lines).
  • the database/BDD table can correspond to: Index Latitude Longitude Temperature Precipitation (Millimeter) Date Signature 1 40.77 -73.96 15°C 5mm D1 S1 2 40.77 -73.96 8°C 8mm D2 S2 3 40.77 -73.96 6°C 7mm D3 S3 4 40.77 -73.96 11°C 0mm D4 S4 5 40.77 -73.96 9°C 0mm D5 S5
  • the BDD database stores chronologically the temperature and rainfall readings of a weather station identified by its GPS position (latitude, longitude). Each new record added to the BDD table (index +1) is associated with an electronic signature Sn of the service that entered the information in the table and with a time data Dn (second time stamp within the meaning of the invention) indicating for example the date of the temperature and rainfall measurements.
  • the electronic signature can correspond to the signature of the national meteorological service of the country or locality that manages the weather station in question.
  • the signature may correspond to a digital fingerprint (e.g. a hash) of a unique piece of data belonging to the signer and stored in one of their smart contracts within the blockchain.
  • a digital fingerprint e.g. a hash
  • the database obtains the SQL query in step E52 and sends the result to the oracle O in step E53.
  • SQL query can be:
  • the result received by the smart contract SC V during step E24 may for example correspond to: Index Latitude Longitude Temperature Precipitation (Millimeter) Date Signature 2 40.77 -73.96 8°C 8mm D2 S2 3 40.77 -73.96 6°C 7mm D3 S3 4 40.77 -73.96 11°C 0mm D4 S4
  • the record of index 5 is not present while it also corresponds to a possible result of the SQL query/command.
  • the result provided by the oracle O is therefore partial (error by omission).
  • This error can be fortuitous (data integrity problem following a technical/network problem or caused by the oracle for example when it optimizes its processes to go faster with the consequence of a lack of verification and a lower quality of processing.
  • the smart contract SC V may not perform a validity test.
  • the smart contract SC V can test the signature(s) of the data received from the oracle O (result of the command received during step E24).
  • the smart contract SC V sends (E24_1) to the smart contract of the client SC C the result of the command obtained from the oracle O, the result being received by the smart contract of the client SC C at step E14_1.
  • the smart contract SC V knows the electronic address of the smart contract SC C .
  • the address of the smart contract SC C is for example obtained when the command is received from the smart contract of the client SC C (E21).
  • the electronic address of the smart contract SC C is sent from the terminal S at the same time as the command (E21).
  • the smart contract SC V sends (E24_1) instead of or in addition to the result of the command a parameter indicating that the data sent is not valid.
  • step E45 the terminal BH sends a request to the smart contract SC C to obtain the result of the command provided by the oracle to the smart contract SC C .
  • the sending of the request can be issued following the reception (for example from the blockchain or from the terminal S) by the terminal BH of an event indicating that the smart contract SC C and/or SC V has received the result of the command from the oracle O.
  • the BH terminal sends a request to the SC V smart contract to obtain the command result provided by the oracle.
  • step E15 The request is received by the SC smart contract C in step E15.
  • the result received in step E14_1 is then transmitted to the terminal BH (E16) and then received by the terminal BH in step E46.
  • the terminal BH has the command received in step E41 and the result of the command provided by the oracle O in step E46.
  • the terminal BH can then verify the result, for example, on behalf of the user of the terminal S.
  • step E47 the terminal BH issues the command to the database BDD.
  • the command is received by the database in step E57.
  • the result of the command is obtained by the database BDD in step E58 and then transmitted to the terminal BH in step E48.
  • the terminal BH compares (E49) the two results of the command obtained respectively in steps E46 and E48 in order to verify the result transmitted by the oracle O to the smart contract SC V .
  • the verification process considers that the result provided by the oracle O to the smart contract SC C / SC V is valid. Otherwise, the verification process tests the validity of all or part of the data obtained during step E48 from the blockchain and more particularly from the smart contract SC V which implements the validation process.
  • the terminal BH issues (E49) a request for validation of all or part of the data obtained during step E48 to the smart contract SC V .
  • the request is received and then processed by the SC smart contract. V at step E29.
  • the smart contract SC V performs (cumulatively or alternately) three tests to determine whether the data received from the BH terminal is valid.
  • the first test consists of verifying that the signature (Sn) associated with each received data (record) is valid. Obviously this assumes that the process has cryptographic key(s) (private and/or public) allowing this verification.
  • the second test aims to verify that the received data is indeed prior to the creation or issue of the request. To do this, the process verifies that the timestamp of the command is indeed after the timestamps of the data received from the BH terminal. Finally, the process also verifies that the received data corresponds to a valid response to the request. In our example, the process verifies that the received data corresponds to a possible result of executing the SQL command. Concretely, the process verifies that the index of the data received from the BH terminal is indeed ⁇ 2.
  • the comparison of the results of the command obtained respectively during steps E46 and E48 and carried out by the terminal BH can be carried out by the smart contract SC V.
  • the valid data received from the BH terminal and not included in the result of the command obtained from the oracle (E24) can also be sent to the client's smart contract (SC C ) during step E120.
  • the invention also applies to data other than weather data such as, for example, information on the recycling of elements constituting a manufactured product, making it possible, for example, to calculate the carbon footprint of the product in question or information on the traceability of elements of a product such as the parts of an automobile.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Facsimiles In General (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention propose un procédé de vérification d'au moins une première donnée obtenue depuis un service de fourniture de données, le procédé étant mis en œuvre par un dispositif de vérification et caractérisé en ce qu'il comprend les étapes suivantes : - obtention d'une commande émise à destination dudit service; - obtention de ladite au moins une première donnée correspondant à un premier résultat d'exécution de ladite commande par ledit service; - obtention d'au moins une seconde donnée correspondant à un deuxième résultat d'exécution de ladite commande; - vérification de ladite au moins une première donnée en fonction dudit deuxième résultat.

Description

    Procédé et dispositif de vérification d’au moins une donnée obtenue depuis un service de fourniture de données
  • 1. Domaine de l'invention
  • L’invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »).
  • 2. Art Antérieur
  • Une chaîne de bloc est un système d'exécution de confiance garantissant, par exemple, l'intégrité et la transparence de l'exécution d’un processus. Concrètement, la chaîne de blocs forme une base de données distribuée dont les utilisateurs jouent un rôle actif dans sa mise à jour. Elle stocke de manière sécurisée, dans plusieurs blocs de données connectés/chaînés entre eux, l’historique de toutes les transactions effectuées par les utilisateurs. Elle est en outre accessible par chaque utilisateur sans aucun intermédiaire. Ainsi, chaque utilisateur a la possibilité de vérifier les données qui la constituent et donc sa validité.
  • Les contrats intelligents (en anglais « smart contract ») des chaînes de blocs permettent, par exemple, la gestion de l'exécution de tâches du processus et l'attribution de ces tâches de manière décentralisée et fiable. L'objectif de ces contrats intelligents est de digitaliser les processus physiques en remplaçant les contrats papiers par du code informatique.
  • Pour fonctionner correctement, certains contrats intelligents peuvent avoir besoin de données externes à la chaîne de blocs. Or la chaîne de blocs ne peut pas accéder à des données stockées en dehors de son réseau. Pour résoudre ce problème, le contrat intelligent a la possibilité d’utiliser les services d’un « oracle » qui a la possibilité d’ajouter des données du monde extérieur au sein d’une chaîne de blocs. Les oracles fournissent de nombreuses données comme par exemple des températures, des résultats sportifs, des horaires, etc. En fonction des informations fournies par les Oracles, le contrat intelligent s’exécutera ou non.
  • Force est de constater qu’il n’existe pas de mécanisme technique qui permette de s’assurer que l’oracle est bien de confiance ou que celui-ci n’a pas commis une erreur dans la fourniture des informations.
  • 3. Exposé de l'invention
  • L'invention vient améliorer l'état de la technique et propose à cet effet un procédé de vérification d’au moins une première donnée obtenue depuis un service de fourniture de données, le procédé étant mis en œuvre par un dispositif de vérification et caractérisé en ce qu’il comprend les étapes suivantes :
    • obtention d’une commande émise à destination dudit service ;
    • obtention de ladite au moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service ;
    • obtention d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ;
    • vérification de ladite au moins une première donnée en fonction dudit deuxième résultat.
  • Avantageusement, l’invention permet de contrôler les informations/données fournies par un service de fourniture de données. Concrètement, le procédé obtient une commande émise, par exemple par un utilisateur, à destination d’un service de fourniture de données et une ou plusieurs données (première(s) donnée(s)) correspondant au résultat (premier résultat) de l’exécution de la commande par le service. Il obtient également un deuxième résultat d’exécution de la commande (la commande pouvant être exécutée par le procédé lui-même) puis vérifie la ou les données obtenues du service par exemple via une comparaison des résultats d’exécution de la commande. S’ils sont identiques alors la ou les données fournies par le service sont considérées comme vérifiées.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ledit service fournit à une chaîne de blocs des données externes à ladite chaîne de blocs et en ce que ladite commande est obtenue depuis un premier contrat intelligent inscrit à ladite chaîne de blocs et ladite au moins une première donnée est obtenue depuis un deuxième contrat intelligent inscrit à ladite chaîne de blocs.
  • Avantageusement, ce mode de réalisation permet de contrôler les informations/données fournies par un service de fourniture de données externes à une chaîne de blocs tel qu’un oracle. De ce fait, ce mode de réalisation propose un nouveau rôle associé à la gestion d’une chaîne de blocs ; celui de vérificateur de données d’oracle.
  • En effet, un oracle peut fortuitement ou sciemment (par exemple lorsque celui-ci est malveillant) retourner des données erronées ou bien omettre des données dans sa réponse. Ainsi, l’invention permet de vérifier le résultat (i.e. des données) obtenu à la suite de l’exécution d’une commande par un oracle et sa complétude.
  • Concrètement, le procédé obtient depuis un premier contrat intelligent inscrit à la chaîne de blocs une commande émise par un utilisateur à destination d’un premier oracle. Le procédé obtient également le résultat de l’exécution de la commande par le premier oracle par exemple depuis un deuxième contrat intelligent.
  • Selon un mode particulier de réalisation, le premier et le deuxième contrat intelligent est un seul et même contrat intelligent.
  • Selon un mode particulier de réalisation, la commande peut être obtenue depuis le premier contrat intelligent et depuis l’utilisateur de la chaîne de blocs. Ce mode de réalisation permet comparer les requêtes obtenues et de s’assurer que la requête à traiter par le procédé, c’est-à-dire émise par le premier utilisateur à destination de l’oracle est bien la bonne.
  • Le procédé obtient ensuite un deuxième résultat d’exécution de la commande, par exemple depuis un deuxième oracle. Puis, le procédé vérifie le premier résultat par exemple en le comparant au deuxième résultat. S’ils sont identiques alors les données fournies par le service (c’est-à-dire le premier oracle) sont considérées comme valides.
  • Selon un mode particulier de réalisation, le procédé peut lui-même exécuter la commande, dans ce cas le procédé peut être considéré comme le deuxième oracle.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite étape de vérification correspond à une comparaison de ladite au moins une première donnée avec ledit deuxième résultat et lorsque le résultat de ladite comparaison est négatif une demande de validité de tout ou partie dudit deuxième résultat est émise à destination d’un troisième contrat intelligent inscrit à ladite chaîne de blocs.
  • Ce mode de réalisation permet de valider tout ou partie du deuxième résultat d’exécution de la commande auprès d’un contrat intelligent (troisième contrat intelligent au sens de l’invention) inscrit à la chaîne de blocs. Un contrat intelligent n’étant pas altérable dans le temps l’ensemble des tests réalisés par le troisième contrat intelligent sur le deuxième résultat d’exécution peuvent être considérés comme certifiés. Ainsi, le résultat de ces tests permet de certifier la validité de tout ou partie du deuxième résultat d’exécution de la commande.
  • L'invention propose également un procédé de validation, par un contrat intelligent inscrit à une chaîne de blocs, d’au moins une donnée obtenue depuis un service de fourniture à ladite chaîne de blocs de données externes à ladite chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend les étapes suivantes :
    • obtention d’une requête émise à destination dudit service, ladite requête comprenant une première estampille temporelle et une commande ;
    • obtention d’un premier résultat d’exécution de ladite commande par ledit service ;
    • obtention de tout ou partie d’un deuxième résultat d’exécution de ladite commande comprenant ladite au moins une donnée associée à une signature électronique et à une deuxième estampille temporelle ;
  • et lorsque ladite au moins une donnée n’est pas comprise dans ledit premier résultat
    • vérification de la validité de ladite au moins une donnée via le contrôle de la validité de ladite signature, de l’antériorité de ladite deuxième estampille temporelle par rapport à ladite première estampille temporelle et de la validité de ladite au moins une donnée comme résultat de ladite commande.
  • Avantageusement, l’invention permet de s’assurer de la validité des informations/données fournies par un service de fourniture de données d’une chaîne de blocs.
  • Concrètement, le procédé obtient par exemple d’un premier utilisateur inscrit à une chaîne de blocs une demande d’information/de donnée(s) (requête au sens de l’invention) émise à destination d’un premier oracle (service de fourniture de données au sens de l’invention). La demande comprend au moins une commande à exécuter par l’oracle et une première estampille temporelle indiquant par exemple la date d’émission ou de création de la demande /requête. Le procédé obtient ensuite le résultat de l’exécution de la commande par l’oracle. Le résultat est par exemple obtenu depuis un contrat intelligent inscrit à la chaîne de blocs.
  • Le procédé obtient par la suite tout ou partie d’un deuxième résultat d’exécution de la commande par exemple via un deuxième utilisateur de la chaîne de blocs tel qu’un deuxième oracle. La réponse comprend une ou plusieurs données avec pour chaque donnée obtenue une signature électronique et une deuxième estampille temporelle associée.
  • Par exemple, lorsque la commande est une requête de type SQL (Structure Query Language en anglais) la ou les données peuvent correspondre à un ou plusieurs enregistrements d’une base de données (une ligne ou plusieurs lignes de la base de données). La deuxième estampille temporelle peut alors correspondre à une information sur la chronologie de l’écriture de la donnée au sein de la base de données comme par exemple l’index de la base de données lorsque celle-ci est seulement accessible en écriture (pas de suppression d’enregistrement/donnée/ligne au sein de la base de données) ou bien à un horodatage de la donnée elle-même. La signature électronique peut quant à elle correspondre à la signature électronique de l’entité qui alimente la base de données.
  • Lorsque la ou les données obtenues ne sont pas comprises dans le premier résultat d’exécution de la requête, le procédé vérifie la validité des données reçues via la réalisation de plusieurs tests. Le premier test consiste à vérifier que la signature associée à une donnée est bien valide. Bien évidement cela suppose que le procédé dispose de clef(s) cryptographique(s) (privé et/ou publique) permettant cette vérification. Le deuxième test a pour but de vérifier que les données reçues sont bien antérieures à la création ou à l’émission de la requête. Pour cela le procédé vérifie que l’estampille temporelle de la requête est bien postérieure aux estampilles temporelles des données. Enfin, le procédé vérifie également que les données reçues correspondent bien à une réponse valide de la requête. Dans le cas où les données reçues correspondent à une ou plusieurs lignes d’une base de données, le procédé vérifie que l’ensemble des données correspondent à un résultat possible d’exécution de la commande SQL.
  • On entend par commande une instruction informatique permettant l’exécution d’un ordre, d’une action ou d’une suite d’ordres et d’actions.
  • On entend par signature électronique (ou signature numérique) une suite de caractères permettant d’authentifier l’auteur d’une donnée (par exemple l’entité qui a ajouté une donnée à une base de données) et d’en garantir l’authenticité. La signature électronique peut également permettre de garantir l’inaltérabilité de la donnée une fois celle-ci signée par l’entité qui la détient/partage. De façon connue, l'essentiel des procédures de signature numérique existantes s’appuie sur la cryptographie asymétrique comme l’algorithme RSA.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de vérification est suivie par une étape d’émission d’une notification de validité de ladite au moins une donnée.
  • Ce mode de réalisation permet d’informer/notifier un utilisateur de la chaîne de blocs (oracle ou non) de la validité ou de la non-validité des données obtenues.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite étape de vérification est précédée d’une étape d’obtention (E20) d’un paramètre dont la valeur correspond à un montant financier et en ce que lorsque le résultat de ladite vérification est positif tout ou partie de la valeur dudit paramètre est émis (E120, E121) à destination d’un utilisateur de ladite chaîne de blocs.
  • Ce mode de réalisation permet de rémunérer un utilisateur (par exemple un deuxième oracle) de la chaîne de blocs lorsque celui-ci fournit/trouve une donnée valide (c’est-à-dire une donnée qui correspond à tout ou partie d’un résultat possible d’exécution de la commande) non transmise par l’oracle. Pour ce faire le procédé obtient, par exemple du premier oracle, un paramètre dont la valeur correspond à un montant financier. La valeur du paramètre peut correspondre à un montant libellé dans une monnaie d’un pays, à un nombre défini de jetons d’une cryptomonnaie ou plus généralement à une valeur marchande quelconque (par exemple des jetons de calcul d’un serveur informatique). Concrètement, le paramètre peut être assimilé à une caution/séquestre consentie par l’oracle en cas d’erreur de celui-ci. Lorsqu’une erreur est avérée tout ou partie de la caution est reversée à l’utilisateur (par exemple sur un de ses contrats intelligent) qui a permis de détecter l’erreur, c’est-à-dire à l’utilisateur qui a fourni au procédé une donnée valide non transmise par l’oracle.
  • L'invention concerne également un dispositif de vérification d’au moins une première donnée obtenue depuis un service de fourniture de données caractérisé en ce qu’il comprend :
    • un premier module d’obtention d’une commande émise à destination dudit service ;
    • un deuxième module d’obtention de ladite moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service ;
    • un troisième module d’obtention d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ;
    • un module de vérification de ladite au moins une première donnée en fonction dudit deuxième résultat.
  • Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
  • L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de vérification et/ou de validation décrits ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
  • L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
  • Ce dispositif de vérification et le programme d'ordinateur mettant en œuvre le procédé de vérification présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de vérification.
  • Le programme d'ordinateur mettant en œuvre le procédé de validation présente des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de validation.
  • 4. Liste des figures
  • D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
  • La illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention ;
  • La représente l’architecture matérielle d’un dispositif de vérification selon un mode particulier de réalisation.
  • La représente sous forme d’organigramme les principales étapes des procédés de vérification et de validation selon un mode particulier de réalisation de l’invention,
  • 5. Description d'un mode de réalisation de l'invention
  • La illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation. L’environnement représenté en comprend une chaîne de blocs BC et une base de données BDD. L’environnement comprend aussi deux terminaux O et BH appartenant à des utilisateurs de la chaîne de blocs aptes à fournir à la chaîne de blocs des données externes à la chaîne de blocs. Le terminal O appartient par exemple à un oracle. Le terminal BH intègre un dispositif de vérification apte à mettre en œuvre le procédé de vérification et peut également appartenir à un oracle. L’environnement comprend en outre un terminal S appartenant à un utilisateur de la chaîne de blocs BC.
  • La chaîne de blocs BC et/ ou un contrat intelligent inscrit à la chaîne de blocs BC est apte à mettre en œuvre le procédé de validation.
  • Les terminaux O, S et BH sont par exemple des terminaux de type smartphone (téléphone intelligent en anglais), tablette, serveur, télévision connectée, objet connecté, ordinateur de bord d’une voiture, ordinateur personnel ou tout autre terminal apte à communiquer (émettre et/ou recevoir des requêtes) selon les technologies de l’état l’art via par exemple un réseau IP (100), le réseau pouvant être privé ou public.
  • Selon un mode particulier de réalisation de l'invention, la chaîne de blocs BC peut être hébergée par un ou plusieurs serveurs informatiques.
  • La illustre un dispositif DISP configuré pour mettre en œuvre le procédé de vérification selon un mode particulier de réalisation de l'invention. Le dispositif DISP a l'architecture classique d'un ordinateur, et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les étapes du procédé de vérification tel que décrit ultérieurement à l’appui de la , lorsque le programme est exécuté par le processeur PROC.
  • A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de vérification selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la et selon les instructions du programme d'ordinateur PG.
  • Le dispositif DISP comprend un premier module d’obtention OBT1 apte à obtenir une commande émise à destination d’un service de fourniture de données comme par exemple un oracle d’une chaîne de blocs. La commande peut être obtenue depuis un utilisateur de la chaîne de blocs ou bien depuis un contrat intelligent inscrit à la chaîne de blocs.
  • Le dispositif DISP comprend aussi un deuxième module d’obtention OBT2 apte à obtenir au moins une donnée correspondant à un résultat d’exécution de la commande par le service de fourniture de données.
  • Le dispositif DISP comprend également un troisième module d’obtention OBT3 apte à obtenir un deuxième résultat d’exécution de ladite commande. Le deuxième résultat est par exemple obtenu par le dispositif DISP à la suite de l’exécution de la commande par le procédé de vérification.
  • Le dispositif DISP comprend en outre un module de vérification VERIF de la ou des données obtenues via le module OBT2. La vérification est par exemple réalisée par comparaison de la ou des données avec le deuxième résultat obtenu via le module OBT3.
  • La illustre des étapes des procédé de vérification et de validation selon un mode particulier de réalisation de l'invention en lien avec l’environnement de mise en œuvre décrit à l’appui de la .
  • Lors de l’étape E30, l’oracle O émet à destination d’un contrat intelligent SCV un paramètre dont la valeur correspond à un montant financier, par exemple un nombre de jetons d’une monnaie cryptographique, un nombre de jetons offrant des crédits d’utilisation de la chaîne de blocs BC ou un montant libellé dans une monnaie officielle d’un pays (Euro, Dollars, etc.). Concrètement, l’oracle O transfère une somme d’argent au contrat intelligent SCV. Cet argent peut être vu comme une caution concédée par l’oracle O permettant par exemple de garantir une certaine qualité de service / d’exécution d’action(s) de sa part. Lorsque l’oracle commet une erreur, la caution peut être utilisée pour dédommager le client et/ou rémunérer l’acteur qui a détecté l’erreur. Le paramètre est reçu par le contrat intelligent SCV lors de l’étape E20.
  • A l’étape E21 le contrat intelligent SCV obtient depuis le terminal S d’un client une commande dont le destinataire est l’oracle O (non représenté). Le contrat intelligent SCV obtient également une première estampille temporelle associée à la commande reçue. Cette estampille correspond par exemple à la date à laquelle la commande a été reçue par le contrat intelligent SCV et/ou à un numéro de bloc de la chaîne de blocs BC associé à la commande. Alternativement, l’estampille temporelle peut correspondre à la date de création la commande et/ou d’émission par le terminal S.
  • Alternativement, la commande est obtenue depuis un contrat intelligent du client (SCC). La commande est par exemple obtenue via ou à la suite de la réception d’un évènement diffusé au sein de la chaîne de blocs indiquant l’émission, par le contrat intelligent du client, de la commande à destination de l’oracle O.
  • Selon un mode particulier de réalisation de l’invention, le contrat intelligent SCV relaie la commande obtenue du terminal S du client ou du contrat intelligent SCC à destination de l’oracle et du terminal BH. Alternativement, la commande est obtenue par le terminal BH via ou à la suite de la réception d’un évènement diffusé au sein de la chaîne de blocs indiquant l’émission de la commande à destination de l’oracle O.
  • La commande est obtenue par l’oracle O et le terminal BH respectivement aux étapes E31 et E41. Lors de l’étape E32, l’oracle exécute la commande. La commande est par exemple apte à obtenir un ensemble de lignes d’un tableau stocké dans un espace de stockage numérique tel qu’un fichier, une base de données BDD, etc. Par exemple, la commande peut correspondre à une requête effectuée dans un langage informatique de type SQL, NoSQL, OQL, Prolog ou à une liste de paramètres de filtrage permettant d’obtenir, depuis la base de données BDD, un ou de plusieurs enregistrements (i.e. lignes).
  • Prenons le cas d’une requête SQL de données météo. La base de données/table BDD peut correspondre à :
    Index Latitude Longitude Température Précipitation
    (Millimètre)     		Date Signature
    1 40.77 -73.96 15°C 5mm D1 S1
    2 40.77 -73.96 8°C 8mm D2 S2
    3 40.77 -73.96 6°C 7mm D3 S3
    4 40.77 -73.96 11°C 0mm D4 S4
    5 40.77 -73.96 9°C 0mm D5 S5
  • La base de données BDD stocke de façon chronologique les relevés de température et de pluviométrie d’une station météo identifiée par sa position GPS (latitude, longitude). Chaque nouvel enregistrement ajouté à la table BDD (index +1) est associé à une signature électronique Sn du service qui a inscrit les informations dans la table et à une donnée de temps Dn (deuxième estampille temporelle au sens de l’invention) indiquant par exemple la date des mesures de température et de pluviométrie. Dans notre cas la signature électronique peut correspondre à la signature du service de météorologie national du pays ou de la localité qui gère la station météo en question.
  • Alternativement, la signature peut correspondre à une empreinte numérique (par exemple un hash) d’une donnée unique appartenant au signataire et stockée dans un de ses contrats intelligent au sein de la chaîne de blocs.
  • La base de données obtient la requête SQL à l’étape E52 et envoie le résultat à destination de l’oracle O lors de l’étape E53.
  • Dans notre exemple la requête SQL peut être :
  • Select * From BDD where Index ≥ 2
  • Une fois le résultat reçu par l’oracle O (E33), celui-ci le retransmet (E34) à destination du contrat intelligent SCV. Le résultat reçu par le contrat intelligent SCV lors de l’étape E24 peut par exemple correspondre à :
    Index Latitude Longitude Température Précipitation
    (Millimètre)     		Date Signature
    2 40.77 -73.96 8°C 8mm D2 S2
    3 40.77 -73.96 6°C 7mm D3 S3
    4 40.77 -73.96 11°C 0mm D4 S4
  • Dans l’exemple décrit ci-dessus l’enregistrement de l’index 5 n’est pas présent alors qu’il correspond également un résultat possible de la requête/commande SQL. Le résultat fournit par l’oracle O est donc partiel (erreur par omission). Cette erreur peut être fortuite (problème d’intégrité des données suite à un problème technique / réseau ou bien provoquée par l’oracle par exemple lorsque celui-ci optimise ses processus pour aller plus vite avec pour conséquence un manque de vérification et une qualité de traitement plus faible.
  • Les informations étant fournies par une entité dite de confiance, c’est-à-dire l’oracle O, le contrat intelligent SCV peut ne pas réaliser de test de validité.
  • Selon un mode particulier de réalisation de l’invention, le contrat intelligent SCV peut tester la ou les signatures des données reçues de l’oracle O (résultat de la commande reçu lors de l’étape E24).
  • Le contrat intelligent SCV envoie (E24_1) à destination du contrat intelligent du client SCC le résultat de la commande obtenu de l’oracle O, le résultat étant reçu par le contrat intelligent du client SCC à l’étape E14_1. Bien évidemment cela suppose que le contrat intelligent SCV connaisse l’adresse électronique du contrat intelligent SCC. L’adresse du contrat intelligent SCC est par exemple obtenue lorsque la commande est reçue depuis le contrat intelligent du client SCC (E21). Alternativement, l’adresse électronique du contrat intelligent SCC est envoyée depuis le terminal S en même temps que la commande (E21).
  • Dans le cas où les signatures sont testées et qu’elles ne sont pas valides le contrat intelligent SCV envoie (E24_1) en remplacement ou en plus du résultat de la commande un paramètre indiquant que les données envoyées ne sont pas valides.
  • Lors de l’étape E45, le terminal BH envoie une demande au contrat intelligent SCC pour obtenir le résultat de la commande fourni par l’oracle au contrat intelligent SCC.
  • Selon un mode particulier de réalisation de l’invention, l’envoi de la demande peut être émis suite à la réception (par exemple depuis la chaîne de blocs ou depuis le terminal S) par le terminal BH d’un évènement indiquant que le contrat intelligent SCCet/ou SCV a reçu le résultat de la commande en provenance de l’oracle O.
  • Alternativement, le terminal BH envoie une demande au contrat intelligent SCV pour obtenir le résultat de la commande fourni par l’oracle.
  • La demande est reçue par le contrat intelligent SCC à l’étape E15. Le résultat reçu lors de l’étape E14_1 est ensuite transmis au terminal BH (E16) puis reçu par le terminal BH lors de l’étape E46. A ce stade le terminal BH dispose de la commande reçue lors de l’étape E41 et du résultat de la commande fourni par l’oracle O lors de l’étape E46. Le terminal BH peut alors vérifier le résultat par exemple pour le compte de l’utilisateur du terminal S. Ainsi, lors de l’étape E47, le terminal BH émet la commande à destination de la base de données BDD. La commande est reçue par la base de données lors de l’étape E57. Le résultat de la commande est obtenu par la base de données BDD lors de l’étape E58 puis transmis au terminal BH à l’étape E48. Le terminal BH compare (E49) ensuite les deux résultats de la commande obtenus respectivement lors des étapes E46 et E48 afin de vérifier le résultat transmis par l’oracle O au contrat intelligent SCV. Lorsque les résultats sont identiques le procédé de vérification considère que le résultat fourni par l’oracle O au contrat intelligent SCC/ SCV est valide. Dans le cas contraire le procédé de vérification teste la validité de tout ou partie des données obtenues lors de l’étape E48 auprès de la chaîne de blocs et plus particulièrement auprès du contrat intelligent SCV qui met en œuvre le procédé de validation. Concrètement, le terminal BH émet (E49) une demande de validation de tout ou partie des données obtenues lors de l’étape E48 à destination du contrat intelligent SCV. La demande est reçue puis traitée par le contrat intelligent SCV à l’étape E29. Concrètement le contrat intelligent SCV réalise (cumulativement ou alternativement) trois tests afin de déterminer si les données reçues du terminal BH sont valides.
  • Le premier test consiste à vérifier que la signature (Sn) associée à chaque donnée reçue (enregistrement) est bien valide. Bien évidement cela suppose que le procédé dispose de clef(s) cryptographique(s) (privé et/ou publique) permettant cette vérification. Le deuxième test a pour but de vérifier que les données reçues sont bien antérieures à la création ou à l’émission de la requête. Pour cela le procédé vérifie que l’estampille temporelle de la commande est bien postérieure aux estampilles temporelles des données reçues du terminal BH. Enfin, le procédé vérifie également que les données reçues correspondent bien à une réponse valide de la requête. Dans notre exemple, le procédé vérifie que les données reçues correspondent à un résultat possible d’exécution de la commande SQL. Concrètement, le procédé vérifie que l’index de la donnée reçue du terminal BH est bien ≥ 2.
  • Alternativement, la comparaison des résultats de la commande obtenus respectivement lors des étapes E46 et E48 et réalisée par le terminal BH peut être réalisée par le contrat intelligent SCV.
  • Selon un mode particulier de réalisation de l’invention, lorsqu’une donnée reçue du terminal BH n’est pas comprise dans le résultat de la commande obtenu de l’oracle (E24) et que cette donnée est déterminée comme valide par le contrat intelligent SCV, alors tout ou partie de la caution est reversée au terminal BH (étapes E121, E131) et/ou au client S (étapes E120, E110) via par exemple un transfert de tout ou partie du montant de la caution vers un contrat intelligent du client (SCC) ou du détenteur du terminal BH (SCBH).
  • Bien évidemment, la ou les données valides reçues du terminal BH et non comprises dans le résultat de la commande obtenu de l’oracle (E24) peuvent également être émises à destination du contrat intelligent du client (SCC) lors de l’étape E120.
  • Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention. Selon d'autres modes particuliers de réalisation de l'invention, l'invention s'applique également à des données autres que des données météo comme par exemple des informations de recyclage d’éléments constituant un produit manufacturier permettant par exemple de calculer l'empreinte carbone du produit en question ou bien des informations de traçabilité d’éléments d’un produit comme les pièces d’une automobile.

Claims (8)

  1. Procédé de vérification d’au moins une première donnée obtenue depuis un service de fourniture de données (O), le procédé étant mis en œuvre par un dispositif de vérification (DISP) et caractérisé en ce qu’il comprend les étapes suivantes :
    - obtention (E41) d’une commande émise à destination dudit service ;
    - obtention (E46) de ladite au moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service, ladite au moins une première donnée ayant été émise par ledit service à destination d’une chaîne de blocs (BC) ;
    - obtention (E48) d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ;
    - vérification (E49) de ladite au moins une première donnée en fonction dudit deuxième résultat.
  2. Procédé selon la revendication 1 dans lequel ladite commande est obtenue depuis un premier contrat intelligent (SCV) inscrit à ladite chaîne de blocs et ladite au moins une première donnée est obtenue depuis un deuxième contrat intelligent (SCC) inscrit à ladite chaîne de blocs.
  3. Procédé selon la revendication 1 dans lequel ladite étape de vérification correspond à une comparaison de ladite au moins une première donnée avec ledit deuxième résultat et lorsque le résultat de ladite comparaison est négatif une demande de validité de tout ou partie dudit deuxième résultat est émise (E49) à destination d’un troisième contrat intelligent (SCV) inscrit à ladite chaîne de blocs.
  4. Procédé de validation, par un contrat intelligent (SCV) inscrit à une chaîne de blocs, d’au moins une donnée obtenue depuis un service de fourniture à ladite chaîne de blocs de données externes à ladite chaîne de blocs (O), le procédé étant caractérisé en ce qu’il comprend les étapes suivantes :
    - obtention d’une requête émise à destination dudit service, ladite requête comprenant une première estampille temporelle et une commande ;
    - obtention (E24) d’un premier résultat d’exécution de ladite commande par ledit service ;
    - obtention (E29) de tout ou partie d’un deuxième résultat d’exécution de ladite commande comprenant ladite au moins une donnée associée à une signature électronique et à une deuxième estampille temporelle ;
    et lorsque ladite au moins une donnée n’est pas comprise dans ledit premier résultat
    - vérification (E29) de la validité de ladite au moins une donnée via le contrôle de la validité de ladite signature, de l’antériorité de ladite deuxième estampille temporelle par rapport à ladite première estampille temporelle et de la validité de ladite au moins une donnée comme résultat de ladite commande.
  5. Procédé selon la revendication 4 dans lequel ladite étape de vérification est suivie par une étape d’émission (E120, E121) d’une notification de validité de ladite au moins une donnée.
  6. Procédé selon la revendication 4 dans lequel ladite étape de vérification est précédée d’une étape d’obtention (E20) d’un paramètre dont la valeur correspond à un montant financier et en ce que lorsque le résultat de ladite vérification est positif tout ou partie de la valeur dudit paramètre est émis (E120, E121) à destination d’un utilisateur de ladite chaîne de blocs.
  7. Dispositif de vérification (DISP) d’au moins une première donnée obtenue depuis un service de fourniture de données caractérisé en ce qu’il comprend :
    - un premier module (OBT1) d’obtention d’une commande émise à destination dudit service ;
    - un deuxième module (OBT2) d’obtention de ladite au moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service, ladite au moins une première donnée ayant été émise par ledit service à destination d’une chaîne de blocs (BC) ;
    - un troisième module (OBT3) d’obtention d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ;
    - un module de vérification (VERIF) de ladite au moins une première donnée en fonction dudit deuxième résultat.
  8. Programme d'ordinateur comportant des instructions pour la mise en œuvre des procédés de vérification et de validation selon l'une quelconque des revendications 1 à 3 et 4 à 6, lorsque le programme est exécuté par un processeur.
EP24709401.4A 2023-03-15 2024-03-07 Procédé et dispositif de vérification d'au moins une donnée obtenue depuis un service de fourniture de données Pending EP4681108A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2302399A FR3146743A1 (fr) 2023-03-15 2023-03-15 Procédé et dispositif de vérification d’au moins une donnée obtenue depuis un service de fourniture de données
PCT/EP2024/056088 WO2024188823A1 (fr) 2023-03-15 2024-03-07 Procédé et dispositif de vérification d'au moins une donnée obtenue depuis un service de fourniture de données

Publications (1)

Publication Number Publication Date
EP4681108A1 true EP4681108A1 (fr) 2026-01-21

Family

ID=86657581

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24709401.4A Pending EP4681108A1 (fr) 2023-03-15 2024-03-07 Procédé et dispositif de vérification d'au moins une donnée obtenue depuis un service de fourniture de données

Country Status (3)

Country Link
EP (1) EP4681108A1 (fr)
FR (1) FR3146743A1 (fr)
WO (1) WO2024188823A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020120672A1 (fr) * 2018-12-14 2020-06-18 Sony Corporation Nœud de réseau de communication, procédés et terminal mobile
US11269863B2 (en) * 2020-01-23 2022-03-08 International Business Machines Corporation Index structure for blockchain ledger

Also Published As

Publication number Publication date
FR3146743A1 (fr) 2024-09-20
WO2024188823A1 (fr) 2024-09-19

Similar Documents

Publication Publication Date Title
US12555160B2 (en) Externally held account discovery and aggregation
US11138300B2 (en) Multi-factor profile and security fingerprint analysis
WO2002067534A1 (fr) Systeme de paiement electronique a distance
WO2019233951A1 (fr) Une application logicielle et un serveur informatique pour authentifier l'identité d'un créateur de contenu numérique et l'intégrité du contenu du créateur publié
AU2020402602B2 (en) Information deletion assurance system using distributed ledger
CH678986A5 (fr)
FR3061971A1 (fr) Procede d'authentification en deux etapes, dispositif et programme d'ordinateur correspondant
AU2020273345A1 (en) Account verification
FR2958102A1 (fr) Procede et systeme de validation d'une transaction, terminal transactionnel et programme correspondants.
FR2979044A1 (fr) Procede de gestion et de controle de donnees de differents domaines d'identite organises en ensemble structure
WO2024188823A1 (fr) Procédé et dispositif de vérification d'au moins une donnée obtenue depuis un service de fourniture de données
FR3062499A1 (fr) Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
WO2021053300A1 (fr) Procede de transmission d'une information complementaire relative a une transaction financiere
EP4359986B1 (fr) Procédé et dispositif de paiement par chaînes de blocs
WO1997040474A1 (fr) Systeme securise de controle d'acces permettant le transfert d'habilitation a produire des cles
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
FR3040519A1 (fr) Methode de securisation et de verifiabilite d’un vote electronique
FR3052895A1 (fr) Procede d'envoi d'une information de securite
WO1997040473A1 (fr) Systeme securise de controle d'acces permettant l'invalidation automatique de cles electroniques volees ou perdues et/ou le transfert d'habilitation a produire des cles
FR3108818A1 (fr) Procédé et dispositif d’authentification d’un utilisateur auprès d’une application.
CA3163020C (fr) Systeme d'assurance de suppression d'informations utilisant un registre distribue
WO2021165612A1 (fr) Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs
FR3093225A1 (fr) Procédé de gestion d’accès d’un utilisateur à un service vocal, dispositif, système et programmes correspondants
WO2024188822A1 (fr) Procédé et dispositif de paiement confidentiel sur chaîne de blocs
WO2022254117A1 (fr) Procede de gestion d'un registre local d'un noeud appartenant a un ensemble de noeuds contribuant a un registre distribue

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250926

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR