A blockchain-based method and system for protecting tourism data privacy

Abstract

This invention relates to the field of blockchain technology, specifically to a blockchain-based method and system for protecting the privacy of tourism data. The method includes: constructing a distributed caching layer deployed between blockchain nodes and user terminals to dynamically capture newly added tourism data from users, and aggregating this data into data block groups based on preset time windows or data volume thresholds. This invention avoids performing a complete privacy protection process on each piece of new data separately by constructing a distributed caching layer between blockchain nodes and user terminals, thus reducing redundant computation and verification operations. The data block groups are encrypted using a dual-layer approach: lightweight symmetric encryption ensures basic data efficiency, while asymmetric encryption strengthens group-level metadata security. Furthermore, it initiates sharded parallel verification and utilizes message queues to achieve lock-free operation, shortening verification time.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a blockchain-based method and system for protecting the privacy of tourism data. Background Technology

[0002] Blockchain technology, with its decentralized, immutable, and traceable characteristics, has been increasingly applied to data management in the tourism industry. Tourism data encompasses a wide range of sensitive information, including user identity information, travel itineraries, consumption records, and accommodation preferences. This data not only relates to user privacy and security but may also affect the accurate provision of tourism services and the industry's compliant operation. Currently, the industry frequently attempts to use blockchain technology for the storage and protection of tourism data, hoping to leverage its technical characteristics to prevent unauthorized data tampering or leakage, and to provide a new solution for the secure management of tourism data.

[0003] Existing blockchain-based tourism data privacy protection technologies suffer from an imbalance between processing efficiency and resource consumption when dealing with dynamically added tourism data. Tourism data is not static; users continuously generate new data during their travels, such as temporarily added attraction reservations and real-time updated transportation ticketing information. Current technologies often require a separate, complete privacy protection process for each new data entry, including re-encryption, node verification, and on-chain storage. This process not only increases data processing latency, preventing users from accessing or using their latest travel data promptly, but also excessively consumes the blockchain network's computing and storage resources due to repetitive computation and verification. This resource imbalance becomes more pronounced during peak travel periods when data volume is high, ultimately affecting the stable operation of the entire blockchain-based tourism data system. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a blockchain-based method and system for protecting tourism data privacy, which solves the problem of efficiency and resource consumption imbalance when processing dynamically added tourism data in existing technologies.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based tourism data privacy protection method, comprising:

[0006] A distributed caching layer is constructed and deployed between blockchain nodes and user terminals. It is used to dynamically capture new travel data from users and aggregate the new travel data into data block groups in a preset time window or data volume threshold.

[0007] The data block group is subjected to two-layer encryption, which includes applying lightweight symmetric encryption to the basic data in the data block group and applying asymmetric encryption to the group-level metadata in the data block group.

[0008] The double-encrypted data block group is submitted to the blockchain network, and sharded parallel verification is initiated. Sharded parallel verification includes:

[0009] The verification nodes in the blockchain network are divided into a metadata verification group, a content consistency group, and an authorization audit group.

[0010] The metadata verification group verifies the origin and digital signature of the data block group;

[0011] The hash values ​​of data within a data block group are compared in parallel by the content consistency group;

[0012] The access control group synchronously checks users' access permissions to data.

[0013] Implement lock-free parallel operations between the metadata verification group, content consistency group, and permission audit group through message queues;

[0014] The aggregate fingerprint of the data block group is stored on the core blockchain. The aggregate fingerprint contains a summary of the data characteristics of the data block group, a user permission token, and a pointer to the distributed cache layer.

[0015] The original data after double encryption is split into data fragments and stored in a lightweight sidechain;

[0016] Data processing employs a two-phase consensus mechanism, which includes:

[0017] In the first phase, the distributed caching layer quickly responds to requests for new tourism data and returns temporary receiving credentials;

[0018] In the second phase, the final verification and storage of data block groups are completed asynchronously in the blockchain backend; and based on real-time data traffic, the dynamic resource scheduler automatically adjusts the computation frequency of the double-layer encryption and the number of shards in the lightweight sidechain.

[0019] Furthermore, the construction of the distributed caching layer includes:

[0020] A distributed caching layer is established between blockchain nodes and user terminals. The distributed caching layer is used as a real-time incremental buffer for newly added tourism data.

[0021] The real-time incremental buffer dynamically receives new tourism data from user terminals in real time;

[0022] When the amount of data in the real-time incremental buffer reaches the preset storage threshold, or when the real-time incremental buffer passes through the preset time window, the newly added tourism data in the real-time incremental buffer will be aggregated into a data block group.

[0023] Furthermore, the double-layer encryption process for the data block group includes:

[0024] The basic data in the data block group is symmetrically encrypted using the first preset key;

[0025] The group-level metadata in the data block group is asymmetrically encrypted using a second preset key. The group-level metadata includes user identity information and key operation records.

