Difference between revisions of "Application Scenario"

From IridiaWiki
Jump to navigationJump to search
Line 2: Line 2:
 
** 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
 
** 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
 
** The swarm should come to consensus; no robot should be able to do something without getting automatically punished or rewarded
** Robots should be fully autonomous (that is 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)
+
** 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)
 
** 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)
 
** 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)

Revision as of 23:11, 20 November 2016

  • 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 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
    • Physical Proof of Work
  • Q: Robots are computationally limited devices. Therefore, they can only perform proof-of-work with limited difficulty. What happens if a much more powerful attacker performs a 51% attack?


  • 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