Blockchain Technology Secures Robot Swarms: A Comparison of Consensus Protocols and Their Resilience to Byzantine Robots

Abstract

Consensus achievement is a crucial capability for robot swarms, for example, for path selection, spatial aggregation, or collective sensing. However, the presence of malfunctioning and malicious robots (Byzantine robots) can make it impossible to achieve consensus using classical consensus protocols. In this work, we show how a swarm of robots can achieve consensus even in the presence of Byzantine robots by exploiting blockchain technology. Bitcoin and later blockchain frameworks, such as Ethereum, have revolutionized financial transactions. These frameworks are based on decentralized databases (blockchains) that can achieve secure consensus in peer-to-peer networks. We illustrate our approach in a collective sensing scenario where robots in a swarm are controlled via blockchain-based smart contracts (decentralized protocols executed via blockchain technology) that serve as "meta-controllers" and we compare it to state-of-the-art consensus protocols using a robot swarm simulator. Additionally, we show that our blockchain-based approach can prevent attacks where robots forge a large number of identities (Sybil attacks). The developed robot-blockchain interface is released as open-source software in order to facilitate future research in blockchain-controlled robot swarms. Besides increasing security, we expect the presented approach to be important for data analysis, digital forensics, and robot-to-robot financial transactions in robot swarms.

Keywords: Byzantine fault-tolerance; blockchain technology; resilient robotics; swarm robotics; verifiable robotics.

Figure 1

The robots' task is to determine the relative frequency of white tiles in an environment in which the floor is covered with black and white tiles. For each robot, an instance of the Ethereum blockchain software is executed in a separate Docker container and the robots maintain a custom Ethereum blockchain network. Via a blockchain-based smart contract, the sensor readings of the robots are stored and aggregated. When robots are within communication range, they exchange their blockchain information. In contrast to classical approaches, the blockchain is able to mitigate the negative impact of malfunctioning or malicious robots and allows the creation of a tamper-proof system, in which the messages of the robots are securely stored.

Figure 2

A blockchain is composed of linked blocks containing data consisting of transactions. Each block is divided into two parts: a body and a header. In the body, the transactions of the participants are stored. The header contains metadata and links each block to the hash of a previous block to create a chain of blocks. A copy of the blockchain is stored by each participant in the peer-to-peer network; the peers exchange and update their blockchain information based on a consensus protocol.

Figure 3

In the illustration, Robot 1 (Fork A) and Robot 2 (Fork B) have conflicting blockchain versions (forks). This situation can occur if there is a delay in communication, for example, because the two robots were in different “clusters” that could not communicate with each other and now they can communicate with each other again. Fork B is the longer blockchain (the one that contains more PoW) and is accepted as the true blockchain, while the shorter blockchain is discarded. That is, after exchanging their blockchain information, the two robots agree on Fork B. Transactions in the shorter blockchain become unconfirmed transactions again (stored in a separate memory pool) and can be included in a later block (e.g., Block 3). The memory pool contains transactions that can be included into blocks.

Figure 4

For each robot, the ARGoS-Blockchain interface establishes a connection to the Ethereum blockchain via a Docker container and shell scripts that provide templates for executing Ethereum (geth) functions.

Figure 5

This scheme shows the initialization phase that is executed at the start of each experimental run.

Figure 6

The robots explore the environment using a random walk routine and sample their ground sensors. Using the classical approaches lcp and w-msr (top), they update their frequency estimate every 45 s (i.e., every 45 time-steps) via Equation (1). Using the blockchain approach (bottom), every 45 s, the robots create a blockchain transaction that includes their sensor reading. In contrast to the classical approaches, with the blockchain approach, the robots can check whether a consensus has been reached by querying the state (true or false) of the smart contract event consensusReached. If true, they enter the exit state and stop creating blockchain transactions. Then, they still perform the random walk and connect to other robots in their proximity to exchange blockchain information.

Figure 7

The smart contract keeps track of the frequency estimate ${\widehat{\rho }}_t$ and provides the function escrow to send a sensor reading ${\widehat{\rho }}_{i,m}^{\prime }$. The event consensusReached is set to true when the frequency estimate does not change more than τ from one escrow round to the next one.

