Cross-chain meteorological and hydrological data consistency verification method oriented to multi-block chain collaboration

Abstract

The invention discloses a cross-chain meteorological and hydrological data consistency verification method oriented to multi-block-chain collaboration, which effectively solves the problem of data alignment caused by inconsistent time standards in a multi-chain environment by collecting multi-source data and generating a data tuple with a geographic identifier and distributing a unified reference timestamp for the data in combination with a physical clock synchronization mechanism. And furthermore, the time deviation is extracted through a layered verification structure and inter-chain cross check, and the timestamp weight is dynamically adjusted, so that the time synchronization precision of the cross-chain data is improved. Finally, a standardized time sequence is generated through segmented aggregation of the data, cross-chain storage is completed, regular backtracking verification is performed in combination with a supervision chain, time consistency and content credibility of the meteorological and hydrological data in the cross-chain circulation process are guaranteed, and efficient collaboration and traceability between heterogeneous block chain systems are achieved.

Description

Technical Field

[0001] The present invention belongs to the field of data processing technology, and specifically relates to a cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration. Background Art

[0002] With the rapid development of blockchain technology, its applications in data storage, trusted sharing, and other fields are becoming increasingly widespread. However, in time-sensitive scenarios such as meteorological and hydrological monitoring, the varying consensus mechanisms and time management strategies employed by different blockchain systems make it difficult to unify cross-chain data in the temporal dimension, impacting the data consistency and verifiability of multi-chain collaboration. Existing technologies typically provide time identification for cross-chain data through a single on-chain timestamp or centralized time server. However, such approaches cannot effectively address the significant differences in time bases and low synchronization accuracy between chains, potentially leading to risks such as data time disarray and verification failures.

[0003] Therefore, how to achieve unified timestamp alignment of meteorological and hydrological data between multiple blockchains with different consensus mechanisms has become a key technical challenge in current cross-chain data collaboration. Summary of the Invention

[0004] The purpose of this invention is to provide a cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration, which effectively improves the consistency and credibility of cross-chain data in the time dimension, ensures the accurate aggregation and retrospective verification of meteorological and hydrological observation data in a distributed heterogeneous chain environment, and solves the technical problems in the existing technology of data incomparability and difficulty in verification due to inconsistent time bases.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration, comprising the following steps:

[0006] Collect multi-source meteorological and hydrological raw data to generate an initial data set containing geographic identifiers and observation values. Through a preset cross-chain time anchor generator, assign a reference timestamp based on physical clock synchronization to the initial data set; bind the reference timestamp to the initial data set to form a cross-chain data packet with a time identifier, and use a hierarchical verification structure to perform intra-chain verification on the cross-chain data packet to confirm the correlation between the timestamp and the observation value; cross-validate the cross-chain data packet through a multi-chain consensus node, extract the inter-chain deviation value of the timestamp, and dynamically adjust the timestamp weight allocation strategy of the cross-chain data packet based on the inter-chain deviation value; perform segmented aggregation operations on the adjusted cross-chain data packet to generate standardized time series data, distribute the standardized time series data to the target blockchain, and complete cross-chain storage; regularly backtrack the standardized time series data through the supervision chain to verify the consistency of the timestamp and the observation value.

[0007] Preferably, generating an initial data set containing geographic identifiers and observations includes:

[0008] Obtain raw observation records from sensor devices deployed in different regions and extract temperature, humidity, precipitation, and water flow velocity parameters;

[0009] Bind the latitude and longitude coordinates of each sensor to its corresponding raw observation parameters one-to-one to construct a raw data tuple, where the latitude and longitude represent the sensor's geographic location, and the observation parameters include temperature, humidity, precipitation, and water flow velocity;

[0010] Performing a time stamp operation on the original data tuples, adding a collection time to each tuple, and generating an extended tuple;

[0011] The extended tuples are grouped and aggregated according to a preset time window to generate an initial data set divided by region and time period, wherein each data group corresponds to geographic data within a time window.

