A blockchain storage joint optimization method and system for Internet of Vehicles

Abstract

A static blockchain storage joint optimization method for the Internet of Vehicles (IoV) includes: randomly dividing the RSU nodes in a blockchain storage system into multiple node clusters to obtain a target cluster solution; optimizing the target cluster solution to obtain an optimized cluster solution, and determining the master RSU node in each node cluster; calculating a target block deployment solution; optimizing the target block deployment solution to obtain an optimized block deployment solution and calculating a fitness value; repeating these steps until a termination condition is met, outputting the block deployment solution with the optimal fitness value across all repetitions, and updating the block deployment in the blockchain storage system, the division of RSU node clusters in the blockchain storage system, and the master RSU node in each node cluster based on the block deployment solution with the optimal fitness value. This design can lower the threshold for node participation in the blockchain, reduce storage resource waste, and achieve a balance between block storage and data access.

Description

Technical Field

[0001] The present invention relates to the field of blockchain data storage technology, and in particular to a blockchain storage joint optimization method and system for the Internet of Vehicles. Background Art

[0002] With the development of blockchain technology, it has been widely applied in various fields, such as the internet, sensor networks, drones, and the Internet of Vehicles (IoV). However, due to the limited computing and storage resources of these devices, the ever-expanding blockchain ledger cannot be fully stored on a single device. This problem is particularly prominent in the IoV, where the real-time and high mobility of IoVs generate and exchange massive amounts of data, placing high demands on the blockchain's storage and processing capabilities. This often requires the assistance of a centralized cloud. However, data stored in centralized servers can be tampered with or deleted, lacking guaranteed traceability and accountability. In reality, blockchain's inherent immutability, decentralization, and transparency make it more reliable, cost-effective, and efficient than traditional database systems.

[0003] The integration of blockchain and the Internet of Vehicles (IoV) can enhance system security, privacy, and trust. As a distributed database, blockchain technology offers advantages such as decentralization, immutability, and transparency. Compared to traditional distributed databases, blockchain can operate in untrusted environments and maintain system security and reliability even in the presence of malicious nodes (such as Byzantine nodes). Therefore, addressing blockchain storage issues while leveraging these advantages and developing secure, traceable, and storage-efficient solutions is a key research topic. Summary of the Invention

[0004] The purpose of the present invention is to overcome the problem of insufficient storage and processing capabilities of blockchain in the field of Internet of Vehicles in the prior art, and to provide a blockchain storage joint optimization method and system for Internet of Vehicles.

[0005] To achieve the above objectives, the technical solution of the present invention is:

[0006] In a first aspect, the present invention provides a blockchain storage joint optimization method for an Internet of Vehicles (IoV), the blockchain storage joint optimization method comprising:

[0007] When the proportion of consumed storage resources of any RSU node cluster in the blockchain storage system to its total storage resources exceeds the preset threshold, the following steps are performed to update the block deployment:

[0008] S1. Randomly divide the RSU nodes in the blockchain storage system into multiple node clusters to obtain the target cluster solution.

[0009] S2. Optimize the target cluster partitioning scheme to obtain an optimized cluster scheme, and determine the master RSU node in each node cluster in the optimized cluster scheme;

[0010] S3. Calculate the target block deployment plan based on the optimized cluster plan;

[0011] S4. Optimizing the target block deployment plan to obtain an optimized block deployment plan, and acquiring a fitness value of the optimized block deployment plan;

[0012] S5. Repeat S1 to S4 until the repetition termination condition is reached, output the block deployment plan with the best fitness value in all the repetitions, and update the block deployment in the blockchain storage system, the division of node clusters in the blockchain storage system, and the master RSU node in each node cluster according to the block deployment plan with the best fitness value.

[0013] The step S1 comprises:

[0014] S101. Randomly generate multiple clustering schemes based on RSU nodes in the blockchain storage system, where each clustering scheme divides the RSU nodes in the blockchain storage system into n node clusters;

[0015] S102: Randomly select two of the multiple cluster solutions as target cluster solutions, select one of the n node clusters included in each target cluster solution, and exchange the two selected node clusters;

[0016] S103, checking the repeated RSU nodes in the target cluster solution, and deleting the repeated RSU nodes in each target cluster solution from the remaining n-1 node clusters except the selected node cluster;

[0017] S104: Add the RSU nodes in the blockchain storage system that are not included in the n node clusters of any target cluster solution to the cluster from which duplicate RSU nodes have been deleted.

[0018] The step S2 comprises:

[0019] S201, calculating the fitness values of the two target cluster solutions;

[0020] S202: For each target cluster solution, randomly select two from its corresponding n node clusters as target node clusters, randomly select an RSU node in each of the two target node clusters as a crossover node, swap the positions of the two crossover nodes, update the target cluster solution, and record the number of updates to the target cluster solution.

[0021] S203, calculating the fitness values of the two updated target clustering solutions;

[0022] S204: Determine whether the update times of the target clustering scheme reaches the upper limit of the first iteration times. If not, return to step S202. If yes, select the target clustering scheme corresponding to the optimal fitness value as the optimized clustering scheme.

[0023] S205. In the n node clusters corresponding to the optimized cluster solution, calculate the trust scores of all RSU nodes in each node cluster, and randomly select one of the five RSU nodes with the highest trust scores in each node cluster as the master node of the node cluster;

[0024] The first nodes Trust score Calculated according to the following formula:

[0025] ;

[0026] ;

[0027] ;

[0028] ;

[0029] ;

[0030] Where, For nodes Storage resource score; For nodes The remaining storage resources; For nodes Maximum storage capacity; For nodes historical performance scores; For nodes The performance score in the most recent historical period, where a historical period refers to the period from the start of one update of the partition of the RSU node cluster to the next update of the partition of the RSU node cluster; For nodes The highest performance score across all historical periods; For nodes Computing resource score; For nodes The remaining computing resources; is the maximum computing resource of the cluster; 、 、 are all weight coefficients.

