Efficient Mobile Vehicle Data Sharing Scheme Based on Consortium Blockchain

Abstract

Efficient data sharing schemes are one of the key technologies in the Internet of Vehicles (IoV). However, the insufficient willingness of vehicle users to provide data makes the traditional blockchain-based IoV network have low throughput. The income of IoV providers decreases when the vehicle density increases on the road. In this paper, we investigated a mobile vehicle data sharing scheme based on the consortium blockchain. In detail, the consortium blockchain was used to limit the degree of decentralization and openness, and the optimal revenue strategy approach between vehicles and data-demand devices was obtained through the Stackelberg game. The load test library based on Node.js was used to simulate and compare the data transmission performance of the proposed consortium blockchain with traditional blockchain schemes. Simulation results show that the proposed scheme had higher buyer’s revenue, and the block transmission performance was significantly higher than that of traditional blockchain schemes.

1. Introduction

With the development of autonomous driving, massive data will be generated during vehicle movement, which will be collected and processed by scientific technologies and sent to the relevant entities via the Internet of Vehicles (IoV), to meet the requirements of driving model training or traffic management [1,2,3,4]. A moving vehicle on the road should exchange sensing data with the roadside units and surrounding vehicles, especially when the vehicle passes through intersections or the density of vehicles on the road is high. In order to encourage vehicles on the road to participate in data sharing, the IoV powered by blockchain is a suitable solution.

Nowadays, efficient data sharing in IoV has received widespread attention from both academia and industry [5,6,7,8,9,10,11]. Ref. [5] studied mobile vehicles and built a sharing framework covering data collection, management and other links, but its research results did not involve the details of vehicle data sharing. Combined with user privacy protection requirements, the authors in [6] introduced the concept of a trusted authority (TA) using pseudonyms to enforce user privacy. However, that scheme is only applicable to parked vehicles, not to mobile vehicles on the road that need data sharing, and the proposed scheme cannot ensure real-time data sharing. Ref. [7] created a lightweight solution, the core of which is the application of encryption technology to ensure that mobile vehicles will not cause hidden problems in V2V data transmissions during data operation. In the process of increasingly advancing blockchain technology, people introduced it into the research field of data sharing in IoV. The authors in [8] developed a point trust mechanism based on blockchain to support secure data transmission between vehicles. In detail, the IoV node credit evaluation was completed to find and eliminate malicious nodes, which provides a powerful guarantee for V2V communication. However, if the available resources of a single node are small, it is very expensive to build a public blockchain at this time, and this solution is not ideal for large-scale IoV data sharing networks. Ref. [9] created a model based on federated blockchain, which needs to meet specific privacy conditions to protect vehicle privacy and provide a guarantee for information security sharing. In terms of cost, this scheme is significantly superior to public blockchain. Ref. [10] proposed an interactive security approach based on blockchain for electric vehicles.

However, the existing data sharing and transmission schemes for mobile vehicles in IoV still have some problems, such as: privacy threats, transmission security risks and low sharing efficiency. The traditional blockchain can be used in the IoV data sharing scheme, but it will cause longer transaction confirmation times. To address these problems, we propose an efficient data sharing scheme for mobile vehicles on the road based on the consortium blockchain; the Stackelberg game is used to ensure data exchange efficiency among vehicles. The main contributions of this paper are summarized as follows:

• We design a mobile vehicle data security sharing model based on the consortium blockchain.
• The Stackelberg game is used to ensure data exchange efficiency between vehicles (data sellers) and demand entities (data buyers, such as traffic scheduling centers and autonomous driving companies). We adopt a special architecture to provide sufficient security for privacy and data sharing of both, to improve the system data transmission efficiency.
• We conduct a set of simulations to show that the proposed data sharing scheme can improve the data transmission efficiency and that the privacy of vehicles is guaranteed.

The rest of this paper is organized as follows. In Section 2, we describe the system model, and in Section 3, the process of data sharing based on the consortium blockchain is proposed. In Section 4, we present the problem formulation and solution algorithm. We present the simulation analysis in Section 5. Finally, Section 6 contains the conclusion of this paper presented.

2. System Model

2.1. System Model

The data sharing system model of IoV based on the consortium blockchain is shown in Figure 1, which includes trusted authority (TA), moving vehicle (i.e., data seller), RSU, and data demand entity (i.e., data buyer) [12]. TA is mainly responsible for the registration and certification of entities, and a special government department is responsible for TA authority and security. Any IoV entity that wants to be part of the sharing system (such as mobile vehicles, traffic dispatching centers, autonomous driving companies) should first register and obtain the TA’s access permission to join the network through issuance of a digital certificate.

