An Integrated Blockchain Framework for Secure Autonomous Vehicle Communication System

Abstract

Autonomous Vehicles (AV) have been extensively studied in both scientific and social contexts. Over the past two decades, there has been a significant rise in their real-world applications, including neural networks, Blockchain, Internet of Things, autonomous navigation, computer vision, automation processes, and various other areas. Hence, it is imperative to investigate the interplay between software, hardware, and individuals. To guarantee secure and unaffected interactions within autonomous vehicle devices and networks, decentralized Blockchain technology is proposed. This study presents the introduction of a framework we named “DEMU-NAV” for an ecosystem that includes Artificial Intelligence (AI), humans, and robots. The framework makes use of a decentralized Blockchain, Smart-Contract (SC), and Internet of things (IoT) network. Our framework was implemented using Ethereum and Python, enabling us to oversee Blockchain, Smart-Contracts, and the IoT for the facilitation of autonomous vehicle navigation.

1. Introduction

Historically, Autonomous Vehicles (AV) have been a motivating idea in the socioscientific community, highlighting advances of the twentieth century, such as automated line following, computer vision, and Artificial Neural Networks, among other factors [1,2]. However, the present 21st century has managed to crystallize tangible AV. In a practical definition, an autonomous vehicle is a transportation system equipped with sensors and cameras in contact with its environment and an Artificial Intelligence (AI) processing unit [3,4]; for example, the technologies proposed by Google and Tesla have the elements mentioned above.

Today, AVs can navigate in controlled laboratory environments and limited experimental routes [5,6]; this raises the question: How does a human driver interact with an Artificial Intelligence or an AI with another AI? The answer takes different aspects, such as having intelligent vehicles that can communicate and translate information between a human navigation system and artificial intelligence, as well as vehicle design with the ability to transfer data over the Internet, among other features [7].

On the other hand, in a scenario where the autonomous vehicle interacts in a navigation network with other entities of roles such as pedestrians, cyclists, drivers, or navigation authority. It poses different challenges, which are: how to generate a tracking network where the exchanged information is free from hacking. Besides, there are different levels of access of public and private elements; adaptation to the growth of new elements; encrypted security systems to prevent hacking of the network. In response to the above requirements, research has proposed the incursion and adaptation of the decentralized Blockchain network in autonomous systems [8].

The Blockchain was initially a peer-to-peer transaction registration system for cryptocurrency exchange, which defines a decentralized ledger with encryption security; today, research uses the Blockchain as a solution to the problem of autonomous vehicle interaction where each vehicle is a node of the decentralized network [9]. Consequently, the interaction between vehicles and Blockchain attracts different benefits: vehicle anti-hacking cybersecurity, self-adaptation in the face of the growth of new elements; information exchange avoiding centralized bottlenecks; among others [10,11]. However, Blockchain limits its potential to the registration of secure transactions between AV and different actors on the network—leaving open the problem of public and private privileges of peer-to-peer contracts.

In the context of autonomous communication of human vehicles, there are different levels of privileges, as shown in Figure 1:

• The first level of authorization is where the human controls and enables the Artificial Intelligence of the autonomous vehicle.
• The second level describes the scenario where information exchange occurs between the AV and the navigation authority.
• The third level belongs to the cases involving collaboration and conflict resolution between navigating vehicles in the Blockchain network.

Figure 1. Model of communication and collaboration between users, IA, Humans and Blockchain.

Figure 1. Model of communication and collaboration between users, IA, Humans and Blockchain.

In comparison, in primary communication, the human is the direct authority of the vehicle; the responsible party has access to all information in the system (see Figure 1 First Level), while at the secondary level, the navigation authority only requests relevant information to carry out that purpose (see Figure 1 Second Level). Ultimately, as illustrated in Figure 1 at the third level, all network participants share public information and do not require human verification. Therefore, the above argument suggests the need for a level system that records or allows access to information following specific transaction protocols.

A framework called “DEMU-NAV” is introduced that combines a Blockchain network, Smart-Contract, and the Internet of Things (IoT) for autonomous navigation. The framework encompasses the following software contributions:

• The Blockchain network is dedicated to the research and technological development of AV in navigation.
• Decentralized network communication clients powered by IoT technologies and communication with Smart-Contracts.
• Smart-Contracts designed for autonomous navigation considering public and private privileges requested for an autonomous vehicle in a decentralized network.

The rest of this work is organized as follows. The description of the framework is given in Section 2, the description of the software in Section 3, and illustrative examples in Section 4. The impact description of our software is shown in Section 5, and the conclusions are reported in Section 6.

2. Proposed Framework

2.1. Related Work

