Data tracing and operation regulation method and system based on blockchain storage

Abstract

This invention discloses a data traceability and operation control method and system based on blockchain-based evidence storage. The method involves monitoring local data streams at various edge devices in an industrial site to determine data stream characteristic parameters; setting data upload logic for all edge devices based on these parameters; generating a dual-format data queue based on the data upload logic and cloud operation status parameters; performing local retention and blockchain upload on the dual-format data queues to form an associated local cache queue and blockchain evidence storage queue; identifying data interruption characteristics of the blockchain evidence storage queue based on network link quality parameters, and dynamically tracing these interruptions in the local cache queue to obtain supplementary data segments; and adjusting the cloud operation status based on the supplementary data segments. By monitoring and filtering local data streams at the edge devices, a dual-format data queue with local retention and blockchain upload is formed, providing supplementary data for the blockchain to address communication interruptions and improving the continuity and reliability of blockchain data evidence storage.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a method and system for data traceability and operation control based on blockchain-based evidence storage. Background Technology

[0002] Blockchain, as a decentralized distributed ledger that is block-chained, immutable, secure, and reliable, is widely used in data security storage scenarios. Industrial sites contain various types of industrial equipment, each generating production data during operation. This data includes confidential information such as real-time operational details of the equipment and production line status. To formulate timely and accurate effective response strategies in case of malfunctions, stable and reliable storage of this data is essential. Storing this confidential data on the blockchain is a viable solution. However, the collection and uploading of confidential data rely on communication paths, and interruptions in these paths can prevent continuous transmission of confidential data to the blockchain, affecting the integrity of the stored data. Therefore, determining and temporarily storing the data that should be received by the blockchain during communication path interruptions is crucial for ensuring the continuity and reliability of blockchain data storage. Summary of the Invention

[0003] Given that existing blockchain data storage methods cannot accurately pinpoint the original data transmission process when communication is interrupted and then restored, leading to data duplication and disordered storage, and affecting the continuity and reliability of data storage in blockchain-based evidence storage scenarios, this invention provides a data traceability and operation control method based on blockchain-based evidence storage, including: Monitor the local data streams at each edge of the industrial site to determine the data stream characteristic parameters; and set the data upload logic for all edge devices based on the data stream characteristic parameters. Based on the data upload logic and cloud operation status parameters (including but not limited to the available storage space of cloud blockchain nodes and the congestion level of the transaction pool), a dual-format data queue is generated; the dual-format data queue is locally retained and uploaded to the blockchain to form an associated local cache queue and blockchain evidence queue. Based on network link quality parameters (including but not limited to network bandwidth, packet loss rate, and communication latency between the edge and the cloud), the data interruption characteristics of the blockchain evidence storage queue are identified, thereby dynamically tracing back in the local cache queue to obtain supplementary data segments; and the cloud's operating status is adjusted based on the supplementary data segments.

[0004] Optionally, monitor the local data streams at each edge of the industrial site to determine data stream characteristic parameters; based on the data stream characteristic parameters, set the data upload logic for all edge devices, including: Based on the access location of each edge terminal in the industrial site and the communication link of each industrial device, determine all industrial devices covered by each edge terminal; adjust the monitoring mode of each edge terminal according to the real-time working status of all the covered industrial devices. Based on the monitoring mode, the local data streams formed by all industrial devices under the coverage of each edge terminal are extracted; the data type of the local data stream is identified, and the occupied segments of valid data within the local data stream are marked; time and data rate are calibrated for all occupied segments to determine the data stream characteristic parameters; wherein, the data stream characteristic parameters refer to the statistical characteristics of the arrival rate of valid data components within the local data stream per unit time (i.e., the actual effective data rate received by the edge terminal), specifically the variance or standard deviation of the arrival rate; this parameter is used to measure the degree of fluctuation of data traffic; Based on the data stream characteristic parameters, predict the accumulation trend of effective data components at each edge. Based on the accumulation trends of all effective data components and the cache limit of each edge, set the data upload logic for all edge edges. The data upload logic refers to the priority order and single upload limit of effective data components uploaded by all edge edges to the cloud. The priority order is determined by sorting the current cache occupancy rate of each edge edge from high to low, and further weighted by data importance. For example, priority order = cache occupancy rate weight × 0.6 + data importance weight × 0.4. Data importance is preset according to the type of industrial equipment, specifically: core production equipment (such as reactors, compressors) is set to the highest priority (weight 1.0), auxiliary equipment (such as conveyor belts, fans) is set to medium priority (weight 0.5), and monitoring equipment (such as temperature sensors, pressure sensors) is set to ordinary priority (weight 0.3). The single upload limit is dynamically calculated based on the remaining cache space and currently available network bandwidth of each edge edge, specifically: single upload limit = min(remaining cache space × 0.8, ... Available bandwidth × upload time window), where the upload time window is set according to the data acquisition cycle of the industrial site (e.g., set to an integer multiple of the data acquisition interval, or dynamically and adaptively adjusted according to network latency).

[0005] Optionally, based on the data upload logic and cloud operation status parameters, a dual-format data queue is generated; the dual-format data queue is locally retained and uploaded to the blockchain to form an associated local cache queue and blockchain evidence queue, including: According to the data upload logic, valid data component fragments matching the data volume are extracted locally from each edge terminal, and all extracted valid data component fragments are arranged to form an initial data queue. Based on the real-time compatible data format in the cloud, the initial data queue is subjected to data format identification and partial data format conversion to generate a modified data queue. The initial data queue and the modified data queue are then aligned and calibrated along the timeline to generate a dual-format data queue. The initial data queue and the modified data queue are completely identical in data content, differing only in data format, and both are arranged in the same timestamp order. To avoid wasting storage resources at the edge, the initial data queue and the modified data queue are not physically stored as two complete copies, but rather two format views of the same data object are maintained in memory, or real-time format conversion is performed only when necessary. The timeline alignment and calibration uses a network time protocol to synchronize the clocks at each edge and timestamps each data segment in the two queues with a unified time base to ensure alignment accuracy. The initial data queue and the changed data queue under the dual-format data queue are locally retained and uploaded to the blockchain, respectively. Based on the real-time progress of the blockchain upload, the initial data queue and the changed data queue are updated to form an associated local cache queue and a blockchain evidence queue. The update refers to deleting the corresponding uploaded data segment from the locally retained initial data queue whenever some data in the changed data queue is successfully uploaded to the blockchain, thereby achieving dynamic synchronization between the local queue and the blockchain evidence queue. Successful upload means that the blockchain node returns a transaction receipt and the transaction has been confirmed by the network in the block. If the upload fails, the data segment is added back to the head of the changed data queue.

