A blockchain-based zero-trust collaborative computing method for Internet of Vehicles

Abstract

The present invention provides a blockchain-based zero-trust vehicle network collaborative computing method, comprising: a task offloading requesting vehicle sends relevant task information and vehicle information to the nearest roadside unit; the roadside unit reads the scores of each service vehicle providing computing from the blockchain, and selects a task execution vehicle based on the scores of each service vehicle and a multi-attribute task offloading algorithm; the task execution vehicle establishes a transaction with the task offloading requesting vehicle, and the transaction is recorded in the roadside unit; after the task is executed, the task execution vehicle transmits the calculation result to the task offloading requesting vehicle and the roadside unit; the roadside unit selects a verification vehicle group to repeatedly calculate the execution task and obtain the calculation result; by comparing the calculation results of the task execution vehicle with those of the verification vehicle group, the correctness of the calculation result of the task execution vehicle is determined; and a smart contract automatically executes payment or penalty based on the correctness of the calculation result of the task execution vehicle. The method of the present invention improves the resource utilization of vehicles.

Description

Technical Field

[0001] The present invention relates to the field of vehicle collaborative computing technology, and in particular to a zero-trust vehicle network collaborative computing method based on blockchain. Background Art

[0002] The Internet of Things (IoT) has become a transformative force in intelligent transportation systems. Powerful communication technologies such as dedicated short-range communications (DSRC) and advanced cellular networks (such as 5G) within the IoT enable efficient, high-speed data exchange within vehicle networks, laying the foundation for the Internet of Vehicles (IoV). However, as technology evolves, the IoV also faces unique challenges. For example, emerging modes such as urban air traffic and autonomous driving will further complicate urban transportation, requiring powerful computing and communication capabilities to support real-time, data-intensive applications. Addressing the communication and computing challenges of these applications typically relies on roadside units, edge servers, and mobile cloud computing. However, these solutions often come with high costs and significant end-to-end latency.

[0003] Vehicular fog computing (VFC) addresses these challenges by extending computing power to edge networks and utilizing vehicles on the road as infrastructure nodes. The VFC architecture primarily consists of three layers: the cloud layer, where remote servers and data centers reside; the cloudlet layer, where local fog servers (LFSs) reside; and the fog layer, where vehicles reside. In the VFC architecture, after a vehicle generates a task, the LFS schedules the task, deciding whether to offload it to a remote server, handle it within the local service area, or transfer it to an LFS in a neighboring service area. By leveraging the vehicle's idle computing resources, VFCs can more efficiently process real-time, data-intensive operations and reduce latency, unleashing their enormous computing potential. To effectively align the computing resources of various nodes (FVs, roadside units, and edge / cloud servers) with tasks and optimize the offloading process, task offloading in VFCs has become a key research topic for improving the quality of service (QoS) of connected vehicles. Numerous studies have focused on addressing the various challenges of task offloading, including mobility control, resource allocation, power management, and security. Trust management is also crucial in the VFC task offloading process. The effectiveness of task offloading depends heavily on the reliability of participating nodes. Malicious nodes that return erroneous computational results pose a significant threat, undermining the overall efficiency of the task offloading strategy. Despite advances in trust management, existing technologies typically treat trust and computation as two separate phases of task offloading, potentially wasting computing resources and increasing the risk of vehicle fraud.

[0004] Meanwhile, with the development of 6G technology, the concept of Zero Trust (ZT) has been proposed. As a key security concept, ZT assumes that all users are untrustworthy and does not grant implicit trust based solely on physical location or asset ownership. By continuously verifying and dynamically authorizing all users based on trust factors, ZT provides a set of concepts and ideas designed to minimize uncertainty. In the field of cybersecurity, ZT was developed to address cyber threats and security vulnerabilities. Its advantages have been explored in various scenarios. However, its application in the dynamic environment of the Internet of Vehicles has not been fully considered and studied. Summary of the Invention

[0005] In view of this, the present invention provides a blockchain-based zero-trust Internet of Vehicles collaborative computing method to solve the above problems.

[0006] The present invention provides a zero-trust vehicle network collaborative computing method based on blockchain, including: a task offloading requesting vehicle sends relevant task information and vehicle information to the nearest roadside unit; the roadside unit reads the scores of each service vehicle providing computing resources from the blockchain, and selects a task execution vehicle based on the scores of each service vehicle providing computing resources and a multi-attribute task offloading algorithm; the task execution vehicle establishes a transaction with the task offloading requesting vehicle, and the transaction is recorded in the roadside unit; after the task is executed, the task execution vehicle transmits the calculation result to the task offloading requesting vehicle and the roadside unit; the roadside unit selects a verification vehicle group to repeatedly calculate the execution task to obtain a calculation result; by comparing the calculation results of the task execution vehicle and the verification vehicle group, the correctness of the calculation result of the task execution vehicle is determined; the smart contract automatically executes payment or penalty according to the correctness of the calculation result of the task execution vehicle.

