Difference between revisions of "PhDSupervision:VolkerStrobel"

From IridiaWiki
Jump to navigationJump to search
 
(58 intermediate revisions by the same user not shown)
Line 12: Line 12:
 
'''Belgian mobile phone:''' +32 483 42 21 04
  
'''Belgian mobile phone:''' +32 483 42 21 04
   
−
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles
 +
'''Belgian home adress:''' Arthur Goemaerelei 62, 2018 Antwerpen
   
 
===ULB-related===
  
===ULB-related===
Line 26: Line 26:
   
   
  +
== Open Questions / Future Research Directions ==
−
== TODO ==
  
   
  +
This section contains an unordered list of ideas, remarks, future research questions etc.
−
* 30/1/2017
  
−
** Implement majority voting and voter model in smart contract
 
−
** Compare classical approach and secure approach (run experiments)
  
−
*** Answer question 1: "What do we get more?"
  
−
*** Answer question 2: "What can we do in terms of attacks and robustness?"
  
−
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy
  
   
  +
* Recurring question: sparse connectivity; separate the swarm in the beginning; different regions with different distributions
⚫
==== Lab Responsibilities ====
  
  +
  +
* Test the safety criteria of the AAMAS paper
  +
  +
* See how the mining difficulty influences the experiment
  +
  +
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)
  +
  +
* See how the choice of the stable block (z = 6 currently) influences the experiments
  +
  +
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)
  +
  +
* Transfer system to real robots
  +
  +
* Collective estimation (estimating the relative frequency of features in an environment)
  +
  +
  +
* Overview of alternative consensus algorithms (who uses them, why, what are their features)
  +
  +
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?
  +
  +
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?
  +
  +
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)
  +
  +
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).
  +
  +
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.
  +
  +
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.
  +
  +
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.
  +
  +
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.
  +
  +
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.
  +
  +
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).
  +
  +
== Change in the final version of the AAMAS 2018 paper ==
  +
  +
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.
  +
  +
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete
  +
  +
* The DC-strategy is not properly introduced.
  +
  +
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?
  +
  ⚫
== Lab Responsibilities ==
   
 
* IRIDIA server maintenance
  
* IRIDIA server maintenance
Line 168: Line 212:
 
** Draft: 11th April (incl. results of current experiments)
  
** Draft: 11th April (incl. results of current experiments)
   
−
=== Next Meeting ===
 +
=== Meeting 26/4/2017 ===
 
* Design and plan experiments
  
* Design and plan experiments
 
** Why? -> Reasons, goal, hypothesis, what do I expect
  
** Why? -> Reasons, goal, hypothesis, what do I expect
Line 188: Line 232:
 
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel
  
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel
 
** I have 200 cores on the cluster now
  
** I have 200 cores on the cluster now
−
** They are very slow; the main speed bottleneck is the large number of voting transactions for the voter model and the majority rule; I have to check if I can use ARGoS parallelization
 +
