JP2024507908A - Ｓｓｉを用いたブロックチェーンネットワークアイデンティティ管理 - Google Patents

Abstract

例示的な動作は、ブロックチェーンネットワークへの格納の要求を受信する段階、自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成される検証可能なクレデンシャルであって、ブロックチェーンノードのクレーム、および前記検証可能なクレデンシャルを作成した前記ＳＳＩネットワークの証明を含む、検証可能なクレデンシャルを前記要求に関連付けられたブロックチェーントランザクションへ前記ブロックチェーンノードを介してアタッチする段階、前記ブロックチェーントランザクションおよびアタッチされた前記検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送する段階、および前記ブロックチェーントランザクションおよび前記アタッチされた検証可能なクレデンシャルを前記ブロックチェーン上のデータブロックを介して格納する段階のうちの１つまたは複数を含み得る。

Description

集中型プラットフォームは、データを単一の位置に格納して維持する。この位置は、多くの場合、中央コンピュータ、例えば、クラウドコンピューティング環境、ウェブサーバまたはメインフレームコンピュータ等である。集中型プラットフォームに格納された情報は、典型的には、複数の異なるポイントからアクセス可能である。複数のユーザまたはクライアントワークステーションが、例えば、クライアント／サーバ構成に基づいて、集中型プラットフォームで同時に作業できる。集中型プラットフォームは、その単一の位置を原因として、特にセキュリティの目的で、管理、維持および制御が容易である。集中型プラットフォーム内では、全てのデータを単一の位置に格納することは、データの所与のセットにプライマリレコードが１つしかないことも意味するので、データ冗長性が最小化される。

１つの例示的な実施形態は、ブロックチェーンへの格納の要求を受信するように構成されたネットワークインタフェース、および自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成される検証可能なクレデンシャルであって、ブロックチェーンノードのクレーム、および前記検証可能なクレデンシャルを作成した前記ＳＳＩネットワークの証明を含む、検証可能なクレデンシャルを前記要求に関連付けられたブロックチェーントランザクションへ前記ブロックチェーンノードを介してアタッチするように、かつ、前記ブロックチェーントランザクションおよびアタッチされた前記検証可能なクレデンシャルを前記ブロックチェーン上のデータブロックを介して格納するように構成されたプロセッサ、ここで、前記プロセッサはさらに、前記ブロックチェーントランザクションおよび前記アタッチされた検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送するよう前記ネットワークインタフェースを制御するように構成されている、を備える装置を提供する。

別の例示的な実施形態は、ブロックチェーンへの格納の要求を受信する段階、自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成される検証可能なクレデンシャルであって、ブロックチェーンノードのクレーム、および前記検証可能なクレデンシャルを作成した前記ＳＳＩネットワークの証明を含む、検証可能なクレデンシャルを前記要求に関連付けられたブロックチェーントランザクションへ前記ブロックチェーンノードを介してアタッチする段階、前記ブロックチェーントランザクションおよびアタッチされた前記検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送する段階、および前記ブロックチェーントランザクションおよび前記アタッチされた検証可能なクレデンシャルを前記ブロックチェーン上のデータブロックを介して格納する段階のうちの１つまたは複数を含む方法を提供する。

さらなる例示的な実施形態は、プロセッサにより読み取られた場合、ブロックチェーンへの格納の要求を受信する手順、自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成される検証可能なクレデンシャルであって、ブロックチェーンノードのクレーム、および前記検証可能なクレデンシャルを作成した前記ＳＳＩネットワークの証明を含む、検証可能なクレデンシャルを前記要求に関連付けられたブロックチェーントランザクションへ前記ブロックチェーンノードを介してアタッチする手順、前記ブロックチェーントランザクションおよびアタッチされた前記検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送する手順、および前記ブロックチェーントランザクションおよび前記アタッチされた検証可能なクレデンシャルを前記ブロックチェーン上のデータブロックを介して格納する手順のうちの１つまたは複数を前記プロセッサに実行させる命令を備える非一時的コンピュータ可読媒体を提供する。

例示的な実施形態による、自己主権型アイデンティティ（ＳＳＩ）を用いたブロックチェーンネットワークを示す図である。

例示的な実施形態による検証可能なクレデンシャルを示す図である。

例示的な実施形態による検証可能なクレデンシャルのさらなる詳細を示す図である。

例示的な実施形態による例示的なブロックチェーンアーキテクチャ構成を示す図である。

例示的な実施形態による、ノード間のブロックチェーントランザクションフローを示す図である。

例示的な実施形態による許可型ネットワークを示す図である。

例示的な実施形態による別の許可型ネットワークを示す図である。

例示的な実施形態による非許可型ネットワークを示す図である。

例示的な実施形態による、検証可能なクレデンシャルを発行する処理を示す図である。

例示的な実施形態による、検証可能なクレデンシャルを用いてブロックチェーントランザクションを実行する方法を示す図である。

例示的な実施形態による、本明細書において説明される１つまたは複数の動作を実行するように構成された例示的なシステムを示す図である。

例示的な実施形態による、本明細書において説明される１つまたは複数の動作を実行するように構成された別の例示的なシステムを示す図である。

例示的な実施形態による、スマートコントラクトを利用するように構成されたさらなる例示的なシステムを示す図である。

例示的な実施形態による、ブロックチェーンを利用するように構成されたさらに別の例示的なシステムを示す図である。

例示的な実施形態による、分散型台帳に追加される新しいブロックの処理を示す図である。

例示的な実施形態による、新しいデータブロックのデータコンテンツを示す図である。

例示的な実施形態による、デジタルコンテンツのブロックチェーンを示す図である。

例示的な実施形態による、ブロックチェーン内のブロックの構造を表し得るブロックを示す図である。

例示的な実施形態による、機械学習（人工知能）データを格納する例示的なブロックチェーンを示す図である。

例示的な実施形態による、例示的な量子セキュアブロックチェーンを示す図である。

例示的な実施形態のうちの１つまたは複数をサポートする例示的なシステムを示す図である。

本明細書において概して説明され、図示されるような本コンポーネントは、多種多様な異なる構成で配置および設計され得ることが容易に理解されるであろう。したがって、添付図面に表されるような、方法、装置、非一時的コンピュータ可読媒体およびシステムのうちの少なくとも１つの実施形態の以下の詳細な説明は、特許請求される本願の範囲を限定することを意図するものではなく、選択された実施形態を表しているに過ぎない。

本明細書の全体にわたって説明される本特徴、構造、または特性は、１つまたは複数の実施形態において任意の適切な方式で組み合わせまたは除去し得る。例えば、本明細書の全体にわたって、「例示的な実施形態」、「いくつかの実施形態」という語句、または他の同様の文言の使用は、実施形態に関連して説明された特定の特徴、構造、または特性が、少なくとも１つの実施形態に含まれ得るということを指す。したがって、本明細書の全体にわたって、「例示的な実施形態」、「いくつかの実施形態において」、「他の実施形態において」という語句または他の同様の文言の出現は、必ずしも全てが実施形態の同じグループを指すわけではなく、説明された特徴、構造、または特性は、１つまたは複数の実施形態において任意の適切な方式で組み合わせるか、または除去し得る。さらに、図において、要素間の任意の接続により、示されている接続が一方向または双方向の矢印の場合でも、一方向通信および／または双方向通信が可能になり得る。図面に示された任意のデバイスは、異なるデバイスであってもよい。例えば、モバイルデバイスが情報を送信していることが示される場合、情報を送信するために、有線デバイスも用いられ得る。

加えて、「メッセージ」という用語が実施形態の説明において用いられていることがあるが、本願は、多くのタイプのネットワークおよびデータに適用され得る。さらに、例示的な実施形態において、特定のタイプの接続、メッセージ、およびシグナリングが示されていることがあるが、本願は、特定のタイプの接続、メッセージ、およびシグナリングに限定されるものではない。

例示的な実施形態は、自己主権型アイデンティティ（ＳＳＩ）ネットワークを介したブロックチェーンネットワークアイデンティティの管理に関する方法、システム、コンポーネント、非一時的コンピュータ可読媒体、デバイスおよび／またはネットワークを提供する。

様々な実施形態によれば、各ブロックチェーンエンティティ（例えば、ピア、オーダラ、エンドーサ、クライアント、オーディタ、ａｄｍｉｎ等）には、ブロックチェーンネットワーク内のブロックチェーンエンティティを識別する一意の非集中型識別子（ＤＩＤ）が割り当てられ得る。ＤＩＤを有するブロックチェーンエンティティには、ブロックチェーントランザクション、メッセージおよびブロック等に署名するためにブロックチェーンエンティティにより用いられ得る１つまたは複数の検証可能なクレデンシャル（ＶＣ）が発行され得る。いくつかの実施形態において、各ブロックチェーンエンティティは、各々がブロックチェーンエンティティに１つまたは複数のクレームを与えるＶＣのセットを含み得る。クレームは、例えば、特定のスマートコントラクト（チェーンコード）についてトランザクションに署名することをブロックチェーンピアが許可されているクレームであってよい。別の例として、クレームは、ブロックチェーン台帳の複数のチャネルの間の特定のチャネル／ブロックチェーン上でトランザクトするのをブロックチェーンピアが許可されることであってよい。別の例として、クレームは、ブロックチェーンピアがブロックチェーンネットワークのエンドースピア等であるというアイデンティティであってよい。

検証可能なクレデンシャルの各々は、ブロックチェーンネットワークのＳＳＩネットワーク内の当局、例えば、メンバーシップサービスプロバイダ（ＭＳＰ）または認証局（ＣＡ）等から発行され得る。検証可能なクレデンシャルは、検証可能なクレデンシャルの発行者の署名など、「証明」を含み得る。ＳＳＩネットワークは、割り当てられたＤＩＤ、およびＶＣ等の全てを維持し得る。加えて、ＳＳＩネットワークは、各ＶＣのスキーマ情報および公開鍵に署名した発行者の公開鍵等を維持し得る。ブロックチェーンのメンバは、レジストリにアクセスし、スキーマ情報および発行者の公開鍵を取得して、検証可能なクレデンシャルのスキーマおよび発行者の署名をそれぞれ検証できる。このように、ブロックチェーンエンティティのいずれも、中央局に依存することなく、検証可能なクレデンシャルの妥当性を確認できる。

１つの実施形態において、本願は、互いに通信する複数のノードを含む分散型ストレージシステムである非集中型データベース（ブロックチェーンなど）を利用する。非集中型データベースは、相互に信頼されていない当事者間の記録を維持することができる分散型台帳に似た、アペンド専用の不変データ構造を含む。信頼されていない当事者は、本明細書において、ピアまたはピアノードと称される。各ピアはデータベースレコードのコピーを維持しており、分散されたピア間でコンセンサスに達しない限り、どの単一のピアもデータベースレコードを修正できない。例えば、ピアはコンセンサスプロトコルを実行して、ブロックチェーンストレージトランザクションの妥当性を確認し、ストレージトランザクションをブロックにグループ化し、ブロックにわたってハッシュチェーンを構築し得る。この処理では、一貫性を保つために、必要に応じてストレージトランザクションを順序付けすることによって、台帳が形成される。様々な実施形態において、許可型ブロックチェーンおよび／または非許可型ブロックチェーンを用いることができる。パブリックなまたは非許可型ブロックチェーンでは、誰でも特定のアイデンティティなしで参加できる。パブリックブロックチェーンは、ネイティブ暗号通貨を伴ってよく、プルーフオブワーク（ＰｏＷ）などの様々なプロトコルに基づくコンセンサスを用いてよい。一方、許可型ブロックチェーンデータベースは、資金、物品および情報等を交換するビジネスなど、共通の目的を共有するが、互いに十分には信頼していないエンティティのグループ間でのセキュアなインタラクションを提供する。

本願は、非集中型ストレージスキームに合わせて調整され、「スマートコントラクト」または「チェーンコード」と称される、任意のプログラマブルロジックを動作させるブロックチェーンを利用できる。いくつかの事例において、システムチェーンコードと称される、管理機能およびパラメータに特化したチェーンコードが存在し得る。本願はさらに、ブロックチェーンデータベースの改ざん防止特性、および、エンドースメントまたはエンドースメントポリシーと称される、ノード間の基礎となる合意を活用する信頼されている分散アプリケーションであるスマートコントラクトを利用できる。このアプリケーションに関連付けられたブロックチェーントランザクションは、ブロックチェーンにコミットされる前に「エンドース」できるが、エンドースされていないトランザクションは無視される。エンドースメントポリシーにより、チェーンコードは、エンドースメントに必要なピアノードのセットの形式でトランザクションのエンドーサを指定することが可能になる。クライアントがトランザクションをエンドースメントポリシーで指定されたピアに送信するとき、トランザクションが実行され、トランザクションの妥当性を確認される。妥当性確認後、トランザクションは順序付けフェーズに入り、ここでは、ブロックにグループ化されたエンドースされたトランザクションの順序付けられたシーケンスが生成するために、コンセンサスプロトコルが用いられる。

本願は、ブロックチェーンシステムの通信エンティティであるノードを利用することができる。「ノード」は、同じ物理サーバ上で異なるタイプの複数のノードが動作し得るという意味で、論理機能を実行し得る。ノードは信頼ドメインにグループ化され、様々な態様でこれらを制御する論理エンティティに関連付けられる。ノードは、エンドーサ（例えば、ピア）にトランザクション呼び出しをサブミットし、順序付けサービス（例えば、順序付けノード）にトランザクション提案をブロードキャストするクライアントまたはサブミッティングクライアントノードなど、異なるタイプを含み得る。別のタイプのノードは、クライアントがサブミットしたトランザクションを受信し、トランザクションをコミットし、かつ、ブロックチェーントランザクションの台帳の状態およびコピーを維持することができるピアノードである。ピアは、エンドーサの役割も有し得るが、これは要件ではない。順序付けサービスノードまたはオーダラは、全てのノードに対する通信サービスを実行するノードであり、トランザクションをコミットし、通常は制御およびセットアップ情報を含む初期ブロックチェーントランザクションの別名であるブロックチェーンのワールドステートを修正する場合、システム内のピアノードの各々へのブロードキャストなどの配信保証を実装する。

本願は、ブロックチェーンの全ての状態遷移のシーケンス化された改ざん耐性のある記録である台帳を利用できる。状態遷移は、参加当事者（例えば、クライアントノード、順序付けノード、エンドーサノード、ピアノード等）によってサブミットされたチェーンコード呼び出し（すなわち、トランザクション）から生じ得る。参加している当事者（ピアノードなど）の各々は、台帳のコピーを維持できる。トランザクションの結果、資産鍵値ペアのセットが、例えば、作成、更新および削除等、１つまたは複数のオペランドとして台帳にコミットされ得る。台帳は、不変シーケンス化レコードをブロックに格納するために用いられるブロックチェーン（チェーンとも称される）を含む。台帳は、ブロックチェーンの現在の状態を維持する状態データベースも含む。

本願は、ハッシュリンクされたブロックとして構築されたトランザクションログであるチェーンを利用でき、各ブロックは、Ｎが１に等しいまたは１よりも大きい一連のＮ個のトランザクションを含む。ブロックヘッダは、ブロックのトランザクションのハッシュ、および、前のブロックのヘッダのハッシュを含む。このようにして、台帳上の全てのトランザクションをシーケンス化し、暗号的に共にリンクし得る。したがって、ハッシュリンクを破壊することなく台帳データを改ざんすることは不可能である。直近で追加されたブロックチェーンブロックのハッシュは、その前に発生したチェーン上の全てのトランザクションを表し、全てのピアノードが一貫性のある信頼できる状態にあるのを保証することを可能にする。チェーンは、ピアノードファイルシステム（すなわち、ローカル、アタッチトストレージ、クラウド等）に格納され得、ブロックチェーンワークロードのアペンド専用の性質を効率的にサポートする。

不変台帳の現在の状態は、チェーントランザクションログに含まれる全ての鍵の最新の値を表す。現在の状態はチャネルに既知の最新の鍵値を表すので、ワールドステートと称されることがある。チェーンコード呼び出しは、台帳の現在の状態データに対してトランザクションを実行する。これらのチェーンコードインタラクションを効率的にするために、鍵の最新の値を状態データベースに格納し得る。状態データベースは、単にチェーンのトランザクションログへのインデックス付きビューであり得、したがって、いつでもチェーンから再生成できる。状態データベースは、ピアノードの起動時であって、トランザクションが受け入れられる前に、自動的に回復（または必要である場合に生成）されてよい。

