JP7828353B2 - ブロックチェーン木構造 - Google Patents

Description

本開示は、ブロックチェーンにオーバーレイされた木構造の様々なバージョンを作成する方法、および木構造のバージョンにアクセスする方法に関する。

ブロックチェーンとは、ある形式の分散型データ構造を指し、ブロックチェーンの複製は、分散型ピアツーピア(P2P)ネットワーク(以下では「ブロックチェーンネットワーク」と呼ばれる)の中の複数のノードの各々において維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを備え、各ブロックは、1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションまでの1つまたは複数のブロックにまたがり得るシーケンスの中の先行するトランザクションを指し示す。コインベーストランザクションについて、以下でさらに説明する。ブロックチェーンネットワークに出されるトランザクションは、新しいブロックに含まれる。新しいブロックは「マイニング」と呼ばれることが多い処理により作成され、これは、複数のノードの各々が競争して「プルーフオブワーク」を実行すること、すなわち、ブロックチェーンの新しいブロックに含められることを待機している、順序付けられ妥当性確認された未処理のトランザクションの定義されたセットの表現に基づいて、暗号パズルを解くことを伴う。ブロックチェーンはいくつかのノードにおいて枝刈りされてもよく、ブロックの公開はブロックヘッダだけの公開により達成され得ることに留意されたい。

ブロックチェーンにおけるトランザクションは、以下の目的、すなわちデジタル資産(すなわち、ある数のデジタルトークン)を運ぶこと、仮想化された台帳もしくは登録簿のエントリのセットを順序付けること、タイムスタンプエントリを受け取り処理すること、および/またはインデックスポインタを時間的に順序付けることのうちの、1つまたは複数のために使用され得る。ブロックチェーンは、ブロックチェーンに追加の機能を重ねるためにも利用され得る。たとえば、ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータに対するインデックスの記憶を可能にし得る。単一のトランザクションに記憶され得る最大のデータ容量にはあらかじめ指定された限界はないので、ますます複雑になるデータを組み込むことができる。たとえば、これは、ブロックチェーンの中の電子文書、またはオーディオデータもしくはビデオデータを記憶するために使用され得る。

ブロックチェーンネットワークのノード(「マイナー」と呼ばれることが多い)は、後でより詳しく説明される、分散型のトランザクションの登録および検証のプロセスを実行する。要約すると、この処理の間に、ノードはトランザクションを妥当性確認し、それらをブロックテンプレートに挿入し、ノードはそのブロックテンプレートについて有効なプルーフオブワークの解を特定することを試みる。有効な解が見つかると、新しいブロックがネットワークの他のノードに広められるので、各ノードがブロックチェーンに新しいブロックを記録することを可能にする。トランザクションがブロックチェーンに記録されるようにするために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)は、トランザクションが広められるように、それをネットワークのノードのうちの1つに送信する。トランザクションを受信するノードは競って、妥当性確認されたトランザクションを新しいブロックへ組み込むプルーフオブワークの解を見つけることができる。各ノードは同じノードプロトコルを実施するように構成され、これは、トランザクションが有効になるための1つまたは複数の条件を含む。無効なトランザクションは、広められることも、ブロックに組み込まれることもない。トランザクションが妥当性確認され、それによりブロックチェーン上で受け入れられると仮定すると、トランザクション(あらゆるユーザデータを含む)は、イミュータブルな公開記録としてブロックチェーンネットワークの中のノードの各々において登録されインデクシングされたままになる。

最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは通常、ある額のデジタル資産、すなわちある数のトークンを分配する「コインベーストランザクション」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出および拒絶は、ネットワークのエージェントとして活動し不正を報告して阻止する動機のある、競合するノードの活動によって実施される。情報を広く公開することで、ユーザはノードの実績を継続的に監査することが可能になる。ブロックヘッダのみの公開により、参加者はブロックチェーンの完全性が継続中であることを確実にすることが可能になる。

「出力ベース」モデル(UTXOベースのモデルと呼ばれることがある)では、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を備える。あらゆる消費可能な出力は、トランザクションの先行するシーケンスから導出可能であるデジタル資産の額を指定する要素を備える。消費可能な出力は、UTXO(「未消費トランザクション出力」)と呼ばれることがある。出力はさらに、出力のさらなる引き換えのための条件を指定するロックスクリプトを備え得る。ロックスクリプトは、デジタルトークンまたは資産を妥当性確認して移すために必要な条件を定義する述部である。トランザクション(コインベーストランザクション以外)の各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち、参照)を備え、指し示された出力のロックスクリプトのロックを解除するためのロック解除スクリプトをさらに備え得る。よって、トランザクションのペアを考え、それらを第1のトランザクションおよび第2のトランザクション(または「ターゲット」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定し、出力をアンロッキンングする1つまたは複数の条件を定義するロックスクリプトを備える、少なくとも1つの出力を備える。第2のターゲットトランザクションは、第1のトランザクションの出力へのポインタと、第1のトランザクションの出力のロックを解除するためのロック解除スクリプトとを備える、少なくとも1つの入力を備える。

そのようなモデルでは、第2のターゲットトランザクションが、ブロックチェーンにおいて広められて記録されるようにブロックチェーンネットワークに送信されるとき、各ノードにおいて適用される有効性の基準の1つは、ロック解除スクリプトが第1のトランザクションのロックスクリプトにおいて定義される1つまたは複数の条件のすべてを満たすというものである。別の基準は、第1のトランザクションの出力が別のより前の有効なトランザクションによってまだ引き換えられていないということである。これらの条件のいずれかに従ってターゲットトランザクションが無効であることを見出したいずれのノードも、トランザクションを広めず(場合によっては無効なトランザクションを登録するために有効なトランザクションとして広めない)、またブロックチェーンに記録されるべき新しいブロックにトランザクションを含めない。

代替的なタイプのトランザクションモデルは、アカウントベースモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別のノードによって記憶され、定期的に更新される。

ブロックチェーンネットワークはすでに、インターネットなどの下にあるネットワーク上にオーバーレイされたオーバーレイネットワークの一タイプである。しかしながら、ブロックチェーン上にオーバーレイネットワークのさらなるレイヤをオーバーレイすることも可能である。この一例が、Metanetとして知られている。Metanetの各ノードは、ブロックチェーン上の異なるトランザクションである(「ノード」は今異なる意味で使用されており、ブロックチェーンネットワークのノードを指すのではなく、Metanetのノードを指すことに留意する)。データコンテンツおよびMetanetメタデータは、そのような各トランザクションのペイロードに、OP_RETURNを用いてまたはOP_PUSHDATAのような他の手段によってトランザクションの支出不可(unspendable)出力において、記憶される。データコンテンツは、Metanetがたとえばテキスト、画像、ビデオ、または音声コンテンツなどを記憶するために使用されている実際のユーザコンテンツであるが、メタデータは、Metanetノード間のリンクを定義する。Metanetノード間のリンクまたはエッジは、必ずしもブロックチェーンレイヤにおいて支出エッジ(spending edge)に対応するとは限らない。すなわち、所与のMetanetトランザクションの入力が、ブロックチェーンレイヤにおいて別の、資金提供トランザクション(funding transaction)の出力を指し示す場合、その同じトランザクションの親またはMetanetレイヤにおけるMetanetノードは、必ずしも資金提供トランザクションと同じトランザクションとは限らない。代わりにMetanetレイヤにおけるリンクまたはエッジは、Metanetのデータコンテンツ間のリンクを定義する。

Metanetは、静的構造であるように設計され、ここで、新しいノードが木に追加されるとき、それは除去され得ない。ノードは、異なる技法を使用すること(たとえば、相対的UTXOを支出すること)は無効であると見なされ得るが、ノードは、木から分離され得ない(リンクは、取り消され得ない)。これは、木が頻繁に更新されるときに制約となり得る。なぜならば、木は著しく成長し、ウォレットアプリケーションおよび他のアプリケーションは無効なノードを含めてすべてのノードをダウンロードして処理しなければならないからである。同様の検討が、Metanetのみでなく、ブロックチェーンにオーバーレイされたオーバーレイネットワークの他の形態に適用し得る。

本開示は、グラフ構造の異なるバージョン(すなわち、表示)を作成するために使用され得るMetanetベースのグラフなど、ブロックチェーンにオーバーレイされたグラフ構造に基づいて解を提示する。「木構造」という用語は、「グラフ構造」という用語と交換可能に使用されることに留意されたい。これらの用語は、それぞれ、木およびグラフに短縮され得る。たとえば、実施形態では、Metanetフラックスプロトコル(MFP)と本明細書では呼ばれる新しいMetanetプロトコルは、Metanetグラフの異なるバージョンが、たとえば、グラフにアクセスしているユーザに応じて、作成およびアクセスされることを可能にする。いくつかの例では、グラフのバージョンは、グラフがアクセスされる時間および/または日に依存し得る。言い換えれば、単一の静的構造を有することに限定されるMetanetグラフの代わりに、MFPは、変動する(たとえば、動的な)構造、したがって「フラックス」という用語の構造を可能にする。

動的な木は、いくつかのオフチェーン条件(たとえば、時間、ユーザ名)に従ってノードの作成を可能にする。したがって、時変の、カスタマイズ可能な、ユーザ固有の木が、作成され得る。これらの木は、各ユーザが、同じ木の異なるパーソナル化された表示(マルチビューの木)を有することができ、エッジが難読化され得るので、より高いプライバシーを提示する。さらに、それは、古い枝およびノードが、木構造から自動的に取り除かれ得るので、よりスケーラブルな構造を生成する。加えて、動的な木は、重みおよびプルーフオブワークをこれらの木に埋め込むために使用され得る。

本明細書で開示する一態様によれば、ブロックチェーンにオーバーレイされた木構造の異なるバージョンを作成するコンピュータ実装方法が提供され、木構造がノードのセットとノード間のエッジとを備え、各ノードがブロックチェーンに記録された異なるトランザクションであり、各エッジがそれぞれの子ノードからそれぞれの親ノードに接続し、親ノードの1つが木構造の根ノードであり、各ノードがそれぞれの鍵に関連付けられ、各子ノードが、i)それぞれのトランザクション識別子と、ii)それぞれの親ノードに関連付けられたそれぞれの鍵に対応する署名とを備え、方法は、木作成者によって実行され、ターゲット親ノードの1つまたは複数のターゲット子ノードを作成するステップであって、各ターゲット子ノードがそれぞれのデータペイロードを備える、ステップと、ターゲット子ノードの各々をそれぞれのリンク識別子に関連付けることによって各ターゲット子ノードとターゲット親ノードとの間にそれぞれのエッジを形成するステップとを備え、それぞれのリンク識別子は、少なくとも1つのオフチェーンパラメータに基づく。

上で言及されたように、木構造(たとえば、Metanet)の以前の実装形態は、単一のバージョンを有するように限定されている。すなわち、すべてのユーザは、木の同じノードを見る(すなわち、アクセスすることができる)。対照的に、本発明の実施形態は、同じ木の異なるバージョンの作成を可能にする。木の2つ以上のバージョンは、それらのバージョンが同じ根ノードを有する場合、同じ木のバージョンであると見なされる。根ノードは、以下で詳しく説明される。木作成者は、既存の親ノードの少なくとも1つの子ノードを作成する。親ノードは、根ノードであってもなくてもよい。木作成者は、各新しい子ノードと親ノードとの間にエッジを形成する。各エッジは、各子ノードをそれぞれのリンク識別子(ID)に関連付けることによって形成される。リンクIDは、子ノードを親ノードに接続するエッジ(すなわち、リンク)を識別する。各リンクIDは、1つまたは複数のオフチェーンパラメータに基づく。オフチェーンパラメータは、ブロックチェーンに固有でない任意のパラメータ(たとえば、ストリングまたは値)であり得る。オフチェーンパラメータは、代わりに、下にあるブロックチェーンプロトコルの一部として生成されない任意のパラメータとして定義され得る。

オフチェーンデータの例は、日、月、年、名前、住所、郵便番号、ユーザ名、メールアドレスなどを含む。対照的に、(トランザクションのコンテンツをハッシュすることによって生成される)トランザクション識別子は、オンチェーンパラメータの一例である。リンクIDは、トランザクション識別子に基づいてまだ生成され得るが、それはまた、1つまたは複数のオフチェーンパラメータ(たとえば、TxIDおよび日)に基づかなければならないことに留意されたい。

いくつかの実施形態では、唯一の子ノードが作成される。これは、子ノードが、1つの条件だけに従って、たとえば、特定の日に、または特定のユーザによって、アクセス可能であるべきときに有用であり得る。同様に、同じリンクIDを使用して親ノードに接続される、複数の子ノードが作成され得る。その場合、それらのノードは、同じ1つの条件だけに従ってアクセス可能である。これらの例の両方は、同じ木構造の複数のバージョンをまだ作成する。一バージョンでは子ノードが存在する一方で、他のバージョンでは子ノードが存在しない。たとえば、リンクIDは、特定の日(たとえば、月曜日)に基づいてもよい。ユーザは、そのリンクIDが本日に基づく親ノードの子ノードにアクセスすることを試みる。ユーザが、「月曜日」の日に基づくリンクIDを生成する場合、ノードが検索されることになる。対照的に、ユーザが、「火曜日」の日に基づくリンクIDを生成する場合、ノードは見つけられず、検索されないことになる。したがって、リンクIDは、月曜日にのみ有効であると見なされ得る。

他の実施形態では、木作成者は、同じ既存の親ノード(すなわち、既存のトランザクション)の複数の子ノードを作成する。新しい子ノードのうちの少なくとも2つが、異なるリンクIDに関連付けられ得る。したがって、木構造の少なくとも2つの異なるバージョンが作成され、したがって、新しい子ノードを親ノードにリンクするために使用されるリンクIDに応じてアクセスされ得る。たとえば、リンクIDは、ユーザ識別子(たとえば、ユーザ名)に基づいてもよい。ユーザ(または、機械)が木構造にアクセスするとき、ユーザは、それらのユーザ名に基づくリンクIDを有する子ノードのみを取得するように選択することができる。したがって、一ユーザ、Aliceは、彼女のユーザ名(たとえば、Alice123)に基づくリンクIDを有する子ノードのみを有する木のバージョンを見得るが、別のユーザ、Bobは、彼のユーザ名(たとえば、Bob456)に基づくリンクIDを有する子ノードのみを有する木のバージョンを見得る。AliceおよびBobのユーザ名は、彼らのプライバシーを保護するためにハッシュされ得る。子ノードは、特定のユーザに固有のデータを含み得る。特定のリンクIDを有する子ノードのみを有する木は、他のノード、たとえば、その子ノードの親ノード、および根ノードまでさかのぼる任意の他のノードを有する木を排除しないことが理解されるだろう。

本明細書で開示する一態様によれば、ブロックチェーンにオーバーレイされた木構造にアクセスするコンピュータ実装方法が提供され、木構造がノードのセットとノード間のエッジとを備え、各ノードがブロックチェーンに記録された異なるトランザクションであり、各エッジがそれぞれの子ノードからそれぞれの親ノードに接続し、親ノードの1つが木構造の根ノードであり、各ノードがそれぞれの鍵に関連付けられ、各子ノードが、i)それぞれのトランザクション識別子と、ii)それぞれの親ノードに関連付けられたそれぞれの鍵に対応する署名とを備え、ターゲット親ノードが複数のターゲット子ノードに接続され、各ターゲット子ノードがそれぞれのデータペイロードを備え、ターゲット子ノードの各々がそれぞれのリンク識別子に関連付けられ、それぞれのリンク識別子が少なくとも1つのオフチェーンパラメータに基づき、方法は、木アクセサ(tree accessor)によって実行され、ターゲット親ノードを取得するステップと、1つまたは複数のリンク識別子を取得するステップと、取得された1つまたは複数のリンク識別子のうちのそれぞれのリンク識別子に関連付けられたターゲット子ノードのうちの1つまたは複数を識別するステップと、識別されたターゲット子ノードのうちの1つまたは複数を備えるが、取得された1つまたは複数のリンク識別子のうちのそれぞれのリンク識別子に関連付けられていると識別されないターゲット子ノードを備えない木構造のバージョンを作成するステップとを備える。

本開示の実施形態の理解を助けるために、およびそのような実施形態がどのように実行に移され得るかを示すために、単に例として、添付の図面を参照する。

ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す図である。 ブロックチェーンにオーバーレイされたネットワークの概略図である。 ブロックチェーンにMetanetなどのネットワークをオーバーレイするための例示的なプロトコルを示す概略トランザクション図である。 Metanetなどのオーバーレイネットワークの文脈におけるノードバージョニングの概念を概略的に示す図である。 Metanetなどのオーバーレイネットワークの文脈におけるノード削除の概念を概略的に示す図である。 本明細書で開示する実施形態を実装するための例示的なシステムの概略ブロック図である。 異なる時間において異なる表示を有する動的木構造の一例を概略的に示す図である。 静的木構造を概略的に示す図である。 動的木構造を概略的に示す図である。 難読化されないエッジを概略的に示す図である。 難読化されたエッジを概略的に示す図である。 本明細書で開示するいくつかの実施形態による、例示的な方法を示す概略フローチャートである。 有効な子ノードのみの検索を概略的に示す図である。 開示された実施形態が同じウェブサイトの2つのバージョンを作成するためにどのように使用され得るかを概略的に示す図である。

例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、通常はインターネットなどのワイドエリアインターネットワークである、パケット交換ネットワーク101を備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように並べられ得る複数のブロックチェーンノード104を備える。示されていないが、ブロックチェーンノード104は準完全グラフとして並べられ得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104に高度に接続される。

