Vehicle network system based on block chain hybrid consensus algorithm DTSP-PBFT

By introducing the DTSP-PBFT consensus algorithm, the problems of high communication load and node number limitation in vehicle networks are solved, achieving efficient communication and data security of the system, and improving the system's scalability and throughput.

CN121664433APending Publication Date: 2026-03-13SHAANXI SCI TECH UNIV
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-12
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

Existing blockchain consensus algorithms suffer from high communication load and node number limitations in vehicle network environments, making it difficult to meet the needs of large-scale networks.

Method used

The system adopts the blockchain hybrid consensus algorithm DTSP-PBFT, which introduces authoritative node election, distributed key distribution, committee consensus and multi-factor reputation update mechanism, and combines the competitiveness and reputation mechanism of PoW to reduce communication complexity and improve system activity.

Benefits of technology

It significantly reduces system communication overhead, improves scalability and throughput, ensures data authority and immutability, and enables incentives for node behavior and maintenance of system activity.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121664433A_ABST
    Figure CN121664433A_ABST
Patent Text Reader

Abstract

The invention discloses a vehicle network system based on a block chain hybrid consensus algorithm DTSP-PBFT. The vehicle network system comprises a main chain, a side chain, and a vehicle, an automobile manufacturer and a road side unit which are in communication connection. The main chain is constructed and maintained by an automobile manufacturer and is used for storing privacy data or hash values of vehicles; the side chain is constructed by a plurality of road side units and is used for processing a vehicle service request and performing identity authentication by adopting a DTSP-PBFT-based hybrid consensus algorithm; the vehicle carries a vehicle-mounted unit, interacts with the road side unit and the main chain through a dedicated short-range communication protocol, and participates in the network as a side chain light node; and the road side unit is used for communicating with the vehicle, forwarding the zero knowledge proof to the main chain, and executing the flow of the DTSP-PBFT-based hybrid consensus algorithm as a consensus node. According to the method, the communication overhead in the consensus process is effectively reduced, and remarkable effects are achieved in the aspects of expansibility, safety, system throughput rate and the like.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of vehicle network technology, and in particular to a vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT. Background Technology

[0002] Vehicle-to-everything (IoV), as an emerging technology supporting autonomous and intelligent driving, signifies the automotive industry's continuous transformation towards intelligence and connectivity. Vehicles, through integrated sensors, intelligent control systems, and wireless communication technologies, achieve five typical communication scenarios: vehicle-to-cloud communication, vehicle-to-vehicle communication, vehicle-to-infrastructure communication, vehicle-to-person communication, and in-vehicle communication. While bringing convenience to people's lives, IoV also raises privacy and security issues. For example, IoV services may collect sensitive information such as customer vehicle speed and location. If this data is leaked, malicious third parties could manipulate unsafe route planning services, potentially leading to traffic accidents. Blockchain technology, with its distributed ledger and immutability, is considered one solution to these problems.

[0003] However, mainstream blockchain consensus algorithms, such as Proof of Work (PoW), while offering high security, consume significant resources, making them unsuitable for the demands of IoT environments. Delegated Proof of Stake (DPoS) relies on token mechanisms, posing challenges to its deployment in IoT systems. While Practical Byzantine Fault Tolerance (PBFT) does not rely on computational power competition or require token mechanisms, its high communication complexity limits its capacity to a maximum of 100 nodes. This characteristic clashes with the large number of terminal nodes in connected vehicle environments.

[0004] Therefore, in recent years, the academic community has proposed a variety of solutions. Most of these solutions reduce the number of nodes participating in consensus through hierarchical architecture and reputation mechanisms, thereby improving system throughput to some extent. However, they still follow the original PBFT consensus process and fail to fundamentally solve the problem of high communication load in large-scale networks. Summary of the Invention

[0005] To address the technical problems existing in the prior art, this invention proposes a vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT, which achieves effective node behavior incentives and system activity maintenance.

