Improving Security in the Internet of Vehicles: A Blockchain-Based Data Sharing Scheme

Abstract

To ensure the aggregation of a high-quality global model during the data-sharing process in the Internet of Vehicles (IoV), current approaches primarily utilize gradient detection to mitigate malicious or low-quality parameter updates. However, deploying gradient detection in plain text neglects adequate privacy protection for vehicular data. This paper proposes the IoV-BDSS, a novel data-sharing scheme that integrates blockchain and hybrid privacy technologies to protect private data in gradient detection. This paper utilizes Euclidean distance to filter the similarity between vehicles and gradients, followed by encrypting the filtered gradients using secret sharing. Moreover, this paper evaluates the contribution and credibility of participating nodes, further ensuring the secure storage of high-quality models on the blockchain. Experimental results demonstrate that our approach achieves data sharing while preserving privacy and accuracy. It also exhibits resilience against 30% poisoning attacks, with a test error rate remaining below 0.16. Furthermore, our scheme incurs a lower computational overhead and faster inference speed, markedly reducing experimental costs by approximately 26% compared to similar methods, rendering it suitable for highly dynamic IoV systems with unstable communication.

1. Introduction

The Internet of Vehicles (IoV) seamlessly integrates Vehicle-to-Vehicle (V2V), Vehicle-to-Road (V2R), and Vehicle-to-Infrastructure (V2I) communications by employing onboard equipment as the communication medium [1,2,3]. IoV represents a comprehensive network that facilitates wireless communication and data sharing among vehicles, individuals, and road infrastructure. Its versatile capabilities encompass traffic flow forecasting, vehicle position monitoring, dynamic data exchange, route selection and planning, and optimal driving experiences [4,5]. In the dynamic context of motion, vehicles continually generate diverse data types, including multimedia data, intricate driving trajectories, and real-time traffic information [6]. The abundance of data can result in communication congestion and potential redundancy [7]. Consequently, concerns regarding single points of failure and privacy breaches hinder users from actively participating [8]. Given these issues, current approaches to utilizing a centralized server for data collection become impractical [9,10]. Traditional machine learning approaches may not be well suited for highly dynamic IoV systems that are characterized by unstable communication [11].

Federated Learning (FL) has emerged as a privacy-preserving approach, ensuring both the availability and privacy of original data. Integrating FL with IoV offers various advantages, such as increased efficiency, improved privacy, decreased response time, and enhanced practicability [12,13]. The central server updates the global model by utilizing the collected local models, while the private data are stored locally. This approach can solve specific security concerns linked to the transmission of original data, but it does introduce a reliance on third-party aggregators, thereby exposing itself to potential attacks, such as single points of failure, data tampering, and privacy breaches. The balance among these issues holds paramount importance in realizing a harmonious fusion of FL and IoV.

Blockchain provides decentralized and tamper-resistant functionality to IoV through various methods, such as data encryption, timestamps, and distributed consensus [14,15], effectively enhancing security and privacy within the IoV. By eliminating centralized management in traditional IoV systems, blockchain reduces reliance on cloud-based data storage and management, enabling any two entities (e.g., individuals, RSUs, and vehicles) to engage in peer-to-peer transactions, sharing, and communication. Directly maintaining vehicle services and transactions through blockchain facilitates significant reductions in operating costs and system risks. Establishing robust trust relationships among initially untrusted entities enhances the credibility of vehicle data through reliable verification, consequently reducing the possibility of fraud and false data dissemination. Nodes in the blockchain review uploaded models and securely store them in immutable ledgers, using cryptographic technology to enhance the security and privacy within this IoV system. Smart contracts facilitate the deployment and execution of predefined rules or scripts. In conclusion, integrating blockchain into an IoV system enhances the security, reliability, and credibility of data, reduces system costs, and enables rapid sharing and exchange of vehicle information among multiple entities [16,17]. This solution not only mitigates the risk of training nodes sharing malicious and redundant data but also ensures the security and quality of the model. Moreover, it achieves dynamic selection and control of blockchain nodes, resolving concerns of privacy breaches during task allocation processes. This, ultimately, enhances the throughput and efficiency of the IoV system [18,19].

Figure 1 illustrates that the integration of Federated Learning (FL) and blockchain is commonly used for data sharing in the Internet of Vehicles (IoV) [20,21,22]. However, there exists a potential vulnerability whereby training nodes can upload malicious models.

Although vehicles undergo verification upon participating in an FL task, complete trust cannot be guaranteed. Vehicles have the potential to engage in malicious behavior during the training process. If each vehicle utilizes the initial model obtained from the roadside unit, there is the possibility of intentionally tampering with a certain proportion of training results or submitting incorrect gradients [23], thereby increasing the likelihood of data misclassification and results manipulation [24]. As a result, false and invalid traffic information may manifest in the IoV system. Some scholars have used gradient detection to identify models that deviate significantly from normal models by calculating the distance. This method effectively filters out malicious model updates to prevent potential damage. However, this assumes that the central aggregator can clearly observe updates during gradient detection, without considering the potential risk of privacy breaches for participating users. Previous studies [25] have shown that in the presence of an unsecured edge computing wireless communication channel, when a node uploads parameters to the RSU in plain text, external adversaries can still launch inference attacks on parameter updates, inferring the original training data (e.g., gradient and weight). Consequently, private information about these vehicles [26] or sensitive data on the model updates [25] (e.g., the original distribution of the training data) could be compromised. Moreover, because of the curious and dynamic nature of each vehicle, there is a possibility that it may intentionally attempt to access the private information of other vehicles. In an IoV system characterized by unstable communication, intermittent disconnections may occur, which can negatively impact the aggregation of the global model.

In this paper, we propose IoV-BDSS, a new data-sharing scheme that distinguishes itself through its expert incorporation of blockchain and federated learning techniques. This scheme enables the filtration and sharing of data within an Internet-of-Vehicles (IoV) environment. The primary contributions of this study are presented as follows:

• We designed an innovative data-sharing scheme for the IoV, employing a secret-sharing algorithm based on the Chinese remainder theorem as an alternative to homomorphic encryption. Our proposed scheme significantly mitigates the computational overhead related to encrypting and decrypting training results.
• To optimize the training effectiveness and efficiency, we innovatively utilized the Euclidean distance to select vehicles that exhibit high data similarity to the task issuer. Furthermore, we improved the Multi-Krum algorithm and integrated it with the secret-sharing algorithm to achieve ciphertext-level filtering of toxic parameter updates. This integration helps optimize the training process further.
• We implemented assessment mechanisms to evaluate the contribution of RSUs and the credibility of vehicles, further ensuring the reliability of training. Furthermore, coupled with the improved consensus mechanism, this enables the secure storage of high-quality models on the blockchain.
• Our proposed scheme was implemented utilizing FISCO BCOS as the underlying distributed framework for the IoV, coupled with FL deployment. Performance validation was conducted using two real datasets. The experimental results demonstrate its effectiveness in ensuring the protection of private data, and our model outperforms other advanced approaches in terms of the overall performance.

The following sections of this paper are organized as follows: Section 2 presents the related work; Section 3 describes the system architecture; and Section 4 introduces the overall process of the IoV-BDSS in detail. Then, Section 5 analyzes the security of the system, while Section 6 conducts simulation experiments and evaluates the performance. Finally, Section 7 presents the conclusion of the full text.

2. Related Work

Federated learning has shown successful applications in the Internet of Vehicles (IoV), including accurate predictions in domains like heavy vehicle driving status forecasting and unmanned drone lighting status monitoring [27]. However, the current IoV system still encounters challenges related to the privacy of vehicle information, despite notable advancements in these applications [16]. To address these challenges, the integration of blockchain and federated learning emerges as a critical component within the IoV. A Blockchain-Based Federated Learning (BFL) system was proposed by Pokhrel et al. [16], enabling updates for local on-vehicle machine learning via a consensus mechanism, eliminating the necessity of the centralized coordination of data or other entities. Chai et al. [20] introduced a federated learning framework that facilitates data sharing, leveraging a hierarchical blockchain, utilizing Roadside Units (RSUs), and implementing a two-layer Proof of Knowledge (PoK) consensus mechanism, all while formulating the transaction process as a multileader and multiparty game.

Previous schemes aimed at protecting data privacy and defending against poisoning attacks primarily utilized centralized anomaly detection, Secure Multiparty Computation (MPC) [28], Homomorphic Encryption (HE) [29], and Differential Privacy (DP) [30]. HE guarantees that the encrypted computation results are identical to the original ones, thereby enhancing computation task security. However, because of the high computation and communication requirements and the assumption that all participating nodes are reliable [29], it is not appropriate for highly mobile IoV. In contrast, DP has lower computation and communication overheads. It adds noise to the original data, making it challenging for attackers to reverse engineer stolen results and access the original data. Additionally, DP-AFL [30] is a federated learning algorithm used for vehicular networks that incorporates Local Differential Privacy (LDP) into the training process, avoiding the security threats of centralized aggregation through a distributed asynchronous update scheme. Wang et al. [31], on the basis of Local Differential Privacy (LDP), randomized local model parameters and proposed a Reinforcement Learning (RL)-based incentive mechanism to encourage high-quality model parameters sharing by drones in dynamic systems. However, Differential Privacy (DP) disturbance is irreversible and may significantly affect training accuracy while performing poorly in Byzantine attacks. Some scholars later proposed machine learning algorithms based on secret sharing [28], which can securely output results for untrusted parties without revealing the original data in the absence of a trusted third party. The most commonly used secret-sharing scheme is Shamir [32], it has additive homomorphism, meaning that the sum of the shares of two secrets is equal to the share of the sum of the secrets, and low computational complexity, making it appropriate for the gradient aggregation process in FL. However, this scheme requires both the secret distributor and participating nodes to be honest and trustworthy.

