Internet of vehicles double-layer block chain fragmentation method

Abstract

The invention discloses an Internet of Vehicles double-layer block chain fragmentation method, and relates to the field of intelligent transportation systems.The Internet of Vehicles double-layer block chain fragmentation method is characterized in that consensus tasks are processed in a labor division mode through an'mining-packaging 'double-layer fragmentation structure, parallel transaction processing is achieved, single-node load is reduced, and the overall processing capacity is improved; a node reputation evaluation mechanism is used for dynamically evaluating and screening consensus nodes, low-reputation even malicious nodes are effectively eliminated, the Byzantine risk is reduced, and safe operation of the block chain is guaranteed.

Description

Technical Field

[0001] The present invention belongs to the technical field of intelligent transportation systems, and specifically relates to a dual-layer blockchain sharding method for Internet of Vehicles (IoV). Background Art

[0002] With the rapid development of Internet of Vehicles (IoV) technology, intelligent transportation systems increasingly rely on real-time data exchange between vehicles, roadside units (RSUs), and cloud platforms. This data, including vehicle trajectories, traffic conditions, road conditions, and emergency notifications, is critical to supporting the efficient and safe operation of IoV systems. However, traditional centralized data management approaches are prone to performance bottlenecks, security risks, and privacy leaks when faced with large-scale nodes, high-frequency communications, and strict real-time requirements.

[0003] Blockchain sharding is a key approach aimed at improving system throughput and scalability. Sharding divides the network into smaller, more manageable parts (or "shards"), allowing for parallel processing of transactions and data, significantly improving overall network throughput and responsiveness. Sharded blockchains, as an efficient blockchain architecture, can effectively process the massive amounts of real-time data in the connected vehicle (IoV), such as vehicle location, speed, and other sensor information. However, existing sharding schemes primarily rely on randomness. While this approach can address data processing locality to a certain extent, it also results in long distances between nodes within a shard, high communication latency, and an unknown number of malicious nodes. This approach also ignores the impact of dynamic factors such as vehicle traffic volume and the number of roadside units (RSUs) in the IoV. Consequently, sharding schemes based solely on randomness struggle to maintain efficiency and stability in highly dynamic environments, resulting in poor system performance and resource utilization. Furthermore, traditional single-layer sharding structures often incur significant cross-shard communication and synchronization overhead, increasing latency and complexity, and impacting system performance and scalability. Summary of the Invention

[0004] To address the aforementioned issues in the prior art, the present invention provides a dual-layer blockchain sharding method for the Internet of Vehicles (IoV). The technical issues addressed by the present invention are achieved through the following technical solutions:

[0005] The present invention provides a dual-layer blockchain sharding method for an Internet of Vehicles (IoV), comprising:

[0006] Step 1: The vehicle sends the generated transaction data to an RSU node that meets a first preset credibility threshold, wherein the transaction data includes vehicle status information and road information;

[0007] Step 2: Use the RSU node as the founder node, and perform a mining shard operation based on the founder node to obtain a mining shard;

[0008] Step 3: Conducting a first-stage consensus in the mining shard, aggregating the transaction data that successfully reach consensus into a first mining block, and aggregating the transaction data that failed to reach consensus into a second mining block, and sending the first mining block and the second mining block to the packaging shard, wherein the packaging shard is composed of multiple RSU nodes that meet a second preset reputation threshold;

[0009] Step 4: In the packaging shard, the first mining blocks are aggregated into packaging blocks and uploaded to the blockchain, the second mining blocks are subjected to the second-stage consensus, the second mining blocks that have successfully reached the consensus are aggregated into packaging blocks and uploaded to the blockchain, and the RSU nodes that have voted incorrectly or not voted in the mining shard are kicked out of the mining shard and prohibited from participating in the consensus again;

[0010] Among them, after each consensus cycle, the node reputation value of the RSU nodes participating in the consensus is updated based on the node reputation evaluation mechanism.

[0011] In one embodiment of the present invention, the vehicle status information includes vehicle speed, vehicle position, and engine operation status; and the road information includes the location of the accident.

[0012] In one embodiment of the present invention, after step 1, the method further includes: the RSU node filtering the received transaction data to remove damaged or duplicate transaction data.

[0013] In one embodiment of the present invention, step 2 includes:

[0014] Step 2.1: Obtain node information of the RSU nodes around the founder node;

[0015] Step 2.2: Obtain all RSU nodes within the M-hop range of the founder node according to the node information to obtain a first node set, where M is the set hop range;

[0016] Step 2.3: Selecting RSU nodes that overlap with the future trajectory of the vehicle from the first node set based on the vehicle state information and the node information to obtain a second node set;

[0017] Step 2.4: Selecting RSU nodes that meet the first preset reputation threshold from the second node set according to the node information to obtain a third node set;

[0018] Step 2.5: If the number of nodes in the third node set is within the preset node number range, all RSU nodes in the third node set constitute the mining shard; otherwise, adjust M and return to step 2.2.

