Internet of Vehicles Resource Scheduling Based on Blockchain and Game Theory

,


Introduction
In recent years, the Internet of things (IOT) [1][2][3][4] has attracted great attention from academia and the industry.Its applications in life can be seen everywhere, such as smart phones, tablet computers, smart TVs, and smart vehicles.As a key branch of the Internet of things, the Internet of vehicles (IOV) [5][6][7] has also become a key research eld and development direction concerned by all walks of life.e vigorous development of the Internet of vehicles has a strong foundation.It is safer, more environmentally friendly, and more convenient to drive.Functionally speaking, it can communicate and add more on-board entertainment, selfdiagnosis, and repair, which are the necessary conditions for the realization of unmanned driving.On a deeper level, if the Internet of vehicles is used to realize driverless, the car is not only a vehicle, but also a mobile space.In addition, the Internet of vehicles can also realize vehicle to everything (V2X), where x can be an entity or nonentity [8,9].However, with the rapid development of the Internet of vehicles, the data of the Internet of vehicles has also experienced a blowout growth in recent years [10][11][12][13][14]. Intel's Research Report on the amount of data used by Internet of vehicles users a few years ago pointed out that, in 2020, the amount of data used by a car that realizes automatic driving will be 4000 GB [15].At the same time, in the face of the huge and complicated number of vehicles and roads, plus the huge number of sensors, the Internet of vehicles puts forward high requirements for the processing delay of data tasks and network bandwidth resources.
Although the resource scheduling of mobile vehicles in IOV has many advantages, the current resource scheduling scheme still has many problems [16].Resource scheduling in IOV is mainly conducted through vehicle to vehicle (V2V) and vehicle to RSU (V2R).However, since V2V communication and V2R communication do not encrypt data, malicious nodes can intercept or even tamper with communication data in the process of data transmission [17].On the other hand, the information between entities participating in resource scheduling is opaque, RSUs located on the roadside are vulnerable to external attacks, and there is a lack of an effective trust mechanism between entities participating in resource scheduling.For the sake of privacy and data security, vehicles may not be willing to participate in the resource scheduling of IOV [18,19].Most importantly, there is a lack of an efficient resource scheduling mechanism in IOV, which can not meet the needs of the rapidly changing IOV resource scheduling market.To sum up, the current IOV resource scheduling including data sharing and computing task unloading mainly faces the following three challenges.

Unsafe Data Transmission.
During the process of data sharing and computing task unloading, the communication node does not encrypt the data, so the data is easy to be intercepted or even tampered by malicious nodes during transmission, which poses a serious threat to the data security of IOV.

Low Efficiency of the Centralized Dispatching System.
In the traditional IOV, the resource scheduling between vehicles is centrally controlled by the authority.Today, with the increasing scale of IOV, the centralized scheduling time and energy consumption are relatively large.On the other hand, if the dispatching organization is attacked, large-scale data leakage may occur, resulting in a series of uncontrollable events.

Lack of Efficient Resource Scheduling Mechanism.
e resource scheduling in IOV involves multiple entities involved in scheduling, which makes the process of resource scheduling very complex.is requires us to design an efficient resource scheduling strategy for the two resource scheduling scenarios of data sharing and computing task unloading to meet the needs of the IOV resource scheduling market.
In recent years, blockchain technology [20][21][22][23] has developed rapidly.Due to its characteristics of decentralization, anonymity, and trust, a large number of researchers have done more and more research work on the combination of blockchain and Internet of vehicles from different angles.
Blockchain is a chained data structure.Consensus nodes package transaction records into blocks and link blocks to the blockchain according to the time sequence of block generation.In fact, blockchain can be regarded as a distributed database, which uses encryption technology to ensure that data cannot be tampered with and forged.When the distributed nodes share data, each node can verify the validity of the transaction signature based on the public key in the distributed network to ensure the authenticity of the shared data.In addition, smart contract is also an important technology in blockchain.It is a commitment in digital form, including the specific algorithm to be executed and the algorithm execution conditions.After the smart contract is deployed, it will be automatically executed by computer programs.rough the smart contract blockchain, various distributed applications can be supported to achieve more complex functions.In addition, the blockchain will distribute digital currency rewards to the consensus nodes that have obtained the bookkeeping right, which can motivate the nodes to provide computing power and resources.
Blockchain can promote the establishment of a secure, mutual trust, and decentralized intelligent transportation network to solve the resource scheduling problem in IOV and help make better use of transportation infrastructure and resources.

