Computer-implemented system and method for connecting blockchain with digital twin set

Abstract

A computer-implemented method and system is described that uses blockchain technology as a storage system for data retrieved from a digital twin set. A blockchain may be used to generate an immutable transaction history of data generated by a digital twin set. In the event of an error or failure, the relevant party can access and analyze the immutable data record. The method can be used in combination with a block chain protocol.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201880071730.7 (PCT international application number PCT / IB2018 / 058258), application date October 23, 2018, and name “Computer-implemented system and method for connecting blockchain and digital twin collection”. Technical Field

[0002] The present specification generally relates to computer-implemented methods and systems suitable for implementation with a blockchain network. The present invention also relates to security, integrity, and efficiency in computer-implemented systems. Background Art

[0003] The design of industrial assets relies on various models and a large number of data sources. Data scientists process large amounts of data, while specialized teams create models and perform analyses for their specific tasks. The latest information and calculations may not be immediately available for critical decisions, and this siloed way of working leads to cost and inefficiency, creates uncertainty, and wastes a lot of time and resources.

[0004] A digital twin is a virtual, dynamic replica of a real object, process, or service that allows testing and prevention of errors or failures. Digital twins can be created of products, mechanical parts of aircraft or cars, production processes, and more. Digital twins can be seen as a revolutionary combination of simulation, real-time data, and response.

[0005] Simulating the behavior of a process or system assumes knowledge of how all variables involved in the simulation behaved in the past, as well as observation of the system under test over a sufficiently large time frame and recording of all input / output variables. Knowledge of the past is a prerequisite for building a good simulator. The possibility of adding real-time information to this process can significantly improve the precision and accuracy of the entire simulation, until the exact behavior of the system or process is reflected.

[0006] Figure 1 A simple schematic diagram of a digital twin of a physical system is shown. Sensors collect data about a physical system, which could be a component of an aircraft, for example. Historical data is used to build the digital twin, which evolves to simulate the physical system as more real-time data is fed into the system. As mentioned earlier, a digital twin can be used to monitor parameters of a physical system, assess the current state of a physical system, predict the future state of a physical system, and perform tests and predict failures. Summary of the invention

[0007] As described below, many problems have been discovered with current digital twin technology.

[0008] The reliability and security of a digital twin depends on the security of the data on which the digital twin relies. Ideally, the data should be immutable so that the operation of the digital twin cannot be tampered with during real-time operation and that the digital twin correctly reflects the state of the physical system. This may be important, for example, to prevent a third party from interfering with the data so that the digital twin does not correctly represent the real-time state of the physical system. This could result in the digital twin providing misleading information, leading to operational errors or failures of the physical system.

[0009] Furthermore, the stored data should be immutable so that an accurate and reliable history of the system's performance is preserved. This may be important, for example, if a physical system fails and the data needs to be examined to confirm why the physical system failed and whether there is any liability on the part of the user or manufacturer of the physical system. This is also important in processes where a certain operation may depend on the execution of a previous operation. In such cases, a third party may alter the stored data to make it appear that a specific operation has been performed when in fact it has not, thereby erroneously triggering further operations.

[0010] Another issue is the accessibility of data to many interested parties. These parties may have conflicting interests, so it is beneficial to have a secure, immutable record of data that is secure and cannot be changed, yet accessible to all parties.

[0011] There’s also the issue that traditional data storage solutions, such as the black box recorders on airplanes, can be damaged or lost in the event of an accident.

[0012] Yet another problem is that in a scenario where a further action is required once a previous action has been completed, the digital twin may indicate that further action is required, but cannot ensure that the action is actually performed. For example, the digital twin may indicate that a certain physical process has been completed, and therefore further steps are required, such as payment for the completion of the physical process. However, the digital twin cannot ensure that such payment is actually made, and therefore relies on a party to the process being trustworthy and paying, or pre-paying, which depends on the trustworthiness of the provider of the process to complete the process correctly.

[0013] It is an aim of certain embodiments of the present invention to address these problems by providing a solution as described herein.

