Method for data interaction using a blockchain-based decentralized Internet collaboration system

Abstract

The present application provides a method for data interaction using a decentralized Internet collaboration system based on blockchain. Among them, the system includes: a device layer composed of physical entities, where the physical entities collect source data through sensors and upload it to digital entities; a network layer composed of edge gateways and base stations, which receives source data from physical entities; a storage layer that stores the source data of physical entities through cloud services and uploads the metadata of the production source data to the edge blockchain network for unique mapping indexing; an oracle network layer composed of data oracles, cross-domain oracles, and computing oracles for computing resource sharing; and a control layer composed of a digital twin platform, which provides interfaces for adding, deleting, modifying, and querying for each production node based on the data flowing through the device layer, network layer, storage layer, and oracle network layer. Through the above solution, the problem that there is no efficient data interaction between existing digital entities and physical entities is solved.

Description

Technical Field

[0001] This application belongs to the field of Internet technologies, and particularly relates to a method for data interaction using a decentralized Internet collaboration system based on blockchain. Background Art

[0002] With the continuous development of technologies such as IoT, 5G / 6G, and digital twins, the operation mode of the industrial world is changing. Thanks to connected devices, ultra-low latency, and fast feedback between the physical world and the digital world, industrial machines have evolved from originally requiring human intervention, to customized production according to human needs, and then to providing two-way feedback, and intelligent industrial Internet (IIoT) machines have developed rapidly.

[0003] However, while advanced industrial machines bring rapid data exchange, they also pose relatively severe challenges to centralized industrial architectures. First, when data is transmitted from industrial machines to the cloud service center, it consumes a large amount of bandwidth, posing a challenge to the performance of the cloud service center. Second, the multi-source data standards among multiple participating entities bring great challenges to industrial data processing. It is difficult to uniformly process data such as database diagrams, data interfaces, and data files, which results in digital entities having difficulty making rapid feedback on the data transmitted by physical entities. Finally, there are data trust issues among industrial participating entities, and industrial entities are reluctant to share data known as digital oil with other participating entities in the centralized industrial architecture.

[0004] Blockchain is a decentralized approach that can connect multiple participating entities without trust through a consensus mechanism and reduce the load on a single machine through a decentralized architecture. For example, the synchronization of data models among multiple industrial entities can be achieved through blockchain technology, and the synchronization between the physical system and the digital system can be achieved through digital twin technology. The digital twin edge network proposed based on federated learning, edge computing, and blockchain can build a trusted digital twin network based on blockchain and enhance the security of learning based on federated learning empowered by blockchain.

[0005] However, blockchain is merely a collection of programs based on simple rules and method calls, and it is difficult to process complex industrial Internet data and logic. Building an industrial digital twin network needs to face huge industrial data and complex data sources, and blockchain is difficult to directly call and store the above data. Due to the deterministic nature of blockchain, it is unable to actively obtain external industrial data, making it difficult for the IIoT ecological data exchange of multiple blockchains and the data exchange between digital entities and physical entities in the digital twin network difficult.

[0006] Regarding the problems existing in data collaboration and computing collaboration in the existing industrial digital twin network, no effective solutions have been proposed yet. Summary of the Invention

[0007] The purpose of this application is to provide a method for data interaction using a blockchain-based decentralized Internet collaboration system, which can achieve efficient data exchange between digital entities and physical entities.

[0008] On the one hand, a blockchain-based decentralized Internet collaboration system is provided, including:

[0009] The device layer, which consists of physical entities. Among them, the physical entities collect source data through sensors and upload it to digital entities;

[0010] The network layer, which consists of edge gateways and base stations, receives source data from the physical entities, preprocesses the source data, and uploads it to digital entities;

[0011] The storage layer, which is jointly composed of cloud services and an edge blockchain network. The source data of the physical entities is stored through cloud services, and the metadata of the production source data is uploaded to the edge blockchain network for unique mapping indexing;

[0012] The oracle network layer, which consists of a data oracle for in-domain data sharing, a cross-domain oracle for cross-domain data sharing, and a computing oracle for computing resource sharing;

[0013] The control layer, which consists of a digital twin platform, and is used to provide interfaces for adding, deleting, modifying, and querying for each production node based on the data flowing through the device layer, network layer, storage layer, and oracle network layer.

[0014] In one embodiment, the edge blockchain network includes: the first layer, which consists of a federated chain formed by each participating entity and regulatory nodes, and is used to manage global data; the second layer, which consists of local chains formed by each participating digital entity respectively, and is used to manage local data.

[0015] In one embodiment, the data oracle includes: an application contract for receiving industrial data sharing requests of digital twin entities, a unified industrial data oracle interface, and a peer-to-peer network for obtaining and calling back industrial data off-chain; the cross-domain oracle includes: a source blockchain containing an application contract for receiving cross-domain sharing requests of entities, a destination blockchain containing a proxy contract for receiving cross-domain sharing requests, and a peer-to-peer network for forwarding and calling back cross-domain sharing requests; the computing oracle includes: an application contract for receiving industrial computing sharing requests, a computing oracle interface and a proxy contract, and a computing oracle network for calling back training results.

[0016] On the other hand, a method for data interaction using the above blockchain-based decentralized Internet collaboration system is provided, including:

[0017] On-chain and off-chain collaboration of industrial data through a data oracle;

[0018] Inter-chain data collaboration through a cross-chain oracle;

[0019] Computing collaboration through a computing oracle.

[0020] In one implementation, on-chain and off-chain collaboration of industrial data through a data oracle includes:

[0021] A physical entity or a digital entity triggers an industrial data sharing event by calling the request function of an application contract and then calling the function of a proxy contract;

[0022] The data oracle listens for the industrial data sharing event;

[0023] The data oracle addresses the address specified by the industrial data sharing event to obtain industrial data and aggregates the data off-chain;

[0024] The aggregated result is returned to the off-chain data oracle network to listen for the event, addresses the address specified by the industrial data sharing request to obtain industrial data, aggregates it off-chain, and returns the aggregated result on-chain.

[0025] In one implementation, on-chain and off-chain collaboration of industrial data through a data oracle includes:

[0026] A target entity sends an off-chain industrial data request to a production contract and specifies a data interface or data source;

[0027] The production contract calls the interface provided by the proxy contract to forward the industrial data request, where the industrial data request includes at least one of the following: data source, public key, signature, certificate, callback address, timestamp, deadline;

[0028] After receiving the industrial data request, the proxy contract verifies the identity of the target entity and adds the industrial data request to the off-chain data request queue to trigger an off-chain event;

[0029] After the data oracle listens for the event off-chain, it obtains data from the specified data source, and after off-chain aggregation and consensus, it callbacks the data to the proxy contract, where the callback data includes at least one of the following: data, public key group callback address, timestamp, aggregated signature;

