Vehicle-to-Everything (V2X) Traffic Information Consensus System and Route Planning Method Based on Consensus System

Abstract

This invention relates to a vehicle-to-everything (V2X) traffic information consensus system and a route planning method based on the consensus system. The system includes a dynamic consensus group selection module for selecting a coordinator from edge nodes and generating a consensus group through dynamic election; a first-stage competitive block-producing module for competing for the right to produce blocks and report traffic information based on effective capacity and reputation; a second-stage competitive block-producing module for competing for the right to produce blocks and report traffic information again after excluding the winner of the first stage; a two-stage differentiated reward module for giving different reputation rewards to the winners of the first and second stage competitive block-producing stages; and a reputation management and self-healing module for managing the reputation values ​​of all edge nodes in the network and realizing fault recovery based on the established two-layer blacklist-self-healing logic. It not only maintains energy-saving characteristics but also significantly improves transaction processing speed, has anti-attack capabilities, and can self-heal in large-scale networks, providing reliable and consensus-based traffic data.

Description

Technical Field

[0001] This invention belongs to the field of vehicle network data processing technology, specifically relating to a vehicle network traffic information consensus system and a route planning method based on the consensus system. Background Technology

[0002] In typical connected vehicle applications, such as intersections or specific road sections, data sources from multiple vehicles and sensors generate a large amount of real-time traffic information, which may even conflict with each other. For example, for the same event (such as a temporary obstacle), there may be multiple reports with different timestamps or location descriptions. If navigation and route planning systems make decisions directly based on this raw data, it will lead to problems such as frequent path jitter and inaccurate estimated time of arrival (ETA).

[0003] Wu Hanlin et al. proposed a fine-grained path planning method based on deep learning (DL) to predict the spatial-temporal characteristics of vehicle traffic (Reference: Deep Learning Enabled Fine Grained Path Planning for Connected Vehicular Networks, IEEE Transactions on Vehicular Technology 71.10 (2022): 10303-10315.). Although it can predict future road traffic trends, it cannot share real-time traffic information, which greatly reduces the timeliness of traffic information.

[0004] Oubbati Omar Sami et al. proposed an SDN-based vehicle path planning scheme (reference: SEARCH: an SDN-Enabled Approach for Vehicle Path-Planning, IEEE Transactions on Vehicular Technology 69.12(2020):14523-14536.) to enhance the situational awareness of urban roads, efficiently collect traffic information in real time, and formulate optimal navigation strategies. However, its use of drones to construct the architecture does not conform to the general situation of daily traffic processes and cannot solve the data collection problem before general path planning.

[0005] Chen et al. proposed an autonomous vehicle path planning scheme using deep reinforcement learning at network edge nodes (Reference: An Intelligent Path Planning Scheme of Autonomous Vehicles Platoon Using Deep Reinforcement Learning on Network Edge, IEEE Access 8 (2020): 99059-99069.). While ensuring the task deadline, it can significantly reduce the fuel consumption of the vehicle fleet. However, its experimental subjects are autonomous vehicles, and the current autonomous driving technology is not yet mature. Therefore, its universality to real road conditions is insufficient and it cannot meet the needs of complex real-world road conditions.

[0006] Consensus mechanisms can guarantee the consistency of blockchain ledger data. Consensus on real-time traffic data in the Internet of Vehicles (IoV) provides highly reliable and consistent data for application decision-making, resolving issues such as frequent route fluctuations and inaccurate estimated times of arrival (ETAs). However, consensus performance requirements vary across different scenarios, necessitating the design or selection of consensus mechanisms based on the specific characteristics and needs of each scenario.

[0007] Traditional Proof-of-Capacity (PoC) consensus mechanisms (such as Burstcoin and Chia) utilize hard disk space resources instead of electricity resources for minimum time competition, offering significant advantages in terms of green energy efficiency. However, they suffer from the following major drawbacks: 1) High confirmation latency: Due to the need to prevent forks, traditional PoC typically requires long block intervals, resulting in low system throughput (TPS). 2) Security issues: They are vulnerable to "Nothing at Stake" attacks and "grinding" attacks because the cost of generating multiple block branches is extremely low. 3) Lack of dynamic adaptability: Existing consensus systems often lack automatic recovery mechanisms after suffering large-scale network attacks (such as DDoS or Sybil attacks). Even after the attack stops, honest nodes may be unable to rejoin the consensus process in time due to reputational damage or resource exhaustion, leading to a prolonged period of low system performance. 4) Limited scalability: As the number of nodes in the network increases, the communication overhead of network broadcasting and verification grows exponentially. Therefore, there is an urgent need for a consensus method suitable for the Internet of Vehicles environment that can maintain the energy-saving characteristics of PoC, significantly improve transaction processing speed, have anti-attack capabilities, and be self-healing in large-scale networks. Summary of the Invention

[0008] In view of the shortcomings and deficiencies of the existing technology, the first objective of the present invention is to provide a vehicle-to-everything (V2X) traffic information consensus system. This system is suitable for the V2X environment, can maintain the energy-saving characteristics of Proof-of-Concept (PoC), significantly improve transaction processing speed, has anti-attack capabilities, and can self-heal in large-scale networks. It can provide reliable and consensus-based traffic data, thereby improving the stability and decision-making accuracy of the upper-layer route planning system.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] A vehicle-to-everything (V2X) traffic information consensus system includes a dynamic consensus group selection module, a first-stage competitive block generation module, a second-stage competitive block generation module, a two-stage differentiated reward module, and a reputation management and self-healing module. The dynamic consensus group selection module is used to select a coordinator for the consensus process from edge nodes. The coordinator is either the winner of the previous round or the initial node. A consensus group is generated through dynamic election. During dynamic election, the top 50% of edge nodes in the comprehensive score are first selected as a candidate pool. Then, a logarithmic constraint is applied based on the total number of edge nodes N in the network to determine the number of consensus group members K.

[0011] The first-stage competitive block generation module is used to compete for the right to generate blocks and report traffic information based on effective capacity and reputation.

[0012] The second-stage competitive block production module is used to conduct another round of competition for block production and traffic reporting rights after excluding the winner of the first stage.

