JP2023087665A - システム、方法、およびコンピュータプログラム製品（許可型ブロックチェーンのためのマルチ発行者匿名クレデンシャル） - Google Patents

Abstract

【課題】単一のルートオーソリティが存在しない場合でもユーザの匿名性を確保するシステム匿名クレデンシャル方式、システム、方法及びプログラムを提供する。【解決手段】ブロックチェーンネットワークのユーザは、１つ以上の承認済み発行者から選択される発行者からユーザのクレデンシャルを取得することができる。クレデンシャルは、ユーザの１つ以上の属性に基づき、１つ以上の属性に対する署名と秘密鍵とを含む。さらに、ユーザは、ペイロードと第２の署名とからなる操作を生成し、発行者の公開鍵に対するコミットメントを計算し、ｏｎｅ－ｏｕｔ－ｏｆ－ｍａｎｙ証明を用いて、コミットメントが承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることを証明し、ゼロ知識証明を用いて、発行者の公開鍵に基づく署名及びクレデンシャルに関する知識の証明を証明し、署名された秘密鍵及び属性の値に関する知識の証明を用いて証明を行う。【選択図】図６

Description

本開示は、ブロックチェーンネットワーク上での操作の処理に関し、より具体的には、許可型ブロックチェーン（permissioned blockchains）のためのマルチ発行者匿名クレデンシャル（multi-issuer anonymous credentials）に関する。

ブロックチェーンとは、ブロックと呼ばれる、暗号的にリンクされた記録のリストである。ブロックチェーンネットワークを用いて、様々な当事者による様々な種類の操作を制御することができる。

本開示は、単一のルートオーソリティが存在しない場合でもユーザの匿名性を確保する匿名クレデンシャル方式を提供することを目的とする。

本開示の実施形態は、ブロックチェーンネットワークにおける許可型ブロックチェーンのためのマルチ発行者匿名クレデンシャル用のシステム、方法、およびコンピュータプログラム製品を含む。

本開示の実施形態は、メモリと、前記メモリと通信するプロセッサと、を含むシステムを含む。前記プロセッサは、ユーザによって、当該ユーザの１つ以上の属性に基づく当該ユーザのクレデンシャルを発行者から取得することであって、当該発行者は、１つ以上の承認済み発行者から選択され、当該クレデンシャルは、当該１つ以上の属性に対する署名と秘密鍵とを含むことと、前記ユーザによって、ペイロードと第２の署名とからなる操作を生成することと、前記ユーザによって、前記発行者の公開鍵に対するコミットメントを計算することと、前記ユーザによってone-out-of-many証明を用いて、前記コミットメントが前記承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることを証明することと、前記ユーザによってゼロ知識証明を用いて、前記発行者の前記公開鍵に基づく前記署名および前記クレデンシャルに関する知識の証明を証明することと、前記ユーザによって、署名された前記秘密鍵および属性の値に関する知識の証明を用いて、証明を行うことと、を含むプロセスを実行するように構成されている。

本開示のさらなる実施形態は、ユーザによって、当該ユーザの１つ以上の属性に基づく当該ユーザのクレデンシャルを発行者から取得することであって、当該発行者は、１つ以上の承認済み発行者から選択され、当該クレデンシャルは、当該１つ以上の属性に対する署名と秘密鍵とを含むことと、前記ユーザによって、ペイロードと第２の署名とからなる操作を生成することと、前記ユーザによって、前記発行者の公開鍵に対するコミットメントを計算することと、前記ユーザによってone-out-of-many証明を用いて、前記コミットメントが前記承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることを証明することと、前記ユーザによってゼロ知識証明を用いて、前記発行者の前記公開鍵に基づく前記署名および前記クレデンシャルに関する知識の証明を証明することと、前記ユーザによって、署名された前記秘密鍵および属性の値に関する知識の証明を用いて、証明を行うことと、を含む、方法を含む。

本開示のさらなる実施形態は、プログラム命令が実装されたコンピュータ可読記憶媒体を含むコンピュータプログラム製品を含む。当該プログラム命令はプロセッサによって実行可能であり、当該プロセッサに、ユーザによって、当該ユーザの１つ以上の属性に基づく当該ユーザのクレデンシャルを発行者から取得することであって、当該発行者は、１つ以上の承認済み発行者から選択され、当該クレデンシャルは、当該１つ以上の属性に対する署名と秘密鍵とを含むことと、前記ユーザによって、ペイロードと第２の署名とからなる操作を生成することと、前記ユーザによって、前記発行者の公開鍵に対するコミットメントを計算することと、前記ユーザによってone-out-of-many証明を用いて、前記コミットメントが前記承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることを証明することと、前記ユーザによってゼロ知識証明を用いて、前記発行者の前記公開鍵に基づく前記署名および前記クレデンシャルに関する知識の証明を証明することと、前記ユーザによって、署名された前記秘密鍵および属性の値に関する知識の証明を用いて、証明を行うことと、を含む方法を実行させる。

上記の要約は、本開示における各図示された実施形態またはすべての実装形態を説明することを意図していない。

本開示に含まれる図面は、本明細書に組み込まれ、かつ本明細書の一部を構成する。これらの図面は、本開示の実施形態を例示し、かつ、明細書と併せて、本開示の原理を説明することに資するものである。図面は、特定の実施形態を例示するものに過ぎず、本開示を限定するものではない。

図１は、例示的な実施形態に係る、データベースを含むシステムのネットワーク図である。 図２Ａは、例示的な実施形態に係る、例示的なブロックチェーンアーキテクチャ構成を示す図である。 例示的な実施形態に係る、ブロックチェーントランザクションのフローを示す図である。 図３Ａは、例示的な実施形態に係る、許可型ネットワークを示す図である。 図３Ｂは、例示的な実施形態に係る、別の許可型ネットワークを示す図である。 図３Ｃは、例示的な実施形態に係る、非許可型ネットワークを示す図である。 図４Ａは、例示的な実施形態に係る、分散型台帳に新たなブロックを追加するためのプロセスを示す図である。 図４Ｂは、例示的な実施形態に係る、新たなデータブロックの内容を示す図である。 図４Ｃは、例示的な実施形態に係る、デジタルコンテンツ用のブロックチェーンを示す図である。 図４Ｄは、例示的な実施形態に係る、ブロックチェーンにおけるブロックの構造を表すことができるブロックを示す図である。 図５は、本開示の実施形態に係る、本明細書に記載の方法、ツール、モジュール、およびいずれかの関連機能のうちの１つ以上を実装する際に使用可能な一例としてのコンピュータシステムの概略ブロック図である。 図６は、例示的な実施形態に係る、ブロックチェーンネットワークにおける許可型ブロックチェーンのためのマルチ発行者匿名クレデンシャルの方法の一例のフローチャートである。

本明細書に記載する各実施形態は、様々な変更および代替形態が可能であるが、これらの実施形態の具体的な内容を、図面に例示し、かつ詳細に説明する。ただし、本明細書に記載する具体的な実施形態は、限定的な意味で解釈されるべきではない。むしろ、本開示の主旨および範囲に含まれるすべての変形、均等物、および代替形態を包含することが意図される。

本開示の態様は、ブロックチェーンネットワーク上の操作の処理に関し、より具体的には、ブロックチェーンネットワークにおける許可型ブロックチェーンのためのマルチ発行者匿名クレデンシャルに関する。

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

本明細書全体を通じて説明される特徴、構造、または特性は、１つ以上の実施形態において、任意の適切な方法で組み合わされるか、または削除されてもよい。例えば、「例示的な実施形態」、「一部の実施形態」、または他の同様の言葉が使用される場合、本明細書全体を通じて、実施形態に関連して説明される特定の特徴、構造、または特性が、少なくとも１つの実施形態に含まれ得ることを意味する。したがって、「例示的な実施形態」、「一部の実施形態」、「他の実施形態」、または他の同様の言葉が出てきた場合、本明細書全体を通じて、必ずしもすべてが同一の実施形態のグループを指すわけではなく、説明される特徴、構造、または特性は、１つ以上の実施形態において、任意の適切な方法で組み合わされてもよいし、削除されてもよい。さらに、図面において、要素間の任意の接続は、図示された接続が一方向または双方向の矢印である場合でも、一方向通信もしくは双方向通信またはその両方を許容することができる。また、図面に示された任意のデバイスは、異なるデバイスであってもよい。例えば、情報を送信するモバイルデバイスが図示されている場合、当該情報を送信するのに有線デバイスを使用してもよい。

さらに、「メッセージ」という用語が各実施形態の説明において用いられる場合があるが、本出願は、多くの種類のネットワークおよびデータに適用可能である。さらに、例示的な実施形態において、特定の種類の接続、メッセージ、および信号伝達が示される場合があるが、本出願は、ある特定の種類の接続、メッセージ、および信号伝達に限定されない。

一部の実施形態において、方法、システム、もしくはコンピュータプログラム製品またはその組み合わせは、相互に通信する複数のノードを含む分散型ストレージシステムである、（ブロックチェーンなどの）非集中型データベース（decentralized database）を利用する。非集中型データベースは、相互に信頼されていない関係者間でレコードを維持することができる分散型台帳に似た、追加専用（append-only）の変更不可能（immutable）なデータ構造を含む。信頼されていない関係者を、本明細書ではピアまたはピアノードと呼ぶ。各ピアは、データベースレコードのコピーを維持し、単一のピアは、分散されたピア間で合意に達しなければ、データベースレコードを変更することができない。例えば、ピアは、コンセンサスプロトコルを実行して、ブロックチェーン格納トランザクションを認証（validate）し、それらの格納トランザクションをブロックにグループ化し、複数ブロックのハッシュチェーンを構築してもよい。このプロセスは、一貫性のために、必要に応じて格納トランザクションを順序付ける（order）ことによって台帳を形成する。

各種の実施形態において、許可型ブロックチェーンもしくは非許可型（permission-less）ブロックチェーンまたはその両方を用いてもよい。公開型または非許可型ブロックチェーンでは、誰もが特定の識別情報を持たずに（例えば、匿名性を維持しながら）参加可能である。公開型ブロックチェーンは、ネイティブ暗号通貨を含むことができ、プルーフオブワーク（Proof of Work）などの各種のプロトコルに基づくコンセンサスを用いることができる。一方、許可型ブロックチェーンデータベースは、資金、商品、情報などを交換する企業など、共通の目標を持ちながらも、互いを完全には信頼していない実体のグループ間での安全なインタラクションを可能にする。