[0030] After receiving the callback request, the proxy contract verifies the validity of the aggregated signature and determines whether the timestamp is less than the deadline;

[0031] When it is determined that the aggregated signature is valid and the timestamp is less than the deadline, the callback request is called back to the production contract, and the industrial data request is deleted from the off-chain data request queue.

[0032] In one implementation, cross-chain data collaboration is achieved through a cross-domain oracle, including:

[0033] The target entity sends a cross-domain request to the production contract of the source local chain with cross-domain data requirements and specifies the target local chain that will accept the cross-domain request;

[0034] The production contract calls the cross-domain interface provided by the proxy contract on the source local chain with cross-domain data requirements to forward the cross-domain request, where the cross-domain request carries at least one of the following: the specified target local chain that will accept the cross-domain request, the address of the production contract in the specified target local chain that will accept the cross-domain request, the data status to be modified, public key, signature, certificate, callback address, timestamp, deadline;

[0035] After receiving the cross-domain request, the proxy contract verifies the identity of the target entity based on the certificate, adds the cross-domain request to the off-chain data request queue to be processed, and triggers a cross-domain event;

[0036] The proxy for double-chain interaction forwards the cross-domain request to the federated chain and records it on the federated chain;

[0037] The proxy for double-chain interaction writes the Merkle root of the record transaction into the proxy contract of the source local chain with cross-domain data requirements;

[0038] After the cross-domain oracle monitors the cross-domain event, it verifies whether the Merkle root exists in the federated chain after monitoring the cross-domain event;

[0039] If it exists, after network consensus, the cross-domain request is written into the proxy contract of the target local chain that will accept the cross-domain request;

[0040] The proxy contract of the target local chain that is specified to accept the cross-domain request verifies the validity of the signature and determines whether the timestamp is less than the deadline;

[0041] When it is determined that the signature is valid and the timestamp is less than the deadline, the proxy contract calls the production contract specified by the callback address to modify the data and triggers a callback event;

[0042] In response to the callback event, after performing a consensus operation, the proxy contract of the source local chain with cross-domain data requirements is called to execute a callback operation;

[0043] The proxy contract of the source local chain with cross - domain data requirements verifies the signature and result. After successful verification, it calls the production contract to return the result and removes the cross - domain request from the off - chain data request queue to be processed.

[0044] In one embodiment, computing collaboration is achieved through a computing oracle, including:

[0045] A physical entity or digital entity writes an industrial computing task into an application contract;

[0046] The application contract forwards the industrial computing task to a proxy contract to trigger an industrial computing task sharing event;

[0047] The computing oracle listens for the industrial computing task sharing event and controls multiple nodes in the network to perform collaborative computing on the industrial computing task to obtain a computing result;

[0048] The computing result is called back to the chain.

[0049] In one embodiment, when the computing oracle listens for the industrial computing task sharing event and controls multiple nodes in the network to perform collaborative computing on the industrial computing task to obtain a computing result, it includes:

[0050] After each client node receives the computing task from the master node, it obtains the data it needs to process according to the storage location of the data set, trains to obtain the optimal model parameters according to the preset training rules and parameters, and sends the obtained optimal model parameters to the master node for aggregation;

[0051] After the master node receives the optimal model parameters obtained by training sent by all client nodes, it selects a predetermined proportion of the test set to test each optimal model parameter to obtain a model parameter ranking result;

[0052] Select the model parameters ranked in the top preset proportion from the model parameter ranking result and distribute them to the client nodes in the oracle network layer:

[0053] After the client nodes in the oracle network layer receive the model parameters ranked in the top preset proportion, they verify whether the digest of the model parameters ranked in the top preset proportion is the same as the digest of the model parameters stored on the chain. If they are the same, the global model is updated.

[0054] On the other hand, a computer - readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the above - mentioned method are implemented.

[0055] The method for data interaction using a decentralized Internet collaboration system based on blockchain provided by this application can connect off-chain and on-chain data by introducing data oracles and cross-domain oracles, and can achieve the consistency of off-chain data through a unified collaboration mechanism. By introducing computing oracles, computing tasks can be transferred to off-chain execution, and the authenticity of off-chain computing tasks can be guaranteed. That is, by introducing oracles in the collaboration system, the problem that there is no efficient data interaction between existing digital entities and physical entities can be effectively solved, achieving the technical effect of efficient and accurate data interaction, and complex data calculations can be completed. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments recorded in this application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on these drawings.

[0057] Figure 1 is a schematic diagram of the architecture of the decentralized Internet collaboration system based on blockchain provided by this application;

[0058] Figure 2 is a flowchart of the method for data interaction of the decentralized Internet collaboration system based on blockchain provided by this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0059] In order to enable those skilled in the art to better understand the technical solutions in this application, the following will clearly and completely describe the technical solutions in the embodiments of this application in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this application.

[0060] Considering that blockchain is merely a collection of programs based on simple rules and method calls, it is difficult to handle complex industrial Internet of Things (IIoT) data and logic. Building an industrial digital twin network requires dealing with a vast amount of industrial data and complex data sources, and blockchain cannot directly call and store such data. Due to the deterministic nature of blockchain, it cannot actively obtain external industrial data, making it difficult for multi-blockchain IIoT ecological data exchange and the data exchange between digital and physical entities in the digital twin network. Therefore, a medium for data collaboration needs to be set up in the industrial architecture. Further, due to the demand for intelligence in digital twins, blockchain based on simple rules is difficult to execute a large number of computing tasks on the chain, so a medium for computing collaboration needs to be set up.

[0061] Therefore, in this example, for the blockchain-based digital twin architecture for IIoT, a decentralized industrial Internet collaboration mechanism based on blockchain is proposed, and an oracle is introduced as the data medium and computing medium. The oracle feeds back the on-chain industrial data requirements through an off-chain decentralized data collaboration network, executes on-chain industrial computing tasks through an off-chain decentralized computing collaboration network, and proposes a general off-chain collaboration mechanism to uniformly process data collaboration and computing collaboration logically to ensure the consistency of IIoT data in off-chain collaboration.

[0062] To clearly illustrate the solution, the following are explanations of several terms involved:

[0063] 1) Data collaboration:

[0064] Blockchain is a peer-to-peer distributed data sharing paradigm. Smart contracts, the product of the blockchain 2.0 era, have become an important means to meet the complex logic of the industrial Internet in the 3.0 era. However, smart contracts are just a collection of subroutines based on simple rules and recursive calls. Facing the application scenarios of the industrial Internet with large amounts of data and a large number of devices, it poses challenges to the storage capacity, consensus efficiency, and collaboration ability of blockchain. Regarding the challenge of industrial blockchain storage expansion, considering that based on the on-chain and off-chain collaboration mechanism, the storage capacity of blockchain can be expanded by using the off-chain decentralized storage space to exchange for storage. Managing edge device data on the blockchain management cloud service, the role of blockchain is the authorization and authentication center of the cloud service, and blockchain only stores authorization information. Regarding the challenges of consensus efficiency and collaboration ability, there are currently two means: on-chain and off-chain. On-chain means are through modifying block size, block organization method, sharding, etc.; off-chain means are through side chains, rollups, multi-chain layering, etc. Since there are many participants in the industrial Internet and there are system association relationships among the participants, in this example, it is mainly considered whether the multi-chain layered network architecture can address the challenges of consensus efficiency and data collaboration.