[0019] In one embodiment of the present invention, the node information includes: geographic location, neighbor information, node load and node reputation value.

[0020] In one embodiment of the present invention, in step 3, an improved PBFT algorithm is used to perform a first-stage consensus in the mining shard, wherein, for the transaction data, if the voting results of all nodes received by the master node in the mining shard within a preset time are consistent, the consensus is considered successful, otherwise the consensus fails.

[0021] In one embodiment of the present invention, the second preset reputation threshold is greater than the first preset reputation threshold.

[0022] In one embodiment of the present invention, in step 4, the Hotstuff algorithm is used to perform the second-stage consensus on the packaged shards.

[0023] In one embodiment of the present invention, the node reputation value of the RSU node is calculated according to the following formula:

[0024]

[0025] Where, is the node reputation value of the i-th RSU node in the previous consensus cycle, S ni is the voting behavior score of the i-th RSU node, is the transaction processing delay of the i-th RSU node, is the interaction frequency of the i-th RSU node, α is S ni The weight factor of The weight factor of The weight factor of

[0026] in,

[0027] S ni =w(i)*s(i);

[0028]

[0029] Among them, s(i) is the sum of the scores obtained according to the votes given by the i-th RSU node in the consensus, w(i) is the weight function of the i-th RSU node participating in the vote and voting correctly, is the time when the i-th RSU node completes verification of the transaction submission, is the time when the i-th RSU node receives the transaction, t TX is the time it takes for all RSU nodes in the shard to verify the transaction, AVG(t TX ) is the average time taken by all RSU nodes in the shard to verify the transaction, V(Iij ) is the verification function of RSU node communication, num is the number of RSU nodes in the shard, T is the time of the entire consensus cycle, and the weight function of the i-th RSU node is calculated as follows:

[0030]

[0031] Where b i Indicates the number of times the block where the RSU node votes is on the chain, v i Indicates the number of times the RSU node vote is accepted by the shard master node and packaged into the block. The value of the weight function is between 0 and 1.

[0032] Compared with the prior art, the present invention has the following beneficial effects:

[0033] The dual-layer blockchain sharding method for the Internet of Vehicles of the present invention divides the consensus tasks through a "mining-packaging" dual-layer sharding structure, realizes parallel transaction processing, reduces the load on a single node, and improves overall processing capabilities; utilizes a node reputation evaluation mechanism to dynamically evaluate and screen consensus nodes, effectively eliminating low-reputation or even malicious nodes, reducing Byzantine risks and ensuring the safe operation of the blockchain.

[0034] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the following preferred embodiments are specifically cited and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a flow chart of a dual-layer blockchain sharding method for Internet of Vehicles provided by an embodiment of the present invention;

[0036] Figure 2 A neighbor node topology diagram provided by an embodiment of the present invention;

[0037] Figure 3 This is a schematic diagram of a blockchain system with a double-layer sharding architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0038] In order to further illustrate the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the following is a detailed description of a dual-layer blockchain sharding method for Internet of Vehicles proposed according to the present invention in combination with the accompanying drawings and specific implementation methods.

[0039] The aforementioned and other technical contents, features, and effects of the present invention are clearly presented in the following detailed description of the specific embodiments in conjunction with the accompanying drawings. Through the description of the specific embodiments, a deeper and more specific understanding of the technical means and effects adopted by the present invention to achieve the intended purpose can be obtained. However, the accompanying drawings are provided for reference and illustration purposes only and are not intended to limit the technical solutions of the present invention.

[0040] The embodiment of the present invention provides a dual-layer blockchain sharding method for Internet of Vehicles. Figure 1 , Figure 1 This is a flow chart of a dual-layer blockchain sharding method for Internet of Vehicles provided by an embodiment of the present invention. Figure 1 As shown, the dual-layer blockchain sharding method for the Internet of Vehicles of this embodiment includes:

[0041] Step 1: The vehicle sends the generated transaction data to an RSU node that meets the first preset credibility threshold. The transaction data includes vehicle status information and road information.

[0042] In this embodiment, vehicle status information includes vehicle speed, vehicle location, and engine operation status; road information includes the location of the accident. The vehicle can obtain vehicle status information and road information through hardware devices such as on-board GPS, cameras, radar, and sensors.

[0043] In this embodiment, after the vehicle sends the generated transaction data to the RSU node, the RSU node filters the received transaction data to remove damaged or duplicate transaction data.

[0044] In this embodiment, the vehicle sends the generated transaction data to the RSU node that meets the first preset credibility threshold through a three-way negotiation mechanism. Specifically, the vehicle will search for nearby RSU nodes in advance based on its own vehicle trajectory. When it finds an RSU node that meets the first preset credibility threshold, it will sign the transaction data it needs to submit and send it to it. After receiving it, the RSU node will verify the signature and the legitimacy of the vehicle. If both meet the requirements, it will send a signed receipt message to the vehicle to inform the vehicle that the transaction data has been received. After the vehicle receives the message and verifies it, it will send a signed confirmation message to the RSU node again to inform the RSU node that it has confirmed it. In order to protect privacy, the vehicle and the RSU node will also use each other's public key to encrypt the transaction to ensure that only the target object can receive it.