Biswas and Wang [8] presents a detailed examination of the current literature on how these technologies affect and are implemented in AV architectures, as well as the various challenges they face. In addition, they offer perspectives on technological developments for their smooth integration to satisfy AV requirements. Lastly, the document highlights potential avenues for research and opportunities that could drive further progress. Examines the blending of pivotal enabling technologies within a unified study. From Bendiab et al. [12], they investigated potential opportunities for combining Blockchain and AI technologies to fortify the security of AVs.Initially, they presented a categorization of the security and privacy risks that could emerge with the use of AV technologies. Next, we provide an overview of recent studies on the use of Blockchain and AI to improve the security of AVs. Lastly, they point out the limitations and challenges that could arise when merging Blockchain and AI with AVs according to our systematic review, and propose possible future research directions in this area.

Liang et al. [13] examine the complex traffic scenarios that pose a challenge to the collaborative management of connected and automated vehicles (CAVs).A control architecture employing a multiagent system (MAS) is introduced, incorporating a hierarchical controller to help manage the cooperative control system for CAVs. The upper tier evaluates potential states of a CAV during platoon formation, including cruising and following actions, and outlines the transition criteria for distinct maneuvering behaviors. The foundational layer combines the specific motion controllers for each CAV. By employing a blend of the artificial potential field (APF) with the distributed model predictive control algorithm, this layer ensures synchronized management of longitudinal, lateral, and yaw motions in CAVs. Inspired by the Pareto-optimal method for tackling MAS-cooperation challenges, an optimal strategy is introduced to solve the CAVs cooperation problem by applying control theory principles.

In addition, multiple constraints are implemented to maintain a safe distance between connected and autonomous vehicles (CAVs), while also ensuring vehicle stability. The results of the simulation reveal that the hierarchical control structure using MAS can proficiently manage the cooperation control of the CAV in the absence of standard traffic scenarios. The successful real-time application of the proposed controller further demonstrates its practicality.

In recent years, research on autonomous vehicles (AV) has made substantial progress. Anushka Biswas et al. [8] have focused on the use of Blockchain technology to improve traffic safety and efficiency. Meanwhile, Emmanuel Ekene Okere et al. [14] have investigated the combination of machine learning and Blockchain to develop intelligent transportation systems. On the other hand, Stefan Iordache et al. [15] have presented a proposal to use Blockchain and AI-based predictive algorithms to facilitate communication between AV and the city infrastructure.

In contrast, our work (your abstract) stands out for presenting a framework we call ‘DEMU-NAV’ that contemplates artificial intelligence, humans, and robots in an ecosystem and uses Blockchain technology, Smart-Contracts, and an IoT network to facilitate navigation of AV, because previous research has given the foundation for integration of AV, but without considering the interactions between AI agents, humans, and government entities.

A further highlight of our research, compared to previous work, is the incorporation of agents interacting with AV using LoRa technology (long range), which enables efficient and secure communication in low-infrastructure environments. This represents a significant advance in the field, as most previous work has focused on utilizing technologies such as Wi-Fi or 5G for communication between AV. In contrast, our proposal offers a more accessible and scalable solution for rural environments or areas with infrastructure limitations.

2.2. DEMU-NAV Framework

Figure 1 illustrates the overall concept of the proposed framework. It shows a scenario with different actors: a set of AVs that emit and receive signals from their environment; a vehicle owner with decision-making authority and responsibility; a navigation authority who regulates vehicle traffic laws in general; and finally, a set of entities (e.g., Hospital) interacting with the vehicle. Consequently, all actors together generate a network of information exchange.

The suggested approach involves treating the autonomous vehicle navigation network as a decentralized network. In this network, the Blockchain is utilized to record all interactions between its members while adhering to our information protection level model. To provide an example, Figure 2 presents an illustrative diagram of a Blockchain scenario, highlighting the key components and their interactions. In another scenario, we present four different agents: (A) the autonomous vehicle, (B) the vehicle owner, (C) human agents acting as authorities, and (D) public agents (other autonomous vehicles, and public buildings). The agents in the scenario interact with the rest of the agents both public and private through transactions exchanged by Smart-Contracts (E), which are recorded in the Blockchain in real time.

Autonomous navigation scenario in a decentralized network. The vehicle has three interactions: the first, the legal responsible makes a request; then the protection level is private, but it must be recorded in the network; the second, the vehicle communicates information to the navigation authority or the proxy communicates it, in both cases it is also private; third, the vehicle communicates nonprivate information to other elements of the network (hospital, another vehicle). Consequently, the information record is public.

To automatically address the registration of interactions in the Blockchain network, the concept of Smart-Contract Self-Driving is presented, which allows generating secure transactions between stakeholders, without intermediaries that can corrupt the network, as well as communication between Artificial Intelligence and humans, without the need to explain the behavior of the AI, since humans wrote the contracts and the AI obeys their orders.

