Vehicle Internet of Things Data Sharing Method and System Based on Dynamic Behavior Atlas and Blockchain

Abstract

The present invention discloses a vehicle networking data sharing method and system based on a dynamic behavior graph and a blockchain, which relates to the technical field of vehicle networking information security, and includes: obtaining vehicle driving-related data, preprocessing the vehicle driving-related data, encrypting the processed vehicle driving-related data with an asymmetric key, and uploading the encrypted vehicle driving-related data to the RSU; based on the encrypted vehicle driving-related data, taking the vehicle and the RSU as nodes and the interaction relationship between the vehicle and the RSU as edges to generate a dynamic behavior graph, querying the data hash value based on the dynamic behavior graph, and decrypting the encrypted vehicle driving-related data; determining whether the decrypted vehicle driving-related data is valid based on the data hash value, if it is invalid, triggering an exception handling mechanism, otherwise indicating that the data is available, thereby realizing data sharing and providing high-reliability and low-latency collaborative decision-making support for autonomous driving and intelligent transportation systems.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Vehicles information security, and specifically to a method and system for sharing Internet of Vehicles data based on a dynamic behavior graph and blockchain. Background Art

[0002] In an Internet of Vehicles (IoV) system, the real-time data sharing technology based on environmental perception and road information interaction is a fundamental element to support the environmental perception and decision-making control of an autonomous driving system and an intelligent assisted driving system. Through the multi-source data interaction among vehicles, roadside units, and the cloud, the IoV can integrate the sensing data of intelligent connected vehicles, the dynamic information of neighboring vehicles, and the high-precision map resources of remote content providers to form a multi-dimensional traffic situation perception ability. Among them, the real-time data sharing between vehicles not only supports the optimization of vehicle driving parameters (such as path planning, speed coordination), but also improves the system's dynamic adaptability to complex traffic scenarios. It constructs a reliable technical support framework for key scenarios such as collaborative accident warning and real-time decision-making support in an intelligent transportation system, and finally realizes a closed-loop link from data fusion to driving behavior optimization. However, due to the high-dynamic topology structure, wide-area coverage characteristics of the IoV system, and the imperfect node trust evaluation mechanism, data sharing still faces challenges in terms of security, efficiency, and reliability.

[0003] In recent years, the decentralized, anonymous, and data-immutable characteristics of blockchain technology (such as sharding technology, zero-knowledge proof, DAG structure) have provided a new trusted paradigm for IoV data sharing. Aiming at the low throughput problem of traditional public blockchains, sharding technology realizes parallel transaction processing through dynamic node allocation (based on vehicle reputation, computing power, and location centrality), significantly improving the system throughput; zero-knowledge proof completes anonymous auditing without exposing the original data, taking into account both privacy and verifiability. To further reduce the consensus delay, some research combines blockchain with edge computing. For example, the local processing of edge nodes reduces the online computing load, or intelligent algorithms are used to optimize the data delivery strategy to reduce the transmission delay. In the field of trust management, the consortium blockchain trust model guarantees data reliability through a reputation scoring and malicious recommendation filtering mechanism, and a dynamic game mechanism is introduced to integrate traffic environment parameters for reputation evaluation, thereby motivating vehicles to actively cooperate. In addition, the application of federated learning and deep reinforcement learning technologies further expands the technical boundaries: machine learning is used to model the knowledge trading market, and the time series prediction model combines an adaptive strategy optimization to achieve a balance between privacy protection and data utility. However, the existing solutions still have significant technical bottlenecks in aspects such as dynamic trust evaluation, consensus efficiency improvement, and resource optimization adaptation, and it is difficult to meet the real-time trusted data sharing requirements in high-dynamic scenarios of the IoV. Summary of the Invention

[0004] To address the deficiencies mentioned in the above background art, the purpose of the present invention is to provide a vehicle networking data sharing method and system based on a dynamic behavior map and blockchain.

[0005] In a first aspect, the purpose of the present invention can be achieved through the following technical solutions: A vehicle networking data sharing method based on a dynamic behavior map and blockchain, the method comprising the following steps:

[0006] Obtain vehicle driving-related data, preprocess the vehicle driving-related data, encrypt the processed vehicle driving-related data using an asymmetric key, and upload the encrypted vehicle driving-related data to the RSU, wherein the vehicle driving-related data includes vehicle location, road conditions, and vehicle speed;

[0007] Based on the encrypted vehicle driving-related data, generate a dynamic behavior map with vehicles and RSUs as nodes and the interaction relationship between vehicles and RSUs as edges, query the data hash value based on the dynamic behavior map, and decrypt the encrypted vehicle driving-related data;

[0008] Determine whether the decrypted vehicle driving-related data is valid based on the data hash value. If it is invalid, trigger an exception handling mechanism; otherwise, it indicates that the data is available, thus realizing data sharing.

[0009] Combined with the first aspect, in certain implementation manners of the first aspect, the method further includes: The process of encrypting the processed vehicle driving-related data using an asymmetric key and uploading the encrypted vehicle driving-related data to the RSU:

[0010]

[0011] where is the th vehicle; is the th road test unit; represents encrypting the data using the public key of the road test unit ; is the vehicle driving-related data to be transmitted; is using the private key of vehicle to perform a digital signature on ; is the th pseudo-identifier of vehicle ; is the vehicle location information; is the vehicle real-time status information; is the timestamp generated by the data;

[0012] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: after receiving the encrypted vehicle driving-related data, the RSU verifies the legality and consistency of the vehicle driving-related data, detects abnormal behaviors, updates the malicious counter of the vehicle, and submits the vehicle driving-related data to the graph to trigger graph update:

[0013]

[0014] where is the malicious behavior counter of the vehicle ; is the dynamic behavior graph; represents the graph update function; is a node in the dynamic behavior graph, is an edge in the dynamic behavior graph.