[0065] An oracle is a tool that connects the blockchain with external real-world data. It enables data collaboration by bridging smart contracts with the real world and is considered an important application scenario for interoperability.

[0066] 2) Computing collaboration:

[0067] Edge computing is a computing paradigm that decentralizes computing and storage capabilities to the edge side to reduce the load on the core network. The distributed nature of edge computing makes it a natural fit for the blockchain. The blockchain provides data collaboration for edge computing, and edge computing provides computing collaboration for the blockchain.

[0068] 3) Digital twin:

[0069] With the development of new-generation information technology and digital technology, more and more industrial data is being collected, and the future industrial Internet is considered to have a decentralized architecture. More and more industrial devices can achieve two-way control of instructions and data, which has drawn increasing attention to the concept of digital twin and led to its rapid development. Digital twin is one of the fundamental technologies that make up the metaverse. Its concept is simple: it connects physical entities and digital entities in an accurate and real-time manner. Based on the characteristics of bidirectional synchronization and control of physical and digital entities, digital twin has been applied to multiple industrial scenarios. However, heterogeneous data and models have become stumbling blocks hindering the development of digital twin. The trusted sharing of the blockchain is naturally compatible with digital twin technology, especially in manufacturing scenarios with many participating entities and no mutual trust.

[0070] A digital twin network architecture for manufacturing can be divided into two parts: physical entities and digital entities. Among them, physical entities mainly include various industrial devices and network devices in the manufacturing workshop, and digital entities mainly include a digital twin control panel that receives requirements and preferences, a blockchain network that maintains data security and trust, and an oracle network that connects the blockchain and the digital twin physical entities.

[0071] As Figure 1 shown, the blockchain-based decentralized Internet collaboration system may include:

[0072] Device layer 101, which consists of physical entities. Among them, the physical entities collect source data through sensors and upload it to the digital entities;

[0073] Network layer 102, which consists of edge gateways and base stations, receives the source data from the physical entities, preprocesses the source data, and then uploads it to the digital entities;

[0074] Storage layer 103, which consists of cloud services and an edge blockchain network. The cloud services store the source data of the physical entities, and the metadata of the production source data is uploaded to the edge blockchain network for unique mapping indexing;

[0075] The oracle network layer 104 consists of a data oracle for in-domain data sharing, a cross-domain oracle for cross-domain data sharing, and a computing oracle for computing resource sharing;

[0076] The control layer 105 consists of a digital twin platform, which provides interfaces for adding, deleting, modifying, and querying for each production node based on the data flowing through the device layer, network layer, storage layer, and oracle network layer.

[0077] Among them, the above-mentioned edge blockchain network may include: the first layer, consisting of a federated chain formed by each participating entity and regulatory node, for managing global data; the second layer, consisting of local chains formed by each participating digital entity respectively, for managing local data.

[0078] Specifically, the above-mentioned data oracle may include: an application contract for receiving industrial data sharing requests of digital twin entities, a unified industrial data oracle interface, and a peer-to-peer network for obtaining and calling back industrial data off-chain; the above-mentioned cross-domain oracle may include: a source blockchain containing an application contract for receiving cross-domain sharing requests of entities, a destination blockchain containing a proxy contract for receiving cross-domain sharing requests, and a peer-to-peer network for forwarding and calling back cross-domain sharing requests; the above-mentioned computing oracle may include: an application contract for receiving industrial computing sharing requests, a computing oracle interface and a proxy contract, and a computing oracle network for calling back training results.

[0079] Based on the above blockchain-based decentralized Internet collaboration system, in this example, a method for data interaction is provided, as Figure 2 shown, which may include the following steps:

[0080] Step 201: Collaborate on industrial data on-chain and off-chain through a data oracle;

[0081] Specifically, collaborating on industrial data on-chain and off-chain through a data oracle may include:

[0082] S1: A physical entity or digital entity triggers an industrial data sharing event by calling the request function of the application contract and then calling the function of the proxy contract;

[0083] S2: The data oracle listens for the industrial data sharing event;

[0084] S3: The data oracle addresses the address specified by the industrial data sharing event to obtain industrial data and aggregates the data off-chain;

[0085] S4: Return the aggregation result to the off-chain data oracle network. This network monitors this event, locates the industrial data at the address specified in the industrial data sharing request, aggregates the data off-chain, and returns the aggregation result to the on-chain.

[0086] Step 202: Achieve inter-chain data collaboration through a cross-domain oracle.

[0087] Step 203: Achieve computing collaboration through a computing oracle.

[0088] When implementing, the collaboration of on-chain and off-chain industrial data through a data oracle can include:

[0089] S1: The target entity sends an off-chain industrial data request to the production contract and specifies a data interface or data source.

[0090] S2: The production contract calls the interface provided by the proxy contract to forward the industrial data request. The industrial data request includes at least one of the following: data source, public key, signature, certificate, callback address, timestamp, expiration time.

[0091] S3: After receiving the industrial data request, the proxy contract verifies the identity of the target entity and adds the industrial data request to the off-chain data request queue to trigger an off-chain event.

[0092] S4: After the data oracle monitors this event off-chain, it obtains data from the specified data source, and after off-chain aggregation and consensus, it calls back the data to the proxy contract. The callback data includes at least one of the following: data, public key group, callback address, timestamp, aggregated signature.

[0093] S5: After receiving the callback request, the proxy contract verifies the validity of the aggregated signature and determines whether the timestamp is less than the expiration time.

[0094] S6: If it is determined that the aggregated signature is valid and the timestamp is less than the expiration time, the callback request is called back to the production contract, and the industrial data request is deleted from the off-chain data request queue.

[0095] When implementing, the inter-chain data collaboration achieved through a cross-domain oracle can include:

[0096] S1: The target entity sends a cross-domain request to the production contract of the source local chain with cross-domain data requirements and specifies the target local chain that accepts the cross-domain request.

[0097] S2: The production contract invokes the cross - domain interface provided by the proxy contract on the source local chain with cross - domain data requirements to forward the cross - domain request. Among them, the cross - domain request carries at least one of the following: the specified target local chain that accepts the cross - domain request, the address of the production contract in the specified target local chain that accepts the cross - domain request, the data status to be modified, public key, signature, certificate, callback address, timestamp, deadline;

[0098] S3: After receiving the cross - domain request, the proxy contract verifies the identity of the target entity according to the certificate, adds the cross - domain request to the off - chain data request queue to be processed, and triggers a cross - domain event;