3. Materials and Methods

Examine the functionality of Smart-Contracts, vehicles, and other actors carefully; it is necessary to develop a framework that lets us describe the interaction between them. Therefore, the DEMU-NAV library was designed to be compatible with Blockchain, IoT elements, and high-level language programming. Consequently, a framework is developed that has the ability to replicate a minimum of three scenarios, according to the generality levels outlined in Figure 1. In Section 4, a scenario is provided for each level, presenting the process sequentially.

3.1. Software Architecture

Hong-Ning et al. [16] proposed a model in which the convergence between Blockchain and IoT was made in four layers: Perception, communication, Blockchain-composite, and Industrial applications.

Using a Blockchain-IoT (BCIoT) architecture to model the software, which allows us to guarantee support to the final users, such as AV in the IoT environment.

Our software consists of four layers in Figure 3 (from bottom to top):

• Perception Layer: This layer collects data from all IoT devices, such as sensors, computers, cameras, robots, mobile devices, and others. The current layer involves an independent vehicle that is capable of identifying other vehicles, traffic lights, and various objects on the road. The following sections present examples that illustrate the interaction between the elements of this layer and the layers above.
• Communication Layer: Such as in the OSI (Open Systems Interconnection) Model, the third layer contains network devices that aim to decide the physical paths the data will take. The communication layer is similar to the OSI’s Network-Layer in charge of managing the information from mobile devices. In this case, communication can be managed by LoRa, WiFi AP, IoT gateway, and routers.
• Blockchain Composite layer: The Blockchain layer is the most important part due to its complexity and functionality. According to the BCIoT model, this layer has five sub-layers that allow data storage; the network layer is the propagation and verification mechanism; the consensus layer is the incentive layer to make the transactions and reward; and finally, the Service layer with Smart-Contracts.
• Industrial Applications: Only one industrial application was presented, but our software could support other problems such as manufacturing, Supply chain, food Industry, smart grid, and health care.

Figure 3. Blockchain and IoT convergence Diagram.

Figure 3. Blockchain and IoT convergence Diagram.

3.2. Internet of Things

The Internet of Things (IoT) was possible due to advances in technology and software development. This terminology involves the connection and communication of any electronic element over the Internet [17,18]. On the market, devices designed specifically for IoT in health, industry, or home security applications are found [19,20].

The primary way these devices communicate is wireless. In this field, LoRa is used as a technology that sends and receives data on a free communication band at a low rate and distances greater than one mile without obstacles [21,22]. Due to low power consumption, LoRa is used to monitor parameters in smart cities and rural areas, positioning it as an excellent protocol to communicate with autonomous robots in any sector [23,24,25,26].

The Internet of Robotics Things (IoRT) concept involves robotics knowledge and Internet of Things topics, but this does not mean robots; these devices are connected and controlled through the Internet. The concept of IoRT describes its interaction; however, there is a minor controversy about security issues in the communication process [27,28]. On the other hand, an emerging tool named Blockchain is used, which allows robot interactions to be done safely [29]. Using the Blockchain paradigm, it can be developed to develop groups of robots with essential characteristics such as interaction and communication through Smart-Contracts [30].

3.3. Blockchain

The starting point of the Blockchain began in 2008 when Satoshi Nakamoto presented the concept to the world. Nakamoto justified his innovation on the need for a transaction system free from central regulation but keeping transactions incorruptible; based on the Nakamoto concept, the first cryptocurrency (Bitcoin) was born. Consequently, Bitcoin triggers a set of decentralized rules and concepts, highlighting examples such as crypto-signatures, cryptocurrency mining, and decentralized transaction logging.

From another perspective, the limitations present in Nakamoto’s concept generated a second and third generation of Blockchain: the second generation of Blockchain aims to improve aspects such as the crypto-security of transactions, some of which were to the extreme of being anonymous. The third evolution was based on the creation of public or private network concepts; however, the most important idea was the generation of Smart-Contracts, which opened the door to multiple applications because Smart-Contracts include elements other than cryptocurrencies.

The Blockchain concept is currently undergoing its fourth evolution, which is attributed to the introduction of Smart-Contracts. These contracts allow stakeholders to engage in transactions that involve any significant object. In this context, stakeholders are defined as entities that possess an account and a cryptographic signature on the Blockchain. Blockchain 4.0 flourishes here because stakeholders can be humans, Artificial Intelligence, robots, and anything that can exchange information with other elements. In the following Section, the attention is directed towards explaining the essential components of the Blockchain that have an effect on an autonomous navigation ecosystem. Additionally, we highlight the importance of Smart-Contracts in facilitating transactions between parties.

3.3.1. Self-Driving Blockchain

