A Scalable Protocol for Driving Trust Management in Internet of Vehicles With Blockchain

IEEE INTERNET OF THINGS JOURNAL, VOL. 7, NO. 12, DECEMBER 2020

overview

Background : Recent developments in the Internet of Things have facilitated the development of the Internet of Vehicles (IoV) with autonomous vehicles and roadside infrastructure as key components. However, due to the untrusted environment, it is difficult for the vehicle to assess the trustworthiness of the received information. Therefore, establishing trust in IoV is a critical security issue that has been limited by scalability challenges.

This paper proposes : This paper proposes a blockchain-based IoV protocol using smart contractssmart contracts, physical unclonable functionsphysically unclonable functions (PUFs), certificatescertificates, and a dynamic Proof-of-Work (dPoW) consensus algorithma dynamic proof-of-work consensus algorithm.

• Together with smart contracts, blockchain provides a security framework for registering trusted vehicles and blocking malicious ones.
• PUF is used to assign a unique identity to each trust-building vehicle.
• Certificates are issued by roadside units that protect vehicle privacy.
• The dPoW consensus allows the protocol to scale based on the incoming traffic generated by vehicles.

The traditional encryption method has inherent defects because it needs to store the key. Therefore, the industry has developed a new next-generation encryption technology that does not need to store the key, which is called PUF (Physically Unclonable FuncTIon, physically non-replicable function). This technology originated in the United States, and uses the difference in the physical structure of the chip produced by uncontrollable factors in the chip manufacturing process to generate a completely random key. Each chip is the key itself. From the perspective of the underlying physical structure, there are no two identical chips in the world, which guarantees the randomness and uniqueness of the key . Moreover, there is no need to save the extracted key, and it will disappear immediately after use, and the key can be extracted from the chip when it needs to be used. If the key is not saved, hackers will not be able to attack or steal it, which also solves the problem of key security.

PUFs have certain properties that make them an attractive option for IoV, such as physical security, low energy consumption, high throughput with low silicon area, low cost, simple structure, and non-reproducibility.

status quo

1. Most existing IoV trust management protocols do not provide reliable security measures, and lack reliable systems for secure vehicle registration and deregistration of vehicles .
2. Vehicle networks often rely on decentralized resources, and centralized systems are not suitable for establishing and managing trust in vehicle networks . However, most existing IoV applications rely on a centralized model.

• To solve 1, in this paper, we use the physically unclonable function PUF as the trust basis of the protocol. PUFs have certain properties that make them an attractive option for IoV, such as physical security, low energy consumption, high throughput with low silicon area, low cost, simple structure, and non-reproducibility.
• To address 2, we use blockchain to develop a decentralized protocol with no central authority that provides a secure method of managing vehicle registrations. However, running blockchain mining processes while supporting increasingly intelligent applications and their operations requires enormous computing and storage resources. Thus, different avenues (e.g., real-time processing, resource-intensive applications, mining, and consensus algorithms) have been identified to address the scalability challenges of blockchain-based solutions.

Quartet tradeoffs

Similar to the Distributed Theorem: The Consistency, Availability, Tolerance to Network Partitions (CAPs) Theorem for Distributed Systems states [8]: "A robust distributed system can only simultaneously provide two of the three properties.

Four trade-offs: scalability, decentralization, latency, security.

Similar to distributed systems: two out of three for consistency, availability, and partition tolerance. The blockchain system can also be seen as a four-way trade-off:

Scalability(Scalability): The scalability issue refers to the ability of a blockchain system to process transactions. In order for blockchain technology to become more ubiquitous, the system should be able to handle increasing transaction volumes across a wide range of applications.
Decentralization(Decentralization): Decentralization reflects the fragmentation of control over the entire system, which allows the system to achieve other goals: censorship resistance, public participation, protection from certain attacks, and elimination of single points of failure.
Security(Security): The blockchain system should guarantee the invariance of the ledger, general robustness against 51% attack, Sybil attack, distributed denial of service and other attacks.
Latency(Latency): The latency of the blockchain is measured by the time-to-finish (TTF), which is defined as the time when a transaction is completed/confirmed and becomes irreversible.
Examples:
比特币以太坊: To achieve good decentralization and security, but there are problems of insufficient scalability and finality.
Cardano和EOS: To achieve scalability (high throughput) at the expense of decentralization of block producers.
Cosmos和AION: Scalability, decentralization, and fast TTF at the cost of taking on additional attack risk.