[0006] To achieve the above objectives, this invention provides a vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT, comprising: Main chain, side chain, and communication connections for vehicles, automakers, and roadside units; The main chain is built and maintained by the car manufacturer and is used to store the vehicle's privacy data or hash values; The sidechain is constructed from several roadside units and is used to process vehicle service requests and identity authentication using a hybrid consensus algorithm based on DTSP-PBFT. The vehicle is equipped with an onboard unit that interacts with the roadside unit and the main chain via a dedicated short-range communication protocol, and participates in the network as a sidechain light node. The roadside unit is used to communicate with vehicles, forward zero-knowledge proofs to the main chain, and act as a consensus node to execute the process of a hybrid consensus algorithm based on DTSP-PBFT. The hybrid consensus algorithm based on DTSP-PBFT includes authoritative node election, distributed key distribution, committee consensus, multi-factor reputation update mechanism, and incentive strategy.

[0007] Preferably, the election of the authoritative node includes: Roadside unit nodes compete to become authoritative nodes by calculating hash values ​​and meeting certain conditions, where hash difficulty is inversely proportional to reputation value; The first e roadside units that find valid random numbers first form a consensus committee, where e ≥ 3f + 1, and f is the maximum number of Byzantine nodes allowed by the system.

[0008] Preferably, the hash value satisfies the following condition: ; In the formula, C i This represents the reputation value of node i. For hash value, For the target value, For version number, The hash value of the previous block. For timestamps, Difficulty level It is a random number.

[0009] Preferably, the distributed key distribution phase uses Verifiable secret sharing schemes include: Each authoritative node generates a random number and calculates the commitment value; Public key information is generated and broadcast using CL encryption and ElGamal encryption. Perform secret sharing and aggregate to form a master public key and private key share; Use zero-knowledge proofs to verify the validity of shares.

[0010] Preferably, the committee consensus includes: During the pre-prepare phase, the master node collects transactions and constructs blocks, broadcasting a Pre-Prepare message; During the preparation phase, the replica nodes partially sign the Pre-Prepare message and send it to the master node. The master node aggregates at least 2f+1 signatures and then broadcasts the threshold signature, where f is the maximum number of Byzantine nodes allowed by the system. During the commit phase, replica nodes decide whether to broadcast a commit message based on the flag bits in the threshold signature, and the master node re-aggregates and broadcasts the threshold signature; The flag bit is used to indicate whether to vote in favor or against. The threshold signature is valid and proceeds to the next stage; otherwise, the current consensus is terminated.

[0011] Preferably, the partial signatures and aggregate signatures in the committee consensus process are implemented based on a multi-party threshold signature protocol, which includes a partial signature protocol and an aggregate signature protocol, wherein the partial signature protocol includes: Each authoritative node encrypts the random value and generates a commitment; Calculate and exchange encrypted shares through homomorphic operations; After decrypting and verifying the validity of the share, a partial signature is generated. The aggregate signature protocol includes: The signature shares are committed to, zero-knowledge proofs are verified, and the complete signature is generated by aggregation.

[0012] Preferably, the multi-factor reputation update mechanism includes: Reputation value is updated based on node voting accuracy, online rate, and master node contribution rewards; The voting accuracy is calculated based on the number of correct, incorrect, and missing votes to determine the behavioral benefit. The online rate is used to calculate the online reward based on the ratio of the cumulative number of votes to the total number of blocks produced. The master node contribution reward provides additional rewards and introduces an exponential decay factor to periodically decay the reputation value.

[0013] Preferably, the incentive strategy includes: Transaction fees are allocated based on the authority node's reputation increment in the current era; The revenue of the authoritative node is as follows: ; In the formula, For nodes The gains in the kth generation, The total transaction fee in generation k. Let be the reputation value of node i in generation k+1. Let i be the reputation value of node i in generation k. Let j be the reputation value of node j in generation k+1. Let be the reputation value of node j in generation k, and e be the number of authoritative nodes.

[0014] Preferably, when the vehicle joins the network for the first time, it sends a zero-knowledge proof of privacy data to the roadside unit, and the roadside unit uses the DTSP-PBFT consensus algorithm to reach a consensus on the authentication result returned by the main chain.

[0015] Preferably, the communication overhead of the DTSP-PBFT consensus algorithm is: ; In the formula, M is the number of nodes participating in the consensus, and N is the total number of nodes.

