1. Introduction
1.1. Internet of Vehicles (IoV)
IoV, one of the rapidly developing areas of the Internet of Things, is transforming the modern transportation landscape by enabling real-time communication between vehicles, infrastructure, and other entities such as manufacturers and service providers [1]. In IoV, vehicles equipped with sensors and communication systems can relay data about their location, speed, and even the occurrence of potential hazards, such as sudden braking or adverse weather conditions [2]. When this information is shared with other connected vehicles and traffic management systems, it can increase awareness among all the participants in the network, reducing the likelihood of accidents and making more informed decisions. Beyond safety, connected vehicles can revolutionize urban mobility by optimizing traffic flow, reducing congestion, and improving parking resource management [3].
However, IoV faces significant challenges related to the secure and efficient sharing of data between different stakeholders. The current centralized systems create data silos that lead to fragmentation and limited interoperability [4]. In addition, these centralized systems are prone to data breaches that compromise sensitive information such as vehicle status, driver behavior, and insurance records. The lack of a standardized, transparent, and trustworthy platform further hinders collaboration among stakeholders and reduces the efficiency of operational processes [5]. Therefore, there is a need for an approach to build a secure, transparent, and interoperable data-sharing platform that fosters trust, ensures data privacy, and improves efficiency within the connected car ecosystem.
1.2. Blockchain
Blockchain technology was first introduced in 2008 to support the cryptocurrency Bitcoin and has since attracted significant interest due to its potential to revolutionize industries beyond finance [6]. In a blockchain network, data are stored in consecutive blocks that are linked together to form a chain. Each block contains a set of transactions or messages that are verified and encrypted by a network of distributed participants, often called nodes or miners. Once a block is added to the chain, it becomes immutable, ensuring that the recorded data cannot be modified or deleted, thus providing a tamper-proof and secure ledger [7]. Nowadays, blockchain technology has emerged as a revolutionary solution to the challenge of secure and transparent data sharing across industries. Its decentralized, immutable, and tamper-proof nature makes it particularly suitable for managing sensitive data and ensuring trust between untrusted parties. Blockchain enables seamless information sharing among multiple stakeholders, ensuring data integrity and traceability while protecting privacy [8].
1.3. Hyperledger Fabric (HLF)
HLF is an open-source blockchain framework developed by the Linux Foundation as a part of the Hyperledger Project specifically to meet the needs of enterprise-class blockchain applications [9]. Unlike public blockchains that rely on open participation and resource-intensive consensus mechanisms, HLF is designed to operate as a permissioned blockchain, where only authorized entities are allowed to join the network. This permissioned architecture makes it particularly suitable for environments such as connected car networks, where privacy and controlled participation are critical [10].
One of the main advantages of the HLF is its use of smart contracts, called “chaincode” in Hyperledger terminology. Chaincode defines and automates business logic, ensuring that transactions between participants are executed according to predefined rules [11]. Chaincode is executed in Docker containers, ensuring isolation and security for each instance. It runs on peer nodes and interacts with the ledger via the Fabric chaincode lifecycle. The Fabric chaincode lifecycle provides a well-defined process for managing chaincode, including packaging, installing, approving, and committing. This ensures that chaincode deployment is secure and that all the participating organizations reach a consensus before activation. Users or applications invoke chaincode functions to perform specific operations, such as querying data or submitting a transaction [9,12]. Chaincode is crucial for implementing the business logic for different channels in our multi-channel architecture. Each channel has its own chaincode to handle channel-specific data and policies, ensuring isolated and efficient data operations. This automated and secure contract management process simplifies complex workflows in connected vehicle networks, including the management of vehicle status, insurance policy claims, and parking facilities. This is particularly useful when participants need to establish trust in a decentralized network without relying on a central authority.
In addition, HLF’s channel is a defining feature that sets it apart from other blockchain solutions. Channels in HLF can be thought of as private “sub-networks” within a larger blockchain network [13]. Channels enable organizations to share data securely without exposing it to the entire network. Only the members of a channel can access its ledger and participate in transactions. It means that access to a channel’s data and chaincode is restricted to its members. Transactions in one channel have no impact on other channels, ensuring operational independence [9]. In a network of connected vehicles, data generated by sensors, usage patterns, and maintenance logs may require different access rights for different stakeholders. HLF’s endorsement policy adds additional security by allowing organizations to specify which members must approve a transaction before it becomes part of the ledger [10].
1.4. Motivation and Challenges
The rapid proliferation of Internet-connected vehicles and the emergence of the IoV have revolutionized the transportation system, enabling vehicles to share data such as traffic conditions, operational status, and environmental information in real time. However, the increasing reliance on data sharing poses significant challenges related to data privacy, security, trust, and scalability that traditional centralized systems have struggled to effectively address [14].
Blockchain technology, with its decentralization, offers promising solutions to these challenges [8]. In particular, HLF has strong scalability while ensuring efficient and secure transactions [10]. By leveraging this technology, our research aims to design a blockchain-based system that can handle the complex requirements of IoV, such as real-time data exchange, privacy protection, and scalability while building trust among different stakeholders, such as manufacturers, insurance companies, and traffic authorities.
Despite the potential of blockchain technology, there are still a number of challenges waiting to be resolved in order to build a robust and efficient system for IoV [15]:
Data Security: IoV involves sensitive data such as vehicle location, operational status, and user identity. Ensuring that data are shared securely and only with authorized parties without compromising user privacy is a complex challenge.
Performance: IoV generates large amounts of data in real time, requiring blockchain systems to handle high transaction throughput while keeping latency low. The design must address the trade-off between decentralization and performance.
Trust Among Stakeholders: Building trust in a decentralized environment with different stakeholders such as manufacturers, insurance companies, and traffic authorities requires strong consensus mechanisms and governance models.
Data Isolation: The isolation of specific data ensures the rights and interests of different organizations. Blockchain systems need to develop functionality that is tailored to the specific needs of the organization to ensure the proper management of specific data.
1.5. Our Contributions
In this paper, we propose a blockchain-based system architecture for IoV using HLF. Our contributions are summarized as follows:
Multi-Channel Design: We introduce a multi-channel architecture in HLF specifically tailored for IoV. In the system, different types of data are exchanged across multiple channels involving various organizations. Each channel is dedicated to specific types of data such as vehicle status, insurance policies, and traffic conditions. This approach allows different stakeholders to collaborate efficiently while maintaining strict access control policies.
Cross-Channel Communication using Chaincode: We develop and implement cross-channel communication using chaincodes, which is a key aspect of our multi-channel approach. This allows for the secure querying and exchanging of data across different channels. For instance, vehicle status data from one channel can be queried by a related insurance policy channel. Chaincode can enhance the system’s capability and provide a comprehensive data management solution.
Functional Testing: Self-defined node parameters ensure that organizations can choose the number of nodes according to their needs. Chaincode deployment and testing ensure stable information exchange between organizations. By implementing and testing our multi-channel system in a real blockchain environment, from deployment to functionality, we demonstrate its scalability, feasibility, and reliability.
Performance Analysis: We conduct performance tests in different situations, even including high-pressure situations. We test the main functions of the proposed system. The results validate the system’s ability to handle high transaction volumes while ensuring stable performance across diverse workloads. At the same time, it is also an important process for our system to approach the real environment.
2. Literature Review
Blockchain-based product traceability systems are receiving increasing attention from industry and academia. Ding et al. [16] proposed a permissioned blockchain-based double-layer framework for a product traceability system that addresses key challenges such as privacy protection, scalability, and regulatory compliance. In their framework, the consortium blockchain serves as the main layer, sharing product traceability information among organizations and allowing consumers to access the data, while a private blockchain is used for sensitive data storage within each enterprise. Unlike traditional single-layer systems, the double-layer framework separates data entry from data sharing. This separation enhances the scalability of the system and ensures better performance when handling a large number of transactions. In addition, the double-layer structure allows regulatory agencies to participate in the traceability process, which enriches traceable information and improves the reliability and credibility of the system.
Hussain et al. [17] proposed a blockchain-enabled secure communication framework aimed at enhancing trust and access control within the IoV ecosystem. The framework includes two core modules: a vehicle registration system and a message alert generation system, which use smart contracts to ensure the secure interaction of autonomous vehicles. A key aspect of their solution is the use of Ethereum’s decentralized environment to manage interactions, ensuring that vehicle data integrity and reliability are maintained throughout the communication. The proposed framework introduces a decentralized design that leverages the proof-of-stake (PoS) consensus mechanism to handle transaction validation, which reduces computational overhead compared to proof of work (PoW). This makes the system more energy efficient and suitable for real-time vehicle-to-vehicle communication, an essential feature in IoV scenarios where efficiency and timely data exchanges are critical.
Ndzimakhwe et al. [18] present an innovative approach to solving privacy and data integrity issues within electronic health record (EHR) systems by employing HLF as the foundational technology. HLF allows for granular privacy control, ensuring that only authorized participants have access to particular datasets. This aligns with the privacy requirements critical in healthcare environments. Chaincode in the framework manages user permissions effectively. This contract-driven mechanism supports fine-grained access controls, enabling users to grant and revoke data access permissions dynamically. This system guarantees data immutability, meaning any changes to the health records are securely logged in a transparent yet privacy-preserving manner. The relevance of this study to connected vehicle networks lies in its demonstration of how HLF can manage sensitive data in a secure, distributed manner, with a high emphasis on privacy and selective data sharing.
Novo [19] explores a decentralized access control system leveraging blockchain technology to manage IoT devices. Traditional centralized access control systems are identified as limited in their scalability and adaptability, especially in dynamic IoT scenarios. The proposed architecture addresses these limitations by eliminating reliance on central authorities. It can ensure mobility, scalability, and transparency in access control. This work highlights a blockchain-based system where IoT device access policies are enforced through a single smart contract. This reduces overhead and enhances policy management. Also, IoT devices remain independent of the blockchain network while managers enforce policies. This ensures scalability and cross-domain adaptability. By using lightweight mechanisms and a management hub, the system caters to constrained IoT devices while maintaining security and data integrity.
3. System Design
The proposed system focuses on secure and trustworthy data exchange between various stakeholders, such as vehicle manufacturers, insurance companies, service stations, and regulatory bodies. We leverage the features of HLF—particularly its channel architecture, consensus mechanisms, and chaincode—to provide the necessary security, privacy, and efficiency in vehicle data management.
3.1. System Architecture
As shown in Figure 1, our HLF-based system is composed of several components that work together to enable a decentralized and secure environment for data exchange.
3.1.1. Organizations and Peer Nodes
In HLF, each stakeholder is represented by an organization [9]. Our system consists of nine organizations. Org1 represents the vehicle manufacturer and holds the running status of the vehicle. Org2 and Org3 are also manufacturers. But, they are below Org1. In other words, Org2 and Org3 can also be branches of Org1. Org4 stands for a vehicle insurance company. It holds the insurance status of the vehicle. Org5 and Org6 are like Org2 and Org3; they are also branches of Org4. Finally, Org7 stands for the traffic management department. It has information on real-time road conditions and surrounding facilities, such as parking lots, etc. Org8 and Org9 belong to the subordinate departments of Org7. Each organization has its own peer node that is responsible for executing chaincode, endorsing transactions, and maintaining the distributed ledger. Each peer node is linked to its organization’s membership service provider (MSP), which ensures proper identity management [10]. Multiple peer nodes can exist within each organization for information storage and sharing. For testing purposes, we set up only one node per organization.
3.1.2. Orderer Nodes
Our system employs a distributed ordering service consisting of three orderer nodes Orderer1, Orderer2, and Orderer3. We use the etcd Raft consensus protocol to ensure fault tolerance and maintain consistency across the network [20]. The orderers are responsible for collecting transactions from different organizations, ordering them, and then creating blocks to be distributed to peers. These orderer nodes are distributed among the stakeholders to avoid centralization, thereby providing resilience to failures and attacks.
3.1.3. Channels
One of the critical aspects of our system is the use of multi-channel architecture to achieve data isolation, privacy, and efficient communication. The channels allow different groups of organizations to share data without exposing it to unauthorized entities. There are four channels in our system.
Channel A serves as the central channel for the entire system. It connects the exchange of information between different organizations. It realizes the sharing of different kinds of information across organizations. For example, the traffic management department can call the insurance information of specific vehicles through Channel A. For security and authority reasons, only main organizations can join Channel A. Branches, such as Org2 and Org3, and subsidiaries cannot join.
Channel B includes Org1, Org2, and Org3. They share information about the real-time status of the vehicle, such as position, speed, etc., within the channel. Figure 2 shows the structure of the real-time state of the vehicle that we set up during the testing phase.
Channel C includes Org4, Org5, and Org6. It serves as a conduit between insurance companies, primarily for the sharing of vehicle insurance information. Figure 3 shows the structure of the insurance information.
Channel D includes Org7, Org8, and Org9. It serve as a conduit between the traffic management department and subordinate departments to share information such as real-time road conditions and surrounding facilities. In our testing, we set up real-time information on parking lots. Figure 4 shows the structure.
3.1.4. Certificate Authority (CA)
CA plays a crucial role in establishing identity management, authentication, and authorization. CA is a fundamental component for managing identities and securing communication in the HLF network. Each organization has its own CA to issue digital certificates and keys, ensuring secure identity management and mutual authentication among the nodes.
The CA issues digital certificates to peers, orderers, and clients, which serve as cryptographic credentials for verifying identities. The CA issues Transport Layer Security (TLS) certificates to peers, orderers, and clients, enabling encrypted communication between network components. This ensures that data transmitted over the network remains secure and prevents unauthorized access. Also, the CA can revoke certificates when necessary, such as when a participant’s credentials are compromised. This ensures that revoked participants cannot access or interact with the network.
Here is the workflow of CA. Participants are first registered with the CA, which assigns them identity attributes. During enrollment, the CA generates a key pair and issues a certificate to the participant. HLF’s MSP uses CA-issued certificates to manage identities within the blockchain network. MSP ensures that only valid identities interact with the network. TLS certificates secure communication between peers, orderers, and clients. Additionally, multi-channel architecture ensures that only authorized members access specific channel data.
3.1.5. Docker and CouchDB
Our system is deployed using Docker for container orchestration. Docker provides a scalable and manageable environment for a distributed blockchain network. All peers, orderers, and CAs are deployed as Docker containers. This ensures easy deployment, isolation, and scalability. It allows each organization to manage its resources independently.
Meanwhile, each peer node in the network maintains a ledger and uses CouchDB as the state database. The integration of CouchDB with peer nodes facilitates the efficient querying of vehicle and service-related data.
3.2. Consensus
The consensus protocol used in this system is the etcd Raft consensus protocol. It is a key feature of HLF to ensure the ordering of transactions in a secure and efficient manner [20]. This protocol is particularly well suited for enterprise blockchain applications where resilience and stability are critical.
In the system, etcd Raft achieves consensus through a leader election process. One node is elected as the leader, and it coordinates all the transactions among the other nodes, which act as followers. This leader-based mechanism ensures that the transactions are processed in a sequential manner, minimizing conflicts and ensuring data integrity. The leader is responsible for proposing transaction blocks. Once a majority of the nodes (the followers) agree on the proposed block, it is committed to the blockchain [13].
In our system setup, three orderer nodes are deployed as part of the etcd Raft consensus group. Each orderer node runs an instance of the etcd Raft protocol to replicate data and to ensure that all the nodes have the same view of the ledger. This setup enhances the fault tolerance of the network. It allows the system to continue operating even if one or two of the orderer nodes fail.
3.3. Chaincode
In our system, the chaincode is written in the Go language. The lifecycle of chaincode deployment follows several steps. It begins with packaging and installation. Then, each organization will approve it. Finally, the chaincode will be committed to the channel. This process ensures that the defined logic is agreed upon and trusted by all the participants [9]. Figure 5 shows the structure of chaincodes in our system. Basically, as the central channel, Channel A operates the UnifiedQuery() function to query data from Channels B, C, and D. Meanwhile, Channels B, C, and D operate the Create(), Query(), Update(), and Delete() functions to process the data.
3.3.1. Channel A
In Channel A, the chaincode is designed to facilitate cross-channel queries that enable Channel A to interact with information present in Channels B, C, and D. Before querying, the client’s identity and permissions are verified using the MSP of the respective organization. TLS encryption ensures that the communication between the client and the peer nodes is secure. The system leverages HLF’s inter-channel capabilities, called InvokeChaincode API, to fetch information about vehicles, insurance policies, traffic conditions, and parking facilities from different channels. The request is forwarded to the chaincode associated with Channel A. Then, the chaincode processes the request and interacts with CouchDB to fetch the required data. The chaincode retrieves the queried data and returns it in a structured format, such as JSON, to the client.
The chaincode includes functions for querying vehicle status and history from Channel B, querying insurance policy information from Channel C, and querying traffic conditions and parking facility data from Channel D. The chaincode is shown in Algorithm 1.
| Algorithm 1: Chaincode in Channel A |
| Input: Transaction Context (ctx), various identifiers (vehicleID, policyID, facilityID, location, localTime) |
| Output: String representing the result of the cross-channel query or error message |
| function QueryVehicleStatus(ctx, vehicleID) |
| args = [ChannelBQuery, vehicleID] |
| response = ctx.InvokeChaincode(ChainCodeBName, args, ChannelB) |
| if (response is invalid) then |
| return response.Message |
| end if |
| return response.Payload |
| end function |
| function UnifiedQuery(ctx, channel, action, id, localTime) |
| clientMSP = ctx.GetClientIdentity().GetMSPID() |
| if (call channel B but MSP is not Org1MSP) then |
| return “Only Org1 can query Channel B” |
| else if (call channel C but MSP is not Org4MSP) then |
| return “Only Org4 can query Channel C” |
| else if (call channel D but MSP is not Org7MSP) then |
| return “Only Org7 can query Channel D” |
| end if |
| switch channel: |
| case ChannelB: |
| if (action is VehicleStatus) then |
| return QueryVehicleStatus(ctx, id) |
| else if (action is VehicleStatusHistory) then |
| return QueryVehicleStatusHistory(ctx, id) |
| end if |
| case ChannelC: |
| if (action is InsurancePolicy) then |
| return QueryInsurancePolicy(ctx, id) |
| else if (action is InsurancePolicyHistory) then |
| return QueryInsurancePolicyHistory(ctx, id) |
| end if |
| case ChannelD: |
| if (action is TrafficCondition) then |
| return QueryTrafficCondition(ctx, id, localTime) |
| else if (action is ParkingFacility) then |
| return QueryParkingFacility(ctx, id) |
| end if |
| end switch |
| return error |
| end function |
The chaincode related to the query is used to retrieve information from Channels B, C, and D. Their structure is similar, thus we only show QueryVehicleStatus() in Algorithm 1. It accepts vehicleID as input and then invokes the chaincode on Channel B to obtain the data. The output is the current status of the vehicle, such as location. Also, The UnifiedQuery() function acts as a generic entry point that allows users to access multiple query types through a single function call. Based on the input parameters, this function will dynamically decide which specific query function to call. This simplifies user interaction with the system and provides a streamlined method to access multiple datasets across different channels.
3.3.2. Channels B, C, and D
The chaincode in channels B, C, and D offers a set of functions to perform CRUD (Create, Read, Update, and Delete) operations and historical queries. Algorithm 2 shows the chaincode in Channel B. For additions, the implementation of CRUD in Channel C and D is the same as in B. Therefore, we only show the algorithm in Channel B.
| Algorithm 2: Chaincode in Channel B |
| Input: VehicleID, Location, Speed, FuelLevel, Battery, Timestamp |
| Output: |
| - Confirmation of success or failure |
| - Requested Vehicle Status or History |
| function CreateVehicleStatus(vehicleID, location, speed, fuelLevel, battery, timestamp) |
| if (this vehicle ID already exists) then |
| return “Error: Vehicle already exists” |
| end if |
| create vehicleStatus |
| serialize vehicleStatus to JSON |
| store JSON in Ledger[vehicleID] |
| end function |
| function QueryVehicleStatus(vehicleID) |
| fetch data from Ledger[vehicleID] |
| if (data is NULL) then |
| return “Error: Vehicle not found” |
| end if |
| deserialize data to VehicleStatus |
| return VehicleStatus |
| end function |
| function UpdateVehicleStatus(vehicleID, location, speed, fuelLevel, battery, timestamp) |
| if (vehicle does not exist) then |
| return “Error: Vehicle not found” |
| end if |
| update status |
| serialize vehicleStatus to JSON |
| store JSON in Ledger[vehicleID] |
| return “Vehicle status updated successfully” |
| end function |
| function DeleteVehicleStatus(vehicleID) |
| if (vehicle does not exist) then |
| return “Error: Vehicle not found” |
| end if |
| delete Ledger[vehicleID] |
| return “Vehicle status deleted successfully” |
| end function |
| function VehicleStatusExists(vehicleID) |
| fetch data from Ledger[vehicleID] |
| return data is not NULL |
| end function |
| function QueryVehicleHistory(vehicleID) |
| fetch history from Ledger[vehicleID] |
| if (History is empty) then |
| return “No history available” |
| end if |
| deserialize history to List[VehicleStatus] |
| return List[VehicleStatus] |
| end function |
These functions ensure the complete lifecycle management of the vehicle status data. CreateVehicleStatus() adds a new vehicle status record to the ledger and validates that the VehicleID does not already exist. Finally, it encodes the data as JSON and writes it to the ledger. QueryVehicleStatus() retrieves the latest status for a given vehicle. It can decode JSON data. UpdateVehicleStatus() updates an existing vehicle record. It can modify the fields and write the updated JSON back to the ledger. DeleteVehicleStatus() deletes a vehicle status record. It can verify the record exists before removing it from the ledger. Chaincodes in Channel C and D have similar structures.
3.4. Use Cases
The proposed system involves diverse stakeholders, such as vehicle manufacturers, insurance companies, and traffic management departments. They need to exchange data in a secure, transparent, and efficient way. The multi-channel blockchain system is designed to address these challenges by enabling isolated yet interconnected communication between these entities. To illustrate the practicality and effectiveness of the proposed architecture, we present two representative use cases: accident management and Parking Assistance. These scenarios demonstrate how the multi-channel design optimizes data flow. The detailed workflows below highlight the advantages of the system and its potential for real-world applications.
3.4.1. Accident Management
Accident management is a critical aspect of IoV, requiring collaboration between vehicle manufacturers, insurance companies, and traffic management departments. Accident data are shared only with relevant parties through their respective channels.
Accident Detection: A vehicle detects an accident using onboard sensors, such as collision detection or sudden deceleration, and records the event. The vehicle’s onboard system sends the traffic details through facilities with communication capabilities, such as Roadside Units, to relevant nodes in Channel D, the traffic management department's channel, and the vehicle’s status to nodes in Channel B, the manufacturers’ channel.
Data Sharing Across Channels: The vehicle manufacturer verifies the accident report and updates the vehicle’s status on Channel B. Meanwhile, the traffic management also verifies the report. At this time, the vehicle’s status is shared with the traffic management department through Channel A.
Traffic and Emergency Management: Traffic management will take appropriate actions based on the vehicle’s status obtained from Channel A and the traffic details in Channel D.
Insurance Processing: Insurance companies can query relevant data through Channel C to verify the accident situation to implement the claims process. Using immutable blockchain records, claims processes can reduce the risk of fraud.
Post-Accident Actions: Once the accident is resolved, all the records can be stored in the blockchain. Immutable accident records enhance trust among all the parties.
3.4.2. Parking Assistance
Efficient parking management is another vital use case for IoV, involving real-time data sharing between vehicles and traffic management departments.
Parking Availability: The traffic management department collects vehicle status and location information through Channel A from vehicle manufacturers and basic parking information in Channel D to generate real-time parking information, including location, total spots, available spots, and pricing.
Parking Request: Traffic management departments can send real-time parking information to drivers through facilities with communication capabilities, such as Roadside Units. Drivers can request this kind of information by using the onboard system.
Parking Information Update: When a vehicle decides on a parking location, the real-time status of the vehicle is uploaded into the system. The traffic management department can update the parking information at any time by obtaining the vehicle status information through Channel A. When the vehicle leaves the parking location, the parking information can also be updated.
Optional Payment Method: The insurance company can also query vehicles’ parking records through Channel A while the vehicle decides the parking location. The driver can decide to include the parking bill in the insurance bill and pay it with the insurance.
4. Deployment and Testing
4.1. Deployment
Before testing our system, the deployment of the HLF network and chaincode is an important step.
4.1.1. Deployment of HLF Network
In this section, we outline the step-by-step process for deploying a HLF network to support our proposed multi-channel system. The deployment involves generating cryptographic materials, configuring the network structure, creating channels, and connecting peers from different organizations to their respective channels. Below, we detail each step of the deployment process.
Step 1: We use the cryptogen tool to create cryptographic certificates for all the network entities [9]. These materials are critical for creating secure communication and identity verification. By using this tool, we can create MSP directories and TLS certificates for peers and orderers.
Step 2: We use the configtxgen tool to define the structure and policies of the network. In total, we create the genesis block, which defines the orderer and consortium configurations, and configuration files for application channels and for updating the anchor peers of each organization in each channel.
Step 3: We submit the channel configuration transactions to the orderer to create channels. In this step, the peer channel create command is used for creating each channel.
Step 4: It is necessary to connect peers from various organizations to their respective channels. We need to set the peer’s MSP, TLS root certificate, and address and use the peer channel join command to associate each peer with the appropriate channel block.
Step 5: The peer channel update command is used to update transactions to designate specific peers as anchor peers.
4.1.2. Deployment of Chaincode
This section describes the process of deploying and activating chaincode on the HLF network. Chaincode, which implements the business logic of the system, must be packaged, installed, approved, and committed across all the relevant organizations within their respective channels. This ensures consensus on the chaincode’s configuration and enables its functions to be executed securely on the blockchain. The following steps outline the detailed deployment process.
Step 1: We need to package the chaincode into a format suitable for distribution across the network [9]. The chaincode is developed using Go in our system. The peer lifecycle chaincode package command is used to package the chaincode into the .tar.gz file. This file contains all the chaincode source code and metadata.
Step 2: The packaged chaincode is installed on all the peer nodes of the participating organizations in the respective channel. For example, in Channel D, the packaged chaincode is only installed in Org7, 8, and 9. Therefore, environment variables specific to each organization are set to identify the target peer for installation. The peer lifecycle chaincode install command is executed to install the chaincode package on the peer node. Once installed, the chaincode’s unique ID is queried and stored for further approval steps.
Step 3: To ensure that all the organizations agree on the chaincode’s parameters, each organization must approve the chaincode definition. The peer lifecycle chaincode approveformyorg command is used in this step.
Step 4: Once all the organizations have approved, the chaincode is committed to the channel, making it active for use. In this step, the peer lifecycle chaincode commit command is used and the peer lifecycle chaincode querycommitted command validates the chaincode deployment.
Step 5: Finally, we can test the chaincode by invoking its functions and querying data.
4.2. Testing
In this section, we will show the results of the process of deployment and functional test.
4.2.1. Channel Creation
As shown in Figure 6, the creation of Channel A begins with initializing the endorser and orderer connections. This confirms the communication setup between peers and the orderer. Also, initial attempts to retrieve the channel genesis block resulted in various statuses. NOT_FOUND suggests the block was not yet created and SERVICE_UNAVAILABLE indicates the temporary unavailability of the orderer service. After a series of retries, the genesis block for each channel was successfully retrieved. In a nutshell, the retry mechanism can ensure resilience against transient failures and the genesis block shows successful channel creation.
4.2.2. Peer Joining Test
As shown in Figure 7, each peer successfully submitted a proposal to join the channel. The successful join operation confirms that the channel block is valid and the peers are configured correctly to participate in the channel. These results confirm the proper configuration of MSPs, certificates, and block files.
4.2.3. Anchor Peer Update Test
Anchor peers for each organization were updated to enable inter-organization communication. As shown in Figure 8, updates to anchor peer configurations were successfully submitted. All the anchor peer updates were processed without errors, indicating robust coordination among the peers, orderer, and the configuration update mechanism.
4.2.4. Query Channel Information Test
It is necessary to query information about the four channels to verify their proper configuration and deployment. The goal is to ensure that all the participating organizations have successfully joined their respective channels and that the ledger state is synchronized across peers. As shown in Figure 9, as we expected, Org1, 4, and 7 joined into Channel A properly. The consistent ledger height validates proper transaction propagation and block generation across the channel. Also, “_lifecycle” shows that the chaincode lifecycle management process is operational. Due to the excessive length of the image, Figure 9 only shows the information for Org4, omitting the information for Org1 and Org7. The information for Org1 and Org7 is the same as for Org4, except for Endpoint and Identity.
4.2.5. Deployment of Chaincode Test
In this part, we tested the deployment, approval, and functionality of the chaincodes across the respective channels. As shown in Figure 10, the chaincode installation succeeded across all the peers in Channel B. Also, the generated package identifier is the same across all the installations. It confirms successful packaging and propagation.
Then, as shown in Figure 11, all the participating organizations, Org1, 2, and 3, approved the chaincode definition for Channel B. It means endorsement policies and chaincode parameters were correctly validated and accepted.
After approval, as shown in Figure 12, the chaincode was committed successfully on all the peers in Channel B. The committed version 1.0 and sequence 1 confirm the initial deployment. Finally, it is a functional test.
As shown in Figure 13, in Channel B, we operated the CreateVehicleStatus() function to create statues in advance and the result shows that chaincode executed the CreateVehicleStatus() function successfully, indicating proper function implementation. Then, by operating the QueryVehicleStatus() function, vehicle status was retrieved successfully with expected values. Next, by operating the UpdateVehicleStatus() function, the vehicle status was updated correctly and the updated values were reflected in the subsequent queries. In the end, the history query correctly retrieved all the changes to the vehicle status. The basic function of Channels B, C, and D is the same, so only the result of Channel B is shown here.
For Channel A, which is the central channel of the system, we did a unified query test across channels. As shown in Figure 14, we can see that the unified queries successfully retrieved data across Channels B, C, and D. For Channel B, the query retrieves vehicle operational data. For Channel C, the query fetches insurance policy details. And, for Channel D, the unified query retrieves two types of data, traffic condition data, and parking facility data. Each query is limited to its respective channel, demonstrating the privacy and isolation features of the system. This figure serves as evidence of the system’s ability to segregate and query channel-specific data efficiently. It also emphasizes the potential of blockchain-based multi-channel architecture in managing diverse datasets.
5. Performance Analysis
Performance analysis is a critical aspect of evaluating the practical feasibility and efficiency of the proposed multi-channel system. In this section, we show the setup of the test environment and results.
5.1. Test Environment
In this work, we use Hyperledger Caliper (Caliper) to monitor the network performance. Caliper is a performance benchmarking tool specifically designed for blockchain platforms, including HLF. It provides a standardized way to evaluate and measure the performance of blockchain networks under various configurations and workloads [21]. The proposed system and performance test are implemented on a local personal computer (PC) which has 10 CPU cores: Intel(R) Core(TM) i9-10900K 3.70 GHz, Ram 16.0 GB. PC runs the Linux distribution Ubuntu 22.04 by using Windows Subsystem for Linux (WSL).
5.2. Performance Measurement
We focus on two indicators to measure the performance of the system. These indicators include the number of transactions per second (TPS), known as throughput, and the latency, which means the overall time the transactions take from issuing to the response.
5.3. Benchmark Setup
Before testing the performance, we need to set up the workspace which is related to benchmark files. The workspace includes three parts: networks, workload, and benchmarks. The network includes a network configuration, which contains compulsory information about the work, such as channels, organizations, etc. The workload is the key part of Caliper. It defines the way to interact with chaincodes. The benchmark is a configuration file for the execution of Caliper. It defines some parameters during the process of the performance test.
To achieve different results during the performance test, our benchmark configuration includes the following parameters:
Worker Numbers: Worker represents the number of threads. More workers represent more concurrent transaction requests. However, more workers will send more transactions, which may cause transactions to be cached or queued, increasing the load on the system. We set three different values: 5, 25, and 50.
Number of Transactions (txNumber): It defines the total number of transactions executed during the test period. A larger number allows testing the stability of the system over a long period of time. We set three different values: 1000, 2000, and 5000.
Transactions Per Seconds (transactionLoad): It defines the number of transactions sent per second. In order to test the latency and maximum throughput in different scenarios, we set three different values: 50, 100, and 200.
High-Pressure Test: We additionally test the system’s performance in a high-pressure environment. We set the number of workers to 50 and the TPS to 400. In particular, we did not use the total number of transactions. We set the total transaction duration (txDuration) to 300 s. The purpose is to perform continuous testing over a long period of time.
5.4. Results and Evaluation
We mainly tested the CRUD function in the system. The CRUD logic in Channels B, C, and D is the same, so we summarize the results in five parts, Create(), Query(), Update(), Delete(), and high-pressure test.
5.4.1. Create()
First, to test the impact of the total number of transactions and TPS on the performance of the system, we fix the number of workers to the default of 5. Then, we change the values of the total number of transactions and TPS, respectively, for testing. The result is shown in Table 1. As the TPS increases (from 50 to 200), both the send rate and throughput improve significantly. At higher TPS (e.g., 200), the throughput approaches the send rate, indicating that the system is efficiently processing transactions and has not yet reached a performance bottleneck. Latency is relatively high for lower TPS (around 2 ms for TPS = 50 and 100). At higher TPS, latency drops significantly (to ~0.6 ms). The reason may be that at higher transaction rates, batching and block generation may optimize the overall performance, reducing per-transaction latency. Increasing txNumber (from 1000 to 5000) while keeping TPS fixed does not significantly affect the send rate or throughput. This suggests that the system maintains consistent performance over larger transaction loads.
Then, to test the impact of the number of workers, we fix the number of total transactions and TPS during the test process. We set 2000 transactions and 100 TPS as the fixed parameters. The result is shown in Table 2. Increasing the number of workers leads to a higher send rate and throughput. The reason is that additional workers generate more concurrent transactions, effectively utilizing the network’s capacity for parallel processing. Latency increases slightly from 1.79 ms (5 workers) to 2.05 ms (25 workers) but decreases slightly at 50 workers (1.93 ms). The reason may be that at higher concurrency, peer and orderer nodes process transactions more efficiently due to better batching and resource utilization. With 50 workers, the system achieves its highest throughput while maintaining acceptable latency, indicating that the resources are not yet saturated.
5.4.2. Query()
The setup is the same as the test of the Create() function. The result of the Query() function with the fixed number of workers is shown in Table 3. As TPS increases from 50 to 200, both the send rate and throughput increase but begin to saturate. With the fixed number of workers, the system achieves near-optimal performance, as indicated by the minimal differences between the send rate and throughput across various txNumber values. For a larger txNumber (e.g., 5000), the system maintains stable performance with high throughput. The reported latency is essentially negligible (0.00 or 0.01 ms), indicating that query operations are highly efficient. This is expected since queries are typically read-only and do not involve state updates, allowing for faster execution. Therefore, increasing the total number of transactions from 1000 to 5000 does not significantly affect throughput or latency, demonstrating that the system scales well under the given load.
The result of the Query() function with the fixed number of transactions and TPS is shown in Table 4. Contrary to expectations, increasing the number of workers leads to a decrease in both send rate and throughput. For 5 workers, the system achieves a send rate of 1042.8 and a throughput of 1041.1 TPS, which significantly drops to 179.1 and 179.0 TPS, respectively, with 50 workers. Query operations are highly efficient and likely CPU-bound. Adding more workers beyond the system’s processing capacity leads to contention for resources, reducing performance. Latency increases slightly (from 0.00 to 0.03 ms) as the number of workers grows. The rise in latency is minor, indicating that the system is still able to process queries quickly, even under higher contention. Therefore, with five workers, the system achieves the best balance between throughput and latency for query operations. Increasing workers to 25 or 50 does not improve performance and instead decreases throughput.
5.4.3. Update()
The result of the Update() function with the fixed number of workers is shown in Table 5. As TPS increases from 50 to 200, both the send rate and throughput increase significantly. However, the gap between the send rate and throughput widens slightly at higher TPS. This could indicate some resource contention or system queuing. Latency decreases significantly as TPS increases, dropping from ~1.9 ms to ~0.5 ms. Increasing txNumber (from 1000 to 5000) does not significantly affect throughput or latency, demonstrating that the system handles higher workloads consistently. At TPS = 200, the system achieves its highest throughput and lowest latency, indicating the network’s ability to handle high-frequency updates efficiently.
The result of the Update() function with the fixed number of transactions and TPS is shown in Table 6. As the number of workers increases, both the send rate and throughput improve. The improvement is linear, indicating the system can effectively handle increased concurrency latency increases slightly from 1.93 ms at 5 workers to 2.02 ms at 50 workers as the number of workers grows. This increase is minor, demonstrating that the system maintains low latency even under higher concurrency. In general, the system performs efficiently with 50 workers, achieving the highest throughput. However, latency begins to plateau, suggesting that further increases in worker count may not yield significant benefits.
5.4.4. Delete()
The result of the Delete() function with the fixed number of workers is shown in Table 7. At lower TPS, send rate and throughput are closely aligned, indicating that the system is able to handle this level of workload without issues. Also, the system processes significantly more transactions as the send rate and throughput increase sharply at higher TPS. For txNumber = 5000, the send rate reaches 146.3 TPS, and throughput is close at 137.8 TPS, indicating the system is efficiently handling high rates. At lower TPS (50 and 100), latency is higher due to lower transaction batching efficiency. At TPS = 200, latency drops significantly, indicating the system benefits from higher throughput and better resource utilization. Therefore, the total number of transactions has little impact on performance. Across all the txNumber values (1000, 2000, and 5000), the system maintains consistent throughput and latency.
The result of the Delete() function with the fixed number of transactions and TPS is shown in Table 8. As the number of workers increases, both the send rate and throughput improve. The system handles concurrency well, with throughput increasing linearly with the number of workers. Latency remains relatively stable across all the worker configurations. This suggests that the system maintains low contention for resources, even with higher concurrency. In general, increasing workers to 50 provides the highest throughput. However, the slight increase in latency indicates that the system is nearing its optimal concurrency limit.
5.4.5. High-Pressure Test
Table 9 shows the result of the performance test of high pressure. In general, all four functions were completed without any failed transactions under high pressure, indicating excellent system stability. The throughput values are close to their respective send rate values, demonstrating that the system effectively processes most of the submitted transactions within the defined duration.
First, the creation process exhibits relatively higher latency compared to the other operations. This is expected as Create() involves writing new data and updating the blockchain state, which is computationally heavier. Second, Query() achieves the highest throughput among all the operations with minimal latency, as it involves read-only operations that do not require state changes or consensus. Third, the update process is more resource-intensive than Query() but still achieves high throughput and low latency. The latency (0.61 ms) is slightly better than Create() because updates generally involve modifying the existing records rather than inserting new ones. Fourth, similarly to Update(), Delete() exhibits efficient performance with moderate latency. The throughput and latency are comparable to Update(), indicating consistent resource utilization for state-altering operations.
6. Discussion
This section evaluates the advantages and limitations of the proposed system. The term Pros refers to the system’s key strengths and benefits, such as HLF’s features, enhanced data privacy, and decentralized management. On the other hand, Cons identify potential challenges and areas where improvements are needed, such as transaction latency and system complexity. By comparing these aspects against traditional database systems, the analysis highlights the practicality and future potential of the proposed architecture.
6.1. Pros of the Proposed System
Unlike computationally intensive Proof of Work (PoW), HLF utilizes the Raft consensus protocol to provide a lightweight yet reliable mechanism to maintain the blockchain’s integrity [20]. It enables faster transaction finalization while preserving fault tolerance, making it well suited for IoV environments with high transaction volumes. By leveraging CouchDB as the state database, the system enables efficient and complex queries on chaincode data. Thanks to HLF, our system utilizes TLS for secure communications and encryption for identity management. It can make the system resistant to common cybersecurity threats. Also, access control through MSP ensures that only authenticated and authorized participants can interact with the network.
Also, the decentralized architecture of HLF is the key feature of our system. It can eliminate the need for a central authority and reduce the risk of a single point of failure. Therefore, it ensures that no single organization has any unilateral control over the data. Meanwhile, the use of blockchain ensures that all the transactions are immutable once submitted. The multi-channel structure provides logical isolation to ensure that only authorized parties have access to sensitive data. We find this feature particularly useful in use cases involving multiple departments, especially where data collaboration is required. Finally, in the central channel, Channel A, of our system, unified queries allow seamless integration and interaction between different data domains.
6.2. Cons of the Proposed System
First, during the testing phase, we find that the use of consensus protocols and cryptographic operations introduces latency, particularly under high transaction loads. This may limit the system’s applicability for ultra-low latency IoV applications, such as autonomous driving control systems. Second, setting up and maintaining a HLF network requires a significant number of operations. Updating or expanding systems can be challenging compared to conventional systems. Any changes, such as adding new participants, require careful updates to network configurations and chaincode. Third, the size of the ledger grows over time, with higher storage requirements compared to traditional databases. When the system is large enough, it may be inefficient to store large amounts of data on the chain.
6.3. Comparison with Traditional Database Systems
Traditional database systems are typically managed by a single authority or organization. Decisions about the database, such as access rights and data updates, are centralized. For blockchain, data are replicated across multiple nodes in a peer-to-peer network. Each participant holds a copy of the ledger. It can ensure data redundancy and robustness against single-point failures [22]. Traditional database system relies on user roles, passwords, and firewalls for security. A single breach in the central database can expose the entire dataset [23]. For our system, logical isolation ensures sensitive data are only accessible to authorized parties. Transactions are validated by multiple nodes, making them highly resilient to fraud or cyberattacks. As for performance, traditional database systems can have high throughput. It is optimized for speed, with support for thousands of transactions per second. It is also suitable for applications requiring immediate data updates [24]. However, blockchain systems may have transaction latency due to consensus protocols. It is optimized for trust and focuses on data integrity.
7. Conclusions
This paper presents a multi-channel HLF-based IoV system. Our system leverages the decentralized, secure, and immutable architecture of blockchain to enhance data integrity, privacy, and trust among stakeholders in the IoV.
The key contribution of the system is the multi-channel structure. The separation of data into different channels can ensure data privacy and efficient collaboration among different organizations. The use of chaincodes enables secure and automated transactions across channels. The testing phase validates successful deployment, chaincode operation, and efficient data exchange across channels. The Performance Analysis Section demonstrates the stable performance of the proposed system in different environments.
Several areas remain for further research and enhancement. In the future, first, we will focus on improving user interfaces and developer tools to simplify the interaction and deployment of blockchain-based IoV systems for stakeholders. Moreover, we desire to explore the integration of edge computing for real-time data processing at the vehicle level. It is necessary to reduce the network load and latency associated with blockchain transactions. Finally, we want to conduct extensive scalability tests under real-world scenarios to evaluate system performance with many participants and diverse data streams.
Conceptualization, Y.L., Y.F. and K.S.; methodology, Y.L. and Y.F.; software, Y.L.; validation, Y.L.; formal analysis, Y.L. and Y.F.; investigation, Y.L. and Y.F.; writing—original draft preparation, Y.L.; writing—review and editing, Y.F. and K.S.; visualization, Y.L.; supervision, Y.F. and K.S.; project administration, Y.L., Y.F. and K.S. All authors have read and agreed to the published version of the manuscript.
Data are contained within the article.
The authors declare no conflicts of interest.
Footnotes
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Performance test of Create() with the fixed number of workers.
| Create(): Fixed N. of Workers, Different txNumber and TPS | |||||
|---|---|---|---|---|---|
| N. of Workers | txNumber | TPS | Send Rate | Throughput | Avg Latency |
| 5 | 1000 | 50 | 11.5 | 11.2 | 2.07 |
| 100 | 20.2 | 19.3 | 2.01 | ||
| 200 | 111.4 | 90.5 | 0.59 | ||
| 5 | 2000 | 50 | 12.5 | 12.4 | 1.66 |
| 100 | 22.7 | 22.2 | 1.79 | ||
| 200 | 129.3 | 125.6 | 0.65 | ||
| 5 | 5000 | 50 | 12.3 | 12.2 | 1.75 |
| 100 | 27.1 | 26.8 | 1.71 | ||
| 200 | 154.8 | 147.2 | 0.56 | ||
Performance test of Query() with the fixed number of workers.
| Query(): Fixed N. of Workers, Different txNumber and TPS | |||||
|---|---|---|---|---|---|
| N. of Workers | txNumber | TPS | Send Rate | Throughput | Avg Latency |
| 5 | 1000 | 50 | 606.4 | 605.3 | 0.01 |
| 100 | 693.5 | 692.0 | 0.00 | ||
| 200 | 699.3 | 696.9 | 0.00 | ||
| 5 | 2000 | 50 | 986.2 | 985.2 | 0.00 |
| 100 | 1042.8 | 1041.1 | 0.00 | ||
| 200 | 1093.5 | 1092.3 | 0.00 | ||
| 5 | 5000 | 50 | 1484.6 | 1483.7 | 0.00 |
| 100 | 1607.2 | 1605.7 | 0.00 | ||
| 200 | 1518.4 | 1517.0 | 0.00 | ||
Performance test of Update() with the fixed number of workers.
| Update(): Fixed N. of Workers, Different txNumber and TPS | |||||
|---|---|---|---|---|---|
| N. of Workers | txNumber | TPS | Send Rate | Throughput | Avg Latency |
| 5 | 1000 | 50 | 11.4 | 11.2 | 1.97 |
| 100 | 25.4 | 25.1 | 1.64 | ||
| 200 | 128.8 | 108.7 | 0.56 | ||
| 5 | 2000 | 50 | 12.6 | 12.4 | 1.82 |
| 100 | 21.3 | 20.8 | 1.93 | ||
| 200 | 145.4 | 127.3 | 0.45 | ||
| 5 | 5000 | 50 | 13.5 | 13.4 | 1.57 |
| 100 | 27.6 | 27.3 | 1.73 | ||
| 200 | 138.2 | 130.6 | 0.52 | ||
Performance test of Delete() with the fixed number of workers.
| Delete(): Fixed N. of Workers, Different txNumber and TPS | |||||
|---|---|---|---|---|---|
| N. of Workers | txNumber | TPS | Send Rate | Throughput | Avg Latency |
| 5 | 1000 | 50 | 12.6 | 12.3 | 1.76 |
| 100 | 24.8 | 23.7 | 1.97 | ||
| 200 | 127.3 | 110.2 | 0.51 | ||
| 5 | 2000 | 50 | 11.7 | 11.5 | 1.79 |
| 100 | 27.0 | 26.4 | 1.68 | ||
| 200 | 146.0 | 137.0 | 0.56 | ||
| 5 | 5000 | 50 | 13.5 | 13.7 | 1.71 |
| 100 | 23.2 | 23.0 | 1.80 | ||
| 200 | 146.3 | 137.8 | 0.49 | ||
Performance test of high pressure.
| High Pressure with N. of Workers: 50, txDuration: 300, TPS: 400 | |||||
|---|---|---|---|---|---|
| Function | Succ | Fail | Send Rate | Throughput | Avg Latency |
| Create() | 105,167 | 0 | 361.3 | 360.7 | 0.75 |
| Query() | 1,011,725 | 0 | 3846.4 | 3486.4 | 0.06 |
| Update() | 131,422 | 0 | 451.2 | 448.0 | 0.61 |
| Delete() | 128,493 | 0 | 441.9 | 440.5 | 0.62 |
Performance test of Create() with the fixed number of transactions and TPS.
| Create(): Fixed txNumber and TPS, Different N. of Workers | |||||
|---|---|---|---|---|---|
| txNumber | TPS | N. of Workers | Send Rate | Throughput | Avg Latency |
| 2000 | 100 | 5 | 22.7 | 22.2 | 1.79 |
| 25 | 37.1 | 35.8 | 2.05 | ||
| 50 | 39.0 | 38.0 | 1.93 | ||
Performance test of Query() with the fixed number of transactions and TPS.
| Query(): Fixed txNumber and TPS, Different N. of Workers | |||||
|---|---|---|---|---|---|
| txNumber | TPS | N. of Workers | Send Rate | Throughput | Avg Latency |
| 2000 | 100 | 5 | 1042.8 | 1041.1 | 0.00 |
| 25 | 333.7 | 333.4 | 0.03 | ||
| 50 | 179.1 | 179.0 | 0.03 | ||
Performance test of Update() with the fixed number of transactions and TPS.
| Update(): Fixed txNumber and TPS, Different N. of Workers | |||||
|---|---|---|---|---|---|
| txNumber | TPS | N. of Workers | Send Rate | Throughput | Avg Latency |
| 2000 | 100 | 5 | 21.3 | 20.8 | 1.93 |
| 25 | 37.0 | 35.8 | 1.96 | ||
| 50 | 42.9 | 41.4 | 2.02 | ||
Performance test of Delete() with the fixed number of transactions and TPS.
| Delete(): Fixed txNumber and TPS, Different N. of Workers | |||||
|---|---|---|---|---|---|
| txNumber | TPS | N. of Workers | Send Rate | Throughput | Avg Latency |
| 2000 | 100 | 5 | 27.0 | 26.4 | 1.68 |
| 25 | 35.4 | 34.1 | 1.9 | ||
| 50 | 40.0 | 38.5 | 1.86 | ||
References
1. Meijers, J.; Michalopoulos, P.; Motepalli, S.; Zhang, G.; Zhang, S.; Veneris, A.; Jacobsen, H.A. Blockchain for V2X: Applications and Architectures. IEEE Open J. Veh. Technol.; 2022; 3, pp. 193-209. [DOI: https://dx.doi.org/10.1109/OJVT.2022.3172709]
2. Yeong, D.J.; Velasco-hernandez, G.; Barry, J.; Walsh, J. Sensor and sensor fusion technology in autonomous vehicles: A review. Sensors; 2021; 21, 2140. [DOI: https://dx.doi.org/10.3390/s21062140] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/33803889]
3. Ang, L.M.; Seng, K.P.; Ijemaru, G.K.; Zungeru, A.M. Deployment of IoV for Smart Cities: Applications, Architecture, and Challenges. IEEE Access; 2019; 7, pp. 6473-6492. [DOI: https://dx.doi.org/10.1109/ACCESS.2018.2887076]
4. Chen, C.; Quan, S. A Summary of Security Techniques-Based Blockchain in IoV. Secur. Commun. Netw.; 2022; 2022, 8689651. [DOI: https://dx.doi.org/10.1155/2022/8689651]
5. Hammoud, A.; Sami, H.; Mourad, A.; Otrok, H.; Mizouni, R.; Bentahar, J. AI, Blockchain, and Vehicular Edge Computing for Smart and Secure IoV: Challenges and Directions. IEEE Internet Things Mag.; 2020; 3, pp. 68-73. [DOI: https://dx.doi.org/10.1109/IOTM.0001.1900109]
6. Zheng, Z.; Xie, S.; Dai, H.; Chen, X.; Wang, H. An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends. Proceedings of the 2017 IEEE 6th International Congress on Big Data, BigData Congress 2017; Honolulu, HI, USA, 25–30 June 2017.
7. Yaga, D.; Mell, P.; Roby, N.; Scarfone, K. Blockchain Technology Overview; No. 8202 National Institute of Standards and Technology: Gaithersburg, MD, USA, 2019; pp. 1-57.
8. Mollah, M.B.; Zhao, J.; Niyato, D.; Guan, Y.L.; Yuen, C.; Sun, S.; Lam, K.Y.; Koh, L.H. Blockchain for the Internet of Vehicles towards Intelligent Transportation Systems: A Survey. IEEE Internet Things J.; 2021; 8, pp. 4157-4185. [DOI: https://dx.doi.org/10.1109/JIOT.2020.3028368]
9. Github Contributors. Hyperledger Fabric. Available online: https://github.com/hyperledger/fabric (accessed on 11 December 2024).
10. Androulaki, E.; Barger, A.; Bortnikov, V.; Muralidharan, S.; Cachin, C.; Christidis, K.; De Caro, A.; Enyeart, D.; Murthy, C.; Ferris, C. et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. Proceedings of the 13th EuroSys Conference, EuroSys 2018; Porto, Portugal, 23–26 April 2018.
11. Nasir, Q.; Qasse, I.A.; Abu Talib, M.; Nassif, A.B. Performance analysis of hyperledger fabric platforms. Secur. Commun. Netw.; 2018; 2018, 3976093. [DOI: https://dx.doi.org/10.1155/2018/3976093]
12. Foschini, L.; Gavagna, A.; Martuscelli, G.; Montanari, R. Hyperledger Fabric Blockchain: Chaincode Performance Analysis. Proceedings of the ICC 2020–2020 IEEE International Conference on Communications (ICC); Dublin, Ireland, 7–11 June 2020.
13. Pajooh, H.H.; Rashid, M.; Alam, F.; Demidenko, S. Hyperledger fabric blockchain for securing the edge internet of things. Sensors; 2021; 21, 359. [DOI: https://dx.doi.org/10.3390/s21020359] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/33430274]
14. Alalwany, E.; Mahgoub, I. Security and Trust Management in the Internet of Vehicles (IoV): Challenges and Machine Learning Solutions. Sensors; 2024; 24, 368. [DOI: https://dx.doi.org/10.3390/s24020368] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/38257461]
15. Karim, S.M.; Habbal, A.; Chaudhry, S.A.; Irshad, A. Architecture, Protocols, and Security in IoV: Taxonomy, Analysis, Challenges, and Solutions. Secur. Commun. Netw.; 2022; 2022, 113479. [DOI: https://dx.doi.org/10.1155/2022/1131479]
16. Ding, Q.; Gao, S.; Zhu, J.; Yuan, C. Permissioned Blockchain-Based Double-Layer Framework for Product Traceability System. IEEE Access; 2020; 8, pp. 6209-6225. [DOI: https://dx.doi.org/10.1109/ACCESS.2019.2962274]
17. Hussain, S.; Tahir, S.; Masood, A.; Tahir, H. Blockchain-Enabled Secure Communication Framework for Enhancing Trust and Access Control in the Internet of Vehicles (IoV). IEEE Access; 2024; 12, pp. 110992-111006. [DOI: https://dx.doi.org/10.1109/ACCESS.2024.3431279]
18. Ndzimakhwe, M.; Telukdarie, A.; Munien, I.; Vermeulen, A.; Chude-Okonkwo, U.K.; Philbin, S.P. A Framework for User-Focused Electronic Health Record System Leveraging Hyperledger Fabric. Information; 2023; 14, 51. [DOI: https://dx.doi.org/10.3390/info14010051]
19. Novo, O. Blockchain Meets IoT: An Architecture for Scalable Access Management in IoT. IEEE Internet Things J.; 2018; 5, pp. 1184-1195. [DOI: https://dx.doi.org/10.1109/JIOT.2018.2812239]
20. Huang, D.; Ma, X.; Zhang, S. Performance Analysis of the Raft Consensus Algorithm for Private Blockchains. IEEE Trans. Syst. Man. Cybern. Syst.; 2020; 50, pp. 172-181. [DOI: https://dx.doi.org/10.1109/TSMC.2019.2895471]
21. Github Contributors. Hyperledger Caliper. Available online: https://github.com/hyperledger-caliper/caliper (accessed on 16 January 2025).
22. Stephen, R.; Alex, A. A Review on BlockChain Security. IOP Conf. Ser. Mater. Sci. Eng.; 2018; 396, 012030. [DOI: https://dx.doi.org/10.1088/1757-899X/396/1/012030]
23. Muqorobin, M.; Rozaq Rais, N.A. Comparison of PHP Programming Language with Codeigniter Framework in Project CRUD. Int. J. Comput. Inf. Syst.; 2022; 3, pp. 94-98. [DOI: https://dx.doi.org/10.29040/ijcis.v3i3.77]
24. Abourezq, M.; Idrissi, A. Database-as-a-Service for Big Data: An Overview. Int. J. Adv. Comput. Sci. Appl.; 2016; 7, pp. 157-177. [DOI: https://dx.doi.org/10.14569/IJACSA.2016.070124]
© 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.
Details
; Sakurai, Kouichi 2 1 Graduate School of Information Science and Electrical Engineering, Kyushu University, Fukuoka 819-0395, Japan
2 Faculty of Information Science and Electrical Engineering, Kyushu University, Fukuoka 819-0395, Japan