IoT data adaptive blockchain evidence storage methods, systems, blockchain gateway devices and computer program products

Abstract

This application provides an adaptive blockchain notarization method, system, blockchain gateway device, and computer program product for IoT data. The main components include: receiving raw data transmitted from IoT devices; calculating the notarization value score of the raw data based on at least two of the following: risk deviation index, event scarcity index, device reputation weight index, and service interruption indication index; periodically acquiring the operating status parameters of the blockchain network and calculating the current congestion index based on the operating status parameters; calculating a rapid notarization threshold and an aggregated notarization threshold based on the current congestion index; and performing the following diversion processing on the raw data according to the relationship between the notarization value score and the rapid notarization threshold and the aggregated notarization threshold, respectively, to complete the notarization of data transmitted by IoT devices, achieving adaptive resource optimization and timely protection of critical data.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to an adaptive blockchain evidence storage method, system, blockchain gateway device and computer program product for Internet of Things data. Background Technology

[0002] In scenarios such as the Industrial Internet of Things (IIoT) and smart cities, massive amounts of devices generate high-frequency streaming data. To ensure its immutability and traceability, the data hash values ​​are often stored on the blockchain. However, the limited on-chain throughput and high storage costs fundamentally contradict the massive nature of IoT data. Existing solutions mainly fall into two categories: one is the "full on-chain" model, which writes all data directly onto the chain, resulting in uncontrollable costs, and even high-value data faces delays during network congestion; the other is the "static batch processing" model, which aggregates data onto the chain according to fixed time or quantity windows. Although this reduces costs, it cannot respond to sudden high-risk events and carries the risk of data loss and response delays. Ultimately, existing technologies lack the ability to quantify and differentiate the intrinsic value of data, and fail to perceive and dynamically adapt to changes in the state of the blockchain network, making it difficult to achieve a balance between cost, real-time performance, and reliability in the notarization strategy. Summary of the Invention

[0003] This application provides an adaptive blockchain evidence storage method, system, blockchain gateway device, and computer program product for IoT data. It can solve the technical problem mentioned in the background art of how to dynamically adapt to network conditions when blockchain resources are limited, and achieve real-time reliable evidence storage of high-value key data and global optimization of evidence storage costs for low-value data in IoT data.

[0004] The core concept of this application lies in constructing a dual-loop adaptive control model. The inner loop (data value loop) quantifies the necessity of storing each piece of IoT data in real time through multi-dimensional indicators, generating a storage value score V(d). The outer loop (network state loop) senses the congestion index C of the blockchain network in real time. net Dynamically adjust the 'price' of resource access (i.e., the ultra-fast evidence storage threshold T) fast And aggregated evidence threshold T chain The internal and external loops work together to enable the evidence storage strategy to dynamically adjust to the data value density and the scarcity of network resources, thereby achieving a global balance between real-time ownership confirmation of high-value data and optimization of overall evidence storage costs.

[0005] In a first aspect, embodiments of this application provide that the method is executed by a blockchain gateway device connected to a blockchain network, including the following steps:

[0006] Step S1: Receive raw data from IoT devices;

[0007] Step S2: Determine at least two indicators corresponding to the original data, including: a risk deviation indicator, an event scarcity indicator, a device reputation weight indicator, and a service interruption indication indicator; wherein, the risk deviation indicator represents the degree of deviation of the original data from the statistical characteristics of a historical time window; the event scarcity indicator represents the frequency of occurrence of the event type to which the original data belongs within a preset historical statistical period; the device reputation weight indicator represents the weight corresponding to the reputation level of the IoT device that generated the original data; and the service interruption indication indicator represents the service alarm level corresponding to the original data.

[0008] Step S3: Calculate the evidentiary value score of the original data based on at least two determined indicators;

[0009] Step S4: Periodically acquire the operating status parameters of the blockchain network, and calculate the current congestion index based on the operating status parameters;

[0010] Step S5: Calculate the maximum speed evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index;

[0011] Step S6: Based on the relationship between the evidence preservation value score and the rapid evidence preservation threshold and the aggregated evidence preservation threshold, the original data is processed as follows:

[0012] If the business interruption indicator indicates that it belongs to the preset highest alarm level, then the constraint of the ultra-fast evidence storage threshold is ignored, and the original data is routed to a single transaction channel for blockchain evidence storage.

[0013] If the service interruption indicator does not indicate that it belongs to the preset highest alarm level, and the evidence value score is greater than or equal to the ultra-fast evidence storage threshold, then the original data is routed to the single transaction channel; if the evidence value score is less than the ultra-fast evidence storage threshold, but greater than or equal to the aggregated evidence storage threshold, then the original data is routed to the batch processing channel for blockchain evidence storage.

[0014] If the evidence preservation value score is less than the aggregated evidence preservation threshold, calculate the first hash value of the original data, and store the original data and its corresponding first hash value in the local data storage system; after reaching the preset archiving time period, perform a summary calculation on all the first hash values ​​stored locally within the archiving time period to generate a periodic summary hash value; construct a blockchain evidence preservation transaction, the transaction including at least the periodic summary hash value and metadata representing the archiving time period, and submit the transaction to the blockchain network to complete the evidence preservation.

[0015] The beneficial effects of this application are as follows: This invention proposes an adaptive blockchain notarization method and system for IoT data based on multi-dimensional value assessment and network state linkage; its core concept lies in constructing an "adaptive game model of two-way feedback between data value and network resources." This model achieves dynamic equilibrium through a two-way feedback closed loop.

[0016] Inner loop (data value assessment loop): At the data access end, the inherent "necessity of evidence storage" of each piece of IoT data is quantified in real time through a multi-dimensional value scoring engine.

[0017] Outer ring (network status awareness ring): At the on-chain interaction end, the "resource scarcity" (i.e. congestion index) of the blockchain is perceived in real time through network status monitoring.

[0018] The two closed loops are linked by a dynamic threshold calculation module: the congestion index of the outer loop dynamically adjusts the evidence access "price" (threshold) of the inner loop, so that when network resources are scarce, only data with higher value can obtain on-chain evidence resources, thereby achieving the optimization of global cost and utility, realizing adaptive resource optimization and timely protection of key data.

[0019] In one embodiment, the operating status parameters of the blockchain network include the current transaction fee reference value, the historical average transaction fee reference value, the number of transactions to be packaged in the current transaction pool, and the transaction pool capacity.

[0020] Accordingly, for step S4, the periodic acquisition of the operating status parameters of the blockchain network and the calculation of the current congestion index based on the operating status parameters include:

[0021] Obtain the current transaction fee reference value and the historical average transaction fee reference value, and calculate the fee relative factor;

[0022] Obtain the number of transactions to be packaged in the current transaction pool and the capacity of the transaction pool, and calculate the transaction pool occupancy rate;

[0023] The relative cost factor and the transaction pool occupancy rate are weighted according to preset weights, and the weighted result is mapped to a preset range through pruning and scaling to obtain the current congestion index.

[0024] In one embodiment, in step S5, calculating the maximum speed evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index includes:

[0025] Based on the current congestion index, the rapid evidence storage threshold and the aggregated evidence storage threshold are calculated using a monotonically increasing nonlinear function, such that the higher the current congestion index, the higher at least one of the rapid evidence storage threshold and the aggregated evidence storage threshold.

[0026] Among them, the ultra-fast evidence storage threshold T fast and the aggregated evidence threshold T chain Satisfy the following formula:

[0027] T fast =min(V max , T base_fast · exp(k · C net ));

[0028] T chain = T base_chain · (1 + C net );

[0029] Among them, V max T represents the preset upper limit of the evidence value score. base_fast The basic threshold for ultra-fast evidence storage, T base_chain This represents the basic threshold for aggregated evidence storage, k represents the sensitivity parameter, and C... net This indicates the current congestion index.

[0030] Among them, the ultra-fast evidence storage threshold T is calculated. fast and the aggregated evidence threshold T chain Then, threshold consistency correction is performed to satisfy the ultra-fast evidence storage threshold T. fast Not less than the aggregated evidence storage threshold T chain ;

[0031] In practical implementation, it can be achieved through formula T. fast = max(T fast , T chain Perform threshold consistency correction, i.e., when T is calculated according to their respective formulas... fast <T chain , then T fast Adjusted to T chain To ensure the ultra-fast evidence storage threshold T fast Not less than the aggregated evidence storage threshold T chain To avoid channel semantic conflicts (e.g., the threshold for aggregated channels is higher than that for ultra-fast channels).

[0032] In one embodiment, in step S6: if the evidence preservation value score is less than the ultra-fast evidence preservation threshold and greater than or equal to the aggregated evidence preservation threshold, then routing the original data to the batch processing channel for blockchain evidence preservation includes:

[0033] If the evidence value score is less than the ultra-fast evidence storage threshold and greater than or equal to the aggregated evidence storage threshold, the original data is routed to the batch processing channel, a Merkle root hash is constructed for multiple data entries in the batch processing channel, and evidence is stored through a single blockchain transaction.

[0034] The batch processing channel triggers a blockchain notarization once when any of the following conditions are met:

[0035] The number of data entries in the current batch has reached the batch processing threshold dynamically calculated based on the current congestion index.

[0036] The current batch's waiting time has reached the maximum waiting time threshold dynamically calculated based on the current congestion index.

[0037] In one embodiment, the batch processing number threshold and the maximum waiting time threshold increase monotonically with the current congestion index, thereby increasing the batch processing scale to spread the cost of a single transaction in the event of network congestion.

[0038] In one embodiment, in step S3, the evidence value score is calculated using the following formula:

[0039] V(d) = α·Norm(P risk ) + β·Norm(P rarity ) + γ·Norm(P trust ) + δ·I biz

[0040] Where α, β, γ, and δ are configurable weight parameters, Norm(·) is the normalization function, and P risk P is the risk deviation index. rarity P is the scarcity index of the event. trust I is the device reputation weight index. biz This is the indicator for the service interruption.

[0041] In one embodiment, in step S2 above, the risk deviation index is calculated using the Z-Score method based on the mean and standard deviation within a sliding time window, including:

[0042] The measurement value x at time t t Let the mean value within the sliding time window be μ. t The standard deviation is σ t Then the risk deviation is |x t -μ t | / (σ t +ε), where ε is a preset minimum positive number.

[0043] In one embodiment, in step S2 above, the event scarcity index is based on the frequency f of the event type to which the target data belongs in historical data. type Calculated as 1 / (f) type + ε), where ε is a preset minimum positive number.

[0044] In one embodiment, in step S2 above, the device reputation weight index is dynamically updated based on the following rules:

[0045] For IoT devices whose historical data reporting consistency meets the preset standards, their corresponding device reputation weight value will be reduced.

[0046] For IoT devices in the initial access state, or IoT devices whose historical evidence verification has failed, increase their corresponding device reputation weight value.

[0047] In one embodiment, the method further includes an exception handling step:

[0048] a) When it fails to obtain the operating status parameters of the blockchain network, the most recent valid historical congestion index is used as the current congestion index; when it fails to obtain the parameters for a preset number of consecutive times, the congestion index is set to a preset conservative value.

[0049] b) When submitting a single transaction or batch processing transaction to the blockchain fails, a preset number of retries will be performed; if the retries still fail, the corresponding data will be downgraded to local storage and marked as pending blockchain status; after the network is restored, the pending blockchain status data will be re-initiated for blockchain notarization.

[0050] c) For raw data routed to a single transaction channel, when constructing a blockchain transaction, set the transaction fee parameter or transaction priority parameter to a preset strategy that is higher than the current recommended value to improve the packaging priority.

[0051] Secondly, embodiments of this application also propose an adaptive blockchain-based evidence storage system for Internet of Things (IoT) data, comprising:

[0052] The data access module is used to receive raw data from IoT devices;

[0053] The value assessment engine module is used to determine the risk deviation index, event scarcity index, equipment reputation weight index, and business interruption indication index of the raw data; and to calculate the evidence value score of the raw data based on at least two of the determined indicators.