The main objective of the research is to propose a framework for autonomous vehicle navigation in smart city environments (DEMU-NAV). The fundamental elements of DEMU-NAV lie in the integration of blockchain, Smart contracts, and IoT technology gathered in Open-source software, which allows researchers in the autonomous vehicle sector a starting point in IoT information security. This framework combines key software contributions, including a Blockchain network dedicated to autonomous vehicle research and technology development in navigation, which is characterized by its ability to provide a decentralized and immutable record of navigation data; decentralized network communication clients powered by IoT technologies, such as LoRa, which enable interconnection and information exchange between vehicles and infrastructure; and Smart-Contracts designed specifically for autonomous navigation, which consider both public and private privileges requested for an autonomous vehicle in a decentralized network, by implementing consensus algorithms and secure communication protocols.

In principle, we will analyze the needs demanded by the self-driving Blockchain: First, the navigation network invokes a regulatory authority; then the Self-Driving Blockchain coincides with the concept of permissioned Blockchain. Second, the network has a private character, as it must protect the information of its transactions. Third, according to its environmental characteristics, the network must be open or closed; for example, in an industrial environment, it will be closed, while in city navigation it will be open. Fourth, the existence of different accounts in the protection levels, which coincide with the structure of the levels presented in Figure 1.

3.3.2. Self-Driving Permissioned Blockchain

The authority controls and generates the initial characteristics of the Blockchain; in technical terms, the Genesis Blockchain, which has the levels of mining complexity, a set of administrative accounts, transaction controllers, accounts corresponding to administrators with a permission value, which means by the permission value the amount allowed to grant transactions. On the other hand, the Self-Driving Blockchain contains the wallets of the members of the assigned network and their cryptocurrencies (see Figure 4).

3.3.3. Crypto-Security

The main elements are to protect the exchange of information from level 2 to level 3 (see Figure 4) since these levels contain data from the private and administrative domain, in contrast to the public domain; consequently, mining must be dynamic considering the level of complexity at a minimum in the public domain and high in transactions of level 2 and 3. Therefore, the navigation authority will build the genesis block, thus defining the dynamic degree of mining by streamlining the network transaction records.

DEMU-NAV is a framework that contains its cryptosecurity structure in the Elliptic Curve Digital Signature models [31], which are characterized by defining a finite field ${\mathbb{F}}_p$ known in the literature as the prime field, where p represents a prime number, which defines the space of integers $\{1,2,\dots ,p-1\}$. Consequently, let $p>3$ be a prime number characterized by an elliptic curve $\mathbb{E}$ in the finite prime space (${\mathbb{F}}_p$), described by

$$y^2=(x^3+a·x+b),$$

(1)

where $a,b$ are elements of the set of the finite prime space, considering the property of (2),

$$4a^3+27b^2\not\equiv 0modp.$$

(2)

In the elements of $\mathbb{F}$ that match a given p, for example, consider $p=7$ determined by a finite space ${\mathbb{F}}_7:\{0,1,2,3,3,4,5,6\}$, then one possibility is to determine $a=1$, $b=2$ and evaluate (2), resulting in $4+3=0mod7$; concluding that due to the property of (2), a and b are not elements of a nonsingular elliptic curve, which implies determining all elements a and b that satisfy (2) and guarantee cryptographic security for DEMU-NAV.

The model presented in (1) and (2) allows us to guarantee the generation of cryptographic signatures with a high degree of complexity in order not to be hacked. In the context of DEMU-NAV, these signatures are divided into two main parts: the private part, which belongs to the personal systems of both authority and navigation or transport, as well as to the users. This kind of private security signature allows peer-to-peer transactions with direct authentication by users; in particular, the prime values used are of the order of 192 to 224 bits, which covers the spectrum of basic, where the signature security is minimal as public information exchange, and the highest threshold corresponds to an acceptable minimum for private signatures guaranteeing limited hardware and energy consumption.

3.3.4. Self-Driving Net Authentication

The members of the Self-Driving network contain different human actors. First, the navigation control authority, which has an organizational representative; second, legal proxies of the AV; third, human contact or interaction members, e.g., hospital representatives, school principals, among others. Consequently, we have described human-to-human interaction actors, which represent our current world. In another scenario, Autonomous Vehicle Artificial Intelligence (Autonomous-IA) represents a new paradigm in navigation systems; it needs inclusion, as it generates different combinations of Human—Autonomous-IA, Autonomous-IA—Autonomous-IA, and Autonomous-IA—Authority. Therefore, DEMU-NAV generates a set of accounts considering the different roles, such as Authority, Legal Proxy, Contact Member, and Autonomous-IA, each with different cryptosignatures.

