Internet of Things cross-network data monitoring method, device, equipment and medium

Abstract

The invention relates to the technical field of Internet of Things, and discloses an Internet of Things cross-network data monitoring method, device and equipment and a medium, and provides a unified basis for cross-network log consistency verification through log standardization preprocessing. The consensus and the Hash uplink evidence storage are verified by relying on multiple nodes of the alliance chain, so that the defect that a traditional centralized log is easy to tamper and lose is thoroughly avoided, and the authenticity and the non-tampering property of the cross-network data exchange log are ensured; meanwhile, by means of an on-chain and off-chain regular comparison alarm mechanism, credible monitoring and abnormal tracing of logs in a cross-multi-network environment are achieved, and the requirements for safety monitoring and responsibility tracing in a complex Internet of Things scene are met.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to IoT cross-network data monitoring methods, devices, equipment, and media. Background Technology

[0002] Cross-network data exchange in the Internet of Things (IoT) is a crucial link in achieving device interconnection and system collaboration. Existing technologies have formed a basic support system. For example, cross-network data transmission completes protocol conversion between different networks through gateway devices, and relies on standard protocols such as MQTT, CoAP, and NB-IoT to ensure data interoperability. Log management mostly adopts a centralized architecture, collecting information such as device data exchange logs, transmission status, and event alarms for basic operation and maintenance and fault diagnosis. Some solutions attempt to introduce blockchain technology to write log summaries or event hashes into a distributed ledger in order to improve data credibility. However, auditing and traceability capabilities are still limited to a single network or organization, lacking a unified and trustworthy mechanism across multiple network environments.

[0003] However, existing solutions suffer from the core technical problem of insufficient security in centralized log storage. More specifically, traditional centralized logs are easily tampered with or lost, which directly leads to the inability to verify the authenticity of cross-network data exchanges and makes it difficult to meet the needs of reliable log monitoring and accountability in complex IoT environments. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for cross-network data monitoring in the Internet of Things (IoT) to solve the technical problem that existing cross-network log monitoring methods cannot meet the requirements of reliability and traceability.

[0005] Firstly, it provides a method for cross-network data monitoring in the Internet of Things, including: The data exchange logs across IoT networks are collected and standardized preprocessed to obtain structured log data; The structured log data is stored off-chain, and the hash value and metadata of the structured log data are extracted and encapsulated to form log transaction data; The log transaction data is broadcast to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain the consensus result. If the consensus result is that a consensus has been reached, the log transaction data will be packaged into a new block through the preset node of the consortium blockchain, and the log transaction data will be stored on the blockchain for evidence. Periodically extract notarized log transaction data from the blockchain, compare and verify it with off-chain structured log data, and trigger an anomaly alarm when the verification results are inconsistent.

[0006] Secondly, it provides an IoT cross-network data monitoring device, including: The data acquisition module is used to collect and standardize the logs of cross-network data exchange in the Internet of Things to obtain structured log data. The extraction module is used to store the structured log data off-chain, and extract and encapsulate the hash value and metadata of the structured log data to form log transaction data; The consensus module is used to broadcast the log transaction data to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain the consensus result. The on-chain module is used to package the log transaction data into a new block through the preset node of the consortium blockchain and perform on-chain storage of the log transaction data if the consensus result is that a consensus has been reached. The verification module is used to periodically extract the notarized log transaction data from the blockchain, compare and verify it with the off-chain structured log data, and trigger an anomaly alarm when the verification results are inconsistent.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described IoT cross-network data monitoring method.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described IoT cross-network data monitoring method.

[0009] The beneficial effects of this invention compared with existing technologies are as follows: This invention provides a unified foundation for cross-network log consistency verification through standardized log preprocessing; and by relying on consortium blockchain multi-node verification consensus and hash on-chain notarization, it completely avoids the defects of traditional centralized logs being easily tampered with and lost, ensuring the authenticity and immutability of cross-network data exchange logs; at the same time, the on-chain and off-chain periodic comparison and alarm mechanism realizes reliable monitoring and anomaly tracing of logs in multi-network environments, meeting the security monitoring and responsibility tracing needs in complex IoT scenarios.

[0010] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of the present invention more obvious and understandable, preferred embodiments are described in detail below. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of an application environment for an IoT cross-network data monitoring method according to an embodiment of the present invention; Figure 2This is a flowchart illustrating an IoT cross-network data monitoring method according to an embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S10; Figure 4 yes Figure 2 A schematic diagram of a specific implementation method for step S20; Figure 5 yes Figure 2 Another flowchart illustrating a specific implementation of step S30; Figure 6 yes Figure 2 A schematic diagram of a specific implementation of step S40; Figure 7 yes Figure 2 A schematic diagram of a specific implementation method for step S50; Figure 8 This is a schematic diagram of the structure of an IoT cross-network data monitoring device according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 10 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0013] It should be understood that, when used in this specification and the appended claims, the terms “comprising” and “including” indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0014] It should also 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.

[0015] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] Please see Figure 1 and Figure 2 , Figure 1 This diagram illustrates an application scenario of the IoT cross-network data monitoring method provided in this invention. Users can send log monitoring configuration or audit query requests to the server via a client. The client collects and standardizes IoT cross-network data exchange logs to obtain structured log data. The structured log data is stored off-chain, and its hash value and metadata are extracted and encapsulated to form log transaction data. The log transaction data is broadcast to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain a consensus result. If the consensus result indicates consensus has been reached, the log transaction data is packaged into a new block through a preset node of the consortium blockchain, and the log transaction data is stored on-chain. The stored log transaction data is periodically extracted from the blockchain and compared with the off-chain structured log data. An anomaly alarm is triggered when the verification results are inconsistent. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a separate server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0017] Please see Figure 2 As shown, Figure 2 This is a schematic flowchart illustrating an IoT cross-network data monitoring method provided in an embodiment of the present invention. The IoT cross-network data monitoring method includes the following steps: S10: Collect and standardize the logs of cross-network data exchange in the Internet of Things to obtain structured log data.

[0018] The Internet of Things (IoT) refers to the ability to collect real-time information about any object or process that needs to be monitored, connected, or interacted with through various information sensing devices, enabling interconnection between objects and between objects and people. The IoT platform in this embodiment supports multiple cross-network communication protocols such as MQTT, CoAP, NB-IoT, and LTE-M, possessing unified data reception, parsing, and storage capabilities, and is compatible with multi-protocol data. Cross-Network Data Exchange refers to data transmission between different IoT networks (such as enterprise intranets, carrier NB networks, edge computing networks, etc.), which typically requires gateway devices to complete protocol conversion, security filtering, and authentication.

[0019] For step S10, multi-protocol fusion collection ensures that no cross-network logs are missed, and standardized preprocessing achieves a unified log data structure. This provides a standardized data foundation for subsequent hash value calculation and metadata extraction, and avoids subsequent verification and evidence storage failures caused by format chaos, thereby improving the compatibility and efficiency of cross-network log management.

[0020] In some embodiments of the present invention, such as Figure 3 As shown, a specific data collection and preprocessing scheme is provided. In S10, the data collection and standardized preprocessing of IoT cross-network data exchange logs are performed to obtain structured log data, which specifically includes the following steps S11-S16.

[0021] S11: Collect log data from IoT devices across the network in real time, and store the collected log data in a preset database table, wherein the database table includes a device identifier and a payload field for recording data content.

