JP7454616B2 - 分散型元帳におけるｄａｇベースのトランザクション処理方法およびシステム - Google Patents

Description

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

優先権主張
本願は、２０１９年１月２９日に出願され、「分散型元帳におけるＤＡＧベースのトランザクション処理方法およびシステム」と題された米国特許出願第１６／２６１３７１号、および２０１８年８月２４日に出願され、「分散型元帳におけるＤＡＧベースのトランザクション処理方法およびシステム」と題された米国仮特許出願第６２／７２２５９５号に基づく優先権の利益を主張し、各々の出願の全体が参照により本明細書に組み込まれる。

分野
本開示は、一般的に、分散型元帳（distributed ledger）を提供するためのシステムおよび方法に関する。より詳しくは、本開示は、分散型元帳における有向非循環グラフ（Directed Acyclic Graph：ＤＡＧ）ベースのトランザクション処理方法およびシステム並びにそのコンポーネントを開示する。

背景
分散型元帳は、大まかに、資産所有権のデジタル記録として称される。元帳は、中央管理者を有しなく、中央データストアを有しない。代わりに、元帳は、コンピューティング環境において、複数の場所、複数の国、または複数の施設にわたって地理的に分布され得る多くの参加ノードにわたって複製される。コンセンサスプロトコルは、元帳の各ノードのコピーと他の全てのノードのコピーとの同一性を保証する。同様に、１組のコピーは、１つの共有元帳として見なされてもよい。資産所有者は、分散型元帳を用いて、例えば、暗号署名技術に基づいて、一部の資産所有者の口座の負債を記入し、別の資産所有者の口座の信用度を評価することができる。

ブロックチェーンは、改ざん防止の分散型元帳を実装するために使用することができるデータ構造である。複数のノードは、クライアントからのトランザクションをブロックにパッケージ化する共通プロトコルに従い、ノードは、コンセンサスプロトコルを使用して、次のブロックに合意する。ブロックは、累積暗号ハッシュを有するため、元帳の改ざんが困難である。各ブロックは、時間的に前のブロックの参照値（ハッシュ値）を有する。また、各ブロックは、自身のハッシュ値を有する。ブロックチェーンは、後方（例えば、チェーンの上方）にトラバースすることができる。

許可無し分散型元帳は、任意の単一のエンティティによる制御を回避しながら、匿名参加者が元帳を管理することを可能にする。しかしながら、匿名の場合、アイデンティティ（identity）、説明責任（accountability）および監査能力（auditability）は、困難である。対照的に、許可有り分散型元帳は、明示的に許可された当事者が元帳を管理するこ
とを可能にすることによって、信用レベルおよび説明責任を可能にする。許可型元帳は、より柔軟な管理およびコンセンサスメカニズムのより広い選択をサポートする。他のトランザクションよりも一部のトランザクションを好む参加者は、２種類の分散型元帳を容易に操作することができる。しかしながら、許可有り元帳の基礎となる説明責任は、参加者に制約を与える機会を提供する。

ブロックチェーンは、線形記録構造を用いてトランザクション履歴を記録することによって、分散型元帳問題を解決するための潜在的な解決策を提供する。しかしながら、分散システムの基本的な特性によって、多くの場合、複数の当事者が複数のトランザクションを同一の共有元帳に送信する場合、トランザクション競合がしばしば発生する。競合を緩和するための方法は、いくつかがあるが、いずれの方法は、良好な性能を提供するものではない。

典型的な公衆ブロックチェーン、暗号通貨に関連する公衆ブロックチェーンは、マイナー（miner）が順序付け（ordering）に基づいて維持すべきトランザクションまたは拒絶
すべきトランザクションを決定することを可能にする。これらのマイナーは、常により多くの報酬を有するトランザクションを好むため、事実上インセンティブモデルを選択する。しかしながら、部分的にインセンティブモデルによって、公衆ブロックチェーンは、非常に遅くなる。

典型的なエンタープライズブロックチェーンファブリックは、各ピアが単にオーダリングサービスからの一連のトランザクションの時間順序に基づいてトランザクションを提出するタイミングモデルを選択する。この場合、時間順序によって、多くのトランザクションが拒否される可能性がある。

概要
本明細書は、一実施形態に従って、分散型元帳におけるＤＡＧベースのトランザクション処理システムおよび方法およびそのコンポーネントを記載する。

一実施形態によれば、本開示は、ＤＡＧ構造を導入することによって、新しいトランザクション処理モデルを提供する。新しいモデルは、高いスループット性能を達成することができる。追加の重みメカニズムを用いて、様々なビジネス要件に基づいて最終性能を調節することができる。線形構造を使用した既存の作業とは異なり、より良好な性能を達成することができる。

ハイパーレッジャプロジェクトは、オープンソースのエンタープライズ級の分散型元帳フレームワークおよびコードベースを作成するように、Linux（登録商標）財団のプロジ
ェクトとして達成された共同成果である。ハイパーレッジャファブリックは、スマートコントラクトを実行するための分散型元帳プラットフォームの実装である。ハイパーレッジャファブリックは、コンテナ技術を利用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。

一実施形態によれば、ハイパーレッジャの参加者は、元帳のコピーを複製する。元帳情報の共有に加えて、元帳を更新するプロセスも共有される。参加者のプライベートプログラムを用いて関連するプライベート元帳を更新する他のシステムとは異なり、ブロックチェーンシステムは、共有プログラムを用いて、共有元帳を更新する。共有元帳を介して参加者のビジネスネットワークを調整することによって、ブロックチェーンネットワークは、（信用性を増加しながら）プライベート情報を元帳に配布することに関連する時間、コストおよびリスク、並びに処理時間を低減することができる。ハイパーレッジャファブリックは、プライベートであり、許可型である。ハイパーレッジャファブリックネットワー
クのメンバが登録される。また、ハイパーレッジャファブリックは、チャネルを作成する機能を提供することができる。各チャネルは、特定のグループの参加者に可視である個別のトランザクション元帳を含むことができる。これによって、トランザクションプライバシを可能にする。

一実施形態によれば、ファブリックの分散型元帳プロトコルは、ピア（peer）によって実行される。ファブリックは、２種類のピアを識別する。検証ピアは、ネットワーク上で、コンセンサスの実行、トランザクションの検証、および元帳の管理に関与するノードである。一方、非検証ピアは、（トランザクションを発行する）クライアントを検証ピアに接続するためのプロキシとして機能するノードである。非検証ピアは、トランザクションを実行しないが、トランザクションを検証することができる。ファブリックのいくつかの特徴は、即時最終性を有し、チェーンコードと呼ばれる任意のスマートコントラクトを実行する許可型ブロックチェーンを含む。ユーザによって定義されたチェーンコードのスマートコントラクトは、コンテナの中でカプセル化され、システムチェーンコードは、ピアと同様のプロセスに実行される。ネットワークの全体において元帳トランザクションを同期状態に保持する（例えば、適切な参加者がトランザクションを承認する場合のみ、元帳を更新し、元帳を更新する場合、同様のトランザクションと共に同様の順序で元帳を更新することを保証する）ためのプロセスは、コンセンサスと称されてもよい。ファブリックは、ＴＬＳ（トランスポート層セキュリティ）証明書、登録証明書、およびトランザクション証明書を認証するための認証局（ＣＡ）をサポートすることによって、コンセンサスプロトコルおよびセキュリティを実装する。

一実施形態に従って、ブロックチェーンクラウドサービスシステムのファブリック内のトランザクションフローを示す図である。 一実施形態に従って、ブロックチェーンクラウドサービスシステムを示す図である。 一実施形態に従って、ＢＣＳシステムを示す図である。 一実施形態に従って、ＢＣＳシステムを示す図である。 一実施形態に従って、ブロックチェーンクラウドサービスシステムのゲートウェイを示す図である。 一実施形態に従って、ブロックチェーンクラウドサービスシステムの永続化を示す図である。 ＢＣＳ上のファブリックの例示的な配置を示す図である。 一実施形態に従って、チェーンコードアーキテクチャを示す図である。 一実施形態に従って、管理コンソールを提供するためのシステムを示す図である。 一実施形態に従って、ＢＣＳコンソールＵＩ内のユーザインターフェイスの一例を示す図である。 一実施形態に従って、ＢＣＳコンソールＵＩ内のユーザインターフェイスの一例を示す図である。 一実施形態に従って、ＢＣＳインスタンスにおいてＲＥＳＴプロキシを提供するためのシステムを示す図である。 一実施形態に従って、シングルサインオン用の典型的なＩＤＣＳ使用ケースを示す図である。 一実施形態に従って、ファブリッククライアント認証用のＩＤＣＳ使用ケースを示す図である。 一実施形態に従って、分散型元帳におけるＤＡＧベースのトランザクション処理方法およびシステムを示す図である。 一実施形態に従って、本開示の一実施形態に使用され得る例示的な関係グラフを示す図である。 一実施形態に従って、本開示の一実施形態に使用され得る例示的な関係グラフを示す図である。 一実施形態に従って、本開示の一実施形態に使用され得る例示的な関係グラフを示す図である。 一実施形態に従って、分散元帳における有向非循環グラフ（ＤＡＧ）ベースのトランザクション処理方法の一例を示すフローチャートである。

詳細な説明
一実施形態によれば、本明細書は、ブロックチェーンファブリックにおいてＳＱＬベースのリッチクエリをサポートするためのシステムおよび方法を記載する。一実施形態によれば、本明細書に記載されたシステムおよび方法は、ＳＱＬクエリを実行することによって、より容易およびより管理可能な方法で複雑なスマートコントラクトを作成することができる。また、データ選別を（スマートコントラクトレベルで実行するではなく）ストレージエンジンに戻すことおよびデータの同時読み出しおよび書き込みアクセスをサポートするリレーショナルエンジンに依存することによって、性能を改善することができる。また、ワールドデータベースのステートは、同時読み出し／書き込みアクセスを提供することができる。

一実施形態によれば、ブロックチェーンファブリックにおいてＳＱＬベースのリッチクエリをサポートする例示的なブロックチェーンファブリックは、クラウドサービスとして提供することができる。一実施形態によれば、エンタープライズ級のフレームワークは、クラウド技術を使用する様々なクライアントアプリケーションの拡張性、管理、設定、永続化、および互換性を含む。特定の実施形態において、許可型ブロックチェーン元帳およびブロックチェーンファブリックは、ブロックチェーンクラウドサービス（ＢＣＳ）として提供される。

以下の説明では、本開示は、限定ではなく例示として添付の図面に示される。本開示に言及された様々な実施形態は、必ずしも同様の実施形態を指すものではなく、このような言及は、少なくとも１つを意味する。具体的な実装例を説明するが、これらの実装例は、例示という目的のために提供される。当業者は、本開示の範囲および精神から逸脱することなく、他のコンポーネントおよび構成を使用できることを認識できるであろう。本開示の説明は、請求される方法をサポートおよび開示する例示および実施形態を提供する。

また、特定の場合に、多数の具体的な詳細を記載することによって、本開示の完全な説明を提供する。しかしながら、当業者なら、これらの具体的な詳細がなくても、本開示に教示された方法の結果および利点を達成することができ、本開示に教示された発想を実施することができることを理解するであろう。場合によって、本開示を曖昧にしないために、周知の特徴を詳細に記載しない。

特定の機能の性能およびそれらの関係を示す機能的な構築ブロックを用いて、本開示の教示を説明する。これらの機能的な構築ブロックの境界は、説明の都合上、本開示において任意に定義されることが多い。したがって、代替的な実施形態において、同様の要素によって実行される機能は、異なる要素によって実行されてもよい。機能を実行する各々の要素は、１つの要素に合併されてもよい。特定の機能およびそれらの関係を適切に実行できる限り、代替的な境界を定義してもよい。したがって、これらの任意の代替的な境界は、本開示の範囲および精神に含まれる。

図面および詳細な説明全体において、同様の参照番号を用いて、同様の要素を示す。し
たがって、要素が他の場所に記載されている場合、図面に使用された参照番号は、その図面に関連する詳細な説明において、言及されてもよく、言及されなくてもよい。

ブロックチェーン技術は、利用者のエコシステムにおいてトランザクションをほぼリアルタイムで分散し、安全で改ざん防止データ共有を可能にすることによって、企業ビジネス価値を劇的に向上させることができる。ハイパーレッジャファブリックブロックチェーンは、モジュラアーキテクチャ、平形／共通型産業技術サポート、および企業需要に対するサポートを組み込む。

序論
一実施形態によれば、ハイパーレッジャファブリック（hyperledger fabric）は、高度の機密性、回復性、柔軟性、および拡張性を提供するモジュラアーキテクチャによって支持される分散型元帳ソリューションのプラットフォームである。ハイパーレッジャファブリックは、異なるコンポーネントのプラグ可能な実装をサポートし、実用のエコシステムに存在する複雑性および混雑性に適応するように設計される。

一実施形態によれば、ハイパーレッジャファブリックは、代替的なブロックチェーン解決策と異なり、柔軟で拡張可能なアーキテクチャを提供する。

ブロックチェーン－分散型元帳
一実施形態によれば、ブロックチェーンネットワークは、ネットワーク上で行われている全てのトランザクションを記録する分散型元帳を含むことができる。

ブロックチェーン元帳は、多くのネットワーク参加者によって複製され、各々のネットワーク参加者の協働によって管理されるため、しばしば分散型元帳と称される。分散および協働は、企業が実世界において商品およびサービスを交換する方法を反映する属性である。

分散および協働に加えて、ブロックチェーンに記録される情報は、暗号技術を用いて追加されるのみである。すなわち、いったんトランザクションを元帳に追加すると、このトランザクションは、変更できない。この不変性によって、情報の事後変更ができないため、参加者は、情報の出所を容易に決定することができる。したがって、ブロックチェーンは、証明システムとして考えられてもよい。

ブロックチェーン－スマートコントラクト
一実施形態によれば、情報の一貫した更新および特定の元帳機能（トランザクション、クエリなど）をサポートするために、ブロックチェーンネットワークは、スマートコントラクトを使用することによって、元帳へのアクセスを制御する。

一実施形態によれば、スマートコントラクトは、情報をカプセル化し、ネットワーク全体にわたってその情報を簡単に維持するための重要なメカニズムだけでなく、参加者がトランザクションの特定部分を自動的に実行できるように書かれてもよい。

スマートコントラクトは、例えば、品物の到着時間に応じて出荷コストを変化するように書かれてもよい。両方の当事者によって合意され、元帳に記載された条件に基づいて、品物を受け取った時に、対応の資金が自動的に譲渡される。

ブロックチェーン－コンセンサス
一実施形態によれば、ネットワークの全体において元帳トランザクションを同期状態に保持する（例えば、適切な参加者がトランザクションを承認する場合のみ、元帳を更新し
、元帳を更新する場合、同様のトランザクションと共に同様の順序で元帳を更新することを保証する）ためのプロセスは、コンセンサスと称されてもよい。

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

ブロックチェーンの利点
一実施形態によれば、現在利用可能なトランザクションネットワークは、ビジネス記録を保持する時に存在していたバージョンのネットワークである。ビジネスネットワークのメンバが互いに取引をするが、各メンバは、各自の取引記録を管理する。同様に、品物を販売する企業がその品物の所有権を確認するための権原連鎖を保有することを保証するために、取引の対象物を販売する度に、出所を確認することができる。

現在のビジネスネットワークがコンピューティングシステムによって近代化されているにも関わらず、ネットワーク参加者のアイデンティティを管理するための統一システムが存在しておらず、（数兆ドルにも昇る世界規模の）証券取引を決済するのに数日がかかり、契約を手動で署名し実行しなければないため、出所の確認は、困難である。また、システム内の各データベースが固有の情報を含むため、１つの欠点を表す。

一実施形態によれば、ブロックチェーンは、ネットワーク上でアイデンティティを確立し、トランザクションを実行し、データを記憶するための標準方法を提供することによって、多くの非効率な標準トランザクションシステムの代替案を提供する。

一実施形態によれば、ブロックチェーンネットワークの各参加者は、各自の元帳のコピーを有する。元帳情報の共有に加えて、元帳を更新するプロセスも共有される。参加者のプライベートプログラムを用いて関連するプライベート元帳を更新する他のシステムとは異なり、ブロックチェーンシステムは、共有プログラムを用いて、共有元帳を更新する。

一実施形態によれば、共有元帳を介して参加者のビジネスネットワークを調整することによって、ブロックチェーンネットワークは、信用性および可視性を増加しながら、プライベート情報の配布に関連する時間、コストおよびリスク、並びに処理時間を低減することができる。

ハイパーレッジャファブリック
ハイパーレッジャファブリックは、他のブロックチェーン技術と同様に、元帳を有し、スマートコントラクトを使用し、参加者がトランザクションを管理するシステムである。

ハイパーレッジャファブリックは、プライベートであり許可型であるため、いくつかの他のブロックチェーンシステムとは異なる。いくつかのブロックチェーンネットワークは、「プルーフオブワーク」の代わりに、アイデンティティを使用して認証する（基準を満たす人がネットワークの参加を許可する）。ハイパーレッジャファブリックネットワークのメンバは、メンバシップサービスプロバイダを介して登録する。

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

さらに、ハイパーレッジャファブリックは、チャネルを作成する機能を提供することによって、参加者グループが別々のトランザクション元帳を作成することを可能にする。これによって、ネットワーク上の一部の参加者が競合者であり、全てのトランザクションを参加者の全員に公開しないこと（例えば、一部の参加者に特別価格を提供し、他の参加者に提供していないこと）を可能にする。２人の参加者がチャネルを作成する場合、他の参加者を除き、この２人の参加者は、そのチャネルの元帳のコピーを有する。