[0026] A one-time aggregation encryption operation is triggered only after the data block group has been aggregated, in order to encrypt the entire data block group.

[0027] Furthermore, the verification of the source and digital signature of the data block group by the metadata verification group includes:

[0028] The metadata verification group receives the data block group and extracts the metadata verification information contained in the data block group;

[0029] Verify the data source in the metadata verification information to ensure the legitimacy of the data block group;

[0030] Verify the digital signature in the metadata verification information to ensure the integrity and non-repudiation of the data block group.

[0031] Furthermore, the hash values ​​of the data within the data block group that are compared in parallel by the content consistency group include:

[0032] The content consistency group receives the data block group and independently calculates the hash value of each data fragment within the data block group;

[0033] The independently computed hash values ​​are compared in parallel with the pre-stored hash digests in the data block group;

[0034] Based on the comparison results, the consistency of data content within the data block group was confirmed.

[0035] Furthermore, the synchronous check of user access permissions to data by the permissions audit group includes:

[0036] The access control audit group obtains the user identity information and access request type associated with the data block group;

[0037] Retrieve the user's corresponding permission rules from the preset permission management policy;

[0038] Simultaneously verify whether the user's identity has the permission to access or operate on the data block group.

[0039] Furthermore, the step of storing the aggregated fingerprint of data block groups on the core blockchain and splitting the double-encrypted original data into data fragments and storing them on a lightweight sidechain includes:

[0040] The aggregate fingerprint of the data block group is uploaded to the core blockchain, and the aggregate fingerprint serves as the unique identifier of the data block group.

[0041] The original data after double encryption is fragmented, and the fragmented data segments are stored off-chain in a lightweight sidechain.

[0042] When it is necessary to query the original data, the corresponding data fragment on the lightweight sidechain is located by the aggregate fingerprint on the core blockchain, and the data is reconstructed.

[0043] Furthermore, the step of locating the corresponding data fragment on the lightweight sidechain through the aggregated fingerprint on the core blockchain and reconstructing the data when it is necessary to query the original data includes:

[0044] Receive data query requests from users;

[0045] Retrieve aggregate fingerprints that match the query request within the core blockchain;

[0046] Based on the pointer information of the distributed cache layer and the data feature digest contained in the aggregate fingerprint, the corresponding encrypted data fragment is retrieved from the lightweight sidechain;

[0047] The retrieved encrypted data fragments are decrypted and reassembled to restore the original data.

[0048] Furthermore, the step of automatically adjusting the computation frequency of the double-layer encryption and the number of shards in the lightweight sidechain based on real-time data traffic via a dynamic resource scheduler includes:

[0049] The dynamic resource scheduler monitors data traffic in the blockchain network in real time;

[0050] When data traffic is at off-peak times, the dynamic resource scheduler reduces the frequency of double encryption operations and decreases the number of shards in the lightweight sidechain.

[0051] When data traffic is at its peak, the dynamic resource scheduler increases the frequency of double-encrypted operations and the number of shards in the lightweight sidechain, while also enabling backup validator node groups to assist in processing.

[0052] This invention also provides a blockchain tourism data privacy protection system, implementing the blockchain tourism data privacy protection method described in any of the above claims, comprising:

[0053] The data aggregation module is used to build a distributed caching layer. The distributed caching layer is deployed between the blockchain node and the user terminal to dynamically capture new travel data from users and aggregate the new travel data into data block groups in a preset time window or data volume threshold.

[0054] The encryption processing module is used to perform two-layer encryption processing on the data block group. The two-layer encryption processing includes: applying lightweight symmetric encryption to the basic data in the data block group, and applying asymmetric encryption to the group-level metadata in the data block group.

[0055] The parallel verification module is used to submit the double-encrypted data block group to the blockchain network and initiate sharded parallel verification. The parallel verification module includes:

[0056] The node sharding unit is used to divide the verification nodes in the blockchain network into a metadata verification group, a content consistency group, and a permission audit group.

[0057] The collaborative verification unit is used by the metadata verification group to verify the source and digital signature of the data block group, by the content consistency group to compare the hash values ​​of the data within the data block group in parallel, and by the permission audit group to synchronously check the user's access rights to the data.

[0058] The message queue unit is used to enable lock-free parallel operations between the metadata verification group, the content consistency group, and the permission audit group.

[0059] The cross-chain storage module is used to store the aggregate fingerprint of data block groups on the core blockchain. The aggregate fingerprint contains the data feature digest of the data block group, the user permission mark, and the pointer to the distributed cache layer. It is also used to split the double-encrypted original data into data fragments and store them on a lightweight sidechain.

