Industrial Internet of Things cooperative management system and method of double-track block chain consensus engine, computer equipment and medium

Abstract

The invention discloses an industrial Internet of Things cooperative management method and system of a double-track block chain consensus engine, computer equipment and a medium, and the method comprises the steps: carrying out the data distribution based on multi-type data, and carrying out the dynamic fragmentation of high-priority real-time data based on a core layer; sorting the blocks in each fragment, executing a dual-stage submission protocol, and outputting an encrypted block; tracking behavior data of the nodes in real time based on a daemon layer, performing anomaly detection, and synchronizing an anomaly evidence set to all the nodes based on a Byzantine broadcast mechanism when an abnormal event is detected; and performing hash chain verification on the encrypted block, transmitting the encrypted block passing the verification into a trusted execution environment, and issuing an industrial control instruction to a production line execution terminal after verifying a hardware signature. According to the invention, low-delay consensus, rapid fault recovery, cross-platform compatibility and dynamic fault-tolerant balance can be realized through a double-track collaborative architecture of the core layer and the guard layer in combination with the collaborative verification capability of the trusted execution environment.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) technology, and in particular to an industrial IoT collaborative management method, system, computer equipment, and medium based on a dual-track blockchain consensus engine. Background Technology

[0002] With the deepening of Industry 4.0, the Industrial Internet of Things (IIoT) has become a core supporting technology for fields such as intelligent manufacturing, smart energy, and cross-border trade. In industrial scenarios, massive amounts of terminal equipment (such as PLC controllers, sensors, handling robots, and smart meters) need to achieve real-time data interaction and collaborative control. For example, in discrete production lines such as automobile manufacturing, equipment needs to respond to control commands in milliseconds; in cross-border financial settlement scenarios, a large amount of letter of credit verification data needs to be processed; in smart energy microgrids, electricity price commands and energy storage charging and discharging actions need to be executed atomically to avoid overload tripping. These scenarios place demands on the system's real-time performance, security, and availability. Blockchain technology, due to its distributed, immutable, and traceable characteristics, provides a new solution for trusted data management in the Industrial Internet of Things. However, the insufficient adaptability of traditional blockchain consensus technology to industrial scenarios restricts its large-scale application.

[0003] However, existing technologies suffer from several drawbacks, including excessive consensus latency, inability to meet real-time requirements, and technical limitations such as fault recovery deadlock, cross-platform barriers, and poor protocol compatibility in traditional single-layer architectures.

[0004] Therefore, existing technologies still need improvement. Summary of the Invention

[0005] To address the aforementioned shortcomings of existing technologies, this invention provides an industrial IoT collaborative management method, system, computer equipment, and medium based on a dual-track blockchain consensus engine. The technical solution adopted by this invention is as follows: In a first aspect, the present invention provides an industrial IoT collaborative management method with a dual-track blockchain consensus engine, the method comprising: Based on the collection of multiple types of data by industrial IoT terminals, the multiple types of data are sorted. Based on the core layer, the high-priority real-time data obtained after data diversion is dynamically fragmented, the blocks within each fragment are sorted, a two-phase commit protocol is executed on the sorted blocks, and encrypted blocks are output. Based on the real-time tracking of node behavior data by the guardian layer and anomaly detection, when an abnormal event is detected, the abnormal evidence set is synchronized to all nodes based on the Byzantine broadcast mechanism; The encrypted block is verified by hash chain, the verified encrypted block is passed to the trusted execution environment, and after verifying the hardware signature, the industrial control command is sent to the production line execution terminal.

[0006] In one implementation, multiple types of data are collected based on industrial IoT terminals, and the multiple types of data are then sorted, including: Data stream vector sets are formed by collecting various types of data based on industrial IoT terminals; The data flow vector set is split by a routing function to control the data flow to the core layer or the guardian layer.

[0007] In one implementation, a routing function is used to split the data flow vector set and control the data flow to the core layer or the guardian layer, including: If the latency tolerance of the data in the data stream vector set is less than or equal to the preset real-time threshold, then control the flow of high-priority real-time data to the core layer. If the latency tolerance of the data in the data stream vector set is greater than the preset real-time threshold, then the security monitoring data flow is controlled to the guardian layer.

[0008] In one implementation, the routing function is represented as:

[0009] in, Data latency tolerance represents the maximum allowable processing latency for data. This is a real-time threshold that can be dynamically configured according to the application scenario. Indicates the core layer. This indicates the protection layer.

[0010] In one implementation, the high-priority real-time data obtained after data diversion is dynamically fragmented based on the core layer, and the blocks within each fragment are sorted, including: Based on the core layer receiving the high-priority real-time data, the high-priority real-time data is merged into the transaction pool, and the high-priority real-time data is dynamically sharded to obtain several block subsets. A 5f+1 node architecture is adopted, and the blocks within each shard are sorted based on the DAG topology.

[0011] In one implementation, a two-phase commit protocol is executed on the sorted blocks to output encrypted blocks, including: Nodes sign off on the sorted blocks; The vote count is tallied, and a consensus certificate is generated when the required number of votes is met. Based on the consensus certificate, encrypted blocks are generated using a trusted encryption function.

[0012] In one implementation, the daemon layer tracks node behavior data in real time and performs anomaly detection, including: The cross-layer verification interface based on the guardian layer receives security monitoring data and tracks the behavior data of the core layer nodes in real time, constructing a behavior vector for each node; Anomaly detection is performed using an anomaly detection function based on the aforementioned behavior vector; If the detected index is lower than the preset threshold, the node is determined to have experienced an abnormal event.

[0013] In one implementation, based on the real-time tracking of node behavior data by the guardian layer and the anomaly detection, it also includes: If the number of abnormal nodes exceeds the fault tolerance limit, an early warning will be triggered.

[0014] In one implementation, when an anomalous event is detected, the set of anomalous evidence is synchronized to all nodes based on a Byzantine broadcast mechanism, including: When an abnormal event is detected, the Byzantine broadcast mechanism is activated to synchronize the abnormal evidence set to all nodes according to the reliable broadcast conditions; Execute the synchronization recovery protocol, remove abnormal nodes, and reconfigure the core layer node set.

[0015] In one implementation, the method further includes: The cross-layer verification interface based on the guardian layer collects the operating status data of the production line execution terminal in real time; The detection threshold of the guardian layer is dynamically optimized or updated based on the feedback mechanism.

[0016] Secondly, embodiments of the present invention also provide an industrial IoT collaborative management system with a dual-track blockchain consensus engine, wherein the system is used for the steps of the industrial IoT collaborative management method with a dual-track blockchain consensus engine as described in any of the above solutions, and the system includes: The data splitting module is used to collect multiple types of data based on industrial IoT terminals and to split the multiple types of data. The dynamic sharding and sorting module is used to dynamically shard the high-priority real-time data obtained by data diversion based on the core layer, sort the blocks within each shard, execute the two-phase commit protocol on the sorted blocks, and output encrypted blocks. The anomaly detection module is used to track the behavior data of nodes in real time based on the guardian layer and perform anomaly detection. When an abnormal event is detected, the abnormal evidence set is synchronized to all nodes based on the Byzantine broadcast mechanism. The verification and execution module is used to perform hash chain verification on the encrypted block, pass the verified encrypted block into the trusted execution environment, and after verifying the hardware signature, issue industrial control instructions to the production line execution terminal.

