DAppsへの理解をアップグレードする（1）：類推思考で誤解を打ち破る

著者：Robert Mao（ArcBlockチーフアーキテクト、CEO）

今月から「分散型アプリケーションへの理解をアップグレードする」という連載を始めます。この連載に合わせて、関連する短い動画も制作し、定期的に配信したり、Clubhouseで議論したりする予定です。この連載は、開発者や専門家だけでなく、ブロックチェーンや分散型アプリケーションに関心を持つ、より幅広い読者を対象としています。短い動画ごとに一つの概念や知識を取り上げ、ArcBlockにおける実際の設計と実装を交えながら、より多くの人に分散型アプリケーション（DApps）の価値を知ってもらい、これらが単なるビジョンではなく、今すぐ利用できる技術と製品であることを理解してもらうことを目指します。

何年も前、インターネットの商用化が始まったばかりの頃、こんな出来事がありました。広告デザインで名の知られたチームが、ある顧客向けにウェブサイトのソリューションを設計しました。そのデザインは非常に洗練され、美しさでは競合を圧倒していました。しかし、一つだけ問題がありました。彼らはHTMLページを単なる画像だと考え、すべてのページを一枚の完成画像としてデザインしていたのです。今日のWebに対する理解からすれば笑い話のようですが、当時はこのようなことが珍しくありませんでした。今、分散型アプリケーションを、インターネットのアーキテクチャに似たものにブロックチェーンやスマートコントラクトを使っただけのものだと捉え、それこそが分散型アプリケーションの姿だと考えるなら、それはウェブページを作ることを、カラー印刷のチラシを大量に作ることと同じだと考えるようなものです。

誤解を打ち破ることも、認識をアップグレードする一環

分散型アプリケーションは、以前から非常に分かりにくい言葉です。その本質を理解するのが容易でないのも不思議ではありません。数年前、私がこの分野に関わり始めた頃も、さまざまな概念に惑わされ、市場にあふれる互いに矛盾した説明を目にしては、自分の知性や長年培ってきたコンピューターサイエンスの知識を疑うことさえありました。初期のDAppsは概念先行だったため、多くの人が混乱し、分散型アプリケーションについてさまざまな誤解が生まれました。過度に崇拝する原理主義者（分散化の度合いが十分かどうかを常に論じる人々など）がいれば、「ファットプロトコル」のようなさまざまな「概念」の難解さもあり、商業的な宣伝を目的とした誇張も数多くありました。この2年ほどは、分散型アプリケーションへの過剰な幻想が失望を招いた結果、今度は反対の極端へ向かっているように見えます。

ここ数年、私たちはArcBlock Platformを開発する中で、DAppsとは何か、何ではないのか、そしてDAppsを実装する利点について、さまざまな観点から数十本の記事を書いてきました。昨年、中信出版集団から刊行された私たちの著書、「ブロックチェーン実践：技術革新からビジネスモデルへ」でも、複数の章を割いてこの問題を詳しく説明しています。

2019年のオンライン講座「分散型アプリケーションの開発設計：焦点を絞った分散型プロダクト思考法を学ぶ」では、主に分散型ID（DID）の観点から分散型アプリケーションを開発する考え方について話しました。まだこの講義をご覧になっていない方は、ぜひ時間を取って視聴することをお勧めします。分散型アプリケーションの開発で最も必要なのは、発想の転換だからです。開発手法、ツール、言語、フレームワーク、さらにはスキルさえ大きく更新する必要はありませんが、設計思想には新しい考え方が必要です。

「中央集権型アプリケーション」と「分散型アプリケーション」を類推する

ArcBlockを理解している方なら、私たちが製品や技術の設計で「第一原理」をよく口にすることをご存じでしょう。しかし、分散型アプリケーションへの理解を深めてもらうとき、私はむしろ「類推」を多く用いる方を好みます。

少し前に、私たちのデザイナーであるCao Wenが、レゴブロックを使ってArcBlockのアーキテクチャ体系を類推し、理解する記事「レゴのおもちゃ店を訪ねて：分散型アプリケーションを開発する興味深い旅」を書きました。類推という観点から私たちのソフトウェアアーキテクチャを読者に分かりやすく説明したもので、多くの好評を得ました。

