Internet of vehicles information sharing method and vehicle

Abstract

The present disclosure provides a kind of Internet of Vehicles information sharing method and vehicle, it is related to intelligent network connection technical field, the method applied to first vehicle includes: multiple first vehicles and at least one second vehicle form peer-to-peer communication network, share data broadcasted by second vehicle is received using peer-to-peer communication network;Distributed consensus mechanism is used to jointly verify the distributed data with second vehicle;The share data that is verified is stored to the local distributed ledger of first vehicle.The method of the present disclosure, through the data broadcast and distributed verification of decentralization, eliminates the single point failure bottleneck of central server, at the same time, the share data that is verified is stored in the local distributed ledger of each vehicle, realizes anti single point failure, reduces communication delay, and prevents data privacy centralized leakage.

Description

Technical Field

[0001] This disclosure relates to the field of intelligent connected vehicle technology, specifically to a vehicle-to-everything (V2X) information sharing method and vehicle. Background Technology

[0002] In the field of vehicle-to-everything (V2X) technology, to achieve functions such as collaborative driving and intelligent traffic management, vehicles need to share critical information such as driving status and perception data in real time. Because this information is related to driving safety and traffic efficiency, relevant application scenarios generally require information sharing systems to have high reliability, low communication latency, and the ability to protect the privacy of users' sensitive data. Especially in high-density traffic scenarios or environments with limited network conditions, ensuring the continuous, timely, and reliable transmission of safety-related messages has become a clear and urgent technical requirement. Summary of the Invention

[0003] This disclosure aims to at least partially address one of the technical problems in the related art. To this end, embodiments of this disclosure strive to provide a method and vehicle for sharing information in a vehicle-to-everything (V2X) network, thereby solving the problems in the prior art where all vehicle data relies on a central server for relay and centralized storage in a V2X information sharing environment, resulting in single points of failure, high communication latency, and easy leakage of user data privacy. To achieve the above objectives, a first aspect of this disclosure proposes a vehicle-to-everything (V2X) information sharing method, applied to a first vehicle, wherein multiple first vehicles and at least one second vehicle form a peer-to-peer communication network. The method includes: using the peer-to-peer communication network to receive shared data broadcast by the second vehicle; employing a distributed consensus mechanism to jointly perform distributed verification of the shared data with the second vehicle; and storing the verified shared data in the local distributed ledger of the first vehicle.

[0004] According to the vehicle-to-everything (V2X) information sharing method of this disclosure, applied to a first vehicle, multiple first vehicles and at least one second vehicle form a peer-to-peer communication network. The method includes: receiving shared data broadcast by the second vehicle using the peer-to-peer communication network; jointly verifying the shared data with the second vehicle using a distributed consensus mechanism; and storing the verified shared data in the local distributed ledger of each first vehicle. Thus, this method fundamentally eliminates the bottleneck of single point of failure of the central server by directly broadcasting shared data in the peer-to-peer communication network and using a distributed consensus mechanism to replace the relay and centralized decision-making of the central server. Simultaneously, storing the verified shared data in the local distributed ledger of each vehicle avoids the aggregation of sensitive information at the central server, thereby achieving the effects of resisting single point of failure, reducing communication latency, and preventing centralized leakage of data privacy.

[0005] In some embodiments of this disclosure, a distributed consensus mechanism is employed to jointly perform distributed verification of shared data with a second vehicle, including: during the consensus period, determining at least a portion of the vehicles forming the peer-to-peer communication network as consensus committee members based on at least one of the location information of the first vehicle, the movement status information of the first vehicle, and the reputation parameter information of the second vehicle, wherein the reputation parameter information is determined based on the behavioral data of the second vehicle participating in historical consensus; forming a consensus committee group with the consensus committee members to jointly perform distributed verification of the shared data.

[0006] In some embodiments of this disclosure, the consensus committee group includes a master node and member nodes, with the first vehicle being either a master node or one of the member nodes. The consensus committee group, composed of the first vehicle and its members, performs distributed verification of shared data. This includes: if the first vehicle is a master node, packaging the shared data into blocks and broadcasting consensus proposal messages to member nodes based on the blocks; if the first vehicle is a member node, receiving the consensus proposal messages broadcast by the master node, verifying the blocks based on the consensus proposal messages, and broadcasting member confirmation messages to other nodes after successful verification; and generating distributed verification confirmation messages when the first vehicle receives a preset number of member confirmation messages. These distributed verification confirmation messages instruct the submission of the blocks to the local distributed ledger.

[0007] In some embodiments of this disclosure, storing verified shared data in the local distributed ledger of a first vehicle includes: adding a block to the local distributed ledger of the first vehicle in response to a distributed verification confirmation message.

[0008] In some embodiments of this disclosure, before using a distributed consensus mechanism to jointly perform distributed verification of the shared data with a second vehicle, the method further includes: determining the priority of the shared data based on the event type corresponding to the shared data, wherein the priority includes at least one of the following: a first priority directly related to driving safety, a second priority related to assisted driving, and a third priority related to traffic efficiency; placing the shared data into a cache queue corresponding to the priority of the shared data; and filtering the shared data in the cache queue based on at least one of the time attribute, spatial distance attribute, and source reputation attribute of the shared data.

[0009] In some embodiments of this disclosure, the shared data is filtered based on at least one of the time attribute, spatial distance attribute, and source reputation attribute of the shared data, including: determining a comprehensive data value score based on at least one of the time attribute, spatial distance attribute, and source reputation attribute; and filtering the shared data based on the comprehensive data value score and a target score threshold.

[0010] In some embodiments of this disclosure, a first vehicle forms a peer-to-peer communication network with multiple second vehicles through various heterogeneous communication interfaces, including a primary communication interface and a backup communication interface. Utilizing the peer-to-peer communication network to receive shared data broadcast by the second vehicles includes: monitoring the data transmission status of the primary communication interface; if the data transmission status does not meet the target data transmission conditions, establishing a backup communication interface to connect with the second vehicles while maintaining the primary communication interface connection; and using the backup communication interface to receive the shared data broadcast by the second vehicles.

[0011] The second objective of this disclosure is to propose a vehicle-to-everything (V2X) information sharing method for a second vehicle. By performing privacy protection processing on sensitive fields, the second vehicle can still prove the credibility of the shared data it broadcasts to the first vehicle without disclosing its own driving trajectory and identity details, thus achieving an effective balance between the availability of shared data and the protection of user privacy.

[0012] To achieve the above objectives, a second aspect of this disclosure proposes a vehicle-to-everything (V2X) information sharing method, applied to a second vehicle, which forms a peer-to-peer communication network with at least one first vehicle. The method includes: performing privacy protection processing on sensitive fields in shared data stored in the second vehicle to generate proof data, wherein the proof data is data that the vehicles forming the peer-to-peer communication network can verify the authenticity of the sensitive fields without exposing the specific content of the sensitive fields; broadcasting the shared data and proof data to the first vehicle using the peer-to-peer communication network, so that the first vehicle can use a distributed consensus mechanism to jointly perform distributed verification of the shared data with the second vehicle, and storing the verified shared data in the first vehicle's local distributed ledger.