さらに、いくつかの実施形態において、方法、システム、もしくはコンピュータプログラム製品またはその組み合わせは、非集中型ストレージ方式に合わせて設計され、「スマートコントラクト」または「チェーンコード」と呼ばれる任意のプログラム可能なロジックを動作させるブロックチェーンを用いることができる。いくつかの場合、システムチェーンコードと呼ばれる、管理機能およびパラメータのための専用チェーンコードが存在する場合がある。方法、システム、もしくはコンピュータプログラム製品またはその組み合わせはさらに、ブロックチェーンデータベースが持つ改ざん防止の特性、およびノード間の基礎になる合意（エンドースメント(endorsement)またはエンドースメントポリシーと呼ばれる）を活用する、信頼性の高い分散型アプリケーションであるスマートコントラクトを利用することができる。このアプリケーションに関連付けられたブロックチェーントランザクションは、ブロックチェーンにコミットされる前に「エンドース」されることができ、エンドースされていないトランザクションは無視される。

エンドースメントポリシーでは、チェーンコードが、トランザクションのエンドーサ（endorser）を、エンドースメントに必要なピアノードのセットという形で指定することができる。クライアントが、エンドースメントポリシーにおいて指定されたピアにトランザクションを送信すると、トランザクションを認証するためのトランザクションが実行される。認証後、トランザクションは順序付けフェーズに移行し、コンセンサスプロトコルが使用され、ブロックへとグループ化されたエンドース済みのトランザクションの順序付けされたシーケンスが生成される。

いくつかの実施形態において、方法、システム、もしくはコンピュータプログラム製品またはその組み合わせは、ブロックチェーンシステムにおける通信エンティティであるノードを利用することができる。「ノード」は、異なる種類の複数のノードが同じ物理サーバ上で実行可能であるという意味で、論理機能を実行することができる。ノードは、信頼ドメイン内でグループ化され、様々な方式でこれらのノードを制御する論理エンティティに関連付けられる。ノードは、トランザクション呼び出しをエンドーサ（例えば、ピア）にサブミットするとともに、トランザクション提案を順序付けサービス（例えば、順序付けノード）にブロードキャストするクライアントノードまたはサブミットクライアントノードなど、異なる種類を含んでもよい。

別の種類のノードとしては、クライアントが提出したトランザクションを受信し、トランザクションをコミットし、ブロックチェーントランザクションの台帳の状態およびコピーを維持することができるピアノードがある。ピアはエンドーサの役割を持つこともできるが、これは必要条件ではない。順序付けサービスノードまたはオーダラ（orderer）は、すべてのノードのために通信サービスを実行するノードである。いくつかの場合、順序付けサービスノードは、トランザクションをコミット／確認するとき、およびブロックチェーンのワールド状態（world state）を変更するときの、システム内のピアノードの各々へのブロードキャストなどの配信保証（delivery guarantee）を実施する。ワールド状態とは、通常は制御情報および設定情報を含む初期ブロックチェーントランザクションの別名である。

いくつかの実施形態において、方法、システム、もしくはコンピュータプログラム製品またはその組み合わせは、ブロックチェーンのすべての状態遷移の、シーケンス化された改ざん防止機能付きのレコードである台帳を利用する。状態遷移は、参加している関係者（例えばクライアントノード、順序付けノード、エンドーサノード、ピアノードなど）によってサブミットされたチェーンコード呼び出し（例えば、トランザクション）から生じる場合がある。各参加している関係者（ピアノードなど）は、台帳のコピーを維持することができる。いくつかの実施形態において、参加している関係者は、操作に関わっている関係者（例えば、ブロックチェーンネットワーク上にノードを有する組織）である。トランザクションの結果、アセットのキーと値のペアのセットが、作成、更新、削除などの１つ以上のオペランドとして台帳にコミットされ得る。台帳は、シーケンス化された変更不可能なレコードをブロックに格納するのに用いられるブロックチェーン（チェーンとも呼ばれる）を含む。台帳はまた、ブロックチェーンの現在の状態を維持する状態データベースを含む。

いくつかの実施形態において、本明細書の記載の方法、システム、もしくはコンピュータプログラム製品またはその組み合わせは、ハッシュによってリンクされたブロック（hash-linked blocks）として構造化されたトランザクションログであるチェーンを利用することができる。各ブロックは、Ｎ個のトランザクションのシーケンスを含む（ここで、Ｎは１以上である）。ブロックヘッダは、ブロックのトランザクションのハッシュ、および先行ブロックのヘッダのハッシュを含む。このようにして、台帳上のすべてのトランザクションがシーケンス化され、暗号的に互いにリンクすることができる。したがって、ハッシュリンクを壊さずに台帳データを改ざんすることはできない。直近で追加されたブロックチェーンのブロックのハッシュは、それ以前に発生したチェーン上のすべてのトランザクションを表し、これにより、すべてのピアノードが一貫し、信頼された状態にあることを確実にできる。チェーンは、ブロックチェーンワークロードの追加専用という性質を効率的にサポートするピアノードのファイルシステム（すなわちローカル、接続型ストレージ、クラウドなど）に格納されてもよい。

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

ブロックチェーンが従来のデータベースと異なるのは、ブロックチェーンが中央ストレージではなく、むしろ非集中型の変更不可能かつ安全なストレージであり、ノードがストレージ内のレコードに対する変更を共有しなければならないという点にある。ブロックチェーンに固有であって、ブロックチェーンの実装に役立つ一部の特性としては、変更不可能な台帳、スマートコントラクト、セキュリティ、プライバシー、非集中化、コンセンサス、エンドースメント、アクセス可能性、などが挙げられる（ただし、これらに限定されない）。これらについては本明細書でさらに説明する。

特に、ブロックチェーンの台帳データは変更不可能であり、それが、ブロックチェーンネットワークにおける操作の効率的な処理方法を実現する。また、ブロックチェーンにおける暗号化の使用は、セキュリティを実現し、信頼を構築する。スマートコントラクトは、ライフサイクルを完了するためにアセットの状態を管理する。したがって、専用ノードは、匿名性の要件を有するブロックチェーン操作が、ブロックチェーンネットワークに対して安全に操作をサブミットできるようにすることができる。例示的なブロックチェーンは、許可分散型（permission decentralized）である。したがって、各エンドユーザは、アクセスするための自身の台帳コピーを有してもよい。複数の組織（およびピア）がブロックチェーンネットワークにオンボードされてもよい。主要な組織は、スマートコントラクトの実行結果、読み取りセット（read-set）および書き込みセット（write-set）を認証するためのエンドーシングピア（endorsing peers）として機能してもよい。すなわち、ブロックチェーンに固有の特徴により、ブロックチェーンネットワークにおけるプライベートトランザクション処理の効率的な実装が可能になる。

例示的な実施形態の利点の一つは、ブロックチェーンネットワークにおけるプライベートトランザクションを処理するための方法を実装することによって、コンピューティングシステムの機能を向上できることである。本明細書に記載のブロックチェーンシステムを通じて、コンピューティングシステム（または、コンピューティングシステム内のプロセッサ）は、分散台帳、ピア、暗号化技術、ＭＳＰ、イベント処理などの能力へのアクセスを提供することによって、ブロックチェーンネットワークを用いたプライベートトランザクション処理の機能を実行することができる。また、ブロックチェーンは、ビジネスネットワークを作成することを可能にし、任意のユーザまたは組織をオンボードさせて参加させることができる。このように、ブロックチェーンは、単なるデータベースではない。ブロックチェーンは、ユーザとオンボード／オフボードの組織とが協働するためのネットワークを形成するとともに、スマートコントラクトの形でサービスプロセスを実行する能力を備えている。

一方、従来のデータベースは、例示的な実施形態の実施に有用ではない可能性がある。なぜなら、従来のデータベースは、すべての関係者をネットワークに参加させず、従来のデータベースは、信頼性の高い協力を生じさせることがなく、かつ、従来のデータベースは、安全かつ効率的に操作をサブミットする方法を実現しないからである。従来のデータベースでは、改ざん防止ストレージが得られず、保証された有効なトランザクションが得られない。したがって、例示的な実施形態は、ブロックチェーンネットワークにおいて匿名で操作をサブミットする分野／領域における問題に対する具体的な解決手段を提供するものである。

図１は、例示的な実施形態に係る、ブロックチェーンネットワークにおけるスマートデータアノテーション（smart data annotation）のための論理ネットワーク図１００である。

図１を参照すると、例示的なネットワーク１００は、ドキュメントオーナー組織を表す他のブロックチェーン（ＢＣ）ノード１０５に接続されたノード１０２を含む。ノード１０２は、ノード１０５間で共有されるデータ１１０を格納するための台帳１０８を有するブロックチェーン１０６に接続されてもよい。この例では、１つのノード１０２のみを詳細に説明するが、複数のこのようなノードがブロックチェーン１０６に接続されてもよい。なお、ノード１０２は追加のコンポーネントを含んでもよく、本明細書に記載のコンポーネントの一部は、本明細書に開示するノード１０２の範囲から逸脱することなく、除去もしくは変更またはその両方が行われてもよい。ノード１０２は、コンピューティングデバイスまたはサーバコンピュータなどであってもよく、プロセッサ１０４を含んでもよい。プロセッサ１０４は、半導体ベースのマイクロプロセッサ、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、もしくは別のハードウェアデバイスまたはその組み合わせであってもよい。なお、単一のプロセッサ１０４を図示しているが、ノード１０２は、ノード１０２システムの範囲から逸脱することなく、複数のプロセッサ、複数のコアなどを含んでもよい。分散ファイルストレージ１５０が、プロセッサノード１０２および他のＢＣノード１０５にアクセス可能であってもよい。分散ファイルストレージ１５０を用いて、台帳１０８において識別されるドキュメントを格納してもよい。

ノード１０２はまた、プロセッサ１０４によって実行可能な機械可読命令を記憶可能な非一時的コンピュータ可読媒体１１２を含んでもよい。機械可読命令の例を、符号１１４～１１８として示すが、これについては以下で詳述する。非一時的コンピュータ可読媒体１１２の例は、実行可能な命令を含むかまたは記憶する電子、磁気、光学、または他の物理的な記憶装置を含んでもよい。例えば、非一時的コンピュータ可読媒体１１２は、ＲＡＭ、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、ハードディスク、光ディスク、または他の種類の記憶装置であってもよい。

プロセッサ１０４は、ユーザをタプルに関連付ける機械可読命令１１４を実行してもよい。上述したように、ブロックチェーン台帳１０８は、ノード１０５間で共有されるデータ１１０を記憶してもよい。ブロックチェーン１０６のネットワークは、複数の参加ノードのトランザクションを管理する１つ以上のスマートコントラクトを使用するように構成されてもよい。アノテーション情報にリンクされたドキュメントは、分散ファイルストレージ１５０に記憶されてもよい。プロセッサ１０４は、発行者をＰＫ公開鍵に関連付ける機械可読命令１１６を実行してもよい。プロセッサ１０４は、ユーザによる操作に署名する機械可読命令１１８を実行してもよい。

