A blockchain-based secure data sharing method for internet of vehicles

Abstract

The application relates to a blockchain-based vehicle networking security data sharing method and belongs to the technical field of mobile communication. First, a cloud-edge-end three-layer network model of a vehicle networking scene is established. Then, a double-layer blockchain architecture is proposed to enable a data sharing process, and a sharing strategy and an asynchronous partition sharing method are further proposed. The scheme can realize safe and efficient asynchronous model sharing in the vehicle networking scene while protecting the data privacy of user vehicles. The scheme maximizes sharing efficiency in the vehicle moving scene, efficiently utilizes edge network and user data resources, and breaks the bottleneck of artificial intelligence application in the vehicle networking scene.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of mobile communication, and relates to a blockchain-based vehicle networking security data sharing method. BACKGROUND

[0002] Machine learning tasks for vehicle networking intelligent applications usually rely on valuable data of a large number of vehicles. With the explosive growth of data, data sharing has become an important technical means to improve vehicle driving safety and travel efficiency. Vehicles can share basic safety signaling and massive application data to provide richer intelligent services for vehicles. Data sharing technology enables vehicles to break through the information island barrier, and a large amount of data can be comprehensively analyzed and processed, greatly improving the quality of vehicle intelligent services.

[0003] However, data sharing technology still faces user privacy problems, and the security problems caused by data sharing are becoming more and more serious. Federated learning (FL) is a new form of distributed learning, and is a main method for solving data privacy problems in data sharing. It allows vehicles to train locally using private data and upload model parameters to a central server for aggregation. Federated learning converts data sharing between vehicles into model sharing, that is, sharing of data-oriented applications, so that vehicles only need to share models rather than data itself to ensure their own data privacy and security. Due to the distributed and structural characteristics of the data sharing architecture based on federated learning, it can be well integrated with blockchain technology to provide tamper resistance and traceability, etc. to resist security threats and malicious attacks such as interruption, availability attacks, single point of failure and poisoning attacks, etc. suffered by FL models.

[0004] At present, there are still many problems in the application of data sharing based on blockchain and federated learning in vehicle networking: 1) In large-scale vehicle networking applications, the limitation of blockchain throughput seriously affects the efficiency of data sharing; 2) Traditional federated learning is still based on a cloud computing architecture, which will cause unacceptable transmission and response delays due to the long-distance transmission of a large amount of model data to the cloud; 3) The transmission performance of vehicles is often unstable due to their mobility, and the traditional synchronous learning method will cause frequent failures of model aggregation, resulting in a slow model training process; 4) Due to the unpredictable mobility and resource requirements of vehicles, the network topology is time-varying, which will generate the need for vehicle cross-zone data migration; 5) Malicious user vehicles can tamper with data or models to affect vehicle judgment, and thus cause serious traffic accidents. SUMMARY

[0005] In view of this, the purpose of the present application is to provide a blockchain-based vehicle networking security data sharing method for solving the problem of large-scale safe and efficient data sharing in vehicle networking scenarios. User vehicles can collect road data information in real time through vehicle-mounted sensors, and share learning models through the architecture for vehicle networking intelligent services such as autonomous driving, etc.

[0006] To achieve the above purpose, the present application provides the following technical solutions:

[0007] A blockchain-based vehicle networking security data sharing method, the method comprising the following steps:

[0008] S1: The cloud initiates a data sharing task to the edge network, and uploads an initial model to each partitioned blockchain network;

[0009] S2: The data sharing vehicle initiates a data sharing request to obtain the current model and the optimal sharing strategy;

[0010] S3: The data sharing vehicle obtains the model from the RSU or BS, verifies and aggregates the selected model as a to-be-trained model;

[0011] S4: The data sharing vehicle trains the model obtained in S3 using a local data set to obtain an updated global model;

[0012] S5: The data sharing vehicle uploads the global model in S4 to the blockchain network through the RSU or BS;

[0013] S6: All data sharing vehicles repeat steps S2-S5 until the partitioned models converge.

[0014] Optionally, in S1, the data sharing network includes a cloud layer, an edge layer and a terminal layer; the cloud layer provides AI solutions for the network and coordinates various data sharing tasks; the edge layer is composed of edge computing nodes such as roadside units and base stations, and provides communication, calculation and storage resources for user layer vehicles; the terminal layer is composed of intelligent vehicles participating in data sharing;

[0015] The edge layer is divided into multiple partitions, each of which is composed of one BS and multiple RSUs, each of which cooperates and processes data sharing tasks in parallel and independently maintains a blockchain to enable data sharing process, and data sharing is in the form of federated learning to ensure the data privacy of vehicle users; a DAG+PBFT double-layer blockchain architecture is adopted in the edge layer to realize safe and efficient asynchronous federated learning, edge trusted verification and data migration in the Internet of Vehicles; wherein the lower layer is composed of a partitioned blockchain based on an improved DAG consensus to realize asynchronous data sharing, responsible for transaction verification and edge model aggregation process within the partition, and the DAG chain is maintained by the BS and multiple RSUs of the partition; the upper layer is composed of a main blockchain based on a PBFT consensus, responsible for recording and verifying global cross-zone data migration, and the PBFT chain is maintained by all BSs of the partitions; the RSUs and BSs within a partition are connected through a wireless network to form an edge computing network of a partition; the BSs of the partitions are connected through a wireless network to form the entire edge layer; the data sharing vehicles of the terminal layer are connected with the BSs and RSUs through a wireless connection to share model data; the data sharing tasks are divided into intra-partition sharing and cross-zone sharing, and the BSs are responsible for the cross-zone sharing tasks of the vehicles, and the RSUs are responsible for the intra-partition sharing tasks of the vehicles; the entire data sharing process is recorded in the blockchain.

