Application Scenario

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 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 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 to which organization or person a robot belongs)
• These settings can be used in: exploration, mapping, oil spill removal, humanitarian demining
• Each robot is a (light) node in the network; they could verify and distribute transactions
• 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
• Physical Proof of Work

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

• 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 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 provide a proof-of-concept

• 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