JP6823732B2 - ブロックチェーンクラウドサービスのためのレプレゼンテーショナルステートトランスファープロキシサービスを提供するためのシステムおよび方法 - Google Patents

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる資料を含む。この特許文献または特許開示は特許商標庁の特許ファイルまたは記録に記載されているため、著作権保有者は、何人によるその複写複製に対して異議はないが、その他の場合には如何なるときもすべての著作権を保有する。

優先権の主張および関連出願との相互参照：
本願は、２０１７年９月２９日に出願された出願番号第６２／５６５，９９９号の「ブロックチェーンクラウドサービスを提供するためのシステムおよび方法」（SYSTEM AND METHOD FOR PROVIDING A BLOCKCHAIN CLOUD SERVICE）と題された米国仮特許出願、２０１８年９月２５日に出願された出願番号第１６／１４１，３２９号の「ブロックチェーンクラウドサービスのためのインターフェイスを提供するためのシステムおよび方法」（SYSTEM AND METHOD FOR PROVIDING AN INTERFACE FOR A BLOCKCHAIN CLOUD SERVICE）と題さ
れた米国特許出願、２０１８年９月２５日に出願された出願番号第１６／１４１，３３７号の「ブロックチェーンクラウドサービスを管理するためのシステムおよび方法」（SYSTEM AND METHOD FOR MANAGING A BLOCKCHAIN CLOUD SERVICE）と題された米国特許出願、
および、２０１８年９月２５日に出願された出願番号第１６／１４１，３３９号の「ブロックチェーンクラウドサービスのためのレプレゼンテーショナルステートトランスファープロキシサービスを提供するためのシステムおよび方法」（SYSTEM AND METHOD FOR PROVIDING A REPRESENTATIONAL STATE TRANSFER PROXY SERVICE FOR A BLOCKCHAIN CLOUD SERVICE）と題された米国特許出願の優先権の利益を主張するとともに、２０１７年４月１２日に出願された番号第１５／４８５，５３２号の「マルチテナントアイデンティティおよびデータセキュリティ管理クラウドサービス」（MULTI-TENANT IDENTITY AND DATA SECURITY MANAGEMENT CLOUD SERVICE）と題された米国特許出願（後に米国特許第９，７８１，１２２号として２０１７年１０月３日に発行）に関連している。これらの出願の各々は、ここに引用により援用される。

発明の分野：
この開示は概して、分散型台帳を提供するためのシステムおよび方法に関する。より特定的には、この開示は、ブロックチェーンクラウドサービスとして実現される分散型台帳を管理するためのシステムおよび方法を説明する。

背景：
分散型台帳は、資産所有権のデジタル記録として大まかに説明され得る。台帳の中心的なアドミニストレータは存在せず、中央データストアも存在しない。代わりに、台帳は、複数の場所、国、または機関にわたって地理的に広がり得るコンピューティング環境における多くの参加ノードにわたって複製される。コンセンサスプロトコルが、各ノードの台帳のコピーが他のすべての他のノードのコピーと同一であることを保証する。また、コピーの集合が、単一の共有台帳として見られてもよい。分散型台帳は、資産所有者によって、たとえば自分のアカウントから引き落として別のアカウントに入金するために、暗号署名技術を用いて使用されてもよい。

ブロックチェーンとは、改ざんされにくい分散型台帳を実現するために使用され得るデータ構造である。複数のノードが、クライアントからのトランザクションがブロックへと
パッケージ化される共通プロトコルに従い、ノードは、次のブロックについて同意するためにコンセンサスプロトコルを使用する。ブロックは、台帳の改ざんを困難にする累積暗号ハッシュを担持する。各ブロックは、時間的に前のブロックとの関連（ハッシュ値）を有する。加えて、各ブロックは、それ自体のハッシュを含み得る。ブロックチェーンは、後方に（たとえばチェーンを遡って）横断され得る。

ブロックチェーンは、非許可型ブロックチェーンまたは許可型ブロックチェーンのいずれかであり得る。誰でも非許可型ブロックチェーンに加入して分散型台帳のコピーを有することができる。ビットコイン（Bitcoin）およびイーサリアム（Ethereum）は、非許可
型ブロックチェーンの例である。非許可型ブロックチェーンは、単一のエンティティによる制御を回避しつつ、匿名の参加者が台帳を保持することを可能にする。しかしながら、匿名性に鑑みて、アイデンティティ、説明責任、および監査可能性が困難である。対照的に、許可型ブロックチェーンは、招待によってメンバーを受け入れ、明示的に認可された当事者が台帳を保持することを可能にすることによって信用および説明責任のレベルを考慮する。

ハイパーレッジャー（Hyperledger）ファブリックは、許可型ブロックチェーンの例で
ある。企業グレードのオープンソース分散型台帳フレームワークおよびコードベースとしてのハイパーレッジャーファブリックは、スマートコントラクトを実行するための分散型台帳プラットフォームの実現化例である。それは、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。

プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）とは、
アプリケーション開発、データ管理、統合、モバイル、およびモノのインターネット（Internet of Things：ＩＯＴ）のための多くのクラウドサービスである。クラウドサービスからの需要が増えるにつれて、ブロックチェーンＰａａＳクラウドサービスを提供することが望ましいであろう。ブロックチェーンＰａａＳクラウドサービスは、第三者である仲介役の必要性を減少させつつ、スマートコントラクトを構築して実行し、改ざんされにくい分散型台帳を保持するための予め組立てられたプラットフォームを提供することができる。ＰａａＳブロックチェーンクラウドサービスはまた、他のＰａａＳサービスを活用するブロックチェーンソリューションの開発を可能にすることができる。

概要：
一実施形態によれば、分散型台帳をブロックチェーンクラウドサービス（Blockchain Cloud Service：ＢＣＳ）として実現するためのシステムおよび方法がここに説明される。ＢＣＳは、生産準備ができたブロックチェーンの設定および実行を可能にするために、計算、コンテナ、ストレージ、アイデンティティ管理、およびイベントストリーミングというインフラストラクチャサービスおよび埋め込みリソースの完全集合を含み得る。ＢＣＳは、アドミニストレータが１つ以上のパラメータを特定することに応答して、根底的なインフラストラクチャに、必要とされるブロックチェーンネットワークコンポーネント、インターフェイス、レプレゼンテーショナルステートトランスファー（representational state transfer：ＲＥＳＴ）プロキシサービスコンポーネント、および管理コンソールコ
ンポーネントをプロビジョニングすることができる。

一実施形態によれば、分散型台帳はハイパーレッジャーファブリックであってもよく、それは、ブロックチェーンアプリケーションを開発するための基盤として意図されたブロックチェーン技術の実現化例である。ハイパーレッジャーファブリックはモジュール式ア
ーキテクチャを提供することができ、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。

一実施形態によれば、ＢＣＳは、ＰａａＳマネージャ（たとえば、オラクルＰａａＳサービスマネージャ（PaaS Service Manager：ＰＳＭ）プラットフォーム）に基づくことができ、ＰａａＳマネージャ上の計算空間（たとえば、外部計算空間）で実行可能である。システムは、オラクルアイデンティティクラウドサービス（Identity Cloud Service：ＩＤＣＳ）、オラクル・ロード・バランサ・アズ・ア・サービス（Load Balancer as a Service：ＬＢａａＳ）、オラクルイベントハブクラウドサービス、およびオラクルクラウドストレージを使用して階層化されたコンテナランタイムサービス環境（Dockerまたはオラクルのアプリケーションコンテナクラウドサービスなど）を含むＰＳＭプラットフォームの特徴を利用する。各顧客ブロックチェーンはプロビジョニングされ、テナントとして実行され得る。システムは複数のブロックチェーンをサポートし、それらは各々、マルチテナント環境において別個のテナントとしてプロビジョニングされ、実行される。

一実施形態によれば、管理コンソールコンポーネントおよびＲＥＳＴプロキシサービスコンポーネントは双方とも、ＢＣＳにおけるネットワークノードであり得る。

一実施形態によれば、管理コンソールコンポーネントは、ＢＣＳのプロビジョニング、監視、および構成を容易にし、自動化する。管理コンソールコンポーネントは、スクリプトランタイム環境、たとえばNode.jsにおいて実行されるウェブアプリケーションを含み
得る。ウェブアプリケーションは、グラフィカルユーザインターフェイスフレームワークおよびウェブフレームワーク上に構築可能であり、ＢＣＳインスタンスにおけるさまざまなノードまたはサービスと通信するための複数のカスタム機能またはＡＰＩを含み得る。ウェブアプリケーションは、ＢＣＳインスタンスにおけるさまざまなノードまたはサービスからの情報を、コンソールユーザインターフェイスでの表示のために、ビューオブジェクトにポピュレートすることができる。管理コンソールコンポーネントはまた、アドミニストレータがＢＣＳインスタンスにおける１つ以上のノードを起動、停止、および更新するための複数の機能を提供することができる。ウェブアプリケーションによって提供されるものと同じ機能をサポートするために、１組の管理ＲＥＳＴ ＡＰＩが、スクリプトランタイム環境によって提供され、またはスクリプトランタイム環境によってアクセスされ得る。

一実施形態によれば、ＢＣＳインスタンス内のＲＥＳＴプロキシサービスコンポーネント（すなわち、ＲＥＳＴプロキシサービス、またはＲＥＳＴプロキシ）は、分散型台帳と通信するために、ＢＣＳにおける分散型台帳のためのサービス開発キット（service development kit：ＳＤＫ）を使用することができ、また、チェーンコードを通して問合せ、
チェーンコードを通してトランザクションを同期的または非同期的に呼び出し、トランザクションステータスを入手し、ＢＣＳプロキシバージョンを入手するために、クライアントアプリケーションによって使用されるためのＲＥＳＴ ＡＰＩを提供することができる。ＲＥＳＴプロキシサービスコンポーネントは、分散型台帳とインターフェイス接続する際に使用するために、ＲＥＳＴコールを認証し、ＲＥＳＴコールをリモートプロシージャコール、たとえばグーグル（登録商標）リモートプロシージャコール（Google Remote Procedure Call：ｇＲＰＣ）に変換することができる。ＲＥＳＴプロキシサービスコンポーネントはさらに、ＢＣＳ管理コンソールコンポーネントによって提供されるものと同じ機能をサポートするＲＥＳＴ ＡＰＩを提供し、ＢＣＳインスタンスを消費するためにクライアントアプリケーションのためのユーザインターフェイスを提供することができる。

図面の簡単な説明：
一実施形態に従った、ブロックチェーンクラウドサービスシステムのファブリックにおけるトランザクションフローを示す図である。 一実施形態に従ったブロックチェーンクラウドサービスシステムを示す図である。 一実施形態に従ったＢＣＳシステムを示す図である。 一実施形態に従ったＢＣＳシステムを示す図である。 一実施形態に従った、ブロックチェーンクラウドサービスのためのインターフェイスを提供するための方法のフローチャートである。 一実施形態に従った、ブロックチェーンクラウドサービスシステムのためのゲートウェイを示す図である。 一実施形態に従った、ブロックチェーンクラウドサービスシステムのための持続性を示す図である。 ＢＣＳ上のファブリックの例示的なデプロイメントを示す図である。 一実施形態に従ったチェーンコードアーキテクチャを示す図である。 一実施形態に従った、管理コンソールを提供するためのシステムを示す図である。 一実施形態に従った、ＢＣＳコンソールＵＩにおけるユーザインターフェイスの例を示す図である。 一実施形態に従った、ＢＣＳコンソールＵＩにおけるユーザインターフェイスの例を示す図である。 一実施形態に従った、管理コンソールを提供するための方法を示す図である。 一実施形態に従った、ＢＣＳインスタンスにおいてＲＥＳＴプロキシサービスを提供するためのシステムを示す図である。 一実施形態に従った、ＢＣＳインスタンスにおいてＲＥＳＴプロキシサービスを提供するためのシステムを示す図である。 一実施形態に従った、ＢＣＳインスタンスにおいてＲＥＳＴプロキシサービスを提供するための方法を示す図である。 一実施形態に従った、シングルサインオンのための典型的なＩＤＣＳ使用事例を示す図である。 一実施形態に従った、ファブリッククライアント認証のためのＩＤＣＳ使用事例を示す図である。

詳細な説明：
一実施形態によれば、分散型台帳をクラウドサービスとして実現するためのシステムおよび方法がここに説明される。特定の一実施形態では、許可型ブロックチェーン台帳、たとえばハイパーレッジャーファブリックが、ブロックチェーンクラウドサービス（ＢＣＳ）として提供され得る。

以下の説明では、この発明を、添付図面の図において、限定のためではなく例示のために説明する。この開示におけるさまざまな実施形態への参照は、必ずしも同じ実施形態への参照ではなく、そのような参照は少なくとも１つを意味する。特定の実現化例が述べられるが、これは例示のためにのみ提供されるということが理解される。関連技術の当業者であれば、他の構成要素および構成が、この発明の範囲および精神から逸脱することなく使用され得るということを認識するであろう。

一実施形態によれば、場合によっては、この発明の徹底的な説明を提供するために、多くの特定の詳細が述べられるであろう。しかしながら、この発明がこれらの特定の詳細なしで実践され得るということは、当業者には明らかであろう。他の場合、発明を不明瞭に
しないように、周知の特徴はそれほど詳細には説明されていない。

本発明は、特定される機能およびそれらの関係の実行を示す機能的構造ブロックの助けを借りて説明される。説明の便宜上、これらの機能的構造ブロックの境界はしばしば、ここに任意に定義されている。このため、同じ要素によって行なわれると図示された機能が、代替的な実施形態では、異なる要素によって行なわれてもよい。別々の要素において行なわれると図示された機能が、代わりに、１つの要素へと組合されてもよい。特定される機能およびそれらの関係が適切に実行される限り、代替的な境界を定義することができる。このため、そのような代替的な境界はいずれも、この発明の範囲および精神内にある。

図面および詳細な説明の全体にわたって同じ要素を示すために、共通の参照符号が使用される。したがって、ある図で使用される参照符号は、要素が別の場所に記載される場合、そのような図に特有の詳細な説明で参照されてもされなくてもよい。

ブロックチェーン技術は、顧客のエコシステムにわたってほぼリアルタイムの分散トランザクションを可能にすることにより、および、安全で改ざんされにくいデータ共有を可能にすることにより、企業ビジネス価値を劇的に高める潜在能力を有する。ハイパーレッジャーファブリックブロックチェーンは、モジュール式アーキテクチャと、水平／産業横断的技術サポートと、企業ニーズのためのサポートとを取り入れている。

はじめに
一実施形態によれば、ハイパーレッジャーファブリックは、高度の機密性、回復力、柔軟性、およびスケーラビリティを与えるモジュール式アーキテクチャによって下支えされた、分散型台帳ソリューションのためのプラットフォームである。それは、異なるコンポーネントのプラグ可能な実現化例をサポートし、経済エコシステムにわたって存在する複雑性に対処するように設計されている。

一実施形態によれば、ハイパーレッジャーファブリックは、柔軟で拡張可能なアーキテクチャを与え、それを代替的ブロックチェーンソリューションから区別する。

ブロックチェーン − 分散型台帳
一実施形態によれば、ブロックチェーンネットワークは、ネットワーク上で起こるトランザクションをすべて記録する分散型台帳を含み得る。

一実施形態によれば、ブロックチェーン台帳はしばしば、分散化されていると説明される。なぜなら、それが多くのネットワーク参加者にわたって複製され、参加者は各々、その保持において協力するためである。分散化および協力は、ビジネスが実世界で商品やサービスを交換するやり方を反映する属性である。

分散化され協力的であることに加えて、ブロックチェーンに記録される情報は付加のみであり、トランザクションが台帳にいったん追加されるとそれを修正することはできないということを保証する暗号手法を使用する。この不変性という特性は、情報の出所の判断を簡単にする。なぜなら、参加者は情報が事後に変更されていないことを確信できるためである。このように、ブロックチェーンは、証明のシステムとして考えられ得る。

ブロックチェーン − スマートコントラクト
一実施形態によれば、情報の一貫した更新をサポートするために、および、ある台帳機能（取引する、問合せるなど）を可能にするために、ブロックチェーンネットワークは、スマートコントラクトを使用して、台帳への制御されたアクセスを提供する。

一実施形態によれば、スマートコントラクトは、情報をカプセル化し、それをネットワーク中で簡単なまま保つための主要メカニズムであるだけではなく、それらは、参加者がトランザクションのある局面を自動的に実行できるようにするように書かれることもできる。

一実施形態によれば、スマートコントラクトは、たとえば、品物がいつ到着するかに依存して変わる、品物を出荷するコストを規定するために書かれ得る。品物が受け取られると、両当事者によって同意され、台帳に書かれた条件で、適切な費用が自動的にやりとりされる。

ブロックチェーン − コンセンサス
一実施形態によれば、適切な参加者によってトランザクションが承諾された場合のみ台帳が更新されること、および、台帳が更新を行なうとそれらが同じトランザクションを同じ順序で用いて更新されることを保証するために、ネットワーク全体で台帳トランザクションを同期されたまま保つプロセスは、コンセンサスと称され得る。

一実施形態によれば、ブロックチェーンは、スマートコントラクトを介して更新され、コンセンサスと呼ばれる協力的プロセスを通して一貫して同期されたまま保たれる、共有の複製されたトランザクションシステムとして考えられ得る。

ブロックチェーンの利点
一実施形態によれば、現在利用可能なトランザクションネットワークは、ビジネス記録が保存されてから存在してきたネットワークのバージョンである。ビジネスネットワークのメンバーは互いに取引するが、各メンバーは自分のトランザクションの別個の記録を保持する。また、トランザクションのオブジェクトは、それらが販売されるたびに確立されるそれらの出所を有することにより、ある品物を販売するビジネスが、それ自体の品物の所有権を検証する所有権変遷履歴を所有することを保証できる。

一実施形態によれば、現在のビジネスネットワークがコンピューティングシステムによって現代化されているにもかかわらず、ネットワーク参加者のアイデンティティを管理するための統一されたシステムは存在していない。セキュリティトランザクション（その世界全体での金額は何兆ドルにも達する）を明らかにするには数日かかるので、出所を確立することは手間がかかる。コントラクトは手作業で署名され実行されなければならない。また、システムにおけるあらゆるデータベースは固有の情報を含み、したがって単一障害点を表わす。

一実施形態によれば、ブロックチェーンは、ネットワーク上にアイデンティティを確立し、トランザクションを実行し、データを格納するための標準的方法を提供することにより、トランザクションの標準的システムによって表わされる非効率のうちの多くに対する代替物を提供する。

一実施形態によれば、ブロックチェーンネットワークでは、それへの各参加者は、台帳の自分用の複製されたコピーを有する。台帳情報が共有されることに加えて、台帳を更新するプロセスも共有される。参加者のプライベート台帳を更新するために参加者のプライベートプログラムが使用される他のシステムとは異なり、ブロックチェーンシステムは、共有台帳を更新するための共有プログラムを有する。

一実施形態によれば、共有台帳を通してビジネスネットワークを調整する能力を用いて、ブロックチェーンネットワークは、信用および可視性を向上させつつ、個人情報および処理に関連付けられた時間、コスト、およびリスクを減少させることができる。

ハイパーレッジャーファブリック
一実施形態によれば、ハイパーレッジャーファブリックは、他のブロックチェーン技術と同様に、台帳を有し、スマートコントラクトを使用する。また、ハイパーレッジャーファブリックは、参加者が自分のトランザクションを管理するシステムである。

一実施形態によれば、ハイパーレッジャーファブリックが他のいくつかのブロックチェーンシステムと異なっているところは、それがプライベート用で許可型であるということである。いくつかのブロックチェーンネットワークがアイデンティティを検証するために使用する「プルーフ・オブ・ワーク」（それらの基準を満たす人は誰でもネットワークに加入できる）の代わりに、ハイパーレッジャーファブリックネットワークのメンバーは、メンバーシップサービスプロバイダを通して登録する。

一実施形態によれば、ハイパーレッジャーファブリックはまた、いくつかのプラグ可能なオプションを提供する。台帳データは複数のフォーマットで格納可能であり、コンセンサスメカニズムはインおよびアウトに切替可能であり、異なるＭＳＰ（Membership Service Provider：メンバーシップサービスプロバイダ）がサポートされる。

一実施形態によれば、ハイパーレッジャーファブリックはまた、チャネルを作成する能力を提供し、参加者のグループがトランザクションの別個の台帳を作成することを可能にする。これは、一部の参加者が競合企業かもしれず、自分が行なうトランザクション（たとえば、一部の参加者のみに提供している特別価格）のすべてを全参加者には知らせたくない場合に、ネットワークについてのオプションを可能にする。２人の参加者があるチャネルを形成する場合、それらの参加者のみがそのチャネルについての台帳のコピーを有する。

共有台帳
一実施形態によれば、ハイパーレッジャーファブリックは、ワールドステートとトランザクションログという２つのコンポーネントを含む台帳サブシステムを有する。各参加者は、自分が属するすべてのハイパーレッジャーファブリックネットワークの台帳のコピーを有する。