[0045] Step 2: Use the RSU node as the founder node, and perform mining sharding operations based on the founder node to obtain mining shards.

[0046] In this embodiment, after three negotiations are completed, the RSU node will generate a certificate to apply to the TA organization to establish a mining shard.

[0047] In this embodiment, step 2 may specifically include the following steps:

[0048] Step 2.1: Get the node information of the RSU nodes around the founder node.

[0049] In this embodiment, node information includes: geographic location, neighbor information, node load, and node reputation. The geographic location is used to determine whether the RSU node is distributed on the vehicle trajectory, the neighbor information is used to select all RSU nodes within a certain hop count range, and the node load and node reputation are used to determine the reliability and security of the RSU node.

[0050] In this embodiment, geographic location, node load, and neighbor information are obtained through regular broadcasts, and node reputation values can be obtained by consulting the blockchain.

[0051] Step 2.2: Obtain all RSU nodes within the M-hop range of the founder node according to the node information to obtain the first node set, where M is the set hop range.

[0052] In this embodiment, to facilitate the selection of all RSU nodes within a set hop count range, an undirected graph is used to represent the neighbor information of all RSU nodes within an N-hop range (N-hop), i.e., the network topology. The undirected graph is denoted as G(V,E), where vertices V represent all nodes and edges E indicate whether two nodes can communicate with each other in a single hop, with 1 indicating that they can communicate in a single hop and 0 indicating that they cannot.

[0053] See Figure 2 The embodiment of the present invention shown provides a neighbor node topology graph, which represents the network topology relationship within N hops around node A through an undirected graph. The breadth-first search (BFS) algorithm is a hierarchical traversal method of a graph, and nodes with the same distance from the starting point are located in the same layer, that is, nodes that can communicate through a single hop. In this embodiment, each layer represents 1 hop, so all nodes within each hop range can be obtained through the BFS algorithm. During the traversal process, it is necessary to record the number of traversed layers. If the specified number of hops is reached, the traversal process is terminated. Finally, all RSU nodes within the M-hop range (M-hop) of the builder node are obtained through Algorithm 3, that is, the first node set, recorded as S M-hop At the same time, the node distance array dist of each layer is obtained for next use. The node distance array dist records the number of hops required from the neighbor node to the founder node. The specific process of Algorithm 3 is as follows:

[0054]

[0055] Step 2.3: According to the vehicle state information and node information, select RSU nodes that overlap with the vehicle's future trajectory from the first node set to obtain a second node set.

[0056] In this embodiment, overlapping with the vehicle's future trajectory means that the RSU's geographic location is in the vehicle's direction of travel, and the distance between them is shrinking. Selecting such an RSU ensures a long communication time between them, making them less likely to leave the network during the consensus process, while also preventing the vehicle from frequently switching between serving RSU nodes.

[0057] Specifically, the method of selecting RSU nodes with overlapping trajectories usually considers the moving speed and direction of the vehicle, so that it can be determined which RSU nodes may overlap or meet based on the consideration of location and time. gen The position at time t is (x veh (t),y veh (t)), where the initial position is (x0, y0) and the moving speed is Node gen_speed , moving direction is Node gen_direction , then the vehicle's position changes over time as follows:

[0058] x veh (t)=x0+Node gen_speed ·cos(Node gen_direction )·t;

[0059] y veh (t)=y0+Node gen_speed sin(Node gen_direction )·t;

[0060] Due to S M-hop The position of the RSU node in the set is fixed, assuming that (x RSU ,y RSU ). In order to determine the overlap, it is necessary to calculate the distance D(t) between the vehicle and the RSU node. When D(t+1)-D(t) is less than the preset threshold Δdistance, the vehicle trajectory is considered to overlap with the RSU node, otherwise it does not overlap. Through the above steps, the second node set is finally obtained, denoted as S Overlap , S Overlap The nodes in the set are within M hops and are connected to the vehicle node Node gen The future trajectories overlap.

[0061] Step 2.4: Select RSU nodes that meet the first preset reputation threshold from the second node set according to the node information to obtain a third node set;

[0062] In this embodiment, the RSU node whose node reputation value is greater than the first preset reputation threshold is selected. This is because S OverlapSome malicious nodes in the set may engage in malicious behavior and undermine transaction consensus. A node with a higher reputation value is more reliable and honest. Conversely, a node with a lower reputation value may be at risk of malicious behavior. Therefore, select RSU nodes with higher reputation values to participate in consensus.

