A consensus method for internet of vehicles based on double-layer block chain

Abstract

This invention seeks protection for a consensus method for vehicle-to-everything (V2X) networks based on a two-layer blockchain, belonging to the field of V2X security technology. It includes: S1, constructing a two-layer architecture of a bottom-layer sharded chain and a top-layer main chain; S2, selecting vehicle nodes participating in the sharded chain consensus through a multi-dimensional consensus node election algorithm; S3, determining the sharded chain consensus master node using a hidden master node election mechanism; S4, completing consensus within the sharded chains using a practical Byzantine fault-tolerant algorithm; S5, the main chain adopts a directed acyclic graph consensus mechanism and introduces a dynamic verification quantity calculation model. The advantages of this invention are: (1) The multi-dimensional election algorithm selects high-quality nodes, improving consensus stability and security; (2) The layered architecture divides the V2X network into parallel consensus domains, with the bottom layer handling local consensus in parallel to reduce communication complexity, and the top layer coordinating cross-shard transactions to improve scalability; (3) The dynamic verification quantity calculation model adaptively adjusts the verification quantity according to network load, significantly improving system throughput.

Description

Technical Field

[0001] This invention relates to the field of vehicle network security technology, specifically a vehicle network consensus method based on a two-layer blockchain. Background Technology

[0002] With the development of intelligent transportation systems and autonomous driving technology, the Vehicle-to-Everything (V2X) network is gradually becoming an important component of future transportation systems. V2X enables traffic information sharing, collaborative driving, and intelligent traffic management through communication between vehicles, between vehicles and roadside infrastructure, and between vehicles and the network.

[0003] In the connected vehicle (V2V) environment, vehicle nodes continuously generate a large amount of traffic data, such as vehicle location, speed, direction of travel, and road condition information. This data needs to be shared in real time between vehicles and traffic infrastructure to support traffic management and safe driving. However, due to the characteristics of V2V, such as large node scale, frequent network topology changes, and complex communication environment, traditional centralized systems are unable to meet the security and efficiency requirements of the V2V environment.

[0004] Traditional vehicle-to-everything (V2X) systems typically rely on a central server for authentication and data management. This approach suffers from a significant single point of failure; if the central server is attacked or malfunctions, the entire system will cease to function properly. Furthermore, the centralized architecture makes the system vulnerable to malicious attacks, thus threatening the security of V2X data.

[0005] Blockchain technology, with its decentralized, immutable, and traceable characteristics, is widely used in the field of connected vehicle security. By introducing blockchain into connected vehicles, trusted data storage and distributed identity authentication can be achieved, thereby reducing reliance on centralized institutions. However, existing blockchain systems still face some challenges in connected vehicle environments.

[0006] First, traditional blockchain systems employ a single-chain structure, requiring all nodes to participate in the consensus process. As the number of nodes increases, the communication complexity of the consensus algorithm increases significantly, leading to a decrease in system throughput. Second, the common Byzantine Fault-Tolerant (PBFT) consensus algorithm suffers from high communication overhead with a large number of nodes, making it difficult to meet the high-concurrency transaction processing requirements of the connected vehicle environment. Furthermore, traditional consensus mechanisms lack optimizations for the characteristics of the connected vehicle environment in node selection, making them vulnerable to malicious node attacks and impacting system security. Additionally, in the traditional PBFT consensus mechanism, the master node is typically generated through rotation, a method that is easily predictable. Attackers can launch denial-of-service attacks against the master node, disrupting normal system operation. Therefore, a blockchain consensus method suitable for the connected vehicle environment is needed to improve system scalability, consensus efficiency, and security. Summary of the Invention

[0007] This invention addresses the aforementioned problems in existing technologies by proposing a high-efficiency consensus method for vehicle-to-everything (V2X) networks based on a two-layer blockchain. By constructing a layered blockchain architecture and optimizing the consensus node selection mechanism, it achieves secure and efficient data sharing in a V2X environment. The technical solution of this invention is as follows:

[0008] 1. A consensus method for vehicle-to-everything (V2X) networks based on a two-layer blockchain, characterized in that the consensus method for V2X networks based on a two-layer blockchain includes the following steps:

[0009] S1. Construct a two-layer blockchain architecture, including a bottom-layer shard chain and a top-layer main chain. The shard chains are divided according to the geographical location of the vehicle, and each shard is an independent consensus domain. The main chain is jointly maintained by high-reputation roadside units and trusted authorities (TAs).

[0010] S2, in the sharded chain, vehicle nodes participating in consensus are selected through a multi-dimensional consensus node election algorithm. The multi-dimensional factors include the vehicle's mobility stability, reputation value, communication connectivity, and hardware performance.

[0011] S3 employs a master node secret election mechanism based on a verifiable random function to determine the master node for each round of consensus during the sharded chain consensus process.