[0016] Compared with the prior art, the present invention has the following advantages and technical effects: (1) By introducing an authoritative node election committee based on a reputation mechanism, this invention reduces the number of nodes participating in each round of consensus from the total number of nodes (N) in the network to a fixed-size committee (M), fundamentally changing the communication complexity, significantly reducing system communication overhead, and improving scalability and throughput. (2) This invention combines the competitiveness and reputation mechanism of PoW, making it easier for nodes with strong computing power and good historical behavior to become authoritative nodes, thereby improving the reliability of the consensus group from the source. While ensuring high security, it achieves effective node behavior incentives and system activity maintenance.

[0017] (3) This invention employs a main chain maintained by the automobile manufacturer and a side chain maintained by the roadside unit for division of labor and cooperation. The main chain uses the credibility of the manufacturer to store core vehicle privacy data, ensuring the authority and immutability of the data. The side chain handles high-frequency business transactions, realizing data diversion and efficient processing. Attached Figure Description

[0018] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of a vehicle network system structure based on the blockchain hybrid consensus algorithm DTSP-PBFT according to an embodiment of the present invention; Figure 2 This is a flowchart of the DTSP-PBFT algorithm according to an embodiment of the present invention. Detailed Implementation

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0021] This embodiment proposes a vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT, including: Main chain, side chain, and communication connections for vehicles, automakers, and roadside units; The main chain is built and maintained by the car manufacturer and is used to store the vehicle's privacy data or hash values; The sidechain is constructed from several roadside units and is used to process vehicle service requests and identity authentication using a hybrid consensus algorithm based on DTSP-PBFT. The vehicle is equipped with an onboard unit that interacts with the roadside unit and the main chain via a dedicated short-range communication protocol, and participates in the network as a sidechain light node. The roadside unit is used to communicate with vehicles, forward zero-knowledge proofs to the main chain, and act as a consensus node to execute the process of a hybrid consensus algorithm based on DTSP-PBFT. The hybrid consensus algorithm based on DTSP-PBFT includes authoritative node election, distributed key distribution, committee consensus, multi-factor reputation update mechanism, and incentive strategy.

[0022] Furthermore, the vehicle network system specifically includes (such as) Figure 1 ): Vehicle (VE): The vehicle is equipped with an onboard unit that supports a dedicated short-range communication protocol. When the vehicle in front detects an obstacle and brakes suddenly, it immediately notifies the following vehicle via DSRC. The following vehicle can receive the alert and react within 2 milliseconds. Before joining the network for the first time, the vehicle needs to send a zero-knowledge proof of its privacy data to the roadside unit in the sidechain for identity authentication. The vehicle has limited computing and storage capabilities and only acts as a light node in the sidechain, not participating in the consensus process.

[0023] Automakers (AM): Automakers are the builders of the main chain, and their main responsibilities include: (1) Before a vehicle leaves the factory, generate and store a unique digital identity and related privacy data (such as vehicle identification number VIN, fingerprint of core components, factory configuration, etc.) for each vehicle.

[0024] (2) Responsible for the operation of the main chain nodes, and using their inherent brand credibility and stable organizational structure to ensure the long-term stability and security of the main chain network.

[0025] (3) When a vehicle identity authentication request is received from the side link side unit, the vehicle manufacturer node completes the authoritative authentication of the vehicle identity and returns the result to the side link side unit.

[0026] Roadside Unit (RSU): The roadside unit is a key device in vehicle-to-everything (V2X) communication, typically installed on both sides of the road. Its main functions include: (1) Exchange data with the vehicle’s onboard unit.

[0027] (2) Real-time acquisition and transmission of information such as traffic flow, road conditions, and traffic signal status to help drivers make better decisions and improve traffic safety and efficiency.

[0028] (3) The roadside unit can be connected to the parking management system to provide real-time parking space information. When a car owner approaches a certain area, the system can guide the vehicle to find an empty parking space, avoid unnecessary cruising, and reduce traffic congestion caused by searching for parking spaces.

[0029] (4) Responsible for forwarding the zero-knowledge proof sent by the vehicle to the main chain.

[0030] (5) Perform TS-PBFT consensus on the authentication results returned by the main chain.

[0031] In the above system, only RSU participates in the DTSP-PBFT consensus process.

[0032] The core process of DTSP-PBFT is divided into six sub-stages (such as...) Figure 2 (1) RSU authority node election, (2) distributed key distribution protocol, (3) committee consensus, (4) multi-factor reputation update mechanism, and (5) incentive strategy.

