Patent Description:
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, transport systems, etc. - relies on data stored in a distributed database.

Various functionality relying on data stored in the distributed database can be event driven. , one or more functionalities 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 one or more observables of an event. Then, the measurement datasets can be 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.

Accordingly, there is a need for techniques of validating measurement datasets. In particular, there is a need for techniques which overcome or mitigate at least some of the above-identified restrictions and drawbacks.

<CIT> teaches using a redundant set of sensors to identify attacks on a cyber-physical system. Two sets of measurements are collected from two sets of sensors and evaluated for consistency using a "smart contract" running in a blockchain setting. Conditional on the requisite consensus among entities performing such consistency checks being reached, a corresponding entry is entered into a blockchain.

<CIT> teaches securing a fluid distribution system by having a blockchain-based system evaluate data collected from multiple sensors for consistency prior to appending new blocks to a blockchain ledger.

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 one or more first observables of an event; and to obtain, via the communication interface and from a second oracle, a second measurement dataset indicative of one or more second observables of the event, wherein the one or more first observables are different from the one or more second observables; 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 one or more validation measures for at least one of the first measurement dataset or the second measurement dataset, the one or more validation measures being implemented at a distributed database, wherein the one or more validation measures comprise storing a variable indicative of at least one of the results of the comparison, the first measurement dataset, and the second measurement dataset in the distributed database and the first measurement device checking the variable.

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 one or more second observables of an event. The first measurement dataset is indicative of one or more first observables of the event, wherein the one or more first observables are different from the one or more second observables. 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 one or more validation measures for the first measurement dataset and/or the second measurement dataset, depending on a result of the comparison. The one or more validation measures are implemented at a distributed database, wherein the one or more validation measures comprise storing a variable indicative of at least one of the results of the comparison, the first measurement dataset, and the second measurement dataset in the distributed database and the first measurement device checking the variable.

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 one or more first observables of an event; capture a second measurement dataset indicative of one or more 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 one or more validation measures for at least one of the first measurement dataset or the second measurement dataset, the one or more validation measures being 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 which modify data and/or which generate data and/or which 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. By means of the interfaces, it is possible to exchange data (e.g., to receive, communicate, transmit or provide data). By means of an evaluation unit, it is possible to compare, validate, process, assign or calculate data in a computer-implemented and/or automated manner. By means of 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 a 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. By means of 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 which 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 by means of 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 [<NUM>] 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 by means of further checksums from the Merkle tree or the Patricia tree, respectively, e.g., by using the transaction checksums, wherein 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 which 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 which 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 [<NUM>]. 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 - that 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 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 [<NUM>], [<NUM>], [<NUM>].

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., by means of 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 [<NUM>], [<NUM>], [<NUM>]. 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 [<NUM>], [<NUM>], 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. Alternative, 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, measurement data etc.).

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 which 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, wherein the runtime environment or the program code are preferably Turing complete. The program code is preferably executed by the infrastructure of the DBS [<NUM>], [<NUM>]. 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 [<NUM>], [<NUM>] - 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 has been 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 [<NUM>], [<NUM>], [<NUM>]. 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 by means of a directed acyclic graph (DAG), a cryptographic puzzle, a hash graph or a combination of these variants [<NUM>], [<NUM>]. It would also be possible to implement different consensus algorithms. For example, a consensus algorithm can be implemented by means of 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) [<NUM>], [<NUM>]. For example, if a blockchain is used, then this can, in particular, be implemented by a bitcoin-based implementation or an Ethereum-based implementation [<NUM>], [<NUM>], [<NUM>]. 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. , (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" - that 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 [<NUM>]. 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 [<NUM>], [<NUM>], [<NUM>]. 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, Byteball, etc. 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" [<NUM>] or "number used once" [<NUM>]. 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 - that perform operations associated with the DBS, e.g., a blockchain [<NUM>], [<NUM>], [<NUM>]. 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, 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, that 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., by means of 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.

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, service downtime, etc..

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) one or more validation measures 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, wherein 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.

<FIG> schematically illustrates a system <NUM>.

The system <NUM> includes oracles <NUM>, <NUM>. Each one of the oracles <NUM>, <NUM> includes a control circuitry <NUM>. For example, the control circuitry <NUM> 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, to validate the measurement dataset, etc..