図２Ａは、例示的な実施形態に係る、ブロックチェーンアーキテクチャ構成２００を示す。図２Ａを参照すると、ブロックチェーンアーキテクチャ２００は、特定のブロックチェーン要素（例えば、ブロックチェーンノードのグループ２０２）を含んでもよい。ブロックチェーンノード２０２は、１つ以上のピアノード２０４、２０６、２０８、２１０を含んでもよい（これら４つのノードは、例示に過ぎない）。これらのノードは、ブロックチェーントランザクションの追加や認証プロセス（コンセンサス）など、複数の活動に参加する。ブロックチェーンノード２０４～２１０のうちの１つ以上は、エンドースメントポリシーに基づいてトランザクションをエンドースしてもよく、アーキテクチャ２００内のすべてのブロックチェーンノード２０２に対する順序付けサービスを提供してもよい。ブロックチェーンノード２０４～２１０は、ブロックチェーン認証（authentication）を開始し、ブロックチェーンレイヤ２１６に格納されたブロックチェーンの変更不可能な台帳への書き込みを求めてもよい。そのコピーは、基盤となる物理インフラストラクチャ２１４に格納されてもよい。ブロックチェーン構成２００は、１つ以上のアプリケーション２２４を含んでもよい。アプリケーション２２４は、参加者が求めるカスタマイズされた構成に従って作成され、参加者自身の状態を維持し、参加者自身のアセットを制御し、外部情報を受信することができる格納されたプログラム／アプリケーションコード２２０（たとえば、チェーンコード、スマートコントラクトなど）にアクセスしてこれを実行するために、アプリケーションプログラミングインタフェース（ＡＰＩ）２２２にリンクされている。これは、トランザクションとしてデプロイし、分散型台帳に追加することによって、すべてのブロックチェーンノード２０４～２１０にインストールすることができる。

ブロックチェーンベースまたはプラットフォーム２１２は、ブロックチェーンデータ、サービス（例えば、暗号信用サービス、仮想実行環境など）、ならびに、新たなトランザクションを受信および格納するとともに、データエントリにアクセスしようとしている監査人（auditors）にアクセスを提供するために使用可能な基礎となる物理コンピュータインフラストラクチャ２１４の様々なレイヤを含んでもよい。ブロックチェーンレイヤ２１６は、プログラムコード２２０を処理して物理インフラストラクチャ２１４を参加させるために必要な仮想実行環境へのアクセスを提供するインタフェースを公開してもよい。暗号信用サービス２１８は、アセット交換トランザクションなどのトランザクションを検証（verify）し、情報をプライベートに維持するのに使用されてもよい。

図２Ａのブロックチェーンアーキテクチャ構成２００は、ブロックチェーンプラットフォーム２１２によって公開される１つ以上のインタフェースおよび提供されるサービスを介して、プログラム／アプリケーションコード２２０を処理および実行することができる。コード２２０は、ブロックチェーンアセットを制御してもよい。例えば、コード２２０は、データを格納および転送することができ、スマートコントラクト、および条件を含む関連チェーンコードまたは実行の対象になる他のコード要素の形態で、ノード２０４～２１０によって実行されてもよい。非限定的な例として、リマインダ、更新、もしくは、変更や更新等の対象になる他の通知、またはその組み合わせを実行するために、スマートコントラクトが作成されてもよい。スマートコントラクトは、それ自体、承認およびアクセス要件ならびに台帳の使用に関連するルールを識別するのに使用することができる。例えば、ドキュメント属性情報２２６は、ブロックチェーンレイヤ２１６に含まれる１つ以上の処理エンティティ（例えば、仮想マシン）により処理されてもよい。この処理の結果２２８は、リンクされた複数の共有ドキュメントを含んでもよい。物理インフラストラクチャ２１４は、本明細書に記載のデータまたは情報のいずれを取得するために利用されてもよい。

スマートコントラクトは、高水準のアプリケーションおよびプログラミング言語を介して作成し、ブロックチェーン内のブロックに書き込んでもよい。スマートコントラクトは、ブロックチェーン（例えば、ブロックチェーンピアの分散ネットワーク）への登録、格納、もしくは複製またはその両方が行われる実行可能コードを含んでもよい。トランザクションとは、スマートコントラクトに関連する条件が満たされることに応じて実行可能なスマートコントラクトコードの実行である。スマートコントラクトの実行により、デジタルブロックチェーン台帳の状態に対する信頼できる変更をトリガーしてもよい。スマートコントラクトの実行によって引き起こされるブロックチェーン台帳への変更は、１つ以上のコンセンサスプロトコルを介して、ブロックチェーンピアの分散ネットワーク全体に自動的に複製されてもよい。

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

チェーンコードは、追加機能とともに、スマートコントラクトのコード解釈（code interpretation）を含んでもよい。本明細書に記載するように、チェーンコードは、コンピューティングネットワーク上にデプロイされるプログラムコードであってもよく、コードはコンセンサスプロセス中にチェーンバリデータ（chain validators）によって一緒に実行および認証される。チェーンコードは、ハッシュを受信し、以前に格納された特徴抽出機能（feature extractor）を使用することで作成されたデータテンプレートに関連付けられたハッシュをブロックチェーンから取得する。ハッシュ識別子のハッシュと、格納された識別子テンプレートデータから作成されたハッシュが一致する場合、チェーンコードは、承認キー（authorization key）を、要求されたサービスに送信する。チェーンコードは、暗号の詳細に関連するデータをブロックチェーンに書き込んでもよい。

図２Ｂは、例示的な実施形態に係る、ブロックチェーン（例えば、図１に示すブロックチェーン１０６）のノード間のブロックチェーントランザクションフロー２５０の一例を示す図である。図２Ｂを参照して、トランザクションフロー２５０の一般的な説明を行い、それに続けて、より具体的な例を示す。トランザクションフロー２５０は、アプリケーションクライアントノード２６０によって第１のエンドーシングピアノード２８１に送信されるトランザクション提案２９１を含んでもよい。第１のエンドーシングピア２８１は、クライアントの署名を検証し、チェーンコード機能を実行して、トランザクションを開始してもよい。出力は、チェーンコードの結果、チェーンコードにおいて読み取られたキー／値のバージョンのセット（読み取りセット）、およびチェーンコードにおいて書き込まれたキー／値のセット（書き込みセット）を含んでもよい。提案応答（proposal response）２９２が、承認される場合はエンドースメント署名とともに、クライアント２６０に送り返される。クライアント２６０は、エンドースメントをトランザクションペイロード２９３にまとめて、それを順序付けサービス（第４のピア）ノード２８４にブロードキャストする。次に、順序付けサービスノード２８４は、順序付けされたトランザクションを、ブロックとして同じチャネル上のすべての追加ピア２８１、２８２、２８３に配信する。ブロックチェーンへのコミットの前に、各追加ピア２８１～２８３は、トランザクションを認証してもよい。例えば、ピア２８１～２８３は、トランザクション提案２９１で指定されたピアの正しい割り当てが結果に署名し、トランザクションペイロード２９３に対する署名を認証したことを保証するために、エンドースメントポリシーをチェックしてもよい。いくつかの実施形態において、ピアの１つ以上は、マネージャノードであってもよい。

トランザクションフロー２５０のより具体的な説明は、より具体的な例によって理解することができる。初めに、クライアントノード２６０は、リクエストを構築して、エンドーサであるピアノード２８１に送信することによって、トランザクション提案２９１を開始する。クライアント２６０は、利用可能なＡＰＩ用いてトランザクション提案を生成する、サポートされたソフトウェア開発キット（ＳＤＫ）を利用するアプリケーションを含んでもよい。提案は、データを台帳から読み取り、もしくは台帳に書き込み（すなわち、アセットの新たなキーと値のペアを書き込み）、またはその両方が行えるように、チェーンコード関数を呼び出すリクエストである。ＳＤＫは、トランザクション提案を適切に設計されたフォーマット（例えば、遠隔手続き呼び出し（ＲＰＣ：remote procedure call）を経由するプロトコルバッファ）にパッケージ化するシム（shim）として機能し、クライアントの暗号クレデンシャルを受け取って、トランザクション提案の一意の署名を生成してもよい。

これに応じて、エンドーシングピアノード２８１は、（ａ）トランザクション提案が適切に形成されていること、（ｂ）トランザクションが過去にすでにサブミットされていないこと（リプレイアタック保護（replay-attack protection））、（ｃ）署名が有効であること、および（ｄ）そのチャネルに対する提案された操作を実行するための適切な権限がサブミッタ（この例では、クライアント２６０）に与えられていることを検証してもよい。エンドーシングピアノード２８１は、トランザクション提案の入力を、呼び出されるチェーンコード関数への引数として受け取ってもよい。その後、チェーンコードが、現在の状態データベースに対して実行され、応答値、読み取りセット、および書き込みセットを含むトランザクション結果を生成する。ただしこの時点では、台帳に対する更新は行われない。トランザクション結果のセットが、エンドーシングピアノード２８１の署名と共に、提案応答２９２としてクライアント２６０のＳＤＫに返され、このＳＤＫが、アプリケーションが使用するためのペイロードを解析する。

それに応じて、クライアント２６０のアプリケーションが、エンドーシングピア２８１の署名を検査／検証し、提案応答２９２を比較して、提案応答２９２が有効であるかどうかを判定する。チェーンコードが単に台帳を照会した場合、アプリケーションは照会応答を検査し、通常は、トランザクションを順序付けサービスノード２８４にサブミットしない。クライアントアプリケーションが、台帳を更新するためにトランザクションを順序付けサービスノード２８４にサブミットすることを意図している場合、アプリケーションは、サブミットする前に、指定されたエンドースメントポリシーが満たされているかどうか（すなわち、トランザクションに必要なすべてのピアノードがトランザクションをエンドースしたかどうか）を判定する。ここで、クライアント２６０は、トランザクションの複数の関係者のうちの１つのみを含んでもよい。この場合、各クライアントは、自身のエンドーサノードを含んでもよく、各エンドーサノードがトランザクションをエンドースする必要がある。アーキテクチャは、アプリケーションが応答を検査しないことを選択するか、またはその他の方法でエンドースされていないトランザクションを転送する場合でも、エンドースメントポリシーが、ピアによって依然として施行され、コミット認証フェーズにおいて維持されるようになっている。

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