[0033] Furthermore, the election of the authoritative node includes: Roadside unit nodes compete to become authoritative nodes by calculating hash values ​​and meeting certain conditions, where hash difficulty is inversely proportional to reputation value; The first e roadside units that find valid random numbers first form a consensus committee, where e ≥ 3f + 1, and f is the maximum number of Byzantine nodes allowed by the system.

[0034] Specifically, RSU nodes compete to become authoritative nodes through a PoW-like mining process. Mining difficulty is inversely proportional to a node's reputation value; nodes with higher reputation are more likely to win. The first node to find a random number that meets the conditions... Each RSU node becomes an RSU authority node and forms a consensus committee.

[0035] RSU authoritative nodes require strong computing power and high reputation scores. Therefore, we designed a PoW-like mining algorithm to select some nodes in the network as authoritative nodes. In this algorithm, the mining difficulty of node i is inversely proportional to its reputation score (the calculation of node reputation score is explained in Section 6). Specifically, node i will perform mining operations according to the following formula: ; In the formula, C i This represents the reputation value of node i. For hash value, For the target value, For version number, The hash value of the previous block. For timestamps, Difficulty level It is a random number.

[0036] The first to find the random numbers that meet the conditions A node wins the election and becomes the authoritative node. Assuming the IoT system allows no more than f Byzantine nodes, the number of authoritative nodes... This is to ensure that the system can still reach a consensus even in extreme situations.

[0037] Furthermore, the distributed key distribution phase uses Verifiable secret sharing schemes include: Each authoritative node generates a random number and calculates the commitment value; Public key information is generated and broadcast using CL encryption and ElGamal encryption. Perform secret sharing and aggregate to form a master public key and private key share; Use zero-knowledge proofs to verify the validity of shares.

[0038] Specifically, after completing the RSU authoritative node election, using The Verifiable Secret Sharing (VSS) scheme executes a distributed threshold signature protocol to achieve key distribution among RSU authoritative nodes, thereby providing support for subsequent threshold signature functions.

[0039] Based on the basic distributed key distribution protocol, distributed key distribution was completed among multiple RSU authoritative nodes. This protocol uses... Verifiable Secret Sharing (VSS) scheme and a commitment scheme.

[0040] First, each RSU authoritative node Choose a random number And calculate the points of the elliptic curve. Commitment value .

[0041] Subsequently, Generate CL encrypted key pairs ,in .Then, Refresh the key pair to get , .at the same time, It also generates an ElGamal encryption key pair. .

[0042] Next, Broadcast its public key information to other RSU authority nodes: , , and commitment value , Any RSU authoritative node can check whether the received public key satisfies the following conditions. and If the conditions are not met, the agreement will be terminated. Then, the commitment will be opened. get And aggregated to form the master public key .

[0043] after, Random numbers implement Verifiable Secret Sharing (VSS): Generating Polynomials Calculate the share and commitment value . Shares Send to RSU authoritative node and broadcast the commitment value .

[0044] Each RSU authoritative node Shares collected from other RSU authority nodes Then, add them together to get ,These This constitutes the master private key of Threshold secret shared share.

[0045] Finally, each RSU authoritative node A zero-knowledge proof needs to be generated. The protocol then broadcasts the proof. Any RSU authority node verifies the proof; if verification fails, the protocol aborts. The protocol ultimately outputs the master public key. And the private key share of each RSU authority node. All parties obtained Then, the appropriate Lagrange coefficients can be used to calculate... Addition shares as well as .

[0046] Furthermore, the committee consensus includes: During the pre-prepare phase, the master node collects transactions and constructs blocks, broadcasting a Pre-Prepare message; During the preparation phase, the replica nodes partially sign the Pre-Prepare message and send it to the master node. The master node aggregates at least 2f+1 signatures and then broadcasts the threshold signature, where f is the maximum number of Byzantine nodes allowed by the system. During the commit phase, replica nodes decide whether to broadcast a commit message based on the flag bits in the threshold signature, and the master node re-aggregates and broadcasts the threshold signature; The flag bit is used to indicate whether to vote in favor or against. The threshold signature is valid and proceeds to the next stage; otherwise, the current consensus is terminated.

