Blockchain-Enabled Self-Autonomous Intelligent Transport System for Drone Task Workflow in Edge Cloud Networks

Abstract

In recent years, self-autonomous intelligent transportation applications such as drones and autonomous vehicles have seen rapid development and deployment across various countries. Within the domain of artificial intelligence, self-autonomous agents are defined as software entities capable of independently operating drones in an intelligent transport system (ITS) without human intervention. The integration of these agents into autonomous vehicles and their deployment across distributed cloud networks have increased significantly. These systems, which include drones, ground vehicles, and aircraft, are used to perform a wide range of tasks such as delivering passengers and packages within defined operational boundaries. Despite their growing utility, practical implementations face significant challenges stemming from the heterogeneity of network resources, as well as persistent issues related to security, privacy, and processing costs. To overcome these challenges, this study proposes a novel blockchain-enabled self-autonomous intelligent transport system designed for drone workflow applications. The proposed system architecture is based on a remote method invocation (RMI) client–server model and incorporates a serverless computing framework to manage processing costs. Termed the self-autonomous blockchain-enabled cost-efficient system (SBECES), the framework integrates a client and system agent mechanism governed by Q-learning and deep-learning-based policies. Furthermore, it incorporates a blockchain-based hash validation and fault-tolerant (HVFT) mechanism to ensure data integrity and operational reliability. A deep reinforcement learning (DRL)-enabled adaptive scheduler is utilized to manage drone workflow execution while meeting quality of service (QoS) constraints, including deadlines, cost-efficiency, and security. The overarching objective of this research is to minimize the total processing costs that comprise execution, communication, and security overheads, while maximizing operational rewards and ensuring the timely execution of drone-based tasks. Experimental results demonstrate that the proposed system achieves a 30% reduction in processing costs and a 29% improvement in security and privacy compared to existing state-of-the-art solutions.

1. Introduction

Self-autonomous vehicles have gained significant popularity in practice, with their usage progressively increasing in recent years [1]. Robots and programming handle self-driving cars without human interaction in practice. For instance, package delivery drones are self-learning agents that can learn from services how to dispatch packages and navigate within the network. The aim is to enhance machine capabilities and minimize human effort in the domain of vehicles [2]. One of the autonomous vehicle’s fundamental applications is the ubiquitous use of drones for accessing the omnipresent services of distributed cloud computing [3]. Cloud computing is a core and rich domain where various vehicle services execute drone applications with different pricing models within the self-autonomous vehicle network. Many cloud providers, such as Amazon, Google, and Azure, offer services based on virtual machine infrastructure for drone applications. Two types of self-autonomous applications are designed in practice, such as semi-autonomous and fully autonomous systems [4]. Task scheduling is a key problem in a dynamic and uncertain environment, particularly when the cloud offers open services without considering security and processing costs for self-driving vehicles.

Many studies [1,2,3,4,5] have investigated the task scheduling problem for self-autonomous vehicles in distributed fog cloud networks. The goal is to successfully operate autonomous cars in uncertain and resource-constrained cloud data centers. The cloud resources are uncertain due to the heavy traffic of requests during peak hours, and the availability of services is a critical challenge for the vehicles’ applications. Several dynamic machine learning algorithms have been proposed for the dynamic scheduling of drone applications. For instance, support vector machines (SVM), random forest, naive Bayes, and other method-based schemes are suggested to handle the uncertain situation of cloud services for drone applications in the network. These studies suggest using supervised-based solutions to label the traffic path for self-driving vehicles. However, these machine learning solutions are centralized, and many datasets are trained on a single node. Decentralized training and testing models of machines based on federated learning for self-autonomous systems are presented in [6,7,8,9,10]. Federated learning enables training and testing models on different nodes, but it suffers from network overhead, security, and load balancing issues. To enhance the protection of the decentralized network, these studies [11,12,13,14,15,16,17] utilize blockchain technology to enable federated learning systems, which are proposed for self-driving vehicles. Security is enhanced by blockchain federated learning; however, the resource costs become prohibitively high for self-driving cars. Therefore, numerous research challenges exist in the current self-autonomous vehicle systems for intelligent vehicles, as documented in the research literature. For instance, if service cost and availability are critical concerns, drone-based workflow applications may fail when required services are unavailable within the system. These drone applications, which rely on sensors, generate task-related data and offload it to cloud networks for processing.

Several research challenges exist in current self-autonomous systems, which include the following: (I) Existing resource allocation schemes have high processing and storage requirements for drone applications in distributed computing. (II) Existing security mechanisms for drone applications are primarily centralized, which can lead to point-of-failure situations when any drone data is compromised. (III) Existing blockchain schemes, such as proof of work, proof of stake, and Byzantine fault-tolerance, consume significantly more resources and have high processing costs. (IV) Existing scheduling schemes are not adaptive, as resource uncertainty degrades the performance of applications during scheduling in distributed cloud computing.

Answering the research questions raised above in this paper, the study develops a self-autonomous blockchain-enabled cost-efficient system (SBECES) for an intelligent transport drone workflow application. The goal is to determine the application processing costs, including execution, communication, and security costs, for workflow applications. The study makes four critical contributions to the research questions as follows:

• The study presents a self-autonomous blockchain-enabled cost-efficient system (SBECES), which consists of various schemes to operate self-autonomous drones in a distributed cloud computing environment. The schemes include deep Q-learning, adaptive scheduling policy, hash validation, and fault learning (HVFT) to process workflow applications based on their quality of service requirements (e.g., deadline, security, and costs). SBECES is a newly designed system that offers resources based on the serverless functions of different cloud providers (e.g., Amazon, Google, Azure), with varying pricing and configurations. SBECES is a remote method invocation (RMI)-based client and server system that supports a self-autonomous agent, based on deep reinforcement learning, to perceive and comprehend the reward from the environment during execution.
• The study devises a symbol blockchain with three different roles (e.g., verifying the data hash, function authentication, and handling node failures due to attacks) within the system.
• The study devises the deep adaptive reinforcement policy and Q-learning scheme to ensure the agent’s learning accuracy and reward the agent for running the applications in the system.
• The study designs a lightweight training and testing scheme to train the autonomous agent with the minimum processing cost and execution time in the system.

The paper consisted of various sections, including Related Work, Mathematical Model, Methodology, Performance Evaluation, and Conclusions.

2. Related Work