Normally, RSU performs as data agent to respond to requests for data purchases and sales in the IoV. As shown in Figure 1, RSU is one of the consensus nodes of the federated blockchain; the data sharing smart contract (DSSC) is used to control data sharing. The communication between RSUs is referred to as R2R, which is mainly cable connection. The data buyer to RSU communication is referred to as B2R, and it can also be connected by wired connection. The mobile vehicle to RSU communication is referred to as V2R, which is completed by satellite, wireless communication network, 4G/5G or other technologies [13,14]. Moving vehicles covered within a network area are called data sellers. The data seller registers an account with TA, and this account can be a non-real name, so as to protect the privacy of the vehicle owner. After account registration is completed, the wallet function needs to be activated to store resource coins. The mobile vehicle communicates with the RSU through the onboard unit (OBU). Moreover, the data demand entity can be an enterprise or an institution, such as an autonomous driving company, a traffic control center, etc. It plays the data buyer role in the entire framework. Data originating from moving vehicles are obtained using the scheduling of smart contracts deployed on the RSU. In addition, these data are used for a fee, paid through resource coins.

2.2. Assumptions of the Data Sharing Model

The operation of system model is based on certain assumptions, which are explained below:

• Figure 1 shows the details of the data exchange between different entities. The data demander and the RSU use cables to realize B2R communication, while the RSUs communicate with each other through R2R, which also requires cables. Since the RSU and the moving vehicles communicate with each other through V2R, we assume that there are a set of equally spaced RSUs deployed on the road, and the communicable range radius of the RSUs is described as $R^{RSU}$. $P_j(t)$ represents the position of the RSU $j$, and $P_i(t)$ is the position of the moving vehicle $i$, when

  $$\left|\right|P_i(t_1^{-})-P_j(t_1^{-})>R^{RSU}\left|\right|,$$

  $$\left|\right|P_i(t_1^{})-P_j(t_1^{})\le R^{RSU}\left|\right|$$

  $$\left|\right|P_i(t_2^{})-P_j(t_2^{})>R^{RSU}\left|\right|,$$

  we set that the moving vehicle $i$ and $RS{U}_j$ in $t\in [t_1,t_2)$ produce a contact (here, $\left|\right|.\left|\right|$ is Euclidean distance, $t_1$ and $t_2$ denote the time points before and after $t$), the vehicle and the RSU establish a data link;
• Divide the whole time duration into a series of time slots; the data sharing market for vehicles is explored within a specific time period;
• Regulate data sharing through smart contracts on RSU; the RSU is completely neutral between buyers and sellers, but it will also give appropriate assistance when the requests come from legal entities;
• There are several data buyers and sellers active in each time slot. For the convenience of research, only the data sharing activities of buyer and the seller managed by RSU are discussed. Of course, other situations can also be represented by the proposed system model;
• We consider the shared price standard for all data to be unified. In addition, for the buyer, the purpose of the data is to conduct traffic flow analysis, automatic driving analysis training, etc. The larger the amount of data, the more accurate the analysis results and the better the training effect that can be obtained.

3. Data Sharing Process

In this section, we explain the mobile vehicle data sharing process based on the consortium blockchain, which is controlled by the DSSC in TA, as shown as Figure 2. Specifically, we provide the details of block generation and link flow.

• System initialization

Before becoming a system entity, each vehicle, RSU and data buyer should be registered with TA to obtain a legal and valid identity [15]. In the registration process, an asymmetric elliptic curve encryption algorithm is used to initialize the system. The system gives the registrant a real identity $ID$ and a virtual identity $VID\left(VirtualID\right)$, as well as a new wallet address $WID\left(WalletID\right)$. In addition, the system issues a special tuple, including the public key $PK\left(PublicKey\right)$, private key $SK\left(\mathrm{Sec}retKey\right)$ and digital certificate $Cer{t}_{id}(DigitalCertificate)$, to each entity. Moreover, the TA’s public key $P{K}_{TA}$ also will be issued to all of the entities to ensure the security of the transmitted data.

After the entity is successfully registered, it will obtain the current data information from the storage pool of the surrounding consortium blockchain nodes (i.e., RSU), and ensure the consistency of the entity and the system state to prevent errors caused by information differences between these two parties. In addition, the entity should remit a certain resource currency, that is, the deposit, into the account under the supervision of TA. If the entity damages the system for its own benefit during sharing, it will be penalized in the form of a fine. If the total number of malicious acts carried out by an entity reaches a specified value, that entity will be ejected from the system and lose its legal status.

2.

The data buyer initiates a data sharing request