一実施形態によれば、ワールドステートコンポーネントは、所与の時点での台帳の状態を記述する。それは、台帳のデータベースである。トランザクションログコンポーネントは、ワールドステートの現在の値をもたらしたすべてのトランザクションを記録する。それは、ワールドステートのための更新履歴である。台帳はその場合、ワールドステートデータベースとトランザクションログ履歴との組合せである。

一実施形態によれば、共有台帳は、ワールドステートのための取替可能なデータストアを有する。デフォルトにより、これは、LevelDBキー値ストアデータベースである。トラ
ンザクションログは、プラグ可能である必要がない。それは単に、ブロックチェーンネットワークによって使用される台帳データベースの事前および事後の値を記録する。

スマートコントラクト
一実施形態によれば、ハイパーレッジャーファブリックスマートコントラクトはチェーンコードで書かれており、ブロックチェーンの外部のアプリケーションが台帳と対話する必要がある場合にそのアプリケーションによって呼び出される。多くの場合、チェーンコードは、台帳のデータベースコンポーネントであるワールドステートとのみ対話し（たとえば、それに問合せる）、トランザクションログとは対話しない。

コンセンサス
一実施形態によれば、トランザクションは、たとえそれらがネットワーク内の参加者の異なる集合間で起こったものであっても、それらが起こった順序で台帳に書かれる。これが生じるために、トランザクションの順序が確立され、また、誤って（または悪意を持って）台帳に挿入された不良トランザクションを拒否するための方法が導入され得る。

一実施形態によれば、ハイパーレッジャーファブリックは、ネットワークエンティティ（たとえば、ネットワークユーザ、ピア、スタータ）が、参加者間に存在する関係を最も良く表わすコンセンサスメカニズムを選択することを可能にする。プライバシーと同様に、それらの関係において高度に構造化されたネットワークから、よりピア・ツー・ピアであるネットワークまで、さまざまなニーズがある。

チェーンコード
一実施形態によれば、チェーンコードは、資産と、資産を修正するためのトランザクション命令とを定義するソフトウェアを含み得る。それはビジネスロジックである。チェーンコードは、キー値ペアまたは他の状態データベース情報を読出すか変更するための規則を実施する。チェーンコード機能は、台帳の現在の状態データベースに対して実行され、トランザクション提案を通して始動される。チェーンコードの実行は、ネットワークに提出されてすべてのピア上の台帳に適用され得る１組のキー値書込み（書込みセット）をもたらす。

台帳の特徴
一実施形態によれば、台帳は、ファブリックにおけるすべての状態トランザクションの、配列された改ざんされにくい記録である。状態トランザクションは、参加当事者によって提出されたチェーンコード呼び出し（「トランザクション」）の結果である。各トランザクションは、作成、更新、または削除として台帳にコミットされる１組の資産キー値ペアをもたらす。

一実施形態によれば、台帳は、配列された不変の記録をブロックに格納するためのブロックチェーンと、現在のファブリック状態を保持するための状態データベースとから構成される。チャネルごとに１つの台帳があってもよく、各チャネルは、参加者の特定のグループに見えるトランザクションの別個の台帳を含む。各ピアは、それらがメンバーであるチャネルごとに台帳のコピーを保持する。

チャネルを通したプライバシー
一実施形態によれば、ハイパーレッジャーファブリックは、チャネルごとの不変の台帳と、資産の現在の状態を操作し修正する（すなわち、キー値ペアを更新する）ことができるチェーンコードとを採用する。台帳はあるチャネルの範囲に存在し、それは（すべての参加者が１つの共通チャネル上で動作していると仮定すると）ネットワーク全体にわたって共有され得る。または、それは参加者の特定の集合のみを含むように私有化され得る。

一実施形態によれば、後者のシナリオでは、そのような参加者は別個のチャネルを作成し、それにより、自分のトランザクションおよび台帳を隔離／分離することができる。全体透明性とプライバシーとの間のギャップを埋めたいシナリオを可能にするために、チェーンコードは、読出しおよび書込みを行なうために資産状態にアクセスする必要があるピアにのみインストールされ得る（たとえば、チェーンコードがあるピアにインストールされていない場合、台帳と適切にインターフェイス接続することはできないであろう）。データをさらに曖昧にするために、チェーンコード内の値を、台帳に付加する前に、ＡＥＳ（Advanced Encryption Standard：アドバンスト・エンクリプション・スタンダード）などの共通暗号アルゴリズムを使用して（部分的にまたは全体的に）暗号化することができ
る。

セキュリティ＆メンバーシップサービス
一実施形態によれば、ハイパーレッジャーファブリックは、すべての参加者がアイデンティティを知っているトランザクションネットワークを提供する。パブリックキーインフラストラクチャが、組織、ネットワークコンポーネント、およびエンドユーザまたはクライアントアプリケーションに結合される暗号証明書を生成するために使用される。その結果、データアクセス制御が、より広いネットワーク上で、およびチャネルレベルで操作され、管理され得る。ハイパーレッジャーファブリックのこの「許可型」の概念は、チャネルの存在および能力と組合されて、プライバシーおよび機密性が最重要課題であるシナリオに対処するのに役立つ。

コンセンサス
一実施形態によれば、分散型台帳では、コンセンサスは、単にトランザクションの順序について同意すること以上のことを包含し得る。この差別化は、ハイパーレッジャーファブリックにおいて、提案および承認から順序付け、有効性確認、およびコミットメントまでのトランザクションフロー全体におけるその基本的役割を通して強調される。コンセンサスは、ブロックを含む１組のトランザクションの正確性の全面的検証として定義され得る。

一実施形態によれば、コンセンサスは、ブロックのトランザクションの順序および結果が明示的なポリシー基準チェックを満たす場合に達成される。これらのチェックおよびバランスはトランザクションのライフサイクル中に行なわれ、どの特定のメンバーがあるトランザクションクラスを承認しなければならないかを指示するための承認ポリシーと、これらのポリシーが実施され支持されることを保証するシステムチェーンコードとの使用を含む。コミットメントに先立ち、ピアはこれらのシステムチェーンコードを採用して、十分な承認が存在すること、および、それらが適切なエンティティから生じたことを確認することができる。さらに、トランザクションを含むブロックが台帳に付加される前に、台帳の現在の状態が同意または承諾されるバージョニングチェックが行なわれ得る。この最終チェックは、データ完全性を損ない得る二重支払い動作や他の脅威に対する保護を提供し、機能が非静的変数に対して実行されることを可能にする。

一実施形態によれば、行なわれた承認、有効性、およびバージョニングチェックに加えて、進行中のアイデンティティ検証もトランザクションフローにおいて生じている。アクセス制御リストがネットワークの階層上で実現され（チャネルへのオーダリングサービス）、また、トランザクション提案が異なるアーキテクチャコンポーネントを通過するにつれて、ペイロードが繰り返し署名され、検証され、認証される。コンセンサスはトランザクションのバッチの同意された順序に限定されておらず、むしろ、それは、提案からコミットメントまでのトランザクションのフロー中に行なわれる進行中の検証の副産物として達成されるプロセスである。

ブロックチェーンクラウドサービス − アーキテクチャ
一実施形態によれば、クラウドシステム（たとえば、ブロックチェーンクラウドサービス（ＢＣＳ））などのシステムは、上述のハイパーレッジャーファブリックを始点として利用することができる。そのようなシステムは、新しいブロックチェーンベースのアプリケーションの構築および／または既存のＳａａＳ、ＰａａＳ、ＩａａＳおよびオンプレミスアプリケーションの拡張を可能にする、極めて高度で差別化された企業グレードの分散型台帳クラウドプラットフォームを提供する。

一実施形態によれば、システムは、スケーラビリティ、セキュリティ、頑強性、統合、
および性能といったミッションクリティカルな企業ニーズをサポートして、採択への障壁を取り除き、生産中のブロックチェーンアプリケーションをサポートすることができる。システムは、プラットフォーム・アズ・ア・サービス（ＰａａＳ）クラウドソリューションとしてＢＣＳを提供することにより、ユーザがブロックチェーンをデプロイメントし、構成し、管理し、監視して、ブロックチェーンを企業にデプロイメントするためのコストを下げることを可能にする。システムはまた、ブロックチェーンアプリケーションの開発および他のプラットフォームとの統合を加速する。システムにより、ＳａａＳクラウド顧客は、調達、支払い、貿易金融、会計、ＨＲ、ＣＸのような自分の企業プロセスが、ブロックチェーンクラウドプラットフォームを使用して、第三者アプリケーションおよび外部分散型台帳技術とデータを安全に共有し、分散トランザクションを行なうことを可能にする。

一実施形態によれば、システムは、ＰａａＳマネージャ（たとえば、オラクルＰａａＳサービスマネージャ（ＰＳＭ）プラットフォーム）に基づくクラウドサービスである。一般に、そのようなシステムは、計算空間（たとえば、外部計算空間）で実行される管理されたクラウドサービスである。実施形態では、システムは、オラクルアイデンティティクラウドサービス（ＩＤＣＳ）、オラクル・ロードバランサ・アズ・ア・サービス（ＬＢａａＳ）、オラクルイベントハブクラウドサービス、およびオラクルクラウドストレージを使用して階層化されたコンテナランタイムサービス環境（Dockerまたはアプリケーションコンテナクラウドサービスなど）を含むＰＳＭプラットフォームの特徴を利用する。各顧客ブロックチェーンはプロビジョニングされ、テナントとして実行され得る。システムは複数のブロックチェーンをサポートし、それらは各々、マルチテナント環境において別個のテナントとしてプロビジョニングされ、実行される。

一実施形態によれば、したがって、システムは、アプリケーションまたは顧客アプリケーションが、それらのアプリケーションにとって必要なまたは望ましい程度スマートコントラクトを用いて分散型台帳を実現することを可能にする。そのようなシステムのクライアントおよびユーザは、クラウド（ブロックチェーン信用）の内部または外部にあってもよく、いくつかのブロックチェーンネットワークは、クラウド環境の外部のコンポーネントを含んでいてもよい（または、ある特定のクラウドに制約され得る）。

一実施形態によれば、そのようなシステムは、特に信用およびアイデンティティの問題を解決すべき多当事者間トランザクションにおけるさまざまなアプリケーション機能にとって有用であり得る。他のブロックチェーンシステムとは異なり、提供されるシステムサービスは匿名のものではない。実際、アイデンティティおよび監査可能性は、基本的で総合的な要素である。したがって、ＢＣＳは、たとえば資本市場、国境を越えたトランザクション、金融サービス、資産トランザクション、法的調整アプリケーション、ヘルスケア記録、出版、物流、トレーサビリティ、および偽造防止においてアプリケーションを見つける。

一実施形態によれば、上述のように、ブロックチェーン上の各当事者は、（台帳がある当事者にプロビジョニング／私有化されていない限り）データベース全体およびその完全な履歴へのアクセスを有する。どの単一の当事者も、データまたは情報を制御しない。すべての当事者はまた、そのトランザクションパートナーの記録を、仲介役を通さずに直接検証することができる。通信は、中央ノードを通る代わりに、ピア間で直接生じる。各ノードは、情報を格納し、他のすべてのノードに転送する。いったんトランザクションがデータベースに入力され、アカウントが更新されると、記録を変更することはできない。なぜなら、それらは、それらの前に生じたすべてのトランザクション記録にリンクされているためである（よって、「チェーン」という用語が使用される）。トランザクションにエラーがある場合、エラーを覆すために新しいトランザクションを使用しなければならず、
その場合、双方のトランザクションが、プロビジョニングされたユーザには見える。新しい有効トランザクションを追加するために、参加者はその有効性にコンセンサスメカニズムを介して同意することができる。ブロックチェーンにおける参加者は、資産がどこから生じたか、および、資産の所有権が時間とともにどのように変わってきたかを証明することができる。デジタル署名が、文書を認証するために使用可能であり、アクセス制御［さまざまなレベルの許可］およびプログラム可能性［実行可能なビジネス規則］に配置可能である。

一実施形態によれば、多くの多当事者間トランザクションでは、ある当事者が資産またはサービスを受け取るとお金がやりとりされる。典型的にはトランザクション時間に起因して、どちらか一方の当事者が、他方の当事者よりも先に商品またはお金を委ねなければならない。いくつかの環境では、コントラクトにおける条件の完了までエスクローで資金を保持する仲介役を使用することによって、信用問題が解決される。これは、元々の当事者間の信用問題を解決する。しかしながら、そのような方法は、信頼されるべきもう一人の中心となる当事者を追加し、複雑性、およびおそらくはトランザクションのコストを増加させる。提供されるシステムの一部としてのスマートコントラクトの使用は、仲介役の必要性をなくすことができ、当事者は、仲介役を有することなく、信用されたトランザクションをブロックチェーン上で行なうことができる。

一実施形態によれば、ＢＣＳなどの提供されるシステムの利点は、そこに含まれる情報が分散されているということを含む。監査可能性が利用可能でありながら、アクセスが制御され、ある程度のプライバシーが維持され得る。さらに、ブロックチェーン台帳は本質的に不変であり、否認できない。台帳は、ブロックのリストから構成される。各トランザクションブロックは、ブロックＩＤ、前のハッシュ、データハッシュ、タイムスタンプ、トランザクションＩＤリスト、アクション（１．．ｎ）、チェーンコードＩＤ、チェーンコード提案、応答（ｒ／ｗセット、イベント、成功または失敗）、エンドーサを含む。各ブロックは前のハッシュとそれ自体のハッシュとを含むため、ブロックは本質的に順序付けられており、いったん知られる／分散されると不変である（注：現在のブロックのハッシュは、前のブロックのハッシュと現在のブロックにおける他のデータとのハッシュであり、よって、チェーンにおけるブロックをリンクする）。コンセンサスは、差異を解消することができる。集中化データベースまたは仲介役と比べて、中心となる機関に過度の権限を与える必要がない。台帳の分散される性質はまた、分散されるコピーの使用、およびコンセンサスが、（アルゴリズム的には可能な場合であっても）修正を難しくするという点で、ブロックチェーン記録技術の基本的不変性を増大させる。このため、トランザクションの順序付けを考慮すると、誰かがチェーンにおける最新のブロックのコピーを有する場合、台帳をハッキングすることはほぼ不可能である。

いくつかの実施形態によれば、以下に説明されるように、提供されるシステムは、オラクルＰａａＳサービスマネージャ（ＰＳＭ）プラットフォームに基づくことができ、ファブリックベースのブロックチェーンのプロビジョニング、監視、および構成を単純化／促進／自動化する管理コンソールを用いて増大される。加えて、単一のＲＥＳＴ ＡＰＩを含むＲＥＳＴプロキシサービスが、アプリケーションとブロックチェーンファブリックとの接触を単純化するために提供される。開発者らはスマートコントラクトを構築し、管理コンソールを使用してスマートコントラクトをデプロイメントし、次に、アプリケーションにブロックチェーン上でスマートコントラクトを非同期的に（それはデフォルトである）または同期的に（即時の返答が望ましい場合）呼び出させることができる。ＲＥＳＴプロキシサービスおよびＡＰＩは、プラットフォームの必要性に依存して、同期および非同期双方の能力を提供する。

一実施形態によれば、ファブリックＣＡサーバは、ファブリックのためのメンバーシッ
プサービスを提供することができる。ファブリックＣＡサーバは、ユーザについての認証と、ブロックチェーン（ピアおよびオーダーのグループ）にアクセスするための認証と、アプリケーションクライアント、ピア、およびオーダーに証明書を配送できるＣＡサーバという３つの部分を含み得る。ファブリックＣＡは、認証および認可を実現するために証明書を利用することができる。証明書は、認証のための登録証明書と、認可のためのトランザクション証明書という２つのタイプを含む。一実施形態によれば、ＩＤＣＳなどのアイデンティティサービスも、認証および認可を提供することができる。

ハイパーレッジャーファブリック
上述のように、一実施形態では、提供されるシステムは、スマートコントラクトを実行するための分散型台帳プラットフォームを提供するハイパーレッジャーファブリックを実現することができる。ファブリックは、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。代替的な実施形態では、ブロックチェーンクラウドサービスは、たとえば、ここに引用により援用される、２０１６年５月３１日に出願された「分散型台帳システムにおける説明責任および信用」（Accountability And Trust In Distributed Ledger Systems）と題された米国特許出願連続番号第１５／１６９，６２２号（米国公報第２０１７／０２３６１２０号）に記載されるような「テンダーミント」（Tendermint）台帳システムを含む、代替的な分散型台帳プラットフォームを実現する。

一実施形態によれば、ハイパーレッジャーファブリックの分散型台帳プロトコルは、ピアによって実行される。以前のブロックチェーン技術の１つの欠点は、すべてのピアがすべてのトランザクションを記録することを要求されるということである。これはかなりのＩ／Ｏおよびプロセッサオーバーヘッドを生み出し、企業グレードのシステムへと便利にスケール変更されない。ハイパーレッジャーファブリックは、２種類のピアを区別する。有効性確認ピアは、コンセンサスを実行し、トランザクションの有効性を確認し、台帳を維持することについて責任を負う、ネットワーク上のノードである。一方、非有効性確認ピアは、（トランザクションを発行する）クライアントを有効性確認ピアに接続するプロキシとして機能するノードである。非有効性確認ピアはトランザクションを実行しないが、それはトランザクションを検証してもよい。ピアのタイプ／機能の分離は、システムのスケーラビリティを向上させる。

一実施形態によれば、ハイパーレッジャーの特徴は、チェーンコードと呼ばれる任意のスマートコントラクトを実行する、即時の最終性を有する許可型ブロックチェーンである。ユーザ定義のチェーンコードスマートコントラクトはコンテナ内にカプセル化され、システムチェーンコードはピアと同じプロセスで実行される。チェーンコードの実行はトランザクションの順序付けから区分されており、ノードタイプにわたる信用および有効性確認の要求されるレベルを制限し、ネットワークオーバーヘッドを減少させる。

一実施形態によれば、ハイパーレッジャーファブリックにおけるチャネルは、共通ネットワーク上で資産を交換する競合ビジネスおよび規制産業によって必要とされる高度のプライバシーおよび機密性を有する多面的トランザクションを可能にする。不変の共有台帳は、チャネルごとに全トランザクション履歴を符号化しており、効率的な監査および論争解決のための問合せ能力を含む。台帳はあるチャネルの範囲に提供され、それは（すべての参加者が１つの共通チャネル上で動作していると仮定すると）ネットワーク全体にわたって共有され得る。または、それは１組の参加者のみを含むように私有化され得る。

一実施形態によれば、ハイパーレッジャーファブリックは、ＴＬＳ証明書、登録証明書、およびトランザクション証明書についての証明機関（certificate authority：ＣＡ）
へのサポートを通してセキュリティを実現する。パブリックキーインフラストラクチャが
、組織、ネットワークコンポーネント、およびエンドユーザまたはクライアントアプリケーションに結合される暗号証明書を生成するために使用される。その結果、データアクセス制御が、より広いネットワーク上で、およびチャネルレベルで操作され、管理され得る。ハイパーレッジャーファブリックのこの「許可型」の特徴は、チャネルの存在および能力と組合されて、多当事者間企業システムにおけるプライバシーおよび機密性の必要性を満たす。

一実施形態によれば、ハイパーレッジャーファブリックは、チェーンコードトランザクションを使用して資産を修正する能力を提供する。上述のように、チェーンコードは、資産と、資産を修正するためのトランザクション命令とを定義するソフトウェアである。

一実施形態によれば、総合的なコンセンサスメカニズムは、提案および承認から順序付け、有効性確認、およびコミットメントまでの、ハイパーレッジャーファブリックにおけるトランザクションフローにおける基本的役割を有する。コンセンサスは、上述のように、ブロックを含む１組のトランザクションの有効性の検証である。コンセンサスは究極的には、ブロックのトランザクションの順序および結果が明示的なポリシー基準チェックを満たす場合に達成される。

図１Ａは、ブロックチェーンサービスを提供するシステムのファブリックにおけるトランザクションフローを示す。より具体的には、この図は、一実施形態に従ったブロックチェーンクラウドサービス（ＢＣＳ）システムを示す。１で、クライアント１６０が、ファブリックＳＤＫ１６２を使用して、登録のためにファブリック証明機関１７０、１７２、１７４にアクセスする。１．１で、ファブリックＣＡが、クライアント１６０に登録証明書を返す。２で、クライアント１６０は、ファブリックＳＤＫ１６２を使用してピアコンテナ１８０にアクセスし、エンドーサ１８２からの承認を要求する。２．１で、エンドーサ１８２は、署名されたＲＷセット（読出し／書込みセット）を返す。３で、クライアント１６０のファブリックＳＤＫ１６２は、ＲＷセットとエンドーサの署名とを含む承認されたＴＸ（トランザクション）を、オーダリングコンテナ１９０のオーダリングサービスに提出する。４で、オーダラー１９２が、ピアコンテナ１８０におけるコミッタ１８４にＴＸバッチを配送する。オーダラーは、トランザクションをブロックへと順序付ける、ノードの定義された集団である。オーダリングサービスはピアプロセスから独立して存在し、ネットワーク上の全チャネルについてトランザクションを先着順で順序付ける。５および５．１で、コミッタ１８４は、台帳１８６およびワールドステート１８８への変更を適用する。ファブリック証明機関１７０は、ピアコンテナ１８０、スマートコントラクトコンテナ１６６および１６８（スマートコントラクト）、ならびにオーダラー１９２について署名および認可の有効性を確認するために使用され得る。加えて、スマートコントラクト１６８はエンドーサ１８２と通信することができる。