[0006] Optionally, based on network link quality parameters, the data interruption characteristics of the blockchain evidence storage queue are calibrated, thereby dynamically tracing back in the local cache queue to obtain supplementary data segments; based on the supplementary data segments, the cloud's operating status is adjusted, including: Monitor the network link quality parameters between each edge device and the cloud, and obtain the block height or transaction hash corresponding to the last successfully uploaded data in the blockchain evidence queue. Use the block height or transaction hash as the last confirmed upload point. Use the timestamp of the data corresponding to the last confirmed upload point as the starting boundary of the unuploaded data segment. Data generated from this starting boundary until communication is restored is marked as the unuploaded data segment, and its time axis coverage range is determined as the data interruption feature. If there is data in the transmission queue before the communication interruption but it has not yet been confirmed to be uploaded to the blockchain, the data in the transmission queue but not yet confirmed to be uploaded to the blockchain is also included in the unuploaded data segment. The local cache queue is dynamically traced according to the time axis coverage interval, and a supplementary data segment is obtained from the local cache queue; wherein, the supplementary data segment has the same time axis coverage interval as the data segment, and the supplementary data segment is the original local data that has not yet been uploaded to the blockchain; Based on the timeline coverage interval label of the supplemented data segment, when communication is restored at the cloud edge, the supplemented data segment is uploaded to the blockchain space in the cloud, appended to the chain as a new block, and stored on the blockchain. Each data entry contains the original data generation time (master timestamp) and the supplemented upload time (auxiliary marker). When the application layer queries or the smart contract processes the data, the data is sorted and indexed by reading the master timestamp, thereby achieving logical alignment in business time sequence. Preferably, the master timestamp can be used as an indexable field of blockchain transactions or recorded through smart contract events, so that the application layer can perform efficient time sequence queries through indexing. The upload does not modify any existing historical blocks on the blockchain, but only appends the new data block to the chain, thereby ensuring that the immutability of the blockchain is not affected.

[0007] Preferably, the cloud operation status parameters include the available storage space of the cloud blockchain nodes and the congestion level of the transaction pool; the network link quality parameters include the network bandwidth, packet loss rate, and communication latency between the edge and the cloud.

[0008] As one aspect of the present invention, the present invention also provides a data traceability and operation control system based on blockchain evidence storage, comprising: The data fluctuation determination module is used to monitor the local data streams at each edge of the industrial site and determine the characteristic parameters of the data streams. The upload logic setting module is used to set the data upload logic for all edge terminals based on the data stream characteristic parameters. The data queue generation module is used to generate a dual-format data queue based on the data upload logic and cloud operation status parameters; and to perform local retention and blockchain upload on the dual-format data queue to form an associated local cache queue and blockchain evidence queue. The traceability module is used to identify the data interruption characteristics of the blockchain evidence storage queue based on network link quality parameters, so as to dynamically trace the data in the local cache queue and obtain the supplementary data segment. The adjustment module is used to adjust the cloud's operating status based on the supplemented data segment.

[0009] Optionally, the data fluctuation determination module is used to monitor the local data streams at each edge of the industrial site and determine the data stream characteristic parameters, including: Based on the access location of each edge terminal in the industrial site and the communication link of each industrial device, determine all industrial devices covered by each edge terminal; adjust the monitoring mode of each edge terminal according to the real-time working status of all the covered industrial devices. According to the monitoring mode, the local data streams formed by all industrial devices covered by each edge terminal are extracted; the data type of the local data stream is identified, and the occupied segments of valid data in the local data stream are marked; the time and data rate of all occupied segments are calibrated to determine the data stream characteristic parameters; wherein, the data stream characteristic parameters refer to the statistical characteristics of the arrival rate of valid data components in the local data stream per unit time, specifically the variance or standard deviation of the arrival rate; The upload logic setting module is used to set the data upload logic for all edge terminals according to the data stream characteristic parameters, including: Based on the data stream characteristic parameters, predict the accumulation trend of effective data components at each edge. Based on the accumulation trends of all effective data components and the cache limit of each edge, set the data upload logic for all edge edges. The data upload logic refers to the priority order and single upload limit of effective data components uploaded by all edge edges to the cloud. The priority order is determined by sorting the current cache occupancy rate of each edge edge from high to low, and further weighted by data importance. For example, priority order = cache occupancy rate weight × 0.6 + data importance weight × 0.4. Data importance is preset according to the type of industrial equipment, specifically: core production equipment (such as reactors, compressors) is set to the highest priority (weight 1.0), auxiliary equipment (such as conveyor belts, fans) is set to medium priority (weight 0.5), and monitoring equipment (such as temperature sensors, pressure sensors) is set to ordinary priority (weight 0.3). The single upload limit is dynamically calculated based on the remaining cache space and currently available network bandwidth of each edge edge, specifically: single upload limit = min(remaining cache space × 0.8, ... Available bandwidth × upload time window), where the upload time window is set according to the industrial site data acquisition cycle.

[0010] Optionally, the data queue generation module is used to generate a dual-format data queue based on the data upload logic and cloud operation status parameters; and to perform local retention and blockchain upload on the dual-format data queue to form an associated local cache queue and blockchain evidence queue, including: According to the data upload logic, valid data component fragments matching the data volume are extracted locally from each edge terminal, and all extracted valid data component fragments are arranged to form an initial data queue. Based on the real-time compatible data format in the cloud, the initial data queue is subjected to data format identification and partial data format conversion to generate a modified data queue. The initial data queue and the modified data queue are then aligned and calibrated along the timeline to generate a dual-format data queue. The initial data queue and the modified data queue are completely identical in data content, differing only in data format, and both are arranged in the same timestamp order. The initial data queue and the modified data queue are not physically stored as two complete copies, but rather two format views of the same data object are maintained in memory, or real-time format conversion is performed as needed. The timeline alignment and calibration uses a network time protocol to synchronize the clocks at each edge end, and timestamps are marked on each data segment in the two queues using a unified time base. The initial data queue and the changed data queue under the dual-format data queue are locally retained and uploaded to the blockchain, respectively. Based on the real-time progress of the blockchain upload, the initial data queue and the changed data queue are updated to form an associated local cache queue and a blockchain evidence queue. The update refers to deleting the corresponding uploaded data segment from the locally retained initial data queue whenever some data in the changed data queue is successfully uploaded to the blockchain, thereby achieving dynamic synchronization between the local queue and the blockchain evidence queue. Successful upload means that the blockchain node returns a transaction receipt and the transaction has been confirmed by the network in the block. If the upload fails, the data segment is added back to the head of the changed data queue.

[0011] Optionally, the tracing module is used to calibrate the data interruption characteristics of the blockchain evidence storage queue based on network link quality parameters, thereby dynamically tracing back in the local cache queue to obtain the supplementary data segment, including: Monitor the network link quality parameters between each edge device and the cloud, and obtain the block height or transaction hash corresponding to the last successfully uploaded data in the blockchain evidence queue. Use the block height or transaction hash as the last confirmed upload point. Use the timestamp of the data corresponding to the last confirmed upload point as the starting boundary of the unuploaded data segment. Data generated from this starting boundary until communication is restored is marked as the unuploaded data segment, and its time axis coverage range is determined as the data interruption feature. If there is data in the transmission queue before the communication interruption but it has not yet been confirmed to be uploaded to the blockchain, the data in the transmission queue but not yet confirmed to be uploaded to the blockchain is also included in the unuploaded data segment. The local cache queue is dynamically traced according to the time axis coverage interval, and a supplementary data segment is obtained from the local cache queue; wherein the supplementary data segment has the same time axis coverage interval as the data segment, and the supplementary data segment is the original local data that has not yet been uploaded to the blockchain; The adjustment module is used to adjust the cloud's operating status based on the supplemented data segment, including: Based on the timeline coverage interval label of the supplemented data segment, when communication is restored at the cloud edge, the supplemented data segment is uploaded to the blockchain space in the cloud, appended to the chain as a new block, and stored on the blockchain. Each data entry contains the original data generation time (master timestamp) and the supplemented upload time (auxiliary marker). When the application layer queries or the smart contract processes the data, the data is sorted and indexed by reading the master timestamp, thereby achieving logical alignment in business time sequence. Preferably, the master timestamp can be used as an indexable field of blockchain transactions or recorded through smart contract events, so that the application layer can perform efficient time sequence queries through indexing. The upload does not modify any historical blocks that already exist on the blockchain.