各ブロックチェーンノード104は、ピアのコンピュータ機器を備え、異なるノード104は異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などの他の機器を備える、処理装置を備える。各ノードはまた、メモリ、すなわち、非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または高額ディスクドライブなどの光学媒体を利用する、1つまたは複数のメモリユニットを備え得る。

ブロックチェーン150はデータのブロック151のチェーンを備え、ブロックチェーン150のそれぞれのコピーが、分散ネットワークまたはブロックチェーンネットワーク106の中の複数のブロックチェーンノード104の各々において維持される。上で言及されたように、ブロックチェーン150のコピーを維持することは、ブロックチェーン150を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン150は、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(以下で論じられる)を記憶する限り、データを枝刈りされ得る。チェーンの中の各ブロック151は1つまたは複数のトランザクション152を備え、この文脈においてトランザクションはある種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、1つの特定のトランザクションプロトコルを全体で使用する。ある一般的なタイプのトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を備える。各出力は、ある数量のデジタル資産を表す額を財産として指定し、その例は、出力が暗号によりにロックされる対象であるユーザ103である(ロックを解除、および引き換えまたは消費のために、そのユーザの署名または他のソリューションを必要とする)。各入力は、先行するトランザクション152の出力を指し示し、それによりそれらのトランザクションをつなぐ。

各ブロック151はまた、ブロック151に対する逐次的な順序を定義するために、チェーンの中の以前に作成されたブロック151を指し示すブロックポインタ155を備える。各トランザクション152(コインベーストランザクション以外)は、トランザクションのシーケンスに対する順序を定義するために、以前のトランザクションへのポインタを備える(トランザクション152のシーケンスは分岐することが許容されることに留意されたい)。ブロック151のチェーンは、チェーンにおいて最初のブロックであったジェネシスブロック(Gb)153まで戻る。チェーン150の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくジェネシスブロック153を指し示していた。

ブロックチェーンノード104の各々は、トランザクション152を他のブロックチェーンノード104に転送し、それにより、トランザクション152がネットワーク106全体に広められるようにするように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード104はまた、ブロック151へと組み込まれるのを待機しているトランザクション152の順序付けられたセット(または「プール」)154を維持する。順序付けられたプール154は、「メモリプール」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図しない。それは、ノード104が有効であるものとして受け入れた、かつ同じ出力を消費することを試みる他のトランザクションをノード104が受け入れることが義務付けられない、トランザクションの順序付けられたセットを指す。

所与の現在のトランザクション152jにおいて、入力(または各入力)は、トランザクションのシーケンスの中の先行するトランザクション152iの出力を参照するポインタを備え、これは、この出力が現在のトランザクション152jにおいて引き換えられる、または「消費される」ことになることを指定する。一般に、先行するトランザクションは、順序付けられたセット154または任意のブロック151における任意のトランザクションであり得る。先行するトランザクション152iは、現在のトランザクション152iが作成される時点で、またはネットワーク106に送信される時点ですら、必ずしも存在する必要はないが、現在のトランザクションが有効になるためには、先行するトランザクション152iが存在して妥当性確認される必要がある。したがって、本明細書における「先行する」は、ポインタにより連結される論理シーケンスにおいて先行するものを指し、時間的な順序における作成または送信の時間を必ずしも指さず、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも排除しない(オーファントランザクションについての以下の議論を参照)。先行するトランザクション152iは同様に、祖先トランザクションまたは先行者トランザクションと呼ばれ得る。

現在のトランザクション152jの入力はまた、入力承認、たとえば、先行するトランザクション152iの出力がロックされる対象であるユーザ103aの署名を備える。そして、現在のトランザクション152jの出力は、新しいユーザまたはエンティティ103bに暗号によりロックされ得る。したがって、現在のトランザクション152jは、現在のトランザクション152jの出力において定義されるような新しいユーザまたはエンティティ103bに、先行するトランザクション152iの入力において定義される額を移すことができる。いくつかの場合、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、残金を与えるために元のユーザまたはエンティティ103aであり得る)の間で入力の額を分割するために、複数の出力を有し得る。いくつかの場合、トランザクションはまた、1つまたは複数の先行するトランザクションの複数の出力からの額を一緒に集めて、現在のトランザクションの1つまたは複数の出力を再分配するために、複数の入力を有し得る。

ビットコインなどの出力ベースのトランザクションプロトコルによれば、個人ユーザまたは団体などの関係者103が、(手動でまたは関係者によって使用される自動プロセスによって)新しいトランザクション152jを実施することを望むとき、実施する関係者は、関係者のコンピュータ端末102から受信者に新しいトランザクションを送信する。実施する関係者または受信者は最終的に、このトランザクションをネットワーク106のブロックチェーンノード104(これは今日では通常はサーバまたはデータセンターであるが、原理的には他のユーザ端末であってもよい)のうちの1つまたは複数に直接送信する。新しいトランザクション152jを実施する関係者103がトランザクションをブロックチェーンノード104のうちの1つまたは複数に送信でき、いくつかの例では受信者に送信できないことも、排除されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかを確認する。ブロックチェーンノードプロトコルは通常、新しいトランザクション152jの中の暗号署名が予想される署名と一致することをブロックチェーンノード104が確かめることを必要とし、予想される署名は、トランザクション152の順序付けられたシーケンスの中の以前のトランザクション152iに依存する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション152jの入力に含まれる関係者103の暗号署名または他の承認が、新しいトランザクションが割り当てる先行するトランザクション152iの出力において定義される条件と一致することを確かめることを備えることがあり、この条件は通常、新しいトランザクション152jの入力の中の暗号署名または他の承認が、新しいトランザクションの入力がつなげられる以前のトランザクション152iの出力のロックを解除することを、少なくとも確かめることを備える。この条件は、先行するトランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替として、それは単純にブロックチェーンノードプロトコルだけによって固定されてもよく、または、それはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じ試験を適用し、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送するなどする。このようにして、新しいトランザクションが、ブロックチェーンノード104のネットワーク全体に広められる。

出力ベースのモデルにおいて、所与の出力(たとえば、UXTO)が割り当てられる(たとえば、消費される)かどうかの定義は、それがブロックチェーンノードプロトコルに従って別の前方のトランザクション152jの入力によりすでに有効に引き換えられているかどうかである。トランザクションが有効になるための別の条件は、そのトランザクションが引き換えることを試みる先行するトランザクション152iの出力が、別のトランザクションによってまだ引き換えられていないことである。やはり、有効ではない場合、トランザクション152jは、ブロックチェーン150において広められず(無効であるものとしてフラグを立てられて警告のために広められない限り)、または記録されない。これは、取引者が同じトランザクションの出力を一度より多く割り当てることを試みるような、二重消費から守る。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重消費から守る。やはり、トランザクションの定められた順序があるので、アカウント残高は任意のある時間において単一の定められた状態を有する。

トランザクションを検証することに加えて、ブロックチェーンノード104はまた、マイニングと一般に呼ばれるプロセスにおいて、トランザクションのブロックを最初に作成するのを競い、これは「プルーフオブワーク」により支援される。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されているブロック151にまだ表れていない有効なトランザクションの順序付けられたプール154に追加される。そして、ブロックチェーンノードは、暗号パズルを解こうとすることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を競って組み立てる。通常、これは、「ノンス」が未処理のトランザクション154の順序付けられたプールの表現と連結されてハッシュされると、ハッシュの出力が所定の条件を満たすような、ノンス値を探すことを備える。たとえば、所定の条件は、ハッシュの出力がある定められた数の先頭の0を有するということであり得る。これは、プルーフオブワークパズルの1つの具体的なタイプにすぎず、他のタイプが排除されないことに留意されたい。ハッシュ関数の性質は、それがその入力に関して予測不可能な出力を有するというものである。したがって、この探索は、ブルートフォースによってのみ実行することができるので、パズルを解こうとしている各ブロックチェーンノード104において大量の処理リソースを消費する。

パズルを解こうとする第1のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークの中の他のブロックチェーンノード104によって容易に確かめられ得る証明として解を提供する(ハッシュへの解が与えられると、それによりハッシュの出力が条件を満たすようになることを確かめるのは単純である)。第1のブロックチェーンノード104は、ブロックを受け入れしたがってプロトコルルールを実施する、他のノードの閾値コンセンサスにブロックを広める。トランザクションの順序付けられたセット154は次いで、ブロックチェーンノード104の各々によってブロックチェーン150の中の新しいブロック151として記録されるようになる。ブロックポインタ155はまた、チェーンの中の以前に作成されたブロック151n-1を指し示す新しいブロック151nに割り当てられる。プルーフオブワークの解を作成するために必要とされる、たとえばハッシュの形式の大量の労力は、ブロックチェーンプロトコルのルールに従うという第1のノードの104の意図を示すものである。そのようなルールは、以前に妥当性確認されたトランザクションと同じ出力を割り当てる場合(これは別様に二重消費として知られている)、有効であるものとしてトランザクションを受け入れないことを含む。作成されると、ブロック151を改変することはできず、それは、ブロック151が、ブロックチェーンネットワーク106の中のブロックチェーンノード104の各々において認識され維持されるからである。ブロックポインタ155はまた、逐次的な順序をブロック151に課す。トランザクション152は、ネットワーク106の中の各ブロックチェーンノード104において順序付けられるブロックに記録されるので、これはトランザクションのイミュータブルな公開台帳を提供する。

任意の所与の時間において競ってパズルを解く異なるブロックチェーンノード104は、それらのブロックチェーンノードがいつ解の探索を始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間におけるまだ公開されていないトランザクション154のプールの異なるスナップショットに基づいて、競ってパズルを解いていることがあることに留意されたい。それぞれのパズルを最初に解いた者が、どのトランザクション152が次の新しいブロック151nに含まれるか、およびどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール154は更新される。ブロックチェーンノード104は次いで、公開されていないトランザクション154の新しく定義された順序付けられたプールからブロックを競って作成し続け、以下同様である。生じ得るあらゆる「フォーク」を解決するためのプロトコルも存在し、これは、2つのブロックチェーンノード104が互いに非常に短い時間内にパズルを解き、その結果、ブロックチェーンの矛盾する表示がノード104間で広められるようになる状況である。つまり、フォークの先端がより長く成長した方が、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークに現れるので、これはネットワークのユーザまたはエージェントに影響しないはずであることに留意されたい。

ビットコインブロックチェーン(および大部分の他のブロックチェーン)によれば、新しいブロックを構築することに成功するノード104は、(あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を移す、エージェント間またはユーザ間のトランザクションとは対照的に)追加の、定められた数量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、追加の、許容される額のデジタル資産を新たに割り当てる能力を与えられる。この特別なタイプのトランザクションは普通、「コインベーストランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」とも呼ばれ得る。それは通常、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で引き換えられることを可能にするプロトコルルールに従うという、新しいブロックを構築するノードの意図を示すものである。ブロックチェーンプロトコルルールは、この特別なトランザクションを引き換えられるようになるまで、成熟期間、たとえば100ブロックを必要とし得る。しばしば、通常の(非生成)トランザクション152はまた、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加のトランザクションフィーを指定する。この料金は普通は「トランザクションフィー」と呼ばれ、以下で論じられる。

トランザクションの妥当性確認および公開に関与するリソースにより、典型的にはブロックチェーンノード104の少なくとも各々が、1つまたは複数の物理サーバユニットを備えるサーバという形態をとり、またはデータセンター全体という形態すらとる。しかしながら、原理的には、あらゆる所与のブロックチェーンノード104は、一緒にネットワーク接続されたユーザ端末またはユーザ端末のグループという形態をとり得る。

各ブロックチェーンノード104のメモリは、それぞれの役割を実行し、ブロックチェーンノードプロトコルに従ってトランザクション152を扱うように、ブロックチェーンノード104の処理装置上で実行するように構成される、ソフトウェアを記憶する。ブロックチェーンノード104に対する本明細書に起因するあらゆる活動が、それぞれのコンピュータ機器の処理装置で実行されるソフトウェアによって実施され得ることが理解されるだろう。ノードソフトウェアは、アプリケーション層における1つまたは複数のアプリケーションで、またはオペレーティングシステム層もしくはプロトコル層などのより低次の層で、またはこれらの任意の組合せで実装され得る。

消費するユーザの役割において複数の関係者103の各々のコンピュータ機器102もまた、ネットワーク101に接続される。これらのユーザは、ブロックチェーンネットワーク106と対話し得るが、トランザクションの検証、またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者または受信者として活動し得る。他のユーザは、必ずしも送信者または受信者として活動することなく、ブロックチェーン150と対話し得る。たとえば、一部の関係者は、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ストレージエンティティとして活動し得る。

関係者103の一部またはすべてが、異なるネットワーク、たとえばブロックチェーンネットワーク106に重畳されるネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ(「クライアント」と呼ばれることが多い)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われることがある。しかしながら、これらのユーザはブロックチェーンノード104ではなく、それは、ブロックチェーンノードに必要とされる役割を実行しないからである。代わりに、各関係者103は、ブロックチェーンネットワーク106と対話し、それにより、ブロックチェーンノード106に接続する(すなわち、それと通信する)ことによって、ブロックチェーン150を利用し得る。第1の関係者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の関係者103bおよびそのそれぞれのコンピュータ機器102bという、2名の関係者103および彼らのそれぞれの機器102が例示を目的に示されている。より多くのそのような関係者103およびそれぞれのコンピュータ機器102が、システム100において存在して参加していてもよいが、便宜的にそれらは示されていないことが理解されるだろう。各関係者103は、個人または組織であり得る。純粋に例示として、第1の関係者103aはAliceと本明細書では呼ばれ、第2の関係者103bはBobと呼ばれるが、これは限定するものではなく、本明細書でのAliceまたはBobへのあらゆる言及は、それぞれ「第1の関係者」および「第2の関係者」で置き換えられ得ることが理解されるだろう。

各関係者103のコンピュータ機器102は、1つまたは複数のプロセッサ、たとえば1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを備える、それぞれの処理装置を備える。各関係者103のコンピュータ機器102はさらに、非一時的コンピュータ可読媒体の形式のメモリ、すなわちコンピュータ可読ストレージを備える。このメモリは、1つまたは複数のメモリ媒体、たとえばハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光学ディスクドライブなどの光学媒体を利用する、1つまたは複数のメモリユニットを備え得る。各関係者103のコンピュータ機器102のメモリは、処理装置上で実行するようになされる少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを備えるソフトウェアを記憶する。所与の関係者103に対する本明細書に起因するあらゆる活動は、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されるだろう。各関係者103のコンピュータ機器102は、少なくとも1つのユーザ端末、たとえばデスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを備える。所与の関係者103のコンピュータ機器102はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、1つまたは複数の他のネットワーク接続されたリソースを備え得る。

クライアントアプリケーション105は最初に、たとえばサーバからダウンロードされる、あるいは、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光学ディスク、またはリムーバブル光学ドライブなどの、リムーバブルストレージデバイス上で提供される、適切なコンピュータ可読記憶媒体上の任意の所与の関係者103のコンピュータ機器102に提供され得る。

クライアントアプリケーション105は、少なくとも「ウォレット」機能を備える。これには2つの主要な機能がある。これらのうちの1つは、それぞれの関係者103がトランザクション152を作成し、承認(たとえば署名)し、1つまたは複数のビットコインノード104に送信して、トランザクション152がブロックチェーンノード104のネットワーク全体に広められてブロックチェーン150に含まれるようにすることを可能にすることである。もう1つは、それぞれの関係者が現在所有するデジタル資産の額をそれぞれの関係者に報告することである。出力ベースのシステムでは、この第2の機能は、対象の関係者に属するブロックチェーン150全体に散在する様々な152トランザクションの出力において定義される額を照合することを備える。

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

各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能がトランザクション152をネットワーク106に送信することを可能にする。クライアント105はまた、それぞれの関係者103が受信者であるあらゆるトランザクションについてブロックチェーン150にクエリするために、ブロックチェーンノード104に連絡することも可能である(または、実施形態では、ブロックチェーン150が、公的な存在であることにより一部トランザクションに信用をもたらす公的機関であるので、実際にブロックチェーン150における他の関係者のトランザクションを調査する)。各コンピュータ機器102のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を編成して送信するように構成される。上で述べられたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を妥当性確認し、ブロックチェーンネットワーク106全体にトランザクション152を広めるためにそれらを転送するように構成される、ソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルを伴い、一緒に所与のトランザクションモデルを実装する。ブロックチェーン150の中のすべてのトランザクション152に対して、同じトランザクションプロトコルが使用される。同じノードプロトコルが、ネットワーク106の中のすべてのノード104によって使用される。

所与の関係者103、たとえばAliceが、新しいトランザクション152jをブロックチェーン150に含まれるように送信することを望むとき、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを編成する。彼女は次いで、クライアントアプリケーション105から、彼女が接続されている1つまたは複数のブロックチェーンノード104に、トランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最善に接続されるブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104が新しいトランザクション152jを受信するとき、ブロックチェーンノード104は、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従って、新しいトランザクション152jを扱う。これは、新しく受信されたトランザクション152jが「有効」であるための何らかの条件を満たすかどうかをまず確かめることを備え、その例がまもなくより詳しく論じられる。一部のトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替として、この条件は単に、ノードプロトコルの内蔵機能であってもよく、またはスクリプトとノードプロトコルの組合せによって定義されてもよい。