一実施形態では、システムは、オーダリングサービスとしてKafkaクラスタを利用する
ことができる。Kafkaとは、パブリッシュおよびサブスクライブ意味論をサポートする分
散ストリーミングサービスである。Kafkaクラスタは複数のサーバ上で実行され、記録の
ストリームをトピックと呼ばれるカテゴリーに格納する。各記録は、キー値とタイムスタンプとから構成される。Kafkaはこのため、オーダリングサービスノード（ＯＳＮ−ｎ）
とKafkaクラスタとを含むオーダリングサービスとして使用され得る。オーダリングサー
ビスクライアントは、複数のＯＳＮに接続され得る。ＯＳＮは、互いに直接通信しない。これらのオーダリングサービスノード（ＯＳＮ）は、（１）クライアント認証を行ない、（２）クライアントが単純なインターフェイスを使用してchain1に書込むことまたはそれから読出すことを可能にし、（３）それらはまた、既存のチェーンを再構成するかまたは新しいチェーンを作成する構成トランザクションのために、トランザクションフィルタリングおよび有効性確認を行なう。Kafkaにおけるメッセージ（記録）は、トピックパーテ
ィションに書込まれる。Kafkaクラスタは複数のトピックを有することができ、各トピッ
クは複数のパーティションを有することができる。各パーティションは、絶えず付加される、記録の順序付けられた不変の配列である。ＯＳＮがいったんクライアント認証およびトランザクションフィルタリングを行なうと、それらは、あるチェーンに属する着信クライアントトランザクションを、そのチェーンの対応するパーティションへ中継することができる。それらは次にそのパーティションを消費して、すべてのオーダリングサービスノードにわたって共通である、トランザクションの順序付けられたリストを再び入手することができる。

一実施形態によれば、各ピアは、エンドーサおよびコミッタになる能力を有する。ピアがエンドーサになることを可能にし得る構成項目（たとえば、CORE_PEER_ENDORSER_ENABLED）がある。ピアがチャネルに加入すると、このピアはこのチャネルのコミッタになる。チェーンコードがピアにインストールされると、このピアはこのチェーンコードのための候補エンドーサになる。クライアントがトランザクションを提案すると、どのピアがエンドーサになるかを（候補エンドーサから）選択することは、クライアントの選択である。

一実施形態によれば、オーダラーがブロックをピアに配送するためのオーダリングメカニズムは、以下のとおりである。まず、ピア（たとえばリーダーピア）が、そのバージョン（最後のブロック番号）を送信することによって、オーダラーからの新しいブロックの要求を配送する。次に、オーダラーはピアのバージョンをチェックし、ａ）それがオーダラーよりも大きい場合、ピアにエラーを返す。それは、オーダーにおける台帳が失われ、EventHubから復元できないことを示す（このシナリオでは、オーダラーは作業を適切に続けることができない）。ｂ）ピアのバージョンがオーダラーよりも小さい場合、オーダラーはＲＡＭまたはローカルファイルのいずれかにおけるローカル台帳からブロックを検索し、ピアに送り返す。または、ｃ）それらが同じバージョンを有する場合、オーダラーは、新しいブロックが利用可能になるまでブロックする。EventHubから切断された新しいブロックデータが準備できると、オーダラーはそれをローカルブロックファイルまたはＲＡＭに入れるであろう。次に、配送スレッドがこのブロックを台帳から読出してそれをピアに送り返す。ピアはこのブロックを入手し、それをローカル台帳にコミットし、次に、その最新バージョンを他のピアへブロードキャストすることができる。

ＢＣＳシステムアーキテクチャ
図１Ｂは、ブロックチェーンサービスを提供するシステムのファブリックにおけるトランザクションフローを示す。より具体的には、この図は、一実施形態に従ったブロックチェーンクラウドサービス（ＢＣＳ）システムを示す。図示されるように、ブロックチェーンクラウドサービスコンポーネントは、たとえばオラクルＰａａＳサービスマネージャ（ＰＳＭ）プラットフォーム上にある計算空間１２０（たとえば、外部計算空間）にプロビジョニングされる。システムへのアクセスは、ＰＳＭ ＡＰＩ１２２およびブロックチェーンＲＥＳＴ ＡＰＩ１２４によって仲介される。外部計算１２０は、利用可能な適切なリソースにわたって着信トランザクションを分散させるために、ロード・バランシング・アズ・ア・サービスＬＢａａＳ１２６を活用する。

一実施形態によれば、ＢＣＳは、コンテナランタイムサービス環境（Dockerまたはアプリケーションコンテナクラウドサービスなど）１２８上に、ＰＳＭプラットフォームを用いて構築されたアプリケーションコンテナ階層化サービスである。ＢＣＳエンティティの各々は、別個のコンテナ上で実行される。ＢＣＳエンティティの各々は、コンテナランタイムサービスに対して１対１対応である。ブロックチェーンクラウドサービスは、上述のハイパーレッジャーファブリックの特徴を実現する。基本的なファブリックネットワークを構築するコンポーネントに加えて、いくつかのコンポーネントが、ハイパーレッジャーファブリックをブロックチェーンクラウドサービスに活用するために開発されている。こ
れらのコンポーネントは、これらのコンポーネントをデプロイメントするために別々のデプロイメント挙動およびバイナリを必要とする。クラウドスタックマネージャは、設計図によって定義されたすべてのサービスの、スタックと呼ばれる単一ユニットとしてのプロビジョニングを自動化する権限をユーザに与えるために使用され得る。

一実施形態によれば、ＢＣＳは、スマートコントラクトを実行するための分散型台帳プラットフォームの実現化例である、ハイパーレッジャーファブリックの実現化例を提供する。ＢＣＳは、コンテナ技術を活用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。

一実施形態によれば、ファブリックの分散型台帳プロトコルは、ピアによって実行される。ファブリックは、２種類のピアを区別する。有効性確認ピアは、コンセンサスを実行し、トランザクションの有効性を確認し、台帳を維持することについて責任を負う、ネットワーク上のノードである。一方、非有効性確認ピアは、（トランザクションを発行する）クライアントを有効性確認ピアに接続するプロキシとして機能するノードである。非有効性確認ピアはトランザクションを実行しないが、それはトランザクションを検証してもよい。ファブリックリリースのいくつかの主な特徴は、チェーンコードと呼ばれる任意のスマートコントラクトを実行する、即時の最終性を有する許可型ブロックチェーンを含む。ユーザ定義のチェーンコードスマートコントラクトはコンテナ内にカプセル化され、システムチェーンコードはピアと同じプロセスで実行される。ファブリックは、ＴＬＳ証明書、登録証明書、およびトランザクション証明書についての証明機関（ＣＡ）へのサポートを通して、コンセンサスプロトコルおよびセキュリティを実現する。

一実施形態によれば、ＢＣＳエンティティは、コンテナランタイムサービス１２８を有する階層状コンテナインスタンスにおいて実行される。コンテナは、ＰＳＭの動作をプロビジョニングすることによって作成および／または起動される。ファブリックＣＡコンテナ１３０は、ＢＣＳファブリックＣＡ（証明機関）コンポーネントが提供されるコンテナである。ＢＣＳピア（コンテナ）１３２は、読出し／書込み動作を台帳コンポーネントに行なうために台帳を保持し、チェーンコードコンテナを実行するＢＣＳピアネットワークエンティティが実行されているコンテナである。ＢＣＳオーダリングコンテナ１３４は、トランザクションを全チャネル用のブロックチェーンへと順序付けるサービスを提供するＢＣＳオーダラーが実行されているコンテナである。ＢＣＳチェーンコード実行コンテナ１３９は、ピアエンティティによって作成され起動されるコンテナである。このコンテナでは、チェーンコード実行ユニットが親ピアエンティティと通信して、ブロックチェーンにおける資産を修正するために資産およびトランザクション命令の符号化を行なう。

一実施形態によれば、ＢＣＳチェーンコードビルダーコンテナ１４０は、ピアエンティティによって作成され起動されるコンテナである。このコンテナでは、チェーンコード構築環境がインストールされてデプロイメントされ、チェーンコード実行ユニットがそこに構築される。クライアント側ファブリックＳＤＫ１０６が、ＢＣＳにアクセスするための機能性を提供する。ブロックチェーンクラウドサービスはまた、イベントハブクラウドサービス１５０、クラウドストレージサービス１５２、およびアイデンティティサービス１５４を活用する。オラクルストレージクラウドサービスは、ＢＣＳのためのストレージサービスとして使用される。

一実施形態によれば、Docker／Weave１４１は、コンテナサービスである。コンテナは
、共有のオペレーティングシステム上で分離されて実行可能なフォーマットでソフトウェアをパッケージ化するやり方を提供する。ＶＭとは異なり、コンテナはオペレーティングシステム全体をバンドルせず、代わりに、ソフトウェアを働かせるために必要なライブラリおよび設定を使用することが必要とされる。これは効率的で軽量の自給式システムを生
み出し、ソフトウェアがどこにデプロイメントされているかにかかわらず常に同じように実行されることを保証する。

一実施形態によれば、各ＢＣＳインスタンスは、異なるタイプのノードから構成される。ＢＣＳインスタンスには、少数（たとえば０またはそれ以上）〜複数のピアノードがあり得る。ＢＣＳインスタンスには、少数（たとえば０）〜複数のオーダラーノードがあり得る。ＢＣＳインスタンスには、１〜複数のファブリックＣＡノードが、ＶＭごとに１つある。ＢＣＳゲートウェイについては、ＢＣＳインスタンスには、少数（たとえば０）〜複数のＢＣＳゲートウェイがあり得る。ＢＣＳコンソールも、ＢＣＳインスタンスのコンポーネントである。ＢＣＳインスタンスには、ＢＣＳコンソールが１つだけある。

一実施形態によれば、ＢＣＳ管理サーバ（コンソール）１３６はＢＣＳのコンポーネントであり、それは、以下により詳細に説明されるように、豊富な監視、管理、およびビュー機能性をＢＣＳスタックインスタンスに提供する。ＢＣＳゲートウェイ（ＲＥＳＴプロキシ）１３８はＢＣＳの新しいコンポーネントであり、ＲＥＳＴ ＡＰＩインターフェイスを顧客／クライアントに提供し、以下により詳細に説明されるようなトランザクションを行なうためにファブリックにアクセスするために使用される。

一実施形態によれば、パブリックアクセスクライアント側１００で、ＰＳＭコンソールＵＩ１０２は、プラットフォームサービスマネージャの管理を可能にする。ＢＣＳコンソールＵＩ１０４は、ＢＣＳ管理サーバの制御を可能にする。ファブリックＳＤＫクライアント１０６、ＢＣＳ ＲＥＳＴクライアント１０８、およびファブリックメンバーシップクライアント１１０を含む、さまざまな異なるクライアントタイプが、ＢＣＳサービスにアクセスすることができる。

一実施形態によれば、個々のサービスタイプとして上にリストされたコンテナタイプごとに、設計図を定義することができる。オラクルクラウドスタックマネージャは、これらの設計図を使用して、すべての個々のサービスタイプの単一スタックユニットへのプロビジョニングを自動化する。ＢＣＳエンティティごとにサービスタイプを定義する利点は、実行中のさまざまなエンティティのアップグレードおよび維持が簡単であることである。コンテナランタイムサービス階層化サービスは、CREATE_SERVICE、DELETE_SERVICE、SCALE_SERVICE、および起動／停止／再起動という４つのタイプの動作をサポートする。これ
らの動作は、サービスごとに適用され得る。

一実施形態によれば、ハイパーレッジャーファブリックでは、オーダリングサービスコンポーネントはApache Kafkaを使用して、クラッシュ故障に耐性のある態様で複数のチェーンのためのオーダリングサービスおよびサポートを提供する。したがって、ＢＣＳクラウドサービスでは、オーダリングサービスコンポーネントは、ＯＥＨＣＳ（管理されたストリーミングデータプラットフォームとしてKafkaのパワーを配送し、オラクルのクラウ
ドの残りと統合され得る、オラクルイベントハブクラウドサービス）を使用するであろう。

図１Ｃは、一実施形態に従ったＢＣＳシステムを示す。より具体的には、この図はＢＣＳランタイムを示す。

一実施形態によれば、ゲートウェイベースのアプリケーション１０３および／またはファブリックベースのアプリケーション１０５などのクライアントは、インターネット１０７などのネットワークを介して、および、（以下に述べる）CloudGateを含み得るロード
バランサＬＢａａＳ１２６などのフロントエンドを介して、コンテナランタイムサービスインスタンス１２８と通信することができる。着信コールは、ＲＥＳＴ通信（図において
より濃い破線として示す）、または、状況によっては、着信ｇＲＰＣ通信（図においてより薄い破線として示す）を含み得る。着信ＲＥＳＴ通信は、（ＲＥＳＴ ＡＰＩ／ＲＥＳＴプロキシを含み得る）ゲートウェイ１３８、（上述のように）コンソール１３６、またはエージェントファブリックＣＡ１３０へ向けられ得る。ここで内部コール（ｇＲＰＣ）に変換されたＲＥＳＴ通信は、（エージェント／ピア１３２、エージェント／オーダラー１３４、チェーンコード１４２、およびチェーンコードビルダー１４０を含む）ブロックチェーンファブリック／ハイパーレッジャーのインスタンスとインターフェイス接続可能である。一方、着信ｇＲＰＣ通信は、ブロックチェーン／ハイパーレッジャーとインターフェイス接続するために、たとえばエージェント／ピア１３２およびエージェント／オーダラー１３４に直接送信され得る。

一実施形態によれば、コンテナランタイムサービスインスタンス内のトランザクションがいったん生じると、コンテナランタイムサービスインスタンスは、たとえば、ＲＥＳＴ通信を介してクラウドストレージで台帳を持続させることができ、または、同様にＲＥＳＴ通信を介してイベントハブと通信することができる。

一実施形態によれば、図にはコンテナランタイムサービスインスタンスが１つしか示されていないものの、クライアント（ゲートウェイベースのアプリケーション１０３および／またはファブリックベースのアプリケーション１０５など）が説明されたＢＣＳランタイムを介して通信することができる、１つまたは複数のコンテナランタイムサービスインスタンスが存在し得るということを、当業者であれば容易に理解するであろう。

図１Ｄは、一実施形態に従ったＢＣＳシステムを示す。より特定的は、この図は、ＢＣＳシステム内のコンポーネント濃度、すなわち、各ＢＣＳインスタンスに対するコンポーネントの比率を示す。

一実施形態によれば、ＢＣＳインスタンス１００ａごとに、オーダラー１０１ａは１：Ｎの比率で提供可能であり、ファブリックＣＡメンバーシップ１０２ａは１：Ｎの比率で提供可能であり、ＢＣＳ ＲＥＳＴプロキシ１０３ａは１：Ｎの比率で提供可能であり、ＢＣＳコンソール１０４ａは１：１の比率で提供可能であり、ピアコンテナ１０５ａは１：Ｎの比率で存在可能である。

一実施形態によれば、各ピアコンテナは、トランザクションをシミュレートできるエンドーサと、同様にピアコンテナで提供される台帳への変更を適用できるコミッタとを含み得る。

一実施形態によれば、チェーンコード１０９ａは、ピアコンテナに対して１：Ｎの比率で提供可能である。加えて、ストレージ１０６ａは、ピアコンテナおよびオーダラーに対してＮ：１の比率で提供可能である。また、イベントハブ１０７ａは、ピアコンテナおよびオーダラーに対してＮ：１の比率で提供可能である。ＩＤＣＳ１０８ａは、ファブリックＣＡメンバーシップに対してＮ：１の比率で提供可能である。

図１Ｅは、一実施形態に従った、ブロックチェーンクラウドサービスのためのインターフェイスを提供するための方法のフローチャートである。

一実施形態によれば、ステップ１７５で、方法は、少なくとも１つのプロセッサを含むコンピュータで、コンテナランタイムサービスの少なくとも１つのインスタンスと、コンテナランタイムサービスの少なくとも１つのインスタンスにおける分散型台帳コンポーネントとを提供することができ、分散型台帳はブロックチェーンクラウドサービスとしてプロビジョニングされ、ブロックチェーンクラウドサービスは、ピアコンテナと、オーダリ
ングコンテナと、チェーンコードコンテナとを含む。

一実施形態によれば、ステップ１７６で、方法は、ピアコンテナによってブロックチェーン台帳を保持することができる。

一実施形態によれば、ステップ１７７で、方法は、オーダリングコンテナによってブロックチェーン台帳内のトランザクションを順序付けることができる。

一実施形態によれば、ステップ１７８で、方法は、チェーンコードコンテナのチェーンコード実行ユニットによって台帳における資産を符号化することができる。

一実施形態によれば、ステップ１７９で、方法は、クライアントアプリケーションから着信コールを受信するように、コンテナランタイムサービスの少なくとも１つのインスタンスを構成することができ、着信コールはブロックチェーン台帳へのエントリを要求する。

ブロックチェーンクラウドサービス（ＢＣＳ）ゲートウェイ
一実施形態によれば、ＢＣＳゲートウェイ（ＢＣＳＧＷ）は、ファブリックネットワークと通信するためにファブリックＳＤＫを使用するネットワークノードを含む。ＢＣＳゲートウェイは、クライアント／クライアントアプリケーションがＢＣＳのファブリックの要素と対話することを可能にするＨＴＴＰＳ ＲＥＳＴｆｕｌ ＡＰＩを、クライアント側で顧客に提供する。

図２は、一実施形態に従った、ブロックチェーンクラウドサービスシステムのためのゲートウェイを示す。図２に示すように、エンドユーザ２００は、ＨＴＴＰＳを使用して、認証および認可のためにアプリケーションアダプタ２０２と対話する。アプリケーションアダプタ２０２は、CloudGate２１２（すなわち、ＬＢａａＳ）などのＬＢａａＳへのＨ
ＴＴＰＳを使用して、パブリッククラウド２１０にアクセスする。ロード・バランシング・アズ・ア・サービス（ＬＢａａＳ）は、着信トランザクションのために行なわれる。CloudGate２１２は、ＨＴＴＰＳを使用して、トランザクションをＢＣＳゲートウェイ２２
２へ渡す。ＢＣＳゲートウェイは、通信がｇＲＰＣリモートプロシージャコールプロトコルを利用するＢＣＳファブリック２２０へのインターフェイスを提供する。

一実施形態によれば、CloudGate２１２は、たとえばOAuth2およびOpenID Connect規格
を使用してウェブブラウザおよびＲＥＳＴ ＡＰＩリソースを安全にする、リバースプロキシ「アクセス実施モジュール」または「ポリシー実施ポイント」である。ＩＤＣＳは、CloudGateを内部で使用して、それ自体の管理ＵＩおよびＲＥＳＴ ＡＰＩを安全にする
（「ＩＤＣＳウェブ層」と呼ばれる）。他のアプリケーションについては、クラウドゲート：ＯＴＤが、非ＩＤＣＳまたはスタンドアロンとして公知である、半分サポートされた／暫定的な設定において、追加のインスタンスとしてデプロイメントされる。

一実施形態によれば、OAuth／OpenIDベースの認証は、（ＵＩクライアントのための）
ユーザブラウザフローをサポートし、それは、ＨＴＴＰ要求が「ユーザ−エージェント」ヘッダを含む場合、すなわち、その要求がブラウザまたはモバイルアプリのようなＵＩからのものである場合にトリガされる。CloudGateは、クレデンシャル（ユーザ名／パスワ
ード）についてユーザを促し、クレデンシャルを検証し、次に、OAuthセッションクッキ
ーを作成して返す。OAuthセッションクッキーは、ブラウザからのその後のＨＴＴＰ要求
によって使用され得る。OAuth／OpenIDベースの認証はまた、（プログラマティッククラ
イアントのための）リソースサーバフローをサポートする。このフローは、ＨＴＴＰ要求が認証「ベアラ」トークンヘッダを含む場合にトリガされる。CloudGateは、認証のため
にトークンの有効性を確認する。

一実施形態によれば、ＨＴＴＰ基本認証のために、ＨＴＴＰ要求ごとに、クレデンシャル（ユーザ名／パスワード）がＨＴＴＰ認可「基本」ヘッダに含まれていなければならない。クラウドゲートは、ＨＴＴＰ要求ごとにクレデンシャルを検証する。この方法は、ＵＩクライアントおよびプログラマティッククライアント双方に当てはまる。

