目次

• 分散型アプリ
• 失敗を撤回できない仕組み
• バグの無いプログラムは制作可能か？
• バグのないスマートコントラクトは制作が難しい
• ハイブリッドDApps？
• DAppsの魅力
• 完全自己責任世界
• Self-Destruct
• DAppsの論理的な削除
• 論理的な削除の恩恵
• DAppsの開発難易度
• DAppsの開発に安住の地はあるのか？
• DAppsは流行るのか？

分散型アプリ

イーサリアムに代表されるブロックチェーンを使ったプラットフォーム上で実行できる分散型アプリDApps.
スマートコントラクトというプログラムをブロックチェーンに埋め込み実行することで、ブロックチェーン上で動作するアプリを作ることができる。
スマートコントラクト自体は「Solidity」などの専用言語で記述する。

DAppsはブロックチェーンの性質が反映される。
P2Pネットワークで耐障害性があり、データは書き換え困難
運用にはブロックチェーン参加者からの合意形成が必要になる。
ブロックチェーンに埋め込まれたスマートコントラクト自体のバイナリコードも変更ができない。

スマートコントラクトの開発は宇宙開発に例えられる。
つまり「一度打ち上げたらあとはなるようになる」。

失敗を撤回できない仕組み

ブロックチェーンはそのデータ構造とアルゴリズム上、一度登録したデータは変更できない。
スマートコントラクトにバグがあった場合、そのバグのあるプログラムはブロックチェーン上に残ることになる。

バグをフィックスするには新しいスマートコントラクトを登録し、それを使うようにしなければならない。
だがバグのあるプログラム自体は、Self-Destructなどを使うほかは撤回することはできない。
これはバイナリコードがブロックチェーンに束縛されるからだ。

バグの無いプログラムは制作可能か？

努力は出来る。
しかし人間はミスをする生き物なので、100%バグが無いことは保証できない。

テストを書いたとしてもテスト漏れがあればそれがバグの原因になる。
つまり機械的に網羅的にテストしなければならないのだが、現代ではテストは人が書くものだ。
人が書く以上、テスト漏れも100%防ぐことはできない。

バグのないスマートコントラクトは制作が難しい

スマートコントラクトのバグは残ってしまうので、自然にスマートコントラクトのコード自体を減らしてミスも減らすという選択肢になる。
コードを減らしてシンプルなものにすれば、バグが混入する可能性も減らすことができるからである。

しかし、このような傾向はDApps的に言って本末転倒であると言える。
分散型アプリの強みはブロックチェーンの性質が反映されるもので、スマートコントラクトのコードを減らすというのはつまりブロックチェーンのデメリットを減らし、かつメリットも減らすというものになる。

だが現実的に言ってバグの無いスマートコントラクトの制作は難しいわけで、どうしたもんかなーという話である。

ハイブリッドDApps？

スマートコントラクトのコードを減らして、機能をどのように補強するのか。
それは既存の技術である。
クライアントサーバー型のネットワークにサーバーを公開し、JavaScriptなどで書いたフロントエンドなどをデプロイし、そのJavaScriptからスマートコントラクトのAPIを呼び出す。

だがこれはDAppsと言えるのかは疑問符が付くところである。
分散型アプリと言ってるのにこの構成は単一障害点がある。

だがイーサリアムをはじめ多くのプラットフォームはあまり気にしていないようにも見える。
ということは私の認識に間違いがあるのかしら？

DAppsの魅力

分散型アプリの魅力は、非中央集権であることである。
つまり特定の権力者、責任者に依存しない「個」の力と影響が強いアプリを作ることができる。

さらにブロックチェーンを通じてアプリは実行されるので、一度稼働させたらゼロダウンタイム、つまりアプリが落ちることがない。
新しく登録するスマートコントラクトの採用には参加者からの合意形成も必要になる。
つまり、合意をしない人は古いスマートコントラクトを使えばいいことになる。

中央集権がユーザーに使わせるアプリを強制させることができるのに比較して、なんと「個」の力が強いことか。

完全自己責任世界

分散型アプリはその性質上、つまりブロックチェーンの性質だが、利用は完全に自己責任の世界になる。
たとえばバグのあるスマートコントラクトがブロックチェーン上に残っていて、それを知らずにそのスマートコントラクトを使ったとする。
しかしそれによって生じた損害も自己責任である（？）。
（この辺はわからない。アプリ運営者に文句を言う人も出てくると思う）

アプリをリリースしている側は新しいスマートコントラクトを使うようにアナウンスするので、知らんぷりである。

まぁ実際は開発者はSelf-Destructなどでアプリを停止させるはずだ。
しかしそれにバグがあったら停止はできなくなる。

Self-Destruct

イーサリアムのスマートコントラクト（Solidity）などには「Self-Destruct」という仕組みが存在する。
これを使えばブロックチェーンからコントラクトを削除（停止）できる。

だが、スマートコントラクトを登録したときのコントラクトアカウントは残るので送金は行えてしまうらしい。

Introduction to Smart Contracts — Solidity 0.5.4 ドキュメント

コントラクトの削除は理論上は良いアイデアの様に聞こえますが、潜在的に危険をはらんでいます。誰かが削除されたコントラクトにEtherを送り、そのEtherは永遠に失われる様なことが起こり得ます。