[0060] The consensus optimization module is used to process data using a two-stage consensus mechanism, which includes: a first stage in which a distributed caching layer quickly responds to new tourism data requests and returns temporary receipt credentials; and a second stage in which the final verification and storage of data block groups are completed asynchronously in the blockchain backend.

[0061] The resource scheduling module is used to automatically adjust the computation frequency of the double-encrypted system and the number of shards in the lightweight sidechain based on real-time data traffic through a dynamic resource scheduler.

[0062] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0063] This invention constructs a distributed caching layer between blockchain nodes and user terminals, aggregating newly added user travel data into data block groups according to preset time windows or data volume thresholds. This avoids performing a complete privacy protection process for each new data entry, reducing redundant computations and verification operations. The data block groups employ dual-layer encryption: lightweight symmetric encryption ensures basic data efficiency, while asymmetric encryption strengthens group-level metadata security. It initiates sharded parallel verification and uses message queues to achieve lock-free operation, shortening verification time. A two-phase consensus mechanism allows the distributed caching layer to quickly respond to user requests and return temporary credentials, while the background asynchronously completes final verification and storage. A dynamic resource scheduler adjusts the encryption operation frequency and the number of sidechain shards based on real-time traffic, increasing processing capacity during peak periods and reducing resource waste during off-peak periods. This solves the problems of low efficiency and unbalanced resource consumption in existing technologies for processing dynamic travel data, alleviates resource pressure during peak travel periods, and ensures the stable operation of the blockchain travel data system. Attached Figure Description

[0064] Figure 1 This is a flowchart of the method of the present invention;

[0065] Figure 2 This is a system structure diagram of the present invention. Detailed Implementation

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

[0067] Please see Figure 1 This invention provides a blockchain-based method for protecting the privacy of tourism data, comprising:

[0068] A distributed caching layer is constructed and deployed between blockchain nodes and user terminals. It is used to dynamically capture new travel data from users and aggregate the new travel data into data block groups in units of preset time windows or data volume thresholds.

[0069] The data block group is subjected to two-layer encryption, which includes applying lightweight symmetric encryption to the basic data in the data block group and applying asymmetric encryption to the group-level metadata in the data block group.

[0070] The double-encrypted data block group is submitted to the blockchain network, and sharded parallel verification is initiated. Sharded parallel verification includes:

[0071] The verification nodes in the blockchain network are divided into a metadata verification group, a content consistency group, and an authorization audit group.

[0072] The metadata verification group verifies the origin and digital signature of the data block group;

[0073] The hash values ​​of data within a data block group are compared in parallel by the content consistency group;

[0074] The access control group synchronously checks users' access permissions to data.

[0075] Implement lock-free parallel operations between the metadata verification group, content consistency group, and permission audit group through message queues;

[0076] The aggregate fingerprint of the data block group is stored on the core blockchain. The aggregate fingerprint contains a summary of the data characteristics of the data block group, a user permission token, and a pointer to the distributed cache layer.

[0077] The original data after double encryption is split into data fragments and stored in a lightweight sidechain;

[0078] Data processing employs a two-phase consensus mechanism, which includes:

[0079] In the first phase, the distributed caching layer quickly responds to requests for new tourism data and returns temporary receiving credentials;

[0080] In the second phase, the final verification and storage of data block groups are completed asynchronously in the blockchain backend; and based on real-time data traffic, the dynamic resource scheduler automatically adjusts the computation frequency of the double-layer encryption and the number of shards in the lightweight sidechain.

[0081] Specifically, in the blockchain-based tourism data privacy protection scenario, a distributed caching layer is first deployed between blockchain nodes and user terminals. This caching layer can capture new data generated by users during their travels in real time, such as temporary attraction reservation records and real-time transportation ticketing information. To clarify the data aggregation triggering conditions, relevant parameters are set: Let the cumulative amount of newly added tourism data in the distributed caching layer be... The preset storage threshold is The cumulative time for the cache layer to receive data is The preset time window is When the conditions of formula (1) are met, the cache layer automatically aggregates the scattered new data into a data block group, avoiding the need to perform a complete processing flow for each new data separately, and reducing the resource consumption caused by repeated operations.

[0082]

[0083] in, The unit is bytes. Units and Consistent, preset according to system storage capacity; The unit is seconds. Units and Consistent, based on the preset frequency of new additions according to tourism data; "" indicates a logical "OR" operation, which triggers aggregation when either condition is met.

[0084] The aggregated data blocks are subjected to two layers of encryption. For basic data in the blocks, such as trip route details and consumption amount, a lightweight symmetric encryption method is used to improve encryption efficiency while ensuring basic privacy. For group-level metadata in the blocks, such as user identity characteristics and data upload operation records, an asymmetric encryption method is used to strengthen the security protection of sensitive information.