Although the aforementioned schemes have successfully computed the aggregation results and demonstrated resilience against inference attacks, they remain susceptible to poisoning attacks. To mitigate this concern, Lu et al. [33] put forth an architecture that combines federated learning and hybrid blockchain. The objective of this architecture is to minimize transmission overhead and safeguard the privacy of data providers. They introduced a novel consensus mechanism named PoQ to mitigate the impact of malicious updates. However, identifying malicious nodes solely after the completion of training may entail supplementary computational expenses for retraining the global model, and the absence of a mechanism to eliminate these malicious nodes could result in irreversible deterioration of model accuracy. Bulyan’s [34] cross-comparison scheme is well suited for nodes with independently and uniformly distributed data, although it does come with the drawback of high computational complexity. Trim Mean [35] utilizes statistical methods to compare local gradients, demonstrating effectiveness solely in scenarios in which the node data are independently and uniformly distributed. In the aggregation process, Multi-Krum [36] can identify and eliminate malevolent users, thereby ensuring that the proportion of malicious models remains within an acceptable threshold. Biscotti [37] guarantees data privacy by employing PoF consensus and Verifiable Random Functions (VRFs), while achieving secure aggregation through differential privacy and the Shamir algorithm. Nonetheless, this centralized verification method encounters challenges related to single points of failure and compromised accuracy.

There is currently a lack of a holistic and decentralized solution available to effectively mitigate inference attacks and poisoning attacks in the Internet of Vehicles (IoV). To strike a balance between development and user privacy requirements, it is crucial to conduct more comprehensive research. These efforts not only facilitate the enhancement of trust but also promote continuous technological advancements.

3. System Model and Security Objectives

3.1. System Model

Figure 2 illustrates that the IoV-BDSS consists of five main components:

(1) Task Issuer: The task issuer creates a training model based on its needs and releases Federated Learning (FL) tasks through the blockchain. As more and more vehicles join and contribute to FL tasks, the task issuer gradually obtains an ideal model.

(2) Roadside Unit (RSU): RSUs are wireless devices installed on roadsides or specific locations to serve as crucial intermediaries between task issuers and nearby vehicles. They play a vital role in facilitating communication among these entities. RSUs are primarily responsible for distributing FL tasks, filtering out malicious parameters, decrypting, and aggregating the training models. Additionally, RSUs can operate as miner nodes within the blockchain. Multiple RSUs engage in a competitive process to validate the accuracy of the aggregated results, and the winning RSU, acting as the miner, subsequently records the validated global model on the blockchain using a consensus mechanism. Equipped with computing and storage capabilities, each RSU possesses a pair of public and private keys. Once the number of vehicle nodes uploading training results reaches the threshold of secret sharing, an RSU can restore the master key and decrypt the training results.

(3) Certification Authority (CA): The CA is responsible for generating, distributing, and maintaining secret keys, as well as registering vehicle identities. Once it has generated the master key and secret share, the CA encrypts and distributes them to the relevant parties. Vehicles participating in the FL task employ the master key provided by the CA to encrypt their training results before sending them to the RSUs. This ensures that the training data remain secure and protected during transmission and storage. In summary, the CA is responsible for managing the security of the FL process, ensuring that only authorized vehicles have access to the model and that the data are encrypted using a secure key.

(4) Vehicle: As a mobile edge computing device, the vehicle is mainly responsible for data collection, storage, and preprocessing. In each round, it downloads the global model and employs it to train local data. Additionally, it assists the RSU in the filtering process and calculates the Euclidean distance among neighboring vehicles. Then, using the master key provided by the CA, it encrypts the training results before uploading them to a nearby RSU. The training process is reiterated until the global model reaches the desired accuracy.

(5) Blockchain: The blockchain in this system is primarily constructed and maintained by distributed RSUs, which are the default configuration of the consortium chain and do not allow external registration. These RSUs are classified into two types: miner nodes and ordinary nodes. Miner nodes possess write permissions, generate new blocks, and oversee the consensus process. Ordinary nodes do not have write permission but contribute to the system. Miner nodes are selected from ordinary nodes based on their contribution, which is evaluated using the accuracy deviation value of the aggregated results. Nodes with higher contributions will be designated as miner nodes. Consensus is reached solely among miner nodes during the verification process of a new block, without disseminating consensus messages to all ordinary nodes. Thus, this approach reduces communication overhead and enhances the consensus efficiency of the IoV system.

3.2. Security Objectives

(1) Ensuring the Accuracy of Global Models: To guarantee the accuracy of the global model, our proposed scheme incorporates the Multi-Krum algorithm and a consortium chain. By using a smart contract, we calculate the Euclidean distances between models and implement a secret-sharing algorithm to filter out malicious updates at the ciphertext level. Subsequently, we employ a vehicle node selection algorithm based on the Euclidean distance to choose vehicles that closely match the data of the task issuer. We evaluate the contribution of each RSU node by assessing the deviation value of accuracy within the models. RSUs that contribute more are designated as miner nodes and are responsible for storing high-quality models on the blockchain. If all participating nodes diligently adhere to the protocol process, the task issuer can, ultimately, obtain a precise model.

(2) Ensuring the Privacy of Filtered Models: Privacy is a significant concern in our scheme, especially regarding the filtered results after removing malicious parameters. To address this, we encrypt these parameter updates using a secret-sharing algorithm, ensuring that plaintext forms are not directly transmitted to RSUs. This prevents external adversaries from inferring the intermediate parameters and sensitive local data of vehicle nodes based on the ciphertext updates, thereby preserving data privacy. Importantly, both vehicles and RSU nodes will refrain from disclosing private data unless explicitly disclosing the training results. Throughout the collaborative training process, other participating vehicle nodes cannot access original data either directly or indirectly. By leveraging the threshold secret-sharing algorithm, even if a limited number of training vehicles engage in collusion, RSU nodes can algorithmically reconstruct the initial secret, providing robustness in IoV environments facing unstable communication.

4. Details of Our Proposed Scheme

In this section, we provide a comprehensive outline of the IoV-BDSS workflow.

Table 1. Summary of main notations.

Acronym	Description
${\mathrm{N}}_{\mathrm{V}}$	The number of vehicles
${\mathrm{V}}_{\mathrm{i}}$	The i-th vehicle
${\mathrm{N}}_{\mathrm{R}}$	The number of RSUs
${\mathrm{R}}_{\mathrm{j}}$	The j-th RSU
$\mathrm{t}$	The current training round
${\mathrm{GM}}_0$	The initial global model
${\mathrm{GM}}_{\mathrm{t}}$	The global model for the t-th round
${\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}$	The local update of ${\mathrm{V}}_{\mathrm{i}}$ for the t-th round
${\mathrm{Cert}}_{{\mathrm{V}}_{\mathrm{i}}}$	The identity of the i-th vehicle
${\mathrm{R}}_{\mathrm{a}}{, \mathrm{R}}_{\mathrm{b}}$	The honesty and malicious thresholds
${\mathrm{Rep}}_{\mathrm{st}}$	The reputation threshold of an FL task
${\mathrm{Rep}}_{\mathrm{i}}$	The reputation of a vehicle
${\mathrm{M}}_{{\mathrm{R}}_{\mathrm{j}}}$	The aggregated model of the j-th RSU
${\mathrm{Con}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}$	The contribution score of the j-th RSU

below summarizes the main notations used in our proposed scheme.

4.1. System Initialization

(1) RSU Public–private Key Pairs Generation: The RSU randomly selects two large prime numbers, represented as $\mathrm{p}$ and $\mathrm{q}$. It then calculates the public modulus: ${\mathrm{m}}_{\mathrm{R}}=\mathrm{p}\times \mathrm{q}$. The number of binary digits of ${\mathrm{m}}_{\mathrm{R}}$ is equal to the length of the RSA key ${\mathrm{L}}_{\mathrm{RSA}}$. According to the values of $\mathrm{p}, \mathrm{q}$, and ${\mathrm{m}}_{\mathrm{R}}$, the RSU can calculate the Euler’s number, $\mathrm{r}$, using the following formula: $\mathrm{r}=\mathsf{\phi }\left({\mathrm{m}}_{\mathrm{R}}\right)=\mathsf{\phi }\left(\mathrm{p}\right) \times \mathsf{\phi }\left(\mathrm{q}\right)=\left(\mathrm{p}-1\right) \times \left(\mathrm{q}-1\right)$. It selects an integer, ${\mathrm{e}}_{\mathrm{R}},$ that satisfies the condition ${\mathrm{e}}_{\mathrm{R}} < \mathrm{r}, \gcd \left({\mathrm{e}}_{\mathrm{R}}, \mathrm{r}\right)=1$. Next, the RSU can calculate the modular inverse element, ${\mathrm{d}}_{\mathrm{R}},$ such that ${\mathrm{e}}_{\mathrm{R}}{ \times \mathrm{d}}_{\mathrm{R} }\equiv 1\left(\mathrm{mod} \mathrm{r}\right)$. The j-th RSU $\left(\mathrm{j}\in \left[{1, \mathrm{N}}_{\mathrm{R}}\right]\right)$ possesses a public–private key pair, expressed as $\left\{{\mathrm{Pk}}_{\mathrm{R}}{, \mathrm{Sk}}_{\mathrm{R}}\right\}$. Here, ${\mathrm{Pk}}_{\mathrm{R}}=\left({\mathrm{m}}_{\mathrm{R}}{, \mathrm{e}}_{\mathrm{R}}\right)$ is the public key, whereas ${\mathrm{Sk}}_{\mathrm{R} }=\left({\mathrm{m}}_{\mathrm{R}}{, \mathrm{d}}_{\mathrm{R}}\right)$ is the private key. Lastly, the RSU sends the ${\mathrm{Pk}}_{\mathrm{R}}$ to the CA and securely stores the corresponding ${\mathrm{Sk}}_{\mathrm{R}}$.