新しく受信されるトランザクション152jが有効であるものとして見なされるように試験に合格する条件(すなわち、それが「妥当性確認される」条件)のもとで、トランザクション152jを受信する任意のブロックチェーンノード104が、新しい妥当性確認されたトランザクション152をそのブロックチェーンノード104に維持されているトランザクションの順序付けられたセット154に追加する。さらに、トランザクション152jを受信するあらゆるブロックチェーンノード104は、妥当性確認されたトランザクション152以降をネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に広める。各ブロックチェーンノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、それがまもなくネットワーク106全体に広められることを意味する。

所与のブロックチェーンノード104において維持される保留中のトランザクションの順序付けられたプール154の利用を認められると、そのブロックチェーンノード104は、新しいトランザクション152を含むトランザクションのそれぞれのプール154の最新のバージョンについてのプルーフオブワークパズルを競って解き始める(他のブロックチェーンノード104が、トランザクションの異なるプール154に基づいてパズルを解こうとしていることがあるが、最初にたどり着いた者が最新のブロック151に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたプール154の一部のためのパズルを解く)。プルーフオブワークが、新しいトランザクション152jを含むプール154に対して行われると、それはイミュータブルに、ブロックチェーン150の中のブロック151のうちの1つの一部になる。各トランザクション152は、より前のトランザクションへのポインタを備えるので、トランザクションの順序もイミュータブルに記録される。

異なるブロックチェーンノード104は、所与のトランザクションの異なるインスタンスをまず受信するので、あるインスタンスが新しいブロック151において公開される前は、どのインスタンスが「有効」であるかについて矛盾する表示を有することがあり、それが公開される時点では、公開されるインスタンスが唯一の有効なインスタンスであることにすべてのブロックチェーンノード104が合意している。ブロックチェーンノード104があるインスタンスを有効であるものとして受け入れ、第2のインスタンスがブロックチェーン150に記録されていることを発見する場合、そのブロックチェーンノード104は、これを受け入れ、最初に受け入れたインスタンス(すなわち、ブロック151において公開されていないインスタンス)を廃棄する(すなわち、無効であるものとして扱う)。

一部のブロックチェーンネットワークによって運用される代替のタイプのトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと呼ばれることがある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別に、そのネットワークのノードによって記憶され、定期的に更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、暗号署名の一部として送信者により署名され、トランザクション参照計算の一部としてハッシュされる。加えて、任意のデータフィールドはまた、署名されたトランザクションであってもよい。このデータフィールドは、たとえば以前のトランザクションIDがデータフィールドに含まれる場合、以前のトランザクションを指し示し得る。

UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と省略される)は、ブロックチェーン150の基本データ構造である(各ブロック151は1つまたは複数のトランザクション152を備える)。以下は、出力ベースまたは「UTXO」ベースのプロトコルに言及して説明される。しかしながら、これはすべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルはビットコインに言及して説明されるが、それは他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。

UTXOベースのモデルでは、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を備えるデータ構造を備える。各出力203は、未消費のトランザクション出力(UTXO)を備えてもよく、これは、別の新しいトランザクションの入力202のソースとして使用され得る(UTXOがまだ引き換えられていない場合)。UTXOは、デジタル資産の額を指定する値を含む。これは、分散型台帳上のある設定された数のトークンを表す。UTXOはまた、情報の中でもとりわけ、UTXOの由来であるトランザクションのトランザクションIDを含み得る。トランザクションデータ構造はヘッダ201も備えることがあり、これは入力フィールド202および出力フィールド203のサイズのインジケータを備えることがある。ヘッダ201はまた、トランザクションのIDを含むことがある。実施形態では、トランザクションIDは、トランザクションデータ(トランザクションID自体を除く)のハッシュであり、ノード104に出される生のトランザクション152のヘッダ201に記憶される。

Alice 103aが、対象のある額のデジタル資産をBob 103bに移すトランザクション152jを作成することを望んでいるとする。図2において、Aliceの新しいトランザクション152jは「Tx₁」とラベリングされる。Tx₁は、シーケンスの中の先行するトランザクション152iの出力203においてAliceにロックされるデジタル資産の額をとり、その少なくとも一部をBobに移す。先行するトランザクション152iは、図2では「Tx₀」とラベリングされる。Tx₀およびTx₁は任意のラベルにすぎない。それらは、Tx₀がブロックチェーン151の最初のトランザクションであることを必ずしも意味せず、Tx₁がプール154の中のすぐ次のトランザクションであることも意味しない。Tx₁は、Aliceにロックされている未消費の出力203をまだ有するあらゆる先行する(すなわち、祖先)トランザクションを指し示し得る。

