RC-chain: Reputation-based Crowdsourcing Blockchain for
Vehicular Networks

The scenario consists of the following entities: Certificate Authority (CA), organizations, blockchain, vehicles, RSUs, and fog servers (Fig. 1). Various organizations can form a regional consortium based on RC-chain. We divide the crowdsourcing services into two types here, the question and answer (Q&A) service and the data-sharing service.

The Q&A service involves a provider answering to questions proposed by the service consumer. For instance, consider a map company that needs traffic condition information for a certain road at a specific time, a weather bureau that needs to collect the precise air quality status of a park, or a traffic police authority that needs to know in real-time where traffic accidents have occurred. As potential service consumers, the vehicles within these organizations ask questions, then nearby vehicles including taxis, buses, and passenger cars can compete as service providers to answer the questions.

The data-sharing service refers to vehicles actively sharing data among various organizations. For example, a taxi service provider publishes collected data which can be utilized by other organizations (e.g., a traffic police authority) to analyze and plan holiday route changes. The weather bureau shares weather predictions which can be shared by the taxi company with their passengers. More details about this type of transaction process are introduced in Section 4.1.

RC-chain has a three-layer network architecture composed of a user stratum, fog stratum, and cloud stratum. The user stratum includes on-vehicle sensors and terminal devices which upload the collected data to the fog nodes, that is, the RSUs distributed along the road and organization-owned fog servers. As the number of transactions continues to increase, the fog nodes can upload early accounts to the cloud stratum after a certain period. Organizations can rent cloud services from suppliers based on their own needs to conduct big data analysis and large-capacity storage as necessary.

The roles and functionalities of entities are as follows.

Certificate Authority: The CA issues certificates and often held by the audit and management department. Unlike the traditional P2P trading of public blockchains, nodes without identity certificates are not permitted to participate in the transaction. Each user obtains a legal identity, then is given an initial reputation value that is constantly updated based on its service behavior (Section 5). The vehicle’s subsequent behavior after joining the consortium is reflected through the transaction records in the ledger (Lu et al., 2018).

Organizations: An organization is a collection of multiple members who generally share the same root certificate. An organization can be as large as a multi-national corporation or as small as an individual, e.g., traffic police authority, taxi company, map company, or weather bureau as shown in Fig. 1. A collection of organizations with common interest, joining to a network only by authorization, form a consortium. Nodes in the organization, such as vehicles, are the transaction objects.

Blockchain: The Hyperledger Fabric platform of the consortium blockchain is an important component of RC-chain, which consists of three main components: peers with the ledger, orderers, and clients. Peers may be endorsing peers, committing peers, or leading peers. Each organization has its peers with copies of the ledger of their consortium network. The ledger is composed of the transactions logs of the blockchain structure and the world state, the database of the ledger, which describes the state of the ledger at a given point in time. The transactions logs record all transactions that produce the current value of the world state regardless of legality. Orderers are responsible for ordering transactions and packaging them into blocks. The client is operated by users. Every organization may contain a different number of peers, orderers, and clients. As shown in Fig. 1, the map company with two peers and one orderer initiates transactions through client A1. The peers and orderers work together to complete the consensus process; endorsing peers, orderers, and committing peers can all run independently for enhanced efficiency (Section 4.2).

Vehicles: Each vehicle belongs to one organization as a user capable of playing different roles (requester, server, idler) according to their own VCS needs. The client is deployed on vehicles. Vehicles are equipped with advanced communication devices such as On-Board Units (OBUs) which can collect data through sensors, execute simple calculation and storage operations, and communicate with nearby RSUs (Lasla et al., 2018).

RSUs: A certain number of RSUs are distributed in each area. RSUs act fog nodes that collect transaction requests and update reputation values. Orderers are deployed on RSUs to order services. The RSUs executes these processes according to agreed-upon rules specified in the smart contract, and upload the process to the ledger to be supervised by other nodes.

Fog servers: By leveraging the rich computing and storage resources of fog servers close to the edge of the network, peers deployed on fog servers within various organizations can effectively minimize latency. Transaction information is stored in the distributed ledger of the fog server for the purposes of consistency and transparency.

