JP2023508088A - ブロックチェーンオーバーレイネットワークへの鍵のマッピング - Google Patents

Abstract

ブロックチェーンのデータストレージトランザクションにオーバーレイされたオーバーレイネットワークを管理する方法であって、オーバーレイネットワークのデータコンテンツがデータストレージトランザクションのペイロードに格納され、オーバーレイ層リンクがデータストレージトランザクション間で定義される、方法。方法は、オーバーレイネットワークのグラフ構造を識別することを含み、ノードは、データストレージトランザクションのうちの異なる１つに対応し、エッジはリンクに対応する。各ノードは、ブロックチェーンへの子の書き込みを認可するために、子データストレージトランザクションの入力に署名するためのそれぞれの第１の鍵に関連付けられる。方法は、子鍵導出（ＣＫＤ）関数を使用して、オーバーレイネットワークと同じグラフ構造を有する第２の鍵の階層セットを決定することをさらに含み、ここで、第２の鍵は、データストレージトランザクションの入力に署名すること以外の追加の機能を可能にする。

Description

本開示は、ブロックチェーン上にオーバーレイされるメタネットなどのオーバーレイネットワークに関し、オーバーレイネットワークの異なるノードにマッピングするための鍵のセットを決定することに関する。

ブロックチェーンは、分散型データ構造の形態を指し、ブロックチェーンの複製コピーが、ピアツーピア（Ｐ２Ｐ）ネットワーク内の複数のノードの各々において維持される。ブロックチェーンは、データブロックのチェーンを含み、各ブロックは１つまたは複数のトランザクションを含む。各トランザクションは、１つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指し示し得る。トランザクションは、新しいブロックに含まれるためにネットワークにサブミットされ得る。新しいブロックは、「マイニング」として知られるプロセスによって作成され、このプロセスは、複数のマイニングノードがそれぞれ、「プルーフオブワーク」を実行しようと競うこと、すなわち、ブロックに含まれるのを待っている保留中のトランザクションのプールに基づいて暗号パズルを解くことを伴う。

従来、ブロックチェーンにおけるトランザクションは、デジタル資産、すなわち価値の蓄蔵として機能するデータを通信するために使用される。しかしながら、ブロックチェーンは、ブロックチェーンの上に追加の機能を重ねるために活用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションの出力における追加のユーザデータの格納を可能にし得る。最新のブロックチェーンでは、単一のトランザクション内に格納可能な最大データ容量が増えており、より複雑なデータを組み込むことが可能である。例えば、これを使用して、ブロックチェーンに電子文書を格納したり、さらにはオーディオまたはビデオデータを格納したりすることができる。

ネットワーク内の各ノードは、フォワード、マイニング、および格納という３つの役割のうちのいずれか１つ、２つ、またはすべてを担うことができる。フォワーディングノードは、ネットワークのノード全体にトランザクションを伝搬する。マイニングノードは、ブロックへのトランザクションのマイニングを実行する。ストレージノードは各々が、ブロックチェーンのマイニングされたブロックのそれら自体のコピーを格納する。ブロックチェーンにトランザクションを記録させるために、当事者は、伝搬されるべきネットワークのノードのうちの１つにトランザクションを送信する。トランザクションを受信するマイニングノードは、トランザクションを新しいブロックにマイニングしようと競い合い得る。各ノードは、同じノードプロトコルを尊重するように構成され、そのノードプロトコルには、トランザクションが有効であるための１つまたは複数の条件が含まれる。無効なトランザクションは、伝搬もブロックへのマイニングもされない。トランザクションが妥当性確認（validate）され、それによってブロックチェーン上に受け入れられたと仮定すると、トランザクション（任意のユーザデータを含む）は、不変の公開記録としてＰ２Ｐネットワーク内のノードの各々に格納されたままになる。

プルーフオブワークパズルを解くのに成功して最新のブロックを作成したマイナーは、典型的に、新しい額のデジタル資産を生成する「生成トランザクション」と呼ばれる新しいトランザクションで報酬が与えられる。ブロックをマイニングするためには大量の計算リソースを必要とし、二重支出の試みを含むブロックは他のノードによって受け入れられない可能性が高いので、プルーフオブワークは、それらのブロックに二重支出トランザクションを含めることによって、マイナーがシステムで不正を行わないためのインセンティブを与える。

「出力ベース」のモデル（ＵＴＸＯベースモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つまたは複数の入力と１つまたは複数の出力とを含む。任意の使用可能な出力は、デジタル資産の額を指定する要素を含み、これはＵＴＸＯ（「未使用トランザクション出力」）と呼ばれることもある。出力は、出力を償還するための条件を指定するロックスクリプトをさらに含み得る。各入力は、先行するトランザクションにおけるそのような出力へのポインタを含み、指し示された出力のロックスクリプトをロック解除するためのロック解除スクリプトをさらに含み得る。そのため、トランザクションのペアを考慮して、それらを第１のトランザクションおよび第２のトランザクション（または「ターゲット」トランザクション）と呼ぶ。第１のトランザクションは、デジタル資産の額を指定する少なくとも１つの出力を含み、出力をロック解除する１つまたは複数の条件を定義するロックスクリプトを含む。第２のターゲットトランザクションは、第１のトランザクションの出力へのポインタを含む少なくとも１つの入力と、第１のトランザクションの出力をロック解除するためのロック解除スクリプトとを含む。

そのようなモデルでは、第２のターゲットトランザクションがＰ２Ｐネットワークに送られて伝搬されブロックチェーンに記録されるとき、各ノードで適用される有効性の基準のうちの１つは、ロック解除スクリプトが第１のトランザクションのロックスクリプトで定義された１つまたは複数の条件のすべてを満たすことである。もう１つは、第１のトランザクションの出力が別の先の有効なトランザクションによってまだ償還されていないということである。これらの条件のいずれかにしたがってターゲットトランザクションが無効であることを発見したノードは、それを伝搬することも、ブロックチェーンに記録されるブロックへとマイニングするために含めることもしない。

トランザクションモデルの別のタイプは、アカウントベースのモデルである。この場合、各トランザクションは、一連の過去のトランザクションにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にマイナーによって格納され、絶えず更新される。

ブロックチェーンネットワークは、すでに、インターネットなどの基礎となるネットワーク上にオーバーレイされたオーバーレイネットワークの一種である。しかしながら、ブロックチェーン上にオーバーレイネットワークのさらなる層をオーバーレイすることも可能である。この例はメタネットとして知られている。メタネットの各ノードは、ブロックチェーン上の異なるトランザクションである。データコンテンツおよびメタネットメタデータは、ＯＰ＿ＲＥＴＵＲＮによるトランザクションの使用不可能な出力において、そのような各トランザクションのペイロードに格納される。データコンテンツは、例えば、テキスト、画像、ビデオまたはオーディオコンテンツなどを格納するためにメタネットが使用されている実際のユーザコンテンツであり、メタデータはメタネットノード間のリンクを定義する。メタネットノード間のリンクまたはエッジは、ブロックチェーン層における使用エッジ（spending edge）に必ずしも対応しない。すなわち、所与のメタネットトランザクションの入力が、ブロックチェーン層における別のファンディングトランザクション（funding transaction）の出力を指す場合、メタネット層におけるその同じトランザクションまたはメタネットノードの親は、必ずしもファンディングトランザクションと同じトランザクションではない。代わりに、メタネット層におけるリンクまたはエッジは、メタネットのデータコンテンツ間のリンクを定義する。

例示の目的で、この概要は、メタネット、ならびにメタネットノードおよびエッジの文脈で説明される。しかしながら、これは限定的なものではなく、より一般的には、ブロックチェーン上にオーバーレイされた任意のオーバーレイネットワークのノードおよびエッジには同じ原理を適用することができることが理解されよう。

メタネットネットワーク内の各ノードは、何らかの所与の機能のためにそれに関連付けられた鍵を有し得、例えば、鍵は、それぞれのメタネットノードへのデータコンテンツの書き込みを認可するために必要とされる。さらに、所与の機能（例えば、書き込み）について、異なる個々の鍵が、複数の異なるメタネットノードの各々に対して必要とされ得る。したがって、複数の異なるメタネットノードのそれぞれに１つずつ、複数の鍵のセットが必要となる。

さらに、メタネットネットワーク内の任意の所与のノードは、実際に、それに関連付けられたいくつかの異なる可能な機能のうちの１つまたは複数を有し得、ここで、そのような各機能は異なる鍵を必要とし得る。例えば、第１の鍵セットからの第１の鍵は、メタネットノードにデータコンテンツを書き込むために必要とされ得、第２の鍵セットの第２の鍵は、所与のメタネットノードのデータコンテンツを暗号化および／または解読するために必要とされ得る。したがって、複数のメタネットノードにわたって、鍵の第１のセットは、第１の関数に必要とされ得（メタネットノードごとに異なる個々の第１の鍵）、鍵の第２のセットは、第２の関数に必要とされ得る（メタネットノードごとに異なる個々の第２の鍵）。

鍵の所与のセットは、本質的に階層的であり得る。これは、セット内で、階層内のさらに下の鍵が、潜在的に複数の世代（親、祖父母など）にわたって、階層内のさらに上の親鍵からそれぞれ導出され、最終的にセット内のすべての鍵が導出される共通のシードまでずっと戻ることを意味する。したがって、鍵セットは、ツリー構造などのグラフ構造を有するものとして説明され得、ここで、ツリー内のノードは、セット内の異なる鍵に対応し、ノード間のエッジは、１つの鍵の別の鍵からの導出を表す。シードは、ツリーの「幹」または「根」のように考えられ得る。鍵は、子鍵導出（ＣＫＤ）関数と呼ばれる既知のタイプの決定論的鍵導出アルゴリズムを使用して互いに導出され得る。システム設計者が望む任意のグラフ構造にしたがってシステム設計者が鍵のセットを導出することを可能にする様々な形態のＣＫＤ関数が知られている。

メタネットネットワーク（または同様のもの）の様々な鍵をより効果的に割り振り、管理し、および／または通信する手段を提供することが望ましい。

特に、所与の機能のための鍵が互いに導出された所与の鍵セットの階層構造が、メタネットノードおよびメタネットの対応する部分のエッジ（またはブロックチェーン上にオーバーレイされた他のそのようなオーバーレイネットワーク）のグラフ（例えばツリー）構造に直接マッピングされる場合に望ましい。言い換えれば、ツリー構造内の所与の点におけるメタネットノード（または同様のもの）について、そのメタネットノードに対して所与の機能を実行するのに必要な鍵は、同じグラフ構造を有する対応する階層鍵セット内の同じ位置で見つかるであろう。次に、所与のメタネットノードに使用する鍵を決定するためには、関連のあるシードおよびグラフ構造内のノードの位置だけが分かればよい。

したがって、本明細書で開示される一態様によれば、ブロックチェーンのデータストレージトランザクションにオーバーレイされたオーバーレイネットワークを管理する方法であって、オーバーレイネットワークのデータコンテンツがデータストレージトランザクションのペイロードに格納され、オーバーレイ層リンクがデータストレージトランザクション間で定義される、方法が提供される。この方法は、第１のコンピュータ機器上で実行される第１のソフトウェアモジュールによって、オーバーレイネットワークのグラフ構造を識別することを含み、グラフ構造は複数のノードとノード間のエッジとを含み、ノードの各々はデータストレージトランザクションのうちの異なるそれぞれ１つに対応し、エッジの各々はリンクのうちの異なるそれぞれ１つに対応する。各ノードは、ブロックチェーンへの子の書き込みを認可するために、オーバーレイネットワークのグラフ構造における子データストレージトランザクションの入力に署名するためのそれぞれの第１の鍵に関連付けられる。第１の鍵は第１のシードから生成される。方法は、第１のソフトウェアモジュールによって、第２のシードに適用される子鍵導出（ＣＫＤ）関数を使用して、オーバーレイネットワークと同じグラフ構造を有する第２の鍵の階層セットを決定することをさらに含む。各第２の鍵は、グラフ構造においてそれぞれのデータストレージトランザクションと同じ位置にあるノードのうちの異なるそれぞれ１つに対応し、第２の鍵は、データストレージトランザクションの入力に署名するために使用されるのではなく、代わりに追加の機能（例えば、ファンディングまたは解読）を有効にするために提供される。

オーバーレイネットワーク（例えば、メタネットネットワーク）の列挙されたグラフ構造は、オーバーレイネットワークの一部または全部の構造であり得る。

各鍵は、公開鍵－秘密鍵ペアの秘密鍵、または公開鍵－秘密鍵ペアの公開鍵、またはその両方を含み得る。

以前は、メタネットにおいて、メタネットと同じ構造を有する鍵の階層を生成するという考えは、メタネットデータストレージトランザクションの入力に署名するためのセット鍵（構造鍵または書き込み鍵と呼ばれることもある）に対してのみ使用されていた。ファンディングまたは暗号化に使用される鍵のセットなど、任意の他のタイプの鍵の階層構造を生成するために使用されたことはこれまでなかった。本開示は、この考えが他のそのような鍵のセットに拡張され得ることを認識している。

例えば、これにより、所与のメタネットノードの鍵を、そのメタネットノードのグラフにおける位置を示すだけで、ソフトウェアの異なるモジュール（例えば、異なる当事者のウォレット、または所与のウォレット内の異なる分離されたモジュール）間で通信することができる。関連のある鍵セットのシードが与えられると、受信モジュールは、グラフ構造内の指示された位置にあるメタネットノードに必要な鍵を、そのノードの位置およびグラフのシードを知るだけで導出することができる。これにより、より少ないデータオーバーヘッドで鍵をシグナリングするより効率的な方法が提供される。シードがソフトウェアモジュールの選択されたグループ（例えば、送信側の当事者および受信側の当事者のみ、または選択された当事者のグループ）の間で秘密に保たれる場合、鍵自体がモジュール間でシグナリングされる必要がないので、これはより安全でもある。

したがって、実施形態では、方法は、第１のソフトウェアモジュールから、グラフ構造における位置のうちの１つの指示を第２のソフトウェアモジュールに通信し、したがって、第２のソフトウェアモジュールが、通信された位置と、第１のシードと、第１の鍵に使用されるＣＫＤ関数とに基づいて、その位置にあるノードのそれぞれの第１の鍵を決定することを可能にすることをさらに含み得る。

鍵の階層セットがツリー構造または他のそのようなグラフ構造を有するといわれる場合、当業者によく知られているように、これは、鍵の階層的に導出されたセットを意味する。すなわち、セット内の鍵は、構造の最上部のシードから開始して、階層的に互いに導出される。言い換えれば、グラフ構造内の各ノードは、それぞれの鍵に対応し、各エッジは、セット内の鍵のうちの１つの別の鍵からの導出に対応する。鍵の階層セットがオーバーレイネットワーク（例えばメタネット）と同じグラフ構造を有するといわれる場合、これは、鍵間の階層導出のグラフ構造が、オーバーレイネットワーク内のデータストレージトランザクション間のリンクの構造と同じであることを意味する。言い換えれば、グラフ構造内の各ノードは、セット内のそれぞれの鍵とオーバーレイネットワーク内のそれぞれのデータストレージトランザクションとの両方に対応し、グラフ構造内の各エッジは、鍵セット内のそれぞれの依存関係と、オーバーレイネットワーク内のデータストレージトランザクション間のそれぞれのリンクとに対応する。

実施形態では、同じグラフ構造を２つ以上の異なる鍵セットに使用することができ、各鍵セットは異なる機能のためのものである（例えば、１つはデータコンテンツを暗号化および／または解読するためのものであり、もう１つはデータコンテンツの書き込みを認可するためのものである）。

例えば、方法は、第１のソフトウェアモジュールによって、第１のシードに適用されるＣＫＤ関数を使用して、第１の鍵を、オーバーレイネットワークおよび第２の鍵セットと同じグラフ構造を有する階層鍵セットの鍵として決定することをさらに含み、ここで、各第１の鍵は、グラフ構造においてそれぞれのノードと同じ位置にあるノードのうちの異なるそれぞれ１つに対応する。

この場合、鍵セットは、異なるシードを使用して導出されるが、同じ階層グラフ構造を有する。第２の鍵のセットを決定するために使用されるＣＫＤ関数は、第１の鍵のセットに使用されるものと同じ形態の機能であってもよく（ただし、異なるシードに適用される）、またはＣＫＤ関数の異なる形態であってもよい。

好ましくは、第２のシードが第１のソフトウェアモジュールによって第２のソフトウェアモジュールに通信されることも、第２のソフトウェアモジュールに、任意の他の方法で第２のシードへのアクセスが与えられることもない。