[0012] Preferably, allocating a reference timestamp based on physical clock synchronization to the initial data set includes:

[0013] Select a unified physical time source and obtain the current Coordinated Universal Time as the basic reference time;

[0014] For each extended tuple in the geographic data group, calculate the difference between its local collection time and the basic reference time;

[0015] Perform statistical analysis on all differences to determine the time offset benchmark and correct the time records in the initial data set accordingly;

[0016] The time field of each extended tuple is adjusted using the time offset reference to generate a calibrated timestamp under a unified reference, and the calibrated timestamp replaces the original acquisition time to complete timestamp alignment.

[0017] Preferably, forming a cross-chain data packet with a time stamp includes:

[0018] Extracting the geographic identifier, the observation value, and the corresponding calibration timestamp from the extended tuple that completes the time alignment, and structurally combining the calibration timestamp with the observation value to generate a time-bound record unit;

[0019] According to the blockchain transmission unit format, multiple time-bound record units are packaged into a unified data block; the data block is encapsulated into a cross-chain data packet, including the source chain identifier, target chain list and integrity summary, to complete the data organization.

[0020] Preferably, confirming the correlation between the timestamp and the observation value includes:

[0021] Parse the cross-chain data packet on the source chain node, extract the data block and its integrity summary; recalculate the local data summary for each time-bound record unit in the data block, and build the overall verification chain of the block;

[0022] Comparing the overall verification chain with the integrity summary, if they are consistent, confirming that the timestamp and the corresponding observation value have not been tampered with;

[0023] Combined with the calibration timestamp, the historical records in the adjacent time window are searched on the local chain to verify whether the current observation value change trend meets the time continuity constraint.

[0024] Preferably, obtaining the inter-chain deviation value of the timestamp includes:

[0025] The cross-chain data packet is broadcast to the target chain network, and the consensus nodes on each chain receive and parse the calibration timestamp and geographic identifier;

[0026] Each consensus node records the presentation moment of the calibration timestamp in the local view based on the local chain’s time recording system and calculates the single-chain deviation;

[0027] All participating nodes upload the single-chain deviation to the coordination node, which aggregates the deviations to form a set of inter-chain time deviations.

[0028] A weighted average process is performed on the inter-chain time offset set to obtain a global inter-chain offset estimate, which is used for subsequent timestamp adjustment.

[0029] Preferably, dynamically adjusting the timestamp weight distribution strategy of the cross-chain data packet includes:

[0030] Obtain the inter-chain time deviation set and the global inter-chain deviation estimate, and calculate the relative deviation of each chain's single chain deviation; assign a timestamp correction weight to each chain based on the relative deviation, so that chains with higher deviations receive lower weights;

[0031] The weights are applied to the packet timestamp adjustment process of the corresponding chain to generate weighted aligned timestamps and achieve dynamic adaptive synchronization.

[0032] Preferably, generating standardized time series data includes:

[0033] Divide the weighted aligned timestamps into continuous time intervals according to a unified time granularity, and set the start and end times of each interval;

[0034] Collect all cross-chain data records belonging to each time interval and spatially classify them according to geographical identifiers to form regional observation groups. The average value of the observations in each regional observation group is calculated based on the time-corrected weight of the corresponding chain.

[0035] The average value in each time interval is combined with the time label to generate a structured time series entry, which is then aggregated to form a standardized time series dataset.

[0036] Preferably, distributing the standardized time series data to the target blockchain includes:

[0037] Extracting structured time series entries from the standardized time series dataset and appending source chain signatures for identification;

[0038] Determine the target blockchain address corresponding to each structured time series entry and generate a package with a path identifier;

[0039] Submit the package to the corresponding target chain, and the verification node on the target chain confirms the legitimacy of the data source based on the signature of the source chain;

