(57)【要約】  本明細書において、暗号化メッセージが各ノード間で交換されるピアツーピア・ネットワーク内でデータ構造を分散するための暗号プラットフォームを提供するシステムが開示される。このシステムは、プライベートでありながらグローバル状態ルートを使用して検証可能な各サブスペースを含む、プライベートにサブスペース化されたブロックチェーンの作成および管理を提供する。グローバル状態ルートは、サブスペースのルートに基づいて更新され、これらルートはそのサブスペース内のデータに基づいて生成される。
2020522796.tif 000002
【特許請求の範囲】
【請求項１】
データのプライベートで安全な交換を可能にし、当該データの信頼性を確保するための分散型プラットフォームを提供するシステムであって、
ネットワークを介して通信可能に互いに結合された複数のノードであって、前記複数のノードにおけるそれぞれのノードが、共通サブスペース内で交換されるメッセージを受信するためのロジックを備える、複数のノードと、
前記複数のノード内のノードのサブセットであって、ドメインに対応し、当該ドメイン内のプライベート・サブスペース内で交換されるメッセージへのアクセス許可を有する、ノードのサブセットと、
前記ノードのサブセット内の検証ノードのセットであって、それぞれの検証ノードが、前記プライベート・サブスペース内で交換されるメッセージに基づいて状態ルートを生成するためのロジックを備える、検証ノードのセットと、
前記状態ルートに基づいてグローバル状態ルート値を生成するためのロジックを更に備える、前記ノードのサブセット内のノードと、を備える、システム。
【請求項２】
前記状態ルートが、前記プライベート・サブスペース内のデータに対して実行されたハッシュ関数の結果であるハッシュ値であり、前記グローバル状態ルートが、前記状態ルートを含むデータのセットに対して実行されたハッシュ関数の結果であるハッシュ値である、請求項１に記載のシステム。
【請求項３】
前記検証ノードのセット内のそれぞれのノードが、前記検証ノードのセット内の他のノードに関わるコンセンサス投票プロセスに基づいて、前記プライベート・サブスペース内で交換されるメッセージを検証するためのロジックを備える、請求項１に記載のシステム。
【請求項４】
それぞれのノードについての許可情報が、前記共通サブスペース内で維持され、許可情報への変更が、前記共通サブスペース内でメッセージを交換および検証する前記複数のノードを通じて管理される、請求項１に記載のシステム。
【請求項５】
前記複数のノード内のそれぞれのノードが、前記許可情報に基づいて、受信したメッセージを当該メッセージを受信することを許可された他のノードに転送するためのロジックを備える、請求項４に記載のシステム。
【請求項６】
複数のノード内のそれぞれのノードが、データベースに通信可能に結合され、前記複数のノード内のそれぞれのノードが、検証済みのメッセージおよびブロックを前記データベース内に保存する、請求項１に記載のシステム。
【請求項７】
それぞれのノードが、基準の１つ以上のセットに従ってメッセージおよびブロックを削除するためのロジックを更に備え、メッセージを削除してもサブスペース・ハッシュ値およびグローバル・ハッシュ値は保持される、請求項６に記載のシステム。
【請求項８】
データのプライベートで安全な交換を可能にし、当該データの信頼性を確保するための分散型プラットフォーム内のネットワーク・ノードであって、
ネットワーク内の全てのノードがメッセージへのアクセス許可を有する共通サブスペース内で交換されるメッセージを受信し、前記ノードが許可されているプライベート・サブスペース内で交換されるメッセージを受信するためのロジックと、
前記プライベート・サブスペース内で交換されるメッセージに基づいてサブスペース・ハッシュ値を生成するためのロジックと、
前記サブスペース・ハッシュ値に基づいてグローバル・ハッシュ値を生成するためのロジックと、を備える、ネットワーク・ノード。
【請求項９】
前記分散型プラットフォーム内の他のノードに関わるコンセンサス投票プロセスに基づいて、前記プライベート・サブスペース内で交換されるメッセージを検証するためのロジックを更に備える、請求項８に記載のネットワーク・ノード。
【請求項１０】
前記分散型プラットフォーム内のそれぞれのノードについての許可情報が前記共通サブスペース内で維持され、許可情報への変更が前記共通サブスペース内でメッセージを交換および検証する前記ネットワーク・ノードを通じて管理される、請求項８に記載のネットワーク・ノード。
【請求項１１】
前記許可情報に基づいて、受信したメッセージを当該メッセージを受信することを許可された他のノードに転送するためのロジックを更に備える、請求項１０に記載のネットワーク・ノード。
【請求項１２】
前記ネットワーク・ノードが、データベースに通信可能に結合され、前記ネットワーク・ノードが、検証済みのメッセージおよびブロックを前記データベース内に保存する、請求項８に記載のネットワーク・ノード。
【請求項１３】
基準の１つ以上のセットに従ってメッセージおよびブロックを削除するためのロジックを更に備え、メッセージを削除しても前記サブスペース・ハッシュ値およびグローバル・ハッシュ値は保持される、請求項１２に記載のネットワーク・ノード。
【請求項１４】
分散型ネットワーク内の複数のノード間でプライベート・データを安全に交換し、当該データの信頼性を確保するための、コンピューターメモリに実装された分散型データ構造であって、
十分なアクセス資格を有する前記複数のノード内のノードのみがアクセス可能な内容を有する１つ以上のプライベート・サブスペースであって、それぞれのサブスペースが状態ルートを含む、１つ以上のプライベート・サブスペースと、
前記複数のノード内の全てのノードがアクセス可能な共通サブスペースであって、それぞれのプライベート・サブスペースの検証ノードを識別する、共通サブスペースと、
前記１つ以上のサブスペースの前記状態ルートに基づくグローバル状態ルートを含むヘッダと、を備える、分散型データ構造。
【請求項１５】
それぞれのプライベート・サブスペースの前記状態ルートが、当該プライベート・サブスペース内のデータに対して実行されたハッシュ関数の結果であるハッシュ値である、請求項１４に記載の分散型データ構造。
【請求項１６】
前記グローバル状態ルートが、前記１つ以上のプライベート・サブスペースの前記状態ルートを含むデータのセットに対して実行されたハッシュ関数の結果であるハッシュ値である、請求項１４に記載の分散型データ構造。
【請求項１７】
前記共通サブスペースが、前記複数のノード内のそれぞれのノードの許可を管理するためのスクリプトを含む、請求項１４に記載の分散型データ構造。
【請求項１８】
それぞれのプライベート・サブスペースが、前記サブスペースのハッシュ値を保持する削除プロセスを通じて、前記プライベート・サブスペース内のブロックおよびメッセージを削除するためのポリシーを含む、請求項１４に記載の分散型データ構造。
【請求項１９】
前記ヘッダが、前記分散型データ構造を検証するために使用される１つ以上の暗号署名を更に含む、請求項１４に記載の分散型データ構造。
【請求項２０】
前記ヘッダが、前記分散型データ構造内に含まれる全てのメッセージの関数である値を有するメッセージ・ルートを更に含む、請求項１４に記載の分散型データ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、米国特許仮出願第６２／５１３，７７３号（出願日：２０１７年６月１日）に基づく優先権を主張するものであり、この米国特許仮出願の開示は、参照により法律が許す限りにおいて本明細書に組み込まれる。
【０００２】
本発明は全体として、プライベートにサブスペース化されたブロックチェーン分散型データ構造と、それを管理するためのシステムおよび方法に関する。より具体的には、本発明は、複数のサブスペースを備えた新規な許可型連鎖データ構造と、更に連鎖データ構造内の各サブスペースへの許可および安全なアクセスを提供する統合検証メカニズムと、そのような許可型連鎖データ構造を管理するためのシステムおよび方法に関する。
【背景技術】
【０００３】
分散型データベースは、互いに離れた場所にいながら共有データにアクセスする必要がある可能性のある複数のそれぞれ異なるユーザに共有データを分散配置するための非集中型手段を提供することができる。このような共有データが信頼できるものであるためには、分散型データベース内のデータの整合性を検証する方法が必要である。分散型データベースの一形態として「ブロックチェーン（ｂｌｏｃｋｃｈａｉｎ）」（または「ブロック・チェーン」（ｂｌｏｃｋ  ｃｈａｉｎ」）がある。これは「ブロック」と呼ばれる、時間順にリンクされた一連のより小さなデータ構造またはレコードからなり、それぞれがブロックチェーン内の前のブロックへのリンクを含むデータ構造の一種である。それぞれのブロックは、ブロックチェーン内の前のブロックのハッシュ値を含み、これは２つのブロックをリンクするための手段として機能する。ハッシュ値の使用は、データの検証可能性を確保し、ブロックチェーン内でデータが変更されることを防ぐのに役立つ。ブロックチェーンの整合性は、中央に配置されたブロックチェーンの「オフィシャル」コピーが存在する必要がないという点で、ブロックチェーンの非集中型の性質によって向上している。代わりに、ブロックチェーンの複数の検証可能なコピーをそれぞれ異なるユーザの元に保存することによって、ブロックチェーンの不正な変更を防止してもよい。
【０００４】
従来のブロックチェーンのようなこうした分散型および非集中型のデータ構造の欠点の１つは、データ構造のコピーのそれぞれの所有者が、そのようなデータ構造内に保存されているデータに必然的にアクセス可能となることである。分散型データ構造のコピーのそれぞれの所有者がデータにアクセス可能であることは、ユーザがそこに保存されているデータの整合性を検証することを可能にし、分散型データ構造の特定のコピー内に保存されているデータが改ざんおよび許可なく変更されていないことを確認するために不可欠である。その結果、従来のブロックチェーンのようなこうした分散型データ構造では、ユーザがデータをブロックチェーン内にプライベートに保存することを許可していない。このような分散型データ構造を共有および利用する従来のシステムも、権限または許可されたアクセスを必要とせず、むしろ、追加的なユーザの存在により分散型データ構造のコピー数が通常増加し、従って記録改ざんのリスクが低減するため、アクセス制御の欠如から恩恵を受ける。この点について、このような従来のシステムには通常、システム内の各ノードのアイデンティティおよび関連する許可を検証する手段がない。
【発明の概要】
【０００５】
本明細書では、安全なアクセス制限を可能にすることができる新規なデータ構造の作成および分散型管理のためのシステムおよび方法を開示する。新規なデータ構造および関連する各機能は、共にチェーンを形成するリンクされた各ブロックを含む分散型データベースであるという点でブロックチェーンの原理に基づき、それぞれのブロックは、２つのブロック同士をリンクするチェーン内の前のブロックのハッシュを含む。しかし、これらの新規なデータ構造は、それぞれのブロックのデータセット内で各プライベート・データ・サブスペースを設けることを可能にする重要で新規な特徴および機能性を含むという点で、従来のブロックチェーン構造とは異なる。そのような各サブスペースへは、各サブスペースにアクセスすることを許可されている各ノードのみがアクセス可能であり、各ブロックのコピーは一般に、あるノードがそのノードに許可されている各サブスペースからのみ受信するような方法で伝播される。参照し易いように、本明細書で開示する新規なデータ構造は「プライベートにサブスペース化されたブロックチェーン」と呼ばれるが、これらのデータ構造は、以下で詳細に説明するように、従来のブロックチェーンとは大きく異なることが認識されている。
【０００６】
本明細書で開示するように、新規なデータ構造およびその管理は、データ・ペイロード（サブスペース）整合性の分散型でコンセンサスベースの検証の利点を提供し、複数のそれぞれ異なるノードがデータ構造の一部のコピーを保管すると同時に、データ共有にデータ分離をもたらす。特に、データ構造内の共通参照データは全ての許可されたノードにとって利用可能であるが、データ・ペイロードの一部（本明細書において、データ構造内の「サブスペース」と呼ぶ）は十分なアクセス資格を有するノードのみが利用することができる。これらのシステムおよび方法は更に、十分な許可を有する各ノードに、必要に応じて読み取り／書き込みアクセスさせることを許可されるべきデータを提供する。本発明のシステムおよび方法は更に、各ノード間のこれらのデータ構造の安全で認証された転送のための、そして特定のデータ構造に関する各ノード間の通信がシステム容量またはデータ構造の他のコピーに関わる他の各ノード間の通信を処理する能力に影響を与えないような転送を容易にするために各ノード間の相互接続をプロビジョニングするための新規な手段を提供する。本発明のシステムおよび方法は更に、分離を確保するデータ構造のための改善されたコンセンサス・メカニズムを提供し、これは、あるノード対間のコンセンサスの不成立が他の各ノード対間の連鎖的不成立をもたらさないことを意味する。本発明のシステムおよび方法は更に、連続性を確保するデータ構造のための改善されたコンセンサス・メカニズムを提供し、これは、システムが適切に処理を継続し、到達不能な処理ノードの場合であってもデータ構造の整合性が維持されることを意味する。本発明のシステムおよび方法は更に、各ノード間の改善された競合管理、および追加的なノードの配置が既存の各ノードの重要な更新を必要としない改善された拡張を提供する。加えて、本発明のシステムおよび方法は更に、データが検証可能であるような方法での外部データベースとの改善された同期を提供する。
【０００７】
本明細書に記載の新規なプライベートにサブスペース化されたブロックチェーン・データ構造並びに関連するシステムおよび方法は、上記の特徴および改善が有利となる様々な状況で使用され得る。例えば、新規なデータ構造並びに関連するシステムおよび方法を使用して、在庫管理、部品追跡（例えば航空機部品メンテナンス・サイクル追跡）、高価値商品（ダイヤモンド等）の原産地検証、医療記録、不動産およびデジタル資産に関係する権利譲渡、安全な文書処理、および分散型検証と許可されたデータの保存およびアクセスの両方の特徴を提供するデータ構造から恩恵を受ける他の分野および用途に関するデータの安全な交換を実現してもよい。加えて、新規なデータ構造並びに関連するシステムおよび方法を使用して、クレジット・デフォルト・スワップ（ＣＤＳ）、エクイティ・スワップ、および外国為替（ＦＸ）トランザクションに関連するものを含むスマートコントラクトアプリケーションのための安全なシステムを実現してもよい。
【０００８】
本発明の一実施形態によれば、ピアツーピア・ネットワーク内でデータ構造を分散させるための暗号プラットフォーム用システムが提供される。このシステムは、非一時的なコンピュータ可読記憶媒体と、記憶媒体に保存されたコードの形態である命令を含む１つ以上のソフトウェア・モジュールを実行することによって構成されたプロセッサとを備える。これらのモジュールは、ネットワーク上で遠隔デバイスから暗号化データを第１のピア・ノードと第２のピア・ノードとの間で送信および受信するようにプロセッサを構成する通信モジュールと、前記第１のピア・ノードと第２のピア・ノードとの間で交換される暗号化データを表す状態ルート（ｓｔａｔｅ  ｒｏｏｔ）を作成するようにプロセッサを構成するコア・モジュールであって、更に、ネットワーク内の複数のピア・ノード間で交換される暗号化データを表すグローバル状態ルート（ｇｌｏｂａｌ  ｓｔａｔｅ  ｒｏｏｔ）を作成するようにプロセッサを構成し、更に、ネットワーク内の各ピア・ノード間で交換されるデータの検証可能な記録を提供するプライベートにサブスペース化されたブロックチェーン内で許可されたブロックを作成するようにプロセッサを構成する、コア・モジュールと、前記第１のピア・ノードと第２のピア・ノードとの間で伝搬されるデータを記憶媒体に保存するようにプロセッサを構成するデータベース・モジュールであって、更に、状態ルート、グローバル状態ルート、およびブロックを記憶媒体に保存するようにプロセッサを構成する、データベース・モジュールと、を含む。
【０００９】
別の実施形態において、データ構造の分散を処理するためにコンピュータ可読媒体上で具現化されるコンピュータ・プログラム製品が提供される。このコンピュータ・プログラム製品は、複数のピア・ノード間で複数の暗号化メッセージを送信および受信するためのコンピュータ・コードと、前記ピア・ノード間で交換される前記暗号化メッセージについての複数の状態ルートを作成するためのコンピュータ・コードと、グローバル状態ルート内に複数の状態ルートを保存するためのコンピュータ・コードであって、それぞれの状態ルートがデータのサブスペースを定義する、コンピュータ・コードと、複数のサブスペースを含む複数のグローバル状態ルートからなるプライベートにサブスペース化されたブロックチェーンを作成するためのコンピュータ・コードと、を含む。
【００１０】
本発明の更に別の実施形態において、基礎となるネットワーク上に構築された１つ以上のネットワーク内の各ピア・ノード間でデータ構造を分散させるための暗号システムが提供される。これらのデータ構造は複数のグローバル状態ルートを含み、複数のグローバル状態ルートは複数の状態ルートを含む。暗号システムは、プライベートにサブスペース化されたブロックチェーン内に複数の許可されたブロックを保存するメモリと、サブスペース内の複数のピア・ノード間で交換される暗号化メッセージに基づいて状態ルートを作成する状態ルートジェネレータと、１つ以上の状態ルートに基づいてグローバル状態ルートを作成するグローバル状態ルートジェネレータと、前記グローバル状態ルートと状態ルートとをコンパイルするブロック・コンパイラと、前記許可された各ブロックを生成する許可ブロック・ジェネレータであって、許可されたブロックが前記グローバル状態ルートと１つ以上の状態ルートとを含む、許可ブロック・ジェネレータと、を備える。
【００１１】
別の実施形態において、ピアツーピア・ネットワーク内でデータ構造を分散させるための暗号プラットフォームを提供するシステムが提供される。このシステムは、複数のブロックのそれぞれについて、複数のグローバル状態ルートを定義するデータを含むクラウドベースのデータベースであって、グローバル状態ルートのそれぞれが複数の状態ルートを含む、クラウドベースのデータベースと、複数のピア・ノードで暗号化データを送信および受信するためのネットワーク対応デバイスと、ネットワーク対応デバイスとクラウドベースのデータベースとに結合されたコンピュータ・サーバと、を備える。コンピュータ・サーバは、第１のピア・ノードと第２のピア・ノードとの間で送信されるデータを暗号化し、前記第１のピア・ノードと第２のピア・ノードとの間で送信されるデータについての状態ルートを自動的に生成して情報のサブスペースを作成し、状態ルートの生成に応答して、グローバル状態ルートを自動的に更新し、情報のサブスペースを備えた前記状態ルートを含む複数の状態ルートからなる更新されたグローバル状態ルートで構成されたブロックを作成し、前記クラウドベースのデータベース内のプライベートにサブスペース化されたブロックチェーン内に前記ブロックを保存するようにプログラムされる。
【００１２】
更に別の実施形態において、プライベート・スマートコントラクトに対応する命令を保存し、プライベートにサブスペース化されたブロックチェーン・データ構造を使用して仮想マシンにおいてそれらの命令を実行するためのシステムおよび方法が提供される。
【００１３】
これらおよび他の側面並びに利点が、添付の図面を適宜参照して以下の詳細な説明を読むことにより、当業者に明らかになるであろう。また、前述の概要は単なる例示であり、本発明の範囲または添付の特許請求の範囲が法的に権利を与えられる均等物の範囲を如何なる形でも限定する意図はないことが理解されるべきである。
【図面の簡単な説明】
【００１４】
本特許または出願ファイルには、カラーで作成された少なくとも１つの図面が含まれている。カラー図面（群）付き本特許または特許出願公開の写しは、請求および必要な手数料の支払いを受けて庁が提供する。以下、本発明を下記の各説明図に関連して説明する。
【００１５】
【図１】本発明の一実施形態による、安全なアクセス制限を備えたデータ構造の作成および分散型管理のためのシステムの各コンポーネントを示す図である。
【００１６】
【図２】本発明の一実施形態による、上記システムのコア・モジュールおよびデータベース・モジュールの各コンポーネントを示す図である。
【００１７】
【図３】本発明の一実施形態による、ピアまたは検証ノードの各コンポーネントを示す図である。
【００１８】
【図４】本発明の一実施形態による、ブロックの内容を示す図である。
【００１９】
【図５】本発明の一実施形態による、暗号化データを交換する２つのノードの図である。
【００２０】
【図６】本発明の一実施形態による、データを要請し、許可をチェックし、データを検証するサービス・ノードの図である。
【００２１】
【図７Ａ】本発明の一実施形態による、別の許可されたノードがアクセス可能なサブスペース内で情報を送信するノードを示す図である。
【図７Ｂ】本発明の一実施形態による、別の許可されたノードがアクセス可能なサブスペース内で情報を送信するノードを示す図である。
【００２２】
【図８】本発明の一実施形態による、３つのそれぞれ異なるノードにとってアクセス可能なデータの各サブスペースを示す図である。
【００２３】
【図９】本発明の一実施形態による、プライベートにサブスペース化されたブロックチェーンに追加されている各サブスペースにおいて交換されるメッセージを示す図である。
【００２４】
【図１０】本発明の一実施形態による、ブロック・ヘッダに含まれる各状態ルートおよびグローバル状態ルートの作成を示す図である。
【００２５】
【図１１Ａ】本発明の一実施形態による、データの交換、データの検証、および全てのサブスペースからの各状態ルートを組み込むブロックの作成を示す図である。
【図１１Ｂ】本発明の一実施形態による、データの交換、データの検証、および全てのサブスペースからの各状態ルートを組み込むブロックの作成を示す図である。
【図１１Ｃ】本発明の一実施形態による、データの交換、データの検証、および全てのサブスペースからの各状態ルートを組み込むブロックの作成を示す図である。
【図１１Ｄ】本発明の一実施形態による、データの交換、データの検証、および全てのサブスペースからの各状態ルートを組み込むブロックの作成を示す図である。
【００２６】
【図１２Ａ】本発明の一実施形態による、各ノード間のコンセンサスのプロセスを示す図である。
【図１２Ｂ】本発明の一実施形態による、各ノード間のコンセンサスのプロセスを示す図である。
【図１２Ｃ】本発明の一実施形態による、各ノード間のコンセンサスのプロセスを示す図である。
【図１２Ｄ】本発明の一実施形態による、各ノード間のコンセンサスのプロセスを示す図である。
【図１２Ｅ】本発明の一実施形態による、各ノード間のコンセンサスのプロセスを示す図である。
【図１２Ｆ】本発明の一実施形態による、各ノード間のコンセンサスのプロセスを示す図である。
【図１２Ｇ】本発明の一実施形態による、各ノード間のコンセンサスのプロセスを示す図である。
【００２７】
【図１３】本発明の一実施形態による、許可されたネットワーク内の各検証ノードを示す図である。
【００２８】
【図１４】本発明の一実施形態による、サブスペース検証マッピングの図である。
【００２９】
【図１５】本発明の一実施形態による、スマートコントラクトの各コンポーネントおよび各サブスペースの対応する相互作用を示す図である。
【００３０】
【図１６Ａ】本発明の一実施形態による、コア・モジュールのアプリケーションを示す図である。
【図１６Ｂ】本発明の一実施形態による、コア・モジュールのアプリケーションを示す図である。
【図１６Ｃ】本発明の一実施形態による、コア・モジュールのアプリケーションを示す図である。
【図１６Ｄ】本発明の一実施形態による、コア・モジュールのアプリケーションを示す図である。
【図１６Ｅ】本発明の一実施形態による、コア・モジュールのアプリケーションを示す図である。
【００３１】
【図１７Ａ】本発明の一実施形態による、コア・モジュールの別のアプリケーションを示す図である。
【図１７Ｂ】本発明の一実施形態による、コア・モジュールの別のアプリケーションを示す図である。
【図１７Ｃ】本発明の一実施形態による、コア・モジュールの別のアプリケーションを示す図である。
【００３２】
【図１８】本発明の一実施形態による、自動化された物理的接続および契約許可を備えた現行の権利管理を使用するシステムのアプリケーションを示す図である。
【００３３】
【図１９】本発明の一実施形態による、プライベートにサブスペース化されたブロックチェーンに対する各ドメインと各サブスペースとの間の関係を示す図である。
【００３４】
【図２０Ａ】不動産担保証券（ＭＢＳ）プールの実装におけるプライベートにサブスペース化されたブロックチェーンおよび関連するシステムの使用を示す図である。
【図２０Ｂ】不動産担保証券（ＭＢＳ）プールの実装におけるプライベートにサブスペース化されたブロックチェーンおよび関連するシステムの使用を示す図である。
【発明を実施するための形態】
【００３５】
本発明は様々な形態で具現化することができるが、簡素化および例示の目的で、本発明の原理をそのいくつかの実施形態を参照することにより部分的に説明する。ただし、本開示は、特許請求されている主題の例示と見なされるべきであり、添付の特許請求の範囲を例示されている特定の実施形態に限定する意図はないことが理解される。本発明が、これらの特定の詳細に限定されることなく実施され得ることは当業者には明らかであろう。他の各例において、本発明を不必要に曖昧にしないために、周知の方法および構造は詳細には説明されていない。
【００３６】
図１は、本発明の一実施形態による、プライベートにサブスペース化されたブロックチェーンおよび安全なアクセス制限を備えた他の分散型データ構造の作成および分散型管理のためのシステム１００を示す。システム１００は、ローカル・エリア・ネットワーク（ＬＡＮ）またはインターネットなどの広域ネットワーク（ＷＡＮ）、またはそれらの組み合わせを介して互いに通信可能にリンクされた各ノード１１２の分散型ネットワークを中心に構築される。それぞれのノードは、本明細書で説明する機能を実行するためのロジックを備えた１つ以上のサーバ上に実装されてもよい。システム１００の各コンポーネント（コア・モジュール１０４およびデータベース１０６など）は、個々のサーバ上にあってもよく、または１つ以上のサーバ上にあってもよい。コア・モジュール１０４は、システム内のそれぞれのノードのコア機能性を提供する。それぞれのノードはコア・モジュール１０４と共に、別個のサーバ上にあってもよいデータベース・モジュール１０６と相互作用し得る。コア・モジュール１０４に関連付けられた機能性に加え、それぞれのノードは、各ＡＰＩ  １０２（以下で更に説明する）に関連付けられた機能性、およびセキュリティを強化するためのハードウェア鍵管理１０８も含み得る。コア・モジュール１０４は、各ノードの作成、構成、および登録のための各機能を含む。あるノードが作成されると、コア・モジュール１０４はそのノードを初期化し、そのノードを各統合ツール（各ＡＰＩ）１０２に接続し、ピアツーピア・ネットワークを介してそのノードを１つ以上のコンセンサス・ノードに接続する。コア・モジュール１０４は、以下で更に説明するように、システム１００内でのノードの役割を決定するノードのタイプ（検証、ピア、サービス）に基づいてノードを構成する。コア・モジュール１０４は更に、ノードを作成しているパーティまたはユーザを識別する識別子に基づいて、ノードがどの各サブスペースにアクセスできるのかを示す情報をノードに提供することによってノードを構成する。特定の各実施形態において、パーティまたはユーザの識別子は、ノード・タイプに関連付けられてもよく、ノード・タイプを識別するために使用されてもよい。例えば、登録プロセスの一環として、システムはそれぞれのパーティ／ユーザの識別子を特定のノード・タイプ（検証、ピア、サービス）に関連付けるテーブルを維持し、それぞれのノードに分散させる。追加的または代替的に、システムは、ノードの一意のノード識別子をノード・タイプ（検証、ピア、サービス）に関連付けるテーブルをそれぞれのノードに分散させる。追加的または代替的に、システム内の全てのノードがアクセスできる共通サブスペース内に維持された情報を使用してノード登録が維持され、それによって登録データが一貫し、全てのノードにとって利用可能であることを確実にする。ノード登録情報には、ノードが許可されている各サブスペースのリスト、およびそれぞれのサブスペースへのアクセス権のレベル（例えば、ピアに検証者、ピア、またはサービス・ノードのアクセス権があるかどうか）が含まれる。このようにして、ノードはそれぞれ異なるサブスペースに対してそれぞれ異なるレベルのアク���ス権を持つことができる。例えば、ノードは、あるサブスペース上の「検証者」であると同時に別のサブスペース上の「ピア」であってもよい。ノード登録は、共通サブスペース上で実行される特定のスクリプト（例えばスマートコントラクト）内で管理されてもよい。登録データセットへの変更は、共通サブスペース上のスクリプトにメッセージを送信することによって行われ、このような変更は、プライベートにサブスペース化されたブロックチェーン内のブロックにおいて変更を要請するメッセージが確認されると有効になる。
【００３７】
それぞれのノードは、ノードのタイプ（検証、ピア、またはサービス）を示すタイプ情報を保存する。これは、図２に示すように、ノードのデータ・アクセス・レベルおよびその主要な機能など、システム１００およびネットワーク上の他の各ノードに対するノードの役割とその挙動を決定する。検証ノード２０２は、そのノードが許可されている全てのサブスペースにアクセスできる。検証ノードは、以下で更に説明するように、プライベートにサブスペース化されたブロックチェーン内の各ブロックを検証するためのコンセンサス・プロセスに関与している。特に、検証ノードは、有効なメッセージおよびブロックに関して特定のサブスペースにおいて他の各ノードと合意する。検証ノード２０２は更に、受信する全てのメッセージを、そのような各メッセージを受信することを許可された各ノードに中継し、プライベートにサブスペース化されたブロックチェーン上の各ブロックにメッセージをコミットする。検証ノード２０２と同様に、ピア・ノード２０４は、そのノードが許可されている全てのサブスペースにアクセスできる。ただし、検証ノードとは異なり、ピア・ノードはコンセンサス・プロセスに参加しないオブザーバである。このため、ピア・ノードはオブザーバノードと呼ばれる場合がある。機能性に関し、ピア・ノード２０４も、受信する全てのメッセージを、そのような各メッセージを受信することを許可された各ノードに中継するが、プライベートにサブスペース化されたブロックチェーン上の各ブロックにメッセージをコミットしない。加えて、ピア・ノード２０４および検証者ノードはそれぞれ、外部システムへのアクセスを提供し、そのような外部システムと相互作用する。ピア・ノード（他のノードと同様）は、以下で更に説明するように、エンタープライズ・データベース２０８を維持するように構成されている。この点について、エンタープライズ・データベースには拡張データセットが含まれ、それぞれのノードには、データベース２０８にデータを保存および集約し、ノードのタイプに応じて効率的にデータベース２０８にクエリする能力のような、データベース２０８との相互作用を可能にするロジックおよびプログラミングが含まれる。特に、ピア・ノードは、ノードがデータベース２０８にクエリすることを可能にするロジックおよびプログラミングを備える。検証者ノードは、ノードがデータベース２０８にクエリし、スマートコントラクトにリンクされたイベントを通じてデータベース２０８内にデータを保存および集約することを可能にするロジックおよびプログラミングを備える。データベース２０８によって提供されるデータベース機能性に加え、各ＡＰＩ  １０２は、システム１００が他のデータフォーマットを備えた外部レガシー・システムと統合することを可能にする拡張機能を提供する。例えば、各ＡＰＩ  １０２は、本明細書で説明するブロックチェーン構造とは異なるデータフォーマットで外部レガシー・システムに保存されたデータにアクセスし、エンタープライズ・データベース２０８内にデータをインポートし、そのようなデータをクエリし、そのようなデータをシステム１００に統合し、データセットを本明細書で説明するブロックチェーン構造で��用するのに適したフォーマットに変換し、本明細書で説明するブロックチェーン構造から外部システムによって使用されるのに適したフォーマットにデータをエクスポートするための機能およびプロシージャを含んでもよい。他の各実施形態において、検証ノードはまた、外部システムと相互作用してもよい。サービス・ノード２０６は、特定の各サブスペース内のスマートコントラクトの限られたセットにアクセスできる。サービス・ノード２０６はまた、限られた数のメッセージを受信および中継するが、共通サブスペースにおいて全てのメッセージを受信する。
【００３８】
図３は、本システムの一実施形態によるピア・ノードまたは検証ノード３００の図であり、それぞれのノードに関連付けられた特徴およびロジックを示す。それぞれのノードは、ＬＡＮまたはＷＡＮを介してシステム１００内の他のネットワーク接続された各ノードおよび各コンポーネントに通信するための各インターフェイス、本明細書に列記された機能を実行するための内部ロジック、および変数およびデータを保存するための内部ストレージを備えた１つ以上のサーバに実装してもよい。本明細書で更に説明するように、それぞれのピア・ノードまたは検証ノードは、ピアツーピア（ｐ２ｐ）プロトコルを介して他の各ノードと通信するための通信ロジック３０２を含む。好ましい実施形態において、システム１００内の各ノードは、通信用のメッセージをフォーマットするために、再帰的な長さの接頭辞（ＲＬＰ）などの拡張可能なバージョン化されたバイナリ符号化スキームを使用する。ノードによって送信されたメッセージは、送信ノードのアイデンティティを検証し、なりすましを防止するためにプライベート鍵で署名される。それぞれのピア・ノードまたは検証ノードは、ノードが通知を他の各ノードおよび各システム・コンポーネントに送信したり、他の各システム・コンポーネントにおけるプロシージャおよびサブルーチンの実行を呼び出すために使用できる遠隔プロシージャ呼び出し（ＲＰＣ）プロトコルを実装するためのＡＰＩロジック３０４を更に含む。好ましい実施形態において、各ノードはＪＳＯＮ−ＲＰＣプロトコルを使用する。本明細書で更に説明するように、それぞれのピア・ノードまたは検証ノードは、システムがメッセージおよび各ブロックを検証するために使用するコンセンサス・アルゴリズムを実装するために使用されるコンセンサスロジック３０６を更に含む。一実施形態によれば、システムは、Ｒａｆｔコンセンサス・アルゴリズムを使用するが、他のコンセンサス・アルゴリズムがロジック３０６によって実装されてもよい。他の各実施形態において、ビザンチン・フォールト・トレラント（ＢＦＴ）コンセンサス・メカニズムが使用される。他の各実施形態において、システムは、ローテーション（ｒｏｔａｔｉｏｎａｌ）コンセンサス・メカニズムまたは連合署名を使用してメッセージおよび各ブロックを検証する。コンセンサスロジック３０６は、メッセージを処理し、検証されたメッセージを各ブロックに追加する役割も担う。各ピア・ノードまたは検証ノードは、例えばスマートコントラクトに関連付けられたコードの実行を含む、スクリプトの実行のためのランタイム環境として機能してもよいスクリプト実行用のロジック３０８を更に含む。スクリプト実行用のロジック３０８は、イーサリアム仮想マシン（ＥＶＭ）実装と互換性があり得る。それぞれのピア・ノードまたは検証ノードは、データストア３１０を、データストアを保存、取り出し、およびクエリするための関連ロジックと共に更に含む。データストア３１０は、メッセージ、各ブロック、および関連するメタデータのデータベースリポジトリとして機能する。特に、データストア３１０は、プライベートにサブスペース化されたブロックチェーン・データなどのシステム変数の長期保存用の１つ以上のデータベースを含む。データストア３１０は、それぞれのノードに、そのノードが許可されている全てのサブスペース用のデータへのアクセスを提供する。プライベートにサブスペース化されたブロックチェーンがスマートコントラクトに関連する場合、データストア３１０はスマートコントラクト情報を保存し、各ノードについてのそのような情報の迅速な取り出しを行う。
【００３９】
サービス・ノード２０６は、全てのメッセージを処理するわけではなく（例えば、仮想マシンにおいて全てのメッセージを実行するわけではなく）、それぞれのサブスペースについて完全な状態ツリーを維持しないという点でピアおよび検証ノードと異なる。サービス・ノードは、各サブスペース内のデータのサブセットを受信し、仮想マシンにおいてメッセージを処理するか、あるいはスクリプトの実行結果として生成されたデータ（例えば契約データ）を単に受信することができる。例えば、サービス・ノードは特定のトランザクション（例えば特定の契約）への全てのメッセージを受信するか、あるいはそのトランザクション・データの最新の状態をただ受信してメッセージを全く処理しないことが可能である。サービス・ノード２０６は、サービス・ノードが許可されている検証者またはピア・ノードに状態ツリーの任意の部分を要請する。サービス・ノードは、サブスペース内の全てのメッセージ、または各メッセージのサブセットのみを受信することを許可され得る。サブセットは、例えば、アカウントを送信することによるなど柔軟なフィルタリング規則によって定義されるため、このきめ細かなレベルのアクセスが可能である。
【００４０】
図１に関し、クライアント端末１１４は、アプリケーション・プログラミング・インターフェイス（各ＡＰＩ）のセットであるシステム統合ツール１０２の使用により、システム１００およびコア・モジュール１０４の機能性にアクセスできる。これらのＡＰＩ  １０２は機能呼び出しを含み、クライアント端末１１４は、これらの機能呼び出しを通じて、クライアントのノードの許可を管理し、各遠隔プロシージャ呼び出し（各ＲＰＣ）を実行してシステム・ネットワーク内の各ノードとの接続を確立し、システムを用いてクライアントのアカウントを管理し、本明細書で開示するプライベートにサブスペース化されたブロックチェーン内のデータ記録の内容（例えばスマートコントラクト）を管理する。特に、これらのＡＰＩ  １０２は、ノードを作成、構成、および登録し、本明細書で開示する新規な分散型データ構造と相互作用し、許可およびシステム・ネットワークへのアクセスを構成するために、コア・モジュール１０４の機能性にアクセスするクライアント端末１１４によって呼び出すことができる機能を含む。これらのＡＰＩ  １０２は、データベース・モジュール１０６に保存されたデータにアクセスし、そのようなデータを管理し、そのようなデータに対してクエリを実行するために、データベース・モジュール１０６の機能性にアクセスするクライアント端末１１４によって呼び出すことができる機能を更に含む。ハードウェア鍵管理が使用される各実施形態において、これらのＡＰＩは、プライベート鍵を保存および取り出し、トランザクションに署名するために、ハードウェア鍵管理モジュール１０８の機能性にアクセスするクライアント端末１１４によって呼び出すことができる機能を更に含む。各統合ツール１０２の各ＡＰＩは、プライベートにサブスペース化されたブロックチェーンと直接相互作用する。プライベートにサブスペース化されたブロックチェーン内のデータ記録の作成またはそれとの相互作用に関わるＡＰＩコマンドは何れも、ブロックチェーン・メッセージを生成し、メッセージの識別に使用できるメッセージ・ハッシュ値を返してシステム１００のユーザが後に取り出して閲覧することができるようにする。クライアント端末１１４は、様々な形態をとることができる。例えば、クライアント端末１１４は、各ＡＰＩにデータを提供し、各ＡＰＩ  １０２によって提供される機能を呼び出し、各ＡＰＩからのプロンプトおよびデータを表示することによって、各ＡＰＩ  １０２とインターフェイスする手段を提供するグラフィカル・ユーザ・インターフェイス（エンドユーザによって使用される）であり得る。クライアント端末１１４はまた、外部イベントが発生したときに各ＡＰＩ  １０２を介して外部イベント起動機能を監視する完全に自動化されたソフトウェアであり得る。例えば、クライアント端末１１４は、各ＡＰＩ  １０２を介して台帳機能を起動して取引におけるカウンターパーティをマッチングするマッチングプラットフォームであり得る。
【００４１】
コア・モジュール１０４によって作成されるシステム１００内のそれぞれのノードは、システム１００のネットワークと相互作用するためにノードが使用する特定の情報も保存する。この情報は、ノード内のデータ・ディレクトリに、データベースまたはテーブル構造で保存されてもよい。それぞれのノードは、そのタイプ（検証、ピア、またはサービス）を保存する。システム１００内のそれぞれのノードは名前を更に含み、この名前はシステム内の他の各ノードと共有され、ログファイルに表示される。それぞれのノードは、ノードの完全な証明書であるノード識別子（またはノードＩＤ）を更に含む。代替的に、安全なハッシュを使用してノードＩＤを実装することによって、ハッシュが固定長の値（固定長３２バイトのハッシュ値など）であるという条件で様々な証明書タイプおよび長さを使用できるようにしてもよい。このように、許可契約（または本明細書で更に説明する「チェーンパーム（ｃｈａｉｎｐｅｒｍ）」スクリプト）は、セキュリティを損なうことなく、オンチェーンで効率的に管理できる固定長値を保存するだけで済む。従って、ノードＩＤには、システムのそれぞれの配置のための特定の要件に応じて、ノードの完全な証明書または証明書のハッシュ（オンチェーンでの効率向上とデータの高速処理化のため）を使用できる。
【００４２】
好ましい実施形態において、システム１００内の各ノードはＴＬＳ認証プロシージャを使用するため、セキュリティ証明書はＴＬＳ証明書である。このノードＩＤはノードを一意に識別し、ネットワークに一意である。それぞれのノードは署名アドレスを更に含み、署名アドレスは、ノードのパブリック鍵のハッシュであり、プライベートにサブスペース化されたブロックチェーン内のメッセージおよび各ブロックに署名するために使用される。署名アドレス情報は、オブザーバー・ノード（ピア・タイプ・ノードなど）内にある必要はない。それぞれのノードは、そのノードが検証者として作用する多数のドメイン名、およびそのノードがオブザーバーとして作用する多数のドメイン名を更に含む。ブロックおよびメッセージの作成に参加するのに先立ち、それぞれのノードは自身のセキュリティ証明書（ＴＬＳ証明書など）と署名鍵を持っている必要があり、それらはノードのデータ・ディレクトリに保存されている。この点について、それぞれのノードは２つのプライベート鍵を有する。１つはＴＬＳ認証プロシージャ用のプライベート鍵であり、もう１つは本明細書に記載のブロックの作成および投票プロセスに従って、とりわけブロックや投票に署名するためのプライベート鍵（例えばＥＣＤＳＡプライベート鍵）である。
【００４３】
図１および図２を参照し、システム１００は、プライベートにサブスペース化されたブロックチェーン・データの保存のための１つ以上のデータベース２０８を含むデータベース・モジュール１０６を更に含む。データベース・モジュール１０６は、プライベートにサブスペース化されたブロックチェーンから保存のための共通データベースフォーマットへの一方向の同期を提供する。データベース・モジュール１０６は、補足データをプライベートにサブスペース化されたブロックチェーン・データに追加することも可能にする。データベース・モジュール１０６は更に、１つ以上のデータベースに保存されたデータに対して複雑なデータクエリおよびアナリティクスを実行する。データベース・モジュール１０６は、コア・モジュール１０４と同じサーバ上にあってもよいし、別個のサーバ上にあってもよい。
【００４４】
コア・モジュール１０４は、ローカルノードに関連付けられた各アカウントの作成を提供する機能を更に含む。それぞれのアカウントは、プライベートにサブスペース化されたブロックチェーン上のユーザのアイデンティティを定義する。加えて、プライベートにサブスペース化されたブロックチェーンの各ブロック内に保存されているデータがスマートコントラクトまたは他の自己実行／自己執行スクリプトに関連する場合、アカウントを使用してそれらのスマートコントラクトおよび／またはスクリプトに関して各アクターを識別する。アカウントは、メッセージおよび自己実行スクリプト（スマートコントラクトなど）を送受信するための一意の識別子である。それぞれのアカウントは、そのパブリック鍵に対応するアドレスによって参照される。それぞれのアカウントはまた、プライベートにサブスペース化されたブロックチェーン内のスクリプトに署名して相互作用する際に使用する関連プライベート鍵を有する。アカウントは更に、プライベートにサブスペース化されたブロックチェーン上の各ユーザのアイデンティティのそれぞれを定義する。プライベートにサブスペース化されたブロックチェーンを使用して、例えば、スマートコントラクトを実装する場合、アカウントを使用してスマートコントラクトに関係する各パーティを識別する。
【００４５】
コア・モジュール１０４は、メッセージを受信および中継し、メッセージをプライベートにサブスペース化されたブロックチェーンにコミットする能力を含む、他のネットワーク・ノード１１２ａから１１２ｄとの通信およびそれらの間の通信に必要な機能性をノードに提供するロジックを更に含む。システム１００用の通信ネットワークは、ネットワーク内のそれぞれのノードの既知の各アイデンティティを備えたピアツーピア・ネットワークとしてセットアップされる。本明細書で説明するように、各ノード間の接続はＴＬＳ証明書を使用して認証され、ＴＬＳ証明書が承認済みリストに含まれるノードのみがネットワークへの接続を許される。好ましい実施形態において、コア・モジュール１０４は、メッセージまたはコマンドを発信するパーティ／ユーザの識別子、およびカウンターパーティ／ユーザの識別子に基づいて、メッセージまたはコマンド用のサブスペースを決定する。例えば、パーティＡがメッセージまたはコマンドを送信し、そのメッセージまたはコマンドのカウンターパーティＢをパーティＢとして指定する場合、コア・モジュール１０４は、そのメッセージまたはコマンドはＡＢサブスペース上に送信されるべきであると判断する。
【００４６】
図４は、本発明の一実施形態による、プライベートにサブスペース化されたブロックチェーン内のブロック４００の図である。それぞれのブロックはデータ用のリポジトリとして機能し、プライベートにサブスペース化されたブロックチェーン内の前のブロックへのリンクを含む。それぞれのブロック４００は、ブロックの内容を検証するために使用される状態情報を有するヘッダ４０２を含む。本明細書でより詳細に説明するように、ヘッダは、ブロック内の各サブスペースおよび他のデータに対応する１つ以上の基礎となるハッシュ値に基づくグローバル・ハッシュ値を含む。好ましい実施形態において、グローバル・ハッシュ値は、マークル・ツリーなどのハッシュ・ツリーの状態ルートであり、ツリーの下にある各葉は各サブスペースを表す。ヘッダはメッセージ・ルート（ｍｅｓｓａｇｅ  ｒｏｏｔ）を更に含み、メッセージ・ルートは、ブロックに含まれる全てのメッセージの概要であり、プライベートにサブスペース化されたブロックチェーンの内容によってトリガされる各イベントに基づいて更新される。それぞれのサブスペースは、サブスペースの状態ルートに加え、サブスペースのメッセージ・ルート、受信ルート（ｒｅｃｅｉｐｔ  ｒｏｏｔ）、および実行に使用される「ガス」の量（つまり、トランザクション実行のための計算ステップ数）を含む。メッセージ・ルートおよび受信ルートは、メッセージおよび受信確認の追加によってトリガされたイベントに基づいて更新されるツリー・ルート・ハッシュであり、これらのメッセージおよび受信確認に含まれるデータに基づく。例えば、メッセージ・ルートおよび受信ルートは、ブロックがマークル・ツリー構造内のサブスペースについて確認する全てのメッセージ（または受信ルートの場合はメッセージ受信確認）を追加し、ルート値を取得することによって計算されるマークル・ツリー・ルート・ハッシュであってもよい。ヘッダは、ブロックの検証に使用される暗号署名を更に含む。それぞれのブロックは、１つ以上のサブスペース、例えば、サブスペースＡ、ＢからＮなどに分割されたデータ・ペイロードを更に含む。これらのサブスペースは、ユーザの定義されたサブセットのみがアクセスおよび追加を許可されている共有ブロックチェーン内の切り離された領域である。このようにして、サブスペースは、参加者が許可された参加者のみが受信する記録およびデータを保存するためのプライベートエリアを作成する。サブスペースは、そのサブスペースに固有であり、アクセス許可によって、そのサブスペースへのアクセスが許可されているノードのみがアクセスできるように保護されているロジック（例えば、自己実行スクリプト、スマートコントラクト）およびデータセット（例えば、メッセージや受信確認など、一連のデータ記録）を含む。それぞれのサブスペースは、そのサブスペースに対して権限を付与されているノードのみがアクセスでき、ネットワーク上の単一のパーティ、複数のパーティ、または全てのパーティを含んでもよい。この点について、本発明のプライベートにサブスペース化されたブロックチェーンは、ブロックチェーンの有効性と整合性を確保するためにそれぞれのブロックの内容についてのパブリック可視性��依存する従来のブロックチェーン実装とは大きく異なる。本明細書で更に説明するように、プライベートにサブスペース化されたブロックチェーンの各サブスペースは、特定のトランザクション（例えば、２つのパーティ間のクレジット・デフォルト・スワップ（ＣＤＳ））に基づいて分離されるか、あるいはそのような各サブスペースにアクセスできるパーティまたは各パーティに基づいて分離されてもよい。例えば、それぞれのサブスペースは、あるグループの各パーティ間の一連のトランザクションを保存し、サブスペース内のメッセージリストがそのような各トランザクションの完全な履歴を提供するようにしてもよい。トランザクションに関係する各パーティのみが、そのトランザクションに対応するサブスペースへのアクセス許可を有し、メッセージおよびトランザクションがシステムによって伝播されると、それらのパーティに対応するノードのみがそれらのサブスペースの内容を受信する。この点について、これらのサブスペースに保存されたデータは別々のデータベースに保存され、ネットワーク内の各ノードによって別々に同期され得る。
【００４７】
一実施形態において、サブスペースのデータはアカウント毎に整理される。アカウントはアドレスによって参照され、メッセージノンス（何かを一意に識別するために使用される乱数または擬似乱数、この場合はメッセージ記録）、スクリプト記述コードまたは「バイトコード」（すなわち、スマートコントラクトコード）、およびアカウントがストレージに保持してもよい任意の鍵と値のペアを有する。アカウントには（１）ユーザアカウント、および（２）スクリプト／スマートコントラクトアカウントの２種類がある。ユーザアカウントは、システム内にメッセージを送信するためにユーザが使用するアカウントである。ユーザのアカウントのアドレスは、ユーザのパブリック鍵から得られる。ユーザアカウントには、バイトコードまたは鍵と値のペアは何ら関連付けられていない。一方、スクリプト／スマートコントラクトアカウントは、スクリプト記述コード／バイトコードを有し、鍵と値のペアを永続的データに保存してもよい。スクリプト／スマートコントラクトアカウントのアドレスは、生成アカウントのアドレスとノンスから得られるが、スクリプト／スマートコントラクトアカウントのアドレス（パブリック鍵）に一致するプライベート鍵は知られていない。このような構成においては、ユーザは送信者アカウントがスクリプト／スマートコントラクトであるメッセージを送信することはできない。
【００４８】
図８は、本発明の一実施形態による、プライベートにサブスペース化されたブロックチェーン内のブロックの別の図であり、このブロックのペイロード内の各サブスペースの構成を示す。ブロック・ヘッダ８０２に加え、上述したように、ブロック８００は、そのサブスペースにアクセスできる各パーティに基づいて分割された複数のサブスペースを含む。各サブスペースは、単一のパーティのみが許可され、データにアクセスできる単一パーティ・サブスペース８０４を含み、単一パーティ・サブスペース８０４は、パーティＡに対応するサブスペース８０４ａ、パーティＢに対応するサブスペース８０４ｂ、およびパーティＣに対応するサブスペース８０４ｃを含む。単一パーティ・サブスペースは、証券取引所からの株式購入、商品取引、医療記録など、単一のパーティに関わる記録またはトランザクションを含み得る。ブロック８００内の各サブスペースは、２つのパーティがそれぞれ許可され、データにアクセスできるバイラテラル・サブスペース８０６を更に含む。示された例において、これらのサブスペースは、パーティＡおよびＢに対応するバイラテラル・サブスペース８０６ａｂ、パーティＡおよびＣに対応するバイラテラル・サブスペース８０６ａｃ、およびパーティＢおよびＣに対応するバイラテラル・サブスペース８０６ｂｃを含む。バイラテラル・サブスペース８０６は、クレジット・デフォルト・スワップまたはエクイティ・スワップなど、２つのパーティに関わる記録またはトランザクションを含み得る。共通サブスペース８０８は、参照データ、サービス・ノード許可リスト、システム１００内のそれぞれのノードのノードＩＤと対応するタイプ、およびそれぞれのノードに対する許可を提供するアイデンティティ・ディレクトリ（またはピア・レジストリ）、トランザクションマネージャ、および全てのパーティとシステム内の各ノードが一般に使用する、またはノードがアクセスおよび各ノードによる許可決定を行うのに必要な他の情報およびスクリプトを含む。トランザクションマネージャは、メッセージ・スケジューリング・サービスを提供する。これによってユーザは、メッセージが後の時点で、または特定のイベントが発生したときに自動的に実行されるようにスケジュールすることができる。このメッセージ・スケジューリング・サービス機能性は、他のコンポーネントによっても提供され得る。メッセージ・スケジューリング・サービスは、例えば、取引契約（時間でトリガされるインスタンス）のためのクーポンの支払いを自動化したり、エンティティ登録（イベントでトリガされるインスタンス）でエンティティ名が更新されたときに取引契約における参照エンティティの名前を変更するのに使用され得る。共通サブスペースは、スクリプト／スマートコントラクトバイトコード、アプリケーション・バイナリ・インターフェイス（ＡＢＩ）、スマートコントラクトファクトリ、データベース構成情報、およびその他のドメインまたはサブスペースの状態情報を追加的に含んでもよい。１つ以上のパーティの他の組み合わせに関わる追加的なサブスペースが可能である。例えば、図１９に示すように、特定のドメインに複数のサブスペースを含めてもよい。例えば、バイラテラルドメインには２つのパーティ（例えばパーティＡとパーティＢ）がアクセス可能であり、どちらのパーティもこのドメインの検証者として作用する。このドメイン内で、両パーティはドメイン内の全てのサブスペースにアクセスできる（プライバシーを確保するために、何れかのパーティについての任意の真のプライベートサブスペースが別個のプライベート・ドメイン内に配置される）。ドメイン内で、それぞれ異なるサブスペースを使用して、別々のグループの記録、または別々のトランザクションを指定できる。例えば、バイラテラルドメインにおいて、様々な資産クラスのトランザクションを処理するために複数のサブスペースが作成され得、それぞれのサブスペースが様々な資産クラスに対応するため、各パーティはそのようなトランザクションを別々に独立して処理および追跡できる。
【００４９】
従来のブロックチェーン・データ構造内の各ブロックと同様に、それぞれのサブスペース内の各データ記録は、データ（パーティ間の特定のトランザクションに対応するデータなど）とそのデータに基づく鍵（そのデータに基づくハッシュ値など）、およびサブスペース内の前のデータ記録へのリンクを含む。サブスペースを使用することにより、ノードは、データを確実に同期および検証しながら、同時にそれぞれ異なる各ユーザに関連するデータセットを切り離しておくことができる。更に、サブスペースを使用することにより、システム１００は、それぞれ異なる各サブスペースにおけるメッセージの同時処理を提供できる。従来のブロックチェーンにおいて、ブロックチェーンの整合性を保持するために、メッセージおよびトランザクションは順次処理されなければならない。プライベートにサブスペース化されたブロックチェーン内のサブスペースにより、それぞれ異なる各サブスペース内のメッセージおよびトランザクションを同時に処理することができ、同じサブスペース内のメッセージを順次処理するだけでよくなる。仮想マシン内でメッセージを処理するために、ノードは、それぞれが最新の状態にある、メッセージ起動が関係する全てのアカウント（例えば、バイトコードおよびストレージを含むスマートコントラクト）にアクセスする必要がある。そのため、それぞれのメッセージがトランザクションの状態を変更し得、それによって後続メッセージ実行の結果に影響を及ぼす可能性があることから、同じサブスペース上の各メッセージを順次処理する必要がある。とは言え、メッセージは特定の他のサブスペース内に特定の呼び出しを行うことができ、このことはデータアクセスに関する追加的な要件を生じさせる。例えば、メッセージは、共通サブスペース内およびドメイン内の他の各サブスペース内に呼び出しを行ってもよい。
【００５０】
パーティの各ノード上で維持されるブロックのそれぞれのコピーは、各サブスペースによって作成されたプライバシーおよびアクセス制限を反映する。特に、パーティの各ノードは、パーティおよびノードが許可されている各サブスペース内のデータのみを含む各ブロックのコピーを含む。図８の例に示すように、パーティＡノード上で維持されるブロック８００のコピーには、パーティＡが許可され、アクセスできる各サブスペース内にあるデータのみが含まれる。つまり、パーティＡノードは、単一パーティ・サブスペース８０４ａ、バイラテラル・サブスペース８０６ａｂおよび８０６ａｃ、および共通サブスペース８０８のみからのデータを含むブロック８００のコピーを含む。パーティーＡノードは、パーティーＡが許可されていない各サブスペースからのデータを全く持たない。つまり、パーティーＡノードは、ユニラテラル・サブスペース８０４ｂまたは８０４ｃ、またはバイラテラル・サブスペース８０６ｂｃからのデータは全く持たない。同様に、パーティＢノード上で維持されるブロック８００のコピーには、パーティＢが許可され、アクセスできる各サブスペース内にあるデータのみが含まれ、パーティＢが許可されていない各サブスペースからのデータは含まれない。つまり、パーティＢノードは、単一パーティ・サブスペース８０４ｂ、バイラテラル・サブスペース８０６ａｂおよび８０６ａｃ、および共通サブスペース８０８からのデータを含むブロック８００のコピーを含むが、ユニラテラル・サブスペース８０４ａまたは８０４ｃ、またはバイラテラル・サブスペース８０６ａｃからのデータは全く持たない。更に同様に、パーティＣノード上で維持されるブロック８００のコピーには、パーティＣが許可され、アクセスできる各サブスペース内にあるデータのみが含まれ、パーティＣが許可されていない各サブスペースからのデータは含まれない。つまり、パーティＣノードは、単一パーティ・サブスペース８０４ｃ、バイラテラル・サブスペース８０６ａｃおよび８０６ｂｃ、および共通サブスペース８０８からのデータを含むブロック８００のコピーを含むが、ユニラテラル・サブスペース８０４ａまたは８０４ｂ、またはバイラテラル・サブスペース８０６ａｂからのデータは全く持たない。ノードは、ノードが許可されていないサブスペース用のデータを受信しないため、各サブスペースは完全にプライベートのままであり、そのようなデータにアクセスできないパーティまたはノードにデータが不注意に開示されるリスクがない。
【００５１】
図９は、本発明の一実施形態による、サブスペースの更新に基づいたプライベートにサブスペース化されたブロックチェーンにおける各ブロックの作成を示す。最初に、パーティＡおよびパーティＢからのネットワーク内の各ノードは、２つのパーティ間のトランザクションに関するメッセージ９１２および９１４を交換し、その結果、これらの一連のトランザクションの状態ＡＢ２が得られる。同様に、パーティＡおよびパーティＣは、それらの間のトランザクションに関するメッセージ９２６を交換し、その結果、これら２つのパーティ間のトランザクションの状態ＡＣ１が得られる。これらのメッセージのコンセンサスおよび検証の後、これらのトランザクションとそれに関連する情報の安全な記録として、新しいプライベートにサブスペース化されたブロックチェーン９００内の新しいブロック９０２が作成される。プライベートにサブスペース化されたブロックチェーン９００およびそれに含まれる各ブロックは、パーティＡとパーティＢとの間のトランザクションに対応するサブスペースＡＢ  ９０８と、パーティＡとパーティＣとの間のトランザクションに対応するサブスペースＡＣ  ９１０の２つのバイラテラル・サブスペースを有する。ブロック９０２は、メッセージ９１２および９１４をサブスペースＡＢ  ９０８に記録し、メッセージ９２６をＡＣ  ９１０に記録する。好ましい実施形態において、特定のサブスペース内のそれぞれのメッセージは、ブロックチェーン原理に基づくブロックの形態でサブスペース内に保存され、チェーン内のそれぞれのブロックは関連するハッシュ値を有し、前のブロックのハッシュ値を使用して現在のブロックのハッシュ値を計算し、これによって各ブロック間のリンクを作成する。例えば、第１のメッセージ９１２は、サブスペースＡＢ  ９０８に対応するブロックチェーン内の第１のブロックとして保存され、第２のメッセージは、そのブロックチェーン内に後続として記録される。より具体的には、特定のサブスペース内のメッセージは、プライベートにサブスペース化されたブロックチェーンの形態のサブスペース内に保存される。本明細書で開示するように、プライベートにサブスペース化されたブロックチェーンは、（同様にプライベートにサブスペース化されたブロックチェーンの形態の）追加的なサブスペースを持つことができる。加えて、状態ルートＡＢ２  ９０８ａは、ＡＢサブスペース内に保存されたメッセージ（この時点でメッセージ９１２および９１４からなる）に基づいて生成される。状態ルートは、サブスペース内のデータに基づく状態鍵であり、通常、サブスペース内のデータに対して実行されたハッシュ関数の結果であるハッシュ値である。例えば、それぞれのサブスペースについての状態ルートは、マークル・ツリーなどのハッシュ・ツリーのルートであってもよく、本明細書で更に説明するように、これらの状態ルートは、全てのサブスペースについての状態ルートを含むより大きなハッシュ・ツリーの一部であってもよい。同様に、状態ルートＡＣ１  ９１０ａは、ＡＣサブスペース内に保存されたメッセージ（この時点でメッセージ９２６からなる）に基づいて生成される。本明細書でより詳細に説明するように、これらの状態ルー���は、ブロック・ヘッダに組み込むための特定のサブスペース内でリーダー・ノードによって生成される。このようにして、各ブロックは、それぞれのサブスペースから最も最近送信された状態情報を含む。加えて、以下で更に説明するように、プライベートにサブスペース化されたブロックチェーン内のブロックに含まれる前に、特定のサブスペース内のそれぞれ個々のメッセージまたはトランザクションについて各検証ノード間でコンセンサスが達成される。結果が常に予測可能で信頼できるものであることを確実にするために、それぞれ個々のメッセージはコンセンサス・プロセスを経なければならない。これは、一部には、検証者ノードが、受信するメッセージの順序を確実に特定できないことによる。
【００５２】
ブロック内の各サブスペースについての新しい状態ルートが生成されると、ブロックについてのグローバル状態ルートも更新される。これは、各サブスペースについての状態ルートが、グローバル状態ルートの値をもたらすハッシュ関数への入力として機能するからである。図１０は、サブスペースの状態ルートが、ブロックについてのグローバル状態ルートの値にどのように影響するかを示す。図９内の各ブロックと同様に、図１０のブロック１０００は、サブスペースＡＢ  １０１２とサブスペースＡＣ  １０１４の２つのサブスペースを含む。これらのサブスペースの各々は、状態ルート、すなわちＡＢ状態ルート１００４およびＡＣ状態ルート１００６をそれぞれ有する。特定のサブスペース内に追加的なサブスペース（事実上「サブ・サブスペース」）がない場合、その特定のサブスペースについての状態ルートは、チェーン内の最新ブロックについてのハッシュ値であってもよい。サブスペース内に１つ以上の複数のサブスペース（すなわち、複数のサブ・サブスペース）がある場合、そのサブスペースについての状態ルートは、それら１つ以上のサブスペースの状態ルート値に基づく、マークル・ツリーのようなハッシュ・ツリーのルートであってもよい。このように、それぞれのサブスペースは、図１０に示すように、再帰的なデータ構造要素であり、階層ブロックチェーン構造からなり得る。サブスペースＡＢ  １０１２は、その中に複数のサブスペース１００８を有し、これらのサブ・サブスペースの状態ルートは、ＡＢ状態ルート１００４を生成するハッシュ関数への入力として機能する。同様に、サブスペースＡＣ  １０１４は、その中に複数のサブスペース１０１０を有し、これらのサブ・サブスペースの状態ルートは、ＡＣ状態ルート１００６を生成するハッシュ関数への入力として機能する。サブスペースの検証者ノードは、サブ・サブスペースの状態ルートを受け入れ、または拒否する能力を有する。
【００５３】
図９の例に示すように、後続のメッセージ９１６および９１８は、ＡＢサブスペース内のトランザクションに対して生成され、その結果、ＡＢサブスペース９０８についての新しい状態ルートＡＢ４  ９０８ｂが生成される。これらのメッセージおよび新しい状態ルートは、プライベートにサブスペース化されたブロックチェーン９００内の新しいブロック９０４に保存される前に検証される。同様に、ＡＣサブスペース９１０内のトランザクションに対して後続のメッセージ９２８が生成され、その結果、ＡＣサブスペースについての新しい状態ルートＡＣ２  ９１０ｂが生成される。メッセージ９２８および新しい状態ルート９１０ｂも、ブロック９０４内に保存される前に検証される。図９に更に示すように、更新された状態ルート（ＡＢサブスペース９０８内の状態ルートＡＢ６  ９０８ｃおよびＡＣサブスペース９１０内の状態ルートＡＣ４  ９１０ｃ）に対応する追加的なメッセージ（ＡＢサブスペース９０８内の９２０、９２２およびＡＣサブスペース９１０内のメッセージ９３０および９３２）が生成され、これらの追加的なメッセージおよび状態ルートは検証され、チェーン内の新しいブロック（例えば、ブロック９０６）に追加される。このプロセスが継続され、追加的なメッセージがサブスペース内で交換されるにつれて、追加的なブロックがプライベートにサブスペース化されたブロックチェーン９００に追加される。
【００５４】
好ましい実施形態において、新しいブロックは、それぞれのサブスペースから最も最近送信された状態情報に基づく固定された時間間隔で作成される。代替的に、新しいブロックは、メッセージの交換に基づいて作成されてもよい。例えば、プライベートにサブスペース化されたブロックチェーン内のサブスペースに関連するメッセージが送信されるたびに、新しいブロックが作成されてもよい。新しいまたは既存のブロックチェーンのための新しいブロックの作成はまた、システム１００の外部のイベントを含む他のイベントに基づいてトリガされてもよい。
【００５５】
ブロックチェーン内の初期ブロックであるジェネシス・ブロックは、ブロックチェーン上の全てのノードについて同じ構成ファイルに従って作成される。ジェネシス・ブロックは、他の全てのブロックとは異なり、署名されておらず、同様に署名されていない任意の数のメッセージを含んでもよい。例えば、「共通」サブスペースを含む「パブリック」ドメインの場合、ジェネシス・ブロックは、許可を管理するための専用スクリプトまたはスマートコントラクト（例えば「チェーンパーム」スクリプト）を配置し、その専用スクリプトまたはスマートコントラクトにおける検証者ノードの初期セットを登録するメッセージを含む。
【００５６】
このシステムは、プライベートにサブスペース化されたブロックチェーン用の分散型コンセンサス・アルゴリズムを採用している。このアルゴリズムは、悪意のあるアクターに対する強力な暗号保護を用いて設計されており、ビザンチン・フォールト・トレランス（ＢＦＴ）保護を使用する。好ましい実施形態によれば、コンセンサス・アルゴリズムは以下のように機能する。まず、サブスペース内で検証ノードとして許可されている各ノードが、リーダー・ノードを選出する。リーダー・ノードはその後、フォロワー・ノードとして作用する、サブスペース内の残りの各検証ノードにメッセージおよびブロックをアナウンスする機能を果たす。各フォロワー・ノードは、暗号署名の形態で承認してリーダーに応答することにより、新しいメッセージおよびブロックを承認する。過半数の（５０％を超える）各フォロワー・ノードが承認すると、リーダー・ノードは、新しいメッセージの有効性または新しいブロックの確認を各フォロワー・ノードにアナウンスする。コンセンサス・プロセスに参加しないネットワーク内の他の各ノードは、メッセージまたはブロックに関する署名を検証することにより、メッセージまたはブロックが過半数の検証ノードによって承認されたことを、管理者による承認を必要としない方法で検証できる。
【００５７】
図１１Ａから図１１Ｄは、本発明の一実施形態による、サブスペースについてのメッセージ伝播および検証プロセス、並びに後続のブロックの作成プロセスを示す。図１１Ａは、初期トランザクション作成メッセージの生成および通信を示す。図１１Ａに示された例において、パーティノードの図１１０４、１１０６、および１１０８は、パーティ、この場合はそれぞれパーティＡ、パーティＢ、およびパーティＣによって管理されるノードのクラスタを表す。ノードのクラスタ１１０４、１１０６、および１１０８およびサービス・ノード１１０２は、ピアツーピア通信ネットワークを介して通信可能に結合される。サービス・ノード１１０２は、パーティＡとパーティＢとの間のトランザクションのためのトランザクション作成メッセージを送信する。トランザクション作成メッセージは、トランザクションの条件を含み、自己実行スクリプトまたはスマートコントラクトの形態を取ってもよく、関連するサブスペース識別子、この場合はＡＢサブスペースを更に含む。特に、パーティＣはＡＢサブスペースについて許可されておらず、従ってＡＢサブスペース上のトランザクション情報にアクセスできないため、本明細書で更に説明するように、サービス・ノード１１０２はトランザクション作成メッセージをのパーティＣノードのクラスタ１１０８に送信せず、パーティＡノードのクラスタ１１０４およびパーティＢノードのクラスタ１１０６は、パーティＣノードのクラスタ１１０８にトランザクション作成メッセージを伝播しない。その結果、パーティＣノードのクラスタは、トランザクション作成メッセージを受信せず、トランザクション作成メッセージを認識しない。
【００５８】
図１１Ｂおよび図１１Ｃに示された例に図示するように、それぞれのメッセージは、検証およびブロック作成プロセスを促進するために、関連するサブスペース上で許可されているネットワーク内の全ての検証ノードに伝播される。まず、サービス・ノードは、メッセージに関連するサブスペースにおいて許可されている、サービス・ノードが接続されている全ての検証ノードにメッセージを送信する。図１１Ｂに示すように、サービス・ノード１１１０および１１０２は、メッセージを送信するためのエントリポイントとして使用される非検証ノードである。サービス・ノードＡ  １１１０は、サービス・ノード１１０２からトランザクション作成メッセージを受信し、メッセージがＡＢサブスペースに関係することを識別する。その結果、サービス・ノードＡ  １１１０は、メッセージをサービス・ノード１１０２からＡＢサブスペース内の全ての検証ノードに伝播する。特定のサブスペースについての検証ノードのＩＤは、プライベートにサブスペース化されたブロックチェーン上のブロック内に含まれるか、またはプライベートにサブスペース化されたブロックチェーン上にあるスクリプトまたはスマートコントラクトによって管理されてもよい。例えば、一実施形態において、許可を管理するための専用スクリプトまたはスマートコントラクト（例えば、「チェーンパーム」スクリプト）が、ジェネシス・ブロック内の共通サブスペース内に配置される。ノードを許可するには、チェーンパーム契約に、新しいノードの名前、パブリックトランスポート層セキュリティＩＤ（ＴＬＳ−ＩＤ）、パブリック署名アドレス、およびノードがアクセスおよび／または検証することを許されたドメインよびサブスペースのリストと共にメッセージを送信する。検証者許可はドメイン・レベルで付与され、オブザーバー（非検証者）アクセスはサブスペース・レベルで付与できる。他のノードからの接続を受け入れる全てのノードが少なくとも「共通」サブスペースにアクセスでき、そのことから、それらのノードがチェーンパーム契約にアクセスして検証できることが想定されている。ブロックチェーン内のデータによって、ネットワーク上の全てのノードが確実に同期されるため、全てのノードがチェーンパーム契約に対して一貫したビューを持ち、それに応じてノード接続を受け入れ／拒否する。図１１Ｂに示された例において、サーバ・ノードは、パーティＡノードのクラスタ１１０４内のノードＡ１（１１１２ａ）およびＡ２（１１１２ｂ）と、パーティＢノードのクラスタ１１０６内のノードＢ１（１１１４ａ）およびＢ２（１１１４ｂ）をサブスペースのための検証ノードとして識別する。繰り返すが、パーティＣノードはＡＢサブスペースで許可されていないため、メッセージを受信しない。
【００５９】
次に、関連するサブスペースにおいて許可された、接続された各検証ノードへのサーバ・ノードによるメッセージの伝播に続き、各検証ノードは、Ｒａｆｔコンセンサスプロトコルなどのコンセンサス・プロセスを通じたメッセージの検証に進むが、ローテーション（ｒｏｔａｔｉｏｎａｌ）リーダーメカニズムなど、他のコンセンサス・アルゴリズムを使用してもよい。図１１Ｃに示すように、ランダム化プロセスを使用して、ノードＡ１（１１１２ａ）である、コンセンサス・プロセスのためのリーダー・ノードを選出する。選出されたリーダーは、関連するサブスペース上で許可されている、リーダーが接続されている他の全ての検証ノードによる投票のために受信したメッセージを提案する。示された例において、リーダー・ノードＡ１（１１１２ａ）は、許可されたサブスペース内の他の各検証ノード、すなわち、パーティＡノードのクラスタ１１０４内のノードＡ２（１１１２ｂ）とパーティＢノードのクラスタ１１０６内のノードＢ１（１１１４ａ）およびＢ２（１１１４ｂ）による投票のためにサービス・ノード１１０２から受信したメッセージを提案する。投票期間の終わり（特定のコンセンサスプロトコルによって決定され、一定時間量の経過（タイムアウト）、または全て若しくは十分な数の投票検証ノードからの投票の受信によって決定されてもよい）であって、十分な数の投票が受信されたと想定した場合には、状態ルートが送信されてブロック・ヘッダ内に含められる。
【００６０】
サブスペースについての状態ルートがブロック・ヘッダに含められることについて承認されると、ネットワークのための更新されたブロックを作成できる。一実施形態によれば、システム用の検証ノードの１つが、ブロックを作成するためのリーダーとしてランダムに選出される。全てのサブスペース・リーダーはその後、それぞれの状態ルートをブロック・リーダーに送信する。図１１Ｄに示された例において、パーティＣノードのクラスタ１１０８内のノード（例えばノードＣ１）は、ブロックの作成のためのリーダーとしてランダムに選出される。従って、ＡＢサブスペース・リーダーＡ１（１１１２ａ）などの全てのサブスペース・リーダーは、それぞれの選出された状態ルートを、ブロック・リーダーである、パーティＣノードのクラスタ１１０８内のノードＣ１に送信する。ブロック・リーダーとして、ノードＣ１は各サブスペースからの状態ルートを組み合わせ、グローバル状態ルートおよび更新されたブロック・ヘッダを決定し、ネットワーク内の各フォロワー・ノードに更新されたブロック・ヘッダの承認を要請する。各フォロワー・ノードは、ブロック・リーダーからの更新されたブロック・ヘッダを、自身のブロック・ヘッダの決定と比較し、ブロック・リーダーにその承認を表明する。承認を受信すると、ブロック・リーダー（この例ではノードＣ１）は、全てのサブスペースからの状態ルートを組み込んで、プライベートにサブスペース化されたブロックチェーン内のそのポイントのオフィシャル・ブロックを作成する。
【００６１】
図１２Ａから図１２Ｇは、本発明の一実施形態によるコンセンサス・プロセスを更に詳細に示す。上記の通り、システムは全体として、通常、図１９に示すように、複数のドメインおよびサブスペースで構成される。それぞれのドメインは１つ以上のサブスペースを含み、それぞれのサブスペースは１つのドメインにだけ含まれる。それぞれのドメインは、ジェネシス・ブロックから始まる自身のプライベートにサブスペース化されたブロックチェーンを有する。コンセンサス・プロセスは各ドメインに対して実行される。その意味で、サブスペースは直接リーダー・ノードまたは各フォロワー・ノードを持たないが、そのサブスペースを含むドメインはリーダー・ノードおよび各フォロワー・ノードを持つ。それぞれのドメインは、自身の検証者ノードのセットを有する。１つの検証者ノードは、１つ以上のドメインを検証できるが、コンセンサス・プロセスはドメインごとに個別に実行される。つまり、２つのドメインを検証するある検証者ノードは、コンセンサス・プロセスの２つの別々のインスタンスを実行する。その結果、この検証者ノードは、一方のドメイン上でリーダーシップを「獲得」するが、他方のドメイン上ではフォロワーとして作用し得る。好ましい実施形態において、コンセンサス・プロセスの実装は１つのみであり、これは全てのドメインについて同様である。
【００６２】
好ましい実施形態において、システムによって使用されるコンセンサス・プロセスは、示されるようにビザンチン・フォールト・トレラント（ＢＦＴ）Ｒａｆｔコンセンサス・プロセスである。このプロセスは、リーダーを決定するための選出プロセスおよび検証プロセスを含む。図１２Ａから図１２Ｃは、本発明の一実施形態による選出プロセスを示す。この例に示すように、特定のサブスペースについてのメッセージおよびトランザクションを検証する５つの検証ノードＡからＥ（ノード１２０２、１２０４、１２０６、１２０８、および１２１０）がある。プロセスの開始時には、リーダー・ノードはなく、全てのノードがフォロワーと見みなされる。それぞれのフォロワー・ノードは、ランダムな時間量だけ待ってから（「タイムアウト」）、選出開始を試み、他の各検証ノードからの確認投票を要請する候補者ノードとして自身を指定する。図１２Ｂに示すように、ノードＡ（１２０２）は、他の各検証ノードよりも前に（または任意の他の検証ノードから確認投票の要請を受信する前に）タイムアウトに達するため候補者ノードとなり、関連サブスペース内で許可されている、ノードＡ（１２０２）が接続されているそれぞれの検証ノードに要請を送信する。この関連サブスペース内では、候補者ノードが確認投票、すなわち「はい（ｙｅｓ）」投票を要請する。最初に１つのノードのみが候補になる見込みを最適化するために、それぞれのノードのタイムアウトは、十分に長い時間にわたって（ネットワーク待ち時間条件に応じて）ランダム化される。それぞれのノードは、要請を最初に受信する候補者ノードに対して確認投票、すなわち「はい」投票を送信する。言い換えれば、それぞれのフォロワー・ノードは、選出の要請で最初にそのフォロワー・ノードにコンタクトする候補者に投票する。十分な数の投票を受信する候補者がリーダーとして選出される。選出されるには、過半数のフォロワー投票が必要なことに留意されたい。加えて、投票プロセスの全ての確認の整合性を確保するために、各フォロワーによる投票は、投票を生成するノードによって署名され、全てのフォロワー投票署名が検証される。フォロワー投票が送信された後、十分な数の確認投票を有する候補者が、選出結果を確認し、フォロワーがリーダーとして選出されたことを確認するメッセージをそのフォロワーに送信する。図１２Ｃに関し、タイムアウトし、任意の他のフォロワー・ノードより前に投票要請を送信したノードＡ  １２０２は、４つのフォロワー・ノードＢ（１２０４）、Ｃ（１２０６）、Ｄ（１２０８）、およびＥ（１２１０）のそれぞれから確認投票を受信する。ノードＡ  １２０２が、投票内の署名を検証し、投票検証後に、ノードＡ  １２０２をリーダーとして識別する選出結果を確認する確認メッセージを４つのフォロワー・ノードに送信すると、各フォロワー・ノードはノードＡが現在のリーダーであるという情報を保存する。トランザクションがない場合、選出されたリーダーは、一定の間隔で全てのフォロワーに定期的なハートビートメッセージを送信する。ノードは、選出されたリーダー・ノードから有効な定期的メッセージを受信する限り、フォロワーのままである。現在のリーダーが応答せず、定期的なハートビートメッセージを送信しない場合は、新しい過半数投票を得るために新しいリーダー選出が行われる。
【００６３】
特定のブロックまたは特定のドメインの各検証ノードの中からリーダーが選出されると、各ノードはサブスペース内でトランザクション検証およびブロック作成プロセスを継続してもよい。図１２Ｄから図１２Ｇは、本発明の一実施形態によるコンセンサス・プロセスを示す。リーダー・ノードの選出後、全てのフォロワー・ノードは、どのノードが特定のブロックまたはサブスペースについてのリーダー・ノードであるかを認識している。リーダーは、それぞれのコンセンサス「期間」の終わりにブロックを作成する役割を担う。それぞれのコンセンサス期間は、特定の時間（例えば、１秒から３秒の間の時間、および好ましくは２秒）しか続かなくてもよく、またはシステムにおいて特定のイベントが発生するまでしか続かなくてもよい。それぞれの期間中、リーダーは、トランザクションおよびメッセージをサブスペースデータに事前コミットする役割を担う。期間の終わりに、事前コミットされたトランザクションおよびメッセージが各フォロワーによって承認されると、フォーマルブロックが完了し、プライベートにサブスペース化されたブロックチェーンにコミットされる。図１２Ｄに示すように、選出後、全てのフォロワー・ノードは、ノードＡ  １２０２が検証された選出によるリーダーであることを認識している。メッセージがノードによって受信されると、本明細書で説明するように、そのメッセージは、そのノードによってピアツーピアのメッセージ伝播に従って伝播される。例えば、図１２Ｅに示すように、ノードＢ  １２０４は、特定のトランザクション（Ｔｘ  １）を表すメッセージを受信し、そのメッセージをシステム内の他の全てのノード（ノードＡ（１２０２）、ノードＣ（１２０６）  、ノードＤ（１２０８）、ノードＥ（１２１０））に伝搬することによって応答する。次にこれらのノードＡ、Ｃ、Ｄ、およびＥは、選出されたリーダー・ノードＡ  １２０２を含む、ネットワーク内の他の全ての検証ノードにメッセージを伝搬する。伝播されたメッセージを受信後、リーダー・ノードは、全てのフォロワー・ノードに、メッセージをサブスペースに事前コミットするための承認を要請するメッセージを送信する。それぞれのフォロワー・ノードは、リーダー・ノードからの承認要請のメッセージを調査し、それからフォロワー・ノードは承認メッセージをリーダー・ノードに送信する。メッセージは、適切な署名や適切なノンス値など、メッセージが有効であることを確実にするための特定の基準を満たす場合、フォロワー・ノードによって事前コミットが承認される。好ましい実施形態において、メッセージは、（ｉ）正しくフォーマットされ（ｐ２ｐプロトコルによって定義されたメッセージ構造に準拠し）、（ｉｉ）署名され、（ｉｉｉ）  送信アカウントの予想されるノンスに等しいノンス値を有する、場合にフォロワー・ノードによって事前コミットが承認される。過半数のフォロワー・ノードが事前コミットの承認を送信すると、リーダーはメッセージをサブスペースに事前コミットする。過半数のフォロワー・ノードに対応する数は、共通サブスペースへのアクセス許可を有するノードの数に基づいて決定される。図１２Ｆの例に示すように、トランザクションＴｘ  １を表すメ���セージを受信したリーダー・ノードＡ  １２０２は、メッセージを関連サブスペース内に事前コミットするための承認を要請するメッセージを全てのフォロワー・ノードに送信する。フォロワー・ノード１２０４、１２０６、１２０８、および１２１０が、リーダー・ノードＡ  １２０２によって送信されたＴｘ  １メッセージを有効であると判断し、承認を送信すると、リーダー・ノードａ  １２０２がＴｘ  １メッセージをサブスペースに事前コミットする。
【００６４】
リーダー・ノードは、その期間が終了するまで、上記のプロセスに従ってメッセージの受信、承認、および事前コミットを継続する。その期間の終わりに、リーダー・ノードは、全ての事前コミットされたメッセージを含むフォーマルブロックを作成し、このブロックのコピーを承認の要請とともに全てのフォロワー・ノードに送信する。リーダー・ノードが過半数のフォロワー・ノードから承認メッセージを受信すると、ブロックは完了し、プライベートにサブスペース化されたブロックチェーンにコミットされる。ブロックが完了し、プライベートにサブスペース化されたブロックチェーンに追加された直後に、新しい期間が始まるリーダーは、複数の期間を務めてもよく、またはそれぞれの期間の初めに選出されてもよい。期間番号は、選出が行われるたびにインクリメントされる。ブロックによって期間は終了しない。従って、リーダーは１期間の任期で選出されるが、ブロックを作り続けている限り、複数の時間／日／週の間リーダーとして作用し得る。再選出がある場合、期間番号は、新しいリーダーが決定されるまで選出ラウンドごとにインクリメントされる。新しいリーダーは、前のリーダーと同じであってもよい。図１２Ｇの引き続く例に示すように、期間中、リーダー・ノードは、トランザクションＴｘ  １、Ｔｘ  ２、およびＴｘ  ３に対応するメッセージを受信し、（各フォロワー・ノードからの承認後）事前コミットしている。期間の完了時、リーダー・ノードＡは、フォーマルブロックを作成し、承認のためにそれをフォロワー・ノードであるノードＢ（１２０４）、ノードＣ（１２０６）、ノードＤ（１２０８）、およびノードＥ（１２１０）に送信する。リーダーＡは、過半数のフォロワー・ノードから承認メッセージを受信すると、ブロックをプライベートにサブスペース化されたブロックチェーンにコミットする。その後、新しい期間が始まると、後続のメッセージが新しいブロックに事前コミットされる。
【００６５】
本明細書の他の箇所で述べるように、ノードの許可はサブスペースごとに行われる。特に、検証ノードの数はサブスペースごとに異なってもよい。例えば、図１３および図１４に示すように、本発明によるノードのピアツーピア・ネットワークは、いくつかのパーティに対応する数の検証ノードを含んでもよいが、それらのノードが検証ノードとして許可されるサブスペースに関して異なり得る。図１３に示すように、パーティＡノードのクラスタ１３００は、検証ノードであるノードＡ０（１３００ａ）、ノードＡ１（１３００ｂ）、ノードＡ２（１３００ｃ）を含み、パーティＢノードのクラスタ１３０２は、検証ノードであるノードＢ０（１３０２ａ）、ノードＢ１（１３０２ｂ）、ノードＢ２（１３０２ｃ）を含み、パーティＣノードのクラスタ１０３４は、検証ノードであるノードＣ０（１３０４ａ）、ノードＣ１（１３０４ｂ）、ノードＣ２（１３０４ｃ）を含み、これらの全てが、システム・ネットワーク１３０８にアクセスし、それらのタイプおよび許可に基づいて互いに通信する権限を付与されている。ただし、図１４に示すように、各ノードは全て検証ノードであるが、検証ノードとして許可されているサブスペースが異なる。例えば、ノードＡ０（１３００ａ）は、サブスペースＡ単独１４０８、サブスペースＡＢ  １４００、およびサブスペースＡＣ  １４０２における検証ノードとして許可されるが、共通サブスペース１４０６では許可されない（ただし、ノードＡ０は、共通サブスペースのピア・ノードとして許可されてもよく、従ってそのサブスペース内のデータにアクセス可能であってもよい）。別の例として、ノードＢ２（１３０２ｃ）は、Ｂ単独サブスペース１４１０および共通サブスペース１４０６における検証ノードとして許可されるが、ＡＢサブスペース１４００またはＢＣサブスペース１４０４では許可されない（ただし、ノードＢ２は、ＡＢおよびＢＣサブスペースのピア・ノードとして許可されてもよく、従ってそれらのサブスペース内のデータにアクセス可能であってもよい）。ただし、どの実装においても、サブスペースの検証ノードを３つ未満とするのは最適ではない。なぜなら、サブスペースにおいて検証ノードを２つだけ使用する場合、任意の承認プロセスでそれら２つの検証ノードが同じように投票しないという許容できない失敗のリスクがあるからである。
【００６６】
プライベートにサブスペース化されたブロックチェーンへのブロックの追加に関する上記の説明から理解され得るように、これらの分散型データ構造は、時間が経つにつれて比較的大きくなる可能性があり、プライベートにサブスペース化されたブロックチェーン内のメッセージおよびブロックの数が増加する。従来のブロックチェーン構造とは異なり、本明細書で開示するプライベートにサブスペース化されたブロックチェーンは、プライベートにサブスペース化されたブロックチェーン内のデータの整合性を維持し、且つデータを検証し、コンセンサス・プロセスを維持する能力を保持する、本明細書で説明する新規プルーニング（ｐｒｕｎｉｎｇ）プロセスを通じてサイズ縮小されてもよい。プライベートにサブスペース化されたブロックチェーンのプルーニングにより、データ構造に必要なメモリを大幅に削減し、ハードディスクのスペースを節約し、その結果、データストレージに関する効率を向上させることができる。加えて、プライベートにサブスペース化されたブロックチェーンのプルーニングにより、パーティは、データ保管および破棄ポリシーへの準拠を維持でき、これは従来のブロックチェーン構造では不可能である。
【００６７】
本明細書で説明するプルーニング・プロセスは、時間ベースの基準などの所定の基準に基づいてトリガされる。例えば、プライベートにサブスペース化されたブロックチェーンは、作成後２年または３年など、一定時間量後にメッセージおよびブロックをプルーニングしてもよい。この時間量は、規制ポリシーまたはパーティ自身のデータ保管ポリシーによって規定されてもよい。メッセージおよびブロックを削除するプルーニング・プロセスを開始するための所定の基準は、サブスペースごとにあってもよい。つまり、それぞれのサブスペースが、プルーニングのための自身のポリシーと基準を有してもよい。加えて、それぞれ異なるパーティは、そのパーティノード上およびそのデータストア内に維持されているプライベートにサブスペース化されたブロックチェーンのプルーニングのために、それぞれ異なるポリシーおよび基準を利用してもよい。好ましい実施形態において、何れの場合も、プルーニングのためのポリシーおよび、従ってプルーニング・プロセスをトリガする基準は、プライベートにサブスペース化されたブロックチェーンにおいて具現化された自己実行スクリプトまたはスマートコントラクトにおけるような、プライベートにサブスペース化されたブロックチェーンそのもの上で維持される。システム１００のコア・モジュール１０４は、プルーニング・プロセスを管理する。コア・モジュール１０４は、それぞれのプライベートにサブスペース化されたブロックチェーンからプルーニングのためのポリシーを取り出し、それらのポリシーに従ってプルーニング・プロセスをトリガする基準を監視する。基準が満たされると、コア・モジュール１０４は、プルーニングされ得るメッセージの特徴を識別する基準のセットまたはフィルターに基づいてブロックおよびメッセージを削除するなどにより、プルーニング・プロセスを実施すると同時に、ブロックおよびメッセージのハッシュ（ブロック内の様々なサブスペースについての状態ルートなど）を保持する。例えば、プルーニング・プロセスによって、特定の契約または契約の特定のセットのブロックおよびメッセージをパージしてもよく、または一定の保管期限を過ぎたブロックおよびメッセージをパージしてもよい。プルーニング・プロセス中、全てのハッシュ値が保管されるため、コンセンサス・プロセスは影響を受けない。ただし、プルーニング・プロセスのために削除されたブロックおよびメッセージにアクセスしようとすると、データが削除済みであることを示すエラーが発生する。
【００６８】
プルーニング・プロセスによって、状態データベース（例えばマークル・ツリー）内のデータが削除され、これによって、上記の通り、スペース節約はもちろん、データ保管ポリシーへの準拠も可能になる。それぞれのデータ・オブジェクト（例えば、それぞれのインスタンス化されたスマートコントラクト）は、その状態データベース内にオブジェクトの形態で存在する。オブジェクトを削除する際、データ保管ポリシーまたは他の理由から、システムは、少なくともそれぞれ異なる参加者がそれぞれ異なるデータ保管ポリシーを実装してもよいという理由で、ツリーの状態ルートが変更されないことを確実にする必要がある。それぞれ異なるデータ保管ポリシーを有するパーティ間のコンセンサスを維持するため、データベースからのオブジェクトのプルーニングでは、ツリーの状態ルートを変更できないようになっている。コンセンサスが確実に維持できるようにしながらデータの削除を実現するために、本明細書で説明するプルーニング・プロセスは、全ての隣接ツリー・ノードをルートまでずっとハッシュする場合（例えばマークル・ツリー・ハッシング）、あたかもオブジェクトがまだ所定の位置にあるかのように同じルート・ハッシュが計算されることを確実にする。この点について、オブジェクトをプルーニングするために、システムは、データ・オブジェクト・ツリー・ノードを維持するが、そこから全てのペイロードを削除する。残るのは、データ・オブジェクトのアドレスとツリー・ノードのハッシュだけである。加えて、データ・オブジェクトは「プルーニング済み」として、またはそのペイロードを削除済みとしてマークされる。アクセスされると、その形態のデータ・オブジェクトは「プルーニング済み」と識別され、それによってシステムは存在しないデータ・オブジェクトとプルーニング済みデータ・オブジェクトとを区別することができる。プルーニング・プロセス後にオブジェクト内に保管される情報（例えば、データ・オブジェクトのアドレスおよびハッシュ）から、元のデータ・ペイロードを復元することはできない。
【００６９】
一実施形態において、削除されたデータ・ペイロードの復元を防ぐために、データ・オブジェクトのツリー・ノードに追加情報が埋め込まれている。特定の状況において、データ・ペイロードを削除するだけでは、データ・オブジェクトは、一致するハッシュが見つかるまで削除された値を推測するなどによってデータを復元しようとする総当たりの試みを許してしまう可能性がある。例えば、ブロックチェーンが１つのタイプの契約のみに使用され、その契約のフィールドが日付と値のみである場合、攻撃者は、一致するハッシュが見つかるまで、日付と値の全ての妥当な組み合わせとバイトコードを結びつけるツリー・ノード・マッチングを生成することができる。このような攻撃から保護するために、ソルト（ｓａｌｔ）（すなわち、ハッシング情報に対する追加的な入力として使用されるランダム・データ）がそれぞれのプライベートにサブスペース化されたブロックチェーン内のそれぞれのツリー・ノードに埋め込まれ、これによって、全ての非ランダム・データが知られている場合であっても、総当たりおよびランダムな推測の試みによる削除されたデータを復元しようとする試みがはるかに困難になる。
【００７０】
図５は、システム１００のネットワーク内の各ノード間の安全な通信プロセスを示す。好ましい実施形態において、システム１００は、認証およびアイデンティティ管理のためにトランスポート層セキュリティ（ＴＬＳ）機能性を使用する。安全な通信プロセスには双方向認証プロシージャが含まれ、双方向認証プロシージャにおいては、接続を受け入れるノード（受け入れノード）が、接続先のノード（接続ノード）の資格（セキュリティ証明書など）が承認されていることを検証し、接続ノードが、受け入れノードの資格が承認されていることを検証する。好ましい実施形態において、双方向プロセスでは、受け入れノードが接続ノードのＴＬＳ証明書が承認されていることを検証し、接続ノードが受け入れノードのＴＬＳ証明書が承認されていることを検証する必要がある。ノードがネットワーク上の他の各ノードを正常に認証し、それらと通信することができるようになる前に、そのノードのセキュリティ証明書（例えば、そのＴＬＳ証明書）のハッシュ値がシステム１００に登録されなければならない。一実施形態において、それぞれのノードの証明書は、ピア・レジストリ５１２、５１４内のコア・モジュール１０４によって登録され、それぞれのノードはピア・レジストリのコピーを維持する。この登録では、セキュリティ証明書をノードのタイプ（検証、ピア、またはサービス）に関連付ける必要があり、その結果、それぞれのノードのＴＬＳ証明書が特定の役割に関連付けて登録される。図５に示すように、システム・ネットワーク内の別のノードとの接続を確立する際、第１のノード５０２であるノードＡは、まず、第２のノード５０８であるノードＢのＴＬＳモジュール５１４に通信可能に結合されたＴＬＳモジュール５０４を使用してＴＬＳハンドシェイク・プロシージャを受ける。このＴＬＳ証明書の初期交換および検証は、ＴＬＳプロトコル仕様に従っている。ＴＬＳプロトコル仕様プロセスに加えて、またはそれに代えて、ハンドシェイクプロセスの一環として、ノードＢはそのデジタル証明書の形態のＩＤであるＴＬＳ証明書を提供する。ノードＡは、そのＴＬＳ証明書がピア・レジストリ５１２に登録されているかどうかをチェックすることにより、ノードＢのＴＬＳ証明書を検証する。追加的または代替的に、各ノードは署名機関を使用せずに自己署名できる。
【００７１】
システム１００は、ＴＬＳ証明書がピア・レジストリ（例えば「チェーンパーム」スクリプトまたは契約）において承認されているかどうかをチェックする二次検証ステップを実施する。これは、ＴＬＳ証明書の交換が完了した後であって、接続が任意のブロックチェーンの目的で使用される前にのみ行われる。図５を参照すると、ピア・レジストリ５１２は、許可を管理するための専用スクリプトまたはスマートコントラクト（例えば「チェーンパーム」スクリプト）に対応する。ノードＢによって返されたＴＬＳ証明書がピア・レジストリ５１２に登録されている場合、接続ノードであるノードＡは、受け入れノードであるノードＢのＴＬＳ証明書が承認されたと判断し、それからノードＡ  ５０２は、セッション鍵に基づくデータを暗号化し、ネットワーク５１０を介してデータとそのＴＬＳ証明書をノードＢ  ５０８に送信する。ノードＢは、ＴＬＳモジュール５０６を使用して、ノードＡによって提供されたＴＬＳ証明書がピア・レジストリ５１４に登録されているかどうかをチェックすることにより、ノードＡのＴＬＳ証明書を検証する。ノードＡによって返されたＴＬＳ証明書がピア・レジストリ５１４に登録されている場合、受け入れノードであるノードＢは、接続ノードであるノードＡのＴＬＳ証明書が承認されたと判断し、それからノードＢ  ５０８は、メッセージを解読してメッセージ内のデータを取り出し、それに応じてデータを処理する。トランスポート層セキュリティ（ＴＬＳ）機能性が、暗号化だけでなくシステムにおける認証にも使用されるため、この安全な通信プロセスは、従来のシステムに比べて重要な利点をもたらす。
【００７２】
接続プロセスを通じて、ノードは、それが接続されているそれぞれのノードのタイプも判別する。上記で説明したように、それぞれのノードは、特定のタイプ（検証、ピア、サービス）としてシステムに登録され、それぞれのノードは、それぞれ異なる各サブスペースおよび各ドメインについて異なるノード・タイプで承認され得る。この登録情報は、専用のピア・レジストリ（例えば、「チェーンパーム」スクリプト）で維持される。特に、システムは、それぞれのノードの一意の識別子をそのタイプに関連付けるレジストリを維持し、ネットワーク内の各ノードに分散させる。上記で説明したように、それぞれのノードの一意の識別子はそのＴＬＳ証明書から得られる。接続ノードがシステム内の別のノードに接続するとき、その接続ノードはシステム内の別のノードのＴＬＳ証明書を取得し、ＴＬＳ証明書およびレジストリ内に維持されている情報に基づいて、その接続ノードは別のノードの関連タイプを判別する。その結果、それぞれのノードは、それがどの検証ノードに接続されているのか、それがどのピア・ノードに接続されているのか、およびそれがどのサービス・ノードに接続されているのかを判別する。それぞれのノードのタイプおよびその接続先のノードのタイプは、システム内でのノードのメッセージの処理の仕方に影響する。検証ノードとして登録されたノードは、ブロックおよびメッセージ検証プロセスに自動的に参加するが、オブザーバまたはサービス・ノードから受信した検証ピアツーピア・メッセージは全て破棄する。加えて、コンセンサスを必要とするメッセージおよびブロックを受信するノードは、検証ノードとして認証されるノードにのみそのようなメッセージおよびブロックを送信する。
【００７３】
上記の通り、許可（すなわち、ノードがネットワーク内の他の各ノードおよびデータに対して起こすことを許されたアクション）はサブスペースによってグループ化される。つまり、例えば、ノードは１つのサブスペースに対する検証ノードであってもよく、かつ別のサブスペース上のピア・ノードであってもよい。特に、ノードは、検証することを許されたサブスペースのセットを有してもよく、その結果、このノードはコンセンサス投票およびブロッキング署名プロセス（ｃｏｎｓｅｎｓｕｓ  ｖｏｔｉｎｇ  ａｎｄ  ｂｌｏｃｋｉｎｇ  ｓｉｇｎｉｎｇ  ｐｒｏｃｅｓｓｅｓ）に参加する。加えて、ノードは、ピアとして観察することを許されたサブスペースのセットを有してもよく、その結果、このノードはブロックおよびメッセージの受動的インポートに関与する。また、ノードは、サービス・ノード（またはＡＰＩクライアント）としてのみ接続することを許されたサブスペースの特定のセットを有してもよく、その結果、このノードはコンセンサスに参加したり、ブロックおよびメッセージに対する能動的または受動的なアクティビティに関与することがない。この点について、ノードは、サービス・ノード／ＡＰＩクライアントとして検証、機能、または作用することが許可されている各サブスペース用のブロックおよびメッセージの発信しか許されていない。本システムによれば、ジェネシス・ブロックと呼ばれる、それぞれの許可されたブロックチェーン内の初期ブロックは、その中のそれぞれのサブスペースの検証ノードの初期セットを含む。ジェネシス・ブロックは、それぞれのサブスペースのピア・ノードおよびサービス・ノードのリストを更に含んでもよい。従って、それぞれのサブスペースごとの識別されたノードのセットとそれらに対応する役割（および許可レベル）がオンチェーンで維持され、ノードがそれぞれのサブスペースに対してどのアクションを起こすことが許されるのかを決定するのに使用される。それぞれのサブスペースごとの識別されたノードのセットとそれらに対応する役割（および許可レベル）は、特定のメッセージによって更新できる。
【００７４】
図６は、サービス・ノードなど、アクセスおよび許可が限定されているノードが、管理者による承認を必要としない検証プロセスに関与することができることを示す。サービス・ノード６０２は、例えば特定のスマートコントラクト６０８などの、特定のサブスペース内のデータに関する情報を要請する。まず、サービス・ノード６０２は、ＴＬＳゲートウェイ６０４を通じてサーバ・ノード６０６（ピア・ノードまたは検証ノードであってもよい）との安全な接続を確立した後、データに対する要請６１４を生成する。サーバ・ノード６０６は、サービス・ノード６０２からの要請を解読し、サービス・ノード６０２が要請対象のサブスペースに対していくらかのレベルの許可を有するかどうかを最初にチェックする（６１６）ことにより要請を処理する。許可をチェックする（６１６）ために、サーバ・ノード６０６は、関連するサブスペースを持つプライベートにサブスペース化されたブロックチェーンを取り出し、次に特定のサブスペース６０８（例えばスマートコントラクト）にアクセスして、そのサブスペース６０８に対して許可レベル（ピア、検証、サービス）を有するノードのリストを取り出す。サービス・ノード６０２が特定のサブスペースに対するサービス／ＡＰＩ許可を有するものとしてリストされている場合、許可が承認される（６１８）。この点について、許可のレベルは階層的であり、検証ノードはピア・ノードよりも大きい許可を有し、ピア・ノードはサービス／ＡＰＩノードよりも大きい許可を有することに留意すべきである。その結果、より低いレベルの許可がより高いレベルの許可の範囲内に含まれるため、より高いレベルの許可を有するノードが、より低いレベルの許可を要する要請について承認される。例えば、ノードが特定のサブスペースの検証ノードである場合、そのノードは検証、ピア、またはサービス／ＡＰＩ許可を要する要請について承認される。別の例として、ノードが特定のサブスペースのピア・ノードである場合、そのノードはピアまたはサービス／ＡＰＩ許可を要する要請について承認される。システムは、必要に応じて追加的な許可レベルをサポートしてもよい。サービス・ノード６０２が特定のサブスペース内のデータにアクセスする許可を有すると判断すると、サーバ・ノードは、検証データ６２２を返すことによって応答し、サービス・ノード６０２はその検証データ６２２から応答が有効であることを判断できる。例えば、この検証データは、完全なブロック・ヘッダ（サーバ・ノード６０６、メッセージ・ルート、および状態ルートからの署名を含む）を含むブロック６２２の一バージョンであってもよいが、サービス・ノードが許可されていないサブスペースからのデータは除外し、サービス・ノード６０２が許可されている関連サブスペース（例えば、要請対象のスマートコントラクト）からのデータ・ペイロード内のデータ、またはその一部、および除外されたデータからのハッシュ値またはインデックス６１０のみを含む。サービス・ノードがブロックの限られた部分を返すという事実にも拘わらず、サービス・ノードは、例えば、ハッシュ・ツリー上で証明を実行することにより、検証データを評価することによってデータを検証できる。証明では、ルート６１２を生成し、それをブロック・ヘッダ内の状態ルートと比較して、ルート６１２が状態ルートの同等値を生成することを確認する。状態ルートがマークル・ツリーのものである場合、サービス・ノード６０２は、サーバ・ノード６０６によって返されたデータを検証するためにマークル証明を実行する。
【００７５】
図１５は、様々なスマートコントラクトおよび対応する共通かつプライベートな各サブスペースを示す。これらの対応する共通かつプライベートなサブスペースによって、ネットワーク内の参加者は、上記のプライベートにサブスペース化されたブロックチェーンを使用し、サブスペースにアクセスする許可を有するノードのみが特定のデータおよびロジックにアクセスできるような方法で、データを保存し、ロジックを実行できる。サブスペース１５００はパーティＡにプライベートであり、エンリッチメント・スマートコントラクト１５０６を含む。スマートコントラクト１５０６は、その各取引契約からパーティＡのプライベート・データを保存する。共通サブスペース１５０４は、マーケットデータ、許可レジストリ、およびベース・テンプレート契約を含む。ベース・テンプレート契約１５２０は、金融契約に関連付けられた規則およびロジックを含む。許可レジストリ契約１５２４は、様々なプライベートにサブスペース化されたブロックチェーン内の各パーティの許可リストを維持する。マーケットデータ契約１５２６は、スマートコントラクトのロジックを実行するための入力を提供する。バイラテラル・サブスペース１５０２は、パーティＡとパーティＢの２つのパーティ間の取引を記録するスマートコントラクトのセットを含む。取引契約１５２８は、契約の現在の状態１５２２、特定の取引の条件１５０８、この取引に対して行われた更新のセット１５１２、および取引契約の規則／ロジックを実行するためのバイトコード１５１８を保存する。サブスペース１５０２は、全ての取引契約を保存するためのレジストリ契約１５１０、ブロック・ヘッダ内のタイムスタンプを追跡するためのイベント・スケジューラ１５１４、取引契約から発生する支払いを一元化し、ネッティングされた値を計算する支払いスマートコントラクト１５１６も含む。取引契約条件１５０８のエンリッチメントデータ部分は、両パーティによって、自身のプライベート・サブスペース１５００内にあるエンリッチメント契約１５０６を通じてポピュレートされる。取引契約１５２８自体は、ベーステンプレート１５２０を使用してインスタンス化され、取引１５０８の特定の条件をポピュレートされる。取引契約１５２８のロジックを実行できる各パーティに対する許可は、共通サブスペース内のレジストリ契約１５２４を通じて管理される。
【００７６】
図１６Ａから図１６Ｅは、一実施形態による、プライベートにサブスペース化されたブロックチェーンに実装された金利スワップ（ＩＲＳ）契約の様々なライフサイクルイベントを示す。図１６Ａは、ＩＲＳ契約のアーキテクチャを示す。ＩＲＳの実装に使用されるスマートコントラクトは、（１）各パーティ間のバイラテラル・サブスペース１６００、および（２）共通サブスペース１６０２、の２つのサブスペース内にある。ＩＲＳデータ契約１６０８は取引条件を含み、レジストリ契約１６０６はＩＲＳインスタンスを維持し、支払い契約１６１０は支払いの一元化およびネッティングに使用される。共通サブスペース１６０２は、ＩＲＳの実行に使用される３つの契約を含む。ベース契約１６１２はＩＲＳ契約のテンプレートであり、許可レジストリ契約１６１４は各サブスペース全体にわたる各パーティの許可を管理し、参照データ契約１６１６はパブリック参照データを維持する。図１６Ｂは、新しいＩＲＳの作成中の各イベントのシーケンスを示す。マッチング・エンジン１６２０は、バイラテラル・サブスペース１６００内のサーバ・ノード１６１８と相互作用し、プライベートにサブスペース化されたブロックチェーン上で取引の記録を開始する。サーバ・ノードは、共通サブスペースからベーステンプレート契約１６１２にアクセスして、新しいＩＲＳ契約１６０８をインスタンス化する。サービス・プロバイダの許可は、レジストリ契約１６１４にアクセスすることによって検証される。資格を検証すると、新しい契約がレジストリ１６０６に保存され、前払い金額が支払い契約１６１０に送信される。新しい契約はまた、ブロック・ヘッダのタイムスタンプを追跡するためのスケジューラ１６０４に追加される。図１６Ｃは、バイラテラル・サブスペース１６００においてＩＲＳ契約の更新をもたらすイベントのシーケンスを示す。共通サブスペース１６０２において、クリアリング・ハウス・ノード１６２４はサーバ・ノード１６２２に接続する。サーバ・ノードは、参照データ契約１６１６にメッセージを送信する。バイラテラル・サブスペース上のイベント・スケジューラ１６０４は、このメッセージを観察し、ＩＲＳレジストリ契約１６０６に通知する。レジストリ契約はその後、基礎となるＩＲＳ契約１６０８の状態を更新する。図１６Ｄは、時間ベースのトリガに続くイベントのシーケンスを示す。事前定義されたタイムスタンプに到達すると、イベント・スケジューラ１６０４は、ＩＲＳレジストリ１６０６に通知することにより、タイムトリガ型イベントをトリガする。レジストリは基礎となるＩＲＳ契約１６０８に通知し、契約の支払いが支払い契約１６１０において適切に更新される。図１６Ｅは、新しいバイラテラル・サブスペースの作成を示す。クリアリング・ノード１６２４は、サーバ・ノード１６２２にメッセージを送信し、新しいバイラテラルなプライベートにサブスペース化されたブロックチェーンを作成する。許可レジストリ契約１６１４は、許可を検証し、新しいバイラテラル・サブスペースを作成し、更に両パーティからの関連する各ノードに通知を送信する。
【００７７】
図１７Ａから図１７Ｃは、一実施形態による、エクイティ・スワップ契約の作成を示す。図１７Ａは、プライベート・サブスペース１７００と共通サブスペース１７０２の両方における必要な契約を示す。共通サブスペースは、ベース・テンプレート契約１７１２、許可レジストリ１７１４、およびマーケット・データ契約１７１６を含む。各パーティ間のバイラテラル・サブスペース１７００は、エクイティ・スワップ契約１７０８、支払い契約１７１０、レジストリ契約１７０６、およびイベント・スケジューラ契約１７０４を含む。図１７Ｂは、バイラテラル・サブスペース１７００における新しいエクイティ・スワップ契約の作成を示す。マーケット・ノード１７２０は、サーバ・ノード１７１８と相互作用して、新しい取引契約の作成を開始する。サーバ・ノードはブロックチェーン・メッセージを作成して、ベース契約１７１２において定義されたテンプレートからスワップ契約１７０８を作成する。スワップ契約が作成されると、レジストリ契約１７０６およびスケジューラ契約１７０４が更新される。図１７Ｃは、各パーティ間の支払いの取引終了（ｅｎｄ  ｏｆ  ｄａｙ）更新中のイベントのシーケンスを示す。共通サブスペースにおいて、マーケット・データ・プロバイダ１７２４は、サーバ・ノード１７２２に接続する。サーバ・ノードは、メッセージを送信することによってマーケット・データ契約１７１６を更新する。バイラテラル・サブスペース内のイベント・スケジューラ契約１７０４は、レジストリ１７０６から未処理の契約をフェッチする値洗い（ｍａｒｋ  ｔｏ  ｍａｒｋｅｔ）（ＭＴＭ）イベントをトリガする。未処理の取引契約１７０８は、最新の金利についてマーケット・データ契約１７１６にクエリし、ＭＴＭを計算し、最終的に支払い契約１７１０にメッセージを送信する。
【００７８】
図１８は、参照データ・プロバイダ１８１６、確認サービス・プロバイダ１８１２、および他の各ノードが、共通接続性ネットワーク１８２２を通じてどのように相互作用するかを示す。バイ・サイド（ｂｕｙ  ｓｉｄｅ）企業、ディーラー、および他の各サービス・プロバイダは、ネットワークへのそれぞれ異なる接続を維持する。マッチングおよび確認サービス・プロバイダ１８１２、参照データ・プロバイダ１８１６、および他の各サービス・プロバイダ１８１４は、ネットワークへのソフトウェア定義型ネットワーク（ＳＤＮ）ベースの接続のみを維持する。これらの３つのサービスはサービス・レベル・ノードのみを備え、よって、ネットワーク内への可視性が限定されている。これらのノードは、特定のサブスペース内の契約の限られたセットにのみアクセスできる。また、これらのノードは、共通サブスペース内の全てのメッセージを受信する。ディーラー・ノード１８００はフル・ノードであり、これは、ディーラ・ノード１８００が、許可されたサブスペース（群）内の全てのメッセージを受信し、またブロックをサブスペース・ブロックチェーンにコミットすることを意味する。ディーラー・ノード１８００は、ネットワーク１８２２へのクライアント接続およびベンダー接続を維持する。ディーラー・ノード１８０２および１８０４もフル・ノードであり、ＳＤＮおよびネットワークへのクライアント接続を維持する。バイ・サイド・ノード１８０６、１８０８および１８１０はサービス・ノードであり、許可されたサブスペース内のメッセージの限られたセットにアクセスする。
【００７９】
本発明をいくつかの好ましい実施形態に関して説明してきたが、本発明の範囲内に入る多くの変更、置換、および均等物があることが理解されるべきである。また、本発明のプロセスと装置の両方を実施する代替的な方法があることにも留意されるべきである。例えば、各ステップは必ずしも添付の各図に示された順序で行われる必要はなく、適宜並べ替えてもよい。従って、添付の特許請求の範囲は、本発明の真の精神および範囲内にある全てのそのような変更、置換、および均等物を含むことが意図されている。
【００８０】
本発明は、デジタル電子回路、またはコンピュータ・ハードウェア、ファームウェア、ソフトウェア、若しくはそれらの組み合わせで実施することができる。本発明は、コンピュータ・プログラム製品、すなわち、データ処理装置、例えば、プログラム可能なプロセッサ、コンピュータ、または複数のコンピュータによる実行のために、またはその動作を制御するために、例えば機械可読記憶デバイスまたは伝播信号などの情報キャリアにおいて有形で具現化されたコンピュータ・プログラムとして実装できる。コンピュータ・プログラムは、コンパイラ型またはインタープリタ型言語を含む、任意の形態のプログラミング言語で記述でき、スタンド・アロン・プログラムとして、またはモジュール、コンポーネント、サブルーチン、若しくはコンピューティング環境における使用に適した他のユニットとしての形態を含む任意の形態で配置され得る。コンピュータ・プログラムは、１つのコンピュータ上または１つのサイトにおける複数のコンピュータ上で実行されるように、または複数のサイト全体にわたって分散され、通信ネットワークによって相互接続されるように配置することができる。
【００８１】
本発明の方法ステップは、入力データを操作して出力を生成することによって本発明の各機能を果たすためのコンピュータ・プログラムを実行する１つ以上のプログラム可能なプロセッサによって遂行することができる。方法ステップは、特殊目的ロジック回路、例えばＦＰＧＡ（フィールド・プログラム可能ゲート・アレイ）またはＡＳＩＣ（特定用途向け集積回路）によって遂行することもでき、本発明の装置は、そのような特殊目的ロジック回路として実施され得る。
【００８２】
コンピュータ・プログラムの実行に適したプロセッサには、例として、マイクロプロセッサ、および任意の高性能デジタル・コンピューティング・プラットフォームの任意の１つ以上のプロセッサが含まれる。プロセッサは、読み取り専用メモリ、若しくはランダム・アクセス・メモリ、またはその両方から命令およびデータを受信する。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令およびデータを保存するための１つ以上のメモリデバイスである。一般に、コンピュータは、データを保存するための１つ以上の大容量記憶デバイス、例えば磁気ディスク、光磁気ディスク、または光ディスクも含むか、それらからデータを受信またはそれらにデータを転送するようにそれらに動作可能に結合されるか、あるいはその両方である。コンピュータ・プログラムの命令およびデータを具現化するのに適した情報キャリアには、あらゆる形態の不揮発性メモリが含まれ、その例には、半導体メモリ・デバイス、例えばＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイス；磁気ディスク、例えば、内蔵ハードディスクまたはリムーバブルディスク；光磁気ディスク；並びにＣＤ  ＲＯＭおよびＤＶＤ−ＲＯＭディスクが含まれる。プロセッサおよびメモリは、特殊目的ロジック回路によって補完されるか、あるいは特殊目的ロジック回路に組み込むことができる。
【００８３】
本開示の文脈において（特に以下の特許請求の範囲の文脈において）用語「ａ」、「ａｎ」、「ｔｈｅ」、および類似の参照の使用は、本明細書において特に別の記載がない限り、または文脈上明らかに矛盾しない限り、単数および複数の両方を包含すると解釈されるべきである。本明細書で説明する全ての方法は、本明細書において特に別の記載がない限り、または文脈上明らかに矛盾しない限り、任意の適切な順序で実行することができる。本明細書において提供される全ての例または例示的な言い回し（例えば、好ましい、好ましくは）の使用は、単に開示の内容を更に説明することを意図しており、特許請求の範囲を限定するものではない。明細書中の如何なる言い回しも、任意の非請求要素が本開示の実施に必須であると示すかのように解釈されるべきではない。
【００８４】
本明細書において複数の実施形態が説明され、それらの実施形態には、請求されている発明を実施するための本発明者らに知られた最良の形態が含まれる。これらから、開示された各実施形態の変形が、前述の開示を読むことで当業者に明らかになるであろう。本発明者らは、当業者がそのような変形を適宜採用する（例えば、各特徴または各実施形態を変更または組み合わせる）ことを期待し、本発明が本明細書に具体的に記載された以外の方法で実施されることを意図している。
【００８５】
従って、本発明は、適用法で許可されているように、本明細書に添付の特許請求の範囲に記載された主題のあらゆる変更および均等物を含む。更に、上記各要素のあらゆる可能な変形における任意の組み合わせは、本明細書において特に別の記載がない限り、または文脈上明らかに矛盾しない限り、本発明に包含される。
【図１】
2020522796.tif 000003
【図２】
2020522796.tif 000004
【図３】
2020522796.tif 000005
【図４】
2020522796.tif 000006
【図５】
2020522796.tif 000007
【図６】
2020522796.tif 000008
【図７Ａ】
2020522796.tif 000009
【図７Ｂ】
2020522796.tif 000010
【図８】
2020522796.tif 000011
【図９】
2020522796.tif 000012
【図１０】
2020522796.tif 000013
【図１１Ａ】
2020522796.tif 000014
【図１１Ｂ】
2020522796.tif 000015
【図１１Ｃ】
2020522796.tif 000016
【図１１Ｄ】
2020522796.tif 000017
【図１２Ａ】
2020522796.tif 000018
【図１２Ｂ】
2020522796.tif 000019
【図１２Ｃ】
2020522796.tif 000020
【図１２Ｄ】
2020522796.tif 000021
【図１２Ｅ】
2020522796.tif 000022
【図１２Ｆ】
2020522796.tif 000023
【図１２Ｇ】
2020522796.tif 000024
【図１３】
2020522796.tif 000025
【図１４】
2020522796.tif 000026
【図１５】
2020522796.tif 000027
【図１６Ａ】
2020522796.tif 000028
【図１６Ｂ】
2020522796.tif 000029
【図１６Ｃ】
2020522796.tif 000030
【図１６Ｄ】
2020522796.tif 000031
【図１６Ｅ】
2020522796.tif 000032
【図１７Ａ】
2020522796.tif 000033
【図１７Ｂ】
2020522796.tif 000034
【図１７Ｃ】
2020522796.tif 000035
【図１８】
2020522796.tif 000036
【図１９】
2020522796.tif 000037
【図２０Ａ】
2020522796.tif 000038
【図２０Ｂ】
2020522796.tif 000039
【国際調査報告】
2020522796.tif 000040
2020522796.tif 000041
2020522796.tif 000042