[0031] The step S3 comprises:

[0032] S301, calculating the block deployment plan in each cluster using a greedy strategy to obtain a first deployment plan;

[0033] S302. Based on the weight of each block, determine the active blocks that require redundant backup. Taking the active blocks that require redundant backup as the object, calculate the backup deployment plan of each active block based on the first deployment plan according to the weight of each active block and the remaining storage resources of each cluster, and obtain the target block deployment plan.

[0034] In step S302, the weight of the block is calculated according to the following formula:

[0035] ;

[0036] ;

[0037] ;

[0038] ;

[0039] ;

[0040] Where, For blocks For the nodes The weight of Represents a block Node Frequency of inquiries; A node in a fixed time slot Block Number of queries; A node in a fixed time slot The total number of queries for all blocks; is the total number of blocks; For blocks Mining time parameters; is the current time, For blocks Time of creation; is the additional correction weight, According to the block Whether to include the node Directly related transactions are valued; For blocks Middle and Node The number of transactions involved; For blocks The total number of transactions in ; The weight of the corresponding block when the block deployment was last updated; 、 is the weighting coefficient.

[0041] The step S4 comprises:

[0042] S401, calculating the fitness value of the target block deployment solution through a fitness function;

[0043] S402: performing a random mutation operation on the target block deployment plan;

[0044] S403: Determine whether the target block deployment plan after the mutation operation meets the constraint conditions. If not, the mutation operation fails and the process returns to S402. If it meets the constraint conditions, the target block deployment plan is updated according to the result of the mutation operation and the update number of the target cluster plan is recorded.

[0045] S404: Calculate the fitness value of the updated target block deployment solution using a fitness function;

[0046] S405: Determine whether the update times of the target block deployment plan reaches the second iteration number upper limit. If not, return to step S402. If so, select the target block deployment plan corresponding to the optimal fitness value as the optimized block deployment plan.

[0047] The fitness function is:

[0048] ;

[0049] The constraints are:

[0050] ;

[0051] ;

[0052] ;

[0053] In the formula, the variable is an indicator function, indicating the Blocks Is it stored in nodes Up, if , then it means the Blocks Stored in nodes Up, if , then it means the Blocks Not stored in nodes superior; It's a block The amount of storage space required; is the storage resource of the corresponding node; For blocks The weight of For nodes The set of communication delays with all other nodes; For nodes and nodes Communication costs between is the collection of all node clusters in the cluster solution, For the cluster solution A cluster of nodes; is the set of all blocks; is the total number of blocks; is the total number of nodes; For cluster solutions The storage resources of the nodes in the cluster; is the sum of all block sizes.

[0054] In a second aspect, the present invention provides a blockchain storage joint optimization system for the Internet of Vehicles, comprising:

[0055] The cluster partitioning module is used to randomly partition the RSU nodes in the blockchain storage system into multiple node clusters to obtain the target cluster solution;

[0056] The cluster optimization module is used to optimize the target cluster partitioning scheme, obtain an optimized cluster scheme, and determine the master node in each node cluster in the optimized cluster scheme;

[0057] The blockchain deployment module is used to calculate the target block deployment plan based on the optimized cluster plan;

[0058] A deployment optimization module is used to optimize the target block deployment plan to obtain an optimized block deployment plan and obtain a fitness value of the optimized block deployment plan;

[0059] The loop module is used to repeatedly run the above cluster division module to the optimization deployment module until the repeated termination condition is reached, output the block deployment plan with the best fitness value in all the repeated processes, and update the deployment of blocks in the blockchain storage system, the division of RSU node clusters in the blockchain storage system, and the main RSU nodes in each node cluster according to the block deployment plan with the best fitness value.

[0060] In a third aspect, the present invention provides an electronic device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of any one of the above-mentioned methods for joint optimization of blockchain storage for the Internet of Vehicles are implemented.

[0061] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing a computer program; when the computer program is executed by a processor, the steps of any one of the above-mentioned blockchain storage joint optimization methods for the Internet of Vehicles are implemented.

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

[0063] 1. In a blockchain storage joint optimization method for the Internet of Vehicles, the present invention divides the RSU nodes into clusters, calculates the optimized target cluster solution through a genetic algorithm, and then calculates the target block deployment solution based on the optimized target cluster solution. The target block deployment solution is subjected to a bit mutation operation and iterated to obtain an optimized block deployment solution. The above operation is then repeated until the number of repetitions reaches a preset upper limit to obtain an optimized cluster and block deployment solution. The above process jointly optimizes the cluster division and block storage process, and utilizes cluster storage blocks to enable node cluster division and block storage to achieve optimal coordination, optimize the storage structure, reduce the storage requirements of each node, and maintain data integrity and availability. Therefore, this design jointly optimizes the cluster division and block storage process, enables cluster division and block storage to achieve optimal coordination, optimizes the storage structure, reduces the storage requirements of each node, and maintains data integrity and availability.

[0064] 2. In a blockchain storage joint optimization method for the Internet of Vehicles (IoV), the present invention divides the numerous RSU nodes in the system into multiple clusters. Each cluster includes multiple RSU nodes in a target area. Each RSU node cluster represents a peer in the blockchain network. Multiple peers jointly achieve blockchain storage consensus, effectively improving deployment efficiency. Therefore, this design divides the node clusters, each node cluster represents a peer in the blockchain network, and jointly achieves blockchain storage consensus, effectively improving deployment efficiency.