Taking the data demand entity (i.e., the data buyer) $b_i$ numbered $i$ as an example, when it generates a vehicle data demand, it uses the cable B2R to release the request $\mathrm{Re}q\{VI{D}_i,Cer{t}_i,time,p_{avg}\}$ to $RS{U}_j$ numbered $j$. Here, $VI{D}_i$ represents the virtual identity of $b_i$, $Cer{t}_i$ is the digital certificate of $b_i$. During the registration process of $b_i$, TA encrypts the public key of $b_i$ and other information with its own private key to form a digital certificate; $time$ represents the requested time slot; $b_i$ can use the data sharing system to complete data transactions with mobile vehicles or data centers and enterprises, where $p_{avg}$ represents the average price of transactions that have been completed by buyer $b_i$ and other data suppliers.

3.

RSU acquires the buyer’s request and broadcasts it to moving vehicles within the communication area

$RS{U}_j$ is responsible for obtaining the request from the buyer. When the buyer releases the request to RSU within a certain time slot, the latter buyer send the request to all moving vehicles in its communication area $R^{RSU}$ and obtains the feedback via V2R.

4.

The mobile vehicle responds to the RSU

After the mobile vehicle $s_k$ (i.e., the data seller) obtains the request from $RS{U}_j$ successfully, it makes a decision about whether to trade or not based on its own CPU performance and other aspects, and gives feedback to $RS{U}_j$ with the content $Ans\{VI{D}_k,sign,time,D_k\}$, where $VI{D}_k$ represents the virtual identity of the mobile vehicle $s_k$, $sign$ is generally {yes,no}, which means willing/unwilling to trade. $time$ means the time consumed to respond to feedback. $D_k$ is the upper limit of the data that vehicle $s_k$ can trade with $b_i$. The condition for it to be a non-zero value is that the value of $sign$ is $yes$.

5.

RSU plays the game and feeds back the results to both parties

After receiving the feedback from seller, $RS{U}_j$ calculates the equilibrium point through the Stackelberg game and calculates the corresponding relationship between the most suitable buyer’s bid and the amount of data that can be enjoyed. After this, both parties receive the results from $RS{U}_j$, where ${p_i}^{\ast }$ and ${d_k}^{\ast }$ both are the buyer’s $b_i$ unit of data that should be bid and the total amount of data provided to $b_i$ via vehicle $s_k$; $time$ represents the timestamp of the reply.

6.

Data sharing and payment

After vehicle $s_k$ obtains the matching result of $RS{U}_j$, it will de-duplicate and de-old the data, and then transmit the processed data to $RS{U}_j$. After that, a series of processing steps such as de-duplication are completed using the data filter. If the result shows that the data from vehicle $s_k$ contain duplicate, expired or harmful content, a certain penalty will be deducted from the security deposit of the vehicle, penalizing sellers who offer worthless or harmful data in pursuit of profit. Actually, if the vehicles send duplicated data to the RSU, the data transmission efficiency will be affected directly, which is important for data sharing in IoV.

After the buyer obtains the data successfully, the resource currency of $p^{\ast }{d}^{\ast }$ is retrieved from the wallet and paid to the seller. At the end of this data transaction, a record is generated in the memory pool of $RS{U}_j$, which will be broadcasted across the entire network and added to the block in subsequent links.

7.

Block generation and linking to the blockchain

Aiming at the contention of accounting rights among different nodes, we formulated the proof of work (POW) workload proof mechanism. Although it requires more resources, it is more mature among consensus mechanisms and is immune to attacks such as double-spending attacks and selfish mining attacks with a mining power below 51% [16,17]. The steps of block generation and linking are shown in Figure 3.

Examination of Figure 3 reveals that the operation process of the POW mechanism is as follows:

8.

After RSU generates a data sharing record, it saves it in the memory pool and then informs all RSU nodes. These nodes will also store the record after being notified. The RSU fuses the data sharing records in the memory pool together to obtain a new block during a time period;

9.

All RSU nodes use the POW workload proof mechanism to compete for accounting rights. The essence of the POW mechanism is to continuously adjust the input value of a hash function to obtain the target value. In the block generation time period, the RSU that obtains the qualified random number in the shortest time is the accounting node;

10.

The accounting node broadcasts its own block within the network range. After other RSUs determine that the accounting node has obtained the qualified value, it will not continue to calculate, and then verifies the latter’s block. The final verification result will be reported to the accounting node in the form of “valid” or “invalid”;

11.

The accounting node counts all notifications. When more than half of the notifications are valid, it proves that the block is valid. At this time, the accounting node establishes a connection between the block and the copy of the local consortium blockchain. It is valid for all RSUs, which perform the same operation of establishing a connection;

12.

After judging the block to be valid, the accounting node successfully “mines”. The system will award resource coins, and in this way, it will be motivated to continue “mining”. In addition, the accounting RSU retrieves the data sharing records contained in the memory pool, identifies all of the mobile vehicles participating in the data sharing, determines the degree of participation and reward resource coins, and directly deposits coins in the vehicle’s wallet to encourage them to continue data sharing. After the current round of consensus is completed, it will enter the next round.