[0063] Specifically, we first need to evaluate S Overlap Node reputation value of each RSU node in the set Overlap_reputation , and compare it with the first preset reputation threshold ΔR. Specifically, if the node reputation value of a certain RSU node is greater than the first preset reputation threshold (i.e., it satisfies the Node Overlap_reputation ≥ΔR), it means that the behavior of the RSU node is normal and has a high credibility. Therefore, the RSU node that meets this condition will be considered a normal node and added to the third node set, denoted as S Reputation Through the above selection process, the final S Reputation The RSU nodes in the set are located within M hops, are close to other important nodes, and behave normally.

[0064] Step 2.5: If the number of nodes in the third node set is within the preset node number range, all RSU nodes in the third node set form a mining shard, otherwise adjust M and return to step 2.2.

[0065] As mentioned above, the number of nodes participating in the consensus will affect the efficiency and security of the consensus. In this embodiment, the maximum number of nodes participating in the consensus is set to Num cons_max and the minimum number Num cons_min , that is, the range of node quantity. These two parameters are set by the system according to the network environment. Reputation All nodes in the collection meet the requirements, but the number of nodes in the collection Num Reputation Maybe not in Num cons_min and Num cons_max At this time, the value of M needs to be dynamically adjusted to obtain the final consensus node set S Final The specific process of dynamically adjusting M is shown in Algorithm 4 below:

[0066]

[0067] In this embodiment, the node set generated by Algorithm 4 is the final consensus node set, denoted as S Final , the number of nodes is Num cons_min and Num cons_max In the end, S Final All RSU nodes in the set form a mining shard for the vehicle node gen The generated transaction data reaches consensus.

[0068] In this embodiment, the selection of nodes within the mining shard is based on physical proximity and vehicle driving trajectory, which can significantly reduce the communication delay between nodes within the shard and improve real-time performance.

[0069] It should be noted that when the traffic density is low, the number of RSU nodes selected by Algorithm 4 may always be less than Num cons_min In this case, the consensus security cannot be guaranteed. At this time, the RSU node will first save the generated transaction data locally. When the number of consensus nodes is greater than Num cons_min Reach consensus again.

[0070] It's worth noting that to avoid frequent network sharding, when the builder node receives transaction data, it compares the current network environment with the previous shard. If the node load in the previous shard is within the limit and the node reputation meets the requirements, the mining shard can be reused. If the vehicle is already within the range of a mining shard, there's no need to create a new mining shard; simply submit the transaction data to the nodes in that mining shard.

[0071] Step 3: Perform the first phase of consensus in the mining shard, aggregate the transaction data that successfully reach consensus into the first mining block, aggregate the transaction data that failed to reach consensus into the second mining block, and send the first mining block and the second mining block to the packaging shard.

[0072] In this embodiment, an improved PBFT algorithm is used to perform the first phase consensus in the mining shards. The PBFT algorithm process includes the request, pre-preparation, preparation, submission and reply stages.

[0073] In this embodiment, the PBFT algorithm is improved by requiring all nodes in the mining shard to complete all votes within T1, when the master node proposes blocks and coordinates node voting. The final consensus result is then tallied by the master node, and consensus is considered successful only if all consensus nodes vote unanimously. In other words, for transaction data, if the voting results received by the master node in the mining shard are consistent within a preset time, consensus is considered successful; otherwise, it fails.

[0074] The specific process of the first phase of consensus is as follows:

[0075] Node RSU i Receive the request message m sent by the requesting vehicle in the mining shard, the format of which is: And put the request message m into the transaction waiting pool within the shard, where o represents the node RSU i The specific operation of receiving the request message m, t represents the timestamp, that is, the request vehicle sends the request message to the node RSU itime, g represents the vehicle location, including longitude and latitude information, c represents the requested vehicle number, σ c Indicates the vehicle's signature.

[0076] Pre-preparation phase: The master node L of the mining shard assigns a sequence number to the request message in the transaction waiting pool and broadcasts a preparation message to all nodes in the shard.<PRE-PREPARE,v,h,d> σ L ,m>.

[0077] in,<PRE-PREPARE,v,h,d> σ L is the signature of the master node using its private key, v represents the view number, h represents the sequence number assigned to the request message m, and d represents the digest of the request message m.

[0078] Preparation phase: After receiving the PRE-PREPARE message from the master node, the node RSU i Use the corresponding public key to verify. After successful verification, check the legality of the transactions in the block. If all transactions are legal, send a message to other nodes (including the master node) in the shard. The message represents your own signed message.

[0079] Commit phase: If the node RSU i After receiving 2f+1 PREPARE messages that have passed verification, the confirmation phase begins. The multicast message is sent to all nodes in the mining shard.