The dashed arrows illustrate a higher hierarchical level. The solid arrows illustrate lower hierarchical levels. Up to this point, we have addressed the structure of a Self-Driving Blockchain; however, we have limited ourselves to describing one of the particular aspects of DEMU-NAV, which is the Smart-Contract, where this concept evolves the contract to a digital environment that includes Artificial Intelligence as a member of the transaction. In Section 3.3.5, we address the importance of Smart-Contracts and the elements that impact the environment of the AI-controlled vehicle.

3.3.5. Smart-Contract

Smart-Contracts were defined from the third evolution of the Blockchain concept as a mediator between peers that generate transactions beyond cryptocurrencies; for example, votes in an election campaign and intellectual property registration. However, the importance of Smart-Contracts in Self-Driving Blockchain flourishes in its upper layer feature, which allows Smart-Contracts to be the ones that supervise transactions between interested parties, safeguarding the integrity of the contract and eliminating hacking in exchanges.

One of the properties of Smart-Contracts is their inheritance from peer-to-peer contracts but evolving to a digital environment inclusive of nonhuman entities; for example, Artificial Intelligence. Compared to classical contracts, Smart-Contracts communicate information in a secure digital environment without the constraint of written interpretation or human-only drafting. Therefore, a revolution arises in the Human-AI interaction since the AI must have a cryptosignature granted by its legal proxy when exchanging classified information.

Self-Driving Smart-Contract: Following the framework shown in Figure 1, Smart-Contracts allow one to adapt the concept of three levels of interaction. Public approach, Smart-Contracts have public functions that do not generate transaction costs and are free for consultation if an instruction allows access to the information, see Scenario 1. Private, both levels and level 3 need authentication; then there is a set of instructions that are private and need a cryptosignature to interact with the Blockchain, generating a block in the chain, see Scenarios 2 and 3. Hybrid, in practice, the contracts will have a public and private interaction approach. Consequently, sometimes they generate a crypto-signature or not according to the needs, see Scenarios 1 and 2.

3.3.6. Software Functionalities

To understand the interaction between different actors such as authority navigation, autonomous vehicles, humans, and Blockchain, it is necessary to have a framework that lets us see and manipulate the interaction through them. The software structure of the DEMU-NAV library is shown in Figure 4. The library consists of five packages:

• Smart-Contracts. This package contains modules and functions to manipulate and create Smart-Contracts. This folder contains five files,
  IIoT.abi,
  IIoT.sol,
  IIoT_hash_Blockchain.txt,
  IIoT_sol_IIoT_Register.abi and
  IIoT_sol_IIoT_Register.bin
• Client. This package contains three archives (app.js, package-lock.json, and pacakage.json) and one package with all classes, and for this work we call “nodes,” which manage the Block-Chase and Smart-Contracts. Some examples of these nodes are parses, content-disposition, cookies, crypto-js, media-describers, general methods, among others.
• Self-Driving Permissioned Blockchain. This package contains two packages, geth and keystore, which allows it to be manipulated through different classes such as transactions, nodes, and metadata, among others.
• IoT-Client. This folder contains one package and two classes codified in Python. These classes let us manipulate the IoT element with Python.

3.3.7. Installation

The package is coded in Python 3.8, Solidity and Ethereum core [32], and DEMU-NAV can be used on multiple platforms and operating systems. DEMU-NAV can be downloaded by cloning the source code directly from GitHub, https://github.com/juandeanda/DEMU-NAV/ (accessed on 22 June 2025). Codes 1 and 2 show the instructions for installing the library and ensuring the functionality of the library. This can be installed by executing the setup script in the root or any other directory. After installation, all functions and classes can be used in the DEMU-NAV library. In the online documentation, complex examples are documented that can help to understand the functionality and potential of our library.

• Code 1. DEMU-NAV repository link available for download.

• Code 2. DEMU-NAV installation and implementation.

4. Numerical Results and Simulations

4.1. Experimental Results

To determine the most suitable cryptographic elliptic curve for implementation within the DEMU-NAV algorithm, we designed a set of experiments that compare the most prominent cryptographic elements in the literature, including ECDSA-secp256r1, ECDSA-secp521r1, ECDSA-secp384r1 and Ed25519. In particular, we focus on cryptographic algorithms based on elliptic curves, as described in Section 3.3.3, from both classical and modern perspectives to evaluate their efficiency in terms of response time, signature authenticity verification, and memory consumption.

The experiment involved a statistical comparison of average response times for signature and verification to identify the most efficient algorithm in this context of response speed. Considering that the requests per unit time in a standard autonomous vehicle navigation system will be very high, it is crucial to select a fast algorithm to handle all requests, especially during peak hours or in areas with high traffic density. Therefore, our evaluation focuses on identifying the cryptographic algorithm based on elliptic curves that offers the best trade-off between security and efficiency in autonomous vehicle environments.