[0015] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: the generation process of the dynamic behavior graph:

[0016] Taking the vehicle and the RSU as nodes and the interaction relationship as edges to generate a dynamic behavior graph and endowing corresponding attributes, with direct data updated in real time: the original data uploaded by the vehicle is synchronized to the graph in real time according to the timestamp; the trust value is dynamically adjusted: divided into periodic maintenance and real-time event-driven; the trust value update is divided into periodic maintenance and real-time event-driven, and every fixed update, and real-time event-driven includes that when events such as the vehicle interacting with the RSU or other vehicles, the RSU detecting abnormal behaviors, and the malicious behavior detection of the dynamic behavior graph occur, the attributes of the nodes and edges in the dynamic behavior graph are dynamically adjusted, triggering a re-evaluation of the trust value;

[0017]

[0018]

[0019] where is the dynamic behavior graph; is the set of nodes in the graph; is the set of edges; is the set of attributes of the nodes and edges; is the periodic update; is the event-driven update; is the interaction event between the vehicle and other entities; is the abnormal behavior detection event.

[0020] The dynamic behavior graph regularly clears the nodes and edges that have been inactive for a long time, recalculates the behavior feature vectors, and the data submission and trust value update will be uploaded to the dynamic behavior graph blockchain in the form of transactions:

[0021]

[0022] In the formula, is the dynamic behavior graph; is the graph cleaning function; is the set of nodes and edges that have been inactive for a long time; is the blockchain ledger; is the matrix-form transaction; is the updated node trust value; is the data submission timestamp.

[0023] Combined with the first aspect, in some implementations of the first aspect, the method further includes: The vehicle trust value is calculated using trust evaluation, and the trust evaluation uses the time-series weighted decay trust aggregation algorithm TWDT-Trust. The trust value is synthesized by four dynamic modules: the direct interaction trust module, the indirect recommendation trust module, the time decay weighted module, and the dynamic correction and penalty module:

[0024]

[0025] Among them, is the vehicle at time trust value, ; is the direct interaction trust; is the indirect recommendation trust; is the time decay interval, which is the time difference from the most recent interaction to the current; is the environment correction factor, where ; is the malicious penalty term, where ; is the weight coefficient; is the decay coefficient.

[0026] Combined with the first aspect, in some implementations of the first aspect, the method further includes: The process of querying the data hash value based on the dynamic behavior graph and decrypting the encrypted vehicle driving-related data:

[0027] The data requester sends a request. If the target data is a node or edge attribute, it directly queries the dynamic behavior graph, queries the hash value of the data through the dynamic behavior graph blockchain, decrypts the data using the supplier's public key, and verifies the content integrity by comparing the data hash value SHA-256 stored in the blockchain;

[0028]

[0029] In the formula, is the data requester; is the dynamic behavior graph; is the query operation function; is the target pseudo-identifier; is the data hash value generated using the SHA-256 algorithm; is the verification function; is to decrypt the data using the supplier's public key; is the hash value recalculated after data decryption; is the original data hash value stored on the blockchain.

[0030] If it is other data or the number of data trusted nodes is insufficient, the data collection process will be triggered. The data requester broadcasts the data requirements through the RSU, and the data provider sends the data index Index to the RSU. The data index contains metadata and its hash value. The RSU collects the responding Index, checks the trust value of the sender. If the trust value is higher than the threshold Tthreshold, it is added to the data sharing blockchain, otherwise it is ignored:

[0031]

[0032] In the formula, is the data requester; is the data requirement description; is the data provider; is the data index; is the metadata; is the hash value of the data.

[0033] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: the process of determining whether the decrypted vehicle driving-related data is valid based on the data hash value:

[0034] The data requester retrieves the latest block through the blockchain browser or the local light node, parses the index information of the target data. If the current block does not contain the required data, it can query back along the blockchain history until a matching record is found. The data requester views the trust value of the data provider through the dynamic behavior graph, selects the data provider with a high trust value, the data provider sends the complete data, the requester decrypts the data, recalculates the hash and compares it with the record on the chain. If they are consistent, it is determined that the data is valid, otherwise the exception handling mechanism is triggered;

[0035]

[0036] Among them, is the data requester; is the blockchain ledger; is the index parsing operation; is the data provider; For complete data content; is the verification function; The hash value recalculated by the requester for the received data; It is the hash value of the original data stored on the blockchain.

[0037] The exception handling mechanism is to trigger a hierarchical response strategy when the hash comparison is inconsistent, including:

[0038] Primary response phase: The requester initiates a data retransmission request through the roadside unit, requiring the original provider to resend the complete data packet and perform a secondary hash verification. At the same time, the data is marked as pending verification in the local block cache and participation in the decision-making process is suspended.

[0039] Intermediate trust adjustment: The smart contract performs dynamic trust assessment based on the level of abnormal events. It implements a preliminary trust downgrade and triggers an alarm notification for nodes that fail initial verification. It also initiates a hierarchical permission restriction mechanism for nodes that continuously experience verification anomalies.

[0040] Advanced disposal measures: For persistently abnormal nodes, the trust assessment system will perform a trust value reset operation, add the persistently abnormal nodes to the isolation list and broadcast a security notice. The data requester will automatically switch to the backup node with the highest trust assessment level to establish a communication channel.

[0041] In conjunction with the first aspect, in certain implementations of the first aspect, the method further includes: automatically increasing or decreasing the trust value of the data shared based on the provider's data quality and response speed and the requester's usage feedback through a smart contract, all of which are verified and recorded through a blockchain consensus mechanism; after the data sharing is completed, the dynamic behavior graph is further updated, and the sharing process is added to the blockchain as a transaction generation block, thereby forming a closed-loop, auditable sharing ecosystem;

