Application Scenario

Goal

• Secure coordination: Swarm behaves exactly as specified, without human intervention, without possibility of downtime, without the possibility of censorship; each robots has a certain guarantee that an action leads to certain consequences
• Byzantine fault tolerance: The swarm should be resilient to robots that do not work at all anymore, to robots that send deliberately wrong information, and to robots that send wrong information due to broken sensors
• Reaches consensus: Information (e.g., votes of the robots if a certain task should be executed or not) gets propagated in a peer-to-peer manner; peers have a hard time to tamper with information during propagation and once the information is recorded in the blockchain
• Decentralized way: The swarm does not need a trusted third party for communication and coordination; no member needs to trust anyone in the swarm; the blockchain builds trust among the untrusted agents

Impacts

• Increases scalability: New members can be included into the swarm at any time; there is no need for identification; controllers could be obtained from the blockchain or in another peer-to-peer manner (e.g., BitTorrent)
• Increases autonomy: Robots behave exactly as specified without supervision; they are a self-organized system that makes decisions without human intervention
• Increases security: Attackers have little chance/incentive to maliciously influence the swarm behavior (smart contracts provide unstoppable and tamper-proof coordination mechanisms; beneficial behavior could be rendered more profitable than malicious behavior)
• Increases transparency: All critical events are recorded in the blockchain; the blockchain is very hard to tamper with, therefore, the information in it can be trusted

General properties for a application scenario

• Robots work remotely, without real-time supervision (e.g., deep sea, planetary exploration, or underground); they can only communicate in a peer-to-peer manner; there is no central trusted source of information
• The swarm should come to consensus; no robot should be able to do something without getting automatically punished or rewarded; robots (and, therefore, their owner) should have a guarantee that a certain action leads to certain consequences
• Robots should be fully autonomous (no single point of failure, no one can just press a button and stop them, no person decides if a member is included in the swarm or not)
• The swarm should be able to add new members at any time (there is no need of password authentification, any robot can join)
• Robots possibly belong to different organizations (e.g., international robot project: no country wants to face the risk that another country just stops the project)
• The swarm members are untrusted (you don't have to know which organization or person a robot belongs to; you don't have to know if a robot sends right or wrong information)
• Each robot is a (light) node in the network; they can verify and distribute transactions (maybe they still need a connection to a full client from time to time)
• The blockchain does not need to be the only communication medium, instead, it could be used for critical information only and complemented with "normal" local communication
• After a mission was performed, it might be important to see, which robot performed what action; thanks to the immutability of the blockchain, this can be done long time after the actual actions were performed

Examples of application scenarios

The framework could be used for any robot task where security is an issue:

• Search & Block: Find moving target (e.g., terrorist) and block it (robots need to collaborate, terrorists have an incentive to send wrong information, one robot alone could not do it, robot need to come to consensus what to do next, ...)
• Oil spill removal (robots get rewarded if they detect spills or if they remove spills)
• Humanitarian demining (vote for best action for defusing the mine)
• Collective decisions in general (weighted reputation-based voting in a best-of-n problem)
• Exploration??
• Mapping?? (robots get rewarded if they send part of a map, smart contract determines if the partial map is "reasonable")

FAQ

• Q: Robots are computationally limited devices. Therefore, they can only solve proof-of-work (PoW) problems with limited difficulty. What happens if a much more powerful attacker performs a 51% attack?
  • Bitcoin's classical PoW might not be the right choice. Instead, proof-of-stake (PoS) might be a better alternative. The stake might be built by using "Physical PoW", for example by removing oil spills or mines or by making good decisions in a voting scenario.

• Q: How do light clients work in a PoS framework?
  • See https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/:

1. Calculate random number R
2. Find blockmakers and signers based on this number and get their public addresses
3. Verify the signatures in the block header based on the public addresses
4. Ask a full node for a Merkle path

• Q: How does the global knowledge of the blockchain match with the local sensing and communication capabilities in swarm robotics?
  • Importantly, the blockchain is not a centralized medium but is spread among the robots. Information gets only propagated in a peer-to-peer manner using local communication.