[0012] Preferably, the cloud operation status parameters include the available storage space of the cloud blockchain nodes and the congestion level of the transaction pool; the network link quality parameters include the network bandwidth, packet loss rate, and communication latency between the edge and the cloud.

[0013] The beneficial effects of the above-mentioned technical solutions provided in the embodiments of the present invention include at least the following: This invention provides a data traceability and operation control method and system based on blockchain-based evidence storage. It monitors local data streams at various edge devices in an industrial site, determines data stream characteristic parameters, and uses this to set data upload logic for all edge devices. Based on the data upload logic and cloud operation status parameters, a dual-format data queue is generated. The dual-format data queue is locally retained and uploaded to the blockchain, forming an associated local cache queue and a blockchain evidence storage queue. Based on network link quality parameters, data interruption characteristics of the blockchain evidence storage queue are identified, allowing dynamic tracing in the local cache queue to obtain supplementary data segments. Based on the supplementary data segments, the cloud operation status is adjusted. By monitoring and filtering local data streams at the edge devices, a dual-format data queue is formed, consisting of locally retained and blockchain-uploaded data. This provides supplementary data for the blockchain to address communication interruptions, improving the continuity and reliability of blockchain data evidence storage.

[0014] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0015] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0016] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1This is a flowchart illustrating the data traceability and operation control method based on blockchain evidence storage provided in this embodiment of the invention. Figure 2 This is a schematic diagram of the data traceability and operation control system based on blockchain evidence provided in this embodiment of the invention. Detailed Implementation

[0017] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0018] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," "outer," "far," "near," "front," and "rear," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0019] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0020] Please see Figure 1 As shown, an embodiment of this application provides a data traceability and operation control method based on blockchain-based evidence storage. This data traceability and operation control method based on blockchain-based evidence storage includes: Monitor the local data streams at each edge of the industrial site to determine the data stream characteristic parameters; and set the data upload logic for all edge devices based on the data stream characteristic parameters. Based on the data upload logic and cloud operation status parameters, a dual-format data queue is generated; the dual-format data queue is locally retained and uploaded to the blockchain to form an associated local cache queue and blockchain evidence queue. Based on network link quality parameters, the data interruption characteristics of the blockchain evidence storage queue are identified, and the data segments are dynamically traced in the local cache queue to obtain supplementary data segments; based on the supplementary data segments, the cloud operation status is adjusted.

[0021] The beneficial effects of the above embodiments are as follows: the data traceability and operation control method based on blockchain evidence storage forms a dual-format data queue of local retention and blockchain upload by listening to and filtering the local data stream at the edge, providing supplementary data for the blockchain to cope with communication interruptions, and improving the continuity and reliability of blockchain data evidence storage.

[0022] In another embodiment, the local data streams at each edge of the industrial site are monitored to determine data stream characteristic parameters; based on the data stream characteristic parameters, data upload logic for all edge devices is set, including: Based on the access location of each edge terminal in the industrial site and the communication link of each industrial device, determine all industrial devices covered by each edge terminal; adjust the monitoring mode of each edge terminal according to the real-time working status of all the covered industrial devices. According to the monitoring mode, the local data streams formed by all industrial devices covered by each edge terminal are extracted; the data type of the local data stream is identified, and the occupied segments of valid data in the local data stream are marked; the time and data rate of all occupied segments are calibrated to determine the data stream characteristic parameters; wherein, the data stream characteristic parameters refer to the statistical characteristics of the arrival rate of valid data components in the local data stream per unit time, specifically the variance or standard deviation of the arrival rate; Based on the data stream characteristic parameters, predict the accumulation trend of effective data components at each edge. Based on the accumulation trends of all effective data components and the cache limit of each edge, set the data upload logic for all edge edges. The data upload logic refers to the priority order and single upload limit of effective data components uploaded by all edge edges to the cloud. The priority order is determined by sorting the current cache occupancy rate of each edge edge from high to low, and further weighted by data importance. For example, priority order = cache occupancy rate weight × 0.6 + data importance weight × 0.4. Data importance is preset according to the type of industrial equipment, specifically: core production equipment (such as reactors, compressors) is set to the highest priority (weight 1.0), auxiliary equipment (such as conveyor belts, fans) is set to medium priority (weight 0.5), and monitoring equipment (such as temperature sensors, pressure sensors) is set to ordinary priority (weight 0.3). The single upload limit is dynamically calculated based on the remaining cache space and currently available network bandwidth of each edge edge, specifically: single upload limit = min(remaining cache space × 0.8, ... Available bandwidth × upload time window), where the upload time window is set according to the industrial site data acquisition cycle.

[0023] The beneficial effects of the above embodiments are as follows: Industrial sites such as production workshops are equipped with various types of industrial equipment, which perform different production processes on the production line. Each piece of industrial equipment executes corresponding production actions under the control of a server. It can be understood that the server issues work instructions to each piece of industrial equipment, and each piece of equipment parses these work instructions and executes the corresponding production actions. During the production work of each piece of industrial equipment, the real-time production actions of each piece of equipment are collected synchronously. Several edge terminals (such as edge computers) are also distributed throughout the industrial site. All edge terminals are connected to the Internet of Things (IoT) of the industrial site to collect work instructions issued by the server to the industrial equipment and the real-time production actions of each piece of industrial equipment, thereby forming local data about each piece of industrial equipment. Considering the large number and variety of industrial equipment within the industrial site, it is not possible to configure a dedicated edge terminal for each piece of industrial equipment. To ensure monitoring of each piece of industrial equipment, based on the access location of each edge terminal in the IoT and the communication link of each piece of industrial equipment, all industrial equipment covered by each edge terminal under its effective monitoring link path is determined. Understandably, the limited length of the monitoring link path at each edge device results in a limited number of industrial devices that each edge device can monitor within the Internet of Things (IoT). That is, each edge device can only monitor a subset of industrial devices, and cannot effectively monitor other industrial devices located outside the aforementioned monitoring link path length. Furthermore, the monitoring mode of each edge device is adjusted based on the duration of its real-time idle status across all industrial devices covered by that edge device. This monitoring mode can be, but is not limited to, allocating time intervals for each edge device to monitor all industrial devices within its coverage area.

