A multi-blockchain-based trusted hierarchical v2x data processing system

Abstract

The application relates to a multi-blockchain-based trusted hierarchical V2X data processing system, which comprises a vehicle layer, an RSU layer, a service layer and a cloud layer. The system proposes to divide the RSU network based on the RSU topological structure to reduce the data storage pressure; the system proposes a blockchain oracle mechanism in the Internet of Vehicles scene, through vehicle verification, node verification and cloud verification, all members in the system are organically involved in the data security protection process of the system, and the data security is ensured; the system proposes to use a particle swarm algorithm to optimize various parameters of the oracle, the optimization process is more scientific, and the effect is better than that of the experience-determined parameters.

Description

Technical Field

[0001] This invention belongs to the field of vehicle network data security technology, specifically involving a trusted hierarchical V2X data processing system and method based on multiple blockchains. Background Technology

[0002] Due to the variable nature of network deployment environments, data access based on RSU caching can reduce the time required for vehicles to acquire data, significantly improving the scalability and practicality of connected vehicle applications. However, the sheer volume of data in connected vehicles would place enormous pressure on terminal storage devices if all data were stored. Therefore, it is essential to select cached data, keeping only the most important cached data within the system. Current research on cache selection falls into two main categories. One type ignores the nature of the cached files, selecting files for caching solely based on overall file access frequency, file size, and access latency, without considering file content classification. The other type is based on the nature of the cached files; in contrast, this type analyzes file content and classifies files, then selects files based on the popularity of each category among users.

[0003] While caching-based connected vehicles offer greater efficiency and potential, they still harbor numerous security concerns, including data trustworthiness and privacy. The rapidly developing blockchain technology offers advantages in data encryption, immutability, traceability, and Byzantine fault tolerance, making it a promising new solution for secure content caching in connected vehicles. Existing products and research have proposed numerous solutions for integrating these two technologies, focusing on cloud storage and compression, role verification, and edge computing. However, most of these solutions still fail to address issues such as ensuring data security throughout the entire process, data timeliness, and effective blockchain partitioning.

[0004] Blockchain can use "blockchain oracles" to securely upload data and ensure the trustworthiness of the source data. Essentially, a blockchain oracle is a system that ensures the trustworthiness of data between different parts of the blockchain. Blockchains can achieve trusted data transmission by connecting to oracles or applying oracle mechanisms. Currently available oracles, such as Ethereum's ChainLink and Provable, already support the protection of simple information such as random numbers and weather information. However, there are currently no oracles suitable for connected vehicle scenarios. Existing research has also not conducted in-depth studies on blockchain oracles or proposed satisfactory solutions. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and propose a trusted hierarchical V2X data processing system based on multiple blockchains to solve the problems of data storage pressure and data security throughout the entire process.

[0006] The technical problem solved by this invention is achieved through the following technical solution:

[0007] A trusted hierarchical V2X data processing system based on multiple blockchains, characterized in that: the system includes a vehicle layer, an RSU layer, a service layer, and a cloud layer;

[0008] Each vehicle user in the vehicle layer requests data services from the RSU layer and provides service quality feedback after receiving the services from the RSU layer. At the same time, the data in the RSU layer is subject to both active and passive vehicle verification.

[0009] The RSU layer can automatically acquire information within the monitored area, form an instant cache, and upload it to the cloud layer to transform it into a long-term cache. It can also deploy and partition the data based on the acquired geographical location information and build a permitted blockchain within the partition. The RSU layer will periodically upload the service quality score feedback from the vehicle layer to the permitted blockchain. At the same time, the RSU layer will receive the tasks and data verifications scheduled by the service layer and upload the results to the permitted blockchain.

[0010] The service layer consists of multiple trusted servers. These trusted servers jointly maintain a permitted blockchain and complete the system's user management, task allocation, and status monitoring. They also register and authenticate the entities in the vehicle layer and RSU layer and record the identity information in the permitted blockchain.

[0011] The cloud layer is used to support the storage of data in the vehicle network data processing system.

[0012] Furthermore, the initialization process of the system includes partition determination, blockchain deployment, and member identity registration.

[0013] 1) Partition determination: The system first constructs a topology map based on the positional relationship and overlapping monitoring ranges of multiple RSUs in the RSU layer. Then, it divides the topology map based on the HDRF edge segmentation algorithm to obtain multiple partitions. Finally, it sets boundary partitions between each adjacent partition to solve the boundary data conflict problem.

[0014] 2) Blockchain deployment: In the service layer, the blockchain is deployed on a trusted server and runs in the form of a private chain to ensure the security of the service layer; in any area of ​​the RSU layer, the blockchain is deployed in the form of a consortium blockchain, and each RSU participates in the maintenance of the system as a blockchain node.

[0015] 3) Member Identity Registration: Each node in the service layer registers on the service layer blockchain to confirm its administrator identity. Then, service layer members go to various regions and register their administrator identities there to obtain the permission to publish tasks in that region. After the service layer members complete their operations, the node sends a request to the trusted server. The trusted server adds its identity to the blockchain, completing the node registration. The trusted server also updates the node's adjacency information based on existing information. Vehicle users can send requests to nodes at any time. The node generates and distributes blockchain wallets to vehicle users, enabling them to obtain legitimate identities.