[0017] In one implementation, the data splitting module includes: The data acquisition unit is used to collect various types of data based on industrial IoT terminals and form a data stream vector set. The security monitoring data diversion unit is used to control the flow of high-priority real-time data to the core layer if the latency tolerance of the data in the data flow vector set is less than or equal to the preset real-time threshold. The high-priority real-time data diversion unit is used to control the flow of security monitoring data to the guardian layer if the latency tolerance of the data in the data flow vector set is greater than the preset real-time threshold.

[0018] In one implementation, the dynamic sharding and sorting module includes: The dynamic sharding unit is used to receive the high-priority real-time data based on the core layer, merge the high-priority real-time data into the transaction pool, and dynamically shard the high-priority real-time data to obtain several block subsets. The block sorting unit is used to sort the blocks within each shard using a 5f+1 node architecture and a DAG topology.

[0019] In one implementation, the dynamic sharding and sorting module also includes: The node signing unit is used to sign the sorted blocks. The consensus certificate generation unit is used to summarize the vote count and generate a consensus certificate when the vote count meets the requirements. A block encryption unit is used to generate encrypted blocks based on the consensus certificate using a trusted encryption function.

[0020] In one implementation, the anomaly detection module includes: The behavior vector construction unit is used to receive security monitoring data based on the cross-layer verification interface of the guardian layer, and to track the behavior data of the core layer nodes in real time to construct the behavior vector of each node. An anomaly detection unit is used to perform anomaly detection based on the behavior vector using an anomaly detection function; An abnormal event determination unit is used to determine that an abnormal event has occurred at a node if the detected index is lower than a preset threshold.

[0021] The synchronization node unit is used to initiate the Byzantine broadcast mechanism when an abnormal event is detected, and to synchronize the abnormal evidence set to all nodes according to the reliable broadcast conditions; The synchronization recovery unit is used to execute the synchronization recovery protocol, remove abnormal nodes, and reconfigure the core layer node set.

[0022] Thirdly, embodiments of the present invention also provide a computer device, wherein the computer device includes a memory, a processor, and an industrial IoT collaborative management program of a dual-track blockchain consensus engine stored in the memory and executable on the processor. When the processor executes the industrial IoT collaborative management program of the dual-track blockchain consensus engine, it implements the steps of the industrial IoT collaborative management method of the dual-track blockchain consensus engine of any of the above-mentioned schemes.

[0023] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores an industrial IoT collaborative management program of a dual-track blockchain consensus engine, and the industrial IoT collaborative management program of the dual-track blockchain consensus engine implements the steps of the industrial IoT collaborative management method of the dual-track blockchain consensus engine as described in any of the above schemes on the computer-readable storage medium.

[0024] Beneficial Effects: Compared with existing technologies, this invention provides an industrial IoT collaborative management method based on a dual-track blockchain consensus engine. First, this invention collects multiple types of data from industrial IoT terminals, performs data diversion on these data types, and dynamically shards the high-priority real-time data obtained after data diversion based on the core layer. Then, the blocks within each shard are sorted, and a two-phase commit protocol is executed on the sorted blocks to output encrypted blocks. Next, the behavior data of nodes is tracked in real time based on the guardian layer, and anomaly detection is performed. When an abnormal event is detected, the abnormal evidence set is synchronized to all nodes based on the Byzantine broadcast mechanism. Finally, the encrypted blocks are verified using a hash chain, and the verified encrypted blocks are passed to the trusted execution environment. After verifying the hardware signature, industrial control commands are issued to the production line execution terminal.

[0025] This invention can achieve low-latency consensus, rapid fault recovery, cross-platform compatibility, and dynamic fault tolerance balance through a dual-track collaborative architecture of core layer and guardian layer, combined with the hardware and software collaborative verification capabilities of trusted execution environment. It can build an end-to-end trusted pipeline from industrial IoT terminal data collection to production line execution terminal command issuance, meeting the core needs of scenarios such as intelligent production line control of industrial IoT, cross-border financial settlement, and smart energy microgrid management. Attached Figure Description

[0026] Figure 1 This diagram illustrates the application environment of the industrial IoT collaborative management method using a dual-track blockchain consensus engine, as provided in this embodiment of the invention.

[0027] Figure 2 This is a flowchart illustrating a preferred embodiment of the industrial IoT collaborative management method using a dual-track blockchain consensus engine provided in this invention.

[0028] Figure 3A schematic diagram of the technical route of the industrial IoT collaborative management method with a dual-track blockchain consensus engine provided in this embodiment of the invention.

[0029] Figure 4 This is a schematic diagram of the data diversion process in the industrial IoT collaborative management method of the dual-track blockchain consensus engine provided in this embodiment of the invention.

[0030] Figure 5 This is a schematic diagram of the dynamic sharding and sorting process in the industrial IoT collaborative management method of the dual-track blockchain consensus engine provided in this embodiment of the invention.

[0031] Figure 6 This is a schematic diagram of the two-stage submission process in the industrial IoT collaborative management method of the dual-track blockchain consensus engine provided in this embodiment of the invention.

[0032] Figure 7 This is a schematic diagram of the anomaly detection process in the industrial IoT collaborative management method of the dual-track blockchain consensus engine provided in this embodiment of the invention.

[0033] Figure 8 This is a system block diagram of an industrial IoT collaborative management system with a dual-track blockchain consensus engine, provided in an embodiment of the present invention.

[0034] Figure 9 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0036] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0037] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0038] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, the first control information and the second control information are only used to distinguish different control information and do not limit their order.

[0039] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0040] It should also be understood that the terms "and / or" as used in this specification and the appended claims refer to any combination of one or more of the associated listed items and all possible combinations, and include such combinations.

[0041] The existing technologies mainly suffer from the following technical pain points: 1. The consensus latency is too high, failing to meet real-time requirements. Traditional Byzantine Fault Tolerance (BFT) protocols (such as PBFT) require three rounds of message exchange: pre-preparation and submission. Consensus latency typically exceeds 1 second, making it difficult to adapt to the millisecond-level response requirements of industrial control commands (such as robotic arm movement commands and AGV scheduling signals). For example, in an automotive manufacturing line, a delay exceeding 500ms in robotic arm control commands could lead to component assembly deviations and production accidents. In cross-border financial settlements, SWIFT message format conversion latency must be ≤50ms, and the processing speed of traditional BFT protocols cannot meet the demands of high-throughput clearing and settlement.

[0042] 2. Single-layer architecture suffers from fault recovery deadlock. Most existing blockchain systems adopt a single-layer consensus architecture. When Byzantine nodes (malicious or faulty nodes) appear in the network, they lack independent fault isolation and recovery mechanisms, which can easily lead to network-wide consensus stagnation. For example, in a smart energy microgrid, if the data transmission node of the electricity meter malfunctions, the single-layer architecture cannot quickly remove the faulty node, resulting in the interruption of electricity bill settlement. When upgrading the firmware of industrial equipment clusters, malicious firmware may spread through consensus nodes, causing the paralysis of thousands of devices.