4. Problem Formulation and Solving

In this section, we model and solve the game process in which the buyer unit data should bid $p$ and the seller should provide data volume $d$ in the process.

4.1. Stackelberg Game Scheme Modeling

When the data buyer $b_i$ has a demand for mobile vehicle data, the buyer releases the request $\mathrm{Re}q\{VI{D}_i,Cer{t}_i,time,p_{avg}\}$ for $RS{U}_j$ numbered $j$, through the analysis above. $p_{avg}$ denotes the average price of $b_i$ buyer’s previous transactions with other sellers, considering that the transaction in this market is completely transparent, so the buyer can not tender fictitious $p_{avg}$. After $RS{U}_j$ sending the request to the mobile vehicle within its communication range $R^{RSU}$, when the number $k$ of the mobile vehicle $s_k$ (the data seller) has made a sharing decision, it will be answered $Ans\{VI{D}_k,sign,time,D_k\}$ for $RS{U}_j$, where $D_k$ denotes the number of resources that the seller’s mobile vehicle $s_k$ needs to provide. Through an analysis of previous works [12,17,18], $D_k$ can be determined via $s_k$. The maximum amount of data, $D_k$ can be related to the buyer’s bid directly, and it can also be restricted by the CPU performance, the remaining electrical energy and other factors of $s_k$. We measure the inconvenience of sharing by the inconvenience parameter ${\alpha }_k$ to the vehicle. Based on the Stackelberg game method deployed by the smart contract DSSC in $RS{U}_j$, it determines the number of resources that the seller $s_k$ needs to provide, and the unit data price that the buyer $b_i$ should actually pay. Then, it completes the derivation of the game process.

Here, we use $p_i$ to indicate the unit data price that seller entity $b_i$ should pay. Then, to help the seller $s_k$ determine the utility criteria, it should involve the following attributes of the problem:

The higher the $p_i$ value, the utility of the seller becomes higher, which means more substantial return. In addition, the higher the value of the inconvenience parameter ${\alpha }_k$, the lower the utility of the seller.

The utility function $U_{s_k}$ of the seller’s vehicle $s_k$ is the concave function of $d_k$. First, if $d_k$ is higher than a certain value, the utility function $U_{s_k}$ is a non-decreasing function of $d_k$, because the larger the shared resource $d_k$, the higher the return that the seller can obtain. However, if the $d_k$ value is too high, the utility of the seller is reduced, because its resources are limited, and it is difficult to guarantee the quality of service, such as accelerating the loss of power and CPU performance.

To present the concaveness of the utility function, we set the function extreme value point to be $\frac{p_i{D}_k}{2{\alpha }_k}$; these two parameters $p_i$ and $D_k$ are positive correlations, but the relationship between the inconvenience parameter ${\alpha }_k$ is a negative correlation. Based on the above analysis, we determine the seller’s utility function of $s_k$ as:

$$U_{s_k}(d_k)=p_i{D}_k{d}_k-{\alpha }_k{d}_k{}^2$$

(1)

Obviously, the above Equation (1) is a concave function with $d_k$. There is a maximum point of value $\frac{p_i{D}_k}{2{\alpha }_k}$, which can meet the setting conditions.

Next, we analyze the utility function for the buyer $b_i$. The benefit that $b_i$ can obtain the bid of the unit resource, that is, in the utility function of $b_i$, the buyer bid is the independent variable. To effectively reduce the cost of task execution, buyers $b_i$ want to reduce the price of data. However, if the price for sellers is low enough to be unattractive, it is will be difficult to achieve good performance gains. We use n to denote the vehicles that represent the data transactions between the buyer $b_i$ and the buyer within the management range of $RS{U}_j$, and if the set of them constitutes $\left\{s_1,s_2,\dots ,s_n\right\}$, then the utility function of $b_i$ is:

$$U_{b_i}(p_i)={\eta }_i{\displaystyle \sum _{k=1}^n{d}_k-}{\beta }_i{p}_i{\displaystyle \sum _{k=1}^n{d}_k}$$

(2)

where the total revenue ${\eta }_i{\displaystyle \sum _{k=1}^n{d}_k}$ of $b_i$ is the buyer’s purchase of data from the vehicle n within the management range of $RS{U}_j$, and the income that the buyer $b_i$ can earn from the unit data of the vehicle purchased.

The total cost ${\beta }_i{p}_i{\displaystyle \sum _{k=1}^n{d}_k}$ of the transaction between the buyer $b_i$ and vehicle $n$ shows that the bid for all vehicles is exactly the same. According to the different amounts of data used by each buyer, the cost and performance gains are fully considered before the transaction, and the parameters ${\beta }_i$ are balanced.

