Introduction

A mobile multi-robot system (Box 1) consists of a group of mobile autonomous robots that work together to solve a problem or perform a task1. Such multi-robot systems might be more efficient, robust and flexible than a single robot2. For example, mobile multi-robot systems can simultaneously cover and sense a large area3, can prevent a single point of failure4, can replace broken robots5 and can reconfigure their shape in accordance with a required task6. Even though most examples of mobile multi-robot systems are still demonstrated in research environments7,8 — with the notable exception of a few real-world implementations in warehouse automation9 — it is believed that once hardware and control limitations, as well as economic constraints, are overcome, their deployment in the real world will become widespread8,10,11. However, there are security aspects that are often overlooked but that will be of paramount importance for successful deployment in the real world: we need to equip these systems with properties such as accountability of behaviour12, mitigation of Byzantine faults13 (Box 1), confidentiality about the mission14 and compliance with the law15 in order to protect the robots, their owners, the environment in which they operate and the humans with whom they interact16.

Blockchain technology has been used to start addressing these issues13,17,18,19. Developed in 2008 to store transactions of the digital currency Bitcoin20, blockchain technology (Box 2) secures consensus on a decentralized ledger without the need for a trusted third party, such as a bank. A decentralized blockchain network maintains information that can be trusted even if the participating agents do not trust each other. Following the release of Bitcoin, the blockchain framework Ethereum was developed to support smart contracts (Box 2), which are tamper-proof and Turing-complete programs that are executed by each node of the blockchain network21. Even though blockchain technology was originally designed for establishing digital currencies, it holds great potential for integration into other systems, thanks to its decentralized character and fault tolerance and the availability of smart contracts.

In this Perspective, we first summarize the state of the art of blockchain-based mobile multi-robot systems22,23,24. As of the beginning of 2024, only preliminary proofs of concept for coordinating and securing multi-robot systems via smart contracts have been reported. We highlight the main challenges that need to be overcome before blockchain-based multi-robot systems can be used in real-world situations. We then discuss how blockchain not only provides new opportunities for the solution of the above-mentioned security-related issues but could also enable novel ways to organize the activities of the robots.

Blockchain-based mobile multi-robot systems

Blockchain technology can be integrated into mobile multi-robot systems using different architectures that let the robots manage the blockchain activities with various degrees of autonomy (Fig. 1). The maximum degree of autonomy is provided by Architecture 1: the blockchain is maintained exclusively by the multi-robot system. Each robot produces, broadcasts and validates the contents of new blocks, and maintains a local copy of the blockchain. This architecture is suitable for fully autonomous mobile multi-robot systems that do not require or permit any external interaction after deployment. Architecture 2 provides the minimum degree of autonomy: the mobile multi-robot system interacts with an external blockchain, for example, a publicly hosted blockchain. This architecture could be chosen if a reliable connection between the robots and an external infrastructure is available, but independence from a single controlling authority is desired. In between these two ends of the spectrum, there are potential hybrid architectures; for example, Architecture 3, a hybrid architecture where the multi-robot system hosts and maintains an internal blockchain (often called a sidechain25) which synchronizes relevant information with an externally hosted blockchain (mainchain) when possible. Architecture 3 could be chosen if only intermittent connections to an external infrastructure are possible.

Fig. 1: Architectures of blockchain-based multi-robot systems.
figure 1

Architecture 1: the blockchain is maintained exclusively by the multi-robot system. Architecture 2: the multi-robot system interacts with an external blockchain, for example, a publicly hosted blockchain. Architecture 3: the multi-robot system hosts an internal sidechain that is maintained by the robots and synchronizes relevant information with an externally hosted blockchain when possible.

Full size image

In the following, we limit the discussion of the state of the art to Architecture 1 and Architecture 2 as there is currently no research that discusses Architecture 3.

Architecture 1