[0099] S4: The proxy for double - chain interaction forwards the cross - domain request to the federated chain and files it on the federated chain;

[0100] S5: The proxy for double - chain interaction writes the Merkle root of the filing transaction into the proxy contract of the source local chain with cross - domain data requirements;

[0101] S6: After the cross - domain oracle monitors the cross - domain event, it verifies whether the Merkle root exists in the federated chain after monitoring the cross - domain event;

[0102] S7: If it exists, after network consensus, write the cross - domain request into the proxy contract of the target local chain that accepts the cross - domain request;

[0103] S8: The proxy contract of the target local chain that specifies to accept the cross - domain request verifies the validity of the signature and determines whether the timestamp is less than the deadline;

[0104] S9: When it is determined that the signature is valid and the timestamp is less than the deadline, the proxy contract invokes the production contract specified by the callback address to modify the data and triggers a callback event;

[0105] S10: In response to the callback event, after performing a consensus operation, call the proxy contract of the source local chain with cross - domain data requirements to execute a callback operation;

[0106] S12: The proxy contract of the source local chain with cross - domain data requirements verifies the signature and the result. After passing the verification, call the production contract to return the result and remove the cross - domain request from the off - chain data request queue to be processed.

[0107] Specifically, to achieve computing collaboration through a computing oracle, it can include:

[0108] S1: A physical entity or a digital entity writes an industrial computing task into an application contract;

[0109] S2: The application contract forwards the industrial computing task to the proxy contract to trigger an industrial computing task sharing event;

[0110] The computing oracle monitors the industrial computing task sharing event and controls multiple nodes in the network to perform collaborative computing on the industrial computing task to obtain a computing result;

[0111] S3: Callback the computing result to the chain.

[0112] When implemented, when the computing oracle monitors the industrial computing task sharing event and controls multiple nodes in the network to perform collaborative computing on the industrial computing task to obtain a computing result, it may include:

[0113] S1: After each client node receives the computing task from the master node, it obtains the data it needs to process according to the storage location of the data set, trains to obtain the optimal model parameters according to the preset training rules and parameters, and sends the obtained optimal model parameters to the master node for aggregation;

[0114] S2: After the master node receives the optimal model parameters obtained by training sent by all client nodes, it selects a predetermined proportion of the test set to test each optimal model parameter to obtain a model parameter ranking result;

[0115] S3: Select the model parameters ranked in the top preset proportion from the model parameter ranking result and distribute them to the client nodes in the oracle network layer:

[0116] S4: After the client nodes in the oracle network layer receive the model parameters ranked in the top preset proportion, they verify whether the digest of the model parameters ranked in the top preset proportion is the same as the digest of the model parameters stored on the chain. If they are the same, the global model is updated.

[0117] Specifically, the above blockchain-based decentralized Internet collaborative system may include:

[0118] Device layer, which consists of physical entities such as industrial devices, production devices in the workshop, and acceptance devices for order delivery. These physical entities collect multi-modal data of the physical entities through sensors and upload it to the digital entities of the digital twin through the network layer.

[0119] Network layer, which consists of communication devices such as edge gateways and base stations. It receives the sensing data from the physical entities, uploads it to the digital entities after preprocessing, and issues the control commands of the digital entities to help the physical entities and digital entities achieve two-way data flow.

[0120] The storage layer includes cloud services and the edge blockchain network, and their functions complement each other. The redundant backup feature of the blockchain makes it impossible for the digital twin network to store large-scale multi-source heterogeneous data. At the same time, the types of transaction data in the edge blockchain are relatively single, which means it cannot access the data interfaces, data files, and database tables of the digital twin network. Meanwhile, each participant in the IIoT ecosystem usually stores data in its local data center and is not willing to upload it to decentralized storage. Therefore, in this example, cloud services and the blockchain are selected to jointly form the storage layer. However, the centralized feature of cloud services may lead to the problem of malicious nodes deliberately tampering with data. Therefore, in this example, it is considered that the source data produced by physical entities can be stored in cloud services, and the metadata of the production source data can be uploaded to the edge blockchain network for unique mapping indexing. By extending various data types into digital objects with a logically centralized and unified metadata index, which is convenient for on-chain use and off-chain management, the storage capacity of the blockchain can be expanded and data tampering can be prevented while a unified data standard can be constructed.

[0121] The Pedal layer (Oracle layer) mainly consists of data oracles responsible for in-domain data sharing, cross-domain oracles for cross-domain data sharing, and computing oracles for computing resource sharing. This oracle network can be regarded as Pedal, which is an important component of the digital twin. Due to the closed feature of the blockchain, that is, when reaching a consensus, it ensures that each node has the same result for the same transaction request, and it cannot actively interact with external digital and physical entities. Therefore, oracles are needed to connect the blockchain with the digital twin world, and industrial blockchains with each other, ultimately enabling the efficient full-process flow of data and computing tasks in the digital twin scenario.

[0122] The control layer consists of a digital twin platform. Based on the data flowing through the device layer, network layer, storage layer, and Pedal layer, this platform provides interfaces for adding, deleting, modifying, and querying to each production node, analyzes and mines the fault diagnosis, fault tolerance, etc. of each production process based on the double-layer blockchain network, constructs an industrial portrait of the full scenario, helps decision-makers at all levels efficiently control and receive device data from the industrial site, and improves efficiency.

[0123] The blockchain in the above storage layer is a blockchain ecosystem composed of two layers and multiple blockchains, named SewingChain. This is mainly because there are numerous participating entities, numerous domains, and a large amount of device data in the real IIoT ecosystem, making it difficult for these entities to build a completely unified blockchain network for data sharing, similar to the internal network within each company. At the same time, digital twins are an important part of future smart cities and require the participation of regulatory departments to standardize the behaviors of all participating entities. SewingChain includes the Federal Blockchain (FBC) with a regulatory role and the Local Blockchain (LBC) composed within each participating entity.

[0124] Among them, the first layer of SewingChain is the FBC jointly composed of all participating entities and regulatory departments, whose function is to achieve global industrial data governance. Nodes participating in the block consensus and verification of the FBC network can be called Federal Node, denoted as F_g. When interaction is required between industrial blockchains, between industrial blockchains and digital entities, and between industrial blockchains and physical entities, a request needs to be sent to the FBC, and only after obtaining the consensus of F_g can the interaction be carried out.

[0125] The second layer of SewingChain is the LBC composed of each participating digital entity respectively. There can be multiple LBCs, that is, digital entities can arbitrarily form LBCs, and its function is to achieve local industrial data management. The global nodes participating in the block consensus and verification of the LBC network are called Local Node, which can be expressed as L_g. Nodes with only the query permission for the LBC network are called ObserveNode, which can be expressed as L_o. L_g receives the metadata from physical entities and stores it in the LBC after waiting for consensus. If the off-chain cloud service node tamps with the data without permission, then the metadata of this part of the data cannot match the metadata in the LBC, and at this time it can be known that the data is untrue. L_o provides a query interface for the digital twin platform to facilitate the analysis and mining of data on the chain.