ＳＳＩメンバーシップおよび識別情報を用いたブロックチェーンネットワークの利益のいくつかは、プライバシー、セキュリティおよびポータビリティ（または相互運用性）を含む。例えば、ＳＳＩを用いて、ネットワーク参加者は、特定の文脈において、非集中型識別子（ＤＩＤ）を所望の露出レベルで用いることができる。例えば、ブロックチェーンピアは、ブロックに含めるためにトランザクションに署名する場合、そのネットワーク内でトランザクションに署名する目的で自己に対して発行されたクレデンシャル（またはクレデンシャルの一部分）のみを用いる。このピアのＤＩＤは、様々な他の属性および所属（例えば、複数のビジネスネットワークに参加している組織にピアが属し得ること）を含み得るが、その情報のいずれも、トランザクションサイクルにおいて公開されない。妥当性を確認するピアは、検証可能なクレデンシャルのＶＰ（検証可能なプレゼンテーション）を、（数日後に）オーディタが行うようにチェックするだけである。

さらに、例えば、許可された台帳の間で資産またはデータ項目が共有されるクロスネットワークインタラクションにおいて、セキュリティも強化され得る。ＳＳＩ（ＤＩＤおよびＶＣなど）を有する参加者（ブロックチェーンピア）は、それら自体を認証でき、異なるビジネスネットワークの集中型エンティティまたは参加者など、（それらのポリシーを自由に選択できる）外部当事者に対し、ＶＣ／ＶＰに、かつ、ＤＩＤアイデンティティおよびストレージプロバイダとして動作するＳＳＩネットワークに依存することにより単純な処理を用いて、自己の特性を証明できる。さらに、ポータビリティおよび相互運用性が向上し得る。許可型ネットワークは今日、（クレデンシャルの発行および格納のための）独自のプロプライエタリアイデンティティ管理システムを有している。これは、ネットワークの外部の当事者には見えない。これらの異種かつ不透明なアイデンティティ管理システムの代わりにＳＳＩを用いることにより、例示的な実施形態は、ネットワーク参加者が認識され、そのネットワークの外部で自己の真正性を証明できることを保証することにより、データおよび資産が（ポリシー制御された態様で）ネットワーク境界にわたって流れることを可能にし得る。さらに、ＳＳＩネットワークは、特定のネットワークとの関係がない周知のアイデンティティプロバイダまたはクレデンシャル当局の周囲に構築され得る。これにより、ネットワーク間インタラクションでのアイデンティティおよびクレデンシャルのポータビリティが可能になる。

例示的な実施形態において、検証可能なクレデンシャルが、ＤＩＤ保有者（ＳＳＩに依存するネットワーク参加者）に対して発行され得る。検証可能なクレデンシャルは、許可型ネットワーク内の既存のアイデンティティプロバイダおよび認証局であり得るか、または周知の外部当局であり得る発行者（ＳＳＩネットワークのメンバ）により発行され得る。ネットワーク内で、発行者は、ネットワークまたは組織的な（サブディビジョン）ＣＡを含み得る。Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃネットワークにおいて、これらのエンティティは、ＭＳＰ（メンバーシップサービスプロバイダ）と呼ばれ、ルートおよび中間ＣＡのチェーンを維持する。Ｃｏｒｄａネットワークには、結果としてクレデンシャルノードＣＡ（各ノードがトランザクションについて署名および承認する能力を有する）であるドアメンＣＡを認証するネットワークＣＡのヒエラルキーが存在する。これらのＭＳＰまたはＣＡは、ネットワーク全体またはネットワーク内サブディビジョンのいずれかを表し、アイデンティティおよびクレデンシャル（ＤＩＤなど）を発行／破棄する。ネットワークの外部で、発行者は、ＶｅｒｉｓｉｇｎまたはＤＭＶのような著名なＣＡおよび認証局など、外部当事者を含み得る。他の発行者は、許可型ネットワークへの参加を選択した既存の組織、ビジネスネットワーク、例えばサプライチェーン、フードトラストネットワーク等を含む組織のコンソーシアムを代表するアドホック当局を含み得る。ＳＳＩネットワークは、複数のネットワークの参加者のアイデンティティを管理でき、ネットワーク境界にわたるアイデンティティの共有に容易にできることも理解されたい。

例示的な実施形態において、ブロックチェーンピアまたはブロックチェーンクライアントなど、ＳＳＩネットワークの参加者には、ＤＩＤが発行され得る。ＤＩＤは、ブロックチェーンエンティティを識別するＵＲＩなど、一意識別子であってよい。例えば、ＤＩＤにより、検証可能な非集中型デジタルアイデンティティが可能になる。ＤＩＤは、識別することをＤＩＤのコントローラが決定した任意の対象（例えば、人、組織、モノ、データモデル、抽象エンティティ等）を識別する。典型的な連携識別子とは対照的に、ＤＩＤは、集中型レジストリ、アイデンティティプロバイダおよび認証局から切り離され得るように設計されている。具体的には、他の当事者は、ＤＩＤに関連する情報の発見を可能にするのを助けるために用いられ得るが、この設計は、任意の他の当事者からの許可を必要とすることなく、ＤＩＤのコントローラがその制御を証明することを可能にする。ＤＩＤは、その対象に関連付けられた信頼できるインタラクションを可能にするＤＩＤドキュメントにＤＩＤ主題を関連付けるＵＲＩである。

各ＤＩＤドキュメントは、ＤＩＤコントローラがＤＩＤの制御を証明することを可能にするメカニズムのセットを提供する暗号マテリアル、検証方法またはサービスを表し得る。サービスにより、ＤＩＤ主題に関連付けられた信頼できるインタラクションが可能になる。ＤＩＤ主題がデータモデルなどの情報リソースである場合、ＤＩＤドキュメントは、ＤＩＤ主題自体を含み得る。このドキュメントは、共通データモデル、ＵＲＬフォーマット、および、ＤＩＤ、ＤＩＤドキュメントおよびＤＩＤ方法の動作のセットを指定し得る。ＤＩＤは、ＵＲＩスキーム識別子（ＤＩＤ）、ＤＩＤ方法識別子およびＤＩＤ方法固有識別子を含む３つの部分から成る単純な文字列である。ＤＩＤは、ＤＩＤドキュメントへ分解可能である。ＤＩＤ ＵＲＬは、特定のリソース、例えば、ＤＩＤドキュメントの内部の公開鍵またはＤＩＤドキュメントの外部で利用可能なリソースの位置を特定すべく、基本的ＤＩＤの構文を拡張して、他の標準的なＵＲＩコンポーネント（経路、クエリ、フラグメント）を組み込む。

ＤＩＤドキュメントは、ＤＩＤに関連付けられた情報を含み、典型的には、ＤＩＤ主題とのインタラクションに関連する検証方法（公開鍵など）およびサービスを表す。ＤＩＤドキュメントは、特定の構文に従ってシリアル化され得る。ＤＩＤ自体は、ＩＤ特性の値である。ＤＩＤドキュメント内に存在する特性は、更新され得る。ＤＩＤ方法は、特定の検証可能データなレジストリを用いて特定のタイプのＤＩＤおよびその関連付けられたＤＩＤドキュメントが作成、解決、更新および非アクティブ化されるメカニズムである。ＤＩＤ方法は、別個のＤＩＤ方法仕様を用いて定義される。例示的な実施形態において、ＤＩＤ、ＶＣおよびＶＰ等は、検証可能なデータレジストリを含むブロックチェーン台帳に格納され得る。

ＤＩＤの所有者には、クレデンシャルプロバイダ（例えば、運転免許証を発行するＤＭＶ、成績証明書を発行する大学等）により、所有者のいくつかの特性を確立するＶＣが発行され得る。例示的な実施形態において、検証可能なクレデンシャルは、例えば、ブロックチェーンエンティティがエンドースピアであること、ブロックチェーンエンティティが特定の台帳上でのトランザクトを許可されていること、ブロックチェーンエンティティが特定のチェーンコードの実行／呼び出しを許可されていること等のクレデンシャルを保持するブロックチェーンエンティティの特性を確立し得る。この結合は、ＶＣ内に記録され得るデジタル署名を用いてセキュアかつ改ざん防止なものにされる。全体的に、ＤＩＤは、ＶＣ（満了時間を有する）よりも長い寿命を有する。例えばブロックチェーンピア、オーダラ、エンドーサ、クライアント等、任意のネットワークコンポーネントは、動作開始時にＤＩＤを取得する。その後、参加者は、ＳＳＩネットワークを含む認証局にＶＣを要求し、認証局からＶＣを取得できる。各ＶＣは、ブロックに含めるためのトランザクションへの署名または異なるネットワークと取引される資産状態への署名のような、異なる（かつ限定的な）目的を果たし得る。ＶＣが（ＶＰまたは検証可能なプレゼンテーションを用いて）どのように用いられ得るかは、ポリシーに依存することがある；例えば、トランザクションコミットメントポリシーは、ネットワークの一部である組織内のメンバーシップの証明に署名ピアを必要とする。

検証可能なクレデンシャルおよび検証可能なプレゼンテーションは、１つまたは複数の機械可読データフォーマット、例えば、ｃｏｍｍａ ｓｅｐａｒａｔｅｄ ｖａｌｕｅ（ＣＳＶ）ファイル、拡張可能マークアップ言語（ＸＭＬ）ファイルおよびＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）ファイル等でシリアル化可能であってよい。シリアル化および／または非シリアル化の処理は、決定論的、双方向性かつ無損失性であってよい。検証可能なクレデンシャルまたは検証可能なプレゼンテーションのあらゆるシリアル化は、結果として生じる検証可能なクレデンシャルが相互運用可能な方式で処理され得るように、決定論的な処理における一般的データモデルへ変換可能であってよい。また、シリアル化された形式は、データまたはコンテンツの損失なく、データモデルからの生成が可能であってよい。さらに、検証可能なプレゼンテーション（ＶＰ）は、検証可能なクレデンシャルの属性を開示し、または検証器により要求される導出された述語を満たすことができる。導出された述語は、例えば、よりも大きい、よりも少ない、に等しい、セット内である等のＢｏｏｌｅａｎ条件である。

例示的な実施形態において、ＤＩＤは、グローバルにではなく、ＤＩＤプロバイダのドメイン（またはより典型的には、レジストリ）内でのみ一意であることを保証され得る。許可型ネットワークまたは許可型ネットワークのグループが単一のＤＩＤレジストリを信頼することを決定した場合、そのセットアップ内のピアは、一意のＤＩＤを有することになる。そうでなければ、ピアのＤＩＤは、タプル＜ＤＩＤ Ｒｅｇｉｓｔｒｙ，ＤＩＤ＞によりグローバルに、一意に解決され得る。

ＳＳＩネットワークは、ＤＩＤ値によりインデックス化された記録を維持するＤＩＤレジストリを含む。加えて、ＳＳＩネットワークは、ＶＣのスキーマ（構造）および妥当性確認鍵を維持できる（Ｈｙｐｅｒｌｅｄｇｅｒ Ｉｎｄｙは、ＳＳＩコンセプトで構築されたそのようなＤＩＤレジストリの一例である）。ＶＣは、ＳＳＩネットワークレジストリに格納されているものにスキーマを合致させることにより、および、レジストリに格納された（ストレージは、分散型台帳自体であり得るが、必須ではない）公開鍵を用いてＶＣを発行する発行者のデジタル署名の妥当性を確認することにより、部分的に検証され得る。しかしながら、ＶＣ内のＤＩＤ所有者の特性についてのクレームへの信頼は、ひとたび妥当性が確認されると、バリデータがＶＣ発行者を信頼しているかどうかだけに依存する。

例示的な実施形態において、ＶＣ自体は、ＳＳＩネットワークのＤＩＤレジストリに格納されないが、むしろ、発行者から所有者／保有者へのピアツーピア通信を通じて発行され、所有者／保有者により格納される。ＶＣの妥当性確認および認証のために、ＶＣを受信する検証器は、ＤＩＤを一意識別子として用いて、ＶＣのＤＩＤレジストリ（ブロックチェーン）に格納されたスキーマおよび公開鍵を識別できる。ＶＣの特性であるタイムスタンプ自体は、レジストリに格納されない。しかしながら、台帳レジストリに記録されているものは、ＶＣ発行（またはＶＣ発行イベント）の事実である。そのようなイベントは、後の妥当性確認および監査に用いられ得る自動タイムスタンプを搬送する。ＳＳＩネットワークがどのように構成され得るかについての複数の変形例が可能である。１つの例において、内部構成は、認証局、ＭＳＰ等を有するブロックチェーンネットワークなど、異なるネットワークの既存のアイデンティティ発行者と重なったＳＳＩネットワークを含む。別の例として、ＳＳＩネットワークは、ブロックチェーンネットワークからは完全に別個／外部であるが異なるネットワークの既存のアイデンティティ発行者と緩やかに結合したネットワークであり得る。

図１Ａは、例示的な実施形態による自己主権型アイデンティティ（ＳＳＩ）を用いたブロックチェーンネットワーク１００を示す。図１Ａを参照すると、ブロックチェーンネットワーク１００は、ブロックチェーン台帳１５０、順序付けノード１５０およびクライアント１０２を管理する複数のブロックチェーンピア１１０、１２０、１３０および１４０を含む。図４の例に関してさらに説明されるように、クライアント１０２、ブロックチェーンピア１１０－１４０および順序付けノード１５０がメンバーシップを（例えば、認証局、メンバーシップサービスプロバイダ等を介して）ブロックチェーンネットワーク１００に登録する場合、クライアント１０２、ブロックチェーンピア１１０－１４０および順序付けノード１５０は、１つまたは複数の検証可能なクレデンシャルを受信し得る。例えば、クライアント１０２は、ＶＣ１０４を受信してよく、ブロックチェーンピア１１０、１２０、１３０および１４０はそれぞれ、ＶＣ１１２、２２、１３２および１４２を受信してよく、順序付けノード１５２は、ＶＣ１５２を受信してよい。

この例ではＶＣが１つだけ示されているが、図１Ａに示されるブロックチェーンエンティティのうちの１つまたは複数が複数のＶＣを受信し得ること、およびそのようなＶＣが異なる寿命、異なる用法、異なる作成時間等を有し得ることを理解されたい。例えば、ブロックチェーンピア１１０－１４０は、有しており実行／呼び出しをできる各チェーンコードについて、異なる／別個のＶＣを受信し得る。別の例として、ブロックチェーンピア１１０－１４０の各々は、アクセスを有しており内部に格納されている各台帳／台帳上のチャネルについて、異なる／別個のＶＣを受信し得る。

ＶＣは、ブロックチェーンエンティティの各々のクレデンシャルとして機能してよく、このクレデンシャルは、ブロックチェーンエンティティが、現在行っているアクションの実行を許可されていることを示す。例えば、図１Ａにおいて、クライアント１０２は、トランザクションをブロックチェーンピア１１０へ送信する。ここで、クライアント１０２のＶＣ１０４は、クライアント１０２をブロックチェーン１０５のメンバ／クライアントとして識別し得る。ＶＣ１０４は、例えばＣＡ、ＭＳＰ等、ＶＣ１０４の発行者により署名され得る。別の例として、ブロックチェーンピア１１０、１２０、１３０および１４０のＶＣ１１２、１２２、１３２および１４２は、ブロックチェーンピア１１０－１４０がブロックチェーン１０５のメンバであり、かつ、ブロックチェーン１０５の格納権利／チェーンコード実行機能を有することを識別し得る。一方、順序付けノード１５０のＶＣ１５２は、順序付けノード１５０をブロックチェーン１５０に格納されたブロックのオーダラとして識別し得る。ブロックチェーンエンティティ（クライアント１０２、ブロックチェーンピア１１０－１４０および順序付けノード１５０）の各々は、ネットワーク１００の内部で伝送されるメッセージ、トランザクション、提案、要求等へ、および外部エンティティ（示されていない）へそれぞれのＶＣをアタッチし得る。