共有元帳
一実施形態によれば、ハイパーレッジャファブリックは、２つのコンポーネント、すなわち、ワールドステートおよびトランザクションログを含む元帳サブシステムを有する。各参加者は、所属する全てのハイパーレッジャファブリックネットワークの元帳のコピーを有する。

ワールドステートというコンポーネントは、所定の時点における元帳の状態を記述する。ワールドステートは、元帳のデータベースである。トランザクションログというコンポーネントは、ワールドステートの現在値をもたらした全てのトランザクションを記録する。トランザクションログは、ワールドステートの更新履歴である。したがって、元帳は、ワールドステートデータベースとトランザクションログ履歴との組み合わせである。

共有元帳は、ワールドステートの交換可能なデータストアを有する。デフォルトでは、共有元帳は、レベルＤＢキー値ストアデータベースである。トランザクションログは、プラグ可能ではなくてもよい。トランザクションログは、単に、ブロックチェーンネットワークによって使用される前後の元帳データベースの値を記録するものである。

スマートコントラクト
ハイパーレッジャファブリックスマートコントラクトは、チェーンコードで書かれ、ブロックチェーンの外部のアプリケーションが元帳と対話する必要があるときに、そのアプリケーションによって呼び出される。殆どの場合、チェーンコードは、トランザクションログではなく、ワールドステートである元帳のデータベースコンポーネントのみと対話する（例えば、データベースを検索する）。

コンセンサス
一実施形態によれば、トランザクションは、ネットワーク内の異なるセットの参加者の間に実行されても、実行される順序で元帳に書き込まれる。このため、トランザクションの順序が確立され、誤った（または悪意で）元帳に挿入される悪いトランザクションを拒否することができる。

ハイパーレッジャファブリックによって、ネットワークエンティティ（例えば、ネットワークユーザ、ピア、スタータ）は、参加者の間の関係を最もよく表すコンセンサスメカニズムを選択することができる。プライバシと同様に、参加者の間の関係で高度に構造化されたネットワークからよりピアツーピアであるネットワークまでの広範囲のネットワークが必要である。

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

元帳の特徴
一実施形態によれば、元帳は、ファブリック内の全ての状態遷移のひと続きの耐タンパー性の記録である。状態遷移は、参加者がチェーンコードを実行すること（トランザクション）によってもたらした結果である。各トランザクションは、作成、更新、または削除として元帳にコミットする一組の資産キー値対を生成する。

元帳は、変更できないひと続きの記録をブロックに格納するブロックチェーン、および現在のファブリック状態を保持するための状態データベースから構成される。各チャネルは、１つの元帳を含み、各チャネルは、特定の参加者グループに可視であるトランザクションの別個の元帳を含む。各ピアは、メンバとして所属する各チャネルの元帳のコピーを保持する。

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

後者の場合、参加者は、別個のチャネルを作成することによって、トランザクションおよび元帳を分離／隔離することができる。完全な透明度とプライバシとの間のギャップを埋めることを可能にするために、チェーンコードは、読み取りおよび書き込みを実行するために資産状態にアクセスする必要があるピアのみにインストールされてもよい（すなわち、チェーンコードをピアにインストールしない場合、ピアは、元帳と適切にインターフェイスすることができない）。データをさらに不明瞭にするために、ＡＥＳ（高度暗号化標準）などの通常の暗号アルゴリズムを用いて、チェーンコード内の値を（部分的または全体的に）暗号化してから、元帳に追加する。

一実施形態によれば、チャネルプライバシよりも小さい概念である「プライベートコレクション」を用いて、プライバシを改善することができる。

セキュリティおよびメンバシップサービス
一実施形態によれば、ハイパーレッジャファブリックは、全ての参加者が既知のアイデンティティを有するトランザクションネットワークを提供する。パブリックキーインフラストラクチャを用いて、組織、ネットワークコンポーネント、およびエンドユーザまたはクライアントアプリケーションに関連付ける暗号化証明書を作成する。したがって、より広いネットワークおよびチャネル上でデータのアクセスを制御および管理することができる。ハイパーレッジャファブリックのこの「許可」概念は、チャネルの存在および特性と共に、プライバシおよび機密性が重要であるシナリオに対処することができる。

コンセンサス
一実施形態によれば、分散型元帳において、コンセンサスは、単にトランザクションの順序に対する合意よりも多くのものを含むことができる。この区別は、提案およびエンドースメントから、順序付け、検証およびコミットメントまでのハイパーレッジャファブリックのトランザクションフロー全体における基本的な役割によって強調される。コンセンサスは、ブロックを含む一組のトランザクションの正当性の完全検証として定義される。

トランザクションブロックの順序および結果が明示的なポリシ基準チェックを満たした
ときに、コンセンサスが最終的に達成される。これらのチェックおよびバランスは、トランザクション中に行われ、特定のトランザクションに署名しなければならない特定のメンバを決定するためのエンドースメントポリシの使用、およびこれらのポリシを実行および遵守することを保証するためのシステムチェーンコードを含む。コミットメントの前に、ピアは、これらのシステムチェーンコードを利用して、エンドースメントが確実に存在し且つ適切なエンティティからのものであることを確認することができる。また、トランザクションを含む任意のブロックを元帳に付加する前に、元帳の現在の状態に合意または同意している間に、バージョンチェックを実行する。この最終チェックは、データの完全性を損なう可能性のある二重使用および他の脅威に対する保護を提供すると共に、非静的変数に対する関数の実行を可能にする。

エンドースメント、検証およびバージョンチェックに加えて、トランザクションフローに行われる継続的なアイデンティティ検証を含む。アクセス制御リストは、ネットワークの（オーダリングサービスからチャネルまでの）階層上で実装され、トランザクション提案が異なるアーキテクチャコンポーネントを通過する際に、ペイロードは、繰り返して署名され、検証され、認証される。コンセンサスは、合意された一連のトランザクションの順序に限定されず、むしろ、提案からコミットメントまでのトランザクションフローに行われる継続的な検証の副産物として達成されたプロセスである。

ブロックチェーンクラウドサービス－アーキテクチャ
一実施形態によれば、クラウドシステム（例えば、ブロックチェーンクラウドサービス（ＢＣＳ））などのシステムは、上述したハイパーレッジャファブリックを出発点として利用することができる。このようなシステムは、高度に進歩した特異なエンタープライズ級の分散型元帳クラウドプラットフォームを提供することによって、新しいブロックチェーンベースのアプリケーションの作成および／または既存のＳａａＳ、ＰａａＳおよびＩａａＳ並びにオンプレミスアプリケーションの拡張を可能にする。

一実施形態によれば、システムは、拡張性、安全性、ロバスト性、統一性、およびパフォーマンスなどのミッションクリティカル企業需要をサポートすることによって、作成中ブロックチェーンアプリケーションの採択およびサポートに対する障壁を取り除くことができる。システムは、ＢＣＳをクラウドＰａａＳ（Platform as a Service）として提供
することによって、ユーザがブロックチェーンを配置、設定、管理および監視することおよびブロックチェーンを企業に配置するためのコストを低減することを可能にする。また、システムは、ブロックチェーンアプリケーションの開発および他のプラットフォームとの統合を加速する。このシステムによって、ＳａａＳクラウド利用者は、ブロックチェーンクラウドプラットフォームを使用する第三者アプリケーションおよび外部分散型元帳技術を用いて、調達、支払、貿易金融、会計、ＨＲ、ＣＸなどの企業プロセスのデータを安全に共有することができ、分散トランザクションを実行することができる。

一実施形態によれば、システムは、ＰａａＳマネージャ（例えば、オラクル（登録商標）ＰａａＳサービスマネージャ（ＰＳＭ）プラットフォーム）に基づくクラウドサービスである。通常、このようなシステムは、計算スペース（例えば、外部計算スペース）に動作するクラウド管理サービスである。一実施形態において、システムは、オラクルアイデンティティクラウドサービス（ＩＤＣＳ）、オラクルロードバランササービス（ＬＢａａＳ）、オラクルイベントハブクラウドサービス、およびオラクルクラウドストレージを用いて、階層化したオラクルアプリケーションコンテナクラウドサービス（ＡＣＣＳ）を含むＰＳＭプラットフォームの特徴を利用する。各クライアントのブロックチェーンを作成することができ、テナントとして実行することができる。システムは、複数のブロックチェーンをサポートすることができ、各ブロックチェーンは、マルチテナント環境内の各々のテナントとして作成され、動作する。

したがって、このシステムによって、アプリケーションまたはクライアントアプリケーションは、必要または所望に応じて、スマートコントラクトを含む分散型元帳を実装することができる。このようなシステムのクライアントおよびユーザは、クラウド（ブロックチェーン信用）の内部であってもよく、または外部であってもよい。いくつかのブロックチェーンネットワークは、クラウド環境外部のコンポーネントを含んでもよく、または特定のクラウドに限定されてもよい。

一実施形態によれば、このシステムは、多種多様な応用、特に信用およびアイデンティティを解決しなければならないマルチパーティトランザクションに有用である。他のブロックチェーンシステムとは異なり、本開示のシステムサービスは、匿名ではない。実際に、アイデンティティおよび監査能力は、基本的な統合要素である。したがって、ＢＣＳは、例えば、資本市場、越境トランザクション、金融サービス、資産トランザクション、法律規制、ヘルスケア記録、公開、ロジスティック、変更追跡、および偽造防止において応用されてもよい。

上述したように、ブロックチェーン上の各当事者は、（元帳が特定の当事者に作成／私有化されない限り）全てのデータベースおよび全ての履歴にアクセスすることができる。各当事者は、データまたは情報を制御することができない。また、全ての当事者は、仲介人なしで、トランザクション相手の記録を直接に検証することができる。通信は、中心ノードを介せず、ピア間で直接に行われる。各ノードは、情報を記憶すると共に、情報を全ての他のノードに転送する。いったんトランザクションがデータベースに入力され、アカウントが更新されると、記録は、その前に入力された全てのトランザクションの記録にリンクされる（したがって、「チェーン」と呼ばれる）ため、変更することができない。トランザクションにエラーが存在する場合、新しいトランザクションを用いてエラーを訂正することができる。両方のトランザクションは、提供されたユーザに可視である。新しい有効なトランザクションを追加するために、参加者は、コンセンサスメカニズムを介してトランザクションの有効性に合意することができる。ブロックチェーンの参加者は、資産の出所、および資産所有権の時間的な変化を検証することができる。デジタル署名を用いて文書を認証することができ、デジタル署名をアクセス制御（許可レベルの変更）およびプログラマビリティ（実行可能なビジネスルール）に追加することができる。

多くのマルチパーティトランザクションにおいて、当事者は、資産またはサービスを受け取った時に、金銭を交換する。通常、トランザクション時間によって、一方の当事者は、他方の当事者よりも先に商品または金銭を提供しなければならない。いくつかの環境では、信用は、仲介人が契約の条件が成立するまで資金を預託することによって解決される。この方法は、当事者間の信用を解決する。しかしながら、この方法は、信用しなければならない別の集権者を追加するため、複雑性を増加すると共に、トランザクションのコストを増加する。本開示のシステムの一部としてスマートコントラクトを使用することによって、仲介人を排除することができる。これによって、当事者は、仲介人を介することなく、ブロックチェーン上で信用できるトランザクションを行うことができる。

一実施形態によれば、ＢＣＳなどの本開示のシステムの利点は、システム内の情報を分散することを含む。監査能力を利用できると共に、アクセスを制御することができ、いくつかのプライバシを管理することができる。また、ブロックチェーン元帳は、本質的に変更することができず、拒否することができない。元帳は、複数のブロックから構成される。各トランザクションブロックは、ブロックＩＤ、過去のハッシュ、データハッシュ、タイムスタンプ、トランザクションＩＤリスト、動作（１～ｎ）、チェーンコードＩＤ、チェーンコード提案、応答（ｒ／ｗセット、イベント、成功または失敗）、およびエンドーサを含む。各ブロックは、過去のハッシュおよびそれ自体のハッシュを含むため、いった
ん公開／配布されると、本質的に順序付けられ、不変である（なお、現在ブロックのハッシュは、過去ブロックのハッシュと現在ブロック内の他のデータとのハッシュであるため、チェーン内のブロックをリンクする）。コンセンサスは、矛盾を解消することができる。集中型データベースまたは仲介人と比較して、集中型権威者に過度の権限を与える必要はない。また、元帳の分散性質は、分散コピーおよびコンセンサスを使用することによって、（アルゴリズム的に可能であっても）変更が難しいため、ブロックチェーン記録技術の基本的な不変性を強化する。したがって、トランザクションの順序が一定であるため、誰かがチェーンの最新のブロックのコピーを有する場合、元帳のハッキングは、ほぼ不可能である。

特定の実施形態において、以下で説明するように、本開示のシステムは、オラクルＰａａＳサービスマネージャ（ＰＳＭ）プラットフォームに基づくことができ、ファブリックベースのブロックチェーンの作成、監視および設定を単純化／容易化／自動化する管理コンソールを含むこによって強化される。また、アプリケーションとブロックチェーンファブリックとの間の接触を簡単化するために、１つのＲＥＳＴ ＡＰＩを含むＲＥＳＴプロキシサービスが提供される。開発者は、スマートコントラクトを構築し、管理コンソールを用いてスマートコントラクトを配置し、次いで、アプリケーションを用いて、ブロックチェーン上でスマートコントラクトを（デフォルトの場合）非同期的にまたは（即時応答が要求される場合）同期的に呼び出すことができる。ＲＥＳＴプロキシサービスおよびＡＰＩは、プラットフォームの需要に応じて、同期および非同期の両方の能力を提供する。

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

ハイパーレッジャファブリック
上述したように、一実施形態において、本開示のシステムは、スマートコントラクトを実行するための分散型元帳プラットフォームを提供するハイパーレッジャファブリックを実装することができる。ハイパーレッジャファブリックは、コンテナ技術を利用して、システムのアプリケーションロジックを含む「チェーンコード」と呼ばれるスマートコントラクトをホストする。代替的な実施形態において、ブロックチェーンクラウドサービスは、例えば、２０１６年５月３１日に出願され、参照により本明細書に組み込まれる米国特許出願第１５／１６９６２２号「分散型元帳システムにおける説明責任および信用」に記載された「Tendermint」元帳システムを含む代替的な分散型元帳プラットフォームを実装する。

ハイパーレッジャファブリックの分散型元帳プロトコルは、ピアによって実行される。従来のブロックチェーン技術の１つの欠点は、全てのピアが全てのトランザクションを記録する必要があることである。このことは、実質的にＩ／Ｏおよびプロセッサのオーバーヘッドを引き起こし、エンタープライズ級のシステムに応じて簡便に拡張することができない。ハイパーレッジャファブリックは、２種類のピアを識別する。コミッタピアは、エンドースメントを確認し、トランザクションをブロックチェーンにコミットする前にトランザクション結果を検証し、および元帳を管理するためのネットワーク上のノードである。一方、非検証ピアは、（トランザクションを発行する）クライアントを検証ピアに接続するためのプロキシとして機能するノードである。非検証ピア（またはエンドーサピア）
は、トランザクションを実行しないが、トランザクションをシミュレートし、署名することができる。ピアの種類／機能の分離は、システムの拡張性を改善する。オーダリングサービスは、署名済みトランザクションを受信し、ブロックに順序付け、ブロックをコミッタピアに送信することができる。このような分散型元帳システムにおいて、コンセンサスは、元帳に追加される次のトランザクションセットの合意を形成するプロセスである。ハイパーレッジャファブリックにおいて、コンセンサスは、３つの別個のステップ、すなわち、トランザクションのエンドースメント、順序付け、並びに検証およびコミットメントを含む。

一実施形態によれば、ハイパーレッジャの特徴は、即時最終性を有し、チェーンコードと呼ばれる任意のスマートコントラクトを実行する許可型ブロックチェーンである。ユーザによって定義されたチェーンコードのスマートコントラクトは、コンテナの中でカプセル化され、システムチェーンコードは、ピアと同様のプロセスに実行される。チェーンコードの実行は、トランザクションの順序で分割されるため、必要とされるノード間の信用レベルおよび検証レベルを制限し、ネットワークのオーバーヘッドを低減する。

一実施形態によれば、ハイパーレッジャファブリック内のチャネルは、共通のネットワーク上で資産を交換する競合ビジネスおよび規制産業によって要求された高度なプライバシおよび機密性で、多者トランザクションを行うことを可能にする。変更できない共有元帳は、各チャネルの全てのトランザクション履歴を暗号化し、監査および紛争を効率的に解決するためのクエリ機能を含む。元帳は、チャネルの範囲に作成される。元帳は、（全ての参加者が１つの共通チャネル上で動作している場合）ネットワーク全体にわたって共有されてもよく、または特定組の参加者のみを含むように私有化されてもよい。

一実施形態によれば、ハイパーレッジャファブリックは、ＴＬＳ証明書、登録証明書およびトランザクション証明書を認証するための認証局（ＣＡ）をサポートすることによって、セキュリティを実装する。パブリックキーインフラストラクチャを用いて、組織、ネットワークコンポーネント、およびエンドユーザまたはクライアントアプリケーションに関連付ける暗号証明書を作成する。したがって、より広いネットワークおよびチャネル上でデータのアクセスを制御および管理することができる。ハイパーレッジャファブリックのこの「許可」特徴は、チャネルの存在および能力と共に、多者企業システムのプライバシおよび機密性の要求を満たす。

一実施形態によれば、ハイパーレッジャファブリックは、チェーンコードトランザクションを用いて資産を変更することができる。上述したように、チェーンコードは、１つ以上の資産と、資産を変更するためのトランザクション命令とを定義するソフトウェアである。