Recent advancements in unmanned aerial vehicle (UAV)-enabled intelligent transportation systems (ITSs) have demonstrated significant potential in enhancing traffic management, surveillance, and vehicular communication infrastructures. Telikani et al. [1] provide a comprehensive survey of the integration of UAVs into ITS, highlighting the vision, architectural frameworks, key challenges such as energy limitations and airspace regulation, and the broad opportunities presented by UAVs in smart mobility ecosystems. Their work outlines the technological and operational landscape necessary for UAV adoption in next-generation ITS. Building on cooperative functionalities, Shahkar [2] proposes a multi-agent UAV localization strategy tailored for ITS environments. The study introduces a cooperative localization mechanism that enhances the spatial accuracy of UAV fleets in urban transportation contexts, particularly under conditions of GPS uncertainty. This work addresses a critical limitation in autonomous UAV navigation and demonstrates improvements in distributed coordination and real-time geolocation precision. Bakirci [3] explores the synergy between Internet of Things (IoT) infrastructure and UAV platforms to facilitate real-time mobility analysis in smart cities. By employing sensor-rich UAVs integrated with IoT nodes, the system provides granular insights into dynamic traffic flows, congestion patterns, and urban mobility analytics. The research underscores the role of aerial traffic monitoring and data fusion in enabling responsive and adaptive traffic control systems. Additionally, Oliveira [4] presents an adaptive path optimization approach that utilizes V2X (Vehicle-to-Everything) road intelligence and drone-based perspectives, particularly in GPS-deprived or obstructed environments. The method incorporates environmental sensing and vehicular collaboration to dynamically adjust UAV routes dynamically, thereby improving mission reliability. This contribution is particularly relevant in urban canyons and tunnels where traditional satellite navigation systems are compromised. The federated learning-enabled intelligent transport system is suggested in these works [5,6,7,8,9,10]. The goal is to introduce decentralized self-autonomous training and testing models to reduce the centralized overhead of machine learning models in the studies, as mentioned earlier. Federated learning trains and tests models on local devices, sharing the training and testing data with the global node to run intelligent transport workloads with minimal overhead.

The blockchain-enabled intelligent transport system for the self-autonomous model is suggested in these studies [11,12,13]. These studies designed miners and consensus algorithms, such as proof of work and proof of stake, to ensure the security of self-driving vehicles in the network. The Byzantine fault-tolerant approach suggested in [15,16,17] is proposed to avoid and mitigate external and internal cyber-attacks on blockchain networks for autonomous vehicles.

Resource allocation and offloading enabled self-autonomous vehicle systems to utilize blockchain technology, as implemented in these studies [18,19,20]. The goal is to meet the quality of service of applications during processing in the ubiquitous network. These studies enhanced the security performance of applications during mobility in the omnipresent network.

Malware and fraud effectiveness studies [21,22,23,24] suggest that blockchain and machine learning-enabled systems are designed for self-driving vehicles. The goal was to identify external attacks, such as denial-of-service, phishing, SQL injection, and cross-site scripting. These studies claimed that the distribution of data between nodes was based on immutability and valid features. The mobility features are considered in this work, where data migration based on virtual machines and containers is widely viewed as a key aspect of blockchain networks.

Several approaches to DAG-based scheduling in edge and cloud environments have been proposed. Cai et al. [25] presented a failure-resilient model, while Zhang et al. [26] explored reinforcement learning for DAG optimization. Lakhan et al. [27] focused on deadline-aware energy-efficient methods. Furthermore, Mastoi et al. [28] proposed a hybrid fog-cloud healthcare monitoring system, and Rajput et al. [29] introduced a Spark-based workflow scheduling method considering deadlines and uncertain performance.

Self-driving cars, while promising revolutionary advances in intelligent transport, come with significant resource demands in terms of computation, energy, communication, and storage. These systems require real-time processing of multi-modal data such as LIDAR, radar, GPS, ultrasonic sensors, and high-resolution video feeds. According to Badue et al. [30], a typical autonomous vehicle must process up to 1 GB of sensor data per second, necessitating high-performance onboard GPUs and neural processing units (NPUs). These processing units alone can consume over 250–300 watts of power, significantly impacting the energy budget of electric vehicles. In a related study, Ndikumana et al. [31] highlighted the computational and caching challenges in autonomous vehicle scenarios, particularly when leveraging deep learning-based decision-making on the edge. Their findings suggest that when offloading real-time data to multi-access edge computing (MEC) nodes, latency must be maintained below 20 ms to ensure safety in dynamic environments. This stringent latency requirement mandates dedicated edge infrastructure and increases operational costs exponentially as the number of vehicles scales. Thus, the resource costs (including GPU/TPU hardware, energy consumption, and low-latency edge–cloud communication) become prohibitively high, especially for large-scale deployments in urban environments. These issues are amplified when blockchain or additional security mechanisms are integrated, requiring more computing power per vehicle node.

To the best of our knowledge, there are no cost-efficient blockchain-enabled AI-driven smart autonomous vehicle ecosystems for drone workflow applications that have been studied. This is an important objective that considers both processing costs and storage in the work. The study designed a cost-efficient system based on deep federated learning with blockchain for self-autonomous applications.

3. Proposed System

The study proposes a new self-autonomous system for intelligent transport systems based on the efficient hybrid validation fault-tolerant scheme of a symbol blockchain based on the remote method invocation (RMI) mechanism, as shown in Figure 1. In the proposed work, there are two main self-autonomous agents: the client RMI and the system RMI agent. The RMI client agent controls the application objects and methods on the local drone machine while processing the workflow application locally, adhering to a set of stringent requirements. The system is designed using remote method invocation (RMI), where functions are declared on the client side and executed on the server side to minimize the burden on the local drone device. The client RMI has two parts: (a) The drone is installed with workflow applications for package delivery. All tasks in the workflow application are interdependent. Initially, all the parents will be executed, and their predecessors will run the applications. For example, the package delivery workflow applications have several tasks: registration account, login, package information, location tracing, short path finding, trip progress, data saving, and others, all of which are executed on different computing nodes, as shown in Figure 1b at the client RMI. The RMI system is another agent that controls server execution, application security, and processing costs of the applications, as shown in Figure 1b. The client RMI offloads the data of all tasks to the system RMI. Different states manage the tasks in the system. The system utilizes serverless functions from various cloud providers, including Amazon, Azure, and Google, as well as their respective functions. To validate the integrity of function and task data, the study devises a symbol blockchain scheme that incorporates hybrid validation (e.g., data-hashing validation among nodes and function authenticity checks before being added to the system services pool for further usage). To adopt uncertainty in resource allocation and workflow execution, the study devises the self-autonomous blockchain-enabled cost-efficient system (SBECES) algorithm framework, which comprises various schemes. The four key schemes are the deep Q-learning network (DQN), state management, hybrid validation, fault-tolerant, and adaptive allocation scheduler policy, which control the entire system during workflow execution.

