dAppsを作る難しさと必要性について考える

dAppsという言葉が賑わっていますが、実際にイーサリアムでコントラクトのプログラムを書いてみて思ったことを書きまとめておきます。

コントラクトとdApps

イーサリアムでは独自のプログラムを書いてブロックチェーン上にアップロードし(デプロイと言う)、ETHの送金をトリガーにプログラムを実行するように仕込める。こういったプログラムをイーサリアムでは、スマートコントラクトもしくは単にコントラクトと呼ぶ。

1つのコントラクトは、1つ以上の機能を持つことができ、機能の実行により状態を書き換えブロックチェーン上に保持することができる(以下、オンチェーンで保存すると呼ぶ)。1つ以上のコントラクトの機能を組み合わせて、それらを呼び出すUIを用意すればアプリのようにすることもできる。

ゲームで例を出すとしよう。コントラクトに「ユーザーが敵を攻撃する」という機能があるとする。この機能を実行すると、敵のHPを減らし、もし0になれば経験値を与えるとしよう。これはゲームにありきたりな処理であるが、イーサリアムのコントラクトの場合、実行された結果の状態(この場合は経験値)は、オンチェーンで保存される。

一度、ブロックチェーン上にデプロイされたコントラクトは、最初に書かれたプログラムに従って動き続ける。開発者ですら修正できないし、第三者による改ざんもできない(極めて困難といった方が正確かもしれないが)。また、コントラクトの機能およびプログラムは誰でも見ることができる。(理解するにはプログラミングの知識が必要であるが)

このようなコントラクトによって作られたアプリは、非中央集権的な特性からdApps(Decentralized Apps)と呼ばれる。非中央集権という言葉に惹かれる人々は素晴らしい!と思うかもしれないが、実際にdAppsを作るの難しい。またユーザーにとってdAppsは、どの程度必要性があるものだろうか。

dAppsを作る難しさ

まず最初の難題は、コントラクトの機能を実行するためには、コントラクトのアドレスへETHの送金が必要になることである。つまりお金がかかる。0 ETHで良い場合もあるが(コントラクト次第)、最低でも手数料(GAS)はかかる。さらに送金完了待ち(トランザクション完了待ち)という遅延が発生する。

また、ゲームバランスの調整が難しいという問題も大きいと思う。たとえば、従来のオンラインゲームでは開発運営会社がユーザーのプレイ状況を見て、特定の種族や職業を選択したユーザーが有利になりすぎるようなら、バランスを調整してアップデートするといったことができる。しかし、コントラクトの場合はプログラムの修正ができない。

例えば、支払ったETHに応じてトレーニングで得る経験値が多くなるように、コントラクトにプログラムしてあったとしよう。ユーザーから必要なETHが高すぎるとクレームがあっても、コントラクトのプログラムを修正してバランス調整することはできない。

しかし、このような単純な例なら対処の方法はある。コントラクトに作った本人しか実行できない機能を用意することもできる。機能実行前に送金元のアドレスをチェックし、それが開発者のものでなければ実行しないといった具合にである。

この例では、コントラクトにトレーニングに必要な金額(ETH)を状態として保持しておき、後からその金額を変更できる機能をつけておけばよい。プログラムは変えられないが状態を変えることはできるのだ。これで開発者はいつでもトレーニングの金額を変更できる。

しかし、ゲームバランスを調整するのは、このような単純なケースばかりとは限らない。プログラム自体書き換える必要がある場合もあるだろう。この場合、プログラムが修正不可能という条件でどのように対処すればよいだろうか?

新しいコントラクトを作ることが1つの対処法となるだろう。そしてゲームのUI(ブラウザやアプリ上のプログラム)をアップデートし、新しいコントラクトにアクセスするようにすればよい。しかし、これでも問題がある。一度、ブロックチェーンにデプロイしたコントラクトは修正できないだけでなく消すこともできないのだ。

コントラクトの実行は、そのコントラクトのアドレスを知っていて、そこへ送金すればゲームのUIを介さずとも実行することが可能だ。もし、以前のコントラクトを実行したほうがゲームを有利に運べるのなら、そのようにするユーザーもいるだろう。いわゆるチート行為である。

これに対する対処もないわけではない。コントラクトに機能が実行可能かどうかの状態を持たせておいて、これをON/OFFできる機能を開発者のみが実行できるようにしておけばよい。そして、アップデートのタイミングで古いコントラクトの古い機能をOFFにしてしまえばよい。

しかし、このような仕組みになってしまうと、もはやdAppsとは言えないのではないだろうか?結局、開発者のさじ加減でルール変更が行えてしまい、ブロックチェーンのコントラクトを使っていても中央集権的ではないだろうか?

dAppsである必要性

ゲームにバランス調整やアップデートはつきものであり、そのためにはコントラクトに開発者のみ実行できる機能や、新たなコントラクトへの移行と古いコントラクトを停止する仕組みがあるのであれば、従来のオンラインゲーム同様にユーザーはルール変更がありうることを受け入れざるを得ない。

ゲームを例に話してきたが、広く使われているスマホのアプリのほとんどはdAppsである必要があるものは多くないと思う。TODOアプリで今日のTODOを保存したり、完了にしたり、その都度、ETHを払うのも馬鹿らしいし、自分の予定をオンチェーンで保存する必要もないはずだ。

もちろんdAppsであることに意義があり、革命的なdAppsが出てくる可能性はある。またゲームシステムは従来通り開発元のサーバーで運営するが、ゲームデータをトークンとしてエクスポートして売買できるようにすることは流行るかもしれない。しかし、これはdAppsとは呼ばないだろう。

dAppsとして作るべきものの範囲はそう多くなく、スマホのアプリのような隆盛はdAppsにはないように思うがどうだろうか?そもそもdAppsの定義が何かによるかも知れないが・・・これまでに書いたように開発者のさじ加減でルールが変わるものでも、状態記憶媒体のブロックチェーンは非中央集権で動いているのだから、dAppsだと言うのであればこの限りではない。

※もし認識の間違いなどあればTwitterでRTか返信おねがいします。

仮想通貨投資はZaifのコイン積立だけで十分だと思う理由