Some of the first attempts to use blockchain technology in mobile multi-robot systems have studied the architecture in which the blockchain was maintained by the robots themselves (Fig. 1, Architecture 1). The initial goal was to demonstrate that security issues in multi-robot systems (in particular, in robot swarms with only local communication capabilities) could be handled using smart contracts. Securing robots in a robot swarm via a smart contract was first experimentally demonstrated in 2018 with a simulated robot swarm that maintained an internal Ethereum blockchain, where each robot was a blockchain node13. A smart contract enabled the robot swarm to detect inconsistencies in robots’ behaviours (some of the robots were Byzantine), demonstrating how blockchain technology could add a security layer on top of existing swarm robotics algorithms in a binary decision-making scenario. The work was then extended to demonstrate the collective estimation of an environmental feature: a reputation management system was implemented in a smart contract by assigning a trust value to the robots in the swarm, over time neutralizing the misleading estimates of Byzantine robots26. A comparison between a robot swarm controlled by a smart contract and one using consensus protocols available in the literature showed that smart contracts could identify and exclude Byzantine robots, whereas the existing consensus protocols failed27. Importantly, the robot swarms controlled by the smart contracts were also resilient to Sybil attacks27 — attacks in which a small minority of robots forge many fake identities to try and gain control over the robot swarm.

The first implementations on real robots demonstrated the practicality of operating blockchain software within a swarm of physical robots (considering their computing power, random-access memory and storage capabilities)17,28. Exploiting the tamper-proof crypto tokens offered by blockchain technology enabled a blockchain-based token economy in the robot swarms. Robots could earn crypto tokens by sending information that was judged useful by the smart contract, and would lose crypto tokens otherwise. This design ensured that the number of crypto tokens owned by Byzantine robots would decrease over time, making it impossible for them to continue participating in the token economy17.

Besides securing robot swarms, smart contracts can also coordinate and supervise the actions of individual robots in multi-robot systems29, aggregating information gathered by the individual robots, and then performing group-level decisions that improve the performance and efficiency of the entire system.

Architecture 2

Architecture 2 is employed when mobile multi-robot systems exploit a blockchain that is hosted by an external infrastructure (Fig. 1, Architecture 2). This is an interesting approach when a stable connection between the robots and the external blockchain nodes can be established or when the data stored on the blockchain need to be accessed by other parties during the robots’ operation.

Similar to Architecture 1, Architecture 2 can be employed to increase the security of a mobile multi-robot system. For example, Byzantine robots, when used in a leader–follower formation, can temporarily misguide their peers. This misguidance, however, can eventually be detected and undone by analysing the transaction history on the external blockchain30. An external blockchain can also be employed to improve data integrity and protection against malicious attacks31.

Smart contracts residing on an external blockchain have also been used for path planning in multi-robot systems: when all robots store their planned paths on the blockchain, they can detect whether their path would lead to collisions with other robots and adapt the path accordingly. This path planning is enabled by the blockchain’s shared data storage. Performing the collision detection can be done using an off-chain planner32 or entirely on a smart contract18. In 2021, a first proof of concept demonstrated the use of a reward system, regulated by a smart contract, to incentivize surveying points of interest by multiple unmanned aerial vehicles. A distributed ledger, originally developed for the Internet of Things, that employs a directed acyclic graph (DAG) in its architecture was used18. In a similar example, smart contracts were employed to assign different roles to robots (for example, the role of worker or the role of distributing crypto tokens as a reward) to incentivize the completion of a collaborative task19. This work was then extended by showing how robots in a heterogeneous multi-robot system can allocate tasks (such as object retrieval or object transportation) in a warehouse application using smart contracts33,34.

External blockchains have also been proposed as a means for data-sharing between humans, robots and organizations, for example, to store personal data of patients and protect their privacy when a robot needs access to the data35. Motivated by the COVID-19 crisis, a framework based on the combination of blockchain and multi-robot systems was proposed for battling pandemics through spotting lockdown violations or delivering medication36.

