Smarter Swarms: Empirical Assessment of Blockchain-Based RLR and DeTAV Algorithms in Swarm Network

Smarter Swarms: Empirical Assessment of Blockchain-Based RLR and DeTAV Algorithms in Swarm Network | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Smarter Swarms: Empirical Assessment of Blockchain-Based RLR and DeTAV Algorithms in Swarm Network SATHISHKUMAR RANGANATHAN, Muralindran Mariappan, Karthigayan Muthukaruppan This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-6810291/v1 This work is licensed under a CC BY 4.0 License Status: Published Journal Publication published 12 Feb, 2026 Read the published version in Discover Computing → Version 1 posted 20 You are reading this latest preprint version Abstract Swarm robotics is an evolving realm, designed to achieve complex tasks collaboratively. This technology faces challenges in secure communication, decentralized decision making, and scalability aspects. While many studies suggested using of Blockchain technology for swarm robotics, the existing Blockchain solutions with Proof of Work (PoW) or Proof of Stake (PoS) based consensus, originally designed for finance and trade network systems, are inefficient for swarm robotics due to their high computation needs or stake-based monopolies. This research addresses these challenges by introducing a Blockchain based Rotational Leadership Role (RLR) consensus algorithm, a voting-based consensus protocol, with Decentralized Task Authorization and Validation (DeTAV), a token-based transaction validation mechanism, to ensure efficiency, security, and scalability features in swarm robotic and drone systems. RLR is a lightweight hybrid solution suitable to run within the limited computing resources of any small robots or aerial drones. A custom-built robotic simulator compared RLR to PoW, demonstrating RLR's superior performance. Based on the experiments conducted with 70 concurrent robots, RLR used under 100MB RAM and 12.5% CPU, while PoW exceeded 450MB RAM and 25% CPU, showing a 500% RAM and 173% CPU reduction by using RLR. RLR's DeTAV also enhanced network security through context-based task validation to restrict suspicious activities initiated by malfunction or malicious robots in the network. Scalability tests performed using 4 to 70 robots revealed RLR's ability to scale effortlessly to handle over 70 nodes. Thus, RLR with DeTAV effectively meets the efficiency, security, and scalability needs of swarm robotic or drone networks. Blockchain Swarm Robotics Consensus algorithm Raft Decentralized networks security Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 1 Introduction Industry 4.0 represents a significant transformation of the industrial sector, integrating advanced digital technologies such as IoT, cyber-physical systems, AI, and cloud computing into smart manufacturing or production processes [ 1 ]. Recent advancements in this field emphasize merging traditional automation technologies with these constructive digital innovations to create intelligent, interconnected, and efficient industrial systems. As one of the vital pillars of Industry 4.0, the role of swarm robotics aligns with the industry's goal of decentralized intelligence, enabling robot swarms to enhance flexibility and efficiency within smart factories and automated warehouses [ 2 ]. This multi-agent distributed network of autonomous robots collaborate in a decentralized manner, inspired by social insects like ants or bees. This innovative technology is capable of carrying out complex tasks for industrial applications like aerial surveillance, farming, marine operations, handling hazardous environments like space, and smart manufacturing processes [ 3 ]. Recent developments shows that Blockchain technology is increasingly integrated with swarm robotics to overcome challenges in secure coordination and maintaining data integrity across decentralized robotic networks used in factories, automated warehouses, and critical operations [ 4 ]. Blockchain's decentralized ledger and smart contracts have significantly enhanced tamper-proof data sharing without central authority oversight in token-based economies [ 5 ]. However, substantial challenges remain, particularly concerning the efficiency in computational and energy requirements of blockchain algorithms, communication delays, and scalability within large robot swarms, necessitating the development of lightweight and optimized consensus mechanisms. Particularly, ensuring seamless interoperability between blockchain platforms and swarm robotic systems is also a key area of ongoing research [ 6 ]. Blockchain integration in swarm robotics commonly employs consensus algorithms like Proof of Work (PoW) and Proof of Stake (PoS) based variants. Proof of Work (PoW), famously used in Bitcoin, provides robust security through solving computationally intensive cryptographic puzzles, which makes it less feasible for real-time robotic swarms due to its high computational demands and environmental impact [ 7 ]. In contrast, Proof of Stake (PoS) and Delegated Proof of Stake (DPoS) has emerged as another promising consensus approach, particularly due to its significantly lower energy requirements and computational demands compared to Proof of Work, by relying on validators' stakes to secure consensus [ 8 ]. Yet integrating PoS into swarm robotics brings its own complexities, particularly in managing stakes, validator selection, and ensuring security against collusion among robots holding substantial stakes. Furthermore, current research has highlighted scalability and decentralization trade-offs, emphasizing the need for optimized frameworks specifically designed for swarm robotics applications [ 9 ]. Recent researches have also proposed Raft algorithm [ 10 ], a voting-based consensus algorithm, and its variants because of its lightweight nature. But they fail to meet necessary aspects like context-based activity validation, optimized leader election and communication overheads of swarm robotic or drone applications. To address these challenges, our research is an important step towards creating new consensus algorithm suitable for Peer-to-Peer (P2P) network-based swarm robotic or drone systems [ 11 ]. As a result, we have developed a Voting-based Blockchain-Raft specific consensus mechanism designed explicitly to integrate Blockchain technology with swarm robotics that enables efficiency, decentralized context-oriented security, and scalability aspects of the P2P network-based swarm applications [ 12 ]. Rest of the paper is organized into following sections. Firstly, Related Works section briefly discusses other research works related to Raft based consensus and their current gaps or scope for further improvements. The Problem Statement section clearly defines the challenges our research is aimed to address. The Methodology section explains the approach and the experiment setup of the newly developed solution to address the identified gaps. This section also highlights the significance of our solution compared to other related works. The Results Discussion section discusses the results of simulations that validate the effectiveness of our newly developed solution. Finally, Conclusion section summarizes the findings based on the results and highlights the novelty of our solution for swarm robotics applications. 2 Related Works The Raft algorithm integration with robotic networks is still relatively new, and ongoing research continues to refine its effectiveness, security, and applicability with decentralized robotic systems. This section briefly analysis other research works related to Raft based variants introduced in last 2 years. The authors of [ 13 ] proposes a VSSB-Raft algorithm combining original Raft algorithm with zero trust principles for general blockchain networks. However, introduction of supervisor nodes, SM2 signature algorithm for authentication and Named Data Networking (NDN) framework for node communication increases complexity. Moreover, as per the model presented, this algorithm is primarily targets general blockchain networks for client server architecture rather than decentralized P2P network. RaBFT algorithm proposed in [ 14 ] combines the Raft with Byzantine Fault Tolerance (BFT) and Schnorr signature mechanisms to improve the reliability and security of consensus processes. It introduced a new role of a committee to the leader election algorithm and to share the communication burden of the leader node thus increasing the complexity of the lightweight Raft algorithm. This model required further improvements on performance on log replication, reliability on the newly introduced committee role and scalability of the network. The Raftlet model introduced in [ 15 ] uses notarization process to validate the blocks proposed by the leader of the term. Minimum two-third of the network nodes must approve the proposal after verifying if the block is part of the longest chain. Further, to finalize any proposed block, three consecutive leaders must propose the two successive previously accepted blocks along with new block proposal. The notarization process and repeated block proposal and validation creates network overhead thus reducing the throughput. Moreover, the changes made to the leader election process based on hash function reduces the fairness in leader election for any follower nodes of the network. Authors of [ 16 ] introduces changes to the leader election process and log synchronisation status check to address some of the basic challenges that are part of original Raft algorithm. According to this model, leader election validation is done based on the runtime profile (number of nodes) of the swarm which makes it more realistic rather than pre-configuration. It also proposes changes to add two additional return values from follower nodes to confirm the log sync status of each follower node. Despite these enhancements, this model doesn’t consider to solve the default byzantine condition which is a major security issue. The original version of Raft [ 17 ] algorithm is primarily intended to synchronise the server state within the cluster environment in a client server architecture. By design, Raft states three distinct roles: Leader, Follower, and Candidate for its nodes. The cluster nodes using Raft algorithm can assume one of these three roles. Leader of the cluster is selected using vote-based election process. Once a server transition from follower to candidate role, it will initiate the election process for the next term triggered by random timeout method and soliciting votes from other follower servers in the cluster. Followers will vote to candidates on first come first server basis. Candidate received majority of votes will become leader of that term. The leader manages state synchronisation process through log replication and sends regular heartbeats to maintain its leadership role. Follower servers will accept the state from the leader by verifying the term and log indexes thus achieving consensus in the cluster network. But, as discussed in [ 18 ], Raft algorithm has limitations in election efficiency because of frequent elections. While many recent researches [ 13 – 15 ] proposed improvements to the original Raft algorithm, it still falls short to meet the requirements of P2P based swarm applications. In summary, though the above discussed variants of Raft contribute to improve the original Raft, the holistic picture of swarm network requirements are still not addressed at large. Notable, these consensuses algorithms are yet to realize the context-based network security aspect in the swarm robot or drone network environment. 3 Problem Statement By comparing all the approaches discussed in the Related Works section, it is evident that the original Raft and its variants are fall short to meet the specific needs of fully decentralized swarm robotic or drone applications. Current solutions are; Not providing require security to prevent byzantine actors in the network. Not efficient enough to perform context-based task or transaction validation using minimal computational capacity available in the small robots or drones. Not supporting the scalability requirements of the swarm network when number of network nodes grow bigger. Our current research is a significant step towards addressing the above stated challenges. 4 Methodology As proposed in my earlier work [ 12 ], the aim of this research is to address the identified gaps and create a suitable solution to use Blockchain with swarm robotic or drone systems by eliminating unwanted complexities associated with various layers of the current blockchain architecture. Inline to this objective, we have developed Rotational Leadership Role (RLR), a Raft based consensus algorithm along with Decentralized Task Authorization and Validation (DeTAV), a token-based task validation method. The primary objectives of this solution are to; Enhance the efficiency of the overall network through changes to the original Raft leader election process. Improve the network security to restrict the malfunctioning and malicious (byzantine) nodes from participating in network activities by introducing context-based activity validation and Provide required scalability by reducing unwanted communication overheads and remove unwanted complexities in the consensus process. Rest of this section discusses the working principles of RLR and DeTAV algorithms, explains the experiment setup and finally describes the simulator used to validate our solution. 4.1 Rotational Leadership Role (RLR) The idea of RLR is to develop an efficient algorithm to streamline and optimise the consensus process between nodes (robots or drones) in a swarm network environment. As shown in Fig. 1 below, RLR, an enhanced consensus algorithm based on Raft voting approach, is tailored explicitly for swarm robots or drone systems. It’s light-weight design makes it suitable to run within the limited computing resources available in any small robot or aerial drone. It also reduces network overhead and improves fault tolerance properties of the swarm network by incorporating the following improvements. Standardising term duration: In the original Raft algorithm network participants can start term elections if they don't receive heartbeat message from the term leader within its individual election timeout duration. By ignoring the leader's heartbeat message or its election timeout duration, a byzantine node can continuously initiate elections that leads to send out flood of vote requests to all nodes to stall the network operations. To address this issue, the leader term duration between the elections in RLR is standardised to a configurable duration. So that any malicious candidate’s election request within a valid term duration while current term leader is live, will be ignored by all the followers. But all the legitimate followers in the network will monitor the leader’s health for contingency by listening its heartbeat messages. Graceful leadership change: As per the Raft design, leader can hold on to its role as long as it could send heartbeat messages continuously without fail or delay within the random election timeout period of the followers. This scenario may lead to monopoly situation in the network. To avoid this and ensure fairness in leadership election, in RLR, all the followers will keep track of leader term duration while monitoring the leader’s health. Under normal conditions, leader will send out stepdown status through its heartbeat message at the end of its term. This triggers the random election timeouts of the followers to initiate elections for the next term. The successful candidate takes over the leadership role for the next term from the current leader. Under byzantine conditions, if leader is not sending stepdown message and trying to hold on to the leader role, followers will forcefully end the term by starting elections following its standardised election timeout duration. This ensures no leader can stay beyond its permitted term duration. Fareness in elections: By default, Raft design allows leaders to participate in subsequent (immediate next) election to continue the leader role if elected. A byzantine leader can start next election before the end of standardised term duration without waiting for its election timeout duration. This will also lead to monopoly situation in the network. To ensure equal opportunity to all other followers to become candidate and initiate election, leader of current term will be barred from taking part in immediate next election. Protection against vote manipulations: During the election phase, byzantine candidate may manipulate the vote response from followers in an attempt to became leader. To prevent this, followers sign their vote response to ensure the authenticity. In parallel, followers will share the same vote response to the current leader. This enables two-way consolidated vote response verification by the candidate as well as the current leader of the term. Further, during block creation cycle, all these vote requests will be verified before accepting the block. Blacklist malfunctioning or malicious actors: As explained in the DeTAV request validation process, malfunctioning or malicious participants of the swarm network will be blacklisted as part of request authorisation process preventing them from becoming the term leader. The original Raft algorithm doesn’t have such mechanism to prevent malevolent acters becoming term leader. Furthermore, RLR is designed to use a configurable and dedicated port to support the leadership related services. This model segregates the leader node functions which leads to reduction of network traffic in the default port used to support the original objective of the network. To reduce the network latency further, the log append entry request has been tailored to broadcast newly created blocks by the leader in equal intervals. By incorporating the above changes in the RLR, issues related to election process of the original Raft design has been fixed. Network performance has been improved by reducing communication overheads and network latency. 4.2 Decentralized Task Authorization and Validation (DeTAV) As discussed in the Problem Statement section above, the context-based validation is the primary gap while integrating Blockchain platform with swarm robotics network. Without the knowledge about the original objective of the swarm network, appropriate activity or transaction validation is not possible. DeTAV mechanism is designed to address this gap. At its core this design enhances the swarm network security using two tier token-based task authorization and validation method. Following steps explains this request validation process in detail. Irrespective of the Raft role, all the robots or drones of the P2P network are referred as nodes of the network. When a node communicates in such network, all other nodes of the network is referred as peers. When network is initiated, network objectives will be recorded as part of the Genisis block of blockchain while initiating the blockchain storage. Network objectives will have all legitimate mappings or task assignments. All the nodes of the network will be issued with a service granting token with a unique ID representing each individual node in the network. Once the network is started, the node responsible for performing a particular task, will generate a single use token using its granting token issued, valid only for a very short (configurable) duration, representing the task and broadcast it to the network for validation. Once received the token, peers of the network will perform the context-based validation against the network’s objective and the authorisation is granted to the requested node. When majority of the peers agreed on the request after validation, the node is allowed to perform its task within the network. Under byzantine condition, if a malfunctioning or malicious node raises any requests that is not aligned of the original objective of the network or not within the scope of the authorisation granted for that node, the peer validation will fail and hence the node will not be allowed to perform its task or it will be intervened by other nodes as part of the built-in prevention mechanism. The robots requesting authorisation for any invalid activities will be blocklisted to prevent them from becoming term leader. Leader of the term will record all these activities as transactions of the new block and publish it in the network to peers. Leader will also notify the network about any invalid requests raised by malfunctioning or malicious nodes thus enhancing the swarm network security. Peers will validate the transactions of the proposed new block against its local record of transactions before adding it to the local Blockchain. Below mathematical equation expresses the correlation between granting token and the single use token generated based on the granting token withing the timeframe of the swarm network session. $$\:{T}_{S}={\sum\:}_{i=1}^{n}{O}_{i}$$ Where: T s ​ = Service Granting token ID. O i ​ = One-time token generated at instance i. n = Total number of one-time tokens generated for Ts in a session. RLR along with DeTAV mechanism ensures that the consensus is achieved in the swarm network is achieved in an efficient, secured and lean way thus making the newly developed consensus algorithm most suitable for futuristic swarm networks. 4.3 Experiment Setup As depicted in Fig. 2, a swarm robotic experimental setup has been designed to demonstrate the capabilities of the Rotational Leadership Role (RLR) and Decentralized Task Authorization and Validation (DeTAV) based consensus algorithm in a Blockchain network suitable for swarm network. The flow of events depicted in the below flow chart in Fig. 3, explains the sequence of tasks performed by each robot in the setup shown in Fig. 2. In this experimental setup, a P2P based decentralised swarm robotic network is integrated with Blockchain platform that uses RLR to reach consensus among the robots and DeTAV to valid tasks performed by each robot in the network. There are three robots R1, R2, and R3 standing at their respective robot stations and four positions A, B, C, and D that can hold a ping pong ball. The objective of this network is to move a ping pong ball sequentially from position A to B, and then from B to C. Robot R1 is assigned to shift the ping pong ball from position A to B. Similarly, R2’s task is to shift the ball from position B to C. Robot R3 will act as a malicious intruder. Once the network started, all the nodes will be issued with a service granting token that encapsulates a task along with a unique ID representing each individual robot, station and the position in the network. Then, for the first time, the network will go for leader election based on timeout configurations. At this point of time, the participants of the network will start to perform their tasks as per the network configuration explained above. 4.4 Simulator A software-based robotic network simulator has been developed using Java 18 to validate the capabilities of newly developed RLR consensus algorithm with DeTAV validation algorithm in a swarm network similar to the experiment setup shown in Fig. 2. The scenario shown in Fig. 4 is the exact replication of the experiment shown in Fig. 2 highlighting features needed to run the simulation test under various scenarios. Simulator will create a P2P network between all the nodes shown in this network. The robots in this simulator will travel along the lines in the direction of the arrows indicating the normal or expected travel path in the circuit. Using the controls at the bottom panel, various test scenarios can be created and start / stop the backend P2P network. Using the controls proved in left panel, the robotic movement can be controlled. Right panel of the simulator will provide the essential RAM and CPU usage statistics while running the experiments. As explained in the Results Discussion section, we have used this simulator to simulate various test scenarios with multiple tests runs and load conditions. Fig. 5 below shows the robots in action in maximum load configuration with possible byzantine condition in continuous loop mode. Using the list of robot names provided directly under each circuit, malfunctioning and malicious intruding robots in the swarm network can be simulated. A blockchain based P2P network has been developed. It is seamlessly integrated with the RLR and DeTAV algorithms for consensus and transaction validations with the simulator as frontend to simulate the network activities. Blockchain architecture has been covered in detail in my paper [ 12 ]. At the core, this network follows basic blockchain architecture using SHA-256 hashing algorithm, RSA algorithm for asymmetric public / private key pair generation and SHA256withRSA algorithm for transaction signing and verification. At the beginning of each session, network objectives based on the configured scenario will be stored in this blockchain as Genisis block. As explained in the RLR section, vote based election will be conducted to select new term leader following the election configuration. The term leader will create new blocks with valid transactions at configured equal interval. If no valid transaction is recorded in the recent interval, block creation activity will be suspended. This will help to minimise the communication overhead and reduce network latency. At the receiving end, all the peers will compare each transaction of the new block with their local store before adding the new block into their local chain. 5 Test Strategy The aim of the testing is to validate the capabilities of RLR and DeTAV algorithms using our simulator to do experiments and by comparing these experiment results with other well-known and applicable consensus algorithms in terms of efficiency, security and scalability aspects and assess its suitability for swarm robotics or drone network based on the results. 5.1 Comparison with PoW We are comparing RLR with PoW, a well-known blockchain based consensus algorithm, primarily to understand the vast performance difference in RAM & CPU usage metrics between these two algorithms, making PoW not suitable for swarm network. 5.2 Exclusion of PoS We are not comparing the RLR with PoS as the later algorithm is mainly based on percentage of stake hold by individual node of the network. But, by basic working principles, all the nodes of swarm network are considered having equal stake in the achieving the objective, even though they perform different roles in the network. Thus, stake-based consensus will be irrelevant for swarm network. 5.3 Comparison with existing research works Experiment results of RLR will be compared with the existing research work results published recently in [ 14 ]. Authors have done a great job by comparing various consensus algorithms on useful metrics. The primary purpose of this results comparison is to evaluate RLR’s performance metrics with recently published similar voting-based algorithm. Below listed metrics will be compared at various load conditions as shown in the graphs to assess and understand the efficiency of RLR and DeTAV implementation. Number of transactions per second (TPS) to assess the network performance. Consensus latency to assess the distributed consistency and security of task validation process. Election latency to assess the efficiency and scalability in the election process. Quality of Detection to assess security of the fault tolerance mechanism. 6 Results Discussion To establish a testing environment, we have used a Windows PC equipped with an Intel i7 16-Core Ultra 7 155H 3.80 GHz processor and 16GB RAM hardware configuration. To validate the capabilities of RLR and DeTAV algorithms, we conducted all the tests discussed in the Test Strategy using our simulator to simulate normal and byzantine conditions with sequential and parallel test scenarios. Test runs were performed in the localhost environment assigning different ports for each node. Experiments were conducted covering 8 test scenarios with 14 different load conditions (5 to 70 nodes with the increment of 4/5/10 per run). Each test run was repeated at an average of 5 times using our RLR and DeTAV solution. We have also conducted test run using PoW algorithm with suitable test scenarios. A total of 840 test runs were conducted and the results were compared with PoW and with the existing research results published in [14] to compare our RLR and DeTAV with VBBS [13], RaBFT [14], Raft [17] algorithms. 6.1 Comparison with PoW Proof of Work (PoW) algorithm was integrated with our simulator to perform comparative test runs with difficulty value of 21. Figure 6 shows the CPU and RAM usage of PoW and RLR algorithms of similar test runs. The results shows that RLR’s CPU and RAM usage is consistently lower throughout the test runs. Compared to RLR, the rapid increase in recourse usage of PoW leads to a wider percentage difference between these 2 algorithms. During peak load testing with 70 network nodes, RLR used under 100MB RAM and 12.5% CPU, while PoW exceeded 450MB RAM and 25% CPU, showing a 500% RAM and 173% CPU reduction by using RLR. This test result proves that PoW based algorithms are not suitable to run within the limited resources of swarm robots or drones. This result also confirms that our RLR based on Voting-based algorithm is the ideal approach to support secure swarm network. Further to this test we’ll compare all our test results with the existing research results published in [14] to compare the performance of our RLR with Raft, VBBS, RaBFT algorithms. We have replicated the metrics based on the graphs in [14] using AI based online graph reading tools to get maximum possible accuracy of the data set. 6.2 Throughput For any consensus algorithm and its base network, data throughput is a vital metric for assessing its suitability to swarm network. This is measured in terms of number of transactions that a network can successfully handle per unit of time typically represented by Transactions Per Second (TPS). We’ll be comparing RLR’s TPS with the results of Raft, VBBS and RaBFT algorithms published in [14] as shown in the Fig. 7 below. Using our simulator, throughput test was conducted with load configurations as shown in the graph. The result shows that our RLR algorithm has achieved an average of approximately 144% increase in throughput compared to Raft, 58% increase compared to VSSB-Raft and 32% increase compared with the RaBFT algorithm as per the published results of [14]. While RaBFT, VSSB-Raft and Raft algorithms records lower throughput with more nodes, RLR maintains an observable lead, showing s RLR’s higher scalability nature to support larger P2P networks compared to the other algorithms tested. 6.3 Consensus Latency Under Normal Condition Purpose of latency test is to measure the time delay between the request and its corresponding response in the network. This test is crucial to determine the response time required by the consensus algorithm between validation request submission and achieving consensus on the request. Using our simulator, under ideal conditions without any malfunctioning or malicious nodes in the network, we have conducted multiple tests with varying number of nodes to measure the consensus response time of RLR in comparison with RaBFT, VBBS, Raft algorithms as shown in the graph Fig. 8 below. Based on the result of the comparison experiments, it is evident that RLR’s overall average latency (response time), without any byzantine conditions, is approximately 34% less compared to other algorithms as per the published results of [14]. Individually, RLR’s consensus latency is approximately 51% less compared to Raft, 30% less compared to RaBFT and 20% less compared to VSSB-Raft algorithm. 6.4 Consensus Latency Under Byzantine Condition Using our simulator, we have repeated the latency test run with the load similar to previous latency experiment to test RLR’s latency in the presence of 1/4th and 1/3rd malfunctioning or malicious nodes of the total load. These test results are compared with the result of RaBFT algorithm’s latency results in the presence of 1/4rd byzantine nodes of the total load. As shown in Fig. 9 below, RLR’s average latency with 1/3rd byzantine nodes is approximately 28% less than RaBFT’s average latency with 1/4th byzantine nodes as per the results of [14]. This demonstrates that our RLR consensus algorithm can handle higher number of byzantine nodes with less latency in the network. 6.5 Leader Election Latency As discussed at the beginning of the Methodology section, DeTAV task validation algorithm, as part of our RLR consensus, has enhanced the consensus as a context aware process along with security enhancements. To assess the efficiency of this algorithm, we have conducted election latency test using our simulator with varying load conditions as shown below in Fig. 10. RLR’s average election latency is approximately 47% less compared to other algorithms as per the published results of [14]. Individually, RLR’s election latency is approximately 51% less compared to VSSB-Raft, 48% less compared to Raft and 42% less compared to RaBFT algorithm. The less latency in the election process proves that RLR is capable of handling larger networks without much delays in the decentralised decision-making process. 6.6 Quality of Detection To evaluate the security of consensus algorithms the Quality of Detection (QoD) was introduced in [19]. This metric compares the total time taken for reaching consensus in a network with the time needed to identify and isolate malfunctioning or malicious nodes in that network. To assess the Byzantine fault tolerance capability of our RLR algorithm, we have conducted test runs with a total of 40 network nodes. Using our simulator, gradually we simulated the network with 10%, 20% and 30% malfunctioning or malicious behaviour nodes into the network to validate the fault detection and tolerance capability of RLR with DeTAV algorithms. Below results in Fig. 11 shows a stable and linear performance by RLR to identify and insolate byzantine nodes in the network. Even with 30% byzantine nodes configuration, RLR’s percentage of time to handle byzantine nodes compared to the time taken for reaching consensus in the network is 67% less compared to RaBFT algorithm as per the result published in [14]. This experiment results illustrates that RLR’s reliability in byzantine fault tolerance even in bigger networks. 7 Conclusion As technology progresses towards advancements, decentralise network applications like swarm robotics or drones are becoming more complex. While variants of PoW and PoS were proven as not suitable for swarm networks, Raft, a light weight consensus algorithm, is facing fundamental problems such as low election efficiency, frequent elections and unreliable term durations. As discussed in Related Works section, the variants of Raft algorithm have its own limitations in meeting fully decentralised swarm network requirements. Moreover, context-based transaction or task validation mechanism was considered as major gap in providing required network level security. Our research is primarily focused on eliminating these gaps and the unrealistic complexities in decentralised network consensus process and embrace a voting based secured consensus with context-based validation and fault tolerance in swarm network. As a result, we developed RLR as a light weight consensus algorithm capable of running withing the limited resources of the swarm network devices. DeTAV validation algorithm is a component of RLR to validate transactions or tasks inline to the objectives of the network. The RLR election process is designed to enhance election efficiency and security and tolerate follower, candidate and leader roles related byzantine fault conditions. This design has been fine tuned to minimize communication overheads and improve throughput of the swarm network. By introducing asymmetric key based transaction signing and verification mechanism along with context-based transaction validation, the security aspect of the network has been improved further. The CPU and RAM utilisation test proves that PoW based consensus is not suitable for swarm network. The comparative experiment result illustrates RLR’s higher scalability with an average of 78% higher throughput, superior efficiency with 47% lesser election latency and 34% lesser consensus latency and proving its network security with 100% success in malfunction or malicious node detection in 67% lesser QoD time. These metrics have clearly demonstrated the superior capabilities of our RLR and DeTAV algorithms to address the efficiency, security and scalability needs of the swarm robotic or drone network as defined in our objectives of this research. By integrating our RLR and DeTAV algorithms with P2P decentralised swarm robotics or aerial drone networks makes them more futuristic and enable these networks to handle complex and dynamic requirements. Declarations Author contributions Sathishkumar R. Performed analysis, defined the methodology, conducted research experiment, studied results and wrote the manuscript. Muralindran M. and Karthigayan M. Guided and supervised research, reviewed manuscript draft, and approved the final manuscript. All authors proofread the revised manuscript for typos and grammatical mistakes. Funding There was no funding. Data availability The datasets prepared and/or analysed during the current research work are available from the corresponding author upon reasonable request. Ethics approval and consent to participate Not applicable . Consent for publication Not applicable . Competing interests The authors declare no competing interests. Additional information Correspondence and requests for materials should be addressed to corresponding author Muralindran M., [email protected] . Open Access This article is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, which permits any non-commercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this article or parts of it. The images or other third-party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. References Folgado FJ, Calderón D, González I, Calderón AJ. Review of Industry 4.0 from the perspective of automation and supervision systems: Definitions, architectures and recent trends. Electronics. 2024 Feb 16;13(4):782. https://doi.org/10.3390/electronics13040782 Ikumapayi, O.M., Laseinde, O.T., Elewa, R.R., Ogedengbe, T.S. and Akinlabi, E.T. Swarm Robotics in a Sustainable Warehouse Automation: Opportunities, Challenges and Solutions. E3S Web of Conferences 2024, 552: 01080. https://doi.org/10.1051/e3sconf/202455201080 Dias PG, Silva MC, Rocha Filho GP, Vargas PA, Cota LP, Pessin G. Swarm robotics: A perspective on the latest reviewed concepts and applications. Sensors. 2021 Mar 15;21(6):2062. https://doi.org/10.3390/s21062062 Queralta JP, Westerlund T. Blockchain-powered collaboration in heterogeneous swarms of robots. arXiv preprint 2019 Nov 23. arXiv:1912.01711. https://doi.org/10.48550/arXiv.1912.01711 Strobel V, Pacheco A, Dorigo M. Robot swarms neutralize harmful Byzantine robots using a blockchain-based token economy. Science Robotics. 2023 Jun 28;8(79):eabm4636. https://doi.org/10.1126/scirobotics.abm4636 Aditya US, Singh R, Singh PK, Kalla A. A survey on blockchain in robotics: Issues, opportunities, challenges and future directions. Journal of Network and Computer Applications. 2021 Dec 15;196:103245. https://doi.org/10.1016/j.jnca.2021.103245 Sapra N, Shaikh I, Dash A. Impact of proof of work (PoW)-Based blockchain applications on the environment: a systematic review and research agenda. Journal of Risk and Financial Management. 2023 Mar 31;16(4):218. https://doi.org/10.3390/jrfm16040218 Hu Q, Yan B, Han Y, Yu J. An improved delegated proof of stake consensus algorithm. Procedia Computer Science. 2021 Jan 1;187:341-6. https://doi.org/10.1016/j.procs.2021.04.109 Ferrer EC. If blockchain is the solution, robot security is the problem. Frontiers in Blockchain. 2023 May 16;6:1181820. https://doi.org/10.3389/fbloc.2023.1181820 Du Z, Qu Z, Fu Y, Huang M, Liu L. Multi‐strategy‐based leader election mechanism for the Raft algorithm. Concurrency and Computation: Practice and Experience. 2023 Oct 10;35(22):e7734. https://doi.org/10.1002/cpe.7734 Ranganathan S, Mariappan M, PG KM. Design methodology for using blockchain in swarm robotics. In2021 IEEE 19th Student Conference on Research and Development (SCOReD) 2021 Nov 23 (pp. 76-81). IEEE. https://doi.org/10.1109/SCOReD53546.2021.9652778 Ranganathan S, Mariappan M, Muthukaruppan K. Efficient distributed consensus algorithm for swarm robotic. In2022 IEEE International Conference on Artificial Intelligence in Engineering and Technology (IICAIET) 2022 Sep 13 (pp. 1-6). IEEE. https://doi.org/10.1109/IICAIET55139.2022.9936787 Tian S, Bai F, Shen T, Zhang C, Gong B. Vssb-raft: a secure and efficient zero trust consensus algorithm for blockchain. ACM Transactions on Sensor Networks. 2024 Jan 9;20(2):1-22. https://doi.org/10.1145/3611308 Bai F, Li F, Shen T, Zeng K, Zhang X, Zhang C. RaBFT: an improved Byzantine fault tolerance consensus algorithm based on raft. The Journal of Supercomputing. 2024 Sep;80(14):21533-60. https://doi.org/10.1007/s11227-024-06284-6 Takehana C, Lim D, Sharma S. Raftlet: A Byzantine Fault Tolerant Raft. Raftlet_A_Byzantine_Fault_Tolerant_Raft.pdf Zhang Y, Cui G, Sui W. A Raft Consensus Algorithm Modification for Adapting Frequent Leader Switch in Multi-agent Swarm Robotics Applications. InInternational Conference on Guidance, Navigation and Control 2024 Aug 9 (pp. 618-629). Singapore: Springer Nature Singapore. https://doi.org/10.1007/978-981-96-2204-7_59 Ongaro D, Ousterhout J. In search of an understandable consensus algorithm. In2014 USENIX annual technical conference (USENIX ATC 14) 2014 (pp. 305-319). atc14-paper-ongaro.pdf Jafar U, Aziz MJ, Shukur Z. Blockchain for electronic voting system—review and open research challenges. Sensors. 2021 Aug 31;21(17):5874. https://doi.org/10.3390/s21175874 Zhang X, Miao X, Xue M. A Reputation‐Based Approach Using Consortium Blockchain for Cyber Threat Intelligence Sharing. Security and Communication Networks. 2022;2022(1):7760509. https://doi.org/10.1155/2022/7760509 Additional Declarations No competing interests reported. Cite Share Download PDF Status: Published Journal Publication published 12 Feb, 2026 Read the published version in Discover Computing → Version 1 posted Editorial decision: Revision requested 29 Sep, 2025 Reviews received at journal 04 Aug, 2025 Reviews received at journal 25 Jul, 2025 Reviews received at journal 24 Jul, 2025 Reviewers agreed at journal 24 Jul, 2025 Reviewers agreed at journal 24 Jul, 2025 Reviewers agreed at journal 23 Jul, 2025 Reviewers agreed at journal 23 Jul, 2025 Reviewers agreed at journal 23 Jul, 2025 Reviews received at journal 01 Jul, 2025 Reviewers agreed at journal 01 Jul, 2025 Reviews received at journal 30 Jun, 2025 Reviewers agreed at journal 30 Jun, 2025 Reviewers agreed at journal 29 Jun, 2025 Reviewers agreed at journal 25 Jun, 2025 Reviewers invited by journal 24 Jun, 2025 Editor invited by journal 20 Jun, 2025 Editor assigned by journal 07 Jun, 2025 Submission checks completed at journal 07 Jun, 2025 First submitted to journal 03 Jun, 2025 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-6810291","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":476302590,"identity":"41a14914-670c-4c67-bc06-cae909288b24","order_by":0,"name":"SATHISHKUMAR RANGANATHAN","email":"","orcid":"","institution":"Universiti of Malaysia Sabah","correspondingAuthor":false,"prefix":"","firstName":"SATHISHKUMAR","middleName":"","lastName":"RANGANATHAN","suffix":""},{"id":476302591,"identity":"71bc1852-ed9e-45a8-b27d-83d755613786","order_by":1,"name":"Muralindran Mariappan","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAuElEQVRIiWNgGAWjYLCCBwY2EAYP0VoSDNJI1sJwmAQtujNyH35IKDifuLb/AOODt20M0QYHCGgxu5FuLJFgcDtx240EZsO5bQy5GwhrSWOAamFgk+YlUgvzjwSDc4nbzh9g/02sFjagLQcStx1IYGMmTsuZZ2wWCQbJxttuJDZLzjknkTuToJbjacw3Pvyxk912/vDBD2/KbHL7CGlBAowNQEKCQYEELVAg30CyllEwCkbBKBjmAAAPJUbSHpoaZwAAAABJRU5ErkJggg==","orcid":"","institution":"Universiti of Malaysia Sabah","correspondingAuthor":true,"prefix":"","firstName":"Muralindran","middleName":"","lastName":"Mariappan","suffix":""},{"id":476302592,"identity":"6d7fc84c-2ebf-4728-8153-dcde183f77c0","order_by":2,"name":"Karthigayan Muthukaruppan","email":"","orcid":"","institution":"ASRIX PRIME BERHAD","correspondingAuthor":false,"prefix":"","firstName":"Karthigayan","middleName":"","lastName":"Muthukaruppan","suffix":""}],"badges":[],"createdAt":"2025-06-03 10:38:28","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-6810291/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-6810291/v1","draftVersion":[],"editorialEvents":[{"content":"https://doi.org/10.1007/s10791-026-09951-9","type":"published","date":"2026-02-12T15:58:15+00:00"}],"editorialNote":"","failedWorkflow":false,"files":[{"id":85486377,"identity":"2c4cbc99-a43b-41a3-b56a-5758d38afd48","added_by":"auto","created_at":"2025-06-26 12:08:07","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":66575,"visible":true,"origin":"","legend":"\u003cp\u003eLeadership Election Process [12].\u003c/p\u003e","description":"","filename":"floatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/218f5da8c4c0f4d1415d1b39.png"},{"id":85486380,"identity":"4eaf2901-f0e0-4cce-b6c4-dce045243b1a","added_by":"auto","created_at":"2025-06-26 12:08:08","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":148247,"visible":true,"origin":"","legend":"\u003cp\u003eSwarm robotics experiment setup with Blockchain integration [12].\u003c/p\u003e","description":"","filename":"floatimage2.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/096c686d9e429850aeebac84.png"},{"id":85488520,"identity":"8fdf2c2a-05ab-4136-adad-99e7d69b778a","added_by":"auto","created_at":"2025-06-26 12:32:21","extension":"jpeg","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":128712,"visible":true,"origin":"","legend":"\u003cp\u003eFlow of events for Fig. 2 [12].\u003c/p\u003e","description":"","filename":"floatimage3.jpeg","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/933f4b9cafb65289bf3acb7f.jpeg"},{"id":85486392,"identity":"5121fddc-ff56-43e4-81b2-df3f77370683","added_by":"auto","created_at":"2025-06-26 12:08:08","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":32787,"visible":true,"origin":"","legend":"\u003cp\u003eSoftware simulator developed to conduct experiment shown in Fig. 2.\u003c/p\u003e","description":"","filename":"floatimage4.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/81c6b8e948e4cc0a0663bdfa.png"},{"id":85486396,"identity":"7c65f886-05d4-487a-8b33-5c4ec35f6f84","added_by":"auto","created_at":"2025-06-26 12:08:08","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":85472,"visible":true,"origin":"","legend":"\u003cp\u003eSoftware simulator with maximum load and all possible byzantine scenarios.\u003c/p\u003e","description":"","filename":"floatimage5.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/7021507de19d912961d99011.png"},{"id":85487121,"identity":"0b0256e0-6fac-4bc8-84aa-0d297dedd668","added_by":"auto","created_at":"2025-06-26 12:16:08","extension":"jpg","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":46825,"visible":true,"origin":"","legend":"\u003cp\u003eCPU and RAM Usage of PoW \u0026amp; RLR algorithms during peak load test.\u003c/p\u003e","description":"","filename":"floatimage6.jpg","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/a2de60d5647b5cdf81c4e2a3.jpg"},{"id":85487690,"identity":"e8ce75fa-a758-41bd-826c-007f0dfdc2f7","added_by":"auto","created_at":"2025-06-26 12:24:20","extension":"png","order_by":7,"title":"Figure 7","display":"","copyAsset":false,"role":"figure","size":42786,"visible":true,"origin":"","legend":"\u003cp\u003eRLR TPS comparison with replicated data published in [14].\u003c/p\u003e","description":"","filename":"floatimage7.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/f6ee52552251dccfed36c631.png"},{"id":85486397,"identity":"435f8f51-f7a6-47b3-97ff-5a624511b97a","added_by":"auto","created_at":"2025-06-26 12:08:08","extension":"png","order_by":8,"title":"Figure 8","display":"","copyAsset":false,"role":"figure","size":68991,"visible":true,"origin":"","legend":"\u003cp\u003eRLR consensus latency comparison with the data published in [14].\u003c/p\u003e","description":"","filename":"floatimage8.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/b7cd7a32cfd765ded77d6f6b.png"},{"id":85487122,"identity":"0d92d044-319d-469c-97fd-e10445d8ca89","added_by":"auto","created_at":"2025-06-26 12:16:08","extension":"png","order_by":9,"title":"Figure 9","display":"","copyAsset":false,"role":"figure","size":47924,"visible":true,"origin":"","legend":"\u003cp\u003eRLR consensus latency with byzantine nodes comparison with replicated data published in [14].\u003c/p\u003e","description":"","filename":"floatimage9.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/36b529ba3db2cb710baba348.png"},{"id":85486398,"identity":"f0252ace-ef3a-4527-9c59-fe94ab2c3b34","added_by":"auto","created_at":"2025-06-26 12:08:09","extension":"png","order_by":10,"title":"Figure 10","display":"","copyAsset":false,"role":"figure","size":52172,"visible":true,"origin":"","legend":"\u003cp\u003eRLR election latency comparison with replicated data published in [14].\u003c/p\u003e","description":"","filename":"floatimage10.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/eacd5cc297ae924cc1a59142.png"},{"id":85486382,"identity":"2d7b22af-81b8-468f-b215-aaf24f27586c","added_by":"auto","created_at":"2025-06-26 12:08:08","extension":"png","order_by":11,"title":"Figure 11","display":"","copyAsset":false,"role":"figure","size":57462,"visible":true,"origin":"","legend":"\u003cp\u003eRLR QoD result comparison with replicated data published in [14].\u003c/p\u003e","description":"","filename":"floatimage11.png","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/41db4edba9a3254717ebe1da.png"},{"id":102785592,"identity":"c2a34bae-fdd3-4e20-b534-e7b2807d38a3","added_by":"auto","created_at":"2026-02-16 16:08:34","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1405512,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-6810291/v1/40ed347d-73b6-438f-b1a9-af85ce726850.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"Smarter Swarms: Empirical Assessment of Blockchain-Based RLR and DeTAV Algorithms in Swarm Network","fulltext":[{"header":"1 Introduction","content":"\u003cp\u003eIndustry 4.0 represents a significant transformation of the industrial sector, integrating advanced digital technologies such as IoT, cyber-physical systems, AI, and cloud computing into smart manufacturing or production processes [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e]. Recent advancements in this field emphasize merging traditional automation technologies with these constructive digital innovations to create intelligent, interconnected, and efficient industrial systems. As one of the vital pillars of Industry 4.0, the role of swarm robotics aligns with the industry's goal of decentralized intelligence, enabling robot swarms to enhance flexibility and efficiency within smart factories and automated warehouses [\u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e]. This multi-agent distributed network of autonomous robots collaborate in a decentralized manner, inspired by social insects like ants or bees. This innovative technology is capable of carrying out complex tasks for industrial applications like aerial surveillance, farming, marine operations, handling hazardous environments like space, and smart manufacturing processes [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e]. Recent developments shows that Blockchain technology is increasingly integrated with swarm robotics to overcome challenges in secure coordination and maintaining data integrity across decentralized robotic networks used in factories, automated warehouses, and critical operations [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eBlockchain's decentralized ledger and smart contracts have significantly enhanced tamper-proof data sharing without central authority oversight in token-based economies [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e]. However, substantial challenges remain, particularly concerning the efficiency in computational and energy requirements of blockchain algorithms, communication delays, and scalability within large robot swarms, necessitating the development of lightweight and optimized consensus mechanisms. Particularly, ensuring seamless interoperability between blockchain platforms and swarm robotic systems is also a key area of ongoing research [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eBlockchain integration in swarm robotics commonly employs consensus algorithms like Proof of Work (PoW) and Proof of Stake (PoS) based variants. Proof of Work (PoW), famously used in Bitcoin, provides robust security through solving computationally intensive cryptographic puzzles, which makes it less feasible for real-time robotic swarms due to its high computational demands and environmental impact [\u003cspan citationid=\"CR7\" class=\"CitationRef\"\u003e7\u003c/span\u003e]. In contrast, Proof of Stake (PoS) and Delegated Proof of Stake (DPoS) has emerged as another promising consensus approach, particularly due to its significantly lower energy requirements and computational demands compared to Proof of Work, by relying on validators' stakes to secure consensus [\u003cspan citationid=\"CR8\" class=\"CitationRef\"\u003e8\u003c/span\u003e]. Yet integrating PoS into swarm robotics brings its own complexities, particularly in managing stakes, validator selection, and ensuring security against collusion among robots holding substantial stakes. Furthermore, current research has highlighted scalability and decentralization trade-offs, emphasizing the need for optimized frameworks specifically designed for swarm robotics applications [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e]. Recent researches have also proposed Raft algorithm [\u003cspan citationid=\"CR10\" class=\"CitationRef\"\u003e10\u003c/span\u003e], a voting-based consensus algorithm, and its variants because of its lightweight nature. But they fail to meet necessary aspects like context-based activity validation, optimized leader election and communication overheads of swarm robotic or drone applications. To address these challenges, our research is an important step towards creating new consensus algorithm suitable for Peer-to-Peer (P2P) network-based swarm robotic or drone systems [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e]. As a result, we have developed a Voting-based Blockchain-Raft specific consensus mechanism designed explicitly to integrate Blockchain technology with swarm robotics that enables efficiency, decentralized context-oriented security, and scalability aspects of the P2P network-based swarm applications [\u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eRest of the paper is organized into following sections. Firstly, Related Works section briefly discusses other research works related to Raft based consensus and their current gaps or scope for further improvements. The Problem Statement section clearly defines the challenges our research is aimed to address. The Methodology section explains the approach and the experiment setup of the newly developed solution to address the identified gaps. This section also highlights the significance of our solution compared to other related works. The Results Discussion section discusses the results of simulations that validate the effectiveness of our newly developed solution. Finally, Conclusion section summarizes the findings based on the results and highlights the novelty of our solution for swarm robotics applications.\u003c/p\u003e"},{"header":"2 Related Works","content":"\u003cp\u003eThe Raft algorithm integration with robotic networks is still relatively new, and ongoing research continues to refine its effectiveness, security, and applicability with decentralized robotic systems. This section briefly analysis other research works related to Raft based variants introduced in last 2 years. The authors of [\u003cspan citationid=\"CR13\" class=\"CitationRef\"\u003e13\u003c/span\u003e] proposes a VSSB-Raft algorithm combining original Raft algorithm with zero trust principles for general blockchain networks. However, introduction of supervisor nodes, SM2 signature algorithm for authentication and Named Data Networking (NDN) framework for node communication increases complexity. Moreover, as per the model presented, this algorithm is primarily targets general blockchain networks for client server architecture rather than decentralized P2P network. RaBFT algorithm proposed in [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e] combines the Raft with Byzantine Fault Tolerance (BFT) and Schnorr signature mechanisms to improve the reliability and security of consensus processes. It introduced a new role of a committee to the leader election algorithm and to share the communication burden of the leader node thus increasing the complexity of the lightweight Raft algorithm. This model required further improvements on performance on log replication, reliability on the newly introduced committee role and scalability of the network.\u003c/p\u003e \u003cp\u003eThe Raftlet model introduced in [\u003cspan citationid=\"CR15\" class=\"CitationRef\"\u003e15\u003c/span\u003e] uses notarization process to validate the blocks proposed by the leader of the term. Minimum two-third of the network nodes must approve the proposal after verifying if the block is part of the longest chain. Further, to finalize any proposed block, three consecutive leaders must propose the two successive previously accepted blocks along with new block proposal. The notarization process and repeated block proposal and validation creates network overhead thus reducing the throughput. Moreover, the changes made to the leader election process based on hash function reduces the fairness in leader election for any follower nodes of the network. Authors of [\u003cspan citationid=\"CR16\" class=\"CitationRef\"\u003e16\u003c/span\u003e] introduces changes to the leader election process and log synchronisation status check to address some of the basic challenges that are part of original Raft algorithm. According to this model, leader election validation is done based on the runtime profile (number of nodes) of the swarm which makes it more realistic rather than pre-configuration. It also proposes changes to add two additional return values from follower nodes to confirm the log sync status of each follower node. Despite these enhancements, this model doesn\u0026rsquo;t consider to solve the default byzantine condition which is a major security issue.\u003c/p\u003e \u003cp\u003eThe original version of Raft [\u003cspan citationid=\"CR17\" class=\"CitationRef\"\u003e17\u003c/span\u003e] algorithm is primarily intended to synchronise the server state within the cluster environment in a client server architecture. By design, Raft states three distinct roles: Leader, Follower, and Candidate for its nodes. The cluster nodes using Raft algorithm can assume one of these three roles. Leader of the cluster is selected using vote-based election process. Once a server transition from follower to candidate role, it will initiate the election process for the next term triggered by random timeout method and soliciting votes from other follower servers in the cluster. Followers will vote to candidates on first come first server basis. Candidate received majority of votes will become leader of that term. The leader manages state synchronisation process through log replication and sends regular heartbeats to maintain its leadership role. Follower servers will accept the state from the leader by verifying the term and log indexes thus achieving consensus in the cluster network. But, as discussed in [\u003cspan citationid=\"CR18\" class=\"CitationRef\"\u003e18\u003c/span\u003e], Raft algorithm has limitations in election efficiency because of frequent elections. While many recent researches [\u003cspan additionalcitationids=\"CR14\" citationid=\"CR13\" class=\"CitationRef\"\u003e13\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR15\" class=\"CitationRef\"\u003e15\u003c/span\u003e] proposed improvements to the original Raft algorithm, it still falls short to meet the requirements of P2P based swarm applications. In summary, though the above discussed variants of Raft contribute to improve the original Raft, the holistic picture of swarm network requirements are still not addressed at large. Notable, these consensuses algorithms are yet to realize the context-based network security aspect in the swarm robot or drone network environment.\u003c/p\u003e"},{"header":"3 Problem Statement","content":"\u003cp\u003eBy comparing all the approaches discussed in the \u003cem\u003eRelated Works\u003c/em\u003e section, it is evident that the original Raft and its variants are fall short to meet the specific needs of fully decentralized swarm robotic or drone applications. Current solutions are;\u003c/p\u003e \u003cp\u003e \u003cul\u003e \u003cli\u003e \u003cp\u003eNot providing require security to prevent byzantine actors in the network.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eNot efficient enough to perform context-based task or transaction validation using minimal computational capacity available in the small robots or drones.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eNot supporting the scalability requirements of the swarm network when number of network nodes grow bigger.\u003c/p\u003e \u003c/li\u003e \u003c/ul\u003e \u003c/p\u003e \u003cp\u003eOur current research is a significant step towards addressing the above stated challenges.\u003c/p\u003e"},{"header":"4 Methodology","content":"\u003cp\u003eAs proposed in my earlier work [\u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e], the aim of this research is to address the identified gaps and create a suitable solution to use Blockchain with swarm robotic or drone systems by eliminating unwanted complexities associated with various layers of the current blockchain architecture. Inline to this objective, we have developed Rotational Leadership Role (RLR), a Raft based consensus algorithm along with Decentralized Task Authorization and Validation (DeTAV), a token-based task validation method. The primary objectives of this solution are to;\u003c/p\u003e \u003cp\u003e \u003cul\u003e \u003cli\u003e \u003cp\u003eEnhance the efficiency of the overall network through changes to the original Raft leader election process.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eImprove the network security to restrict the malfunctioning and malicious (byzantine) nodes from participating in network activities by introducing context-based activity validation and\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eProvide required scalability by reducing unwanted communication overheads and remove unwanted complexities in the consensus process.\u003c/p\u003e \u003c/li\u003e \u003c/ul\u003e \u003c/p\u003e \u003cp\u003eRest of this section discusses the working principles of RLR and DeTAV algorithms, explains the experiment setup and finally describes the simulator used to validate our solution.\u003c/p\u003e \u003ch2\u003e4.1 Rotational Leadership Role (RLR)\u003c/h2\u003e \u003cp\u003eThe idea of RLR is to develop an efficient algorithm to streamline and optimise the consensus process between nodes (robots or drones) in a swarm network environment. As shown in Fig.\u0026nbsp;1 below, RLR, an enhanced consensus algorithm based on Raft voting approach, is tailored explicitly for swarm robots or drone systems. It\u0026rsquo;s light-weight design makes it suitable to run within the limited computing resources available in any small robot or aerial drone. It also reduces network overhead and improves fault tolerance properties of the swarm network by incorporating the following improvements.\u003c/p\u003e \u003cp\u003e \u003cul\u003e \u003cli\u003e \u003cp\u003eStandardising term duration: In the original Raft algorithm network participants can start term elections if they don't receive heartbeat message from the term leader within its individual election timeout duration. By ignoring the leader's heartbeat message or its election timeout duration, a byzantine node can continuously initiate elections that leads to send out flood of vote requests to all nodes to stall the network operations. To address this issue, the leader term duration between the elections in RLR is standardised to a configurable duration. So that any malicious candidate\u0026rsquo;s election request within a valid term duration while current term leader is live, will be ignored by all the followers. But all the legitimate followers in the network will monitor the leader\u0026rsquo;s health for contingency by listening its heartbeat messages.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eGraceful leadership change: As per the Raft design, leader can hold on to its role as long as it could send heartbeat messages continuously without fail or delay within the random election timeout period of the followers. This scenario may lead to monopoly situation in the network. To avoid this and ensure fairness in leadership election, in RLR, all the followers will keep track of leader term duration while monitoring the leader\u0026rsquo;s health. Under normal conditions, leader will send out stepdown status through its heartbeat message at the end of its term. This triggers the random election timeouts of the followers to initiate elections for the next term. The successful candidate takes over the leadership role for the next term from the current leader. Under byzantine conditions, if leader is not sending stepdown message and trying to hold on to the leader role, followers will forcefully end the term by starting elections following its standardised election timeout duration. This ensures no leader can stay beyond its permitted term duration.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eFareness in elections: By default, Raft design allows leaders to participate in subsequent (immediate next) election to continue the leader role if elected. A byzantine leader can start next election before the end of standardised term duration without waiting for its election timeout duration. This will also lead to monopoly situation in the network. To ensure equal opportunity to all other followers to become candidate and initiate election, leader of current term will be barred from taking part in immediate next election.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eProtection against vote manipulations: During the election phase, byzantine candidate may manipulate the vote response from followers in an attempt to became leader. To prevent this, followers sign their vote response to ensure the authenticity. In parallel, followers will share the same vote response to the current leader. This enables two-way consolidated vote response verification by the candidate as well as the current leader of the term. Further, during block creation cycle, all these vote requests will be verified before accepting the block.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eBlacklist malfunctioning or malicious actors: As explained in the DeTAV request validation process, malfunctioning or malicious participants of the swarm network will be blacklisted as part of request authorisation process preventing them from becoming the term leader. The original Raft algorithm doesn\u0026rsquo;t have such mechanism to prevent malevolent acters becoming term leader. Furthermore, RLR is designed to use a configurable and dedicated port to support the leadership related services. This model segregates the leader node functions which leads to reduction of network traffic in the default port used to support the original objective of the network. To reduce the network latency further, the log append entry request has been tailored to broadcast newly created blocks by the leader in equal intervals. By incorporating the above changes in the RLR, issues related to election process of the original Raft design has been fixed. Network performance has been improved by reducing communication overheads and network latency.\u003c/p\u003e \u003c/li\u003e \u003c/ul\u003e \u003c/p\u003e \u003ch2\u003e4.2 Decentralized Task Authorization and Validation (DeTAV)\u003c/h2\u003e \u003cp\u003eAs discussed in the \u003cem\u003eProblem Statement\u003c/em\u003e section above, the context-based validation is the primary gap while integrating Blockchain platform with swarm robotics network. Without the knowledge about the original objective of the swarm network, appropriate activity or transaction validation is not possible. DeTAV mechanism is designed to address this gap. At its core this design enhances the swarm network security using two tier token-based task authorization and validation method. Following steps explains this request validation process in detail. Irrespective of the Raft role, all the robots or drones of the P2P network are referred as nodes of the network. When a node communicates in such network, all other nodes of the network is referred as peers.\u003c/p\u003e \u003cp\u003e \u003cul\u003e \u003cli\u003e \u003cp\u003eWhen network is initiated, network objectives will be recorded as part of the Genisis block of blockchain while initiating the blockchain storage. Network objectives will have all legitimate mappings or task assignments.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eAll the nodes of the network will be issued with a service granting token with a unique ID representing each individual node in the network.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eOnce the network is started, the node responsible for performing a particular task, will generate a single use token using its granting token issued, valid only for a very short (configurable) duration, representing the task and broadcast it to the network for validation.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eOnce received the token, peers of the network will perform the context-based validation against the network\u0026rsquo;s objective and the authorisation is granted to the requested node.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eWhen majority of the peers agreed on the request after validation, the node is allowed to perform its task within the network.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eUnder byzantine condition, if a malfunctioning or malicious node raises any requests that is not aligned of the original objective of the\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003enetwork or not within the scope of the authorisation granted for that node, the peer validation will fail and hence the node will not be allowed to perform its task or it will be intervened by other nodes as part of the built-in prevention mechanism.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eThe robots requesting authorisation for any invalid activities will be blocklisted to prevent them from becoming term leader.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eLeader of the term will record all these activities as transactions of the new block and publish it in the network to peers. Leader will also notify the network about any invalid requests raised by malfunctioning or malicious nodes thus enhancing the swarm network security.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003ePeers will validate the transactions of the proposed new block against its local record of transactions before adding it to the local Blockchain. Below mathematical equation expresses the correlation between granting token and the single use token generated based on the granting token withing the timeframe of the swarm network session.\u003c/p\u003e \u003c/li\u003e \u003c/ul\u003e \u003cdiv id=\"Equa\" class=\"Equation\"\u003e \u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equa\" name=\"EquationSource\"\u003e\n$$\\:{T}_{S}={\\sum\\:}_{i=1}^{n}{O}_{i}$$\u003c/div\u003e \u003c/div\u003e \u003c/p\u003e \u003cp\u003eWhere:\u003c/p\u003e \u003cp\u003eT\u003csub\u003es\u003c/sub\u003e​ = Service Granting token ID.\u003c/p\u003e \u003cp\u003eO\u003csub\u003ei\u003c/sub\u003e​ = One-time token generated at instance i.\u003c/p\u003e \u003cp\u003en\u0026thinsp;=\u0026thinsp;Total number of one-time tokens generated for Ts in a session.\u003c/p\u003e \u003cp\u003eRLR along with DeTAV mechanism ensures that the consensus is achieved in the swarm network is achieved in an efficient, secured and lean way thus making the newly developed consensus algorithm most suitable for futuristic swarm networks.\u003c/p\u003e \u003ch2\u003e4.3 Experiment Setup\u003c/h2\u003e \u003cp\u003eAs depicted in Fig.\u0026nbsp;2, a swarm robotic experimental setup has been designed to demonstrate the capabilities of the Rotational Leadership Role (RLR) and Decentralized Task Authorization and Validation (DeTAV) based consensus algorithm in a Blockchain network suitable for swarm network. The flow of events depicted in the below flow chart in Fig.\u0026nbsp;3, explains the sequence of tasks performed by each robot in the setup shown in Fig.\u0026nbsp;2. In this experimental setup, a P2P based decentralised swarm robotic network is integrated with Blockchain platform that uses RLR to reach consensus among the robots and DeTAV to valid tasks performed by each robot in the network. There are three robots R1, R2, and R3 standing at their respective robot stations and four positions A, B, C, and D that can hold a ping pong ball. The objective of this network is to move a ping pong ball sequentially from position A to B, and then from B to C. Robot R1 is assigned to shift the ping pong ball from position A to B. Similarly, R2\u0026rsquo;s task is to shift the ball from position B to C. Robot R3 will act as a malicious intruder. Once the network started, all the nodes will be issued with a service granting token that encapsulates a task along with a unique ID representing each individual robot, station and the position in the network. Then, for the first time, the network will go for leader election based on timeout configurations. At this point of time, the participants of the network will start to perform their tasks as per the network configuration explained above.\u003c/p\u003e \u003ch2\u003e4.4 Simulator\u003c/h2\u003e \u003cp\u003eA software-based robotic network simulator has been developed using Java 18 to validate the capabilities of newly developed RLR consensus algorithm with DeTAV validation algorithm in a swarm network similar to the experiment setup shown in Fig.\u0026nbsp;2. The scenario shown in Fig.\u0026nbsp;4 is the exact replication of the experiment shown in Fig.\u0026nbsp;2 highlighting features needed to run the simulation test under various scenarios. Simulator will create a P2P network between all the nodes shown in this network. The robots in this simulator will travel along the lines in the direction of the arrows indicating the normal or expected travel path in the circuit. Using the controls at the bottom panel, various test scenarios can be created and start / stop the backend P2P network. Using the controls proved in left panel, the robotic movement can be controlled. Right panel of the simulator will provide the essential RAM and CPU usage statistics while running the experiments. As explained in the \u003cem\u003eResults Discussion\u003c/em\u003e section, we have used this simulator to simulate various test scenarios with multiple tests runs and load conditions.\u003c/p\u003e \u003cp\u003eFig. 5 below shows the robots in action in maximum load configuration with possible byzantine condition in continuous loop mode. Using the list of robot names provided directly under each circuit, malfunctioning and malicious intruding robots in the swarm network can be simulated.\u003c/p\u003e \u003cp\u003eA blockchain based P2P network has been developed. It is seamlessly integrated with the RLR and DeTAV algorithms for consensus and transaction validations with the simulator as frontend to simulate the network activities. Blockchain architecture has been covered in detail in my paper [\u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e]. At the core, this network follows basic blockchain architecture using SHA-256 hashing algorithm, RSA algorithm for asymmetric public / private key pair generation and SHA256withRSA algorithm for transaction signing and verification. At the beginning of each session, network objectives based on the configured scenario will be stored in this blockchain as Genisis block. As explained in the \u003cem\u003eRLR\u003c/em\u003e section, vote based election will be conducted to select new term leader following the election configuration. The term leader will create new blocks with valid transactions at configured equal interval. If no valid transaction is recorded in the recent interval, block creation activity will be suspended. This will help to minimise the communication overhead and reduce network latency. At the receiving end, all the peers will compare each transaction of the new block with their local store before adding the new block into their local chain.\u003c/p\u003e"},{"header":"5 Test Strategy","content":"\u003cp\u003eThe aim of the testing is to validate the capabilities of RLR and DeTAV algorithms using our simulator to do experiments and by comparing these experiment results with other well-known and applicable consensus algorithms in terms of efficiency, security and scalability aspects and assess its suitability for swarm robotics or drone network based on the results.\u003c/p\u003e\n\u003ch2\u003e5.1 Comparison with PoW\u003c/h2\u003e\n\u003cp\u003eWe are comparing RLR with PoW, a well-known blockchain based consensus algorithm, primarily to understand the vast performance difference in RAM \u0026amp; CPU usage metrics between these two algorithms, making PoW not suitable for swarm network.\u003c/p\u003e\n\u003ch2\u003e5.2 Exclusion of PoS\u003c/h2\u003e\n\u003cp\u003eWe are not comparing the RLR with PoS as the later algorithm is mainly based on percentage of stake hold by individual node of the network. But, by basic working principles, all the nodes of swarm network are considered having equal stake in the achieving the objective, even though they perform different roles in the network. Thus, stake-based consensus will be irrelevant for swarm network.\u003c/p\u003e\n\u003ch2\u003e5.3 Comparison with existing research works\u003c/h2\u003e\n\u003cp\u003eExperiment results of RLR will be compared with the existing research work results published recently in [\u003cspan class=\"CitationRef\"\u003e14\u003c/span\u003e]. Authors have done a great job by comparing various consensus algorithms on useful metrics. The primary purpose of this results comparison is to evaluate RLR\u0026rsquo;s performance metrics with recently published similar voting-based algorithm. Below listed metrics will be compared at various load conditions as shown in the graphs to assess and understand the efficiency of RLR and DeTAV implementation.\u003c/p\u003e\n\u003cul\u003e\n \u003cli\u003e\n \u003cp\u003eNumber of transactions per second (TPS) to assess the network performance.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eConsensus latency to assess the distributed consistency and security of task validation process.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eElection latency to assess the efficiency and scalability in the election process.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eQuality of Detection to assess security of the fault tolerance mechanism.\u003c/p\u003e\n \u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cbr\u003e\u003c/p\u003e"},{"header":"6 Results Discussion","content":"\u003cp\u003eTo establish a testing environment, we have used a Windows PC equipped with an Intel i7 16-Core Ultra 7 155H 3.80 GHz processor and 16GB RAM hardware configuration. To validate the capabilities of RLR and DeTAV algorithms, we conducted all the tests discussed in the Test Strategy using our simulator to simulate normal and byzantine conditions with sequential and parallel test scenarios. Test runs were performed in the localhost environment assigning different ports for each node. Experiments were conducted covering 8 test scenarios with 14 different load conditions (5 to 70 nodes with the increment of 4/5/10 per run). Each test run was repeated at an average of 5 times using our RLR and DeTAV solution. We have also conducted test run using PoW algorithm with suitable test scenarios. A total of 840 test runs were conducted and the results were compared with PoW and with the existing research results published in [14] to compare our RLR and DeTAV with VBBS [13], RaBFT [14], Raft [17] algorithms.\u003c/p\u003e\n\u003ch2\u003e6.1 Comparison with PoW\u003c/h2\u003e\n\u003cp\u003eProof of Work (PoW) algorithm was integrated with our simulator to perform comparative test runs with difficulty value of 21. Figure 6 shows the CPU and RAM usage of PoW and RLR algorithms of similar test runs.\u003c/p\u003e\n\u003cp\u003eThe results shows that RLR\u0026rsquo;s CPU and RAM usage is consistently lower throughout the test runs. Compared to RLR, the rapid increase in recourse usage of PoW leads to a wider percentage difference between these 2 algorithms. During peak load testing with 70 network nodes, RLR used under 100MB RAM and 12.5% CPU, while PoW exceeded 450MB RAM and 25% CPU, showing a 500% RAM and 173% CPU reduction by using RLR. This test result proves that PoW based algorithms are not suitable to run within the limited resources of swarm robots or drones. This result also confirms that our RLR based on Voting-based algorithm is the ideal approach to support secure swarm network. Further to this test we\u0026rsquo;ll compare all our test results with the existing research results published in [14] to compare the performance of our RLR with Raft, VBBS, RaBFT algorithms. We have replicated the metrics based on the graphs in [14] using AI based online graph reading tools to get maximum possible accuracy of the data set.\u003c/p\u003e\n\u003ch2\u003e6.2 Throughput\u003c/h2\u003e\n\u003cp\u003eFor any consensus algorithm and its base network, data throughput is a vital metric for assessing its suitability to swarm network. This is measured in terms of number of transactions that a network can successfully handle per unit of time typically represented by Transactions Per Second (TPS). We\u0026rsquo;ll be comparing RLR\u0026rsquo;s TPS with the results of Raft, VBBS and RaBFT algorithms published in [14] as shown in the Fig. 7 below. Using our simulator, throughput test was conducted with load configurations as shown in the graph. The result shows that our RLR algorithm has achieved an average of approximately 144% increase in throughput compared to Raft, 58% increase compared to VSSB-Raft and 32% increase compared with the RaBFT algorithm as per the published results of [14]. While RaBFT, VSSB-Raft and Raft algorithms records lower throughput with more nodes, RLR maintains an observable lead, showing s RLR\u0026rsquo;s higher scalability nature to support larger P2P networks compared to the other algorithms tested.\u003c/p\u003e\n\u003ch2\u003e6.3 Consensus Latency Under Normal Condition\u003c/h2\u003e\n\u003cp\u003ePurpose of latency test is to measure the time delay between the request and its corresponding response in the network. This test is crucial to determine the response time required by the consensus algorithm between validation request submission and achieving consensus on the request. Using our simulator, under ideal conditions without any malfunctioning or malicious nodes in the network, we have conducted multiple tests with varying number of nodes to measure the consensus response time of RLR in comparison with RaBFT, VBBS, Raft algorithms as shown in the graph Fig. 8 below. Based on the result of the comparison experiments, it is evident that RLR\u0026rsquo;s overall average latency (response time), without any byzantine conditions, is approximately 34% less compared to other algorithms as per the published results of [14]. Individually, RLR\u0026rsquo;s consensus latency is approximately 51% less compared to Raft, 30% less compared to RaBFT and 20% less compared to VSSB-Raft algorithm.\u003c/p\u003e\n\u003ch2\u003e6.4 Consensus Latency Under Byzantine Condition\u003c/h2\u003e\n\u003cp\u003eUsing our simulator, we have repeated the latency test run with the load similar to previous latency experiment to test RLR\u0026rsquo;s latency in the presence of 1/4th and 1/3rd malfunctioning or malicious nodes of the total load. These test results are compared with the result of RaBFT algorithm\u0026rsquo;s latency results in the presence of 1/4rd byzantine nodes of the total load. As shown in Fig. 9 below, RLR\u0026rsquo;s average latency with 1/3rd byzantine nodes is approximately 28% less than RaBFT\u0026rsquo;s average latency with 1/4th byzantine nodes as per the results of [14]. This demonstrates that our RLR consensus algorithm can handle higher number of byzantine nodes with less latency in the network.\u003c/p\u003e\n\u003ch2\u003e6.5 Leader Election Latency\u003c/h2\u003e\n\u003cp\u003eAs discussed at the beginning of the \u003cem\u003eMethodology\u003c/em\u003e section, DeTAV task validation algorithm, as part of our RLR consensus, has enhanced the consensus as a context aware process along with security enhancements. To assess the efficiency of this algorithm, we have conducted election latency test using our simulator with varying load conditions as shown below in Fig. 10. RLR\u0026rsquo;s average election latency is approximately 47% less compared to other algorithms as per the published results of [14]. Individually, RLR\u0026rsquo;s election latency is approximately 51% less compared to VSSB-Raft, 48% less compared to Raft and 42% less compared to RaBFT algorithm. The less latency in the election process proves that RLR is capable of handling larger networks without much delays in the decentralised decision-making process.\u003c/p\u003e\n\u003ch2\u003e6.6 Quality of Detection\u003c/h2\u003e\n\u003cp\u003eTo evaluate the security of consensus algorithms the Quality of Detection (QoD) was introduced in [19]. This metric compares the total time taken for reaching consensus in a network with the time needed to identify and isolate malfunctioning or malicious nodes in that network. To assess the Byzantine fault tolerance capability of our RLR algorithm, we have conducted test runs with a total of 40 network nodes. Using our simulator, gradually we simulated the network with 10%, 20% and 30% malfunctioning or malicious behaviour nodes into the network to validate the fault detection and tolerance capability of RLR with DeTAV algorithms. Below results in Fig. 11 shows a stable and linear performance by RLR to identify and insolate byzantine nodes in the network. Even with 30% byzantine nodes configuration, RLR\u0026rsquo;s percentage of time to handle byzantine nodes compared to the time taken for reaching consensus in the network is 67% less compared to RaBFT algorithm as per the result published in [14]. This experiment results illustrates that RLR\u0026rsquo;s reliability in byzantine fault tolerance even in bigger networks.\u003c/p\u003e"},{"header":"7 Conclusion","content":"\u003cp\u003eAs technology progresses towards advancements, decentralise network applications like swarm robotics or drones are becoming more complex. While variants of PoW and PoS were proven as not suitable for swarm networks, Raft, a light weight consensus algorithm, is facing fundamental problems such as low election efficiency, frequent elections and unreliable term durations. As discussed in \u003cem\u003eRelated Works\u003c/em\u003e section, the variants of Raft algorithm have its own limitations in meeting fully decentralised swarm network requirements. Moreover, context-based transaction or task validation mechanism was considered as major gap in providing required network level security. Our research is primarily focused on eliminating these gaps and the unrealistic complexities in decentralised network consensus process and embrace a voting based secured consensus with context-based validation and fault tolerance in swarm network. As a result, we developed RLR as a light weight consensus algorithm capable of running withing the limited resources of the swarm network devices. DeTAV validation algorithm is a component of RLR to validate transactions or tasks inline to the objectives of the network.\u003c/p\u003e \u003cp\u003eThe RLR election process is designed to enhance election efficiency and security and tolerate follower, candidate and leader roles related byzantine fault conditions. This design has been fine tuned to minimize communication overheads and improve throughput of the swarm network. By introducing asymmetric key based transaction signing and verification mechanism along with context-based transaction validation, the security aspect of the network has been improved further. The CPU and RAM utilisation test proves that PoW based consensus is not suitable for swarm network. The comparative experiment result illustrates RLR\u0026rsquo;s higher scalability with an average of 78% higher throughput, superior efficiency with 47% lesser election latency and 34% lesser consensus latency and proving its network security with 100% success in malfunction or malicious node detection in 67% lesser QoD time. These metrics have clearly demonstrated the superior capabilities of our RLR and DeTAV algorithms to address the efficiency, security and scalability needs of the swarm robotic or drone network as defined in our objectives of this research. By integrating our RLR and DeTAV algorithms with P2P decentralised swarm robotics or aerial drone networks makes them more futuristic and enable these networks to handle complex and dynamic requirements.\u003c/p\u003e"},{"header":"Declarations","content":"\u003cp\u003eAuthor contributions\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSathishkumar R.\u003c/strong\u003e Performed analysis, defined the methodology, conducted research experiment, studied results and wrote the manuscript. \u003cstrong\u003eMuralindran M.\u003c/strong\u003e and \u003cstrong\u003eKarthigayan M.\u0026nbsp;\u003c/strong\u003eGuided and supervised research, reviewed manuscript draft, and approved the final manuscript. All authors proofread the revised manuscript for typos and grammatical mistakes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFunding\u003c/strong\u003e There was no funding.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eData availability\u003c/strong\u003e\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe datasets prepared and/or analysed during the current research work are available from the corresponding author upon reasonable request.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eEthics approval and consent to participate\u0026nbsp;\u003c/strong\u003eNot applicable\u003cstrong\u003e.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eConsent for publication\u0026nbsp;\u003c/strong\u003eNot applicable\u003cstrong\u003e.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCompeting interests\u003c/strong\u003e The authors declare no competing interests.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAdditional information\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCorrespondence\u0026nbsp;\u003c/strong\u003eand requests for materials should be addressed to corresponding author Muralindran M., [email protected].\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpen Access\u003c/strong\u003e This article is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, which permits any non-commercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this article or parts of it. The images or other third-party material in this article are included in the article\u0026rsquo;s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article\u0026rsquo;s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc-nd/4.0/.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n\u003cli\u003eFolgado FJ, Calder\u0026oacute;n D, Gonz\u0026aacute;lez I, Calder\u0026oacute;n AJ. Review of Industry 4.0 from the perspective of automation and supervision systems: Definitions, architectures and recent trends. Electronics. 2024 Feb 16;13(4):782. https://doi.org/10.3390/electronics13040782\u003c/li\u003e\n\u003cli\u003eIkumapayi, O.M., Laseinde, O.T., Elewa, R.R., Ogedengbe, T.S. and Akinlabi, E.T. Swarm Robotics in a Sustainable Warehouse Automation: Opportunities, Challenges and Solutions. E3S Web of Conferences 2024, 552: 01080. https://doi.org/10.1051/e3sconf/202455201080 \u003c/li\u003e\n\u003cli\u003eDias PG, Silva MC, Rocha Filho GP, Vargas PA, Cota LP, Pessin G. Swarm robotics: A perspective on the latest reviewed concepts and applications. Sensors. 2021 Mar 15;21(6):2062. https://doi.org/10.3390/s21062062\u003c/li\u003e\n\u003cli\u003eQueralta JP, Westerlund T. Blockchain-powered collaboration in heterogeneous swarms of robots. arXiv preprint 2019 Nov 23. arXiv:1912.01711. https://doi.org/10.48550/arXiv.1912.01711\u003c/li\u003e\n\u003cli\u003eStrobel V, Pacheco A, Dorigo M. Robot swarms neutralize harmful Byzantine robots using a blockchain-based token economy. Science Robotics. 2023 Jun 28;8(79):eabm4636. https://doi.org/10.1126/scirobotics.abm4636\u003c/li\u003e\n\u003cli\u003eAditya US, Singh R, Singh PK, Kalla A. A survey on blockchain in robotics: Issues, opportunities, challenges and future directions. Journal of Network and Computer Applications. 2021 Dec 15;196:103245. https://doi.org/10.1016/j.jnca.2021.103245\u003c/li\u003e\n\u003cli\u003eSapra N, Shaikh I, Dash A. Impact of proof of work (PoW)-Based blockchain applications on the environment: a systematic review and research agenda. Journal of Risk and Financial Management. 2023 Mar 31;16(4):218. https://doi.org/10.3390/jrfm16040218\u003c/li\u003e\n\u003cli\u003eHu Q, Yan B, Han Y, Yu J. An improved delegated proof of stake consensus algorithm. Procedia Computer Science. 2021 Jan 1;187:341-6. https://doi.org/10.1016/j.procs.2021.04.109\u003c/li\u003e\n\u003cli\u003eFerrer EC. If blockchain is the solution, robot security is the problem. Frontiers in Blockchain. 2023 May 16;6:1181820. https://doi.org/10.3389/fbloc.2023.1181820\u003c/li\u003e\n\u003cli\u003eDu Z, Qu Z, Fu Y, Huang M, Liu L. Multi‐strategy‐based leader election mechanism for the Raft algorithm. Concurrency and Computation: Practice and Experience. 2023 Oct 10;35(22):e7734. https://doi.org/10.1002/cpe.7734 \u003c/li\u003e\n\u003cli\u003eRanganathan S, Mariappan M, PG KM. Design methodology for using blockchain in swarm robotics. In2021 IEEE 19th Student Conference on Research and Development (SCOReD) 2021 Nov 23 (pp. 76-81). IEEE. https://doi.org/10.1109/SCOReD53546.2021.9652778 \u003c/li\u003e\n\u003cli\u003eRanganathan S, Mariappan M, Muthukaruppan K. Efficient distributed consensus algorithm for swarm robotic. In2022 IEEE International Conference on Artificial Intelligence in Engineering and Technology (IICAIET) 2022 Sep 13 (pp. 1-6). IEEE. https://doi.org/10.1109/IICAIET55139.2022.9936787\u003c/li\u003e\n\u003cli\u003eTian S, Bai F, Shen T, Zhang C, Gong B. Vssb-raft: a secure and efficient zero trust consensus algorithm for blockchain. ACM Transactions on Sensor Networks. 2024 Jan 9;20(2):1-22. https://doi.org/10.1145/3611308 \u003c/li\u003e\n\u003cli\u003eBai F, Li F, Shen T, Zeng K, Zhang X, Zhang C. RaBFT: an improved Byzantine fault tolerance consensus algorithm based on raft. The Journal of Supercomputing. 2024 Sep;80(14):21533-60. https://doi.org/10.1007/s11227-024-06284-6\u003c/li\u003e\n\u003cli\u003eTakehana C, Lim D, Sharma S. Raftlet: A Byzantine Fault Tolerant Raft. Raftlet_A_Byzantine_Fault_Tolerant_Raft.pdf \u003c/li\u003e\n\u003cli\u003eZhang Y, Cui G, Sui W. A Raft Consensus Algorithm Modification for Adapting Frequent Leader Switch in Multi-agent Swarm Robotics Applications. InInternational Conference on Guidance, Navigation and Control 2024 Aug 9 (pp. 618-629). Singapore: Springer Nature Singapore. https://doi.org/10.1007/978-981-96-2204-7_59 \u003c/li\u003e\n\u003cli\u003eOngaro D, Ousterhout J. In search of an understandable consensus algorithm. In2014 USENIX annual technical conference (USENIX ATC 14) 2014 (pp. 305-319). atc14-paper-ongaro.pdf\u003c/li\u003e\n\u003cli\u003eJafar U, Aziz MJ, Shukur Z. Blockchain for electronic voting system\u0026mdash;review and open research challenges. Sensors. 2021 Aug 31;21(17):5874. https://doi.org/10.3390/s21175874 \u003c/li\u003e\n\u003cli\u003eZhang X, Miao X, Xue M. A Reputation‐Based Approach Using Consortium Blockchain for Cyber Threat Intelligence Sharing. Security and Communication Networks. 2022;2022(1):7760509. https://doi.org/10.1155/2022/7760509\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":true,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"discover-computing","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"","sideBox":"Learn more about [Discover Computing](https://link.springer.com/journal/10791)","snPcode":"10791","submissionUrl":"https://submission.springernature.com/new-submission/10791/3","title":"Discover Computing","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Discover Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true},"keywords":"Blockchain, Swarm Robotics, Consensus algorithm, Raft, Decentralized networks security","lastPublishedDoi":"10.21203/rs.3.rs-6810291/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-6810291/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eSwarm robotics is an evolving realm, designed to achieve complex tasks collaboratively. This technology faces challenges in secure communication, decentralized decision making, and scalability aspects. While many studies suggested using of Blockchain technology for swarm robotics, the existing Blockchain solutions with Proof of Work (PoW) or Proof of Stake (PoS) based consensus, originally designed for finance and trade network systems, are inefficient for swarm robotics due to their high computation needs or stake-based monopolies. This research addresses these challenges by introducing a Blockchain based Rotational Leadership Role (RLR) consensus algorithm, a voting-based consensus protocol, with Decentralized Task Authorization and Validation (DeTAV), a token-based transaction validation mechanism, to ensure efficiency, security, and scalability features in swarm robotic and drone systems. RLR is a lightweight hybrid solution suitable to run within the limited computing resources of any small robots or aerial drones. A custom-built robotic simulator compared RLR to PoW, demonstrating RLR's superior performance. Based on the experiments conducted with 70 concurrent robots, RLR used under 100MB RAM and 12.5% CPU, while PoW exceeded 450MB RAM and 25% CPU, showing a 500% RAM and 173% CPU reduction by using RLR. RLR's DeTAV also enhanced network security through context-based task validation to restrict suspicious activities initiated by malfunction or malicious robots in the network. Scalability tests performed using 4 to 70 robots revealed RLR's ability to scale effortlessly to handle over 70 nodes. Thus, RLR with DeTAV effectively meets the efficiency, security, and scalability needs of swarm robotic or drone networks.\u003c/p\u003e","manuscriptTitle":"Smarter Swarms: Empirical Assessment of Blockchain-Based RLR and DeTAV Algorithms in Swarm Network","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2025-06-26 12:08:03","doi":"10.21203/rs.3.rs-6810291/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"decision","content":"Revision requested","date":"2025-09-29T16:57:19+00:00","index":"","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2025-08-04T09:53:10+00:00","index":"hide","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2025-07-25T21:59:39+00:00","index":"hide","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2025-07-24T13:24:27+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"31441710804857221009036856875181556501","date":"2025-07-24T11:31:56+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"8044947882724263468421497511610477704","date":"2025-07-24T09:38:36+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"217052362432101425390959575807912090244","date":"2025-07-23T16:37:24+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"62470843211262228024976378781807218093","date":"2025-07-23T12:31:45+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"73795536251607119889270206208768739301","date":"2025-07-23T12:21:50+00:00","index":"hide","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2025-07-01T04:51:53+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"113874693003875843889801440061394799661","date":"2025-07-01T04:36:59+00:00","index":"hide","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2025-06-30T16:53:29+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"336658352043634074141973188848779374937","date":"2025-06-30T04:23:46+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"323157845929328070386833868854180412670","date":"2025-06-29T11:54:36+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"104941451022350908296193747591877728118","date":"2025-06-25T12:00:46+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2025-06-24T08:09:03+00:00","index":"","fulltext":""},{"type":"editorInvited","content":"","date":"2025-06-20T07:57:07+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2025-06-07T09:19:23+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2025-06-07T09:17:49+00:00","index":"","fulltext":""},{"type":"submitted","content":"Discover Computing","date":"2025-06-03T10:29:54+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"discover-computing","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"","sideBox":"Learn more about [Discover Computing](https://link.springer.com/journal/10791)","snPcode":"10791","submissionUrl":"https://submission.springernature.com/new-submission/10791/3","title":"Discover Computing","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Discover Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"7029caef-6e09-49e0-9ca8-64200abb5863","owner":[],"postedDate":"June 26th, 2025","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"published-in-journal","subjectAreas":[],"tags":[],"updatedAt":"2026-02-16T16:05:47+00:00","versionOfRecord":{"articleIdentity":"rs-6810291","link":"https://doi.org/10.1007/s10791-026-09951-9","journal":{"identity":"discover-computing","isVorOnly":false,"title":"Discover Computing"},"publishedOn":"2026-02-12 15:58:15","publishedOnDateReadable":"February 12th, 2026"},"versionCreatedAt":"2025-06-26 12:08:03","video":"","vorDoi":"10.1007/s10791-026-09951-9","vorDoiUrl":"https://doi.org/10.1007/s10791-026-09951-9","workflowStages":[]},"version":"v1","identity":"rs-6810291","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-6810291","identity":"rs-6810291","version":["v1"]},"buildId":"8U1c8b4HqxoKbykW_rLl7","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}