[0065] 3. In the blockchain storage joint optimization method for the Internet of Vehicles (IoV) of the present invention, during block deployment, block weights are calculated based on query frequency and mining time to determine whether the block is active. Based on the block's activity level, weight, and the storage resource requirements of the node cluster, the necessity of block storage is evaluated, and the block is deployed to further optimize the storage structure. Therefore, this design calculates block weights and deploys blocks based on the block's activity level, weight, and the storage resource requirements of the node cluster to further optimize the storage structure. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 This is a flow chart of a blockchain storage joint optimization method for the Internet of Vehicles provided by an embodiment of the present invention.

[0067] Figure 2 This is a flow chart of a target cluster solution generation method provided by an embodiment of the present invention.

[0068] Figure 3 This is a flow chart of a method for optimizing a target cluster solution provided by an embodiment of the present invention.

[0069] Figure 4 It is a flow chart of a calculation target block deployment solution provided by an embodiment of the present invention.

[0070] Figure 5 It is a flowchart of optimizing the target block deployment solution provided by an embodiment of the present invention.

[0071] Figure 6 This is a structural diagram of a blockchain storage joint optimization system for the Internet of Vehicles provided by an embodiment of the present invention.

[0072] Figure 7 This is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0073] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0074] The integration of blockchain and the Internet of Vehicles (IoV) can enhance the system's security, privacy, and trustworthiness. However, in related technologies, the ever-expanding blockchain ledger cannot be fully stored on a single device due to limited computing and storage resources. At the same time, the real-time and high mobility of the IoV will result in the generation and exchange of large amounts of data, placing higher demands on the blockchain's storage and processing capabilities.

[0075] To address the issue of insufficient blockchain storage capacity in connected vehicles (IoV) systems, an embodiment of the present invention provides a joint optimization method for IoV blockchain storage. This method jointly optimizes node clustering and block deployment to ensure efficient data access. This method not only lowers the barrier to entry for nodes and reduces storage resource waste, but also effectively addresses access latency issues associated with collaborative storage, achieving a balance between block storage and data access.

[0076] The blockchain storage joint optimization method for the Internet of Vehicles is based on a blockchain storage system, which includes RSU nodes in a specified area. The RSU nodes in the blockchain storage system are divided into multiple node clusters. The master RSU node in each node cluster distributes the newly generated blocks to one or more nodes in the node cluster for storage.

[0077] In this embodiment, we divide the road-side units (RSUs) into multiple node clusters. By grouping the road-side units into node clusters, the nodes within the clusters collaborate to store the complete blockchain ledger, thus meeting the ever-expanding storage needs in resource-constrained systems.

[0078] Blockchain is a distributed ledger technology that uses encryption algorithms to store data blocks in a chain structure. It has the characteristics of decentralization, immutability, and transparency, making it very suitable for recording transactions, sharing data, and other scenarios. The application advantages of blockchain technology in the Internet of Vehicles are significant, mainly reflected in enhancing data security, promoting efficient data sharing, improving transaction efficiency, and realizing decentralized identity authentication. It provides solid technical support for the rapid development and intelligent application of the Internet of Vehicles.

[0079] In this embodiment, the blockchain storage system includes both light nodes and full nodes. Vehicles function as light nodes, while roadside units (RSUs) function as full nodes, jointly constructing a blockchain storage and consensus framework for the connected vehicle network. In this blockchain storage system, vehicle nodes, due to their high dynamic nature and limited storage resources, only store block headers and participate in data verification and querying, without needing to store the entire blockchain or participate in complex consensus. RSUs, on the other hand, function as full nodes, responsible for storing the blockchain ledger and participating in the consensus process. Specifically, multiple roadside units (RSUs) form a node cluster. Within a node cluster, multiple RSUs collaborate to store the entire blockchain. Multiple RSUs within the same node cluster share different blocks, distributing storage and computational loads to cope with the growth of blockchain data.

[0080] In the blockchain consensus mechanism, multiple peer nodes are usually required to participate in decision-making. We can regard each node cluster as a peer, and select a master node within each cluster to be responsible for achieving the consensus process at the cluster level, thereby ensuring the consistency of the system. The functions of the master node include:

[0081] Storage table maintenance: The master node is responsible for managing the block storage table within the cluster, recording information such as the block storage location, redundant backup plan, and access frequency. Since the master node is dynamically elected, storage table management must ensure that the previous storage table information can be seamlessly inherited and synchronized after the master node changes, thereby ensuring consistent access to blocks by all nodes in the cluster. To this end, a redundant backup and synchronization mechanism is adopted to ensure the reliability and stability of the storage table when the master node changes;

[0082] Data query and verification: When other nodes (such as vehicles or base stations) need to query data in the static blockchain, the master node can serve as the query entry point to ensure query speed and data consistency;

[0083] Fault recovery: When a secondary node fails, the primary node can restore the lost data of the secondary node through collaborative storage, ensuring that the system can quickly return to normal state;

[0084] Node management and trust evaluation: The master node can be responsible for managing the nodes in the cluster and performing node trust evaluation.

[0085] Specifically, once the master node is determined, the block generation and consensus phase begins. The specific process is as follows:

[0086] Block generation: The master node generates a new block based on the current blockchain status within the cluster and the data of the Internet of Vehicles.

[0087] Consensus protocol: PBFT (Practical Byzantine Fault Tolerance) or other consensus protocols adapted to the Internet of Vehicles (IoV) environment (such as Proof of Storage) are used, with the primary node and secondary nodes jointly verifying the legitimacy and integrity of the new block.

[0088] Block Verification: Within the cluster, secondary nodes participate in the verification process of new blocks to ensure the validity of the blocks. After verification, the block is marked as valid.

[0089] After consensus verification, the newly generated block is officially added to the blockchain's overall ledger, forming a record available to the entire network. At this point, the new block is synchronized by nodes in each node cluster and broadcast to other clusters or external systems. Specifically, the master node propagates the new block to nodes in other clusters via a peer-to-peer network to ensure blockchain consistency across the entire network. All nodes update their own blockchain data and store the new block's header.