Smart contracts residing on an external blockchain can interface with robots, building the basis for human to robot economic transactions and robots-as-a-service applications37. The Autonomous Intelligent Robot Agent (AIRA) project proposes proof-of-concept software for such applications, exploiting smart contracts on an external Ethereum blockchain to hire multi-robot systems composed of unmanned aerial vehicles38.

Challenges for blockchain-based mobile multi-robot systems

Blockchains were originally created to operate in networks of computers. Their use in mobile multi-robot systems requires tackling challenges caused by the mobility of the robots and by hardware constraints. In the following, we identify and discuss four main challenges that should be overcome to enable the deployment of blockchain-based mobile multi-robot systems.

Computation, storage and communication requirements

The computing power, storage and communication capabilities of robots used in mobile multi-robot systems are typically more limited than in the dedicated stationary computers employed in traditional blockchain networks — making it challenging to use computing-intensive consensus protocols such as proof of work (Box 2). Alternative consensus mechanisms have therefore been explored. An example is given by Raft39 (available in the Hyperledger Fabric blockchain framework40), which is a low-cost consensus algorithm that, however, only works under the assumption that the nodes are non-Byzantine41. Alternatively, permissioned consensus protocols, such as proof of authority, can be employed in Ethereum networks, as demonstrated on a group of 10 physical robots28 — later extended to 24 physical and 120 simulated robots17 — with limited hardware capabilities.

Although permissioned protocols enable secure and cost-effective consensus, the delays introduced by the blockchain processes could still be too high to be useful for typical applications in mobile multi-robot systems. Even though the block period (that is, the time between two consecutive blockchain blocks) can be shortened, its reduction increases the costs in terms of data storage and bandwidth, as blocks are generated more frequently and the blockchain synchronization process becomes more demanding29. Therefore, a trade-off exists between costs and delays, leading us to expect that most blockchain applications in multi-robot systems will be reserved for high-level decision-making and for security-critical applications rather than for lower-level control of individual robots.

The implementation of social consensus mechanisms based on trust graphs (see, for example, the Stellar Consensus Protocol), where the robots that are most trustworthy and active in message exchanges are trusted to produce blocks, is an alternative to the introduction of permissioned consensus protocols. The Decentralized Blocklist Protocol42 establishes a system in which robots can levy accusations of misconduct against their peers, potentially leading to diminished trust and loss of privileges for the accused robots (in the study, the simulations were performed with up to 100 robots). Another, as yet unexplored, alternative could be the extension of the concept of proof of useful work43 to a proof-of-physical-work consensus protocol13 where robots can add information to a blockchain only if they first perform some physical work, such as transporting an object — thus linking the physical world with blockchain mechanisms.

In terms of storage, every blockchain node (Box 2) needs to keep a copy of the blockchain. Although this might not be a problem for Architecture 2 that uses an external blockchain, robots in Architecture 1 and Architecture 3 need to consider storage limitations. Having intermittent access to external infrastructure would enable uploading old blocks to an external infrastructure and keeping a trimmed blockchain with the most recent blocks. Storage and communication requirements can also be reduced by storing the hash values of large data files (for example, videos or maps) on the blockchain. These hash values can be used as unique identifiers, and the larger files can be shared on request through off-chain exchanges.

Regarding communication requirements, network topologies in mobile multi-robot systems can be much more dynamic than those in networks composed of non-mobile nodes; the potentially local communication capabilities of the robots, together with the relatively high likelihood of broken robots, might lead to periods of disconnection. Suchdisconnections might affect the workings of the blockchain protocol — in particular of block production — as existing blockchain consensus protocols were not designed with these issues in mind. For example, because of potentially high partitioning in a mobile multi-robot system, proof-of-work consensus protocols might become susceptible to local majority attacks, where the largest partition creates the longest blockchain, and can therefore influence the sequence of blocks. Proof-of-authority systems might halt the production of blocks when none of the authorized block producers is reachable.