したがって、第１のソフトウェアモジュールは、メタネットグラフ構造（または同様のもの）におけるノードの位置の指示を第２のソフトウェアモジュールにシグナリングすることができるが、第２のシードを漏らすことはない。例えば、これらのモジュールは、異なる当事者のコンピュータ機器上で実行されるソフトウェアであってもよく、または所与の当事者のコンピュータ機器内で実行される異なる分離されたモジュールであってもよい。いずれにしても、第２のソフトウェアモジュールは、第１のシードにアクセスできるが、第２のシードにはアクセスできない。例えば、第１のシードは、第１のモジュールによってノード位置と共に第２のモジュールに送られ得るか、または第１のノードは、第２のモジュールに事前に知られていてもよい（例えば、第１のモジュールまたは第３のモジュールによって事前に共有されている）。これにより、第２のソフトウェアモジュールは、位置とシードとに基づいて第１の機能の鍵を導出することができるが、第２のシードへのアクセスは有さないので、同じ位置にあるノードの第２の機能の鍵を導出することはできない。

これの例示的なアプリケーションとして、第１のソフトウェアモジュールは、顧客アリスのウォレットが含み得、第２のソフトウェアモジュールは、アリスよりも技術的専門知識を有するサービスプロバイダボブのソフトウェアが含み得る。アリスは、メタネットのノードとしてブロックチェーン上のトランザクションにアリスのデータを記録するためにボブに支払う。アリスは、ノードに書き込むための鍵をボブに通信する必要がある。しかしながら、アリスはコンテンツを暗号化することにもなり、暗号化鍵をボブに漏らすことを望まない。データをアップロードするために、ボブがデータを解読したりそれを平文で見たりできなければならない理由はない。

第２の鍵セットのオーバーレイネットワークグラフ構造への開示されたマッピングの有利な適用の別の代替的または追加的な例は、少なくとも第１のソフトウェアモジュールについて、その鍵導出における構造が保存され、その結果、何らかの他のエンティティ（すなわち、第３のソフトウェアモジュール）が、鍵および構造におけるトランザクションの位置（およびＣＫＤ）の知識のみを使用して、データストレージトランザクション（例えば、メタネットトランザクション）に関するすべての関連のある鍵を回復することができるようになることを保証することである。

本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、単なる例として添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す。 ブロックチェーン上にオーバーレイされたネットワークの概略図である。 メタネットなどのネットワークをブロックチェーン上にオーバーレイするための例示的なプロトコルを示す概略トランザクション図である。 メタネットノードのネットワークの少なくとも一部と同じツリー構造を有する鍵の階層セットを概略的に示す。 それぞれが鍵の階層セットを含む複数の鍵ドメインを導出するための方式を概略的に示す。 図６に示される方式の異なるパスタイプを概略的に示す。 第１のソフトウェアモジュールと第２のソフトウェアモジュールとの間の鍵の通信を示す概略ブロック図である。 第１のコンピュータ機器によって実行される方法の概略フローチャートである。 第２のコンピュータ機器によって実行される方法の概略的なフローチャートである。 ＨＤウォレットフレームワークにおいて親から子の秘密鍵および公開鍵を生成するための機構を概略的に示す。 拡張親公開鍵から子公開鍵を生成する機構を概略的に示す。

例示的なシステムの概要
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１を含む。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）オーバーレイネットワーク１０６を形成するように構成された複数のノード１０４を含む。

このサブセクションの目的のために、「ノード」は、ブロックチェーンネットワーク１０６のノード１０４を指す。後に、ノードはまた、メタネットのノード、またはブロックチェーン上にオーバーレイされた他のそのようなネットワークを指す。

ブロックチェーンネットワーク１０６の各ノード１０４は、ピアのコンピュータ機器を含み、ノード１０４のうちの異なるノードは異なるピアに属する。各ノード１０４は、１つまたは複数のプロセッサ、例えば１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を備える処理装置を含む。各ノードはまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を使用する１つまたは複数のメモリユニットを備え得る。

ブロックチェーン１５０は、データブロック１５１のチェーンを含み、ブロックチェーン１５０のそれぞれのコピーは、Ｐ２Ｐネットワーク１６０内の複数のノードの各々において維持される。チェーン内の各ブロック１５１は、１つまたは複数のトランザクション１５２を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、典型的には、全体を通して１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つの入力と少なくとも１つの出力とを含む。各出力は、出力が暗号的にロックされている（ロック解除され、それによって償還または使用されるためにはそのユーザの署名を必要とする）ユーザ１０３に属するデジタル資産の量を表す額を指定する。各入力は、先行するトランザクション１５２の出力を指し示し、それによってトランザクションをリンクする。

ノード１０４のうちの少なくともいくつかは、トランザクション１５２をフォワードし、それによって伝搬するフォワーディングノード１０４Ｆの役割を引き受ける。ノード１０４のうちの少なくともいくつかは、ブロック１５１をマイニングするマイナー１０４Ｍの役割を引き受ける。ノード１０４のうちの少なくともいくつかは、ストレージノード１０４Ｓ（「フルコピー」ノードと呼ばれることもある）の役割を引き受け、その各々が、同じブロックチェーン１５０のそれぞれのコピーをそれぞれのメモリに格納する。各マイナーノード１０４Ｍはまた、ブロック１５１にマイニングされるのを待っているトランザクション１５２のプール１５４を維持する。所与のノード１０４は、フォワーディングノード１０４、マイナー１０４Ｍ、ストレージノード１０４Ｓ、またはこれらのうちの２つもしくはすべての任意の組合せであり得る。

所与の現在のトランザクション１５２ｊにおいて、入力（または各入力）は、トランザクションのシーケンスにおける先行するトランザクション１５２ｉの出力を参照するポインタを含み、この出力が現在のトランザクション１５２ｊにおいて償還または「使用」されるべきであることを指定する。一般に、先行するトランザクションは、プール１５４または任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２ｉは、現在のトランザクションが有効となるために存在および妥当性確認される必要があるが、先行するトランザクション１５２ｉは、現在のトランザクション１５２ｊが作成されるときまたはネットワーク１０６に送信されるときに必ずしも存在する必要はない。したがって、本明細書における「先行する（preceding）」は、ポインタによってリンクされた論理シーケンスにおける先行するものを指し、必ずしも時間シーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション１５２ｉ、１５２ｊが順不同に作成または送信されることを必ずしも除外するものではない（オーファントランザクションに関する以下の説明を参照）。先行するトランザクション１５２ｉは、先のトランザクション（antecedent transaction）または先行したトランザクション（predecessor transaction）とも呼ばれる。

現在のトランザクション１５２ｊの入力はまた、先行するトランザクション１５２ｉの出力がロックされるユーザ１０３ａの署名を含む。次に、現在のトランザクション１５２ｊの出力は、新しいユーザ１０３ｂに暗号的にロックされ得る。したがって、現在のトランザクション１５２ｊは、先行するトランザクション１５２ｉの入力において定義された額を、現在のトランザクション１５２ｊの出力において定義されたように、新しいユーザ１０３ｂに転送することができる。場合によっては、トランザクション１５２は、複数のユーザ（残り（change）を与えるためにそのうちの１人が元のユーザ１０３ａであり得る）間で入力額を分割するために複数の出力を有し得る。場合によっては、トランザクションはまた、１つまたは複数の先行するトランザクションの複数の出力からの額をまとめ、現在のトランザクションの１つまたは複数の出力に再分配するために複数の入力を有することができる。

上記は、「出力ベース」トランザクションプロトコルと称され得、未使用トランザクション出力（ＵＴＸＯ）タイププロトコルと称されることもある（ここでは出力はＵＴＸＯと称される）。ユーザの総残高は、ブロックチェーンに格納された任意の１つの数字で定義されるのではなく、代わりに、ユーザは、ブロックチェーン１５１内の多くの異なるトランザクション１５２全体に散在しているそのユーザのすべてのＵＴＸＯの値を照合するための特別な「ウォレット」アプリケーション１０５を必要とする。

トランザクションプロトコルの代替的なタイプは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと称され得る。アカウントベースの場合、各トランザクションは、一連の過去のトランザクションにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別にマイナーによって格納され、絶えず更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー（「ポジション」とも呼ばれる）を使用して順序付けられる。この値は、送信者によってその暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。加えて、トランザクションにおける任意選択のデータフィールドも署名することができる。このデータフィールドは、例えば、前のトランザクションＩＤがデータフィールドに含まれている場合、前のトランザクションを指し示し得る。

いずれかのタイプのトランザクションプロトコルを用いて、ユーザ１０３が新しいトランザクション１５２ｊを成立させることを望む場合、ユーザは新しいトランザクションをユーザのコンピュータ端末１０２からＰ２Ｐネットワーク１０６のノード１０４（これは、今日では典型的にはサーバまたはデータセンタであるが、原理的には他のユーザ端末であってもよい）のうちの１つに送信する。このノード１０４は、ノード１０４の各々において適用されるノードプロトコルにしたがってトランザクションが有効であるかどうかをチェックする。ノードプロトコルの詳細は、当該ブロックチェーン１５０において使用されているトランザクションプロトコルのタイプに対応し、全体としてトランザクションモデルを形成する。ノードプロトコルは、典型的には、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序付けられたシーケンス内で前のトランザクション１５２ｉに依存する予想される署名と一致することをチェックするようにノード１０４に求める。出力ベースの場合、これは、新しいトランザクション１５２ｊの入力に含まれるユーザの暗号署名が、新しいトランザクションが使用する先行するトランザクション１５２ｉの出力において定義される条件と一致することをチェックすることを含み得、この条件は、典型的には、新しいトランザクション１５２ｊの入力における暗号署名が、新しいトランザクションの入力が指し示す前のトランザクション１５２ｉの出力をロック解除することをチェックすることを少なくとも含む。いくつかのトランザクションプロトコルでは、条件は、入力および／または出力に含まれるカスタムスクリプトによって少なくとも部分的に定義され得る。代替的に、単にノードプロトコルのみによって固定されてもよく、またはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合、現在のノードは、それをＰ２Ｐネットワーク１０６内のノード１０４のうちの１つまたは複数の他のノードにフォワードする。これらのノード１０４のうちの少なくともいくつかは、フォワーディングノード１０４Ｆとしても機能し、同じノードプロトコルにしたがって同じテストを適用し、そして、新しいトランザクション１５２ｊを１つまたは複数のさらなるノード１０４にフォワードし、以下同様である。このようにして、新しいトランザクションはノード１０４のネットワーク全体に伝搬される。

出力ベースのモデルでは、所与の出力（例えば、ＵＴＸＯ）が使用されたかどうかの定義は、それがノードプロトコルにしたがって別の前方のトランザクション１５２ｊの入力によって有効に償還されたかどうかかである。トランザクションが有効であるための別の条件は、それが使用または償還しようとする先行するトランザクション１５２ｉの出力が、別の有効なトランザクションによってまだ使用／償還されていないことである。同様に、有効でない場合、トランザクション１５２ｊは、ブロックチェーンに伝搬も記録もされない。これは、使用者が同じトランザクションの出力を複数回使用しようとする二重支出を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重支出を防止する。ここでも、トランザクション順序が定義されているので、アカウント残高は常に単一の定義された状態にある。

妥当性確認に加えて、ノード１０４Ｍのうちの少なくともいくつかはまた、「プルーフオブワーク」に支えられるマイニングとして知られるプロセスにおいてトランザクションのブロックを最初に作成しようと競い合う。マイニングノード１０４Ｍにおいて、ブロック内にまだ現れていない有効なトランザクションのプールに新しいトランザクションが追加される。次いで、マイナーは、暗号パズルを解くことを試みることによって、トランザクションのプール１５４からトランザクション１５２の新しい有効ブロック１５１を組み立てようと競い合う。典型的には、これは、ノンスがトランザクションのプール１５４と連結されハッシュされたときにハッシュの出力が所定の条件を満たすような「ノンス」値を探索することを含む。例えば、所定の条件とは、ハッシュの出力が特定の所定の数の先行ゼロを有することであり得る。ハッシュ関数の特性は、その入力に対して予測不可能な出力を持つことである。したがって、この探索は、総当たりでしか実行することができないので、パズルを解こうとしている各ノード１０４Ｍでかなりの量の処理リソースを消費する。

最初にパズルを解いたマイナーノード１０４Ｍは、これをネットワーク１０６に公表し、後にネットワーク内の他のノード１０４によって容易にチェックすることができるその解を証明として提供する（ハッシュに対する解が与えられると、ハッシュの出力が条件を満たすことをチェックすることは簡単である）。勝者がパズルを解いたトランザクションのプール１５４は、次いで、ストレージノード１０４Ｓとして機能するノード１０４のうちの少なくともいくつかによって、そのような各ノードにおいて勝者が公表した解をチェックしたことに基づいて、ブロックチェーン１５０内に新しいブロック１５１として記録されるようになる。ブロックポインタ１５５はまた、チェーン内の前に作成されたブロック１５１ｎ－１を指し示す新しいブロック１５１ｎに割り当てられる。プルーフオブワークは、新たなブロック１５１を作成するのに多大な労力を要するので、二重支出のリスクを低減するのに役立ち、二重支出を含むブロックは他のノード１０４によって拒絶される可能性が高いので、マイニングノード１０４Ｍは、二重支出がそれらのブロックに含まれないようにインセンティブが与えられる。ブロック１５１は、一旦作成されると、同じプロトコルにしたがってＰ２Ｐネットワーク１０６内の格納ノード１０４Ｓの各々で認識および維持されるので、修正することができない。ブロックポインタ１５５はまた、ブロック１５１にシーケンシャル順序を付与する。トランザクション１５２は、Ｐ２Ｐネットワーク１０６内の各ストレージノード１０４Ｓにおいて順序付けられたブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。

任意の所与の時間にパズルを解こうと競い合う異なるマイナー１０４Ｍは、それらがいつ解を探索し始めたかに応じて、任意の所与の時間におけるマイニングされていないトランザクションプール１５４の異なるスナップショットに基づいてそうしている可能性があることに留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション１５２が次の新しいブロック１５１ｎに含まれるかを定義し、マイニングされていないトランザクションの現在のプール１５４が更新される。次いで、マイナー１０４Ｍは、新しく定義された未処理プール１５４からブロックを作成しようと競い合い続け、以下同様である。２人のマイナー１０４Ｍが互いに非常に短い時間内にパズルを解いて、ブロックチェーンの相反する見解が伝搬される場合に発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどちらのプロングが最も長く成長しても、最終的なブロックチェーン１５０となる。

ほとんどのブロックチェーンでは、勝利マイナー１０４Ｍには、（あるユーザから別のユーザにある額のデジタル資産を転送する通常のトランザクションとは対照的に）突如新しい量のデジタル資産を作成する特別なタイプの新しいトランザクションで自動的に報酬が与えられる。したがって、勝者ノードは、ある量のデジタル資産を「マイニング」したといわれる。この特別なタイプのトランザクションは、「生成」トランザクションと称されることがある。それは自動的に新しいブロック１５１ｎの一部を形成する。この報酬は、マイナー１０４Ｍがプルーフオブワーク競争に参加するためのインセンティブを与える。多くの場合、通常の（非生成）トランザクション１５２はまた、そのトランザクションが含まれたブロック１５１ｎを作成した勝利マイナー１０４Ｍにさらに報酬を与えるために、その出力の１つにおいて追加のトランザクション手数料を指定する。

マイニングに関与する計算リソースに起因して、典型的には、マイナーノード１０４Ｍの少なくとも各々は、１つまたは複数の物理サーバユニットを含むサーバの形態をとるか、またはデータセンタ全体の形態をとる。各フォワーディングノード１０４Ｍおよび／またはストレージノード１０４Ｓもまた、サーバまたはデータセンタの形態をとり得る。しかしながら、原則として、任意の所与のノード１０４は、一緒にネットワーク化されたユーザ端末またはユーザ端末のグループの形態をとることができる。

各ノード１０４のメモリは、そのそれぞれの１つまたは複数の役割を実行し、ノードプロトコルにしたがってトランザクション１５２を処理するために、ノード１０４の処理装置上で実行ように構成されたソフトウェアを記憶する。本明細書においてノード１０４に帰する任意のアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。ノードソフトウェアは、アプリケーション層、またはオペレーティングシステム層もしくはプロトコル層などの下位層、またはこれらの任意の組合せにおける１つまたは複数のアプリケーションにおいて実装され得る。また、本明細書で使用される「ブロックチェーン」という用語は、一般に、この種類の技術を指す総称であり、任意の特定の専有のブロックチェーン、プロトコルまたはサービスに限定されない。