Therefore, this paper focuses on designing a decentralized trust management protocol for IoV while addressing the four-party trade-off problem.

contribute

1. A decentralized and scalable protocol is proposed for vehicle trust management in IoV,

2. A reliable framework for managing vehicle registration is proposed through blockchain public key infrastructure (PKI) functionality and smart contracts.

3. A hardware primitive based on the assignment of different vehicle identities is proposed to protect its privacy via PUF as well as by issuing certificates.

4. Propose a dynamic consistency algorithm that can measure and change vehicle behavior based on the amount of incoming traffic generated by the vehicle.

5. Rigorous performance analysis of the protocol while addressing the four-way trade-offs of the blockchain.

6. A case study evaluating protocol dynamics and a comprehensive comparative analysis with state-of-the-art IoV trust management protocols

Research status

The traditional centralized system architecture of vehicular ad hoc networks (VANETs) is difficult to cope with the increasing complexity of ITS applications.

• Gazdar et al. propose a dynamic distributed trust model for establishing trust relationships among vehicles in VANETs.
• Lu et al. [19], [20] proposed BARS, a blockchain-based trust management system for vehicle networks, where they assign a trustworthiness score based on historical data of vehicles.
• Malik et al. [4] also proposed a framework for vehicle network authentication using blockchain.

However, these protocols only focus on the privacy protection of vehicles and fail to address their scalability issues.

• Singh and Kim proposed cryptographic trustpoints (cTp) using blockchain [28]. cTp enables vehicles to share data securely.
• Likewise, Shrestha et al. [27] discussed a blockchain-based IoV messaging service.

However, neither of these solutions can protect vehicle privacy.

• Zhang et al. [25] highlighted the amount of data generated in IoT networks and emphasized the importance of mobile edge computing to offset resource consumption in blockchain-based vehicle networks. Their solution helps reduce blockchain computing overhead, but the introduction of edge computing doesn't make it truly decentralized.

• Furthermore, Singh and Kim [26] proposed Trust Bit, a reward-based communication mechanism for vehicles. They use a blockchain with a unique encrypted ID (cID), which is issued by the vehicle owner for secure communication.

• Zhang and Chen [24] introduced a secure platform for sharing and storing data in a vehicle network using a consortium blockchain. However, using such a blockchain results in additional overhead and poor scalability.

• Yahiatene and Rachedi [18] discussed a blockchain and software-defined networking approach for securing a Vehicle Social Network (VSN). Their approach makes vehicle networks programmable, virtualized, and partitionable, while blockchain enables transaction authentication and maintains data integrity.

• Kaci and Rachedi [30] proposed PoolCoin, a distributed trust model for miner reputation management in the blockchain. This idea can be extended to research into outsourcing RSU computing load to mining pools, or allowing other miners to participate in regional RSU mining pools.

• Khelifi et al. [23] propose an interesting use of blockchain for network caching of IoV secure name data. ,

• Yang et al. [21] proposed a blockchain-based decentralized trust management protocol for vehicle networks.

• Finally, Lei et al. [22] discuss dynamic key management for heterogeneous vehicle systems. They use blockchain for their proposed key management protocol.

IoV-Blockchain protocol content

network model

Contains the following parts:

1. Vehicles : Each vehicle has its own blockchain account and a pair of public and private keys for encrypted communication.
2. RSUs : Traffic processing system units that provide wireless communication from roadside infrastructure to vehicles.
3. Smart Contract : A computer program script that can run autonomously. A public contract that interacts with the RSU to ensure that the data generated by the vehicle comes from a trusted source. In addition to the first time, it is also responsible for storing and reading data in the blockchain ledger.
4. Server/Miner : This represents a setup or group of setups that can interact with the network's RSUs and vehicles to provide different types of services, such as deploying the blockchain itself. Miners represent the computing resources of RSU.
5. Storage : The process of reading and/or writing data to storage devices in the blockchain, which can store different forms of data.
6. PUFs : A PUF is a "hardware fingerprint" that can provide a unique identity to a semiconductor device (such as a microprocessor, integrated circuit, etc.). PUF is usually characterized by a challenge-response pair (CRP), which can be expressed as $$R^i=PUF\left(C^i\right)$$Among them,$R^i$是质軉$C^{}$The response generated by${}^{i\; .}$Therefore, when using$C^{When\; i}$ is excited, each PUF generates a unique$R^i$。
7. Blockchain : A blockchain instance represents a locally distributed and geographically limited ledger that works with smart contracts.