というかブロックチェーンなのにアプリを削除できるというのもなんだかなーという感じである。
理屈は、バイトコードは残るがつまりスマートコントラクトの「稼働を停止」させるというのがSelf-Destructだろうか？
それなら一応理屈は通る。

だが、「停止」したスマートコントラクトは「稼働」を続けるわけで、そこにイーサなどのトークンを送ったら行ったきりになるということらしい。
「ブラックホールDApp」じゃないか。

DAppsの論理的な削除

Self-Destructでそう言った問題が起こるというのなら、自然と次のような考えになる。
つまり「停止キーを送信してロジカルにスマートコントラクトを停止させる」というものだ。

if文などを使ってスマートコントラクトのクリティカルな処理部分を無効化するコードを書いておく。
そしてフラグが真になっていたら論理的に処理を中断する。

このスマートコントラクトはブロックチェーン上で稼働は続けるが、論理的に停止させることが出来る。
トークン（仮想通貨）が送信されてきたらエラーを出すようにすればいいわけである。

だがこの実装は以前としてバグの不安が残るものである。
つまり

• 停止キーによるアプリの論理的な停止

• それが失敗したらSelf-Destruct

という二重対策を行う必要が出てくる。
（このアイデアは机上の論理です（たぶん）。試される方は注意してください）

「論理的な削除」はWebではありふれたアプローチだ。
DAppsにもこれを適用できるということになる。

論理的な削除の恩恵

論理的な削除を行うコードを追加する、あるいはSelf-Destructを使うのであれば、スマートコントラクトのバグフィックスが一応可能にはなる。
スマートコントラクトにバグが見つかったら、そのコントラクトに停止キーを送信しSelf-Destruct等を使い論理的に停止させる。
あとはバグをフィックスしたコントラクトをブロックチェーンに新しく登録する。
そしてユーザーにアナウンスする。

このアプローチであれば机上の上では「論理的な停止を行うコード」を念入りにテストすればいいことになる。
論理停止が可能であれば危険なコントラクトを停止できるからだ。

しかしこの論理停止のコードにバグがあった場合は、Self-Destruct頼みになる。
さらにSelf-Destructに関連するコードにバグがあったら停止もできない。
つまり以前としてバグの問題は残る。

そうなのだ、最後の頼みがSelf-Destructであるなら最初からSelf-Destructを実行したほうがいいのだ。
そしてそれにまつわるコードを徹底的にテストする。

おそらくスマートコントラクトにおいては、ビジネスロジックよりも停止ロジックの方が重要になってくる。
なんて言ったってブロックチェーンにバイトコードが残ってしまうのだ。
ああおそろしい。

DAppsの開発難易度

DAppsでは何より大事になってくるのが「テスト」だと予想できる。
テストをしていないDAppをデプロイするのはほぼ自滅行為である。
（これは従来のアプリでも同じ）

いわゆる開発者の黒歴史がブロックチェーン上に永遠と残ることになる。
むかしの中二の痛い黒歴史は、時間と共に薄れて消えてくれる。
しかしブロックチェーンはプラットフォーム、というかノードが稼働している限り永遠と残り続ける。

これはメリットでありデメリットでもある。
ブロックチェーンはなんともおそろしいものに思える。

DAppsの開発に安住の地はあるのか？

私のこれまで調べた範囲ではDAppsはまぁ恐ろしい印象しかない。
興味本位で開発しようと思ったが、調べれば調べるほどデメリットも浮き彫りになってくる。

基本的には多くの人は臆病で、ミスをよくするものだ。
だからテストが必要なのだが、われわれ人間にはDAppsは向いていないようにも思える。

だいたいGUIのテストが難しいのに加えて、スマートコントラクトのテストまで難しいとなったら、しっちゃかめっちゃかである。
興味本位でやったらおそらく痛い目を見るだろう。

しかし開発したい技術的好奇心は残る。
ということはデプロイせずに開発環境でだけ稼働させてみる手もある。

しかし開発がうまくいって、バグもないな～と安心してしまったらきっとデプロイしたくなるだろう。
そしてバグが見つかって肝を冷やすと。

うーん、想像がたやすい。

DAppsは流行るのか？

そのうちスタンダードになる可能性はあるかもしれないが、当分は時間がかかるだろう。
技術的な魅力は多いし「個」の力は強くなるが、「個」の責任も増えてしまう。
つまりトレードオフの関係にある。
これを世界がどのように受け入れるかによる。

従来のアプリはアプリ開発者を信頼して利用するという形態だった。
これがソースコードレベルで透明になり（スマートコントラクトのコードは見ることが出来る）、ユーザーは開発者の代わりにソースコードを信頼する形になる。
トラストレスと呼ばれる新しい形態だ。
その内ソースコードのリーディングが必須の時代が来るだろう。
（だがハイブリッドDAppの場合は不透明な部分も出てくる。これはどうしたものか？）

イーサリアムを筆頭にイーサリアムキラーと呼ばれるプラットフォームも次々と隆盛している。
それらもスマートコントラクトを実装するわけだが、果たしてWeb3.0ではどうなるのか。

分散型アプリが常識になるにはおそらくあと15,6年ぐらい、いやもっとかかるだろう。
その頃にはDAppsの開発の負担も減っているかもしれない。