All transactions are performed via chaincode. A vehicle broadcasts the request for Q&A service as shown in Fig. 2. The request proposal and following main process need verifications of three-stage consensus to proceed. Then they are recorded in the ledger as evidence of transactions. Any vehicle willing to answer the question can send a service request to the nearest RSU, which selects the server according to TPFS model. After the service is finished, the requester evaluates the service, then the reputation value of the corresponding server is updated. The data-sharing service only requires the server to upload the shared data index. The requester selects the data of interest according to the index, then establishes communication with the server to obtain integral data, other processes are similar to the Q&A service.

Step 1: All participants joining in the consortium should be authenticated in the CA by binding their registration information (e.g., vehicle license plate). CA issues public keys, private keys, transaction certificates, and identity certificates to legal entities via an elliptic curve digital signature algorithm and asymmetric cryptography. The initial reputation value of entities is generally 0.5.

Step 2: The requester broadcasts the request to the other vehicles and nearest RSU (the “leading” RSU), which communicates with other (“following”) RSUs in the same area to keep in sync. The following RSU passes the request to vehicles in its vicinity. The requester sends the request transaction proposal to endorsing peers in the fog servers of organizations to execute consensus. Endorsing peers are chosen by the endorsement policy in chaincode, which defines organizations that need to endorse the proposal to be accepted by the ledger. This is the literal definition of “consensus” – every organization involved must endorse a proposed ledger before it can be accepted by any peer of any organization. Vehicles must reach consensus before a transaction proposal can be completed. After the proposal passes the three stages of endorsement (Step 2.1), ordering (Step 2.2), and commitment (Step 2.3), it is considered to be a legal transaction and the ledger can be updated accordingly (Section 4.2).

Step 3: The service-intentioned vehicle submits a service-request to the nearest RSU.

Step 4: The leading RSU and following RSUs select one service candidate based on the TPFS model (Section 5). The following RSUs send the service candidates to the leading RSU, who selects the final server at random. The final server sends a service proposal with the RSU’s signature to the ledger.

Step 5: The requester establishes communication with the server, then the server sends the service-process proposal to the ledger as a proof of transaction.

Step 6: After the service is completed, the requester gives the leading RSU feedback (e.g., rating, timeliness report) about the server.

Step 7: The RSUs update the reputation value of the servers according to the TPFS model and send a reputation-update proposal to the ledger. In this way, the reputation value can be traced through the transaction records of the block.

In the blockchain, “consensus” is an agreement on the order and status of multiple transactions generated within a certain period. The transaction is packaged into blocks according to certain rules to ensure that the ledger owned by the distributed nodes retains a stable state. It is possible that not all nodes run in an ideal state however, so a current consensus algorithm of the blockchain system is very challenging to establish. For example, this probabilistic consensus algorithm PoW causes not only a waste of resources but also “double spending” problems possibly. The PoS is susceptible to collusion attacks by malicious nodes. The Practical Byzantine Fault Tolerance (PBFT) cannot prevent sybil attacks, that is, where malicious users exploit multiple IDs to participate in erroneous consensus behavior. The pursuit of security can cause problems such as long delays and poor scalability.

Fortunately, the consensus of the Hyperledger Fabric is not susceptible to double spending. The three-stage consensus can effectively ensure security. It is the consensus of the whole process based on staged consensus, that is, the failure of any stage will lead to failure in the end. The separation between endorsement and ordering lends performance and scalability advantages, while the use of fog computing technology accelerates the processing time.

The transaction proposal discussed in Section  4.1 can only be written into the ledger after the endorsement, ordering, and commitment steps (2.1-2.3 in Fig. 2) of consensus are all complete. As shown in Fig. 3, there are two types of nodes participating in the consensus process. Peers are mainly used for endorsement and commitment and are divided into endorsing peers, leading peers, and committing peers categories while orderers are used for ordering.

Endorsement stage: The vehicles exploit the client to send the transaction proposal to the designated endorsing peers on fog servers of related organizations. The endorsing peers comprise a small portion of the total peers and are dynamically designated by the endorsement policy. Compared to situations wherein all nodes participate in the endorsement process, this markedly improves efficiency. Upon receiving a transaction proposal, the endorsing peers simulate execution of the transaction process per the chaincode, and record results, but the status of the ledger is not yet updated, The endorsing peers of various organizations then return the transaction proposal response with signatures to the client.