[0022] In practice, IoT devices report collected log data to the IoT platform in real time via cross-network communication protocols such as MQTT, CoAP, NB-IoT, and LTE-M. The platform stores the collected log data in a pre-defined database table named devicesvc.device_data, with the following JSON format: { "id": 1, "trace_id": "abc123xyz789", "device_id": "device001", "product_id": 1001, "tenant_id": "tenantA", "imei": "123456789012345", "payload": { Temperature: 25.6 "humidity": 60, "status": "normal" }, "create_time": 1699352096000, "created_at": "2024-07-08T12:34:56.000Z" } The database table structure includes key fields such as device identifier (device_id), product identifier (product_id), tenant identifier (tenant_id), device IMEI (imei), data content (payload), and timestamp (create_time). The payload field stores the structured business data reported by the device, providing a data foundation for subsequent hash calculations and blockchain notarization. The timestamp identifies the precise time of data generation or transmission, recording the order of data exchange, and together with the blockchain timestamp, constitutes a full lifecycle identifier for data behavior. Blockchain is a decentralized, immutable, distributed ledger technology that uses cryptographic algorithms to protect data integrity and achieve multi-node consensus. In this embodiment, it is used to store IoT data exchange logs and metadata, ensuring the reliability and traceability of the log data.

[0023] For step S11, multi-protocol collection ensures that device logs across different networks can be effectively accessed, avoiding data omissions; the logs are uniformly stored in a database table containing device identifier and payload fields, which not only binds the logs to specific devices, providing a basis for subsequent traceability by device dimension, but also retains complete business data through the payload field, ensuring the integrity and traceability of subsequent data processing, and solving the problems of data dispersion and weak device correlation in traditional collection methods.

[0024] S12: Parse the log data into JSON format to obtain the parsed log data.

[0025] Understandably, the IoT platform invokes a dedicated data parsing module to parse the raw text-formatted log data into a unified JSON structured format, targeting the payload field and other core fields of the log data in the database table. This ensures that the parsed log data fields are clear, the hierarchy is well-defined, and it meets the requirements of subsequent format validation and key field extraction. By uniformly parsing to JSON format, the limitations of traditional log formats—diverse and incompatible—are overcome. This provides logs generated by different networks and devices with a unified data structure, facilitating automated processing such as format validation and key field extraction in subsequent steps. It also reduces processing errors caused by format differences and improves the operability and compatibility of log data.

[0026] S13: Perform format validation on the payload field of the parsed log data to determine whether the payload field conforms to the predefined JSON template and field specifications. If it does not conform, mark it as abnormal data.

[0027] Step S13: For the parsed JSON format log data, focus on performing structured validation on the payload fields. The predefined JSON template and field specifications include the core fields that the payload must contain (such as sensor type, data value, unit, etc.), field data types (such as numeric type, character type), and format requirements. If the payload fields are missing core fields, have incorrect data types, or do not conform to the specifications, the log data is marked as abnormal data to prevent it from entering the subsequent processing flow.

[0028] Step S13 performs format validation on the payload fields and marks abnormal data in advance. This can filter out non-compliant data in the early stages of log processing, prevent invalid data from occupying subsequent computing and storage resources, and ensure that the log data fields entering subsequent steps are complete and have valid formats. This provides a high-quality data foundation for operations such as key field extraction and hash calculation, and reduces the error rate of subsequent processes.

[0029] S14: Extract preset key fields from the parsed log data.

[0030] Extract preset key fields from the JSON format log data that has passed format validation. The preset key fields can be sensor type (such as temperature, humidity), data value (such as 25.6, 60), data unit (such as degrees Celsius, percentage), device identifier, timestamp (corresponding to create_time), etc. The extracted data will be used for subsequent invalid data filtering, hash calculation and metadata integration.

[0031] For step S14, by extracting key fields, focusing on the core information in the log data, and eliminating redundant fields, the computational load of subsequent data processing such as hash calculation and metadata encapsulation is reduced, improving processing efficiency. It also makes the metadata stored on the chain more accurate, which facilitates the rapid location of key information during subsequent auditing and tracing. This solves the technical problems of redundant log information and difficulty in extracting key information in traditional logs.

[0032] S15: Filter the abnormal data and the invalid data after the key fields are extracted.

[0033] Understandably, the filtering targets include the data with abnormal format marked in step S13, as well as invalid data that appears after the key fields are extracted. Invalid data refers to records that are missing key fields, have values ​​that are outside the reasonable range, or have abnormal formats. For example, logs that are missing device identifiers, logs with sensor values ​​that are far beyond the normal operating range, and logs with incorrect key field formats (such as timestamps that are not in numeric format) will all be filtered out.

[0034] For step S15, double filtering is used to further improve the quality of log data, ensuring that all records entering the structured log data are valid data with legal format, complete core fields, and reasonable data. This avoids invalid data interfering with subsequent off-chain storage, on-chain evidence storage, and audit analysis, while reducing off-chain storage resource consumption and improving the processing efficiency and accuracy of subsequent processes.

[0035] S16: The filtered log data forms the structured log data.

[0036] After the collection, parsing, verification, extraction and filtering operations in steps S11-S15, the filtered log data forms structured log data. This data has the characteristics of unified format (JSON format), complete fields and valid data, and can be directly used for off-chain storage, hash value calculation and metadata extraction in step S20.

[0037] S20: Store the structured log data off-chain, and extract and encapsulate the hash value and metadata of the structured log data to form log transaction data.

[0038] Understandably, "off-chain" refers to entities outside the blockchain, including but not limited to local disks, object storage, or log platforms.

[0039] By storing structured log data, i.e. raw log data, in an off-chain system, the cost and efficiency issues caused by directly storing large amounts of raw data on the blockchain are avoided. At the same time, a hash digest is calculated on the structured log data, the corresponding metadata is extracted from a pre-set database table, and the hash digest and metadata are integrated and signed with the private key of the sending node, and then packaged into log transaction data according to the blockchain transaction format.

[0040] By adopting a model that combines off-chain storage of raw data with on-chain storage of hashes and metadata, the problem of high storage costs and low query efficiency in traditional blockchains is solved. The hash digest ensures the integrity of the raw data, while the data encapsulation guarantees the authenticity of the log transaction data and on-chain compatibility, providing a reliable data sample for subsequent consortium blockchain node verification and consensus, thus balancing storage efficiency and data security.

[0041] In some embodiments of the present invention, such as Figure 4 As shown, a specific extraction and encapsulation scheme is provided. In S20, the structured log data is stored off-chain, and the hash value and metadata of the structured log data are extracted and encapsulated to form log transaction data. Specifically, it includes the following steps S21-S25.

[0042] S21: Store the structured log data off-chain.

[0043] The structured log data (i.e. the complete original log data) generated in step S16 is stored in the off-chain system. During the storage process, the association between the structured log data and the device identifier and timestamp is preserved to ensure that the data can be accurately retrieved through the device identifier or time range during subsequent S50 verification.

[0044] For step S21, large-capacity structured log data is stored off-chain to avoid occupying the storage resources of blockchain nodes, significantly reducing the operating costs of the blockchain, while preserving the integrity of the original data. The design of the association relationship during off-chain storage facilitates the rapid retrieval of the original data during subsequent periodic verification and anomaly tracing, solving the problem of low efficiency caused by the full on-chain storage of traditional blockchain solutions.

[0045] S22: The structured log data is hashed using the SHA-256 hash algorithm to generate a unique log hash digest.