消費ユーザの役割を果たす複数の当事者１０３の各々のコンピュータ機器１０２もネットワーク１０１に接続されている。これらは、トランザクションにおいて支払人および受取人として機能するが、他の当事者に代わってトランザクションのマイニングまたは伝搬に必ずしも参加するわけではない。それらは、マイニングプロトコルを必ずしも実行するわけではない。２つの当事者１０３およびそれらのそれぞれの機器１０２、すなわち、第１の当事者１０３ａおよびそのそれぞれのコンピュータ機器１０２ａ、ならびに第２の当事者１０３ｂおよびそのそれぞれのコンピュータ機器１０２ｂは、例示の目的で示されている。はるかに多くのそのような当事者１０３およびそれらのそれぞれのコンピュータ機器１０２が存在し、システムに参加し得るが、便宜上、それらは図示されていないことが理解されよう。各当事者１０３は、個人または組織であり得る。純粋に例示として、第１の当事者１０３ａは、本明細書ではアリスと称され、第２の当事者１０３ｂはボブと称されるが、これは限定的なものではなく、本明細書におけるアリスまたはボブへのいかなる参照も、それぞれ「第１の当事者」および「第２の当事者」と置き換えられ得ることが理解されよう。

各当事者１０３のコンピュータ機器１０２は、１つまたは複数のプロセッサ、例えば、１つまたは複数のＣＰＵ、ＧＰＵ、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および／またはＦＰＧＡを含むそれぞれの処理装置を含む。各当事者１０３のコンピュータ機器１０２は、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。このメモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を使用する１つまたは複数のメモリユニットを備え得る。各当事者１０３のコンピュータ機器１０２上のメモリは、処理装置上で実行するように構成された少なくとも１つのクライアントアプリケーション１０５のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の当事者１０３に帰する任意のアクションは、それぞれのコンピュータ機器１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各当事者１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを備える。所与の当事者１０３のコンピュータ機器１０２はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの１つまたは複数の他のネットワーク化されたリソースを備え得る。

クライアントアプリケーション１０５は、最初に、適切な１つまたは複数のコンピュータ可読記憶媒体上で任意の所与の当事者１０３のコンピュータ機器１０２に提供され得、例えば、サーバからダウンロードされ得るか、またはリムーバブルＳＳＤ、フラッシュメモリキー、リムーバブルＥＥＰＲＯＭ、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、ＣＤもしくはＤＶＤ ＲＯＭなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブル記憶デバイス上で提供され得る。

クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これは２つの主要な機能を有する。これらのうちの１つは、それぞれのユーザ当事者１０３が、ノード１０４のネットワーク全体に伝搬され、それによってブロックチェーン１５０に含まれることとなるトランザクション１５２を作成し、署名し、送信することを可能にすることである。もう１つは、それぞれの当事者に、その当事者が現在所有しているデジタル資産の額を報告することである。出力ベースのシステムでは、この第２の機能は、当該当事者に属するブロックチェーン１５０全体に散在している様々なトランザクション１５２の出力において定義された額を照合することを含む。

様々なクライアント機能が、所与のクライアントアプリケーション１０５に統合されるものとして説明され得るが、必ずしもこれに限定されず、代わりに、本明細書で説明される任意のクライアント機能は、代わりに、例えば、ＡＰＩを介してインターフェースする、または一方が他方へのプラグインである２つ以上の別個のアプリケーション一式において実装され得ることに留意されたい。より一般的には、クライアント機能は、アプリケーション層もしくはオペレーティングシステムなどの下位層、またはこれらの任意の組合せにおいて実装され得る。以下では、クライアントアプリケーション１０５に関して説明するが、これに限定されないことが理解されよう。

各コンピュータ機器１０２上のクライアントアプリケーションまたはソフトウェア１０５のインスタンスは、Ｐ２Ｐネットワーク１０６のフォワーディングノード１０４Ｆのうちの少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能はトランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５はまた、それぞれの当事者１０３が受信者である任意のトランザクションについてブロックチェーン１５０にクエリを行うために、ストレージノード１０４のうちの１つ、いくつか、またはすべてにコンタクトすることができる（または、実施形態では、ブロックチェーン１５０は、部分的にその公開可視性を通じてトランザクションにおける信頼を提供する公開施設であるので、実際にブロックチェーン１５０における他の当事者のトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルにしたがってトランザクション１５２を定式化し、送信するように構成される。各ノード１０４は、ノードプロトコルにしたがってトランザクション１５２を妥当性確認するように構成されたソフトウェアを実行し、フォワーディングノード１０４Ｆの場合には、トランザクション１５２をネットワーク１０６全体に伝搬させるためにそれらをフォワードするように構成される。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと共に進行し、一緒に所与のトランザクションモデルを実装する。ブロックチェーン１５０内のすべてのトランザクション１５２に対して同じトランザクションプロトコルが使用される（ただし、トランザクションプロトコルは、その中のトランザクションの異なるサブタイプを可能にし得る）。ネットワーク１０６内のすべてのノード１０４によって同じノードプロトコルが使用される（ただし、これは、トランザクションの異なるサブタイプを、そのサブタイプに対して定義された規則にしたがって異なって処理し、また、異なるノードが異なる役割を担い、したがってプロトコルの異なる対応する態様を実装することができる）。

述べたように、ブロックチェーン１５０は、ブロック１５１のチェーンを含み、各ブロック１５１は、前述したようなプルーフオブワークプロセスによって作成された１つまたは複数のトランザクション１５２のセットを含む。各ブロック１５１はまた、ブロック１５１へのシーケンシャル順序を定義するために、チェーン内の前に作成されたブロック１５１を指し示すブロックポインタ１５５を含む。ブロックチェーン１５０は、プルーフオブワークプロセスによって新しいブロックに含まれるのを待っている有効なトランザクションのプール１５４も含む。各トランザクション１５２（生成トランザクション以外）は、トランザクションのシーケンスへの順序を定義するように、前のトランザクションへ戻るポインタを含む（注意：トランザクション１５２のシーケンスは分岐することが可能である）。ブロック１５１のチェーンは、チェーン内の最初のブロックであった発生ブロック（Ｇｂ）１５３までずっと戻る。チェーン１５０内の早期にある１つまたは複数の元のトランザクション１５２は、先行するトランザクションではなく発生ブロック１５３を指し示していた。

所与の当事者１０３、例えばアリスが、ブロックチェーン１５０に含まれるべき新しいトランザクション１５２ｊを送信することを望むとき、アリスは、関連のあるトランザクションプロトコルにしたがって（アリスのクライアントアプリケーション１０５内のウォレット機能を使用して）新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション１０５から、アリスが接続されている１つまたは複数のフォワーディングノード１０４Ｆのうちの１つにトランザクション１５２を送信する。例えば、これは、アリスのコンピュータ１０２に最も近いまたは最良に接続されたフォワーディングノード１０４Ｆであり得る。任意の所与のノード１０４が新しいトランザクション１５２ｊを受信すると、それはノードプロトコルおよびそのそれぞれの役割にしたがってそれを処理する。これは、新たに受信されたトランザクション１５２ｊが「有効」であるための特定の条件を満たすか否かを最初にチェックすることを含み、その例については、以下でより詳細に説明する。いくつかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替的に、条件は、単にノードプロトコルの組込み特徴であってもよく、またはスクリプトとノードプロトコルとの組合せによって定義されてもよい。

新たに受信されたトランザクション１５２ｊが有効であると見なされるためのテストにパスすることを条件として（すなわち、それが「妥当性確認される」ことを条件として）、トランザクション１５２ｊを受信する任意のストレージノード１０４Ｓは、そのノード１０４Ｓにおいて維持されるブロックチェーン１５０のコピー内のプール１５４に新たな妥当性確認済みトランザクション１５２を追加する。さらに、トランザクション１５２ｊを受信する任意のフォワーディングノード１０４Ｆは、妥当性確認済みトランザクション１５２をＰ２Ｐネットワーク１０６内の１つまたは複数の他のノード１０４へと前方に伝搬する。各フォワーディングノード１０４Ｆは同じプロトコルを適用するので、トランザクション１５２ｊが有効であると仮定すると、これは、それがすぐにＰ２Ｐネットワーク１０６全体にわたって伝搬されることを意味する。

１つまたは複数のストレージノード１０４において維持されるブロックチェーン１５０のコピー内のプール１５４に認められると、マイナーノード１０４Ｍは、新しいトランザクション１５２を含むプール１５４の最新バージョンに対してプルーフオブワークパズルを解こうと競い始める（他のマイナー１０４Ｍは、プール１５４の古いビューに基づいてパズルを解こうと試みている可能性があるが、誰が最初に到達しても、次の新しいブロック１５１がどこで終わり新しいプール１５４がどこで開始するかを定義することとなり、最終的には、誰かが、アリスのトランザクション１５２ｊを含むプール１５４の一部についてパズルを解く）。新しいトランザクション１５２ｊを含むプール１５４に対してプルーフオブワークが行われると、それは不変的にブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、前のトランザクションへ戻るポインタを含むので、トランザクションの順序も不変的に記録される。

異なるノード１０４は、まず、所与のトランザクションの異なるインスタンスを受信し得るので、１つのインスタンスがブロック１５０にマイニングされる前に、どのインスタンスが「有効」であるかの矛盾する見解を有する可能性があり、この時点で、すべてのノード１０４は、マイニングされたインスタンスが唯一の有効なインスタンスであることに同意する。ノード１０４が１つのインスタンスを有効として受け入れ、次いで第２のインスタンスがブロックチェーン１５０に記録されていることを発見した場合、そのノード１０４はこれを受け入れなければならず、最初に受け入れたマイニングされていないインスタンスを破棄する（すなわち、無効として扱う）。

ＵＴＸＯベースのモデル
図２は、例示的なトランザクションプロトコルを示す。これは、ＵＴＸＯベースのプロトコルの一例である。トランザクション１５２（「Ｔｘ」と略記される）は、ブロックチェーン１５０の基本的なデータ構造である（各ブロック１５１は１つまたは複数のトランザクション１５２を含む）。以下では、出力ベースまたは「ＵＴＸＯ」ベースのプロトコルを参照して説明する。しかしながら、これはすべての可能な実施形態に限定されない。

ＵＴＸＯベースのモデルでは、各トランザクション（「Ｔｘ」）１５２は、１つまたは複数の入力２０２および１つまたは複数の出力２０３を含むデータ構造を含む。各出力２０３は、未使用トランザクション出力（ＵＴＸＯ）を含み得、これは、（ＵＴＸＯがまだ償還されていない場合）別の新しいトランザクションの入力２０２のソースとして使用され得る。ＵＴＸＯは、デジタル資産（価値の蓄蔵）の額を指定する。それはまた、他の情報の中でも、元となるトランザクションのトランザクションＩＤを含み得る。トランザクションデータ構造は、入力フィールド（複数可）２０２および出力フィールド（複数可）２０３のサイズを示すインジケータを含み得るヘッダ２０１も含み得る。ヘッダ２０１はまた、トランザクションのＩＤを含み得る。実施形態では、トランザクションＩＤは、（トランザクションＩＤ自体を除く）トランザクションデータのハッシュであり、マイナー１０４Ｍにサブミットされる生のトランザクション１５２のヘッダ２０１に格納される。

アリス１０３ａが、当該デジタル資産の額をボブ１０３ｂに転送するトランザクション１５２ｊを作成することを望むとする。図２では、アリスの新しいトランザクション１５２ｊは「Ｔｘ_１」とラベル付けされている。これは、シーケンス内の先行するトランザクション１５２ｉの出力２０３においてアリスにロックされたデジタル資産の額を取り、これのうちの少なくとも一部をボブに転送する。先行するトランザクション１５２ｉは、図２では「Ｔｘ_０」とラベル付けされている。Ｔｘ_０およびＴｘ_１は、単なる任意のラベルである。それらは、Ｔｘ_０がブロックチェーン１５１内の最初のトランザクションであることも、Ｔｘ_１がプール１５４内のすぐ次のトランザクションであることも必ずしも意味するものではない。Ｔｘ_１は、アリスにロックされた未使用の出力２０３を依然として有する任意の先行する（すなわち先の）トランザクションを指し示すことができる。

先行するトランザクションＴｘ_０は、アリスが新しいトランザクションＴｘ_１を作成した時点では、または少なくともアリスがそれをネットワーク１０６に送信する時点までには、すでに妥当性確認されブロックチェーン１５０に含まれている可能性がある。それは、その時点でブロック１５１のうちの１つにすでに含まれていてもよいし、プール１５４で依然として待機していてもよく、この場合、すぐに新しいブロック１５１に含まれることになる。代替的に、Ｔｘ_０およびＴｘ_１を作成してネットワーク１０２に一緒に送信することができるか、またはノードプロトコルが「オーファン」トランザクションのバッファリングを可能にする場合には、Ｔｘ_０をＴｘ_１の後に送信することさえもできる。トランザクションのシーケンスの文脈において本明細書で使用される「先行する」および「後続の」という用語は、トランザクション内で指定されているトランザクションポインタ（どのトランザクションがどの他のトランザクションを指し示すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、同様に、「先行するもの」および「後続するもの」、または「先の」および「後の」、「親」および「子」などと置き換えられ得る。これは、それらの作成、ネットワーク１０６への送信、または任意の所与のノード１０４への到着の順序を必ずしも意味するものではない。それにもかかわらず、先行するトランザクション（先のトランザクションまたは「親」）を指し示す後続するトランザクション（後のトランザクションまたは「子」）は、親トランザクションが妥当性確認されるまでおよび妥当性確認されない限り、妥当性確認されない。その親より前にノード１０４に到着する子は、オーファンと見なされる。それは、ノードプロトコルおよび／またはマイナー挙動に応じて、親を待つために特定の時間バッファされるかまたは破棄され得る。

先行するトランザクションＴｘ_０の１つまたは複数の出力２０３のうちの１つは、本明細書ではＵＴＸＯ_０とラベル付けされた特定のＵＴＸＯを含む。各ＵＴＸＯは、ＵＴＸＯによって表されるデジタル資産の額を指定する値と、ロックスクリプトとを含み、ロックスクリプトは、後続のトランザクションが妥当性確認され、したがってＵＴＸＯが正常に償還されるために、後続のトランザクションの入力２０２内のロック解除スクリプトが満たさなければならない条件を定義する。典型的には、ロックスクリプトは、その額を特定の当事者（それが含まれるトランザクションの受益者）にロックする。すなわち、ロックスクリプトは、典型的には、後続のトランザクションの入力内のロック解除スクリプトに、先行するトランザクションがロックされる当事者の暗号署名が含まれるという条件を含むロック解除条件を定義する。

ロックスクリプト（通称scriptPubKey）は、ノードプロトコルによって認識されるドメイン固有言語で書かれたコードの一部分である。そのような言語の特定の例は、「スクリプト」（大文字Ｓ）と呼ばれる。ロックスクリプトは、トランザクション出力２０３を使用するためにどの情報が必要とされるか、例えばアリスの署名の要件を指定する。ロック解除スクリプトはトランザクションの出力に現れる。ロック解除スクリプト（通称scriptSig）は、ロックスクリプト基準を満たすのに必要な情報を提供するドメイン固有言語で書かれたコードの一部分である。例えば、ボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力２０２に現れる。

つまり、図示の例では、Ｔｘ_０の出力２０３内のＵＴＸＯ_０は、ＵＴＸＯ_０が償還されるために（厳密には、ＵＴＸＯ_０を償還しようとする後続のトランザクションが有効となるために）アリスの署名Ｓｉｇ Ｐ_Ａを必要とするロックスクリプト[Checksig P_A]を含む。[Checksig P_A]は、アリスの公開鍵－秘密鍵ペアからの公開鍵Ｐ_Ａを含む。Ｔｘ_１の入力２０２は、（例えば、実施形態ではトランザクションＴｘ_０全体のハッシュであるそのトランザクションＩＤ、ＴｘＩＤ_０によって）Ｔｘ_１を指し示すポインタを含む。Ｔｘ_１の入力２０２は、Ｔｘ_０の任意の他の可能な出力の中から、ＵＴＸＯ_０を識別するために、Ｔｘ_０内のそれを識別するインデックスを含む。Ｔｘ_１の入力２０２は、アリスが鍵ペアからのアリスの秘密鍵をデータの所定の部分（暗号では「メッセージ」と呼ばれることもある）に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト＜Ｓｉｇ Ｐ_Ａ＞をさらに含む。有効な署名を提供するためにどのデータ（または「メッセージ」）がアリスによって署名される必要があるかは、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。

新しいトランザクションＴｘ_１がノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトで定義されている条件（この条件は１つまたは複数の基準を含み得る）を満たすかどうかをチェックすることを含む。実施形態では、これは２つのスクリプトを連結することを含む。
<Sig P_A> <P_A> || [Checksig P_A]
ここで、「｜｜」は連結を表し、「＜…＞」はデータをスタックに置くことを意味し、「［…］」はロック解除スクリプト（この例ではスタックベースの言語）で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されるとき、スクリプトは、Ｔｘ_０の出力内のロックスクリプトに含まれるようなアリスの公開鍵Ｐ_Ａを使用して、Ｔｘ_１の入力内のロックスクリプトが、データの予想される部分に署名したアリスの署名を含むことを認証する。データの予想される部分自体（「メッセージ」）はまた、この認証を実行するためにＴｘ_０命令に含まれる必要がある。実施形態では、署名されたデータは、Ｔｘ_０の全体を含む（つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要はない）。

