A blockchain-based vehicle task offloading method

Abstract

The application provides a vehicle task unloading method based on a blockchain technology. First, a task unloading model of Internet of Vehicles in the presence of malicious attacks is designed, the total task processing delay and the task unloading success rate of a task vehicle are considered, the task unloading optimization problem of the Internet of Vehicles system is formalized, the task unloading scene of the task vehicle is modeled as interacting with an intelligent agent, and a trust-aware deep deterministic policy gradient optimization method is designed by combining a blockchain system and a deep reinforcement learning algorithm to solve the optimization problem. Finally, simulation experiments are designed, and the experimental results of the method in terms of the total processing delay and the task unloading success rate of the task vehicle are analyzed. The results show that, compared with a traditional unloading method, the task processing efficiency is obviously improved, and the task unloading success rate is greatly improved.

Description

Technical Field

[0001] This invention relates to the fields of wireless communication networks and blockchain technology, specifically a blockchain-based method for unloading vehicle tasks. Background Technology

[0002] With the development of vehicle-to-everything (V2X) and intelligent driving technologies, modern vehicles are gradually equipped with functions such as autonomous driving, intelligent perception, and multimedia entertainment. During operation, they generate a large number of computing tasks with low latency and high reliability requirements. Since the vehicle's local computing resources are limited, it is difficult to complete all computing needs independently. Therefore, some tasks are usually offloaded to roadside units (RSUs) or edge servers for processing to reduce processing latency and alleviate local load pressure.

[0003] In real-world vehicle-to-everything (V2X) edge computing environments, due to the open and distributed nature of edge nodes, some roadside units may engage in malicious behaviors such as falsely reporting computing resources, delaying task execution, or returning false computation results. This can affect the reliability of task offloading and the security of system operation. Therefore, while ensuring the efficiency of task offloading, blockchain technology is used to assign a reputation value to each roadside unit for vehicle task offloading reference, thereby improving the credibility and security of the task offloading process and achieving a balance between security and efficiency in task offloading.

[0004] By simulating the task unloading process in the Internet of Vehicles, the task unloading process is abstracted into an interaction process between the intelligent agent and the environment. Deep reinforcement learning is used to make dynamic decisions based on observation information such as network status, task requirements and resource conditions. The unloading strategy is continuously optimized through reward feedback, thereby improving the overall performance of the system.

[0005] The present application is compared with the prior art as follows:

[0006] Technical comparison with application text CN113542376A "A task offloading method based on energy consumption and latency weighting";

[0007] 1. Application CN113542376A discloses a task offloading method based on energy consumption and latency weighting. The method first constructs a system model based on the communication between the task vehicle, collaborating vehicles, and roadside unit MEC servers, obtaining an objective function with latency and energy consumption weighted as the core. It then determines whether the task vehicle can complete the task locally within the maximum tolerable latency; if not, the task allocation decision problem is transformed into a Markov decision process. Finally, the DQN algorithm is used to solve the strategy selection problem to obtain the optimal offloading node (collaborating vehicle or MEC server). This invention releases the computing resources of idle collaborating vehicles on the road, effectively reduces task computation latency, alleviates the computational pressure on task vehicles and MEC servers, and solves the problem of heuristic algorithms easily getting trapped in local optima. The focus is on optimizing the weighted comprehensive cost of latency and energy consumption using a hybrid V2V and MEC offloading mode in a vehicle-to-everything (V2X) environment.

[0008] 2. The application proposes a blockchain-based vehicle task offloading method. The method first designs a vehicle-to-everything (V2X) task offloading model under malicious attack conditions, constructing a four-element system architecture including task vehicles, roadside units, base stations, and a blockchain; it establishes communication, computing, vehicle movement, and task offloading success rate models, formalizing the optimization problem as a dual-objective problem of minimizing total task processing latency and maximizing task offloading success rate; it designs a vehicle-road-chain collaborative trust framework of "off-chain decision-making + on-chain accounting / reputation," achieving roadside unit behavior notarization and dynamic reputation updates through a consortium blockchain; it models the base station as a reinforcement learning agent, employing a trust-aware deep deterministic policy gradient optimization algorithm (introducing a dual-critic network, delayed policy updates, and trust risk-priority experience replay), jointly outputting the offloading ratio, resource allocation, and trusted offloading node selection strategy. This invention effectively avoids attacks such as computing power false reporting and result fraud in scenarios with malicious roadside units, reducing total task processing latency and improving task offloading success rate. The focus is on achieving task offloading that balances security and efficiency in the context of malicious attacks on connected vehicles by combining blockchain trust mechanisms with improved reinforcement learning.

[0009] The two differ fundamentally in their optimization objectives, system architecture, algorithm design, and application scenarios.

[0010] Technical comparison with application text CN113687875A "A method and device for unloading vehicle tasks in a vehicle network";

[0011] 1. Application CN113687875A discloses a method for vehicle task offloading in the Internet of Vehicles (IoV). This method introduces mobile edge computing into the offloading scenario, establishing a traffic environment containing three types of computing nodes: macro base stations, roadside units, and idle vehicles. With the sole objective of reducing system latency, the offloading problem is modeled as a Markov decision process, and an offloading model is established using a Deep Recurrent Q-Learning (DRQN) algorithm incorporating Residual Networks (ResNet). Simultaneously, tasks are prioritized according to latency tolerance, with high-priority tasks processed first, and different computing nodes are matched based on task computation and latency thresholds. This invention effectively reduces IoV task processing latency through multi-type edge node collaboration and an improved reinforcement learning algorithm, meeting the requirements of low-latency applications. It focuses on latency-oriented multi-node collaborative task offloading in a trusted environment.

[0012] 2. The application proposes a blockchain-based vehicle task offloading method. The method first designs a vehicle-to-everything (V2X) task offloading model under malicious attack conditions, constructing a four-element system architecture including task vehicles, roadside units, base stations, and a blockchain; it establishes communication, computing, vehicle movement, and task offloading success rate models, formalizing the optimization problem as a dual-objective problem of minimizing total task processing latency and maximizing task offloading success rate; it designs a vehicle-road-chain collaborative trust framework of "off-chain decision-making + on-chain accounting / reputation," achieving roadside unit behavior notarization and dynamic reputation updates through a consortium blockchain; it models the base station as a reinforcement learning agent, employing a trust-aware deep deterministic policy gradient optimization algorithm (introducing a dual-critic network, delayed policy updates, and trust risk-priority experience replay), jointly outputting the offloading ratio, resource allocation, and trusted offloading node selection strategy. This invention effectively avoids attacks such as computing power false reporting and result fraud in scenarios with malicious roadside units, reducing total task processing latency and improving task offloading success rate. The focus is on achieving task offloading that balances security and efficiency in the context of malicious attacks on connected vehicles by combining blockchain trust mechanisms with improved reinforcement learning.

[0013] The two differ fundamentally in their optimization objectives, system architecture, algorithm design, application scenarios, and uninstallation decisions.

[0014] Technical comparison with application text CN114615265A "Method for Offloading Vehicle Tasks Based on Deep Reinforcement Learning in Edge Computing Environment";

[0015] 1. Application CN114615265A discloses a method for offloading vehicle-mounted tasks based on deep reinforcement learning in an edge computing environment. The method constructs a vehicle-to-everything (V2X) environment including vehicle terminals and roadside units based on queuing theory, calculates task upload latency, execution latency, and RSU (Roadside Unit) transfer latency; models the problem as a Markov decision process with the goal of minimizing the total task execution latency; and employs the MADDPG (Multi-Agent Programming) algorithm to construct a behavior-evaluation network to solve the problems of multi-region load balancing and uneven task distribution, thereby achieving vehicle-mounted task offloading. This invention improves the resource utilization and computational efficiency of the V2X system, focusing on latency optimization and load balancing under multi-region, multi-agent collaboration.

[0016] 2. The application proposes a blockchain-based vehicle task offloading method. The method first designs a vehicle-to-everything (V2X) task offloading model under malicious attack conditions, constructing a four-element system architecture including task vehicles, roadside units, base stations, and a blockchain; it establishes communication, computing, vehicle movement, and task offloading success rate models, formalizing the optimization problem as a dual-objective problem of minimizing total task processing latency and maximizing task offloading success rate; it designs a vehicle-road-chain collaborative trust framework of "off-chain decision-making + on-chain accounting / reputation," achieving roadside unit behavior notarization and dynamic reputation updates through a consortium blockchain; it models the base station as a reinforcement learning agent, employing a trust-aware deep deterministic policy gradient optimization algorithm (introducing a dual-critic network, delayed policy updates, and trust risk-priority experience replay), jointly outputting the offloading ratio, resource allocation, and trusted offloading node selection strategy. This invention effectively avoids attacks such as computing power false reporting and result fraud in scenarios with malicious roadside units, reducing total task processing latency and improving task offloading success rate. The focus is on achieving task offloading that balances security and efficiency in the context of malicious attacks on connected vehicles by combining blockchain trust mechanisms with improved reinforcement learning.