[0040] Create a block record corresponding to the structured time series entry on the target chain, perform the write operation, and return a cross-chain storage confirmation receipt, which is fed back to the source chain to complete the closed-loop confirmation.

[0041] Preferably, the standardized time series data is periodically traced back through the chain of custody to verify the consistency of the timestamps with the observed values, including:

[0042] Within a preset period, the chain of custody initiates a sampling request for historical time series entries and selects data samples containing time tags, geographical identifiers, and observation means;

[0043] According to the time tag, the corresponding original record unit and package package are retrieved in the source chain and each target chain to build a complete data traceability path;

[0044] Perform consistency comparison on the time fields in the data traceability path to verify whether the time deviation constraint is met;

[0045] If the timestamp deviation is found to exceed the preset boundary or the difference between the observed mean and the original observation value exceeds the allowable threshold, an anomaly flag is triggered.

[0046] Technical effects and advantages of the present invention: The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration proposed in the present invention has the following advantages over the existing technology:

[0047] This invention collects multi-source data and generates data tuples with geographical identifiers, and uses a physical clock synchronization mechanism to assign a unified reference timestamp to the data, effectively solving the data alignment problem caused by inconsistent time standards in a multi-chain environment. Furthermore, through a layered verification structure and inter-chain cross-verification, time deviations are extracted, and timestamp weights are dynamically adjusted, thereby improving the time synchronization accuracy of cross-chain data. Finally, by segmenting and aggregating data to generate standardized time series and completing cross-chain storage, combined with regular backtracking verification of the regulatory chain, the temporal consistency and content credibility of meteorological and hydrological data during cross-chain circulation are guaranteed, achieving efficient collaboration and traceability between heterogeneous blockchain systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 This is a flowchart of the cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration of the present invention. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. The specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0050] The present invention provides Figure 1 The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration shown includes the following steps:

[0051] Step 1: Collect multi-source meteorological and hydrological raw data to generate an initial dataset containing geographic identifiers and observation values; this includes the following steps:

[0052] Obtain original observation records from sensor equipment deployed in different regions and extract parameters such as temperature (A), humidity (B), precipitation (C), and water flow velocity (D). These parameters together constitute a basic data set reflecting the regional climate status and water resource dynamics.

[0053] The longitude and latitude coordinates of each sensor The corresponding observation parameters Perform one-to-one binding to construct the original data tuple , where Xi and Yi represent the geographical location of the i-th sensor, Indicates the collection moment; this tuple realizes the trinity expression of spatial positioning, time tag and environmental parameters.

[0054] Perform timestamp marking operation on the original data tuples, adding the collection time to each tuple , generate extended tuple ; The timestamp is provided by a high-precision clock and the error is controlled within the allowable range.

[0055] Group and aggregate the extended tuples according to the preset time window ΔW to generate the initial data set divided by region and time period , where each geographic data set Represents a group of geographic data within a time window.

[0056] Step 2: Assign a reference timestamp based on physical clock synchronization to the initial data set through a preset cross-chain time anchor generator; including the following steps:

[0057] Select a globally unified physical time source (such as GPS or NTP server) and obtain the current Coordinated Universal Time (UTC) as the basic reference time , used to eliminate the time difference problem between the local clocks of different sensors.

[0058] For each geographic data set The extended tuple in , calculates its local collection time With reference time The deviation between ; A positive value means the local time is ahead of UTC, a negative value means the opposite.

[0059] All Perform statistical analysis to determine the time offset benchmark , and accordingly correct the time records in the initial data set; the time deviation of all acquisition points in the same time window Perform averaging to obtain a deviation benchmark that represents the overall trend This benchmark is then used to perform batch corrections on the original timestamps to remove systematic biases.

[0060] Using a time-shifted benchmark Adjust the time field of each extended tuple to generate a calibrated timestamp under a unified benchmark , and replace the original , complete timestamp alignment.