[0047] Specifically, each RSU authority node takes turns becoming the master node in ascending order of its random number, while the remaining RSU authority nodes become replica nodes. The master node is responsible for initiating the prepare message. During the Prepare and Commit phases, replica nodes send partial threshold signatures of their prepare and commit messages to the master node, which aggregates and broadcasts them. Once a replica node receives a valid threshold signature, it can proceed to the next phase, significantly reducing communication overhead. If the master node engages in malicious behavior or crashes, the system will automatically switch to the node with the smallest random number difference that is greater than the current master node.

[0048] The committee consensus mechanism introduces the concept of a "generation." Each successful round of authoritative node election triggers a generation update. Furthermore, the priority order of an authoritative node as the master node within that generation is determined by the magnitude of the random number it generates. Assuming the message is m, and the authoritative node... The ordinary signature representation of message m is as follows To improve system activity, this embodiment introduces a timeout parameter. If the master node fails to respond within the specified time, the system will perform a view switch.

[0049] During the Pre-prepare phase, the master node The master node collects transactions from the transaction pool involving data exchange, behavior recording, or status updates of IoT devices and constructs a block. Broadcasting the Pre-Prepare message initiates the consensus process into the Prepare phase.

[0050] During the Prepare phase, replica nodes After receiving the Pre-Prepare message,<PREPARE,v,h,Hash(Block),flag> Perform a partial signature, setting `flag` to 1 to indicate a vote in favor and `flag` to 0 to indicate a vote against. Then, send the signed `Prepare` message to the master node. In this embodiment, it is assumed that at least Since all authoritative nodes are honest, the threshold signatures will eventually be successfully aggregated.

[0051] Master node Received replica node After receiving the Prepare message, the threshold counter `counts` is updated. When the master node collects `t` valid partial signatures from different replica nodes, it aggregates these `t` partial signatures into a complete threshold signature and broadcasts it. Replica nodes Upon receiving the aggregate signature from the master node, the replica node checks if the flag in the threshold signature is 1. If it is, the replica node broadcasts a Commit message and enters the Commit phase. Otherwise, the replica node stops processing any messages with that sequence number.

[0052] The Commit phase is exactly the same as the Prepare phase. The only difference is that when the master node... After sending the valid aggregate signature during the Commit phase, the votes given by the authoritative nodes and the final voting results are encapsulated in... This is stored in a set to facilitate subsequent updates to the node's reputation value. If a node is missing a vote in this round, the flag is set to -1. When a replica node... Upon receiving a valid aggregate signature during the Commit phase, it will expand the local blockchain, marking the end of a complete consensus process.

[0053] Furthermore, the partial signatures and aggregate signatures in the committee consensus process are implemented based on a multi-party threshold signature protocol, which includes a partial signature protocol and an aggregate signature protocol. The partial signature protocol includes: Each authoritative node encrypts the random value and generates a commitment; Calculate and exchange encrypted shares through homomorphic operations; After decrypting and verifying the validity of the share, a partial signature is generated. The aggregate signature protocol includes: The signature shares are committed to, zero-knowledge proofs are verified, and the complete signature is generated by aggregation.

[0054] Specifically, the partial signatures and aggregate signatures in the committee consensus process are implemented based on a multi-party threshold signature protocol, which can be divided into partial signature protocols and aggregate signature protocols. Symbols are used in this embodiment. and This represents a homomorphic operation, specifically defined as: for CL ciphertext , , and integers , , .