[0017] The two differ fundamentally in their optimization objectives, system architecture, algorithm design, and application scenarios. Summary of the Invention

[0018] This invention proposes a blockchain-based vehicle task offloading optimization method. In the dynamic environment of the Internet of Vehicles, it comprehensively considers various factors such as task processing latency, edge node credibility, and blockchain consensus overhead. By introducing a consortium blockchain reputation mechanism to manage the service behavior of edge nodes in a trustworthy manner, and combining a deep reinforcement learning algorithm to achieve joint optimization decision-making on the task offloading ratio and offloading nodes, the total task processing latency is reduced, the task offloading success rate is improved, the security and reliability of the system are enhanced, and the computational load pressure on the vehicle terminal is reduced.

[0019] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0020] A blockchain-based method for optimizing vehicle task unloading includes the following specific steps:

[0021] Step 1: Considering vehicle movement scenarios under malicious attacks, design a system model for a vehicle task safe offloading framework;

[0022] Step 2: The task vehicle generates latency-sensitive intensive computing tasks. Design communication models, computing models, vehicle movement models, and task unloading success rate models, and then construct a problem model for safe unloading of vehicle tasks.

[0023] Step 3: Based on the problem model, design the objective optimization function to optimize the total task processing delay and task unloading success rate;

[0024] Step 4: Based on the system model and blockchain technology, design a vehicle-road-chain collaborative trust framework;

[0025] Step 5: Based on the system model and reinforcement learning algorithm, design the base station agent interaction environment;

[0026] Step 6: Design an improved deep deterministic policy gradient optimization algorithm, train the agent, and then determine the unloading target.

[0027] As a further improvement of the present invention, in step 1, the system model of the vehicle task unloading framework is divided into four parts: task vehicle, roadside unit, base station, and blockchain.

[0028] In step 1, in a vehicle-to-everything (V2X) environment with malicious attacks, considering the dynamic movement of the task vehicle, it must complete its computational tasks within the effective coverage area of ​​the roadside unit. When the task vehicle's own computing resources are insufficient to fully process the task, it needs to offload some task data to the roadside unit to meet the task's computational requirements. Furthermore, considering attackers intruding into the roadside unit and maliciously interfering with the task offloading process, blockchain technology is introduced to ensure the secure offloading and processing of computational tasks. The base station, blockchain, roadside unit, and task vehicle are defined as follows:

[0029] (1) Base station:

[0030] The base station assumes the roles of centralized decision-making and coordination, candidate roadside unit generation, recalculation / audit triggering, and reinforcement learning agent; simultaneously, as a consortium blockchain node, the base station participates in on-chain ledger and practical Byzantine fault-tolerant consensus. The base station's service range covers all vehicles within the model, and all unloading processes are completed within the base station's service range.

[0031] (2) Blockchain:

[0032] The blockchain employs a consortium blockchain architecture to immutably record critical evidence and uses smart contracts to punish malicious behavior and maintain reputation, thus providing a foundation of trust and a traceable flow of evidence for off-chain decision-making. Practical Byzantine fault-tolerant consensus is used to ensure the feasibility and efficiency of on-chain confirmation in a consortium environment.

[0033] (3) Roadside unit

[0034] Roadside units, acting as edge servers, possess corresponding computing resources and can provide offloading services for computationally intensive tasks. They also submit crucial evidence of task execution to the base station and participate in on-chain reputation and consensus mechanisms. However, the service ranges of roadside units are not adjacent, and some roadside units are malicious, having been compromised by hackers. These malicious units can hinder vehicle task processing. The set of roadside units is defined as follows: The number of roadside units is defined as follows: .

[0035] (4) Mission vehicles

[0036] Task vehicles are used to generate computational tasks locally. Each computational task generated by a task vehicle consists of multiple sub-tasks. When the local computing resources of the task vehicle cannot meet the processing requirements, some sub-tasks of the corresponding task are offloaded to roadside units. The appropriate offloading target is selected based on the delay requirements and other constraints of the tasks to be offloaded. The set of task vehicles is defined as follows: The number of vehicles is defined as Define the mission vehicle in each time slot. Each will generate its own computational task. , To designate the mission vehicle, For the corresponding task, task By triplet composition, This indicates the number of CPU cycles required to complete the task. This indicates the size of the data for the task. This indicates the maximum tolerable delay in completing the task.

[0037] When a task vehicle reaches the service area of ​​a roadside unit, it needs to complete unloading within the coverage area of ​​that roadside unit, and the unloading time must be completed within the maximum tolerable time of the task. Considering the scenario of partial unloading of the task—that is, part of the task is completed locally on the vehicle and part is unloaded to the roadside unit—for the vehicle... Task Define the task unloading ratio as ,in This indicates the proportion of tasks that are unloaded to the roadside unit for processing. This indicates the proportion of tasks processed locally on the vehicle. For tasks... The partial tasks unloaded to the roadside unit for processing are defined as follows: The partial tasks defined for processing locally on the vehicle are represented as .

[0038] As a further improvement to the present invention, the communication model designed in step 2 is as follows:

[0039] A free-space path loss model is used to describe the process of vehicle task offloading to the edge server. Ignoring downlink transmission delay, it is assumed that orthogonal frequency division multiple access (OFDMA) is used to reduce interference for different vehicle users, and that the roadside units have sufficient bandwidth, with the same bandwidth allocated to each task vehicle, denoted as W. First, the signal-to-noise ratio (SNR) of the uplink transmission channel from task vehicle i to roadside unit j can be obtained as follows: ,in, Indicates the vehicle's task transmission power. This indicates the channel gain between the mission vehicle and the RSU. This represents the additive white Gaussian noise power. Since the vehicle's mission transmission power cannot exceed the vehicle's maximum transmit power, the maximum transmit power of the vehicle is defined as follows. Ignoring channel interference between moving vehicles, according to Shannon's formula, the uplink transmission rate of vehicle i offloading its task to roadside unit j is: Therefore, neglecting the rate loss in data transmission, the uplink data transmission delay from vehicle i to roadside unit j can be expressed as:

[0040] As a further improvement to the present invention, the calculation model designed in step 2 is as follows:

[0041] (1) Local processing:

[0042] First, define the total local computing resources owned by task vehicle i as follows: The amount of computing resources required by the task vehicle to process the local portion of the task is expressed as: Therefore, the completion time of the computation task executed locally can be expressed as:

[0043] (2) Roadside unit treatment:

[0044] Similar to the mission vehicle, the roadside unit itself also has a fixed maximum available computing resources, represented as The amount of computational resources allocated to the task unloaded from vehicle i to the current roadside unit is expressed as: Therefore, the completion time of the task executed in the roadside unit can be expressed as:

[0045] As a further improvement to the present invention, the vehicle movement model designed in step 2 is as follows:

[0046] First, define the position of vehicle i in time slot t as... The location of roadside unit j is The service coverage radius of the roadside unit is r, and the vehicle speed is defined as r. Since the mission vehicle and the roadside unit are not on the same straight line, the motion direction and vector of the mission vehicle are defined. The included angle is Based on this, the link time between task vehicle i and roadside unit j is given, and further discussion is given depending on whether the task vehicle has entered the service range of the roadside unit processing its task at this time:

[0047] (1) The mission vehicle is already within the service area of ​​the roadside unit:

[0048] when At this time, it indicates that the task vehicle has entered the service area of ​​the current roadside unit. The link time between task vehicle i and roadside unit j is expressed as:

[0049] in , Ensure that the processing time of a task in the roadside unit does not exceed the dwell time of the vehicle within the service area of ​​the roadside unit.

[0050] (2) The task vehicle has not yet entered the service area of ​​the roadside unit:

[0051] when At this time, the mission vehicle had not yet entered the service area of ​​the roadside unit. The link time between task vehicle i and roadside unit j is expressed as:

[0052] in It is the perpendicular distance from the vehicle trajectory to the center of the roadside unit circle. Ensure that the processing time of a task in the roadside unit does not exceed the dwell time of the vehicle within the service area of ​​the roadside unit.

[0053] As a further improvement to the present invention, the task unloading success rate model in step 2 is as follows:

[0054] The unloading success rate of a computational task is defined as R, where R = the number of successfully unloaded tasks / the total number of unloading requests from the task vehicles. For a task generated by a task vehicle, it is considered successfully unloaded when the following constraints are met:

[0055] (1) When a task is processed in a roadside unit, the total delay of task i is no more than the maximum link time between the task vehicle and roadside unit j, i.e. .

[0056] (2) The total delay of the task being processed in the roadside unit shall not exceed the maximum tolerable delay of the task, i.e.: .

[0057] Based on this, whether the task was successfully uninstalled is represented as Therefore, the task uninstallation success rate R can be expressed as:

[0058] As a further improvement of the present invention, in step 3, based on the problem model, an objective optimization function is designed to obtain the total task processing delay. Since the task is processed in parallel, that is, the task is processed simultaneously in the local and roadside units, the total task processing delay is the maximum value processed in the local and roadside units. Based on the above model, the task unloading problem is formalized into the following optimization problem:

[0059]

[0060]

[0061]

[0062]

[0063]

[0064]

[0065]

[0066]

[0067]

[0068]

[0069]

[0070]

[0071] in R represents the total processing delay for task vehicle i to complete its task in the current time slot t, and R represents the task unloading success rate of task vehicle i.

[0072] Constraint 1 states that the transmission power of a vehicle task cannot exceed the vehicle's maximum transmission power. Constraints 2 and 3 state that the computing resources allocated to a task vehicle for processing local tasks cannot exceed the total computing resources owned by the task vehicle, and the computing resources allocated to a roadside unit for processing tasks by task vehicle i cannot exceed the total computing resources owned by the roadside unit, respectively. Constraints 4 and 5 state the conditions for a vehicle entering the service range of a roadside unit and for a vehicle not entering the service range of a roadside unit, respectively. Constraints 6 and 7 state the two conditions for a vehicle task to be successfully unloaded. Constraint 8 states whether task i is unloaded to roadside unit j. Constraint 9 states the task allocation ratio for each task generated by a task vehicle. Constraint 10 states that the processing delay of a task in the local and roadside units cannot exceed the maximum tolerable delay of the task, ensuring successful task completion.

[0073] As a further improvement to this invention, in step 4, based on the system model and blockchain technology, a vehicle-road-chain collaborative trust framework is designed. To simultaneously meet the goals of minimizing latency and filtering malicious nodes, a collaborative architecture of "off-chain decision-making + on-chain accounting / reputation" is adopted, consisting of an off-chain reinforcement learning layer and an on-chain consortium blockchain layer. In the off-chain reinforcement learning layer, the base station runs a deep deterministic policy gradient optimization algorithm based on the observed state at each time slot t, and jointly outputs the unloading ratio and the selection of unloading nodes based on the final optimization result, thereby minimizing the total task processing latency T. In the on-chain consortium blockchain layer, the base station and roadside units act as consortium blockchain nodes, and the vehicle acts as a light node. On-chain behavior is recorded through smart contracts, and all occurring behaviors are consistent with the blockchain-related steps in the computational unloading process, namely: the roadside unit publishes the computational resources and the latency required to process the current task; the roadside unit returns a hash value; the vehicle and base station evaluate the service; and the roadside unit's reputation value is updated. In addition, to ensure that the overall process latency of writing data to the blockchain and confirming it is controllable, a practical Byzantine fault-tolerant consensus mechanism is used, and the latency overhead generated by this consensus mechanism is defined as... .

[0074] For malicious nodes in the uninstallation scenario, their malicious behavior is modeled. Since only latency optimization is considered, the behavior of malicious service nodes is divided into two categories:

[0075] (1) False reporting of computing power:

[0076] Roadside unit j declares its available computing power and the computing power allocated to task vehicle i to the base station and vehicles, respectively. and However, the actual computing power owned and allocated is even lower. This results in a higher computational latency for tasks executed on this roadside unit. This will significantly increase the computational latency. In this case, although the computational latency increases, it does not exceed the maximum tolerable latency required by the task. Although the task is successfully processed, the roadside unit has breached its service commitment, and the task is still considered a failure.

[0077] (2) Fraudulent results:

[0078] In this scenario, the processing delay of the task from roadside unit j to vehicle i exceeds the maximum tolerable delay for that task, or the roadside unit fails to process the task, resulting in task processing failure. However, the roadside unit fakes the task's successful completion and returns a false processing result. .

[0079] To ensure that malicious behavior by roadside units is verifiable and accountable, a minimum necessary on-chain evidence is designed. Once a roadside unit completes its computation task, it uploads the result hash to the blockchain. ,in This represents the hash value generated by roadside unit j. This represents the result after roadside unit j has processed task i. When the task vehicle receives the result, since it lacks verification capabilities, it uploads the result to the base station, which then recalculates and uploads it to the blockchain. ,in This represents the hash value of the result after the task vehicle sends it to the base station for recalculation. This indicates the result received by task vehicle i from roadside unit j. This includes the task number, time slot, roadside unit identifier, and task execution time. Since tasks offloaded to roadside units may fail to complete, and the task vehicle cannot reprocess this part of the task, a probabilistic auditing mechanism is introduced: the base station uses probability... The unloaded tasks are recalculated or sampled for verification to obtain a consistency indicator:

[0080]

[0081] When the audit fails, i.e. At that time, the smart contract can deduct the reputation value of the current roadside unit.

[0082] To ensure that reputation scores directly serve the goal of "latency minimization," a single service quality score is defined as follows: ,in The first term on the left side of the formula This represents a sensitivity coefficient for delay penalties; the larger the coefficient, the more sensitive the task is to timeouts. (The second item...) The sensitivity coefficient for resource honesty penalty. Describe a very small constant ( ),prevent This refers to situations where calculation is not possible. For the reliable terms on the right-hand side of the formula, the following definition applies:

[0083]

[0084] This means mapping the "audit result" to a 0-1 confidence weight, and applying a conservative discount when an audit is not triggered. This is to encourage the system to trigger audits in critical scenarios.

[0085] The global reputation value of roadside unit j is updated using exponential sliding: ,in This represents the average score of all task vehicles that interact with roadside unit j within time slot t. Used to control the "historical / recent" weights. It is maintained by smart contracts and is queryable for task vehicles. It can also be used for training and optimization of deep deterministic strategy gradient optimization algorithms with off-chain trust awareness.

[0086] To directly exclude obviously malicious roadside units from the decision space, the base station generates a candidate set based on a reputation threshold: ,in This represents the minimum reputation threshold at which a roadside unit can be trusted. The base station will also feed this candidate set back to the task vehicle after generating it.

[0087] As a further improvement of the present invention, in step 5, a trust-aware deep deterministic policy gradient optimization algorithm is used, and a dual Critic network, target policy smoothing and delayed policy update mechanism are introduced to reduce the Q-value overestimation problem and improve training stability.

[0088] The base station is treated as a reinforcement learning agent, which selects an unloading action based on the observed state in each time slot t and obtains a corresponding reward. This optimizes the processing efficiency of vehicle tasks in unloading scenarios with malicious nodes. The Markov decision process is represented by a quadruple (S, A, R, P), where S is the state space, A is the action space, R is the reward function, and P is the state transition probability.

[0089] State Space: Centralized decision-making is adopted, with the base station acting as a single agent, defining the state in each time slot based on global observations. , in For task-related parameters, This represents the state of the remaining computing resources for the task vehicle and roadside units. This indicates the reputation value of the roadside unit at this time. It stores the movement characteristics of the mission vehicle at this moment (specific location and other information). In addition, for have .

[0090] Action space: The action space is represented as: ,in This represents the soft weight of the roadside unit. And it satisfies: Based on this selection weight, the mission vehicle will be selected from the trusted roadside unit candidate set. Ultimately, the roadside unit with the highest weight is selected, i.e.: Then The proportional calculation task is offloaded to the finally selected roadside unit. Processing is required. To strictly meet... In addition to the interval constraints of computational resources and available power, a differentiable projection is applied to the original output of the action space: , ,in (⋅) is the Sigmoid function, which naturally maps any real number to (0,1), thus guaranteeing that no additional pruning is needed. , , The feasibility of this study is demonstrated, and the network training remains differentiable.

[0091] Reward function: The reward value is designed to be a negative of the task processing latency, while incorporating trust risk and on-chain confirmation overhead. ,in The on-chain reputation value for the finally selected roadside unit. This is an indicator function that indicates if the task times out (i.e., ...). ),but This will result in an additional delay penalty. ,on the contrary There is no penalty for this item. This refers to the previously defined blockchain overhead. , and These are the weight parameters for trust risk penalty, timeout default penalty, and blockchain overhead, respectively, and they satisfy the following conditions: These three weights can be allocated according to specific needs.

[0092] As a further improvement to the present invention, in step 6, a trust-aware deep deterministic policy gradient optimization algorithm is designed, and two critic networks are constructed: The value of the same action is estimated using a value function with independent parameters. The aim is to suppress Q-value overestimation, which is prone to occur with a single critic, thereby improving training stability. The formula for calculating the "true" Q-value, compared to the Q-value obtained from the action network, is defined as follows: The method introduces Bellman recursion to teach the critic network to estimate the Q-value. Since two critic networks are used to calculate the value for the next step, the smaller one is taken as the objective. Indicates an immediate reward. Represents the discount factor and , This represents target action noise (truncated Gaussian noise). The loss function during critic network training is defined as: The mean squared error is used as the loss function during the training of the critic network. For the actor network, the goal is to maximize... In other words, it selects the action that brings greater long-term returns in the current state. Therefore, the update mechanism of the actor network is defined as: .