[0014] The above problems can be solved by using blockchain technology as a storage system for data obtained from physical systems and processes (including real-time applications using digital twins). The data generated from the digital twin can be, for example, data associated with one or more parameters of the physical system, which is generated by one or more sensors that monitor one or more parameters of the physical system. Blockchain can be used to generate an immutable transaction history of data generated by the digital twin. In the event of an error, failure, incident or accident, the relevant parties can access and analyze the immutable data set. This is particularly important in safety-critical systems such as aircraft. In addition, because the blockchain provides distributed storage of data, it is not easy to damage or lose a single storage unit. In addition, data from digital twins can be used for the implementation of digital smart contracts on the blockchain network. This can ensure that the blockchain network can execute steps based on the data received by the digital twin, which indicates the real physical system state. That is, the blockchain network can be used to execute digital smart contracts with multiple parties, which involve systems or processes incorporated into digital twins.

[0015] Current blockchain technology is capable of this when a relatively small amount of data needs to be stored in a relatively infrequent period of time. However, the block size limit and the fact that blocks are only incorporated into the blockchain approximately every 10 minutes means that standard blockchain technology is not well suited as a storage system for real-time applications where the amount of data generated is very large and / or the data needs to be stored at a high frequency / fidelity (e.g., every second or millisecond). This article describes methods for overcoming these issues in order to utilize blockchain as a storage system for such real-time systems.

[0016] Embodiments of the present invention may be provided in a variety of forms. For example, a computer-readable storage medium may be provided that includes computer-executable instructions that, when executed, cause one or more processors to perform the methods described herein. An electronic device may also be provided, comprising: an interface device; one or more processors connected to the interface device; and a memory connected to the one or more processors, the memory storing computer-executable instructions that, when executed, cause one or more processors to perform the methods described herein. The computer-implemented methods described herein may also be implemented in one or more of a digital twin, a buffer, a blockchain network node, or a system comprising a combination of the above components. These components may be placed away from each other, or one or more components may be integrated.

[0017] As described in the detailed description, a computer-implemented method for a blockchain network is provided, the computer-implemented method comprising:

[0018] Receive data from the digital twin collection;

[0019] storing the data in an accessible distributed storage system;

[0020] computing a digest of a data structure representing a compressed version of the data received from the digital twin collection; and

[0021] Send the digest to be stored on the blockchain.

[0022] In the specific implementation, an embodiment is described in which the distributed storage system includes a distributed hash table and the digest of the data structure is the root of a Merkle Tree obtained from the data received from the digital twin set. However, the above method can also be implemented using a different encryption function having an associated digest of the data structure, wherein the digest of the data structure represents a compressed version of the data received from the digital twin set.

[0023] A data structure (e.g., a Merkle tree) can be used to identify in which node of an accessible distributed storage system (e.g., a distributed hash table) the data has been stored. In addition, the data structure can be stored in an accessible distributed storage system. In addition, a summary of the data structure (e.g., the root of the Merkle tree) can be sent to a buffer before forwarding for storage on the blockchain, which selects a sampling frequency of information represented by the summary of the data structure. The buffer can generate a message containing the summary information and send the message over a secure channel for storage on the blockchain. The recipient can receive the message from the buffer and access the distributed storage system to verify the message. After verification, the recipient can send a summary of the data structure for storage on the blockchain.

[0024] According to certain configurations, a second data structure may be provided having a second summary obtained from the data received from the set of digital twins (e.g., a second Merkle tree having a second root obtained from the data received from the set of digital twins). The summary of each data structure may be stored in an accessible distributed storage system. In addition, the summary of each data structure may be stored in a buffer. The buffer may then access the distributed storage system using the two summaries to confirm whether the summaries are identical, and if so, the buffer sends one of the summaries for storage on the blockchain. Otherwise, if the summaries are found to be different, the summaries may be verified to detect which digital twin is not responding.

[0025] The present invention also provides a computer-implemented method for a blockchain network, the computer-implemented method comprising: receiving a set of data from a digital twin set; storing the data in an accessible distributed storage system, the distributed storage system comprising at least one node; calculating a first summary of a first data structure, which represents a version of the data received from the digital twin set; calculating a second summary of a second data structure, which also represents a version of the data received from the digital twin set; and sending the first summary or the second summary for storage on the blockchain.

[0026] Optionally, the first data structure and the second data structure are used to identify in which node of the accessible distributed storage system the data has been stored.

