Patent Application
20220147774
The invention relates to a method for validating a measurement dataset and, more particularly, to validating measurement datasets using at least one validation measure implemented at a distributed database, such as a blockchain.
Distributed databases, such as the blockchain, offer increased security against manipulation of data. Thus, various functionality, e.g., sense and control functionality in industrial environments, control of electrical grids, and/or transport systems, relies on data stored in a distributed database.
Various functionality relying on data stored in the distributed database can be event driven. That is, at least one functionality can be triggered by and/or depend on events external to the distributed database, i.e., based on external data. To this end, measurement devices, sometimes also referred to as oracles, are known. Oracles can provide measurement datasets indicative of at least one observables of an event. The measurement datasets can be then stored in the distributed database. Logic functionality can depend on these measurement datasets.
The validity/integrity of measurement datasets can sometimes be compromised. This can be due, e.g., a malfunctioning oracle or fraud. Such limited validity of the measurement datasets can also compromise the integrity of the data stored in the distributed database or any functionality depending on the measurement dataset.
In view of the foregoing, it is therefore an object of the invention to provide a method for validating measurement datasets, which particularly overcome or mitigate at least some of the above-identified restrictions and drawbacks.
This and over objects and advantages are achieved in accordance with the invention by a method that includes obtaining a first measurement dataset indicative of at least one observables of an event. The first measurement dataset is obtained at a node. The first measurement dataset is provided by a first oracle. The method also includes obtaining, at the node, a second measurement dataset. The second measurement dataset is indicative of at least one second observables of the event. The second measurement dataset is provided by a second oracle. The method further includes triggering a comparison between the first measurement dataset and the second measurement dataset. The method also includes selectively triggering at least one validation measure for either the first measurement dataset and/or the second measurement dataset. The at least one validation measure is implemented at a distributed database.
A computer program or a computer-program product or a computer-readable storage medium includes program code. The program code can be executed by at least one processor. Executing the program code can cause the at least one processor to perform a method. The method includes obtaining a first measurement dataset indicative of at least one observables of an event. The first measurement dataset is obtained at a node. The first measurement dataset is provided by a first oracle. The method also includes obtaining, at the node, a second measurement dataset. The second measurement dataset is indicative of at least one second observables of the event. The second measurement dataset is provided by a second oracle. The method further includes triggering a comparison between the first measurement dataset and the second measurement dataset. The method also includes selectively triggering at least one validation measure for either the first measurement dataset and/or the second measurement dataset. The at least one validation measure is implemented at a distributed database.
A node includes a communication interface and at least one processor. The at least one processor is configured to: obtain, via the communication interface and from a first oracle, a first measurement dataset indicative of at least one first observables of an event; and to obtain, via the communication interface and from a second oracle, a second measurement dataset indicative of at least one second observables of the event; and to trigger a comparison between the first measurement dataset and the second measurement dataset; and depending on a result of the comparison, to selectively trigger at least one validation measure for at least one of the first measurement dataset or the second measurement dataset, where the one or more validation measures is implemented at a distributed database.
A method includes capturing a second measurement dataset at a second oracle. The method also includes obtaining a first measurement dataset at the second oracle. The second measurement dataset is indicative of at least one second observables of an event. The first measurement dataset is indicative of at least one first observables of the event. The first measurement dataset is provided by a first oracle. The method also includes performing a comparison between the first measurement dataset and the second measurement dataset, at the second oracle. The method also includes selectively triggering at least one validation measure for either the first measurement dataset and/or the second measurement dataset, depending on a result of the comparison. The at least one validation measures are implemented at a distributed database.
A computer program or a computer-program product or a computer-readable storage medium includes program code. The program code can be executed by at least one processor. Executing the program code can cause the at least one processor to perform a method. The method includes capturing a second measurement dataset at a second oracle. The method also includes obtaining a first measurement dataset at the second oracle. The second measurement dataset is indicative of at least one second observables of an event. The first measurement dataset is indicative of at least one first observables of the event. The first measurement dataset is provided by a first oracle. The method also includes performing a comparison between the first measurement dataset and the second measurement dataset, at the second oracle. The method also includes selectively triggering at least one validation measure for either the first measurement dataset and/or the second measurement dataset, depending on a result of the comparison. The at least one validation measure is implemented at a distributed database.
An oracle includes a communication interface and at least one processor. The at least one processor is configured to obtain, via the communication interface and from a further oracle, a first measurement dataset indicative of at least one first observables of an event; capture a second measurement dataset indicative of at least one second observables of the event; perform a comparison between the first measurement dataset and the second measurement dataset; and depending on a result of the comparison, selectively trigger at least one validation measure for at least one of the first measurement dataset or the second measurement dataset, where the at least one validation measure is implemented at a distributed database.
Unless explicitly stated otherwise the terms “perform”, “calculate”, “computer-implemented”, “calculate”, “establish”, “generate”, “configure”, “reconstruct” and the like preferably relate to actions and/or processes and/or processing steps that modify data and/or that generate data and/or that transform data in other data. Data can be represented by physical quantities or be present as physical quantities, e.g., as electrical pulses. In particular, the term “computer” should be interpreted broadly to cover all electronic devices having data processing capabilities. Computers can, thus, be implemented by personal computers, servers, memory programmable controllers, handheld computer systems, pocket PC devices, wireless communication devices and other communication devices that can process data, processors and other electronic devices for processing data.
In the context of the present disclosure, “computer-implemented” can relate to an implementation of a method in which a processor performs at least one method step.
A processor in the context of the present disclosure can be a machine or electronic circuit. A processor can be specifically implemented by a central processing unit (CPU) or a microprocessor or a microcontroller, e.g., an application-specific integrated circuit (ASIC) or a digital signal processor, possibly in combination with a memory unit for storing program code, etc. A processor can alternatively or additionally be implemented by an integrated circuit (IC), specifically a field programmable gate array (FPGA), an ASIC or a digital signal processor (DSP) or a graphic processing unit (GPU). Alternatively or additionally, a processor can be implemented by a virtual processor or a virtual machine or a soft CPU. A processor can be implemented by a programmable processor having configuration interfaces that facilitate configuration of various techniques described herein. The programmable processor can be configured to implement method steps as described herein, components, modules, or other aspects of the techniques described herein.
A “memory unit” or “memory module” or the like can be implemented by a volatile memory in the form of random access memory (RAM) or a non-volatile memory, such as a hard disc or data carrier.
A “module”, in the context of the present disclosure, can be implemented by a processor and/or a memory unit for storing program instructions. A module can be implemented in hardware and/or software and/or firmware. For example, the processor can be configured to execute the program instructions such that the processor executes functions that implement methods or steps of a method as described herein. A module can also be a node of a distributed database (DBS) that implements specific functions/features of the respective module. The respective modules can, e.g., be implemented as separate/individual modules. For this, the respective modules can include further elements. For example, these further elements can be one or more interfaces (e.g., database interfaces, communication interfaces, e.g., a network interface or WLAN interface) and/or an evaluation unit (e.g., a processor) and/or a memory unit. With the interfaces, it is possible to exchange data (e.g., to receive, communicate, transmit or provide data). With an evaluation unit, it is possible to compare, validate, process, assign or calculate data in a computer-implemented and/or automated manner. With the memory unit, data can be stored, retrieved or provided in a computer-implemented and/or automated manner. It would also be possible that multiple modules are implemented by a common processor.
The term “include”, specifically with respect to data and/or information, can relate to a (computer-implemented) storing of respective information or the respective date in a data structure/data set (which, e.g., in turn is also stored in a memory unit) in the context of the present disclosure.
The term “assign”, specifically in relation to data and/or information, can relate to a computer-implemented assignment of data and/or information in connection with the present disclosure. For example, a first date is assigned, by means of a memory address or a unique identifier, a second date, e.g., by storing the first date together with the memory address or the unique identifier of the second date in a data set.
The term “providing”, in particular in regard to data and/or information, can relate to a computer-implemented providing in connection with the present disclosure. Said providing may be implemented by an interface, e.g., a database interface, a network interface, an interface to a memory unit. It is possible that respective data and/or information are communicated and/or transmitted and/or retrieved and/or received when providing via the interface.
The term “providing” can also relate to the loading or saving, e.g., of a transaction together with respective data in the context of the present disclosure. For example, this can be implemented on or by a memory module.
The term “providing” can also relate to communicating (or transmitting or receiving or transfer) of respective data from a node to another node of the blockchain or the DBS (respectively of the corresponding infrastructure) in the context of the present disclosure.
A “smart-contract process” or “smart-contract functionality” can refer to the execution of program code, e.g., of a control instruction, in a process by means of the DBS or the respective infrastructure.
A “checksum”, e.g., a data-block checksum, a data checksum, a node checksum, a transaction checksum, a chaining checksum or the like can relate to a cryptographic checksum or a cryptographic hash or hash value, in the context of the present disclosure. Such checksums can, in particular, be determined across a data set and/or data and/or one or more transactions and/or a subsection of a data block, e.g., the block header of a block of the blockchain or the data block header of a data block of a DBS or only a part of the transaction of a data block. A checksum can be specifically implemented by a checksum or checksums or a hash value or hash values of a hash tree, e.g., a Merkle tree, a Patricia tree. Moreover, a “checksum” can also be implemented by a digital signature or a cryptographic message authentication code. With checksums, it is possible to implement cryptographic protection/protection against manipulation for transactions and the associated data and datasets on various levels of the DBS. For example, if there is a need for an increased level of security, it would be possible to create and validate checksums on transaction level. For example, if a reduced level of security is required, then it would be possible to create and validate checksums on block level, e.g., across the entire block or only across a part of the data block and/or a part of the transaction.
A “data-block checksum” can relate to a checksum that is calculated across a part or all transactions of a data block in the context of the present disclosure. A node can validate/determine the integrity/authenticity of the respective part of the data block via data-block checksums. Alternatively or additionally, the data-block checksum can also be formed across transactions of a preceding data block/predecessor data block. The data-block checksum can, in particular, be implemented by means of a hash tree, e.g., a Merkle tree [1] or a Patricia tree. Here, the data-block checksum can be the root checksum of the Merkle tree of the Patricia tree or of another binary hash tree. It would be possible that transactions are saved via further checksums from the Merkle tree or the Patricia tree, respectively, e.g., by using the transaction checksums, where in particular the further checksums can relate to leaves of the Merkle tree or the Patricia tree, respectively. The data-block checksum can, thereby, protect the transaction by forming the root checksum from the further checksums. The data-block checksum can, in particular, be calculated for the transactions of a specific data block of the data blocks. In particular, such a data-block checksum can be included in a subsequent data block of the given data block, e.g., to chain this subsequent data block with the preceding data blocks and, in particular to make the integrity of the DBS testable. Thereby, the data-block checksum can implement the chaining checksum or, at least, go into the chaining checksum. The header of a data block (e.g., of a new data block or a data block for which the data-block checksum is determined) can include the data-block checksum.
A “transaction checksum” can relate to a checksum that is determined across a transaction of a data block, in connection with the present disclosure. In addition, the calculation of the data-block checksum of a respective data block can be accelerated, because for this already calculated transactions checksums can be readily used as leaves of a Merkle tree.
A “chaining checksum” in the context of the present disclosure can relate to a checksum that, for the respective data block of a DBS, indicates or references to a preceding data block of the DBS, which is often referred to as “previous block hash” in literature [1]. For this, in particular, a respective chaining checksum is determined for the preceding data block. The chaining checksum can be implemented, e.g., by a transaction checksum or a data-block checksum of a data block, i.e., of an existing data block of the DBS; to thereby chain a new data block with a (existing) data block of the DBS. For example, it would also be possible that a checksum is determined across a header of the preceding data block or across the entire preceding data block to be used as a chaining checksum. For example, this could also be calculated for multiple or all of the preceding data blocks. For example, the chaining checksum could also be implemented by a checksum determined across the header of a data block in the data-block checksum. A respective data block of the DBS includes, however, preferably a chaining checksum that has been calculated or relates to a preceding data block, specifically, the next-neighbor preceding data block directly adjacent to the respective data block. For example, it would also be possible that a respective chaining checksum is determined only across a part of the respective data block, e.g., the preceding data block. Thereby, a data block can be implemented which has an integrity protected part and a non-protected part. Thereby, a data block can be implemented that has a non-changeable integrity protected part and that has a non-protected part that can be modified later on.
Integrity protected can mean that a change of the integrity protected data can be detected by means of a checksum.
Next, example implementations of a transaction are described.
The data, which is, e.g., stored in or written to a transaction of a data block, can be provided in various manners. Instead of data, e.g., user data, such as measurement data or data/ownership structure regarding ASICs, a transaction of a data block can rather include the checksum for such data. The respective checksum can be implemented in various manners. For example, a respective data-block checksum of a data block, e.g., including the respective data, of another database or of the DBS, a transaction checksum of a data block of the respective data, e.g., of the DBS or of another database, or a data checksum determined across the data can be used.
In addition, the respective transaction can optionally include a link to or an indication of a memory position, e.g., an address of a file server and indications of where the respective data are to be found on the file server; or an address of another DBS which includes the data. The respective data could, e.g., also be provided in a further transaction of a further data block of the DBS, e.g., if the respective data and the associated checksums are included in different data blocks. It would also be possible that those data are provided via another communication channel, e.g., via another database and/or a cryptographically-secured communication channel.
Further, it would be possible that in addition to the checksum an add-on data set, e.g., a link or an indication to a memory position, is provided in the respective transaction. The add-on data set can, in particular, indicate where the data can be retrieved. This can be helpful to limit the amount of data of the blockchain or of the DBS.
The term “security protected” can, specifically, relate to a protection that can be implemented by a cryptographic method. For example, this can be implemented by using a DBS for the providing or communication or transmitting of respective data/transactions. This can be implemented by a combination of the various checksums, e.g., cryptographic, by appropriate synergetic interaction between the checksums, to, e.g., increase the security or the cryptographic security for the data of the transactions. In other words, “security protected” in the context of the present disclosure can also relate to “cryptographically protected” and/or “protected against manipulation”, wherein “protected against manipulation” can also be referred to as “protected integrity”.
Insertion of transactions into a DBS can include chaining of data blocks of a DBS. The term “chaining of data blocks of a DBS” in the connection of the present disclosure can relate to the data blocks respectively including information (such as the chaining checksum) which links to another data block or multiple other data blocks of the DBS [1], [4], [5].
Insertion of transactions into a DBS can include saving the transactions in one or more data blocks of the DBS.
Insertion of transactions can include validating and/or confirming transactions.
The term “insertion of transactions into the DBS” or “writing of data to the DBS” and the like can relate to communicating a transaction or transactions or a data block including the transactions to one or more nodes of a DBS. If those transactions are successfully validated, e.g., via the one or more nodes, these transactions can be chained as a new data block with at least one existing data block of the DBS [1], [4], [5]. For this, the respective transactions are stored in a new data block. In particular, this validating and/or chaining can be implemented by a trusted node, e.g., a mining node, a blockchain oracle or a blockchain platform.
In particular, a blockchain can relate to a blockchain as a service, such as has been proposed by Microsoft or IBM. In particular, trusted nodes and/or other nodes can deposit a node checksum, e.g., a digital signature, in a data block, e.g., in a data block that has been validated by the respective node and which is then chained, in particular to facilitate identification of the creator of the data block and/or identification of the node. Here, the node checksum indicates which node has chained the respective data block with at least one other data block of the DBS.
A “transaction” or “transactions” in connection with the present disclosure can relate to a smart contract [4], [5], a data structure or a transaction data set, which, in particular, respectively include a transaction or multiple transactions. The term “transaction” or “transactions” can also relate to the data of a transaction of a data block of a blockchain, in connection with the present disclosure. A transaction can, e.g., include a program code which, e.g., implements a smart contract. For example, a transaction can also relate to a control transaction and/or a confirmation transaction in the context of the present disclosure. Alternatively, a transaction can also be implemented by a data structure which saves the data (e.g., the control instructions and/or the contract data and/or other data such as video data, user data, and/or measurement data).
In particular, the term “saving transactions in data blocks”, “saving transaction” and the like can relate to a direct saving or indirect saving. A direct saving can relate to the respective data block of the DBS or the respective transaction of the DBS including the respective data. An indirect saving can relate to the respective data block or the respective transaction including a checksum and, optionally, an add-on data set, e.g., a link to or an indication of a memory location for respective data; hence, the respective data are not directly saved in the data block (or the transaction). Rather, a checksum is provided for these data in the data block. In particular, these checksums can be validated when saving transactions in data blocks, such as has been explained above with respect to “inserting into the DBS”.
A “program code”, such as a smart contract, can relate to a program instruction or multiple program instructions that are saved in one or more transactions, in connection with the present disclosure. The program code can be executable and can be executed, e.g., by the DBS. This can be implemented, e.g., by a runtime environment, e.g., of a virtual machine, where the runtime environment or the program code are preferably Turing complete. The program code is preferably executed by the infrastructure of the DBS [4], [5]. Here, a virtual machine is implemented by the infrastructure of the DBS. It is possible to execute the program code when validating a corresponding transaction.
A “smart contract” can relate to an executable program code in connection with the present disclosure [4], [5] (see, in particular, explanations with respect to “program code” provided above). The smart contract is preferably saved in a transaction of the DBS, e.g., a blockchain, e.g., in a data block of the DBS. For example, the smart contract can be executed in the same manner as previously described in connection with the definition of “program code”, in particular in connection with the subject disclosure.
The term “proof of work” can relate to solving a computationally expensive task, in particular, depending on the content of a data block or the content of a specific transaction, in connection with the present disclosure [1], [4], [5]. Such a computationally expensive task can also be referred to as cryptographic puzzle.
The term “DBS”, which can also be referred to simply as “distributed database”, can generally relate to a decentralized, distributed database, a blockchain, a distributed ledger, a distributed memory system, a distributed ledger technology (DLT) based system (DLTS), a revision secure database system, a cloud, a cloud-service, a blockchain in a cloud or a peer-to-peer database system, in the context of the present disclosure. Also, various implementations of a blockchain or of a DLTS can be used, e.g., such as a blockchain or a DLTS that is implemented via a directed acyclic graph (DAG), a cryptographic puzzle, a hash graph or a combination of these variants [6], [7]. It would also be possible to implement different consensus algorithms. For example, a consensus algorithm can be implemented via a cryptographic puzzle, a gossip about gossip, a virtual voting or a combination of such techniques (e.g., gossip about gossip combined with virtual voting) [6], [7]. For example, if a blockchain is used, then this can, in particular, be implemented by a bitcoin-based implementation or an Ethereum-based implementation [1], [4], [5]. The term “distributed database” can also relate to a DBS that has at least a part of its nodes and/or devices and/or infrastructure implemented by a cloud. For example, the respective components can be implemented as nodes/devices in the cloud (e.g., as virtual nodes in a virtual machine). This can be implemented by WMware, Amazon web services or Microsoft Azure. Due to the increased flexibility of the described implementation scenarios, it is, in particular, possible to combine partial aspects of the described implementation scenarios with each other, e.g., by using a hash graph as blockchain, wherein the blockchain itself can also be a block batch.
For example, if a directed acyclic graph (DAG) is used (e.g., IOTA or Tangle), transactions or blocks or nodes of the graph are connected with each other via directed edges. That is, (all) edges are (always) having the same direction, e.g., as observed for time. In other words, it is, in particular, not possible to propagate through or visit transactions or blocks or nodes of the graph backwards (i.e., opposite to the common unified direction). Acyclic means, in particular, that there are no loops or ring closures when traversing the graph. For example, a DBS can relate to a public DBS (e.g., a public blockchain) or a closed (private) distributed databased system (e.g., a private blockchain).
For example, in the case of a public DBS, the nodes and/or devices can join the DBS without proof of authorization or authentication or login credentials, respectively be accepted by the DBS without such information. In particular, in such a case the operator of the nodes and/or devices can remain anonymous.
For example, in the case of implementation of the DBS by a closed database system, new nodes and/or devices can require a valid proof of authorization and/or valid authentication information and/or valid credentials and/or valid login information to join the DBS or be accepted by the DBS.
A DBS can also be implemented by a distributed communication system for data exchange. For example, this can be a network or a peer-to-peer network.
The term “data block”, which can be, depending on the context and implementation, also be referred to as “constituent” or “block”, can refer to, in the context of the present disclosure, a data block of a DBS, e.g., a blockchain or a peer-to-peer database, which are, in particular, implemented as a data structure and, preferably, include one of the transactions or multiple of the transactions. In an implementation, the database or the database system can be a DLT based system (DLTS) or a blockchain and the data block can be a block of the blockchain or of the DLTS.
As a general rule, a data block can, e.g., include indications of the size—e.g., data volume in bytes—of the data block, a data block header (block header), a transaction counter and one or more transactions [1]. The data block header can include a version, a chaining checksum, a data-block checksum, a timestamp, a proof of work, a Nonce, i.e., a unique value, a random value or a counter which is used for the proof of work [1], [4], [5]. A data block can, e.g., also simply relate to a respective memory range or address range of the overall data that is stored in the DBS. Thereby, it is possible to implement blockless DBS such as the IOT chain (ITCA), IOTA, and/or Byteball. Here, the functionality of the blocks of a blockchain and of the transactions are combined with each other in such a manner that, e.g., the transactions themselves secure the sequence or chains of transactions of the DBS, such that they are, in particular, saved in a secured manner. For this, the transactions can be chained by means of a chaining checksum, e.g., by using a separate checksum or the transaction checksum of one or more transactions as chaining checksum, which is saved in a new transaction in the DBS when storing the new transaction in the DBS. In such a scenario, a data block can, e.g., also include one or more transactions, wherein in a simple scenario a data block relates to a single transaction.
The term “Nonce” can relate to, in connection with the present disclosure, a cryptographic nonce, which is an abbreviation for “used only once” [2] or “number used once” [3]. In particular, a Nonce indicates individual numbers or a combination of letters that is preferably only used once in the respective context, e.g., transaction, data communication.
The term “preceding data blocks of a (given) data block of the DBS” can relate, in connection with the present disclosure, e.g., to the data block of the DBS that is a direct predecessor of the (given) data block. Alternatively, the term “preceding data blocks of a (given) data block of the DBS” can also relate to all data blocks of the DBS that precede the given data block. Thereby, the chaining checksum or the transaction checksum can be determined across the direct preceding data block (respectively the transactions thereof) or all data blocks preceding the given data block (respectively the respective transactions).
The terms “blockchain node”, “node”, “node of a DBS” and the like can relate, in the context of the present disclosure, to devices, e.g., mobile devices, wireless communication devices, computers, smartphones, clients or participants, which perform operations associated with the DBS, e.g., a blockchain [1], [4], [5]. Such nodes can, e.g., execute transactions of a DBS or the respective data blocks or can insert new data blocks including new transactions into the DBSs by means of new data blocks. In particular, this validation and/or chaining can be implemented by a trusted node, e.g., a mining node, or exclusively by trusted nodes. A trusted node is a node that has additional security measures, e.g., firewalls, access restrictions to the node or the like—to avoid manipulation of the node. Alternatively or additionally, a trusted node can, e.g., save a node checksum, e.g., a digital signature or a certificate, in the new data block when chaining the new data block with the DBS. Thereby, it is possible to provide the proof that indicates that the respective data block has been inserted by a specific node, respectively indicate the originator.
As a general rule, a device or the devices can be implemented by devices of a technical system and/or an industrial plant and/or an automation network and/or a fabrication plant, which can also be nodes of the DBS. Thereby, the devices can be mobile devices or devices of the Internet of things, that can also be nodes of the DBS. Nodes can, e.g., include at least one processor, e.g., to execute their computer-implemented functionality.
The term “blockchain oracle” and the like can relate, in the context of the present disclosure, to nodes, devices or computers that include a security module that has software protection mechanisms, e.g., cryptographic methods, mechanical protection mechanisms, e.g., a lockable housing or electric protection measures, e.g., tamper protection or a protection system that deletes data of the security module in the case of unauthorized use/modification of the blockchain oracle. The security module can include, e.g., cryptographic keys that are required for the calculation of checksums, e.g., of transaction checksums or node checksums.
The term “computer” or “device” can relate to a computer (system), a client, a smartphone, a device or a server that are arranged outside of the blockchain, respectively or are not participants of the DBS, e.g., of the blockchain, i.e., do not execute operations of the DBS or simply retrieve those without executing transactions, inserting data blocks or calculate proof of works. Alternatively, the term “computer” or “device” can also relate to a node of the DBS. In other words, a device can in particular implement a node of the DBS or a device outside of the blockchain and the DBS, respectively. A device outside of the DBS can, e.g., access the data, e.g., the transactions or the control transactions of the DBS. A device outside of the DBS can be controlled by nodes, e.g., via smart contracts and/or blockchain oracles. For example, if a control of a device, e.g., a device implemented as a node or a device outside of the DBS, is implemented by a node, then this can occur via a smart contract which, in particular, is saved in a transaction of the DBS.
Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims. It should be further understood that the drawings are not necessarily drawn to scale and that, unless otherwise indicated, they are merely intended to conceptually illustrate the structures and procedures described herein.
The invention is described by exemplary embodiments in the accomplished figures in detail, in which:
Some examples of the present disclosure generally provide for a plurality of circuits or other electrical devices. All references to the circuits and other electrical devices and the functionality provided by each are not intended to be limited to encompassing only what is illustrated and described herein. While particular labels may be assigned to the various circuits or other electrical devices disclosed, such labels are not intended to limit the scope of operation for the circuits and the other electrical devices. Such circuits and other electrical devices may be combined with each other and/or separated in any manner based on the particular type of electrical implementation that is desired. It is recognized that any circuit or other electrical device disclosed herein may include any number of microcontrollers, a graphics processor unit (GPU), integrated circuits, memory devices (e.g., FLASH, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), or other suitable variants thereof), and software which co-act with one another to perform operation (s) disclosed herein. In addition, any one or more of the electrical devices may be configured to execute a program code that is embodied in a non-transitory computer readable medium programmed to perform any number of the functions as disclosed.
In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are taken to be illustrative only.
The drawings are to be regarded as being schematic representations and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software, or a combination thereof.
Hereinafter, techniques are described that facilitate validating measurement datasets provided by oracles. As a general rule, oracles can be implemented by hardware oracles and/or software oracles. A hardware oracle can measure, e.g., using a sensor, one or more physical observables of a physical event. Examples would include measurement of electrical characteristics, e.g., electrical current or electrical voltage, fluid flow or fluid volume, pressure, temperature, operational activity of an industrial machine such as oil change, operating mode, switch on/switch off, etc.; logistics such as dispatch, waypoint passing, delivery, etc. Software oracles can provide measurement data indicative of software-defined events, e.g., website updates, data availability, and/or service downtime.
Various examples described herein facilitate validating a given measurement dataset based on a consensus between (i) the one or more observables of the given measurement datasets associated with a given event, and (ii) one or more observables of one or more further measurement datasets, also associated with the same given event. Thereby, independent or largely independent information on one and the same event can be obtained and a respective comparison between these measurement datasets can be triggered. Based on the result of the comparison, it would then be possible to trigger or to not trigger (selectively trigger) at least one validation measure for the measurement datasets. These one or more validation measures can be implemented at a distributed database.
Such techniques are based on the finding that by using independent or largely independent measures for one and the same given event, it becomes possible to identify malfunctioning or fraud associated with an oracle. Thus, the trust level for the measurement datasets can be increased.
As a general rule, various options are available for implementing the validation measures. To give a few examples, the validation measures can include validating or invalidating the measurement datasets. For example, a variable may be stored in the distributed database, where the variable is indicative of the positive or negative result of the comparison. It would also be possible that the variable is indicative of the underlying measurement datasets, i.e., it would be possible that the measurement datasets are selectively stored in the distributed database, depending on the result of the comparison. Further, in case of lack of consensus, it would be possible to inform involved stakeholders accordingly, i.e., one or more nodes that would rely on the measurement datasets.
The system 70 includes oracles 101, 102. Each one of the oracles 101, 102 includes a control circuitry 105. For example, the control circuitry 105 could include a processor and a non-volatile memory. The processor could load program code from the non-volatile memory and execute the program code to perform various functionality such as: measuring data for a measurement dataset indicative of one or more physical observables of an event; transmitting the measurement dataset; processing raw data of the measurement dataset; implementing or triggering a comparison between the measurement dataset and further measurement dataset from another oracle, and/or to validate the measurement dataset.
In further detail, as illustrated in
As a general rule, the event 81 could be a physical event and the observables 85, 86 could be physical observables. It would also be possible for the event 81 to be a software event, or for the observables 85, 86 to correspond to software observables 85, 86.
The oracles 101, 102 can provide respective measurement dataset 91, 92 to a network 71. The measurement dataset 91 provided by the oracle 101 is indicative of the observable 85 of the event 81, while the measurement dataset 92 provided by the oracle 102 is indicative of the observable 86 of the event 81. In particular, it would be possible that the observable 85 differs from the observable 86. More generally speaking, different oracles can provide measurement datasets that are indicative of different observables. For example, a first oracle could provide measurement datasets indicative of a temperature, while a second oracle provides measurement datasets indicative of pressure, to give just one example. Thereby, independent information and multiple measures of the event 81 can be obtained. This helps to validate the measurement datasets 91, 92.
As illustrated, in
Because the network 71 can have a limited data throughput, sometimes it is not feasible to include raw measurement data in the measurement datasets 91, 92. Rather, some data compression or data pre-processing may be implemented at the oracles 101, 102, respectively, before transmitting the measurement datasets 91, 92 towards the communication network 71.
In the example of
Hereinafter, various examples will be described in connection with an implementation of the distributed database 159 as blockchain. However, in other examples, the distributed database 159 may be implemented in another manner, e.g., by a blockless distributed database, etc.
Each one of the mining nodes 151, 152, 153 can attempt to store variables as transactions in the blockchain 159. The smart contract 90 can define self-executable program code. To this end, the mining nodes 151, 152, 153 can provide the host environment to execute such program code.
The system 70 also includes stakeholder nodes 111, 112. Each stakeholder nodes 111, 112 includes a processor 115 that can load and execute program code stored by a respective non-volatile memory 117. The stakeholder nodes 111, 112 are connected to the networks 71 via respective interfaces 116.
The stakeholder nodes 111, 112 may be operated by an operator that relies on functionality implemented by, e.g., the smart contract 90 of the blockchain 159. Corresponding functionality may rely on the validity of the measurement datasets 92. Therefore, each one of the stakeholder nodes 111, 112 is associated with an operator that has an interest in the validation of the measurement datasets 91, 92.
In the example of
The inset of
Next, details with respect to the functioning of the system 70 will be explained in connection with the following FIGs.
At block 5001, a first measurement dataset is obtained. The first measurement dataset is indicative of at least one observables of an event provided by a first oracle. For example, the measurement dataset 91 could be obtained from the oracle 101 and the measurement dataset 91 could be indicative of the physical observable 85 of the event 81 (cf.
At block 5002, a second measurement dataset is obtained. The second measurement dataset is indicative of one or more second observables of the event, i.e., the same event for which at block 5001 the first measurement data is obtained. The second measurement data is provided by a second oracle. For example, the measurement dataset 92 could be obtained from the oracle 102, where the measurement dataset 92 is indicative of the observable 86 of the event 81 (cf.
Next, at block 5003, a comparison between the first measurement dataset (obtained at block 5001) and the second measurement dataset (obtained at block 5003) is triggered.
Block 5003 could include sending a trigger or request message to execute the comparison. Block 5003 could also include executing the comparison locally, e.g., at the third-party node 121 or the respective mining node 151, 152, 153. For example, block 5003 could include invoking a corresponding function of a smart contract of a blockchain, e.g., invoking a corresponding function of the smart contract 90 of the blockchain 159 (cf.
In other examples, the comparison could be implemented locally at the third-party node 121.
As a general rule, various options are available for implementing the comparison at block 5003. The comparison can vary along with the type of measurement dataset and, more specifically, with the type of observables indicated by the first and second measurement datasets obtained in block 5001 and 5002. To give an example, it would be possible that the comparison is based on a predefined agreement indicative of a metric of the comparison. The metric can define a ruleset for comparing the various involved measurement datasets and the various involved physical observables. In particular, using an appropriate metric, it is even possible to compare different observables, e.g., temperature with pressure, or operational statistics of a field device with current consumption, to give just a few examples. In some examples, the comparison could be implemented by a machine-learning algorithm that is trained to detect abnormalities in the behavior of the multiple physical observables. In other examples, a predefined rule set could be analytically defined.
For example, a tolerance range could be defined by the metric. The tolerance range may specify certain acceptable ranges of deviation between the first measurement dataset and the second measurement dataset.
Alternatively or additionally, it would be possible to base the metric on a time shift between capturing of the at least one first observables indicated by the first measurement data and the capturing of the at least one second observables indicated by the second measurement dataset. Such techniques can be based on the finding that an increased time shift can limit the possibility of (cross-) validating the first measurement data and the second measurement data, respectively.
Next, at block 5004, a result of the comparison is checked. Depending on the result of the comparison, one or more (Positive or negative) validation measures are selectively triggered at block 5005 or 5006, respectively. The at least one validation measure pertains to the first measurement dataset and/or the second measurement dataset. In particular, the at least one validation measure can be implemented at the blockchain, e.g., at the blockchain 159.
In detail, if at block 5004 it is judged that the comparison yields a positive result, i.e., a (cross-) validation of the first measurement dataset and the second measurement dataset is positively obtained, then a positive validation measured can be taken at block 5005; otherwise, a negative validation measure can be taken at block 5006.
As a general rule, various options are available for implementing positive and negative validation measures, e.g., in connection with blocks 5005 and 5006. To give just a few examples, a positive validation measure that could be taken as part of executing block 5005 could pertain to storing the first measurement data and/or the second measurement data in the blockchain, e.g., in the blockchain 159. It would also be possible for a flag indicator to be appropriately set, where the flag indicator is stored in the blockchain, e.g., the blockchain 159. The flag indicator could indicate whether a (cross-) validation was successful or not. Yet another validation measure may include transmitting a corresponding report message to at least one of the stakeholder nodes 111, 112. Thereby, parties interested in the validation can be appropriately informed.
In case the comparison yields a negative result, it would be possible to trigger, as part of execution of block 5006, a settlement process. The settlement process can include a predefined rule set or workflow for the case of a deviation between the first measurement dataset and the second measurement dataset. For example, the settlement could be associated with a trust level of the first oracle providing the first measurement dataset and/or the trust level of the second oracle providing the second measurement dataset. Then, if there are deviations between the first measurement dataset and the second measurement dataset, the particular measurement dataset may prevail that has the larger associated trust level.
At block 3001, the oracle 101 captures the measurement dataset 91 that is indicative of the observable 85 of the event 81.
As a general rule, measurement datasets as described herein may include a time series of measurement data points. For example, the oracles may sample the events by capturing multiple data points with a certain sampling rate. Some pre-processing of this raw data may occur, when generating the corresponding measurement dataset. For example, filters such as a low-pass filter may be applied. Measurement data points may be integrated.
At block 3002, the measurement dataset is digitally signed, to generally provide a security protection. For example, this can be implemented using cryptographic keying material associated with the oracle 101. A public-private keying material configuration could be used.
Blocks 3003 and 3004 respectively corresponding to blocks 3001 and 3002, but for the oracle 102 and the measurement dataset 92.
Next, the oracle 101 triggers storing the measurement dataset 91 in the blockchain 159. For this, a corresponding request can be transmitted to the blockchain infrastructure 150, e.g., to one or more of the mining nodes 151, 152, 153. One or more of the mining nodes 151, 152, 153 can then create a new block to be changed with pre-existing blocks of the blockchain 159, where the new block includes a variable that includes or is indicative of the measurement dataset 91 (see block 3006). This can include solving a cryptographic puzzle, e.g., proof-of-work or proof-of-stake.
Blocks 3007 and 3008 respectively correspond to blocks 3005 and 3006, but for the oracle 102 and the measurement dataset 92.
Next, the comparison between the measurement dataset 91 and the measurement dataset 92 is performed. This includes, at block 3009, the smart contract 90 performing a look-up for the variables associated with the measurement dataset 91 and the measurement dataset 92 and applying a predefined metric 93 thereto. The predefined metric 93 can be obtained through a negotiation at 3010 between the stakeholder nodes 111, 112. The metric 93 defines how the measurement dataset 91 and the measurement dataset 92 are compared and what criteria of consensus of the oracles 101, 102 are.
Next, at block 3011, the result of the comparison in accordance with block 3009 is checked. Again, this can be functionality that is implemented by the smart contract 90. Block 3011, as such, corresponds to block 5004 (cf.
In case of a positive result of the comparison, i.e., consensus between the oracles 101, 102, a corresponding variable 95 is written to the blockchain 159, at block 3012. This variable 95 is indicative of the consensus, i.e., the positive result of the comparison. Otherwise, at block 3013, a corresponding variable 96 indicative of the lack of consensus is written to the blockchain 159.
In block 3014, a warning or notification can be triggered, as a settlement process. The warning is issued to the stakeholder nodes 111, 112.
The various blocks 3001-3013 that have been explained so far correspond to a capturing phase 6000 and a validation phase 6001. During the capturing phase 6000, the measurement datasets 91, 92 are captured at the oracles 101, 102. During the validation phase 6001, a check can be performed to determine whether consensus exists between the measurement datasets 91, 92 provided by the oracles 101, 102.
As will be appreciated, in the scenario of
The example of
In
At block 3105, the oracle 101 provides the measurement dataset 91 to the third-party node 121. At 3107, the oracle 102 provides the measurement dataset 92 to the third-party node 121.
Next, at block 3109, the third-party node 121 implements the comparison between the measurement dataset 91 and the measurement dataset 92. Again, this is based on the metric 93 obtained from a corresponding agreement 3110.
At block 3111, the result of the comparison is checked. Depending on the result, at least one validation measure is taken. In particular, block 3112 corresponds to block 3012 according to
In the example of
At block 5011, second sensor data is captured. This can include obtaining a readout of a corresponding sensor, e.g., sensor 106 of the oracle 102 (cf.
At block 5012, a first measurement dataset is obtained. For example, the measurement dataset 91 may be obtained from the oracle 101.
Next, at block 5013, a comparison is implemented between the first measurement dataset (obtained at block 5012) and the second measurement dataset (captured at block 5011). Block 5013 as such corresponds to block 5003. In the example of
At block 5014, the result of the comparison is checked. Block 5014 corresponds to block 5004. Depending on the result of the comparison, one or more validation measures are taken.
Here, blocks 5015, 5016 respectively correspond to blocks 5005, 5006.
The scenario of
At block 3201 the measurement dataset 91 is captured. At block 3202, the measurement dataset 91 is signed. Blocks 3201, 3202 thus corresponds to blocks 3001, 3002, respectively (cf.
At block 3205, the oracle 101 provides the measurement dataset 91 to the oracle 102, e.g., via the backbone communication line 72.
At block 3203, the measurement dataset 92 is captured at the oracle 102. Block 3203 thus corresponds to block 3003 (cf.
At block 3209, the comparison between the measurement dataset 91 and the measurement dataset 92 is performed at the oracle 102. Block 3209 thus corresponds to block 3009 (cf.
At block 3211, a result of the comparison is checked and, depending on the result, at least one validation measure is selectively triggered.
In the example of
To store the measurement dataset 91 (and optionally the measurement dataset 92), the oracle 102 provides the measurement dataset 91 (and, optionally, the measurement dataset 92) to the blockchain infrastructure 150 and the mining nodes 151, 152, 153 can chain a new block including a variable indicative of the measurement dataset 91 (and, optionally, the measurement dataset 92). As such, the storing of the variable indicative of the measurement dataset 91 in the blockchain 159 at block 3206 corresponds to a validation measure taken in case of a positive result of the comparison. As a general rule, it would be possible, alternatively or additionally to storing the variable indicative of the measurement dataset 91, to store a variable indicative of the measurement dataset 92 and/or a variable indicative of the result of the comparison, e.g., a flag (cf.
Next, at block 3220, the oracle 101 checks the variable in the blockchain 159. For example, the execution of block 3220 can be triggered by providing the measurement dataset 91 at 3205 to the oracle 102. Alternatively or additionally, block 3220 could be triggered by storing the measurement dataset 91 in the blockchain 159 at block 3206. For example, the smart contract 90 may transmit a respective notification to the oracle 101.
Block 3220, i.e., the check implemented by the oracle 101, provides for a measure to verify whether consensus has been validated. If the check at block 3220 yields a negative result, the oracle 101 can trigger a settlement process as block 3214. Block 3214 corresponds to block 3014 (cf.
The application phase 6002 of the example of
Summarizing, above, techniques have been described that enable validation of the consensus between multiple oracles, e.g., between the oracles 101 and 102 according to the system 70 of
As a general rule, the techniques described herein may find application in various use-case scenarios. To give a few examples: it would be possible to implement pay-per-use scenarios in electrical power grids. Here, a first oracle may capture measurement datasets indicative of electrical characteristics such as electrical current or electrical voltage of an electrical load, e.g., a pump, connected to the electrical power grid. A second oracle may capture a measurement dataset indicative of another physical observable, e.g., operational characteristics of the load, in the scenario of the pump e.g. flow rate. Thus, multiple independent physical observables of one and the same event, here, operation of the pump, can be obtained. The stakeholders can be associated with the operator of the pump, i.e., the consumer, and the operator of the power grid, i.e., the service provider. Both can have an interest in accurate determination of the electrical power consumption of the pump.
Another use case relates to lifecycle monitoring of an industrial field device, e.g., to determine warranty claims, second-life applications, residual value, and/or leasing or rent royalties. Here, the event can be an oil change at the industrial field device. A first oracle can capture measurement datasets indicative of a user input to a human machine interface of the industrial field device, e.g., pertaining to activation of a service mode associated with the oil change. This would be a software oracle. A second hardware oracle could capture measurement datasets that are indicative of a switch activation at the cover lid of the oil tank of the industrial field device. The comparison can then be based on a plausibility analysis between both measurement datasets. A further measurement dataset associated with a further physical observable could relate to the current consumption of the industrial field device, because it can be expected that the load imposed by the industrial field device is reduced in response to the oil change.
A third use case pertains to tracking of shipping of goods. Here, a first oracle could capture measurement data that is indicative of a first radio frequency identity tag readout at dispatch, while a second oracle could capture a measurement dataset that is indicative of radio frequency identity tag readout at arrival.
For illustration, above, various scenarios have been described in which the comparison is implemented in the validation phase 6001 prior to the application phase 6002. However, in various exemplary embodiments, it would be possible to co-implement the validation phase 6001 and the application phase 6002, cf.
In the scenario of
For further illustration, various examples have been described above in connection with an implementation of the blockchain as the blockchain 159. Similar techniques may be readily applied for other kinds and types of blockchains.
Furthermore, various examples have been described in which separate mining nodes 151, 152, 153 of the blockchain infrastructure 150 are available to store datasets or data in the blockchain 159. In other examples, it would be possible that the oracles 101, 102 also implement mining functionality, i.e., can directly store the datasets or data into the blockchain 159.
Thus, while there have been shown, described and pointed out fundamental novel features of the invention as applied to a preferred embodiment thereof, it will be understood that various omissions and substitutions and changes in the form and details of the methods described and the devices illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Moreover, it should be recognized that structures and/or elements and/or method steps shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.
| Number | Date | Country | Kind |
|---|---|---|---|
| 19169157.5 | Apr 2019 | EP | regional |
This is a U.S. national stage of application No. PCT/EP2020/060241 filed 9 Apr. 2020. Priority is claimed on European Application No. 19169157.5 filed 15 Apr. 2019, the content of which is incorporated herein by reference in its entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2020/060241 | 4/9/2020 | WO | 00 |
