https://iridia.ulb.ac.be/w/api.php?action=feedcontributions&user=VolkerStrobel&feedformat=atom
IridiaWiki - User contributions [en]
2024-03-19T05:22:02Z
User contributions
MediaWiki 1.35.4
https://iridia.ulb.ac.be/w/index.php?title=What_you_need_to_begin_to_work_in_IRIDIA&diff=8227
What you need to begin to work in IRIDIA
2022-10-03T15:36:40Z
<p>VolkerStrobel: /* PhD students and Post-Docs only */</p>
<hr />
<div>=== Visiting - Master students, PhD students, Post-Docs ===<br />
<br />
A number of resources need to be "activated" in order to begin to work in IRIDIA.<br />
<br />
* You need to provide two recent pictures of you (also in electronic format) for your student card and insurance and give them to [http://code.ulb.ac.be/iridia.people.php?id=3 Muriel Decreton]. <br>The student card will allow you to have a reduced price in the ULB cantine, as well as cinemas and other places advertising discounts for students.<br />
<br />
* [http://code.ulb.ac.be/iridia.people.php?id=3 Muriel Decreton] can provide you keys for entering your office.<br />
<br />
* You will need an entry in the [http://code.ulb.ac.be/iridia.people.php IRIDIA people page].<br>Contact the administrator of the people page (currently [http://code.ulb.ac.be/iridia.people.php?id=1285 Dhananjay Ipparthi], he will need your personal information a picture and a link to your home page).<br>If you will have a permanent position, make sure you have a page on the iridia web server first.<br />
<br />
* If you need an account on the cluster, please contact the system administrators of IRIDIA's cluster (currently [http://iridia.ulb.ac.be/~fpagnozzi/ Federico Pagnozzi] and [http://iridia.ulb.ac.be/~afranzin/ Alberto Franzin]). For all communications related to the cluster (requesting an account, reporting issues, etc) write ONLY to cluster_admins at iridia.ulb.ac.be. Any mail about cluster matters sent to the personal or institutional accounts of the cluster admins will be ignored. More info about the cluster can be found [http://majorana.ulb.ac.be/wordpress/ here].<br />
<br />
* You have to subscribe to the following [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/ IRIDIA mailing lists] <sup id="ref1">[[What_you_need_to_begin_to_work_in_IRIDIA#note1|[1]]]</sup> :<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/guests Guests] (if you are a visitor or a master student doing your thesis at IRIDIA) <br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/optimization-group Optimization Group] (if your domain of research is optimization)<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/robotics Robotics Group] (if your domain of research is Robotics)<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/seminars Seminars] (to receive information about talks and seminars being held at IRIDIA)<br />
<br />
* You can also subscribe to the following [http://iridia.ulb.ac.be/Calendars/ calendars]:<br />
** [https://www.google.com/calendar/ical/km87al7a1mb596h2l07mknom48%40group.calendar.google.com/public/basic.ics IRIDIA Seminars]<br />
** [https://www.google.com/calendar/ical/26s3f312i7lhc2jpmvhtg4kqls%40group.calendar.google.com/public/basic.ics IRIDIA Robotics]<br />
** [https://www.google.com/calendar/ical/3aqjlr91cmusi761hounf7a7ac%40group.calendar.google.com/public/basic.ics IRIDIA Optimization]<br />
** [https://www.google.com/calendar/ical/ait7l5qcsv24f9jmshvl2g0urc%40group.calendar.google.com/public/basic.ics IRIDIA Others]<br />
<br />
* You are also encouraged to apply for a membership to the [http://groups.google.com/group/iridians iridians mailing list], where you will be kept posted about dinners and other events we might organise. :-) You are more than welcome to propose events!<br />
<br />
In [http://iridia.ulb.ac.be/wiki/Moving_to_Brussels this] and [http://iridia.ulb.ac.be/wiki/Surviving_in_Brussels this] page you can find general information about living in Bruxelles (where to search for a flat, French courses, bureaucracy etc.)<br />
<br />
For further questions contact [http://iridia.ulb.ac.be/~fpagnozzi Federico Pagnozzi].<br />
<br />
=== PhD students and Post-Docs only ===<br />
<br />
* WEB server space <br>Contact the IRIDIA web server administrator (currently [http://code.ulb.ac.be/iridia.people.php?id=1473 Volker Strobel]).<br />
<br />
* Account on the BACKUP server.<br/>Contact the system administrator of the IRIDIA's backup server (currently [http://iridia.ulb.ac.be/~afranzin Alberto Franzin]).<br />
<br />
* If you are supposed to have the key of the robotic lab (arena), [http://iridia.ulb.ac.be/~mbiro Mauro Birattari] can provide you a copy of the key.<br />
<br />
* If you need an SVN account ask [http://iridia.ulb.ac.be/~dgarzon/ David Garzon].<br />
<br />
* For an account on the IRIDIA Wiki, contact the responsible (currently [http://iridia.ulb.ac.be/~afranzin Alberto Franzin]).<br />
<br />
* You can subscribe to the following two mailing lists:<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/staff Staff] (if you are a new phd student or postdoc)<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/phdstudents PhD Students](if you are a new phd student)<br />
<br />
* In [http://iridia.ulb.ac.be/wiki/Workstation_configuration this page] you can find useful information concerning the configuration of printers etc.<br />
<br />
If you work at IRIDIA for a longer period of time, probably you want also an email @ulb.ac.be. For [https://idsapp.ulb.ac.be/pam/pamsignup.php?language=uk registering] you will need an "Enrollment number" and a "PIN-code/Numéro de lecteur". You can find them on your ULB card. Once you activate the account you can [https://idsapp.ulb.ac.be/pam/index.php manage your account], [http://webserv1.ulb.ac.be/intranet/access?_mode=login1 access the intranet], and [http://webmail.ulb.ac.be/ your webmail].<br />
<br />
== Notes ==<br />
1. <sup>^</sup> <sup id="note1">[[What_you_need_to_begin_to_work_in_IRIDIA#ref1|a]]</sup> In order not to be submerged by spam, most of the lists accept posts only from email addresses that are in the subscribers list... meaning that if you subscribed to the Staff list with the address xxx@iridia.ulb.ac.be and try to send a message from your other addresses xxx@ulb.ac.be or xyz@gmail.com they will be discarded by the system.<br>If you have experienced such a problem, or want to be allowed to post from your other addresses, please contact the list owner providing the list of addresses to be added to the "white-list".</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8187
PhDSupervision:VolkerStrobel
2021-07-26T14:20:05Z
<p>VolkerStrobel: /* Meetings */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Arthur Goemaerelei 62, 2018 Antwerpen<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Recurring question: sparse connectivity; separate the swarm in the beginning; different regions with different distributions<br />
<br />
* Test the safety criteria of the AAMAS paper<br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8186
PhDSupervision:VolkerStrobel
2021-07-26T14:19:53Z
<p>VolkerStrobel: /* Meetings */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Arthur Goemaerelei 62, 2018 Antwerpen<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Recurring question: sparse connectivity; separate the swarm in the beginning; different regions with different distributions<br />
<br />
* Test the safety criteria of the AAMAS paper<br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
Just a test<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8174
Iridia Supplementary Information Instructions page
2020-09-08T21:47:48Z
<p>VolkerStrobel: /* Procedure for adding supplementary material */</p>
<hr />
<div>On this page, you find instructions on how to use the Iridia Supplementary Information page (http://iridia.ulb.ac.be/supp). You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. The example sections in the template file (Abstract, Statistical data, Videos) are not obligatory. Please feel free to use any sections that fit your need. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp20xz-0ab. The papers get an ascending number based on their year.<br />
If you need to hide confidential information for a certain time period (for example, until the paper gets published), please inform the [[Lab_responsibilities|responsible of the supplementary pages]].<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8173
Iridia Supplementary Information Instructions page
2020-09-08T21:47:36Z
<p>VolkerStrobel: /* Procedure for adding supplementary material */</p>
<hr />
<div>On this page, you find instructions on how to use the Iridia Supplementary Information page (http://iridia.ulb.ac.be/supp). You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. The example sections in the template file (Abstract, Statistical data<br />
, Videos) are not obligatory. Please feel free to use any sections that fit your need. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp20xz-0ab. The papers get an ascending number based on their year.<br />
If you need to hide confidential information for a certain time period (for example, until the paper gets published), please inform the [[Lab_responsibilities|responsible of the supplementary pages]].<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8128
PhDSupervision:VolkerStrobel
2019-05-14T09:13:04Z
<p>VolkerStrobel: /* Personal */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Arthur Goemaerelei 62, 2018 Antwerpen<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Recurring question: sparse connectivity; separate the swarm in the beginning; different regions with different distributions<br />
<br />
* Test the safety criteria of the AAMAS paper<br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8120
Iridia Supplementary Information Instructions page
2019-01-24T13:35:48Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you find instructions on how to use the Iridia Supplementary Information page (http://iridia.ulb.ac.be/supp). You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp20xz-0ab. The papers get an ascending number based on their year. <br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8119
Iridia Supplementary Information Instructions page
2019-01-24T13:33:48Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you find instructions on how to use the Iridia Supplementary Information page (http://iridia.ulb.ac.be/supp). You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp20xx-0xx (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=What_you_need_to_begin_to_work_in_IRIDIA&diff=8118
What you need to begin to work in IRIDIA
2019-01-24T13:31:38Z
<p>VolkerStrobel: /* PhD students and Post-Docs only */</p>
<hr />
<div>=== Visiting - Master students, PhD students, Post-Docs ===<br />
<br />
A number of resources need to be "activated" in order to begin to work in IRIDIA.<br />
<br />
* You need to provide two recent pictures of you (also in electronic format) for your student card and insurance and give them to [http://code.ulb.ac.be/iridia.people.php?id=3 Muriel Decreton]. <br>The student card will allow you to have a reduced price in the ULB cantine, as well as cinemas and other places advertising discounts for students.<br />
<br />
* [http://code.ulb.ac.be/iridia.people.php?id=3 Muriel Decreton] can provide you keys for entering your office.<br />
<br />
* You will need an entry in the [http://code.ulb.ac.be/iridia.people.php IRIDIA people page].<br>Contact the administrator of the people page (currently [http://code.ulb.ac.be/iridia.people.php?id=1285 Dhananjay Ipparthi], he will need your personal information a picture and a link to your home page).<br>If you will have a permanent position, make sure you have a page on the iridia web server first.<br />
<br />
* If you need an account on the cluster, please contact the system administrators of IRIDIA's cluster (currently [http://iridia.ulb.ac.be/~fpagnozzi/ Federico Pagnozzi] and [http://iridia.ulb.ac.be/~afranzin/ Alberto Franzin]). For all communications related to the cluster (requesting an account, reporting issues, etc) write ONLY to cluster_admins at iridia.ulb.ac.be. Any mail about cluster matters sent to the personal or institutional accounts of the cluster admins will be ignored. More info about the cluster can be found [http://majorana.ulb.ac.be/wordpress/ here].<br />
<br />
* You have to subscribe to the following [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/ IRIDIA mailing lists] <sup id="ref1">[[What_you_need_to_begin_to_work_in_IRIDIA#note1|[1]]]</sup> :<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/guests Guests] (if you are a visitor or a master student doing your thesis at IRIDIA) <br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/optimization-group Optimization Group] (if your domain of research is optimization)<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/robotics Robotics Group] (if your domain of research is Robotics)<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/seminars Seminars] (to receive information about talks and seminars being held at IRIDIA)<br />
<br />
* You can also subscribe to the following [http://iridia.ulb.ac.be/Calendars/ calendars]:<br />
** [https://www.google.com/calendar/ical/km87al7a1mb596h2l07mknom48%40group.calendar.google.com/public/basic.ics IRIDIA Seminars]<br />
** [https://www.google.com/calendar/ical/26s3f312i7lhc2jpmvhtg4kqls%40group.calendar.google.com/public/basic.ics IRIDIA Robotics]<br />
** [https://www.google.com/calendar/ical/3aqjlr91cmusi761hounf7a7ac%40group.calendar.google.com/public/basic.ics IRIDIA Optimization]<br />
** [https://www.google.com/calendar/ical/ait7l5qcsv24f9jmshvl2g0urc%40group.calendar.google.com/public/basic.ics IRIDIA Others]<br />
<br />
* You are also encouraged to apply for a membership to the [http://groups.google.com/group/iridians iridians mailing list], where you will be kept posted about dinners and other events we might organise. :-) You are more than welcome to propose events!<br />
<br />
In [http://iridia.ulb.ac.be/wiki/Moving_to_Brussels this] and [http://iridia.ulb.ac.be/wiki/Surviving_in_Brussels this] page you can find general information about living in Bruxelles (where to search for a flat, French courses, bureaucracy etc.)<br />
<br />
For further questions contact [http://iridia.ulb.ac.be/~fpagnozzi Federico Pagnozzi].<br />
<br />
=== PhD students and Post-Docs only ===<br />
<br />
* WEB server space and email@iridia.ulb.ac.be. <br>Contact the IRIDIA web server administrator (currently [http://code.ulb.ac.be/iridia.people.php?id=1473 Volker Strobel]).<br />
<br />
* Static IP address (i.e., wired Ethernet connection). <br>Write an email to the IRIDIA web server administrator (currently [http://code.ulb.ac.be/iridia.people.php?id=1473 Volker Strobel]) with the following information:<br />
** the MAC address of your wired Ethernet device,<br />
** the "type" of your computer (e.g., private laptop, IRIDIA desktop PC,...),<br />
** for how long you probably need to have the wired connection.<br />
<br />
* Account on the BACKUP server.<br/>Contact the system administrator of the IRIDIA's backup server (currently [http://iridia.ulb.ac.be/~eferrante/ Eliseo Ferrante]).<br />
<br />
* If you are supposed to have the key of the robotic lab (arena), [http://iridia.ulb.ac.be/~mbiro Mauro Birattari] can provide you a copy of the key.<br />
<br />
* If you need an SVN account ask [http://code.ulb.ac.be/iridia.people.php?id=1307 Lorenzo Garattoni].<br />
<br />
* For an account on the IRIDIA Wiki, contact the responsible (currently [http://iridia.ulb.ac.be/~afranzin Alberto Franzin]).<br />
<br />
* You can subscribe to the following two mailing lists:<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/staff Staff] (if you are a new phd student or postdoc)<br />
** [https://iridia.ulb.ac.be/cgi-bin/mailman/listinfo/phdstudents PhD Students](if you are a new phd student)<br />
<br />
* In [http://iridia.ulb.ac.be/wiki/Workstation_configuration this page] you can find useful information concerning the configuration of email, printers etc.<br />
<br />
If you work at IRIDIA for a longer period of time, probably you want also an email @ulb.ac.be. For [https://idsapp.ulb.ac.be/pam/pamsignup.php?language=uk registering] you will need an "Enrollment number" and a "PIN-code/Numéro de lecteur". You can find them on your ULB card. Once you activate the account you can [https://idsapp.ulb.ac.be/pam/index.php manage your account], [http://webserv1.ulb.ac.be/intranet/access?_mode=login1 access the intranet], and [http://webmail.ulb.ac.be/ your webmail].<br />
<br />
== Notes ==<br />
1. <sup>^</sup> <sup id="note1">[[What_you_need_to_begin_to_work_in_IRIDIA#ref1|a]]</sup> In order not to be submerged by spam, most of the lists accept posts only from email addresses that are in the subscribers list... meaning that if you subscribed to the Staff list with the address xxx@iridia.ulb.ac.be and try to send a message from your other addresses xxx@ulb.ac.be or xyz@gmail.com they will be discarded by the system.<br>If you have experienced such a problem, or want to be allowed to post from your other addresses, please contact the list owner providing the list of addresses to be added to the "white-list".</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8117
Iridia Supplementary Information Instructions page
2019-01-24T13:16:57Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you find instructions on how to use the Iridia Supplementary Information page (http://iridia.ulb.ac.be/supp). You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8116
Iridia Supplementary Information Instructions page
2019-01-24T13:12:41Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you find instructions on how to use the Iridia Supplementary Information page (http://iridia.ulb.ac.be/supp). You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8115
Iridia Supplementary Information Instructions page
2019-01-24T13:12:29Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page (http://iridia.ulb.ac.be/supp). You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8114
Iridia Supplementary Information Instructions page
2019-01-24T13:11:36Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
The structure is as follows:<br />
* At the page http://iridia.ulb.ac.be/supp, we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8113
Iridia Supplementary Information Instructions page
2019-01-24T13:10:51Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
The structure is as follows:<br />
* At the page http://iridia.ulb.ac.be/supp, we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# You should<br />
## <br />
##<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8112
Iridia Supplementary Information Instructions page
2019-01-24T13:10:10Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to the IRIDIA Supplementary Information Pages.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# You should<br />
## <br />
##<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8111
Iridia Supplementary Information Instructions page
2019-01-24T13:09:14Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to this page.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# You should<br />
## <br />
##<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8110
Iridia Supplementary Information Instructions page
2019-01-24T13:09:04Z
<p>VolkerStrobel: /* Procedure for adding supplementary material */</p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to this page.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# Locally prepare:<br />
## The index.html of your supplementary page using the template at http://iridia.ulb.ac.be/supp/template.html. Your index.html should contain all the information referred to in the paper (it can also include extra text). You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
## All the supplementary information (images, videos, etc.) and use local links from the index.html page.<br />
## <br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# You should<br />
## <br />
##<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8109
Iridia Supplementary Information Instructions page
2019-01-24T12:59:50Z
<p>VolkerStrobel: /* Procedure for adding supplementary material */</p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to this page.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# First create your supplementary page locally using the template at http://iridia.ulb.ac.be/supp/template.html. You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
<br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# You should<br />
## create an index.html page which should contain ALL the information referred to in the paper. It can potentially include extra text.<br />
## create a compressed file with all the supplementary information (images, videos, etc) in her/his directory, and USE LOCAL LINKS in hers/his index.html pages<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8108
Iridia Supplementary Information Instructions page
2019-01-24T12:56:35Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to this page.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# First create your supplementary page locally using the template at http://iridia.ulb.ac.be/supp/template.html. You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
<br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# Your should<br />
## create an index.html page which should contain ALL the information referred to in the paper. It can potentially include extra text.<br />
## create a compressed file with all the supplementary information (images, videos, etc) in her/his directory, and USE LOCAL LINKS in hers/his index.html pages<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8107
Iridia Supplementary Information Instructions page
2019-01-24T12:55:48Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to this page.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep a record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# First create your supplementary page locally using the template at [[http://iridia.ulb.ac.be/supp/template.html]]. You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
<br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# Your should<br />
## create an index.html page which should contain ALL the information referred to in the paper. It can potentially include extra text.<br />
## create a compressed file with all the supplementary information (images, videos, etc) in her/his directory, and USE LOCAL LINKS in hers/his index.html pages<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8106
Iridia Supplementary Information Instructions page
2019-01-24T12:55:14Z
<p>VolkerStrobel: /* Procedure for adding supplementary material */</p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to this page.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
# First create your supplementary page locally using the template at [[http://iridia.ulb.ac.be/supp/template.html]]. You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
<br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# Your should<br />
## create an index.html page which should contain ALL the information referred to in the paper. It can potentially include extra text.<br />
## create a compressed file with all the supplementary information (images, videos, etc) in her/his directory, and USE LOCAL LINKS in hers/his index.html pages<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Iridia_Supplementary_Information_Instructions_page&diff=8105
Iridia Supplementary Information Instructions page
2019-01-24T11:51:49Z
<p>VolkerStrobel: </p>
<hr />
<div>On this page, you can find instructions on how to use the Iridia Supplementary Information page. You should transfer all the supplementary information (videos, images, pictures, graphs, etc.) of your papers to this page.<br />
The structure is as follows:<br />
* There is the page http://iridia.ulb.ac.be/supp in which we keep record of all the papers containing supplementary information, with a link leading to a dedicated page containing this info. <br />
* Under /supp/ there are directories, one for each paper, containing all the media plus an index.html file<br />
<br />
<br />
=== Procedure for adding supplementary material ===<br />
<br />
The procedure is the following:<br />
<br />
# First create your supplementary page locally using the template at [[http://iridia.ulb.ac.be/supp/template.html]]. You can develop and try out your page in the public_html/ directory of your user account on the IRIDIA web server.<br />
<br />
# Then, please write an email to the [[Lab_responsibilities|responsible of the supplementary pages]] with the following information:<br />
## Title<br />
## Authors<br />
## Link to or zip file of your supplementary page <br />
<br />
# The [[Lab_responsibilities|responsible of the supplementary pages]] will create a directory under http://iridia.ulb.ac.be/supp/ with the title IridiaSupp200x-00x (the numbering is according to the year of the paper and the rank it gets for that year). Papers will acquire an ascending number (the first who asks for a number gets it). <br />
# Your should<br />
## create an index.html page which should contain ALL the information referred to in the paper. It can potentially include extra text.<br />
## create a compressed file with all the supplementary information (images, videos, etc) in her/his directory, and USE LOCAL LINKS in hers/his index.html pages<br />
<br />
<br />
=== Adding streaming video ===<br />
<br />
To add a streaming video, please use HTML5. The simple procedure is the following.<br />
<br />
# Add the tag <pre><video src="video.ogg" controls="controls">Your browser does not support the video tag.</video></pre><br />
# Convert your avi to ogg with <pre> ffmpeg -i video.avi -b 1024k video.ogg </pre><br />
# Place video.ogg in IridiaSupp200x-00x<br />
<br />
More info on ffmpeg can be found here: [[Ffmpeg|useful ffmpeg commands]].<br />
<br />
=== Questions? ===<br />
<br />
In case you have any questions, please contact the [[Lab_responsibilities|responsible of the supplementary pages]].</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Volker_Literature&diff=8099
Volker Literature
2018-10-06T11:18:32Z
<p>VolkerStrobel: /* PROPOSED (SKIMMED) */</p>
<hr />
<div>== Robotics ==<br />
<br />
=== PROPOSED (READ) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="BicFagPal2010:ram" class="entry"><br />
<td>Bicchi, A., Fagiolini, A. and Pallottino, L.</td><br />
<td>Towards a Society of Robots</td><br />
<td>2010</td><br />
<td>IEEE Robotics Automation Magazine<br/>Vol. 17(4), pp. 26-36&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:BicFagPal2010ram.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZikLebGur2014:rusmart" class="entry"><br />
<td>Zikratov, I.A., Lebedev, I.S. and Gurtov, A.V.</td><br />
<td>Trust and Reputation Mechanisms for Multi-agent Robotic Systems</td><br />
<td>2014</td><br />
<td>Internet of Things, Smart Spaces, and Next Generation Networks and Systems: 14th International Conference, NEW2AN 2014 and 7th Conference, ruSMART 2014, St. Petersburg, Russia, August 27-29, 2014. Proceedings, pp. 106-120&nbsp;</td><br />
<td>inbook</td><br />
<td></td><br />
<td>[[Media:ZikLebGur2014rusmart.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== PROPOSED (SKIMMED) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="BuiGan2014:ecai" class="entry"><br />
<td>Buiu, C. and G&acirc;nsari, M.</td><br />
<td>A new model for interactions between robots in a swarm</td><br />
<td>2014</td><br />
<td>Proc. 6th Int Electronics, Computers and Artificial Intelligence (ECAI) Conf, pp. 5-10&nbsp;</td><br />
<td>inproceedings</td><br />
<td>The authors use P colonies to model interactions in a robot swarm.</td><br />
<td>[[Media:BuiGan2014ecai.pdf|pdf]]</td><br />
</tr><br />
<tr id="SarTom2013:dasc" class="entry"><br />
<td>Sargeant, I. and Tomlinson, A.</td><br />
<td>Modelling malicious entities in a robotic swarm</td><br />
<td>2013</td><br />
<td>Proc. IEEE/AIAA 32nd Digital Avionics Systems Conf. (DASC), pp. 7B1-1-7B1-12&nbsp;</td><br />
<td>inproceedings</td><br />
<td>The author focuses on security aspects in robot swarms. Might be quite interesting.</td><br />
<td>[[Media:SarTom2013dasc.pdf|pdf]]</td><br />
</tr><br />
<tr id="SarTom2016:escs" class="entry"><br />
<td>Sargeant, I. and Tomlinson, A.</td><br />
<td>Maliciously Manipulating a Robotic Swarm</td><br />
<td>2016</td><br />
<td>Proceedings of the Int'l Conf. Embedded Systems, Cyber-physical Systems, &amp; Applications (ESCS'16)&nbsp;</td><br />
<td>incollection</td><br />
<td>The author focuses on security aspects in robot swarms. Might be quite interesting.</td><br />
<td>[[Media:SarTom2016escs.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== PROPOSED (UNREAD) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="AzaHorSri-etal2006:wac" class="entry"><br />
<td>Azarnoush, H., Horan, B., Sridhar, P., Madni, A.M. and Jamshidi, M.</td><br />
<td>Towards optimization of a real-world Robotic-Sensor System of Systems</td><br />
<td>2006</td><br />
<td>Proc. World Automation Congress, pp. 1-8&nbsp;</td><br />
<td>inproceedings</td><br />
<td></td><br />
<td>[[Media:AzaHorSri-etal2006wac.pdf|pdf]]</td><br />
</tr><br />
<tr id="LaiNgTomMar2016:inbook" class="entry"><br />
<td>Laing, T.M., Ng, S.-L., Tomlinson, A. and Martin, K.M.</td><br />
<td>Security in Swarm Robotics</td><br />
<td>2016</td><br />
<td>Handbook of Research on Design, Control, and Modeling of Swarm Robotics, pp. 42-66&nbsp;</td><br />
<td>incollection</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr id="NouGroBon-etal2009:tec" class="entry"><br />
<td>Nouyan, S., Gross, R., Bonani, M., Mondada, F. and Dorigo, M.</td><br />
<td>Teamwork in Self-Organized Robot Colonies</td><br />
<td>2009</td><br />
<td>IEEE Transactions on Evolutionary Computation<br/>Vol. 13(4), pp. 695-711&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:NouGroBon-etal2009tec.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZikLebGurKuz2014:aict" class="entry"><br />
<td>Zikratov, I.A., Lebedev, I.S., Gurtov, A.V. and Kuzmich, E.V.</td><br />
<td>Securing swarm intellect robots with a police office model</td><br />
<td>2014</td><br />
<td>Proc. IEEE 8th Int Application of Information and Communication Technologies (AICT) Conference, pp. 1-5&nbsp;</td><br />
<td>inproceedings</td><br />
<td></td><br />
<td>[[Media:ZikLebGurKuz2014aict.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZikMasLeb-etal2016:rusmart" class="entry"><br />
<td>Zikratov, I., Maslennikov, O., Lebedev, I., Ometov, A. and Andreev, S.</td><br />
<td>Dynamic Trust Management Framework for Robotic Multi-Agent Systems</td><br />
<td>2016</td><br />
<td>Internet of Things, Smart Spaces, and Next Generation Networks and Systems: 16th International Conference, NEW2AN 2016, and 9th Conference, ruSMART 2016, St. Petersburg, Russia, September 26-28, 2016, Proceedings, pp. 339-348&nbsp;</td><br />
<td>inbook</td><br />
<td></td><br />
<td>[[Media:ZikMasLeb-etal2016rusmart.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== READ (FRIA) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="Bay2016:el" class="entry"><br />
<td>Bayindir, L.</td><br />
<td>A review of swarm robotics tasks</td><br />
<td>2016</td><br />
<td>Neurocomputing<br/>Vol. 172, pp. 292-321&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Bay2016neurocomp.pdf|pdf]]</td><br />
</tr><br />
<tr id="BonDorThe1999:book" class="entry"><br />
<td>Bonabeau, E., Dorigo, M. and Theraulaz, G.</td><br />
<td>Swarm Intelligence: From Natural to Artificial Systems</td><br />
<td>1999</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td>[[Media:BonDorThe1999book.pdf|pdf]]</td><br />
</tr><br />
<tr id="BraBruDorBir2014:acmtaas" class="entry"><br />
<td>Brambilla, M., Brutschy, A., Dorigo, M. and Birattari, M.</td><br />
<td>Property-driven design for robot swarms: A design method based on prescriptive modeling and model checking</td><br />
<td>2014</td><br />
<td>ACM Transactions on Autonomous and Adaptive Systems<br/>Vol. 9(4), pp. 17:1-17:28&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:BraBruDorBir2014acmtaas.pdf|pdf]]</td><br />
</tr><br />
<tr id="BraFerBirDor2013:si" class="entry"><br />
<td>Brambilla, M., Ferrante, E., Birattari, M. and Dorigo, M.</td><br />
<td>Swarm robotics: A Review from the Swarm Engineering Perspective</td><br />
<td>2013</td><br />
<td>Swarm Intelligence<br/>Vol. 7(1), pp. 1-41&nbsp;</td><br />
<td>article</td><br />
<td>The review uses two taxonomies (i) methods and (ii) collective behaviors, to compare swarm robotics research. It was interesting to see that most papers use one of the following techniques:<br />
- probabilistic finite state machine<br />
- virtual physics-based design<br />
- artificial evolution</td><br />
<td>[[Media:BraFerBirDor2013si.pdf|pdf]]</td><br />
</tr><br />
<tr id="DorFloGam-etal2013:ram" class="entry"><br />
<td>Dorigo, M., Floreano, D., Gambardella, L.M., Mondada, F., Nolfi, S., Baaboura, T., Birattari, M., Bonani, M., Brambilla, M., Brutschy, A., Burnier, D., Campo, A., Christensen, A.L., Decugniere, A., Caro, G.D., Ducatelle, F., Ferrante, E., Forster, A., Gonzales, J.M., Guzzi, J., Longchamp, V., Magnenat, S., Mathews, N., de Oca, M.M., O'Grady, R., Pinciroli, C., Pini, G., Retornaz, P., Roberts, J., Sperati, V., Stirling, T., Stranieri, A., Stutzle, T., Trianni, V., Tuci, E., Turgut, A.E. and Vaussard, F.</td><br />
<td>Swarmanoid: A Novel Concept for the Study of Heterogeneous Robotic Swarms</td><br />
<td>2013</td><br />
<td>IEEE Robotics Automation Magazine<br/>Vol. 20(4), pp. 60-71&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:DorFloGam-etal2013ram.pdf|pdf]]</td><br />
</tr><br />
<tr id="Fer2016:arxiv" class="entry"><br />
<td>Ferrer, E.C.</td><br />
<td>The blockchain: a new framework for robotic swarm systems</td><br />
<td>2016</td><br />
<td>&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Fer2016arxiv.pdf|pdf]]</td><br />
</tr><br />
<tr id="HigTomMar2009:icas" class="entry"><br />
<td>Higgins, F., Tomlinson, A. and Martin, K.M.</td><br />
<td>Survey on Security Challenges for Swarm Robotics</td><br />
<td>2009</td><br />
<td>Proc. Fifth Int. Conf. Autonomic and Autonomous Systems, pp. 307-312&nbsp;</td><br />
<td>incollection</td><br />
<td></td><br />
<td>[[Media:HigTomMar2009icas.pdf|pdf]]</td><br />
</tr><br />
<tr id="MasBraLat-etal2013:si" class="entry"><br />
<td>Massink, M., Brambilla, M., Latella, D., Dorigo, M. and Birattari, M.</td><br />
<td>On the use of Bio-PEPA for modelling and analysing collective behaviours in swarm robotics</td><br />
<td>2013</td><br />
<td>Swarm Intelligence<br/>Vol. 7(2-3), pp. 201-228&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:MasBraLat-etal2013si.pdf|pdf]]</td><br />
</tr><br />
<tr id="MonPetGui-etal2004:autrob" class="entry"><br />
<td>Mondada, F., Pettinaro, G.C., Guignard, A., Kwee, I.W., Floreano, D., Deneubourg, J.-L., Nolfi, S., Gambardella, L.M. and Dorigo, M.</td><br />
<td>Swarm-Bot: A New Distributed Robotic Concept</td><br />
<td>2004</td><br />
<td>Autonomous Robots<br/>Vol. 17(2-3), pp. 193-221&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:MonPetGui-etal2004autrob.pdf|pdf]]</td><br />
</tr><br />
<tr id="RubCorNag2014:science" class="entry"><br />
<td>Rubenstein, M., Cornejo, A. and Nagpal, R.</td><br />
<td>Programmable self-assembly in a thousand-robot swarm</td><br />
<td>2014</td><br />
<td>Science<br/>Vol. 345(6198), pp. 795-799&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:RubCorNag2014science.pdf|pdf]]</td><br />
</tr><br />
<tr id="ValFerHamDor2016:aamas" class="entry"><br />
<td>Valentini, G., Ferrante, E., Hamann, H. and Dorigo, M.</td><br />
<td>Collective Decision with 100 Kilobots: Speed Versus Accuracy in Binary Discrimination Problems</td><br />
<td>2016</td><br />
<td>Autonomous Agents and Multi-Agent Systems<br/>Vol. 30(3), pp. 553-580&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:ValFerHamDor2016aamas.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZloSteDiaTha2002:icra" class="entry"><br />
<td>Zlot, R., Stentz, A., Dias, M.B. and Thayer, S.</td><br />
<td>Multi-robot exploration controlled by a market economy</td><br />
<td>2002</td><br />
<td>Proceedings of the 2002 IEEE International Conference on Robotics and Automation, pp. 3016-3023&nbsp;</td><br />
<td>incollection</td><br />
<td></td><br />
<td>[[Media:ZloSteDiaTha2002icra.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
== Blockchain technology ==<br />
<br />
=== PROPOSED (READ) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="ChrDev2016:access" class="entry"><br />
<td>Christidis, K. and Devetsikiotis, M.</td><br />
<td>Blockchains and Smart Contracts for the Internet of Things</td><br />
<td>2016</td><br />
<td>IEEE Access<br/>Vol. 4, pp. 2292-2303&nbsp;</td><br />
<td>article</td><br />
<td>The papers gives a very good overview of the state of the art of blockchain technology (PoW/PoS, smart contracts, ...). It does not deal that much with The Internet of Things domain. There are just some possible applications, such as firmware update and workflow automation.</td><br />
<td>[[Media:ChrDev2016access.pdf|pdf]]</td><br />
</tr><br />
<tr id="DelArnKos-etal2015:iacr" class="entry"><br />
<td>Kevin Delmolino Mitchell Arnett, A.K.A.M. and Shi, E.</td><br />
<td>Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab.</td><br />
<td>2015</td><br />
<td>IACR Cryptology ePrint Archive, Report 2015/460&nbsp;</td><br />
<td>techreport</td><br />
<td>The paper describes some experiences of the authors teaching to program smart contracts to students. The authors use Serpent and descreibed possible pitfalls based on one scenario.</td><br />
<td>[[Media:DelArnKos-etal2015iacr.pdf|pdf]]</td><br />
</tr><br />
<tr id="LuuChuOli2016:iacr" class="entry"><br />
<td>Luu, L., Chu, D.-H., Olickel, H., Saxena, P. and Hobor, A.</td><br />
<td>Making smart contracts smarter</td><br />
<td>2016</td><br />
<td><i>School</i>: Cryptology ePrint Archive, Report 2016/633, 201 6. http://eprint. iacr. org/2016/633&nbsp;</td><br />
<td>techreport</td><br />
<td>Discusses security issues in smart contracts and presents Oyente, a tool for finding security bugs.</td><br />
<td>[[Media:LuuChuOli2016iacr.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== PROPOSED (SKIMMED) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="Atz2016:ssrn" class="entry"><br />
<td>Atzori, M.</td><br />
<td>Blockchain-Based Architectures for the Internet of Things: A Survey.</td><br />
<td>2016</td><br />
<td>Available at SSRN&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
</tr><br />
<tr id="DorKanJur2016:arxiv" class="entry"><br />
<td>Dorri, A., Kanhere, S.S. and Jurdak, R.</td><br />
<td>Blockchain in internet of things: Challenges and Solutions</td><br />
<td>2016</td><br />
<td>pre-print&nbsp;</td><br />
<td>article</td><br />
<td>The authors describe possible applications for smart homes using "overlay networks." At first sight, the setup seems to be a bit too complicated since the blockchain is not really needed for the described application (only trusted devices, and so on) but I should read the paper again.</td><br />
<td>[[Media:DorKanJur2016arxiv.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== PROPOSED (UNREAD) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="LeiMemHog2016:ubicomp" class="entry"><br />
<td>Leiding, B., Memarmoshrefi, P. and Hogrefe, D.</td><br />
<td>Self-managed and Blockchain-based Vehicular Ad-hoc Networks</td><br />
<td>2016</td><br />
<td>Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing: Adjunct, pp. 137-140&nbsp;</td><br />
<td>inproceedings</td><br />
<td>I should read the paper again. It's quite short (3 pages) and I think it mainly describes a scenario for automated payments for cars.</td><br />
<td>[[Media:LeiMemHog2016ubicomp.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== READ (FRIA) ===<br />
<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="But2014:online" class="entry"><br />
<td>Buterin, V.</td><br />
<td>Ethereum: A next-generation smart contract and decentralized application platform</td><br />
<td>2014</td><br />
<td>&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:But2014techreport.pdf|pdf]]</td><br />
</tr><br />
<tr id="Fer2016:arxiv" class="entry"><br />
<td>Ferrer, E.C.</td><br />
<td>The blockchain: a new framework for robotic swarm systems</td><br />
<td>2016</td><br />
<td>&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Fer2016arxiv.pdf|pdf]]</td><br />
</tr><br />
<tr id="Nak2008:techreport" class="entry"><br />
<td>Nakamoto, S.</td><br />
<td>Bitcoin: A peer-to-peer electronic cash system</td><br />
<td>2008</td><br />
<td>&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:Nak2008techreport.pdf|pdf]]</td><br />
</tr><br />
<tr id="Sza1997:techreport" class="entry"><br />
<td>Szabo, N.</td><br />
<td>Formalizing and securing relationships on public networks</td><br />
<td>1997</td><br />
<td>First Monday<br/>Vol. 2(9)&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:Sza1997techreport.pdf|pdf]]</td><br />
</tr><br />
<tr id="Woo2014:techreport" class="entry"><br />
<td>Wood, G.</td><br />
<td>Ethereum: A secure decentralised generalised transaction ledger</td><br />
<td>2014</td><br />
<td>Ethereum Project Yellow Paper&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:Woo2014techreport.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
== Others ==<br />
<br />
=== PROPOSED (UNERAD) ===<br />
<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="ButHub2007:book" class="entry"><br />
<td>Levente Buttyan, J.-P.H.</td><br />
<td>Security and Cooperation in Wireless Networks: Thwarting Malicious and Selfish Behavior in the Age of Ubiquitous Computing</td><br />
<td>2007</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td>[[Media:ButHub2007book.pdf|pdf]]</td><br />
</tr><br />
<tr id="BeaRen2007:book" class="entry"><br />
<td>Randal Beard, W.R.</td><br />
<td>Distributed Consensus in Multi-vehicle Cooperative Control</td><br />
<td>2007</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td></td><br />
</tr><br />
</table><br />
<br />
=== READ (FRIA) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="Con2010:annmai" class="entry"><br />
<td>Conitzer, V.</td><br />
<td>Comparing Multiagent Systems Research in Combinatorial Auctions and Voting</td><br />
<td>2010</td><br />
<td>Annals of Mathematics and Artificial Intelligence<br/>Vol. 58(3-4), pp. 239-259&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Con2010annmai.pdf|pdf]]</td><br />
</tr><br />
<tr id="ParWoo2002:aamas" class="entry"><br />
<td>Parsons, S. and Wooldridge, M.</td><br />
<td>Game Theory and Decision Theory in Multi-Agent Systems</td><br />
<td>2002</td><br />
<td>Autonomous Agents and Multi-Agent Systems<br/>Vol. 5(3), pp. 243-254&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:ParWoo2002aamas.pdf|pdf]]</td><br />
</tr><br />
<tr id="PezBabChe-etal2013:ejor" class="entry"><br />
<td>Pezeshki, Y., Baboli, A., Cheikhrouhou, N., Modarres, M. and Jokar, M.R.A.</td><br />
<td>A rewarding-punishing coordination mechanism based on Trust in a divergent supply chain</td><br />
<td>2013</td><br />
<td>European Journal of Operational Research<br/>Vol. 230(3), pp. 527-538&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:PezBabChe-etal2013ejor.pdf|pdf]]</td><br />
</tr><br />
<tr id="WooWo2001:book" class="entry"><br />
<td>Woolridge, M. and Wooldridge, M.J.</td><br />
<td>An Introduction to Multiagent Systems - Second Edition</td><br />
<td>2001</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td>[[Media:WooWoo2001book.pdf|pdf]]</td><br />
</tr><br />
</table></div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8046
PhDSupervision:VolkerStrobel
2018-05-31T15:06:23Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Recurring question: sparse connectivity; separate the swarm in the beginning; different regions with different distributions<br />
<br />
* Test the safety criteria of the AAMAS paper<br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8045
PhDSupervision:VolkerStrobel
2018-05-30T20:16:20Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Test the safety criteria of the AAMAS paper<br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8043
PhDSupervision:VolkerStrobel
2018-04-18T13:21:45Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8042
PhDSupervision:VolkerStrobel
2018-04-18T13:21:09Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Reputation management system: Experiment with a, b in Python (the values are stored in allVotes.txt); maybe there's something<br />
better than the parabola (e.g., x^3, standard deviation, or online k-means clustering).<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8041
PhDSupervision:VolkerStrobel
2018-04-17T14:58:24Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm (could be done during my stay at MIT and would be important to convince people that blockchain technology is suited for robot swarms)<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8040
PhDSupervision:VolkerStrobel
2018-04-17T14:57:06Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* Introduce a real permissioned blockchain (look into HydraChain and Monax) and use an alternative consensus algorithm<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=Volker_Literature&diff=8010
Volker Literature
2018-03-02T10:46:24Z
<p>VolkerStrobel: Protected "Volker Literature" ([edit=VolkerStrobel] (indefinite) [move=VolkerStrobel] (indefinite) [read=VolkerStrobel] (indefinite))</p>
<hr />
<div>== Robotics ==<br />
<br />
=== PROPOSED (READ) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="BicFagPal2010:ram" class="entry"><br />
<td>Bicchi, A., Fagiolini, A. and Pallottino, L.</td><br />
<td>Towards a Society of Robots</td><br />
<td>2010</td><br />
<td>IEEE Robotics Automation Magazine<br/>Vol. 17(4), pp. 26-36&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:BicFagPal2010ram.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZikLebGur2014:rusmart" class="entry"><br />
<td>Zikratov, I.A., Lebedev, I.S. and Gurtov, A.V.</td><br />
<td>Trust and Reputation Mechanisms for Multi-agent Robotic Systems</td><br />
<td>2014</td><br />
<td>Internet of Things, Smart Spaces, and Next Generation Networks and Systems: 14th International Conference, NEW2AN 2014 and 7th Conference, ruSMART 2014, St. Petersburg, Russia, August 27-29, 2014. Proceedings, pp. 106-120&nbsp;</td><br />
<td>inbook</td><br />
<td></td><br />
<td>[[Media:ZikLebGur2014rusmart.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== PROPOSED (SKIMMED) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="BuiGan2014:ecai" class="entry"><br />
<td>Buiu, C. and G&acirc;nsari, M.</td><br />
<td>A new model for interactions between robots in a swarm</td><br />
<td>2014</td><br />
<td>Proc. 6th Int Electronics, Computers and Artificial Intelligence (ECAI) Conf, pp. 5-10&nbsp;</td><br />
<td>inproceedings</td><br />
<td>The authors use P colonies to model interactions in a robot swarm.</td><br />
<td>[[Media:BuiGan2014ecai.pdf|pdf]]</td><br />
</tr><br />
<tr id="SarTom2013:dasc" class="entry"><br />
<td>Sargeant, I. and Tomlinson, A.</td><br />
<td>Modelling malicious entities in a robotic swarm</td><br />
<td>2013</td><br />
<td>Proc. IEEE/AIAA 32nd Digital Avionics Systems Conf. (DASC), pp. 7B1-1-7B1-12&nbsp;</td><br />
<td>inproceedings</td><br />
<td>The author focuses on security aspects in robot swarms. Might be quite interesting.</td><br />
<td>[[Media:SarTom2013dasc.pdf|pdf]]</td><br />
</tr><br />
<tr id="SarTom2016:escs" class="entry"><br />
<td>Sargeant, I. and Tomlinson, A.</td><br />
<td>Maliciously Manipulating a Robotic Swarm</td><br />
<td>2016</td><br />
<td>Proceedings of the Int'l Conf. Embedded Systems, Cyber-physical Systems, &amp; Applications (ESCS'16)&nbsp;</td><br />
<td>incollection</td><br />
<td>The author focuses on security aspects in robot swarms. Might be quite interesting.</td><br />
<td>[[Media:SarTom2016escs.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== PROPOSED (UNREAD) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="AzaHorSri-etal2006:wac" class="entry"><br />
<td>Azarnoush, H., Horan, B., Sridhar, P., Madni, A.M. and Jamshidi, M.</td><br />
<td>Towards optimization of a real-world Robotic-Sensor System of Systems</td><br />
<td>2006</td><br />
<td>Proc. World Automation Congress, pp. 1-8&nbsp;</td><br />
<td>inproceedings</td><br />
<td></td><br />
<td>[[Media:AzaHorSri-etal2006wac.pdf|pdf]]</td><br />
</tr><br />
<tr id="LaiNgTomMar2016:inbook" class="entry"><br />
<td>Laing, T.M., Ng, S.-L., Tomlinson, A. and Martin, K.M.</td><br />
<td>Security in Swarm Robotics</td><br />
<td>2016</td><br />
<td>Handbook of Research on Design, Control, and Modeling of Swarm Robotics, pp. 42-66&nbsp;</td><br />
<td>incollection</td><br />
<td></td><br />
<td></td><br />
</tr><br />
<tr id="NouGroBon-etal2009:tec" class="entry"><br />
<td>Nouyan, S., Gross, R., Bonani, M., Mondada, F. and Dorigo, M.</td><br />
<td>Teamwork in Self-Organized Robot Colonies</td><br />
<td>2009</td><br />
<td>IEEE Transactions on Evolutionary Computation<br/>Vol. 13(4), pp. 695-711&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:NouGroBon-etal2009tec.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZikLebGurKuz2014:aict" class="entry"><br />
<td>Zikratov, I.A., Lebedev, I.S., Gurtov, A.V. and Kuzmich, E.V.</td><br />
<td>Securing swarm intellect robots with a police office model</td><br />
<td>2014</td><br />
<td>Proc. IEEE 8th Int Application of Information and Communication Technologies (AICT) Conference, pp. 1-5&nbsp;</td><br />
<td>inproceedings</td><br />
<td></td><br />
<td>[[Media:ZikLebGurKuz2014aict.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZikMasLeb-etal2016:rusmart" class="entry"><br />
<td>Zikratov, I., Maslennikov, O., Lebedev, I., Ometov, A. and Andreev, S.</td><br />
<td>Dynamic Trust Management Framework for Robotic Multi-Agent Systems</td><br />
<td>2016</td><br />
<td>Internet of Things, Smart Spaces, and Next Generation Networks and Systems: 16th International Conference, NEW2AN 2016, and 9th Conference, ruSMART 2016, St. Petersburg, Russia, September 26-28, 2016, Proceedings, pp. 339-348&nbsp;</td><br />
<td>inbook</td><br />
<td></td><br />
<td>[[Media:ZikMasLeb-etal2016rusmart.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== READ (FRIA) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="Bay2016:el" class="entry"><br />
<td>Bayindir, L.</td><br />
<td>A review of swarm robotics tasks</td><br />
<td>2016</td><br />
<td>Neurocomputing<br/>Vol. 172, pp. 292-321&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Bay2016neurocomp.pdf|pdf]]</td><br />
</tr><br />
<tr id="BonDorThe1999:book" class="entry"><br />
<td>Bonabeau, E., Dorigo, M. and Theraulaz, G.</td><br />
<td>Swarm Intelligence: From Natural to Artificial Systems</td><br />
<td>1999</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td>[[Media:BonDorThe1999book.pdf|pdf]]</td><br />
</tr><br />
<tr id="BraBruDorBir2014:acmtaas" class="entry"><br />
<td>Brambilla, M., Brutschy, A., Dorigo, M. and Birattari, M.</td><br />
<td>Property-driven design for robot swarms: A design method based on prescriptive modeling and model checking</td><br />
<td>2014</td><br />
<td>ACM Transactions on Autonomous and Adaptive Systems<br/>Vol. 9(4), pp. 17:1-17:28&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:BraBruDorBir2014acmtaas.pdf|pdf]]</td><br />
</tr><br />
<tr id="BraFerBirDor2013:si" class="entry"><br />
<td>Brambilla, M., Ferrante, E., Birattari, M. and Dorigo, M.</td><br />
<td>Swarm robotics: A Review from the Swarm Engineering Perspective</td><br />
<td>2013</td><br />
<td>Swarm Intelligence<br/>Vol. 7(1), pp. 1-41&nbsp;</td><br />
<td>article</td><br />
<td>The review uses two taxonomies (i) methods and (ii) collective behaviors, to compare swarm robotics research. It was interesting to see that most papers use one of the following techniques:<br />
- probabilistic finite state machine<br />
- virtual physics-based design<br />
- artificial evolution</td><br />
<td>[[Media:BraFerBirDor2013si.pdf|pdf]]</td><br />
</tr><br />
<tr id="DorFloGam-etal2013:ram" class="entry"><br />
<td>Dorigo, M., Floreano, D., Gambardella, L.M., Mondada, F., Nolfi, S., Baaboura, T., Birattari, M., Bonani, M., Brambilla, M., Brutschy, A., Burnier, D., Campo, A., Christensen, A.L., Decugniere, A., Caro, G.D., Ducatelle, F., Ferrante, E., Forster, A., Gonzales, J.M., Guzzi, J., Longchamp, V., Magnenat, S., Mathews, N., de Oca, M.M., O'Grady, R., Pinciroli, C., Pini, G., Retornaz, P., Roberts, J., Sperati, V., Stirling, T., Stranieri, A., Stutzle, T., Trianni, V., Tuci, E., Turgut, A.E. and Vaussard, F.</td><br />
<td>Swarmanoid: A Novel Concept for the Study of Heterogeneous Robotic Swarms</td><br />
<td>2013</td><br />
<td>IEEE Robotics Automation Magazine<br/>Vol. 20(4), pp. 60-71&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:DorFloGam-etal2013ram.pdf|pdf]]</td><br />
</tr><br />
<tr id="Fer2016:arxiv" class="entry"><br />
<td>Ferrer, E.C.</td><br />
<td>The blockchain: a new framework for robotic swarm systems</td><br />
<td>2016</td><br />
<td>&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Fer2016arxiv.pdf|pdf]]</td><br />
</tr><br />
<tr id="HigTomMar2009:icas" class="entry"><br />
<td>Higgins, F., Tomlinson, A. and Martin, K.M.</td><br />
<td>Survey on Security Challenges for Swarm Robotics</td><br />
<td>2009</td><br />
<td>Proc. Fifth Int. Conf. Autonomic and Autonomous Systems, pp. 307-312&nbsp;</td><br />
<td>incollection</td><br />
<td></td><br />
<td>[[Media:HigTomMar2009icas.pdf|pdf]]</td><br />
</tr><br />
<tr id="MasBraLat-etal2013:si" class="entry"><br />
<td>Massink, M., Brambilla, M., Latella, D., Dorigo, M. and Birattari, M.</td><br />
<td>On the use of Bio-PEPA for modelling and analysing collective behaviours in swarm robotics</td><br />
<td>2013</td><br />
<td>Swarm Intelligence<br/>Vol. 7(2-3), pp. 201-228&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:MasBraLat-etal2013si.pdf|pdf]]</td><br />
</tr><br />
<tr id="MonPetGui-etal2004:autrob" class="entry"><br />
<td>Mondada, F., Pettinaro, G.C., Guignard, A., Kwee, I.W., Floreano, D., Deneubourg, J.-L., Nolfi, S., Gambardella, L.M. and Dorigo, M.</td><br />
<td>Swarm-Bot: A New Distributed Robotic Concept</td><br />
<td>2004</td><br />
<td>Autonomous Robots<br/>Vol. 17(2-3), pp. 193-221&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:MonPetGui-etal2004autrob.pdf|pdf]]</td><br />
</tr><br />
<tr id="RubCorNag2014:science" class="entry"><br />
<td>Rubenstein, M., Cornejo, A. and Nagpal, R.</td><br />
<td>Programmable self-assembly in a thousand-robot swarm</td><br />
<td>2014</td><br />
<td>Science<br/>Vol. 345(6198), pp. 795-799&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:RubCorNag2014science.pdf|pdf]]</td><br />
</tr><br />
<tr id="ValFerHamDor2016:aamas" class="entry"><br />
<td>Valentini, G., Ferrante, E., Hamann, H. and Dorigo, M.</td><br />
<td>Collective Decision with 100 Kilobots: Speed Versus Accuracy in Binary Discrimination Problems</td><br />
<td>2016</td><br />
<td>Autonomous Agents and Multi-Agent Systems<br/>Vol. 30(3), pp. 553-580&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:ValFerHamDor2016aamas.pdf|pdf]]</td><br />
</tr><br />
<tr id="ZloSteDiaTha2002:icra" class="entry"><br />
<td>Zlot, R., Stentz, A., Dias, M.B. and Thayer, S.</td><br />
<td>Multi-robot exploration controlled by a market economy</td><br />
<td>2002</td><br />
<td>Proceedings of the 2002 IEEE International Conference on Robotics and Automation, pp. 3016-3023&nbsp;</td><br />
<td>incollection</td><br />
<td></td><br />
<td>[[Media:ZloSteDiaTha2002icra.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
== Blockchain technology ==<br />
<br />
=== PROPOSED (READ) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="ChrDev2016:access" class="entry"><br />
<td>Christidis, K. and Devetsikiotis, M.</td><br />
<td>Blockchains and Smart Contracts for the Internet of Things</td><br />
<td>2016</td><br />
<td>IEEE Access<br/>Vol. 4, pp. 2292-2303&nbsp;</td><br />
<td>article</td><br />
<td>The papers gives a very good overview of the state of the art of blockchain technology (PoW/PoS, smart contracts, ...). It does not deal that much with The Internet of Things domain. There are just some possible applications, such as firmware update and workflow automation.</td><br />
<td>[[Media:ChrDev2016access.pdf|pdf]]</td><br />
</tr><br />
<tr id="DelArnKos-etal2015:iacr" class="entry"><br />
<td>Kevin Delmolino Mitchell Arnett, A.K.A.M. and Shi, E.</td><br />
<td>Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab.</td><br />
<td>2015</td><br />
<td>IACR Cryptology ePrint Archive, Report 2015/460&nbsp;</td><br />
<td>techreport</td><br />
<td>The paper describes some experiences of the authors teaching to program smart contracts to students. The authors use Serpent and descreibed possible pitfalls based on one scenario.</td><br />
<td>[[Media:DelArnKos-etal2015iacr.pdf|pdf]]</td><br />
</tr><br />
<tr id="LuuChuOli2016:iacr" class="entry"><br />
<td>Luu, L., Chu, D.-H., Olickel, H., Saxena, P. and Hobor, A.</td><br />
<td>Making smart contracts smarter</td><br />
<td>2016</td><br />
<td><i>School</i>: Cryptology ePrint Archive, Report 2016/633, 201 6. http://eprint. iacr. org/2016/633&nbsp;</td><br />
<td>techreport</td><br />
<td>Discusses security issues in smart contracts and presents Oyente, a tool for finding security bugs.</td><br />
<td>[[Media:LuuChuOli2016iacr.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== PROPOSED (SKIMMED) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="Atz2016:ssrn" class="entry"><br />
<td>Atzori, M.</td><br />
<td>Blockchain-Based Architectures for the Internet of Things: A Survey.</td><br />
<td>2016</td><br />
<td>Available at SSRN&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Atz2016ssrn.pdf|pdf]]</td><br />
</tr><br />
<tr id="DorKanJur2016:arxiv" class="entry"><br />
<td>Dorri, A., Kanhere, S.S. and Jurdak, R.</td><br />
<td>Blockchain in internet of things: Challenges and Solutions</td><br />
<td>2016</td><br />
<td>pre-print&nbsp;</td><br />
<td>article</td><br />
<td>The authors describe possible applications for smart homes using "overlay networks." At first sight, the setup seems to be a bit too complicated since the blockchain is not really needed for the described application (only trusted devices, and so on) but I should read the paper again.</td><br />
<td>[[Media:DorKanJur2016arxiv.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
<br />
=== PROPOSED (UNREAD) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="LeiMemHog2016:ubicomp" class="entry"><br />
<td>Leiding, B., Memarmoshrefi, P. and Hogrefe, D.</td><br />
<td>Self-managed and Blockchain-based Vehicular Ad-hoc Networks</td><br />
<td>2016</td><br />
<td>Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing: Adjunct, pp. 137-140&nbsp;</td><br />
<td>inproceedings</td><br />
<td>I should read the paper again. It's quite short (3 pages) and I think it mainly describes a scenario for automated payments for cars.</td><br />
<td>[[Media:LeiMemHog2016ubicomp.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
=== READ (FRIA) ===<br />
<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="But2014:online" class="entry"><br />
<td>Buterin, V.</td><br />
<td>Ethereum: A next-generation smart contract and decentralized application platform</td><br />
<td>2014</td><br />
<td>&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:But2014techreport.pdf|pdf]]</td><br />
</tr><br />
<tr id="Fer2016:arxiv" class="entry"><br />
<td>Ferrer, E.C.</td><br />
<td>The blockchain: a new framework for robotic swarm systems</td><br />
<td>2016</td><br />
<td>&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Fer2016arxiv.pdf|pdf]]</td><br />
</tr><br />
<tr id="Nak2008:techreport" class="entry"><br />
<td>Nakamoto, S.</td><br />
<td>Bitcoin: A peer-to-peer electronic cash system</td><br />
<td>2008</td><br />
<td>&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:Nak2008techreport.pdf|pdf]]</td><br />
</tr><br />
<tr id="Sza1997:techreport" class="entry"><br />
<td>Szabo, N.</td><br />
<td>Formalizing and securing relationships on public networks</td><br />
<td>1997</td><br />
<td>First Monday<br/>Vol. 2(9)&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:Sza1997techreport.pdf|pdf]]</td><br />
</tr><br />
<tr id="Woo2014:techreport" class="entry"><br />
<td>Wood, G.</td><br />
<td>Ethereum: A secure decentralised generalised transaction ledger</td><br />
<td>2014</td><br />
<td>Ethereum Project Yellow Paper&nbsp;</td><br />
<td>techreport</td><br />
<td></td><br />
<td>[[Media:Woo2014techreport.pdf|pdf]]</td><br />
</tr><br />
</table><br />
<br />
== Others ==<br />
<br />
=== PROPOSED (UNERAD) ===<br />
<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="ButHub2007:book" class="entry"><br />
<td>Levente Buttyan, J.-P.H.</td><br />
<td>Security and Cooperation in Wireless Networks: Thwarting Malicious and Selfish Behavior in the Age of Ubiquitous Computing</td><br />
<td>2007</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td>[[Media:ButHub2007book.pdf|pdf]]</td><br />
</tr><br />
<tr id="BeaRen2007:book" class="entry"><br />
<td>Randal Beard, W.R.</td><br />
<td>Distributed Consensus in Multi-vehicle Cooperative Control</td><br />
<td>2007</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td></td><br />
</tr><br />
</table><br />
<br />
=== READ (FRIA) ===<br />
<br />
<table id="qs_table" border="1"><br />
<tr><th width="20%">Author</th><th width="30%">Title</th><th width="5%">Year</th><th width="15%">Journal/Proceedings</th><th width="10%">Reftype</th><th width="12%">Comment</th><th width="3%">file</th></tr><br />
<tr id="Con2010:annmai" class="entry"><br />
<td>Conitzer, V.</td><br />
<td>Comparing Multiagent Systems Research in Combinatorial Auctions and Voting</td><br />
<td>2010</td><br />
<td>Annals of Mathematics and Artificial Intelligence<br/>Vol. 58(3-4), pp. 239-259&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:Con2010annmai.pdf|pdf]]</td><br />
</tr><br />
<tr id="ParWoo2002:aamas" class="entry"><br />
<td>Parsons, S. and Wooldridge, M.</td><br />
<td>Game Theory and Decision Theory in Multi-Agent Systems</td><br />
<td>2002</td><br />
<td>Autonomous Agents and Multi-Agent Systems<br/>Vol. 5(3), pp. 243-254&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:ParWoo2002aamas.pdf|pdf]]</td><br />
</tr><br />
<tr id="PezBabChe-etal2013:ejor" class="entry"><br />
<td>Pezeshki, Y., Baboli, A., Cheikhrouhou, N., Modarres, M. and Jokar, M.R.A.</td><br />
<td>A rewarding-punishing coordination mechanism based on Trust in a divergent supply chain</td><br />
<td>2013</td><br />
<td>European Journal of Operational Research<br/>Vol. 230(3), pp. 527-538&nbsp;</td><br />
<td>article</td><br />
<td></td><br />
<td>[[Media:PezBabChe-etal2013ejor.pdf|pdf]]</td><br />
</tr><br />
<tr id="WooWo2001:book" class="entry"><br />
<td>Woolridge, M. and Wooldridge, M.J.</td><br />
<td>An Introduction to Multiagent Systems - Second Edition</td><br />
<td>2001</td><br />
<td>&nbsp;</td><br />
<td>book</td><br />
<td></td><br />
<td>[[Media:WooWoo2001book.pdf|pdf]]</td><br />
</tr><br />
</table></div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8008
PhDSupervision:VolkerStrobel
2018-02-26T23:39:57Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* See how the choice of the stable block (z = 6 currently) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8007
PhDSupervision:VolkerStrobel
2018-02-20T16:52:44Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* See how the mining difficulty influences the experiment<br />
<br />
* See how the choice of the stable block (z = 6 currenlty) influences the experiments<br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=8002
PhDSupervision:VolkerStrobel
2018-02-08T15:46:23Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Collective estimation (estimating the relative frequency of features in an environment)<br />
<br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7997
PhDSupervision:VolkerStrobel
2018-01-25T10:32:36Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* '''Most important next step''': Decentralized consensus (should be easy to implement and a strong advantage of the blockchain approach)<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7991
PhDSupervision:VolkerStrobel
2018-01-17T11:33:51Z
<p>VolkerStrobel: /* Meeting 18/9/2017 */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September<br />
<br />
=== Next Meeting ===<br />
* Added section about open questions<br />
* Wrote tutorial for Eduardo (TODO)<br />
* Completed Proof-of-X paper (TODO)</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7990
PhDSupervision:VolkerStrobel
2018-01-15T14:42:24Z
<p>VolkerStrobel: /* Change in the final version of the AAMAS 2018 paper */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7989
PhDSupervision:VolkerStrobel
2018-01-15T14:37:03Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Overview of alternative consensus algorithms (who uses them, why, what are their features)<br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7988
PhDSupervision:VolkerStrobel
2018-01-15T14:36:24Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
== Change in the final version of the AAMAS 2018 paper ==<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7987
PhDSupervision:VolkerStrobel
2018-01-15T14:03:16Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
* Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
* Transfer system to real robots <br />
<br />
* Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
* Decentralized consensus using the blockchain approach? What happens if we do not stop the experiment but let it run? Please clarify what happens in the case of a Byzantine attack where the simulation is not stopped and is allowed to run. Does it converge? Do we need to know which are Byzantine nodes in order to claim success? Is the effect of Byzantine nodes bounded?<br />
<br />
* Presuming that most people in robotics will not be experts in Blockchain technology, a tutorial approach to using an example with 3 robots to show how the blockchains form and grow in the context of the application will be really useful. I would strongly suggest the authors to have a running example throughout Section 4.3 and 4.4 that clearly shows the difference between the classical consensus and blockchain-based consensus (in the absence of Byzantine robots).<br />
<br />
* A distributed robotic swarm system is usually made of simple agents (in terms of computational, sensing, and communication capabilities) that use wireless communication. In algorithms for such system, one is interested in the computation load, the storage, and the communication burden (size and frequency of transmitting messages). Blockchain as applied to swarm consensus seems to be a distributed database that stores all the communication, and the operations done between every pair of robots. It seems that there is a computation overhead of using Blockchain which the authors have addressed. However, the authors have not clearly explained the storage overhead and the communication overhead. Please elaborate clearly on the storage requirements and the communication message size as a function of time as well as the growth in the number of robots.<br />
<br />
* Unfortunately, the actual process of excluding the Byzantine robots in the tested scenario stays unclear. The last paragraph in Sec. 4.5 is not clear. When, how, and with what reasoning is a robot put on the blacklist? How can you know for sure it is a ‘bad’ robot? Then the 3rd paragraph in Sec. 5.2 reads as if no robot is ever put on the blacklist. In the conclusion you write that Byz. robots can be identified and are excluded from the swarm. This seems contradictory and is just not clear. A clear description of how the excluding process works is not given.<br />
<br />
* Connectivity requirements: It is unclear for how often robots need to stay in contact to make the approach work. You mention outdated blockchains as safety criteria but the actual requirement is unclear. I’m quite sure that for certain scenarios (robot densities in relation to sensor range and robot speed) this approach would just not work; but this is not discussed.<br />
<br />
* Memory requirements: The blockchain grows constantly during runtime. Memory requirements are mentioned as being an issue but without any real discussion. Again, our swarm robots are simple and the memory question is another game-changer for the whole approach. In the conclusion you mention, for example, pruning methods; again, sounds interesting but it is unclear whether that will help to survive the high demand of memory (potentially gigabytes). It would have been interesting to see some measurements from your simulation of how much memory was used.<br />
<br />
* Computational requirements: In swarm robotics we usually have simple robots, such as the e-puck (as mentioned by the authors) but going down all the way to robots, such as the Kilobot. The very idea of the Blockchain relies on computationally complex tasks for the Proof-of-Work-based mining puzzle. An attacker requires 50% of the total network processing power. If I would be fighting 200 Kilobots or 50 e-pucks, it seems that my computational power would not need to be high. What if my attacking robot has a wireless connection to “the cloud” or just some powerful computer? Such an issue is shortly mentioned in the conclusion but should be discussed in detail. This is a very crucial question for the paper: either the approach is a real option or just makes no sense. Also what exactly was the Proof-of-Work-based mining puzzle? The option of physical proof-of-work is very interesting but unclear in the way how it is presented.<br />
<br />
* Sec. 2 “security issues in swarm robotics have been largely ignored” is too strong. You cite Higgins et al. and you miss to cite work of Anders Christensen on fault-tolerant swarm robots, fault-detection, and fault injection.<br />
<br />
* Sec. 3: Please honor Dr Turing with a capital letter: Turing-complete<br />
<br />
* The DC-strategy is not properly introduced.<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7986
PhDSupervision:VolkerStrobel
2018-01-15T13:45:02Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
This section contains an unordered list of ideas, remarks, future research questions etc. <br />
<br />
- Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
- Transfer system to real robots <br />
- Before conducting/setting up experiments, think about the following questions: What question do I want to answer? Which variables do I wand to manipulate? Which outcomes do I expect? Why do I want to conduct this experiment?<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7985
PhDSupervision:VolkerStrobel
2018-01-15T13:24:46Z
<p>VolkerStrobel: /* Open Questions / Future Research Directions */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
- Use range of transmitter as modulation strategy (e.g., stronger signal -> higher confidence)<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7984
PhDSupervision:VolkerStrobel
2018-01-15T13:23:08Z
<p>VolkerStrobel: /* TODO */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== Open Questions / Future Research Directions ==<br />
<br />
<br />
== Lab Responsibilities ==<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7977
PhDSupervision:VolkerStrobel
2017-09-18T12:29:28Z
<p>VolkerStrobel: /* Meeting 18/9/2017 */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7976
PhDSupervision:VolkerStrobel
2017-09-18T12:29:04Z
<p>VolkerStrobel: /* Meeting 18/9/2017 */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* 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)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7975
PhDSupervision:VolkerStrobel
2017-09-18T12:28:37Z
<p>VolkerStrobel: /* Meeting 18/9/2017 */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* Ethereum protocol (geth) can be executed directly on the E-pucks (at least using an older version of geth; I'll check if I can modify newer versions)<br />
* Invented/implemented a new strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7974
PhDSupervision:VolkerStrobel
2017-09-18T12:26:56Z
<p>VolkerStrobel: /* Meeting 18/9/2017 */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* Ethereum protocol (geth) can be executed directly on the E-pucks (at least using an older version of geth; I'll check if I can modify newer versions)<br />
* New strategy for identifying Byzantine robots<br />
* Work from home/holiday?: 25. - 27. September</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7973
PhDSupervision:VolkerStrobel
2017-09-18T12:24:57Z
<p>VolkerStrobel: /* Meeting 14/8/2017 */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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<br />
<br />
=== Meeting 18/9/2017 ===<br />
* Ethereum protocol (geth) can be executed directly on the E-pucks (at least using an older version of geth; I'll check if I can modify newer versions)<br />
* New strategy for identifying Byzantine robots</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7972
PhDSupervision:VolkerStrobel
2017-09-18T12:22:44Z
<p>VolkerStrobel: /* Next Meeting */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Meeting 14/8/2017 ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7971
PhDSupervision:VolkerStrobel
2017-08-14T08:07:41Z
<p>VolkerStrobel: /* Next Meeting */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Next Meeting ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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</div>
VolkerStrobel
https://iridia.ulb.ac.be/w/index.php?title=PhDSupervision:VolkerStrobel&diff=7970
PhDSupervision:VolkerStrobel
2017-08-14T08:05:44Z
<p>VolkerStrobel: /* Next Meeting */</p>
<hr />
<div>[[Category:PhDSupervision_Strobel_Volker]]<br />
<br />
<br />
== General Information ==<br />
<br />
=== Personal ===<br />
<br />
'''Name:''' Volker Strobel<br />
<br />
'''Birthdate:''' 10 November 1987<br />
<br />
'''Belgian mobile phone:''' +32 483 42 21 04<br />
<br />
'''Belgian home adress:''' Av Adolphe Buyl 179, 1050 Ixelles / Bruxelles<br />
<br />
===ULB-related===<br />
<br />
'''PhD started:''' 7 September 2016<br />
<br />
'''Matricule ULB:''' 000443899<br />
<br />
'''Office phone:''' +32-2-650 27 12<br />
<br />
===Projects===<br />
<br />
<br />
<br />
== TODO ==<br />
<br />
* 30/1/2017<br />
** Implement majority voting and voter model in smart contract <br />
** Compare classical approach and secure approach (run experiments)<br />
*** Answer question 1: "What do we get more?"<br />
*** Answer question 2: "What can we do in terms of attacks and robustness?"<br />
** Possible further improvements: use signal strength (range of the transmitter) as modulation strategy<br />
<br />
==== Lab Responsibilities ====<br />
<br />
* IRIDIA server maintenance<br />
<br />
== Tutorials ==<br />
<br />
* [https://www.coursera.org/learn/cryptocurrency/home/welcome Udemy: Ethereum Developer: Build A Decentralised Blockchain App] '''Completed 75 %'''<br />
* [https://www.udemy.com/ethereum-developer/ Coursera: Bitcoin and Cryptocurrency Technologies]<br />
<br />
== Literature ==<br />
<br />
=== [[Volker_Literature|See separate page]] ===<br />
<br />
== FRIA ==<br />
* [https://www.dropbox.com/s/8xvw6slf4adabyi/FRIA_combined.pdf?dl=0 Presentation]<br />
* Ideas for next proposal: [[Volker_Ideas_Proposal | Ideas ]]<br />
<br />
== Meetings ==<br />
<br />
=== Meeting 27/9/2016 ===<br />
<br />
* Continue literature research (read papers mentioned in FRIA proposal)<br />
<br />
* Find out which labs are doing blockchain / cryptocurrency / cryptography research (see [https://docs.google.com/document/d/1fRRGMsFYflg0-2N2KCX6oepoqsssloUAyfD86lpmhkc/edit?usp=sharing Google Docs])<br />
<br />
=== Meeting 4/10/2016 ===<br />
<br />
* Propose literature ([[Volker_Literature|see separate page]])<br />
* 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]<br />
* Practice presentation with Marco, Yasu, Gaetan, and Ken ([[Volker - Comments of Marco, Yasu, Gaetan, and Ken]])<br />
<br />
=== Meeting 18/10/2016 ===<br />
<br />
* French language course Mon 31 October - Fri 4 November?<br />
* iMAL Blockchain symposium & showcase Friday 4 November 2pm - 6pm (0 EUR) -- http://imal.org/en/activity/blockchain-fact-fiction-future/<br />
* iMAL Hacklab Saturday 5 November (30 EUR)<br />
<br />
=== Intermediate Meeting ===<br />
* French language course Mon 31 October - Fri 4 November time: 9am - 1pm<br />
<br />
=== Meeting 15/11/2016 ===<br />
* Continued literature research<br />
* Started first web application for smart contracts ([http://164.15.10.140/ http://164.15.10.140/]) with very basic functionality:<br />
** Robots can be added to the swarm<br />
** Miner can issue a premium in Ether as incentive for removing oil<br />
** Oil can be removed by pressing a button -> sender gets rewarded<br />
* Experimented a bit with ARGoS<br />
* Discussed points during the meeting:<br />
** I need a convincing problem/application that absolutely requires the blockchain (could be very different from the oil spill removal task)<br />
** 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<br />
** 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)<br />
** I can use the footbot simulation for now but will probably use the e-puck in the real experiments<br />
<br />
=== Meeting 22/11/2016 ===<br />
* [[ Application Scenario | Application Scenario ]]<br />
* [[ Proof-of-X | Proof-of-X ]]<br />
* Created simple interface between ARGoS and Ethereum node<br />
* 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<br />
<br />
=== Intermediate Meeting 25/11/2016 ===<br />
* Discussed [[Collective decisions | Collective decisions]]<br />
<br />
=== Meeting 29/11/2016 ===<br />
* Finished Week 1 of Coursera course<br />
* Started ARGoS simulation for the collective decisions scenario (centralized version):<br />
** 10 robots, each robot has an account/address with some ETH<br />
** Robots with id 0 - 3: send opinion red; Robots with id 4 - 9: send opinion green<br />
** If a robot detects a wall or another robot it sends its opinion via the smart contract<br />
** 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<br />
** TODO:<br />
*** Make voting only possible if 1 ETH is send with the transaction<br />
*** Distribute ETH after an epoch is finished<br />
*** Base opinions on sensor inputs<br />
*** Implement strategies for changing opinions (e.g., majority opinion, voter model)<br />
<br />
<br />
=== Meeting 7/12/2016 ===<br />
* Implemented decentralized ARGoS/Ethereum framework<br />
** Each robot is an Ethereum node<br />
** Some are miners (currently, only one is a miner)<br />
** Only robots that are physically close to each other are connected to each other via their Ethereum nodes<br />
* TODO: <br />
** Transfer simple scenario to collective decision scenario<br />
** 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)<br />
* Looked at Davide's code and Master's thesis<br />
* Answer Pedro (Innoviris funding)<br />
<br />
=== Meeting 13/12/2016 ===<br />
<br />
* Prototype of collective decision scenario with Epucks in ARGoS<br />
* Next steps:<br />
** Transfer to cluster (first steps are done)<br />
** Improve voting strategies (e.g., payed voting, direct modulation, ...)<br />
<br />
=== Meeting 19/12/2016 ===<br />
* Transferred framework to cluster<br />
* Conducted some experiments<br />
* Robots are always mining now<br />
* MAJORITY VOTING: black is: 664 white is: 1032 -> Choosing white<br />
<br />
=== Meeting 12/1/2017 ===<br />
* FNRS Aspirant<br />
** Pre-form entry<br />
** Link to application: [https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit?usp=sharing Google Docs]<br />
* Link to Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 24/1/2017 ===<br />
* Continued with Technical report: [https://www.dropbox.com/s/j2wke6be3tv335x/report.pdf?dl=0 PDF (Dropbox)]<br />
<br />
=== Meeting 31/1/2017 ===<br />
* Make scenarios more similar (non-secure approach vs. blockchain approach) - [[comparison]]<br />
<br />
=== Intermediate Meeting ===<br />
* FNRS proposal: https://docs.google.com/document/d/1XCAz8S4f8vP6GFaH4P-HqzD05ecvW35RfA-oB7pcWNM/edit<br />
* FNRS abstract: https://docs.google.com/document/d/1ZQYwFREb8mcoknzqjYp9RLN-nokxLOvKRZiyiSquMUI/edit?usp=sharing<br />
* FNRS publications: https://docs.google.com/document/d/1VgC82EYPeXfKxhLj968vuJPMdjODq_la-8_H-c6yd6g/edit?usp=sharing<br />
* FNRS course details: https://docs.google.com/document/d/1WVSvWKR3uHBk8kDjy_y0ByLj6KAvXdfTo5dYqrKEjgo/edit?usp=sharing<br />
* TODO:<br />
** Upload letter from Jason<br />
** Update workplan; include MIT visit<br />
<br />
=== Meeting 4/4/2017 ===<br />
* Collective decisions<br />
** 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 <br />
** Experiments are running (N: 10 robots, difficulty: 34 % and 48 % black cells, repetitions: 10, strategies: 1-3)<br />
*** Will compare probability of correct outcome and consensus time between the strategies<br />
** Wrote script for running the same experiments as in "Collective Perception of Environmental Features in a Robot Swarm"<br />
*** 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.<br />
<br />
* Rapport d'avancement de recherche<br />
** [https://www.sharelatex.com/project/58b1e917c5ea61d907febafd ShareLaTeX]<br />
** Draft: 11th April (incl. results of current experiments)<br />
<br />
=== Meeting 26/4/2017 ===<br />
* Design and plan experiments<br />
** Why? -> Reasons, goal, hypothesis, what do I expect<br />
** Plan; how much time will it take?<br />
** What data to collect? Which purpose does it serve?<br />
** Attacker model: how can I model bad things that could happen? Do I have to conduct experiments or can I reason about them?<br />
** Clearly describe properties of the experiment, e.g., how many malicious entities<br />
** See PDF on ShareLaTex: [https://www.sharelatex.com/project/58e36527f8f9d78008c03f98]<br />
<br />
* Implemented improvements<br />
** Modified the code to run on multiple nodes with different IP addresses (ssh calls, connect to geth processes of other ip addresses)<br />
*** 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<br />
** 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.)<br />
** 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)<br />
** 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<br />
** Many other small bug fixes<br />
<br />
* Experiments are running<br />
** Started on Sunday but restarted on Thursday when I found some bugs and completed the code for running multiple experiments in parallel<br />
** I have 200 cores on the cluster now<br />
** 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<br />
** Sometimes one of the cluster nodes crashes (hardware failure)<br />
** Also compiled and executed the classical code (for comparison)<br />
** TODO (for tomorrow): Evaluation and continue experiments; for now, I'd focus on Experiment 1 and compare it to the classical ARGoS implementation<br />
<br />
=== Meeting 16/5/2017 ===<br />
* geth will not run on the E-Puck processor; it has a simple dsPIC processor<br />
* Continued with RAR (methods, results, discussion)<br />
* Created slides and prepared presentation for RAR<br />
* 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<br />
<br />
=== Meeting 9/6/2017 ===<br />
* Replicated experiments of classical approach<br />
** found error in the implementation of majority rule: ties always result in opinion 'white'<br />
** different results for voter model and direct comparison (no intersection)<br />
* Implemented Byzantine robots (they don't change their opinion)<br />
** Results with Byzantine robots using the classical approach<br />
** 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)<br />
** 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<br />
<br />
=== Next Meeting ===<br />
* Experiments run ca. 5 times faster now using non-blocking background call, better initialization by preallocating ether and removal of unnecessary code<br />
* RAR draft is pretty complete; I can send a finished draft by tonight (Aug. 3); Experiment 2 (with Byzantine robots is missing)<br />
* 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</div>
VolkerStrobel