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 |
+ | ** 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 |
+ | ** 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 |
+ | ** 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