[0042]

[0043] in, For smart contracts; for data quality; For response speed; For feedback; is the trust value; For blockchain ledger; To store transactions; For shared raw data; Update records for trust values; For digital signature.

[0044] In a second aspect, in order to achieve the above-mentioned objectives, the present invention discloses a vehicle network data sharing system based on dynamic behavior graphs and blockchain, comprising:

[0045] A data processing module, configured to obtain vehicle driving-related data, preprocess the vehicle driving-related data, encrypt the processed vehicle driving-related data using an asymmetric key, and upload the encrypted vehicle driving-related data to an RSU. The vehicle driving-related data includes vehicle position, road conditions, and vehicle speed.

[0046] A data verification module, configured to generate a dynamic behavior graph with the vehicle and the RSU as nodes and the interaction relationship between the vehicle and the RSU as edges based on the encrypted vehicle driving-related data, query a data hash value based on the dynamic behavior graph, and decrypt the encrypted vehicle driving-related data.

[0047] A data sharing module, configured to determine whether the decrypted vehicle driving-related data is valid based on the data hash value. If it is invalid, an exception handling mechanism is triggered; otherwise, it indicates that the data is available, thereby realizing data sharing.

[0048] In another aspect of the present invention, to achieve the above object, a terminal device is disclosed, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. The memory stores a computer program capable of running on the processor. When the processor loads and executes the computer program, the vehicle networking data sharing method based on a dynamic behavior graph and a blockchain as described above is adopted.

[0049] Advantages of the present invention:

[0050] Based on the time series modeling technology of the dynamic behavior graph, the present invention synchronously quantifies the local interaction credibility and global network influence of nodes by integrating multi-dimensional data of vehicle trajectories, communication frequencies, and abnormal event sequences, solves the problem of single trust evaluation dimension in traditional methods, and significantly improves the recognition accuracy of camouflage attacks and latent malicious nodes; the Trust-Weighted Hybrid Byzantine Fault Tolerance algorithm (TWH-BFT) limits the core consensus process to a group of highly trusted nodes through a hierarchical consensus architecture and a trust-weighted voting mechanism, and only requires a small number of highly trusted nodes to complete the core consensus, avoiding the multi-round broadcast across the network of PBFT, and reducing the communication overhead compared with the traditional PBFT algorithm. Through the efficient coordination of the multi-dimensional trust evaluation of the dynamic behavior graph and the TWH-BFT consensus mechanism, the present invention significantly reduces the system communication and computing overhead while ensuring the security of vehicle networking data sharing, realizes the global optimization of "security - efficiency - scalability" in complex dynamic scenarios, and provides high-reliability and low-latency collaborative decision-making support for autonomous driving and intelligent transportation systems. Description of the Drawings

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the accompanying drawings required in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings;

[0052] Figure 1 is a schematic diagram of the method flow of the present invention;

[0053] Figure 2 is a schematic diagram of the model structure of the present invention;

[0054] Figure 3 is a schematic diagram of the data sharing process of the present invention;

[0055] Figure 4 is a schematic diagram of the system structure of the present invention. Detailed implementation manners

[0056] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts belong to the scope of protection of the present invention.

[0057] Embodiment 1:

[0058] As Figure 1 shown, a vehicle networking data sharing method based on a dynamic behavior map and a blockchain, the method includes the following steps:

[0059] S101: Obtain vehicle driving-related data, preprocess the vehicle driving-related data, encrypt the processed vehicle driving-related data using an asymmetric key, and upload the encrypted vehicle driving-related data to the RSU, where the vehicle driving-related data includes vehicle location, road conditions, and vehicle speed;

[0060] The process of encrypting the processed vehicle driving-related data using an asymmetric key and uploading the encrypted vehicle driving-related data to the RSU:

[0061]

[0062] In the formula, is the th vehicle; is the th road test unit; represents encrypting the data using the public key of the road test unit ; is the vehicle driving related data to be transmitted; For using the vehicle private key to perform digital signature; is the th pseudo-identifier of the vehicle; is the vehicle location information; is the vehicle real-time status information; is the timestamp generated by the data; is other extended data fields.

[0063] After receiving the encrypted vehicle driving related data, the RSU verifies the legality and consistency of the vehicle driving related data, detects abnormal behaviors, updates the malicious counter of the vehicle, and submits the vehicle driving related data to the graph to trigger graph update:

[0064]

[0065] In the formula, is the malicious behavior counter of the vehicle; is the dynamic behavior graph; represents the graph update function; is a node in the dynamic behavior graph, is an edge in the dynamic behavior graph.

[0066] Data collection and upload are specifically as follows: We divide data collection into the following levels, as shown in Table 1:

[0067] Table 1 Data Collection

[0068]

[0069] S102: Based on the encrypted vehicle driving related data, generate a dynamic behavior graph with the vehicle and the RSU as nodes and the interaction relationship between the vehicle and the RSU as edges, query the data hash value based on the dynamic behavior graph, and decrypt the encrypted vehicle driving related data;

[0070] The generation process of the dynamic behavior graph:

[0071] Generate a dynamic behavior graph with the vehicle and the RSU as nodes and the interaction relationship as edges and assign corresponding attributes. The update mechanism of the graph includes two parts: direct data real-time update, and the original data uploaded by the vehicle (such as location, speed) is synchronized to the graph in real-time according to the timestamp; trust value dynamic adjustment, which is divided into periodic maintenance and real-time event-driven, every Fixed updates, real-time event-driven. When interactions occur between vehicles and RSU or other vehicles, abnormal behaviors are detected by RSU, or events for malicious behavior detection in the dynamic behavior graph occur, the attributes of nodes and edges in the dynamic behavior graph are dynamically adjusted, triggering a re-evaluation of trust values;

