A resource allocation method and system in an Internet of Vehicles based on blockchain

Abstract

The present application provides a method and system for resource allocation in a vehicle-to-everything (V2X) network based on blockchain, which relates to the technical field of V2X communication. The method includes: uploading resource requirement information of a target vehicle to a first roadside unit node; obtaining the resource requirement information uploaded by the first roadside unit node and the available resource information uploaded by multiple second roadside unit nodes respectively; automatically executing intelligent contract resource allocation to generate a resource allocation scheme according to the benefits and energy consumption of the blockchain system; according to the resource allocation scheme, a third roadside unit node among the multiple second roadside unit nodes returns the calculation result for the resource requirement information to the target vehicle, and after verifying the integrity and correctness of the calculation result, the target vehicle uploads the transaction data and the reputation value for the third roadside unit node to the blockchain system. The present application can achieve the allocation of computing resources in a dynamic environment.

Description

Technical Field

[0001] This application relates to the technical field of vehicle networking communication, and particularly relates to a method and system for resource allocation in a vehicle networking based on blockchain. Background Art

[0002] With the rapid development of vehicle networking, more and more vehicles and infrastructures are interconnected through wireless networks, constructing a large-scale and dynamic vehicle networking system. In vehicle networking, different types of vehicles and roadside units can achieve data sharing and collaborative computing through vehicle-to-vehicle and vehicle-to-infrastructure communications. However, with the increase in the number of connected vehicles, the contradiction between the supply and demand of computing resources has become increasingly prominent, and traditional centralized resource allocation methods are difficult to meet the resource allocation requirements in complex vehicle networking environments.

[0003] The introduction of blockchain technology provides a new solution idea for vehicle networking resource allocation. Blockchain has characteristics such as decentralization, data immutability, and security and transparency, making it suitable for resource management and data sharing in vehicle networking environments. However, the application of blockchain-based resource allocation in vehicle networking also faces challenges. How to achieve the allocation of computing resources in a dynamic environment has become a technical problem that needs to be solved urgently. Summary of the Invention

[0004] This application provides a method and system for resource allocation in a vehicle networking based on blockchain, which can achieve the allocation of computing resources in a dynamic environment.

[0005] In the first aspect of this application, a method for resource allocation in a vehicle networking based on blockchain is provided. The method includes:

[0006] Upload the resource requirement information of the target vehicle to the first roadside unit node, where the target vehicle is a vehicle that needs computing resources, and the first roadside unit node is the roadside unit node closest to the target vehicle among the multiple roadside unit nodes included in the blockchain system;

[0007] Obtain the resource requirement information uploaded by the first roadside unit node and the available resource information respectively uploaded by multiple second roadside unit nodes, where the second roadside unit nodes are the roadside unit nodes with resource supply capabilities among the multiple roadside unit nodes;

[0008] Automatically execute the intelligent contract resource allocation, and generate a resource allocation plan according to the benefits and energy consumption of the blockchain system. The resource allocation plan includes the transaction and allocation methods for the available resource information of multiple second roadside unit nodes, the quantity of resources, and the information of all parties to the transaction;

[0009] According to the resource allocation scheme, a third roadside unit node among the multiple second roadside unit nodes returns the calculation result for the resource demand information to the target vehicle. After verifying the integrity and correctness of the calculation result, the target vehicle uploads the transaction data and the reputation value for the third roadside unit node to the blockchain system.

[0010] Based on the above technical solution, preferably, after a third roadside unit node among the multiple second roadside unit nodes returns the calculation result for the resource demand information to the target vehicle according to the resource allocation scheme, the method further includes:

[0011] If it is determined that the priority of the target vehicle reaches a preset priority, set the voting right of the target vehicle so that the target vehicle can participate in node election;

[0012] Based on the result of the node election, the multiple roadside unit nodes are divided into active nodes and standby nodes according to the reputation value and the voting right. Among them, the active nodes take turns as block managers, responsible for packing and publishing data blocks, and at the same time encourage highly productive roadside unit nodes to participate in data verification and become verification nodes. The verification nodes review the data content through local and mutual verification processes and send the verification results to the block manager within a specified time. The block manager adds the verified data blocks to the blockchain system.

[0013] Based on the above technical solution, preferably, after verifying the integrity and correctness of the calculation result, the target vehicle uploads the transaction data and the reputation value for the third roadside unit node to the blockchain system, and specifically further includes:

[0014] Retrieve the interaction record between the target vehicle and the third roadside unit node, and obtain the recommendation values of multiple roadside unit nodes for the third roadside unit node;

[0015] Based on the interaction record and the recommendation values, calculate the reputation value of the third roadside unit node. Among them, the calculation of the reputation value uses a multiple weight model for calculation, and the calculation factors include familiarity, timeliness, and interaction enthusiasm.

[0016] Based on the above technical solution, preferably, the dynamic execution of the intelligent contract resource allocation generates a resource allocation scheme according to the benefits and energy consumption of the blockchain system, specifically including:

[0017] S1: Randomly generate an initial population, where the initial population contains different resource allocation schemes between the target vehicle and the second roadside unit node, and each individual in the initial population is a preset resource allocation scheme;

[0018] S2: Determine the system total benefit objective function and the system total energy consumption objective function of each individual in the blockchain system. The system total benefit includes the cost and revenue of resources, and the system total energy consumption includes transmission and computing energy consumption;

[0019] S3: Perform non-dominated sorting on each individual and find the crowding degree of each individual;

[0020] S4: According to the calculation result of the crowding degree, use the tournament selection method to select target individuals that meet the preset fitness from multiple individuals;

[0021] S5: Perform crossover and mutation operations on the target individuals to generate a new candidate population;

[0022] S6: Combine the initial population and the candidate population to obtain a combined population;

[0023] S7: Select individuals that meet the preset fitness in the combined population according to non-dominated sorting and crowding degree to form a new population;

[0024] S8: Repeat steps S1 to S7 until the preset number of iterations is reached or the convergence condition is met, obtain and output the target solution set, and get the resource allocation scheme.

[0025] Based on the above technical solutions, preferably, for determining the system total benefit objective function and the system total energy consumption objective function of each individual in the blockchain system, the system total benefit objective function is specifically determined by the following formula:

[0026]

[0027] Where, is the system total benefit, τ is to balance the contributions of different parts to the system total benefit, Φ is the cost of purchasing resources, is the quantity of resources purchased by the buyer, ε is the revenue from selling resources, represents the quantity of resources sold at time t, represents the block packaging revenue of the block manager at time t, represents the reward of the verification node at time t;

[0028] The system total energy consumption objective function is determined by the following formula:

[0029]

[0030] Among them, is the total system energy consumption, η is the effective capacitance parameter of the chipset, is the computing frequency that the roadside unit node can provide, is the computing delay of the target vehicle, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, p is the transmission power, is the number of computing tasks, is the block size for transmission, download, and upload during the k-th block verification process, is the link channel bandwidth, is the link channel gain, is the Gaussian noise power.

[0031] Based on the above technical solutions, preferably, the method further includes:

[0032] Calculate the uplink transmission rate of the target vehicle to upload the resource demand information to the roadside unit node based on the communication uplink channel bandwidth from the target vehicle to the roadside unit node, the vehicle transmission power of the target vehicle, and the uplink channel gain from the target vehicle to the roadside unit node;

[0033] Calculate the uplink transmission delay based on the uplink transmission rate;

[0034] Calculate the computing delay based on the amount of tasks that the target vehicle needs to offload to the roadside unit node and the computing task processing rate of the target vehicle;

[0035] Calculate the downlink transmission rate of the target vehicle to upload the resource demand information to the roadside unit node based on the downlink channel bandwidth from the target vehicle to the roadside unit node, the node transmission power of the roadside unit node, and the downlink channel gain from the target vehicle to the roadside unit node;

[0036] Calculate the downlink transmission delay according to the task size included in the resource demand information and the downlink transmission rate;