[0085] After encryption, the data block group is submitted to the blockchain network and sharded parallel verification is initiated. The verification nodes in the network are first divided into a metadata verification group, a content consistency group, and an access control audit group. The metadata verification group is responsible for verifying the legitimacy of the data block group's origin and the completeness of the digital signature. The content consistency group calculates the hash value of each data fragment within the block group in parallel and compares it with a pre-stored hash digest (hash value calculation uses existing technology, which will not be elaborated here). The access control audit group synchronously checks the user's access permissions to the data block group. Simultaneously, a message queue enables lock-free parallel operation of the three groups of nodes, significantly reducing verification time.

[0086] In the storage phase, the aggregate fingerprint of the data block group is stored in the core blockchain. The aggregate fingerprint includes a data feature digest, user permission marker, and distributed cache layer pointer. The original data after double encryption is then split into data fragments and stored in a lightweight sidechain to reduce the storage pressure on the core blockchain.

[0087] A two-phase consensus mechanism is used to process data. When a user initiates a request for new travel data, the distributed caching layer responds immediately and returns a temporary receipt, allowing the user to quickly obtain feedback. Subsequently, the final verification and storage of the data block group are completed asynchronously in the blockchain backend, avoiding user waiting. Simultaneously, the dynamic resource scheduler monitors network data traffic in real time. To achieve dynamic resource adjustment, parameters are set: Let the real-time data traffic be... The system's preset baseline flow rate is The flow coefficient is The basic operation frequency of double-layer encryption is The real-time computing frequency is The number of lightweight sidechain base shards is The number of real-time shards is First, the flow coefficient is calculated using formula (2). (Normalize the traffic to ensure consistent dimensions), and then adjust the encryption operation frequency and the number of sidechain fragments using formulas (3) and (4) respectively.

[0088] Formula (2):

[0089] Formula (3):

[0090] Formula (4):

[0091] in, and The units are all bytes per second; It is a dimensionless coefficient that reflects the ratio of real-time flow to baseline flow. and The units are all times per second; and All are positive integers. When data volume surges during peak tourist seasons, , ,at this time and The corresponding increase; when the traffic is during off-peak periods, , , and This reduces resource consumption accordingly, enabling a more rational allocation of resources and addressing the issues of low efficiency in processing dynamic data and unbalanced resource consumption in existing technologies, thus ensuring stable system operation.

[0092] In this embodiment, constructing the distributed cache layer includes:

[0093] A distributed caching layer is established between blockchain nodes and user terminals. The distributed caching layer is used as a real-time incremental buffer for newly added tourism data.

[0094] The real-time incremental buffer dynamically receives new tourism data from user terminals in real time;

[0095] When the amount of data in the real-time incremental buffer reaches the preset storage threshold, or when the real-time incremental buffer passes through the preset time window, the newly added tourism data in the real-time incremental buffer will be aggregated into a data block group.

[0096] Specifically, a distributed caching layer is established between blockchain nodes and user terminals. This caching layer serves as a real-time incremental buffer for newly added tourism data, continuously receiving real-time new data sent by user terminals, including but not limited to hotel check-in updates and attraction visit records. The data aggregation trigger condition follows the judgment logic of formula (1), where the amount of data stored in the real-time incremental buffer... Reaching the preset storage threshold Or the data storage time in the buffer. After the preset time window At this time, the buffer automatically integrates and aggregates all newly added travel data into a single data block. This aggregation process avoids the need for separate encryption and verification operations for each new data entry, reducing the frequency of data processing, lowering the system's computational burden, and shortening the overall processing time caused by processing large amounts of fragmented data, thereby improving data processing efficiency.

[0097] In this embodiment, the double-layer encryption process for the data block group includes:

[0098] The basic data in the data block group is symmetrically encrypted using the first preset key;

[0099] The group-level metadata in the data block group is asymmetrically encrypted using a second preset key. The group-level metadata includes user identity information and key operation records.

[0100] A one-time aggregation encryption operation is triggered only after the data block group has been aggregated, in order to encrypt the entire data block group.

[0101] Specifically, when performing two-layer encryption on the aggregated data block group, the first preset key is used to perform symmetric encryption on the basic data in the data block group. This basic data includes non-sensitive information from the travel itinerary, such as attraction opening hours and transportation schedules. This lightweight symmetric encryption method allows for rapid encryption, ensuring processing efficiency. Then, the second preset key is used to perform asymmetric encryption on the group-level metadata in the data block group. This group-level metadata contains user identity information and key operation records. This type of information is highly sensitive, and asymmetric encryption provides a higher level of security, preventing information leakage or tampering. Furthermore, a one-time aggregation encryption operation is triggered only after the data block group is fully aggregated, encrypting the entire data block group as a whole. This ensures the overall security of the data block group while avoiding obstacles to the aggregation operation caused by pre-encryption, balancing security and processing smoothness.

[0102] In this embodiment, the verification of the source and digital signature of the data block group by the metadata verification group includes:

[0103] The metadata verification group receives the data block group and extracts the metadata verification information contained in the data block group;

[0104] Verify the data source in the metadata verification information to ensure the legitimacy of the data block group;

[0105] Verify the digital signature in the metadata verification information to ensure the integrity and non-repudiation of the data block group.

[0106] Specifically, after receiving the double-encrypted data block group, the metadata verification group first extracts metadata verification information containing data source, digital signature, and other information from the data block group. Then, it verifies the data source in the metadata verification information to confirm whether the data block group comes from a legitimate user terminal or authorized platform, ruling out the possibility of illegitimate data entering the blockchain network. Next, it verifies the digital signature in the metadata verification information. Signature verification ensures that the data block group has not been tampered with during transmission, while also guaranteeing the non-repudiation of the data sender. This allows subsequent data processing to be based on a reliable data source, improving the security and trustworthiness of the entire blockchain tourism data system.

[0107] In this embodiment, the hash values ​​of the data within the data block group are compared in parallel by the content consistency group, including:

[0108] The content consistency group receives the data block group and independently calculates the hash value of each data fragment within the data block group;

[0109] The independently computed hash values ​​are compared in parallel with the pre-stored hash digests in the data block group;

[0110] Based on the comparison results, the consistency of data content within the data block group was confirmed.

[0111] Specifically, after receiving the data block group, the content consistency group independently calculates the hash value of each data segment within the data block group (hash value calculation uses existing technology, which will not be elaborated here). The calculation process is carried out in parallel to avoid the delay of calculating a single data segment affecting the overall progress. After the calculation is completed, the obtained hash value is compared in parallel with the pre-stored hash digest in the data block group. By performing multiple sets of comparison operations simultaneously, it is quickly confirmed whether the hash value of each data segment is consistent with the pre-stored hash digest. Based on the final comparison result, it is determined whether the data within the data block group remains intact and has not been tampered with, ensuring the consistency of the data entering the storage stage and providing a reliable guarantee for subsequent user queries and use of data.

[0112] In this embodiment, the synchronous check of user access permissions to data by the permission audit group includes:

[0113] The access control audit group obtains the user identity information and access request type associated with the data block group;

[0114] Retrieve the user's corresponding permission rules from the preset permission management policy;

[0115] Simultaneously verify whether the user's identity has the permission to access or operate on the data block group.

[0116] Specifically, when processing data block groups, the access audit team first obtains the user identity information associated with the data block group and the type of access request initiated by the user, clarifying the user identity and purpose of the current operation. Then, it retrieves the specific access rules corresponding to the user identity from the preset access management policy to understand the scope of data the user can access and the types of operations they can perform. Based on the retrieved access rules, it simultaneously verifies whether the user identity has the necessary permissions to access or operate on the current data block group. If the user's permissions do not meet the requirements, their access or operation request is denied, preventing unauthorized users from obtaining sensitive travel data and effectively protecting user data privacy.

[0117] In this embodiment, storing the aggregated fingerprint of the data block group on the core blockchain and splitting the double-encrypted original data into data fragments and storing them on a lightweight sidechain includes:

[0118] The aggregate fingerprint of the data block group is uploaded to the core blockchain, and the aggregate fingerprint serves as the unique identifier of the data block group.

[0119] The original data after double encryption is fragmented, and the fragmented data segments are stored off-chain in a lightweight sidechain.

[0120] When it is necessary to query the original data, the corresponding data fragment on the lightweight sidechain is located by the aggregate fingerprint on the core blockchain, and the data is reconstructed.

[0121] Specifically, when storing aggregate fingerprints of data block groups on the core blockchain, the aggregate fingerprint is first uploaded to the core blockchain. This aggregate fingerprint serves as a unique identifier for the data block group, allowing for quick location of the corresponding data block group information. Next, the double-encrypted original data is fragmented, and the resulting data fragments are stored in a lightweight sidechain. This achieves off-chain storage of the original data from the core blockchain, significantly reducing the storage pressure on the core blockchain and improving its operational efficiency. When querying the original data, the aggregate fingerprint stored on the core blockchain quickly locates the corresponding data fragments on the lightweight sidechain. These data fragments are then integrated and recombined to ensure that users can accurately obtain the required original data, balancing storage efficiency and data query convenience.

[0122] In this embodiment, the step of locating the corresponding data fragment on the lightweight sidechain through the aggregated fingerprint on the core blockchain and reconstructing the data when it is necessary to query the original data includes:

[0123] Receive data query requests from users;

[0124] Retrieve aggregate fingerprints that match the query request within the core blockchain;

[0125] Based on the pointer information of the distributed cache layer and the data feature digest contained in the aggregate fingerprint, the corresponding encrypted data fragment is retrieved from the lightweight sidechain;