一体化コンセンサスメカニズムは、提案およびエンドースメントから、順序付け、検証およびコミットメントまでのハイパーレッジャファブリックのトランザクションフローにおいて、基本的な役割を有する。コンセンサスは、上述したように、ブロックを含むトランザクションセットの有効性の検証である。コンセンサスは、トランザクションブロックの順序および結果が明示的なポリシ基準チェックを満たしたときに最終的に達成される。

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

一実施形態において、システムは、カフカ（Kafka）クラスタをオーダリングサービス
として利用することができる。カフカは、セマンティクスの公開および加入をサポートする分散型ストリーミングサービスである。カフカクラスタは、複数のサーバ上で動作し、一連の記録をトピックと呼ばれるカテゴリに記憶する。各記録は、キー、値およびタイムスタンプを含む。したがって、カフカは、オーダリングサービスノード（ＯＳＮ－ｎ）およびカフカクラスタを含むオーダリングサービスとして使用されてもよい。オーダリングサービスクライアントは、複数のＯＳＮに接続されてもよい。ＯＳＮは、互いに直接に通信しない。これらのオーダリングサービスノード（ＯＳＮ）は、（１）クライアント認証を行い、（２）クライアントが簡単なインターフェイスを用いてチェーン１に書き込むことまたはチェーン１から読み取ることを可能にし、および（３）既存のチェーンを再構成するまたは新しいチェーンを作成するための構成トランザクションに対してトランザクションの選別および検証を行う。カフカ内のメッセージ（記録）は、トピックパーティションに書き込まれる。カフカクラスタは、複数のトピックを有してもよく、各トピックは、複数のパーティションを有してもよい。各パーティションは、継続的に付加される、順序づけられた不変のひと続きの記録である。ＯＳＮは、クライアント認証およびトランザクション選別を実行した後、特定のチェーンに所属する入来クライアントトランザクションを対応するチェーンのパーティションに中継することができる。次いで、クライアントトランザクションは、そのパーティションで実行され、全てのオーダリングサービスノードに対して共通なトランザクションの順序づけられたリストを返信することができる。

一実施形態によれば、各ピアは、エンドーサおよびコミッタになることができる。設定項目（例えば、CORE_PEER_ENDORSER_ENABLED）は、ピアをエンドーサにすることができる。ピアがチャネルに参加すると、このピアは、このチャネルのコミッタになる。チェーンコードがピアにインストールされると、このピアは、このチェーンコードのエンドーサ候補になる。クライアントがトランザクションを提案する場合、クライアントは、（エンドーサ候補から）エンドーサになるピアを選択することができる。

一実施形態によれば、オーダがブロックをピアに配布するための順序付けメカニズムは、以下の通りである。まず、ピア（例えば、リーダピア）は、自身のバージョン（最後のブロック番号）を送信することによって、オーダから新しいブロックを要求する。次に、オーダは、ピアのバージョンをチェックする。ａ）ピアのバージョンがオーダのバージョンよりも大きい場合、オーダの元帳が無くしており、イベントハブ（EventHub）から回復することができないことを示すエラーをピアに返信する（このシナリオにおいて、オーダは、適切な動作を継続することができない）。ｂ）ピアのバージョンがオーダのバージョンより小さい場合、オーダは、ＲＡＭまたはローカルファイル内のローカル元帳からブロックを取り出し、ピアに返信する。ｃ）両者が同様のバージョンを有する場合、オーダは
、新しいブロックが利用可能になるまで中止する。イベントハブから切り出した新しいブロックが利用可能になると、オーダは、このブロックをローカルブロックファイルまたはＲＡＭに入れ、次に、元帳からこのブロックを読み出す配布スレッドをピアに返信する。ピアは、このブロックを入手し、ローカル元帳にコミットし、ブロックの最新バージョンを他のピアにブロードキャストすることができる。

ＢＣＳシステムアーキテクチャ
図１Ｂは、ブロックチェーンサービスを提供するシステムのファブリックに行われたトランザクションフローを示す。より具体的には、図１Ｂは、一実施形態に従って、ブロックチェーンクラウドサービス（ＢＣＳ）システムを示す。図示のように、ブロックチェーンクラウドサービスコンポーネントは、例えば、オラクルＰａａＳサービスマネージャ（ＰＳＭ）プラットフォーム上で、計算スペース１２０（例えば、外部計算スペース）に作成される。システムへのアクセスは、ＰＳＭ ＡＰＩ１２２およびブロックチェーンＲＥＳＴ ＡＰＩ１２４によって仲介される。外部計算スペース１２０は、負荷分散サービスＬＢａａＳ（load balancing as a service）１２６を利用して、入来トランザクション
を利用可能なリソースに適切に分散する。

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

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

一実施形態によれば、ファブリックの分散型元帳プロトコルは、ピアによって実行される。ファブリックは、２種類のピアを識別する。検証ピアは、コンセンサスの実行、トランザクションの検証、および元帳の管理に関与するネットワーク上のノードである。一方、非検証ピアは、（トランザクションを発行する）クライアントを検証ピアに接続するためのプロキシとして機能するノードである。非検証ピアは、トランザクションを実行しないが、トランザクションを検証することができる。ファブリックのいくつかの重要な特徴は、即時最終性を有し、チェーンコードと呼ばれる任意のスマートコントラクトを実行する許可型ブロックチェーンを含む。ユーザによって定義されたチェーンコードのスマートコントラクトは、コンテナの中でカプセル化され、システムチェーンコードは、ピアと同様のプロセスに実行される。ファブリックは、ＴＬＳ証明書、登録証明書、およびトランザクション証明書を認証するための認証局（ＣＡ）をサポートすることによって、コンセンサスプロトコルおよびセキュリティを実装する。

一実施形態によれば、ＢＣＳエンティティは、ＡＣＣＳ１２８を用いて階層化されたコンテナインスタンスで動作する。コンテナは、ＰＳＭの作成動作によって作成および／または作動される。ファブリックＣＡコンテナ１３０は、ＢＣＳファブリックＣＡ（認証局
）コンポーネントを提供するコンテナである。ＢＣＳピアコンテナ１３２は、元帳コンポーネントに対して読み出し／書き込み動作を実行するために、元帳コンポーネントを管理し、チェーンコードコンテナを実行するためのＢＣＳピアネットワークエンティティが動作するコンテナである。ＢＣＳオーダコンテナ１３４は、トランザクションを全てのチャネルのブロックチェーンに順序付けるためのＢＣＳオーダが動作するコンテナである。ＢＣＳチェーンコード実行コンテナ１３９は、ピアエンティティによって作成され、作動されるコンテナである。コンテナにおいて、チェーンコード実行ユニットは、親ピアエンティティと通信し、資産とブロックチェーン内の資産を変更するためのトランザクション命令との符号化を実行する。

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

一実施形態によれば、ドッカ／ウイーブ（Docker/Weave）１４１は、コンテナサービスである。コンテナは、共有オペレーティングシステム上で単独に実行できるフォーマットでソフトウェアをパッケージ化する方法である。ＶＭとは異なり、コンテナは、完全なオペレーティングシステムをバンドルせず、その代わりに、ソフトウェアの動作に必要なライブラリおよび設定を使用してバンドルする。これによって、効率的且つ軽量な自己内蔵型システムを作成することができ、ソフトウェアが配置場所に関係なく常に同様に動作することができる。

一実施形態によれば、各ＢＣＳインスタンスは、異なる種類のノードから構成される。ＢＣＳインスタンスは、少数（例えば、０以上）から多くのピアノードを含むことができ、少数（例えば、０）から多くのオーダノードを含むことができる。各ＶＭは、１つのＢＣＳインスタンスを含み、各ＢＣＳインスタンスは、１つから複数のファブリックＣＡノードを含む。ＢＣＳゲートウェイについて、ＢＣＳインスタンスは、少数（例えば、０）から多くのＢＣＳゲートウェイを含むことができる。ＢＣＳコンソールは、ＢＣＳインスタンスのコンポーネントである。各ＢＣＳインスタンスは、１つのみのＢＣＳコンソールを含む。

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

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

一実施形態によれば、上記に列挙した各種類のコンテナに、ブループリントを独立サービスタイプとして定義することができる。オラクルクラウドスタックマネージャは、ブループリントを用いて、単一のスタックユニットで全ての独立サービタイプの作成を自動化する。各ＢＣＳエンティティをサービスタイプとして定義する利点は、様々な実行エンティティを容易に更新および管理することである。アプリケーションコンテナ階層サービスは、４種類の動作、すなわち、作成サービス（CREATE_SERVICE）、削除サービス（DELETE_SERVICE）、スケールサービス（SCALE_SERVICE）、起動/停止/再起動（Start/Stop/Restart）をサポートする。これらの動作は、サービスごとに適用することが可能である。

一実施形態によれば、ハイパーレッガファブリックネットワークにおいて、オーダリングサービスコンポーネントは、アパッチカフカ（Apache Kafka）を用いて、クラッシュフォールトトレラント方法でオーダリングサービスを提供し、複数のチェーンをサポートする。したがって、ＢＣＳクラウドサービスにおいて、オーダリングサービスコンポーネントは、（カフカのパワーを処理済みストリーミングデータプラットフォームとして配布し、オラクルの残りのクラウドと一体化することができる）オラクルイベントハブクラウドサービス（ＯＥＨＣＳ）を使用する。

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

一実施形態によれば、ゲートウェイベースのアプリケーション１０３および／またはファブリックベースのアプリケーション１０５などのクライアントは、インターネット１０７などのネットワークおよび（後述する）クラウドゲートを含むロードバランサＬＢａａＳ１２６などのフロントエンドを介して、ＡＡＣＳインスタンス１２８と通信することができる。入来コールは、（図面において太い破線として示された）ＲＥＳＴ通信、または特定の状況では（図では淡い破線として示された）入来ｇＲＰＣ通信を含むことができる。入来ＲＥＳＴ通信は、（ＲＥＳＴ ＡＰＩ／ＲＥＳＴプロキシを含み得る）ゲートウェイ１３８、コンソール１３６、または（上述した）エージェントファブリックＣＡ１３０に転送されてもよい。内部コール（ｇＲＰＣ）に変形／変換されたＲＥＳＴ通信は、（エージェント／ピア１３２、エージェント／オーダ１３４、チェーンコード１４２、およびチェーンコードビルダ１４０を含む）ブロックチェーンファブリック／ハイパーレッジャのインスタンスとインターフェイスすることができる。一方、入来ｇＲＰＣ通信は、例えば、エージェント／ピア１３２およびエージェント／オーダ１３４に直接に転送され、ブロックチェーン／ハイパーレッジャとインターフェイスすることができる。

一実施形態によれば、ＡＣＣＳインスタンスにトランザクションが行われると、ＡＣＣＳインスタンスは、例えば、ＲＥＳＴ通信を介して元帳をクラウドストレージに永続化することができ、またはＲＥＳＴ通信を介してイベントハブと通信することができる。

一実施形態によれば、図面は、１つのＡＣＣＳインスタンスのみを示しているが、当業者なら、（例えば、ゲートウェイベースのアプリケーション１０３および／またはファブリックベースのアプリケーション１０５などの）クライアントが上述したＢＣＳランタイムを介して通信することができるＡＣＣＳインスタンスが１つ以上であってもよいことを容易に理解するであろう。

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

一実施形態によれば、各ＢＣＳインスタンス１００ａに対して、オーダ１０１ａは、１：Ｎの比で提供され、ファブリックＣＡメンバシップ１０２ａは、１：Ｎの比で提供され、ＢＣＳ ＲＥＳＴプロキシ１０３ａは、１：Ｎの比で提供され、ＢＣＳコンソール１０４ａは、１：１の比で提供され、ピアコンテナ１０５ａは、１：Ｎの比で提供されてもよい。

各ピアコンテナは、トランザクションをシミュレートすることができるエンドーサと、同一のピアコンテナに形成され、元帳に変更を適用することができるコミッタとを含むことができる。

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

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

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

一実施形態によれば、クラウドゲート２１２は、例えばＯＡｕｔｈ２およびＯｐｅｎＩＤコネクト規格を用いてウェブブラウザおよびＲＥＳＴ ＡＰＩリソースを保護する逆方向プロキシ「アクセス強制モジュール」または「ポリシ強制ポイント」である。ＩＤＣＳは、内部でクラウドゲートを使用することによって、自身の管理ＵＩおよびＲＥＳＴ ＡＰＩ（「ＩＤＣＳウェブ層」と呼ばれる）を保護する。別の応用として、クラウドゲートＯＴＤは、非ＩＤＣＳまたはスタンドアローンとして知られるセミサポート／暫定セットアップにおいて、追加のインスタンスとして配置される。

一実施形態によれば、ＯＡｕｔｈ／ＯｐｅｎＩＤベースの認証は、ＨＴＴＰ要求が「ユーザエージェント」ヘッダを含む場合、すなわち、ＨＴＴＰ要求がブラウザまたはモバイルアプリのようなＵＩからの場合にトリガされる（ＵＩクライアントの）ユーザブラウザフローをサポートする。クラウドゲートは、ユーザにクレデンシャル（ユーザ名／パスワード）を提示し、クレデンシャルを検証し、その後、ブラウザからの後続のＨＴＴＰ要求によって使用され得るＯＡｕｔｈセッションクッキを作成してユーザに返送する。また、ＯＡｕｔｈ／ＯｐｅｎＩＤベースの認証は、（プログラムクライアントの）リソースサーバフローをサポートする。このフローは、ＨＴＴＰ要求が認証「ベアラ」トークンヘッダを含む場合にトリガされる。クラウドゲートは、認証のためにトークンを検証する。

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

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

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

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

一実施形態によれば、ＢＣＳは、オラクルクラウドなどのクラウドシステムに配置される。ゲートウェイは、ＡＣＣＳコンテナに動作することができる。ゲートウェイは、ステートレスである。古いゲートウェイを強制終了して、新しいゲートウェイを起動することによって、ゲートウェイを更新することができる。ＢＣＳゲートウェイは、クライアントクエリを許可することができ、またはＲＥＳＴｆｕｌプロトコルを介してファブリックチェーンコードを呼び出すことができる。ＢＣＳゲートウェイは、クライアントがＨＴＴＰＳ／ＲＥＳＴｆｕｌサービスを介してオラクルクラウド内のファブリックネットワークにアクセスすることを可能にする。ＢＣＳゲートウェイは、ファブリックＳＤＫを用いてファブリックネットワークと通信するネットワークノードである。ファブリック内の通信は、ｇＲＰＣを通信プロトコルとして使用する。ＢＣＳゲートウェイは、ＨＴＴＰＳ／ＲＥＳＴｆｕｌ ＡＰＩをクライアント側のクライアントに提供する。ＲＥＳＴ ＡＰＩは、クライアントがファブリックＳＤＫを用いてファブリック内で関数を呼び出すことを可能にする。

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

一実施形態によれば、ＩＤＣＳは、ゲートウェイ証明書およびゲートウェイユーザ（「アプリアダプタ」）証明書を発行する。これらの証明書は、組織ＣＡによって署名される。ゲートウェイおよびゲートウェイユーザは、組織ＣＡと共に配置されるため、ＨＴＴＰＳを用いて互いに検証することができる。

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

一実施形態によれば、１つのコンテナは、１つのトムキャット（tomcat）サーバを稼働し、１つのファブリックユーザにマッピングされる１つのＢＣＳゲートウェイを配置する。複数のアプリアダプタは、１つのゲートウェイに接続することができる。

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

一実施形態によれば、ＢＣＳＧＷは、オラクルクラウドで実行され、設定は、ＪＳＯＮファイルを用いてＢＣＳコンソールによって設定される。管理者ユーザは、ピア、チャネルおよびチェーンコードの一部をゲートウェイに公開することができる。管理者ユーザは、コンソールを介してゲートウェイを起動する。ゲートウェイは、起動後に設定をリフレッシュしない。管理者ユーザは、チェーンコードのエンドーサを設定することができる。エンドユーザは、ポリシを知らず、ゲートウェイは、チェーンコードポリシをチェックしない。

一実施形態によれば、ＢＣＳＧＷは、ＢＣＳコンソールによって起動される。ＢＣＳコンソールは、ＢＣＳＧＷ設定ファイルを作成し、ＢＣＳＧＷパッケージを用いて新しいゲートウェイを起動する。起動時に、起動スクリプトは、ＢＣＳＧＷ設定ファイルをチェックし、トムキャット用の設定ファイル（例えば、トムキャット設定ファイル）を変更してから、トムキャットを起動する。トムキャットは、ＢＣＳＧＷのスレッドを起動し、このスレッドは、各チャネルの設定ファイルを読み出すことによって、チャネルオブジェクトを作成し、オーダ、ピアおよびイベントハブとの接続を作成する。異なるチャネルは、オーダ／ピア／イベントハブへの異なる接続を有する。イベントハブは、ピアの第２のポートである。ゲートウェイは、このポートに接続することによって、トランザクションの結果を取得する。トムキャットサーブレットコンテナは、クライアント要求をリッスンすることができる。チェーンコードクエリ方法の場合、ＢＣＳＧＷは、要求をチャネルの全てのピアに送信し、第１の結果のみを使用する。チェーンコード呼び出し方法の場合、ＢＣＳＧＷは、要求をチャネルの全てのエンドサに送信し、全てのエンドサのうちの１つが成功を返信する場合、ＢＣＳＧＷは、トランザクションをチャネルの全てのオーダに送信する。

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