[0093] Delayed update strategy: The critic network is updated multiple times, while the actor network is updated with a delay, specifically every two steps. This makes the Q-value update more stable. In addition, soft parameter updates are used to prevent Q-value divergence, allowing the algorithm to update slowly and gradually obtain the optimal solution.

[0094] Trust risk-prioritized experience replay: Malicious samples from malicious roadside units are typically sparse but extremely critical. If replayed completely uniformly, the strategy may not learn how to avoid malicious nodes for a considerable period. Therefore, trust risk-prioritized replay is introduced to improve the experience... Define a priority ,in This represents the timing difference error. It is a constant to prevent extremely small values ​​with a priority of 0. Used to control priority intensity. This indicates an amplification of trust risk. It is used to control the extent to which risks are amplified.

[0095] As a further improvement of the present invention, in step 6, the intelligent agent interaction environment is trained, and the training process is as follows:

[0096] In step 6, the interactive environment of the intelligent agent is trained. The training process is as follows: First, the input data and environmental parameters required for the trust perception task offloading training are initialized, including: the computing tasks generated by the vehicle in time slot t within the base station coverage area, the set of roadside units participating in collaborative computing and their edge server resource status, and the continuous time is discretized into multiple time slots to form an interactive training environment; in each time slot, the task vehicle publishes the task requirement to the base station, the base station filters the available roadside units based on roadside unit resources and load and returns a candidate list, the vehicle offloads the task to the target roadside unit for execution, the roadside unit returns the result and execution information and submits the evaluation, available resources / time and task hash value to the base station, the vehicle submits the evaluation of the roadside unit to the base station, and finally the base station summarizes, verifies and updates the evaluation and writes it into the consortium blockchain to update the reputation value of the roadside unit. Second, the base station is regarded as a single intelligent agent, and in each time slot, based on the global observation state... Choose an uninstall action and receive a reward to optimize uninstallation efficiency; the state It consists of task-related parameters, the remaining computing resource status of the vehicle and roadside units, the reputation value of the roadside units, and vehicle movement characteristics. Then, the Actor policy network is initialized to output unloading actions, and the Critic value network is initialized to evaluate the value of the actions. Next, the current state is obtained at each time slot t. Then, the Actor outputs a hybrid action: for discrete selection of roadside units, it first outputs a continuously relaxed correlation weight vector that satisfies normalization constraints, and then selects the one with the largest weight from the set of credible roadside unit candidates as the final unloading roadside unit; for continuous decision variables, it applies a differentiable projection to the Actor's original output to strictly satisfy interval constraints and maintain differentiability, thereby obtaining the executable action. Then the action is performed. Complete the task processing for this time slot and calculate the instant reward. Observe the new state after execution. The interactive quadruple (S(t), A(t), R(t), S(t+1)) is stored in the experience replay buffer D for subsequent offline sampling updates. Trust risk-priority experience replay is adopted to accelerate the model's learning of the pattern that "low reputation leads to bad results," and then the Critic network is updated. Simultaneously, truncated Gaussian noise is added to the target action as target action noise, and the mean squared error is used as the Critic loss function. Perform backpropagation updates. Next, update the Actor network by using the deterministic policy gradient to propagate the gradient of the "Q-pair action" back to the Actor parameters to update them. Finally, soft parameter updates are performed on the target network, allowing the target Actor and Critic to smoothly follow the changes in the main network with smaller step sizes, preventing Q-value divergence during training and gradually converging to the optimal policy.

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

[0098] In the context of vehicle-to-everything (V2X) task offloading, this invention introduces consortium blockchains and smart contracts to reliably store and dynamically update the reputation value of roadside unit calculation processes and evaluation information. Combined with a trust-aware deep reinforcement learning agent, it adaptively generates an "offloading ratio + offloading target" strategy, thereby effectively avoiding malicious roadside units and ensuring traceability of offloading results. This reduces the total task execution latency and improves the security and overall efficiency of task offloading. Attached Figure Description

[0099] Figure 1 This is a model diagram of the unloading system of the present invention.

[0100] Figure 2 This is a diagram of the algorithm framework of the present invention.

[0101] Figure 3 This is a flowchart of the algorithm of the present invention. Detailed Implementation

[0102] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0103] This example provides a blockchain-based method for unloading vehicle tasks, including the following steps:

[0104] In step 1, the system model of the vehicle task unloading framework is as follows: Figure 1 The system is divided into four parts: mission vehicle, roadside unit, base station, and blockchain.

[0105] In step 1, in a vehicle-to-everything (V2X) environment with malicious attacks, considering the dynamic movement of the task vehicle, it must complete its computational tasks within the effective coverage area of ​​the roadside unit. When the task vehicle's own computing resources are insufficient to fully process the task, it needs to offload some task data to the roadside unit to meet the task's computational requirements. Furthermore, considering attackers intruding into the roadside unit and maliciously interfering with the task offloading process, blockchain technology is introduced to ensure the secure offloading and processing of computational tasks. The base station, blockchain, roadside unit, and task vehicle are defined as follows:

[0106] (1) Base station:

[0107] The base station assumes the roles of centralized decision-making and coordination, candidate roadside unit generation, recalculation / audit triggering, and reinforcement learning agent; simultaneously, as a consortium blockchain node, the base station participates in on-chain ledger and practical Byzantine fault-tolerant consensus. The base station's service range covers all vehicles within the model, and all unloading processes are completed within the base station's service range.

[0108] (2) Blockchain:

[0109] The blockchain employs a consortium blockchain architecture to immutably record critical evidence and uses smart contracts to punish malicious behavior and maintain reputation, thus providing a foundation of trust and a traceable flow of evidence for off-chain decision-making. Practical Byzantine fault-tolerant consensus is used to ensure the feasibility and efficiency of on-chain confirmation in a consortium environment.

[0110] (3) Roadside unit

[0111] Roadside units, acting as edge servers, possess corresponding computing resources and can provide offloading services for computationally intensive tasks. They also submit crucial evidence of task execution to the base station and participate in on-chain reputation and consensus mechanisms. However, the service ranges of roadside units are not adjacent, and some roadside units are malicious, having been compromised by hackers. These malicious units can hinder vehicle task processing. The set of roadside units is defined as follows: The number of roadside units is defined as follows: .

[0112] (4) Mission vehicles

[0113] Task vehicles are used to generate computational tasks locally. Each computational task generated by a task vehicle consists of multiple sub-tasks. When the local computing resources of the task vehicle cannot meet the processing requirements, some sub-tasks of the corresponding task are offloaded to roadside units. The appropriate offloading target is selected based on the delay requirements and other constraints of the tasks to be offloaded. The set of task vehicles is defined as follows: The number of vehicles is defined as Define the mission vehicle in each time slot. Each will generate its own computational task. , To designate the mission vehicle, For the corresponding task, task By triplet composition, This indicates the number of CPU cycles required to complete the task. This indicates the size of the data for the task. This indicates the maximum tolerable delay in completing the task.

[0114] When a task vehicle reaches the service area of ​​a roadside unit, it needs to complete unloading within the coverage area of ​​that roadside unit, and the unloading time must be completed within the maximum tolerable time of the task. Considering the scenario of partial unloading of the task—that is, part of the task is completed locally on the vehicle and part is unloaded to the roadside unit—for the vehicle... Task Define the task unloading ratio as ,in This indicates the proportion of tasks that are unloaded to the roadside unit for processing. This indicates the proportion of tasks processed locally on the vehicle. For tasks... The partial tasks unloaded to the roadside unit for processing are defined as follows: The partial tasks defined for processing locally on the vehicle are represented as .

[0115] The communication model designed in step 2 is as follows:

[0116] A free-space path loss model is used to describe the process of vehicle task offloading to the edge server. Ignoring downlink transmission delay, it is assumed that orthogonal frequency division multiple access (OFDMA) is used to reduce interference for different vehicle users, and that the roadside units have sufficient bandwidth, with the same bandwidth allocated to each task vehicle, denoted as W. First, the signal-to-noise ratio (SNR) of the uplink transmission channel from task vehicle i to roadside unit j can be obtained as follows: ,in, Indicates the vehicle's task transmission power. This indicates the channel gain between the mission vehicle and the RSU. This represents the additive white Gaussian noise power. Since the vehicle's mission transmission power cannot exceed the vehicle's maximum transmit power, the maximum transmit power of the vehicle is defined as follows. Ignoring channel interference between moving vehicles, according to Shannon's formula, the uplink transmission rate of vehicle i offloading its task to roadside unit j is: Therefore, neglecting the rate loss in data transmission, the uplink data transmission delay from vehicle i to roadside unit j can be expressed as:

[0117] The calculation model designed in step 2 is as follows:

[0118] (1) Local processing:

[0119] First, define the total local computing resources owned by task vehicle i as follows: The amount of computing resources required by the task vehicle to process the local portion of the task is expressed as: Therefore, the completion time of the computation task executed locally can be expressed as:

[0120] (2) Roadside unit treatment:

[0121] Similar to the mission vehicle, the roadside unit itself also has a fixed maximum available computing resources, represented as The amount of computational resources allocated to the task unloaded from vehicle i to the current roadside unit is expressed as: Therefore, the completion time of the task executed in the roadside unit can be expressed as:

[0122] The vehicle movement model is designed in step 2 as follows:

[0123] First, define the position of vehicle i in time slot t as... The location of roadside unit j is The service coverage radius of the roadside unit is r, and the vehicle speed is defined as r. Since the mission vehicle and the roadside unit are not on the same straight line, the motion direction and vector of the mission vehicle are defined. The included angle is Based on this, the link time between task vehicle i and roadside unit j is given, and further discussion is given depending on whether the task vehicle has entered the service range of the roadside unit processing its task at this time:

[0124] (1) The mission vehicle is already within the service area of ​​the roadside unit:

[0125] when At this time, it indicates that the task vehicle has entered the service area of ​​the current roadside unit. The link time between task vehicle i and roadside unit j is expressed as:

[0126] in , Ensure that the processing time of a task in the roadside unit does not exceed the dwell time of the vehicle within the service area of ​​the roadside unit.

[0127] (2) The task vehicle has not yet entered the service area of ​​the roadside unit:

[0128] when At this time, the mission vehicle had not yet entered the service area of ​​the roadside unit. The link time between task vehicle i and roadside unit j is expressed as:

[0129] in It is the perpendicular distance from the vehicle trajectory to the center of the roadside unit circle. Ensure that the processing time of a task in the roadside unit does not exceed the dwell time of the vehicle within the service area of ​​the roadside unit.

[0130] The task uninstallation success rate model in step 2 is as follows:

[0131] The unloading success rate of a computational task is defined as R, where R = the number of successfully unloaded tasks / the total number of unloading requests from the task vehicles. For a task generated by a task vehicle, it is considered successfully unloaded when the following constraints are met:

[0132] (1) When a task is processed in a roadside unit, the total delay of task i is no more than the maximum link time between the task vehicle and roadside unit j, i.e. .

[0133] (2) The total delay of the task being processed in the roadside unit shall not exceed the maximum tolerable delay of the task, i.e.: .

[0134] Based on this, whether the task was successfully uninstalled is represented as Therefore, the task uninstallation success rate R can be expressed as:

[0135] In step 3, based on the problem model, an objective optimization function is designed to obtain the total task processing delay. Since the task is processed in parallel, meaning it is processed simultaneously in the local and roadside units, the total task processing delay is the maximum value processed in both the local and roadside units. Based on the above model, the task unloading problem is formalized into the following optimization problem:

[0136]

[0137]

[0138]

[0139]

[0140]

[0141]

[0142]

[0143]

[0144]

[0145]

[0146]

[0147]

[0148] in R represents the total processing delay for task vehicle i to complete its task in the current time slot t, and R represents the task unloading success rate of task vehicle i.

[0149] Constraint 1 states that the transmission power of a vehicle task cannot exceed the vehicle's maximum transmission power. Constraints 2 and 3 state that the computing resources allocated to a task vehicle for processing local tasks cannot exceed the total computing resources owned by the task vehicle, and the computing resources allocated to a roadside unit for processing tasks by task vehicle i cannot exceed the total computing resources owned by the roadside unit, respectively. Constraints 4 and 5 state the conditions for a vehicle entering the service range of a roadside unit and for a vehicle not entering the service range of a roadside unit, respectively. Constraints 6 and 7 state the two conditions for a vehicle task to be successfully unloaded. Constraint 8 states whether task i is unloaded to roadside unit j. Constraint 9 states the task allocation ratio for each task generated by a task vehicle. Constraint 10 states that the processing delay of a task in the local and roadside units cannot exceed the maximum tolerable delay of the task, ensuring successful task completion.

[0150] In step 4, based on the system model and blockchain technology, the following was designed: Figure 2 The vehicle-road-chain collaborative trust framework, as shown, adopts a collaborative architecture of "off-chain decision-making + on-chain accounting / reputation" to simultaneously meet the goals of minimizing latency and filtering malicious nodes. This architecture consists of an off-chain reinforcement learning layer and an on-chain consortium blockchain layer. In the off-chain reinforcement learning layer, the base station runs a deep deterministic policy gradient optimization algorithm based on the observed state at each time slot t. Based on the final optimization result, it jointly outputs the offloading ratio and the selection of offloading nodes to minimize the total task processing latency T. In the on-chain consortium blockchain layer, the base station and roadside units act as consortium blockchain nodes, and the vehicle acts as a light node. On-chain behavior is recorded through smart contracts. All actions are consistent with the blockchain-related steps in the computational offloading process: the roadside unit publishes computing resources and the latency required to process the current task; the roadside unit returns a hash value; the vehicle and base station evaluate the service; and the roadside unit's reputation value is updated. Furthermore, to ensure that the overall process latency of writing data to the blockchain and confirming it is controllable, a practical Byzantine fault-tolerant consensus mechanism is used. The latency overhead generated by this consensus mechanism is defined as... For malicious nodes in the uninstallation scenario, their malicious behavior is modeled. Since only latency optimization is considered, the behavior of malicious service nodes is divided into two categories:

[0151] (1) False reporting of computing power:

[0152] Roadside unit j declares its available computing power and the computing power allocated to task vehicle i to the base station and vehicles, respectively. and However, the actual computing power owned and allocated is even lower. This results in a higher computational latency for tasks executed on this roadside unit. This will significantly increase the computational latency. In this case, although the computational latency increases, it does not exceed the maximum tolerable latency required by the task. Although the task is successfully processed, the roadside unit has breached its service commitment, and the task is still considered a failure.

[0153] (2) Fraudulent results:

[0154] In this scenario, the processing delay of the task from roadside unit j to vehicle i exceeds the maximum tolerable delay for that task, or the roadside unit fails to process the task, resulting in task processing failure. However, the roadside unit fakes the task's successful completion and returns a false processing result. .

[0155] To ensure that malicious behavior by roadside units is verifiable and accountable, a minimum necessary on-chain evidence is designed. Once a roadside unit completes its computation task, it uploads the result hash to the blockchain. ,in This represents the hash value generated by roadside unit j. This represents the result after roadside unit j has processed task i. When the task vehicle receives the result, since it lacks verification capabilities, it uploads the result to the base station, which then recalculates and uploads it to the blockchain. ,in This represents the hash value of the result after the task vehicle sends it to the base station for recalculation. This indicates the result received by task vehicle i from roadside unit j. This includes the task number, time slot, roadside unit identifier, and task execution time. Since tasks offloaded to roadside units may fail to complete, and the task vehicle cannot reprocess this part of the task, a probabilistic auditing mechanism is introduced: the base station uses probability... The unloaded tasks are recalculated or sampled for verification to obtain a consistency indicator:

[0156]

[0157] When the audit fails, i.e. At that time, the smart contract can deduct the reputation value of the current roadside unit.

[0158] To ensure that reputation scores directly serve the goal of "latency minimization," a single service quality score is defined as follows: ,in The first term on the left side of the formula This represents a sensitivity coefficient for delay penalties; the larger the coefficient, the more sensitive the task is to timeouts. (The second item...) The sensitivity coefficient for resource honesty penalty. Describe a very small constant ( ),prevent This refers to situations where calculation is not possible. For the reliable terms on the right-hand side of the formula, the following definition applies:

[0159]

[0160] This means mapping the "audit result" to a 0-1 confidence weight, and applying a conservative discount when an audit is not triggered. This is to encourage the system to trigger audits in critical scenarios.

[0161] The global reputation value of roadside unit j is updated using exponential sliding: ,in This represents the average score of all task vehicles that interact with roadside unit j within time slot t. Used to control the "historical / recent" weights. It is maintained by smart contracts and is queryable for task vehicles. It can also be used for training and optimization of deep deterministic strategy gradient optimization algorithms with off-chain trust awareness.

[0162] To directly exclude obviously malicious roadside units from the decision space, the base station generates a candidate set based on a reputation threshold: ,in This represents the minimum reputation threshold at which a roadside unit can be trusted. The base station will also feed this candidate set back to the task vehicle after generating it.

[0163] In step 5, a trust-aware deep deterministic policy gradient optimization algorithm is used, and a dual Critic network, target policy smoothing and delayed policy update mechanism are introduced to reduce the Q-value overestimation problem and improve training stability.

[0164] The base station can be viewed as a reinforcement learning agent that selects an unloading action based on the observed state in each time slot t and receives a corresponding reward. This optimizes the processing efficiency of vehicle tasks in unloading scenarios with malicious nodes. A Markov decision process is represented by a quadruple (S, A, R, P), where S is the state space, A is the action space, R is the reward function, and P is the state transition probability.

[0165] State Space: Centralized decision-making is adopted, with the base station acting as a single agent, defining the state in each time slot based on global observations. , in For task-related parameters, This represents the state of the remaining computing resources for the task vehicle and roadside units. This indicates the reputation value of the roadside unit at this time. It stores the movement characteristics of the mission vehicle at this moment (specific location and other information). In addition, for have .