[0126] The retrieved encrypted data fragments are decrypted and reassembled to restore the original data.

[0127] Specifically, when a user issues a data query request, the system first receives the request and clarifies the scope and type of travel data the user needs to query. Then, it retrieves a matching aggregate fingerprint from the core blockchain to quickly identify the associated data block group. Based on the distributed cache layer pointer information and data feature digest contained in the aggregate fingerprint, it accurately retrieves the corresponding encrypted data fragment in a lightweight sidechain. The retrieved encrypted data fragment is then decrypted, and the decrypted fragments are reassembled according to their original data structure to ultimately restore the original travel data required by the user. This allows users to quickly obtain accurate data while avoiding the direct processing of large amounts of raw data queries on the core blockchain, thus ensuring the operational stability of the core blockchain.

[0128] In this embodiment, the step of automatically adjusting the computation frequency of the double-layer encryption and the number of shards in the lightweight sidechain based on real-time data traffic via a dynamic resource scheduler includes:

[0129] The dynamic resource scheduler monitors data traffic in the blockchain network in real time;

[0130] When data traffic is at off-peak times, the dynamic resource scheduler reduces the frequency of double encryption operations and decreases the number of shards in the lightweight sidechain.

[0131] When data traffic is at its peak, the dynamic resource scheduler increases the frequency of double-encrypted operations and the number of shards in the lightweight sidechain, while also enabling backup validator node groups to assist in processing.

[0132] Specifically, the dynamic resource scheduler monitors changes in data traffic within the blockchain network in real time to understand the data processing needs within the network at different times. The resource adjustment logic follows the calculation methods of formulas (2), (3), and (4), first by checking the real-time data traffic... Compared with the baseline flow rate Calculate the flow coefficient And then according to Adjusting the frequency of double-layer encryption operations and the number of lightweight sidechain segments When data traffic is detected to be during off-peak periods, The dynamic resource scheduler automatically reduces the computation frequency of double-encryption. This reduces unnecessary consumption of computing resources and also reduces the number of shards in the lightweight sidechain. This avoids resource waste caused by excessive data fragmentation. When data traffic peaks and the amount of new tourism data increases significantly, The dynamic resource scheduler immediately increases the frequency of double-encrypted operations. This ensures that newly added data is encrypted in a timely manner, while also increasing the number of shards in the lightweight sidechain. This improves the efficiency of storing and retrieving raw data, and enables backup verification node groups to assist in data verification operations, alleviating the pressure on the main verification node and ensuring that the system can still operate efficiently and stably during peak periods, avoiding data processing delays or system lag.

[0133] Please see Figure 2 The present invention also provides a blockchain-based tourism data privacy protection system, comprising:

[0134] The data aggregation module is used to build a distributed caching layer. The distributed caching layer is deployed between the blockchain node and the user terminal to dynamically capture new travel data from users and aggregate the new travel data into data block groups in a preset time window or data volume threshold.

[0135] The encryption processing module is used to perform two-layer encryption processing on the data block group. The two-layer encryption processing includes: applying lightweight symmetric encryption to the basic data in the data block group, and applying asymmetric encryption to the group-level metadata in the data block group.

[0136] The parallel verification module is used to submit the double-encrypted data block group to the blockchain network and initiate sharded parallel verification. The parallel verification module includes:

[0137] The node sharding unit is used to divide the verification nodes in the blockchain network into a metadata verification group, a content consistency group, and a permission audit group.

[0138] The collaborative verification unit is used by the metadata verification group to verify the source and digital signature of the data block group, by the content consistency group to compare the hash values ​​of the data within the data block group in parallel, and by the permission audit group to synchronously check the user's access rights to the data.

[0139] The message queue unit is used to enable lock-free parallel operations between the metadata verification group, the content consistency group, and the permission audit group.

[0140] The cross-chain storage module is used to store the aggregate fingerprint of data block groups on the core blockchain. The aggregate fingerprint contains the data feature digest of the data block group, the user permission mark, and the pointer to the distributed cache layer. It is also used to split the double-encrypted original data into data fragments and store them on a lightweight sidechain.

[0141] The consensus optimization module is used to process data using a two-stage consensus mechanism, which includes: a first stage in which a distributed caching layer quickly responds to new tourism data requests and returns temporary receipt credentials; and a second stage in which the final verification and storage of data block groups are completed asynchronously in the blockchain backend.

[0142] The resource scheduling module is used to automatically adjust the computation frequency of the double-encrypted system and the number of shards in the lightweight sidechain based on real-time data traffic through a dynamic resource scheduler.

