Block chain storage joint optimization method and system for Internet of Vehicles

Abstract

The static block chain storage joint optimization method for the Internet of Vehicles comprises the following steps: dividing RSU nodes in a block chain storage system into a plurality of node clusters in a random manner to obtain a target cluster scheme; optimizing the target cluster scheme to obtain an optimized cluster scheme, and determining a main RSU node in each node cluster; calculating a target block deployment scheme; optimizing the target block deployment scheme to obtain an optimized block deployment scheme and calculating a fitness value; and repeating the above steps until a repetition termination condition is reached, outputting a block deployment scheme with the optimal fitness value in the previous repetition process, and updating the deployment of the blocks in the block chain storage system, the division of the RSU node clusters in the block chain storage system and the main RSU node in each node cluster according to the block deployment scheme with the optimal fitness value. According to the design, the threshold that the node participates in the block chain can be reduced, waste of storage resources is reduced, and balance is achieved between block storage and data access.

Description

Technical Field

[0001] The present invention relates to the field of blockchain data storage technology, and particularly 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. However, due to limited device computing and storage resources, the continuously expanding blockchain ledger cannot be fully stored on a single device. This problem is particularly prominent in the Internet of Vehicles. Due to the real-time nature and high mobility of the Internet of Vehicles, a large amount of data will be generated and exchanged, which poses higher requirements for the storage and processing capabilities of the blockchain. This usually requires the help of a central cloud. However, the data in the centralized server may be tampered with or deleted, thus lacking guaranteed traceability and accountability. In fact, the immutability, decentralization, and transparency of the blockchain itself make it more reliable, more economical, and more efficient than traditional database systems.

[0003] The integration of blockchain and the Internet of Vehicles can improve the advantages of the system, such as security, privacy, and trust. As a distributed database, blockchain technology has the characteristics of decentralization, immutability, and transparency. Compared with traditional distributed databases, blockchain can operate in an untrusted environment. Even in the presence of malicious nodes (such as Byzantine nodes), the security and reliability of the system can still be maintained. Therefore, how to solve the blockchain storage problem while fully leveraging these advantages and proposing a secure, traceable, and storage resource-saving solution is a key research topic. Summary of the Invention

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

[0005] To achieve the above object, the technical solution of the present invention is as follows:

[0006] In a first aspect, the present invention provides a blockchain storage joint optimization method for the Internet of Vehicles. The blockchain storage joint optimization method includes:

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

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

[0009] S2. Optimize the target cluster division plan to obtain an optimized cluster plan, and determine the primary RSU nodes in each node cluster of the optimized cluster plan;

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

[0011] 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;

[0012] S5. Repeat the above S1 to S4 until the repetition termination condition is reached, output the block deployment plan with the optimal fitness value in each repetition process, and update the deployment of blocks in the blockchain storage system, as well as the division of node clusters in the blockchain storage system and the primary RSU nodes in each node cluster according to the block deployment plan with the optimal fitness value.

[0013] The step S1 includes:

[0014] S101. Randomly generate multiple cluster plans based on the RSU nodes in the blockchain storage system. Among them, each cluster plan divides the RSU nodes in the blockchain storage system into n node clusters;

[0015] S102. Randomly select two from the multiple cluster plans as the target cluster plans. For each target cluster plan, select one from the n node clusters it contains, and exchange the two selected node clusters;

[0016] S103. Check for duplicate RSU nodes in the target cluster plan. For the duplicate RSU nodes in each target cluster plan, delete them in the remaining n - 1 node clusters except the selected node cluster;

[0017] S104. Supplement the RSU nodes in the blockchain storage system that are not included in the n node clusters of any target cluster plan to the clusters where the duplicate RSU nodes have been deleted.

[0018] The step S2 includes:

[0019] S201. Calculate the fitness values of the two target cluster plans;

[0020] S202. For each target cluster plan, randomly select two from its corresponding n node clusters as the target node clusters, randomly select one RSU node in each of the two target node clusters as the crossover nodes, exchange the positions of the two crossover nodes, update the target cluster plan and record the update times of the target cluster plan;

[0021] S203. Calculate the fitness values of the two updated target cluster solutions;

[0022] S204. Determine whether the number of updates of the target cluster solution reaches the upper limit of the first iteration number. If not, return to step S202; if so, select the target cluster solution corresponding to the optimal fitness value as the optimized cluster solution;