適切な類推を用いれば、分散型アプリケーションと中央集権型アプリケーションの違いとつながりを容易に理解でき、いくつかの疑問や戸惑いも簡単に解消できます。建築設計であれレゴブロックであれ、類推は理解を助けるために使われます。建築設計と分散型アプリケーションの類推は巨視的な視点に立ち、分散型アプリケーションとは何かを体感しやすくします。一方、レゴブロックから分散型アプリケーションを見る類推は微視的な視点に立ち、細部から中央集権型アプリケーションの構築方法を理解できるようにします。この二つには共通点があります。注意すべきなのは、「類推」という手法は理解を助けるためによく使われるものの、必ずしも厳密ではない場合があることです。そのため、類推を通じて概念を理解した後には、さらに考えを深める必要があります。

画像：ブロックで作った家の模型と実際の家。

ソフトウェア設計者（Software Architect）も建築家も、ともにArchitectです。そこで、住宅建築を例に、建築の観点から分散型ソフトウェアと、今日のインターネット時代によく見られる中央集権型ソフトウェアの違いとつながりを理解してみましょう。

画像の左側にある高層マンションは、多くの人にとって日常的な居住環境としてなじみ深いでしょう。このような住宅は、今日の多くのインターネットサービスをたとえるのに実に適しています。マンション型住宅は中央集権的な特徴を持つ典型的なサービスで、多くの住民が廊下、階段、エレベーター、地上の空間を共有します。多くの場合、住民は建物や土地を実際に所有しておらず、本質的には利用権を「借りている」にすぎません。では、WeChatやWeiboなど、あなたが利用しているさまざまなインターネットサービスを想像してみてください。あなたは何百万人もの他のユーザーとともに、サービス提供者が提供するサービスを「借りて」いるのです。あなたのアカウントは実際にはあなたのものではなく、データもあなたの管理下にはありません。

画像：左 - 香港の集合住宅（Unsplash @jcgellidon）、右 - オーストラリアの現代住宅（Unsplash @rarchitecture_melbourne）

右側では、独立した一戸建て住宅を「分散型アプリケーション」にたとえています。分散型アプリケーションが重視するのはユーザーの自律性です。この一戸建て住宅のように、住民は多くの場合、自分の土地と建物を独立して所有しています。これはまさに「分散型アプリケーション」が重視することです。ユーザーは自律的なIDを持ち、自律的なデータ資産を持つべきなのです。

この類推を念頭に置けば、「分散型アプリケーション」の四つの重要な特徴を理解しやすくなるでしょう。ぜひ理解し、考えてみてください。

上の図になぞらえれば、「分散型アプリケーション」と現在の「中央集権型アプリケーション」の共通点と相違点、そして将来どのようなアプリケーションを持ちたいかを容易に理解できます。ただし、この類推にどのような偏りがあるかも考えてみてください。最も分かりやすい偏りは、左側が密集した集合住宅であるのに対し、右側がより高級な住宅であることです。現実には、豪華なマンションもあれば、手狭な一戸建て住宅もあります。それでも、類推の際にこうした偏りを認識し、表面を越えて本質を見ることができれば、新しい物事の概念を理解するために類推をより効果的に使えます。

「中央集権型アプリケーション」と「分散型アプリケーション」には多くの共通点がある

分散型アプリケーションのすべてが独立しているのでしょうか。この概念は建築にたとえると、とても簡単に理解できます。一戸建て住宅は非常に独立していて分散型ですが、通常は共有の電力網、電話回線、ブロードバンドに接続し、地域の小規模な水道網にもつながっています。さらに、郵便局による郵便物の配達、宅配会社による荷物の配送、警察による治安維持、地方政府による道路や街灯など都市管理に関わるあらゆる業務といった、さまざまな公共サービスも利用します。分散型アプリケーションも、この「分散型」の一戸建て住宅と同じように、大きな独立性と空間を与えてくれますが、だからといって世界から孤立するわけではありません。ここで、私が一貫して主張してきた点を強調しておきます。中央集権化と分散化は絶対的なものでも、対立するものでもありません。

分散型アプリケーションであっても、より使いやすくするために、一部の中央集権型サービスを利用する必要があるかもしれません。たとえば、ドメインネームシステム（DNS）は比較的中央集権的なシステムです。分散型アプリケーションはもちろんドメイン名を使わずに稼働できますし、新しい分散型ドメインネームサービスも登場していますが、一般に広く受け入れられるにはまだほど遠い状況です。同様に、分散型アプリケーションのサーバーも、現在のブロックチェーンでさえも、インターネットから独立して存在しているわけではありません。一戸建て住宅も地面の上に建てる必要があるのと同じで、理想的な一戸建て住宅は、よりよい公共サービスを受けられるよう、常に適切に計画された地域に建てられます。