[0013] The vehicle-to-everything (V2X) information sharing method according to embodiments of this disclosure is applied to a second vehicle, which forms a peer-to-peer communication network with at least one first vehicle. The method includes: performing privacy protection processing on sensitive fields in shared data stored in the second vehicle to generate proof data, wherein the proof data is data that allows vehicles forming the peer-to-peer communication network to verify the authenticity of the sensitive fields without exposing their specific content; broadcasting the shared data and proof data to the first vehicle via the peer-to-peer communication network, so that the first vehicle and the second vehicle can jointly perform distributed verification of the shared data using a distributed consensus mechanism, and storing the verified shared data in the first vehicle's local distributed ledger. Thus, by performing privacy protection processing on sensitive fields, the second vehicle can prove the credibility of the shared data it broadcasts to the first vehicle without disclosing its own driving trajectory and identity details, achieving an effective balance between the availability of shared data and the protection of user privacy.

[0014] In some embodiments of this disclosure, broadcasting shared data and proof data to a first vehicle using a peer-to-peer communication network includes: determining a broadcast interval for broadcasting the shared data and proof data to the first vehicle based on at least one of the second vehicle's driving speed, the second vehicle's driving direction, and the density of the first vehicle within a preset range of the second vehicle; and broadcasting the shared data and proof data to the first vehicle using the peer-to-peer communication network based on the broadcast interval.

[0015] The third objective of this disclosure is to propose a vehicle.

[0016] To achieve the above objectives, a third aspect of this disclosure provides a vehicle including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described vehicle network information sharing method.

[0017] According to the embodiments of this disclosure, by executing the above-described vehicle-to-everything (V2X) information sharing method, the vehicle can directly broadcast shared data in the peer-to-peer communication network and use a distributed consensus mechanism to replace the relay and centralized decision-making of the central server, thereby fundamentally eliminating the bottleneck of single point of failure of the central server. At the same time, the verified shared data is stored in the local distributed ledger of each vehicle, avoiding the aggregation of sensitive information in the central server, thereby achieving the effects of resisting single point of failure, reducing communication latency, and preventing centralized leakage of data privacy.

[0018] A third aspect of this disclosure provides a vehicle-to-everything (V2X) information sharing method and apparatus, applied to a first vehicle, wherein multiple first vehicles and at least one second vehicle form a peer-to-peer communication network, comprising: a receiving module for receiving shared data broadcast by the second vehicle using the peer-to-peer communication network; a verification module for jointly verifying the shared data with the second vehicle using a distributed consensus mechanism; and a storage module for storing the verified shared data in the local distributed ledger of the first vehicle.

[0019] A fourth aspect of this disclosure provides a vehicle-to-everything (V2X) information sharing device applied to a second vehicle, which forms a peer-to-peer communication network with at least one first vehicle. The device includes: a processing module for performing privacy protection processing on sensitive fields in shared data stored in the second vehicle, generating proof data, wherein the proof data is data that allows vehicles forming the peer-to-peer communication network to verify the authenticity of the sensitive fields without exposing their specific content; and a broadcasting module for broadcasting the shared data and proof data to the first vehicle via the peer-to-peer communication network, so that the first vehicle, using a distributed consensus mechanism, can jointly perform distributed verification of the shared data with the second vehicle, and store the verified shared data in the first vehicle's local distributed ledger.

[0020] Additional aspects and advantages of this disclosure will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0021] Figure 1 This is a flowchart of a vehicle network information sharing method according to some embodiments of this disclosure.

[0022] Figure 2 This is a flowchart illustrating a vehicle network information sharing method according to some embodiments of this disclosure.

[0023] Figure 3 This is a block diagram of a vehicle according to some embodiments of the present disclosure.

[0024] Figure 4 This disclosure presents a structural block diagram of some implemented vehicle-to-everything (V2X) information sharing devices.

[0025] Figure 5 This disclosure presents a structural block diagram of some embodiments of a vehicle-to-everything (V2X) information sharing device. Detailed Implementation

[0026] Embodiments of this disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0027] In the field of vehicle-to-everything (V2X) information sharing, to enable vehicles to acquire ambient perception data for collaborative driving, intelligent traffic management, and other functions, a centralized architecture is typically used to build a vehicle-to-everything (V2X) information sharing system. This involves deploying a central server in the cloud, where all vehicles upload data such as driving status and sensor perception results. The central server then processes this data centrally before distributing the decision-making or fused information to other vehicles. Data transmission and decision-making rely on the central server as an intermediary; vehicles do not directly exchange information. The central server's ability to uniformly manage data formats, execute complex fusion algorithms, and maintain global state consistency makes it widely used in these technologies.

[0028] However, in high-density, high-mobility traffic scenarios, this central server-based information sharing scheme exposes performance degradation issues. A fundamental contradiction lies in the fact that to maintain a unified view of global data, all data must be aggregated through a central server. As the number of vehicles increases and real-time requirements rise, the communication and computing load on the central server rises sharply, causing response latency to fail to converge to the millisecond range required for safe decision-making. Simultaneously, availability becomes overly dependent on the stable operation of the central server. Specifically, in emergency braking warning scenarios, if the vehicle in front transmits an emergency braking message to the vehicle behind through the central server, when vehicle density is high, server message queue congestion can cause forwarding delays of hundreds of milliseconds or even seconds, preventing the following vehicle from reacting in time. Furthermore, if the central server is attacked or the network is interrupted, the message transmission link is completely severed, paralyzing vehicle coordination functions throughout the entire area.

[0029] In-depth analysis revealed that the root cause of the aforementioned contradiction lies in the fact that the information sharing scheme based on a central server designs the data flow as a triangular path from vehicle to the central server and back to the vehicle. Each information sharing requires circling the central server in the cloud, not only lengthening the physical path but also creating a centralized bottleneck for computing and storage on the central server side. Simultaneously, the convergence of all vehicle perception data and location trajectories on the server side results in a highly concentrated risk of user privacy exposure; once the server is breached, it could lead to a large-scale data leak.

[0030] To address the aforementioned issues, this disclosure proposes a vehicle-to-everything (V2X) information sharing method. By directly broadcasting shared data in a peer-to-peer communication network and utilizing a distributed consensus mechanism to replace the relay and centralized decision-making of the central server, the bottleneck of single point of failure of the central server is fundamentally eliminated. At the same time, the verified shared data is stored in the local distributed ledger of each vehicle, avoiding the aggregation of sensitive information on the central server. This achieves the effects of resisting single point of failure, reducing communication latency, and preventing centralized leakage of data privacy.

[0031] The following description, with reference to the accompanying drawings, illustrates the vehicle-to-everything (V2X) information sharing method and vehicle proposed in embodiments of this disclosure.

[0032] Figure 1 This is a flowchart of a vehicle network information sharing method according to some embodiments of this disclosure.