[0016] Furthermore, the system's workflow includes data acquisition, oracle data verification, and task distribution.

[0017] 1) Data Acquisition:

[0018] a) The vehicle layer user initiates a data request to the RSU layer, containing the tag metadata of the required data;

[0019] b) The RSU layer checks the cache for the specified content; if it exists, it returns directly.

[0020] c) If it does not exist, go to the local blockchain, retrieve the data hash of the corresponding data domain through the tag metadata, sign the hash with the private key, and send it to the vehicle layer together with the cloud address;

[0021] d) Users use an address, carrying the signed hash and metadata of the required data, to retrieve data from the cloud layer;

[0022] e) The cloud layer uses the RSU public key to obtain the hash, then unlocks the access rights to the data field specified by the hash, and exchanges data with the vehicle layer;

[0023] 2) Oracle data verification

[0024] Oracle verification mechanisms include node verification, active / passive verification by the oracle, and cloud verification.

[0025] a) Node verification

[0026] Nodes perform mutual verification based on overlapping data to confirm whether adjacent nodes have data errors. If data errors occur frequently, it can be determined that the node may be corrupted or attacked.

[0027] The node verification process is as follows: At the beginning of the round, A initiates a transaction and announces the start of node verification. If other nodes find A to be adjacent to them, they send a request to that node to start verifying the data. If the verification passes, B initiates a transaction, which votes for A as an endorsement, and the voting power represents its credibility. If all votes are collected or the round is nearing its end, the votes are tallied. If the result is greater than 0, the verification passes. If the result is less than 0, A's data is considered unreliable, and A is forced to update its data and its credibility is reduced. After the update is completed, A participates in the vehicle active verification in the next round.

[0028] b) Passive verification of vehicles

[0029] When a vehicle acquires data, the vehicle user compares the acquired data with the information they can obtain to confirm whether the data returned by the node is correct.

[0030] The process of vehicle passive verification is as follows: In each round, once a vehicle user accesses node data, they can vote on its correctness and broadcast it. At the end of each round, each node counts the voting results. If more than half of the vehicles believe there is a problem, then the next round will enter the node verification process.

[0031] c) Vehicle Active Verification

[0032] After a problem is detected during node verification, to prevent malicious nodes from repeatedly falsely accusing other nodes, a third-party vehicle is deployed to perform a secondary verification of potentially problematic nodes. The verification method is the same as the passive verification performed by the vehicle.

[0033] The process of vehicle active verification is as follows: At the beginning of the current round, A broadcasts to all vehicles within range, requesting them to verify their own data. All vehicles that receive the message immediately perform a passive verification in response to the verification request. If the results are collected or the current round is about to end, the voting results are tallied. If the result is greater than 0, the verification passes; if the verification result is less than 0, A's data is considered unreliable, and A is forced to update its data and reduce its credibility. After completing the update, A participates in the node verification in the next round.

[0034] d) Cloud verification

[0035] Initiated by the top-level blockchain, the long-term cache inside the node is compared with the original data stored in the cloud to ensure the correctness of the node's long-term cache;

[0036] The cloud verification process involves the top-level blockchain initiating a verification request to A and providing a long-term cached digest that needs to be verified. A responds to the service layer's request by sending the corresponding part of the metadata and the digest. The service layer retrieves the corresponding data from the cloud using the metadata, generates a digest, and compares it with the data. If they are the same, the service layer records the verification result on the blockchain where A is located. Otherwise, it sends the correct information to the node, lowers the node's credibility, and forces it to participate in the next round of cloud verification.

[0037] 3) Task Issuance

[0038] 1) At the start of the round, the upper-layer blockchain publishes a list of nodes that will be verified by nodes, cloud verification, and vehicle active verification in this round. After each node finds the list, it starts the verification in the order of node verification, cloud verification, and vehicle active verification.

[0039] 2) During the rounds, the above verifications are completed while the vehicle is being passively verified.

[0040] 3) At the end of the round, the settlement is completed in the order of cloud verification, vehicle verification, and node verification. The node credibility is recalculated. After the upper-level nodes summarize the verification results, a new verification list is obtained and published in the next round.

[0041] Furthermore, the buffer lifecycle of the RSU layer and cloud layer of the system includes instant cache acquisition, instant cache verification, long-term cache generation and instant cache destruction, long-term cache verification and long-term cache destruction, and the specific process is as follows:

[0042] 1) Real-time cache retrieval

[0043] The RSU layer obtains raw data through the sensor and caches it in real time. Once the cache is obtained, it takes effect immediately, meaning that the vehicle user can now obtain this cached data based on the data acquisition process.

[0044] 2) Real-time cache verification

[0045] While the real-time cache still has a time limit, it is checked and corrected based on node verification, vehicle passive verification, and vehicle active verification.

[0046] 3) Long-term cache generation and immediate cache destruction