トランザクション２９３のブロックは、順序付けノード２８４からチャネル上の他のすべてのピアノード２８１～２８３に配信される。ブロック内のトランザクション２９４は、どのエンドースメントポリシーも満たされていることを保証するために、かつ、読み取りセットがトランザクション実行によって生成されてから、読み取りセットの変数に関して台帳状態に対する変更がなかったことを保証するために、認証が行われる。ブロック内のトランザクション２９４は、有効または無効としてタグ付けされる。さらに、操作２９５において、各ピアノード２８１～２８３は、ブロックをチャネルのチェーンに追加し、各有効なトランザクションについて、現在の状態データベースに書き込みセットがコミットされる。トランザクション（呼び出し）２９３が変更不可能な形でチェーンに追加されたことをクライアントアプリケーションに通知するために、かつトランザクション２９３が有効にされたか、または無効にされたかを通知するために、イベントが発せられる。

図３Ａは、例示的な実施形態に係る、一例としての許可型ブロックチェーンネットワーク３００を示す図である。ネットワーク３００は、分散型の非集中的ピアツーピアアーキテクチャを特徴とする。この例では、ブロックチェーンユーザ３０２は、許可型ブロックチェーン３０４に対するトランザクションを開始してもよい。この例では、トランザクションは、デプロイ、呼び出し、または照会とすることができ、ＳＤＫを利用するクライアント側のアプリケーションを介して、またはＡＰＩを介して直接的に、などの態様で発行されてもよい。ネットワーク３００は、監査人などのレギュレータ３０６へのアクセスを提供してもよい。ブロックチェーンネットワークオペレータ３０８は、レギュレータ３０６を「監査人」として登録し、ブロックチェーンユーザ３０２を「クライアント」として登録するなど、メンバー許可を管理する。監査人を、台帳の照会のみに制限してもよく、クライアントは、特定の種類のチェーンコードのデプロイ、呼び出し、および照会を行う権限が付与されてもよい。

ブロックチェーン開発者３１０は、チェーンコードおよびクライアント側のアプリケーションを書き込むことができる。ブロックチェーン開発者３１０は、インタフェースを介して、チェーンコードをネットワーク３００に直接デプロイすることができる。従来のデータソース３１２からのクレデンシャルをチェーンコードに含めるために、開発者３１０は、アウトオブバンド接続（out-of-band connection）を使用してデータにアクセスしてもよい。この例では、ブロックチェーンユーザ３０２は、ピアノード３１４の１つ（ノード３１４ａ～ｅのいずれかを指す）を介して許可型ブロックチェーン３０４に接続する。ピアノード３１４（例えば、ノード３１４ａ）は、いずれかのトランザクションを開始する前に、ユーザ３０２の登録およびトランザクションの証明書を、ユーザの役割および許可を管理する認証機関３１６から取得する。場合によっては、ブロックチェーンユーザは、許可型ブロックチェーン３０４上でトランザクションを行うために、これらのデジタル証明書を所有していなければならない。一方、チェーンコードを利用しようとしているユーザは、従来のデータソース３１２上の自身のクレデンシャルを検証することが要求される場合がある。ユーザ３０２の権限付与を確認するために、チェーンコードは、従来の処理プラットフォーム３１８を介して、このデータへのアウトオブバンド接続を使用することができる。

図３Ｂは、例示的な実施形態に係る、別の例としての許可型ブロックチェーンネットワーク３２０を示す図である。ネットワーク３２０は、分散型の非集中的ピアツーピアアーキテクチャを特徴とする。この例では、ブロックチェーンユーザ３２２は、トランザクションを許可型ブロックチェーン３２４にサブミットしてもよい。この例では、トランザクションは、デプロイ、呼び出し、または照会とすることができ、ＳＤＫを利用するクライアント側のアプリケーションを介して、またはＡＰＩを介して直接的に、などの態様で発行されてもよい。ネットワークは、監査人などのレギュレータ３２６へのアクセスを提供してもよい。ブロックチェーンネットワークオペレータ３２８は、レギュレータ３２６を「監査人」として登録し、ブロックチェーンユーザ３２２を「クライアント」として登録するなど、メンバー許可を管理する。監査人を、台帳の照会のみに制限してもよく、クライアントは、特定の種類のチェーンコードのデプロイ、呼び出し、および照会を行う権限が付与されてもよい。

ブロックチェーン開発者３３０は、チェーンコードおよびクライアント側のアプリケーションを書き込む。ブロックチェーン開発者３３０は、インタフェースを介して、チェーンコードをネットワークに直接デプロイすることができる。従来のデータソース３３２からのクレデンシャルをチェーンコードに含めるために、開発者３３０は、アウトオブバンド接続を使用してデータにアクセスしてもよい。この例では、ブロックチェーンユーザ３２２は、ピアノード３３４（ノード３３４ａ～ｅのいずれかを指す）を介してネットワークに接続する。ピアノード３３４（例えば、ノード３３４ａ）は、いずれかのトランザクションを開始する前に、ユーザの登録およびトランザクションの証明書を認証機関３３６から取得する。場合によっては、ブロックチェーンユーザは、許可型ブロックチェーン３２４上でトランザクションを実行するために、これらのデジタル証明書を所有していなければならない。一方、チェーンコードを利用しようとしているユーザは、従来のデータソース３３２上の自身のクレデンシャルを検証することが要求される場合がある。ユーザの権限付与を確認するために、チェーンコードは、従来の処理プラットフォーム３３８を介して、このデータへのアウトオブバンド接続を使用することができる。

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

図３Ｃは、例示的な実施形態に係る、複数のノード３５４を含む非許可型ブロックチェーン３５２によってトランザクションが処理されるネットワーク３５０を示す図である。送信側３５６は、非許可型ブロックチェーン３５２を介して、支払いまたはその他の形態の値（例えば、証書、医療記録、契約、商品、サービス、またはデジタルレコードにカプセル化可能な任意の他のアセット）を受信側３５８に送信することを望んでいる。いくつかの実施形態において、送信側デバイス３５６および受信側デバイス３５８の各々は、トランザクションパラメータのユーザインタフェース制御および表示を提供する（ブロックチェーン３５２に関連付けられた）デジタルウォレットを有してもよい。それに応じて、トランザクションがブロックチェーン３５２全体のノード３５４（ノード３５４ａ～ｅのいずれかを指す）にブロードキャストされる。

ブロックチェーン３５２のネットワークパラメータに応じて、ノードは、非許可型ブロックチェーン３５２の作成者によって確立されたルール（事前に定義されるか、または動的に割り当て可能である）に基づいてトランザクションを検証するための検証モジュール３６０を使用する。例えば、この検証は、関与する当事者の識別情報を検証することなどを含んでもよい。トランザクションは、直ちに検証されてもよいし、他のトランザクションと共にキューに配置されてもよい。そして、ノード３５４は、ネットワークルールのセットに基づいてトランザクションが有効であるかどうかを判定する。

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

ブロックをブロックチェーン３５２に追加する前に、ブロックを認証する必要がある。非許可型ブロックチェーン３５２の場合の認証は、ブロックのヘッダから得られるパズルへの解であるプルーフオブワーク（ＰｏＷ）を含んでもよい。図３Ｃの例には示していないが、ブロックを認証する別のプロセスとして、プルーフオブステーク（proof-of-stake）がある。数学的問題を解いたマイナーにアルゴリズムが報酬を与えるプルーフオブワークとは異なり、プルーフオブステークでは、資産（wealth）（「ステーク」とも定義される）に応じて、新たなブロックの作成者が決定論的に選択される。その後、選定／選択されたノードによって、同様の証明が実行される。

マイニングモジュール３６４によって、ノードは、解がネットワーク全体にわたるターゲットを満たすまで、１つの変数に対してインクリメンタルな変更を加えることによって、ブロックを解くことを試みる。これにより、ＰｏＷが生成され、それによって正しい答えが保証される。言い換えれば、可能性のある解は、計算リソースが問題を解くのに消費されたことを証明しなければならない。非許可型ブロックチェーンの一部の種類では、ブロックを正しくマイニングしたことに対する報酬としてマイナーに価値（例えば、コインなど）が与えられる場合がある。

ここで、ＰｏＷ処理は、ブロックのチェーン化と並行して、ブロックチェーン３５２に対する変更を極めて困難にする。これは、１つのブロックに対する変更を受け入れられるようにするには、攻撃者はすべての後続ブロックを変更しなければならないからである。さらに、新たなブロックがマイニングされると、ブロックの変更がさらに困難になり、後続ブロックの数が増加する。配布モジュール３６６によって、認証に成功したブロックが非許可型ブロックチェーン３５２を通して配布され、すべてのノード３５４が、そのブロックを、非許可型ブロックチェーン３５２の監査可能な台帳であるマジョリティチェーン（majority chain）に追加する。さらに、送信側３５６によってサブミットされたトランザクションにおける価値が、受信側デバイス３５８のデジタルウォレットに預け入れられるか、またはその他の方法で転送される。

図４Ａは、例示的な実施形態に係る、分散型台帳４２０に新たなブロックを追加するプロセス４００を実行するブロックチェーンシステムを示す図である。図４Ｂは、例示的な実施形態に係る、ブロックチェーンに対する新たなデータブロック構造４３０の内容を示す図である。新たなデータブロック４３０は、ドキュメントリンク用データ（document linking data）を含んでもよい。

図４Ａを参照すると、プロセス４００においてクライアント（不図示）は、ブロックチェーンノード４１１、４１２、もしくは４１３またはその組み合わせにトランザクションをサブミットしてもよい。クライアントは、任意のソースから受信される、ブロックチェーン４２２上でアクティビティを実行する命令であってもよい。一例として、クライアントは、デバイス、人物、エンティティなどの要求者に代わって、ブロックチェーン４２２にトランザクションを提案するように機能するアプリケーションであってもよい。複数のブロックチェーンピア（例えば、ブロックチェーンノード４１１、４１２、４１３）は、ブロックチェーンネットワークの状態および分散型台帳４２０のコピーを維持してもよい。異なる種類のブロックチェーンノード／ピアが、ブロックチェーンネットワーク内に存在してもよい。これは例えば、クライアントによって提案されたトランザクションをシミュレートおよびエンドースするエンドーシングピアと、エンドースメントを検証し、トランザクションを認証し、トランザクションを分散型台帳４２０にコミットするコミッティングピア（committing peers）とを含む。この例では、ブロックチェーンノード４１１、４１２、４１３の各々は、エンドーサノード、コミッタノード、またはその両方の役割を果たしてもよい。