[0046] The structured log data generated in step S16 is standardized to ensure that the field order and format are consistent. Then, the SHA-256 hash algorithm interface is called to perform hash calculation and generate a unique log hash digest. The log hash digest represents the hash value for verifying the uniqueness and integrity of the log content. This value can be used to verify whether the original log data has been tampered with.

[0047] The irreversibility and uniqueness of the SHA-256 hash algorithm ensure that each piece of structured log data corresponds to a unique log hash digest. If the original data is tampered with, the hash digest will change, thereby achieving accurate verification of log integrity. At the same time, the hash digest is only a fixed-length string, which greatly reduces the amount of data stored on the chain and improves the efficiency of on-chain data transmission and query.

[0048] S23: Extract the metadata corresponding to the structured log data from the database table, and integrate the log hash digest and the metadata into a data set.

[0049] Extract metadata corresponding to the current structured log data from the preset database table that stores log data in S11, namely the devicesvc.device_data table. This metadata includes device identifier (device_id), product identifier (product_id), tenant identifier (tenant_id), device IMEI (imei), data content (payload), and timestamp (create_time). After extraction, integrate the log hash digest and the above metadata into a data set in a preset order to ensure that the log hash digest and device identifier correspond one-to-one in each data set.

[0050] The extraction and integration of metadata binds log hash digests with key information such as device identity, time, and product ownership. During subsequent auditing or tracing, the corresponding device and time of the log can be quickly located through metadata, solving the problem that in traditional data interaction, only hash values ​​exist and cannot be associated with actual devices. The structured integration of the data set provides a unified data unit for subsequent private key signing and transaction encapsulation, improving the processing efficiency of subsequent steps.

[0051] S24: Obtain the private key of the sending node, and use an asymmetric encryption algorithm to digitally sign the data set to generate signature information.

[0052] For step S24, the private key of the IoT platform or log sending node is obtained, i.e., the private key in the asymmetric encryption system. An asymmetric encryption algorithm is used to digitally sign the data set formed in step S23, generating unique signature information. This signature information can be verified using the public key of the sending node to prove that the data set originates from a legitimate node and has not been tampered with. By signing the data set with the private key using an asymmetric encryption algorithm, an identity identifier is added, achieving tamper-proof security and improving the trustworthiness of the log transaction data.

[0053] S25: The data set and the corresponding signature information are encapsulated according to the preset transaction structure specifications to form the log transaction data.

[0054] The preset transaction structure specification corresponds to the transaction format requirements defined by the consortium blockchain of the blockchain system. The data set in step S23 and the signature information in step S24 are combined according to this specification to ensure that the encapsulated log transaction data contains three core modules: hash digest, metadata, and signature information. The field format and order meet the parsing requirements of the consortium blockchain node and can be normally received and verified by the node.

[0055] Data is packaged according to blockchain transaction specifications to ensure that log transaction data can be recognized and parsed by all consensus nodes of the consortium blockchain, avoiding transaction failures due to format incompatibility; at the same time, the packaged transaction data has a complete structure, including data content and identity verification information, providing complete data basis for subsequent independent verification by nodes and ensuring the smooth progress of the consensus process.

[0056] It is understood that this embodiment stores the hash digest of each log entry in blocks according to device identifiers and achieves tamper-proof and immutable evidence storage on the blockchain. This allows the platform to quickly locate and verify the source and integrity of any device log. In practice, users can use the one-click traceability function to input the device identifier or log identifier to query the corresponding block and off-chain log content in real time. This enables full lifecycle tracking and responsibility confirmation of device logs across network environments, effectively improving the transparency and security of the IoT system.

[0057] S30: Broadcast the log transaction data to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, collect the verification results of all consensus nodes to obtain the consensus result.

[0058] More specifically, this embodiment employs a multi-party consensus mechanism to confirm the validity and legality of log transaction data. Multi-party consensus refers to a mechanism in a blockchain where multiple participating nodes (such as members of a consortium blockchain) reach a consensus on a particular transaction or data, such as RAFT, PBFT, and PoA, to ensure data consistency and trust in a distributed environment. Preferably, this embodiment uses the PBFT multi-node consensus mechanism. The PBFT algorithm ensures that even with a small number of illegitimate nodes, a correct consensus can still be reached, addressing the lack of cross-organizational multi-node consensus in existing solutions and improving the credibility of cross-network log evidence storage.

[0059] For step S30, distributed verification and recognition of log transaction data are achieved through a process of node broadcasting, independent verification, and multi-node consensus, avoiding the problem of insufficient credibility caused by single-node decision-making.

[0060] In some embodiments of the present invention, such as Figure 5 As shown, a specific consensus verification scheme is provided. In S30, the log transaction data is broadcast to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain the consensus result. Specifically, the scheme includes the following steps S31-S37.

[0061] S31: Call the blockchain's communication interface to submit the log transaction data to the access node of the consortium blockchain network.

[0062] In this embodiment, the communication interface of the blockchain is a REST API. The IoT platform sends the log transaction data generated in step S25 to the access node of the consortium blockchain network by calling the REST API. The access node is responsible for receiving the transaction data submitted from outside, in preparation for subsequent broadcasting to all consensus nodes.

[0063] For step S31, data is submitted through a standardized REST API to ensure communication compatibility between the IoT platform and the consortium blockchain network, avoiding data transmission failures due to inconsistent interfaces. As a data entry point, the access node can perform preliminary filtering on the submitted log transaction data, such as whether the format meets basic requirements, reducing invalid data entering the consensus process and improving the consensus efficiency of the consortium blockchain.

[0064] S32: The access node broadcasts the log transaction data to all consensus nodes of the consortium blockchain, wherein the consensus nodes include master nodes and replica nodes.

[0065] After receiving log transaction data, the access node can broadcast the log transaction data to all consensus nodes of the consortium blockchain through the P2P network mechanism built into the blockchain platform. The consensus nodes are divided into primary / leader nodes, which are responsible for initiating the consensus process, and replica / backup nodes, which are responsible for participating in verification and voting.

[0066] Among them, P2P network broadcasting can ensure that all consensus nodes receive log transaction data synchronously, avoiding consensus inconsistencies caused by data transmission delays or omissions; the clear division of labor between master nodes and replica nodes provides a role basis for the subsequent PBFT consensus pre-preparation-commit phase, ensuring the orderly progress of the consensus process and improving the efficiency and accuracy of distributed verification.

[0067] S33: After receiving the log transaction data, each consensus node performs independent verification based on preset verification rules; if the consensus node passes the verification, it generates a verification pass result, signs it, and broadcasts the verification pass result to all other consensus nodes; if the verification fails, it discards the log transaction data and sends back verification failure information.

[0068] In practice, the preset verification rules include: verifying the digital signature in the transaction using the sender's public key to verify the authenticity of the source; verifying whether the log data structure conforms to the JSON format specification defined by the smart contract and the validity of the timestamp; and verifying whether the device corresponding to the device identifier is within the legal registration scope and whether the tenant has the right to store evidence. Nodes that pass the verification sign the result and broadcast it, while nodes that fail discard the data and report back, ensuring that illegal data does not enter the subsequent consensus process.

[0069] Independent verification by each consensus node avoids the risk of single-point verification failure. Multiple verification rules, such as verification of source, format, and permissions, filter illegal data from multiple dimensions, such as forged signatures, incorrect format, and logs from unauthorized devices, significantly improving the security of the consortium blockchain network. The signature and broadcast of verification results provide a reliable basis for subsequent master nodes to statistically verify the situation, ensuring that the consensus process is based on real and legitimate data.

