過去の連載記事では、エンタープライズ企業がブロックチェーンの基盤選定をする際における、設計思想への理解の重要性について述べ、プライバシー確保がなぜ重要で難しいかを説明した上で、実際の開発・保守・運用においてどんな検討事項があるかについて説明しました。そして、なぜエンタープライズ企業はパブリックチェーンよりもエンタープライズ・ブロックチェーンを選ぶ傾向にあるかについて説明しました。
・ブロックチェーンとの向き合い方 -Cordaの設計思想を例に-
・エンタープライズ企業におけるブロックチェーン活用の課題 -プライバシーの確保-
・エンタープライズ企業のブロックチェーン導入 -開発・保守・運用-
・エンタープライズ企業がブロックチェーンの基盤選定でパブリックチェーンを避ける理由
本記事では、さらに一歩踏み込んで、Cordaの設計思想やその設計思想を元に、どのような実装をしたかについて述べたいと思います。
- 目次
Cordaの設計思想
Cordaの設計思想は企業の要件と向き合い、実際に問題を解決することだと私は考えています。
Cordaを設計・開発したのはアメリカのR3社ですが、R3社はエンドユーザーである複数の銀行によって設立され、金融機関でブロックチェーン技術を活用していくことを目的に設立された会社です。その後、各ブロックチェーン基盤を比較したり、実証実験を行ったりしていく中で、既存の基盤では、どうしても要件に合わないと気付いたのです。
分散台帳技術/ブロックチェーン技術がビジネスにもたらすインパクトを誰よりも理解しているため、「じゃあ自分たちで作っちゃうか！」と全くゼロの状態からスクラッチで開発されたのがCordaです。
言い換えると、要件ありきで開発されたブロックチェーン基盤ということになります。具体的にどのような要件があったのでしょうか。
プライバシーの確保
一言でプライバシーと言っても様々なレベルがあります。Cordaで実現したかったプライバシーとは「取引当事者間でのみデータを公開する」ということです。
過去の記事の中でも、ブロックチェーン技術自体、プライバシー確保とあまり相性が良くないと述べました。それは、「正しい」とされる台帳を決めるためには、そのデータの中身を見る必要があるからです。データを見なければ「正しい」とされる台帳を決められない中で、プライバシーを守ろうとしているから難しいのです。
ブロックチェーンが想定通りにワークするためには、複数のノード(それぞれ異なる企業が持つノード)で一つの「正しい」とされる台帳を決める必要があります。ある時点のデータを「正しい」と決め、皆でそのデータを持つことで、誰かが一つのノードのデータを改ざんしても、他の人が持つノードのデータと異なるため、改ざんされたことがわかるわけです。
プライバシー確保のために、Cordaは1ブロック１取引となるように設計されています。言い換えると、設計段階からプライバシーの確保を考慮して、ビットコインやイーサリアムと異なる半順序モデルに設計しているということになります。 例えば図表1のブロック２をみてみましょう。ブロック2のデータの中には、ハッシュ１が含まれています。その為、ブロック２はブロック1を特定することができます。しかし、ブロック2はブロック3のデータを一切持っていなく、ブロック2からブロック3を探す事はできないません。
図表1 Cordaのデータモデル
これは暗号学やデータサイエンスのアプローチとは異なるアプローチとも言えます。一方、このような設計をすると、二重支払をどのように防ぐかの課題が出てきます。
Cordaでは、Notaryノードという二重支払防止の役割を果たすノードがあります。Notaryは各トランザクションのHash及びトランザクションのアウトプットに紐づくインデックスだけを基に二重支払い有無の検証を行います。
当然、このような設計では様々な問題があります。例えば、単一障害点になり得るのではないか、データモデルの性質上、データをなくした場合どうするかなどは良く指摘される問題です。
Notaryノードが単一障害点になり得る指摘に関しては、複数運営主体によるクラスタ構成をとることで解決することができ、データの厳格な管理はエンタープライズの世界では当たり前のリスク管理で、バックアップをとるなど様々な方法があります。エンタープライズ企業の要件や運用方法を深く理解し、設計されているからこそ、Corda別のアプローチを取れたのではないかと私は考えます。
アイデンティティの問題
エンタープライズ企業レベルで使う時の要件として、アイデンティティの問題もあります。この点もCordaは企業の要件と向き合い、実際に問題を解決しようという思想のもと、設計されています。
エンタープライズレベルで使うネットワークを構築することは何を意味するのでしょうか。また、どのようなことを考える必要があるのでしょうか。
当然、適切にネットワークに参加するアイデンティティの認証や管理を行う必要があります。例えば、ネットワークに参加できるのはどのような主体なのか、参加するためにはどのような手続きが必要で、それを管理しているのは誰なのかなどを考える必要があります。当然のことながら、ネットワークにアクセスすることを拒否できる権限を持つ団体は営利団体であってはいけません。
また、ネットワークに参加した企業の情報の管理をどのように行うのかも考えなければなりません。各アイデンティティのノードにどのような情報をどのような方法で持たせる必要があるかも考える必要があります。例えば、公開鍵発行の仕方はどのように行うか、公開鍵と実世界におけるアイデンティティをどのように結びつけるかなどです。
なぜなら、データのやり取りをする際、自分がやり取りしている相手は「本当に」やり取りすべき相手なのかどうかを確実に確認できる必要があるからです。特にグローバル範囲に渡って価値のやり取りを行おうとすると、かなり強固なアイデンティティを管理するシステムが必要になってくると考えられます。そこで、実世界の本当に存在しているアイデンティティとやり取りをするためのスキームが必要になってきます。
Cordaのネットワークは様々なコンポーネントがあります。
Trust Root (Root CA)
Trust Rootはネットワークに参加するノードに対し、公開鍵を付与/証明書を発行する認証局のことです。
ノードは、TLSを通して認証され、標準のPKIXテクノロジーを使用して、双方向のセッションを実行します。各ノードは、指定された認証局（CA）がネットワークに対して発行したX.509証明書によって識別されます。CAはCorda Networkの運営組織によって任命されます。
Trust RootはCordaのネットワークにおける信頼の源泉であり、厳格なセキュリティで管理されます。言い換えると、CordaにおけるセキュリティはこのTrust Root(左図のRoot CA)によって保障されるのです。
また、Trust Rootを元に、左の図のような構造で自由に階層を設計することができます。
以下のURLからポリシーについて確認することができます。 https://trust.corda.network/trust-root/certificate-policy.html
Identity Manager(アイデンティティ・マネージャー)
Identity Managerはネットワークの参加の管理を行うコンポーネントです。主には参加の許可と参加許可の失効の二つの役割があります。
ネットワークにノードが参加する際、Trust Rootの鍵を元に作成されたIdentity Managerが持つ鍵を利用して、ネットワークに参加するノードの公開鍵/証明書を発行します。X.500識別名と公開鍵のペアから作成される証明書を参加ノードに提供することで、Cordaネットワークへの参加が承認されます。
参加ノードより、証明書を失効させたいとリクエストを受けた際には、証明書のシリアル番号や正式なリーガル名等の様々な情報を受けて失効させることも可能です。
Network Map Service(ネットワーク マップ サービス)
Network Map Serviceはネットワークに参加しているノードの電話帳のようなものです。
Network Mapにはネットワークへの参加が許可されたノードの公開鍵や証明書、IPアドレス、国や地域、名前等のノードの情報が入っています。
現実世界で電話することをイメージすることでノード間通信を考えると分かりやすいかもしれません。電話をかけるためには、電話帳から電話を掛けたい相手の名前や電話番号を調べて電話をかけるように、Cordaにおけるノード間通信はNetwork Mapから通信したいノードの名前を調べ、公開鍵を調べる必要があります。
当然電話帳に間違った電話番号を記載すると電話の掛け間違いが生じます。電話をかけ間違ったら、正しい電話番号を調べてかけなおせば良いのですが、価値のやり取りを行うブロックチェーン基盤でこのようなことが生じると、甚大な被害が出る可能性があります。
これでネットワークに参加しているノードがお互いに安全に通信できる環境が整いました。
ビジネスロジックの構築
ただこれだけでは不十分です。上述の電話の例において、人間は電話をつないで話せば良いのですが、機械間の通信はそう簡単にはいきません。ある種のビジネスプロセス（例えば、請求書に同意するプロセスや保険証券の詳細を更新するプロセス）をエンコードするビジネスロジックを記述する方法が必要です。
複数の企業間で実行できる同様のコードを展開する必要がありますが、特定のやり取りでは、各企業の役割はおそらくわずかに異なるようにする必要もあるでしょう。
したがって、ビジネスプロセスの参加者間で分散できる、記述が簡単で、ビジネスロジックだけでなくプロセスロジックとワークフローロジックもカバーできる、ある種のアプリケーションが必要です。
CordaではそれをCorDappと言います。
CorDappではState、Transaction、Contract、Flowの四つのキーコンセプトがあります。この4つのキーコンセプトを用いて、エンタープライズ企業間で発生し得る様々な業務プロセスをカバーすることができます。
結局Cordaの設計思想は何？
改めてCordaの設計思想について考えてみたいと思います。冒頭でCordaの設計思想は企業の要件と向き合い、実際に問題を解決することだと述べました。エンタープライズ企業の要件とは何でしょうか。ユースケースごと、企業ごと、部署ごとに要件が異なるかもしれません。
しかし、分散台帳技術/ブロックチェーン技術の特性上、複数のエンティティで使うからこそ初めて価値が発揮されるケースが多くあります。様々なエンティティがあり、要件が異なる中で、できるだけ多くのエンタープライズ企業が納得して使えるように設計したのがCordaなのではないかと私は考えています。
最後まで読んで頂き、ありがとうございます。ぜひ気軽に声をかけていただき、一緒に分散台帳技術の普及について検討させていただけるとありがたいとおもっています。
Facebook： m.me/R3DLTJapan Twitter： SBI R3 Japan(@r3sbi) HP： https://sbir3japan.co.jp/product.html
また、SBI R3 Japanでは、一緒にビジネスを作り上げてくれる仲間（コンサルタント・エンジニア）を募集しています。興味がある方はinfo-srj@sbir3japan.co.jpまでご連絡ください。カジュアルミーティングも大歓迎です。
（記事作成：SBI R3 Japan/Zhao sheng)