分散型台帳４２０は、変更不可能なシーケンス化レコードをブロック（例えば、データブロック４２３、４２４、４２５、４２６、４２７、４２８、４２９、４３０）に格納するブロックチェーンと、ブロックチェーン４２２の現在の状態を維持する状態データベース４２４（現在のワールド状態）とを含む。分散型台帳４２０が各チャネルに１つ存在してもよく、各ピアは、自身がメンバーである各チャネルに関する分散型台帳４２０のコピーを自身で維持する。ブロックチェーン４２２は、各ブロックがＮ個のトランザクションのシーケンスを含む、ハッシュでリンクされたブロックとして構築されるトランザクションログである。ブロックは、図４Ｂに示すものなどの各種のコンポーネントを含んでもよい。ブロック（例えば、ブロック４２３～４３０）のリンク付け（図４Ａにて矢印で示す）は、先行ブロックのヘッダのハッシュを、現在のブロックのブロックヘッダ内に追加することによって生成されてもよい。このように、ブロックチェーン４２２上のすべてのトランザクションが、シーケンス化されて暗号的に相互にリンクされるため、ハッシュリンクを破壊することなくブロックチェーンデータが改ざんされることが防止される。さらに、これらのリンクがあることにより、ブロックチェーン４２２内の最新ブロック（例えば、データブロック４３０）は、それに先行するすべてのトランザクションを表す。ブロックチェーン４２２は、追加専用ブロックチェーンワークロードをサポートする、ピアファイルシステム（ローカルまたは接続型ストレージ）に格納されてもよい。

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

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

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

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

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

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

図４Ｂを参照すると、分散型台帳４２０のブロックチェーン４２２に格納された新たなデータブロック４３０（データブロックとも呼ばれる）は、ブロックヘッダ４４０、ブロックデータ４５０、およびブロックメタデータ４６０などの、複数のデータセグメントを含んでもよい。なお、図４Ｂに示す新たなデータブロック４３０およびその内容などの、図示される各種のブロックおよびその内容は例示に過ぎず、例示的な実施形態の範囲を限定することを意図していない。新たなデータブロック４３０は、Ｎ個（例えば、１、１０、１００、５００、１０００、２０００、３０００など）のトランザクションのトランザクション情報をブロックデータ４５０内に格納してもよい。また、新たなデータブロック４３０は、（例えば、図４Ａのブロックチェーン４２２上の）先行ブロックへのリンクをブロックヘッダ４４０内に含んでもよい。特に、ブロックヘッダ４４０は、先行ブロックのヘッダのハッシュを含んでもよい。また、ブロックヘッダ４４０は、一意のブロック番号（例えば、データブロック４２３～４３０）や、新たなデータブロック４３０のブロックデータ４５０のハッシュなどを含んでもよい。新たなデータブロック４３０のブロック番号は、一意であり、０から始まる増分的／連続的な順序などの様々な順序で割り当てられてもよい。

ブロックデータ４５０は、新たなデータブロック４３０内に記録された各トランザクションのトランザクション情報を格納してもよい。例えば、トランザクションデータは、トランザクションの種類、バージョン、タイムスタンプ、分散型台帳４２０のチャネルＩＤ、トランザクションＩＤ、エポック、ペイロードの可視性、チェーンコードパス（トランザクションのデプロイ）、チェーンコード名、チェーンコードバージョン、入力（チェーンコードおよび機能）、公開鍵および証明書などのクライアント（作成者）識別情報、クライアントの署名、エンドーサの識別情報、エンドーサの署名、提案のハッシュ、チェーンコードイベント、応答の状態、名前空間、読み取りセット（トランザクションによって読み取られたキーとバージョンのリストなど）、書き込みセット（キーと値のリストなど）、開始キー、終了キー、キーのリスト、Ｍｅｒｋｅｌツリークエリサマリなどのうちの１つ以上を含んでもよい。トランザクションデータは、Ｎ個のトランザクションの各々について格納されてもよい。

また、いくつかの実施形態において、ブロックデータ４５０は、ブロックチェーン４２２内のハッシュでリンクされたブロックのチェーンにさらなる情報を追加する新たなデータ４６２を格納してもよい。さらなる情報は、本明細書で説明または図示するステップ、特徴、プロセス、もしくは動作またはその組み合わせのうちの１つ以上を含む。したがって、新たなデータ４６２は、分散型台帳４２０上のブロックの変更不可能なログ内に格納することができる。このような新たなデータ４６２を格納するメリットのいくつかは、本明細書で開示および図示する各種の実施形態に反映されている。なお、図４Ｂでは、新たなデータ４６２がブロックデータ４５０内に示されているが、新たなデータ４６２はブロックヘッダ４４０またはブロックメタデータ４６０内に位置してもよい。新たなデータ４６２は、組織内のドキュメントをリンクするのに用いられるドキュメント複合キー（document composite key）を含んでもよい。

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

図４Ｃは、本明細書に記載のいくつかの実施形態に係る、デジタルコンテンツのためのブロックチェーン４７０を示す図である。デジタルコンテンツは、１つ以上のファイルおよび関連情報を含んでもよい。ファイルは、メディア、イメージ、ビデオ、オーディオ、テキスト、リンク、グラフィック、アニメーション、ウェブページ、ドキュメント、または他の形態のデジタルコンテンツを含んでもよい。ブロックチェーンが持つ変更不可能かつ追加専用という特徴は、デジタルコンテンツの完全性、有効性、および真正性を保護するセーフガードとしての役割を果たし、このことにより、許容性ルール（admissibility rules）が適用される法的手続きにおいて、または、エビデンスが考慮される状況やデジタル情報の提示および使用がその他の点で関心事となる状況などの他の状況において、ブロックチェーンの使用が好適となる。この場合、デジタルコンテンツは、デジタルエビデンスと呼ばれる場合がある。

ブロックチェーンは、様々な方法で形成することができる。いくつかの実施形態において、デジタルコンテンツは、ブロックチェーン自体に含まれ、かつブロックチェーンからアクセスされてもよい。例えば、ブロックチェーンの各ブロックは、参照情報（例えば、ヘッダ、値など）のハッシュ値を、関連するデジタルコンテンツとともに格納してもよい。その後、ハッシュ値および関連するデジタルコンテンツは、一緒に暗号化されてもよい。したがって、各ブロックのデジタルコンテンツは、ブロックチェーン内の各ブロックを復号することによってアクセスすることができ、各ブロックのハッシュ値は、先行ブロックを参照するための基礎として用いることができる。これは、以下のように示すことができる。
ブロック１ ブロック２ ・・・ ブロックＮ
ハッシュ値１ ハッシュ値２ ハッシュ値Ｎ
デジタルコンテンツ１ デジタルコンテンツ２ デジタルコンテンツＮ

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

ブロックチェーン ストレージ領域
ブロック１のハッシュ値 ブロック１のハッシュ値…内容
・ ・
・ ・
・ ・
ブロックＮのハッシュ値 ブロックＮのハッシュ値…内容

図４Ｃの例示的な実施形態において、ブロックチェーン４７０は、順序付けられたシーケンスで暗号的にリンクされた複数のブロック４７８_１、４７８_２、・・・４７８_Ｎを含む（Ｎは１以上である）。ブロック４７８_１、４７８_２、・・・４７８_Ｎをリンクするのに用いられる暗号化は、複数の鍵付きハッシュ関数または鍵なしハッシュ関数のいずれかとすることができる。いくつかの実施形態において、ブロック４７８_１、４７８_２、・・・４７８_Ｎは、ブロック内の情報に基づく入力からｎビットの英字数字出力を生成するハッシュ関数の対象になる（ｎは２５６または別の数である）。このようなハッシュ関数の例としては、ＳＨＡ型アルゴリズム（ＳＨＡは、セキュアハッシュアルゴリズム（Secured Hash Algorithm）を表す）、マークルダンガード（Merkle-Damgard）アルゴリズム、ＨＡＩＦＡアルゴリズム、マークルツリー（Merkle-tree）アルゴリズム、ノンスベースの（nonce-based）アルゴリズム、および非衝突耐性（non-collision-resistant）疑似ランダム関数（ＰＲＦ：Pseudo Random Function）が挙げられる（ただし、これらに限定されない）。別の実施形態において、ブロック４７８_１、４７８_２、・・・４７８_Ｎは、ハッシュ関数とは異なる関数によって暗号的にリンクされてもよい。例示として、以下ではハッシュ関数（例えば、ＳＨＡ－２）を参照して説明を行う。

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

ブロックチェーン内の最初のブロック４７８_１は、ジェネシスブロックと呼ばれ、ヘッダ４７２_１と、元のファイル４７４_１と、初期値４７６_１とを含む。ジェネシスブロックに用いられる（そして実際には、すべての後続ブロックにおいて用いられる）ハッシュ方式は、異なってもよい。例えば、最初のブロック４７８_１内のすべての情報を一度にハッシュ化してもよいし、最初のブロック４７８_１内の情報の一部を個別にハッシュ化した後に、個別にハッシュ化された部分のハッシュを実行してもよい。

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

ジェネシスブロック内の元のファイル４７４_１は、例えば、デバイスによって取り込まれたデータとすることができる。データは、ブロックチェーンに含める前に処理されていてもよいし、処理されていなくてもよい。元のファイル４７４_１は、システムのインタフェースを介して、デバイス、媒体ソース、またはノードから受信される。元のファイル４７４_１は、メタデータと関連付けられる。メタデータは例えば、手動または自動のいずれかによって、ユーザ、デバイス、もしくはシステムプロセッサまたはその組み合わせによって生成されてもよい。メタデータは、元のファイル４７４_１に関連付けて最初のブロック４７８_１内に含まれてもよい。

ジェネシスブロック内の値４７６_１は、元のファイル４７４_１の１つ以上の固有の属性に基づいて生成された初期値である。いくつかの実施形態において、１つ以上の固有の属性は、元のファイル４７４_１のハッシュ値、元のファイル４７４_１のメタデータ、およびファイルに関連付けられた他の情報を含んでもよい。一実装形態において、初期値４７６_１は、以下の固有の属性に基づいてもよい。
１） ＳＨＡ－２によって元のファイルに対して計算されたハッシュ値
２） 発信デバイスＩＤ
３） 元のファイルの開始タイムスタンプ
４） 元のファイルの初期ストレージ位置
５） 元のファイルおよび関連メタデータをソフトウェアが現在制御するためのブロックチェーンネットワークメンバーＩＤ

ブロックチェーン内の他のブロック４７８_２～４７８_Ｎも、ヘッダ、ファイル、および値を含む。しかしながら、最初のブロックのヘッダ４７２_１とは異なり、他のブロック内のヘッダ４７２_２～４７２_２Ｎの各々は、直前のブロックのハッシュ値を含む。直前のブロックのハッシュ値は、単に先行ブロックのヘッダのハッシュであってもよいし、先行ブロック全体のハッシュ値であってもよい。先行ブロックのハッシュ値を残りのブロックの各々に含むことによって、矢印４８０で示すように、Ｎ番目のブロックからジェネシスブロック（および関連する元のファイル）まで戻るブロック単位のトレースを実行することができ、監査可能かつ変更不可能な証拠保全（chain-of-custody）を確立することができる。

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