protocol operation

The operation of the protocol consists of two phases:

1. vehicle registration stage
2. Data transfer phase of communication between vehicles

vehicle registration stage

When a vehicle generates data, the inspector checks that it is registered. If the vehicle is in the registration list, a PUF challenge will be sent to the vehicle. If it responds positively to the challenge, the link between the vehicle and the local blockchain will be successfully established. Finally, after these inspections, the RSU issues a certificate to the vehicle for certification.

Therefore, after the certificate is issued, the vehicle does not need to undergo these inspections again. Certificate issuance is a one-time operation, and certificates issued to vehicles are valid for the duration of their connection to the local blockchain. If the vehicle is removed from the registration list, the certificate issued to it will be revoked and it must repeat the setup phase again to register itself and obtain a certificate.

data transfer stage

Premise: Each vehicle has its own unique ID as well as a unique CRP stored in the blockchain.

It is worth noting here that the cryptographic fingerprint (cID) is used for secure communication in the IoV blockchain network.

The certificate is used to anonymize the identity of the vehicle to protect its privacy and reduce overhead, i.e. once a certificate is issued to the vehicle, it does not need to go through a PUF challenge to verify the identity.

Security Analysis & Assumptions & Threat Models

A. Hypothesis

1. Every car is equipped with PUF.
2. The PUF and the vehicle's microcontroller form a system-on-a-chip System-on-a-chip (SoC) , and any tampering will disable the PUF.
3. Given the SoC assumption, the PUF and the microcontroller communicate over a secure channel.
4. The standard assumption about PUFs is that each PUF is unique and non-identifiable, i.e. the adversary cannot predict its behavior. PUF can be modeled as: PUF : { 0 , 1 } l 1 → { 0 , 1 } l 2 PUF:\left\lbrace0,1\right\rbrace^{l_1}→ \left\lbrace0,1\right\rbrace ^{l_2}PUF:{ 0，1}l1​→{ 0，1}l2​, that is, the length of the PUF in use is $l_1$The input excitation will produce length $l_2$Output.

The protocol proposed in this paper uses a secure game between challenger C and adversary A $Ex{p}_{PUF,A}^{Sec}$Modeling PUF security, the game is defined as follows:

1. A randomly chooses a challenge $C^i$ and send it to C.
2. C obtains the response R i R^i through PUF$R^i$ parallel grip$R^i$ send to A.
3. C chooses a random challenge C x C^x that has not been used before$C^x$ , and get the response R x R^xthrough PUF$R^x$，即$R^x=PUF(C^x)$。
4. For $C^{For\; challenges\; other\; than\; x}$ , A can perform PUF queries of polynomial order.
5. A against $C^x$ challenge, output its guess value:$R^{x^{\prime }}$。
6. If $R^{x^{\prime }}=R^x$ , then A wins the game. The advantage of opponent A in this game can be obtained by$Ad{v}_A^{PUF}=Pr[R^{x\prime }=R^x]$to model.

B. Threat Model

A set of vehicles V = V1, V2, ..., Vn interacts with these secure blockchains S. But vehicles interact with the blockchain over an insecure network. At the end of the authentication phase, the entity is either registered with the network or rejected. If the authentication is successful, the vehicle can start transferring data by interacting with the contract. Adversary A assumes full control over the communication channels between vehicles and miners in the blockchain. This can include attacks such as eavesdropping, tampering, replaying and injecting packets into the network. The following are used to model these attacks:

1. SendS(S, m0, r0, m1): A imitates the behavior of a legal vehicle, and sends a message m0 to the blockchain S and receiver r0, and then the vehicle replies to S with a message m1.
2. SendM(ID, m0, r0): A mimics the behavior of the blockchain and sends a message m0 to A and receiver r0.
3. Monitor(M, S): Simulates the ability of A to continuously eavesdrop on the channel between vehicle V and blockchain S.
4. Drop(A): Simulates A's ability to drop packets between V and S.

For the various functions above, the opponent A can call the polynomial number of times.

C. Proof of Safety

lemma:

1. It is impossible for an adversary to tamper with the data in the blockchain.
2. It is impossible for the vehicle's secret response to be revealed.
3. PUF is safe against physical/cloning attacks.
4. The vehicle's public key cannot be linked.