[0070] S34: The master node receives the verification results from each consensus node, generates a pre-prepared message containing a summary of log transaction data and a sequence number, and broadcasts it to all replica nodes.

[0071] Understandably, the master node collects the verification results from all consensus nodes, confirms that the number of passing nodes has reached a preset basic threshold, calculates a digest of the log transaction data to ensure the message is concise, assigns a unique sequence number to avoid transaction order confusion, integrates the transaction digest and sequence number to generate a pre-prepared message, and then broadcasts the pre-prepared message to all replica nodes through the P2P network, officially starting the core process of PBFT consensus.

[0072] Among these features, the transaction summary in the pre-preparation message can reduce the amount of data transmission and improve broadcast efficiency; the unique sequence number can ensure that all replica nodes process transactions in a unified order, avoiding consensus failure due to disordered order; the master node actively initiates the pre-preparation phase, which clarifies the timing of the consensus process start, avoids replica nodes waiting for timeout, and improves the overall efficiency of consensus.

[0073] S35: After receiving the pre-preparation message, the replica node performs a second verification of the legality of the log transaction data. If the verification is successful, it generates a preparation message and broadcasts it.

[0074] Step S35 is the PBFT preparation phase. Specifically, after receiving the pre-preparation message, the replica node does not directly accept it, but performs secondary verification. That is, it re-verifies the signature, format, and device permissions of the log transaction data (consistent with the verification rules in step S33), and verifies whether the sequence number in the pre-preparation message is within a reasonable range to ensure that it has not been duplicated. After the secondary verification is passed, the replica node generates a preparation message and broadcasts the preparation message to all consensus nodes of the consortium chain, including the master node and other replica nodes, indicating that it is ready to accept the transaction.

[0075] S36: After each consensus node collects preparation messages from more than 2f different replica nodes, it generates a commit message and broadcasts it, where f is the number of malicious nodes that the consortium blockchain can tolerate.

[0076] Among them, a consortium blockchain is a private blockchain system jointly maintained by multiple specific organizations. It has partial openness and access control mechanisms, making it suitable for cross-organizational data sharing and trusted collaboration environments. It is the preferred chain type for trusted log storage in this embodiment. F is the preset number of malicious nodes that the consortium blockchain can tolerate; for example, f=3 means that 3 malicious nodes can be tolerated.

[0077] Step S36 is the transition between PBFT preparation and commit. Each consensus node collects preparation messages sent by other replica nodes in real time. When the number of preparation messages collected from different replica nodes exceeds 2f, it is determined that a majority of replica nodes have recognized the legality of the transaction. At this time, a commit message is generated and broadcast to all consensus nodes, advancing the consensus into the final confirmation stage.

[0078] Understandably, the design of having more than 2f preparation messages ensures that even if f malicious nodes forge preparation messages, the process can still proceed through the preparation messages of the majority of legitimate nodes, demonstrating the PBFT algorithm's advantage against malicious nodes. The broadcasting of the commit message enables all nodes to enter the final confirmation stage synchronously, avoiding inconsistencies in the ledger caused by some nodes committing early and others lagging behind, thus ensuring the consistency of consortium blockchain data.

[0079] S37: When any consensus node collects at least 2f+1 commit messages, a consensus result is generated.

[0080] Step S37 is the PBFT commit phase. After broadcasting the commit message, each consensus node continues to collect commit messages from other nodes. When any node has collected at least 2f+1 commit messages, the majority node confirmation condition for PBFT consensus is met. It is determined that the log transaction data has been recognized by a majority of the consortium blockchain nodes. At this point, a consensus result is generated and synchronized to the IoT platform and other nodes. Each node can independently determine the consensus result, avoiding single points of failure caused by reliance on the master node, improving the fault tolerance and reliability of the consensus process, and providing a trusted foundation for subsequent on-chain evidence storage with multi-party recognition.

[0081] S40: If the consensus result is that a consensus has been reached, the log transaction data is packaged into a new block through the preset node of the consortium blockchain, and the log transaction data is stored on the blockchain for evidence.

[0082] In this embodiment, the preset node is the block producer (Proposer) of the consortium blockchain. The block producer collects log transaction data that has reached consensus. When the data volume reaches a threshold or the time reaches a threshold, the transactions are deduplicated, sorted, and packaged. A Merkle tree is constructed by calculating the transaction hash to generate the block body. The block header is generated by combining the hash of the previous block, the Merkle root, the timestamp, and the block producer's signature to form a new block. The block producer broadcasts the new block. After each node verifies it, it is added to the local blockchain ledger to complete the on-chain evidence storage.

[0083] Among them, the threshold-triggered packaging mechanism of block-producing nodes balances block generation efficiency and data volume, avoiding blocks that are too large or too small; the design of the Merkle tree and block header ensures the integrity and chain continuity of block data, preventing blocks from being tampered with; full node verification and ledger synchronization realize distributed notarization of log transaction data, solving the core problems of easy tampering and loss in traditional centralized storage, and realizing trusted notarization of logs across the network.

[0084] In some embodiments of the present invention, such as Figure 6 As shown, a specific on-chain evidence storage scheme is provided. In S40, if the consensus result is that a consensus has been reached, the log transaction data is packaged into a new block through the preset node of the consortium blockchain, and the log transaction data is stored on the blockchain for evidence storage. Specifically, it includes the following steps S41-S48.

[0085] S41: Using the pre-set block-producing nodes of the consortium blockchain, log transaction data that has reached consensus is collected in real time. When the number of collected log transaction data reaches a preset threshold or a block time threshold, the collected log transaction data is deduplicated and sorted to obtain a set of transactions to be packaged.

[0086] The pre-set block-producing nodes (Proposer nodes) monitor the log transaction data that has reached consensus in the consortium blockchain in real time; the pre-set thresholds include but are not limited to quantity thresholds (such as every 100 consensus transactions collected) and time thresholds (such as every 5 minutes). Meeting either threshold will trigger packaging; before packaging, the transaction data is deduplicated, that is, duplicate submissions of the same log transaction are removed, and sorted by timestamp to ensure that the transaction order is consistent with the actual occurrence order, and finally a set of transactions to be packaged is formed.

[0087] Among them, the mechanism of reaching a preset threshold for the number of blocks or reaching a block time threshold avoids excessively frequent block production that wastes resources or excessively slow production that delays evidence storage, thus balancing evidence storage efficiency and resource consumption; the deduplication operation prevents the same log transaction from being repeatedly uploaded to the chain, which leads to ledger redundancy; the sorting operation ensures that the transaction order within the block is consistent with the actual order of occurrence in the log, providing an accurate basis for timeline tracing during subsequent audits and improving the standardization and traceability of the ledger.

[0088] S42: Perform format validation on each log transaction data in the transaction set to be packaged, remove transaction data with abnormal format, and retain valid transaction data.

[0089] For the set of transactions to be packaged obtained in step S41, the format of each log transaction is checked twice. The verification standard is the same as the format verification rule in step S33, namely, whether it conforms to the blockchain transaction format specification, whether the fields are complete, and whether the data type is correct. If abnormal transaction data is found, such as missing fields or disordered format, it is removed and only valid transaction data with legal format is retained to ensure that all transactions entering the block can be parsed normally by all nodes.

[0090] The verification in step S42 serves as the final filter before being uploaded to the blockchain, preventing abnormal transactions from being uploaded due to data corruption or malicious tampering after consensus, thus ensuring the legality of the block data. After removing abnormal data, only valid transactions are retained in the block, reducing block storage redundancy and ensuring that subsequent nodes will not fail to verify the block due to abnormal transactions, thereby improving the success rate of the block being uploaded to the blockchain and the purity of the ledger.