図１Ｂは、例示的な実施形態によるブロックチェーンピア１１０の検証可能なクレデンシャル１１２の基本コンポーネントを示す図である。図１Ｂを参照すると、検証可能なクレデンシャル１１２は、クレデンシャルメタデータ１６０、１つまたは複数のクレーム１７０および１つまたは複数のクレーム１７０に関連付けられた１つまたは複数の証明１８０を含む、デジタルフォーマットの機械可読なファイル、コード、ドキュメント等を含み得る。検証可能なクレデンシャルは、対象／保有者のＤＩＤ、発行局（例えば、ＣＡ、ＭＳＰ等）に関連する情報、クレデンシャルのタイプについての情報、クレデンシャルの具体的な属性についての情報、クレデンシャルがどのように導出されたかに関連する情報、クレデンシャルに対する制約（使用条件、満了等）に関連する情報など、対象／保有者の識別子を含み得る。検証可能なクレデンシャルは、人間可読形式ではなく機械可読フォーマット（例えば、ＪＳＯＮ、ＸＭＬ、ＣＳＶ等）であることを除き、物理クレデンシャルと同じ情報を表し得る。

検証可能なクレデンシャルに含まれるクレーム１７０の一例は、ブロックチェーンネットワークのメンバであること、およびブロックチェーンネットワークのブロックチェーンにデータを格納する能力を有していることを主張するブロックチェーンピアである。別のタイプのクレーム１７０は、特定のチェーンコードへのアクセスを有すること、およびそのようなチェーンコードに基づいてクライアントからのトランザクションを実行できることを主張するブロックチェーンピアである。別のタイプのクレーム１７０は、ブロックチェーン台帳等の特定のチャネルのメンバ／参加者であることを主張するブロックチェーンピアである。検証可能なクレデンシャルにより作成され得る多くの他のクレームが存在し、各ブロックチェーンエンティティは、複数のＶＣを保持し得る。さらに、ＶＣは、新しいクレームの追加、クレームの修正、クレームの削除等を行うように更新されてよく、発行エンティティにより実行されてよい。

メタデータ１６０は、検証可能なクレデンシャル１１２の特性を記述したデータ、例えば、発行者、検証可能なクレデンシャル（例えば、ＪＳＯＮ、ＸＭＬ、ＣＳＶ等）のスキーマ、満了日／時間、クレデンシャルの画像、検証に用いられる公開鍵の識別子、取り消しメカニズム等を含み得る。証明１８０は、クレデンシャルの改ざんを発見可能にする発行者のデジタル署名を、この署名のデータ／時間、証明の目的およびこの署名を検証するための公開鍵の識別子等と共に含み得る。

図１Ｃはさらに、例示的な実施形態による検証可能なクレデンシャル１１２のクレーム１７０および証明１８０の詳細を示す。図１Ｂは、検証可能なクレデンシャル１１２の基本コンポーネントを示しているが、図１Ｃは、検証可能なクレデンシャル１１２がデータをどのように内部に格納するかについてのスキーマを示している。特に、クレーム１７０（およびメタデータ１６０）および証明１８０は、別個の情報グラフとして格納され得る。この例において、第１の情報グラフは、ＤＩＤノード１７２（保有者のＤＩＤ）に相互接続されたクレデンシャルＩＤノード１７１、（ＶＣ１１２を発行したＭＳＰの）発行者ＩＤノード１７３、クレデンシャルタイプ１７４（例えば、ブロックチェーンピアＶＣ、順序付けノードＶＣ、クライアントＶＣ、台帳ＶＣ、チェーンコードＶＣ等、クレデンシャルのアイデンティティ）、およびＶＣ１１２が作成された時間／日を含むタイムスタンプノード１７５を含む。第２の情報グラフは、検証可能なクレデンシャル１１２の発行者の署名を含む署名ＩＤノード１８１、署名コンテンツを含む署名値ノード１８２、公開鍵を識別する作成者ノード１８３、署名がいつ追加されたかを示すタイムスタンプノード１８４、およびデジタル署名のタイプ（例えば、ＲＳＡ、ＡＥＳ等）を識別する署名タイプノード１８５を含む。

図２Ａは、例示的な実施形態によるブロックチェーンアーキテクチャ構成２００を示す。図２Ａを参照すると、ブロックチェーンアーキテクチャ２００は、特定のブロックチェーン要素、例えば、ブロックチェーンノード２０２のグループを含み得る。ブロックチェーンノード２０２は、１つまたは複数のノード２０４－２１０を含み得る（これらの４つのノードは例としてのみ示されている）。これらのノードは、ブロックチェーントランザクション追加および妥当性確認プロセス（コンセンサス）など、複数のアクティビティに参加する。ブロックチェーンノード２０４－２１０のうちの１つまたは複数は、エンドースメントポリシーに基づいてトランザクションをエンドースしてよく、アーキテクチャ２００内の全てのブロックチェーンノードに順序付けサービスを提供してよい。ブロックチェーンノードは、ブロックチェーン認証を開始し、ブロックチェーン層２１６に格納されたブロックチェーン不変台帳への書き込みをしようとしてよく、そのコピーは、基礎となる物理的インフラストラクチャ２１４に格納されてもよい。ブロックチェーン構成は、格納されているプログラム／アプリケーションコード２２０（例えば、チェーンコード、スマートコントラクト等）にアクセスして実行するためにアプリケーションプログラミングインタフェース（ＡＰＩ）２２２にリンクされている１つまたは複数のアプリケーション２２４を含んでよく、格納されているプログラム／アプリケーションコード２２０は、参加者が求めるカスタマイズされた構成に従って作成でき、独自の状態を維持し、独自の資産を制御し、外部情報を受信することができる。これをトランザクションとして展開し、分散型台帳への追加を介して、全てのブロックチェーンノード２０４－２１０にインストールできる。

ブロックチェーンベースまたはプラットフォーム２１２は、ブロックチェーンデータ、サービス（例えば、暗号トラストサービス、仮想実行環境等）、および新しいトランザクションを受信および格納するために、かつ、データエントリにアクセスしようとしているオーディタにアクセスを提供するために用いられ得る基礎となる物理的コンピュータインフラストラクチャの、様々な層を含み得る。ブロックチェーン層２１６は、プログラムコードを処理して物理的インフラストラクチャ２１４に関与するために必要な仮想実行環境へのアクセスを提供するインタフェースを公開し得る。暗号トラストサービス２１８は、資産交換トランザクションなどのトランザクションを検証し、情報をプライベートに保つために用いられ得る。

図２Ａのブロックチェーンアーキテクチャ構成は、ブロックチェーンプラットフォーム２１２により公開される１つまたは複数のインタフェースおよび提供されるサービスを介してプログラム／アプリケーションコード２２０を処理および実行し得る。コード２２０は、ブロックチェーン資産を制御し得る。例えば、コード２２０は、データを格納および転送でき、ノード２０４－２１０により、スマートコントラクトおよび条件付きの関連付けられたチェーンコードまたはその実行の対象となる他のコード要素の形態で実行され得る。非限定的な例として、スマートコントラクトは、リマインダ、更新、および／または、変更、更新等の対象となる他の通知を実行するように作成され得る。スマートコントラクト自体は、許可およびアクセス要件および台帳の使用に関連付けられたルールを識別するために用いられ得る。例えば、スマートコントラクト（またはスマートコントラクトのロジックを実行するチェーンコード）は、ブロックチェーン層２１６に含まれる１つまたは複数の処理エンティティ（例えば、仮想マシン）により処理され得るブロックチェーンデータ２２６を読み取って、複雑なサービスシナリオ内で、アラートおよび責任の決定等を含む結果２２８を生成し得る。物理的インフラストラクチャ２１４を利用して、本明細書において説明されるデータまたは情報のいずれかを取得し得る。

スマートコントラクトは、高レベルのアプリケーションおよびプログラミング言語を介して作成され、次に、ブロックチェーン内のブロックに書き込まれ得る。スマートコントラクトは、ブロックチェーン（例えば、ブロックチェーンピアの分散型ネットワーク）で登録、格納および／または複製された実行可能コードを含み得る。トランザクションは、スマートコントラクトに関連付けられた条件が満たされていることに応答して実行され得るスマートコントラクトロジックの実行である。スマートコントラクトの実行により、デジタルブロックチェーン台帳の状態に対する信頼された修正がトリガされ得る。スマートコントラクトの実行により引き起こされたブロックチェーン台帳に対する修正は、１つまたは複数のコンセンサスプロトコルを通じて、ブロックチェーンピアの分散型ネットワーク全体にわたって自動的に複製され得る。

スマートコントラクトは、鍵値ペアのフォーマットでデータをブロックチェーンに書き込み得る。さらに、スマートコントラクトコードは、ブロックチェーンに格納された値を読み取り、これらをアプリケーション動作において用いることができる。スマートコントラクトコードは、様々な論理演算の出力をブロックチェーン内の１つまたは複数のブロック内に書き込むことができる。コードは、仮想マシンまたは他のコンピューティングプラットフォームにおいて、一時的なデータ構造を作成するために用いられ得る。ブロックチェーンに書き込まれたデータは、パブリックにでき、および／または暗号化してプライベートに維持できる。スマートコントラクトにより使用／生成された一時的なデータは、提供された実行環境によりメモリに保持され、次に、ひとたびブロックチェーンに必要なデータが識別されると、削除される。

チェーンコードは、スマートコントラクトのコード解釈（例えば、ロジック）を含み得る。例えば、チェーンコードは、スマートコントラクト内のロジックのパッケージ化された展開可能なバージョンを含み得る。本明細書において説明されるように、チェーンコードは、コンピューティングネットワーク上に展開されたプログラムコードであってよく、コンセンサス処理中に共に、チェーンバリデータにより、実行され、妥当性が確認される。チェーンコードは、ハッシュを受信し、以前に格納された特徴抽出器を使用して作成されたデータテンプレートに関連付けられたハッシュをブロックチェーンから取得し得る。ハッシュ識別子のハッシュ、および格納された識別子テンプレートデータから作成されたハッシュが合致する場合、チェーンコードは、要求されたサービスへ許可鍵を送信する。チェーンコードは、暗号詳細に関連付けられているブロックチェーンデータに書き込まれてよい。

図２Ｂは、例示的な実施形態による、ブロックチェーンのノード間のブロックチェーントランザクションフロー２５０の一例を示す。図２Ｂを参照すると、トランザクションフローは、エンドースピアノード２８１にトランザクション提案２９１を伝送するクライアントノード２６０を含み得る。エンドースピア２８１は、クライアント署名を検証し、チェーンコード関数を実行して、トランザクションを開始し得る。出力は、チェーンコードの結果、チェーンコードで読み取られた鍵／値バージョンのセット（読み取りセット）、およびチェーンコードに書き込まれた鍵／値のセット（書き込みセット）を含み得る。ここで、エンドースピア２８１は、トランザクション提案をエンドースするかどうかを判断し得る。提案応答２９２は、承認された場合、エンドースメント署名と共にクライアント２６０に返送される。クライアント２６０は、エンドースメントをトランザクションペイロード２９３にアセンブルし、それを順序付けサービスノード２８４にブロードキャストする。次に、順序付けサービスノード２８４は、順序付けされたトランザクションをブロックとしてチャネル上の全てのピア２８１－２８３に配信する。ブロックチェーンにコミットする前に、各ピア２８１－２８３はトランザクションの妥当性を確認し得る。例えば、指定されたピアの正しい割り当てが、結果に署名し、トランザクションペイロード２９３に対する署名を認証したことを保証するように、ピアはエンドースメントポリシーをチェックしてよい。

図２Ｂを再び参照すると、クライアントノードは、要求を構築してエンドーサであるピアノード２８１に要求を送信することにより、トランザクション２９１を開始する。クライアント２６０は、利用可能なＡＰＩを利用してトランザクション提案を生成する、サポートされたソフトウェア開発キット（ＳＤＫ）を活用するアプリケーションを含み得る。提案は、データを台帳から読み取りおよび／または書き込む（すなわち、資産のための新しい鍵値ペアを書き込む）ことができるように、チェーンコード関数を呼び出すための要求である。ＳＤＫは、トランザクション提案を適切に設計されたフォーマット（例えば、リモートプロシージャコール（ＲＰＣ）に対するプロトコルバッファ）へパッケージ化し、トランザクション提案のための一意の署名を生成するために、クライアントの暗号クレデンシャルを取得するシムとして機能してよい。

これに応答して、エンドースピアノード２８１は、（ａ）トランザクション提案が整形式であること、（ｂ）トランザクションが、過去にまだサブミットされていないこと（リプレイアタック保護）、署名が有効であること、（ｄ）サブミッタ（この例では、クライアント２６０）がそのチャネル上で提案される動作を実行するのを適切に許可されていることを検証してよい。エンドースピアノード２８１は、トランザクション提案入力を、呼び出されるチェーンコード関数に対する引数として取得してよい。次に、チェーンコードは、現在の状態データベースに対して実行され、応答値、読み取りセットおよび書き込みセットを含むトランザクション結果を生成する。しかしながら、この時点では台帳は更新されていない。２９２において、値のセットは、エンドースピアノード２８１の署名と共に、アプリケーションが消費するペイロードを解析するクライアント２６０のＳＤＫに提案応答２９２として返される。

これに応答して、クライアント２６０のアプリケーションは、エンドースピアの署名を検査／検証し、提案応答が同じであるかどうかを判断するためにそれらの提案応答を比較する。チェーンコードが台帳のみをクエリした場合、アプリケーションはクエリ応答を検査し、典型的にはトランザクションを順序付けノードサービス２８４にサブミットしない。クライアントアプリケーションが、台帳を更新するために、トランザクションを順序付けノードサービス２８４にサブミットすることを意図する場合、アプリケーションは、サブミットの前に、指定されたエンドースメントポリシーが満たされているかどうか（すなわち、トランザクションに必要な全てのピアノードがトランザクションをエンドースしたか）を判断する。ここで、クライアントは、トランザクションに対する複数の当事者のうちの１つのみを含み得る。この場合、各クライアントは独自のエンドースノードを有してよく、各エンドースノードはトランザクションをエンドースする必要がある。このアーキテクチャは、アプリケーションが応答を検査しないことを選択するか、または、そうでなければ、エンドースされていないトランザクションを転送する場合でも、依然としてエンドースメントポリシーはピアによって実施され、コミット妥当性確認フェーズで維持されるようになっている。

検査が成功した後、段階２９３で、クライアント２６０はエンドースメントをトランザクション提案にアセンブルし、トランザクションメッセージ内のトランザクション提案および応答を順序付けノード２８４にブロードキャストする。トランザクションは、読み取り／書き込みセット、エンドースピア署名およびチャネルＩＤを含み得る。順序付けノード２８４は、その動作を実行すべくトランザクションのコンテンツ全体を検査する必要はなく、その代わりに、順序付けノード２８４は、単にネットワーク内の全てのチャネルからトランザクションを受信し、これらをチャネル毎に時系列で順序付けし、チャネルあたりのトランザクションのブロックを作成してもよい。

ブロックは、順序付けノード２８４からチャネル上の全てのピアノード２８１－２８３に配信される。エンドースメントポリシーが満たされていることを保証し、読み取りセットがトランザクション実行によって生成されて以降、読み取りセット変数の台帳の状態が変更されていないことを保証するために、ブロック内のデータセクションの妥当性が確認され得る。さらに、段階２９５で、各ピアノード２８１－２８３はブロックをチャネルのチェーンに追加し、有効なトランザクションの各々について、書き込みセットが現在の状態データベースにコミットされる。トランザクション（呼び出し）が不変にチェーンに追加されたことをクライアントアプリケーションに通知するために、およびトランザクションが有効化されたか無効化されたかを通知するために、イベントが発行され得る。