[0013] The dual-stage differentiated reward module is used to give different reputation rewards to the winners of the first-stage competitive block generation module and the second-stage competitive block generation module. The winner of the first stage is given a fixed basic reward, while the winner of the second stage is given a dynamic reward based on ability.

[0014] The reputation management and self-healing module is used to manage the reputation values ​​of all edge nodes in the network and to achieve fault recovery based on the established two-layer blacklist mechanism, global amnesty and self-healing logic.

[0015] As a preferred embodiment of the present invention, the process by which the dynamic consensus group selection module dynamically elects a consensus group is as follows:

[0016] Step A1. Startup and Staking:

[0017] At the start of each round, the coordinator broadcasts a message to open the staking window; edge nodes participating in the consensus across the network calculate their own comprehensive score and submit a comprehensive score of capacity and reputation to the coordinator, while also submitting their staking space;

[0018] The expression for the overall score is: ComScore = C × R;

[0019] ComScore is the overall score, C is the physical capacity, and R is the reputation score.

[0020] Step B2. Sort and filter the Top 50%:

[0021] The coordinator collects the submission information of all qualified edge nodes, sorts them from highest to lowest score, and selects the top 50% of edge nodes as the candidate pool; a logarithmic constraint is applied based on the total number of edge nodes N in the network to determine the number of consensus group members. Then, the top K members are selected from the candidate pool to form a consensus group, which is then broadcast across the entire network.

[0022] As a preferred embodiment of the present invention, the process of the first-stage block-competing module competing to produce blocks is as follows:

[0023] Step A2. Calculate the effective capacity E based on the physical capacity C, wherein the effective capacity E has a non-linear power function relationship with the physical capacity C;

[0024] Step B2. Perform capacity graph traversal and deadline calculation:

[0025] Edge nodes generate challenge values ​​based on the hash of the previous block, traverse and search the capacity graph in local storage to find the best random number that matches the challenge value, and calculate the deadline by combining the effective capacity E and the reputation value R.

[0026] Step C2. Broadcast the proposal:

[0027] The first node that finds a random number that meets the difficulty requirement and reaches the deadline is the winner of the first stage, and the Phase 1 proposal is broadcast.

[0028] Step D2. Consensus Voting:

[0029] Other members of the consensus group verify the legality of the proposal; if legal, they send a signature vote; the winner of the first phase must collect more than 2 / 3 of the consensus group members' signature votes for the block to be successfully verified.

[0030] Step E2. Block production:

[0031] After reaching a consensus, the winner of the first phase broadcasts the Phase 1 confirmation block message.

[0032] As a preferred embodiment of the present invention, the process of the second-stage competitive block generation module is as follows: Excluding the winner of the first stage, the remaining K-1 consensus members use the hash value of the Phase 1 block as a new seed, recalculate the challenge value, and traverse the capacity graph stored locally to find a new optimal random number that matches the challenge value. They then combine the effective capacity E and the reputation value R to calculate the deadline. Subsequently, the edge node that first finds a random number that meets the difficulty requirement and reaches the deadline becomes the winner of the second stage and broadcasts the Phase 2 proposal. Next, the consensus members verify and vote on the Phase 2 proposal. The winner of the second stage must also collect signatures from more than 2 / 3 of the consensus members for the proposed block to be successfully verified. Finally, after reaching a consensus, the winner of the second stage broadcasts the Phase 2 confirmation block message.

[0033] As a preferred embodiment of the present invention, the dual-stage differentiated reward module provides a fixed base reward of 2 to the winner of the first stage; and a dynamic reward based on ability matching to the winner of the second stage, with the reward formula as follows:

[0034] ;

[0035] Where Reward_P2 is the reward value for the winner of the second phase, E_1 is the effective capacity of the winner of Phase 1, E_2 is the effective capacity of the winner of Phase 2, and the base reward value BaseReward is 2.

[0036] As a preferred embodiment of the present invention, the reputation management and self-healing module rewards edge nodes that successfully produce blocks and participate in valid voting, and the reputation value update process is as follows:

[0037] ;

[0038] Wherein, ΔR follows a normal distribution N(2.0,0.5) with a mean of 2.0 and a standard deviation of 0.5, R_old is the reputation value of the edge node in the previous state, and if the edge node is a successful block-producing node, then this value is the reputation value after adding the reward value, and R_new is the updated reputation value.

[0039] Edge nodes detected to be producing double blocks or engaging in malicious behavior will be penalized, and the reputation value update process is as follows:

[0040] ;

[0041] ;

[0042] Where Penalty is the penalty value, CurrentRep is the current reputation value of the edge node, and Threshold is the reputation threshold.

[0043] As a preferred embodiment of the present invention, the reputation management and self-healing module establishes a two-layer blacklist mechanism and introduces global amnesty and self-healing logic. The two-layer blacklist includes a temporary observation list (Level-1) and a permanent ban list (Level-2). The trigger condition for the temporary observation list (Level-1) is that the reputation value of an edge node falls below a threshold for the first time or times out multiple times. When Level-1 is triggered, the corresponding edge node will be disqualified from participating in the consensus group election, and a recovery time trigger will be initiated. If there is no further malicious behavior during the observation period, the edge node will be removed from the temporary observation list and its corresponding reputation will be restored. The trigger condition for the permanent ban list (Level-2) is that the edge node commits malicious acts or forges signatures again during Level-1. When Level-2 is triggered, the corresponding edge node will be permanently deprived of its network participation rights.

[0044] The global amnesty and self-healing logic is as follows: When the system detects that the network throughput has returned to normal or the proportion of malicious nodes has dropped beyond a set value, and the average reputation is lower than a set threshold, a global recovery event is triggered. All edge nodes in the network execute the global amnesty protocol, traverse the local edge node list, and for all edge nodes that are in the temporary observation list Level-1 but have not entered the permanent ban list Level-2, their reputation value is forcibly reset to the safety baseline, and they regain the qualification to participate in the Top 50% consensus group election in the next round.

[0045] As a further preferred embodiment of the present invention, the expression for the effective capacity E in step A2 is: ;

[0046] The expression for the deadline in step B2 is: Where BaseTime is the base time.