[0033] like Figure 1 As shown, the vehicle network information sharing method of this disclosure is applied to a first vehicle, and multiple first vehicles and at least one second vehicle form a peer-to-peer communication network. The method may include the following steps.

[0034] Step S110: Receive shared data broadcast by the second vehicle using a peer-to-peer communication network.

[0035] Specifically, a peer-to-peer (P2P) communication network can characterize a network topology formed by multiple first vehicles and at least one second vehicle directly connecting and communicating with each other in a peer-to-peer manner. Data transmission in a peer-to-peer network does not require a central server for relay. For example, a peer-to-peer network may include, but is not limited to: a self-organizing network based on the 5G Vehicle-to-Everything (5G-V2X) direct communication protocol supported by fifth-generation mobile communication technology; a local area network based on the Dedicated Short Range Communications (DSRC) protocol; temporary point-to-point connections established through short-range communication methods such as Wi-Fi Direct or Bluetooth; or a combination of the above communication protocols. The size and topology of a peer-to-peer network can dynamically change with vehicle location and communication distance. In a peer-to-peer network, each first or second vehicle can simultaneously act as both a data sender and a data receiver. As the data sender, the second vehicle packages the sensor events collected by its own sensors, such as obstacle locations, emergency braking signals, and road slipperiness, into shared data and broadcasts it directly within the peer-to-peer communication network. As the data receiver, the first vehicle receives the shared data broadcast by the second vehicle.

[0036] In one implementation, a second vehicle acts as the sender, and a first vehicle as the receiver. Either vehicle can maintain a neighbor node table, which records the identifiers, communication addresses, signal strengths, geographical locations, and last communication times of surrounding vehicles. After receiving the shared data broadcast by the sender at the physical layer, the receiver first extracts the sender's geographical location information and compares it with its own current location. If the spatial distance between the sender and receiver exceeds a preset effective range, such as 300 meters, the shared data is considered an invalid broadcast and is discarded.

[0037] This location-based broadcast filtering effectively avoids consuming vehicle-side computing and storage resources due to processing a large number of irrelevant broadcasts in scenarios with high vehicle density. Furthermore, in some embodiments, the shared data may also include a monotonically increasing sequence number corresponding to the sender. By maintaining the latest sequence number received by each neighboring node, the receiver can identify and discard old messages arriving due to network retransmission or malicious replay, thereby preventing replay attacks.

[0038] Step S120: A distributed consensus mechanism is used to jointly verify the shared data with the second vehicle.

[0039] Specifically, a distributed consensus mechanism can be characterized as a technical means by which vehicles in a peer-to-peer communication network consisting of multiple first vehicles and at least one second vehicle reach a consensus on the state of shared data through multiple message exchanges and specific decision-making rules. In one implementation, the distributed consensus mechanism can be optimized based on a practical Byzantine fault-tolerant algorithm. By replacing the centralized decision-making of the central server in related technologies with a distributed consensus mechanism, decentralized data verification is achieved.

[0040] Step S130: Store the verified shared data in the local distributed ledger of the first vehicle.

[0041] Specifically, a local distributed ledger can represent a data record maintained locally by each participating vehicle. This data record logically maintains consistency with the data records of all vehicles in the peer-to-peer communication network and is organized using a tamper-proof data structure. The local distributed ledger can employ a chained data structure to form a blockchain. Each block encapsulates a set of shared data confirmed within a consensus cycle, and the block header records information such as hash pointers and timestamps used for chain verification. As a lightweight storage strategy, the first vehicle does not need to store the complete historical data of all vehicles in the peer-to-peer communication network; it can only store data directly related to its own driving decisions, thus reducing the storage burden on a single vehicle. For example, the shared data broadcast by the second vehicle within the first vehicle's preset range, and the hash chain formed by the header information of all blocks.

[0042] After a distributed consensus is successfully reached, the first vehicle, as a participant in the consensus process, will execute the operation of writing the verified shared data into the local distributed ledger. By writing the verified shared data into the local distributed ledger, the first vehicle obtains an immutable and traceable local data copy. This local data copy can be reliably used by the first vehicle's autonomous driving algorithm or driver assistance function modules (such as automatic emergency braking and adaptive cruise control), thereby achieving the technical effect of ensuring data integrity and availability while eliminating dependence on a central server.

[0043] By directly broadcasting shared data in a peer-to-peer communication network and using a distributed consensus mechanism to replace the relay and centralized decision-making of the central server, the bottleneck of single point of failure of the central server is fundamentally eliminated. At the same time, the verified shared data is stored in the local distributed ledger of each vehicle, avoiding the aggregation of sensitive information on the central server. This achieves the effects of resisting single point of failure, reducing communication latency, and preventing centralized leakage of data privacy.

[0044] In some embodiments of this disclosure, a distributed consensus mechanism is employed to jointly perform distributed verification of shared data with a second vehicle, including: during the consensus period, determining at least a portion of the vehicles forming the peer-to-peer communication network as consensus committee members based on at least one of the location information of the first vehicle, the movement status information of the first vehicle, and the reputation parameter information of the second vehicle, wherein the reputation parameter information is determined based on the behavioral data of the second vehicle participating in historical consensus; forming a consensus committee group with the consensus committee members to jointly perform distributed verification of the shared data.

[0045] Specifically, the consensus period can characterize the time unit or triggering condition for executing a complete distributed consensus process or electing a consensus committee. The consensus period defines the time granularity for batch verification of shared data. For example, the consensus period may include, but is not limited to: a preset fixed time interval, such as 5 seconds; or a dynamic time window triggered by a specific event, such as when the amount of shared data to be verified reaches a set threshold.

[0046] Consensus committee members can be represented as a subset of vehicles selected from the vehicles forming a peer-to-peer communication network during a specific consensus period, specifically responsible for participating in the distributed verification of shared data within that period. A consensus committee group can be represented as a logical set composed of all consensus committee members and the first vehicle. Within the consensus committee group, distributed verification of shared data is jointly completed through specific role assignments (such as determining the master node and member nodes) and message exchange processes.

[0047] By defining a consensus committee group or consensus committee members, the participants in the consensus process can be limited to a smaller, more trustworthy subset, thereby reducing communication complexity and improving efficiency. For example, this could include, but is not limited to, dynamically selecting one or more vehicles as consensus committee members based on one or more of the following conditions: the location information of the first vehicle, the movement status information of the first vehicle, and the reputation parameters of the second vehicle.

[0048] In one implementation, location information can be obtained through an onboard GPS system. The first vehicle's motion status information may include its direction of travel, speed, etc., and can be read from the vehicle's own Controller Area Network (CAN) bus or inertial measurement unit. Reputation parameter information can characterize a numerical value or index that quantifies the trustworthiness of a second vehicle based on its behavioral data related to historical consensus participation. Reputation parameter information can serve as a screening criterion when electing consensus committee members to suppress malicious vehicles from participating in the consensus process.