図２Ｂの例において、クライアントノード２６０、およびブロックチェーンピア２８１－２８４の各々は、検証可能なクレデンシャルを署名として用い得る。トランザクションが図２Ｂの異なる段階を進むとき、クライアントノード２６０およびブロックチェーンピア２８１－２８４の各々は、実行した段階にそれぞれのＶＣをアタッチし得る。この例において、ブロックチェーンピア２８１－２８４の各々は、ブロックチェーンピア２８１－２８４に関連付けられたアイデンティティおよびメンバーシップ情報を提供するＶＣのセット（例えば、１つまたは複数のＶＣ）を含み得る。例えば、クライアントノード２６０は、クライアントをブロックチェーン上でトランザクトするためのメンバとして識別するブロックチェーンネットワークのＭＳＰにより発行されるクレーム付きの検証可能な証明書を含み得る。別の例として、ブロックチェーンピア２８１－２８３は、ブロックチェーンピア２８１－２８３をブロックチェーンのエンドースピアとして識別するＶＣを含み得る。一方、ブロックチェーンピア２８４は、ブロックチェーンピア２８４をブロックチェーンの順序付けノードとして識別するＶＣを含み得る。多くの他のＶＣが可能である。例えば、ブロックチェーン（例えば、同じ台帳上の異なるブロックチェーン）上の特定のチャネルは、クライアント、ピア、エンドーサおよびオーダラ等として機能すべく、異なるＶＣを必要とし得る。別の例として、異なるタイプのトランザクションおよび／またはチェーンコードは、クライアント、ピア等による別個のＶＣを必要とし得る。例えば、クライアントは、特定のチェーンコードを用いる権限をクライアントが有していることを識別するＶＣを有する場合、トランザクションをサブミットするだけでそのようなチェーンコードを呼び出し得る。

図３Ａは、分散型の非集中的なピアツーピアアーキテクチャを特徴とする、許可型ブロックチェーンネットワーク３００の一例を示している。この例では、ブロックチェーンユーザ３０２は、許可型ブロックチェーン３０４に対するトランザクションを開始してよい。この例では、トランザクションを展開、呼び出し、またはクエリでき、ＡＰＩ等を通じて直接、ＳＤＫを活用してクライアント側アプリケーションを通じて発行してよい。ネットワークは、オーディタなどのレギュレータ３０６へのアクセスを提供してよい。ブロックチェーンネットワークオペレータ３０８は、レギュレータ３０６を「オーディタ」として登録し、ブロックチェーンユーザ３０２を「クライアント」として登録するなど、メンバ許可を管理する。オーディタは台帳のクエリのみに制限され得る一方で、クライアントには、特定のタイプのチェーンコードの展開、呼び出しおよびクエリを許可され得る。

ブロックチェーン開発者３１０は、チェーンコードおよびクライアント側アプリケーションを書き込むことができる。ブロックチェーン開発者３１０は、インタフェースを通じてネットワークに直接チェーンコードを展開できる。従来のデータソース３１２からのクレデンシャルをチェーンコードに含めるために、開発者３１０は帯域外接続を使用してデータにアクセスし得る。この例では、ブロックチェーンユーザ３０２は、ピアノード３１４を通じて許可型ブロックチェーン３０４に接続する。任意のトランザクションに進む前に、ピアノード３１４は、ユーザの役割および許可を管理する認証局３１６からユーザの登録証明書およびトランザクション証明書を取得する。いくつかの事例において、ブロックチェーンユーザは、許可型ブロックチェーン３０４上でトランザクトすべく、これらのデジタル証明書を所有していなければならない。一方、チェーンコードの利用を試みるユーザは、自身のクレデンシャルを従来のデータソース３１２上で検証する必要があり得る。ユーザの許可を確認するために、チェーンコードは、従来の処理プラットフォーム３１８を通じたこのデータへの帯域外接続を使用できる。

図３Ｂは、分散型の非集中的なピアツーピアアーキテクチャを特徴とする、許可型ブロックチェーンネットワーク３２０の別の例を示している。この例では、ブロックチェーンユーザ３２２は、トランザクションを許可型ブロックチェーン３２４にサブミットしてよい。この例では、トランザクションを展開、呼び出し、またはクエリでき、ＳＤＫを活用するクライアント側アプリケーションを通じて、ＡＰＩを直接通じて等、発行してよい。ネットワークは、オーディタなどのレギュレータ３２６へのアクセスを提供してよい。ブロックチェーンネットワークオペレータ３２８は、レギュレータ３２６を「オーディタ」として登録し、ブロックチェーンユーザ３２２を「クライアント」として登録するなど、メンバ許可を管理する。オーディタは台帳のクエリのみに制限され得る一方で、クライアントには特定のタイプのチェーンコードの展開、呼び出しおよびクエリが許可され得る。

ブロックチェーン開発者３３０は、チェーンコードおよびクライアント側アプリケーションを書き込んでよい。ブロックチェーン開発者３３０は、インタフェースを通じてネットワークに直接チェーンコードを展開できる。従来のデータソース３３２からのクレデンシャルをチェーンコードに含めるために、開発者３３０は帯域外接続を使用してデータにアクセスし得る。この例では、ブロックチェーンユーザ３２２は、ピアノード３３４を通じてネットワークに接続する。任意のトランザクションを進める前に、ピアノード３３４は、認証局３３６から、ユーザの登録およびトランザクション証明書を取得する。いくつかの事例において、ブロックチェーンユーザは、許可型ブロックチェーン３２４上でトランザクトすべく、これらのデジタル証明書を所有していなければならない。一方、チェーンコードの利用を試みるユーザは、自身のクレデンシャルを従来のデータソース３３２上で検証する必要があり得る。ユーザの許可を確認するために、チェーンコードは、従来の処理プラットフォーム３３８を通じたこのデータへの帯域外接続を使用できる。

いくつかの実施形態において、本明細書のブロックチェーンは非許可型ブロックチェーンであり得る。参加するのに許可が必要な許可型ブロックチェーンとは対照的に、非許可型ブロックチェーンには誰でも参加できる。例えば、非許可型ブロックチェーンに参加するために、ユーザは個人アドレスを作成し、トランザクションをサブミットして台帳にエントリを追加することにより、ネットワークとのインタラクトを開始し得る。追加的に、全ての当事者は、システム上でノードを実行し、トランザクションを検証するのに役立つマイニングプロトコルを使用することを選択できる。

図３Ｃは、複数のノード３５４を含む非許可型ブロックチェーン３５２によって処理されるトランザクションのプロセス３５０を示している。送信者３５６は、非許可型ブロックチェーン３５２を介して受信者３５８に支払いまたは他の何らかの形態の価値（例えば、証書、医療記録、コントラクト、商品、サービス、またはデジタル記録にカプセル化できる任意のその他の資産）を送信することを所望する。１つの実施形態において、送信者デバイス３５６および受信者デバイス３５８の各々は、ユーザインタフェース制御およびトランザクションパラメータの表示を提供する（ブロックチェーン３５２に関連付けられた）デジタルウォレットを有し得る。これに応答して、トランザクションは、ブロックチェーン３５２の全体にわたってノード３５４にブロードキャストされる。ブロックチェーン３５２のネットワークパラメータに応じて、ノードは非許可型ブロックチェーン３５２の作成者によって確立されたルール（予め定義され得るか、または動的に割り当てられ得る）に基づいてトランザクションを検証する（３６０）。例えば、これには、関与する当事者のアイデンティティの検証等が含まれ得る。トランザクションは直ちに検証され得るか、または他のトランザクションと共にキューに入れられてよく、ノード３５４はネットワークルールのセットに基づいてトランザクションが有効かどうかを判断する。

構造３６２において、有効なトランザクションは、ブロックへと形成され、ロック（ハッシュ）でシールされる。この処理は、ノード３５４の間のマイニングノードによって実行されてよい。マイニングノードは、特に非許可型ブロックチェーン３５２のブロックをマイニングおよび作成するために、追加のソフトウェアを利用し得る。各ブロックは、ネットワークによって同意されたアルゴリズムを使用して作成されたハッシュ（例えば、２５６ビット数等）によって識別され得る。各ブロックには、ヘッダ、チェーン内の先行ブロックのヘッダのハッシュへのポインタまたは参照、および有効なトランザクションのグループが含まれ得る。先行ブロックのハッシュへの参照は、ブロックのセキュアで独立したチェーンの作成に関連付けられている。

ブロックをブロックチェーンに追加できるようになる前に、ブロックの妥当性が確認されなければならない。非許可型ブロックチェーン３５２の妥当性確認は、ブロックのヘッダから導出されるパズルへの解答であるプルーフオブワーク（ＰｏＷ）を含み得る。図３Ｃの例には示されていないが、ブロックの妥当性を確認する別のプロセスはプルーフオブステークである。アルゴリズムが数学的問題を解決したマイナに報酬を与えるプルーフオブワークとは異なり、プルーフオブステークでは、新しいブロックの作成者は、「ステーク」とも定義される富に応じて決定論的な態様で選出される。次に、選択／選出されたノードによって同様の証明が実行される。

マイニング３６４では、ノードは、解答がネットワークワイドターゲットを満たすまで、１つの変数にインクリメンタルな変更を行うことによって、ブロックを解決しようとする。これによりＰｏＷが作成され、それにより、正解が保証される。言い換えると、潜在的な解は、問題を解決するためにコンピューティングリソースが枯渇したことを証明しなければならない。いくつかのタイプの非許可型ブロックチェーンでは、マイナはブロックを正しくマイニングすることで価値（例えば、コイン等）の報酬を受け取り得る。

ここで、ＰｏＷ処理は、ブロックをチェーンにしながら、攻撃者が１つのブロックの修正が受け入れられるようにするために全ての後続ブロックを修正しなければならないことで、ブロックチェーンの修正を極めて困難にする。さらに、新しいブロックがマイニングされると、ブロックを修正することの困難さが高まり、後続ブロックの数が増加する。分散３６６では、正常に妥当性が確認されたブロックが非許可型ブロックチェーン３５２を通じて分散され、全てのノード３５４がブロックを非許可型ブロックチェーン３５２の監査可能な台帳である多数派チェーンに追加する。さらに、送信者３５６によってサブミットされたトランザクションの値は、受信者デバイス３５８のデジタルウォレットに入金または、そうでなければ、転送される。

図４は、例示的な実施形態による、検証可能なクレデンシャルを発行する処理４００を示す。図４を参照すると、複数の組織４２０がブロックチェーン台帳４３０（例えば、１つまたは複数のブロックチェーン状態データベース等）を共有している。各組織４２０は、複数の組織４２０間で共有されるブロックチェーン台帳４３０のブロックチェーン上でトランザクションを実行する１つまたは複数のピア４２２を有し得る。様々な実施形態によれば、複数の組織４２０は、ブロックチェーン台帳４３０に関連する内部または外部ネットワークであってよいＳＳＩネットワーク４１０とインタラクトし得る。ＳＳＩネットワーク４１０は、ＣＡ、ＭＳＰ、ａｄｍｉｎおよび他の信頼できるエンティティなど、複数のアイデンティティプロバイダ４１２（信頼できるソース）を含み得る。アイデンティティプロバイダ４１２は、ＤＩＤおよびＶＣをピア組織４２０のピア４２２に提供し得る。ＶＣおよびＤＩＤは、ＳＳＩネットワークのレジストリ４１４に格納され得る。いくつかの実施形態において、レジストリ４１４は、別個のブロックチェーン台帳であってよいが、これに限定されない。

レジストリ４１４は、ＤＩＤにより識別されるデータを格納し得る。例えば、レジストリ４１４は、ＤＩＤ値によりインデックス付けされた記録を格納し得る。加えて、レジストリ４１４は、ＶＣのスキーマ（構造）および妥当性確認鍵を維持できる。ＶＣは、レジストリ４１４に格納されているものへそのスキーマを合致させることにより、および、レジストリ４１４に格納されるＶＣを発行する発行者の公開鍵を用いてデジタル署名の妥当性を確認することにより、部分的に検証され得る。しかしながら、ＶＣ内のＤＩＤ所有者の特性についてのクレームへの信頼は、ひとたび妥当性が確認されると、バリデータがＶＣ発行者を信頼しているかどうかだけに依存する。ブロックチェーンピア４２０の各々は、内部にインストールされたＳＳＩエージェント４２４を含み得る。ＳＳＩエージェント４２４は、それぞれのコンポーネントのクレデンシャルの「ウォレット」を維持するための追加のソフトウェアであってよく、指定されたＳＳＩネットワークと、また、他のネットワークに属するコンポーネントと通信する。この機能の一部は、ブロックチェーンに固有である。なぜなら、所与のネットワークにそのコンポーネントが適合する場所の認識、および、外部ブロックチェーンネットワーク（ＳＳＩネットワークを含む）とどのように通信するかについての理解を伴うからである。この機能の他の一部は、ブロックチェーンではなく、ＤＩＤ管理に固有である。

例示的な実施形態において、ＤＩＤ、改ざん発見、クレームの検証可能なセットを拡張する検証可能なクレデンシャル（ＶＣ）は、発行者により作成される。特定の検証器と共有される特定のクレデンシャルの属性を提示するために、検証可能なプレゼンテーション（ＶＰ）は、ＶＣから導出され得る。いくつかの実施形態において、ＶＣは、元のクレデンシャル（例えば、ゼロ知識証明等）から合成されたデータを含み得る。検証可能なデータレジストリは、ＶＣの妥当性を確認するための情報を取得すべく、検証器とインタラクトされ得る。レジストリは、アイデンティティ、クレデンシャルスキーマ等の作成および検証を媒介する。ＤＩＤもＶＣに含まれ得る。ＤＩＤは、ブロックチェーンネットワークコンポーネントを識別するために用いられ得る。プライベートブロックチェーンネットワーク（Ｆａｂｒｉｃ、Ｃｏｒｄａ等）では、クライアントおよび全てのアクティブコンポーネントがアイデンティティを有する。Ｆａｂｒｉｃピアおよびオーダラは、アイデンティティを有する。例示的な実施形態において、ブロックチェーンネットワークの全てのアイデンティティは、ＳＳＩアイデンティティネットワークにより管理される。ＳＳＩネットワークにより、ブロックチェーンネットワークに参加する全てのアイデンティティのクレデンシャルの発行および検証が容易になる。ブロックチェーンネットワークコンポーネントは、ＳＳＩネットワークにより管理されるアイデンティティにマッピングされる。

アイデンティティデータ（実際のアイデンティティネットワーク）は、同じまたは外部ネットワーク内でホストされ得る。この技術は、ブロックチェーンを必要としない（アーキテクチャおよび動作に関する選択）。しかしながら、外部オプションを用いるいくつかの利点が存在する。例えば、外部ネットワークは、ネットワーク間交換のためのブリッジ（またはメディエータ）として機能しつつ、複数のネットワークのアイデンティティネットワークとして機能し得る。外部ネットワークにより、組織または大型エコシステムにわたるアイデンティティ管理の統合および単純化が可能になる。このアイデンティティメカニズムにより、全体的な外部ネットワークベースの構成管理メカニズムが可能になる。いくつかの実施形態において、組織は、ＳＳＩ発行者（ＣＡと同様）により表される。

例示的な実施形態において、発行者は、自己が管理するネットワークコンポーネント（ピア等）にアイデンティティを提供する。ネットワーク信頼モデルは、発行者（組織）間の信頼を確立することにより形成される。これは、ＳＳＩネットワークの初期のセットアップを表す。ＳＳＩネットワークは、動的モデルであってよく、これにより、いつでも変更が可能になる。拡張により、発行者により発行されるアイデンティティ／ＶＣは、検証器により信頼される。全てのネットワークコンポーネントは、機能の妥当性確認を実行するときに検証器の役割を果たし得る。

ブロックチェーンネットワーク用に新しく構成されているブロックチェーンピアなど、アクティブコンポーネントの構成を実行するために、デフォルトセットアップが行われ得る。ここで、アクティブコンポーネントは、ウォレットまたは同様のメカニズムを有し得る。各コンポーネントには、自己が属する組織／発行者により管理されるＤＩＤが割り当てられ得る。別の例として、各コンポーネントには、初期暗号マテリアルが割り当てられ得る。各コンポーネントは、ＳＳＩアイデンティティネットワークへの接続の構成を有し得る。初期セットアップ／起動中、コンポーネントは、そのＤＩＤ／暗号マテリアルを用いて、初期ＶＣを取得する。組織のニーズに応じて、コンポーネントは、様々な台帳、スマートコントラクト、トランザクション等に必要な複数のＶＣまたはＶＰを発行できる。発行者およびネットワークは、ＴＸ／ブロックに署名するためにどのタイプのクレデンシャルが用いられなければならないか等を定義するアイデンティティ発行ポリシーを有する。コンポーネントは、このポリシーに基づいてアイデンティティ関連機能を実行する（必要な場合にＶＣ／ＶＰを取得する）ＳＳＩエージェントを含み得る。これにより、動的構成、およびＴＸ、ブロック等を処理するために用いられるクレデンシャルの更新が可能になる。