(2) Vehicle Training Nodes Selection: In order to improve the efficiency and effectiveness of the training process, we propose an algorithm based on the concept of Euclidean distance. The implementation process is illustrated in Algorithm 1, which is implemented as a smart contract on the consortium chain. The algorithm aims to select vehicles with high data similarity to the task issuer, which forms a training group and assigns them FL tasks.

Algorithm 1: Vehicle Selection Contract

Similarity Calculation:

Input: $\mathrm{Task}=\left\{\mathrm{Re}, \mathrm{D}=\left({\mathrm{D}}_1^{\mathrm{q}},{ \mathrm{D}}_2^{\mathrm{q}},\cdots ,{ \mathrm{D}}_{\mathrm{n}}^{\mathrm{q}}\right)\right\}$, ${\mathrm{X}}_{\mathrm{i}}=\left({\mathrm{X}}_1, {\mathrm{X}}_2, \cdots ,{ \mathrm{X}}_{{\mathrm{N}}_{\mathrm{V}}}\right)$;

Output: ${\mathrm{V}}_{\mathrm{i}}=\left({\mathrm{V}}_1, {\mathrm{V}}_2,\cdots ,{\mathrm{V}}_{\mathrm{m}}\right)$;

Initial_List[ ] $=\left\{0\right\}, \mathrm{v}=\mathrm{s}=0,$

$for \mathrm{i}=1;\mathrm{i}<{\mathrm{N}}_{\mathrm{V}}+1;\mathrm{i}++ \mathrm{do}$

$for \mathrm{j}=1;\mathrm{j}<\mathrm{n}+1;\mathrm{j}++ \mathrm{do}$

$\mathrm{v}={\left({\mathrm{D}}_1^{\mathrm{q}}-{\mathrm{X}}_{\mathrm{i}1}\right)}^2$

$\mathrm{s}=\mathrm{s}+\mathrm{v}$

end for

Similarity(issuer, Vi) $=\sqrt{\mathrm{s}}$

Similarity(issuer, Vi) → Initial_List[ ]

end for

Rank(Initial_List[ ])

Select the first m vehicles from Initial_List[ ] to form ${\mathrm{V}}_{\mathrm{i}}=\left({\mathrm{V}}_1,{\mathrm{V}}_2,\cdots ,{\mathrm{V}}_{\mathrm{m}}\right)$

Credibility Verification:

Input: ${\mathrm{V}}_{\mathrm{i}}=\left({\mathrm{V}}_1,{\mathrm{V}}_2,\cdots ,{\mathrm{V}}_{\mathrm{m}}\right), {\mathrm{Rep}}_{\mathrm{st}},{\mathrm{Rep}}_{\mathrm{i}}$;

Output: TrainingGroup_List

$for$ each ${\mathrm{V}}_{\mathrm{i}}\in \left({\mathrm{V}}_1,{\mathrm{V}}_2,\cdots ,{\mathrm{V}}_{\mathrm{m}}\right)$ $\mathrm{do}$

$if$ ${\mathrm{Rep}}_{\mathrm{i}}>{\mathrm{Rep}}_{\mathrm{st}}$

$then \mathrm{TrainingGroup\_List}.\mathrm{add}\left({\mathrm{V}}_{\mathrm{i}}\right)$;

$else$ Remove this vehicle ${\mathrm{V}}_{\mathrm{i}}$

$end if$

$end for$

return TrainingGroup_List

End of Algorithm

Initially, the task issuer submits an FL task to the blockchain and stipulates that the total number of vehicles in the training group is represented by $\mathrm{m}$. Upon receiving this FL task, denoted as $\mathrm{Ta}=\left\{\mathrm{Re}, \mathrm{D}=\left({\mathrm{D}}_1^{\mathrm{q}}{, \mathrm{D}}_2^{\mathrm{q}}, \cdots {, \mathrm{D}}_{\mathrm{n}}^{\mathrm{q}}\right)\right\}$, the smart contract responsible for forming the training group is activated. Here, $\mathrm{Re}$ represents the specific requirements of the FL task $\mathrm{Ta}$, $\mathrm{D}=\left({\mathrm{D}}_1^{\mathrm{q}}{, \mathrm{D}}_2^{\mathrm{q}}, \cdots {, \mathrm{D}}_{\mathrm{n}}^{\mathrm{q}}\right)$ represents the data requirements for the vehicle training nodes, ${\mathrm{X}}_{\mathrm{i}}=\left({\mathrm{X}}_{\mathrm{i}1}{, \mathrm{X}}_{\mathrm{i}2}, \cdots {, \mathrm{X}}_{{\mathrm{iN}}_{\mathrm{V}}}\right)$ represents the local data summary of each vehicle, and $\mathrm{n}$ denotes the number of feature items in the similarity calculation. The data similarity between each vehicle and the task issuer is calculated using Formula $\left(1\right)$:

$$\mathrm{Similarity}\left({\mathrm{issuer}, \mathrm{V}}_{\mathrm{i}}\right)=\sqrt{{\left({\mathrm{D}}_1^{\mathrm{q}}-{\mathrm{X}}_{\mathrm{i}1}\right)}^2+{\left({\mathrm{D}}_2^{\mathrm{q}}-{\mathrm{X}}_{\mathrm{i}2}\right)}^2+\cdots {\left({\mathrm{D}}_{\mathrm{n}}^{\mathrm{q}}-{\mathrm{X}}_{\mathrm{in}}\right)}^2}$$

(1)

Once the calculation of the data similarity between all vehicles and the task issuer is completed, the smart contract arranges the similarity values in descending order to select the top m vehicles to form a training group. To further select trustworthy vehicles for task training, Algorithm 1 also performs credibility verification on these vehicles. The details of this verification process will be introduced in the fourth part of this section. Each vehicle ${\mathrm{V}}_{\mathrm{i}} \left( \mathrm{i}\in \left[{1, \mathrm{N}}_{\mathrm{m}}\right]\right)$ also utilizes the RSA-based method to generate a public–private key pair $\left\{{\mathrm{Pk}}_{\mathrm{V}}{, \mathrm{Sk}}_{\mathrm{V}}\right\}$. The public key is ${\mathrm{Pk}}_{\mathrm{V}}=\left({\mathrm{m}}_{\mathrm{V}}{, \mathrm{e}}_{\mathrm{V}}\right)$, and the private key is ${\mathrm{Sk}}_{\mathrm{V}}=\left({\mathrm{m}}_{\mathrm{V}}{, \mathrm{d}}_{\mathrm{V}}\right)$.

Subsequently,${\mathrm{V}}_{\mathrm{i}}$ acquires the timestamp ${\mathrm{RT}}_{\mathrm{i}}$ and utilizes it to sign its identity ${\mathrm{Cert}}_{{\mathrm{V}}_{\mathrm{i}}}$, generating ${\mathrm{Sig}}_{{\mathrm{RT}}_{\mathrm{i}}}\left({\mathrm{Cert}}_{{\mathrm{V}}_{\mathrm{i}}}\right)$. It sends $\left\{{\mathrm{Pk}}_{\mathrm{V}},{ \mathrm{Sig}}_{{\mathrm{RT}}_{\mathrm{i}}}\left({\mathrm{Cert}}_{{\mathrm{V}}_{\mathrm{i}}}\right)\right\}$ to the CA for identity registration. Upon receiving this registration request, the CA performs initial checks on the validity of the ${\mathrm{RT}}_{\mathrm{i}}$ to ensure that it is within an acceptable time range. The CA then examines the validity of the ${\mathrm{Cert}}_{{\mathrm{V}}_{\mathrm{i}}}$. Finally, the CA stores $\left\{{\mathrm{Pk}}_{\mathrm{V}}{, \mathrm{Sig}}_{{\mathrm{RT}}_{\mathrm{i}}}\left({\mathrm{Cert}}_{{\mathrm{V}}_{\mathrm{i}}}\right)\right\}$ of each vehicle in this FL task that has successfully registered. This process ensures that only authorized vehicle nodes are allowed to participate in the training task.

(3) Master Key and Secret Share Generation: The CA employs the AES key generation function to create a master key: $\mathrm{K}=\mathrm{KeyGen}\left({\mathrm{L}}_{\mathrm{AES}}\right)$, and ${\mathrm{L}}_{\mathrm{AES}}$ is the AES key length. It randomly chooses m mutually prime integers, ${\mathrm{a}}_{\mathrm{I}}=\left\{{\mathrm{a}}_1{, \mathrm{a}}_2, \cdots {, \mathrm{a}}_{\mathrm{m}}\right\}$, as the modulus and computes the Formula (2) with the assistance of $\mathrm{K}$:

$${\mathrm{b}}_{\mathrm{i}}=\mathrm{K}\left({\mathrm{mod} \mathrm{a}}_{\mathrm{i}}\right)$$

(2)

Each vehicle’s secret share is represented as ${\mathrm{S}}_{\mathrm{i}}=\left({\mathrm{b}}_{\mathrm{i}}{, \mathrm{a}}_{\mathrm{i}}\right)$ in the subsequent text.