他のブロック内のファイル４７２_２～４７２_Ｎは、例えば実行される処理の種類に応じて、元のファイルと同じであってもよいし、ジェネシスブロック内の元のファイルの変更されたバージョンであってもよい。実行される処理の種類は、ブロックごとに異なってもよい。処理は、例えば、情報を編集するか、もしくはその他の方法で情報の内容を変更するか、情報をファイルから取り除くか、または情報をファイルに追加するなどの、先行ブロック内のファイルの任意の変更を含んでもよい。

上記に加えて、または上記に代えて、処理は、先行ブロックからファイルを単にコピーすること、ファイルのストレージ位置を変更すること、１つ以上の先行ブロックからのファイルを分析すること、ファイルをあるストレージもしくはメモリ位置から別のストレージもしくはメモリ位置に移動すること、あるいは、ブロックチェーンのファイルもしくはその関連メタデータまたはその両方に対して動作を実行することを含んでもよい。ファイルの分析を伴う処理としては、例えば、様々な分析結果、統計値、またはファイルに関連付けられたその他の情報を追加すること、含めること、またはその他の関連付けることを含んでもよい。

他のブロックにおける他のブロック４７６_２～４７６_Ｎの各々の値は、実行された処理の結果として、固有の値であり、すべて異なっている。例えば、いずれか１つのブロックにおける値は、先行ブロックにおける値の更新されたバージョンに対応する。この更新は、値が割り当てられたブロックのハッシュに反映される。したがって、ブロックの値は、ブロックにおいてどのような処理が実行されたかを示すとともに、ブロックチェーンを元のファイルまで戻りトレースすることも可能にする。この追跡により、ブロックチェーン全体を通じて、ファイルの証拠保全が確認される。

例えば、ファイル内に示されている人物の識別情報を保護するべく、先行ブロック内のファイルの一部が編集、遮断、または画素化されている場合を考える。この場合、編集されたファイルを含むブロックは、例えば、編集がどのように実行されたか、誰が編集を実行したか、編集が行われたときのタイムスタンプなど、編集されたファイルに関連付けられたメタデータを含んでもよい。このメタデータはハッシュ化されて、値を形成してもよい。ブロックのメタデータは、先行ブロックにおける値を形成するためにハッシュ化された情報とは異っているため、これらの値は互いに異なっており、復号時に回復されてもよい。

いくつかの実施形態において、次のうちのいずれか１つ以上が発生した場合に、現在のブロックの値を形成するように、先行ブロックの値が更新されてもよい（例えば、新たなハッシュ値が計算されてもよい）。この例示的な実施形態において、新たなハッシュ値は、以下に示す情報のすべてまたは一部をハッシュ化することによって計算されてもよい。
ａ）ファイルがいずれかの方法で処理された場合（例えば、ファイルに対して編集、コピー、変更、アクセス、または他の何らかの動作が行われた場合）に、ＳＨＡ－２によって計算された新たなハッシュ値
ｂ）ファイルの新たなストレージ位置
ｃ）ファイルに関連付けられている識別された新たなメタデータ
ｄ）あるブロックチェーン参加者から別のブロックチェーン参加者への、ファイルのアクセスまたは制御の移転

図４Ｄは、いくつかの実施形態に係る、ブロックチェーン（例えば、４７０）内のブロックの構造を表すことができるブロック４９０を示す図である。ブロック（例えば、ブロック_ｉ）は、ヘッダ４７２_ｉ、ファイル４７４_ｉ、および値４７６_ｉを含む。

ヘッダ４７２_ｉは、先行ブロック（ブロック_ｉ-1）のハッシュ値と、追加の参照情報とを含む。参照情報は例えば、本明細書で説明する情報のいずれの種類であってもよい（例えば、参照、特性、パラメータなどを含むヘッダ情報）。すべてのブロック（当然ながらジェネシスブロックを除く）は、先行ブロックのハッシュを参照する。先行ブロックのハッシュ値は、単に先行ブロック内のヘッダのハッシュであってもよいし、ファイルおよびメタデータを含む、先行ブロック内の情報のすべてまたは一部のハッシュであってもよい。

ファイル４７４_ｉは、データ１、データ２、・・・データＮなどの複数のデータを順に含む。データは、データに関連付けられた内容もしくは特性またはその両方を記述するメタデータ１、メタデータ２、・・・メタデータＮでタグ付けされる。例えば、各データのメタデータは、データのタイムスタンプ、データのプロセス、データ内に示された人物もしくは他の内容を示すキーワード、もしくは、ファイル全体としての有効性および内容を確立するとともに、特に（例えば以下の実施形態に関連して説明するように）、デジタルエビデンスとしてのファイルの使用を確立するのに有用となり得る他の特徴、またはその組み合わせを含んでもよい。メタデータに加えて、各データは、改ざん、ファイル内のギャップ、およびファイル全体の連続的な参照を防止するために、先行データへの参照（ＲＥＦ_１、ＲＥＦ_２、・・・ＲＥＦ_Ｎ）でタグ付けされてもよい。

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

値４７６_ｉは、上述した情報の種類のいずれかに基づいて計算されたハッシュ値または他の値である。例えば、所与のブロック（ブロック_ｉ）の場合、当該ブロックの値は、当該ブロックに対して実行された処理（例えば、新たなハッシュ値、新たなストレージ位置、関連するファイルの新たなメタデータ、制御もしくはアクセスの移転、識別子、またはその他の動作もしくは追加される情報）を反映するように更新されてもよい。なお、各ブロック内の値が、ファイルおよびヘッダのデータのメタデータとは別個であるように示されているが、別の実施形態において、この値は、部分的にまたは全体的にこのメタデータに基づいてもよい。

ブロックチェーン４７０の形成後のいずれかの時点で、ブロック全体にわたる値のトランザクション履歴に関してブロックチェーンに照会することによって、ファイルの変更不可能な証拠保全が取得されてもよい。この照会、すなわち追跡手順はまず、最後に含まれたブロック（例えば、最後（Ｎ番目）のブロック）の値を復号し、次に、ジェネシスブロックに到達して元のファイルが回復されるまで、他のブロックの値の復号を続けてもよい。復号はさらに、各ブロックにおいてヘッダおよびファイルならびに関連メタデータを復号することを含んでもよい。

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

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

本明細書でより詳細に説明するように、本明細書に記載の方法の実施形態のいくつかにおける工程の一部または全部は、他の順序で行われてもよいし、まったく行われなくてもよいことが考えられる。さらに、複数の工程が同時に行われてもよいし、より大きなプロセスの内部部分として行われてもよい。

図５は、本開示の実施形態に係る、本明細書に記載の方法、ツール、モジュール、およびいずれかの関連する機能のうちの１つ以上を（例えば、コンピュータの１つ以上のプロセッサ回路またはコンピュータプロセッサを用いて）実装する際に使用可能な一例としてのコンピュータシステム５０１の概略ブロック図である。いくつかの実施形態において、コンピュータシステム５０１の主要なコンポーネントは、１つ以上のＣＰＵ５０２、メモリサブシステム５０４、端末インタフェース５１２、ストレージインタフェース５１６、Ｉ／Ｏ（入力／出力）デバイスインタフェース５１４、およびネットワークインタフェース５１８を含むことができる。これらはすべて、メモリバス５０３、Ｉ／Ｏバス５０８、およびＩ／Ｏバスインタフェースユニット５１０を介したコンポーネント間の通信を行うために直接または間接的に通信可能に結合することができる。

コンピュータシステム５０１は、１つ以上の汎用プログラマブル中央処理装置（ＣＰＵ）５０２Ａ、５０２Ｂ、５０２Ｃ、および５０２Ｄ（ここではＣＰＵ５０２と総称する）を含むことができる。いくつかの実施形態において、コンピュータシステム５０１は、比較的大型のシステムでよく見られるように複数のプロセッサを含んでもよいが、他の実施形態ではそれに代えて、コンピュータシステム５０１は単一のＣＰＵを用いたシステムであってもよい。各ＣＰＵ５０２は、メモリサブシステム５０４に記憶された命令を実行することができる。また、各ＣＰＵ５０２は、１つ以上のレベルのオンボードキャッシュを含むことができる。

システムメモリ５０４は、ランダムアクセスメモリ（ＲＡＭ）５２２やキャッシュメモリ５２４などの揮発性メモリとしてのコンピュータシステム読取可能媒体を含むことができる。コンピュータシステム５０１は、他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータシステム記憶媒体をさらに含むことができる。あくまでも例示として、ストレージシステム５２６は、「ハードドライブ」などの取り外し不可能な不揮発性の磁気媒体への読み書きのために設けることができる。図示は省略するが、取り外し可能な不揮発性磁気ディスク（例えば、フロッピーディスク）への読み書きのための磁気ディスクドライブ、および取り外し可能な不揮発性光学ディスク（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭや他の光学媒体など）への読み書きのための光学ディスクドライブを設けることができる。さらに、メモリ５０４は、フラッシュメモリ（例えば、フラッシュメモリスティックドライブまたはフラッシュドライブ）を含むことができる。メモリデバイスは、１つ以上のデータ媒体インタフェースによってメモリバス５０３に接続することができる。メモリ５０４は、各種の実施形態の機能を実行するように構成されたプログラムモジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

各々が少なくとも１セットのプログラムモジュール５３０を有する１つ以上のプログラム／ユーティリティ５２８は、メモリ５０４に記憶することができる。プログラム／ユーティリティ５２８は、ハイパーバイザー（仮想マシンモニタとも呼ばれる）、１つ以上のオペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータを含むことができる。オペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータの各々、またはこれらの何らかの組み合わせは、ネットワーク環境の実装形態を含むことができる。プログラム５２８もしくはプログラムモジュール５３０またはその両方は一般に、各種の実施形態の機能または方法を実行する。

メモリバス５０３は、図５では、ＣＰＵ５０２、メモリサブシステム５０４、およびＩ／Ｏバスインタフェース５１０間の直接的な通信経路を提供する単一のバス構造として図示されているが、メモリバス５０３は、いくつかの実施形態において、複数の異なるバスまたは通信経路を含むことができる。これらのバスまたは通信経路は、階層的なスター型もしくはウェブ型構成のポイントツーポイントリンク、複数の階層的バス、並列および冗長経路、またはいずれかの他の適切な種類の構成など、各種形態のうちのいずれかで配置することができる。さらに、Ｉ／Ｏバスインタフェース５１０およびＩ／Ｏバス５０８は、それぞれ単一のユニットとして図示されているが、コンピュータシステム５０１は、いくつかの実施形態において、複数のＩ／Ｏバスインタフェースユニット５１０、複数のＩ／Ｏバス５０８、またはその両方を含むことができる。さらに、複数のＩ／Ｏインタフェースユニットが図示されており、これらが、各種のＩ／Ｏデバイスにつながる各種の通信経路からＩ／Ｏバス５０８を分離しているが、他の実施形態において、Ｉ／Ｏデバイスの一部または全部が、１つ以上のシステムＩ／Ｏバスに直接接続されてもよい。