[0012] S4 employs a practical Byzantine fault-tolerant algorithm to achieve consensus within the sharded chain, completing the verification and confirmation of transactions within the shard;

[0013] S5, in the main chain, adopts a parallel consensus mechanism based on a directed acyclic graph and introduces a dynamic verification quantity calculation model. It dynamically adjusts the verification quantity of new blocks according to the network state, processes cross-shard transactions, and achieves consistency of the global ledger.

[0014] 2. The vehicle network consensus method based on a two-layer blockchain according to claim 1, characterized in that the multi-dimensional consensus node election algorithm in step S2 specifically includes:

[0015] S21, the transaction initiating node collects real-time information of the set of neighboring nodes within a certain communication range around it through a smart contract, including movement speed, direction, location distance, reputation value, available bandwidth, signal connection strength, computing speed and remaining storage capacity;

[0016] S22, Evaluate the mobility stability score of neighboring nodes according to the mobility stability calculation formula;

[0017] S23. Evaluate the comprehensive reputation value of neighboring nodes according to the reputation value calculation formula. The comprehensive reputation value is obtained by weighting the basic reputation value, behavioral reputation value and historical reputation value.

[0018] S24. Evaluate the communication connectivity of neighboring nodes according to the communication connectivity calculation formula, wherein the communication connectivity is obtained by weighting the available bandwidth, signal connection strength and communication delay.

[0019] S25, evaluate the hardware performance of neighboring nodes according to the hardware performance calculation formula, wherein the hardware performance is obtained by weighting computing power and remaining storage capacity;

[0020] S26, Set an initial threshold and filter out nodes that simultaneously meet all threshold conditions to form a candidate set;

[0021] S27. Dynamically adjust the threshold so that the size of the candidate set falls between the preset minimum number of consensus nodes and the maximum number of consensus nodes, thus obtaining the final consensus node set.

[0022] 3. The vehicle-to-everything (V2X) consensus method based on a two-layer blockchain according to claim 2, characterized in that the mobility stability calculation formula in step S22 is:

[0023]

[0024] in This represents the stability of the movement of vehicles around the node where the transaction occurred at time t. Its value ranges from (0,1), with values ​​closer to 1 indicating more stable future movement trends for both vehicles. It is the node where the transaction is generated. The nodes surrounding the node that generated the transaction are selected. Surrounding nodes, initially and The distance is negligible. and These represent the instantaneous velocity magnitudes of the transaction initiating node and its surrounding nodes at time t, respectively. and For each of their respective directions of motion, Let be the angle between the motions of the two, and in the denominator This represents the maximum speed allowed on the road, used to normalize the relative speed to the [0,1] interval; It is a positive adjustable parameter that controls the decay rate.

[0025] 4. The consensus method for vehicle networking based on a two-layer blockchain according to claim 1, characterized in that the master node covert election mechanism based on a verifiable random function in step S3 specifically includes: S31, selecting the hash value of the latest block in the transaction initiating node's account chain as a public random seed; S32, each node in the consensus node set uses its own private key to call the verifiable random function evaluation function to generate pseudo-random numbers and zero-knowledge proofs; S33, the node calculates the hash value of the pseudo-random number and compares it with a preset threshold. If the threshold condition is met, the node becomes a candidate master node; S34, the candidate master node broadcasts a verification message to all consensus nodes. The verification message includes a pseudo-random number, a zero-knowledge proof, a transaction identifier, a timestamp, and a node address; S35, the validity of the verification message received by the receiving node is verified, and the node that passes the verification is recorded as a valid candidate master node; S36, a waiting window is set, starting from the receipt of the first valid message. After the window ends, the candidate node with the smallest timestamp is selected as the master node for this round. If the timestamps are the same, the node with the highest reputation value is selected.

[0026] 5. The vehicle network consensus method based on a two-layer blockchain according to claim 4, wherein the threshold in step S33 is dynamically adjusted according to the number of consensus nodes, and the probability of having at least one candidate master node is not lower than a preset threshold; if no one is elected, the threshold is gradually reduced by step size until at least one node meets the condition.

[0027] 6. The vehicle network consensus method based on a two-layer blockchain according to claim 1, characterized in that the practical Byzantine fault-tolerant consensus algorithm of the sharded chain in step S4 includes a pre-preparation phase, a preparation phase, a commit phase, and a response phase, specifically including: S41, the master node assigns a view identifier and sequence number to the transaction to be processed and broadcasts a pre-preparation message to all slave nodes; S42, after receiving the pre-preparation message, the slave node verifies the signature and field validity, and broadcasts a preparation message after passing the verification; S43, after receiving the preparation message, the node verifies and caches it, and when the number of preparation messages for the same transaction reaches the fault tolerance threshold, it enters the commit phase and broadcasts a commit message; S44, when the number of commit messages for the same transaction reaches the fault tolerance threshold, it enters the response phase, and the slave node sends a response message to the master node; S45, the master node verifies the response message, and when the number of response messages for the same transaction with the same result reaches the commit threshold, it considers the result valid and writes the transaction into the blockchain.