ＳＳＩ決定性は、課題を含み得る。ＶＣ／ＶＰは、経時的変化、満了、更新等をし得る。ＳＳＩネットワークは、更新され得る（取り消しリスト等）。台帳の遡及的な妥当性確認のために、ＶＣ／ＶＰは、ＴＸ処理時点と同じく分解可能かつ検証可能でなければならない。ＶＣ／ＶＰの状態、およびＴＸの条件。ここで、ＶＣ／ＶＰは、満了タイムスタンプを有し得る。ＴＸは、ネットワークにわたる調整されたタイムスタンプである。ネットワークは、単一の代表的なタイムスタンプに収束し得る。ＴＸピアのタイムスタンプは、ピアノ特定のデルタ内（特定のネットワーク用に構成可能）でなければならない。ＴＸ処理メカニズムにより、ＴＸ内で用いられる全てのＶＣ／ＶＰについてタイムスタンプの妥当性が確認されることが保証される（満了は、他の有効性チェックは別にして、ＴＸよりも後でなければならない）。トランザクションの作成中に用いられるＶＣ／ＶＰは、そのトランザクションに含まれ、ヘッダ（ＴＸまたはブロック）に格納／アタッチされる。格納された表現は、検証可能なサブセット（例えば、ＶＣの特定のＶＰ）であり得る。ＶＣ／ＶＰおよびタイムスタンプを台帳に含めることで、後の状態変化にかかわらず、遡及的な妥当性確認が可能になる。

ＳＳＩネットワークの状態は、経時的に変化し得る。台帳の妥当性確認をサポートするために、ＳＳＩネットワークは、遡及的なクエリおよび妥当性確認の機能をサポートするように拡張され得る。ＳＳＩネットワークは、ブロックチェーン／台帳（または同様のもの）など、検証可能な過去の状態を独自に含み得る。ＳＳＩネットワークプロトコル／ＡＰＩは、時間拘束の妥当性確認を可能にするように拡張され得る。例示的な実施形態は、タイムスタンプをＡＰＩ関数の引数として含み得る。タイムスタンプ引数は、表される時間において有効なアーティファクトの状態を取得するために用いられ得る。ネットワーク間の合成の欠如を可能にするためにクエリにおいて用いられるデルタ引数も存在し得る。

図５は、例示的な実施形態による、検証可能なクレデンシャルを用いてブロックチェーントランザクションを実行する方法５００を示す。非限定的な例として、方法５００は、ブロックチェーン台帳等を管理するブロックチェーンピアにより実行され得る。図５を参照すると、５１０において、方法は、ブロックチェーンネットワークへの格納の要求を受信する段階を含み得る。一例として、この要求は、ブロックチェーンに対するブロックチェーントランザクションの実行、エンドース、コミット等を含み得る。別の例として、この要求は、ブロックチェーンにコミットされるブロックにおいて順序付けおよび格納される複数のトランザクションを含み得る。

５２０において、方法は、自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成された検証可能なクレデンシャルを署名としてブロックチェーントランザクションへブロックチェーンノードを介してアタッチする段階を含んでよく、検証可能なクレデンシャルは、要求に署名したブロックチェーンノードのクレーム、および検証可能なクレデンシャルを作成したＳＳＩネットワークの証明を含む。ここで、ブロックチェーンノードは、ブロックチェーントランザクションを実行してよく、例えば、ブロックチェーンの現在の状態に対しトランザクションの１つまたは複数のパラメータをシミュレートして応答を生成してよい。ブロックチェーンノードは、ＶＣをトランザクションの実行結果にアタッチし、実行された結果およびアタッチされたＶＣを別のブロックチェーンピア、クライアント、オーダラ等へ伝送し得る。５３０において、方法は、ブロックチェーントランザクションおよびアタッチされた検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送する段階を含み得る。さらに、５４０において、方法は、ブロックチェーントランザクションおよびアタッチされた検証可能なクレデンシャルをブロックチェーン上のデータブロックを介して格納する段階を含み得る。

いくつかの実施形態において、検証可能なクレデンシャルは、ブロックチェーンノードを一意に識別する非集中型識別子（ＤＩＤ）を含み得る。いくつかの実施形態において、要求は、ブロックチェーンのチェーンコードの実行の要求を含んでよく、検証可能なクレデンシャルは、チェーンコードの実行を許可されているブロックチェーンピアとしてブロックチェーンノードを識別するクレームを内部に含んでよい。いくつかの実施形態において、検証可能なクレデンシャルは、それがいつ作成されたかについてのタイムスタンプ、および満了値を含み得る。いくつかの実施形態において、方法は、修正された検証可能なクレデンシャルをＳＳＩネットワークから受信する段階をさらに含んでよく、修正された検証可能なクレデンシャルは、それに追加された新しいクレーム、新しいクレームがいつ作成されたかについてのタイムスタンプ、および満了値を含む。

いくつかの実施形態において、要求は、複数のブロックチェーントランザクションの順序付け要求を含んでよく、署名することは、新しいブロック内の複数のブロックチェーントランザクションを順序付けること、および、ブロックチェーンノードがブロックチェーンの順序付けノードであることを示す検証可能なクレデンシャルを用いて新しいブロックに署名することを含む。いくつかの実施形態において、要求は、予め定義されたブロックチェーン台帳、台帳のチャネル等へのブロックの追加の要求を含んでよく、検証可能なクレデンシャルは、このブロックを予め定義されたブロックチェーン台帳等に格納することを許可されているブロックチェーンピアとしてブロックチェーンノードを識別するクレームを内部に格納する。いくつかの実施形態において、要求は、クライアントから受信されるブロックチェーンエントリを含んでよく、署名は、ブロックチェーンエントリのエンドースメントを含み、検証可能なクレデンシャルは、このブロックチェーンノードをブロックチェーンのエンドースピアとして識別する。

図６Ａは、例示的な実施形態による、様々な動作を実行するように構成された物理的インフラストラクチャ６１０を含む例示的なシステム６００を示す。図６Ａを参照すると、物理的インフラストラクチャ６１０は、モジュール６１２およびモジュール６１４を含む。モジュール６１４は、ブロックチェーン６２０およびスマートコントラクト６３０（ブロックチェーン６２０上に存在し得る）を含み、例示的な実施形態のいずれかに含まれる（モジュール６１２内の）動作段階６０８のいずれかを実行し得る。段階／動作６０８は、説明または図示された実施形態のうちの１つまたは複数を含んでよく、１つまたは複数のスマートコントラクト６３０および／またはブロックチェーン６２０に書き込まれる出力または、それらから読み取られる書き込まれた情報を表し得る。物理的インフラストラクチャ６１０、モジュール６１２およびモジュール６１４は、１つまたは複数のコンピュータ、サーバ、プロセッサ、メモリおよび／または無線通信デバイスを含み得る。さらに、モジュール６１２およびモジュール６１４は、同じモジュールであり得る。

図６Ｂは、例示的な実施形態による、様々な動作を実行するように構成された別の例示的なシステム６４０を示す。図６Ｂを参照すると、システム６４０は、モジュール６１２およびモジュール６１４を含む。モジュール６１４は、ブロックチェーン６２０およびスマートコントラクト６３０（ブロックチェーン６２０上に存在し得る）を含み、例示的な実施形態のいずれかに含まれる（モジュール６１２内の）動作段階６０８のいずれかを実行し得る。段階／動作６０８は、説明または図示された実施形態のうちの１つまたは複数を含んでよく、１つまたは複数のスマートコントラクト６３０および／またはブロックチェーン６２０に書き込まれる出力または、それらから読み取られる書き込まれた情報を表し得る。物理的インフラストラクチャ６１０、モジュール６１２、およびモジュール６１４は、１つまたは複数のコンピュータ、サーバ、プロセッサ、メモリおよび／または無線通信デバイスを含み得る。さらに、モジュール６１２およびモジュール６１４は、同じモジュールであり得る。

図６Ｃは、例示的な実施形態による、コントラクト当事者間でスマートコントラクト構成を利用するように構成された例示的なシステムおよび、ブロックチェーン上でスマートコントラクト条件を実行するように構成された媒介サーバを示す。図６Ｃを参照すると、構成６５０は、１つまたは複数のユーザデバイス６５２および／または６５６を明示的に識別するスマートコントラクト６３０によって駆動される、通信セッション、資産移転セッション、またはプロセスまたは手順を表し得る。スマートコントラクト実行の実行、動作および結果は、サーバ６５４によって管理され得る。スマートコントラクト６３０のコンテンツは、スマートコントラクトトランザクションの当事者であるエンティティ６５２および６５６のうちの１つまたは複数によるデジタル署名を必要とし得る。スマートコントラクト実行の結果は、ブロックチェーントランザクションとしてブロックチェーン６２０に書き込まれ得る。スマートコントラクト６３０は、１つまたは複数のコンピュータ、サーバ、プロセッサ、メモリおよび／または無線通信デバイス上に存在し得るブロックチェーン６２０上に存在する。

図６Ｄは、例示的な実施形態による、ブロックチェーンを含むシステム６６０を示す。図６Ｄの例を参照すると、アプリケーションプログラミングインタフェース（ＡＰＩ）ゲートウェイ６６２は、ブロックチェーンロジック（例えば、スマートコントラクト６３０またはその他のチェーンコード）およびデータ（例えば、分散型台帳等）にアクセスするための共通インタフェースを提供する。この例では、ＡＰＩゲートウェイ６６２は、１つまたは複数のエンティティ６５２および６５６をブロックチェーンピア（すなわち、サーバ６５４）に接続することによって、ブロックチェーン上でトランザクション（呼び出し、クエリ等）を実行するための共通インタフェースである。ここで、サーバ６５４は、クライアント６５２および６５６がワールドステートに関するデータをクエリし、スマートコントラクト６３０およびエンドースメントポリシーに応じて、エンドースピアがスマートコントラクト６３０を実行するブロックチェーンネットワーク内にトランザクションのサブミットを可能にする、ワールドステートおよび分散型台帳のコピーを保持するブロックチェーンネットワークピアコンポーネントである。

上記の実施形態は、ハードウェア内、プロセッサによって実行されるコンピュータプログラム内、ファームウェア内、または上記の組み合わせ内で実装され得る。コンピュータプログラムは、記憶媒体など、コンピュータ可読媒体上で具現化され得る。例えば、コンピュータプログラムは、ランダムアクセスメモリ（「ＲＡＭ」）、フラッシュメモリ、リードオンリメモリ（「ＲＯＭ」）、消去可能プログラマブルリードオンリメモリ（「ＥＰＲＯＭ」）、電気的消去可能プログラマブルリードオンリメモリ（「ＥＥＰＲＯＭ」）、レジスタ、ハードディスク、リムーバブルディスク、コンパクトディスクリードオンリメモリ（「ＣＤ－ＲＯＭ」）、または当技術分野で知られている任意の他の形態の記憶媒体内に存在し得る。

例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込み得るように、プロセッサに結合され得る。代替的に、記憶媒体は、プロセッサに一体化され得る。プロセッサおよび記憶媒体は、特定用途向け集積回路（「ＡＳＩＣ」）内に存在し得る。代替的に、プロセッサおよび記憶媒体は、個別コンポーネントとして存在し得る。

図７Ａは、例示的な実施形態による、新しいブロックが分散型台帳７２０に追加される処理７００を示しており、図７Ｂは、例示的な実施形態による、ブロックチェーンのための新しいデータブロック構造７３０のコンテンツを示している。図７Ａを参照すると、クライアント（不図示）は、トランザクションをブロックチェーンノード７１１、７１２および／または７１３にサブミットし得るクライアントは、任意のソースから受信される、ブロックチェーン７２０上でアクティビティを実行する命令であってよい。一例として、クライアントは、ブロックチェーンにトランザクションを提案するように、デバイス、人物、またはエンティティなどの要求者の代理で動作するアプリケーションであってよい。複数のブロックチェーンピア（例えば、ブロックチェーンノード７１１、７１２および７１３）は、ブロックチェーンネットワークの状態および分散型台帳７２０のコピーを維持してよい。クライアントによって提案されたトランザクションをシミュレートしてエンドースするエンドースピア、および、エンドースメントを検証し、トランザクションの妥当性を確認し、トランザクションを分散型台帳７２０にコミットするコミッティングピアを含む、異なるタイプのブロックチェーンノード／ピアが、ブロックチェーンネットワーク内に存在してよい。この例では、ブロックチェーンノード７１１、７１２、および７１３は、エンドーサノード、コミッタノード、またはその両方の役割を果たし得る。

分散型台帳７２０は、不変シーケンス化レコードをブロックに格納するブロックチェーン、およびブロックチェーン７２２の現在の状態を維持する状態データベース７２４（現在のワールドステート）を含む。分散型台帳７２０がチャネル毎に１つ存在してよく、各ピアは、それらのピアが各チャネルのメンバである分散型台帳７２０の独自のコピーを維持する。ブロックチェーン７２２は、各ブロックが一連のＮ個のトランザクションを含む、ハッシュリンクされたブロックとして構築されているトランザクションログである。ブロックは、図７Ｂに示すものなど、様々なコンポーネントを含み得る。ブロックのリンク（図７Ａの矢印で示されている）は、現在のブロックのブロックヘッダ内に前のブロックのヘッダのハッシュを追加することによって生成され得る。このように、ブロックチェーン７２２上の全てのトランザクションは、シーケンス化されて共に暗号的にリンクされ、ハッシュリンクを破壊することなくブロックチェーンデータの改ざんを防止する。さらに、これらのリンクがあるので、ブロックチェーン７２２内の最新ブロックは、その前に来る全てのトランザクションを表す。ブロックチェーン７２２は、アペンド専用ブロックチェーンワークロードをサポートするピアファイルシステム（ローカルまたはアタッチトストレージ）上に格納されてよい。

ブロックチェーン７２２および分散型台帳７２２の現在の状態は、状態データベース７２４に格納されてよい。ここで、現在の状態データは、ブロックチェーン７２２のチェーントランザクションログにこれまでに含まれている全ての鍵の最新の値を表す。チェーンコード呼び出しは、状態データベース７２４内の現在の状態に対してトランザクションを実行する。これらのチェーンコードインタラクションを極めて効率的にするために、全ての鍵の最新の値は、状態データベース７２４に格納されてよい。状態データベース７２４は、ブロックチェーン７２２のトランザクションログ内へのインデックス付きビューを含んでよく、したがって、いつでもチェーンから再生成できる。状態データベース７２４は、ピアの起動時であって、トランザクションが受け入れられる前に、自動的に回復（または必要な場合は生成）されてよい。

エンドースノードは、クライアントからトランザクションを受信し、シミュレート結果に基づいてトランザクションをエンドースする。エンドースノードは、トランザクション提案をシミュレートするスマートコントラクトを保持する。エンドースノードがトランザクションをエンドースする場合、エンドースノードは、シミュレートされたトランザクションのエンドースメントを示すエンドースノードからクライアントアプリケーションへの署名付き応答であるトランザクションエンドースメントを作成する。トランザクションをエンドースする方法は、チェーンコード内で指定され得るエンドースメントポリシーに応じて決まる。エンドースメントポリシーの一例としては、「エンドースピアの大部分がトランザクションをエンドースしなければならない」というものがある。異なるチャネルには、異なるエンドースメントポリシーがあり得る。エンドースされたトランザクションは、クライアントアプリケーションによって順序付けサービス７１０に転送される。

順序付けサービス７１０は、エンドースされたトランザクションを受け入れて、これらをブロック内へと順序付けて、ブロックをコミッティングピアへ配信する。例えば、順序付けサービス７１０は、トランザクションの閾値に達した、タイマがタイムアウトした、または別の条件となった場合、新しいブロックを開始してよい。図７Ａの例では、ブロックチェーンノード７１２は、ブロックチェーン７２０に格納される新しいデータの新しいデータブロック７３０を受信するコミッティングピアである。ブロックチェーン内の第１のブロックは、ブロックチェーン、そのメンバ、その内部に格納されているデータ等についての情報を含むジェネシスブロックと称され得る。