To conclude, there is a need for dedicated blockchain frameworks — or at least for making appropriate design choices in existing ones, for example, in terms of consensus protocol, block period or block size — considering the specificities of mobile multi-robot systems. The SwarmDAG protocol, for example, organizes information using a partition-tolerant distributed database based on a DAG instead of a linear blockchain44. In this way, when the multi-robot system is split into disconnected subsystems, robots can first reach a local consensus in a subnetwork partition and then a global consensus when they reunite, leading to eventual data consistency.

The implementation of DAG-based ledgers is still in an early stage and tests on real robots are limited. One advantage of DAG-based ledgers lies in their ability to append transactions in different partitions, which might improve the scalability of the system as the number of robots increases. However, this same feature makes the execution of smart contracts more challenging because DAG-based ledgers lack the inherent transaction ordering and immutability that a linear blockchain provides. The DAG-based distributed ledger framework IOTA45,46 tackles this challenge by executing smart contracts on separate blockchain layers maintained by subnetworks of nodes. However, IOTA requires a centralized coordinator on the DAG layer, thus contradicting the intended decentralized nature of the system. It remains unclear whether the added value provided by the higher partition tolerance compensates for the associated costs caused by the increased data structure complexity and for the extra challenges in achieving a consistent data state.

Blockchain architecture

The scalability issues and design trade-offs presented above bring us to the question of where to host the blockchain, that is, which architecture to choose (Fig. 1).

In Architecture 1, the blockchain network is hosted by the robots themselves that act as full blockchain nodes without any external interactions. Such an architecture is particularly interesting for the classical application domains of swarm robotics, where the robots are supposed to act fully autonomously and where a connection to the Internet or other external infrastructure is not warranted (for example, underwater or underground). In some cases — such as in heterogeneous robot swarms composed of robots with different degrees of computational capabilities — it might be possible to use the more capable robots as full nodes (they store and propagate the blockchain) and let the less capable robots act as light nodes (they interact with the blockchain through the full nodes without either storing or propagating the blockchain).

Interacting with an external blockchain (Architecture 2) can be interesting when the robots in the mobile multi-robot system can reliably connect to it. For example, if the external blockchain is a public blockchain, this architecture can enable the implementation of business models, as the crypto tokens of a public blockchain usually have a real-world monetary value. In addition, an established public blockchain provides all the necessary security features without adding considerable computational overhead to the robots. Although an external blockchain might, at first sight, resemble control via a central server, there are important differences. An external blockchain is a decentralized system and, therefore, does not exhibit a single point of failure. Additionally, any node of the external peer-to-peer network that maintains the blockchain is a possible entry point to interact with the blockchain and the mobile multi-robot system. Even if some of the blockchain nodes become unavailable, both the external blockchain and the mobile multi-robot system continue to work. The use of external blockchains also has some limitations. First, blockchains can usually be more easily accessed by outsiders than central servers, and therefore additional privacy features should be implemented. Second, blockchains can introduce longer delays in updating information than central servers, and therefore the right value for relevant parameters — such as the block period and block size — should be selected. However, parameter personalization is not always possible as external blockchains often are not customizable. Third, storing information in external blockchains can potentially be costly, and therefore it might be necessary to choose which information should be processed on-chain and which information should be processed off-chain.

We believe that a hybrid sidechain architecture (Architecture 3), which combines sidechains hosted by the robots with a mainchain hosted by an external blockchain network, could be an efficient and scalable choice. Even though the sidechains are hosted by the robots themselves, it is possible for the robots to transfer information and crypto tokens from a mainchain to the sidechains, without overloading the mainchain and without being restricted by the properties of the mainchain (such as transaction costs and long block periods). Similar to Architecture 1, in such a hybrid approach an important design choice is which robots should maintain the sidechain.

Authenticating real-world information

Whereas blockchains guarantee the integrity of the information stored in the smart contracts and the validity of their deterministic output, they cannot guarantee the validity of off-chain (real-world) inputs47,48. However, sensing, agreeing and acting on real-world states (for example, environmental conditions) and events (for example, completion of a task) is important for many mobile multi-robot system activities. The bridge between off-chain and on-chain information can be established by entities, often called oracles47, which provide external data to smart contracts.