一実施形態において、非同期ＡＰＩは、以下のように動作することができる。クライアント要求のパラメータをチェックした後、ゲートウェイは、トランザクションＩＤをクライアントに返信する。したがって、クライアントは、起動されたトランザクションが終了
していないことを認識することができる。ゲートウェイは、トランザクションを継続して処理するために、バックグラウンドスレッドを起動する。クライアントは、未完了トランザクションを追跡することができる。ゲートウェイは、クライアントがトランザクションＩＤを用いてトランザクション状態をクエリするための「トランザクション」ＡＰＩを提供することができる。

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

永続化－ストレージクラウド
一実施形態によれば、ハイパーレッジャファブリックプロジェクトコードは、元帳をローカルファイルシステムに格納するためのブロック、および他のランタイムデータ、例えば、ブロックインデックス、ワールドステート、履歴、および（全ての元帳ＩＤおよび回復ステータスを保持する）元帳プロバイダデータベースを同一のローカルファイルシステムに格納されているレベルＤＢに格納するためのブロック含む。ＡＣＣＳにおいて、コンテナファイルシステムは、一過性である。これは、何らかのハードウェア障害によって、コンテナが停止され、新しいＶＭ上で新しいコンテナが再起動される場合、ファイルシステムの内容が失われる可能性があることを意味する。全てのコンテナが失われた場合、元帳を回復することができない。したがって、元帳データをＡＣＣＳコンテナの外部に格納しなければならない。このため、永続化ソリューションは、上述したハイパーレッジャファブリックのコンポーネントによって使用されるオブジェクト格納サービスとして提供される。

一実施形態によれば、ＢＣＳにおいて、永続化ソリューションは、ストレージクラウドサービス、例えば、オラクルストレージクラウドサービスを利用する。元帳は、オブジェクトストアにバックアップされる。元帳は、コンテナファイルシステムに書き込まれないが、オブジェクトストレージにバックアップされる。インデックスおよびワールドステートは、コンテナファイルシステムを用いて記録され、コンテナを再起動する場合、ストレージクラウドサービスから回復されることができる。オラクルストレージクラウドは、インフラストラクチャサービス（ＩａａＳ）製品であり、ファイルおよび非構造化データを記憶するためのエンタープライズ級の大規模なオブジェクト記憶ソリューションを提供する。

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

オブジェクトストレージは、各オーダの元帳を永続化するために使用される。オーダがブロックをピアに配布するための現行メカニズムは、以下の通りである。まず、ピアは、自身のバージョン（最後のブロック番号）を送信することによって、オーダから新しいブロックを要求する。次に、オーダは、ピアのバージョンをチェックする。ａ）ピアのバー
ジョンがオーダのバージョンよりも大きい場合、オーダの元帳が無くしており、イベントハブ（EventHub）から回復することができないことを示すエラーをピアに返信する（このシナリオにおいて、オーダは、適切な動作を継続することができない）。ｂ）ピアのバージョンがオーダのバージョンより小さい場合、オーダは、ＲＡＭまたはローカルファイル内のローカル元帳からブロックを取り出し、ピアに返信する。ｃ）両者が同様のバージョンを有する場合、オーダは、新しいブロックが利用可能になるまで遮断する。イベントハブから切り出した新しいブロックが利用可能になると、オーダは、このブロックをローカルブロックファイルまたはＲＡＭに入れ、次に、元帳からこのブロックを読み出す配布スレッドをピアに返送する。ピアは、このブロックを入手し、ローカル元帳にコミットし、ブロックの最新バージョンを他のピアにブロードキャストすることができる。

一実施形態によれば、上記のプロセスによって、オーダまたはイベントハブのいずれかは、全てのブロックを永続化することができる。上述したように、イベントハブは、時間制限保持をサポートする。イベントハブがブロックの保存を実行することができる場合、オーダは、元帳タイプをＲＡＭまたはファイルに設定することができる。オーダが再起動され、元帳が失われた場合、オーダは、イベントハブから記録を再生し、バッチメッセージをブロックに切断することによって、元帳を再構築することができる。イベントハブが時間制限保持のみをサポートする場合、いったんオーダが再起動され、元帳が失われると、イベントハブ内の最初の記録が元帳の真の記録ではないため、元帳を正しく再構築することはできない。この場合、オーダは、チャネル情報を含む最初のブロックが失われ、バージョン番号（最後のブロック番号）も正しくないため、古いチャネルを起動することができない。

一実施形態によれば、各オーダは、全てのチャネルＩＤをオブジェクトストレージに永続化すると共に、各ブロックをオラクルストレージに保存することができる。ピアは、チャネル情報を有するジェネシスブロック（genesis block）のみを永続化する。他のブロ
ックデータが失われると、ピアは、オーダから他のブロックデータを読み取ることができる。

一実施形態によれば、ＡＣＣＳインスタンス３００は、元帳３１６およびインデックス３２６を含むピアコンテナ３０６と、元帳３１８およびインデックス３２８を含むピアコンテナ３０８とを含むことができる。ピアは、５種類のランタイムデータ、すなわち、トランザクションログ（ブロックファイル）、ブロックファイルインデックス（レベルＤＢ）、元帳プロバイダＤＢ（レベルＤＢ）、状態データベース（レベルＤＢまたはカウチＤＢ）、および履歴（レベルＤＢ）を生成する。全てのトランザクションデータは、ローカルファイル内のリンク付きブロックとしてトランザクションログに格納され、オラクルストレージクラウドサービスに永続化される。元帳プロバイダＤＢは、全ての元帳ＩＤおよびステータスをレベルＤＢに永続化する。元帳ＩＤは、ピアが所属するチャネルを識別するための特有ＩＤであり、オラクルストレージクラウドサービスに保存されなければならない。実行時に、ピアは、他のものを自動的に回復することができ、ローカルファイルシステムに保存することができる。

一実施形態によれば、オラクルストレージクラウドサービスは、ファイルをオブジェクトにアップロードするまたはオブジェクトからファイルをダウンロードするためのＲＥＳＴ ＡＰＩを提供する。新しいブロックを作成する場合、まず、従来と同様にブロックをローカルブロックファイルに書き込むが、各ファイルに１つのみのブロックを書き込むことで異なる。次に、このブロックファイルをオブジェクトとしてオラクルストレージにアップロードする。アップロードが失敗した場合、ローカルファイルの変化は、ロールバックされ、エラーを発信者に返信する。

一実施形態によれば、オーダがブロックファイルインデックスの最新チェックポイントを更新するときに、その情報をオラクルストレージに永続化してから、ローカルレベルＤＢを更新する。この操作が失敗した場合、エラーを発信者に返信することができる。この情報は、ブロックファイルインデックスの回復に使用される。オラクルストレージにおいて、各ピアおよびオーダは、ＭＳＰ ＩＤおよびノードＩＤの組み合わせからなる固有のコンテナ名を有する。オブジェクト名は、プレフィックスとしてのチャネル名とブロックファイル名との組み合わせである。さらなる詳細は、オラクルストレージの命名規則を参照する。

一実施形態によれば、オプションとして、元帳プロバイダＤＢをオラクルストレージに保存することができる。元帳プロバイダＤＢが更新されると、レベルＤＢの全体をオラクルストレージクラウドサービスに複製することができる。このファイルが非常に小さく且つ更新が頻繁ではないため、複製によるオーバーヘッドを無視することができる。コンテナを再起動する場合、オラクルストレージクラウドサービスからコンテナをダウンロードすることができる。新しいコンテナからオーダを再起動する場合、まず、オーダは、ストレージオブジェクトからチャネルＩＤをダウンロードし、その後、オーダは、チャネルＩＤに従って、ストレージから最新のチェックポイントを取得する。次に、オーダは、最初のブロックから最後のブロックまでのブロックインデックスを回復する。この間、ブロックファイルは、１つずつダウンロードされる。その後、オーダは、状態ＤＢおよび履歴ＤＢを回復する。新しいコンテナからピアを再起動する場合、まず、ピアは、元帳プロバイダＤＢをダウンロードし、その後、全ての元帳ＩＤを取得することができる。次に、ピアは、元帳ＩＤに従って、ストレージから関連するジェネシスブロックを取得する。ピアは、ジェネシスブロック内の設定で開始し、クエストをオレンダに送信することによって、他のブロックデータを取得する。ピアは、これらのブロックを入手した後、ブロックインデックス、状態ＤＢおよび履歴ＤＢを回復する。

一実施形態によれば、ローカルブロックファイルは、読み取りキャッシュとして機能する。クエリは、まずローカルからデータを読み取り、データがローカルに存在しない場合、オブジェクトストレージからデータをダウンロードする。元帳のほかに、チェーンコードのソースコードをオラクルストレージに永続化する必要がある。チェーンコードを現行のファブリックにインストールした後、ソースコードは、符号化され、ピアに格納される。ピアは、各呼び出しまたはインスタンスのチェーンコードコンテナをチェックし、コンテナが存在しない場合、ソースコードからコンテナを再構築する。したがって、各チェーンコードをインストールするたびに、ソースコードをオラクルストレージにアップロードすることができ、ディスク障害からピアを再起動するときに、オラクルストレージからソースコードをダウンロードすることができる。

ＢＣＳ：ＳＤＫベース設定ファイルの操作および作成後の配置
一実施形態によれば、設定ファイルおよび配置機能は、ピア、オーダ、ＣＡサーバ、およびチェーンコードを含むアプリケーションを配置または更新するときに、アプリケーションに関する設定を配置、生成、更新、および取得する。これらの機能は、ＢＣＳコンソール（Node.js）およびファブリックコンテナ（ピア／オーダ／チェーンコードコンテナ
）の両方に常駐する。ＵＩから要求されると、これらの機能は、設定を取得／更新し、必要に応じてＳＤＫ ＡＰＩを呼び出すことによって、設定を変更する。ＢＣＳコンソールバックエンドの一部としてのこのコンポーネントは、ＢＣＳコンソールＵＩ、ＩＤＣＳバックエンドＳＤＫ、および全てのＢＣＳアプリケーションと対話することによって、ＵＩを操作するためＳＤＫを提供し、要求された設定を取得／更新する。また、このコンポーネントは、ＢＣＳアプリケーションの作成を補助する。ＢＣＳ作成コンポーネントは、ＢＣＳアプリケーションを、ＰＳＭを用いて作成されたＶＭのドッカ（docker）コンテナに配置する。この特徴は、ＢＣＳコンソールＵＩのＳＤＫ ＡＰＩを実装し、ＢＣＳ作成コ
ンポーネントは、後期作成段階において、ＢＣＳアプリケーション構成を取得または更新し、配置する。作成システムは、後期作成段階において、ＣＡサーバ、オーダ、ピアなどのＢＣＳアプリケーションをドッカ／スウォーム（swarm）に配置する。ＶＭは、起動時
に、起動スクリプトを呼び出すことによって、後期作成作業およびＶＭ初期作業を行う。

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

一実施形態によれば、作成システムは、全てのリソースの割り当てを行う。リソースは、ＶＭ、ネットワーク、およびストレージを含む。

一実施形態によれば、作成システムは、全てのリソース割り当て情報をストレージサービスに保存する。この情報は、ＶＭ番号および関連するネットワークアドレス／アカウント証明、各ＶＭ内のＢＣＳアプリケーションの番号および種類、公衆ＩＰおよび内部ＩＰを含む。また、作成システムは、（ＶＭ間でアクセス可能な）コンテナ用の十分な内部ＩＰアドレスを有する。

一実施形態によれば、ＢＣＳ作成コンポーネントが作成作業を完了した場合、ＶＭ起動スクリプトは、起動してスウォームを呼び出すことによってアプリケーションコンテナを配置し、コンテナ起動シェルスクリプトは、コンテナ内で初期動作を実行する。

一実施形態によれば、ＢＣＳコンソールは、作動すると、ストレージサービスから設定を取得し、ＵＩからのユーザ入力をストレージサービスに保存し、その後、再起動コマンドをスウォームに送信する。

一実施形態によれば、必要なセキュリティ証明書は、ＩＤＣＳに保存されてもよく、ＩＤＣＳから取得されてもよい。

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

一実施形態によれば、ＢＣＳアプリケーションコンテナが起動されると、ＢＣＳアプリケーションは、設定の詳細を収集することによって、アプリケーション種類（ピア、チェーンコードコンテナまたは他のもの）を判断し、必要な設定をロードすることができる。

一実施形態によれば、このコンポーネントは、設定を更新し、ＢＣＳアプリケーション起動シェルコードを提供する。ＢＣＳによる設定ファイルの取得／更新動作は、いくつかのステップを含む。まず、ＢＣＳコンソールは、起動されると、ストレージから設定を取得し、更新を必要とする場合、設定（シェルおよびnode.js）をストレージに保存する。
ＢＣＳアプリケーションコンテナが起動されると、まず、（各ドッカコンテナ内の）起動スクリプトが起動し、その後、アプリケーションの種類に関する設定を取得し、ＩＤＣＳ（シェル）からアプリ証明書を取得する。ＢＣＳコンソールＵＩは、ＢＣＳアプリケーションを再起動する場合、コンテナ内のアプリケーションを再起動するためのメッセージをドッカ／スウォームに送信する。

一実施形態によれば、ＢＣＳコンソールは、ステートレスであり、起動されると、全てのＢＣＳインスタンス設定を収集し、ＢＣＳアプリケーションに接続すると共に、ＢＣＳアプリケーションを監視することができる。設定は、バックエンドＡＰＩを介してストレ
ージサービスから取得される。設定が変更されると、ＢＣＳコンソールは、バックエンドＡＰＩを呼び出すことによって、設定をストレージサービスに保存し、関連するアプリケーションを再起動する。クライアントがＢＣＳコンソールＵＩを介して設定項目を変更すると、ＵＩは、設定をキー／値データにエンコードし、バックエンドコードは、それをファイルに変換し、ストレージサービスに保存する。ＢＣＳコンソールは、ＢＣＳアプリケーションを監視、起動および停止することができる。起動コマンドおよび停止コマンドは、ドッカ／スウォームＡＰＩを用いて、この機能を実現する。

ファブリックネットワークの配置
一実施形態によれば、ファブリックネットワークは、以下のエンティティ、すなわち、ピア、クライアント、オーダリングサービス、およびこれらのエンティティ間の通信を容易にするためのプロトコルセットを含む。組織は、ファブリックネットワークの関係者を構成する論理エンティティまたは企業である。ファブリックネットワークは、複数の参加組織を有する。メンバは、ネットワークの固有のルート証明書を所有する法的に独立するエンティティである。ピアノードおよびアプリケーションクライアントなどのネットワークコンポーネントは、メンバにリンクされる。各組織は、１つ以上のメンバを有してもよい。１つの組織は、オーダおよびピアの両方を構成することができ、オーダのみまたはピアのみを構成することができる。

ファブリックネットワークを配置するための第１のステップは、参加者を定義することである。このステップは、ファブリックネットワークの帯域外で行われる。ファブリックネットワークの全ての参加組織は、ネットワークの構成、例えば、オーダノードを構成する組織またはピアノードを構成する組織を協議し、決定する。オーダノードを構成する各組織は、オーダサーバのルート証明書を公開する。ピアノードを構成する各組織は、ピアサーバのルート証明書を公開する。クライアントを含む各組織は、クライアントのルート証明書を公開する。クライアントは、１つの組織においてピアから異なるメンバに分けることができる。

一例として、４つのバンク（バンク１、バンク２、バンク３、およびバンク４）は、バンク１およびバンク２によって所有されているオーダノードを含むオーダリングサービスを用いて、ブロックチェーンネットワークを配置するとする。バンク１は、このネットワークのオーダのみを構成する。各バンクは、ファブリックネットワークの組織である。すなわち、バンク１は、１つのメンバ、オーダ（ルート証明書１）を有する。バンク２は、３つのメンバ、すなわち、クライアント（ルート証明書２１）、ピア（ルート証明書２２）、およびオーダ（ルート証明書２３）を有する。バンク３は、２つのメンバ、すなわち、クライアント（ルート証明書３１）およびピア（ルート証明書３２）を有する。バンク４は、２つのメンバ、すなわち、クライアント（ルート証明書４１）およびピア（ルート証明書４２）を有する。

参加者を定義した後、オーダおよびピアの証明書を作成する。各オーダまたはピアは、それ自体を識別するための（秘密キーおよび署名証明書）対を必要とする。各メンバは、ルート証明書を用いて、それ自体のファブリックＣＡサーバを構成および起動し、ＣＬＩまたはＳＤＫを用いて、ＣＡサーバに要求することによって、当該メンバの各オーダ／ピアサーバの（秘密キーおよび署名証明書）を作成することができる。ＢＣＳは、証明書を作成することができるファブリックＣＡサーバを提供する。しかしながら、ファブリックＣＡサーバは、証明書を作成するための唯一の手段ではない。ユーザは、他のＣＡシステムを用いて、証明書を作成することができる。したがって、ファブリックＣＡサーバは、ファブリックネットワークの必須コンポーネントではない。

オーダおよびピアの証明書を作成した後、システムチャネルを作成することによって、
ファブリックネットワークを起動する。オーダリングサービス（従って１つのファブリックネットワーク）のためにシステムチャネルが１つのみであるため、作成される（より正確には起動される）システムチャネルは、第１のチャネルである。システムチャネルは、ファブリックネットワークの以下の構成、すなわち、１つのオーダリングサービスと、１つ以上のコンソーシアムとを定義する。１つのオーダリングサービスは、１つ以上のオーダ組織（各組織は、ＭＳＰ ＩＤおよび証明書を含む）と、オーダリングサービスの属性（例えば、ソロまたはカフカなどの種類、オーダのアドレス、バッチサイズ／タイムアウト）と、（チャネルを作成するための）ポリシとを含む。各コンソーシアムは、１つ以上のピア組織を含み、このファブリックネットワークに参加することを望む各ピア組織は、コンソーシアムのうちの１つにおいて定義されなければならない。各組織は、ＭＳＰ ＩＤ、証明書およびアンカーピアを含む。