theorem:

• Theorem 1: PUF realizes mutual authentication of vehicle and blockchain.
• Theorem 2 (Data Origin): The proposed protocol successfully establishes the authenticity of the data origin.

Simulation and Implementation

• Use the Solidity language to create an IoV blockchain network model.
• The dPoW consensus mechanism is written in Python3.7.3.

A. Simulation environment

• Laptop with Ubuntu OS (version 17.04).
• The computer specifications are as follows: Intel Core i7-7700HQ CPU (4 cores, @2.8 GHz), 16-GB RAM, Nvidia GeForce GTX 1060 GPU, 6 GB memory, 1 TB HDD, 128-GB SSD.
• The shell script environment is Terminal.
• The Ethereum development kit is used in the terminal, and nodes are instantiated using the Ethereum Go client (Geth), a command-line interface written in the Go language.
• Remix is ​​Solidity's browser-based IDE for writing and compiling smart contracts.
• web3.jsAllows RSU and vehicles to interact with local or remote Ethereum nodes using HTTP/IPC connections. The vehicle side uses web3.jsan HTTP connection to interact with the corresponding Geth client to send the request as a transaction to the smart contract and receive the authorization result. The RSU side web3.jsinteracts with the Geth client to deploy compiled smart contracts and host the local blockchain.

The algorithm will initialize two types of nodes, including a group of RSU nodes represented by R and a group of vehicle nodes represented by V. Each node has its own blockchain account and can interact with other nodes through smart contracts.

Each RSU node holds a snapshot of the blockchain, synchronized with its peer RSU nodes.

B. Contract execution process

The contract execution process consists of two operational phases:

1. Initialization: The RSU node will initialize the contract, which will be considered as a serviceable variable by the contract instance . Therefore, the contract can be compiled in the Geth terminal of the RSU node.
2. Deployment: Deploy the compiled contract on the RSU node, and then the RSU node continues to mine to obtain the contract address needed to interact with the contract instance. For interaction, the contract ABI is also required from the Remix IDE. Then, the contract address is broadcast among the vehicle nodes, enabling it to interact and communicate with the RSU nodes through the contract. Thus, RSU nodes can now authorize vehicles, register or delete them, and allow them to send requests as transactions.

Reference: https://www.jianshu.com/p/aa60e81825f8 : Application Binary Interface, ABI is an interface for interaction between programs, but the program is compiled binary code. So it is the same interface, but the information is passed in binary format. So the ABI must describe how to decode/encode binary information passed between programs.

C. Operating costs of the agreement

"gas" is the name of a special unit used by Ethereum . It measures how much "work" an action or series of actions takes to perform. Every operation that a transaction or contract can perform on Ethereum costs a certain amount of gas.

The importance of gas is that it helps ensure appropriate fees are paid for transactions submitted to the network . By requiring transactions to pay execution fees for each operation, we ensure that the network is not bogged down performing a lot of intensive work that is of no value to anyone. This is different from Bitcoin transaction fees, which are based only on the size of the transaction in kilobytes. Since Ethereum allows arbitrarily complex computer codes to be run, short codes can actually result in a lot of computational work being done. So it's important to measure the work done directly, rather than just choosing fees based on the length of the deal or contract.

Table III lists gas consumption estimates in Wei (ether) for the IoV blockchain protocol and its functions, which were obtained using the Remix IDE. The amount of gas required to execute the contract is 21 128, while the amount of gas required to deploy the contract is 985 200. sendMessage() and registryVehicles() have infinite gas estimates. This is because their input size is undefined.

Reference: Detailed explanation of gas-related concepts used in smart contract calls in Ethereum

Performance Analysis of IoV-Blockchain Quartet Tradeoffs

This section presents the performance evaluation of the protocol and discusses its efficiency from the perspective of blockchain's four-party trade-off. We also compare the performance of the protocol with respect to vehicle trust management with proposed schemes [21].

方案【21】：Z. Yang, K. Yang, L. Lei, K. Zheng, and V. C. M. Leung, “Blockchain-based decentralized trust management in vehicular networks,”IEEEInternet Things J., vol. 6, no. 2, pp. 1495–1505, Apr. 2019.

A) Scalability