System Model
We mainly study the mobile vehicle computing task unloading problem in the resource scheduling of the Internet of vehicles.At present, there are many researches on mobile vehicle computing task unloading, but there are still many problems in the existing schemes, such as vehicle privacy and data leakage, low system operation efficiency, inability to provide an effective incentive mechanism, and so on.
erefore, we propose a scheme for mobile vehicle computing task unloading and build a system framework based on the alliance blockchain.

System Entities.
Figure 1 is the model diagram of the mobile vehicle computing task offloading system based on the alliance blockchain [20][21][22][23] designed in this paper.e model mainly includes three classes of entities: trusted Authority (TA), roadside unit (RSU), and mobile vehicles.
e details of the functions of each entity in the system are as follows.

Trusted Authority (TA).
e function of the TA is the same as that of the TA introduced in Section 3.1, both of which deal with the registration and authentication of entities in the system and send a digital certificate, public key, and private key to the entity to ensure the security of entity data transmission.

Roadside Unit (RSU).
In the system model, the RSU acts as a vehicle computing task offloading agent responsible for hosting and directing the auction process to handle calculating resource scheduling problems.At the same time, RSU is also the consensus node of the alliance blockchain.A smart contract (Computation Offloading Smart Contract, COSC) that controls the offloading of vehicle computing tasks is deployed on the RSU.A copy of the alliance blockchain is saved on each RSU.ere are multiple RSUs beside the road, and the coverage radius is defined as RSUR.Similarly, all RSUs are carried out through communication cables, and mobile vehicles can communicate with RSUs through V2R wireless communication.

Mobile Vehicles.
Mobile vehicles with compute-intensive applications waiting to be offloaded act as buyers of 2 Mathematical Problems in Engineering computing resources.Vehicle users with idle computing resources can be rented to buyers to act as computing resource suppliers, i.e., sellers.Vehicles can communicate with the RSU through V2R, and the vehicles communicate through V2V. e vehicle also has a wallet for storing resource coins and a virtual identity for privacy protection.
As shown in the system model diagram in Figure 1, the smart contract COSC divides each RSU and the mobile vehicles within its communication range into a network area according to the communication range R RSU of each RSU, and the network area is named regional computation o oading network (RCON).As the regional manager of an RCON, each RSU manages the o oading of vehicle computing tasks in the RCON and acts as a consensus node of the alliance blockchain on the other hand.RSU will package the transaction records into blocks and pass the corresponding consensus mechanism to link the block to the consortium blockchain.In addition, RCONs are connected by cable, and the same is true between RCONsand the edge server cloud, and they can all communicate with each other.Vehicles can o oad computing tasks to other vehicles with spare computing resources in the same RCON through RSU scheduling or o oad computing tasks to edge cloud servers through RSU.We focus on the case where a vehicle o oads computational tasks to a nearby moving vehicle.