ファブリックネットワークのシステムチャネルが起動された後、システムチャネルのジェネシスブロック（チェーン内の第１のブロック）が作成される。オーダリングサービスの管理者は、システムチャネル用のジェネシスブロックを作成する。ジェネシスブロックは、設定ファイル生成（configtxgen）ツールによって（ファイルとして）作成されても
よく、またはオーダ起動時に（一時的に）作成されてもよい。設定ファイル生成ツールを用いてジェネシスブロックを作成する場合、入力としての設定ファイルconfigtx.yamlを
作成しなければならない。このファイルは、以下の情報、すなわち、ファブリックネットワーク内の全てのオーダ組織のルート証明書と、全てのピア組織のルート証明書と、オーダの種類、アドレス、バッチタイムアウト、バッチサイズおよびカフカを含むオーダリングサービスの属性と、ポリシと、チャネル配信要求を認証および検証するためのチャネルリーダと、チャネルブロードキャスト要求を認証および検証するチャネルライタと、チェーン作成要求を評価するためのチェーン作成者と、チャネル再構成要求を認証および検証するための管理者とを含む。

オーダリングサービスの管理者は、設定ファイルおよびジェネシスブロックを用いて、オーダサーバを起動する。換言すれば、ジェネシスブロックを用いて、システムチャネルを作成する。オーダサーバを起動するために、リッスンアドレス／ポート、元帳種類、ローカルＭＳＰ（秘密キー、署名証明書）を含む設定ファイルorderer.yamlが必要である。オーダリングサービスを提供する各組織は、（ジェネシスブロックを指定することなく）自身のオーダサーバを起動する。

ピアノードを構成する各組織は、ピアを識別するためのローカルＭＳＰ（秘密キー、署名証明書）、およびリッスンアドレス／ポート、ブートストラップピア、ゴシップ属性などのピア属性を特定するための各ピアの設定ファイル（default location/etc/hyperledger/fabric/core.yaml）を用意して、ピアサーバを起動する。

オーダおよびピアを起動した後、（チャネルを作成する権利を有する）チャネル管理者は、ファブリックＣＬＩまたはＳＤＫを用いて、次の入力、すなわち、（システムチャネルに既に定義された）１つのコンソーシアム、およびコンソーシアム内の１つ以上のピア組織を含むチャネルを作成するようにオーダに要求する。各参加組織は、ファブリックＣＬＩまたはＳＤＫを用いて、ピアの一部を新しく作成されたチャネルに参加させる。

実施例：ＢＣＳ上のファブリックネットワークの配置
図４は、ＢＣＳ上のファブリックの例示的な配置を示す。

より具体的には、図面および説明は、ＢＣＳ上でファブリックネットワークを配置するためのステップを説明する。この例において、４つのエンティティＡ、Ｂ、Ｃ、およびＤがファブリックネットワークを作成および参加することを望んでいる。４つのエンティテ
ィは、オフラインで議論し、様々なエンティティの責任を決定する。各エンティティは、ＯＰＣ上で１つ以上のＢＣＳインスタンスを作成する。

一実施形態によれば、エンティティＡは、オーダとピアの両方を提供する。エンティティＡは、２つのインスタンス、すなわち、オーダのオーダ＿組織１ ４０１と、ピアのピア＿組織１ ４２１とを作成する。エンティティＡは、ファブリックネットワークの作成にも関与する（なお、オーダのみは、ファブリックネットワークを作成することができる）。オーダリングサービス４００は、オーダ＿組織１ ４０１と、オーダ＿組織２ ４０２と、カフカクラスタ４１０とを含む。

一実施形態によれば、エンティティＢは、オーダとピアの両方を提供する。エンティティＢは、２つのインスタンス、すなわち、オーダのオーダ＿組織２ ４０２と、ピアのピア＿組織２ ４２２とを作成する。

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

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

一実施形態によれば、各ＢＣＳインスタンスの管理者は、ＢＣＳコンソールから、現在の組織のＣＡ証明書および管理者証明書を収集する。各ピア組織の管理者は、現在のピア組織のアンカーピアを特定し、アンカーピアのＩＰ／ポートを収集する。４つのエンティティは、オフラインで、収集された全ての情報を互いに交換する。

一実施形態によれば、オーダ＿組織１の管理者は、ＢＣＳコンソールから、前のステップで収集された情報、すなわち、各組織のＣＡ証明書および管理者証明書書、および各ピア組織のアンカーピアを用いてシステムチャネルを作成することによって、ファブリックネットワークを作成する。バックエンド作業は、ファブリックツールを呼び出すことによって、ジェネシスブロックを作成するステップと、ジェネシスブロックを用いてオーダを設定することによって、システムチャネルを作成するステップとを含む。

一実施形態によれば、各ピア組織の管理者は、ＢＣＳコンソールから、収集された他の組織のＣＡ／管理者証明書を追加するように全てのピアノードの設定を更新し、全てのピアノードを再起動することによって、ファブリックネットワークに参加する。

一実施形態によれば、新しい組織がシステム内の既存のファブリックネットワークに参加することを可能にする方法が提供される。また、ファブリックネットワークを作成／参加するため、例えばファブリックを形成する前のオフラインアクションを保護するために、参加者間の通信を容易にし且つユーザが取り扱い簡単な方法を提供することができる。

チェーンコード（スマートコントラクト）コンテナ
一実施形態によれば、上述したように、チェーンコードは、１つ以上の資産と、資産を変更するためのトランザクション命令（ビジネスロジック）とを定義するソフトウェアを含むことができる。チェーンコードは、キー値対または他の状態データベース情報を読み取るまたは変更するための規則を実行する。チェーンコードの機能は、元帳の現在の状態データベースに対して実行され、トランザクション提案によって作動される。チェーンコードの実行は、ネットワークに提出され、全てのピア上の元帳に適用される一組のキー値の書き込み（書き込みセット）をもたらす。

一実施形態によれば、情報の一貫した更新をサポートするためおよび特定の元帳機能（トランザクション、クエリなど）を可能にするために、ブロックチェーンネットワークは、スマートコントラクトを使用して、制御された元帳アクセスを提供する。スマートコントラクトは、情報をカプセル化し、ネットワーク全体にわたってその情報を簡単に複製することだけでなく、参加者がトランザクションの特定部分を自動的に実行できるように書かれてもよい。

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

一実施形態によれば、ハイパーレッジャファブリックは、ドッカエンジンを用いてチェーンコードを構築し、チェーンコードを配置し、チェーンコードを実行する。本節は、ファブリックのアーキテクチャ、およびＢＣＳのＡＣＣＳ階層化モデルに統合する方法を説明する。

一実施形態によれば、ファブリックは、以下のようにユーザチェーンコードを配置し、管理する。まず、一過性ＣＣ環境コンテナにおいてチェーンコードを構築する。次に、チェーンコードをソースコードとしてビルダコンテナに転送し、静的にリンクされた必要なライブラリ（「Ｊａｖａ（登録商標）ビルド」）でコンパイルし、バイナリとしてピアに返送する。静的なリンクは、実際のチェーンコードコンテナをできる限り小さくすることを可能にする。その後、チェーンコードイメージおよびコンテナを構築し、起動する。チェーンコードコンテナは、ピアが停止するまたはチャネルが終了するまで、動作し続ける。チェーンコードコンテナがクラッシュするまたは強制終了される場合、イメージが存在すれば、次の呼び出しで再起動される。この設計の場合、１つのピアおよびチャネルは、１つのチェーンコードドッカコンテナを有する。チェーンコードは、ピアに明示的にインストールされる。すなわち、チェーンコードは、必ずしも、チャネルに参加している全てのピアにインストールされなくてもよい。

一実施形態によれば、ユーザは、ピア、オーダ、およびチェーンコードなどのコンポーネントを容易に配信することができるファブリックネットワークをＡＣＣＳ階層コンテナに配置することができる。ローカルブロックストレージが信用できる回復方法ではなく、ＡＣＬＳコンテナのチェーンコードバイナリをクラウドストレージに保存する必要があるため、チェーンコードランタイム環境コンテナ（ｃｃｅｎｖ）は、動的に作動される。チェーンコードバイナリは、構築されると、コンテナクラッシュの場合に回復するためにクラウドストレージにアップロードされる。

一実施形態によれば、各チェーンコードの相互作用は、チェーンコードの様々な機能に対応する。唯一の制約は、チェーンコードをインスタンス化するまで、呼び出すまたはクエリすることができないことである。また、呼び出されると、動作していないチェーンコードコンテナは、再起動される。

図５は、一実施形態に従って、チェーンコードアーキテクチャを示す。より具体的には、図５は、一実施形態に従って、クライアント５３０が、ＡＣＣＳ環境５００において、チェーンコードをインストールし、トランザクションを実行することを可能にするチェーンコードアーキテクチャを示す。ステップ１において、クライアント５３０は、チェーンコードのソースコードをピア１ ５１０にインストールする。まず、一過性ＣＣ環境コンテナにおいてチェーンコードを構築する。クライアント５３０が「インストール」を実行
するときに、クライアント５３０は、ビルダエージェントを自動的に起動するビルダコンテナを起動し、ビルダコンテナが初期化を終了するのを待って、ピアを介してチェーンコードのソースコードをビルダコンテナに送信する（ステップ２）。ビルダエージェントは、チェーンコード（Ｊａｖａビルド）を構築する。チェーンコードをソースコードとしてビルダコンテナに転送し、静的にリンクされた必要なライブラリ（「Ｊａｖａビルド」）でコンパイルし、バイナリとしてピアに返送する。静的なリンクは、実際のチェーンコードコンテナをできる限り小さくすることを可能にする。チェーンコードパッケージ（ｔｇｚファイル）は、いったん構築されると、クラウドストレージ５６０にアップロードされる（ステップ３）。ビルダエージェントは、後で参照するために、クラウド記憶位置をピアに送信する（ステップ４．２）。

一実施形態によれば、ピア５１０は、次いで、ＰＳＭ ＲＥＳＴ ＡＰＩを用いて、ＣＣ環境をＡＣＬＳ（アクセス制御リスト）コンテナ５２０として起動する。チェーンコードイメージおよびコンテナを構築し、起動する。チェーンコードコンテナは、ピアが停止するまたはチャネルが終了するまで、動作し続ける。ピア５１０は、チェーンコードＩＤ、（チェーンコード登録用）セルフＩＰおよびクラウドストレージロケーションをＡＣＬＳコンテナに渡し開始する（ステップ４．１）。ピアは、チェーンコードの起動または設定期間の後のタイムアウトを待つ。ＣＣ環境は、チェーンコードを起動する。起動されると、チェーンコードは、それ自体をピアに登録する（ステップ４．３）。これによって、登録時に確立された接続を用いて、トランザクションにおいてチェーンコードを呼び出すことができる（ステップ５）。

一実施形態によれば、ビルダコンテナ５５０は、単純なＲＥＳＴ型サーバを含む。ビルダコンテナ５５０は、ビルダエージェント５５３を含む。ビルダコンテナ５５０は、起動されると、チェーンコードを構築するための要求をリッスンする。ビルダコンテナ５５０が構築リスト、例えば、ベース６４で符号化したソースコードをボディとするＰＯＳＴ呼び出しを受信すると、ベース６４は、ソースコードを復号し、チェーンコードソースコードをローカルファイルシステムに保存する。ビルダエージェント５５３は、ソースコードに対して「Ｊａｖａビルド」を行う。「Ｊａｖａビルド」が成功した場合、ビルダエージェント５５３は、バイナリをパッケージ化し、クラウドストレージ５６０にアップロードする。また、ビルダエージェントは、チェーンコード位置をピアに送信する。「Ｊａｖａビルド」が失敗した場合、エージェントは、エラーおよび理由をピアに送信する。

ＢＣＳ管理コンソール
上述したように、ＢＣＳの各インスタンスは、管理コンソールを含み、管理コンソールを用いて、ＢＣＳゲートウェイ、ＢＣＳノード、およびＢＣＳチャネルを含むＢＣＳインスタンスを管理および監視することができる。

一実施形態によれば、管理コンソールを提供するためのシステムは、スクリプトランタイム環境、例えばNode.jsに動作するウェブアプリケーションを含むことができる。ウェ
ブアプリケーションは、グラフィカルユーザインターフェイスフレームワークおよびウェブフレームワーク上で構築することができ、ＢＣＳインスタンス内の様々なノードまたはサービスと通信するための複数のカスタム機能またはＡＰＩを含むことができる。ウェブアプリケーションは、ＢＣＳインスタンス内の様々なノードまたはサービスからの情報をビューオブジェクトに読み込み、コンソールユーザインターフェイスに表示することができる。また、管理コンソールは、ＢＣＳインスタンス内の１つ以上のノードを起動、停止、および更新するための機能を管理者に提供することができる。管理ＲＥＳＴ ＡＰＩセットは、ウェブアプリケーションによって提供された機能と同様の機能をサポートするために、スクリプトランタイム環境によって提供されてもよく、またはスクリプトランタイム環境によってアクセスされてもよい。

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

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

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

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

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

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

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

一実施形態によれば、図７Ａに示すように、ＢＣＳ概要７１１をダッシュボード内に表示することができる。概要は、組織の数、ピアの数、オーダの数、チャネルの数、およびチェーンコードの数を含むことができる。

一実施形態によれば、ＢＣＳインスタンスの健康情報７１３を表示することができる。健康情報は、視覚的に示され、数字で表示される。例示のＵＩは、トランザクションの実行７１４および元帳の概要７１５を表示することもできる。

一実施形態によれば、図７Ｂは、ＢＣＳインスタンス内の全てのノードの情報を示す。例えば、例示のＵＩは、２つのピア、１つのオーダ、１つのファブリックＣＡ、および（ＢＣＳゲートウェイノード内の）１つのＲＥＳＴプロキシを含む合計５つのノードを示す。概要ＵＩ７１７は、ノードの名前７２３、ノード７２５の経路情報、ノード７２９の種別、ノード７３１の状態情報を表示する。例示のＵＩは、管理者がノードを追加するためのボタン７２１と、ノードを選別するための１つ以上のドロップダウンリスト７１９とを含む。

ノードの管理
一実施形態によれば、２つのエンティティ、すなわち、ＢＣＳ管理者およびＢＣＳユーザは、管理コンソールを用いて、ＢＣＳインスタンスを管理することができる。各ＢＣＳインスタンスに対してＢＣＳ管理者アカウントが１つのみである。ＢＣＳ管理者アカウントは、ＢＣＳインスタンスを作成するときに作成されてもよい。ＢＣＳ管理者は、ファブリックＣＡ管理者にバンドルされてもよい（すなわち、ＢＣＳ管理者は、ファブリックＣＡ管理者ＩＤを使用して、ＢＣＳコンソールからまたはＢＣＳ管理ＲＥＳＴ ＡＰＩを介して、全ての動作を実行する）。ＢＣＳユーザアカウントが２つ以上であってもよい。ＢＣＳユーザアカウントは、ＢＣＳ管理者によって、ファブリックＣＡアイデンティティを登録することによって作成されてもよい。

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

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

一実施形態によれば、ＢＣＳ管理者は、ノードを追加するときに、ノードの属性を設定することができる。新たに追加されたノードは、追加動作の一部として自動的に起動することができる。ノードを削除する場合、当該ノードは、停止され、ＢＣＳインスタンスから削除される。

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

一実施形態によれば、ＢＣＳ管理者は、ピアノードを管理するときに、アクティブなピアノードを既存のチャネルに加え、アクティブなオーダノードの属性を閲覧および編集することができる。ＢＣＳユーザは、アクティブなピアノードの一部の属性を閲覧することができる。

また、アクティブなピアノードの性能メトリック、例えば、メモリの使用率、ＣＰＵの使用率、ネットワークＩ／Ｏ、およびディスクＩ／Ｏのスナップショットは、ＢＣＳコンソールＵＩに表示されてもよい。

一実施形態によれば、ＢＣＳ管理者は、オーダノードを管理するときに、アクティブなオーダノードのログを閲覧することができ、アクティブなオーダノードの属性を閲覧および編集することができる。ＢＣＳユーザは、アクティブなオーダノードの一部の属性を閲覧することができる。ピアノードの管理と同様に、ＢＣＳ管理者は、アクティブなオーダノードの性能メトリック、例えば、メモリの使用率、ＣＰＵの使用率、ネットワークＩ／Ｏ、およびディスクＩ／Ｏのスナップショットを閲覧することができる。

一実施形態によれば、ＢＣＳ管理者は、ファブリックＣＡノードを管理するときに、アクティブなファブリックＣＡノードの属性を閲覧および編集し、アクティブなファブリックＣＡノードからＣＡ証明書を取得し、アクティブなファブリックＣＡノードのログを閲覧することができる。また、ＢＣＳ管理者は、アクティブファブリックノードのの性能メトリック、例えば、メモリの使用率、ＣＰＵの使用率、ネットワークＩ／Ｏ、およびディスクＩ／Ｏのスナップショットを閲覧することができる。

上述したように、ＢＣＳゲートウェイノードの管理は、ＢＣＳゲートウェイノードを追加すること、またはＢＣＳゲートウェイノードを削除することをさらに含むことができるＢＣＳゲートウェイノードの最大許可数が特定のＢＣＳインスタンスをインスタンス化するときに指定されるため、ＢＣＳインスタンスに追加され得るＢＣＳゲートウェイノードの数は、設定されたＢＣＳゲートウェイノードの最大許可数によって制限される。