先行するトランザクションTx₀は、Aliceが新しいトランザクションTx₁を作成するとき、または少なくとも彼女がそれをネットワーク106に送信するときにはすでに、ブロックチェーン150のブロック151において妥当性確認されそれに含まれていることがある。それは、その時点ですでにブロック151のうちの1つに含まれていることがあり、または、順序付けられたセット154においてまだ待機していることがあり、その場合、それは新しいブロック151にまもなく含められる。代替として、Tx₀およびTx₁は、一緒に作成されてネットワーク106に送信されてもよく、または、ノードプロトコルが「オーファン」トランザクションのバッファリングを許容する場合、Tx₀がTx₁の後に送信されることすらあってもよい。トランザクションのシーケンスの文脈で本明細書において使用される「先行する」および「後続の」という用語は、トランザクションにおいて指定されるトランザクションポインタによって定義されるようなシーケンスにおけるトランザクションの順序を指す(どのトランザクションがどの他のトランザクションを指し示すか、など)。それらは、「先行者」および「後継者」、または「祖先」および「子孫」、「親」および「子」などにより等しく置き換えられ得る。これは、それらが作成される順序、ネットワーク106に送信される順序、または任意の所与のブロックチェーンノード104に到達する順序を必ずしも示唆しない。それでも、先行するトランザクション(祖先トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが妥当性確認されるまでは、かつ妥当性確認されない限り、妥当性確認されない。親より前にブロックチェーンノード104に到達する子は、オーファンであると見なされる。それは、ノードプロトコルおよび/またはノード挙動に応じて、廃棄され、または親を待機するためにある時間の間バッファリングされ得る。

先行するトランザクションTx₀の1つまたは複数の出力203のうちの1つは、ここでUTXO₀とラベリングされる特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが妥当性確認されるようにするために、したがってUTXOの引き換えが成功するために、後続のトランザクションの入力202におけるロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを備える。通常、ロックスクリプトは、額を特定の関係者(ロックスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトはロック解除条件を定義し、その条件は通常、後続のトランザクションの入力におけるロック解除スクリプトが、先行するトランザクションがロックされる対象である関係者の暗号署名を備えるという条件を備える。

ロックスクリプト(scriptPubKeyとしても知られている)は、ノードプロトコルによって認識される分野特有の言語で書かれるコードである。そのような言語の具体的な例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、トランザクション出力203を消費するためにどの情報が必要とされるか、たとえば、Aliceの署名の要件を指定する。ロック解除スクリプトは、トランザクションの出力に現れる。ロック解除スクリプト(scriptSigとしても知られている)は、ロックスクリプト基準を満たすために必要とされる情報を提供する分野特有の言語で書かれるコードである。たとえば、それはBobの署名を含み得る。ロック解除スクリプトはトランザクションの入力202に現れる。

よって、示される例では、Tx₀の出力203におけるUTXO₀は、UXTO₀が引き換えられるようにするために(厳密には、UTXO₀を引き換えようとする後続のトランザクションが有効になるために)Aliceの署名Sig P_Aを必要とするロックスクリプト[Checksig P_A]を備える。[Checksig P_A]は、Aliceの公開-秘密鍵のペアからの公開鍵P_Aの表現(すなわち、ハッシュ)を含む。Tx₁の入力202は、Tx₁を指し示す(たとえば、そのトランザクションIDであるTxID₀によって指し示す、TxID₀は実施形態ではトランザクション全体Tx₀のハッシュである)ポインタを備える。Tx₁の入力202は、Tx₀のあらゆる他のあり得る出力の中からUTXO₀を特定するために、Tx₀内でUTXO₀を特定するインデックスを備える。Tx₁の入力202はさらに、Aliceが鍵のペアからの自身の秘密鍵をデータのあらかじめ定められた部分(暗号学では「メッセージ」と呼ばれることがある)に適用することによって作成される、Aliceの暗号署名を備えるロック解除スクリプト<Sig P_A>を備える。Aliceにより有効な署名を提供するために署名される必要のあるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。

新しいトランザクションTx₁がブロックチェーンノード104に到達すると、ノードはノードプロトコルを適用する。これは、ロック解除スクリプトがロックスクリプトにおいて定義される条件(この条件は1つまたは複数の基準を備え得る)を満たすかどうかを確かめるために、ロックスクリプトおよびロック解除スクリプトを一緒に実行することを備える。実施形態では、これは2つのスクリプトを連結することを伴う。
<Sig P_A><P_A>||[Checksig P_A]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロックスクリプト(この例では、スタックベース言語)に含まれる関数である。等価的に、スクリプトを連結するのではなく、スクリプトは共通のスタックを用いて次々に実行されてもよい。いずれにしても、一緒に実行されると、スクリプトは、Tx₀の出力の中のロックスクリプトに含まれるような、Aliceの公開鍵P_Aを使用して、Tx₁の入力の中のロック解除スクリプトがデータの予想される部分に署名するAliceの署名を含むことを認証する。データ自体(「メッセージ」)の予想される部分も、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータはTx₁の全体を備える(よって、平文でデータの署名された部分を指定する別個の要素が含まれる必要がなく、それは、もともと存在していたからである)。

公開-秘密暗号による認証の詳細は、当業者には馴染みがある。基本的に、Aliceが自身の秘密鍵を使用してメッセージに署名した場合、平文のAliceの公開鍵およびメッセージを与えられると、ノード104などの別のエンティティは、メッセージがAliceによって署名されたに違いないことを認証することが可能である。署名することは通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージへとタグ付けすることで、公開鍵のあらゆる保有者が署名を認証することを可能にすることを備える。したがって、本明細書における、特定のデータまたはトランザクションの一部に署名することなどへのあらゆる言及は、実施形態では、そのデータまたはトランザクション一部のハッシュに署名することを意味することに留意されたい。

Tx₁におけるロック解除スクリプトがTx₀のロックスクリプトにおいて指定される1つまたは複数の条件を満たす場合(よって示される例では、Aliceの署名がTx₁において提供されて認証される場合)、ブロックチェーンノード104はTx₁を有効であると見なす。これは、ブロックチェーンノード104がTx₁を未処理のトランザクションの順序付けられたプール154に追加することを意味する。ブロックチェーンノード104はまた、ネットワーク106の中の1つまたは複数の他のブロックチェーンノード104にトランザクションTx₁を転送するので、それは、ネットワーク106全体に広められる。Tx₁がブロックチェーン150において妥当性確認され含められると、これは消費されるものとしてTx₀からのUTXO₀を定義する。Tx₁は、未消費のトランザクション出力203を消費する場合にのみ、有効であり得ることに留意されたい。別のトランザクション152によってすでに消費されている出力を消費しようとする場合、Tx₁は、すべての他の条件が満たされている場合でも無効になる。したがって、ブロックチェーンノード104は、先行するトランザクションTx₀の中の参照されるUTXOがすでに消費されているかどうか(すなわち、すでに有効な入力を別の有効なトランザクションへと形成したかどうか)を確かめる必要もある。これは、トランザクション152に定められた順序を課すことがブロックチェーン150にとって重要である1つの理由である。実際には、所与のブロックチェーンノード104は、トランザクション152がその中で消費されたどのUTXO203をマークする別個のデータベースを維持してもよいが、究極的には、UTXOが消費されたかどうかを定義するものは、UTXOが有効な入力をブロックチェーン150の中の別の有効なトランザクションへとすでに形成したかどうかである。

所与のトランザクション152のすべての出力203において指定される総額が、すべてのその入力202によって指し示される総額より大きい場合、これもまた、大半のトランザクションモデルにおいて、無効であることの根拠になる。したがって、そのようなトランザクションは、広められず、ブロック151にも含められない。

UTXOベースのトランザクションモデルにおいて、所与のUTXOは全体として消費される必要があることに留意されたい。それは、消費されるものとしてUTXOにおいて定義される額の一部を、別の一部が消費されながら「置き去りにする」ことができない。しかしながら、UTXOからの額は、次のトランザクションの複数の出力の間で分割され得る。たとえば、Tx₀の中のUTXO₀において定義される額は、Tx₁の中の複数のUTXO間で分割され得る。したがって、AliceがUTXO₀において定義される額のすべてをBobに与えることを望まない場合、彼女はリマインダーを使用してTx₁の第2の出力の残金を自分に与え、または別の関係者に支払うことができる。

実際には、Aliceはまた通常、ブロック151に自分のトランザクション104を含むことに成功するビットコインノード104に対する料金を含める必要がある。Aliceがそのような料金を含めない場合、Tx₀はブロックチェーンノード104によって拒絶されてもよく、したがって、技術的には有効であっても、広められず、ブロックチェーン150に含められなくてもよい(ノードプロトコルは、ブロックチェーンノード104がトランザクション152を受け入れることを望まない場合、それを強いることはない)。一部のプロトコルでは、トランザクションフィーは、固有の別々の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指し示される総額と所与のトランザクション152の出力203において指定される総額とのあらゆる差が、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO₀へのポインタがTx₁への唯一の入力であり、Tx₁が唯一の出力UTXO₁を有するとする。UTXO₀において指定されるデジタル資産の額が、UTXO₁において指定される額よりも大きい場合、その差は、UTXO₁を含むブロックを作成するためにプルーフオブワークのレースに勝つノード104によって割り当てられ得る。しかしながら、代替または追加として、トランザクションフィーが、トランザクション152のUTXO203のうちの自身固有のUTXOにおいて明示的に指定され得ることは、必ずしも排除されない。

AliceおよびBobのデジタル資産は、ブロックチェーン150のどこかにある任意のトランザクション152において彼らにロックされるUTXOからなる。したがって、通常は、所与の関係者103の資産は、ブロックチェーン150全体の、様々なトランザクション152のUTXO全体に分散している。所与の関係者103の総残高を定義する1つの数字が、ブロックチェーン150のどこかに保管されているということはない。それぞれの関係者にロックされており、別のその先のトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を一緒に照合することが、クライアントアプリケーション150のウォレット機能の役割である。そのウォレット機能は、ビットコインノード104のいずれかに記憶されているようなブロックチェーン150のコピーをクエリすることによって、これを行うことができる。

スクリプトコードはしばしば、概略的(すなわち、厳密な言語を使用せずに)に表現されることに留意されたい。たとえば、特定の関数を表すためにオペレーションコード(オペコード)を使用することがある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの最初おいてOP_FALSEが前にあるとトランザクション内のデータを記憶できるトランザクションの消費不可能な出力を生み出し、それによりブロックチェーン150にデータをイミュータブルに記録するような、Script言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を備え得る。

通常、トランザクションの入力は、公開鍵P_Aに対応するデジタル署名を含む。実施形態では、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は特定のデータに署名する。いくつかの実施形態では、所与のトランザクションに対して、署名はトランザクション入力の一部、およびトランザクション出力の一部またはすべてに署名する。署名する出力の具体的な部分は、SIGHASHフラグに依存する。SIGHASHフラグは普通は、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名の時点で固定される)4バイトのコードである。

ロックスクリプトは時々「scriptPubKey」と呼ばれ、それぞれのトランザクションがロックされる対象である関係者の公開鍵をロックスクリプトが通常は備えるという事実を指している。ロック解除スクリプトは時々「scriptSig」と呼ばれ、ロック解除スクリプトが対応する署名を通常は供給するという事実を指している。しかしながら、より一般的には、UTXOが引き換えられるようにするための条件が署名を認証することを備えることは、ブロックチェーン150のすべての適用例において必須ではない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用され得る。したがって、より一般的な用語「ロックスクリプト」および「ロック解除スクリプト」が好まれることがある。

レイヤ2オーバーレイネットワーク
ブロックチェーンネットワーク106はすでに、インターネット101などのネットワーク上にオーバーレイされたオーバーレイネットワークの形態である。しかしながら、ブロックチェーンにオーバーレイネットワークの別のレイヤを層状に重ねることも可能である。これは、図3に例として示されている。一例がMetanetである。そのようなネットワークは、それが、下にあるネットワークインフラストラクチャとしてのベースネットワーク101(たとえば、インターネット)、およびベースネットワーク上にオーバーレイされたオーバーレイネットワークの第1のレイヤとしてのブロックチェーンネットワーク106に対して、オーバーレイネットワークの第2のレイヤであるという意味において、「レイヤ2」ネットワークと呼ばれることもある。

オーバーレイネットワーク300のこの第2の層は、ノード301およびエッジ302のネットワークを含む。ノード301は今、Metanet(またはブロックチェーンにオーバーレイされた他のそのようなネットワーク)のレイヤのノードを指し、図1および図2に関して前に説明したブロックチェーンネットワーク106のレイヤにおけるノード104ではないことに留意されたい。Metanetネットワーク(または同様のもの)の各ノード301は、ブロックチェーン150上の異なるそれぞれのトランザクション152であり、その各々が、それぞれのトランザクションのペイロードにデータを記憶する。したがって、Metanetネットワーク300(または同様のもの)のノード301は、本明細書ではデータ記憶ノードまたはデータ記憶トランザクションと呼ばれることもある。そこに記憶されたデータは、データコンテンツおよび/またはメタデータを含み、一般的には両方を含み得る。出力ベースモデルでは、それは、それぞれのトランザクションの支出不可出力203に記憶されてもよく、またはさらにはそれぞれのトランザクションの消費可能な出力に記憶されてもよい。出力は、実行時にスクリプトを終了する、ロックスクリプト内の1つまたは複数のオペコードによって支出不可にされてもよい。たとえば、スクリプト言語を使用するシステムでは、これは、使用されるプロトコルに応じて、OP_RETURNオペコードであってもよく、またはOP_FALSE続いてOP_RETURNであってもよい。しかしながらこれは限定ではなく、他のブロックチェーンシステムにおいて、たとえばアカウントベースのモデルを使用するシステムにおいて、トランザクションに任意のペイロードデータを記憶するための他の技法を当業者は承知であろう。以下は、出力ベースのモデルに関して例示される場合があるが、これは限定ではない。

レイヤ2オーバーレイネットワーク300は、純粋にデータからなり、完全に仮想的であり得ることに留意されたい。すなわち、ブロックチェーン150のトランザクション152にオーバーレイされたオーバーレイネットワークとしての、Metanetなどのノード301およびエッジ32は、必ずしも下にあるブロックチェーンネットワーク106または下にあるネットワークインフラストラクチャ101のいずれか特定の物理的アクタ(actor)またはエンティティに対応しない。

データコンテンツは、たとえばテキスト、音声、静止画もしくは動画、または他のドキュメントを記憶するためにMetanet(または同様のもの)が使用されている実際のデータである。データコンテンツは、ユーザコンテンツまたはユーザデータと呼ばれることもある。メタデータは、ブロックチェーン150にネットワークを層状に重ねるためのプロトコルを実装する。トランザクション152の少なくとも一部では、メタデータは、データコンテンツ間のリンクを定義する。これらは、ノード301間のエッジ302として説明されることもある。リンクまたはポインタは、たとえば、親ノードのトランザクションID、TxID_parentを含んでもよい。本明細書で言及する「リンク」は必ずしもハイパーテキストリンクを意味するとは限らないが、それは1つの可能性であることに留意されたい。より一般的にはリンクは、Metatnetレイヤ(またはブロックチェーン150に層状に重ねられた他のそのようなオーバーレイレイヤ)において現在のノード301が関連している別のノード301を指し示すどんな形態のポインタも指すことができる。

便宜上、以下は、Metanetに関して例として説明することになるが、これは限定ではなく、より一般的には、Metanetに言及する本明細書のどこでも、これはブロックチェーン上にオーバーレイされたどんなオーバーレイネットワークに置き換えられてもよいことが諒解されよう。同様に、Metanetノードへのいずれの言及も、いずれのオーバーレイネットワークノード、またはオーバーレイネットワークのデータストレージノードへの言及に置き換えられてもよく、Metanetリンクまたはエッジへのいずれの言及も、当該のオーバーレイネットワークのレイヤにおけるいずれのオーバーレイネットワークエッジまたはリンクへの言及に置き換えられてもよい。

Metanetプロトコルは、パブリックブロックチェーンに記憶され、多くの使用事例に様々なアプリケーションにおいて使用され得るオンチェーンデータを構築するための方式および規格を定義する。プロトコルは、ノードおよびエッジを含む、グラフ構造が、ブロックチェーントランザクションのセットから構成できること、ならびにこれらの構造が、どんな性質のデータ(「コンテンツ」)も記憶、搬送、表現、および配信するために使用され得ることを指定する。トランザクションをノードとして、および署名をトランザクション間で作成されたエッジとして扱うことによって、Metanetプロトコルは、図3に示すオンチェーングラフ構造の作成を可能にする。

図からわかるように、Metanet300のノード301およびエッジ302は、木構造を形成する。すなわち、親ノード301は、1つまたは複数の子ノード301にリンクされ、任意の所与の子301はそれ自体が、それ自体の1つまたは複数の子にリンクされた親であるなどであってもよい。目下の目的のための当該の木構造は、より広い木またはグラフのサブセットであるにすぎない場合があることに留意されたい。

図3はまた、ノード301およびそれの関連するエッジ302がどのように更新され得るかを示す。トランザクションはブロックチェーン152に不変に記録されるので、Metanetノード301への更新は、新しいトランザクション152によって、新しいインスタンス301'および対応するエッジ302'を作成することを必要とする。

図3の構造は、入れ子になった領域、たとえばウェブサイトおよびそれのページの構造を含んでもよく、ここで「トップレベル領域」がそれの下のサブ領域などを封入する。1つの機能的鍵領域(たとえば、書込み鍵、資金提供鍵(funding key)、または暗号化鍵の領域)は、これらの構造領域の多くに及ぶことができる。

図3の円はノードを表し、ノードは単に、Metanetプロトコルのルールセットに従って作成されたトランザクションである。そのルールセットに従って作成され、形式を定められたトランザクション152Nの一例を、図4に示す。

図4の右側のトランザクション152Cは、Metanetの所与のノード301C(子)を実装するブロックチェーン150のトランザクション152を表す。図4の左上のトランザクション152Pは、Metanetレイヤにおいて子ノード152Cの親を実装するブロックチェーン150のトランザクションを表す。子ノードトランザクション152Cは、ロック解除スクリプトを含み、ブロックチェーン150の資金提供トランザクション152Fの出力203を指し示す入力202を有する。言い換えれば、資金提供トランザクション152Fの出力は、Metanetノード152Cの入力によって消費される。資金提供トランザクション152FおよびMetanet親トランザクション152Pは必ずしも同じトランザクションではない(しかしそれは除外もされない)ことに留意されたい。

子トランザクション152Cは、たとえば、OP_RETURNによって支出不可にされた、ペイロード(ブロックチェーンレイヤの観点からのペイロード)を維持する、支出不可出力203を含む。このペイロードは、ハッシュ化および/または暗号化された、Metanetのデータコンテンツ(「Data」)を含んでもよく、または単に(「平文の」)生データであってもよい。

子トランザクション152Cのペイロードはまた、Metanetネットワークレイヤのメタデータを含む。このメタデータは、少なくとも親トランザクション152Pのトランザクション識別子を含む。これは、Metanetレイヤにおいてリンク(エッジ)302を作成する。子ノード301Cに関連する鍵P_nodeを含むことが、Metanetプロトコルによって必要とされる場合もある。

資金提供トランザクション152Fの出力203のロックスクリプトはまた、子ノード152Cの入力202のロック解除スクリプトに含まれる署名を必要とする。詳細には、この署名は、Metanet親に関連する鍵P_parentを使用して署名された署名(すなわち、その鍵によって署名されたメッセージ)であることが必要とされる。これは、ブロックチェーンレイヤにおいてエッジ402(支出エッジと呼ばれることがある)を作成する。子トランザクション152Cの入力202のロック解除スクリプトに、必要な署名が含まれていない場合、子トランザクション152Cは、ブロックチェーンネットワーク106のノード104によって有効にされないことになり、したがってブロックチェーンネットワーク106を通して伝播されず、ブロックチェーン150に記録もされないことになる。しかしながらこの場合も、資金提供トランザクション152Fは必ずしもMetanet親トランザクション152Pと同じブロックチェーントランザクション152ではなく、したがってブロックチェーンレイヤ支出エッジ402は、必ずしもMetanetレイヤエッジ302と同じではないことに留意されたい。

図4は、Metanetトランザクションの単にいくつかの関連する構成要素を、全体としてトランザクションの抽象化として概説する。これらの構成要素は、プロトコル識別子フラグに加えて、
・ 公開鍵P_nodeと、
・ 親公開鍵P_parentの署名SigP_parentと、
・ ノード自体のトランザクションID TxID_nodeと、
・ ノードの親のトランザクションID TxID_parentと
を含む。

プレースホルダ<Data>は一般に、Metanetノードトランザクションに含まれ得る任意のコンテンツデータを指す。いくつかの適用例では、暗号化鍵ekでデータを暗号化したいであろうことも考えられるが、その場合、トランザクションに含まれるデータは、<e(Data,ek)>とされ、ここでe( )は好適な暗号化関数である。

各Metanetノード301は、ペア(P_node,TxID_node)によって一意に識別でき、これは強力なバージョニングおよびパーミッショニング制御がMetanetグラフによって受け継がれることを可能にするインデックスである。各Metanetノードが、それ自体(P_node,TxID_node)およびそれの親(P_parent,TxID_parent)を識別するのに十分な情報を含むことも諒解されたい。

Metanet子ノード301Cトランザクションが、親ノード301Pからの正しい入力署名SigP_parentを含むことを保証するために、多くの場合、1つまたは複数の資金提供トランザクション152Fを作成してこれを容易にすることが望ましい場合があり、これを図4の左下に示している。

親鍵P_parentおよび/または子ノード鍵P_nodeは、子ノード301Cのデータをブロックチェーン150に書き込む権限を与える書込み鍵として見ることができる。

Metanetはしたがって、ブロックチェーン自体の下にある技術のみを使用して、そのようなデータに対するパーミッショニングおよび書込みアクセス制御を符号化するようにして、オンチェーンデータが構築されることを可能にするプロトコル提供する。Metanetプロトコルは、したがって、ユーザがユーザのオンチェーンコンテンツを証明可能な方法で所有することを可能にするソリューションである。

Metanetプロトコルは、Metanet有向非巡回グラフ(Metanet Direct Acyclic Graph: Metanet DAG)の作成を可能にするルールのセットを定義する。Metanet DAGの単一の事例は、Metanet木と呼ばれる。各Metanet木は、根ノード(最上レベルのノード)を有し、根ノードを含む各Metanetノードは、1つまたは複数の子ノード(たとえば、再び図3参照)を有することができる。

したがって、Metanet DAGは、木の大域集合になり、ここで各木は、それ自体の根ノードから始まり、それ自体の局所化されたパーミッショニング構造を有することができる。

Metanetノード301は単に、Metanetプロトコルのルールセットに従うトランザクションである。2つのタイプのノード、すなわち親のない根ノードと、子ノードとがあり、所与の子ノードは、厳密に1つの親を有する。一実装形態によれば、Metanetノードの最も基本的なアウトライン構造は、以下の基準を満たすトランザクションを必要とする。
・ トランザクションは少なくとも1つのOP_RETURN出力(または、より一般的には、支出不可出力)を有する。
・ OP_RETURNペイロードは、以下を含む。
○ Metanetフラグ。
○ ノードアドレスP_node。
○ 親トランザクションID TxID_parent。
・ 根ノードを除く、各トランザクションが、親ノードによって署名された入力を含む。

同じデータが、たとえば、OP_PUSHDATAを使用して、消費可能な出力に含まれ得ることも排除されない。

上述のように、Metanetノードは、以下の4つの要素を含むトランザクション152である。
・ P_node -ノードのアドレス。
・ TxID_node -ノードのバージョン。
・ P_parent -ノードの親のアドレス。
・ TxID_parent -ノードの親のバージョン。

Metanetエッジ302が、署名によって作成される。親ノードから子ノードへのエッジを作成するために、子ノードは、それの親に関連する鍵ペアを使用して署名されなければならず、Sig P_parentが子ノードの入力に見られなければならない。

いくつかの例では、Metanetトランザクションは、公開鍵Pnode自体ではなく、公開鍵Pnodeに基づくアドレス(たとえば、公開鍵のハッシュ)を備え得ることに留意されたい。

ノードのトランザクションID TxIDnodeは、ノードのバージョンとして解釈され得ることにも留意されたい。同様に、ノードの親のトランザクションID TxIDparentは、親ノードのバージョンとして解釈され得る。ノードバージョニングは、以下で論じられる。

Metanetノードは、図4に示すように、親と子との間のリンクは、子の「ボディ」(すなわち、出力)の中の親のトランザクションIDを有するトランザクションを公開することによって静的に作成されるので、木から切断することはできない。そして、ノード(トランザクション)は、親の秘密鍵を使用して署名される。したがって、Metanetノードは、同じノードの新しいバージョンを作成することによって、またはそれを無効にすることによってのみ、木から排除され得る(ユーザは、それが有効であるかどうかを確認するためにそれを検索することをまだ必要とする)。

トランザクションID TxIDnodeは、ノードのバージョンとして解釈される。同じ公開鍵を有する2つのノードがある(図5に示す)場合、最大のプルーフオブワーク(最新のブロックに挿入されたプルーフオブワーク)を有するトランザクションIDを有するノードが、そのノードの最新のバージョンとして解釈される。

ノードは、削除されるノードに含まれる特定のUTXOを消費する新しいトランザクション(必ずしもMetanetトランザクションではない)を生成することによって削除することができるか、または無効にすることができる。消費されたUTXOを有するノードは、プロトコルによって無効であると見なされ、したがって、木から取り除かれる。

木構造のバージョンを作成する
以下は、Metanet、またはブロックチェーンにオーバーレイされた他のそのようなグラフ構造が、動的木構造、すなわち同じ木の異なるバージョンを作成するために使用され得る方法を説明する。この方法は、以下でMetanetフラックスプロトコル(MFP)と呼ばれることがあるが、これは、都合の良いラベルにすぎず、Metanetと木構造の他のタイプの両方に当てはまることを理解されたい。Metanetフラックスプロトコルに従って作成された木は、Metanetフラックス木と呼ばれる。

いくつかの実施形態では、MFPは、Metanetフラックス木構造を作成するために使用することができ、ここで、木のいくつかのノードは有効であると見なされるが、その他は(たとえば、木がアクセスされる日、または誰が木にアクセスしているかに応じて)無効であると見なされる。重要なことには、ノードは、関連するUTXOを消費する必要なしに無効と見なすことができ、したがって、ブロックチェーンに出されるトランザクションの数が削減される。さらなる特徴および利点が、以下で論じられる。

図7は、本明細書において説明される実施形態を実装するための例示的なシステム700を示す。システム700は、Metanetフラックス木を作成するように構成された木作成者701を備える。木作成者701は、一般に、任意のタイプの関係者(たとえば、個人、個人のグループ、会社など)、または機械もしくはスマートコントラクトなどの自動化エンティティであり得る。木作成者701は、図1および図2に関してAlice 103aおよび/またはBob 103bに起因する動作の一部またはすべてを実行するように構成され得る。たとえば、木作成者701は、ブロックチェーントランザクションを生成すること、ならびにそれらのトランザクションをブロックチェーンネットワーク106に出すことおよび/またはそれらのブロックチェーントランザクションを別の関係者に送ることを行うように構成される。システム700はさらに、ブロックチェーンネットワーク106の1つまたは複数のノードを備える。1人または複数のユーザ702も、システム700の一部であるとして示される。2人のユーザ(ユーザAおよびユーザB)が図7に示されるが、システム700は、任意の数のユーザ702を備えてもよいことが理解されよう。木作成者701と同様に、各ユーザ702は、Alice 103aおよび/またはBob 103bによって実行される動作のいずれかを実行するように構成され得る。しかしながら、これは、いくつかの例では必要ではない。一般に、各ユーザ702は、たとえば、ブロックチェーンノード104を介して、ブロックチェーン150にアクセスするように構成されることのみが必要である。いくつかの例では、各ユーザ702もまた、木作成者701と通信するように、たとえば、パラメータを木作成者701に送信するように構成され得る。通信は、任意のワイヤードまたはワイヤレス接続上にあり得る。

木作成者701および各ユーザ702は、それぞれのコンピュータ機器(図7に示さず)を運用し得る。各関係者のそれぞれのコンピュータ機器は、1つまたは複数のプロセッサ、たとえば、1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサおよび/またはFPGAを備える、それぞれの処理装置を備える。それぞれのコンピュータ機器はさらに、メモリ、すなわち、非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSDなどの電子媒体、フラッシュメモリもしくはEEPROM、および/または光学ディスクドライブなどの光学媒体を利用する1つまたは複数のメモリユニットを備え得る。それぞれのコンピュータ機器のメモリは、処理装置上で実行するようになされる少なくとも1つのそれぞれのクライアントアプリケーションのそれぞれのインスタンスを備えるソフトウェアを記憶する。木作成者701またはユーザ702に対する本明細書に起因するあらゆる活動は、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されるだろう。それぞれのコンピュータ機器は、少なくとも1つのユーザ端末、たとえばデスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを備える。それぞれのコンピュータ機器はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、1つまたは複数の他のネットワーク接続されたリソースを備え得る。それぞれのクライアントアプリケーションは最初に、たとえばサーバからダウンロードされる、あるいは、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光学ディスク、またはリムーバブル光学ドライブなどの、リムーバブルストレージデバイス上で提供される、適切なコンピュータ可読記憶媒体上のそれぞれのコンピュータ機器に提供され得る。

ブロックチェーン150にオーバーレイされた木構造(たとえば、Metanet木)の例は、図3～図6に関して上で説明された。本発明の実施形態に従って作成された木構造は、少なくとも、子ノードを親ノードに接続するエッジが作成され得る方法において、上で説明された木構造と異なる。すなわち、以下の実施形態は、子ノードと親ノードとの間にエッジを形成する新しい方法を説明する。いくつかの例では、木構造の各子ノードは、この新しい方法を使用して形成され得る。他の例では、木構造のいくつかの子ノードのみが、この新しい方法を使用して形成される。

木作成者701は、木構造の少なくとも一部へのアクセスを有する。木構造は、根ノードのみ、または根ノードおよび1つまたは複数の子ノード、たとえば、根ノードの直接の子ノード、もしくは根ノードの1つまたは複数の子ノードおよびそれらの子ノードの1つまたは複数の子ノードなどを備え得る。上で言及されたように、各子ノードは、ブロックチェーントランザクションであり、したがって、トランザクション識別子、たとえば、トランザクションコンテンツの(ダブル)ハッシュを備える。各子ノードはまた、その子ノードが接続される親ノードに関連付けられた公開鍵に対応する署名を(たとえば、トランザクションの入力の中に)備える。署名がその公開鍵を使用して妥当性確認され得る場合、署名は、公開鍵に対応する。

ある時点で、木作成者701は、1つまたは複数の新しい子ノードを作成する。これらの新しい子ノードは、同じ親ノードの(すなわち、同じ親ノードに接続された)子である。親ノードは、根ノードであっても、または木の異なるノードであってもよい。新しい子ノードおよびそれらのノードが接続される親ノードはそれぞれ、以下、ターゲット子ノードおよびターゲット親ノードと呼ばれる。各ターゲット子ノードは、それぞれのデータペイロードを、たとえばトランザクションの出力の中に備える。

木作成者701はまた、各ターゲット子ノードとターゲット親ノードとの間にそれぞれのエッジを形成する。以前の木構造は、トランザクションの出力の中に親ノードのトランザクション識別子を含めることによってエッジを形成する。対照的に、ターゲット子ノードとターゲット親ノードとの間のエッジは、ターゲット子ノードをそれぞれのリンク識別子(ID)に関連付けることによって形成される。リンクIDは、対応するトランザクションの出力に含められることによってターゲット子ノードに関連付けられ得る。出力は、消費可能な出力または支出不可出力であり得る。データ(たとえば、リンクID)は、たとえばOP_PUSHDATAを使用して支出不可出力に含められ得る。データは、たとえばOP_RETURNまたはOP_FALSE OP_RETURNを使用して消費可能な出力に含められ得る。あらゆる他の等価な方法が使用され得る。リンクIDが、異なる方法で、たとえば、対応するトランザクションの入力に含めることによって、ターゲット子ノードに関連付けられ得ることは排除されない。

いくつかの例では、少なくとも2つのターゲット子ノードが、異なるリンクIDに関連付けられる(たとえば、異なるリンクIDを備える)。したがって、少なくとも、木の2つの異なるバージョン(すなわち、表示)が、これらの例の中で作成される。

いくつかの例では、各ターゲット子ノードは、異なるリンクIDに関連付けられ得る。たとえば、ターゲット親ノードが3つのターゲット子ノードを有する場合、それらの3つのターゲット子ノードの各々が、異なるリンクIDに関連付けられ得る。したがって、木の3つのバージョンが作成される。他の例では、1つまたは複数のターゲット子ノードが、同じリンクIDに関連付けられ得る。同じリンクIDに関連付けられたターゲットノードは、木の同じバージョンに属する(すなわち、それの一部を形成する)。

木構造が、たとえばユーザ702によってアクセスされると、ユーザ702は、木の特定のバージョン、たとえば、特定のリンクIDに関連付けられたターゲット子ノードを有するバージョンにアクセスすることを選択することができる。木にアクセスすることは、木の1つまたは複数のノードを検索することを備えることに留意されたい。上記のノードを検索することは、それらのノードを、たとえばメモリに記憶することを備え得る。したがって、ユーザ702は、特定のリンクIDに関連付けられたターゲット子ノードを備え、他のターゲット子ノードを備えない木のバージョンを検索することを選択することができる。他の非ターゲット子ノード、たとえばターゲット親ノードおよび木構造内のターゲット親ノードの上の任意のノードはまだ検索され得、根ノードまで戻って追跡する。同様に、1つまたは複数のターゲット子ノードは、それら自体、1つまたは複数の子ノードのそれぞれの親であり得る。木のバージョンにアクセスすることはまた、特定のリンクIDに関連付けられたターゲット子ノードの子ノードを検索することを備え得る。

リンクIDは、あらゆるタイプのオフチェーンデータに基づき得る。リンクIDは、そのデータを備えることによって、または何か他の方法で、データ「に基づく」ことができる。たとえば、オフチェーンデータの機能に基づいてリンクIDを生成することは、以下で論じられる。

一例として、リンクIDは、時間関連データ、たとえば、日、週、月、年、年月日(たとえば、21/12/21)などのうちの1つまたは複数に基づき得る。たとえば、1つのターゲット子ノードのリンクIDは、1つの月(たとえば、3月)に基づき得るが、別のターゲット子ノードのリンクIDは、異なる月(たとえば、4月)に基づき得る。したがって、木にアクセスするとき、ユーザは、木がアクセスされる月に対応するターゲット子ノードのみにアクセスすることを選択し得る。たとえば、現在の月が4月である場合、ユーザは、そのリンクIDが月「4月」に基づくターゲット子ノードのみにアクセスすることを選択することができる。前月に対応するリンクIDに関連付けられたターゲット子ノードは、無視されて(または、無効と見なされて)検索されず、したがって、ユーザ702によって検索および記憶されるノードの数が削減される。

別の例として、リンクIDは、ユーザ関連データ、すなわち、特定のユーザまたはユーザのグループに関連するデータに基づき得る。たとえば、リンクIDは、以下の名前、住所、誕生日、パスポート番号、電話番号、メールアドレスなどのうちの1つまたは複数に基づき得る。木構造は、特定のアプリケーション、ウェブサイト、サービスなどに関連し得る。そして、リンクIDは、上記のアプリケーション、ウェブサイト、サービスなどのユーザのユーザ名に基づき得る。これらの例は、ターゲット子ノードが、特定のユーザに対して、または特定のユーザのグループに対して作成されることを可能にする。したがって、ユーザは、そのユーザに固有のターゲット子ノードを備える木のバージョンにアクセスすることができる。ここで、ユーザに固有のターゲット子ノードは、そのターゲット子ノードのリンクIDが、そのユーザに関連するデータに基づくことを意味する。同じことが、ユーザのグループに対して適用される。

いくつかの例では、各ターゲット子ノードのそれぞれのリンクIDは、同じタイプのデータに基づき得る。たとえば、各リンクIDは、ユーザ名に基づいてもよく、異なるユーザ名は異なるリンクIDをもたらす。同様に、各リンクIDは、年月日に基づいてもよく、異なる年月日は異なるリンクIDをもたらす。他の例では、1つまたは複数のリンクIDは、1つのタイプのデータ(たとえば、名前)に基づき得るが、1つまたは複数のリンクIDは、異なるタイプのデータ(たとえば、曜日)に基づく。

1つまたは複数のリンクIDは、木作成者701によって生成され得る。そして、木作成者701は、生成されたリンクIDのうちの1つまたは複数を1人または複数のユーザ702に送り得る。木作成者701は、リンクIDのすべてをすべてのユーザ702に送り得る。たとえば、7つのリンクIDが、特定の週のそれぞれの日に対して1つ作成され得る。木作成者は、各ユーザが、特定の曜日に木の特定のバージョンにアクセスすることができるように、リンクIDを各ユーザ702に送り得る。他の例では、木作成者は、特定のリンクIDのみを特定のユーザに送ってもよく、たとえば、ユーザAのデータ(たとえば、ユーザ名)に基づくリンクIDがユーザA 702aにのみ送られ得る一方で、ユーザBのデータに基づくリンクIDがユーザB 702bにのみ送られ得る。

追加または代替として、1つまたは複数のリンクIDが、1人または複数のユーザから受信され得る。たとえば、ユーザA 702aは、彼ら自身のリンクIDを(たとえば、彼らのユーザ固有のデータに基づいて)作成してもよく、それらを木作成者701に送ってもよい。そして、木作成者は、そのユーザ702aから受信されたリンクIDを使用してターゲット子ノードとターゲット親ノードとの間にエッジを形成し得る。ターゲット子ノードは、そのユーザ702aを対象としたデータコンテンツを備え得る。

上で言及されたように、リンクIDは、リンクIDが上記のデータを備えるという点で、データに基づき得る。代替として、リンクIDは、リンクIDがそのデータの関数であるという点で、データに基づき得る。すなわち、データは、リンクIDを生成するように構成された関数のパラメータである。関数は、以下、「リンクID関数」と呼ばれる。リンクIDは、1つまたは複数のパラメータをリンクID関数に入力することによって生成され得る。リンクID関数の一例は、ハッシュ関数である。ハッシュ関数を使用することは、もたらされる各リンクIDが同じ長さを有し、ランダムに生成されるように見えるので有利である。加えて、異なる入力パラメータに基づく場合、2つのリンクIDが同じになる可能性は極めて低く、もたらされたリンクIDのみに基づいて入力パラメータを導出することは、計算上実行不可能である。したがって、入力パラメータ(たとえば、ユーザ名)のプライバシーは維持される。他の関数、たとえば要約関数、結合関数、XOR関数などが、代わりに使用されてもよい。

いくつかの例では、各リンクIDは、1つまたは複数のパラメータをリンクID関数に入力することによって生成される。各リンクIDは、1つまたは複数のパラメータを同じリンクID関数に入力することによって生成され得る。代替として、1つまたは複数のリンクIDは、パラメータを1つのリンクID関数に入力することによって生成され得る一方で、1つまたは複数のリンクIDは、パラメータを異なるリンクID関数に入力することによって生成され得る。

リンクIDは、単一のパラメータのみをリンクID関数に供給することによって、または複数のパラメータをリンクID関数に供給することによって生成され得る。関数に供給されるパラメータは、時間関連パラメータ、ユーザ固有のパラメータ、および重み付けパラメータのうちの1つ、一部またはすべてを備え得る。時間関連パラメータ、たとえば日、週、月、年月日などは、上で論じられた。同様に、ユーザ固有のパラメータ、たとえばユーザ名、誕生日、メールアドレス、連絡先の番号なども、上で論じられた。重み付けパラメータは、以下で論じられる。これらは、使用され得る様々なパラメータの単なる例であり、パラメータの他のタイプ、たとえば会社関連データ(たとえば、会社名、株式ティッカーシンボルなど)、地理関連データ(たとえば、都市、国など)などのユーザを排除しないことに留意されたい。

これらの例では、リンクIDはまた、ターゲット親ノードのトランザクションIDの関数であり得る。たとえば、リンクIDは、ターゲット親ノードのトランザクションIDおよびユーザ702のユーザ名に基づき得る。

各リンクIDは、パラメータの同じセットに基づき得る。代替として、いくつかのリンクIDは、他と比較してパラメータの異なるセットに基づき得る。

1つまたは複数のリンクIDは、1つまたは複数の暗号化されたパラメータ、またはパラメータのセットの暗号化されたバージョンに基づいて生成され得る。たとえば、ユーザ名をリンクID関数に供給するのではなく、ユーザ名の暗号化されたバージョンが、代わりに供給され得る。これは、リンクIDが、データ自体を公開することなく、機密データに基づくことを可能にする。

いくつかの例では、木作成者701は、1つまたは複数のリンクID関数へのアクセスを有し得る。その場合、木作成者は、リンクIDを生成し得る。そして、リンクIDは、1人または複数のユーザ702に送られ得る。これらの例では、木作成者701は、リンクIDを生成するために、どのパラメータがリンクID関数に供給されるかを選択することができる。代替として、ユーザ702は、パラメータのセットを木作成者701に送り得る。そして、木作成者701は、それらのパラメータに基づいてリンクIDを生成し得る。このシナリオは、図7に示され、ここで、ユーザA 702aがパラメータのセットを提供し、ユーザB 702bがパラメータの異なるセットを提供する。リンクID関数は最初に、ユーザ702から木作成者701に提供され得るか、または少なくとも最初に、ユーザ702によって決定され得る。たとえば、ユーザAは、ハッシュ関数を使用することを決定し得るが、ユーザBは、代替の関数を使用することを決定し得る。

いくつかの例では、ユーザ702は、パラメータの1つまたは複数のそれぞれのセットをリンクID関数に供給することによって、1つまたは複数のリンクIDを生成し得る。そして、ユーザ702は、リンクIDを木作成者701に送り得る。

いくつかの例では、プルーフオブワークは、プルーフオブワークが目標の難易度を満たすブロックハッシュを見つけることによってブロックチェーン150のブロック151に埋め込まれる方法に類似して、リンクIDに埋め込まれ得る。これと同様に、プルーフオブワークは、目標の難易度を満たすリンクIDにハッシュする原像を見つけることによって、リンクIDに埋め込まれ得る。すなわち、リンクID関数(たとえば、ハッシュ関数または等価な関数)に供給されるパラメータのセットは、目標の難易度を満たすリンクIDをもたらさなければならない。リンクID関数がハッシュ関数である場合、目標の難易度は、リンクID(すなわち、ハッシュダイジェスト)が先頭の0の数の最小数を有することを要求することによって規定され得る。難易度は、他の方法で、たとえば最小の0の数で終わることで規定され得る。

これを行うために、リンクID関数に入力されるパラメータのうちの1つまたは複数は、静的のままであるが、異なるノンス値が毎回、異なる出力をもたらすために使用される。たとえば、ユーザ名、親ノードトランザクションID、および日は、同じままであり得るが、ノンスは、0から始まる整数においてインクリメントされる。ノンスをインクリメントして結果を計算するプロセスは、有効なリンクIDが見つかるまで繰り返され得る。

各ターゲット子ノードに対して必要とされる難易度は、同じであり得る。言い換えれば、ターゲット子ノードを木に追加するために必要とされるプルーフオブワークは、すべてのターゲット子ノードに対して一致している。代替として、いくつかのターゲット子ノードは、異なる難易度レベルが満たされることを必要とする場合がある。このようにして、あるターゲット子ノードが、別のターゲット子ノードより多量のプルーフオブワークを必要とすることがわかる。したがって、より大きい難易度(たとえば、20個の先頭の0)を満たすリンクIDを有するターゲット子ノードは、より小さい難易度(たとえば、5個の先頭の0)を満たすリンクIDを有するターゲット子ノードより有用なコンテンツを含むことが推測され得る。コンテンツの価値は、必ずしも金銭的な面で測定されるとは限らないことに留意されたい。たとえば、価値は、コンテンツにおける信用の尺度であり得る。たとえば、多量のプルーフオブワークをリンクIDを生成することに投入する木作成者701は、木作成者が信用し、したがってプルーフオブワークを木に追加することに消費する価値があるデータに対してのみ、そのように行い得る。

いくつかの実施形態では、ターゲット子ノードのうちの1つまたは複数は、特定のユーザ702に関連付けられるか、または少なくとも特定のユーザ702を対象とする。言い換えれば、それらのターゲット子ノードは、特定のユーザによってアクセスされるデータペイロードを備える。各ターゲット子ノードが、異なるユーザ702を対象とし得るか、または2つ以上のターゲット子ノードが、同じユーザ702を対象とし得る。本発明の実施形態は、個人ユーザが、どのターゲット子ノードがそのユーザに関連するかを決定すること、したがって関係のあるノードだけを検索することを可能にする。

いくつかの実施形態では、ターゲット子ノードのうちの1つまたは複数が、いくつかの条件のもとで有効または重要であること、たとえば一定の時間期間の間有効であること、または一定のユーザもしくはユーザのグループに対して有効であることを意図するデータを備え得る。たとえば、ターゲット子ノードは、ニュースのコンテンツを備え得る。ターゲット子ノードは、毎日、木に追加され得、そのターゲット子ノードは、その日のニュースを含む。本発明の実施形態は、個人ユーザが、どのターゲット子ノードが有効であるかを決定すること、したがって有効なノードのみを検索することを可能にする。

いくつかの実施形態では、ターゲット子ノードのうちの1つまたは複数は、それぞれのウェブページ、ブログ記事などを備え得る。ウェブページの場合、コンテンツは、特定のユーザに対して調整され得る。したがって、説明された技法は、ユーザ固有のデータに基づいてリンクIDを生成するために使用することができ、そのユーザが関連するウェブページにのみアクセスすることを可能にする。ブログ記事の場合、各ブログ記事のリンクIDは、プルーフオブワークで埋め込まれ得る。したがって、多量のプルーフオブワークを有するブログ記事は、正規であるか、または少なくとも作成者に対して有用であると見なされ得る。木にアクセスするユーザが同じリンクIDを(たとえば、必要とされるノンスを提供されることによって)作成することができるとき、ユーザは、作成者リンクIDを作成することに時間、資金、および努力を費やしたことを確信することができる。ターゲット子ノード内のデータコンテンツ(たとえば、ブログ記事)は、有用である、たとえば信用できると見なされ得る。

ターゲット子ノードに含まれる他のタイプのデータコンテンツは、たとえば、メディアコンテンツ(たとえば、テキスト、画像、ビデオ、オーディオなど)、またはファイル(たとえば、文書、ソフトウェア、オペレーティングシステムなど)を含む。

複数のターゲット子ノードを作成すると、木作成者は、上記のターゲット子ノードのうちの1つまたは複数の、1つまたは複数の子ノードを作成し得る。したがって、ターゲット子ノードは、1つまたは複数の子ノードに対する親になる。それらの子ノードと親との間のエッジは、上で説明された技法を使用して形成され得る。代替として、エッジの一部またはすべては、既存のプロトコル、たとえばMetanetによって使用される技法を使用して形成され得る。

いくつかの実施形態では、ターゲット子ノードとターゲット親ノードとの間のエッジは、1つまたは複数の追加の要素によって、すなわちリンクIDに加えて形成され得る。たとえば、エッジは、ターゲット子ノードが、ターゲット親ノードに関連付けられた公開鍵に対応する署名に関連付けられる(たとえば、トランザクションの入力または出力に含まれる)ことを必要とし得る。

いくつかの実施形態では、各ターゲット子ノードは、ターゲット子ノードをターゲット親ノードに接続するエッジが、開示される実施形態に従って形成されることを示すプロトコルフラグを備え得る。

以下は、関係者(たとえば、ユーザ702)が、開示された実施形態に従って木作成者701によって作成された木の特定のバージョンにどのようにアクセスすることができるかを説明する。方法は、ユーザA 702aによって実行されることに関して説明されるが、方法は、一般に、あらゆる関係者に適用される。ユーザA 702aは、Aliceと呼ばれる。これは、図1に言及して説明されるAlice 103aと同じであってもなくてもよい。

Alice 702aは、ターゲット親ノードを取得する。ターゲットノードは、木の根ノード、または木の異なるノードであり得る。Alice 702aは、たとえば、1つまたは複数の中間ノードを介して、根ノードからターゲット親ノードまでの接続を追跡することによってターゲット親ノードを取得し得る。Alice 702aは、親ノード(ノードアドレスと呼ばれる)に関連付けられたそれぞれの公開鍵を取得することによってターゲット親ノードを取得し得、そして、その公開鍵を含むノードを識別する。ターゲット親ノードは、代替の方法で、たとえば、ターゲット親ノードのトランザクション識別子を使用して、取得され得る。

Alice 702aはまた、たとえば、1つまたは複数のリンクIDを生成すること、および/または木作成者701から1つまたは複数のリンクIDを受信することによって、1つまたは複数のリンクIDを取得する。Alice 702aは、パラメータのセットをリンクID関数に供給することによってリンクIDを生成し得る。Alice 702aは最初に、ターゲット子ノードとターゲット親ノードとの間にエッジを形成するために1つまたは複数のリンクIDを木作成者701に送っていてもよく、または上で説明されたように、木作成者701がリンクIDを生成してもよい。同じく上で説明されたように、Alice 702aは、それぞれのリンクIDを生成するために、パラメータの1つまたは複数のそれぞれのセットを木作成者701に送っていてもよい。

Alice 702aがターゲット親ノードおよびリンクIDを取得する順序が反転されてもよいことが理解されるだろう。とにかく、ターゲット親ノードおよびリンクIDを取得すると、Alice 702aは、取得されたリンクIDのうちのそれぞれのリンクIDに関連付けられたターゲット親ノードの1つまたは複数の子ノードを識別する。これは、たとえば、上記のトランザクションの出力の中に、リンクIDのうちのそれぞれのリンクIDを備えるブロックチェーントランザクションを識別することを備え得る。

そして、Alice 702aは、識別されたターゲット子ノード(すなわち、取得されたリンクIDのうちのそれぞれのリンクIDによって形成されたエッジを介してターゲット親ノードに接続された)を備える木構造のバージョンを作成する。木のAliceのバージョンは、取得されたリンクIDのうちの1つに関連付けられないターゲット子ノード、たとえば、もはや有効でないか、または異なるユーザに関連するターゲット子ノードを備えない。Alice 702aは、木の彼女のバージョンを形成するノードを記憶(たとえば、メモリにダウンロード)し得る。

木構造の彼女のバージョンを取得すると、Aliceは、彼女のバージョンの一部を形成するターゲット子ノードに記憶されたデータを利用し得る。たとえば、Alice 103aは、上記のターゲット子ノードに含まれたデータを使用および/または記憶し得る。データを利用することは、ターゲット子ノードに記憶されたデータのタイプに依存することになる。たとえば、データがウェブページである場合、データを利用することは、ウェブブラウザを使用してウェブページをロードすることを備え得る。データがファイル(たとえば、テキストファイル)である場合、データを利用することは、ワードプロセッサなどのアプリケーションを使用してファイルを開くことを備え得る。

開示される実施形態のさらなる例が、今提供される。これらの例は、Metanetフラックスプロトコルと呼ばれる特定のプロトコルに関して説明されるが、それらはまた、上で説明されたより一般的な例に適用されることが理解されるだろう。

Metanetは静的な木のような構造であり、ここで各ノードは、親ノードに永続的にリンクされる、1つまたは複数の子を作成することができる。上で説明されたように、このリンクは、親のIDを子のトランザクションに挿入することによって作成される。本発明の実施形態は、この静的エッジを本発明の実施形態は、この静的エッジを置き換え、親ノードのIDを新しい一意のIDに置き換え、そのIDは、所与の条件(たとえば、固定された時間期間の間、選択されたユーザに対してのみ)に従ってのみ有効である。この手法は、以下、Metanetフラックスと呼ばれる、動的Metanet構造を有することを可能にする。

2つの異なる時間フレームにおける、この動的構造の例が、図8に示される。木は、静的根ノード(Tx1)から始まるブロックチェーン150から検索される。t=1において、根ノードは、2つの子、ノード2(Tx2)およびノード3(Tx3)を有する。同じ根ノードは、t=2において異なる構造を有し、ノード3(Tx3)はまだ存在する一方で、ノード2(Tx2)は、子ノード2b.1(Tx5)を有するノード2b(Tx4)によって置き換えられている。

Metanetフラックスは、時変の、カスタマイズされた木の設計を可能にし、マルチビュー機能を有する木の作成を可能にする。たとえば、Metanetフラックス構造を使用して作られたウェブサイトは、経時的に変化し得、ユーザに対して個人向けのコンテンツを提供し得る。

Metanetフラックスは、エッジ作成を除いて、標準的なMetanet木の同じルールのうちのいくつかに従い得る。標準的な実装形態では、親ノードから子ノードへのエッジを作成するために、子ノードは、それの親に関連する鍵ペアを使用して署名されなければならず、Sig Pparentが子ノードの入力に、またはそのトランザクション(たとえば、OP_RETURN出力)の別の部分に、見られなければならない。子ノードは、データペイロード(たとえば、OP_RETURNペイロード、またはOP_PUSHDATAペイロード)を含み、データペイロードは、
○ Metanetフラグ。
○ ノードアドレスPnode。
○ 親トランザクションID TxIDparent。
を含む。

フラックス実装形態では、署名プロセスは同じであり得るが、データペイロードは、以下のように改変され得る。
○ Metanetフラックスフラグ。
○ ノードアドレスPnode。
○ オフチェーン変数(たとえば、時間、名前)を使用して決定論的に生成された一意のID。

ノードアドレスは同じであるが、他の2つのフィールドは異なる。特定のフラグが、標準的な実装形態とフラックス実装形態とを区別するために使用され、親トランザクションIDが、一意のIDと置き換えられる。この最後の変化は、静的エッジを、「フラックス」を定義する動的エッジと置き換える。一意のIDが、1つまたは複数の異なるパラメータを組み合わせて、決定論的に生成される(ID生成は、以下のセクションで詳細に説明される)。この方法で、リンクが、ユーザのセットにのみ知られているパラメータを使用して、または時変情報を使用して作成され得る。そのオフチェーン情報を使用してそれの親にリンクされた子は、木が探索されるときに同じ情報が提供され得る場合にのみ、検索される。

この技法は、いくつかの利点を有し、たとえば、それは、期限切れのデータ(たとえば、年月日)を有するリンクは無効になるので、古いノードを自動的に無効にする。さらに、それは、マルチビュー木の作成を可能にし、ここで、各ユーザは異なる一意のID、およびしたがって異なるエッジを生成する(同じ親を有するユーザが、異なる子を検索する)。代替として、それは、重みまたはプルーフオブワークを木エッジに埋め込むために使用され得る。

この手法はまた、プライベートリンクを有するために有用であり、ノードの子は、ビットコインネットワーク内で公開されているが、オーバーレイ構造(たとえば、枝)は、リンクが(オフチェーン変数および/またはIDを作成するために使用される関数が秘密である限り)秘密であるので、再構築することは不可能である。

リンクIDは、外部関数を使用して生成され、Metanetフラックス木作成者またはユーザによって提供される。この関数は、パラメータのリストを入力としてとり、一意のIDを生成する。この一意のIDを生成するための最も単純な方法は、パラメータを連結し、それらをハッシュすることである。たとえば、時変リンクIDが、(標準的なMetanet実装形態のような)親トランザクションIDおよび現在の日を入力パラメータとして使用することができる。
Link ID = hash(parent TxID + day)

日パラメータが変化するとき、リンクIDも変化し、親ノードは、その子をこれ以上検索しない。これは、各親ノードが、新しい日(または月、または時間)ごとに子の異なるセットを検索することを意味する。

同様に、ユーザ名または他の識別子が、リンク作成に含まれ得る。
Link ID = hash(parent TxID + username)

このようにして、異なるユーザが、異なる枝およびノードへのアクセスを有する。ここで、枝またはノードにアクセスすることは、リンクID、およびしたがって親と子ノードとの間のエッジ、および究極的には枝の構造を再作成することができることを意味する。ユーザ名に応じて、リンクは、あるユーザに対して有効であり得るが、別のユーザに対しては有効でない。

リンクID生成関数は、単純なハッシュより複雑であり得、複雑なリンク生成は、外部ユーザに対して、特定の枝を検索することまたは特定のユーザを特定の枝に関連付けることの難易度を高める。リンクID生成関数は、木作成者および木を合法的に検索することを望むユーザによって知られなければならず、または少なくともアクセス可能でなければならない。たとえば、プライバシーを高めるために、ユーザは、リンクID関数を提供することができ、木を作成するエンティティが新しい子を作成する必要があるとき、そのエンティティに(たとえば、APIを使用して)リンクID関数にアクセスさせる。その関数を知らない他のユーザは、パラメータが知られている場合でも、そのリンクを再構築することができない。

本来のMetanetエッジ(図9A)およびMetanetフラックスエッジ(図9B)の作成と除去との間の比較が、図9Aおよび図9Bに示される。例では、Metanetフラックス親ノードが、時変リンクID関数を使用して新しい子を作成している。本来のMetanetに対して、TxID_Cは有効であるが、TxID_Bは、TxID_Dによって無効にされている。Metanetフラックスに対して、TxID_BおよびTxID_Cの妥当性は、関数パラメータ(すなわち、日)に依存する。

本来の実装形態とMetanetフラックス実装形態の両方は、親から子への(実線の矢印、左から右)静的リンクを作成する。これは、ユーザが、所与のノードのすべての子(それらは、親ノードPAから始まるトランザクションである)を見つけることができることを可能にする。

2つの手法の間の主な差は、一方では、本来の実装形態が、子から親へ(破線の矢印、右から左)においても静的リンクも有し、静的で分離できないエッジを作成することである。一方、フラックス実装形態は、所与のいくつかのオフチェーン変数にのみ有効である動的リンク(破線の矢印)を作成する。説明したように、この動的リンクの機能は、ノードが設計によって有効であるかどうかを定義すること、および難読化された情報を埋め込むことである。

いくつかの表示が同じコンテンツにアクセスするために必要であるとき、コンテンツは、それにアクセスすることが必要な各ユーザに対して複製される。これは、リソースの浪費および木の不必要な成長につながる。これを阻止する方法は、追加のパラメータ(たとえば、グループ)を追加すること、およびそれを、リンクIDを生成するために使用することである、
Link ID = hash(parent TxID + group)、
または、より一般的には、
Link ID = link_id(parent TxID, group, username, other parameters)、
ここで、link_idは、任意の適切な関数である。より複雑なリンクID生成関数も可能である。これらの関数は、複数のユーザに対して有効なリンクを作成するために使用することができ、すなわち、入力パラメータの異なる組合せが、同じリンクIDを出力として生成する。これは、2人以上のユーザに対してアクティブなノードまたは枝を有することを可能にする。たとえば、入力としての異なるユーザ名は、いくつかの状況では、同じリンクIDを生成し、したがって、2人以上のユーザに対してアクティブなノードを作ることができる。これは、ユーザのグループの内部のコンテンツを共有して、同じ情報の不必要な複製を避けることを可能にする。

この設計から現れる別の有利な特徴は、リンクを難読化する能力であり、所与のノードのすべての子を常に検索することができるが、構造を再構築すること、および他の情報を推測することは不可能である。本来の実装形態の場合、ユーザに関連付けられたすべてのノードは(ユーザ名が暗号化される場合でも、ハッシュは同じであり)クラスタ化することができ、フラックス実装形態では、ユーザ名が他のパラメータと混合され、したがって、任意の種類の構造を検出すること、または任意の相互関係を推測することは不可能である。

一例として、図10Aでは、ユーザ名は、親ノードのノードに含まれる。この本来のMetanet実装形態では、攻撃者は、木の活動をモニタし、同じユーザに属するすべてのノードをクラスタ化することができる。対照的に、図10Bに示されるフラックス実装形態では、リンクは、それらが運んでいるデータを難読化し、ユーザのプライバシーを高める。

難読化は、ノード(トランザクション)に埋め込まれているデータに適用するだけでなく、木の部分を隠すためにも使用され得、したがって、プライバシーをさらに高める。標準的なMetanet木では、ノードIDへのアクセスを有する場合、そのノードの親は、親ノードのTxIDが子ノードに記憶されるので、見つけられ得る。同様に、親ノードを見つけると、親ノードの親もまた、木の他の枝とともに見つけられ得る。究極的には、木全体が再構築され得る。

しかしながら、Metanetフラックス木では、ノードIDへのアクセスを有する場合、リンクIDのみが子ノード内に存在し、親のTxIDは存在しないので、親ノードを見つけることは不可能である。これは、子ノードの子、およびそれらの子、等々、だけが検索され得ることを意味する。これは、木の特定の枝を(子ノードから葉まで)見て回ることのみ可能であるが、より高いレベルおよび他の枝を検出することはできないことを意味する。これは、木(たとえば、木の部分に記憶されたデータ)のプライバシー面を高める。

いくつかの例では、Metanetフラックス木を検索することを望むユーザ702は、3点の情報、
○ 親ノードID、すなわち、公開鍵Pnode(ユーザが木全体にアクセスしている場合は根ID Proot、または副木のアクセスに対しては任意の他のノードID Pnode)、
○ リンクID生成関数、および
○ リンクIDパラメータ(たとえば、日、ユーザ名、他のデータ)
を必要とする場合がある。

親ノードIDは、ブロックチェーン150内で探索を始めるために使用されるが、リンクID生成関数およびパラメータは、接続された子を探すために使用される。親ノードPnodeから始まる全検索プロセスは、以下のようである。
1.木を検索するために使用される新しいオフチェーンMetanet木構造MTを初期化する。これは、その構造(たとえば、ブラウザ、JSライブラリなどのライブラリ)を使用することを望むあらゆるアプリケーションによって行うことができる。
2.木MTの根としてノードPnodeを設定する。
3.ブロックチェーン150上で公開されるPnodeから開始するすべてのトランザクションPxを収集する。
4.各トランザクションPxに対して、
a.それがMetanetフラックスプロトコルに従うかどうかを検証する(Metanetフラックスフラグを確かめる)。
従わない場合、トランザクションを廃棄してポイント4に戻る。
b.リンクID生成関数およびオフチェーンパラメータが与えられると、リンクIDが有効であるかどうかを検証する。
有効でない場合、トランザクションを廃棄してポイント4に戻る。
c.開始したトランザクションPnodeの子として、トランザクションPxをMetanet構造MTに追加する。
5.木MTに追加された各新しいノードPxに対して、Pnodeから開始するすべてのトランザクションを収集してポイント4から再開する。

いくつかのステップは、異なる順序で実行されてもよい。この方法のすべてのステップが必ずしも、すべての状況において必要とされるとは限らない。たとえば、プロトコルフラグを使用することで、木を形成し得る可能性のあるトランザクションを絞り込み得るが、プロトコルフラグは必須ではない。たとえば、各トランザクションPxは、プロトコルに従うと見なされ得る。

方法は、図11に概略的に示される。ステップS101において、ユーザ702は、新しいオフチェーンオーバーレイ木構造(たとえば、Metanet)を初期化する。ステップS102において、ユーザ702は、たとえば、木作成者701からターゲット親ノードを取得する。ステップS103において、ユーザ702は、ターゲット親ノードから開始するすべてのトランザクションを収集する。そして、ステップS104において、ユーザ702は、各トランザクションがMetanetフラックスプロトコルの要件を満たすことを確かめる。ステップS105において、ユーザ702は、各トランザクションが有効なリンクIDに関連付けられる(たとえば、備える)ことを確かめる。たとえば、ユーザ702は、リンクIDのセットを取得しているか、または生成している場合がある。1つまたは複数のチェックが満たされない場合、チェックに失敗したトランザクションは、S107において廃棄される。すべてのチェックが満たされた場合、トランザクションは、ステップS108において木構造に追加される。

図11に示すように、動的エッジは、現在有効なノード(例におけるオフチェーンパラメータ「日=2」)だけを選択して、軽量の木構造を作成することを可能にする。

例示的な使用事例
図12は、説明された実施形態が、ウェブサイトを、異なる時間間隔で更新されるセクションに分割するために、どのように使用され得るかを示す。たとえば、ウェブサイトの構造は、月次有効性で公開され得、毎日のニュースは、年月日パラメータ(たとえば、「日/月/年」)を使用して毎日公開され得る。ウェブサイトは、その日のニュースだけを示して、より古いニュースをアーカイブセクションで提供することができ、アーカイブセクションは、日のパラメータを換えることによって作成され、関心のある読者だけからのみ検索される。同様に、ウェブサイトは、ログインしたユーザに対してパーソナライズされた体験を提示するようにカスタマイズされ得る。ユーザは、図12に示されるように、カスタムコンテンツを有するウェブサイトの個人向けセクションを検索する。木の有効期間内の更新は、標準的なMetanetプロトコルの無効化ルールに従って達成され得る。

ウェブサイト木は、新しいデータが毎日または毎時追加され、ログインしたユーザはカスタマイズされたコンテンツを予想するので、多数の情報を含む。しかしながら、情報(すなわち、単一のユーザによって検索されたノード)は、ウェブサイト木全体のほんの一部であり、それは、常に軽量であり、更新される。

別の例として、Metanetフラックスは、重みパラメータをリンクID関数に追加することによって、重み付けられた木を作成するために使用され得る。単一のリンクIDは、以下のように作成され得る。
Link ID = hash(parent TxID + weight)

これは、ユーザ702が、所与の重みを有するかまたは最小の重みを有するノードだけを検索することを可能にし、重みが0と5との間であり得、かつ4以上の重みを有するノードだけが検索されるべきである場合、2つのリンクIDが作成され、1つは重み=4を使用し、1つは重み=5を使用する。1つの子ノードが2つのリンクIDのうちの1つと一致する場合、それが検索され、一致しない場合、それは廃棄される。重みは、ノードの新しいバージョンが公開されるとき(たとえば、新しい日が始まるとき)にノードの重みが更新されるように、追加のパラメータ(たとえば、日、バージョン番号)を使用することによって変更され得る。

重み付けられた木は、ウェブサイト、たとえばブログを表す木構造に対して使用され得る。より高い重みは、たとえば、より多くの「いいね(likes)」、より多くの検索、より多くのコメントなどを有するページまたはブログ記事に割り当てられ得る。別の例として、木構造は、配水パイプラインを表し得る。より高い重みが、より高いスループット能力を有するパイプライン内のパイプに割り当てられ得る。したがって、木構造が水を目的地に送付するために使用されるとき、より高い重みを有するパイプで構成されたルートが選択され得る。別の例として、木構造は、ナビゲーション目的のために使用され得る。たとえば、ユーザは、出発地から目的地までのルートを要求し得る。各ノードは、接続点(たとえば、関心のある点、交差点、回り道など)を表し得る。2つのノードを接続する各エッジは、それらのノードによって表される接続点間の道を表す。より高く重み付けられたエッジ(すなわち、より高く重み付けられたリンクIDによって形成される)は、自動車道路を表し得る一方で、より低く重み付けられたエッジは、より小さい道路、レーンを表し得る。目的地へのルートを計算するとき、すなわち、2点(2つのノード)の間のルートを計算するとき、より高い重みを有する道路(エッジ)が、目的地により速く到達するために、またはルート計算速度を改善するために選択され得る。

Metanetフラックスの別のアプリケーションは、エッジに埋め込まれたプルーフオブワーク(PoW)を有する木を作成することであり、すなわち、新しいノードを追加するために、所定の難易度の閾値(ブロック生成のためのPoWの均等物)を満たすリンクIDを生成する必要がある。PoWは、公正を奨励し、スパムを防止する。誰かが、多くのPoWが埋め込まれた木または枝を公開するとき、彼らは、公開されている情報は重要であると信じている(彼らは、単にスパムを送っているのではない)ことを暗黙的に言っている。

リンクID生成関数は、埋め込まれたPoWを有するリンクIDを生成するために使用され得る。新しいノードをPoW Metanet木に追加しようとするサービスまたはユーザは、必要とされる難易度を満たすリンクID(たとえば、所与の数の0で始まるリンク)を作成することを必要とされ得る。ユーザがそのリンクを生成することに失敗する場合、ノードは拒絶される。代替として、それは追加され得るが、木にアクセスするサービスによって検索されない。ブロック作成と同様に、リンクID生成関数は、ノンスを埋め込むことによってPoWを可能にし、それをPoWリンクを作成するために使用することができる。
PoW link ID = link_id(parameters, nonce)
または同様に、
PoW link ID = link_id(old_link_id(parameters), nonce)

PoWリンクIDは、PoWを使用する他のシステムの同じ方法を使用し、ここで、ノンスは、生成されたハッシュが所与の閾値より低い場合に有効である。ブロックチェーンノード104は、報酬と引き換えにノンス探索サービスを提示することができる。作成される子ノードから独立したパラメータだけ(たとえば、親TxIDおよびユーザ名だけ)が使用される場合、PoWが見つかると、そのPoWが、他の子を同じノードに追加するために使用され得ることは注目に値する。これを防止するための1つの方法は、各単一の子ノードに固有のパラメータ、たとえば、入力として使用されるトランザクション(消費されるUTXO)のIDを追加することである。

いくつかの実施形態では、この手法は、埋め込まれたPoWを有するリンクを生成するためにコンテンツ発行者によって使用され得る。ノンスは、ユーザに対して利用可能でなければならず、それにより、彼らは、木を検索しているときにエッジを再構築することができる。

他のアプリケーションでは、有効なノンスが、所与の枝に追加されるべきノードを作成するための意志または努力を表す手段として、ユーザによって(または、ブロックチェーンノード104によって)生成され得る。たとえば、ブログ内で、スレッドは、公開を可能にするために、所定の量のPoWを有するリンクを要求することができる。異なるスレッドは、異なるPoW要件を有することができる。ユーザは、彼らが、コンテンツおよび他の変数とともに有効なノンスを生成することができる場合にのみ、特定のスレッドの中でメッセージ(新しいノード)を公開することができる。

PoWは、新しい子ノードを作成するときのみに使用され、既存のPoW木が読みだされるとき、それ以上のPoWは必要とされないことは注目に値する。唯一の要件は、リンクを生成するために使用されたノンスを知ることである。

ノンスおよび日がともに、リンクIDに埋め込まれる場合、(アプリケーションに応じて)コンテンツ制作者またはユーザは、毎日新しい有効なノードを作成(たとえば、毎日同じコンテンツを再発行)しなければならず、したがって、毎日新しいPoWを生成する。これは、ノードオーナーが、コンテンツがまだ重要である場合にのみ作業を消費することを強制し、無用なまたは古い情報の自動除去につながる。

ここで、PoWは、新しいコンテンツを特定の木/枝の中で公開するための要件として使用される。PoWはまた、フィルタ処理の形態として木ユーザによって使用され得、高いPoWが埋め込まれた木だけを可視化またはダウンロードするように決定され得ることは注目に値する。同様に、これらのユーザは、より重要な/関心のある枝、またはむしろより多くのPoWが埋め込まれた枝をフィルタ処理することによって、木のサイズをさらに削減することができる。

要約すると、Metanetフラックスは、時変の、カスタマイズされた木を作成するための技法である。これは、ユーザが、木の直近に更新されたユーザ固有のバージョンのみを検索することを可能にする。この技法の利点は、迅速な検索および軽量の木を提供すること、および(いくつかのオフチェーンパラメータに従って)異なるユーザまたはグループによってアクセス可能な同じ木の異なるバージョン(表示)を作成することである。さらに、この技法は、重み付けられたMetanet木およびPoW Metanet木の作成を可能にする。最後に、Metanetフラックスは、難読化されたエッジを作成し、ユーザの活動および他の情報を隠す。たとえば、頻繁に更新されるMetanet木は、非常に速く成長することができ、検索および処理することが遅くなる。なぜならば、無効なノードが確かめられて、ユーザによって除去されなければならない(たとえば、ウェブサイトを見て回るユーザは、多くの古い情報をダウンロードすることになる)からである。対照的に、Metanetフラックス木は、無効なノードおよび枝を設計によって枝刈りすることになり、管理効率およびユーザ体験を改善する。一例として、根および無効な子が与えられると、本来のMetanet実装形態を使用して、ユーザは、子を検索して、それが有効かどうかを検証する(たとえば、UTXOが消費されたか、またはこの子の子を探しているかを検証するためにメモリプールを確かめる)べきである。反対に、フラックス実装形態は、単純に有効なエッジを見つけない。さらに、ユーザは、根に接続された子の正確な数を(それらが無効である場合でも)見つけることができるが、同じユーザは、この情報をMetanetフラックスを使用して理解することができない。

Metanetフラックスは、時変の木の生成を可能にし、異なるオフチェーンパラメータを使用して、同じ木の異なるカスタマイズ可能なバージョンの生成を可能にする。加えて、得られた木構造は、標準的なMetanet木より検索が速く、軽量である。木のエッジは難読化される。それは、重み付けられた木の作成も可能にする。また、プルーフオブワークが、木および枝に埋め込まれ得る。

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

たとえば、上のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン150の1つの特定の例であり、上の説明はあらゆるブロックチェーンに一般に当てはまり得ることが理解されるだろう。すなわち、本発明は、決してビットコインブロックチェーンに限定されない。より一般的には、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記のあらゆる言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104に関して置き換えられ得る。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上で説明されたような、ビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明された性質の一部またはすべてを共有し得る。

本発明の好ましい実施形態では、ブロックチェーンネットワーク106は、ビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成する、公開する、広める、および記憶する、説明された機能の少なくともすべてを実行する。これらの機能のすべてではなく1つまたは一部だけを実行する他のネットワークエンティティ(またはネットワーク要素)があり得ることは排除されない。すなわち、ネットワークエンティティは、ブロックを作成して公開することなく、ブロックを広めるおよび/または記憶する機能を実行し得る(これらのエンティティは好ましいビットコインネットワーク106のノードであるとは考えられないことを思い出されない)。

本発明の他の実施形態では、ブロックチェーンネットワーク106はビットコインネットワークではないことがある。これらの実施形態では、ノードが、ブロックチェーン150のブロック151を作成し、公開し、広め、記憶する機能のすべてではなく、少なくとも1つまたは一部を実行し得ることは排除されない。たとえば、それらの他のブロックチェーンネットワークでは、「ノード」は、ブロック151を作成して公開するが、それらのブロック151を記憶せず、かつ/または他のノードに広めないように構成される、ネットワークエンティティを指すために使用されることがある。

またさらに一般的には、上記の「ビットコインノード」104という用語へのあらゆる言及は、「ネットワークエンティティ」または「ネットワーク要素」という用語で置き換えられてもよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、広め、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104に関して上で説明されたのと同じ方法でハードウェアにおいて実装され得る。

上記の実施形態は単に例として説明されたことが諒解されよう。より一般的には、以下の陳述のうちのいずれか1つまたは複数による方法、装置、またはプログラムが提供され得る。

陳述1:ブロックチェーンにオーバーレイされた木構造の異なるバージョンを作成するコンピュータ実装方法であって、木構造がノードのセットとノード間のエッジとを備え、各ノードがブロックチェーンに記録された異なるトランザクションであり、各エッジがそれぞれの子ノードからそれぞれの親ノードに接続し、親ノードの1つが木構造の根ノードであり、各ノードがそれぞれの鍵に関連付けられ、各子ノードが、i)それぞれのトランザクション識別子と、ii)それぞれの親ノードに関連付けられたそれぞれの鍵に対応する署名とを備え、方法は、木作成者によって実行され、
ターゲット親ノードの1つまたは複数のターゲット子ノードを作成するステップであって、各ターゲット子ノードがそれぞれのデータペイロードを備える、ステップと、
ターゲット子ノードの各々をそれぞれのリンク識別子に関連付けることによって各ターゲット子ノードとターゲット親ノードとの間にそれぞれのエッジを形成するステップとを備え、それぞれのリンク識別子は、少なくとも1つのオフチェーンパラメータに基づく、コンピュータ実装方法。

