Blockchain-based multi-party cooperative vehicle-to-road communication security guarantee system and method

Abstract

The application belongs to the technical field of network communication, and discloses a multi-party cooperative vehicle-road communication security guarantee system and method based on a block chain; the method comprises the following steps: adding a miner card, an RSU and a control center into a block chain network, providing the miner card with a sensor, generating an identity certificate containing a public key hash by using ECC, generating an initial weight according to historical operation data, and selecting a high-weight miner card to give the network consensus qualification; collecting physical data after completing the operation, generating a work proof by zero-knowledge proof and hash, and calculating a weight distribution communication right; grouping according to a geographical area, taking the RSU as a leader, preferentially submitting a block by a high-weight person, and verifying a lightweight PBF variant; monitoring an anomaly by an intelligent contract, triggering verification, and adjusting the weight according to a communication task; and the application solves the problem of difficult verification of the physical device identity in the traditional scheme, improves the communication security, reduces the communication complexity, adapts to the frequent moving scene of the miner card, and improves the consensus efficiency.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and more specifically, to a blockchain-based multi-party collaborative vehicle-road communication security system and method. Background Technology

[0002] As vehicle-road cooperative technology develops towards intelligence and networking, the application of blockchain as a distributed trust infrastructure in vehicle-road communication faces multiple technical challenges.

[0003] Chinese patent application CN116132459A discloses a minimum-overhead node group construction and multi-block allocation mechanism for a blockchain system based on lightweight devices. It uses lightweight devices as nodes in the blockchain system, measures the upper limit of the data storage capacity of these nodes, and calculates the overhead of storing a unit of data. It also measures the geographical distance between nodes, calculates the communication overhead of transmitting data between nodes per unit distance, and calculates the query overhead of a node when querying data per unit of data. Furthermore, it statistically analyzes the blockchain used by the nodes, calculates the data size of each block in the blockchain, and associates different stability thresholds with each block based on the number of times a block is verified in the blockchain system. A mathematical model is constructed, and based on the optimization objective and constraints, a strategy is formulated to complete the construction of the node group and allocate blocks to the nodes in each node group. This invention controls the redundancy of each block in the node group by setting a block stability threshold, ensuring the integrity of the blockchain replicas in the node group while reducing unnecessary block redundancy and saving node resource overhead.

[0004] While the above methods can meet the needs of most scenarios, research and practical application of these methods and existing technologies have revealed at least the following shortcomings:

[0005] Traditional proof-of-work consensus relies on computing power competition, which consumes a lot of power resources and does not match the low power consumption requirements of mining cards in vehicle-to-everything (V2X) communication. Furthermore, consensus mechanisms such as PBFT have high communication complexity when the number of nodes changes dynamically, making them difficult to adapt to the scenario of frequent movement and offline operation of mining card nodes in V2X communication.

[0006] In view of this, the present invention proposes a blockchain-based multi-party collaborative vehicle-road communication security assurance system and method to solve the above problems. Summary of the Invention

[0007] To overcome the aforementioned deficiencies of the existing technology and to achieve the above objectives, the present invention provides the following technical solution: a blockchain-based multi-party collaborative vehicle-road communication security assurance method, comprising the following steps:

[0008] Mining cards are used as nodes and joined to the blockchain network along with RSU and control center. Each mining card is equipped with a corresponding sensor. A node identity certificate with embedded sensor public key hash and historical operation data is generated through ECC. An initial weight of the mining card is generated based on historical operation data and registration information. Mining cards with an initial weight higher than the minimum weight threshold are granted network consensus qualification.

[0009] After the mining card completes its operation cycle, the physical data of the mining card is collected, and verified by zero-knowledge proof in combination with public key hash. The verified physical data of the mining card is used to generate a proof of work through lightweight hash. The weight of the mining card is calculated based on the proof of work, and communication permissions are allocated according to the weight of the mining card.

[0010] Mining cards are grouped by geographical region, with RSU as the leader of each group. Alternate leaders are elected based on the weight of the mining cards. In each period, the mining card with the highest weight submits the block first, and other nodes verify it through PBFT. Verification nodes respond in a hierarchical manner according to the weight of the mining cards.

[0011] RSU monitors messages through smart contracts. If an anomaly is detected, it triggers zero-knowledge proof verification. Each time a mining card completes a valid communication task, it gains a trust increment, which is then used to adjust the mining card's weight.

[0012] Furthermore, methods for verification using zero-knowledge proofs in conjunction with public-key hashing include:

[0013] The mining card is required to provide the original mining card physical data F;

[0014] Calculate the hash h of the original mining card physical data F ;

[0015] The mining card's public key (PK) is pre-attached to the blockchain, along with its corresponding hash (h). PK Embedded node identity certificate;

[0016] Verification of data compliance, identity authenticity, and time validity. F and h PK Whether they come from the same legitimate node;

[0017] Methods for generating proof-of-work using lightweight hashing include:

[0018] The verified physical data D of the mining card is serialized and compressed to obtain Dn;

[0019] Perform a first hash and a second hash on the mining card ID, Dn, mining card private key signature, and timestamp;

[0020] By adjusting the random number, find the quadratic hash value where the first e bits are 0 that meets the condition;

[0021] Verify that the second hash value satisfies the condition that the first e bits are 0, and verify that the timestamp is within a preset reasonable range; use the mining card public key to verify that the signature is correct.

[0022] After successful verification, a cryptographic hash value generated from D, mining card ID, timestamp, and random number hash is obtained as proof of work.

[0023] Furthermore, methods for calculating mining card weights based on proof-of-work include:

[0024] Based on the task type preset priority of the control center, the task priority is dynamically adjusted according to the task objectives and historical risks to obtain the task urgency.

[0025] The time decay factor is calculated based on the interval between the task completion time and the current time, combined with the decay coefficient.

[0026] The weight of the mining card is obtained by weighting the task urgency and time decay factor.

[0027] Furthermore, methods for grouping mining cards by geographical region include:

[0028] Taking the mining operation area as a whole, virtual geographic grids are divided into M×M grids. Each grid is defined with a unique grid ID and records the boundary latitude and longitude and the corresponding unique RSU; where M is the number of rows of virtual geographic grids.

[0029] The grid ID, boundary latitude and longitude, and RSU are hashed and uploaded to the blockchain via smart contract to form shards;

[0030] The real-time coordinates of the mining card are obtained. The RSU calls the Voronoi diagram algorithm to calculate the nearest neighbor of the mining card to each RSU and determine the shard to which the mining card belongs.

[0031] Furthermore, the methods for adjusting the weight of mining cards include:

[0032] The system detects the execution status of mining truck commands, calculates the completion score based on preset execution requirements, and obtains the job completion rate.

[0033] The system detects the response speed, calculates the speed score based on preset response requirements, and statistically obtains the response speed score.

[0034] The system checks the data quality of mining cards, calculates a quality score based on preset quality requirements, and statistically obtains the data quality score.

[0035] Detect violations by mining cards, calculate violation scores based on preset behavioral requirements, and obtain a violation quality score.

[0036] Trust increments are calculated by weighting scores based on task completion, response speed, data quality, and violation quality.

[0037] The current trust value is dynamically adjusted by combining the decay factor that decays over time with the trust value of the previous period and the trust increment.

[0038] Based on the current trust value, the updated mining card weight is obtained by combining the Sigmoid function, the trust threshold, and the mining card weight update of the previous cycle.

[0039] Furthermore, if an anomaly is detected, the methods for triggering zero-knowledge proof verification include:

[0040] The mining card is required to provide raw sensor data; if the verification is successful, the mining card's trust value is increased and the mining card's weight is updated; otherwise, the mining card's trust value is deducted and the leader node's consensus participation right is suspended.

[0041] Furthermore, methods for generating node identity certificates via ECC include:

[0042] Pre-select a standard elliptic curve and define a finite field and a base point G, where the order of the base point is n;

[0043] The mining card or RSU node is located locally, and a private key d is randomly selected, where d∈[1,n-1].

[0044] Calculate the public key 0 using scalar multiplication based on the private key and the base point;

[0045] Bind the public key Q to the node's physical identifier to generate an identity tuple;

[0046] The identity tuple is hashed and uploaded to the blockchain via a smart contract to obtain the node identity certificate.

[0047] Furthermore, the methods for generating the initial weights of mining cards include:

[0048] The equipment reputation is obtained by calculating the historical total fault-free duration, total operating time, number of compliant operations, and total number of operations of mining trucks over the past N days, and weighting the data according to the sub-item weights.

[0049] Obtain the task type of sub-tasks in a single task; calculate the value of a single task based on the preset type value; adjust the value of a single task based on the quality coefficient of the single task to obtain the adjusted value; calculate the total adjusted value of all single tasks in the past N days based on the adjusted value, and use it as the task base.

[0050] The initial weight of the mining card is obtained by weighting the equipment reputation and the number of operations.

[0051] Furthermore, the methods for verification via PBFT include:

[0052] RSU selects the top k miners each period based on their weights to form a consensus committee. k is calculated based on the average weight of the shard, a preset upper limit, and the sum of the weights of all miners in the shard, and k satisfies preset conditions.

[0053] The mining card submits a request to the RSU containing proof of work;

[0054] RSU merges L mining card requests into a single block, broadcasts the block to the consensus committee, and broadcasts the block to the validator nodes through the shard leader relay. RSU sends a heartbeat packet every cycle. If there is no response for U consecutive times, a leader election is triggered, and the standby leader takes over according to the mining card weight order.

[0055] The verification node only sends data to the RSU and its two adjacent nodes;

[0056] After the RSU aggregate signature is broadcast once across the entire network, the verification node performs local verification.

[0057] When the number of nodes that refuse consensus exceeds the number of Byzantine nodes, zero-knowledge proof verification is triggered. If the first verification fails, the mining card weight is reduced. If the verification fails B times in a row, the mining card weight is reset.

[0058] Nodes with mining card weights below the minimum weight threshold are automatically downgraded to light nodes, and backup nodes with weights above the minimum weight threshold are selected in descending order of weight to replace them; among them, light nodes that submit valid proof of work within V consecutive periods are automatically restored to validator nodes.

[0059] If an RSU monitoring verification node does not respond for T consecutive cycles, it is determined to be offline, and a backup node with a weight higher than the lowest weight threshold is selected in descending order of weight to replace it.

[0060] The blockchain-based multi-party collaborative vehicle-road communication security system, implementing the aforementioned blockchain-based multi-party collaborative vehicle-road communication security method, includes:

[0061] Node registration module: The mining card is used as a node and joins the blockchain network with the RSU and control center. Each mining card is equipped with a corresponding sensor. The node identity certificate is generated by ECC with embedded sensor public key hash and historical operation data. The initial weight of the mining card is generated based on the historical operation data and registration information. Mining cards with initial weights higher than the minimum weight threshold are granted network consensus qualifications.