[0037] Calculate the average response time of the target vehicle to the processing task request from the roadside unit node according to the uplink transmission delay, the computing delay, and the downlink transmission delay.

[0038] Based on the above technical solutions, preferably, the reputation value of the third roadside unit node is calculated based on the interaction record and the recommendation value, and is specifically calculated by the following formula:

[0039]

[0040] Wherein, represents the reputation value at time t, represents the historical reputation value at time t-1, k represents the number of newly added verifications from the previous moment to this moment, is the reputation weight, represents the total number of verifications, and the historical reputation value is specifically calculated by the following formula:

[0041]

[0042] Wherein, ra(t) is the historical reputation value at time t, ra(t-1) is the historical reputation value at time t-1, ψ is the weight parameter, β is the transmission delay weight parameter of the target vehicle, and the transmission delay weight parameter is specifically calculated by the following formula:

[0043]

[0044] Wherein, β is the transmission delay weight parameter, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, is the average response time of the processing task request from the target vehicle to the roadside unit node.

[0045] In the second aspect of the present application, a resource allocation system in a vehicle-to-everything network based on blockchain is provided. The system includes an acquisition module, a processing module, and an output module, wherein:

[0046] The acquisition module is used to upload the resource requirement information of the target vehicle to the first roadside unit node. The target vehicle is a vehicle that requires computing resources, and the first roadside unit node is the roadside unit node closest to the target vehicle among the multiple roadside unit nodes included in the blockchain system;

[0047] The acquisition module is used to acquire the resource requirement information uploaded by the first roadside unit node, and the available resource information uploaded by multiple second roadside unit nodes respectively. The second roadside unit nodes are the roadside unit nodes among the multiple roadside unit nodes that have the resource supply ability;

[0048] The processing module is used to automatically execute the intelligent contract resource allocation, generate a resource allocation plan according to the benefits and energy consumption of the blockchain system, and the resource allocation plan includes the trading and allocation methods of the available resource information for multiple second roadside unit nodes, the quantity of resources, and the information of all parties to the transaction;

[0049] The output module is used to, according to the resource allocation plan, the third roadside unit node among multiple second roadside unit nodes returns the calculation result for the resource demand information to the target vehicle, and after verifying the integrity and correctness of the calculation result, the target vehicle uploads the transaction data and the reputation value for the third roadside unit node to the blockchain system.

[0050] Based on the above technical solution, preferably, the processing module is used to, if it is determined that the priority of the target vehicle reaches a preset priority, set the voting right of the target vehicle so that the target vehicle can participate in node election;

[0051] The processing module is used to, based on the result of the node election, divide multiple roadside unit nodes into active nodes and standby nodes according to the reputation value and the voting right, where the active nodes take turns as block managers, responsible for packaging and publishing data blocks, and at the same time encourage highly productive roadside unit nodes to participate in data verification and become verification nodes, and the verification nodes review the data content through local and mutual verification processes and send the verification results to the block manager within a specified time, and the block manager adds the verified data block to the blockchain system.

[0052] Based on the above technical solution, preferably, the acquisition module is used to retrieve the interaction record between the target vehicle and the third roadside unit node, and obtain the recommendation value for the third roadside unit node from multiple roadside unit nodes;

[0053] The processing module is used to calculate the reputation value of the third roadside unit node based on the interaction record and the recommendation value, where the calculation of the reputation value is performed using a multiple weight model, and the calculation factors include familiarity, timeliness, and interaction enthusiasm.

[0054] Based on the above technical solution, preferably, the processing module is used to randomly generate an initial population, and the initial population includes different resource allocation plans between the target vehicle and the second roadside unit nodes, and each individual in the initial population is a preset resource allocation plan;

[0055] The processing module is used to determine the total system benefit objective function and the total system energy consumption objective function of each individual in the blockchain system. The total system benefit includes the cost and revenue of resources, and the total system energy consumption includes transmission and computing energy consumption;

[0056] The processing module is used to perform non-dominated sorting on each individual and find the crowding degree of each individual;

[0057] The processing module is used to adopt the tournament selection method according to the calculation result of the crowding degree to select target individuals that meet the preset fitness from multiple individuals;

[0058] The processing module is used to perform crossover and mutation operations on the target individuals to generate a new candidate population;

[0059] The processing module is used to combine the initial population and the candidate population to obtain a combined population;

[0060] The processing module is used to select individuals that meet the preset fitness from the combined population according to non-dominated sorting and crowding degree to form a new population;

[0061] The processing module is used to repeat the above steps until the preset number of iterations is reached or the convergence condition is met, obtain and output the target solution set, and obtain the resource allocation scheme.

[0062] Based on the above technical solutions, preferably, the processing module is used to determine the total system benefit objective function and the total system energy consumption objective function of each individual in the blockchain system. The total system benefit objective function is specifically determined by the following formula:

[0063]

[0064] Among them, is the total system benefit, τ is to balance the contributions of different parts to the total system benefit, Φ is the cost of purchasing resources, is the quantity of resources purchased by the buyer, ε is the revenue from selling resources, represents the quantity of resources sold at time t, represents the block packaging revenue of the block manager at time t, represents the reward of the verification node at time t;

[0065] The total system energy consumption objective function is determined by the following formula:

[0066]

[0067] Among them, is the total system energy consumption, η is the effective capacitance parameter of the chipset, The computing frequency available for the roadside unit node The computing delay of the target vehicle The uplink transmission delay from the target vehicle to the roadside unit node The downlink transmission delay from the target vehicle to the roadside unit node, where p is the transmission power The number of computing tasks The block size for transmission, download, and upload during the k-th block verification process The link channel bandwidth The link channel gain The Gaussian noise power

[0068] Based on the above technical solutions, preferably, the processing module is configured to calculate the uplink transmission rate at which the target vehicle uploads the resource requirement information to the roadside unit node based on the communication uplink channel bandwidth from the target vehicle to the roadside unit node, the vehicle transmission power of the target vehicle, and the uplink channel gain from the target vehicle to the roadside unit node. The calculation is specifically performed using the following formula:

[0069]

[0070] Where is the uplink channel bandwidth is the vehicle transmission power is the uplink channel gain is the Gaussian noise power

[0071] The processing module is configured to calculate the uplink transmission delay based on the uplink transmission rate. The calculation is specifically performed using the following formula:

[0072]

[0073] Where is the uplink transmission delay is the task size included in the resource requirement information is the uplink transmission rate

[0074] The processing module is configured to calculate the computing delay based on the amount of tasks that the target vehicle needs to offload to the roadside unit node and the computing task processing rate of the target vehicle. The calculation is specifically performed using the following formula:

[0075]

[0076] Where For the computing delay, For the task volume, U is the number of CPU cycles required for the target vehicle to process each bit of task volume input data, For the computing task processing rate;

[0077] The processing module is configured to calculate the downlink transmission rate at which the target vehicle uploads the resource demand information to the roadside unit node based on the downlink channel bandwidth from the target vehicle to the roadside unit node, the node transmission power of the roadside unit node, and the downlink channel gain from the target vehicle to the roadside unit node, and specifically calculates through the following formula:

[0078]

[0079] Wherein, is the downlink transmission rate, is the downlink channel bandwidth, is the node transmission power, is the downlink channel gain, is the Gaussian noise power;

[0080] Calculate the downlink transmission delay according to the task size included in the resource demand information and the downlink transmission rate, and specifically calculate through the following formula:

[0081]

[0082] Wherein, is the downlink transmission delay, is the task size included in the resource demand information, is the downlink transmission rate;

[0083] The processing module is configured to calculate the average response time of the processing task request from the target vehicle to the roadside unit node according to the uplink transmission delay, the computing delay, and the downlink transmission delay, and specifically calculates through the following formula:

[0084]

[0085] Wherein, is the average response time of the processing task request, is the uplink transmission delay, is the computing delay, is the downlink transmission delay.