Basic Assumptions of the Computing Task O oading
Model.
e research on computing task o oading [24][25][26] of mobile vehicles will be based on the following assumptions: (1) First, consider the communication between model entities.Figure 1 shows that wired communication between RCONs and between RCONs and edge cloud servers will be carried out through cables.e communication between them does not need to consider the e ect of communication range.e V2R communication between the RSU and the vehicle is a ected by the communication range RSUR of the RSU.In contrast, the communication between them does not need to consider the e ect of communication range.V2R communication between RSU and vehicle is a ected by RSU's communication range R RSU .At the same time, only when the reliability of data transmission can be guaranteed by one-hop V2V connection the calculation o oad can be performed between the two vehicles; otherwise, there may be data loss during the transmission process.
(2) We also assume that time is time-slotted and studies the computing task o oading strategy of moving vehicles in a speci c period.(3) Assuming there is a lack of information in the computing task o oading market, the RSU and buyer cannot know the seller's bid, and the seller cannot know the bids of other sellers.RSU manages the computing task o oading market through the smart contract COSC of the alliance blockchain.RSU will not favor any buyer or seller, nor can it refuse to help any vehicle that wants to participate in computing task o oading.In addition, due to the  characteristics of the consortium blockchain system, various entities cannot collude with each other.(4) In the process of computing task offloading, one buyer can only uninstall its application to one seller, but one seller can provide services for multiple buyers.At the same time, since the computing task offloading scheme proposed applies to all RCONs, to simplify the discussion, in the follow-up work, we will take an RCON as an example to study computing task offloading.(5) It is assumed that a computing task can be divided into a computing program with fixed data size.is computing program is the smallest unit of computing task division.

The Specific Process of Computing Task Offloading
e particular process of vehicle computing task offloading is shown as follows.

System Initialization.
All entities must be registered with TA and submit a certain amount of resource coins as a deposit to the account under the supervision of TA. en download the latest data information from the nearby alliance blockchain nodes' storage pool to synchronize the entity system's state, which will not be repeated here.

Both Buyers and Sellers Submit Relevant Information to RSU.
In RCON, buyers and sellers of vehicles who intend to participate in the offloading of computing tasks will submit relevant information to RSU.
e information submitted by the buyer's vehicle b i can be described by vector , where sign B i marks the vehicle b i as the buyer.at is, it needs external computing resources to unload its intensive computing tasks, d i is the data amount of computing tasks that need to be unloaded by vehicle b i , and v B i and l B i are the current speed and position of vehicle bi; on the other hand, the information vector submitted by the seller's vehicle s j can be expressed as I s j � sign S j , c j , v S j , l S j , p j , r j  , where sign S j represents that the vehicle s j is the seller.at is, the vehicle s j has redundant computing resources and is willing to provide computing task offloading services for other vehicles, c j is the computing power of the vehicle s j , described by the number of CPU cycles per second of the vehicle, v S j and l S j are the current speed and position of the vehicle s j , and p j is the bid of the vehicle s j to process the application data of one computing task.r j represents the idle computing resources of vehicle s j virtualized as resource blocks (CPU cycles).
In addition, it should be noted that all buyers and sellers participating in the offloading of computing tasks are within the communication range R RSU of RSU.erefore, their information can be sent to RSU through V2R.At the same time, it is assumed that the RCON contains and m sellers S � s 1 , S 2 , . . ., s m  ; these vehicles have the same communication range R V .

RSU Calculates the Scheduling Results and Publishes the
Results to Both Buyers and Sellers.After receiving the relevant information about the buyer's vehicle and the seller's vehicle, the RSU will extract and integrate the information, and then according to the reverse auction mechanism proposed in this chapter, the RSU will match buyers and sellers and send the best match results back to buyers and sellers.

Unloading and Payment of Computing
Tasks.After receiving the scheduling result of RSU, the buyer's vehicle will directly unload the computing task to the seller's vehicle through one-hop V2V.After the seller's vehicle completes the calculation, it will return the calculation result to the buyer.Since the data size of the application result is much smaller than the input data, the result feedback delay can be further ignored.
After the buyer confirms the receipt of the calculation result, the buyer will forward a resource currency to the corresponding seller's vehicle through its wallet as the cost of unloading the calculation task.At the same time, the buyer sends a transaction completion message to the RSU.When the seller receives the fee, a transaction completion message will also be sent to RSU, which represents that the transaction has been completed.e transaction record will be placed in the RSU memory pool and broadcast to the entire network, waiting to be added to the block.
If there is any objection between the buyer and the seller during the transaction, for example, the buyer has not received the calculation result, the seller has not received the corresponding fee, etc., the objecting party can file a complaint with RSU, and RSU initiates verification of data transmission and wallet payment in the inspection network.For vehicles with cheating, RSU will deduct a part of the security deposit for the vehicle.
is mechanism can restrain some vehicles from doing damage to the interests of other vehicles for their own interests during the unloading process of computing tasks and ensure the stability of the system operation.