[0080] Reply phase: If the node RSU i Receive 2f+1 verified COMMIT messages, which indicates that all nodes of the current mining shard have reached a consensus. The node sends a reply message to the master node L of the shard The master node of the mining shard checks the REPLY messages with the same sequence number replied by the members of the current mining shard, including itself, to confirm whether a consensus has been reached in the mining shard. If the voting results of all nodes received within T1 are consistent, the master node considers that a consensus has been reached in the mining shard. Otherwise, the consensus fails. The master node packages the request message and voting data into a block. Mining Broadcast to all nodes in the packaged shard.

[0081] In the first phase of consensus, there are only two possible outcomes: 1. The block is unanimously accepted, which means that no node in the process shard has shown adversarial behavior, and the block has not yet received a unanimous vote; 2. Due to the synchronous communication assumption, all honest nodes vote within T1 and receive each other's votes. Honest nodes will reach the same decision on the block (accept or reject). When a block does not receive a unanimous vote, it means that there are adversarial nodes in the shard.

[0082] It should be noted that after the consensus is successful, the mining shard will start a new round of consensus requests. Otherwise, the nodes in the mining shard need to wait for the packaging shard to make a ruling on the block that failed the consensus before they can continue to start a new round of consensus requests.

[0083] In this embodiment, the packaged fragment is composed of a plurality of RSU nodes that meet a second preset reputation threshold, wherein the second preset reputation threshold is greater than the first preset reputation threshold.

[0084] Optionally, in the packaging shard, a shard node random election algorithm based on dynamic reputation value is used to obtain the RSU nodes that constitute the packaging shard. The specific process is shown in Algorithm 5 below. This algorithm combines the node reputation value of the RSU node with randomness and randomly selects RSU nodes with high and stable node reputation values from the RSU nodes in the entire network as the consensus nodes of the packaging shard.

[0085] In this algorithm, the long-term and short-term reputation values of RSU nodes are comprehensively calculated to ensure that RSU nodes with relatively stable reputations are given priority in sharding. This effectively prevents malicious nodes from disguising themselves as honest nodes by increasing their reputation values in the short term (such as in a "switch attack"), thereby reducing the possibility of malicious nodes entering the consensus process. At the same time, the algorithm dynamically adjusts the size of the packaged shards based on the current network size and the distribution of node reputation values, ensuring that the representativeness and effectiveness of the selected packaged shards remain stable as the network size increases or the distribution of node reputation values changes. This adaptive adjustment mechanism improves election fairness while reducing the probability of malicious nodes being selected.

[0086]

[0087] Step 4: In the packaging shard, the first mining block is aggregated into a packaging block and uploaded to the blockchain. The second mining block is subjected to the second-stage consensus. The second mining block that successfully reaches the consensus is aggregated into a packaging block and uploaded to the blockchain. The RSU nodes that voted incorrectly or did not vote in the mining shard are kicked out of the mining shard and are prohibited from participating in the consensus again.

[0088] In the second phase of consensus, there are two main tasks: one is to aggregate the mined blocks that successfully passed the first phase of consensus into packaged blocks for on-chain inclusion; the other is to adjudicate the mined blocks that failed the first phase of consensus, deciding whether to include them on-chain and penalizing nodes that voted incorrectly or did not vote. In this embodiment, the Hotstuff algorithm is used to perform the second phase of consensus on the packaged shards.

[0089] Specifically, after receiving the mining block sent by the mining shard, the nodes in the packaging shard need to perform the following checks on the mining block: check whether the mining block is successful, check whether the signatures in each mining block are sufficient, verify whether the signatures of all verification nodes are correct, and check whether there are conflicts in the inputs of all transactions.

[0090] After passing the check, the mined blocks are arranged in chronological order. To quickly resume work on the mining shard that generated the block that failed consensus, the mined block that failed consensus will be given a higher priority. After the packing shard receives all or three-quarters of the mined blocks, it is packaged into a single packing block and added to the blockchain. To reduce consensus latency, the packing shard uses the HotStuff algorithm, which boasts faster consensus speeds, especially in a synchronous network model. Reaching consensus requires four phases: Prepare, Pre-Commit, Commit, and Decide. The specific process of the second phase of consensus is as follows:

[0091] Prepare stage:

[0092] The master node P of the packaged shard will wait The master node selects the preparedQC with the highest height as highQC and broadcasts it. <block packaging ,HASH(block Mining ),highQC,t>σ P The message contains the new block and highQC, where highQC serves as the security verification of the prepare message. The replica node receives the prepare message from the master node corresponding to the current view number, verifies it, and if it passes the verification, signs the prepare message and sends the signature to the master node.

[0093] Pre-Commit stage:

[0094] The master node collects signatures. After collecting at least 2f+1 signatures about the above message, it performs signature aggregation. The aggregated signature is saved locally as preparedQC and placed in <block packaging ,HASH(blockMining ),prepareQC,t>σ P The message is broadcast to the replica nodes. After receiving the message, the replica node verifies it, signs the message, and sends the signature to the master node.

[0095] Commit phase:

[0096] After the master node collects at least 2f+1 signatures on the above message, it performs a signature aggregation operation, uses the aggregated signature as precommitQC, and puts it into <block packaging ,HASH(block Mining ),precommitQC,t>σ P The message is broadcast in the message. After receiving the message, the replica node verifies it, signs the message, and replies to the master node. At this time, the replica node locks the precommitQC and updates the local lockQC to the received precommitQC.

[0097] Decide stage:

[0098] When the master node receives at least 2f+1 signatures on the above message, it aggregates them into commitQC and broadcasts <block packaging ,HASH(block Mining ),commitQC,t>σ P After receiving the commitQC message, the replica node executes the transactions in the block and increases the view number by 1, starting a new view.

[0099] In this embodiment of the dual-layer blockchain sharding method for the Internet of Vehicles, a node reputation evaluation mechanism is implemented. After each consensus cycle, the node reputation values of the participating RSU nodes are updated based on this node reputation evaluation mechanism. In this embodiment, each consensus cycle consists of 20 rounds of consensus, meaning that node reputation values are updated every 20 blocks generated.

[0100] It is understood that before the end of each round of consensus, the current shard consensus master node will initiate a request to update the node reputation value. Upon receiving the request, the shard consensus node calculates the node reputation value of each node based on its previous local behavior records. It then uses the consensus protocol proposed in this invention to reach a consensus on node reputation. After consensus is reached, the master node packages the node reputation values generated in this round into a block, and after global consensus is reached, it is uploaded to the chain and recorded in the node behavior table.

[0101] Specifically, the node reputation value of the RSU node is calculated according to the following formula:

[0102]

[0103] Where, is the node reputation value of the i-th RSU node in the previous consensus cycle, S ni is the voting behavior score of the i-th RSU node, is the transaction processing delay of the i-th RSU node, is the interaction frequency of the i-th RSU node, α is S ni The weight factor of The weight factor of The weight factor of

[0104] in,

[0105] S ni =w(i)*s(i);

[0106]

[0107] Among them, s(i) is the sum of the scores obtained according to the votes given by the i-th RSU node in the consensus, w(i) is the weight function of the i-th RSU node participating in the vote and voting correctly, is the time when the i-th RSU node completes verification of the transaction submission, is the time when the i-th RSU node receives the transaction, t TX is the time it takes for all RSU nodes in the shard to verify the transaction, AVG(t TX ) is the average time taken by all RSU nodes in the shard to verify the transaction, V(Ii j ) is the verification function of RSU node communication, num is the number of RSU nodes in the shard, T is the time of the entire consensus cycle, and the weight function of the i-th RSU node is calculated as follows:

[0108]

[0109] Where b i Indicates the number of times the block where the RSU node votes is on the chain, v i Indicates the number of times the RSU node vote is accepted by the shard master node and packaged into the block. The value of the weight function is between 0 and 1.

[0110] In this embodiment, all RSU nodes participating in consensus in the system will have their node reputations evaluated based on three dimensions: voting behavior score, transaction processing latency, and interaction frequency. The voting behavior score is a score that adds or subtracts points based on the correctness of the votes cast by the RSU node in its transactions. After a consensus cycle, the node's total score is calculated based on the RSU node's votes in the consensus process. Transaction processing latency is the average response delay for a node to process a transaction. Interaction frequency indicates the frequency of communication between the current RSU node and other RSU nodes. The specific calculation process for the voting behavior score is shown in Algorithm 1, and the specific calculation process for the node reputation value of an RSU node is shown in Algorithm 2.

[0111]

[0112]

[0113] The dual-layer blockchain sharding method for the Internet of Vehicles in an embodiment of the present invention divides the consensus tasks through a "mining-packaging" dual-layer sharding structure, realizes parallel transaction processing, reduces the load on a single node, and improves overall processing capabilities; utilizes a node reputation evaluation mechanism to dynamically evaluate and screen consensus nodes, effectively eliminating low-reputation or even malicious nodes, reducing Byzantine risks and ensuring the safe operation of the blockchain.

[0114] Based on the Internet of Vehicles dual-layer blockchain sharding method of the present invention, an embodiment of the present invention also provides a blockchain system with a dual-layer sharding architecture that implements the Internet of Vehicles dual-layer blockchain sharding method. The blockchain system with the dual-layer sharding architecture adopts a dual-layer sharding structure design, sets a reputation value update and incentive mechanism, and adopts a dynamic sharding mechanism based on the reputation value, and adopts a two-stage consensus mechanism.