陳述2:ターゲット子ノードのうちの少なくとも2つが、異なるそれぞれのリンク識別子に関連付けられる、陳述1に記載の方法。

陳述3:ターゲット子ノードの各々が、異なるそれぞれのリンク識別子に関連付けられる、陳述1または陳述2に記載の方法。

陳述4:それぞれのリンク識別子のうちの1つ、一部、または各々を生成するステップを備える、陳述1から3のいずれか1つに記載の方法。

陳述5:木作成者以外の1つまたは複数のエンティティから、それぞれのリンク識別子のうちの1つ、一部、または各々を受信するステップを備える、陳述1から4のいずれか1つに記載の方法。

陳述6:それぞれのリンク識別子のうちの1つ、一部、または各々は、オフチェーンパラメータのそれぞれのセットを、パラメータのセットに基づいてリンク識別子を生成するように構成されたそれぞれのリンク識別子関数に供給することによって生成される、陳述1から5のいずれか1つに記載の方法。

陳述7:それぞれのリンク識別子のうちの1つ、一部、または各々は、オフチェーンパラメータのそれぞれのセットを、同じリンク識別子関数に供給することによって生成される、陳述6に記載の方法。

陳述8:それぞれのリンク識別子のうちの少なくとも2つが、オフチェーンパラメータのそれぞれのセットを、異なるリンク識別子関数に供給することによって生成される、陳述7に記載の方法。