[0090] The blockchain storage joint optimization method includes: when the proportion of consumed storage resources of any node cluster in the blockchain storage system to its total storage resources exceeds a resource consumption threshold, executing steps S1 to S5 to update the RSU node cluster division in the blockchain storage system, the master RSU node in each node cluster, and the deployment of blocks.

[0091] In a distributed Internet of Vehicles system, when the storage resource consumption of a cluster approaches a threshold, the system needs to automatically trigger the redeployment of the blockchain ledger to ensure data consistency and integrity.

[0092] In this embodiment, a storage resource consumption ratio threshold is set for each node cluster according to the system situation. When the storage resource usage ratio of the node cluster exceeds this ratio, the algorithm is triggered to call and update the cluster division and block deployment. Node cluster , when its storage resource usage exceeds When , the redeployment of the blockchain ledger is automatically triggered. Formula middle, For the The total storage resources in the node cluster.

[0093] See Figure 1 , Figure 1 This is a flow chart of updating the RSU node cluster division, the master RSU node in each node cluster, and the block deployment in a blockchain storage system provided by an embodiment of the present invention. The method includes steps S1 to S5.

[0094] S1. Divide the RSU nodes in the blockchain storage system into multiple node clusters in a random manner to obtain the target cluster solution.

[0095] In this embodiment, each node cluster consists of multiple roadside units (RSU nodes). Since the storage resources of each node are limited, a node cluster maintains at least one filtered complete blockchain copy through collaborative storage.

[0096] The optimized clustering scheme can be obtained by continuously optimizing the fitness function. Specifically, Figure 2 This is a flow chart of a method for generating a target cluster solution provided by an embodiment of the present invention. Figure 2 As shown, the RSU nodes in the blockchain storage system are randomly divided into multiple node clusters, and the target cluster solution includes steps S101 to S104:

[0097] S101. Based on the RSU nodes in the blockchain storage system, randomly generate multiple clustering schemes, wherein each clustering scheme divides the RSU nodes in the blockchain storage system into n node clusters.

[0098] In this embodiment, for any generated clustering scheme, the clustering scheme divides the RSU nodes in the blockchain storage system into n non-overlapping node clusters, each of which corresponds to a node list, and the node list records all RSU nodes in the corresponding node cluster.

[0099] S102 . Randomly select two target cluster solutions from the multiple cluster solutions. For each target cluster solution, select one from the n node clusters contained therein, exchange the two selected node clusters, and update the contents of the two target cluster solutions according to the exchange result.

[0100] Specifically, two target clustering solutions are selected, a node list is randomly selected from the n node lists corresponding to each target clustering solution, and the two selected node lists are exchanged to obtain two updated target clustering solutions.

[0101] After exchanging the node lists in the two target clustering schemes, the target cluster scheme may miss some RSU nodes or duplicate some RSU nodes. Therefore, it is necessary to correct the target cluster scheme after exchanging the node lists to avoid the above-mentioned node omission and duplication problems.

[0102] S103 : Check the repeated RSU nodes in the updated target cluster solution, and delete the repeated RSU nodes in each target cluster solution from the remaining n-1 node clusters except the selected node cluster.

[0103] Taking the duplicate RSU nodes in the n node clusters corresponding to the target cluster solution as the object, we delete them in the remaining n-1 node clusters except the selected node cluster, and in subsequent steps, add RSU nodes in the blockchain storage system that do not appear in the n node clusters corresponding to the target cluster solution.

[0104] S104. Add the RSU nodes in the blockchain storage system that are not included in the n node clusters of any target cluster solution to the cluster from which duplicate nodes have been deleted, so that the n node clusters of each target cluster solution include all RSU nodes in the blockchain storage system, ensuring the integrity of the cluster solution.

[0105] S2. Optimize the target cluster partitioning scheme to obtain an optimized cluster scheme, and determine the master RSU node in each node cluster in the optimized cluster scheme.

[0106] After generating the target cluster solution, we need to continue to optimize it. Specifically, Figure 3 FIG. 1 is a flow chart of an optimization method for a target cluster solution provided by an embodiment of the present invention. Figure 3 As shown, optimizing the target cluster solution to obtain an optimized cluster solution and determining the master RSU node in each node cluster in the optimized cluster solution includes steps S201 to S205:

[0107] S201. Calculate the fitness values of the two target clustering solutions.

[0108] In this embodiment, we calculate the fitness value of the target cluster solution through the fitness function, and the fitness function is:

[0109] (1);

[0110] The constraints are:

[0111] (2);

[0112] (3);

[0113] (4);

[0114] In the formula, the variable is an indicator function, indicating the Blocks Is it stored in nodes Up, if , then it means the Blocks Stored in nodes Up, if , then it means the Blocks Not stored in nodes superior; It's a block The amount of storage space required; is the storage resource of the corresponding node; For blocks The weight of For nodes The set of communication delays with all other nodes; For nodes and nodes Communication costs between is the collection of all node clusters in the cluster solution, For the cluster solution A cluster of nodes; is the set of all blocks; is the total number of blocks; is the total number of RSU nodes; For cluster solutions The storage resources of the RSU nodes in the cluster; is the sum of all block sizes.

[0115] The above formula (1) is the optimization goal, that is, the lowest communication cost is the optimal goal; formula (2) limits the storage resources of the RSU node, that is, the total size of all blocks stored on each RSU node cannot exceed the storage capacity of the node; formula (3) puts forward additional constraints on the blockchain in the cluster, requiring each block to have at least one backup. This constraint ensures the redundancy and reliability of the data, so that the system can still maintain the integrity and availability of the data when a node failure occurs; formula (4) limits the total resources of all RSU nodes in the cluster to ensure that each RSU node can collaborate to store the entire blockchain. This constraint aims to balance the system load, optimize the allocation and use of resources, and thus improve the overall performance and efficiency of the blockchain network.

