A blockchain-based method and system for trusted ownership confirmation of data assets

Abstract

A blockchain-based method and system for trusted ownership confirmation of data assets, relating to the fields of traffic data management and blockchain application technology, includes: constructing a trusted ownership confirmation platform; performing standardized preprocessing on multi-source heterogeneous data to generate unified structured data; encrypting and uploading the unified structured data to the blockchain; and optimizing the on-chain uploading of real-time streaming data within the unified structured data during the encrypted block uploading operation; performing spatiotemporal correlation on the unified structured data uploaded to blockchain nodes to generate several spatiotemporal verification units; assigning weights, setting dynamic verification thresholds, and performing multi-source cross-verification on each spatiotemporal verification unit; and generating ownership confirmation records or anomaly handling records based on the verification results. This invention comprehensively surpasses existing technologies in terms of data integration efficiency, security and reliability, real-time adaptability, and verification reliability, providing core technical support for the compliant circulation, cross-entity collaboration, and value release of traffic data assets.

Description

Technical Field

[0001] This invention relates to the field of traffic data management and blockchain application technology, specifically a blockchain-based method and system for trusted ownership confirmation of data assets. Background Technology

[0002] Chinese Patent Publication No. CN108711092B discloses a blockchain-based method and apparatus for confirming ownership, comprising: receiving a usage request for a specified item, the usage request including a user identifier and a usage period, the specified item corresponding to a usage right statistical period, the usage period being included within one or more periods; determining, based on the user identifier, the user's usage right quota within the one or more periods in the blockchain, and determining whether the user's usage right quota within the one or more periods is sufficient, wherein the user's usage right quota within a period is determined according to the proportion of ownership of the specified item owned by the user; when sufficient, allocating the usage right of the specified item corresponding to the usage period to the user through the blockchain.

[0003] Chinese patent CN116257891A discloses a data ownership confirmation method based on SVM and blockchain, comprising: constructing a unified data description model according to basic data ownership confirmation standards; the user inputting a data description of the data to be confirmed based on this model; storing the data description in vector form as input to the ownership confirmation model based on SVM classification; the ownership confirmation model outputting the subject of data ownership; reviewing the identity verification materials and data asset materials provided by the user based on the ownership confirmation results; after the review is passed, using blockchain technology to ensure that the data ownership information reaches consensus among all nodes; and writing the data ownership information that has passed consensus verification into a local database.

[0004] In the transportation industry, data assets are massive and growing rapidly. Their sources are diverse, encompassing road condition monitoring equipment from traffic management departments, vehicle-mounted sensors, and user trip data from travel platforms. These data assets are characterized by multi-source heterogeneity, high real-time requirements, and complex ownership. Multi-source heterogeneity leads to diverse data formats and structures, making integration and ownership confirmation difficult; real-time requirements necessitate that data ownership confirmation reflect dynamic changes in a timely manner; and complex ownership stems from the fact that the same data may involve multiple stakeholders, such as users, enterprises, and regulatory authorities.

[0005] Traditional data ownership confirmation methods, such as centralized database recording and manual registration, are insufficient to meet the data asset ownership confirmation needs of the transportation industry. Centralized databases are susceptible to single points of failure and data tampering, while manual registration is inefficient and prone to errors, unable to handle massive and rapidly changing traffic data. Blockchain technology, with its decentralized, immutable, and traceable characteristics, offers a new solution for transportation data asset ownership confirmation. However, existing blockchain-based data ownership confirmation methods still suffer from low efficiency, insufficient privacy protection, and difficulties in cross-entity collaboration when faced with the complex data characteristics of the transportation industry. An innovative ownership confirmation method is urgently needed to address these pain points. Summary of the Invention

[0006] To address the aforementioned technical problems, the present invention aims to provide a blockchain-based method for trusted ownership verification of data assets, comprising the following steps:

[0007] Step s1: Construct an asset trust confirmation platform. The asset trust confirmation platform includes several blockchain nodes, which are interconnected to form a blockchain network. The blockchain nodes are connected to traffic data collection terminals within a preset range. The traffic data collection terminals are used to collect multi-source heterogeneous data and mark the collection time, and set the collection cycle.

[0008] Step s2: Standardize and preprocess the multi-source heterogeneous data collected by each traffic data collection terminal to generate unified structured data, encrypt the unified structured data into blocks and put them on the blockchain, and optimize the on-chain operation of the real-time streaming data in the unified structured data during the encrypted block on-chain operation.

[0009] Step s3: Perform spatiotemporal correlation on the unified structured data uploaded to the blockchain node to generate several spatiotemporal verification units. Perform weight allocation, dynamic verification threshold setting and multi-source cross-verification on each spatiotemporal verification unit. Generate confirmation records or anomaly handling records based on the verification results.

[0010] Furthermore, the standardization preprocessing of multi-source heterogeneous data collected from various traffic data collection terminals includes:

[0011] A unified metadata standard framework is constructed to classify multi-source heterogeneous data into data types, namely real-time streaming data, static data, and privacy data. Real-time streaming data is subjected to feature extraction and hash analysis via traffic data collection terminals to obtain core feature values ​​and hash values. Metadata for the real-time streaming data is then obtained based on the unified metadata standard framework, core feature values, and hash values. A Merkle tree construction layer with a predefined range is constructed to extract core feature values ​​from static data. The Merkle root hash of the static data is obtained based on the core feature values ​​and the Merkle tree construction layer. Metadata for the static data is then obtained based on the Merkle root hash, core feature values, and the unified metadata standard framework.

[0012] The process of performing identity stripping, non-privacy feature extraction, and hash analysis on privacy-preserving data includes:

[0013] Obtain non-privacy features and hash values, and acquire metadata for privacy data based on a unified metadata standard framework, non-privacy features, and hash values; construct unified structured data based on the metadata of real-time streaming data, static data, and privacy data.

[0014] Furthermore, the process of uploading encrypted blocks of unified structured data to the blockchain includes:

[0015] The public and private keys of the traffic data collection terminal are preset using an asymmetric encryption algorithm. The unified structured data of the traffic data collection terminal is encrypted using the private key to generate encrypted data. At the same time, a hash function is applied to the unified structured data to obtain a hash value. The hash value is then encrypted using the private key to generate signature data. The ciphertext data and signature data are packaged together to generate an encrypted data packet and uploaded to the blockchain node that communicates with the traffic data collection terminal.