[0091] S43: Calculate the hash value of each valid transaction data, construct a Merkle tree based on the hash values ​​of all valid transaction data, and form a block based on the root hash of the Merkle tree.

[0092] Merkle trees are hash tree structures that combine multiple log hashes into a root hash. They are used to efficiently verify the consistency of log sets and are often used in blockchains to implement batch data integrity verification.

[0093] For each valid transaction data retained in step S42, calculate its hash value; according to the Merkle tree structure, take all transaction hash values ​​as leaf nodes and calculate the parent node hash layer by layer upwards. Among them, the hashes of every two child nodes are merged to calculate the parent hash, and finally a unique Merkle root hash is obtained; the block body is formed in the form of Merkle root hash and a list of valid transaction data, and the Merkle root hash represents the integrity of all transaction data.

[0094] Understandably, the construction of the Merkle tree links all transaction data within a block through a root hash. When subsequent nodes verify the integrity of the block, they do not need to verify each transaction individually, but only the Merkle root hash, which greatly improves verification efficiency. At the same time, if any transaction data is tampered with, the Merkle root hash will change, which can quickly locate the tampering location and achieve efficient integrity verification of block data, solving the problem of low efficiency in traditional transaction-by-transaction verification.

[0095] S44: Obtain the hash value of the latest block in the consortium blockchain as the hash of the previous block, and combine it with the root hash of the Merkle tree, the current timestamp, and the block-producing node identifier to generate the block header.

[0096] The block header, or metadata portion of each block in the blockchain, includes the block hash, the previous block hash, a timestamp, and the Merkle root, and is used to verify the legitimacy of the block data and the continuity of the chain structure. These pieces of information are combined in a preset order to form a fixed-format block header, serving as the block's identity and association identifier.

[0097] The hash of the previous block creates a chain structure between the new block and the blockchain ledger, ensuring the continuity of the blockchain. If any historical block is tampered with, the hash of the previous block in subsequent blocks will not match, achieving full-chain tamper-proofing. The Merkle root hash, timestamp, and block-producing node identifier respectively ensure the integrity of the block body, the traceability of the evidence storage time, and the traceability of the block-producing node, providing a comprehensive basis for subsequent auditing and liability determination, and improving the security and traceability of the ledger.

[0098] S45: Combine the block body and the block header to form a block candidate.

[0099] The block body formed in step S43 and the block header generated in step S44 are combined in the order of block header first and block body last to form a block candidate body. The block candidate body is the prototype of a new block, containing all the core information of the block, and only needs to be confirmed by signature to become a formal block.

[0100] Understandably, the combination of block candidate bodies makes the block information structured and complete, ensuring that it includes identity identifiers (block headers) and data content (block bodies), providing a unified block unit for subsequent signing and broadcasting; the fixed block header and block body structure conforms to the parsing habits of consortium blockchain nodes, avoiding nodes being unable to recognize due to structural chaos, and ensuring the smooth progress of subsequent block broadcasting and verification.

[0101] S46: The block-producing node uses its own private key to digitally sign the block candidate to form a new block.

[0102] The block-producing node obtains its own private key, uses an asymmetric encryption algorithm to digitally sign the block candidate, and generates the block-producing node's signature information; the signature information is appended to the end of the block candidate to form a formal new block. The signature information can be verified by the block-producing node's public key to prove that the block originated from a legitimate block-producing node.

[0103] For step S46, the block-producing node's private key signature adds a legitimate source identifier to the new block, preventing illegal nodes from forging and broadcasting the block, and ensuring the authenticity of the block's source. The signature information is bound to the block, and subsequent nodes can quickly confirm whether the block was generated by a legitimate block-producing node through the public key, improving the security of the block on the chain and preventing malicious blocks from interfering with the consistency of the ledger.

[0104] S47: The block-producing node broadcasts the new block to all nodes in the consortium blockchain.

[0105] After a block-producing node generates a new block, it can broadcast the new block to all nodes in the consortium blockchain through the P2P network mechanism built into the blockchain platform. During the broadcast, a distributed transmission method is used to ensure that all nodes can receive the new block synchronously in a short time, avoiding the loss of synchronization of node ledgers due to network latency.

[0106] Among them, P2P network broadcasting ensures that all consortium blockchain nodes can obtain new blocks, realize distributed synchronous storage of the ledger, and avoid consistency problems caused by some nodes not updating the ledger; fast synchronization ensures that audit nodes across organizations can obtain the latest evidence logs in a timely manner, improve the real-time performance of cross-network log auditing, and solve the problem of slow synchronization in traditional centralized storage.

[0107] S48: After receiving the new block, each consensus node verifies whether the hash of the previous block is consistent with the hash of the latest local block, whether the Merkle root can be restored by hashing valid transaction data, and whether the signature of the block-producing node is valid. If the verification is successful, the new block is added to the local blockchain ledger, and the on-chain storage of the log transaction data is completed.

[0108] Auditing, in particular, involves tracking, comparing, and tracing responsibility based on data stored in blockchain logs. It supports consistency verification of on-chain and off-chain logs and assists in tasks such as operation and maintenance, security, and compliance. Evidence anchoring is the process of recording key event summaries with legal or systemic validity in the blockchain for future use as evidence in disputes or audits. It features verifiability, non-repudiation, and immutability.

[0109] After receiving a new block, each consensus node performs three core verifications: First, previous block hash verification, which checks if the hash of the previous block matches the hash of the latest block in the local ledger to ensure chain continuity. Second, Merkle root verification, which recalculates the Merkle root using the hash values ​​of valid transaction data within the block and checks if it matches the Merkle root in the block header to verify transaction integrity. Third, block-producing node signature verification, which verifies the block signature using the block-producing node's public key to confirm the legitimacy of the source. Once all three verifications pass, the new block is added to the local blockchain ledger, completing the on-chain storage of log transaction data.

[0110] Triple verification ensures the legality and validity of new blocks from three dimensions: chain continuity, transaction integrity, and source legitimacy, completely eliminating the risk of tampering with or forging blocks. Each node independently updates its local blockchain ledger, realizing distributed and tamper-proof storage of log transaction data. This solves the core problems of traditional centralized logs being easily tampered with and difficult to trace responsibility, providing a multi-party stored and tamper-proof trusted data foundation for subsequent auditing and traceability.

[0111] S50: Periodically extracts the notarized log transaction data from the blockchain, compares and verifies it with the off-chain structured log data, and triggers an anomaly alarm when the verification results are inconsistent.

[0112] For step S50, a periodic verification cycle is set, such as hourly or daily, and verification tasks are triggered periodically. During verification, the notarized log transaction data is extracted from the blockchain ledger according to the time interval or device identifier. The core is the log hash digest. The corresponding structured log data, i.e. the original log data, is retrieved from the off-chain database table. The hash value of the off-chain data is recalculated and compared with the hash digest on the chain. If they are inconsistent, it is determined that the data has been tampered with or lost. The verification result is recorded and an abnormal alarm is triggered.

[0113] Understandably, regular comparison and verification enable full lifecycle integrity monitoring of log data. Even if the original off-chain data is tampered with, it can be quickly detected through the immutable hash digest on the chain, solving the problem that traditional off-chain data is easy to tamper with but difficult to detect. The anomaly alarm mechanism ensures that operations and maintenance personnel can respond to tampering risks in a timely manner, quickly trace the problematic device and time, improve the security supervision capability of cross-network logs, and meet the requirement of verifiable data authenticity in compliance audits.