[0054] The blockchain status monitoring module is used to periodically acquire the operating status parameters of the blockchain network and calculate the current congestion index based on the operating status parameters.

[0055] The threshold calculation module is used to calculate the ultra-fast evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index.

[0056] The dynamic routing control module is used to perform the following traffic splitting process on the original data based on the relationship between the evidence preservation value score and the ultra-fast evidence preservation threshold and the aggregated evidence preservation threshold:

[0057] If the business interruption indicator indicates that it belongs to the preset highest alarm level, then the constraint of the ultra-fast evidence storage threshold is ignored, and the evidence storage execution module routes the original data to a single transaction channel for blockchain evidence storage.

[0058] If the service interruption indicator does not indicate that it belongs to the preset highest alarm level, and the evidence preservation value score is greater than or equal to the ultra-fast evidence preservation threshold, the evidence preservation execution module will route the original data to the single transaction channel; if the evidence preservation value score is less than the ultra-fast evidence preservation threshold, but greater than or equal to the aggregated evidence preservation threshold, the evidence preservation execution module will route the original data to the batch processing channel for blockchain evidence preservation.

[0059] If the evidence preservation value score is less than the aggregated evidence preservation threshold, the evidence preservation execution module calculates the first hash value of the original data and stores the original data and its corresponding first hash value in the local data storage system. After reaching the preset archiving time period, all the first hash values ​​stored locally within the archiving time period are aggregated and calculated to generate a periodic aggregated hash value. A blockchain evidence preservation transaction is constructed, the transaction including at least the periodic aggregated hash value and metadata representing the archiving time period, and the transaction is submitted to the blockchain network to complete the evidence preservation.

[0060] Thirdly, embodiments of this application also propose a blockchain gateway device, comprising: a processor and a memory, wherein the processor is connected to the memory, the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the blockchain gateway device performs the method as described in the first aspect.

[0061] Fourthly, embodiments of this application also propose a computer program product, including an IoT data adaptive blockchain evidence storage program, which, when run by a blockchain gateway device, causes the steps of the IoT data adaptive blockchain evidence storage method as described in the first aspect to be executed.

[0062] Compared with existing full-scale on-chain or static batch processing solutions, this invention achieves the following significant beneficial effects by introducing an adaptive evidence storage game model based on multi-dimensional value assessment and network state linkage:

[0063] Significantly reduce overall evidence storage costs: Fine-grained value differentiation of massive IoT data is achieved through evidence storage value scoring V(d), combined with network congestion index C. net Dynamically increasing admission threshold T fast and T chain This redirects the vast majority of low-value, routine data to lower-cost batch processing or local archiving channels. This effectively filters out unnecessary single-transaction on-chain requests, significantly reducing on-chain transaction fees (Gas) and storage overhead while ensuring the credibility of core data.

[0064] Ensuring real-time ownership confirmation of critical data: For data with the highest business alarm level (L_max), a threshold bypass mechanism was designed, allowing it to bypass dynamic threshold restrictions and directly enter the high-speed channel. By setting higher priority for transactions in this channel (such as increasing the Gas Price), it is ensured that data crucial to system security and business continuity can be on-chain and stored within the next block cycle, regardless of the state of the blockchain network. This solves the "risk lag" problem of delayed response to critical data in static batch processing solutions.

[0065] A continuously adjustable multi-level evidence storage system was constructed: An innovative three-level evidence storage path was designed, comprising ultra-fast single-transaction on-chain storage, batch aggregated on-chain storage, and local archiving plus periodic summary on-chain storage. This system forms a continuous spectrum between "high cost-strong trust" and "low cost-weak trust," enabling the system to flexibly and accurately configure evidence storage resources according to the differentiated needs of different data values ​​and business scenarios, achieving an optimal engineering balance between cost and trustworthiness.

[0066] Intelligent control that enables network state adaptation: quantifying the real-time load state of the blockchain network as a congestion index C. net This information is used as the core feedback signal to dynamically adjust the evidence storage threshold and batch processing parameters. This forms an adaptive control closed loop of "perception-decision-execution," enabling the system to automatically adapt to changes in network congestion: lowering the threshold and increasing the granularity of evidence storage when idle; and raising the threshold, aggregating data, and distributing costs when congested, thereby improving the overall throughput and stability of the system under different network environments.

[0067] Enhancing the system's high availability and fault tolerance: A robust anomaly handling mechanism has been designed, including conservative rollback when network state acquisition fails, limited retries and downgraded archiving when transaction submission fails, and subsequent automatic chain replenishment. These mechanisms ensure that data is not lost and system services are not interrupted during temporary blockchain network outages or anomalies, and automatically complete data consistency repair after network recovery, greatly improving the system's robustness and industrial availability. Attached Figure Description

[0068] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0069] Figure 1 The main flowchart of an adaptive blockchain evidence storage method for IoT data provided in this application;

[0070] Figure 2 A flowchart illustrating an embodiment of the adaptive blockchain-based IoT data notarization method provided in this application, involving the calculation of notarization value scores.

[0071] Figure 3 A structural block diagram of the IoT data adaptive blockchain evidence storage system provided in this application;

[0072] Figure 4 This is a schematic diagram of the structure of a blockchain gateway device according to an embodiment of this application. Detailed Implementation

[0073] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0074] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0075] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0076] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), unless otherwise expressly and specifically defined.

[0077] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0078] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0079] Understandably, in scenarios such as Industrial IoT (IIoT), smart cities, and smart grids, a large number of sensors, controllers, and edge gateways continuously generate high-frequency streaming data. Typical scenarios include:

[0080] High-frequency vibration sensors generate thousands of sampling points per second;

[0081] Video / image devices generate large volumes of data streams;

[0082] Various business statuses, heartbeats, and alarm logs are continuously reported.

[0083] To ensure the immutability and traceability of critical operational data, the industry generally considers storing the data or its hash value on a blockchain system (such as Ethereum, FISCO BCOS, and other consortium blockchains). However, on-chain throughput and storage space are limited, and write costs (such as transaction fees) fluctuate dynamically with network load, creating a fundamental contradiction between massive IoT data and limited on-chain resources.

[0084] The applicant of this invention has found that existing typical solutions mainly include the following two categories:

[0085] Existing Solution 1: Full On-Chain Mode, which mainly involves directly writing all collected data (or its hash) into the blockchain as transactions; its technical drawbacks are that in public chains or congested consortium chain environments, the writing cost increases almost linearly with the amount of data; a large amount of low-value, repetitive routine data (such as device heartbeats) consumes block space and transaction pool resources; when the network is congested, high-priority alarm data may not be uploaded to the chain in time due to queuing delays; and the operating costs are uncontrollable, forming a "cost black hole".

[0086] Existing Solution 2: Static sampling / batch processing mode, which mainly involves packaging several data entries into a Merkle Root and uploading them to the blockchain according to a fixed time window (e.g., every 10 minutes) or a quantity threshold (e.g., every 100 entries). Its technical drawback lies in the delayed response to sudden high-risk events: when the window has not yet been triggered, high-risk alarm data remains in the local buffer; if a power outage or network failure occurs during the window, critical evidence data that should be promptly solidified is at risk of being lost; the batch processing parameters are fixed and cannot be dynamically adjusted according to the network status, resulting in "risk lag".

[0087] In summary, the existing solutions have the following shortcomings:

[0088] Lack of data value differentiation mechanism: failure to quantify value based on the multidimensional characteristics of the data itself, resulting in high-value data and low-value data using the same evidence preservation strategy;

[0089] Lack of network state awareness: The real-time load status of the blockchain network is not incorporated into the decision-making logic, making it impossible to dynamically adapt the evidence storage strategy to network conditions.

[0090] Lack of a multi-level evidence storage system: There is no continuous and adjustable intermediate state between "full on-chain" and "no on-chain at all", making it difficult to achieve an engineering balance between cost and credibility.

[0091] Lack of critical data protection mechanisms: There is a lack of dedicated fast channels for the highest business priority data, making it impossible to guarantee real-time ownership confirmation under any network conditions.

[0092] To address the above-mentioned technical deficiencies, this application will now illustrate its technical solutions through specific embodiments.

[0093] Example 1

[0094] Firstly, such as Figure 1 As shown, this application provides a method for controlling the storage of IoT data. The method is executed by a blockchain gateway device connected to a blockchain network and mainly includes the following steps S1 to S6:

[0095] Step S1: Receive raw data from IoT devices;

[0096] Step S2: Determine the risk deviation index, event scarcity index, device reputation weight index, and service interruption indication index of the original data; wherein, the risk deviation index represents the risk deviation of the original data relative to the statistical characteristics of historical time windows; the event scarcity index represents the frequency of occurrence of the event type to which the original data belongs within a preset historical statistical period; the device reputation weight index represents the weight of the reputation of the IoT device that generated the original data; and the service interruption indication index represents the service interruption indication corresponding to the service alarm level of the original data.

[0097] Step S3: Calculate the evidentiary value score of the original data based on at least two of the risk deviation index, the event scarcity index, the equipment reputation weight index, and the service interruption indication index;

[0098] Step S4: Periodically acquire the operating status parameters of the blockchain network, and calculate the current congestion index based on the operating status parameters;

[0099] Step S5: Calculate the maximum speed evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index;

[0100] Step S6: Based on the relationship between the evidence preservation value score and the rapid evidence preservation threshold and the aggregated evidence preservation threshold, the original data is processed as follows:

[0101] If the business interruption indicator indicates that it belongs to the preset highest alarm level, then the constraint of the ultra-fast evidence storage threshold is ignored, and the original data is routed to a single transaction channel for blockchain evidence storage.

[0102] If the service interruption indicator does not indicate that it belongs to the preset highest alarm level, and the evidence value score is greater than or equal to the ultra-fast evidence storage threshold, then the original data is routed to the single transaction channel; if the evidence value score is less than the ultra-fast evidence storage threshold, but greater than or equal to the aggregated evidence storage threshold, then the original data is routed to the batch processing channel for blockchain evidence storage.

[0103] If the evidence preservation value score is less than the aggregated evidence preservation threshold, calculate the first hash value of the original data, and store the original data and its corresponding first hash value in the local data storage system; after reaching the preset archiving time period, perform a summary calculation on all the first hash values ​​stored locally within the archiving time period to generate a periodic summary hash value; construct a blockchain evidence preservation transaction, the transaction including at least the periodic summary hash value and metadata representing the archiving time period, and submit the transaction to the blockchain network to complete the evidence preservation.

[0104] For ease of understanding, the following explains some key terms in this embodiment:

[0105] Internet of Things (IoT) devices are physical entities capable of sensing, collecting, executing, and interacting with other devices or systems, such as sensors, controllers, and smart terminals. These devices typically generate large amounts of raw data continuously.

[0106] A blockchain gateway device is an intermediary device that connects an IoT network and a blockchain network. Its main function is to receive raw data from IoT devices, process the data according to preset strategies, and finally store the qualified data or its summary information on the blockchain.

[0107] Raw data, also known as IoT data or data awaiting verification, refers to unprocessed initial data directly generated or collected by IoT devices, such as temperature readings, pressure values, vibration frequencies, and device status logs. Each piece of raw data may contain information such as device ID, timestamp, numerical value, and event type.

[0108] The risk deviation index characterizes the degree of anomalousness of raw data relative to its historical statistical characteristics. This index quantifies the extent to which the current data point deviates from the normal data pattern over a period of time; a greater deviation usually indicates that the data has higher risk or anomalous value.

[0109] The event scarcity index represents the frequency of occurrence of the event type in the original data within a preset historical statistical period. This index is used to measure the rarity of an event; events with lower occurrence frequencies are generally considered to have higher informational value or priority for evidence preservation.

[0110] The device reputation weight index characterizes the reputation level of the IoT devices that generate the raw data. This weight can be dynamically adjusted based on factors such as the consistency of historical data reporting and the results of evidence verification, and is used to differentiate the evidence storage strategies of devices with different levels of trustworthiness.