[0007] In another implementation of the present invention, the multi-attribute task offloading algorithm comprehensively considers multiple attributes of a task, including the task's computational requirements, deadline, data size, and priority.

[0008] In another implementation of the present invention, it also includes: when the accumulated transaction records in the roadside unit reaches a preset threshold, the blockchain verification process is started, other node operators verify the new block, and add the new block to the blockchain after reaching a consensus.

[0009] In another implementation of the present invention, the roadside unit reads the scores of each service vehicle providing computing resources from the blockchain, and selects a task execution vehicle based on the scores of each service vehicle providing computing resources and a multi-attribute task offloading algorithm, including: the roadside unit collects the willingness and vehicle information of the computing resource vehicles within a distance threshold, evaluates the trust score of the service vehicles providing computing resources, and stores it in the blockchain; based on the trust score, task attributes and communication resource conditions, calculates the task expectation of each pair of tasks and service vehicles providing computing resources after matching, obtains an expectation matrix, and converts it into a cost matrix; based on the Hungarian algorithm, uses the cost matrix to determine a task offloading scheme that meets the maximum expectation; and selects a task execution vehicle based on the task offloading scheme.

[0010] In another implementation of the present invention, the roadside unit selects a verification vehicle group to perform repeated calculations on the execution task to obtain a calculation result, including: the roadside unit selects a verification vehicle group based on a genetic algorithm; initializes the verification vehicle group and calculates the fitness function of the verification vehicle group; eliminates solutions in the fitness function that are less than a preset threshold, and copies solutions in the fitness function that are greater than the preset threshold; and performs cross and compilation operations on the remaining solutions to obtain a calculation result.

[0011] In another implementation of the present invention, the smart contract automatically executes payment or punishment based on the correctness of the calculation result of the task execution vehicle, including: if the calculation result of the task execution vehicle is consistent with the settlement result of the verification vehicle group, it means that the calculation result is correct, and the smart contract rewards the task execution vehicle that honestly completes the task; if the calculation result of the task execution vehicle is inconsistent with the settlement result of the verification vehicle group, it means that the calculation result is wrong, and the smart contract punishes the task execution vehicle that dishonestly completes the task.

[0012] In another implementation of the present invention, the method further includes: updating the vehicle score and writing it into the blockchain based on the correctness of the calculation result of the vehicle executing the task.

[0013] Another aspect of the present invention provides a zero-trust vehicle network collaborative computing system based on blockchain, including: a task offloading module: used for the task offloading requesting vehicle to send relevant task information and vehicle information to the nearest roadside unit; a scoring management module: used for the roadside unit to read the scores of each service vehicle providing computing resources from the blockchain, and select the task execution vehicle according to the scores of each service vehicle providing computing resources and the multi-attribute task offloading algorithm; an information management module: used for the task execution vehicle to establish a transaction with the task offloading requesting vehicle, and the transaction is recorded in the roadside unit; after the task is executed, the task execution vehicle transmits the calculation result to the task offloading requesting vehicle and the roadside unit; a verification feedback module: used for the roadside unit to select a verification vehicle group to repeatedly calculate the execution task to obtain the calculation result; by comparing the calculation results of the task execution vehicle and the verification vehicle group, the correctness of the calculation result of the task execution vehicle is determined; the smart contract automatically executes payment or penalty according to the correctness of the calculation result of the task execution vehicle.

[0014] The blockchain-based zero-trust Internet of Vehicles collaborative computing method of the present invention effectively improves the computing efficiency of multi-vehicle collaboration, ensures the successful and effective completion rate of tasks, fully improves the resource utilization of vehicles, and reduces system latency. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. By reading the detailed description of the embodiments below, the advantages and benefits of the solutions will become clear to those skilled in the art. The drawings are only for the purpose of illustrating preferred embodiments and are not to be considered as limiting the present invention.

[0016] In the attached figure:

[0017] Figure 1 This is a flowchart of a blockchain-based zero-trust vehicle network collaborative computing method according to an embodiment of the present invention.

[0018] Figure 2 FIG. 1 is a schematic diagram of the BlockZT-VFC architecture according to an embodiment of the present invention.

[0019] Figure 3 Schematic diagram of the relationship between functional modules in the architecture of an embodiment of the present invention.

[0020] Figure 4 This is an experimental simulation diagram of the impact of penalty intensity and verification probability on system utility according to an embodiment of the present invention.

[0021] Figure 5This is an experimental simulation diagram of the impact of the verification threshold on the effective task completion rate (ETR) and verification accuracy rate of an embodiment of the present invention.