[0016] Optionally, in S2, the optimal sharing strategy is:

[0017] The data sharing vehicle first initiates a sharing request, which is intra-partition sharing or cross-zone sharing, if it is an intra-partition request, the vehicle sends the request to the RSU of the zone; if it is a cross-zone request, the vehicle sends the request to the BSs of the zone and the target partition; all requests at the current time are collected and sent to the BS or cloud to calculate the optimal sharing strategy; the time span from the initiation of the sharing task request by the vehicle to the successful confirmation of the task in the blockchain is defined as the time delay of a sharing task; the optimal data sharing strategy is the precision selection, matching and communication resource allocation strategy that minimizes the average total time delay of all tasks, as shown in the following formula:

[0018]

[0019] wherein T v represents the time delay of the sharing task of the vehicle v, which is composed of three parts: 1) vehicle local training time delay, related to precision selection; 2) communication time delay of sharing model upload, related to time-varying channel conditions caused by vehicle movement; 3) blockchain chaining and confirmation time delay, related to DAG and PBFT time delay; the time delay of the sharing task of the vehicle v is as follows:

[0020]

[0021] wherein and respectively represent the local training, model uploading and blockchain on-chain confirmation delay of the task; the data sharing vehicle will obtain the optimal sharing strategy from the RSU or BS, and obtain the current Tips, and then perform local training and subsequent sharing according to the obtained sharing strategy; for intra-partition sharing, after the vehicle performs local training, the vehicle uploads the model to the RSU in the current partition according to the sharing strategy, and then adds the model to the DAG in the current partition for verification; for cross-partition sharing, after the vehicle performs local training, the vehicle needs to upload the model to the RSU in the current partition and the RSU in the target partition, and then adds the model to the two corresponding DAGs for verification, and then packs all the transactions involved in the cross-partition transaction and uploads the transactions to the upper PBFT chain to record and verify the cross-partition transaction globally; finally, the vehicle receives the sharing success information, and the current round of sharing ends.

[0022] Optionally, the intra-partition sharing is:

[0023] A Tangle network based on DAG is used in each partition to realize asynchronous data sharing; each transaction in the DAG contains a model shared by a vehicle, and the model is obtained by local training and updating of the aggregated model in all transactions pointed to by the transaction; that is, each transaction will point to some Tips when it is added to the DAG network, and then verify and aggregate the models to perform local training; the transaction will become a Tip after being connected to the DAG network;

[0024] For intra-partition data sharing, the vehicle obtains the Tips in the current DAG from the RSUs in the current partition, and randomly selects 2 Tips according to the precision weight; then the validity of the 2 Tips is verified, and the models in the 2 Tips are extracted and aggregated as a model to be trained;

[0025]

[0026] wherein C1 and C2 are weight factors representing the importance of the two models from the Tips; according to the obtained optimal sharing strategy, the local data set is used for training, such as performing a gradient descent:

[0027]

[0028] wherein a is a learning rate, F v (v, ω) is a loss function on the data set of the vehicle v; then the updated model and the selected Tips are packed into a transaction; finally, the transaction is connected to the corresponding RSU according to the obtained optimal sharing strategy; the RSU packs the transaction, adds transaction header information, and then broadcasts to the edge network to be chained to the DAG in the current partition for verification by other transactions;

[0029] As new transactions are continuously added to the DAG chain, the DAG chain grows, and the Tips are gradually verified to become trusted transactions, and the newly added transactions are supplemented as Tips waiting for the connection of subsequent new transactions; the model accuracy in the Tips in the DAG chain gradually increases to convergence.

[0030] Optionally, the cross-zone sharing is:

[0031] The vehicle will obtain Tips from two DAGs in the local BS and the target BS, respectively, and then randomly select one Tip from each according to the accuracy weight, extract the model after verifying the validity, and train the model according to the obtained optimal sharing strategy using the local data set, and then pack the updated model and the selected Tips into a transaction; the vehicle uploads the transaction to the DAG network of the local zone and the target zone through the local BS and the target BS, respectively, and then packs the related transactions into a block and adds it to the upper PBFT main chain through PBFT consensus; the PBFT main chain records the whole process of cross-zone sharing, which is used to record and verify the cross-zone transactions in the DAG globally;

[0032] The cross-zone transaction is first recorded in the DAG chain, and the verifier obtains the block containing the cross-zone transaction from the BS and verifies its validity; then, the verifier observes whether the cross-zone transaction and the two transactions connected thereto recorded in the DAG and the cross-zone target DAG are consistent with those recorded in the block, and if so, the cross-zone transaction is admitted to be valid.