[0061] Step 3: Bind the reference timestamp to the initial data set to form a cross-chain data packet with a time stamp; including the following steps:

[0062] Extract the geographic identifier from the extended tuple after completing the time alignment , observations and the corresponding calibration timestamp These fields constitute the basic data unit with temporal and spatial consistency. Xi represents longitude and Yi represents latitude.

[0063] The timestamp will be calibrated Combined with observations to generate time-bound record units ; Combine the above seven fields into a structured record unit U_i in a fixed format, so that each record contains a complete spatial location, environmental observation value and a unified timestamp, thereby achieving spatiotemporal traceability of the data.

[0064] According to the blockchain transmission unit format, multiple time-bound record units U_i are packaged into a unified data block B, and an integrity summary H(B)=SHA256(B) is attached for subsequent verification, which represents the unique fingerprint of the block content. Once the data is modified, H(B) will undergo irreversible changes, thereby detecting an abnormality.

[0065] Encapsulate data block B into a cross-chain data packet P, including the source chain identifier , target chain list and the completeness summary H(B), completing the data organization.

[0066] Step 4: Using a hierarchical verification structure, perform intra-chain verification on the cross-chain data packet to confirm the correlation between the timestamp and the observed value; including the following steps:

[0067] After the cross-chain transmission is completed, the cross-chain data packet P is parsed on the source chain node to extract the data block B and its integrity summary H(B); where B contains multiple record units bound to timestamps , H(B) is the summary value generated by the SHA256 algorithm for the entire content of the block.

[0068] For each time-bound record unit in data block B Recalculate the local hash value , and build the overall verification chain of the block Specifically, the system reads U_i one by one and calculates its local hash using the same hash algorithm (such as SHA256) , then all The blocks are concatenated in sequence and hashed again to generate a verification chain V_chain representing the entire block content.

[0069] Compare the entire verification chain with the integrity summary H(B). If , then confirm the timestamp The corresponding observations have not been tampered with; combined with the calibration timestamp Search the local chain for historical records within the adjacent time window to verify whether the current observation trend meets the time continuity constraint: If the difference is less than the preset threshold , it is considered that the acquisition frequency is stable and the time series is reasonable; otherwise, there may be time dislocation or abnormal acquisition.

[0070] Step 5: Cross-validate the cross-chain data packet through a multi-chain consensus node to extract the inter-chain deviation value of the timestamp; including the following steps:

[0071] After the source chain completes the initial verification, the cross-chain data packet P is broadcast to the target chain network, and the consensus nodes on each chain receive and parse the calibration timestamp. Geographical indications ; Each consensus node records the calibration timestamp according to the local chain's time recording system Rendering time in local view , and calculate the single-chain deviation A positive value indicates that the local chain time is faster than the source chain time, while a negative value indicates the opposite.

[0072] All participating nodes will deviate from the single chain Upload to the coordination node and aggregate to form a set of inter-chain time deviations , used to further analyze the overall inter-chain time consistency.

[0073] Perform weighted averaging on the inter-chain time deviation set to obtain the global inter-chain deviation estimate Δ This value will serve as an important basis for timestamp adjustment, used to correct the time tags of subsequent transmitted data and improve cross-chain consistency.

[0074] Step 6: Dynamically adjust the timestamp weight distribution strategy of the cross-chain data packet based on the inter-chain deviation value; including the following steps:

[0075] Get the inter-chain time deviation set Estimation of global inter-chain deviation ; Used to reflect the individual differences of each chain, It represents the level of cognitive deviation of the entire chain network from the source chain time.

[0076] Single chain bias for each chain Calculate relative deviation , used to measure the stability of the chain's time record; the larger the value, the more unstable or abnormal the chain's time record is.

[0077] According to the relative deviation Assigning timestamp-corrected weight to each chain , so that the chain with high deviation gets lower weight; this formula is a nonlinear decay function, which ensures that the weight varies between 0 and 1, and The larger it is, the lower the weight.