[0027] Optionally, at least one of the first data structure and the second data structure is stored in the accessible distributed storage system.

[0028] Optionally, the first digest and the second digest are sent to a buffer before being forwarded for storage on the blockchain, the buffer selecting a sampling frequency of information represented by the first digest and the second digest, respectively.

[0029] Optionally, the buffer generates a message including information of the first digest and the second digest, and sends the message through a secure channel to be stored on the blockchain.

[0030] Optionally, the recipient receives the message from the buffer and accesses the distributed storage system to verify the message.

[0031] Optionally, after verification, the recipient sends the first digest or the second digest to be stored on the blockchain.

[0032] Optionally, the buffer uses the first digest and the second digest to access the distributed storage system to confirm whether the digests are the same, and if they are the same, the buffer sends one of the digests to be stored on the blockchain.

[0033] Optionally, if the first digest is found to be different from the second digest, the digests are verified to detect which digital twin is unresponsive.

[0034] Optionally, the distributed storage system includes a distributed hash table, and each of the first digest and the second digest is a root of a Merkle tree obtained from data received from the digital twin set.

[0035] Also provided is a computer-readable storage medium comprising computer-executable instructions which, when executed, cause one or more processors to perform the methods described herein.

[0036] An electronic device is also provided, comprising:

[0037] Interface devices;

[0038] one or more processors connected to the interface device;

[0039] A memory connected to one or more processors having computer executable instructions stored thereon, which when executed cause the one or more processors to perform the methods described herein.

[0040] In addition, a system for performing the method described herein is provided, the system comprising:

[0041] Digital twin collection;

[0042] An accessible distributed storage system for storing data from the collection of digital twins;

[0043] a processor for computing a digest of a data structure representing a compressed version of data received from the digital twin collection; and

[0044] A sender that sends the digest to be stored on the blockchain.

[0045] The present invention differs from prior art involving digital twins in that it is specifically directed to a blockchain approach for managing data flows from a collection of digital twins rather than a single digital twin. The concepts of the present invention involve receiving data from a collection of digital twins, storing the data in an accessible distributed storage system, computing a digest of a data structure that represents a compressed version of the data received from the collection of digital twins, and sending the digest for storage on a blockchain.

[0046] In the described embodiment, the distributed storage system includes a distributed hash table, and the summary of the data structure is in the path of a Merkle tree, which is obtained from the data received from the digital twin collection. That is, a common Merkle tree structure is used for the collection of digital twins, rather than a separate Merkle tree for each digital twin. The present invention provides a solution for processing large amounts of data from digital twins while also being able to securely verify the data. In the current case, the solution is able to manage large amounts of data from a collection of digital twins while compressing the amount of data that needs to be stored on the blockchain and still being able to verify the data. This is in contrast to prior art such as that briefly discussed below.

[0047] US2017 / 0284974 discloses a digital twin system. However, there does not appear to be any disclosure of storing data from such a digital twin system on a blockchain, and certainly not the specific methods described in this specification.

[0048] CN105812126 appears to disclose the acquisition of human physiological data and the storage of this data on a blockchain. However, the method described in this specification for processing data from a digital twin collection does not appear to be disclosed.

[0049] Carlo Gutierrez's paper titled "Boeing Improves Operations with Blockchain and the Internet of Things" appears to disclose the use of digital twins and storing data on a blockchain. However, the document only provides a relatively high-level overview and does not appear to have any details on how this is implemented in practice. Likewise, the methods described in this specification for processing data from a collection of digital twins are not disclosed.

[0050] Burkhard Blechschmidt’s article titled “Digital Twin on Blockchain, Enabling the Circular Economy” is another high-level document that touches on the application of digital twins and blockchain. Again, there are no details on how this can be achieved in practice, and certainly no disclosure of the specific methods described in this specification for processing data from a collection of digital twins.

[0051] The article by Trouton et al., entitled "3D Opportunity for Blockchain", also appears to disclose the use of blockchain technology in conjunction with digital twins in order to manage system data. Again, there does not appear to be any details about how the system is used to process and save data. In particular, the methods described in this specification for processing data streams from a collection of digital twins do not appear to be disclosed.