[0033] Optionally, the vehicle network security data sharing method comprises the following specific steps:

[0034] S401: system initialization;

[0035] S402: the cloud publishes a data sharing task and an initial model to an edge network;

[0036] S403: generating a task publishing request list;

[0037] S404: the BS receives the request;

[0038] S405: verifying the identity information and request content of the vehicle, if passed, then proceed to the next step, if it is a task publishing request, then execute S406; if it is a task termination request, then execute S409; if it is a cross-zone sharing request, then execute S412; otherwise, repeat step S404;

[0039] S406-S408: the BS receives the task publishing request, generates a DAG chain for the task in each zone and adds a genesis block, and broadcasts the information to the edge network, and then returns to execute step S404;

[0040] S409-S411: The BS receives the task termination request, terminates the shared task, broadcasts information to the edge network, and then returns to step S404;

[0041] S412: The BS receives the cross-region sharing request. If it is a model acquisition request, step S413 is performed. If it is a model upload request, step S422 is performed.

[0042] S413-S415: The BS receives the cross-region shared model acquisition request, sends all cross-region sharing request information to the cloud to obtain the optimal sharing strategy.

[0043] S416: The cloud collects cross-region request information.

[0044] S417: The cloud obtains the optimal sharing strategy by minimizing the long-term average delay of all tasks, including network resource allocation, vehicle and BS or RSU matching, and vehicle local training accuracy.

[0045] S418: The optimal sharing strategy table corresponding to the task is generated and returned to the BS.

[0046] S419-S421: The BS obtains the optimal sharing strategy, then sends the Tips of the local area and the Tips of the target partition of the cross-region and their corresponding sharing strategies to the corresponding vehicles, and finally returns to step S404.

[0047] S422-S428: The BS receives the cross-region shared model upload request, respectively packages and chains the transaction to the local DAG and the DAG of the target partition of the cross-region, then packages the cross-region transaction and all Tips connected to it into a block, and chains it to the upper PBFT chain between BSs through PBFT consensus, and finally returns the success information to the vehicle.

[0048] S429: The RSU receives the request.

[0049] S430: Verify the identity information and request content of the requesting vehicle. If it passes, proceed to the next step, otherwise repeat step S429.

[0050] S431: The RSU receives the intra-partition sharing request. If it is a model acquisition request, step S432 is performed. If it is a model upload request, step S441 is performed.

[0051] S432-S434: The RSU receives the intra-partition shared model acquisition request, sends all intra-partition sharing request information to the local BS to obtain the optimal sharing strategy.

[0052] S435: The BS collects intra-partition request information.

[0053] S436: The BS obtains the optimal sharing strategy by minimizing the long-term average latency of all tasks, including the allocation of network resources, the matching of vehicles and BSs or RSUs, and the accuracy of vehicle local training;

[0054] S437: The optimal sharing strategy table corresponding to the task is generated, and then returned to the RSU;

[0055] S438-S440: The RSU obtains the optimal sharing strategy, then sends the Tips in the area and their corresponding sharing strategies to the corresponding vehicles, and finally returns to step S429 for execution;

[0056] S441-S444: The RSU receives the model upload request for sharing within the partition, packages the transaction and uploads it to the area DAG, and finally returns the success information to the vehicle;

[0057] S445-S447: The data sharing vehicle initiates a sharing request, which can be either intra-partition sharing or cross-partition sharing;

[0058] S448: Generate a model acquisition request list. If it is intra-partition sharing, send it to the RSU in the area for execution of S429. If it is cross-partition sharing, send it to the BSs in the area and the target area for execution of S404;

[0059] S449: Wait for the information returned by the edge network;

[0060] S450-S452: Extract the model information in the obtained Tips. If it is intra-partition sharing, randomly select 2 Tips in the area according to the accuracy weight to verify their effectiveness and aggregate the model. If it is cross-partition sharing, randomly select 1 Tip from the Tips in the area and the target partition according to the accuracy weight to verify its effectiveness and aggregate the model;

[0061] S453: Train the aggregated model according to the obtained optimal sharing strategy;

[0062] S454-S457: Package the updated model and the hash information of the selected Tips into a transaction. If it is intra-partition sharing, upload the model to the corresponding RSU according to the optimal strategy and execute S429. If it is cross-partition sharing, upload the model to the BSs in the area and the target partition according to the optimal strategy and execute S404;

[0063] S458: Receive the return information and start the next round of sharing, and return to S225 for execution;

[0064] S459: The cloud obtains the current model training situation from the edge network;

[0065] S460: Analyze the performance of the current model;

[0066] S461: when it considers that the model reaches the expectation or has converged, sends task termination information to each partitioned RSU and BS, the data sharing task ends, otherwise returns to execute S459;

[0067] S462: sends the task termination information to the BS;

[0068] S463: generates a task termination request list and sends it to the BS;

[0069] S464: the running ends.