In further detail, as illustrated in <FIG>, each one of the oracles <NUM>, <NUM> includes an input interface <NUM>, e.g., a sensor for a hardware oracle or a communication interface for a software-implemented input interface. The input interfaces <NUM> of the oracles <NUM>, <NUM> are configured to measure observables <NUM>, <NUM> of an event <NUM>.

As a general rule, the event <NUM> could be a physical event and the observables <NUM>, <NUM> could be physical observables. It would also be possible that the event <NUM> is a software event, that the observables <NUM>, <NUM> would correspond to software observables <NUM>, <NUM>.

The oracles <NUM>, <NUM> can provide respective measurement dataset <NUM>, <NUM> to a network <NUM>. The measurement dataset <NUM> provided by the oracle <NUM> is indicative of the observable <NUM> of the event <NUM>; while the measurement dataset <NUM> provided by the oracle <NUM> is indicative of the observable <NUM> of the event <NUM>. In particular, it would be possible that the observable <NUM> differs from the observable <NUM>. 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 <NUM> can be obtained. This helps to validate the measurement datasets <NUM>, <NUM>.

As illustrated, in <FIG>, the oracles <NUM>, <NUM> are also directly connected via a backbone communication line <NUM>. This is generally optional. For example, it would be possible that the oracles <NUM>, <NUM> are arranged next to each other, because they observe the same event <NUM>. For example, the oracle <NUM> and the oracle <NUM> may be arranged in the same apparatus or machine. In such scenarios, close-range communication may be used to implement the backbone communication line <NUM>. As a general rule, a data throughput of the backbone communication line <NUM> may be higher than a data throughput of the communication network <NUM>. As a further general rule, a downtime/service availability may be better for the backbone communication line <NUM> if compared to the downtime/data availability of the communication network <NUM>.

Because the network <NUM> can have a limited data throughput, sometimes it is not feasible to include raw measurement data in the measurement datasets <NUM>, <NUM>. Rather, some data compression or data pre-processing may be implemented at the oracles <NUM>, <NUM>, respectively, before transmitting the measurement datasets <NUM>, <NUM> towards the communication network <NUM>.

In the example of <FIG>, the communication network <NUM> is also connected to a distributed database infrastructure <NUM>. The distributed database infrastructure <NUM> includes multiple mining nodes <NUM>-<NUM> that store and access a distributed database <NUM>. For example, a smart contract <NUM> may be implemented on the distributed database <NUM>.

Hereinafter, various examples will be described in connection with an implementation of the distributed database <NUM> as blockchain. However, in other examples, the distributed database <NUM> may be implemented in another manner, e.g., by a blockless distributed database, etc..

Each one of the mining nodes <NUM>-<NUM> can attempt to store variables as transactions in the blockchain <NUM>. The smart contract <NUM> can define self-executable program code; to this end, the mining nodes <NUM>-<NUM> can provide the host environment to execute such program code.

The system <NUM> also includes stakeholder nodes <NUM>, <NUM>. Each stakeholder nodes <NUM>, <NUM> includes a processor <NUM> that can load and execute program code stored by a respective non-volatile memory <NUM>. The stakeholder nodes <NUM>, <NUM> are connected to the networks <NUM> via respective interfaces <NUM>.

The stakeholder nodes <NUM>, <NUM> may be operated by an operator that relies on functionality implemented by, e.g., the smart contract <NUM> of the blockchain <NUM>. Corresponding functionality may rely on the validity of the measurement datasets <NUM>. Therefore, each one of the stakeholder nodes <NUM>-<NUM> is associated with an operator that has an interest in the validation of the measurement datasets <NUM>, <NUM>.

In the example of <FIG>, the system <NUM> also includes a third-party node <NUM>. For example, the third-party node <NUM> could implement supervisory control and data acquisition (SCADA) functionality. The third-party node includes - in a manner comparable to the stakeholder nodes <NUM>, <NUM> - a processor <NUM> that can load and execute program code from a non-volatile memory <NUM>. The third-party node <NUM> is connected to the network <NUM> via an interface <NUM>. The third-party node <NUM> is operated by an operator independent of the operators of the stakeholder nodes <NUM>-<NUM>. Sometimes such an independent operator is referred to a central authority.

The inset of <FIG> also illustrates details with respect to the mining nodes <NUM>-<NUM> of the blockchain infrastructure <NUM> (the inset in <FIG> is illustrated with the dashed lines). Each one of the mining nodes <NUM>-<NUM> includes a processor <NUM>. The processor <NUM> can load program code from a memory <NUM> and can execute the program code. The processor <NUM> can communicate, via an interface <NUM>, e.g., with the network <NUM>. Each one of the mining nodes <NUM>-<NUM> may store a replica of the blockchain <NUM>.