[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 from the five RSU nodes with the highest trust scores in each node cluster as the master node of the node cluster;

[0024] The th node in the blockchain storage system has its trust score

[0025] ;

[0026] ;

[0027] ;

[0028] ;

[0029] ;

[0030] In the formula, is the storage resource score of node ; is the remaining storage resource of node ; is the maximum storage capacity of node ; is the historical performance score of node ; is the performance score of node in the most recent historical period. A historical period refers to the time period from the start of an update of the RSU node cluster partition to before the next update of the RSU node cluster partition; is the highest performance score of node in all historical periods; is the computing resource score of node ; is the remaining computing resource of node ; is the maximum computing resource of the cluster; ., ., All are weight coefficients.

[0031] The step S3 includes:

[0032] S301. Calculate the block deployment plan within each cluster through a greedy strategy to obtain the first deployment plan;

[0033] S302. Based on the weights of each block, determine the active blocks that need redundant backup. Taking the active blocks that need redundant backup as objects, calculate the deployment plan for the backup of each active block based on the weights of each active block and the remaining storage resources of each cluster, and obtain the target block deployment plan.

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

[0035] ;

[0036] ;

[0037] ;

[0038] ;

[0039] ;

[0040] In the formula, is the weight of block For the th node ; represents the frequency of block being queried by node ; is the number of queries of block by node within a fixed time slot; is the total number of queries of all blocks by node within a fixed time slot; is the total number of blocks; is the mining time parameter of block ; is the current time, is the time when block is created; is an additional correction weight, and takes a value according to whether block contains a transaction directly related to node ; is the number of transactions related to node in block ; is the total number of transactions in the block ; is the weight of the corresponding block when the deployment of the block was last updated , is the weighting factor

[0041] The step S4 includes:

[0042] S401. Calculate the fitness value of the target block deployment plan through the fitness function

[0043] S402. Perform 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 returns to S402. If so, update the target block deployment plan according to the result of the mutation operation and record the update times of the target cluster plan

[0045] S404. Calculate the fitness value of the updated target block deployment plan through the fitness function

[0046] S405. Determine whether the update times of the target block deployment plan reach the upper limit of the second iteration times. 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 constraint conditions are:

[0050] ;

[0051] ;

[0052] ;

[0053] In the formula, the variable is an indicator function, indicating whether the th block is stored on the th node . If , it means that the th block is stored on the th node . If , it means that the th block Not stored in the th node ; is the size of the storage space required for the block; is the storage resource of the corresponding node; is the weight of the block; is the set of communication delays between the node and all other nodes; is the communication cost between the node and the node is the set of all node clusters in the cluster scheme, is the th node cluster in the cluster scheme; is the set of all blocks; is the total number of blocks; is the total number of nodes; is the storage resource of the nodes in the th cluster in the cluster scheme.

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

[0055] A cluster division module, configured to randomly divide the RSU nodes in the blockchain storage system into multiple node clusters to obtain a target cluster scheme;

[0056] A cluster optimization module, configured to optimize the target cluster division scheme to obtain an optimized cluster scheme, and determine the master nodes in each node cluster in the optimized cluster scheme;

[0057] A blockchain deployment module, configured to calculate a target block deployment scheme based on the optimized cluster scheme;

[0058] A deployment optimization module, configured to optimize the target block deployment scheme to obtain an optimized block deployment scheme, and obtain the fitness value of the optimized block deployment scheme;

[0059] A loop module, configured to repeatedly run the above cluster division module to the optimized deployment module until a repetition termination condition is reached, output the block deployment scheme with the optimal fitness value in each repeated process, and update the deployment of the blocks in the blockchain storage system, the division of the RSU node clusters in the blockchain storage system, and the master RSU nodes in each node cluster according to the block deployment scheme with the optimal fitness value.

[0060] In a third aspect, the present invention provides an electronic device, which 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 vehicle networking 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 in the above-mentioned blockchain storage joint optimization method for vehicle networking are implemented.

[0062] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0063] 1. In the blockchain storage joint optimization method for vehicle networking of the present invention, the RSU nodes are clustered, and the optimal cluster scheme is calculated by a genetic algorithm. Subsequently, based on the optimized target cluster scheme, the target block deployment scheme is calculated, and bit mutation operations are performed on the target block deployment scheme and iterated to obtain an optimized block deployment scheme. Then, the above operations are repeated until the number of repetitions reaches the preset upper limit, and an optimized cluster and block deployment scheme are obtained. The above process jointly optimizes the cluster division and block storage process, and uses the cluster to store blocks, enabling the node cluster division and block storage to achieve the best cooperation, optimizing the storage structure, reducing the storage requirements of each node, and maintaining the integrity and availability of data. Therefore, this design jointly optimizes the cluster division and block storage process, enables the cluster division and block storage to achieve the best cooperation, optimizes the storage structure, reduces the storage requirements of each node, and maintains the integrity and availability of data.

[0064] 2. In the blockchain storage joint optimization method for vehicle networking of the present invention, a large number of RSU nodes in the system are divided into multiple clusters, each cluster includes multiple RSU nodes within the target area, and each RSU node cluster is a peer in the blockchain network. Multiple peers jointly achieve blockchain storage consensus, effectively improving the deployment efficiency. Therefore, this design divides the node clusters, and each node cluster is a peer in the blockchain network, jointly achieving blockchain storage consensus and effectively improving the deployment efficiency.