[0024] Each edge device monitors all industrial equipment under its corresponding monitoring mode, generating operational record data for all industrial equipment. This operational record data may include, but is not limited to, work instructions received by the industrial equipment and real-time production data. The local data stream generated by each edge device's monitoring is extracted. This local data stream can include, but is not limited to, work instructions received by the industrial equipment, real-time production data, and information about external interference encountered during operation. Considering that this local data stream contains a large amount of data related to and unrelated to the industrial equipment's operation, directly storing this local data stream on the blockchain would consume blockchain storage space and affect the blockchain's data reliability. Therefore, it is necessary to filter and extract local data streams, specifically to identify the data types of the local data streams and mark the occupied sections of valid data within the local data streams. The occupied sections of valid data refer to the data stream intervals occupied by the data portion related to the operation of industrial equipment within the local data streams. Then, time and data rate calibrations are performed on all occupied sections (i.e., the start and end time points corresponding to each occupied section are calibrated and the transmission rate of each occupied section in the local data stream is calibrated). This determines the change attribute of the transmission rate of the valid data components within the local data stream over time, providing a basis for subsequently determining the data uploaded from each edge device to the blockchain in the cloud.

[0025] Furthermore, based on the aforementioned data flow characteristic parameters, the accumulation trend of effective data components at each edge endpoint is predicted (i.e., the increase in effective data components per unit time). It is understandable that the accumulated effective data components at each edge endpoint will occupy its own cache. When the cache of each edge endpoint reaches saturation, the effective data components need to be uploaded to the cloud blockchain to reduce the cache pressure on the edge endpoints. To balance the differences in the accumulation trends of effective data components across all edge endpoints and the upper limit of cache space, corresponding data upload logic is set for all edge endpoints. This standardizes the priority order and single upload limit of effective data components uploaded to the cloud by all edge endpoints, ensuring that all edge endpoints upload their local effective data components to the cloud in a timely manner and avoiding effective data component overflow at the edge endpoints.

[0026] In one embodiment, setting the priority order in the data upload logic of all edge devices, as described above, can be implemented as follows: Step S31: Obtain the real-time status parameters of each edge terminal; wherein, the real-time status parameters of the i-th edge terminal include the current cache usage of the i-th edge terminal. Cache limit Rate of change in cache usage during the current sampling period and the data importance weight of subordinate industrial equipment. ;in, The preset data sampling time interval, This represents the difference between the current time and the previous time at the i-th edge. Step S32: Determine the upload urgency index of each edge terminal based on the real-time status parameters of each edge terminal and the preset upload urgency index formula; Specifically, the preset upload urgency index formula is as follows: ; in, This represents the upload urgency index of the i-th edge. This is a preset normalized baseline value for the cache growth rate, used to normalize the dimensions of the cache change rate to a dimensionless value. Its value is preset based on the historical peak growth rate of cache occupancy at each edge point under normal operating conditions in an industrial setting, or the maximum tolerable growth rate of the system design. ; This means that the value is 0 when the cache usage decreases, in order to prevent negative growth from reducing the urgency index, thereby ensuring that the urgency index only reflects the positive risk of data backlog; , , Let the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient all have values ​​greater than zero and less than 1, and satisfy the following conditions: These are used to adjust the proportions of current cache inventory risk, cache growth trend risk, and data type importance risk in the urgency index, respectively; wherein, the cache growth trend item... Decoupled from currently available network bandwidth, it independently reflects the rate of deterioration of local data backlog at the edge; Step S33: The calculated upload urgency index is used as the priority quantification value of each edge terminal, and all edge terminals are sorted in descending order of upload urgency index to obtain the priority order; wherein the larger the upload urgency index value, the higher the urgency of the data upload of the corresponding edge terminal, and the higher the priority of the upload resource when uploading data.

[0027] This embodiment quantifies the upload priority at the edge as a calculable value by constructing an upload urgency index (UUI). This index is a weighted composite of three dimensions: current cached inventory risk (…). This reflects the severity of data accumulation and the risk of cache growth trends. This reflects the rate of deterioration of data accumulation and the risk associated with the importance of data types. This reflects the business value of data from different industrial equipment. Each of the three dimensions is multiplied by a weighting coefficient. , , The summation yields a urgency index with values ​​ranging from [0,1]. Specifically, a cache growth trend term is introduced. The function prevents negative growth interference and is completely decoupled from network bandwidth, allowing the urgency index to purely reflect the severity of local data backlog.

[0028] This embodiment eliminates the reliance on simple cache occupancy ranking for edge device uploads. Instead, it integrates two time dimensions: current cache fullness and how quickly it will become full, enabling proactive scheduling. Even if two edge devices have the same current cache occupancy, the one with faster cache growth will receive higher upload priority, effectively preventing cache overflow. Furthermore, because the urgency index is decoupled from bandwidth, it avoids long-term data backlogs at edge devices with poor network conditions due to bandwidth suppression. This ensures that all edge devices have the opportunity to upload data before cache overflow, guaranteeing the continuity and integrity of blockchain data storage.

[0029] In one embodiment, setting the single-upload data limit in the data upload logic of all edge terminals can be implemented as follows: Step S41: Obtain the dynamic constraint parameters of each edge, wherein the dynamic constraint parameters of the i-th edge include the remaining cache space of the i-th edge. Available network bandwidth measured in the previous control cycle And the urgency index for uploading The available network bandwidth measured in the previous control cycle This refers to the available bandwidth value measured in the most recent network monitoring cycle before the current upload decision (e.g., measured by heartbeat packets), in order to avoid mathematical circular dependencies caused by self-calculation using variables affected by the current decision; Step S42: Determine the single upload data limit for each edge terminal based on the dynamic constraint parameters of each edge terminal and the preset dynamic adaptive upload quota formula. Specifically, the preset dynamic adaptive upload quota formula is as follows: ; in, The preset cache security factor has a value range of [value range missing]. ; The preset upload control period duration; This is the preset minimum bandwidth utilization constant, with a value range of [value range missing]. ; This is a preset hard limit for a single upload at the i-th edge. To upload the urgency index; Among them, the first sub-item For cache security constraints, This is used to prevent the edge cache from being exhausted due to excessive data uploads in a single session, thus affecting the real-time reception of new data; the physical meaning of the first sub-item is the maximum amount of data allowed to be uploaded in a single session, provided that the edge has sufficient cache space to receive new data.