[0052] Stocker's article, titled "Implementing First Industry 4.0 Use Cases with DAG Tangle-Machine Tagging for Digital Twins," also appears to disclose the use of blockchain technology in conjunction with digital twins in order to manage data. Again, there does not appear to be any details on how the system is used to process and save data. In particular, the methods described in this specification for processing data from a collection of digital twins do not appear to be disclosed. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Various aspects of the invention will become clear and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0054] Figure 1 A simple schematic diagram of a digital twin of a physical system is shown;

[0055] Figure 2 An example of a Merkle tree is shown;

[0056] Figure 3 Two different Merkle trees are shown;

[0057] Figure 4 (a) to 4(c) illustrate a system comprising four digital twins, a Merkle tree having a root obtained from data from the four digital twins, and a blockchain on which the root is stored;

[0058] Figure 5 (a) and 5(b) show the use of blockchain as a proof of existence for data generated by a digital twin, a system similar to Figure 4 The system shown in (a) to 4(c), but modified so that data from the digital twin is stored in a distributed hash table and wherein a second, replica Merkle tree is provided that provides degeneracy in the event of a failure in the connection between the digital twin and the blockchain network;

[0059] Figure 6 The parties involved in a Merkle tree based protocol for historical delta hashing are shown;

[0060] Figure 7 shows the stages involved in a Merkle tree based protocol for historical delta hashing;

[0061] Figure 8 The steps involved in a Merkle tree-based protocol for historical delta hashing are shown;

[0062] Fig. 9 As shown previously in Figure 5 The mirrored or replica Merkle trees shown in (a) and 5(b) provide degeneracy in the event of a failure in the connection between the digital twin and the blockchain network;

[0063] Fig.10 shows the steps of mirroring roots and verification in order to check the reliability of the transmission and maintain consistent data; and

[0064] Fig.11 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION

[0065] In this document, the term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers. These include, but are not limited to, consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. It should be noted that the present invention is not limited to use with a specific blockchain, and other blockchain implementations and protocols also fall within the scope of the present invention.

[0066] A blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed computer-based system consisting of blocks, which consist of transactions and other information. In the case of digital assets, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so that the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its inception. Transactions contain small programs, called scripts, embedded in the inputs and outputs of the transaction that specify how and by whom the output of the transaction can be accessed. On some platforms, these scripts are written in a stack-based scripting language.

[0067] In order for a transaction to be written to the blockchain, it must be "validated". Some network nodes perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. For example, a software client installed on the node performs validation work on a transaction that references an unspent transaction output (UTXO). Validation can be performed by executing its locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to true (TRUE), and if certain specific conditions are met, the transaction is valid and can be written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, the transaction must: i) be validated by the node that receives the transaction - if the transaction is validated, the node relays the transaction to other nodes in the network; ii) be added to a new block that is constructed; iii) be mined, that is, added to the public ledger of past transactions. A transaction is considered confirmed when a sufficient number of blocks have been added to the blockchain to make the transaction effectively irreversible.

[0068] Digital entrepreneurs have begun exploring the use of cryptographically secure systems and the use of data stored on blockchains to implement new systems. It would be extremely advantageous if blockchains could be used to automate tasks and processes. Such solutions would be able to leverage the advantages of blockchains (e.g., permanent tamper-proof records of events, distributed processing, etc.) while being more versatile in the application of said solutions.

[0069] One area of ​​research is the use of blockchain to implement “smart contracts.” These smart contracts are computer programs designed to automatically execute the terms of a machine-readable contract or agreement. Unlike traditional contracts written in a natural language, a smart contract is a machine-executable program that includes rules that process inputs to produce results, and the smart contract can perform actions based on those results.

[0070] This specification describes the use of blockchain in combination with digital twins, and optionally in combination with smart contracts. As previously mentioned, digital twins can simplify supply management processes and can be an important diagnostic tool for safety-critical systems (such as the aircraft and aerospace industry or the general transportation industry). There are many potential applications for the combination of digital twins and blockchain technology. For example, a blockchain network can be used to securely store information generated by a digital twin, or to execute contracts with multiple parties involved in a system or process that includes a digital twin. A digital twin can effectively act as an interface between a physical system and a blockchain, so that data about a system or process can be obtained through a digital twin and stored in a blockchain, and the blockchain can trigger certain actions based on the received data according to one or more smart contracts stored on the blockchain.