[0028] 7. The vehicle network consensus method based on a two-layer blockchain according to claim 1, wherein the main chain parallel consensus mechanism based on a directed acyclic graph in step S5 specifically includes: S51, the main chain consensus node periodically collects transactions generated by the sharded chains and generates new directed acyclic graph transactions;

[0029] S52: Each new transaction selects a fixed number of transactions from all previous transactions that have not yet reached a consensus across the network for direct verification, and records the hash value of the selected transactions in its own transaction header;

[0030] S53 introduces a dynamic verification quantity calculation model, which dynamically adjusts the number of preceding transactions that need to be verified for a new transaction based on the network status.

[0031] S54. The verification of new transactions adopts a recursive tracing method, tracing back along the directed acyclic graph until a consensus block is encountered. If no conflict or invalid data is found during the entire tracing process, the new transaction is initially identified as legitimate.

[0032] S55: When the cumulative weight of a transaction reaches a certain threshold, the transaction finally reaches consensus.

[0033] 6. The vehicle network consensus method based on a two-layer blockchain according to claim 5, characterized in that the dynamic verification quantity calculation model in step S53 is:

[0034]

[0035] Where k is the number of historical transactions that need to be verified for the new transaction as initially calculated, k min The number of basic verifications, where T is the number of unconfirmed transactions in the current network. max R is the maximum number of unconfirmed transactions allowed by the network, and R is the current transaction generation rate. max α represents the maximum transaction generation rate of the network. k and β k The weighting coefficients ultimately yield the number of historical transactions that need to be verified.

[0036]

[0037] Where K final K represents the number of historical transactions that a new transaction ultimately needs to be verified. max This indicates the minimum security verification threshold preset by the system.

[0038] 9. A vehicle-to-everything (V2X) consensus system based on a two-layer blockchain, used to implement the method described in any one of claims 1-6, characterized in that it comprises: a trusted institution, at the highest trust level, responsible for the registration and verification of vehicles and roadside units, the issuance of digital certificates, and the allocation of initial reputation values; roadside units, including high-reputation roadside units and ordinary roadside units, wherein high-reputation roadside units participate in the dual consensus of the main chain and shard chains, and ordinary roadside units only participate in the consensus of the shard chains; vehicle nodes, as terminal entities participating in V2X interaction, wherein selected vehicles participate in the consensus of the shard chains according to a consensus node election algorithm based on moving speed, direction, location distance, etc.; a bottom-layer shard chain, jointly maintained by vehicle nodes and roadside units, storing local data and transaction records, and adopting a practical Byzantine fault-tolerant consensus algorithm based on verifiable random functions; and a top-layer main chain, maintained by high-reputation roadside units, adopting a parallel consensus mechanism based on a directed acyclic graph, and introducing a dynamic verification quantity calculation model to handle cross-shard transactions.

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

[0040] High scalability: Through a layered and sharded architecture, the large-scale vehicle network is divided into multiple independent consensus domains, and each shard executes consensus in parallel, reducing the overall network communication complexity.

[0041] High consensus efficiency: The sharded chain adopts a multi-dimensional node election mechanism to select high-performance nodes to participate in consensus, reducing the number of nodes participating in consensus; the main chain adopts a DAG parallel consensus mechanism and combines it with a dynamic verification number calculation model to adaptively adjust the verification number according to the network status, further improving transaction processing throughput.

[0042] High security: It adopts a master node covert election mechanism based on a verifiable random function to ensure the unpredictability of the master node and effectively prevent adaptive attacks against the master node; combined with node reputation value evaluation, it filters malicious nodes and enhances the security of the consensus process.

[0043] Strong adaptability: The multi-dimensional consensus node election algorithm comprehensively considers the vehicle's mobility stability, reputation value, communication connectivity, and hardware performance, enabling it to adapt to the highly dynamic environment of the Internet of Vehicles; the dynamic verification quantity calculation model enables the main chain consensus to automatically adjust according to network load and maintain efficient operation. Attached Figure Description

[0044] Figure 1 This is the overall system architecture diagram; Figure 2 This is a flowchart of the PBFT consensus process for sharded blockchains; Figure 3 This is a schematic diagram of the main chain DAG consensus; Detailed Implementation

[0045] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown 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 are only used to explain the present invention, and should not be construed as limiting the present invention.

[0046] This invention provides a consensus method for vehicle-to-everything (V2X) networks based on a two-layer blockchain, comprising the following steps:

[0047] S1 constructs a two-layer blockchain architecture, including a bottom-layer shard chain and a top-layer main chain. The shard chains are divided according to the geographical location of vehicles, and each shard is an independent consensus domain, jointly maintained by vehicles and roadside units within that region; the main chain is jointly maintained by high-reputation roadside units.