[0055] Partial Signature Agreement: First, each RSU authoritative node Perform the following operation: Select a random value random numbers .then, Using the CL encryption scheme on the public key Encryption Received the ciphertext .at the same time, value ( (Base point of elliptic curve) generates a commitment .also, Using the ElGamal encryption scheme in public key Encryption Received the ciphertext . Setting statement Subsequently, Broadcast commitment to all other RSU authority nodes CL ciphertext and ElGamal ciphertext , and attached a Proof of the Agreement to prove its statement Belongs to language (That is, to prove that the two ciphertexts encrypt the same message) If any participant's proof verification fails, the protocol is terminated.

[0056] Next, the RSU authoritative nodes interact with each other. For other RSU authoritative nodes Perform the following operations: Randomly select and calculate At the same time, select a random number. And calculate its modulus value , .then, Compute two new CL ciphertexts using homomorphic operations: and .at last, Will , , , , Send to After receiving the message, Use its CL private key Decrypt the ciphertext: and . Verify the equation Whether it is valid or not; if not, the agreement is terminated. Each Calculate its local share: and The value of broadcasting All RSU authoritative nodes jointly compute. .

[0057] Each RSU authoritative node Open its promise: Send and A zero-knowledge proof All RSU authoritative nodes verify the proof; if they fail, the process aborts. Next, each RSU authoritative node opens the commitment. Then, all RSU authority nodes compute... and calculate Each RSU authoritative node Calculate message hash Then calculate its signature share. .

[0058] Aggregate signature protocol: Each RSU authoritative node Select random number ,calculate and and make a commitment And one Zero-knowledge proof , broadcast , , .

[0059] All RSU authoritative nodes verify the received zero-knowledge proofs; if they fail, the process aborts. Next, the common value is computed. and Subsequently, calculate and and generate another commitment. . broadcast , and its signature share Then, verify. Check if the condition is true; if not, stop. Finally, calculate... .if If it is a valid signature, output the signature; otherwise, abort.

[0060] Furthermore, the multi-factor reputation update mechanism includes: Reputation value is updated based on node voting accuracy, online rate, and master node contribution rewards; The voting accuracy is calculated based on the number of correct, incorrect, and missing votes to determine the behavioral benefit. The online rate is used to calculate the online reward based on the ratio of the cumulative number of votes to the total number of blocks produced. The master node contribution reward provides additional rewards and introduces an exponential decay factor to periodically decay the reputation value.

[0061] Specifically, if the RSU authority node with the largest random number engages in malicious behavior or goes down, the system will dynamically update the reputation value of each RSU authority node based on factors such as its historical voting accuracy, online rate, and whether it serves as a master node in this "generation".

[0062] A node's reputation score is a crucial indicator for assessing its reliability and honesty, directly impacting its probability of being elected as an authoritative node. A multi-factor reputation update mechanism is employed, comprehensively considering factors such as voting accuracy, online stability, and contribution, to achieve precise quantification of node behavior. Let node... In the generation Reputation value ,in, and These are the lower and upper limits of the reputation value set by the system, respectively.

[0063] The reputation update model consists of the following steps: Voting accuracy: For each successful participation in a consensus round and correct vote, a node's reputation value increases by a fixed reward. If contradictory messages are sent, deduct the penalty. If no response is received within the timeout period, the penalty will be deducted. .node In the The benefit of voting accuracy in a generation can be expressed as ,in , and These represent nodes in the consensus mechanism. Number of correct, incorrect, and missing results.

[0064] Online rate: Record nodes In the The ratio of the cumulative number of votes to the total number of blocks produced in each generation is: .when At that time, node In the Online revenue in the generation .when hour, .

[0065] Master Node Contribution Reward: If a node acts as the master node in a given sequence number and successfully completes consensus, it will receive an additional reward. Define the master node indicator function: .

[0066] Reputation decay: To reflect a node's recent performance, an exponential decay factor is introduced. A node's reputation decays every time it experiences... Each generation decays once: .

[0067] Taking all the above factors into account, the node In the generation Reputation value at the end for: ; In the formula, and To adjust parameters, used to balance the impact of different behaviors on reputation score, This is the maximum reputation score. This is the lower limit of the reputation score. For nodes In the Benefits from improved voting accuracy in the generation For online revenue, For nodes In the The ratio of the cumulative number of votes in a generation to the total number of blocks produced. The primary node reward constant. This is the master node indicator function.

[0068] Furthermore, the incentive strategy includes: Transaction fees are allocated based on the authority node's reputation increment in the current era.

[0069] Specifically, after the reputation update, the accumulated transaction fees for that "generation" are distributed based on the reputation increment of each RSU authority node in that "generation," encouraging nodes to continue participating honestly.

[0070] Assuming an authoritative node In the The reputation value of the generation , No. The reputation value of each generation The system in the The total transaction fee for each agent is Considering that high-reputation nodes already possess a certain advantage during the committee election phase, no additional incentives will be provided specifically for high-reputation nodes in the incentive design. The profit can be calculated using the following formula: ; In the formula, For nodes The gains in the kth generation, The total transaction fee in generation k. Let be the reputation value of node i in generation k+1. Let i be the reputation value of node i in generation k. Let j be the reputation value of node j in generation k+1. Let be the reputation value of node j in generation k, and e be the number of authoritative nodes.

[0071] Specifically, authoritative nodes Benefits The rewards will be allocated based on the node's reputation increment in that generation, in order to achieve precise quantification and incentive of the node's behavior.

[0072] Furthermore, in the DTSP-PBFT consensus algorithm, due to the timeout mechanism of the master node, the master node typically has high communication capabilities. To simplify the analysis of the expected consensus time of DTSP-PBFT, each replica node other than the master node is assigned an independent and identically distributed random variable X when sending consensus messages, where X follows a uniform distribution of U(0,T).

[0073] In DTSP-PBFT, the time it takes for the master node to send the threshold signature message during the preparation phase can be represented as the t-th order statistic. According to order statistic theory, the expected value of the t-th order statistic for M independent and identically distributed U(0,T) random variables is: ; Therefore, the expected time for the master node to send the preparation phase threshold signature can be expressed as: ; Therefore, the expected time for reaching a consensus is: ; Without loss of generality, let M = 3f + 1 and N = 2M. Therefore, we can obtain the relationship between the expected time to reach consensus and the total number of nodes in the system, namely: .

[0074] The DTSP-PBFT algorithm requires only M=N / 2 nodes to participate in consensus, and it improves the preparation and commit phases of the consensus protocol. The communication overhead of the DTSP-PBFT algorithm during the network-wide node election process is M×(N-1), and the communication overhead during the committee consensus phase is as follows: ; It is worth noting that the election of the authoritative node and the distributed key distribution occur only once during committee rotation. In the long-term consensus process, the single-time overhead of these two parts can be approximated as negligible. Therefore, the main, continuous communication overhead of the DTSP-PBFT algorithm is dominated by the committee consensus phase, approximately T1.

[0075] The PBFT algorithm involves N-1 communications during the Pre-prepare phase, (N-1)² communications during the Prepare phase, N×(N-1) communications during the Commit phase, and N communications during the Reply phase. Therefore, the total communication overhead of the PBFT consensus algorithm is as follows: ; To demonstrate the superiority of this algorithm in consensus, Table 1 compares the total number of iterations required to achieve consensus by four algorithms: PBFT, Q-PBFT, APBFT, and CS-PBFT.

[0076] Table 1 This embodiment proposes a hybrid consensus algorithm, DTSP-PBFT, combining Proof-of-Work (PoW) and Personalized Power Flow (PBFT). This algorithm elects a subset of authoritative nodes through a mining process similar to PoW, with the mining difficulty inversely proportional to the node's reputation value. The elected authoritative nodes form a committee responsible for the consensus process, while ordinary nodes only update the consensus results reached by the committee and do not participate in the actual consensus decision-making. Furthermore, to address the high communication overhead during the Prepare and Commit phases of the original PBFT algorithm, this embodiment introduces a threshold signature scheme for improvement. Specifically, each replica node adds a flag bit to the messages sent during the prepare and commit phases: "1" represents a vote in favor, and "0" represents a vote against. Replica nodes no longer broadcast prepare and commit messages to the entire network but instead send them directly to the master node. When the master node receives at least 2f+1 messages of the same voting type, it aggregates these messages into a complete threshold signature and broadcasts it. Upon receiving a valid threshold signature, the replica node selects different operations based on the voting type in the threshold signature. If the flag is "0", the consensus is considered to have failed, and the replica node no longer processes messages under that sequence number. If the flag is "1", the process immediately proceeds to the next stage, effectively reducing communication overhead during the consensus process. This algorithm achieves significant results in terms of scalability, security, and system throughput.

[0077] The above are merely preferred embodiments of this application, but the scope of protection of this application 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 this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT, characterized in that, include: Main chain, side chain, and communication connections for vehicles, automakers, and roadside units; The main chain is built and maintained by the car manufacturer and is used to store the vehicle's privacy data or hash values; The sidechain is constructed from several roadside units and is used to process vehicle service requests and identity authentication using a hybrid consensus algorithm based on DTSP-PBFT. The vehicle is equipped with an onboard unit that interacts with the roadside unit and the main chain via a dedicated short-range communication protocol, and participates in the network as a sidechain light node. The roadside unit is used to communicate with vehicles, forward zero-knowledge proofs to the main chain, and act as a consensus node to execute the process of a hybrid consensus algorithm based on DTSP-PBFT. The hybrid consensus algorithm based on DTSP-PBFT includes authoritative node election, distributed key distribution, committee consensus, multi-factor reputation update mechanism, and incentive strategy.

2. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 1, characterized in that, The election of the authoritative node includes: Roadside unit nodes compete to become authoritative nodes by calculating hash values ​​and meeting certain conditions, where hash difficulty is inversely proportional to reputation value; The first e roadside units that find valid random numbers first form a consensus committee, where e ≥ 3f + 1, and f is the maximum number of Byzantine nodes allowed by the system.

3. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 2, characterized in that, The hash value satisfies the following condition: ; In the formula, C i This represents the reputation value of node i. For hash value, For the target value, For version number, The hash value of the previous block. For timestamps, Difficulty level It is a random number.

4. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 1, characterized in that, Used in the distributed key distribution phase Verifiable secret sharing schemes include: Each authoritative node generates a random number and calculates the commitment value; Public key information is generated and broadcast using CL encryption and ElGamal encryption. Perform secret sharing and aggregate to form a master public key and private key share; Use zero-knowledge proofs to verify the validity of shares.

5. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 1, characterized in that, The committee consensus includes: During the pre-prepare phase, the master node collects transactions and constructs blocks, broadcasting a Pre-Prepare message; During the preparation phase, the replica nodes partially sign the Pre-Prepare message and send it to the master node. The master node aggregates at least 2f+1 signatures and then broadcasts the threshold signature, where f is the maximum number of Byzantine nodes allowed by the system. During the commit phase, replica nodes decide whether to broadcast a commit message based on the flag bits in the threshold signature, and the master node re-aggregates and broadcasts the threshold signature; The flag bit is used to indicate whether to vote in favor or against. The threshold signature is valid and proceeds to the next stage; otherwise, the current consensus is terminated.

6. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 5, characterized in that, The partial signatures and aggregate signatures in the committee consensus process are implemented based on a multi-party threshold signature protocol. This multi-party threshold signature protocol includes a partial signature protocol and an aggregate signature protocol. The partial signature protocol includes: Each authoritative node encrypts the random value and generates a commitment; Calculate and exchange encrypted shares through homomorphic operations; After decrypting and verifying the validity of the share, a partial signature is generated. The aggregate signature protocol includes: The signature shares are committed to, zero-knowledge proofs are verified, and the complete signature is generated by aggregation.

7. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 1, characterized in that, The multi-factor reputation update mechanism includes: Reputation value is updated based on node voting accuracy, online rate, and master node contribution rewards; The voting accuracy is calculated based on the number of correct, incorrect, and missing votes to determine the behavioral benefit. The online rate is used to calculate the online reward based on the ratio of the cumulative number of votes to the total number of blocks produced. The master node contribution reward provides additional rewards and introduces an exponential decay factor to periodically decay the reputation value.

8. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 1, characterized in that, The incentive strategies include: Transaction fees are allocated based on the authority node's reputation increment in the current era; The revenue of the authoritative node is as follows: ; In the formula, For nodes The gains in the kth generation, The total transaction fee in generation k. Let be the reputation value of node i in generation k+1. Let i be the reputation value of node i in generation k. Let j be the reputation value of node j in generation k+1. Let be the reputation value of node j in generation k, and e be the number of authoritative nodes.

9. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 1, characterized in that, When a vehicle joins the network for the first time, it sends a zero-knowledge proof of its privacy data to the roadside unit, which then uses the DTSP-PBFT consensus algorithm to reach a consensus on the authentication result returned by the main chain.

10. The vehicle network system based on the blockchain hybrid consensus algorithm DTSP-PBFT according to claim 9, characterized in that, The communication overhead of the DTSP-PBFT consensus algorithm is: ; In the formula, M is the number of nodes participating in the consensus, and N is the total number of nodes.