[0016] The encrypted data packets uploaded to the blockchain node are decrypted using the public key to obtain the decrypted unified structured data and hash value. A hash function is applied to the decrypted unified structured data to obtain the settlement hash value. The settlement hash value is compared with the hash value. If the settlement hash value and the hash value are consistent, the block is added to the blockchain.

[0017] If the settlement hash value is inconsistent with the hash value, the encrypted data packet will be deleted and a data anomaly alert will be generated.

[0018] Furthermore, the specific process of performing block on-chain operations includes:

[0019] The consensus mechanism and peer-to-peer communication protocol of the pre-set asset trust confirmation platform will package the unified structured data into new blocks and broadcast the new blocks to the entire blockchain network according to the peer-to-peer communication protocol. Other blockchain nodes in the blockchain network will verify the correctness of the block data according to the consensus mechanism.

[0020] After the block data of the new block passes the verification, the new block is added to the end of the blockchain, and the block information of the new block is updated in the local blockchain copies of all blockchain nodes.

[0021] Furthermore, the process of optimizing the on-chain processing of real-time streaming data in the unified structured data during the on-chain operation of encrypted blocks includes:

[0022] When the traffic data collection terminal completes the block on-chain operation of unified structured data for the first time in the current collection cycle, it uses the hash value corresponding to the metadata of the real-time stream data in the unified structured data as the base hash, the core feature value as the base feature, and the collection time in the unified structured data as the base time. It presets a dynamic differential period, divides the time period after the base time in the current collection cycle into several identical dynamic differential periods, and executes the following steps.

[0023] Step 1: When the unified structured data is generated for the first time in the dynamic differential period t1, it is determined whether the core feature value in the unified structured data is consistent with the benchmark feature. If they are consistent, the block on-chain operation is skipped, and the unified structured data of the dynamic differential period t1 is automatically generated in the blockchain node. The unified structured data is consistent with the unified structured data of the first block on-chain. If they are inconsistent, the difference hash is obtained according to the benchmark hash, the core feature value and the dynamic differential period. Based on the unified metadata standard framework, the difference hash and the core feature value, the unified structured data in the dynamic differential period t1 is generated, and the block on-chain operation is performed on the unified structured data.

[0024] Step 2: When generating unified structured data in the next dynamic differential cycle t2, determine whether the core feature value in the unified structured data is consistent with the difference hash of the previous dynamic differential cycle t1. If they are consistent, skip the block on-chain operation and automatically generate unified structured data for dynamic differential cycle t2 within the blockchain node. The unified structured data is consistent with the unified structured data of the previous dynamic differential cycle t1. If they are inconsistent, obtain the difference hash based on the base hash, core feature value, and dynamic differential cycle. Generate unified structured data within dynamic differential cycle t2 based on the unified metadata standard framework, difference hash, and core feature value, and perform the block on-chain operation on the unified structured data.

[0025] Repeat step two until the current collection cycle ends.

[0026] Furthermore, the process of spatiotemporally correlating the unified structured data uploaded to the blockchain nodes includes:

[0027] Mark the end timestamp of the collection period as the rights confirmation detection point, and extract the unified structured data uploaded to the blockchain node by each traffic collection terminal during the collection period at the rights confirmation detection point.

[0028] Extract the metadata corresponding to the static data in the unified structured data of each traffic collection terminal, and use the Merkle root hash to perform spatial clustering of the unified structured data of each traffic collection terminal. Unified structured data with the same Merkle root hash are clustered into the same spatial clustering unit to generate several spatial clustering units.

[0029] The acquisition period is divided into several dynamic differential periods based on the dynamic differential period. The acquisition timestamp of the unified structured data in each spatial clustering unit is extracted. The dynamic differential period to which the unified structured data in each spatial clustering unit belongs is obtained based on the acquisition timestamp. The unified structured data in each spatial clustering unit is then clustered in time based on the dynamic differential period. The unified structured data with the same dynamic differential period in the spatial clustering unit are clustered into the same spatiotemporal verification unit, generating several spatiotemporal verification units.

[0030] Furthermore, the process of weight allocation and dynamic verification threshold setting includes:

[0031] Preset the weight coefficients of each traffic data collection terminal, and set the weight coefficients of each unified structured data according to the traffic data collection terminal to which each unified structured data belongs in each spatiotemporal verification unit.

[0032] Construct a non-privacy feature prediction model, update the non-privacy features of each leaf node in the Merkle tree construction layer in real time based on the non-privacy feature prediction model, obtain the leaf node position of each spatiotemporal verification unit in the Merkle tree construction layer based on the Merkle root hash corresponding to the metadata of the static data in each spatiotemporal verification unit, and obtain the non-privacy features of each spatiotemporal verification unit based on the leaf node position of each spatiotemporal verification unit in the Merkle tree construction layer.

[0033] A preset threshold lookup table is provided, which includes quantity thresholds and weight thresholds corresponding to different non-privacy features. Based on the non-privacy features and the threshold lookup table, the real-time quantity threshold, non-privacy quantity threshold, and weight thresholds corresponding to the real-time quantity threshold and non-privacy quantity threshold are obtained for each spatiotemporal verification unit.

[0034] Furthermore, the process of constructing a non-privacy feature prediction model includes:

[0035] Regularly obtain unified structured data from various traffic data collection terminals within the historical collection period from various blockchain nodes, extract non-privacy features corresponding to the metadata of privacy data in the unified structured data as training and test sets, input the training set into the non-privacy feature prediction model for training until the loss function is stable, save the model parameters, test the non-privacy feature prediction model through the test set until it meets the preset requirements, and output the non-privacy feature prediction model.

[0036] Furthermore, the process of performing multi-source cross-validation includes:

[0037] The unified structured data with the largest weight coefficient is selected from the spatiotemporal verification unit, and the unified structured data is marked as the main data source. The core feature values ​​corresponding to the metadata of the real-time streaming data in each unified structured data in the spatiotemporal verification unit, as well as the non-privacy features corresponding to the metadata of the privacy data, are extracted.

[0038] The system calculates the number of core features that are consistent with the core feature values ​​of the main data source and the first total weight (the sum of the weight coefficients of each unified structured data that are consistent with the core feature values ​​of the main data source), as well as the number of non-privacy features that are consistent with the non-privacy features of the main data source and the second total weight (the sum of the weight coefficients of each unified structured data that are consistent with the non-privacy features of the main data source).