Next, details with respect to the functioning of the system <NUM> will be explained in connection with the following FIGs.

<FIG> is a flowchart of a method according to various examples. The method of <FIG> may be executed by the processor <NUM> of the third-party node <NUM>, upon loading respective program code from the memory <NUM>. It would also be possible that the method of <FIG> is executed by the processor <NUM> of one of the mining nodes <NUM>-<NUM>, upon loading respective program code from the memory <NUM>.

At block <NUM>, a first measurement dataset is obtained. The first measurement dataset is indicative of one or more observables of an event provided by a first oracle. For example, the measurement dataset <NUM> could be obtained from the oracle <NUM> and the measurement dataset <NUM> could be indicative of the physical observable <NUM> of the event <NUM> (cf.

At block <NUM>, 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 <NUM> the first measurement data is obtained. The second measurement data is provided by a second oracle. For example, the measurement dataset <NUM> could be obtained from the oracle <NUM>, wherein the measurement dataset <NUM> is indicative of the observable <NUM> of the event <NUM> (cf.

Next, at block <NUM>, a comparison between the first measurement dataset - obtained at block <NUM> - and the second measurement dataset - obtained at block <NUM> - is triggered.

Block <NUM> could include sending a trigger or request message to execute the comparison. Block <NUM> could also include executing the comparison locally, e.g., at the third-party node <NUM> or the respective mining node <NUM>-<NUM>. For example, block <NUM> could include invoking a corresponding function of a smart contract of a blockchain, e.g., invoking a corresponding function of the smart contract <NUM> of the blockchain <NUM> (cf. In such a scenario, the comparison, in other words, is provided by a smart contract. In other examples, the comparison could be implemented locally at the third-party node <NUM>.

As a general rule, various options are available for implementing the comparison at block <NUM>. 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 <NUM> and <NUM>. 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 that the metric is based on a time shift between capturing of the one or more first observables indicated by the first measurement data and the capturing of the one or more 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 <NUM>, 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 <NUM> or <NUM>, respectively. The one or more validation measures pertain to the first measurement dataset and/or the second measurement dataset. In particular, the one or more validation measures can be implemented at the blockchain, e.g., at the blockchain <NUM>.

In detail, if at block <NUM> 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 <NUM>; otherwise, a negative validation measure can be taken at block <NUM>.

As a general rule, various options are available for implementing positive and negative validation measures, e.g., in connection with blocks <NUM> and <NUM>. To give just a few examples, a positive validation measure that could be taken as part of executing block <NUM> could pertain to storing the first measurement data and/or the second measurement data in the blockchain, e.g., in the blockchain <NUM>. It would also be possible that a flag indicator is appropriately set, the flag indicator being stored in the blockchain, e.g., the blockchain <NUM>. 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 <NUM>, <NUM>. 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 <NUM>, 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.

<FIG> is an signaling flowchart illustrating the functioning of the system <NUM>. For example, the signaling in accordance with <FIG> could implement the method of <FIG>, in particular when executed by the infrastructure <NUM>.

At block <NUM>, the oracle <NUM> captures the measurement dataset <NUM> that is indicative of the observable <NUM> of the event <NUM>.

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 <NUM>, 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 <NUM>. A public-private keying material configuration could be used.

Blocks <NUM> and <NUM> respectively corresponding to blocks <NUM> and <NUM>, but for the oracle <NUM> and the measurement dataset <NUM>.

Next, the oracle <NUM> triggers storing the measurement dataset <NUM> in the blockchain <NUM>. For this, a corresponding request can be transmitted to the blockchain infrastructure <NUM>, e.g., to one or more of the mining nodes <NUM>-<NUM>. One or more of the mining nodes <NUM>-<NUM> can then create a new block to be changed with pre-existing blocks of the blockchain <NUM>, the new block including a variable that includes or is indicative of the measurement dataset <NUM>, see block <NUM>. This can include solving a cryptographic puzzle, e.g., proof-of-work or proof-of-stake.

Blocks <NUM> and <NUM> respectively correspond to blocks <NUM> and <NUM>, but for the oracle <NUM> and the measurement dataset <NUM>.

Next, the comparison between the measurement dataset <NUM> and the measurement dataset <NUM> is performed. This includes, at block <NUM>, the smart contract <NUM> performing a look-up for the variables associated with the measurement dataset <NUM> and the measurement dataset <NUM> and applying a predefined metric <NUM> thereto. The predefined metric <NUM> can be obtained through a negotiation at <NUM> between the stakeholder nodes <NUM>, <NUM>. The metric <NUM> defines how the measurement dataset <NUM> and the measurement dataset <NUM> are compared and what criteria of consensus of the oracles <NUM>, <NUM> are.

Next, at block <NUM>, the result of the comparison in accordance with block <NUM> is checked. Again, this can be functionality that is implemented by the smart contract <NUM>. Block <NUM>, as such, corresponds to block <NUM> (cf.

In case of a positive result of the comparison - i.e., consensus between the oracles <NUM>, <NUM> -, a corresponding variable <NUM> is written to the blockchain <NUM>, at block <NUM>. This variable <NUM> is indicative of the consensus, i.e., the positive result of the comparison. Otherwise, at block <NUM>, a corresponding variable <NUM> indicative of the lack of consensus is written to the blockchain <NUM>.

In block <NUM>, a warning or notification can be triggered, as a settlement process. The warning is issued to the stakeholder nodes <NUM>, <NUM>.

The various blocks <NUM>-<NUM> that have been explained so far correspond to a capturing phase <NUM> and a validation phase <NUM>. During the capturing phase <NUM>, the measurement datasets <NUM>, <NUM> are captured at the oracles <NUM>, <NUM>. During the validation phase <NUM>, it can be checked whether consensus exists between the measurement datasets <NUM>, <NUM> provided by the oracles <NUM>, <NUM>.

As will be appreciated, in the scenario of <FIG> it is possible to implement the validation phase <NUM> in a close temporal relationship with the capturing phase <NUM> of the measurement datasets <NUM>, <NUM>. This has the advantage that un-validated measurement datasets <NUM>, <NUM> can timely be identified. The trust level of the various entries in the blockchain <NUM> can be high. For example, in case a lack of consensus is identified timely after capturing the measurement datasets <NUM>, <NUM>, various counter-measures may be available to the settlement process (that may not be available if the lack of consensus is only identified later). For example, an alternative oracle may be deployed. For example, a measurement dataset may be re-captured. For example, maintenance of the oracles <NUM>, <NUM> may be triggered.

<FIG> also illustrates aspects with respect to an application phase <NUM> in which the measurement datasets <NUM>, <NUM> are used for further processing. Here, the various measurement datasets <NUM>, <NUM> can be retrieved from the blockchain <NUM>. It is then possible to implement certain functionality based on the measurement datasets <NUM>, <NUM> at blocks <NUM> and <NUM>, at the stakeholder nodes <NUM>, <NUM>. Each stakeholder associated with a stakeholder node <NUM>, <NUM> can trust in the correctness of the measurement datasets <NUM>, <NUM> for executing the respective functionality at blocks <NUM>, <NUM>, respectively, because of the validation during the validation phase <NUM>.

<FIG> is a functional flowchart illustrating details with respect to the functioning of the system <NUM> according to <FIG>. For example, the signaling in accordance with the example of <FIG> could implement the method as described in connection with <FIG>, in particular when executed by the third-party node <NUM>.

The example of <FIG> generally corresponds to the example of <FIG>. However, in the example of <FIG>, the comparison is not implemented by the blockchain infrastructure <NUM>, but is rather implemented by the third-party node <NUM>.

In <FIG>, blocks <NUM> and <NUM> correspond to blocks <NUM> and <NUM> according to <FIG>, respectively. Furthermore, blocks <NUM> and <NUM> correspond to blocks <NUM> and <NUM> according to <FIG>.

At block <NUM>, the oracle <NUM> provides the measurement dataset <NUM> to the third-party node <NUM>. At <NUM>, the oracle <NUM> provides the measurement dataset <NUM> to the third-party node <NUM>.

Next, at block <NUM>, the third-party node <NUM> implements the comparison between the measurement dataset <NUM> and the measurement dataset <NUM>. Again, this is based on the metric <NUM> obtained from a corresponding agreement <NUM>.

At block <NUM>, the result of the comparison is checked. Depending on the result, one or more validation measures are taken. In particular, block <NUM> corresponds to block <NUM> according to <FIG>; block <NUM> corresponds to block <NUM> according to <FIG>; and block <NUM> corresponds to block <NUM> according to <FIG>.

In the example of <FIG>, the application phase <NUM> corresponds to the application phase <NUM> of the example of <FIG>.

<FIG> is a flowchart of a method according to various examples. For example, the method of <FIG> could be executed by the control circuitry <NUM> of the oracle <NUM>, e.g., upon loading program code from an associated memory.

At block <NUM>, second sensor data is captured. This can include obtaining a readout of a corresponding sensor, e.g., sensor <NUM> of the oracle <NUM> (cf. For example, block <NUM> can include sampling a corresponding physical observable at a sampling rate.

At block <NUM>, a first measurement dataset is obtained. For example, the measurement dataset <NUM> may be obtained from the oracle <NUM>.

Next, at block <NUM>, a comparison is implemented between the first measurement dataset - obtained at block <NUM> - and the second measurement dataset - captured at block <NUM>. Block <NUM> as such corresponds to block <NUM>. In the example of <FIG>, however, the comparison can be implemented locally at the respective oracle.

At block <NUM>, the result of the comparison is checked. Block <NUM> corresponds to block <NUM>. Depending on the result of the comparison, one or more validation measures are taken. Here, blocks <NUM>, <NUM> respectively correspond to blocks <NUM>, <NUM>.

The scenario of <FIG> allows to implement the comparison between the measurement datasets at a low level, i.e., in the signal processing chain close to the data source such as the sensor <NUM> of the respective oracle <NUM>, <NUM> (cf. This can have multiple advantages. Firstly, it would be possible to implement the comparison based on the measurement datasets including raw data points that have not been significantly pre-processed or compressed. For example, a high temporal resolution, without down sampling or low-pass filtering may be subject to the comparison. For example, it may not be required to implement significant analysis to the raw measurement data points, i.e., it may not be required to perform analysis such as object detection, feature detection, down sampling, etc., before implementing the comparison. The reason is that a high throughput, high-availability data communication link can exist between the multiple oracles (cf. <FIG>: backbone communication line <NUM>). A second advantage lies in the close temporal relationship between the capturing of the measurement datasets - e.g., at block <NUM> - and the implementation of the comparison. This limits possible attack vectors: the time window available for manipulation of the measurement datasets is limited if compared to other scenarios in which the measurement datasets are compared by another node (e.g., by a mining node <NUM>-<NUM> of the blockchain infrastructure <NUM>, such as explained in connection with <FIG>; or a third-party node <NUM>, as explained in connection with <FIG>). This low-latency comparison can also be helpful in scenarios in which a service availability between the oracles and the respective nodes implementing the comparison (cf. <FIG>: network <NUM>) is significant; in such scenarios, a buffering of the measurement datasets at the oracles may be required and the comparison can be delayed which opens the attack vectors.

<FIG> is a functional flowchart illustrating details with respect to the functioning of the system <NUM> (cf. For example, the signaling as illustrated in <FIG> could be used to implement the method according to <FIG>.

At block <NUM> the measurement dataset <NUM> is captured. At block <NUM>, the measurement dataset <NUM> is signed. Blocks <NUM>, <NUM> thus corresponds to blocks <NUM>, <NUM>, respectively (cf.

At block <NUM>, the oracle <NUM> provides the measurement dataset <NUM> to the oracle <NUM>, e.g., via the backbone communication line <NUM>.

At block <NUM>, the measurement dataset <NUM> is captured at the oracle <NUM>. Block <NUM> thus corresponds to block <NUM> (cf.

At block <NUM>, the comparison between the measurement dataset <NUM> and the measurement dataset <NUM> is performed at the oracle <NUM>. Block <NUM> thus corresponds to block <NUM> (cf.

At block <NUM>, a result of the comparison is checked and, depending on the result, one or more validation measures are selectively triggered.

In the example of <FIG>, in case of a positive result of the comparison <NUM> - i.e., consensus between the oracles <NUM>, <NUM> - the measurement dataset <NUM> (and, optionally, the measurement dataset <NUM>) is stored in the blockchain <NUM>, block <NUM>. Optionally, the measurement dataset <NUM> may be previously signed, at block <NUM>. As such, block <NUM> corresponds to block <NUM> (cf.

To store the measurement dataset <NUM> (and optionally the measurement dataset <NUM>), the oracle <NUM> provides the measurement dataset <NUM> (and, optionally, the measurement dataset <NUM>) to the blockchain infrastructure <NUM> and the mining nodes <NUM>-<NUM> can chain a new block including a variable indicative of the measurement dataset <NUM> (and, optionally, the measurement dataset <NUM>). As such, the storing of the variable indicative of the measurement dataset <NUM> in the blockchain <NUM> at block <NUM> 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 <NUM>, to store a variable indicative of the measurement dataset <NUM> and/or a variable indicative of the result of the comparison, e.g., a flag (cf. <FIG>: blocks <NUM>, <NUM>).

Next, at block <NUM>, the oracle <NUM> checks the variable in the blockchain <NUM>. For example, the execution of block <NUM> can be triggered by providing the measurement dataset <NUM> at <NUM> to the oracle <NUM>. Alternatively or additionally, block <NUM> could be triggered by storing the measurement dataset <NUM> in the blockchain <NUM> at block <NUM>. For example, the smart contract <NUM> may transmit a respective notification to the oracle <NUM>.

Block <NUM>, i.e., the check implemented by the oracle <NUM>, provides for a measure to verify whether consensus has been validated. If the check at block <NUM> yields a negative result, the oracle <NUM> can trigger a settlement process as block <NUM>. Block <NUM> corresponds to block <NUM> (cf.

The application phase <NUM> of the example of <FIG> corresponds to the application phase <NUM> of <FIG>.

Summarizing, above, techniques have been described which enable to validate consensus between multiple oracles, e.g., between the oracles <NUM> and <NUM> according to the system <NUM> of <FIG>. The consensus can be validated by implementing a comparison between respective measurement datasets. As has been described, according to the various examples multiple options are available for implementing the comparison. In particular, the node and/or a point in time at which the comparison is implemented can vary from option to option. For example, a comparison can be implemented at the oracles (cf. <FIG>), thereby facilitating a low-level comparison of raw measurement data points and in a close temporal context with the capturing of the measurement data points. It would also be possible to implement the comparison at a central authority that is independently operated from the stakeholders of any application implemented based on the measurement datasets, e.g., using a third-party node (cf. <FIG>) or a smart contract implemented in the blockchain (cf.

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, leasing or rent royalties, etc. 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.

Although the invention has been shown and described with respect to certain preferred embodiments, equivalents and modifications will occur to others skilled in the art upon the reading and understanding of the specification.

For illustration, above, various scenarios have been described in which the comparison is implemented in the validation phase <NUM> prior to the application phase <NUM>.

However, in various examples, it would be possible to co-implement the validation phase <NUM> and the application phase <NUM>, cf. In <FIG>, a separate capturing phase <NUM> is defined in which the measurement datasets <NUM>, <NUM> are captured by the oracles <NUM>, <NUM> and respectively written to the blockchain <NUM>. In <FIG>, blocks <NUM> - <NUM> correspond to blocks <NUM> - <NUM> (cf. <FIG>), respectively.

In the scenario of <FIG>, the comparison could be co-implemented with the functionality at block <NUM> and/or block <NUM>, i.e., as additional blocks <NUM> and/or <NUM>. Then, depending on a check of the result of these comparisons at blocks <NUM> and/or <NUM>, a respective settlement process may be triggered at block <NUM>, as a validation measure.

For further illustration, various examples have been described above in connection with an implementation of the blockchain as the blockchain <NUM>. Similar techniques may be readily applied for other kinds and types of blockchains.

Claim 1:
A method, comprising:
- obtaining, at a second measurement device (<NUM>), a first measurement dataset (<NUM>) indicative of one or more first observables (<NUM>) of an event (<NUM>), the first measurement dataset (<NUM>) being provided by a first measurement device (<NUM>),
- capturing, at the second measurement device (<NUM>), a second measurement dataset (<NUM>) indicative of one or more second observables (<NUM>) of the event (<NUM>),
wherein the one or more first observables (<NUM>) are different from the one or more second observables (<NUM>),
- performing, at the second measurement device (<NUM>), a comparison between the first measurement dataset (<NUM>) and the second measurement dataset (<NUM>), and
- depending on a result of the comparison: selectively triggering one or more validation measures for at least one of the first measurement dataset (<NUM>) or the second measurement dataset (<NUM>), the one or more validation measures being implemented at a distributed database (<NUM>),
wherein the one or more validation measures comprise storing a variable indicative of at least one of the results of the comparison, the first measurement dataset (<NUM>), and the second measurement dataset (<NUM>) in the distributed database (<NUM>) and
- the first measurement device (<NUM>) checking the variable.