Ordering stage: After receiving sufficient endorsement, the client sends the endorsed transaction proposal to the orderers on RSUs. An orderer does not read the transaction content, but only orders the received transactions using the Kafka algorithm in real time, then packs them into blocks and sends them to the leading peer.

Commitment stage: The most basic function of peers is commitment. The leading peer in each organization synchronizes the received block to other committing peers. The committing peers verify the validity of transactions in the block, including the transaction structure, signature integrity, whether it is repeated, and whether the read and write collection versions match. (This step may contain a double spending transaction, which is considered invalid.) After verification, the transaction is written to the updated ledger.

The three-stage consensus performs well in fault tolerance. In the endorsement stage, the clients learn the current transaction status through feedback from the endorsing peers. The Kafka algorithm in the ordering stage supports Crash Fault-Tolerance (CFT), the downtime of a few orderers does not affect the generation of blocks. If a committing peer fails to synchronize a block due to communication failures, etc., it can pull the block from other committing peers to maintain ledger consistency. If transactions (e.g., the update of reputation value) can not be completed due to the consensus failure or network breakdown, they are not updated in the ledger, but recorded in the transactions logs for audit.

Due to the mobility of the vehicle, the client may have diconnection problem. In the endorsement stage, if client does not receive sufficient endorsement signatures, there are two possible cases:

Case 1. The client did not send the transaction proposal to sufficient endorsing peers for endorsement.

Case 2. Execution timeout of endorsement peers and no response.

For the Case 1 the client can propose the transaction again. Though Case 2 rarely occurs, we take it into account. The risk of disconnection can be reduced by setting in the endorsement policy. For instance, 1) increase the number of endorsing peers; 2) allow for passing the verification with fewer signatures; 3) select more backup nodes in client’s vicinity, etc. Even though they are all disconnected, repeat the submission.

The three-stage consensus process thus achieves BFT.

When the number of vehicles is very sparse in the vehicular network, most have not established interactions and thus it is difficult to find a suitable vehicle to send an inquiry request. The recommendations of other vehicles can be considered here, namely, TP. If $i$ has a reputation value to $j$ and $j$ has a reputation value to $f$, then $i$ can calculate the reputation value to $f$ through $j$. TWSL synthesizes the general opinions of all vehicles on $f$, but does not consider any situation wherein vehicles with lower reputation values make incorrect recommendations. Here, we do take this into consideration to distinguish between reliable and unreliable opinions.

We set two thresholds ${T}_{l},{T_{h}}$ for the reputation value, and deem the recommendation of neighbors with reputation values lower than ${T}_{l}$ to be unreliable while those of vehicles with recommendation values higher than ${T}_{h}$ are reliable. We define the recommended confidence of vehicle $i$ to $j$ as:

where ${{R}}_{i\to j}$ is the reputation value of neighbor vehicle $i$ to vehicle $j$.

The recommendation of vehicle $j$ can be divided into positive and negative opinions. For a positive opinion, the reputation value ${R_{j\to f}}$ of neighbor vehicle $j$ to vehicle $f$ is greater than reputation threshold ${T}_{l}$. For a negative opinion, the reputation value is ${R_{j\to f}}$ less than the reputation threshold ${T}_{l}$. The number of positive and negative recommendations is $a$ and $b$ respectively. The weighted aggregation of positive opinions is:

and the weighted aggregation of negative opinions is:

Based on the number of positive opinions and negative opinions, we can separately find their weights to find an indirect reputation value. The weights of positive and negative opinions are defined by Eq. (4) and Eq. (5), respectively.

The indirect reputation value of vehicle $i$ to vehicle $f$ is:

The TWSL model assumes that all vehicles provide honest ratings of other vehicles, but this assumption makes it difficult to identify malicious vehicles. Since a malicious vehicle may not only send fake messages but may also create malicious, inaccurate ratings. “Pretending-type” (P-type) malicious vehicles may send real messages before beginning to emit fake messages. Two honest (or malicious) vehicles are likely to be given similar ratings by the same group of vehicles that have interacted with them, but this is unlikely to be the case for an honest vehicle versus a malicious vehicle.