公開－秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自身の秘密鍵でメッセージを暗号化することによってメッセージに署名した場合、アリスの公開鍵および平文のメッセージ（暗号化されていないメッセージ）が与えられると、ノード１０４などの別のエンティティは、メッセージの暗号化バージョンがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージの平文バージョンにタグ付けすることを含み、これにより、公開鍵の任意の保持者が署名を認証することができる。したがって、データの特定の部分またはトランザクションの一部などに署名することへの本明細書におけるいかなる参照も、実施形態では、データのその部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。

Ｔｘ_１内のロック解除スクリプトが、Ｔｘ_０のロックスクリプト内で指定されている１つまたは複数の条件を満たす場合（つまり、図示の例では、アリスの署名がＴｘ_１内で提供され、認証された場合）、ノード１０４は、Ｔｘ_１が有効であると見なす。それがマイニングノード１０４Ｍである場合、これは、ワークオブプルーフを待つトランザクションのプール１５４にそれを追加することを意味する。それがフォワーディングノード１０４Ｆである場合、トランザクションＴｘ_１をネットワーク１０６内の１つまたは複数の他のノード１０４にフォワードして、トランザクションＴｘ_１がネットワーク全体に伝搬されるようにする。Ｔｘ_１が妥当性確認されてブロックチェーン１５０に含まれると、これは、Ｔｘ_０からのＵＴＸＯ_０を使用済みとして定義する。Ｔｘ_１は、未使用のトランザクション出力２０３を使用する場合にのみ有効であり得ることに留意されたい。別のトランザクション１５２によってすでに使用された出力を使用しようとする場合、Ｔｘ_１は、他のすべての条件が満たされたとしても無効になる。したがって、ノード１０４はまた、先行するトランザクションＴｘ_０内の参照されたＵＴＸＯがすでに使用済みである（別の有効なトランザクションへの有効な入力をすでに形成している）かどうかをチェックする必要がある。これは、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である１つの理由である。実際には、所与のノード１０４は、どのトランザクション１５２内のどのＵＴＸＯ２０３が使用されたかをマーキングする別個のデータベースを維持し得るが、最終的には、ＵＴＸＯが使用されたかどうかを定義するものは、ブロックチェーン１５０内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。

所与のトランザクション１５２のすべての出力２０３において指定された総額が、そのすべての入力２０２によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効性の別の根拠となる。したがって、そのようなトランザクションは、ブロック１５１に伝搬もマイニングもされない。

ＵＴＸＯベースのトランザクションモデルでは、所与のＵＴＸＯが全体として使用される必要があることに留意されたい。ＵＴＸＯにおいて使用済みとして定義された額の一部を「後に残す」ことはできず、別の一部が使用される。しかしながら、次のトランザクションの複数の出力間でＵＴＸＯからの額を分割することはできる。例えば、Ｔｘ_０内のＵＴＸＯ_０において定義された額は、Ｔｘ_１内の複数のＵＴＸＯ間で分割され得る。したがって、アリスが、ＵＴＸＯ_０において定義された額のすべてをボブに与えたくない場合、アリスは、リマインダを使用して、Ｔｘ_１の第２の出力において自分自身に残りを与えるか、または別の当事者に支払うことができる。

実際には、今日、生成トランザクションの報酬だけでは、典型的には、マイニングを動機付けるのに十分ではないので、アリスは通常、勝利マイナーに対する手数料を含む必要もある。アリスがマイナーに対する手数料を含めない場合、Ｔｘ_０は、マイナーノード１０４Ｍによって拒否される可能性が高く、したがって、技術的に有効であっても、それは依然として伝搬されず、ブロックチェーン１５０に含まれない（マイナープロトコルは、マイナー１０４Ｍが望まない場合にトランザクション１５２を受け入れることを強制しない）。いくつかのプロトコルでは、マイニング手数料は、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯを必要としない）。代わりに、所与のトランザクション１５２の入力（複数可）２０２によって指し示される総額と出力（複数可）２０３で指定されている総額との間の差が自動的に勝利マイナー１０４に与えられる。例えば、ＵＴＸＯ_０へのポインタがＴｘ_１への唯一の入力であり、Ｔｘ_１は唯一の出力ＵＴＸＯ_１を有するとする。ＵＴＸＯ_０で指定されているデジタル資産の額がＵＴＸＯ_１で指定されている額より大きい場合、その差が自動的に勝利マイナー１０４Ｍに贈られる。しかしながら、代替的にまたは追加的に、マイナー手数料がトランザクション１５２のＵＴＸＯ２０３のうちのそれ自体の１つにおいて明示的に指定され得ることが必ずしも除外されるものではなない。

アリスおよびボブのデジタル資産は、ブロックチェーン１５０内のどこにでもある任意のトランザクション１５２においてそれらにロックされた未使用ＵＴＸＯから構成される。したがって、典型的には、所与の当事者１０３の資産は、ブロックチェーン１５０全体にわたる様々なトランザクション１５２のＵＴＸＯ全体に散在している。ブロックチェーン１５０内のどこにも、所与の当事者１０３の総残高を定義する数字は格納されない。クライアントアプリケーション１０５におけるウォレット機能の役割は、それぞれの当事者にロックされ、別の前方のトランザクションでまだ使用されていない様々なＵＴＸＯすべての値を一緒に照合することである。これは、ストレージノード１０４Ｓのいずれか、例えば、それぞれの当事者のコンピュータ機器１０２に最も近いまたは最良に接続されたストレージノード１０４Ｓに格納されたブロックチェーン１５０のコピーにクエリを行うことによって行うことができる。

スクリプトコードは、しばしば、概略的に表される（すなわち、正確な言語ではない）ことに留意されたい。例えば、[Checksig P_A]と書いて[Checksig P_A] = OP_DUP OP_HASH160 <H(P_A)> OP_EQUALVERIFY OP_CHECKSIGを意味し得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。ＯＰ＿ＣＨＥＣＫＳＩＧ（「Ｃｈｅｃｋｓｉｇ」とも呼ばれる）は、２つの入力（署名および公開鍵）を取り、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）を使用して署名の有効性を検証するスクリプトオペコードである。実行時に、署名（「ｓｉｇ」）の存在（occurrence）はスクリプトから除去されるが、ハッシュパズルなどの追加要件は、「ｓｉｇ」入力によって検証されたトランザクションに残る。別の例として、ＯＰ＿ＲＥＴＵＲＮは、トランザクション内にメタデータを格納することができ、それによってメタデータをブロックチェーン１５０に不変に記録することができる、トランザクションの使用不可能な出力を作成するためのスクリプト言語のオペコードである。例えば、メタデータは、ブロックチェーンに格納することが望まれる文書を含み得る。

署名Ｐ_Ａはデジタル署名である。実施形態において、これは、楕円曲線ｓｅｃｐ２５６ｋ１を使用するＥＣＤＳＡに基づく。デジタル署名は、特定のデータの一部分に署名する。実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の全部または一部に署名する。署名された出力の特定の部分は、ＳＩＧＨＡＳＨフラグに依存する。ＳＩＧＨＡＳＨフラグは、どの出力が署名されるかを選択するために署名の最後に含まれる４バイトコードである（したがって、署名時に固定される）。

ロックスクリプトは、それぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「ｓｃｒｉｐｔＰｕｂＫｅｙ」と呼ばれることがある。ロック解除スクリプトは、それが対応する署名を供給するという事実を指して「ｓｃｒｉｐｔＳｉｇ」と呼ばれることがある。しかしながら、より一般的には、ＵＴＸＯが償還されるための条件が署名を認証することを含むことは、ブロックチェーン１５０のすべてのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語を使用して、任意の１つまたは複数の条件を定義することができる。したがって、「ロックスクリプト」および「ロック解除スクリプト」というより一般的な用語が好まれ得る。

レイヤ２オーバーレイネットワーク
ブロックチェーンネットワーク１０６は、すでに、インターネット１０１などのネットワーク上にオーバーレイされたオーバーレイネットワークの形態である。しかしながら、ブロックチェーンの上にオーバーレイネットワークの別の層を重ねることも可能である。これは、例として図３に示されている。一例はメタネットである。そのようなネットワークはまた、基礎となるネットワークインフラストラクチャとしてのベースネットワーク１０１（例えば、インターネット）と、ベースネットワーク上にオーバーレイされたオーバーレイネットワークの第１の層としてのブロックチェーンネットワーク１０６とに対して、オーバーレイネットワークの第２の層であるという意味で、「レイヤ２」ネットワークと呼ばれ得る。

オーバーレイネットワーク３００のこの第２の層は、ノード３０１およびエッジ３０２のネットワークを含む。ここで、ノード３０１は、図１および図２に関連して前述したようなブロックチェーンネットワーク１０６の層におけるノード１０４ではなく、メタネット（またはブロックチェーン上にオーバーレイされた他のそのようなネットワーク）の層におけるノードを指すことに留意されたい。メタネットネットワーク（または同様のもの）の各ノード３０１は、ブロックチェーン１５０上の異なるそれぞれのトランザクション１５２であり、それぞれが、それぞれのトランザクションのペイロードにデータを格納する。したがって、メタネットネットワーク３００（または同様のもの）のノード３０１は、本明細書では、データストレージノードまたはデータストレージトランザクションとも呼ばれ得る。そこに格納されるデータは、データコンテンツおよび／またはメタデータ、典型的には両方を含み得る。出力ベースのモデルでは、それぞれのトランザクションの使用不可能な出力２０３に格納され得る。この出力は、実行時にスクリプトを終了させるロックスクリプト内のオペコードによって使用不可能にされ得る。例えば、スクリプト言語を用いるシステムでは、これはＯＰ＿ＲＥＴＵＲＮオペコードであり得る。しかしながら、これは限定されず、当業者は、他のブロックチェーンシステム、例えばアカウントベースのモデルを採用するシステムにおいてトランザクションに任意のペイロードデータを格納するための他の技法を認識するであろう。以下では、出力ベースのモデルに関して例示し得るが、これに限定されるものではない。

レイヤ２オーバーレイネットワーク３００は、純粋にデータから構成され、完全に仮想であってもよいことに留意されたい。すなわち、ブロックチェーン１５０のトランザクション１５２上にオーバーレイされたオーバーレイネットワークとして、メタネットなどのノード３０１およびエッジ３０２は、基礎となるブロックチェーンネットワーク１０６または基礎となるネットワークインフラストラクチャ１０１の任意の特定の物理的アクタまたはエンティティに必ずしも対応しない。

データコンテンツは、例えばテキスト、オーディオ、静止画もしくは動画、または他のファイルもしくは文書を格納するためにメタネット（または同様のもの）が使用されている実際のデータである。これは、ユーザコンテンツまたはユーザデータとも呼ばれ得る。メタデータは、ブロックチェーン１５０の上にネットワークを階層化するためのプロトコルを実装する。トランザクション１５２の少なくともいくつかでは、それはデータコンテンツ間のリンクを定義する。これらは、ノード３０１間のエッジ３０２として説明することもできる。リンクまたはポインタは、例えば、親ノードのトランザクションＩＤ、ＴｘＩＤ_{ｐａｒｅｎｔ}、を含み得る。本明細書で参照される「リンク」は、１つの可能性ではあるが、必ずしもハイパーテキストリンクを意味するものではないことに留意されたい。より一般的には、リンクは、現在のノード３０１がメタネット層（または、ブロックチェーン１５０の上に階層化された他のそのようなオーバーレイ層）において関連している別のノード３０１を指し示す任意の形態のポインタを指すことができる。

便宜上、以下では、例としてメタネットに関して説明するが、これに限定されず、より一般的には、メタネットを参照する本明細書の箇所はいずれも、ブロックチェーン上にオーバーレイされた任意のオーバーレイネットワークで置き換えられ得ることが理解されよう。同様に、メタネットノードへのいかなる参照も、任意のオーバーレイネットワークノードまたはオーバーレイネットワークのデータストレージノードへの参照と置き換えられ得、メタネットリンクまたはエッジへの任意の参照は、当該オーバーレイネットワークの層における任意のオーバーレイネットワークエッジまたはリンクへの参照と置き換えられ得る。

メタネットプロトコルは、公開ブロックチェーン上にマイニングされ、多くの使用事例のために様々なアプリケーションにおいて使用されることができるオンチェーンデータを構造化するための方式および規格を定義する。プロトコルは、ノードおよびエッジを含むグラフ構造をブロックチェーントランザクションのセットから構築することができること、およびこれらの構造を使用して任意の性質のデータ（「コンテンツ」）を格納し、伝達し、表現し、配信することができることを規定する。トランザクションをノードとして扱い、署名をトランザクション間に作成されたエッジとして扱うことによって、メタネットプロトコルは、図３に示すようなオンチェーングラフ構造の作成を可能にする。

図から分かるように、メタネット３００のノード３０１およびエッジ３０２はツリー構造を形成する。すなわち、親ノード３０１は、１つまたは複数の子ノード３０１にリンクされ、任意の所与の子３０１はそれ自体が、それ自体の１つまたは複数の子にリンクされた親であり得、以下同様である。本発明の目的上、当該ツリー構造は、より広いツリーまたはグラフのサブセットのみであり得ることに留意されたい。

図３はまた、ノード３０１およびその関連付けられたエッジ３０２がどのように更新され得るかを示す。トランザクションはブロックチェーン１５２上に不変的に記録されるので、メタネットノード３０１に対する更新は、新しいトランザクション１５２によって新しいインスタンス３０１’および対応するエッジ３０２’を作成することを必要とする。

図３の構造は、ネストされたドメイン、例えば、ウェブサイトおよびそのページの構造を含み得、ここで、「トップレベルドメイン」は、その下のサブドメインをカプセル化し、以下同様である。１つの機能鍵ドメイン（後述する、例えば、書き込み鍵、ファンディング鍵（funding key）または暗号化鍵のドメイン）は、これらの構造ドメインの多くに及ぶことができる。図３に示される構造的な「ドメイン」は、後述される機能鍵ドメインと混同されるべきではない。

図３の円は、メタネットプロトコルのルールセットにしたがって作成される単なるトランザクションであるノードを表す。そのルールセットにしたがって作成されフォーマットされたトランザクション１５２Ｎの例を図４に示す。

図４の右側にあるトランザクション１５２Ｎは、メタネットの所与のノード３０１Ｎ（子）を実装するブロックチェーン１５０のトランザクション１５２を表す。図４の左上にあるトランザクション１５２Ｐは、メタネット層における子ノード１５２Ｎの親を実装するブロックチェーン１５０のトランザクションを表す。子ノードのトランザクション１５２Ｎは、ロック解除スクリプトを含み、ブロックチェーン１５０のファンディングトランザクション１５２Ｆの出力２０３を指し示す入力２０２を有する。言い換えれば、ファンディングトランザクション１５２Ｆの出力は、メタネットノード１５２Ｎの入力によって消費される。ファンディングトランザクション１５２Ｆおよびメタネット親トランザクション１５２Ｐは、必ずしも同じトランザクションではないことに留意されたい（ただし、それも除外されない）。

子トランザクション１５２Ｎは、ペイロード（ブロックチェーン層の観点からのペイロード）を保持する、例えばＯＰ＿ＲＥＴＵＲＮによって使用不可能にされた使用不可能な出力２０３を含む。このペイロードは、メタネットのデータコンテンツを含み得、それは、暗号化される場合もされない場合もある。図４では、例として、データコンテンツ（「Ｄａｔａ」）は、暗号化関数ｅおよび暗号化鍵ｅｋによって暗号化されて示されている。しかしながら、これは、平文のデータコンテンツによって置き換え得る（この場合、＜ｅ（Ｄａｔａ，ｅｋ）＞は、単に図４の＜Ｄａｔａ＞によって置き換えられる）。データコンテンツが暗号化されている場合、データを解読し、それを平文で見るためには、暗号化鍵ｅｋ、または対応する解読鍵が必要とされる。

子トランザクション１５２Ｎのペイロードは、メタネットネットワーク層のメタデータも含む。このメタデータは、少なくとも親トランザクション１５２Ｐのトランザクション識別子を含む。これは、メタネット層でリンク（エッジ）３０２を作成する。また、子ノード３０１Ｎに関連付けられた鍵Ｐ_ｎｏｄｅを含むことがメタネットプロトコルによって要求され得る。