[0111] The business interruption indicator represents the business alarm level corresponding to the raw data. This indicator is directly related to the business importance of the data. For example, the highest level business alarm may indicate a major security incident or business interruption risk, requiring the highest priority handling.

[0112] The evidence preservation value score can be understood as a comprehensive quantitative score obtained after multi-dimensional evaluation of the original data. It is used to measure the necessity and priority of the data for blockchain evidence preservation. The higher the score, the more important the data is, and the more timely and reliable blockchain evidence preservation is required.

[0113] Blockchain networks are decentralized distributed ledger technologies that use cryptographic methods to ensure the immutability and traceability of data. In this embodiment, a blockchain network is used to store evidence of IoT data to ensure the integrity and authenticity of the data.

[0114] Operating status parameters can be understood as various indicators that reflect the current load and resource supply and demand of the blockchain network, such as current transaction fees, the number of transactions to be packaged in the transaction pool, and block generation speed.

[0115] The current congestion index can be understood as a normalized index calculated based on the operational parameters of the blockchain network, used to quantify the degree of network congestion. This index typically takes values ​​within a preset range, such as [0,1], where higher values ​​indicate greater network congestion. The preset range is the value range of the congestion index; for example, in the range [0,1], 0 represents an idle network, and 1 represents extreme congestion. The congestion index reflects the normalized load state of the blockchain network, taking values ​​within the range [0,1], where 0 represents extremely idle and 1 represents extremely congested. This index is calculated using on-chain operational parameters (such as gas price and transaction pool depth).

[0116] The ultra-fast data storage threshold can be understood as the minimum value score required for data to enter a single transaction channel. This threshold is dynamically adjusted based on the congestion index of the blockchain network; the more congested the network, the higher the threshold typically becomes, ensuring that only the highest-value data can be quickly stored through this channel.

[0117] The aggregated evidence storage threshold can be understood as the minimum evidence value score threshold for data to enter the batch processing channel. Similar to the ultra-fast evidence storage threshold, this threshold is also dynamically adjusted according to the network congestion index, and is used to control the admission conditions for medium and high value data to be stored in batch processing.

[0118] A single transaction channel can be understood as a storage path used to process high-value or high-priority data. Through this channel, each piece of data typically generates an independent blockchain transaction, and higher transaction fees may be paid to obtain priority packaging and faster confirmation.

[0119] Batch processing channels can be understood as evidence storage paths used to process medium- to high-value data. These channels aggregate multiple data entries, for example, by constructing a Merkle tree and writing its root hash as a single transaction to the blockchain, thereby distributing the cost of individual transactions and improving economic efficiency.

[0120] A local data storage system can be understood as a storage medium inside or connected to a blockchain gateway device, used for temporary or long-term storage of raw data with low evidentiary value scores.

[0121] A summary hash can be understood as a single hash value obtained by aggregating and calculating the hash values ​​of multiple original data items or their respective hash values ​​stored locally within a preset archiving time period. This summary hash can represent the integrity of all data within that archiving time period and is written to the blockchain to achieve low-cost, weak evidence storage.

[0122] It is understood that the IoT data adaptive blockchain notarization method provided in this embodiment mainly achieves adaptive selection of data notarization path through multi-dimensional value assessment and network status linkage.

[0123] First, in this embodiment, regarding the aforementioned step S1 "receiving raw data from an IoT device," the blockchain gateway device receives raw data from the IoT device. As an example, the IoT device could be a temperature sensor deployed in an industrial site, periodically sending temperature readings to the blockchain gateway device. The raw data can be received via standard network protocols. For instance, the blockchain gateway device can be configured with an HTTP interface, to which the IoT device sends data via an HTTP POST request; alternatively, the blockchain gateway device can act as a client of an MQTT broker server, subscribing to specific MQTT topics to receive data published by the IoT device.

[0124] Next, in this embodiment of the application, the risk deviation index, event scarcity index, device reputation weight index, and service interruption indication index of the blockchain gateway device acquiring the original data in the aforementioned step S2 are described.

[0125] As an example, the risk deviation index can be calculated using the Z-Score method based on the mean and standard deviation within a sliding time window, including:

[0126] The measurement value x at time t t Let the mean value within the sliding time window be μ. t The standard deviation is σ t Then the risk deviation is |x t -μ t | / (σ t +ε), where ε is a preset minimum positive number.

[0127] As an example, the event scarcity index is based on the frequency f of the event type to which the target data belongs in historical data. type Calculated as 1 / (f) type +ε), where ε is a preset minimum positive number.

[0128] As an example, the device reputation weight index is dynamically updated based on the following rules:

[0129] For IoT devices whose historical data reporting consistency meets preset standards, their corresponding device reputation weight value is reduced; for IoT devices in the initial access state, or those whose historical evidence verification has failed, their corresponding device reputation weight value is increased. It can be understood that for devices with a high long-term consistency rate between reported data and blockchain evidence data, the device reputation weight is reduced; for newly accessed devices or devices that have previously shown inconsistencies between their data and blockchain evidence data, the device reputation weight is increased.

[0130] Corresponding to the previous example, the risk deviation index can be obtained by comparing the currently received temperature reading with the fixed average temperature value over the past hour and calculating the absolute difference; the larger the difference, the higher the risk deviation. The event scarcity index can be obtained by querying a preset list of event types and finding the corresponding fixed scarcity value in that list based on the event type of the current data. The device reputation weight index can be obtained by maintaining a static device list within the blockchain gateway device, with each device assigned a preset reputation weight value; for example, newly connected devices may be given a higher initial weight. The service interruption indication index can be obtained by parsing specific fields in the raw data; for example, if the data contains the word "alarm," its service interruption indication index is set to a non-zero value.

[0131] Furthermore, in this embodiment of the application, for the aforementioned step S3, "calculate the evidence value score of the original data based on at least two of the above-mentioned risk deviation index, event scarcity index, equipment reputation weight index, and business interruption indication index," in a specific implementation, the risk deviation index and the event scarcity index can be selected, each normalized to the [0,1] interval, and then simply added together to obtain a preliminary evidence value score. Alternatively, the risk deviation index, event scarcity index, and equipment reputation weight index can be weighted and summed, where the weight parameters can be pre-configured according to business needs.

[0132] refer to Figure 2 As an example, this embodiment calculates the evidence value score using the following formula:

[0133] V(d) = α·Norm(P risk ) + β·Norm(P rarity ) + γ·Norm(P trust ) + δ·I biz

[0134] Where α, β, γ, and δ are configurable weight parameters, and Norm(·) is a normalization function. Norm(·) represents a function that normalizes each index so that the output is within a preset range (e.g., [0,1]).