** They are very slow; the main speed bottleneck is the large number of voting transactions for the voter model and the majority rule; I cannot use ARGoS parallelization (since it's not a robot to thread match); I'll try today and see what happens if I execute the blockchain voting transactions in the background
 
** Sometimes one of the cluster nodes crashes (hardware failure)
  
** Sometimes one of the cluster nodes crashes (hardware failure)
 
** Also compiled and executed the classical code (for comparison)
  
** Also compiled and executed the classical code (for comparison)
  +
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation
−
** TODO: Evaluation
  
  +
  +
=== Meeting 16/5/2017 ===
  +
* geth will not run on the E-Puck processor; it has a simple dsPIC processor
  +
* Continued with RAR (methods, results, discussion)
  +
* Created slides and prepared presentation for RAR
  +
* Started with threat model; "stubborn" Byzantine robots: robots which never change their opinion (i.e., they do not follow the decision-making strategy); consensus is reached if the non-Byzantine robots agree on an opinion; either white & black initial opinion, only white or only black
  +
  +
=== Meeting 9/6/2017 ===
  +
* Replicated experiments of classical approach
  +
** found error in the implementation of majority rule: ties always result in opinion 'white'
  +
** different results for voter model and direct comparison (no intersection)
  +
* Implemented Byzantine robots (they don't change their opinion)
  +
** Results with Byzantine robots using the classical approach
  +
** Implemented detection strategy for Byzantine robots using the blockchain approach (if a robot does not change its opinion, its vote is not stored in the blockchain)
  +
** No results yet with the blockchain approach; I think the implementation is ok (I'm currently checking the log files) but it crashed due to zombie processes, failing cluster nodes, and failing geth processes; additionally, it's still very slow in general
  +
  +
=== Meeting 14/8/2017 ===
  +
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code
  +
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)
  +
* Current alternative for identifying Byzantine robots: just ignore the vote if it does not match the previously determined opinion (no blacklist anymore); there is a bug in the code since the exit prob. is currently 0; maybe something else would be better, for example, robot gets a hashcode when applying the decision-making strategy and has to send this code again when voting
  +
  +
=== Meeting 18/9/2017 ===
  +
* Ethereum protocol (geth) can be directly executed on the E-pucks (at least using an older version of geth; I'll check if I need newer versions)
  +
* Invented/implemented a new strategy for identifying Byzantine robots
  +
* Work from home/holiday?: 25. - 27. September
  +
  +
=== Next Meeting ===
  +
* Added section about open questions
  +
* Wrote tutorial for Eduardo (TODO)
  +
* Completed Proof-of-X paper (TODO)

Latest revision as of 15:20, 26 July 2021


General Information

Personal

Name: Volker Strobel

Birthdate: 10 November 1987

Belgian mobile phone: +32 483 42 21 04

Belgian home adress: Arthur Goemaerelei 62, 2018 Antwerpen

ULB-related

PhD started: 7 September 2016

Matricule ULB: 000443899

Office phone: +32-2-650 27 12

Projects

Open Questions / Future Research Directions

This section contains an unordered list of ideas, remarks, future research questions etc.

  • Recurring question: sparse connectivity; separate the swarm in the beginning; different regions with different distributions
  • Test the safety criteria of the AAMAS paper
  • See how the mining difficulty influences the experiment
  • Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)
  • See how the choice of the stable block (z = 6 currently) influences the experiments
  • Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)
  • Transfer system to real robots
  • Collective estimation (estimating the relative frequency of features in an environment)


  • Overview of alternative consensus algorithms (who uses them, why, what are their features)
  • Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?
  • Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?
  • Most important next step: Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)
  • Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).
  • A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.
  • Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.
  • Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.
  • Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.
  • Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.
  • Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).

Change in the final version of the AAMAS 2018 paper

  • Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.
  • Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete
  • The DC-strategy is not properly introduced.
  • Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?

Lab Responsibilities

  • IRIDIA server maintenance

Tutorials

Literature

See separate page

FRIA

Meetings

Meeting 27/9/2016

  • Continue literature research (read papers mentioned in FRIA proposal)
  • Find out which labs are doing blockchain / cryptocurrency / cryptography research (see Google Docs)

Meeting 4/10/2016

Meeting 18/10/2016

Intermediate Meeting

  • French language course Mon 31 October - Fri 4 November time: 9am - 1pm

Meeting 15/11/2016

  • Continued literature research
  • Started first web application for smart contracts (http://164.15.10.140/) with very basic functionality:
    • Robots can be added to the swarm
    • Miner can issue a premium in Ether as incentive for removing oil
    • Oil can be removed by pressing a button -> sender gets rewarded
  • Experimented a bit with ARGoS
  • Discussed points during the meeting:
    • I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)
    • Look into PoW/PoS/PoX algorithms and see which one is best for robot swarms (also look into "Physical Proof of Work"); since robots are computationally rather limited, we need a clever consensus algorithm, otherwise, an attacker could easily perform a 51% attack; also find out which cryptocurrencies use which algorithm; see if it is possible to switch to PoS in Ethereum
    • Investigate possibilities for light clients (e.g., each city/organization could have a node that maintains the blockchain and the corresponding robots just run light clients)
    • I can use the footbot simulation for now but will probably use the e-puck in the real experiments

Meeting 22/11/2016

  • Application Scenario
  • Proof-of-X
  • Created simple interface between ARGoS and Ethereum node
  • TODO: Find out, which application scenario is suited for blockchain technology (for example by reading Swarm robotics: a review); see if Amanda's paper is relevant

Intermediate Meeting 25/11/2016

Meeting 29/11/2016

  • Finished Week 1 of Coursera course
  • Started ARGoS simulation for the collective decisions scenario (centralized version):
    • 10 robots, each robot has an account/address with some ETH
    • Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green
    • If a robot detects a wall or another robot it sends its opinion via the smart contract
    • After a random amount of time an epoch is finished, the majority opinion is determined, and the counters for red and green are set back to 0
    • TODO:
      • Make voting only possible if 1 ETH is send with the transaction
      • Distribute ETH after an epoch is finished
      • Base opinions on sensor inputs
      • Implement strategies for changing opinions (e.g., majority opinion, voter model)


Meeting 7/12/2016

  • Implemented decentralized ARGoS/Ethereum framework
    • Each robot is an Ethereum node
    • Some are miners (currently, only one is a miner)
    • Only robots that are physically close to each other are connected to each other via their Ethereum nodes
  • TODO:
    • Transfer simple scenario to collective decision scenario
    • Transfer framework to the cluster (and see if it is possible at all, since the processes have to talk to each other; maybe reserve some fixed cluster nodes)
  • Looked at Davide's code and Master's thesis
  • Answer Pedro (Innoviris funding)