[0047] The second objective of this invention is to provide a route planning method based on a consensus system. Before route planning, the method processes the vehicle network data to ensure the consistency, uniqueness, and reliability of the input data. Then, it plans the route based on the real-time traffic information that has reached a consensus, thus avoiding problems such as frequent path fluctuations and inaccurate estimated time of arrival (ETA). This method meets the general conditions of daily traffic processes and is applicable to complex real-world traffic conditions.

[0048] A route planning method based on a consensus system, comprising the following steps:

[0049] Step 1. On-board unit (OBU), roadside sensors, and pedestrian / non-motorized vehicle units collect dynamic traffic data in real time and send the collected raw road condition data to the nearest roadside unit (RSU), i.e., edge node;

[0050] Step 2. The Roadside Unit (RSU) acquires road condition information, completes identity verification and data preprocessing, and submits it to the authentication layer. The authentication layer reaches consensus based on the aforementioned vehicle-to-everything (V2X) road condition information consensus system. When the consensus threshold is reached, the data is uploaded to the blockchain, and a confirmed "road condition snapshot" is generated.

[0051] Step 3. Upload the generated and determined "road condition snapshot" to the application service layer to provide a unified and consensus-based "road condition snapshot" for the dynamic route planning module within the application service layer;

[0052] Step 4. The dynamic route planning module performs route planning based on the "road condition snapshot".

[0053] As a preferred embodiment of the present invention, the consensus process of the vehicle-to-everything (V2X) traffic information consensus system in step 2 is as follows:

[0054] Step 2.1. Select a coordinator for the consensus process based on whether it is the initialization phase; at the beginning of each round, the coordinator broadcasts a message to open the staking window, and all edge nodes in the network calculate their own comprehensive scores and send them to the coordinator; after receiving the reply, the coordinator excludes edge nodes in the double-layer blacklist, sorts them from high to low scores, selects the top 50%, and according to the logarithmic formula K=6×log2(N), the coordinator finally selects the top K from the top 50% of edge nodes to form a consensus group and broadcasts the list;

[0055] Step 2.2. Phase 1 Minimum Deadline Competition:

[0056] After the K consensus members receive the list, they start the local PoC minimum deadline competition; each edge node generates a challenge value based on the hash of the previous block, quickly retrieves the best random number in the local Plot file, and calculates the deadline; if edge node A completes the retrieval first and reaches the deadline, it packages the transactions to generate the Phase1 proposal block and broadcasts it to the entire network.

[0057] Step 2.3. Phase 1 Confirmation and Stage Transition:

[0058] The remaining K-1 consensus members receive the proposal block from edge node A and verify its legitimacy. After successful verification, they send a signature message to edge node A. After edge node A collects more than 2 / 3×K signatures, it broadcasts the Phase 1 confirmation block. Once all edge nodes in the network receive the confirmation, they automatically proceed to Phase 2.

[0059] Step 2.4. Phase 2 Double Confirmation:

[0060] The remaining K-1 consensus group members initiate the second round of PoC retrieval based on the Phase1 block hash; edge node C obtains the right to produce a Phase2 block and generates a Phase2 proposal that includes a reference to the block hash of edge node A; the consensus group votes again to confirm, and after reaching a consensus, broadcasts the final confirmed Phase2 block, completes the data on-chain, and generates a confirmed "road condition snapshot";

[0061] Step 2.5. Reputation Settlement and Self-Healing:

[0062] All edge nodes write two blocks to the ledger. According to the differentiated reward formula, edge node A receives a fixed reward, and edge node C receives a dynamic reward matching the capacity of edge node A. Then, the reputation of all edge nodes is updated based on the dynamic reputation scoring model, and the temporary watch list Level-1 and the permanent ban list Level-2 are updated simultaneously. The average reputation is calculated. If the system detects that the network throughput has returned to normal or the proportion of malicious nodes has dropped beyond a set value, and the average reputation of the network is lower than the set threshold, the system will automatically trigger reputation recovery, resetting the reputation of all edge nodes on the temporary watch list to 70.0, thus completing self-healing.

[0063] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0064] (1) This invention collects the original road condition information submitted by the vehicle-mounted unit (OBU), roadside sensors, etc., and enables the edge nodes to reach a consensus on the road condition information based on the vehicle network road condition information consensus system. Then, the processed road condition information is encapsulated into a data packet, and finally, efficient route planning is performed based on this road condition data packet, thereby solving problems such as complex data volume, data conflict, and frequent jitter of the planned path.

[0065] (2) The vehicle network traffic information consensus system provided by the present invention introduces a two-stage consensus process (each stage produces blocks) and a dynamic reputation recovery mechanism. Under the premise of ensuring decentralization, it realizes high-frequency transaction confirmation and gives the system the ability to quickly self-heal after the attack ends, so that it can realize reliable information sharing of the vehicle network and provide a guarantee for consensus information.

[0066] (3) The vehicle network traffic information consensus system provided by the present invention can reach a consensus on the real-time traffic conditions in the region; finally, it outputs a unified, consensus-reached "traffic condition snapshot"; the snapshot contains a unique, confirmed list of events and their attributes (such as event ID, type, precise location, confirmation timestamp, credibility, etc.); the "traffic condition snapshot" can be used as a standard data interface for other modules such as hazard warning in the vehicle network ecosystem to call directly, thereby ensuring that the data on which the upper-layer application decision is based is highly reliable and consistent.

[0067] (4) The vehicle network traffic information consensus system provided by the present invention has the advantage of high throughput. Through the dual-stage dual-block mechanism, the consensus group efficiently produces two blocks (proposal block + confirmation block) in each round, which effectively improves the transaction processing speed of the system.

[0068] (5) The vehicle network traffic information consensus system provided by the present invention has enhanced security. The system is based on the Top 50% dynamic consensus group screening mechanism of “capacity × reputation”, which effectively resists Sybil attacks.

[0069] (6) The vehicle network road condition information consensus system provided by the present invention can quickly self-heal. The original reputation "amnesty" mechanism enables the system to restore its performance to normal level within one round after a large-scale attack causes a large number of nodes to lose their reputation, thus solving the pain point of slow recovery of traditional hybrid consensus.

[0070] (7) The vehicle network traffic information consensus system provided by the present invention adheres to the principle of fairness and introduces the calculation of effective capacity by the power of 0.6 of physical capacity, which avoids the monopoly of storage size and protects the participation rights of small and medium-sized nodes.