[0022] Figure 6 This is an experimental simulation diagram showing how the average delay changes with the increase in the number of service vehicles under different scenarios according to an embodiment of the present invention.

[0023] Figure 7 This is an experimental simulation diagram showing how the effective task completion rate changes with the increase in the number of service vehicles under different scenarios according to an embodiment of the present invention.

[0024] Figure 8 This is an experimental simulation diagram showing how throughput changes with the increase in the number of service vehicles under different scenarios according to an embodiment of the present invention.

[0025] Figure 9 This is an experimental simulation diagram showing how the number of vehicles in different fractional segments changes over time according to an embodiment of the present invention. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be clearly and detailedly described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in the embodiments of the present invention should fall within the scope of protection of the embodiments of the present invention.

[0027] Figure 1 A flowchart of a blockchain-based zero-trust vehicle networking collaborative computing method provided by an embodiment of the present invention is as follows: Figure 1 As shown, this embodiment mainly includes:

[0028] S101: A task offloading requesting vehicle sends relevant task information and vehicle information to the nearest roadside unit.

[0029] For example, the roadside unit mainly acts as a platform for vehicle matching and transactions. Task offloading request vehicles (RVs) and service vehicles (FVs) providing computing resources send corresponding requests and vehicle information to the roadside unit. The dynamic environment is modeled as a Hungarian matching process that minimizes system delay under multi-attribute constraints. The roadside unit performs global resource service matching optimization while satisfying individual optimization goals.

[0030] S102. The roadside unit reads the scores of each service vehicle providing computing resources from the blockchain, and selects a task execution vehicle based on the scores of each service vehicle providing computing resources and the multi-attribute task offloading algorithm.

[0031] For example, based on the vehicle fog computing architecture, the roadside center unit is used as the resource control node in the service area (fog area). The roadside center unit realizes the sharing of computing resources between areas through the connection with the external area, and then assists the trading of computing resources between vehicles within the area to meet the supply and demand requirements of computing resources of different vehicles.

[0032] The concept of zero trust is introduced into the architecture. The zero trust concept in the Internet of Vehicles environment means that all vehicle nodes are untrustworthy, and implicit trust is not granted to assets or user accounts based on physical location or asset ownership. It is necessary to adopt continuous verification and dynamic authorization to dynamically manage the trust of vehicle nodes. After determining the service vehicle to perform the task, the multi-attribute task offloading algorithm is used to authorize the selected service vehicles (FVs) to perform the task.

[0033] S103: The task execution vehicle establishes a transaction with the task unloading request vehicle, and the transaction is recorded in the roadside unit.

[0034] For example, the authorized task execution vehicle establishes a transaction with the task offloading request vehicle. Under the constructed P2P resource transaction framework, the service vehicle that provides computing resources can obtain currency by completing computing tasks or verification tasks, and the vehicle that issues the service request can use the currency to purchase the idle computing resources of other vehicles.

[0035] This task offloading algorithm allows vehicles to autonomously determine the number of transactions based on their relative demand for computing resources and currency. Roadside units then perform unified matching within the region, minimizing system latency while satisfying both parties' supply and demand. This algorithm also optimizes the returns for both parties. The buyer and seller must establish a match that generates positive returns for both parties, ensuring that both parties involved in the resource transaction experience corresponding benefits.

[0036] S104: After the task is executed, the task executing vehicle transmits the calculation results to the task offloading requesting vehicle and the roadside unit.

[0037] S105. The roadside unit selects a verification vehicle group to perform repeated calculations on the execution task to obtain calculation results.

[0038] For example, a verification mechanism is provided for the constructed environment framework to ensure the credibility of the task offloading process and incentivize vehicles to contribute computing resources. This verification mechanism offloads a task to multiple vehicles, ensures that this group of vehicles meets the required requirements, and then determines the correctness of the original result by comparing the calculation results of this group of vehicles. The specific data of the verification task can be stored in the cloud to facilitate subsequent delayed verification, thereby enabling the detection of vehicles launching deceptive attacks. The verification mechanism adopted is a redundant verification scheme, which can choose to verify immediately or delay verification according to the vehicle's wishes.

[0039] S106 , determining the correctness of the calculation results of the task execution vehicle by comparing the calculation results of the task execution vehicle with those of the verification vehicle group.

[0040] S107. The smart contract automatically executes payment or penalty based on the correctness of the calculation results of the task execution vehicle.

[0041] For example, smart contracts are used on the blockchain to ensure the security of data transmission and the fairness and transparency of the transaction process, including ensuring that private keys are used to encrypt data when transmitting between the roadside unit and the vehicle, public keys are used to decrypt data when receiving data, and after the transaction is completed, the vehicle's account is deducted and paid by evaluating the completion quality of the vehicle.

