Difference between revisions of "Application Scenario"
From IridiaWiki
Jump to navigationJump to search (→FAQ) |
|||
Line 37: | Line 37: | ||
** Since the robots work at remote areas, they may be without Internet connection for a long time. |
** 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. |
** 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? |
* 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. |
** 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? |
* Q: Ethereum and blockchain technology is already out there. What are your contributions? |
||
Line 45: | Line 47: | ||
** Bring blockchain technology to smaller devices; study possibilities for light clients without proof of work |
** Bring blockchain technology to smaller devices; study possibilities for light clients without proof of work |
||
** Provide proof-of-concept for robot swarms |
** Provide proof-of-concept for robot swarms |
||
+ | |||
* Q: How will you prevent physical attacks on the swarm (destroy robots, catch & release robots)? |
* Q: How will you prevent physical attacks on the swarm (destroy robots, catch & release robots)? |
Revision as of 00:44, 21 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 (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., 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 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 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
- 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 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 provide a proof-of-concept
- Allows to study "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 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
- 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 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 behaviour more profitable than malicious behavior. Since the blockchain is tamper-proof, one can easily transfer "real money" to it (e.g., from another blockchain).