(4) Encrypted Distribution of Master Key and Secret Shares: Using the ${\mathrm{Pk}}_{\mathrm{R}}=\left({\mathrm{m}}_{\mathrm{R}}{, \mathrm{e}}_{\mathrm{R}}\right)$, CA encrypts each ${\mathrm{S}}_{\mathrm{i}}$ resulting in the secret share ciphertext, ${\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}$, obtained using Formula $\left(3\right)$:

$${\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}={\left({\mathrm{S}}_{\mathrm{i}}\right)}^{{\mathrm{e}}_{\mathrm{R}}}\left({\mathrm{mod} \mathrm{m}}_{\mathrm{R}}\right)$$

(3)

Subsequently, the CA employs ${\mathrm{Pk}}_{\mathrm{V}}=\left({\mathrm{m}}_{\mathrm{V}},{ \mathrm{e}}_{\mathrm{V}}\right)$ to encrypt the $\mathrm{K}$, and acquires the master key ciphertext, ${\mathrm{C}}_{\mathrm{K}}$, using Formula $\left(4\right)$:

$${\mathrm{C}}_{\mathrm{K}}={\left(\mathrm{K}\right)}^{{\mathrm{e}}_{\mathrm{V}}}\left({\mathrm{mod} \mathrm{m}}_{\mathrm{V}}\right)$$

(4)

Finally, the CA distributes ${\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}$ and ${\mathrm{C}}_{\mathrm{K}}$ to the vehicles in this training group, while the RSU transmits the ${\mathrm{GM}}_0$ and $\mathrm{Re}$ to the vehicles within its coverage area.

4.2. Local Model Training

In the initial iteration, each vehicle receives ${\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}$ and ${\mathrm{C}}_{\mathrm{K}}$ from the CA and simultaneously accesses the ${\mathrm{GM}}_0$ and $\mathrm{Re}$ issued by the RSU to commence training. In the t-th iteration, each vehicle downloads the global model, ${\mathrm{GM}}_{\mathrm{t}-1}$, from the previous round for training.

(1) Find the Euclidean Distance: To address the issue of vehicles potentially uploading erroneous or low-quality parameters, we enhanced the FL by integrating Multi-Krum [36,37]. Before encrypting and uploading the training results, it enables us to find Euclidean distances between gradients, identifying gradients that deviate significantly from normal gradients as malicious. Distributing calculation tasks to each vehicle not only reduces the computational burden on the RSUs but also improves the filtering efficiency. From a security aspect, each vehicle receives a set of ciphertexts and lacks the private keys of others. This effectively prevents the explicit determination of the distances between a given vehicle and other vehicles. Algorithm 2 illustrated the procedure for filtering out updates and generating the list of legitimate vehicles, with the detailed steps described below:

Algorithm 2: Filtering Contract

Find Euclidean Distance:

Input: Enc_PkV$\left({\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}\right)$, Enc_PkV$\left(-{\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}\right)$, ${\mathrm{Pk}}_{\mathrm{V}}$

Output: ${\mathrm{Dis}}_{\mathrm{sum}\_\mathrm{i}}$

$\left(1\right) for \mathrm{j}=0{ \mathrm{to} \mathrm{N}}_{\mathrm{m}};\mathrm{j}\ne \mathrm{i} \mathrm{do}$

Enc_disi[j] = Enc_PkV$\left({\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}\right)\times$ Enc_PkV$\left(-{\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}\right)$ = Enc_PkV$\left({\mathrm{u}}_{\mathrm{i}}^{\mathrm{t}}-{\mathrm{u}}_{\mathrm{j}}^{\mathrm{t}}\right);$

$\left(2\right) {\mathrm{Pk}}_{\mathrm{V}}\to \mathrm{Blockchain}\to {\mathrm{Sk}}_{\mathrm{V}}$

$\left(3\right) for \mathrm{j}=0{ \mathrm{to} \mathrm{N}}_{\mathrm{m}}; \mathrm{j}\ne \mathrm{i} \mathrm{do}$

Disi[j] = Dec(Enc_disi[j]);

Euclidean_Dis[j] = ${\Vert {\mathrm{Dis}}_{\mathrm{i}}\left[\mathrm{j}\right]\Vert }^2$

$\left(4\right)$  Euclidean_Dissum_i = ${\displaystyle \sum }_{\mathrm{j}\in \left[0,\mathrm{m}\right],\mathrm{j}\ne \mathrm{i}}$ Euclidean_Disi[j]

$\left(5\right){ \mathrm{Sig}}_{{\mathrm{Sk}}_{\mathrm{V}}}$ [Euclidean_Dissum_i]&Enc_PkV$\left({\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}\right)\to \mathrm{RSU}$

Parameter Filtering:

Input: the set of the Euclidean_Dissum_i

Output: Selection_List

$\left(1\right) \mathrm{SortDis}=\mathrm{AScendSort}$(Euclidean_Dissum_i)

$\left(2\right)$ Selection_Dis = $\mathrm{SortDis}.\mathrm{subset}\left[0,\mathrm{m}-\mathrm{z}\right]$

$\left(3\right) for$ $\mathrm{i}=0{ \mathrm{to} \mathrm{N}}_{\mathrm{m}} \mathrm{do}$

if Euclidean_Dissum_i ∈ Selection_Dis

then Selection_List$.\mathrm{add}\left(\mathrm{i}\right);$

return Selection_List

In the t-th iteration, the local update of ${\mathrm{V}}_{\mathrm{i}}$ is denoted as ${\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}$. ${\mathrm{V}}_{\mathrm{i}}$ first encrypts ${\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}$ and $-{\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}$ using its own public key, ${\mathrm{Pk}}_{\mathrm{V}}$, resulting in Enc_Pk_V$\left({\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}\right)$ and Enc_Pk_V$\left(-{\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}\right)$; Next, it signs Enc_Pk_V$\left(-{\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}\right)$ using its own private key ${\mathrm{Sk}}_{\mathrm{V}}$, generating ${\mathrm{Sig}}_{{\mathrm{Sk}}_{\mathrm{V}}}$Enc_Pk_V$\left[\left(-{\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}\right)\right]$. The signature is shared to other vehicles in the training group for verification purposes. Upon receiving the broadcast messages from other vehicles, each vehicle node initially performs identity verification, then it uses Enc_Pk_V$\left({ \mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}\right)$ and Enc_Pk_V$\left(-{\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}\right)$ as inputs to execute the Find Euclidean distance defined in Algorithm 2. Then, this contract sends ${\mathrm{Pk}}_{\mathrm{V}}$ to ${\mathrm{V}}_{\mathrm{i}}$ to obtain the corresponding ${\mathrm{Sk}}_{\mathrm{V}}$. It decrypt and find the distance. Here, m denotes the number of vehicles, z represents the number of malicious vehicles. To calculate the quality score for each local model, we sum the Euclidean distances between each vehicle’s local model and its m-z-2 closest local models:

$$\mathrm{score}\left(\mathrm{i}\right)={}_{\begin{array}{c}\mathrm{i}\to \mathrm{j}\\ \mathrm{i}\ne \mathrm{j}\end{array}}{}^{\sum }\Vert \Delta {\mathrm{w}}_{\mathrm{i}}^{\mathrm{T}}-\Delta {\mathrm{w}}_{\mathrm{j}}^{\mathrm{T}}{\Vert }^2$$

where $\mathrm{i}\to \mathrm{j}$ signifies that the local model, $\Delta {\mathrm{w}}_{\mathrm{i}}^{\mathrm{T}},$ is among the m-z-2 closest local models to the ideal local model, $\Delta {\mathrm{w}}_{\mathrm{j}}^{\mathrm{T}}$. Finally, the m-z local models exhibiting the lowest quality scores are selected as the Legal_Dis for aggregation. This filtering contract calculates Euclidean_Dis_{sum_i}, which corresponds to the total sum of Euclidean distances between the vehicle and all other vehicles. Then, ${\mathrm{V}}_{\mathrm{i}}$ signs the Euclidean_Dis_{sum_i} using its own private key, and sends ${\mathrm{Sig}}_{{\mathrm{Sk}}_{\mathrm{V}}}$[Euclidean_Dis_{sum_i}], along with Enc_Pk_V$\left({\mathrm{LU}}_{\mathrm{i}}^{ \mathrm{t}}\right),$ to RSU.

(2) Legal Vehicle List Generation: The RSU use the output Euclidean_Dis_{sum_i} derived from Algorithm 2. It then verifies the identity of each vehicle and chooses m-z models that are in proximity to others while disregarding the remaining models. Lastly, the filtering contract appends the identities of vehicles with retained local models to the Selection_List set, thereby creating the final list of legal vehicles.

(3) Uploading Encrypted Training Results: the m-z vehicles identified in the legal list utilize ${\mathrm{Sk}}_{\mathrm{V}}=\left({\mathrm{m}}_{\mathrm{V}}{, \mathrm{d}}_{\mathrm{V}}\right)$ to recover the $\mathrm{K}$ through Formula (5) using ${\mathrm{C}}_{\mathrm{K}}$:

$$\mathrm{K}={\left({\mathrm{C}}_{\mathrm{k}}\right)}^{{ \mathrm{d}}_{\mathrm{V}}}\left({\mathrm{mod} \mathrm{m}}_{\mathrm{V}}\right)$$

(5)