[0065] 3. In the blockchain storage joint optimization method for the Internet of Vehicles of the present invention, during the process of block deployment, the block weight is calculated according to the query frequency and mining time to determine whether the block is active. Based on the activity level and weight of the block, as well as 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, in this design, by calculating the block weight and based on the activity level and weight of the block, as well as the storage resource requirements of the node cluster, the block is deployed to further optimize the storage structure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0067] Figure 2 FIG. is a schematic flowchart of a target cluster scheme generation method provided by an embodiment of the present invention.

[0068] Figure 3 FIG. is a schematic flowchart of an optimization method for a target cluster scheme provided by an embodiment of the present invention.

[0069] Figure 4 FIG. is a schematic flowchart of a method for calculating a target block deployment scheme provided by an embodiment of the present invention.

[0070] Figure 5 FIG. is a schematic flowchart of an optimization method for a target block deployment scheme provided by an embodiment of the present invention.

[0071] Figure 6 FIG. is a schematic 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 FIG. is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0073] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0074] The integration of blockchain and the Internet of Vehicles can improve the advantages of the system such as security, privacy, and trust. However, in related technologies, due to the limited computing and storage resources of devices, the continuously expanding blockchain ledger cannot be fully stored on a single device. At the same time, due to the real-time nature and high mobility of the Internet of Vehicles, a large amount of data will be generated and exchanged, which poses higher requirements for the storage and processing capabilities of the blockchain.

[0075] To solve the problem of insufficient storage capacity of the blockchain in the Internet of Vehicles existing in related technologies, the embodiments of the present invention provide a joint optimization method for blockchain storage for the Internet of Vehicles. This method jointly optimizes node cluster division and block deployment to ensure the efficiency of data access. Through this method, not only is the threshold for nodes to participate in the blockchain reduced, waste of storage resources is reduced, but also the access delay problem caused by collaborative storage is effectively solved, achieving a balance between block storage and data access.

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

[0077] In this embodiment, we divide roadside units (RSUs) into multiple node clusters. By grouping roadside units into node clusters, the nodes within the cluster collaborate to store the complete blockchain ledger to cope with the continuously expanding storage requirements in resource-constrained systems.

[0078] Blockchain is a distributed ledger technology that stores data blocks in a chain structure through cryptographic algorithms. It has characteristics such as decentralization, immutability, and transparency, and is very suitable for scenarios such as recording transactions and sharing data. The application of blockchain technology in the Internet of Vehicles has significant advantages, mainly reflected in enhancing data security, promoting efficient data sharing, improving transaction efficiency, and implementing decentralized identity authentication, etc., providing a solid technical support for the rapid development and intelligent application of the Internet of Vehicles.

[0079] In this embodiment, the blockchain storage system includes lightweight nodes and full nodes. Vehicles are used as lightweight nodes, and roadside units (RSUs) are used as full nodes to jointly construct the blockchain storage and consensus framework in the vehicle-to-everything (V2X) network. In the blockchain storage system, due to the strong dynamics and limited storage resources of vehicle nodes, they only store block headers and participate in data verification and query, without storing the entire blockchain or participating in complex consensus. As full nodes, RSU nodes are responsible for storing the blockchain ledger and participating in the consensus process. Specifically, multiple roadside units (RSUs) form a node cluster, and multiple RSU nodes in the node cluster cooperate to store the entire blockchain. Multiple RSU nodes in the same node cluster share different blocks to share the storage and computing pressure, so as to cope with the growth of blockchain data.

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

[0081] Storage table maintenance: The primary node is responsible for managing the block storage table within the cluster, recording information such as the storage location of blocks, redundancy backup schemes, and access frequencies. Since the primary node is dynamically elected, the management of the storage table must ensure that after the change of the primary node, it can seamlessly inherit and synchronize the previous storage table information, so as to ensure the access consistency of all nodes in the cluster to blocks. For this purpose, a redundancy backup and synchronization mechanism is adopted to ensure the reliability and stability of the storage table when the primary node is replaced;

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

[0083] Fault recovery: When a secondary node fails, the primary node can cooperate to store and recover the data lost by the secondary node to ensure that the system can quickly return to the normal state;

[0084] Node management and trustworthiness evaluation: The primary node can be responsible for managing the nodes within the cluster and serving as the node trustworthiness evaluation.

[0085] Specifically, once the primary node is determined, it enters the block generation and consensus stage. The specific process is as follows:

[0086] Block generation: The primary node generates new blocks according to the current blockchain state within the cluster and the data of the vehicle-to-everything (V2X) network.

[0087] Consensus Protocol: The PBFT (Practical Byzantine Fault Tolerance) or other consensus protocols adapted to the vehicle networking environment (such as Proof of Storage) are adopted, and the main node and the secondary nodes jointly verify the legality and integrity of the new block.

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

[0089] After consensus verification, the newly generated block is officially added to the overall ledger of the blockchain to form a record available throughout the network. At this time, the new block is synchronized by the nodes in each node cluster and broadcast to other clusters or external systems. Specifically, the main node propagates the new block to the nodes of other clusters through the peer-to-peer network to ensure the consistency of the blockchain across the network; all nodes update their blockchain data and store the block header of the new block.

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