[0042] The blockchain-based zero-trust Internet of Vehicles collaborative computing method of the present invention is distributed, not centralized, which effectively improves the computing efficiency of multi-vehicle collaboration, ensures the successful and effective completion rate of tasks, fully improves the resource utilization of vehicles, and reduces system latency.

[0043] In another implementation of the present invention, the multi-attribute task offloading algorithm comprehensively considers multiple attributes of a task, including the task's computational requirements, deadline, data size, and priority.

[0044] In another implementation of the present invention, it also includes: when the accumulated transaction records in the roadside unit reaches a preset threshold, the blockchain verification process is started, other node operators verify the new block, and add the new block to the blockchain after reaching a consensus.

[0045] For example, the RSU layer includes two types of RSUs, each with different responsibilities. Standard RSU nodes are responsible only for vehicle matching and collecting vehicle service records, while node operator RSUs are responsible for generating service record blocks and vehicle account blocks and adding them to the blockchain.

[0046] The blockchain consists of two blockchains: the service transaction record blockchain and the vehicle account blockchain. The service transaction record blockchain records every transaction between vehicles, while the vehicle account blockchain records and manages vehicle account balance information.

[0047] In another implementation of the present invention, the roadside unit reads the scores of each service vehicle providing computing resources from the blockchain, and selects a task execution vehicle based on the scores of each service vehicle providing computing resources and a multi-attribute task offloading algorithm, including: the roadside unit collects the willingness and vehicle information of the computing resource vehicles within a distance threshold, evaluates the trust score of the service vehicles providing computing resources, and stores it in the blockchain; based on the trust score, task attributes and communication resource conditions, calculates the task expectation of each pair of tasks and service vehicles providing computing resources after matching, obtains an expectation matrix, and converts it into a cost matrix; based on the Hungarian algorithm, uses the cost matrix to determine a task offloading scheme that meets the maximum expectation; and selects a task execution vehicle based on the task offloading scheme.

[0048] In another implementation of the present invention, the roadside unit selects a verification vehicle group to perform repeated calculations on the execution task to obtain a calculation result, including: the roadside unit selects a verification vehicle group based on a genetic algorithm; initializes the verification vehicle group and calculates the fitness function of the verification vehicle group; eliminates solutions in the fitness function that are less than a preset threshold, and copies solutions in the fitness function that are greater than the preset threshold; and performs cross and compilation operations on the remaining solutions to obtain a calculation result.

[0049] For example, the verification vehicle set must meet two constraints. One is that the product of the verification vehicle score values ​​must be greater than a specified value. This constraint is used to ensure that at least one vehicle returns the correct result; the other constraint is that the vehicle that accepts the task must have sufficient computing resources to complete the task.

[0050] The genetic algorithm for selecting the verification vehicle set includes two types of crossover methods when performing the gene crossover process. One is intra-gene crossover, that is, two groups of vehicle sets for verifying the same task are randomly exchanged; the other is inter-gene crossover, that is, two groups of vehicle sets for verifying different tasks are randomly exchanged.

[0051] In another implementation of the present invention, the smart contract automatically executes payment or punishment based on the correctness of the calculation result of the task execution vehicle, including: if the calculation result of the task execution vehicle is consistent with the settlement result of the verification vehicle group, it means that the calculation result is correct, and the smart contract rewards the task execution vehicle that honestly completes the task; if the calculation result of the task execution vehicle is inconsistent with the settlement result of the verification vehicle group, it means that the calculation result is wrong, and the smart contract punishes the task execution vehicle that dishonestly completes the task.

[0052] In another implementation of the present invention, the method further includes: updating the vehicle score and writing it into the blockchain based on the correctness of the calculation result of the vehicle executing the task.

[0053] For example, during the transaction process, the honesty and deception of the vehicle will be recorded in the blockchain as a service record. Vehicles that correctly calculate the task and complete it within the specified time will receive reward currency. Vehicles that fail to provide corresponding computing resources or fail to complete the task within the specified time will be punished by deducting corresponding currency. This reward and punishment process is automatically executed when the block is added to the blockchain through smart contract technology.

[0054] In another implementation of the present invention, each vehicle can only perform a limited number of computing resource transactions within each time period. This transaction ensures that ownership of the computing resources is transferred to the buyer within a certain period of time. After that, the seller will provide computing services to complete the tasks posted by the buyer.

[0055] In another implementation of the present invention, Figure 2 As shown in Figure 2, BlockZT-VFC consists of a three-layer architecture: cloud layer, roadside unit layer, and vehicle fog layer.

[0056] The cloud layer is used to provide basic authentication services, is responsible for registering vehicles and roadside units, and distributes public and private keys and digital certificates, as well as providing sufficient storage resources to store specific task offloading content.