[0072]

[0073]

[0074] Wherein, is the dynamic behavior graph; is the set of nodes in the graph; is the set of edges; is the set of attributes of nodes and edges; is the periodic update; is the event-driven update; is the interaction event between vehicles and other entities; is the abnormal behavior detection event.

[0075] The dynamic behavior graph regularly clears nodes and edges that have been inactive for a long time, recalculates the behavior feature vectors, and uploads data submission and trust value updates to the dynamic behavior graph blockchain in the form of transactions:

[0076]

[0077] Wherein, is the dynamic behavior graph; is the graph cleaning function; is the set of nodes and edges that have been inactive for a long time; is the blockchain ledger; is the matrix-form transaction; is the updated node trust value; is the data submission timestamp.

[0078] Construction of the dynamic behavior graph. The graph G=(V,E) consists of the node set V, the edge set E, and their related attributes. Vehicle nodes and roadside units in the vehicle networking environment together constitute the nodes in the graph, and their attributes include static identifiers and dynamic behavior characteristics. The relevant attributes of the nodes are shown in Table 2:

[0079] Table 2 Node Attributes

[0080]

[0081] Edges represent the interaction relationships between nodes (such as vehicle-vehicle, vehicle-RSU), and their attributes include interaction quality and time series information. Specifically, it is shown in Table 3:

[0082] Table 3 Edge Attributes

[0083]

[0084] The vehicle trust value is calculated using trust evaluation, and the trust evaluation uses the Timely Weighted Decay Trust Aggregation Algorithm TWDT-Trust. The trust value is synthesized by four dynamic modules: the direct interaction trust module, the indirect recommendation trust module, the time decay weighted module, and the dynamic correction and penalty module:

[0085]

[0086] Among them, is the trust value of the vehicle at time ; ; is the direct interaction trust; is the indirect recommendation trust; is the time decay interval, which is the time difference from the most recent interaction to the current time; is the environmental correction factor, where ; is the malicious penalty term, where ; is the weight coefficient; is the decay coefficient.

[0087] The direct interaction trust is calculated based on real-time behavior data:

[0088] , where ;

[0089] is the index function, and its specific calculation is shown in Table 4:

[0090] Table 4 Index Function

[0091]

[0092] Dynamic weight Adopts the objective weighting method based on information entropy to avoid subjective deviation:

[0093]

[0094] is the entropy value of the th item of the index, reflecting the data dispersion degree; the smaller the entropy value, the higher the index discrimination degree and the greater the weight.

[0095] The indirect recommendation trust is the weighted aggregation of neighbor node evaluations:

[0096]

[0097] Among them, the credibility weight Fusing historical interactions and behavioral similarity:

[0098]

[0099] Historical interaction similarity ( is the interaction quality score of node with the th neighbor), and the feature similarity uses the reciprocal of the Euclidean distance ( is the behavioral feature vector after dimensionality reduction), and Sigmoid normalization .

[0100] The decay function of the time decay weighted module combines exponential decay and a sliding window. Exponential decay makes the system sensitive to short-term behaviors, and the sliding window retains long-term reputation memory, aiming to balance the influence weights of recent behaviors and historical reputations, ensuring that the trust evaluation reflects both real-time changes and retains long-term behavioral characteristics.

[0101] In dynamic scenarios such as the Internet of Vehicles, node behaviors may change rapidly (such as malicious nodes disguising compliance in the short term). By adjusting the decay coefficient, the algorithm assigns higher weights to recent interaction data. The form of exponential decay is as follows:

[0102]

[0103] When the network topology changes drastically (such as vehicles moving rapidly on a highway), automatically increase to accelerate the decay of old data; adopt piecewise decay (in 5-minute windows) to reduce the resource consumption of frequent calculations. The reference frequency (such as 10 times / minute) is used to normalize the topological dynamics of different scenarios. If node A frequently provides highly authentic data within the last 5 minutes, its trust value will increase rapidly; conversely, if it suddenly sends false information, the trust value will drop significantly.

[0104] To prevent malicious nodes from "whitewashing" historical records through short-term compliance behaviors, the algorithm retains a 30-day historical trust value window, but uses exponential decay to reduce the impact of old data. For example, if a node has performed well in the past but has frequently violated regulations recently, its historical reputation will gradually become invalid over time. The historical trust value sequence is weighted by time decay as follows:

[0105]

[0106] Exponential decay ensures that the impact of old data decreases non-linearly, avoiding the monopoly of long-term data on trust evaluation.

[0107] For malicious behaviors, the dynamic correction and punishment module proposes a cascading punishment mechanism:

[0108]

[0109] The triggering conditions are shown in Table 5:

[0110] Table 5 Triggering Conditions

[0111]

[0112] Since the external environment (such as bad weather and complex road conditions) may affect data reliability. For example, when heavy rain causes the camera to misjudge the road conditions, the algorithm uses the environmental correction factor to reduce the negative impact of such data:

[0113]

[0114] The road condition complexity is quantified according to the congestion index, accident density, etc. (0 - 10 points, with 10 being extremely complex); the bad weather degree is quantified according to visibility, precipitation intensity, etc. (0 - 5 points, with 5 being extremely bad); the correction range , the positive correction improves the weight of trusted nodes, the negative correction suppresses abnormal data, and the upper and lower limits are taken when exceeding the range.

[0115] In addition, the weight adaptive mechanism dynamically adjusts the balance between direct trust and indirect trust. At the initial stage of node interaction (such as a newly added vehicle), indirect trust (neighbor recommendation) dominates; as the number of direct interactions increases, the algorithm gradually relies on its own observed data:

[0116]

[0117] is the number of direct interactions, is the number of indirect recommendations.

