Difference between revisions of "Application Scenario"

From IridiaWiki
Jump to navigationJump to search
(Created page with "* General properties for a application scenario ** Robots work remotely, without real-time supervision (e.g., deep sea, planetary exploration, or underground) ** Robots should...")
 
Line 1: Line 1:
 
* General properties for a application scenario
 
* General properties for a application scenario
** Robots work remotely, without real-time supervision (e.g., deep sea, planetary exploration, or underground)
+
** 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 (that is no single point of failure, no one can just press a button and stop them)
 
** Robots should be fully autonomous (that is no single point of failure, no one can just press a button and stop them)
** The swarm can add new members at any time (there is no need of authentification, any robot can join)
+
** The swarm should be ablte to add new members at any time (there is no need of authentification, any robot can join)
** The swarm members are untrusted, however, but the blockchain can be trusted
+
** The swarm members are untrusted
 
** Physical Proof of Work
 
** Physical Proof of Work
 
** Robots possibly belong to different organizations (e.g. collaboration between different countries)
 
** Robots possibly belong to different organizations (e.g. collaboration between different countries)
  +
  +
* Challenges
  +
** 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?
 
* 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 show a proof-of-concept
+
** 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?
 
* 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
 
   
   

Revision as of 23:05, 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 (that is no single point of failure, no one can just press a button and stop them)
    • The swarm should be ablte to add new members at any time (there is no need of authentification, any robot can join)
    • The swarm members are untrusted
    • Physical Proof of Work
    • Robots possibly belong to different organizations (e.g. collaboration between different countries)
  • Challenges
    • 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