[0043] 3. Cross-platform barriers and poor protocol compatibility. Traditional blockchain systems lack a unified interface with industrial hardware protocols (such as Modbus / TCP and Profinet), preventing consensus results from being directly sent to industrial control terminals (such as PLC controllers). This necessitates protocol conversion via additional gateways, increasing system complexity and introducing risks of data tampering and latency. For instance, blockchain-based quality traceability data needs to be converted into executable instructions for industrial equipment; traditional protocol conversion methods may result in data loss or increased latency, impacting real-time production line scheduling.

[0044] 4. The contradiction between performance and safety. In traditional consensus protocols, improving fault tolerance (such as supporting more Byzantine nodes) requires sacrificing consensus performance (such as increasing message interaction rounds and reducing throughput), while pursuing high performance requires lowering fault tolerance standards, creating a performance-security triangle paradox. In industrial scenarios, fault tolerance requirements are typically ≤20%, but traditional solutions cannot dynamically adjust fault tolerance strategies according to the scenario, resulting in either insufficient performance or excessive security redundancy.

[0045] 5. High false alarm rate in anomaly detection, lack of closed-loop optimization. Existing fault detection mechanisms mostly rely on fixed thresholds, which cannot adapt to dynamic changes in industrial scenarios (such as equipment load fluctuations and network latency jitter), resulting in a high false alarm rate. For example, a temporary decrease in equipment response speed during peak production periods may be misjudged as a node failure, triggering unnecessary recovery processes; and potential faults caused by node performance degradation after long-term operation cannot be detected in a timely manner because the thresholds are not dynamically adjusted.

[0046] While existing technologies have made some improvements to address the aforementioned pain points, significant shortcomings still exist, as detailed below: To address consensus latency issues, some solutions improve speed by simplifying the consensus process (e.g., reducing message interaction rounds), but sacrifice fault tolerance and cannot withstand Byzantine attacks. Regarding fault recovery, some solutions introduce node voting and eviction mechanisms, but lack an independent guardian layer for behavior tracking and evidence collection, resulting in low fault diagnosis accuracy and long recovery times. For cross-platform compatibility, some solutions develop dedicated gateways for protocol conversion, but fail to achieve native integration of blockchain with industrial hardware, resulting in an incomplete data trust link. Regarding the performance-security trade-off, existing solutions lack a dynamic fault-tolerance balancing mechanism, unable to adjust resource allocation between the core and security layers according to real-time needs in industrial scenarios. Regarding false alarm rates, existing solutions lack a closed-loop optimization mechanism based on execution status feedback, with fixed detection thresholds that cannot adapt to dynamic changes in scenarios. Therefore, there is an urgent need for an industrial IoT collaborative management solution that balances real-time performance, security, availability, and compatibility to address the many shortcomings of existing technologies.

[0047] To address this, this embodiment provides an industrial IoT collaborative management method based on a dual-track blockchain consensus engine. This method achieves low-latency consensus, rapid fault recovery, cross-platform compatibility, and dynamic fault-tolerant balancing. In specific applications, this embodiment first collects multiple types of data from industrial IoT terminals, performs data diversion on these data types, and dynamically shards the high-priority real-time data obtained after data diversion based on the core layer. Then, the blocks within each shard are sorted, and a two-phase commit protocol is executed on the sorted blocks to output encrypted blocks. Next, the behavior data of nodes is tracked in real time based on the guardian layer, and anomaly detection is performed. When an abnormal event is detected, the abnormal evidence set is synchronized to all nodes based on the Byzantine broadcast mechanism. Finally, the encrypted blocks are verified using a hash chain, and the verified encrypted blocks are transmitted to a trusted execution environment. After verifying the hardware signature, industrial control commands are issued to the production line execution terminal. This embodiment can construct an end-to-end trusted pipeline from industrial IoT terminal data collection to production line execution terminal command issuance, meeting the core needs of scenarios such as intelligent production line control, cross-border financial settlement, and smart energy microgrid management in the industrial IoT.

[0048] The industrial IoT collaborative management method using the dual-track blockchain consensus engine in this embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be placed in the cloud or on other network servers. The industrial IoT collaborative management method of the dual-track blockchain consensus engine can be executed through terminal 102 or server 104, or it can be executed collaboratively by terminal 102 and server 104.

[0049] The terminal 102 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, IoT device, or portable wearable device. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices, etc.

[0050] Server 104 can be an independent physical server, a cloud server, or a service node in a blockchain system, where the service nodes in the blockchain system form a peer-to-peer network.

[0051] In addition, server 104 can also be a server cluster consisting of multiple physical servers, which can be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0052] Terminal 102 and server 104 can be connected via Bluetooth, USB (Universal Serial Bus) or network, etc., and this application does not impose any restrictions.

[0053] In some embodiments, such as Figure 2 As shown, an industrial IoT collaborative management method based on a dual-track blockchain consensus engine is provided. This method can be applied to terminals, such as intelligent products like computers. In this embodiment, the dual-track collaborative logic is as follows: / / Pseudocode representing key collaboration points function processTransaction(data) { if (coreLayer.commit(data)) { / / Core layer successfully committed updateLedger(data); } else { / / Trigger guardian layer intervention guardLayer.diagnose(data); if (guardLayer.recoveryStatus == SUCCESS) { restartCorePipeline(data); } } }

[0054] The method specifically includes the following steps: Step S100: Collect multiple types of data based on industrial IoT terminals, and perform data diversion on the multiple types of data.

[0055] In practical applications, this embodiment first collects various types of data from industrial IoT terminals. A routing function is then used to dynamically distribute the data, clearly defining the processing boundaries between the core layer and the guard layer. In this embodiment, the industrial IoT terminals (including production line execution terminals, sensors, smart meters, financial settlement nodes, etc.) collect various types of data, including high-priority real-time data and security monitoring data, forming a data flow vector set, i.e., corresponding to… Figure 3 The data stream in the system is as follows: High-priority real-time data can include industrial control commands, AGV scheduling signals, letter of credit verification data, electricity price commands, etc.; safety monitoring data can include node behavior logs, equipment operation status logs, firmware upgrade package verification data, etc. The data stream vector set representation in this embodiment is as follows: , is the first data in the data stream vector set, and m is the total amount of data.

[0056] Next, combined Figure 3 As shown, this embodiment can activate a dual-track engine, based on data distribution routing, to divert high-priority real-time data to the BB-Core core layer and security monitoring data to the BB-Guard guardian layer, thus achieving a dual-track parallel processing mechanism between the core layer and the guardian layer. Figure 4 As shown, the specific steps include the following: Step S101: If the latency tolerance of the data in the data stream vector set is less than or equal to the preset real-time threshold, then control the high-priority real-time data flow to the core layer. Step S102: If the latency tolerance of the data in the data flow vector set is greater than the preset real-time threshold, then control the security monitoring data flow to the guardian layer.