[0070] The beneficial effects of the present application are that the network architecture of the present application is composed of a cloud-edge-end three-layer network, and the edge layer adopts a double-layer blockchain architecture to empower the data sharing process, which well solves the large-scale data sharing problem in the vehicle networking scene, realizes the safe and efficient asynchronous model sharing, and protects the data privacy of the user vehicle. The scheme maximizes the sharing efficiency in the vehicle moving scene, efficiently utilizes the edge network and user data resources, and breaks the bottleneck of artificial intelligence application in the vehicle networking scene.

[0071] Other advantages, objects, and features of the present application will be in part apparent and in part pointed out hereinafter in the specification, and will be observed in the practice of the application. The objects and other advantages of the present application can be realized and attained by the below description. BRIEF DESCRIPTION OF DRAWINGS

[0072] In order to make the purpose, technical scheme and advantages of the present application clearer, the preferred detailed description of the present application will be combined with the drawings as follows, wherein:

[0073] Figure 1 It is a cloud-edge-end partitioned data sharing model diagram based on double-layer blockchain;

[0074] Figure 2 It is a vehicle optimal sharing strategy flowchart;

[0075] Figure 3 It is an asynchronous data sharing flowchart based on double-layer blockchain;

[0076] Figure 4 It is a partitioned safe and efficient data sharing scheme execution flowchart based on blockchain in vehicle networking. DETAILED DESCRIPTION

[0077] The present application is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which: BRIEF DESCRIPTION OF THE DRAWINGS

[0078] Wherein, the drawings are only used for example description, the representation is only schematic diagram, not real object drawing, cannot be understood as the limitation of the present application; in order to better illustrate the embodiment of the present application, some components of the drawings will be omitted, enlarged or reduced, and do not represent the size of the actual product; for those skilled in the art, it is understandable that some well-known structures and their descriptions in the drawings can be omitted.

[0079] The same or similar reference numerals in the drawings of the embodiments of the present application correspond to the same or similar components; in the description of the present application, it is understood that if the terms 'upper', 'lower', 'left', 'right', 'front', 'back' and the like indicate the orientation or positional relationship shown in the drawings, only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, therefore the terms describing the positional relationship in the drawings are only used for example description, cannot be understood as the limitation of the present application, for those skilled in the art, the specific meaning of the above terms can be understood according to the specific situation.

[0080] Figure 1 A possible structure schematic diagram of the data sharing system related to the embodiments of the present application is shown. As shown in the figure, the network considers three layers of network, cloud layer, edge layer and terminal layer. The cloud layer provides AI solutions for the network, and coordinates various data sharing tasks. The edge layer is composed of edge computing nodes such as roadside units and base stations, and provides communication, calculation and storage resources for user layer vehicles. The terminal layer is composed of intelligent vehicles participating in data sharing. Figure 1

[0081] ​The edge layer is divided into multiple partitions, each of which is composed of one BS and multiple RSUs, each of which cooperates and processes data sharing tasks in parallel and independently maintains a blockchain to enable data sharing process. Data sharing is carried out in the form of federated learning to ensure the privacy of vehicle users, so vehicles only need to share models rather than data themselves. In the edge layer, a DAG+PBFT double-layer blockchain architecture is adopted to realize safe and efficient asynchronous federated learning, edge trusted verification and data migration in the Internet of Vehicles. The lower layer is composed of a partitioned blockchain based on an improved DAG consensus to realize asynchronous data sharing, responsible for transaction verification (including identity verification and model verification, etc.) and edge model aggregation process within the partition, and the DAG chain is maintained by the BS and multiple RSUs of the partition; the upper layer is composed of a main blockchain based on PBFT consensus, responsible for recording and verifying global cross-zone data migration, and the PBFT chain is maintained by all BSs of the partitions. The RSUs and BSs within a partition are connected through a wireless network to form an edge computing network of a partition. The BSs and RSUs of the terminal layer are connected through a wireless network to form an edge layer. The data sharing vehicles of the terminal layer are connected with the BSs and RSUs through a wireless network to share model data. Data sharing tasks are divided into intra-partition sharing and cross-zone sharing, and the BSs are responsible for cross-zone sharing tasks of vehicles, and the RSUs are responsible for intra-partition sharing tasks of vehicles. The whole process of data sharing will be recorded in the blockchain.

[0082] 1. Optimal sharing strategy of vehicles

[0083] The data sharing vehicle first initiates a sharing request, which is intra-partition sharing or cross-zone sharing, as shown in Figure 2 If it is an intra-partition request, the vehicle will send the request to the RSU of the zone; if it is a cross-zone request, the vehicle will send the request to the BSs of the zone and the target partition. All requests at the current time will be collected and sent to the BS (intra-partition sharing) or the cloud (cross-zone sharing) to calculate the optimal sharing strategy. The time span from the initiation of the sharing task request by the vehicle to the successful confirmation of the task in the blockchain is defined as the time delay of the sharing task. The optimal data sharing strategy is the precision selection, matching and communication resource allocation strategy that minimizes the average total time delay of all tasks, as shown in the following formula:

[0084]

[0085] where T v represents the time delay of the sharing task of vehicle v, which is composed of three parts: 1) local training time delay of the vehicle, related to precision selection; 2) communication time delay of model uploading, related to the time-varying channel conditions caused by vehicle movement; 3) blockchain chaining and confirmation time delay, related to DAG and PBFT time delay. The time delay of the sharing task of vehicle v is as follows:

[0086]

[0087] where and respectively represent the local training of the task, model uploading and blockchain on-chain confirmation delay. The data sharing vehicle will obtain the optimal sharing strategy from the RSU or BS, and at the same time obtain the current Tips, and then perform local training and subsequent sharing according to the obtained sharing strategy. For intra-partition sharing, after the vehicle is locally trained, the model is uploaded to the RSU in the local area according to the sharing strategy, and then added to the local DAG for verification; for cross-area sharing, the vehicle needs to upload to the local BS and target area BS after local training, and add it to the corresponding two DAGs for verification, and then pack all the transactions involved in the cross-area transaction and upload it to the upper PBFT chain to record and verify the cross-area transaction globally. Finally, the vehicle will receive the sharing success information, and the current sharing round ends.

[0088] 2. Intra-partition data sharing

[0089] Each intra-partition uses a DAG-based Tangle network to achieve asynchronous data sharing, as shown in Figure 3 Each transaction in the DAG contains a vehicle-shared model, which is the model aggregated in all transactions pointed to by this transaction and updated by local training. That is, each transaction will point to some Tips when it is added to the DAG network, and then verify and aggregate its model for local training. The transaction will become a Tip after being connected to the DAG network.

[0090] For intra-partition data sharing, the vehicle obtains the current Tips in the DAG from the RSUs in the local area, and randomly selects 2 Tips according to the precision weight. Then verify the validity of the 2 Tips, and extract the model in them to aggregate as the model to be trained.

[0091]

[0092] where C1 and C2 are weight factors representing the importance of the two models from the Tips. According to the obtained optimal sharing strategy (precision selection), the local data set is trained, such as performing a gradient descent:

[0093]

[0094] where α is the learning rate, F v (ω) is the loss function on the vehicle v data set. Then the updated model and its selected Tips are packaged into a transaction, and its structure is as follows: Figure 3Finally, the corresponding RSU uploads the transaction according to the obtained optimal sharing strategy (RSU matching strategy). The RSU will package the transaction, add transaction header information, and then broadcast it to the edge network to be chained to the local DAG, waiting for the verification of other transactions.

[0095] As new transactions are continuously chained, the DAG chain grows, and the Tips are gradually verified to become trusted transactions, and the newly added transactions are supplemented as Tips waiting for the connection of subsequent new transactions. Therefore, the model accuracy in the Tips in the DAG chain will gradually increase to convergence. Vehicles only need to aggregate the models of part (2 in the embodiment of the application) of the Tips in the current DAG chain for local training, without waiting for other vehicles, so the method is asynchronous, and all vehicles can participate in training at any time and can offline at any time.

[0096] 3. Cross-zone data sharing

[0097] For cross-zone data sharing, vehicles will obtain Tips from two DAGs in the local BS and the target BS, then each randomly selects one Tip according to the accuracy weight, verifies the validity, extracts the model for weighted aggregation, trains according to the obtained optimal sharing strategy (accuracy selection) using the local data set, and then packs the updated model and the selected Tips into a transaction. The vehicle uploads the transaction to the DAG network of the local zone and the target zone through the local BS and the target BS, respectively, and then packs the related transactions (the cross-zone transaction and the selected two transactions) into a block, which is added to the upper PBFT main chain through PBFT consensus. The PBFT main chain records the whole process of cross-zone sharing, which is used to record and verify the cross-zone transactions in the DAG globally.

[0098] Based on the above steps, the cross-zone transaction is first recorded in the DAG chain, but its two connected Tips are not in the same DAG chain, making it difficult to verify the validity of the cross-zone transaction. However, the three transactions are all recorded in the upper PBFT main chain, and when verifying the cross-zone transaction, the block information in the main chain needs to be obtained to assist the verification. First, the verifier obtains the block containing the cross-zone transaction from the BS, and verifies its validity. Then, the verifier observes whether the cross-zone transaction and its two connected transactions recorded in the DAG and the target DAG are consistent with the block, and if they are consistent, the validity of the cross-zone transaction is admitted.

[0099] 4. System flow

[0100] Figure 4 The execution flowchart of the secure and efficient data sharing scheme based on blockchain in the Internet of Vehicles is shown, and the specific steps are as follows:

[0101] S401: System initialization;

[0102] S402: The cloud publishes data sharing tasks and initial models to the edge network;

[0103] S403: Generate a task publishing request list;

[0104] S404: BS receives requests;

[0105] S405: Verify the identity information and request content of the requesting vehicle. If it passes, proceed to the next step. If it is a task publishing request, perform S406. If it is a task termination request, perform S409. If it is a cross-zone sharing request, perform S412. Otherwise, repeat step S404;

[0106] S406-S408: BS receives a task publishing request, generates a DAG chain for the task in each partition and adds a genesis block, and broadcasts the information to the edge network, then returns to step S404;

[0107] S409-S411: BS receives a task termination request, terminates the sharing task, and broadcasts the information to the edge network, then returns to step S404;

[0108] S412: BS receives a cross-zone sharing request. If it is a model acquisition request, perform S413. If it is a model upload request, perform S422;