An important design choice is whether to rely on centralized oracles (trusted third parties that feed the smart contract with the required data) or on decentralized oracles (a group of contributors that do not necessarily trust each other but try to reach a consensus on the required data). A centralized oracle can be a reasonable design choice for externally hosted blockchains. However, such a solution is not suitable for fully decentralized blockchain-based multi-robot systems, where instead decentralized oracles could be used: first, they do not exhibit a single point of failure (making them more robust than a centralized one); and, second, the contributors to decentralized oracles could be the robots of the multi-robot system themselves49. Certain robotic tasks, such as collective sensing50, can be regarded as decentralized oracle problems when the robots aggregate the individually collected information on the blockchain. Trust in and integrity of the information obtained via a decentralized oracle could be achieved through mechanisms based on cryptography49, which protect the systems from external attacks, and economics51, which regulate the exchange of crypto tokens among contributors.

Transparency, confidentiality and privacy

Although it is sometimes assumed that all blockchains provide anonymity52, in general, transactions on blockchains are publicly accessible. The purported anonymity is, in fact, pseudonymity and stems from the difficulty of matching a public key used in the blockchain to a real-world identity53. Once the real identity of a public key is exposed, however, many blockchain frameworks provide an easy-to-follow trace of the actions of this specific identity. Because transactions are publicly accessible and smart contracts are created by sending transactions, in frameworks supporting smart contracts, the compiled code is also public. Consequently, the source code can be retrieved either because the creator of the smart contract made it publicly accessible or by reverse-engineering from the compiled code.

On the one hand, such transparent open-source code can give the community the chance to detect vulnerabilities and improve the system so that it is secure and trustworthy54. Security patches can be applied either by designing smart contracts that can be upgraded at run time55 or by letting the multi-robot system use a new smart contract each time a new vulnerability is detected. On the other hand, transparency also facilitates exploits, as for example happened with an exploit in an Ethereum smart contract where an attacker was able to steal 3.6 million ether tokens (worth over US$50 million at the time) due to a vulnerability in the code56. In addition, generally, the transactions that serve as input to the functions of a smart contract are publicly accessible, making the system vulnerable to data leakages. It will be particularly important to determine how to prevent such exploits as blockchain-based multi-robot systems, due to their physicality, can pose an immediate danger to life and the environment.

Privacy-enhancing technologies can be employed to conceal the trail of transactions that is usually exposed in blockchain frameworks. To this purpose, Monero conceals the trail of transactions by employing a set of privacy-enabling features, such as ring signatures. However, Monero does not support smart contracts and in blockchain frameworks that do so, protecting privacy becomes more challenging.

There are proposals for secret smart contracts, as exemplified by the Oasis Network or by the Secret Network. These protocols, however, can require the use of specialized hardware (such as trusted execution environments57) and are, therefore, not suited for all robotic applications. In addition, current frameworks do not offer full privacy and it is still possible to read both the input and the output, that is, the transactions and the results of the execution of the smart contracts.

Another possibility is to temporarily conceal the input to smart contracts by using commitment schemes based on hashing58,59. For example, in certain applications, a smart contract might reward robots based on the quality of the information that they send (see also ‘Authenticating real-world information’). In these applications, it is important that each oracle data point is obtained independently: the robots should not copy the data from other robots without performing any sensing or action themselves. By first sending only the hash of the actual data point as a commitment, the data can initially be concealed. With a smart contract, it is possible to wait for a pre-specified number of oracle data points, and afterwards to ask the robots to reveal the actual data. Data integrity could be ensured by comparing the actual data with the previously sent hash value.

Opportunities for blockchain-based mobile multi-robot systems

Enhancing multi-robot systems through blockchain technology enables a set of opportunities that future research could exploit (see Fig. 2). Note that none of these opportunities concern the low-level control of individual robots, that likely needs to be executed using traditional off-chain control. Therefore, the designer will need, first, to understand whether a robot activity should be implemented using on-chain smart contracts, and then whether it is possible to combine the off-chain and on-chain controls using hybrid control methods.

