JP2023551458A - Ｏｐｒｆを介したブロックチェーンネットワークにおける鍵再生 - 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. 前記変換する段階は、前記複数の鍵の中からの鍵及び前記秘密入力値を受信し、前記それぞれの鍵について鍵共有を出力する忘却疑似乱数関数（ＯＰＲＦ）を実行する段階を有する、請求項１９に記載のコンピュータプログラム製品。