Figure 8

In this example, robot 3 creates the transaction tx 0x1 in order to send its sensor reading to the smart contract. The transaction is then disseminated to its neighboring robots 1, 5, and 9. Since the transaction is not included in a block yet, it is an unconfirmed transaction. Robot 1 is able to mine a new block that includes this transaction and two other transactions tx 0x2 and tx 0x3. Robot 1 then disseminates this mined block among its neighboring robots 3 and 8.

Figure 9

Experiment 1: Random distribution (no Byzantines). lcp (top), w-msr (middle), and the blockchain approach (bottom) perform well if the tiles are randomly distributed and if there are no Byzantine robots. This result serves as a baseline for the following simulations. No correlation between the actual frequency of white tiles and the absolute error (ae_*) is visible. The graphs on the left-hand side show the mean with the error bars indicating the standard deviation. The dashed line in the plots on the right-hand side show the ideal outcome, i.e., when the true % of white tiles equals the estimated % of white tiles.

Figure 10

Experiment 2: Random distribution. When the number of Byzantine robots increases, lcp's performance (top) quickly deteriorates and the frequency of extreme outliers becomes high (the percentages at the top of each graph correspond to the frequency with which Byzantine robots were selected when calculating ae_*). Therefore, with the classical approaches, one is always exposed to the risk of getting a completely wrong result, even if there is just one Byzantine robot in the swarm. w-msr (middle) is able to manage a few Byzantine robots but its ae_* quickly increases when there are more than three of them. The blockchain approach (bottom) is largely unaffected by the increasing number of Byzantine robots, and does not contain extreme outliers. The graphs on the left-hand side show the mean with the error bars indicating the standard deviation. The blue line is obtained by locally estimated scatterplot smoothing (loess), the gray band around the blue line shows the 95% confidence interval for predictions from the loess regression.

Figure 11

Experiment 3: Consensus. (Top) In the absence of Byzantine robots all approaches are able to reach a consensus in a reasonably short amount of time. However, there is a trade-off between consensus time in the absence of Byzantine robots and the level of security an approach provides. (Bottom) When testing the swarm's ability to reach a consensus, the classical approaches can only reach a consensus on the values of the Byzantine robots. In contrast, the blockchain approach continues to work. It shows a slight increase in the consensus time when the number of Byzantine robots is increased; this happens due to the increased variance that is introduced by the increasing number of Byzantine robots. The graphs on the left-hand side show the mean with the error bars indicating the standard deviation. The blue line is obtained by locally estimated scatterplot smoothing (loess), the gray band around the blue line shows the 95% confidence interval for predictions from the loess regression.

Figure 12

When using the fixed distribution of the tiles, the left part of the environment is covered with black tiles while the rest is covered with white tiles. This fixed distribution is expected to make it more difficult for the smart contract to detect Byzantine robots since normal robots might send the same sensor values as Byzantine robots.

Figure 13

Experiment 4: Binary distribution. Similar to the random distribution, lcp (top) shows a steep increase in ae_*, w-msr (middle) can handle a few Byzantine robots, and the blockchain approach (bottom) is also resilient to a higher number of Byzantine robots. The graphs on the left-hand side show the mean with the error bars indicating the standard deviation. The blue line is obtained by locally estimated scatterplot smoothing (loess), the gray band around the blue line shows the 95% confidence interval for predictions from the loess regression.

Figure 14

Experiment 5: Sybil attack. In the comparison of the approaches, it is clearly visible that lcp (top) and w-msr (middle) fail in the presence of even one Byzantine robot performing a Sybil attack. In contrast, the blockchain approach (bottom) is able to prevent these attacks by limiting the number of transactions that can be included in the blockchain. The graphs on the left-hand side show the mean with the error bars indicating the standard deviation. The blue line is obtained by locally estimated scatterplot smoothing (loess), the gray band around the blue line shows the 95% confidence interval for predictions from the loess regression.