[0091] In the distributed vehicle networking system, when the storage resource consumption of the cluster is close to the threshold, the system needs to automatically trigger the redeployment of the blockchain ledger to ensure data consistency and integrity.

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

[0093] Please refer to Figure 1 , Figure 1 is a schematic flowchart of a process for updating the division of the RSU node clusters in the blockchain storage system, the main RSU nodes in each node cluster, and the deployment of the blocks provided by the embodiment of the present invention. The method includes the steps in S1 to S5;

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

[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 collaboratively stores at least one screened complete blockchain copy.

[0096] The optimized clustering scheme can be continuously optimized and calculated according to the fitness function. Specifically, Figure 2 is a schematic flowchart of a method for generating a target cluster scheme provided by an embodiment of the present invention. As Figure 2 shown, randomly dividing the RSU nodes in the blockchain storage system into multiple node clusters to obtain a target cluster scheme includes the steps in S101 to S104:

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

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

[0099] S102. Randomly select two from the multiple cluster schemes as target cluster schemes. For each target cluster scheme, select one from the n node clusters it contains, and exchange the two selected node clusters, and update the content of the two target cluster schemes according to the exchange result.

[0100] Specifically, select two target cluster schemes, randomly select a node list from the n node lists corresponding to each of the target cluster schemes, and exchange the two selected node lists to obtain two updated target cluster schemes.

[0101] After exchanging the node lists in the two target clustering schemes, the target cluster scheme may have problems such as missing some RSU nodes and some RSU nodes being repeated. Therefore, it is necessary to correct the target cluster scheme after exchanging the node lists to avoid the above problems of node omission and repetition.

[0102] S103. Check the duplicate RSU nodes in the updated target cluster scheme. For the duplicate RSU nodes in each target cluster scheme, delete them in 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 scheme as the object, we delete them in the remaining n - 1 node clusters except the selected node cluster, and supplement the RSU nodes in the blockchain storage system that do not appear in the n-node clusters corresponding to the target cluster scheme in the subsequent steps.

[0104] S104. Supplement the RSU nodes in the blockchain storage system that are not included in the n-node clusters of any target cluster scheme into the clusters from which the duplicate nodes have been deleted, so that each of the n-node clusters of the target cluster scheme contains all the RSU nodes in the blockchain storage system, ensuring the integrity of the cluster scheme.

[0105] S2. Optimize the target cluster division scheme to obtain an optimized cluster scheme, and determine the primary RSU nodes in each node cluster of the optimized cluster scheme.

[0106] After generating the target cluster scheme, we need to continue to optimize it. Specifically, Figure 3 is a schematic flowchart of a method for optimizing the target cluster scheme provided by an embodiment of the present invention. As Figure 3 shown, optimizing the target cluster scheme to obtain an optimized cluster scheme, and determining the primary RSU nodes in each node cluster of the optimized cluster scheme includes the steps in S201 to S205:

[0107] S201. Calculate the fitness values of the two target cluster schemes.

[0108] In this embodiment, we calculate the fitness values of the target cluster schemes through a fitness function, and the fitness function is:

[0109] (1);

[0110] The constraint conditions are:

[0111] (2);

[0112] (3);

[0113] (4);

[0114] In the formula, the variable is an indicator function, indicating whether the th block is stored on the th node . If , it means that the th block Stored on the th node If , it means that the th block is not stored on the th node ; is the size of the storage space required for the block ; is the storage resource of the corresponding node; is the block weight; is the node and the set of communication delays with all other nodes; is the node and node communication cost between; is the set of all node clusters in the cluster scheme, is the th node cluster in the cluster scheme; is the set of all blocks; is the total number of blocks; is the total number of RSU nodes; is the storage resource of the RSU nodes in the th cluster in the cluster scheme; is the sum of the sizes of all blocks.

[0115] The above formula (1) is the optimization objective, that is, the lowest communication cost is the optimal objective; formula (2) limits the storage resources of RSU nodes, 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 that each block has at least one backup, which ensures the redundancy and reliability of the data and enables the system to maintain data integrity and availability in case of node failures; formula (4) limits the total resources of all RSU nodes in the cluster to ensure that each RSU node can cooperate to store the entire blockchain, which 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 through the fitness function includes: based on the target cluster solution, calculating the deployment solution of each block through a greedy strategy, and then calculating the fitness value of the target cluster solution according to the deployment solution of each block and the fitness function, and then judging the pros and cons of the cluster solution through 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 of the target cluster solutions, randomly select two from the corresponding n node clusters as target node clusters, randomly select one node in each of the two target node clusters as a cross node, exchange the positions of the two cross nodes, update the contents of the two target cluster solutions according to the exchange result, and record the number of updates of the target cluster solutions.

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

[0120] S204, determining whether the update times of the target clustering scheme reaches the preset upper limit of the first iteration times, if not, returning to step S202, if yes, selecting the target clustering scheme corresponding to the best 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] In the formula, is the storage resource score of node ; is the remaining storage resource of node ; is the maximum storage capacity of node ; is the historical performance score of node ; is the performance score of node in the most recent historical period. A historical period refers to the time period experienced from the start of an update of the RSU node cluster partition to before the next update of the RSU node cluster partition; is the highest performance score of node in all historical periods; is the computing resource score of node ; is the remaining computing resource of node ; is the maximum computing resource of the cluster; , , are all weight coefficients.