Here, we use the same group of vehicles $Com(i,j)$ (e.g., vehicle $q$) to indicate that have interacted with both vehicles $i$ and $j$, and calculate the feedback similarity of vehicle $i$ and vehicle $j$, thereby distinguishing P-type malicious vehicles from others. If the similarity of the feedback ratings of vehicle $i$ and vehicle $j$ is high, then vehicle $j$ has a high reputation value to vehicle $i$. The feedback formula of the overall rating of vehicle $i$ to $q$ is as follows (and is also applicable to the feedback of vehicle $j$ to $q$):

where $\alpha,\beta$ are the number of positive ratings and negative ratings and their weights are ${f_{1}},{f_{2}}$ respectively, as shown in Eq. (8) and Eq. (9).

We used the Weighted Euclidean Distance (WED) method to calculate the feedback similarity of vehicles. We determined a dispersion value based on the historical rating feedback of vehicle $i$ and vehicle $j$; smaller dispersion indicates greater similarity. The similarity of vehicle $i$ and vehicle $j$ based on feedback is defined as (Liu et al., 2016):

where $Q(i,j,q)$ represents the normalized weight of the influence of vehicle $q$ on the similarity, and its standard deviation is $Q^{\prime}(i,j,q)$. The equations above were provided by (Liu et al., 2016).

WED can be used to assign different weights to amplify the different ratings of vehicles $i$ and $j$ for the same group of participants. We utilized the exponential function of feedback similarity to define the local reputation confidence ${r_{i\to j}}$ (Eq. (11)), thereby preventing P-type vehicles accumulate deliberately high reputation values from certain honest vehicles. If there is no common interactive vehicle, the local reputation value weight is $\theta$ $\in$ [0, 1].

When the feedback similarity of the vehicle is high, ${r_{i\to j}}$ is also high (and vice versa).

The final reputation value ${{Rfi}}{{{n}}_{i\to f}}$ can be divided into the following situations:

1. 1.

   Vehicle $i$ and vehicle $f$ have never interacted and have no recommendations. The initial local reputation value from $i$ to $f$ is $\gamma$ $\in$ [0, 1] and the final reputation value is:

   $${{Rfi}}{{{n}}_{i\to f}}={{{r}}_{i\to f}}\cdot\gamma$$

   (12)

2. 2.

   Vehicle $i$ and vehicle $f$ have not established interactions before, but neighbor vehicles $j$ has a recommendation to $f$. The local reputation value is $\eta$ $\in$ [0, 1] and the final reputation value of $i$ to $f$ is:

   $${{Rfi}}{{{n}}_{i\to f}}={{{r}}_{i\to f}}\cdot\eta+{(1-}{{{r}}_{i\to f}})\cdot Ri{n_{i\to f}}$$

   (13)

   where $Ri{n_{i\to f}}$ is given by Eq. (2), Eq. (3) and
   Eq. (6).

3. 3.

   Vehicle $i$ has established interaction with vehicle $f$, but no neighboring vehicle has a recommendation to $f$. The final reputation value of $i$ to $f$ is:

   $${{Rfi}}{{{n}}_{i\to f}}={{{r}}_{i\to f}}\cdot{R_{i\to f}}$$

   (14)

4. 4.

   Vehicle $i$ has established interaction with vehicle $f$, and the neighboring vehicle has a recommendation to $f$ and the final reputation value of $i$ to $f$ is:

   $$Rfi{n_{i\to f}}={r_{i\to f}}\cdot{R_{i\to f}}+(1-{r_{i\to f}})\cdot Ri{n_{i\to f}}$$

   (15)

It is worth mentioning that in the process of updating the reputation value based on the chaincode, and the reputation value can be traced through the transaction records of the block. In addition, if the reputation value of a server is lower than the suggested service threshold $T_{k}$, it is marked to remind the requester to proceed with caution. If a server’s reputation value is lower than the allowable threshold $T_{m}$, its identity certificate is revoked – the consortium removes it and does not permit it again in the future. A flowchart of reputation management processes is given in Fig. 4(a). We also divided the intentioned servers into two groups, one new and one old, based on the historical number of trading threshold $T_{n}$ to enhance the fairness of the server selection process. This provides service opportunities for vehicles newly joining the consortium.

