Enhancing Swarm Robotics: A Blockchain-Based Consensus Design for Security and Efficiency

Enhancing Swarm Robotics: A Blockchain-Based Consensus Design for Security and Efficiency | 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 Method Article Enhancing Swarm Robotics: A Blockchain-Based Consensus Design for Security and Efficiency SATHISHKUMAR RANGANATHAN, Dr. Muralindran Mariappan, Dr. Karthigayan Muthukaruppan This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-7523681/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract Swarm robotics, as a distributed multi-agent platform, is well-suited for applications such as surveillance, rescue, hazardous operations, and smart manufacturing. However, current systems face critical challenges in secure communication, decentralized decision-making, and fault tolerance. Blockchain offers promising features of decentralization, security, and reliability, yet its integration into swarm robotics remains limited by the lack of suitable consensus algorithms that address real-time operational needs, task validation, and malicious activity detection. This study reviews the evolution of consensus mechanisms, analysing their security, scalability, and efficiency in decentralized networks. It highlights existing gaps in blockchain-based consensus for swarm robotics and proposes directions for developing lightweight, secure, and scalable solutions. The findings aim to advance robust consensus designs that enhance autonomy, resilience, and trust within swarm robotic networks. Robotics Computer Architecture and Engineering 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 Figure 12 Figure 13 Figure 14 1 Introduction Industry 4.0 revolution is emphasizing on smart, decentralized and autonomous systems that can communicate and collaborate in real time without depending on centralized control [ 1 ]. Inline to this advancement, Swarm Robotics is a multi-agent distributed network platform, capable of carrying out complex tasks in a highly synchronized way. Because of its collaborative nature, this technology is highly suitable for industrial applications like large area surveillance, search and rescue operations, handling hazardous environments, and smart manufacturing processes [ 2 ]. However, this technology faces numerous challenges to fulfill recent demands in this field, including secured data communication, decentralized decision-making, and fault tolerance [ 3 ]. This chapter shows new insights into existing challenges and proposes a novel solution based on blockchain technology. On the other hand, blockchain technology has been proposed to provide decision-making, security, and reliability aspects in the swarm robotics network. The decentralization of decision making holds much importance in enabling the autonomous mode of operations in a swarm robotics network. Blockchain indeed stands as a perfect solution, which helps to maintain distributed ledger and peer-to-peer properties to support the participants of the robotic network in working independently without centralized management. However, the most challenging aspect of incorporating blockchain into swarm robotics is devising a suitable consensus algorithm that can handle the real-time needs of swarming operations like fault-tolerance and scalable. Most of these blockchain-based solutions are still incapable of effectively validating task execution and restricting malicious activity across the swarm network [ 4 ]. Consequently, our research is an important step towards more secure, robust and scalable swarm robotic systems that can work autonomously towards achieving their defined objectives. Rest of this paper is organized in the following sections. Section 2 details the blockchain architecture and its implementation models. Section 3 covers summary on swarm network and the importance of reaching consensus in the swarm network. Section 4 details the proposed RLR and DeTAV design. Section 5 explains the experiment setup and Sections 6 reviews the experiment results. Finally, Section 7 concludes this paper with summary on the proposed design and scope of our further research work. 2 Blockchain Architecture Blockchain architecture defines the core structure and protocols of the decentralized ledger on how the data must be recorded, shared, or validated within a distributed network [14]. This system is generally built on network-connected computing devices with data storage capacity. Network transactions or activities are stored in the form of an interconnected chain of blocks. The data stored in these blocks is time-stamped, and immutable to ensure transparency and security properties. As shown in Fig. 1, blockchain architecture consists of several key components, including nodes, blocks, chains, and consensus mechanisms. 2.1 Nodes Nodes are the individual devices or participants in a blockchain network. Each node has a copy of the blockchain, enabling it to participate in its operations. As listed below, in general, there are 3 different types of nodes. 1. Full Nodes : This type of nodes will store full copy of the blockchain in its local database and perform transaction validation in the network. 2. Light Nodes : This type of nodes does not store the entire blockchain in its local database but can perform transactions in the network. They rely on Full Nodes for transaction validation. 3. Mining Nodes : This type of nodes will participate in the mining process using its computational power, create new blocks and perform transaction validations in the network. 2.2 Blocks A block is a collection of transaction data. Each block typically contains the following information. 1. Block Header : Header part of the block contains metadata about the block. It’ll also have the previous block’s hash value, timestamp, nonce (used for mining), and Merkle root (hash representing all transactions in the block). 2. Block Body : Body part of the block contains the list of all the actual transactions performed within the network. 2.3 Chain Structure Blocks are linked together in chronological order to form a chain. The chain’s integrity is maintained through cryptographic hashes. As shown in Fig. 1, an interlinked chain of blocks will be created by adding the hash of the previous block into the new block. This interlinked structure makes the chain of blocks immutable. This arrangement ensures that any alteration in a block will affect all subsequent blocks, rendering the chain invalid. 2.4 Layers of Blockchain Architecture This section provides a comprehensive overview of the multi-layered structure of the blockchain platform, where each layer serves a distinct purpose in ensuring the efficient operation of the underlying network [15]. As portrayed in Fig. 2, the core layers of this platform are the Data, Network, Consensus, Contract, Incentive, and Application. 2.4.1 Data Layer Data layer is the foundation of blockchain architecture. It is responsible for storing all transactional and configuration data in a secure and immutable format. Following details are part of this layer. 1. Transactions : Interactions between the nodes within the blockchain are recorded as transactions. Each transaction contains specific details such as sender and receiver addresses, transaction amount, and a unique identifier. 2. Chain Structure : Blockchain platform stores the data in block format. These blocks are sequentially linked using hash of the previous block to form an interlinked chain like structure. So, any modification to a block would require changing all subsequent blocks. This property helps to maintaining the immutability in the blockchain platform. 3. Merkle Tree : Merkle tree structure is used to efficiently and securely verify the integrity of the transactions recorded within a block. 2.4.2 Network Layer Network layer provides the underlying infrastructure for peer-to-peer (P2P) communication in the blockchain network. This layer is critical for ensuring data synchronization and connectivity among all participants. 1. P2P Network Communication : This mechanism facilitates the direct exchange of information among nodes without relying on a central server, ensuring that all nodes can share and receive updates about the state of the blockchain. 2. State Synchronization : Nodes maintain a consistent view of the blockchain through regular updates, ensuring that all participants are aligned on the current state of the ledger. 3. Transport Protocols : This layer employs various transport protocols to manage how data packets are sent and received, ensuring reliable communication among nodes. 2.4.3 Consensus Layer The Consensus Layer plays a pivotal role in maintaining the integrity and reliability of the blockchain by establishing a protocol for agreement among nodes. It determines how transactions are verified and added to the blockchain. The consensus layer is responsible for validating the authenticity of transactions before they are added to the blockchain, preventing fraud and ensuring the network's security. Some of the commonly used consensus algorithms are listed below. 1. Proof of Work (PoW) [16] : Requires nodes (miners) to solve complex mathematical problems to validate transactions and create new blocks, consuming significant computational power. 2. Proof of Stake (PoS) [17] : Allows validators to create new blocks based on the amount of cryptocurrency they hold and are willing to "stake," reducing energy consumption compared to PoW. 3. Delegated Proof of Stake (DPoS) [18] : A variation of PoS where stakeholders elect delegates to validate transactions on their behalf, increasing efficiency and scalability. 4. Practical Byzantine Fault Tolerance (PBFT) [19] : Designed for permissioned blockchains, this mechanism achieves consensus through a voting system among a limited number of trusted nodes. 2.4.4 Contract Layer The Contract Layer enables the automation of agreements through programmable logic embedded in the blockchain. This layer encompasses: 1. Smart Contracts [20] : These are self-executing contracts with the terms of the agreement directly written into code. Smart contracts automatically enforce and execute contractual obligations when predefined conditions are met, reducing the need for intermediaries and enhancing efficiency. 2. Executable Code : The Contract Layer allows for the deployment of various scripts and algorithms that govern interactions within the blockchain ecosystem, facilitating complex applications ranging from finance to supply chain management. 2.4.5 Incentive Layer The Incentive Layer is crucial for motivating participants to engage with and maintain the blockchain network. This layer includes: 1. Reward Mechanisms : Participants (e.g., miners or validators) are incentivized through reward systems that distribute tokens or cryptocurrency for their contributions to the network, such as validating transactions or maintaining network security. 2. Penalties : To discourage malicious behavior, this layer may also implement penalties for nodes that attempt to undermine the network, ensuring a balanced and fair ecosystem. 2.4.6 Application Layer The Application Layer is the topmost layer, where user-facing applications and services interact with the blockchain. This layer involves: 1. Domain-Specific Applications : Applications are designed to meet the needs of specific industries or use cases, such as finance, healthcare, or supply chain management. These applications leverage the functionalities provided by the underlying blockchain layers to offer innovative solutions. 2. User Interfaces : This layer includes the interfaces through which end-users interact with the blockchain, such as wallets, dashboards, and other user-friendly tools that enhance accessibility and usability. As technology continues to evolve, advancements in these layers will likely lead to more efficient and scalable blockchain solutions. 2.5 Implementation Models Blockchain technology classified into three categories: Public blockchains, Consortium blockchains, and Private blockchains [21] (Korpela, Hallikas, & Dahlberg, 2017). Each category has unique characteristics and applications, based on the factors such as access permissions, consensus mechanisms, and governance structure of the blockchain network. 2.5.1 Public Blockchains Public blockchains are built on a decentralized network and do not require permission from any participants and every participant in the network has access to all the information. In this way, anyone can join the network, make and endorse transactions as it is the reality of such a level of openness. This makes the environment very democratic and transparent. Good examples of public blockchains are Bitcoin and Ethereum. These blockchains use different consensus mechanisms that ensure security and reliability: the consensus of all participants in one way or another is highly important for the integrity of the blockchain. The two most widely used consensus algorithms in public blockchains are Proof of Work and Proof of Stake. Public blockchains are designed to handle applications that require quite a bit of trust without middlemen, thanks to their inherent transparency and inclusiveness. 2.5.2 Consortium Blockchains Consortium Blockchains is also referred to as federated blockchains. It enables a pre-selected group of participants to handle and govern the blockchain network. In the case of a consortium blockchain, while information is shared across all members, processes like data modification and consensus mechanisms are permitted only for predefined groups in organizations or by individuals. It finds widespread application in sectors where collaboration among trusted third parties are needed such as the banking sector, supply chain management, and healthcare. A case in point may be where the members of consortium blockchains focus on sponsoring and tracking jointly undertaking marketing projects or collective databases of customers. In essence, this decentralization of powers prevents a single point of failure from compromising all control or decision-making authorities. Below listed are some of the examples of consortium blockchains. 1. R3 : A consortium of banks and financial organizations focused on the development of blockchain solutions for the financial sector. 2. Energy Web Foundation : It leverages profound experience in accelerating blockchain technology for energy, which empowers decentralized solutions within the sector. 3. B3i-Blockchain Insurance Industry Initiative : This initiative looks to bring more efficiency into insurance practices through the sharing of blockchain networks between insurers and reinsurers. The consortium blockchains have a governance structure that allows these organizations to collectively decide without bias, thus gaining trust among participants in collaboration. 2.5.3 Private Blockchains Private blockchains are also known as permission blockchains because central authority governs them, and only anyone can access specific information or hold the right to modify something. Most often, there is one governing body within a private blockchain, operated either by one organization or a consortium with well-defined hierarchies and roles. For example, a payroll system using blockchain might limit access solely to HR personnel and specific departments within an organization. In private blockchains, the central authority governs who can read, write, or participate in the blockchain thus making it highly restricted unlike in public blockchains. Therefore, the consensus mechanism used by private block chains is most of the time a single central authority instruction rather than a general agreement as it is in public block chains. This could make decision processes easier and increase efficiency but at the expense of some degree of decentralization and transparency. 2.6 Evolution and Taxonomy of Blockchain Architectures This section in turn explains the general pattern and changes in relation to blockchain architecture over the years advancing to a categorization that enables developers to choose appropriate platforms for relevant applications [22]. 2.6.1 Single-Ledger-Based Architecture 1. Public Networks : Introduced with platforms like Ethereum, these allow open participation but raise privacy concerns due to publicly accessible transaction data. 2. Private Networks : This architecture is designed to address privacy issues, by incorporating a certificate authority and handshaking mechanisms to manage user access and authenticate nodes. Platforms such as Hyperledger Burrow and Multichain exemplify this architecture. 3. Hybrid Networks : Developed to facilitate private transactions within a public ledger, platforms like Quorum implement encryption techniques to maintain data confidentiality while enabling public participation. 2.6.2 Multi-Ledger-Based Architecture Multi-Ledger based blockchain architecture was introduced by Hyperledger Fabric network. This architecture supports confidential transactions among specific participants within the network. This mechanism creates a network of channels for secure communication. Transaction validation involves multiple endorsing peers to enhance the security and privacy within the network environment. 2.6.3 Interoperability-Based Architecture As the blockchain platform implementation surges across various application sectors, interoperability between various types of blockchain implementations has become essential. Platforms like Inter-Blockchain Communication (IBC), cross-chain bridges. etc. have been developed to allow communication between public and private blockchains, enhancing security through mechanisms like anchoring, which links the sidechains to mainchains. 3 Swarm Robotics Network Swarm robotics is an advanced branch of multi-robot systems which allows autonomous robots to work together without a centralized chain of command [23]. The core notion is based on the concept of decentralized and self-organization whereby network members of the swarm can take some local autonomous decisions. One of the most interesting aspects in this case is that robots in the network do not have knowledge of what every other robot is doing in the swarm, putting them at a disadvantage. Thus, they depend on a decentralized consensus mechanism within their network. Thus, information of the individual member is shared with other nodes and the swarm is able to build the complete picture of the goal of the network. For example, if a robot meets an obstacle, or a portion of the task is completed, the robot will pass such information to the nearest robots, thus making it possible for the entire group to change its plan within the performance of the task. The beauty of this system lies in its scalability and fault tolerance. Since robots are independent and decentralized, if one or several robots fail, the others can compensate by continuing to share information and maintain the network’s objective. This behavior is often modelled after natural systems, like ant colonies or flocks of birds, where simple interactions between individuals lead to complex, coordinated behaviors. 3.1 Importance of Consensus algorithms The concept of Coordinated Industrial Robotics is particularly interesting because the current trend is rapidly moving towards the integration of smarter, decentralized, and more autonomous cyber-physical systems that can operate together in a highly coordinated way. These systems, composed of several robotic agents acting in close cooperation, are the modern trends in industrial automation. A swarm of robot systems is characterized by real time communication and effective, action driven integration of all individual robots towards the shared goal irrespective of their local perspective. As a result, the strength of the communication and the efficiency of the algorithms employed for decentralized decision-making processes determine the viability of swarm robotics applications. This decentralization opens up a broad scope for new innovations in future robotics construction, offering dynamic and dominant systems in the robotics construction parameters. However, even the more sophisticated swarm networks are facing challenges while implementing consensus algorithms to handle data validation, security, and efficiency within these coordinated networks where decentralized control and decision-making are essential [24]. As described below, there are two critical limitations that hinder the full potential of coordinated robotics networks. 3.1.1 Inefficient Consensus Algorithms Consensus algorithms designed for finance and other trade networks are not suitable to support the basic needs of any swarm robotics network. These systems demand high standards of data validation, security, and overall operational efficiency. Without robust and efficient consensus protocols, it becomes difficult for the network to achieve reliable performance, especially when operating under dynamic conditions or in larger, more complex swarm setups. 3.1.2 Inability to Detect and Isolate Malicious Robots These consensus algorithms also face limitations to detect and eliminate malfunctioning or malicious actors in a swarm of robots. Within a distributed network in which trust and collaboration is stressed, even one or several robots, either faulty or purposefully defective, can render the whole system useless and unsafe. Addressing these limitations is essential to making coordinated industrial and swarm robotics systems more reliable and efficient. 4 Proposed Consensus Algorithm for Swarm Networks The study suggests designing a consensus mechanism for the Blockchain that is tailored to the needs of these swarm robotic networks. This custom solution along with Blockchain technology, which possesses significant advantages in distributed data storage, decentralized governance, security, will be the right fit to address the needs of swarm robotic networks [3, 25]. The research methodology will focus on the following areas: 1 Analyzing Blockchain’s Distributed Data and Decision-Making Capabilities : We will examine how blockchain’s distributed ledger technology can be integrated into a robot network to improve decision-making efficiency and data validation. By leveraging blockchain, we aim to eliminate many of the centralized bottlenecks that currently hinder robot coordination. 2 Simplifying Blockchain Architecture : The complexities found in blockchain's Consensus, Incentive, and Network and Security layers often hinder its adoption in real-time systems. Our approach will involve streamlining these layers to better suit the real-time operational needs of coordinated robotics, without compromising the security and trust that blockchain provides. 3 Developing an Efficient Consensus Algorithm : A key outcome of the research will be the creation of an efficient consensus algorithm, purpose-built for coordinated industrial robots. This algorithm will be designed to ensure rapid and secure data validation, while also providing the resilience needed to handle the dynamic environments in which industrial and swarm robots operate. 4 Designing an Experiment Setup : The study will include a detailed experiment setup to test the integration of blockchain with coordinated industrial robots. We will assess its impact on improving performance, enhancing communication reliability, and bolstering overall security. 4.1 Rotational Leadership Role (RLR): The idea of Rotational Leadership Role (RLR) is derived from Raft, voting based consensus algorithm, designed to resolve fault tolerance and improve the efficiency of mechanisms for log or state replication. Raft is ideal for practical systems requiring distributed state consensus [25]. Not only does it maintain a level of redundancy and consistency within a distributed system, but it also provides a way of recovery from failures if most participants in the system are still in working order. This algorithm satisfies the requirement of upholding a single system image by ensuring that distinct participants collectively resolve the state of the system as one regardless of the presence of some network participants. RLR core structure of the proposed consensus algorithm. This model applies the improvised leader election process in which leader roles are distributed among members of the network over time. Proposals for leader candidates can be made by any member of the network for a limited period during an election cycle. Leaders are elected and qualifications for the position of Leader can be attained after participation in an open contest by any participant node of the network. When a leader is elected, their leadership role is only limited for the duration of that term. At the end of the term, defined by a predetermined time interval, a fresh round of elections is held to choose a new leader for the next term. The plurality voting mechanism ensures that no more than one leader is elected per term, maintaining the integrity of the leadership structure. Fig. 3 in the paper illustrates the leader election process in detail, showcasing how the consensus algorithm facilitates this rotation of leadership. As part of their leadership duties, the elected leader is responsible for the following key tasks: 1 Network Synchronization and Fault Tolerance : The leader ensures that all network participants remain in sync, maintaining the fault-tolerant structure of the network. 2 Management of Token Cache and Cache Synchronization : The leader manages the token cache and oversees synchronization between network participants to maintain consistency across the system. 3 Consolidation of Validated Transactions : The leader consolidates all validated transactions conducted by participants within the network. 4 Creation of New Blocks : Once the transactions have been agreed upon, the leader creates a new block representing these transactions. 5 Block Distribution : Finally, the leader shares the newly created block with all network participants, ensuring that the distributed ledger remains up-to-date and accurate. By leveraging this rotational leadership and voting-based consensus mechanism, the system ensures equitable participation among network members and maintains consistency and fault tolerance, even in the face of failures. 4.2 Decentralized Task Authorization and Validation (DeTAV) The Decentralized Task Authorization and Validation mechanism proposed here enhances process security through a two-tier, dynamic, token-based validation system. This approach builds on the Rotational Leadership Role (RLR), which governs leadership and task distribution in the swarm network [25]. There are 2 aspects of network security we are considering for the swarm robotics network. 1 Communication & Data Security : By default, Blockchain networks use unique cryptographic signature and hash functions to ensure the network data security. 2 Process Security : Most of the current consensus algorithms do not consider the processes that individual participant of the swarm network is contributing. This paper will concentrate on this gap to ensure process or task level security and achieving objective based consensus among participants of swarm network. This will prevent any accidental damage to the participants or to the process and eliminate the threat of giving network control to faulty or intruding robots in the swarm network. At the start of each term, the elected leader issues Request Tokens (RT) to all participants in the network. The RT is renewed by the leader at the beginning of each term, ensuring that no participant can misuse previously issued tokens, thereby safeguarding the network from unauthorized actions. Participant must present their RT within the network for validation and task authorisation. The network then validates the RT, and the leader issues an Approval Token (AT) to the requesting participant. This AT effectively binds the participant to their task. Because of this authorisation process, the entire swarm network remains aware of who is performing which task, and by when, thereby enhancing transparency across the network. Fig. 4 illustrates the integration of the Rotational Leadership Role (RLR) with the DeTAV mechanism. This forms the core component of the proposed lightweight blockchain-based consensus algorithm. This method eliminates all the typical complexities like solving computational puzzles or executing heavy logic processes generally seen in mining operations. This makes the system more efficient and tailored for the decentralized nature of the swarm robotics, where the computing power of individual robots may be very limited. Both RLR and DeTAV processes of the proposed solution provide a secure, and efficient framework for task validation and management in the swarm robotic network without having unnecessary computational overhead. This solution significantly enhances the overall security and performance of the coordinated swarm robotics system. This enhanced solution also removes the dominance created by individual robots with a high percentage of ownership / stake in the swarm robotics network. The hypothesis of this proposed solution is to reduce the processing load of individual robots, improving the performance and ensure the process security aspects of the swarm network. More details on the results will be added based on further experiments of the proposed solution. 5 Experiment Setup This section outlines a simple experimental setup designed to demonstrate the application of the proposed Rotational Leadership Role (RLR) and Decentralized Task Authorization and Validation (DeTAV) based consensus algorithm in a swarm robotics network, as depicted in Fig. 5. In this experiment, three robots (R1, R2, and R3) interact with four ball holders positioned at A, B, C, and D. The primary objective of the network is to move a ball sequentially from position A to B, and then from B to C, following a predefined sequence. The event flow, illustrated in Fig. 6, explains the tasks performed by each robot in the swarm network according to the pre-configured setup seen in Fig. 5. In this scenario, without the integration a suitable decentralised system like blockchain, these robots operate in isolation, where no consensus is established regarding the exchange of information within the swarm. This leads to various challenges, such as ensuring the safety of individual robots, detecting faulty or malicious behaviors, verifying the authenticity of shared data, and reaching consensus among the robots. To address these challenges, this experimental setup integrates the proposed private blockchain solution to introduce decentralized process-based decision-making thus enhancing the network security. The integration of the proposed solution ensures that all actions within the swarm network are verified and authorized, thus mitigating risks related to intrusions or faulty behavior. The above process flow explains the DeTAV’s multi-level token-based process validation using the sequence depicted in the experimental setup in Fig. 5. The process is aimed mainly to prevent any unauthorized tasks within the swarm network and ensure the network security. The following steps are illustrated assuming Robot R2 is the leader of the current term of the network. 1 As the leader of the current term, R2 sends renewed Request Tokens (RT) to R1, Position A, B & C for current term. 2 Before starting its task, R1 will share its RT with network participants and request for approval to shift the ball from Position A (PA) to B (PB). 3 Based on the proposed solution, network reaches consensus on R1’s request. R2 will send the Approval Token (AT) to R1 to perform its task. 4 R1 will move from station S1 to PA, hand over the AT and request for ball. 5 Before handing over the ball, PA will share the AT with network participants for validation. 6 Again, network reaches consensus on AT and R2, as a leader, will confirm back to PA to release the ball to R1. 7 Based this approval, PA will hand over the ball to R1. 8 After receiving the ball from PA, R1 will move to drop the ball at PB. 9 Before accepting the ball from R1, steps 5 and 6 will be repeated by PB. 10 Steps 3 to 8 will be repeated for R2 to shift ball from PB to PC. 11 Steps 10 to 12 will be repeated for every action to validate the objective before concluding the network actions. 6 Experiment Results A software-based robotic network simulator has been created to demonstrate the objective of the experiment setup shown in Fig. 5. Fig. 7 illustrates the decentralised swarm robotic network application. As highlighted in red rectangles in the below Fig. 7, this simulator is designed with functions to setup the environment and to start, stop and reset the experiment setup. It has an option to simulate network attack by malfunctioning or malicious robots in the network to demonstrate the network security. 6.1 Stage-I Without Malicious or Malfunctioning Participant in The Network To start this experiment, initially this setup is created with 2 robot workstations named S1 & S2 with 1 robot each. Robot R1 at station S1 & robot R1 at S2. A robot workstation is designed to hold robots before and after their task. A ball is placed at Position A. As explained above in the setup 5, this experiment begins with Robot R1 at S1 moving the ball from Position A(PA) to Position B(PB). Subsequently, Robot R2 at S2 shifts the ball from Position B to Position C(PC), successfully fulfilling the original objective of the network. All the stations, robots and ball positions will work with each other as per the proposed consensus mechanism explained in Fig. 6. Following these steps, R1 will get the network approval and move to PA to get the ball. As shown in Fig. 8, R1 reached PA. After getting network approval PA handed over the ball to R1. The ball count at PA is changed to 0 from 1 and the ball is with R1 indicating the approved exchange of ball between R1 and PA. R1 moving towards PB to drop the ball. As shown in Fig. 9, R1 reached PB. After getting network approval PB received the ball from R1. The ball count at PB changed from 0 to 1 and R1 moves without ball indicating the approved exchange of ball between R1 and PB. Once its task is done, R1 is moving back to its station S1. As shown in Fig. 10, while R1 is returning to its stations, R2 got the network approval and moving to PB to get the ball. After getting network approval PB handed over the ball to R2. The ball count at PB is changed to 0 from 1 and the ball is with R2 indicating the approved exchange of ball between R2 and PB. R2 moving towards PC to drop the ball. As shown in Fig. 11, R2 reached PC. After getting network approval, PC received the ball from Re. The ball count at PC changed from 0 to 1 and R2 moves without ball indicating the approved exchange of ball between R2 and PC. Once its task is done, R2 is moving back to its station S2. 6.2 Stage-II With Malicious or Malfunctioning Participant in The Network The Fig. 12 is a blockchain based decentralised swarm network similar to the network shown in Fig. 7, except this network is initiated in attack mode to simulate a malicious or malfunctioning participant in the network. The objective of the network is still the same. Robots R1 and R2 will shift a ball from Position A(PA) to Position B(PB) and subsequently to Position C(PC). Additionally, Robot R3 at Station S3 is initiated to simulate an attack in this network. As shown in Fig. 13, after successfully dropping the ball at PC, R2 is returning to its stations S2. Simultaneously, a malfunctioning or malicious participant R3 has started from its station S3 without getting network approval and moving to PC to get the ball. As shown in Fig. 14, when R3 approached PC to get the ball, PC will not get network approval as this move is not part of original network objective. Thus, PC will not handover the ball to R3. As highlighted in red rectangles at PC, the ball count at PC remains 1 and R3 is moving to PD without ball indicating the unapproved network status for the ball exchange. The results shows that the proposed blockchain-enabled consensus algorithm helps mitigate threats created by malfunctioning or malicious robot and ensuring that any task performed by any robot in the network is validated through the DeTAV mechanism and securely authorized by the network’s leader. This ensures that only approved tasks are executed, preventing unauthorized actions like those exhibited by Robot R3 from disrupting the swarm’s legitimate operations. By integrating the RLR and DeTAV mechanisms into the swarm robotics network, this experiment demonstrates decentralized decision-making and secure consensus features of the proposed consensus algorithm to effectively safeguard against intrusions, task authenticity, and improve the overall resilience of the decentralised swarm robotic network systems. 7 Conclusion This chapter presents a detailed analysis of the proposed design to develop a new blockchain based consensus algorithm suitable for swarm robotics network. The experiment and the simulated decentralised swarm robotic network application provided a deep insight of the proposed consensus algorithm design by exploring the integration of the Rotational Leadership Role (RLR) election-based system and the Decentralized Task Authorization and Validation (DeTAV) mechanism. The core objective of this design is to prove the viability of the proposed blockchain-based consensus algorithm within a swarm robotics network. The results suggest that incorporating this novel approach can significantly enhance the overall security and reliability within the swarm network and forecasts a strong potential for decentralised applications in the real-world scenario. Declarations Author contributions Sathishkumar R. Performed analysis, defined the methodology, conducted research, and wrote the manuscript. Assoc. Prof. Ir. Dr. Muralindran M. and Dr. 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. Fundin g 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 Ghobakhloo M (2020) Industry 4.0, digitization, and opportunities for sustainability. J Clean Prod 252:119869 Dias PG, Silva MC, Rocha Filho GP, Vargas PA, Cota LP, Pessin G (2021) Swarm robotics: A perspective on the latest reviewed concepts and applications. Sensors 21(6):2062 Ranganathan S, Mariappan M (2021) and, Muthukaruppan K., Design Methodology For Using Blockchain In Swarm Robotics, 2021 IEEE 19th Student Conference on Research and Development (SCOReD), pp. 76–81. 10.1109/SCOReD53546.2021.9652778 Jensen IJ, Selvaraj DF, Ranganathan P Blockchain technology for networked swarms of unmanned aerial vehicles (UAVs)., In2019 IEEE 20th International Symposium on A World of Wireless, Mobile and Multimedia Networks(WoWMoM) 2019 Jun 10 (pp. 1–7). IEEE Haber S, Stornetta WS (1991) How to time-stamp a digital document. Springer Berlin Heidelberg Bayer D, Haber S, Stornetta WS Improving the efficiency and reliability of digital time-stamping., InSequences II: Methods in Communication, Security, and Computer Science 1993 (pp. 329–334). Springer New York Haber S, Stornetta WS Secure names for bit-strings., InProceedings of the 4th ACM Conference on Computer and Communications Security 1997 Apr 1 (pp. 28–35) Nakamoto S (2008) Bitcoin: A peer-to-peer electronic cash system Dutta P, Choi TM, Somani S, Butala R (2020) Blockchain technology in supply chain operations: Applications, challenges and research opportunities. Transp Res E 142:102067 Agbo CC, Mahmoud QH, Eklund JM Blockchain technology in healthcare: a systematic review., InHealthcare 2019 Apr 4 (Vol. 7, No. 2, p. 56). MDPI Singh PK, Singh R, Nandi SK, Ghafoor KZ, Rawat DB, Nandi S (2020) An efficient blockchain-based approach for cooperative decision making in swarm robotics. Internet Technol Lett 3(1):e140 El Haddouti S, El Kettani MD Analysis of identity management systems using blockchain technology., In2019 International Conference on Advanced Communication Technologies and Networking (CommNet) 2019 Apr 12 (pp. 1–7). IEEE Kumar K, Zindani D, Davim JP (2019 May) Industry 4.0: developments towards the fourth industrial revolution. Springer, Cham, Switzerland, p 13 Tabatabaei MH, Vitenberg R, Veeraragavan NR (2023) Understanding blockchain: Definitions, architecture, design, and system comparison. Comput Sci Rev 50:100575 Wang C, Jiang H, Zeng J, Min YU, Huang Q, Zuo Z (2021) A review of blockchain layered architecture and technology application research. Wuhan Univ J Nat Sci 26(5):14 Zhang R, Preneel B Lay down the common metrics: Evaluating proof-of-work consensus protocols' security., In2019 IEEE Symposium on Security and Privacy (SP) 2019 May 19 (pp. 175–192). IEEE Kaur S, Chaturvedi S, Sharma A, Kar J (2021) A research survey on applications of consensus protocols in blockchain. Secur Communication Networks 2021(1):6693731 Saad SM, Radzi RZ (2020) Comparative review of the blockchain consensus algorithm between proof of stake (pos) and delegated proof of stake (dpos). Int J Innovative Comput. ;10(2) Navaroj GI, Julie EG, Robinson YH (2022) Adaptive practical Byzantine fault tolerance consensus algorithm in permission blockchain network. Int J Web Grid Serv 18(1):62–82 Khan SN, Loukil F, Ghedira-Guegan C, Benkhelifa E, Bani-Hani A (2021) Blockchain smart contracts: Applications, challenges, and future trends. Peer-to-peer Netw Appl 14:2901–2925 Khettry AR, Patil KR, Basavaraju AC (2021) A detailed review on blockchain and its applications. SN Comput Sci 2(1):30 Xu X, Weber I, Staples M, Zhu L, Bosch J, Bass L, Pautasso C, Rimba P A taxonomy of blockchain-based systems for architecture design., In2017 IEEE international conference on software architecture (ICSA) 2017 Apr 3 (pp. 243–252). IEEE Hawashin D, Nemer M, Gebreab SA, Salah K, Jayaraman R, Khan MK, Damiani E (2024) Blockchain applications in UAV industry: Review, opportunities, and challenges. J Netw Comput Appl 230:103932 Ibrahim H, Shouman MA, El-Fishawy NA, Ahmed A Literature review of blockchain technology in space industry: Challenges and applications., In2021 International Conference on Electronic Engineering (ICEEM) 2021 Jul 3 (pp. 1–8). IEEE Ranganathan S, Mariappan M and, 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 Additional Declarations The authors declare no competing interests. Cite Share Download PDF Status: Posted Version 1 posted 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-7523681","acceptedTermsAndConditions":true,"allowDirectSubmit":true,"archivedVersions":[],"articleType":"Method Article","associatedPublications":[],"authors":[{"id":509490499,"identity":"807ddebe-5e22-40d1-b02b-9bc922df3d24","order_by":0,"name":"SATHISHKUMAR RANGANATHAN","email":"","orcid":"","institution":"Universiti Malaysia Sabah","correspondingAuthor":false,"prefix":"","firstName":"SATHISHKUMAR","middleName":"","lastName":"RANGANATHAN","suffix":""},{"id":509490500,"identity":"bd1c055c-2e35-492b-8a25-a1849a78f308","order_by":1,"name":"Dr. Muralindran Mariappan","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAuElEQVRIiWNgGAWjYLCCBwY2EAYP0VoSDNJI1sJwmAQtujNyH35IKDifuLb/AOODt20M0QYHCGgxu5FuLJFgcDtx240EZsO5bQy5GwhrSWOAamFgk+YlUgvzjwSDc4nbzh9g/02sFjagLQcStx1IYGMmTsuZZ2wWCQbJxttuJDZLzjknkTuToJbjacw3Pvyxk912/vDBD2/KbHL7CGlBAowNQEKCQYEELVAg30CyllEwCkbBKBjmAAAPJUbSHpoaZwAAAABJRU5ErkJggg==","orcid":"","institution":"Universiti Malaysia Sabah","correspondingAuthor":true,"prefix":"Dr.","firstName":"Muralindran","middleName":"","lastName":"Mariappan","suffix":""},{"id":509490501,"identity":"2dfc9819-0147-4313-9bef-56943526ae4c","order_by":2,"name":"Dr. Karthigayan Muthukaruppan","email":"","orcid":"","institution":"ASRIX PRIME BERHAD","correspondingAuthor":false,"prefix":"Dr.","firstName":"Karthigayan","middleName":"","lastName":"Muthukaruppan","suffix":""}],"badges":[],"createdAt":"2025-09-03 06:58:45","currentVersionCode":1,"declarations":{"humanSubjects":false,"vertebrateSubjects":false,"conflictsOfInterestStatement":false,"humanSubjectEthicalGuidelines":false,"humanSubjectConsent":false,"humanSubjectClinicalTrial":false,"humanSubjectCaseReport":false,"vertebrateSubjectEthicalGuidelines":false},"doi":"10.21203/rs.3.rs-7523681/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-7523681/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":90560754,"identity":"e12be473-f449-4f97-8ab6-1d5cc4952359","added_by":"auto","created_at":"2025-09-04 06:05:52","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":58585,"visible":true,"origin":"","legend":"\u003cp\u003eBlockchain infrastructure model\u003c/p\u003e","description":"","filename":"1.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/799bd683ab68149ecc395caa.png"},{"id":90561503,"identity":"82c976fe-1218-4e59-97c4-c7e596f10a61","added_by":"auto","created_at":"2025-09-04 06:13:52","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":97579,"visible":true,"origin":"","legend":"\u003cp\u003eBlockchain Layered Architecture\u003c/p\u003e","description":"","filename":"2.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/6ec4f04b3f6cdf4b87e0144b.png"},{"id":90560755,"identity":"24a2cb17-430a-47bc-b88e-ae57b72cd5ed","added_by":"auto","created_at":"2025-09-04 06:05:52","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":41120,"visible":true,"origin":"","legend":"\u003cp\u003eLeadership Election Process [25].\u003c/p\u003e","description":"","filename":"3.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/c0062e74b8625e6fe9a7f009.png"},{"id":90560759,"identity":"415f683f-a67f-4c1e-9c19-821a6d5bd3f7","added_by":"auto","created_at":"2025-09-04 06:05:52","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":118346,"visible":true,"origin":"","legend":"\u003cp\u003eLeadership role for Mining Process [25].\u003c/p\u003e","description":"","filename":"4.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/53c9d5ca02b29328fe74c567.png"},{"id":90562777,"identity":"7632548d-857d-4d6a-a0fe-e49c67ba551d","added_by":"auto","created_at":"2025-09-04 06:37:52","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":99817,"visible":true,"origin":"","legend":"\u003cp\u003eSwarm robotics experiment setup with Blockchain integration [25].\u003c/p\u003e","description":"","filename":"5.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/a6ed3f5d8b00e11a17ddceac.png"},{"id":90560769,"identity":"9309d5ba-a983-4dd9-a1a3-d622da621d4a","added_by":"auto","created_at":"2025-09-04 06:05:52","extension":"png","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":141928,"visible":true,"origin":"","legend":"\u003cp\u003eFlow of events for Fig. 5 [25].\u003c/p\u003e","description":"","filename":"6.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/d706320984ac5316eab867ef.png"},{"id":90560765,"identity":"298643ff-0c34-43f1-87a7-3944e84d8f6f","added_by":"auto","created_at":"2025-09-04 06:05:52","extension":"png","order_by":7,"title":"Figure 7","display":"","copyAsset":false,"role":"figure","size":54551,"visible":true,"origin":"","legend":"\u003cp\u003eSoftware simulator to demonstrate the experiment as shown in Fig. 5.\u003c/p\u003e","description":"","filename":"7.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/ac1dd54b7523a8837a76e8bf.png"},{"id":90560764,"identity":"218efbb3-b2f3-4518-bdfb-c1f6fe0c18cf","added_by":"auto","created_at":"2025-09-04 06:05:52","extension":"png","order_by":8,"title":"Figure 8","display":"","copyAsset":false,"role":"figure","size":26886,"visible":true,"origin":"","legend":"\u003cp\u003eR1 moves to PB.\u003c/p\u003e","description":"","filename":"8.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/0c88bd62770de903e0d19c6c.png"},{"id":90561680,"identity":"79eb8a66-2de9-4e1b-8547-3ccee0d6cf9f","added_by":"auto","created_at":"2025-09-04 06:21:53","extension":"png","order_by":9,"title":"Figure 9","display":"","copyAsset":false,"role":"figure","size":31709,"visible":true,"origin":"","legend":"\u003cp\u003eR1 dropped the ball at PB.\u003c/p\u003e","description":"","filename":"9.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/1ffaa2c7db56f04903a1a2cf.png"},{"id":90561512,"identity":"0aec14b5-f324-498d-b822-3894795897ec","added_by":"auto","created_at":"2025-09-04 06:13:53","extension":"png","order_by":10,"title":"Figure 10","display":"","copyAsset":false,"role":"figure","size":34777,"visible":true,"origin":"","legend":"\u003cp\u003eR2 moving to PB to shift the ball to PC.\u003c/p\u003e","description":"","filename":"10.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/133be59b273ccc003bdaa66e.png"},{"id":90560791,"identity":"e907bec7-b4b3-46b3-8f15-42cbd7636f7c","added_by":"auto","created_at":"2025-09-04 06:05:53","extension":"png","order_by":11,"title":"Figure 11","display":"","copyAsset":false,"role":"figure","size":31719,"visible":true,"origin":"","legend":"\u003cp\u003eR2 dropped the ball at PC and moved back to its station S1.\u003c/p\u003e","description":"","filename":"11.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/fc7d6f882674da014e534c13.png"},{"id":90560778,"identity":"208c89c9-660d-4b84-bca4-69a379b8d235","added_by":"auto","created_at":"2025-09-04 06:05:53","extension":"png","order_by":12,"title":"Figure 12","display":"","copyAsset":false,"role":"figure","size":47553,"visible":true,"origin":"","legend":"\u003cp\u003eSimulated Swarm Robotic Network with Malicious or Malfunctioning Participant.\u003c/p\u003e","description":"","filename":"12.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/78c19e004ff2c067f699a8d5.png"},{"id":90561508,"identity":"53fe469a-ea8c-4920-a7e6-a2f5af33d4e9","added_by":"auto","created_at":"2025-09-04 06:13:52","extension":"png","order_by":13,"title":"Figure 13","display":"","copyAsset":false,"role":"figure","size":31264,"visible":true,"origin":"","legend":"\u003cp\u003eR3 moving to PC to get the ball.\u003c/p\u003e","description":"","filename":"13.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/f54edc71da7e8832d955728d.png"},{"id":90561516,"identity":"fab4b591-2395-4f55-a6cd-b6eb262498d7","added_by":"auto","created_at":"2025-09-04 06:13:53","extension":"png","order_by":14,"title":"Figure 14","display":"","copyAsset":false,"role":"figure","size":34207,"visible":true,"origin":"","legend":"\u003cp\u003eR3 moving to PD without the ball.\u003c/p\u003e","description":"","filename":"14.png","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/3f02359983e9aad8a9bcbf2d.png"},{"id":91148128,"identity":"8d1394e8-bea9-48f2-98bf-0f1f520036d4","added_by":"auto","created_at":"2025-09-12 06:42:29","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1619971,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-7523681/v1/1fc29aef-d838-4984-b0db-590ea2870ee6.pdf"}],"financialInterests":"The authors declare no competing interests.","formattedTitle":"\u003cp\u003e\u003cstrong\u003eEnhancing Swarm Robotics: A Blockchain-Based Consensus Design for Security and Efficiency\u003c/strong\u003e\u003c/p\u003e","fulltext":[{"header":"1 Introduction","content":"\u003cp\u003eIndustry 4.0 revolution is emphasizing on smart, decentralized and autonomous systems that can communicate and collaborate in real time without depending on centralized control [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e]. Inline to this advancement, Swarm Robotics is a multi-agent distributed network platform, capable of carrying out complex tasks in a highly synchronized way. Because of its collaborative nature, this technology is highly suitable for industrial applications like large area surveillance, search and rescue operations, handling hazardous environments, and smart manufacturing processes [\u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e]. However, this technology faces numerous challenges to fulfill recent demands in this field, including secured data communication, decentralized decision-making, and fault tolerance [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e]. This chapter shows new insights into existing challenges and proposes a novel solution based on blockchain technology.\u003c/p\u003e\u003cp\u003eOn the other hand, blockchain technology has been proposed to provide decision-making, security, and reliability aspects in the swarm robotics network. The decentralization of decision making holds much importance in enabling the autonomous mode of operations in a swarm robotics network. Blockchain indeed stands as a perfect solution, which helps to maintain distributed ledger and peer-to-peer properties to support the participants of the robotic network in working independently without centralized management. However, the most challenging aspect of incorporating blockchain into swarm robotics is devising a suitable consensus algorithm that can handle the real-time needs of swarming operations like fault-tolerance and scalable. Most of these blockchain-based solutions are still incapable of effectively validating task execution and restricting malicious activity across the swarm network [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e]. Consequently, our research is an important step towards more secure, robust and scalable swarm robotic systems that can work autonomously towards achieving their defined objectives.\u003c/p\u003e\u003cp\u003eRest of this paper is organized in the following sections. Section 2 details the blockchain architecture and its implementation models. Section 3 covers summary on swarm network and the importance of reaching consensus in the swarm network. Section 4 details the proposed RLR and DeTAV design. Section 5 explains the experiment setup and Sections 6 reviews the experiment results. Finally, Section 7 concludes this paper with summary on the proposed design and scope of our further research work.\u003c/p\u003e"},{"header":"2 Blockchain Architecture","content":"\u003cp\u003eBlockchain architecture defines the core structure and protocols of the decentralized ledger on how the data must be recorded, shared, or validated within a distributed network [14]. This system is generally built on network-connected computing devices with data storage capacity. Network transactions or activities are stored in the form of an interconnected chain of blocks. The data stored in these blocks is time-stamped, and immutable to ensure transparency and security properties. As shown in Fig. 1, blockchain architecture consists of several key components, including nodes, blocks, chains, and consensus mechanisms.\u003c/p\u003e\n\u003ch2\u003e2.1 \u0026nbsp; \u0026nbsp; Nodes\u003c/h2\u003e\n\u003cp\u003eNodes are the individual devices or participants in a blockchain network. Each node has a copy of the blockchain, enabling it to participate in its operations. As listed below, in general, there are 3 different types of nodes.\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eFull Nodes\u003c/em\u003e: This type of nodes will store full copy of the blockchain in its local database and perform transaction validation in the network.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eLight Nodes\u003c/em\u003e: This type of nodes does not store the entire blockchain in its local database but can perform transactions in the network. They rely on Full Nodes for transaction validation.\u003c/p\u003e\n\u003cp\u003e3. \u003cem\u003eMining Nodes\u003c/em\u003e: This type of nodes will participate in the mining process using its computational power, create new blocks and perform transaction validations in the network.\u003c/p\u003e\n\u003ch2\u003e2.2 \u0026nbsp; \u0026nbsp; Blocks\u003c/h2\u003e\n\u003cp\u003eA block is a collection of transaction data. Each block typically contains the following information.\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eBlock Header\u003c/em\u003e: Header part of the block contains metadata about the block. It\u0026rsquo;ll also have the previous block\u0026rsquo;s hash value, timestamp, nonce (used for mining), and Merkle root (hash representing all transactions in the block).\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eBlock Body\u003c/em\u003e: Body part of the block contains the list of all the actual transactions performed within the network.\u003c/p\u003e\n\u003ch2\u003e2.3 \u0026nbsp; \u0026nbsp; Chain Structure\u003c/h2\u003e\n\u003cp\u003eBlocks are linked together in chronological order to form a chain. The chain\u0026rsquo;s integrity is maintained through cryptographic hashes.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eAs shown in Fig. 1, an interlinked chain of blocks will be created by adding the hash of the previous block into the new block. This interlinked structure makes the\u0026nbsp;chain of blocks immutable. This arrangement ensures that any alteration in a block will affect all subsequent blocks, rendering the chain invalid.\u003c/p\u003e\n\u003ch2\u003e2.4 \u0026nbsp; \u0026nbsp; Layers of Blockchain Architecture\u003c/h2\u003e\n\u003cp\u003eThis section provides a comprehensive overview of the multi-layered structure of the blockchain platform, where each layer serves a distinct purpose in ensuring the efficient operation of the underlying network [15]. As portrayed in Fig. 2, the core layers of this platform are the Data, Network, Consensus, Contract, Incentive, and Application.\u0026nbsp;\u003c/p\u003e\n\u003ch3\u003e2.4.1 \u0026nbsp; \u0026nbsp; Data Layer\u003c/h3\u003e\n\u003cp\u003eData layer is the foundation of blockchain architecture. It is responsible for storing all transactional and configuration data in a secure and immutable format. Following details are part of this layer.\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eTransactions\u003c/em\u003e: Interactions between the nodes within the blockchain are recorded as transactions. Each transaction contains specific details such as sender and receiver addresses, transaction amount, and a unique identifier.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eChain Structure\u003c/em\u003e: Blockchain platform stores the data in block format. These blocks are sequentially linked using hash of the previous block to form an interlinked chain like structure. So, any modification to a block would require changing all subsequent blocks. This property helps to maintaining the immutability in the blockchain platform.\u003c/p\u003e\n\u003cp\u003e3. \u003cem\u003eMerkle Tree\u003c/em\u003e: Merkle tree structure is used to efficiently and securely verify the integrity of the transactions recorded within a block.\u0026nbsp;\u003c/p\u003e\n\u003ch3\u003e2.4.2 \u0026nbsp; \u0026nbsp;Network Layer\u003c/h3\u003e\n\u003cp\u003eNetwork layer provides the underlying infrastructure for peer-to-peer (P2P) communication in the blockchain network. This layer is critical for ensuring data synchronization and connectivity among all participants.\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eP2P Network Communication\u003c/em\u003e: This mechanism facilitates the direct exchange of information among nodes without relying on a central server, ensuring that all nodes can share and receive updates about the state of the blockchain.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eState Synchronization\u003c/em\u003e: Nodes maintain a consistent view of the blockchain through regular updates, ensuring that all participants are aligned on the current state of the ledger.\u003c/p\u003e\n\u003cp\u003e3. \u003cem\u003eTransport Protocols\u003c/em\u003e: This layer employs various transport protocols to manage how data packets are sent and received, ensuring reliable communication among nodes.\u003c/p\u003e\n\u003ch3\u003e2.4.3 \u0026nbsp; \u0026nbsp;Consensus Layer\u003c/h3\u003e\n\u003cp\u003eThe Consensus Layer plays a pivotal role in maintaining the integrity and reliability of the blockchain by establishing a protocol for agreement among nodes. It determines how transactions are verified and added to the blockchain. The consensus layer is responsible for validating the authenticity of transactions before they are added to the blockchain, preventing fraud and ensuring the network\u0026apos;s security. Some of the commonly used consensus algorithms are listed below.\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eProof of Work (PoW) [16]\u003c/em\u003e: Requires nodes (miners) to solve complex mathematical problems to validate transactions and create new blocks, consuming significant computational power.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eProof of Stake (PoS) [17]\u003c/em\u003e: Allows validators to create new blocks based on the amount of cryptocurrency they hold and are willing to \u0026quot;stake,\u0026quot; reducing energy consumption compared to PoW.\u003c/p\u003e\n\u003cp\u003e3. \u003cem\u003eDelegated Proof of Stake (DPoS) [18]\u003c/em\u003e: A variation of PoS where stakeholders elect delegates to validate transactions on their behalf, increasing efficiency and scalability.\u003c/p\u003e\n\u003cp\u003e4. \u003cem\u003ePractical Byzantine Fault Tolerance (PBFT) [19]\u003c/em\u003e: Designed for permissioned blockchains, this mechanism achieves consensus through a voting system among a limited number of trusted nodes.\u003c/p\u003e\n\u003ch3\u003e2.4.4 \u0026nbsp; \u0026nbsp;Contract Layer\u003c/h3\u003e\n\u003cp\u003eThe Contract Layer enables the automation of agreements through programmable logic embedded in the blockchain. This layer encompasses:\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eSmart Contracts [20]\u003c/em\u003e: These are self-executing contracts with the terms of the agreement directly written into code. Smart contracts automatically enforce and execute contractual obligations when predefined conditions are met, reducing the need for intermediaries and enhancing efficiency.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eExecutable Code\u003c/em\u003e: The Contract Layer allows for the deployment of various scripts and algorithms that govern interactions within the blockchain ecosystem, facilitating complex applications ranging from finance to supply chain management.\u003c/p\u003e\n\u003ch3\u003e2.4.5 \u0026nbsp; \u0026nbsp;Incentive Layer\u003c/h3\u003e\n\u003cp\u003eThe Incentive Layer is crucial for motivating participants to engage with and maintain the blockchain network. This layer includes:\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eReward Mechanisms\u003c/em\u003e: Participants (e.g., miners or validators) are incentivized through reward systems that distribute tokens or cryptocurrency for their contributions to the network, such as validating transactions or maintaining network security.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003ePenalties\u003c/em\u003e: To discourage malicious behavior, this layer may also implement penalties for nodes that attempt to undermine the network, ensuring a balanced and fair ecosystem.\u003c/p\u003e\n\u003ch3\u003e2.4.6 \u0026nbsp; \u0026nbsp;Application Layer\u003c/h3\u003e\n\u003cp\u003eThe Application Layer is the topmost layer, where user-facing applications and services interact with the blockchain. This layer involves:\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eDomain-Specific Applications\u003c/em\u003e: Applications are designed to meet the needs of specific industries or use cases, such as finance, healthcare, or supply chain management. These applications leverage the functionalities provided by the underlying blockchain layers to offer innovative solutions.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eUser Interfaces\u003c/em\u003e: This layer includes the interfaces through which end-users interact with the blockchain, such as wallets, dashboards, and other user-friendly tools that enhance accessibility and usability.\u003c/p\u003e\n\u003cp\u003eAs technology continues to evolve, advancements in these layers will likely lead to more efficient and scalable blockchain solutions.\u003c/p\u003e\n\u003ch2\u003e2.5 \u0026nbsp; \u0026nbsp; Implementation Models\u003c/h2\u003e\n\u003cp\u003eBlockchain technology classified into three categories: Public blockchains, Consortium blockchains, and Private blockchains [21] (Korpela, Hallikas, \u0026amp; Dahlberg, 2017). Each category has unique characteristics and applications, based on the factors such as access permissions, consensus mechanisms, and governance structure of the blockchain network.\u003c/p\u003e\n\u003ch3\u003e2.5.1 \u0026nbsp; \u0026nbsp; Public Blockchains\u003c/h3\u003e\n\u003cp\u003ePublic blockchains are built on a decentralized network and do not require permission from any participants and every participant in the network has access to all the information. In this way, anyone can join the network, make and endorse transactions as it is the reality of such a level of openness. This makes the environment very democratic and transparent. Good examples of public blockchains are Bitcoin and Ethereum. These blockchains use different consensus mechanisms that ensure security and reliability: the consensus of all participants in one way or another is highly important for the integrity of the blockchain. The two most widely used consensus algorithms in public blockchains are Proof of Work and Proof of Stake. Public blockchains are designed to handle applications that require quite a bit of trust without middlemen, thanks to their inherent transparency and inclusiveness.\u003c/p\u003e\n\u003ch3\u003e2.5.2 \u0026nbsp; \u0026nbsp;Consortium Blockchains\u003c/h3\u003e\n\u003cp\u003eConsortium Blockchains is also referred to as federated blockchains. It enables a pre-selected group of participants to handle and govern the blockchain network. In the case of a consortium blockchain, while information is shared across all members, processes like data modification and consensus mechanisms are permitted only for predefined groups in organizations or by individuals. It finds widespread application in sectors where collaboration among trusted third parties are needed such as the banking sector, supply chain management, and healthcare. A case in point may be where the members of consortium blockchains focus on sponsoring and tracking jointly undertaking marketing projects or collective databases of customers. In essence, this decentralization of powers prevents a single point of failure from compromising all control or decision-making authorities. Below listed are some of the examples of consortium blockchains.\u003c/p\u003e\n\u003cp\u003e1. \u003cem\u003eR3\u003c/em\u003e: A consortium of banks and financial organizations focused on the development of blockchain solutions for the financial sector.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003eEnergy Web Foundation\u003c/em\u003e: It leverages profound experience in accelerating blockchain technology for energy, which empowers decentralized solutions within the sector.\u003c/p\u003e\n\u003cp\u003e3. \u003cem\u003eB3i-Blockchain Insurance Industry Initiative\u003c/em\u003e: This initiative looks to bring more efficiency into insurance practices through the sharing of blockchain networks between insurers and reinsurers.\u003c/p\u003e\n\u003cp\u003eThe consortium blockchains have a governance structure that allows these organizations to collectively decide without bias, thus gaining trust among participants in collaboration.\u0026nbsp;\u003c/p\u003e\n\u003ch3\u003e2.5.3 \u0026nbsp; \u0026nbsp;Private Blockchains\u0026nbsp;\u003c/h3\u003e\n\u003cp\u003ePrivate blockchains are also known as permission blockchains because central authority governs them, and only anyone can access specific information or hold the right to modify something. Most often, there is one governing body within a private blockchain, operated either by one organization or a consortium with well-defined hierarchies and roles. For example, a payroll system using blockchain might limit access solely to HR personnel and specific departments within an organization. In private blockchains, the central authority governs who can read, write, or participate in the blockchain thus making it highly restricted unlike in public blockchains. Therefore, the consensus mechanism used by private block chains is most of the time a single central authority instruction rather than a general agreement as it is in public block chains. This could make decision processes easier and increase efficiency but at the expense of some degree of decentralization and transparency.\u003c/p\u003e\n\u003ch2\u003e2.6 \u0026nbsp; \u0026nbsp; Evolution and Taxonomy of Blockchain Architectures\u003c/h2\u003e\n\u003cp\u003eThis section in turn explains the general pattern and changes in relation to blockchain architecture over the years advancing to a categorization that enables developers to choose appropriate platforms for relevant applications [22].\u0026nbsp;\u003c/p\u003e\n\u003ch3\u003e2.6.1 \u0026nbsp; \u0026nbsp; Single-Ledger-Based Architecture\u003c/h3\u003e\n\u003cp\u003e1. \u003cem\u003ePublic Networks\u003c/em\u003e: Introduced with platforms like Ethereum, these allow open participation but raise privacy concerns due to publicly accessible transaction data.\u003c/p\u003e\n\u003cp\u003e2. \u003cem\u003ePrivate Networks\u003c/em\u003e: This architecture is\u0026nbsp;designed to address privacy issues, by incorporating a certificate authority and handshaking mechanisms to manage user access and authenticate nodes. Platforms such as Hyperledger Burrow and Multichain exemplify this architecture.\u003c/p\u003e\n\u003cp\u003e3. \u003cem\u003eHybrid Networks\u003c/em\u003e: Developed to facilitate private transactions within a public ledger, platforms like Quorum implement encryption techniques to maintain data confidentiality while enabling public participation.\u003c/p\u003e\n\u003ch3\u003e2.6.2 \u0026nbsp; \u0026nbsp;Multi-Ledger-Based Architecture\u0026nbsp;\u003c/h3\u003e\n\u003cp\u003eMulti-Ledger based blockchain architecture was introduced by Hyperledger Fabric network. This architecture supports confidential transactions among specific participants within the network. This mechanism creates a network of channels for secure communication. Transaction validation involves multiple endorsing peers to enhance the security and privacy within the network environment.\u003c/p\u003e\n\u003ch3\u003e2.6.3 \u0026nbsp; \u0026nbsp;Interoperability-Based Architecture\u003c/h3\u003e\n\u003cp\u003eAs the blockchain platform implementation surges across various application sectors, interoperability between various types of blockchain implementations has become essential. Platforms like Inter-Blockchain Communication (IBC), cross-chain bridges. etc. have been developed to allow communication between public and private blockchains, enhancing security through mechanisms like anchoring, which links the sidechains to mainchains.\u003c/p\u003e"},{"header":"3 Swarm Robotics Network","content":"\u003cp\u003eSwarm robotics is an advanced branch of multi-robot systems which allows autonomous robots to work together without a centralized chain of command [23]. The core notion is based on the concept of decentralized and self-organization whereby network members of the swarm can take some local autonomous decisions. One of the most interesting aspects in this case is that robots in the network do not have knowledge of what every other robot is doing in the swarm, putting them at a disadvantage. Thus, they depend on a decentralized consensus mechanism within their network. Thus, information of the individual member is shared with other nodes and the swarm is able to build the complete picture of the goal of the network. For example, if a robot meets an obstacle, or a portion of the task is completed, the robot will pass such information to the nearest robots, thus making it possible for the entire group to change its plan within the performance of the task. The beauty of this system lies in its scalability and fault tolerance. Since robots are independent and decentralized, if one or several robots fail, the others can compensate by continuing to share information and maintain the network\u0026rsquo;s objective. This behavior is often modelled after natural systems, like ant colonies or flocks of birds, where simple interactions between individuals lead to complex, coordinated behaviors.\u003c/p\u003e\n\u003ch2\u003e3.1\u0026nbsp; \u0026nbsp; \u0026nbsp;Importance of Consensus algorithms\u003c/h2\u003e\n\u003cp\u003eThe concept of Coordinated Industrial Robotics is particularly interesting because the current trend is rapidly moving towards the integration of smarter, decentralized, and more autonomous cyber-physical systems that can operate together in a highly coordinated way. These systems, composed of several robotic agents acting in close cooperation, are the modern trends in industrial automation. A swarm of robot systems is characterized by real time communication and effective, action driven integration of all individual robots towards the shared goal irrespective of their local perspective. As a result, the strength of the communication and the efficiency of the algorithms employed for decentralized decision-making processes determine the viability of swarm robotics applications. This decentralization opens up a broad scope for new innovations in future robotics construction, offering dynamic and dominant systems in the robotics construction parameters. However, even the more sophisticated swarm networks are facing challenges while implementing consensus algorithms to handle data validation, security, and efficiency within these coordinated networks where decentralized control and decision-making are essential [24]. As described below, there are two critical limitations that hinder the full potential of coordinated robotics networks.\u003c/p\u003e\n\u003ch3\u003e3.1.1\u0026nbsp; \u0026nbsp; \u0026nbsp;Inefficient Consensus Algorithms\u003c/h3\u003e\n\u003cp\u003eConsensus algorithms designed for finance and other trade networks are not suitable to support the basic needs of any swarm robotics network. These systems demand high standards of data validation, security, and overall operational efficiency. Without robust and efficient consensus protocols, it becomes difficult for the network to achieve reliable performance, especially when operating under dynamic conditions or in larger, more complex swarm setups.\u0026nbsp;\u003c/p\u003e\n\u003ch3\u003e3.1.2\u0026nbsp; \u0026nbsp; \u0026nbsp;Inability to Detect and Isolate Malicious Robots\u003c/h3\u003e\n\u003cp\u003eThese consensus algorithms also face limitations to detect and eliminate malfunctioning or malicious actors in a swarm of robots. Within a distributed network in which trust and collaboration is stressed, even one or several robots, either faulty or purposefully defective, can render the whole system useless and unsafe. Addressing these limitations is essential to making coordinated industrial and swarm robotics systems more reliable and efficient.\u003c/p\u003e"},{"header":"4 Proposed Consensus Algorithm for Swarm Networks","content":"\u003cp\u003eThe study suggests designing a consensus mechanism for the Blockchain that is tailored to the needs of these swarm robotic networks. This custom solution along with Blockchain technology, which possesses significant advantages in distributed data storage, decentralized governance, security, will be the right fit to address the needs of swarm robotic networks [3, 25]. The research methodology will focus on the following areas:\u003c/p\u003e\n\u003cp\u003e1 \u003cem\u003eAnalyzing Blockchain\u0026rsquo;s Distributed Data and Decision-Making Capabilities\u003c/em\u003e: We will examine how blockchain\u0026rsquo;s distributed ledger technology can be integrated into a robot network to improve decision-making efficiency and data validation. By leveraging blockchain, we aim to eliminate many of the centralized bottlenecks that currently hinder robot coordination.\u003c/p\u003e\n\u003cp\u003e2 \u003cem\u003eSimplifying Blockchain Architecture\u003c/em\u003e: The complexities found in blockchain\u0026apos;s Consensus, Incentive, and Network and Security layers often hinder its adoption in real-time systems. Our approach will involve streamlining these layers to better suit the real-time operational needs of coordinated robotics, without compromising the security and trust that blockchain provides.\u003c/p\u003e\n\u003cp\u003e3 \u003cem\u003eDeveloping an Efficient Consensus Algorithm\u003c/em\u003e: A key outcome of the research will be the creation of an efficient consensus algorithm, purpose-built for coordinated industrial robots. This algorithm will be designed to ensure rapid and secure data validation, while also providing the resilience needed to handle the dynamic environments in which industrial and swarm robots operate.\u003c/p\u003e\n\u003cp\u003e4 \u003cem\u003eDesigning an Experiment Setup\u003c/em\u003e: The study will include a detailed experiment setup to test the integration of blockchain with coordinated industrial robots. We will assess its impact on improving performance, enhancing communication reliability, and bolstering overall security.\u003c/p\u003e\n\u003ch2\u003e4.1 Rotational Leadership Role (RLR):\u0026nbsp;\u003c/h2\u003e\n\u003cp\u003eThe idea of Rotational Leadership Role (RLR) is derived from Raft, voting based consensus algorithm, designed to resolve fault tolerance and improve the efficiency of mechanisms for log or state replication. Raft is ideal for practical systems requiring distributed state consensus [25]. Not only does it maintain a level of redundancy and consistency within a distributed system, but it also provides a way of recovery from failures if most participants in the system are still in working order. This algorithm satisfies the requirement of upholding a single system image by ensuring that distinct participants collectively resolve the state of the system as one regardless of the presence of some network participants. RLR core structure of the proposed consensus algorithm. This model applies the improvised leader election process in which leader roles are distributed among members of the network over time. Proposals for leader candidates can be made by any member of the network for a limited period during an election cycle. Leaders are elected and qualifications for the position of Leader can be attained after participation in an open contest by any participant node of the network. When a leader is elected, their leadership role is only limited for the duration of that term. At the end of the term, defined by a predetermined time interval, a fresh round of elections is held to choose a new leader for the next term. The plurality voting mechanism ensures that no more than one leader is elected per term, maintaining the integrity of the leadership structure.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eFig. 3 in the paper illustrates the leader election process in detail, showcasing how the consensus algorithm facilitates this rotation of leadership. As part of their leadership duties, the elected leader is responsible for the following key tasks:\u003c/p\u003e\n\u003cp\u003e1 \u003cem\u003eNetwork Synchronization and Fault Tolerance\u003c/em\u003e: The leader ensures that all network participants remain in sync, maintaining the fault-tolerant structure of the network.\u003c/p\u003e\n\u003cp\u003e2 \u003cem\u003eManagement of Token Cache and Cache Synchronization\u003c/em\u003e: The leader manages the token cache and oversees synchronization between network participants to maintain consistency across the system.\u003c/p\u003e\n\u003cp\u003e3 \u003cem\u003eConsolidation of Validated Transactions\u003c/em\u003e: The leader consolidates all validated transactions conducted by participants within the network.\u003c/p\u003e\n\u003cp\u003e4 \u003cem\u003eCreation of New Blocks\u003c/em\u003e: Once the transactions have been agreed upon, the leader creates a new block representing these transactions.\u003c/p\u003e\n\u003cp\u003e5 \u003cem\u003eBlock Distribution\u003c/em\u003e: Finally, the leader shares the newly created block with all network participants, ensuring that the distributed ledger remains up-to-date and accurate.\u003c/p\u003e\n\u003cp\u003eBy leveraging this rotational leadership and voting-based consensus mechanism, the system ensures equitable participation among network members and maintains consistency and fault tolerance, even in the face of failures.\u003c/p\u003e\n\u003ch2\u003e4.2 \u0026nbsp; \u0026nbsp; Decentralized Task Authorization and Validation (DeTAV)\u0026nbsp;\u003c/h2\u003e\n\u003cp\u003eThe Decentralized Task Authorization and Validation mechanism proposed here enhances process security through a two-tier, dynamic, token-based validation system. This approach builds on the Rotational Leadership Role (RLR), which governs leadership and task distribution in the swarm network [25]. There are 2 aspects of network security we are considering for the swarm robotics network.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e1 \u003cem\u003eCommunication \u0026amp; Data Security\u003c/em\u003e: By default, Blockchain networks use unique cryptographic signature and hash functions to ensure the network data security.\u003c/p\u003e\n\u003cp\u003e2 \u003cem\u003eProcess Security\u003c/em\u003e: Most of the current consensus algorithms do not consider the processes that individual participant of the swarm network is contributing. This paper will concentrate on this gap to ensure process or task level security and achieving objective based consensus among participants of swarm network. This will prevent any accidental damage to the participants or to the process and eliminate the threat of giving network control to faulty or intruding robots in the swarm network.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eAt the start of each term, the elected leader issues Request Tokens (RT) to all participants in the network. The RT is renewed by the leader at the beginning of each term, ensuring that no participant can misuse previously issued tokens, thereby safeguarding the network from unauthorized actions. Participant must present their RT within the network for validation and task authorisation. The network then validates the RT, and the leader issues an Approval Token (AT) to the requesting participant. This AT effectively binds the participant to their task. Because of this authorisation process, the entire swarm network remains aware of who is performing which task, and by when, thereby enhancing transparency across the network. Fig. 4 illustrates the integration of the Rotational Leadership Role (RLR) with the DeTAV mechanism. This forms the core component of the proposed lightweight blockchain-based consensus algorithm. This method eliminates all the typical complexities like solving computational puzzles or executing heavy logic processes generally seen in mining operations. This makes the system more efficient and tailored for the decentralized nature of the swarm robotics, where the computing power of individual robots may be very limited.\u003c/p\u003e\n\u003cp\u003eBoth RLR and DeTAV processes of the proposed solution provide a secure, and efficient framework for task validation and management in the swarm robotic network without having unnecessary computational overhead. This solution significantly enhances the overall security and performance of the coordinated swarm robotics system. This enhanced solution also removes the dominance created by individual robots with a high percentage of ownership / stake in the swarm robotics network. The hypothesis of this proposed solution is to reduce the processing load of individual robots, improving the performance and ensure the process security aspects of the swarm network. More details on the results will be added based on further experiments of the proposed solution.\u003c/p\u003e"},{"header":"5 Experiment Setup","content":"\u003cp\u003eThis section outlines a simple experimental setup designed to demonstrate the application of the proposed Rotational Leadership Role (RLR) and Decentralized Task Authorization and Validation (DeTAV) based consensus algorithm in a swarm robotics network, as depicted in Fig. 5. In this experiment, three robots (R1, R2, and R3) interact with four ball holders positioned at A, B, C, and D. The primary objective of the network is to move a ball sequentially from position A to B, and then from B to C, following a predefined sequence.\u003c/p\u003e\n\u003cp\u003eThe event flow, illustrated in Fig. 6, explains the tasks performed by each robot in the swarm network according to the pre-configured setup seen in Fig. 5. In this scenario, without the integration a suitable decentralised system like blockchain, these robots operate in isolation, where no consensus is established regarding the exchange of information within the swarm. This leads to various challenges, such as ensuring the safety of individual robots, detecting faulty or malicious behaviors, verifying the authenticity of shared data, and reaching consensus among the robots. To address these challenges, this experimental setup integrates the proposed private blockchain solution to introduce decentralized process-based decision-making thus enhancing the network security. The integration of the proposed solution ensures that all actions within the swarm network are verified and authorized, thus mitigating risks related to intrusions or faulty behavior.\u003c/p\u003e\n\u003cp\u003eThe above process flow explains the DeTAV\u0026rsquo;s multi-level token-based process validation using the sequence depicted in the experimental setup in Fig. 5. The process is aimed mainly to prevent any unauthorized tasks within the swarm network and ensure the network security. The following steps are illustrated assuming Robot R2 is the leader of the current term of the network.\u003c/p\u003e\n\u003cp\u003e1 As the leader of the current term, R2 sends renewed Request Tokens (RT) to R1, Position A, B \u0026amp; C for current term.\u003c/p\u003e\n\u003cp\u003e2 Before starting its task, R1 will share its RT with network participants and request for approval to shift the ball from Position A (PA) to B (PB).\u003c/p\u003e\n\u003cp\u003e3 Based on the proposed solution, network reaches consensus on R1\u0026rsquo;s request. R2 will send the Approval Token (AT) to R1 to perform its task.\u003c/p\u003e\n\u003cp\u003e4 R1 will move from station S1 to PA, hand over the AT and request for ball.\u003c/p\u003e\n\u003cp\u003e5 Before handing over the ball, PA will share the AT with network participants for validation.\u003c/p\u003e\n\u003cp\u003e6 Again, network reaches consensus on AT and R2, as a leader, will confirm back to PA to release the ball to R1.\u003c/p\u003e\n\u003cp\u003e7 Based this approval, PA will hand over the ball to R1.\u003c/p\u003e\n\u003cp\u003e8 After receiving the ball from PA, R1 will move to drop the ball at PB.\u003c/p\u003e\n\u003cp\u003e9 Before accepting the ball from R1, steps 5 and 6 will be repeated by PB.\u003c/p\u003e\n\u003cp\u003e10 Steps 3 to 8 will be repeated for R2 to shift ball from PB to PC.\u003c/p\u003e\n\u003cp\u003e11 Steps 10 to 12 will be repeated for every action to validate the objective before concluding the network actions.\u003c/p\u003e"},{"header":"6 Experiment Results","content":"\u003cp\u003eA software-based robotic network simulator has been created to demonstrate the objective of the experiment setup shown in Fig. 5. Fig. 7 illustrates the decentralised swarm robotic network application. As highlighted in red rectangles in the below Fig. 7, this simulator is designed with functions to setup the environment and to start, stop and reset the experiment setup. It has an option to simulate network attack by malfunctioning or malicious robots in the network to demonstrate the network security.\u0026nbsp;\u003c/p\u003e\n\u003ch2\u003e6.1 \u0026nbsp; \u0026nbsp; Stage-I Without Malicious or Malfunctioning Participant in The Network\u003c/h2\u003e\n\u003cp\u003eTo start this experiment, initially this setup is created with 2 robot workstations named S1 \u0026amp; S2 with 1 robot each. Robot R1 at station S1 \u0026amp; robot R1 at S2. A robot workstation is designed to hold robots before and after their task. A ball is placed at Position A. As explained above in the setup 5, this experiment begins with Robot R1 at S1 moving the ball from Position A(PA) to Position B(PB). Subsequently, Robot R2 at S2 shifts the ball from Position B to Position C(PC), successfully fulfilling the original objective of the network. All the stations, robots and ball positions will work with each other as per the proposed consensus mechanism explained in Fig. 6. Following these steps, R1 will get the network approval and move to PA to get the ball.\u003c/p\u003e\n\u003cp\u003eAs shown in Fig. 8, R1 reached PA. After getting network approval PA handed over the ball to R1. The ball count at PA is changed to 0 from 1 and the ball is with R1 indicating the approved exchange of ball between R1 and PA. R1 moving towards PB to drop the ball.\u003c/p\u003e\n\u003cp\u003eAs shown in Fig. 9, R1 reached PB. After getting network approval PB received the ball from R1. The ball count at PB changed from 0 to 1 and R1 moves without ball indicating the approved exchange of ball between R1 and PB. Once its task is done, R1 is moving back to its station S1.\u003c/p\u003e\n\u003cp\u003eAs shown in Fig. 10, while R1 is returning to its stations, R2 got the network approval and moving to PB to get the ball. After getting network approval PB handed over the ball to R2. The ball count at PB is changed to 0 from 1 and the ball is with R2 indicating the approved exchange of ball between R2 and PB. R2 moving towards PC to drop the ball.\u003c/p\u003e\n\u003cp\u003eAs shown in Fig. 11, R2 reached PC. After getting network approval, PC received the ball from Re. The ball count at PC changed from 0 to 1 and R2 moves without ball indicating the approved exchange of ball between R2 and PC. Once its task is done, R2 is moving back to its station S2.\u003c/p\u003e\n\u003ch2\u003e6.2 \u0026nbsp; \u0026nbsp; Stage-II With Malicious or Malfunctioning Participant in The Network\u003c/h2\u003e\n\u003cp\u003eThe Fig. 12 is a blockchain based decentralised swarm network similar to the network shown in Fig. 7, except this network is initiated in attack mode to simulate a malicious or malfunctioning participant in the network. The objective of the network is still the same. Robots R1 and R2 will shift a ball from Position A(PA) to Position B(PB) and subsequently to Position C(PC). Additionally, Robot R3 at Station S3 is initiated to simulate an attack in this network.\u003c/p\u003e\n\u003cp\u003eAs shown in Fig. 13, after successfully dropping the ball at PC, R2 is returning to its stations S2. Simultaneously, a malfunctioning or malicious participant R3 has started from its station S3 without getting network approval and moving to PC to get the ball.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eAs shown in Fig. 14, when R3 approached PC to get the ball, PC will not get network approval as this move is not part of original network objective. Thus, PC will not handover the ball to R3. As highlighted in red rectangles at PC, the ball count at PC remains 1 and R3 is moving to PD without ball indicating the unapproved network status for the ball exchange.\u0026nbsp;\u003c/p\u003e\n\u003cp\u003eThe results shows that the proposed blockchain-enabled consensus algorithm helps mitigate threats created by malfunctioning or malicious robot and ensuring that any task performed by any robot in the network is validated through the DeTAV mechanism and securely authorized by the network\u0026rsquo;s leader. This ensures that only approved tasks are executed, preventing unauthorized actions like those exhibited by Robot R3 from disrupting the swarm\u0026rsquo;s legitimate operations. By integrating the RLR and DeTAV mechanisms into the swarm robotics network, this experiment demonstrates decentralized decision-making and secure consensus features of the proposed consensus algorithm to effectively safeguard against intrusions, task authenticity, and improve the overall resilience of the decentralised swarm robotic network systems.\u003c/p\u003e"},{"header":"7 Conclusion","content":"\u003cp\u003eThis chapter presents a detailed analysis of the proposed design to develop a new blockchain based consensus algorithm suitable for swarm robotics network. The experiment and the simulated decentralised swarm robotic network application provided a deep insight of the proposed consensus algorithm design by exploring the integration of the Rotational Leadership Role (RLR) election-based system and the Decentralized Task Authorization and Validation (DeTAV) mechanism. The core objective of this design is to prove the viability of the proposed blockchain-based consensus algorithm within a swarm robotics network. The results suggest that incorporating this novel approach can significantly enhance the overall security and reliability within the swarm network and forecasts a strong potential for decentralised applications in the real-world scenario.\u003c/p\u003e"},{"header":"Declarations","content":"\u003cp\u003e\u003cstrong\u003eAuthor contributions\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSathishkumar R.\u003c/strong\u003e Performed analysis, defined the methodology, conducted research, and wrote the manuscript. \u003cstrong\u003eAssoc. Prof. Ir. Dr.\u003c/strong\u003e \u003cstrong\u003eMuralindran M.\u003c/strong\u003e and \u003cstrong\u003eDr.\u003c/strong\u003e \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\u003eFundin\u003c/strong\u003e\u003cstrong\u003eg\u003c/strong\u003e There was no funding.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eData availability\u0026nbsp;\u003c/strong\u003e\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\u003eEthics approval and consent to participate\u0026nbsp;Not applicable.\u003c/p\u003e\n\u003cp\u003eConsent for publication\u0026nbsp;Not applicable.\u003c/p\u003e\n\u003cp\u003eCompeting interests\u0026nbsp;The authors declare no competing interests.\u003c/p\u003e\n\u003cp\u003eAdditional information\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCorrespondence\u0026nbsp;\u003c/strong\u003eand requests for materials should be addressed to corresponding author\u0026nbsp;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\u003cli\u003e\u003cspan\u003eGhobakhloo M (2020) Industry 4.0, digitization, and opportunities for sustainability. J Clean Prod 252:119869\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eDias PG, Silva MC, Rocha Filho GP, Vargas PA, Cota LP, Pessin G (2021) Swarm robotics: A perspective on the latest reviewed concepts and applications. Sensors 21(6):2062\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eRanganathan S, Mariappan M (2021) and, Muthukaruppan K., Design Methodology For Using Blockchain In Swarm Robotics, 2021 IEEE 19th Student Conference on Research and Development (SCOReD), pp. 76\u0026ndash;81. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1109/SCOReD53546.2021.9652778\u003c/span\u003e\u003cspan address=\"10.1109/SCOReD53546.2021.9652778\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eJensen IJ, Selvaraj DF, Ranganathan P Blockchain technology for networked swarms of unmanned aerial vehicles (UAVs)., In2019 IEEE 20th International Symposium on A World of Wireless, Mobile and Multimedia Networks(WoWMoM) 2019 Jun 10 (pp. 1\u0026ndash;7). IEEE\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eHaber S, Stornetta WS (1991) How to time-stamp a digital document. Springer Berlin Heidelberg\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eBayer D, Haber S, Stornetta WS Improving the efficiency and reliability of digital time-stamping., InSequences II: Methods in Communication, Security, and Computer Science 1993 (pp. 329\u0026ndash;334). Springer New York\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eHaber S, Stornetta WS Secure names for bit-strings., InProceedings of the 4th ACM Conference on Computer and Communications Security 1997 Apr 1 (pp. 28\u0026ndash;35)\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eNakamoto S (2008) Bitcoin: A peer-to-peer electronic cash system\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eDutta P, Choi TM, Somani S, Butala R (2020) Blockchain technology in supply chain operations: Applications, challenges and research opportunities. Transp Res E 142:102067\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eAgbo CC, Mahmoud QH, Eklund JM Blockchain technology in healthcare: a systematic review., InHealthcare 2019 Apr 4 (Vol. 7, No. 2, p. 56). MDPI\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eSingh PK, Singh R, Nandi SK, Ghafoor KZ, Rawat DB, Nandi S (2020) An efficient blockchain-based approach for cooperative decision making in swarm robotics. Internet Technol Lett 3(1):e140\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eEl Haddouti S, El Kettani MD Analysis of identity management systems using blockchain technology., In2019 International Conference on Advanced Communication Technologies and Networking (CommNet) 2019 Apr 12 (pp. 1\u0026ndash;7). IEEE\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eKumar K, Zindani D, Davim JP (2019 May) Industry 4.0: developments towards the fourth industrial revolution. Springer, Cham, Switzerland, p 13\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eTabatabaei MH, Vitenberg R, Veeraragavan NR (2023) Understanding blockchain: Definitions, architecture, design, and system comparison. Comput Sci Rev 50:100575\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eWang C, Jiang H, Zeng J, Min YU, Huang Q, Zuo Z (2021) A review of blockchain layered architecture and technology application research. Wuhan Univ J Nat Sci 26(5):14\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eZhang R, Preneel B Lay down the common metrics: Evaluating proof-of-work consensus protocols' security., In2019 IEEE Symposium on Security and Privacy (SP) 2019 May 19 (pp. 175\u0026ndash;192). IEEE\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eKaur S, Chaturvedi S, Sharma A, Kar J (2021) A research survey on applications of consensus protocols in blockchain. Secur Communication Networks 2021(1):6693731\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eSaad SM, Radzi RZ (2020) Comparative review of the blockchain consensus algorithm between proof of stake (pos) and delegated proof of stake (dpos). Int J Innovative Comput. ;10(2)\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eNavaroj GI, Julie EG, Robinson YH (2022) Adaptive practical Byzantine fault tolerance consensus algorithm in permission blockchain network. Int J Web Grid Serv 18(1):62\u0026ndash;82\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eKhan SN, Loukil F, Ghedira-Guegan C, Benkhelifa E, Bani-Hani A (2021) Blockchain smart contracts: Applications, challenges, and future trends. Peer-to-peer Netw Appl 14:2901\u0026ndash;2925\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eKhettry AR, Patil KR, Basavaraju AC (2021) A detailed review on blockchain and its applications. SN Comput Sci 2(1):30\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eXu X, Weber I, Staples M, Zhu L, Bosch J, Bass L, Pautasso C, Rimba P A taxonomy of blockchain-based systems for architecture design., In2017 IEEE international conference on software architecture (ICSA) 2017 Apr 3 (pp. 243\u0026ndash;252). IEEE\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eHawashin D, Nemer M, Gebreab SA, Salah K, Jayaraman R, Khan MK, Damiani E (2024) Blockchain applications in UAV industry: Review, opportunities, and challenges. J Netw Comput Appl 230:103932\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eIbrahim H, Shouman MA, El-Fishawy NA, Ahmed A Literature review of blockchain technology in space industry: Challenges and applications., In2021 International Conference on Electronic Engineering (ICEEM) 2021 Jul 3 (pp. 1\u0026ndash;8). IEEE\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003eRanganathan S, Mariappan M and, 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\u0026ndash;6). IEEE\u003c/span\u003e\u003c/li\u003e\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":true,"hideJournal":true,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true},"keywords":"Blockchain, Swarm Robotics, Consensus algorithm, Raft, Decentralized networks security","lastPublishedDoi":"10.21203/rs.3.rs-7523681/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-7523681/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eSwarm robotics, as a distributed multi-agent platform, is well-suited for applications such as surveillance, rescue, hazardous operations, and smart manufacturing. However, current systems face critical challenges in secure communication, decentralized decision-making, and fault tolerance. Blockchain offers promising features of decentralization, security, and reliability, yet its integration into swarm robotics remains limited by the lack of suitable consensus algorithms that address real-time operational needs, task validation, and malicious activity detection. This study reviews the evolution of consensus mechanisms, analysing their security, scalability, and efficiency in decentralized networks. It highlights existing gaps in blockchain-based consensus for swarm robotics and proposes directions for developing lightweight, secure, and scalable solutions. The findings aim to advance robust consensus designs that enhance autonomy, resilience, and trust within swarm robotic networks.\u003c/p\u003e","manuscriptTitle":"Enhancing Swarm Robotics: A Blockchain-Based Consensus Design for Security and Efficiency","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2025-09-04 06:05:36","doi":"10.21203/rs.3.rs-7523681/v1","editorialEvents":[{"type":"communityComments","content":0}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"98c5d165-f79e-4468-9054-a16499e4defb","owner":[],"postedDate":"September 4th, 2025","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"posted","subjectAreas":[{"id":54111036,"name":"Robotics"},{"id":54111037,"name":"Computer Architecture and Engineering"}],"tags":[],"updatedAt":"2025-09-04T06:05:48+00:00","versionOfRecord":[],"versionCreatedAt":"2025-09-04 06:05:36","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-7523681","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-7523681","identity":"rs-7523681","version":["v1"]},"buildId":"8U1c8b4HqxoKbykW_rLl7","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}