[0129] After the iteration is completed, the master node of the current consensus round is elected according to the node trust degree within the cluster based on the storage resource score, the node historical performance (whether it is selected as the master node), and the computing resource score, so as to ensure the efficient verification and storage of data. Among them, the storage resource score is used to evaluate the storage capacity of the node; the computing resource score can be obtained by calculating the ratio of the remaining computing power of the node to the maximum computing power of the nodes in the cluster, and the computing resource score is used to evaluate the computing ability of the node; the performance score of the RSU node in any historical period is obtained according to whether the node is the master node in that period. Therefore, the historical performance score of each RSU node is related to whether the node has ever been selected as the master node. According to the historical performance of the node, that is, whether each RSU node has ever been selected as the master node, and the number of times each RSU node has been selected as the master node in each historical period, we standardize the historical performance score to a value within the range of [0,1]. Therefore, if an RSU node has ever been the master node, the historical performance score of this node is relatively higher.

[0130] Inside each cluster, a state machine-based Practical Byzantine Fault Tolerance (PBFT) consensus mechanism is adopted. Through message passing and voting protocols among nodes, the consistency and reliability of data within the cluster are ensured. The primary node in each cluster is responsible for generating blocks, and verifies the legality and integrity of block contents through the consensus protocol. Finally, the generated blocks are merged into the global blockchain to ensure the consistency of the global ledger and the security of decentralization. On this basis, the primary nodes can back up the new blocks generated by other clusters' primary nodes in a peer-to-peer manner.

[0131] Since some nodes may be more likely to be elected as primary nodes in subsequent rounds due to their history, to avoid the phenomenon of "the rich getting richer", randomness is introduced into the election process of the leader node. Specifically, when electing, a node is randomly selected from the top five nodes in terms of scores as the primary node for the current round. This strategy plays an important role in balancing the resource advantages of nodes and the fairness of elections, preventing a node from continuously dominating the election of the leader node due to its historical performance or resource advantages, thereby enhancing the fairness and robustness of the system.

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

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

[0134] Since the size of a block is related to the number of transactions specifically stored, the block size is not fixed. Each cycle, the blockchain packs the transactions within this cycle into new blocks and adds them to the blockchain. As the number of blocks in the blockchain system increases, the blockchain ledger grows rapidly, and it is difficult for a single node to store all the blocks since the genesis block.

[0135] Therefore, we adopt a node cluster mode to collaboratively store the entire blockchain ledger. A node cluster (node cluster) is composed of no less than 3 RSU nodes within the same geographical location range. For each node in the cluster within a fixed time window, accessing different blocks will generate the access frequency of the node to the blocks. At the same time, combined with the generation time of the blocks, we can define the weight of the blocks to evaluate the necessity of block storage. We deploy according to the alignment of the weights of the blocks. Specifically, Figure 4 is a schematic flowchart of a process for calculating the target block deployment plan provided by an embodiment of the present invention. As Figure 4 shown, based on the optimized cluster scheme, calculating the target block deployment plan includes the steps in S301 to S302:

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

[0137] Specifically, based on the clustering scheme with the optimal fitness value, calculating the first deployment plan for each block through a greedy strategy includes:

[0138] For each cluster, determine the available storage resources of each RSU node within it. Following the rules of the greedy strategy, allocate RSU nodes to each block one by one until all blocks are allocated, obtaining the first deployment plan, which specifies the specific nodes on which each block should be deployed and the clusters they belong to. The greedy strategy means preferentially allocating blocks to the nodes with the richest storage resources.

[0139] S302. Based on the weights of each block, determine the active blocks that need redundant backup. Taking the active blocks that need redundant backup as the objects, according to the weights of each active block and the remaining storage resources of each cluster, calculate the deployment plan for the backups of each active block on the basis of the first deployment plan. Combine the first deployment plan and the deployment plan for the backups of each active block to obtain the target block deployment plan. Calculating the deployment plan for the backups of each active block includes, in accordance with the weights of each active block, sequentially allocating their backups to the nodes with the most remaining storage resources.

[0140] After obtaining the target block deployment plan, it is necessary to ensure that this deployment plan meets the constraint conditions. We calculate whether the target block deployment plan satisfies the constraint conditions. If not, it is necessary to adjust the storage status and storage location of the blocks in the adjustment plan until the target block deployment plan meets the constraint conditions.