[0115] Specifically, the blockchain system of this embodiment is divided into "mining shards" and "packaging shards." The mining shard is responsible for initial transaction aggregation and verification, while the packaging shard performs final consensus and blocks packaging and uploading, forming a distributed consensus system with clear responsibilities. After each consensus cycle, the node reputation of the participating RSU nodes is updated to incentivize honest nodes, improve the overall system participation quality, and inhibit malicious behavior. In addition, RSU nodes are rated based on their historical behavior (such as voting accuracy, processing latency, and interaction frequency). During sharding, RSU nodes with high node reputations are prioritized for consensus participation, ensuring the honesty and reliability of RSU nodes within the shard. Sharding nodes use breadth-first search to select neighboring nodes within a certain number of hops (M-hops). Furthermore, considering the vehicle's future movement trajectory, RSU nodes with high node reputations along the vehicle's forward direction are prioritized to improve connection stability. Secondly, in the first phase, a modified PBFT algorithm is used to reach preliminary consensus in the mining shard. If consensus cannot be reached, the consensus is submitted to the packaging shard, where the HotStuff algorithm is used for secondary arbitration and final confirmation.

[0116] See Figure 3 As shown, Figure 3 This is a schematic diagram of a blockchain system with a double-layer sharding architecture provided by an embodiment of the present invention. Figure 3 As shown, the blockchain system of the dual-layer sharding architecture of this embodiment includes four layers, namely the physical layer, the mining layer, the packaging layer and the cloud layer.

[0117] The physical layer is responsible for the physical perception of the connected vehicle network, receiving data from sensors such as vehicles. Vehicles use hardware devices such as GPS, cameras, radar, and sensors to obtain vehicle status information and road information, such as speed, location, engine status, and accident location. Vehicles transmit the generated transaction data to the roadside units (RSUs) in the mining layer. The RSUs filter the captured transaction data and remove corrupted or duplicated data.

[0118] The mining layer aggregates and initially verifies transaction data from the physical layer. Verified blocks are then transferred to the packaging layer. The mining layer establishes multiple mining shards for parallel transaction processing. These mining shards are dynamically created based on vehicle selection. Multiple roadside units are selected as a mining shard based on the physical distance between the roadside unit and the vehicle and the node's reputation. The RSU node with the highest node reputation is selected as the master node for the mining shard. Each mining shard is responsible for processing transaction data, which reduces energy consumption and improves efficiency. After a period of time, the first phase of consensus begins. The master node of the mining shard sends the block to all healthy nodes. Healthy nodes verify the received data by comparing them. When all nodes vote unanimously (either unanimously or unanimously), the unanimously agreed block is transferred to the packaging layer for on-chain inclusion. In the event of inconsistent votes, the master node sends the block to the packaging layer for adjudication, during which time consensus within the mining shard is suspended.

[0119] The packaging layer is responsible for packaging and uploading correct mining shard blocks to the blockchain, and for secondary verification and adjudication of inconsistent blocks. The nodes that package the shards are composed of random RSU nodes with high node reputation scores, and the RSU node with the highest node reputation score is designated as the master node for the packaging shard. The master node packages all consistent blocks sent by the mining layer into a single block and broadcasts the voting signature message for each mining shard and the final packaged block to all verification nodes. The verification nodes verify the correctness of the decoded data signature message. If all are correct, the block is uploaded to the blockchain. Inconsistent blocks indicate the presence of malicious or faulty nodes within the mining shard. The packaging shard first processes the inconsistent blocks. After consensus verification, if the block passes, all nodes within the mining shard that voted against or did not vote are kicked out of the mining shard and prohibited from participating in consensus again. The same applies if the block fails.

[0120] The cloud layer not only stores the final blocks but also provides blockchain visualization and accessibility for all nodes in the network. As the system's core storage unit, the cloud layer ensures that all blocks verified and packaged through the consensus process are securely stored across the entire network, maintaining long-term traceability and consistency. Through its efficient storage mechanism, the cloud layer assigns unique timestamps and versioning to each generated block, ensuring that the blockchain returns accurate status information when queried by any node.

[0121] The blockchain system with a two-layer sharding architecture in this embodiment includes three system objects: vehicles, roadside units (ROUs), and trusted authorities (TAs). In the connected vehicle network, vehicles are equipped with communication devices and smart sensors that can transmit collected road information to the blockchain network via wireless communication technologies (such as Wi-Fi, cellular networks, and onboard communication systems). Powered by blockchain technology, vehicles act as light nodes, responsible for message generation and message requests. Compared to vehicles, RSUs have stronger computing power, enabling efficient information encryption and verification, greater storage capacity for important blockchain data and transaction records, and sufficient energy supply to prevent node disconnection. Furthermore, wired communication between RSUs typically offers higher bandwidth and faster data transmission speeds. Fixed-location RSUs are also more easily repaired after being attacked. Therefore, RSUs are selected as nodes in the blockchain network to participate in consensus. RSUs collect communication data submitted by vehicles within their communication range and then package the results into blocks, adding them to the blockchain network for query by global vehicles and entities such as RSUs. The TA issues certificates to authorized vehicles and roadside units (RSUs) and distributes their public and private keys over secure channels. The TA ensures that only authorized and trusted vehicles can join and operate within the connected vehicle network. The TA is also responsible for shard management, issuing shard certificates to authorized RSUs and monitoring the shard status across the network. It also enables vehicles to query information such as shard coverage.