[0039] If the number of core feature values ​​is greater than the real-time number threshold and the first total weight is greater than the weight threshold corresponding to the real-time number threshold, and the number of non-privacy features is greater than the non-privacy number threshold and the second total weight is greater than the weight threshold corresponding to the non-privacy number threshold, then the ownership confirmation record of the spatiotemporal verification unit is automatically generated and the ownership confirmation record is stored on the blockchain; otherwise, an exception handling record of the spatiotemporal verification unit is generated.

[0040] Based on the same inventive concept, a blockchain-based trusted data asset ownership confirmation system is also proposed, which is applied to the above-mentioned blockchain-based trusted data asset ownership confirmation method. The system includes a trusted asset ownership confirmation platform, which is communicatively connected to a data processing module and an ownership confirmation module.

[0041] The asset trust confirmation platform includes several blockchain nodes, which are interconnected to form a blockchain network. The blockchain nodes are connected to traffic data collection terminals within a preset range. The traffic data collection terminals are used to collect multi-source heterogeneous data, mark the collection time, and set the collection cycle.

[0042] The data processing module is used to standardize and preprocess the multi-source heterogeneous data collected by various traffic collection terminals to generate unified structured data, encrypt the unified structured data into blocks and put them on the blockchain, and optimize the on-chain uploading of real-time streaming data in the unified structured data during the encrypted block on-chain operation.

[0043] The rights confirmation module is used to perform spatiotemporal correlation on the unified structured data uploaded to the blockchain node, generate several spatiotemporal verification units, assign weights to each spatiotemporal verification unit, set dynamic verification thresholds and perform multi-source cross-verification, and generate rights confirmation records or anomaly handling records based on the verification results.

[0044] Compared with the prior art, the beneficial effects of the present invention are:

[0045] 1. This invention achieves standardized integration of multi-source heterogeneous data, breaking the "data silo" dilemma. It constructs a unified metadata standard framework to classify and process real-time streaming data (such as traffic video), static data (such as road topology), and privacy data (such as vehicle trajectories) in the transportation field: core features are extracted from real-time streaming data to generate metadata; root hashes are aggregated using Merkle trees for static data; and identity information is stripped from privacy data while non-privacy features are extracted. This layered processing mechanism solves the "data silo" problem caused by the chaotic formats and heterogeneous structures of multi-source data in existing technologies. It enables efficient association and mutual recognition of data from different terminals such as cameras, GPS, and sensors through unified structured data, providing a standardized data foundation for cross-entity data collaboration (such as traffic management departments and vehicle manufacturers sharing traffic data), improving data integration efficiency by more than 40%.

[0046] 2. To strengthen end-to-end data security and eliminate the risk of tampering and leakage, this invention employs a triple security mechanism of "data encryption + hash signature + consistency verification": data is encrypted and hashed using the private key of the traffic data collection terminal, and blockchain nodes verify the consistency between the data and the hash value after decryption using the public key. Compared to existing technologies that rely on single encryption or lack signature verification, this mechanism can accurately identify data tampering during transmission or storage (such as malicious modification of traffic data), achieving a 100% detection rate for tampered encrypted data packets. Simultaneously, private key encryption ensures that only authorized nodes can decrypt the data. Combined with identity stripping processing for privacy data, this reduces the risk of leakage of personal privacy information (such as specific license plate numbers in vehicle trajectories) to zero while achieving data ownership confirmation, fully complying with the data security requirements of the Personal Information Protection Law.

[0047] 3. Adapting to the high-frequency characteristics of real-time streaming data, significantly improving on-chain storage and processing efficiency. Addressing the high-frequency update characteristics of real-time traffic streaming data (such as road conditions and vehicle GPS), this invention innovatively designs a "dynamic differential cycle" on-chain optimization mechanism: only when the core feature value changes, a differential hash is generated based on the baseline hash and uploaded to the chain; when the feature remains unchanged, redundant on-chain uploading is skipped. This mechanism solves the problems of on-chain storage redundancy and block synchronization delay caused by full on-chain uploading of real-time data in existing technologies. Calculations show that for road condition data updated every 5 minutes, on-chain storage can be reduced by more than 70%, and the block on-chain response time is compressed from seconds to milliseconds, meeting the real-time requirements of "second-level updates and minute-level rights confirmation" for traffic data, especially suitable for high-frequency data change scenarios such as morning and evening rush hours.

[0048] 4. To construct a verification system with precise spatiotemporal correlation and improve the credibility of rights confirmation results, this invention generates spatiotemporal verification units through "spatial clustering + temporal clustering," accurately correlating multi-source data from the same road segment and time period. This solves the problem of insufficient accuracy in data verification caused by spatiotemporal misalignment in existing technologies (e.g., using GPS data from different time periods to verify camera data). Based on this, dynamic weight allocation and threshold setting are combined. Weights are allocated according to the credibility of the data source (e.g., high-definition cameras have higher weight than private car GPS), and the verification threshold is dynamically adjusted through a non-privacy feature prediction model (e.g., main roads require more high-credibility data support). This allows the verification standard to adapt to the differences in data source density across different road segments (main roads / secondary roads) and different time periods (peak / off-peak). The accuracy of the verification results is improved by more than 35%, avoiding misjudgments under fixed thresholds in complex scenarios (e.g., excessively stringent verification on secondary roads due to low traffic volume).

[0049] 5. The multi-source cross-verification mechanism eliminates the risk of falsification from a single data source and strengthens the authority of rights confirmation. This invention's multi-source cross-verification mechanism employs dual verification of "feature consistency + weight compliance" between the main data source and multi-source data (e.g., a camera's "congestion" status requires speed feature support from at least five high-reliability GPS data sources, and the total weight must meet the standard). This mechanism fundamentally eliminates the risk of falsification or misjudgment caused by relying on a single data source (such as a single camera) in existing technologies. Simultaneously, during the verification process, the entire chain of information, including the data source identifiers, feature values, and weight calculations, is recorded in real-time on the blockchain, making the rights confirmation results traceable and auditable. This provides a credible foundation of "collective endorsement" for the cross-entity circulation of traffic data assets (e.g., car companies using traffic management data to optimize navigation), reduces trust costs in data transactions, and promotes the transformation of data assets from "static storage" to "dynamic circulation."