[0141] In this embodiment, in the block deployment plan, we record the blocks allocated on each RSU node through a storage table matrix.

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

[0143] ;

[0144] ;

[0145] ;

[0146] ;

[0147] ;

[0148] In the formula, is the th block in the blockchain For the th node weight; represents the block The frequency queried by the node ; For the number of times a node queries a block in a fixed time slot; ; For the total number of queries of all blocks by a node in a fixed time slot; Is the total number of blocks; Is the mining time parameter of the block , Is the current time, Is the time when the block is created; Is the additional correction weight, which is valued according to whether the block contains transactions directly related to the node ; Is the number of transactions related to the node in the block ; Is the total number of transactions in the block ; Is the weight of the corresponding block when the last update of the block deployment was made ; , Are weighting coefficients.

[0149] Adding correction coefficients can improve the flexibility and accuracy of weight calculation, enabling it to better reflect the correlation between blocks and nodes. Compared with the evaluation method that simply relies on access frequency or time decay parameters, the introduction of correction coefficients can significantly improve the discrimination of block importance evaluation, enabling the system to give higher priority to backing up and allocating active blocks containing key transactions, improving the timeliness and effectiveness of data storage in the vehicle network, and thus better supporting the dynamic interaction of vehicles and the demand for efficient data transmission.

[0150] In this embodiment, we define the query frequency of a block as the ratio of the number of times an RSU node queries the block in a consensus period to the sum of the number of times it queries all other blocks. The higher the query frequency of a block, the higher the weight corresponding to that block. Generally speaking, the query frequency of new blocks is higher than that of old blocks. Therefore, we consider the impact of mining time on the block weight and assign higher weights to the most recently mined blocks. According to the above weight calculation formula, the higher the query frequency and the larger the value of the parameter, the more active the block.

[0151] Through the above calculations, we can obtain the weights of each block for each node. Since the weights can effectively reflect the activity level of the corresponding blocks, we calculate the weights of each block in the blockchain and, according to the high and low of the weights and the remaining storage resources of each RSU node in the node cluster, determine whether each block needs redundant backup and the deployment locations of each backup block in the order from high to low of the corresponding weights.

[0152] Calculate the weight of a block based on the query frequency of a certain block by different nodes in the node cluster within a fixed time window, the block generation time, and the relationship between the transactions in the block and the nodes. After obtaining the preliminary deployment plan of the entire blockchain ledger, consider redeploying the blocks with higher weights to the 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 is a schematic flowchart of a process for optimizing the target block deployment plan provided by an embodiment of the present invention. As Figure 5 shown, optimizing the target block deployment plan to obtain an optimized block deployment plan and calculating the fitness value of the optimized block deployment plan according to the fitness function includes the steps in S401 to S405:

[0154] S401. Calculate the fitness value of the target block deployment plan through the fitness function.

[0155] S402. Perform 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 record the blocks allocated to each RSU node through the storage table matrix, we can modify the variables on the storage table matrix to implement the mutation operation on the target block deployment plan.

[0157] Specifically, after performing the mutation operation on the target block deployment plan, determine 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, this mutation operation fails and returns to S402. If it meets the conditions, update the target block deployment plan according to the result of the mutation operation and record the update times of the target cluster plan;

[0159] S404. Calculate the fitness value of the updated target block deployment plan through the fitness function;

[0160] S405. Determine whether the number of updates to the target block deployment plan reaches the upper limit of the second iteration. If not, return to step S402. If so, select the target block deployment plan corresponding to the optimal fitness value obtained in previous calculations as the optimized block deployment plan.

[0161] S5. Repeat the above S1 to S4 until the repetition termination condition is reached. Output the block deployment plan with the optimal fitness value in previous repetitions, as well as the corresponding optimized cluster plan and the master nodes 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 optimal fitness value, and update the division of node clusters and the master RSU nodes in each node cluster in the blockchain storage system according to the corresponding optimized cluster plan and the master nodes of each cluster.

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

[0163] In summary, the embodiments of the present invention provide a method for jointly optimizing blockchain storage for the Internet of Vehicles. This method jointly optimizes node cluster division and block deployment. Through this method, not only the threshold for nodes to participate in the blockchain is reduced, waste of storage resources is reduced, but also the access delay problem caused by collaborative storage is effectively solved, achieving a balance between block storage and data access. We use the method for jointly optimizing blockchain storage for simulation experiments. Under the condition of generating almost the same network background as the existing commonly used solutions, the block access cost of this method is much lower than that of other methods. We also compare the cluster division schemes with different numbers of nodes and different numbers of blocks. The results show that this scheme can maintain stable advantages in different environmental states.

[0164] According to the method described in the above embodiments, this embodiment will be further described from the perspective of a system for jointly optimizing blockchain storage for the Internet of Vehicles. The system for jointly optimizing blockchain storage for the Internet of Vehicles can be specifically implemented as an independent entity, or can be integrated in an electronic device, such as a terminal. The terminal can include a mobile phone, a tablet computer, etc.