[0030] Second sub-item This is a bandwidth-critical linear coupling constraint term. Among them, The available network bandwidth is expressed as data volume divided by time; T is the preset upload control period duration, and ( (where the number is a positive integer), the upload control period and the data sampling time interval Proportional to ensure that the control cycle and the data acquisition cycle maintain a fixed time series multiple relationship; The unit of measurement is data volume, and its physical meaning is the maximum amount of data that can be transmitted within the current upload control cycle using the currently available bandwidth; the bandwidth utilization adjustment coefficient in parentheses In the above, δ is used to ensure that even in the upload urgency index... In this case, the edge device still retains the basic upload quota and there will be no transmission interruption; The range of values ​​is The second sub-item uses a linear mapping method, when Only the basic bandwidth percentage is used. ,when This fully utilizes all available bandwidth, allowing edge devices with high urgency to receive larger single-upload quotas. Therefore, the overall physical meaning of the second sub-item is the upper limit of the amount of uploaded data that the available bandwidth, adjusted based on the upload urgency index, can handle within the current upload control cycle.

[0031] Third Sub-item Used to limit the maximum amount of data uploaded in a single session, to prevent excessively large uploads from exceeding the blockchain's transaction capacity or blocking other processing tasks at the edge; subscript The physical meaning of the maximum value.

[0032] Step S43: The calculated single upload data limit is used as the upper limit of the amount of data extracted by each edge terminal from the local cache and formed into an initial data queue within the current upload control cycle, so as to adaptively adjust the upload load of each edge terminal.

[0033] The above calculation The formula uses a minimum value (min function) calculation method. The principle is that the amount of data uploaded in a single instance must simultaneously meet three constraints: cache security, bandwidth capacity, and system hard limit. The final upload limit is determined by the minimum value of these three (i.e., the shortest "plank"). This is the well-known "barrel effect" principle in engineering. Upload Urgency Index By adjusting the bandwidth utilization adjustment coefficient in the second sub-item The value of the third sub-item dynamically affects the size of the bandwidth constraint: when the upload urgency index increases, the bandwidth utilization adjustment coefficient increases, the value of the second sub-item increases, and the bandwidth constraint is correspondingly relaxed; when the upload urgency index decreases, the bandwidth utilization adjustment coefficient decreases, the value of the second sub-item decreases, and the bandwidth constraint is correspondingly tightened. Under different operating conditions, the "weakest link" of the three constraints may be different: when the cache is sufficient and the hard limit is adequate, the second sub-item (bandwidth constraint) usually becomes the minimum value, and the upload urgency index directly determines the upload quota size; when the cache is tight, the first sub-item (cache security constraint) becomes the minimum value, and cache protection strategies are prioritized to prevent data loss; when the hard limit is low, the third sub-item (hard limit constraint) becomes the minimum value, and transaction load protection strategies are prioritized to prevent on-chain failure. Through the dynamic coordination of the above three constraints, adaptive adjustment to different operating conditions is achieved, ensuring that the system does not exceed any security boundary under any circumstances.

[0034] The above embodiments achieve the technical effect of adaptively adjusting the upload load among various edge devices through the synergistic effect of three constraints: when the caches at each edge device are sufficient and the blockchain transaction load capacity is reasonably limited, bandwidth constraints dominate, with edge devices having higher urgency indices receiving larger single upload quotas, thereby accelerating the removal of backlogged data; when the cache at a certain edge device is close to saturation, cache security constraints take over, forcibly limiting the single upload amount to prevent cache overflow and data loss; when the blockchain transaction load capacity is limited, hard upper limit constraints take over, preventing on-chain failures due to excessively large transaction data. The switching between the above control mechanisms under different operating conditions is all controlled by... The system automatically selects the dominant constraint under the current operating condition based on the real-time collected status parameters of each edge terminal and network environment parameters, without the need for manual intervention. This enables adaptive adaptation to various industrial site conditions, thereby improving the overall data upload efficiency and the timeliness and reliability of blockchain-stored evidence data in industrial site environments with limited communication resources.

[0035] In another embodiment, a dual-format data queue is generated based on the data upload logic and cloud operation status parameters; the dual-format data queue is then locally retained and uploaded to the blockchain to form an associated local cache queue and a blockchain evidence queue, including: Based on the data upload logic, valid data component fragments matching the data volume are extracted locally from each edge terminal, and all extracted valid data component fragments are arranged to form an initial data queue. Based on the real-time compatible data format in the cloud, the initial data queue is identified and partially converted to generate a modified data queue. The initial data queue and the modified data queue are then aligned and calibrated along the timeline to generate a dual-format data queue. The initial data queue and the modified data queue are completely identical in data content, differing only in data format, and both are arranged in the same timestamp order. The initial data queue and the modified data queue are not physically stored as two complete copies, but rather two format views of the same data object are maintained in memory, or real-time format conversion is performed as needed. The timeline alignment and calibration uses a network time protocol to synchronize the clocks at each edge end, and timestamps are marked on each data segment in the two queues using a unified time base. The initial data queue and the changed data queue under the dual-format data queue are locally retained and uploaded to the blockchain, respectively. According to the real-time progress of the blockchain upload, the initial data queue and the changed data queue are updated to form an associated local cache queue and blockchain evidence queue. The update means that whenever part of the data in the changed data queue is successfully uploaded to the blockchain, the corresponding uploaded data segment is deleted from the locally retained initial data queue to achieve dynamic synchronization between the local queue and the blockchain evidence queue. Successful upload means that the blockchain node returns a transaction receipt and the transaction has been confirmed by the network in the block. If the upload fails, the data segment is added back to the head of the changed data queue.

[0036] The beneficial effects of the above embodiments are as follows: Considering that stable communication between the edge and the cloud cannot be maintained continuously and may be interrupted at certain times, if the edge only forms an upload data queue to the cloud, once communication between the two is interrupted, the original upload data queue will be interrupted. The interruption may include, but is not limited to, the disorder of the currently uploaded data position in the upload data queue. When subsequent communication is restored, it is impossible to continue data upload from the previously uploaded data position, and all data must be re-uploaded, resulting in the limited storage space in the blockchain being occupied by repeated data uploads. To avoid the waste of limited storage space in the blockchain, a local data queue consistent with the above-mentioned upload data queue needs to be set up locally. It is understood that the above-mentioned local data queue and the upload data queue are completely identical in terms of data content and dynamic data changes. By setting the above-mentioned local data queue as a local mapping of the upload data queue, a reference guide is provided for the continuous uploading of blockchain data in the event of subsequent potential communication interruption recovery. Specifically, according to the above data upload logic, effective data component fragments matching the data volume are extracted from each edge local, and all extracted effective data component fragments are arranged in order to form an initial data queue. The above-mentioned initial data queue can be directly used as a local data queue. To adapt to the format requirements of blockchain data uploaded to the cloud, the initial data queue undergoes data format identification and partial format conversion based on the cloud's real-time compatible data format, generating a modified data queue, which then serves as the upload data queue. Furthermore, the initial and modified data queues are aligned along a timeline to generate a dual-format data queue, thus forming two data queues that simultaneously adapt to local retention and blockchain uploads. The initial and modified data queues under the dual-format data queues are then used for both local retention and blockchain uploads, respectively. Based on the real-time progress of blockchain uploads, the initial and modified data queues are updated, forming an associated local cache queue and blockchain evidence queue. For example, the system retrieves the portion of the modified data queue that has been uploaded to the blockchain in real time, and deletes the corresponding portion of the data queue within the initial data queue based on this uploaded portion, achieving a dynamic association between the two data queues.

[0037] In another embodiment, based on network link quality parameters, the data interruption characteristics of the blockchain evidence storage queue are identified, thereby dynamically tracing back in the local cache queue to obtain supplementary data segments; based on the supplementary data segments, the cloud's operating status is adjusted, including: Monitor the network link quality parameters between each edge device and the cloud, and obtain the block height or transaction hash corresponding to the last successfully uploaded data in the blockchain evidence queue. Use the block height or transaction hash as the last confirmed upload point. Use the timestamp of the data corresponding to the last confirmed upload point as the starting boundary of the unuploaded data segment. Data generated from this starting boundary until communication is restored is marked as the unuploaded data segment, and its time axis coverage range is determined as the data interruption feature. If there is data in the transmission queue before the communication interruption but it has not yet been confirmed to be uploaded to the blockchain, the data in the transmission queue but not yet confirmed to be uploaded to the blockchain is also included in the unuploaded data segment. The local cache queue is dynamically traced according to the time axis coverage interval, and a supplementary data segment is obtained from the local cache queue; wherein the supplementary data segment has the same time axis coverage interval as the data segment, and the supplementary data segment is the original local data that has not yet been uploaded to the blockchain; Based on the timeline coverage interval label of the supplemented data segment, when communication is restored at the cloud edge, the supplemented data segment is uploaded to the blockchain space in the cloud, appended to the chain as a new block, and stored on the blockchain. Each data entry contains the original data generation time (master timestamp) and the supplemented upload time (auxiliary marker). When the application layer queries or the smart contract processes the data, the data is sorted and indexed by reading the master timestamp, thereby achieving logical alignment in business time sequence. Preferably, the master timestamp can be used as an indexable field of blockchain transactions or recorded through smart contract events, so that the application layer can perform efficient time sequence queries through indexing. The upload does not modify any existing historical blocks on the blockchain, but only appends the new data block to the chain, thereby ensuring that the immutability of the blockchain is not affected.

[0038] Preferably, the cloud operation status parameters include the available storage space of the cloud blockchain nodes and the congestion level of the transaction pool; the network link quality parameters include the network bandwidth, packet loss rate, and communication latency between the edge and the cloud.

[0039] The beneficial effects of the above embodiments are as follows: In actual operation, network link quality parameters between each edge device and the cloud are monitored. These parameters may include, but are not limited to, bandwidth and packet loss rate. If the available communication bandwidth is less than a preset bandwidth threshold, it is determined that communication between the edge device and the cloud is interrupted. The start and end times of the communication interruption between the edge device and the cloud are obtained, along with the confirmation point (block height or transaction hash) of the last successful upload to the blockchain. Using the data timestamp corresponding to this confirmation point as the boundary, the actual un-uploaded data segment and its timeline coverage range are determined. It can be understood that the above data segment corresponds to the data segment that is re-uploaded to the blockchain after communication is restored. Since the blockchain evidence storage queue and the local cache queue have already undergone timeline alignment, the local cache queue is dynamically traced according to the aforementioned timeline coverage interval. Supplementary data segments are obtained from the local cache queue and then, based on the timeline coverage interval label of the aforementioned supplementary data segments, when communication is restored between the edge and the cloud, the aforementioned supplementary data segments are uploaded to the blockchain space in the cloud as a new block. Each data entry is marked with its original time and supplementary time, and the logical sequence is achieved by the application layer or smart contract sorting according to the original time, without modifying existing blocks.

[0040] Please see Figure 2 As shown in this application, an embodiment of a data traceability and operation control system based on blockchain evidence storage is provided. This blockchain-based data traceability and operation control system includes: The data fluctuation determination module is used to monitor the local data streams at each edge of the industrial site and determine the characteristic parameters of the data streams. The upload logic setting module is used to set the data upload logic for all edge terminals based on the data stream characteristic parameters. The data queue generation module is used to generate a dual-format data queue based on the data upload logic and cloud operation status parameters; and to perform local retention and blockchain upload on the dual-format data queue to form an associated local cache queue and blockchain evidence queue. The traceability module is used to identify the data interruption characteristics of the blockchain evidence storage queue based on network link quality parameters, so as to dynamically trace the data in the local cache queue and obtain the supplementary data segment. The adjustment module is used to adjust the cloud's operating status based on the supplemented data segment.

[0041] The beneficial effects of the above embodiments are as follows: the data traceability and operation control system based on blockchain evidence storage forms a dual-format data queue of local retention and blockchain upload by listening to and filtering the local data stream at the edge, providing supplementary data for the blockchain to cope with communication interruptions, and improving the continuity and reliability of blockchain data evidence storage.

[0042] In another embodiment, the data fluctuation determination module is used to monitor the local data streams at each edge of the industrial site and determine the data stream characteristic parameters, including: Based on the access location of each edge terminal in the industrial field and the communication link of each industrial device, determine all industrial devices covered by each edge terminal; adjust the monitoring mode of each edge terminal according to the real-time working status of all covered industrial devices. Based on the monitoring mode, extract the local data streams formed by all industrial devices covered by each edge terminal; identify the data type of the local data streams and mark the occupied segments of valid data within the local data streams; perform time calibration and data rate calibration on all occupied segments to determine the data stream characteristic parameters; wherein, the data stream characteristic parameters refer to the statistical characteristics of the arrival rate of valid data components within the local data streams per unit time, specifically the variance or standard deviation of the arrival rate; The upload logic setting module is used to set the data upload logic for all edge terminals based on the data stream characteristic parameters, including: Based on the data stream characteristic parameters, predict the accumulation trend of effective data components at each edge. Based on the accumulation trends of all effective data components and the cache limit of each edge, set the data upload logic for all edge edges. The data upload logic refers to the priority order and single upload limit of effective data components uploaded by all edge edges to the cloud. The priority order is determined by sorting the current cache occupancy rate of each edge edge from high to low, and further weighted by data importance. For example, priority order = cache occupancy rate weight × 0.6 + data importance weight × 0.4. Data importance is preset according to the type of industrial equipment, specifically: core production equipment (such as reactors, compressors) is set to the highest priority (weight 1.0), auxiliary equipment (such as conveyor belts, fans) is set to medium priority (weight 0.5), and monitoring equipment (such as temperature sensors, pressure sensors) is set to ordinary priority (weight 0.3). The single upload limit is dynamically calculated based on the remaining cache space and currently available network bandwidth of each edge edge, specifically: single upload limit = min(remaining cache space × 0.8, ... Available bandwidth × upload time window), where the upload time window is set according to the industrial site data acquisition cycle.

[0043] In another embodiment, the data queue generation module is used to generate a dual-format data queue based on the data upload logic and cloud operation status parameters; and to perform local retention and blockchain upload on the dual-format data queue to form an associated local cache queue and a blockchain evidence queue, including: Based on the data upload logic, valid data component fragments matching the data volume are extracted locally from each edge terminal, and all extracted valid data component fragments are arranged to form an initial data queue. Based on the real-time compatible data format in the cloud, the initial data queue is identified and partially converted to generate a modified data queue. The initial data queue and the modified data queue are then aligned and calibrated along the timeline to generate a dual-format data queue. The initial data queue and the modified data queue are completely identical in data content, differing only in data format, and both are arranged in the same timestamp order. The initial data queue and the modified data queue are not physically stored as two complete copies, but rather two format views of the same data object are maintained in memory, or real-time format conversion is performed as needed. The timeline alignment and calibration uses a network time protocol to synchronize the clocks at each edge end, and timestamps are marked on each data segment in the two queues using a unified time base. The initial data queue and the changed data queue under the dual-format data queue are locally retained and uploaded to the blockchain, respectively. According to the real-time progress of the blockchain upload, the initial data queue and the changed data queue are updated to form an associated local cache queue and blockchain evidence queue. The update means that whenever part of the data in the changed data queue is successfully uploaded to the blockchain, the corresponding uploaded data segment is deleted from the locally retained initial data queue to achieve dynamic synchronization between the local queue and the blockchain evidence queue. Successful upload means that the blockchain node returns a transaction receipt and the transaction has been confirmed by the network in the block. If the upload fails, the data segment is added back to the head of the changed data queue.

[0044] In another embodiment, the tracing module is used to identify the data interruption characteristics of the blockchain evidence storage queue based on network link quality parameters, thereby dynamically tracing back in the local cache queue to obtain the supplementary data segment, including: Monitor the network link quality parameters between each edge device and the cloud, and obtain the block height or transaction hash corresponding to the last successfully uploaded data in the blockchain evidence queue. Use the block height or transaction hash as the last confirmed upload point. Use the timestamp of the data corresponding to the last confirmed upload point as the starting boundary of the unuploaded data segment. Data generated from this starting boundary until communication is restored is marked as the unuploaded data segment, and its time axis coverage range is determined as the data interruption feature. If there is data in the transmission queue before the communication interruption but it has not yet been confirmed to be uploaded to the blockchain, the data in the transmission queue but not yet confirmed to be uploaded to the blockchain is also included in the unuploaded data segment. The local cache queue is dynamically traced according to the time axis coverage interval, and the supplementary data segment is obtained from the local cache queue. The supplementary data segment has the same time axis coverage interval as the data segment, and the supplementary data segment is the local original data that has not yet been uploaded to the blockchain. The adjustment module is used to adjust the cloud's operating status based on the supplementary data segments, including: Based on the timeline coverage interval label of the supplemented data segment, when communication is restored at the cloud edge, the supplemented data segment is uploaded to the blockchain space in the cloud, appended to the chain as a new block, and stored on the blockchain. Each data entry contains the original data generation time (master timestamp) and the supplemented upload time (auxiliary marker). When the application layer queries or the smart contract processes the data, the data is sorted and indexed by reading the master timestamp, thereby achieving logical alignment in business time sequence. Preferably, the master timestamp can be used as an indexable field of blockchain transactions or recorded through smart contract events, so that the application layer can perform efficient time sequence queries through indexing. The upload does not modify any historical blocks that already exist on the blockchain.

[0045] Preferably, the cloud operation status parameters include the available storage space of the cloud blockchain nodes and the congestion level of the transaction pool; the network link quality parameters include the network bandwidth, packet loss rate, and communication latency between the edge and the cloud.

[0046] The data traceability and operation control system based on blockchain evidence of the present invention has the same operation and effect as the aforementioned data traceability and operation control method based on blockchain evidence, and will not be described again here.

[0047] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. This disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims. Thus, if these modifications and variations of the invention fall within the scope of the claims of the invention and their equivalents, the invention is also intended to include these modifications and variations.

Claims

1. A data traceability and operation control method based on blockchain-based evidence storage, characterized in that: include: Monitor the local data streams at each edge point in the industrial field to determine the characteristic parameters of the data streams; Based on the data stream characteristic parameters, set the data upload logic for all edge terminals; Based on the data upload logic and cloud operation status parameters, a dual-format data queue is generated; the dual-format data queue is locally retained and uploaded to the blockchain to form an associated local cache queue and blockchain evidence queue. Based on network link quality parameters, the data interruption characteristics of the blockchain evidence storage queue are identified, and the data segments are dynamically traced in the local cache queue to obtain the supplementary data segments. Adjust the cloud's operating status based on the supplemented data segments.

2. The data traceability and operation control method based on blockchain evidence storage as described in claim 1, characterized in that: Monitor the local data streams at each edge point in the industrial field to determine the characteristic parameters of the data streams; Based on the data stream characteristic parameters, set the data upload logic for all edge terminals, including: Based on the access location of each edge terminal in the industrial site and the communication link of each industrial device, determine all industrial devices covered by each edge terminal; adjust the monitoring mode of each edge terminal according to the real-time working status of all the covered industrial devices. According to the monitoring mode, extract the local data stream formed by all industrial devices covered by each edge terminal; identify the data type of the local data stream and mark the occupied segment of valid data in the local data stream; perform time calibration and data rate calibration on all occupied segments to determine the data stream characteristic parameters. Based on the data stream characteristic parameters, predict the accumulation trend of effective data components at each edge; based on the accumulation trends of all effective data components and the cache limit of each edge, set the data upload logic for all edge edges.

3. The data traceability and operation control method based on blockchain evidence storage as described in claim 1, characterized in that: Based on the data upload logic and cloud operation status parameters, a dual-format data queue is generated; The dual-format data queue is locally retained and uploaded to the blockchain to form an associated local cache queue and blockchain evidence storage queue, including: According to the data upload logic, valid data component fragments matching the data volume are extracted locally from each edge terminal, and all extracted valid data component fragments are arranged to form an initial data queue. Based on the real-time compatible data format in the cloud, the initial data queue is subjected to data format identification and partial data format conversion to generate a modified data queue; the initial data queue and the modified data queue are aligned and calibrated on the time axis to generate a dual-format data queue; the initial data queue and the modified data queue are completely identical in data content, only the data format is different, and both are arranged in the same timestamp order; The initial data queue and the changed data queue under the dual-format data queue are locally retained and uploaded to the blockchain, respectively. Based on the real-time progress of the blockchain upload, the initial data queue and the changed data queue are updated to form an associated local cache queue and a blockchain evidence queue. The update refers to deleting the corresponding uploaded data segment from the locally retained initial data queue whenever some data in the changed data queue is successfully uploaded to the blockchain, thereby achieving dynamic synchronization between the local queue and the blockchain evidence queue. Successful upload means that the blockchain node returns a transaction receipt and the transaction has been confirmed by the network in the block. If the upload fails, the data segment is added back to the head of the changed data queue.

4. The data traceability and operation control method based on blockchain evidence storage as described in claim 1, characterized in that: Based on network link quality parameters, the data interruption characteristics of the blockchain evidence storage queue are identified, and the data segments are dynamically traced in the local cache queue to obtain the supplementary data segments. Based on the supplemented data segments, adjust the cloud's operating status, including: Monitor the network link quality parameters between each edge device and the cloud, and obtain the block height or transaction hash corresponding to the last successfully uploaded data in the blockchain evidence queue. Use the block height or transaction hash as the last confirmed upload point. Use the timestamp of the data corresponding to the last confirmed upload point as the starting boundary of the unuploaded data segment. Mark the data generated after the starting boundary until the communication is restored as the unuploaded data segment and determine its time axis coverage range as the data interruption feature. If there is data in the transmission queue before the communication interruption but has not yet been confirmed for upload, the data in the transmission queue but has not yet been confirmed for upload is also included in the unuploaded data segment. The local cache queue is dynamically traced according to the time axis coverage interval, and a supplementary data segment is obtained from the local cache queue; wherein the supplementary data segment has the same time axis coverage interval as the data segment, and the supplementary data segment is the original local data that has not yet been uploaded to the blockchain; Based on the time axis coverage interval label of the supplemented data segment, when communication is restored at the cloud edge, the supplemented data segment is uploaded to the blockchain space of the cloud and added to the chain as a new block. When stored on the blockchain, each data entry contains the original data generation time and the supplemented upload time. When the application layer queries or the smart contract processes the data, the data is sorted and indexed by reading the master timestamp, thereby achieving logical alignment in the business time sequence.

5. The data traceability and operation control method based on blockchain evidence storage according to claim 2, characterized in that, Configure the priority order of data upload logic for all edge devices, including: Step S31: Obtain the real-time status parameters of each edge terminal; wherein, the real-time status parameters of the i-th edge terminal include the current cache usage of the i-th edge terminal. Cache limit Rate of change in cache usage during the current sampling period and the data importance weight of subordinate industrial equipment. ;in, The preset data sampling time interval, This represents the difference between the current time and the previous time at the i-th edge. Step S32: Determine the upload urgency index of each edge terminal based on the real-time status parameters of each edge terminal and the preset upload urgency index formula; Specifically, the preset upload urgency index formula is as follows: ； This represents the upload urgency index of the i-th edge. The default cache growth rate is the normalized baseline value, and ; , , Let the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient all have values ​​greater than zero and less than 1, and satisfy the following conditions: ; Step S33: The calculated upload urgency index is used as the priority order quantification value of each edge terminal, and all edge terminals are sorted in descending order of upload urgency index to obtain the priority order.

6. The data traceability and operation control method based on blockchain evidence storage according to claim 5, characterized in that, Set the single upload data limit in the data upload logic of all edge devices, including: Step S41: Obtain the dynamic constraint parameters of each edge, wherein the dynamic constraint parameters of the i-th edge include the remaining cache space of the i-th edge. Available network bandwidth measured in the previous control cycle And the urgency index for uploading ; Step S42: Determine the single upload data limit for each edge terminal based on the dynamic constraint parameters of each edge terminal and the preset dynamic adaptive upload quota formula. Specifically, the preset dynamic adaptive upload quota formula is as follows: ； in, The preset cache security factor has a value range of [value range missing]. ; The preset upload control period duration; This is the preset minimum bandwidth utilization constant, with a value range of [value range missing]. ; This is a preset hard limit for a single upload at the i-th edge. Step S43: The calculated single upload data limit is used as the upper limit of the amount of data extracted by each edge terminal from the local cache and formed into an initial data queue within the current upload control cycle, so as to adaptively adjust the upload load of each edge terminal.

7. A data traceability and operation control system based on blockchain-based evidence storage, characterized in that: include: The data fluctuation determination module is used to monitor the local data streams at each edge of the industrial site and determine the characteristic parameters of the data streams. The upload logic setting module is used to set the data upload logic for all edge terminals based on the data stream characteristic parameters. The data queue generation module is used to generate a dual-format data queue based on the data upload logic and cloud operation status parameters; and to perform local retention and blockchain upload on the dual-format data queue to form an associated local cache queue and blockchain evidence queue. The traceability module is used to identify the data interruption characteristics of the blockchain evidence storage queue based on network link quality parameters, so as to dynamically trace the data in the local cache queue and obtain the supplementary data segment. The adjustment module is used to adjust the cloud's operating status based on the supplemented data segment.

8. The data traceability and operation control system based on blockchain evidence storage as described in claim 7, characterized in that: The data fluctuation determination module is used to monitor the local data streams at each edge of the industrial site and determine the data stream characteristic parameters, including: Based on the access location of each edge terminal in the industrial site and the communication link of each industrial device, determine all industrial devices covered by each edge terminal; adjust the monitoring mode of each edge terminal according to the real-time working status of all the covered industrial devices. According to the monitoring mode, the local data streams formed by all industrial devices covered by each edge terminal are extracted; the data type of the local data stream is identified, and the occupied segments of valid data in the local data stream are marked; the time and data rate of all occupied segments are calibrated to determine the data stream characteristic parameters; wherein, the data stream characteristic parameters refer to the statistical characteristics of the arrival rate of valid data components in the local data stream per unit time, specifically the variance or standard deviation of the arrival rate; The upload logic setting module is used to set the data upload logic for all edge terminals according to the data stream characteristic parameters, including: Based on the data stream characteristic parameters, predict the accumulation trend of effective data components at each edge; based on the accumulation trends of all effective data components and the cache limit of each edge, set the data upload logic for all edge edges.

9. The data traceability and operation control system based on blockchain evidence storage as described in claim 7, characterized in that: The data queue generation module is used to generate a dual-format data queue based on the data upload logic and cloud operation status parameters; The dual-format data queue is locally retained and uploaded to the blockchain to form an associated local cache queue and blockchain evidence storage queue, including: According to the data upload logic, valid data component fragments matching the data volume are extracted locally from each edge terminal, and all extracted valid data component fragments are arranged to form an initial data queue. Based on the real-time compatible data format in the cloud, the initial data queue is subjected to data format identification and partial data format conversion to generate a modified data queue; the initial data queue and the modified data queue are aligned and calibrated on the time axis to generate a dual-format data queue; the initial data queue and the modified data queue are completely identical in data content, only the data format is different, and both are arranged in the same timestamp order; The initial data queue and the changed data queue under the dual-format data queue are locally retained and uploaded to the blockchain, respectively. Based on the real-time progress of the blockchain upload, the initial data queue and the changed data queue are updated to form an associated local cache queue and a blockchain evidence queue. The update refers to deleting the corresponding uploaded data segment from the locally retained initial data queue whenever some data in the changed data queue is successfully uploaded to the blockchain, thereby achieving dynamic synchronization between the local queue and the blockchain evidence queue. Successful upload means that the blockchain node returns a transaction receipt and the transaction has been confirmed by the network in the block. If the upload fails, the data segment is added back to the head of the changed data queue.

10. The data traceability and operation control system based on blockchain evidence storage as described in claim 7, characterized in that: The tracing module is used to calibrate the data interruption characteristics of the blockchain evidence storage queue based on network link quality parameters, thereby dynamically tracing back in the local cache queue to obtain the supplementary data segment, including: Monitor the network link quality parameters between each edge device and the cloud, and obtain the block height or transaction hash corresponding to the last successfully uploaded data in the blockchain evidence queue. Use the block height or transaction hash as the last confirmed upload point. Use the timestamp of the data corresponding to the last confirmed upload point as the starting boundary of the unuploaded data segment. Mark the data generated after the starting boundary until the communication is restored as the unuploaded data segment and determine its time axis coverage range as the data interruption feature. If there is data in the transmission queue before the communication interruption but has not yet been confirmed for upload, the data in the transmission queue but has not yet been confirmed for upload is also included in the unuploaded data segment. The local cache queue is dynamically traced according to the time axis coverage interval, and a supplementary data segment is obtained from the local cache queue; wherein the supplementary data segment has the same time axis coverage interval as the data segment, and the supplementary data segment is the original local data that has not yet been uploaded to the blockchain; The adjustment module is used to adjust the cloud's operating status based on the supplemented data segment, including: Based on the time axis coverage interval label of the supplemented data segment, when communication is restored at the cloud edge, the supplemented data segment is uploaded to the blockchain space of the cloud and added to the chain as a new block. When stored on the blockchain, each data entry contains the original data generation time and the supplemented upload time. When the application layer queries or the smart contract processes the data, the data is sorted and indexed by reading the master timestamp, thereby achieving logical alignment in the business time sequence.

Images