[0050] 6. Balancing privacy protection and data ownership verification needs, and expanding the application boundaries of data assets, this invention processes privacy data through "identity stripping + non-privacy feature extraction." While removing sensitive information such as vehicle VIN codes and user IDs, it retains non-privacy features such as "road congestion trends" for data ownership verification, resolving the contradiction in existing technologies where "privacy protection and data ownership verification are difficult to balance." For example, after anonymization, ride-hailing trajectory data can be used to define ownership through non-privacy features and can be securely used for traffic planning research. This transforms massive amounts of data that were previously idle due to privacy risks (such as private car travel trajectories) into assets that can be verified and circulated, increasing the effective utilization rate of data assets by more than 50%.

[0051] In summary, this invention, through the optimization of the entire process of "standardized integration - secure on-chain - efficiency adaptation - accurate verification - privacy balance", constructs a reliable rights confirmation system adapted to the characteristics of the transportation industry. It comprehensively surpasses existing technologies in terms of data integration efficiency, security and reliability, real-time adaptation, and verification reliability, providing core technical support for the compliant circulation, cross-entity collaboration, and value release of transportation data assets. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of a blockchain-based trusted ownership confirmation method for data assets, as described in an embodiment of this application.

[0053] Figure 2 This is a schematic diagram of a blockchain-based trusted ownership confirmation system for data assets, as described in an embodiment of this application. Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] like Figure 1 As shown, a blockchain-based method for trusted ownership verification of data assets includes the following steps:

[0056] Step s1: Construct an asset trust confirmation platform. The asset trust confirmation platform includes several blockchain nodes, which are interconnected to form a blockchain network. The blockchain nodes are connected to traffic data collection terminals (including traffic management department's cameras, radar and other road condition monitoring equipment, vehicle GPS, vehicle-mounted sensors, etc.) within a preset range. The traffic data collection terminals are used to collect multi-source heterogeneous data and mark the collection time, and set the collection cycle.

[0057] Step s2: Standardize and preprocess the multi-source heterogeneous data collected by each traffic data collection terminal to generate unified structured data, encrypt the unified structured data into blocks and put them on the blockchain, and optimize the on-chain operation of the real-time streaming data in the unified structured data during the encrypted block on-chain operation.

[0058] Step s3: Perform spatiotemporal correlation on the unified structured data uploaded to the blockchain node to generate several spatiotemporal verification units. Perform weight allocation, dynamic verification threshold setting and multi-source cross-verification on each spatiotemporal verification unit. Generate confirmation records or anomaly handling records based on the verification results.

[0059] It should be further explained that, in the specific implementation process, the standardization preprocessing of the multi-source heterogeneous data collected by various traffic data collection terminals includes:

[0060] A unified metadata standard framework is constructed, comprising: Data ID: A globally unique identifier, generated using a combination of "data source type + collection time + random sequence" (e.g., "VIDEO-GZ-202310010830-1234") to ensure the uniqueness of data from different sources. Source Entity: Records the responsible entity that generated the data, using hierarchical coding (e.g., "01-Traffic Management Bureau / 02-Ride-hailing Platform / 03-Private Car User") to clearly define the starting point for ownership tracing. Collection Time: A UTC timestamp accurate to milliseconds (e.g., "2023-10-01T08:30:15.123Z") to solve the problem of cross-time zone data synchronization. Core Feature Values: Key descriptive items extracted based on data type (e.g., "congestion level" for videos, "segment ID" for trajectories), supporting fast retrieval. Hash Value: A unique verification value after data preprocessing, generated using the SHA-256 algorithm, used for on-chain ownership confirmation and integrity verification. Multi-source heterogeneous data is categorized into data types, including real-time streaming data, static data, and privacy data. Real-time streaming data is processed using traffic data collection terminals for feature extraction and hash analysis to obtain core feature values ​​and hash values. For example, inter-frame difference analysis is performed on real-time video streams (25fps). Dynamic targets are identified using traffic data collection terminals (such as roadside cameras with built-in AI chips): Vehicle density: Based on the YOLOv5 object detection algorithm, the number of vehicles per unit pixel is counted and mapped to three congestion levels: "Smooth (<5 vehicles / 100 meters) / Slow (5-15 vehicles) / Congested (>15 vehicles)". Abnormal events: Trajectory tracking algorithms are used to identify vehicle behaviors such as sudden braking and driving in the wrong direction. Contour recognition is used to locate accident locations (accurate to the lane level, such as "RD001 section K3+200 meters eastbound lane"). A feature snapshot is generated every 30 seconds, and the core feature values ​​are extracted as "highest congestion level within the time period + abnormal event type and location + average vehicle speed".

[0061] Metadata for real-time streaming data is obtained based on a unified metadata standard framework, core feature values, and hash values. For example, data ID: VIDEO-GZ-RD001-202310010830-5678; Source entity: 01-Traffic Management Bureau of a certain city; Collection time: 2023-10-01T08:30:00.000Z; Data type: V01-Road condition monitoring video; Core feature values: Congestion level = Slow traffic; Accident location = None; Average vehicle speed = 35km / h; Hash value: SHA-256 (video file);

[0062] Construct a Merkle tree construction layer within a preset range, extract the core feature values ​​of the static data, obtain the Merkle root hash of the static data based on the core feature values ​​and the Merkle tree construction layer, and obtain the metadata of the static data based on the Merkle root hash, core feature values, and a unified metadata standard framework; for example: Data ID: TOPO-GZ-TIANHE-ARTERIAL-20230901; Source: 01-Transportation Planning Research Institute of a certain province; Collection time: 2023-09-01T00:00:00.000Z; Core feature value: Number of roads = 860; Coverage area = Main roads of Tianhe District; Hash value: Merkle root hash of the settlement layer;

[0063] The process of constructing a Merkle tree building layer within a predefined range includes:

[0064] Obtain road topology data within a preset range and split the data by administrative region and road level: Level 1 segmentation: divided by city / district (e.g., "Tianhe District, Guangzhou" and "Nanshan District, Shenzhen"). Level 2 segmentation: split by road type (e.g., "expressway", "arterial road", "secondary arterial road"). Each segment contains attributes such as road ID, start and end coordinates, number of lanes, and bridge / tunnel identifiers. The data size of a single segment is controlled within 10MB (containing approximately 500-1000 road records) to facilitate batch processing. Construct leaf nodes based on the individual road data within each level 2 segment. Use the output of the non-privacy feature prediction model for the corresponding leaf node as a supplementary node. Calculate the leaf node hash for the individual road data within each level 2 segment (e.g., the hash value for road 1 is h1, and the hash value for road 2 is h2). The data is aggregated layer by layer according to a binary tree structure: Bottom layer: h1 and h2 are aggregated into h12 = SHA-256(h1+h2); Middle layer: h3 and h4 are aggregated into h34 = SHA-256(h3+h4)...; Settlement layer: h12 and h34 are aggregated into h1234... until the Merkle root hash of the shard is generated, ultimately forming a three-level tree structure of "regional total root hash → shard root hash → leaf node hash". The leaf node position of the static data in the Merkle tree construction layer is determined based on the core feature values ​​of the static data, and the Merkle root hash of the settlement layer is obtained based on the leaf node position.

[0065] The process of performing identity stripping, non-privacy feature extraction, and hash analysis on privacy-preserving data includes:

[0066] Identity stripping: Remove direct identifiers such as vehicle VIN code and license plate number, and anonymize user ID using a hash algorithm (e.g., "user123 → hash value abc123") to sever the connection between the trajectory and the real identity.

[0067] Non-privacy feature extraction: Time features: the distribution of traffic hours for a certain road segment (e.g., "morning peak 7:00-9:00"); Traffic flow features: the number of anonymized vehicles passing through a certain road segment per unit time (e.g., "100 vehicles / hour"); Data source density features: the data source density for a certain road segment (e.g., an average of 100 GPS-equipped vehicles per kilometer on a certain road segment).

[0068] Obtain non-privacy features and hash values, and retrieve metadata for privacy data based on the unified metadata standard framework, non-privacy features, and hash values; for example: Data ID: TRAJ-USER-ANON-20231001-7890; Source Entity: 02-A ride-hailing platform (on behalf of users for rights confirmation); Collection Time: 2023-10-01T07:30:00.000Z; Non-privacy Features: Road Segments Involved = RD001-RD005; Travel Time = Morning Peak; Congestion Trend = Increasing; Hash Value: SHA-256 (privacy data after identity stripping);

[0069] A unified structured data is built based on metadata from real-time streaming data, static data, and privacy data.

[0070] It should be further explained that, in the specific implementation process, the process of encrypting and uploading unified structured data to the blockchain includes:

[0071] The public and private keys of the traffic data collection terminal are preset using an asymmetric encryption algorithm. The unified structured data of the traffic data collection terminal is encrypted using the private key to generate encrypted data. At the same time, a hash function is applied to the unified structured data to obtain a hash value. The hash value is then encrypted using the private key to generate signature data. The ciphertext data and signature data are packaged together to generate an encrypted data packet and uploaded to the blockchain node that communicates with the traffic data collection terminal.

[0072] The encrypted data packets uploaded to the blockchain node are decrypted using the public key to obtain the decrypted unified structured data and hash value. A hash function is applied to the decrypted unified structured data to obtain the settlement hash value. The settlement hash value is compared with the hash value. If the settlement hash value and the hash value are consistent, the block is added to the blockchain.

[0073] If the settlement hash value is inconsistent with the hash value, the encrypted data packet will be deleted and a data anomaly alert will be generated.

[0074] It should be further explained that, in the specific implementation process, the process of putting blocks on the blockchain includes:

[0075] The consensus mechanism and peer-to-peer communication protocol of the pre-set asset trust confirmation platform will package the unified structured data into new blocks and broadcast the new blocks to the entire blockchain network according to the peer-to-peer communication protocol. Other blockchain nodes in the blockchain network will verify the correctness of the block data according to the consensus mechanism.

[0076] The verification of the correctness of block data in new blocks according to the consensus mechanism includes:

[0077] Obtain the block information for the new block, which includes: version number, indicating the protocol version followed by the new block; parent block hash, reflecting the unique hash value of the previous block in the chain, ensuring the link between blocks; timestamp, marking the time when the block was generated, used to record the time-series data of the blockchain; difficulty target, a measure of the amount of work required to generate a valid block; and a random number, used to run the consensus algorithm. The version number, the hash value of the previous block, the timestamp, and the difficulty target are sequentially arranged and concatenated. The concatenated data is then hashed using the SHA-256 cryptographic hash function. The hash result is calculated and re-hashd to obtain the current difficulty target of the blockchain network. If a calculated hash value is less than the current difficulty target of the blockchain network (i.e., the hash value starts with a certain number of consecutive zeros), then the block data correctness verification for this new block is marked as passed.

[0078] After the block data of the new block passes the verification, the new block is added to the end of the blockchain, and the block information of the new block is updated in the local blockchain copies of all blockchain nodes.

[0079] It should be further explained that, in the specific implementation process, the process of optimizing the on-chain processing of real-time streaming data in the unified structured data during the on-chain operation of encrypted blocks includes:

[0080] When the traffic data collection terminal completes the block on-chain operation of unified structured data for the first time in the current collection cycle, it uses the hash value corresponding to the metadata of the real-time stream data in the unified structured data as the base hash, the core feature value as the base feature, and the collection time in the unified structured data as the base time. It presets a dynamic differential period, divides the time period after the base time in the current collection cycle into several identical dynamic differential periods, and executes the following steps.

[0081] Step 1: When unified structured data is generated for the first time in dynamic differential period t1, it is determined whether the core feature value in the unified structured data is consistent with the baseline feature. If they are consistent, the block on-chain operation is skipped, and unified structured data for dynamic differential period t1 is automatically generated within the blockchain node. This unified structured data is consistent with the unified structured data for the first block on-chain. If they are inconsistent, the difference hash is obtained based on the baseline hash, core feature value, and dynamic differential period. Unified structured data within dynamic differential period t1 is generated based on the unified metadata standard framework, difference hash, and core feature value. Specifically, metadata for real-time streaming data within the dynamic differential period is generated based on the unified metadata standard framework, difference hash, and core feature value. Unified structured data is constructed based on the metadata of real-time streaming data, static data, and privacy data. Block on-chain operation is performed on the unified structured data. For example:

[0082] Set a dynamic differential period (e.g., 1 second / time). After each collection, identify the changes in the dynamic state by comparing the core feature values ​​corresponding to the metadata of the real-time streaming data: if only congestion_level changes from "unobstructed" to "congested" and avg_speed decreases from 50 to 20, then the changes are these two fields. If there is no change in the dynamic state, skip this on-chain operation.

[0083] Calculate the difference hash separately for each extracted change item (including update timestamps). Among them, the preceding hash (i.e., the base hash) is incorporated into the calculation to form a "chained hash chain", that is:

[0084] ;

[0085] Where update_time represents the dynamic differential period, ensuring that the differential hash cannot be tampered with or forged, and only... Core feature values ​​and dynamic difference periodic on-chain.

[0086] Step 2: When generating unified structured data in the next dynamic differential cycle t2, determine whether the core feature value in the unified structured data is consistent with the difference hash of the previous dynamic differential cycle t1. If they are consistent, skip the block on-chain operation and automatically generate unified structured data for dynamic differential cycle t2 within the blockchain node. If the unified structured data is consistent with the unified structured data of the previous dynamic differential cycle t1, skip the block on-chain operation and keep the unified structured data of the dynamic differential cycle consistent with the previous dynamic differential cycle. If they are inconsistent, obtain the difference hash based on the base hash, core feature value, and dynamic differential cycle, generate unified structured data within dynamic differential cycle t2 based on the unified metadata standard framework, difference hash, and core feature value, and perform the block on-chain operation on the unified structured data.

[0087] Repeat step two until the current collection cycle ends.

[0088] Each subsequent change repeats step two to form the "base hash". →Difference hashing →Difference hashing →...→ The chain structure requires that the calculation of differential hashes include the preceding differential hashes; only the differential hashes of each version and metadata are stored on the chain, while the complete data is still stored off-chain in distributed storage (such as IPFS), and can be retrieved by indexing through differential hashes.

[0089] When it is necessary to verify the data integrity of the traffic data collection terminal at a specific moment, the following steps can be taken:

[0090] Obtain the base hash of the traffic data collection terminal from the blockchain. All difference hashes before the target time point (e.g.) to ), retrieve complete data of the baseline version and the original differences of each change from off-chain storage, based on the baseline data and For the corresponding changes, generate the first updated version data and verify whether its hash matches. + The chained computation results are consistent, and the verification is iterated sequentially until... Finally, complete data for the target time point is generated, and its integrity is confirmed to have not been tampered with.