Fig. 2: Opportunities enabled by blockchain technology for the mobile multi-robot systems of our future.
figure 2

a, By regulating decentralized autonomous organizations (DAOs) through smart contracts on the blockchain, robots and humans could make joint decisions on how to self-govern the mobile multi-robot system, for example, which robots can join or need to leave the system. b, Compliance with regulations and accountability could be achieved through online or offline analysis of the tamper-proof blockchain, where actions and decisions made by each accountable robot are logged. In this way, it is possible to exclude Byzantine robots and, potentially, sanction their owners. c, Robots trading crypto tokens as economic agents could lead to the creation of a decentralized interface between humans and multi-robot systems. Trading crypto tokens could also enable cooperation between robots as part of a robot to robot economy. d, Consistent shared data can facilitate the execution of collaborative tasks, such as simultaneous localization and mapping (SLAM) and federated learning, and can also prevent Sybil attacks. e, Smart contracts can act as a decentralized supervisor implementing system-level action policies, for example, for assigning tasks to robots according to their capabilities.

Full size image

Self-governance

Blockchain technology offers the opportunity for robots to self-bootstrap and self-govern multi-robot systems of which they are part, through decentralized autonomous organizations (DAOs). A DAO is an organization whose policy and interactions among its members are managed digitally by smart contracts60,61. Even though members of DAOs are typically humans, it is possible to conceive DAOs governed by robots or a mix of robots and humans62 (Fig. 2a) that could acquire and use voting shares in the form of DAO tokens (crypto tokens issued by the respective DAO). The governance could comprise system activities and decisions about, for example, who are the leaders for specific missions, what are the internal rules and regulations, whether the robots’ software should be updated and who are the owners of the robots.

Such governance could be particularly relevant for open multi-robot systems, which are composed of robots belonging to different stakeholders27,63 (such as individuals, companies or governmental bodies). These robots participate in a collective application but have potentially conflicting individual goals, such as maximizing individual, rather than collective, profit. We refer to such dynamic multi-robot systems as ‘open’ because robots from different parties can join and leave the systems. In an open multi-robot system, a DAO could establish an access control layer that dictates which robots can join or need to leave the system. In this case, it will be important to determine how to specify the rules for joining (for example, by voting or by DAO token acquisition) and leaving (for example, voluntary leave of the robot or forced leave due to Byzantine behaviour) the multi-robot system.

Compliance and accountability

Once mobile multi-robot systems are deployed in the real world, they should exhibit compliant behaviour: they should work as intended, comply with applicable laws and not cause any harm to humans, to the environment or to other robots15,16. Robots that do not comply with the intended behaviour — also called Byzantine robots (Box 1) — can adversely affect group performance, and even cause full system failure27.

Non-compliant robot behaviour could be detected within the multi-robot system without external interaction through the integration of a blockchain (Fig. 2b), for example, by comparing the robots’ behaviours with each other or with the agreed-upon protocol stored in a smart contract. Smart contracts can also implement anomaly detection methods to exclude Byzantine robots from participating in the multi-robot system activities and can be used to store robots’ tamper-proof reputation values. Robots that contribute valuable information for a given task could increase their reputation, whereas Byzantine robots that send misleading information (determined by an anomaly detection method) would be assigned a lower reputation. Such reputation values could then be used for weighted information aggregation so that the information contributed by robots with a higher reputation has a larger weight than information from robots with a lower reputation — preventing misbehaving robots from harming collective success.

Because a blockchain can securely exchange and store robot to robot and human to robot messages, it could also be used to analyse and monitor robots’ and people’s behaviour by external observers — both during live operation and after the completion of a mission64. In addition, the blockchain could also be used to establish accountability, and the chain of actions recorded in it could be used in law enforcement when the system did not act in compliance with applicable laws.

Robot economy

