Application Scenario

Goal

• Secure coordination: Swarm behaves exactly as specified, without human intervention, without possibility of downtime, without the possibility of censorship
• 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., voting) gets propagated in a peer-to-peer manner; peers have a hard time to tamper with information
• Decentralized way: The swarm does not need a trusted third party; no member needs to trust anyone in the swarm

Impacts

• Increases scalability: New members can be included at any time; their controllers can be obtained from the blockchain
• Increases autonomy: Robots behave exactly as specified without supervision; they are a self-organized system that makes decisions without human intervention
• Increases security: Attacker have little chance/incentive to maliciously influence the swarm 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
• The swarm behavior should behave "exactly as specified" -> secure coordination (important for all sensitive tasks)
• 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., robot project collaboration between different countries, 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 could verify and distribute transactions
• 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 imporant 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
• These settings can be used in: exploration, mapping, oil spill removal, humanitarian demining

FAQ

• Q: Robots are computationally limited devices. Therefore, they can only perform proof-of-work (PoW) 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.

• Q: How do light clients work with Ethereum/with your framework?
  • The development of suitable light clients could be a part of the research. Light clients for PoS still have to be developed.

• Q: Why do you use physical robot and not just simulation?
  • 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 to study "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 classicial 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 a 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 a 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 at 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.

• 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
  • Bring blockchain technology to smaller devices; study possibilities for light clients without proof of work
  • Provide proof-of-concept for robot swarms

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

• Q: Does your thesis also contribute if one does not want to start a new blockchain?
  • Yes. I will develop protocols for light (thin) clients that work on limited devices.
  • I will develop methods for sparse communication.
  • ...

• Q: Is this really swarm robotics or rather a multi-robot system?