[0109] S413-S415: BS receives a cross-zone sharing model acquisition request, sends all cross-zone sharing request information to the cloud to obtain the optimal sharing strategy;

[0110] S416: The cloud collects cross-zone request information;

[0111] S417: The cloud obtains the optimal sharing strategy by minimizing the long-term average delay of all tasks, including network resource allocation, vehicle and BS or RSU matching, and vehicle local training accuracy;

[0112] S418: Generate an optimal sharing strategy table for the corresponding task, then return to BS;

[0113] S419-S421: BS obtains the optimal sharing strategy, then sends the Tips of the local zone and the Tips of the target partition of the cross-zone and their corresponding sharing strategies to the corresponding vehicles, and finally returns to step S404;

[0114] S422-S428: BS receives a cross-zone sharing model upload request, respectively packages and chains the transaction to the local DAG and the DAG of the target partition of the cross-zone, then packages the cross-zone transaction and all Tips connected to it into a block, and chains it to the upper PBFT chain through PBFT consensus between BSs, finally returns the success information to the vehicle;

[0115] S429: RSU receives the request;

[0116] S430: Verify the identity information and request content of the requesting vehicle. If passed, proceed to the next step, otherwise repeat step S429;

[0117] S431: RSU receives the intra-partition sharing request. If it is a model acquisition request, execute S432. If it is a model upload request, execute S441;

[0118] S432-S434: RSU receives the intra-partition shared model acquisition request, sends all intra-partition sharing request information to the local BS to obtain the optimal sharing strategy;

[0119] S435: BS collects intra-partition request information;

[0120] S436: BS obtains the optimal sharing strategy by minimizing the long-term average delay of all tasks, including network resource allocation, vehicle and BS or RSU matching, and vehicle local training accuracy;

[0121] S437: Generate the optimal sharing strategy table corresponding to the task, and then return to the RSU;

[0122] S438-S440: RSU obtains the optimal sharing strategy, then sends the Tips of the local area and their corresponding sharing strategy to the corresponding vehicle, and finally returns to execute step S429;

[0123] S441-S444: RSU receives the intra-partition shared model upload request, packages the transaction and uploads it to the local DAG, and finally returns the success information to the vehicle;

[0124] S445-S447: Data sharing vehicle initiates a sharing request, which has intra-partition sharing and cross-partition sharing;

[0125] S448: Generate a model acquisition request list. If it is intra-partition sharing, send it to the local RSU to execute S429. If it is cross-partition sharing, send it to the local and target area BSs to execute S404;

[0126] S449: Wait for the information returned by the edge network;

[0127] S450-S452: Extract the model information in the obtained Tips. If it is intra-partition sharing, randomly select 2 Tips in the local Tips according to the accuracy weight to verify their effectiveness and aggregate the model. If it is cross-partition sharing, randomly select 1 Tips from the local and target partition Tips according to the accuracy weight to verify their effectiveness and aggregate the model;

[0128] S453: Train the aggregated model according to the obtained optimal sharing strategy;

[0129] S454-S457: Pack the updated model and the hash information of the selected Tips into a transaction, and upload the model to the corresponding RSU according to the optimal strategy if the sharing is within the partition, or upload the model to the BS in the current partition and the BS in the target partition across the partition according to the optimal strategy if the sharing is across the partition, and perform S429 or S404;

[0130] S458: Receive the return information and start the next round of sharing, and return to perform S225;

[0131] S459: The cloud obtains the current model training situation from the edge network;

[0132] S460: Analyze the performance of the current model;

[0133] S461: When it considers that the model meets the expectation or has converged, send the task termination information to each partition RSU and BS, and the data sharing task ends, otherwise return to perform S459;

[0134] S462: Send the task termination information to the BS;

[0135] S463: Generate a task termination request list and send it to the BS;

[0136] S464: The running ends.

[0137] Finally, it should be pointed out that the above embodiments are only used to illustrate the technical solutions of the present application and are not limiting. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced equivalently without departing from the purpose and scope of the technical solutions, and they should be covered in the scope of the claims of the present application.

Claims