[0118] S103: Determine whether the decrypted vehicle driving-related data is valid based on the data hash value. If it is invalid, trigger the exception handling mechanism; otherwise, it means the data is available, thus realizing data sharing.

[0119] The process of querying the data hash value based on the dynamic behavior graph and decrypting the encrypted vehicle driving-related data:

[0120] Data request and sharing: Data retrieval and collection: The data requester sends a request. If the target data is a node or edge attribute, it directly queries the graph, queries the hash value of the data through the dynamic behavior graph blockchain, decrypts the data using the supplier's public key, and verifies the content integrity by comparing the data hash value (SHA-256) stored in the blockchain to ensure that the data has not been tampered with.

[0121]

[0122] Wherein, is the data requester; is the dynamic behavior map; is the query operation function; is the target pseudo-identifier; is the data hash value generated using the SHA-256 algorithm; is the verification function; is to decrypt the data using the supplier's public key; is the hash value recalculated after data decryption; is the original data hash value stored on the blockchain.

[0123] If it is other data or the number of trusted nodes is insufficient, the system will trigger the data collection process. The data requester broadcasts the data requirements through the RSU. The data provider sends the data index Index to the RSU. The data index contains metadata and its hash. The RSU collects the responding Index, checks the trust value of the sender, and if the trust value is higher than the threshold Tthreshold, it is added to the data sharing blockchain, otherwise it is ignored.

[0124]

[0125] Wherein, is the data requester; is the data requirement description; is the data provider; is the data index; is the metadata; is the hash value of the data.

[0126] The data requester retrieves the latest block through the blockchain browser or the local light node, and parses the index information of the target data. If the current block does not contain the required data, it can query back along the blockchain history until a matching record is found. The data requester can view the trust value of the data provider through the map and select a data provider with a higher trust value. The provider sends the complete data to it. The requester decrypts the data, recalculates the hash again and compares it with the record on the chain. If they are consistent, the data is determined to be valid, otherwise the exception handling mechanism is triggered.

[0127]

[0128] Among them, is the data requester; is the blockchain ledger; is the index parsing operation; is the data provider; is the complete data content; is the verification function; The hash value recalculated by the requester for the received data; It is the hash value of the original data stored on the blockchain.

[0129] The exception handling mechanism is to trigger a hierarchical response strategy when the hash comparison is inconsistent:

[0130] (1) Primary response phase: The requester initiates a data retransmission request through the roadside unit, requiring the original provider to resend the complete data packet and perform a secondary hash verification. At the same time, the data is marked as pending verification in the local block cache, suspending its participation in the decision-making process.

[0131] (2) Intermediate trust adjustment: The smart contract performs dynamic trust evaluation based on the level of abnormal events, implements a preliminary trust downgrade and triggers an alarm notification for nodes that fail the first verification, and activates a hierarchical permission restriction mechanism for nodes that have continuous verification anomalies;

[0132] (3) Advanced disposal measures: For persistently abnormal nodes, the trust assessment system will perform a trust value reset operation, include the node in the network-wide isolation list, and broadcast a security notice. The data requester will automatically switch to the backup node with the highest trust assessment level to establish a communication channel.

[0133] Punishment and incentives: After the entire sharing process is completed, the system automatically increases or decreases the trust value through smart contracts based on the provider's data quality, response speed, and the requester's usage feedback. All related operations are verified and recorded through the blockchain consensus mechanism. After the sharing is completed, the map is further updated, and the sharing process is added to the blockchain as a transaction generation block, forming a closed-loop and auditable sharing ecosystem.

[0134]

[0135] in, For smart contracts; for data quality; For response speed; For feedback; is the trust value; For blockchain ledger; To store transactions; For shared original data; Update records for trust values; For digital signature.

[0136] Specifically, the solution of the present invention will be further elaborated through embodiments below: The blockchain consensus mechanism adopts the Trust-Weighted Hybrid Byzantine Fault Tolerance (TWH-BFT) consensus algorithm. The specific process is as follows:

[0137] The specific process of the pre-confirmation includes:

[0138] Pre-Commit: Quickly reach a preliminary consensus through highly trusted nodes to reduce communication overhead.

[0139] Step1 (Leader election): Randomly select a Leader from the committee composed of highly trusted nodes through the VRF algorithm. is the set of RSUs in the vehicle network , and a Leader is randomly selected through VRF from the pre-confirmation committee composed of the set of highly trusted nodes in each round :

[0140]

[0141] Among them, is the private key of the th node, is the unique identifier of the current block (such as block hash), is the Verifiable Random Function, which can generate a pseudo-random number and its verifiable proof based on and . Generate a proposal (including a transaction list, timestamp, and previous block hash), and broadcast to the committee.

[0142] Step2 (Trust-weighted voting): After verifying the validity of the proposal, committee members send votes with VRF proofs to the aggregator according to their trust value weights. Each committee node verifies the validity of the proposal and calculates its voting weight . Node sends a vote to the aggregator .

[0143] Step3 (Aggregate signature and pre-confirmation): When the aggregator calculates that the total weight is greater than or equal to the threshold, it generates a TSS aggregate signature and broadcasts a pre-confirmation message across the network. The aggregator collects votes and calculates the total trust weight . If , generate aggregate signature , broadcast pre-confirmation message .

[0144] The specific process of the final confirmation includes:

[0145] Finalization: Ensure data finality through an asynchronous challenge mechanism to prevent malicious proposals.

[0146] Step 1 (Pre-confirmation broadcast): The pre-confirmation message triggers a 30-second countdown and starts the final confirmation process. Broadcast to the entire network, triggering the final confirmation countdown (e.g. 30 seconds).

[0147] Step 2 (Asynchronous Challenge Window): Allow non-committee nodes to submit zero-knowledge proof challenge invalid data, which must be accompanied by witness evidence. Any node Challenges can be submitted , a zero-knowledge proof is required Prove data invalidity:

[0148]

[0149] Challenger Broadcast .

[0150] Step 3 (Challenge Processing): After the committee verifies the validity of the challenge, it rolls back the block and punishes the Leader. If there is no challenge within the time limit, the transaction is written into the ledger to complete the final confirmation. verify If the verification is successful, roll back the block , confiscate the Leader's trust value , and trigger a new round of consensus; if there is no valid challenge within the time limit, confirm This is the final block, written into the ledger.

[0151] Trust value update: Dynamically adjust trust value based on node behavior

[0152] For nodes that successfully upload valid data or participate in voting, ; For issuing invalid challenges or forging data, ; For long-term inactive nodes, The trust value update formula is as follows:

[0153]

[0154] in, Dynamically adjusted through on-chain governance.

[0155] like Figure 2As shown in the figure, in the data sharing system for the Internet of Vehicles, vehicles serve as the core terminals in the network, acting as both data requesters and suppliers. Each vehicle collects traffic data such as location information and road conditions in real time through on-vehicle sensors, performs preprocessing and encryption operations locally, and then uploads the trusted data to the neighboring Road Side Unit (RSU). Vehicles can actively initiate data requests, verify the integrity of the acquired data through the blockchain, and rely on the graph to screen high-trust-value nodes to obtain the target data. In addition, the behavior of vehicles when responding to others' requests is also fed back into their trust value system, directly affecting their subsequent participation and benefits, thus forming a "contribution-benefit" closed-loop mechanism.

[0156] As the core edge computing node, the RSU is responsible for receiving the encrypted data uploaded by vehicles and performing data verification operations. When the verification passes, the RSU writes the data into the shared blockchain and broadcasts the sharing request; if the verification fails, the relevant data is directly discarded. The RSU also needs to detect abnormal patterns in the data, such as conflict information or malicious node behavior, and trigger the update mechanism of the behavior graph accordingly to ensure the robustness and security of the system operation.

[0157] The dynamic behavior graph is the central module that supports the intelligent decision-making of the system. By modeling the interaction process between vehicles and RSUs, it quantitatively analyzes the node trust value and the reliability of the edges. The graph dynamically updates the node attributes (such as ID, type, trust value, behavior vector, etc.) and edge attributes (such as ID, source node, destination node, etc.) based on real-time interaction data (such as the interaction between vehicle V1 and vehicle V2), and adjusts the node trust value under the trigger of periodic or specific events (such as malicious behavior), while clearing the invalid nodes to maintain the timeliness of the model. The system constructs and dynamically updates the behavior graph (DBG), evolving the previous moment's DBG(t - 1) into the current moment's DBG(t) to depict the trust relationship and behavior trajectory between nodes.

[0158] As the underlying cornerstone of the system's trusted mechanism, the blockchain is divided into two types: the dynamic behavior graph blockchain and the data sharing blockchain. The former is used to record the change process of the graph evolving over time, and the latter is responsible for storing the verified encrypted data hash values and sharing index information. Each block contains the block hash, the previous block hash, a nonce, a timestamp, the Merkle root hash value, and multiple transaction records (Tx), ensuring the integrity and traceability of the data.

[0159] As Figure 3 shown, the data sharing process is divided into four parts: data collection and upload, dynamic behavior graph and trust evaluation, dynamic behavior graph and trust evaluation, punishment and incentive:

[0160] 1. Data collection and upload

[0161] ① Collect and encrypt data in real time through sensors: On-vehicle sensors (GPS, cameras, radars) collect raw data and encrypt it using an asymmetric encryption algorithm;

[0162] ② Upload data to the Road Side Unit (RSU): The encrypted data is uploaded to the RSU through the on-vehicle communication module;

[0163] ③ The RSU verifies the data: The RSU verifies the data format, signature legality, and hash consistency;

[0164] ④ Upload data to the Behavior Dynamics Graph (BDG): After passing the verification, the data is uploaded to the BDG for subsequent sharing, otherwise it is discarded.

[0165] 2. Behavior Dynamics Graph and Trust Evaluation

[0166] ① Interaction between nodes: Record the communication logs between vehicles and RSUs or other vehicles;

[0167] ② Changes in the node topology: Changes occur in the edges between nodes;

[0168] ③ Graph update: Changes in the node topology trigger changes in the nodes, edges, and their corresponding attributes of the Behavior Dynamics Graph;

[0169] ④ Trust value calculation: Calculate comprehensively by combining direct interaction trust, indirect recommendation trust, time decay weighting module, dynamic correction and penalty module;

[0170] ⑤ Node cleaning: Regularly remove nodes that have been inactive for a long time or have low trust values;

[0171] ⑥ Join the blockchain: The graph update records are written into the blockchain in the form of transactions.

[0172] 3. Data Request and Sharing

[0173] ① The data requester sends a request;

[0174] ② Obtain the target data from the Behavior Dynamics Graph;

[0175] ③ If the target data is not found or the node trust value is insufficient, the RSU initiates a data solicitation broadcast request;

[0176] ④ The data provider submits a data index: including metadata and hash values;

[0177] ⑤ Execute the TWH-BFT consensus;

[0178] ⑥ Generate a block: Package the data as a transaction and generate a new block;

[0179] ⑦ Add the block to the blockchain;

[0180] ⑧ Retrieval block, select required data: The requester retrieves and downloads data through a blockchain browser;

[0181] ⑨ Select providers with higher trust values: Prioritize nodes with high trust values;

[0182] ⑩ Share data: The data provider sends the complete data to the requester, and the requester receives it after verification.

[0183] 4. Penalties and incentives

[0184] ① The smart contract executes to adjust the trust value: Automatically increase or decrease the trust value according to data quality, response speed, and user feedback;