Table 1. Comparison of Cryptographic Algorithms for 10,000 requests: units for time values are in [s], while memory usage estimates are in [KB].

Algorithm	Time Signature	Time Verification	Total Time	Memory
ECDSA-secp256r1	4.29 × 10−5	7.41 × 10−5	1.17 × 10−4	1.20 × 10−2
Ed25519	4.84 × 10−5	1.17 × 10−4	1.65 × 10−4	0.00
ECDSA-secp521r1	2.70 × 10−4	4.76 × 10−4	7.46 × 10−4	0.00
ECDSA-secp384r1	7.40 × 10−4	6.28 × 10−4	1.37 × 10−3	0.00

presents the experimental results for the cryptographic algorithms mentioned above. These were evaluated using 10,000 signature and verification requests. The results indicate that the algorithm type ECDSA-secp256r1 shows the highest average time consumption in evaluation and verification, as well as the highest memory consumption for processing graphs. However, the Ed25519 algorithm shows a slight improvement compared to the Ed25519 y ECDSA-secp521r1 algorithm, although its average value remains higher. In contrast, the algorithm ECDSA-secp521r1 presents an optimal trade-off between signature verification and cryptographic signature creation. It should be noted that the VE algorithm, recently designed to enhance stability in cryptographic processes, exhibits a very similar performance to the ECDSA-secp521r1 algorithm. Overall, our results suggest that algorithm ECDSA-secp521r1 strikes a good balance between security and efficiency in terms of both time and memory.

Figure 5 shows a comparison of cryptographic performance for signature generation and verification. The results show that algorithms A and D perform the best, as they present an optimal balance in terms of signature generation and verification. This makes them ideal candidates for use in our implementation and they match the elements described in Section 3.3.3.

Finally, from the results obtained, we have decided to use Algorithm A due to its simplicity and technical standard of configuration. On the other hand, algorithms B and C present higher computational costs in terms of verification and signature generation time, which makes them less suitable for our implementation, especially considering the high demand for signature generation and signature verification in optimal navigation. Consequently, we have decided not to use these algorithms in our work and instead use Algorithm A as the primary option and Algorithm D as a secondary alternative due to its good performance and stability. This will enable us to proceed with our implementation and experimentation efficiently.

4.2. Implementation of DEMU-NAV

We present a set of three scenarios for the development of communication in autonomous navigation, focusing on three levels of communication: the first level interacts with the Blockchain, which offers insights into the system’s status and signals the commencement of navigation (see Scenario 1). The second level shows a scenario where there are different actors, such as the owner, the navigation authority, and other vehicles that need to interact with the vehicle in a private and public way (see Scenario 2). Finally, the third level shows one scenario in which the vehicle navigates in open environments and communicates its telemetry status using IoT technologies for remote logging (see Scenario 3).

We start by making a connection between the autonomous vehicle and the Blockchain using the command in Code 3:

• Code 3. First connection with the Blockchain and autonomous vehicle.

Once the autonomous vehicle has been connected to the system, it will have to generate a response verification with the general decentralized navigation network, which will allow it to initiate the route. Consequently, in Code 4, we have designed a Smart-Contract, which is placed as a first-level interaction (see Figure 1). Please note that at this level it does not require a direct signature and an authorization registration of access.

• Code 4. Smart contract for verification of connection to the decentralized navigation network.

The main function (i.e., Connection()) does the connection to the decentralized navigation network, in which the autonomous vehicle makes a public request from a Smart-Contract Index, called the Application Binary Interface (ABI), that allows communication with the Blockchain. Code 5 represents the resulting structure after the compilation of Code 4, the autonomous vehicle client has to indicate the references of inputs and outputs.

• Code 5. Compilation result of Code 4, which is configured for the Application Binary Interface (ABI) standard.

Continuing the communication request of Codes 4 and 5, the autonomous vehicle contains the client that addresses the Blockchain, where the Smart-Contract was mined (see Code 6, Instruction 1), pointing out that each contract is mined and registered on the network. This is the distinctive anti-hacking factor. The contract address is a hexadecimal character string; the system encrypts it in the network and allows us to interact with the Smart-Contract.

• Code 6. The first instruction attaches the smart contract address of Code 4. The second instruction invokes the public function connecting the smart contract to the Blockchain net.

In the second instruction of Code 6, the autonomous vehicle invokes the Smart-Contract function generating the result: “Connection true”, ending the basic communication cycle of the vehicle. This concludes the Scenario 1, where a connection at level 1 is described. The focus is to interact with the decentralized navigation network without the need to extract the result, giving agility to the initial autonomous navigation cycles. In the following example, we will detail the interactions between different levels in DEMU-NAV.