順序付けサービス７１０は、オーダラのクラスタで構成されてよい。順序付けサービス７１０は、トランザクション、スマートコントラクトの処理または共有台帳の維持をしない。むしろ、順序付けサービス７１０は、エンドースされたトランザクションを受け入れて、これらのトランザクションが分散型台帳７２０にコミットされる順序を指定してよい。ブロックチェーンネットワークのアーキテクチャは、「順序付け」の具体的な実装（例えば、Ｓｏｌｏ、Ｋａｆｋａ、ＢＦＴ等）がプラグ可能なコンポーネントとなるように設計されてよい。

トランザクションは、一貫した順序で分散型台帳７２０に書き込まれる。トランザクションの順序は、状態データベース７２４に対する更新がネットワークにコミットされるときにそれらの更新が有効になることを保証するために確立される。順序付けが暗号パズルを解くことまたはマイニングを通じて行われる暗号通貨ブロックチェーンシステム（例えば、ビットコイン等）とは異なり、この例では、分散型台帳７２０の当事者は、ネットワークに最も良く適合する順序付けメカニズムを選択してよい。

順序付けサービス７１０が新しいデータブロック７３０を初期化する場合、新しいデータブロック７３０は、コミッティングピア（例えば、ブロックチェーンノード７１１、７１２および７１３）にブロードキャストされてよい。これに応答して、各コミッティングピアは、読み取りセットおよび書き込みセットが状態データベース７２４内の現在のワールドステートを依然として合致することを確実にするようにチェックすることによって、新しいデータブロック７３０内のトランザクションの妥当性を確認する。具体的には、コミッティングピアは、エンドーサがトランザクションをシミュレートしたときに存在していた読み取りデータが、状態データベース７２４内の現在のワールドステートと同一であるかどうかを判断できる。コミッティングピアがトランザクションの妥当性を確認する場合、トランザクションは、分散型台帳７２０上のブロックチェーン７２２に書き込まれ、状態データベース７２４は、読み取り書き込みセットからの書き込みデータで更新される。トランザクションが失敗した場合、つまり、コミッティングピアが、読み取り書き込みセットが状態データベース７２４内の現在のワールドステートと合致しないことを発見した場合、ブロックに順序付けられたトランザクションは依然としてそのブロックに含まれるが、無効としてマークされ、状態データベース７２４は更新されない。

図７Ｂを参照すると、分散型台帳７２０のブロックチェーン７２２に格納される新しいデータブロック７３０（データブロックとも称される）は、ブロックヘッダ７４０、ブロックデータ７５０（ブロックデータセクション）およびブロックメタデータ７６０など、複数のデータセグメントを含み得る。図７Ｂに示される、新しいデータブロック７３０およびそのコンテンツなど、図示される様々なブロックおよびそれらのコンテンツは、例に過ぎず、例示的な実施形態の範囲を限定することを意味しないことを理解されたい。従来のブロックでは、データセクションは、ブロックデータ７５０内にＮ個のトランザクション（例えば、１個、１０個、１００個、５００個、１０００個、２０００個、３０００個等）のトランザクション情報を格納し得る。

また、新しいデータブロック７３０は、（例えば、図７Ａのブロックチェーン７２２上にある）先行ブロックへのリンクをブロックヘッダ７４０内に含み得る。特に、ブロックヘッダ７４０は、先行ブロックのヘッダのハッシュを含み得る。また、ブロックヘッダ７４０は、一意ブロック番号、新しいデータブロック７３０のブロックデータ７５０のハッシュ等を含み得る。新しいデータブロック７３０のブロック番号は、一意であり、ゼロから開始するインクリメンタル／シーケンシャル順序など、様々な順序で割り当てられてよい。

様々な実施形態によれば、ブロックデータ７５０は、例えば、検証可能なクレデンシャル、ＤＩＤ、検証可能なプレゼンテーション等、ＳＳＩ識別情報７５２を格納し得る。様々な実施形態によれば、ＳＳＩ識別情報７５２は、分散型台帳７２０上のブロックの不変ログに格納され得る。ＳＳＩ識別情報７５２をブロックチェーンに格納することの利益のいくつかは、本明細書において開示および図示される様々な実施形態に反映されている。図７ＢではＳＳＩ識別情報７５２がブロックデータ７５０内に示されているが、他の実施形態において、ＳＳＩ識別情報７５２は、ブロックヘッダ７４０またはブロックメタデータ７６０内に位置し得る。

ブロックメタデータ７６０は、メタデータの複数のフィールドを（例えば、バイト配列等として）格納してよい。メタデータフィールドは、ブロック作成時の署名、最後の構成ブロックの参照、ブロック内の有効トランザクションおよび無効トランザクションを識別するトランザクションフィルタ、ブロックを順序付けた順序付けサービスの最後の持続したオフセット等を含み得る。署名、最後の構成ブロックおよびオーダラメタデータは、順序付けサービス７１０によって追加されてよい。一方、ブロックのコミッタ（ブロックチェーンノード７１２など）は、エンドースメントポリシーおよび読み取り／書き込みセットの検証等に基づいて、有効性／無効性情報を追加してよい。トランザクションフィルタは、ブロックデータ７５０に含まれるトランザクションの数に等しいサイズのバイト配列、およびトランザクションが有効であったか／無効であったかを識別する妥当性確認コードを含み得る。

図７Ｃは、本明細書において説明される実施形態による、デジタルコンテンツのためのブロックチェーン７７０の一実施形態を示している。デジタルコンテンツは、１つまたは複数のファイルおよび関連情報を含み得る。ファイルは、メディア、画像、ビデオ、オーディオ、テキスト、リンク、グラフィック、アニメーション、ウェブページ、ドキュメントまたは他のデジタルコンテンツの形式を含み得る。ブロックチェーンの不変でアペンド専用の態様は、デジタルコンテンツの整合性、有効性、および真正性を保護するためのセーフガードとして機能し、許容ルールが適用される法的手続きまたは、証拠が考慮されるか、または、デジタル情報の提示および使用が、その他の点で関心のある他の設定で適切に用いられる。この場合、デジタルコンテンツは、デジタルエビデンスと称され得る。

ブロックチェーンは、様々な態様で形成されてよい。１つの実施形態において、デジタルコンテンツは、ブロックチェーン自体に含まれ、ブロックチェーン自体からアクセスし得る。例えば、ブロックチェーンの各ブロックは、関連付けられているデジタルコンテンツに沿って、参照情報（例えば、ヘッダ、値等）のハッシュ値を格納してよい。次に、ハッシュ値および関連付けられているデジタルコンテンツは、共に暗号化されてよい。したがって、各ブロックのデジタルコンテンツは、ブロックチェーン内の各ブロックを解読することによってアクセスされてよく、各ブロックのハッシュ値は、先行ブロックを参照するための基礎として用いられてよい。これは、以下のとおりに示され得る。

１つの実施形態において、デジタルコンテンツはブロックチェーンに含まれ得ない。例えば、ブロックチェーンは、デジタルコンテンツのいずれも伴うことなく、各ブロックのコンテンツの暗号化されたハッシュを格納してよい。デジタルコンテンツは、元のファイルのハッシュ値に関連付けて別の格納エリアまたはメモリアドレスに格納されてよい。他の格納エリアは、ブロックチェーンを格納するのに用いられるものと同じストレージデバイスであってよく、または、異なる格納エリアまたはさらには別個の関係データベースであってよい。各ブロックのデジタルコンテンツは、関心のあるブロックのハッシュ値を取得またはクエリし、次に、実際のデジタルコンテンツに対応付けて格納されている格納エリア内の値を有するものをルックアップすることによって、参照またはアクセスされてよい。この動作は、例えば、データベースゲートキーパによって実行され得る。これは、以下のとおりに示され得る。

図７Ｃの例示的な実施形態において、ブロックチェーン７７０は、順序付けられたシーケンスにして暗号的にリンク付けられた複数のブロック７７８_１、７７８_２...７７８_Ｎを含み、ここでＮ≧１である。ブロック７７８_１、７７８_２...７７８_Ｎをリンク付けるのに用いられる暗号化は、複数の鍵付きまたは鍵付きでないハッシュ関数のいずれかであってよい。１つの実施形態において、ブロック７７８_１、７７８_２、…７７８_Ｎは、ブロック内の情報に基づく入力からｎビットの英数字出力（ｎは２５６または別の数）を生成するハッシュ関数の対象となる。そのようなハッシュ関数の例は、限定されるものではないが、ＳＨＡタイプ（ＳＨＡはセキュアハッシュアルゴリズムを表す）アルゴリズム、マークルダンガードアルゴリズム、ＨＡＩＦＡアルゴリズム、マークルツリーアルゴリズム、ノンスベースのアルゴリズムおよび非衝突困難ＰＲＦアルゴリズムを含む。別の実施形態では、ブロック７７８_１、７７８_２、…、７７８_Ｎは、ハッシュ関数とは異なる関数によって暗号的にリンクされ得る。図示の目的で、以下の説明は、ハッシュ関数、例えば、ＳＨＡ－２に関して行われる。

ブロックチェーン内のブロック７７８_１、７７８_２...７７８_Ｎの各々は、ヘッダ、ファイルのバージョン、および値を含む。ヘッダおよび値は、ブロックチェーン内のハッシュ化の結果として、各ブロックについて異なる。１つの実施形態において、値はヘッダに含まれ得る。以下でさらに詳細に説明するように、ファイルのバージョンは、元のファイルであってよく、または元のファイルの異なるバージョンであってよい。

ブロックチェーン内の第１のブロック７７８_１は、ジェネシスブロックと称され、ヘッダ７７２_１、元のファイル７７４_１および初期値７７６_１を含む。ジェネシスブロックおよび実際には全ての後続ブロックに用いられるハッシュ化スキームは、異なってよい。例えば、第１のブロック７７８_１内の全ての情報が共に一度でハッシュ化されてよく、または、第１のブロック７７８_１内の情報の各々または一部が別個にハッシュ化されてよく、次に、別個にハッシュ化された一部のハッシュが実行されてよい。

ヘッダ７７２_１は、１つまたは複数の初期パラメータを含んでよく、例えば、バージョン番号、タイムスタンプ、ノンス、ルート情報、難易度、コンセンサスプロトコル、継続時間、媒体フォーマット、ソース、記述キーワード、および／または、元のファイル７７４_１および／またはブロックチェーンに関連付けられている他の情報を含み得る。ヘッダ７７２_１は、（例えば、ソフトウェアを管理するブロックチェーンネットワークによって）自動的に、または、ブロックチェーン参加者によって手動で生成されてよい。ブロックチェーン内の他のブロック７７８_２－７７８_Ｎ内のヘッダとは異なり、ジェネシスブロック内のヘッダ７７２_１は、単に先行ブロックが存在しないので、先行ブロックを参照しない。

ジェネシスブロック内の元のファイル７７４_１は、例えば、ブロックチェーンに含める前に処理をしたかまたはしていない、デバイスによってキャプチャされたデータであってよい。元のファイル７７４_１は、デバイス、メディアソース、またはノードから、システムのインタフェースを通じて受信される。元のファイル７７４_１は、メタデータに関連付けられ、メタデータは、例えば、手動または自動のいずれかで、ユーザ、デバイスおよび／またはシステムプロセッサによって生成されてよい。メタデータは、元のファイル７７４_１に関連付けて第１のブロック７７８_１内に含まれてよい。

ジェネシスブロック内の値７７６_１は、元のファイル７７４_１の１つまたは複数の一意の属性に基づいて生成される初期値である。１つの実施形態において、１つまたは複数の一意の属性は、元のファイル７７４_１のハッシュ値、元のファイル７７４_１のメタデータ、およびファイルに関連付けられた他の情報を含み得る。１つの実装では、初期値７７６_１は、
１）元のファイルのＳＨＡ－２の計算されたハッシュ値
２）送信元デバイスＩＤ
３）元のファイルの開始タイムスタンプ
４）元のファイルの初期格納位置
５）元のファイルおよび関連付けられたメタデータを現在制御するソフトウェアのブロックチェーンネットワークメンバＩＤ
という一意の属性に基づき得る。

ブロックチェーン内の他のブロック７７８_２－７７８_Ｎも、ヘッダ、ファイルおよび値を有する。しかしながら、第１のブロック７７２_１とは異なり、他のブロックのヘッダ７７２_２－７７２_Ｎの各々は、直前のブロックのハッシュ値を含む。直前のブロックのハッシュ値は、単に先行ブロックのヘッダのハッシュであってよく、または、先行ブロック全体のハッシュ値であってよい。先行するブロックのハッシュ値を残りのブロックの各々に含むことにより、監査可能かつ不変な管理の連鎖を確立するために、矢印７８０で示されているようにＮ番目のブロックからジェネシスブロック（および関連付けられている元のファイル）まで戻る追跡をブロック単位で実行できる。

また、他のブロック内のヘッダ７７２_２－７７２_Ｎの各々は、他の情報、例えば、バージョン番号、タイムスタンプ、ノンス、ルート情報、難易度、コンセンサスプロトコル、および／または、対応するファイルおよび／または一般的にブロックチェーンに関連付けられている他のパラメータまたは情報を含み得る。

他のブロック内のファイル７７４_２－７７４_Ｎは、例えば、実行される処理のタイプに応じて、元のファイルに等しくてよく、またはジェネシスブロック内の元のファイルの修正されたバージョンであってよい。実行される処理のタイプは、ブロックによって異なってよい。処理は、例えば、情報の編集またはそうでなければコンテンツの変更、情報の除去、または、ファイルへの情報の追加またはアペンドなど、先行するブロック内のファイルの任意の修正を伴い得る。

追加的に、または代替的に、処理は、先行するブロックからのファイルの単なるコピー、ファイルの格納位置の変更、１つまたは複数の先行するブロックからのファイルの分析、１つのストレージまたはメモリ位置から別の位置へのファイルの移動、またはブロックチェーンおよび／またはその関連付けられているメタデータのファイルに対するアクションの実行を伴い得る。ファイルの分析を伴う処理は、例えば、様々な分析、統計、またはファイルに関連付けられた他の情報の追加、包含、またはそうでなければ関連付けを含み得る。

他のブロックにおける他のブロック７７６_２－７７６_Ｎの各々における値は、一意の値であり、実行された処理の結果として全て異なる。例えば、任意の１つのブロックにおける値は、先行ブロックにおける値の更新されたバージョンに対応する。更新は、値が割り当てられるブロックのハッシュに反映される。したがって、ブロックの値は、ブロックにおいてどのような処理が実行されたかのインジケーションを提供し、また、ブロックチェーンを通じて元のファイルまで戻る追跡を可能にする。この追跡により、ブロックチェーンの全体にわたってファイルの管理の連鎖が確認される。

例えば、ファイル内に示されている人物のアイデンティティを保護すべく、先行ブロック内のファイルの一部が編集、ブロックアウトまたはピクセル化されている事例を検討する。この場合、編集されたファイルを含むブロックには、例えば、編集の実行方法、編集の実行者、編集が行われたタイムスタンプ等、編集されたファイルに関連付けられたメタデータが含まれる。メタデータは、値を形成するようにハッシュ化されてよい。ブロックのためのメタデータは、先行ブロックにおける値を形成するようにハッシュ化された情報とは異なるので、これらの値は、互いに異なり、解読されるときに回復されてよい。

１つの実施形態において、以下のいずれか１つまたは複数が行われた場合、先行ブロックの値を更新して（例えば、新しいハッシュ値を計算して）、現在のブロックの値を形成し得る。新しいハッシュ値は、この例示的な実施形態では、以下に示されている情報の全てまたは一部をハッシュ化することによって計算されてよい。
ａ）ファイルが任意の態様で処理されている場合（例えば、ファイルが編集、コピー、変更、アクセスされたか、または何らかの他のアクションが取られた場合）、新しいＳＨＡ－２計算ハッシュ値、
ｂ）ファイルのための新しい格納位置、
ｃ）ファイルに関連付けられている識別された新しいメタデータ、
ｄ）１つのブロックチェーン参加者から別のブロックチェーン参加者への、ファイルのアクセスまたは制御の移転。

