Difference between revisions of "PhDSupervision:VolkerStrobel"

From IridiaWiki
Jump to navigationJump to search
Line 211: Line 211:
 
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code
  
* 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)
  
* 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); 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
 +
* 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

Revision as of 09:07, 14 August 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

Next Meeting

  • 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
Retrieved from "https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&oldid=7971"