[0114] In some embodiments of the present invention, such as Figure 7 As shown, a specific verification scheme is provided. In S50, the notarized log transaction data is periodically extracted from the blockchain and compared with the off-chain structured log data for verification. When the verification results are inconsistent, an abnormal alarm is triggered. Specifically, it includes the following steps S51-S55.

[0115] S51: Set a periodic verification cycle, trigger a verification task according to the verification cycle, and in each verification task, query and extract the proven log hash digest from the blockchain ledger according to the preset time interval or device identifier.

[0116] In practice, the periodic verification cycle can be set by the user according to business needs, and the verification task is automatically triggered on a periodic basis. During extraction, the corresponding log transaction data is accurately queried from the blockchain ledger by preset filtering conditions, such as the time range of "nearly 24 hours" and the device identifier "device001". Only the log hash digest is extracted, rather than the complete transaction data, which reduces the amount of data transmission and improves the extraction efficiency.

[0117] S52: Retrieve the corresponding structured log data from the off-chain database table based on the tenant identifier or device identifier associated with the extracted log hash digest.

[0118] It is understandable that when the log hash digest is stored on the chain, it is associated with the tenant identifier (tenant_id) and the device identifier (device_id). When retrieving, the corresponding structured log data is queried and retrieved from the preset database table devicesvc.device_data off-chain through this association. That is, the original log data stored off-chain in step S21 ensures that the retrieved off-chain data and the on-chain hash digest belong to the same log.

[0119] For step S52, the on-chain hash and the off-chain raw data are accurately matched by the tenant / device identifier association, avoiding the distortion of the verification result due to the matching error; the data is directly retrieved from the off-chain database table without the need for re-collection, which improves the data retrieval efficiency, and at the same time ensures that the retrieved data is the complete raw log data, providing an accurate data source for subsequent hash recalculation.

[0120] S53: Call the SHA-256 hash algorithm to perform hash calculation on the retrieved off-chain structured log data to obtain the comparison hash value.

[0121] The comparison hash value is the hash value recalculated from the structured log data stored off-chain in step S21, and it also uses the SHA-256 hash algorithm.

[0122] S54: Compare the comparison hash value with the stored log hash digest one by one to determine whether the two are completely consistent.

[0123] Step S54: Compare the comparison hash value obtained in step S53 with the hash digest of the proven log extracted in step S51 one by one. When comparing, it is necessary to ensure that one on-chain hash corresponds to one off-chain data to avoid chaotic comparisons of many to one or one to many. The two are judged by string matching. If they are consistent, it means that the off-chain data has not been tampered with. If they are inconsistent, it means that there is a risk of tampering or loss.

[0124] One-to-one comparison ensures that every log data is verified without omission, avoiding the possibility of undetected tampering due to sampling verification; the string matching method is simple and efficient, and can quickly produce verification results. At the same time, the uniqueness of the hash value ensures that consistency means no tampering and inconsistency means anomaly, making the verification results accurate and providing a reliable basis for subsequent alarms.

[0125] S55: If the comparison result is inconsistent, it is determined that the structured log data under the chain is at risk of being tampered with or lost. The verification result is recorded in the preset log verification table and an abnormal alarm is triggered.

[0126] If the comparison is inconsistent, it is determined that the off-chain structured log data is at risk of being tampered with or lost; the verification result is recorded in the log verification table used to retain audit traces, and at the same time the alarm module of the IoT platform is triggered to send abnormal alarm information to the system management terminal or the preset responsible person.

[0127] For step S55, risk assessment and result recording provide a complete audit trail for subsequent accountability and problem investigation, meeting the requirement of traceability of anomalies in compliance management; real-time anomaly alarms ensure that maintenance personnel can be aware of tampering risks as soon as possible and intervene quickly, such as locating tampered devices and restoring original data, avoiding audit errors or security incidents caused by data tampering and improving the security protection response speed of cross-network logs.

[0128] S60: The structured log data is streamed through a message queue. The log behavior is analyzed in real time based on preset rules and behavior recognition models. If an anomaly is detected, an alarm event is generated, and the hash information of the alarm event is written into the blockchain for evidence storage.

[0129] Specifically, message queues such as Kafka, Plusar, or MQTT are deployed to stream the structured log data generated in step S16 in real time, achieving low-latency transmission. Pre-defined behavior rules, such as unauthorized device access, log request frequency exceeding the threshold, and cross-domain data writing, are loaded and matched in real time through a JavaScript rule engine. This is combined with sliding window statistical analysis for calculating the frequency of anomalies per unit time, and a pre-trained LSTM behavior recognition model for detecting sudden changes in behavior patterns. When an anomaly is detected and an alarm event is generated, the SHA-256 hash information of the alarm event is calculated and written to the blockchain for evidence storage according to the encapsulation method in step S20.

[0130] Understandably, message queue streaming access enables real-time processing of log data, avoiding the lag in anomaly detection caused by offline analysis. The triple anomaly detection mechanism of rule matching, statistical analysis, and model recognition covers both known anomalies, such as illegal access in preset rules, and unknown anomalies, such as pattern mutations, improving the comprehensiveness of anomaly detection. Alarm event hashing and on-chain storage ensure that alarm information is tamper-proof, providing a reliable basis for subsequent responsibility determination of anomaly events. This achieves dual protection of real-time monitoring and anomaly tracing of cross-network logs, improving the security level of cross-network data exchange in the Internet of Things.

[0131] As can be seen, the above scheme provides a unified foundation for cross-network log consistency verification through standardized log preprocessing; and by relying on consortium blockchain multi-node verification consensus and hash on-chain notarization, it completely avoids the defects of traditional centralized logs being easily tampered with and lost, ensuring the authenticity and immutability of cross-network data exchange logs; at the same time, the on-chain and off-chain periodic comparison and alarm mechanism realizes reliable monitoring and anomaly tracing of logs in multi-network environments, meeting the security monitoring and accountability requirements in complex IoT scenarios.

[0132] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0133] In one embodiment, the present invention provides an IoT cross-network data monitoring device 100, which corresponds one-to-one with the IoT cross-network data monitoring method described in the above embodiments. For example... Figure 8 As shown, the IoT cross-network data monitoring device 100 includes a data acquisition module 101, an extraction module 102, a consensus module 103, an on-chain module 104, and a verification module 105. Detailed descriptions of each functional module are as follows: The acquisition module 101 is used to collect and standardize the logs of cross-network data exchange in the Internet of Things to obtain structured log data.

[0134] Extraction module 102 is used to store the structured log data off-chain, and extract and encapsulate the hash value and metadata of the structured log data to form log transaction data.

[0135] The consensus module 103 is used to broadcast the log transaction data to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain the consensus result.

[0136] The on-chain module 104 is used to package the log transaction data into a new block through the preset node of the consortium blockchain and perform on-chain storage of the log transaction data if the consensus result is that a consensus has been reached.

[0137] The verification module 105 is used to periodically extract the notarized log transaction data from the blockchain, compare and verify it with the off-chain structured log data, and trigger an anomaly alarm when the verification results are inconsistent.