Definition 1. 

This study implements the symbol-type blockchain in the RMI system, which hashes the workflow data when executing different cloud functions. The blockchain network is a manager that creates miners for each function when they execute workflow tasks within the system and updates their status across different cloud providers. All miners are validated based on the values of $G,M,k1,b1,s1,a1,r$ and functions from all nodes, as specified in the HVFT-Q-Table within the system.

Definition 2. 

Cloud resources: In the proposed system, the RMI-based cloud acts as an intermediary that connects multiple cloud providers (e.g., Amazon Web Services, Google Cloud Platform, and Microsoft Azure). Each provider publishes its service functions to the RMI server registry, where the system cloud selectively imports these functions into its resource pool once they are verified to be secure and protected from potential attacks—for example, a representative function M. function M.

Definition 3. 

Functions: The system executes workflow applications based on the functions and charges a price based on execution time, memory usage, and system speed. It differs from existing resource provisioning models, which include on-demand, on-reserve, and spot-instant models.

3.1. Drone Edge Cloud Scenario System Model

We present the system model of the scenario, which is a blockchain-enabled self-autonomous intelligent transport system (BESITS), designed to coordinate drone-based workflow tasks across local (drone), edge, and cloud computing layers using socket programming as the backbone for communication and blockchain as the trust anchor, as shown in Figure 2.

In this system, autonomous drones operate as local nodes, equipped with embedded sensors, GPS modules, obstacle detection systems, and onboard computation units. These drones are assigned tasks such as package deliveries, traffic surveillance, and emergency response. Each drone operates independently, making real-time decisions based on sensor inputs, yet it collaborates within a networked infrastructure through socket-based communication. For example, one drone might detect congestion on a route and relay that information via socket communication to a neighboring drone and the edge node, prompting rerouting. These drones, acting as intelligent transport agents, continuously monitor their environment, collect data such as their own geolocation, environmental conditions, or task status, and send this data to a nearby edge node using TCP or UDP sockets. UDP sockets are primarily used for lightweight telemetry transmission, such as location and battery updates. In contrast, TCP sockets ensure the reliable delivery of critical messages such as task commands or AI inferences.

Once the data reaches the edge layer, which includes geographically distributed edge cloud servers, it undergoes real-time analysis, decision-making, and storage. These edge nodes serve as intermediate computational entities that reduce latency and offload the cloud. Here, lightweight AI models are applied for tasks such as route prediction, swarm coordination, or object recognition from drone feeds. Additionally, each edge server operates a lightweight blockchain node, such as a Hyperledger Fabric or Quorum instance, which maintains a local copy of the distributed ledger. The blockchain network stores hashes of drone actions such as pick-up/drop tasks, timestamped logs, and task authentication. These entries ensure immutability and verifiability, forming a tamper-proof audit trail that government bodies or auditing systems can verify when needed. Blockchain smart contracts are deployed at the edge to automatically validate incoming drone requests, check permission tokens, and approve or reject the continuation of tasks. For instance, if a drone intends to enter a geo-fenced area, it must first request access from the smart contract deployed on the edge blockchain. If the policy allows the operation (e.g., based on time, weather, or priority of delivery), the drone receives a digitally signed confirmation and proceeds. This integration ensures decentralized trust and accountability without relying on a single point of control. In the cloud layer, the full system-level orchestration takes place. The cloud servers are responsible for collecting and analyzing historical data from all edge nodes. They host centralized blockchain nodes that synchronize with the edge ledgers, train deep learning models using aggregated drone telemetry, and provide predictive analytics such as traffic forecasting, fault detection, and environmental modeling. For example, by combining video feeds and location data from hundreds of drones over time, the cloud AI engine can train a model to detect patterns of congestion or identify accident-prone zones. These insights are then shared with the edge servers or directly transmitted back to drones as updated behavioral models. Socket-based persistent connections are maintained between edge and cloud layers to allow seamless data streaming, control instructions, and blockchain synchronization. Security is a major concern in such decentralized systems, and blockchain addresses these challenges effectively. All drone identities are registered on the blockchain network with unique cryptographic credentials. This allows mutual authentication when a drone connects to an edge server. Moreover, the use of smart contracts ensures that only authorized drones perform sensitive operations such as entering restricted airspace or handling emergency supplies. Since all events are recorded immutably on the distributed ledger, the system maintains complete transparency, which is critical in public transportation and logistics environments. In case of operational disputes or failures, system stakeholders can verify each action through the blockchain’s traceable records. The diagram presented in Figure 2 visually illustrates this architecture. It shows drones operating at the local level, sending data via socket connections to edge cloud servers, where preliminary processing and blockchain validation occur. The edge layer interacts with a centralized cloud platform through further socket-based channels. The figure emphasizes the role of blockchain at the edge and cloud tiers, reinforcing trust and integrity across the workflow. It also shows drone-to-drone and drone-to-vehicle interactions occurring in real time, coordinated by the edge cloud networks. This visual representation provides readers with a comprehensive understanding of the data flow, communication architecture, and system distribution in the BESITS framework. Consider an emergency response scenario in Karachi Smart City, where a road accident has occurred and emergency supplies need to be dispatched urgently. A drone, stationed nearby, receives a broadcast from the central transport AI system. It initiates a socket connection to the edge server, sharing its current location, battery level, and readiness status. The edge server validates the drone’s credentials using blockchain, assigns the pickup location, and activates the task via a smart contract. The drone flies autonomously, avoiding obstacles and adjusting for weather changes using its onboard intelligence. It continuously streams its progress to the edge server, which logs events to the blockchain. If the edge server detects interference or unpredictable behavior, it issues a real-time override, guiding the drone to the closest safe path. All communication, decisions, and operational metadata are stored immutably, ensuring accountability and post-operation analysis. Once the task is completed, the cloud server updates the drone’s profile with performance metrics and retrains its AI module if necessary.