[0057] The blockchain is built on the roadside unit layer, where the node operator roadside unit node is a trusted roadside unit responsible for collecting transaction records from road layer units within the perception range, generating blocks and broadcasting them, acting as an account management server to manage the vehicle's currency account; ordinary roadside units serve as transaction server nodes in the blockchain network, responsible for communicating with vehicles, assisting vehicles in the task unloading process, and recording transaction information.

[0058] In another implementation of the present invention, a blockchain-based P2P trusted computing resource transaction architecture BlockZT-VFC is designed with multi-attribute task offloading and group-based continuous verification scheme (MAOCV), as described below:

[0059] 1) In each time period, vehicles willing to offload tasks will send relevant task information and vehicle information to the nearest roadside unit;

[0060] a) The roadside unit collects the willingness and information of nearby computing resource sellers and evaluates the trust score of the vehicle;

[0061] b) Calculate the expected QoS of task offloading based on vehicle scores, task attributes, and communication resource conditions;

[0062] c) Calculate the expected QoS of each task after matching the vehicle computing resources, obtain the expected matrix, and convert it into a cost matrix;

[0063] 2) Based on the Hungarian algorithm, the cost matrix is ​​used to obtain a task offloading solution that meets the maximum expected QoS;

[0064] 3) Execute the task offloading process and write the transaction information into the blockchain;

[0065] 4) Select the verification vehicle group based on genetic algorithm:

[0066] a) For each verification task, initialize the verification vehicle group corresponding to the verification task

[0067] b)Repeat

[0068] times←0

[0069] Calculate the fitness function of each verification vehicle group

[0070] Eliminate the solutions with smaller fitness functions, copy the solutions with larger fitness functions, perform cross-compilation and compilation operations on the solutions, and obtain a new solution set.

[0071] times←times+1

[0072] c)Until times>max iterations

[0073] d) Unload the tasks that need to be verified to their corresponding verification vehicle groups. After each verification vehicle completes the verification, it returns the verification results to the RSU;

[0074] 5) RSU summarizes the verification results of the verification vehicles and determines whether the task has been completed honestly;

[0075] 6) RSU uses the blockchain’s smart contract to punish vehicles that dishonestly complete tasks, reward vehicles that honestly complete tasks, and update the vehicle’s credit score and write it into the blockchain. This time period ends and enters the next period.

[0076] The proposed architecture and algorithm can effectively reduce system latency and improve the system's effective task completion rate during actual operation.

[0077] In another implementation of the present invention, a comparison is presented of local task completion rates under different environmental parameters within a VFC architecture. In the simulation, both the generation of computing tasks and the arrival of vehicles at a service area are assumed to follow a Poisson distribution. The overall task completion rate can be used to measure the service area's ability to handle tasks. Table 1 below lists the simulation parameters, where the malicious probability represents the probability that a vehicle would return an erroneous result in a typical computing framework. A higher probability value indicates a greater likelihood of a vehicle returning an erroneous result and a lower success rate for the task.

[0078] Table 1 Simulation parameters

[0079] Simulation time 200s Vehicle computing resources 2.5Gage cycle / s Vehicle score (0,1) Number of vehicles 50 Vehicle information transmission power 23dBm Calculate task data size [0.02,1]MB Task time period [0.1,0.3]Gigacycle Task unit price [0.3,1]$ / G cycle Roadside unit coverage radius 500m Number of roadside units (RBs) 20 Vehicle computing resource cost 0.3 / 0.5$ / G cycle Vehicle malicious probability 10％ / 20％

[0080] The algorithm of this solution is evaluated based on the following indicators:

[0081] 1) Average Task Latency: The latency of a successfully transmitted task is the sum of the transmission latency and computation latency. For tasks that fail due to transmission errors, timeouts, or spoofing, their latency is considered their deadline.

[0082] 2) Task throughput: Task throughput is defined as the number of computing tasks completed in each time slot in the system.

[0083] 3) Effective Task Rate (ETR): An effective task is a task that is completed honestly within the deadline. The effective task completion rate is the ratio of the number of effective tasks to the total number of computing tasks.

[0084] Since the system utility is affected by the verification mechanism parameters, such as verification probability, penalty intensity, and verification threshold, multiple trials are conducted to determine the optimal values ​​of these parameters in order to demonstrate the comprehensiveness of the simulation experiments.

[0085] First, regarding the impact of verification probability and penalty intensity, higher verification probabilities and higher penalty intensities reduce the utility gained by vehicles cheating, encouraging them to behave honestly. This increases the effective task completion rate and improves the overall utility of the system. However, excessively high verification probabilities may cause verification tasks to occupy computing resources for other tasks, and overly harsh penalties may inhibit the motivation of vehicles in the system. Therefore, experiments were conducted under different acceptance probability and penalty intensity scenarios to obtain empirically optimal parameters.