[0138] In one embodiment, the acquisition module 101 is specifically used for: Log data from IoT devices across networks is collected in real time and stored in a preset database table, wherein the database table includes a device identifier and a payload field for recording data content; The log data is parsed into JSON format to obtain the parsed log data; The format of the payload field of the parsed log data is validated to determine whether the payload field conforms to the predefined JSON template and field specifications. If it does not conform, it is marked as abnormal data. Extract the preset key fields from the parsed log data; Filter out the abnormal data and the invalid data after extracting the key fields; The filtered log data forms the structured log data.

[0139] In one embodiment, the acquisition module 102 is specifically used for: The structured log data is stored off-chain; The structured log data is hashed using the SHA-256 hash algorithm to generate a unique log hash digest; Extract metadata corresponding to the structured log data from the database table, and integrate the log hash digest and the metadata into a data set; Obtain the private key of the sending node, and use an asymmetric encryption algorithm to digitally sign the data set to generate signature information; The data set and corresponding signature information are encapsulated according to a preset transaction structure specification to form the log transaction data.

[0140] In one embodiment, the consensus module 103 is specifically used for: The blockchain's communication interface is invoked to submit the log transaction data to the access node of the consortium blockchain network; The access node broadcasts the log transaction data to all consensus nodes of the consortium blockchain, wherein the consensus nodes include master nodes and replica nodes; After receiving the log transaction data, each consensus node independently verifies it based on preset verification rules. If the consensus node passes the verification, it generates a verification result, signs it, and broadcasts the verification result to all other consensus nodes. If the verification fails, it discards the log transaction data and sends back a verification failure message. The master node receives the verification results from each consensus node, generates a pre-prepared message containing a summary of log transaction data and a sequence number, and broadcasts it to all replica nodes. After receiving the pre-preparation message, the replica node performs a second verification of the legality of the log transaction data. If the verification is successful, it generates a preparation message and broadcasts it. After each consensus node collects preparation messages from more than 2f different replica nodes, it generates a commit message and broadcasts it, where f is the number of malicious nodes that the consortium blockchain can tolerate. A consensus result is generated when any consensus node collects at least 2f+1 commit messages.

[0141] In one embodiment, the on-chain module 104 is specifically used for: Using the pre-set block-producing nodes of the consortium blockchain, log transaction data that has reached consensus is collected in real time. When the number of collected log transaction data reaches a preset threshold or a block time threshold, the collected log transaction data is deduplicated and sorted to obtain a set of transactions to be packaged. Perform format validation on each log transaction data in the transaction set to be packaged, remove transaction data with abnormal format, and retain valid transaction data; Calculate the hash value of each valid transaction data, construct a Merkle tree based on the hash values ​​of all valid transaction data, and form a block body based on the root hash of the Merkle tree; Obtain the hash value of the latest block in the consortium blockchain as the hash of the previous block, and combine it with the root hash of the Merkle tree, the current timestamp, and the block-producing node identifier to generate the block header; The block body and the block header are combined to form a block candidate body; The block-producing node uses its own private key to digitally sign the block candidate to form a new block; The block-producing node broadcasts the new block to all nodes in the consortium blockchain. After receiving the new block, each consensus node verifies whether the hash of the previous block is consistent with the hash of the latest local block, whether the Merkle root can be restored by hashing valid transaction data, and whether the signature of the block-producing node is valid. If the verification is successful, the new block is added to the local blockchain ledger, completing the on-chain storage of the log transaction data.

[0142] In one embodiment, the verification module 105 is specifically used for: Set a periodic verification cycle, trigger a verification task according to the verification cycle, and in each verification task, query and extract the stored log hash digest from the blockchain ledger according to the preset time interval or device identifier. Based on the tenant or device identifier associated with the extracted log hash digest, retrieve the corresponding structured log data from the off-chain database table; The SHA-256 hash algorithm is invoked to perform hash calculations on the retrieved off-chain structured log data to obtain the comparison hash value; The comparison hash value is compared one by one with the proven log hash digest to determine whether the two are completely consistent. If the comparison results are inconsistent, it is determined that the structured log data under the chain is at risk of being tampered with or lost. The verification result is recorded in the preset log verification table, and an abnormal alarm is triggered.

[0143] The IoT cross-network data monitoring device 100 in this embodiment further includes: an alarm module 106; the alarm module 106 is used to access the structured log data in a streaming manner through a message queue, perform real-time analysis of log behavior based on preset rules and behavior recognition models, generate an alarm event if an anomaly is detected, and write the hash information of the alarm event into the blockchain for storage.

[0144] Specific limitations regarding the IoT cross-network data monitoring device 100 can be found in the limitations of the IoT cross-network data monitoring method described above, and will not be repeated here. Each module in the aforementioned IoT cross-network data monitoring device 100 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0145] In one embodiment, a computer device 200 is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9As shown. The computer device 200 includes a processor 220, memory, and a network interface 250 connected via a system bus 210. The processor 220 provides computing and control capabilities. The memory of the computer device 200 includes non-volatile and / or volatile storage media and internal memory 240. The non-volatile storage media 230 stores an operating system 231, computer programs 232, and a database 233. The internal memory 240 provides an environment for the operation of the operating system and computer programs in the non-volatile storage media 230. The network interface 250 of the computer device 200 is used for communication with external clients via a network connection. When the computer program is executed by the processor 220, it implements the functions or steps of a cross-network data monitoring method server for the Internet of Things (IoT). That is, when the processor 220 executes the computer program, it implements the following steps: The data exchange logs across IoT networks are collected and standardized preprocessed to obtain structured log data; The structured log data is stored off-chain, and the hash value and metadata of the structured log data are extracted and encapsulated to form log transaction data; The log transaction data is broadcast to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain the consensus result. If the consensus result is that a consensus has been reached, the log transaction data will be packaged into a new block through the preset node of the consortium blockchain, and the log transaction data will be stored on the blockchain for evidence. Periodically extract notarized log transaction data from the blockchain, compare and verify it with off-chain structured log data, and trigger an anomaly alarm when the verification results are inconsistent.

[0146] In one embodiment, a computer device 300 is provided, which may be a client, and its internal structure diagram may be as follows: Figure 10 As shown. The computer device includes a processor 320, memory, network interface 350, display screen 370, and input device 360 ​​connected via a system bus 310. The processor 320 provides computing and control capabilities. The memory includes a non-volatile storage medium 330 and internal memory 340. The non-volatile storage medium 330 stores an operating system 331 and a computer program 332. The internal memory provides an environment for the operation of the operating system 331 and the computer program 332 in the non-volatile storage medium 330. The network interface 350 of the computer device 300 is used for communication with an external server via a network connection. When the computer program is executed by the processor 320, it implements the functions or steps on the client side of an IoT cross-network data monitoring method. That is, when the processor 320 executes the computer program 332, it performs the following steps: The data exchange logs across IoT networks are collected and standardized preprocessed to obtain structured log data; The structured log data is stored off-chain, and the hash value and metadata of the structured log data are extracted and encapsulated to form log transaction data; The log transaction data is broadcast to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain the consensus result. If the consensus result is that a consensus has been reached, the log transaction data will be packaged into a new block through the preset node of the consortium blockchain, and the log transaction data will be stored on the blockchain for evidence. Periodically extract notarized log transaction data from the blockchain, compare and verify it with off-chain structured log data, and trigger an anomaly alarm when the verification results are inconsistent.