[0049] In one implementation, the reputation parameter information can be a reputation score, which may include, but is not limited to: a reputation score accumulated after adding points based on the number of times a vehicle correctly participates in voting and the number of times it provides valid shared data, and deducting points for behaviors such as sending false shared data and inconsistent voting behavior. Vehicles with higher reputation scores are more likely to become members of the consensus committee. For example, each vehicle maintains a reputation score for its neighboring vehicles. When a vehicle correctly participates in voting or broadcasts shared data that is ultimately confirmed as valid during the historical consensus process, its reputation score will increase accordingly. Conversely, if a vehicle is found to have sent false shared data, or its voting behavior is inconsistent with that of the majority of other consensus committee members, its reputation score will be deducted.

[0050] When determining that at least some vehicles are members of the consensus committee, the first vehicle can comprehensively utilize its location information, movement status information, and reputation parameters of the second vehicle to form a screening strategy. For example, the screening strategy could prioritize vehicles traveling in the same direction as the first vehicle, located close to it, and with reputation scores higher than a preset threshold, as members of the consensus committee. The purpose of this is that vehicles traveling in the same direction are more likely to share similar traffic scenarios and areas of interest, vehicles that are close to each other have lower communication latency, and vehicles with high reputation scores are more likely to be honest.

[0051] For example, based on the location and movement status information of the first vehicle, multiple second vehicles with high spatiotemporal correlation to the first vehicle can be identified. Furthermore, based on the reputation parameters of the second vehicles, at least some of these vehicles can be selected as members of the consensus committee. As another example, at least some vehicles can be identified as members of the consensus committee based on the location and movement status information of the first vehicle.

[0052] By employing this multi-dimensional filtering method based on location information, mobility status information, and reputation parameters, the vehicles participating in the consensus can be limited to a subset that is highly relevant to and trustworthy in the current driving scenario of the first vehicle. This reduces the number of vehicles involved in consensus communication and the message overhead, thereby meeting the requirements of low latency and high throughput in the Internet of Vehicles (IoV) scenario. At the same time, the reward and punishment mechanism based on reputation evaluation effectively suppresses the possibility of malicious vehicles being frequently elected as members of the consensus committee. Thus, in the dynamic IoV environment where untrusted vehicles exist, the security and execution efficiency of the consensus process are improved.

[0053] In some embodiments of this disclosure, the consensus committee group includes a master node and member nodes, with the first vehicle being either a master node or one of the member nodes. The consensus committee group, composed of the first vehicle and its members, performs distributed verification of shared data. This includes: if the first vehicle is a master node, packaging the shared data into blocks and broadcasting consensus proposal messages to member nodes based on the blocks; if the first vehicle is a member node, receiving the consensus proposal messages broadcast by the master node, verifying the blocks based on the consensus proposal messages, and broadcasting member confirmation messages to other nodes after successful verification; and generating distributed verification confirmation messages when the first vehicle receives a preset number of member confirmation messages. These distributed verification confirmation messages instruct the submission of the blocks to the local distributed ledger.

[0054] Specifically, in a consensus committee group, one node can be designated as the master node, while the remaining nodes can serve as member nodes. The first "vehicle" can be the master node or one of multiple member nodes, and its role can be dynamically assigned based on preset rotation rules or factors such as reputation parameters. The master node represents the specific "vehicle" designated or elected within the consensus committee group to initiate a new round of consensus. For example, it may include, but is not limited to: the committee member with the highest reputation value within a consensus cycle, a randomly selected committee member, or a committee member determined through a rotation mechanism. Member nodes represent the "vehicles" within the consensus committee group that receive and verify consensus proposal messages initiated by the master node.

[0055] The distributed verification process of shared data by a consensus committee group can also be called the consensus process of shared data by the consensus committee group. Specifically, the consensus process is a process of voting and confirming shared data within the consensus committee group through a pre-defined message interaction flow that includes multiple stages. For example, one node in the consensus committee group acts as the master node, responsible for packaging the received shared data into a data block and broadcasting a consensus proposal message to other member nodes in the consensus committee group. The consensus proposal message is generated based on the block and signed by the master node. In one implementation, the signature is made using the sender's private key, for example, based on Elliptic Curve Cryptography (ECC) to generate the private key. For example, the NIST P-256 elliptic curve or secp256k1 elliptic curve can be used, with a key length of 256 bits, providing security equivalent to the 3072-bit RSA public key cryptography algorithm (RSA 3072). The consensus proposal message is signed with the sender's private key and accompanied by a public key certificate.

[0056] After receiving the consensus proposal message, each member node performs signature verification and content legality checks on the data contained in the block, and broadcasts a confirmation message based on the verification results. In one implementation, the receiver verifies the signature using a public key certificate to ensure the data source is authentic and has not been tampered with; the public key certificate is pre-installed on the vehicle by a trusted authority. When the first vehicle receives more than a preset threshold of consistent confirmation messages from different member nodes, consensus for that block is considered successfully reached. Non-consensus committee members only act as data sources and synchronizers of their local distributed ledgers. That is, after successful consensus, they broadcast the block's hash chain to non-consensus committee members, who then request the complete block via a peer-to-peer communication network based on the block's hash chain and add it to their respective local distributed ledgers.

[0057] In one implementation, if the first vehicle is the master node, it will organize the received shared data according to time order or priority within the current consensus period and package it into blocks. Subsequently, it will generate a consensus proposal message based on the blocks and broadcast this message to all member nodes. The consensus proposal message may include the complete content of the block and the master node's digital signature.

[0058] In one implementation, if the first node is a member node, it receives the consensus proposal message broadcast by the master node. Upon receiving the consensus proposal message, the member node first verifies the master node's signature to confirm the legitimacy of the consensus proposal message's source. Next, it verifies the validity of the data contained within the block, specifically checking whether the data sender's signature is genuine, whether the data format conforms to specifications, and whether the data content has any obvious anomalies. If all these verifications pass, the member node broadcasts a member confirmation message to all other nodes, including the master node, indicating that the member node has voted in favor of the block proposed by the master node.

[0059] In some embodiments, the first vehicle, regardless of whether its role is a master node or a member node, continuously receives member confirmation messages from other consensus committee members. When the first vehicle receives a preset number of identical member confirmation messages from different members, it can determine that consensus for the block has been successfully reached. At this point, the first vehicle generates a distributed verification confirmation message, which can be used to indicate that the block can be submitted to the local distributed ledger.

[0060] In one implementation, the preset number can be set to be greater than or equal to two-thirds of the total number of consensus committee nodes to meet the Byzantine fault tolerance condition, ensuring that even if there are a few malicious or faulty nodes in the consensus committee group, reliable and irreversible consensus on the validity of blocks can still be reached.

[0061] The three-stage process of broadcasting consensus proposal messages by the master node, verifying blocks by member nodes and broadcasting member confirmation messages, and generating distributed verification confirmation messages after the first vehicle receives a threshold of member confirmation messages can use deterministic message interaction steps and strict quantity thresholds as conditions for successful consensus, thereby improving the reliability of distributed verification in unreliable vehicle network environments.