In summary, to determine the buyer’s bid price $p_i$ and the amount of data with the maximum utility function, we have:

$$\underset{d_k}{\max }{U}_{s_k}(d_k)=\underset{d_k}{\max }\left(p_i{D}_k{d}_k-{\alpha }_k{d}_k{}^2\right)$$

(3a)

Subject to:

$$d_k\le D_k$$

(3b)

In addition, given the amount of data $d_k$ that the seller $s_k$ is willing to trade, the buyer $b_i$ determines the bid for the unit data based on the maximization of its utility function (2), as:

$$\underset{p_i}{\max }{U}_{b_i}(p_i)=\underset{p_i}{\max }\left({\eta }_i{\displaystyle \sum _{k=1}^n{d}_k-}{\beta }_i{p}_i{\displaystyle \sum _{k=1}^n{d}_k}\right)$$

(4a)

Subject to

$$p_i\le p_{avg}$$

(4b)

Through the above analysis, it can be seen that the average price $p_{avg}$ of transactions made by the buyer $b_i$ and other sellers in the past, $p_i\le p_{avg}$ means that the price at which the agent and the vehicle are transacted does not exceed the average price.

4.2. Stackelberg Game Solution

This paper models the problem as a Stackelberg game, $RS{U}_j$ deployed on the DSSC using the Stackelberg game to find the amount of data $d_k{}^{\ast }$ that the seller $s_k$ should supply to the buyer $b_i$ and the final unit data bid $p_i{}^{\ast }$. It is a common leader–follower game and includes both the follower’s decision and the leader’s decision. The model of the Stackelberg game can be formally summarized as:

$$\mathsf{\Gamma }=\{(S,\left\{b_i\right\}),\{D_k{\}}_{1\le k\le n},\{U_{s_k}{\text{}}}_{1\le k\le n},p_i,U_{b_i}\}$$

(5)

In Equation (5), $(S,\{b\})$ is a set of all participants, the buyer $b_i$ is the leader, and the set $S$ contains all of the sellers who are followers, $D_k$ is the strategy vector of $s_k$. $U_{s_k}$ is the benefit function when $s_k$ provides $d_k$ quantities of data to $b_i$, $U_{b_i}$ is a function of the benefit obtained by buying data for $b_i$ bids and $p_i$. After the game is completed, it is possible to determine the optimal value of the amount of data $d_k{}^{\ast }$ traded by the seller $s_k$ in the transaction and the bid of $b_i$ the buyer’s final unit data $p_i{}^{\ast }$.

For the convenience of research, we divide the entire game process into two stages: firstly, the buyer $b_i$ who plays the role of leader, $RS{U}_j$ defines the strategy of $b_i$, that is, the bid $p_i$. Secondly, $RS{U}_j$ determines the seller’s strategy, the amount of data it is willing to trade is mainly considered. For this game $\mathsf{\Gamma }$, the purpose is to achieve Stackelberg equilibrium, $d_k{}^{\ast }$ determines $s_k$ the maximum benefit and $p_i{}^{\ast }$ determine $b_i$ the greatest benefit, which is defined as follows.

Definition 1.

For Stackelberg game $\mathsf{\Gamma }$, the strategy $\left(d_k{}^{\ast },p_i{}^{\ast }\right)$ meets the following conditions to achieve Stackelberg equilibrium:

$$\begin{array}{l}{U}_{s_k}\left(d_k{}^{\ast },p_i{}^{\ast }\right)\ge U_{s_k}\left(d_k,d_{-k}{}^{\ast },p_i{}^{\ast }\right)\\ U_{b_i}\left(d_k{}^{\ast },p_i{}^{\ast }\right)\ge U_{b_i}\left(d_k{}^{\ast },p_i\right)\end{array}$$

(6)

where $d_k{}^{\ast }$ is the strategy set of all sellers that $s_k$ are not included. In the game $\mathsf{\Gamma }$ , when $b_i$ bid  $p_i{}^{\ast }$ determined, the seller $s_k$ can obtain the most considerable benefit in the case of sharing $d_k{}^{\ast }$ data, so the amount of shared data cannot be adjusted to improve the seller’s income by $RS{U}_j$. In addition, in the case of $s_k$ shared $d_k{}^{\ast }$ data, the buyer $b_i$ earns the most considerable income $p_i{}^{\ast }$, and even if the bid strategy is adjusted, it cannot improve the income.

4.2.1. Problem Analysis

Lemma 1.

The Stackelberg game $\mathsf{\Gamma }$ has and only has a Stackelberg equilibrium point.

Proof. 