[0086] For each parameter, 10 experiments were conducted and the average results were recorded. Figure 4 It can be seen that the points corresponding to the maximum system utility are (5, 32%) and (9, 20%). In view of the fact that a lower verification probability can reduce the verification overhead, a verification probability of 20% and a penalty intensity of 9 are selected as the empirical parameters for subsequent experiments.

[0087] Next, we design the verification threshold. The verification mechanism improves accuracy by offloading redundancy. However, accuracy is affected by the verification threshold. We need to ensure that the probability of misjudgment is below this threshold. Setting the threshold too low may lead to excessive redundant calculations, thus monopolizing the system's computing resources. Through experiments, we found an appropriate verification threshold with high verification accuracy and low verification overhead. Figure 5 The trends of validation accuracy and ETR at different validation thresholds are shown. Statistics show that when the threshold is about 3%, both validation accuracy and ETR exceed 95%.

[0088] Figure 6The average delays of four different algorithms in two scenarios are presented, and the results show that MAOCV outperforms the comparison algorithms in terms of average delay, especially in environments with high malicious rates. In addition, algorithms that integrate group verification mechanisms (such as V-GS and MAOCV) significantly outperform GS and WHO in reducing average delay and improving system performance. Although the verification process does not have strict delay requirements, the use of genetic algorithms with lower delay can improve the utilization of computing resources over a longer period of time. In addition, by considering the multiple attributes of tasks and vehicles, MAOCV unifies trustworthiness and computing into one stage of task offloading, selects appropriate RV-FV pairs and optimizes ETR. MAOCV effectively reduces delays caused by task failures, and the system delay is reduced by 34% compared to WHO.

[0089] Figure 7 It shows that algorithms that include verification mechanisms are significantly better than algorithms that do not include verification mechanisms in terms of ETR. The incentive structure created by the verification mechanism prompts rational vehicles to complete tasks in a timely manner and return accurate results to avoid penalties for failing the verification process. Therefore, the verification mechanism plays a key role in improving the overall efficiency and effectiveness of the system.

[0090] Figure 8 The results show that MAOCV outperforms the other three algorithms in terms of throughput, and V-GS also outperforms the basic GS algorithm. Despite the verification overhead, the group verification mechanism utilizes the idle computing resources of low-scoring vehicles without preempting computing resources. Instead, the verification feedback module improves the ETR and increases the effective task throughput of the system. Compared with WHO, MAOCV effectively improves system throughput by 18%.

[0091] Figure 9 The curves in Figure 1 show how the number of vehicles in the system varies over time, based on the randomly assigned initial scores. Vehicles are divided into three groups using a set score threshold. Specifically, the top 30% of scores are assigned a high score threshold, while the bottom 30% are assigned a low score threshold. Vehicles with scores above the high score threshold are classified as high-scoring vehicles, those below the low score threshold are classified as low-scoring vehicles, and those in between are classified as medium-scoring vehicles. Over time, the number of vehicles selected to provide honest service in the system increases, while the number of malicious vehicles decreases. Consequently, the overall score and trustworthiness in the system show an upward trend. This observation demonstrates the effectiveness of our mechanism in mitigating malicious nodes.

[0092] Taking into account the limitations of traditional network security models in dealing with modern complex threat environments with the development of technology, the concept of zero trust is introduced into the Internet of Vehicles environment to find a mechanism to promote vehicles to contribute computing resources and ensure the successful completion of tasks in a zero-trust Internet of Vehicles environment. With the help of the core concept of zero trust "dynamic authorization and continuous verification", a multi-attribute task offloading algorithm and a group-based continuous verification scheme are designed.

[0093] Specifically, the multi-attribute task offloading algorithm comprehensively considers multiple attributes of the task, such as the task's computing requirements, deadline, data size, and priority, and dynamically calculates and updates the vehicle's trust score in real time through the score management module. The score serves as an important basis for task allocation decisions. In the task allocation process, not only a single attribute is considered, but a weighted calculation of multiple attributes of the vehicle and task is integrated to ensure that the task can be assigned to the most suitable vehicle within the optimal time window, maximizing the success rate and efficiency of the task. Based on the group-based continuous verification scheme, the algorithm adopts a genetic mutation mechanism to select a group of vehicles that meet the requirements for task verification, thereby reducing the bottleneck problem of inaccurate verification results of a single vehicle, and also optimizing the completion delay of multiple vehicles performing task processing at the same time.

[0094] Another aspect of the present invention, as Figure 3 As shown, a blockchain-based zero-trust Internet of Vehicles collaborative computing system is provided, including:

[0095] Task offloading module: used for task offloading requesting the vehicle to send relevant task information and vehicle information to the nearest roadside unit.

[0096] Scoring management module: used by the roadside unit to read the scores of each service vehicle providing computing resources from the blockchain, and select the task execution vehicle based on the scores of each service vehicle providing computing resources and the multi-attribute task offloading algorithm.

[0097] Information management module: used for the task execution vehicle to establish a transaction with the task unloading request vehicle, and the transaction is recorded in the roadside unit; after the task is executed, the task execution vehicle transmits the calculation results to the task unloading request vehicle and the roadside unit.

[0098] Verification feedback module: used by the roadside unit to select a verification vehicle group to repeatedly calculate the execution task and obtain the calculation results; by comparing the calculation results of the task execution vehicle and the verification vehicle group, the correctness of the calculation results of the task execution vehicle is determined; the smart contract automatically executes payment or punishment based on the correctness of the calculation results of the task execution vehicle.

[0099] Exemplarily, the information management module is the foundation of all other modules. This module uses blockchain technology based on proof of stake (PoS) as a secure database to store transaction logs and vehicle information, providing information for the other three modules.

[0100] In another implementation of the present invention, it also includes a trust score management module, which calculates the trust value by using a method of estimating the trust value based on historical data. The obtained trust value participates in the decision-making process in the task unloading module as one of the attributes, and also participates in the verification process as one of the evaluation criteria for vehicle selection in the verification feedback module. The calculation method of the vehicle score in the trust score module is based on the mathematical idea of ​​the law of large numbers, combined with the priority of the task and the vehicle history for the successful completion rate of such priority tasks.

[0101] Blockchain is decentralized, tamper-proof, and traceable. By storing transaction information on the chain, payments and fines are automatically settled through smart contracts on the blockchain in RC transactions.

[0102] Smart contracts are self-executing contracts on the blockchain, where the terms of the agreement between different entities are embedded in a computer program. This ensures the automation and transparency of payment settlements, preventing situations where buyers refuse to pay or sellers misreport transaction amounts.

[0103] To assess the trustworthiness and timeliness of FVs, a trust score is introduced. A score management module calculates and updates vehicle scores, which are stored in the information management module. This module forms the foundation for the task offloading and verification feedback modules, as the scores serve as attributes and criteria for the task offloading algorithm and verification vehicle selection, respectively. Based on the score management and information management modules, the task offloading module dynamically determines whether a vehicle is authorized to perform a task using a multi-attribute task offloading algorithm. The verification feedback module is responsible for continuously verifying the correctness of task results, providing vehicle score feedback, and deterring potential malicious behavior.

[0104] In another aspect of the present invention, an electronic device includes a processor, a memory, a communication bus, and a communication interface.

[0105] in:

[0106] The processor, memory and communication interface communicate with each other through a communication bus.

[0107] Communication interface, used to communicate with other electronic devices or servers.

[0108] The processor is used to execute the program, and specifically can execute the steps of any one of the blockchain-based zero-trust vehicle network collaborative computing methods in the above embodiments.

[0109] Specifically, the program may include program codes including computer operation instructions.

[0110] The processor may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs; or different types of processors, such as one or more CPUs and one or more ASICs.

[0111] Memory is used to store programs. The memory may include high-speed RAM memory and may also include non-volatile memory (non-volatile memory), such as at least one disk storage.

[0112] The program can be specifically used to cause the processor to execute the steps to implement any of the blockchain-based zero-trust vehicle network collaborative computing methods described in the embodiments. The specific implementation of each step in the program can refer to the corresponding descriptions of the steps and units executed in any of the blockchain-based zero-trust vehicle network collaborative computing methods in the above steps, and will not be repeated here. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the devices and modules described above can refer to the corresponding process descriptions in the aforementioned method embodiments.

[0113] The exemplary embodiments of the present application further provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the methods of the various embodiments of the present application.

[0114] The method according to the embodiment of the present invention described above can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or as computer code that is originally stored in a remote recording medium or a non-temporary machine-readable medium downloaded via a network and will be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code, and when the software or computer code is accessed and executed by a computer, a processor or hardware, the method described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown here, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown here.

[0115] Thus far, specific embodiments of the present invention have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing may be advantageous.

[0116] It should be noted that all directional indications in the embodiments of the present invention (such as up, down, left, right, back, etc.) are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0117] In the description of the present invention, the terms "first" and "second" are used solely to facilitate description of different components or names and should not be construed as indicating or implying a sequential relationship, relative importance, or implicitly specifying the quantity of the technical features being described. Therefore, features specified as "first" or "second" may explicitly or implicitly include at least one of such features.

