NoahOrblog

某・福島にある大学のコンピュータ理工学部の大学生のお話。

平成最後のハッカソンに参加してきた

Noahです。

平成最後の日、CAの平成最後のハッカソンというものに後輩と同期と出てきたのでそのおはなしです。

詳細は下をチェケラ

www.cyberagent.co.jp

参加するに至るまで

最初は参加するつもりはなく、参加するといっていた同期や後輩の応援団になろうとしていたのですが、僕の友人の id:flying_hato_bus に、募集締切の一週間前くらいに誘われたので参加しました。

自分は以前からブロックチェーンないしは分散システムに対して興味を持っていたので、せっかくならそれをうまく応用したものを作りたいなと、そのころから密かに思ってました

準備期間 (4/19~4/29)

今回のハッカソンには、十日間ほどの準備期間がありました。自分は現在、東京で 出稼ぎ お仕事をしていたので、テーマ発表兼準備期間の初日の19日(金)に急遽会津へ戻り、土日で作るモノの話し合いを id:yt8492, id:flying_hato_bus とともに行い、画面設計などをしてあとは開発するだけ、というところまで持ち込みました。

実際に作ったものは、ざっくばらんに言えば 黒歴史を永久保存させるSNS です。

f:id:NoahOrberg:20190509184836p:plain
某有名アニメ風ですね

大体どんなものかというと、モバイルアプリでユーザとURLを指定すると、そのユーザの黒歴史としてそのURLを永久保存させるか否かの投票が始まります。(なお実はこの時点でWeb魚拓サービスで魚拓を取ります(悪質))

一定の数の承認を得ると、そのURLの示すページは 黒歴史としてバックで動くブロックチェーンノードに永久不滅の形で残るという恐ろしいものです。

id:yt8492, id:flying_hato_bus はふたりともよく鳥さんのマークのSNSで話すことが多かったので互いの技術セットをよく把握しており、作る箇所もそれぞれの得意分野を選定できました。

f:id:NoahOrberg:20190509185238j:plain
画面の仕様を練る練る

みんなの担当箇所

id:yt8492
id:flying_hato_bus
id:NoahOrberg (自分)

それぞれの開発ですが、自分以外の箇所はおそらく彼ら自身のエントリを読んだほうがいいと思います。

自分(id:NoahOrberg)の範囲でいうと、主に基幹となるブロックチェーンの開発が主で、モバイルとの接続APIは主にid:flying_hato_busに書いてもらい、モバイルと接続する際のデバッグや認証部分などをお手伝い程度に(ゴリッと)書きました。

自分は以前、別のハッカソンで、Proof of Stakeをもとにした合意形成アルゴリズムブロックチェーンを1から実装したことがありましたが、RedisのPub/Subでノード間通信を行ったり今考えるとひどい実装だったので、今回はちゃんとgRPCで相互通信させて実装しました。

今回はProof of Workをもとにした合意形成アルゴリズムを勝手に作り(その場のテンションで考えたので妥当性はともかくとして)、それの実装をしています。

就業後に実装をしていたのですが、初日にほぼほぼ案を固めていたおかげか、アイデア由来で躓くことはなかったです。

躓いたところといえば、タイムラグ関係で少しだけ躓きました。

全ノードに通信する箇所があるのですが、そこを愚直にforで回していたところタイムラグによってうまく合意形成されなかったので、goroutineを使う際によくやる手法ではありますが、goroutineで全ノード用に一気に処理をさせるためにchannelをwaitさせ、すべてのgoroutineが送信だけになったところでmain側でchannelをcloseすることによってほぼ同時にリクエストを投げるようにしたことくらいです。

タイムラグの発生によってうまく合意形成されないのは割と問題でした。

今回PoWがベースなのでひたすらノードに計算をさせるのですが、計算間隔を1msec以下で、検証用にハッシュ計算の難易度を比較的易しめにしたところ、合意形成がバッティングしてうまく合意形成ができなく、かといって(あまり練られてないので)難易度の調整も難しく、仕方なく各ノードのハッシュ計算の間隔を100msecごとにしているなど、妥協点もあります。以前PoSをベースに書いていた時はdiffパラメータを変えることで合意形成のハッシュ計算成功の割合を柔軟に変化できていたのですが、PoWはそうはいかず、色々な手段を右往左往していました。

あとは、Goを普段書いているはずなのに並列処理に関してあまり知見がなかったため、race conditionを引き起こすこともありました。

ひとつのcontrollerで行う処理が多いため、mutexをcontroller単位でかけると時間差によって処理がハングするところがあったので、(正攻法かはわかりませんが)問題ない程度の単位処理ごとにロックを小分けにしてやることでmutexのロックの時間を短くするなど、時間差ファーストに処理を書いたりしています。

今回は、「とりあえず、正常に動かす」という信念があったので、正攻法かどうかを考えるのは、とりあえず考えついた方法を動かして正常に動くところをみてから、という方針で書きました。最近はアルバイトのコードばかり書いているので特に何も考えずに好きなように実装をできたのがすごく楽しかったです。

開発環境にも少しだけ凝って、†最強†のMakefileを書きましたが、今思えばたいしたことなかったです。(スライドに思いっきり†最強†と書いてしまっていた)

ちなみにリポジトリはこちらです。上がサーバー兼ブロックチェーン、下が後輩の仕上げたAndroidアプリです。

github.com

github.com

当日 (4/30)

当日です。発表では他のチームの圧倒的技術力に圧倒されました。やはりインパクトというのは大事ですね。

自分はあまりWebフロントに明るくないですが、すごいWebアプリケーションばかりでした。もちろんハードをつかったものも。個人的に、かわいい女の子に目隠しされる作品がすごく好きでした。

ちなみに、僕は発表終了後にプレゼン用に壇上に置いてあった人事の方のPCを自分のと勘違いしてケーブル引っこ抜いて持ち帰ろうとしたのですが、これも見事に自分の開発したモノに黒歴史として刻まれました。

さいごに

参加チームが20チーム以上あり、とても大規模なハッカソンでした。自分は今まであまりハッカソンには参加していなかったのですが、とても良い刺激になりました。

関係された皆様、ありがとうございました。