[0062] The generation of a distributed verification confirmation message signifies the successful achievement of consensus. However, if a node writes the verified shared data to its local distributed ledger prematurely or delayed, it may trigger a ledger fork. To prevent this problem, in some embodiments of this disclosure, storing the verified shared data to the local distributed ledger of the first vehicle includes: adding a block to the local distributed ledger of the first vehicle in response to the distributed verification confirmation message.

[0063] Specifically, a causal relationship and timing constraint are established between the first vehicle's operation of writing a block to its local ledger and the generation of the distributed verification confirmation message. The first vehicle will only execute the operation of writing the block to its local distributed ledger after confirming that a distributed verification confirmation message has been generated or after receiving a distributed verification confirmation message broadcast by other nodes. This design locks the ledger update action after consensus is successfully reached.

[0064] By responding to the distributed verification confirmation message and adding the block to the local distributed ledger of the first vehicle, the ledger fork that may be caused by the node writing the block too early before the consensus is successfully reached can be avoided, ensuring that the local distributed ledger of the node can ultimately maintain logical consistency in a dynamically changing and potentially faulty peer-to-peer communication network.

[0065] To further address the issue of critical security data being blocked when vehicles receive large amounts of shared data due to a lack of differentiation in message urgency, the following preferred solutions are also provided.

[0066] In some embodiments of this disclosure, before using a distributed consensus mechanism to jointly perform distributed verification of the shared data with a second vehicle, the method further includes: determining the priority of the shared data based on the event type corresponding to the shared data, wherein the priority includes at least one of the following: a first priority directly related to driving safety, a second priority related to assisted driving, and a third priority related to traffic efficiency; placing the shared data into a cache queue corresponding to the priority of the shared data; and filtering the shared data in the cache queue based on at least one of the time attribute, spatial distance attribute, and source reputation attribute of the shared data.

[0067] Specifically, the priority of shared data can be determined based on the event type corresponding to the shared data. The priority includes at least one of the following: First priority may correspond to emergency event types directly related to driving safety, such as a second vehicle's emergency braking signal, forward collision warning, or drift warning. First priority data directly relates to whether a collision avoidance response can be triggered within milliseconds. Second priority corresponds to event types related to driver assistance, such as lane departure warnings, obstacle location information, and road slipperiness alerts. Second priority data is used to support better decision-making for driver assistance functions such as adaptive cruise control and lane keeping assist. Third priority corresponds to event types related to traffic efficiency, such as information on upcoming traffic congestion, traffic light countdown phases, and available parking space information.

[0068] After determining the data priority of the shared data, the first vehicle will place the shared data into the cache queue corresponding to that priority. Specifically, a circular buffer with priority scheduling function can be maintained in the vehicle's on-board memory. The circular buffer can be logically divided into three queues: queue P0, queue P1, and queue P2. Specifically, queue P0 corresponds to the first priority, queue P1 corresponds to the second priority, and queue P2 corresponds to the third priority.

[0069] Furthermore, to maximize the value of information when cache resources are limited, shared data is dynamically filtered based on multi-dimensional attributes within each cache queue. Specific filtering criteria may include at least one of the following: time attribute, spatial distance attribute, and source reputation attribute. The time attribute can represent the timestamp carried by the shared data itself; the spatial distance attribute can represent the distance between the second vehicle broadcasting the shared data and the first vehicle; and the source reputation attribute can represent the reputation score maintained by the second vehicle broadcasting the shared data in the first vehicle.

[0070] One implementation can perform timeliness filtering, automatically discarding shared data whose timestamps exceed a preset time window limit. For example, if the current sliding window length is 5 seconds, any shared data with a timestamp more than 5 seconds old will be considered to have lost its immediate value and removed directly from the queue. Spatial distance attenuation filtering can also be performed, assigning a retention weight to shared data based on the distance between the second and first vehicles. Shared data that is closer in distance generally has greater reference value for the first vehicle's driving decisions and is therefore less likely to be filtered out. Redundancy merging can also be performed; when multiple pieces of shared data describing the same event or location and similar in type and location exist in the cache queue, only the one with the highest source reputation score is retained, and the rest are marked as redundant and discarded.

[0071] By employing a two-tiered cache management mechanism that combines priority determination with multi-dimensional dynamic filtering within the cache queue, it is ensured that urgent data posing a direct threat to driving safety is always prioritized for processing and transmission, and is sent to the subsequent consensus verification stage as soon as possible. Simultaneously, this two-tiered cache management mechanism effectively suppresses the resource consumption of massive amounts of low-value or repetitive information, ensuring the effectiveness of vehicle-side cache space utilization and data processing throughput efficiency.

[0072] In some embodiments of this disclosure, the shared data is filtered based on at least one of the time attribute, spatial distance attribute, and source reputation attribute of the shared data, including: determining a comprehensive data value score based on at least one of the time attribute, spatial distance attribute, and source reputation attribute; and filtering the shared data based on the comprehensive data value score and a target score threshold.

[0073] Specifically, the first vehicle can determine the overall data value score based on at least one of the following attributes: time, spatial distance, and source reputation. For example, a weighted function can be designed where higher data freshness, closer spatial distance, and higher source reputation score result in a higher overall data value score. Conversely, outdated, distant data with low source reputation will have a lower overall data value score. After determining the overall data value score, the first vehicle compares it with a target score threshold. As a dynamically implemented strategy, the target score threshold can be set lower when the buffer is not full to retain as much potentially useful data as possible. When the buffer is about to overflow, the target score threshold can be dynamically increased, and data with an overall data value score below the target score threshold can be discarded, starting with lower priority queues.

[0074] By transforming the originally discrete, rule-based multi-condition judgments into unified filtering decisions based on comprehensive data value scoring, the data filtering behavior becomes more accurate and consistent, avoiding potential policy conflicts or uncertain results when weighing multiple factors. This improves the decision quality of cache space utilization and the reproducibility of filtering behavior.

[0075] To address the issue of interrupted shared data reception caused by a single communication interface failure in scenarios involving high-speed vehicle movement or fluctuating network environments, the following preferred solutions are also provided.

[0076] In some embodiments of this disclosure, a first vehicle forms a peer-to-peer communication network with multiple second vehicles through various heterogeneous communication interfaces, including a primary communication interface and a backup communication interface. Utilizing the peer-to-peer communication network to receive shared data broadcast by the second vehicles includes: monitoring the data transmission status of the primary communication interface; if the data transmission status does not meet the target data transmission conditions, establishing a backup communication interface to connect with the second vehicles while maintaining the primary communication interface connection; and using the backup communication interface to receive the shared data broadcast by the second vehicles.

[0077] Specifically, the first vehicle forms a peer-to-peer communication network with multiple second vehicles through various heterogeneous communication interfaces. These heterogeneous communication interfaces may include a primary communication interface and backup communication interfaces. For example, the primary communication interface could be a 5G-V2X terminal pass-through interface or a DSRC interface, while the backup communication interface could be a Bluetooth or Wi-Fi Direct interface.