[0086] Based on the above technical solutions, preferably, the processing module is configured to calculate the reputation value of the third roadside unit node based on the interaction record and the recommendation value, specifically calculated by the following formula:

[0087]

[0088] Wherein, represents the reputation value at time t, represents the historical reputation value at time t-1, k represents the number of newly added verifications from the previous moment to this moment, is the reputation weight, represents the total number of verifications, and the historical reputation value is specifically calculated by the following formula:

[0089]

[0090] Wherein, ra(t) is the historical reputation value at time t, ra(t-1) is the historical reputation value at time t-1, ψ is the weight parameter, β is the transmission delay weight parameter of the target vehicle, and the transmission delay weight parameter is specifically calculated by the following formula:

[0091]

[0092] Wherein, β is the transmission delay weight parameter, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, is the average response time of the processing task request from the target vehicle to the roadside unit node.

[0093] In the third aspect of the present application, an electronic device is provided, including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device executes the method described in any one of the above.

[0094] In the fourth aspect of the present application, a computer-readable storage medium is provided. The computer-readable storage medium stores instructions, and when the instructions are executed, the method described in any one of the above is executed.

[0095] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages:

[0096] 1. This application utilizes the decentralized and smart contract mechanisms of blockchain to collect real-time resource demand information of target vehicles and available resource information of multiple roadside unit nodes. It balances system benefits and energy consumption through automatically executed smart contracts, and dynamically generates an optimal resource allocation plan. Meanwhile, the node reputation evaluation mechanism ensures the fairness and reliability of resource allocation, and the upload of the verification results of target vehicles further strengthens the credibility of data and the self-adaptability of the system. The overall design can not only cope with the dynamic changes of nodes in the vehicle-to-everything (V2X) network, but also ensure the transparency and efficiency of resource allocation.

[0097] 2. Through a multi-objective optimization method, using the benefit and energy consumption functions of the blockchain system, a resource allocation plan is dynamically generated. The diversity of solutions is maintained through non-dominated sorting and crowding degree calculation, and the resource allocation strategy is continuously optimized by combining tournament selection, crossover, and mutation operations to ensure that the resource allocation reaches a balance between cost-benefit and energy consumption. Finally, through multiple rounds of iteration, it converges to the optimal solution set, achieving the maximization of resource utilization efficiency, the minimization of computing energy consumption, and the ability of the system to adapt to dynamic environments, thereby improving the fairness and reliability of computing resource allocation in the V2X network.

[0098] 3. Considering factors such as interaction records, recommendation values, and transmission delays, the reputation value of roadside unit nodes is dynamically calculated, and a comprehensive evaluation mechanism is established. Through the reputation increment formula for current verification behaviors and the dynamic adjustment formula for historical reputation values, the short-term performance and long-term stability of nodes are weighed, and at the same time, a transmission delay weight parameter is introduced to effectively reduce the impact of inefficient nodes on the system. The accurate quantification and dynamic optimization of node reputation are achieved, improving the fairness and reliability of system resource allocation, and providing a scientific basis for node selection and resource collaboration in the V2X network. Brief Description of the Drawings

[0099] Figure 1 is a schematic flowchart of a method for resource allocation in a vehicle-to-everything (V2X) network based on blockchain disclosed in an embodiment of this application;

[0100] Figure 2 is a schematic block diagram of a resource allocation system in a vehicle-to-everything (V2X) network based on blockchain disclosed in an embodiment of this application;

[0101] Figure 3 is a schematic structural diagram of an electronic device disclosed in an embodiment of this application.

[0102] Description of the Reference Numerals: 201, acquisition module; 202, processing module; 203, output module; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Embodiments

[0103] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments.

[0104] In the description of the embodiments of this application, words such as "for example" or "for illustration" are used to give examples, illustrations or explanations. Any embodiment or design solution described as "for example" or "for illustration" in the embodiments of this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "for example" or "for illustration" is intended to present the relevant concepts in a specific manner.

[0105] In the description of the embodiments of this application, the meaning of the term "plural" refers to two or more. For example, a plurality of systems refers to two or more systems, and a plurality of screen terminals refers to two or more screen terminals. In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the technical features indicated. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features. The terms "include", "comprise", "have" and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0106] The rapid development of the vehicle networking has brought about large-scale interconnection and data sharing between vehicles and infrastructure. However, the resulting contradiction between the supply and demand of computing resources makes it difficult for traditional centralized resource allocation to meet the requirements. Blockchain technology, with its characteristics of decentralization, data immutability, and security and transparency, provides a new idea for vehicle networking resource management. However, in a dynamic and complex vehicle networking environment, how to efficiently implement blockchain-based computing resource allocation still faces huge challenges.

[0107] This embodiment discloses a method for resource allocation in a vehicle networking based on blockchain, referring to Figure 1 , including the following steps S110-S140:

[0108] S110, upload the resource demand information of the target vehicle to the first roadside unit node.

[0109] In the embodiments of this application, the vehicles participating in the resource allocation in the vehicle networking are equipped with in-vehicle units and advanced communication devices, enabling them to perform vehicle-to-infrastructure and vehicle-to-vehicle communications. The roadside unit node, as an important part of the public infrastructure, is supervised and certified by relevant regulatory agencies (such as the government or the Federal Communications Commission). In addition, the roadside unit node has excellent computing and storage capabilities and can provide computing resources to meet the computing tasks and information transmission in the vehicle networking.

[0110] All entities within the vehicle networking are authenticated by a global trust authority. All roadside unit nodes form a blockchain system. Roadside unit nodes are an important part of the vehicle networking, mainly referring to communication and computing devices deployed on both sides of the road or on traffic infrastructure. These nodes are responsible for enabling communication between vehicles and infrastructure in the vehicle networking. Meanwhile, in a blockchain-based system, they may also participate in data storage, verification, and consensus as nodes of the blockchain network. Roadside unit nodes undergo additional regulatory reviews during the authentication process. Whether they are candidates for blockchain nodes depends on whether their reputation values exceed a set threshold. After authorization, an entity obtains a public key, a private key, and an encryption certificate for secure communication, and generates multiple wallet accounts on the blockchain for resource allocation and transactions.

[0111] Vehicles participating in resource allocation within the vehicle networking include on-board units and communication devices, which specifically consist of the following parts:

[0112] On-board unit OBU, which is used to collect vehicle status and environmental information, and communicate with roadside unit nodes RSU and other vehicles. It usually includes sensors, a processor, a memory, etc.

[0113] Communication devices, which support V2V through Wi-Fi or Bluetooth, are usually integrated with the OBU, and are used to achieve data interaction and communication between vehicles.

[0114] The roadside unit nodes within the vehicle networking system include a communication module, a computing module, a resource trading module, a blockchain verification module, and a transaction settlement module, specifically as follows:

[0115] Communication module, which completes information interaction with vehicles and base stations, and together with the blockchain verification module completes initialization, transmits information through the blockchain network, and conducts identity authentication through the global trust authority TA.

[0116] Computing module, which is the core component of the vehicle networking system base station, is responsible for processing the computing tasks unloaded by vehicles. It can dynamically adjust resource allocation according to vehicle requirements and traffic conditions, coordinate vehicles for cooperative computing to improve computing efficiency and task completion speed. It also conducts quality control and security control, including error detection, result feedback, access control, and behavior monitoring, to ensure the accuracy of task results and the security of the system. In addition, the computing module also completes reputation evaluation and urgency assessment, calculates the reputation value according to a multiple weight model to form a local opinion, considers resource requirements and reputation values, queues tasks according to the urgency and reputation values of vehicles, and allocates corresponding computing resources to achieve higher-quality resource allocation and lower energy consumption.

[0117] The resource trading module executes the allocation decision of the resource allocation module, sends the transaction information to the blockchain verification module for verification, conducts transaction settlement based on the verification result, and records the transaction log to ensure the transparency and traceability of the transaction.