「分散型アプリケーション」はプライバシー保護と検閲への耐性に優れていますが、「無法地帯」ではないことも容易に理解できます。違法な強制や略奪に抵抗する力をもたらしながら、現代の法治社会のガバナンスの仕組みに従い、さらには民主的な法の支配をよりよく反映するガバナンス手法にもなり得ます。合法性という点では、中央集権型アプリケーションと分散型アプリケーションに大きな違いはありません。

「分散型アプリケーション」は設計と実装がより難しいのか？

類推を使って、自分に問いかけてみてください。30階建ての高層マンションを設計する方が「難しい」のか、それとも2階建ての独立した住宅を設計する方が難しいのか。高層マンションの建設費の方が高く、建築上の要件も厳しいのでしょうか。それとも独立した住宅の費用の方が高く、建築上の要件も厳しいのでしょうか。同時に、同じ面積の住宅なら、高層マンションの一戸と独立した住宅のどちらが高価か、その理由も考えてみてください。

分散型アプリケーションの設計と実装の発想は異なりますが、その概念を理解してしまえば、実際にはとても自然で、中央集権型アプリケーションよりも理解しやすいほどです。なぜなら、私たち人間自身が分散型だからです。世界の人口を一元的に統合・管理する「マザー（Matrix）」システムは存在せず、一人ひとりが世界を知覚することによって、自分自身の世界を築いています。したがって、ある意味では分散型アプリケーションの方がシンプルで直接的です。

ソフトウェアエンジニアリングの観点から見ると、多数のユーザーを抱える中央集権型サービスを設計、開発、運用するコストと難易度は、分散型アプリケーションよりはるかに高い可能性があります。しかし、ユーザーが分散型アプリケーションを利用するコストは、中央集権型サービスを借りるより高くなるかもしれません。

ArcBlockのABT NodeとBlockletのフレームワークは、分散型アプリケーションの設計、開発、運用へのハードルをさらに下げます。実際、将来の分散型アプリケーションの繁栄は、現在のように多数のインターネット大手が支配する状況ではなく、中小規模の開発者、さらには個人開発者の繁栄をもたらすと私たちは考えています。

ユーザーにとって「分散型アプリケーション」のインストールと利用はより難しいのか？

分散型アプリケーションの非常に重要な特徴の一つが「分散型デプロイ」です。分散型デプロイは常に課題でした。前世代の分散型アプリケーション運動では、分散型ソフトウェアにとって最大の課題はインストールでした。過去の分散型ソーシャルソフトウェア運動で最も成功し、影響力を持ったMastodonやDiasporaのようなプロジェクトでも、ドキュメントの導入部分を見れば、それらの分散型アプリケーションのインスタンスをインストールするには、技術マニアやプログラマーであることに加え、非常に強い情熱と、ある程度のネットワークおよびサービス資源が必要だったことが分かります。まさにこの難しさのために、その設計では多くの場合、より多くのユーザーが参加できるよう、熱意ある人々がある集団のために共有インスタンスを構築する必要がありました。

最近人気のあるブロックチェーン関連の分散型アプリケーションの多くは、この重要な問題を解決できていません。ほとんどの分散型ソフトウェアは実際には中央集権的にデプロイされています。たとえばCryptoKittiesやUniswapはスマートコントラクトだけをブロックチェーン上にデプロイし、Webのフロントエンドは依然としてインターネットサービスと同じ方法でデプロイしています。

ArcBlockのABTノードとABTトークンの仕組みは、分散型アプリケーションの王冠を飾る真珠と表現できます。ArcBlockのABTノードが解決する最大の問題は「分散型デプロイ」です。ArcBlockプラットフォームでは、ユーザーはABTトークンで支払うだけで、ABTノードのノードリソースを自動的に取得できます。これらのノードのインストール、デプロイ、起動、管理はすべて自動化されています。ユーザーはNFTを通じて、ノードとサービスの利用権を証明します。今後の動画デモでは、ABTノードの「分散型デプロイ」を簡単に実現する方法を紹介します。これは始まりにすぎません。将来は誰もが利用できるサービスとなり、ますます良くなっていくでしょう。

今日の第1回では、分散型ソフトウェアやサービスとは何か、中央集権型サービスとどう違うのかを考え、分散型アプリケーションにまつわる誤解を打ち破るための思考法を提示しました。これらを明確に理解したうえで、一歩ずつ先へ進み、ArcBlockプラットフォームによって開発者がすでに何を実現できるのかを見ていきましょう。すべては始まったばかりであり、多くのことが想像を超えるかもしれません。なぜなら、分散型ソフトウェアの設計思考そのものが、認識のアップグレードだからです。