Even though blockchain technology is now used in a wide variety of applications, such as supply chain management and voting65, it was originally developed for the maintenance of decentralized digital currencies (cryptocurrencies) to execute global financial transactions (see also Box 2). Digital currencies not only enable humans to exchange tokens of value but could also enable robots to take part in economies66. Therefore, we envision robot to human economies, in which humans could hire mobile multi-robot systems for certain applications (such as mapping an unknown environment) and pay by sending crypto tokens to the systems’ accounts, establishing robots-as-a-service applications14 (Fig. 2c). Mobile multi-robot systems could also pay humans for certain tasks, such as maintenance or battery recharges.

Blockchain technology could also enable multi-robot systems to establish an economy among robots — within the multi-robot system — without the need for a centralized management of the economy. Robots that belong to different stakeholders could trade goods and services among themselves in exchange for crypto tokens. For example, flying robots could sell locations of resources, maps of the environment and navigation advice to ground robots, whereas ground robots could sell physical help in object transportation. In open multi-robot systems, such economic exchanges could enable cooperative behaviour in groups of self-interested robots. Additionally, by granting economic rewards to robots based on their performance, it could be possible to measure the reputation of a robot through the number of crypto tokens it possesses.

Data consistency

Many activities performed by mobile multi-robot systems require an agreement on the data that are shared among the robots (Fig. 2d). Synchronizing consistent and conflict-free data across the robots in a mobile multi-robot system is a challenging problem due to the potential occurrence of failed components, communication delays and attacks67. For example, a severe problem in decentralized systems is double counting, where the sender of a possibly erroneous message receives back its own message after it was disseminated in the network and treats it as a new message68. When the messages are stored and aggregated on a blockchain, such a situation can be avoided, as each message is uniquely identifiable. Whereas double counting might be unintentional, decentralized systems can also be vulnerable to intentional Sybil attacks69. During a Sybil attack, a small minority of nodes (robots in multi-robot systems) forge many fake identities to gain control over the system or interfere with its operations. A blockchain can prevent this situation by assigning unique identifiers to each robot in closed mobile multi-robot systems17 or, alternatively, by introducing scarcity into the system, for example, by charging a fee in crypto tokens for each sent message in open mobile multi-robot systems (the limiting factor is therefore the number of crypto tokens and not the number of identities)27.

Collaborative simultaneous localization and mapping (SLAM) is an example task that needs shared data in mobile multi-robot systems. For this task, a database is needed to store and aggregate the map. Although this topic is currently being discussed in the literature70,71, most of the mobile multi-robot SLAM research addresses the issue by employing centralized map aggregation. Blockchain technology has the potential to provide the necessary infrastructure for mobile multi-robot systems to achieve this in a conflict-free and distributed manner, protecting from double counting and Sybil attacks.

Data synchronization is also important for collective learning in mobile multi-robot systems. Traditional machine learning requires the transmission of all data from the robots to a server to train a machine-learning model, which can have huge memory and communication costs. Federated learning is a technique where the devices (robots in this case) train a model locally and then exchange only the learned parameters instead of the raw data72. This technique is advantageous as it increases privacy, reduces data exchange and allows for parallelization of computing resources. To aggregate the locally trained parameters, existing work mostly uses centralized servers. A blockchain maintained by the mobile multi-robot system can potentially serve as a decentralized and secure data structure that is able to execute federated learning algorithms.

Decentralized supervisor

A smart contract can run algorithms that act as a decentralized supervisor of the mobile multi-robot system, enhancing its collective performance and decision-making abilities. Such a decentralized supervisor gathers individual robot inputs and generates system-level action policies that the individual robots can implement considering their capabilities29 (Fig. 2e). This form of hierarchical control could allocate group-level decisions to the smart contract, while simultaneously allowing for fast actions to be made by the individual robots, in a way that preserves local robustness and responsiveness.