The scenario starts from the description of the Smart-Contract Code 7. The code considers all levels of interaction.

• First level: the vehicle consults the permissions granted in previous states with Function Navigation() (lines 24 to 30). The function grants the navigation permission or declines it depending on if its owner or the navigation authority.
• Second level: In function set_owner_status() (lines 18 to 20), the vehicle’s legal proxy grants the permission to navigate, pointing out that any change implies a record in the Blockchain.
• Third level: the navigation authority publishes in the decentralized network the navigation status of the vehicle with Function set_authority_system() (lines 21 to 23).
• Finally, in Function set_Navigation_emergency() (lines 31 to 39), the contract allows a navigation exception, provided by legal proxy requests based on an emergency, which will have an obligation to register in the network and present a witness (e.g., the legal representative of the hospital).

• Code 7. Smart contract for navigation depending on the system’s status, legal proxy, and control authority.

After mining the contract and the result of the .abi file. Code 8 presents an example in which the client invokes that contract and prepares the communication with the Blockchain (for practicality, we have omitted the rest of the client code; however, client_example2.py contains all the information, Consult in the Github repository).

• Code 8. Loading contract’s index in .abi format for autonomous vehicle interaction.

As an example of navigation monitoring (First-Level interaction) where the legal proxy has been uploaded. The Code 9 requests the navigation status. The result of this request is False because, by default, the vehicle needs the authorization of its legal proxy. Here, Blockchain and Smart-Contracts begin to highlight their importance. To capture or steal the autonomous vehicle, they need the cryptosignature of its legal proxy and other authorities. Therefore, it protects and generates trust in AI paradigms.

• Code 9. Navigation status request of the autonomous vehicle.

A Second level interaction could be one where the legal proxy grants navigation permission (see Code 10). Since the autonomous vehicle has received a movement instruction, it must be registered in the decentralized network. Consequently, the registration generates a transaction that must be crypto-signed by the person in charge of the vehicle and subsequently creates a mining process to save the status in the network.

• Code 10. Request for navigation dictated by the legal proxy.

As a third-level interaction, the navigation authority (see Code 11), e.g., traffic controllers or police system, grants permission (true); after reviewing its history of violations or current policies. Like Code 10, the navigation authority records its vote in the decentralized network with its corresponding cryptosignature. At this point, we highlight the importance of a Blockchain-Smart-Contract system that streamlines authorization process.

• Code 11. Navigation authorization by regulatory or governmental authority.

Finally, the last interaction, the authorization cycle ends when the autonomous vehicle again requests information about navigation status (see Code 12). Since the responsible entities have granted the permission, the request result is positive. The vehicle can begin the journey designated by its legal proxy.

• Code 12. Authorization of navigation by the legal representative of the vehicle and the traffic controller.

From another perspective, we analyze a case where the legal representative of the autonomous vehicle needs to navigate, and the authority denies him free transit by infraction or another case. Then the vehicle cannot attend to its owner’s request; consequently, the above scenario raises the question: In what situation should the autonomous vehicle attend to its owner’s request?. A possible answer lies in a priority medical emergency. Therefore, the Smart-Contract must contain a hospital legal witness that corroborates the need for attention to the emergency (see Code 13).

• Code 13. Case of omission of navigation restriction in the event of a legal proxy emergency.

In summary, we have presented a set of interactions of the autonomous vehicle with information authorizations and navigation levels. We highlight the importance of the Smart-Contract since it allows an atmosphere of information exchange in the decentralized system that takes care of the non-hacking or capture of the autonomous vehicle. In addition to the above, the Smart-Contract allows efficient communication between human beings and automated systems.

Figure 6 shows a scenario of autonomous vehicle navigation that exchanges information in an open environment, which has two types of possible systems: First, the vehicle interacts locally with other objects in the first level; then there is no need for registration on the Blockchain (The term “non-registration” refers to a scenario where agents do not define a contract for the exchange of information, emphasizing that they only provide public elements); second, the Self-Driving registers information in the Blockchain collected during its navigation (e.g., telemetry, events of interest to the navigation authorities or its legal proxy).

To achieve navigation logging in an open environment, we propose to use a coverage network in the LoRa coverage; where the autonomous system locates the nearest LoRa antenna; antennas can be placed at strategic points such as hospitals, government centers, traffic lights, among others. Consequently, Code 14 describes the client’s information exchange in the LoRa communication standard that records data on a Blockchain network and interacts with Smart-Contracts (see Code 15).

• Code 14. Receiving antenna client in LoRa technology standard and information recording in the Blockchain.

• Code 15. Example of information registration in smart contract and IoT interaction.

5. Discussions