一実施形態によれば、マルチトークンフローは、あるＨＴＴＰ要求をカバーする自己適応可能な方法である。ＨＴＴＰ要求が認可「基本」ヘッダを含む場合、CloudGateはＨＴ
ＴＰ基本挙動を行なう。ＨＴＴＰ要求が認可「ベアラ」ヘッダを含む場合、クラウドゲートは、リソースサーバフローと同様に挙動する。

一実施形態では、ＢＣＳコンソールブラウザクライアントは、ユーザブラウザフローを利用する。実施形態では、ＢＣＳコンソールおよびゲートウェイプログラマティッククライアントのために、システムは、CloudGateマルチトークン認証方法を使用することがで
きる。プログラマティッククライアントは、ＨＴＴＰ基本認証を介してＢＣＳ ＲＥＳＴ
ＡＰＩを呼び出すことができる。

一実施形態によれば、ＢＣＳゲートウェイ２２２はピア２２４と通信する。ピア２２４は、台帳を保持するとともに、台帳に読出し／書込み動作を行なうためにチェーンコードコンテナを実行する、ネットワークエンティティである。ピアは、メンバーによって所有され、保持される。ＢＣＳゲートウェイ２２２およびピア２２４は、オーダラー２２６と通信する。オーダラーは、オーダリングサービスを提供する。オーダラーは、トランザクションをブロックへと順序付ける、ノードの定義された集団である。オーダリングサービスはピアプロセスから独立して存在し、ネットワーク上の全チャネルについてトランザクションを先着順で順序付ける。ピア２２４およびオーダラー２２６は、ファブリック証明機関２２８と通信する。ＢＣＳゲートウェイ２２２はまた、ＢＣＳ管理サーバ／コンソール２３０へのアクセスを提供する。

一実施形態によれば、ＢＣＳは、オラクルクラウドなどのクラウドシステムにデプロイメントされる。ゲートウェイは、コンテナランタイムサービスコンテナにおいて実行され得る。ゲートウェイはステートレスである。ゲートウェイは、古いゲートウェイを止めて新しいゲートウェイを起動することによって更新され得る。ＢＣＳゲートウェイは、ＲＥＳＴｆｕｌプロトコルによって、顧客問合せを可能にするかまたはファブリックチェーンコードを呼び出すことができる。ＢＣＳゲートウェイは、クライアントがＨＴＴＰＳ／ＲＥＳＴｆｕｌサービスによってオラクルクラウドにおけるファブリックネットワークにアクセスすることを可能にする。ＢＣＳゲートウェイは、ファブリックネットワークと通信するためにファブリックＳＤＫを使用するネットワークノードである。ファブリック内の通信は、通信プロトコルとしてｇＲＰＣを使用する。クライアント側で、ＢＣＳゲートウェイは、ＨＴＴＰＳ／ＲＥＳＴｆｕｌ ＡＰＩを顧客に提供する。ＲＥＳＴ ＡＰＩは、クライアントがファブリックＳＤＫを使用してファブリック内の機能を呼び出すことを可能にする。

一実施形態によれば、ゲートウェイは、ファブリックユーザと１対１の関係で提供され得る。すべてのゲートウェイユーザは１つの組織に属し、すべてのゲートウェイユーザは、１つのゲートウェイにおいて１つのファブリックユーザにマッピングされる。１つのゲートウェイは、たった１つのファブリックユーザを構成する。

一実施形態によれば、ＩＤＣＳは、ゲートウェイ証明書およびゲートウェイユーザ（「アプリアダプタ」）証明書を発行する。これらの証明書は、組織ＣＡによって署名される
。ゲートウェイおよびゲートウェイユーザは組織ＣＡによってデプロイメント可能であり、そのため、それらはＨＴＴＰＳを使用して互いに有効性を確認してもよい。

一実施形態によれば、各エンドユーザは、「アプリアダプタ」を通してＢＣＳＧＷにアクセスする。認証には３段階ある。エンドユーザ２００は、アプリアダプタ２０２によって認証され得る。アプリアダプタ２０２は、クライアント証明書を用いてＢＣＳゲートウェイ２２２によって認証され得る。ＢＣＳゲートウェイは、ファブリックネットワーク２２０におけるピア２２４およびオーダラー２２６によって認証され得る。

一実施形態によれば、１つのコンテナは１つのtomcatサーバを実行し、１つのＢＣＳゲートウェイをデプロイメントし、１つのファブリックユーザにマッピングされる。複数のアプリアダプタが１つのゲートウェイに接続してもよい。

一実施形態によれば、異なるゲートウェイが異なるファブリックユーザに関連付けられ得る。１つのゲートウェイに接続するアプリアダプタのエンドユーザらは、１つのファブリックユーザにマッピングされることができる。

一実施形態によれば、ＢＣＳＧＷはオラクルクラウドにおいて実行され、構成がＪＳＯＮファイルを使用してＢＣＳコンソールによって設定される。Adminユーザは、ピア、チ
ャネル、およびチェーンコードの一部をゲートウェイへ発行してもよい。Adminユーザは
、コンソールによってゲートウェイを起動する。ゲートウェイは、ブート後に構成をリフレッシュしない。Adminユーザは、チェーンコードのためにエンドーサを設定することが
できる。ポリシーはエンドユーザには不明瞭であり、ゲートウェイはチェーンコードポリシーをチェックしない。

一実施形態によれば、ＢＣＳＧＷはＢＣＳコンソールによって起動される。ＢＣＳコンソールはＢＣＳＧＷ構成ファイルを作成し、ＢＣＳＧＷパッケージを使用して、新しいゲートウェイを起動する。起動時、起動スクリプトがＢＣＳＧＷ構成ファイルをチェックし、Tomcatのために構成ファイル（たとえば、Tomcat構成ファイル）を修正し、次にTomcatを起動する。TomcatはＢＣＳＧＷのためのスレッドを起動し、スレッドはチャネルごとに構成ファイルを読み、それはチャネルオブジェクトを起動して、オーダー、ピア、イベントハブとの接続を作成することができる。異なるチャネルは、オーダー／ピア／イベントハブとの異なる接続を有するであろう。ここでのイベントハブは、ピアの第２のポートである。ゲートウェイは、トランザクションの結果を入手するために、このポートに接続する。Tomcatサーブレットコンテナは、クライアント要求をリッスンして待つことができる。チェーンコードの問合せ方法については、ＢＣＳＧＷはチャネルのすべてのピアに要求を送信し、最初の結果のみを使用する。チェーンコードの呼び出し方法については、ＢＣＳＧＷはチャネルのすべてのエンドーサに要求を送信し、それらのうちの１つが成功を返した場合、ＢＣＳＧＷはチャネルのすべてのオーダラーにトランザクションを送信する。

一実施形態によれば、非同期ＡＰＩがサポートされる。ピアは２つのポートを開くことができ、１つのポートはイベント交換用である。ゲートウェイは、ピアのイベントポートに接続できる。ゲートウェイは、１つのチャネルについて１つのイベントポートに接続するだけでよい。通常のクライアントＡＰＩは同期的である。トランザクションには数秒かかる場合があり、クライアントは応答を待つ必要がある。クライアントに非同期イベントを送信することは、Ｖ１プランにはない。同期トランザクションＡＰＩに加えて、ゲートウェイは、非同期トランザクションＡＰＩ「asyncinvoke」を提供する。

一実施形態では、非同期ＡＰＩはこのように作動できる。クライアント要求のパラメータをチェックした後で、ゲートウェイはクライアントにトランザクションＩＤを返すであ
ろう。クライアントは、トランザクションが起動されたものの終わっていないことを認識できる。ゲートウェイは、トランザクションを処理し続けるために、バックグラウンドスレッドを起動するであろう。クライアントは、終わっていないトランザクションを追跡することができる。ゲートウェイは、クライアントがトランザクションＩＤを使用してトランザクションステータスを問合せるための「トランザクション」ＡＰＩを提供することができる。

一実施形態によれば、クライアントログインがサポートされ得る。ＢＣＳＧＷはＨＴＴＰＳプロトコルをサポートすることができ、安全でないＨＴＴＰアクセスを許可できない。ＢＣＳＧＷは、アプリアダプタまたはＳＡＬＴを信用するために証明書を使用する。アプリアダプタは、エンドユーザを認証することができる。Tomcatは、ＨＴＴＰＳクライアント証明書認証を使用するために設定される必要がある。keystoreファイルは、クライアントがＢＣＳコンソールによって提供されることの有効性を確認するために、ＢＣＳＧＷcertとＣＡcertとを含む。ＢＣＳゲートウェイは、クライアントアクセスのためのＢＣＳ
ＲＥＳＴインターフェイスを提供する。

持続性 − ストレージクラウド
一実施形態によれば、ハイパーレッジャーファブリックは、ローカルファイルシステムに格納されている台帳と、同様にローカルファイルシステムに格納されるLevelDBに格納
されているブロックインデックス、ワールドステート、履歴、および台帳プロバイダのような他のランタイムデータとのブロックを有する。コンテナランタイムサービスでは、コンテナファイルシステムは一時的である。すなわち、何らかのハードウェア故障に起因してコンテナが停止され、新しいコンテナが新しいＶＭ上で再起動される場合、ファイルシステムコンテンツが失われるおそれがある。コンテナがすべて失われる状況を考慮すると、その場合、台帳を復元する方法はない。そのため、台帳データは、コンテナランタイムサービスコンテナの外部で格納されなければならない。このため、持続性ソリューションが、上述のハイパーレッジャーファブリックのコンポーネントによって使用されるオブジェクトストレージサービスの形でプロビジョニングされる。

一実施形態によれば、したがってＢＣＳでは、持続性ソリューションは、ストレージクラウドサービス、たとえばオラクルストレージクラウドサービスを利用する。台帳は、オブジェクトストアへバックアップされる。台帳はコンテナファイルシステムへの書込みだけでなく、オブジェクトストレージへのバックアップをブロックする。インデックスおよびワールドステートはコンテナファイルシステムを使用して記録されるが、コンテナが再起動される場合にはストレージクラウドサービスから復元されてもよい。オラクルストレージクラウドはインフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）製品であり、それは、ファイルおよび非構造化データのための、企業グ
レードの大規模なオブジェクトストレージソリューションを提供する。

図３は、一実施形態に従った、ブロックチェーンクラウドサービスシステムのための持続性を示す。図３に示すように、コンテナランタイムサービスインスタンス３００は複数のコンテナを含む。コンテナは、たとえば、台帳／ブロックチェーン３１２および３１４を有するオーダリングコンテナ３０２および３０４を含む。台帳／ブロックチェーン３１２および３１４は、ＲＥＳＴインターフェイスを通してオブジェクトストレージ３２０へバックアップされる。オブジェクトストレージ３２０は、たとえばクラウドストレージサービスであってもよい。

一実施形態によれば、オブジェクトストレージは、各オーダラーの台帳を持続させるために使用される。オーダラーがブロックをピアに配送するための現在のメカニズムは、以下のとおりである。まず、ピアが、そのバージョン（最後のブロック番号）を送信するこ
とによって、オーダラーからの新しいブロックの要求を配送する。次に、オーダラーはピアのバージョンをチェックし、ａ）それがオーダラーよりも大きい場合、ピアにエラーを返す。それは、オーダーにおける台帳が失われ、EventHubから復元できないことを示す。このシナリオでは、オーダラーは作業を適切に続けることができない。ｂ）ピアのバージョンがオーダラーよりも小さい場合、オーダラーはＲＡＭまたはローカルファイルのいずれかにおけるローカル台帳からブロックを検索し、ピアに送り返す。ｃ）それらが同じバージョンを有する場合、オーダラーは、新しいブロックが利用可能になるまでブロックする。EventHubから切断された新しいブロックデータが準備できると、オーダラーはそれをローカルブロックファイルまたはＲＡＭに入れるであろう。次に、配送スレッドがこのブロックを台帳から読出してそれをピアに送り返す。最後に、ピアはこのブロックを入手し、それをローカル台帳にコミットする。次に、台帳の最新バージョンが他のピアへブロードキャストされ得る。

一実施形態によれば、上述のプロセスに従って、オーダラーまたはEventHubのいずれかは、ブロック全体を持続させることができる。上述のように、EventHubは、時間が制限された保存を有する。EventHubがそれをすることができる場合、オーダラーは台帳タイプをＲＡＭまたはファイルに設定することができ、いったんオーダラーが再起動されて台帳が失われると、それはEventHubから記録を再生してバッチメッセージをブロックへと切断することができ、次に、台帳を再構築することができる。EventHubが制限された保存期間のみをサポートする場合、いったんオーダラーが再起動されて台帳が失われると、それは台帳を正確に再構築することができない。なぜなら、EventHubにおける最初の記録が台帳における真の記録ではないためである。このシナリオでは、オーダラーは古いチャネルを起動することができない。なぜなら、チャネル情報を有する最初のブロックが失われ、バージョン番号（最後のブロック番号）も正しくないためである。

一実施形態によれば、その場合、各オーダラーは各ブロックをオラクルストレージまで持続させ、一方、すべてのチャネルＩＤをストレージにおけるオブジェクトに保存することもできる。ピア上では、ジェネシスブロックのみを持続させる。なぜなら、それはチャネル情報を有するためである。他のブロックデータについては、ピアは、いったんそれが失われると、それをオーダラーから検索することができる。

一実施形態によれば、コンテナランタイムサービスインスタンス３００はまた、台帳３１６、３１８とインデックス３２６、３２８とを含むピアコンテナ３０６、３０８を含み得る。ピアによって生成されるランタイムデータには、トランザクションログ（ブロックファイル）、ブロックファイルインデックス（LevelDB）、台帳プロバイダ（LevelDB）、状態データベース（LevelDBまたはcouchdb）、履歴（LevelDB）という５つのタイプがあ
る。すべてのトランザクションデータは、ローカルファイルにおけるリンクしたブロックとしてトランザクションログに格納され、それはオラクルストレージクラウドサービスまで持続されなければならない。台帳プロバイダＤＢは、すべての台帳ＩＤおよび復元ステータスをLevelDBに保存する。台帳ＩＤは、ピアが属するチャネルを識別するための固有
のｉｄである。それはオラクルストレージクラウドサービスまで持続されなければならない。他については、ピアはそれをランタイムに自動的に復元し、そのためそれらをローカルファイルシステムに保存することができる。

一実施形態によれば、オラクルストレージクラウドサービスは、ファイルをオブジェクトにアップロード／オブジェクトからダウンロードするためのＲＥＳＴ ＡＰＩを提供する。新しいブロックが生成されると、まず、それは前述のようにローカルブロックファイルに書込まれるであろう。違いは、ファイルごとに１つのブロックである。次に、このブロックファイルはオブジェクトとしてオラクルストレージにアップロードされるであろう。それが失敗した場合、ローカルファイルにおける変更はロールバックであり、エラーが
呼び出し元に返されるであろう。

一実施形態によれば、ブロックファイルインデックスについては、オーダラーが最新のチェックポイントを更新すると、まず情報をオラクルストレージまで持続させることができ、次にローカルLevelDBを更新する。動作が失敗した場合、エラーが呼び出し元に返さ
れ得る。この情報は、ブロックファイルインデックスについての復元のために使用されるであろう。オラクルストレージでは、各ピアおよびオーダラーは、ｍｓｐ ｉｄとノードｉｄとの組合せである固有のコンテナ名を有する。オブジェクト名は、チャネル名が前に付いたブロックファイルの名前である。より詳細については、オラクルストレージにおける命名規則を参照されたい。

一実施形態によれば、台帳プロバイダＤＢをオラクルストレージに保存するオプションが提供され得る。台帳プロバイダＤＢについては、LevelDB全体が、それがいったん更新
されるとオラクルストレージクラウドサービスに複製され得る。このファイルは非常に小さく、また、更新は頻繁ではないため、複製上のオーバーヘッドは無視され得る。コンテナが再起動されると、それは、それがオラクルストレージクラウドサービスに存在する場合、そこからダウンロードすることができる。オーダラーが新しいコンテナから再起動される場合、それはまず、ストレージオブジェクトからチャネルｉｄをダウンロードし、次に、チャネルｉｄによってストレージから最新のチェックポイントを入手するであろう。次に、最初のブロックから最後のブロックまで復元ブロックインデックスを起動する。この期間中、ブロックファイルは１つずつダウンロードされるであろう。その後、オーダラーは状態ＤＢおよび履歴ＤＢを復元するために起動する。ピアが新しいコンテナから再起動される場合、それはまず、台帳プロバイダＤＢを最初にダウンロードするであろう。それから、それはすべての台帳ｉｄを入手することができる。次に、台帳ｉｄによってストレージから関連ジェネシスブロックを入手する。ピアはジェネシスブロックにおける構成を起動し、オーダラーに問合せを配送して、他のブロックデータを入手する。ピアがこれらのブロックを入手した後で、それは、ブロックインデックス、状態ＤＢおよび履歴ＤＢを復元するために起動する。

一実施形態によれば、ローカルブロックファイルは、読出しキャッシュとして作用する。問合せはまず、ローカルからデータを読出すであろう。それが存在しない場合には、オブジェクトストレージからダウンロードするであろう。台帳に加えて、チェーンコードのソースコードをオラクルストレージまで持続させる必要がある。現在のファブリックでは、チェーンコードがインストールされた後で、符号化されたソースコードがピアに格納されるであろう。ピアは、各呼び出しまたはインスタンス化ごとにチェーンコードコンテナをチェックするであろう。コンテナが存在しない場合、ピアはそれをソースコードから再構築するであろう。そのため、それは、チェーンコードのインストールごとにそれをオラクルストレージにアップロードし、ピアがディスク故障から再起動されるとそれをダウンロードすることができる。

ＢＣＳ：ＳＤＫベースの構成ファイル動作およびプロビジョニング後のデプロイメント
一実施形態によれば、構成ファイルおよびデプロイメント機能は、アプリケーションをデプロイメントまたは更新する場合、ピア、オーダラー、ＣＡサーバ、およびチェーンコードを含むアプリケーションについての構成をデプロイメントし、生成開始し、更新し、入手する。これらの機能は、（Node.jsにおける）ＢＣＳコンソール、およびファブリッ
クコンテナ（ピア／オーダラー／チェーンコードコンテナ）の双方に存在する。これらの機能は、ＵＩから要求されるように構成を入手／更新し、ＳＤＫ ＡＰＩを呼び出して、必要な場合に構成変更をアクティブにするであろう。ＢＣＳコンソールバックエンドの一部としてのコンポーネントが、ＢＣＳコンソールＵＩ、ＩＤＣＳバックエンドＳＤＫ、およびすべてのＢＣＳアプリケーションと対話して、ＵＩ動作のためのＳＤＫを提供し、要
求されるような構成を入手／更新する。コンポーネントはまた、ＢＣＳアプリケーションをプロビジョニングするのにも役立つ。ＢＣＳプロビジョンコンポーネントは、ＰＳＭを使用して作成されたＶＭのDockerコンテナへＢＣＳアプリケーションをデプロイメントするであろう。この特徴は、ＢＣＳコンソールＵＩのためのＳＤＫ ＡＰＩを実現するであろう。そして、ＢＣＳプロビジョンコンポーネントは、プロビジョニング後の段階でＢＣＳアプリケーション構成およびデプロイメントを入手または更新する。プロビジョニング後の段階では、プロビジョニングシステムは、Docker／Swarm下で、ＣＡサーバ、オーダ
ラー、ピアなどのＢＣＳアプリケーションをデプロイメントするであろう。ＶＭが起動すると、それは、プロビジョニング後の作業およびＶＭの最初の作業を行なうために起動スクリプトを呼び出すであろう。

一実施形態によれば、ピア、オーダラー、ファブリックＣＡ、およびＢＣＳゲートウェイを含むファブリックコンポーネントのために構成ファイルが提供される。ＢＣＳアプリケーションパッケージ、構成、チェーンコードは、顧客のストレージクラウドサービスに格納される。

一実施形態によれば、プロビジョンシステムは、すべてのリソース割当てを完了すべきである。リソースは、ＶＭ、ネットワーク、およびストレージを含む。

一実施形態によれば、プロビジョンシステムは、すべてのリソース割当て情報をストレージサービスに保存すべきである。この情報は、ＶＭ番号およびそれらのネットワークアドレス／アカウントクレデンシャル、各ＶＭにおけるＢＣＳアプリケーション番号およびそれらのタイプ、パブリックＩＰおよび内部ＩＰを含む。そして、コンテナのための（ＶＭ間でアクセス可能な）内部ＩＰアドレスも十分あるべきである。

一実施形態によれば、ＢＣＳプロビジョンコンポーネントがプロビジョン作業を済ませると、ＶＭ起動スクリプトが起動し、次に、swarmを呼び出してコンテナランタイムサー
ビスをデプロイメントし、そしてコンテナの内部でコンテナstartup.shスクリプトが起動し、開始動作を行なうであろう。

一実施形態によれば、ＢＣＳコンソールは起動時、ストレージサービスから構成を入手し、ＵＩからのユーザ動作の入力をストレージサービスに保存し、次に、再起動コマンドをswarmに送信するであろう。