First argue that the Stackelberg equilibrium of the seller exists. In the second stage of the game, $RS{U}_j$ know that the seller needs to trade the amount of data $U_{s_k}$, it can obtain the highest benefit. The second derivative of $U_{s_k}$ derived from Equation (1) is ${U^{″}}_{s_k}=-2{\alpha }_k<0$ (${\alpha }_k>0$). Thus, $U_{s_k}$ is a strictly concave function of $d_k$. There is a maximum value of $U_{s_k}$ relative to $d_k$. Therefore, for any offer $p_i$, the seller can find the best solution that exists only if it is proven.

Secondly, the Stackelberg equilibrium for the argument buyer exists. After the second stage, the buyer’s strategy is determined. For the determined offer $p_i$, based on Formula (7), $RS{U}_j$ determines $s_k$ and the seller’s shared data $d_k$ amount, which means that the point that $d_k$ makes the quadratic function $U_{s_k}$ extreme, the first derivative is zero, as:

$$\frac{\partial U_{s_k}}{\partial d_k}=0$$

(7)

Considering $d_k\le D_k$, the seller’s best decision is given as:

$$d_k{}^{\ast }=\min \left\{\frac{p_i{D}_k}{2{\alpha }_k},{\mathrm{D}}_k\right\}$$

(8)

After determining the value of $d_k$, according to the buyer’s utility function (2), we have:

$$U_{b_i}(p_i)={\eta }_i{\displaystyle \sum _{k=1}^n{d}_k{}^{\ast }-}{\beta }_i{p}_i{\displaystyle \sum _{k=1}^n{d}_k{}^{\ast }}$$

(9)

Make the obtained derivative $d_k{}^{\ast }$ to the above equation, and calculate the second derivative ${U^{″}}_{b_i}\le 0$ of $U_{b_i}(p_i)$, then, the function image $U_{b_i}(p_i)$ will definitely be convex. Therefore, there is a maximum point, which can be derived as a strict concave function $U_{b_i}$ of $p_i$. The $RS{U}_j$ can determine the best bid $p_i{}^{\ast }$ that the buyer has and only based on the seller’s strategy.

It can be seen that the game $\mathsf{\Gamma }$ strategy of the DSSC on $RS{U}_j$ ensures the existence of the Stackelberg equilibrium point. □

4.2.2. Algorithms for Achieving Stackelberg Equalization

This section creates an algorithm based on ternary search, to ensure both parties can reach the equilibrium point. In detail, since the buyer’s bid must not exceed the historical average price $p_{avg}$, we select four points in the range between 0 and $p_{avg}$:$L,R,p_{mid},p_{midmid}$ and there are:

$$L=0,R=p_{avg},p_{mid}=\frac{L+R}{2},p_{midmid}=\frac{p_{mid}+R}{2}$$

(10)

The execution steps of the algorithm are:

• Based on the buyer’s bid $p_{mid}$, use Formula (8) to find the optimal decision $d_k{}^{\ast }$ of $RS{U}_j$ each seller’s vehicle, and then, based on the decision set $\left\{d_1{}^{\ast },d_2{}^{\ast },\dots ,d_n{}^{\ast }\right\}$ of all sellers and the buyer’s bid $p_{mid}$, the buyer’s benefit function $U_{b_i}$ can be calculated. For the sake of convenience and differentiation, we use $U_{b_i}$, which represents the value of the benefit function in the case of the bid $p_{mid}$ from the buyer;
• According to the buyer’s bid $p_{mid}$, we find the seller’s decision set and the buyer’s benefit, using ${\ddot{U}}_{b_i}$, which represents the buyer’s benefit;
• Determine the relationship with the size of ${\ddot{U}}_{b_i}$ and ${\ddot{U}}_{b_i}$; if ${\dot{U}}_{b_i}>{\ddot{U}}_{b_i}$, the upper limit of $U_{b_i}$ appears in the $L$ to $p_{midmid}$ interval, the interval is reduced, and $R=p_{midmid}$. Otherwise, the upper limit of $U_{b_i}$ appears in the interval from $p_{mid}$ to $R$, the interval is reduced, and $L=p_{mid}$.

Repeat until the difference between $L$ and $R$ the minimum unit $\tau$ of the price becomes small enough. Considering $U_{b_i}$ is a true concave function, the algorithm ternary search should be able to find the bid $p_i{}^{\ast }$ that $U_{b_i}$ is capped. Based on the buyer’s bid $p_i{}^{\ast }$, each seller determines the amount of resources $d_k{}^{\ast }$ it provides to achieve the most substantial benefits. The cycle continues until the buyer’s bid cannot be further divided, and both parties to the transaction achieve an equilibrium point. That is to realize simultaneously $s_k$ seller’s optimal shared data volume $d_k{}^{\ast }$ and $p_i$ buyer’s optimal bid $p_i{}^{\ast }$.