Meeting 13/12/2016

  • Prototype of collective decision scenario with Epucks in ARGoS
  • Next steps:
    • Transfer to cluster (first steps are done)
    • Improve voting strategies (e.g., payed voting, direct modulation, ...)

Meeting 19/12/2016

  • Transferred framework to cluster
  • Conducted some experiments
  • Robots are always mining now
  • MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white

Meeting 12/1/2017

Meeting 24/1/2017

Meeting 31/1/2017

  • Make scenarios more similar (non-secure approach vs. blockchain approach) - comparison

Intermediate Meeting

Meeting 4/4/2017

  • Collective decisions
    • Voter model (Strat. 1), Majority voting (Strat. 2), Direct modulation (Strat. 3) are implemented; they use ether now to (theoretically) restrict the number of transactions
    • Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)
      • Will compare probability of correct outcome and consensus time between the strategies
    • Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"
      • Might be running into a problem: they use N = 100 robots. Since each robot can be a miner, I think I'd need a cluster with 100 cores.
  • Rapport d'avancement de recherche
    • ShareLaTeX
    • Draft: 11th April (incl. results of current experiments)

Meeting 26/4/2017

  • Design and plan experiments
    • Why? -> Reasons, goal, hypothesis, what do I expect
    • Plan; how much time will it take?
    • What data to collect? Which purpose does it serve?
    • Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?
    • Clearly describe properties of the experiment, e.g., how many malicious entities
    • See PDF on ShareLaTex: [4]
  • Implemented improvements
    • Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)
      • Problems since mining stopped working without error messages; the solution was to create different clones of geth with different (hardcoded) DAG paths; future versions of geth will include a DAG path setting
    • Modified the code to run multiple experiments in parallel (also took a lot of time, since all processes can access the same files; therefore it was important to ensure that not collisions take place also had to make sure to kill the right prcoesses at the right time etc.)
    • Made the code run faster and safer (implemented security checks, e.g., restart experiment on fatal blockchain errors, wait until all robots have the same blockchain in the beginning, etc. -> no crashes during the experiments so far)
    • Made changes for using newer geth version (1.6.0), the most recent version currently leads to a memory error since they changed the mining from C++ to go
    • Many other small bug fixes
  • Experiments are running
    • Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel
    • I have 200 cores on the cluster now
    • They are very slow; the main speed bottleneck is the large number of voting transactions for the voter model and the majority rule; I cannot use ARGoS parallelization (since it's not a robot to thread match); I'll try today and see what happens if I execute the blockchain voting transactions in the background
    • Sometimes one of the cluster nodes crashes (hardware failure)
    • Also compiled and executed the classical code (for comparison)
    • TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation

Meeting 16/5/2017

  • geth will not run on the E-Puck processor; it has a simple dsPIC processor
  • Continued with RAR (methods, results, discussion)
  • Created slides and prepared presentation for RAR
  • Started with threat model; "stubborn" Byzantine robots: robots which never change their opinion (i.e., they do not follow the decision-making strategy); consensus is reached if the non-Byzantine robots agree on an opinion; either white & black initial opinion, only white or only black

Meeting 9/6/2017

  • Replicated experiments of classical approach
    • found error in the implementation of majority rule: ties always result in opinion 'white'
    • different results for voter model and direct comparison (no intersection)
  • Implemented Byzantine robots (they don't change their opinion)
    • Results with Byzantine robots using the classical approach
    • Implemented detection strategy for Byzantine robots using the blockchain approach (if a robot does not change its opinion, its vote is not stored in the blockchain)
    • No results yet with the blockchain approach; I think the implementation is ok (I'm currently checking the log files) but it crashed due to zombie processes, failing cluster nodes, and failing geth processes; additionally, it's still very slow in general

Meeting 14/8/2017

  • Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code
  • RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)
  • Current alternative for identifying Byzantine robots: just ignore the vote if it does not match the previously determined opinion (no blacklist anymore); there is a bug in the code since the exit prob. is currently 0; maybe something else would be better, for example, robot gets a hashcode when applying the decision-making strategy and has to send this code again when voting

Meeting 18/9/2017

  • Ethereum protocol (geth) can be directly executed on the E-pucks (at least using an older version of geth; I'll check if I need newer versions)
  • Invented/implemented a new strategy for identifying Byzantine robots
  • Work from home/holiday?: 25. - 27. September

Next Meeting

  • Added section about open questions
  • Wrote tutorial for Eduardo (TODO)
  • Completed Proof-of-X paper (TODO)
Retrieved from "https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&oldid=8187"