[0047] First, confirm whether the soon-to-expire instant cache has been verified. Only when both node verification and vehicle passive verification pass simultaneously is the current instant cache considered trustworthy. If the above conditions are not met, a node verification needs to be performed immediately, and the system needs to wait for the current round of vehicle passive verification until the above conditions are met. Then, the node uploads all instant caches to the cloud layer, selects the most popular data based on access frequency, converts it into long-term cache, and finally deletes other expired instant caches.

[0048] 4) Long-term cache verification

[0049] Over a relatively long period, cloud-based verification is used regularly to check and correct long-term caches.

[0050] 5) Long-term cache destruction

[0051] When a long-term cache expires, it will be deleted along with the currently expired immediate cache during the next long-term cache generation.

[0052] Furthermore, the oracle optimization parameters of the system include:

[0053] Node verification penalty coefficient Basic_node: During node verification, if node verification fails, the node's credibility will be reduced by multiplying this coefficient by the overall credibility of the verifier.

[0054] Vehicle active verification penalty coefficient Basic_car: In the active verification of vehicles, if the active verification of vehicles fails, the credibility of the node will be reduced by multiplying this coefficient by the proportion of the vote to veto.

[0055] Basic_cloud: During cloud verification, if the verification fails, the node's credibility will be reduced proportionally based on this coefficient.

[0056] Vehicle voting threshold (CarThreshold): To prevent specific vehicles from influencing the system results by participating in verification through a large amount of access data, a voting threshold needs to be set.

[0057] Node selection ratio NodePercent: At the beginning of each round, the server will randomly select a certain percentage of nodes for node verification based on this coefficient;

[0058] Minimum Credit Percent: When the creditworthiness drops below the product of this value and the maximum creditworthiness value, it is considered that it needs to be repaired.

[0059] The oracle parameter optimization process is as follows:

[0060] 1) Scenario Design: Design a verification scenario including the number of RSUs, the number of vehicles, the map size, the distribution relationship of RSUs, and the map data, and construct a simulation scenario for this system;

[0061] 2) Case Design: Generate user behavior sets to determine the damaged parts of the RSU, the type of damage, and the proportion of malicious vehicle users;

[0062] 3) Objective function design: Based on the oracle algorithm, in a specific scenario a, the following three metrics are obtained after a fixed number of rounds:

[0063] Damaged node repair ratio b a After a fixed number of rounds have been completed, how many damaged or malicious RSUs have been repaired?

[0064] Number of repairs r a After a fixed number of rounds have been completed, how many repair actions were performed to fix damaged or malicious RSUs?

[0065] Repair time t a The number of turns required to complete the repair. If the final repair percentage is less than 1, meaning the repair is not completed, then this is the maximum number of turns.

[0066] Based on this, the following evaluation function is obtained:

[0067] D a =W b *b a -W r *r a -W t *t a

[0068] Among them: W b W r W t These are all hyperparameters, specified as 0.6, 0.3, and 0.1 respectively.

[0069] 4) Apply the particle swarm optimization algorithm to optimize the parameters according to the objective function: Based on 1) and 2), under fixed scene information, generate multiple sets of attack and damage cases for nodes and vehicles. Then, apply the particle swarm optimization algorithm to set several initial parameter sets. For each input parameter, test it using the generated multiple sets of cases to obtain multiple evaluation values. Calculate the average value as the evaluation value of the input parameter. Then, using the particle swarm optimization algorithm, after multiple rounds, obtain the maximum evaluation value and its corresponding parameter set, which is the optimal parameter set.

[0070] The advantages and beneficial effects of this invention are as follows:

[0071] 1. This invention reduces the data storage pressure in the Internet of Vehicles + Blockchain system by means of cloud storage, blockchain partitioning, and data compression encoding, while maintaining the system's protection of data.

[0072] 2. This invention is based on a blockchain oracle design involving a vehicle network cache verification mechanism that comprises four parts: server, roadside unit (RSU), vehicle user, and cloud storage service. It integrates this mechanism into a trusted hierarchical V2X data processing system based on multiple blockchains, thereby providing protection for data before it reaches the blockchain and ensuring its security throughout the entire process together with the blockchain.

[0073] 3. This invention fully utilizes the capabilities of each member of the system to ensure the normal operation of the system. Through the collaborative cooperation of the four parts—vehicle, node, server, and cloud—the computing power of each part of the system can be utilized to provide services to the system together.

[0074] 4. This invention leverages the cloud layer and segments the vehicle network to reduce storage pressure. It introduces cloud storage services and stores data on the blockchain in the form of digital digests. This ensures unique data authentication (i.e., there is no other way to obtain and parse the original data in the cloud except through the digital digest on the blockchain) while reducing storage pressure. In addition, this system segments the RSU network and establishes independent blockchains in each partition, so that each RSU node does not need to store the entire blockchain information of the network, thus reducing its storage pressure.

[0075] 5. The cache verification process of this invention truly realizes "data being reliably recorded on the chain," ensuring the security of cached data throughout its entire lifecycle. The distributed oracle in this system is more resistant to common problems such as single points of failure and attacks.