A blockchain consists of a chain of blocks, where each block contains metadata (previous hash) and data (tuples of transactions). This means that the length of the blockchain keeps increasing over time. Therefore, we evaluate the scalability of the proposed protocol from two aspects:

1. Communication overhead

Consider the maximum packet size required for transmission using the proposed protocol of [21], as shown in Table VII. We observe that the communication overhead of our proposed protocol is 36% lower than that in [21]. To study the scalability of the protocol in terms of communication overhead, we show in Fig. 4 the effect of increasing the number of vehicles on the communication overhead. It can be seen that the protocol is more scalable than [21] and can manage more vehicles with less overhead.

2. dPoW consensus

We define the dPow consensus algorithm with the four scenarios listed in Table IV.

We observe that the mining difficulty is highest when the arrival rate is low, and the mining target value is defined by the four significant bits of the mining hash. Likewise, when the arrival rate is high, the mining difficulty is lowest, and the target value is defined by one significant bit of the mining hash. This allows the protocol to scale efficiently, i.e. a low arrival rate with high mining difficulty improves security fidelity, while a high arrival rate with low mining difficulty increases throughput, allowing more blocks to be mined in less time.

We simulated the scenario of 1000 blocks mentioned in Table IV, with 100 virtual transactions in each block, as shown in Fig. 7.

As shown in Figure 7(a), the total time required to mine 1000 blocks under the scenario δ = 4 is almost 5 seconds [i.e. about 20 000 transactions per second (tx/s)].
Figure 7© and (e) show that under the scenario δ=3.2, the total time required for mining is about 50 and 650 seconds (i.e., 2000 and 150 tx/s), respectively.
As can be seen in Figure 7(g), the total time spent mining a block under the scenario δ=1 is 10 000 s (ie 10 tx/s).

Therefore, it can be concluded that the throughput is lower for low arrival rate and higher for high arrival rate, which makes the proposed protocol scalable.

B. Decentralization

The degree of decentralization of a blockchain can be assessed by the distribution of its control and resources among miners .

In order to process requests generated as transactions in an IoV blockchain network and ensure its smooth operation, miners (RSUs) need to verify transactions and generate blocks efficiently. Therefore, miners need to complete the following steps: 1) collect, verify, and organize transactions into a block and mine it; 2) broadcast the mined block in the network to reach consensus and attach it to the blockchain.

To measure the degree of decentralization of the protocol, consider an IoV blockchain system with N peer nodes and M miner nodes. Note that peer nodes represent miner nodes and server nodes.

• Node set: N = { n 1 , n 2 , … , n N } \mathcal{N}=\left\lbrace n_1, n_2, …, n_N \right\rbraceN={ n1​，n2​，…，nN​}。
• 设计能动：$c=\left\{c_1,c_2，\dots ,c_n\right\}$ , node$n_n$The computing power of $c_n$express.
• 矿工： M = { m 1 ， … ， m m ， … ， m M } \mathcal{M}=\left\lbrace m_1，…，m_m，…，m_M \right\rbrace M={ m1​，…，mm​，…，mM​}，$\mathcal{M}\subseteq N$ , fromN \mathcal{N}Choose from$N.$

Assume that according to the density λ ( x ) λ(x)A non-uniform Poisson point process (PPP) of$\lambda$$($$x$$)$$R^{}$Independent random positions in${}^2$$n_n$The position of the two-dimensional coordinate $x_n\in R^2$， x = { x n } x=\left\lbrace x_n \right\rbrace x={ xn​} is the location set.

Density $\lambda \left(x\right)$ is defined as for any$A\subseteq R^2$，$E\left\{Num\left(A\right)\right\}={\iint }_A\lambda （x）dx\subseteq R2$ , where$Num\left(A\right)$ is the number of nodes in area A.

To measure decentralization, this paper uses the Gini coefficient , a well-studied measure of wealth or income inequality . We measure decentralization by considering the geographical distribution of RSUs . Since the miner density distribution λ(x) is a continuous function of x, the Gini coefficient of miners with respect to (wrt) geographical distribution can be expressed as
$$g\left(\lambda \right)=\frac{{\int }_a{\int }_a|\lambda (x)-\lambda (y)|dyd}{{\int }_a{\int }_a\lambda (x)dydx}=\frac{{\int }_a{\int }_a|\lambda (x)-\lambda (y)|dyd}{2M}$$
Among them, a represents the density set as $l=\left\{\lambda \left(x\right)\right\},x\in$The area related to the two-dimensional coordinates (x, y) of$a$$a\subseteq R^2$。