[0122] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations are intended to cover non-exclusive inclusion, so that an article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed. In the absence of further restrictions, an element defined by the statement "comprising a ..." does not exclude the presence of additional identical elements in the article or device comprising the element. Similar words such as "connected" or "connected" are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

[0123] In the description of this specification, the reference terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" mean that the specific features or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features or characteristics described can be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification.

[0124] The above is a further detailed description of the present invention in conjunction with specific preferred embodiments, and the specific implementation of the present invention should not be considered to be limited to these descriptions. For those skilled in the art of the present invention, without departing from the concept of the present invention, several simple deductions or substitutions can be made, which should be considered to fall within the scope of protection of the present invention.

Claims

1. A dual-layer blockchain sharding method for Internet of Vehicles, characterized in that: include: Step 1: The vehicle sends the generated transaction data to an RSU node that meets a first preset credibility threshold, wherein the transaction data includes vehicle status information and road information; Step 2: Use the RSU node as the founder node, and perform a mining shard operation based on the founder node to obtain a mining shard; Step 3: Conducting a first-stage consensus in the mining shard, aggregating the transaction data that successfully reach consensus into a first mining block, and aggregating the transaction data that failed to reach consensus into a second mining block, and sending the first mining block and the second mining block to the packaging shard, wherein the packaging shard is composed of multiple RSU nodes that meet a second preset reputation threshold; Step 4: In the packaging shard, the first mining blocks are aggregated into packaging blocks and uploaded to the blockchain, the second mining blocks are subjected to the second-stage consensus, the second mining blocks that have successfully reached the consensus are aggregated into packaging blocks and uploaded to the blockchain, and the RSU nodes that have voted incorrectly or not voted in the mining shard are kicked out of the mining shard and prohibited from participating in the consensus again; Among them, after each consensus cycle, the node reputation value of the RSU nodes participating in the consensus is updated based on the node reputation evaluation mechanism.

2. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 1 is characterized in that: The vehicle status information includes vehicle speed, vehicle position, and engine operation status; the road information includes the location of the accident.

3. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 1 is characterized in that: After step 1, the method further includes: the RSU node filtering the received transaction data to remove damaged or duplicate transaction data.

4. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 1 is characterized in that: The step 2 includes: Step 2.1: Obtain node information of the RSU nodes around the founder node; Step 2.2: Obtain all RSU nodes within the M-hop range of the founder node according to the node information to obtain a first node set, where M is the set hop range; Step 2.3: Selecting RSU nodes that overlap with the future trajectory of the vehicle from the first node set based on the vehicle state information and the node information to obtain a second node set; Step 2.4: Selecting RSU nodes that meet the first preset reputation threshold from the second node set according to the node information to obtain a third node set; Step 2.5: If the number of nodes in the third node set is within the preset node number range, all RSU nodes in the third node set constitute the mining shard; otherwise, adjust M and return to step 2.

2.

5. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 4 is characterized in that: The node information includes: geographic location, neighbor information, node load and node reputation value.

6. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 1 is characterized by: In step 3, the improved PBFT algorithm is used to perform the first-stage consensus in the mining shard, wherein, for the transaction data, if the voting results of all nodes received by the master node in the mining shard are consistent within a preset time, the consensus is considered successful; otherwise, the consensus fails.

7. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 1 is characterized in that: The second preset credibility threshold is greater than the first preset credibility threshold.

8. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 1 is characterized in that: In step 4, the Hotstuff algorithm is used to perform the second phase consensus on the packaged shards.

9. The dual-layer blockchain sharding method for Internet of Vehicles according to claim 1 is characterized in that: The node reputation value of the RSU node is calculated according to the following formula: Where, is the node reputation value of the i-th RSU node in the previous consensus cycle, S ni is the voting behavior score of the i-th RSU node, is the transaction processing delay of the i-th RSU node, is the interaction frequency of the i-th RSU node, α is S ni The weight factor of The weight factor of The weight factor of in, S ni =w(i)*s(i); Among them, s(i) is the sum of the scores obtained according to the votes given by the i-th RSU node in the consensus, w(i) is the weight function of the i-th RSU node participating in the vote and voting correctly, is the time when the i-th RSU node completes verification of the transaction submission, is the time when the i-th RSU node receives the transaction, t TX is the time it takes for all RSU nodes in the shard to verify the transaction, AVG(t TX ) is the average time taken by all RSU nodes in the shard to verify the transaction, V(I ij ) is the verification function of RSU node communication, num is the number of RSU nodes in the shard, T is the time of the entire consensus cycle, and the weight function of the i-th RSU node is calculated as follows: Where b i Indicates the number of times the block where the RSU node votes is on the chain, v i Indicates the number of times the RSU node vote is accepted by the shard master node and packaged into the block. The value of the weight function is between 0 and 1.

Images