[0057] This embodiment uses a routing function to split the data flow vector set, controlling the data flow to either the core layer or the guardian layer. The routing function in this embodiment is represented as follows:

[0058] in, Data latency tolerance represents the maximum allowable processing latency for data. This is a real-time threshold that can be dynamically configured according to the application scenario. Indicates the core layer. This represents the guardian layer. Based on the routing function described above, if the latency tolerance of the data in the data flow vector set is less than or equal to a preset real-time threshold, then the high-priority real-time data is directed to the core layer; if the latency tolerance of the data in the data flow vector set is greater than the preset real-time threshold, then the security monitoring data is directed to the guardian layer. In this embodiment, high-priority real-time data enters the core layer, enabling low-latency consensus processing in subsequent steps; security monitoring data enters the guardian layer, enabling behavior tracking and anomaly detection in subsequent steps.

[0059] In other implementations, the real-time threshold configuration in this embodiment is determined based on the application scenario: for example, in the industrial IoT smart production line control scenario, the real-time threshold is 500ms, adapting to the millisecond-level response requirements of devices such as robotic arms and AGVs. In the cross-border financial settlement scenario, the real-time threshold is 50ms, meeting the low-latency requirements of SWIFT message format conversion. In the smart energy microgrid management scenario, the real-time threshold is 1000ms, balancing the requirements of electricity price instruction execution and fault detection. Latency tolerance can be preset through data type; for example, the latency tolerance for industrial control instructions is 300ms, the latency tolerance for financial settlement data is 20ms, the latency tolerance for node logs is 5000ms, and the latency tolerance for firmware upgrades is 10000ms.

[0060] Step S200: Based on the core layer, the high-priority real-time data obtained after data diversion is dynamically fragmented, the blocks in each fragment are sorted, the two-phase commit protocol is executed on the sorted blocks, and the encrypted blocks are output.

[0061] Furthermore, such as Figure 5 As shown, this embodiment includes the following steps when dynamically partitioning and sorting data: Step S11: Based on the core layer, receive the high-priority real-time data, merge the high-priority real-time data into the transaction pool, and dynamically shard the high-priority real-time data to obtain several block subsets; Step S12: Using a 5f+1 node architecture, the blocks within each shard are sorted based on the DAG topology.

[0062] Specifically, the core layer receives high-priority real-time data from data distribution and improves consensus throughput and real-time performance through dynamic sharding in the transaction pool and rapid sorting using 5f+1 nodes. Specifically, based on the high-priority real-time data received by the core layer, the high-priority real-time data is aggregated into the transaction pool. The high-priority real-time data is then dynamically fragmented to obtain... A subset of blocks, and satisfying load balancing: , This represents the j-th block subset in the transaction pool. Specifically, the union of all block subsets equals the original transaction pool, and in this embodiment, the data volume difference between each block subset is ≤10%, ensuring balanced processing pressure across shards. (Block subset) It can be dynamically adjusted according to the number of nodes and data throughput. For example, when the number of core layer nodes is 5f+1=11 (f=2, supporting 2 Byzantine nodes) and the data throughput is 100,000 TPS, k=5, and each shard processes 20,000 TPS of data.

[0063] Combination Figure 3 As shown, this embodiment employs a 5f+1 node architecture, using a DAG topology to quickly sort blocks within each shard. Specifically, the core layer of this embodiment uses a 5f+1 node architecture, where f is the maximum allowed number of Byzantine nodes (f≥1). In industrial scenarios, f=2 is typically configured (supporting 20% ​​fault tolerance), meaning the total number of core layer nodes is 11. The node types include a leader node (1) and follower nodes (10). The leader node is responsible for block sorting and proposal initiation, while the follower nodes are responsible for signature verification and voting. Based on this, the leader node constructs a directed acyclic graph (DAG) based on block reference relationships to perform topological sorting of blocks within each shard. The sorting function is:

[0064] Where B is the set of blocks within a certain shard, For a single block, For blocks The reference set. `topo-sort` is a topological sorting algorithm that ensures blocks are arranged in causal order, avoiding transaction conflicts. The dynamic sharding load balancing algorithm in this embodiment employs a dual-factor scheduling approach, considering both data volume and node performance: specifically, firstly, the real-time load of each node (CPU utilization, memory usage, network bandwidth utilization) is calculated; then, the matching degree between the data volume of each shard and the node performance is calculated, allocating large data volume shards to high-performance nodes; then, the load balancing is recalculated every 100ms, dynamically adjusting the shard allocation, thus ensuring that the load difference between nodes is ≤10%. This embodiment can improve throughput through sharding parallel processing; it introduces DAG topological sorting to ensure transaction causal consistency, utilizing... The number of nodes is reduced to a consensus round, resulting in a two-step message delay.

[0065] Furthermore, this embodiment executes a two-phase commit protocol on the sorted blocks, generating encrypted blocks after consensus verification to ensure data integrity and consistency. Specifically, the two phases in this embodiment include: a Prepare phase and a Commit phase. Figure 6 As shown, the two-phase commit in this embodiment includes: Step S201: Sign the nodes on the sorted blocks; Step S202: Summarize the votes. When the vote count meets the requirements, generate a consensus certificate. Step S203: Based on the consensus certificate, generate an encrypted block using a trusted encryption function.

[0066] Specifically, in the Prepare phase, the leader node sends the sorted blocks as a proposal to all follower nodes. Follower nodes then verify the proposal by signing it (including block data integrity verification and before-reference validity verification). When a node signs a proposal, it must satisfy the signature count threshold SignCount ≥ 2f + 1, where SignCount is the number of nodes that have completed valid signatures, and f is the number of Byzantine nodes (when f = 2, SignCount ≥ 5), ensuring the proposal has initial validity.