[0147] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: The data exchange logs across IoT networks are collected and standardized preprocessed to obtain structured log data; The structured log data is stored off-chain, and the hash value and metadata of the structured log data are extracted and encapsulated to form log transaction data; The log transaction data is broadcast to all consensus nodes of the consortium blockchain. After each consensus node independently verifies the log transaction data, the verification results of all consensus nodes are collected to obtain the consensus result. If the consensus result is that a consensus has been reached, the log transaction data will be packaged into a new block through the preset node of the consortium blockchain, and the log transaction data will be stored on the blockchain for evidence. Periodically extract notarized log transaction data from the blockchain, compare and verify it with off-chain structured log data, and trigger an anomaly alarm when the verification results are inconsistent.

[0148] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0149] Those skilled in the art will understand that all or part of the processes in the methods of 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. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0150] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0151] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. 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. Such 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, and should all be included within the protection scope of the present invention.

Claims

1. A method for cross-network data monitoring for the Internet of Things, characterized in that, The method comprises the following steps: Collecting and standardizing preprocessing of the Internet of Things cross-network data exchange log to obtain structured log data; Storing the structured log data off-chain, extracting and packaging the hash value and metadata of the structured log data to form log transaction data; Broadcasting the log transaction data to all consensus nodes of the consortium chain, collecting the validation results of all consensus nodes to obtain a consensus result after each consensus node independently validates the log transaction data; If the consensus result is consensus, the log transaction data is packaged into a new block by a preset node of the consortium chain, and the on-chain storage of the log transaction data is performed; Periodically extracting the stored log transaction data from the blockchain, comparing and verifying the off-chain structured log data, and triggering an abnormal alarm when the verification result is inconsistent.

2. The IoT cross-network data monitoring method of claim 1, wherein, The method comprises the following steps: Real-time collection of log data of Internet of Things devices across networks, and storage of the collected log data in a preset database table, wherein the database table contains device identification and a payload field for recording data content; Parsing the log data into JSON format to obtain parsed log data; Format checking of the payload field of the parsed log data to determine whether the payload field conforms to the predefined JSON template and field specification, and marking as abnormal data if it does not conform; Extracting the preset key field from the parsed log data; Filtering the abnormal data and invalid data after the key field extraction; The filtered log data forms the structured log data.

3. The IoT cross-network data monitoring method of claim 2, wherein, The method comprises the following steps: Storing the structured log data off-chain; Using the SHA-256 hash algorithm to calculate the hash of the structured log data to generate a unique log hash digest; Extracting the metadata corresponding to the structured log data from the database table, integrating the log hash digest and the metadata into a data set; Obtaining the private key of the sending node, digitally signing the data set using an asymmetric encryption algorithm to generate signature information; Encapsulating the data set and the corresponding signature information according to the preset transaction structure specification to form the log transaction data.

4. The IoT cross-network data monitoring method of claim 3, wherein, The method comprises the following steps: Calling the communication interface of the blockchain to submit the log transaction data to the access node of the consortium chain network; Broadcasting the log transaction data to all consensus nodes of the consortium chain by the access node, wherein the consensus nodes include master nodes and replica nodes; After each consensus node receives the log transaction data, the consensus node independently verifies the log transaction data based on a preset verification rule; if the consensus node passes the verification, the consensus node generates a verification pass result, signs the verification pass result, and broadcasts the verification pass result to all other consensus nodes; if the consensus node fails the verification, the consensus node discards the log transaction data and feeds back a verification failure message; The main node receives the verification pass results of the consensus nodes, generates a pre-preparation message containing a log transaction data digest and a serial number, and broadcasts the pre-preparation message to all replica nodes; After the replica node receives the pre-preparation message, the replica node verifies the legality of the log transaction data again, and generates a preparation message and broadcasts the preparation message if the verification passes; After each consensus node collects preparation messages from more than 2f different replica nodes, the consensus node generates a submission message and broadcasts the submission message, where f is a preset number of tolerable malicious nodes of the alliance chain; When any consensus node collects at least 2f+1 submission messages, the consensus node generates a consensus result.

5. The IoT cross-network data monitoring method of claim 4, wherein, If the consensus result is a consensus, the preset node of the alliance chain packs the log transaction data into a new block and performs on-chain storage of the log transaction data, including: The preset block node of the alliance chain collects log transaction data that reaches a consensus in real time, removes and sorts the collected log transaction data when the number of collected log transaction data reaches a preset threshold or a block generation time threshold, and obtains a to-be-packed transaction set; Each log transaction data in the to-be-packed transaction set is subjected to format verification, and invalid transaction data is removed, and valid transaction data is retained; The hash value of each valid transaction data is calculated, a Merkle tree is constructed based on the hash values of all valid transaction data, and a block body is formed based on the root hash of the Merkle tree; The hash value of the current latest block of the alliance chain is obtained as a previous block hash, and a block header is generated by combining the root hash of the Merkle tree, a current timestamp, and a block node identifier; The block body and the block header form a block candidate; The block node uses its own private key to digitally sign the block candidate to form a new block; The block node broadcasts the new block to all nodes of the alliance chain; After each consensus node receives the new block, the consensus node verifies whether the previous block hash is consistent with the local latest block hash, whether the Merkle root can be restored from the hash values of the valid transaction data, and whether the block node signature is valid, and if the verification passes, the consensus node adds the new block to the local blockchain ledger, and completes the on-chain storage of the log transaction data.

6. The IoT cross-network data monitoring method of claim 5, wherein, The stored log transaction data is extracted from the blockchain at regular intervals, compared and verified with off-chain structured log data, and an abnormal alarm is triggered when the verification result is inconsistent, including: A periodic verification period is set, and a verification task is triggered according to the verification period. In each verification task, a stored log hash digest is queried and extracted from the blockchain ledger according to a preset time interval or device identifier; According to the tenant identifier or device identifier associated with the extracted log hash digest, the corresponding structured log data is retrieved from the off-chain database table; The SHA-256 hash algorithm is called to hash the called off-chain structured log data, and a comparison hash value is obtained. The comparison hash value is compared with the stored log hash digest one by one to determine whether they are completely consistent. If the comparison result is inconsistent, it is determined that the off-chain structured log data has tampering or loss risk, the verification result is recorded in the preset log verification table, and an abnormal alarm is triggered.

7. The IoT cross-network data monitoring method of claim 6, wherein, After the periodic extraction of the stored log transaction data from the blockchain, the comparison and verification of the off-chain structured log data, and the triggering of an abnormal alarm when the verification result is inconsistent, the method further comprises: The structured log data is accessed through a message queue, the log behavior is analyzed in real time based on a preset rule and a behavior recognition model, an alarm event is generated if an abnormality is identified, and the hash information of the alarm event is written into the blockchain for storage.

8. An IoT cross-network data monitoring device, characterized by, It comprises: A collection module for collecting and standardizing the Internet of Things cross-network data exchange log to obtain structured log data; An extraction module for storing the structured log data off-chain and extracting and packaging the hash value and metadata of the structured log data to form log transaction data; A consensus module for broadcasting the log transaction data to all consensus nodes of the alliance chain, collecting the verification results of all consensus nodes to obtain a consensus result after the log transaction data is independently verified by each consensus node; An on-chain module for packaging the log transaction data into a new block through a preset node of the alliance chain and storing the log transaction data on the chain if the consensus result is consensus; A verification module for periodically extracting the stored log transaction data from the blockchain, comparing and verifying the off-chain structured log data, and triggering an abnormal alarm when the verification result is inconsistent.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to realize the steps of the Internet of Things cross-network data monitoring method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, the computer-readable storage medium comprising: The computer program is executed by the processor to realize the steps of the Internet of Things cross-network data monitoring method according to any one of claims 1 to 7.

Images