[0126] The above Pedal layer is mainly composed of a data oracle, a cross-domain oracle, and a computing oracle, which solve the problems of difficult in-domain sharing, difficult cross-domain sharing, and difficult computing sharing respectively.

[0127] Among them, the Data Oracle consists of three parts, namely, an application contract for receiving industrial data sharing requests of digital twin entities, a unified industrial data oracle interface, i.e., a proxy contract, and a peer-to-peer network for obtaining and callback industrial data off-chain, i.e., the data oracle network. Physical entities or digital entities trigger industrial data sharing events by calling the request function of the application contract and then the function of the proxy contract; the off-chain data oracle network listens for this event, locates the address specified in the industrial data sharing request to obtain industrial data, aggregates it off-chain, and returns the aggregation result to the chain.

[0128] The Cross-domain Oracle consists of a source blockchain, a destination blockchain, and a peer-to-peer network. The source blockchain contains an application contract for receiving cross-domain sharing requests of entities and a unified cross-domain oracle interface, i.e., a proxy contract; the destination blockchain contains a proxy contract for receiving cross-domain sharing requests and an application contract for executing cross-domain sharing requests; the peer-to-peer network is a peer-to-peer network for forwarding and callback cross-domain sharing requests.

[0129] The Computation Oracle consists of an application contract for receiving industrial computation sharing requests, a computation oracle interface and a proxy contract, and a computation oracle network for callback training results. Physical entities or digital entities write industrial computation tasks into the application contract, and then the application contract forwards the industrial computation tasks to the proxy contract, triggering industrial computation sharing events. The computation oracle network listens for this event and, as required, enables multiple nodes in the network to perform collaborative computations and finally callback the computation results to the chain.

[0130] Based on the above network architecture, data processing can be carried out according to the following process:

[0131] Industrial data interaction in the digital twin scenario mainly focuses on intra-domain sharing and cross-domain sharing. Intra-domain sharing refers to how industrial devices in the same trust domain communicate, and cross-domain sharing refers to how industrial data in different trust domains interact. Cross-domain sharing includes two parts: on-chain and off-chain and between chains. The data interaction mechanism is as follows:

[0132] Initialization:

[0133] Industrial devices, gateways, edge servers, etc. need to create a globally unique key in the SewingChain architecture. Using the elliptic curve digital signature algorithm and asymmetric keys, the identity information of each link and department is created. Since the consortium blockchain only allows authorized and authenticated nodes to join the blockchain network, it is more suitable for digital twin scenarios. Therefore, the above devices can authenticate each entity in each link of the digital twin through the authorized and authenticated nodes of the consortium blockchain. After successful authentication, the entity will have legal identity information on the chain, including: account address, public key, private key, and certificate.

[0134] For example, it can be expressed as: Addr_(e_i), PK_(e_i), SK_(e_i), Cert_(e_i), where Addr_(e_i) is a string calculated from PK_(e_i) through a cryptographic algorithm, with the collision-resistance property, and is used as the account address of each entity. SK_(e_i) is used for signing to uniquely represent the entity's ownership of Addr_(e_i), and Cert_(e_i) is used for authentication to prove the entity's legality in on-chain operations.

[0135] Inter-domain interaction:

[0136] Intra-domain interaction is the interaction between digital twin entities within the same trust domain, including the interaction between entities within the same LBC and the interaction between LBC and FBC.

[0137] Interaction within LBC:

[0138] The industrial data interaction within LBC is roughly the same as the general blockchain network transaction process. The only difference is that in order to maintain the supervision of LBC by FBC, LBC needs to regularly send the Merkle root of the latest block locally to FBC for storage, for future traceability. Since the periodic snapshot only saves the Merkle root and transaction summary, it will not affect the performance of FBC.

[0139] Interaction between LBC and FBC:

[0140] LBC contains a special L_g, denoted as L_f. This node has both read and write permissions for LBC and FBC and serves as an agent for the interaction between the two chains. L_f can be selected by methods such as reputation value, direct assignment, rotation, verifiable random function, etc. L_g will regularly upload the on-chain snapshot of the latest blockchain in LBC to LBC for storage.

[0141] The specific process is as follows: L_g broadcasts the transaction to LBC, and other L_g and L_f execute the predefined consensus mechanism. Subsequently, the request is stored in the databases of each node of LBC. After a certain block height, L_f broadcasts the on-chain snapshot of LBC (including the Merkle root and transaction summary) to F_g of FBC to initiate the consensus process. After the consensus ends, the on-chain snapshot of LBC is saved on FBC.

[0142] The role of this hierarchical interaction is that a large number of digital twin data requests will be consensus separately on multiple LBCs in the lower layer according to regions and industries, and the upper-layer FBC only performs incremental saving, so as to improve scalability. Although the method of only saving the on-chain snapshot in the upper-layer FBC will lead to a decrease in data availability, due to the security of the blockchain network LBC, it is worthwhile to sacrifice some data availability in exchange for data scalability.

[0143] Cross-domain sharing:

[0144] Cross-domain sharing refers to the interaction of digital twin entities in different trust domains, including cross-domain sharing on-chain and off-chain and between chains, that is, LBC or FBC requests real-time industrial data from the outside world, and LBC and LBC interact industrial data.

[0145] On-chain and off-chain collaboration:

[0146] In some links of digital twins, real-time off-chain data needs to be used. Taking the settlement of manufacturing export funds as an example, the exchange rate at that moment needs to be called for settlement. However, LBC or FBC is limited by the characteristics of the blockchain network and cannot actively obtain real-time data from the outside world, let alone obtain fund data through a data interface. Therefore, in this example, a data oracle is used to achieve on-chain and off-chain industrial data collaboration.

[0147] The whole mechanism is divided into the following parts: entities with off-chain industrial data requirements, cloud services storing corresponding data, production contract LoProd receiving entity demand logic, proxy contract LoProxy providing off-chain data interfaces, LBC, and Pedal network based on data oracle.

[0148] Specifically, entity e i sends an off-chain industrial data requirement to LoProd and specifies a data interface or data source. Subsequently, LoProd calls the interface provided by LoProxy and forwards the request, which can include: data source d s public key signature certificate callback address addr c timestamp deadline exp t, where addr c is the contract address of LoProd on LBC. It can be expressed as:

[0149]

[0150] After obtaining the request, LoProxy first verifies the identity of the entity, then adds the message to the off-chain data request queue to be processed. After the transaction is written to LBC, it will trigger an off-chain event. After the data oracle in the Pedal network hears the event off-chain, the node goes to the specified d s to obtain the data, and after off-chain aggregation and consensus, it calls back the data to LoProxy. The callback message can include: data, public key group callback address addr c , timestamp aggregated signature Sig a . It can be expressed as:

[0151]

[0152] After receiving the callback request, LoProxy first verifies the validity of Sig a , and then verifies if it is less than exp t . If the above conditions are all met, it will call back resp to LoProd and delete it from the off-chain data request queue. When LBC broadcasts the above transaction, e i can obtain the data of the specified d s .

[0153] Cross-chain collaboration:

[0154] The multi-chain heterogeneous interconnection ecosystem of digital twins makes it a problem to be solved for each LBC to cooperate with each other. In this example, cross-chain data collaboration is achieved based on a cross-domain oracle.

[0155] The whole mechanism can be divided into: Source LBC (SLBC) with cross-domain data requirements, FBC for filing cross-domain requests, Pedal based on cross-domain oracle for executing cross-domain requests, and Destination LBC (DLBC) for accepting cross-domain requests.

[0156] Specifically, entity e i sends a cross-domain request to LoProd of SLBC and specifies DLBC. Then LoProd calls the cross-domain interface provided by LoProxy on SLBC and forwards the request. The request can include: the specified SLBC, the address Addr of LoProd in SLBC d , the data state s to be modified, public key signature Certificate Callback address addr c , Timestamp Expiration time exp t . It can be expressed as:

[0157]

[0158] After obtaining a cross - domain request, LoProxy can first verify the entity's identity according to , then add the request to the queue of off - chain data requests to be processed. After the transaction is written to SLBC, a cross - domain event is triggered. At the same time, L f needs to forward the request to FBC. After filing the cross - domain request on FBC, L f then writes the Merkle root root m of the filing transaction to the LoProxy of SLBC. After the cross - domain oracle in the Pedal network monitors the cross - domain event, it first verifies whether root m exists in FBC. If it does not exist, the request is not executed, and after exp t passes, the relevant status is restored; if it exists, after consensus in the pedal network, a cross - domain request is written to the LoProxy of DLBC, and the content of the request can be expressed as:

[0159]

[0160] The LoProxy of DLBC first verifies the validity of Sig a , and then verifies whether is less than exp t . If the above conditions are met, LoProxy calls LoProd specified by Addr d to modify the corresponding s and trigger a callback event. The Pedal network performs relevant consensus and calls the LoProxy of SLBC to execute the callback operation. The content of the callback can be expressed as:

[0161]

[0162] The LoProxy of SLBC verifies the validity and result of the signature. If it passes, it calls LoProd to return the result and removes the request from the queue of cross - domain requests to be completed.

[0163] Regarding the main consensus method of the Pedal network:

[0164] Based on verifiable random functions and threshold signatures, it supports data interaction and collaboration among data oracles, cross-domain oracles, and computing oracles. The Pedal consensus is jointly guaranteed by on-chain and off-chain parts. The off-chain part conducts voting, and the on-chain part verifies the results. The entire consensus process can be divided into: registration, election, aggregation, and callback.

[0165] Registration:

[0166] Due to the consortium characteristics of digital twins, the nodes participating in the Pedal network need to register in advance on the FBC to obtain a legal identity. The generation of node identities requires k nodes. First, k positive integers s1, s2,..., s k , and gcd(s i , s j ) = 1 (i ≠ j) are relatively prime. Then, these integers are used as seeds seed and the multiplicative cyclic group G1 to generate the key pair key(sk i , pk i , x i ), that is, the private key, public key, and signature. The threshold signature contains a linear mapping e such that the multiplicative cyclic group has the property G1xG2 → G3. In addition, the threshold signature also has the homomorphic property, that is, for any two transactions tx1, tx2, if the transaction satisfies tx ∈ G2, then h(tx1 + tx2) = h(tx1) + h(tx2), where h is the hash function.

[0167] Election:

[0168] The election refers to the primary node of the consensus group. Nodes need to register in the election contract FeElect of the FBC to participate in the election of the primary node. The generation of the primary node requires the use of VRF. First, it relies on a string of any length to generate where α is a string composed of messages, terms, etc., used to screen nodes. Here, the term means that to prevent fraud that may occur due to the long tenure of the primary node, the primary node needs to be rotated after a certain block height. The seed of the leader in the first term term is empty.

[0169] Nodes generate a pair of public and private keys locally and generate a signature Generate a random number and proof based on their own private key and the published seed It should be emphasized that the locally generated sk and π at each node are invisible, that is, other nodes cannot know which node is elected as the master node. However, during the election process, three situations may occur: First, there is exactly one node that meets the conditions, and this node is the master node; Second, multiple nodes meet the conditions or no node meets the conditions, and FeElect polls from the candidate pool to select. After the master node is elected, the group led by the master node polls, samples, or uses other more random methods from the candidate pool. After the working group is formed, the group public key of this working group will be generated.

[0170] Aggregation:

[0171] When a node in Pedal hears a req, it operates according to the message content carried by the req. The node generates a signature σ i =(h(req)) x , and forwards this message to the master node. After the master node receives a sufficient number of messages, it aggregates according to the following formula:

[0172]

[0173] Callback:

[0174] The master node writes the aggregated message and signature into the proxy contract. The proxy contract first verifies the identity of the master node from two aspects:

[0175]

[0176] Subsequently, the proxy contract verifies the validity of the aggregated signature. If the following equation is satisfied, it accepts; otherwise, it rejects:

[0177]

[0178] After the proxy contract verifies the validity of the signature, it returns the aggregated signature and the request result to the application contract, and removes the req from the queue being executed.

[0179] Computing oracle:

[0180] Digital twin entities with limited resources need to use a computing oracle to outsource computing tasks. The computing oracle combines Pedal consensus and federated learning to enable multiple nodes in the Pedal network to collaborate to complete computing tasks. However, during the outsourcing process, node misbehavior may occur. The first is that the aggregating node misbehaves, which can be solved by the method of aggregated signature. The second is the situation where the client node misbehaves. For the misbehavior of the client node, in this example, an abnormal node detection mechanism based on verification sorting is proposed. In this example, the computing sharing method assumes that the number m of malicious nodes does not exceed That is

[0181] The digital twin entity with limited computing resources writes the computing requirements into LoProd. The computing requirements need to include necessary training parameters such as dataset D, dataset storage location url, number of communication rounds r, number of iteration rounds e, learning rate η, batch size B, seed, etc., and calculate the optimal model parameter w according to the following equation. Subsequently, LoProd is forwarded to LoProxy, triggering a computing resource sharing event, which is listened to by the master node of Pedal.

[0182]

[0183] Local update:

[0184] After the client nodes in Pedal receive the computing tasks from the master node, they first obtain D according to the url i , and then train the parameter w layer by layer according to the parameters (r, e, η,..., B) i . Subsequently, it is sent to the master node for aggregation:

[0185]

[0186] Aggregation:

[0187] After the master node receives all the w i , it does not directly aggregate like FedAvg. Since the local D of each client node i is not the same, it is difficult to guarantee the effectiveness of w i . w i may be obtained through training or randomly generated. Therefore, the master node can take out the test set to test each w i to obtain the sorted result w s , as described in the following equation. And according to w s select the top w i to obtain the aggregated result w g and download it to the client nodes of the Pedal network, as described in the following equation. At the same time, in order to prevent the master node from downloading different parameters to different client nodes, it needs to write the digest of w g into LBC for verification.

[0188]

[0189] Global update:

[0190] After the client nodes in the Pedal network receive w g′ , they first verify w g′Is the summary of w stored on the chain g The summaries are the same; if they are the same, then the global model is updated; if they are not the same, the model is not updated.

[0191] The value of α can be determined based on experience. The main purpose is to use rough tests to determine the value of w. i For the value of , it can be assumed that there are n client nodes participating in the training in the digital twin network, among which there are m malicious nodes, and they satisfy The characteristic of malicious nodes is that they randomly generate w i , the parameter results generated by the malicious node are better than some The probability of an honest node is ξ, and the probability of the generated parameter result being worse than that of some honest nodes is 1-ξ. Then the top nodes with better results selected after Verify-Sort are The probability that there are k1 malicious nodes in is:

[0192]

[0193] In addition to the probability of malicious nodes being partially honest nodes, they also have to become the front of the decision model. Node γ, then after verifying the sorting, the top The probability that there are k2 malicious nodes in is:

[0194]

[0195] Since the probabilities of ξ and γ are much smaller than those of honest nodes, the possibility of malicious nodes attempting to interfere with the collaborative process of digital twin computing is low.

[0196] In the above example, considering that intelligent IIoT machines require frequent data exchange between physical entities and digital entities, this poses a severe challenge to the traditional centralized industrial architecture, and a decentralized industrial architecture is imminent. However, the decentralized industrial architecture based on blockchain and digital twins cannot handle huge and complex industrial data, cannot connect equipment data in the industrial blockchain ecosystem, and cannot handle complex and energy-intensive industrial computing tasks. To solve the above problems, in the above example, a decentralized industrial Internet collaboration mechanism based on blockchain is proposed, and a data collaboration network based on oracles is proposed to connect industrial data on the chain, off the chain, and between chains, and achieve consistency of off-chain data through a logically unified collaboration mechanism. Furthermore, a computing collaboration network based on oracles is proposed to transfer computing tasks to off-chain execution, and to achieve the authenticity of off-chain computing tasks through a reliable aggregation method.

[0197] The embodiments of the present application also provide a specific implementation of an electronic device capable of implementing all the steps in the data interaction method in the above embodiments, wherein the electronic device specifically includes the following contents: a processor, a memory, a communication interface, and a bus; wherein the processor, the memory, and the communication interface communicate with each other through the bus; the processor is used to call a computer program in the memory, and when the processor executes the computer program, all the steps in the data interaction method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0198] Step 1: Collaborate on-chain and off-chain industrial data through data oracles;

[0199] Step 2: Realize data collaboration between chains through cross-domain oracles;

[0200] Step 3: Achieve computational collaboration through computational oracle.

[0201] From the above description, it can be seen that the embodiment of the present application can connect the off-chain and on-chain data by introducing data oracles and cross-domain oracles, and can achieve the consistency of off-chain data through a unified collaborative mechanism. By introducing computing oracles, computing tasks can be transferred to off-chain execution, and the authenticity of off-chain computing tasks can be guaranteed. That is, by introducing oracles in the collaborative system, the problem of inefficient data interaction between existing digital entities and physical entities can be effectively solved, and the technical effect of efficient and accurate data interaction can be achieved, and complex data calculations can be completed.

[0202] The embodiments of the present application also provide a computer-readable storage medium capable of implementing all the steps in the data interaction method in the above embodiments. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, all the steps of the data interaction method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0203] Step 1: Collaborate on-chain and off-chain industrial data through data oracles;

[0204] Step 2: Realize data collaboration between chains through cross-domain oracles;

[0205] Step 3: Achieve computational collaboration through computational oracle.

[0206] As can be seen from the above description, in the embodiments of the present application, by introducing a data oracle and a cross-domain oracle, the off-chain and on-chain data can be connected, and the consistency of off-chain data can be achieved through a unified coordination mechanism. By introducing a computing oracle, the computing tasks can be transferred to off-chain execution, and the authenticity of off-chain computing tasks can be ensured. That is, by introducing oracles in the coordination system, the problem that there is no efficient data interaction between existing digital entities and physical entities can be effectively solved, the technical effect of efficient and accurate data interaction is achieved, and complex data calculations can be completed.

[0207] The embodiments in this specification are all described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the hardware + program type embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0208] The specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0209] Although the present application provides method operation steps as described in the embodiments or flowcharts, based on routine or non-creative labor, there may be more or fewer operation steps. The order of steps listed in the embodiments is only one way among the execution orders of numerous steps and does not represent the only execution order. When the actual device or client product is executed, it can be executed in the order shown in the embodiments or the drawings or in parallel (such as in an environment of parallel processors or multi-threaded processing).

[0210] The systems, devices, modules, or units clarified in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0211] Although the embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way among the execution orders of numerous steps and does not represent the only execution order. When the actual device or terminal product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or executed in parallel (for example, in an environment of parallel processors or multi-threaded processing, or even in a distributed data processing environment). The term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, product or device comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or also includes elements inherent to such process, method, product or device. Without further limitation, there is no exclusion of additional identical or equivalent elements in the process, method, product or device comprising the said elements.

[0212] For the convenience of description, when describing the above device, it is divided into various modules according to functions for separate description. Of course, when implementing the embodiments of this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the modules implementing the same function can be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

[0213] Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the method steps can be logically programmed to enable the controller to be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same function. Therefore, such a controller can be regarded as a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and the structures within the hardware component.

[0214] This application is described with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of flows and / or blocks in the flowchart and / or block diagram can also be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or means for implementing the functions specified in multiple blocks.

[0215] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means implement the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or means for implementing the functions specified in multiple blocks.

[0216] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or means for implementing the functions specified in multiple blocks.

[0217] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

[0218] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0219] A computer-readable medium includes both permanent and non-permanent, removable and non-removable media and can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information accessible by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0220] Those skilled in the art will understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, the embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) that contain computer-usable program code.

[0221] The embodiments of this specification can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The embodiments of this specification can also be practiced in a distributed computing environment where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0222] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For the relevant parts, reference can be made to the corresponding description in the method embodiment. In the description of this specification, the description of reference terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the embodiments of this specification. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0223] The above is only the embodiment of the embodiments of this specification and is not used to limit the embodiments of this specification. For those skilled in the art, various changes and modifications can be made to the embodiments of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of this specification shall be included within the scope of the claims of the embodiments of this specification.