[0071] (8) The vehicle network traffic information consensus system provided by the present invention can significantly improve the stability and decision accuracy of the upper-level route planning system by providing reliable and consensus-based traffic data, avoiding path misjudgment and frequent replanning caused by data conflicts, thereby improving the user's navigation experience. Attached Figure Description

[0072] Figure 1 A consensus flowchart for the vehicle-to-everything (V2X) traffic information consensus system provided by this invention;

[0073] Figure 2 The flowchart of the route planning method based on a consensus system provided by this invention is shown below.

[0074] Figure 3 This is a schematic diagram of the reputation status of edge nodes in this invention;

[0075] Figure 4 This is a timing diagram of the road condition information consensus mechanism of the present invention;

[0076] Figure 5 A comparison chart of throughput for various consensus systems;

[0077] Figure 6 A throughput graph showing the percentage of different malicious nodes;

[0078] Figure 7 This is a dynamic self-healing ability test diagram. Detailed Implementation

[0079] To enable those skilled in the art to better understand the technical solution and advantages of the present invention, the present application will be described in detail below with reference to the accompanying drawings. It should be noted that the following embodiments are only used to explain the present invention and are not intended to limit the scope of protection of the present invention.

[0080] Example 1:

[0081] like Figure 1 , Figure 3 , Figure 4 As shown, the vehicle network traffic information consensus system provided in this embodiment combines a dynamic reputation evaluation system, a two-stage block generation process, and an adaptive recovery mechanism to achieve reliable sharing of vehicle network traffic information. Specifically, the vehicle network traffic information consensus system includes: a dynamic consensus group screening module, a first-stage competitive block generation module, a second-stage competitive block generation module, a two-stage differentiated reward module, and a reputation management and self-healing module.

[0082] The dynamic consensus group selection module is used to select a coordinator for the consensus process from edge nodes. The coordinator is either the winner of the previous round or the initial node. The consensus group is generated through dynamic election, rather than through blind competition across the entire network. The specific process is as follows:

[0083] Step A1. Startup and Staking:

[0084] At the start of each round, the coordinator broadcasts a message to open the staking window; edge nodes participating in the consensus across the entire network calculate their own comprehensive score (ComScore=C×R), where ComScore is the comprehensive score, C is the physical capacity, and R is the reputation value, and send a COMMIT_TO_MAIN message (nodes submit their comprehensive score of capacity and reputation to the coordinator) to the coordinator, while also submitting their staking space;

[0085] Step B2. Sort and filter the Top 50%:

[0086] The coordinator collects the submission information of all qualified edge nodes, excludes edge nodes in the double blacklist, sorts them by score from high to low, and selects the top 50% of edge nodes as the candidate pool.

[0087] To prevent the communication overhead caused by a large number of nodes on the consensus network, this embodiment adopts a logarithmic size constraint: ensuring the communication efficiency of the consensus system in ultra-large-scale networks, the final number of people in the consensus group K is not directly equal to 50% of the number of edge nodes, but is logarithmically constrained based on the total number of edge nodes N in the network.

[0088]

[0089] Finally, the coordinator selects the top K candidates from the candidate pool to form a consensus group, and broadcasts the final list of K consensus group members across the network.

[0090] In this embodiment, only members of the consensus group are qualified to produce blocks and publish traffic information that has been agreed upon.

[0091] The first-stage block-producing module is used to compete for the right to produce blocks and report traffic information based on effective capacity and reputation. The specific process is as follows:

[0092] Step A2. Calculate the effective capacity based on the physical capacity C;

[0093] In this embodiment, consensus group members (K members) compete for block production rights based on effective capacity and reputation. The effective capacity calculation employs a non-linear mapping method, which effectively prevents excessive concentration of storage resources leading to computing power monopoly, utilizing the diminishing marginal returns effect. Specifically, the effective capacity E and the physical capacity C have a non-linear power function relationship.

[0094]

[0095] This means that as physical capacity increases, the growth rate of effective block weight gradually slows down, thereby protecting the participation rights of small and medium-sized edge nodes.

[0096] Step B2. Perform capacity graph traversal and deadline calculation:

[0097] Edge nodes generate a challenge value based on the hash of the previous block, and then traverse the local capacity graph to find the best nonce that matches the challenge value. Finally, they combine the effective capacity E and the reputation value R to calculate the deadline.

[0098]

[0099] BaseTime is adjusted based on the network size. As the network size increases, the base time decreases dynamically. This process simulates the search for the optimal solution in the pre-generated capacity proof data. The shorter the deadline, the more likely the edge node is to obtain the right to produce blocks first.

[0100] Step C2. Broadcast the proposal:

[0101] The first edge node (Winner1) to traverse and retrieve a Nonce that meets the difficulty requirement and reaches the deadline broadcasts the Phase1 proposal (POC_BLOCK_PROPOSAL, a block proposal message under the proof-of-capacity consensus), which contains the transaction data of this round.

[0102] Step D2. Consensus Voting:

[0103] Other members of the consensus group verify the legality of the proposal; if legal, they send a signature vote; among them, Winner1 must collect more than 2 / 3 of the consensus group members (i.e., >2 / 3×K) of the signature votes for the block to be successfully verified.

[0104] Step E2. Block production:

[0105] After reaching a consensus, Winner1 broadcasts the Phase1 confirmation block message (BLOCK_CONFIRMATION).

[0106] The second phase, the block-producing module, is used to conduct another round of competition for block production and traffic reporting rights after excluding Winner1 from the first phase. Specifically, after excluding Winner1, the remaining K-1 consensus group members will compete again for PoC (Proof of Capacity) and basic capacity proof. The specific process is as follows:

[0107] To ensure security, each edge node uses the hash value (ProposalHash) of the Phase1 block as a new seed to recalculate the challenge value, and traverses and searches the capacity graph stored locally to find a new best random number (Nonce) that matches the challenge value. It then combines the effective capacity E and the reputation value R to calculate the deadline.

[0108] Subsequently, the edge node (Winner2) that first retrieves a Nonce that meets the difficulty requirement and reaches the deadline broadcasts the Phase2 proposal. This block serves as the final confirmation block for this round. Its data structure explicitly contains the hash value of the winning block of Phase1 and uses it as the parent hash, thereby cryptographically locking the traffic information content of Phase1, marking the network reaching a final consensus on this round.

