PhDSupervision:VolkerStrobel

From IridiaWiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


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 executed directly 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