5. Simulation Analysis

In this section, we simulate and analyze the Stackelberg game and consortium blockchain framework with MATLAB2016A to determine the performance level of the proposed schemes.

5.1. Performance Analysis of the Stackelberg Game Solution Scheme

5.1.1. Simulation Setting

Considering IEEE 802.11p communication protocol is used in the IoV, including the V2V and V2R, the transmission distance of RSU does not exceed 1000 m [19] $R^R$= 1000 m. Thus, the simulation network area is set as 600 m × 600 m, with five equally spaced roads from east–west and north–south, all in four lanes. Considering that in the IEEE 802.11p communication protocol followed by the RSU, the transmission distance does not exceed 1000 m [19] $R^R$ = 1000 m. To evaluate the Stackelberg game solution scheme performance, the proposed BCB scheme and the following two baseline schemes are analyzed, as:

• SPRS (Set Price by Response Time Scheme): After the RSU sends the request from the buyer to the vehicle, the shorter the feedback time of the vehicle giving priority to trade with the buyer, and the buyer tends to purchase all the data provided by it $D$. The shorter the vehicle feedback time, the higher the unit price of the data, and the price can be obtained. Prices can be determined by $P_{SPRS}=\frac{\mu p_{avg}}{t_{ans}}$. Here, $\mu$ represents the coefficient of adjusting the price, $t_{ans}$ is the response time of vehicle. Under the scheme, when the seller tends to give feedback faster, the buyer can obtain the data in a shorter time period. In the process of simulation analysis, the response time of the vehicle is set randomly to imitate the feedback situation of each vehicle, which is more consistent with reality;
• POS (Purchase from Other Data Providers Scheme): The buyer trades the data at the market price $p_{avg}$ directly, with other institutions.

5.1.2. Simulation Analysis

In this section, we first simulate the performance of the Stackelberg game algorithm in a buyer case, that is, when the buyer $b_i$ releases requests to a nearby RSU in a time slot.

• The relationship between the $b_i$ maximum amount of data and $b_i$ income that the seller is willing to sell to the buyer.

Assuming that in the network area, the number of mobile vehicles $n=50$, and they are willing to share with the $b_i$ buyer. Set the $b_i$ price for purchasing 128M data from other data institutions as $p_{avg}=0.5RC$ (RC represents resource currency units), and the income that the buyer can receive as ${\eta }_i=1RC/128M$ the balance parameters β_i = 1, the inconvenience parameters $\alpha$ of all vehicles are randomly distributed within [0, 0.5], the $\tau$ minimum unit value of the price is 0.01RC. In addition, assuming that the maximum amount of data that each vehicle is sharing is $D_k,k\in [0,n]$, and the data they are willing to sell is consistent, it is a dead core $D_1=D_2=\dots =D_n$, and $D_k$ does not exceed the range of [1 GB, 6 GB].

Each scheme performs 50 simulations, with the average as the final value, thus enabling a convincing simulation analysis of the data sharing for each vehicle in various traffic environments. First, the simulation of the BCB scheme is completed, and the total amount of data purchased by the b_i buyer can be obtained. Then, the total data amounts purchased by the other two schemes are the same as that of the BCB scheme, and on that basis, the buyer’s incomes under three sets of schemes are compared. In the D_k process of continuous change, the income fluctuations of the buyers under the three schemes are shown in Figure 4.

Figure 4 shows that in the process of continuously increasing the maximum data $D_k,k\in [0,n]$ amount shared by the vehicle to the $b_i$ buyer, the benefit of the buyer shows a trend of increase in all schemes. The reason is that $D_k$ in the improvement process, buyers can obtain more data, and earn considerably more income. In addition, when the data purchased by the buyer are consistent, compared with the baseline schemes SPRS and POS, the BCB scheme can bring higher returns to the buyer. The reason is that the BCB scheme can better balance between the buyer’s bid and the seller’s shared data volume, and the buyer can obtain more considerable returns based on reasonable bidding.

2.

The impact of vehicle density on buyers’ income

Assume that the number of vehicles in the 600 m × 600 m network area continuously varies within the [50, 300] range, and $D_k,k\in [0,n]$ the maximum amount of data each seller is willing to provide the $b_i$ buyer is [2 GB, 3 GB], the data amount $D_k$ is close to reality, taking different values, and the remaining parameters are consistent with the previous simulations. Assuming the same data purchase volume of $b_i$ buyers under the three sets of schemes, 50 simulations are completed with the average as the final results. Figure 5 shows the fluctuation of buyer benefits under each scheme.

