Difference between revisions of "PhDSupervision:VolkerStrobel"
From IridiaWiki
Jump to navigationJump to search(138 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:''' |
+ | '''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles |
===ULB-related=== |
===ULB-related=== |
||
Line 26: | Line 26: | ||
− | == |
+ | == 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 ==== |
==== Lab Responsibilities ==== |
||
+ | * IRIDIA server maintenance |
||
− | * Take care of websites / YouTube channel |
||
− | * Help with writing blockchain proposal? |
||
− | * IRIDIA server maintenance? |
||
== Tutorials == |
== Tutorials == |
||
− | * [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] |
+ | * [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] |
+ | * [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies] |
== Literature == |
== Literature == |
||
− | === [[See separate page]] === |
+ | === [[Volker_Literature|See separate page]] === |
== FRIA == |
== FRIA == |
||
− | * [https:// |
+ | * [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation] |
+ | * Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]] |
||
== Meetings == |
== Meetings == |
||
Line 56: | Line 62: | ||
=== Meeting 4/10/2016 === |
=== Meeting 4/10/2016 === |
||
− | * Propose literature |
+ | * 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] |
* 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, and Gaetan |
+ | * 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 |
||
+ | |||
+ | === 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 14: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
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
- Udemy: Ethereum Developer: Build A Decentralised Blockchain App Completed 75 %
- Coursera: Bitcoin and Cryptocurrency Technologies
Literature
See separate page
FRIA
- Presentation
- Ideas for next proposal: Ideas
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
- Propose literature (see separate page)
- Séance d'information sur les financements permettant des mobilités dans le cadre d’un doctorat [1][2][3]
- 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/) 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
- Discussed 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: Google Docs
- Link to Technical report: PDF (Dropbox)
Meeting 24/1/2017
- Continued with Technical report: 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
- 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
- Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)
- 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