[0062] Consensus Anchoring Module: After the mining card completes its operation cycle, the module collects the mining card's physical data, verifies it using zero-knowledge proof in combination with the public key hash, generates a proof of work for the verified mining card's physical data using lightweight hash, calculates the mining card's weight based on the proof of work, and allocates communication permissions according to the mining card's weight.

[0063] Collaborative communication module: The mining cards are grouped by geographical region, with RSU as the leader of each group. An alternate leader is elected based on the weight of the mining cards. In each period, the mining card with the highest weight submits the block first, and other nodes are verified by PBFT. The verification nodes respond in a hierarchical manner according to the weight of the mining cards.

[0064] Trust Update Module: RSU monitors message patterns through smart contracts. If an anomaly is detected, it triggers zero-knowledge proof verification. Each time a mining card completes a valid communication task, it gains a trust increment, which is then used to adjust the mining card's weight.

[0065] The technical effects and advantages of the blockchain-based multi-party collaborative vehicle-road communication security assurance system and method of this invention are as follows:

[0066] This invention generates node identity certificates with embedded public key hashes and historical job data using ECC, and verifies the authenticity of physical data using zero-knowledge proofs. This ensures node identity and data trustworthiness from the source, solving the problem of difficult verification of physical device identity in traditional solutions and improving communication security. It generates proof-of-work from mining card physical data using lightweight hashing, replacing computational power competition with physical contributions, reducing energy consumption and matching the low-power requirements of mining cards. A dynamic weighting mechanism integrates job urgency, time decay factors, and multi-dimensional behavioral scores, updating weights in real time using the Sigmoid function to achieve accurate assessment of node trustworthiness. This solves the problem of static or singular weights in traditional consensus mechanisms, allowing high-value nodes to obtain communication permissions first and reducing invalid computational power competition. Geographic grouping combined with the Voronoi diagram algorithm dynamically divides shards, with the RSU acting as the leader to aggregate blocks and verify them through PBFT, reducing communication complexity, adapting to scenarios with frequent mining card movement, and improving consensus efficiency. Attached Figure Description

[0067] Figure 1 This is a schematic diagram of the blockchain-based multi-party collaborative vehicle-road communication security assurance method according to Embodiment 1 of the present invention;

[0068] Figure 2 This is a schematic diagram of the data flow in Embodiment 1 of the present invention;

[0069] Figure 3 This is a schematic diagram of the method flow of Embodiment 2 of the present invention;

[0070] Figure 4 This is a schematic diagram of the structure of the blockchain-based multi-party collaborative vehicle-road communication security system according to Embodiment 3 of the present invention. Detailed Implementation

[0071] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] Example 1:

[0073] Please see Figure 1 , Figure 2 As shown, this embodiment provides a blockchain-based multi-party collaborative vehicle-road communication security assurance method, including the following steps:

[0074] Mining trucks (mining trucks, or mining trucks for short) are used as nodes and joined to the blockchain network along with RSUs (Roadside Units) and the control center. Each mining truck is equipped with a corresponding sensor and generates a node identity certificate through ECC. The certificate embeds the sensor's public key hash and historical operation data. An initial weight of the mining truck is generated based on the historical operation data and registration information. Mining trucks with an initial weight higher than the minimum weight threshold are selected to be granted network consensus qualifications. The minimum weight threshold is dynamically adjusted according to the network load. For example, the threshold is lowered during peak periods to absorb more verification nodes.

[0075] Methods for generating node identity certificates via ECC include:

[0076] Pre-select a standard elliptic curve and define a finite field and a base point G, where the order of the base point is n;

[0077] The mining card or RSU node is located locally, and a private key d is randomly selected, where d∈[1,n-1].

[0078] The public key Q is calculated using scalar multiplication based on the private key and the base point;

[0079] Bind the public key Q to the node physical identifier to generate an identity tuple, where the node physical identifier includes the mining card ID, RSU ID, sensor public key hash, and historical operation data, etc.

[0080] The identity tuple is hashed and uploaded to the blockchain via a smart contract to obtain the node identity certificate.

[0081] When nodes communicate, they verify their identities using an elliptic curve digital signature algorithm.

[0082] The signature generation method is as follows:

[0083] Calculate the hash h for the message;

[0084] Randomly select a temporary private key j∈[1,n-1], and use scalar multiplication to calculate the temporary public key R based on j and G;

[0085] Take the x-axis coordinate modulus 'a' of R as the random factor r;

[0086] Calculate the modular inverse J of j, and combine J, h, d, and r to generate the signature s.

[0087] The signature verification method is as follows:

[0088] Recalculate the hash H of the message and verify whether r and s are within the valid range, that is, verify whether r, s∈[1, n-1];

[0089] Calculate the inverse module S of s, and convert H and r into temporary factors associated with s based on S;

[0090] Reconstruct the temporary public key P using the public key Q, the temporary factor, and G;

[0091] To verify the signature, we need to check if the modulus a of the x-coordinate of P is equal to r. If the private key d matches the public key Q = d × G, then P = R, and its modulus a of the x-coordinate is equal to r.

[0092] The private key of the mining card is used to sign communication data, while the public key of the mining card is written into the blockchain as an identity identifier.

[0093] The above method leverages the high security and low computational complexity of elliptic curve cryptography to avoid the high energy consumption problem of traditional PoW computing power competition, thus adapting to the low power consumption requirements of mining cards. Simultaneously, based on the fast verification mechanism of on-chain identity certificates, nodes can quickly regain their consensus participation eligibility through lightweight signature verification when rejoining after dynamic movement or offline. Combined with the immutable nature of on-chain identity tuple hashing, this reduces the communication overhead caused by node authentication in PBFT consensus, improves consensus efficiency in scenarios with dynamic node changes, and effectively solves the energy consumption and communication complexity problems of traditional consensus mechanisms in vehicle-to-everything (V2X) communication.

