# Efficient Mobile Vehicle Data Sharing Scheme Based on Consortium Blockchain
## 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. 1. 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(Virtual\ ID)\), as well as a new wallet address \(WID(Wallet\ ID)\). In addition, the system issues a special tuple, including the public key \(PK(Public\ Key)\), private key \(SK(Secret\ Key)\) and digital certificate \(Cert_{id}(Digital\ Certificate)\), to each entity. Moreover, the TA's public key \(PK_{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 \(\text{Re}q\{VID_{i},\ Cert_{i},\ time,\ p_{avg}\}\) to \(RSU_{j}\) numbered \(j\). Here, \(VID_{i}\) represents the virtual identity of \(b_{i}\), \(Cert_{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. Figure 2: Data sharing process flow. 3. RSU acquires the buyer's request and broadcasts it to moving vehicles within the communication area \(RSU_{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 \(RSU_{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 \(RSU_{j}\) with the content \(Ans\{VID_{k},\,sign,\,time,\,D_{k}\}\), where \(VID_{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.