[0109] Next, consensus voting: Consensus group members validate and vote on the Phase2 proposal. Winner2 must also collect signatures from more than 2 / 3 of the consensus group members (i.e., >2 / 3×K) for its proposed block to be successfully validated. Finally, after reaching consensus, Winner2 broadcasts the Phase2 confirmation block message (BLOCK_CONFIRMATION). Only after receiving the Phase2 block will all edge nodes in the network officially write the two blocks of this round into the ledger, thus completing the core process of the consensus system.

[0110] In this embodiment, if the Winner and the block-producing node do not receive more than 2 / 3 of the consensus group edge nodes' votes by the voting window time expires, the votes are discarded to ensure the security of the consensus and thus the reliability of real-time traffic information.

[0111] The dual-stage differentiated reward module is used to give different reputation rewards to the winners of the first-stage competitive block generation module and the second-stage competitive block generation module.

[0112] In this embodiment, a differentiated incentive model is designed to balance the contribution and risk of edge nodes at different stages. Phase 1 (first stage) has a fixed base reward. The winner of Phase 1 (Winner1) is responsible for packaging real-time traffic information and generating the first proposal block, undertaking the main computation, storage, and retrieval work. The reward formula is as follows:

[0113]

[0114] The base reward value BaseReward is 2, and Reward_P1 is the reward value for the winner of the first stage. It guarantees the basic income of the edge node that produces blocks and publishes real-time traffic information, covering its storage, maintenance and network broadcasting costs.

[0115] Phase 2 (the second stage) involves dynamic rewards based on capability matching. The winner of Phase 2 (Winner2) is responsible for the final confirmation of the Phase 1 block. To encourage mutual supervision among edge nodes of similar strength and to avoid security risks caused by smaller nodes blindly verifying larger nodes, this invention introduces a dynamic reward coefficient based on the effective capacity difference (CapacityDifference). The reward formula is as follows:

[0116]

[0117] Here, Reward_P2 represents the reward value for the winner of Phase 2, E_1 represents the effective capacity of the Phase 1 winner, and E_2 represents the effective capacity of the Phase 2 winner. When E_2 is close to E_1, the difference term approaches 0, maximizing the reward; when the effective capacities of the two are significantly different, the reward coefficient decreases. This mechanism fosters interactive verification relationships within the network, where large-capacity nodes tend to be verified by other large-capacity nodes, and small-capacity nodes tend to be verified by other small-capacity nodes. This not only improves verification efficiency (bandwidth and processing capacity matching) but also enhances the system's resistance to collusion.

[0118] The reputation management and self-healing module is used to manage the reputation values ​​of all edge nodes in the network and to achieve fault recovery based on the established two-layer blacklist-self-healing logic.

[0119] This embodiment establishes a dynamic reputation evaluation system based on historical behavior. Through a refined reward and punishment mechanism and an original "double-layer blacklist-self-healing" logic, it achieves rapid fault recovery of the system while ensuring security. It provides a solution for the reputation evaluation of edge nodes and can effectively reduce the impact of erroneous or malicious road condition data on subsequent path planning.

[0120] In this embodiment, a dynamic reputation scoring model is defined. The system maintains a global reputation table R, with an initial reputation value of 70.0 by default. Reputation value updates follow the principle of "additive growth, multiplicative decay." Honest behavior is rewarded: for edge nodes that successfully produce blocks and participate in valid voting, their reputation value increases linearly to incentivize long-term honest behavior. The reputation value update formula is as follows:

[0121]

[0122] Here, ΔR follows a normal distribution N(2.0, 0.5) with a mean of 2.0 and a standard deviation of 0.5. This random perturbation is introduced to prevent attackers from accurately predicting the reputation growth curve, thereby increasing the difficulty of "reputation boosting" attacks. R_old is the reputation value of the edge node in the previous state. If the edge node is a successful block-producing node, this value is the reputation value after adding the reward value. R_new is the updated reputation value.

[0123] Meanwhile, malicious behavior is penalized: for edge nodes detected to have engaged in malicious behavior such as double mining or malicious proposals, their reputation value is multiplicatively decayed, causing it to quickly fall below the threshold (60.0). The penalty value formula and reputation value update formula are as follows:

[0124]

[0125]

[0126] Where Penalty is the penalty value, CurrentRep is the current reputation value of the edge node, and Threshold is the reputation threshold. This formula ensures that the reputation of a malicious node immediately drops below the threshold (e.g., 59.0) after an attack, and it immediately loses its eligibility to run for the consensus group in the next round.

[0127] Furthermore, in this embodiment, to distinguish between disconnections caused by network jitter and deliberate attacks, a two-level blacklist mechanism is established, specifically including a temporary observation list (Level-1) and a permanent ban list (Level-2). The temporary observation list (Level-1) is triggered when the edge node's reputation value first falls below a threshold or exhibits minor anomalies (such as multiple timeouts). When Level-1 is triggered, the corresponding edge node is disqualified from participating in the consensus group election, and a recovery timer (e.g., 30 seconds) is activated. If there is no further malicious behavior during the observation period, the edge node can be removed from the temporary observation list and have some reputation restored. The permanent ban list (Level-2) is triggered when an edge node commits malicious acts again during Level-1, or is detected to be engaging in a serious consensus attack (such as signature forgery). When Level-2 is triggered, the corresponding edge node is permanently stripped of its network participation rights, its public key is marked invalid across the entire network, and it is no longer allowed to receive any messages from it. This measure protects the consensus of normal traffic information and reduces path planning jitter caused by malicious attacks.

[0128] Building upon this foundation, a global amnesty and self-healing logic is introduced. To address situations where large-scale DDoS attacks or network partitions could damage the reputation of numerous honest edge nodes (false positives), the system incorporates an amnesty self-healing mechanism. When the system detects that network throughput (TPS) has returned to normal or the proportion of malicious nodes has significantly decreased, and the average reputation falls below a set threshold, a global recovery event (REPUTATION_RECOVERY) is triggered. All edge nodes across the network execute the global amnesty protocol, iterating through their local edge node lists. For all edge nodes on the Level-1 list but not yet on the Level-2 list, their reputation values ​​are forcibly reset to 70.0 (the security baseline). This mechanism ensures that honest edge nodes, after experiencing large-scale network fluctuations, do not need a lengthy "climb" to accumulate reputation; instead, they are immediately revived in the next round (Roundn+1), regaining their eligibility to participate in the Top 50% consensus group election. This reduces the system's recovery time from a fault state to full-speed operation to the second level.