[0116] Since the current target cluster solution does not correspond to a block deployment solution, in order to calculate the fitness value of the corresponding target cluster solution, we can calculate an initial deployment solution for the current target cluster solution and calculate the fitness value based on the initial deployment solution. Specifically, calculating the fitness values of the two target cluster solutions using the fitness function includes: based on the target cluster solution, calculating the deployment solution of each block using a greedy strategy, then calculating the fitness value of the target cluster solution based on the deployment solution of each block and the fitness function, and then judging the quality of the cluster solution by the fitness value.

[0117] We can also use other fitness functions or algorithms to calculate the fitness value of the target clustering solution, and then compare the advantages and disadvantages of each target clustering solution.

[0118] S202. For each target cluster solution, randomly select two from its corresponding n node clusters as target node clusters, randomly select a node in each of the two target node clusters as a cross node, swap the positions of the two cross nodes, update the contents of the two target cluster solutions according to the swap result, and record the number of updates to the target cluster solutions.

[0119] S203: Calculate the fitness values of the two updated target clustering solutions using a fitness function.

[0120] S204: Determine whether the update times of the target clustering scheme reaches the preset upper limit of the first iteration times. If not, return to step S202. If yes, select the target clustering scheme corresponding to the optimal fitness value in all the iterations as the optimized clustering scheme.

[0121] S205. In the n node clusters corresponding to the optimized cluster solution, calculate the trust scores of all RSU nodes in each node cluster, and randomly select one of the five RSU nodes with the highest trust scores in each node cluster as the master node of the node cluster;

[0122] The first nodes Trust score Calculated according to the following formula:

[0123] ;

[0124] ;

[0125] ;

[0126] ;

[0127] ;

[0128] Where, For nodes Storage resource score; For nodes The remaining storage resources; For nodes Maximum storage capacity; For nodes historical performance scores; For nodes The performance score in the most recent historical period, where a historical period refers to the period from the start of one update of the partition of the RSU node cluster to the next update of the partition of the RSU node cluster; For nodes The highest performance score across all historical periods; For nodes Computing resource score; For nodes The remaining computing resources; is the maximum computing resource of the cluster; 、 、 are all weight coefficients.

[0129] After the iteration is complete, the master node for the current consensus round is elected based on the trust of the nodes in the cluster, the storage resource score, the node's historical performance (whether it has been elected as the master node), and the computing resource score, thereby ensuring efficient data verification and storage. The storage resource score is used to evaluate the node's storage capacity; the computing resource score can be calculated by calculating the ratio of the node's remaining computing power to the maximum computing power of the nodes in the cluster. The computing resource score is used to evaluate the node's computing power; the performance score of the RSU node in any historical cycle is determined based on whether the node was the master node during that cycle. Therefore, the historical performance score of each RSU node is related to whether the node has been elected as the master node. Based on the node's historical performance, that is, whether each RSU node has been elected as the master node and the number of times each RSU node has been elected as the master node in each historical cycle, we normalize the historical performance score to a value in the range [0,1]. Therefore, if an RSU node has been a master node, its historical performance score is relatively higher.

[0130] Each cluster utilizes a state-machine-based Byzantine Fault Tolerance (PBFT) consensus mechanism, ensuring data consistency and reliability within the cluster through inter-node messaging and voting protocols. The master node in each cluster is responsible for block generation and verifies the legitimacy and integrity of block content through a consensus protocol. Ultimately, the generated blocks are merged into the global blockchain to ensure global ledger consistency and decentralized security. Furthermore, master nodes can collaborate with master nodes in other clusters in a peer-to-peer manner to back up new blocks generated by each other's clusters.

[0131] Because some nodes, due to their past experience as leader nodes, may be more likely to be re-elected in subsequent rounds, randomness is introduced into the leader node election process to prevent a "rich get richer" phenomenon. Specifically, a random selection of the top five nodes by score is made as the leader node for the current round. This strategy plays a key role in balancing node resource advantages with election fairness, preventing a single node from consistently dominating leader node elections due to historical performance or resource advantages, thereby improving the fairness and robustness of the system.

[0132] S3. Calculate the target block deployment plan based on the optimized cluster plan.

[0133] After obtaining the optimized clustering scheme, we calculate the initial block deployment plan based on the optimized clustering scheme.

[0134] Because block size is dependent on the number of transactions stored, it is not fixed. Each cycle, the blockchain packages the transactions within that cycle into a new block and adds it to the blockchain. As the number of blocks in the blockchain system increases, the blockchain ledger grows rapidly, making it difficult for a single node to store all blocks since the genesis block.

[0135] Therefore, we adopt a node cluster model to collaboratively store the entire blockchain ledger. A node cluster is composed of no less than three RSU nodes in the same geographical location. Within a fixed time window, for each node in the cluster, accessing different blocks will generate the node's access frequency to the block. At the same time, combined with the time when the block was generated, we can define the weight of the block to evaluate the necessity of block storage. We deploy according to the weight alignment of the block. Specifically, Figure 4 This is a flow chart of a calculation target block deployment solution provided by an embodiment of the present invention. Figure 4 As shown, based on the optimized cluster solution, calculating the target block deployment solution includes steps S301 to S302:

[0136] S301. Calculate the block deployment plan in each cluster using a greedy strategy to obtain a first deployment plan.

[0137] Specifically, based on the clustering solution with the best fitness value, calculating the first deployment solution of each block by a greedy strategy includes:

[0138] For each cluster, the available storage resources of each RSU node within it are determined. Following the greedy strategy, RSU nodes are assigned to each block one by one until all blocks are assigned. This results in a first deployment plan that specifies the specific node and cluster where each block should be deployed. The greedy strategy prioritizes allocating blocks to nodes with the most storage resources.