ファンディングトランザクション１５２Ｆの出力２０３のロックスクリプトはまた、署名が子ノード１５２Ｎの入力２０２内のロック解除スクリプトに含まれることを必要とする。具体的には、この署名は、メタネット親に関連付けられた鍵Ｐ_{ｐａｒｅｎｔ}を使用して署名された署名（すなわち、その鍵によって署名されたメッセージ）である必要がある。これは、ブロックチェーン層においてエッジ４０２（使用エッジと呼ばれることもある）を作成する。必要とされる署名が子トランザクション１５２Ｎの入力２０２内のロック解除スクリプトに含まれていない場合、子トランザクション１５２Ｎは、ブロックチェーンネットワーク１０６のノード１０４によって妥当性確認されないので、ブロックチェーンネットワーク１０６を通して伝搬されることも、ブロックチェーン１５０に記録されることもない。しかしながら、ファンディングトランザクション１５２Ｆは必ずしもメタネット親トランザクション１５２Ｐと同じブロックチェーントランザクション１５２ではないので、ブロックチェーン層使用エッジ４０２は、必ずしもメタネット層エッジ３０２と同じではないことに再度留意されたい。

図４は、トランザクション全体の抽象化として、メタネットトランザクションの特定の関連のある構成要素のみを概説する。これらの構成要素は、プロトコル識別子フラグに加えて、以下を含む：
・ 公開鍵Ｐ_ｎｏｄｅ
・ 親公開鍵Ｐ_{Ｐａｒｅｎｔ}の署名ＳｉｇＰ_{Ｐａｒｅｎｔ}
・ ノード自体のトランザクションＩＤ ＴｘＩＤ_ｎｏｄｅ
・ ノードの親のトランザクションＩＤ ＴｘＩＤ_{Ｐａｒｅｎｔ}

プレースホルダ＜Ｄａｔａ＞は、一般に、メタネットノードトランザクションに含まれ得る任意のコンテンツデータを指す。また、多くのアプリケーションでは、暗号化鍵ｅｋでデータを暗号化することを望むことも予想され、ここ場合、トランザクションに含まれるデータは＜ｅ（Ｄａｔａ，ｅｋ）＞としてキャストされ、ここで、ｅ（ ）は適切な暗号化関数である。

各メタネットノード３０１は、強力なバージョニングおよび許可制御がメタネットグラフによって継承されることを可能にするインデックスであるペア（Ｐ_ｎｏｄｅ，ＴｘＩＤ_ｎｏｄｅ）によって一意に識別され得る。各メタネットノードは、それ自体（Ｐ_ｎｏｄｅ，ＴｘＩＤ_ｎｏｄｅ）およびその親（Ｐ_{Ｐａｒｅｎｔ}，ＴｘＩＤ_{ｐａｒｅｎｔ}）を識別するのに十分な情報を含むことも理解されたい。

メタネットノード３０１Ｎのトランザクションが親ノード３０１Ｐからの正しい入力署名ＳｉｇＰ_{Ｐａｒｅｎｔ}を含むことを保証するために、多くの場合、これを容易にするファンディングトランザクションを作成することが望ましい場合があり、これを図４の左下に示す。

親鍵Ｐ_{ｐａｒｅｎｔ}および／または子ノード鍵Ｐ_ｎｏｄｅは、ブロックチェーン１５０への子ノード３０１Ｎのデータの書き込みを認可する書き込み鍵と見なされ得る。これらはまた、本明細書では「構造鍵」とも呼ばれ得る。

階層鍵セット
特定のユーザまたはアプリケーションに関するブロックチェーントランザクション１５２に関連付けられた鍵は、典型的には、階層鍵構造を使用して管理される。例えば、所与のユーザのウォレットに関連付けられ得る多くの秘密鍵および公開鍵を処理するために、階層的決定論的（ＨＤ）鍵管理として知られる共通規格が出現している。この規格は、ユーザのウォレット内のすべての鍵が単一のエントロピー源から導出され得ることを保証することと、公に知られている導出関数を使用して、鍵が決定論的な方法でそのシードから導出されることを保証することとによって、多くのそのような鍵ペアの処理を容易にするように設計される。ＨＤウォレット自体は周知であり、単に、「ＢＩＰ」として知られる複数の改善提案、すなわちＢＩＰ３２、ＢＩＰ３９、およびＢＩＰ４４において概説されるトランザクションで使用されるべき鍵を導出するための明確に定義された規格を使用するウォレットである。本質的に、これらの規格は、「シード」鍵から多くの秘密鍵および公開鍵を決定論的に生成し、シード鍵から特定の子孫鍵を生成するための「パス」を定義し、決定論的な鍵導出関数を使用して階層ウォレット構造を定義する方法を定義する。所与のユーザの資金または特定のアプリケーションのトランザクションに関連付けられた鍵を処理するためのこれらの規格は、ブロックチェーン業界で広く使用されている。

決定論的な方法で別の鍵から１つの鍵を導出する決定論的アルゴリズムは、子鍵導出（ＣＫＤ）関数と呼ばれることがある。したがって、鍵のセットは、シードから開始して決定され得、これらはすべて階層的に互いに関連している。このような鍵の階層セットもツリー構造を有する。すなわち、セット内の鍵は、ツリー構造に従う導出の階層において互いに導出される。すなわち、１つまたは複数の鍵がシードから導出され、次いで、シードのそのような子ごとに、１つまたは複数の鍵がその鍵から導出され得、以下同様である。このツリー構造では、各ノードは鍵であり、各エッジはその親からのその鍵の導出を表す。親鍵またはシードが与えられると、アルゴリズムを知っている任意の当事者がその１つまたは複数の子を決定論的に決定することは可能であるが、子鍵が与えられても、親鍵を決定することは不可能である（または少なくとも計算的に実行可能ではない）。当技術分野では、所望される任意のグラフ構造（例えばツリー構造）を有する階層鍵セットを生成することを可能にする様々な形態のＣＫＤが知られている。例示としてのみ、１つの特定の例を後述する。ＣＫＤをシードまたは親鍵に適用することによって所与の鍵または鍵グラフ構造が導出されるといわれる場合、これは、ＣＫＤをシード／親およびいくつかの他のデータに適用することによって鍵またはグラフ構造が導出され得ることを除外しないことに留意されたい。例えば、実施形態では、ＣＫＤ関数は、入力として、親鍵またはシード、チェーンコードと呼ばれる何らかの他のデータ、および所与の親に対して（複数の兄弟の）子が作成されているインデックスを取る。同様に、チェーンコードおよび／またはインデックスを、ＣＫＤの形態をパラメータ化するパラメータとみなすことができる。

本明細書で使用される「シード」という用語は、シードが全体的な階層またはツリーにおける絶対的な最高レベルの鍵であることを必ずしも意味しないことにも留意されたい。より一般的には、ＣＫＤを階層内の任意の鍵に適用して、そこから１つまたは複数の子鍵を生成することができる。本明細書における「シード」は、単に、所与の鍵セットの他の子鍵が導出される任意の親鍵または値である。実施形態では、シード自体が、より広い階層における別の鍵またはシードの子鍵であってもよい（例えば、後でより詳細に説明する図６を参照）。

メタネット構造に対して上記フレームワークを採用することが望ましいであろう。特に、メタネット構造を定義する鍵ＰをＨＤウォレットなどにマッピングするためにＣＫＤ関数が使用され得る。これは、例として図５に示されている。

上述したように、各メタネットノード３０１は、メタネットネットワーク層においてそれに関連付けられた鍵Ｐを有する（図４の例におけるＰ_ｎｏｄｅおよびＰ_{ｐａｒｅｎｔ}を参照）。メタネットネットワークノード３０１およびエッジ３０２の対応するツリー構造３００上に直接マッピングするツリー構造５００にしたがってこれらの鍵を生成することが有利である。すなわち、メタネットツリー構造内の各メタネットノード３０１は、鍵ツリー５００内の１つの対応する鍵に一意にマッピングされ、各メタネットエッジ３０２は、鍵ツリー５００内の１つの対応する鍵導出エッジに一意にマッピングされる。これは、メタネットツリーにおけるノード３０１の位置、シードの知識、および使用されるＣＫＤ関数の形態が与えられると、そのノード３０１に必要とされる関連のある鍵を導出することが常に可能であることを意味する。

これの有利な適用は、ソフトウェアの異なるモジュール間で鍵のより安全なおよび／または圧縮された（より低いオーバーヘッドの）通信を可能にすることである。これは、図８に示されている。図８は、第１のソフトウェアモジュール８１０および第２のソフトウェアモジュール８２０を示す。例えば、これらは、遠隔で（例えば、インターネット１０１上で）通信するコンピュータ機器の別個の部分上のソフトウェアのモジュールであり得る。および／または、それらは、異なる当事者によって実行されるソフトウェアのモジュールであってもよい。代替的に、それらは、同じ当事者の同じコンピュータ機器上で実行されるソフトウェアの異なるモジュールであってもよく、この場合、２つのモジュール間に少なくともある程度の分離が望まれる（例えば、一方が破損したり危険にさらされたりしても、他方がそうならないように）。それらは、ブロックチェーンネットワーク１０６のクライアント１０３のウォレットソフトウェア、またはブロックチェーンネットワーク１０６のノード１０４のノードソフトウェア（例えば、マイナーソフトウェア）に実装され得る。それらは、１つまたは複数のメモリユニット上に物理的に記憶され、図１に関連して前述したタイプのいずれか、および／または当業者によく知られている任意の他のタイプの１つまたは複数の処理ユニット上で実行され得る。

第１のソフトウェアモジュール８１０は、通信８１５を第２のソフトウェアモジュール８２０に送り、メタネット３００の所与のノード３０１に関連付けられた鍵を第２のモジュール８２０に通信して、第２のソフトウェアモジュール８２０が、鍵の実行を必要とするそのノード３０１に関連する機能を実行することを可能にする。通信８１５は、１つまたは複数の個々の信号またはメッセージを含み得る。

鍵を通信するためには、第１のモジュール８１０は、通信８１５に、Ｉ）メタネットツリー構造におけるノード３０１の位置を含めるだけでよい。通信８１５はまた、異なる可能なオプションがある場合、ＩＩ）使用されるＣＫＤ関数の形態の指示を含み得る。代替的に、ＣＫＤの形態は、第２のモジュール８２０に事前に知られている固定された所定の種類であってもよく、この場合、通信８１５においてシグナリングされる必要はない。いずれにしても、シードが事前に決定され、第２のモジュール８２０に事前に知られている場合、鍵自体もシードも通信８１５に含まれる必要はない。例えば、シードは、第１のモジュール８１０と第２のモジュール８２０との間で共有されるシークレットであり得、例えば、ある初期の時点で第１のモジュール８１０または第３の管理者モジュールによって第２のモジュール８２０と一度だけ共有され得る。これは、後の時点で第１のモジュール８１０が異なるメタネットノード３０１について鍵を第２のモジュール８２０に通信するとき、鍵を明示的にシグナリングする必要がないことを意味し、したがって、傍受のリスクを低減し、および／または各メタネットノード３０１について鍵またはシードを毎回送るシグナリングオーバーヘッドを回避することを意味する。

ツリー構造３００は、全体的なメタネットグラフのサブセットでしかない可能性があることに再度留意されたい。したがって、シードは、単に、階層ドメインのあるレベルにおける親鍵であり得、シード自体が、ツリーまたはグラフのさらに上に親を有し得る。

いくつかの他のアプリケーションでは、通信８１５は、ＩＩＩ）シードも含み得る。これについては後により詳細に説明する。

機能鍵ドメイン
暗号化されたデータを含み得る、図４に示されるような典型的なメタネットトランザクション１５２Ｎ、およびその対応するファンディングトランザクション１５２Ｆを調べると、単一のメタネットノード３０１に関連付けられたいくつかの異なる鍵（例えば、Ｐ_ｎｏｄｅ、Ｐ_{ｐａｒｅｎｔ}、ＴｘＩＤ_ｎｏｄｅ、ｅｋ）が存在することが分かる。

メタネットノードおよびその対応するファンディングトランザクションに関連付けられた潜在的に多くの異なるタイプの鍵が存在する。例えば、これらは、その機能にしたがって以下のように分類され得る：
・ 構造（書き込み）鍵－Ｐ_{ｎｏｄｅ，}Ｐ_{Ｐａｒｅｎｔ}
・ 暗号化鍵－ｅｋ
・ ファンディング鍵－Ｐ_{Ｆｕｎｄｉｎｇ}

メタネットトランザクションのより複雑な例では、メタネットノードトランザクション１５２Ｎを作成するために使用される他の機能に関連する他の鍵タイプ、および／またはメタネットノード３０１に関連して他の機能を実行する他の鍵タイプも存在し得ることに留意されたい。例えば、別のタイプの鍵は、アプリケーション層機能を容易にするアプリケーション層鍵、例えば、（ノード３０１のデータが、何らかのアプリケーション層目的のために２回以上使用されない、または２回カウントされないことを保証するための）冪等鍵であり得る。別の例として、暗号化の代替として、またはそれに加えて、データコンテンツは、パディングまたは並べ替えなどの別の形態の難読化の対象であり得、これは、難読化および／または難読化解除するために対応する難読化鍵を必要とし得る。

前述したように、鍵を管理するためにＨＤウォレット規格（または同様のもの）の普及およびロバスト性を利用することが有利であり、本明細書に開示される実施形態では、この要望は、任意のまたはすべてのそのような鍵タイプ、例えば、構造鍵、暗号化鍵、およびファンディング鍵にまで及ぶ。しかしながら、異なる鍵タイプは、別々に処理および管理される必要があり得る。また、好ましくは、すべての鍵は、危殆化のリスクを低減するために同じシードから生じるべきである。しかしながら、これら２つの要件は全く矛盾する。すべてが同じシード鍵から生じることを維持しながら鍵の分離をどのように保証すべきか、直ちに明らかにならない。さらに複雑なことに、上述したように、そのようなＨＤ鍵階層のさらに望ましい特性は、所与の鍵の導出パスがメタネットグラフ構造に（少なくとも部分的に）マッピングされるべきであることである。言い換えれば、メタネットグラフ構造を鍵階層（例えば図５にあるような）に反映させたいという要望は、最初の２つの相反する要件の調整に加えて、満たされなければならない第３の要件として機能する。

以下では、特定のトランザクションの作成に関与する単一の機能に関連する鍵を有するＨＤウォレットの分岐として機能鍵ドメインを定義することによってこの問題を解決するソリューションを開示する。

メタネットトランザクションでは、説明すべき２つ、３つまたはそれ以上の異なる機能（例えば、構造化、暗号化、およびファンディング）が存在し得る場合、各鍵タイプは、ＨＤ鍵構造の独立した分岐を割り当てられる。

書き込み鍵（すなわち構造鍵）Ｐ_ｎｏｄｅ、Ｐ_{ｐａｒｅｎｔ}は、メタネットトランザクションに署名するために使用され、暗号化鍵は、トランザクションに含まれる任意のコンテンツデータを暗号化するために使用され、ファンディング鍵は、ＵＴＸＯがメタネットトランザクションによって使用されるファンディングトランザクションに署名するために使用される。

ＨＤ構造全体におけるすべての鍵は一意であり、ウォレットのマスタ鍵（ｍｋ）ペア（マスタシード）の知識なしでは互いに関連付けることができない。しかしながら、それらはすべてが同じメタネット構造位置に属するという点で関連している。この共通の位置は、所与の鍵に対する全体的なパス内に埋め込まれた複数のパスタイプのシステムを使用して符号化される。

図６は、異なる機能鍵ドメインを割り振る例を示す。図６は、ＣＫＤ関数を使用して作成され得る例示的な導出ツリーを示す。好ましくは、ツリーの上部（ソースまたはルート）にマスタシード６０１Ｍ（ｍｋ）がある。複数の子シードが、複数のタイプの機能のそれぞれに１つずつ、これから導出される。各子シードは、それぞれのタイプの機能（例えば、書き込み、暗号化、およびファンディング）のための鍵のそれぞれセットのソース／ルートとして機能する。示された例では、３つのそのような機能のための３つの子シードがそれぞれ存在し、それらは次の通りである：メタネットノード３０１の書き込みを可能にするための書き込み鍵Ｐのセットを導出するための書き込みシード６０１Ｗ、ノード３０１のデータコンテンツを暗号化および／または解読するための暗号化鍵ｅｋのセットを導出するための暗号化シード６０１Ｅ、およびブロックチェーン１５０上のノード３０１の対応するトランザクション１５２の記録にファンディングするための鍵のセットを導出するためのファンディングシード６０１Ｆ。シード自体は、一種の鍵（すべてが同じマスタ鍵６０１Ｍから導出される場合にはそのそれぞれの鍵セットのシードまたはサブマスタ鍵）と考えられ得る。

