誰の為のブロックチェーンシステムか？
あらゆるブロックチェーンサービスにおいて、実際の業務から課題を明らかにし、実行可能範囲を決定していく、”設計”は非常に重要な役割を果たします。
というのも「まずはブロックチェーンを使ってとりあえず実証実験をする」という観点からスタートしてしまうと多くのブロックチェーンプロジェクトが陥ってしまう「Why Blockchain?（なぜブロックチェーンが必要なのか？）」というスパイラルに飲み込まれてしまうからです。
✔︎ 本記事の内容
- ブロックチェーンプロジェクトを進める手順
- ブロックチェーンを使う際の注意点
- ブロックチェーンシステムと一般システムの相違点
クーガーでは以前より、様々なエンタープライズ向けブロックチェーンプロジェクトに関わってきました。そして、多くの企業がブロックチェーンサービスを構築する過程において、「どの様な視点で仮説や検証が必要なのか」、「どのような問題を解決するのか」について悩んでいる現場を目の当たりにしてきました。しかし、そのような悩みを抱えるのも当然です。なぜなら、ブロックチェーンを使ったシステムアーキテクチャは従来のサービスとは違った視点のアプローチが必要になってくるからです。
後に詳しい図が登場する、通信業者の例の場合、従来は部署や連携している子会社毎によって管理しているデータベースが異なっていました。これを消費者目線の具体的課題で言うと、Twitterでフォロワー10万人の影響力を持つユーザーはインスタグラムでは、Twitterの信用価値を流用できないという事と同義です。そこで、ブロックチェーンの特性を生かしてデータ各部署がを共有しながらも、全てを公開するのではなく、データの切り分けによって公開範囲を限定するという事を目的としています。これによって多くの企業が連携やアライアンスの際に抱える、データの「ガラパゴス化」を防ぎ、安全かつスケーラビリティの持ったデータの運用を行う事ができます。
それらのプロセスと実装の概要をクーガーがどの様に行ってきたのか、本記事で具体的に紹介したいと思います。
①UXの可視化とデータ管理
最初のスタートとして、業務フロー・各エンティティ(データの集合体)による制限を明確化をする事が重要です。これらは通常のシステム実装の要件定義では当然行われる事ではありますが、ブロックチェーンのプロジェクトではそれに加えて「誰がデータを保存し、保証をするのか？」が非常に重要になります。
この「誰が？」について深く考察する事が後々になって、どのブロックチェーンをアーキテクチャ(*2)に組み込むのかに大きく関わるというという点で、既存のシステム設計と大きく異なります。
②ユースケース選定
先ほど言及した様に、「誰の為のシステム」で、「誰がシステムを動かすのか？」は非常に重要な要素です。TechCrunchの記事でも紹介されているKDDI社とのプロジェクトでは主に3つの要素を最重要項目として切り出しました。
- データの永続性（トレーサビリティ）
- 情報を秘匿化し、特定の業者間でやりとり（アクセスコントロール）
- 異なるブロックチェーン間での相互運用性（インターオペラビリティ）
トレーサビリティ | データの永続性
一つ目はブロックチェーンを使う上では当然の事なのですが、データのトレーサビリティ（改ざん不可能という点では「イミュータビリティ」の方が適切かもしれません）が挙げられます。しかし、その際に重要な点は「誰がノード(*3)を運用するのか？」です。
考えられるトレーサビリティに対する攻撃としては、もしも運用ノードのコントロールを可能なエンティティ(データの集合体)が2組以下の場合、このシステムはトレーサビリティの担保に失敗してしまいます。なぜなら、ブロックチェーンを分岐してしまえばデータの改ざんが可能になってしまうからです。したがって、ブロックチェーン技術の一つの特徴であるデータの改ざん耐性を保つために、3ノード以上で運用する事がまず第一に決定しました。
アクセスコントロール | 情報を秘匿化し、特定の業者間でやりとり
重要な個人情報や業務情報を扱うシステム設計を考慮にいれると、全ての情報を公開する前提のパブリックイーサリアムは企業にとっては得策とは言えません。では、限られたメンバーのみで運用する場合、果たしてブロックチェーンで行う必要があるのかという問題があります。
そこで我々は、「Enterprise Ethereum Alliance(EEA)」の中で頻繁に紹介されるイーサリアム ブロックチェーンの「Quorum」を使う事にしました。ではなぜQuorumなのか？大きく分けて2つあります。
(1) Ethereumの持つ基本的なブロック、アカウント、ステートの概念は維持したい
(2) 情報を秘匿化し、特定の業者間でのやりとりをしたい
特に重要な点は2つ目です。『トランザクション自体（例えばAlice -> Bobへ何かしらのトランザクション）は記録として残し、Charlieにはトランザクションの中身は見せたく無い。』という事例に対応できないかという点です。ブロックチェーン以外でもエンタープライズの要件では通常こういった要件が発生し、多くは企業が提供するAPI等で対応しています。しかし、それらのAPI自体もサービス側のデータベースより提供される為、データの信頼性は不確かになってしまいます。
そこで異なる3つのエンティティ(データの集合体)がノードを動かし、データの種類に応じて公開範囲を選定して運用するアーキテクチャを採用しました。（※これらを満たすブロックチェーンは2017年の時点ではQuorumのみが対応していた為にこちらに決定）
インターオペラビリティ | 異なるブロックチェーン間での相互運用性
しかし、上記の2つのみだと、エンタープライズブロックチェーンの運用には不十分です。なぜでしょうか？それはサービスというのは通常、長期で運用をしていく必要があるからです。エンタープライズが長期で運用していくには様々な点を考慮に入れていく必要があります。
例えば、
データの容量、
障害やバックアップ対応、
他業者との流動的なアライアンス etc
その中でも今回は、長期的に他業者がアラインアンスに参加してくる際の対応として重要になってくる「インターオペラビリティ（相互運用性）」に着目しました。
なぜインターオペラビリティが重要なのでしょうか？
通常、使用するブロックチェーンネットワークが異なれば、それに参加してるエンティティ(データの集合体)のみが書き込みや読み込みを行う事ができます。しかし、それだけだと流動的な対応ができなくなります。エンタープライズではパートナーの締結やアライアンスも多様になり、設計の際に限定されたネットワーク参加者のみが使えるブロックチェーンだけですと、どうしてもアジリティ(敏しょう性)に欠けてしまいます。
そこで当プロジェクトでは、様々な業者がブロックチェーンを活用したサービスを提供すると仮定して、もう一つのエンティティ(データの集合体)が異なるブロックチェーンを運用する想定でアーキテクチャを選定しました。そこで、イーサリアム以外のブロックチェーンでIBM社が提供するHyperledger Fabricをもう一つのエンティティ(データの集合体)の要件とし、相互接続にInterledger Protocol（通称ILP）を使用しました。
アーキテクチャ
これらを実装する為のアーキテクチャは以下の図の様になります。
第一と第二のユースケースを具現化した物が左側の「修理コンソーシアムネットワーク」に集約されています。ここには一般的なユーザー（つまり消費者）が介入する事はありませんが、通常エンタープライズとそれに関わる関連企業は何かしらのデータベースシステムにアクセスし、業務を行わなければなりません。それらを想定しているのがこのQuorumを使ったコンソーシアム型ネットワークになります。
コンソーシアム型ブロックチェーンに参加しているエンティティ(データの集合体)毎に共有している情報は上の図の一番左の図の通りになります。この図の見てわかる通り、どのエンティティ(データの集合体)に対してどの情報を公開するか、逆にどの情報を秘匿化するのかが明確になります。
そして第三のアーキテクチャでは別のプライベート型ブロックチェーン（今回はHyperledger Fabric）を使って管理しているコンソーシアム外のリユースプライベートネットワークに対しての相互接続を行いました。共有するデータはケースによって異なりますが、例えば修理のステータスや在庫状況、携帯端末の金額等が良い例となります。
これによってエンタープライズブロックチェーンに特化したQuorumのプライベートトランザクションの機能を生かして共有範囲を限定する事でデータのプライバシーを保護しながら運用出来る事を実現しました。
まとめ
ブロックチェーンのシステムを構築する際に、様々な要因が絡んでアーキテクチャを選定しなくてはならない事がわかるかと思います。それらは既存のアプローチとは大きく異なり、ノードをオペレートするエンティティ(データの集合体)に対してのインセンティブやインターオペラビリティ、アクセスコントロール等を考慮しなければならない点等が一例として挙げられます。
また「Why Blockchain？」に対する回答が明確になったら、次は「どのブロックチェーンを利用するのか？」を検討しなければなりません。これはユースケース毎に異なり、何でも解決できるいわゆる「銀の弾丸」として機能する「ブロックチェーン」は存在しないと言う事を理解した上で最適なアーキテクチャを構築しなければなりません。
企業はトランザクションスピード、ユーザビリティ、スケーラビリティ、ゲーム理論等の様々な角度から、サービスの特徴を生かしたブロックチェーンアプリケーションを構築していく必要があります。今回の記事はそのプロジェクト設計の具体的事例の一つでしたが、今後こういった技術的、ビジネス的なアプローチ手法を紹介をしていく予定です。
■ 用語集
*アーキテクチャ：コンピュータ システムの論理的構造
*ノード : ネットワークの接点、分岐点
*インターオペラビリティ : 相互運用性