[0071] The amount of real-time data generated by a digital twin can vary depending on the complexity of the system being mirrored. For example, a digital twin can be built that reflects the temperature of an office. In this case, given that the temperature of a room does not usually change suddenly, it makes sense to transmit one temperature value every minute (or every 5 minutes) in order to reduce the amount of data transmitted over the network. With one temperature value per minute, the digital twin will record and transmit (in real time) 60 temperature values ​​per hour.

[0072] Such an amount of data is certainly reasonable to store on a blockchain and does not create any major problems. However, if the system being mirrored is, for example, an aircraft engine in flight, or a train cylinder on a train journey, the situation becomes more complicated. In these examples, even transmitting values ​​every second may not be enough, and a higher fidelity may need to be guaranteed, for example, sampling once every millisecond (very likely in the case of an aircraft). Furthermore, the number of variables recorded can vary, and in complex systems, a large number of variables may need to be recorded with high fidelity.

[0073] The need to consider the amount and frequency of data transmitted by digital twins is an important premise that is constrained when considering blockchain as a possible backbone infrastructure for storing information related to a specific object or process. The amount of data generated by digital twins is very large, so when trying to interface the structure of digital twins with blockchain, it may be very difficult to manage such a large amount of data. In this specification, an improved protocol based on Merkle trees is described, including the following features:

[0074] 1. We propose a solution that is able to store a large amount of information generated by a collection of digital twins in a distributed hash table and store the corresponding value of the root of the Merkle tree on a public blockchain.

[0075] 2. We propose to use the Merkle tree structure as a proof of existence of data generated by a set of digital twins and as a method to identify in which node of the distributed hash table the actual data has been stored.

[0076] 3. We propose the concept of mirrored Merkle trees, which introduces an additional layer of security and reliability for data transmitted from the buffer to the receiver.

[0077] Merkle Tree

[0078] A hash function is a one-way function that takes an input and generates an output of a fixed length. A well-designed hash function is based on the property that two inputs will not produce the same output (a collision) with a high probability. Therefore, a hash can be considered a unique identifier for a given content.

[0079] For example, a file F can be stored in a peer-to-peer network by dividing it into small chunks and distributing it in the network. The peers participating in this process need to provide sufficient bandwidth and disk space. In addition, peers are anonymous and untrusted, so it is risky to accept F from a peer without first verifying that the content is legitimate.

[0080] Merkle trees have unique properties that allow us to efficiently verify data across a network of peers. Merkle trees are binary trees whose nodes store hashes instead of fragments of data, such as Figure 2 As shown in the figure, the leaf node stores the hash of part of the data, while the parent node stores the hash of the left and right child nodes combined.

[0081] The basic property is that the only element we need to check to compare two Merkle trees is the root, e.g. Figure 3 The two trees are different because the two roots R and S are different. Therefore, the two trees represent two different sets of data, such as {a, b, c, d} on the left and {a, b, c, e} on the right.

[0082] History incremental hashing

[0083] The information stored on the blockchain is not the data generated by the digital twin, but a signed hash of a given amount of data D generated within a given time frame T.

[0084] History delta hashing is based on the following steps:

[0085] 1. The digital twin starts recording data at a given frequency f;

[0086] 2. Data is recorded in private nodes;

[0087] 3. At time T0, the node generates a first hash (H0), which hashes the data recorded by the digital twin at time T0: H0 = H(D), and records the hash locally and in the blockchain;

[0088] 4. At time T0+x, each new hash will be linked to the previous hash (the second hash will be linked to H0, and so on), producing a hash chain that will be recorded on the blockchain.

[0089] The blockchain will contain a sequence of hashes that can be used to reconstruct the entire history of data generated by the digital twin, with the authenticity of the recorded information verified by private nodes.

[0090] Additionally, if the digital twin is sending critical information, for example, it is mirroring the mechanical parts of a device involved in safety-critical operations, the information should be sent over the network through a secure channel.

[0091] Blockchain as Proof of Existence