Note that the value of the Gini coefficient is in the range [0,1], where 0 means perfect dispersion and 1 means perfect concentration . Therefore, the more dispersed or uniform the geographical distribution of miners is, the closer the coefficient is to 0. In addition, in order to ensure the geographical dispersion of miners, the following constraints need to be satisfied: $$g\left(\lambda \right)\le {the}_g,\forall {\eta }_g\in [0,1]$$

where $n_g$Decentralization threshold w.r.t geographic distribution for miners .

Figure 5 shows the decentralized performance of the protocol. It can be seen that as the value of the Gini coefficient decreases, the Lorenz curve gradually approaches the ideal decentralization, that is, the blockchain becomes more decentralized . As can be seen from the figure, for three different values ​​of the Gini coefficient, different regions of the Lorenz curve. Higher values ​​of the Gini coefficient mean that the distribution of miners is more concentrated, while lower values ​​mean that their distribution is more dispersed.

C. Latency

Similar to MAC/PHY (Media Access Control and Physical layer) overhead, latency is also an important performance indicator for IoV, as it represents the total time it takes for a vehicle to successfully authenticate itself and its requests via the RSU . Therefore, the latency of our proposed protocol is evaluated from two aspects:

1. We study the authentication latency on the RSU side, i.e. the time it takes for the RSU to authenticate the vehicle.
2. We study the TiF of transactions generated by vehicles , i.e., the time it takes for a transaction to be completed and irreversible.

1. RSU identity authentication delay

Figure 6 shows the comparison of the vehicle authentication latency on the RSU side between the protocol proposed in this paper and the protocol proposed in [21]. For a fair comparison, we simulated both protocols using the parameters given in Table VI. Results obtained using a custom discrete-event simulator in MATLAB confirm that the authentication latency of the proposed protocol is significantly lower than [21]. This reduces the burden on RSUs, allowing them to efficiently manage trust as the number of vehicles increases.

二、TiF（Time-to-Finality)

For TiF, we consider the same four scenarios listed in Table IV. Transaction processing in the protocol proposed in this paper requires two steps: adding transactions together, forming a block and mining it, and reaching consensus on the mined block. Therefore, we formulate TiF for vehicle-generated transactions, which includes block mining time (i.e., block interval) and block verification time, as follows:
$$t_{f,}=t_{i,}+t_{c,},d=1,2,3,4$$
of which$t_{i,}$Represents the block interval time, which depends on the choice of δ, and δ represents the consensus delay, that is, the time it takes miners to verify a block. For simplicity, assume a consistent latency of 1, since validating a block is simple and requires input proof values ​​to generate the target hash. Therefore, we only consider the blocking interval, and mainly focus on the mining dynamics of the protocol under different transaction arrival rates .

We simulate the scenario of 1000 blocks in Table IV with 100 virtual transactions per block, as shown in Figure 7.

• Under the scenario δ=4, the number of hash iterations of each block (that is, the TiF of 100 transactions) is shown in the figure. 7(b) peaks at 120 hash iterations per block (h/b, hash iterations per block).
• Similarly, the number of hash iterations under the scenario δ = 3.2 is shown in Fig. 7(d) and (f), with peak values ​​of 2500 and 35000 h/b, respectively.
• Furthermore, Fig. 7(h) shows the number of hashing iterations per block under the scenario δ = 1 (peak around 400 000 h/b).

Therefore, we can conclude that TiF is high for low arrival rates and low for high arrival rates, which allows our protocol to operate with low latency .

Therefore, in our proposed protocol, vehicles should obtain the finality of transactions within a short period of time. In order to meet the IoV blockchain latency requirement, it is assumed that a block should be in consecutive block intervals (ie $△(△>1)$ mined and verified within a block interval). Specifically, TiF should satisfy the following constraints
$$t_{f,}\le {△}_{t_i},d=1,2,3,4$$

It can also be observed that the effect of the block interval on the blockchain is twofold:

1. Reducing the block interval can improve throughput, as shown in Figure 7;
2. TiF increases proportionally with block intervals, as larger intervals translate into more transactions to be verified. Furthermore, the reduction of the block interval imposes a tighter constraint on the consensus latency, which is closely related to the dynamics of miners and the chosen consensus algorithm.