RSU generates a random number $R$ to compare with the value of $Q\in$ [0, 1], which is a threshold specified by chaincode. Fig. 4(b) shows the detailed flowchart of the server selection. There may also be all intentioned servers whose reputation value is relatively low. In this case, servers are selected randomly. (Of course, this is rare.)

We conducted a series of experiments through Matlab to evaluate the performance of TPFS and to compare it against TWSL. Parameters in the experiment included $\gamma$=0.2, $\eta$=0.2, and $\theta$=0.7 (Section 5.3).

Firstly, we analyzed the changes in reputation values over time based on different models as vehicles interact. Most services in the IoV have timeliness requirements. We considered segmented interactions in different situations to determine whether the reputation value can be updated in time. Kang et al. (2018) set the reputation value update time to 1 minute in their work; similarly, we assumed in this experiment that vehicle $i$ and vehicle $j$ interact once per minute for a total of 100 interactions with 100 minutes. Vehicle $j$ sends real messages in [0, 50] minutes and sends fake messages in [51, 80] minutes. Negative ratings have a greater impact on vehicle reputation than positive ratings, so the reputation declines rapidly in the latter half of this process. In [81, 100] minutes, vehicle $i$ and vehicle $j$ do not interact.

At this time, the impact of previous ratings on vehicle reputation value gradually decreases while the influence of neighbor vehicle recommendation gradually increases. Fig. 5 shows the change in the reputation value of the vehicle $i$ to $j$ over time. Because TP considers recommendations from malicious vehicles, the reputation value it obtains is lower than that obtained by TWSL.

We also analyzed the impact of trusted neighbor recommendations on reputation. We set a total of 30 neighboring vehicles. In the case of no interaction between vehicle $i$ and vehicle $j$, the reputation value of vehicle $i$ to vehicle $j$ originates entirely from “trust propagation”, that is, the recommendations of other neighbor vehicles. Fig. 6 shows the relationship between the percentage of truthful neighbor vehicles to all neighbor vehicles and the reputation of vehicle $i$ to $j$. The reputation value of vehicle $i$ to vehicle $j$, obtained by TP, is lower when there are fewer trusted vehicles providing recommendations. This is because TWSL ignores the fact that malicious vehicles may lead to malicious recommendations. TP first evaluates the credibility of the recommended vehicle and can reject any unreliable recommendation provided by a malicious vehicle.

It is also important to consider that malicious vehicles may have unstable behavior. For the next experiment, we set 15 distributed vehicles as servers randomly. As shown in Fig. 7, No. 1 is a malicious vehicle that sends numerous real messages to confuse vehicle $i$. It attempts to conduct malicious attacks after gaining a high reputation value. After 100 interactions, we obtained the reputation value of 15 vehicles as shown in Fig. 7. The reputation values calculated based on TWSL and TP are higher than those obtained by TPFS, because TPFS reduces its reputation value by identifying the malicious vehicle.

We designed a queueing system with three different service stages, that express the three-stage consensus process and the building of a new block. By analyzing the queueing model, we obtained three key performance measures: 1) the average number of transactions in system; 2) the average transaction confirmation time, and 3) the average transaction throughput.

The notations used in this section, which are related to the RC-chain consensus mechanism (Section  4), are summarized in Table 2. A diagram of the model is given in Fig. 8.

We constructed a three-node open queueing network (Hayes and Babu, 2004). The endorsement stage is node 0, the ordering stage is node 1, and the commitment stage is node 2. Assuming that the transaction arrival from clients is a Poisson process, the arrival rate can be denoted as $\lambda_{0}$ and the external arrival to each node is represented by the vector $\boldsymbol{\lambda}$ = [$\lambda_{0}$, 0, 0].

In RC-chain, the transactions that do not meet the endorsement policy or fail the verification are not be updated to the ledger. Such invalid transactions are considered to be leaving the queueing network. The probability that a transaction is routed from node $j$ to node $i$ is given by $q_{ji}$. The probabilistic routing matrix is:

The total traffic into each node of the the network is:

As per the probabilistic routing matrix $Q$ and the external arrival $\boldsymbol{\lambda}$,