[0048] S2, in the sharded chain, a multi-dimensional consensus node election algorithm is used to select vehicle nodes to participate in the consensus. The multi-dimensional factors include the vehicle's mobility stability, reputation value, communication connectivity, and hardware performance.

[0049] S3 employs a master node secret election mechanism based on a verifiable random function to determine the master node for each round of consensus during the sharded chain consensus process.

[0050] S4 employs a practical Byzantine fault-tolerant algorithm to achieve consensus within the sharded chain, completing the verification and confirmation of transactions within the shard.

[0051] S5, in the main chain, adopts a parallel consensus mechanism based on a directed acyclic graph and introduces a dynamic verification quantity calculation model. It dynamically adjusts the verification quantity of new blocks according to the network state, processes cross-shard transactions, and achieves consistency of the global ledger.

[0052] Figure 1 The overall architecture of the system of this invention is described. As shown in the diagram, the system includes a Trusted Authority (TA), Roadside Units (RSUs), Vehicle Nodes (OBUs), and a two-layer blockchain structure: a bottom-layer shard chain (BC) and a top-layer main chain (TC). The Trusted Authority (TA) is at the highest trust level and is responsible for vehicle and RSU registration verification, digital certificate issuance, and initial reputation value allocation. Roadside Units are divided into high-reputation RSUs and ordinary RSUs. High-reputation RSUs participate in both the main chain and shard chains' consensus, while ordinary RSUs only participate in the shard chain consensus. Vehicle Nodes participate in the shard chain consensus after being selected according to an election algorithm. The bottom-layer shard chain is divided according to geographical location, and each shard operates independently; the top-layer main chain is maintained by high-reputation RSUs and is responsible for cross-shard transaction coordination.

[0053] Furthermore, the construction of the two-layer blockchain architecture in step S1 specifically includes:

[0054] First, the entire vehicle-to-everything (V2X) coverage area is divided into several sub-regions based on geographical location, with each sub-region serving as a shard. Within each shard, all registered vehicles and RSUs jointly maintain a shard chain (BC chain). The shard chain adopts a consortium blockchain format, and nodes must be registered and authorized by a TA (Task Authority) to join.

[0055] Secondly, RSUs with reputation values ​​above a threshold and strong computing and storage capabilities are selected from all shards as high-reputation RSUs. These high-reputation RSUs, together with TAs, constitute the consensus nodes of the top-level main chain (TC chain). The main chain adopts a private chain form, recording block summaries and transaction information of all shards.

[0056] Furthermore, the multi-dimensional consensus node election algorithm in step S2 specifically includes:

[0057] When the transaction initiating node When a transaction is required, the system uses a smart contract to collect a set S of neighboring nodes within a certain communication range. nei and obtain each neighbor node. Real-time information, including the speed and direction of movement of neighboring vehicle nodes and their spatial distance from the transaction initiating node, is used to evaluate the mobility stability of candidate nodes. Historical reputation values ​​of neighboring vehicles are also obtained to measure the node's trustworthiness. Furthermore, the available bandwidth resources of surrounding vehicles and their signal strength with the transaction initiating node are collected to calculate the node's communication connectivity. Finally, the hardware performance of the nodes is comprehensively evaluated by analyzing their computing power and remaining storage resources. Based on the above information, each candidate node is evaluated from four dimensions:

[0058] (1) The formula for calculating the motion stability is:

[0059]

[0060] in This represents the stability of the movement of vehicles around the node where the transaction occurred at time t. Its value ranges from (0,1), with values ​​closer to 1 indicating more stable future movement trends for both vehicles. It is the node where the transaction is generated. The nodes surrounding the node that generated the transaction are selected. Surrounding nodes, initially and The distance is negligible. and These represent the instantaneous velocity magnitudes of the transaction initiating node and its surrounding nodes at time t, respectively. and For each of their respective directions of motion, Let be the angle between the motions of the two, and in the denominator This represents the maximum speed allowed on the road, used to normalize the relative speed to the [0,1] interval; It is a positive adjustable parameter that controls the decay rate.

[0061] (2) Credit score calculation: Overall credit score E t i It is obtained by weighting three parts: basic reputation score, behavioral reputation score, and historical reputation score, and is calculated as follows:

[0062] Surrounding nodes Base reputation value at time t The calculation is as follows:

[0063]

[0064] Represents a node Online time within the time period (𝑡 − 𝜖, 𝑡); This indicates the maximum possible online time within that time period; Indicates the number of valid messages sent by the node. This represents the system-defined message reference value, and 𝜖 represents the system-defined time window parameter.

[0065] Behavioral reputation scores are used to monitor node behavior in real time and curb malicious attacks. At time 𝑡, the behavioral reputation value The calculation is as follows:

[0066]