Figure 5 shows that in the process of continuous improvement in vehicle density, the buyer’s income basically maintains rising momentum. The reason is that the more data the buyer can obtain, the higher the satisfaction of its demand and the higher the benefit. However, in the case of 200 vehicles, the benefit of the buyer’s price in all schemes is reduced, because the value in the BCB scheme $D_k$ is within the [2 GB, 3 GB] range, and it is randomly selected. In the case of 200 vehicles, the amount of data that the vehicle is willing to sell is not much, so the total data available to the buyer is less, and the benefit does not increase and decrease.

Overall, the BCB scheme is higher for the buyers, but the revenue of the SPRS scheme at 100 exceeds the BCB scheme. The reason is that in the SPRS scheme, the response time of vehicles is a random value. When the number of vehicles becomes 100, the overall response time of vehicles in the network becomes long. In this case, the overall bid of the buyer is low, the total cost of buying the same data is lower, and the buyer indirectly improves the benefit, which is the reason for the higher income of the buyer in the SPRS scheme. However, this is a special case, in which the number of vehicles and shared data continue to increase; after repeated simulation and calculating the average value, the probability of this special case is greatly reduced. In summary, the BCB scheme has significant advantages in terms of overall performance.

3.

Impact of the inconvenience parameters $\alpha$ on the buyer’s benefit and cost

The following will study the relationship between the buyer’s inconvenience sharing parameters $\alpha$ and the buyer benefit and cost in the BCB scheme. Assuming consistent $\alpha$ values for the whole vehicle, fluctuating in the range of [0.04, 0.32], the presence of 50 random vehicles on the 600 m × 600 m network area roads, offer $p_{avg}=0.5RC$, ${\eta }_i=1RC/GB$, balance parameters, ${\beta }_i=1$, the maximum data that all vehicles are willing to provide is $D_k$ consistent and equal to 2 GB. To ensure that the data meet the general requirements, 50 simulations are completed, with the average as the final result, drawing the buyer income fluctuation map in the POS scheme with the same amount of purchase data. The simulation results are detailed in Figure 6.

Figure 6 shows that during the $\alpha$ continuous improvement of the BCB parameters, the buyer’s income in the BCB scheme continues to decrease, while the cost shows the opposite trend. The root cause is that when the seller is under the influence of various factors, the buyer will increase the bid and enhance the seller’s tendency to share, so that the buyer needs to bear higher costs, and the benefits will be affected. In addition, in the POS scheme, the $\alpha$ income is also negatively correlated, because we assume the same data purchase volume under the two sets in the simulation analysis. In the $\alpha$ of raising the case, the data purchase volume in BCB and POS scheme decreases, and the buyer benefit and data purchase volume of the POS scheme are positively correlated, so the income in the buyer’s scheme is also reduced.

5.2. Performance Analysis of the Consortium Blockchain Framework

The results of a comparison of consortium blockchain with traditional blockchain are shown in Figure 7. The consortium blockchain framework uses Hyperledger Fabric to write smart contracts of blockchain. In this paper, 10 peering points (each peer adopts x64 virtual machine simulation) are compared to 10 RSU to conduct simulation and analysis. Based on Node.js, the load test library completes the scheme test. It is assumed that 200 cars in the covered area perform as data sellers, and they all have a certain willingness to share the data. The number of buyers is 50. The other parameters are exactly consistent with the previous simulation parameters.

According to the analysis of Figure 7, the average transaction confirmation time of a block in the BCB scheme is basically not more than 10 to 15 min, while this index in the traditional blockchain is about 60 min [20]. The proposed scheme can confirm the block more efficiently. The reason is that from the perspective of BCB, it only completes the blockchain block consensus between the RSUs, avoiding the consensus of the traditional blockchain on all of the connected nodes. Moreover, in the BCB scheme, the number of consensus nodes is strictly limited, so the network throughput has been significantly improved. Block can be confirmed in a shorter time. Based on the proposed mode, the nodes can reach a consensus more efficiently and effectively shorten the waiting time. The efficiency of the consortium blockchain framework is ensured.

6. Conclusions

In this paper, a mobile vehicle data sharing scheme based on consortium blockchain was designed to build a decentralized data sharing system framework. The data transaction time in the system can be reduced, and the entity security of vehicles and RSUs is ensured. In addition, we proposed an optimal revenue strategy approach between vehicles and data-demanding devices through the Stackelberg game. The amounts of the optimal buyer’s bid and seller’s available data are determined, which effectively maximizes the benefits of both transaction sides. Finally, the performances of the BCB scheme, SPRS and POS scheme were simulated and compared, and a performance comparison between the consortium blockchain framework and traditional blockchain was also presented. Simulation results show that the proposed BCB scheme has a higher level of performance. On the premise of protecting entity privacy and data security, the data of mobile vehicles can be shared with buyers more quickly.