Original Article : Avoiding blockchain for blockchain’s sake: Three real use case criteria
Posted on July 24, 2017 by antonylewis2015
＊この記事はbitsonblocks.netより許可を頂き日本語に翻訳してご案内しております。
2016年は、ビジネス上の問題を解決するのに、ブロックチェーン・ベースのソリューションが適しているかどうかを判断するための枠組みとフィルターを作る年だったといえます。ところがしばしば、ブロックチェーン化が成熟したとして、不適切にユースケースの可能性を主張する枠組みがあったのも確かです。なぜならこうした枠組みをデザインしているのが、可能な限りブロックチェーンを普及させようとしている、当のブロックチェーン・ベンダーやコンサルタントであることが多いからです。しかしながら、2016-17年に作られたコンセプト証明の多くが、産業的なソリューションになっていない。それはなぜなのでしょう？
主な理由はふたつあります：
- テクノロジーがユースケースの要件を満たしていない
- ユースケース自体が誤って選択された
本記事では、ユースケースの選択について何が過ちだったかを説明し、新たにこうした選択に関する2つのより良い問いを提案します。
2016年：ユースケース選択の誤り
2016年にブロックチェーン・ユースケースの可能性を特定するために用いられた一般的な問いが以下です。
しかし、これらはお粗末な選択基準であり、しばしばビットコインのブロックチェーンおよびネットワークのプロパティを大まかに見て、他のビジネスシナリオに誤って適用されていました。 たとえば……
たくさんの参加者がいますか？
ビットコインのブロックチェーンには、ノードと呼ばれる約5,000人のバリデーターとブロックを作成する10〜15人のマイナーが参加しています。ビットコイン・ネットワークは、それを管理する実体を持たないようにデザインされているから分散化型なのです。しかし、当事者が特定・認知されている業界の分散型台帳では、数多くのバリデーターを必要としません。2名の参加者間で分散型台帳があれば、効率性はすぐに作り出すことができます。分散型台帳がものごとを改善するためには、多くの参加者が必要だというわけではないのです。
データ共有はありますか？
これについては記事「分散型台帳：データ共有ではなく共有コントロール」にて書きました。 データ共有は解決済みの問題です。ウェブポータルを使用すればよいのです。
データ「検証」の必要がありますか？
ビットコインで検証は狭義に定義されています。つまり、デジタル署名を数学的に検証し、使用されたビットコインがそれまでに使用されていないことを検証することを意味します。ビットコインは「真実」を検証することも、合法性や道徳性を検証することもありません。それに学術研究の結果も（学術研究が結論を不正に導き出していないことをマイナーが検証するという、ブロックチェーン・ユースケースのプロポーザルを見たことが私も確かにありますが、何をか言わんや、です）。
コントラクトはありますか？
人びとに魔法の存在を信じさせる「スマートコントラクト」という言葉を、イーサリアムが普及させました。が、残念ながら、自律実行型の魔法の契約は、ハリー・ポッターの世界にしか存在しません。ビジネスネットワークにおける契約の存在は、直ちにブロックチェーンまたは分散型台帳が適していることを意味するものではないのです。
その他
他にも多くのフィルターや枠組みが適用されていますが、それらの多くは有用ではありません。
2017：それではどうする？
では、このテクノロジーについてどのように考えるべきなのでしょう？ 「ブロックチェーン」や「分散型台帳テクノロジー・DLT」について、いつ考えはじめたらいいのでしょう？ これらの問題は、（共有データではなく）データをめぐるコントロールの共有についてです。そして、（ビジネス・ワークフローの自動化ではなく）マルチエンティティ・プロセスの保証についてなのです。
そこで、分散型台帳の可能性を検討できる3つの問いがここに提案します。 これらは2016年版よりも微妙なニュアンスを含んでいます。
- B2Bワークフロー：各参加者が他の参加者のデータの正確性および/またはプロセスを独立して検証する必要のある、二者間またはそれ以上のB2Bワークフローが存在するか？
分散型台帳は相手が格納し使用しているデータが、自分が使用中のデータと同じであることを当事者に保証することができます。台帳自体は、参加者が「誠実」であるかどうかを知らせてくれることはありませんが、参加者が同じデータにアクセスしていることは保証してくるのです。
同様に、当事者間のワークフローが遵守されていること、各エンティティが同じビジネスロジックを運用していること、またはエンティティが事前に合意されたエンゲージメント・ルールと互換性のある結果を出すことも保証できます。言い換えれば、台帳データに対して提案された変更は、事前に合意されたルールに従うものであることです。
さて、分散型台帳でさえも、各当事者は他の誰かの計算結果を検証する必要があるでしょうか……もちろんですよね。 完全に他人の計算に依存するなんて、恐ろしいことですから。 異なるのは、調停がデータが格納される前ではなく、むしろ後に行われるという点です。私は分散型台帳について、「事後に確認される」のではなく、「進行形で確認される」と以前書きました。注文をスイッチすることは、運用リスクに非常に大きな違いをもたらします。
- 業界のユーティリティ：業界向けユースケースの可能性のために、理にかなった業界ユーティリティを想定して設計することはできるでしょうか？ なぜそれがいまだ存在しないのでしょう？ おそらく所有権をめぐる政治的理由か、はたまた誰もが、あるいは誰もそれを所有したいと思わないから、弾みがつかないのでしょうか？
分散型台帳は、場合によっては所有権とユーティリティ制御の問題回避という答えを提供できます。 誰もが特定の種類のデータ共有やデータ相互検証、多者間プロセスに参加していますが、データ自体は、ネットワークを経由するデータを究極的に制御する単一エンティティを経由しないため、ボトルネックは消滅しました。
- 集中化はリスクなのか？
おそらく完璧に優れた集中型ソリューションは存在します。しかし以前、銀行間支払いシステムと集中型のリスクについて書いてきました。サイバー犯罪やサイバー戦争が現実化するなか、破綻の起点が一箇所に集中する重要なインフラシステムのリスクを、速やかに排除していなかくてはなりません。破綻の一点集中化を解決する方策として分散型台帳が有用かを調査することが、国家にとって早急な課題であるといえます。
結論
2016年に使用されたユースケースの枠組みはもはや十分ではありません。この新しいテクノロジーの理解が世界規模で深まるにつれて、それをいつ適用するのかの決定方法を進化させる必要があります。
予算や各委員会、組織政治の現実があるのはわかります。不適切なブロックチェーンのユースケースをプロジェクトにパラパラと振りかけることで、そうでもしなければ受け取れなかったであろう資金を得て、自動化システム構築の予算を確保できることだってあるでしょう。それはそれでオーケーです！
しかしながら、私自身はもう長いこと、「ブロックチェーンのためのブロックチェーン使用」を避けよと提案してきました。本記事で述べた3つの基準／問いは、ビジネスや業界の改善に向け、本当に付加価値のあるユースケースを判断するために役立つはずです。