[0078] During the process of receiving data using the peer-to-peer communication network, the first vehicle continuously monitors the data transmission status of the main communication interface. The data transmission status can be evaluated based on a series of indicators reflecting link quality, including but not limited to signal strength, packet loss rate, and end-to-end transmission delay.

[0079] When the data transmission status is detected to be inconsistent with the target data transmission conditions, such as a packet loss rate exceeding 20% ​​or a transmission delay exceeding 100 milliseconds, it indicates that the performance of the main communication link has deteriorated to the point where it cannot reliably transmit vehicle-to-everything (V2X) information. In this case, the first vehicle will not immediately disconnect the main communication interface. Instead, while maintaining the existing connection of the main communication interface, it will actively establish a connection with the target second vehicle via a backup communication interface. This "build first, then disconnect" switching strategy relies on pre-detecting and confirming the availability of the backup link. For example, the first vehicle can actively pair and establish a connection with at least one nearest neighbor second vehicle through Bluetooth or Wi-Fi Direct discovery mechanisms. After the communication channel of the backup link has been confirmed to be stable through a handshake, the data stream is smoothly switched to the backup interface. Subsequently, the first vehicle continues to receive shared data broadcast by the second vehicle using this backup communication interface. When using the backup communication interface to receive shared data broadcast by the second vehicle, geographic location-based clustering can be employed. Cluster heads can be selected to forward data with surrounding clusters, forming a multi-hop local network to maintain information sharing within a limited range. For example, this ensures that vehicles within 200 meters ahead can still receive emergency braking signals.

[0080] Once the transmission status monitoring indicators of the main communication interface recover to meet the target data transmission conditions, the data stream can be switched back to the main communication interface first, and the backup connection can be disconnected as needed to save power consumption and channel resources.

[0081] In one implementation, when the data transmission status is detected to meet the target data transmission conditions, the main communication interface can be used to continuously receive shared data broadcast by the second vehicle.

[0082] By using this multi-mode heterogeneous interface collaboration and adaptive switching strategy of building first and then disconnecting, the problem of peer-to-peer communication interruption caused by the failure of a single communication standard can be reduced in weak network or no network scenarios such as tunnels, underground garages, remote mountainous areas or strong electromagnetic interference, thus maintaining the continuity of data reception between vehicles and ensuring that information can still be reliably transmitted under adverse communication conditions.

[0083] Figure 2 This is a flowchart illustrating a vehicle network information sharing method according to some embodiments of this disclosure.

[0084] like Figure 2 As shown, the vehicle network information sharing method of this disclosure is applied to a second vehicle, which forms a peer-to-peer communication network with at least one first vehicle. The method may include the following steps.

[0085] Step S210: Perform privacy protection processing on sensitive fields in the shared data stored in the second vehicle to generate proof data. The proof data is data that enables vehicles forming a peer-to-peer communication network to verify the authenticity of sensitive fields without exposing the specific content of the sensitive fields.

[0086] Specifically, the second vehicle, as the data sender, may broadcast shared data containing sensitive fields, such as the vehicle's precise Global Positioning System (GPS) coordinates, license plate number, and driver identification. Broadcasting these sensitive fields in plaintext within a peer-to-peer communication network poses a threat to user privacy. Therefore, the second vehicle performs privacy protection processing on sensitive fields before broadcasting shared data. This privacy protection processing aims to generate special proof data. Specifically, the proof data demonstrates that other vehicles in the peer-to-peer communication network can verify the truthfulness of a statement regarding a sensitive field based on this data, but cannot deduce the specific content of that sensitive field from the proof data.

[0087] In one implementation, privacy protection can be achieved using zero-knowledge proof techniques, such as a lightweight variant of zero-knowledge succinct non-interactive argument of knowledge (zk-SNARKs). Specifically, the statement to be verified could be "the obstacle observed by this vehicle is located within a certain area," "this vehicle's speed exceeds a certain threshold," or "this vehicle is currently near an intersection." The second vehicle compiles the compliance judgment logic of the statement to be verified into an arithmetic circuit, using sensitive fields (such as precise coordinates and actual speed) as private inputs and public statements (such as area radius and speed threshold) as public inputs. By running a proof generation algorithm, proof data is generated, for example, proof π. This proof π itself does not contain precise coordinates or actual speed; any third party intercepting this proof π cannot determine the second vehicle's specific location or speed. However, the receiving party (such as the first vehicle) can verify the truthfulness of a certain statement in the second vehicle's sensitive fields by running the corresponding verification algorithm, inputting the proof π and the public statements, without needing to know the specific content of the sensitive fields.

[0088] Step S220: Using a peer-to-peer communication network, the shared data and proof data are broadcast to the first vehicle, so that the first vehicle can use a distributed consensus mechanism to jointly verify the shared data with the second vehicle, and store the verified shared data in the first vehicle's local distributed ledger.

[0089] After generating the proof data, the second vehicle broadcasts it along with its corresponding shared data through the peer-to-peer communication network. For example, in an emergency braking message, besides the non-sensitive information "event type: emergency braking," its location information is replaced with a proof π associated with the location information and an associated public statement (such as proving the obstacle is within area R). Upon receiving the broadcast, the first vehicle verifies its signature using the second vehicle's public key certificate and uses the proof π and public statement for verification. If the verification passes, the first vehicle can be certain that the message indeed comes from a legitimate vehicle claiming to be located within area R, and that the message has not been tampered with during transmission. In this way, the first vehicle can trust the broadcast information without knowing the second vehicle's exact location and incorporate it into subsequent consensus and decision-making processes.

[0090] Before the second vehicle broadcasts shared data, by performing privacy protection processing on sensitive fields in the shared data, the second vehicle can still prove the credibility of the shared data it broadcasts to surrounding vehicles without disclosing its own driving trajectory and identity details, thus achieving an effective balance between data availability and user privacy protection.

[0091] In a further preferred embodiment, in order to avoid unnecessary broadcast storms while ensuring message timeliness, the process of the second vehicle broadcasting shared data and proof data to the first vehicle can adopt an adaptive broadcast interval strategy.

[0092] In some embodiments of this disclosure, broadcasting shared data and proof data to a first vehicle using a peer-to-peer communication network includes: determining a broadcast interval for broadcasting the shared data and proof data to the first vehicle based on at least one of the second vehicle's driving speed, the second vehicle's driving direction, and the density of the first vehicle within a preset range of the second vehicle; and broadcasting the shared data and proof data to the first vehicle using the peer-to-peer communication network based on the broadcast interval.

[0093] Specifically, the second vehicle dynamically determines its broadcast interval based on at least one of its own speed, direction of travel, and the density of the first vehicle within its preset communication range. Speed ​​and density are key variables determining the timeliness requirements of safety messages. For example, on a highway at high speed with high surrounding vehicle density (i.e., many vehicles around), vehicle status changes rapidly, and an emergency braking by the vehicle ahead needs to be received by multiple vehicles behind within a very short time. Therefore, a shorter broadcast interval, such as broadcasting once every 100 milliseconds, can be used. Conversely, in low-speed congestion or low surrounding vehicle density (i.e., few vehicles around), the scene changes slowly, and a longer broadcast interval, such as broadcasting once per second, can be used to save wireless channel resources and computational processing overhead.