Lastly, ${\mathrm{V}}_{\mathrm{i}}$ encrypts the training result using $\mathrm{K}$, resulting in ${\mathrm{C}}_{\mathrm{t}}^{ \mathrm{i}}{=\mathrm{Enc}}_{\mathrm{k}}\left({\mathrm{LU}}_{\mathrm{t}}^{ \mathrm{i}}\right)$. It then sends both the ciphertext of training result ${\mathrm{C}}_{\mathrm{t}}^{ \mathrm{i}}$ and the secret share ciphertext ${\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}$ to RSU.

4.3. Global Model Update and Blockchain Consensus

(1) Reconstruction of the Secret Share and Master Key: The RSU receives the ${\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}$ and ${\mathrm{C}}_{\mathrm{t}}^{ \mathrm{i}}$ transmitted by vehicles in the legal vehicle list. Using ${\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}$ and ${\mathrm{Sk}}_{\mathrm{R}}$, the RSU then restore the ${\mathrm{S}}_{\mathrm{i}}$ according to Formula (6):

$${\mathrm{S}}_{\mathrm{i}}= {\left({\mathrm{C}}_{{\mathrm{S}}_{\mathrm{i}}}\right)}^{{\mathrm{d}}_{\mathrm{R}}}\left({\mathrm{mod} \mathrm{m}}_{\mathrm{R}}\right)$$

(6)

If the number of secret shares satisfies the requirements of $(\mathrm{t}, \mathrm{n})$ threshold, the RSU applies the reconstruction algorithm to restore the current round’s $\mathrm{K}$ using more than t secret shares. If the number of secret shares is inadequate (indicating more than $\mathrm{t}$ vehicles have exited), the current round of reconstruction fails, and the system proceeds to the next round of global iteration. The secret reconstruction algorithm follows these steps:

First, t secret shares are selected, denoted as ${\mathrm{S}}_{\mathrm{t} }=\left\{{\mathrm{S}}_{\mathrm{i}+1}{, \mathrm{S}}_{\mathrm{i}+2}, \cdots {, \mathrm{S}}_{\mathrm{i}+\mathrm{t}}\right\}$. Then, the modulus product ${\mathrm{N}}_1$ is calculated using modulus ${\mathrm{a}}_{\mathrm{i}+1}$ according to Formula (7):

$${\mathrm{N}}_1{=\mathrm{a}}_{\mathrm{i}+1}{ \times \mathrm{a}}_{\mathrm{i}+2}\times \cdots {\times \mathrm{a}}_{\mathrm{i}+\mathrm{t}}$$

(7)

The modulus equation set is derived using Formula (2) and denoted as Formula (8):

$$\left\{\begin{array}{c}\mathrm{K}\equiv {\mathrm{b}}_{\mathrm{i}+1}\left({\mathrm{mod} \mathrm{a}}_{\mathrm{i}+1}\right)\\ \mathrm{K}\equiv {\mathrm{b}}_{\mathrm{i}+2}\left({\mathrm{mod} \mathrm{a}}_{\mathrm{i}+2}\right)\\ ⋮\\ \mathrm{K}\equiv {\mathrm{b}}_{\mathrm{i}+\mathrm{t}}\left({\mathrm{mod} \mathrm{a}}_{\mathrm{i}+\mathrm{t}}\right)\end{array}\right.$$

(8)

The modulus equation set (8) and the modulus product ${\mathrm{N}}_1$ are utilized to calculate the master key using Formula (9):

$$\mathrm{K}={\displaystyle \sum }_{\mathrm{j}=1}^{ \mathrm{i}+\mathrm{t}}{\mathrm{b}}_{\mathrm{j}}\times \frac{{\mathrm{N}}_1}{{\mathrm{a}}_{\mathrm{j}}}\times {\left[{\left(\frac{{\mathrm{N}}_1}{{\mathrm{a}}_{\mathrm{j}}} \right)}^{-1}\right]}_{{\mathrm{a}}_{\mathrm{j}}}\left({\mathrm{mod} \mathrm{N}}_1\right)$$

(9)

(2) Decryption and Aggregation of Training Results: The RSU decrypts the ${\mathrm{C}}_{\mathrm{t}}^{ \mathrm{i}}$ using the $\mathrm{K}$ and obtains the local update ${\mathrm{LU}}_{\mathrm{t}}^{ \mathrm{i}}$ for each vehicle, denoted as ${\mathrm{LU}}_{\mathrm{t}}^{ \mathrm{i}}{=\mathrm{Dec}}_{\mathrm{K}}\left({\mathrm{C}}_{\mathrm{t}}^{ \mathrm{i}}\right)$.

Subsequently, utilizing all the received local training models and calculating Formula (10), the RSU can aggregate the model parameters denoted as ${\mathrm{M}}_{{\mathrm{R}}_{\mathrm{j}}}\left({\mathrm{R}}_{\mathrm{j}}\in {\mathrm{N}}_{\mathrm{R}}\right)$:

$${\mathrm{M}}_{{\mathrm{R}}_{\mathrm{j}}}={\displaystyle \sum }_{\mathrm{i}=1}^{\mathrm{M}}\frac{1}{\mathrm{M}}{ \mathrm{LU}}_{\mathrm{t}}^{ \mathrm{i}}$$

(10)

Finally, the RSU distributes ${\mathrm{M}}_{{\mathrm{R}}_{\mathrm{j}}}$ to all of the vehicle nodes in the current training group, thereby marking the completion of the model training.

(3) Evaluating RSU Contributions: In this section, to incentivize active participation from multiple RSUs in collaborative model training to acquire an accurate training model, we evaluate the contribution of each RSU using the accuracy deviation value. RSUs that make greater contributions are subsequently elected as miner nodes through a consensus mechanism, enabling them to record the aggregated results on the consortium chain.

Each RSU first aggregates its own model ${\mathrm{M}}_{{\mathrm{R}}_{\mathrm{j}}}\left({\mathrm{R}}_{\mathrm{j}}\in {\mathrm{N}}_{\mathrm{R}}\right)$ and, subsequently, transmits its model ${\mathrm{M}}_{{\mathrm{R}}_{\mathrm{m}}}\left({\mathrm{R}}_{\mathrm{m}}\in {\mathrm{N}}_{\mathrm{R}}\&\mathrm{m}\ne \mathrm{j}\right)$ to other RSU nodes while receiving the model set $\left\{{\mathrm{M}}_{{\mathrm{R}}_{\mathrm{m}}}\right\}$ broadcasted by them. Each RSU then trains and validates ${\mathrm{M}}_{{\mathrm{R}}_{\mathrm{j}}}$ using $\left\{{\mathrm{M}}_{{\mathrm{R}}_{\mathrm{m}}}\right\}$, resulting in the accuracy set $\left\{{\mathrm{Acc}}_{{\mathrm{R}}_{\mathrm{m}}}\right\}$. The accuracy deviation value is computed using Formula (11) to measure the comparative quality advantage of this RSU in relation to other RSU nodes:

$${\mathrm{acc}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}=1+\frac{{{\displaystyle \sum }}_{{\mathrm{R}}_{\mathrm{m}}\in {\mathrm{N}}_{\mathrm{R}}/{\mathrm{R}}_{\mathrm{j}}}\left({\mathrm{Acc}}_{{\mathrm{R}}_{\mathrm{j}}}-{\mathrm{Acc}}_{{\mathrm{R}}_{\mathrm{m}}}\right)}{\left|{\mathrm{N}}_{\mathrm{R}}\right|-1}$$

(11)

By considering its historical contributions, the RSU updates its contribution score for the current round using Formula (12) based on ${\mathrm{acc}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}$:

$${\mathrm{Con}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}=\frac{1+{\mathrm{acc}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}}{1+{\mathrm{e}}^{-\mathrm{acc}\left({\mathrm{Con}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}-1}\times {\mathrm{acc}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}\right)}}$$

(12)

(4) Blockchain Consensus Mechanism: Enhancing consensus efficiency facilitates the completion of FL tasks at a faster rate. By considering RSU’s historical contributions, we incorporated a consensus based on the delegated Byzantine fault-tolerant algorithm (dBFT) [38] in this paper. The dBFT is a consensus developed based on the PBFT. In comparison to other consensuses, like PoW and DPoS, it provides the flexibility to replace miner nodes without the need for a fixed miner group and exhibits superior performance. Hence, we employ this consensus to construct a flexible consortium chain that ensures efficient and reliable federated learning. Unlike PoS, DPoS, and PBFT, which sequentially select leader nodes, the dBFT provides higher fairness by offering each node an equal opportunity to be selected. The steps of this mechanism are illustrated in Figure 3.

After the completion of the contribution calculation, the RSU with the highest score will be declared as the miner node. The miner node then generates a block encompassing global models and the contribution score for the current round. The block format adheres to the following structure:

$$\mathrm{Block}=\left\{\mathrm{Head},{\mathrm{M}}_{{\mathrm{R}}_{\mathrm{j}}},\mathrm{trans},{\mathrm{Con}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}\right\}.$$

Here, Head represents the block header, and trans denotes the transaction information.

Following dissemination by the miner node, this new Block is then distributed to the remaining ordinary nodes for verification. The ordinary nodes validate the correctness of the Head and tra, as well as comparing their ${\mathrm{Con}}_{{\mathrm{R}}_{\mathrm{j}}}^{\mathrm{t}}$ with that of the miner node. In the case that the miner node’s contribution score exceeds that of the ordinary node, the ordinary node must acknowledge the miner node’s contribution in the current round. Otherwise, the CA will select a new miner node from the pool of ordinary nodes. Once the verification is successful, the ordinary node sends a confirmation message to the miner node. When the miner node receives confirmation messages from at least two-thirds of the ordinary nodes, it confirms the legitimacy of the Block. The miner node then signs, broadcasts, and stores this new Block in the blockchain to ensure its immutability.