[0076] 6. All real-time cache verification processes in this invention are post-verification processes, that is, the data is first validated and then periodically confirmed. This mechanism can effectively capture corrupted nodes without delaying the cache's effectiveness.

[0077] 7. The cache verification based on trustworthiness in this invention can serve blockchain consensus. Because the RSU network is an unmanned system, the nodes in it cannot perform active block maintenance. Trustworthiness, as the only indicator for comprehensive evaluation of nodes, can provide nodes with a basis for judging whether other nodes are trustworthy, enabling them to automatically select the nodes they trust the most and complete consensus-related tasks such as blockchain election. Attached Figure Description

[0078] Figure 1 This is a system architecture diagram of the present invention;

[0079] Figure 2 This is a cache lifecycle diagram of the present invention;

[0080] Figure 3 The flowchart for single-round verification of the task assignment in this invention is shown. Detailed Implementation

[0081] The present invention will be further described in detail below through specific embodiments. The following embodiments are merely descriptive and not limiting, and should not be used to limit the scope of protection of the present invention.

[0082] 1. System Design

[0083] like Figure 1As shown, a trusted hierarchical V2X data processing system based on multiple blockchains is innovative in that the system consists of the following four parts:

[0084] (1) Vehicle Layer

[0085] All vehicle users reside in the vehicle layer and are responsible for the following functions:

[0086] Service Request: Each vehicle user has the right to request data services from the RSU after registering their identity, and to rate and provide feedback on the Quality of Service (QoS) after receiving services from the RSU.

[0087] System maintenance: Each vehicle user is obligated to participate in the data verification at the RSU layer through both active and passive verification when an RSU request is initiated.

[0088] (2)RSU Layer

[0089] All Roadside Units (RSUs) reside in this layer. Each RSU in this system has the ability to independently acquire various information within its monitored area and provide data to users accordingly. During system deployment, all RSUs are partitioned according to geographical location, and each partition builds its own Permissioned Blockchain. Furthermore, to address the issue of different consensuses between two partitions on the same data, edge partitions are additionally set up in the RSU layer to resolve this data problem. The RSU layer is responsible for the following functions:

[0090] Service Response: Each RSU is obligated to provide service to a vehicle user after a request is made. Service quality feedback will be recorded and uploaded to the blockchain periodically.

[0091] System Maintenance: Each RSU is obligated to participate in various data verification processes within the time slice specified by the system, according to the tasks and indicators predetermined by the server layer, and to upload and record the results to the blockchain. Furthermore, each RSU is obligated to complete blockchain maintenance work according to system regulations.

[0092] Behavioral oversight: Each RSU has an obligation to oversee whether other RSUs have fulfilled their responsibilities, such as system maintenance, as required, and to report any RSU that fails to perform its responsibilities adequately.

[0093] Data storage: Each RSU is obligated to obtain information through its own sensor to form an immediate cache; and to retain some data at a certain time and upload it to the cloud to convert it into a long-term cache.

[0094] (3) Server Layer

[0095] This layer consists of multiple more powerful trusted servers. Each server collaboratively maintains a permitted blockchain, performing tasks such as user management, task allocation, and status monitoring based on pre-defined smart contracts, and recording these tasks on the blockchain. The service layer is responsible for the following functions:

[0096] Identity authentication: The entire service layer is obligated to register and authenticate the identities of any entity in the RSU layer and vehicle layer of the system, and record their identity information in the blockchain.

[0097] System monitoring: The entire service layer is obligated to determine the tasks and metrics for network verification of each RSU partition in the next time slice based on historical system status and current verification results.

[0098] (4) Cloud Layer:

[0099] As mentioned above, the cloud layer is responsible for supporting the storage of the massive amounts of data in the vehicle-to-everything (V2X) system. In this system, we assume that the cloud is trustworthy, meaning that the cloud layer can reliably store and protect the data stored therein, and that it will not be tampered with.

[0100] The system initialization process of this invention is divided into three parts: partition determination, blockchain deployment, and member identity registration.

[0101] (1) Partition determination: The system first constructs a topology map based on the positional relationship between RSUs and the overlap of monitoring ranges. Then, it divides the topology map based on the HDRF edge segmentation algorithm to obtain multiple partitions. Finally, it sets boundary partitions between each adjacent partition to solve the boundary data conflict problem.

[0102] (2) Blockchain deployment: In the service layer, the blockchain is deployed on the server and runs in the form of a private chain to ensure the security of the service layer; in any area of ​​the RSU layer, the blockchain is deployed in the form of a consortium chain, and each RSU participates in the maintenance of the system as a blockchain node.

[0103] (3) Member Registration: Each node in the service layer registers on the service layer's blockchain to confirm its administrator status. Then, service layer members travel to various regions and register their administrator status there to gain permission to publish tasks in those regions. After completing their operations, the node sends a request to the server, which adds its identity to the blockchain, completing the node registration. The server then updates the node's adjacency information based on existing data. Vehicle users can send requests to nodes at any time, and the nodes generate and distribute blockchain wallets to the vehicles, granting them a legitimate identity.

[0104] The main workflow of the system of the present invention includes three parts: data acquisition, data verification, and task distribution.