[0185] ② Update the dynamic behavior graph: Real-time synchronize the change of the trust value to the graph;

[0186] ③ Blockchain consensus: Verify and record: All operations are verified through the consensus mechanism to ensure the process is transparent and tamper-proof.

[0187] Embodiment 2: Second aspect, as Figure 4 shown, to achieve the above object, the present invention discloses a vehicle networking data sharing system based on a dynamic behavior graph and a blockchain, including:

[0188] A data processing module 11, configured to obtain vehicle driving-related data, preprocess the vehicle driving-related data, encrypt the processed vehicle driving-related data using an asymmetric key, and upload the encrypted vehicle driving-related data to the RSU, where the vehicle driving-related data includes vehicle position, road conditions, and vehicle speed;

[0189] A data verification module 12, configured to generate a dynamic behavior graph with the vehicle and the RSU as nodes and the interaction relationship between the vehicle and the RSU as edges based on the encrypted vehicle driving-related data, query the data hash value based on the dynamic behavior graph, and decrypt the encrypted vehicle driving-related data;

[0190] A data sharing module 13, configured to determine whether the decrypted vehicle driving-related data is valid based on the data hash value. If it is invalid, trigger an exception handling mechanism. Otherwise, it means the data is available, thereby realizing data sharing.

[0191] Based on the same inventive concept, the present invention further provides a computer device, which includes: one or more processors, and a memory for storing one or more computer programs; the program includes program instructions, and the processor is configured to execute the program instructions stored in the memory. The processor may be a Central Processing Unit (CPU), or may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing core and control core of the terminal, and is used to implement one or more instructions. Specifically, it is used to load and execute one or more instructions in the computer storage medium to implement the above method.

[0192] It should be further noted that, based on the same inventive concept, the present invention further provides a computer storage medium, on which a computer program is stored, and the computer program, when run by a processor, executes the above method. The storage medium may be any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may, for example, but not be limited to, an electrical, magnetic, optical, electro-magnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the computer-readable storage medium include: an electrical connection having one or more wires, a portable computer disk, a hard disk, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM or flash memory), an optical fiber, a portable compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program may be used by or combined with an instruction execution system, apparatus, or device.

[0193] In the description of this specification, the description with reference to the terms "one embodiment", "example", "specific example", etc. means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0194] The foregoing has shown and described the basic principles, main features and advantages of the present disclosure. Those skilled in the art should understand that the present disclosure is not limited by the above embodiments, and what is described in the above embodiments and the specification is only to illustrate the principles of the present disclosure. Without departing from the spirit and scope of the present disclosure, the present disclosure will have various changes and improvements, and these changes and improvements fall within the scope of the present disclosure claimed.

Claims

1. A method for sharing vehicle networking data based on a dynamic behavior graph and blockchain, characterized in that The method includes the following steps: Obtain vehicle driving-related data, preprocess the vehicle driving-related data, encrypt the processed vehicle driving-related data using an asymmetric key, and upload the encrypted vehicle driving-related data to the RSU. Among them, the vehicle driving-related data includes vehicle position, road conditions, and vehicle speed; Based on the encrypted vehicle driving-related data, generate a dynamic behavior graph with the vehicle and the RSU as nodes and the interaction relationship between the vehicle and the RSU as edges. Query the data hash value based on the dynamic behavior graph, and decrypt the encrypted vehicle driving-related data; The generation process of the dynamic behavior graph: Taking the vehicle and RSU as nodes and the interaction relationship as edges, a dynamic behavior graph is generated and corresponding attributes are assigned. The update mechanism of the graph consists of two parts: direct data real-time update: the original data uploaded by the vehicle is synchronously updated to the graph in real-time according to the timestamp; trust value dynamic adjustment: it is divided into periodic maintenance and real-time event-driven. Every fixed update, real-time event-driven includes when the vehicle interacts with the RSU or other vehicles, the RSU detects abnormal behavior, and an event of malicious behavior detection in the dynamic behavior graph occurs, the attributes of the nodes and edges in the dynamic behavior graph are dynamically adjusted, triggering a re-evaluation of the trust value; Wherein, is a dynamic behavior atlas; is the set of nodes in the atlas; is the edge set; is the set of attributes of nodes and edges; is a periodic update; is an event-driven update; is an interaction event between the vehicle and other entities; is an abnormal behavior detection event; The dynamic behavior graph periodically clears long-unactive nodes and edges, recalculates the behavior feature vectors, and uploads data submission and trust value updates to the dynamic behavior graph blockchain in the form of transactions: Wherein, is a dynamic behavior map; is a map cleaning function; is a set of nodes and edges that have been inactive for a long time; is a blockchain ledger; is a matrix-form transaction; is the updated node trust value; is the data submission timestamp; The vehicle trust value is calculated using trust assessment. The trust assessment uses the time-series weighted decay trust aggregation algorithm TWDT-Trust, and the trust value is synthesized by four dynamic modules: the direct interaction trust module, the indirect recommendation trust module, the time decay weighted module, and the dynamic correction and penalty module; Wherein, is the trust value of the vehicle at time ; ; is the direct interaction trust; is the indirect recommendation trust; is the time decay interval, which is the time difference from the most recent interaction to the current time; is the environmental correction factor, wherein ; is the malicious penalty term, wherein ; is the weight coefficient; is the decay coefficient; Determine whether the decrypted vehicle driving-related data is valid based on the data hash value. If it is invalid, trigger the exception handling mechanism. Otherwise, it means the data is available, thus realizing data sharing.