[0067] This represents the number of good behaviors of node 𝑖, where This indicates the number of malicious actions performed by node 𝑖. This represents the total number of rows in node 𝑖. This represents the overall score given by other nodes to node 𝑖. This is the maximum score. These are weighting coefficients, typically... Index Term Used to punish malicious behavior The larger the value, the stronger the penalty. If a node sends multiple conflicting transactions in a short period of time, its reputation value will plummet.

[0068] node At any given moment, the overall reputation score for:

[0069]

[0070] in These are the weighting coefficients. This is the overall reputation score from the previous moment.

[0071] (3) Communication connectivity of surrounding nodes It consists of three weighted components, which respectively reflect the impact of bandwidth, signal strength and communication latency on consensus node election.

[0072] Bandwidth capacity contribution The calculation is as follows:

[0073]

[0074] Indicates vehicle The available bandwidth at time t, of which and These represent the maximum and minimum available bandwidth set by the system. The larger this value, the more abundant the currently available bandwidth of the node, which is beneficial for the transmission of large amounts of data during the consensus process.

[0075] In the Internet of Vehicles (IoV), nodes move at high speeds, resulting in significant fluctuations in signal strength. Poor signal quality at a node can easily lead to communication interruptions or increased bit error rates, affecting the reliable transmission of consensus messages. Selecting nodes with high signal strength can reduce the risk of communication interruptions and ensure the continuity and stability of the consensus process; therefore, it is necessary to consider this. and Signal connection strength. Contribution of signal connection strength. The calculation is as follows:

[0076]

[0077] Where S0 is the optimal signal threshold, k s The slope coefficient controls the steepness of the curve. For time t and The model effectively distinguishes between good and bad signal quality, avoiding frequent communication interruptions caused by signal fluctuations.

[0078] Low latency is crucial for achieving rapid consensus. In PBFT, nodes must wait for a sufficient number of responses before proceeding to the next phase; high-latency nodes slow down the entire system's response time. Selecting nodes with lower latency to participate in consensus reduces waiting time, improves consensus efficiency, and avoids the additional overhead caused by timeout retransmissions. Therefore, it is necessary to consider... and Communication delay. Delay contribution The calculation is as follows:

[0079]

[0080] express and The communication delay at time t, This is the attenuation coefficient. Ultimately, communication connectivity... We obtain the following by weighted summation:

[0081]

[0082] Among them, the weighting coefficient satisfy .

[0083] (4) Calculation Hardware performance of surrounding nodes Hardware performance at time 𝑡 It consists of two parts: computing power and storage capacity, and the calculation formula is as follows:

[0084]

[0085] in Let be the weighting coefficient, satisfying , Represents a node The calculation speed at time t This represents the highest theoretical computational speed for the system. Represents a node The remaining storage capacity at time t. This represents the maximum storage capacity of the system node.

[0086] After completing the calculations for each dimension, the system sets the initial threshold. (These correspond to initial screening thresholds for mobile stability, reputation score, communication connectivity, and hardware performance, respectively), and select those that simultaneously meet these criteria. This forms the candidate set 𝑆𝑐𝑎𝑛d. As mentioned earlier, the number of consensus nodes has a significant impact on both the efficiency and security of the consensus process. Therefore, two key parameters are set in the sharding mechanism: the maximum allowed number of consensus nodes. These two values ​​are predetermined by the system based on actual network conditions and operational experience. It is particularly important to note that in the PBFT consensus algorithm, the number of nodes participating in the consensus must be greater than four; otherwise, the fault tolerance requirement cannot be met. The value of should be no less than 4. The candidate set 𝑆𝑐𝑎𝑛d obtained after the aforementioned multi-dimensional screening. While the nodes in this set meet the quality requirements, their number may not fall within the preset range. , [Within]. Then check if the candidate set size is between the preset minimum number of nodes, *min*, and the preset maximum number of nodes, *max*. If the candidate set size is too small, it indicates the threshold is too high, and adjustments need to be made according to the step size. (These represent the magnitude of each adjustment to the thresholds for the four dimensions of mobility stability, reputation value, communication connectivity, and hardware performance.) Appropriately reduce each threshold, but not below the initial value. If the candidate set is too large, the threshold is too low. The threshold needs to be increased by the same time step and the candidate set needs to be re-selected. Repeat this adjustment until the size of the candidate set meets the requirements. At this point, the final node set 𝑆cons is the participating node in this consensus.

[0087] It is worth noting that when the node density is low, the number of selected nodes may never be reached, regardless of how the threshold is adjusted. The situation. Due to This directly relates to the security of the PBFT consensus. If the number of nodes remains below a certain threshold for an extended period, the security requirements of the consensus algorithm will not be met. To address this issue, nodes temporarily store currently generated transactions locally. Once the number of surrounding nodes increases and the minimum consensus node requirement is met, the transaction consensus will be re-initiated. Furthermore, to avoid the additional overhead of frequent consensus node selection, the smart contract checks the consensus node selection process each time the transaction initiating node sends a transaction. Check if there is a set of consensus nodes available nearby. If so, submit the transaction directly to that set of consensus nodes for consensus.