[0105] (1) Data Acquisition:

[0106] a) The user initiates a data request to the RSU, containing metadata about the tags for the required data.

[0107] b) RSU checks its own cache for the specified content. If it exists, it returns the result directly.

[0108] c) If it does not exist, proceed to the local blockchain and retrieve the data hash of the corresponding data field through metadata. Sign the hash with the private key and send it along with the cloud address.

[0109] d) Users use an address, carrying the signed hash and metadata of the required data, to retrieve data from the cloud.

[0110] e) The cloud uses the RSU public key to obtain the hash, then unlocks the access rights to the data field specified by the hash, and exchanges data with the vehicle.

[0111] (2) Data verification and task distribution: These will be detailed in sections 2.a) and 2.c).

[0112] 2. Oracles in the context of connected vehicles

[0113] a) Oracle verification mechanism

[0114] Oracle verification mechanisms include node verification, active (passive) verification by the vehicle, and cloud verification.

[0115] (1) Node verification

[0116] The main purpose of node verification is to allow nodes to cross-check each other based on overlapping data to confirm whether adjacent nodes have data errors. If data errors occur frequently, it can be determined that the node may be corrupted or attacked.

[0117] The node verification process is as follows (taking RSUA as an example): At the start of the round, node A initiates a transaction to announce the start of node verification. Other nodes (such as RSU B) that find A as their neighbor will send a request to that RSU to begin verifying the data (verification is an off-chain process). If the verification passes, B initiates a transaction, which votes for A, endorsing it. The vote weight represents its credibility. If all votes are collected or near the end of each round, the votes are tallied. If the result is greater than 0, the data passes. If the result is less than 0, A's data is considered untrustworthy. A will be forced to update its data and its credibility will be reduced. After completing the update, A will participate in the vehicle active verification in the next round.

[0118] (2) Passive verification of vehicles

[0119] The main purpose of vehicle passive verification is to allow vehicle users to compare the data they can obtain with the data they receive when the vehicle is acquiring data, in order to confirm whether the data returned by the node is correct.

[0120] The passive verification process for vehicles (taking RSUA as an example) is as follows: In each round, once a vehicle user accesses node data, they can vote on its correctness and broadcast the vote. At the end of each round, each node tallies the voting results. If more than half of the vehicles believe there is a problem, the system will proceed to node verification in the next round.

[0121] (3) Vehicle active verification

[0122] The main purpose of vehicle-based active verification is to prevent malicious nodes from repeatedly framing nodes after a problem is found during node verification. The vehicle is mobilized as a third party to perform secondary verification on nodes that may have problems. The verification method is the same as that of vehicle-based passive verification.

[0123] The vehicle-initiated verification process is as follows (taking RSUA as an example): At the start of the current round, vehicle A broadcasts to all vehicles within range, requesting them to verify its data. All vehicles receiving the message immediately perform a data acquisition and feedback process (i.e., passive verification) in response to the verification request. If the results are collected or the current round is about to end, the voting results are tallied. If the result is greater than 0, the verification passes. If the verification result is less than 0, A's data is considered unreliable. A will be forced to update its data and its credibility will be reduced. After completing the update, A will participate in the node verification in the next round.

[0124] (4) Cloud verification

[0125] The main purpose of cloud verification is to compare the long-term cache inside the node with the original data stored in the cloud, initiated by the top-level blockchain, to ensure the correctness of the node's long-term cache.

[0126] The cloud verification process is as follows (taking RSUA as an example): The top-level blockchain initiates a verification request to A, providing a long-term cached digest that needs to be verified. A responds to the service layer's request by sending the corresponding metadata and digest. The service layer retrieves the corresponding data from the cloud using the metadata, generates a digest, and compares it. If they match, the service layer records the verification result on A's blockchain. Otherwise, it sends the correct information to the node, lowers the node's credibility, and forces it to participate in the next round of cloud verification.

[0127] b) Caching mechanisms and their lifecycle

[0128] The cache lifecycle consists of five parts: immediate cache fetching, immediate cache validation, long-term cache generation and immediate cache destruction, long-term cache validation, and long-term cache destruction. The specific process is as follows: Figure 2 As shown.

[0129] (1) Real-time cache retrieval:

[0130] The RSU acquires raw data through the sensor and caches it immediately. Once the cache is acquired, it takes effect immediately, meaning that the vehicle user can now access this cached data based on the data acquisition process in 1.c.1).

[0131] (2) Real-time cache verification

[0132] While the real-time cache still has time sensitivity, it is checked and corrected based on node verification, vehicle passive verification, and vehicle active verification in 2.a).

[0133] (3) Long-term cache generation and immediate cache destruction

[0134] First, verify that the soon-to-expire instant cache has been validated. Only when both node validation and vehicle passive validation pass simultaneously is the current instant cache considered trustworthy. If these conditions are not met, a node validation must be performed immediately, and the system must wait for the current round of vehicle passive validation until the conditions are met. Then, the node uploads all instant caches to the cloud and selects the most frequently accessed data based on access frequency, converting it into a long-term cache. Finally, delete any other expired instant caches.