[0118] The blockchain verification module allows the roadside unit node RSU to participate in the blockchain verification process through the Enhance Delegated Proof of Reputation (eDPoR) consensus mechanism, effectively identifies and resists malicious attacks, ensures that only trusted vehicles can participate in blockchain interactions, verifies transaction data and maintains the security of the blockchain, and feeds back the verification result to the resource trading module to ensure the legality and integrity of the transaction.

[0119] The transaction settlement module executes the settlement operation of the resource transaction after the blockchain verification module confirms the validity of the transaction, ensuring the final completion of the transaction and the accurate transfer of resource coins.

[0120] The on-board unit OBU collects vehicle status and environmental information. When the vehicle's computing power is insufficient, it can interact the computing resource requirements to the communication module of the nearest roadside unit node through the integrated communication device. The communication module of the roadside unit node conducts information transmission and identity verification through the blockchain network, and publishes the resource task requirements to the computing module. The computing module processes the computing tasks unloaded by the vehicle, conducts resource scheduling and quality control, including reputation evaluation and urgency assessment. Subsequently, the resource trading module executes the final resource allocation strategy from the computing module and sends the transaction information to the blockchain verification module for verification. The blockchain verification module verifies the validity of the transaction through the eDPoR consensus mechanism and protects the security of the blockchain. After the transaction is verified as valid, the transaction settlement module executes the final transaction settlement.

[0121] In addition, the vehicle networking system is divided into two layers: the physical layer and the virtual layer. Specifically:

[0122] In the physical layer, the vehicle can receive data from the roadside unit node and other vehicle intelligent devices through the on-board unit. When the vehicle's computing power is limited, it can interact with the communication module of the roadside unit node to offload the computing task to the computing module of the nearby roadside unit node for collaborative computing. The roadside unit node has modules such as communication, computing, resource trading, blockchain verification, and transaction settlement, with strong computing and storage capabilities. It can connect vehicles and infrastructure, provide blockchain services, and share computing resources. According to the allocation result, the vehicle will be assigned different vehicle reputation values, which will affect the voting weight of each vehicle when calculating the final reputation value of the roadside unit node. In this embodiment, the offloading of the vehicle's computing task is regarded as a resource trading market, and the buyers and sellers in the trading market are the roadside unit node and the vehicle.

[0123] At the virtualization layer, the roadside unit node runs a resource allocation algorithm through a computing module and a blockchain verification module. Then, based on the eDPoR consensus mechanism, the roadside unit node is selected as a blockchain node and classified into an active node and a standby node according to its reputation value. All blockchain nodes need to record the data sharing in the communication with the fleet vehicles and the information related to the collaborative computing transactions between the vehicles and the roadside unit nodes. When an active node is selected as the block manager, it is responsible for incorporating the recorded information from the blockchain nodes into the blockchain in the form of blocks, thus realizing effective data sharing and collaborative computing. During the block verification process, the nodes consume computing resources to verify the transaction blocks.

[0124] The target vehicle establishes communication with the surrounding roadside unit nodes through its on-vehicle unit and communication equipment. The on-vehicle unit automatically determines the closest roadside unit node as the target node, that is, the first roadside unit node, based on parameters such as signal strength, communication delay, or geographical location. If there are multiple RSU nodes to choose from, the blockchain system may adopt a load balancing algorithm or priority rules to select the optimal node.

[0125] After establishing a secure communication link, the target vehicle sends detailed resource requirement information (including task size, computing demand, latency requirement, etc.) to the communication module of the first roadside unit node. After receiving the requirement information, the communication module of the first roadside unit node uploads it to the blockchain network to prepare for resource allocation.

[0126] S120, the first roadside unit node uploads the resource requirement information to the blockchain system, and multiple second roadside unit nodes respectively upload the available resource information to the blockchain system.

[0127] The resource requirement information packed by the first roadside unit node is broadcast to other blockchain nodes through the blockchain network. The verification nodes of the blockchain network use a consensus mechanism (such as the enhanced delegated proof of reputation mechanism, eDPoR) to verify the legality of the information. After passing the verification, the resource requirement information is recorded in the transaction sub-block of the blockchain and associated with the transaction Merkle tree root to ensure the immutability of the data.

[0128] The second roadside unit node monitors its own available resource information in real time through its computing module, including idle CPU processing power, storage space, network bandwidth, power consumption, etc., extracts the resource data that can be supplied currently, and generates a resource description, including resource type, quantity, estimated response time, etc.

[0129] Each second roadside unit node formats its own available resource information, packages it into a transaction format supported by the blockchain, and digitally signs the resource description using the private key of the node to ensure the credibility of the data source. The second roadside unit node broadcasts the signed available resource information through the blockchain network to all nodes including the first roadside unit node. Other blockchain nodes verify the authenticity of the resource information through the consensus mechanism to ensure that the data has not been tampered with.

[0130] S130, automatically execute the intelligent contract resource allocation, and generate a resource allocation plan according to the benefits and energy consumption of the blockchain system.

[0131] In a possible implementation manner, the automatically executing the intelligent contract resource allocation and generating a resource allocation plan according to the benefits and energy consumption of the blockchain system specifically includes:

[0132] S1: Randomly generate an initial population, where the initial population contains different resource allocation plans between the target vehicle and the second roadside unit node, and each individual in the initial population is a preset resource allocation plan.

[0133] First, according to the resource demand information of the target vehicle and the source supply capacity of the second roadside unit node, randomly generate an initial population. Each individual (solution) represents a resource allocation plan, including the allocation details of computing tasks, such as resource quantity, allocation path, time arrangement, etc. The size of the initial population is determined by system parameters to ensure the diversity of the population.

[0134] S2: Determine the system total benefit objective function and the system total energy consumption objective function of each individual in the blockchain system. The system total benefit includes the cost and revenue of resources, and the system total energy consumption includes transmission and computing energy consumption.

[0135] Among them, the system total benefit objective function is specifically determined by the following formula:

[0136]

[0137] Among them, is the system total benefit, τ is to balance the contributions of different parts to the system total benefit, Φ is the cost of purchasing resources, is the quantity of resources purchased by the buyer, ε is the revenue from selling resources, represents the quantity of resources sold at time t, represents the block packaging revenue of the block manager at time t, represents the reward of the verification node at time t.

[0138] In the formula, Describe the economic benefits of resource trading. The cost paid by the buyer for the resource reduces the system benefits, so it is represented by a negative sign. The seller obtains revenue by selling the resource, increasing the system benefits. Describe the revenue of blockchain-related participants. The revenue obtained by the block manager for packing blocks and the rewards obtained by the verification nodes for block verification together increase the system benefits. By dynamically monitoring the quantity of resources purchased by the buyer and sold by the seller, as well as the revenue of the block manager and verification nodes, the smart contract calculates the total system benefits according to the trading and reward rules. The optimization goal is to maximize the total system benefits.

[0139] The total system energy consumption objective function is determined by the following formula:

[0140]

[0141] Where, is the total system energy consumption, η is the effective capacitance parameter of the chipset, is the computing frequency that the roadside unit node can provide, is the computing delay of the target vehicle, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, p is the transmission power, is the number of computing tasks, is the block size transmitted and downloaded during the k-th block verification process, is the link channel bandwidth, is the link channel gain, is the Gaussian noise power.

[0142] In the formula, represents the computing energy consumption, which increases with the square of the computing frequency. represents the channel transmission energy consumption, including the energy consumption of the number of tasks and the block size. The channel transmission rate is calculated by the Shannon formula, considering the bandwidth, transmission power, channel gain, and noise power. By calculating the computing delay, transmission delay, and energy consumption of the target vehicle and the roadside unit node, combined with communication channel parameters (such as bandwidth, channel gain, noise power), the system evaluates the total energy consumption in real time. The optimization goal is to minimize the total system energy consumption.

[0143] For the calculation formula of the above total system energy consumption objective function, the calculation process of some parameters is as follows:

[0144] Calculate the uplink transmission rate at which the target vehicle uploads resource demand information to the roadside unit node based on the uplink channel bandwidth of the communication from the target vehicle to the roadside unit node, the vehicle transmission power of the target vehicle, and the uplink channel gain from the target vehicle to the roadside unit node. Specifically, it is calculated using the following formula:

[0145]

[0146] Wherein, is the uplink channel bandwidth, is the vehicle transmission power, is the uplink channel gain, is the Gaussian noise power. The uplink refers to the communication link through which data is uploaded from the user equipment (vehicle) to the infrastructure (roadside unit node). Based on the Shannon formula, it is used to calculate the maximum data transmission rate of the uplink. The channel bandwidth determines the spectral range that can be transmitted, is the signal-to-noise ratio, which is jointly determined by the vehicle's transmission power, channel gain, and noise. The data transmission rate has a logarithmic relationship with the signal-to-noise ratio: the higher the signal-to-noise ratio, the greater the transmission rate.

[0147] Calculate the uplink transmission delay based on the uplink transmission rate. Specifically, it is calculated using the following formula:

[0148]

[0149] Wherein, is the downlink transmission delay, is the task size included in the resource demand information, is the downlink transmission rate. The transmission delay is the ratio of the task size to the transmission rate. The larger the task size or the smaller the transmission rate, the longer the delay. The summation of the task sizes in the formula represents the case of combined processing of multiple tasks.

[0150] Calculate the computing delay based on the amount of tasks that the target vehicle needs to offload to the roadside unit node and the computing task processing rate of the target vehicle. Specifically, it is calculated using the following formula:

[0151]

[0152] Wherein, is the computing delay, is the amount of tasks, and U is the number of CPU cycles required for the target vehicle to process each bit of task volume input data, is the computing task processing rate. The computing delay is equal to the total amount of task data multiplied by the number of CPU cycles required per bit, and then divided by the processing rate, Represents the total amount of computation required for the task. The higher the processing rate of the computing task, the lower the computing latency.

[0153] Based on the downlink channel bandwidth from the target vehicle to the roadside unit node, the node transmission power of the roadside unit node, and the downlink channel gain from the target vehicle to the roadside unit node, calculate the downlink transmission rate at which the target vehicle uploads resource demand information to the roadside unit node. Specifically, it is calculated through the following formula:

[0154]

[0155] Where, is the downlink transmission rate, is the downlink channel bandwidth, is the node transmission power, is the downlink channel gain, is the Gaussian noise power. The downlink refers to the communication link through which data is transmitted from the infrastructure (roadside unit node) to the user equipment (vehicle). Similar to the calculation of the uplink transmission rate, the downlink transmission rate is calculated based on the Shannon formula. The difference lies in that the signal source is the roadside unit, and its transmission power and channel gain may be different from those of the vehicle.

[0156] According to the task size included in the resource demand information and the downlink transmission rate, calculate the downlink transmission latency. Specifically, it is calculated through the following formula:

[0157]

[0158] Where, is the downlink transmission latency, is the task size included in the resource demand information, is the downlink transmission rate. The latency is also calculated based on the ratio of the task size and the transmission rate. The signal characteristics of the downlink may be different from those of the uplink, so it needs to be calculated separately.

[0159] According to the uplink transmission latency, the computing latency, and the downlink transmission latency, calculate the average response time of the target vehicle to the roadside unit node for processing the task request. Specifically, it is calculated through the following formula:

[0160]

[0161] Where, is the average response time of the processing task request, is the uplink transmission latency, is the computing latency, is the downlink transmission delay. The average response time is equal to the sum of the time for uplink transmission, the calculation process, and downlink transmission. It measures the total time delay from the task request to the result return.

[0162] S3: Perform non-dominated sorting on each individual to find the crowding degree of each individual;

[0163] For all individuals in the population, sort them according to the objective function values. The sorting of each individual is based on its superiority in two objectives: the total system benefit and the total system energy consumption. A non-dominated solution means that no other individual is superior to this solution in both objectives. Calculate the neighborhood distance of each individual in the objective space (i.e., the distribution density with other solutions). The crowding degree reflects the sparsity of the individual in the objective function value space and is used to maintain the population diversity. Each individual has multiple objective function values (such as the total system benefit and the total system energy consumption). These values define the quality of the solution. Perform non-dominated sorting on all individuals in the population to divide them into different levels (Pareto fronts). For individuals in the same level, sort them according to the objective function values. Calculate the neighborhood distance of the individual in the objective space, that is, the gap between the individual and the adjacent individuals before and after. The higher the crowding degree of an individual, the sparser the distribution of the solutions around it, and it is preferentially retained to enhance the diversity of the solutions.

[0164] S4: According to the calculation result of the crowding degree, use the tournament selection method to select target individuals that meet the preset fitness from multiple individuals;

[0165] Randomly select several individuals from the current population for a "tournament". Preferentially select individuals with a higher non-dominated sorting rank and a lower crowding degree as target individuals to enter the next generation. Tournament selection is a competition-based individual selection strategy used to select individuals that meet the fitness requirements from the current population. Randomly select a certain number of individuals from the population, usually 2 or more, to form a subset. Compare the individuals in the subset and select a winner according to the preset fitness including non-dominated sorting and crowding degree. Repeat the above process until the required number of target individuals is selected.

[0166] Specifically, randomly draw a certain number of individuals from the current population to form a subset, that is, the tournament pool. First, compare the non-dominated sorting ranks and select the individual with a higher rank. If two individuals are at the same rank, then compare the crowding degrees and select the individual with a higher crowding degree. The individual who wins the tournament is selected as the target individual and enters the next-generation population. Repeat the above steps multiple times until enough target individuals are selected.

[0167] S5: Perform crossover and mutation operations on the target individuals to generate a new candidate population;

[0168] Cross the details of the resource allocation plan for the target individual, such as the allocation path, resource quantity, etc. Two parent individuals exchange part of their genes to generate new candidate solutions, increasing the diversity of the solutions. Randomly change some genes of the candidate solutions (such as adjusting the path of task allocation or the resource quantity). The mutation rate is controlled by system parameters and is used to explore better solutions.

[0169] S6: Combine the initial population and the candidate population to obtain a combined population;

[0170] Combine the initial population and the newly generated candidate population to form a larger combined population, which contains all the solutions of the current generation.

[0171] S7: Select the individuals in the combined population that meet the preset fitness according to non-dominated sorting and crowding degree to form a new population;

[0172] Perform non-dominated sorting on the combined population and recalculate the crowding degree.

[0173] Select the individuals that meet the preset fitness (such as a better balance between benefit and energy consumption) to form the next generation population.

[0174] S8: Repeat steps S1 to S7 until the preset number of iterations is reached or the convergence condition is met, obtain and output the target solution set, and get the resource allocation plan.

[0175] Repeat the above steps to optimize the population generation by generation. The smart contract records the non-dominated solutions of each generation and tracks the optimal solution during the iteration process. When the preset number of iterations is reached, or the objective function value of the population converges (that is, the change of the solution tends to be stable). The finally output solution set is the Pareto front, which contains multiple optimal solutions that meet the balance between system benefit and energy consumption. The system selects an optimal solution from the solution set as the resource allocation plan according to the requirements of the target vehicle.

[0176] S140. According to the resource allocation plan, the third roadside unit node among multiple second roadside unit nodes returns the calculation result for the resource demand information to the target vehicle. After verifying the integrity and correctness of the calculation result, the target vehicle uploads the transaction data and the reputation value for the third roadside unit node to the blockchain system.

[0177] According to the resource allocation plan, the third roadside unit node among multiple second roadside unit nodes is selected to execute the calculation task of the target vehicle. The third roadside unit node uses its calculation module to process the task and completes data analysis, calculation or information processing according to the requirements. After the task is completed, a calculation result is generated and a preliminary integrity verification is performed, including error detection and redundancy check.