一実施形態によれば、必要とされるセキュリティ証明書をＩＤＣＳに保存することができる。それに代えて、セキュリティ証明書をＩＤＣＳから検索することができる。

一実施形態によれば、ＢＣＳコンソールバックエンドは、swarmを用いてＢＣＳアプリ
ケーションと通信することができる。

一実施形態によれば、ＢＣＳコンテナランタイムサービスが起動すると、ＢＣＳアプリケーションは、構成詳細を集めてそのアプリケーションタイプ（ピアまたはチェーンコードコンテナまたはその他）を決定し、次に、必要とされる構成をロードすることができる。

一実施形態によれば、このコンポーネントは構成を更新し、ＢＣＳアプリケーション起動シェルコードを提供する。ＢＣＳが構成ファイルを入手／更新する動作は、いくつかの部分に分割され得る。まず、ＢＣＳコンソールは起動時、ストレージから構成を入手し、更新が必要な場合に構成をＢＣＳコンソールからストレージに保存するであろう（シェルおよびNode.js）。ＢＣＳコンテナランタイムサービスが起動すると、（各Dockerコンテ
ナにおける）起動スクリプトがまず起動し、次に、そのアプリケーションタイについての構成を入手し、ＩＤＣＳ（シェル）からアプリcertを入手する。ＢＣＳコンソールＵＩがＢＣＳアプリケーションを再起動すると、それは、コンテナにおいてそのアプリケーションを再起動するよう、Docker／Swarmにメッセージを送信する。

一実施形態によれば、ＢＣＳコンソールはステートレスであり、起動されるとすべてのＢＣＳインスタンス構成を集めることができ、ＢＣＳアプリケーションに接続してそれらを監視する。構成は、ストレージサービスからバックエンドＡＰＩを介して取得されるであろう。いずれかの構成が変化すると、ＢＣＳコンソールはバックエンドＡＰＩを呼び出して、構成をストレージサービスに保存し、関連するアプリケーションを再起動するであろう。顧客がＢＣＳコンソールＵＩを介して構成項目を変更した場合、ＵＩは構成をキー／値データに符号化し、バックエンドコードはそれをファイルに変換してストレージサービスに保存するであろう。ＢＣＳコンソールは、ＢＣＳアプリケーションを監視し、起動し、停止することができる。起動コマンドおよび停止コマンドは、この機能を実現するためにDocker／SwarmＡＰＩを使用する。

ファブリックネットワークのデプロイメント
一実施形態によれば、ファブリックネットワークは、ピア、クライアント、オーダリングサービス、および、これらのエンティティ間の通信を容易にする１組のプロトコルというエンティティを含む。組織は、ファブリックネットワークのステークホルダーを構成する論理エンティティまたは団体である。ファブリックネットワークは複数の参加組織を有する。メンバーは、ネットワークのための固有のルート証明書を所有する、法的に別個のエンティティである。ピアノードおよびアプリケーションクライアントなどのネットワークコンポーネントは、メンバーにリンクされるであろう。各組織は、１人以上のメンバーを有していてもよい。１つの組織は、オーダラーおよびピアの双方、またはオーダラーのみ、またはピアのみをもたらし得る。

一実施形態によれば、ファブリックネットワークをデプロイメントする際の最初のステップは、参加者を定義することである。このステップは、ファブリックネットワークの帯域外で行なわれる。ファブリックネットワークのすべての参加組織は、たとえば、どの組織がオーダラーノードをもたらすか、およびどの組織がピアノードをもたらすかを含むネットワークの構成を取り決めて完結させる。オーダラーノードをもたらすすべての組織は、そのオーダラーサーバのためのルート証明書を発行する。ピアノードをもたらすすべての組織は、そのピアサーバのためのルート証明書を発行する。クライアントを有するすべての組織は、そのクライアントのためのルート証明書を発行する。クライアントは、１つの組織においてピアから異なるメンバーまで分離され得る。

一実施形態によれば、一例として、４つの銀行（bank1、bank2、bank3、およびbank4）が、bank1およびbank2が所有するオーダラーノードを含むオーダリングサービスを使用してブロックチェーンネットワークをデプロイメントすることを決定したとする。そして、bank1は、このネットワークにおいて唯一、オーダラーをもたらすためのものである。各
銀行は、ファブリックネットワークの組織である。bank1は、オーダラー（root_cert_1）という１人のメンバーを有する。bank2は、クライアント（root_cert_21）、ピア（root_cert22）、オーダー（root_cert23）という３人のメンバーを有する。bank3は、クライアント（root_cert31）、ピア（root_cert32）という２人のメンバーを有する。bank4は、
クライアント（root_cert41）、ピア（root_cert42）という２人のメンバーを有する。

一実施形態によれば、参加者を定義後、オーダラーおよびピアのために証明書が生成される。各オーダラーまたはピアは、それ自体を識別するために（プライベートキー、署名証明書）のペアを必要とする。各メンバーは、そのルート証明書を用いてそれ自体のファ
ブリックＣＡサーバを構成して起動し、ＣＬＩまたはＳＤＫを使用して、ＣＡサーバに、このメンバーのオーダラー／ピアサーバごとに（プライベートキー、署名証明書）を生成するよう要求することができる。ＢＣＳは、証明書を提供できるファブリックＣＡサーバを提供する。しかしながら、ファブリックＣＡサーバは、証明書を生成する唯一のアプローチではない。ユーザは、同じことをするために他のＣＡシステムを使用することができる。そのため、ファブリックＣＡサーバは、ファブリックネットワークにおける必須のコンポーネントではない。

一実施形態によれば、オーダラーおよびピアのための証明書を生成後、ファブリックネットワークは、システムチャネルを作成することによってブートストラップされる。オーダリングサービスのための（ひいては１つのファブリックネットワークのための）システムチャネルはちょうど１つあり、それは、作成される（より正確にはブートストラップされる）べき最初のチャネルである。システムチャネルは、ファブリックネットワークの構成を定義する：
●１つのオーダリングサービス
○１つ以上のオーダラー組織。各orgの
・ＭＳＰ ＩＤ
・Cert
・オーダリングサービス属性（たとえば、タイプ−ソロまたはKafka、オーダラー
アドレス、バッチサイズ／タイムアウト）
・ポリシー（だれがチャネルを作成できるか、など）
●１つ以上のコンソーシアム。各コンソーシアムは以下を含む
○１つ以上のピア組織。このファブリックネットワークに参加したいどのピア組織も、コンソーシアムのうちの１つにおいてここに定義されなければならない。各orgの
・ＭＳＰ ＩＤ
・Cert
・アンカーピア。

一実施形態によれば、ファブリックネットワークシステムチャネルがブートストラップされた後で、そのシステムチャネルのためにジェネシスブロックが作成される（チェーンにおける最初のブロック）。オーダラーサービスアドミニストレータは、そのシステムチャネルのためにジェネシスブロックを生成する。ジェネシスブロックは、ツールconfigtxgenによって（genesismethod＝file）、またはオーダラー起動中に（genesismethod＝provisional）生成され得る。configtxgenツールを使用してジェネシスブロックを生成する
場合、構成ファイルconfigtx.yamlが入力として構成され得る。このファイルは、以下の
情報を含む：ファブリックネットワークにおけるすべてのオーダラー組織のルート証明書；すべてのピア組織のルート証明書；オーダリングサービス属性：orderertype、アドレ
ス、batchtimeout、batchsize、kafka；ポリシー；チャネルリーダ：チャネル配送要求の認証および有効性確認；チャネルライタ：チャネルブロードキャスト要求の認証および有効性確認；チェーンクリエータ：チェーン作成要求の評価；Admin：チャネル再構成要求
の認証および有効性確認。

一実施形態によれば、オーダラーサービスアドミニストレータは、構成ファイルおよびジェネシスブロックを用いてオーダラーサーバを起動する。これは、ジェネシスブロックを使用してシステムチャネルを作成する。オーダラーサーバ：リッスンアドレス／ポート、ledgertypeなど；LocalMSP（プライベートキー、署名証明書）を起動するために、構成ファイルorderer.yamlが必要とされる。オーダリングサービスを提供する各組織は、そのオーダラーサーバを起動する（ジェネシスブロックは特定されるべきでない）。

一実施形態によれば、ピアノードをもたらす各組織は、ピアを識別するためのLocalMSP
（プライベートキー、署名証明書）；およびピア属性：リッスンアドレス／ポート、ブートストラップピア、ゴシップ属性などを特定するために、ピアごとに構成ファイル（デフォルト場所/etc/hyperledger/fabric/core.yaml）を準備する。そして次に、ピアサーバ
を起動する。

一実施形態によれば、オーダラーおよびピアが起動された後で、（チャネルを作成する特権を有する）チャネルアドミニストレータは、ファブリックＣＬＩまたはＳＤＫを使用して、オーダラーに、（システムチャネルで定義されたはずの）１つのコンソーシアムとそのコンソーシアムにおける１つ以上のピアorgという入力を用いてチャネルを作成する
よう要求する。各参加組織は、ファブリックＣＬＩまたはＳＤＫを使用して、そのピアのいくつかを新しく作成されたチャネルに加入させる。

例：ＢＣＳ上のファブリックネットワークのデプロイメント
図４は、ＢＣＳ上のファブリックの例示的なデプロイメントを示す。

一実施形態によれば、より特定的には、この図および説明は、ＢＣＳにファブリックネットワークをデプロイメントするためのステップを説明する。この例では、４つのエンティティＡ、Ｂ、Ｃ、およびＤが、ファブリックネットワークを作成してそれに加入することを望んでいる。４つのエンティティはオフラインで話し合い、さまざまなエンティティの責任を決定する。各エンティティは、ＯＰＣ上に１つ以上のＢＣＳインスタンスを作成する。

一実施形態によれば、エンティティＡはオーダラーおよびピアの双方を提供する。エンティティＡは、オーダラーのためのOrderer_Org1 ４０１と、ピアのためのPeer_Org1
４２１という２つのインスタンスを作成する。エンティティＡはまた、ファブリックネットワークを作成することについて責任を負う（注：オーダラーのみがファブリックネットワークを作成できる）。オーダリングサービス４００は、Orderer_Org1 ４０１およびOrderer_Org2 ４０２と、Kafkaクラスタ４１０とを含む。

一実施形態によれば、エンティティＢはオーダラーおよびピアの双方を提供する。エンティティＢは、オーダラーのためのOrderer_Org2 ４０２と、ピアのためのPeer_Org2
４２２という２つのインスタンスを作成する。

一実施形態によれば、エンティティＣはピアのみを提供する。エンティティＣは、インスタンスPeer_Org3 ４２３を作成する。

一実施形態によれば、エンティティＤはピアのみを提供する。エンティティＤは、インスタンスPeer_Org4 ４２４を作成する。

一実施形態によれば、各ＢＣＳインスタンスのアドミニストレータは、現在のorgのＣ
Ａ証明書およびadmin証明書をＢＣＳコンソールから収集する。各ピアorgのアドミニストレータは、現在のorgのアンカーピアを識別し、アンカーピアのＩＰ／ポートを収集する
。４つのエンティティは、収集されたすべての情報をオフラインで互いに交換する。

一実施形態によれば、Orderer_Org1のアドミニストレータは、前のステップで収集された情報である各orgのＣＡ証明書およびadmin証明書と各ピアorgのアンカーピアとを用い
てシステムチャネルを作成することによって、ＢＣＳコンソールからファブリックネットワークを作成する。バックエンド作業は、ジェネシスブロックを作成するためにファブリックツールを呼び出すことと、ジェネシスブロックを使用してシステムチャネルを作成するためにオーダラーを構成することとを含み得る。

一実施形態によれば、各ピアorgのアドミニストレータは、収集された他のorgのＣＡ／admin証明書を追加するためにすべてのピアノードの構成を更新し、すべてのピアノード
を再起動することによって、ＢＣＳコンソールからファブリックネットワークに加入する。

一実施形態によれば、システムで、新しいorgが既存のファブリックネットワークに加
入することを可能にするための方法が提供される。さらに、ファブリックネットワークを作成／ファブリックネットワークに加入するために、たとえば、ファブリックの形成に先立ってオフラインのアクションをカバーするために、参加者間の通信を容易にするためのユーザフレンドリーな方法が提供され得る。

チェーンコード（スマートコントラクト）コンテナ
一実施形態によれば、および上述のように、チェーンコードは、資産と、資産を修正するためのトランザクション命令とを定義するソフトウェアである。チェーンコードは、キー値ペアまたは他の状態データベース情報を読出すか変更するための規則を実施する。チェーンコード機能は、台帳の現在の状態データベースに対して実行され、トランザクション提案を通して始動される。チェーンコードの実行は、ネットワークに提出されてすべてのピア上の台帳に適用され得る１組のキー値書込み（書込みセット）をもたらす。

一実施形態によれば、情報の一貫した更新をサポートするために、および、多くの台帳機能（取引する、問合せるなど）を可能にするために、ブロックチェーンネットワークは、スマートコントラクトを使用して、台帳への制御されたアクセスを提供する。スマートコントラクトは情報をカプセル化し、それをファブリックにわたって自動的に複製することができ、それらはまた、参加者がトランザクションのある局面を自動的に実行できるようにするように書かれることもできる。

一実施形態によれば、ハイパーレッジャーファブリックスマートコントラクトはチェーンコードで書かれており、ブロックチェーンの外部のアプリケーションが台帳と対話する必要がある場合にそのアプリケーションによって呼び出される。多くの場合、チェーンコードは、台帳のデータベースコンポーネントであるワールドステートとのみ対話し（たとえば、それに問合せる）、トランザクションログとは対話しない。

一実施形態によれば、ハイパーレッジャーファブリックはDockerエンジンを利用してチェーンコードを構築し、それをデプロイメントし、それを実行されたままにする。このセクションは、ファブリックアーキテクチャと、それがＢＣＳのためのコンテナランタイムサービス階層化モデルにどのように統合されるかとについて説明する。

一実施形態によれば、ファブリックは、以下のようにユーザチェーンコードをデプロイメントし、管理する。第１に、チェーンコードを一時的ＣＣenvコンテナに構築する。第
２に、チェーンコードはソースコードとしてビルダーコンテナに転送され、静的にリンクされた必要なライブラリを用いてコンパイルされ（「Javaビルド」）、次に、バイナリがピアに送り返される。静的リンクは、実際のチェーンコードコンテナができるだけ小さくなることを可能にする。第３に、チェーンコード画像およびコンテナを構築し、それを起動する。チェーンコードコンテナは次に、ピアがシャットダウンされるかチャネルが終了されるまで実行されたままとなる。チェーンコードコンテナがクラッシュするかまたは止めた場合、画像が存在するならば、それは次の呼び出しで再起動される。設計は、ピアおよびチャネルごとに１つのチェーンコードDockerコンテナを有することである。チェーンコードはピアに明示的にインストールされる。すなわち、チャネルに加入するすべてのピアにチェーンコードが必ずインストールされているとは限らない。

一実施形態によれば、ユーザは、ピア、オーダラー、およびチェーンコードなどのコンポーネントを透過的に分散させる能力を有するコンテナランタイムサービス階層状コンテナに、ファブリックネットワークをデプロイメントすることができる。ローカルブロックストレージは信頼できる復元方法とは考えられないため、ＡＣＬＳコンテナチェーンコードバイナリがクラウドストレージに保存されると、チェーンコードランタイム環境コンテナ（ccenv）は動的に起動されるであろう。いったん構築されると、チェーンコードバイ
ナリは、コンテナクラッシュの場合に復元する目的のためにクラウドストレージにアップロードされるであろう。

一実施形態によれば、各チェーンコードインタラクションは、チェーンコードのさまざまな機能に対応することができる。唯一の制約は、チェーンコードがインスタンス化されるまでそれを呼び出したりそれに問合せることができないということである。加えて、呼び出し時、チェーンコードコンテナは、それが実行中だと判明しなければ再起動される。

図５は、一実施形態に従ったチェーンコードアーキテクチャを示す。より具体的には、この図は、一実施形態に従って、クライアント５３０がコンテナランタイムサービス環境５００においてチェーンコードをインストールし、トランザクションを実行することを可能にする、チェーンコードアーキテクチャを示す。ステップ１で、クライアント５３０はチェーンコードソースコードをピア１ ５１０にインストールする。第１に、チェーンコードを一時的ＣＣenvコンテナに構築する。クライアント５３０が「インストール」を行
なうと、それは、ビルダーエージェントを自動的に起動するビルダーコンテナを起動し、ビルダーコンテナが初期化を終えるのを待ち、チェーンコードソースコードをピアを介してビルダーコンテナに送信するであろう（ステップ２）。ビルダーエージェントが、チェーンコードを構築するであろう（Javaビルド）。チェーンコードはソースコードとしてビルダーコンテナに転送され、静的にリンクされた必要なライブラリを用いてコンパイルされ（「Javaビルド」）、次に、バイナリがピアに送り返される。静的リンクは、実際のチェーンコードコンテナができるだけ小さくなることを可能にする。いったん構築されると、チェーンコードパッケージ（tgzファイル）が、クラウドストレージ５６０にアップロ
ードされるであろう（ステップ３）。ビルダーエージェントは、後で参照するために、クラウドストレージの場所をピアに送信するであろう（ステップ４．２）。

一実施形態によれば、ピア５１０は次に、ＰＳＭ ＲＥＳＴ ＡＰＩを使用して、ＣＣenvをＡＣＬＳ（アクセス制御リスト）コンテナ５２０として起動するであろう。チェー
ンコード画像およびコンテナを構築し、それを起動する。チェーンコードコンテナは次に、ピアがシャットダウンされるかチャネルが終了されるまで実行されたままとなる。ピア５１０は、チェーンコードＩＤ、（チェーンコード登録のための）自己ＩＰ、およびクラウドストレージの場所を、起動のためにＡＣＬＳコンテナに渡すであろう（ステップ４．１）。ピアは、チェーンコードが起動するのを、または設定時間の後でタイムアウトするのを待つであろう。ccenvはチェーンコードを起動するであろう。起動時、チェーンコー
ドはそれ自体をピアに登録するであろう（ステップ４．３）。チェーンコードは、トランザクションにおける呼び出しのための準備ができるであろう（ステップ５）。それは、登録時に確立された接続を使用して行なわれるであろう。

一実施形態によれば、ビルダーコンテナ５５０は、単純なＲＥＳＴタイプサーバを含む。ビルダーコンテナ５５０は、ビルダーエージェント５５３を含む。ビルダーコンテナ５５０は起動して、チェーンコード構築要求をリッスンする。ビルダーコンテナ５５０が構築要求、たとえば本体としてbase64符号化ソースコードを有するＰＯＳＴコールを受信すると、それはソースコードをbase64復号化し、チェーンコードソースコードをローカルファイルシステムに保存する。ビルダーエージェント５５３は次に、ソースコード上で「Ja
vaビルド」を行なう。「Javaビルド」が成功した場合、ビルダーエージェント５５３はバイナリをパッケージ化してクラウドストレージ５６０にアップロードする。ビルダーエージェントはまた、チェーンコードの場所をピアに返す。「Javaビルド」が失敗した場合、エージェントはエラーおよび理由をピアに返す。

ＢＣＳ管理コンソール
一実施形態によれば、上述のように、ＢＣＳの各インスタンスは管理コンソールを含むことができ、それは、ＢＣＳゲートウェイ、ＢＣＳノード、およびＢＣＳチャネルを含むＢＣＳインスタンスを管理し、監視するために使用され得る。

一実施形態によれば、管理コンソールコンポーネントは、ＢＣＳのプロビジョニング、監視、および構成を容易にし、自動化する。管理コンソールコンポーネントは、スクリプトランタイム環境、たとえばNode.jsにおいて実行されるウェブアプリケーションを含み
得る。ウェブアプリケーションは、グラフィカルユーザインターフェイスフレームワークおよびウェブフレームワーク上に構築可能であり、ＢＣＳインスタンスにおけるさまざまなノードまたはサービスと通信するための複数のカスタム機能またはＡＰＩを含み得る。ウェブアプリケーションは、ＢＣＳインスタンスにおけるさまざまなノードまたはサービスからの情報を、コンソールユーザインターフェイスでの表示のために、ビューオブジェクトにポピュレートすることができる。管理コンソールコンポーネントはまた、アドミニストレータがＢＣＳインスタンスにおける１つ以上のノードを起動、停止、および更新するための複数の機能を提供することができる。ウェブアプリケーションによって提供されるものと同じ機能をサポートするために、１組の管理ＲＥＳＴ ＡＰＩが、スクリプトランタイム環境によって提供され、またはスクリプトランタイム環境によってアクセスされ得る。

一実施形態によれば、システムは、ウェブアプリケーションによって提供されるウェブインターフェイスを通して、または、管理ＲＥＳＴ ＡＰＩの集合を使用して書かれたカスタムＲＥＳＴクライアントアプリケーションを通して、関連付けられたＢＣＳインスタンスの監視および管理を容易にすることができる。