[0067] Commit Phase: The leader node summarizes the votes from the follower nodes, and when the number of votes meets the requirement... When (f=2, If the threshold is ≥9), the proposal is deemed passed, and a consensus certificate (Cert) is generated. The consensus certificate contains information such as the proposal block hash, signatures of all voting nodes, and consensus timestamps, and must satisfy certain conditions. ( (The consensus validity determination function for block b) if and only if .

[0068] Furthermore, this embodiment can generate encrypted blocks based on the consensus certificate using a trusted encryption function. Specifically, this embodiment can encrypt block data using the trusted encryption function EnCTEE based on the consensus certificate Cert, generating an encrypted block Block = EnCTEE(BlockData, Cert, Nonce), where BlockData is the original block data, Nonce is a random number (to prevent replay attacks), and EnCTEE is a hardware-level encryption function provided by the HarmonyOS execution environment (e.g., based on the AES-256 algorithm). The key is stored in a chip-level secure area (e.g., SecureEnclave), which cannot be maliciously tampered with. This embodiment's two-phase commit reduces network latency sensitivity; after block generation, hardware-level encryption is used to protect data integrity, adapting to the high reliability requirements of industrial control systems.

[0069] Furthermore, the message interaction process for the two-phase commit in this embodiment can be as follows: The Prepare phase of the two-phase commit protocol execution: The leader node sends a "proposal message" (containing block data, reference set, and leader signature) to the follower node to execute the two-phase commit protocol. After the follower node verifies the proposal, it returns a "preparation confirmation message" (containing node signature) to execute the two-phase commit protocol. For example, the message delay is ≤100ms. The Commit phase of the two-phase commit protocol execution: After the leader node collects enough "preparation confirmation messages" to execute the two-phase commit protocol, it sends a "commit message" (including consensus certificate) to all nodes. After verifying the certificate, the nodes return a "commit confirmation message" to execute the two-phase commit protocol, for example, with a message delay of ≤100ms. It can be seen that the message interaction latency of the entire two-phase commit is ≤200ms. Combined with the 100ms latency of the two-phase commit protocol executed by topology sorting, the total consensus latency is ≤0.5s, which meets the real-time requirements of industrial scenarios.

[0070] Step S300: Track the behavior data of nodes in real time based on the guardian layer and perform anomaly detection. When an abnormal event is detected, synchronize the abnormal evidence set to all nodes based on the Byzantine broadcast mechanism.

[0071] In this embodiment, the BB-Guard protection layer tracks the behavior of core layer nodes in real time, identifies Byzantine faults based on behavior vectors and anomaly detection functions, and achieves early warning of faults. Specifically, as follows... Figure 7 As shown, the anomaly detection in this embodiment includes: Step S301: Receive security monitoring data based on the cross-layer verification interface of the guardian layer, and track the behavior data of the core layer nodes in real time to construct the behavior vector of each node; Step S302: Perform anomaly detection using the anomaly detection function based on the behavior vector; Step S303: If the detection index is lower than the preset threshold, it is determined that an abnormal event has occurred at the node.

[0072] Specifically, this embodiment first receives the distributed security monitoring data from step S100 in real time through a cross-layer verification interface, while simultaneously synchronizing the operational status data of the core layer nodes (including node signature records, voting behavior, network interaction logs, and CPU / memory load data). Next, a behavior vector is constructed for each core layer node. ,in, (Security Status Indicator): Value range [0,1], calculated by weighting node signature compliance rate (SignCompliance), data transmission integrity (DataIntegrity), and consensus rule compliance (RuleCompliance), specifically as follows: =0.4×SignCompliance+0.3×DataIntegrity+0.3×RuleCompliance. Where, Signature Compliance Rate = Number of Valid Signatures / Total Number of Signatures (Valid signatures refer to signatures that conform to encryption standards and do not involve double signing); Data Transmission Integrity = Amount of Untampered Data / Total Amount of Transmitted Data (based on hash verification); Consensus Rule Compliance = Number of Votes According to Rules / Total Number of Votes. (Activity Metric): Values ​​range from [0,1], calculated by weighting node response speed (ResponseSpeed) and online time ratio (OnlineRatio). Specifically, =0.6×ResponseSpeed+0.4×OnlineRatio; Response speed = (1 - average node response latency / preset response threshold) (preset response threshold = 200ms); Online time percentage = node online time / statistical period (statistical period = 10min).

[0073] Next, this embodiment is based on behavior vectors Anomaly detection is performed using an anomaly detection function, which is: ,in, , This is the safety threshold (default value is 0.7). This is the activity threshold (default value 0.6), which can be dynamically adjusted through a closed-loop optimization mechanism. When FaultDetect(V)... i When )=true, it is determined that an abnormal event has occurred at the node (such as Byzantine fault or equipment failure). In addition, this embodiment also counts the number of abnormal nodes N_fault. When N_fault>f (when f=2, N_fault>2), that is, when the number of abnormal nodes exceeds the fault tolerance lower limit, a system warning is triggered and the fault recovery process is started.

[0074] In one implementation, the exception event types of this embodiment include: Byzantine Fault: node double signature, data tampering, malicious voting (voting that contradicts the consensus rules); Device failure: Node offline, response latency timeout (e.g., >500ms), CPU / memory load exceeding limits (e.g., >90%). Security attacks: malicious firmware injection, signing key leakage (detected through signature anomaly detection).

[0075] Furthermore, when an anomaly is detected, the evidence set is synchronized via Byzantine broadcast, and a synchronization recovery protocol is executed to quickly restore the availability of the core layer. Specifically, in this embodiment, the guardian layer collects behavioral evidence of anomaly nodes, forming an anomaly evidence set E={e1,e2,...,en}, where ei includes verifiable evidence such as the signature records, data transmission logs, fault timestamps, and hash verification results of the anomaly nodes. When an anomaly is detected, the Byzantine broadcast mechanism is activated to synchronize the anomaly evidence set to all nodes according to reliable broadcast conditions. The reliable broadcast conditions in this embodiment include: Integrity: The evidence set E received by all honest nodes is completely consistent, with no missing or tampered data; Validity: Each piece of evidence ei in evidence set E is verifiable (verified by hash signature); Timeliness: Evidence synchronization delay ≤100ms.

[0076] Finally, the synchronization recovery protocol is executed to remove abnormal nodes and reconfigure the core layer node set. Specifically, this includes: Remove abnormal nodes: Based on the abnormal evidence set E, all honest nodes unanimously vote to remove the abnormal nodes and update the core layer node set NodeSet_new = NodeSet_old - Node_fault (Node_fault is the set of abnormal nodes); Node reorganization: If the number of core layer nodes |NodeSet_new| < 5f+1 after removing abnormal nodes, select healthy nodes from the standby node pool to supplement them, ensuring that the number of nodes remains at 5f+1 (11 when f=2). Process restart: The reorganized core layer nodes reinitialize the transaction pool and sharding configuration, restart the consensus process, and restore the core layer processing capabilities.

[0077] The time complexity of the synchronous recovery protocol in this embodiment is O(n) (where n is the total number of nodes). By accelerating inter-node communication through the HarmonyOS distributed soft bus, the time taken for the entire recovery process (evidence broadcasting → node removal → reorganization → restart) can be greatly reduced, ensuring that the system downtime is reduced to the 200ms level.

[0078] Step S400: Perform hash chain verification on the encrypted block, transmit the verified encrypted block to the trusted execution environment, and after verifying the hardware signature, send the industrial control command to the production line execution terminal.

[0079] In this embodiment, during hash chain verification, the block verification pipeline calls the verification function Verify(B) to verify the encrypted block B generated in step S200. The verification function is defined as follows: Verify(B)=true, if HMAC(b_prev,Nonce)==BlockHash(B); false, otherwise; Where b_prev is the hash of the previous block of the current block, nonce is the random number generated when the block is generated, BlockHash(B) is the hash value of the current block, and HMAC is the hash message authentication code algorithm (based on SHA-256). Hash chain verification ensures that the blocks have not been tampered with and that the causal relationship between blocks is legitimate, preventing fork attacks.

[0080] Next, the verified encrypted block is passed to the HarmonyOS Trusted Execution Environment, which calls the HongMongTEE.execute_safe_instruction(block) interface for processing, specifically including: Hardware signature verification: HarmonyOS TEE verifies the consistency between the consensus certificate signature of the block and the hardware root of trust (such as SecureEnclave) to ensure the legitimacy of the block's origin; Protocol conversion: Converts blockchain-formatted instructions into protocols supported by industrial hardware (such as Modbus / TCP, Profinet) without the need for additional gateways, achieving native interoperability.