Blocks Are Generated and Linked to the Blockchain.
When generating the blockchain, this chapter proposes a new consensus mechanism based on the total amount of buyer computing task data received by all sellers in the RCON managed by each RSU node to elect the accounting node (Proof of Computation Resource, POCR).e RSU with the most significant amount of buyer computing tasks received by all sellers in the RCON area is elected as the accounting node within a block generation interval.
It should be noted that when an RSU successfully obtains the accounting right and generates a block link to the blockchain, the system will also distribute a certain amount of resource coins to it as a reward.RSU will distribute resource coins proportionally to the seller as a reward according to the contribution of the seller's vehicle's computing resources in the process of computing task offloading to encourage them to continue to participate in computing tasks offloading.at is, the POCR consensus mechanism uses the total amount of buyer computing task data received by the seller to measure the seller's computing resource contribution.

Modeling and Solution
4.1.Modeling of the Reverse Auction Scheme.Consider a computing task offloading scenario in an RCON.Since there are multiple buyers and sellers in the RCON, buyers will compete for the seller's computing resources to complete computing tasks faster.erefore, this chapter will use the reverse auction method to match buyers and sellers to obtain the matching result that maximizes regional benefits.e actual meaning of the important parameters involved in the auction scheme is shown in Table 1.
Consider first the benefits of offloading the buyer's computing tasks.Since each seller's computing power is different, the utility benefits provided by each seller to the buyer are different.e benefit that the buyer b i can get by offloading the unit calculation data to the seller s j can be expressed by the following function: In formula ( 1), (δ/c EC + 1/T EC + θ) represents the time for the buyer ib to offload the unit computing task to the edge cloud server ECS, δ is the mapping of bits to CPU cycles, C EC is the computing power of the edge cloud server, T EC is the data transfer rate between the vehicle and the ECS, θ is the response delay due to network congestion or insufficient ECS performance, δ/c j + 1/T ij represents the time for the buyer b i to offload the unit computing task to the seller s j , and T ij represents the data transmission speed between the buyer b i and the seller s j .
To sum up, the time saved by the buyer b i offloading the unit computing task data to the seller s j compared to the time saved by the buyer b i offloading the unit computing task to the edge cloud server is the unit benefit of the buyer b i .
Next, consider the overall benefit of RCON.For Use R b i to denote a seller within the coverage of the buyer's b i communication.Use R s j to represent buyers who are within the seller's s j communication coverage.en, in a time slot, through the calculation and offloading of buyers and sellers, the overall regional benefit that RCON can obtain can be expressed as Here, η ij is used to the nature of the task of calibrating the buyer b i to the winning seller s j .When η ij � 1, the buyer b i can unload its application data to the seller s j through a one-hop V2V communication; otherwise, it cannot be uninstalled.For example, when the seller s j is not within the communication coverage of the buyer b i , or the seller s j has exhausted its idle computing resources, the situation of η ij � 0 will occur.d ij represents the amount of task data unloaded by the buyer b i to the seller s j .λ i is used to adjust the expected revenue of the buyer b i unloading unit data.When the importance of the calculation task or the timeliness requirement is high, the value of λ i is larger; this represents that the buyers are willing to pay a higher price to complete the current computing task faster.
Here, the limited value of constraint η ij ∈ 0, 1 { } can only be 0 or 1; that is, the unloading of computing tasks from buyer b i to seller js has only two states of success and failure;  m j�1 η ij ∈ 0, 1 { } represents that a buyer can only offload tasks to one seller; δ  n i�1 d ij η ij ≤ r j is used to prevent the total workload offloaded from the buyer from exceeding the computing resources that the seller can provide; ) determines the actual uninstall data from buyer b i to seller s j based on the smaller value between the two data, where Δt ij represents the real transmission time of the buyer b i offloading the computing task to the seller s j .

