A. Overview

I had my first hackathon on July 14–15th, 2018 as a part of a team named Teckle. Apart from how much fun I had with the team, I thought it was a great experience for me to work with competent developers. I believe a success of an organization depends on how tasks are assigned and how each member fulfills those task. The most important challenge of all is to ensure that everyone is minding their own business and doing what they are good at, yet the team, as a whole, is working towards the same goal. I think I had just that experience during the hackathon which made me feel like I can implement this again later.

B. What we built

I am very interested in building a decentralized community where people interact with each other based on mutual interest. The activity itself can be anything as long a group agree on a certain rule. The rule is very important because it provides a mission. Whether one fulfilled this mission or not can determines his or her contribution to the network. As long as contribution can be proven, it can be measured. And the measurement can serve as the record of one’s value within that community. Even further, I believe this value within a community can be considered outside the community. The most primitive form of this example is reputation in social network such as Facebook Like button. However, I want more formal and reliable system that can measure one’s effort and is fungible throughout the different networks.

C. Personal shortcoming

I am very sorry to my team mates because I think I showed some lack of competency during the competition. I think there are a lot of things to improve for the next time.

  1. Presentation Skill:
    My roles during hackathon were the main ideation planner, script writer, and the main presenter. In other words, I needed to understand what we are trying to make and explain that to other people. I do not think I did a great job. The most critical mistake made was that I did not make a thorough slides for presentation. I thought that I will be okay with pictures from the page design slides as long as I have a good script. However, I often forgot where I was going. I needed some text to refer me back to what I was saying.
  2. Technical understanding:
    When I studied blockchain, I had a goal to communicate technical concepts with others who know more about it than I do. I thought that I reached some conceptual level of understanding where I can converse technical terms at least on conceptual level.
    During the hackathon, this thought turned out to be naive. It seems that I had been blessed to meet good people who could explain very difficult concept in simple terminology. They were able to explain so well that it made me feel that I am good at understanding. In short, it is not because I was able to understand; people made me understand it.
    I am studying the code and I cannot understand how it operates. If I do not understand this myself, how would I be able to explain it to others?

D. Questions From Panels

During our final presentation, there were three questions asked from panels. They were all very good questions and gave me a lot of thoughts.

  1. Why decentralized?
    The second question was about why this service needs to be developed on top of decentralized ENS. There are two reasons for decentralization.
    a. Community based participation: Anyone can participate and anyone can motivate. It is not within our intention to control people’s activity.
    b. Victory as honor: If Conquest control the allocation of Victory, there is no difference between Victory and Facebook Like. The purpose of Victory is to ensure credibility. This requires decentralization.
  2. How does one picture a day become a proof?
    The third question was about validation. Namely, how can a picture prove that one actually worked out? Even if one fulfills the task, there are ways to tamper the proof. For instance, one might take one picture on the same day and post it over and over again. There are validators who verify the picture but would it be sufficient to prove the authenticity?
    To generalize the question, it touches on the problem of decentralized Oracle. Namely, whether off-chain data, a picture of workout, can be validated on-chain. I stated a few models that are addressing this issue including Augur, Gnosis, Aragon, and Kleros. However, it is not yet apparent whether those models can be directly applied for our purpose. P2P validation system in Conquest requires much more research.

E. Further Questions

There are additional questions that should be addressed.

  1. Victory issuance system:
    For an ICO, Token economics is there to ensure whether incentive aligns with the system and the price of token. Victory, as honor system, require something akin to this to ensure scarcity, time-effort relations, utility, and psychological value that affects the supply-and-demand. However, at the moment, there is no limitation to Victory issuance without enough consideration on the fair value.
    There is one interesting aspect we added to incentivize people to cooperate. That is, each person receive more Victory if more people reach the finish line. For instance, one person receive 10 Victory if he or she is the only winner whereas each person receive 20 Victory if there are two winners. I think the general idea is okay but there need to be more research on the proportion based to consider inflation.
  2. Coercion attack:
    People may try to form a group and receive Victory by constantly doing the same thing. Some of it would be outright invalid but others may be more tricky. For instance, a group of friends who are native Chinese speaker may open Chinese 101 class repeatedly just to receive Victory. This is tricky because it is not outright immoral but only sounds a bit like cheating.
    I think some of this problem can be addressed systematically. For instance, if Victory level can store data involving one’s skill set and track one’s record of completion, it is possible to determine whether the person is pushing himself harder or is just doing things repetitiously. From this, it is possible to determine how much Victory should be issued based on time-effort metrics. However, it is still a question for those who have no initial data in the system.

F. Conclusion

Hackathon was very exhausting. To stay up all night and finish the project on time was not easy. However, I had such a great time. I truly thank my team and the team who organized this event for this great experience.

커뮤니티를 만들고 운영합니다