2. The method for sharing vehicle networking data based on a dynamic behavior map and a blockchain according to claim 1, wherein The process of encrypting the processed vehicle driving-related data using an asymmetric key and uploading the encrypted vehicle driving-related data to the RSU: Wherein, is the th vehicle; is the th road test unit; represents encrypting data with the public key of the road test unit ; is the vehicle driving related data to be transmitted; is to use the private key of the vehicle to perform digital signature; is the th pseudo-identifier of the vehicle; is the vehicle location information; is the vehicle real-time status information; is the timestamp generated by the data; is other extended data fields.

3. The method for sharing vehicle networking data based on a dynamic behavior map and a blockchain according to claim 2, wherein After receiving the encrypted vehicle driving-related data, the RSU verifies the legality and consistency of the vehicle driving-related data, detects abnormal behaviors, updates the vehicle's malicious counter, and submits the vehicle driving-related data to the graph to trigger graph updates: Wherein, is the malicious behavior counter of the vehicle ; is the dynamic behavior graph; represents the graph update function; is a node in the dynamic behavior graph, and is an edge in the dynamic behavior graph.

4. The method for sharing vehicle networking data based on a dynamic behavior map and a blockchain according to claim 1, wherein The process of querying the data hash value based on the dynamic behavior graph and decrypting the encrypted vehicle driving-related data: The data requester sends a request. If the target data is a node or edge attribute, directly query it from the dynamic behavior graph, query the hash value of the data through the dynamic behavior graph blockchain, decrypt the data using the supplier's public key, and verify the content integrity by comparing the data hash value SHA-256 stored in the blockchain; Wherein, is the data requester; is the dynamic behavior graph; is the query operation function; is the target pseudo-identifier; is the data hash value generated using the SHA-256 algorithm; is the verification function; is the data decrypted using the supplier's public key; is the hash value recalculated after data decryption; is the original data hash value stored on the blockchain; If it is other data or the number of data trusted nodes is insufficient, trigger the data solicitation process. The data requester broadcasts the data requirements through the RSU. The data provider sends the data index Index to the RSU. The data index contains metadata and its hash value. The RSU collects the responding Indexes, checks the trust value of the sender. If the trust value is higher than the threshold Tthreshold, add it to the data sharing blockchain. Otherwise, ignore it: Wherein, is the data requester; is the data requirement description; is the data provider; is the data index; is the metadata; is the hash value of the data.

5. The method for sharing vehicle networking data based on a dynamic behavior map and a blockchain according to claim 1, wherein The process of determining whether the decrypted vehicle driving-related data is valid based on the data hash value: The data requester retrieves the latest block through a blockchain browser or local light node and parses the index information of the target data. If the current block does not contain the required data, it can backtrack along the blockchain history until a matching record is found. The data requester checks the trust value of the data provider through the dynamic behavior graph and selects the data provider with a high trust value. The data provider sends the complete data, and the requester decrypts the data, calculates the hash again and compares it with the on-chain record. If they match, the data is considered valid, otherwise the exception handling mechanism is triggered. Among them, is the data requester; is the blockchain ledger; is the parsing index operation; is the data provider; is the complete data content; is the verification function; is the hash value recalculated by the requester for the received data; is the original data hash value stored on the blockchain; The exception handling mechanism is to trigger a hierarchical response strategy when the hash comparison is inconsistent, including: Primary response phase: The requester initiates a data retransmission request through the roadside unit, requiring the original provider to resend the complete data packet and perform a secondary hash verification. At the same time, the data is marked as pending verification in the local block cache and participation in the decision-making process is suspended. Intermediate trust adjustment: The smart contract performs dynamic trust assessment based on the level of abnormal events. It implements a preliminary trust downgrade and triggers an alarm notification for nodes that fail initial verification. It also initiates a hierarchical permission restriction mechanism for nodes that continuously experience verification anomalies. Advanced disposal measures: For persistently abnormal nodes, the trust assessment system will perform a trust value reset operation, add the persistently abnormal nodes to the isolation list and broadcast a security notice. The data requester will automatically switch to the backup node with the highest trust assessment level to establish a communication channel.

6. The method for sharing vehicle networking data based on a dynamic behavior map and a blockchain according to claim 1, wherein, The data sharing is based on the provider's data quality, response speed and the requester's feedback. The trust value is automatically increased or decreased through smart contracts. All of this is verified and recorded through the blockchain consensus mechanism. After the data sharing is completed, the dynamic behavior map is further updated, and the sharing process is added to the blockchain as a transaction generation block, forming a closed-loop auditable sharing ecosystem. Among them, is a smart contract; is data quality; is response speed; is feedback; is trust value; is a blockchain ledger; is a storage transaction; is shared raw data; is a trust value update record; is a digital signature.

7. The vehicle networking data sharing system based on the dynamic behavior graph and blockchain adopts the vehicle networking data sharing method based on the dynamic behavior graph and blockchain according to any one of claims 1 to 6, and is characterized in that, include: A data processing module is used to obtain vehicle driving related data, pre-process the vehicle driving related data, encrypt the processed vehicle driving related data using an asymmetric key, and upload the encrypted vehicle driving related data to the RSU, wherein the vehicle driving related data includes vehicle location, road conditions, and vehicle speed; The data verification module is used to generate a dynamic behavior graph based on the encrypted vehicle driving data, with the vehicle and RSU as nodes and the interaction relationship between the vehicle and RSU as edges, query the data hash value based on the dynamic behavior graph, and decrypt the encrypted vehicle driving data; The data sharing module is used to determine whether the decrypted vehicle driving-related data is valid based on the data hash value. If it is invalid, the exception handling mechanism is triggered. Otherwise, it indicates that the data is available, thereby realizing data sharing.

8. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, The memory stores a computer program that can be run on a processor. When the processor loads and executes the computer program, the vehicle network data sharing method based on dynamic behavior graphs and blockchain as described in any one of claims 1 to 6 is adopted.

Images