[0094] Methods for generating the initial weight of mining cards include:

[0095] The historical total fault-free duration, total operating time, number of compliant operations, and total number of operations of mining trucks over the past N days are statistically analyzed. The equipment reputation is obtained by weighting the sub-items according to their respective weights, which are defined based on the actual mining area safety strategy.

[0096] Obtain the task type of the sub-task in a single job, calculate the value of the single job based on the preset type value, and adjust the value of the single job based on the quality coefficient of the single job to obtain the adjusted value; calculate the total adjusted value of all single jobs in the past N days based on the adjusted value, and use it as the job base; where the quality coefficient is obtained based on the compliance of the job, such as +10% for on-time completion and -30% for overload.

[0097] The initial weight of the mining card is obtained by weighting equipment reputation and operating base. The weighting coefficient is determined by domain experts and the needs of the mining area scenario. For example, the weight of operating base is increased in areas with intensive operations to give priority to incentivizing production capacity, and the weight of equipment reputation is increased in areas with severe equipment aging to ensure safety.

[0098] The above method deeply binds the historical performance and reliability of mining cards with the actual needs of the mining area, accurately assesses the initial trust value of nodes, and avoids the resource waste and inefficiency caused by single or static evaluation of node weights in traditional consensus mechanisms. By selecting mining cards with greater reliability and contribution potential to participate in consensus through initial weight selection, it reduces the ineffective computing power competition of low-value nodes, reduces energy consumption, and dynamically adjusts the qualifications of consensus nodes according to weights. This effectively addresses dynamic scenarios such as frequent movement and offline of mining cards, optimizes the communication complexity of consensus mechanisms such as PBFT, and improves the security and efficiency of vehicle-to-everything (V2X) communication systems.

[0099] After the mining card completes its operation cycle, the physical data of the mining card is collected, and verified by zero-knowledge proof in combination with public key hash. The verified physical data of the mining card is used to generate a proof of work through lightweight hash. The weight of the mining card is calculated based on the proof of work, and communication permissions are allocated according to the weight of the mining card.

[0100] By collecting physical data from the mining card's operational cycle and using public-key hashing with zero-knowledge proofs to verify the data's authenticity and compliance, the system avoids forged data from participating in consensus. Lightweight hashing is then used to generate proof-of-work bound to physical jobs, replacing traditional computing power competition with physical job contributions. This significantly reduces energy consumption and matches the low-power characteristics of mining cards. Dynamic weights are calculated based on the proof-of-work, and communication permissions are allocated according to these weights. This allows high-weight mining cards to have priority access to communication resources and consensus participation, reducing the number of consensus nodes and invalid communication. It also optimizes the communication complexity of consensus mechanisms like PBFT in scenarios with frequent node movement and offline operation, achieving a closed loop of "trustworthy physical data - dynamic weight adjustment - optimized communication efficiency." This effectively solves the problems of high energy consumption and poor dynamic adaptability in traditional consensus mechanisms.

[0101] Methods for verification using zero-knowledge proofs in conjunction with public-key hashing include:

[0102] The mining card is required to provide the original mining card physical data F;

[0103] Calculate the hash h of the original mining card physical data F ;

[0104] The mining card's public key (PK) is pre-attached to the blockchain, along with its corresponding hash (h). PK Embedded node identity certificate;

[0105] Verification of data compliance, identity authenticity, and time validity. F and h PK Whether they come from the same legitimate node.

[0106] Methods for generating proof-of-work using lightweight hashing include:

[0107] The verified physical data D of the mining card is serialized and compressed to obtain Dn;

[0108] Perform a first hash and a second hash on the mining card ID, Dn, mining card private key signature, and timestamp;

[0109] By adjusting the random number, find the quadratic hash value where the first e bits are 0 that meets the condition;