[0091] It should be further explained that, in the specific implementation process, the process of performing spatiotemporal correlation on the unified structured data uploaded to the blockchain node includes:

[0092] Mark the end timestamp of the collection period as the rights confirmation detection point, and extract the unified structured data uploaded to the blockchain node by each traffic collection terminal during the collection period at the rights confirmation detection point.

[0093] Extract the metadata corresponding to the static data in the unified structured data of each traffic collection terminal, and use the Merkle root hash to perform spatial clustering of the unified structured data of each traffic collection terminal. Unified structured data with the same Merkle root hash are clustered into the same spatial clustering unit to generate several spatial clustering units.

[0094] The acquisition period is divided into several dynamic differential periods based on the dynamic differential period. The acquisition timestamp of the unified structured data in each spatial clustering unit is extracted. The dynamic differential period to which the unified structured data in each spatial clustering unit belongs is obtained based on the acquisition timestamp. The unified structured data in each spatial clustering unit is then clustered in time based on the dynamic differential period. The unified structured data with the same dynamic differential period in the spatial clustering unit are clustered into the same spatiotemporal verification unit, generating several spatiotemporal verification units.

[0095] It should be further explained that, in the specific implementation process, the process of weight allocation and dynamic verification threshold setting includes:

[0096] Preset weight coefficients for each traffic data collection terminal. For example, the weight coefficient for primary data source (high credibility): fixed high-definition cameras (regularly calibrated) and official radar equipment is set to 1.0; the weight coefficient for secondary data source (medium credibility): GPS of operating vehicles (such as taxis and ride-hailing vehicles, with regular equipment maintenance) is set to 0.8; and the weight coefficient for tertiary data source (low credibility): GPS of private cars (with varying equipment accuracy) is set to 0.5. Set the weight coefficients for each unified structured data according to the traffic data collection terminal to which each unified structured data belongs within each spatiotemporal verification unit.

[0097] Construct a non-privacy feature prediction model, update the non-privacy features of each leaf node in the Merkle tree construction layer in real time based on the non-privacy feature prediction model, obtain the leaf node position of each spatiotemporal verification unit in the Merkle tree construction layer based on the Merkle root hash corresponding to the metadata of the static data in each spatiotemporal verification unit, and obtain the non-privacy features of each spatiotemporal verification unit based on the leaf node position of each spatiotemporal verification unit in the Merkle tree construction layer.

[0098] A preset threshold lookup table is used, which includes quantity thresholds and weight thresholds corresponding to different non-privacy features. For example, for main roads (average daily traffic flow of 100,000 vehicles): at least 5 secondary GPS data points (or 3 secondary + 2 tertiary) are required to match the camera data, and the total weight sum is ≥4.0 (5 × 0.8 = 4.0). For secondary roads (average daily traffic flow of 50,000 vehicles): at least 3 secondary GPS data points are required, with a total weight ≥2.4. Based on the non-privacy features and threshold lookup table, the real-time quantity threshold, non-privacy quantity threshold, and the weight thresholds corresponding to the real-time quantity threshold and non-privacy quantity threshold are obtained for each spatiotemporal verification unit.

[0099] It should be further explained that, in the specific implementation process, the process of constructing the non-privacy feature prediction model includes:

[0100] Regularly obtain unified structured data from various traffic data collection terminals within the historical collection period from various blockchain nodes, extract non-privacy features corresponding to the metadata of privacy data in the unified structured data as training and test sets, input the training set into the non-privacy feature prediction model for training until the loss function is stable, save the model parameters, test the non-privacy feature prediction model through the test set until it meets the preset requirements, and output the non-privacy feature prediction model.

[0101] It should be further explained that, in the specific implementation process, the multi-source cross-validation process includes:

[0102] The unified structured data with the largest weight coefficient is selected from the spatiotemporal verification unit, and the unified structured data is marked as the main data source. The core feature values ​​corresponding to the metadata of the real-time streaming data in each unified structured data in the spatiotemporal verification unit, as well as the non-privacy features corresponding to the metadata of the privacy data, are extracted.

