Difference between revisions of "PhDSupervision:VolkerStrobel"

From IridiaWiki
Jump to navigationJump to search
Line 175: Line 175:
 
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?
  
** 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
  
** Clearly describe properties of the experiment, e.g., how many malicious entities
  +
** See: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]
   
 
* Implemented improvements
  
* Implemented improvements

Revision as of 23:31, 20 April 2017


General Information

Personal

Name: Volker Strobel

Birthdate: 10 November 1987

Belgian mobile phone: +32 483 42 21 04

Belgian home adress: Avenue Wielemans Ceuppens 138, 1190 Forest / 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)

Next Meeting

  • 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: [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, etc.)
    • Modified the code to run multiple experiments in parallel (took some time, since I only have one account on the cluster but all processes can access the same files)
    • Made the code run faster and safer (implemented security checks, e.g., catch blockchain errors, wait until all robots have the same blockchain in the beginning -> 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
Retrieved from "https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&oldid=7927"