[0129] In this embodiment, the reputation value of the winner in both stages is updated based on the reward value output by the two-stage differentiated reward module. Then, the reputation value of the winner in both stages and the reputation value of the edge nodes of the entire network are further updated and managed based on the dynamic reputation scoring model.

[0130] Performance verification and comparison experiments:

[0131] To verify the vehicle network traffic information consensus system, this invention constructed a comparative experimental environment under the same hardware conditions, and ran the traffic data consensus system (DR-PoC) of this invention with standard PoG (Proof of Service), PoW (Proof of Work), PoC (Proof of Capacity) and PBFT (Efficient Byzantine Fault Tolerance).

[0132] 1. Throughput and scalability testing:

[0133] To verify the performance of this invention in large-scale networks, comparative tests were conducted in an environment where the node size N gradually increases from 16 to 256. Figure 5 As shown in the figure. Experimental results demonstrate that DR-PoC exhibits excellent scalability. With the increase in the number of nodes, the system throughput did not decrease; instead, it remained at [percentage missing]. The system operated smoothly at high levels above Transaction / Sec. This was thanks to the dynamic consensus group mechanism, which limited the consensus communication complexity to O(K). 2 This ensures that consensus efficiency is not diluted as the network size increases. Compared to other systems, it has a higher throughput capacity.

[0134] 2. Anti-malicious attack performance test:

[0135] To verify the security and robustness of the consensus system, this invention injected different proportions (10%, 20%, 30%) of malicious nodes into the network. These nodes performed malicious behaviors such as double-block production, silent attacks, and broadcasting invalid transactions. Experimental results are as follows: Figure 6 As shown: Low-proportion attacks (10%-20%): The throughput curve of the consensus system highly overlaps with the no-attack baseline (BaseDR-PoC), indicating that the two-layer blacklist mechanism of this invention can quickly identify and isolate a small number of malicious nodes, making them have almost no impact on the network. High-proportion attacks (30%): Even in the extreme environment where the proportion of malicious nodes reaches 30% (close to the Byzantine fault tolerance theory limit of 33%), the consensus system still shows amazing resilience. Although the throughput is lower than the baseline, it still remains stable at a high level of over 3500 TPS, with the decrease controlled within 15%. Comparative conclusion: Compared with traditional consensus systems where the throughput often plummets by 60% or even paralyzes under a 30% attack, this invention, with its "reputation veto" mechanism, ensures that malicious nodes cannot be continuously elected as consensus group members, thereby guaranteeing the efficient operation of the main chain. This result strongly demonstrates the high security of this invention in an open network environment.

[0136] 3. Dynamic self-healing ability test:

[0137] To verify the consensus system's resilience after a sudden large-scale attack, a dynamic environment lasting 3000 seconds was simulated. Figure 7As shown, the process is divided into three phases: the stable phase (0-1000s), the attack phase (1000s-2000s), and the recovery phase (2000s+). The stable phase occurs when the consensus system operates normally, with TPS fluctuating between 2000-6000, demonstrating the inherent random block generation characteristic of the PoC algorithm. The attack phase occurs when 35% of malicious nodes are suddenly injected at the 1000th second. Figure 7 As shown, the average throughput of the consensus system shows a noticeable decline, with frequent troughs below 2000 TPS, indicating that malicious nodes are interfering with consensus through denial-of-service or forks. However, due to the robustness of the algorithm, the system's throughput can still maintain a relatively good level during the attack period. Recovery Phase: The system's self-healing mechanism is triggered at 2000 seconds. Experimental curves show that TPS rebounds almost instantly (within 1-2 rounds), and the fluctuation range immediately returns to the normal level of 3000-5000, without the long "climbing recovery period" common in traditional reputation models. Conclusion: This result intuitively verifies the effectiveness of the "reputation amnesty" mechanism proposed in this invention, proving that the system can fully recover from a sub-healthy state to full-speed operation within seconds.

[0138] Example 2:

[0139] like Figure 2 As shown, this embodiment provides a route planning method based on a consensus system, which includes the following steps:

[0140] Step 1. On-board unit (OBU), roadside sensors, and pedestrian / non-motorized vehicle units collect dynamic traffic data in real time and send the collected raw road condition data to the nearest roadside unit (RSU, edge node).

[0141] Step 2. The Roadside Unit (RSU) acquires road condition information, completes identity verification and data preprocessing, and submits it to the authentication layer. The authentication layer reaches consensus based on the vehicle-to-everything (V2X) road condition information consensus system of Example 1. Other edge nodes (Roadside Units, RSUs) vote. When the consensus threshold is reached, the data is uploaded to the blockchain and a determined "road condition snapshot" is generated.

[0142] Step 3. Upload the generated and determined "road condition snapshot" to the application service layer to provide a unified and consensus-based "road condition snapshot" for the dynamic route planning module within the application service layer;

[0143] Step 4. The dynamic route planning module performs route planning based on the "road condition snapshot".

[0144] Furthermore, in this embodiment, the confirmed "road condition snapshot" can be used as a standard data interface, which the dynamic route planning module can directly call when performing route planning. Of course, other modules such as the hazard warning module within the application service layer can also directly call it, thereby ensuring that the data on which the upper-layer application makes decisions is highly reliable and consistent.

[0145] In this embodiment, the original road condition data uploaded by the on-board unit (OBU), pedestrian / non-motorized vehicle unit, etc., will be acquired by the nearest edge node. After the edge node acquires the original road condition data within a set time window, it packages the data into blocks and inputs them into the authentication layer. The vehicle network road condition information consensus system in the authentication layer reaches a state consensus on the real-time road condition in the area through processes such as proposal, verification, voting, sorting, and confirmation, and generates a determined "road condition state snapshot".

[0146] In this embodiment, the implementation environment is as follows: the number of network edge nodes N=100, the initial reputation value is 70.0, and the base block time (base time) is BaseTime=10s. When the network node scale increases, the base time decreases dynamically. The base time is inversely proportional to the network scale, simulating the actual situation that the block generation speed becomes faster and faster as the number of network nodes increases.