Assuming that each node in queueing network has unlimited storage space, and the transaction service time in each node is exponentially distributed with average rate $\mu_{i}$, $i$ = 0, 1, 2.

At any consensus stage in the RC-chain, multiple servers serve the same transaction independently and simultaneously. For example, in the endorsement stage, multiple endorsing peers simultaneously validate the same transaction proposals. Therefore, we assume that there is one server at each node in the queueing network.

In Hyperledger Fabric, there are two conditions for orderers to perform block packaging: the number of transactions waiting packaged reaches the batch size, or these transaction waiting time reaches maximum elapsed duration (i.e., batch timeout). When either condition is met, the orderers immediately package the transactions into blocks. Here, we take the first condition as the model setting and let $M$ denote the batch size. Because the transaction arrival rate to the ordering stage is $\Lambda_{1}=q_{01}\cdot\lambda_{0}$, the average arrival time interval for a transaction is $1/\Lambda_{1}$. For $M$ transactions, the time to wait for packaging after the transaction arrives is (0, $M/\Lambda_{1}$). The service rate of the orderers is given by

where the service rate of the committing peer is assumed to be equal to that of the endorsing peers.

Let $Q1$, $Q2$, and $Q3$ denote the queue length in node 0, 1, and 2 in the steady state, respectively. At this point, the model is identical to the 3-node open Jackson network. The state of the system is defined by the number of transactions in each of the nodes: $k_{0}$, $k_{1}$, $k_{2}$. By strictly applying the derivation given by (Hayes and Babu, 2004), we have

where

represents the service intensity of each node. The steady state condition of the system is ${R_{{i}}}/{S_{i}}={R_{i}}<1$

According to Eq. (18) and Eq. (21),

According to Law of Total Probability, the state equation of each node is:

This system satisfies Jackson’s theorem. The average number of transactions in each node is:

The average number of transactions in system is:

As per Little’s theorem, the average delay of a transaction through node $i$ is:

Let $\bar{D}$ denote the average transaction confirmation time, the time interval from the arrival time point of a transaction to its departure. Be noted that the transaction confirmation time here is calculated from the arrival endorsement stage of the transaction, and the time from the client to the endorsement peers is ignored for simplicity of analysis. Then,

The average transaction throughput $H$ is defined as the rate at which verified transactions are committed by the blockchain across the entire network, that is, the number of transactions that are updated in the ledger per unit time. $H$ is given by

Transaction confirmation time is a key factor for evaluation blockchain-based VCS platform, and the trust information dissemination in vehicular network is time-sensitive. Therefore, we discuss the time performance in transaction confirmation.

Through the numerical calculation on Matlab, we analyze with average transaction confirmation time and average transaction delay at orderer of RC-chain. The results show that the performance of RC-chain based Hyperledger Fabric occupies a clear advantage.

We take some common parameters: transaction arrival rate $\lambda_{0}\in$ [10, 110], batch size $M$=10, 50, 100, $q_{01}$=0.9, $q_{23}$=0.95. The service rate of both the endorsing peers and the committing peers are 150.

It should be noted that the ordering stage has a great impact on the efficiency of block generation. Fig. 9 shows the relationship between average transaction delay at orderer and the transaction arrival rate. It can be seen, as the transaction arrival rate increases, the average delay of the transaction at orderer gradually increases. When the arrival rate increases to 40, the value converge smoothly. The change of average transaction confirmation time with arrival rate has the same trend, as shown in Fig. 10. In addition, the smaller the batch size, that is, the higher the service rate of orderers, the shorter the average transaction delay at orderer, and so does the average transaction confirmation time. Take Fig. 10 as an example, when $M$ is 100, the average delay is about 500 microseconds higher than $M$ is 10, and about 108 microseconds higher than $M$ is 50, which provides an effective basis for the next experiment deployment.

The RC-chain design combined with the consortium blockchain Hyperledger Fabric platform can achieve the following security goals.

Distributed solution: RC-chain is a distributed VCS solution. It does not rely on a unified manager during the transaction process. It is difficult for an attacker to target all nodes in the network, which enhances its fairness and security while reducing the possibility of the entire network being threatened by a single point attack.