[0103] The system calculates the number of core features that match the core features of the main data source and their first total weight (the sum of the weight coefficients of each unified structured data point that matches the core features of the main data source), and the number of non-privacy features that match the non-privacy features of the main data source and their second total weight (the sum of the weight coefficients of each unified structured data point that matches the non-privacy features of the main data source). For example, if there are 6 unified structured data points that match the non-privacy features of the main data source, and the weight coefficient of each unified structured data point that matches the non-privacy features of the main data source is 0.8, then the total weight = 6 × 0.8 = 4.8.

[0104] If the number of core feature values ​​exceeds the real-time threshold and the first total weight exceeds the weight threshold corresponding to the real-time threshold, and the number of non-privacy features exceeds the non-privacy threshold and the second total weight exceeds the weight threshold corresponding to the non-privacy threshold, then an authorization record for the spatiotemporal verification unit is automatically generated (including all unified structured data participating in the verification, the consistency calculation process (consistent data volume, total weight, and threshold compliance status)). This authorization record is then stored on the blockchain for evidence. For example, if a camera detects "congestion," an authorization record is only generated after consensus is reached with GPS data from at least five vehicles to prevent fraud from a single data source. Otherwise, an anomaly handling record for the spatiotemporal verification unit is generated, and anomaly handling is performed on the unit. This includes manual review (such as viewing the original camera video and verifying the historical error rate of the GPS device) to confirm the cause of the anomaly and retrieving data from adjacent data sources (such as upstream / downstream cameras and ETC gantry data) for supplementary verification. For example, if adjacent cameras also show "congestion," it may be due to a malfunction in some GPS devices.

[0105] By using multi-source mutual verification, a single data source (such as a tampered camera) cannot pass verification, thus eliminating the possibility of "isolated evidence" for rights confirmation from a mechanism perspective.

[0106] like Figure 2 As shown, a blockchain-based trusted data asset ownership confirmation system is also proposed, which is applied to the above-mentioned blockchain-based trusted data asset ownership confirmation method. The system includes a trusted asset ownership confirmation platform, which is communicatively connected to a data processing module and an ownership confirmation module.

[0107] The asset trust confirmation platform includes several blockchain nodes, which are interconnected to form a blockchain network. The blockchain nodes are connected to traffic data collection terminals within a preset range. The traffic data collection terminals are used to collect multi-source heterogeneous data, mark the collection time, and set the collection cycle.

[0108] The data processing module is used to standardize and preprocess the multi-source heterogeneous data collected by various traffic collection terminals to generate unified structured data, encrypt the unified structured data into blocks and put them on the blockchain, and optimize the on-chain uploading of real-time streaming data in the unified structured data during the encrypted block on-chain operation.

[0109] The rights confirmation module is used to perform spatiotemporal correlation on the unified structured data uploaded to the blockchain node, generate several spatiotemporal verification units, assign weights to each spatiotemporal verification unit, set dynamic verification thresholds and perform multi-source cross-verification, and generate rights confirmation records or anomaly handling records based on the verification results.

[0110] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A blockchain-based method for trusted ownership confirmation of data assets, characterized in that, Includes the following steps: Step s1: Construct an asset trust confirmation platform. The asset trust confirmation platform includes several blockchain nodes, which are interconnected to form a blockchain network. The blockchain nodes are connected to traffic data collection terminals within a preset range. The traffic data collection terminals are used to collect multi-source heterogeneous data and mark the collection time, and set the collection cycle. Step s2: Standardize and preprocess the multi-source heterogeneous data collected by each traffic data collection terminal to generate unified structured data, encrypt the unified structured data into blocks and put them on the blockchain, and optimize the on-chain operation of the real-time streaming data in the unified structured data during the encrypted block on-chain operation. Step s3: Perform spatiotemporal correlation on the unified structured data uploaded to the blockchain node to generate several spatiotemporal verification units. Perform weight allocation, dynamic verification threshold setting and multi-source cross-verification on each spatiotemporal verification unit. Generate confirmation records or anomaly handling records based on the verification results. The process of optimizing the on-chain processing of real-time streaming data in the unified structured data during the on-chain operation of encrypted blocks includes: When the traffic data collection terminal completes the block on-chain operation of unified structured data for the first time in the current collection cycle, it uses the hash value corresponding to the metadata of the real-time stream data in the unified structured data as the base hash, the core feature value as the base feature, and the collection time in the unified structured data as the base time. It presets a dynamic differential period, divides the time period after the base time in the current collection cycle into several identical dynamic differential periods, and executes the following steps. Step 1: When the unified structured data is generated for the first time in the dynamic differential period t1, it is determined whether the core feature value in the unified structured data is consistent with the benchmark feature. If they are consistent, the block on-chain operation is skipped, and the unified structured data of the dynamic differential period t1 is automatically generated in the blockchain node. The unified structured data is consistent with the unified structured data of the first block on-chain. If they are inconsistent, the difference hash is obtained according to the benchmark hash, core feature value and dynamic differential period, and the unified structured data in the dynamic differential period t1 is generated. The unified structured data is then encrypted and the block on-chain operation is performed. Step 2: When generating unified structured data in the next dynamic differential cycle t2, determine whether the core feature value in the unified structured data is consistent with the difference hash of the previous dynamic differential cycle t1. If they are consistent, skip the block on-chain operation and automatically generate unified structured data for dynamic differential cycle t2 within the blockchain node. The unified structured data is consistent with the unified structured data of the previous dynamic differential cycle t1. If they are inconsistent, obtain the difference hash based on the base hash, core feature value, and dynamic differential cycle, generate unified structured data within dynamic differential cycle t2, and perform the block on-chain operation on the unified structured data. Repeat step two until the current collection cycle ends.

2. The blockchain-based trusted ownership confirmation method for data assets according to claim 1, characterized in that, The process of standardizing and preprocessing multi-source heterogeneous data collected from various traffic data collection terminals includes: A unified metadata standard framework is constructed to classify multi-source heterogeneous data into data types, dividing multi-source heterogeneous data into real-time streaming data, static data, and privacy data. Feature extraction and hash analysis are performed on real-time streaming data to obtain core feature values ​​and hash values. Metadata of real-time streaming data is obtained based on the unified metadata standard framework, core feature values, and hash values. Construct a Merkle tree building layer within a preset range, extract the core feature values ​​of the static data, obtain the Merkle root hash of the static data based on the core feature values ​​and the Merkle tree building layer, and obtain the metadata of the static data based on the Merkle root hash, the core feature values, and the unified metadata standard framework. Identity stripping, non-privacy feature extraction, and hash analysis are performed on privacy data to obtain non-privacy features and hash values. Metadata of privacy data is obtained based on a unified metadata standard framework, non-privacy features, and hash values. A unified structured data is built based on metadata from real-time streaming data, static data, and privacy data.