[0166] Action space: The action space is represented as: ,in This represents the soft weight of the roadside unit. And it satisfies: Based on this selection weight, the mission vehicle will be selected from the trusted roadside unit candidate set. Ultimately, the roadside unit with the highest weight is selected, i.e.: Then The proportional calculation task is offloaded to the finally selected roadside unit. Processing is required. To strictly meet... In addition to the interval constraints of computational resources and available power, a differentiable projection is applied to the original output of the action space: , ,in (⋅) is the Sigmoid function, which naturally maps any real number to (0,1), thus guaranteeing that no additional pruning is needed. , , The feasibility of this study is demonstrated, and the network training remains differentiable.

[0167] Reward function: The reward value is designed to be a negative of the task processing latency, while incorporating trust risk and on-chain confirmation overhead. ,in The on-chain reputation value for the finally selected roadside unit. This is an indicator function that indicates if the task times out (i.e., ...). ),but This will result in an additional delay penalty. ,on the contrary There is no penalty for this item. This refers to the previously defined blockchain overhead. , and These are the weight parameters for trust risk penalty, timeout default penalty, and blockchain overhead, respectively, and they satisfy the following conditions: These three weights can be allocated according to specific needs.

[0168] As a further improvement to the present invention, in step 6, a trust-aware deep deterministic policy gradient optimization algorithm is designed, and two critic networks are constructed: The value of the same action is estimated using a value function with independent parameters. The aim is to suppress Q-value overestimation, which is prone to occur with a single critic, thereby improving training stability. The formula for calculating the "true" Q-value, compared to the Q-value obtained from the action network, is defined as follows: The method introduces Bellman recursion to teach the critic network to estimate the Q-value. Since two critic networks are used to calculate the value for the next step, the smaller one is taken as the objective. Indicates an immediate reward. Indicates the discount factor and , This represents target action noise (truncated Gaussian noise). The loss function during critic network training is defined as: The mean squared error is used as the loss function during the training of the critic network. For the actor network, the goal is to maximize... In other words, it selects the action that brings greater long-term returns in the current state. Therefore, the update mechanism of the actor network is defined as: .

[0169] Delayed update strategy: The critic network is updated multiple times, while the actor network is updated with a delay, specifically every two steps. This makes the Q-value update more stable. In addition, soft parameter updates are used to prevent Q-value divergence, allowing the algorithm to update slowly and gradually obtain the optimal solution.

[0170] Trust risk-prioritized experience replay: Malicious samples from malicious roadside units are typically sparse but extremely critical. If replayed completely uniformly, the strategy may not learn how to avoid malicious nodes for a considerable period. Therefore, trust risk-prioritized replay is introduced to improve the experience... Define a priority ,in This represents the timing difference error. It is a constant to prevent extremely small values ​​with a priority of 0. Used to control priority intensity. This indicates an amplification of trust risk. It is used to control the extent to which risks are amplified.

[0171] The training process for the intelligent agent's interactive environment is as follows:

[0172] First, the input data and environmental parameters required for trust-aware task offloading training are initialized, including: the computational tasks generated by the vehicle in time slot t within the base station coverage area, the set of roadside units participating in collaborative computation and their edge server resource status, and the continuous time is discretized into multiple time slots to form an interactive training environment. Within each time slot, the task vehicle publishes its task requirements to the base station. The base station filters available roadside units based on roadside unit resources and load and returns a candidate list. The vehicle offloads the task to the target roadside unit for execution. The roadside unit returns the results and execution information and submits an evaluation, available resources / time, and task hash value to the base station. The vehicle submits its evaluation of the roadside unit to the base station, which finally aggregates, verifies, and updates the evaluation before writing it into the consortium blockchain to update the roadside unit's reputation value. Second, the base station is treated as a single agent, and in each time slot, based on the global observation state... Choose an uninstall action and receive a reward to optimize uninstallation efficiency; the state It consists of task-related parameters, the remaining computing resource status of the vehicle and roadside units, the reputation value of the roadside units, and vehicle movement characteristics. Then, the Actor policy network is initialized to output unloading actions, and the Critic value network is initialized to evaluate the value of the actions. Next, the current state is obtained at each time slot t. Then, the Actor outputs a hybrid action: for discrete selection of roadside units, it first outputs a continuously relaxed correlation weight vector that satisfies normalization constraints, and then selects the one with the largest weight from the set of credible roadside unit candidates as the final unloading roadside unit; for continuous decision variables, it applies a differentiable projection to the Actor's original output to strictly satisfy interval constraints and maintain differentiability, thereby obtaining the executable action. Then the action is performed. Complete the task processing for this time slot and calculate the instant reward. Observe the new state after execution. The interactive quadruple (S(t), A(t), R(t), S(t+1)) is stored in the experience replay buffer D for subsequent offline sampling updates. Trust risk-priority experience replay is adopted to accelerate the model's learning of the pattern that "low reputation leads to bad results," and then the Critic network is updated. Simultaneously, truncated Gaussian noise is added to the target action as target action noise, and the mean squared error is used as the Critic loss function. Perform backpropagation updates. Next, update the Actor network by using the deterministic policy gradient to propagate the gradient of the "Q-pair action" back to the Actor parameters to update them. Finally, soft parameter updates are performed on the target network, allowing the target Actor and Critic to smoothly follow the changes in the main network with smaller step sizes. This prevents Q-value divergence during training and gradually converges to the optimal policy. Based on this, the overall algorithm flow is as follows: Figure 3 As shown.

[0173] The following describes the settings of various parameters in the experiment. All neural networks in the experiment were implemented on the Python 3.8.0+ PyTorch 2.0.0 platform, and the Adam optimizer was used to update the network parameters. The performance of the proposed algorithm was evaluated through numerous simulation experiments. In the simulation scenario, vehicles move on the road and periodically generate computational tasks requiring real-time processing. Each task needs to be processed within a tolerable latency after generation and deleted immediately after returning the processing result to avoid storage overflow at the vehicle or roadside end. In the task model, both the computational load and data volume are randomly generated within a given range: the computational load of the task satisfies… The task data volume meets the requirements. The maximum tolerable delay for the task is satisfied. The vehicle's local computing resources meet the requirements. The roadside unit claims that its computing resources meet the requirements.

[0174] In the experimental simulation, both the Actor network and the Critic network consist of two fully connected layers. The Actor network outputs continuous unloading decisions, while the Critic network estimates action values ​​and guides policy updates. Each task vehicle simulates a real-world scenario and calculates its unloading result using a trust-aware deep deterministic policy gradient algorithm based on its own task requirements. Three baseline methods were selected for comparison with the algorithm proposed in this invention: the DQN algorithm, the DDPG algorithm, and the greedy algorithm. The main experimental parameter settings for the algorithm of this invention are shown in Table 1.

[0175] Table 1. Main experimental parameter settings

[0176]

[0177] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other way. Any modifications or equivalent changes made based on the technical essence of the present invention shall still fall within the scope of protection claimed by the present invention.

Claims

1. A vehicle task unloading method based on blockchain, characterized in that: The specific steps include the following: Step 1: Considering vehicle movement scenarios under malicious attacks, design a system model for a vehicle task safe offloading framework; Step 2: The task vehicle generates latency-sensitive intensive computing tasks. Design communication models, computing models, vehicle movement models, and task unloading success rate models, and then construct a problem model for safe unloading of vehicle tasks. Step 3: Based on the problem model, design the objective optimization function to optimize the total task processing delay and task unloading success rate; Step 4: Based on the system model and blockchain technology, design a vehicle-road-chain collaborative trust framework; Step 5: Based on the system model and reinforcement learning algorithm, design the base station agent interaction environment; Step 6: Design a deep deterministic policy gradient optimization algorithm for trust perception, and determine the unloading target after training the agent.