[0094] Once the broadcast interval is determined, the second vehicle will periodically use the peer-to-peer communication network to broadcast the latest shared data and its corresponding proof data to the surrounding first vehicles based on the broadcast interval.

[0095] By adaptively adjusting the broadcast interval, a dynamic balance is achieved between the load of the peer-to-peer communication network and the real-time nature of messages, enabling effective information sharing with appropriate communication overhead under various road conditions with varying traffic flow density.

[0096] In one implementation, when a second vehicle (Vehicle A) detects an emergency braking event, it generates an emergency message and broadcasts it to the first vehicle (Vehicle B) via 5G-V2X. The emergency message includes the event type (emergency braking), timestamp, location information, and Vehicle A's signature. The location information is processed using zero-knowledge proofs to handle sensitive fields. Vehicle B receives the emergency message and verifies it, confirming the message's source region is reliable. It then decrypts and signs the message for verification. After all verifications pass, the message is assigned a first-priority (P0) and directly placed into the corresponding first-priority cache queue. It is then filtered and subjected to distributed verification. During verification, Vehicle B broadcasts the emergency message to a consensus committee group to participate in the consensus process. The consensus committee group votes to confirm the emergency message, ultimately generating a block. After successful verification, the block is added to the local distributed ledger for post-event auditing or insurance claims. Throughout the information transmission process, if the primary communication interface is interrupted, it automatically switches to a backup communication interface to receive data, maintaining local communication between Vehicle A and Vehicle B and ensuring the emergency braking message can still be transmitted.

[0097] Corresponding to the above embodiments, this disclosure also proposes a vehicle that can serve as either the first vehicle or the second vehicle in any of the above embodiments.

[0098] Figure 3 This is a block diagram of a vehicle according to some embodiments of the present disclosure.

[0099] like Figure 3 As shown, the vehicle 300 in this embodiment may include: a memory 310, a processor 320, and a program stored in the memory 310 and executable on the processor 320. When the processor 320 executes the program, it implements the above-described vehicle network information sharing method.

[0100] According to the embodiments of this disclosure, by executing the above-described vehicle-to-everything (V2X) information sharing method, the vehicle can directly broadcast shared data in the peer-to-peer communication network and use a distributed consensus mechanism to replace the relay and centralized decision-making of the central server, thereby fundamentally eliminating the bottleneck of single point of failure of the central server. At the same time, the verified shared data is stored in the local distributed ledger of each vehicle, avoiding the aggregation of sensitive information in the central server, thereby achieving the effects of resisting single point of failure, reducing communication latency, and preventing centralized leakage of data privacy.

[0101] Based on the above-described vehicle-to-everything (V2X) information sharing method, this disclosure also provides a V2X information sharing device. The following will be combined with... Figure 4 The device is described in detail.

[0102] Figure 4 This disclosure presents a structural block diagram of some implemented vehicle-to-everything (V2X) information sharing devices.

[0103] like Figure 4 As shown, the vehicle-to-everything (V2X) information sharing device 400 of this embodiment is applied to a first vehicle, and multiple first vehicles and at least one second vehicle form a peer-to-peer communication network. Specifically, the V2X information sharing device 400 includes a receiving module 410, a verification module 420, and a storage module 430.

[0104] The receiving module 410 is used to receive shared data broadcast by the second vehicle using a peer-to-peer communication network. In one embodiment, the receiving module 410 can be used to perform step S110 described above, which will not be repeated here.

[0105] The verification module 420 is used to perform distributed verification of shared data jointly with the second vehicle using a distributed consensus mechanism. In one embodiment, the verification module 420 can be used to execute step S120 described above, which will not be repeated here.

[0106] Storage module 430 is used to store the verified shared data to the local distributed ledger of the first vehicle. In one embodiment, storage module 430 can be used to perform step S130 described above, which will not be repeated here.

[0107] In some embodiments of this disclosure, the verification module 420 includes: a first verification submodule, configured to determine at least a portion of the vehicles forming the peer-to-peer communication network as members of the consensus committee based on at least one of the location information of the first vehicle, the movement status information of the first vehicle, and the reputation parameter information of the second vehicle during the consensus period, wherein the reputation parameter information is determined based on the behavioral data of the second vehicle participating in historical consensus; and a second verification submodule, configured to form a consensus committee group with the members of the consensus committee to jointly perform distributed verification of the shared data.

[0108] In some embodiments of this disclosure, the consensus committee group includes a master node and member nodes, and the first vehicle is either a master node or one of the member nodes; the second verification submodule includes: a first verification unit, configured to, if the first vehicle is a master node, package shared data into blocks and broadcast consensus proposal messages to member nodes based on the blocks; a second verification unit, configured to, if the first vehicle is a member node, receive the consensus proposal messages broadcast by the master node, verify the blocks based on the consensus proposal messages, and broadcast member confirmation messages to other nodes after successful verification; and a third verification unit, configured to, if the first vehicle receives a preset number of member confirmation messages, generate distributed verification confirmation messages; wherein, the distributed verification confirmation messages are used to instruct the blocks to be submitted to the local distributed ledger.

[0109] In some embodiments of this disclosure, storage module 430 includes: a first storage submodule, configured to add a block to the local distributed ledger of the first vehicle in response to a distributed verification confirmation message.

[0110] In some embodiments of this disclosure, the vehicle-to-everything (V2X) information sharing device 400 further includes: a first filtering module, configured to determine the priority of the shared data based on the event type corresponding to the shared data, wherein the priority includes at least one of the following: a first priority directly related to driving safety, a second priority related to assisted driving, and a third priority related to traffic efficiency; a second filtering module, configured to place the shared data into a cache queue corresponding to the priority of the shared data; and a third filtering module, configured to filter the shared data in the cache queue based on at least one of the time attribute, spatial distance attribute, and source reputation attribute of the shared data.

[0111] In some embodiments of this disclosure, the third filtering module includes: a first filtering submodule, used to determine a comprehensive data value score based on at least one of a time attribute, a spatial distance attribute, and a source reputation attribute; and a second filtering submodule, used to filter shared data based on the comprehensive data value score and a target score threshold.

[0112] In some embodiments of this disclosure, the first vehicle forms a peer-to-peer communication network with multiple second vehicles through multiple heterogeneous communication interfaces, including a main communication interface and a backup communication interface; the receiving module 410 includes: a first receiving submodule for monitoring the data transmission status of the main communication interface; a second receiving submodule for establishing a backup communication interface to connect with the second vehicles while maintaining the connection of the main communication interface when the data transmission status does not meet the target data transmission conditions; and a third receiving submodule for receiving shared data broadcast by the second vehicles using the backup communication interface.