[0118] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0119] It should be noted that although the specific embodiments of the present invention are described in detail in conjunction with the accompanying drawings, this should not be construed as limiting the scope of protection of the present invention. Within the scope described by the claims, various modifications and variations that can be made by those skilled in the art without creative effort still fall within the scope of protection of the present invention.

[0120] The examples of the embodiments of the present invention are intended to briefly illustrate the technical features of the embodiments of the present invention so that those skilled in the art can intuitively understand the technical features of the embodiments of the present invention, and are not intended to improperly limit the embodiments of the present invention.

[0121] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A blockchain-based zero-trust vehicle networking collaborative computing method, characterized in that: include: The task offloading request vehicle sends relevant task information and vehicle information to the nearest roadside unit; The roadside unit reads the scores of each service vehicle providing computing resources from the blockchain, and selects a task execution vehicle based on the scores of each service vehicle providing computing resources and the multi-attribute task offloading algorithm; The task execution vehicle establishes a transaction with the task unloading request vehicle, and the transaction is recorded in the roadside unit; After the task is executed, the task execution vehicle transmits the calculation result to the task offloading request vehicle and the roadside unit; The roadside unit selects a verification vehicle group to perform repeated calculations on the execution task to obtain calculation results; By comparing the calculation results of the mission execution vehicle and the verification vehicle group, the correctness of the mission execution vehicle's calculation results is determined; Smart contracts automatically execute payments or penalties based on the correctness of the vehicle's calculation results when executing the task.

2. The method according to claim 1, characterized in that The multi-attribute task offloading algorithm comprehensively considers multiple attributes of a task, including the task's computational requirements, deadline, data size, and priority.

3. The method according to claim 1, characterized in that Also includes: When the accumulated transaction records in the roadside unit reach a preset threshold, the blockchain verification process is initiated, and other node operators verify the new block and add the new block to the blockchain after reaching a consensus.

4. The method according to claim 3, characterized in that The roadside unit reads the scores of each service vehicle providing computing resources from the blockchain, and selects a task execution vehicle based on the scores of each service vehicle providing computing resources and the multi-attribute task offloading algorithm, including: The roadside unit collects the willingness and vehicle information of computing resource vehicles within the distance threshold, evaluates the trust score of the service vehicle providing computing resources, and stores it in the blockchain; Based on the trust score, task attributes, and communication resource conditions, the task expectation of each pair of tasks and the service vehicle providing computing resources is calculated to obtain an expectation matrix, and the expectation matrix is ​​converted into a cost matrix; Based on the Hungarian algorithm, the cost matrix is ​​used to determine a task offloading solution that meets the maximum expectation; A task execution vehicle is selected according to the task offloading plan.

5. The method according to claim 1, wherein The roadside unit selects a verification vehicle group to perform repeated calculations on the execution task to obtain calculation results, including: The roadside unit selects a verification vehicle group based on a genetic algorithm; Initializing the verification vehicle group and calculating the fitness function of the verification vehicle group; Eliminate solutions whose fitness function is less than a preset threshold, and copy solutions whose fitness function is greater than the preset threshold; Perform cross and compile operations on the remaining solutions to obtain the calculation results.

6. The method according to claim 5, characterized in that The smart contract automatically executes payment or penalty based on the correctness of the calculation results of the task execution vehicle, including: If the calculation result of the task execution vehicle is consistent with the settlement result of the verification vehicle group, it means that the calculation result is correct, and the smart contract rewards the task execution vehicle that honestly completes the task; If the calculation result of the task execution vehicle does not match the settlement result of the verification vehicle group, it means that the calculation result is wrong, and the smart contract punishes the task execution vehicle that dishonestly completes the task.

7. The method according to claim 6, characterized in that Also includes: Based on the correctness of the calculation results of the task execution vehicle, the vehicle score is updated and written into the blockchain.

8. A blockchain-based zero-trust Internet of Vehicles collaborative computing system, characterized by: include: Task offloading module: used for the task offloading request vehicle to send relevant task information and vehicle information to the nearest roadside unit; Scoring management module: used for the roadside unit to read the scores of each service vehicle providing computing resources from the blockchain, and select a task execution vehicle based on the scores of each service vehicle providing computing resources and the multi-attribute task offloading algorithm; Information management module: used for the task execution vehicle to establish a transaction with the task unloading request vehicle, and the transaction is recorded in the roadside unit; After the task is executed, the task execution vehicle transmits the calculation result to the task offloading request vehicle and the roadside unit; Verification feedback module: used for the roadside unit to select a verification vehicle group to perform repeated calculations on the execution task to obtain calculation results; By comparing the calculation results of the mission execution vehicle and the verification vehicle group, the correctness of the mission execution vehicle's calculation results is determined; Smart contracts automatically execute payments or penalties based on the correctness of the vehicle's calculation results when executing the task.

Images