[0135] (4) Long-term cache verification

[0136] Over a relatively long period, the long-term cache is periodically checked and corrected using the cloud verification in section 2.2.2.

[0137] (5) Long-term cache destruction

[0138] When a long-term cache expires, it will be deleted along with the currently expired immediate cache during the next long-term cache generation.

[0139] c) Single-round verification process

[0140] Building upon the previous two parts, this section will demonstrate the verification process of the oracle algorithm in one round, as shown in the flowchart below. Figure 3 As shown.

[0141] (1) At the start of the round, the upper-layer blockchain publishes a list of nodes that will undergo node verification, cloud verification, and vehicle-initiated verification in this round. After each node retrieves the list, it begins verification in the order of node verification, cloud verification, and vehicle-initiated verification.

[0142] (2) During the rounds, the above-mentioned verifications are completed while the vehicle's passive verification is performed.

[0143] (3) At the end of the round, settlement is completed in the order of cloud verification, vehicle verification, and node verification, and node credibility is recalculated. After the upper-level nodes summarize the verification results, a new verification list is obtained and published in the next round.

[0144] d) Oracle optimization

[0145] In the oracle designed for this system, the following parameters need to be specified:

[0146] (1) Node verification penalty coefficient Basic_node: During node verification, if node verification fails, the node's credibility will be reduced by multiplying this coefficient by the overall credibility of the verifier.

[0147] (2) Vehicle active verification penalty coefficient Basic_car: In the active verification of vehicles, if the active verification of vehicles fails, the credibility of the node will be reduced by multiplying this coefficient by the proportion of the vote to veto.

[0148] (3) Cloud verification penalty coefficient Basic_cloud: If the cloud verification fails, the node's credibility will be reduced proportionally according to this coefficient.

[0149] (4) Vehicle voting threshold CarThreshold: To prevent specific vehicles from affecting the system results by participating in the verification through a large amount of access data, a voting threshold needs to be set.

[0150] (5) Node selection ratio NodePercent: At the beginning of each round, the server will randomly select a certain percentage of nodes for node verification based on this coefficient.

[0151] (6) Minimum Credit Percent: When the creditworthiness drops below the product of this value and the maximum creditworthiness value (i.e., the creditworthiness threshold), it is considered that it needs to be repaired.

[0152] To scientifically set parameters based on the characteristics of the scenario, we propose using the particle swarm optimization algorithm for optimization, as follows:

[0153] (1) Scene design:

[0154] Based on the oracle's process, an algorithm model is implemented. Furthermore, to complete the algorithm simulation, a verification scenario needs to be designed, consisting of the following elements: the number of RSUs, the number of vehicles, the map size, the distribution of RSUs, and the map data. Based on these five parts, a simulation scenario for this system is constructed.

[0155] (2) Case Design:

[0156] Generate user behavior sets to determine which RSUs will be compromised, in what form (data corruption or attack), and what percentage of vehicle users are malicious.

[0157] (3) Objective function design

[0158] Based on the oracle algorithm, the following three metrics can be obtained in a specific scenario (a) and based on a specific case, after a fixed number of rounds:

[0159] Damaged node repair ratio b a After a fixed number of rounds have been completed, how many damaged or malicious RSUs have been repaired?

[0160] Number of repairs r a This metric represents the number of repair actions performed to fix damaged or malicious RSUs after a fixed number of rounds have been completed. Note that this metric is only meaningful when the repair rate is 1 (i.e., a complete repair).

[0161] Repair time t a : Number of turns required to complete the repair. If the final repair percentage is less than 1 (i.e., the repair is not completed), then this is the maximum number of turns.

[0162] Based on this, the following evaluation function is obtained: D a =W b *b a -W r *r a -W t *t a

[0163] Among them, W b W r W t These are all hyperparameters and cannot be obtained using the particle swarm optimization algorithm. In this system, we specify the three hyperparameters as 0.6, 0.3, and 0.1. The reasons are as follows:

[0164] For W b Since the core objective of the algorithm is to discover and automatically eliminate all damaged or malicious nodes, W b The value is the highest.

[0165] For W r Since the number of repairs represents the number of times manual intervention is required, this action is much more costly than automatic system repair, and therefore has a higher weight.

[0166] As for W t Since the time for a single round is not too long, the repair time will not affect the algorithm's performance, so it has the lowest weight.

[0167] (4) Apply the particle swarm optimization algorithm to optimize the parameters based on the objective function. The optimization method is as follows:

[0168] Based on (1) and (2), under fixed scene information, multiple sets of attack and damage cases for nodes and vehicles are generated. Then, the particle swarm optimization algorithm is applied to set several initial parameter sets. For each input parameter, multiple sets of cases generated in (a) are used for testing, and multiple evaluation values ​​are obtained. The average value is then calculated as the evaluation value of the input parameter.

[0169] Then, by using the particle swarm optimization algorithm, after multiple rounds, we obtain the maximum evaluation value and its corresponding parameter set, which is the optimal parameter set we are looking for.