陳述9:それぞれのリンク識別子関数に供給されたオフチェーンパラメータのそれぞれのセットが、以下の、1つまたは複数の時間関連パラメータ、1つまたは複数のユーザ固有のパラメータ、ユーザのグループに固有の1つまたは複数のパラメータ、1つまたは複数の重み付きパラメータ、1つまたは複数のデータセット固有のパラメータ、および1つまたは複数のアプリケーション固有のパラメータ、のうちの1つ、一部、または各々を備える、陳述6またはそれに従属するいずれかの陳述に記載の方法。

時間関連パラメータは、たとえば、時間、時間期間、日、月、週、年などのうちの1つまたは複数を含み得る。ユーザ固有のパラメータは、たとえば、名前、住所、誕生日、ユーザ名、メール、電話番号などを含む。グループに固有のパラメータは、グループ名、グループ識別子、グループロケーション、グループ内のユーザの数などを備え得る。データセット固有のパラメータは、データの主題(たとえば、トピック)に関連するパラメータであり、たとえば、主題は自動車であり得、パラメータは、ライセンスプレート番号、自動車のメーカー、自動車のモデル、および/または自動車の使用年数などを含み得る。同様に、アプリケーション固有のパラメータは、特定のアプリケーションに関連するパラメータである。たとえば、アプリケーションは、ウェブサイト(たとえば、ソーシャルメディアサイト)であり得、パラメータは、ウェブサイト名、ウェブサイトアドレス、および/またはウェブサイトのページなどを含み得る。