Therefore, the block interval, miner distribution, and choice consensus dynamics should be carefully tuned to address the four-way trade-off.

D. Security

Our proposed protocol uses a variant of the PoW consensus algorithm, namely dPoW. As long as the number of honest miners is greater than malicious miners, PoW provides a high degree of security. In theory, an adversary/group of adversaries could, by using (>50%) mining power, potentially mine another "longer" chain that goes back to the genesis block. Therefore, the loyalty of honest miners is crucial in PoW. To guarantee the security of the proposed protocol using the consensus algorithm δ, the number of malicious miners $n_m$subject to the following constraints:
$$n_m\le n_{m,},d=dPoW$$

任作$n_{m,}=\lfloor [(n_{h,}-1)/2]\rfloor$ represents the maximum tolerable number of malicious miners in the proposed protocol, ie$<50$，$n_{h,}$Indicates the total number of honest miners.

To analyze this, we consider a scenario where an attacker tries to create a chain of dishonest miners that is faster than the chain of honest miners. The competition between the attacker and honest miners can be described as a binomial random walk. And give the definition of success and failure:

• success: Indicates that the honest chain has been extended by one block, thereby increasing its lead over the dishonest chain by +1.
• failure: Represents that the dishonest chain is extended by one block to reduce the gap, ie -1.