一実施形態によれば、管理コンソールは、１つ以上のピアノード、１つ以上のオーダラーノード、１つ以上のファブリックＣＡノード、１つ以上のＢＣＳゲートウェイノード、チャネル、および１つ以上のチェーンコードを含むＢＣＳインスタンスの複数のコンポーネントを、ＢＣＳアドミニストレータが管理できるようにすることができる。

一実施形態によれば、ＢＣＳコンポーネントを管理することは、コンポーネントを起動すること、コンポーネントを停止すること、コンポーネントを追加すること、コンポーネントを除去すること、コンポーネントの属性を見る／編集すること、コンポーネントの性能メトリックを見ること、および、コンポーネントのログを見ることという動作のうちの１つ以上を行なうことを含み得る。

図６は、一実施形態に従った、管理コンソールを提供するためのシステムを示す。
一実施形態によれば、図に示すように、ＢＣＳ管理コンソール１３６は、コンテナランタイムサービス１２８におけるＢＣＳインスタンスのコンポーネントとして提供され得る。ＢＣＳ管理コンソールは、Node.jsによって提供されるランタイム環境を表わし得るス
クリプトランタイム環境６０５において実行されるウェブアプリケーションであり得る。

一実施形態によれば、管理コンソールは、複数のバックエンドＡＰＩ６１０、たとえば、ファブリックノードサービス開発キット（ＳＤＫ）６１１、複数のファブリックカスタム機能／ＡＰＩ６１３、および複数のコンテナランタイムサービスＡＰＩ６１５を含み得
る。ＳＤＫ、カスタム機能／ＡＰＩ、およびコンテナランタイムサービスＡＰＩは、分散ストリーミングサービス（たとえばKafka）６０３を含み得るファブリックネットワーク
６０１と通信するために使用され得る。管理コンソールはさらに、ビューオブジェクト６２３を含み得る。ビューオブジェクト６２３は、ＢＣＳコンソールＵＩ１０４またはＲＥＳＴクライアント６０４に表示される必要のある情報を含み、もしくは、ＢＣＳコンソールＵＩまたはＲＥＳＴクライアントから管理コンソールに渡される必要のある情報を含み得る。ファブリックノードＳＤＫ６２１は、ファブリックネットワークからの情報と、ＢＣＳコンソールＵＩまたはＲＥＳＴクライアントからの情報とをマッピングするように動作することができる。

一実施形態によれば、ＢＣＳ管理コンソールは複数のクライアントＡＰＩ６２２を含み得る。それらは、ＢＣＳクラウドサービスをプロビジョニングし、プロビジョニングされたＢＣＳクラウドサービスを管理するために、ＢＣＳコンソールＵＩまたはＲＥＳＴクライアントによって使用され得る。プロビジョニングされたＢＣＳクラウドサービスを管理することは、ピアノード、オーダラーノード、ファブリックＣＡノード、およびＢＣＳゲートウェイノードを起動および停止することと、ピアノード、オーダラーノード、およびＢＣＳゲートウェイノードを追加および除去することとを含み得る。

一実施形態によれば、ＢＣＳ管理コンソールはさらに、ＧＵＩフレームワーク（たとえばＪＥＴ）６１７と、ウェブフレームワーク（たとえばExpress）６１９とを含み得る。
ＧＵＩフレームワークは、管理コンソールウェブアプリケーションにおいて使用され得るさまざまなユーザインターフェイス（user interface：ＵＩ）コンポーネントおよび要素を提供することができる。たとえば、ＵＩコンポーネントおよび要素は、フォームを作成し、データを収集し、データを視覚化するために使用され得る。ウェブフレームワークはJavaScript（登録商標）で書くことができ、ウェブアプリケーションおよびモバイルアプリケーションを開発するために、頑強な一組の特徴を含むウェブアプリケーションフレームワークを提供することができる。

図７Ａ〜７Ｂは、一実施形態に従った、ＢＣＳコンソールＵＩにおけるユーザインターフェイスの例を示す。

一実施形態によれば、図７Ａに示すように、ＢＣＳサマリー７１１がダッシュボードに表示され得る。サマリーは、組織の数、ピアの数、オーダラーの数、チャネルの数、およびチェーンコードの数を含み得る。

一実施形態によれば、ＢＣＳインスタンスの健全性情報７１３が表示され得る。健全性情報は、視覚的に表示され、数値的に表示され得る。サンプルＵＩはまた、トランザクション実行７１４と台帳サマリー７１５とを表示することができる。

一実施形態によれば、図７Ｂは、ＢＣＳインスタンスにおけるすべてのノードについての情報を示す。たとえば、サンプルＵＩは、（ＢＣＳゲートウェイノード内の）２つのピア、１つのオーダー、１つのファブリックＣＡ、および１つのＲＥＳＴプロキシを含む、合計５つのノードを示す。ノードごとに、サマリーＵＩ７１７は、ノードの名前７２３、ノードのルート情報７２５、ノードのタイプ７２９、およびノードのステータス情報７３１を表示する。サンプルＵＩは、アドミニストレータがノードを追加するためのボタン７２１と、ノードをフィルタリングするための１つ以上のドロップダウンリスト７１９とを含む。

ノード管理
一実施形態によれば、管理コンソールを使用してＢＣＳインスタンスを管理することが
できるエンティティは２つあり得る。それらは、ＢＣＳアドミニストレータおよびＢＣＳユーザである。ＢＣＳアドミニストレータアカウントは、ＢＣＳインスタンスごとに１つだけある。ＢＣＳアドミニストレータアカウントは、ＢＣＳインスタンスが作成されると作成され得る。ＢＣＳアドミニストレータは、ファブリックＣＡアドミニストレータとバンドルされ得る（すなわち、ＢＣＳアドミニストレータがＢＣＳコンソールから、またはＢＣＳ管理ＲＥＳＴ ＡＰＩを介して行なうアクションはすべて、ファブリックＣＡアドミニストレータアイデンティティを使用する）。ＢＣＳユーザアカウントは２つ以上あってもよく、それらは、ファブリックＣＡアイデンティティを登録することによってＢＣＳアドミニストレータによって作成され得る。

一実施形態によれば、ＢＣＳインスタンスにおけるノードは、１つのウェブページに表示され得る。管理コンソールは２つのモードをサポートすることができる。第１のモードでは、各ノードの名前、タイプ、アクセスＵＲＬ、およびステータスが、リストとしてを提示され得る。第２のモードでは、各ピアが参加しているチャネルが図表で提示され得る。

さらに、一実施形態によれば、管理コンソールは、ＢＣＳアドミニストレータが、ピアノード、オーダラーノード、ファブリックＣＡノード、およびＢＣＳゲートウェイノードを起動および停止することと、ピアノード、オーダラーノード、およびＢＣＳゲートウェイノードを追加および除去することとを可能にすることができる。ファブリックＣＡノードを追加または除去することはできない。

一実施形態によれば、ノードを追加する場合、ＢＣＳアドミニストレータは、そのノードの属性を設定することができる。新しく追加されるノードは、追加動作の一部として自動的に起動され得る。ノードが除去される場合、そのノードは停止され、ＢＣＳインスタンスから除去される。

一実施形態によれば、ＢＣＳコンソールＵＩは、アクティブなピアノードが参加しているすべてのチャネルと、アクティブなピアノードにインストールされたすべてのチェーンコードとをリストすることができる。

一実施形態によれば、ピアノードを管理する場合、ＢＣＳアドミニストレータはアクティブなピアノードを既存のチャネルに加入させること、およびアクティブなオーダラーノードの属性を見て編集することができる。ＢＣＳユーザは、アクティブなピアノードの属性のうちのいくつかを見ることができる。

一実施形態によれば、さらに、メモリ使用量、使用されるＣＰＵパーセンテージ、ネットワークＩ／Ｏ、およびディスクＩ／Ｏといった、アクティブなピアノードについてのスナップショット性能メトリックが、ＢＣＳコンソールＵＩに表示され得る。

一実施形態によれば、オーダラーノードを管理する場合、ＢＣＳアドミニストレータは、アクティブなオーダラーノードのログを見ること、アクティブなオーダラーノードの属性を見て編集することができる。ＢＣＳユーザは、アクティブなピアノードの属性のうちのいくつかを見ることができる。ピアノードの管理と同様に、ＢＣＳアドミニストレータは、メモリ使用量、使用されるＣＰＵパーセンテージ、ネットワークＩ／Ｏ、およびディスクＩ／Ｏといった、アクティブなオーダラーノードについてのスナップショット性能メトリックを見ることができる。

一実施形態によれば、ファブリックＣＡノードを管理する場合、ＢＣＳアドミニストレータは、アクティブなファブリックＣＡノードの属性を見て編集すること、アクティブな
ファブリックＣＡノードからＣＡ証明書を入手すること、および、アクティブなファブリックＣＡノードのログを見ることができる。さらに、ＢＣＳアドミニストレータは、メモリ使用量、使用されるＣＰＵパーセンテージ、ネットワークＩ／Ｏ、およびディスクＩ／Ｏといった、アクティブなファブリックノードの性能メトリックを見ることができる。

一実施形態によれば、上述のように、ＢＣＳゲートウェイノードを管理することは、ＢＣＳゲートウェイノードを追加すること、またはさらに除去することを含み得る。許容されるＢＣＳゲートウェイノードの最大数は、特定のＢＣＳインスタンスがインスタンス化される時に指定されるため、ＢＣＳインスタンスに追加され得るＢＣＳゲートウェイノードの数は、ＢＣＳゲートウェイの構成された最大許容数によって制限される。

一実施形態によれば、各ＢＣＳゲートウェイノードは、ゲートウェイノードのグローバルに固有のアイデンティティである名前を有し得る。名前は、将来ＢＣＳゲートウェイノードが構成される場合に参照され得る。ネットワークアドレスも、ＢＣＳゲートウェイノードを作成する場合に判断され、表示され得る。

一実施形態によれば、ＢＣＳゲートウェイノードを構成する場合、ＢＣＳアドミニストレータはＢＣＳゲートウェイ構成ファイルを定義し、ＢＣＳゲートウェイノードをブートストラップすることができる。ＢＣＳインスタンスがプロビジョニングされている場合、作成されるチャネルまたはデプロイメントされるチェーンコードがないかもしれない。そのため、１つ以上のチェーンコードがデプロイメントされ、有効なＢＣＳゲートウェイ構成が管理コンソールを通して定義されるまで、ＢＣＳゲートウェイノードは機能的ではない。

一実施形態によれば、ＢＣＳゲートウェイノードごとに構成ページがあり得る。ある実施形態では、以下の項目が構成ページで構成され得る：
１）チャネル：現在のゲートウェイノードを通してどのチャネルを露出すべきかを選択する；
２）チェーンコード：各チャネルにおけるすべてのインスタンス化チェーンコードのリストから、どのインスタンス化チェーンコードを露出すべきかを選択する；
３）エンドーサ：チェーンコードごとに、承認ピアを定義する；
４）上述の設定に従ってＢＣＳゲートウェイ構成を生成する。有効な構成ファイルがＢＣＳゲートウェイのためにいったん生成されると、ゲートウェイは起動され得る。

一実施形態によれば、ＢＣＳコンソールは、リストビュー機能を使用してＢＣＳゲートウェイ特性のビューを可能にする。リストビューでは、ＢＣＳゲートウェイごとに以下の情報が提供される：
１）名前：ゲートウェイ作成時に指定されたグローバルな固有の名前；
２）ファブリックアイデンティティ名：各ＢＣＳゲートウェイは、ＢＣＳゲートウェイ作成時に登録されるファブリッククライアントアイデンティティに関連付けられ得る。ＢＣＳゲートウェイが行なうアクション（たとえば、呼び出し、問合せ）はすべて、このファブリッククライアントとして命名され得る；
３）ネットワークアドレス：パブリックインターネットネットワークアドレスを有するアクセスポイント；
４）ステータス：アップまたはダウン。

一実施形態によれば、管理コンソールはまた、ＢＣＳアドミニストレータがアクティブなＢＣＳゲートウェイノードのログを見ること、および、以下のＢＣＳゲートウェイメトリックを見ることを可能にする：
１）接続されたクライアント：クライアント名、アドレス、ログオン時間など；
２）現在のトランザクション情報：現在のトランザクション情報は、状態情報、すなわち、このトランザクションがどんな状態にあるかという情報とともに、利用可能になり得る。現在のトランザクション情報は、ハングトランザクションをデバッグするのに役立ち得る；
３）トランザクション統計：トランザクション統計は、管理コンソールＵＩを通して利用可能になり得る。たとえば、トランザクション統計は、完了したトランザクションの数、受信されたイベント通知の数、および配送されたイベント通知の数を含み得る；
４）メモリ使用量；
５）ＣＰＵパーセンテージ；
６）ネットワークＩ／Ｏ；
７）ディスクＩ／Ｏ。

チャネル管理
一実施形態によれば、ＢＣＳユーザは、現在のＢＣＳインスタンスが参加しているチャネルをすべてリストすることができる。ＢＣＳアドミニストレータは、チャネル名、コンソーシアム名、および１つ以上の組織名を入力として用いて、チャネルを作成することができる。チャネル作成の成功または失敗を示すために、出力も表示され得る。

一実施形態によれば、ＢＣＳユーザは、チャネルの参加ノードおよび組織を見ることができる。管理コンソールは、リストモードとトポロジーモードという２つのビューモードをサポートすることができる。リストモードでは、（そのアンカーピアによって表わされる）参加ローカルノードおよび外部組織が、リストとしてリストされ得る。トポロジーモードでは、（そのアンカーピアによって表わされる）参加ローカルノードおよび外部組織が、トポロジー図で表わされ得る。

一実施形態によれば、ＢＣＳアドミニストレータは、チャネルにおけるピアの台帳に問合せることができる。台帳は、トランザクションブロックのリストから構成され得る。当該ブロックの各々は、ブロックＩＤ、前のハッシュ、データハッシュ、タイムスタンプ、トランザクションＩＤリスト、アクション（１．．ｎ）、チェーンコードＩＤ、チェーンコード提案、応答（ｒ／ｗセット、イベント、成功または失敗）、および１つ以上のエンドーサを含み得る。ブロックの数および呼び出しの数という統計データも表示され得る。

一実施形態によれば、ＢＣＳアドミニストレータは、チャネルにおいてインスタンス化されたチェーンコードをすべてリストすることができる。リストされた項目は、チェーンコードＩＤおよびバージョンを含み得る。ＢＣＳアドミニストレータはまた、インスタンス化トランザクションによって特定されるような経路であるPathと、インスタンス化引数という、インスタンス化チェーンコードの情報を見ることができる。

一実施形態によれば、ＢＣＳアドミニストレータは、チャネルにおけるインスタンス化チェーンコードをアップグレードすることができる。アップグレード動作は、チェーンコードの新バージョンがインストールされたターゲット承認ピア、１つ以上のオーダラー、チェーンコードバージョン、および、オプションでチェーンコードに特有の文字列配列引数であり得る引数という入力をとることができる。アップグレード動作の出力は、成功、またはエラーメッセージを有する失敗であり得る。

チェーンコード管理
一実施形態によれば、ＢＣＳアドミニストレータは、現在のＢＣＳインスタンスの任意のピアにインストールされたチェーンコードをすべてリストすることができる。リストされた項目は、チェーンコードＩＤおよびバージョンを含む。加えて、ＢＣＳアドミニストレータはまた、インストールされたチェーンコードを有するローカルピアノードと、チェ
ーンコードをインスタンス化したチャネルという、インストールされたチェーンコードの情報を見ることができる。

一実施形態によれば、管理コンソールを通して、ＢＣＳアドミニストレータは、チェーンコードを１つ以上のローカルピアノードにインストールすることができる。インストール動作のための入力は、ターゲットピア；チェーンコードタイプ、たとえば、golang／Java（登録商標）；チェーンコードの名前であり得るチェーンコードＩＤ；チェーンコードバージョン；チェーンコードのソースコードの場所であり得るチェーンコード経路；およびチェーンコードパッケージ（オプション）を含み得る。インストール動作の出力は、成功、またはエラーメッセージを有する失敗であり得る。

一実施形態によれば、ＢＣＳアドミニストレータは、チャネル名；チェーンコードがインストールされたターゲット承認ピア；オーダラー；オプションであってもよく、チェーンコードに特有の文字列配列引数であってもよい引数；および承認ポリシーという情報を入力として用いて、定義されたフォーマットで、または、定義されたフォーマットがない場合はデフォルトフォーマットで、インストールされたチェーンコードをチャネルにインスタンス化することができる。

メンバーシップ管理
一実施形態によれば、ＢＣＳアドミニストレータは、現在のＢＣＳインスタンスにおけるアイデンティティをすべてリストすること、現在のＢＣＳインスタンスのための新しいユーザ／アイデンティティを登録すること、アイデンティティの登録を取り消すこと、および、現在のＢＣＳインスタンスからユーザを除去することができる。さらに、ＢＣＳアドミニストレータは、表１に示すようなアイデンティティの以下の属性を見る／編集することができる。

一実施形態によれば、管理コンソールは、ＢＣＳユーザがそれ自体を登録または再登録することを可能にし、それは、そのユーザのためのプライベートキーおよび証明書を生成することができる。管理コンソールはまた、ＢＣＳアドミニストレータが以前に登録されたアイデンティティを取り消すことを可能にし、ＢＣＳユーザがそのパスワードを変更することを可能にする。

一実施形態によれば、ＢＣＳ管理コンソールは、関連付けられたＢＣＳインスタンスの起動または停止とともに起動または停止され得る。

一実施形態によれば、ＢＣＳ管理コンソールのログレベルを設定するやり方は２つあり得る。それらは、ＢＣＳ管理コンソール自体から設定するやり方と、管理ＲＥＳＴ ＡＰＩを使用してランタイムにログレベルを変更するやり方とである。

図７Ｃは、一実施形態に従った、管理コンソールを提供するための方法を示す。
一実施形態によれば、図７Ｃに示すように、ステップ７８１で、コンテナランタイムサービスが提供される。

一実施形態によれば、ステップ７８３で、コンテナランタイムサービスにおいて、分散型台帳および管理コンソールコンポーネントが提供される。

一実施形態によれば、ステップ７８５で、管理コンソールコンポーネントにおいて、複数のクライアントアプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）と、複数のバックエンドＡＰＩとが提供され、複数のクラ
イアントＡＰＩはクライアントアプリケーションによって呼び出されるように構成され、複数のバックエンドＡＰＩは分散型台帳の複数のノードと通信するように構成され、複数のクライアントＡＰＩは、分散型台帳をブロックチェーンクラウドサービスとしてプロビジョニングする際に、およびブロックチェーンクラウドサービスを管理する際に、複数のバックエンドＡＰＩのうちの１つ以上を使用する。

ＲＥＳＴプロキシサービス
一実施形態によれば、上述のように、ファブリックネットワーク内の異なるコンポーネント間の通信は、ｇＲＰＣプロトコルに基づいている。そのため、ファブリックネットワークに基づいたＢＣＳインスタンスは、クライアントアプリケーションに、ファブリックＳＤＫを使用してＢＣＳインスタンスにおけるチェーンコードを呼び出すよう要求するであろう。

一実施形態によれば、クライアントアプリケーションに、ファブリックＳＤＫを使用してブロックチェーンクラウドサービスと通信するよう要求することは、分散型台帳をクラウドサービスとして提供する利点を部分的に相殺する場合がある。たとえば、利点のうちの１つは、クラウドサービスがインターネット接続を用いてどこからでもアクセスされるはずであるということである。

一実施形態によれば、ＢＣＳインスタンス内のＲＥＳＴプロキシサービスコンポーネントは、分散型台帳と通信するために、ＢＣＳにおける分散型台帳のためのサービス開発キット（ＳＤＫ）を使用することができ、また、チェーンコードを通して問合せ、チェーンコードを通してトランザクションを同期的または非同期的に呼び出し、トランザクションステータスを入手し、ＢＣＳプロキシバージョンを入手するために、クライアントアプリケーションによって使用されるためのＲＥＳＴ ＡＰＩを提供することができる。ＲＥＳＴプロキシサービスコンポーネントは、分散型台帳とインターフェイス接続する際に使用するために、ＲＥＳＴコールを認証し、ＲＥＳＴコールをリモートプロシージャコール、たとえばグーグルリモートプロシージャコール（ｇＲＰＣ）に変換することができる。ＲＥＳＴプロキシサービスコンポーネントはさらに、ＢＣＳ管理コンソールコンポーネントによって提供されるものと同じ機能をサポートするＲＥＳＴ ＡＰＩを提供し、ＢＣＳインスタンスを消費するためにクライアントアプリケーションのためのユーザインターフェイスを提供することができる。

一実施形態によれば、ＲＥＳＴプロキシサービスコンポーネントは、ＢＣＳとして実現され、クラウド環境（たとえばオラクルクラウド）におけるコンテナランタイムサービスコンテナで実行される分散型台帳におけるネットワークノードであってもよく、ＰａａＳマネージャ（たとえば、オラクルＰａａＳサービスマネージャ（ＰＳＭ）プラットフォーム）によって管理されてもよい。