[0165] Please refer to Figure 6 , Figure 6 which is a schematic structural diagram of a system for jointly optimizing blockchain storage for the Internet of Vehicles provided by the embodiments of the present invention. As Figure 6 shown, the system for jointly optimizing blockchain storage for the Internet of Vehicles provided by the embodiments of the present invention includes:

[0166] The cluster division module is used to randomly divide the RSU nodes in the blockchain storage system into multiple node clusters to obtain a target cluster scheme, and the cluster division module is used to execute the steps in S1;

[0167] The cluster optimization module is used to optimize the target cluster division scheme to obtain an optimized cluster scheme and determine the master nodes in each node cluster of 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 a target block deployment scheme based on the optimized cluster scheme, and the blockchain deployment module is used to execute the steps in S3;

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

[0170] The loop module is used to repeatedly run the above-mentioned cluster division module to the optimized deployment module until the repeated termination condition is reached, output the block deployment scheme with the optimal fitness value in each repeated process, update the deployment of the blocks in the blockchain storage system, as well as the division of the node clusters in the blockchain storage system and the master RSU nodes in each node cluster. The loop module is used to execute the steps in S5.

[0171] In addition, please refer to Figure 7 , Figure 7 which is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. As Figure 6 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 vehicle networking are implemented.

[0172] Those of ordinary skill in the art can understand that all or part of the steps in the above-mentioned various methods can be completed by instructions or by controlling relevant hardware through instructions. The instructions can be stored in a computer-readable storage medium and loaded and executed by a processor. For this reason, an embodiment of the present invention provides a storage medium in which multiple instructions are stored, and when the instructions are executed by a processor, the steps in the above-mentioned blockchain storage joint optimization method for vehicle networking are implemented.

[0173] Generally speaking, the computer instructions for implementing the method of the present invention can be carried by any combination of one or more computer-readable storage media. A non-transitory computer-readable storage medium can include any computer-readable medium except for the signal propagating temporarily itself.

[0174] A computer-readable storage medium may be, for example, but not limited to, a system, apparatus, or device of electricity, magnetism, optics, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of the computer-readable storage medium include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with a system, apparatus, or device instructed to execute.

[0175] Computer program code for performing the operations of the present invention may be written using one or more programming languages or combinations thereof. These programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the C language or similar programming languages. In particular, the Python language suitable for neural network computing and platform frameworks based on TensorFlow, PyTorch, etc. can be used. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as an independent 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 may be connected to the user's computer through various types of network connections, including a local area network (LAN) or a wide area network (WAN), or through an Internet service provider for an Internet connection.