• Q: Why do you use physical robots and not just a simulator?
  • Simulations can never capture all aspects of the real-world
  • The goal is to pave the way for real-world robot task; physical robots provide a proof-of-concept
  • Allows studying "Physical proof of work"
  • It allows to directly study and the capability of the blockchain technology to handle failing sensors, actuators, and other unforeseen events

• Q: Why don't you just use a classical consensus algorithm?
  • Other existing consensus algorithms (apart from blockchain technology) are susceptible to Sybil attacks or only provide consensus to a small degree.

• Q: Why don't you use an authentification system to only include trusted members?
  • A classical authentification system can be easily compromised (e.g., once the password is revealed, the entire system breaks down)
  • The swarm is more flexible without an authentification system: everyone can join at any time

• Q: Why do you want to start your own blockchain instead of using the main Ethereum blockchain?
  • Since the robots work in remote areas, they may be without Internet connection for a long time.
  • Currently, there are no available light (thin) clients for Ethereum and the main blockchain is too memory-intense for small robots.
  • It allows for adapting settings to robot scenarios: block time, mining difficulty, ...

• Q: Why would new members join the swarm?
  • New members could join the swarm to replace broken members, to reduce the time for solving the problem, or to be able to solve the problem at all.

• Q: Ethereum and blockchain technology is already out there. What are your contributions?
  • Study possibilities and limitations of combining blockchain technology and robot swarms
  • Provide design principles for writing smart contracts for robots swarms
  • Bring blockchain technology to smaller devices; study possibilities for light clients without proof of work
  • Provide proof-of-concept that blockchain technology is able to manage security aspects in robot swarms

• Q: How will you prevent physical attacks on the swarm (e.g., if someone destroys robots, or catches & releases them)?
  • Using inspiration from game theory, one could render beneficial behavior more profitable than malicious behavior. Since the blockchain is tamper-proof, one can easily transfer "real money" to it (e.g., from another blockchain). By using certification methods, one could check if the robot has been "reprogrammed" during captivity.

• Q: Does your thesis also make contributions if one does not want to start a new blockchain but use the main Ethereum blockchain instead?
  • Yes, I will develop:
    • protocols for light (thin) clients that work on limited devices.
    • methods for sparse and effective communication.
    • methods for handling time delays
    • design principles for writing smart contracts for robots swarms

• Q: Let's say you don't start a new blockchain. In a laboratory setting, is there any difference between using the main Ethereum framework and classical server/database architecture?
  • The goal of the project is to pave the way for real-world applications. Real-world applications benefit from using the Ethereum framework instead of a classical server/database architecture since Ethereum is tamper-proof, able to run unstoppable software, and allows for sending financial value. A server may be hacked, shut down, or censored. However, the increased security via the blockchain is not without cost: robots need to be able to verify transactions and deal with the introduced time delays and memory requirements of the blockchain. I will investigate how these drawbacks can be addressed in the best manner.

• Q: Is this a swarm robotics system or rather a multi-robot system?
  • The system is a swarm robotics system (from Brambilla et al., 2013):
    • robots are autonomous;
    • robots are situated in the environment and can act to modify it;
    • robots’ sensing and communication capabilities are local;
    • robots do not have access to centralized control and/or to global knowledge;
    • robots cooperate to tackle a given task.
  • Additionally, according to the definition of Higgins et al., 2009:
    • Autonomous
    • Large Number of Robots
    • Simple
    • Local sensing and communication
    • Self-organizing
    • Emergent behavior?
    • Cooperate to accomplish task
    • Distributed Command / Control
    • Mobile
    • No ID necessary

• Q: How does the ever-increasing blockchain size match with the limited memory of robots?
  • Possibilities are:
    • sparse communication: use the blockchain only for critical information, therefore, it will only very slowly increase in size
    • light clients (download only a part of the blockchain, e.g., just the headers and ask full nodes )
    • pruning (download the entire blockchain from the start but once information is not needed anymore, discard it)

• Q: You say that robots build up a reputation. Why would a robot be better than another? All robots run the same controller and have the same sensors and actuators?
  • The initial controller could be the same for every robot but it could evolve other time (e.g., neural network, evolutionary algorithm, ...)
  • Sensors can fail and can have a different quality (even if they are from the same model/manufacturer). Therefore, the reputation is linked to the quality of the sensor.