鍵の各セットは、それぞれのツリー構造を含み、それにしたがって、それぞれの鍵セット内の鍵がそれにしたがって互いから導出される。このような各ツリー構造は、マスタシード６０１Ｍから生じるツリー全体のサブツリーである。各鍵セット内で、ツリー構造は、メタネット３００のツリー構造上に直接マッピングされる。したがって、異なる鍵セットのツリー構造は、互いに同じである。そのため、例えば、メタネット（または当該断片）のノード３０１ごとに１つの書き込み鍵が存在し、それらの鍵の導出のエッジは、メタネットツリー構造３００内の対応するエッジ３０２に正確に従う。同時に、メタネット（または当該断片）のノード３０１ごとに１つのファンディング鍵が存在し、ファンディング鍵の導出のエッジは、メタネットツリー構造３００内の対応するエッジ３０２、および書き込み鍵セット内の対応する書き込み鍵間の端（end）に正確に従う。また、この方式にしたがって鍵セットが導出される暗号化および／または任意の他の機能についても同様である。

ここでの所与の鍵は、秘密鍵、または公開鍵、または公開鍵－秘密鍵ペアを指し得ることに留意されたい。実施形態では、秘密鍵は、最初にツリー構造にしたがって導出され、次いで、対応する公開鍵が秘密鍵から導出される。

これらのタイプの機能のうちの１つまたは複数、例えば暗号化について、例えば暗号化の複数のレイヤに対して、複数の鍵セットが生成され得ることにも留意されたい。この場合、暗号化鍵セットの各々は、図６の下中央に例として示されるように、同じツリー構造を有する。

さらに、本明細書で使用される「シード」という用語は、広いツリー構造の絶対的な最終のマスタシードを必ずしも意味しないことに再度留意されたい。例えば、書き込みシード６０１Ｗは、それ自体がマスタシード６０１Ｍの子鍵である。シードは、単に任意のタイプの鍵または値であり、他の鍵を導出するために使用され得る。実施形態では、異なる機能のシード（例えば、６０１Ｗ、６０１Ｅ、６０１Ｆ）は、実際には、すべて何らかのマスタシードまたは鍵６０１Ｍから導出された鍵である。本明細書で参照されるシードは、（少なくとも局所的に）所与の鍵のセットに対する階層の「トップ」鍵であるが、より広い階層では子であり得る特別なタイプの鍵を指し得る。

書き込み、暗号化、およびファンディングの例は、それぞれの鍵セットが必要とされ得るメタネット（または同様のもの）において実装され得る異なるタイプの機能のいくつかの例にすぎず、ここで、所与のタイプの機能に対して所与のセット内のノードごとに鍵があることが理解されよう。より一般的には、上で概説した方式は、任意の第１および第２の機能の鍵セットに適用され、いくつかの実施形態では、第３の機能またはそれ以上の機能に適用され得る。例えば、暗号化は、任意の難読化（例えばパディングまたは並べ替え）に一般化され得る。または、この方式は、何らかのアプリケーション層目的（例えば、冪等）で各メタネットノード３０１に割り当てられるべきアプリケーション層シリアル番号など、完全に異なるタイプの鍵に使用され得る。

図８に戻ることで、説明した方式の有利な適用を理解することができる。第２の鍵セットの鍵を危険にさらすことも、鍵自体を明示的に通信することもなく、第１のソフトウェアモジュール８１０が、第１の鍵セットの鍵を第２のソフトウェアモジュール８２０にシグナリングすることを望む場合を考慮する。同様に、第１および第２のモジュール８１０は、異なる遠隔コンピュータ機器上で、および／または異なる当事者によって実行され得るか、または、所与の当事者のソフトウェア内の分離モジュールであり得、および／もしくは同じ機器上で実行され得る。いずれにしても、鍵の第１のセットが第１のタイプの機能（例えば、メタネットにノード３０１を書き込むこと）を可能にし、鍵の第２のセットが第２のタイプの機能（例えば、ノードのデータコンテンツを解読すること）を可能にする場合を考慮する。所与のセット内で、各鍵は、メタネットノード３０１の異なる対応する１つに対する機能を有効にする。第２のモジュール８２０がノード３０１の特定の１つに関連して第１の機能を実行することを可能にするために、第１のソフトウェアモジュール８１０は、少なくとも、Ｉ）メタネット鍵構造３００における対応するノード３０１の位置に関して対応する第１の鍵を示す通信８１５を第２のモジュール８２０に送ることができる。任意選択的に、それはまた、ＩＩ）使用されるＣＫＤ関数の形態、およびＩＩＩ）第１のシード（第１の機能のための第１の鍵セットが導出されるシード、例えば６０１Ｗ）をシグナリングし得る。代替的に、これらのＩＩ、ＩＩＩ）の一方または両方は、事前に決定され、第２のモジュール８２０に事前に知られていてもよい。いずれにしても、第２の鍵またはシード（例えば、６０１Ｅ）は送られない。したがって、第２のソフトウェアモジュール８２０は、関連のある第１のシードと、ノード３０１および対応する第１の鍵の両方のツリー構造内の位置とを知っているので、第１の機能（例えば、書き込み）に関する関連する第１の鍵を導出することができる。しかしながら、第２の鍵を有していないので、第２の機能（例えば、解読）のための鍵を導出することはできない。

例えば、第１のソフトウェアモジュール８１０はアリス１０３ａのウォレットであり得、第２のソフトウェアモジュール８２０はサービスプロバイダボブ１０３ｂまたはマイナー１０４のソフトウェアであってもよい。ボブを例にとる。アリスは、データコンテンツをメタネット３００にアップロードするための技術的専門知識を有していない。ボブは、アリスに代わってこれを行うサービスを提供する。ボブがアリスの代わりにこれを行うために、ボブは、ブロックチェーン１５０に書き込まれるべきＰ個の各ノード３０１に対するアリスの書き込み鍵が必要である。しかしながら、ノード３０１のうちの１つまたは複数のデータコンテンツはまた、そのような各ノードに対して対応する暗号化鍵を用いて暗号化されるべきである。アリスはボブがデータコンテンツを解読できることを望まず、暗号化された形態でそれをアップロードするためにボブによる解読が必要な理由もない。したがって、アリスは、開示された方法を使用して、第２の鍵セット（暗号化鍵）を危険にさらすことなく、第１の鍵セットからの鍵（この場合、書き込み用）をボブに通信することができる。

本出願では、ボブが第２の鍵セットを導出できるようにしないことが目的であるので、アリスは、任意選択的に、ボブへの通信８１５において第１のシードＩＩＩ）をシグナリングし得るが、ボブは、第２のシードが送られることも、他の方法で第２のシードへのアクセスが提供されることもない点に留意されたい。

実施形態では、暗号化鍵は、データを暗号化するために使用される暗号化鍵ｅｋがデータを解読するために必要とされる鍵と同じである対称暗号化方式（例えば、ＡＥＳ）のためのものであり得る。代替的に、データを解読するために異なる鍵が必要とされる非対称暗号化方式（例えば、ＥＣＩＥＳ）が使用されてもよい。この場合、第２の鍵セットの「暗号化」鍵は、解読鍵であってもよく、第２のソフトウェアモジュール８２０に通信される「暗号化」鍵は、解読鍵（アプリケーション空間または暗号化のコンテキストにおいて使用される鍵であるという意味で、一般に「暗号化鍵」と呼ばれる）であってもよい。

ファンディング鍵Ｐ_{ｆｕｎｄｉｎｇ}は、アリスがＢｏｂに知られたくないが鍵の別の例である。ファンディング鍵は、アリスが、メタネットトランザクションをアップロードするための支払いを行うトランザクションに署名するために使用する鍵であり、そのため、アリスは、ボブ（または他の誰か）がそれらを入手して、サービスを提供することなく支払いを受け取ることができるようになることを望まないであろう。

ファンディングトランザクションは必ずしもボブに支払うものではないことに留意されたい。むしろ、ファンディングトランザクションは、ブロックチェーンに乗るために単に（または少なくとも）データストレージトランザクションの支払いを行うものであり、最低限として、マイニング手数料だけを支払い得る。アリスは、オンチェーンまたはオフチェーンのいずれかで、サービスの支払いをボブに行っても行わなくてもよい。鍵の第２のセットをアウトソーシングさせるより説得力のある理由は、処理と量のためであり得る。すなわち、会社（アリス）がブロックチェーン上に多くのデータを置くことを望む場合で、（ａ）そうするためにネイティブ暗号トークン（デジタル資産）を購入すること、または（ｂ）ＵＴＸＯ管理およびトランザクション作成を行うために企業グレードのウォレットを使用するという最適化問題に対処することを望まない場合、単にプロセス全体を他の当事者（ボブ）にアウトソースすることを望み得る。

アリスがデータをチェーン上に置くことを望む者であり、アリスがそれを行うためにボブに「支払う」ことになる場合、仕事を行っているだけなので、両方の当事者がファンディング鍵を知っていても、それは必ずしも問題ではなく、アリスは、不換または他のオフチェーン決済またはビジネストランザクションを介してファンディングトランザクションを作成することでボブのコストをカバーしている可能性がある。

別の例示的な使用事例では、第１のソフトウェアモジュール８１０および第２のソフトウェアモジュール８２０は、所与のウォレットアプリケーション内の異なる分離された機能であり得る。例えば、第１のモジュール８１０は書き込み機能（図６の左側の分岐に対応）であり得、第２の機能は暗号化関数（図６の中央の分岐に対応）であり得る。この場合、一方のモジュールが破損したり危険にさらされたりしても、他方の分離されたモジュールの鍵セットは、必ずしも、それに伴って危険にさらされたり影響を受けたりすることはない。

鍵の導出はツリーの上から下への一方向であることに再度留意されたい。すなわち、上流に戻って子から親鍵を決定することはできないが、親から子鍵を決定することはできる。そのため、第１のシードが共有されても、これはマスタシードを危険にさらすことはないため、第２のシードまたはそれから導出される鍵のいずれも危険にさらさない。ツリーを「下には進むことができるが上には進むことができない」。実施形態では、鍵に対して、特定の分岐を下に進むことができないようにする他の制限を課すこともでき、これは、ハードニングと呼ばれるプロセスを使用して、鍵ごとに適用され得る。

開示された方式を採用する別の代替的なまたは追加的な有利な理由として、ソフトウェアモジュール８１０、８２０の一方または両方は、何らかの他のエンティティ（すなわち、第３のソフトウェアモジュール）が、構造（およびＣＫＤ）におけるメタネットトランザクションの構造／位置およびそれらの鍵の知識のみを使用してメタネットトランザクションのすべての関連のある鍵を回復することができるように、それらの鍵導出における構造が保存されることを保証することを望み得る。この根拠は、第１のモジュール８１０および第２のモジュール８２０が上述した方法で互いに鍵を通信するかどうかにかかわらず適用され得る。

図７は、パスタイプの概念を示す。異なる機能に関連する鍵が異なるエンティティによって別々に処理され得ることを保証するために、実施形態は、鍵階層における垂直レベルに応じて複数の異なるパスタイプに分解され得る機能ベースのパス構造を鍵導出に使用する。例えば：
・ ｍ－パス：トップレベルパスであり、階層内のあらゆるものを記述することができる。
・ ｐ－パス：機能レベルパス（暗号化パス、書き込みパス、ファンディングパス）。
・ ｂ－パス：メタネットグラフ構造パス。

これらのパスは、各鍵に対するより大きな全体的なパスの一部としてより簡単に表現することができ、以下のように書かれる：

ｍ／ｐ／ｂ構成要素に続くパス要素は、所与のメタネットトランザクションに関連付けられたすべての鍵について同一である。これは、メタネットトランザクションが鍵Ｐ_{Ｐａｒｅｎｔ}で署名され、鍵ｅｋで暗号化されたデータを有し、鍵Ｐ_{Ｆｕｎｄｉｎｇ}で署名されたファンディングトランザクションを有し、ここで、すべての鍵は、それぞれのメタネット構造ルートに続く共通パスサブ構造（/…/…）を共有することを意味する。

図９は、第１のソフトウェアモジュール８１０によって実行され得る方法のフローチャートである。ステップＳ１０において、第１のソフトウェアモジュールは、メタネットツリー構造３００を識別する。ステップＳ２０において、第１のソフトウェアモジュール８１０は、第１のシード（例えば、６０１Ｗ）に基づいて、メタネットと同じツリー構造を有する鍵の第１のセットを決定する。ステップＳ３０において、第２のシード（例えば、６０１Ｅ）に基づいて、メタネットおよび第１の鍵セットと同じツリー構造を有する鍵の第２のセットを決定する。好ましくは、第１および第２のシードは、同じマスタシード（例えば、６０１Ｍ）から導出される。ステップＳ４０において、第１のソフトウェアモジュール８１０は、メタネットノード３０１のツリー構造における位置を示す通信８１５を第２のソフトウェアモジュール８２０に送り、第２のモジュール８２０が、示された位置におけるメタネットノード３０１に関連して、鍵の第１のセットに関連付けられた機能を実行することを可能にする。この通信８１５は、任意選択で、第１の鍵セットおよび／または第１のシードを導出するために使用されるＣＫＤ関数の形態を含み得る。代替的に、これらは、第２のソフトウェアモジュール８２０に事前に知られていてもよい。いずれにしても、第１のソフトウェアモジュール８１０から第２のソフトウェアモジュール８２０への通信８１５は、第２のシード（またはマスタシード）を含まない。

図１０は、第２のソフトウェアモジュール８２０によって実行され得る方法を示すフローチャートである。ステップＴ１０において、第２のソフトウェアモジュール８２０は、第１のソフトウェアモジュール８１０からツリー構造におけるノード位置の指示を受信する。ステップＴ２０において、ツリー構造の示された位置知識（およびＣＫＤ関数および第１のシード）に基づいて、第２のソフトウェアモジュール８２０は、第１の鍵セットからメタネットノードおよび対応する鍵を決定する。ステップＴ３０において、次いで、導出された第１の鍵に基づいて、示されたノード３０１に関連して関連のある機能を実行することができる。しかしながら、対応する第２の鍵を導出することができないので、第２の機能を実行することはできない。

本明細書に提示される機能鍵ドメインの概念は、以下の利点または類似のもののうちのいずれか１つまたは複数を提供するために使用され得る。
・ トランザクションの作成は、モジュール化されて、複数の機能に分割され得、複数の機能は、複数の異なるアクタ、サービス、またはマシンの間で分散され得る。これにより、各構成要素を、マイクロサービスとして作成し、他の構成要素から独立して、かつ、動作するために構成要素が他の構成要素に関する情報を有する必要としない方法で最適化することができるので、トランザクション構築をより効率的に行うことができ、システムのスケーラビリティを向上させる効果も有する。
・ マルチ構成要素トランザクション作成システムでは、この方法は、各構成要素は自身の機能ドメイン分岐内の鍵にしかアクセスすることができないので、ある構成要素が危険にさらされた場合に、それが他の構成要素の鍵を危険にさらすことができないことを保証する。
・ 複数の暗号化鍵ｅｋ_１，ｅｋ_２，・・・，ｅｋ_ｎが存在する場合、この方式は、暗号化の複数の層または機能によって操作されたデータに対するきめ細かい許可およびアクセス制御を実装することを可能にする。これを使用して、オンチェーンメタネットデータのための複雑なアクセス制御フレームワーク（ＡＣＦ）を作成することができる。
・ すべての機能ドメイン分岐は、同じ単一のエントロピー減から生じ、これにより、トランザクション構築システム内のすべての構成要素のセキュリティを、マスタ鍵（ｍｋ）へのアクセスを唯一有する単一の非常に安全な構成要素によって処理することができる。これにより、セキュリティをカスタムメイド（bespoke）し、マルチ構成要素システムの単一の構成要素に集中させることができ、これは、システムが全体としてどのように構築されるかを最適化するのに役立ち得る。

子鍵導出（ＣＫＤ）関数
以下では、既知のＣＫＤ関数の例を示す。これは限定的なものではなく、他のＣＫＤも当業者に知られていることは理解されよう。

先に採用された用語では、所与の鍵セットにおけるトップの鍵は「シード」と呼ばれており、複数のそのようなシードは、全体的な階層における「マスタシード」から導出され得る。代替的な用語では、所与のセットのローカル「シード」は、「拡張」鍵（公開鍵であるか秘密鍵であるかにかかわらず）と呼ばれ得、マスタシードは、「エントロピー」と呼ばれ得る。