[0178] Then, use the private key of the third roadside unit node to digitally sign the calculation result to ensure the source and integrity of the result. If sensitive data is involved, the public key of the target vehicle can be used to encrypt the calculation result to ensure transmission security. The third roadside unit node sends the calculation result to the target vehicle through the downlink. The transmission adopts the encrypted communication mechanism of the blockchain network to prevent data leakage or tampering.

[0179] Use the private key of the target vehicle to decrypt the received calculation result, verify the digital signature of the third roadside unit node, and ensure the authenticity and integrity of the calculation result. According to the task requirements, the target vehicle checks whether the result meets the expectations through local calculation or preset verification methods. If the result is found to be incorrect or does not meet the requirements, the target vehicle will reject the result and record the anomaly.

[0180] In a possible implementation manner, after the third roadside unit node among multiple second roadside unit nodes returns the calculation result for the resource demand information to the target vehicle according to the resource allocation scheme, the method further includes: if the blockchain system determines that the priority of the target vehicle reaches the preset priority, set the voting right of the target vehicle so that the target vehicle can participate in node election; based on the result of the node election, multiple roadside unit nodes are divided into active nodes and standby nodes according to the trust value and voting right. Among them, the active nodes take turns as block managers, responsible for packing and publishing data blocks, and at the same time encourage highly productive roadside unit nodes to participate in data verification and become verification nodes. The verification nodes review the data content through local and mutual verification processes and send the verification results to the block manager within the specified time. The block manager adds the verified data block to the blockchain system.

[0181] Specifically, if the target vehicle reaches the preset priority and obtains the voting right to participate in node election, the priority is divided according to the vehicle use, specifically:

[0182] Emergency and special-purpose vehicles, including vehicles performing emergency tasks such as ambulances and fire trucks, and vehicles transporting specific materials such as oil tankers and trailers. Both types of vehicles bear important social responsibilities and need to obtain communication and resources preferentially in case of emergencies to ensure emergency safety and the normal operation of infrastructure.

[0183] Public service vehicles, including logistics trailers, express delivery trucks, etc., which are logistics vehicles supporting social logistics and transportation needs, and public buses, tourist buses, etc., which are vehicles providing public transportation services. Both types of vehicles provide public services to society and need to obtain better communication conditions in case of network congestion to maintain the normal operation of the social transportation system and logistics transportation.

[0184] Commercial and private vehicles, including online car-hailing, taxis, etc., commercial sedans providing commercial travel services and private cars mainly used for personal travel needs. These two types of vehicles mainly provide convenience for individuals and have a relatively low priority. Usually, they will only obtain additional priority when network resources are sufficient.

[0185] In the embodiments of the present application, emergency and special-purpose vehicles are classified as priority level 1, public service vehicles are classified as priority level 2, and commercial and private vehicles are classified as priority level 3.

[0186] According to the trust value and voting right, roadside unit nodes are divided into active nodes and standby nodes, and active nodes take turns as block managers. Active nodes take turns as block managers, responsible for packing and publishing blocks, and motivating high-productivity nodes to participate in block verification. Verification nodes review the block content through local and mutual verification processes, send the verification results to the block manager within k timestamps, and finally the block manager adds the verified blocks to the blockchain through the blockchain verification module.

[0187] Furthermore, the target transportation vehicle retrieves the historical interaction data between itself and the third roadside unit node, including information such as transaction completion status and task response time, and reads the recommended values of other roadside unit nodes for the third roadside unit node from the blockchain to evaluate its overall credibility. Based on the interaction records and recommended values, calculate the reputation value of the third roadside unit node at the current moment. Specifically, it is calculated through the following formula:

[0188]

[0189] Among them, represents the reputation value at time t, represents the historical reputation value at time t - 1, k represents the number of newly added verifications from the previous moment to this moment, is the reputation weight, represents the total number of verifications. The reputation value increases with time, and reflects the positive contribution of the third roadside unit node in the current period through the number of newly added verifications and the weight. To prevent the reputation value from expanding rapidly, the growth rate is limited by the total number of verifications. And by calculating the result of with the maximum value in 1, ensure that the reputation value is not less than 1 and maintain the lowest reputation baseline.

[0190] Among them, the historical reputation value is specifically calculated through the following formula:

[0191]

[0192] Where, ra(t) is the historical credit value at time t, ra(t - 1) is the historical credit value at time t - 1, ψ is the weight parameter, and β is the transmission delay weight parameter of the target vehicle. The historical credit value is adjusted based on the previous historical credit value, reflecting the long-term evolution trend of the credit. By adjusting the weight parameter, the contributions of the historical credit value and real-time adjustment are balanced. The transmission delay weight parameter reduces the credit value weight of unstable or inefficient nodes.

[0193] The transmission delay weight parameter is specifically calculated by the following formula:

[0194]

[0195] Where, β is the transmission delay weight parameter, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, is the average response time of the processing task request from the target vehicle to the roadside unit node.

[0196] This embodiment also discloses a resource allocation system in a vehicle-to-everything network based on blockchain. Referring to Figure 2 , the system includes an acquisition module 201, a processing module 202, and an output module 203, where:

[0197] The acquisition module 201 is configured to upload the resource demand information of the target vehicle to the first roadside unit node. The target vehicle is a vehicle that requires computing resources, and the first roadside unit node is the roadside unit node closest to the target vehicle among the multiple roadside unit nodes included in the blockchain system.

[0198] The acquisition module 201 is configured to acquire the resource demand information uploaded by the first roadside unit node, and the available resource information uploaded by multiple second roadside unit nodes respectively. The second roadside unit nodes are the roadside unit nodes among the multiple roadside unit nodes that have the resource supply ability.

[0199] The processing module 202 is configured to automatically execute the intelligent contract resource allocation, and generate a resource allocation plan according to the benefits and energy consumption of the blockchain system. The resource allocation plan includes the trading and allocation methods for the available resource information of multiple second roadside unit nodes, the quantity of resources, and the information of all parties to the transaction.

[0200] The output module 203 is configured to, according to the resource allocation plan, the third roadside unit node among the multiple second roadside unit nodes returns the calculation result for the resource demand information to the target vehicle. After verifying the integrity and correctness of the calculation result, the target vehicle uploads the transaction data and the credit value for the third roadside unit node to the blockchain system.

[0201] In a possible implementation, the processing module 202 is configured to set the voting right of the target vehicle if it is determined that the priority of the target vehicle reaches a preset priority, so that the target vehicle can participate in node election.

[0202] The processing module 202 is configured to divide multiple roadside unit nodes into active nodes and standby nodes based on the result of node election according to the reputation value and the voting right. Among them, the active nodes take turns as block managers, responsible for packing and publishing data blocks, and at the same time encourage high-productivity roadside unit nodes to participate in data verification and become verification nodes. The verification nodes review the data content through local and mutual verification processes and send the verification results to the block manager within a specified time. The block manager adds the verified data block to the blockchain system.

[0203] In a possible implementation, the acquisition module 201 is configured to retrieve the interaction record between the target vehicle and the third roadside unit node and obtain the recommendation values of multiple roadside unit nodes for the third roadside unit node.

[0204] The processing module 202 is configured to calculate the reputation value of the third roadside unit node based on the interaction record and the recommendation values. Among them, the calculation of the reputation value is performed using a multiple weight model, and the calculation factors include familiarity, timeliness, and interaction enthusiasm.

[0205] In a possible implementation, the processing module 202 is configured to randomly generate an initial population, which includes different resource allocation schemes between the target vehicle and the second roadside unit node, and each individual in the initial population is a preset resource allocation scheme.

[0206] The processing module 202 is configured to determine the system total benefit objective function and the system total energy consumption objective function of each individual in the blockchain system. The system total benefit includes the cost and revenue of resources, and the system total energy consumption includes transmission and computing energy consumption.

[0207] The processing module 202 is configured to perform non-dominated sorting on each individual and find the crowding degree of each individual.

[0208] The processing module 202 is configured to select target individuals that meet the preset fitness from multiple individuals using the tournament selection method according to the calculation result of the crowding degree.