[0143] Specifically, the data aggregation module in the blockchain tourism data privacy protection system constructs a distributed caching layer between blockchain nodes and user terminals to dynamically capture newly added tourism data from users, according to the triggering condition of formula (1), that is, when the accumulated amount of data... Or cumulative duration When new data is added, it is aggregated into data block groups. The encryption processing module performs two-layer encryption on the data block groups: lightweight symmetric encryption is used to process the basic data, and asymmetric encryption is used to process the group-level metadata.

[0144] The parallel verification module submits the double-encrypted data block group to the blockchain network. The node sharding unit divides the verification nodes into a metadata verification group, a content consistency group, and an access control audit group. The collaborative verification unit completes data source and signature verification, data hash value comparison (hash value calculation adopts existing technology), and access control verification, respectively. The message queue unit realizes lock-free parallel operation of the three groups of nodes.

[0145] The cross-chain storage module stores the aggregated fingerprint of data block groups on the core blockchain and stores the raw data shards on a lightweight sidechain. The consensus optimization module adopts a two-stage consensus mechanism: first, the distributed caching layer quickly responds to user requests and returns credentials, and then the final verification and storage are completed asynchronously in the background. The resource scheduling module uses a dynamic resource scheduler to adjust the encryption operation frequency and the number of sidechain shards based on formulas (2), (3), and (4) and in conjunction with real-time data traffic. All modules work together to achieve high efficiency and security in protecting tourism data privacy and adapt to the dynamic changes in tourism data.

[0146] In summary, this invention constructs a distributed caching layer between blockchain nodes and user terminals, aggregating newly added user travel data into data block groups according to preset time windows or data volume thresholds. This avoids performing a complete privacy protection process for each new data entry separately, reducing redundant computations and verification operations. The data block groups employ dual-layer encryption: lightweight symmetric encryption ensures basic data efficiency, while asymmetric encryption strengthens group-level metadata security. It initiates sharded parallel verification and uses message queues to achieve lock-free operation, shortening verification time. A two-phase consensus mechanism allows the distributed caching layer to quickly respond to user requests and return temporary credentials, while the background asynchronously completes final verification and storage. A dynamic resource scheduler adjusts the encryption operation frequency and the number of sidechain shards based on real-time traffic, increasing processing capacity during peak periods and reducing resource waste during off-peak periods. This solves the problems of low efficiency and unbalanced resource consumption in existing technologies for processing dynamic travel data, alleviates resource pressure during peak travel periods, and ensures the stable operation of the blockchain travel data system.

