(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-19
(45)【発行日】2023-07-27
(54)【発明の名称】ブロックチェーンクラウドサービスのためのインターフェイスを提供するためのシステムおよび方法
(51)【国際特許分類】
G06F 9/52 20060101AFI20230720BHJP
G06F 16/182 20190101ALI20230720BHJP
G06F 9/54 20060101ALI20230720BHJP
G06F 9/455 20180101ALI20230720BHJP
【FI】
G06F9/52 150C
G06F16/182
G06F9/54 D
G06F9/455 150
【外国語出願】
(21)【出願番号】P 2021209477
(22)【出願日】2021-12-23
(62)【分割の表示】P 2019546842の分割
【原出願日】2018-09-28
【審査請求日】2022-01-17
(32)【優先日】2017-09-29
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2018-09-25
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2018-09-25
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2018-09-25
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】リトル,トッド
(72)【発明者】
【氏名】シ,ピアース
(72)【発明者】
【氏名】リ,ジャレド
(72)【発明者】
【氏名】ジョウ,シ・シャン
(72)【発明者】
【氏名】ジュ,ウェイグオ
(72)【発明者】
【氏名】ジュ,シェン
(72)【発明者】
【氏名】リ,シュン
(72)【発明者】
【氏名】ジン,ジム
(72)【発明者】
【氏名】ヂャン,チンシェン
【審査官】三坂 敏夫
(56)【参考文献】
【文献】特表2015-507301(JP,A)
【文献】特開2011-215827(JP,A)
【文献】特表2014-512589(JP,A)
【文献】米国特許出願公開第2017/0177855(US,A1)
【文献】本多和幸,既存ビジネスモデルの破壊か、進化か? ブロックチェーンの革新 34,週刊BCN,株式会社BCN,2017年03月06日,第1668巻,p.20
【文献】Marko Vukolic,Rethinking Permissioned Blockchains,BCC '17: Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts,2017年04月,pp.3-7
【文献】赤羽喜治ほか,ブロックチェーン 仕組みと理論,第1版,株式会社リックテレコム,2016年10月28日,pp.198-217
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/455- 9/54
16/182
(57)【特許請求の範囲】
【請求項1】
ブロックチェーンクラウドサービスのためのインターフェイスを提供するためのシステムであって、
少なくとも1つのプロセッサを含むコンピュータと、
コンテナサービスを含むクラウドベースのプラットフォームと、
複数の分散型台帳とを含み、前記複数の分散型台帳の各々は、前記クラウドベースのプラットフォームの複数のテナントのうちの別個のテナントとして前記クラウドベースのプラットフォーム上で実行され、前記複数の分散型台帳の各々は、前記コンテナサービスによって提供される1組のコンテナ上で実行され、前記システムはさらに、
アイデンティティサービスを含み、前記アイデンティティサービスは、前記複数の分散型台帳の各々について認証を提供し、
前記複数の分散型台帳の各々はそれぞれ、
ピアコンテナと、
オーダリングコンテナと、
チェーンコードコンテナとを含
み、
一部の参加者によって構成されるグループに対してチャネルが定義され、
各トランザクションは、前記複数の分散型台帳のうち1の分散型台帳に対応するチャネルを特定する情報を含み、
前記複数の分散型台帳の各々において、トランザクションは、当該トランザクションにおいて特定されるチャネルに対応するオーダリングコンテナに送信される、システム。
【請求項2】
前記複数の分散型台帳の各々はそれぞれ、異なるブロックチェーン台帳に関連付けられる、請求項1に記載のシステム。
【請求項3】
各ピアコンテナはそれぞれ、関連付けられた前記ピアコンテナの前記分散型台帳に関連付けられた前記ブロックチェーン台帳を保持する、請求項2に記載のシステム。
【請求項4】
各チェーンコードコンテナはそれぞれ、関連付けられた前記チェーンコードコンテナの前記分散型台帳に関連付けられた前記ブロックチェーン台帳に資産が書かれることを可能にする、請求項3に記載のシステム。
【請求項5】
各オーダリングコンテナはそれぞれ、関連付けられた前記オーダリングコンテナの前記分散型台帳に関連付けられた前記ブロックチェーン台帳上のトランザクションを順序付ける、請求項4に記載のシステム。
【請求項6】
各チェーンコードコンテナは、関連付けられたピアコンテナによって開始される、請求項4に記載のシステム。
【請求項7】
前記複数の分散型台帳の各々に関連付けられたフロントエンドロードバランサをさらに含み、
前記複数の分散型台帳のうちの1つの分散型台帳への着信コールは、関連付けられた前記フロントエンドロードバランサを通って渡される、請求項1~請求項6のいずれか1項に記載のシステム。
【請求項8】
ブロックチェーンクラウドサービスのためのインターフェイスを提供するための方法であって、
少なくとも1つのプロセッサを含むコンピュータを提供するステップと、
前記コンピュータで、コンテナサービスを含むクラウドベースのプラットフォームを提供するステップと、
複数の分散型台帳を実行するステップとを含み、前記複数の分散型台帳の各々は、前記クラウドベースのプラットフォームの複数のテナントのうちの別個のテナントとして実行され、前記複数の分散型台帳の各々は、前記コンテナサービスによって提供される1組のコンテナ上で実行され、前記方法はさらに、
アイデンティティサービスを提供するステップを含み、前記アイデンティティサービスは、前記複数の分散型台帳の各々について認証を提供し、
前記複数の分散型台帳の各々はそれぞれ、
ピアコンテナと、
オーダリングコンテナと、
チェーンコードコンテナとを含
み、
一部の参加者によって構成されるグループに対してチャネルが定義され、
各トランザクションは、前記複数の分散型台帳のうち1の分散型台帳に対応するチャネルを特定する情報を含み、
前記複数の分散型台帳を実行するステップは、前記複数の分散型台帳のそれぞれについて、トランザクションを、当該トランザクションにおいて特定されるチャネルに対応するオーダリングコンテナに送信することを含む、方法。
【請求項9】
前記複数の分散型台帳の各々をそれぞれ、異なるブロックチェーン台帳に関連付けるステップをさらに含む、請求項8に記載の方法。
【請求項10】
各ピアコンテナはそれぞれ、関連付けられた前記ピアコンテナの前記分散型台帳に関連付けられた前記ブロックチェーン台帳を保持する、請求項9に記載の方法。
【請求項11】
各チェーンコードコンテナはそれぞれ、関連付けられた前記チェーンコードコンテナの前記分散型台帳に関連付けられた前記ブロックチェーン台帳に資産が書かれることを可能にする、請求項10に記載の方法。
【請求項12】
各オーダリングコンテナはそれぞれ、関連付けられた前記オーダリングコンテナの前記分散型台帳に関連付けられた前記ブロックチェーン台帳上のトランザクションを順序付ける、請求項11に記載の方法。
【請求項13】
各チェーンコードコンテナは、関連付けられたピアコンテナによって開始される、請求項11に記載の方法。
【請求項14】
前記複数の分散型台帳の各々に関連付けられたフロントエンドロードバランサを提供するステップをさらに含み、
前記複数の分散型台帳のうちの1つの分散型台帳への着信コールは、関連付けられた前記フロントエンドロードバランサを通って渡される、請求項8~請求項13のいずれか1項に記載の方法。
【請求項15】
コンピュータによって実行されることにより前記コンピュータに請求項8~請求項14のいずれか1項に記載の方法を実施させる命令を有する、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
著作権表示
この特許文献の開示の一部は、著作権保護の対象となる資料を含む。この特許文献または特許開示は特許商標庁の特許ファイルまたは記録に記載されているため、著作権保有者は、何人によるその複写複製に対して異議はないが、その他の場合には如何なるときもすべての著作権を保有する。
【0002】
優先権の主張および関連出願との相互参照:
本願は、2017年9月29日に出願された出願番号第62/565,999号の「ブロックチェーンクラウドサービスを提供するためのシステムおよび方法」(SYSTEM AND METHOD FOR PROVIDING A BLOCKCHAIN CLOUD SERVICE)と題された米国仮特許出願、2018年9月25日に出願された出願番号第16/141,329号の「ブロックチェーンクラウドサービスのためのインターフェイスを提供するためのシステムおよび方法」(SYSTEM AND METHOD FOR PROVIDING AN INTERFACE FOR A BLOCKCHAIN CLOUD SERVICE)と題さ
れた米国特許出願、2018年9月25日に出願された出願番号第16/141,337号の「ブロックチェーンクラウドサービスを管理するためのシステムおよび方法」(SYSTEM AND METHOD FOR MANAGING A BLOCKCHAIN CLOUD SERVICE)と題された米国特許出願、
および、2018年9月25日に出願された出願番号第16/141,339号の「ブロックチェーンクラウドサービスのためのレプレゼンテーショナルステートトランスファープロキシサービスを提供するためのシステムおよび方法」(SYSTEM AND METHOD FOR PROVIDING A REPRESENTATIONAL STATE TRANSFER PROXY SERVICE FOR A BLOCKCHAIN CLOUD SERVICE)と題された米国特許出願の優先権の利益を主張するとともに、2017年4月12日に出願された番号第15/485,532号の「マルチテナントアイデンティティおよびデータセキュリティ管理クラウドサービス」(MULTI-TENANT IDENTITY AND DATA SECURITY MANAGEMENT CLOUD SERVICE)と題された米国特許出願(後に米国特許第9,781,122号として2017年10月3日に発行)に関連している。これらの出願の各々は、ここに引用により援用される。
【0003】
発明の分野:
この開示は概して、分散型台帳を提供するためのシステムおよび方法に関する。より特定的には、この開示は、ブロックチェーンクラウドサービスとして実現される分散型台帳を管理するためのシステムおよび方法を説明する。
【背景技術】
【0004】
背景:
分散型台帳は、資産所有権のデジタル記録として大まかに説明され得る。台帳の中心的なアドミニストレータは存在せず、中央データストアも存在しない。代わりに、台帳は、複数の場所、国、または機関にわたって地理的に広がり得るコンピューティング環境における多くの参加ノードにわたって複製される。コンセンサスプロトコルが、各ノードの台帳のコピーが他のすべての他のノードのコピーと同一であることを保証する。また、コピーの集合が、単一の共有台帳として見られてもよい。分散型台帳は、資産所有者によって、たとえば自分のアカウントから引き落として別のアカウントに入金するために、暗号署名技術を用いて使用されてもよい。
【0005】
ブロックチェーンとは、改ざんされにくい分散型台帳を実現するために使用され得るデータ構造である。複数のノードが、クライアントからのトランザクションがブロックへと
パッケージ化される共通プロトコルに従い、ノードは、次のブロックについて同意するためにコンセンサスプロトコルを使用する。ブロックは、台帳の改ざんを困難にする累積暗号ハッシュを担持する。各ブロックは、時間的に前のブロックとの関連(ハッシュ値)を有する。加えて、各ブロックは、それ自体のハッシュを含み得る。ブロックチェーンは、後方に(たとえばチェーンを遡って)横断され得る。
【0006】
ブロックチェーンは、非許可型ブロックチェーンまたは許可型ブロックチェーンのいずれかであり得る。誰でも非許可型ブロックチェーンに加入して分散型台帳のコピーを有することができる。ビットコイン(Bitcoin)およびイーサリアム(Ethereum)は、非許可
型ブロックチェーンの例である。非許可型ブロックチェーンは、単一のエンティティによる制御を回避しつつ、匿名の参加者が台帳を保持することを可能にする。しかしながら、匿名性に鑑みて、アイデンティティ、説明責任、および監査可能性が困難である。対照的に、許可型ブロックチェーンは、招待によってメンバーを受け入れ、明示的に認可された当事者が台帳を保持することを可能にすることによって信用および説明責任のレベルを考慮する。
【0007】
ハイパーレッジャー(Hyperledger)ファブリックは、許可型ブロックチェーンの例で
ある。企業グレードのオープンソース分散型台帳フレームワークおよびコードベースとしてのハイパーレッジャーファブリックは、スマートコントラクトを実行するための分散型台帳プラットフォームの実現化例である。それは、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。
【0008】
プラットフォーム・アズ・ア・サービス(Platform as a Service:PaaS)とは、
アプリケーション開発、データ管理、統合、モバイル、およびモノのインターネット(Internet of Things:IOT)のための多くのクラウドサービスである。クラウドサービスからの需要が増えるにつれて、ブロックチェーンPaaSクラウドサービスを提供することが望ましいであろう。ブロックチェーンPaaSクラウドサービスは、第三者である仲介役の必要性を減少させつつ、スマートコントラクトを構築して実行し、改ざんされにくい分散型台帳を保持するための予め組立てられたプラットフォームを提供することができる。PaaSブロックチェーンクラウドサービスはまた、他のPaaSサービスを活用するブロックチェーンソリューションの開発を可能にすることができる。
【発明の概要】
【課題を解決するための手段】
【0009】
概要:
一実施形態によれば、分散型台帳をブロックチェーンクラウドサービス(Blockchain Cloud Service:BCS)として実現するためのシステムおよび方法がここに説明される。BCSは、生産準備ができたブロックチェーンの設定および実行を可能にするために、計算、コンテナ、ストレージ、アイデンティティ管理、およびイベントストリーミングというインフラストラクチャサービスおよび埋め込みリソースの完全集合を含み得る。BCSは、アドミニストレータが1つ以上のパラメータを特定することに応答して、根底的なインフラストラクチャに、必要とされるブロックチェーンネットワークコンポーネント、インターフェイス、レプレゼンテーショナルステートトランスファー(representational state transfer:REST)プロキシサービスコンポーネント、および管理コンソールコ
ンポーネントをプロビジョニングすることができる。
【0010】
一実施形態によれば、分散型台帳はハイパーレッジャーファブリックであってもよく、それは、ブロックチェーンアプリケーションを開発するための基盤として意図されたブロックチェーン技術の実現化例である。ハイパーレッジャーファブリックはモジュール式ア
ーキテクチャを提供することができ、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。
【0011】
一実施形態によれば、BCSは、PaaSマネージャ(たとえば、オラクルPaaSサービスマネージャ(PaaS Service Manager:PSM)プラットフォーム)に基づくことができ、PaaSマネージャ上の計算空間(たとえば、外部計算空間)で実行可能である。システムは、オラクルアイデンティティクラウドサービス(Identity Cloud Service:IDCS)、オラクル・ロード・バランサ・アズ・ア・サービス(Load Balancer as a Service:LBaaS)、オラクルイベントハブクラウドサービス、およびオラクルクラウドストレージを使用して階層化されたコンテナランタイムサービス環境(Dockerまたはオラクルのアプリケーションコンテナクラウドサービスなど)を含むPSMプラットフォームの特徴を利用する。各顧客ブロックチェーンはプロビジョニングされ、テナントとして実行され得る。システムは複数のブロックチェーンをサポートし、それらは各々、マルチテナント環境において別個のテナントとしてプロビジョニングされ、実行される。
【0012】
一実施形態によれば、管理コンソールコンポーネントおよびRESTプロキシサービスコンポーネントは双方とも、BCSにおけるネットワークノードであり得る。
【0013】
一実施形態によれば、管理コンソールコンポーネントは、BCSのプロビジョニング、監視、および構成を容易にし、自動化する。管理コンソールコンポーネントは、スクリプトランタイム環境、たとえばNode.jsにおいて実行されるウェブアプリケーションを含み
得る。ウェブアプリケーションは、グラフィカルユーザインターフェイスフレームワークおよびウェブフレームワーク上に構築可能であり、BCSインスタンスにおけるさまざまなノードまたはサービスと通信するための複数のカスタム機能またはAPIを含み得る。ウェブアプリケーションは、BCSインスタンスにおけるさまざまなノードまたはサービスからの情報を、コンソールユーザインターフェイスでの表示のために、ビューオブジェクトにポピュレートすることができる。管理コンソールコンポーネントはまた、アドミニストレータがBCSインスタンスにおける1つ以上のノードを起動、停止、および更新するための複数の機能を提供することができる。ウェブアプリケーションによって提供されるものと同じ機能をサポートするために、1組の管理REST APIが、スクリプトランタイム環境によって提供され、またはスクリプトランタイム環境によってアクセスされ得る。
【0014】
一実施形態によれば、BCSインスタンス内のRESTプロキシサービスコンポーネント(すなわち、RESTプロキシサービス、またはRESTプロキシ)は、分散型台帳と通信するために、BCSにおける分散型台帳のためのサービス開発キット(service development kit:SDK)を使用することができ、また、チェーンコードを通して問合せ、
チェーンコードを通してトランザクションを同期的または非同期的に呼び出し、トランザクションステータスを入手し、BCSプロキシバージョンを入手するために、クライアントアプリケーションによって使用されるためのREST APIを提供することができる。RESTプロキシサービスコンポーネントは、分散型台帳とインターフェイス接続する際に使用するために、RESTコールを認証し、RESTコールをリモートプロシージャコール、たとえばグーグル(登録商標)リモートプロシージャコール(Google Remote Procedure Call:gRPC)に変換することができる。RESTプロキシサービスコンポーネントはさらに、BCS管理コンソールコンポーネントによって提供されるものと同じ機能をサポートするREST APIを提供し、BCSインスタンスを消費するためにクライアントアプリケーションのためのユーザインターフェイスを提供することができる。
【図面の簡単な説明】
【0015】
図面の簡単な説明:
【
図1A】一実施形態に従った、ブロックチェーンクラウドサービスシステムのファブリックにおけるトランザクションフローを示す図である。
【
図1B】一実施形態に従ったブロックチェーンクラウドサービスシステムを示す図である。
【
図1C】一実施形態に従ったBCSシステムを示す図である。
【
図1D】一実施形態に従ったBCSシステムを示す図である。
【
図1E】一実施形態に従った、ブロックチェーンクラウドサービスのためのインターフェイスを提供するための方法のフローチャートである。
【
図2】一実施形態に従った、ブロックチェーンクラウドサービスシステムのためのゲートウェイを示す図である。
【
図3】一実施形態に従った、ブロックチェーンクラウドサービスシステムのための持続性を示す図である。
【
図4】BCS上のファブリックの例示的なデプロイメントを示す図である。
【
図5】一実施形態に従ったチェーンコードアーキテクチャを示す図である。
【
図6】一実施形態に従った、管理コンソールを提供するためのシステムを示す図である。
【
図7A】一実施形態に従った、BCSコンソールUIにおけるユーザインターフェイスの例を示す図である。
【
図7B】一実施形態に従った、BCSコンソールUIにおけるユーザインターフェイスの例を示す図である。
【
図7C】一実施形態に従った、管理コンソールを提供するための方法を示す図である。
【
図8A】一実施形態に従った、BCSインスタンスにおいてRESTプロキシサービスを提供するためのシステムを示す図である。
【
図8B】一実施形態に従った、BCSインスタンスにおいてRESTプロキシサービスを提供するためのシステムを示す図である。
【
図8C】一実施形態に従った、BCSインスタンスにおいてRESTプロキシサービスを提供するための方法を示す図である。
【
図9A】一実施形態に従った、シングルサインオンのための典型的なIDCS使用事例を示す図である。
【
図9B】一実施形態に従った、ファブリッククライアント認証のためのIDCS使用事例を示す図である。
【発明を実施するための形態】
【0016】
詳細な説明:
一実施形態によれば、分散型台帳をクラウドサービスとして実現するためのシステムおよび方法がここに説明される。特定の一実施形態では、許可型ブロックチェーン台帳、たとえばハイパーレッジャーファブリックが、ブロックチェーンクラウドサービス(BCS)として提供され得る。
【0017】
以下の説明では、この発明を、添付図面の図において、限定のためではなく例示のために説明する。この開示におけるさまざまな実施形態への参照は、必ずしも同じ実施形態への参照ではなく、そのような参照は少なくとも1つを意味する。特定の実現化例が述べられるが、これは例示のためにのみ提供されるということが理解される。関連技術の当業者であれば、他の構成要素および構成が、この発明の範囲および精神から逸脱することなく使用され得るということを認識するであろう。
【0018】
一実施形態によれば、場合によっては、この発明の徹底的な説明を提供するために、多くの特定の詳細が述べられるであろう。しかしながら、この発明がこれらの特定の詳細なしで実践され得るということは、当業者には明らかであろう。他の場合、発明を不明瞭に
しないように、周知の特徴はそれほど詳細には説明されていない。
【0019】
本発明は、特定される機能およびそれらの関係の実行を示す機能的構造ブロックの助けを借りて説明される。説明の便宜上、これらの機能的構造ブロックの境界はしばしば、ここに任意に定義されている。このため、同じ要素によって行なわれると図示された機能が、代替的な実施形態では、異なる要素によって行なわれてもよい。別々の要素において行なわれると図示された機能が、代わりに、1つの要素へと組合されてもよい。特定される機能およびそれらの関係が適切に実行される限り、代替的な境界を定義することができる。このため、そのような代替的な境界はいずれも、この発明の範囲および精神内にある。
【0020】
図面および詳細な説明の全体にわたって同じ要素を示すために、共通の参照符号が使用される。したがって、ある図で使用される参照符号は、要素が別の場所に記載される場合、そのような図に特有の詳細な説明で参照されてもされなくてもよい。
【0021】
ブロックチェーン技術は、顧客のエコシステムにわたってほぼリアルタイムの分散トランザクションを可能にすることにより、および、安全で改ざんされにくいデータ共有を可能にすることにより、企業ビジネス価値を劇的に高める潜在能力を有する。ハイパーレッジャーファブリックブロックチェーンは、モジュール式アーキテクチャと、水平/産業横断的技術サポートと、企業ニーズのためのサポートとを取り入れている。
【0022】
はじめに
一実施形態によれば、ハイパーレッジャーファブリックは、高度の機密性、回復力、柔軟性、およびスケーラビリティを与えるモジュール式アーキテクチャによって下支えされた、分散型台帳ソリューションのためのプラットフォームである。それは、異なるコンポーネントのプラグ可能な実現化例をサポートし、経済エコシステムにわたって存在する複雑性に対処するように設計されている。
【0023】
一実施形態によれば、ハイパーレッジャーファブリックは、柔軟で拡張可能なアーキテクチャを与え、それを代替的ブロックチェーンソリューションから区別する。
【0024】
ブロックチェーン - 分散型台帳
一実施形態によれば、ブロックチェーンネットワークは、ネットワーク上で起こるトランザクションをすべて記録する分散型台帳を含み得る。
【0025】
一実施形態によれば、ブロックチェーン台帳はしばしば、分散化されていると説明される。なぜなら、それが多くのネットワーク参加者にわたって複製され、参加者は各々、その保持において協力するためである。分散化および協力は、ビジネスが実世界で商品やサービスを交換するやり方を反映する属性である。
【0026】
分散化され協力的であることに加えて、ブロックチェーンに記録される情報は付加のみであり、トランザクションが台帳にいったん追加されるとそれを修正することはできないということを保証する暗号手法を使用する。この不変性という特性は、情報の出所の判断を簡単にする。なぜなら、参加者は情報が事後に変更されていないことを確信できるためである。このように、ブロックチェーンは、証明のシステムとして考えられ得る。
【0027】
ブロックチェーン - スマートコントラクト
一実施形態によれば、情報の一貫した更新をサポートするために、および、ある台帳機能(取引する、問合せるなど)を可能にするために、ブロックチェーンネットワークは、スマートコントラクトを使用して、台帳への制御されたアクセスを提供する。
【0028】
一実施形態によれば、スマートコントラクトは、情報をカプセル化し、それをネットワーク中で簡単なまま保つための主要メカニズムであるだけではなく、それらは、参加者がトランザクションのある局面を自動的に実行できるようにするように書かれることもできる。
【0029】
一実施形態によれば、スマートコントラクトは、たとえば、品物がいつ到着するかに依存して変わる、品物を出荷するコストを規定するために書かれ得る。品物が受け取られると、両当事者によって同意され、台帳に書かれた条件で、適切な費用が自動的にやりとりされる。
【0030】
ブロックチェーン - コンセンサス
一実施形態によれば、適切な参加者によってトランザクションが承諾された場合のみ台帳が更新されること、および、台帳が更新を行なうとそれらが同じトランザクションを同じ順序で用いて更新されることを保証するために、ネットワーク全体で台帳トランザクションを同期されたまま保つプロセスは、コンセンサスと称され得る。
【0031】
一実施形態によれば、ブロックチェーンは、スマートコントラクトを介して更新され、コンセンサスと呼ばれる協力的プロセスを通して一貫して同期されたまま保たれる、共有の複製されたトランザクションシステムとして考えられ得る。
【0032】
ブロックチェーンの利点
一実施形態によれば、現在利用可能なトランザクションネットワークは、ビジネス記録が保存されてから存在してきたネットワークのバージョンである。ビジネスネットワークのメンバーは互いに取引するが、各メンバーは自分のトランザクションの別個の記録を保持する。また、トランザクションのオブジェクトは、それらが販売されるたびに確立されるそれらの出所を有することにより、ある品物を販売するビジネスが、それ自体の品物の所有権を検証する所有権変遷履歴を所有することを保証できる。
【0033】
一実施形態によれば、現在のビジネスネットワークがコンピューティングシステムによって現代化されているにもかかわらず、ネットワーク参加者のアイデンティティを管理するための統一されたシステムは存在していない。セキュリティトランザクション(その世界全体での金額は何兆ドルにも達する)を明らかにするには数日かかるので、出所を確立することは手間がかかる。コントラクトは手作業で署名され実行されなければならない。また、システムにおけるあらゆるデータベースは固有の情報を含み、したがって単一障害点を表わす。
【0034】
一実施形態によれば、ブロックチェーンは、ネットワーク上にアイデンティティを確立し、トランザクションを実行し、データを格納するための標準的方法を提供することにより、トランザクションの標準的システムによって表わされる非効率のうちの多くに対する代替物を提供する。
【0035】
一実施形態によれば、ブロックチェーンネットワークでは、それへの各参加者は、台帳の自分用の複製されたコピーを有する。台帳情報が共有されることに加えて、台帳を更新するプロセスも共有される。参加者のプライベート台帳を更新するために参加者のプライベートプログラムが使用される他のシステムとは異なり、ブロックチェーンシステムは、共有台帳を更新するための共有プログラムを有する。
【0036】
一実施形態によれば、共有台帳を通してビジネスネットワークを調整する能力を用いて、ブロックチェーンネットワークは、信用および可視性を向上させつつ、個人情報および処理に関連付けられた時間、コスト、およびリスクを減少させることができる。
【0037】
ハイパーレッジャーファブリック
一実施形態によれば、ハイパーレッジャーファブリックは、他のブロックチェーン技術と同様に、台帳を有し、スマートコントラクトを使用する。また、ハイパーレッジャーファブリックは、参加者が自分のトランザクションを管理するシステムである。
【0038】
一実施形態によれば、ハイパーレッジャーファブリックが他のいくつかのブロックチェーンシステムと異なっているところは、それがプライベート用で許可型であるということである。いくつかのブロックチェーンネットワークがアイデンティティを検証するために使用する「プルーフ・オブ・ワーク」(それらの基準を満たす人は誰でもネットワークに加入できる)の代わりに、ハイパーレッジャーファブリックネットワークのメンバーは、メンバーシップサービスプロバイダを通して登録する。
【0039】
一実施形態によれば、ハイパーレッジャーファブリックはまた、いくつかのプラグ可能なオプションを提供する。台帳データは複数のフォーマットで格納可能であり、コンセンサスメカニズムはインおよびアウトに切替可能であり、異なるMSP(Membership Service Provider:メンバーシップサービスプロバイダ)がサポートされる。
【0040】
一実施形態によれば、ハイパーレッジャーファブリックはまた、チャネルを作成する能力を提供し、参加者のグループがトランザクションの別個の台帳を作成することを可能にする。これは、一部の参加者が競合企業かもしれず、自分が行なうトランザクション(たとえば、一部の参加者のみに提供している特別価格)のすべてを全参加者には知らせたくない場合に、ネットワークについてのオプションを可能にする。2人の参加者があるチャネルを形成する場合、それらの参加者のみがそのチャネルについての台帳のコピーを有する。
【0041】
共有台帳
一実施形態によれば、ハイパーレッジャーファブリックは、ワールドステートとトランザクションログという2つのコンポーネントを含む台帳サブシステムを有する。各参加者は、自分が属するすべてのハイパーレッジャーファブリックネットワークの台帳のコピーを有する。
【0042】
一実施形態によれば、ワールドステートコンポーネントは、所与の時点での台帳の状態を記述する。それは、台帳のデータベースである。トランザクションログコンポーネントは、ワールドステートの現在の値をもたらしたすべてのトランザクションを記録する。それは、ワールドステートのための更新履歴である。台帳はその場合、ワールドステートデータベースとトランザクションログ履歴との組合せである。
【0043】
一実施形態によれば、共有台帳は、ワールドステートのための取替可能なデータストアを有する。デフォルトにより、これは、LevelDBキー値ストアデータベースである。トラ
ンザクションログは、プラグ可能である必要がない。それは単に、ブロックチェーンネットワークによって使用される台帳データベースの事前および事後の値を記録する。
【0044】
スマートコントラクト
一実施形態によれば、ハイパーレッジャーファブリックスマートコントラクトはチェーンコードで書かれており、ブロックチェーンの外部のアプリケーションが台帳と対話する必要がある場合にそのアプリケーションによって呼び出される。多くの場合、チェーンコードは、台帳のデータベースコンポーネントであるワールドステートとのみ対話し(たとえば、それに問合せる)、トランザクションログとは対話しない。
【0045】
コンセンサス
一実施形態によれば、トランザクションは、たとえそれらがネットワーク内の参加者の異なる集合間で起こったものであっても、それらが起こった順序で台帳に書かれる。これが生じるために、トランザクションの順序が確立され、また、誤って(または悪意を持って)台帳に挿入された不良トランザクションを拒否するための方法が導入され得る。
【0046】
一実施形態によれば、ハイパーレッジャーファブリックは、ネットワークエンティティ(たとえば、ネットワークユーザ、ピア、スタータ)が、参加者間に存在する関係を最も良く表わすコンセンサスメカニズムを選択することを可能にする。プライバシーと同様に、それらの関係において高度に構造化されたネットワークから、よりピア・ツー・ピアであるネットワークまで、さまざまなニーズがある。
【0047】
チェーンコード
一実施形態によれば、チェーンコードは、資産と、資産を修正するためのトランザクション命令とを定義するソフトウェアを含み得る。それはビジネスロジックである。チェーンコードは、キー値ペアまたは他の状態データベース情報を読出すか変更するための規則を実施する。チェーンコード機能は、台帳の現在の状態データベースに対して実行され、トランザクション提案を通して始動される。チェーンコードの実行は、ネットワークに提出されてすべてのピア上の台帳に適用され得る1組のキー値書込み(書込みセット)をもたらす。
【0048】
台帳の特徴
一実施形態によれば、台帳は、ファブリックにおけるすべての状態トランザクションの、配列された改ざんされにくい記録である。状態トランザクションは、参加当事者によって提出されたチェーンコード呼び出し(「トランザクション」)の結果である。各トランザクションは、作成、更新、または削除として台帳にコミットされる1組の資産キー値ペアをもたらす。
【0049】
一実施形態によれば、台帳は、配列された不変の記録をブロックに格納するためのブロックチェーンと、現在のファブリック状態を保持するための状態データベースとから構成される。チャネルごとに1つの台帳があってもよく、各チャネルは、参加者の特定のグループに見えるトランザクションの別個の台帳を含む。各ピアは、それらがメンバーであるチャネルごとに台帳のコピーを保持する。
【0050】
チャネルを通したプライバシー
一実施形態によれば、ハイパーレッジャーファブリックは、チャネルごとの不変の台帳と、資産の現在の状態を操作し修正する(すなわち、キー値ペアを更新する)ことができるチェーンコードとを採用する。台帳はあるチャネルの範囲に存在し、それは(すべての参加者が1つの共通チャネル上で動作していると仮定すると)ネットワーク全体にわたって共有され得る。または、それは参加者の特定の集合のみを含むように私有化され得る。
【0051】
一実施形態によれば、後者のシナリオでは、そのような参加者は別個のチャネルを作成し、それにより、自分のトランザクションおよび台帳を隔離/分離することができる。全体透明性とプライバシーとの間のギャップを埋めたいシナリオを可能にするために、チェーンコードは、読出しおよび書込みを行なうために資産状態にアクセスする必要があるピアにのみインストールされ得る(たとえば、チェーンコードがあるピアにインストールされていない場合、台帳と適切にインターフェイス接続することはできないであろう)。データをさらに曖昧にするために、チェーンコード内の値を、台帳に付加する前に、AES(Advanced Encryption Standard:アドバンスト・エンクリプション・スタンダード)などの共通暗号アルゴリズムを使用して(部分的にまたは全体的に)暗号化することができ
る。
【0052】
セキュリティ&メンバーシップサービス
一実施形態によれば、ハイパーレッジャーファブリックは、すべての参加者がアイデンティティを知っているトランザクションネットワークを提供する。パブリックキーインフラストラクチャが、組織、ネットワークコンポーネント、およびエンドユーザまたはクライアントアプリケーションに結合される暗号証明書を生成するために使用される。その結果、データアクセス制御が、より広いネットワーク上で、およびチャネルレベルで操作され、管理され得る。ハイパーレッジャーファブリックのこの「許可型」の概念は、チャネルの存在および能力と組合されて、プライバシーおよび機密性が最重要課題であるシナリオに対処するのに役立つ。
【0053】
コンセンサス
一実施形態によれば、分散型台帳では、コンセンサスは、単にトランザクションの順序について同意すること以上のことを包含し得る。この差別化は、ハイパーレッジャーファブリックにおいて、提案および承認から順序付け、有効性確認、およびコミットメントまでのトランザクションフロー全体におけるその基本的役割を通して強調される。コンセンサスは、ブロックを含む1組のトランザクションの正確性の全面的検証として定義され得る。
【0054】
一実施形態によれば、コンセンサスは、ブロックのトランザクションの順序および結果が明示的なポリシー基準チェックを満たす場合に達成される。これらのチェックおよびバランスはトランザクションのライフサイクル中に行なわれ、どの特定のメンバーがあるトランザクションクラスを承認しなければならないかを指示するための承認ポリシーと、これらのポリシーが実施され支持されることを保証するシステムチェーンコードとの使用を含む。コミットメントに先立ち、ピアはこれらのシステムチェーンコードを採用して、十分な承認が存在すること、および、それらが適切なエンティティから生じたことを確認することができる。さらに、トランザクションを含むブロックが台帳に付加される前に、台帳の現在の状態が同意または承諾されるバージョニングチェックが行なわれ得る。この最終チェックは、データ完全性を損ない得る二重支払い動作や他の脅威に対する保護を提供し、機能が非静的変数に対して実行されることを可能にする。
【0055】
一実施形態によれば、行なわれた承認、有効性、およびバージョニングチェックに加えて、進行中のアイデンティティ検証もトランザクションフローにおいて生じている。アクセス制御リストがネットワークの階層上で実現され(チャネルへのオーダリングサービス)、また、トランザクション提案が異なるアーキテクチャコンポーネントを通過するにつれて、ペイロードが繰り返し署名され、検証され、認証される。コンセンサスはトランザクションのバッチの同意された順序に限定されておらず、むしろ、それは、提案からコミットメントまでのトランザクションのフロー中に行なわれる進行中の検証の副産物として達成されるプロセスである。
【0056】
ブロックチェーンクラウドサービス - アーキテクチャ
一実施形態によれば、クラウドシステム(たとえば、ブロックチェーンクラウドサービス(BCS))などのシステムは、上述のハイパーレッジャーファブリックを始点として利用することができる。そのようなシステムは、新しいブロックチェーンベースのアプリケーションの構築および/または既存のSaaS、PaaS、IaaSおよびオンプレミスアプリケーションの拡張を可能にする、極めて高度で差別化された企業グレードの分散型台帳クラウドプラットフォームを提供する。
【0057】
一実施形態によれば、システムは、スケーラビリティ、セキュリティ、頑強性、統合、
および性能といったミッションクリティカルな企業ニーズをサポートして、採択への障壁を取り除き、生産中のブロックチェーンアプリケーションをサポートすることができる。システムは、プラットフォーム・アズ・ア・サービス(PaaS)クラウドソリューションとしてBCSを提供することにより、ユーザがブロックチェーンをデプロイメントし、構成し、管理し、監視して、ブロックチェーンを企業にデプロイメントするためのコストを下げることを可能にする。システムはまた、ブロックチェーンアプリケーションの開発および他のプラットフォームとの統合を加速する。システムにより、SaaSクラウド顧客は、調達、支払い、貿易金融、会計、HR、CXのような自分の企業プロセスが、ブロックチェーンクラウドプラットフォームを使用して、第三者アプリケーションおよび外部分散型台帳技術とデータを安全に共有し、分散トランザクションを行なうことを可能にする。
【0058】
一実施形態によれば、システムは、PaaSマネージャ(たとえば、オラクルPaaSサービスマネージャ(PSM)プラットフォーム)に基づくクラウドサービスである。一般に、そのようなシステムは、計算空間(たとえば、外部計算空間)で実行される管理されたクラウドサービスである。実施形態では、システムは、オラクルアイデンティティクラウドサービス(IDCS)、オラクル・ロードバランサ・アズ・ア・サービス(LBaaS)、オラクルイベントハブクラウドサービス、およびオラクルクラウドストレージを使用して階層化されたコンテナランタイムサービス環境(Dockerまたはアプリケーションコンテナクラウドサービスなど)を含むPSMプラットフォームの特徴を利用する。各顧客ブロックチェーンはプロビジョニングされ、テナントとして実行され得る。システムは複数のブロックチェーンをサポートし、それらは各々、マルチテナント環境において別個のテナントとしてプロビジョニングされ、実行される。
【0059】
一実施形態によれば、したがって、システムは、アプリケーションまたは顧客アプリケーションが、それらのアプリケーションにとって必要なまたは望ましい程度スマートコントラクトを用いて分散型台帳を実現することを可能にする。そのようなシステムのクライアントおよびユーザは、クラウド(ブロックチェーン信用)の内部または外部にあってもよく、いくつかのブロックチェーンネットワークは、クラウド環境の外部のコンポーネントを含んでいてもよい(または、ある特定のクラウドに制約され得る)。
【0060】
一実施形態によれば、そのようなシステムは、特に信用およびアイデンティティの問題を解決すべき多当事者間トランザクションにおけるさまざまなアプリケーション機能にとって有用であり得る。他のブロックチェーンシステムとは異なり、提供されるシステムサービスは匿名のものではない。実際、アイデンティティおよび監査可能性は、基本的で総合的な要素である。したがって、BCSは、たとえば資本市場、国境を越えたトランザクション、金融サービス、資産トランザクション、法的調整アプリケーション、ヘルスケア記録、出版、物流、トレーサビリティ、および偽造防止においてアプリケーションを見つける。
【0061】
一実施形態によれば、上述のように、ブロックチェーン上の各当事者は、(台帳がある当事者にプロビジョニング/私有化されていない限り)データベース全体およびその完全な履歴へのアクセスを有する。どの単一の当事者も、データまたは情報を制御しない。すべての当事者はまた、そのトランザクションパートナーの記録を、仲介役を通さずに直接検証することができる。通信は、中央ノードを通る代わりに、ピア間で直接生じる。各ノードは、情報を格納し、他のすべてのノードに転送する。いったんトランザクションがデータベースに入力され、アカウントが更新されると、記録を変更することはできない。なぜなら、それらは、それらの前に生じたすべてのトランザクション記録にリンクされているためである(よって、「チェーン」という用語が使用される)。トランザクションにエラーがある場合、エラーを覆すために新しいトランザクションを使用しなければならず、
その場合、双方のトランザクションが、プロビジョニングされたユーザには見える。新しい有効トランザクションを追加するために、参加者はその有効性にコンセンサスメカニズムを介して同意することができる。ブロックチェーンにおける参加者は、資産がどこから生じたか、および、資産の所有権が時間とともにどのように変わってきたかを証明することができる。デジタル署名が、文書を認証するために使用可能であり、アクセス制御[さまざまなレベルの許可]およびプログラム可能性[実行可能なビジネス規則]に配置可能である。
【0062】
一実施形態によれば、多くの多当事者間トランザクションでは、ある当事者が資産またはサービスを受け取るとお金がやりとりされる。典型的にはトランザクション時間に起因して、どちらか一方の当事者が、他方の当事者よりも先に商品またはお金を委ねなければならない。いくつかの環境では、コントラクトにおける条件の完了までエスクローで資金を保持する仲介役を使用することによって、信用問題が解決される。これは、元々の当事者間の信用問題を解決する。しかしながら、そのような方法は、信頼されるべきもう一人の中心となる当事者を追加し、複雑性、およびおそらくはトランザクションのコストを増加させる。提供されるシステムの一部としてのスマートコントラクトの使用は、仲介役の必要性をなくすことができ、当事者は、仲介役を有することなく、信用されたトランザクションをブロックチェーン上で行なうことができる。
【0063】
一実施形態によれば、BCSなどの提供されるシステムの利点は、そこに含まれる情報が分散されているということを含む。監査可能性が利用可能でありながら、アクセスが制御され、ある程度のプライバシーが維持され得る。さらに、ブロックチェーン台帳は本質的に不変であり、否認できない。台帳は、ブロックのリストから構成される。各トランザクションブロックは、ブロックID、前のハッシュ、データハッシュ、タイムスタンプ、トランザクションIDリスト、アクション(1..n)、チェーンコードID、チェーンコード提案、応答(r/wセット、イベント、成功または失敗)、エンドーサを含む。各ブロックは前のハッシュとそれ自体のハッシュとを含むため、ブロックは本質的に順序付けられており、いったん知られる/分散されると不変である(注:現在のブロックのハッシュは、前のブロックのハッシュと現在のブロックにおける他のデータとのハッシュであり、よって、チェーンにおけるブロックをリンクする)。コンセンサスは、差異を解消することができる。集中化データベースまたは仲介役と比べて、中心となる機関に過度の権限を与える必要がない。台帳の分散される性質はまた、分散されるコピーの使用、およびコンセンサスが、(アルゴリズム的には可能な場合であっても)修正を難しくするという点で、ブロックチェーン記録技術の基本的不変性を増大させる。このため、トランザクションの順序付けを考慮すると、誰かがチェーンにおける最新のブロックのコピーを有する場合、台帳をハッキングすることはほぼ不可能である。
【0064】
いくつかの実施形態によれば、以下に説明されるように、提供されるシステムは、オラクルPaaSサービスマネージャ(PSM)プラットフォームに基づくことができ、ファブリックベースのブロックチェーンのプロビジョニング、監視、および構成を単純化/促進/自動化する管理コンソールを用いて増大される。加えて、単一のREST APIを含むRESTプロキシサービスが、アプリケーションとブロックチェーンファブリックとの接触を単純化するために提供される。開発者らはスマートコントラクトを構築し、管理コンソールを使用してスマートコントラクトをデプロイメントし、次に、アプリケーションにブロックチェーン上でスマートコントラクトを非同期的に(それはデフォルトである)または同期的に(即時の返答が望ましい場合)呼び出させることができる。RESTプロキシサービスおよびAPIは、プラットフォームの必要性に依存して、同期および非同期双方の能力を提供する。
【0065】
一実施形態によれば、ファブリックCAサーバは、ファブリックのためのメンバーシッ
プサービスを提供することができる。ファブリックCAサーバは、ユーザについての認証と、ブロックチェーン(ピアおよびオーダーのグループ)にアクセスするための認証と、アプリケーションクライアント、ピア、およびオーダーに証明書を配送できるCAサーバという3つの部分を含み得る。ファブリックCAは、認証および認可を実現するために証明書を利用することができる。証明書は、認証のための登録証明書と、認可のためのトランザクション証明書という2つのタイプを含む。一実施形態によれば、IDCSなどのアイデンティティサービスも、認証および認可を提供することができる。
【0066】
ハイパーレッジャーファブリック
上述のように、一実施形態では、提供されるシステムは、スマートコントラクトを実行するための分散型台帳プラットフォームを提供するハイパーレッジャーファブリックを実現することができる。ファブリックは、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。代替的な実施形態では、ブロックチェーンクラウドサービスは、たとえば、ここに引用により援用される、2016年5月31日に出願された「分散型台帳システムにおける説明責任および信用」(Accountability And Trust In Distributed Ledger Systems)と題された米国特許出願連続番号第15/169,622号(米国公報第2017/0236120号)に記載されるような「テンダーミント」(Tendermint)台帳システムを含む、代替的な分散型台帳プラットフォームを実現する。
【0067】
一実施形態によれば、ハイパーレッジャーファブリックの分散型台帳プロトコルは、ピアによって実行される。以前のブロックチェーン技術の1つの欠点は、すべてのピアがすべてのトランザクションを記録することを要求されるということである。これはかなりのI/Oおよびプロセッサオーバーヘッドを生み出し、企業グレードのシステムへと便利にスケール変更されない。ハイパーレッジャーファブリックは、2種類のピアを区別する。有効性確認ピアは、コンセンサスを実行し、トランザクションの有効性を確認し、台帳を維持することについて責任を負う、ネットワーク上のノードである。一方、非有効性確認ピアは、(トランザクションを発行する)クライアントを有効性確認ピアに接続するプロキシとして機能するノードである。非有効性確認ピアはトランザクションを実行しないが、それはトランザクションを検証してもよい。ピアのタイプ/機能の分離は、システムのスケーラビリティを向上させる。
【0068】
一実施形態によれば、ハイパーレッジャーの特徴は、チェーンコードと呼ばれる任意のスマートコントラクトを実行する、即時の最終性を有する許可型ブロックチェーンである。ユーザ定義のチェーンコードスマートコントラクトはコンテナ内にカプセル化され、システムチェーンコードはピアと同じプロセスで実行される。チェーンコードの実行はトランザクションの順序付けから区分されており、ノードタイプにわたる信用および有効性確認の要求されるレベルを制限し、ネットワークオーバーヘッドを減少させる。
【0069】
一実施形態によれば、ハイパーレッジャーファブリックにおけるチャネルは、共通ネットワーク上で資産を交換する競合ビジネスおよび規制産業によって必要とされる高度のプライバシーおよび機密性を有する多面的トランザクションを可能にする。不変の共有台帳は、チャネルごとに全トランザクション履歴を符号化しており、効率的な監査および論争解決のための問合せ能力を含む。台帳はあるチャネルの範囲に提供され、それは(すべての参加者が1つの共通チャネル上で動作していると仮定すると)ネットワーク全体にわたって共有され得る。または、それは1組の参加者のみを含むように私有化され得る。
【0070】
一実施形態によれば、ハイパーレッジャーファブリックは、TLS証明書、登録証明書、およびトランザクション証明書についての証明機関(certificate authority:CA)
へのサポートを通してセキュリティを実現する。パブリックキーインフラストラクチャが
、組織、ネットワークコンポーネント、およびエンドユーザまたはクライアントアプリケーションに結合される暗号証明書を生成するために使用される。その結果、データアクセス制御が、より広いネットワーク上で、およびチャネルレベルで操作され、管理され得る。ハイパーレッジャーファブリックのこの「許可型」の特徴は、チャネルの存在および能力と組合されて、多当事者間企業システムにおけるプライバシーおよび機密性の必要性を満たす。
【0071】
一実施形態によれば、ハイパーレッジャーファブリックは、チェーンコードトランザクションを使用して資産を修正する能力を提供する。上述のように、チェーンコードは、資産と、資産を修正するためのトランザクション命令とを定義するソフトウェアである。
【0072】
一実施形態によれば、総合的なコンセンサスメカニズムは、提案および承認から順序付け、有効性確認、およびコミットメントまでの、ハイパーレッジャーファブリックにおけるトランザクションフローにおける基本的役割を有する。コンセンサスは、上述のように、ブロックを含む1組のトランザクションの有効性の検証である。コンセンサスは究極的には、ブロックのトランザクションの順序および結果が明示的なポリシー基準チェックを満たす場合に達成される。
【0073】
図1Aは、ブロックチェーンサービスを提供するシステムのファブリックにおけるトランザクションフローを示す。より具体的には、この図は、一実施形態に従ったブロックチェーンクラウドサービス(BCS)システムを示す。1で、クライアント160が、ファブリックSDK162を使用して、登録のためにファブリック証明機関170、172、174にアクセスする。1.1で、ファブリックCAが、クライアント160に登録証明書を返す。2で、クライアント160は、ファブリックSDK162を使用してピアコンテナ180にアクセスし、エンドーサ182からの承認を要求する。2.1で、エンドーサ182は、署名されたRWセット(読出し/書込みセット)を返す。3で、クライアント160のファブリックSDK162は、RWセットとエンドーサの署名とを含む承認されたTX(トランザクション)を、オーダリングコンテナ190のオーダリングサービスに提出する。4で、オーダラー192が、ピアコンテナ180におけるコミッタ184にTXバッチを配送する。オーダラーは、トランザクションをブロックへと順序付ける、ノードの定義された集団である。オーダリングサービスはピアプロセスから独立して存在し、ネットワーク上の全チャネルについてトランザクションを先着順で順序付ける。5および5.1で、コミッタ184は、台帳186およびワールドステート188への変更を適用する。ファブリック証明機関170は、ピアコンテナ180、スマートコントラクトコンテナ166および168(スマートコントラクト)、ならびにオーダラー192について署名および認可の有効性を確認するために使用され得る。加えて、スマートコントラクト168はエンドーサ182と通信することができる。
【0074】
一実施形態では、システムは、オーダリングサービスとしてKafkaクラスタを利用する
ことができる。Kafkaとは、パブリッシュおよびサブスクライブ意味論をサポートする分
散ストリーミングサービスである。Kafkaクラスタは複数のサーバ上で実行され、記録の
ストリームをトピックと呼ばれるカテゴリーに格納する。各記録は、キー値とタイムスタンプとから構成される。Kafkaはこのため、オーダリングサービスノード(OSN-n)
とKafkaクラスタとを含むオーダリングサービスとして使用され得る。オーダリングサー
ビスクライアントは、複数のOSNに接続され得る。OSNは、互いに直接通信しない。これらのオーダリングサービスノード(OSN)は、(1)クライアント認証を行ない、(2)クライアントが単純なインターフェイスを使用してchain1に書込むことまたはそれから読出すことを可能にし、(3)それらはまた、既存のチェーンを再構成するかまたは新しいチェーンを作成する構成トランザクションのために、トランザクションフィルタリングおよび有効性確認を行なう。Kafkaにおけるメッセージ(記録)は、トピックパーテ
ィションに書込まれる。Kafkaクラスタは複数のトピックを有することができ、各トピッ
クは複数のパーティションを有することができる。各パーティションは、絶えず付加される、記録の順序付けられた不変の配列である。OSNがいったんクライアント認証およびトランザクションフィルタリングを行なうと、それらは、あるチェーンに属する着信クライアントトランザクションを、そのチェーンの対応するパーティションへ中継することができる。それらは次にそのパーティションを消費して、すべてのオーダリングサービスノードにわたって共通である、トランザクションの順序付けられたリストを再び入手することができる。
【0075】
一実施形態によれば、各ピアは、エンドーサおよびコミッタになる能力を有する。ピアがエンドーサになることを可能にし得る構成項目(たとえば、CORE_PEER_ENDORSER_ENABLED)がある。ピアがチャネルに加入すると、このピアはこのチャネルのコミッタになる。チェーンコードがピアにインストールされると、このピアはこのチェーンコードのための候補エンドーサになる。クライアントがトランザクションを提案すると、どのピアがエンドーサになるかを(候補エンドーサから)選択することは、クライアントの選択である。
【0076】
一実施形態によれば、オーダラーがブロックをピアに配送するためのオーダリングメカニズムは、以下のとおりである。まず、ピア(たとえばリーダーピア)が、そのバージョン(最後のブロック番号)を送信することによって、オーダラーからの新しいブロックの要求を配送する。次に、オーダラーはピアのバージョンをチェックし、a)それがオーダラーよりも大きい場合、ピアにエラーを返す。それは、オーダーにおける台帳が失われ、EventHubから復元できないことを示す(このシナリオでは、オーダラーは作業を適切に続けることができない)。b)ピアのバージョンがオーダラーよりも小さい場合、オーダラーはRAMまたはローカルファイルのいずれかにおけるローカル台帳からブロックを検索し、ピアに送り返す。または、c)それらが同じバージョンを有する場合、オーダラーは、新しいブロックが利用可能になるまでブロックする。EventHubから切断された新しいブロックデータが準備できると、オーダラーはそれをローカルブロックファイルまたはRAMに入れるであろう。次に、配送スレッドがこのブロックを台帳から読出してそれをピアに送り返す。ピアはこのブロックを入手し、それをローカル台帳にコミットし、次に、その最新バージョンを他のピアへブロードキャストすることができる。
【0077】
BCSシステムアーキテクチャ
図1Bは、ブロックチェーンサービスを提供するシステムのファブリックにおけるトランザクションフローを示す。より具体的には、この図は、一実施形態に従ったブロックチェーンクラウドサービス(BCS)システムを示す。図示されるように、ブロックチェーンクラウドサービスコンポーネントは、たとえばオラクルPaaSサービスマネージャ(PSM)プラットフォーム上にある計算空間120(たとえば、外部計算空間)にプロビジョニングされる。システムへのアクセスは、PSM API122およびブロックチェーンREST API124によって仲介される。外部計算120は、利用可能な適切なリソースにわたって着信トランザクションを分散させるために、ロード・バランシング・アズ・ア・サービスLBaaS126を活用する。
【0078】
一実施形態によれば、BCSは、コンテナランタイムサービス環境(Dockerまたはアプリケーションコンテナクラウドサービスなど)128上に、PSMプラットフォームを用いて構築されたアプリケーションコンテナ階層化サービスである。BCSエンティティの各々は、別個のコンテナ上で実行される。BCSエンティティの各々は、コンテナランタイムサービスに対して1対1対応である。ブロックチェーンクラウドサービスは、上述のハイパーレッジャーファブリックの特徴を実現する。基本的なファブリックネットワークを構築するコンポーネントに加えて、いくつかのコンポーネントが、ハイパーレッジャーファブリックをブロックチェーンクラウドサービスに活用するために開発されている。こ
れらのコンポーネントは、これらのコンポーネントをデプロイメントするために別々のデプロイメント挙動およびバイナリを必要とする。クラウドスタックマネージャは、設計図によって定義されたすべてのサービスの、スタックと呼ばれる単一ユニットとしてのプロビジョニングを自動化する権限をユーザに与えるために使用され得る。
【0079】
一実施形態によれば、BCSは、スマートコントラクトを実行するための分散型台帳プラットフォームの実現化例である、ハイパーレッジャーファブリックの実現化例を提供する。BCSは、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。
【0080】
一実施形態によれば、ファブリックの分散型台帳プロトコルは、ピアによって実行される。ファブリックは、2種類のピアを区別する。有効性確認ピアは、コンセンサスを実行し、トランザクションの有効性を確認し、台帳を維持することについて責任を負う、ネットワーク上のノードである。一方、非有効性確認ピアは、(トランザクションを発行する)クライアントを有効性確認ピアに接続するプロキシとして機能するノードである。非有効性確認ピアはトランザクションを実行しないが、それはトランザクションを検証してもよい。ファブリックリリースのいくつかの主な特徴は、チェーンコードと呼ばれる任意のスマートコントラクトを実行する、即時の最終性を有する許可型ブロックチェーンを含む。ユーザ定義のチェーンコードスマートコントラクトはコンテナ内にカプセル化され、システムチェーンコードはピアと同じプロセスで実行される。ファブリックは、TLS証明書、登録証明書、およびトランザクション証明書についての証明機関(CA)へのサポートを通して、コンセンサスプロトコルおよびセキュリティを実現する。
【0081】
一実施形態によれば、BCSエンティティは、コンテナランタイムサービス128を有する階層状コンテナインスタンスにおいて実行される。コンテナは、PSMの動作をプロビジョニングすることによって作成および/または起動される。ファブリックCAコンテナ130は、BCSファブリックCA(証明機関)コンポーネントが提供されるコンテナである。BCSピア(コンテナ)132は、読出し/書込み動作を台帳コンポーネントに行なうために台帳を保持し、チェーンコードコンテナを実行するBCSピアネットワークエンティティが実行されているコンテナである。BCSオーダリングコンテナ134は、トランザクションを全チャネル用のブロックチェーンへと順序付けるサービスを提供するBCSオーダラーが実行されているコンテナである。BCSチェーンコード実行コンテナ139は、ピアエンティティによって作成され起動されるコンテナである。このコンテナでは、チェーンコード実行ユニットが親ピアエンティティと通信して、ブロックチェーンにおける資産を修正するために資産およびトランザクション命令の符号化を行なう。
【0082】
一実施形態によれば、BCSチェーンコードビルダーコンテナ140は、ピアエンティティによって作成され起動されるコンテナである。このコンテナでは、チェーンコード構築環境がインストールされてデプロイメントされ、チェーンコード実行ユニットがそこに構築される。クライアント側ファブリックSDK106が、BCSにアクセスするための機能性を提供する。ブロックチェーンクラウドサービスはまた、イベントハブクラウドサービス150、クラウドストレージサービス152、およびアイデンティティサービス154を活用する。オラクルストレージクラウドサービスは、BCSのためのストレージサービスとして使用される。
【0083】
一実施形態によれば、Docker/Weave141は、コンテナサービスである。コンテナは
、共有のオペレーティングシステム上で分離されて実行可能なフォーマットでソフトウェアをパッケージ化するやり方を提供する。VMとは異なり、コンテナはオペレーティングシステム全体をバンドルせず、代わりに、ソフトウェアを働かせるために必要なライブラリおよび設定を使用することが必要とされる。これは効率的で軽量の自給式システムを生
み出し、ソフトウェアがどこにデプロイメントされているかにかかわらず常に同じように実行されることを保証する。
【0084】
一実施形態によれば、各BCSインスタンスは、異なるタイプのノードから構成される。BCSインスタンスには、少数(たとえば0またはそれ以上)~複数のピアノードがあり得る。BCSインスタンスには、少数(たとえば0)~複数のオーダラーノードがあり得る。BCSインスタンスには、1~複数のファブリックCAノードが、VMごとに1つある。BCSゲートウェイについては、BCSインスタンスには、少数(たとえば0)~複数のBCSゲートウェイがあり得る。BCSコンソールも、BCSインスタンスのコンポーネントである。BCSインスタンスには、BCSコンソールが1つだけある。
【0085】
一実施形態によれば、BCS管理サーバ(コンソール)136はBCSのコンポーネントであり、それは、以下により詳細に説明されるように、豊富な監視、管理、およびビュー機能性をBCSスタックインスタンスに提供する。BCSゲートウェイ(RESTプロキシ)138はBCSの新しいコンポーネントであり、REST APIインターフェイスを顧客/クライアントに提供し、以下により詳細に説明されるようなトランザクションを行なうためにファブリックにアクセスするために使用される。
【0086】
一実施形態によれば、パブリックアクセスクライアント側100で、PSMコンソールUI102は、プラットフォームサービスマネージャの管理を可能にする。BCSコンソールUI104は、BCS管理サーバの制御を可能にする。ファブリックSDKクライアント106、BCS RESTクライアント108、およびファブリックメンバーシップクライアント110を含む、さまざまな異なるクライアントタイプが、BCSサービスにアクセスすることができる。
【0087】
一実施形態によれば、個々のサービスタイプとして上にリストされたコンテナタイプごとに、設計図を定義することができる。オラクルクラウドスタックマネージャは、これらの設計図を使用して、すべての個々のサービスタイプの単一スタックユニットへのプロビジョニングを自動化する。BCSエンティティごとにサービスタイプを定義する利点は、実行中のさまざまなエンティティのアップグレードおよび維持が簡単であることである。コンテナランタイムサービス階層化サービスは、CREATE_SERVICE、DELETE_SERVICE、SCALE_SERVICE、および起動/停止/再起動という4つのタイプの動作をサポートする。これ
らの動作は、サービスごとに適用され得る。
【0088】
一実施形態によれば、ハイパーレッジャーファブリックでは、オーダリングサービスコンポーネントはApache Kafkaを使用して、クラッシュ故障に耐性のある態様で複数のチェーンのためのオーダリングサービスおよびサポートを提供する。したがって、BCSクラウドサービスでは、オーダリングサービスコンポーネントは、OEHCS(管理されたストリーミングデータプラットフォームとしてKafkaのパワーを配送し、オラクルのクラウ
ドの残りと統合され得る、オラクルイベントハブクラウドサービス)を使用するであろう。
【0089】
図1Cは、一実施形態に従ったBCSシステムを示す。より具体的には、この図はBCSランタイムを示す。
【0090】
一実施形態によれば、ゲートウェイベースのアプリケーション103および/またはファブリックベースのアプリケーション105などのクライアントは、インターネット107などのネットワークを介して、および、(以下に述べる)CloudGateを含み得るロード
バランサLBaaS126などのフロントエンドを介して、コンテナランタイムサービスインスタンス128と通信することができる。着信コールは、REST通信(図において
より濃い破線として示す)、または、状況によっては、着信gRPC通信(図においてより薄い破線として示す)を含み得る。着信REST通信は、(REST API/RESTプロキシを含み得る)ゲートウェイ138、(上述のように)コンソール136、またはエージェントファブリックCA130へ向けられ得る。ここで内部コール(gRPC)に変換されたREST通信は、(エージェント/ピア132、エージェント/オーダラー134、チェーンコード142、およびチェーンコードビルダー140を含む)ブロックチェーンファブリック/ハイパーレッジャーのインスタンスとインターフェイス接続可能である。一方、着信gRPC通信は、ブロックチェーン/ハイパーレッジャーとインターフェイス接続するために、たとえばエージェント/ピア132およびエージェント/オーダラー134に直接送信され得る。
【0091】
一実施形態によれば、コンテナランタイムサービスインスタンス内のトランザクションがいったん生じると、コンテナランタイムサービスインスタンスは、たとえば、REST通信を介してクラウドストレージで台帳を持続させることができ、または、同様にREST通信を介してイベントハブと通信することができる。
【0092】
一実施形態によれば、図にはコンテナランタイムサービスインスタンスが1つしか示されていないものの、クライアント(ゲートウェイベースのアプリケーション103および/またはファブリックベースのアプリケーション105など)が説明されたBCSランタイムを介して通信することができる、1つまたは複数のコンテナランタイムサービスインスタンスが存在し得るということを、当業者であれば容易に理解するであろう。
【0093】
図1Dは、一実施形態に従ったBCSシステムを示す。より特定的は、この図は、BCSシステム内のコンポーネント濃度、すなわち、各BCSインスタンスに対するコンポーネントの比率を示す。
【0094】
一実施形態によれば、BCSインスタンス100aごとに、オーダラー101aは1:Nの比率で提供可能であり、ファブリックCAメンバーシップ102aは1:Nの比率で提供可能であり、BCS RESTプロキシ103aは1:Nの比率で提供可能であり、BCSコンソール104aは1:1の比率で提供可能であり、ピアコンテナ105aは1:Nの比率で存在可能である。
【0095】
一実施形態によれば、各ピアコンテナは、トランザクションをシミュレートできるエンドーサと、同様にピアコンテナで提供される台帳への変更を適用できるコミッタとを含み得る。
【0096】
一実施形態によれば、チェーンコード109aは、ピアコンテナに対して1:Nの比率で提供可能である。加えて、ストレージ106aは、ピアコンテナおよびオーダラーに対してN:1の比率で提供可能である。また、イベントハブ107aは、ピアコンテナおよびオーダラーに対してN:1の比率で提供可能である。IDCS108aは、ファブリックCAメンバーシップに対してN:1の比率で提供可能である。
【0097】
図1Eは、一実施形態に従った、ブロックチェーンクラウドサービスのためのインターフェイスを提供するための方法のフローチャートである。
【0098】
一実施形態によれば、ステップ175で、方法は、少なくとも1つのプロセッサを含むコンピュータで、コンテナランタイムサービスの少なくとも1つのインスタンスと、コンテナランタイムサービスの少なくとも1つのインスタンスにおける分散型台帳コンポーネントとを提供することができ、分散型台帳はブロックチェーンクラウドサービスとしてプロビジョニングされ、ブロックチェーンクラウドサービスは、ピアコンテナと、オーダリ
ングコンテナと、チェーンコードコンテナとを含む。
【0099】
一実施形態によれば、ステップ176で、方法は、ピアコンテナによってブロックチェーン台帳を保持することができる。
【0100】
一実施形態によれば、ステップ177で、方法は、オーダリングコンテナによってブロックチェーン台帳内のトランザクションを順序付けることができる。
【0101】
一実施形態によれば、ステップ178で、方法は、チェーンコードコンテナのチェーンコード実行ユニットによって台帳における資産を符号化することができる。
【0102】
一実施形態によれば、ステップ179で、方法は、クライアントアプリケーションから着信コールを受信するように、コンテナランタイムサービスの少なくとも1つのインスタンスを構成することができ、着信コールはブロックチェーン台帳へのエントリを要求する。
【0103】
ブロックチェーンクラウドサービス(BCS)ゲートウェイ
一実施形態によれば、BCSゲートウェイ(BCSGW)は、ファブリックネットワークと通信するためにファブリックSDKを使用するネットワークノードを含む。BCSゲートウェイは、クライアント/クライアントアプリケーションがBCSのファブリックの要素と対話することを可能にするHTTPS RESTful APIを、クライアント側で顧客に提供する。
【0104】
図2は、一実施形態に従った、ブロックチェーンクラウドサービスシステムのためのゲートウェイを示す。
図2に示すように、エンドユーザ200は、HTTPSを使用して、認証および認可のためにアプリケーションアダプタ202と対話する。アプリケーションアダプタ202は、CloudGate212(すなわち、LBaaS)などのLBaaSへのH
TTPSを使用して、パブリッククラウド210にアクセスする。ロード・バランシング・アズ・ア・サービス(LBaaS)は、着信トランザクションのために行なわれる。CloudGate212は、HTTPSを使用して、トランザクションをBCSゲートウェイ22
2へ渡す。BCSゲートウェイは、通信がgRPCリモートプロシージャコールプロトコルを利用するBCSファブリック220へのインターフェイスを提供する。
【0105】
一実施形態によれば、CloudGate212は、たとえばOAuth2およびOpenID Connect規格
を使用してウェブブラウザおよびREST APIリソースを安全にする、リバースプロキシ「アクセス実施モジュール」または「ポリシー実施ポイント」である。IDCSは、CloudGateを内部で使用して、それ自体の管理UIおよびREST APIを安全にする
(「IDCSウェブ層」と呼ばれる)。他のアプリケーションについては、クラウドゲート:OTDが、非IDCSまたはスタンドアロンとして公知である、半分サポートされた/暫定的な設定において、追加のインスタンスとしてデプロイメントされる。
【0106】
一実施形態によれば、OAuth/OpenIDベースの認証は、(UIクライアントのための)
ユーザブラウザフローをサポートし、それは、HTTP要求が「ユーザ-エージェント」ヘッダを含む場合、すなわち、その要求がブラウザまたはモバイルアプリのようなUIからのものである場合にトリガされる。CloudGateは、クレデンシャル(ユーザ名/パスワ
ード)についてユーザを促し、クレデンシャルを検証し、次に、OAuthセッションクッキ
ーを作成して返す。OAuthセッションクッキーは、ブラウザからのその後のHTTP要求
によって使用され得る。OAuth/OpenIDベースの認証はまた、(プログラマティッククラ
イアントのための)リソースサーバフローをサポートする。このフローは、HTTP要求が認証「ベアラ」トークンヘッダを含む場合にトリガされる。CloudGateは、認証のため
にトークンの有効性を確認する。
【0107】
一実施形態によれば、HTTP基本認証のために、HTTP要求ごとに、クレデンシャル(ユーザ名/パスワード)がHTTP認可「基本」ヘッダに含まれていなければならない。クラウドゲートは、HTTP要求ごとにクレデンシャルを検証する。この方法は、UIクライアントおよびプログラマティッククライアント双方に当てはまる。
【0108】
一実施形態によれば、マルチトークンフローは、あるHTTP要求をカバーする自己適応可能な方法である。HTTP要求が認可「基本」ヘッダを含む場合、CloudGateはHT
TP基本挙動を行なう。HTTP要求が認可「ベアラ」ヘッダを含む場合、クラウドゲートは、リソースサーバフローと同様に挙動する。
【0109】
一実施形態では、BCSコンソールブラウザクライアントは、ユーザブラウザフローを利用する。実施形態では、BCSコンソールおよびゲートウェイプログラマティッククライアントのために、システムは、CloudGateマルチトークン認証方法を使用することがで
きる。プログラマティッククライアントは、HTTP基本認証を介してBCS REST
APIを呼び出すことができる。
【0110】
一実施形態によれば、BCSゲートウェイ222はピア224と通信する。ピア224は、台帳を保持するとともに、台帳に読出し/書込み動作を行なうためにチェーンコードコンテナを実行する、ネットワークエンティティである。ピアは、メンバーによって所有され、保持される。BCSゲートウェイ222およびピア224は、オーダラー226と通信する。オーダラーは、オーダリングサービスを提供する。オーダラーは、トランザクションをブロックへと順序付ける、ノードの定義された集団である。オーダリングサービスはピアプロセスから独立して存在し、ネットワーク上の全チャネルについてトランザクションを先着順で順序付ける。ピア224およびオーダラー226は、ファブリック証明機関228と通信する。BCSゲートウェイ222はまた、BCS管理サーバ/コンソール230へのアクセスを提供する。
【0111】
一実施形態によれば、BCSは、オラクルクラウドなどのクラウドシステムにデプロイメントされる。ゲートウェイは、コンテナランタイムサービスコンテナにおいて実行され得る。ゲートウェイはステートレスである。ゲートウェイは、古いゲートウェイを止めて新しいゲートウェイを起動することによって更新され得る。BCSゲートウェイは、RESTfulプロトコルによって、顧客問合せを可能にするかまたはファブリックチェーンコードを呼び出すことができる。BCSゲートウェイは、クライアントがHTTPS/RESTfulサービスによってオラクルクラウドにおけるファブリックネットワークにアクセスすることを可能にする。BCSゲートウェイは、ファブリックネットワークと通信するためにファブリックSDKを使用するネットワークノードである。ファブリック内の通信は、通信プロトコルとしてgRPCを使用する。クライアント側で、BCSゲートウェイは、HTTPS/RESTful APIを顧客に提供する。REST APIは、クライアントがファブリックSDKを使用してファブリック内の機能を呼び出すことを可能にする。
【0112】
一実施形態によれば、ゲートウェイは、ファブリックユーザと1対1の関係で提供され得る。すべてのゲートウェイユーザは1つの組織に属し、すべてのゲートウェイユーザは、1つのゲートウェイにおいて1つのファブリックユーザにマッピングされる。1つのゲートウェイは、たった1つのファブリックユーザを構成する。
【0113】
一実施形態によれば、IDCSは、ゲートウェイ証明書およびゲートウェイユーザ(「アプリアダプタ」)証明書を発行する。これらの証明書は、組織CAによって署名される
。ゲートウェイおよびゲートウェイユーザは組織CAによってデプロイメント可能であり、そのため、それらはHTTPSを使用して互いに有効性を確認してもよい。
【0114】
一実施形態によれば、各エンドユーザは、「アプリアダプタ」を通してBCSGWにアクセスする。認証には3段階ある。エンドユーザ200は、アプリアダプタ202によって認証され得る。アプリアダプタ202は、クライアント証明書を用いてBCSゲートウェイ222によって認証され得る。BCSゲートウェイは、ファブリックネットワーク220におけるピア224およびオーダラー226によって認証され得る。
【0115】
一実施形態によれば、1つのコンテナは1つのtomcatサーバを実行し、1つのBCSゲートウェイをデプロイメントし、1つのファブリックユーザにマッピングされる。複数のアプリアダプタが1つのゲートウェイに接続してもよい。
【0116】
一実施形態によれば、異なるゲートウェイが異なるファブリックユーザに関連付けられ得る。1つのゲートウェイに接続するアプリアダプタのエンドユーザらは、1つのファブリックユーザにマッピングされることができる。
【0117】
一実施形態によれば、BCSGWはオラクルクラウドにおいて実行され、構成がJSONファイルを使用してBCSコンソールによって設定される。Adminユーザは、ピア、チ
ャネル、およびチェーンコードの一部をゲートウェイへ発行してもよい。Adminユーザは
、コンソールによってゲートウェイを起動する。ゲートウェイは、ブート後に構成をリフレッシュしない。Adminユーザは、チェーンコードのためにエンドーサを設定することが
できる。ポリシーはエンドユーザには不明瞭であり、ゲートウェイはチェーンコードポリシーをチェックしない。
【0118】
一実施形態によれば、BCSGWはBCSコンソールによって起動される。BCSコンソールはBCSGW構成ファイルを作成し、BCSGWパッケージを使用して、新しいゲートウェイを起動する。起動時、起動スクリプトがBCSGW構成ファイルをチェックし、Tomcatのために構成ファイル(たとえば、Tomcat構成ファイル)を修正し、次にTomcatを起動する。TomcatはBCSGWのためのスレッドを起動し、スレッドはチャネルごとに構成ファイルを読み、それはチャネルオブジェクトを起動して、オーダー、ピア、イベントハブとの接続を作成することができる。異なるチャネルは、オーダー/ピア/イベントハブとの異なる接続を有するであろう。ここでのイベントハブは、ピアの第2のポートである。ゲートウェイは、トランザクションの結果を入手するために、このポートに接続する。Tomcatサーブレットコンテナは、クライアント要求をリッスンして待つことができる。チェーンコードの問合せ方法については、BCSGWはチャネルのすべてのピアに要求を送信し、最初の結果のみを使用する。チェーンコードの呼び出し方法については、BCSGWはチャネルのすべてのエンドーサに要求を送信し、それらのうちの1つが成功を返した場合、BCSGWはチャネルのすべてのオーダラーにトランザクションを送信する。
【0119】
一実施形態によれば、非同期APIがサポートされる。ピアは2つのポートを開くことができ、1つのポートはイベント交換用である。ゲートウェイは、ピアのイベントポートに接続できる。ゲートウェイは、1つのチャネルについて1つのイベントポートに接続するだけでよい。通常のクライアントAPIは同期的である。トランザクションには数秒かかる場合があり、クライアントは応答を待つ必要がある。クライアントに非同期イベントを送信することは、V1プランにはない。同期トランザクションAPIに加えて、ゲートウェイは、非同期トランザクションAPI「asyncinvoke」を提供する。
【0120】
一実施形態では、非同期APIはこのように作動できる。クライアント要求のパラメータをチェックした後で、ゲートウェイはクライアントにトランザクションIDを返すであ
ろう。クライアントは、トランザクションが起動されたものの終わっていないことを認識できる。ゲートウェイは、トランザクションを処理し続けるために、バックグラウンドスレッドを起動するであろう。クライアントは、終わっていないトランザクションを追跡することができる。ゲートウェイは、クライアントがトランザクションIDを使用してトランザクションステータスを問合せるための「トランザクション」APIを提供することができる。
【0121】
一実施形態によれば、クライアントログインがサポートされ得る。BCSGWはHTTPSプロトコルをサポートすることができ、安全でないHTTPアクセスを許可できない。BCSGWは、アプリアダプタまたはSALTを信用するために証明書を使用する。アプリアダプタは、エンドユーザを認証することができる。Tomcatは、HTTPSクライアント証明書認証を使用するために設定される必要がある。keystoreファイルは、クライアントがBCSコンソールによって提供されることの有効性を確認するために、BCSGWcertとCAcertとを含む。BCSゲートウェイは、クライアントアクセスのためのBCS
RESTインターフェイスを提供する。
【0122】
持続性 - ストレージクラウド
一実施形態によれば、ハイパーレッジャーファブリックは、ローカルファイルシステムに格納されている台帳と、同様にローカルファイルシステムに格納されるLevelDBに格納
されているブロックインデックス、ワールドステート、履歴、および台帳プロバイダのような他のランタイムデータとのブロックを有する。コンテナランタイムサービスでは、コンテナファイルシステムは一時的である。すなわち、何らかのハードウェア故障に起因してコンテナが停止され、新しいコンテナが新しいVM上で再起動される場合、ファイルシステムコンテンツが失われるおそれがある。コンテナがすべて失われる状況を考慮すると、その場合、台帳を復元する方法はない。そのため、台帳データは、コンテナランタイムサービスコンテナの外部で格納されなければならない。このため、持続性ソリューションが、上述のハイパーレッジャーファブリックのコンポーネントによって使用されるオブジェクトストレージサービスの形でプロビジョニングされる。
【0123】
一実施形態によれば、したがってBCSでは、持続性ソリューションは、ストレージクラウドサービス、たとえばオラクルストレージクラウドサービスを利用する。台帳は、オブジェクトストアへバックアップされる。台帳はコンテナファイルシステムへの書込みだけでなく、オブジェクトストレージへのバックアップをブロックする。インデックスおよびワールドステートはコンテナファイルシステムを使用して記録されるが、コンテナが再起動される場合にはストレージクラウドサービスから復元されてもよい。オラクルストレージクラウドはインフラストラクチャ・アズ・ア・サービス(Infrastructure as a Service:IaaS)製品であり、それは、ファイルおよび非構造化データのための、企業グ
レードの大規模なオブジェクトストレージソリューションを提供する。
【0124】
図3は、一実施形態に従った、ブロックチェーンクラウドサービスシステムのための持続性を示す。
図3に示すように、コンテナランタイムサービスインスタンス300は複数のコンテナを含む。コンテナは、たとえば、台帳/ブロックチェーン312および314を有するオーダリングコンテナ302および304を含む。台帳/ブロックチェーン312および314は、RESTインターフェイスを通してオブジェクトストレージ320へバックアップされる。オブジェクトストレージ320は、たとえばクラウドストレージサービスであってもよい。
【0125】
一実施形態によれば、オブジェクトストレージは、各オーダラーの台帳を持続させるために使用される。オーダラーがブロックをピアに配送するための現在のメカニズムは、以下のとおりである。まず、ピアが、そのバージョン(最後のブロック番号)を送信するこ
とによって、オーダラーからの新しいブロックの要求を配送する。次に、オーダラーはピアのバージョンをチェックし、a)それがオーダラーよりも大きい場合、ピアにエラーを返す。それは、オーダーにおける台帳が失われ、EventHubから復元できないことを示す。このシナリオでは、オーダラーは作業を適切に続けることができない。b)ピアのバージョンがオーダラーよりも小さい場合、オーダラーはRAMまたはローカルファイルのいずれかにおけるローカル台帳からブロックを検索し、ピアに送り返す。c)それらが同じバージョンを有する場合、オーダラーは、新しいブロックが利用可能になるまでブロックする。EventHubから切断された新しいブロックデータが準備できると、オーダラーはそれをローカルブロックファイルまたはRAMに入れるであろう。次に、配送スレッドがこのブロックを台帳から読出してそれをピアに送り返す。最後に、ピアはこのブロックを入手し、それをローカル台帳にコミットする。次に、台帳の最新バージョンが他のピアへブロードキャストされ得る。
【0126】
一実施形態によれば、上述のプロセスに従って、オーダラーまたはEventHubのいずれかは、ブロック全体を持続させることができる。上述のように、EventHubは、時間が制限された保存を有する。EventHubがそれをすることができる場合、オーダラーは台帳タイプをRAMまたはファイルに設定することができ、いったんオーダラーが再起動されて台帳が失われると、それはEventHubから記録を再生してバッチメッセージをブロックへと切断することができ、次に、台帳を再構築することができる。EventHubが制限された保存期間のみをサポートする場合、いったんオーダラーが再起動されて台帳が失われると、それは台帳を正確に再構築することができない。なぜなら、EventHubにおける最初の記録が台帳における真の記録ではないためである。このシナリオでは、オーダラーは古いチャネルを起動することができない。なぜなら、チャネル情報を有する最初のブロックが失われ、バージョン番号(最後のブロック番号)も正しくないためである。
【0127】
一実施形態によれば、その場合、各オーダラーは各ブロックをオラクルストレージまで持続させ、一方、すべてのチャネルIDをストレージにおけるオブジェクトに保存することもできる。ピア上では、ジェネシスブロックのみを持続させる。なぜなら、それはチャネル情報を有するためである。他のブロックデータについては、ピアは、いったんそれが失われると、それをオーダラーから検索することができる。
【0128】
一実施形態によれば、コンテナランタイムサービスインスタンス300はまた、台帳316、318とインデックス326、328とを含むピアコンテナ306、308を含み得る。ピアによって生成されるランタイムデータには、トランザクションログ(ブロックファイル)、ブロックファイルインデックス(LevelDB)、台帳プロバイダ(LevelDB)、状態データベース(LevelDBまたはcouchdb)、履歴(LevelDB)という5つのタイプがあ
る。すべてのトランザクションデータは、ローカルファイルにおけるリンクしたブロックとしてトランザクションログに格納され、それはオラクルストレージクラウドサービスまで持続されなければならない。台帳プロバイダDBは、すべての台帳IDおよび復元ステータスをLevelDBに保存する。台帳IDは、ピアが属するチャネルを識別するための固有
のidである。それはオラクルストレージクラウドサービスまで持続されなければならない。他については、ピアはそれをランタイムに自動的に復元し、そのためそれらをローカルファイルシステムに保存することができる。
【0129】
一実施形態によれば、オラクルストレージクラウドサービスは、ファイルをオブジェクトにアップロード/オブジェクトからダウンロードするためのREST APIを提供する。新しいブロックが生成されると、まず、それは前述のようにローカルブロックファイルに書込まれるであろう。違いは、ファイルごとに1つのブロックである。次に、このブロックファイルはオブジェクトとしてオラクルストレージにアップロードされるであろう。それが失敗した場合、ローカルファイルにおける変更はロールバックであり、エラーが
呼び出し元に返されるであろう。
【0130】
一実施形態によれば、ブロックファイルインデックスについては、オーダラーが最新のチェックポイントを更新すると、まず情報をオラクルストレージまで持続させることができ、次にローカルLevelDBを更新する。動作が失敗した場合、エラーが呼び出し元に返さ
れ得る。この情報は、ブロックファイルインデックスについての復元のために使用されるであろう。オラクルストレージでは、各ピアおよびオーダラーは、msp idとノードidとの組合せである固有のコンテナ名を有する。オブジェクト名は、チャネル名が前に付いたブロックファイルの名前である。より詳細については、オラクルストレージにおける命名規則を参照されたい。
【0131】
一実施形態によれば、台帳プロバイダDBをオラクルストレージに保存するオプションが提供され得る。台帳プロバイダDBについては、LevelDB全体が、それがいったん更新
されるとオラクルストレージクラウドサービスに複製され得る。このファイルは非常に小さく、また、更新は頻繁ではないため、複製上のオーバーヘッドは無視され得る。コンテナが再起動されると、それは、それがオラクルストレージクラウドサービスに存在する場合、そこからダウンロードすることができる。オーダラーが新しいコンテナから再起動される場合、それはまず、ストレージオブジェクトからチャネルidをダウンロードし、次に、チャネルidによってストレージから最新のチェックポイントを入手するであろう。次に、最初のブロックから最後のブロックまで復元ブロックインデックスを起動する。この期間中、ブロックファイルは1つずつダウンロードされるであろう。その後、オーダラーは状態DBおよび履歴DBを復元するために起動する。ピアが新しいコンテナから再起動される場合、それはまず、台帳プロバイダDBを最初にダウンロードするであろう。それから、それはすべての台帳idを入手することができる。次に、台帳idによってストレージから関連ジェネシスブロックを入手する。ピアはジェネシスブロックにおける構成を起動し、オーダラーに問合せを配送して、他のブロックデータを入手する。ピアがこれらのブロックを入手した後で、それは、ブロックインデックス、状態DBおよび履歴DBを復元するために起動する。
【0132】
一実施形態によれば、ローカルブロックファイルは、読出しキャッシュとして作用する。問合せはまず、ローカルからデータを読出すであろう。それが存在しない場合には、オブジェクトストレージからダウンロードするであろう。台帳に加えて、チェーンコードのソースコードをオラクルストレージまで持続させる必要がある。現在のファブリックでは、チェーンコードがインストールされた後で、符号化されたソースコードがピアに格納されるであろう。ピアは、各呼び出しまたはインスタンス化ごとにチェーンコードコンテナをチェックするであろう。コンテナが存在しない場合、ピアはそれをソースコードから再構築するであろう。そのため、それは、チェーンコードのインストールごとにそれをオラクルストレージにアップロードし、ピアがディスク故障から再起動されるとそれをダウンロードすることができる。
【0133】
BCS:SDKベースの構成ファイル動作およびプロビジョニング後のデプロイメント
一実施形態によれば、構成ファイルおよびデプロイメント機能は、アプリケーションをデプロイメントまたは更新する場合、ピア、オーダラー、CAサーバ、およびチェーンコードを含むアプリケーションについての構成をデプロイメントし、生成開始し、更新し、入手する。これらの機能は、(Node.jsにおける)BCSコンソール、およびファブリッ
クコンテナ(ピア/オーダラー/チェーンコードコンテナ)の双方に存在する。これらの機能は、UIから要求されるように構成を入手/更新し、SDK APIを呼び出して、必要な場合に構成変更をアクティブにするであろう。BCSコンソールバックエンドの一部としてのコンポーネントが、BCSコンソールUI、IDCSバックエンドSDK、およびすべてのBCSアプリケーションと対話して、UI動作のためのSDKを提供し、要
求されるような構成を入手/更新する。コンポーネントはまた、BCSアプリケーションをプロビジョニングするのにも役立つ。BCSプロビジョンコンポーネントは、PSMを使用して作成されたVMのDockerコンテナへBCSアプリケーションをデプロイメントするであろう。この特徴は、BCSコンソールUIのためのSDK APIを実現するであろう。そして、BCSプロビジョンコンポーネントは、プロビジョニング後の段階でBCSアプリケーション構成およびデプロイメントを入手または更新する。プロビジョニング後の段階では、プロビジョニングシステムは、Docker/Swarm下で、CAサーバ、オーダ
ラー、ピアなどのBCSアプリケーションをデプロイメントするであろう。VMが起動すると、それは、プロビジョニング後の作業およびVMの最初の作業を行なうために起動スクリプトを呼び出すであろう。
【0134】
一実施形態によれば、ピア、オーダラー、ファブリックCA、およびBCSゲートウェイを含むファブリックコンポーネントのために構成ファイルが提供される。BCSアプリケーションパッケージ、構成、チェーンコードは、顧客のストレージクラウドサービスに格納される。
【0135】
一実施形態によれば、プロビジョンシステムは、すべてのリソース割当てを完了すべきである。リソースは、VM、ネットワーク、およびストレージを含む。
【0136】
一実施形態によれば、プロビジョンシステムは、すべてのリソース割当て情報をストレージサービスに保存すべきである。この情報は、VM番号およびそれらのネットワークアドレス/アカウントクレデンシャル、各VMにおけるBCSアプリケーション番号およびそれらのタイプ、パブリックIPおよび内部IPを含む。そして、コンテナのための(VM間でアクセス可能な)内部IPアドレスも十分あるべきである。
【0137】
一実施形態によれば、BCSプロビジョンコンポーネントがプロビジョン作業を済ませると、VM起動スクリプトが起動し、次に、swarmを呼び出してコンテナランタイムサー
ビスをデプロイメントし、そしてコンテナの内部でコンテナstartup.shスクリプトが起動し、開始動作を行なうであろう。
【0138】
一実施形態によれば、BCSコンソールは起動時、ストレージサービスから構成を入手し、UIからのユーザ動作の入力をストレージサービスに保存し、次に、再起動コマンドをswarmに送信するであろう。
【0139】
一実施形態によれば、必要とされるセキュリティ証明書をIDCSに保存することができる。それに代えて、セキュリティ証明書をIDCSから検索することができる。
【0140】
一実施形態によれば、BCSコンソールバックエンドは、swarmを用いてBCSアプリ
ケーションと通信することができる。
【0141】
一実施形態によれば、BCSコンテナランタイムサービスが起動すると、BCSアプリケーションは、構成詳細を集めてそのアプリケーションタイプ(ピアまたはチェーンコードコンテナまたはその他)を決定し、次に、必要とされる構成をロードすることができる。
【0142】
一実施形態によれば、このコンポーネントは構成を更新し、BCSアプリケーション起動シェルコードを提供する。BCSが構成ファイルを入手/更新する動作は、いくつかの部分に分割され得る。まず、BCSコンソールは起動時、ストレージから構成を入手し、更新が必要な場合に構成をBCSコンソールからストレージに保存するであろう(シェルおよびNode.js)。BCSコンテナランタイムサービスが起動すると、(各Dockerコンテ
ナにおける)起動スクリプトがまず起動し、次に、そのアプリケーションタイについての構成を入手し、IDCS(シェル)からアプリcertを入手する。BCSコンソールUIがBCSアプリケーションを再起動すると、それは、コンテナにおいてそのアプリケーションを再起動するよう、Docker/Swarmにメッセージを送信する。
【0143】
一実施形態によれば、BCSコンソールはステートレスであり、起動されるとすべてのBCSインスタンス構成を集めることができ、BCSアプリケーションに接続してそれらを監視する。構成は、ストレージサービスからバックエンドAPIを介して取得されるであろう。いずれかの構成が変化すると、BCSコンソールはバックエンドAPIを呼び出して、構成をストレージサービスに保存し、関連するアプリケーションを再起動するであろう。顧客がBCSコンソールUIを介して構成項目を変更した場合、UIは構成をキー/値データに符号化し、バックエンドコードはそれをファイルに変換してストレージサービスに保存するであろう。BCSコンソールは、BCSアプリケーションを監視し、起動し、停止することができる。起動コマンドおよび停止コマンドは、この機能を実現するためにDocker/SwarmAPIを使用する。
【0144】
ファブリックネットワークのデプロイメント
一実施形態によれば、ファブリックネットワークは、ピア、クライアント、オーダリングサービス、および、これらのエンティティ間の通信を容易にする1組のプロトコルというエンティティを含む。組織は、ファブリックネットワークのステークホルダーを構成する論理エンティティまたは団体である。ファブリックネットワークは複数の参加組織を有する。メンバーは、ネットワークのための固有のルート証明書を所有する、法的に別個のエンティティである。ピアノードおよびアプリケーションクライアントなどのネットワークコンポーネントは、メンバーにリンクされるであろう。各組織は、1人以上のメンバーを有していてもよい。1つの組織は、オーダラーおよびピアの双方、またはオーダラーのみ、またはピアのみをもたらし得る。
【0145】
一実施形態によれば、ファブリックネットワークをデプロイメントする際の最初のステップは、参加者を定義することである。このステップは、ファブリックネットワークの帯域外で行なわれる。ファブリックネットワークのすべての参加組織は、たとえば、どの組織がオーダラーノードをもたらすか、およびどの組織がピアノードをもたらすかを含むネットワークの構成を取り決めて完結させる。オーダラーノードをもたらすすべての組織は、そのオーダラーサーバのためのルート証明書を発行する。ピアノードをもたらすすべての組織は、そのピアサーバのためのルート証明書を発行する。クライアントを有するすべての組織は、そのクライアントのためのルート証明書を発行する。クライアントは、1つの組織においてピアから異なるメンバーまで分離され得る。
【0146】
一実施形態によれば、一例として、4つの銀行(bank1、bank2、bank3、およびbank4)が、bank1およびbank2が所有するオーダラーノードを含むオーダリングサービスを使用してブロックチェーンネットワークをデプロイメントすることを決定したとする。そして、bank1は、このネットワークにおいて唯一、オーダラーをもたらすためのものである。各
銀行は、ファブリックネットワークの組織である。bank1は、オーダラー(root_cert_1)という1人のメンバーを有する。bank2は、クライアント(root_cert_21)、ピア(root_cert22)、オーダー(root_cert23)という3人のメンバーを有する。bank3は、クライアント(root_cert31)、ピア(root_cert32)という2人のメンバーを有する。bank4は、
クライアント(root_cert41)、ピア(root_cert42)という2人のメンバーを有する。
【0147】
一実施形態によれば、参加者を定義後、オーダラーおよびピアのために証明書が生成される。各オーダラーまたはピアは、それ自体を識別するために(プライベートキー、署名証明書)のペアを必要とする。各メンバーは、そのルート証明書を用いてそれ自体のファ
ブリックCAサーバを構成して起動し、CLIまたはSDKを使用して、CAサーバに、このメンバーのオーダラー/ピアサーバごとに(プライベートキー、署名証明書)を生成するよう要求することができる。BCSは、証明書を提供できるファブリックCAサーバを提供する。しかしながら、ファブリックCAサーバは、証明書を生成する唯一のアプローチではない。ユーザは、同じことをするために他のCAシステムを使用することができる。そのため、ファブリックCAサーバは、ファブリックネットワークにおける必須のコンポーネントではない。
【0148】
一実施形態によれば、オーダラーおよびピアのための証明書を生成後、ファブリックネットワークは、システムチャネルを作成することによってブートストラップされる。オーダリングサービスのための(ひいては1つのファブリックネットワークのための)システムチャネルはちょうど1つあり、それは、作成される(より正確にはブートストラップされる)べき最初のチャネルである。システムチャネルは、ファブリックネットワークの構成を定義する:
●1つのオーダリングサービス
○1つ以上のオーダラー組織。各orgの
・MSP ID
・Cert
・オーダリングサービス属性(たとえば、タイプ-ソロまたはKafka、オーダラー
アドレス、バッチサイズ/タイムアウト)
・ポリシー(だれがチャネルを作成できるか、など)
●1つ以上のコンソーシアム。各コンソーシアムは以下を含む
○1つ以上のピア組織。このファブリックネットワークに参加したいどのピア組織も、コンソーシアムのうちの1つにおいてここに定義されなければならない。各orgの
・MSP ID
・Cert
・アンカーピア。
【0149】
一実施形態によれば、ファブリックネットワークシステムチャネルがブートストラップされた後で、そのシステムチャネルのためにジェネシスブロックが作成される(チェーンにおける最初のブロック)。オーダラーサービスアドミニストレータは、そのシステムチャネルのためにジェネシスブロックを生成する。ジェネシスブロックは、ツールconfigtxgenによって(genesismethod=file)、またはオーダラー起動中に(genesismethod=provisional)生成され得る。configtxgenツールを使用してジェネシスブロックを生成する
場合、構成ファイルconfigtx.yamlが入力として構成され得る。このファイルは、以下の
情報を含む:ファブリックネットワークにおけるすべてのオーダラー組織のルート証明書;すべてのピア組織のルート証明書;オーダリングサービス属性:orderertype、アドレ
ス、batchtimeout、batchsize、kafka;ポリシー;チャネルリーダ:チャネル配送要求の認証および有効性確認;チャネルライタ:チャネルブロードキャスト要求の認証および有効性確認;チェーンクリエータ:チェーン作成要求の評価;Admin:チャネル再構成要求
の認証および有効性確認。
【0150】
一実施形態によれば、オーダラーサービスアドミニストレータは、構成ファイルおよびジェネシスブロックを用いてオーダラーサーバを起動する。これは、ジェネシスブロックを使用してシステムチャネルを作成する。オーダラーサーバ:リッスンアドレス/ポート、ledgertypeなど;LocalMSP(プライベートキー、署名証明書)を起動するために、構成ファイルorderer.yamlが必要とされる。オーダリングサービスを提供する各組織は、そのオーダラーサーバを起動する(ジェネシスブロックは特定されるべきでない)。
【0151】
一実施形態によれば、ピアノードをもたらす各組織は、ピアを識別するためのLocalMSP
(プライベートキー、署名証明書);およびピア属性:リッスンアドレス/ポート、ブートストラップピア、ゴシップ属性などを特定するために、ピアごとに構成ファイル(デフォルト場所/etc/hyperledger/fabric/core.yaml)を準備する。そして次に、ピアサーバ
を起動する。
【0152】
一実施形態によれば、オーダラーおよびピアが起動された後で、(チャネルを作成する特権を有する)チャネルアドミニストレータは、ファブリックCLIまたはSDKを使用して、オーダラーに、(システムチャネルで定義されたはずの)1つのコンソーシアムとそのコンソーシアムにおける1つ以上のピアorgという入力を用いてチャネルを作成する
よう要求する。各参加組織は、ファブリックCLIまたはSDKを使用して、そのピアのいくつかを新しく作成されたチャネルに加入させる。
【0153】
例:BCS上のファブリックネットワークのデプロイメント
図4は、BCS上のファブリックの例示的なデプロイメントを示す。
【0154】
一実施形態によれば、より特定的には、この図および説明は、BCSにファブリックネットワークをデプロイメントするためのステップを説明する。この例では、4つのエンティティA、B、C、およびDが、ファブリックネットワークを作成してそれに加入することを望んでいる。4つのエンティティはオフラインで話し合い、さまざまなエンティティの責任を決定する。各エンティティは、OPC上に1つ以上のBCSインスタンスを作成する。
【0155】
一実施形態によれば、エンティティAはオーダラーおよびピアの双方を提供する。エンティティAは、オーダラーのためのOrderer_Org1 401と、ピアのためのPeer_Org1
421という2つのインスタンスを作成する。エンティティAはまた、ファブリックネットワークを作成することについて責任を負う(注:オーダラーのみがファブリックネットワークを作成できる)。オーダリングサービス400は、Orderer_Org1 401およびOrderer_Org2 402と、Kafkaクラスタ410とを含む。
【0156】
一実施形態によれば、エンティティBはオーダラーおよびピアの双方を提供する。エンティティBは、オーダラーのためのOrderer_Org2 402と、ピアのためのPeer_Org2
422という2つのインスタンスを作成する。
【0157】
一実施形態によれば、エンティティCはピアのみを提供する。エンティティCは、インスタンスPeer_Org3 423を作成する。
【0158】
一実施形態によれば、エンティティDはピアのみを提供する。エンティティDは、インスタンスPeer_Org4 424を作成する。
【0159】
一実施形態によれば、各BCSインスタンスのアドミニストレータは、現在のorgのC
A証明書およびadmin証明書をBCSコンソールから収集する。各ピアorgのアドミニストレータは、現在のorgのアンカーピアを識別し、アンカーピアのIP/ポートを収集する
。4つのエンティティは、収集されたすべての情報をオフラインで互いに交換する。
【0160】
一実施形態によれば、Orderer_Org1のアドミニストレータは、前のステップで収集された情報である各orgのCA証明書およびadmin証明書と各ピアorgのアンカーピアとを用い
てシステムチャネルを作成することによって、BCSコンソールからファブリックネットワークを作成する。バックエンド作業は、ジェネシスブロックを作成するためにファブリックツールを呼び出すことと、ジェネシスブロックを使用してシステムチャネルを作成するためにオーダラーを構成することとを含み得る。
【0161】
一実施形態によれば、各ピアorgのアドミニストレータは、収集された他のorgのCA/admin証明書を追加するためにすべてのピアノードの構成を更新し、すべてのピアノード
を再起動することによって、BCSコンソールからファブリックネットワークに加入する。
【0162】
一実施形態によれば、システムで、新しいorgが既存のファブリックネットワークに加
入することを可能にするための方法が提供される。さらに、ファブリックネットワークを作成/ファブリックネットワークに加入するために、たとえば、ファブリックの形成に先立ってオフラインのアクションをカバーするために、参加者間の通信を容易にするためのユーザフレンドリーな方法が提供され得る。
【0163】
チェーンコード(スマートコントラクト)コンテナ
一実施形態によれば、および上述のように、チェーンコードは、資産と、資産を修正するためのトランザクション命令とを定義するソフトウェアである。チェーンコードは、キー値ペアまたは他の状態データベース情報を読出すか変更するための規則を実施する。チェーンコード機能は、台帳の現在の状態データベースに対して実行され、トランザクション提案を通して始動される。チェーンコードの実行は、ネットワークに提出されてすべてのピア上の台帳に適用され得る1組のキー値書込み(書込みセット)をもたらす。
【0164】
一実施形態によれば、情報の一貫した更新をサポートするために、および、多くの台帳機能(取引する、問合せるなど)を可能にするために、ブロックチェーンネットワークは、スマートコントラクトを使用して、台帳への制御されたアクセスを提供する。スマートコントラクトは情報をカプセル化し、それをファブリックにわたって自動的に複製することができ、それらはまた、参加者がトランザクションのある局面を自動的に実行できるようにするように書かれることもできる。
【0165】
一実施形態によれば、ハイパーレッジャーファブリックスマートコントラクトはチェーンコードで書かれており、ブロックチェーンの外部のアプリケーションが台帳と対話する必要がある場合にそのアプリケーションによって呼び出される。多くの場合、チェーンコードは、台帳のデータベースコンポーネントであるワールドステートとのみ対話し(たとえば、それに問合せる)、トランザクションログとは対話しない。
【0166】
一実施形態によれば、ハイパーレッジャーファブリックはDockerエンジンを利用してチェーンコードを構築し、それをデプロイメントし、それを実行されたままにする。このセクションは、ファブリックアーキテクチャと、それがBCSのためのコンテナランタイムサービス階層化モデルにどのように統合されるかとについて説明する。
【0167】
一実施形態によれば、ファブリックは、以下のようにユーザチェーンコードをデプロイメントし、管理する。第1に、チェーンコードを一時的CCenvコンテナに構築する。第
2に、チェーンコードはソースコードとしてビルダーコンテナに転送され、静的にリンクされた必要なライブラリを用いてコンパイルされ(「Javaビルド」)、次に、バイナリがピアに送り返される。静的リンクは、実際のチェーンコードコンテナができるだけ小さくなることを可能にする。第3に、チェーンコード画像およびコンテナを構築し、それを起動する。チェーンコードコンテナは次に、ピアがシャットダウンされるかチャネルが終了されるまで実行されたままとなる。チェーンコードコンテナがクラッシュするかまたは止めた場合、画像が存在するならば、それは次の呼び出しで再起動される。設計は、ピアおよびチャネルごとに1つのチェーンコードDockerコンテナを有することである。チェーンコードはピアに明示的にインストールされる。すなわち、チャネルに加入するすべてのピアにチェーンコードが必ずインストールされているとは限らない。
【0168】
一実施形態によれば、ユーザは、ピア、オーダラー、およびチェーンコードなどのコンポーネントを透過的に分散させる能力を有するコンテナランタイムサービス階層状コンテナに、ファブリックネットワークをデプロイメントすることができる。ローカルブロックストレージは信頼できる復元方法とは考えられないため、ACLSコンテナチェーンコードバイナリがクラウドストレージに保存されると、チェーンコードランタイム環境コンテナ(ccenv)は動的に起動されるであろう。いったん構築されると、チェーンコードバイ
ナリは、コンテナクラッシュの場合に復元する目的のためにクラウドストレージにアップロードされるであろう。
【0169】
一実施形態によれば、各チェーンコードインタラクションは、チェーンコードのさまざまな機能に対応することができる。唯一の制約は、チェーンコードがインスタンス化されるまでそれを呼び出したりそれに問合せることができないということである。加えて、呼び出し時、チェーンコードコンテナは、それが実行中だと判明しなければ再起動される。
【0170】
図5は、一実施形態に従ったチェーンコードアーキテクチャを示す。より具体的には、この図は、一実施形態に従って、クライアント530がコンテナランタイムサービス環境500においてチェーンコードをインストールし、トランザクションを実行することを可能にする、チェーンコードアーキテクチャを示す。ステップ1で、クライアント530はチェーンコードソースコードをピア1 510にインストールする。第1に、チェーンコードを一時的CCenvコンテナに構築する。クライアント530が「インストール」を行
なうと、それは、ビルダーエージェントを自動的に起動するビルダーコンテナを起動し、ビルダーコンテナが初期化を終えるのを待ち、チェーンコードソースコードをピアを介してビルダーコンテナに送信するであろう(ステップ2)。ビルダーエージェントが、チェーンコードを構築するであろう(Javaビルド)。チェーンコードはソースコードとしてビルダーコンテナに転送され、静的にリンクされた必要なライブラリを用いてコンパイルされ(「Javaビルド」)、次に、バイナリがピアに送り返される。静的リンクは、実際のチェーンコードコンテナができるだけ小さくなることを可能にする。いったん構築されると、チェーンコードパッケージ(tgzファイル)が、クラウドストレージ560にアップロ
ードされるであろう(ステップ3)。ビルダーエージェントは、後で参照するために、クラウドストレージの場所をピアに送信するであろう(ステップ4.2)。
【0171】
一実施形態によれば、ピア510は次に、PSM REST APIを使用して、CCenvをACLS(アクセス制御リスト)コンテナ520として起動するであろう。チェー
ンコード画像およびコンテナを構築し、それを起動する。チェーンコードコンテナは次に、ピアがシャットダウンされるかチャネルが終了されるまで実行されたままとなる。ピア510は、チェーンコードID、(チェーンコード登録のための)自己IP、およびクラウドストレージの場所を、起動のためにACLSコンテナに渡すであろう(ステップ4.1)。ピアは、チェーンコードが起動するのを、または設定時間の後でタイムアウトするのを待つであろう。ccenvはチェーンコードを起動するであろう。起動時、チェーンコー
ドはそれ自体をピアに登録するであろう(ステップ4.3)。チェーンコードは、トランザクションにおける呼び出しのための準備ができるであろう(ステップ5)。それは、登録時に確立された接続を使用して行なわれるであろう。
【0172】
一実施形態によれば、ビルダーコンテナ550は、単純なRESTタイプサーバを含む。ビルダーコンテナ550は、ビルダーエージェント553を含む。ビルダーコンテナ550は起動して、チェーンコード構築要求をリッスンする。ビルダーコンテナ550が構築要求、たとえば本体としてbase64符号化ソースコードを有するPOSTコールを受信すると、それはソースコードをbase64復号化し、チェーンコードソースコードをローカルファイルシステムに保存する。ビルダーエージェント553は次に、ソースコード上で「Ja
vaビルド」を行なう。「Javaビルド」が成功した場合、ビルダーエージェント553はバイナリをパッケージ化してクラウドストレージ560にアップロードする。ビルダーエージェントはまた、チェーンコードの場所をピアに返す。「Javaビルド」が失敗した場合、エージェントはエラーおよび理由をピアに返す。
【0173】
BCS管理コンソール
一実施形態によれば、上述のように、BCSの各インスタンスは管理コンソールを含むことができ、それは、BCSゲートウェイ、BCSノード、およびBCSチャネルを含むBCSインスタンスを管理し、監視するために使用され得る。
【0174】
一実施形態によれば、管理コンソールコンポーネントは、BCSのプロビジョニング、監視、および構成を容易にし、自動化する。管理コンソールコンポーネントは、スクリプトランタイム環境、たとえばNode.jsにおいて実行されるウェブアプリケーションを含み
得る。ウェブアプリケーションは、グラフィカルユーザインターフェイスフレームワークおよびウェブフレームワーク上に構築可能であり、BCSインスタンスにおけるさまざまなノードまたはサービスと通信するための複数のカスタム機能またはAPIを含み得る。ウェブアプリケーションは、BCSインスタンスにおけるさまざまなノードまたはサービスからの情報を、コンソールユーザインターフェイスでの表示のために、ビューオブジェクトにポピュレートすることができる。管理コンソールコンポーネントはまた、アドミニストレータがBCSインスタンスにおける1つ以上のノードを起動、停止、および更新するための複数の機能を提供することができる。ウェブアプリケーションによって提供されるものと同じ機能をサポートするために、1組の管理REST APIが、スクリプトランタイム環境によって提供され、またはスクリプトランタイム環境によってアクセスされ得る。
【0175】
一実施形態によれば、システムは、ウェブアプリケーションによって提供されるウェブインターフェイスを通して、または、管理REST APIの集合を使用して書かれたカスタムRESTクライアントアプリケーションを通して、関連付けられたBCSインスタンスの監視および管理を容易にすることができる。
【0176】
一実施形態によれば、管理コンソールは、1つ以上のピアノード、1つ以上のオーダラーノード、1つ以上のファブリックCAノード、1つ以上のBCSゲートウェイノード、チャネル、および1つ以上のチェーンコードを含むBCSインスタンスの複数のコンポーネントを、BCSアドミニストレータが管理できるようにすることができる。
【0177】
一実施形態によれば、BCSコンポーネントを管理することは、コンポーネントを起動すること、コンポーネントを停止すること、コンポーネントを追加すること、コンポーネントを除去すること、コンポーネントの属性を見る/編集すること、コンポーネントの性能メトリックを見ること、および、コンポーネントのログを見ることという動作のうちの1つ以上を行なうことを含み得る。
【0178】
図6は、一実施形態に従った、管理コンソールを提供するためのシステムを示す。
一実施形態によれば、図に示すように、BCS管理コンソール136は、コンテナランタイムサービス128におけるBCSインスタンスのコンポーネントとして提供され得る。BCS管理コンソールは、Node.jsによって提供されるランタイム環境を表わし得るス
クリプトランタイム環境605において実行されるウェブアプリケーションであり得る。
【0179】
一実施形態によれば、管理コンソールは、複数のバックエンドAPI610、たとえば、ファブリックノードサービス開発キット(SDK)611、複数のファブリックカスタム機能/API613、および複数のコンテナランタイムサービスAPI615を含み得
る。SDK、カスタム機能/API、およびコンテナランタイムサービスAPIは、分散ストリーミングサービス(たとえばKafka)603を含み得るファブリックネットワーク
601と通信するために使用され得る。管理コンソールはさらに、ビューオブジェクト623を含み得る。ビューオブジェクト623は、BCSコンソールUI104またはRESTクライアント604に表示される必要のある情報を含み、もしくは、BCSコンソールUIまたはRESTクライアントから管理コンソールに渡される必要のある情報を含み得る。ファブリックノードSDK621は、ファブリックネットワークからの情報と、BCSコンソールUIまたはRESTクライアントからの情報とをマッピングするように動作することができる。
【0180】
一実施形態によれば、BCS管理コンソールは複数のクライアントAPI622を含み得る。それらは、BCSクラウドサービスをプロビジョニングし、プロビジョニングされたBCSクラウドサービスを管理するために、BCSコンソールUIまたはRESTクライアントによって使用され得る。プロビジョニングされたBCSクラウドサービスを管理することは、ピアノード、オーダラーノード、ファブリックCAノード、およびBCSゲートウェイノードを起動および停止することと、ピアノード、オーダラーノード、およびBCSゲートウェイノードを追加および除去することとを含み得る。
【0181】
一実施形態によれば、BCS管理コンソールはさらに、GUIフレームワーク(たとえばJET)617と、ウェブフレームワーク(たとえばExpress)619とを含み得る。
GUIフレームワークは、管理コンソールウェブアプリケーションにおいて使用され得るさまざまなユーザインターフェイス(user interface:UI)コンポーネントおよび要素を提供することができる。たとえば、UIコンポーネントおよび要素は、フォームを作成し、データを収集し、データを視覚化するために使用され得る。ウェブフレームワークはJavaScript(登録商標)で書くことができ、ウェブアプリケーションおよびモバイルアプリケーションを開発するために、頑強な一組の特徴を含むウェブアプリケーションフレームワークを提供することができる。
【0182】
図7A~7Bは、一実施形態に従った、BCSコンソールUIにおけるユーザインターフェイスの例を示す。
【0183】
一実施形態によれば、
図7Aに示すように、BCSサマリー711がダッシュボードに表示され得る。サマリーは、組織の数、ピアの数、オーダラーの数、チャネルの数、およびチェーンコードの数を含み得る。
【0184】
一実施形態によれば、BCSインスタンスの健全性情報713が表示され得る。健全性情報は、視覚的に表示され、数値的に表示され得る。サンプルUIはまた、トランザクション実行714と台帳サマリー715とを表示することができる。
【0185】
一実施形態によれば、
図7Bは、BCSインスタンスにおけるすべてのノードについての情報を示す。たとえば、サンプルUIは、(BCSゲートウェイノード内の)2つのピア、1つのオーダー、1つのファブリックCA、および1つのRESTプロキシを含む、合計5つのノードを示す。ノードごとに、サマリーUI717は、ノードの名前723、ノードのルート情報725、ノードのタイプ729、およびノードのステータス情報731を表示する。サンプルUIは、アドミニストレータがノードを追加するためのボタン721と、ノードをフィルタリングするための1つ以上のドロップダウンリスト719とを含む。
【0186】
ノード管理
一実施形態によれば、管理コンソールを使用してBCSインスタンスを管理することが
できるエンティティは2つあり得る。それらは、BCSアドミニストレータおよびBCSユーザである。BCSアドミニストレータアカウントは、BCSインスタンスごとに1つだけある。BCSアドミニストレータアカウントは、BCSインスタンスが作成されると作成され得る。BCSアドミニストレータは、ファブリックCAアドミニストレータとバンドルされ得る(すなわち、BCSアドミニストレータがBCSコンソールから、またはBCS管理REST APIを介して行なうアクションはすべて、ファブリックCAアドミニストレータアイデンティティを使用する)。BCSユーザアカウントは2つ以上あってもよく、それらは、ファブリックCAアイデンティティを登録することによってBCSアドミニストレータによって作成され得る。
【0187】
一実施形態によれば、BCSインスタンスにおけるノードは、1つのウェブページに表示され得る。管理コンソールは2つのモードをサポートすることができる。第1のモードでは、各ノードの名前、タイプ、アクセスURL、およびステータスが、リストとしてを提示され得る。第2のモードでは、各ピアが参加しているチャネルが図表で提示され得る。
【0188】
さらに、一実施形態によれば、管理コンソールは、BCSアドミニストレータが、ピアノード、オーダラーノード、ファブリックCAノード、およびBCSゲートウェイノードを起動および停止することと、ピアノード、オーダラーノード、およびBCSゲートウェイノードを追加および除去することとを可能にすることができる。ファブリックCAノードを追加または除去することはできない。
【0189】
一実施形態によれば、ノードを追加する場合、BCSアドミニストレータは、そのノードの属性を設定することができる。新しく追加されるノードは、追加動作の一部として自動的に起動され得る。ノードが除去される場合、そのノードは停止され、BCSインスタンスから除去される。
【0190】
一実施形態によれば、BCSコンソールUIは、アクティブなピアノードが参加しているすべてのチャネルと、アクティブなピアノードにインストールされたすべてのチェーンコードとをリストすることができる。
【0191】
一実施形態によれば、ピアノードを管理する場合、BCSアドミニストレータはアクティブなピアノードを既存のチャネルに加入させること、およびアクティブなオーダラーノードの属性を見て編集することができる。BCSユーザは、アクティブなピアノードの属性のうちのいくつかを見ることができる。
【0192】
一実施形態によれば、さらに、メモリ使用量、使用されるCPUパーセンテージ、ネットワークI/O、およびディスクI/Oといった、アクティブなピアノードについてのスナップショット性能メトリックが、BCSコンソールUIに表示され得る。
【0193】
一実施形態によれば、オーダラーノードを管理する場合、BCSアドミニストレータは、アクティブなオーダラーノードのログを見ること、アクティブなオーダラーノードの属性を見て編集することができる。BCSユーザは、アクティブなピアノードの属性のうちのいくつかを見ることができる。ピアノードの管理と同様に、BCSアドミニストレータは、メモリ使用量、使用されるCPUパーセンテージ、ネットワークI/O、およびディスクI/Oといった、アクティブなオーダラーノードについてのスナップショット性能メトリックを見ることができる。
【0194】
一実施形態によれば、ファブリックCAノードを管理する場合、BCSアドミニストレータは、アクティブなファブリックCAノードの属性を見て編集すること、アクティブな
ファブリックCAノードからCA証明書を入手すること、および、アクティブなファブリックCAノードのログを見ることができる。さらに、BCSアドミニストレータは、メモリ使用量、使用されるCPUパーセンテージ、ネットワークI/O、およびディスクI/Oといった、アクティブなファブリックノードの性能メトリックを見ることができる。
【0195】
一実施形態によれば、上述のように、BCSゲートウェイノードを管理することは、BCSゲートウェイノードを追加すること、またはさらに除去することを含み得る。許容されるBCSゲートウェイノードの最大数は、特定のBCSインスタンスがインスタンス化される時に指定されるため、BCSインスタンスに追加され得るBCSゲートウェイノードの数は、BCSゲートウェイの構成された最大許容数によって制限される。
【0196】
一実施形態によれば、各BCSゲートウェイノードは、ゲートウェイノードのグローバルに固有のアイデンティティである名前を有し得る。名前は、将来BCSゲートウェイノードが構成される場合に参照され得る。ネットワークアドレスも、BCSゲートウェイノードを作成する場合に判断され、表示され得る。
【0197】
一実施形態によれば、BCSゲートウェイノードを構成する場合、BCSアドミニストレータはBCSゲートウェイ構成ファイルを定義し、BCSゲートウェイノードをブートストラップすることができる。BCSインスタンスがプロビジョニングされている場合、作成されるチャネルまたはデプロイメントされるチェーンコードがないかもしれない。そのため、1つ以上のチェーンコードがデプロイメントされ、有効なBCSゲートウェイ構成が管理コンソールを通して定義されるまで、BCSゲートウェイノードは機能的ではない。
【0198】
一実施形態によれば、BCSゲートウェイノードごとに構成ページがあり得る。ある実施形態では、以下の項目が構成ページで構成され得る:
1)チャネル:現在のゲートウェイノードを通してどのチャネルを露出すべきかを選択する;
2)チェーンコード:各チャネルにおけるすべてのインスタンス化チェーンコードのリストから、どのインスタンス化チェーンコードを露出すべきかを選択する;
3)エンドーサ:チェーンコードごとに、承認ピアを定義する;
4)上述の設定に従ってBCSゲートウェイ構成を生成する。有効な構成ファイルがBCSゲートウェイのためにいったん生成されると、ゲートウェイは起動され得る。
【0199】
一実施形態によれば、BCSコンソールは、リストビュー機能を使用してBCSゲートウェイ特性のビューを可能にする。リストビューでは、BCSゲートウェイごとに以下の情報が提供される:
1)名前:ゲートウェイ作成時に指定されたグローバルな固有の名前;
2)ファブリックアイデンティティ名:各BCSゲートウェイは、BCSゲートウェイ作成時に登録されるファブリッククライアントアイデンティティに関連付けられ得る。BCSゲートウェイが行なうアクション(たとえば、呼び出し、問合せ)はすべて、このファブリッククライアントとして命名され得る;
3)ネットワークアドレス:パブリックインターネットネットワークアドレスを有するアクセスポイント;
4)ステータス:アップまたはダウン。
【0200】
一実施形態によれば、管理コンソールはまた、BCSアドミニストレータがアクティブなBCSゲートウェイノードのログを見ること、および、以下のBCSゲートウェイメトリックを見ることを可能にする:
1)接続されたクライアント:クライアント名、アドレス、ログオン時間など;
2)現在のトランザクション情報:現在のトランザクション情報は、状態情報、すなわち、このトランザクションがどんな状態にあるかという情報とともに、利用可能になり得る。現在のトランザクション情報は、ハングトランザクションをデバッグするのに役立ち得る;
3)トランザクション統計:トランザクション統計は、管理コンソールUIを通して利用可能になり得る。たとえば、トランザクション統計は、完了したトランザクションの数、受信されたイベント通知の数、および配送されたイベント通知の数を含み得る;
4)メモリ使用量;
5)CPUパーセンテージ;
6)ネットワークI/O;
7)ディスクI/O。
【0201】
チャネル管理
一実施形態によれば、BCSユーザは、現在のBCSインスタンスが参加しているチャネルをすべてリストすることができる。BCSアドミニストレータは、チャネル名、コンソーシアム名、および1つ以上の組織名を入力として用いて、チャネルを作成することができる。チャネル作成の成功または失敗を示すために、出力も表示され得る。
【0202】
一実施形態によれば、BCSユーザは、チャネルの参加ノードおよび組織を見ることができる。管理コンソールは、リストモードとトポロジーモードという2つのビューモードをサポートすることができる。リストモードでは、(そのアンカーピアによって表わされる)参加ローカルノードおよび外部組織が、リストとしてリストされ得る。トポロジーモードでは、(そのアンカーピアによって表わされる)参加ローカルノードおよび外部組織が、トポロジー図で表わされ得る。
【0203】
一実施形態によれば、BCSアドミニストレータは、チャネルにおけるピアの台帳に問合せることができる。台帳は、トランザクションブロックのリストから構成され得る。当該ブロックの各々は、ブロックID、前のハッシュ、データハッシュ、タイムスタンプ、トランザクションIDリスト、アクション(1..n)、チェーンコードID、チェーンコード提案、応答(r/wセット、イベント、成功または失敗)、および1つ以上のエンドーサを含み得る。ブロックの数および呼び出しの数という統計データも表示され得る。
【0204】
一実施形態によれば、BCSアドミニストレータは、チャネルにおいてインスタンス化されたチェーンコードをすべてリストすることができる。リストされた項目は、チェーンコードIDおよびバージョンを含み得る。BCSアドミニストレータはまた、インスタンス化トランザクションによって特定されるような経路であるPathと、インスタンス化引数という、インスタンス化チェーンコードの情報を見ることができる。
【0205】
一実施形態によれば、BCSアドミニストレータは、チャネルにおけるインスタンス化チェーンコードをアップグレードすることができる。アップグレード動作は、チェーンコードの新バージョンがインストールされたターゲット承認ピア、1つ以上のオーダラー、チェーンコードバージョン、および、オプションでチェーンコードに特有の文字列配列引数であり得る引数という入力をとることができる。アップグレード動作の出力は、成功、またはエラーメッセージを有する失敗であり得る。
【0206】
チェーンコード管理
一実施形態によれば、BCSアドミニストレータは、現在のBCSインスタンスの任意のピアにインストールされたチェーンコードをすべてリストすることができる。リストされた項目は、チェーンコードIDおよびバージョンを含む。加えて、BCSアドミニストレータはまた、インストールされたチェーンコードを有するローカルピアノードと、チェ
ーンコードをインスタンス化したチャネルという、インストールされたチェーンコードの情報を見ることができる。
【0207】
一実施形態によれば、管理コンソールを通して、BCSアドミニストレータは、チェーンコードを1つ以上のローカルピアノードにインストールすることができる。インストール動作のための入力は、ターゲットピア;チェーンコードタイプ、たとえば、golang/Java(登録商標);チェーンコードの名前であり得るチェーンコードID;チェーンコードバージョン;チェーンコードのソースコードの場所であり得るチェーンコード経路;およびチェーンコードパッケージ(オプション)を含み得る。インストール動作の出力は、成功、またはエラーメッセージを有する失敗であり得る。
【0208】
一実施形態によれば、BCSアドミニストレータは、チャネル名;チェーンコードがインストールされたターゲット承認ピア;オーダラー;オプションであってもよく、チェーンコードに特有の文字列配列引数であってもよい引数;および承認ポリシーという情報を入力として用いて、定義されたフォーマットで、または、定義されたフォーマットがない場合はデフォルトフォーマットで、インストールされたチェーンコードをチャネルにインスタンス化することができる。
【0209】
メンバーシップ管理
一実施形態によれば、BCSアドミニストレータは、現在のBCSインスタンスにおけるアイデンティティをすべてリストすること、現在のBCSインスタンスのための新しいユーザ/アイデンティティを登録すること、アイデンティティの登録を取り消すこと、および、現在のBCSインスタンスからユーザを除去することができる。さらに、BCSアドミニストレータは、表1に示すようなアイデンティティの以下の属性を見る/編集することができる。
【0210】
【0211】
一実施形態によれば、管理コンソールは、BCSユーザがそれ自体を登録または再登録することを可能にし、それは、そのユーザのためのプライベートキーおよび証明書を生成することができる。管理コンソールはまた、BCSアドミニストレータが以前に登録されたアイデンティティを取り消すことを可能にし、BCSユーザがそのパスワードを変更することを可能にする。
【0212】
一実施形態によれば、BCS管理コンソールは、関連付けられたBCSインスタンスの起動または停止とともに起動または停止され得る。
【0213】
一実施形態によれば、BCS管理コンソールのログレベルを設定するやり方は2つあり得る。それらは、BCS管理コンソール自体から設定するやり方と、管理REST APIを使用してランタイムにログレベルを変更するやり方とである。
【0214】
図7Cは、一実施形態に従った、管理コンソールを提供するための方法を示す。
一実施形態によれば、
図7Cに示すように、ステップ781で、コンテナランタイムサービスが提供される。
【0215】
一実施形態によれば、ステップ783で、コンテナランタイムサービスにおいて、分散型台帳および管理コンソールコンポーネントが提供される。
【0216】
一実施形態によれば、ステップ785で、管理コンソールコンポーネントにおいて、複数のクライアントアプリケーションプログラミングインターフェイス(application programming interface:API)と、複数のバックエンドAPIとが提供され、複数のクラ
イアントAPIはクライアントアプリケーションによって呼び出されるように構成され、複数のバックエンドAPIは分散型台帳の複数のノードと通信するように構成され、複数のクライアントAPIは、分散型台帳をブロックチェーンクラウドサービスとしてプロビジョニングする際に、およびブロックチェーンクラウドサービスを管理する際に、複数のバックエンドAPIのうちの1つ以上を使用する。
【0217】
RESTプロキシサービス
一実施形態によれば、上述のように、ファブリックネットワーク内の異なるコンポーネント間の通信は、gRPCプロトコルに基づいている。そのため、ファブリックネットワークに基づいたBCSインスタンスは、クライアントアプリケーションに、ファブリックSDKを使用してBCSインスタンスにおけるチェーンコードを呼び出すよう要求するであろう。
【0218】
一実施形態によれば、クライアントアプリケーションに、ファブリックSDKを使用してブロックチェーンクラウドサービスと通信するよう要求することは、分散型台帳をクラウドサービスとして提供する利点を部分的に相殺する場合がある。たとえば、利点のうちの1つは、クラウドサービスがインターネット接続を用いてどこからでもアクセスされるはずであるということである。
【0219】
一実施形態によれば、BCSインスタンス内のRESTプロキシサービスコンポーネントは、分散型台帳と通信するために、BCSにおける分散型台帳のためのサービス開発キット(SDK)を使用することができ、また、チェーンコードを通して問合せ、チェーンコードを通してトランザクションを同期的または非同期的に呼び出し、トランザクションステータスを入手し、BCSプロキシバージョンを入手するために、クライアントアプリケーションによって使用されるためのREST APIを提供することができる。RESTプロキシサービスコンポーネントは、分散型台帳とインターフェイス接続する際に使用するために、RESTコールを認証し、RESTコールをリモートプロシージャコール、たとえばグーグルリモートプロシージャコール(gRPC)に変換することができる。RESTプロキシサービスコンポーネントはさらに、BCS管理コンソールコンポーネントによって提供されるものと同じ機能をサポートするREST APIを提供し、BCSインスタンスを消費するためにクライアントアプリケーションのためのユーザインターフェイスを提供することができる。
【0220】
一実施形態によれば、RESTプロキシサービスコンポーネントは、BCSとして実現され、クラウド環境(たとえばオラクルクラウド)におけるコンテナランタイムサービスコンテナで実行される分散型台帳におけるネットワークノードであってもよく、PaaSマネージャ(たとえば、オラクルPaaSサービスマネージャ(PSM)プラットフォーム)によって管理されてもよい。
【0221】
一実施形態によれば、RESTプロキシサービスコンポーネントによって提供されるR
EST APIは、クライアントアプリケーションがBCSにインストールされたスマートコントラクトにアクセスすることを可能にするREST APIと、管理コンソールコンポーネントのための管理REST APIとを含み得る。
【0222】
図8Aは、一実施形態に従った、BCSインスタンスにおいてRESTプロキシサービスを提供するためのシステムを示す。
【0223】
一実施形態によれば、
図8に示すように、RESTプロキシ138は、RESTオーセンティケータ827と、プロトコルコンバータ829とを含み得る。BCS REST APIクライアント808がRESTコール815をRESTプロキシに送信すると、クラウドゲート811に接続されたLBaaS126は、RESTがBCSインスタンスにアクセスできるようにする有効なユーザ名および有効なパスワードを、RESTコールが含むかどうかを判断するために、コールを認証することができる。
【0224】
一実施形態によれば、RESTコールがLBaaSによって認証された場合、LBaaSはRESTコールをRESTプロキシに向けることができ、RESTプロキシは、クライアントアプリケーションにBCSでの適切な認可が与えられているかどうかを判断するために、RESTコール835をIDCS813に転送することができる。
【0225】
一実施形態によれば、クライアントアプリケーションが適切に認可されている場合、RESTプロキシはRESTコールをgRPCコール825に変換し、gRPCコールをファブリックネットワーク601に送信することができる。RESTコールは、いったん内部コール(gRPC)に変換されると、ブロックチェーンファブリック/ハイパーレッジャーのインスタンスとインターフェイス接続することができる。
【0226】
一実施形態によれば、RESTコールは、gRPCライブラリ833を有するファブリックJavaSDK831に基づいたJavaアプリケーションであり得るプロトコルコンバータによって変換され得る。
【0227】
一実施形態によれば、
図8にさらに示すように、RESTプロキシは、REST API823によって提供される1つ以上の機能を管理コンソールに露出するために、REST821を使用して上述のように管理コンソールと通信することができる。
【0228】
図8Bは、一実施形態に従った、BCSインスタンスにおいてRESTプロキシサービスを提供するためのシステムを示す。
【0229】
一実施形態によれば、
図8Bに示すように、RESTプロキシサービスコンポーネント841は、コンテナランタイムサービスコンテナ838におけるウェブサーバ840(たとえばtomcatサーバ)で実行され、単一のファブリックユーザにマッピングされ得る。さらに、RESTプロキシサービスコンポーネントは、JavaScriptオブジェクト表記法(JavaScript Object Notation:JSON)ファイルを使用して管理コンソールコンポーネントによって提供されるユーザインターフェイスを通して構成可能であり、管理コンソールコンポーネントによって提供されるユーザインターフェイスを通して起動可能である。アドミニストレーションユーザは、ピア、チャネル、およびチェーンコードの一部を、RESTプロキシサービスコンポーネントに発行することができる。RESTプロキシサービスコンポーネントの構成へのいかなる更新も、自動的に再びロードされ得る。
【0230】
一実施形態によれば、RESTプロキシサービスコンポーネント(ノード)は、BCSゲートウェイによって起動され得る。起動スクリプトは、BCSゲートウェイの構成ファイルをチェックすることができ、RESTプロキシサービスコンポーネントをホストする
ウェブサーバの構成ファイルを修正することができ、次に、ウェブサーバを起動することができる。ウェブサーバはBCSゲートウェイのためのスレッドを起動して、チャネルごとに構成ファイルを読み、チャネルオブジェクトを作成することができる。ウェブサーバはまた、チャネルごとに、オーダラー、ピア、イベントハブとの接続を作成することができる。異なるチャネルは、オーダラー/ピア/イベントハブとの異なる接続を有し得る。イベントハブは、ピアの第2のポートであり得る。BCSゲートウェイは、トランザクションの結果を入手するために、このポートに接続することができる。
【0231】
一実施形態によれば、ウェブサーバにおけるサーブレットコンテナは、クライアント要求をリッスンして待つことができる。チェーンコードの問合せ方法については、BCSゲートウェイはチェーンコードの2つのエンドーサに要求をランダムに送信し、最初の結果のみを使用することができる。チェーンコードの呼び出し方法については、BCSゲートウェイはチャネルのすべてのエンドーサに要求を送信し、それらのうちの1つが成功を返した場合、BCSゲートウェイはチャネルのすべてのオーダラーにトランザクションを送信することができる。ピアは2つのポートを開くことができ、1つのポートはイベント交換用である。BCSゲートウェイは、1つのチャネルのためのピアのイベントポートに接続できる。
【0232】
一実施形態では、RESTプロキシサービスコンポーネントは、非同期APIおよび同期APIの双方をサポートすることができる。
【0233】
一実施形態によれば、非同期APIについては、RESTプロキシサービスコンポーネントは、クライアントからの要求のパラメータをチェックし、そのクライアントにトランザクションIDを返すことができる。クライアントは、トランザクションが起動されたものの終わっていないことを示す情報を受信することができる。RESTプロキシサービスコンポーネントは、トランザクションを処理し続けるために、バックグラウンドスレッドを起動することができる。クライアントは、終わっていないトランザクションを追跡することができる。RESTプロキシサービスコンポーネントは、クライアントがトランザクションIDを使用してトランザクションステータスを問合せるためのトランザクションAPIを提供する。
【0234】
図8Cは、一実施形態に従った、BCSインスタンスにおいてRESTプロキシサービスを提供するための方法を示す。
【0235】
一実施形態によれば、
図8Cに示すように、ステップ881で、コンテナランタイムサービスが提供される。
【0236】
一実施形態によれば、ステップ883で、コンテナランタイムサービスにおいて分散型台帳が提供され、分散型台帳は、コンテナランタイムサービスにおいてブロックチェーンクラウドサービスとしてプロビジョニングされる。
【0237】
一実施形態によれば、ステップ885で、コンテナランタイムサービスのコンテナにおいてRESTプロキシサービスが実行され、RESTプロキシサービスは、分散型台帳と通信する際にクライアントアプリケーションによって使用されるための複数のREST APIを含み、複数のREST APIは、クライアントアプリケーションからのRESTコールをリモートプロシージャコールに変換するように構成される。
【0238】
例示的なREST API
一実施形態によれば、RESTプロキシサービスコンポーネントは、BCSと、BCSにインストールされたスマートコントラクト(チェーンコード)とを使用して、クライア
ントアプリケーション間の対話のためのREST APIを提供することができる。以下のREST APIは、ブロックチェーンクラウドサービスのRESTプロキシサービスコンポーネントの機能性を説明するための例として提供される。
【0239】
一実施形態によれば、REST APIを呼び出す前に、RESTプロキシサービスコンポーネントは立ち上がって稼働している必要がある。RESTプロキシサービスコンポーネントのステータスは、管理コンソールを通してチェックされ得る。RESTプロキシサービスコンポーネントが立ち上がって稼働していない場合、それは管理コンソールから起動され得る。
【0240】
一実施形態によれば、REST APIは、BCSインスタンスにおけるピアノードにデプロイメントされたスマートコントラクト(チェーンコード)と対話するために呼び出され得る。デプロイメントプロセスは、管理コンソールのチェーンコードページを通して達成され得る。デプロイメントは、インストール(ピアへのコピー)とインスタンス化(コンパイル、チャネルへの結合、および初期化)という2つのステップからなる。
【0241】
一実施形態によれば、以下に提供される例示的なREST APIは、以下の例示的なチェーンコードがBCSにデプロイメントされていると仮定している。
【0242】
【0243】
一実施形態によれば、上に示すように、表2は、チェーンコードの例示的な関数を示し、表3は、チェーンコードの例示的なインストールを示す。
【0244】
一実施形態によれば、RESTプロキシサービスコンポーネントは、チェーンコードを通して問合せ、チェーンコードを通してトランザクションを呼び出し、チェーンコードを通してトランザクションを非同期的に呼び出し、トランザクションステータスを取得し、BCSゲートウェイのバージョンを入手するためのREST APIを提供することができる。
【0245】
一実施形態によれば、チェーンコードを通して問合せるためのAPIは、問合せアクションを行なうためにチェーンコードを呼び出すことができ、問合せのためのチェーンコードおよび引数はREST APIを通して特定される。トランザクションステータスを取得するためのAPIは、トランザクションステータスについてチャネルに問合せることができ、チャネルおよびトランザクションIDはREST APIを通して特定される。BCSゲートウェイのバージョンを入手するためのAPIは、BCSゲートウェイのバージ
ョン情報を返すことができる。チェーンコードを通してトランザクションを呼び出すためのAPIは、トランザクションアクションを行なうためにチェーンコードを呼び出すことができ、呼び出しのためのチェーンコードおよび引数はREST APIを通して特定される。このREST APIは、トランザクションを同期モードで行なうことができる。すなわち、トランザクションの実行が成功した場合、トランザクションの実行が失敗した場合、トランザクションがタイムアウトした場合という3つの場合のいずれでも、応答が送り返される。
【0246】
一実施形態によれば、チェーンコードを通してトランザクションを非同期的に呼び出すためのAPIは、トランザクションアクションを行なうためにチェーンコードを呼び出すことができ、呼び出しのためのチェーンコードおよび引数はREST APIを通して特定される。このREST APIは、トランザクションを非同期モードで行なう。すなわち、トランザクションが提出された後で、その完了またはタイムアウトを待つことなく、応答/受領確認が直ちに送り返される。その場合、結果はその後提供されてもよい。
【0247】
一実施形態によれば、BCSをプロビジョニングおよび/または管理するための管理コンソールによる呼び出しのために、1組のアドミニストレーションREST APIがRESTプロキシサービスコンポーネント上に提供され得る。
【0248】
問合せの呼び出し
一実施形態によれば、チェーンコードは、情報を問合せるために使用される、より多くの関数を含んでいてもよい。これらの関数は、cURL:curl -H Content-type:application/json -X POST http://localhost:8080/bcsgw/rest/v1/transaction/queryを使用し
てRESTリソースに対するPOST要求を提出することによって、以下のREST APIを通して呼び出すことができる。
【0249】
一実施形態によれば、問合せの呼び出しのJSONでの要求の本体は、以下のように示され得る:
【0250】
【0251】
この例では、funcqueryという名前の関数は、Args[0]:アカウントAという入力パラメータを有する。この関数は、アカウントAについて情報を問合せ、アカウント情報を返すことができる。アカウント情報は、チェーンコード名と、チェーンコードバージョンと、問合せを呼び出すためにチェーンコードにおいて定義された方法と、チェーンコードにおける特定された方法に渡される引数を含むアレイとを含む。
【0252】
問合せの呼び出しのための例示的な応答ヘッダは、以下のように示され得る:
【0253】
【0254】
問合せの呼び出しのための例示的な応答本体は、以下のように示され得る:
【0255】
【0256】
上述の例示的な応答本体では、「returnCode」についての「Success」は、問合せが首
尾よく完了したことを意味しており、「Failure」は、問合せが失敗したことを意味する
であろう。「result」については、returnCodeが「Success」である場合、問合せ結果を
有する文字列が返され得る。「info」については、returnCodeが「Failure」である場合
、失敗の追加の詳細を有する文字列が返され得る。
【0257】
トランザクションの呼び出し(同期)
一実施形態によれば、チェーンコードは、トランザクションのための1つ以上の関数を含んでいてもよい。このREST APIは、これらのトランザクションを呼び出すために使用される。動作についてのタイムアウト、トランザクションの成功、およびトランザクションの失敗という条件のうちのいずれかが満たされる場合、応答が送り返され得る。
【0258】
一実施形態によれば、このREST APIを呼び出すために、cURLコマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction/invocation」が使用され得る。
【0259】
JSONでの例示的な要求本体は、以下のように示され得る:
【0260】
【0261】
この例では、funcinvokeという名前の関数は、Args[0]:アカウントA、Args[1]:アカウントB、およびArgs[2]:金額Cという入力パラメータを有する。この関数は、アカウ
ントAからアカウントBに3を動かすであろう。
【0262】
例示的な応答ヘッダは、以下のように示され得る:
【0263】
【0264】
例示的な応答本体は、以下のように示され得る:
【0265】
【0266】
トランザクションの呼び出し(非同期)
一実施形態によれば、チェーンコードは、トランザクションのための1つ以上の関数を含んでいてもよい。このREST APIまたは動作は、それらの関数を非同期モードで呼び出すために使用され得る。非同期モードでは、動作がまだ完了、失敗、またはタイムアウトしていなくても、トランザクションIDが直ちに返される。この動作を使用する場合、動作のステータスは別々に問合される。
【0267】
APIは、コマンド「curl -H Content type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction/asyncInvocation」を使用して呼び出され得る。
【0268】
JSONでの例示的な要求本体は、以下のように示され得る:
【0269】
【0270】
この例では、funcinvokeという名前の関数は、Args[0]:アカウントA、Args[1]:アカウントB、およびArgs[2]:金額Cという入力パラメータを有する。この関数は、アカウ
ントBからアカウントAに5を動かすであろう。このREST API動作は常に、トランザクションが提出された直後にトランザクションIDを返す。トランザクションについてのステータスは、別のREST API動作によって問合され得る。
【0271】
例示的な応答ヘッダは、以下のように示され得る:
【0272】
【0273】
例示的な応答本体は、以下のように示され得る:
【0274】
【0275】
上述の応答本体では、「returnCode」についての「Success」は、トランザクションが
首尾よく呼び出されたことを意味し、「Failure」は、トランザクションの呼び出しが失
敗したことを意味する。returnCodeが「Failure」である場合、「info」は、失敗につい
ての追加情報を含み得る。
【0276】
特定されたトランザクションのビューステータス
一実施形態によれば、このREST APIを用いて、ユーザは、特定されたチャネル情報およびトランザクションIDによってトランザクションの現在のステータスをチェックすることができる。このREST APIは、トランザクションの現在のステータスを直ちに返すことができる。
【0277】
APIを呼び出すために、cURLコマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction」を使用することができる。
【0278】
以下は、APIを呼び出すためのJSONでの例示的な要求のヘッダである。ヘッダでは、「txid」はトランザクションIDである:
【0279】
【0280】
以下は、例示的な応答のヘッダである:
【0281】
【0282】
以下は、例示的な応答の本体である:
【0283】
【0284】
トランザクションリストのためのビューステータス
一実施形態によれば、このREST APIは、特定されたトランザクションのグループのステータスをチェックするために使用され得る。1)どのトランザクションもInProgressステータスを有していない、すなわち、リストされたすべてのトランザクションが成功に終わったかまたは失敗したという条件;2)この要求についてタイムアウトが到達されたという条件という2つの条件のうちのいずれか一方が真である場合、このREST APIは戻る。
【0285】
REST APIを呼び出すために、コマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction/waitStatus」を使
用することができる。
【0286】
以下は、JSONでの例示的な要求本体である:
【0287】
【0288】
上述の要求は、リストされたチャネルおよびトランザクションIDによって特定されたトランザクションのステータスをチェックする。「timeout」は、この動作についてのタ
イムアウトをミリ秒で特定し、「array」は、問合されるトランザクションをリストする
ために使用される。トランザクションごとに、チャネル名とトランザクションIDとを有する要素を作成することができる。
【0289】
例示的な応答ヘッダは、以下のように示され得る:
【0290】
【0291】
例示的な応答本体は、以下のように示され得る:
【0292】
【0293】
ビューバージョン
一実施形態によれば、このREST APIは、BCSゲートウェイのバージョン情報を検索するために使用可能であり、コマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/version」を使用して呼び出され得る。
【0294】
REST APIを呼び出すためのJSONでの例示的な要求ヘッダは、以下のように示され得る:
【0295】
【0296】
RESTの呼び出しから返された例示的な応答のヘッダは、以下のように示され得る:
【0297】
【0298】
RESTの呼び出しから返された例示的な応答の本体は、以下のように示され得る:
【0299】
【0300】
アイデンティティクラウドサービス(IDCS)と統合されたファブリック証明機関(ファブリックCA)
一実施形態によれば、ファブリックCAサーバは、ファブリックのためのメンバーシッ
プサービスを提供する。それは、ユーザについての認証と、ブロックチェーン(ピアおよびオーダーのグループ)にアクセスするための認証と、アプリケーションクライアント、ピア、およびオーダーに証明書を配送できるCAサーバという3つの部分を含む。ファブリックCAは、認証および認可を実現するために証明書を使用する。証明書は、認証のための登録certと、認可のためのトランザクションcertという2つのタイプを含む。IDCSも、認証および認可を提供する。しかしながら、その認可はOAuthによって実現される
。すなわち、ピアがオーダーにアクセスしたい場合、ピアは、IDCSからユーザのアクセストークンを入手し、このトークンを使用してオーダーにアクセスすべきである。
【0301】
一実施形態によれば、ファブリックCAは、たとえばユーザの名前/パスワード、ユーザの証明書、およびユーザのアフィリエーションといったファブリックCAの登録ユーザの情報を格納するために、データベースまたはLDAPを使用する。パブリッククラウド(OPC)のエンドユーザは、その従業員が適用されるパブリッククラウド(OPC)インスタンスのすべてにアクセスすることを管理するために、1つの集中型IDCSインスタンスを適用するであろう。ブロックチェーンクラウドサービスBCSは好ましくは、他のクラウドサービスに使用されたIDCSと統合される。このため、エンドユーザは、その従業員が、BCSに含まれる、適用されるパブリッククラウド(OPC)インスタンスのすべてにアクセスすることを管理するために、1つの集中型IDCSインスタンスを適用できるようになる。
【0302】
一実施形態では、ブロックチェーンクラウドサービス(BCS)は、ユーザ情報を集中的に格納するために、オラクルアイデンティティクラウドサービス(IDCS)を使用する。BCSは、ファブリックCAユーザの情報をIDCSに格納し、それにより、オラクルBCSがIDCSを使用して、複数のパブリッククラウドサービスインスタンスにわたって集中化されたBCSユーザの情報を管理することを可能にする。このため、一実施形態では、BCSファブリックCAユーザの情報、証明書は、オラクルIDCSに格納される。ファブリック証明書認可フレームワークは、PKIプライベートキー、署名された証明書、CA証明書チェーンを含むファブリックメンバーシッププロバイダ(MSP)であり、それはファブリックCAクライアント/サーバによって設定される。
【0303】
一実施形態によれば、BCSは、OPCのユーザ管理を活用する。どのBCSユーザも、まず、OPCユーザ(ひいてはIDCSアイデンティティ)でなければならない。BCSインスタンスが作成される場合、BCSコンソール、CA、およびRESTプロキシといういくつかのタイプのアプリケーションが作成される。コンソールについては、コンソールadminとコンソールユーザという2つのアプリ役割がある。CAについては、ファブ
リックadmin、ファブリッククライアント、ファブリックピア、ファブリックオーダラー
という4つのアプリ役割がある。RESTプロキシについては、ゲートウェイadminとゲ
ートウェイユーザという2つのアプリ役割がある。
【0304】
一実施形態によれば、BCSユーザになるために、OPCユーザは、OPCユーザ管理コンソールにおけるあるBCSアプリ役割を与えられる必要がある。
【0305】
一実施形態によれば、BCSインスタンスの作成時、作成者は既存のOPCユーザ/パスワードを提供する必要があり、このユーザは、BCSコンソールadminおよびファブリ
ックadminの役割を自動的に与えられるであろう。そのため、このユーザはBCSアドミ
ニストレータになる。
【0306】
認証:BCSコンソール/CA/RESTプロキシについては、認証はクラウドゲートで行なわれる。ピア/オーダラーについては、認証は署名ベースである。BCSコンソールについては、認証後、コンソールは、(IDCSを呼び出すことによって)現在のユー
ザのアプリ役割を手に入れる。ユーザがコンソールadminまたはコンソールユーザの役割
を与えられていない場合、接続が拒否される。その他の場合、コンソールは、予め定義された規則に基づいてアクセス制御を行なう。たとえば、通常のユーザは一般に情報を読むことしかできず、一方、adminは何でも行なうことができる。
【0307】
一実施形態によれば、CAについては、認証後、CAは現在のユーザのアプリ役割を手に入れる。ユーザがファブリック役割を何も与えられていない場合、登録要求が拒否される。
【0308】
一実施形態によれば、RESTプロキシについては、認証後、RESTプロキシは現在のユーザのアプリ役割を手に入れる。ユーザがゲートウェイadminまたはゲートウェイユ
ーザの役割を与えられていない場合、要求は拒否される。その他の場合、RESTプロキシは、予め定義された規則に基づいてアクセス制御を行なう。たとえば、通常のユーザは呼び出し/問合せを行なうことでき、adminは構成を変更したりメトリックを入手するこ
とができる。
【0309】
一実施形態によれば、ファブリックCAサーバは、ファブリックのためのメンバーシップサービスを提供する。それは、ユーザについての認証と、ブロックチェーン(ピアおよびオーダーのグループ)にアクセスするための認証と、アプリケーションクライアント、ピア、およびオーダーに証明書を配送できるCAサーバという3つの部分を含む。
【0310】
一実施形態によれば、ファブリックCAは、認証および認可を実現するために証明書を使用する。証明書は、認証のための登録certと、認可のためのトランザクションcertという2つのタイプを含む。
【0311】
一実施形態によれば、IDCSも、認証および認可を提供する。しかしながら、その認可はOAuthによって実現される。すなわち、ピアがオーダーにアクセスしたい場合、ピア
は、IDCSからユーザのアクセストークンを入手し、このトークンを使用してオーダーにアクセスすべきである。
【0312】
図9Aは、一実施形態に従った、シングルサインオンのための典型的なIDCS使用事例を示す。
【0313】
一実施形態によれば、最初のステップで、ウェブアプリケーション901をIDCS902に追加することができる。次に、ウェブブラウザ900などのクライアントが、ウェブアプリケーションから認証(たとえば、ユーザ名およびパスワード)を要求することができる。ウェブアプリケーションがIDCSに追加されたため、ウェブアプリケーションはウェブブラウザに、IDCSへ認証要求を行なうよう命令することができる。ウェブアプリケーションから応答を受信後、ウェブブラウザは次に、IDCSから認証(たとえば、ユーザ名およびパスワード)を要求することができる。
【0314】
一実施形態によれば、IDCSは次に要求を認証し、認証が成功するとトークンをウェブブラウザに送り返すことができる。認証されそのトークンを受信したウェブブラウザは次に、ウェブアプリケーションから要求することができる。ウェブアプリケーションはトークンを検証し、認証が成功したことをウェブブラウザに合図することができる。
【0315】
図9Aに示す事例では、IDCSは、アプリケーションのためのアイデンティティサービスを提供するためのアイデンティティプロバイダ(IdP)として作用する。すべての当事者間の通信はすべて、HTTPベースである。この使用事例は構成駆動型であるが、HTTPベースのアプリケーションにのみ当てはまる。
【0316】
図9Bは、一実施形態に従った、ファブリッククライアント認証のためのIDCS使用事例を示す。
【0317】
一実施形態によれば、すでに登録されたファブリックユーザ(このユーザのプライベートキーおよび証明書はすでにクライアント側の状態ストアに格納されている)に関連付けられたファブリッククライアント904は、新しいクライアント()、および、クライアントのユーザコンテキスト(ユーザ名)を入手することを要求することができる。ファブリックSDK905は、状態ストアからユーザをロードし、ユーザオブジェクトをファブリッククライアントに返すことができる。クライアントは、ユーザオブジェクトを受信すると、トランザクション提案をファブリックSDKに送信することができ、ファブリックSDKは、同じプライベートキーを使用して提案に署名することができる。署名された提案は次にピア(または複数のピア)906へ行くことができ、ピアはメンバーシップサービス907で署名を検証するであろう。メンバーシップサービスは、ユーザのための証明書をIDCS902から入手することができ、IDCSからの証明書を使用してユーザの署名を検証することができる。メンバーシップサービスは次に、署名が検証されたという検証をピアに返すことができる。
【0318】
本発明のさまざまな実施形態が上述されてきたが、それらは限定のためではなく例示のために提示されてきたことが理解されるべきである。実施形態は、この発明およびその実際の応用の特徴および原則を説明するために選択され、記載された。実施形態は、新しいおよび/または向上した機能を提供すること、ならびに/もしくは、リソース利用の減少、能力の増加、スループットの増加、効率の向上、待ち時間の減少、セキュリティの強化、および/または使いやすさの向上を含むもののそれらに限定されない性能利点を提供することによってシステムおよび方法の性能を向上させるために、本発明のさまざまな特徴が利用される、システムおよび方法を示す。
【0319】
本発明のいくつかの実施形態は、アーキテクチャ、機能性、プロセス、および/または動作を示す、方法、装置(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して、ここに説明される。フローチャートまたはブロック図における各ブロックは、要素、機能、プロセス、モジュール、セグメント、または命令の一部を表わし、それは、特定された機能を実現するための1つ以上の実行可能命令を含む。いくつかの代替的な実施形態では、ブロック図またはフローチャートに記載された機能は、図に記載されたもの以外の順序で起こる。たとえば、連続して示された2つのブロックが、関与する機能性に依存して、実質的に同時に実行されてもよく、または逆の順序で実行されてもよい。フローチャートおよび/またはブロック図の各ブロック、ならびに、フローチャートおよび/またはブロック図におけるブロックの組合せは、特定された機能を行なう、コンピュータプログラム命令、および/または専用ハードウェア、および/またはハードウェアとコンピュータプログラム命令との組合せによって実現され得る。
【0320】
いくつかの実施形態では、本発明の特徴は、プロセッサと、コンピュータ読取可能記憶媒体と、他のコンピュータと通信するためのネットワークカード/インターフェイスとを含む、コンピュータにおいて実現される。いくつかの実施形態では、本発明の特徴は、ネットワークによって相互接続されたパーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラマブルな家電、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどを含む、さまざまなタイプのコンピュータ構成を含むコンピューティングシステムを含むネットワークコンピューティング環境において実現される。ネットワークは、ローカルエリアネットワーク(Local Area Network:LAN)、スイッチファブリックネットワーク(たとえばInfini
Band(インフィニバンド))、ワイドエリアネットワーク(Wide Area Network:WAN
)、および/またはインターネットであり得る。ネットワークは、銅の送信ケーブル、光伝送ファイバー、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、および/またはエッジサーバを含み得る。
【0321】
いくつかの実施形態では、本発明の特徴は、バックエンドコンポーネント(たとえばデータサーバ)を含む、または、ミドルウェアコンポーネント(たとえばアプリケーションサーバ)を含む、または、フロントエンドコンポーネント(たとえば、ユーザがここに説明された主題の実現化例と対話できるようにするグラフィカルユーザインターフェイスまたはウェブブラウザを有するクライアントコンピュータ)を含む、または、ネットワークによって相互接続されたそのようなバックエンド、ミドルウェア、あるいはフロントエンドコンポーネントの任意の組合せを含む、コンピューティングシステムにおいて実現される。コンピューティングシステムは、クライアントーサーバ関係を互いに有するクライアントおよびサーバを含み得る。いくつかの実施形態では、この発明の特徴は、コンピュータの1つ以上のクラスタがネットワークによって接続される分散コンピューティング環境を含むコンピューティングシステムにおいて実現される。分散コンピューティング環境は、すべてのコンピュータを単一の場所で有することができ、または、コンピュータのクラスタを、ネットワークによって接続された遠隔の異なる地理的場所で有することができる。
【0322】
いくつかの実施形態では、本発明の特徴は、ウェブ技術を使用してセルフサービスの計量される方法でユーザに与えられる共有の柔軟なリソースに基づいたクラウドコンピューティングシステムの一部として、またはそのサービスとして、クラウドにおいて実現される。クラウドの特性は、たとえば、オンデマンドのセルフサービス、広いネットワークアクセス、リソースプール、迅速な柔軟性、および測定されるサービスを含んでいてもよい。クラウドデプロイメントモデルは、パブリック、プライベート、およびハイブリッドを含む。クラウドサービスモデルは、ソフトウェア・アズ・ア・サービス(Software as a Service:SaaS)、プラットフォーム・アズ・ア・サービス(PaaS)、データベ
ース・アズ・ア・サービス(Database as a Service:DBaaS)、およびインフラス
トラクチャ・アズ・ア・サービス(IaaS)を含む。クラウドは一般に、共有の柔軟なリソースをユーザに与える、ハードウェアとソフトウェアとネットワークとウェブ技術との組合せを指す。ここに使用されるようなクラウドは、パブリッククラウド、プライベートクラウド、および/またはハイブリッドクラウド実施形態を含んでいてもよく、クラウドSaaS、クラウドDBaaS、クラウドPaaS、および/またはクラウドIaaSデプロイメントモデルを含んでいてもよい。
【0323】
いくつかの実施形態では、本発明の特徴は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せを使用して、あるいはその助けを借りて実現される。いくつかの実施形態では、本発明の特徴は、本発明の1つ以上の機能を実行するように構成またはプログラムされたプロセッサを使用して実現される。いくつかの実施形態では、プロセッサは、ここに説明された機能を行なうように設計された、シングルまたはマルチチッププロセッサ、デジタル信号プロセッサ(digital signal processor:DSP)、システム・オン・チップ(system on a chip:SOC)、特定用途向け集積回路(application specific integrated circuit:ASIC)、フィールドプログラマブルゲートアレイ(field programmable gate array:FPGA)または他のプログラマブルロジックデバイス、ステートマシン、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェアコンポーネント、もしくはそれらの任意の組合せである。いくつかの実現化例では、本発明の特徴は、所与の機能に特有の回路によって実現される。他の実現化例では、特徴は、たとえばコンピュータ読取可能記憶媒体に格納された命令を使用して特定の機能を行なうように構成された、コンピュータ、コンピューティングシステム、プロセッサ
、および/またはネットワークにおいて実現される。
【0324】
いくつかの実施形態では、本発明の特徴は、処理および/またはネットワークシステムのハードウェアを制御するために、ならびに、本発明の特徴を利用する他のシステムとプロセッサおよび/またはネットワークが対話できるようにするために、ソフトウェアおよび/またはファームウェアに組込まれる。そのようなソフトウェアまたはファームウェアは、アプリケーションコード、デバイスドライバ、オペレーティングシステム、仮想マシン、ハイパーバイザー、アプリケーションプログラミングインターフェイス、プログラミング言語、および実行環境/コンテナを含み得るものの、それらに限定されない。本開示の教示に基づいて、適切なソフトウェアコーディングが、熟練したプログラマーによって容易に準備され得る。
【0325】
いくつかの実施形態では、本発明は、ソフトウェアおよび/またはファームウェアを含む命令が格納されたマシン読取可能またはコンピュータ読取可能記憶媒体であるコンピュータプログラム製品を含み、命令は、本発明のプロセスまたは機能のうちのいずれかを行なうように、コンピュータなどのシステムをプログラムするかまたは他の態様で構成するために使用され得る。記憶媒体またはコンピュータ読取可能媒体は、フロッピー(登録商標)ディスク、ハードドライブ、ソリッドステートドライブ、光ディスク、DVD、CD-ROM、マイクロドライブ、および光磁気ディスク、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、フラッシュメモリデバイス、磁気または光カード、分子メモリ、ナノシステム、またはそれらの変形および組合せを含むもののそれらに限定されない、命令および/またはデータを格納するのに好適な任意のタイプの媒体またはデバイスを含み得る。特定の実施形態では、記憶媒体またはコンピュータ読取可能媒体は、非一時的マシン読取可能記憶媒体、または非一時的コンピュータ読取可能記憶媒体である。
【0326】
前述の説明は、網羅的であるよう、またはこの発明を開示された形態そのものに限定するよう意図されていない。加えて、本発明の実施形態は特定の一連のトランザクションおよびステップを使用して説明されてきたが、記載がない限り、実施形態は追加のトランザクションおよびステップの実行を除外しないということは、当業者には明らかであるはずである。また、さまざまな実施形態がこの発明の特徴の特定の組合せを説明しているが、この発明の範囲内にあるような関連技術の当業者には特徴の異なる組合せが明らかである、ということが理解されるべきである。特に、所与の実施形態、変形に記載され、または図面に示された(デバイスのような、または方法のような)特徴は、本発明の範囲から逸脱することなく、別の実施形態、変形、または図面にある別の特徴と組合されてもよく、もしくはそれを置き換えてもよい。さらに、要素のさまざまな追加、削減、削除、変形、均等物との置換、ならびに、形態、詳細、実現化例、および用途における他の修正および変更が、この発明の精神および範囲から逸脱することなく、そこになされ得るということは、関連技術の当業者には明らかであろう。この発明のより広範な精神および範囲は、請求項およびそれらの均等物によって定義されることが意図されている。