1. Introduction
In recent years, the emergence of the Internet of Vehicles (IoV) has garnered significant attention, particularly within the realm of smart transportation, in enhancing security, reducing latency, and minimizing reliance on centralized infrastructures [
1]. IoV communication systems are typically classified into two primary categories: intra-vehicle and inter-vehicle communications, collectively known as Vehicle to Everything (V2X) communications [
2]. Intra-vehicle communication encompasses interactions among sensors, on-board units (OBUs), and electronic control units (ECUs) within a vehicle. On the other hand, inter-vehicle communication involves transmissions between vehicles, facilitated by wireless communication modules like OBUs, and other entities such as road side units (RSUs). The scope of inter-vehicle communication includes vehicle to vehicle (V2V), vehicle to infrastructure (V2I), and vehicle to pedestrian (V2P) interactions.
Despite its promising potential, IoV is accompanied by several security challenges and vulnerabilities. Security threats in IoV span a range of issues, including denial-of-service (DoS)/distributed denial-of-service (DDoS) attacks, eavesdropping, impersonation, man-in-the-middle (MITM) attacks, spoofing, Sybil attacks for inter-vehicle communications, and eavesdropping, masquerading, injection, DoS, and message spoofing attacks for intra-vehicle communications [
3,
4]. These threats jeopardize the confidentiality, integrity, privacy, authentication, and availability of IoV systems.
In response to these challenges, decentralized technologies, exemplified by blockchain, are increasingly recognized for their potential to bolster security across various sectors [
5,
6]. As a fundamental shift away from centralized systems, blockchain technology enhances security by distributing data across a network, thereby reducing the risks of single points of failure and increasing resistance to tampering and eavesdropping attacks [
7]. This approach has seen applications not only in communication networks, where it secures radio access networks [
8], but also in creating more robust peer-to-peer ecosystems [
9]. In addition, blockchain technology supports diverse applications across data sharing, data transactions, and copyright protection, owing to its inherent features of decentralization, immutability, and transparency [
10,
11,
12]. Moreover, blockchain technology is leveraged in broader domains, such as managing complex systems and transactional frameworks, where the secure, transparent handling of data is paramount [
13,
14,
15,
16,
17].
However, the potential of these decentralized solutions is often hindered by the absence of robust communication identity authentication mechanisms and secure, confidential communication protocols within IoV. The dynamic connectivity nature of IoV and its sensitivity to latency require that security measures not only protect data but also accommodate the system’s operational demands without introducing undue complexity. Consequently, to fully leverage the benefits of blockchain and other decentralized technologies, IoV connections must be designed to adhere to specific requirements that ensure both security and efficiency.
To address these requirements effectively, a comprehensive communication identity management system is essential for facilitating peer discovery and the secure peer-to-peer routing of P2P connections in IoV. Additionally, the servers and services supporting such a system must align with specific criteria to ensure optimal performance [
18]. IoV comprises both inter-vehicle and intra-vehicle networks, each with distinct communication levels. While non-sensitive communications should seamlessly traverse between these levels upon user request, the transfer of sensitive information from the intra-vehicle network to the inter-vehicle network raises privacy and security concerns. Therefore, it is imperative to implement separate identity management systems for these networks, ensuring a controlled and conditional exchange of information.
The advancement of IoV technology is not merely a technological issue but also a complex societal concern. Its technological improvements must comply with legal and ethical standards. Previous legal issues arising from autonomous driving technology have already drawn scholars’ attention, such as privacy issues [
19,
20,
21], security issues [
22,
23], conflicts of interest when right-of-way is contested [
24], and legal liabilities in traffic accidents [
25,
26,
27]. While we should actively embrace technological innovation, we must also recognize the legal risks that innovation brings. Therefore, after introducing the technical principles of IoV, it is essential to examine its legality and compliance to ensure that it can address previous technological loopholes in both technical and legal compliance aspects, thereby achieving significant breakthroughs. Through a legal analysis of the IoV system, it is evident that the IoV system relies on a hybrid contract framework, comprising both traditional contracts and smart contracts. Such a framework can achieve the legal objectives stipulated by data protection laws and digital regulations across different jurisdictions, such as the EU General Data Protection Regulation (GDPR) and China’s Personal Information Protection Law (PIPL). This framework involves four types of entities (RSUs, vehicles, users, and insurance companies) and five types of contractual relationships (vehicle-to-RSUs, vehicle-to-vehicle, user-to-vehicle, user-to-user, and insurance-to-user). By adopting this contract-based approach, the IoV system enhances the legal compliance requirements for autonomous driving, particularly with significant improvements in privacy protection and data security. Specifically, the IoV system should be governed by a combination of smart contracts and traditional contracts. While smart contracts offer numerous advantages for signatories and play a significant role in the IoV, the combination of smart contracts and traditional contracts could better achieve the legal values of the IoV system.
Contributions
This paper extends BeACONS [
28] by proposing and evaluating a blockchain-enabled authentication and communication network for scalable IoV. It utilizes BeMutual [
29], a blockchain-based decentralized identity management and end-to-end mutual authentication communication protocol, enhancing communication security in IoV and eliminating the reliance on centralized infrastructure. Additionally, it incorporates BeDNS [
30], a blockchain-based domain name system that provides domain binding and query for decentralized identities in BeMutual, improving system usability and semantic capabilities.
In this paper, tests are conducted on three typical scenarios in BeACONS, including (1) an unauthorized RSU entering the communication range, (2) an authorized RSU entering the communication range, and (3) an established RSU leaving the communication range. Transactions per second (TPS) and latency for these scenarios were collected and analyzed.
This paper defines the four types of participants and five types of contractual relationships in a decentralized, contract-based IoV system, validating that smart contracts hold the same legal validity as traditional contracts and can ensure legal compliance across different jurisdictions. The IoV contract system relies on the principle of autonomy of will, making it less susceptible to varying legal jurisdictions. Additionally, this paper is framed within the context of the GDPR, which serves as a representative framework for data law across multiple jurisdictions.
This paper also identifies the shortcomings of smart contracts within the IoV system, primarily their inability to balance interests between equal rights. This limitation arises from the inherently restricted content of smart contracts, their lack of interpretability, and the difficulty in modifying them. These deficiencies necessitate the supplementation of traditional contracts to address and resolve such issues.
This paper is organized as follows:
Section 2 reviews advancements and gaps in certificateless protocols and blockchain applications for the Internet of Vehicles.
Section 3 explores the system architecture, detailing primary and sub-layer components.
Section 4 provides the implementation details, including smart contract deployment and dynamic RSU management.
Section 5 discusses experimental results that validate the effectiveness of the system.
Section 6 examines the legal implications of integrating smart and traditional contracts in the IoV context. This paper concludes in
Section 7 with a summary of findings and suggestions for future research.
5. Simulations and Results
In
Section 5, four simulations of typical scenarios in the proposed system are described in detail, including the PBFT process, the inter-layer BeMutual session, the dynamic updating of the RSU communication group, and the effective RSUs. All the simulations are conducted on the local computer, which features a 13th-generation Intel Core i7-13620H center process unit (CPU) with 16 GB random access memory (RAM), operating at 2.40 GHz, running on the Windows operating system. The Python program used in the simulation was version 3.12.3, and the imported Python libraries include Web3.py, json.py, random.py, time.py, statistics.py, math.py, threading.py, and Queue.py. The above setups and parameters are shown in
Table 7.
5.1. The Runtime of the PBFT Process
As a preliminary simulation for subsequent simulations B and C, this simulation aims to test the average transaction time of the PBFT process and the corresponding TPS to simplify the simulation processes of simulations B and C. In simulations B and C, the PBFT process is omitted. The formula for calculating their total average transaction time is
Here,
is the average transaction time of the complete process,
is the average transaction time of the PBFT process, and
is the average transaction time of the BeMutual process (
) in simulation B, or the average transaction time of the entering process (
) or leaving process (
) in simulation C.
In the simulations conducted in this section, communication delays are not considered; therefore, the average transaction time obtained in simulations A, B, and C represent the lower bounds.
5.1.1. Scenario Design
The PBFT process is divided into five steps: request, pre-prepare, prepare, commit, and reply [
49]. This simulation sets up five RSUs and simulates a PBFT process initiated by a vehicle
V to verify the identity of a vehicle. In this simulation, one RSU is first randomly selected as the primary node, followed by the random selection of zero or one malicious node, with the remaining nodes being normal.
5.1.2. Simulation Setups and Parameters
The basic setups and parameters are listed at the beginning of this section. The simulation employed Geth to establish five RSU nodes and facilitate communication among six units, involving two vehicles. In this simulation, the vehicle speed v is set to 1, the RSU service range radius r is 7, and the number of RSUs and vehicles in each scenario is 6 and 1, respectively.
5.1.3. Results
In this simulation, the average transaction time of the entire PBFT process is assessed across iterations ranging from 1000 to 10,000, with a step size of 1000. The simulation calculates the average of the obtained simulation results, yielding a result of 0.0393 s:
This simulation provides the constant parameter to simplify this process in subsequent simulations B and C, thereby establishing the lower bound for the average transaction time of the corresponding scenarios.
5.2. The Inter-Layer BeMutual Session
In this IoV system, ATS and overhead are two critically important performance parameters that receive significant attention. This simulation aims to simulate BeMutual communication, testing the overall runtime of the entire process as well as the time of a single transaction (upload, update, and verification), and thus calculating the transactions per second (TPS) accordingly.
5.2.1. Scenario Design
The simulation involves setting up five RSU nodes to simulate a BeMutual communication session between vehicle and vehicle .
Simulation Preparation
Utilizing Geth technology to deploy a block-chain locally and start all RSU nodes
This step is the same as the one in simulation A.
Creating blockchain accounts for all RSU nodes
This step is also the same as the one in simulation A.
Creating a blockchain account for the vehicles and each component of the vehicles
As a client, a vehicle’s BCADD is derived from its PK and is therefore determined when the asymmetric key pair is generated during registration. This simulation simplifies this process, where blockchain accounts were created separately for vehicle 1, vehicle 2, and their respective units by the researchers via Geth directly, as the units on the vehicles have BCADDs independent of the vehicles. The above simplification will not affect the results of this simulation, as it is only part of the preparatory work and does not impact any steps within the simulation.
Writing a Python program using the web3.py package to simulate the BeMutual session
Utilizing web3.py, this simulation crafted a Python script, with a flow block diagram shown in
Figure 7, to simulate the three core transactions and the BeMutual process.
Simulation Measures
The transaction time of upload, update, and verification
This simulation tested the overhead of the three core transactions—upload, update, and verification—in the BeMutual process, and calculated the corresponding TPS. The purpose of the upload operation is to allow other vehicles to verify the mapping information of the vehicle and thus validate the identity of the vehicle, while the update operation allows clients to modify their mapping information as it changes.
The runtime of the entire BeMutual process
In this simulation, the entire BeMutual process duration was recorded, starting from the two vehicles initiating the upload of mapping information to the successful establishment of the secure BeMutual connection. A secure BeMutual connection is a necessary prerequisite for communication between two vehicles in IoV systems, and hence the data from this simulation holds critical indicative significance for ATS expectations.
5.2.2. Simulation Setups and Parameters
The basic setups and parameters are listed at the beginning of this section. This simulation deployed five RSUs, two vehicles, and six units in total to simulate the BeMutual session.
5.2.3. Results
This simulation assessed the performance of the three types of transactions and the entire BeMutual session across iterations ranging from 1000 to 10,000, with a step size of 1000. The average transaction time and the corresponding TPS were computed for each transaction above. The results were then graphically depicted, with the average transaction time for the three single transactions depicted in one graph as shown in
Figure 8, the TPS for them as shown in
Figure 9, the average transaction time for the entire process as shown in
Figure 10, and the TPS for it as shown in
Figure 11.
The results yield the following insights:
For the average transaction time, the order of magnitude is , while the corresponding order for TPS is reversed.
Both upload and update involve writing data to the BeDNS blockchain. However, the update operation also involves querying, and hence the average transaction time for update is greater than that for upload. Conversely, validation does not involve data writing, only data querying and retrieval, and hence the average transaction time is minimal, with the opposite magnitude relationship for TPS.
The line graphs of the average transaction time for upload and verification are relatively flat while the line graph of the average transaction time for update fluctuates more.
The process for the upload operation is relatively fixed, resulting in a smoother line. Although the verification operation requires querying, which may vary in time, the average transaction time is inherently short because no data writing is required, making fluctuations less noticeable in the graph. The upload operation’s average transaction time is relatively longer, and, due to the variability in querying time, the line appears more fluctuating.
The average transaction time of the entire BeMutual session shows a slight increase as the number of iterations increases.
The entire BeMutual session encompasses multiple basic transactions, resulting in a longer total time compared to a single transaction (upload, update, verification). As the total number of iterations for the entire BeMutual session increases, hardware platform limitations cause a backlog, leading to an increase in the average transaction time.
This simulation measured the average transaction time and corresponding TPS of three single transactions (upload, update, verification), as well as the entire BeMutual session. A secure BeMutual connection is a necessary prerequisite for inter-vehicle communication in IoV systems, making the results of this simulation highly indicative of the ATS of RSUs.
5.3. Dynamic Updating of the RSU Communication Group
As the vehicle travels on the road, changes in its physical location lead to dynamic updates in its trusted communication RSU group. Due to the mathematical equivalence between the service range of RSUs and the communication range of vehicles, the simulation, with vehicle V as the reference frame, investigates the entry and exit of RSUs within the communication range of vehicle V as it travels. This simulation measured the time required for the three most common scenarios in this process: (1) an unauthorized RSU entering the communication range, (2) an authorized RSU entering the communication range, and (3) an established RSU leaving the communication range, and thus calculating the TPS accordingly.
5.3.1. Scenario Design
In this simulation, six RSUs were configured for each scenario to simulate the dynamic updating of the RSU communication group for V while it is in motion.
Simulation Preparation
Utilizing Geth technology to deploy a blockchain locally and starting all RSU nodes
This step is the same as the one in simulation B. In scenes 1 and 2, six RSU nodes are configured, with five of them set as established trusted communication RSU nodes for V while the remaining one is either an illegal (for scene 1) or legal (for scene 2) RSU node about to enter the communication range. In scene 3, all six RSU nodes initially belong to the trusted communication RSU group of V, with one of them leaving the communication range of V as it moves.
Creating blockchain accounts for all RSU nodes and V
This step differs slightly from simulation B. For the illegal RSU in scenario 1, this simulation only employs one node initiated by Geth, without subsequent mapping relationship upload operations or integration into the BeDNS blockchain.
Developing a Python program to simulate the dynamic update of RSU groups
The simulation has created a Python program for each scenario separately to facilitate debugging. The flow block diagram for the RSU’s entering process is shown in
Figure 12, and the one for the RSU’s leaving process is generally similar, and will not be displayed.
Simulation Measures
An unauthorized/authorized RSU entering the communication range
The simulation randomly distributes the physical positions of RSUs according to a Poisson distribution to simulate V entering the communication range of an RSU node. The coordinates of the five initially established RSU nodes for trusted communication with V must meet the following conditions:
- -
V should be within the service range of all RSUs at the outset.
- -
V cannot leave any service range of these RSUs during the entire process.
The coordinates of the sixth RSU node used for the simulation also need to meet the following requirements:
- -
V should be out of the service range of the RSU at the outset.
- -
The RSU must be located along the direction of travel of V.
- -
When V is closest to the RSU, the distance between them should not exceed the radius of the RSU’s service range r.
Failure to meet any of the above conditions will result in simulation failure. To improve the success rate of the simulation while ensuring its randomness, the following procedures were implemented:
- (a)
The maximum distance from the initial position of V of the first five RSUs is restricted to r.
- (b)
The random distance between the initial position of the sixth RSU and the vehicle is generated within the range of r + 1 to 1.5r.
- (c)
The randomly generated azimuth angle concerning V’s travel direction is constrained within −60 degrees to 60 degrees.
- (d)
Thousands of simulations were repeated and line charts were plotted based on the results, which are described in the part in detail.
Considering the necessity of ensuring the randomness of the simulations, the above procedures cannot eliminate the possibility of simulation failures.
The aforementioned parameter adjustments (b) and (c) were adopted to improve the success rate of the simulation. To demonstrate that these two parameter adjustments do not affect the simulation results, a comparative simulation was conducted, which tested the average transaction time under conditions with and without the above parameter adjustments. The results of the simulation are as follows:
- -
For invalid RSUs, in the case with adjustments, the average of the simulation results is 0.04210, while, without adjustments, it is 0.04708.
- -
For valid RSUs with adjustments, the average of the simulation results is 0.06227, while, without adjustments, it is 0.06167.
Based on the results above, adjustments (b) and (c) do not make obvious differences to the simulation results, which can be adopted in the simulation.
The simulation only records the time of successful trials and displays the number of successful trials in the section.
An established RSU leaving the communication range
The random scattering rules of RSUs in this scenario are the same as in scenarios 1 and 2, and the initial coordinates of the six RSUs have the same requirements as the first five RSUs in scenarios 1 and 2.
As V moves, one RSU will inevitably leave the communication range of V first, ensuring that simulation failures due to RSU coordinate issues do not occur as long as all RSUs are within V’s communication range initially.
When an RSU leaves the communication range of V, the number of remaining RSU nodes participating in the PBFT mechanism decreases to an odd number, 5. The odd number 5 is chosen for the following reasons:
- -
In the PBFT mechanism,
RSUs are deployed, where
f represents the maximum number of Byzantine faults that can be tolerated. The number of nodes in a PBFT network reaches its minimum value of 4, the lower bound for the number of RSUs in this simulation, when
f is 1 [
49].
- -
An even number of nodes may negatively impact the reliability performance of PBFT consensus based on the result of the simulation in [
52].
- -
This simulation is aimed at obtaining the lower bound for the TPS of the three scenarios, and the number of nodes should be as small as possible.
Based on the reasons above, the odd number 5 is the minimal number that meets the three requirements.
5.3.2. Simulation Setups and Parameters
The basic setups and parameters are listed at the beginning of this section. In this simulation, the vehicle speed v is set to 1, the RSU service range radius r is 7, and the number of RSUs and vehicles in each scenario is 6 and 1, respectively.
5.3.3. Results
In this simulation, the performance of the three scenarios was assessed across iterations ranging from 1000 to 10,000, with a step size of 1000. The average transaction time and the corresponding TPS were computed for each scenario. The results were then graphically depicted, with the average transaction times for all three scenarios depicted in one graph as shown in
Figure 13, and the TPS for all three scenarios in another graph as shown in
Figure 14.
The results yield the following insights:
For the average transaction time, the order of magnitude is while the corresponding order for TPS is reversed.
In the scenario of valid RSU entry, after successful BeDNS verification, updates to the RSU group are conducted by both the relevant RSUs and vehicle V, while no such updates occur in the case of invalid RSU entry. Consequently, the average transaction time is shorter in the latter compared to the former, with a reversed relationship observed for TPS. Neither above scenarios involve view updates. In contrast, in the RSU exit scenario, where updates to the RSU group are executed and view change may also be initiated, the average transaction time is the longest, leading to minimal TPS.
In all three scenarios, there is a noticeable increase in the average transaction time as the number of transactions grows.
Due to hardware platform limitations, an accumulation of transactions occurs as their quantity increases, leading to a rise in the average transaction time across each scenario.
The simulation tested the dynamic updating of the RSU communication group and measured the average transaction time and corresponding TPS for three of the most common scenarios in this process. This provides a partial basis for the expected setting of ATS in subsequent simulation D.
5.4. Effective RSUs
The adequate length of the ATS serves as a guarantee for communication between vehicles and RSUs in this model, ensuring the completion of at least one full communication service cycle. This simulation aims to evaluate the average number of RSUs with ATS t longer than required (effective RSUs) along the way for different vehicles (van, private car, and taxi) based on simulations A, B, and C.
5.4.1. Scenario Design
Requirements Analysis
- -
Distribution of RSUs along the road
The simulation first needs to simulate the distribution of RSUs on the road. Considering the complexity of real-world road conditions, simulating the distribution of RSUs along the road becomes even more challenging. To simplify the simulation of RSU distribution, this simulation first randomly generates a path and then randomly places RSUs along the path, as the RSUs far away from the road do not make a difference to the result.
In the simulation, RSUs are randomly placed along both sides of the road at each distance interval d in the perpendicular direction, following a Poisson distribution. The parameter d needs an appropriate value based on the following reasons:
- *
The distance d cannot be too small as it would result in an overly dense RSU distribution.
- *
If d is too large and exceeds the RSU service radius r, vehicles passing two generated RSU sets would effectively experience two independent simulations.
Therefore, this simulation mathematically calculates the maximum RSU spacing distance
D, where vehicles passing two generated RSU sets would effectively experience two independent simulations, and sets half of this value as the
d parameter for the simulation, as shown in
Figure 15.
The formula for the value of the parameter
d is as follows:
- -
Probability turning and road generation
In real-world scenarios, vehicles do not always travel in straight lines, which impacts the ATS of RSUs because vehicles spend more time within the service range of RSUs at turns compared to straight paths. To simulate the above scenario, turning detection is conducted at each time step in the simulation. Based on the vehicle type (van, private car, and taxi), probability turning judgments are made, thereby generating random roads.
- -
Simulation Measures The overall simulation is divided into two parts: (1) random road generation and random RSU placement, and (2) simulating vehicle movement, with each part comprising half of the total simulation time T.
- *
Random road generation and random RSU placement
In the first part of the simulation, a random road is generated according to the turning rules outlined in the section, and RSUs are randomly placed along both sides of the road concurrently with road generation. For different vehicle types, variations in turning probabilities lead to differences in the complexity of the randomly generated roads.
- *
Simulating vehicle movement
Once the road is determined, the simulation proceeds to simulate vehicle movement on the road. The vehicle V travels at a speed of v, continuously updating its communication with RSUs within its communication range as V moves while recording the duration of continuous communication with the RSUs. At a certain moment, if the communication duration between V and a particular RSU reaches t, the number of effective RSUs at that state point is incremented by 1.
Upon completion of the above process, the average number of effective RSUs for all state points is computed, which serves as the simulation result for this trial.
5.4.2. Parameters
All the parameters that may impact the result are defined and configured as shown in
Table 8. The parameter
d is calculated from parameter
r and rounded to the nearest integer.
5.4.3. Results
The simulations were conducted on fifty simulated road scenarios for three types of vehicles (vans, private cars, and taxis). The resulting average effective RSU quantities are presented in
Table 9, and the representative road simulation diagrams for each vehicle type are illustrated in
Figure 16,
Figure 17 and
Figure 18.
The results yield the following insights:
For different types of vehicles, the higher the probability of turning, the more complex the randomly generated road conditions become.
From vans to private cars to taxis, as the probability of turning increases, the randomly generated roads become increasingly winding. In the randomly generated roads for taxis, loops even appear.
The average effective RSU count follows the order .
With the probability of turning increasing, as discussed in the section and as mentioned in (1), the average effective RSU count obtained from simulations increases accordingly, reflecting the prolonged ATS of RSUs at vehicle turning points.
Three types of vehicles were simulated traversing roads in this simulation, and the average number of effective RSUs was recorded. This will provide data support for the deployment of RSUs in the actual implementation of this model.
6. Legal Analysis of IoV Systems: A Contract-Based Perspective
From a legal perspective, IoV systems not only enhance the performance of autonomous driving on a technical level but also make significant progress in achieving the legal objectives enshrined in digital regulations. Compared to the existing issues of privacy invasion and illegal data collection and processing faced by autonomous driving, a contract-based decentralized IoV system is more compliant with data protection laws and other digital regulations, encompassing both virtual and real entities [
53]. However, at the current stage, legal and IoV systems are not yet perfect. To ensure that IoV development achieves legal and societal values, it is necessary for traditional contracts and smart contracts to work together, forming a comprehensive contractual framework.
6.1. Contractual Entities and Legal Relationships in IoV
6.1.1. Four Types of Entities and Five Types of Relationships in the Contractual System
Four types of entities: As illustrated in
Figure 19, these entities include RSUs, vehicles, users, and insurance companies. RSUs, or Roadside Units, function as roadside infrastructure that provides wireless services. When vehicles lack nearby RSUs or when RSUs are unavailable, they interact with edge servers as a backup through BeDNS interactions. Given the functional similarity between edge servers and RSUs and the fact that RSUs are the primary roadside infrastructure used except in special cases, the term RSUs is used to represent this category of infrastructure.
Five types of contractual relationships: These include vehicle-to-RSU interactions, vehicle-to-vehicle interactions, interactions between users and vehicles, the transfer of vehicles between users, and agreements between insurance companies and users. In these five types of relationships, the first type (vehicle-to-RSUs interaction) and the second type (vehicle-to-vehicle interaction) can be facilitated through smart contracts. These contracts, combined with blockchain technology, create a data-sharing framework based on the evolution of vehicle GPS location errors. Smart contracts can enhance the accuracy and security of vehicle location correction and data sharing in the IoV. However, due to the virtual nature of smart contracts and the difficulty in modifying blockchain-based agreements, the remaining contractual relationships (user-to-vehicle, user-to-user, and insurance-to-user agreements) still rely on traditional contracts to stipulate rights and obligations. Consequently, traditional contracts and smart contracts together form the foundation of this contract-based decentralized IoV system.
6.1.2. Legal Validity of Smart Contracts in IoV
Smart contracts possess the same legal validity as traditional contracts [
54]. Despite their unique format and recognition of commitments, this uniqueness does not impede the fulfillment of obligations [
55].
Contract Elements: The smart contract is compatible with the theory of intent expression. Deploying a smart contract on the blockchain by both parties signifies the externalization of the contract’s execution purpose, thereby producing legal effects. This aligns with the theory of intent expression in contract law. Even if the terms of the smart contract are unilaterally designed and deployed, they require the other party’s consent to be valid. If not agreed upon, the other party has the right to reject the smart contract’s application. Furthermore, both offers and acceptances are expressions of intent. Although these may not fully align with traditional contract norms in the context of smart contracts, they largely correspond. Smart contracts, written in computer language and executed on the blockchain, necessitate precise and concise expression due to computational costs and the nature of code. Therefore, the content conveyed by the code is undoubtedly specific and definite. In summary, smart contracts contain the essential elements of traditional contracts [
56]. If the contracting parties are competent, the expression of intent is genuine, and the contract does not violate laws, smart contracts should hold the same legal validity as traditional contracts.
Legal Validity of Smart Contracts Analogized to Standard Terms: A standard form contract is a preliminary form of a smart contract. Essentially, a smart contract encodes certain repeatedly applicable contractual terms into code, thereby enhancing the efficiency of contract performance. Just as standard form contracts can be used repeatedly, smart contracts can also be utilized by unspecified parties on a blockchain, where they automatically monitor and enforce the contract. Most smart contracts come with pre-drafted content that does not allow for negotiated changes. Consequently, the legal validity of smart contracts is similar to that of standard terms. For clauses in smart contracts that significantly affect both parties’ interests, there should be an obligation to provide notice and explanation.
6.2. Legal Advantages of IoV in Autonomous Driving
6.2.1. IoV in Privacy Protection
The Internet of Vehicles (IoV) utilizes blockchain technology to offer wireless interactive services, thereby minimizing the collection of excessive personal data from users. This approach ensures compliance with data protection legislation. In arguing for the data law compliance of IoV, this paper primarily uses the GDPR as the data law model to demonstrate that IoV can achieve legal compliance across different jurisdictions. Given the impracticality of comprehensively discussing the data legal systems of every country and region, choosing the GDPR is the most representative and effective way to overcome legal differences across various jurisdictions. The GDPR, as a relatively advanced and comprehensive data law, serves as a benchmark for global data protection legislation, with many other data protection laws following similar principles and frameworks. For instance, China’s Personal Information Protection Law (PIPL) [
57] and Brazil’s General Data Protection Law (LGPD) [
58] share similarities with the GDPR. Therefore, under the legal framework of the GDPR, IoV can achieve data compliance and address the previous legal shortcomings of the technology, ensuring that IoV is compliant in the majority of legal jurisdictions and capable of overcoming the legal differences posed by varying legal systems.
Explicit lawful basis for data collection and processing: In accordance with the purpose limitation principle of the GDPR, the IoV system explicitly defines the purpose of data use, data fields, types, and the accessible subject from the outset of the data collection process. This clear definition of data collection purposes is part of the user data privacy protection architecture, ensuring proper process documentation and management [
59]. Additionally, according to Article 6(1) of the GDPR, the collection and processing of personal data by IoV can rely not only on individuals’ consent but also on contractual necessity and legitimate interest to lawfully collect and process personal data. Similarly, according to Article 6 of China’s PIPL, personal information processing must have a clear, reasonable purpose, be directly related to the processing purpose, and be conducted in a manner that minimizes the impact on individual rights. The collection of personal information should be limited to the minimum scope necessary to achieve the processing purpose and should not be excessive. The IoV system processes personal data based on clear and explicit contractual necessity and the legitimate interest of both parties. By distinguishing between internal and external communications and access to personal data by design, it restricts personal information to internal communications, avoiding the transmission of personal information to external parties, thereby complying with data protection laws’ requirements.
Data minimization principle: According to the data minimization principle of Article 5 of the GDPR, the IoV architecture is designed to collect and process only the necessary personal data. Firstly, based on the operating principles of IoV, it only requires the interaction of the RSUs or edge server with the vehicle’s location information, without the need to obtain additional vehicle or user information, making the data collected reasonable. Secondly, the whole decentralized architecture differentiates between internal and external communications. For external communications involving the interaction of data between vehicles and RSUs, other servers, or other vehicles, data collection is strictly limited to the necessary minimum information.
6.2.2. IoV in Preventing Unauthorized Data Access by Third Parties
Encrypted communications: The IoV system employs encrypted communications both between vehicles and between vehicles and RSUs to prevent third-party access to data. This encryption spans the entire transmission process from the point of data generation to reception, ensuring that even if the data storage medium is illegally accessed, the data remain indecipherable. Moreover, access to data is tightly controlled [
60]. The IoV’s technical design requires users to provide private keys or other verification methods to access the system. Untrusted entities are excluded from the blockchain network, preventing unauthorized third parties from accessing the data.
Data security and sharing: Under Article 32(1) of the GDPR, data controllers and processors shall implement appropriate technical and organizational measures to ensure a level of security that mitigates potential risks. As stated in
Section 3, the sub-layer architecture can limit unnecessary access to personal data by design, preventing unauthorized third parties from accessing and obtaining data. Moreover, such a sub-layer design can facilitate secure data sharing because each entity can only access the data necessary for their processing needs. This selective access minimizes exposure and potential breaches in data sharing, thereby maintaining the integrity and security of the IoV system.
6.3. Deficiencies of Smart Contracts in Resolving the Balance of Rights between Equal Parties
Despite the significant improvements in privacy protection and prevention of third-party data access in the contract-based IoV system compared to previous autonomous driving systems, other legal issues remain. One persistent challenge is the balancing of interests between equal rights. While smart contracts, as a crucial component of the IoV, offer greater efficiency than traditional contracts, they cannot address issues of interest balancing when rights are equal. For example, they are not capable of determining when overtaking is permissible if road rights are equal or deciding whether it is acceptable to sacrifice the lives of pedestrians to protect the lives of passengers when life rights are equal. In complex traffic situations, smart contracts cannot promptly adapt to unforeseen road conditions. It is necessary to incorporate legal content and traditional contracts to make timely adjustments and address situations that smart contracts cannot cover.
6.3.1. Smart Contracts Lack Comprehensive Content to Adapt to All Driving Scenarios
They cannot contain ambiguous content: The nature of smart contracts necessitates that rights and obligations are pre-defined and encoded, making subsequent modifications particularly challenging. This characteristic underscores the importance of ensuring the accuracy of pre-defined content [
61]. Consequently, the drafting process for smart contracts must be executed with utmost caution. The automated execution of the promises contained in a smart contract, specifically their technical characteristics [
62], leads to an increased significance of the contract drafting phase compared to the execution phase. To ensure stability, the content should be precise and consist predominantly of broad, general provisions applicable to a wide range of scenarios rather than ambiguous or situation-specific terms. Smart contracts are inherently limited in the scope and detail of the provisions that they can encompass, which often results in an inability to address complex scenarios requiring nuanced judgment and flexibility. However, in real-world driving environments, conflicts between equal parties’ rights are often diverse and intricately complex, making it difficult to pre-determine rights and obligations for every possible situation.
Limitations of smart contracts in representing principle-based provisions: Smart contracts operate through automated code execution, with the actual execution process occurring rapidly. This renders principle-based contractual provisions as difficult to be effectively represented in smart contracts. Such principle-based clauses can be negotiable, interpreted, and contextualized to be applicable, which smart contracts are unlikely to execute. In contrast, the virtual entities in smart contracts lack the capacity to fully comprehend and adapt to these principles. They execute the contract strictly according to the code and computations. As a result, smart contracts cannot adequately address the diverse legal needs that arise in autonomous driving scenarios. This includes addressing how to balance different rights of the same party in case of conflicts. Such a limitation necessitates the continued reliance on traditional contracts to supplement and resolve complex legal issues that smart contracts alone cannot manage effectively.
6.3.2. The Interpretability of Smart Contracts in Balancing Interests of Parties with Equal Rights
Unlike traditional contracts, which can be interpreted by courts [
63] and adapted to unforeseen circumstances, smart contracts lack this interpretability [
64]. Specifically, smart contracts translate terms of rights and obligations into data code [
65], lacking the interpretability of natural language. To ensure the accuracy of smart contracts, they cannot include ambiguous statements. However, when conflicts of rights arise, virtual entities cannot flexibly address issues through the interpretation of specific content in the smart contract.
For example, an autonomous fleet management system governed by smart contracts can precisely define vehicle routes, speed limits, and priority rules. These terms are encoded to ensure automatic execution. The smart contract controls vehicle routes and speeds based on pre-set rules. When two autonomous vehicles (A and B) arrive at an intersection, the smart contract uses traffic conditions and signals to determine which vehicle should proceed first based on the predefined priority rules.
However, if both vehicles have equal priority and the traffic signal at the intersection suddenly fails, causing traffic confusion, the smart contract cannot adapt to this unforeseen situation. The accuracy of the smart contract terms means it cannot adjust in such emergencies, as it strictly follows the encoded priority rules and lacks the flexibility for judgment and adjustment.
6.3.3. Smart Contracts’ Rigidity and the Difficulty in Balancing Rights
Smart contracts, leveraging blockchain technology, are immutable, but this characteristic also leads to rigidity [
66]. The risk of automatically executing contract terms lies in the fact that, once enforced, it becomes difficult to make changes. This means that once a smart contract is established, the parties cannot alter its terms, limiting the scope for post-agreement negotiations. In situations where parties have equal rights, normal negotiations cannot occur automatically. This not only risks depriving the parties of their legal rights to rescind, modify, or terminate the contract but also may contradict the principles of autonomy and freedom advocated by private law.
By design, a blockchain-based immutable smart contract cannot be adjusted in the same way as a traditional contract. The immutability of blockchain contributes to the rigidity of smart contracts. Usually, once the encoded promises are set in motion, they will be executed without any possibility of exerting influence [
67]. This means that once a smart contract is established, the parties find it difficult to alter its terms, limiting the scope for "post-agreement" negotiations. In situations where parties have equal rights, normal negotiations are unlikely to occur automatically.
Even if there are possibilities to modify smart contracts, changing the code and altering the smart contract as a whole is not convenient. A rather impractical solution might be for the parties to agree to reverse the smart contract afterward. In this case, the most effective way for the contracting parties is to stop and destroy the existing contract. However, this would cause system disruptions, and restarting a new smart contract would incur certain costs. The modification of a smart contract cannot be as easily achieved as with traditional contracts, and its negotiable and revisable content is limited.
6.4. Combining Smart Contracts and Traditional Contracts in IoV to Address Conflicts of Equal Rights
6.4.1. Addressing the Limitations of Smart Contracts through Traditional Contracts
The limitations of smart contracts, particularly in terms of content adaptability, should be addressed by supplementing them with traditional contracts [
68]. As mentioned earlier, smart contracts are primarily applicable in vehicle-to-RSUs and vehicle-to-vehicle interactions. To bridge the gaps in smart contract content, traditional contracts can be employed to handle more complex and unforeseen scenarios by involving physical entities to fulfill these agreements.
Specifically, when smart contracts clearly define rights and obligations, they should be executed automatically according to their code. However, when situations arise that exceed the scope of the smart contract, traditional contracts should be used to flexibly manage these unexpected circumstances.
For example, consider a scenario where two vehicles (A and B) are traveling on the same road with equal rights. A smart contract can be pre-set to manage overtaking maneuvers. When vehicle A requests to overtake vehicle B, the smart contract checks for safety distance and speed difference conditions. If these criteria are met, vehicle B automatically yields, allowing vehicle A to overtake. This approach is effective for standard conditions covered by the smart contract’s code. However, in an exceptional situation, such as a sudden traffic accident or road construction that requires urgent action, the smart contract may not be able to adapt quickly enough to handle the new context. Additionally, it is difficult to anticipate such situations and make comprehensive provisions to be included in the smart contract. In such cases, traditional contracts can provide guidelines for drivers on how to communicate and make decisions during emergencies to ensure safety. By integrating smart contracts for routine operations and traditional contracts for complex and variable situations, a comprehensive legal framework and operational guidance can be achieved. This contract-based legal framework significantly enhances the autonomy of the contracting parties. Even parties from different jurisdictions can exercise their autonomy, jointly negotiating ways to handle conflicts of rights. This ensures that IoV achieves legal compliance across various jurisdictions [
69]. This approach ensures that smart contracts handle day-to-day operations efficiently while traditional contracts offer the necessary flexibility to address extraordinary and intricate circumstances, thereby providing full legal protection and operational direction.
6.4.2. Enhancing the Interpretability of Contracts in IoV
Incorporating traditional contract clauses: Traditional contract clauses can supplement the parts of smart contracts that require interpretation, enhancing their flexibility. For instance, traditional contracts can include emergency clauses that allow for flexible adjustments during emergencies or traffic signal failures, specifying appropriate measures for handling such situations. By combining the automated execution capabilities of smart contracts with the interpretative clauses of traditional contracts, it is possible to achieve automatic processing when needed, while also providing space for human interpretation. For, example, a traditional contract could specify that in the event of a traffic signal failure, drivers must follow certain predefined procedures to ensure safety. This clause can be referenced by the smart contract to pause automatic execution and permit human intervention.
Implementing off-chain governance mechanisms: Given that the entire IoV system includes not only the virtual entities of smart contracts but also physical entities, off-chain governance mechanisms [
70] can be implemented through traditional contracts between these physical entities. This provides methods for resolving disputes and interpreting smart contract terms outside the blockchain [
71]. Such mechanisms can include external arbitration or mediation processes, combined with traditional contracts, to address issues that smart contracts cannot handle autonomously. For instance, if a dispute arises regarding the execution of a smart contract, an external arbitration clause in a traditional contract can be invoked. This allows an independent arbitrator to review and interpret the contract terms and make a binding decision.
6.4.3. Enhancing the Flexibility of a Contract-Based IoV System
Due to the immutable nature of smart contracts, they offer high security, a characteristic that cannot be easily compromised. However, to avoid the rigidity that this immutability can bring [
72], the flexibility of the entire IoV system can be enhanced through the following methods:
Using upgradable smart contract frameworks: By employing upgradable smart contract frameworks such as OpenZeppelin, it is possible to update parts of the contract logic without altering the entire contract [
73]. This method enhances the flexibility of smart contracts when modifications or updates are necessary. Taking the proxy contract model, for example, in this model, a permanent proxy contract points to the logic contract. When the logic needs to be changed, a new logic contract is deployed, and the proxy contract is updated to point to the new logic contract.
Designing modular smart contracts: Designing modular smart contracts involves breaking down different functionalities into multiple independent contracts [
74]. This approach allows specific modules to be modified or updated without redeploying the entire system.
Combining traditional and smart contracts: Integrating traditional contracts with smart contracts can introduce human oversight into the execution process of smart contracts. This ensures that complex decisions can be reviewed and interpreted by humans when necessary, combining the advantages of automated execution with human judgment.
6.5. Summary
From a legal perspective, the IoV system cannot be fully implemented by relying solely on smart contracts, nor can it depend entirely on inefficient traditional contracts. Thus, smart contracts and traditional contracts should not be viewed as opposing mechanisms but as complementary ones. Together, they form the legal foundation of a contract-based decentralized IoV system. When the smart contract explicitly stipulates terms, the precise provisions in the contract should take precedence. However, in instances where conflicts arise between the two, the flexible and interpretable traditional contracts should take precedence.