マスタ鍵を作成するプロセスは、以下のように書くことができる：
・ 「ウォレットシード」として機能するビットの（例えば２５６ビットの）ランダムシーケンスＤを安全な擬似乱数生成器から生成する、
・ ランダムビットシーケンスに対して関数Ｆ（例えば、ＨＭＡＣ－ＳＨＡ５１２）を実行する、
・ ウォレットパラメータを以下のように割り当てる：
－ マスタシークレット鍵：＝Ｆ（Ｄ）の左の２５６ビット、および
－ マスタチェーンコード：＝Ｆ（Ｄ）の右の２５６ビット。

マスタシークレット鍵は、ウォレットのためのマスタ秘密鍵であり、一般に、階層内に秘密鍵－公開鍵ペアを含む。

所与の親鍵の知識だけではその子鍵を生成するのに不十分であることを保証するために、「チェーンコード」として知られる追加のエントロピーがＨＤウォレット全体にわたって使用され得る。チェーンコードは、ＨＤウォレットのすべてのチェーンコードの決定論的シーケンスにおける初期チェーンコードとしてここで生成された「マスタチェーンコード」を使用して、そのＨＤウォレットの鍵階層全体にわたって決定論的に生成される。

マスタ鍵に必要なエントロピーを、人間が覚えやすく操作しやすいようにニーモニックフレーズに抽象化するシステムはＢＩＰ３９に概説されており、それ以来、暗号通貨ウォレットで使用される標準的な技法となっている。

拡張鍵：前述したように、ＨＤウォレットは、子鍵を導出するために、鍵の知識に加えて、チェーンコードとして知られる追加のエントロピー単位を必要とする。したがって、「拡張」鍵の概念は、その対応するチェーンコードと連結された所与の鍵を表すために使用され得る。これらは、それぞれ拡張秘密鍵および拡張公開鍵について、以下のように書くことができる：
EPriv：＝(privkey, chain code)
EPub：＝(pubkey, chain code)
これらの拡張秘密鍵および拡張公開鍵は、周知の公開子鍵導出関数を使用して、導出された子鍵を生成するために使用され得る。

子鍵導出（ＣＫＤ）関数：例示的な子鍵導出（ＣＫＤ）関数は、ＢＩＰ３２において定義されており、所与の親秘密鍵または親公開鍵を使用して、それぞれ子秘密鍵または子公開鍵を導出することを可能にし、これは以下のように書くことができる：

ここで、ｉは、その兄弟間の子鍵のインデックスに対する３２バイトのインデックス値である。これらの関数の完全な定義は、ＢＩＰ３２において見つけることができる。秘密鍵（親または子）が与えられた場合、楕円曲線乗算などの単純な適用によって、対応する公開鍵（親または子）を生成することも自明であることに留意されたい。この事実は、一般に、所与の親秘密鍵からは子公開鍵と子秘密鍵の両方を導出することが可能であるが、所与の親公開鍵からは子公開鍵を導出することのみが可能であることを意味する。

ＨＤウォレットの鍵ツリーは、決定論的に、下方にトラバースすることしかできず、決して上方に行くことはできないことにも留意されたい。また、拡張公開鍵の場合、ハードニング（hardening）として知られているプロセスによって、下方に行く能力を制限することも可能である。

強化鍵：ＢＩＰ３２において、強化鍵を使用してＨＤウォレットを生成するオプション。これらの鍵は、拡張親公開鍵から強化拡張子公開鍵を生成する能力を排除し、これは、２^３２－１より大きいインデックスに対するＣＫＤ関数の定義を拡張することによって達成される。

マルチアカウント階層：ＢＩＰ４４に正式に導入されているのは、暗号通貨の使用に関連する異なるアカウントに対してＨＤウォレット内の鍵階層の異なる分岐およびレベルを使用するという概念である。しかしながら、すべての場合において、異なる「アカウント」は、実質的に同じ目的、すなわち、トランザクションに署名することによって暗号通貨を使用する目的のために鍵を定義する。

階層的決定論的ウォレット
以下では、楕円曲線暗号を用いる特定の実施形態の文脈において階層的決定論的ウォレットのいくつかのさらなる議論について説明する。図１１を参照する。

ＥＣ点乗算の準同型性（homomorphic property）は、ＨＤウォレットに影響を与える。これにより、対応する子公開鍵Ｓ_{ｃｈｉｌｄ}を知ることも格納することもなく、親公開鍵Ｐ_{Ｐａｒｅｎｔ}から子公開鍵Ｐ_{ｃｈｉｌｄ}を連続的に構築することができる。

図１１は、階層的決定論的（ＨＤ）ウォレットにおいて親鍵ペアに対する動作からどのように子鍵ペアが構築されるかを示す。

図１１は、ＨＤウォレットフレームワークにおいて親から子の秘密鍵および公開鍵を生成するための例示的な機構を示す。

これは、それぞれ以下のように定義される拡張秘密鍵または拡張公開鍵のいずれかを使用して行うことができる：

ここで、Ｃは、チェーンコードとして知られるランダムエントロピー成分である。兄弟鍵を互いに区別するために、追加のインデックスが階層内の所与のレベルで各鍵に割り当てられている。このインデックスは図面では省略されているが、通常はＨＭＡＣ－ＳＨＡ５１２プリイメージの一部として使用される。

ケース１：拡張秘密鍵を使用する。拡張秘密鍵ＥＳ_{ｐａｒｅｎｔ}が与えられると、子鍵ペアの秘密鍵Ｓ_{ｃｈｉｌｄ}および公開鍵Ｐ_{ｃｈｉｌｄ}の両方を構築することができる。図面によれば、これらは、次のように定義および計算される：

ここで、Ｈは、暗号ハッシュ関数（例えば、ＨＭＡＣ－ＳＨＡ５１２）を示し、ＬＨＳは、Ｈの５１２ビット出力の左端２５６ビットを示す。

ここでは、拡張された親秘密鍵が与えられ、図面で概説されているプロセスを使用して、子鍵ペアの両方の部分を計算することができた。

ケース２：拡張公開鍵を使用する。拡張公開鍵ＥＰ_{ｐａｒｅｎｔ}が与えられると、次のように公開鍵Ｐ_{ｃｈｉｌｄ}のみを構築することができる：

この結果の導出は、楕円曲線秘密鍵－公開鍵ペアの準同型性に依拠する。導出は以下の通りである：

この公開鍵に対する対応する秘密鍵Ｓ_{ｃｈｉｌｄ}を導出することは、その親の拡張公開鍵ＥＰ_{ｐａｒｅｎｔ}：＝（Ｐ_{Ｐａｒｅｎｔ}||Ｃ_{ｐａｒｅｎｔ}）のみ与えられてもＳ_{ｐａｒｅｎｔ}が必要であるので、不可能であることが分かる。この理由は、Ｈの出力の左端の数字によって与えられる決定論的部分に親秘密鍵を追加しなければならないからであり、図面から見て取れる。

Ｓ_{ｃｈｉｌｄ}を見つける唯一の他の方法は、楕円曲線点乗算アルゴリズムを「反転」させることであるが、これは現在のところ至難な問題である。

対応する秘密鍵を見る、知る、または格納する必要なしに子公開鍵を生成することは、ストレージ要件を低減し、支払いを受け取るためのブロックチェーンアドレスを生成するために秘密鍵を格納する必要がないはるかに安全なウォレット実装に使用可能であるので、有利である。

この効果は、ＥＣ点乗算の準同型性およびＥＣＣ鍵ペアの基本的特性の直接的な結果である。

完全を期すために、図１２には、子公開鍵がどのようにして拡張公開鍵から生成され得るかの例を示す。

結論
上記の実施形態は、単に例として説明されていることが理解されよう。

例えば、上記の例では、オーバーレイ層リンクがメタネットトランザクションのペイロードにおいて（例えば、図４の例におけるＴｘＩＤ_ｎｏｄｅの出力におけるＴｘＩＤ_{ｐａｒｅｎｔ}によって）定義されることが説明されている。しかしながら、これは必須ではない。代替的な実施形態では、グラフ構造は、実際に、オンチェーンで宣言される必要はなく、または少なくとも完全にそうである必要はない。例えば、いくつかのデータ構造がブロックチェーン上に格納されるが、オーバーレイ層リンクがオフチェーンで格納され得る場合、メタネットの変形が提供され得る。データストレージトランザクションの入力に署名する鍵の階層は、データ構造（の大部分）を回復するのに依然として十分であるが、シードを知っている者のみに対してであり、すなわちブロックチェーンを見ている一般公衆に対してではないので、プライバシーを向上させる。さらなる変形例では、メタネット（または他のそのようなオーバーレイネットワーク）のグラフ構造は、完全にオフチェーンで定義され得、データコンテンツのみがオンチェーンで格納される。

さらに、上記はツリー構造に関して説明されているが、より一般的には、任意のグラフ構造に同じ原理を適用することができる。例えば、所与のノード３０１は２つの親を有することができる。この場合、対応する鍵は２つの親鍵から導出されることとなる。

より一般的には、以下のステートメントのうちのいずれか１つまたは複数による方法、装置、またはプログラムが提供され得る。

ステートメント１：ブロックチェーンのデータストレージトランザクションにオーバーレイされたオーバーレイネットワークを管理する方法であって、オーバーレイネットワークのデータコンテンツがデータストレージトランザクションのペイロードに格納され、オーバーレイ層リンクがデータストレージトランザクション間で定義され、方法は、第１のコンピュータ機器上で実行される第１のソフトウェアモジュールによって、以下を行うことを含む：
オーバーレイネットワークのグラフ構造を識別すること、ここで、グラフ構造は複数のノードとノード間のエッジとを含み、ノードの各々はデータストレージトランザクションのうちの異なるそれぞれ１つに対応し、エッジの各々はリンクのうちの異なるそれぞれ１つに対応し、各ノードは、ブロックチェーンへの子の書き込みを認可するために、オーバーレイネットワークのグラフ構造における子データストレージトランザクションの入力に署名するためのそれぞれの第１の鍵に関連付けられ、第１の鍵は第１のシードから生成される、および
第２のシードに適用される子鍵導出（ＣＫＤ）関数を使用して、オーバーレイネットワークと同じグラフ構造を有する第２の鍵の階層セットを決定すること、ここで、各第２の鍵は、グラフ構造においてそれぞれのデータストレージトランザクションと同じ位置にあるノードのうちの異なるそれぞれ１つに対応し、第２の鍵は、データストレージトランザクションの入力に署名するために使用されるのではなく、代わりに追加の機能を有効にするために提供される。

オーバーレイネットワークの上記グラフ構造は、オーバーレイネットワークの一部または全部の構造であり得る。

各鍵は、公開鍵－秘密鍵ペアの秘密鍵、または公開鍵－秘密鍵ペアの公開鍵、またはその両方を含み得る。

ＣＫＤを親またはシードに適用することによって階層鍵セットが導出されるといわれる場合、これは、ＣＫＤへの唯一の入力が親鍵またはシード（公開親鍵であるか秘密親鍵であるかにかかわらず）でなければならないことを必ずしも意味しないことにも留意されたい。例えば、実施形態では、ＣＫＤは、入力パラメータとしてチェーンコードおよび／またはインデックス値を取ることもできる。

ステートメント２：ステートメント１に記載の方法であって、以下をさらに含む：
第１のシードに適用されるＣＫＤ関数を使用して、第１の鍵を、オーバーレイネットワークおよび第２の鍵セットと同じグラフ構造を有する階層鍵セットの鍵として決定すること、ここで、各第１の鍵は、グラフ構造においてそれぞれのノードと同じ位置にあるノードのうちの異なるそれぞれ１つに対応する。

ステートメント３：ステートメント１または２に記載の方法であって、以下をさらに含む：
第１のソフトウェアモジュールから、グラフ構造における位置のうちの１つの指示を第２のソフトウェアモジュールに通信し、したがって、第２のソフトウェアモジュールが、通信された位置と、第１のシードと、第１の鍵に使用されるＣＫＤ関数とに基づいて、その位置にあるノードのそれぞれの第１の鍵を決定することを可能にすること。

ステートメント４：第１のシードも第２のソフトウェアモジュールに通信され、第２のモジュールによる上記決定は、第２のモジュールに通信された第１のシードに基づく、ステートメント３に記載の方法。

これは、第１のソフトウェアモジュール、または、例えば、別個の第三者のコンピュータ機器上で実行されるか、第１もしくは第２のソフトウェアモジュールと同じ機器上で実行されるが、第１および第２のモジュールから分離される第３のソフトウェアモジュールから通信され得る。

ステートメント５：第１のシードは第２のソフトウェアモジュールに事前に知られており、第２のモジュールによる決定は第１のシードの事前知識に基づく、ステートメント３に記載の方法。

ステートメント６：第１の鍵に使用されるＣＫＤ関数の指示も第２のソフトウェアモジュールに通信され、第２のモジュールによる上記決定は、第１のソフトウェアモジュールによって示されたＣＫＤ関数に基づく、ステートメント３、４または５に記載の方法。

同様に、これは、第１のソフトウェアモジュール、または、例えば、別個の第三者のコンピュータ機器上で実行されるか、第１もしくは第２のソフトウェアモジュールと同じ機器上で実行されるが、第１および第２のモジュールから分離される第３のソフトウェアモジュールから通信され得る。

ステートメント７：ＣＫＤ関数は第２のソフトウェアモジュールに事前に知られており、第２のモジュールによる決定はＣＫＤ関数の事前知識に基づく、ステートメント３、４または５に記載の方法。

ステートメント８：第１の鍵の各々は、ブロックチェーンへのそれぞれの子データストレージトランザクションの書き込みを認可する、先行ステートメントのいずれかに記載の方法。

ステートメント９：データストレージトランザクションのうちの１つまたは複数の各々は、別のトランザクションのそれぞれのファンディング出力を指し示すそれぞれの入力を含み、それぞれの入力はそれぞれのロック解除スクリプトを含み、それぞれのロックスクリプトは、ブロックチェーンへの記録のためにそれぞれのデータストレージトランザクションを妥当性確認するために、オーバーレイグラフ構造におけるそれぞれの親データストレージトランザクションの第１の鍵に基づく暗号署名がそれぞれのロック解除スクリプトに含まれることを必要とする、先行ステートメントのいずれかに記載の方法。

ステートメント１０：各それぞれのファンディング出力は、それぞれの親データストレージトランザクション以外のそれぞれのファンディングトランザクションの出力である、ステートメント９に記載の方法。

ステートメント１１：各ファンディングトランザクションの入力は、ブロックチェーンへの記録のためにファンディングトランザクションを妥当性確認させるために、それぞれのファンディング鍵に基づく暗号署名を含み、それぞれのファンディングトランザクションの出力は、ブロックチェーンへのそれぞれのデータストレージトランザクションの記録にファンディングするためのデジタル資産の額を指定する、ステートメント１０に記載の方法。

ステートメント１２：上記リンクの各々は、上記データストレージトランザクションのうちの親と子との間のリンクであり、リンクは、子のペイロードに親のそれぞれのトランザクションＩＤを含めることによってオーバーレイ層において形成される、先行ステートメントのいずれかに記載の方法。

例えば、親のトランザクションＩＤは、それぞれの子データストレージトランザクションの使用不可能な出力に含まれ得る。いくつかの実施形態では、そのような出力は、スクリプトを終了させるオペコードをロックスクリプトに含めることによって、使用不可能にされ得る。例えば、これは、スクリプト言語のＯＰ＿ＲＥＴＵＲＮオペコードであろう。

ステートメント１３：第２のソフトウェアモジュールは、第２のシードへのアクセスが与えられない、先行する請求項のいずれかに記載の方法。

ステートメント１４：第２の鍵は難読化鍵であり、上記追加の機能は、それぞれのノードのそれぞれのデータストレージトランザクションのデータコンテンツを難読化および／または難読化解除することを含む、先行ステートメントのいずれかに記載の方法。

ステートメント１５：難読化鍵は暗号化鍵であり、上記追加の機能は、それぞれのノードのそれぞれのデータストレージトランザクションのデータコンテンツを暗号化および／または解読することを含む、ステートメント１４に記載の方法。

ステートメント１６：第２の鍵はファンディング鍵であり、上記追加の機能は、ブロックチェーンに記録されるべきそれぞれのノードのそれぞれのデータストレージトランザクションにファンディングすることを含む、ステートメント１から１３のいずれかに記載の方法。

ステートメント１７：第２の鍵はアプリケーション層鍵であり、上記追加の機能は、それぞれのノードのそれぞれのデータストレージトランザクションに関連して実行されるべきアプリケーション層機能を含む、ステートメント１から１３のいずれかに記載の方法。

例えば、第２の鍵の各々は、例えば、得る冪等目的で使用される、それぞれのノードのそれぞれのデータ格納トランザクションの異なるそれぞれのアプリケーション層シリアル番号であり得る。