[0147] Furthermore, in this embodiment, the consensus process of the vehicle-to-everything (V2X) traffic information consensus system in step 2 is as follows:

[0148] Step 2.1. Select a coordinator for the consensus process based on whether it is the initialization phase; at the beginning of each round, the coordinator broadcasts a message to open the staking window, and all 100 edge nodes in the network calculate their own comprehensive scores and send a COMMIT_TO_MAIN message to the coordinator; after receiving the reply, the coordinator excludes the edge nodes in the double blacklist, sorts them from high to low scores, and selects the top 50% (50 nodes). Based on the logarithmic formula K=6×log2(100)≈40, the coordinator finally selects the top 40 from the 50 edge nodes to form a consensus group, and broadcasts the list through the TOP50_RESULTS (coordinator broadcasts the final consensus group member list) message.

[0149] Specifically, in this embodiment, if the current stage is the initialization stage, the initial node is used as the coordinator; if the current stage is not the initialization stage, the winner of the previous round is used as the coordinator.

[0150] Step 2.2. Phase 1 Minimum Deadline Competition:

[0151] After receiving the list, the 40 consensus members initiate a local PoC minimum deadline competition. Edge node A (high reputation, large capacity) generates a challenge value based on the hash of the previous block, quickly retrieves the best nonce from its local plot file, and calculates a shorter deadline T_deadline of 2.5 seconds. Edge node B (low reputation) has lower retrieval efficiency or insufficient computing power factor, resulting in a T_deadline of 8.0 seconds. Edge node A completes its retrieval first and reaches the deadline, packages the transactions to generate the Phase 1 proposal block, and broadcasts the POC_BLOCK_PROPOSAL message to the entire network.

[0152] Step 2.3. Phase 1 Confirmation and Stage Transition:

[0153] The remaining 39 consensus members receive the proposal block from edge node A and verify its legitimacy. After successful verification, they send a BLOCK_VALIDATION (signature vote sent by consensus members) message to edge node A. After edge node A collects 27 signatures (more than 2 / 3 × 40), it broadcasts the Phase 1 confirmation block. After all nodes in the network receive the confirmation, they automatically enter Phase 2.

[0154] Step 2.4. Phase 2 Double Confirmation:

[0155] The remaining 39 consensus group members (excluding edge node A) initiate the second round of PoC retrieval based on the Phase1 block hash; edge node C obtains the right to produce a Phase2 block and generates a Phase2 proposal that includes a reference to the block hash of edge node A; the consensus group votes again to confirm, and after reaching a consensus, broadcasts the final confirmed Phase2 block, completes the data on-chain, and generates a confirmed "road condition snapshot". This snapshot contains a unique, confirmed list of events and their attributes (such as event ID, type, precise location, confirmation timestamp, credibility, etc.).

[0156] Step 2.5. Reputation Settlement and Self-Healing:

[0157] All edge nodes write two blocks to the ledger. According to the differentiated reward formula, edge node A receives a fixed reward, and edge node C receives a dynamic reward matching the capacity of edge node A. Then, the reputation of all edge nodes is updated based on the dynamic reputation scoring model, and the temporary watch list Level-1 and the permanent ban list Level-2 are updated simultaneously. The average reputation is calculated. If the system detects that the network throughput (TPS) has returned to normal or the proportion of malicious nodes has dropped significantly, and the average reputation of the network is too low (below the set threshold), the system automatically triggers the REPUTATION_RECOVERY (reputation recovery message) signal, resetting the reputation of all edge nodes on the temporary watch list to 70.0, thus completing self-healing.

[0158] The present invention also provides an electronic device, comprising: one or more processors and a memory; wherein the memory is used to store one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement a route planning method based on a consensus system as described in Embodiment 2.

[0159] The present invention also provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a route planning method based on a consensus system as described in Embodiment 2.

[0160] Those skilled in the art will understand that all or part of the functions of the various methods / modules in the above embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, which may include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the above functions can be implemented by executing the program with a computer. For example, the program can be stored in the memory of a device, and when the program in the memory is executed by the processor, all or part of the above functions can be implemented.

[0161] In addition, when all or part of the functions in the above embodiments are implemented by computer programs, the programs can also be stored in storage media such as servers, other computers, disks, optical discs, flash drives, or portable hard drives. They can be downloaded or copied to the memory of the local device, or the system of the local device can be updated. When the program in the memory is executed by the processor, all or part of the functions in the above embodiments can be implemented.

[0162] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of protection described in the claims.

Claims

1. A vehicle-to-everything (V2X) traffic information consensus system, characterized in that: The system includes a dynamic consensus group selection module, a first-stage competitive block production module, a second-stage competitive block production module, a two-stage differentiated reward module, and a reputation management and self-healing module. The dynamic consensus group selection module is used to select a coordinator for the consensus process from edge nodes. The coordinator is either the winner of the previous round or the initial node. A consensus group is generated through dynamic election. During dynamic election, the top 50% of edge nodes in the comprehensive score are first selected as a candidate pool. Then, a logarithmic constraint is applied based on the total number of edge nodes N in the network to determine the number of consensus group members K. The first-stage competitive block generation module is used to compete for the right to generate blocks and report traffic information based on effective capacity and reputation. The second-stage competitive block production module is used to conduct another round of competition for block production and traffic reporting rights after excluding the winner of the first stage. The dual-stage differentiated reward module is used to give different reputation rewards to the winners of the first-stage competitive block generation module and the second-stage competitive block generation module. The winner of the first stage is given a fixed basic reward, while the winner of the second stage is given a dynamic reward based on ability. The reputation management and self-healing module is used to manage the reputation values ​​of all edge nodes in the network and to achieve fault recovery based on the established two-layer blacklist mechanism, global amnesty and self-healing logic.