In another instance, drones are deployed for traffic surveillance across a dense urban corridor. They fly in formation and relay real-time traffic footage and congestion levels to edge servers. The edge applies deep reinforcement learning to detect irregularities or hazards and, if necessary, invokes blockchain-based workflows to trigger alert messages or coordinate rerouting efforts with smart traffic lights. Meanwhile, the cloud continuously refines global AI models to optimize fleet distribution and anticipatory rerouting based on historical trends.

This seamless interplay among autonomy, distributed intelligence, and trust demonstrates the efficacy of the BESITS framework. The use of socket programming enables real-time, bidirectional communication across nodes, while blockchain ensures that every decision is secure, verifiable, and tamper-resistant. This approach ensures resilience against cyberattacks, enhances transparency, and supports rapid decision-making in time-critical environments. It is highly scalable, suitable for multi-drone operations, and compatible with future extensions involving digital twins, AIoT, and smart grid integrations.

3.2. Problem Formulation

This study presents the drone workflow applications using a directed acyclic graph, i.e., $G(V,E)\in A$, where V represents the variable showing workflow tasks, and E denotes the communication of tasks via edges, as shown in

Table 1. Mathematical notation.

Notation	Description
A	Number of different workflow drone applications
G	The G workflow application
$G_D$	Deadline of workflow application
$W_G$	Total workload of application G
V	Number of tasks of application G
v	The vth task of V
$v_d$	The deadline of task v
$dat{a}_v$	The workload of task v
$b_w$	The communication bandwidth between tasks
$T_i^e$	Execution cost of task v
$CP$	Number of fog-cloud nodes
$cp$	The particular node $cp$ from nodes $CP$
$x_{i,j}$	The assignment of task i to function j
B	Number of blockchain blocks
$b_1$	The bth block of B
$M{C}_i$	Mined cost of task $v_i$
M	Number of functions pool of different cloud providers
j	The jth function of pool M
$j_m$	Memory of function j
$j_c$	Execution cost of function j
$DR$	Number of drones
$D{R}_a$	The ath of $DR$
$D{R}_{al}$	Route of drone a
$D{R}_{at}$	Coordinates of drone a
$D{R}_{a-time}$	Flight time of drone a
$D{R}_{a-date}$	Flight date of drone a

. The G application has an N task number. Where the $v_0$ task is an entry task, the $v_n$ task is an exit task. Each task $v_i$ has a deadline of $v_{d}i$ and data $dat{a}_i$ during execution in the system. The study considered the $CP\{c{p}_1,dots,CP\}$ numbers of computing nodes and the {$B{b}_1,dots,B\}$ numbers of blocks for the mining process across all tasks. Each computing node, $cp.b$, is associated with a specific network block. The study considered package delivery drones, e.g., $drone$, exploiting application G to achieve the business goal of transferring packages from one location to another. The drone contains a set of values such as location $dron{e}_{location}$, speed $dron{e}_{speed}$.