1.A blockchain-based secure data sharing method for Internet of Vehicles, characterized in that: The method comprises the following steps: S1: the cloud initiates a data sharing task to the edge network, and uploads an initial model to each partitioned blockchain network; S2: a data sharing vehicle initiates a data sharing request to obtain a current model and an optimal sharing strategy; S3: the data sharing vehicle obtains the model from the RSU or the BS, verifies and aggregates the selected model as a to-be-trained model; S4: the data sharing vehicle trains the model obtained in S3 using a local data set to obtain an updated global model; S5: the data sharing vehicle uploads the global model in S4 to the blockchain network through the RSU or the BS; S6: all data sharing vehicles repeat steps S2-S5 until the partitioned models converge; In S1, the data sharing network comprises a cloud layer, an edge layer and a terminal layer; the cloud layer provides an AI solution for the network and plans all kinds of data sharing tasks; the edge layer comprises edge computing nodes such as roadside units and base stations, and provides communication, calculation and storage resources for the user layer vehicle; the terminal layer comprises intelligent vehicles participating in data sharing; The edge layer is divided into multiple partitions, each partition comprises a BS and multiple RSUs, each partition cooperatively and in parallel processes the data sharing task and independently maintains a blockchain to enable the data sharing process, and the data sharing is in the form of federated learning to ensure the data privacy of the vehicle user; a DAG+PBFT double-layer blockchain architecture is adopted in the edge layer to realize safe and efficient asynchronous federated learning, edge trusted verification and data migration in the Internet of Vehicles; wherein, the lower layer comprises a partitioned blockchain based on an improved DAG consensus to realize asynchronous data sharing, is responsible for transaction verification and edge model aggregation process in the partition, and the DAG chain is maintained by the BS and multiple RSUs of the partition; the upper layer comprises a main blockchain based on a PBFT consensus, is responsible for recording and verifying global cross-zone data migration, and the PBFT chain is maintained by all BSs of the partitions; the RSUs and the BSs in the partition are connected through a wireless network to form an edge computing network of a partition; the BSs are connected through a wireless network between the partitions to form the entire edge layer; the data sharing vehicles of the terminal layer are connected with the BSs and the RSUs through wireless connection to share model data; the data sharing task is divided into intra-partition sharing and cross-zone sharing, the BS is responsible for the cross-zone sharing task of the vehicle, and the RSU is responsible for the intra-partition sharing task of the vehicle; the entire data sharing process is recorded in the blockchain. 2.The blockchain-based secure data sharing method for V2X according to claim 1, wherein: In S2, the optimal sharing strategy is: The data sharing vehicle first initiates a sharing request, which is intra-partition sharing or cross-zone sharing, if it is an intra-partition request, the vehicle sends the request to the RSU in the region; If it is a cross-zone request, the vehicle sends the request to the BSs in the region and the target partition; All requests at the current time are collected and sent to the BS or the cloud to calculate the optimal sharing strategy; the time span from the initiation of the sharing task request by the vehicle to the confirmation of the success of the task in the blockchain is defined as the time delay of a sharing task; the optimal data sharing strategy is the precision selection, matching and communication resource allocation strategy that minimizes the average total time delay of all tasks, as shown in the following formula: where T v denotes the latency of vehicle v sharing the task, which is calculated by three parts: 1) vehicle local training latency, which is related to the precision selection; 2) the communication latency of the shared model upload, which is related to the time-varying channel conditions caused by the vehicle movement; 3) the blockchain on-chain and confirmation latency, which is related to the DAG and PBFT latency; the latency of the vehicle v sharing the task is as follows: wherein and respectively represent the local training of the task, model uploading and blockchain on-chain confirmation delay; the data sharing vehicle will obtain the optimal sharing strategy from the RSU or BS, and obtain the current Tips, and then perform local training and subsequent sharing according to the obtained sharing strategy; for intra-partition sharing, after local training of the vehicle, the model is uploaded to the RSU in the local area according to the sharing strategy, and then added to the local DAG for verification; for cross-area sharing, after local training of the vehicle, the model needs to be uploaded to the BS in the local area and the target area BS, and added to the corresponding two DAGs for verification, and then all transactions involved in the cross-area transaction are packaged and uploaded to the upper PBFT chain to record and verify the cross-area transaction globally; finally, the vehicle will receive the sharing success information, and the current sharing round ends. 3.The blockchain-based secure data sharing method for V2X according to claim 2, wherein: The intra-partition sharing is: Each partition uses a DAG-based Tangle network to achieve asynchronous data sharing; each transaction in the DAG contains a model shared by a vehicle, which is obtained by local training update after aggregation of the models in all transactions pointed to by this transaction; that is, each transaction, when joined to the DAG network, will point to some Tips, then verify and aggregate the models thereof for local training; the transaction will become a Tip after being connected to the DAG network; For intra-partition data sharing, the vehicle obtains the Tips in the current DAG from the RSUs in the region, and randomly selects 2 Tips according to the accuracy weight; then the validity of the 2 Tips is verified, and the models thereof are extracted and weighted aggregated as the to-be-trained model; Wherein C1 and C2 are weight factors representing the importance of the two models from the Tips; the obtained optimal sharing strategy is used for training using the local data set, such as performing a gradient descent: where a is the learning rate, F v (ω) is the loss function on the vehicle v dataset; then the updated model and its selected Tips are packaged into a transaction; finally, the corresponding RSU uploads the transaction according to the obtained optimal sharing strategy; the RSU will package the transaction, add transaction header information, and then broadcast to the edge network to be chained to the local DAG, waiting for the verification of other transactions; As new transactions are continuously on-chained, the DAG chain grows, the Tips are gradually changed into trusted transactions after being verified, and the newly added transactions are supplemented as Tips waiting for connection of subsequent new transactions; the model accuracy in the Tips in the DAG chain gradually increases to convergence. 4.The blockchain-based secure data sharing method for V2X according to claim 2, wherein: The cross-region sharing is: The vehicle obtains Tips from two DAGs in the local BS and the target BS, respectively, then randomly selects 1 Tip from each according to the accuracy weight, extracts the model after verifying the validity, and uses the local data set to train according to the obtained optimal sharing strategy, and then packs the updated model and the selected Tips into a transaction; the vehicle uploads the transaction to the DAG network in the local region and the target region through the local BS and the target BS, respectively, then packs the related transactions into a block, and adds the block to the upper PBFT main chain through PBFT consensus; The PBFT main chain records the whole process of cross-region sharing, and is used for globally recording and verifying the cross-region transactions in the DAG; The cross-region transaction is first recorded in the DAG chain, and the verifier obtains the block containing the cross-region transaction from the BS, and verifies the validity thereof; Then, the verifier observes whether the cross-region transaction and the two transactions connected thereto recorded in the DAG and the target DAG are consistent with those recorded in the block, and if consistent, the validity of the cross-region transaction is admitted. 5.The blockchain-based secure data sharing method for V2X according to claim 1, wherein: The specific steps of the vehicle network security data sharing method are as follows: S401: system initialization; S402: the cloud end publishes a data sharing task and an initial model to an edge network; S403: generating a task publishing request list; S404: the BS receives the request; S405: verifying the identity information and the request content of the vehicle, if passed, then entering the next step, if it is a task publishing request, then executing S406; if it is a task termination request, then executing S409; If it is a cross-region sharing request, then executing S412; otherwise, repeating step S404; S406-S408: The BS receives the task publishing request, generates a DAG chain for the task in each partition and adds a genesis block, broadcasts the information to the edge network, and then returns to step S404; S409-S411: The BS receives the task termination request, terminates the shared task, and broadcasts the information to the edge network, and then returns to step S404; S412: The BS receives the cross-partition sharing request, and if it is a model acquisition request, it performs S413; if it is a model upload request, it performs S422; S413-S415: The BS receives the cross-partition shared model acquisition request, sends all cross-partition sharing request information to the cloud to obtain the optimal sharing strategy; S416: The cloud collects cross-partition request information; S417: The cloud obtains the optimal sharing strategy by minimizing the long-term average delay of all tasks, including network resource allocation, vehicle and BS or RSU matching, and vehicle local training accuracy; S418: Generate an optimal sharing strategy table for the corresponding task, and then return to the BS; S419-S421: The BS obtains the optimal sharing strategy, then sends the Tips of the local area and the Tips of the target partition of the cross-area and their corresponding sharing strategies to the corresponding vehicles, and finally returns to step S404; S422-S428: The BS receives the cross-partition shared model upload request, respectively packages and uploads the transaction to the local area DAG and the DAG of the target partition, then packages the cross-area transaction and all Tips connected to it into a block, and uploads it to the upper PBFT chain through PBFT consensus between BSs, and finally returns the success information to the vehicle; S429: The RSU receives the request; S430: Verify the identity information and request content of the requesting vehicle, if it passes, proceed to the next step, otherwise repeat step S429; S431: The RSU receives the intra-partition sharing request, and if it is a model acquisition request, it performs S432; if it is a model upload request, it performs S441; S432-S434: The RSU receives the intra-partition shared model acquisition request, sends all intra-partition sharing request information to the local area BS to obtain the optimal sharing strategy; S435: The BS collects intra-partition request information; S436: The BS obtains the optimal sharing strategy by minimizing the long-term average delay of all tasks, including network resource allocation, vehicle and BS or RSU matching, and vehicle local training accuracy; S437: Generate an optimal sharing strategy table for the corresponding task, and then return to the RSU; S438-S440: The RSU obtains the optimal sharing strategy, then sends the Tips of the local area and their corresponding sharing strategies to the corresponding vehicles, and finally returns to step S429; S441-S444: The RSU receives the intra-partition shared model upload request, packages and uploads the transaction to the local area DAG, and finally returns the success information to the vehicle; S445-S447: Data sharing vehicles initiate sharing requests, including intra-partition sharing and cross-partition sharing. S448: generate a model acquisition request list, if it is intra-partition sharing, send to the RSU in the area to execute S429; if it is cross-area sharing, send to the BSs in the area and the target area to execute S404; S449: wait for the information returned by the edge network; S450-S452: extract the model information in the obtained Tips, if it is intra-partition sharing, randomly select 2 Tips in the area according to the precision weight to verify their effectiveness and aggregate the model; if it is cross-area sharing, randomly select 1 Tips from the Tips in the area and the target partition according to the precision weight to verify their effectiveness and aggregate the model; S453: train the aggregated model according to the obtained optimal sharing strategy; S454-S457: pack the updated model and the hash information of the selected Tips into a transaction, if it is intra-partition sharing, connect the corresponding RSU to upload the model according to the optimal strategy, execute S429; if it is cross-area sharing, connect the BSs in the area and the target partition to upload the model according to the optimal strategy, execute S404; S458: receive the returned information and start the next round of sharing, return to execute S225; S459: the cloud obtains the current model training situation from the edge network; S460: analyze the performance of the current model; S461: when it considers that the model reaches the expectation or has converged, send task termination information to each partition RSU and BS, the data sharing task is ended, otherwise return to execute S459; S462: send the task termination information to the BS; S463: generate a task termination request list and send it to the BS; S464: the running is ended.

Images