[0135] Prisk is the risk deviation index, Prarity is the event scarcity index, Ptrust is the device reputation weight index, and Ibiz is the service interruption indicator. Each weight parameter satisfies the constraint: α + β + γ + δ = 1 (when I... biz (when it is a normalized value)

[0136] It should be noted that, among the four indicators mentioned above in the original data, if an indicator is not used, its corresponding weight parameter is 0.

[0137] The above formula provides a standardized, multi-dimensional method for calculating the evidence value score, effectively addressing the problems of lacking unified standards and being easily influenced by subjective factors in traditional data value assessments. This formula comprehensively considers risk deviation indicators, event scarcity indicators, device reputation weight indicators, and business interruption indication indicators, and performs normalization and weighting processing to ensure that each piece of IoT data receives an objective and quantifiable evidence value score. This not only improves the accuracy and consistency of data value assessment but also enhances the robustness of the entire evidence storage decision-making system. Furthermore, using this precisely quantified evidence value score V(d) as the core input in the IoT data adaptive blockchain evidence storage method allows for linkage with real-time operational parameters of the blockchain network (such as congestion index), enabling more intelligent and refined data diversion decisions. For example, during network congestion, the system can prioritize the timely storage of high-value data while batch processing or local storage of low-value data, thereby significantly optimizing the utilization efficiency of blockchain resources and reducing overall evidence storage costs while ensuring the credibility of key data. This data-value-based refined management enables the system to better adapt to the contradiction between the massive amount of data in the Internet of Things and the limited resources of blockchain, achieving an engineering balance between cost and credibility.

[0138] Furthermore, in this embodiment of the application, regarding the aforementioned step S4, "the blockchain gateway device periodically obtains the operating status parameters of the blockchain network and calculates the current congestion index based on these operating status parameters," as an example, the blockchain gateway device can query the blockchain node for the currently suggested transaction fee (Gas Price) every minute and compare this fee value with a preset maximum transaction fee, calculating a congestion index through a simple proportional relationship. Alternatively, the blockchain gateway device can also simply obtain the number of transactions to be packaged in the blockchain transaction pool and compare it with the fixed capacity of the transaction pool to calculate the transaction pool occupancy rate as the congestion index.

[0139] Furthermore, for step S4, in some special cases, such as when obtaining the operating status parameters of the blockchain network fails, the most recent valid historical congestion index value can be used as the current congestion index. It is understood that when real-time acquisition of the blockchain network operating status parameters fails, the system will retrieve and use the most recently successfully calculated and recorded congestion index value from its internal storage or cache. This historical value serves as a temporary alternative, ensuring the continuity and availability of congestion index data, thereby avoiding system decision interruptions due to missing real-time data. This historical congestion index value can be maintained and obtained in various ways. For example, the system can maintain a cache queue of historical congestion indices, retrieving the most recent valid value from the queue when needed; or, the system can persistently store the most recently successfully calculated congestion index locally and read this stored value when acquisition fails.

[0140] Furthermore, in this embodiment of the application, for the aforementioned step S5, "calculating the rapid evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index," as an example, a simple linear function can be used to calculate these two thresholds. That is, the rapid evidence storage threshold is equal to a base value plus the current congestion index multiplied by a fixed coefficient, and the aggregated evidence storage threshold is calculated in a similar way. Thus, when the congestion index increases, both thresholds will also increase linearly accordingly.

[0141] Finally, in this embodiment, regarding the aforementioned step S6, "based on the relationship between the evidence value score and the rapid evidence storage threshold and the aggregated evidence storage threshold, the original data is processed in a distributed manner," specifically, if the service interruption indicator indicates that it belongs to the preset highest alarm level (for example, the preset highest alarm level L_max can correspond to scenarios requiring immediate confirmation of rights, such as major safety accidents or personal injury), for example, an emergency security alarm, then the constraint of the rapid evidence storage threshold is ignored, and the original data is directly routed to the single transaction channel for blockchain evidence storage to ensure the highest priority processing. If the service interruption indicator does not indicate that it belongs to the preset highest alarm level, and the evidence value score is greater than or equal to the rapid evidence storage threshold, then the original data is routed to the single transaction channel. For example, a high-value device status change data, whose score reaches the rapid evidence storage threshold, is sent to the single transaction channel. If the evidence value score is less than the rapid evidence storage threshold but greater than or equal to the aggregated evidence storage threshold, for example, a medium-value device log data, then the original data is routed to the batch processing channel for blockchain evidence storage. Batch processing channels can be implemented by caching multiple data entries. When the preset number of data entries for batch processing is reached, the hash values ​​of these data entries are simply concatenated to calculate a total hash value, which is then written to the blockchain. If the evidence value score is less than the aggregated evidence threshold, for example, a regular heartbeat data entry, a "weak evidence" process is initiated: First, the blockchain gateway device calculates the first hash value of the original data entry (e.g., using the SHA-256 algorithm) and stores the original data entry and its first hash value together in a local data storage system (e.g., a local database or file system). During local storage, each data record should at least include the original data content, the first hash value, device identifier, timestamp, and other metadata.

[0142] After reaching a preset local archiving period (e.g., every 24 hours), the system triggers a periodic summary operation. The specific process is as follows: All original data records stored locally in a "weak evidence" manner within the archiving period are read, and the first hash value corresponding to each record is extracted. These first hash values ​​are arranged according to a preset rule (e.g., in ascending order by timestamp) and sequentially concatenated into a byte sequence. Then, the concatenated byte sequence is hashed again (e.g., using SHA-256) to generate a unique periodic summary hash value.

[0143] Subsequently, the system constructs a dedicated blockchain-based notarization transaction. This transaction's payload includes at least: 1) the calculated periodic summary hash value; and 2) metadata representing the summary period, such as the period start timestamp, period end timestamp, and the total number of original data entries within the archive period. This transaction, containing the periodic summary hash value and periodic metadata, is submitted to the blockchain network. Once the transaction is packaged and confirmed, it means that the overall integrity of all low-value original data within the archive period is weakly guaranteed by the blockchain.

[0144] When it is necessary to verify whether a specific piece of original data within an archived time period has been tampered with, the following steps can be performed: First, retrieve the original content of the data to be verified and its associated first hash value from the local storage system. Then, determine the period to which the data belongs based on its timestamp, and obtain the corresponding period's notarized transactions from the blockchain, extracting the period summary hash value and metadata (such as start and end times, total number of records) stored on the chain. Next, based on the time range determined by the metadata, extract the first hash values ​​of all original data records within the complete period from local storage, and rearrange and concatenate them according to the same sorting rules as during aggregation (such as timestamp ascending order). Perform the same hash operation on the concatenated hash sequence to obtain the locally reconstructed period summary hash value. Finally, compare the locally reconstructed period summary hash value with the period summary hash value obtained from the blockchain. If they match, it proves that the overall set of data within the archived time period has not been tampered with or is missing. Based on this, calculate the hash value of the current content of the original data to be verified and compare it with the first hash value stored in the local record. If they match, it proves that the specific data has not been tampered with since storage. This mechanism of "on-chain anchoring of periodic summaries and local maintenance of hash chains" provides auditable and verifiable anti-tampering protection for massive amounts of low-value data at extremely low cost, completing a technical closed loop.

[0145] In a practical implementation, the local data storage system can be a simple file system, storing each piece of original data as an independent file. The calculation of the aggregate hash can be done by simply concatenating the hash values ​​of all locally stored data within the archive time period in chronological order, and then performing a hash operation.

[0146] Furthermore, in other embodiments, when a blockchain evidence storage request for a single transaction channel or batch processing channel fails, the system triggers a retry mechanism: after the first failure, a retry is performed after a 1-second interval; if the retry fails after a total of 3 attempts, the data is downgraded to local archive storage and marked as "to be supplemented chain". After the blockchain network stabilizes, the system automatically scans the data of the chain to be supplemented and re-initiates the evidence storage request.

[0147] The technical advantages of this application's embodiments are as follows: By constructing an adaptive evidence storage system, it solves the problems of resource optimization and critical data protection in high-frequency, massive data scenarios of the Internet of Things; this application combines multi-dimensional data value assessment and network status awareness to dynamically adjust the evidence storage strategy and achieve multi-level processing of data diversion.

[0148] First, receiving raw data is the starting point of the method, ensuring that the input source is obtained from IoT devices;

[0149] Next, risk deviation index, event scarcity index, equipment reputation weight index, and business interruption indication index are obtained. These indicators quantify the degree of data anomaly, event rarity, equipment credibility, and business impact, respectively, providing a multi-dimensional foundation for value assessment. The risk deviation index, calculated based on historical time window statistical characteristics, accurately reflects the risk of data anomalies. The event scarcity index, calculated based on frequency within a preset historical statistical period, identifies the high value of rare events. The equipment reputation weight index assigns weights based on equipment credibility, distinguishing the data priority of equipment with different credibility levels. The business interruption indication index, based on business alarm level definitions, directly relates to business criticality. A notarization value score is calculated based on at least two of these indicators. By integrating multiple dimensions, the problem of a single rule being unable to quantify the necessity of data notarization is solved, ensuring that the assessment results comprehensively reflect the intrinsic value of the data.

[0150] The system periodically acquires operational status parameters and calculates the current congestion index based on these parameters. By using operational status parameters such as transaction fees and transaction pool depth, it can perceive changes in network load in real time, thus solving the problem that static strategies cannot adapt to dynamic environments.

[0151] The high-speed evidence storage threshold and the aggregated evidence storage threshold are calculated based on the current congestion index. The threshold adjustment is driven by the congestion index, which realizes the linkage between network status and evidence storage threshold, and ensures that the resource access price changes with scarcity.

[0152] Finally, data is processed by routing based on the relationship between the evidence value score and the threshold. Data with the highest preset alarm level is prioritized through a business interruption indicator, ignoring threshold constraints and routed to the single transaction channel, ensuring the absolute priority of critical data. For other data, routing is based on a score and threshold comparison to the single transaction channel, batch processing channel, or local storage. Local storage is followed by a summary hash calculation and on-chain storage, constructing a continuous system from high-cost real-time rights confirmation to low-cost, weak evidence storage, thus solving the problem of uneven resource allocation. In summary, the IoT data adaptive blockchain evidence storage method proposed in this application achieves adaptive resource optimization and timely protection of critical data through indicator-driven evaluation, state-aware thresholds, and intelligent routing.

[0153] Compared with existing full-scale on-chain or static batch processing solutions, this invention achieves the following significant beneficial effects by introducing an adaptive evidence storage game model based on multi-dimensional value assessment and network state linkage:

[0154] Significantly reduce overall evidence storage costs: Fine-grained value differentiation of massive IoT data is achieved through evidence storage value scoring V(d), combined with network congestion index C. net Dynamically increasing admission threshold T fast and T chain This redirects the vast majority of low-value, routine data to lower-cost batch processing or local archiving channels. This effectively filters out unnecessary single-transaction on-chain requests, significantly reducing on-chain transaction fees (Gas) and storage overhead while ensuring the credibility of core data.

[0155] Ensuring real-time ownership confirmation of critical data: For data with the highest business alarm level (L_max), a threshold bypass mechanism was designed, allowing it to bypass dynamic threshold restrictions and directly enter the high-speed channel. By setting higher priority for transactions in this channel (such as increasing the Gas Price), it is ensured that data crucial to system security and business continuity can be on-chain and stored within the next block cycle, regardless of the state of the blockchain network. This solves the "risk lag" problem of delayed response to critical data in static batch processing solutions.

[0156] A continuously adjustable multi-level evidence storage system was constructed: An innovative three-level evidence storage path was designed, comprising ultra-fast single-transaction on-chain storage, batch aggregated on-chain storage, and local archiving plus periodic summary on-chain storage. This system forms a continuous spectrum between "high cost-strong trust" and "low cost-weak trust," enabling the system to flexibly and accurately configure evidence storage resources according to the differentiated needs of different data values ​​and business scenarios, achieving an optimal engineering balance between cost and trustworthiness.

[0157] Intelligent control that enables network state adaptation: quantifying the real-time load state of the blockchain network as a congestion index C. net This information is used as the core feedback signal to dynamically adjust the evidence storage threshold and batch processing parameters. This forms an adaptive control closed loop of "perception-decision-execution," enabling the system to automatically adapt to changes in network congestion: lowering the threshold and increasing the granularity of evidence storage when idle; and raising the threshold, aggregating data, and distributing costs when congested, thereby improving the overall throughput and stability of the system under different network environments.

[0158] Enhancing the system's high availability and fault tolerance: A robust anomaly handling mechanism has been designed, including conservative rollback when network state acquisition fails, limited retries and downgraded archiving when transaction submission fails, and subsequent automatic chain replenishment. These mechanisms ensure that data is not lost and system services are not interrupted during temporary blockchain network outages or anomalies, and automatically complete data consistency repair after network recovery, greatly improving the system's robustness and industrial availability.

[0159] Example 2

[0160] Based on the first embodiment described above, this second embodiment provides a more detailed explanation of the above technical solution through a more specific example:

[0161] Imagine a smart manufacturing plant equipped with numerous IoT devices, including temperature sensors to monitor production line temperatures, vibration sensors to detect abnormal equipment vibrations, and safety alarm buttons for emergency shutdowns. These devices continuously generate massive amounts of data, which need to be stored on the blockchain to ensure the traceability and security of the production process. A blockchain gateway device is responsible for receiving this data and executing the storage methods.

[0162] For step S1 mentioned above, firstly, the blockchain gateway device continuously receives raw data from these IoT devices. For example, the temperature sensor reports temperature data once per second, the vibration sensor reports vibration data once per millisecond, and the safety alarm button immediately reports alarm data when triggered.

[0163] Regarding step S2 above, after receiving each piece of raw data, the blockchain gateway device will obtain its corresponding risk deviation index, event scarcity index, device reputation weight index, and service interruption indication index. Specifically:

[0164] For the routine temperature data reported by the temperature sensor, the temperature values ​​fluctuate within the historical normal range, so the risk deviation index is low; this type of data occurs frequently, so the event scarcity index is low; in addition, the temperature sensor has been operating stably for a long time, and the consistency of its historical data reporting meets the preset standards. Based on this historical record, the system dynamically reduces the corresponding device reputation weight value; and no alarms are triggered, so the business interruption indication index is zero.

[0165] For abnormal vibration data reported by vibration sensors, the vibration frequency or amplitude may suddenly exceed the historical normal range, so the risk deviation index is high; such abnormal vibration events are infrequent, so the event scarcity index is medium; in addition, the vibration sensor has a good reputation, and the consistency of its historical data reporting also meets the preset standards, so the system dynamically reduces its corresponding device reputation weight value accordingly; the highest level alarm was not directly triggered, and the service interruption indication index is a general alarm level.

[0166] Emergency shutdown data triggered by a safety alarm button indicates the highest risk to equipment or personal safety, hence the risk deviation index is extremely high; the event is extremely rare, hence the event scarcity index is extremely high; in addition, the safety alarm button device has extremely high credibility, with an extremely high historical evidence verification pass rate, and the system dynamically reduces its corresponding device credibility weight value based on this historical performance; most importantly, its business interruption indication index is set to the preset highest alarm level.

[0167] Next, in step S3, the blockchain gateway device calculates the evidentiary value score for each piece of raw data based on these indicators. For example, for regular temperature data, the evidentiary value score will be very low because all indicators are low. For abnormal vibration data, the evidentiary value score will be at a medium level because the risk deviation index and event scarcity index are high. For emergency shutdown data, although the business interruption indication index will give it a high score, the specific score will no longer be a decisive factor due to the subsequent bypass mechanism.

[0168] Meanwhile, in step S4 mentioned above, the blockchain gateway device periodically acquires the operating status parameters of the blockchain network, such as the current transaction fee and the number of transactions waiting to be packaged in the transaction pool. Based on these parameters, the current congestion index is calculated. For example, if the current transaction fee is high and a large number of transactions are backed up in the transaction pool, the calculated current congestion index will be high, indicating that the network is in a congested state.

[0169] Furthermore, regarding step S5 mentioned above, the blockchain gateway device can dynamically calculate the ultra-fast data storage threshold and the aggregated data storage threshold based on the calculated current congestion index. For example, when the network congestion index is high, these two thresholds will be increased accordingly, meaning that only data of higher value can be stored through a single transaction channel or a batch processing channel.

[0170] Finally, for the aforementioned step S6, the original data is processed by splitting it according to the evidence value score, business interruption indicator, and dynamic threshold for each data point:

[0171] S61: When receiving routine temperature data, its evidentiary value score is lower than the current aggregated evidentiary threshold. In this case, the data is only stored in the local data storage system of the blockchain gateway device. At the end of a preset archiving period, such as early morning each day, the system calculates the aggregated hash of all locally stored temperature data within that archiving period and writes this aggregated hash to the blockchain to complete the evidentiary process. Thus, a large amount of low-value routine data avoids high on-chain costs, while verifiability is preserved through the aggregated hash.

[0172] S62: When abnormal vibration data is received, its evidentiary value score falls between the aggregated evidentiary threshold and the ultra-fast evidentiary threshold. At this point, the data is routed to the batch processing channel. The batch processing channel caches multiple similar medium-value data entries and, after meeting certain conditions (such as reaching a preset number of data entries or a waiting time), aggregates the hash values ​​of these data entries into a Merkle root hash, and writes this root hash to the blockchain through a single blockchain transaction. This method distributes the cost of a single transaction, achieving economical evidentiary storage.

[0173] S63: When emergency shutdown data triggered by a security alarm button is received, its service interruption indicator shows that it belongs to the preset highest alarm level. At this time, regardless of how high the current ultra-fast evidence storage threshold is, the data will ignore the threshold constraint and be directly routed to the single transaction channel. The blockchain gateway device will immediately construct an independent blockchain transaction for this data and may set a higher transaction fee to ensure that it is prioritized for packaging, thereby completing blockchain evidence storage in the shortest possible time and ensuring real-time confirmation of rights for critical business operations.

[0174] Through the above examples, the method of this embodiment can intelligently select the most suitable evidence storage path based on the actual value of the data and the real-time status of the blockchain network, achieving a dynamic balance between cost and credibility.

[0175] Traditional full-data-on-chain methods write all data directly to the blockchain, regardless of its value. In the smart manufacturing factory example mentioned above, if a full-data-on-chain model were adopted, a large amount of routine temperature and vibration data would directly consume expensive on-chain resources, leading to a sharp increase in operating costs and creating a "cost black hole." However, this application's embodiment introduces a multi-dimensional value assessment model to assign low-value scores to routine temperature data and divert it to a local archiving channel, using only periodic aggregated hashing for weak evidence storage, significantly reducing the overall on-chain writing cost.

[0176] Existing static sampling or batch processing modes package data onto the blockchain according to fixed time windows or quantity thresholds. In the example above of this application, if a static batch processing mode is used, when abnormal vibration data or emergency shutdown data is generated, it may remain in the local buffer because it has not met the fixed batch processing conditions, resulting in delayed response to sudden high-risk events and failure to confirm ownership in a timely manner. This embodiment, however, ensures that abnormal vibration data can enter the batch processing channel and emergency shutdown data can unconditionally enter the single transaction channel through dynamic thresholds and a service interruption indication bypass mechanism. Even when the network is congested, the transaction priority parameter can be increased to ensure that key data is packaged and uploaded to the blockchain as early as possible, thereby providing strong real-time ownership confirmation protection and avoiding the "risk lag" problem.

[0177] Furthermore, existing solutions generally lack data value differentiation mechanisms and network status awareness capabilities, as well as multi-level evidence storage systems. This application's embodiment quantifies data value with fine granularity through risk deviation indicators, event scarcity indicators, equipment reputation weight indicators, and business interruption indication indicators. It also calculates a congestion index based on blockchain network operating status parameters, dynamically adjusting the ultra-fast evidence storage threshold and the aggregated evidence storage threshold. This constructs a three-level evidence storage system: "ultra-fast single-transaction on-chain—batch aggregated on-chain—local archiving + periodic summary on-chain." In the example above, this system can adaptively select the most suitable evidence storage path based on the different values ​​of regular temperature data, abnormal vibration data, and emergency shutdown data, as well as network congestion conditions. This achieves a continuously adjustable space between credibility and cost, meeting the differentiated needs of different business scenarios for evidence storage strength. This embodiment introduces an adaptive control closed loop with network status feedback, avoiding the problem of "on-chain state change—manual parameter tuning—strategy lag" in traditional strategies, and improving the system's stability and throughput in complex network environments.

[0178] Example 3

[0179] In some of the aforementioned embodiments of this application, for steps S4 and S5, it is proposed to calculate the current congestion index based on the operating status parameters of the blockchain network in order to dynamically adjust the evidence storage threshold.

[0180] As a specific implementation method, the operating status parameters of the blockchain network in this embodiment may include the current transaction fee reference value, the historical average transaction fee reference value, the number of transactions to be packaged in the current transaction pool, and the transaction pool capacity.

[0181] Accordingly, step S4 may further include:

[0182] S41: Obtain the current reference value of transaction fees and the historical average reference value of transaction fees, and calculate the relative fee factor;

[0183] S42: Obtain the number of transactions to be packaged in the current transaction pool and the transaction pool capacity, and calculate the transaction pool utilization rate;

[0184] S43: Weight the relative cost factor and the transaction pool occupancy rate according to the preset weights, and map the weighted result to a preset range (e.g., the preset range [0,1]) through cropping and scaling to obtain the current congestion index.

[0185] It is understandable that the operational parameters of a blockchain network include the current transaction fee reference value, the historical average transaction fee reference value, the number of transactions awaiting packaging in the current transaction pool, and the transaction pool capacity. The current transaction fee reference value refers to the real-time estimate of the unit price or total cost required to perform a transaction in the blockchain network at the current moment. This value is typically dynamically adjusted by validators in the network based on the current network load and transaction priority, reflecting the immediate cost of packaging a transaction onto the chain. It can be obtained by querying in real-time through API interfaces provided by blockchain nodes (such as Ethereum's `eth_gasPrice` or consortium blockchains' `getTxFee` interface), or by estimating by listening to transaction broadcast information in the network. The historical average transaction fee reference value refers to the average level of transaction fees in the blockchain network over a preset historical time window. This value provides a benchmark for assessing the relative level of current transaction fees. It can be obtained by statistically averaging transaction fee data over a past period (such as the most recent hour, day, or week), or by calculating using methods such as Exponentially Weighted Moving Average (EWMA). The current number of transactions awaiting packaging in the transaction pool refers to the number of transactions in the blockchain network waiting to be validated and packaged into a block. The transaction pool is a temporary storage area for all broadcast but unconfirmed transactions, and its size directly reflects the network's immediate processing pressure. This value can be obtained by querying the blockchain node's transaction pool status API (e.g., `txpool_status`). The transaction pool capacity refers to the maximum number of transactions or data that the blockchain network's transaction pool can hold. This value represents the upper limit of transactions the network can process per unit of time and is an important indicator of network processing capacity. The transaction pool capacity can be a fixed value preset by the blockchain protocol or an adjustable parameter configured by the node.

[0186] Specifically, this embodiment first periodically acquires the operating status parameters of the blockchain network. This step aims to continuously monitor the real-time status of the blockchain network and provide the latest data for subsequent congestion index calculation. Its purpose is to ensure that the congestion index can reflect changes in network status in a timely manner, thereby enabling the evidence storage strategy to respond quickly. This can be achieved by setting a scheduled task (e.g., every 10 seconds, 30 seconds, or 1 minute) to actively initiate a query request to the blockchain node, or by subscribing to the blockchain node's status update events, triggering parameter acquisition when a specific event occurs.

[0187] Further, for sub-step S41, after obtaining the current transaction cost reference value and the historical average transaction cost reference value, a cost relative factor is calculated. This step quantifies the deviation of the current transaction cost from the historical norm by comparing the current transaction cost with the historical average cost. Its function is to capture the real-time fluctuations in transaction costs and reflect the impact of network congestion on economic costs. The implementation method is usually to divide the current transaction cost reference value by the historical average transaction cost reference value to obtain a ratio, for example, `cost relative factor = current transaction cost reference value / (historical average transaction cost reference value + ε)`, where ε is a very small positive number used to avoid division by zero.

[0188] Simultaneously, for sub-step S42, after obtaining the number of transactions to be packaged in the current transaction pool and the transaction pool capacity, the transaction pool occupancy rate is calculated. This step quantifies the saturation level of network processing capacity by calculating the proportion of transactions waiting to be processed in the transaction pool. Its function is to directly reflect the physical pressure on network resources, i.e., how many transactions are queuing up for processing. The implementation method is usually to divide the number of transactions to be packaged in the current transaction pool by the transaction pool capacity to obtain a percentage or decimal, for example, `Transaction Pool Occupancy Rate = Number of Transactions to be Packaged in the Current Transaction Pool / Transaction Pool Capacity`.

[0189] Subsequently, in sub-step S43, the relative cost factor and the transaction pool occupancy rate are weighted according to preset weights. This step aims to comprehensively consider the impact of both transaction costs and network processing capacity on network congestion. Its purpose is to allow the system to flexibly adjust the importance of each indicator in the congestion index calculation based on actual business needs and sensitivity to different congestion factors. This can be achieved through linear weighting, for example, `weighted result = w1`. Cost relative factor + w2 The transaction pool occupancy rate is denoted by `w1` and `w2`, which are preset weight parameters and typically satisfy `w1 + w2 = 1`. Alternatively, a non-linear weighting function can be used to more precisely reflect the sensitivity of the indicator under different levels of congestion.

[0190] Finally, in this embodiment, the weighted result can be mapped to the preset interval [0,1] through pruning and scaling to obtain the current congestion index. This step aims to standardize the original congestion value obtained from the weighted calculation to a unified, bounded interval [0,1], making it an easily understood and subsequently processed indicator. Its purpose is to ensure that the numerical range of the congestion index is controllable, facilitating subsequent threshold calculation and decision-making logic. This can be achieved by using a function like `min(1,max(0, original weighted result / Cmax))` for pruning and scaling, where `Cmax` is a preset upper limit value used to linearly map the original weighted result to the [0,1] interval and ensure that the result does not exceed this range.

[0191] It can be understood that the above method constructs a quantitative indicator that accurately reflects the network congestion status by systematically integrating key operational parameters of the blockchain network. First, the system periodically obtains the current transaction fee reference value, the historical average transaction fee reference value, the number of transactions awaiting processing in the current transaction pool, and the transaction pool capacity from the blockchain network. These parameters characterize the real-time load of the network from two core dimensions: economic cost and resource consumption. Specifically, the comparison between the current transaction fee reference value and the historical average transaction fee reference value generates a relative fee factor, intuitively revealing abnormal fluctuations in current transaction costs and reflecting the market's demand for on-chain resources. Simultaneously, the ratio of the number of transactions awaiting processing in the current transaction pool to the transaction pool capacity calculates the transaction pool occupancy rate, directly quantifying the saturation level of the network's processing capacity—that is, how many transactions are queuing for processing. Subsequently, the system weights these two key factors according to preset weights, allowing the system to flexibly configure the emphasis on transaction cost sensitivity or processing capacity saturation based on the actual application scenario. For example, in scenarios highly sensitive to transaction costs, the relative fee factor can be given a higher weight. Finally, to ensure the standardization and comparability of the congestion index, the weighted result is cropped and scaled to uniformly map it to a preset interval (e.g., [0,1]), thus obtaining the current congestion index. This congestion index, as a unified and quantifiable indicator, can accurately and in real-time reflect the load status of the blockchain network, providing reliable input for subsequent adaptive evidence storage decisions and effectively solving the problem of insufficient adaptability of evidence storage strategies caused by ambiguous network state perception. In this way, the entire system can dynamically perceive the pulse of the blockchain network, ensuring that the optimal evidence storage path selection can be made under different network conditions.

[0192] As an example, the blockchain status monitoring module communicates with blockchain nodes using a publish / subscribe (Pub / Sub) model to obtain operational status parameters in real time; it also interfaces with the configuration center, supporting millisecond-level updates of threshold parameters. When network congestion suddenly changes, the configuration center can proactively push new basic threshold T for ultra-fast notarization. base_fast Parameters such as sensitivity parameter k are used to achieve dynamic adjustment of the threshold.

[0193] Specifically, the blockchain gateway device can deploy a blockchain status monitoring module, configured to send a query request to the connected blockchain nodes every 30 seconds. In each query, the module retrieves the current Gas price (as a reference value for current transaction fees) and the number of transactions awaiting packaging in the transaction pool by calling the blockchain node's API. Simultaneously, the module maintains a 24-hour Gas price sliding window and calculates the average Gas price within that window as a historical average transaction fee reference value. The transaction pool capacity can be a preset fixed value, such as 100,000 transactions. When calculating the congestion index, assuming the current Gas price is 50 Gwei and the historical average Gas price is 25 Gwei, the relative fee factor is 50 / 25 = 2. If the current number of transactions awaiting packaging in the transaction pool is 50,000 and the transaction pool capacity is 100,000, then the transaction pool occupancy rate is 50,000 / 100,000 = 0.5. The system can then weight these two factors according to preset weights. For example, if the preset weight w1 (relative cost factor) is 0.6 and w2 (trading pool utilization) is 0.4, then the weighted result is 0.6. 2 + 0.4 0.5 = 1.2 + 0.2 = 1.4. Finally, to map the weighted result to the [0,1] interval, a maximum congestion value Cmax can be set, for example, 2. Then, the current congestion index Cnet will be calculated using `min(1, max(0, 1.4 / 2))`, resulting in 0.7. This congestion index of 0.7 will serve as the basis for subsequently dynamically adjusting the ultra-fast evidence storage threshold and the aggregated evidence storage threshold. In this way, the system can perceive the congestion level of the blockchain network in real time and quantitatively, and adjust the evidence storage strategy accordingly.

[0194] The technical advantages of this embodiment are as follows: Through the above technical solution, this application provides a precise and operable quantification method, effectively solving the ambiguity problem in network state perception, thereby significantly improving the reliability of adaptive evidence storage decisions. Specifically, by clearly defining key operating state parameters such as the current transaction fee reference value, the historical average transaction fee reference value, the number of transactions to be packaged in the current transaction pool, and the transaction pool capacity, this application can directly capture the dynamics of resource supply and demand in the blockchain network, ensuring that the calculated congestion index is based on the real network load. The calculation of the relative cost factor can promptly identify real-time cost anomalies, avoiding the lag bias caused by static indicators, making the system more sensitive to cost fluctuations. The quantification of the transaction pool occupancy rate directly reveals the saturation of network processing capacity, providing a core basis for judging the degree of network congestion. By weighting these two factors, the system can flexibly balance cost sensitivity and capacity constraints according to the focus of different business scenarios, avoiding the limitations of a single indicator dominating decision-making. Finally, pruning and scaling ensure the standardization and controllability of the congestion index, enabling it to be stably and consistently applied to subsequent threshold calculations, thereby enhancing the robustness of the entire adaptive evidence storage system. This precise and multi-dimensional congestion index calculation mechanism enables the above method to more accurately judge the network condition, and then adjust the evidence storage strategy more reasonably. This ensures that high-value data can still be prioritized for on-chain storage when the network is congested, while low-value data can be processed in a more economical way, achieving an optimal balance between cost and efficiency.

[0195] Example 4

[0196] In some of the aforementioned embodiments of this application, regarding the calculation of the rapid evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index in step S5 to optimize the data diversion strategy, in this embodiment of the application, the calculation of the threshold can be optimized by the following embodiments to ensure that the threshold changes reasonably with the congestion index and improves resource allocation efficiency.

[0197] Accordingly, step S5 mentioned above may further include:

[0198] Based on the current congestion index, the rapid evidence storage threshold and the aggregated evidence storage threshold are calculated using a monotonically increasing nonlinear function, such that the higher the current congestion index, the higher at least one of the rapid evidence storage threshold and the aggregated evidence storage threshold.

[0199] Among them, the ultra-fast evidence storage threshold T fast and the aggregated evidence threshold T chain Satisfy the following formula:

[0200] T fast =min(V max , T base_fast · exp(k · Cnet ));

[0201] T chain = T base_chain · (1 + C net );

[0202] Among them, V max T represents the preset upper limit of the evidence value score. base_fast The basic threshold for ultra-fast evidence storage, T base_chain This represents the basic threshold for aggregated evidence storage, k represents the sensitivity parameter, and C... net This represents the current congestion index; in the specific implementation, it is necessary to ensure that T... fast ≥T chain Used to ensure the threshold T for ultra-fast evidence storage fast Always above the aggregated evidence threshold T chain To avoid data splitting logic conflicts.

[0203] It should be noted that the aforementioned monotonically increasing nonlinear function means that its output value increases as the input value increases, and this increase is not a simple linear proportion. Its purpose is to reflect the complex relationship between blockchain network congestion and data storage priority more precisely and flexibly. For example, when network congestion is low, the threshold may rise slowly; while when congestion reaches a certain level, the threshold may rise rapidly to quickly tighten the storage strategy. Implementation methods can include, but are not limited to, exponential functions, logarithmic functions, power functions, or piecewise functions.

[0204] The ultra-fast evidence storage threshold T in this embodiment fast and the aggregated evidence threshold T chain The formula defines the specific calculation method for the two thresholds mentioned above, ensuring that the thresholds can be calculated based on the current congestion index C. net Make dynamic adjustments. fast The exponential function approach aims to rapidly raise the threshold for ultra-fast data storage as network congestion worsens, prioritizing the on-chain storage of the most valuable data. chain By employing a linear function, the threshold for aggregated evidence storage increases smoothly with congestion levels, achieving a balance between cost and efficiency. max This is a pre-set maximum value, used to limit the theoretical upper limit of the evidence value score. At the ultra-fast evidence storage threshold T... fast In the calculation, the use of the min function ensures that T fast It will not exceed V max Even under extreme congestion, the threshold can be controlled within a reasonable range, preventing all data from being blocked from entering the high-speed channel due to an excessively high threshold, thus maintaining the availability and stability of the system. base_fast and Tbase_chain These are the baseline threshold values ​​for both rapid and aggregated evidence storage. As configurable parameters, they allow the system to set initial evidence storage thresholds under network idle or normal conditions, based on specific business needs and the characteristics of the blockchain network. These basic thresholds serve as the starting point for dynamic adjustment, providing a stable foundation for the entire adaptive mechanism. `k` is a sensitivity parameter used to adjust the rapid evidence storage threshold `T`. fast Regarding the current congestion index C net The response speed to changes. The larger the k value, the faster T... fast Follow C net The faster the increase in k, the more sensitive the system is to network congestion, and the more likely it is to rapidly raise the threshold for ultra-fast data entry during congestion. Conversely, the smaller the k value, the faster T... fast The more gradual the change, the better. The introduction of this parameter allows the system to flexibly adjust its sensitivity to network congestion based on the actual operating environment and policy requirements. net It is a normalized indicator reflecting the current load status of the blockchain network, and its value range is usually [0,1], where 0 represents extremely idle and 1 represents extremely congested. net As the core input variable for threshold calculation, it is obtained by periodically acquiring and calculating the operating status parameters of the blockchain network. It provides the system with the ability to perceive the network status in real time and is the key basis for realizing adaptive adjustment of the evidence storage strategy.

[0205] For example, the basic threshold T for ultra-fast evidence storage base_fast =100, sensitivity parameter k=2, the preset upper limit V of the evidence preservation value score max =1000. When the current congestion index C of the blockchain network... net When = 0.9, substituting into the formula yields:

[0206] T fast =min(V max , T base_fast · exp(k · C net = min(1000, 100 · exp(2 · 0.9) = min(1000, 100 × 6.05) = 605; At this point, the calculation result does not exceed V. max =1000 upper limit, which conforms to the formula constraint logic.

[0207] The IoT data adaptive blockchain notarization method of this application, after receiving raw data from IoT devices and obtaining their multi-dimensional indicators (including risk deviation index, event scarcity index, device reputation weight index, and business interruption indication index), calculates the notarization value score of the raw data based on these indicators. Simultaneously, the blockchain gateway device periodically acquires the operating status parameters of the blockchain network and calculates the current congestion index C based on these parameters. net To optimize subsequent data diversion processing, this application further proposes a method based on the current congestion index C. net Dynamically calculate the threshold T for ultra-fast evidence storage fast And aggregated evidence threshold T chain The specific method involves using a monotonically increasing nonlinear function to calculate these two thresholds, ensuring that when the current congestion index C... net The higher the threshold T, the faster the evidence storage threshold. fast And aggregated evidence threshold T chain At least one of these will also increase. Specifically, the ultra-fast evidence storage threshold T fast The calculation formula is T fast =min(V max , T base_fast · exp(k · C net This formula uses an exponential growth function `exp(k · C)`. net )`, making T fast In C net Growth is relatively slow at lower levels, but at C... net At higher levels, it can rapidly increase, thus quickly raising the threshold for entering a single transaction channel when network congestion worsens, prioritizing data with extremely high evidentiary value. Simultaneously, through `min(V`... max , T base_fast · exp(k · C net ))` operation, ensure T fast It will not exceed the preset upper limit of the evidence value score V. max This avoids the system becoming rigid due to an excessively high threshold. The sensitivity parameter k allows the system to adjust T according to actual needs. fast For C net Response speed to changes. Aggregate evidence storage threshold T chain The calculation formula is T chain = T base_chain · (1 + C net This formula uses a linear growth method, making T chain Follow C netThe increase is gradual and steady; this design aims to ensure that the aggregation channel can continue to be used effectively under moderate congestion levels, reducing costs through batch processing, while avoiding excessive tightening of the threshold that would prevent a large amount of medium-value data from being uploaded to the chain. base_fast and T base_chain As a basic threshold, an initial value threshold is set for the two evidence storage paths. Through the aforementioned dynamic calculation mechanism, the system can measure the real-time perceived blockchain network congestion state C. net This is transformed into a quantifiable, adaptive threshold for evidence preservation. When the network is idle, T... fast Tchain has a lower latency, allowing more data to enter single transaction channels or batch processing channels; however, when the network is congested, Tchain... fast and T chain This will correspondingly increase the efficiency, ensuring that only data with a higher evidence value score V(d) can be stored through the high-speed or aggregated channels, while lower-value data is routed to the local data storage system. This achieves dynamic adaptation of the evidence storage strategy to network conditions, effectively balancing evidence storage costs and data ownership confirmation efficiency. This dynamic adjustment mechanism, closely integrated with the basic evidence value scoring and data routing steps, together constructs an adaptive evidence storage system capable of making intelligent decisions based on data value and network status.

[0208] The technical effect of this embodiment is that, through the above technical solution, this application can further and effectively solve the problem that the threshold calculation lacks a specific optimization method, making it impossible to ensure that the threshold changes reasonably with the congestion index, resulting in low resource allocation efficiency. Specifically, the ultra-fast evidence storage threshold T is calculated using a monotonically increasing nonlinear function. fast And aggregated evidence threshold T chain This allows the threshold to more accurately reflect the real-time congestion status of the blockchain network. The ultra-fast evidence storage threshold T fast An exponential growth function is employed to ensure that the priority of uploading high-value data to the blockchain increases rapidly when network congestion intensifies, while a preset upper limit V is used. max This prevents the threshold from growing indefinitely, ensuring system stability and availability. Aggregate evidence storage threshold T chain By employing a linear growth approach, medium-value data can be batch-processed and stored more cost-effectively even during network congestion. This refined threshold calculation mechanism enables a more intelligent and adaptive data diversion strategy, thereby ensuring real-time ownership confirmation of critical data while effectively controlling overall storage costs and significantly improving the utilization efficiency of blockchain resources.

[0209] Example 5

[0210] Traditional IoT data storage methods route data with storage value scores between the ultra-fast storage threshold and the aggregate storage threshold to the batch processing channel for cost-optimized blockchain storage. However, in its implementation, the storage triggering mechanism of the batch processing channel lacks dynamic adjustment, which may lead to delayed storage or low cost efficiency in the batch processing channel. It is also unable to optimize the batch processing scale and waiting time in real time according to changes in the blockchain network status, thereby increasing the risk of loss of critical data or causing waste of resources.

[0211] In this embodiment, the step S6 in the aforementioned embodiment, "if the evidence value score is less than the ultra-fast evidence storage threshold and greater than or equal to the aggregated evidence storage threshold, then the original data is routed to the batch processing channel for blockchain evidence storage," further includes:

[0212] If the evidence value score is less than the ultra-fast evidence storage threshold and greater than or equal to the aggregated evidence storage threshold, the original data is routed to the batch processing channel, a Merkle root hash is constructed for multiple data entries in the batch processing channel, and evidence is stored through a single blockchain transaction.

[0213] The batch processing channel triggers a blockchain notarization once when any of the following conditions are met:

[0214] The number of data entries in the current batch has reached the batch processing threshold dynamically calculated based on the current congestion index.

[0215] The current batch's waiting time has reached the maximum waiting time threshold dynamically calculated based on the current congestion index.

[0216] Understandably, this embodiment describes a key conditional branch in the data routing decision. When the notarization value score V(d) of IoT data is at a medium level—meaning its value is insufficient for immediate single-transaction notarization via the high-cost high-speed channel, but higher than the threshold for low-value data stored locally—the system will direct it to the batch processing channel. The batch processing channel aims to distribute blockchain transaction costs by aggregating multiple data entries, thereby maximizing cost-effectiveness while ensuring a certain notarization timeliness. This routing mechanism ensures that data with different value densities can be matched with corresponding notarization strategies, avoiding delays for high-value data waiting for batch processing and avoiding unnecessary cost waste for medium-value data due to single-transaction on-chain processing.

[0217] This embodiment employs Merkle tree root hashing, a highly efficient data aggregation and integrity verification mechanism. In the batch processing channel, the system uses multiple collected raw data entries (or their hash values) as leaf nodes. By recursively calculating the hash values ​​of adjacent nodes, a unique root hash is generated. This root hash concisely represents the integrity of all data within the batch. By storing this root hash as evidence of a single blockchain transaction, on-chain storage space and transaction fees can be significantly reduced, because regardless of the number of data entries in the batch, only one root hash needs to be recorded on the chain. For example, hash algorithms such as SHA-256 or Keccak-256 can be used to calculate the hash value and construct the Merkle tree. Furthermore, when verifying the integrity of a specific data entry within the batch, only the hash value of that data and its path in the Merkle tree need to be provided. This allows for rapid verification by comparing it with the on-chain root hash, without needing to store all the raw data on the chain.

[0218] Furthermore, the batch processing channel triggers blockchain notarization once when any of the following conditions are met. This technical feature defines the triggering mechanism for the batch processing channel to package and submit cached data to the blockchain. Traditional batch processing often uses fixed time intervals or data volume thresholds, lacking awareness of the real-time status of the blockchain network. This embodiment introduces dynamic triggering conditions, enabling the batch processing process to adaptively adjust according to network congestion, thereby achieving a better balance between cost and timeliness. This dynamic triggering mechanism is a core component for realizing the adaptability of the notarization strategy, allowing the system to flexibly adjust its behavior according to changes in the external environment.

[0219] The current batch data count has reached the batch processing threshold dynamically calculated based on the current congestion index. The batch processing threshold refers to the upper limit of the amount of data that needs to be aggregated in a batch. When the number of data entries cached in the batch processing channel reaches or exceeds this dynamically calculated threshold, the system will immediately trigger a blockchain notarization. This threshold is not fixed but varies according to the current congestion index C of the blockchain network. net Dynamic adjustments can be made. For example, the threshold could be a piecewise function, where C... net When C is low, the threshold is small to speed up processing; when C is low... net When the load is high, a larger threshold is used to aggregate more data and spread the cost. This dynamic adjustment mechanism allows the system to flexibly optimize the batch processing size based on network load.

[0220] The current batch waiting time has reached the maximum waiting time threshold dynamically calculated based on the current congestion index. The maximum waiting time threshold refers to the longest time a batch of data can wait in the batch processing channel to be aggregated and uploaded to the blockchain. Even if the number of data entries in the batch has not yet reached the batch processing threshold, once the waiting time exceeds this dynamically calculated threshold, the system will forcibly trigger a blockchain notarization. This threshold is also based on the current congestion index C of the blockchain network. net Dynamic adjustments can be made. For example, the threshold could be a value related to C. net Functions that are positively correlated, when C net When C is low, the threshold is short to ensure timeliness; when C is low... net When the threshold is high, it can be appropriately extended to allow for more data aggregation. This mechanism effectively prevents data from waiting indefinitely in the batch processing channel, ensuring the timeliness of data notarization, especially for data that, although of moderate value, still needs to be notarized promptly.

[0221] The solution in this application adaptively routes IoT data to a batch processing channel and combines it with a dynamic triggering mechanism, achieving a balance between cost and timeliness in blockchain-based evidence storage. Specifically, when the blockchain gateway device receives raw data from the IoT device, it will determine the risk deviation index P of the data. risk Event scarcity index P rarity Equipment reputation weight index P trust and Business Interruption Indicator I biz At least two parameters are used to calculate the evidentiary value score V(d) of the original data. Simultaneously, the blockchain gateway device periodically acquires the operational status parameters of the blockchain network and calculates the current congestion index C based on these parameters. net According to the current congestion index C net The system will dynamically calculate the ultra-fast evidence storage threshold T. fast And aggregated evidence threshold T chain ;

[0222] When the evidence preservation value score V(d) of the original data is less than the ultra-fast evidence preservation threshold T fast And greater than or equal to the aggregated evidence storage threshold T chain At this point, the data is routed to the batch processing channel. In the batch processing channel, multiple data entries with moderate evidentiary value are cached. To efficiently store this data on the blockchain, the system utilizes Merkle tree technology to aggregate the hash values ​​of all data within the batch processing channel into a unique Merkle tree root hash. This root hash represents the integrity of all data within the batch and can be stored through a single blockchain transaction, thus significantly reducing on-chain storage and transaction costs.

[0223] The triggering of evidence storage in the batch processing channel is not fixed but highly adaptive. The system will adjust the triggering based on the current congestion index C. net The system dynamically calculates the batch processing count threshold and the maximum waiting time threshold. When the number of data entries cached in the batch processing channel reaches the dynamically calculated batch processing count threshold, or when the waiting time of the current batch of data in the channel reaches the dynamically calculated maximum waiting time threshold, the system triggers a blockchain notarization operation. This dynamic triggering mechanism allows the batch size and waiting time to be adjusted according to the real-time load of the blockchain network. For example, during network congestion, the batch processing count threshold and the maximum waiting time threshold may be increased to aggregate more data and further distribute transaction costs; while during network idle periods, these thresholds may be decreased to reduce batch size and waiting time, thereby accelerating data upload to the blockchain.

[0224] The technical advantage of this application embodiment lies in: by introducing a system based on the current congestion index C... net By dynamically calculating the batch processing threshold and maximum waiting time threshold, the system can flexibly adjust the batch processing scale and waiting time based on the real-time load of the blockchain network. When the network is congested, the system can increase the batch processing scale and aggregate more data, thereby effectively distributing the cost of a single transaction and reducing the overall notarization cost. When the network is idle, the system can reduce the batch processing scale or shorten the waiting time, accelerating the data upload speed and reducing the latency of data caching locally, ensuring the timely notarization of medium- and high-value data. This adaptive batch processing strategy significantly improves the cost-effectiveness and timeliness of blockchain notarization while ensuring data integrity and traceability, avoiding the resource waste or risk of critical data retention caused by fixed parameters, thus achieving a better engineering balance between cost and credibility.

[0225] Furthermore, the batch processing number threshold and maximum waiting time threshold proposed in the aforementioned technical solution of this embodiment are used to control the triggering conditions of the aggregation channel. However, in this process, when the network is congested, if these thresholds are not dynamically adjusted to increase with the congestion index, the batch processing scale cannot be effectively increased, resulting in the inability to distribute the cost of a single transaction and increasing the transaction cost burden.

[0226] In response, this application further proposes that the batch processing number threshold and the maximum waiting time threshold increase monotonically with the current congestion index, so that the batch processing scale can be increased to spread the cost of a single transaction when the network is congested.

[0227] The batch processing threshold defines the lower limit of the number of raw data entries that need to be accumulated in the aggregation channel. When the amount of cached data reaches or exceeds this threshold, the system can trigger a batch processing operation to package these data for blockchain storage. Its purpose is to ensure that the amount of data uploaded to the blockchain each time reaches a certain scale, thereby effectively distributing the fixed cost of a single transaction. This threshold can be a preset integer value, such as 50, 100, or more, and the specific value can be configured according to the cost and real-time requirements of the business scenario. The maximum waiting time threshold defines the maximum time that raw data in the aggregation channel must wait in the cache for batch processing. Even if the number of batch processing entries has not yet reached the preset threshold, once the waiting time reaches or exceeds this threshold, the system will forcibly trigger a batch processing operation. Its purpose is to prevent data from waiting indefinitely in the cache, ensuring data timeliness, especially when data traffic is low or the batch processing threshold is high. This threshold can be a preset time length, such as 30 seconds, 60 seconds, or 120 seconds, and the specific value can also be adjusted according to business needs. The current congestion index is a quantitative indicator of the real-time load status of a blockchain network, typically ranging from [0,1], where 0 indicates network idleness and 1 indicates extreme network congestion. It comprehensively reflects operational parameters such as transaction fees and the number of transactions awaiting packaging in the transaction pool. Monotonically increasing means that the batch processing threshold and the maximum waiting time threshold increase with the current congestion index, indicating a positive correlation between them. This relationship can be linear, exponential, or other non-linear functions, but the core is to ensure that these two thresholds increase accordingly when network congestion worsens. Increasing batch processing size means that when the network is congested, the system tends to package more data in a single blockchain transaction (by increasing the batch processing threshold) or allow data to wait longer in the cache to accumulate more data (by increasing the waiting time threshold). Both mechanisms aim to increase the amount of data processed in each batch, thus creating a larger batch processing scale. Amortizing the cost of a single transaction means that blockchain transactions typically include a fixed base fee and variable fees related to the amount of data. By increasing the scale of mass processing and aggregating multiple pieces of raw data (or their hashes) into a single blockchain transaction, the fixed base cost of this transaction can be spread across more raw data, thereby reducing the average cost of putting each piece of raw data on the blockchain.

[0228] Through the above-described embodiments, this application can dynamically adjust the batch processing strategy of the aggregation channel based on the real-time congestion status of the blockchain network. When the network is congested, by increasing the batch processing number threshold and the maximum waiting time threshold, the system can automatically increase the batch processing size for a single on-chain transaction, allowing more raw data to be aggregated into a single blockchain transaction. This significantly reduces the fixed cost of a single transaction, thereby effectively lowering the average cost of uploading each piece of raw data to the chain and optimizing the utilization efficiency of on-chain resources. This solution solves the problem of low cost-effectiveness of traditional fixed batch processing strategies during network congestion, achieving an adaptive balance between storage costs and network conditions, and ensuring that data storage can be performed in an economical and efficient manner under different network conditions.

[0229] Secondly, refer to Figure 3 This application also proposes an IoT data adaptive blockchain evidence storage system, including a data access module 01, a value assessment engine module 02, a blockchain status monitoring module 03, a threshold calculation module, a dynamic routing control module 05, and an evidence storage execution module 06.

[0230] Data access module 01 is used to receive raw data from IoT devices;

[0231] The value assessment engine module 02 is used to determine the risk deviation index, event scarcity index, equipment reputation weight index, and business interruption indication index of the original data; and to calculate the evidence value score of the original data based on at least two of the risk deviation index, event scarcity index, equipment reputation weight index, and business interruption indication index.

[0232] Blockchain status monitoring module 03 is used to periodically acquire the operating status parameters of the blockchain network and calculate the current congestion index based on the operating status parameters;

[0233] The threshold calculation module is used to calculate the ultra-fast evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index.

[0234] Dynamic routing control module 05 is used to perform the following traffic splitting process on the original data based on the relationship between the evidence preservation value score and the ultra-fast evidence preservation threshold and the aggregated evidence preservation threshold:

[0235] If the business interruption indicator indicates that it belongs to the preset highest alarm level, then the constraint of the ultra-fast evidence storage threshold is ignored, and the evidence storage execution module 06 routes the original data to a single transaction channel for blockchain evidence storage.

[0236] If the service interruption indicator does not indicate that it belongs to the preset highest alarm level, and the evidence preservation value score is greater than or equal to the ultra-fast evidence preservation threshold, the evidence preservation execution module 06 will route the original data to the single transaction channel; if the evidence preservation value score is less than the ultra-fast evidence preservation threshold, but greater than or equal to the aggregated evidence preservation threshold, the evidence preservation execution module 06 will route the original data to the batch processing channel for blockchain evidence preservation.

[0237] If the evidence preservation value score is less than the aggregated evidence preservation threshold, the evidence preservation execution module 06 calculates the first hash value of the original data and stores the original data and its corresponding first hash value in the local data storage system; after reaching the preset archiving time period, all the first hash values ​​stored locally within the archiving time period are aggregated and calculated to generate a periodic aggregated hash value; a blockchain evidence preservation transaction is constructed, the transaction including at least the periodic aggregated hash value and metadata representing the archiving time period, and the transaction is submitted to the blockchain network to complete the evidence preservation.

[0238] It is understood that the IoT data adaptive blockchain evidence storage system in this embodiment can be a computer application installed on a blockchain gateway device, or an integrated circuit chip.

[0239] It should be noted that the information interaction and execution process between the above-mentioned systems / modules are based on the same concept as the method embodiment of the first aspect of this application. For details on their specific functions and the resulting technical effects, please refer to the method embodiment section, which will not be repeated here.

[0240] Furthermore, this application also proposes a blockchain gateway device. Figure 4 This is a schematic diagram of the structure of a blockchain gateway device provided in one embodiment of this application. Figure 4 As shown, the blockchain gateway device 7 of this embodiment includes: at least one processor 70 ( Figure 4 (Only one is shown in the image) a processor, a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70, wherein the processor 70 executes the computer program 72 to implement the steps in any of the above embodiments of the evidence storage control method based on Internet of Things data.

[0241] It is understood that the blockchain gateway device in this embodiment accesses the blockchain network and is typically deployed between the IoT device and the blockchain network. It is responsible for receiving data from multi-source heterogeneous IoT devices and performing semantic normalization, idempotent control, and other processing.

[0242] For example, a blockchain gateway device can be an access node or client of a blockchain network, responsible for submitting the processed raw data (data to be stored) transmitted by IoT devices to the blockchain network for storage using the schemes S1 to S5 described in the first aspect. The gateway device does not directly write the raw data, but instead writes the processed data to be stored into the blockchain, ensuring the uniqueness and immutability of the data from IoT devices.

[0243] In one embodiment, the blockchain gateway device can be an electronic device such as a tablet computer, laptop, or PDA. The blockchain gateway device may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will understand that... Figure 4 This is merely an example of a blockchain gateway device and does not constitute a limitation on blockchain gateway devices. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components, such as input / output devices, network access devices, etc.

[0244] The processor 70 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0245] In some embodiments, the memory 71 may be an internal storage unit of the blockchain gateway device, such as a hard drive or memory of the blockchain gateway device. In other embodiments, the memory 71 may be an external storage device of the blockchain gateway device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the blockchain gateway device. Furthermore, the memory 71 may include both internal and external storage units of the blockchain gateway device. The memory 71 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 71 can also be used to temporarily store data that has been output or will be output.

[0246] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0247] This application also provides a computer program product, including an IoT data adaptive blockchain evidence storage execution program, which, when run, causes the steps of the IoT data adaptive blockchain evidence storage method as described in the first aspect to be executed.

[0248] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0249] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application, and should all be included within the protection scope of this application.

[0250] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0251] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0252] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0253] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0254] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application, and should all be included within the protection scope of this application.

Claims

1. A method for adaptive blockchain-based evidence storage of Internet of Things (IoT) data, characterized in that, The method is executed by a blockchain gateway device connected to the blockchain network and includes the following steps: Receive raw data from IoT devices; At least two indicators are determined corresponding to the raw data, including: a risk deviation indicator, an event scarcity indicator, a device reputation weight indicator, and a service interruption indication indicator; wherein, the risk deviation indicator represents the degree of deviation of the raw data from the statistical characteristics of a historical time window; the event scarcity indicator represents the frequency of occurrence of the event type to which the raw data belongs within a preset historical statistical period; the device reputation weight indicator represents the weight corresponding to the reputation level of the IoT device that generated the raw data; and the service interruption indication indicator represents the service alarm level corresponding to the raw data. The evidentiary value score of the original data is calculated based on at least two determined indicators; The operating status parameters of the blockchain network are periodically acquired, and the current congestion index is calculated based on the operating status parameters. Calculate the rapid evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index; Based on the relationship between the evidence preservation value score and the rapid evidence preservation threshold and the aggregated evidence preservation threshold, the original data is processed as follows: If the business interruption indicator indicates that it belongs to the preset highest alarm level, then the constraint of the ultra-fast evidence storage threshold is ignored, and the original data is routed to a single transaction channel for blockchain evidence storage. If the service interruption indicator does not indicate that it belongs to the preset highest alarm level, and the evidence value score is greater than or equal to the ultra-fast evidence storage threshold, then the original data is routed to the single transaction channel; if the evidence value score is less than the ultra-fast evidence storage threshold, but greater than or equal to the aggregated evidence storage threshold, then the original data is routed to the batch processing channel for blockchain evidence storage. If the evidence preservation value score is less than the aggregated evidence preservation threshold, calculate the first hash value of the original data, and store the original data and its corresponding first hash value in the local data storage system; after reaching the preset archiving time period, perform a summary calculation on all the first hash values ​​stored locally within the archiving time period to generate a periodic summary hash value; construct a blockchain evidence preservation transaction, the transaction including at least the periodic summary hash value and metadata representing the archiving time period, and submit the transaction to the blockchain network to complete the evidence preservation.

2. The method as described in claim 1, characterized in that, The operating status parameters of the blockchain network include the current transaction fee reference value, the historical average transaction fee reference value, the number of transactions to be packaged in the current transaction pool, and the transaction pool capacity. The calculation of the current congestion index based on the operating status parameters includes: Obtain the current transaction fee reference value and the historical average transaction fee reference value, and calculate the fee relative factor; Obtain the number of transactions to be packaged in the current transaction pool and the capacity of the transaction pool, and calculate the transaction pool occupancy rate; The relative cost factor and the transaction pool occupancy rate are weighted according to preset weights, and the weighted result is mapped to a preset range through pruning and scaling to obtain the current congestion index.

3. The method as described in claim 1, characterized in that, The calculation of the ultra-fast evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index includes: Based on the current congestion index, the rapid evidence storage threshold and the aggregated evidence storage threshold are calculated using a monotonically increasing nonlinear function, such that the higher the current congestion index, the higher at least one of the rapid evidence storage threshold and the aggregated evidence storage threshold. Among them, the ultra-fast evidence storage threshold T fast and the aggregated evidence threshold T chain Satisfy the following formula: T fast =min(V max , T base_fast · exp(k · C net )); T chain = T base_chain · (1 + C net ); Among them, V max T represents the preset upper limit of the evidence value score. base_fast The basic threshold for ultra-fast evidence storage, T base_chain This represents the basic threshold for aggregated evidence storage, k represents the sensitivity parameter, and C... net This indicates the current congestion index.

4. The method as described in claim 3, characterized in that, The ultra-fast evidence storage threshold T is calculated. fast and the aggregated evidence threshold T chain Then, threshold consistency correction is performed to satisfy the ultra-fast evidence storage threshold T. fast Not less than the aggregated evidence storage threshold T chain .

5. The method as described in claim 1, characterized in that, If the evidence preservation value score is less than the ultra-fast evidence preservation threshold and greater than or equal to the aggregated evidence preservation threshold, then the original data is routed to the batch processing channel for blockchain evidence preservation, including: If the evidence value score is less than the ultra-fast evidence storage threshold and greater than or equal to the aggregated evidence storage threshold, the original data is routed to the batch processing channel, a Merkle root hash is constructed for multiple data entries in the batch processing channel, and evidence is stored through a single blockchain transaction. The batch processing channel triggers a blockchain notarization once when any of the following conditions are met: The number of data entries in the current batch has reached the batch processing threshold dynamically calculated based on the current congestion index. The current batch waiting time has reached the maximum waiting time threshold dynamically calculated based on the current congestion index; wherein, the batch processing number threshold and the maximum waiting time threshold increase monotonically with the current congestion index, so that the batch processing scale can be increased to spread the cost of a single transaction in the event of network congestion.

6. The method according to any one of claims 1 to 5, characterized in that, The evidence value score is calculated using the following formula: V(d) = α·Norm(P risk ) + β·Norm(P rarity ) + γ·Norm(P trust ) + δ·I biz Where α, β, γ, and δ are configurable weight parameters, Norm(·) is the normalization function, and P risk P is the risk deviation index. rarity P is the scarcity index of the event. trust I is the device reputation weight index. biz This is the indicator for the service interruption.

7. The method according to any one of claims 1 to 5, characterized in that, It also includes exception handling steps: a) When it fails to obtain the operating status parameters of the blockchain network, the most recent valid historical congestion index is used as the current congestion index; when it fails to obtain the parameters for a preset number of consecutive times, the congestion index is set to a preset conservative value. b) When submitting a single transaction or batch processing transaction to the blockchain fails, a preset number of retries will be performed; if the retries still fail, the corresponding data will be downgraded to local storage and marked as pending blockchain status. After the network is restored, re-initiate blockchain notarization of the pending chain status data; c) For raw data routed to a single transaction channel, when constructing a blockchain transaction, set the transaction fee parameter or transaction priority parameter to a preset strategy that is higher than the current recommended value to improve the packaging priority.