2. The vehicle-to-everything (V2X) traffic information consensus system according to claim 1, characterized in that, The process by which the dynamic consensus group selection module dynamically elects consensus groups is as follows: Step A1. Startup and Staking: At the start of each round, the coordinator broadcasts a message to open the staking window; edge nodes participating in the consensus across the network calculate their own comprehensive score and submit a comprehensive score of capacity and reputation to the coordinator, while also submitting their staking space; The expression for the overall score is: ComScore = C × R; ComScore is the overall score, C is the physical capacity, and R is the reputation score. Step B2. Sort and filter the Top 50%: The coordinator collects the submission information of all qualified edge nodes, sorts them from highest to lowest score, and selects the top 50% of edge nodes as the candidate pool; a logarithmic constraint is applied based on the total number of edge nodes N in the network to determine the number of consensus group members. Then, the top K members are selected from the candidate pool to form a consensus group, which is then broadcast across the entire network.

3. The vehicle-to-everything (V2X) traffic information consensus system according to claim 1, characterized in that, The process of the first-stage block-generating module competing to generate blocks is as follows: Step A2. Calculate the effective capacity E based on the physical capacity C, wherein the effective capacity E has a non-linear power function relationship with the physical capacity C; Step B2. Perform capacity graph traversal and deadline calculation: Edge nodes generate challenge values ​​based on the hash of the previous block, traverse and search the capacity graph in local storage to find the best random number that matches the challenge value, and calculate the deadline by combining the effective capacity E and the reputation value R. Step C2. Broadcast the proposal: The first node that finds a random number that meets the difficulty requirement and reaches the deadline is the winner of the first stage, and the Phase 1 proposal is broadcast. Step D2. Consensus Voting: Other members of the consensus group verify the legality of the proposal; if legal, they send a signature vote; the winner of the first phase must collect more than 2 / 3 of the consensus group members' signature votes for the block to be successfully verified. Step E2. Block production: After reaching a consensus, the winner of the first phase broadcasts the Phase 1 confirmation block message.

4. The vehicle-to-everything (V2X) traffic information consensus system according to claim 1, characterized in that, The process of the second phase block-producing module is as follows: after excluding the winner of the first phase, the remaining K-1 consensus group members use the hash value of the Phase1 block as the new seed, recalculate the challenge value, and traverse and search the capacity graph stored locally to find a new best random number that matches the challenge value. The deadline is calculated by combining the effective capacity E and the reputation value R. Subsequently, the first edge node to traverse and retrieve a random number that meets the difficulty requirement and reaches the deadline becomes the winner of the second phase and broadcasts the Phase2 proposal; then, the consensus group members verify and vote on the Phase2 proposal. The winner of the second phase must also collect signatures from more than two-thirds of the consensus group members for the proposed block to be successfully verified; finally, after reaching a consensus, the winner of the second phase broadcasts the Phase 2 confirmation block message.

5. The vehicle-to-everything (V2X) traffic information consensus system according to claim 1, characterized in that, The dual-stage differentiated reward module provides a fixed base reward of 2 to the winner of the first stage; and a dynamic reward based on ability matching to the winner of the second stage, with the reward formula as follows: ； Where Reward_P2 is the reward value for the winner of the second phase, E_1 is the effective capacity of the winner of Phase 1, E_2 is the effective capacity of the winner of Phase 2, and the base reward value BaseReward is 2.

6. The vehicle-to-everything (V2X) traffic information consensus system according to claim 1, characterized in that, The reputation management and self-healing module rewards edge nodes that successfully produce blocks and participate in valid voting. The reputation value update process is as follows: ； Wherein, ΔR follows a normal distribution N(2.0,0.5) with a mean of 2.0 and a standard deviation of 0.5, R_old is the reputation value of the edge node in the previous state, and if the edge node is a successful block-producing node, then this value is the reputation value after adding the reward value, and R_new is the updated reputation value. Edge nodes detected to be producing double blocks or engaging in malicious behavior will be penalized, and the reputation value update process is as follows: ； ； Where Penalty is the penalty value, CurrentRep is the current reputation value of the edge node, and Threshold is the reputation threshold.

7. The vehicle-to-everything (V2X) traffic information consensus system according to claim 1, characterized in that, The reputation management and self-healing module establishes a two-tier blacklist mechanism and introduces global amnesty and self-healing logic. The two-tier blacklist includes a temporary observation list (Level-1) and a permanent ban list (Level-2). The trigger condition for the temporary observation list (Level-1) is that the reputation value of an edge node falls below a threshold for the first time. When Level-1 is triggered, the corresponding edge node will be disqualified from participating in the consensus group election, and a recovery time trigger will be initiated. If there is no further malicious behavior during the observation period, the edge node will be removed from the temporary observation list and its corresponding reputation will be restored. The trigger condition for the permanent ban list (Level-2) is that the edge node commits malicious acts or forges signatures again during the Level-1 period. When Level-2 is triggered, the corresponding edge node will be permanently deprived of its network participation rights. The global amnesty and self-healing logic is as follows: When the system detects that the network throughput has returned to normal or the proportion of malicious nodes has dropped beyond a set value, and the average reputation is lower than a set threshold, a global recovery event is triggered. All edge nodes in the network execute the global amnesty protocol, traverse the local edge node list, and for all edge nodes that are in the temporary observation list Level-1 but have not entered the permanent ban list Level-2, their reputation value is forcibly reset to the safety baseline, and they regain the qualification to participate in the Top 50% consensus group election in the next round.

8. The vehicle-to-everything (V2X) traffic information consensus system according to claim 3, characterized in that, The expression for the effective capacity E in step A2 is: ; The expression for the deadline in step B2 is: Where BaseTime is the base time.

9. A route planning method based on a consensus system, characterized in that, The method includes the following steps: Step 1. On-board unit (OBU), roadside sensors, and pedestrian / non-motorized vehicle units collect dynamic traffic data in real time and send the collected raw road condition data to the nearest roadside unit (RSU), i.e., edge node; Step 2. The Roadside Unit (RSU) acquires road condition information, completes identity verification and data preprocessing, and submits it to the authentication layer. The authentication layer reaches consensus based on the vehicle-to-everything (V2X) road condition information consensus system described in any one of claims 1 to 8. When the consensus threshold is reached, the data is uploaded to the blockchain, and a determined "road condition snapshot" is generated. Step 3. Upload the generated and determined "road condition snapshot" to the application service layer to provide a unified and consensus-based "road condition snapshot" for the dynamic route planning module within the application service layer; Step 4. The dynamic route planning module performs route planning based on the "road condition snapshot".

Images