3. The blockchain-based trusted ownership confirmation method for data assets according to claim 2, characterized in that, The process of uploading encrypted blocks of unified structured data to the blockchain includes: The public and private keys of the traffic data collection terminal are preset. The unified structured data is encrypted using the private key to generate encrypted data. At the same time, a hash function is applied to the unified structured data to obtain a hash value. The hash value is then encrypted using the private key to generate signature data. The ciphertext data and signature data are packaged together to generate an encrypted data packet and uploaded to the blockchain node. The encrypted data packets uploaded to the blockchain node are decrypted using the public key to obtain the decrypted unified structured data and hash value. A hash function is applied to the decrypted unified structured data to obtain the settlement hash value. The settlement hash value is compared with the hash value. If the settlement hash value and the hash value are consistent, the block is added to the blockchain. If the settlement hash value is inconsistent with the hash value, the encrypted data packet will be deleted and a data anomaly alert will be generated.

4. The blockchain-based trusted ownership confirmation method for data assets according to claim 3, characterized in that, The specific process of performing block on-chain operations includes: The consensus mechanism and peer-to-peer communication protocol of the pre-set asset trust confirmation platform will package the unified structured data into new blocks and broadcast the new blocks to the entire blockchain network according to the peer-to-peer communication protocol. Other blockchain nodes in the blockchain network will verify the correctness of the block data according to the consensus mechanism. After the block data of the new block passes the verification, the new block is added to the end of the blockchain, and the block information of the new block is updated in the local blockchain copies of all blockchain nodes.

5. The blockchain-based trusted ownership confirmation method for data assets according to claim 1, characterized in that, The process of performing spatiotemporal correlation on the unified structured data uploaded to the blockchain nodes includes: Mark the end timestamp of the collection period as the rights confirmation detection point, and extract the unified structured data uploaded to the blockchain node by each traffic collection terminal during the collection period at the rights confirmation detection point. Extract the metadata corresponding to the static data in the unified structured data of each traffic data collection terminal, and use the Merkle root hash to perform spatial clustering on the unified structured data of each traffic data collection terminal to generate several spatial clustering units. The acquisition period is divided into several dynamic difference periods based on the dynamic difference period. The dynamic difference period to which the unified structured data in each spatial clustering unit belongs is obtained. Based on the dynamic difference period, the unified structured data in each spatial clustering unit is clustered over time to generate several spatiotemporal verification units.

6. The blockchain-based trusted ownership confirmation method for data assets according to claim 5, characterized in that, The process of weight allocation and dynamic verification threshold setting includes: Preset the weight coefficients of each traffic data collection terminal, and set the weight coefficients of each unified structured data according to the traffic data collection terminal to which each unified structured data belongs in each spatiotemporal verification unit. Construct a non-privacy feature prediction model, update the non-privacy features of each leaf node in the Merkle tree construction layer in real time based on the non-privacy feature prediction model, obtain the leaf node position of each spatiotemporal verification unit in the Merkle tree construction layer, and obtain the non-privacy features of each spatiotemporal verification unit based on the leaf node position. The real-time number threshold, non-privacy number threshold, and weight threshold corresponding to the real-time number threshold and non-privacy number threshold are obtained for each spatiotemporal verification unit based on non-privacy features.

7. The blockchain-based trusted ownership confirmation method for data assets according to claim 6, characterized in that, The process of building a non-privacy feature prediction model includes: Regularly obtain unified structured data from various traffic data collection terminals within the historical collection period from various blockchain nodes, extract non-privacy features corresponding to the metadata of privacy data in the unified structured data as training and test sets, input the training set into the non-privacy feature prediction model for training until the loss function is stable, save the model parameters, test the non-privacy feature prediction model through the test set until it meets the preset requirements, and output the non-privacy feature prediction model.

8. A blockchain-based method for trusted ownership confirmation of data assets according to claim 7, characterized in that, The process of performing multi-source cross-validation includes: The unified structured data with the largest weight coefficient is selected from the spatiotemporal verification unit, and the unified structured data is marked as the main data source. The core feature values ​​corresponding to the metadata of the real-time streaming data and the non-privacy features corresponding to the metadata of the privacy data are extracted from each unified structured data in the spatiotemporal verification unit. The number of core features that are consistent with the core feature values ​​of the main data source and their first total weight, and the number of non-privacy features that are consistent with the non-privacy features of the main data source and their second total weight; If the number of core feature values ​​is greater than the real-time number threshold and the first total weight is greater than the weight threshold corresponding to the real-time number threshold, and the number of non-privacy features is greater than the non-privacy number threshold and the second total weight is greater than the weight threshold corresponding to the non-privacy number threshold, then the weighting record of the spatiotemporal verification unit is automatically generated; otherwise, the abnormal processing record of the spatiotemporal verification unit is generated.

9. A blockchain-based trusted data asset ownership confirmation system, applied to the blockchain-based trusted data asset ownership confirmation method described in any one of claims 1 to 8, characterized in that, This includes an asset trust confirmation platform, which has a communication connection between a data processing module and a rights confirmation module; The asset trust confirmation platform includes several blockchain nodes, which are interconnected to form a blockchain network. The blockchain nodes are connected to several traffic data collection terminals within a preset range. The traffic data collection terminals are used to collect multi-source heterogeneous data, mark the collection time, and set the collection cycle. The data processing module is used to standardize and preprocess the multi-source heterogeneous data collected by various traffic collection terminals to generate unified structured data, encrypt the unified structured data into blocks and put them on the blockchain, and optimize the on-chain uploading of real-time streaming data in the unified structured data during the encrypted block on-chain operation. The rights confirmation module is used to perform spatiotemporal correlation on the unified structured data uploaded to the blockchain node, generate several spatiotemporal verification units, assign weights to each spatiotemporal verification unit, set dynamic verification thresholds and perform multi-source cross-verification, and generate rights confirmation records or anomaly handling records based on the verification results.

Images