[0078] The weight The timestamp adjustment process of the data packets applied to the corresponding chain generates weighted aligned timestamps , to achieve dynamic adaptive synchronization. This formula means that on the basis of a unified benchmark, the actual time perception results of each chain are integrated to form a more representative cross-chain time label.

[0079] Step 7: Perform segment aggregation operations on the adjusted cross-chain data packet to generate standardized time series data; including the following steps:

[0080] Align weighted timestamps with a uniform time granularity (e.g., 15 minutes, 30 minutes, or 1 hour) Divide into continuous time intervals and set the start time of each interval and the end moment ; Each window represents a fixed-length data collection cycle, which is used to organize and analyze data by time period.

[0081] In each time interval Collect all cross-chain data records belonging to the period and identify them according to geographical identification Perform spatial classification to form regional observation groups ; each Represents the set of all observations within a geographic area and within a specific time period.

[0082] For each regional observation group The observation values ​​A, B, C, and D in the calculation are weighted averaged, and the weights are determined by the time correction weights of the corresponding chains. Determine, the calculation formula is:

[0083] ;

[0084] ;

[0085] ;

[0086] ;

[0087] For each group The system corrects the weight of the time carried by the reported data of each target chain based on the time , a weighted average is calculated for temperature (A), humidity (B), precipitation (C), and water velocity (D) to reflect the credibility of the observation results of different chains in the region. The larger the weight, the more stable the chain data is and the greater its influence on the final result.

[0088] Combine the weighted results in each time interval with the time label Combining to generate structured time series entries , aggregated to form the standardized time series dataset TS.

[0089] Step 8: Distribute the standardized time series data to the target blockchain to complete cross-chain storage; including the following steps:

[0090] Extract structured time series entries from a normalized time series dataset , and append the source chain signature Used for identity identification and subsequent target chain verification of the authenticity and integrity of the data source.

[0091] According to the preset cross-chain routing rules R (such as based on regional division, business type or regulatory affiliation), each structured time series entry is determined The corresponding target blockchain address , and generate a package with path identification , as the basic unit of cross-chain transmission.

[0092] Submit the package Pkt to the corresponding target chain through the LightNodeProxy, and the verification node on the chain will sign according to the source chain Confirm the legitimacy of the data source; Specifically, after receiving the Pkt, the verification node of the target chain first parses And verify its validity to confirm that the data does indeed come from a trusted source chain to prevent forgery or man-in-the-middle attacks.

[0093] Create and structure time series entries on the target chain The corresponding block record performs the write operation and returns the cross-chain storage confirmation receipt , used to prove that the data has indeed been successfully landed on the target chain. The receipt is then fed back to the source chain, forming a complete cross-chain processing closed loop.

[0094] Step 9: Regularly trace back the standardized time series data through the chain of custody to verify the consistency of the timestamps and observed values; including the following steps:

[0095] In the preset cycle (e.g. hourly, daily or weekly), the chain of custody initiates the review of historical time series entries Sampling request, select the one containing the time tag , geographical identifiers (Xi, Yi) and observed mean Data samples;

[0096] By time tag Retrieve the corresponding original record unit in the source chain and each target chain and its encapsulation package Pkt, building a complete data traceability path ; This path covers the entire process from original collection to final aggregation, providing full-chain evidence for subsequent consistency verification.

[0097] Perform consistency comparison on the time fields in the data traceability path to verify whether the following conditions are met: Specifically, the system checks the timestamps of different stages in the Path in turn, focusing on verifying whether two key differences are within the allowable range: one is the original calibration timestamp With the final time label The deviation between the two is the weighted alignment timestamp and If any of the above differences exceeds the preset threshold , it is determined to be time inconsistent.

[0098] : Indicates that the original calibration time and the final aggregation time should maintain a reasonable deviation range to ensure time continuity;

[0099] : Indicates that there should be no significant deviation between the cross-chain adjusted time and the center point of the standard time window.