Permissioned identity: The CA utilizes an elliptic curve digital signature algorithm to generate keys and certificates for the entity. The identity information is bound to its registration information and the physical address of the device, which uniquely identify this entity. Entities with malicious historical behavior have a low reputation value and cannot forge identities to join the network.

Privacy protection: The channel mechanism provides transaction privacy and confidentiality for a specific subset of network members. All data on the channel, including transactions, members, and channel information, is invisible to members outside the channel, which preserves privacy.

Reliable reputation value management–TPFS model: The legal identity represents the historical behavior of the entity. Its reputation value is updated timely based on current behavior. By degrading the reputation value of those service participants with untruthful behavior, adversarial or irresponsible behavior can be prevented.

Transparent transaction process: Participants, be they requesters, servers, or the RSU, upload the main steps of the transaction to the ledger. Nodes with copies of the ledger in the same channel can review and supervise others. If the node is malicious, it is easy to be found and held accountable. An entity with malicious behavior risks being forced out of the network due to a dropped reputation value. Thus, RC-chain can effectively prevent malicious behavior.

Three-stage consensus to achieve BFT: The transaction can only move into the subsequent consensus stage after sufficient endorsement signatures have been gathered in the endorsement stage. Illegal transactions cannot secure this sufficient quantity of endorsement signatures, thereby reducing attacks on the network. CFT is achieved via the second-stage Kafka-based ordering service. The final step is the verification process, which eliminates any double spending phenomenon and reviews transactions again. RC-chain implements BFT via this three-stage consensus.

By using the Hyperledger Fabric running on Linux, we conducted another RC-chain experiment based on the results obtained from the above queueing theory model. We deployed RC-chain on a machine with Intel(R) Core(TM) i5-6300HQ CPU @ 2.30GHz and 6GB RAM running Ubuntu 18.04.4 LTS. The VCS network we built for this purpose contains three organizations, each one consisting of two peers and one orderer. The chaincode was written in GO language with the main functions of user registration, information query, data index acquisition, broadcast message, reputation value update, and server selection. According to the conclusion presented in Section 6.2, we set batch size $M$ to 10, with 3 clients submitting transactions randomly in parallel at an average arrival rate of 40. As shown in Fig. 11, we randomly selected trading within 52 minutes and observed it through Hyperledger Explorer. A total of 99784 transactions and 9983 blocks were generated during this period with an average throughput of 32 Tx/s. The throughput reached a maximum of 50 Tx/s and the system was operating in a stable state.

We randomly selected 10 consecutive blocks, calculated and analyzed the actual transaction confirmation time in Hyperledger Fabric, and compared it with the theoretical transaction confirmation time obtained by the queueing model. The results are shown in Table 3. Because the queueing model does not consider propagation delay or other certain factors, the theoretical value is smaller than the actual value on average; however, the average deviation is between them is small enough to consider our scheme realistic and feasible.

We also compared the transaction confirmation time with the framework QcFND in IoV-based Fabric (Xiao et al., 2020). We selected 30 blocks. Similar to the QcFND scheme, we selected five committing peers and calculated the average transaction confirmation time on five nodes with a batch size of 10 and batch timeout of 2s, with negligible time from clients to the endorsing peers. The average transaction confirmation time of 30 blocks was 0.312s in this case and the average transaction confirmation time of 52 minutes period was 0.315s, so we were able to consider the partial representing approximately the whole. As shown in Fig. 12, the average transaction time of the QcFND scheme was 2.194s and the average transaction time of RC-chain was 0.315s in this test; the transaction confirmation time of each of the 30 blocks is also shown in the figure.

As mentioned in Section  4.2, the public blockchain restricts the transaction throughput due to its consensus mechanism (and other factors), which makes the transaction confirmation time longer. The block generation time for Bitcoin is 600s and the throughput is (1048576/500)/600 $\approx$ 3.5 Tx/s. The average block time of Ethereum is 14.096s and the throughput is 71.428/14.096 $\approx$ 6.6 Tx/s, the number of their miners are 2200 and 100 respectively (Memon et al., 2019). Most IoV services require low latency, and the throughput of RC-chain with 6 endorsing peers is 32 Tx/s – in other words, our results suggest that the RC-chain based consortium blockchain has distinct advantages compared other public blockchain schemes.