[0088] Furthermore, the master node covert election mechanism based on a verifiable random function in step S3 specifically includes: First, selecting the hash value of the latest block in the transaction initiating node's account chain as the public random seed seed = Hash(latest_block). The block hash value is determined by the consensus result of the previous stage, which attackers cannot predict in advance, ensuring the unpredictability of the seed. Then, the consensus node set S... consEach node in the consensus mechanism uses its private key to call the VRF evaluation function (r,π) = VRF(sk, seed), where sk is the node's private key, to generate a pseudo-random number r and a zero-knowledge proof π. The node then calculates h = Hash(r) and compares it with a preset threshold λ. If h / 2^L > λ, the node becomes a candidate master node, where L is the length of the hash function output. Since h is uniformly distributed on [0, 2^L), the probability of the above condition being true is 1-λ. The candidate master node broadcasts a verification message ⟨r, π, addr_tx, ts_tx, timestamp, addr> to all consensus nodes. addr_tx is the address of the node that initiated the transaction, ts_tx is the transaction timestamp, timestamp is the node's local timestamp (i.e., the local time when the candidate master node broadcast this message), and addr is the candidate master node's account address. The receiving nodes then verify the validity of the message: checking the matching of r and π, the validity of the signature, the threshold condition, and the validity of the transaction identifier. Nodes that pass the verification are recorded as valid candidate master nodes. The system sets a waiting window ΔT, which starts timing from the receipt of the first valid message. After the window expires, the node with the smallest timestamp among all verified candidate nodes is selected as the master node for this round. If multiple nodes have the same smallest timestamp, the node with the highest reputation value is further selected. The threshold λ is dynamically adjusted according to the number of consensus nodes to ensure that the probability of having at least one candidate master node is not less than 99%. If no one is elected, the threshold is gradually reduced by a step size, and the election process is repeated until at least one node meets the conditions.

[0089] Furthermore, the Byzantine fault-tolerant consensus algorithm used in step S4 specifically includes: such as Figure 2 As shown, after the master node is selected, the remaining nodes in the consensus node set participate in the subsequent voting process as slave nodes. The PBFT consensus of this scheme includes four stages: pre-preparation, preparation, commit, and response.

[0090] Pre-preparation phase: The master node assigns a view identifier ν and a sequence number σ to the transaction to be processed and broadcasts a pre-preparation message to all slave nodes. Upon receiving the message, slave nodes verify the signature and field validity; if successful, they enter the preparation phase. Preparation phase: Slave nodes broadcast preparation messages to the master node. Upon receiving a preparation message, a node verifies and caches it. When the number of preparation messages for the same transaction reaches K = 2·⌊(|S_cons|-1) / 3⌋+1, it enters the commit phase. Commit phase: Nodes broadcast commit messages. When the number of commit messages for the same transaction reaches K, it enters the response phase. Response phase: Slave nodes send response messages to the master node, containing the execution result. The master node verifies the response messages. When the number of response messages for the same transaction with the same result reaches L = ⌊(|S_cons|-1) / 3⌋+1, the master node considers the result valid and writes the transaction to the blockchain.

[0091] Furthermore, in step S5, the main chain uses a parallel consensus mechanism based on a directed acyclic graph, such as... Figure 3 As shown, it specifically includes:

[0092] The main chain consists of consensus nodes comprised of TAs and trusted RSUs, based on a Tangle distributed ledger consensus mechanism using a Directed Acyclic Graph (DAG). Unlike the chain structure of traditional blockchains, Tangle uses DAG as its underlying data structure, achieving high scalability and decentralized consensus. Each new transaction needs to verify multiple preceding transactions, and legitimacy is ensured through recursive tracing. This paper adjusts the blocks used for verifying each transaction based on the current system's transaction generation rate, improving the Tangle consensus mechanism and proposing the TDS consensus mechanism. This mechanism significantly improves system throughput while maintaining Byzantine fault tolerance, adapting to the massive and dynamic data sharing needs of the Internet of Vehicles. Figure 3 This demonstrates the organization of a transaction DAG. Assuming a system with six nodes, R, L, A, B, and C correspond to transactions generated by different nodes. The leftmost node represents the initial transaction, while R, L, and C represent consensus-reached transactions. The remaining nodes have not yet reached consensus. The core principle lies in building a distributed ledger that supports parallel processing without requiring a single-chain serial processing, through the verification relationships between transactions.

[0093] (1) Generation of DAG transactions: In the main chain, consensus nodes are responsible for generating transactions, and they periodically collect transactions generated by shard chains. For example... Figure 3 The DAG transaction verification structure shown requires each newly generated transaction to directly verify a certain number h transactions from all unverified preceding transactions. The new transaction records the hash values ​​of these selected transactions in its header, forming directed edges pointing to them. This mechanism means that each new block carries h links pointing to previous transactions, thus gradually weaving together the entire DAG transaction network of the vehicle network.