[0092] The properties of Merkle trees can be exploited to make the process of storing and validating data collected from digital twins connected to complex systems (e.g., aircraft) more efficient. Figure 4 As shown in (a) to 4(c), instead of storing the same number of hashes as the digital twin, only the root of the Merkle tree representing the system under observation (SUO) can be stored.

[0093] Figure 4 (a) shows an observed system monitored by four digital twins {a, b, c, d} that simulate specific parts of an aircraft. The digital twins produce data at a given rate. The data is stored in a private node (or multiple nodes) and its hash is used to calculate the root ( Figure 4 (b)). The only information stored in the blockchain is the root of the Merkle tree ( Figure 4 (c)). This means that the amount of information generated by the digital twin array will not have an impact on the storage requirements of the blockchain. Note also that the frequency used to generate each timestamp (the root of the Merkle tree) depends on the application.

[0094] In this way, we can use Merkle trees and digital twins to establish on-chain proof of existence for the generated data. Figure 5 (a) and 5(b) illustrate the use of blockchain as a proof of existence for the data generated by the digital twin. Figure 5 As shown in (a), stored in the blockchain ( Figure 5 (b)) will be used to prove the existence at a certain time of a dataset generated by the digital twin array and stored in a distributed hash table (DHTs). The recorded hash can also be used to identify which nodes of the distributed hash table contain specific information.

[0095] In the next section, we present an improved protocol for using (single or combined) Merkle trees to store data generated by digital twins.

[0096] A Merkle-tree based protocol for historical incremental hashing

[0097] We propose an optimized solution based on Merkle trees and historical incremental hashing to use blockchain as an authentication system to store information produced by digital twin arrays.

[0098] Figure 6 shows a solution for the parties involved in a solution. To achieve a secure channel, we need to Figure 6The buffer in our case (A) creates a shared key K between the sender and the receiver, provided that only the sender and the receiver know the key K. The role of the buffer is to act as an interface that connects the Merkle tree representing the set of digital twins to the secure channel. In this process, the data stream S (consisting of the raw data generated by the digital twins and the hash of the Merkle tree) is converted into a discrete message sequence {m1,m2,…,m n}. The buffer will be responsible for collecting, storing and sending all generated data. After discretizing S and generating n required messages, it will be used for each message m i Generate key K i Each time a secure channel is established, for example, each time a message m is sent i When sending, a key agreement protocol is used between the buffer and the receiver to set a unique key (session key). The buffer will decide how many discrete messages to send, for example, based on the network conditions at the time of sending.

[0099] For each message m sent through the channel i , the buffer will calculate and store the hash H(m i ). Then, it will form the message m h =H(m1),H(m2),…,H(m n ) and append m H =H(m h ) to complete the process. The receiver receives the sequence of messages and can use m h and m H to verify.

[0100] protocol

[0101] The solution described in the previous section works if the set of digital twins that mirror the SUO is limited or involves processes / systems that do not generate a lot of data. When the SUO features a large number of digital twins, or the set of digital twins is mirroring a complex system described by many variables that require a lot of data, the sending of messages (containing the raw data) and the root of the associated Merkle tree may not be efficient in a given time. In this section, we propose a protocol where (i) the raw data is stored directly on the DHT, and (ii) the root of the associated Merkle tree is computed, sent, and stored on the blockchain.

[0102] The proposed protocol is based on the following steps, such as Figure 7 As shown:

[0103] 1. Data provided (continuously) by a collection of digital twins of mirror systems (a) is stored in the DHT (b).

[0104] 2. The Merkle tree (a) is used to link all digital twins of the mirror system together. Only the root of the tree will be sent and stored on the blockchain.

[0105] 3. During step (b), the buffer is responsible for selecting the sampling frequency of the information represented by the root of the Merkle tree. The frequency will depend on the system being controlled and the required resolution.

[0106] 4. The message generated by the buffer in step (b) is sent through the secure channel (c) and then received by the recipient in step (d).

[0107] 5. The recipient has access to the DHT, which stores the data generated by the digital twin collection. The DHT can be used to verify the integrity of the information. The DHT used is a private platform. Therefore, unauthorized users cannot access the information stored in the DHT.

[0108] 6. As a final step, a hash of the root of the Merkle tree is stored on the blockchain.