[0139] S302: Based on the weights of each block, active blocks requiring redundant backup are determined. Based on the first deployment plan, a backup deployment plan for each active block is calculated based on the weights of each active block and the remaining storage resources of each cluster. The target block deployment plan is then obtained by combining the first deployment plan and the backup deployment plan for each active block. Calculating the backup deployment plan for each active block includes allocating the backups of each active block to the nodes with the most remaining storage resources, in order according to the weights of the active blocks.

[0140] After obtaining the target block deployment plan, we need to ensure that the deployment plan meets the constraints. We calculate whether the target block deployment plan meets the constraints. If not, we need to adjust the target block deployment plan by adjusting the storage status and storage location of the blocks in the plan until the target block deployment plan meets the constraints.

[0141] In this embodiment, in the block deployment solution, we record the blocks allocated to each RSU node by storing a table matrix.

[0142] Specifically, the activity of a block is determined by its weight, which is calculated according to the following formula:

[0143] ;

[0144] ;

[0145] ;

[0146] ;

[0147] ;

[0148] Where, For the first Blocks For the nodes The weight of Represents a block Node Frequency of inquiries; A node in a fixed time slot Block Number of queries; A node in a fixed time slot The total number of queries for all blocks; is the total number of blocks; For blocks The mining time parameter, is the current time, For blocks Time of creation; is the additional correction weight, According to the block Whether to include the node Directly related transactions are valued; For blocks Middle and Node The number of transactions involved; For blocks The total number of transactions in ; The corresponding block when the block deployment was last updated The weight of 、 is the weighting coefficient.

[0149] Adding a correction factor improves the flexibility and accuracy of weight calculations, enabling them to better reflect the relevance between blocks and nodes. Compared to evaluation methods that rely solely on access frequency or time decay parameters, the introduction of a correction factor significantly improves the discriminability of block importance assessments, enabling the system to prioritize the backup and allocation of active blocks containing critical transactions, improving the real-time and effectiveness of data storage in the Internet of Vehicles, and thus better supporting the needs of dynamic vehicle interaction and efficient data transmission.

[0150] In this example, we define the block The query frequency for RSU nodes Query blocks within a consensus cycle The ratio of the number of queries to the total number of queries for all other blocks. The more frequently a block is queried, the higher its weight will be. Generally speaking, new blocks are queried more frequently than old blocks. Therefore, we consider the impact of mining time on block weight and assign higher weights to recently mined blocks. According to the above weight calculation formula, the higher the query frequency, the higher the weight. The larger the parameter value, the more active the block.

[0151] Through the above calculations, we can obtain the weight of the block for each node. Since the weight can effectively reflect the activity level of the corresponding block, we calculate the weight of each block in the blockchain and, based on the weight and the remaining storage resources of each RSU node in the node cluster, determine whether each block needs redundant backup and the deployment location of each backup block in descending order of corresponding weight.

[0152] The weight of a block is calculated based on the frequency of queries for a block by different nodes in the node cluster within a fixed time window, the block generation time, and the relationship between transactions within the block and the nodes. After obtaining a preliminary deployment plan for the entire blockchain ledger, it is considered to redeploy blocks with higher weights to nodes with redundant storage resources to improve data access efficiency and optimize system performance.

[0153] S4. Optimize the target block deployment plan to obtain an optimized block deployment plan, and obtain the fitness value of the optimized block deployment plan. Specifically, Figure 5 This is a flow chart of optimizing the target block deployment solution provided by an embodiment of the present invention. Figure 5 As shown, optimizing the target block deployment scheme to obtain an optimized block deployment scheme, and calculating the fitness value of the optimized block deployment scheme according to the fitness function include steps S401 to S405:

[0154] S401: Calculate the fitness value of the target block deployment solution using a fitness function.

[0155] S402, performing a mutation operation on the target block deployment plan;

[0156] Specifically, the mutation operation refers to randomly changing the number or type of blocks stored on the RSU nodes in the block deployment plan. Since we use a storage table matrix to record the blocks allocated to each RSU node, we can mutate the target block deployment plan by modifying the variables in the storage table matrix.

[0157] Specifically, after performing a mutation operation on the target block deployment plan, it is determined whether the target block deployment plan after the mutation operation meets the constraint conditions of the fitness function.

[0158] S403: Determine whether the target block deployment plan after the mutation operation meets the constraint conditions. If not, the mutation operation fails and the process returns to S402. If it meets the constraint conditions, the target block deployment plan is updated according to the result of the mutation operation and the update number of the target cluster plan is recorded.

[0159] S404: Calculate the fitness value of the updated target block deployment solution through a fitness function;

[0160] S405. Determine whether the update times of the target block deployment plan has reached the second iteration limit. If not, return to step S402. If so, select the target block deployment plan corresponding to the optimal fitness value obtained in all previous calculations as the optimized block deployment plan.

[0161] S5. Repeat S1 to S4 above until the repetition termination condition is reached, and output the block deployment plan with the best fitness value in all the repetitions and its corresponding optimized cluster plan, the master node of each cluster in the cluster plan, update the deployment of blocks in the blockchain storage system according to the block deployment plan with the best fitness value, and update the division of node clusters in the blockchain storage system and the master RSU node in each node cluster according to the corresponding optimized cluster plan and the master node of each cluster in the cluster plan.

[0162] The repetition termination condition is that the number of repetitions reaches the preset upper limit. The repetition termination condition can also be set as the change in the fitness value of the optimized block deployment scheme in the last M repetitions is lower than the set threshold. .