一実施形態によれば、ＲＥＳＴプロキシサービスコンポーネントによって提供されるＲ
ＥＳＴ ＡＰＩは、クライアントアプリケーションがＢＣＳにインストールされたスマートコントラクトにアクセスすることを可能にするＲＥＳＴ ＡＰＩと、管理コンソールコンポーネントのための管理ＲＥＳＴ ＡＰＩとを含み得る。

図８Ａは、一実施形態に従った、ＢＣＳインスタンスにおいてＲＥＳＴプロキシサービスを提供するためのシステムを示す。

一実施形態によれば、図８に示すように、ＲＥＳＴプロキシ１３８は、ＲＥＳＴオーセンティケータ８２７と、プロトコルコンバータ８２９とを含み得る。ＢＣＳ ＲＥＳＴ ＡＰＩクライアント８０８がＲＥＳＴコール８１５をＲＥＳＴプロキシに送信すると、クラウドゲート８１１に接続されたＬＢａａＳ１２６は、ＲＥＳＴがＢＣＳインスタンスにアクセスできるようにする有効なユーザ名および有効なパスワードを、ＲＥＳＴコールが含むかどうかを判断するために、コールを認証することができる。

一実施形態によれば、ＲＥＳＴコールがＬＢａａＳによって認証された場合、ＬＢａａＳはＲＥＳＴコールをＲＥＳＴプロキシに向けることができ、ＲＥＳＴプロキシは、クライアントアプリケーションにＢＣＳでの適切な認可が与えられているかどうかを判断するために、ＲＥＳＴコール８３５をＩＤＣＳ８１３に転送することができる。

一実施形態によれば、クライアントアプリケーションが適切に認可されている場合、ＲＥＳＴプロキシはＲＥＳＴコールをｇＲＰＣコール８２５に変換し、ｇＲＰＣコールをファブリックネットワーク６０１に送信することができる。ＲＥＳＴコールは、いったん内部コール（ｇＲＰＣ）に変換されると、ブロックチェーンファブリック／ハイパーレッジャーのインスタンスとインターフェイス接続することができる。

一実施形態によれば、ＲＥＳＴコールは、ｇＲＰＣライブラリ８３３を有するファブリックJavaＳＤＫ８３１に基づいたJavaアプリケーションであり得るプロトコルコンバータによって変換され得る。

一実施形態によれば、図８にさらに示すように、ＲＥＳＴプロキシは、ＲＥＳＴ ＡＰＩ８２３によって提供される１つ以上の機能を管理コンソールに露出するために、ＲＥＳＴ８２１を使用して上述のように管理コンソールと通信することができる。

図８Ｂは、一実施形態に従った、ＢＣＳインスタンスにおいてＲＥＳＴプロキシサービスを提供するためのシステムを示す。

一実施形態によれば、図８Ｂに示すように、ＲＥＳＴプロキシサービスコンポーネント８４１は、コンテナランタイムサービスコンテナ８３８におけるウェブサーバ８４０（たとえばtomcatサーバ）で実行され、単一のファブリックユーザにマッピングされ得る。さらに、ＲＥＳＴプロキシサービスコンポーネントは、JavaScriptオブジェクト表記法（JavaScript Object Notation：ＪＳＯＮ）ファイルを使用して管理コンソールコンポーネントによって提供されるユーザインターフェイスを通して構成可能であり、管理コンソールコンポーネントによって提供されるユーザインターフェイスを通して起動可能である。アドミニストレーションユーザは、ピア、チャネル、およびチェーンコードの一部を、ＲＥＳＴプロキシサービスコンポーネントに発行することができる。ＲＥＳＴプロキシサービスコンポーネントの構成へのいかなる更新も、自動的に再びロードされ得る。

一実施形態によれば、ＲＥＳＴプロキシサービスコンポーネント（ノード）は、ＢＣＳゲートウェイによって起動され得る。起動スクリプトは、ＢＣＳゲートウェイの構成ファイルをチェックすることができ、ＲＥＳＴプロキシサービスコンポーネントをホストする
ウェブサーバの構成ファイルを修正することができ、次に、ウェブサーバを起動することができる。ウェブサーバはＢＣＳゲートウェイのためのスレッドを起動して、チャネルごとに構成ファイルを読み、チャネルオブジェクトを作成することができる。ウェブサーバはまた、チャネルごとに、オーダラー、ピア、イベントハブとの接続を作成することができる。異なるチャネルは、オーダラー／ピア／イベントハブとの異なる接続を有し得る。イベントハブは、ピアの第２のポートであり得る。ＢＣＳゲートウェイは、トランザクションの結果を入手するために、このポートに接続することができる。

一実施形態によれば、ウェブサーバにおけるサーブレットコンテナは、クライアント要求をリッスンして待つことができる。チェーンコードの問合せ方法については、ＢＣＳゲートウェイはチェーンコードの２つのエンドーサに要求をランダムに送信し、最初の結果のみを使用することができる。チェーンコードの呼び出し方法については、ＢＣＳゲートウェイはチャネルのすべてのエンドーサに要求を送信し、それらのうちの１つが成功を返した場合、ＢＣＳゲートウェイはチャネルのすべてのオーダラーにトランザクションを送信することができる。ピアは２つのポートを開くことができ、１つのポートはイベント交換用である。ＢＣＳゲートウェイは、１つのチャネルのためのピアのイベントポートに接続できる。

一実施形態では、ＲＥＳＴプロキシサービスコンポーネントは、非同期ＡＰＩおよび同期ＡＰＩの双方をサポートすることができる。

一実施形態によれば、非同期ＡＰＩについては、ＲＥＳＴプロキシサービスコンポーネントは、クライアントからの要求のパラメータをチェックし、そのクライアントにトランザクションＩＤを返すことができる。クライアントは、トランザクションが起動されたものの終わっていないことを示す情報を受信することができる。ＲＥＳＴプロキシサービスコンポーネントは、トランザクションを処理し続けるために、バックグラウンドスレッドを起動することができる。クライアントは、終わっていないトランザクションを追跡することができる。ＲＥＳＴプロキシサービスコンポーネントは、クライアントがトランザクションＩＤを使用してトランザクションステータスを問合せるためのトランザクションＡＰＩを提供する。

図８Ｃは、一実施形態に従った、ＢＣＳインスタンスにおいてＲＥＳＴプロキシサービスを提供するための方法を示す。

一実施形態によれば、図８Ｃに示すように、ステップ８８１で、コンテナランタイムサービスが提供される。

一実施形態によれば、ステップ８８３で、コンテナランタイムサービスにおいて分散型台帳が提供され、分散型台帳は、コンテナランタイムサービスにおいてブロックチェーンクラウドサービスとしてプロビジョニングされる。

一実施形態によれば、ステップ８８５で、コンテナランタイムサービスのコンテナにおいてＲＥＳＴプロキシサービスが実行され、ＲＥＳＴプロキシサービスは、分散型台帳と通信する際にクライアントアプリケーションによって使用されるための複数のＲＥＳＴ ＡＰＩを含み、複数のＲＥＳＴ ＡＰＩは、クライアントアプリケーションからのＲＥＳＴコールをリモートプロシージャコールに変換するように構成される。

例示的なＲＥＳＴ ＡＰＩ
一実施形態によれば、ＲＥＳＴプロキシサービスコンポーネントは、ＢＣＳと、ＢＣＳにインストールされたスマートコントラクト（チェーンコード）とを使用して、クライア
ントアプリケーション間の対話のためのＲＥＳＴ ＡＰＩを提供することができる。以下のＲＥＳＴ ＡＰＩは、ブロックチェーンクラウドサービスのＲＥＳＴプロキシサービスコンポーネントの機能性を説明するための例として提供される。

一実施形態によれば、ＲＥＳＴ ＡＰＩを呼び出す前に、ＲＥＳＴプロキシサービスコンポーネントは立ち上がって稼働している必要がある。ＲＥＳＴプロキシサービスコンポーネントのステータスは、管理コンソールを通してチェックされ得る。ＲＥＳＴプロキシサービスコンポーネントが立ち上がって稼働していない場合、それは管理コンソールから起動され得る。

一実施形態によれば、ＲＥＳＴ ＡＰＩは、ＢＣＳインスタンスにおけるピアノードにデプロイメントされたスマートコントラクト（チェーンコード）と対話するために呼び出され得る。デプロイメントプロセスは、管理コンソールのチェーンコードページを通して達成され得る。デプロイメントは、インストール（ピアへのコピー）とインスタンス化（コンパイル、チャネルへの結合、および初期化）という２つのステップからなる。

一実施形態によれば、以下に提供される例示的なＲＥＳＴ ＡＰＩは、以下の例示的なチェーンコードがＢＣＳにデプロイメントされていると仮定している。

一実施形態によれば、上に示すように、表２は、チェーンコードの例示的な関数を示し、表３は、チェーンコードの例示的なインストールを示す。

一実施形態によれば、ＲＥＳＴプロキシサービスコンポーネントは、チェーンコードを通して問合せ、チェーンコードを通してトランザクションを呼び出し、チェーンコードを通してトランザクションを非同期的に呼び出し、トランザクションステータスを取得し、ＢＣＳゲートウェイのバージョンを入手するためのＲＥＳＴ ＡＰＩを提供することができる。

一実施形態によれば、チェーンコードを通して問合せるためのＡＰＩは、問合せアクションを行なうためにチェーンコードを呼び出すことができ、問合せのためのチェーンコードおよび引数はＲＥＳＴ ＡＰＩを通して特定される。トランザクションステータスを取得するためのＡＰＩは、トランザクションステータスについてチャネルに問合せることができ、チャネルおよびトランザクションＩＤはＲＥＳＴ ＡＰＩを通して特定される。ＢＣＳゲートウェイのバージョンを入手するためのＡＰＩは、ＢＣＳゲートウェイのバージ
ョン情報を返すことができる。チェーンコードを通してトランザクションを呼び出すためのＡＰＩは、トランザクションアクションを行なうためにチェーンコードを呼び出すことができ、呼び出しのためのチェーンコードおよび引数はＲＥＳＴ ＡＰＩを通して特定される。このＲＥＳＴ ＡＰＩは、トランザクションを同期モードで行なうことができる。すなわち、トランザクションの実行が成功した場合、トランザクションの実行が失敗した場合、トランザクションがタイムアウトした場合という３つの場合のいずれでも、応答が送り返される。

一実施形態によれば、チェーンコードを通してトランザクションを非同期的に呼び出すためのＡＰＩは、トランザクションアクションを行なうためにチェーンコードを呼び出すことができ、呼び出しのためのチェーンコードおよび引数はＲＥＳＴ ＡＰＩを通して特定される。このＲＥＳＴ ＡＰＩは、トランザクションを非同期モードで行なう。すなわち、トランザクションが提出された後で、その完了またはタイムアウトを待つことなく、応答／受領確認が直ちに送り返される。その場合、結果はその後提供されてもよい。

一実施形態によれば、ＢＣＳをプロビジョニングおよび／または管理するための管理コンソールによる呼び出しのために、１組のアドミニストレーションＲＥＳＴ ＡＰＩがＲＥＳＴプロキシサービスコンポーネント上に提供され得る。

問合せの呼び出し
一実施形態によれば、チェーンコードは、情報を問合せるために使用される、より多くの関数を含んでいてもよい。これらの関数は、ｃＵＲＬ：curl -H Content-type:application/json -X POST http://localhost:8080/bcsgw/rest/v1/transaction/queryを使用し
てＲＥＳＴリソースに対するＰＯＳＴ要求を提出することによって、以下のＲＥＳＴ ＡＰＩを通して呼び出すことができる。

一実施形態によれば、問合せの呼び出しのＪＳＯＮでの要求の本体は、以下のように示され得る：

この例では、funcqueryという名前の関数は、Args[0]：アカウントＡという入力パラメータを有する。この関数は、アカウントＡについて情報を問合せ、アカウント情報を返すことができる。アカウント情報は、チェーンコード名と、チェーンコードバージョンと、問合せを呼び出すためにチェーンコードにおいて定義された方法と、チェーンコードにおける特定された方法に渡される引数を含むアレイとを含む。

問合せの呼び出しのための例示的な応答ヘッダは、以下のように示され得る：

問合せの呼び出しのための例示的な応答本体は、以下のように示され得る：

上述の例示的な応答本体では、「returnCode」についての「Success」は、問合せが首
尾よく完了したことを意味しており、「Failure」は、問合せが失敗したことを意味する
であろう。「result」については、returnCodeが「Success」である場合、問合せ結果を
有する文字列が返され得る。「info」については、returnCodeが「Failure」である場合
、失敗の追加の詳細を有する文字列が返され得る。

トランザクションの呼び出し（同期）
一実施形態によれば、チェーンコードは、トランザクションのための１つ以上の関数を含んでいてもよい。このＲＥＳＴ ＡＰＩは、これらのトランザクションを呼び出すために使用される。動作についてのタイムアウト、トランザクションの成功、およびトランザクションの失敗という条件のうちのいずれかが満たされる場合、応答が送り返され得る。

一実施形態によれば、このＲＥＳＴ ＡＰＩを呼び出すために、ｃＵＲＬコマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction/invocation」が使用され得る。

ＪＳＯＮでの例示的な要求本体は、以下のように示され得る：

この例では、funcinvokeという名前の関数は、Args[0]：アカウントＡ、Args[1]：アカウントＢ、およびArgs[2]：金額Ｃという入力パラメータを有する。この関数は、アカウ
ントＡからアカウントＢに３を動かすであろう。

例示的な応答ヘッダは、以下のように示され得る：

例示的な応答本体は、以下のように示され得る：

トランザクションの呼び出し（非同期）
一実施形態によれば、チェーンコードは、トランザクションのための１つ以上の関数を含んでいてもよい。このＲＥＳＴ ＡＰＩまたは動作は、それらの関数を非同期モードで呼び出すために使用され得る。非同期モードでは、動作がまだ完了、失敗、またはタイムアウトしていなくても、トランザクションＩＤが直ちに返される。この動作を使用する場合、動作のステータスは別々に問合される。

ＡＰＩは、コマンド「curl -H Content type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction/asyncInvocation」を使用して呼び出され得る。

ＪＳＯＮでの例示的な要求本体は、以下のように示され得る：

この例では、funcinvokeという名前の関数は、Args[0]：アカウントＡ、Args[1]：アカウントＢ、およびArgs[2]：金額Ｃという入力パラメータを有する。この関数は、アカウ
ントＢからアカウントＡに５を動かすであろう。このＲＥＳＴ ＡＰＩ動作は常に、トランザクションが提出された直後にトランザクションＩＤを返す。トランザクションについてのステータスは、別のＲＥＳＴ ＡＰＩ動作によって問合され得る。

例示的な応答ヘッダは、以下のように示され得る：

例示的な応答本体は、以下のように示され得る：

上述の応答本体では、「returnCode」についての「Success」は、トランザクションが
首尾よく呼び出されたことを意味し、「Failure」は、トランザクションの呼び出しが失
敗したことを意味する。returnCodeが「Failure」である場合、「info」は、失敗につい
ての追加情報を含み得る。

特定されたトランザクションのビューステータス
一実施形態によれば、このＲＥＳＴ ＡＰＩを用いて、ユーザは、特定されたチャネル情報およびトランザクションＩＤによってトランザクションの現在のステータスをチェックすることができる。このＲＥＳＴ ＡＰＩは、トランザクションの現在のステータスを直ちに返すことができる。

ＡＰＩを呼び出すために、ｃＵＲＬコマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction」を使用することができる。

以下は、ＡＰＩを呼び出すためのＪＳＯＮでの例示的な要求のヘッダである。ヘッダでは、「txid」はトランザクションＩＤである：

以下は、例示的な応答のヘッダである：

以下は、例示的な応答の本体である：

トランザクションリストのためのビューステータス
一実施形態によれば、このＲＥＳＴ ＡＰＩは、特定されたトランザクションのグループのステータスをチェックするために使用され得る。１）どのトランザクションもInProgressステータスを有していない、すなわち、リストされたすべてのトランザクションが成功に終わったかまたは失敗したという条件；２）この要求についてタイムアウトが到達されたという条件という２つの条件のうちのいずれか一方が真である場合、このＲＥＳＴ ＡＰＩは戻る。

ＲＥＳＴ ＡＰＩを呼び出すために、コマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/v1/transaction/waitStatus」を使
用することができる。

以下は、ＪＳＯＮでの例示的な要求本体である：

上述の要求は、リストされたチャネルおよびトランザクションＩＤによって特定されたトランザクションのステータスをチェックする。「timeout」は、この動作についてのタ
イムアウトをミリ秒で特定し、「array」は、問合されるトランザクションをリストする
ために使用される。トランザクションごとに、チャネル名とトランザクションＩＤとを有する要素を作成することができる。

例示的な応答ヘッダは、以下のように示され得る：

例示的な応答本体は、以下のように示され得る：

ビューバージョン
一実施形態によれば、このＲＥＳＴ ＡＰＩは、ＢＣＳゲートウェイのバージョン情報を検索するために使用可能であり、コマンド「curl -H Content-type:application/json -X POST -d http://localhost:8080/bcsgw/rest/version」を使用して呼び出され得る。

ＲＥＳＴ ＡＰＩを呼び出すためのＪＳＯＮでの例示的な要求ヘッダは、以下のように示され得る：

ＲＥＳＴの呼び出しから返された例示的な応答のヘッダは、以下のように示され得る：

ＲＥＳＴの呼び出しから返された例示的な応答の本体は、以下のように示され得る：

アイデンティティクラウドサービス（ＩＤＣＳ）と統合されたファブリック証明機関（ファブリックＣＡ）
一実施形態によれば、ファブリックＣＡサーバは、ファブリックのためのメンバーシッ
プサービスを提供する。それは、ユーザについての認証と、ブロックチェーン（ピアおよびオーダーのグループ）にアクセスするための認証と、アプリケーションクライアント、ピア、およびオーダーに証明書を配送できるＣＡサーバという３つの部分を含む。ファブリックＣＡは、認証および認可を実現するために証明書を使用する。証明書は、認証のための登録certと、認可のためのトランザクションcertという２つのタイプを含む。ＩＤＣＳも、認証および認可を提供する。しかしながら、その認可はOAuthによって実現される
。すなわち、ピアがオーダーにアクセスしたい場合、ピアは、ＩＤＣＳからユーザのアクセストークンを入手し、このトークンを使用してオーダーにアクセスすべきである。

一実施形態によれば、ファブリックＣＡは、たとえばユーザの名前／パスワード、ユーザの証明書、およびユーザのアフィリエーションといったファブリックＣＡの登録ユーザの情報を格納するために、データベースまたはＬＤＡＰを使用する。パブリッククラウド（ＯＰＣ）のエンドユーザは、その従業員が適用されるパブリッククラウド（ＯＰＣ）インスタンスのすべてにアクセスすることを管理するために、１つの集中型ＩＤＣＳインスタンスを適用するであろう。ブロックチェーンクラウドサービスＢＣＳは好ましくは、他のクラウドサービスに使用されたＩＤＣＳと統合される。このため、エンドユーザは、その従業員が、ＢＣＳに含まれる、適用されるパブリッククラウド（ＯＰＣ）インスタンスのすべてにアクセスすることを管理するために、１つの集中型ＩＤＣＳインスタンスを適用できるようになる。

一実施形態では、ブロックチェーンクラウドサービス（ＢＣＳ）は、ユーザ情報を集中的に格納するために、オラクルアイデンティティクラウドサービス（ＩＤＣＳ）を使用する。ＢＣＳは、ファブリックＣＡユーザの情報をＩＤＣＳに格納し、それにより、オラクルＢＣＳがＩＤＣＳを使用して、複数のパブリッククラウドサービスインスタンスにわたって集中化されたＢＣＳユーザの情報を管理することを可能にする。このため、一実施形態では、ＢＣＳファブリックＣＡユーザの情報、証明書は、オラクルＩＤＣＳに格納される。ファブリック証明書認可フレームワークは、ＰＫＩプライベートキー、署名された証明書、ＣＡ証明書チェーンを含むファブリックメンバーシッププロバイダ（ＭＳＰ）であり、それはファブリックＣＡクライアント／サーバによって設定される。

一実施形態によれば、ＢＣＳは、ＯＰＣのユーザ管理を活用する。どのＢＣＳユーザも、まず、ＯＰＣユーザ（ひいてはＩＤＣＳアイデンティティ）でなければならない。ＢＣＳインスタンスが作成される場合、ＢＣＳコンソール、ＣＡ、およびＲＥＳＴプロキシといういくつかのタイプのアプリケーションが作成される。コンソールについては、コンソールadminとコンソールユーザという２つのアプリ役割がある。ＣＡについては、ファブ
リックadmin、ファブリッククライアント、ファブリックピア、ファブリックオーダラー
という４つのアプリ役割がある。ＲＥＳＴプロキシについては、ゲートウェイadminとゲ
ートウェイユーザという２つのアプリ役割がある。