[0209] The processing module 202 is configured to perform crossover and mutation operations on the target individuals to generate a new candidate population.

[0210] The processing module 202 is configured to combine the initial population and the candidate population to obtain a combined population.

[0211] The processing module 202 is configured to select individuals in the combined population that meet the preset fitness according to non-dominated sorting and crowding degree, so as to form a new population.

[0212] The processing module 202 is configured to repeat the above steps until the preset number of iterations is reached or the convergence condition is met, obtain and output the target solution set, and obtain the resource allocation scheme.

[0213] In a possible implementation manner, the processing module 202 is configured to determine the system total benefit objective function and the system total energy consumption objective function of each individual in the blockchain system. The system total benefit objective function is specifically determined by the following formula:

[0214]

[0215] where is the system total benefit, τ is to balance the contributions of different parts to the system total benefit, Φ is the cost of purchasing resources, is the quantity of resources purchased by the buyer, ε is the income from selling resources, represents the quantity of resources sold at time t, represents the block packaging income of the block manager at time t, represents the reward of the verification node at time t.

[0216] The system total energy consumption objective function is determined by the following formula:

[0217]

[0218] where is the system total energy consumption, η is the effective capacitance parameter of the chipset, is the computing frequency that the roadside unit node can provide, is the computing delay of the target vehicle, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, p is the transmit power, is the number of computing tasks, is the block size transmitted, downloaded, and uploaded during the k-th block verification process, is the link channel bandwidth, is the link channel gain, is the Gaussian noise power.

[0219] In a possible implementation, the processing module 202 is configured to calculate the uplink transmission rate at which the target vehicle uploads resource requirement information to the roadside unit node based on the communication uplink channel bandwidth from the target vehicle to the roadside unit node, the vehicle transmission power of the target vehicle, and the uplink channel gain from the target vehicle to the roadside unit node.

[0220] The processing module 202 is configured to calculate the uplink transmission delay based on the uplink transmission rate.

[0221] The processing module 202 is configured to calculate the computing delay based on the amount of tasks that the target vehicle needs to offload to the roadside unit node and the computing task processing rate of the target vehicle.

[0222] The processing module 202 is configured to calculate the downlink transmission rate at which the target vehicle uploads resource requirement information to the roadside unit node based on the communication downlink channel bandwidth from the target vehicle to the roadside unit node, the node transmission power of the roadside unit node, and the downlink channel gain from the target vehicle to the roadside unit node.

[0223] Calculate the downlink transmission delay according to the task size included in the resource requirement information and the downlink transmission rate.

[0224] The processing module 202 is configured to calculate the average response time of the processing task request from the target vehicle to the roadside unit node according to the uplink transmission delay, the computing delay, and the downlink transmission delay.

[0225] In a possible implementation, the processing module 202 is configured to calculate the reputation value of the third roadside unit node based on the interaction record and the recommended value, specifically calculated by the following formula:

[0226]

[0227] where represents the reputation value at time t, represents the historical reputation value at time t - 1, k represents the number of newly added verifications from the previous moment to this moment, is the reputation weight, represents the total number of verifications, and the historical reputation value is specifically calculated by the following formula:

[0228]

[0229] where ra(t) is the historical reputation value at time t, ra(t - 1) is the historical reputation value at time t - 1, ψ is the weight parameter, β is the transmission delay weight parameter of the target vehicle, and the transmission delay weight parameter is specifically calculated by the following formula:

[0230]

[0231] where β is the transmission delay weight parameter, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, is the average response time of the processing task request from the target vehicle to the roadside unit node.

[0232] It should be noted that: when the system provided in the above embodiment realizes its functions, only the division of the above functional modules is used for illustration. In practical applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiment belong to the same concept. For the specific implementation process, please refer to the method embodiment, which will not be elaborated here.

[0233] This embodiment also discloses an electronic device. Referring to Figure 3 , the electronic device may include: at least one processor 301, at least one communication bus 302, a user interface 303, a network interface 304, and at least one memory 305.

[0234] Among them, the communication bus 302 is used to realize the connection and communication between these components.

[0235] Among them, the user interface 303 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 303 may further include a standard wired interface and a wireless interface.

[0236] Among them, the network interface 304 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).

[0237] Among them, the processor 301 may include one or more processing cores. The processor 301 connects various parts within the entire server through various interfaces and lines. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 305, and by invoking the data stored in the memory 305, it executes various functions of the server and processes data. Optionally, the processor 301 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 301 may integrate a combination of one or several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor 301 and may be implemented separately by a single chip.

[0238] Among them, the memory 305 may include random access memory (RAM) and may also include read-only memory. Optionally, the memory includes a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store the data involved in the above-mentioned various method embodiments. Optionally, the memory 305 may also be at least one storage device located far from the aforementioned processor 301. As a computer storage medium, the memory 305 may include an operating system, a network communication module, a user interface 303 module, and an application program for a resource allocation method in a blockchain-based vehicle networking.

[0239] In Figure 3In the electronic device shown, the user interface 303 is mainly used to provide an interface for the user to input and obtain the data input by the user; and the processor 301 can be used to call the application program stored in the memory 305 for a resource allocation method in the vehicle networking based on blockchain. When executed by one or more processors 301, the electronic device is caused to execute the method as described in one or more of the above embodiments.

[0240] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be adopted in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0241] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0242] In several embodiments provided in this application, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point, the displayed or discussed coupling or direct coupling or communication connection to each other can be through some service interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical or other form.

[0243] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place, or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0244] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0245] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned memory 305 includes: various media such as USB flash drives, mobile hard disks, magnetic disks, or optical discs that can store program codes.

[0246] This application also discloses a computer-readable storage medium that stores instructions. When executed by one or more processors 301, it causes the electronic device to execute the method as described in one or more of the above embodiments.

[0247] The foregoing are only exemplary embodiments of the present disclosure and should not be used to limit the scope of the present disclosure. That is, any equivalent changes and modifications made in accordance with the teachings of the present disclosure still fall within the scope covered by the present disclosure. After considering the specification and the practice of the truth of the disclosure, those skilled in the art will easily think of other implementation schemes of the present disclosure. This application aims to cover any variations, uses, or adaptive changes of the present disclosure, and these variations, uses, or adaptive changes follow the general principles of the present disclosure and include the common general knowledge or conventional technical means in the technical field not recorded in the present disclosure. The specification and the embodiments are only regarded as exemplary, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. A method for allocating resources in an Internet of Vehicles based on blockchain, characterized in that: The method comprises: Uploading resource demand information of a target vehicle to a first roadside unit node, wherein the target vehicle is a vehicle that requires computing resources, and the first roadside unit node is a roadside unit node closest to the target vehicle among multiple roadside unit nodes included in the blockchain system; Acquire the resource demand information uploaded by the first roadside unit node and the available resource information uploaded by a plurality of second roadside unit nodes, where the second roadside unit node is a roadside unit node with resource supply capability among the plurality of roadside unit nodes; Automatically execute smart contract resource allocation, and generate a resource allocation plan according to the benefits and energy consumption of the blockchain system, wherein the resource allocation plan includes a transaction and allocation method for available resource information of a plurality of the second roadside unit nodes, the quantity of resources, and information of the transaction parties; According to the resource allocation scheme, a third roadside unit node among the plurality of second roadside unit nodes returns a calculation result for the resource demand information to the target vehicle, and the target vehicle uploads the transaction data and the reputation value for the third roadside unit node to the blockchain system after verifying the integrity and correctness of the calculation result; The automatic execution of smart contract resource allocation generates a resource allocation plan based on the benefits and energy consumption of the blockchain system, specifically including: S1: randomly generating a group of initial populations, wherein the initial population includes different resource allocation schemes between the target vehicle and the second roadside unit node, and each individual in the initial population is a preset resource allocation scheme; S2: Determine the total system benefit objective function and the total system energy consumption objective function of each individual in the blockchain system, where the total system benefit includes the cost and income of resources, and the total system energy consumption includes transmission and computing energy consumption; S3: Perform non-dominated sorting on each of the individuals to find out the crowding degree of each of the individuals; S4: According to the calculation result of the crowding degree, a tournament selection method is used to select a target individual that meets a preset fitness from the multiple individuals; S5: performing crossover and mutation operations on the target individuals to generate a new candidate population; S6: Combining the initial population with the candidate population to obtain a combined population; S7: selecting individuals that meet the preset fitness in the combined population according to the non-dominated sorting and crowding degree to form a new population; S8: Repeat steps S1 to S7 until a preset number of iterations is reached or a convergence condition is met, and a target solution set is obtained and output to obtain the resource allocation solution.