[0081] Finally, if the hardware signature verification is successful, HarmonyOS TEE will send the converted industrial control instructions to the production line execution terminals (such as robotic arms, AGVs, PLC controllers, and smart meters). After the terminal executes the instructions, it will return the execution status (success / failure, execution result data).

[0082] In one implementation, the hardware-software co-verification process of HarmonyOS TEE in this embodiment includes: Hardware layer: The root key is stored in a chip-level secure area to sign and verify the consensus certificate, preventing key leakage; System layer: Provides TEE driver interface to realize the conversion between blockchain blocks and industrial protocols; Application layer: The verification and conversion logic is encapsulated through the execute_safe_instruction interface, providing a unified call entry point for terminal execution.

[0083] Furthermore, this embodiment can also collect the operational status data of the production line execution terminal in real time through the cross-layer verification interface; and dynamically optimize or update the detection thresholds of the guardian layer (including the security status threshold Θsafe and the activity threshold Θlive) based on the feedback mechanism, thereby forming a closed-loop optimization mechanism, specifically including: Execution status collection: The cross-layer verification interface collects real-time operational status data of the production line execution terminals, including instruction execution success rate, execution latency, equipment failure rate, data transmission error rate, etc., forming a feedback dataset Feedback={f1,f2,...,fk}.

[0084] Threshold Adjustment Equation: Based on the feedback dataset, the security state threshold Θsafe and the activity threshold Θlive of the guardian layer are dynamically optimized by adjusting the equation. The adjustment equation is as follows: Θ_new = Θ_old + ΔΘ Where ΔΘ is the threshold adjustment amount, α is the adjustment coefficient (default value is 0.1), and Error is the execution error (such as instruction execution failure rate, anomaly detection false alarm rate). t represents the adjustment period (default value is 5 minutes), Θ_old represents the current threshold, and Θ_new represents the adjusted threshold. In this embodiment, the adjusted threshold must satisfy 0.5≤Θsafe≤0.9 and 0.4≤Θlive≤0.8 to avoid false alarms due to excessively high thresholds or false alarms due to excessively low thresholds. By dynamically adjusting the threshold, the false alarm rate of anomaly detection is greatly reduced every week, significantly improving the accuracy of fault detection.

[0085] The following are application examples of intelligent production line control using the Industrial Internet of Things (IIoT): Scenario Requirements: An automotive manufacturing production line contains 200+ pieces of equipment (robotic arms, AGV robots, welding equipment, and detection sensors). It is necessary to achieve real-time on-chain synchronization of robotic arm action commands and AGV scheduling signals, with a transaction confirmation delay of ≤0.5s; during equipment firmware upgrades, it is necessary to prevent the spread of malicious firmware and ensure the security of a cluster of thousands of devices; and the fault recovery time should be ≤200ms.

[0086] Implementation steps: 1. Data Acquisition and Distribution. This includes: (1) Industrial IoT terminals collect robotic arm action commands (such as bolt tightening force and welding position commands), AGV scheduling signals (such as path planning and obstacle avoidance commands), equipment firmware upgrade packages, and node behavior logs. (2) Configure the real-time threshold = 500ms, the data delay tolerance of robotic arm action commands = 300ms, and the data delay tolerance of AGV scheduling signals = 200ms. Since the data delay tolerance is less than the configured real-time threshold, it is routed to the BB-Core core layer; the data delay tolerance of the firmware upgrade package = 10000ms and the data delay tolerance of the node behavior logs = 5000ms, and it is routed to the BB-Guard guardian layer.

[0087] 2. Core layer processing, including: (1) Dynamic sharding of the transaction pool: The number of core layer nodes is 5f+1=11 (f=2), the data throughput is 50,000 TPS, the number of shards is k=5, and each shard processes 10,000 TPS of data. (2) DAG topology sorting: The leader node sorts the robotic arm and AGV instruction blocks in each shard to ensure the causal relationship of instruction execution (such as completing welding before detection). (3) Two-phase commit: The Prepare phase requires 5 nodes to sign, and the Commit phase requires 9 nodes to vote. After generating the consensus certificate, the block is generated by encryption through EnCTEE, and the total consensus delay is 0.4s.

[0088] 3. Guardian layer monitoring, including: (1) Behavior vector construction: constructing 11 core layer nodes , Including signature compliance rate and data integrity, This includes response speed and online percentage. (2) Anomaly detection: If a node's... =0.6<Θsafe=0.7 (if an invalid signature appears), it is determined to be an abnormal node. When the number of abnormal nodes =3>f=2, an early warning is triggered. (3) Fault recovery. By synchronizing abnormal evidence through Byzantine broadcast, 3 abnormal nodes are removed, 3 healthy nodes are added from the backup node pool, and the core layer node set is reorganized. The recovery time is 180ms.

[0089] 4. Block verification and execution, including: (1) Hash chain verification: The block verification pipeline verifies the consistency of the hash chain of the encrypted block to ensure that the instructions have not been tampered with; (2) HarmonyOS TEE processing: The blockchain instructions are converted into Modbus / TCP protocol, and after verifying the hardware signature, they are sent to the robotic arm and AGV terminal; (3) Terminal execution: The robotic arm completes the bolt tightening according to the instructions, and the AGV drives according to the scheduling signal, with an execution success rate of 99.9%.

[0090] 5. Feedback optimization, including: (1) collecting terminal execution status: robotic arm execution delay 200ms, AGV execution delay 150ms, execution failure rate 0.1%; (2) threshold optimization: based on the adjustment equation, Error=0.1%, α=0.1, t=5min, ΔΘ=0.1×(0.1% / 5)=0.002, Θsafe is adjusted from 0.7 to 0.702 to improve detection accuracy.

[0091] Implementation results: Transaction confirmation delay of 0.4s meets the real-time requirements of the production line; fault recovery time of 180ms avoids production line downtime; firmware upgrade packages are verified by the protection layer to prevent the spread of malicious firmware; the false alarm rate of anomaly detection is reduced by 17% per week, and the equipment malfunction rate is reduced to below 0.1%.

[0092] In summary, this embodiment can achieve low-latency consensus, rapid fault recovery, cross-platform compatibility, and dynamic fault tolerance balance through a dual-track collaborative architecture of the core layer and the guardian layer, combined with the hardware and software collaborative verification capabilities of the trusted execution environment. It can build an end-to-end trusted pipeline from industrial IoT terminal data collection to production line execution terminal command issuance, meeting the core needs of scenarios such as intelligent production line control, cross-border financial settlement, and smart energy microgrid management in the industrial IoT.