[0109] The receiver (b) acts as an interface between the SUO and the blockchain. Because the number of roots of the received Merkle tree can be very high and considering network latency, it is necessary to temporarily store the received information until it is published on the blockchain. In addition, the receiver is also able to verify that the given root is correct and represented by the given Merkle tree:

[0110] By checking the message m h and m H .and

[0111] By accessing the relevant DHT.

[0112] Figure 8 The steps involved in the protocol for Merkle tree-based, history delta-hashing are shown.

[0113] While the above approach is able to manage large amounts of data from a digital twin collection, a potential problem could be data inconsistency due to connection failures between the digital twin and the network. In the next section, we illustrate an improved solution to improve the reliability and security of the protocol.

[0114] Mirrored Merkle Tree

[0115] To improve the reliability of step B in the sending protocol, i.e., evaluating whether the root of the Merkle tree is correctly stored in the buffer, we propose Fig. 9 The replica structure shown.

[0116] The two hashes R and R' of the root of the Merkle tree are stored in the DHT and the buffer and can be used to verify whether the digital twin array provides consistent data. A cache system is added to the buffer in order to check the consistency of the root of the Merkle tree.

[0117] The buffer contains three root sets: cached set, acknowledged set, and unacknowledged set. The following steps describe the additional part of the protocol:

[0118] A cache set consists of a pair of roots R and R' generated by a mirror tree.

[0119] · The buffer can access the DHT using roots R and R'.

[0120] If the DHT is successfully accessed using R and R', then both roots are the same, i.e. root R is transferred to the confirmed set.

[0121] If the access to the DHT using R and R' is inconsistent, the root R is moved to the unconfirmed set.

[0122] The roots in the confirmed set are sent over the network, while the roots in the unconfirmed set are verified in order to detect which digital twin(s) are not responding correctly. Fig.10 The steps of mirroring root and verification are shown.

[0123] Computing Environment

[0124] Fig.11 2600 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. An illustrative simplified block diagram of a computing device 2600 that may be used to practice at least one embodiment of the present invention is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems shown and described above. For example, the computing device 2600 may be used as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Fig.11 As shown, computing device 2600 may include one or more processors and a memory controller (collectively referred to as 2602), wherein the one or more processors have one or more levels of cache memory, and the memory controller may communicate with a storage subsystem 2606 including a main memory 2608 and a persistent memory 2610. As shown, main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory 2602 may be used to store information, such as details associated with transactions and blocks described in the present invention. Processor 2602 may be used to provide the steps or functions of any embodiment described in the present invention.

[0125] The processor 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0126] The bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is illustrated as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.

[0127] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface to receive data from and transmit data to other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network, enabling the data technician to transmit data to and receive data from the device at a remote location (e.g., a data center).

[0128] The user interface input devices 2612 may include one or more user input devices such as a keyboard; a pointing device such as an integrated mouse, trackball, touchpad, or drawing tablet; a scanner; a barcode scanner; a touch screen integrated into a display; an audio input device such as a voice recognition system, a microphone, etc.; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0129] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device. The display subsystem may be a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a flat panel device such as a projector, or other display device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used to display a user interface to facilitate user interaction with the application executing the process and its variables when appropriate.

[0130] The storage subsystem 2606 can provide a computer-readable storage medium for storing basic programming and data structures, wherein the basic programming and data structures can provide the functions of at least one embodiment of the present invention. When executed by one or more processors, the application program (program, code module, instruction) can provide the functions of one or more embodiments of the present invention and can be stored in the storage subsystem 2606. These application modules or instructions can be executed by one or more processors 2602. The storage subsystem 2606 can additionally provide a repository for storing data used by the present invention. For example, the main memory 2608 and the cache memory 2602 can provide volatile storage for programs and data. The permanent storage device 2610 can provide permanent (non-volatile) storage for programs and data, and can include flash memory, one or more solid-state drives, one or more disk drives, one or more optical disk drives with associated removable media (such as CD-ROM or DVD or Blue-Ray) and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in the present invention, and data associated with transactions and blocks as described in the present invention.