Alanazi [33] deals with the topic of Blockchain and how it could influence the transportation industry, specifically focusing on Intelligent Transportation Systems (ITS). Blockchain technology stands out as a significant mechanism for addressing obstacles like security, privacy, and interoperability issues, while also enhancing the effectiveness and security of Intelligent Transportation Systems (ITS), despite potential hurdles. This systematic review (SLR) literature review examines 60 articles to investigate both the possible uses and the recognized advantages of incorporating Blockchain technology into ITS. Blockchain’s potential to transform the transportation framework in smart cities is emphasized in this study.

Rakhmanov and Wiseman [34] also discusses the use of data compression techniques to effectively communicate GNSS data to autonomous vehicles and infrastructure such as satellites, ensuring optimal precision and effectiveness.They devised a technique to reduce the size of the NMEA data. Moreover, our findings surpassed those of other contemporary research while maintaining error tolerance and the ability to omit data.

The application of Artificial Intelligence in real-life problems is an ongoing research field; each day more and more applications and validations are being studied. Following this framework, not only mobile devices, sensors and IoT agents will be connected to the Internet in the future, but also machines, vehicles, trucks, trains, houses and buildings. Therefore, the information to be managed will be a vast set of requests and records, which can pose a significant challenge for existing databases to handle and manage. The entities involved in intelligence-supported environments range from sensors, humans, AV, intelligent units (any independent object), hospitals, offices, and police stations.

New technologies are changing the way we perceive things; now we have advanced vehicles with cameras and sensors to avoid colliding with objects. The trend is clear; we are increasingly approaching fully AV; however, there are still some doubts about their safety, especially on roads and urban areas. Integrating IoT, AV and Blockchain can allow navigation and interaction with the environment to be safer [35,36]. However, the information managed and administered by Artificial Intelligence must be supervised by different human administrators. In other words, to prevent conflicts of interest among users of the AI-Managed Network, it is necessary to define different roles and levels of accessibility. To provide a solution to this issue, we propose software that allows the use of existing tools such as Blockchain, IoT, and other components.This paper outlines a scenario where these technologies are integrated. An autonomous vehicle sends data to a central node via LoRa transceivers, which in turn records the information in a Smart-Contract mounted on a Blockchain. The application described in this research can be scaled to more complex systems where it interacts with other AVs, and because of the use of long-range transceivers, a larger area can be covered without losing communication.

A limitation of this system is the distance covered by the LoRa devices; in this case, our modules can receive data between two transceivers until 400 m with obstacles in the way; however, if we use antennas with more gain and without obstacles, distances until 1 km at 915 MHz frequency can be reached. Battery energy is another limitation, but sleep mode can be programmed to save energy. Future works will involve the use of this framework in collaborative robotics. Due to the development of new devices with more capabilities, we are planning to use the Jetson Nano development board and high gain antennas for LoRa transceivers, which can help to improve data processing at high speed and more coverage, respectively.

6. Conclusions

We have presented a framework for autonomous vehicle navigation in a decentralized Blockchain-IoT network system mediated by Smart-Contracts, which allows the inclusion of artificial intelligence in the autonomous navigation process in both closed and open environments. The main contribution lies in maintaining the levels of information security. A highlight is that Smart-Contracts and Blockchain that interact with AV in the different scenarios presented in Section 4 align with the current needs and demands of Explainable Artificial Intelligence (XAI, [37]), providing an additional layer of transparency, automation, security, and flexibility in the implementation of AI models [38,39]. In this context, the concept of explainable is justified, since the interaction with smart contracts allows human agents, both owner and human authority, to more clearly interact with autonomous agents exchanging information in a secure manner, without explaining technical elements of the operation of artificial intelligence when requesting or exchanging information.

Section 2 presented the conceptualization of an autonomous navigation system configured with three levels of Self-Driving interaction. Consequently, in Section 3, we address the integration of the model of Section 2 into decentralized Blockchain, IoT network structures, and coin the term Smart-Contract Self-Driving. Finally, Section 4 shows three case studies in which the autonomous vehicle interacts and communicates information to its environment using Smart-Contracts. In those scenarios, DEMU-NAV allows secure information communication, highlighting that Smart-Contract provides an alternative to the concept of explainable Artificial Intelligence without altering the algorithmic behavior of AI.

The Defense Advanced Research Projects Agency (DARPA) hosts one of the crucial competitions for autonomous robots, the most prominent research organization of the US Department of Defense. DARPA challenge has played an important role in advancing the development of robots and AV. This competition has spurred innovation in various categories and has led to the creation of advanced humanoid robots. These robots are now being utilized in the food and packaging services of multinational companies. The technological advance in hardware and software has allowed the interaction of robots with humans in a collaborative environment, and the application of the Blockchain paradigm offers a safety environment for AV governed by the direction of a human.