陳述10:オフチェーンパラメータのそれぞれのセットに加えて、ターゲット親ノードのトランザクション識別子もまた、それぞれのリンク識別子を生成するためにそれぞれのリンク識別子関数に供給される、陳述9に記載の方法。

陳述11:リンク識別子関数に供給されたパラメータのそれぞれのセットのうちの1つまたは複数が、暗号化される、陳述6またはそれに従属するいずれかの陳述に記載の方法。

陳述12:それぞれのリンク識別子のうちの1つ、一部、または各々が、少なくとも1つの同じパラメータの異なる値に基づいて生成される、陳述6またはそれに従属するいずれかの陳述に記載の方法。

陳述13:リンク識別子関数が、ハッシュ関数を備える、陳述6またはそれに従属するいずれかの陳述に記載の方法。

陳述14:ターゲット子ノードのうちの1つ、一部、または各々が、それぞれのユーザに関連付けられる、陳述1から13のいずれか1つに記載の方法。

陳述15:ターゲット子ノードの各々が、異なるユーザに関連付けられる、陳述14に記載の方法。

陳述16:ターゲット子ノードのうちの少なくとも2つが、同じユーザに関連付けられる、陳述14に記載の方法。

陳述17:1つまたは複数のそれぞれのリンク識別子を1つまたは複数の異なるエンティティから受信するステップが、1つまたは複数のそれぞれのリンク識別子を1人または複数のそれぞれのユーザから受信するステップを備える、陳述5に従属する場合の陳述14から16のいずれか1つに記載の方法。

陳述18:1つまたは複数のそれぞれのリンク識別子を1人または複数のそれぞれのユーザから受信するステップを備える、陳述6に従属する場合の陳述14から17のいずれか1つに記載の方法。

陳述19:パラメータの1つまたは複数のそれぞれのセットを1人または複数のそれぞれのユーザから受信するステップを備える、陳述6に従属する場合の陳述14から18のいずれか1つに記載の方法。

陳述20:所定の難易度を満たすそれぞれのリンク識別子を生成することによって少なくとも1つのターゲット子ノードと親ノードとの間のそれぞれのエッジにプルーフオブワークを埋め込むステップを備え、それぞれのリンク識別子が、パラメータのそれぞれのセットおよびノンス値をそれぞれのリンク識別子関数に供給することによって生成される、陳述6またはそれに従属するいずれかの陳述に記載の方法。

リンク識別子は、たとえば、それが、所定の数の先頭の0を備える場合に、所定の難易度を見たし得る。

陳述21:各ターゲット子ノードのそれぞれのデータペイロードが、ウェブページ、
ブログ記事、ファイル、メディアコンテンツ、ユーザ識別子、自己主権型アイデンティティ、サプライチェーンの構成要素、アクセス制御データ、のうちの1つを備えるか、そうでない場合にはそれらのうちの1つを表す、陳述1から20のいずれか1つに記載の方法。

陳述22:ターゲット子ノードのうちの少なくとも1つに対して、
1つまたは複数の追加のターゲット子ノードを作成するステップと、
各ターゲット追加子ノードと親ノードとの間にそれぞれのエッジを形成するステップとを備える、陳述1から21のいずれか1つに記載の方法。