8. An adaptive blockchain-based data storage system for the Internet of Things (IoT), characterized in that, include: The data access module is used to receive raw data from IoT devices; The value assessment engine module is used to determine the risk deviation index, event scarcity index, equipment reputation weight index, and business interruption indication index of the raw data. The evidentiary value score of the original data is calculated based on at least two of the risk deviation index, the event scarcity index, the equipment reputation weight index, and the business interruption indication index. The blockchain status monitoring module is used to periodically acquire the operating status parameters of the blockchain network and calculate the current congestion index based on the operating status parameters. The threshold calculation module is used to calculate the ultra-fast evidence storage threshold and the aggregated evidence storage threshold based on the current congestion index. The dynamic routing control module is used to perform the following traffic splitting process on the original data based on the relationship between the evidence preservation value score and the ultra-fast evidence preservation threshold and the aggregated evidence preservation threshold: If the business interruption indicator indicates that it belongs to the preset highest alarm level, then the constraint of the ultra-fast evidence storage threshold is ignored, and the evidence storage execution module routes the original data to a single transaction channel for blockchain evidence storage. If the business interruption indicator does not indicate that it belongs to the preset highest alarm level, and the evidence preservation value score is greater than or equal to the ultra-fast evidence preservation threshold, the evidence preservation execution module will route the original data to the single transaction channel. If the evidence value score is less than the ultra-fast evidence storage threshold and greater than or equal to the aggregated evidence storage threshold, the evidence storage execution module will route the original data to the batch processing channel for blockchain evidence storage. If the evidence preservation value score is less than the aggregated evidence preservation threshold, the evidence preservation execution module calculates the first hash value of the original data and stores the original data and its corresponding first hash value in the local data storage system. After the preset archiving time period is reached, all the first hash values ​​stored locally within the archiving time period are aggregated and calculated to generate a periodic aggregated hash value. Construct a blockchain notarization transaction, the transaction including at least the periodic summary hash value and metadata representing the archiving time period, and submit the transaction to the blockchain network to complete the notarization.

9. A blockchain gateway device, characterized in that, include: A processor and a memory, the processor being connected to the memory for storing a computer program, the processor being configured to execute the computer program stored in the memory to cause the blockchain gateway device to perform the method as described in any one of claims 1 to 7.

10. A computer program product, comprising an Internet of Things (IoT) data adaptive blockchain evidence storage program, characterized in that, When the IoT data adaptive blockchain evidence storage program is run by the blockchain gateway device, the steps of the IoT data adaptive blockchain evidence storage method as described in any one of claims 1 to 7 are executed.

Images