一実施形態によれば、ＢＣＳユーザになるために、ＯＰＣユーザは、ＯＰＣユーザ管理コンソールにおけるあるＢＣＳアプリ役割を与えられる必要がある。

一実施形態によれば、ＢＣＳインスタンスの作成時、作成者は既存のＯＰＣユーザ／パスワードを提供する必要があり、このユーザは、ＢＣＳコンソールadminおよびファブリ
ックadminの役割を自動的に与えられるであろう。そのため、このユーザはＢＣＳアドミ
ニストレータになる。

認証：ＢＣＳコンソール／ＣＡ／ＲＥＳＴプロキシについては、認証はクラウドゲートで行なわれる。ピア／オーダラーについては、認証は署名ベースである。ＢＣＳコンソールについては、認証後、コンソールは、（ＩＤＣＳを呼び出すことによって）現在のユー
ザのアプリ役割を手に入れる。ユーザがコンソールadminまたはコンソールユーザの役割
を与えられていない場合、接続が拒否される。その他の場合、コンソールは、予め定義された規則に基づいてアクセス制御を行なう。たとえば、通常のユーザは一般に情報を読むことしかできず、一方、adminは何でも行なうことができる。

一実施形態によれば、ＣＡについては、認証後、ＣＡは現在のユーザのアプリ役割を手に入れる。ユーザがファブリック役割を何も与えられていない場合、登録要求が拒否される。

一実施形態によれば、ＲＥＳＴプロキシについては、認証後、ＲＥＳＴプロキシは現在のユーザのアプリ役割を手に入れる。ユーザがゲートウェイadminまたはゲートウェイユ
ーザの役割を与えられていない場合、要求は拒否される。その他の場合、ＲＥＳＴプロキシは、予め定義された規則に基づいてアクセス制御を行なう。たとえば、通常のユーザは呼び出し／問合せを行なうことでき、adminは構成を変更したりメトリックを入手するこ
とができる。

一実施形態によれば、ファブリックＣＡサーバは、ファブリックのためのメンバーシップサービスを提供する。それは、ユーザについての認証と、ブロックチェーン（ピアおよびオーダーのグループ）にアクセスするための認証と、アプリケーションクライアント、ピア、およびオーダーに証明書を配送できるＣＡサーバという３つの部分を含む。

一実施形態によれば、ファブリックＣＡは、認証および認可を実現するために証明書を使用する。証明書は、認証のための登録certと、認可のためのトランザクションcertという２つのタイプを含む。

一実施形態によれば、ＩＤＣＳも、認証および認可を提供する。しかしながら、その認可はOAuthによって実現される。すなわち、ピアがオーダーにアクセスしたい場合、ピア
は、ＩＤＣＳからユーザのアクセストークンを入手し、このトークンを使用してオーダーにアクセスすべきである。

図９Ａは、一実施形態に従った、シングルサインオンのための典型的なＩＤＣＳ使用事例を示す。

一実施形態によれば、最初のステップで、ウェブアプリケーション９０１をＩＤＣＳ９０２に追加することができる。次に、ウェブブラウザ９００などのクライアントが、ウェブアプリケーションから認証（たとえば、ユーザ名およびパスワード）を要求することができる。ウェブアプリケーションがＩＤＣＳに追加されたため、ウェブアプリケーションはウェブブラウザに、ＩＤＣＳへ認証要求を行なうよう命令することができる。ウェブアプリケーションから応答を受信後、ウェブブラウザは次に、ＩＤＣＳから認証（たとえば、ユーザ名およびパスワード）を要求することができる。

一実施形態によれば、ＩＤＣＳは次に要求を認証し、認証が成功するとトークンをウェブブラウザに送り返すことができる。認証されそのトークンを受信したウェブブラウザは次に、ウェブアプリケーションから要求することができる。ウェブアプリケーションはトークンを検証し、認証が成功したことをウェブブラウザに合図することができる。

図９Ａに示す事例では、ＩＤＣＳは、アプリケーションのためのアイデンティティサービスを提供するためのアイデンティティプロバイダ（ＩｄＰ）として作用する。すべての当事者間の通信はすべて、ＨＴＴＰベースである。この使用事例は構成駆動型であるが、ＨＴＴＰベースのアプリケーションにのみ当てはまる。

図９Ｂは、一実施形態に従った、ファブリッククライアント認証のためのＩＤＣＳ使用事例を示す。

一実施形態によれば、すでに登録されたファブリックユーザ（このユーザのプライベートキーおよび証明書はすでにクライアント側の状態ストアに格納されている）に関連付けられたファブリッククライアント９０４は、新しいクライアント（）、および、クライアントのユーザコンテキスト（ユーザ名）を入手することを要求することができる。ファブリックＳＤＫ９０５は、状態ストアからユーザをロードし、ユーザオブジェクトをファブリッククライアントに返すことができる。クライアントは、ユーザオブジェクトを受信すると、トランザクション提案をファブリックＳＤＫに送信することができ、ファブリックＳＤＫは、同じプライベートキーを使用して提案に署名することができる。署名された提案は次にピア（または複数のピア）９０６へ行くことができ、ピアはメンバーシップサービス９０７で署名を検証するであろう。メンバーシップサービスは、ユーザのための証明書をＩＤＣＳ９０２から入手することができ、ＩＤＣＳからの証明書を使用してユーザの署名を検証することができる。メンバーシップサービスは次に、署名が検証されたという検証をピアに返すことができる。

本発明のさまざまな実施形態が上述されてきたが、それらは限定のためではなく例示のために提示されてきたことが理解されるべきである。実施形態は、この発明およびその実際の応用の特徴および原則を説明するために選択され、記載された。実施形態は、新しいおよび／または向上した機能を提供すること、ならびに／もしくは、リソース利用の減少、能力の増加、スループットの増加、効率の向上、待ち時間の減少、セキュリティの強化、および／または使いやすさの向上を含むもののそれらに限定されない性能利点を提供することによってシステムおよび方法の性能を向上させるために、本発明のさまざまな特徴が利用される、システムおよび方法を示す。

本発明のいくつかの実施形態は、アーキテクチャ、機能性、プロセス、および／または動作を示す、方法、装置（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して、ここに説明される。フローチャートまたはブロック図における各ブロックは、要素、機能、プロセス、モジュール、セグメント、または命令の一部を表わし、それは、特定された機能を実現するための１つ以上の実行可能命令を含む。いくつかの代替的な実施形態では、ブロック図またはフローチャートに記載された機能は、図に記載されたもの以外の順序で起こる。たとえば、連続して示された２つのブロックが、関与する機能性に依存して、実質的に同時に実行されてもよく、または逆の順序で実行されてもよい。フローチャートおよび／またはブロック図の各ブロック、ならびに、フローチャートおよび／またはブロック図におけるブロックの組合せは、特定された機能を行なう、コンピュータプログラム命令、および／または専用ハードウェア、および／またはハードウェアとコンピュータプログラム命令との組合せによって実現され得る。

いくつかの実施形態では、本発明の特徴は、プロセッサと、コンピュータ読取可能記憶媒体と、他のコンピュータと通信するためのネットワークカード／インターフェイスとを含む、コンピュータにおいて実現される。いくつかの実施形態では、本発明の特徴は、ネットワークによって相互接続されたパーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラマブルな家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、さまざまなタイプのコンピュータ構成を含むコンピューティングシステムを含むネットワークコンピューティング環境において実現される。ネットワークは、ローカルエリアネットワーク（Local Area Network：ＬＡＮ）、スイッチファブリックネットワーク（たとえばInfini
Band（インフィニバンド））、ワイドエリアネットワーク（Wide Area Network：ＷＡＮ
）、および／またはインターネットであり得る。ネットワークは、銅の送信ケーブル、光伝送ファイバー、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、および／またはエッジサーバを含み得る。

いくつかの実施形態では、本発明の特徴は、バックエンドコンポーネント（たとえばデータサーバ）を含む、または、ミドルウェアコンポーネント（たとえばアプリケーションサーバ）を含む、または、フロントエンドコンポーネント（たとえば、ユーザがここに説明された主題の実現化例と対話できるようにするグラフィカルユーザインターフェイスまたはウェブブラウザを有するクライアントコンピュータ）を含む、または、ネットワークによって相互接続されたそのようなバックエンド、ミドルウェア、あるいはフロントエンドコンポーネントの任意の組合せを含む、コンピューティングシステムにおいて実現される。コンピューティングシステムは、クライアントーサーバ関係を互いに有するクライアントおよびサーバを含み得る。いくつかの実施形態では、この発明の特徴は、コンピュータの１つ以上のクラスタがネットワークによって接続される分散コンピューティング環境を含むコンピューティングシステムにおいて実現される。分散コンピューティング環境は、すべてのコンピュータを単一の場所で有することができ、または、コンピュータのクラスタを、ネットワークによって接続された遠隔の異なる地理的場所で有することができる。

いくつかの実施形態では、本発明の特徴は、ウェブ技術を使用してセルフサービスの計量される方法でユーザに与えられる共有の柔軟なリソースに基づいたクラウドコンピューティングシステムの一部として、またはそのサービスとして、クラウドにおいて実現される。クラウドの特性は、たとえば、オンデマンドのセルフサービス、広いネットワークアクセス、リソースプール、迅速な柔軟性、および測定されるサービスを含んでいてもよい。クラウドデプロイメントモデルは、パブリック、プライベート、およびハイブリッドを含む。クラウドサービスモデルは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）、プラットフォーム・アズ・ア・サービス（ＰａａＳ）、データベ
ース・アズ・ア・サービス（Database as a Service：ＤＢａａＳ）、およびインフラス
トラクチャ・アズ・ア・サービス（ＩａａＳ）を含む。クラウドは一般に、共有の柔軟なリソースをユーザに与える、ハードウェアとソフトウェアとネットワークとウェブ技術との組合せを指す。ここに使用されるようなクラウドは、パブリッククラウド、プライベートクラウド、および／またはハイブリッドクラウド実施形態を含んでいてもよく、クラウドＳａａＳ、クラウドＤＢａａＳ、クラウドＰａａＳ、および／またはクラウドＩａａＳデプロイメントモデルを含んでいてもよい。

いくつかの実施形態では、本発明の特徴は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せを使用して、あるいはその助けを借りて実現される。いくつかの実施形態では、本発明の特徴は、本発明の１つ以上の機能を実行するように構成またはプログラムされたプロセッサを使用して実現される。いくつかの実施形態では、プロセッサは、ここに説明された機能を行なうように設計された、シングルまたはマルチチッププロセッサ、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、システム・オン・チップ（system on a chip：ＳＯＣ）、特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）または他のプログラマブルロジックデバイス、ステートマシン、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェアコンポーネント、もしくはそれらの任意の組合せである。いくつかの実現化例では、本発明の特徴は、所与の機能に特有の回路によって実現される。他の実現化例では、特徴は、たとえばコンピュータ読取可能記憶媒体に格納された命令を使用して特定の機能を行なうように構成された、コンピュータ、コンピューティングシステム、プロセッサ
、および／またはネットワークにおいて実現される。

いくつかの実施形態では、本発明の特徴は、処理および／またはネットワークシステムのハードウェアを制御するために、ならびに、本発明の特徴を利用する他のシステムとプロセッサおよび／またはネットワークが対話できるようにするために、ソフトウェアおよび／またはファームウェアに組込まれる。そのようなソフトウェアまたはファームウェアは、アプリケーションコード、デバイスドライバ、オペレーティングシステム、仮想マシン、ハイパーバイザー、アプリケーションプログラミングインターフェイス、プログラミング言語、および実行環境／コンテナを含み得るものの、それらに限定されない。本開示の教示に基づいて、適切なソフトウェアコーディングが、熟練したプログラマーによって容易に準備され得る。

いくつかの実施形態では、本発明は、ソフトウェアおよび／またはファームウェアを含む命令が格納されたマシン読取可能またはコンピュータ読取可能記憶媒体であるコンピュータプログラム製品を含み、命令は、本発明のプロセスまたは機能のうちのいずれかを行なうように、コンピュータなどのシステムをプログラムするかまたは他の態様で構成するために使用され得る。記憶媒体またはコンピュータ読取可能媒体は、フロッピー（登録商標）ディスク、ハードドライブ、ソリッドステートドライブ、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気または光カード、分子メモリ、ナノシステム、またはそれらの変形および組合せを含むもののそれらに限定されない、命令および／またはデータを格納するのに好適な任意のタイプの媒体またはデバイスを含み得る。特定の実施形態では、記憶媒体またはコンピュータ読取可能媒体は、非一時的マシン読取可能記憶媒体、または非一時的コンピュータ読取可能記憶媒体である。

前述の説明は、網羅的であるよう、またはこの発明を開示された形態そのものに限定するよう意図されていない。加えて、本発明の実施形態は特定の一連のトランザクションおよびステップを使用して説明されてきたが、記載がない限り、実施形態は追加のトランザクションおよびステップの実行を除外しないということは、当業者には明らかであるはずである。また、さまざまな実施形態がこの発明の特徴の特定の組合せを説明しているが、この発明の範囲内にあるような関連技術の当業者には特徴の異なる組合せが明らかである、ということが理解されるべきである。特に、所与の実施形態、変形に記載され、または図面に示された（デバイスのような、または方法のような）特徴は、本発明の範囲から逸脱することなく、別の実施形態、変形、または図面にある別の特徴と組合されてもよく、もしくはそれを置き換えてもよい。さらに、要素のさまざまな追加、削減、削除、変形、均等物との置換、ならびに、形態、詳細、実現化例、および用途における他の修正および変更が、この発明の精神および範囲から逸脱することなく、そこになされ得るということは、関連技術の当業者には明らかであろう。この発明のより広範な精神および範囲は、請求項およびそれらの均等物によって定義されることが意図されている。

Claims (18)

1. ブロックチェーンクラウドサービスにおいてレプレゼンテーショナルステートトランスファー（ＲＥＳＴ）プロキシサービスを提供するためのシステムであって、前記システムは、
   コンテナランタイムサービスと、
   前記コンテナランタイムサービスにおける分散型台帳とを含み、前記分散型台帳は、前記コンテナランタイムサービスにおいてブロックチェーンクラウドサービスとしてプロビジョニングされ、前記システムはさらに、
   前記コンテナランタイムサービスのコンテナにおいて実行されるＲＥＳＴプロキシサービスを含み、
   前記ＲＥＳＴプロキシサービスは、前記分散型台帳と通信する際にクライアントアプリケーションによって使用されるための複数のＲＥＳＴアプリケーションプログラミングインターフェイス（ＡＰＩ）を含み、前記複数のＲＥＳＴ ＡＰＩは、前記クライアントアプリケーションからのＲＥＳＴコールをリモートプロシージャコールに変換するように構成される、システム。
2. 前記複数のＲＥＳＴ ＡＰＩはさらに、前記クライアントアプリケーションが、
   チェーンコードを通して問合せること、
   前記チェーンコードを通してトランザクションを同期的または非同期的に呼び出すこと、
   トランザクションステータスを入手すること、または
   前記ＲＥＳＴプロキシサービスのバージョン情報を入手すること、のうちの１つ以上を行なうことを可能にするように構成される、請求項１に記載のシステム。
3. 前記ＲＥＳＴプロキシサービスはさらに、前記クライアントアプリケーションからの前記ＲＥＳＴコールを認証するように構成される、請求項１または２に記載のシステム。
4. 前記ＲＥＳＴプロキシサービスはさらに、管理コンソールによって提供される機能をサポートするために追加のＲＥＳＴ ＡＰＩを提供し、前記機能は、前記ブロックチェーンクラウドサービスを管理するために前記管理コンソールによって使用される、請求項１〜３のいずれか１項に記載のシステム。
5. 前記ＲＥＳＴプロキシサービスは、前記コンテナランタイムサービスの前記コンテナにおけるウェブサーバにおいて実行される、請求項１〜４のいずれか１項に記載のシステム。
6. 前記分散型台帳はハイパーレッジャーファブリックである、請求項１〜５のいずれか１項に記載のシステム。
7. 前記ＲＥＳＴプロキシサービスは、前記分散型台帳と通信するために、前記分散型台帳のためのサービス開発キット（ＳＤＫ）を使用する、請求項１〜６のいずれか１項に記載のシステム。
8. 前記ブロックチェーンクラウドサービスは、ピアコンテナと、オーダリングコンテナと、チェーンコードコンテナとを含み、前記ピアコンテナはエンドーサとコミッタとを含み、前記エンドーサは、前記ブロックチェーンクラウドサービス内のトランザクションを承認し、前記コミッタは、前記ピアコンテナによって保持されるブロックチェーン台帳への変更を適用する、請求項１〜７のいずれか１項に記載のシステム。
9. ブロックチェーンクラウドサービスにおいてレプレゼンテーショナルステートトランスファー（ＲＥＳＴ）プロキシサービスを提供するための方法であって、前記方法は、
   コンテナランタイムサービスを提供するステップと、
   前記コンテナランタイムサービスにおいて分散型台帳を提供するステップとを含み、前記分散型台帳は、前記コンテナランタイムにおいてブロックチェーンクラウドサービスとしてプロビジョニングされ、前記方法はさらに、
   前記コンテナランタイムサービスのコンテナにおいて実行されるＲＥＳＴプロキシサービスを提供するステップを含み、
   前記ＲＥＳＴプロキシサービスは、前記分散型台帳と通信する際にクライアントアプリケーションによって使用されるための複数のＲＥＳＴアプリケーションプログラミングインターフェイス（ＡＰＩ）を含み、前記複数のＲＥＳＴ ＡＰＩは、前記クライアントアプリケーションからのＲＥＳＴコールをリモートプロシージャコールに変換するように構成される、方法。
10. 前記複数のＲＥＳＴ ＡＰＩはさらに、前記クライアントアプリケーションが、
    チェーンコードを通して問合せること、
    前記チェーンコードを通してトランザクションを同期的または非同期的に呼び出すこと、
    トランザクションステータスを入手すること、または
    前記ＲＥＳＴプロキシサービスのバージョン情報を入手すること、のうちの１つ以上を行なうことを可能にするように構成される、請求項９に記載の方法。
11. 前記ＲＥＳＴプロキシサービスはさらに、前記クライアントアプリケーションからの前記ＲＥＳＴコールを認証するように構成される、請求項９または１０に記載の方法。
12. 前記ＲＥＳＴプロキシサービスはさらに、管理コンソールによって提供される機能をサポートするために追加のＲＥＳＴ ＡＰＩを提供し、前記機能は、前記ブロックチェーンクラウドサービスを管理するために前記管理コンソールによって使用される、請求項９〜１１のいずれか１項に記載の方法。
13. 前記ＲＥＳＴプロキシサービスは、前記コンテナランタイムサービスの前記コンテナにおけるウェブサーバにおいて実行される、請求項９〜１２のいずれか１項に記載の方法。
14. 前記分散型台帳はハイパーレッジャーファブリックである、請求項９〜１３のいずれか１項に記載の方法。
15. 前記ＲＥＳＴプロキシサービスは、前記分散型台帳と通信するために、前記分散型台帳のためのサービス開発キット（ＳＤＫ）を使用する、請求項９〜１４のいずれか１項に記載の方法。
16. 前記ブロックチェーンクラウドサービスは、ピアコンテナと、オーダリングコンテナと、チェーンコードコンテナとを含み、前記ピアコンテナはエンドーサとコミッタとを含み、前記エンドーサは、前記ブロックチェーンクラウドサービス内のトランザクションを承認し、前記コミッタは、前記ピアコンテナによって保持されるブロックチェーン台帳への変更を適用する、請求項９〜１５のいずれか１項に記載の方法。
17. 請求項９〜１６のいずれかに記載の方法をコンピュータに実行させる、プログラム。
18. ブロックチェーンクラウドサービスにおいてレプレゼンテーショナルステートトランスファー（ＲＥＳＴ）プロキシサービスを提供するためのシステムであって、前記システムは、
    コンテナランタイムサービスと、
    前記コンテナランタイムサービスにおける分散型台帳とを含み、前記分散型台帳は、前記コンテナランタイムサービスにおいてブロックチェーンクラウドサービスとしてプロビジョニングされ、前記ブロックチェーンクラウドサービスは、ピアコンテナと、オーダリングコンテナと、チェーンコードコンテナとを含み、前記ピアコンテナはエンドーサとコミッタとを含み、前記エンドーサは、前記ブロックチェーンクラウドサービス内のトランザクションを承認し、前記コミッタは、前記ピアコンテナによって保持されるブロックチェーン台帳への変更を適用し、前記システムはさらに、
    前記コンテナランタイムサービスのコンテナにおいて実行されるＲＥＳＴプロキシサービスを含み、
    前記ＲＥＳＴプロキシサービスは、前記分散型台帳と通信する際にクライアントアプリケーションによって使用されるための複数のＲＥＳＴアプリケーションプログラミングインターフェイス（ＡＰＩ）を含み、前記複数のＲＥＳＴ ＡＰＩは、前記クライアントアプリケーションからのＲＥＳＴコールをリモートプロシージャコールに変換するように構成される、システム。