2. The vehicle task unloading method based on blockchain according to claim 1, characterized in that: In step 1, the system model of the vehicle task unloading framework is divided into four parts: task vehicle, roadside unit, base station, and blockchain. In step 1, in a vehicle movement scenario under malicious attack conditions within a vehicle-to-everything (V2X) environment, considering the dynamic movement characteristics of the task vehicle, it must complete its computational tasks within the effective coverage area of ​​the roadside unit. When the task vehicle's own computing resources are insufficient to fully process the task, it needs to offload some task data to the roadside unit to meet the task's computational requirements. Furthermore, considering attackers intruding into the roadside unit and maliciously interfering with the task offloading process, blockchain technology is introduced to ensure the secure offloading and processing of computational tasks. The base station, blockchain, roadside unit, and task vehicle are defined as follows: (1) Base station: The base station assumes the roles of centralized decision-making and coordination, candidate roadside unit generation, recalculation / audit triggering, and reinforcement learning agent; at the same time, the base station participates in on-chain accounting and practical Byzantine fault-tolerant consensus as a consortium blockchain node; the base station's service range covers all vehicles in the model, and all unloading processes are completed within the base station's service range; (2) Blockchain: The blockchain adopts a consortium blockchain architecture to immutably record key evidence and uses smart contracts to punish malicious behavior and maintain reputation, thereby providing a trust foundation and traceable evidence flow for off-chain decision-making; it uses practical Byzantine fault-tolerant consensus to ensure the feasibility and efficiency of on-chain confirmation in a consortium environment. (3) Roadside unit Roadside units, acting as edge servers, possess corresponding computing resources and can provide offloading services for computationally intensive tasks. They also submit crucial evidence of task execution to the base station and participate in on-chain reputation and consensus mechanisms. However, the service ranges of roadside units are not adjacent, and some roadside units are malicious units that have been compromised by hackers, which can hinder vehicle task processing. The set of roadside units is defined as follows: The number of roadside units is defined as follows: ; (4) Mission vehicles Task vehicles are used to generate computational tasks locally. Each computational task generated by a task vehicle consists of multiple sub-tasks. When the local computing resources of the task vehicle cannot meet the processing requirements, some sub-tasks of the corresponding task are offloaded to roadside units. The appropriate offloading target is selected based on the delay requirements and other constraints of the task to be offloaded. The set of task vehicles is defined as follows: The number of vehicles is defined as Define the mission vehicle in each time slot. Each will generate its own computational task. , To designate the mission vehicle, For the corresponding task, task By triplet composition, This indicates the number of CPU cycles required to complete the task. This indicates the size of the data for the task. This indicates the maximum tolerable delay in completing the task; When a task vehicle reaches the service area of ​​a roadside unit, it needs to complete unloading within the coverage area of ​​that roadside unit, and the unloading time must be completed within the maximum tolerable time of the task. Considering the scenario of partial unloading of the task—that is, part of the task is completed locally on the vehicle and part is unloaded to the roadside unit—for the vehicle... Task Define the task unloading ratio as ,in This indicates the proportion of tasks that are unloaded to the roadside unit for processing. This indicates the proportion of tasks processed locally within the vehicle; for tasks... The partial tasks unloaded to the roadside unit for processing are defined as follows: The partial tasks defined for processing locally on the vehicle are represented as .

3. The vehicle task unloading method based on blockchain according to claim 1, characterized in that: The communication model designed in step 2 is as follows: A free-space path loss model is used to describe the process of vehicle task offloading to the edge server. Ignoring downlink transmission delay, it is assumed that orthogonal frequency division multiple access (OFDMA) is used to reduce interference for different vehicle users, and that the roadside units have sufficient bandwidth, with the same bandwidth allocated to each task vehicle, denoted as W. First, the signal-to-noise ratio (SNR) of the uplink transmission channel from task vehicle i to roadside unit j is obtained as follows: ,in, Indicates the vehicle's task transmission power. This indicates the channel gain between the mission vehicle and the RSU. This represents the additive white Gaussian noise power. Since the vehicle's mission transmission power cannot exceed the vehicle's maximum transmit power, the maximum transmit power of the vehicle is defined as follows. Ignoring channel interference between moving vehicles, according to Shannon's formula, the uplink transmission rate of vehicle i when offloading tasks to roadside unit j is: Therefore, disregarding data transmission rate loss, the uplink data transmission delay from vehicle i to roadside unit j is expressed as: ; The calculation model designed in step 2 is as follows: (1) Local processing: First, define the total local computing resources owned by task vehicle i as follows: The amount of computing resources required by the task vehicle to process the local portion of the task is expressed as: Therefore, the completion time of the computation task executed locally is expressed as: ; (2) Roadside unit treatment: Similar to the mission vehicle, the roadside unit itself also has a fixed maximum available computing resources, represented as The amount of computational resources allocated to the task unloaded from vehicle i to the current roadside unit is expressed as: Therefore, the completion time of the task executed in the roadside unit is expressed as: ; The vehicle movement model designed in step 2 is as follows: First, define the position of vehicle i in time slot t as... The location of roadside unit j is The service coverage radius of the roadside unit is r, and the vehicle speed is defined as r. Since the mission vehicle and the roadside unit are not on the same straight line, the motion direction and vector of the mission vehicle are defined. The included angle is Based on this, the link time between task vehicle i and roadside unit j is given, and the following discussion is given depending on whether the task vehicle has entered the service range of the roadside unit that is processing its task at this time: (1) The mission vehicle is already within the service area of ​​the roadside unit: when At this time, it indicates that the task vehicle has entered the service area of ​​the current roadside unit. The link time between task vehicle i and roadside unit j is expressed as: in , Ensure that the processing time of a task in the roadside unit does not exceed the dwell time of the vehicle within the service area of ​​the roadside unit; (2) The task vehicle has not yet entered the service area of ​​the roadside unit: when At this time, the mission vehicle has not yet entered the service area of ​​the roadside unit. The link time between task vehicle i and roadside unit j is expressed as: in It is the perpendicular distance from the vehicle trajectory to the center of the roadside unit circle; Ensure that the processing time of a task in the roadside unit does not exceed the dwell time of the vehicle within the service area of ​​the roadside unit; The task uninstallation success rate model in step 2 is as follows: The unloading success rate of a computational task is defined as R, where R = the number of successfully unloaded tasks / the total number of unloading requests from the task vehicle. For a task generated by a task vehicle, it is considered to have been successfully unloaded when the following constraints are met: (1) When a task is processed in a roadside unit, the total delay of task i is no more than the maximum link time between the task vehicle and roadside unit j, i.e. ; (2) The total delay of the task being processed in the roadside unit shall not exceed the maximum tolerable delay of the task, i.e.: ; Based on this, whether the task was successfully uninstalled is represented as Therefore, the task uninstallation success rate R is represented as: .

4. The vehicle task unloading method based on blockchain according to claim 3, characterized in that: In step 3, based on the problem model, an objective optimization function is designed to obtain the total task processing delay. Since the task is processed in parallel, meaning it is processed simultaneously in the local and roadside units, the total task processing delay is the maximum value processed in both the local and roadside units. Based on the above model, the task unloading problem is formalized into the following optimization problem: in R represents the total processing delay for task vehicle i to complete its task in the current time slot t, and R represents the task unloading success rate of task vehicle i. Constraint 1 states that the transmission power of a vehicle task cannot exceed the vehicle's maximum transmission power. Constraints 2 and 3 state that the computing resources allocated to a task vehicle for processing local tasks cannot exceed the total computing resources owned by the task vehicle, and the computing resources allocated to a roadside unit for processing tasks by task vehicle i cannot exceed the total computing resources owned by the roadside unit, respectively. Constraints 4 and 5 state the conditions for a vehicle entering the service range of a roadside unit and for a vehicle not entering the service range of a roadside unit, respectively. Constraints 6 and 7 state the two conditions for a vehicle task to be successfully unloaded. Constraint 8 states whether task i is unloaded to roadside unit j. Constraint 9 states the task allocation ratio for each task generated by a task vehicle. Constraint 10 states that the processing delay of a task in the local and roadside units cannot exceed the maximum tolerable delay of the task, ensuring successful task completion.

5. A vehicle task unloading method based on blockchain according to claim 1, characterized in that: In step 4, based on the system model and blockchain technology, a vehicle-road-chain collaborative trust framework is designed. To simultaneously meet the goals of minimizing latency and filtering malicious nodes, a collaborative architecture of "off-chain decision-making + on-chain accounting / reputation" is adopted, consisting of an off-chain reinforcement learning layer and an on-chain consortium blockchain layer. In the off-chain reinforcement learning layer, the base station runs a deep deterministic policy gradient optimization algorithm based on the observed state at each time slot t, and jointly outputs the unloading ratio and the selection of unloading nodes based on the final optimization results, thereby minimizing the total task processing latency T. In the on-chain consortium blockchain layer, the base station and roadside units act as consortium blockchain nodes, and the vehicle acts as a light node. On-chain behavior is recorded through smart contracts, and all occurring behaviors are consistent with the blockchain-related steps in the computational unloading process, namely: the roadside unit publishes the computational resources and the latency required to process the current task; the roadside unit returns a hash value; the vehicle and base station evaluate the service; and the roadside unit's reputation value is updated. In addition, to ensure that the overall process latency of writing data to the blockchain and confirming it is controllable, a practical Byzantine fault-tolerant consensus mechanism is used, and the latency overhead generated by this consensus mechanism is defined as follows: .