[0163] In summary, the embodiments of the present invention provide a blockchain storage joint optimization method for the Internet of Vehicles (IoV). This method jointly optimizes node clustering and block deployment. This method not only lowers the threshold for node participation in the blockchain and reduces the waste of storage resources, but also effectively solves the access latency problem caused by collaborative storage, achieving a balance between block storage and data access. We used this blockchain storage joint optimization method to conduct simulation experiments. Under a network environment nearly identical to that of existing commonly used solutions, the block access cost of this method was much lower than that of other methods. We also compared cluster division schemes with different numbers of nodes and blocks. The results show that this scheme maintains its stable advantages under different environmental conditions.

[0164] Based on the method described in the above embodiment, this embodiment will be further described from the perspective of a blockchain storage joint optimization system for the Internet of Vehicles. The blockchain storage joint optimization system for the Internet of Vehicles can be implemented as an independent entity or integrated into an electronic device, such as a terminal. The terminal may include a mobile phone, a tablet computer, etc.

[0165] See Figure 6 , Figure 6 This is a structural diagram of a blockchain storage joint optimization system for Internet of Vehicles provided by an embodiment of the present invention, such as Figure 6 As shown, the blockchain storage joint optimization system for the Internet of Vehicles provided by the embodiment of the present invention includes:

[0166] A cluster partitioning module is used to randomly partition the RSU nodes in the blockchain storage system into multiple node clusters to obtain a target cluster solution. The cluster partitioning module is used to execute the steps in S1;

[0167] A cluster optimization module is used to optimize the target cluster partitioning scheme to obtain an optimized cluster scheme and determine the master node in each node cluster in the optimized cluster scheme. The cluster optimization module is used to execute the steps in S2;

[0168] The blockchain deployment module is used to calculate the target block deployment plan based on the optimized cluster plan. The blockchain deployment module is used to execute the steps in S3;

[0169] A deployment optimization module is used to optimize the target block deployment plan to obtain an optimized block deployment plan and acquire a fitness value of the optimized block deployment plan. The deployment optimization module is used to execute the steps in S4;

[0170] The loop module is used to repeatedly run the above cluster division module to the optimization deployment module until the repetition termination condition is reached, output the block deployment plan with the best fitness value in all the repetitions, and update the deployment of blocks in the blockchain storage system, the division of node clusters in the blockchain storage system, and the main RSU nodes in each node cluster according to the block deployment plan with the best fitness value. The loop module is used to execute the steps in S5.

[0171] Also, see Figure 7 , Figure 7 is a structural diagram of an electronic device provided by an embodiment of the present invention, such as Figure 6 As shown, the electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps in the above-mentioned blockchain storage joint optimization method for the Internet of Vehicles are implemented.

[0172] Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be accomplished through instructions, or by controlling related hardware through instructions. The instructions can be stored in a computer-readable storage medium and loaded and executed by a processor. To this end, an embodiment of the present invention provides a storage medium storing a plurality of instructions that, when executed by a processor, can implement the steps of the above-described blockchain storage joint optimization method for the Internet of Vehicles.

[0173] Generally speaking, computer instructions for implementing the method of the present invention may be carried by any combination of one or more computer-readable storage media. Non-transitory computer-readable storage media may include any computer-readable media except for signals that are temporarily propagating.

[0174] Computer-readable storage media may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. For purposes of the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0175] Computer program code for performing the operations of the present invention can be written in one or more programming languages, or a combination thereof. These programming languages include object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as C or similar programming languages. In particular, Python, which is suitable for neural network computing, and platform frameworks based on TensorFlow, PyTorch, etc. can be used. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer via various types of networks, including a local area network (LAN) or a wide area network (WAN), or via the Internet via an Internet service provider.

[0176] Although the embodiments of the present invention have been shown and described above, it should be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.

Claims

1. A blockchain storage joint optimization method for Internet of Vehicles, characterized in that: The blockchain storage joint optimization method includes: When the proportion of consumed storage resources of any RSU node cluster in the blockchain storage system to its total storage resources exceeds the preset threshold, the following steps are performed to update the block deployment: S1. Randomly divide the RSU nodes in the blockchain storage system into multiple node clusters to obtain the target cluster solution. S2. Optimize the target cluster partitioning scheme to obtain an optimized cluster scheme, and determine the master RSU node in each node cluster in the optimized cluster scheme; S3. Calculate the target block deployment plan based on the optimized cluster plan; S4. Optimizing the target block deployment plan to obtain an optimized block deployment plan, and acquiring a fitness value of the optimized block deployment plan; S5. Repeat S1 to S4 above until the repetition termination condition is reached, output the block deployment plan with the best fitness value in all the repetitions, and update the block deployment in the blockchain storage system, the division of RSU node clusters in the blockchain storage system, and the master RSU node in each node cluster according to the block deployment plan with the best fitness value; The step S3 comprises: S301, calculating the block deployment plan in each cluster using a greedy strategy to obtain a first deployment plan; S302: Based on the weights of the blocks, determine the active blocks that require redundant backup. Taking the active blocks that require redundant backup as the target, calculate a backup deployment plan for each active block based on the first deployment plan according to the weights of the active blocks and the remaining storage resources of each cluster, and obtain a target block deployment plan. The step S4 comprises: S401, calculating the fitness value of the target block deployment solution through a fitness function; S402: performing a random mutation operation on the target block deployment plan; S403: Determine whether the target block deployment plan after the mutation operation meets the constraint conditions. If not, the mutation operation fails and the process returns to S402. If it meets the constraint conditions, the target block deployment plan is updated according to the result of the mutation operation and the update number of the target cluster plan is recorded. S404: Calculate the fitness value of the updated target block deployment solution using a fitness function; S405: Determine whether the update times of the target block deployment plan reaches the second iteration number upper limit. If not, return to step S402. If so, select the target block deployment plan corresponding to the optimal fitness value as the optimized block deployment plan.