一実施形態によれば、各ＢＣＳゲートウェイノードは、ゲートウェイノードの全体に一意の識別である名前を有することができる。この名前は、ＢＣＳゲートウェイノードを構成するときに参照される。また、ＢＣＳゲートウェイノードを作成するときに、ネットワークアドレスを決定および表示することができる。

一実施形態によれば、ＢＣＳ管理者は、ＢＣＳゲートウェイノードを構成するときに、ＢＣＳゲートウェイ設定ファイルを定義し、ＢＣＳゲートウェイノードを起動することができる。ＢＣＳインスタンスを作成するときに、チャネルの作成またはチェーンコードの配置をしなくてもよい。したがって、ＢＣＳゲートウェイノードは、管理コンソールを介して１つ以上のチェーンコードを配置し且つ有効なＢＣＳゲートウェイ設定を定義するまで、機能しない。

各ＢＣＳゲートウェイノードは、設定ページを有する。特定の実施形態において、設定ページにおいて、以下の項目を設定することができる。
１）チャネル：現在のゲートウェイノードを介して公開するチャネルを選択する。
２）チェーンコード：各チャネルにインスタンス化された全てのチェーンコードのリストから、公開するインスタンス化チェーンコードを選択する。
３）エンドーサ：各チェーンコードのエンドーサピアを定義する。
４）上記の設定に従ってＢＣＳゲートウェイ設定を作成する。ＢＣＳゲートウェイの有効な設定ファイルが作成されると、ゲートウェイを起動することができる。

一実施形態によれば、ＢＣＳコンソールは、リスト閲覧機能を用いて、ＢＣＳゲートウェイプロパティの閲覧を可能にする。リスト閲覧は、各ＢＣＳゲートウェイの以下の情報を提供する。
１）名前：ゲートウェイを作成する時に指定されたグローバル固有名。
２）ファブリック識別名：各ＢＣＳゲートウェイは、ＢＣＳゲートウェイを作成するとき
に登録されるファブリッククライアントの識別情報に関連付けることができる。このファブリッククライアントは、ＢＣＳゲートウェイによって実行される全ての動作（例えば、呼び出し、クエリ）を実行することができる。
３）ネットワークアドレス：アクセスポイントは、公衆インターネットワークアドレスを有する。
４）状態：作動中または停止中。

一実施形態によれば、ＢＣＳ管理者は、管理コンソールを介して、アクティブなＢＣＳゲートウェイノードのログを閲覧し、以下のＢＣＳゲートウェイメトリックを閲覧することができる。
１）接続されているクライアント：クライアント名、アドレス、ログオン時間など。
２）現在のトランザクション情報：現在のトランザクション情報は、状態情報、すなわち、トランザクションの状態と共に利用可能である。現在のトランザクション情報は、フリーズしたトランザクションをデバッグするときに有用である。
３）トランザクション統計：トランザクション統計は、管理コンソールＵＩを介して利用可能である。例えば、トランザクション統計は、完了したトランザクションの数、受信したイベント通知の数、および送信したイベント通知の数を含むことができる。
４）メモリの使用率。
５）ＣＰＵの使用率。
６）ネットワークＩ／Ｏ。
７）ディスクＩ／Ｏ。

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

一実施形態によれば、ＢＣＳユーザは、チャネルに参加しているノードおよび組織を閲覧することができる。管理コンソールは、リストモードおよびトポロジモードを含むトウビューモードをサポートすることができる。リストモードにおいて、参加しているローカルノードおよび（アンカーピアによって示された）外部組織は、リストとして示されてもよい。トポロジモードにおいて、参加しているローカルノードおよび（アンカーピアによって示された）外部組織は、トポロジ図として示されてもよい。

一実施形態によれば、ＢＣＳ管理者は、チャネル内のピアの元帳にクエリすることができる。元帳は、複数のトランザクションブロックを含むことができる。各トランザクションブロックは、ブロックＩＤ、過去のハッシュ、データハッシュ、タイムスタンプ、トランザクションＩＤリスト、動作（１～ｎ）、チェーンコードＩＤ、チェーンコード提案、応答（ｒ／ｗセット、イベント、成功または失敗）、および１つ以上のエンドーサを含むことができる。また、以下の統計データ、すなわち、ブロックの数および呼び出しの数を表示することもできる。

一実施形態によれば、ＢＣＳ管理者は、チャネルにインスタンス化された全てのチェーンコードをリストすることができる。リストされた項目は、チェーンコードＩＤおよびバージョンを含むことができる。ＢＣＳ管理者は、インスタンス化されたチェーンコードの以下の情報、すなわち、インスタンス化されたトランザクションによって特定されたパス、およびインスタンス引数を閲覧することもできる。

一実施形態によれば、ＢＣＳ管理者は、チャネルにインスタンス化されたチェーンコー
ドを更新することができる。更新動作は、以下の入力、すなわち、新しいバージョンのインストール済みチェーンコードを含むターゲットエンドーサピア、１つ以上のオーダ、チェーンコードバージョン、およびチェーンコードに固有の文字列引数であり得る選択的な引数を使用することができる。更新動作の出力は、成功であってもよく、またはエラーメッセージを含む失敗であってもよい。

チェーンコードの管理
一実施形態によれば、ＢＣＳ管理者は、現在のＢＣＳインスタンスの任意のピアにインストールされた全てのチェーンコードをリストすることができる。リストされた項目は、チェーンコードＩＤおよびバージョンを含む。また、ＢＣＳ管理者は、インストール済みチェーンコードの以下の情報、すなわち、チェーンコードをインストールしたローカルピアノード、およびチェーンコードをインスタンス化したチャネルを閲覧することができる。

一実施形態によれば、ＢＣＳ管理者は、管理コンソールを介して、チェーンコードを１つ以上のローカルピアノードにインストールすることができる。インストールするための入力は、ターゲットピア、例えばＧｏ言語／Ｊａｖａなどのチェーンコード種類、チェーンコードの名前であり得るチェーンコードＩＤ、チェーンコードバージョン、チェーンコードのソースコードの位置であり得るチェーンコード経路、任意選択のチェーンコードパッケージを含むことができる。インストール操作の出力は、成功であってもよく、またはエラーメッセージを含む失敗であってもよい。

一実施形態によれば、ＢＣＳ管理者は、以下の情報、すなわち、チャネル名、新しいバージョンのインストール済みチェーンコードを含むターゲットエンドーサピア、オーダ、チェーンコードバージョン、およびチェーンコードに固有の文字列引数であり得る選択的な引数、特定のフォーマット、または特定のフォーマットがない場合にデフォルトフォーマットを有するエンドースメントポリシを入力として、インストール済みチェーンコードをチャネルにインスタンス化することができる。

メンバシップの管理
一実施形態によれば、ＢＣＳ管理者は、現在のＢＣＳインスタンス内の全てのＩＤをリストすることができ、現在のＢＣＳインスタンスに新しいユーザ／ＩＤを登録することができ、登録したＩＤを解除することができ、現在のＢＣＳインスタンスからユーザを削除することができる。また、ＢＣＳ管理者は、表１に示すように、識別情報の以下の属性を閲覧／編集することができる。

一実施形態によれば、ＢＣＳユーザは、管理コンソールを介して、それ自体を登録する
または再登録することを可能にする。これによって、ユーザの秘密キーおよび証明書を作成することができる。また、ＢＣＳ管理者は、管理コンソールを介して、以前に登録されていたＩＤを無効化することができ、ＢＣＳユーザは、管理コンソールを介して、パスワードを変更することができる。

一実施形態によれば、関連するＢＣＳインスタンスを起動または停止すると共に、ＢＣＳ管理コンソールを起動または停止することができる。

一実施形態によれば、２つの方法でＢＣＳ管理コンソールのログレベルを設定することができる。すなわち、ＢＣＳ管理コンソールまたは管理ＲＥＳＴ ＡＰＩを用いて、実行時にログレベルを変更することができる。

ＲＥＳＴ ＡＰＩ
上述したように、ファブリックネットワーク内の異なるコンポーネントは、ｇＲＰＣプロトコルに基づいて通信する。したがって、ファブリックネットワークに基づくＢＣＳインスタンスの場合、クライアントアプリケーションは、ファブリックＳＤＫを用いて、ＢＣＳインスタンス内のチェーンコードを呼び出す必要がある。

クライアントアプリケーションがファブリックＳＤＫを用いてブロックチェーンクラウドサービスと通信することは、ブロックチェーンフレームワークをクラウドサービスとして提供することによる利点を部分的に打ち消すことになる。例えば、利点の１つは、インターネット接続を用いて、任意の場所からクラウドサービスにアクセスできることである。

一実施形態によれば、本明細書に記載のシステムおよび方法は、ＢＣＳインスタンスにおいてＲＥＳＴプロキシを提供することができる。ＲＥＳＴプロキシは、ＲＥＳＴクライアントによって使用され、チェーンコードを介してクエリし、チェーンコードを介してトランザクションを同期的または非同期的に呼び出し、トランザクションステータスを取得し、ＢＣＳプロキシのバージョンを取得するための複数のＲＥＳＴ ＡＰＩを提供することができる。ＲＥＳＴプロキシは、ＲＥＳＴコールを認証し、ＲＥＳＴコールをＧＲＰＣコールに変換することができる。また、ＲＥＳＴプロキシは、ＢＣＳ管理コンソールによって提供された機能と同様の機能をサポートするＲＥＳＴ ＡＰＩを提供することができる。

一実施形態によれば、ＲＥＳＴプロキシは、クライアントアプリケーションがＢＣＳインスタンスを消費するためのユーザインターフェイスを提供する。

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

図８に示すように、ＲＥＳＴプロキシ１３８は、ＲＥＳＴ認証ツール８２７およびプロトコル変換ツール８２９を含むことができる。ＢＣＳ ＲＥＳＴ ＡＰＩクライアント８０８がＲＥＳＴコール８１５をＲＥＳＴプロキシに送信すると、クラウドゲート８１１に接続されているＬＢａａＳ１２６は、ＲＥＳＴコールを認証することによって、ＲＥＳＴがＢＣＳインスタンスにアクセスすることを可能にする有効なユーザ名および有効なパスワードがＲＥＳＴコールに含まれているか否かを判断することができる。

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

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

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

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

例示的なＲＥＳＴ ＡＰＩ
一実施形態によれば、ＢＣＳインスタンスのＲＥＳＴ ＡＰＩを呼び出す前に、ＲＥＳＴプロキシを起動して、動作させる必要がある。管理コンソールを介して、ＲＥＳＴプロキシの状態をチェックすることができる。ＲＥＳＴプロキシが立ち上げられておらず、動作していない場合、管理コンソールからＲＥＳＴプロキシを作動する必要がある。

一実施形態によれば、ＲＥＳＴ ＡＰＩを呼び出すことによって、ＢＣＳインスタンス内のピアノードに配置されたスマートコントラクト（チェーンコード）と対話することができる。配置プロセスは、管理コンソールを介して達成することができる。

一実施形態によれば、例示の目的で、例示的なＲＥＳＴ ＡＰＩが提供される。本明細書に使用された例は、以下の例示的なチェーンコードがＢＣＳネットワークに配置されると仮定する。

一実施形態によれば、例示は、管理コンソールを含む。ＲＥＳＴプロキシが立ち上げられておらず、動作していない場合、管理コンソールからＲＥＳＴプロキシを作動することができる。

一実施形態によれば、ＲＥＳＴ ＡＰＩを呼び出すことによって、ＢＣＳインスタンス内のピアノードに配置されたスマートコントラクト（チェーンコード）と対話することができる。配置プロセスは、管理コンソールを介して達成することができる。

一実施形態によれば、例示の目的で、例示的なＲＥＳＴ ＡＰＩが提供される。本明細書に使用された例は、以下の例示的なチェーンコードがＢＣＳネットワークに配置されると仮定する。

一実施形態によれば、ＲＥＳＴ ＡＰＩは、以下の機能、すなわち、チェーンコードを介したクエリ、チェーンコードを介したトランザクションの呼び出し、チェーンコードを介したトランザクションの非同期呼び出し、トランザクションステータスの取得、ＢＣＳゲートウェイバージョンの取得を提供する。これらの機能を実行するために、クライアントは、ＨＴＴＰＳを用いてＢＣＳゲートウェイにアクセスし、ＡＰＩに従ってメッセージフォーマットを利用する。

一実施形態によれば、チェーンコードを介したクエリ機能は、チェーンコードを呼び出すことによってクエリ動作を実行する。チェーンコードおよびクエリの引数は、ＲＥＳＴ
ＡＰＩを介して指定される。トランザクションステータスの取得というＲＥＳＴ ＡＰＩは、チャネルにクエリすることによって、トランザクションのステータスを取得する。チャネルおよびトランザクションＩＤは、ＲＥＳＴ ＡＰＩを介して指定される。ＢＣＳゲートウェイバージョンの取得というＲＥＳＴ ＡＰＩは、ゲートウェイバージョン情報を返信する。

一実施形態によれば、チェーンコードを介したトランザクションの呼び出しというＲＥＳＴ ＡＰＩは、チェーンコードを呼び出すことによってトランザクションを実行する。チェーンコードおよび呼び出しの引数は、ＲＥＳＴ ＡＰＩを介して指定される。このＲＥＳＴ ＡＰＩは、同期モードでトランザクションを実行する。これは、トランザクションが成功である応答、トランザクションが失敗である応答、またはトランザクションがタイムアウトである応答のうち、いずれかを返信することを意味する。

一実施形態によれば、チェーンコードを介したトランザクションの非同期呼び出しというＲＥＳＴ ＡＰＩは、チェーンコードを呼び出すことによってトランザクションを実行する。チェーンコードおよび呼び出しの引数は、ＲＥＳＴ ＡＰＩを介して指定される。このＲＥＳＴ ＡＰＩは、非同期モードでトランザクションを実行する。これは、トランザクションの終了またはタイムアウトを待つことなく、トランザクションを投入した直後に、応答／承認を返信することを意味する。結果は、その後に提供される。ＢＣＳインスタンス管理ＲＥＳＴ ＡＰＩは、ＢＣＳコンソール（後述）によって提供された機能と同様の機能をサポートする。

アイデンティティクラウドサービス（ＩＤＣＳ）と一体化されたファブリック認証局（ファブリックＣＡ）
一実施形態によれば、ファブリックＣＡサーバは、ファブリックメンバシップサービスを提供する。ファブリックメンバシップサービスは、以下の３つの部分、すなわち、ユーザの認証、ブロックチェーン（ピアおよびオーダのグループ）にアクセスするための許可、および証明書をアプリケーションクライアント、ピアおよびオーダに配信するためのＣＡサーバを含む。ファブリックＣＡは、証明書を使用して、認証および認可を実施する。証明書は、以下の２種類、すなわち、認証を行うための登録証明および認可を行うためのトランザクション証明を含む。また、ＩＤＣＳも認証および認可を提供する。しかしながら、この認可は、ＯＡｕｔｈによって実施される。すなわち、ピアは、オーダにアクセスしたい場合、ＩＤＣＳからユーザのアクセストークンを取得し、このトークンを用いてオーダにアクセスする。

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

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

一実施形態によれば、ＢＣＳは、ＯＰＣのユーザ管理を利用する。まず、ＢＣＳユーザは、（ＩＤＣＳ ＩＤを有する）ＯＰＣユーザでなければならない。ＢＣＳインスタンスが作成されると、ＢＣＳコンソール、ＣＡおよびＲＥＳＴプロキシを含む数種類のアプリケーションが作成される。コンソールは、以下の２つのアプリ役割、すなわち、コンソール管理者およびコンソールユーザを有する。ＣＡは、４つのアプリ役割、すなわち、ファブリック管理者、ファブリッククライアント、ファブリックピア、およびファブリックオーダを有する。ＲＥＳＴプロキシは、２つのアプリ役割、すなわち、ゲートウェイ管理者およびゲートウェイユーザを有する。

一実施形態によれば、ＯＰＣユーザをＢＣＳユーザにするために、ＯＰＣユーザ管理コンソールにおいて特定のＢＣＳアプリ役割をＯＰＣユーザに付与する必要がある。

作成者は、ＢＣＳインスタンスを作成するときに、既存のＯＰＣユーザ／パスワードを提供する必要があり、このユーザには、ＢＣＳコンソール管理役割およびファブリック管理役割が自動的に付与される。したがって、このユーザは、ＢＣＳ管理者となる。

ＢＣＳコンソール／ＣＡ／ＲＥＳＴプロキシの認証の場合、認証は、クラウドゲートで行われる。ピア／オーダの場合、認証は、署名に基づいて行われる。ＢＣＳコンソールの場合、認証後、コンソールは、（ＩＤＣＳを呼び出すことによって）現在のユーザのアプリ役割を取得する。このユーザにはコンソール管理者またはコンソールユーザの役割が付与されていない場合、接続は、拒否される。そうでなければ、コンソールは、予め定義された規則に基づいてアクセス制御を行う。例えば、通常のユーザは、情報の読み取りのみを行うことができ、管理者は、何でも行うことができる。

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

一実施形態によれば、ＲＥＳＴプロキシの場合、認証後、ＲＥＳＴプロキシは、現在のユーザのアプリ役割を取得する。ユーザにはゲートウェイ管理者またはゲートウェイユーザ役割が付与されていない場合、要求は、拒否される。そうでなければ、コンソールは、予め定義された規則に基づいてアクセス制御を行う。例えば、通常のユーザは、呼び出し／クエリを行うことができ、管理者は、設定を変更し、メトリックを取得することができ
る。

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