Claims

1. A method for data interaction using a blockchain-based decentralized Internet collaboration system, characterized in that, The blockchain-based decentralized Internet collaboration system includes: The device layer, which consists of physical entities. Among them, the physical entities collect source data through sensors and upload it to digital entities. The network layer, which consists of edge gateways and base stations, receives the source data from the physical entities, preprocesses the source data, and uploads it to digital entities. The storage layer, which is jointly composed of cloud services and an edge blockchain network, stores the source data of the physical entities through cloud services, and uploads the metadata of the production source data to the edge blockchain network for unique mapping indexing. The oracle network layer, which consists of a data oracle for in-domain data sharing, a cross-domain oracle for cross-domain data sharing, and a computing oracle for computing resource sharing. The control layer, which consists of a digital twin platform, and is used to provide interfaces for adding, deleting, modifying, and querying for each production node based on the data flowing through the device layer, network layer, storage layer, and oracle network layer. The edge blockchain network includes: The first layer, which consists of a federated chain formed by each participating entity and regulatory node, and is used to manage global data. The second layer, which consists of local chains formed by each participating digital entity respectively, and is used to manage local data. The data oracle includes: an application contract for receiving industrial data sharing requests from digital twin entities, a unified industrial data oracle interface, and a peer-to-peer network for obtaining and calling back industrial data off-chain. The cross-domain oracle includes: a source blockchain containing an application contract for receiving cross-domain sharing requests from entities, a destination blockchain containing a proxy contract for receiving cross-domain sharing requests, and a peer-to-peer network for forwarding and calling back cross-domain sharing requests. The computing oracle includes: an application contract for receiving industrial computing sharing requests, a computing oracle interface and proxy contract, and a computing oracle network for calling back training results. The method includes: Carrying out the collaboration of industrial data on-chain and off-chain through a data oracle. Achieving inter-chain data collaboration through a cross-domain oracle. Achieving computing collaboration through a computing oracle. Among them, achieving inter-chain data collaboration through a cross-domain oracle includes: The target entity sends a cross-domain request to the production contract of the source local chain with cross-domain data requirements and specifies the target local chain that accepts the cross-domain request. The production contract calls the cross-domain interface provided by the proxy contract on the source local chain with cross-domain data requirements to forward the cross-domain request. Among them, the cross-domain request carries at least one of the following: the specified target local chain that accepts the cross-domain request, the address of the production contract in the specified target local chain that accepts the cross-domain request, the data state to be modified, the public key, the signature, the certificate, the callback address, the timestamp, and the deadline. After receiving the cross-domain request, the proxy contract verifies the identity of the target entity according to the certificate, adds the cross-domain request to the off-chain data request queue to be processed, and triggers a cross-domain event. The proxy for double-chain interaction forwards the cross-domain request to the federated chain and records it on the federated chain. The proxy for double-chain interaction writes the Merkle root of the recorded transaction into the proxy contract of the source local chain with cross-domain data requirements. After the cross - domain oracle monitors the cross - domain event, it verifies whether the Merkle root exists in the federated chain after monitoring the cross - domain event; If it exists, after network consensus, write the cross - domain request into the proxy contract of the target local chain that accepts the cross - domain request; The proxy contract of the target local chain that accepts the cross - domain request verifies the validity of the signature and determines whether the timestamp is less than the deadline; When it is determined that the signature is valid and the timestamp is less than the deadline, the proxy contract calls the production contract specified by the callback address to modify the data and triggers a callback event; In response to the callback event, after performing a consensus operation, call the proxy contract of the source local chain with cross - domain data requirements to execute a callback operation; The proxy contract of the source local chain with cross - domain data requirements verifies the signature and the result. After verification passes, call the production contract to return the result and remove the cross - domain request from the off - chain data request queue to be processed; 2. The method according to claim 1, wherein The coordination of on - chain and off - chain industrial data is carried out through a data oracle, including: Physical entities or digital entities trigger an industrial data sharing event by calling the request function of the application contract, and then calling the function of the proxy contract; The data oracle monitors the industrial data sharing event; The data oracle addresses the address specified by the industrial data sharing event to obtain industrial data and aggregates the data off - chain; Return the aggregation result to the off - chain data oracle network to monitor this event, address the address specified by the industrial data sharing request to obtain industrial data, aggregate it off - chain, and return the aggregation result to the on - chain; 3. The method according to claim 1, characterized in that, The coordination of on - chain and off - chain industrial data is carried out through a data oracle, including: The target entity sends an off - chain industrial data request to the production contract and specifies a data interface or data source; The production contract calls the interface provided by the proxy contract to forward the industrial data request, where the industrial data request includes at least one of the following: data source, public key, signature, certificate, callback address, timestamp, and deadline; After receiving the industrial data request, the proxy contract verifies the identity of the target entity and adds the industrial data request to the off - chain data request queue to trigger an off - chain event; After the data oracle monitors this event off - chain, it obtains data from the specified data source, and after off - chain aggregation and consensus, it calls back data to the proxy contract, where the callback data includes at least one of the following: data, public key group callback address, timestamp, and aggregated signature; After receiving the callback request, the proxy contract verifies the validity of the aggregated signature and determines whether the timestamp is less than the deadline; When it is determined that the aggregated signature is valid and the timestamp is less than the deadline, the callback request is called back to the production contract, and the industrial data request is deleted from the off - chain data request queue; 4. The method according to claim 1, characterized in that, The implementation of computing coordination through a computing oracle includes: Physical entities or digital entities write industrial computing tasks into the application contract; The application contract forwards the industrial computing task to the proxy contract to trigger an industrial computing task sharing event; The computing oracle monitors the industrial computing task sharing event and controls multiple nodes in the network to perform collaborative computing on the industrial computing task to obtain a computing result; Callback the computing result to the chain.

5. The method according to claim 4, characterized in that, When the computing oracle monitors the industrial computing task sharing event and controls multiple nodes in the network to perform collaborative computing on the industrial computing task to obtain a computing result, it includes: After each client node receives the computing task from the master node, it obtains the data it needs to process according to the storage location of the data set, trains to obtain the optimal model parameters according to the preset training rules and parameters, and sends the obtained optimal model parameters to the master node for aggregation; After the master node receives the optimal model parameters obtained by training sent by all client nodes, it selects a predetermined proportion of the test set to test each optimal model parameter to obtain a model parameter ranking result; Select the model parameters ranked in the top preset proportion from the model parameter ranking result and distribute them to the client nodes in the oracle network layer: After the client nodes in the oracle network layer receive the model parameters ranked in the top preset proportion, they verify whether the digest of the model parameters ranked in the top preset proportion is the same as the digest of the model parameters stored on the chain. If they are the same, the global model is updated.

6. A computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images