図７Ｄは、１つの実施形態による、ブロックチェーン７９０内のブロックの構造を表し得るブロックの一実施形態を示している。このブロック、すなわちＢｌｏｃｋ_ｉは、ヘッダ７７２_ｉ、ファイル７７４_ｉおよび値７７６_ｉを含む。

ヘッダ７７２_ｉは、先行ブロックＢｌｏｃｋ_ｉ－１のハッシュ値、および、例えば、本明細書において説明される情報（例えば、参照、特性、パラメータ等を含むヘッダ情報）のいずれのタイプであってもよい、追加の参照情報を含む。全てのブロックは、もちろんジェネシスブロックを除いて、先行ブロックのハッシュを参照する。先行ブロックのハッシュ値は、単に、先行ブロック内のヘッダのハッシュ、または、ファイルおよびメタデータを含む、先行ブロック内の情報の全てまたは一部のハッシュであってよい。

ファイル７７４_ｉは、順になったデータ１、データ２、...、データＮなど、複数のデータを含む。データは、データに関連付けられているコンテンツおよび／または特性を記述するメタデータ１、メタデータ２、...、メタデータＮでタグ付けされている。例えば、各データのメタデータは、データのタイムスタンプ、データのプロセス、データ内に示されている人物または他のコンテンツを示すキーワード、および／または、ファイルの全体としての有効性およびコンテンツを確立するのに有用であり得る他の特徴、および、特にその使用、例えば、以下に説明される一実施形態に関連して説明されるようなデジタルエビデンスを示す情報を含み得る。メタデータに加え、各データは、改ざん、ファイル内のギャップ、およびファイルを通じたシーケンシャル参照を防止するために、前のデータの参照ＲＥＦ_１、ＲＥＦ_２、...、ＲＥＦ_Ｎでタグ付けされてよい。

ひとたびメタデータが（例えば、スマートコントラクトを通じて）データに割り当てられると、メタデータは、無効化のために容易に識別され得るハッシュの変化を伴わずには変更できない。したがって、メタデータは、ブロックチェーン内の参加者によって使用のためにアクセスされ得る情報のデータログを作成する。

値７７６_ｉは、ハッシュ値、または、前述の情報のタイプのいずれかに基づいて計算される他の値である。例えば、任意の所与のブロックＢｌｏｃｋ_ｉについて、そのブロックの値は、そのブロックについて実行された処理、例えば、新しいハッシュ値、新しい格納位置、関連付けられているファイルのための新しいメタデータ、制御またはアクセスの移転、識別子、または追加される他のアクションまたは情報を反映するように更新されてよい。各ブロック内の値は、ファイルのデータのためのメタデータおよびヘッダとは別個であるように示されているが、別の実施形態において、値は、部分的にまたは全体的にこのメタデータに基づいてよい。

ひとたびブロックチェーン７７０が形成されると、任意の時点で、ブロックにわたる値のトランザクション履歴をブロックチェーンにクエリすることによって、ファイルのための不変な管理の連鎖が取得され得る。このクエリ、または追跡手順は、直近に含められたブロック（例えば、最後（Ｎ番目）のブロック）の値を解読し、次に、ジェネシスブロックに達すると共に元のファイルが回復されるまで他のブロックの値の解読を続けることで始まってよい。解読は、各ブロックにおけるヘッダおよびファイルおよび関連付けられているメタデータの解読も伴い得る。

解読は、各ブロックで行われた暗号化のタイプに基づいて実行される。これは、秘密鍵、公開鍵、または公開鍵と秘密鍵とのペアの使用を伴ってよい。例えば、非対称暗号化が用いられる場合、ネットワーク内のブロックチェーン参加者またはプロセッサは、予め定められたアルゴリズムを用いて、公開鍵と秘密鍵とのペアを生成してよい。公開鍵および秘密鍵は、何らかの数学的関係を通じて互いに関連付けられている。公開鍵は、他のユーザ、例えばＩＰアドレスまたはホームアドレスからメッセージを受信するためのアドレスとして機能するように、パブリックに分散されてよい。秘密鍵は、秘密に保持され、他のブロックチェーン参加者に送信されたデジタル署名メッセージに対して用いられる。署名は、受信者が送信者の公開鍵を用いて検証できるように、メッセージ内に含まれる。このように、受信者は、送信者だけがこのメッセージを送信できたことを確認できる。

鍵ペアの生成は、ブロックチェーン上でのアカウントの作成と類似であってよいが、実際にどこにも登録する必要はない。また、ブロックチェーン上で実行される全てのトランザクションは、それらの秘密鍵を用いて送信者によってデジタル署名されている。この署名は、アカウントの所有者のみが、（スマートコントラクトによって判断される許可の範囲内である場合）ブロックチェーンのファイルを追跡および処理できることを保証する。

図８Ａおよび図８Ｂは、本明細書に組み込まれて用いられ得るブロックチェーンのユースケースの追加の例を示す。特に、図８Ａは、機械学習（人工知能）データを格納するブロックチェーン８１０の例８００を示す。機械学習は、新しいデータを正確に予測するための予測モデルを構築するために、膨大な量の履歴データ（またはトレーニングデータ）に依存している。機械学習ソフトウェア（例えば、ニューラルネットワーク等）は、多くの場合、数百万個のレコードを選り分けて、直感的でないパターンを発見できる。

図８Ａの例では、ホストプラットフォーム８２０は、資産８３０の予測モニタリングのための機械学習モデルを構築および展開する。ここで、ホストプラットフォーム８２０は、クラウドプラットフォーム、産業用サーバ、ウェブサーバ、パーソナルコンピュータおよびユーザデバイス等であり得る。資産８３０は、例えば、航空機、機関車、タービン、医療機械および機器、石油機器およびガス機器、ボート、船舶および車両等、任意のタイプの資産（例えば、機械または機器等）であり得る。別の例として、資産８３０は、例えば、株式、通貨、デジタルコインまたは保険等、無形資産であり得る。

ブロックチェーン８１０を使用して、機械学習モデルのトレーニングプロセス８０２および、トレーニングされた機械学習モデルに基づく予測プロセス８０４の両方を著しく向上させることができる。例えば、８０２では、データサイエンティスト／エンジニアまたは他のユーザがデータを収集することを要求するのではなく、資産８３０自体によって（または不図示の仲介者を通じて）履歴データをブロックチェーン８１０に格納し得る。これにより、予測モデルのトレーニングを実行するときにホストプラットフォーム８２０が必要とする収集時間を著しく短縮できる。例えば、スマートコントラクトを使用すると、データを、その元の位置からブロックチェーン８１０に直接かつ確実に転送できる。収集されたデータのセキュリティおよび所有権を保証するためにブロックチェーン８１０を使用することにより、スマートコントラクトは、機械学習モデルを構築するためにデータを使用する個人に資産からデータを直接送信し得る。これにより、資産８３０の間でデータを共有することが可能になる。

収集されたデータは、コンセンサスメカニズムに基づいてブロックチェーン８１０に格納され得る。コンセンサスメカニズムは、記録されているデータが検証済みの正確なものであることを保証するために（許可型ノード）を取り込む。記録されたデータにはタイムスタンプが付けられ、暗号で署名され、不変である。したがって、監査可能、透過的、かつセキュアである。ブロックチェーンに直接書き込むＩｏＴデバイスを追加すると、特定の事例（すなわち、サプライチェーン、ヘルスケア、ロジスティクス等）において、記録されるデータの頻度および精度の両方を向上させることができる。

さらに、収集されたデータでの機械学習モデルのトレーニングには、ホストプラットフォーム８２０による改良およびテストのラウンドが必要になり得る。各ラウンドは、追加のデータまたは、機械学習モデルの知識を広げるのに役立つと以前はみなされていなかったデータに基づき得る。８０２では、ホストプラットフォーム８２０によって、異なるトレーニングおよびテスト段階（およびそれに関連付けられたデータ）は、ブロックチェーン８１０に格納され得る。機械学習モデルの各改良（例えば、変数、重み等の変更）は、ブロックチェーン８１０に格納され得る。これにより、モデルのトレーニング方法およびモデルのトレーニングに用いられたデータの検証可能な証明が提供される。さらに、ホストプラットフォーム８２０が最終的にトレーニングされたモデルを実現したとき、その結果として得られるモデルはブロックチェーン８１０に格納され得る。

モデルがトレーニングされた後、モデルは最終的にトレーニングされた機械学習モデルの実行に基づいて予測／決定を行うことができるライブ環境に展開され得る。例えば、８０４では、機械学習モデルは、例えば、航空機、風力タービンおよび医療機械等の資産の状態基準保全（ＣＢＭ）に用いられ得る。この例では、資産８３０からフィードバックされたデータは、機械学習モデルに入力され、例えば失敗イベントおよびエラーコード等のイベント予測を行うために用いられ得る。ホストプラットフォーム８２０での機械学習モデルの実行によって行われた決定は、ブロックチェーン８１０に格納されて、監査可能／検証可能な証明を提供し得る。１つの非限定的な例として、機械学習モデルは、資産８３０の一部に対する将来の故障／失敗を予測し、部品を交換するためのアラートまたは通知を作成し得る。この決定の基となるデータは、ブロックチェーン８１０上のホストプラットフォーム８２０によって格納され得る。１つの実施形態では、本明細書において説明および／または図示される特徴および／またはアクションは、ブロックチェーン８１０上で、またはブロックチェーン８１０に関して行われ得る。

ブロックチェーンの新しいトランザクションを新しいブロック内にまとめて、既存のハッシュ値に追加できる。次に、これが暗号化されて、新しいブロックの新しいハッシュが作成される。これは、トランザクションが暗号化されたとき等に、トランザクションの次のリストに追加される。結果は、全ての先行するブロックのハッシュ値を各々が含むブロックのチェーンである。これらのブロックを格納するコンピュータは、ハッシュ値を定期的に比較して、全てが一致していることを保証する。一致しないコンピュータはいずれも、問題の原因となっているレコードを破棄する。この手法は、ブロックチェーンの改ざん防止を保証するのに適しているが、完全ではない。

このシステムの抜け穴を悪用する１つの態様は、不正なユーザが、自分が有利になるようにトランザクションのリストを変更して、ハッシュを変更しないようにする態様である。これは総当たりによって、言い換えると、レコードを変更し、結果を暗号化し、ハッシュ値が同じかどうかを確認することによって実行できる。合致しない場合は、合致するハッシュが見つかるまで何度も何度も試行する。ブロックチェーンのセキュリティは、通常のコンピュータがこの種の総当たり攻撃を行うことができるのは、宇宙の年齢など、完全に非現実的な時間スケールでしか実行できないという考えに基づいている。対照的に、量子コンピュータははるかに高速（数千倍の速さ）であり、したがって、はるかに大きな脅威になる。

図８Ｂは、量子コンピューティング攻撃に対して保護するために量子鍵配布（ＱＫＤ）を実装する量子セキュアブロックチェーン８５２の例８５０を示す。この例では、ブロックチェーンユーザがＱＫＤを使用して互いのアイデンティティを検証できる。これは、盗聴者が破壊することなくコピーすることはできない、光子などの量子粒子を使用して情報を送信する。このように、ブロックチェーンを通じた送信者および受信者は、互いのアイデンティティを確認できる。

図８Ｂの例では、８５４、８５６、８５８、および８６０という４人のユーザが存在する。ユーザのペアの各々は、それら自体の間で秘密鍵８６２（すなわち、ＱＫＤ）を共有し得る。この例では４つのノードがあるので、６ペアのノードが存在し、したがって、ＱＫＤ_ＡＢ、ＱＫＤ_ＡＣ、ＱＫＤ_ＡＤ、ＱＫＤ_ＢＣ、ＱＫＤ_ＢＤ、およびＱＫＤ_ＣＤを含む６つの異なる秘密鍵８６２が用いられる。各ペアは、盗聴者が破壊することなくコピーすることはできない、光子などの量子粒子を使用して情報を送信することによってＱＫＤを作成できる。このように、ユーザのペアは互いのアイデンティティを確認できる。

ブロックチェーン８５２の動作は、（ｉ）トランザクションの作成、および（ｉｉ）新しいトランザクションを集約するブロックの構築の２つの手順に基づく。新しいトランザクションは、従来のブロックチェーンネットワークと同様に作成され得る。各トランザクションには、送信者、受信者、作成時間、転送される金額（または値）、および送信者が操作のための資金を持っていることを正当化する参照トランザクションのリスト等についての情報が含まれ得る。次に、このトランザクションレコードは、全ての他のノードに送信され、未確認トランザクションのプールに入れられる。ここで、２人の当事者（すなわち、８５４－８６０の中からのユーザのペア）が、共有秘密鍵８６２（ＱＫＤ）を提供することによってトランザクションを認証する。この量子署名は全てのトランザクションに添付できるため、改ざんは極めて困難になる。各ノードは、ブロックチェーン８５２のローカルコピーに関してエントリをチェックし、各トランザクションが十分な資金を有していることを検証する。しかしながら、トランザクションはまだ確認されていない。

ブロックに対して従来のマイニングプロセスを実行するのではなく、ブロードキャストプロトコルを使用して非集中方式でブロックを作成し得る。予め定められた期間（例えば、秒、分、時間等）で、ネットワークはブロードキャストプロトコルを任意の未確認トランザクションに適用し、それにより、トランザクションの正しいバージョンに関するビザンチン合意（コンセンサス）を達成し得る。例えば、各ノードはプライベート値（その特定のノードのトランザクションデータ）を所有し得る。第１のラウンドでは、ノードは自分のプライベート値を互いに伝送する。後続のラウンドでは、ノードは前のラウンドで他のノードから受信した情報の通信を行う。ここでは、正直なノードが新しいブロック内に完全なトランザクションセットを作成できる。この新しいブロックは、ブロックチェーン８５２に追加できる。１つの実施形態では、本明細書において説明および／または図示される特徴および／またはアクションは、ブロックチェーン８５２上で、またはブロックチェーン８５２に関して行われ得る。

図９は、本明細書において説明および／または図示される例示的な実施形態のうちの１つまたは複数をサポートする例示的なシステム９００を示す。システム９００は、多数の他の汎用または専用コンピューティングシステム環境または構成で動作可能である、コンピュータシステム／サーバ９０２を備える。コンピュータシステム／サーバ９０２での使用に適切であり得る周知のコンピューティングシステム、環境および／または構成の例は、限定されるわけではないが、パーソナルコンピュータシステム、サーバコンピュータシステム、シンクライアント、シッククライアント、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラマブル家庭用電子機器、ネットワークＰＣ、ミニコンピュータシステム、メインフレームコンピュータシステム、および上記のシステムまたはデバイス等のいずれかを含む分散型クラウドコンピューティング環境を含む。

コンピュータシステム／サーバ９０２は、コンピュータシステムによって実行されているプログラムモジュールなどのコンピュータシステム実行可能命令の一般的な文脈で説明され得る。概して、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、ロジックおよびデータ構造等を含み得る。コンピュータシステム／サーバ９０２は、通信ネットワークを通じてリンクされたリモート処理デバイスによってタスクが実行される分散型クラウドコンピューティング環境において実施され得る。分散型クラウドコンピューティング環境では、メモリストレージデバイスを含むローカルのコンピュータシステム記憶媒体、および、メモリストレージデバイスを含むリモートコンピュータシステム記憶媒体の両方の中にプログラムモジュールが位置し得る。

図９に示すように、クラウドコンピューティングノード９００内のコンピュータシステム／サーバ９０２が、汎用コンピューティングデバイスの形態で示されている。コンピュータシステム／サーバ９０２のコンポーネントは、限定されるわけではないが、１つまたは複数のプロセッサまたは処理ユニット９０４、システムメモリ９０６、および、システムメモリ９０６を含む様々なシステムコンポーネントをプロセッサ９０４に結合するバスを含み得る。

バスは、メモリバスまたはメモリコントローラ、ペリフェラルバス、アクセラレーテッドグラフィックスポート、および様々なバスアーキテクチャのいずれかを使用するプロセッサまたはローカルバスを含む、いくつかのタイプのバス構造のいずれかのうちの１つまたは複数を表す。限定ではなく例として、そのようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、エンハンスドＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（ＶＥＳＡ）ローカルバス、およびペリフェラルコンポーネントインターコネクト（ＰＣＩ）バスを含む。