[0170] Although embodiments and drawings of the present invention have been disclosed for illustrative purposes, those skilled in the art will understand that various substitutions, variations and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the scope of the present invention is not limited to the contents disclosed in the embodiments and drawings.

Claims

1. A trusted hierarchical V2X data processing system based on multiple blockchains, characterized in that: The system includes a vehicle layer, an RSU layer, a service layer, and a cloud layer; Each vehicle user in the vehicle layer requests data services from the RSU layer and provides service quality feedback after receiving the services from the RSU layer. At the same time, the data in the RSU layer is subject to both active and passive vehicle verification. The RSU layer can automatically acquire information within the monitored area, form an instant cache, upload it to the cloud layer to transform it into a long-term cache, and deploy partitions based on the acquired geographical location information, and build a permitted blockchain within the partitions. The RSU layer will periodically upload the service quality score feedback from the vehicle layer to the permitted blockchain. Meanwhile, the RSU layer receives the tasks and data verifications scheduled by the service layer and uploads the results to the permitted blockchain; The service layer consists of multiple trusted servers. These trusted servers jointly maintain a permitted blockchain and complete the system's user management, task allocation, and status monitoring. They also register and authenticate the entities in the vehicle layer and RSU layer and record the identity information in the permitted blockchain. The cloud layer is used to support the storage of data in the vehicle network data processing system; The system's workflow includes data acquisition, oracle data verification, and task distribution. 1) Data Acquisition: a) The vehicle layer user initiates a data request to the RSU layer, containing the tag metadata of the required data; b) The RSU layer checks the cache for the specified content; if it exists, it returns directly. c) If it does not exist, go to the local blockchain, retrieve the data hash of the corresponding data domain through the tag metadata, sign the hash with the private key, and send it to the vehicle layer together with the cloud address; d) Users use an address, carrying the signed hash and metadata of the required data, to retrieve data from the cloud layer; e) The cloud layer uses the RSU public key to obtain the hash, then unlocks the access rights to the data field specified by the hash, and exchanges data with the vehicle layer; 2) Oracle data verification Oracle verification mechanisms include node verification, active / passive verification by the oracle, and cloud verification. a) Node verification Nodes perform mutual verification based on overlapping data to confirm whether adjacent nodes have data errors. If data errors occur frequently, it can be determined that the node may be corrupted or attacked. The node verification process is as follows: A initiates a transaction at the beginning of this round and announces the start of node verification. If other nodes find that A is adjacent to them, they will send a request to that node to start verifying the data. If the verification passes, B initiates a transaction and votes for A to endorse it. The voting power represents its credibility. If all votes are collected or the round is nearing its end, the votes are tallied. If the result is greater than 0, the vote passes. If the result is less than 0, A's data is considered unreliable, and A is forced to update its data and reduce its credibility. After the update is completed, A will participate in the vehicle active verification in the next round. b) Passive verification of vehicles When a vehicle acquires data, the vehicle user compares the acquired data with the information they can obtain to confirm whether the data returned by the node is correct. The process of vehicle passive verification is as follows: In each round, once a vehicle user accesses node data, they can vote on its correctness and broadcast it. At the end of each round, each node counts the voting results. If more than half of the vehicles believe there is a problem, then the next round will enter the node verification process. c) Vehicle Active Verification After a problem is detected during node verification, to prevent malicious nodes from repeatedly falsely accusing other nodes, a third-party vehicle is deployed to perform a secondary verification of potentially problematic nodes. The verification method is the same as the passive verification performed by the vehicle. The process of vehicle active verification is as follows: At the beginning of the current round, A broadcasts to all vehicles within range, requesting them to verify their own data. All vehicles that receive the message immediately perform a passive verification in response to the verification request. If the results are collected or the current round is about to end, the voting results are tallied. If the result is greater than 0, the verification passes; if the verification result is less than 0, A's data is considered unreliable, and A is forced to update its data and reduce its credibility. After completing the update, A participates in the node verification in the next round. d) Cloud verification Initiated by the top-level blockchain, the long-term cache inside the node is compared with the original data stored in the cloud to ensure the correctness of the node's long-term cache; The cloud verification process involves the top-level blockchain initiating a verification request to A and providing a long-term cached digest that needs to be verified. A responds to the service layer's request by sending the corresponding part of the metadata and the digest. The service layer retrieves the corresponding data from the cloud using the metadata, generates a digest, and compares it with the data. If they are the same, the service layer records the verification result on the blockchain where A is located. Otherwise, it sends the correct information to the node, lowers the node's credibility, and forces it to participate in the next round of cloud verification. 3) Task Issuance 1) At the start of the round, the upper-layer blockchain publishes a list of nodes that will be verified by nodes, cloud verification, and vehicle active verification in this round. After each node finds the list, it starts the verification in the order of node verification, cloud verification, and vehicle active verification. 2) During the rounds, the above verifications are completed while the vehicle is being passively verified. 3) At the end of the round, the settlement is completed in the order of cloud verification, vehicle verification, and node verification. The node credibility is recalculated. After the upper-level nodes summarize the verification results, a new verification list is obtained and published in the next round. The cache lifecycle of the RSU layer and cloud layer of the system includes instant cache acquisition, instant cache verification, long-term cache generation and instant cache destruction, long-term cache verification and long-term cache destruction, and the specific process is as follows: 1) Real-time cache retrieval The RSU layer obtains raw data through the sensor and caches it in real time. Once the cache is obtained, it takes effect immediately, meaning that the vehicle user can now obtain this cached data based on the data acquisition process. 2) Real-time cache verification While the real-time cache still has a time limit, it is checked and corrected based on node verification, vehicle passive verification, and vehicle active verification. 3) Long-term cache generation and immediate cache destruction First, confirm whether the soon-to-expire instant cache has been verified. Only when both node verification and vehicle passive verification pass simultaneously is the current instant cache considered trustworthy. If the above conditions are not met, a node verification needs to be performed immediately, and the system needs to wait for the current round of vehicle passive verification until the above conditions are met. Then, the node uploads all instant caches to the cloud layer, selects the most popular data based on access frequency, converts it into long-term cache, and finally deletes other expired instant caches. 4) Long-term cache verification Over a relatively long period, cloud-based verification is used regularly to check and correct long-term caches. 5) Long-term cache destruction When a long-term cache expires, it will be deleted along with the currently expired immediate cache during the next long-term cache generation; the system initialization process includes partition determination, blockchain deployment, and member identity registration. 1) Partition determination: The system first constructs a topology map based on the positional relationship and overlapping monitoring ranges of multiple RSUs in the RSU layer. Then, it divides the topology map based on the HDRF edge segmentation algorithm to obtain multiple partitions. Finally, it sets boundary partitions between each adjacent partition to solve the boundary data conflict problem. 2) Blockchain deployment: In the service layer, the blockchain is deployed on a trusted server and runs in the form of a private chain to ensure the security of the service layer; in any area of ​​the RSU layer, the blockchain is deployed in the form of a consortium blockchain, and each RSU participates in the maintenance of the system as a blockchain node. 3) Member Identity Registration: Each node in the service layer registers on the service layer blockchain to confirm its administrator identity. Then, service layer members go to various regions and register their administrator identities there to obtain the permission to publish tasks in that region. After the service layer members complete their operations, the node sends a request to the trusted server. The trusted server adds its identity to the blockchain, completes the node registration, and updates the node's adjacency information based on the existing information. Vehicle users can send requests to the node at any time. The node generates and distributes a blockchain wallet to the vehicle user, enabling it to obtain a legitimate identity.