[0094] (2) Dynamic Verification Quantity Calculation Model: In the Tangle consensus process, if the number of preceding transactions required for verification of a new transaction is too small, the chances of old transactions being referenced decrease, and the confirmation speed slows down; conversely, if too many preceding transactions need to be verified for a newly generated transaction, the generation delay of a single transaction will increase, thereby affecting the overall throughput of the system. Therefore, this paper dynamically adjusts the verification quantity based on the network status. When there is a backlog of unconfirmed transactions, the verification quantity is appropriately increased to accelerate consensus; when transactions are active and the transaction generation rate is high, the system's processing capacity is improved by adjusting the verification quantity. To this end, the following dynamic verification quantity calculation model is proposed:

[0095]

[0096] Where k is the number of historical transactions that need to be verified for the new transaction as initially calculated, k min The number of basic verifications, where T is the number of unconfirmed transactions in the current network. max R is the maximum number of unconfirmed transactions allowed by the network, and R is the current transaction generation rate. max α is the maximum block generation rate of the network. k and β k These are the weighting coefficients. The final number of historical transactions to be verified is:

[0097]

[0098] Where K final K represents the number of historical transactions that a new transaction ultimately needs to be verified. max This represents the system's preset minimum security verification threshold. As the number of unconfirmed transactions in the network increases, This increases the number of new transactions verified, accelerating the clearing of unconfirmed transactions; when the transaction generation rate is high, The system increases the number of verifications required for new transactions, thereby enhancing its processing capacity. However, to prevent individual transactions from having excessively large verification scopes and to ensure system security, a maximum limit is set for the number of verifications.

[0099] (3) The process of achieving network consensus: In TDS, when each transaction is initiated by a node, h unverified blocks are first selected for verification using the Markov Chain Monte Carlo (MCMC) algorithm to check for conflicts such as double-spending transactions, thus ensuring the legality of the transaction. Subsequently, the node needs to perform lightweight proof-of-work for the transaction by finding a nonce to associate the transaction hash with the verified transaction data, thereby completing the transaction packaging. After completing the lightweight proof-of-work, the transaction is broadcast to the network. When the transaction is referenced and verified by enough subsequent transactions, and the accumulated weight reaches a set threshold, and no conflicts or invalid data are found during the recursive verification process, the transaction is finally confirmed by the network, and consensus is reached.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A consensus method for vehicle-to-everything (V2X) networks based on a two-layer blockchain, characterized in that, The vehicle-to-everything (V2X) consensus method based on a two-layer blockchain includes the following steps: S1. Construct a two-layer blockchain architecture, including a bottom-layer shard chain and a top-layer main chain. The shard chains are divided according to the geographical location of the vehicle, and each shard is an independent consensus domain. The main chain is jointly maintained by high-reputation roadside units and trusted authorities (TAs). S2, in the sharded chain, vehicle nodes participating in consensus are selected through a multi-dimensional consensus node election algorithm. The multi-dimensional factors include the vehicle's mobility stability, reputation value, communication connectivity, and hardware performance. S3 employs a master node secret election mechanism based on a verifiable random function to determine the master node for each round of consensus during the sharded chain consensus process. S4 employs a practical Byzantine fault-tolerant algorithm to achieve consensus within the sharded chain, completing the verification and confirmation of transactions within the shard; S5, in the main chain, adopts a parallel consensus mechanism based on a directed acyclic graph and introduces a dynamic verification quantity calculation model. It dynamically adjusts the verification quantity of new blocks according to the network state, processes cross-shard transactions, and achieves consistency of the global ledger.

2. The vehicle-to-everything (V2X) consensus method based on a two-layer blockchain according to claim 1, characterized in that, The multi-dimensional consensus node election algorithm in step S2 specifically includes: S21, the transaction initiating node collects real-time information of the set of neighboring nodes within a certain communication range around it through a smart contract, including movement speed, direction, location distance, reputation value, available bandwidth, signal connection strength, computing speed and remaining storage capacity; S22, Evaluate the mobility stability score of neighboring nodes according to the mobility stability calculation formula; S23. Evaluate the comprehensive reputation value of neighboring nodes according to the reputation value calculation formula. The comprehensive reputation value is obtained by weighting the basic reputation value, behavioral reputation value and historical reputation value. S24. Evaluate the communication connectivity of neighboring nodes according to the communication connectivity calculation formula, wherein the communication connectivity is obtained by weighting the available bandwidth, signal connection strength and communication delay. S25, evaluate the hardware performance of neighboring nodes according to the hardware performance calculation formula, wherein the hardware performance is obtained by weighting computing power and remaining storage capacity; S26, Set an initial threshold and filter out nodes that simultaneously meet all threshold conditions to form a candidate set; S27. Dynamically adjust the threshold so that the size of the candidate set falls between the preset minimum number of consensus nodes and the maximum number of consensus nodes, thus obtaining the final consensus node set.