[0147] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0148] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1.A blockchain-based method for protecting privacy of tourism data, characterized in that, The application comprises the following steps: A distributed cache layer is constructed between the blockchain node and the user terminal, which is used to dynamically capture user-added travel data, and aggregate the added travel data into a data block group in units of a preset time window or data volume threshold; Double-layer encryption processing is performed on the data block group, including applying lightweight symmetric encryption to the basic data in the data block group and applying asymmetric encryption to the group-level metadata in the data block group; The double-layer encrypted data block group is submitted to the blockchain network, and sharded parallel verification is started, including: The verification nodes in the blockchain network are divided into a metadata verification group, a content consistency group and a permission audit group; The metadata verification group verifies the source and digital signature of the data block group; The content consistency group performs parallel comparison on the hash values of the data in the data block group; The permission audit group synchronously checks the access permission of the user to the data; The metadata verification group, the content consistency group and the permission audit group realize lock-free parallel operation through a message queue; The aggregated fingerprint of the data block group is stored on the core blockchain, and the aggregated fingerprint contains the data feature digest of the data block group, the user permission mark and the pointer of the distributed cache layer; The double-layer encrypted original data is split into data segments and stored in a lightweight side chain; A two-stage consensus mechanism is adopted for data processing, including: In the first stage, the distributed cache layer quickly responds to the added travel data request and returns a temporary receiving voucher; In the second stage, the final verification and storage of the data block group are completed asynchronously in the background of the blockchain; and According to the real-time data flow, the operation frequency of double-layer encryption and the number of sharding of the lightweight side chain are automatically adjusted by a dynamic resource scheduler: the dynamic resource scheduler monitors the data flow in the blockchain network in real time; when the data flow is in a non-peak period, the dynamic resource scheduler reduces the operation frequency of double-layer encryption and reduces the number of sharding of the lightweight side chain; when the data flow is in a peak period, the dynamic resource scheduler increases the operation frequency of double-layer encryption and increases the number of sharding of the lightweight side chain, and simultaneously enables a backup verification node group to assist in processing. 2.The method of claim 1, wherein, The construction of the distributed cache layer comprises: A distributed cache layer is established between the blockchain node and the user terminal, which is used as a real-time incremental buffer area for added travel data; The real-time incremental buffer area dynamically receives real-time added travel data from the user terminal; When the data volume in the real-time incremental buffer area reaches a preset storage threshold or when the real-time incremental buffer area has passed a preset time window, the added travel data in the real-time incremental buffer area is aggregated into a data block group. 3.The method of claim 1, wherein, The double-layer encryption processing of the data block group comprises: The first preset key is used to symmetrically encrypt the basic data in the data block group; The second preset key is used to asymmetrically encrypt the group-level metadata in the data block group, and the group-level metadata includes user identity feature information and key operation records; Only when the data block group is completed, a one-time aggregation encryption operation is triggered to encrypt the whole data block group. 4.The method of claim 1, wherein, The metadata verification group verifies the source and digital signature of the data block group, including: The metadata verification group receives the data block group and extracts the metadata verification information contained in the data block group; The data source in the metadata verification information is verified to ensure the legality of the data block group; The digital signature in the metadata verification information is verified to ensure the integrity and non-repudiation of the data block group. 5.The method of claim 1, wherein, The hash values of the data in the data block group are compared in parallel by the content consistency group, including: The content consistency group receives the data block group and independently calculates the hash values of each data segment in the data block group; The independently calculated hash values are compared in parallel with the pre-stored hash digest in the data block group; According to the comparison result, the content consistency of the data in the data block group is confirmed. 6.The method of claim 1, wherein, The access permission of the user to the data is synchronously checked by the permission audit group, including: The permission audit group obtains the user identity information and access request type associated with the data block group; The corresponding permission rule of the user is retrieved from the pre-set permission management policy; The permission of the user identity to access or operate the data block group is synchronously checked. 7.The method of claim 1, wherein, The aggregated fingerprint of the data block group is stored on the core blockchain, and the original data after double-layer encryption is split into data segments and stored in the lightweight side chain, including: The aggregated fingerprint of the data block group is uploaded to the core blockchain, and the aggregated fingerprint is used as the unique identifier of the data block group; The original data after double-layer encryption is fragmented, and the fragmented data segments are stored off-chain in the lightweight side chain; When the original data needs to be queried, the corresponding data segment on the lightweight side chain is located through the aggregated fingerprint on the core blockchain, and the data is recombined. 8.The method of claim 7, wherein, When the original data needs to be queried, the corresponding data segment on the lightweight side chain is located through the aggregated fingerprint on the core blockchain, and the data is recombined, including: Receiving a data query request issued by a user; Retrieving the aggregated fingerprint matching the query request in the core blockchain; According to the pointer information of the distributed cache layer and the data feature digest contained in the aggregated fingerprint, the corresponding encrypted data segment is retrieved from the lightweight side chain; The retrieved encrypted data segment is decrypted and recombined to restore the original data. 9.A blockchain-based tourism data privacy protection system implementing the method of any one of claims 1-8, characterized in that, It includes: A data aggregation module for building a distributed cache layer, which is deployed between a blockchain node and a user terminal, for dynamically capturing newly added tourism data of a user, and aggregating the newly added tourism data into a data block group in units of a pre-set time window or a data volume threshold; An encryption processing module for double-layer encryption processing of the data block group, including lightweight symmetric encryption of the basic data in the data block group and asymmetric encryption of the group-level metadata in the data block group; A parallel verification module for submitting the double-layer encrypted data block group to a blockchain network and starting a fragmented parallel verification, including: A node fragmentation unit for dividing the verification nodes in the blockchain network into a metadata verification group, a content consistency group, and a permission audit group; A collaborative verification unit for verifying the source and digital signature of the data block group by the metadata verification group, comparing the hash values of the data in the data block group in parallel by the content consistency group, and synchronously checking the access permission of the user to the data by the permission audit group; A message queue unit is configured to realize lock-free parallel operation among the metadata verification group, the content consistency group and the permission audit group; A cross-chain storage module is configured to store an aggregated fingerprint of the data block group on the core blockchain, the aggregated fingerprint containing a data feature digest of the data block group, a user permission mark and a pointer of the distributed cache layer, and to split the double-layer encrypted original data into data segments and store the data segments in the lightweight side chain; A consensus optimization module is configured to adopt a two-stage consensus mechanism for data processing, the two-stage consensus mechanism including: a first stage of quickly responding to a new tourism data request by the distributed cache layer and returning a temporary receiving voucher; and a second stage of asynchronously completing final verification and storage of the data block group in the background of the blockchain; A resource scheduling module is configured to automatically adjust the operation frequency of the double-layer encryption and the number of fragments of the lightweight side chain according to real-time data traffic through a dynamic resource scheduler: the dynamic resource scheduler monitors the data traffic in the blockchain network in real time; when the data traffic is in a non-peak period, the dynamic resource scheduler reduces the operation frequency of the double-layer encryption and reduces the number of fragments of the lightweight side chain; when the data traffic is in a peak period, the dynamic resource scheduler increases the operation frequency of the double-layer encryption and increases the number of fragments of the lightweight side chain, and simultaneously enables a backup verification node group to assist in processing.

Images