2. The blockchain storage joint optimization method for the Internet of Vehicles according to claim 1 is characterized in that: The step S1 comprises: S101. Randomly generate multiple clustering schemes based on RSU nodes in the blockchain storage system, where each clustering scheme divides the RSU nodes in the blockchain storage system into n node clusters; S102: Randomly select two of the multiple cluster solutions as target cluster solutions, select one of the n node clusters included in each target cluster solution, and exchange the two selected node clusters; S103, checking the repeated RSU nodes in the target cluster solution, and deleting the repeated RSU nodes in each target cluster solution from the remaining n-1 node clusters except the selected node cluster; S104: Add the RSU nodes in the blockchain storage system that are not included in the n node clusters of any target cluster solution to the cluster from which duplicate RSU nodes have been deleted.

3. The blockchain storage joint optimization method for the Internet of Vehicles according to claim 2 is characterized in that: The step S2 comprises: S201, calculating the fitness values of the two target cluster solutions; S202: For each target cluster solution, randomly select two from its corresponding n node clusters as target node clusters, randomly select an RSU node in each of the two target node clusters as a crossover node, swap the positions of the two crossover nodes, update the target cluster solution, and record the number of updates to the target cluster solution. S203, calculating the fitness values of the two updated target clustering solutions; S204: Determine whether the update times of the target clustering scheme reaches the upper limit of the first iteration times. If not, return to step S202. If yes, select the target clustering scheme corresponding to the optimal fitness value as the optimized clustering scheme. S205. In the n node clusters corresponding to the optimized cluster solution, calculate the trust scores of all RSU nodes in each node cluster, and randomly select one of the five RSU nodes with the highest trust scores in each node cluster as the master node of the node cluster; The first nodes Trust score Calculated according to the following formula: ； ； ； ； ； Where, For nodes Storage resource score; For nodes The remaining storage resources; For nodes Maximum storage capacity; For nodes historical performance scores; For nodes The performance score in the most recent historical period, where a historical period refers to the period from the start of one update of the partition of the RSU node cluster to the next update of the partition of the RSU node cluster; For nodes The highest performance score across all historical periods; For nodes Computing resource score; For nodes The remaining computing resources; is the maximum computing resource of the cluster; 、 、 are all weight coefficients.

4. The blockchain storage joint optimization method for the Internet of Vehicles according to claim 3 is characterized in that: In step S302, the weight of the block is calculated according to the following formula: ； ； ； ； ； Where, For blocks For the nodes The weight of Represents a block Node Frequency of inquiries; A node in a fixed time slot Block Number of queries; A node in a fixed time slot The total number of queries for all blocks; is the total number of blocks; For blocks Mining time parameters; is the current time, For blocks Time of creation; is the additional correction weight, According to the block Whether to include the node Directly related transactions are valued; For blocks Middle and Node The number of transactions involved; For blocks The total number of transactions in ; The weight of the corresponding block when the block deployment was last updated; 、 is the weighting coefficient.

5. The blockchain storage joint optimization method for the Internet of Vehicles according to claim 1 is characterized in that: The fitness function is: ； The constraints are: ； ； ； In the formula, the variable is an indicator function, indicating the Blocks Is it stored in nodes Up, if , then it means the Blocks Stored in nodes Up, if , then it means the Blocks Not stored in nodes superior; It's a block The amount of storage space required; is the storage resource of the corresponding node; For blocks The weight of For nodes The set of communication delays with all other nodes; For nodes and nodes Communication costs between is the collection of all node clusters in the cluster solution, For the cluster solution A cluster of nodes; is the set of all blocks; is the total number of blocks; is the total number of nodes; For cluster solutions The storage resources of the nodes in the cluster; is the sum of all block sizes.

6. A blockchain storage joint optimization system for the Internet of Vehicles, comprising: The cluster partitioning module is used to randomly partition the RSU nodes in the blockchain storage system into multiple node clusters to obtain the target cluster solution; The cluster optimization module is used to optimize the target cluster partitioning scheme, obtain an optimized cluster scheme, and determine the master node in each node cluster in the optimized cluster scheme; The blockchain deployment module is used to calculate the target block deployment plan based on the optimized cluster plan, including: S301, calculating the block deployment plan in each cluster using a greedy strategy to obtain a first deployment plan; S302: Based on the weights of the blocks, determine the active blocks that require redundant backup. Taking the active blocks that require redundant backup as the target, calculate a backup deployment plan for each active block based on the first deployment plan according to the weights of the active blocks and the remaining storage resources of each cluster, and obtain a target block deployment plan. The deployment optimization module is used to optimize the target block deployment plan to obtain an optimized block deployment plan and obtain the fitness value of the optimized block deployment plan, including: S401, calculating the fitness value of the target block deployment solution through a fitness function; S402: performing a random mutation operation on the target block deployment plan; S403: Determine whether the target block deployment plan after the mutation operation meets the constraint conditions. If not, the mutation operation fails and the process returns to S402. If it meets the constraint conditions, the target block deployment plan is updated according to the result of the mutation operation and the update number of the target cluster plan is recorded. S404: Calculate the fitness value of the updated target block deployment solution using a fitness function; S405: Determine whether the update times of the target block deployment plan reaches the second iteration number upper limit. If not, return to step S402. If yes, select the target block deployment plan corresponding to the optimal fitness value as the optimized block deployment plan. The loop module is used to repeatedly run the above cluster division module to the optimization deployment module until the repeated termination condition is reached, output the block deployment plan with the best fitness value in all the repeated processes, and update the deployment of blocks in the blockchain storage system, the division of RSU node clusters in the blockchain storage system, and the main RSU nodes in each node cluster according to the block deployment plan with the best fitness value.

7. An electronic device, characterized in that: The electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the method according to any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the method according to any one of claims 1 to 5 are implemented.

Images