[0100] If the timestamp deviation is found to exceed the preset limit Or if the difference between the observed mean and the original observed value exceeds the allowable threshold ε, the abnormal flag is triggered , and initiate a manual verification process to confirm whether there are any problems such as data forgery, transmission errors or node anomalies.

[0101] The following will further illustrate the specific operating steps of the above-mentioned cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration with specific examples:

[0102] Assume that three meteorological sensors (S1, S2, S3) are deployed in a certain area, located in different geographical locations. , continuously collecting data such as temperature A, humidity B, precipitation C, and water flow speed D. The goal is to achieve consistency verification of cross-chain data through blockchain technology and generate standardized time series data.

[0103] Step 1: Collecting raw meteorological and hydrological data from multiple sources

[0104] Sensor data collection:

[0105] ;

[0106] ;

[0107] .

[0108] Time window division:

[0109] The preset time window ΔW = 2 minutes divides the data into two time groups:

[0110] :[16:00:00-16:02:00] (including S1 and S2);

[0111] :[16:02:00-16:04:00] (S3 only).

[0112] Step 2: Cross-chain Time Anchor Generator Calibrates Timestamps

[0113] Select UTC reference time, =16:00:00UTC (Universal Time);

[0114] Calculate the local time offset:

[0115] =16:00:00-16:00:00=0s;

[0116] =16:01:30-16:00:00=90s;

[0117] =16:02:15-16:00:00=135s.

[0118] Statistical time offset benchmark, ;

[0119] Generate calibration timestamp:

[0120] =16:00:00+75s=16:01:15;

[0121] =16:01:30+75s=16:02:45;

[0122] = 16:02:15 + 75s = 16:03:30.

[0123] Step three: Generate cross-chain data packet

[0124] Build time binding record unit U_i:

[0125] = (116°E, 39°N, 28, 65, 0, 1.2, 16:01:15);

[0126] = (117°E, 40°N, 26, 70, 2, 0.8, 16:02:45);

[0127] = (118°E, 41°N, 25, 68, 1, 1.0, 16:03:30).

[0128] Pack data block B:

[0129] ;

[0130] H(B) = SHA256(" ") = "a1b2c3d4...".

[0131] Encapsulate cross-chain data packet P:

[0132] = "weather chain 1";

[0133] = ["water chain", "traffic chain"];

[0134] P = (B, "a1b2c3d4...", "weather chain 1", ["water chain", "traffic chain"]).

[0135] Step four: In-chain verification

[0136] Parse the data packet and verify the hash:

[0137] Recalculate = = "a1b2c3d4...";

[0138] If == H(B), the data has not been tampered with.

[0139] Time continuity check:

[0140] For , = 16:00:00 (historical record), = 120s:

[0141] |16:01:15-16:00:00|=75s<120s→Reasonable.

[0142] Step 5: Multi-chain cross-validation

[0143] Broadcast the data packet to the target chain, and the target chain node records the local time:

[0144] Water chain: =16:01:30 (deviation );

[0145] Traffic chain: =16:02:00 (deviation ).

[0146] Aggregating inter-chain deviations: ={15s,15s}; =(15+15) / 2=15s.

[0147] Step 6: Dynamically adjust timestamp weight

[0148] Calculate the relative deviation: .

[0149] Assign weights: .

[0150] Generate weighted alignment timestamps: ;

[0151] For example: =16:01:15+(115+115)=16:01:45.

[0152] Step 7: Segment aggregation to generate standardized data

[0153] Time interval division: time window ;

[0154] Space classification: ={S1,S2} (same area);

[0155] Weighted average calculation:

[0156] =(128+126) / (1+1)=27°C;

[0157] =(165+170) / 2=67.5%;

[0158] =(16:01:00+16:03:00) / 2=16:02:00.

[0159] Generate structured entries: =(16:02:00,116°E,39°N,27,67.5,1.5,1.0).