ステートメント１８：先行ステートメントのいずれかに記載の方法であって、以下をさらに含む：
第３のシードに適用されるＣＫＤアルゴリズムを使用して、オーバーレイネットワークおよび第２の鍵のセットと同じグラフ構造を有する第３の鍵の階層セットを決定すること、ここで、各第３の鍵は、グラフ構造においてそれぞれのノードと同じ位置にあるノードのうちの異なるそれぞれ１つに対応し、第３の鍵は、第３の機能を有効にするためのものである。

ステートメント１９：少なくとも第１のシードおよび第２のシードは同じマスタシードから導出される、先行ステートメントのいずれかに記載の方法。

ステートメント２０：第２のソフトウェアモジュールは、第１のコンピュータ機器とは別個の第２のコンピュータ機器上で実行される、先行ステートメントのいずれかに記載の方法。

ステートメント２１：第１のコンピュータ機器は第１の当事者のコンピュータ機器であり、第２のコンピュータ機器は第１の当事者とは別個の第２の当事者のコンピュータ機器である、ステートメント２０に記載の方法。

ステートメント２２：方法は、第２の当事者に第２の鍵を明らかにせずに、データストレージトランザクションのうちの１つまたは複数をブロックチェーンに記録させることを第２の当事者に委託するために、第１の当事者によって使用される、ステートメント２１に記載の方法。

ステートメント２３：方法は、第２の当事者がそこに格納されたデータコンテンツを難読化解除することを可能にせずに、データストレージトランザクションのうちの１つまたは複数をブロックチェーン上に記録させることを第２の当事者に委託するために第１の当事者によって使用される、ステートメント１４または１５に従属するステートメント２２に記載の方法。

ステートメント２４：第２のソフトウェアモジュールは、第１のソフトウェアモジュールと同じ第１のコンピュータ機器上で実行される、ステートメント１から１９のいずれかに記載の方法。

例えば、これは、第１のソフトウェアモジュールが破壊またはハッキングされた場合に第２の鍵が危険にさらされることを防止し、それによって、第１のモジュールの機能を第２のモジュールから分離させておくために使用され得る。

ステートメント２５：データコンテンツは、データストレージトランザクションのうちの１つまたは複数の使用不可能な出力に格納される、先行する請求項のいずれかに記載の方法。

例えば、そのような出力は、スクリプトを終了させるオペコードをロックスクリプトに含めることによって、使用不可能にされ得る。例えば、これは、スクリプト言語のＯＰ＿ＲＥＴＵＲＮオペコードであろう。

ステートメント２６：オーバーレイ層リンクは、データストレージトランザクションのペイロードの中に格納される、先行する請求項のいずれかに記載の方法。

ステートメント２７：グラフ構造はツリー構造である、先行する請求項のいずれかに記載の方法。

ステートメント２８：コンピュータ可読ストレージ上に具現化され、実行されると、先行ステートメントのいずれかに記載の方法にしたがって動作を実行するように構成されたコードを含むコンピュータプログラム製品。

ステートメント２９：以下を備えるコンピュータ機器：
１つまたは複数のメモリユニットを備えるメモリ、および
１つまたは複数の処理ユニットを含む処理装置、
ここで、メモリは、１つまたは複数の処理ユニット上で実行するように構成され、実行されると、ステートメント１から２７のいずれかに記載の方法を実行するように構成された第１のソフトウェアモジュールを記憶する。

ステートメント３０：方法であって、第２のソフトウェアモジュールによって、以下を行うことを含む：
オーバーレイネットワークを表すグラフ構造におけるノードの位置の指示を第１のソフトウェアモジュールから受信すること、ここで、オーバーレイネットワークのデータコンテンツはブロックチェーン上のデータストレージトランザクションのペイロードに格納され、オーバーレイ層リンクはデータストレージトランザクション間で定義され、グラフ構造は複数のノードとノード間のエッジとを含み、ノードの各々はデータストレージトランザクションのうちの異なるそれぞれ１つに対応し、エッジの各々はリンクのうちの異なるそれぞれ１つに対応する、
指示された位置を使用して、第１の鍵の階層セットの中から鍵を決定すること、ここで、鍵の階層セットは、オーバーレイネットワークと同じグラフ構造を有し、各第１の鍵は、グラフ構造においてそれぞれのデータストレージトランザクションと同じ位置にあるノードのうちの異なるそれぞれ１つに対応し、上記決定することは、指示された位置にあるノードのそれぞれの鍵を、その位置と、上記セット鍵に使用されるＣＫＤ関数およびシードとに基づいて決定することを含む、ならびに
決定された鍵を使用して、データストレージトランザクションの入力に署名すること以外のそれぞれのデータストレージトランザクションに関連して機能を実行すること。

ステートメント３１：コンピュータ可読ストレージ上に具現化され、実行されると、ステートメント３０に記載の方法にしたがって動作を実行するように構成されたコードを含むコンピュータプログラム製品。

ステートメント３２：以下を備えるコンピュータ機器：
１つまたは複数のメモリユニットを備えるメモリ、および
１つまたは複数の処理ユニットを含む処理装置、
ここで、メモリは、１つまたは複数の処理ユニット上で実行するように構成され、実行されると、ステートメント３０に記載の方法を実行するように構成された第２のソフトウェアモジュールを記憶する。

本明細書で開示される別の態様によれば、第１および第２のソフトウェアモジュールの両方の動作を含む方法が提供され得る。

本明細書で開示される別の態様によれば、第１および第２のソフトウェアモジュールの両方を含む、コンピュータ可読ストレージ上に具現化されたコンピュータプログラム製品が提供され得る。

本明細書で開示される別の態様によれば、第１および第２のコンピュータ機器を備えるシステムが提供され得る。

開示された技法の他の変形例または使用事例は、本明細書の開示が与えられると、当業者に明らかになり得る。本開示の範囲は、説明された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。

Claims (32)

1. ブロックチェーンのデータストレージトランザクションにオーバーレイされたオーバーレイネットワークを管理する方法であって、前記オーバーレイネットワークのデータコンテンツが前記データストレージトランザクションのペイロードに格納され、オーバーレイ層リンクが前記データストレージトランザクション間で定義され、前記方法は、第１のコンピュータ機器上で実行される第１のソフトウェアモジュールによって、
   前記オーバーレイネットワークのグラフ構造を識別することと、ここで、前記グラフ構造は複数のノードとノード間のエッジとを含み、前記ノードの各々は前記データストレージトランザクションのうちの異なるそれぞれ１つに対応し、前記エッジの各々は前記リンクのうちの異なるそれぞれ１つに対応し、各ノードは、前記ブロックチェーンへの子の書き込みを認可するために、前記オーバーレイネットワークの前記グラフ構造における子データストレージトランザクションの入力に署名するためのそれぞれの第１の鍵に関連付けられ、前記第１の鍵は第１のシードから生成され、
   第２のシードに適用される子鍵導出（ＣＫＤ）関数を使用して、前記オーバーレイネットワークと同じグラフ構造を有する第２の鍵の階層セットを決定することと、ここで、各第２の鍵は、前記グラフ構造において前記それぞれのデータストレージトランザクションと同じ位置にある前記ノードのうちの異なるそれぞれ１つに対応し、前記第２の鍵は、前記データストレージトランザクションの入力に署名するために使用されるのではなく、代わりに追加の機能を有効にするために提供される、
   を含む、方法。
2. 前記第１のシードに適用されるＣＫＤ関数を使用して、前記第１の鍵を、前記オーバーレイネットワークおよび前記第２の鍵セットと同じグラフ構造を有する階層鍵セットの鍵として決定することをさらに含み、ここで、各第１の鍵は、前記グラフ構造において前記それぞれのノードと同じ位置にある前記ノードのうちの異なるそれぞれ１つに対応する、
   請求項１に記載の方法。
3. 前記第１のソフトウェアモジュールから、前記グラフ構造における前記位置のうちの１つの指示を第２のソフトウェアモジュールに通信し、したがって、前記第２のソフトウェアモジュールが、前記通信された位置と、前記第１のシードと、前記第１の鍵に使用される前記ＣＫＤ関数とに基づいて、その位置にある前記ノードの前記それぞれの第１の鍵を決定することを可能にすること
   をさらに含む、請求項１または２に記載の方法。
4. 前記第１のシードも前記第２のソフトウェアモジュールに通信され、前記第２のモジュールによる前記決定は、前記第２のモジュールに通信された前記第１のシードに基づく、請求項３に記載の方法。
5. 前記第１のシードは前記第２のソフトウェアモジュールに事前に知られており、前記第２のモジュールによる前記決定は前記第１のシードの事前知識に基づく、請求項３に記載の方法。
6. 前記第１の鍵に使用される前記ＣＫＤ関数の指示も第２のソフトウェアモジュールに通信され、前記第２のモジュールによる前記決定は、前記第１のソフトウェアモジュールによって示された前記ＣＫＤ関数に基づく、請求項３、４または５に記載の方法。
7. 前記ＣＫＤ関数は前記第２のソフトウェアモジュールに事前に知られており、前記第２のモジュールによる前記決定は前記ＣＫＤ関数の事前知識に基づく、請求項３、４または５に記載の方法。
8. 前記第１の鍵の各々は、前記ブロックチェーンへの前記それぞれの子データストレージトランザクションの書き込みを認可する、請求項１から７のいずれか一項に記載の方法。
9. 前記子データストレージトランザクションのうちの１つまたは複数の各々は、別のトランザクションのそれぞれのファンディング出力を指し示すそれぞれの入力を含み、前記それぞれの入力はそれぞれのロック解除スクリプトを含み、前記それぞれのファンディング出力はそれぞれのロックスクリプトを含み、前記それぞれのロックスクリプトは、前記ブロックチェーンへの記録のために前記それぞれのデータストレージトランザクションを妥当性確認するために、前記オーバーレイグラフ構造におけるそれぞれの親データストレージトランザクションの前記第１の鍵に基づく暗号署名が前記それぞれのロック解除スクリプトに含まれることを必要とする、請求項１から８のいずれか一項に記載の方法。
10. 各それぞれのファンディング出力は、前記それぞれの親データストレージトランザクション以外のそれぞれのファンディングトランザクションの出力である、請求項９に記載の方法。
11. 各ファンディングトランザクションの前記入力は、前記ブロックチェーンへの記録のために前記ファンディングトランザクションを妥当性確認させるために、それぞれのファンディング鍵に基づく暗号署名を含み、前記それぞれのファンディングトランザクションの前記出力は、前記ブロックチェーンへの前記それぞれのデータストレージトランザクションの記録にファンディングするためのデジタル資産の額を指定する、請求項１０に記載の方法。
12. 前記リンクの各々は、前記データストレージトランザクションのうちの親と子との間のリンクであり、前記リンクは、前記子の前記ペイロードに前記親のそれぞれのトランザクションＩＤを含めることによって前記オーバーレイ層において形成される、請求項１から１１のいずれか一項に記載の方法。
13. 前記第２のソフトウェアモジュールは、前記第２のシードへのアクセスが与えられない、請求項１から１２のいずれか一項に記載の方法。
14. 前記第２の鍵は難読化鍵であり、前記追加の機能は、前記それぞれのノードの前記それぞれのデータストレージトランザクションのデータコンテンツを難読化および／または難読化解除することを含む、請求項１から１３のいずれか一項に記載の方法。
15. 前記難読化鍵は暗号化鍵であり、前記追加の機能は、前記それぞれのノードの前記それぞれのデータストレージトランザクションのデータコンテンツを暗号化および／または解読することを含む、請求項１４に記載の方法。
16. 前記第２の鍵はファンディング鍵であり、前記追加の機能は、前記ブロックチェーンに記録されるべき前記それぞれのノードの前記それぞれのデータストレージトランザクションにファンディングすることを含む、請求項１から１３のいずれか一項に記載の方法。
17. 前記第２の鍵はアプリケーション層鍵であり、前記追加の機能は、前記それぞれのノードの前記それぞれのデータストレージトランザクションに関連して実行されるべきアプリケーション層機能を含む、請求項１から１３のいずれか一項に記載の方法。
18. 第３のシードに適用されるＣＫＤアルゴリズムを使用して、前記オーバーレイネットワークおよび第２の鍵のセットと同じグラフ構造を有する第３の鍵の階層セットを決定することをさらに含み、ここで、各第３の鍵は、前記グラフ構造において前記それぞれのノードと同じ位置にある前記ノードのうちの異なるそれぞれ１つに対応し、前記第３の鍵は、第３の機能を有効にするためのものである、
    請求項１から１７のいずれか一項に記載の方法。
19. 少なくとも前記第１のシードおよび第２のシードは同じマスタシードから導出される、請求項１から１８のいずれか一項に記載の方法。
20. 前記第２のソフトウェアモジュールは、前記第１のコンピュータ機器とは別個の第２のコンピュータ機器上で実行される、請求項１から１９のいずれか一項に記載の方法。
21. 前記第１のコンピュータ機器は第１の当事者のコンピュータ機器であり、前記第２のコンピュータ機器は前記第１の当事者とは別個の第２の当事者のコンピュータ機器である、請求項２０に記載の方法。
22. 前記方法は、前記第２の当事者に前記第２の鍵を明らかにせずに、前記データストレージトランザクションのうちの１つまたは複数を前記ブロックチェーンに記録させることを前記第２の当事者に委託するために、前記第１の当事者によって使用される、請求項２１に記載の方法。
23. 前記方法は、前記第２の当事者がそこに格納された前記データコンテンツを難読化解除することを可能にせずに、前記データストレージトランザクションのうちの１つまたは複数を前記ブロックチェーン上に記録させることを前記第２の当事者に委託するために前記第１の当事者によって使用される、請求項１４または１５に従属する請求項２２に記載の方法。
24. 前記第２のソフトウェアモジュールは、前記第１のソフトウェアモジュールと同じ第１のコンピュータ機器上で実行される、請求項１から１９のいずれか一項に記載の方法。
25. 前記データコンテンツは、前記データストレージトランザクションのうちの１つまたは複数の使用不可能な出力に格納される、請求項１から２４のいずれか一項に記載の方法。
26. 前記オーバーレイ層リンクは、前記データストレージトランザクションの前記ペイロードの中に格納される、請求項１から２５のいずれか一項に記載の方法。
27. 前記グラフ構造はツリー構造である、請求項１から２６のいずれか一項に記載の方法。
28. コンピュータ可読ストレージ上に具現化され、実行されると、請求項１から２７のいずれか一項に記載の方法にしたがって動作を実行するように構成されたコードを含むコンピュータプログラム製品。
29. コンピュータ機器であって、
    １つまたは複数のメモリユニットを備えるメモリと
    １つまたは複数の処理ユニットを含む処理装置と
    を備え、
    ここで、前記メモリは、前記１つまたは複数の処理ユニット上で実行するように構成され、実行されると、請求項１から２７のいずれか一項に記載の方法を実行するように構成された第１のソフトウェアモジュールを記憶する、
    コンピュータ機器。
30. 方法であって、第２のソフトウェアモジュールによって
    オーバーレイネットワークを表すグラフ構造におけるノードの位置の指示を第１のソフトウェアモジュールから受信することと、前記オーバーレイネットワークのデータコンテンツはブロックチェーン上の前記データストレージトランザクションのペイロードに格納され、オーバーレイ層リンクは前記データストレージトランザクション間で定義され、前記グラフ構造は複数のノードとノード間のエッジとを含み、前記ノードの各々は前記データストレージトランザクションのうちの異なるそれぞれ１つに対応し、前記エッジの各々は前記リンクのうちの異なるそれぞれ１つに対応し、
    前記指示された位置を使用して、第１の鍵の階層セットの中から鍵を決定することと、ここで、鍵の前記階層セットは、前記オーバーレイネットワークと同じグラフ構造を有し、各第１の鍵は、前記グラフ構造において前記それぞれのデータストレージトランザクションと同じ位置にある前記ノードのうちの異なるそれぞれ１つに対応し、前記決定することは、前記指示された位置にある前記ノードの前記それぞれの鍵を、その位置と、前記セット鍵に使用される前記ＣＫＤ関数および前記シードとに基づいて決定することを含み、
    前記決定された鍵を使用して、前記データストレージトランザクションの入力に署名すること以外の前記それぞれのデータストレージトランザクションに関連して機能を実行することと
    を含む方法。
31. コンピュータ可読ストレージ上に具現化され、実行されると、請求項３０に記載の方法にしたがって動作を実行するように構成されたコードを含むコンピュータプログラム製品。
32. コンピュータ機器であって、
    １つまたは複数のメモリユニットを備えるメモリと、
    １つまたは複数の処理ユニットを含む処理装置と
    を備え、
    前記メモリは、前記１つまたは複数の処理ユニット上で実行するように構成され、実行されると、請求項３０に記載の方法を実行するように構成された第２のソフトウェアモジュールを記憶する、
    コンピュータ機器。

Images