[0093] Based on the above embodiments, the present invention also provides an industrial IoT collaborative management system with a dual-track blockchain consensus engine, the system being used to implement the steps in the above method embodiments. Figure 8 As shown, the system includes: a data distribution module 10, a dynamic sharding and sorting module 20, an anomaly detection module 30, and a verification and execution module 40. Specifically, the data distribution module 10 is used to collect multiple types of data based on industrial IoT terminals and perform data distribution on these multiple types of data. The dynamic sharding and sorting module 20 is used to dynamically shard the high-priority real-time data obtained after data distribution based on the core layer, sort the blocks within each shard, execute a two-phase commit protocol on the sorted blocks, and output encrypted blocks. The anomaly detection module 30 is used to track node behavior data in real time based on the guardian layer and perform anomaly detection. When an abnormal event is detected, it synchronizes the abnormal evidence set to all nodes based on the Byzantine broadcast mechanism. The verification and execution module 40 is used to perform hash chain verification on the encrypted blocks, transmit the verified encrypted blocks to the trusted execution environment, and after verifying the hardware signature, issue industrial control commands to the production line execution terminal.

[0094] In one implementation, the data splitting module 10 includes: The data acquisition unit is used to collect various types of data based on industrial IoT terminals and form a data stream vector set. The security monitoring data diversion unit is used to control the flow of high-priority real-time data to the core layer if the latency tolerance of the data in the data flow vector set is less than or equal to the preset real-time threshold. The high-priority real-time data diversion unit is used to control the flow of security monitoring data to the guardian layer if the latency tolerance of the data in the data flow vector set is greater than the preset real-time threshold.

[0095] In one implementation, the dynamic sharding and sorting module 20 includes: The dynamic sharding unit is used to receive the high-priority real-time data based on the core layer, merge the high-priority real-time data into the transaction pool, and dynamically shard the high-priority real-time data to obtain several block subsets. The block sorting unit is used to sort the blocks within each shard using a 5f+1 node architecture and a DAG topology.

[0096] In one implementation, the dynamic sharding and sorting module 20 further includes: The node signing unit is used to sign the sorted blocks. The consensus certificate generation unit is used to summarize the vote count and generate a consensus certificate when the vote count meets the requirements. A block encryption unit is used to generate encrypted blocks based on the consensus certificate using a trusted encryption function.

[0097] In one implementation, the anomaly detection module 30 includes: The behavior vector construction unit is used to receive security monitoring data based on the cross-layer verification interface of the guardian layer, and to track the behavior data of the core layer nodes in real time to construct the behavior vector of each node. An anomaly detection unit is used to perform anomaly detection based on the behavior vector using an anomaly detection function; An abnormal event determination unit is used to determine that an abnormal event has occurred at a node if the detected index is lower than a preset threshold.

[0098] The synchronization node unit is used to initiate the Byzantine broadcast mechanism when an abnormal event is detected, and to synchronize the abnormal evidence set to all nodes according to the reliable broadcast conditions; The synchronization recovery unit is used to execute the synchronization recovery protocol, remove abnormal nodes, and reconfigure the core layer node set.

[0099] In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 9As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements an industrial IoT collaborative management method based on a dual-track blockchain consensus engine. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0100] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0101] In some embodiments, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps: Based on the collection of multiple types of data by industrial IoT terminals, the multiple types of data are sorted. Based on the core layer, the high-priority real-time data obtained after data diversion is dynamically fragmented, the blocks within each fragment are sorted, a two-phase commit protocol is executed on the sorted blocks, and encrypted blocks are output. Based on the real-time tracking of node behavior data by the guardian layer and anomaly detection, when an abnormal event is detected, the abnormal evidence set is synchronized to all nodes based on the Byzantine broadcast mechanism; The encrypted block is verified by hash chain, the verified encrypted block is passed to the trusted execution environment, and after verifying the hardware signature, the industrial control command is sent to the production line execution terminal.

[0102] In one implementation, multiple types of data are collected based on industrial IoT terminals, and the multiple types of data are then sorted, including: Data stream vector sets are formed by collecting various types of data based on industrial IoT terminals; The data flow vector set is split by a routing function to control the data flow to the core layer or the guardian layer.

[0103] In one implementation, a routing function is used to split the data flow vector set and control the data flow to the core layer or the guardian layer, including: If the latency tolerance of the data in the data stream vector set is less than or equal to the preset real-time threshold, then control the flow of high-priority real-time data to the core layer. If the latency tolerance of the data in the data stream vector set is greater than the preset real-time threshold, then the security monitoring data flow is controlled to the guardian layer.

[0104] In one implementation, the routing function is represented as:

[0105] in, Data latency tolerance represents the maximum allowable processing latency for data. This is a real-time threshold that can be dynamically configured according to the application scenario. Indicates the core layer. This indicates the protection layer.

[0106] In one implementation, the high-priority real-time data obtained after data diversion is dynamically fragmented based on the core layer, and the blocks within each fragment are sorted, including: Based on the core layer receiving the high-priority real-time data, the high-priority real-time data is merged into the transaction pool, and the high-priority real-time data is dynamically sharded to obtain several block subsets. A 5f+1 node architecture is adopted, and the blocks within each shard are sorted based on the DAG topology.

[0107] In one implementation, a two-phase commit protocol is executed on the sorted blocks to output encrypted blocks, including: Nodes sign off on the sorted blocks; The vote count is tallied, and a consensus certificate is generated when the required number of votes is met. Based on the consensus certificate, encrypted blocks are generated using a trusted encryption function.

[0108] In one implementation, the daemon layer tracks node behavior data in real time and performs anomaly detection, including: The cross-layer verification interface based on the guardian layer receives security monitoring data and tracks the behavior data of the core layer nodes in real time, constructing a behavior vector for each node; Anomaly detection is performed using an anomaly detection function based on the aforementioned behavior vector; If the detected index is lower than the preset threshold, the node is determined to have experienced an abnormal event.

[0109] In one implementation, based on the real-time tracking of node behavior data by the guardian layer and the anomaly detection, it also includes: If the number of abnormal nodes exceeds the fault tolerance limit, an early warning will be triggered.

[0110] In one implementation, when an anomalous event is detected, the set of anomalous evidence is synchronized to all nodes based on a Byzantine broadcast mechanism, including: When an abnormal event is detected, the Byzantine broadcast mechanism is activated to synchronize the abnormal evidence set to all nodes according to the reliable broadcast conditions; Execute the synchronization recovery protocol, remove abnormal nodes, and reconfigure the core layer node set.

[0111] In one implementation, the method further includes: The cross-layer verification interface based on the guardian layer collects the operating status data of the production line execution terminal in real time; The detection thresholds of the guardian layer are dynamically optimized or updated based on the feedback mechanism.

[0112] It should be noted that the user information (including but not limited to user device function information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0113] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0114] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0115] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An industrial IoT collaborative management method with a dual-track blockchain consensus engine, characterized in that, The method includes: Based on the collection of multiple types of data by industrial IoT terminals, the multiple types of data are sorted. Based on the core layer, the high-priority real-time data obtained after data diversion is dynamically fragmented, the blocks within each fragment are sorted, a two-phase commit protocol is executed on the sorted blocks, and encrypted blocks are output. Based on the real-time tracking of node behavior data by the guardian layer and anomaly detection, when an abnormal event is detected, the abnormal evidence set is synchronized to all nodes based on the Byzantine broadcast mechanism; The encrypted block is verified by hash chain, the verified encrypted block is passed to the trusted execution environment, and after verifying the hardware signature, the industrial control command is sent to the production line execution terminal.

2. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 1, characterized in that, Based on the collection of multiple types of data by industrial IoT terminals, the data is then sorted, including: Data stream vector sets are formed by collecting various types of data based on industrial IoT terminals; The data flow vector set is split by a routing function to control the data flow to the core layer or the guardian layer.

3. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 2, characterized in that, The data flow vector set is split into different data streams using routing functions to control the data flow to the core layer or the guardian layer, including: If the latency tolerance of the data in the data stream vector set is less than or equal to the preset real-time threshold, then control the flow of high-priority real-time data to the core layer. If the latency tolerance of the data in the data stream vector set is greater than the preset real-time threshold, then the security monitoring data flow is controlled to the guardian layer.

4. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 3, characterized in that, The routing function is represented as follows: in, Data latency tolerance represents the maximum allowable processing latency for data. This is a real-time threshold that can be dynamically configured according to the application scenario. Indicates the core layer. This indicates the protection layer.

5. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 4, characterized in that, The core layer dynamically segments the high-priority real-time data obtained after data diversion, and sorts the blocks within each segment, including: Based on the core layer receiving the high-priority real-time data, the high-priority real-time data is merged into the transaction pool, and the high-priority real-time data is dynamically sharded to obtain several block subsets. A 5f+1 node architecture is adopted, and the blocks within each shard are sorted based on the DAG topology.

6. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 5, characterized in that, Perform a two-phase commit protocol on the sorted blocks to output encrypted blocks, including: Nodes sign off on the sorted blocks; The vote count is tallied, and a consensus certificate is generated when the required number of votes is met. Based on the consensus certificate, encrypted blocks are generated using a trusted encryption function.

7. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 6, characterized in that, Based on the guardian layer, real-time tracking of node behavior data is performed, and anomaly detection is carried out, including: The cross-layer verification interface based on the guardian layer receives security monitoring data and tracks the behavior data of the core layer nodes in real time, constructing a behavior vector for each node; Anomaly detection is performed using an anomaly detection function based on the aforementioned behavior vector; If the detected index is lower than the preset threshold, the node is determined to have experienced an abnormal event.

8. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 7, characterized in that, Based on the real-time tracking of node behavior data by the guardian layer and the anomaly detection, it also includes: If the number of abnormal nodes exceeds the fault tolerance limit, an early warning will be triggered.

9. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 8, characterized in that, When an anomalous event is detected, the set of anomalous evidence is synchronized to all nodes based on the Byzantine broadcast mechanism, including: When an abnormal event is detected, the Byzantine broadcast mechanism is activated to synchronize the abnormal evidence set to all nodes according to the reliable broadcast conditions; Execute the synchronization recovery protocol, remove abnormal nodes, and reconfigure the core layer node set.

10. The industrial IoT collaborative management method based on a dual-track blockchain consensus engine according to claim 9, characterized in that, The method further includes: The cross-layer verification interface based on the guardian layer collects the operating status data of the production line execution terminal in real time; The detection threshold of the guardian layer is dynamically optimized or updated based on the feedback mechanism.

11. An industrial IoT collaborative management system with a dual-track blockchain consensus engine, characterized in that, The system is used to implement the steps of the industrial IoT collaborative management method of the dual-track blockchain consensus engine according to any one of claims 1-10, the system comprising: The data splitting module is used to collect multiple types of data based on industrial IoT terminals and to split the multiple types of data. The dynamic sharding and sorting module is used to dynamically shard the high-priority real-time data obtained by data diversion based on the core layer, sort the blocks within each shard, execute the two-phase commit protocol on the sorted blocks, and output encrypted blocks. The anomaly detection module is used to track node behavior data in real time based on the guardian layer and perform anomaly detection. When an abnormal event is detected, the abnormal evidence set is synchronized to all nodes based on the Byzantine broadcast mechanism. The verification and execution module is used to perform hash chain verification on the encrypted block, pass the verified encrypted block into the trusted execution environment, and after verifying the hardware signature, send the industrial control command to the production line execution terminal.

12. The industrial IoT collaborative management system with a dual-track blockchain consensus engine according to claim 11, characterized in that, The data splitting module includes: The data acquisition unit is used to collect various types of data based on industrial IoT terminals and form a data stream vector set. The security monitoring data diversion unit is used to control the flow of high-priority real-time data to the core layer if the latency tolerance of the data in the data flow vector set is less than or equal to the preset real-time threshold. The high-priority real-time data diversion unit is used to control the flow of security monitoring data to the guardian layer if the latency tolerance of the data in the data flow vector set is greater than the preset real-time threshold.

13. The industrial IoT collaborative management system with a dual-track blockchain consensus engine according to claim 12, characterized in that, The dynamic sharding and sorting module includes: The dynamic sharding unit is used to receive the high-priority real-time data based on the core layer, merge the high-priority real-time data into the transaction pool, and dynamically shard the high-priority real-time data to obtain several block subsets. The block sorting unit is used to sort the blocks within each shard using a 5f+1 node architecture and a DAG topology.

14. The industrial IoT collaborative management system with a dual-track blockchain consensus engine according to claim 13, characterized in that, The dynamic sharding and sorting module also includes: The node signing unit is used to sign the sorted blocks. The consensus certificate generation unit is used to summarize the vote count and generate a consensus certificate when the vote count meets the requirements. A block encryption unit is used to generate encrypted blocks based on the consensus certificate using a trusted encryption function.

15. The industrial IoT collaborative management system with a dual-track blockchain consensus engine according to claim 14, characterized in that, The anomaly detection module includes: The behavior vector construction unit is used to receive security monitoring data based on the cross-layer verification interface of the guardian layer, and to track the behavior data of the core layer nodes in real time to construct the behavior vector of each node. An anomaly detection unit is used to perform anomaly detection based on the behavior vector using an anomaly detection function; An abnormal event determination unit is used to determine that an abnormal event has occurred at a node if the detected index is lower than a preset threshold. The synchronization node unit is used to initiate the Byzantine broadcast mechanism when an abnormal event is detected, and to synchronize the abnormal evidence set to all nodes according to the reliable broadcast conditions; The synchronization recovery unit is used to execute the synchronization recovery protocol, remove abnormal nodes, and reconfigure the core layer node set.

16. A computer device, characterized in that, The computer device includes a memory, a processor, and an industrial IoT collaborative management program with a dual-track blockchain consensus engine stored in the memory and executable on the processor. When the processor executes the industrial IoT collaborative management program with the dual-track blockchain consensus engine, it implements the steps of the industrial IoT collaborative management method with the dual-track blockchain consensus engine as described in any one of claims 1-10.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an industrial IoT collaborative management program with a dual-track blockchain consensus engine, and the industrial IoT collaborative management program with the dual-track blockchain consensus engine implements the steps of the industrial IoT collaborative management method with a dual-track blockchain consensus engine as described in any one of claims 1-10 on the computer-readable storage medium.

Images