3. The vehicle-to-everything (V2X) consensus method based on a two-layer blockchain according to claim 2, characterized in that, The formula for calculating motion stability in step S22 is as follows: ； in This represents the stability of the movement of vehicles around the node where the transaction occurred at time t. Its value ranges from (0,1), with values ​​closer to 1 indicating more stable future movement trends for both vehicles. It is the node where the transaction is generated. The nodes surrounding the node that generated the transaction are selected. Surrounding nodes, initially and The distance is negligible. and These represent the instantaneous velocity magnitudes of the transaction initiating node and its surrounding nodes at time t, respectively. and For each of their respective directions of motion, Let be the angle between the motions of the two, and in the denominator This represents the maximum speed allowed on the road, used to normalize the relative speed to the [0,1] interval; It is a positive adjustable parameter that controls the decay rate.

4. The vehicle-to-everything (V2X) consensus method based on a two-layer blockchain according to claim 1, characterized in that, The master node covert election mechanism based on a verifiable random function in step S3 specifically includes: S31, Select the hash value of the latest block in the transaction initiating node's account chain as the public random seed; S32, each node in the consensus node set uses its own private key to call a verifiable random function evaluation function to generate pseudo-random numbers and zero-knowledge proofs; S33, the node calculates the hash value of the pseudo-random number and compares it with a preset threshold. If the threshold condition is met, the node becomes a candidate master node. S34, the candidate master node broadcasts a verification message to all consensus nodes, the verification message containing a pseudo-random number, a zero-knowledge proof, a transaction identifier, a timestamp, and a node address; S35, Receive the node to verify the validity of the message, and the node that passes the verification is recorded as a valid candidate master node; S36, set a waiting window, start timing from the first valid message received, and after the window ends, select the candidate node with the smallest timestamp as the master node for this round. If the timestamps are the same, select the node with the highest reputation value.

5. The vehicle-to-everything (V2X) consensus method based on a two-layer blockchain according to claim 1, characterized in that, The main chain parallel consensus mechanism based on the directed acyclic graph in step S5 specifically includes: S51, the main chain consensus nodes periodically collect transactions generated by the shard chains and generate new directed acyclic graph transactions; S52: Each new transaction selects a fixed number of transactions from all previous transactions that have not yet reached a consensus across the network for direct verification, and records the hash value of the selected transactions in its own transaction header; S53 introduces a dynamic verification quantity calculation model, which dynamically adjusts the number of preceding transactions that need to be verified for a new transaction based on the network status. S54. The verification of new transactions adopts a recursive tracing method, tracing back along the directed acyclic graph until a transaction with consensus is encountered. If no conflict or invalid data is found during the entire tracing process, the new transaction is initially identified as legitimate. S55: When the cumulative weight of a transaction reaches a certain threshold, the transaction finally reaches consensus.

6. The vehicle-to-everything (V2X) consensus method based on a two-layer blockchain according to claim 5, characterized in that, The dynamic verification quantity calculation model in step S53 is as follows: ； Where k is the number of historical transactions that need to be verified for the new transaction as initially calculated, k min The number of basic verifications, where T is the number of unconfirmed transactions in the current network. max R is the maximum number of unconfirmed transactions allowed by the network, and R is the current transaction generation rate. max α represents the maximum transaction generation rate of the network. k and β k The weighting coefficients ultimately yield the number of historical transactions that need to be verified. ； Where K final K represents the number of historical transactions that a new transaction ultimately needs to be verified. max This indicates the minimum security verification threshold preset by the system.

7. A vehicle-to-everything (V2X) consensus system based on a two-layer blockchain, used to implement the method described in any one of claims 1-6, characterized in that, include: Trusted institutions, at the highest level of trust, are responsible for the registration and verification of vehicles and roadside units, the issuance of digital certificates, and the allocation of initial reputation values. Roadside units include high-reputation roadside units and ordinary roadside units. High-reputation roadside units participate in the dual consensus of the main chain and sharded chains, while ordinary roadside units only participate in the consensus of the sharded chains. Vehicle nodes, as terminal entities, participate in vehicle-to-everything (V2X) interactions. Based on a consensus node election algorithm established according to factors such as speed, direction, and distance, the selected vehicles participate in the consensus of the sharded chains. The underlying sharded chain is jointly maintained by vehicle nodes and roadside units, storing local data and transaction records, and adopts a practical Byzantine fault-tolerant consensus algorithm based on verifiable random functions; the top-level main chain is maintained by high-reputation roadside units, adopts a parallel consensus mechanism based on directed acyclic graphs, and introduces a dynamic verification quantity calculation model to handle cross-shard transactions.

Images