一実施形態によれば、フファブリックＣＡは、証明書を使用して、認証および認可を実施する。証明書は、以下の２種類、すなわち、認証を行うための登録証明および認可を行うためのトランザクション証明を含む。

一実施形態によれば、また、ＩＤＣＳも認証および認可を提供する。しかしながら、この認可は、ＯＡｕｔｈによって実施される。すなわち、ピアは、オーダにアクセスしたい場合、ＩＤＣＳからユーザのアクセストークンを取得し、このトークンを用いてオーダにアクセスする。

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

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

次いで、ＩＤＣＳは、要求を認証し、認証が成功する場合、トークンをウェブブラウザに返信することができる。認証され、トークンを受信したウェブブラウザは、ウェブアプリケーションに要求を送信することができる。ウェブアプリケーションは、トークンを検証し、認証が成功したことをウェブブラウザに知らせることができる。

図９Ａに示すケースの場合、ＩＤＣＳは、アプリケーションを識別するためのサービスを提供するＩＤプロバイダ（ＩｄＰ）として機能する。全ての参加者間の全ての通信は、ＨＴＴＰに基づいて行われる。この使用ケースは、設定駆動型であるが、ＨＴＴＰベースのアプリケーションのみに応用される。

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

一実施形態によれば、既に登録され登記されている（ユーザの秘密キーおよび証明書が既にクライアント側のステートストアに格納されている）ファブリックユーザに関連するファブリッククライアント９０４は、新しいクライアントを要求することができ、クライアントのユーザ情報（ユーザ名）を取得することができる。ファブリックＳＤＫ９０５は、ステートストアからユーザをロードし、ファブリッククライアントにユーザオブジェクトを返信することができる。クライアントは、ユーザオブジェクトを受信すると、ファブリックＳＤＫにトランザクション提案を送信することができ、ファブリックＳＤＫは、同様の秘密キーを用いて提案に署名することができる。次いで、署名済み提案は、ピア９０６に送信され、ピア９０６は、メンバシップサービス９０７を用いて署名を検証すること
ができる。メンバシップサービスは、ＩＤＣＳ９０２からユーザの証明書を取得することができ、ＩＤＣＳからの証明書を用いてユーザの署名を検証することができる。次いで、メンバシップサービスは、署名が検証済みという証明をピアに返信することができる。

分散型元帳におけるＤＡＧベースのトランザクション処理
一実施形態によれば、分散型元帳におけるＤＡＧベースのトランザクション処理システムおよび方法を導入することができる。このモデルは、スループット性能を改善することができる。追加の重みメカニズムを用いて、様々なビジネス要件に基づいて最終性能を調節することができる。線形構造を使用した既存の作業とは異なり、より良好な性能を達成することができる。

従来では、ブロックチェーンは、線形記録構造を用いてトランザクション履歴を記録することによって、分散型元帳問題を解決するための潜在的な解決策を提供する。しかしながら、分散システムの基本的な特性によって、多くの場合、複数の当事者が複数のトランザクションを同一の共有元帳に送信する場合、トランザクション競合がしばしば発生する。競合を緩和するための方法は、いくつかがあるが、いずれの方法は、良好な性能を提供するものではない。

典型的な公衆ブロックチェーン、例えば、暗号通貨に関連する公衆ブロックチェーンは、維持すべきトランザクションまたは拒絶すべきトランザクションをマイナーに決定させる。（例えば、いくつかのブロックチェーンが、他のトランザクションよりも特定のトランザクションを優先するようにマイナーに支払うことを可能にするため）これらのマイナーは、事実上インセンティブモデルを選択する。この場合、マイナーおよびブロックチェーンコンセンサスの他のメンバは、常により多くの報酬を有するトランザクションを好む。これは、ブロックチェーンの遅い性能につながる。

他のエンタープライズブロックチェーンファブリックは、各ピアが単にオーダリングサービスからの一連のトランザクションの時間順序に基づいてトランザクションを提出するタイミングモデルを選択する。この場合、時間順序およびトランザクション間の競合によって、多くのトランザクションが拒否される可能性がある。

一実施形態によれば、本開示のシステムおよび方法は、ＤＡＧ構造を導入することによって、新しいトランザクション処理モデルを提供する。新しいモデルは、高いスループット性能を達成することができる。追加の重みメカニズムを用いて、様々なビジネス要件に基づいて最終性能を調節することができる。線形構造を使用した既存の作業とは異なり、より良好な性能を達成することができる。

図１０は、一実施形態に従って、分散型元帳におけるＤＡＧベースのトランザクション処理方法およびシステムの提供をサポートするためのシステム示す。

一実施形態によれば、分散元帳におけるＤＡＧベースのトランザクション処理システムおよび方法の設計は、競合検出器（detector）１００５と、ランキングジェネレータ（generator）１０１０と、トランザクションピッカー（picker）１０１５とを含むことがで
きる。

一実施形態によれば、競合検出器は、複数のトランザクション、例えば、トランザクションリスト１００１からの複数のトランザクション間の競合関係を検出することができる。

一実施形態によれば、一般的に、トランザクション＃１が、トランザクション＃２にお
いて変更される何らかのキーに依存する場合、トランザクション＃１および＃２は、競合していると見なされる。トランザクション＃１と＃２の間に辺（edge）を描画することができる。一連のトランザクションに対していくつかのＤＡＧを描画することができる。

一実施形態によれば、各トランザクションは、ＤＡＧにおいて、グラフの最下層として標記された１辺および頂点を有する。

一実施形態によれば、競合条件を拡張することができる。例えば、２つのトランザクションは、同様のテーブルを変更することができ、または２つのトランザクションの作成者は、同一の部門に所属することができる。

一実施形態によれば、競合検出後、関係は、いくつかのＤＡＧとして示される。各トランザクションは、競合グラフ１００２の頂点である。

一実施形態によれば、本システムおよび方法のランキングジェネレータは、生成されたグラフ１００２の各頂点に重みを追加することができる。全てのトランザクションが同様の重みを有する場合、各頂点の初期ランキングを同様の値、例えば「１」に設定することができる。

一実施形態によれば、複数のトランザクションの重みは、システムおよび方法によって自動的に設定されてもよく、またはユーザ／管理者入力を介して設定されてもよい。トランザクションは、自身の重みの表示を含んでもよい。

一実施形態によれば、各トランザクションの初期ランキング／重み１００３を設定した後、システムおよび方法は、頂点に従ってランキングを計算することができる。

一実施形態によれば、トランザクション＃１が初期値ｘを有し、頂点が別のトランザクション＃２に向ける場合、トランザクション＃１は、トランザクション＃２のランキング／重みに「－ｘ」を寄与する。

一実施形態によれば、このプロセスと共に、ＤＡＧ内の各頂点は、ランキング値を有し、このランキング値は、初期ランキングおよび隣接するトランザクションからの寄与ランキングを用いて計算される。

一実施形態によれば、システムおよび方法は、トランザクションピッカーを用いて、ランキング付きＤＡＧのランキングに基づいて、トランザクションを選択することができる。

一実施形態によれば、選択プロセスは、以下の通りである。まず、最下層の頂点から出発して、以下の原則、すなわち、トランザクション＃ｘを選択する場合、全ての隣接するトランザクション（すなわち、トランザクション＃ｘと競合しているトランザクション）を選択しないという原則に従って、最も高いランキングを有するトランザクションを選択する。

一実施形態によれば、最後に、安全にコミットすることができるトランザクションのサブセットを選択することができる。この方法は、一連のトランザクションの最も高い合計重みを達成することができる。選択されたトランザクションは、結果１００４として出力される。

図１１は、一実施形態に従って、本開示の一実施形態に使用され得る例示的な関係グラ
フを示す。

一実施形態によれば、例えば、元帳システムが、１１０１～１１０８と命名された８つの有序トランザクション＃１～＃８を含む一連のトランザクションを受信すると仮定する。この実施形態において、競合検出器によって判定された各トランザクションの競合関係は、１つのグラフにまとめることができる。

競合検出後、競合関係は、以下の通りである。
・Ｃ（＃１，＃２，＃３）＝＃６
・Ｃ（＃４，＃５）＝＃７
・Ｃ（＃６，＃７）＝＃８
一実施形態によれば、上記の競合関係は、トランザクション＃６がトランザクション＃１、＃２および＃３と競合しているとして理解することができる。同様に、トランザクション＃７は、トランザクション＃４および＃５と競合しており、トランザクション＃８は、トランザクション＃６および＃７と競合している。

一実施形態によれば、この例に引き続き、各トランザクションの重みは、例えば「１」に等しい。これに基づいて、ランキングジェネレータは、図１１に示す関係グラフを生成して、トランザクションピッカーに提供する。トランザクションピッカーは、コミット対象のトランザクションを選択する。

図１１に示すように、トランザクション＃１、＃２、＃３、＃４および＃５は、いずれも「１」という重みおよびトランザクションランキングを有する。各トランザクションのトランザクションランキングを決定するために、上述した方法を用いて、競合しているトランザクションの重みからこれらの重みを減算する。したがって、トランザクション＃６の重みからトランザクション＃１、＃２および＃３の重みを減算すること（すなわち、１－３＝－２）によってトランザクション＃６のトランザクションランキングを計算すると、トランザクション＃６は、トランザクションランキング「－２」を有する。同様の手順を実行して、トランザクション＃７の合計トランザクション重みを決定する。トランザクション＃７のトランザクション重みからトランザクション＃４および＃５のトランザクション重みを減算すること（すなわち、１－２＝－１）によって、トランザクション＃７は、トランザクションランキング「－１」を有する。同様に、トランザクション＃８に対して、この手順を繰り返す。トランザクション＃８のトランザクション重みからトランザクション＃６および＃７の負の重みを減算することによって、トランザクション＃８は、合計トランザクションランキング「４」を有する。

一実施形態によれば、競合グラフを計算した後、ランキングジェネレータが重み付きトランザクション競合に従って各トランザクションをランキングした後、トランザクションピッカーは、コミット対象のトランザクションを決定することができる。この例の場合、（最も高いランキングを有する）トランザクション＃８とトランザクション＃１～＃５とは、正の値を有し且つ互いに競合しないため、コミット対象に選択される。トランザクション＃６および＃７は、トランザクションランキングが低く且つ両方のトランザクションがトランザクション＃８と競合しているため、コミット対象に選択されない。このような選択は、図に示される。図示では、コミット対象に選択されたトランザクションは、太い輪郭を有し、コミット対象に選択されないトランザクションは、破線で示されている。

図１２は、一実施形態に従って、本開示の一実施形態に使用され得る例示的な関係グラフを示す。

一実施形態によれば、図１２は、図１１に示された状況よりも複雑な第２の状況を示す
。

一実施形態によれば、例えば、ブロックチェーンシステムが、１２０１～１２０８と命名された８つの有序トランザクション＃１～＃８を含む一連のトランザクションを受信すると仮定する。この実施形態において、競合検出器によって判定された各トランザクションの競合関係は、１つのグラフにまとめることができる。

競合検出後、競合関係は、以下の通りである。
・Ｃ（＃１，＃２，＃３）＝＃６
・Ｃ（＃４，＃５）＝＃７
・Ｃ（＃３，＃６，＃７）＝＃８
一実施形態によれば、上記の競合関係は、トランザクション＃６がトランザクション＃１、＃２および＃３と競合しているとして理解することができる。同様に、トランザクション＃７は、トランザクション＃４および＃５と競合しており、トランザクション＃８は、トランザクション＃３、＃６および＃７と競合している。

一実施形態によれば、この例に引き続き、各トランザクションの重みは、例えば「１」に等しい。これに基づいて、ランキングジェネレータは、図１２に示す関係グラフを生成して、トランザクションピッカーに提供する。トランザクションピッカーは、コミット対象のトランザクションを選択する。

図１２に示すように、トランザクション＃１、＃２、＃３、＃４および＃５は、いずれも「１」という重みおよびトランザクションランキングを有する。各トランザクションのトランザクションランキングを決定するために、上述した方法を用いて、競合しているトランザクションの重みからこれらの重みを減算する。したがって、トランザクション＃６の重みからトランザクション＃１、＃２および＃３の重みを減算すること（すなわち、１－３＝－２）によってトランザクション＃６のトランザクションランキングを計算すると、トランザクション＃６は、トランザクションランキング「－２」を有する。同様の手順を実行して、トランザクション＃７の合計トランザクション重みを決定する。トランザクション＃７のトランザクション重みからトランザクション＃４および＃５のトランザクション重みを減算すること（すなわち、１－２＝－１）によって、トランザクション＃７は、トランザクションランキング「－１」を有する。同様に、トランザクション＃８に対して、この手順を繰り返す。トランザクション＃８のトランザクション重みからトランザクション＃３、＃６および＃７の負の重みを減算することによって、トランザクション＃８は、合計トランザクションランキング「３」を有する。

図１２の関係グラフでは、システムおよび方法は、複数のトランザクションの競合を提供することができる。例えば、図１２において、トランザクション＃３は、２つのトランザクション（＃６および＃８）と競合している。

一実施形態によれば、競合グラフを計算した後、ランキングジェネレータが重み付きトランザクション競合に従って各トランザクションをランキングした後、トランザクションピッカーは、コミット対象のトランザクションを決定することができる。この例の場合、（最も高いランキングを有する）トランザクション＃８と＃１、＃２、＃４および＃５とは、正の値を有し且つ互いに競合しないため、コミット対象に選択される。トランザクション＃３は、トランザクション＃１、＃２、＃４および＃５と同様のトランザクションランキングを有するにもかかわらず、トランザクション＃３よりも高いランキングを有するトランザクション＃８と競合するため、コミット対象に選択されない。トランザクション＃６および＃７は、トランザクションランキングが低く且つ両方のトランザクションがトランザクション＃８と競合しているため、コミット対象に選択されない。このような選択
は、図に示される。図示では、コミット対象に選択されたトランザクションは、太い輪郭を有し、コミット対象に選択されないトランザクションは、破線で示されている。

図１３は、一実施形態に従って、本開示の一実施形態に使用され得る例示的な関係グラフを示す。

一実施形態によれば、図１３は、図１２に示された状況よりも複雑な第３の状況を示す。図１３の関係マップにおいて、１４個のトランザクションは、２つの競合クラスタに分けられる。トランザクション＃１～＃８（１３０１～１３０８）は、クラスタＡに含まれ、トランザクション＃９～＃１４（１３０９～１３１４）は、クラスタＢに含まれる。

一実施形態によれば、例えば、ブロックチェーンシステムが、トランザクション＃１～＃１４と命名された１４個の有序トランザクションを含む一連のトランザクションを受信すると仮定する。競合検出器によって判定された全てのトランザクションの競合関係は、１つのグラフにまとめることができる。

競合検出後、競合関係は、以下の通りである。
・Ｃ（＃１，＃２，＃３）＝＃６
・Ｃ（＃４，＃５）＝＃７
・Ｃ（＃３，＃６，＃７）＝＃８
・Ｃ（＃９，＃１０，＃１１，＃１３）＝＃１４
・Ｃ（＃１１、＃１２）＝＃１３
一実施形態によれば、この例に引き続き、自動的にまたは管理者によって設定された、初期重み「２」を有するトランザクション＃１０および初期重み「５」を有するトランザクション＃１３を除き、各トランザクションの重みが「１」に等しいと仮定する。

図１３に示すように、トランザクション＃１～＃８は、クラスタＡに含まれる。トランザクション＃１、＃２、＃３、＃４および＃５は、いずれも「１」という重みおよびトランザクションランキングを有する。各トランザクションのトランザクションランキングを決定するために、上述した方法を用いて、競合しているトランザクションの重みからこれらの重みを減算する。したがって、トランザクション＃６の重みからトランザクション＃１、＃２および＃３の重みを減算すること（すなわち、１－３＝－２）によってトランザクション＃６のトランザクションランキングを計算すると、トランザクション＃６は、トランザクションランキング「－２」を有する。同様の手順を実行して、トランザクション＃７の合計トランザクション重みを決定する。トランザクション＃７のトランザクション重みからトランザクション＃４および＃５のトランザクション重みを減算すること（すなわち、１－２＝－１）によって、トランザクション＃７は、トランザクションランキング「－１」を有する。同様に、トランザクション＃８に対して、この手順を繰り返す。トランザクション＃８のトランザクション重みからトランザクション＃３、＃６および＃７の負の重みを減算することによって、トランザクション＃８は、合計トランザクションランキング「３」を有する。

図１３に示すように、トランザクション＃９～＃１４は、クラスタＢに含まれる。トランザクション＃９、＃１１、＃１２および＃１４は、いずれも「１」という重みおよびトランザクションランキングを有する。トランザクション＃１０は、初期重み「２」を有する。トランザクション＃１３は、初期重み「５」を有するが、この重みから（トランザクション＃１１および＃１２の重み）「２」を減算して、トランザクションランキング「３」を有する。トランザクション＃１４は、初期重み「１」を有するが、この重みから（トランザクション＃９、＃１０、＃１１、および＃１３の初期重みおよび修正重み）「７」を減算して、トランザクションランキング「－６」を有する。

一実施形態によれば、競合グラフを計算した後、ランキングジェネレータが重み付きトランザクション競合に従って各トランザクションをランキングした後、トランザクションピッカーは、コミット対象のトランザクションを決定することができる。この例の場合、（最も高いランキングを有する）トランザクション＃８および＃１３とトランザクション＃１、＃２、＃４、＃５、＃９および＃１０とは、正の値を有し且つ互いに競合しないため、コミット対象に選択される。トランザクション＃３は、トランザクション＃１、＃２、＃４および＃５と同様のトランザクションランキングを有するにもかかわらず、トランザクション＃３よりも高いランキングを有するトランザクション＃８と競合するため、コミット対象に選択されない。トランザクション＃６および＃７は、トランザクションランキングが低く且つ両方のトランザクションがトランザクション＃８と競合しているため、コミット対象に選択されない。トランザクション＃１１および＃１２は、トランザクション＃１３と競合するため、コミット対象に選択されない。トランザクション＃１４は、辺を共有するトランザクションに比べてトランザクションランキングが低いため、コミット対象に選択されない。