[0131] The computing device 2600 can be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. In addition, the computing device 2600 can include another device that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, lightning connector, etc.). The device that can be connected to the computing device 2600 includes multiple ports for accepting fiber optic connectors. Thus, the device can convert optical signals into electrical signals that can be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, Fig.11 The computing device 2600 described in the foregoing is merely a specific example to illustrate a preferred embodiment of the device. Fig.11 Many other configurations are possible having more or fewer components than the system depicted.

[0132] Summarize

[0133] In this note, we propose a solution based on the use of Merkle trees to store data generated by digital twin arrays.

[0134] The main problem with using a public blockchain to store the information generated by a digital twin is that the amount of data generated by a digital twin is very large, and it is impossible to store such a large dataset into a public distributed ledger given the technical limitations imposed by its structure.

[0135] In this manual:

[0136] 1. We have described a solution that is able to store a large amount of information generated by a collection of digital twins in a distributed hash table and store the corresponding value of the root of the Merkle tree on a public blockchain.

[0137] 2. We have described the use of a Merkle tree structure as a proof of existence for data generated by a collection of digital twins and as a method of identifying in which node of a distributed hash table the actual data has been stored.

[0138] 3. We have described the concept of mirrored Merkle trees, which introduces an additional layer of security and reliability for data transmitted from the buffer to the receiver.

[0139] It should be noted that the above embodiments illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of other elements and steps as a whole, even though these elements and steps are not listed in any claim or specification. In this specification, "comprises" means "includes or consists of...", and "comprising" means "including or consists of...". The singular reference of an element does not mean to exclude the plural reference of these elements, and vice versa. The present invention can be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a device claim that lists several means, several of these means may be embodied by the same component of hardware. The indisputable fact is that certain methods are listed in mutually different dependent claims, which does not mean that the combination of these methods cannot achieve beneficial effects.

Claims

1. A computer-implemented method for a blockchain network, the computer-implemented method comprising: A collection receiving data from a digital twin collection; storing the data in an accessible distributed storage system, the distributed storage system comprising at least one node; computing a first digest of a first data structure, the first digest of the first data structure representing a version of the data received from the set of digital twins; computing a second digest of a second data structure, the second digest of the second data structure also representing a version of the data received from the set of digital twins; as well as The first digest or the second digest is sent for storage on a blockchain.

2. The computer-implemented method of claim 1, in, The first data structure and the second data structure are used to identify in which node of the accessible distributed storage system the data has been stored.

3. A computer-implemented method according to claim 1 or 2, in, At least one of the first data structure and the second data structure is stored in the accessible distributed storage system.

4. A computer-implemented method according to any preceding claim, in, The first digest and the second digest are sent to a buffer before being forwarded for storage on the blockchain, the buffer selecting a sampling frequency of information represented by the first digest and the second digest, respectively.

5. The computer-implemented method of claim 4, in, The buffer generates a message including information of the first digest and the second digest, and sends the message through a secure channel to be stored on the blockchain.

6. The computer-implemented method of claim 5, in, The recipient receives the message from the buffer and accesses the distributed storage system to verify the message.

7. The computer-implemented method of claim 6, in, After verification, the recipient sends the first digest or the second digest to be stored on the blockchain.

8. A computer-implemented method according to any one of claims 4 to 7, in, The buffer uses the first digest and the second digest to access the distributed storage system to confirm whether the digests are the same, and if they are the same, the buffer sends one of the digests to be stored on the blockchain.

9. The computer-implemented method of claim 8, in, If the first digest is found to be different from the second digest, the digests are verified to detect which digital twin is not responding.

10. A computer-implemented method according to any preceding claim, in, The distributed storage system includes a distributed hash table, and each of the first digest and the second digest is a root of a Merkle tree obtained from data received from the digital twin set.

11. A computer-readable storage medium comprising computer-executable instructions, which when executed cause one or more processors to perform the method of any one of claims 1 to 10.

12. An electronic device comprising: Interface devices; one or more processors connected to the interface device; A memory connected to the one or more processors, wherein the memory stores computer executable instructions, and when the computer executable instructions are executed, the one or more processors perform the method according to any one of claims 1 to 10.

13. A system for performing the method according to any one of claims 1 to 10, the system comprising: Digital twin collection; an accessible distributed storage system for storing data from the collection of digital twins; a processor for computing a digest of a data structure; and A sender that sends the digest to be stored on the blockchain.

Images