いくつかの実施形態において、コンピュータシステム５０１は、マルチユーザメインフレームコンピュータシステム、シングルユーザシステム、または、直接のユーザインタフェースをほとんどもしくは全く有さないが、他のコンピュータシステム（クライアント）から要求を受け取るサーバコンピュータもしくは類似の装置とすることができる。さらに、いくつかの実施形態において、コンピュータシステム５０１は、デスクトップコンピュータ、ポータブルコンピュータ、ラップトップもしくはノートブックコンピュータ、タブレットコンピュータ、ポケットコンピュータ、電話、スマートフォン、ネットワークスイッチもしくはルータ、または任意の他の適切な種類の電子デバイスとして実現することができる。

なお、図５は、一例としてのコンピュータシステム５０１における代表的な主要コンポーネントを図示することを意図している。いくつかの実施形態において、個々のコンポーネントは、図５に示したものよりも複雑であってもよいし、単純であってもよい。また、図５に示したもの以外のコンポーネントが存在してもよいし、図５に示したものに加えて他のコンポーネントが存在してもよい。そのようなコンポーネントの数、種類、および構成は異なってもよい。

一般的な状況において、ブロックチェーンシステムの透明性は、ユーザの操作が分散型台帳に格納され、したがって、その台帳にアクセスできる誰もが利用できることを必要とする。これは、機密のビジネス情報が明らかにされてしまうか、または個人のプライバシーを保護するために特別に設計された既存の規制の遵守しないことになってしまうかの懸念から、この技術の採用の妨げとなる可能性がある。

ユーザのプライバシー保護においては、２つの側面が重視される。すなわち、トランザクションの内容を難読化（obfuscate）することと、ユーザの起源（user origin）の識別情報を隠すことである。内容の難読化は検証可能な暗号化技術によって実現される。一方で、トランザクションの匿名性は、非許可型ブロックチェーンの場合はワンタイムキーによって、許可型ブロックチェーンの場合は匿名クレデンシャルによって実現される。

従来の匿名クレデンシャルは、１つの発行者を想定している。これらのソリューションによってユーザの識別情報を隠すことはできるが、発行者の識別情報は依然として明かされる。委譲可能な（delegatable）クレデンシャル方式は、ルートオーソリティ（root authority）が存在する限り、複数の発行者をサポートする。単一のルートオーソリティの場合、これらのソリューションは、複数の発行者が必ずしも同じルートオーソリティを使用するとは限らないブロックチェーン環境には不向きとなる。

いくつかの実施形態において、本開示は、単一のルートオーソリティが存在しない場合でもユーザの匿名性を確保する匿名クレデンシャル方式について説明する。

匿名クレデンシャルは、ユーザが、自身の識別情報を開示することなく自身についてのステートメントを証明することを可能にする。ユーザはまず、承認済み発行者（authorized issuer）から、ユーザの秘密鍵およびユーザの属性セットに関するクレデンシャル（すなわち署名）を取得する。属性を所有していることを証明するために、ユーザはゼロ知識証明（zero-knowledge proofs）を利用して、（ｉ）承認済み発行者からのクレデンシャルの知識、（ｉｉ）対応する秘密鍵の知識、および（ｉｉｉ）クレデンシャルが、開示された属性をコード化したものであることを証明する。従来の技術では、ユーザの識別情報は隠すことができるが、発行者の識別情報は明かされる。その回避策の１つが、委譲可能なクレデンシャルである。これらは、有効なクレデンシャルの所有を証明することでルートオーソリティの識別情報のみが明かされ、他は何も明かされないような方法で、ルートオーソリティが発行能力を委譲することを可能にする。しかしながら、ブロックチェーン環境においては、ルートオーソリティに依存することなく匿名性を実現できることが望ましい。いくつかの実施形態において、ユーザは、ブロックチェーンネットワーク内のノードであってもよいし、ノードを介してブロックチェーンネットワークにアクセスするユーザであってもよい。

いくつかの実施形態において、ユーザがユーザクレデンシャルに関するステートメントを効率的かつプライバシーが保護された方法で証明できるように、Pointcheval-Sanders署名などの秘密署名方式を用いて、ユーザクレデンシャルに署名してもよい。これらの署名は、署名とそのそれぞれのメッセージに関するゼロ知識証明に対応するように設計されている。さらに、ユーザが発行者の公開鍵を漏洩することを防ぐために、one-out-of-many証明方式を用いて、ユーザがコミットされた公開鍵に対して有効な署名を取得していることと、その公開鍵が承認済み発行者のうちの１つに対応していることとを示す。

いくつかの実施形態において、Pointcheval-SandersまたはGroth署名方式がゼロ知識証明に用いられる。いくつかの実施形態において、Pointcheval-SandersまたはGroth署名は、（ｉ）署名者が１回の試みでメッセージのベクトルに署名することを可能にし、かつ（ｉｉ）証明者が署名およびその対応するメッセージに関するゼロ知識ステートメントを証明することを可能にする、ランダム化可能（randomizable）な署名である。

いくつかの実施形態において、コミットメントのリスト（PedersenコミットメントまたはElGamal暗号など）が与えられると、one-out-of-many証明によって証明者は、プライバシーが保護された方法で、これらのコミットメントのうちの１つをオープンすることに関する知識を証明することができる。PedersenやElGamalのようなコミットメント方式では、コミッタ（または送信者）は、少なくとも２つの要素を有する何らかの公開メッセージ空間（public message space）から取った秘密メッセージｍを決定する（または秘密メッセージｍが与えられる）。同じコミッタ（または送信者）は次にランダムな秘密ｒを決定し、そのｍとｒからコミットメントｃ＝Ｃ（ｍ，ｒ）を生成する。コミットメントは、方式によって定義された何らかの公開方法（コミットメントアルゴリズムＣ）を適用して生成されることによりｃが公開され、後にｍとｒを明らかする。検証者（または受信者）にはｃ、ｍ、ｒが与えられ、実際にＣ（ｍ，ｒ）＝ｃであるかどうかを確認することができる。

いくつかの実施形態において、操作ｔｘ＝（ｊｏｉｎ，ｐｋ，σ）が、公開鍵ｐｋによる先行の参加操作（join operation）がないこと、およびσが管理者の公開鍵に対して有効な多重署名であることを確認することにより、認証される。

いくつかの実施形態において、ユーザの操作は、ペイロードと、ユーザの識別情報を開示しない署名とで構成される。例えば、操作がユーザに関するいかなる情報も漏らさないことを保証するために、ペイロードが強秘匿性の（semantically-secure）暗号化を用いて暗号化され、署名が匿名であれば十分である。いくつかの実施形態において、ペイロードは、操作のデータまたは操作に関連するデータである。

ある操作ｔｘに対する匿名署名を生成するために、ユーザは以下のように処理を進める。（１）発行者の公開鍵に対するコミットメントを計算する、（２）そのコミットメントが承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることをone-out-of-many証明によって証明する、（３）ゼロ知識において、コミットした公開鍵に基づく有効な署名の知識を証明する、（４）値に関する知識の証明（Schnorr証明など）を用いて証明を行う。いくつかの場合、知識の証明（proof of knowledge）とは、証明者が何らかの知識を、当該知識を有していることの証明として検証者が受け入れる程度に実証する、対話的な証明である。いくつかの場合、知識は計算によって証明される。例えば、所与の入力に対して証明者は、検証者が正しい出力として受け入れる（すなわち、検証済みのソースから以前に受け取っていた）出力を提供する。いくつかの実施形態において、証明者は知識そのものを提供するのではなく、その知識が生成に必要となるデータを提供する。

ある操作ｔｘに対する匿名署名を生成するために、ユーザは以下のように処理を進める。（１）発行者の公開鍵に対するコミットメントを計算する、（２）そのコミットメントが承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることをone-out-of-many証明によって証明する、（３）ゼロ知識において、コミットした公開鍵に基づく有効な署名の知識を証明する、（４）値に関する知識の証明（Schnorr証明など）を用いて証明を行う。いくつかの場合、知識の証明とは、証明者が何らかの知識を、当該知識を有していることの証明として検証者が受け入れる程度に実証する、対話的な証明である。いくつかの場合、知識は計算によって証明される。例えば、所与の入力に対して証明者は、検証者が正しい出力として受け入れる（すなわち、検証済みのソースから以前に受け取っていた）出力を提供する。いくつかの実施形態において、証明者は知識そのものを提供するのではなく、その知識が生成に必要となるデータを提供する。

いくつかの実施形態において、証明（たとえば、Schnorr証明）は、操作、これまでに生成されたゼロ知識証明、および公開鍵へのコミットメントを統合することにより、知識の署名（signature of knowledge）の役割を果たす。いくつかの実施形態において、Groth署名とone-out-of-many証明とを結合することにより、ルートオーソリティなしで、マルチ発行者匿名クレデンシャルを効率的に実装することができる。例えば、Groth署名は、署名と対応するメッセージとを含むステートメントに対する効率的なゼロ知識証明をサポートする任意のペアリングベースの（pairing-based）署名で置き換えることができる（たとえば、Pointcheval-Sanders署名など）。

図６は、許可型ブロックチェーンにおいてマルチ発行者匿名クレデンシャルを使用するための一例としての方法６００のフローチャートである。

図６において、まずステップ６０２にて、ユーザがタプルに関連付けられる。いくつかの実施形態において、タプルは、要素の有限順序リストである。ｎ－タプルは、ｎ個の要素のシーケンスである（ここで、ｎは非負整数である）。例えば、タプルは、式ｕｓｅｒ←（ｐｋ，ａ_１，．．．，ａ_ｎ）に基づいて関連付けられてもよい（ここで、ｐｋはユーザの公開鍵であり、ａ_ｉはユーザのｉ番目の属性である）。

いくつかの実施形態において、システムは、クレデンシャルが正しいエポック（correct epoch）において提示されたかどうかを判断してもよい。これは、ステップ６０７に示されている。例えば、一部のクレデンシャルは、単一のエポック中にのみ有効であってもよい。いくつかの実施形態において、ユーザのクレデンシャルが、クレデンシャルが有効であるエポック中に提示された場合、ステップ６０８にて、署名が受理される。いくつかの実施形態において、ユーザのクレデンシャルが、クレデンシャルが有効であるエポック中に提示されなかった場合、ステップ６１０にて、署名が拒否される。