2. A method for allocating resources in a vehicle network based on blockchain according to claim 1, characterized in that: After the third roadside unit node among the plurality of second roadside unit nodes returns the calculation result of the resource demand information to the target vehicle according to the resource allocation scheme, the method further includes: If it is determined that the priority of the target vehicle reaches the preset priority, setting the voting right of the target vehicle so that the target vehicle can participate in the node election; Based on the result of the node election, the plurality of roadside unit nodes are divided into active nodes and standby nodes according to the reputation value and the voting rights, wherein the active nodes take turns as block managers, responsible for packaging and publishing data blocks, and at the same time incentivize high-productivity roadside unit nodes to participate in data verification and become verification nodes, the verification nodes review the data content through local and mutual verification processes, and send the verification results to the block managers within the specified time, and the block managers add the verified data blocks to the blockchain system.

3. The method for allocating resources in a vehicle network based on blockchain according to claim 1, characterized in that: After verifying the integrity and correctness of the calculation result, the target vehicle uploads the transaction data and the reputation value for the third roadside unit node to the blockchain system, which specifically includes: Retrieving the interaction record between the target vehicle and the third roadside unit node, and obtaining the recommended values ​​of a plurality of the roadside unit nodes for the third roadside unit node; Based on the interaction record and the recommendation value, a reputation value of the third roadside unit node is calculated, wherein the reputation value is calculated using a multiple weight model, and the calculation factors include familiarity, timeliness and interaction enthusiasm.

4. The method for allocating resources in a vehicle network based on blockchain according to claim 1, characterized in that: The system total benefit objective function and the system total energy consumption objective function of each individual in the blockchain system are determined, and the system total benefit objective function is specifically determined by the following formula: ； in, is the total benefit of the system, τ is the contribution of different parts to the total benefit of the system, Φ is the cost of purchasing resources, is the amount of resources purchased by the buyer, ε is the revenue from selling resources, represents the quantity of resources sold at time t, Represents the block packaging income of the block manager at time t, Represents the reward of the verification node at time t; The total energy consumption objective function of the system is determined by the following formula: ； in, is the total energy consumption of the system, η is the effective capacitance parameter of the chipset, is the calculation frequency that can be provided by the roadside unit node, is the calculated delay of the target vehicle, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, p is the transmission power, To calculate the number of tasks, is the size of the blocks downloaded and uploaded during the k-th block verification process, is the link channel bandwidth, is the link channel gain, is the Gaussian noise power.

5. The method for allocating resources in a vehicle network based on blockchain according to claim 4 is characterized in that: The method further comprises: Calculate the uplink transmission rate at which the target vehicle uploads the resource demand information to the roadside unit node based on the communication uplink channel bandwidth from the target vehicle to the roadside unit node, the vehicle transmission power of the target vehicle, and the uplink channel gain from the target vehicle to the roadside unit node; Based on the uplink transmission rate, calculating the uplink transmission delay; Calculating the computation delay based on the amount of tasks that the target vehicle needs to unload to the roadside unit node and the computation task processing rate of the target vehicle; Calculate the downlink transmission rate of the target vehicle uploading the resource demand information to the roadside unit node based on the downlink channel bandwidth from the target vehicle to the roadside unit node, the node transmission power of the roadside unit node, and the downlink channel gain from the target vehicle to the roadside unit node; Calculating the downlink transmission delay according to the task size included in the resource requirement information and the downlink transmission rate; The average response time of the processing task request from the target vehicle to the roadside unit node is calculated according to the uplink transmission delay, the calculation delay and the downlink transmission delay.

6. The method for allocating resources in a vehicle network based on blockchain according to claim 3 is characterized in that: The reputation value of the third roadside unit node is calculated based on the interaction record and the recommendation value, specifically by the following formula: ； in, represents the reputation value at time t, represents the historical reputation value at time t-1, k represents the number of new verifications from the previous time to this time, is the reputation weight, Represents the total number of verifications. The historical reputation value is calculated using the following formula: ； Wherein, ra(t) is the historical reputation value at time t, ra(t-1) is the historical reputation value at time t-1, ψ is the weight parameter, β is the transmission delay weight parameter of the target vehicle, and the transmission delay weight parameter is specifically calculated by the following formula: ； Wherein, β is the transmission delay weight parameter, is the uplink transmission delay from the target vehicle to the roadside unit node, is the downlink transmission delay from the target vehicle to the roadside unit node, The average response time of the processing task request from the target vehicle to the roadside unit node.

7. A resource allocation system in an Internet of Vehicles based on blockchain, characterized in that: The system comprises an acquisition module (201), a processing module (202) and an output module (203), wherein: The acquisition module (201) is used to upload resource demand information of a target vehicle to a first roadside unit node, wherein the target vehicle is a vehicle that requires computing resources, and the first roadside unit node is a roadside unit node that is closest to the target vehicle among a plurality of roadside unit nodes included in the blockchain system; The acquisition module (201) is used to acquire the resource demand information uploaded by the first roadside unit node and the available resource information uploaded by a plurality of second roadside unit nodes, wherein the second roadside unit node is a roadside unit node with resource supply capability among the plurality of roadside unit nodes; The processing module (202) is used to automatically execute smart contract resource allocation, generate a resource allocation plan according to the benefits and energy consumption of the blockchain system, and the resource allocation plan includes a transaction and allocation method for available resource information of a plurality of second roadside unit nodes, the quantity of resources and information of the transaction parties; The output module (203) is used for returning the calculation result of the resource demand information to the target vehicle by a third roadside unit node among the plurality of second roadside unit nodes according to the resource allocation scheme, and the target vehicle uploads the transaction data and the reputation value of the third roadside unit node to the blockchain system after verifying the integrity and correctness of the calculation result; A processing module (202) is used to randomly generate a set of initial populations, the initial populations comprising different resource allocation schemes between the target vehicle and the second roadside unit node, and the initial populations comprising each individual as a preset resource allocation scheme; A processing module (202) is used to determine the system total benefit objective function and the system total energy consumption objective function of each individual in the blockchain system, where the system total benefit includes the cost and income of resources, and the system total energy consumption includes transmission and computing energy consumption; A processing module (202) is used to perform non-dominated sorting on each individual to find out the crowding degree of each individual; A processing module (202) is used to select a target individual that meets a preset fitness from a plurality of individuals using a tournament selection method according to the calculation result of the crowding degree; A processing module (202) is used to perform crossover and mutation operations on target individuals to generate a new candidate population; A processing module (202) is used to combine the initial population with the candidate population to obtain a combined population; A processing module (202) is used to select individuals that meet a preset fitness in the combined population according to the non-dominated sorting and the crowding degree to form a new population; The processing module (202) is used to obtain and output a target solution set until a preset number of iterations is reached or a convergence condition is met, thereby obtaining a resource allocation solution.

8. An electronic device, characterized in that: The electronic device comprises a processor (301), a communication bus (302), a user interface (303), a network interface (304) and a memory (305), wherein the memory (305) is used to store instructions, the user interface (303) and the network interface (304) are both used to communicate with other devices, the communication bus (302) is used to realize connection and communication between components in the electronic device, and the processor (301) is used to execute the instructions stored in the memory (305) so that the electronic device executes the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed, the method according to any one of claims 1 to 6 is performed.

Images