Furthermore, the possibility of an attacker chasing blocks later in the honest chain is similar to the gambler's bankruptcy problem. Suppose a gambler starts with a given deficit, has an infinite line of credit, and may make an infinite number of attempts to reach the break-even point. Then, the probability of the attacker catching up with the honest chain is given by
$$Q_n=\{\begin{array}{llc}1& ,if& p\le q\\ (\frac{q}{p}{)}^n& ,if& p>q\end{array}$$

Among them, $p$ is the probability that an honest miner finds the next block,$q$ is the probability that the attacker finds the next block,$Q_n$is the probability of an attacker catching up from a block behind the honest chain. Figure 8 shows the ineffectiveness of this attack as long as honest miners own more than 50% of the total computing power.

It can be seen that when $p=1,0.9,0.8,At\; 0.7and0.6$ , the attacker$Q_n$The probability of exploiting the honest chain attack decreases exponentially with the number of blocks, i.e., after only ten blocks, $Q_n$down to 0. When $p=0.5$ ,$Q_n$Increased to 1, this confirms that whoever controls more than 50% of the total computing capacity of the protocol controls its blockchain . However, considering our assumption $p>q$，$Q_n$The attack drops off exponentially as the number of blocks the attacker has to catch up to increases, rendering the attack ineffective.

In addition, the authenticity of transactions is guaranteed by digital signatures . The protocol uses Elliptic Curve Cryptography (ECC) and Elliptic Curve Digital Signature Algorithm (ECDSA) to ensure that the data generated by the vehicle is legitimate. Table V [45] gives common comparisons between ECC and Rivest–Shamir–Adelman (RSA), Diffie–Hellman (DH) and Digital Signature Algorithm (DSA). We observe that ECC can achieve higher levels of security with smaller key lengths, which reduce computational overhead.

case study

We designed a case study for our protocol using OSMWebWizard 's Urban Mobility ( SUMO ) simulation package. SUMO is an open source, microscopic, highly portable and continuous road traffic simulation software package designed to handle large road networks. We consider the Chinatown area of ​​Singapore, which has 100 left-hand drive nodes, including vehicles, buses and trucks, traveling at an astonishing speed of 33 m/s with no standstill time. Figure 9 shows the steps taken to extract a considered map segment with a route length of approximately 1300 m. After extracting map segments, SUMO generated a map configuration (.cfg) file, which was first converted to a vehicle trace file (.xml), and then, a vehicle movement trace file (.tcl )

A. IoV blockchain protocol dynamics

To analyze our protocol, we use ns-3 , a discrete-event network simulator for Internet systems.

From the mobile tracking files, we defined a custom VANET using the Wireless Access to Vehicle Environments (WAVEs) protocol and the parameters listed in Table VI.

The standard for the WAVE protocol is IEEE [email protected] GHz (the current state of the art for the vehicular environment), a 10 MHz control channel with continuous access to all traffic generated by the vehicle.

• The simulation was run for 100 seconds with 100 vehicles and 10 RSU nodes respectively. In addition, the vehicle nodes were in the 650×650 m 2 m^2 of the extracted map segment according to the movement tracking file$m^{}$Move within the${}^{2\; area.}$
• All vehicle nodes transmit 512-B block headers to the RSU at a rate of 6 Mb/s at a frequency of 10 times per second, that is, broadcast 10,000 block headers per second.
• All vehicles attempt to continuously send 64-B application packets to other nodes at a rate of 2.048 kb/s.
• The routing protocol used by the vehicle is OLSR, and the two-ray ground loss model is combined with the Nakagami attenuation model.
• The transmit power of the vehicle is set to 20 dBm, and the RSUs are 50 m apart.

We calculate the delivery of blockchain packets based on the Packet Delivery Ratio (PDR), which is the number of packets sent to the RSU divided by the number of packets it actually received. We did this for all ten RSUs to see the effect of decay with distance.

B. MAC/PHY Overhead

In the current trust management protocol of the Internet of Vehicles, the broadcast channel is full of vehicle authentication requests. This impacts application throughput and can also overload the RSU, causing longer authentication delays. Therefore, the MAC/PHY overhead is critical to the performance of IoV. Its value is in the range [0,1] and is given by
$$MAC/PHYoverhead=(totalPHYBytes-totalAppBytes)/totalPHYBytes\; Among\; them,$$
PHYBytes represents the traffic of the physical layer, and AppBytes represents the traffic of the data link layer$$.$$MAC/PHY overhead can be viewed as a moving average of protocol overhead over time.

C. Discussion and assessment

• Figure 10(a) and (b) show the protocol's application data and application packet reception rates. Note that the number of bits transmitted per second represents the data rate, and the vehicle node is said to be transmitting 64-B application packets at a rate of 2.048 kb/s. We can see that the total application throughput remains at an average of 150 kb/s, while the application packet reception rate remains at an average of 30 packets per second (pps) . We observe that our protocol hits the throughput ceiling in the current scenario under IEEE 802.11.
• Figure 10(c) shows the associated MAC/PHY overhead, whose low value indicates the efficiency of our protocol.
• Furthermore, Figure 10(d) shows the PDRs of ten RSUs, representing the blockchain data packets broadcast by vehicles to the RSUs. RSU1 is the earliest and has the highest PDR, while RSU10 is the farthest and has the lowest PDR due to channel fading.

Therefore, these results demonstrate the effectiveness of our proposed protocol in IoV.

D. Comparative Analysis

In this section, we compare our protocol with the state-of-the-art protocol proposed by Yang et al. [21]. For a fair comparison without loss of generality, we simulated both protocols using the parameters explained in Section VII-a.

The simulation results and improvements are reported in Table VII, while Figure 11 shows a graphical depiction of the kinetic comparison. We observe that our protocol outperforms [21] in all comparison metrics. Fig. 11(a) shows that the total receiving rate of application traffic for the protocol in [21] is 140 kb/s on average, while our protocol is 150 kb/s, i.e., the receiving rate is increased by 7.15%. Figure 11(b) shows that the application packet throughput of [21] is about 25 pps, while our protocol is 30 pps. This is because the packet size transmitted in [21] is 800 B, while in our protocol, it is 512 B.

Similarly, Fig. 11(c) shows that the MAC/PHY overhead of our protocol is lower than that of [21]. We observe that after 100 seconds, [21] has a MAC/PHY overhead of 16.55%, while our protocol has a MAC/PHY overhead of 11.39%. Furthermore, comparing Figures 10(d) and 11(d), it can be seen that our protocol also outperforms [21] in PDRs with different RSU locations. Hence, our protocol is able to drive trust management for more vehicle entry times due to higher throughput and lower overhead and packet size, which can be verified by the RSU PDR detailed in Table VII. This also makes the proposed protocol well scalable.

Summarize

This paper investigates the problem of vehicle trust management in IoV and proposes a blockchain-based protocol that uses smart contracts with PUF, certificates, and the dPoW consensus algorithm. Blockchain and contracts form the basis of a decentralized IoV network by managing vehicle registration. PUF provides each vehicle with a unique fingerprint, thereby building trust. RSU issues certificates that protect vehicle privacy. Additionally, the dPoW consensus allows the protocol to scale with the incoming traffic generated by vehicles. Our proposed protocol is also able to distinguish registered vehicles from malicious vehicles by managing the list of registered vehicles.