本開示の実施形態は、メモリと、メモリと通信するプロセッサとを含むシステムを含み、プロセッサは、ユーザのトランザクションを匿名で（すなわち、トランザクションを生成するユーザの識別情報、またはユーザのクレデンシャルを生成した発行者の識別情報を明らかにすることなく）署名および検証することを含む動作を実行するように構成される。

本開示のさらなる実施形態は、プライバシーが保護される方法でユーザが自身についての主張を証明することを可能にする署名方式、および、（暗号化またはコミットメントを通じて）難読化された公開鍵が承認済み発行者のうちの１つの公開鍵であることをユーザが証明することを可能にするゼロ知識証明を含む方法を含む。このような署名の例は、Groth署名またはPointcheval Sanders署名であり、ゼロ知識証明の例は、one-out-of-many証明である。

本開示のさらなる実施形態は、プログラム命令が実装されたコンピュータ可読記憶媒体を含むコンピュータプログラム製品を含み、プログラム命令はプロセッサによって実行可能であり、プロセッサに、方法を実行させるためにプロセッサによって実行可能であり、プロセッサに、ブロックチェーン上の発行者登録、ユーザ登録、ユーザのトランザクション署名、およびユーザトランザクションを認証するブロックチェーンを含む方法を実行させる。

本明細書でより詳細に説明するように、本明細書に記載の方法の実施形態のいくつかにおける工程の一部または全部は、他の順序で行われてもよいし、まったく行われなくてもよいことが考えられる。さらに、複数の工程が同時に行われてもよいし、より大きなプロセスの内部部分として行われてもよい。

本発明は、任意の可能な技術詳細レベルで統合されたシステム、方法もしくはコンピュータプログラム製品またはそれらの組み合わせとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでもよい。

コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持し、記憶することができる有形の装置とすることができる。コンピュータ可読記憶媒体は、一例として、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置またはこれらの適切な組み合わせであってよい。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ（またはフラッシュメモリ）、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化された装置、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶媒体は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体として解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピュータ装置／処理装置へダウンロード可能である。あるいは、ネットワーク（例えばインターネット、ＬＡＮ、ＷＡＮもしくはワイヤレスネットワークまたはこれらの組み合わせ）を介して、外部コンピュータまたは外部記憶装置へダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータもしくはエッジサーバまたはこれらの組み合わせを備えることができる。各コンピュータ装置／処理装置内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、当該コンピュータ可読プログラム命令を、各々のコンピュータ装置／処理装置におけるコンピュータ可読記憶媒体に記憶するために転送する。

本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用構成データ、または、スモールトークやＣ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードもしくはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、スタンドアロン型ソフトウェアパッケージとして完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または、完全にリモートコンピュータもしくはサーバ上で実行可能である。後者の場合、リモートコンピュータは、ＬＡＮやＷＡＮを含む任意の種類のネットワークを介してユーザのコンピュータに接続してもよいし、外部コンピュータに（例えば、インターネットサービスプロバイダを使用してインターネットを介して）接続してもよい。いくつかの実施形態において、例えばプログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行する目的で当該電子回路をカスタマイズするために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。

本発明の実施形態は、本明細書において、本発明の実施形態に係る方法、装置（システム）、およびコンピュータプログラム製品のフローチャートもしくはブロック図またはその両方を参照して説明されている。フローチャートもしくはブロック図またはその両方における各ブロック、および、フローチャートもしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実行可能である。

上記のコンピュータ可読プログラム命令は、機械を生産するために、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサに提供することができる。これにより、かかるコンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行するための手段を創出する。上記のコンピュータ可読プログラム命令はさらに、コンピュータ、プログラマブルデータ処理装置もしくは他の装置またはこれらの組み合わせに対して特定の態様で機能するよう命令可能なコンピュータ可読記憶媒体に記憶することができる。これにより、命令が記憶された当該コンピュータ可読記憶媒体は、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作の態様を実行するための命令を含む製品を構成する。

また、コンピュータ可読プログラム命令を、コンピュータ、他のプログラマブル装置、または他の装置にロードし、一連の動作ステップを当該コンピュータ、他のプログラマブル装置、または他の装置上で実行させることにより、コンピュータ実行プロセスを生成してもよい。これにより、当該コンピュータ、他のプログラマブル装置、または他の装置上で実行される命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行する。

本開示の図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に係るシステム、方法およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実行するための１つ以上の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表すことができる。他の一部の実装形態において、ブロック内に示した機能は、各図に示す順序とは異なる順序で実行してもよい。例えば、連続して示される２つのブロックは、実際には、関係する機能に応じて、１つの工程として達成してもよいし、同時もしくは略同時に実行してもよいし、部分的もしくは全体的に時間的に重複した態様で実行してもよいし、場合により逆順で実行してもよい。なお、ブロック図もしくはフローチャートまたはその両方における各ブロック、および、ブロック図もしくはフローチャートまたはその両方における複数のブロックの組み合わせは、特定の機能もしくは動作を行う、または専用ハードウェアとコンピュータ命令との組み合わせを実行する、専用ハードウェアベースのシステムによって実行可能である。

本開示の種々の実施形態を例示として説明してきたが、網羅的であることや、これらの実施形態に限定することを意図したものではない。当業者には明らかなように、記載した各実施形態の範囲および主旨から逸脱することなく、多くの変更および変形が可能である。本明細書で用いられる用語は、各実施形態の原理、実際の用途、または市場で確認される技術に対する技術的な改善を最もよく説明するために、または、当業者が本明細書に開示する各実施形態を理解できるように選択されたものである。

本開示を特定の実施形態の観点から説明してきたが、その変更および変形が当業者にとっては明らかであることが考えられる。したがって、以下の特許請求の範囲は、本開示の真の主旨および範囲に属するすべてのこのような変更および変形を包含するものと解釈されることが意図される。

Claims (20)

1. メモリと、
   前記メモリと通信するプロセッサと、を含むシステムであって、
   前記プロセッサは、
   ユーザによって、当該ユーザの１つ以上の属性に基づく当該ユーザのクレデンシャルを発行者から取得することであって、当該発行者は、１つ以上の承認済み発行者から選択され、当該クレデンシャルは、当該１つ以上の属性に対する署名と秘密鍵とを含むことと、
   前記ユーザによって、ペイロードと第２の署名とからなる操作を生成することと、
   前記ユーザによって、前記発行者の公開鍵に対するコミットメントを計算することと、
   前記ユーザによってone-out-of-many証明を用いて、前記コミットメントが前記承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることを証明することと、
   前記ユーザによってゼロ知識証明を用いて、前記発行者の前記公開鍵に基づく前記署名および前記クレデンシャルに関する知識の証明を証明することと、
   前記ユーザによって、署名された前記秘密鍵および属性の値に関する知識の証明を用いて、証明を行うことと、
   を含むプロセスを実行するように構成されている、
   システム。
2. 前記署名は、Groth署名である、
   請求項１に記載のシステム。
3. 前記ペイロードは、強秘匿性の暗号化を用いて暗号化される、
   請求項１に記載のシステム。
4. 前記知識の証明は、Schnorr証明である、
   請求項１に記載のシステム。
5. Groth署名方式は、有効なクレデンシャルに関する知識のゼロ知識証明を容易にする、
   請求項１に記載のシステム。
6. 前記ユーザは、知識の証明を用いて、前記クレデンシャルが有効であることを証明する、
   請求項１に記載のシステム。
7. 前記クレデンシャルは、あるエポック中のみ有効である、
   請求項１に記載のシステム。
8. ユーザによって、当該ユーザの１つ以上の属性に基づく当該ユーザのクレデンシャルを発行者から取得することであって、当該発行者は、１つ以上の承認済み発行者から選択され、当該クレデンシャルは、当該１つ以上の属性に対する署名と秘密鍵とを含むことと、
   前記ユーザによって、ペイロードと第２の署名とからなる操作を生成することと、
   前記ユーザによって、前記発行者の公開鍵に対するコミットメントを計算することと、
   前記ユーザによってone-out-of-many証明を用いて、前記コミットメントが前記承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることを証明することと、
   前記ユーザによってゼロ知識証明を用いて、前記発行者の前記公開鍵に基づく前記署名および前記クレデンシャルに関する知識の証明を証明することと、
   前記ユーザによって、署名された前記秘密鍵および属性の値に関する知識の証明を用いて、証明を行うことと、
   を含む、方法。
9. 前記署名は、Groth署名である、
   請求項８に記載の方法。
10. 前記ペイロードは、強秘匿性の暗号化を用いて暗号化される、
    請求項８に記載の方法。
11. 前記知識の証明は、Schnorr証明である、
    請求項８に記載の方法。
12. Groth署名方式は、有効なクレデンシャルに関する知識のゼロ知識証明を容易にする、
    請求項８に記載の方法。
13. 前記ユーザは、知識の証明を用いて、前記クレデンシャルが有効であることを証明する、
    請求項８に記載の方法。
14. 前記クレデンシャルは、あるエポック中のみ有効である、
    請求項８に記載の方法。
15. プログラム命令が実装されたコンピュータ可読記憶媒体を含むコンピュータプログラム製品であって、当該プログラム命令はプロセッサによって実行可能であり、当該プロセッサに、
    ユーザによって、当該ユーザの１つ以上の属性に基づく当該ユーザのクレデンシャルを発行者から取得することであって、当該発行者は、１つ以上の承認済み発行者から選択され、当該クレデンシャルは、当該１つ以上の属性に対する署名と秘密鍵とを含むことと、
    前記ユーザによって、ペイロードと第２の署名とからなる操作を生成することと、
    前記ユーザによって、前記発行者の公開鍵に対するコミットメントを計算することと、
    前記ユーザによってone-out-of-many証明を用いて、前記コミットメントが前記承認済み発行者のうちの１つの公開鍵に対する有効なコミットメントであることを証明することと、
    前記ユーザによってゼロ知識証明を用いて、前記発行者の前記公開鍵に基づく前記署名および前記クレデンシャルに関する知識の証明を証明することと、
    前記ユーザによって、署名された前記秘密鍵および属性の値に関する知識の証明を用いて、証明を行うことと、
    を含む方法を実行させる、
    コンピュータプログラム製品。
16. 前記署名は、Groth署名である、
    請求項１５に記載のコンピュータプログラム製品。
17. 前記ペイロードは、強秘匿性の暗号化を用いて暗号化される、
    請求項１５に記載のコンピュータプログラム製品。
18. 前記知識の証明は、Schnorr証明である、
    請求項１５に記載のコンピュータプログラム製品。
19. Groth署名方式は、有効なクレデンシャルに関する知識のゼロ知識証明を容易にする、
    請求項１５に記載のコンピュータプログラム製品。
20. 前記ユーザは、知識の証明を用いて、前記クレデンシャルが有効であることを証明する、
    請求項１５に記載のコンピュータプログラム製品。

Images