6. A vehicle task unloading method based on blockchain according to claim 5, characterized in that: For malicious nodes in the uninstallation scenario, their malicious behavior is modeled. Since only latency optimization is considered, the behavior of malicious service nodes is divided into two categories: (1) False reporting of computing power: Roadside unit j declares its available computing power and the computing power allocated to task vehicle i to the base station and vehicles, respectively. and However, the actual computing power owned and allocated is even lower; at this time, the computational latency of the tasks executed in this roadside unit is higher. The computational delay will increase significantly; although the computational delay increases in this case, it does not exceed the maximum tolerable delay required by the task. Although the task is successfully processed, the roadside unit has breached its service commitment and is still considered to have failed to process the task. (2) Fraudulent results: In this scenario, the processing delay of the task from roadside unit j to vehicle i exceeds the maximum tolerable delay for that task, or the roadside unit fails to process the task, resulting in task processing failure. However, the roadside unit fakes the task's successful completion and returns a false processing result. ; To ensure that malicious behavior by roadside units is verifiable and accountable, a minimum necessary on-chain evidence is designed. Once a roadside unit completes its computation task, it uploads the result hash to the blockchain. ,in This represents the hash value generated by roadside unit j. This represents the result after roadside unit j has processed task i. When the task vehicle receives the result, since the vehicle lacks verification capabilities, it uploads the result to the base station, which then recalculates and uploads it to the blockchain. ,in This represents the hash value of the result after the task vehicle sends it to the base station for recalculation. This indicates the result received by task vehicle i from roadside unit j. This includes the task number, time slot, roadside unit identifier, and task execution time. Since tasks offloaded to roadside units may fail to complete, and the task vehicle cannot reprocess this part of the task, a probabilistic auditing mechanism is introduced: the base station uses probability... The unloaded tasks are recalculated or sampled for verification to obtain a consistency indicator: When the audit fails, i.e. At that time, the smart contract can deduct the reputation value of the current roadside unit; To ensure that reputation scores directly serve the goal of "latency minimization," a single service quality score is defined as follows: ,in The first term on the left side of the formula This represents a sensitivity coefficient for delay penalties; the larger the coefficient, the more sensitive the task is to timeouts. The second term... The sensitivity coefficient for resource honesty penalty. To represent a very small constant, ,prevent In cases where calculation is not possible; for the reliable terms of the results on the right side of the formula, the following definition applies: This means mapping the "audit result" to a 0-1 confidence weight, and applying a conservative discount when an audit is not triggered. To encourage the system to trigger audits in critical scenarios; The global reputation value of roadside unit j is updated using exponential sliding: ,in This represents the average score of all task vehicles that interact with roadside unit j within time slot t. Used to control the "historical / recent" weight; It is maintained by smart contracts and can be queried for task vehicles, and is also used for training and optimization of the deep deterministic strategy gradient optimization algorithm for trust awareness off-chain. To directly exclude obviously malicious roadside units from the decision space, the base station generates a candidate set based on a reputation threshold: ,in This represents the minimum reputation threshold at which a roadside unit can be trusted; the base station will also feed this candidate set back to the task vehicle after generating it.

7. A vehicle task unloading method based on blockchain according to claim 1, characterized in that: In step 5, a trust-aware deep deterministic policy gradient optimization algorithm is used, and a dual Critic network, target policy smoothing and delayed policy update mechanism are introduced to reduce the Q-value overestimation problem and improve training stability. The base station is regarded as a reinforcement learning agent. In each time slot t, it selects an unloading action based on the observed state and obtains a corresponding reward. This is used to optimize the processing efficiency of vehicle tasks in the case of malicious nodes in the unloading scenario. The Markov decision process is represented by a quadruple (S(t), A(t), R(t), P(t)), where S is the state space, A is the action space, R is the reward function, and P is the state transition probability. State Space: Centralized decision-making is adopted, with the base station acting as a single agent, defining the state in each time slot based on global observations. , in For task-related parameters, This represents the state of the remaining computing resources for the task vehicle and roadside units. This indicates the reputation value of the roadside unit at this time. It stores the movement characteristics of the vehicle at this time; in addition, for have ; Action space: The action space is represented as: ,in This represents the soft weight of the roadside unit. And it satisfies: Based on this selection weight, the mission vehicle will be selected from the trusted roadside unit candidate set. Ultimately, the roadside unit with the highest weight is selected, i.e.: Then The proportional calculation task is offloaded to the finally selected roadside unit. Processing is required; in order to strictly meet the requirements In addition to the interval constraints of computational resources and available power, a differentiable projection is applied to the original output of the action space: , ,in (⋅) is the Sigmoid function, which naturally maps any real number to (0,1), thus guaranteeing that no additional pruning is needed. , , The feasibility of this study is demonstrated, and the network training remains differentiable. Reward function: The reward value is designed to be a negative of the task processing latency, while incorporating trust risk and on-chain confirmation overhead. ,in The on-chain reputation value for the finally selected roadside unit. This is an indicator function that, if the task times out, i.e. ,but This will result in an additional delay penalty. ,on the contrary There is no penalty for this item; This refers to the previously defined blockchain overhead; , and These are the weight parameters for trust risk penalty, timeout default penalty, and blockchain overhead, respectively, and they satisfy the following conditions: These three weights can be allocated according to specific needs.

8. A vehicle task unloading method based on blockchain according to claim 1, characterized in that: In step 6, a deep deterministic policy gradient optimization algorithm for trust perception is designed, and two critic networks are constructed: The value of the same action is estimated using a value function with independent parameters. The aim is to suppress Q-value overestimation, which is prone to occur with a single critic, thereby improving training stability; a formula is defined for calculating the "true" Q-value compared to the Q-value obtained from the action network: The method introduces Bellman recursion to teach the critic network to estimate the Q-value. Since two critic networks are used to calculate the value for the next step, the smaller one is taken as the objective. Indicates an immediate reward. Indicates the discount factor and , Representing target action noise; the loss function during critic network training is defined as: The mean squared error is used as the loss function during the training of the critic network; for the actor network, the goal is to maximize... In other words, it selects the action that brings greater long-term returns in the current state. Therefore, the update mechanism of the actor network is defined as: ; Delayed update strategy: The critic network is updated multiple times, while the actor network is updated with a delay. Specifically, the actor network is updated every 2 steps to make the Q-value update more stable. In addition, soft parameter updates are used to prevent Q-value divergence, so that the algorithm updates slowly and gradually obtains the optimal solution. Trust risk-prioritized experience replay: Malicious samples from malicious roadside units are typically sparse but extremely critical. If replayed completely uniformly, the strategy may not learn how to avoid malicious nodes for a considerable period. Therefore, trust risk-prioritized replay is introduced to improve the experience... Define a priority ,in Indicates timing difference error; It is a constant to prevent extremely small values ​​with a priority of 0. Used to control priority intensity; This indicates an amplification of trust risk. It is used to control the extent to which risks are amplified.

9. A vehicle task unloading method based on blockchain according to claim 1, characterized in that: In step 6, the interactive environment of the intelligent agent is trained. The training process is as follows: First, the input data and environmental parameters required for the trust perception task offloading training are initialized, including: the computing tasks generated by the vehicle in time slot t within the base station coverage area, the set of roadside units participating in collaborative computing and their edge server resource status, and the continuous time is discretized into multiple time slots to form an interactive training environment; in each time slot, the task vehicle publishes the task requirement to the base station, the base station filters the available roadside units based on roadside unit resources and load and returns a candidate list, the vehicle offloads the task to the target roadside unit for execution, the roadside unit returns the result and execution information and submits the evaluation, available resources / time and task hash value to the base station, the vehicle submits the evaluation of the roadside unit to the base station, and finally the base station summarizes, verifies and updates the evaluation and writes it into the consortium blockchain to update the reputation value of the roadside unit; second, the base station is regarded as a single intelligent agent, and in each time slot, the state is based on global observation. Choose an uninstall action and receive a reward to optimize uninstallation efficiency; the state The system consists of task-related parameters, the remaining computing resource status of the vehicle and roadside units, the reputation value of the roadside units, and vehicle movement characteristics. Then, the Actor policy network is initialized to output unloading actions, and the Critic value network is initialized to evaluate the value of the actions. Next, the current state is acquired at each time slot t. Then, the Actor outputs a hybrid action: for discrete selection of roadside units, it first outputs a continuously relaxed correlation weight vector that satisfies normalization constraints, and then selects the one with the largest weight from the set of credible roadside unit candidates as the final unloading roadside unit; for continuous decision variables, it applies a differentiable projection to the Actor's original output to strictly satisfy interval constraints and maintain differentiability, thereby obtaining the executable action. ; then perform the action Complete the task processing for this time slot and calculate the instant reward. ; Observe the new state after execution The interactive quadruple (S(t), A(t), R(t), S(t+1)) is stored in the experience replay buffer D for subsequent offline sampling updates. Trust risk-priority experience replay is adopted to accelerate the model's learning of the rule that "low reputation leads to bad results," and then the Critic network is updated. Simultaneously, truncated Gaussian noise is added to the target action as target action noise, and the mean squared error is used as the Critic loss function. Perform backpropagation to update; then update the Actor network, using a deterministic policy gradient to propagate the gradient of the "Q-pair action" back to the Actor parameters to update them. Finally, perform soft parameter updates on the target network to allow the target Actor and Critic to smoothly follow the changes in the main network with smaller step sizes, preventing Q-value divergence during training and gradually converging to the optimal policy.

Images