コンピュータシステム／サーバ９０２は、典型的には、様々なコンピュータシステム可読媒体を含む。そのような媒体は、コンピュータシステム／サーバ９０２がアクセス可能な任意の利用可能な媒体であってよく、揮発性媒体および不揮発性媒体の両方、および、取り外し可能媒体および取り外し不可能媒体を含む。システムメモリ９０６は、１つの実施形態において、他の図のフロー図を実装する。システムメモリ９０６は、ランダムアクセスメモリ（ＲＡＭ）９１０および／またはキャッシュメモリ９１２など、揮発性メモリの形態のコンピュータシステム可読媒体を含み得る。コンピュータシステム／サーバ９０２は、他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータシステム記憶媒体をさらに含み得る。単なる例として、ストレージシステム９１４が、取り外し不可能、不揮発性の磁気媒体（示されていないが、典型的には「ハードドライブ」と呼ばれる）から読み取り、この磁気媒体に書き込むために提供され得る。示されていないが、取り外し可能不揮発性磁気ディスク（例えば、「フロッピーディスク」）との間で読み取りおよび書き込みを行うための磁気ディスクドライブ、およびＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭまたは他の光学媒体などの取り外し可能不揮発性光ディスクとの間で読み取りまたは書き込みを行うための光ディスクドライブが提供され得る。そのような場合、各々を１つまたは複数のデータメディアインタフェースによってバスに接続できる。以下でさらに図示および説明するように、メモリ９０６は、アプリケーションの様々な実施形態の機能を実行するように構成されたプログラムモジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含み得る。

ひと揃いの（少なくとも１つの）プログラムモジュール９１８を有するプログラム／ユーティリティ９１６を、限定ではなく例として、メモリ９０６に格納してもよく、また、オペレーティングシステム、１つまたは複数のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータも同様である。これらのオペレーティングシステム、１つまたは複数のアプリケーションプログラム、他のプログラムモジュール、および、プログラムデータの各々、または、これらの何らかの組み合わせは、ネットワーキング環境の実装形態を含み得る。プログラムモジュール９１８は概して、本明細書において説明されるようにアプリケーションの様々な実施形態の機能および／または方法論を実行する。

当業者には理解されるように、本願の態様は、システム、方法、またはコンピュータプログラム製品として具現化され得る。したがって、本願の態様は、完全にハードウェアの実施形態、完全にソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）の実施形態または、本明細書では全て概して、「回路」、「モジュール」、または「システム」と称され得るソフトウェアおよびハードウェアの態様を組み合わせた一実施形態の形態を取り得る。さらに、本願の態様は、コンピュータ可読プログラムコードがその中に具現化された１つまたは複数のコンピュータ可読媒体に具現化されたコンピュータプログラム製品の形態を取り得る。

コンピュータシステム／サーバ９０２はまた、例えば、キーボード、ポインティングデバイス、ディスプレイ９２２等の１つまたは複数の外部デバイス９２０、ユーザがコンピュータシステム／サーバ９０２とインタラクトすることを可能にする１つまたは複数のデバイス；および／またはコンピュータシステム／サーバ９０２が１つまたは複数の他のコンピューティングデバイスと通信することを可能にする任意のデバイス（例えば、ネットワークカード、モデム等）と通信してもよい。そのような通信は、Ｉ／Ｏインタフェース９２４を介して行われ得る。さらにまた、コンピュータシステム／サーバ９０２は、ローカルエリアネットワーク（ＬＡＮ）、一般的なワイドエリアネットワーク（ＷＡＮ）および／またはパブリックネットワーク（例えば、インターネット）などの１つまたは複数のネットワークとネットワークアダプタ９２６を介して通信することができる。図示のように、ネットワークアダプタ９２６は、バスを介してコンピュータシステム／サーバ９０２の他のコンポーネントと通信する。図示されていないが、他のハードウェアコンポーネントおよび／またはソフトウェアコンポーネントのコンポーネントを、コンピュータシステム／サーバ９０２と併せて用いられ得ることを理解されたい。例は、マイクロコード、デバイスドライバ、冗長処理ユニット、外部ディスクドライブアレイ、ＲＡＩＤシステム、テープドライブおよびデータアーカイブストレージシステム等を含むが、これらに限定されない。

システム、方法、および非一時的コンピュータ可読媒体のうちの少なくとも１つの例示的な実施形態が、添付図面に示され、前述の詳細な説明において説明されているが、本願は、開示される実施形態に限定されるものではなく、以下の特許請求の範囲に記載および定義される多数の再構成、修正、および置換が可能であることを理解されたい。例えば、様々な図のシステムの機能は、本明細書において説明されるモジュールまたはコンポーネントのうちの１つまたは複数によって、または分散アーキテクチャで実行でき、トランスミッタ、レシーバ、または両方のペアを含み得る。例えば、個別のモジュールによって実行される機能の全部または一部は、これらのモジュールのうちの１つまたは複数によって実行され得る。さらに、本明細書において説明される機能は、モジュールまたはコンポーネントの内部または外部の様々なイベントに関連して、様々な時点で実行され得る。また、様々なモジュール間で送信される情報は、データネットワーク、インターネット、音声ネットワーク、インターネットプロトコルネットワーク、無線デバイス、有線デバイスのうちの少なくとも１つを介して、および／または複数のプロトコルを介してモジュール間で送信できる。また、モジュールのいずれかによって送信または受信されるメッセージは、直接および／または他のモジュールのうちの１つまたは複数を介して送信または受信され得る。

「システム」がパーソナルコンピュータ、サーバ、コンソール、パーソナルデジタルアシスタント（ＰＤＡ（登録商標））、携帯電話、タブレットコンピューティングデバイス、スマートフォン、または任意の他の適切なコンピューティングデバイス、またはデバイスの組み合わせとして具現化され得ることを、当業者であれば理解するであろう。上で説明された機能を「システム」によって実行されるものとして提示することは、本願の範囲を決して限定することを意図するものではなく、多くの実施形態の１つの例を提供することを意図するものである。実際、本明細書で開示される方法、システム、および装置は、コンピューティング技術と一貫する局所的および分散的な形態で実装され得る。

本明細書において説明されているシステム特徴のいくつかは、実装の独立性をより具体的に強調すべくモジュールとして提示されていることに留意されたい。例えば、モジュールは、カスタム超大規模集積（ＶＬＳＩ）回路またはゲートアレイ、論理チップ、トランジスタ、または他の個別コンポーネントなどの既製の半導体を含むハードウェア回路として実装され得る。モジュールはまた、例えば、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイスまたはグラフィックス処理ユニット等、プログラマブルハードウェアデバイスに実装され得る。

モジュールはまた、様々なタイプのプロセッサによる実行のために、ソフトウェアに少なくとも部分的に実装され得る。例えば、実行可能コードの識別されたユニットは、例えば、オブジェクト、手順、または機能として編成され得るコンピュータ命令の１つまたは複数の物理ブロックまたは論理ブロックを有し得る。それにもかかわらず、識別されたモジュールの実行可能ファイルは、物理的に共に配置する必要はないが、異なる位置に格納された異種の命令を含んでよく、論理的に結合されたときに、モジュールを有し、モジュールの前述の目的を達成する。さらに、モジュールは、例えば、ハードディスクドライブ、フラッシュデバイス、ランダムアクセスメモリ（ＲＡＭ）、テープ、またはデータを格納するために用いられる任意の他のそのような媒体であり得る、コンピュータ可読媒体に格納され得る。

実際、実行可能コードのモジュールは、単一の命令、または多くの命令であってよく、いくつかの異なるコードセグメントにわたって、異なるプログラム間で、およびいくつかのメモリデバイスにわたっても分散されることさえあり得る。同様に、動作データは、本明細書ではモジュール内で識別および示されてよく、任意の適切な形式で具現化され、任意の適切なタイプのデータ構造内に編成されてよい。動作データは、単一のデータセットとして収集されてよく、または異なるストレージデバイスを含む異なる位置に分散されてよく、少なくとも部分的に、システムまたはネットワーク上の電子信号としてのみ存在してもよい。

本願のコンポーネントは、本明細書で概して説明され、図に示されているように、多種多様な異なる構成で配置および設計され得ることが容易に理解されるであろう。したがって、実施形態の詳細な説明は、特許請求される本願の範囲を限定するようには意図されておらず、本願の選択された実施形態を表しているに過ぎない。

当業者であれば、上記が、異なる順序の複数の段階で、および／または開示されたものとは異なる構成のハードウェア要素で実施され得ることを容易に理解するであろう。したがって、本願をこれらの好ましい実施形態に基づいて説明してきたが、特定の修正、変形および代替的構成が明らかであることは当業者には明らかであろう。

本願の好ましい実施形態について説明してきたが、説明された実施形態は例示に過ぎず、本願の範囲は、実施形態に対する均等物および修正物（例えば、プロトコル、ハードウェアデバイス、ソフトウェアプラットフォーム等）の全範囲を考慮した場合、添付の特許請求の範囲によってのみ定義されるべきであることが理解されるべきである。

Claims (20)

1. ブロックチェーンへの格納の要求を受信するように構成されたネットワークインタフェース；および
   自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成される検証可能なクレデンシャルであって、ブロックチェーンノードのクレーム、および前記検証可能なクレデンシャルを作成した前記ＳＳＩネットワークの証明を含む、検証可能なクレデンシャルを前記要求に関連付けられたブロックチェーントランザクションへ前記ブロックチェーンノードを介してアタッチするように、かつ、前記ブロックチェーントランザクションおよびアタッチされた前記検証可能なクレデンシャルを前記ブロックチェーン上のデータブロックを介して格納するように構成されたプロセッサ、ここで、前記プロセッサはさらに、前記ブロックチェーントランザクションおよび前記アタッチされた検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送するよう前記ネットワークインタフェースを制御するように構成されている
   を備える装置。
2. 前記検証可能なクレデンシャルは、前記ブロックチェーンノードを一意に識別する非集中型識別子（ＤＩＤ）をさらに含む、請求項１に記載の装置。
3. 前記要求は、前記ブロックチェーンのスマートコントラクトを介した前記ブロックチェーントランザクションの実行の要求を含み、前記検証可能なクレデンシャルは、前記スマートコントラクトの実行を許可されているブロックチェーンピアとして前記ブロックチェーンノードを識別するクレームを内部に含む、請求項１に記載の装置。
4. 前記検証可能なクレデンシャルは、前記検証可能なクレデンシャルがいつ作成されたかについてのタイムスタンプ、および満了値を含む、請求項１に記載の装置。
5. 前記プロセッサはさらに、修正された検証可能なクレデンシャルを前記ＳＳＩネットワークから受信するように構成されており、前記修正された検証可能なクレデンシャルは、前記修正された検証可能なクレデンシャルに追加される新しいクレーム、前記新しいクレームがいつ作成されたかについてのタイムスタンプ、および満了値を含む、請求項１に記載の装置。
6. 前記要求は、複数のブロックチェーントランザクションの順序付け要求を含み、前記プロセッサは、新しいブロック内の前記複数のブロックチェーントランザクションを順序付けるように、かつ、前記ブロックチェーンノードが前記ブロックチェーンの順序付けノードであることを示す検証可能なクレデンシャルを前記新しいブロックへアタッチするように構成されている、請求項１に記載の装置。
7. 前記要求は、予め定義されたブロックチェーン台帳へのブロックの追加の要求を含み、前記検証可能なクレデンシャルは、前記予め定義されたブロックチェーン台帳への前記ブロックの格納を許可されているブロックチェーンピアとして前記ブロックチェーンノードを識別するクレームを内部に格納している、請求項１に記載の装置。
8. 前記プロセッサはさらに、前記ブロックチェーントランザクションをエンドースするように構成されており、ここで、前記検証可能なクレデンシャルは、前記ブロックチェーンのエンドースピアとして前記ブロックチェーンノードを識別する、請求項１に記載の装置。
9. ブロックチェーンへの格納の要求を受信する段階；
   自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成される検証可能なクレデンシャルであって、ブロックチェーンノードのクレーム、および前記検証可能なクレデンシャルを作成した前記ＳＳＩネットワークの証明を含む、検証可能なクレデンシャルを前記要求に関連付けられたブロックチェーントランザクションへ前記ブロックチェーンノードを介してアタッチする段階；
   前記ブロックチェーントランザクションおよびアタッチされた前記検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送する段階；および
   前記ブロックチェーントランザクションおよび前記アタッチされた検証可能なクレデンシャルを前記ブロックチェーン上のデータブロックを介して格納する段階
   を備える方法。
10. 前記検証可能なクレデンシャルは、前記ブロックチェーンノードを一意に識別する非集中型識別子（ＤＩＤ）をさらに含む、請求項９に記載の方法。
11. 前記要求は、前記ブロックチェーンのスマートコントラクトを介した前記ブロックチェーントランザクションの実行の要求を含み、前記検証可能なクレデンシャルは、前記スマートコントラクトの実行を許可されているブロックチェーンピアとして前記ブロックチェーンノードを識別するクレームを内部に含む、請求項９に記載の方法。
12. 前記検証可能なクレデンシャルは、前記検証可能なクレデンシャルがいつ作成されたかについてのタイムスタンプ、および満了値を含む、請求項９に記載の方法。
13. 修正された検証可能なクレデンシャルを前記ＳＳＩネットワークから受信する段階、ここで、前記修正された検証可能なクレデンシャルは、前記修正された検証可能なクレデンシャルに追加される新しいクレーム、前記新しいクレームがいつ作成されたかについてのタイムスタンプ、および満了値を含む、をさらに備える、請求項９に記載の方法。
14. 前記要求は、複数のブロックチェーントランザクションの順序付け要求を含み、前記方法は、新しいブロック内の前記複数のブロックチェーントランザクションを順序付け、かつ、前記ブロックチェーンノードが前記ブロックチェーンの順序付けノードであることを示す検証可能なクレデンシャルを前記新しいブロックへアタッチする段階をさらに備える、請求項９に記載の方法。
15. 前記要求は、予め定義されたブロックチェーン台帳へのブロックの追加の要求を含み、前記検証可能なクレデンシャルは、前記予め定義されたブロックチェーン台帳への前記ブロックの格納を許可されているブロックチェーンピアとして前記ブロックチェーンノードを識別するクレームを内部に格納している、請求項９に記載の方法。
16. 前記ブロックチェーントランザクションをエンドースする段階、ここで、前記検証可能なクレデンシャルは、前記ブロックチェーンのエンドースピアとして前記ブロックチェーンノードを識別する、をさらに備える、請求項９に記載の方法。
17. プロセッサにより実行された場合、
    ブロックチェーンへの格納の要求を受信する手順；
    自己主権型アイデンティティ（ＳＳＩ）ネットワークにより作成される検証可能なクレデンシャルであって、ブロックチェーンノードのクレーム、および前記検証可能なクレデンシャルを作成した前記ＳＳＩネットワークの証明を含む、検証可能なクレデンシャルを前記要求に関連付けられたブロックチェーントランザクションへ前記ブロックチェーンノードを介してアタッチする手順；
    前記ブロックチェーントランザクションおよびアタッチされた前記検証可能なクレデンシャルを１つまたは複数の他のブロックチェーンノードへ伝送する手順；および
    前記ブロックチェーントランザクションおよび前記アタッチされた検証可能なクレデンシャルを前記ブロックチェーン上のデータブロックを介して格納する手順
    を含む方法をコンピュータに実行させる命令を備える非一時的コンピュータ可読媒体。
18. 前記検証可能なクレデンシャルは、前記ブロックチェーンノードを一意に識別する非集中型識別子（ＤＩＤ）をさらに含む、請求項１７に記載の非一時的コンピュータ可読媒体。
19. 前記要求は、前記ブロックチェーンのスマートコントラクトを介した前記ブロックチェーントランザクションの実行の要求を含み、前記検証可能なクレデンシャルは、前記スマートコントラクトの実行を許可されているブロックチェーンピアとして前記ブロックチェーンノードを識別するクレームを内部に含む、請求項１７に記載の非一時的コンピュータ可読媒体。
20. 前記検証可能なクレデンシャルは、前記検証可能なクレデンシャルがいつ作成されたかについてのタイムスタンプ、および満了値を含む、請求項１７に記載の非一時的コンピュータ可読媒体。