陳述23:
異なるターゲット親ノードの1つまたは複数のターゲット子ノードを作成するステップであって、各ターゲット子ノードはそれぞれのデータペイロードを備える、ステップと、
ターゲット子ノードの各々をそれぞれのリンク識別子に関連付けることによって各ターゲット子ノードと異なるターゲット親ノードとの間にそれぞれのエッジを形成するステップとを備え、それぞれのリンク識別子は、少なくとも1つのオフチェーンパラメータに基づく、陳述1から22のいずれか1つに記載の方法。

陳述24:ブロックチェーンにオーバーレイされた木構造にアクセスするコンピュータ実装方法であって、木構造がノードのセットとノード間のエッジとを備え、各ノードがブロックチェーンに記録された異なるトランザクションであり、各エッジがそれぞれの子ノードからそれぞれの親ノードに接続し、親ノードの1つが木構造の根ノードであり、各ノードがそれぞれの鍵に関連付けられ、各子ノードが、i)それぞれのトランザクション識別子と、ii)それぞれの親ノードに関連付けられたそれぞれの鍵に対応する署名とを備え、ターゲット親ノードが複数のターゲット子ノードに接続され、各ターゲット子ノードがそれぞれのデータペイロードを備え、ターゲット子ノードの各々がそれぞれのリンク識別子に関連付けられ、それぞれのリンク識別子が少なくとも1つのオフチェーンパラメータに基づき、方法は、木アクセサによって実行され、
ターゲット親ノードを取得するステップと、
1つまたは複数のリンク識別子を取得するステップと、
取得された1つまたは複数のリンク識別子のうちのそれぞれのリンク識別子に関連付けられたターゲット子ノードのうちの1つまたは複数を識別するステップと、
識別されたターゲット子ノードのうちの1つまたは複数を備えるが、取得された1つまたは複数のリンク識別子のうちのそれぞれのリンク識別子に関連付けられていると識別されないターゲット子ノードを備えない木構造のバージョンを作成するステップとを備える、コンピュータ実装方法。

陳述25:木構造の作成されたバージョンを形成するターゲット子ノードのうちの1つまたは複数に対して、そのターゲット子ノードが備えるそれぞれのデータペイロードにアクセスすること、記憶すること、および/または使用することのうちの少なくとも1つを実行するステップを備える、陳述24に記載の方法。

陳述26:的親ノードを前記取得するステップが、ターゲット親ノードに関連付けられたそれぞれの鍵を取得するステップと、それぞれの鍵を使用してその鍵に関連付けられたブロックチェーントランザクションを識別するステップとを備える、陳述24または陳述25に記載の方法。

陳述27:1つまたは複数のターゲット子ノードを前記識別するステップが、取得されたリンク識別子のうちのそれぞれのリンク識別子を備える1つまたは複数のブロックチェーントランザクションを識別するステップを備える、陳述24から26のいずれか1つに記載の方法。

陳述28:取得されたリンク識別子のうちの少なくとも1つが、木作成者に送られたオフチェーンパラメータのそれぞれのセットに基づいて生成される、陳述24から27のいずれか1つに記載の方法。

陳述29:1つまたは複数のリンク識別子を前記取得するステップが、1つまたは複数のリンク識別子のうちの少なくとも1つを生成するステップを備える、陳述24から28のいずれか1つに記載の方法。

陳述30:1つまたは複数のリンク識別子のうちの少なくとも1つを前記生成するステップが、オフチェーンパラメータのセットをリンク識別子関数に供給するステップを備える、陳述26に記載の方法。

陳述31:1つまたは複数のリンク識別子のうちの少なくとも1つを前記生成するステップが、オフチェーンパラメータのセットおよびノンス値をリンク識別子に供給するステップを備える、陳述28に記載の方法。

ノンス値は、木作成者または他の場所から取得され得、たとえば、それは、インターネット上、ブロックチェーン上などに公開され得る。

陳述32:1つまたは複数のリンク識別子を前記取得するステップが、1つまたは複数のリンク識別子のうちの少なくとも1つを、木構造を作成する責任を負う木作成者から受信するステップを備える、陳述24から31のいずれか1つに記載の方法。

陳述33:木構造がMetanetグラフである、陳述1から32のいずれか1つに記載の方法。

陳述34:コンピュータシステムであって、
1つまたは複数の処理ユニットを備える処理装置と、
1つまたは複数のメモリユニットを備えるメモリとを備え、
メモリは、処理装置上で実行するようになされるコードを記憶し、コードは、処理装置上で実行するとき、陳述1から33のいずれか1つに従って動作を実行するように構成される、コンピュータシステム。

陳述35:コンピュータ可読ストレージ上に具現化されたコンピュータプログラムであって、1つまたは複数の処理ユニット上で実行するとき、陳述1から33のいずれか1つに従って動作を実行するように構成されたコードを備える、コンピュータプログラム。

本明細書で開示する別の態様によれば、木作成者および木アクセサの活動を備える方法が提供され得る。

本明細書で開示する別の態様によれば、木作成者および木アクセサのコンピュータ機器を備えるシステムが提供され得る。

100 システム
101 パケット交換ネットワーク
102 コンピュータ/コンピュータ機器
103 ユーザ/関係者/エージェント
103a Alice/エンティティ/第1の関係者
103b Bob/エンティティ/第2の関係者
104 ノード/ブロックチェーンノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク/ブロックチェーンネットワーク
150 ブロックチェーン
151 ブロック
152 トランザクション
152C トランザクション
152F トランザクション
152i トランザクション
152j トランザクション
152N トランザクション
152P トランザクション
153 ジェネシスブロック(Gb)
154 順序付けられたセット/順序付けられたプール/プール/トランザクション
201 ヘッダ
202 入力/入力フィールド
203 支出不可出力/トランザクション出力/出力/出力フィールド/UTXO
300 オーバーレイネットワーク/Metanetネットワーク/Metanet/レイヤ2オーバーレイネットワーク
301 ノード/親ノード/子/Metanetノード/子ノード
301C 子ノード/Metanet子ノード
301P 親ノード
302 エッジ/Metanetエッジ
402 エッジ
700 システム
701 木作成者
702 ユーザ
702a ユーザA
702b ユーザB

Claims (38)

1. ブロックチェーンにオーバーレイされた木構造の異なるバージョンを作成するコンピュータ実装方法であって、
   前記木構造が、ノードのセットと、ノード間のエッジとを備え、
   各ノードが、前記ブロックチェーンに記録された異なるトランザクションであり、
   各エッジが、それぞれの子ノードからそれぞれの親ノードに接続し、
   前記親ノードの1つが、前記木構造の根ノードであり、
   各ノードが、それぞれの鍵に関連付けられ、
   各子ノードが、i)それぞれのトランザクション識別子と、ii)それぞれの親ノードに関連付けられたそれぞれの鍵に対応する署名とを備え、
   前記コンピュータ実装方法は、木作成者によって実行され、
   ターゲット親ノードの1つまたは複数のターゲット子ノードを作成するステップであって、各ターゲット子ノードがそれぞれのデータペイロードを備える、ステップと、
   前記ターゲット子ノードの各々をそれぞれのリンク識別子に関連付けることによって各ターゲット子ノードと前記ターゲット親ノードとの間にそれぞれのエッジを形成するステップと
   を備え、前記それぞれのリンク識別子は、少なくとも1つのオフチェーンパラメータに基づく、
   コンピュータ実装方法。
2. 前記ターゲット子ノードのうちの少なくとも2つが、異なるそれぞれのリンク識別子に関連付けられる、請求項1に記載の方法。
3. 前記ターゲット子ノードの各々が、異なるそれぞれのリンク識別子に関連付けられる、請求項1に記載の方法。
4. 前記それぞれのリンク識別子のうちの1つ、一部、または各々を生成するステップを備える、請求項1に記載の方法。
5. 前記木作成者以外の1つまたは複数のエンティティから、前記それぞれのリンク識別子のうちの1つ、一部、または各々を受信するステップを備える、請求項1に記載の方法。
6. 前記それぞれのリンク識別子のうちの1つ、一部、または各々が、オフチェーンパラメータのそれぞれのセットを、パラメータのセットに基づいてリンク識別子を生成するように構成されたそれぞれのリンク識別子関数に供給することによって生成される、請求項1に記載の方法。
7. 前記それぞれのリンク識別子のうちの1つ、一部、または各々が、オフチェーンパラメータのそれぞれのセットを同じリンク識別子関数に供給することによって生成される、請求項6に記載の方法。
8. 前記それぞれのリンク識別子のうちの少なくとも2つが、オフチェーンパラメータのそれぞれのセットを異なるリンク識別子関数に供給することによって生成される、請求項7に記載の方法。
9. 前記それぞれのリンク識別子関数に供給されたオフチェーンパラメータの前記それぞれのセットが、
   1つまたは複数の時間関連パラメータ、
   1つまたは複数のユーザ固有のパラメータ、
   ユーザのグループに固有の1つまたは複数のパラメータ、
   1つまたは複数の重み付きパラメータ、
   1つまたは複数のデータセット固有のパラメータ、および
   1つまたは複数のアプリケーション固有のパラメータ
   のうちの1つ、一部、または各々を備える、請求項6に記載の方法。
10. オフチェーンパラメータの前記それぞれのセットに加えて、前記ターゲット親ノードのトランザクション識別子もまた、前記それぞれのリンク識別子を生成するために前記それぞれのリンク識別子関数に供給される、請求項9に記載の方法。
11. 前記リンク識別子関数に供給されたパラメータの前記それぞれのセットのうちの1つまたは複数が、暗号化される、請求項6に記載の方法。
12. 前記それぞれのリンク識別子のうちの1つ、一部、または各々が、少なくとも1つの同じパラメータの異なる値に基づいて生成される、請求項6に記載の方法。
13. 前記リンク識別子関数が、ハッシュ関数を備える、請求項6に記載の方法。
14. 前記ターゲット子ノードのうちの1つ、一部、または各々が、それぞれのユーザに関連付けられる、請求項1に記載の方法。
15. 前記ターゲット子ノードの各々が、異なるユーザに関連付けられる、請求項14に記載の方法。
16. 前記ターゲット子ノードのうちの少なくとも2つが、同じユーザに関連付けられる、請求項14に記載の方法。
17. 前記ターゲット子ノードのうちの少なくとも2つが、同じユーザに関連付けられ、1つまたは複数のそれぞれのリンク識別子を前記1つまたは複数の異なるエンティティから受信するステップが、1つまたは複数のそれぞれのリンク識別子を1人または複数のそれぞれのユーザから受信するステップを備える、請求項5に記載の方法。
18. 前記ターゲット子ノードのうちの1つ、一部、または各々が、それぞれのユーザに関連付けられ、1つまたは複数のそれぞれのリンク識別子を1人または複数のそれぞれのユーザから受信するステップを備える、請求項6に記載の方法。
19. 前記ターゲット子ノードのうちの1つ、一部、または各々が、それぞれのユーザに関連付けられ、パラメータの1つまたは複数のそれぞれのセットを1人または複数のそれぞれのユーザから受信するステップを備える、請求項6に記載の方法。
20. 所定の難易度を満たすそれぞれのリンク識別子を生成することによって、少なくとも1つのターゲット子ノードと前記親ノードとの間の前記それぞれのエッジにプルーフオブワークを埋め込むステップを備え、
    前記それぞれのリンク識別子が、パラメータの前記それぞれのセットおよびノンス値を前記それぞれのリンク識別子関数に供給することによって生成される、請求項6に記載の方法。
21. 各ターゲット子ノードの前記それぞれのデータペイロードが、
    ウェブページ、
    ブログ記事、
    ファイル、
    メディアコンテンツ、
    ユーザ識別子、
    自己主権型アイデンティティ、
    サプライチェーンの構成要素、
    アクセス制御データ
    のうちの1つを備えるか、そうでない場合にはそれらのうちの1つを表す、請求項1に記載の方法。
22. 前記ターゲット子ノードのうちの少なくとも1つに対して、
    1つまたは複数の追加のターゲット子ノードを作成するステップと、
    各ターゲット追加子ノードと前記親ノードとの間にそれぞれのエッジを形成するステップと
    を備える、請求項1に記載の方法。
23. 異なるターゲット親ノードの1つまたは複数のターゲット子ノードを作成するステップであって、各ターゲット子ノードはそれぞれのデータペイロードを備える、ステップと、
    前記ターゲット子ノードの各々をそれぞれのリンク識別子に関連付けることによって、各ターゲット子ノードと前記異なるターゲット親ノードとの間にそれぞれのエッジを形成するステップと
    を備え、前記それぞれのリンク識別子は、少なくとも1つのオフチェーンパラメータに基づく、請求項1に記載の方法。
24. 前記木構造がMetanetグラフである、請求項1に記載の方法。
25. ブロックチェーンにオーバーレイされた木構造にアクセスするコンピュータ実装方法であって、
    前記木構造が、ノードのセットと、ノード間のエッジとを備え、
    各ノードが、前記ブロックチェーンに記録された異なるトランザクションであり、
    各エッジが、それぞれの子ノードからそれぞれの親ノードに接続し、
    前記親ノードの1つが、前記木構造の根ノードであり、
    各ノードが、それぞれの鍵に関連付けられ、
    各子ノードが、i)それぞれのトランザクション識別子と、ii)前記それぞれの親ノードに関連付けられた前記それぞれの鍵に対応する署名とを備え、
    ターゲット親ノードが、複数のターゲット子ノードに接続され、
    各ターゲット子ノードが、それぞれのデータペイロードを備え、
    前記ターゲット子ノードの各々が、それぞれのリンク識別子に関連付けられ、
    前記それぞれのリンク識別子が、少なくとも1つのオフチェーンパラメータに基づき、
    前記コンピュータ実装方法は、木アクセサによって実行され、
    前記ターゲット親ノードを取得するステップと、
    1つまたは複数のリンク識別子を取得するステップと、
    前記取得された1つまたは複数のリンク識別子のうちのそれぞれのリンク識別子に関連付けられた前記ターゲット子ノードのうちの1つまたは複数を識別するステップと、
    前記識別されたターゲット子ノードのうちの1つまたは複数を備えるが、前記取得された1つまたは複数のリンク識別子のうちのそれぞれのリンク識別子に関連付けられていると識別されないターゲット子ノードを備えない前記木構造のバージョンを作成するステップと
    を備える、コンピュータ実装方法。
26. 前記木構造の前記作成されたバージョンを形成する前記ターゲット子ノードのうちの1つまたは複数に対して、そのターゲット子ノードが備える前記それぞれのデータペイロードにアクセスすること、前記それぞれのデータペイロードを記憶すること、および/または前記それぞれのデータペイロードを使用することのうちの少なくとも1つを実行するステップを備える、請求項25に記載の方法。
27. 前記ターゲット親ノードを前記取得するステップが、前記ターゲット親ノードに関連付けられた前記それぞれの鍵を取得するステップと、前記それぞれの鍵を使用してその鍵に関連付けられたブロックチェーントランザクションを識別するステップとを備える、請求項25に記載の方法。
28. 前記1つまたは複数のターゲット子ノードを前記識別するステップが、前記取得されたリンク識別子のうちのそれぞれのリンク識別子を備える1つまたは複数のブロックチェーントランザクションを識別するステップを備える、請求項25に記載の方法。
29. 前記取得されたリンク識別子のうちの少なくとも1つが、木作成者に送られたオフチェーンパラメータのそれぞれのセットに基づいて生成される、請求項25に記載の方法。
30. 前記1つまたは複数のリンク識別子を前記取得するステップが、前記1つまたは複数のリンク識別子のうちの少なくとも1つを生成するステップを備える、請求項25に記載の方法。
31. 前記1つまたは複数のリンク識別子のうちの少なくとも1つを生成するステップが、オフチェーンパラメータのセットをリンク識別子関数に供給するステップを備える、請求項27に記載の方法。
32. 前記1つまたは複数のリンク識別子のうちの少なくとも1つを生成するステップが、オフチェーンパラメータの前記セットおよびノンス値を前記リンク識別子に供給するステップを備える、請求項29に記載の方法。
33. 前記1つまたは複数のリンク識別子を前記取得するステップが、前記1つまたは複数のリンク識別子のうちの少なくとも1つを、前記木構造を作成する責任を負う木作成者から受信するステップを備える、請求項25に記載の方法。
34. 前記木構造がMetanetグラフである、請求項25に記載の方法。
35. コンピュータシステムであって、
    1つまたは複数の処理ユニットを備える処理装置と、
    1つまたは複数のメモリユニットを備えるメモリと
    を備え、
    前記メモリは、前記処理装置上で実行するように構成されたコードを記憶し、前記コードは、前記処理装置上で実行されると、請求項1から24のいずれか一項に記載の方法を実行するように構成される、
    コンピュータシステム。
36. コンピュータ可読ストレージ上に具現化されたコンピュータプログラムであって、1つまたは複数の処理ユニット上で実行されると、請求項1から24のいずれか一項に記載の方法を実行するように構成されたコードを備える、コンピュータプログラム。
37. コンピュータシステムであって、
    1つまたは複数の処理ユニットを備える処理装置と、
    1つまたは複数のメモリユニットを備えるメモリと
    を備え、
    前記メモリは、前記処理装置上で実行するように構成されたコードを記憶し、前記コードは、前記処理装置上で実行されると、請求項25から34のいずれか一項に記載の方法を実行するように構成される、
    コンピュータシステム。
38. コンピュータ可読ストレージ上に具現化されたコンピュータプログラムであって、1つまたは複数の処理ユニット上で実行されると、請求項25から34のいずれか一項に記載の方法を実行するように構成されたコードを備える、コンピュータプログラム。