4.4. Vehicle Credibility-Based Incentive Mechanism

This paper presents an incentive mechanism based on vehicle credibility, aiming to encourage active participation and high-quality data contribution from vehicles in the training group. By integrating the Multi-Krum algorithm and reputation-based incentive protocols [39], the filtering results are leveraged to evaluate the credibility of vehicles. The credibility score can serve as an important indicator for evaluating vehicle reliability and guiding an incentive mechanism that ensures the fairness of collaborative training. Finally, the credibility score is recorded on the blockchain, enabling data tamper-proofing and nonrepudiation. The specific steps are illustrated in Figure 4.

(1) Credibility Initialization: Each vehicle initializes its own credibility,${ \mathrm{Rep}}_{\mathrm{i}}$, which is stored in the CA along with its public key and identity certificate. ${\mathrm{Rep}}_{\mathrm{i}}$ is an integer that belongs to the finite set $\left[{0, \mathrm{R}}_{\max }\right]$, where ${\mathrm{R}}_{\mathrm{a}}$ and ${\mathrm{R}}_{\mathrm{b}}$ represent the trustworthy threshold and malicious threshold within this credibility set. If a vehicle node’s credibility satisfies ${\mathrm{Rep}}_{\mathrm{i}} \ge { \mathrm{R}}_{\mathrm{a}}$, it is considered trustworthy and its credibility is initialized to ${\mathrm{R}}_{\mathrm{a}}$. If ${\mathrm{Rep}}_{\mathrm{i}} \le { \mathrm{R}}_{\mathrm{b}}$, the vehicle is deemed untrustworthy, and its identity certificate is revoked by the CA.

(2) Credibility Verification: The task issuer needs to assess the benefits of the global model and allocate task rewards for the training task. This approach serves to incentivize vehicles in the training group to upload high-quality parameters while also qualifying the contribution of each vehicle to the global model. Additionally, the task issuer establishes the credibility threshold, ${\mathrm{Rep}}_{\mathrm{st}}$, according to training task requirements.

Vehicles will be deemed qualified to participate in an FL task only if their credibility meets the condition ${\mathrm{Rep}}_{\mathrm{i}}\ge {\mathrm{Rep}}_{\mathrm{st}}$. The sensitivity of the global model being trained impacts the selection of the credible threshold: a higher threshold is required for highly sensitive global models, while a smaller threshold can be set for models with low sensitivity and a need for more data samples. During the vehicle training node selection phase, Algorithm 1 verifies that the credibility of the vehicles meets or exceeds the credibility threshold to ensure that credible vehicles participate in the training task.

(3) Credibility Update: After successfully passing the verification and joining the group, vehicles begin local training and transmit the latest models to RSUs. During each iteration, vehicles uploading illegal parameters are recorded. Upon receiving the Selection_List from Algorithm 2, RSUs update the credibility of each vehicle using Formula (11):