図１４は、一実施形態に従って、分散元帳における有向非循環グラフ（ＤＡＧ）ベースのトランザクション処理方法の一例を示すフローチャートである。

ステップ１４０１において、方法は、エンタープライズ級の分散型元帳フレームワークにおいて、複数のトランザクションを処理するための分散型元帳ファブリックを提供することができる。

ステップ１４０２において、方法は、競合検出器を用いて、複数のトランザクション間の複数の競合を検出することができる。

ステップ１４０３において、方法は、ランキングジェネレータを用いて、複数の初期重みパラメータのうちの１つの初期重みパラメータを複数のトランザクションのうちの各トランザクションに追加することができる。ランキングジェネレータは、ＤＡＧを生成し、ＤＡＧの少なくとも１つの頂点は、ランキング値を含む。

ステップ１４０４において、方法は、トランザクションピッカーを用いて、生成されたＤＡＧに基づいて、複数のトランザクションから、コミットする予定のトランザクションセットを選択することができる。

以上で様々な実施形態を説明したが、これらの実施形態は、例示として提示され、本開示を限定しない。これらの実施形態は、本開示の特徴および原理並びにその実用を説明するために選択され、説明された。実施形態は、システムおよび方法を例示する。これらの実施形態は、新しい機能および／または改善された機能を提供することによって、および／またはリソース利用率の減少、容量の増加、スループットの増加、効率の改善、待ち時間の減少、セキュリティの強化、および／または使用の容易性の改善を含むがこれらに限定されない性能利点を提供することによって、様々な特徴を用いて、システムおよび方法の性能を改善する。

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

いくつかの実施形態において、特徴は、プロセッサと、コンピュータ可読媒体と、他のコンピュータと通信するためのネットワークカード／インターフェイスとを含むコンピュータに実装される。いくつかの実施形態において、特徴は、ネットワークによって相互接続されたパーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等を含む様々な種類のコンピュータ構成を含むコンピューティングシステムを備えるネットワークコンピューティング環境において実装される。ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、スイッチファブリックネットワーク（例えば、インフィニバンド）、ワイドエリアネットワーク（ＷＡＮ）、および／またはインターネットであってもよい。ネットワークは、銅伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、および／またはエッジサーバを含むことができる。

いくつかの実施形態において、特徴は、バックエンドコンポーネント（例えば、データサーバ）を含むコンピューティングシステム、またはミドルウェアコンポーネント（例えば、アプリケーションサーバ）を含むコンピューティングシステム、またはフロントエンドコンポーネント（例えば、ユーザが本明細書に記載された主題の実装形態と対話するときに使用されるグラフィカルユーザインターフェイスまたはウェブブラウザを有するクライアントコンピュータ）を含むコンピューティングシステム、またはネットワークによって相互接続されたバックエンドコンポーネント、ミドルウェアコンポーネント、もしくはフロントエンドコンポーネントの任意の組み合せを含むコンピューティングシステムにおいて実装される。コンピューティングシステムは、互いにクライアント－サーバ関係を有するクライアントおよびサーバを含むことができる。いくつかの実施形態において、機能は、ネットワークを介して接続される１つ以上のコンピュータクラスタを含む分散型コンピューティング環境を備えるコンピューティングシステムにおいて実装される。分散型コンピューティング環境内の全てのコンピュータは、単一の場所に配置されてもよく、またはネットワークによって接続された異なる遠隔場所にコンピュータクラスタとして配置されてもよい。

いくつかの実施形態において、特徴は、ウェブ技術を用いて共有された弾性リソースに基づいてセルフサービス供給方法でユーザに配布されたクラウドコンピューティングシステムの一部としてまたはサービスとしてクラウドに実装される。クラウドの特性は、例えば、オンデマンドセルフサービス、ブロードネットワークアクセス、リソースプール、急速順応性、および計数サービスを含んでもよい。クラウド配置モデルは、パブリック、プライベート、およびハイブリッドを含む。クラウドサービスモデルは、ＳａａＳ（Software as a Service）、ＰａａＳ（Platform as a Service）、ＤＢａａＳ（Database as a Service）、およびＩａａＳ（Infrastructure as a Service）を含む。クラウドは、一般的に、共有された弾性リソースをユーザに配布するハードウェア、ソフトウェア、ネットワーク、およびウェブ技術の組み合わせを指す。本明細書に使用されたクラウドは、パブリッククラウド、プライベートクラウド、および／またはハイブリッドクラウド実装を含むことができ、クラウドＳａａＳ、クラウドＤＢａａＳ、クラウドＰａａＳ、および／またはクラウドＩａａＳ配置モデルを含むことができる。

いくつかの実施形態において、特徴は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせを用いて実装される。いくつかの実施形態において、特徴は、教示されたアプローチの１つ以上の機能を実行するように構成されたまたはプログラムされたプロセッサを用いて実装される。いくつかの実施形態において、プロセッサは、本明細書に記載の機能を実行するように設計された、シングルチップまたはマルチチッププロセッサ、デジタル信号プロセッサ（ＤＳＰ）、システムオンチップ（ＳＯＣ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理装置、ステートマシン、離散型ゲートまたはトランジスタロジック、離散型ハードウェアコンポーネント、またはそれらの任意の組合せである。いくつかの実装形態において、特徴は、特定の機能を有する回路によって実装される。他の実装形態において、特徴は、例えば、コンピュータ可読記憶媒体に記憶された命令を用いて、特定の機能を実行するように構成されたコンピュータ、コンピューティングシステム、プロセッサ、および／またはネットワークに実装される。

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

いつかの実施形態において、本開示に教示されたアプローチは、ソフトウェアおよび／またはファームウェアを含む命令を格納または担持する機械可読またはコンピュータ可読媒体であるコンピュータプログラム製品を含む。これらの命令を用いて、本開示に教示されたアプローチのプロセスまたは機能を実行するように、コンピュータなどのシステムをプログラムするまたは構成することができる。機械可読またはコンピュータ可読媒体は、フロッピー（登録商標）ディスク、ハードドライブ、ソリッドステートドライブ、光ディスク、ＤＶＤ、ＣＤ－ＲＯＭ、マイクロドライブ、光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ装置、磁気カードまたは光カード、分子メモリ、ナノシステム、またはそれらの変形体およびそれらの組み合わせを含むがこれらに限定されない命令および／またはデータを記憶するのに適した任意の種類の媒体または装置を含むことができる記憶媒体を含むことができる。特定の実施形態において、記憶媒体またはコンピュータ可読媒体は、非一時的な機械可読記憶媒体または非一時的なコンピュータ可読記憶媒体である。また、機械可読媒体またはコンピュータ可読媒体は、搬送波または送信信号などの一過性媒体を含んでもよい。

したがって、一観点から、本明細書は、分散型元帳におけるＤＡＧベースのトランザクション処理システムおよび方法を記載する。一実施形態によれば、分散型元帳におけるＤＡＧベースのトランザクション処理システムおよび方法を導入することができる。このモデルは、スループット性能を改善することができる。追加の重みメカニズムを用いて、様々なビジネス要件に基づいて最終性能を調節することができる。線形構造を使用した既存の作業とは異なり、より良好な性能を達成することができる。

本開示のさらなる例は、以下の番号付き項で説明される。
第１項
分散型元帳における有向非循環グラフ（ＤＡＧ）ベースのトランザクション処理システムであって、エンタープライズ級の分散型元帳フレームワークと、分散型元帳ファブリッ
クとを備え、当該分散型元帳ファブリックは、複数のトランザクションを処理し、競合検出器を備え、当該競合検出器は、複数のトランザクション間の複数の競合を検出し、ランキングジェネレータを備え、当該ランキングジェネレータは、複数の初期重みパラメータのうちの１つの初期重みパラメータを複数のトランザクションのうちの各トランザクションに追加し、当該ランキングジェネレータは、ＤＡＧを生成し、当該ＤＡＧの少なくとも１つの頂点は、ランキング値を含み、トランザクションピッカーを備え、当該トランザクションピッカーは、生成されたＤＡＧに基づいて、複数のトランザクションから、コミット対象のトランザクションセットを選択する。

第２項
複数の初期重みパラメータは、入力を介して提供される、第１項に記載のシステム。

第３項
複数の初期重みパラメータは、自動的に導出される、第１項に記載のシステム。

第４項
複数の初期重みパラメータは、少なくとも複数のトランザクションの各々の相対重要度に基づいて導出される、第３項に記載のシステム。

第５項
生成されたＤＡＧは、複数のトランザクションの各々のランキングを計算し、当該計算された複数のトランザクションの各々のランキングは、トランザクションに割り当てられた初期重みパラメータまたは修正重みパラメータのうちの１つである、先行する項のいずれか一項に記載のシステム。

第６項
各修正重みパラメータは、対象トランザクションの初期重みパラメータと、対象トランザクションと競合するトランザクションの少なくとも１つのランキングとに基づいて計算される、第５項に記載のシステム。

第７項
コミット対象の複数のトランザクションセット内の各トランザクションは、競合しない、第１項から第６項のいずれか一項に記載のシステム。

第８項
分散型元帳における有向非循環グラフ（ＤＡＧ）ベースのトランザクション処理方法であって、エンタープライズ級の分散型元帳フレームワークにおいて、分散型元帳ファブリックを提供することを含み、当該分散型元帳ファブリックは、複数のトランザクションを処理し、競合検出器が、複数のトランザクション間の複数の競合を検出することと、ランキングジェネレータが、複数の初期重みパラメータのうちの１つの初期重みパラメータを複数のトランザクションのうちの各トランザクションに追加することとを含み、当該ランキングジェネレータは、ＤＡＧを生成し、当該ＤＡＧの少なくとも１つの頂点は、ランキング値を含み、トランザクションピッカーが、生成されたＤＡＧに基づいて、複数のトランザクションから、コミット対象のトランザクションセットを選択することを含む。

第９項
複数の初期重みパラメータは、入力を介して提供される、第８項に記載の方法。

第１０項
複数の初期重みパラメータは、自動的に導出される、第８項に記載の方法。

第１１項
複数の初期重みパラメータは、少なくとも複数のトランザクションの各々の相対重要度に基づいて導出される、第１０項に記載の方法。

第１２項
当該生成されたＤＡＧは、複数のトランザクションの各々のランキングを計算し、当該計算された複数のトランザクションの各々のランキングは、トランザクションに割り当てられた初期重みパラメータまたは修正重みパラメータのうちの１つである、第８項から第１１項のいずれか一項に記載の方法。

第１３項
各修正重みパラメータは、対象トランザクションの初期重みパラメータと、対象トランザクションと競合するトランザクションの少なくとも１つのランキングとに基づいて計算される、第１２項に記載の方法。

第１４項
コミット対象の複数のトランザクションセット内の各トランザクションは、競合しない、第８項から第１３項のいずれか一項に記載の方法。

第１５項
分散型元帳における有向非循環グラフ（ＤＡＧ）ベースのトランザクション処理命令を担持するコンピュータ可読媒体であって、当該命令は、読み出されて実行されると、１つ以上のコンピュータに、以下を含むステップを実行させ、当該ステップは、
競合検出器が、複数のトランザクション間の複数の競合を検出することと、
ランキングジェネレータが、複数の初期重みパラメータのうちの１つの初期重みパラメータを複数のトランザクションのうちの各トランザクションに追加することとを含み、当該ランキングジェネレータは、ＤＡＧを生成し、当該ＤＡＧの少なくとも１つの頂点は、ランキング値を含み、
トランザクションピッカーが、生成されたＤＡＧに基づいて、複数のトランザクションから、コミット対象のトランザクションセットを選択することを含む。

第１６項
複数の初期重みパラメータは、入力を介して提供される、第１５項に記載のコンピュータ可読媒体。

第１７項
複数の初期重みパラメータは、自動的に導出される、第１５項に記載のコンピュータ可読媒体。

第１８項
複数の初期重みパラメータは、少なくとも複数のトランザクションの各々の相対重要度に基づいて導出される、第１７項に記載のコンピュータ可読媒体。

第１９項
当該生成されたＤＡＧは、複数のトランザクションの各々のランキングを計算し、
当該計算された複数のトランザクションの各々のランキングは、トランザクションに割り当てられた初期重みパラメータまたは修正重みパラメータのうちの１つである、第１５項から第１８項のいずれか一項に記載のコンピュータ可読媒体。

第２０項
各修正重みパラメータは、対象トランザクションの初期重みパラメータと、対象トランザクションと競合するトランザクションの少なくとも１つのランキングとに基づいて計算される、第１９項に記載のコンピュータ可読媒体。

上記の説明は、網羅的であることまたは範囲を開示された正確な形態に限定することを意図していない。また、特定の一連のトランザクションおよびステップを用いて実施形態を説明したが、明記しない限り、追加のトランザクションおよびステップの実行を排除しないことは、当業者には明白であろう。さらに、様々な実施形態において、特徴の特定の組み合わせを説明するが、特徴の異なる組み合わせが本開示の範囲に含まれることは、当業者には明白であろう。特に、特定の実施形態、変形例または図面に記載された（装置または方法のような）特徴は、教示および範囲から逸脱することなく、別の実施形態、変形例または図面に記載された別の特徴と組み合わせるまたは置き換えることができる。さらに、本開示の精神および範囲から逸脱することなく、様々な追加、減少、削除、変形、均等物による要素の置換、並びに形態、詳細、実装および用途における他の修正および変更を行うことができることは、当業者には明白であろう。より広い精神および保護範囲は、以下の特許請求の範囲およびその均等物によって定義される。

Claims (9)

1. 分散型元帳における有向非循環グラフ（ＤＡＧ）ベースのトランザクション処理を行うための方法であって、
   コンピュータが、分散型元帳フレームワークにおいて、ブロックチェーン元帳を提供することを含み、前記ブロックチェーン元帳は、複数のブロックを含み、各ブロックは、複数のトランザクションのうち、少なくとも１つのトランザクションの記録を含み、
   前記コンピュータが、複数の新しいトランザクションを前記ブロックチェーン元帳にコミットする命令を受信すると、前記複数の新しいトランザクション間の競合を検出することを含み、前記複数の新しいトランザクションの各々は、初期重みパラメータに関連付けられ、
   前記コンピュータが、互いに競合関係を有するトランザクション間にエッジを描画することにより、前記複数の新しいトランザクションの各々を含む有向非循環グラフを生成することと、
   前記コンピュータが、前記生成された有向非循環グラフの前記エッジに基づいて、前記初期重みパラメータの少なくとも１つを修正することと、
   前記コンピュータが、前記初期重みパラメータおよび修正された重みパラメータに基づいて、前記複数の新しいトランザクションの中から一組のトランザクションを選択し、前記一組のトランザクションを前記ブロックチェーン元帳の少なくとも１つの新しいブロックに記録することとを含む、方法。
2. 前記初期重みパラメータの少なくとも１つは、入力を介して提供される、請求項１に記載の方法。
3. 前記初期重みパラメータの少なくとも１つは、前記関連付けられた新しいトランザクションに示される、請求項１に記載の方法。
4. 前記有向非循環グラフの生成中に、前記複数の新しいトランザクションのうちの第１のトランザクションの前記修正された重みパラメータは、前記第１のトランザクションの前記初期重みパラメータと、前記第１のトランザクションと競合する第２のトランザクションの前記初期重みパラメータとに基づいて計算される、請求項１に記載の方法。
5. 分散型元帳における有向非循環グラフ（ＤＡＧ）ベースのトランザクション処理を行うためのシステムであって、
   ブロックチェーン元帳を含む分散型元帳フレームワークを備え、前記ブロックチェーン元帳は、複数のブロックを含み、各ブロックは、複数のトランザクションのうち、少なくとも１つのトランザクションの記録を含み、
   複数の新しいトランザクションを前記ブロックチェーン元帳にコミットする命令を受信すると、前記複数の新しいトランザクション間の競合を検出し、前記複数の新しいトランザクションの各々は、初期重みパラメータに関連付けられ、
   互いに競合関係を有するトランザクション間にエッジを描画することにより、有向非循環グラフを生成し、前記有向非循環グラフは、前記複数の新しいトランザクションの各々を含み、
   前記生成された有向非循環グラフの前記エッジに基づいて、前記初期重みパラメータの少なくとも１つを修正し、
   前記初期重みパラメータおよび修正された重みパラメータに基づいて、前記複数の新しいトランザクションの中から一組のトランザクションを選択し、前記一組のトランザクションを前記ブロックチェーン元帳の少なくとも１つの新しいブロックに記録する、システム。
6. 前記初期重みパラメータの少なくとも１つは、入力を介して提供される、請求項５に記載のシステム。
7. 前記初期重みパラメータの少なくとも１つは、前記関連付けられた新しいトランザクションに示される、請求項５に記載のシステム。
8. 前記有向非循環グラフの生成中に、前記複数の新しいトランザクションのうちの第１のトランザクションの前記修正された重みパラメータは、前記第１のトランザクションの前記初期重みパラメータと、前記第１のトランザクションと競合する第２のトランザクションの前記初期重みパラメータとに基づいて計算される、請求項５に記載のシステム。
9. 請求項１から４のいずれか１項に記載の方法をコンピュータに実行させるためのコンピュータプログラム。