Difference between revisions of "PhDSupervision:VolkerStrobel"

From IridiaWiki
Jump to navigationJump to search
(161 intermediate revisions by 3 users 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:''' Avenue Wielemans Ceuppens 138, 1190 Forest / Bruxelles
+
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles
   
 
===ULB-related===
 
===ULB-related===
Line 26: Line 26:
   
   
== Work Schedule ==
+
== TODO ==
  +
  +
* 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
  +
  +
==== Lab Responsibilities ====
  +
  +
* IRIDIA server maintenance
  +
  +
== Tutorials ==
  +
  +
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''
  +
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]
  +
  +
== Literature ==
  +
  +
=== [[Volker_Literature|See separate page]] ===
  +
  +
== FRIA ==
  +
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]
  +
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]
   
 
== Meetings ==
 
== Meetings ==
Line 32: Line 56:
 
=== Meeting 27/9/2016 ===
 
=== Meeting 27/9/2016 ===
   
- Continue literature research
+
* Continue literature research (read papers mentioned in FRIA proposal)
  +
- Find out who is doing blockchain research
 
  +
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])
  +
  +
=== Meeting 4/10/2016 ===
  +
  +
* Propose literature ([[Volker_Literature|see separate page]])
  +
* Séance d'information sur les financements permettant des mobilités dans le cadre d’un doctorat [https://www.dropbox.com/s/cgcztkr4e3r1vc4/FNRS%20infos%20courts%20s%C3%A9jours%20doct%202016.pdf?dl=0][https://www.dropbox.com/s/qpen05yw1jhw890/ULB%20CCCI%20cr%C3%A9dits%20doctorat%20et%20UC%20Berkeley%202016%202017.pdf?dl=0][https://www.dropbox.com/s/uy4rgl5a521f21y/WBI%20financements%20doct%20s%C3%A9jours%20%C3%A9trangers%202016.pdf?dl=0]
  +
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])
  +
  +
=== Meeting 18/10/2016 ===
  +
  +
* French language course Mon 31 October - Fri 4 November?
  +
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/
  +
* iMAL Hacklab Saturday 5 November (30 EUR)
  +
  +
=== 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/ 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 | Application Scenario ]]
  +
* [[ Proof-of-X | 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 ===
  +
* Discussed [[Collective decisions | Collective decisions]]
  +
  +
=== 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 ===
  +
* FNRS Aspirant
  +
** Pre-form entry
  +
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]
  +
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]
  +
  +
=== Meeting 24/1/2017 ===
  +
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]
  +
  +
=== Meeting 31/1/2017 ===
  +
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]
  +
  +
=== Intermediate Meeting ===
  +
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit
  +
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing
  +
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing
  +
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing
  +
* TODO:
  +
** Upload letter from Jason
  +
** Update workplan; include MIT visit
  +
  +
=== 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
  +
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd 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: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]
  +
  +
* 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
   
==== Lab Responsabilities ====
+
=== 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

Revision as of 13:29, 18 September 2017


General Information

Personal

Name: Volker Strobel

Birthdate: 10 November 1987

Belgian mobile phone: +32 483 42 21 04

Belgian home adress: Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles

ULB-related

PhD started: 7 September 2016

Matricule ULB: 000443899

Office phone: +32-2-650 27 12

Projects

TODO

  • 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

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