$$\left\{\begin{array}{c}{\mathrm{Rep}}_{\mathrm{i}}={\mathrm{Rep}}_{\mathrm{i}}+1, i\in \mathrm{Selection\_List}\\ {\mathrm{Rep}}_{\mathrm{i}}={\mathrm{Rep}}_{\mathrm{i}}-1, i\notin \mathrm{Selection\_List}\end{array}\right.$$

(13)

Once the FL task is completed, the miner node will upload the credibility of the vehicles to the blockchain. All task issuers can select well-performing vehicles to participate in FL tasks by querying their credibility. If a vehicle’s credibility falls below the set threshold, the contract will remove the vehicle from the training group.

(4) Contribution-Based Reward Mechanism: This mechanism commences by initializing the contribution score of each vehicle to 0. The contribution of the vehicle is represented by ${\mathrm{Contri}}_{\mathrm{i}}$, which is calculated using Formula (12):

$$\left\{\begin{array}{c}{\mathrm{Contri}}_{\mathrm{i}}={\mathrm{Contri}}_{\mathrm{i}}+1,{\mathrm{Rep}}_{\mathrm{i}}>{\mathrm{Rep}}_{\mathrm{st}}\\ {\mathrm{Contri}}_{\mathrm{i}}={\mathrm{Contri}}_{\mathrm{i}},{\mathrm{Rep}}_{\mathrm{i}}\le {\mathrm{Rep}}_{\mathrm{st}}\end{array}\right.$$

(14)

The reward calculation based on ${\mathrm{Contri}}_{\mathrm{i}}$ is performed using Formula (13):

$$\left\{\begin{array}{c}{\mathrm{Reward}}_{\mathrm{i}}{=0, \mathrm{Contri}}_{\mathrm{i}}=0\\ {\mathrm{Reward}}_{\mathrm{i}}=\left(\raisebox{1ex}{${\mathrm{Contri}}_{\mathrm{i}}$}\!\left/ \!\raisebox{-1ex}{${{\displaystyle \sum }}_{{\mathrm{Contri}}_{\mathrm{i}}\ge \frac{2\mathrm{t}}{3}}$}\right.{\mathrm{Contri}}_{\mathrm{i}}+1\right){\times \mathrm{Reward}}_{\mathrm{i}}, {\mathrm{Contri}}_{\mathrm{i}}>0\end{array}\right.$$

(15)

5. Security Analysis

5.1. Ensuring Accuracy of the Global Model

(1) Implementation of the Multi-Krum Algorithm: One of our main strategies involves deploying the Multi-Krum algorithm, which is tightly integrated with the consortium chain via smart contracts to discern the disparities among gradients. This method enables us to detect parameters deviating from normal gradients, identifying them as malicious and excluding them. The filtering results serve as a trustworthiness metric for evaluating the behavior of vehicles involved in the collaborative training process. This enhancement of trust proves indispensable in the subsequent training processes, facilitating the selection of exceptionally reliable vehicles for participation.

(2) Node Selection Algorithm Based on Euclidean Distance: Leveraging the principles of Euclidean distance, we designed a vehicle selection algorithm to optimize training efficiency. This selection algorithm proficiently selects a few highly matching vehicles that exhibit significant compatibility. Subsequently, this process further ensures the efficient acquisition of an accurate global model within our system.

(3) Contribution Assessment and Assignment of Miner Nodes: We assess the contribution scores of all RSUs based on the accuracy deviation value. The RSU nodes that demonstrate substantial scores are designated as miner nodes, responsible for writing high-quality models to the blockchain. This methodology comprehensively evaluates the contribution of the RSUs, ensuring the correctness and high quality of the final aggregation results.

5.2. Protecting the Privacy of Filtering Results

(1) Secret Sharing of Local Model: In order to protect the privacy of the filtering results, we implemented the secret-sharing algorithm in our scheme. After training the model using local data and filtering malicious updates, the parameter updates are encrypted rather than being transmitted in plaintext. This ensures that external adversaries cannot infer the intermediate parameter and local data from the ciphertext updates.

(2) Enhanced Robustness via Threshold Secret-Sharing Scheme: Significantly, the use of the threshold secret-sharing scheme ensures robustness even in scenarios involving collusion attacks or node disconnections. The RSU nodes can reconstruct the original secret, providing robustness to the IoV system in unstable communication environments.

Detailed results and information can be found in

Table 2. Security comparisons of data-sharing schemes.

Index/Scheme Name	[40]	[41]	[42]	Ours
Decentralized Management	—	√	—	√
System Security	—	√	—	√
Privacy of Data and Models	—	√	√	√
Robustness of Global Model	—	√	√	√
Nodes Exist Resilient	—	—	—	√

.

6. Implementation and Analysis

6.1. Experimental Environment Configuration

The experimental hardware configuration includes an Intel Core i7-8700K processor (intel, Santa Clara, CA, USA), GTX 1080T GPU, and 16.0 GB of RAM, running in the Ubuntu 20.04 LTS environment. We utilized FISCO BCOS as the framework, an open-source consortium blockchain platform. Through its provided interface, transactions and smart contracts could be examined. The underlying blockchain and consensus process was implemented using Python (v3.6.3), with smart contracts written in C++. The vehicular federated learning environment was constructed using Python (v3.6.3) and TensorFlow (v2.4.2) for local training and global aggregation. Data collection and blockchain updates were simulated using the OMNET (v5.5.1), integrated with the Simulation of Urban Mobility (SUMO-v1.3.0). To simulate the communication among system nodes, we adopted the Krauss model [43]. During simulation, nodes were observed to move at speeds from 20 to 100 km/h on bidirectional roads within a simulated area of $2.5 \mathrm{km}\times 2.5 \mathrm{km}$.

(1) Experimental Model: We adopted the VGG16 image classification model as the global model for federated learning. The VGG16 model consists of eight layers in total, with the first 13 layers being convolutional layers and the last 3 layers being fully connected layers. In the vehicular federated learning environment, the parameters of the VGG16 model were set as follows: learning rate of $1\times {10}^{-3}$ dropout rate of 0.2, and each vehicle performed local training with a batch size of 64, while the RSU performed verification with a batch size of 32.

(2) Datasets: The MNIST dataset [44] consists of 60,000 training samples and $10,000$ test samples, each of which is a $28\times 28$ grayscale image. This dataset contains 10 classes, representing handwritten digits from 0 to 9, paired with their corresponding labels. The CIFAR-10 dataset [45] is a collection of color images, which comprises $50,000$ training samples and $10,000$ test samples. Each sample is a $32\times 32$ RGB image, and this dataset encompasses 10 types of universal objects, such as “aircraft”, “dog”, and “car”. These two datasets can represent the medium-complexity data collected by in-vehicle local devices, which simulate the image information obtained in real time during driving. They serve as benchmark test data for various FL algorithms designed for mobile edge scenarios.

(3) Node Configuration: As shown in

Table 3. Nodes’ parameter settings.

Parameter Name	Parameter Value
Number of Task Issuer	1
Total Number of System Nodes	40
Total Number of Vehicles	32
Total Number of RSUs	8

, we used a configuration of 40 system nodes to simulate data sharing in the IoV. This system scale more precisely replicates the intricacies of the IoV, facilitating the assessment of performance and effectiveness in data-sharing schemes during large-scale deployments. Here, 20% represents the RSUs, while the remaining 80% represents the vehicle nodes. This distribution more precisely mimics the real-world prevalence of RSUs and vehicle nodes, which is a crucial factor in assessing the effects of data sharing and model aggregation among different node types. Moreover, the increased number of vehicles guarantees more frequent local updates, thereby enhancing the reliability and accuracy of the aggregation algorithm. To ensure fairness, equivalent values are configured for the nodes’ parameters in these schemes.

(4) Comparative Schemes:

FL [40]: This centralized federated learning approach lacks validation and protection of intermediate parameter updates. It relies on a central server to distribute and aggregate the global model. The accuracy of the global model in this scheme serves as the baseline.

BPFL [41]: This scheme replaces the central aggregator with a consortium chain in the traditional IoV system and applies homomorphic encryption (HE) to protect gradients. Its global training effect is comparable to that of centralized FL. This scheme enhances the Multi-Krum algorithm to implement gradient detection and filtering, which aligns with our approach. We chose the BPFL as the baseline for comparing with the secret sharing proposed in this paper, allowing us to analyze the computational overhead and global accuracy associated with the encryption and decryption processes.

Madi’s FL [42]: This scheme extends the concept of centralized FL and incorporates homomorphic encryption (HE) and verifiable computing (VC) technology, ensuring both privacy protection and verifiability. The experiments with the Fashion MNIST demonstrate the effective accuracy guarantee of the global model.

6.2. Experimental Results

(1) Model Accuracy: We evaluated the impact of our scheme on the model’s accuracy. Subsequently, the average accuracy for each scheme was calculated, and the experimental results are illustrated in Figure 5.

On the MNIST, these four schemes were trained for 50 rounds, with the BPFL achieving the highest accuracy of 95.56%. Despite our solution not achieving the utmost accuracy, it proved comparable to the BPFL. It is worth noting that our solution displayed a consistently stable accuracy growth curve, resulting in an optimal average accuracy. For the CIFAR-10 dataset, all schemes were trained for 00 training rounds, converging around the 50th epoch. Both our solution and the BPFL scheme realized the highest global model accuracy, with a mere 2.32% disparity.

With an increase in the number of training epochs, the accuracy of the global model steadily improves across all four schemes. Notably, FL and Madi’s FL schemes exhibit a consistent upward trend in global model accuracy, whereas the accuracy of the global model in the two blockchain-based federated learning schemes fluctuates during the training process. Moreover, during the initial stages of model training, the blockchain-based schemes achieve higher accuracy for the global model. This can be attributed to the verification of global model accuracy in FL and Madi’s FL schemes being conducted by a central aggregator, which utilizes a more concentrated dataset distribution for accuracy evaluation, resulting in a stable upward trend. Both the BPFL scheme and our scheme select intermediate gradients with higher accuracy for aggregation through validation nodes and models, resulting in higher accuracy for the global model in the early stages of training. The validation process for the global model in the BPFL scheme and our scheme involves utilizing local datasets from committee members or validation nodes. This leads to variations in the dataset used for each validation process, resulting in fluctuations in the accuracy of the global model observed in the experimental results.

In conclusion, the BPFL scheme achieves the highest accuracy by conducting a hash function verification and setting parameter retention ratios after completing the training process. Our proposed scheme achieves comparable accuracy to the BPFL but with smoother growth. Before training, we employ a vehicle node selection process based on similarity, which results in optimal average accuracy. As a result, our proposed scheme does not compromise the accuracy of the global model and meets the fundamental requirements of the framework design.

(2) Evaluation of Average Training Time: To evaluate the model training performance of our proposed scheme, we conducted experiments to measure the time required for each round, using the MNIST dataset for 50 rounds of training and the CIFAR-10 dataset for 100 rounds. Subsequently, the average time spent in each training round was calculated, with the duration taken for a single entity to complete its computational task recorded to measure the running time. Both the RSU and vehicles executed computational work in parallel. The experimental results are illustrated in Figure 6.

Figure 6 reveals the minimal differences among the four schemes when applied to the MNIST dataset. Specifically, the average time consumed by training in our scheme was 1.3 s higher than the original FL, accounting for 5.18%. Moreover, it was 1.1 s lower than the BPFL, representing a decrease of 4%, and 2.3 s lower than the Madi’s FL, accounting for 8.01%. For the CIFAR-10 dataset, our proposed scheme’s training time increased by 3.6 s compared to the original FL, accounting for 17.40%. However, it decreased by 6.9 s compared to the BPFL, accounting for 22.12%. And it decreased by 8.6 s compared to the Madi’s FL, accounting for 26.14%. The time consumption gap between our proposed scheme and the original FL remained at 20%. Although the overall time consumption was higher than that of the original FL, the utilization of the secret sharing and the malicious model filtering, as presented in this paper, may have an impact on efficiency. Moreover, the training time in our scheme was significantly lower than that of both the BPFL and Madi’s FL, which employed homomorphic encryption, with the difference reaching up to 26%.

Our research adopted secret sharing over homomorphic encryption, providing a more efficient alternative that reduces computing overhead while ensuring the privacy of the global model. Therefore, our scheme is suited for the IoV scenarios characterized by limited computing power and constrained network communication.

(3) Evaluating Blockchain Consensus: to evaluate the performance of our consensus mechanism, we initially compared the dBFT with several mainstream mechanisms and further validated the advantages of our proposed mechanism, as shown in

Table 4. Performance comparison of the consensuses.

Indicator	PoW	PoS	DPoS	PBFT	dBFT
Byzantine-fault Tolerance	√	√	√	√	√
Higher Fairness	√	√	—	√	√
Eventual Consistency	—	—	—	—	√
Low Computing Cost	—	√	√	√	√
Low Transaction Latency	—	—	—	√	√

and Figure 7.

In terms of fairness, the dBFT randomly selects the leader nodes, which is more equitable than the PoS, DPoS, and traditional PBFT, which select leader nodes in a sequential manner. This allows every node to have an equal chance of being selected. Fairness plays a crucial role for the participating nodes in the training process discussed in this paper. Here, each RSU can be chosen as a miner node with accounting rights, ensuring their computing resources are put to meaningful use. In terms of computational consumption, unlike POW, dBFT allows nodes on the blockchain to obtain accounting rights without requiring a significant number of computational resources. This results in higher block generation efficiency by selecting miner nodes to achieve consensus. Once consensus is reached, the Block becomes irreversible and there is no possibility of forks. Compared to the PBFT, the dBFT does not require verification from all nodes on the blockchain, leading to a shorter communication time.

Considering that the Byzantine-fault tolerance rate of the dBFT is one-third, the miner nodes are categorized as positive miners and negative miners. We define the number of negative miners as $N_{neg}$; only when $N_{neg}$ satisfies the condition $N_{neg}<\frac{\left(N_{Miner}-1 \right)}{3}$ can a new Block be successfully verified and recorded on the blockchain, where $N_{Miner}$ represents the number of miner nodes in total. Then, we define the following Formula (16):

$$Neg={\displaystyle \sum }_{N_{neg}}^{q=0}\left(\begin{array}{c}{N}_{Miner}\\ q\end{array}\right){\theta }^q{\left(1-\theta \right)}^{N_{Miner}-q}$$

(16)

Here, the parameter $\theta$ represents the probability of becoming a negative miner, with $\theta \in \left[0.1, 0.3\right]$ representing the security probability of the miner nodes pool. In this experiment, we set the values of $\theta$ to 0.1, 0.2, and 0.3, respectively, as shown in Figure 7.

The security probability of the dBFT process decreases as $\theta$ increases. Additionally, as the size of the miner node pool increases, the security of the system also increases. This is because the number of positive miners participating in block validation increases with the size of the miner node pool. The larger the size of the miner node pool, the more secure the consensus process in this paper becomes. When a sufficient number of miner nodes participate in the dBFT, this ensures reliable validation for generating new blocks.

(4) Validation of the Vehicle Selection Algorithm: To validate the efficacy of the vehicle selection algorithm, we conducted experiments by varying the number of selected vehicle training nodes. We then applied the algorithm to both the MNIST and CIFAR-10 datasets for testing purposes, with a comparison of the model accuracy presented in Figure 8.

We carried out 50 rounds of training on the MNIST dataset, as depicted in Figure 8a. It is evident that the vehicle selection algorithm was utilized, the global model eventually achieved a stable accuracy. However, the necessary training rounds to achieve this stable accuracy varied. The algorithm-based selection of vehicles, using the concept of Euclidean distance, demonstrated high accuracy from the beginning, with the model quickly converging within approximately 20 rounds of training. Conversely, randomly selected vehicles demonstrated extremely low initial accuracy, and it took longer to reach maximum accuracy, typically requiring about 40 rounds.

Then, we performed 100 rounds of training for the CIFAR-10 dataset, as depicted in Figure 8b. By employing the algorithm-based selection of vehicles, stable convergence was achieved within 35 rounds. In contrast, utilizing randomly selected nodes did not lead to stable convergence even after approximately 65 rounds. Additionally, it can also be seen from Figure 8b that a smaller number of training nodes selected by the algorithm results in faster convergence of the accuracy rate. This outcome can be attributed to the enhanced correlation between each vehicle and the task issuer, resulting in quicker convergence of the accuracy rate. Hence, the results of the two comparative experiments demonstrate that this selection algorithm significantly enhances the speed and effectiveness of training.

(5) Evaluating Resistance to Poisoning Attacks: To evaluate the robustness of our scheme against poisoning attacks, we conducted experiments using the label inversion attack in [46] to generate poisoning samples. The labels of the training samples were altered while maintaining their original features, with poison sample ratios set at 10%, 20%, and 30% respectively. These manipulated samples were then assigned to designated attackers, and the outcomes were compared against the FL [40] without any poison samples. We then conducted a comparative analysis between our approach and three advanced algorithms specifically designed to mitigate Byzantine attacks.

The experimental results are presented in Figure 9 and Figure 10. For the MNIST dataset, the source label “1” was modified to the target label “8”, the source label “2” was modified to “4”. For the CIFAR-10 dataset, the source label “dog” was modified to the target label “horse”. To minimize the impact of irrelevant labels, binary classifiers were exclusively trained using samples that only contained the source and target labels. Additionally, a random selection of 500 test samples with the source label was conducted to determine the success rate of the attack. The success rate is defined as the percentage of samples for which the source label was predicted as the target label. Subsequently, we partitioned the experimental dataset randomly into local datasets for each vehicle.

As shown in Figure 9, the poisoning sample ratio was 20%, and the error rate of our approach on both datasets approached 0.1, gradually converging to the level of the FL with no poisoning samples. However, as the poisoning sample ratio increased to 30%, our approach stabilized below 0.16 during subsequent iterations. These findings suggest that our approach can effectively mitigate poisoning attacks with a maximum ratio of 30%.

In order to further validate the performance of our proposed solution, we conducted a comparative analysis by assuming an optimal scenario and comparing it against three other advanced algorithms designed to mitigate Byzantine attacks.

Optimal Scenario: In real-world scenarios where it is impractical to predetermine malicious vehicles, we assume that the RSU has prior knowledge of these malicious nodes. This enables the RSU to autonomously filter out updates uploaded by malicious vehicles, ensuring uninterrupted model training and ultimately resulting in an optimal algorithm outcome. The optimal scenario is employed to assess the accuracy rate of our solution in mitigating poisoning attacks.

Krum [36]: This algorithm is utilized in distributed machine learning to evaluate the similarity of gradient vectors based on the Euclidean distance. This approach effectively eliminates vectors that deviate significantly, thereby eliminating harmful updates. The calculation steps are as follows:

• Calculate Euclidean distance: calculate the Euclidean distance ${\mathrm{d}}_{\mathrm{ij}}$ between each user-uploaded gradient ${\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}$ and the gradient ${\mathrm{LU}}_{\mathrm{j}}^{\mathrm{t}}$ of the other user, ${\mathrm{d}}_{\mathrm{ij}}={\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}-{\mathrm{LU}}_{\mathrm{j}}^{\mathrm{t}}$.
• Select the minimum distance: Identify the set of vectors closest to the vectors of the other n−2f−2 users for each user i, where f represents the number of Byzantine nodes. Denote this set of minimum distances as ${\mathrm{Dis}}_{\mathrm{i}},{ \mathrm{Dis}}_{\mathrm{i}}=\left\{{\mathrm{d}}_{\mathrm{i}1},{\mathrm{d}}_{\mathrm{i}2},\cdots ,{\mathrm{d}}_{\mathrm{i}\left(\mathrm{n}-2\mathrm{f}-2\right)}\right\}$.
• Calculate the score: evaluate the quality score for each gradient vector by summing the distances in its corresponding set of minimum distances, ${\mathrm{Dis}}_{\mathrm{i}}, \mathrm{s}\left(\mathrm{i}\right)={{\displaystyle \sum }}_{\mathrm{j}\in {\mathrm{D}}_{\mathrm{i}}}{\mathrm{d}}_{\mathrm{ij}}$
• Choose the best gradient: select the gradient vector with the lowest quality score as the legitimate update for aggregation, ${\mathrm{LU}}_{\mathrm{best}}^{\mathrm{t}}={\mathrm{argmin}}_{\mathrm{i}}\mathrm{s}\left(\mathrm{i}\right)$.

Multi-Krum [37]: The Multi-Krum algorithm executes the Krum algorithm multiple times, with the calculation steps as follows:

• For n users, where f is the number of Byzantine nodes (satisfying n−2f−2).
• For each user i, perform the Krum to compute the score $\mathrm{s}\left(\mathrm{i}\right)$ for its gradient vector.
• Choose the gradient ${\mathrm{LU}}_{\mathrm{best}}^{\mathrm{t}}$ with the lowest score as legitimate for aggregation.

Median: The dimensional median algorithm is employed for calculating the global gradient by computing the median along each dimension:

$${\mathsf{\Delta }\mathrm{GM}}_{\mathrm{j}}=\mathrm{median}\left\{{\left({\mathrm{LU}}_{\mathrm{i}}^{\mathrm{t}}\right)}_{\mathrm{j}},\cdots ,{\left({\mathrm{LU}}_{\mathrm{k}}^{\mathrm{t}}\right)}_{\mathrm{j}}\right\}$$

Here, ΔGM_j represents the j-th dimension of the global model ΔGM, indicating the median value of the local updates contributed by all nodes in the j-th dimension; ${\left({\mathrm{LU}}_{\mathrm{k}}^{\mathrm{t}}\right)}_{\mathrm{j}}$ represents the j-th dimension of the local update ${\mathrm{LU}}_{\mathrm{k}}^{\mathrm{t}}$; and the function median{$·$} is utilized to calculate the median value within a set or sequence of numbers.

Additionally, we conducted a comparative analysis of our approach with three other advanced algorithms designed to mitigate Byzantine attacks, using the optimal scenario as the baseline. In Figure 10a, we examined a scenario without any Byzantine nodes, ensuring that each vehicle consistently shared accurate updates with the RSU throughout each iteration. It is evident that both our approach and Multi-Krum showcased promising aggregation performance, attaining an accuracy close to 96% and gradually converging toward near-optimal levels. In contrast, the Krum and Median exhibited poor performance, deviating significantly from the optimal level. The experimental results under inversion attack are presented in Figure 10b, revealing that our approach and the Multi-Krum showed robust aggregation performance, maintaining an accuracy of over 91% and approaching the optimal accuracy, while the Krum and Median performed poorly, achieving an accuracy of approximately 84%.

In summary, our solution exhibits exceptional resilience when faced with poisoning attacks at a rate of 30%. Our approach maintains a high level of accuracy when compared to the optimal algorithm and three other advanced Byzantine attack mitigation techniques. Consequently, our solution successfully eliminates harmful parameter updates while meeting the fundamental requirements of the framework design.

(6) Analysis of Computational Complexity: We compared our approach with the three advanced algorithms to evaluate its computational complexity in combating poisoning attacks.

Table 5. Computational complexity.

Methods	$\mathbf{Params}\left({10}^6\right)$	$\mathbf{FLOPs}\left({10}^6\right)$	Infer (ms)
Krum	0.28	132.73	5.08
Multi-Krum	0.47	237.58	15.13
Median	9.34	94.54	3.21
Ours	0.39	82.27	8.91

presents the parameters (Params), floating-point operations (FLOPs), and inference time for each algorithm.

Compared to the Multi-Krum algorithm, our algorithm exhibited lower computational complexity and faster inference speed. This is attributed to the introduction of the vehicle similarity calculation at the initial stage, allowing for the selection of vehicle nodes highly compatible with the data provided by the task issuer through Euclidean distance filtering. Additionally, we implemented an evaluation mechanism for the RSU contribution and vehicle credibility. The calculation of the RSU contribution is based on the precision deviation between an RSU and others, indicating the quality advantage of this RSU node relative to others, further ensuring the reliability of collaborative training. This, combined with the enhanced consensus mechanism and on-chain storage, results in faster convergence of our algorithm. Compared to the original Krum algorithm, although our algorithm has slightly more parameters, Krum may result in misjudgments in the presence of only one anomalous gradient, leading to the discarding of updates from honest clients. Therefore, relative to the Krum and Multi-Krum algorithms, our algorithm performs better overall. Compared to the Median algorithm, its faster inference speed is due to its reliance solely on taking the median along dimensions, but it suffers from lower overall model accuracy. In summary, our algorithm not only exhibits outstanding overall performance but also a relatively faster inference speed, making it more suitable for highly dynamic IoV systems with unstable communication.

7. Conclusions

This paper introduced the IoV-BDSS, a distributed training scheme for the Internet of Vehicles (IoV), designed to tackle privacy protection and Byzantine attacks in data sharing. Real image data and simulated label reversal attack scenarios were used to evaluate the proposed approach through various performance tests, including accuracy, average time overhead, consensus security assessment, and computational complexity analysis.

The experimental results demonstrate the robust resilience of our approach against 30% poisoning attacks, maintaining a test error rate below 0.16. Compared to similar methods, our approach reduces computational overhead by approximately 26% while preserving accuracy, thereby demonstrating its effectiveness and feasibility in achieving data sharing, privacy protection, and accuracy assurance.