[0110] Verify that the second hash value satisfies the condition that the first e bits are 0 (e is much lower than Bitcoin's 64 bits, such as 4 or 8), verify that the timestamp is within a preset reasonable range, and verify that the signature is correct using the mining card's public key.

[0111] After successful verification, a cryptographic hash value generated from D, mining card ID, timestamp, and random number hash is obtained as proof of work.

[0112] By requesting the mining card to provide the original physical data F of the mining card and calculating the hash h F Combined with the hash h of the on-chain public key PK PK Embedded identity certificates verify data compliance, identity authenticity, and time validity. F with h PK This paper presents a zero-knowledge proof method to determine whether data originates from the same legitimate node. It also describes a proof-of-work generation scheme that uses a lightweight double hash of the mining card ID, Dn, private key signature, and timestamp after serializing and compressing the verification data D. By adjusting the random number to make the first e bits of the secondary hash value zero (far lower than the traditional 64-bit Bitcoin hash), this scheme effectively solves the technical problems of high energy consumption due to computational power competition in traditional proof-of-work, which is incompatible with the low power consumption requirements of mining cards. Furthermore, it addresses the high communication complexity of consensus mechanisms like PBFT when nodes are dynamically changing. The method combines physical data with zero-knowledge proofs to achieve real-data verification. It generates proof-of-work by binding physical jobs with low-difficulty hashes to reduce energy consumption. By combining trusted physical data verification, lightweight hash algorithms, and dynamic weighting mechanisms, it optimizes communication efficiency through lightweight consensus in dynamic node scenarios.

[0113] Methods for calculating mining card weights based on proof-of-work include:

[0114] Based on the task type preset priority of the control center, the task priority is dynamically adjusted according to the task objectives and historical risks to obtain the task urgency.

[0115] The time decay factor is calculated based on the interval between the task completion time and the current time, combined with the decay coefficient, where the decay coefficient is set according to the scenario.

[0116] The weight of a mining card is determined by weighting the urgency of the task and the time decay factor; the weighting is determined based on the actual operation strategy of the mining area.

[0117] The above method effectively solves the technical problems of the mismatch between the high energy consumption of traditional Proof-of-Work and the low power consumption requirements of mining cards, as well as the difficulty of consensus mechanisms such as PBFT in adapting to frequent movement and offline scenarios of mining cards. It integrates the actual needs and time effects of the job into the weight calculation, avoiding the resource waste and inefficiency caused by the fixed weights in traditional consensus mechanisms. It enables the weight of the mining card to reflect the importance and timeliness of the job in real time, giving priority to mining cards corresponding to high-urgency jobs higher communication permissions and consensus participation qualifications, reducing invalid computing power competition and communication overhead, thereby reducing energy consumption and improving consensus efficiency in scenarios with dynamic node changes.

[0118] Mining cards are grouped by geographical region, with each group led by the RSU (Resource Unit). A backup leader is elected based on the mining card's weight. The backup leader is selected from the top A mining cards according to their weight. Within each cycle, the mining card with the highest weight submits blocks first, and other nodes verify them via PBFT (Power-Only Graph). Verifying nodes respond according to their weight; high-weight nodes must send signatures to the RSU and neighboring nodes, while low-weight nodes only need to verify locally and respond to the RSU. Nodes with a rejection rate exceeding 30% during the verification phase are penalized. These steps effectively address the mismatch between the high energy consumption of traditional Proof-of-Work (PoW) and the low power consumption requirements of mining cards, as well as the high communication complexity of consensus mechanisms like PBFT in scenarios with dynamic node changes. Geographical grouping reduces cross-regional communication overhead, weighted hierarchical response optimizes node collaboration efficiency, prioritizing high-weight mining cards improves consensus reliability, and the dynamic penalty mechanism ensures compliant node behavior. This reduces computing power consumption and improves the system's robustness and efficiency in scenarios with frequent mining card movement and offline scenarios through hierarchical collaboration and adaptive penalties.

[0119] Methods for grouping mining cards by geographical region include:

[0120] Taking the mining operation area as a whole, virtual geographic grids are divided into M×M grids. Each grid is defined with a unique grid ID and records the boundary latitude and longitude and the corresponding unique RSU; where M is the number of rows of virtual geographic grids.

[0121] The grid ID, boundary latitude and longitude, and RSU are hashed and uploaded to the blockchain via smart contract to form shards;

[0122] Obtain the real-time coordinates of the mining card, and the RSU calls the Voronoi diagram algorithm to calculate the nearest neighbor of the mining card to each RSU and determine the shard to which the mining card should belong.

[0123] When the weight of a mining card is greater than the minimum weight threshold, it is qualified to be a validator node; otherwise, it is a light node by default.

[0124] The total number of nodes in each shard does not exceed the total number threshold, which is calculated based on the lowest weight threshold.

[0125] The above method divides a large-scale network into local autonomous units through geographical sharding, reducing cross-regional communication and lowering the global communication complexity of PBFT consensus. The Voronoi diagram algorithm adapts to the mobile characteristics of mining cards, ensuring the real-time and accuracy of dynamic node affiliation. The weight threshold and total number of nodes limit mechanism selects high-value nodes to participate in consensus, avoiding ineffective computing power competition from low-weight nodes. This not only matches the low power consumption requirements of mining cards, but also optimizes communication efficiency in scenarios with frequent node movement and offline scenarios through lightweight consensus within shards, effectively solving the problems of high energy consumption and poor dynamic adaptability of traditional consensus mechanisms.

[0126] Methods for verification via PBFT include:

[0127] RSU selects the top k miners each period based on their weights to form a consensus committee. k is calculated based on the average weight of the shard, a preset upper limit, and the sum of the weights of all miners in the shard, and k satisfies preset conditions.

[0128] The mining card submits a request to the RSU containing proof of work;

[0129] RSU merges L mining card requests into a single block, broadcasts the block to the consensus committee, and broadcasts the block to the validator nodes through the shard leader relay. RSU sends a heartbeat packet every cycle. If there is no response for U consecutive times, a leader election is triggered, and the standby leader takes over according to the mining card weight order.

[0130] The verification node only sends data to the RSU and its two adjacent nodes;

[0131] After the RSU aggregate signature is broadcast once across the network, the verification node performs local verification.

[0132] When the number of nodes that refuse consensus is greater than the number of Byzantine nodes, zero-knowledge proof verification is triggered. If the first verification fails, the mining card weight is reduced. If the verification fails B times in a row, the mining card weight is reset.

[0133] Nodes with mining card weights below the minimum weight threshold are automatically downgraded to light nodes, and backup nodes with weights above the minimum weight threshold are selected in descending order of weight to replace them; among them, light nodes that submit valid proof of work within V consecutive periods are automatically restored to validator nodes.

[0134] If an RSU monitoring verification node does not respond for T consecutive cycles, it is determined to be offline, and a backup node with a weight higher than the lowest weight threshold is selected in descending order of weight to replace it.

[0135] The above method significantly reduces the communication complexity of PBFT consensus by dynamically adjusting the scale of consensus nodes, optimizing block broadcast paths, and limiting the communication range, making it suitable for scenarios where mining cards move frequently and are offline. At the same time, it selects high-value nodes to participate in consensus based on weights, avoiding ineffective computing power competition from low-weight nodes. It also reduces computational consumption by combining lightweight hashing and zero-knowledge proofs, matching the low power consumption requirements of mining cards, and effectively solving the problems of high energy consumption in traditional proof-of-work and poor dynamic adaptability of PBFT.

[0136] RSU monitors messages via smart contracts. If an anomaly is detected, it triggers zero-knowledge proof verification. Each time a mining card completes a valid communication operation, it gains a trust increment, which is used to adjust the mining card's weight. RSU utilizes smart contracts to monitor messages in real time. Upon detecting anomalies, it immediately triggers zero-knowledge proof verification to ensure data authenticity and compliant node behavior. Simultaneously, it grants trust increments based on the mining card's valid communication operations and dynamically adjusts the mining card's weight accordingly. This mechanism, through proactive anomaly detection and lightweight verification, promptly intercepts malicious data and attacks, preventing consensus failures and communication chaos caused by malicious node behavior. The linkage between trust increments and weight adjustments incentivizes mining cards to continuously provide high-quality communication services. The weight dynamically reflects the node's credibility and contribution, prioritizing communication permissions and consensus qualifications for high-trust nodes, reducing the ineffective participation of low-value nodes, optimizing the communication efficiency of consensus mechanisms such as PBFT, reducing energy consumption caused by traditional computing power competition, and effectively solving the problems of poor security, high energy consumption, and uncontrollable node behavior in traditional consensus mechanisms under dynamic communication scenarios.

[0137] Methods for adjusting mining card weights include:

[0138] The system detects the execution status of mining truck commands, calculates the completion score based on preset execution requirements, and obtains the job completion rate.

[0139] The system detects the response speed, calculates the speed score based on preset response requirements, and statistically obtains the response speed score.

[0140] The system checks the quality of mining card data, calculates a quality score based on preset quality requirements, and statistically obtains the data quality score.

[0141] Detect violations by mining cards, calculate violation scores based on preset behavioral requirements, and obtain a violation quality score.

[0142] Trust increment is obtained by weighting scores based on task completion, response speed, data quality, and violation quality. The weighting is based on expert experience and scenario analysis.

[0143] The current trust value is dynamically adjusted by combining a decay factor that decays over time (initially 1, decaying over time, such as 5% per hour), the trust value of the previous period, and the trust increment.

[0144] Based on the current trust value, the updated mining card weight is obtained by combining the Sigmoid function, the trust threshold, and the mining card weight update of the previous cycle.

[0145] The above methods effectively address the mismatch between the high energy consumption of traditional Proof-of-Work (PoW) and the low power consumption requirements of mining cards, as well as the difficulty of consensus mechanisms such as PBFT in adapting to frequent node movement and offline scenarios. A multi-dimensional real-time evaluation mechanism accurately reflects the behavior of mining cards, and dynamic weight adjustment prioritizes high-value nodes in consensus, reducing ineffective computing power competition and lowering energy consumption. The attenuation factor avoids long-term interference from historical data, improving the system's response speed to node state changes. The Sigmoid function smooths the weight update process, enhancing system stability and optimizing PBFT communication complexity, achieving a dual optimization of low power consumption and high dynamic adaptability.

[0146] If an anomaly is detected, the methods that trigger zero-knowledge proof verification include:

[0147] The mining card is required to provide raw sensor data; if the verification is successful, the mining card's trust value is increased and the mining card's weight is updated; otherwise, the mining card's trust value is deducted and the leader node's consensus participation right is suspended.

[0148] When an anomaly is detected, zero-knowledge proof verification is triggered, forcing the mining card to provide raw sensor data for verification. If the verification passes, the trust value is increased and the weight is updated in real time, incentivizing the mining card to maintain data authenticity and behavioral compliance. If the verification fails, the trust value is deducted and the consensus participation right of the leader node is suspended, promptly isolating potentially malicious or faulty nodes. This mechanism responds quickly to anomalies with a lightweight verification method, avoiding traditional high-energy-consuming verification methods and matching the low-power consumption requirements of mining cards. At the same time, by adjusting the trust value and weight in a linked manner, the participation qualification of nodes in the consensus mechanism is optimized, reducing the risk of communication chaos and consensus failure caused by abnormal nodes, reducing the communication complexity of consensus mechanisms such as PBFT in scenarios with dynamic node changes, and effectively solving the problems of insufficient security, high energy consumption, and difficulty in adapting to frequent mobile offline mining cards in traditional consensus mechanisms.

[0149] Example 2:

[0150] Reference Figure 3 This embodiment provides a hybrid consensus method applied to Embodiment 1, including the following steps:

[0151] At the leadership level, RSU runs the PBFT mechanism as a fixed node, elects master nodes according to mining card weights, and reduces message transmission volume through aggregate signature technology to improve consensus efficiency.

[0152] At the execution layer, the mining card node adopts a lightweight RAFT variant protocol, which only communicates with the RSU and adjacent nodes. When the mining card goes offline, it automatically degrades to an observer node, does not participate in consensus decision-making but keeps the state synchronized.

[0153] A term rotation system is introduced, where the master node is replaced every R′ blocks to prevent malicious nodes from controlling the consensus process for a long time. At the same time, a dynamic trust threshold is set. If a node engages in dishonest behavior, a zero-knowledge proof check is triggered. If the verification fails, its weight is reset to zero, thus achieving effective isolation and punishment of abnormal nodes.

[0154] In the above method, the leadership layer elects master nodes according to weights and rotates them periodically. The execution layer uses a lightweight RAFT variant to make the mining card communicate only with adjacent nodes. Combined with aggregate signature and dynamic trust threshold, it maintains the strong consistency of PBFT and improves dynamic adaptability through RAFT, thereby improving the system TPS. It effectively solves the problems of complex communication, high energy consumption and low efficiency of traditional consensus mechanisms under dynamic nodes, and finally achieves low power consumption, high security, strong real-time performance and dynamic robustness in vehicle-to-everything (V2X) communication scenarios.

[0155] Example 3:

[0156] Reference Figure 4 This embodiment provides a blockchain-based multi-party collaborative vehicle-road communication security system, including:

[0157] Node registration module: The mining card is used as a node and joins the blockchain network with the RSU and control center. Each mining card is equipped with a corresponding sensor. The node identity certificate is generated by ECC with embedded sensor public key hash and historical operation data. The initial weight of the mining card is generated based on the historical operation data and registration information. Mining cards with initial weights higher than the minimum weight threshold are granted network consensus qualifications.

[0158] Consensus Anchoring Module: After the mining card completes its operation cycle, the module collects the mining card's physical data, verifies it using zero-knowledge proof in combination with the public key hash, generates a proof of work for the verified mining card's physical data using lightweight hash, calculates the mining card's weight based on the proof of work, and allocates communication permissions according to the mining card's weight.

[0159] Collaborative communication module: The mining cards are grouped by geographical region, with RSU as the leader of each group. An alternate leader is elected based on the weight of the mining cards. In each period, the mining card with the highest weight submits the block first, and other nodes are verified by PBFT. The verification nodes respond in a hierarchical manner according to the weight of the mining cards.

[0160] Trust Update Module: RSU monitors message patterns through smart contracts. If an anomaly is detected, it triggers zero-knowledge proof verification. Each time a mining card completes a valid communication task, it gains a trust increment, which is then used to adjust the mining card's weight.

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

[0162] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based method for ensuring the security of multi-party collaborative vehicle-road communication, characterized in that: Includes the following steps: Mining cards are used as nodes and joined to the blockchain network along with RSU and control center. Each mining card is equipped with a corresponding sensor. A node identity certificate with embedded sensor public key hash and historical operation data is generated through ECC. An initial weight of the mining card is generated based on historical operation data and registration information. Mining cards with an initial weight higher than the minimum weight threshold are granted network consensus qualification. After the mining card completes its operation cycle, its physical data is collected and verified using zero-knowledge proofs in conjunction with the public key hash. The mining card is then required to provide its original physical data F; the hash h of the original physical data h is then calculated. F The mining card's public key (PK) is pre-uploaded to the blockchain, along with its corresponding hash (h). PK Embedded node identity certificate; verifies data compliance, identity authenticity, and time validity. F and h PK Whether it comes from the same legitimate node; generate a proof of work for the verified mining card physical data using lightweight hashing; serialize and compress the verified mining card physical data D to obtain Dn; perform a first hash and a second hash on the mining card ID, Dn, mining card private key signature, and timestamp; find a second hash value where the first e bits are 0 by adjusting the random number; after verification, obtain an encrypted hash value generated by D, mining card ID, timestamp, and random number hash, as the proof of work; calculate the mining card weight based on the proof of work, and allocate communication permissions according to the mining card weight; Mining cards are grouped by geographical region, with RSU as the leader of each group. Alternate leaders are elected based on the weight of the mining cards. In each period, the mining card with the highest weight submits the block first, and other nodes verify it through PBFT. Verification nodes respond in a hierarchical manner according to the weight of the mining cards. RSU monitors messages through smart contracts. If an anomaly is detected, it triggers zero-knowledge proof verification. Each time a mining card completes a valid communication task, it gains a trust increment. This increment is combined with a decay factor that decays over time, the trust value of the previous period, and the trust increment to dynamically adjust the current trust value. Based on the current trust value, the updated mining card weight is obtained by combining the Sigmoid function, the trust threshold, and the mining card weight update of the previous period.

2. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, Methods for finding and verifying quadratic hash values ​​where the first e bits are 0 include: Verify that the second hash value satisfies the condition that the first e bits are 0, and verify that the timestamp is within a preset reasonable range; use the mining card public key to verify that the signature is correct.

3. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, Methods for calculating mining card weights based on proof-of-work include: Based on the task type preset priority of the control center, the task priority is dynamically adjusted according to the task objectives and historical risks to obtain the task urgency. The time decay factor is calculated based on the interval between the task completion time and the current time, combined with the decay coefficient. The weight of the mining card is obtained by weighting the task urgency and time decay factor.

4. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, Methods for grouping mining cards by geographical region include: Taking the mining operation area as a whole, virtual geographic grids are divided into M×M grids. Each grid is defined with a unique grid ID and records the boundary latitude and longitude and the corresponding unique RSU; where M is the number of rows of virtual geographic grids. The grid ID, boundary latitude and longitude, and RSU are hashed and uploaded to the blockchain via smart contract to form shards; The real-time coordinates of the mining card are obtained. The RSU calls the Voronoi diagram algorithm to calculate the nearest neighbor of the mining card to each RSU and determine the shard to which the mining card belongs.

5. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, Methods for gaining trust increments include: The system detects the execution status of mining truck commands, calculates the completion score based on preset execution requirements, and obtains the job completion rate. The system detects the response speed, calculates the speed score based on preset response requirements, and statistically obtains the response speed score. The system checks the data quality of mining cards, calculates a quality score based on preset quality requirements, and statistically obtains the data quality score. Detect violations by mining cards, calculate violation scores based on preset behavioral requirements, and obtain a violation quality score. Trust increments are calculated by weighting scores based on task completion, response speed, data quality, and violation quality.

6. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, If an anomaly is detected, the methods that trigger zero-knowledge proof verification include: The mining card is required to provide raw sensor data; if the verification is successful, the mining card's trust value is increased and the mining card's weight is updated; otherwise, the mining card's trust value is deducted and the leader node's consensus participation right is suspended.

7. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, Methods for generating node identity certificates via ECC include: Pre-select a standard elliptic curve and define a finite field and a base point G, where the order of the base point is n; The mining card or RSU node is located locally, and a private key d is randomly selected, where d∈[1,n-1]. The public key Q is calculated using scalar multiplication based on the private key and the base point; Bind the public key Q to the node's physical identifier to generate an identity tuple; The identity tuple is hashed and uploaded to the blockchain via a smart contract to obtain the node identity certificate.

8. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, Methods for generating the initial weight of mining cards include: The equipment reputation is obtained by calculating the historical total fault-free duration, total operating time, number of compliant operations, and total number of operations of mining trucks over the past N days, and weighting the data according to the sub-item weights. Obtain the task type of sub-tasks in a single task; calculate the value of a single task based on the preset type value; adjust the value of a single task based on the quality coefficient of the single task to obtain the adjusted value; calculate the total adjusted value of all single tasks in the past N days based on the adjusted value, and use it as the task base. The initial weight of the mining card is obtained by weighting the equipment reputation and the number of operations.

9. The blockchain-based multi-party collaborative vehicle-road communication security assurance method according to claim 1, characterized in that, Methods for verification via PBFT include: RSU selects the top k miners each period based on their weights to form a consensus committee. k is calculated based on the average weight of the shard, a preset upper limit, and the sum of the weights of all miners in the shard, and k satisfies preset conditions. The mining card submits a request to the RSU containing proof of work; RSU merges L mining card requests into a single block, broadcasts the block to the consensus committee, and broadcasts the block to the validator nodes through the shard leader relay. RSU sends a heartbeat packet every cycle. If there is no response for U consecutive times, a leader election is triggered, and the standby leader takes over according to the mining card weight order. The verification node only sends data to the RSU and its two adjacent nodes; After the RSU aggregate signature is broadcast once across the network, the verification node performs local verification. When the number of nodes that refuse consensus is greater than the number of Byzantine nodes, zero-knowledge proof verification is triggered. If the first verification fails, the mining card weight is reduced. If the verification fails B times in a row, the mining card weight is reset. Nodes with mining card weights below the minimum weight threshold are automatically downgraded to light nodes, and backup nodes with weights above the minimum weight threshold are selected in descending order of weight to replace them; among them, light nodes that submit valid proof of work within V consecutive periods are automatically restored to validator nodes. If an RSU monitoring verification node does not respond for T consecutive cycles, it is determined to be offline, and a backup node with a weight higher than the lowest weight threshold is selected in descending order of weight to replace it.

10. A blockchain-based multi-party collaborative vehicle-road communication security assurance system, implementing the blockchain-based multi-party collaborative vehicle-road communication security assurance method according to any one of claims 1-9, characterized in that, include: Node registration module: The mining card is used as a node and joins the blockchain network with the RSU and control center. Each mining card is equipped with a corresponding sensor. The node identity certificate is generated by ECC with embedded sensor public key hash and historical operation data. The initial weight of the mining card is generated based on the historical operation data and registration information. Mining cards with initial weights higher than the minimum weight threshold are granted network consensus qualifications. Consensus Anchoring Module: After a mining card completes its work cycle, the module collects the mining card's physical data, verifies it using zero-knowledge proofs in conjunction with the public key hash, and requests the mining card to provide the original mining card physical data F; it then calculates the hash h of the original mining card physical data. F The mining card's public key (PK) is pre-uploaded to the blockchain, along with its corresponding hash (h). PK Embedded node identity certificate; verifies data compliance, identity authenticity, and time validity. F and h PK Whether it comes from the same legitimate node; generate a proof of work for the verified mining card physical data using lightweight hashing; serialize and compress the verified mining card physical data D to obtain Dn; perform a first hash and a second hash on the mining card ID, Dn, mining card private key signature, and timestamp; find a second hash value where the first e bits are 0 by adjusting the random number; after verification, obtain an encrypted hash value generated by D, mining card ID, timestamp, and random number hash, as the proof of work; calculate the mining card weight based on the proof of work, and allocate communication permissions according to the mining card weight; Collaborative communication module: The mining cards are grouped by geographical region, with RSU as the leader of each group. An alternate leader is elected based on the weight of the mining cards. In each period, the mining card with the highest weight submits the block first, and other nodes are verified by PBFT. The verification nodes respond in a hierarchical manner according to the weight of the mining cards. Trust Update Module: RSU monitors message patterns through smart contracts. If an anomaly is detected, it triggers zero-knowledge proof verification. Each time a mining card completes a valid communication task, it obtains a trust increment. Combined with a decay factor that decays over time, the current trust value is dynamically adjusted based on the trust value of the previous cycle and the trust increment. Based on the current trust value, the updated mining card weight is obtained by combining the Sigmoid function, the trust threshold, and the mining card weight update of the previous cycle.

Images