[0160] Step 8: Cross-chain storage

[0161] Attach source chain signature: = "Weather Chain 1_Signature".

[0162] Package and submit: .

[0163] Target chain write confirmation: =HASH("E_t+water chain address")="e9f8a7b6...".

[0164] Step 9: Chain of Custody Traceability Verification

[0165] Sampling request: Select =(16:02:00,116°E,39°N,27,67.5,1.5,1.0).

[0166] Construct the traceability path: .

[0167] Time consistency verification:

[0168] =|16:01:15-16:02:00|=45s≤ =60s → reasonable;

[0169] =|16:01:45-16:02:00|=15s≤ =60s→reasonable.

[0170] Exception markers:

[0171] If the observed mean =27°C with original Difference exceeds threshold , then trigger .

[0172] Final result:

[0173] Standardized time series dataset TS: contains multiple entries, as in the example above.

[0174] Cross-chain storage confirmation: data is successfully written into the water conservancy chain, receipt .

[0175] Regulatory check: all timestamps and observations are verified for consistency, no exceptions flagged.

[0176] Through this process, cross-chain trusted storage and dynamic verification of multi-source meteorological and hydrological data are realized, ensuring the integrity, consistency and traceability of the data.

[0177] Finally, it should be noted that the above only for the preferred embodiments of the present application, and is not intended to limit the present application, although the foregoing embodiments of the present application have been described in detail, for those skilled in the art, it still can be modified, or part of the technical features of the equivalent replacement, within the spirit and principles of the present application, any modification, equivalent replacement, improvement, etc., should be included within the scope of the present application.

Claims

1. A cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration, characterized by: The following steps are involved: Collect multi-source meteorological and hydrological raw data to generate an initial dataset containing geographic identifiers and observation values. Use a preset cross-chain time anchor generator to assign a reference timestamp based on physical clock synchronization to the initial dataset. Bind the reference timestamp to the initial data set to form a cross-chain data packet with a time stamp. Use a layered verification structure to perform intra-chain verification on the cross-chain data packet to confirm the correlation between the timestamp and the observed value. Cross-validate the cross-chain data packet through a multi-chain consensus node, extract the inter-chain deviation value of the timestamp, and dynamically adjust the timestamp weight distribution strategy of the cross-chain data packet based on the inter-chain deviation value; Performing a segmented aggregation operation on the adjusted cross-chain data packet to generate standardized time series data, and distributing the standardized time series data to the target blockchain to complete cross-chain storage; The standardized time series data is regularly traced back through the chain of custody to verify the consistency of the timestamps with the observed values.

2. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 1 is characterized by: Generate an initial dataset containing geographic identifiers and observations, including: Obtain raw observation records from sensor devices deployed in different regions and extract temperature, humidity, precipitation, and water flow velocity parameters; Bind the latitude and longitude coordinates of each sensor to its corresponding raw observation parameters one-to-one to construct a raw data tuple, where the latitude and longitude represent the sensor's geographic location, and the observation parameters include temperature, humidity, precipitation, and water flow velocity; Performing a time stamp operation on the original data tuples, adding a collection time to each tuple, and generating an extended tuple; The extended tuples are grouped and aggregated according to a preset time window to generate an initial data set divided by region and time period, wherein each data group corresponds to geographic data within a time window.

3. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 2 is characterized by: Allocating a reference timestamp based on physical clock synchronization to the initial data set includes: Select a unified physical time source and obtain the current Coordinated Universal Time as the basic reference time; For each extended tuple in the geographic data group, calculate the difference between its local collection time and the basic reference time; Perform statistical analysis on all differences to determine the time offset benchmark and correct the time records in the initial data set accordingly; The time field of each extended tuple is adjusted using the time offset reference to generate a calibrated timestamp under a unified reference, and the calibrated timestamp replaces the original acquisition time to complete timestamp alignment.

4. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 3 is characterized by: Form a cross-chain data packet with a time stamp, including: Extracting the geographic identifier, the observation value, and the corresponding calibration timestamp from the extended tuple that completes the time alignment, and structurally combining the calibration timestamp with the observation value to generate a time-bound record unit; According to the blockchain transmission unit format, multiple time-bound record units are packaged into a unified data block; the data block is encapsulated into a cross-chain data packet, including the source chain identifier, target chain list and integrity summary, to complete the data organization.

5. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 4 is characterized by: Confirm the association between the timestamp and the observation value, including: Parse the cross-chain data packet on the source chain node, extract the data block and its integrity summary; recalculate the local data summary for each time-bound record unit in the data block, and build the overall verification chain of the block; Comparing the overall verification chain with the integrity summary, if they are consistent, confirming that the timestamp and the corresponding observation value have not been tampered with; Combined with the calibration timestamp, the historical records in the adjacent time window are searched on the local chain to verify whether the current observation value change trend meets the time continuity constraint.

6. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 5 is characterized by: The inter-chain deviation value of the timestamp is obtained, including: Broadcast the cross-chain data packet to the target chain network, and the consensus nodes on each chain receive and parse the calibration timestamp and geographic identifier; Each consensus node records the presentation moment of the calibration timestamp in the local view based on the local chain’s time recording system and calculates the single-chain deviation; All participating nodes upload the single-chain deviation to the coordination node, which aggregates the deviations to form a set of inter-chain time deviations. A weighted average process is performed on the inter-chain time offset set to obtain a global inter-chain offset estimate, which is used for subsequent timestamp adjustment.

7. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 6 is characterized by: Dynamically adjust the timestamp weight distribution strategy of the cross-chain data packet, including: Obtain the inter-chain time deviation set and the global inter-chain deviation estimate, and calculate the relative deviation of each chain's single chain deviation; assign a timestamp correction weight to each chain based on the relative deviation, so that chains with higher deviations receive lower weights; The weights are applied to the packet timestamp adjustment process of the corresponding chain to generate weighted aligned timestamps and achieve dynamic adaptive synchronization.

8. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 7 is characterized by: Generate standardized time series data, including: Divide the weighted aligned timestamps into continuous time intervals according to a unified time granularity, and set the start and end times of each interval; Collect all cross-chain data records belonging to each time interval and spatially classify them according to geographical identifiers to form regional observation groups. The average value of the observations in each regional observation group is calculated based on the time-corrected weight of the corresponding chain. The average value in each time interval is combined with the time label to generate a structured time series entry, which is then aggregated to form a standardized time series dataset.

9. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 8 is characterized by: Distributing the standardized time series data to the target blockchain, including: Extracting structured time series entries from the standardized time series dataset and appending source chain signatures for identification; Determine the target blockchain address corresponding to each structured time series entry and generate a package with a path identifier; Submit the package to the corresponding target chain, and the verification node on the target chain confirms the legitimacy of the data source based on the signature of the source chain; Create a block record corresponding to the structured time series entry on the target chain, perform a write operation, and return a cross-chain storage confirmation receipt, which is fed back to the source chain to complete the closed-loop confirmation.

10. The cross-chain meteorological and hydrological data consistency verification method for multi-blockchain collaboration according to claim 9 is characterized in that: Regularly trace back the standardized time series data through the chain of custody to verify the consistency of the timestamps with the observed values, including: Within a preset period, the chain of custody initiates a sampling request for historical time series entries and selects data samples containing time tags, geographical identifiers, and observation means; According to the time tag, the corresponding original record unit and package package are retrieved in the source chain and each target chain to build a complete data traceability path; Perform consistency comparison on the time fields in the data traceability path to verify whether the time deviation constraint is met; If the timestamp deviation is found to exceed the preset boundary or the difference between the observed mean and the original observation value exceeds the allowable threshold, an anomaly flag is triggered.

Images