This semester's Challenge Task (CT) is to implement either (a) a Decentralized Application (DApp) deployed on the Ethereum Blockchain (BC) or (b) a solution prototype that implements a convincing use-case that leverages the BC’s immutability in a different BC or Distributed Ledger (e.g., Bitcoin, Corda, or NEO). The selection and definition of the use-case depends on the group. The application domain can range from gambling systems, file transfer applications, supply-chain of products, or any decentralized system. The groups shall inform the teaching assistants on the topic and discuss the feasibility of the proposal. One can check past CTs (e.g., Challenge Task 2018, Challenge Task 2019, and Challenge Task 202) to have an idea about examples of applications.
Even though the groups are free to choose the CT focus, either (a) or (b), and the solution to be implemented, all groups must ensure that all requirements are met and follow the defined deadlines. The necessary information to fully accomplish the CT, assumptions, libraries, tools, and impact on the grade are detailed in the next sections and on the CT Formal Description (PDF, 168 KB).
Each CT group is free to decide on the design of the DApp or solution. For example, the architectural decision on how the communication with the BC or Smart Contracts (SC) will be performed. However, for each CT group, the following key requirements need to be met:
- In case of (a), the core functionality must be implemented and executed entirely within SCs. In the case of (b), the core functionalilty of the prototype should be implemented directly interacting with the selected BC via transactions (e.g., creating, signing, and sending transactions) or within the SC in the selected BC.
- The solution must include an economic aspect, e.g., a payment system, gambling, or any other economical incentives.
- The user must be able to interact with the solution via a Graphical User Interface (GUI), for example, a Web-based Single Page Application (SPA).
- The group must deliver a self-contained report documenting the solution, its operation, stakeholders (i.e., actors), and the source code following the Lecture Notes in Computer Science (LNCS) template provide here and as Word Document, LaTeX, or Overleaf Template template. Additionaly, in order to meet this requirement, each student of the group should have handed-in at least 2/3 of the exercises.
Further suggestions include:
- The solution may use existing libraries and code, but those must be allowed to be published under APL or another comparable open software license.
- The final report shall document the application, and its operation, mainly with all the details needed to understand the solution to be shown at the presentation and demo time slot. The report should contain approximately 5-10 pages, and be written in a coherent, scientific and technically accurate manner.
- The source code must be well documented and contain installation guidelines.
The following facts may be assumed:
- The SC can be deployed in a private testnet or in a public testnet (e.g., Ropsten testnet)
- You can use just one node (Ganache, Parity or Geth client) with multiple addresses.
- The use of the testnets provided by the BCs is encouraged.
Note: Further assumptions, which are not restricting these assumptions above, can be made according to each group's approach.
The items below represent supporting libraries, tools, or references that are recommended to be taken into consideration.
- Ethereum is the most popular public blockchain for SC. Supervisors are familiar with geth. Also, Ganache (https://truffleframework.com/ganache) can be used to simulate a private Ethereum blockchain.
- A tutorial to start developing in Solidity, some examples of SCs, as well as instruction to set up a private testnet and previous CTs can be found at https://gitlab.ifi.uzh.ch/scheid/bcoln
- The Solidity documentation can be found at https://solidity.readthedocs.io/en/develop/
- The documentation for the Web3 Python library can be found at https://web3py.readthedocs.io/en/stable/
- A compilation of material and information about Ethereum and Solidity can be found at https://github.com/willitscale/learning-solidity
- The groups shall be balanced in expertise and work-wise. Every group shall have at least one development expert. During the CT, the group shall meet every week during exercise hours to work on the task and discuss the next steps.
- The groups shall utilize their homework times to work on the CT, besides the exercise time slots assigned on Thursdays.
- The groups shall determine and set-up an internal project plan with the overall milestones, responsibilities, and timings provided therein.
- Distribute the workload so that each group member gets a fair load of work (a fair P2P load balancing, no free-riding!) and make sure activities can run in parallel (non-blocking).
- You can create groups in MS Teams in order to organize the tasks and meetings.
- Do not miss the opportunity of discussing details with your group‘s supervisor; he/she might give you useful hints.
- A midterm meeting/presentation to the supervisors is expected from the group in order to update them with the development of the application.
During the challenge task each group will be able to ask questions and get support from their supervisors:
The groups that not discussed or sent their topics to the teaching assistants are encouraged to contact them as soon as possible.
Prasun Saurabh, Anja Koller, Ali Yassine, Faisal Alsayed
|4||Voting Web App|
|4||Trash Collection and Reward System using RFID|
Ettore Tancredi Galante, Pietro Bonazzi, Can Inan, Junwoo Hwang
|4||Yeld Farming DApp|
Mike Suter, Julius Willems, Nicolas Purpura, Kevin Streiter
|4||"Death Node" - Retrieving Lost Funds with SCs|
Michael Nadig, Christian Birchler, Sandro Padovan, Fabian Künzler
|4||SC-based Derivative Trading Platform|
Md Rezuanul Haque, Lauri Tahvanainen, Ronin Chellakudam, Martin Frick
A Generic and Decentralized Betting System
Amadeo Charlé, Steven Näf, Severin Kunz, Yuchen Zhang
|4||Incentivicing Social Behavior: P2P Donations with the Help of Social Experiment|
Michèle Fundneider, Rinor Sefa, Leo Rutschmann, Lorenzo Spoleti
|4||Star Onwership as a NFTs|
Kyra Goud, Timo Schenk, Özgür Güle, Lukas Vollenweider
|4||SC-based Fully Transparent Poll Application|
Daniela Gianora, Tianshuai Lu, Shaoyan Li, Madhav Sachdeva, Abdlrahman Essa
|5||Decentralized Donation Platform|
Dario Akhavan Safa, Jonas Brunner, Tobias Boner, Christian Omlin, Bulin Shaqiri
|5||SC-based Classic Roulette Game (RouDapp)|
Challenge Task (CT) presentations and demonstrations will take place on Thursday 20.05.2021 and Thursday 27.05.2021 from 14:00 to 15:45 hours. On these dates, the groups will present and demonstrate their results, which will be evaluated by the class. Presentations and demos on these two dates will take place in Webex.
- Each group will have ~15 minutes to present their design, and to demonstrate the working application (roughly 5 min presentation, 5 min demo, and 5 min for questions). The presentation shall include slides introducing and motivating the demo. For the demonstration, the group must run one (or more) use-cases of your application, showing that it meets the defined requirements and successfully implements the proposal. The presentation will be performed via screen-sharing. Thus, one person of the group will need to share their screen and present the presentation and or the demo. Note that it is expected that everybody contribute towards the presentation and demo in a organized fashion.
- Make sure that everything will work for your demo! Test everything beforehand with given conditions, especially the blockchain/mining. If a group fails to present within its time window, it will be disqualified.
- Remember that the audience will not only be interested in seeing whether or not your solution works, but more specifically, how the designed mechanisms (e.g., SC communication, random number generation, BC interaction, and so on) for your solution work behind the scenes.
- After the presentations, each group will be evaluated by all of the other groups. The evaluation will work in a decentralized and democratic manner as follows: each group will rank the presentation and solution of other groups. The CSG members as a group will also rank the presentations, which will serve as a tiebreaker in case that no consensus is reached from the group's ranking. The following criteria should be taken into consideration to rank the groups: software design and implementation (overall design, and usability), teamwork, presentation, and demonstration of the solution. Each position in the ranking awards a defined amount of points, which will be summed up for each group. For example, the 1st position in the ranking receives n points while the n position receives 1 point, where n is equal to the number of groups minus one. It should be noted that the group does not rank itself. The results of the ranking will be collected and disclosed after the last presentation. The winning group (i.e., the one who sums more points) will receive a prize and the "BCOLN Challenge Champion 2021" award.
- Each group shall hand-in by e-mail (scheid at ifi.uzh.ch and killer at ifi.uzh.ch) the report and source-code of the solution until 20.05.2021 - 23:58
The CT grade will impact in the final written exam grade in the following manner:
Fulfilment of the Requirements
Requirement / Group
✅ = Fulfilled ❎ = Not Fulfilled
🏆 Winner CSG-award: TBD
Please find the report and source code of each group for download at TBD. Source code is licensed under open source license. In case of questions, please contact the respective supervisor.