Difference between revisions of "Application Scenario"

From IridiaWiki
Jump to navigationJump to search
Line 3: Line 3:
 
* Secure coordination: Swarm behaves exactly as specified, without human intervention, without possibility of downtime, without the possibility of censorship
 
* 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
 
* 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 during propagation and once the information is recorded in the blockchain
+
* Reaches consensus: Information (e.g., votes from 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
 
* 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
   

Revision as of 14:30, 21 November 2016

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., votes from 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
  • 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., 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
  • 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: 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.


  • 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 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). B using certification methods, one could check if the robot has been "reprogrammed" 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?