[0113] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0114] According to embodiments of this disclosure, any plurality of modules among the receiving module 410, verification module 420, and storage module 430 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules may be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the receiving module 410, verification module 420, and storage module 430 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the receiving module 410, verification module 420, and storage module 430 may be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0115] Based on the above-described vehicle-to-everything (V2X) information sharing method, this disclosure further provides a V2X information sharing device. The following will be combined with... Figure 5 The device is described in detail.

[0116] Figure 5 This disclosure presents a structural block diagram of some embodiments of a vehicle-to-everything (V2X) information sharing device.

[0117] like Figure 5 As shown, the vehicle-to-everything (V2X) information sharing device 500 of this embodiment is applied to a second vehicle, which forms a peer-to-peer communication network with at least one first vehicle. Specifically, the V2X information sharing device 500 includes a generation module 510 and a broadcast module 520.

[0118] The generation module 510 is used to perform privacy protection processing on sensitive fields in the shared data stored in the second vehicle and generate proof data. The proof data is data that enables vehicles forming the peer-to-peer communication network to verify the authenticity of the sensitive fields without exposing their specific content. In one embodiment, the generation module 510 can be used to execute step S210 described above, which will not be repeated here.

[0119] The broadcast module 520 is used to broadcast shared data and proof data to the first vehicle via a peer-to-peer communication network, so that the first vehicle can use a distributed consensus mechanism to jointly perform distributed verification of the shared data with the second vehicle, and store the verified shared data in the first vehicle's local distributed ledger. In one embodiment, the broadcast module 520 can be used to perform step S220 described above, which will not be repeated here.

[0120] In some embodiments of this disclosure, the broadcast module 520 includes: a first broadcast submodule, configured to determine a broadcast interval for broadcasting shared data and proof data to the first vehicle based on at least one of the driving speed of the second vehicle, the driving direction of the second vehicle, and the density of the first vehicle within a preset range of the second vehicle; and a second broadcast submodule, configured to broadcast the shared data and proof data to the first vehicle using a peer-to-peer communication network based on the broadcast interval.

[0121] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0122] According to embodiments of this disclosure, any plurality of modules in the generation module 510 and the broadcast module 520 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules may be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the generation module 510 and the broadcast module 520 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the generation module 510 and the broadcast module 520 may be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0123] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0124] It should be understood that various parts of this disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0125] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0126] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0127] In this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this disclosure according to the specific circumstances.

[0128] Although embodiments of the present disclosure have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present disclosure. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present disclosure.

Claims

1. A method for sharing information in a vehicle-to-everything (V2X) network, characterized in that, Applied to a first vehicle, wherein multiple first vehicles and at least one second vehicle form a peer-to-peer communication network, the method includes: Using the peer-to-peer communication network, receive shared data broadcast by the second vehicle; A distributed consensus mechanism is used in conjunction with the second vehicle to perform distributed verification of the shared data. The verified shared data is stored in the local distributed ledger of the first vehicle.

2. The method according to claim 1, characterized in that, The step of using a distributed consensus mechanism to jointly perform distributed verification of the shared data with the second vehicle includes: During the consensus period, based on at least one of the location information of the first vehicle, the movement status information of the first vehicle, and the reputation parameter information of the second vehicle, at least a portion of the vehicles constituting the peer-to-peer communication network are identified as members of the consensus committee, wherein the reputation parameter information is determined based on the behavioral data of the second vehicle participating in historical consensus. The consensus committee members form a consensus committee group to jointly perform distributed verification of the shared data.

3. The method according to claim 2, characterized in that, The consensus committee group includes a master node and member nodes, and the first vehicle is one of the master node or the member node; The process of forming a consensus committee group with the consensus committee members to jointly perform distributed verification of the shared data includes: If the first vehicle is the master node, the shared data is packaged into a block, and a consensus proposal message is broadcast to the member nodes based on the block; If the first vehicle is the member node, it receives the consensus proposal message broadcast by the master node, verifies the block based on the consensus proposal message, and broadcasts a member confirmation message to other nodes after successful verification. When the first vehicle receives a preset number of member confirmation messages, a distributed verification confirmation message is generated; wherein, the distributed verification confirmation message is used to instruct the block to be submitted to the local distributed ledger.

4. The method according to claim 3, characterized in that, The step of storing the verified shared data in the local distributed ledger of the first vehicle includes: In response to the distributed verification confirmation message, the block is added to the local distributed ledger of the first vehicle.

5. The method according to claim 1, characterized in that, Before employing a distributed consensus mechanism and jointly performing distributed verification of the shared data with the second vehicle, the following steps are also included: Based on the event type corresponding to the shared data, the priority of the shared data is determined, wherein the priority includes at least one of the following: a first priority directly related to driving safety, a second priority related to assisted driving, and a third priority related to traffic efficiency; The shared data is placed into a cache queue corresponding to the priority of the shared data. Within the cache queue, the shared data is filtered based on at least one of the time attribute, spatial distance attribute, and source reputation attribute of the shared data.

6. The method according to claim 5, characterized in that, The filtering of the shared data based on at least one of the time attribute, spatial distance attribute, and source reputation attribute of the shared data includes: A comprehensive data value score is determined based on at least one of the time attribute, the spatial distance attribute, and the source reputation attribute. The shared data is filtered based on the comprehensive value score of the data and the target score threshold.

7. The method according to claim 1, characterized in that, The first vehicle forms a peer-to-peer communication network with multiple second vehicles through multiple heterogeneous communication interfaces, including a main communication interface and a backup communication interface. The step of receiving shared data broadcast by the second vehicle using the peer-to-peer communication network includes: Monitor the data transmission status of the main communication interface; If the data transmission status does not meet the target data transmission conditions, while maintaining the connection of the main communication interface, the backup communication interface is established to connect with the second vehicle. The second vehicle broadcasts shared data using the backup communication interface.

8. A method for sharing information in a vehicle-to-everything (V2X) network, characterized in that, Applied to a second vehicle, which forms a peer-to-peer communication network with at least one first vehicle, the method includes: Sensitive fields in the shared data stored in the second vehicle are processed for privacy protection to generate proof data. The proof data is data that enables the vehicles constituting the peer-to-peer communication network to verify the authenticity of the sensitive fields without exposing the specific content of the sensitive fields. Using the peer-to-peer communication network, the shared data and the proof data are broadcast to the first vehicle, so that the first vehicle and the second vehicle can jointly perform distributed verification of the shared data using a distributed consensus mechanism, and store the verified shared data in the local distributed ledger of the first vehicle.

9. The method according to claim 8, characterized in that, The step of broadcasting the shared data and the proof data to the first vehicle using the peer-to-peer communication network includes: The broadcast interval for broadcasting the shared data and the proof data to the first vehicle is determined based on at least one of the second vehicle's driving speed, the second vehicle's driving direction, and the density of the first vehicle within a preset range of the second vehicle. Based on the broadcast interval, the shared data and the proof data are broadcast to the first vehicle using the peer-to-peer communication network.

10. A vehicle, characterized in that, include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the vehicle network information sharing method according to any one of claims 1 to 9.

Images