$${\mathit{x}}_{v_i,j}=\left\{\begin{array}{cc}1,\hfill & x_{v_i,j}\mathrm{is}\mathrm{picked}\mathrm{for}{v}_i\hfill \\ 0,\hfill & \mathrm{otherwise},\hfill \end{array}\right.$$

(1)

The assignment of tasks is determined in Equation (1), where each task is assigned to one function in the specific computing node. There are two execution processes in the study, such as execution time on the function and security and privacy validation of tasks during processing of the blockchain mechanism. The study determines the execution time of tasks in the following.

$$T_i^e=\sum _{v_i=1}^V\sum _{j=1}^M{\displaystyle \frac{dat{a}_v}{j_m}}\times j_c\times x_{v_i,j}+b_{v_i,j}.$$

(2)

The execution time and cost depend on the completion of tasks and usage memory of the function, as illustrated in Equation (2). Initially, the study divides the workflow application deadlines in the following way.

$$ratio=\sum _{G=1}^A{\displaystyle \frac{G_D}{A}},$$

(3)

$$T_i^e\times ratio,$$

(4)

$$e_{v_1\to v_2}=e_{v_1\to v_2}\times ratio,$$

(5)

$$\begin{array}{c}\hfill v_d=\min \left(\left\{v_2\right\}\right)-T_i^{\prime e}\left(v_1\right)-e_{(}{v}_1,v_2)\\ \hfill \forall v_1\in V\exists v_2\in successor\left(v_1\right).\end{array}$$

(6)

These Equations (4)–(6) make sure that all tasks are executed within their deadlines.

$$b_{v_i,j}=Hashing+Validation\leftarrow dat{a}_i\times {\displaystyle \frac{e\leftarrow v_1\to v_2}{b_w}}.$$

(7)

The blockchain hashing and validation are determined based on Equation (7).

$$\begin{array}{c}\hfill validation=hashing\left(dat{a}_v\right)\leftarrow v_1\to \\ \hfill hashing\left(dat{a}_v\right)\leftarrow v_2=1.\end{array}$$

(8)

The validation of communication data in the decentralized function are determined based on the blockchain hashing method, where the current and previous functions must be matched during data processing, as illustrated in Equation (8).

$$hashing=SHA-256\in j\leftarrow {\displaystyle \frac{dat{a}_v}{j_m}}.$$

(9)

The objective function of the study is to minimize the processing cost of all workflow applications, as determined in Equation (11).

$$\min X=\sum _{G=1}^A{T}_i^e,j=1,\dots M.$$

(10)

S.T.

$$\min X=\sum _{G=1}^A{T}_i^e\le v_{d}j=1,\dots M.$$

(11)

This study models drone workflow applications using a directed acyclic graph (DAG) $G(V,E)\in A$, where V denotes the set of workflow tasks, and E defines the communication edges between them, as specified in Table 1. The DAG-based application contains N tasks, with $v_0$ representing the entry task and $v_n$ the final exit task. Each task $v_i$ is characterized by a deadline $v_d^i$ and associated execution data $dat{a}_i$. The execution environment consists of a set of computing nodes $CP=\{c{p}_1,\dots ,c{p}_M\}$ and blockchain blocks $B=\{b_1,\dots ,b_W\}$ used for data validation and security. Each computing node $c{p}_j$ may be linked to a blockchain block $b_j$, forming a decentralized processing and validation infrastructure. Drones executing the workflow are modeled with mobility parameters such as location $dron{e}_{location}$ and speed $dron{e}_{speed}$. Task assignment is determined by Equation (1), where a binary variable $x_{v_i,j}$ indicates whether a specific task $v_i$ is assigned to node j. The system accounts for both functional execution and blockchain-based security validation during task execution. The total execution time of task $v_i$ on node j is quantified in Equation (2), which calculates time as a function of data size, memory usage $j_m$, computational capacity $j_c$, and the overhead from blockchain validation $b_{v_i,j}$. To manage deadline constraints across all tasks, the workflow’s overall deadline is proportionally divided using a ratio metric defined in Equation (3). This ratio is then applied to adjust the execution time (Equation (4)), edge delay (Equation (5)), and finally to update the remaining task deadlines based on precedence constraints, as formulated in Equation (6). This ensures all tasks are scheduled within their respective deadlines. Blockchain validation costs, including hashing and consensus verification, are calculated in Equation (7), which models the cost as a function of data size and edge communication latency normalized by the block bandwidth $b_w$. The validation of communication data integrity across blockchain blocks is defined in Equation (8), where hash values of successive tasks must match to preserve tamper-proof execution history. The cryptographic operation used is SHA-256 and its hashing cost are captured in Equation (9), showing the dependence on data size and memory capacity. The overall system objective is to minimize the processing cost X across all workflow applications by summing the execution times $T_i^e$ for each application G, as outlined in Equation (11), subject to the constraint that each task’s execution must complete within its assigned deadline. This optimization strategy guides task scheduling under decentralized, secure, and resource-constrained edge–cloud environments for drone-based intelligent transport systems.

In the proposed SBECES framework, the total processing cost is composed of three primary components: execution cost, communication cost, and security cost, each representing a distinct resource consumption factor in the drone-based workflow system. Execution cost refers to the computational resources consumed during the processing of drone workflow tasks. This includes the CPU/GPU cycles used by onboard processing units, edge servers, or cloud nodes to execute AI-based control algorithms, path planning, video analysis, and decision-making logic. It is quantified based on the execution time multiplied by the computational resource pricing (e.g., per-second or per-instruction cycle). Communication cost represents the data transmission overhead among drones, edge, and cloud nodes. It includes bandwidth usage, transmission energy, and network latency penalties. The cost is influenced by factors such as data packet size, frequency of updates, and network congestion, and is computed based on the data volume transmitted and the network rate. Security cost refers to the overhead introduced by blockchain operations, including data hashing, encryption, consensus verification, and smart contract execution. These operations incur additional computation and communication delays, which are quantified as latency and energy overhead in the security model. Together, these three costs define the system’s operational efficiency.

To complement the proposed system architecture, we now provide a detailed network and communication model tailored to the nature of wireless mobile communication scenarios involving extensive real-time data collection and exchange among drones, edge, and cloud nodes. Given that self-autonomous intelligent transport applications operate in highly dynamic environments, the underlying communication infrastructure must support real-time, secure, and scalable data transfer. The proposed SBECES (self-autonomous blockchain-enabled cost-efficient system) framework is modeled using a heterogeneous, multi-tiered wireless communication network comprising local (drone), edge (fog), and cloud (centralized) components. Each drone operates as a mobile device which is connected to the edge cloud network with the stable format of communication channels. To mathematically describe communication behavior, we adopt Shannon’s capacity model to define the achievable data rate $R_{d,e}$ between a drone d and its associated edge node e as:

$$R_{d,e}=Bw{\log }_2(1+\mathrm{SNR})$$

(12)

where $Bw$ denotes the available bandwidth, and SNR is the signal-to-noise ratio, which dynamically varies based on distance, interference, and drone mobility. The network topology follows a client–server remote method invocation (RMI) model, where drones act as remote clients invoking workflow execution methods on edge/cloud servers. Edge nodes serve as intermediate decision and caching layers, running containerized microservices to evaluate incoming data, perform Q-learning-based policy selection, and validate data authenticity using the symbol-type blockchain-based hash validation and fault-tolerant (HVFT) mechanism. These blockchain operations are treated as lightweight background processes and are integrated into the network model as additional latency $D_b$, computed during consensus and block propagation phases. Between the edge and cloud layers, high-speed fiber or mmWave backhaul communication is assumed, with average round-trip latency ${\lambda }_{e,c}$ constrained to under 50 ms to maintain quality of service (QoS) during dynamic workflow scheduling. The deep reinforcement learning (DRL)-enabled adaptive scheduler monitors network congestion and available processing bandwidth at the edge in real-time and dynamically adjusts task offloading and data routing strategies. This enables the SBECES framework to maintain QoS guarantees across multiple key performance indicators such as task completion deadlines, communication reliability, and transmission energy costs. The SBECES framework’s network model accounts for realistic communication conditions inherent to mobile self-autonomous systems. It integrates wireless communication constraints, edge–cloud latency, data validation using blockchain, and DRL-based scheduling to ensure efficient and secure transport workflows. This comprehensive approach enables a scalable and fault-tolerant networked architecture suitable for drone-based intelligent transportation applications in real-world smart city environments.

4. Proposed SBECES Algorithm Framework

This study proposes a self-autonomous blockchain-enabled cost-efficient system (SBECES) that consists of different schemes to solve the assignment problem in the network. The considered drones are self-autonomous, with their location and speed determined in the following way.

$$\begin{array}{c}\hfill Mobility-Offloading=\sum _{a=1}^{DR}G\in A\leftarrow \\ \hfill D{R}_{a1},D{R}_{at},D{R}_{a-time},D{R}_{a-date}.\end{array}$$

(13)

Equation (13) determines the drone offloading, mobility, and current location of the drone along with the time and date. The study considers the dynamic mobility-enabled problem of the self-autonomous drone applications. The mobility-enabled data privacy and security are the key requirements in the work. The study devises the SBECES framework, which consists of different schemes, as defined in Algorithm 1. The existing blockchain technology enabled mobility services for drone applications investigated in these studies [32,33,34,35,36].

Algorithm 1 SBECES

Algorithm 1 shows that the SBECES algorithm framework has different schemes, such as statement management, mobility offloading scheme, workflow task sequencing, a blockchain hybrid validation fault-tolerant scheme, and adaptive scheduling policy, which are defined in their respecctive subsections.

4.1. Client and System Agent Training

The SBECES has two main agents, client RMI and system RMI agent, as shown in Figure 3. The cloud $k1$ is the RMI registry, where three different cloud providers (e.g., Google k2, Azure k3, and Amazon k4) publish their functions in the system. All the functions are validated in the system based on the hybrid validation fault-tolerant (HVFT) scheme to handle both the security and authenticity issues in the system. The train and test mechanisms based on deep reinforcement learning are divided into different states, such as $X=Q0(s1,a1,b1,k1)$, where the objective function-based q-learning variable $Q_0$ updated at the first state, with actions, reward, and function in the system cloud $k1$. Each cloud trains and tests at different states based on deadline, processing cost, blockchain cost, hybrid validation, fault-tolerant, and gain of the optimal reward in the system, as shown in Figure 3. Q-Learning stores the record of each state and matches all cloud functions and achieves the optimal functions M for the particular application G. It will continue until and unless all workflows are allocated to the functions till execution in the system. The objective function ${\sum }_{G=1}^{A}X$ is optimized based on deep Q-learning, and matching in the following way.

$$\pi \leftarrow X=\sum _{Q=0}^{N}L\sum _{s=1}^S\sum _{a=1,r=1}^{actions,R}\sum _{k=1,b=1}^{K,B}(s1,a1,b1,k1,r).$$

(14)

Equation (14) determines the optimal policy based on available costs and the status of the function based on reward in different states.

4.2. Task Sequencing

The topological ordering of workflow tasks before scheduling is an important task because all tasks have different execution requirements in the system. For instance, if the three tasks to be started in parallel form, one of them has a stringent deadline, and a small workload must have high priority as compared to a deadline-tolerant task. The study orders the tasks based on Algorithm 2.

Algorithm 2 Workflow task sequencing based on deadline and time

4.3. Hash Validation and Fault Tolerant (HVFT)

The study devises a hybrid validation (e.g., hashing validation and function authenticity) and fault-tolerant scheme. It adds the functions in the pool as per the standard defined in

Table 2. Q-updated deep reinforcement learning.

States Actions	Hashing	Validation	Vendor	Failure	Cost	Memory	Execution
$s1,a1,r,j_1$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s2,a2,r,j_2$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s3,a3,r,j_3$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s4,a4,r,j_4$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s5,a5,r,j_5$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s6,a6,r,j_6$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s7,a7,r,j_7$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s8,a8,r,j_{-}8$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds
$s9,a9,r,j_9$	SHA-256	$k1\leftarrow k2\leftarrow k3\leftarrow k4$	k1,k2,k3,k4	Availability	$0.5\$\sim 10\$$	512–1024 MB	Milliseconds

. The Q-learning adds data based on different metrics in the system after validation of the hashing and the function based on Algorithm 3.

Algorithm 3 Symbol blockchain scheme [37,38]

There are eight attributes in Q-learning that are updated continuously after a given set of intervals, which are the following:

• States Actions: All attributes are divided into different states and actions of the problem and calculated as the reward of the objective in different computing nodes and their function for the workflow application, e.g., $s1,a1,r,j1$.
• Hashing: Each workflow task must be converted into a cipher based on SHA-256; each function must execute data when it has a valid hash in the node.
• Validation: If the data has valid hashing based on SHA-256 symmetric keys, it will allow functions to execute tasks in the system.
• Vendor: Before adding functions to the system function pool from the RMI registry, the study validates and verifies the function authenticity from the parent cloud providers in the system.
• Failure: The study exploited a checkpointing scheme where the point of failure will start from failing, not scratch, once a function or task fails during execution in the system.
• Cost: All the functions are added at their lowest cost in the function pool.
• Memory: The system verifies that the function memory is enough to run the task in the system.
• Execution: All the tasks are charged based on their execution in the system.

4.4. Symbol Blockchain Scheme

The study devises a lightweight blockchain technology scheme to validate the data privacy and security during the mobility of the workflow drone applications in the system. The blockchain scheme consists of hash validation, proof of work, mobility offloading security status, and execution of security in the work. The study designs the blockchain scheme based on the aforementioned attributes defined in Algorithm 3.

Algorithm 3 defines the process of blockchain methods, such as validation, hashing, and scheduling, based on the minimum processing cost in the system. Algorithm 3 has the following steps to validate and efficiently execute the applications.

• Initially, all workflow applications are assigned to the functions in the different nodes.
• All the drones are monitored during their mobility in the network.
• All the data of workflow tasks are converted from plaintext to hash based on the proposed hashing method
• All the tasks are sequenced based on their execution time and deadline in the network.
• All the functions are sorted according to their cost and resources in the network.
• All the tasks are executed under their deadlines.
• The blockchain enabled validation of hashing data during the distribution of data between tasks, validated based on their hashing.
• The workflow tasks run on the different decentralized functions, and the data is to be shared and distributed based on the blockchain technology in the system.
• The failure and run time service predication to be monitored in each hour from different providers for the workflow applications.
• All the workloads are successfully executed under their deadline and meet the security, privacy, and cost requirements of the applications.

4.5. Deep Reinforcement Learning Enabled Self-Adaptive Scheduler Policy

Algorithm 4 determines that, if the reward function of the current state is better than the previous state, it will replace the existing solution X with the new solution $X^{\ast }$ based on trial and error in the system. The system will revise until and unless all applications converge, become optimal, and meet the deadline of all applications.

For the communication, we have suggested Algorithm 5 to maintain the communication between nodes. The proposed algorithm formalizes the network and communication models of the study by explicitly mapping the drone workflow application, represented as a directed acyclic graph $G=(V,E)$, with $\left|V\right|=N$ tasks, an entry task $v_0$ and an exit task $v_n$, onto a set of heterogeneous computing nodes $\mathcal{C}=c{p}_1,\dots ,c{p}_M$, each associated with a blockchain block $b\in \mathcal{B}$.

Algorithm 4 Deep reinforcement learning-enabled self-adaptive scheduler policy

The network model is constructed by assigning each task $v_i$ to a computing node $c{p}_j$ through a binary decision variable $x_{v_i,j}$, where $x_{v_i,j}=1$ if $v_i$ is executed on $c{p}_j$ and 0 otherwise, and storing this mapping $\mathcal{N}$ along with its associated blockchain block $b_j$. The communication model is captured by iterating over each directed edge $(u,v)\in E$, representing task dependencies and computing the adjusted communication delay $e_{u\to v}$ by scaling the original link delay by a ratio factor $ratio=G_D/A$, where $G_D$ is the workflow application deadline, and A is the total number of applications. Thus, we proportionally distribute the global deadline among the edges of the DAG. This adjusted delay is recorded in a communication matrix $\mathcal{L}$, preserving the temporal cost of data transfers between dependent tasks under the distributed deadline constraints. In parallel, the blockchain validation model is formulated for each task $v_i$ by computing the blockchain overhead $b_{v_i,j}$ according to $b_{v_i,j}=\mathrm{Hashing}+\mathrm{Validation}\leftarrow dat{a}_i·{\displaystyle \frac{e_{p\to i}}{b_w}}$, where p denotes the predecessor of $v_i$, and $b_w$ is the blockchain bandwidth. The hashing operation is defined as $hashing=\mathrm{SHA-}256\left({\displaystyle \frac{dat{a}_i}{j_m}}\right)$, where $j_m$ is the memory capacity of the assigned node, while the validation process ensures blockchain consistency by verifying that the hash of the predecessor’s data $hash\left(dat{a}_p\right)$ matches the stored $prevHash\left(dat{a}_i\right)$ of the current task, thereby guaranteeing data integrity and immutability across the distributed workflow. These computed hashing and validation details are stored in a blockchain validation map $\mathcal{H}$. By returning the triple $(\mathcal{N},\mathcal{L},\mathcal{H})$, the algorithm provides a complete and formalized representation of the network topology, inter-task communication delays, and blockchain-based security mechanisms for the workflow application. This approach integrates the computational characteristics of heterogeneous edge/cloud nodes, the latency constraints of task dependencies, and the cryptographic guarantees of blockchain validation into a unified formal model, enabling analytical evaluation and optimization of drone workflow execution in distributed environments. The formalization ensures that every task is explicitly linked to a specific compute–block pair, every dependency is assigned an exact communication cost under deadline constraints, and every data transfer is secured by blockchain hashing and validation, thus providing a rigorous foundation for subsequent optimization, scheduling, and fault-tolerant execution strategies within the system.

Algorithm 5 Formalization of network and communication models

5. Performance Evaluation

The simulation parameters are implemented in the serverless evaluation model defined in

Table 3. Simulation parameters.

Simulation Parameters	Values
Simulator	Ifogsim
G1	15 workflow tasks
G2	50 workflow tasks
G3	100 workflow tasks
Blockchain	Deep Blockchain

.

Table 4. Function of different vendors.

K	M	Memory	C	Update-Hour
k1	$j_1$	512	0.5	1
k1	$j_2$	512	0.7	1
k1	$j_3$	512	0.3	1
k1	$j_4$	512	0.5	1
k1	$j_5$	512	0.6	1
k1	$j_6$	0.3	512	1
k2	$j_1$	512	0.7	1
k2	$j_2$	512	0.8	1
k2	$j_3$	512	0.3	1
k2	$j_6$	512	0.3	1
k2	$j_8$	512	0.4	1
k2	$j_9$	1024	0.9	1
k3	$j_4$	2048	0.9	1
k3	$j_7$	1024	0.7	1
k3	$j_3$	2048	0.11	1
k3	$j_4$	512	0.5	1
k3	$j_8$	512	0.6	1
k3	$j_9$	512	0.2	1

shows the cost of functions of different vendors. Each of the functions was deployed using a Python 3 runtime with 256 MB of memory. The cloud function generated was a factorial function that calculates the factorial of 100 fifty times. In our experiments, three different workflow application graphs—G1, G2, and G3—are simulated, each comprising 15, 50, and 100 drone-executed tasks, respectively. These workflows represent different transport scenarios with increasing complexity. The drones in our model are assigned real-world characteristics such as communication range (100–300 m), average speed (10–20 m/s), and data transmission rates (2–10 Mbps), which are consistent with existing urban drone platforms. Communication delays between drones and edge nodes follow a Gaussian distribution with a mean latency of 15 ms, simulating typical 5G-V2X conditions. Additionally, the blockchain module, implemented using the Deep Blockchain framework, includes lightweight SHA-256 hashing and PBFT consensus latency models. These parameters have been incorporated into the revised Table 3 and clarified in the simulation setup section to enhance reproducibility and the credibility of the evaluation results.

5.1. Drone Workflow Dataset

The study exploited a dataset for the experiment that is obtained from [39], as defined in

Table 5. Drone package delivery dataset.

$\mathit{DR}$	${\mathit{DR}}_{\mathit{S}}$	${\mathit{W}}_{\mathit{G}}$	${\mathit{DR}}_{\mathit{t}}$	$\mathit{DR-}\mathit{Date}$	$\mathit{DR-}\mathit{Time}$	${\mathit{DR}}_{\mathit{l}}$
10	8	512	25	4 December 2020	10:13:00 a.m.	a
20	12	1024	50	4 December 2020	11:13:00 a.m.	a1
30	13	512	75	10 December 2020	12:13:00 p.m.	a2
40	15	719	25	15 December 2020	01:13:00 p.m.	a3
50	17	512	25	19 December 2020	02:13:00 p.m.	a4
60	19	1024	55	21 December 2020	10:13:00 a.m.	a5
70	10	2048	100	1 March 2021	06:13:00 a.m.	a6
100	12	512	150	6 March 2021	05:13:00 a.m.	a7
150	10	1024	170	7 March 2021	07:13:00 a.m.	a8
200	15	512	100	8 March 2021	08:13:00 a.m.	a9
279	20	1024	250	9 March 2021	09:13:00 a.m.	a10

.

5.2. Statistical Method for Performance Evaluation

The study exploits the different statistical evaluation methods, such as ANOVA, t-test, and relative percentage deviation (RPD), to evaluate the performance of the studies based on workflow applications in the system.

$$RPD(\%)={\displaystyle \frac{X^{\ast }-X}{X^{\ast }}}\times 100\%.$$

(15)

5.3. Discussion

To further demonstrate the adaptability of the proposed self-autonomous blockchain-enabled cost-efficient system (SBECES), we designed a comprehensive set of simulations across various dynamic scenarios that reflect the real-world complexities of drone-based intelligent transport applications. Adaptability in this context refers to the system’s ability to efficiently adjust task scheduling, resource allocation, and security management in response to changes in task load, network latency, and environmental uncertainty while maintaining quality of service (QoS) requirements such as deadlines and processing costs. Three different workflow graphs (G1, G2, G3) consisting of 15, 50, and 100 drone-executed tasks, respectively, were simulated to evaluate scalability. The simulation results showed that SBECES maintained optimal scheduling efficiency across all workflow sizes. For example, even under the heaviest workload (G3), the system achieved a 27% improvement in task completion ratio under deadline constraints compared to baseline models using traditional static scheduling. This demonstrates the framework’s ability to adapt to increasing workflow complexity without a significant loss in performance. Moreover, the system was tested under variable network latency conditions (5 ms to 50 ms) to assess its behavior under fluctuating communication quality. The deep reinforcement learning (DRL)-enabled scheduler dynamically adjusted task placement decisions, shifting computational load from congested edge nodes to lightly loaded nodes within acceptable latency margins. The SBECES framework showed resilience by maintaining over 90% task success even in high-latency environments, while baseline schedulers dropped below 70%. This adaptability is a direct result of the scheduler’s continuous state monitoring and policy learning in real time. In addition, we evaluated the system’s behavior under dynamic blockchain overheads by varying the consensus delay and block validation time. When the average blockchain processing delay was increased from 10 ms to 60 ms, SBECES intelligently reprioritized tasks to minimize cumulative delay. Instead of allowing the blockchain layer to become a bottleneck, it selectively bypassed non-critical transactions or grouped multiple transactions for batch validation without compromising security or data integrity. These decisions were based on a Q-learning-based cost–benefit policy, showcasing the system’s ability to adapt its security operations in latency-sensitive scenarios. Furthermore, SBECES showed strong adaptability in energy-constrained drone operations. By dynamically monitoring drone battery levels and communication bandwidth availability, the framework selectively offloaded heavy tasks to stationary edge nodes while assigning lightweight monitoring or routing tasks to mobile drones. This adaptive resource orchestration contributed to a 30% reduction in average energy consumption per task, enabling longer mission lifetimes and reduced drone downtime.

The study implemented the best baseline approaches, such as self-autonomous virtual machine (SAV) [5,7,9], self-autonomous blockchain [12,14,15], and self-autonomous edge cloud (SAC) as the baselines in the work. The evaluation method is a statistical method, with interactions and 95.0 percent Tukey HSD intervals for applications. We measure the performance of each workflow application based on different edge computing models. For instance, edge computing with virtual machine (VM) services, edge computing with containers, edge computing with microservices, and edge computing with the serverless model. Edge computing with virtual machine schedules all workflow applications based on their requirements and exploits on-demand and on-reserve services pricing models to schedule tasks. However, these models require maintenance during the process to show a resilient runtime environment for applications. Edge computing with containers and microservices is a lightweight runtime compared to a virtual machine-based system. These runtimes convert monolithic applications into fine-grained isolated components. The microservices are isolated and resilient. However, these models also have high maintenance costs during the scheduling of IoT workflow applications. Based on the proposed serverless model, we suggested novel schemes that not only satisfy the user’s requirement but also improve provider resource utilization without any waste of cost. The proposed system also meets the deadline requirement of all applications, as shown in Figure 4. The execution deadline of all tasks of a particular application is summed up to the total, as shown in Figure 4. The red line indicates that almost all applications were executed within their deadlines. The study divided the mobility area into three areas and considered more than workflow applications during roaming from one place to another. Figure 5 illustrates that the applications have varying mobility costs during system mobility. Figure 6 illustrates all IoT workflow applications with complex nodes, demonstrating a lower RPD% with the proposed serverless model compared to existing runtime edge computing models and their schemes. There are many reasons. The first reason is that all existing models use searching techniques and game theory to match each resource to the task, which satisfies their requirements. However, it is time-consuming and incurs heavyweight overhead at run time. The second reason is that the serverless-based task sequence and scheduling always choose an optimal function, with security, deadline, and cost constraints. Figure 6 shows that the serverless model works better compared to existing baseline runtimes for drone workflow applications.

All tasks have mining costs in the blockchain network, as shown in Figure 7. The security tasks have larger mining costs due to the encryption and decryption process. However, general tasks incur a small mining cost. In the end, the mined cost of all applications is the sum of general tasks and security tasks during the process, as shown in Figure 7.

Figure 7a shows that the proposed deep reinforcement Q-learning-enabled HVFT outperformed all existing blockchain schemes in both data validation and function validation compared to existing proof of work methods, proof of stake, and Byzantine fault-tolerant methods in the system for the workflow applications. Figure 7b showed that the costs of applications $X\leftarrow G1\sim A$ increased when many failures occurred in the functions because existing schemes only focused on data failure due to attacks in the system. However, existing methods overlooked the validation of functions and resources within the system, as well as the high processing costs that occurred.

6. Conclusions and Future Work

This study proposes a novel blockchain-enabled, self-autonomous intelligent transport system for drone workflow applications, based on a remote method invocation (RMI) client and server architecture. The study suggested a processing cost model based on the serverless function of the study. Based on symbol blockchain and serverless suggestions, the self-autonomous blockchain-enabled cost-efficient (SBECES) system consists of different components: self-autonomous client agent and system agent-based Q-learning and deep learning policy, symbol-type blockchain-based hash validation and fault-tolerant (HVFT) scheme, and deep reinforcement learning-enabled cost-efficient adaptive policy-enabled scheduler scheme to run the drone workflow with the given set of quality of service requirements (e.g., deadline, security, and costs). The study’s objective is to minimize processing costs (execution cost, security cost, and communication cost), maximize rewards, and meet the deadline of the drone workflow in the system. The results show that the proposed work minimizes the cost by 30% and improves security and privacy by 29% using existing methods

However, there are many limitations in the current work that need to be improved in the next work. For instance, the current version targets only one type of workflow application, drone applications; another work we will consider is many workflow applications in the domain of vehicles. The proposed method is dynamic; however, there should be an adaptive method to handle the uncertain issue in the network. This study currently does not account for the impact of dynamic network conditions, such as bandwidth jitter, on the convergence of deep reinforcement learning (DRL) models used for optimizing task offloading and resource scheduling. Such network dynamics can lead to unpredictable latencies, affecting both the learning convergence rate and task deadline violations. Future enhancements should incorporate probabilistic modeling of network bandwidth and its influence on reward functions and convergence behavior in DRL-based schedulers.