Reverse Auction Solution
Schemes.We will use the reverse auction method to solve the proposed computing task offloading problem and, at the same time, prove the authenticity of the seller's bid and the individual's rationality to verify the proposed scheme's rationality.
First, define a list of preferred options from the perspective of the administrator RSU and the buyer, respectively.For the auction manager RSU in RCON, according to the size of the value of formula (3), a list of its preference schemes is defined, and the list can be expressed by formula (4): where > RSU in formula (4) means that RSU is biased to match the buyer b i with the seller s j , rather than matching the buyer b i with other sellers within its communication range; because scheme (b i , s j ) can bring more benefits to RSU than other schemes, it maximizes the regional benefit of RCON.
Next, define a list of preferred options from the buyer's perspective.Also, according to the value of formula (3), the list of buyer's preference schemes defined here is where > b i in formula ( 5) means that the buyer b i prefers to match the seller s j rather than other sellers within its communication range, because the scheme (b i , s j ) can make the buyer b i obtain the maximum benefit.In the following, the lists L RSU and L b i are sorted in descending order according to the value of formula (3).At the same time, a virtual seller s j ′ is added at the end of the list L b i as a critical indicator for the following algorithm to use.e virtual seller s j ′ corresponds to the scheme of offloading computing tasks to ECS.
e buyer b i unloads the unit computing task revenue set to ω i � (λ i φ ij − p EC )d ij , where P EC refers to the unit computing resources ECS price.Here, we consider that all sellers' vehicle bids are lower than P EC , so sellers can attract buyers to offload computing tasks.e value of ω i is smaller than (λ i φ ij − p j )d ij for all real solutions in the list L b i .If no seller in the listing L b i wins the auction, the buyer b i offloads its computation to ECS.On the other hand, when (λ i φ ij − p j )d ij ≤ 0, it means that the buyer b i cannot benefit from the offloading of computing tasks.At this time, η ij � 0, the buyer b i will not offload computing tasks to the seller s j .
e reverse auction scheme proposed here consists of two parts, first, to determine the matching scheme of all buyers and sellers and, then, to determine the actual amount that the buyer should pay to the seller.In the matching process, the list L RSU plays a leading role; that is, the scheme will prioritize the matching scheme that can maximize the regional benefit in the actual operation process, although this may sacrifice the interests of some buyers.e auction algorithm is divided into three parts.e first is to set the algorithm's parameters, create lists L RSU and L b i , and sort the two lists in descending order according to the size of the (λ i φ ij − p EC )d ij value.is is followed by the matching phase, where buyers are matched with suitable sellers in the case of maximizing regional interest, based on listing L RSU , until all buyers are matched, or sellers run out of free resources.
e last is the payment stage.For the matching scheme (b i , s j ), after determining the actual payment amount p s j that the buyer b i should pay to the seller s j , the next seller  s j of s j in the list L b i is selected as the critical reference payment indicator.At this time, the payment amount p s j can be expressed as When the seller  s j is the last seller on the list L b i , the seller  s j is the virtual seller s j ′ at this time; we make is scheme includes n buyers and m sellers.So, the computational complexity of auction is O(n 2 m 2 ).e complexity of the algorithm is low, and the convergence can be achieved in a short time even when the scale of the vehicle network is large.