Decentralized supervisors could also have an important role in situations where groups of robots are required to make safety-critical group decisions, particularly in emergency scenarios where it is imperative to respond in an effective manner. In such scenarios, a centralized controller becomes a potential single point of failure and risks being overloaded by the increased communication demands that occur during an emergency. Conversely, letting robots exchange votes locally can be time-consuming and might not ultimately lead to a consensus on a system-level action plan73, thus resulting in a weak or inadequate response to the emergency. A decentralized supervisor could be used to yield a swift and coordinated response from all of the robots.

Outlook

In the past few years, we have seen conceptual papers presenting blockchain-based mobile multi-robot systems16,36,74 and first proofs of concept with simulated and real robots13,17,18,19,27,28,30. However, the integration of blockchains into multi-robot systems requires addressing several technological challenges. Some challenges, such as the management of transparency, confidentiality and privacy, are common to both the domain of mobile multi-robot systems and stationary computer networks, whereas others require robotics-specific solutions. For example, to address scalability one should explicitly consider computing, storage and communication limitations of hardware-constrained robots, as well as frequent network partitioning caused by the mobility of the robots. The techniques to address scalability which have found success in the domain of traditional blockchain networks, such as sidechain architectures25 (similar to Architecture 3) and permissioned consensus protocols39, require further investigation within the domain of robotics before scalable and secure deployment is possible, particularly when the mobile multi-robot system is composed of a very large number of robots.

Another critical challenge to deploy blockchain-based multi-robot systems is the design of oracles that inject trustworthy real-world information into smart contracts. We believe that further research in decentralized oracles, in which the participants — robots or humans — act as oracle contributors, can lead to solutions that avoid centralization and a potential single point of failure. Game theory and mechanism design75 could be applied to implement economic mechanisms that reward useful information. In this way, oracle contributors would be motivated to adhere to the specified protocol and make useful contributions to the decentralized oracle to maximize their reward.

Once challenges inherent to blockchain technology are solved, the implementation of smart contracts can enable several of the opportunities presented in this Perspective (Fig. 2). Blockchain technology could enable open mobile multi-robot systems having different stakeholders. Although such open multi-robot systems could be highly flexible, they might prove challenging to coordinate. DAO-based secure self-governance is a promising solution, but requires further research to become a reality. Deploying autonomous robots that are compliant with regulations and accountable for their actions could be key in favouring the rise of mobile multi-robot systems and their acceptance by the public because they can be trusted. Additionally, if some of the robots are destroyed or lost, it would be possible to recover a tamper-proof record of the events of a mission (similarly to black boxes used in the aviation industry)76,77,78 and allow investigations to assign liability.

Once we have ensured the compliant behaviour of mobile multi-robot systems, we can start deploying them in real-world applications and let them interact with our economy or even build their own economies. Building an economy among robots that aim at maximizing their reward could lead to efficient self-organization and task allocation where robots perform the tasks for which their skills bring the best contribution. For achieving such self-organized behaviour, it will be important to define the appropriate economic incentives in the smart contracts regulating the robot economy59.

Data consistency in mobile multi-robot systems is of paramount importance in many collective activities such as, for example, monitoring an environment with robots submitting independent evaluations79 or selection of the shortest available path during collective motion in a cluttered environment. Further research will need to investigate which activities would benefit from activity-specific data synchronization and how the capabilities of the robots in terms of storage and communication bandwidth, as well as communication delays caused by partitions in the mobile multi-robot system communication network, affect data synchronization.

Finally, how to supervise the activities of a mobile multi-robot system without relying on centralized control is a general unsolved problem. This problem has been addressed by trying to introduce elements of centralized control in an otherwise self-organized system so that the typical desired properties of self-organization (such as scalability, robustness and flexibility) are preserved4,80. The use of blockchain technology could allow an alternative implementation of such centralized components: smart contracts can play the role of central controllers while benefitting from the fully distributed nature of the blockchain. To exploit the opportunity to implement decentralized supervisors, several scientific questions need to be addressed, including how to integrate the commands from decentralized supervisors with a robot’s local control software, understanding which are the applications where such an approach is the most desirable and how to preserve system scalability when the number of robots and tasks is large.