この記事では2019年2月21に開催されたブロックチェーンイベントblockchain.tokyoのイベントレポート概要です。
本イベントでは、DMMのブロックチェーン研究室が開発しているDapps「Quest」についてデザイン・開発の観点から様々なお話がありました。
DMM ブロックチェーン研究室とは
DMM社内においてブロックチェーンに関するR&Dを行う部署です。
社内外と連携した企画・研究開発や、既存のユーザー体験の分析を行っており、ステークホルダーに捉われず自由なR&Dができる環境にあるようです。
メンバーは大きく8人+インターン生で、ブロックチェーンのエバンジェリストとして著名な加嵜さん・篠原さんをはじめ知見のあるメンバーが揃っています。
お二人はブロックチェーン開発に従事する開発者であれば誰もが読んだことのある『ブロックチェーンアプリケーション開発の教科書』の著者でもあります。
created by Rinker
¥3,300 (2024/04/26 07:46:33時点 Amazon調べ-詳細)
そのようなDMMが開発しているDapps「Quest」を含めて、今回のイベントでは
- ブロックチェーンアプリケーションのUIUX的視点について、デザインストラテジスト・河西さんから
- Questのコントラクトの開発の際の苦労点や体験談について・田中さんから
- Web3.jsとrimble-uiについて、平野さんから
お話していただいた上で、さらに（DEX）分散型取引所AirswapのCo-FounderであるDon Mosites氏も登壇し、長丁場のイベントになりました。
本記事ではQuestの開発の際の話を中心に、主にデザインとコントラクト開発の体験談をまとめていきます。
Questとは？
イベントではまずは河西さんからQuestの内容についての説明がありました。
これは学習行動へのインセンティブ設計で学びの輪を活性化させることを目的として、クリプトの報酬がもらえるように設計されたイベント運用プラットフォームです。
アウトプットや言語化に対して消極的なゲストが積極的に質問する外発的な動機を得ることができるようになるのではないか、との見立てで開発され、実際にアプリケーションレイヤーのユーザーテストを重ねて誕生しました。
実際に2018年11月に開催されたHi-Conというイベントでは300人を相手にユーザーテストをした経験もあります。
Questの機能
機能としてはアプリがイベントごとにイベントの運営者「ホスト」が「ルーム」という部屋を質問を投稿できるようになっており、その中で良い質問をして質問がイベント運営者に採用されたゲストは仮想通貨（暗号資産）で報酬を得ることができる、というものです。
現在α版がリリースされていて、使用の際には一人当たりに提供する通貨の量やイベントのタイトルを指定することが可能です。
開発環境としては、メインネットとテストネット両方で開発を進めており、現在の対応通貨はイーサリアムのみであるものの、今後より多くの通貨が使えるようになる見通し、とのことです。
報酬に使われるイーサリアムはホストがあらかじめ預託しておくほかにも、ゲストによる投げ銭でもプール可能なようです。ですのでイベント運営者に応援の意味で投げ銭したい場合には、ルームのアドレスに送金する形で投げ銭を行うことが可能です。
Questで実現したいこと
河西さんによれば、このQuestによって学習コミュニティーの価値＝個人学習や組織内学習の制約を超えてインプットやアウトプットを研鑽する場の価値を上げていきたい、と考えているようです。
アンダーマイニング効果をはじめとするバッドUXを避けつつ、これまで学習コミュニティーが抱えていたインセンティブの不透明さや立地条件や会場のキャパシティの問題、学習の機会の地域別格差など同じ学習内容でも地域ではその継続維持が難しい問題をブロックチェーンで解決できるのではないか、とのことでした。
DappsにおけるUIUXを考える
ここで河西さんが指摘したのはDappsにおけるUIUXはどうあるべきか、という問題についてです。
「そのアプリは本当にブロックチェーンであるべきなのか？ユーザーが本当に望んでいるものは何か？」と言った課題がブロックチェーンにはありますし、ユーザー視点、ビジネス視点、プロダクト視点、など様々な観点からプロダクトを見た上で、適切なUIUXの設計を行っていくべきだろう、とのことでした。
UXといってもハニカム構造をはじめ、様々な概念があるわけですが、「ブロックチェーンではどの問題が解決できて、アプリケーションレイヤーだとここしか解決できない」と言ったレイヤーごとの問題のボトルネックの特定が必要で、UIUXの議論をアプリケーションやサービスのレイヤーで閉じてはいけない、とのことでした。
例えばブロックチェーンのレイヤーの問題としてはガスコスト、技術的安全性、使いにくさ、などが挙げられますし、DMMではこれらに対して行動経済学や認知心理学と言った様々な実査を行っているとのことでした。
そして河西さんはその中でも特にFat Protocolの重要性についても挙げていました。
Fat protocolは仮想通貨・ブロックチェーンのビジネスモデルを考える理論であり、本ブログではFat Protocolの解説記事を公開しておりますので、よろしければぜひお読みください。
当日の河西さんの資料はこちらから閲覧できます。
Questのコントラクト開発について
次にブロックチェーン研究室 テクノロジー本部の田中さんからQuestのコントラクト開発について、大きく
- コントラクト設計、開発環境
- コントラクトのテスト、セキュリティ
- 工夫した点、苦労した点
についてお話いただきました。
PoCとしてのQuest
Questはは初めて作るDappだったため、DMMとしてはPoC（概念実証）の色合いが強く、マネタイズというより世の中になかったものを出してみてユーザーのリアクションを確かめたり、UX/技術上の課題を実際に形にすることで洗いだす目的があったようです。
他にもインセンティブ設計、承認欲求をどう満たすのか、ウォレットブラウザによる参入障壁でユーザはどう増えるのか、ガスコスト、ブロック間隔、ファイナリティやセキュリティと言った問題はPoCを行わなければ見えてこない課題でしょう。
設計方針
Questの設計方針として、ガスコストとトランザクションの待機時間を最低限にするため、
- 状態変数への書き込み頻度を最低限にする
- コントラクトに持たせる必要のないデータは分散性とトレードにはなるがDBに置く。
- ゲスト（質問投稿者）にはガスを使わせないために、セキュリティの面からはPull型の方が良いとされる送金に関してPush型を採用
しています。とはいってもセキュリティリスクを低減するため、コントラクトは比較的シンプルにすることを心がけたようです。
今回はFacroty Patternを使って開発されていました。
ルームを作るためだけのRoomfactory Contractを作ってあって、この中にRoom関数があり、これをホストがCreateRoom関数を叩くことで実行できる、という形です。
田中さんがインポート文を実際にデモで見せてくださいましたが、実際にルームのコントラクトをインポートして、CreateRoom()の中でコンストラクタが呼ばれるようになっていました。あとはデータベースの方で格納したい情報を引数として持たせ、バックエンドでそれをキャッチさせるだけで、非常にシンプルなコントラクトだなと感じました。
コントラクト開発環境
開発環境としてもブロックチェーンの開発のオーソドックスなものを一通り使用したことが伺えました。
使用した環境は以下の通りだったようです。
- Truffle Framework。test/build/migrationが一気通貫でできてやりやすいため。
- OpenZeppelin-Solidity。セキュアにコントラクトを書くため。
- 初期ではGanache GUIでガシガシデプロイ。
- 一方でGanacheは厳密にはブロックチェーンではないため、GethのプライベートネットとRopstenのテストネットも適宜利用。
- 今回はJavascriptで記述したものの、可読性を高めるためにノードのモジュールを入れた。
Chai,chai-bignumberなども利用されていたようです。
またホワイトボックステストの時にSolidity-coberageを出すようにしたようです。そのまま使うよりも作業効率を上げるためnpm scripts に実行コマンドを定義して、実行するとHTMLで結果を出力できるようにしたそうです。
チェックツール
また静的解析ツールとしてMythril Classic,Oyente,Securityなどを一通り利用し、動的解析のツールも利用したようです。
これらはいずれもConsensysのサイトで読めるとのことです。
さらにセキュリティを高めるための監査(security audit)も外部に委託したとのことでした。
工夫した点・苦労した点
最後に田中さんが開発中に工夫した点として、Truffleでログが残らないのが不便だったのでmigrateすることで、自動でログを残せるようにした点を挙げていました。逆にWeb3.js のバージョンについては、0系なのにフロントエンドでの実装は1.0.0系だったために苦労したとのことですが、現在Truffle ver5で解消されたようです。
他にもWeb3.js 1.0系は送金できないバグがあったりして未だ不安定だったりするようです。
田中さんの話をまとめると
- PoCプロダクト：Dapps Quest
- コントラクトに持たせるデータは最小限にするコントラクト設計
- エコシステムを駆使したコントラクト開発環境
- 可読性を高めるコントラクトのテストとカバレッジの一方、最大限にセキュリティも高めている
ということになりそうです。
田中さんの当日の資料はこちらから見ることができます。
今回はblockchaintokyoで発表されたDMMのDapps「Quest」について、UIUX的観点や開発時の経験がシェアされた有意義なイベントとなりました。
なおDMM ブロックチェーン研究室は先日新しく本を出版しています。
デザインにすごくこだわっていてとても挿絵のイラストや図解が豊富なため実用書特有の堅苦しさはありませんし、ブロックチェーンの初歩からスマートコントラクト開発の実用的な部分まで広くカバーしているので、これからブロックチェーン(特にイーサリアム）の開発を検討している方はぜひ1人一冊持っておくと良いのではないでしょうか？
この文章がよかったと思った方はぜひ下のボタンからSNSでシェアしてくれると嬉しいです！