2. The trusted hierarchical V2X data processing system based on multiple blockchains according to claim 1, characterized in that: The oracle optimization parameters of the system include: Node verification penalty coefficient Basic_node: During node verification, if node verification fails, the node's credibility will be reduced by multiplying this coefficient by the overall credibility of the verifier. Vehicle active verification penalty coefficient Basic_car: In the active verification of vehicles, if the active verification of vehicles fails, the credibility of the node will be reduced by multiplying this coefficient by the proportion of the vote to veto. Basic_cloud: During cloud verification, if the verification fails, the node's credibility will be reduced proportionally based on this coefficient. Vehicle voting threshold (CarThreshold): To prevent specific vehicles from influencing the system results by participating in verification through a large amount of access data, a voting threshold needs to be set. Node selection ratio NodePercent: At the beginning of each round, the server will randomly select a certain percentage of nodes for node verification based on this coefficient; Minimum Credit Percent: When the creditworthiness drops below the product of this value and the maximum creditworthiness value, it is considered that it needs to be repaired. The oracle parameter optimization process is as follows: 1) Scenario Design: Design a verification scenario including the number of RSUs, the number of vehicles, the map size, the distribution relationship of RSUs, and the map data, and construct a simulation scenario for this system; 2) Case Design: Generate user behavior sets to determine the damaged parts of the RSU, the type of damage, and the proportion of malicious vehicle users; 3) Objective function design: Based on the oracle algorithm, in a specific scenario a, the following three metrics are obtained after a fixed number of rounds: Damaged node repair ratio b a After a fixed number of rounds have been completed, how many damaged or malicious RSUs have been repaired? Number of repairs r a After a fixed number of rounds have been completed, how many repair actions were performed to fix damaged or malicious RSUs? Repair time t a The number of turns required to complete the repair. If the final repair percentage is less than 1, meaning the repair is not completed, then this is the maximum number of turns. Based on this, the following evaluation function is obtained: D a =W b b a -W r r a -W t t a Among them: W b W r W t These are all hyperparameters, specified as 0.6, 0.3, and 0.1 respectively. 4) Apply the particle swarm optimization algorithm to optimize the parameters according to the objective function: Based on 1) and 2), under fixed scene information, generate multiple sets of attack and damage cases for nodes and vehicles. Then, apply the particle swarm optimization algorithm to set several initial parameter sets. For each input parameter, test it using the generated multiple sets of cases to obtain multiple evaluation values. Calculate the average value as the evaluation value of the input parameter. Then, using the particle swarm optimization algorithm, after multiple rounds, obtain the maximum evaluation value and its corresponding parameter set, which is the optimal parameter set.

Images