Consortium Blockchain Reward Modeling.
In generating the consortium blockchain, the RSU as the consensus node will compete for the accounting right through the POCR consensus mechanism proposed above.e RSU that has obtained the accounting right can not only package the transaction records into blocks and link them to the blockchain but also be rewarded with resource coins distributed by the blockchain system.After RSU is rewarded with resource coins, it will distribute resource coins to sellers according to the ratio of the total amount of computing task data unloaded by buyers within a block generation interval to the total amount received by all sellers in RSU.Here, the total amount of buyer computing task data received by the seller is used to measure the computing resource contribution of the seller.
e generation of new blocks in the POCR consensus mechanism includes three stages: mining, consensus, and distribution of rewards.In this chapter, "mining" refers to how sellers provide computing resources to buyers for buyers to offload computing tasks.After the "mining" process, the system counts the buyers received by all sellers in the RCON area managed by each RSU.e total amount of unloaded computing task data and the RSU with the largest total amount are elected as the accounting node.e next step is to enter the "consensus" stage.At this time, the accounting node packages part of the computing task by offloading records into a block and sending them to other RSU nodes for verification.After the verification is passed, the accounting node links the block to the blockchain.Next, in the "Distribute Rewards" stage, the system will distribute a certain amount of resource coins to the accounting node RSU as a reward.After RSU receives the resource currency distributed by the system, it will distribute resource currency rewards to each seller according to the number of computing resources contributed by each seller in RCON under its control to encourage sellers to continue to participate in computing resource scheduling.
e actual meanings of the important parameters are shown in Table 2.
e blockchain "distribute rewards" phase is modeled below.Assuming that there are z RCON areas in the current system, there are z consensus nodes RSU, the number of sellers' vehicles in the RSU numbered k, k ∈ [1, z], is m k , the seller numbered j, j ∈ [1, m k ], in the RCON corresponding to this RSU at the amount of buyer calculation task data 6 Mathematical Problems in Engineering received in the current block generation time slot is d j .e probability that the RSU number k successfully obtains the accounting right is and there is  z k�1 f RSU k � 1 here; that is, the sum of the probabilities of all RSUs being successfully elected as accounting nodes is 1.After RSU obtains the accounting rights and generates a block, it will immediately propagate the block on the network for verification to complete the consensus process.If the propagation and verification time is too long, the mined block becomes an orphan block and is abandoned by the blockchain.Here, the propagation delay of RSU number k as a "miner" is set to τ P k � ε k /c • μ, where ϵ k is the number of transactions in a block, c is a parameter related to network size, and μ is the average effective channel capacity per link.Since the verification of transactions requires a fixed amount of computation, this period is assumed to be linear with the number of transactions in the block; then this period can be expressed as τ v k � κ * ε k , where κ is a parameter determined by the size of the network and the average verification speed of nodes.Considering that the generation of new blocks follows a Poisson process, the probability that a block generated by a "miner" RSU k is orphaned is approximate as In the formula, the process parameter λ represents the complexity of the mining block.
e probability that the "miner" RSU k is successfully elected as a bookkeeping node and generates a block is Assuming that the remuneration (reward rate) per unit transaction in the alliance blockchain system is r resource coins, the reward obtained by generating a block with a transaction volume of ε k is rε k .en the benefit function of the reward obtained by the "miner" RSU k can be expressed as ) . ( For the resource currency reward obtained by the "miner" RSU k , the resource currency reward will be distributed to each seller according to the number of computing resources contributed by each seller in the RCON controlled by the RSU; then the seller j accepts the computing task unloading amount d j .en the reward function that seller j should get is expressed as At this point, the blockchain reward model is established.In the next section, we will analyze the system's performance through simulation.

Case Study
Here we will evaluate the performance of the proposed Internet of vehicles resource scheduling based on blockchain and game theory through simulation.First, we compare the proposed auction scheme with several types of baseline schemes to verify the scheme's performance.Second, we conduct a simulation evaluation of the blockchain reward model to verify its effectiveness.

Simulation Setting.
Since the calculation task offloading scheme using the reverse auction method applies to all RCONs, to simplify the discussion, we will first use an RCON as an example to conduct a simulation study on the reverse auction scheme.We use MATLAB2016A as the platform to simulate RCON with a network area of 500 m * 500 m, in which there are 5 roads in the east-west and north-south directions, and each road has 4 lanes.In RCON, an RSU is set up as the central broker, hosting and directing the auction process.On the other hand, this chapter also uses the blockchain open-source framework Hyperledger Fabric to write smart contracts to simulate the consortium blockchain system.
To evaluate the performance of the reverse auction scheme, the mobile vehicle computation offloading scheme based on consortium clockchain (scheme 0) is compared Mathematical Problems in Engineering with the following baseline schemes to evaluate the performance of scheme 0: (1) e fastest process scheme (scheme 1): in this scheme, assuming all sellers bid reasonably, buyers are always matched with the seller who can complete the application and calculate the offload fastest.If this seller runs out of idle resources, the buyer will be forced to find another seller for fast processing or offload computing tasks to edge cloud servers.(2) e lowest cost scheme (scheme 2): in this scheme, assuming that all sellers bid reasonably, buyers are always matched with the seller with the lowest asking price per unit calculation task.Similarly, when sellers run out of idle resources, buyers will be forced to find another low-priced seller or offload computing tasks to edge cloud servers.(3) First-come-first-served service (scheme 3): in this scheme, assuming that all sellers make reasonable bids, the buyer is always matched with the first seller to provide an offer.If this seller runs out of idle resources, the buyer will be forced to offload computing tasks to the edge cloud.Since the vehicles are randomly distributed in the simulation area, FCFS can be regarded as a random unloading scheme.(4) Offload to edge cloud scheme (scheme 4): buyers directly offload their computing tasks to edge cloud servers for processing.
In addition, for the proposed scheme, the function σ j � ac j + e is used here to represent the most reasonable bid of the buyer s j , where a and e are positive constants, and these two constants follow the unloading law of the market economy, which means that the buyer s j provides that the more the computing power, the greater the reasonable bid.
e settings of the relevant simulation parameters are shown in Table 3.

Vehicle Density Analysis.
We first analyze the impact of vehicle density within the RCON region on the overall benefit U(η ij ) of the region and on the average computing time of a single computing program (assuming that the computing task can be divided into computing programs with a fixed data size).
In the case of low and high vehicle flow levels, we simulated the scheme 50 times with different parameter values.We obtained the average value to cover various traffic conditions, making the conclusion more general.
Figures 2-5 show the changes of the average calculation time of a single calculation program and the regional overall benefit U(η ij ) with the number of sellers under low vehicle density (18 buyers and 22 buyers).
According to Figure 2 of Figure 3, we find that the average computing time of a single computing program in scheme 4 is always the highest. is is because when it is offloaded to the edge cloud, the edge cloud receives too many requests, resulting in that it cannot process the task of vehicle unloading in time, which causes a large delay in unloading.
e calculation time of a single calculation program of scheme 2 and scheme 3 gradually decreases with the increase of sellers because the buyer has more options at this time, and the buyer's task can be uninstalled faster.But these two schemes are still less efficient than scheme 0 and scheme 1.For scheme 0 and scheme 1 solutions, with the increase in the number of sellers, the computing resources are gradually sufficient, and the completion time of the unit calculation program gradually decreases.e performance of scheme 0 is close to scheme 1 of the fastest processing scheme, which reflects the superiority of the time performance of scheme 0.
According to Figures 4 and 5, it is found that, with the increase of the number of sellers, the overall regional benefit U(η ij ) of all schemes increases because with the rise in the number of sellers, more buyers can enjoy the calculation service and eventually reach relative stability where most buyers can be successfully matched to the right seller.At the same time, we found that, under low vehicle density, the U(η ij ) value of scheme 0 is higher than other schemes, the buyer's cost of scheme 1 is higher, and scheme 2 time cost is higher.However, the randomness of scheme 3 is high, and the performance level of these schemes is not high, which shows that scheme 0 can reasonably match buyers and sellers and maximize the regional benefits of RCON.
Figures 6-9 show the changes of the average calculation time of a single calculation program and the regional overall benefit U(η ij ) with the number of sellers under higher vehicle density (38 buyers and 42 buyers).
It can be seen from Figures 6 and 7 that the average calculation time of a single calculation program of scheme 4 is always the highest for the same reason as in the low flow case.For scheme 3 and scheme 2, the curve decreases slightly as more buyers access computing services as sellers increase.Likewise, the performance of scheme 0 is close to the timeoptimal scheme 1, which verifies the superiority of the temporal performance of scheme 0. At the same time, the average calculation time of a single calculation program for scheme 0, scheme 3, scheme 2, and scheme 1 decreased compared to the low-traffic case; as buyers had more Mathematical Problems in Engineering offloading options at higher vehicle densities, the processing time of its task will be shortened.Figures 8 and 9 compare the U(η ij ) values under each scheme.Considering various factors, the efficiency of scheme 0 maintains the highest level among multiple schemes.At the same time, compared with low-traffic scenarios, due to the increase in the number of vehicles, the total amount of unloading tasks increases, and the total regional benefit also increases.
To sum up, when considering the scenarios of low and high traffic flow, it can be seen that scheme 0 proposed in this chapter has a relatively high performance in the two performance indicators of task processing efficiency and overall regional benefit. is proves that the proposed reverse auction scheme can effectively match buyers and sellers.

Verification of the Authenticity of the Seller's Bid and
the Rationality of the Individual.Here we will verify the authenticity and individual rationality of the seller's bids proposed.To verify the authenticity of the seller's bid, we simulate the behavior of the randomly selected seller S random in reasonable and other unreasonable bids and calculate the graph of the seller's S random revenue changing with its bid, as shown in Figure 10.
As shown in Figure 10, when the seller's S random bid is less than its reasonable bid, the seller's S random can never get the maximum benefit.On the other hand, when the seller's bid reaches a reasonable price, the benefit of the seller's S random is maximized.Even if the seller's bid is greater than the reasonable price, its benefit will not increase.erefore, it can be proved that the seller will provide a reasonable price to the buyer according to the computing resources and will not provide other quotes; that is, the seller's bid is authentic.

Conclusions
With the rapid development of the automotive industry, vehicles equipped with a variety of intelligent on-board equipment need more and more resources.On the one hand, a large number of driving data will be generated during the driving process of vehicles, which are useful in traffic situation analysis, automatic driving training, and other scenarios.On the other hand, due to the high mobility of vehicles and because their own computing resources are limited and the real-time distribution of computing resources is irregular, it is easy to see that some vehicles have insufficient computing resources while others have spare computing resources.
rough the scheduling of mobile vehicle data and computing resources, the data and computing resources can be shared to the subjects who need them, and both parties involved in the sharing can benefit.For the resource scheduling of Internet of vehicles based on blockchain and game theory, this paper proposes a mobile vehicle computing task unloading scheme based on alliance blockchain.In the simulation phase, the performance of the calculated unloading scheme and several baseline schemes under different traffic flows is compared.e results show that the scheme in this paper has better performance than other schemes.
is research work still has many places that can be improved.For example, for the scheduling of data resources, artificial intelligence technology, big data, and other technologies can be used to filter vehicle data, reduce the proportion of duplicate or useless data in shared data, and improve the efficiency of data sharing.For the scheduling of computing resources, computing tasks can be unloaded to the edge cloud server and the surrounding mobile vehicles at the same time.How to reasonably control the amount of tasks unloaded to the edge cloud and mobile vehicles is also worth studying in the future.

Table 1 :
Parameter correspondence table.C EC e computing power of seller s j and edge server P j , P EC Bidding by seller s j and edge server for unit offload task L RSU , L b i List of preferred options between RSU and buyer b i

Table 2 :
e actual meanings of the important parameters.

Table 3 :
Simulation parameter settings.Figure 2: Change of average calculation time of a single calculation program with the number of sellers (18 buyers).Figure 3: Change of average calculation time of a single calculation program with the number of sellers (22 buyers).Figure 4: Change of average value of regional overall bene t with the number of sellers (18 buyers).Figure 5: Change of average value of regional overall bene t with the number of sellers (22 buyers).Figure 6: Change of average calculation time of a single calculation program with the number of sellers (38 buyers).Figure 7: Change of average calculation time of a single calculation program with the number of sellers (42 buyers).Figure 8: Change of average value of regional overall bene t with the number of sellers (38 buyers).Figure 9: Change of average value of regional overall bene t with the number of sellers (42 buyers).Figure 10: Authenticity veri cation of seller's bid.