[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. Those of ordinary skill in the art may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. A blockchain storage joint optimization method for the Internet of Vehicles, characterized in that the blockchain storage joint optimization method includes: when the proportion of the consumed storage resources of any RSU node cluster in the blockchain storage system exceeds a preset threshold, the following steps are executed to update the deployment of the blocks: S1. Randomly divide the RSU nodes in the blockchain storage system into multiple node clusters to obtain a target cluster scheme; S2. Optimize the target cluster division scheme to obtain an optimized cluster scheme, and determine the primary RSU nodes in each node cluster of the optimized cluster scheme; S3. Calculate the target block deployment scheme based on the optimized cluster scheme; S4. Optimize the target block deployment scheme to obtain an optimized block deployment scheme, and obtain the fitness value of the optimized block deployment scheme; S5. Repeat the above S1 to S4 until the repetition termination condition is reached, output the block deployment scheme with the optimal fitness value in each repetition process, and update the deployment of the blocks in the blockchain storage system, the division of the RSU node clusters in the blockchain storage system, and the primary RSU nodes in each node cluster according to the block deployment scheme with the optimal fitness value.

2. The blockchain storage joint optimization method for the Internet of Vehicles according to claim 1, characterized in that: the step S1 includes: S101. Based on the RSU nodes in the blockchain storage system, randomly generate multiple cluster schemes, where each cluster scheme divides the RSU nodes in the blockchain storage system into n node clusters; S102. Randomly select two from the multiple cluster schemes as the target cluster schemes. For each target cluster scheme, select one from the n node clusters it contains, and exchange the two selected node clusters; S103. Check the duplicate RSU nodes in the target cluster scheme. For the duplicate RSU nodes in each target cluster scheme, delete them in the remaining n - 1 node clusters except the selected node cluster; S104. Supplement the RSU nodes in the blockchain storage system that are not included in the n node clusters of any target cluster scheme to the clusters where the duplicate RSU nodes have been deleted.

3. The blockchain storage joint optimization method for the Internet of Vehicles according to claim 2, characterized in that: the step S2 includes: S201. Calculate the fitness values of the two target cluster schemes; S202. For each target cluster scheme, randomly select two from its corresponding n node clusters as the target node clusters, randomly select one RSU node in each of the two target node clusters as the crossover node, exchange the positions of the two crossover nodes, update the target cluster scheme and record the update times of the target cluster scheme; S203. Calculate the fitness values of the two updated target cluster schemes; S204. Determine whether the update times of the target cluster scheme reach the upper limit of the first iteration times. If not, return to step S202. If so, select the target cluster scheme corresponding to the optimal fitness value as the optimized cluster scheme; S205. In the n-node clusters corresponding to the optimized cluster scheme, calculate the trust scores of all RSU nodes in each node cluster, and randomly select one from the five RSU nodes with the highest trust scores in each node cluster as the master node of the node cluster; The th node in the blockchain storage system has a trust score calculated according to the following formula: ； ； ； ； ； Wherein, is the storage resource score of node ; is the remaining storage resource of node ; is the maximum storage capacity of node ; is the historical performance score of node ; is the performance score of node in the most recent historical period. A said historical period refers to the time period experienced from the start of an update of the RSU node cluster partition to before the next update of the RSU node cluster partition; is the highest performance score of node in all historical periods; is the computing resource score of node ; is the remaining computing resource of node ; is the maximum computing resource of the cluster; , , are all weight coefficients.

4. A blockchain storage joint optimization method for vehicle-to-everything network according to claim 3, characterized in that: The step S3 includes: S301. Calculate the block deployment scheme within each cluster through a greedy strategy to obtain the first deployment scheme; S302. Based on the weights of each block, determine the active blocks that need redundant backup. Taking the active blocks that need redundant backup as the objects, calculate the deployment scheme of the backup of each active block based on the weights of each active block and the remaining storage resources of each cluster, and obtain the target block deployment scheme on the basis of the first deployment scheme.

5. A blockchain storage joint optimization method for vehicle-to-everything network according to claim 4, characterized in that: In the step S302, the weight of the block is calculated according to the following formula: ； ； ； ； ； Wherein, is the block For the th node weight; Indicates that the block is queried by the node frequency; is the number of times the node queries the block in a fixed time slot; is the total number of queries of the node to all blocks in a fixed time slot; is the total number of blocks; is the mining time parameter of the block ; is the current time, is the time when the block is created; is an additional correction weight, According to whether the block contains transactions directly related to the node to take values; is the number of transactions related to the node in the block ; is the total number of transactions in the block ; is the weight of the corresponding block when the last deployment of the block is updated; , are weighting coefficients.

6. A blockchain storage joint optimization method for vehicle-to-everything network according to claim 1, characterized in that: The step S4 includes: S401. Calculate the fitness value of the target block deployment scheme through a fitness function; S402. Perform a random mutation operation on the target block deployment scheme; S403. Determine whether the target block deployment scheme after the mutation operation meets the constraint conditions. If not, this mutation operation fails and returns to S402. If it meets the conditions, update the target block deployment scheme according to the result of the mutation operation and record the update times of the target cluster scheme; S404. Calculate the fitness value of the updated target block deployment scheme through a fitness function; S405. Determine whether the update times of the target block deployment scheme reach the upper limit of the second iteration times. If not, return to step S402. If so, select the target block deployment scheme corresponding to the optimal fitness value as the optimized block deployment scheme.

7. A blockchain storage joint optimization method for vehicle-to-everything network according to claim 6, characterized in that: The fitness function is: ； The constraint conditions are: ； ； ； In the formula, the variable is an indicator function indicating whether the th block is stored on the th node . If , it means that the th block is stored on the th node . If , it means that the th block is not stored on the th node ; is the size of the storage space required by block ; is the storage resource of the corresponding node; is the weight of block ; is the set of communication delays between node and all other nodes; is the communication cost between node and node ; is the set of all node clusters in the cluster scheme, is the th node cluster in the cluster scheme; is the set of all blocks; is the total number of blocks; is the total number of nodes; is the storage resource of the nodes in the th cluster in the cluster scheme; is the sum of the sizes of all blocks.

8. A blockchain storage joint optimization system for vehicle-to-everything network, comprising: A cluster division module for randomly dividing the RSU nodes in the blockchain storage system into multiple node clusters to obtain a target cluster scheme; A cluster optimization module for optimizing the target cluster division scheme to obtain an optimized cluster scheme and determining the master nodes in each node cluster of the optimized cluster scheme; A blockchain deployment module for calculating a target block deployment scheme based on the optimized cluster scheme; A deployment optimization module for optimizing the target block deployment scheme to obtain an optimized block deployment scheme and obtaining the fitness value of the optimized block deployment scheme; A loop module, which is used to repeatedly run the above-mentioned cluster partitioning module to the optimization deployment module until a repeated termination condition is reached, output the block deployment plan with the optimal fitness value in each repeated process, and update the deployment of blocks in the blockchain storage system, the partitioning 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 optimal fitness value.

9. 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. When the processor executes the computer program, the steps in the method according to any one of claims 1 to 7 are implemented.

10. 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 7 are implemented.

Images