JP2024102053A - ブロックチェーンネットワークを介するデータの効率的且つセキュアな処理、アクセス、及び送信のためのシステム及び方法 - Google Patents

Abstract

【課題】ブロックチェーン上のデータを格納し、共有し、読み出し、書き込み及びアクセスする改良された方法及びシステムを提供する。
【解決手段】方法は、プロトコルフラグと任意公開鍵と任意トランザクションＩＤとを含む少なくとも１つのブロックチェーントランザクションを処理するステップを含む。これらは、ブロックチェーンプロトコルの部分として要求されない。この組合せは、データ部分をブロックチェーン上で識別し、読み出し、及び共有できるようにし、更に、複数のトランザクションの中で提供されるとき、互いにリンクされ／関連付けられることを可能にする。それは、データ部分の間の階層的関係を反映し、それらの処理、検索、及び共有を実現する、グラフ又はツリーのような構造を構成する。
【選択図】図１

Description

本発明は、概して、電子ネットワーク、特にブロックチェーンネットワークのようなピアツーピアネットワークに渡るデータ通信及び交換のための改良に関する。本発明は、データ記憶、アクセス、検索、及び処理に関し、特に、ブロックチェーン上のこのようなデータ関連動作に関する。本発明は、特に、限定ではないが、ウェブサイト及びウェブページにより提供されるものと同様の方法で、しかし基礎となるメカニズム又はプラットフォームとしてウェブサーバではなくブロックチェーンを用いて、データを処理する際に使用することに適する。従って、本発明は、セキュアな効率的な暗号法により実施される、データ処理及び転送のための代替的インフラストラクチャを提供する。

本願明細書では、私たちは、全ての形式の電子的な、コンピュータに基づく、分散型台帳を包含するために用語「ブロックチェーン」を使用する。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、並びにこれらの変形を含む。他のブロックチェーン実装が提案され開発されているが、ブロックチェーン技術の最も広く知られているアプリケーションは、Bitcoin台帳である。Bitcoinは、ここでは、便宜上及び説明の目的で参照されることがあるが、本発明はBitcoinブロックチェーンと共に使用することに限定されず、代替のブロックチェーン実装及びプロトコルが本発明の範囲に包含されることに留意すべきである。用語「ユーザ」は、ここでは、人間又はプロセッサに基づくリソースを表してよい。用語「Bitcoin」は、ここでは、Bitcoinプロトコルから派生するプロトコルの全ての変形及びバージョンを包含するために使用される。

ブロックチェーンは、コンピュータに基づく非集中型の分散型システムとして実装されるピアツーピアの電子台帳であり、ブロックにより構成され、ブロックはまたトランザクションにより構成される。各トランザクションは、ブロックチェーンシステムの中の参加者間でデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、これらのブロックは一緒に繋げられて、起源以来ブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能な記録を生成する。トランザクションは、スクリプトとして知られている小さなプログラムを含む。スクリプトは、それらのインプット及びアウトプットを埋め込まれ、トランザクションのアウトプットがどのように及び誰によりアクセス可能であるかを指定する。Bitcoinプラットフォームでは、これらのスクリプトはスタックに基づくスクリプト言語を用いて記述される。

トランザクションがブロックチェーンに書き込まれるためには、検証されなければならない。ネットワークノード（マイナー）は、無効なトランザクションがネットワークから拒否され、各トランザクションが有効であることを保証するために作業を実行する。ノードにインストールされたソフトウェアクライアントは、未使用トランザクション（unspent transaction, UTXO）のロック及びアンロックスクリプトを実行することにより、UTXOに対してこの検証作業を実行する。ロック及びアンロックスクリプトの実行が真（TRUE）と評価する場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。従って、トランザクションがブロックチェーンに書き込まれるためには、（ｉ）トランザクションを受信した第１ノードにより検証され、トランザクションが有効な場合には、ノードが該トランザクションをネットワーク内の他のノードに中継する、（ｉｉ）マイナーにより構築された新しいブロックに追加される、（ｉｉｉ）マイニングされる、つまり過去のトランザクションの公開台帳に追加される、ことが必要である。

ブロックチェーン技術は、暗号通貨の実装の使用のために最も広く知られているが、デジタル事業家が、Bitcoinの基づく暗号セキュリティシステム及び新しいシステムを実装するためにブロックチェーンに格納できるデータの両方の使用を開発し始めている。ブロックチェーンが、暗号通貨の分野に限定されないタスク及びプロセスのために使用できれば、非常に有利になる。このようなソリューションは、ブロックチェーンの利益（例えば、永久性、イベントの記録の耐タンパ性、分散型処理、等）を利用しながら、それらの用途をより多様化し得る。

１つのこのような関心分野は、ユーザ間のデータの記憶、共有、アクセス及び制御のためにブロックチェーンを使用することである。今日、これは、インターネットにより達成され、標準的に検索エンジンにより所望のデータにアクセスするためにユーザが訪問するウェブサイト及びページをホスティングするサーバを伴う。

しかしながら、一部の観察者は、中央パーティによる膨大なデータ及びコンテンツの制御のような、インターネットの欠点の幾つかを解決するために、ブロックチェーンの使用を考え始めている。例えば、以下を参照のこと：Life After Google: The Fall of Big Data and the Rise of the Blockchain Economy”, George Gilder, Gateway Editions, July ２０１８, ISBN－１０: ９７８１６２１５７５７６４及びISBN－１３:９７８－１６２１５７５７６４。

従って、ブロックチェーンの分散型、不変性、且つ永久的特性を有利に利用して、このようなデータがブロックチェーン上で格納され、処理され、読み出され、検索され、及び／又は共有されることを可能にする構成を提供することが望ましい。このような改良されたソリューションがここで考案される。

本開示の実施形態は、少なくとも、ブロックチェーンソリューションを実装し、及びブロックチェーンに又はブロックチェーンからデータを格納し、処理し、検索し、及び／又は読み出す、代替的な効率的且つセキュアな技術を提供する。実施形態は、更に、少なくとも、コンピューティングノード間でデータを格納し、処理し、読み出し、転送し、検索し、及び／又は共有するための、代替的なブロックチェーンにより実装される技術的インフラストラクチャを提供する。本発明は、ブロックチェーンネットワークを新しい方法で使用することを可能にし、並びに、改良された技術的結果を提供するために、本発明は、改良されたブロックチェーンにより実装されるネットワークを提供する。

実施形態は、更に、ブロックチェーン及びブロックチェーンプロトコルを含む技術的に異なる改良されたコンピューティングプラットフォームを介してデジタルリソースへのアクセスのセキュアな制御のためのソリューションを提供する。

本発明は、添付の請求の範囲に定められる。

本発明に従い、コンピュータにより実施される方法及び対応するシステムが提供され得る。当該方法は、ブロックチェーンを介してデータの処理、格納、読み出し、識別、及び／又は共有を可能にする又は制御する方法として記載され得る。追加又は代替として、当該方法は、該データの識別、読み出し及び／又は共有を可能にするために、（別個の／異なる）ブロックチェーントランザクション内に格納されたデータを関連付ける又はリンクする方法として記載され得る。

当該方法は、プロトコルフラグと任意公開鍵（discretionary public key (DPK)）と任意トランザクションID（discretionary transaction ID (DTxID）とを含む少なくとも１つのブロックチェーントランザクション（Tx）を処理するステップを含んでよい。

特徴のこの組合せは、データ部分をブロックチェーン上で識別できるようにし、更に、複数のトランザクションの中で提供されるとき、互いにリンクされ／関連付けられることを可能にする。それは、データ部分の間の階層的関係を反映し、それらの処理、検索、アクセス、生成、及び共有を実現する、グラフ又はツリーのような構造を構成することを可能にする。ここで、「共有」は、ノード又はユーザに、データ部分へのアクセスを送信し、通信し、伝送し、又は提供することを提供することを含んでよい。

前記トランザクションID（TxID）は、ブロックチェーンプロトコルの分野で知られているようなトランザクションの識別子である。各ブロックチェーントランザクションは、基礎にあるブロックチェーンプロトコルの部分としてユニークなIDを有する。これと対照的に、任意公開鍵（DPK）及び／又は任意トランザクションID（DTxID）は、基礎にあるブロックチェーンのプロトコルにより記述されるようにトランザクションの必須成分ではなく、それらが本発明の部分として提供される点で、「任意（discretionary）」であってよい。別の方法では、それらは、基礎にあるブロックチェーンのプロトコル、例えばBitcoinに従いトランザクションを検証するために必要とされない。追加又は代替として、それらは、ブロックチェーンがそれらを必要とするからではなく、本発明の部分として提供される追加の必須ではないアイテムとして記載され得る。

望ましくは、プロトコルフラグは、１つ以上のブロックチェーントランザクションの中のデータを検索し、格納し、及び／又は読み出す、ブロックチェーンに基づくプロトコルに関連付けられ及び／又はそれを示す。プロトコルフラグは、指示子又はマーカであってよい。プロトコルフラグは、トランザクションが所定のプロトコルに従い形成されていることを示してよい。これは、基礎にあるブロックチェーンのプロトコル以外のプロトコルであってよい。それは、ここに記載される任意の実施形態による検索プロトコルであってよい（つまり、ここに記載される「メタネット（metanet）」プロトコルと呼ばれるものであってよい）。

用語「処理（processing）」は、トランザクション又はその関連データに関する、生成、送信、検証、アクセス、検索、共有、ブロックチェーンネットワークへの提出、及び／又は識別を含む、任意の活動を意味するとして解釈されてよい。

任意トランザクションIDは、本発明の実施形態に従いトランザクション（Tx）に関連付けられた識別子、ラベル、指示子、又はタグであってよい。私たちは、これらの用語の全部を含む用語「指示子」を使用する。留意すべきことに、従来知られているように、及び当業者により直ちに理解されるように、ブロックチェーン上の各トランザクションは、従来では標準的にTxIDと呼ばれる識別子によりユニークに識別される。TxIDは、基礎にあるブロックチェーンプロトコルの基本的な、必要な、且つ任意的ではない部分である。この任意的ではないTxIDは、ここで参照される任意トランザクションID(DTxID)と混同してはならない。

望ましくは、ブロックチェーントランザクション（Tx）は、データ部分、又はデータ部分への参照を更に含む。データ部分への参照は、該データが格納された場所のポインタ、アドレス、又は他の指示子であってよい。データ部分は、任意の種類のデータ又はデジタルコンテンツ、例えばコンピュータ実行可能アイテム、テキスト、ビデオ、画像、音声ファイル、等であってよい。前記データ部分は「コンテンツ」と呼ばれてよい。前記データ部分又はそれへの参照は、処理済み形式であってよい。例えば、それは、前記データ部分のハッシュダイジェストであってよい。データは、ブロックチェーン上又はブロックチェーン外（つまり、「オフチェーン」）に格納されてよい。

望ましくは、データ部分又はデータ部分への参照、プロトコルフラグ、任意公開鍵（discretionary public key (DPK)）、及び／又は任意トランザクションID（discretionary transaction ID (DTxID)）は、ブロックチェーントランザクションのアウトプット（UTXO）の中で提供されてよい。

望ましくは、データ部分、データ部分への参照、プロトコルフラグ、任意公開鍵（DPK）及び／又は任意トランザクションID（DTxID）は、後のトランザクションへのインプットとしての後に使用に対してアウトプットを無効であるとマークするスクリプトオペコードに続く位置において、トランザクション（Tx）内で提供される。

このスクリプトオペコードは、Bitcoinプロトコルの１つ以上の変形ではOP_RETURNオペコードであってよく、又は別のブロックチェーンプロトコルからの機能的に類似した／等価なオペコードであってよい。

望ましくは、トランザクション（Tx）は、１つ以上の属性を更に含む。これは、データ／コンテンツを検索するための更に詳細なアプローチを可能にする。属性は、「値」、「ラベル」、又は「タグ」若しくは「識別子」とも呼ばれてよい。

それらは、データ部分を記述し又は注釈を付け、又はデータ部分に関連する追加情報を提供するために使用されてよい。

望ましくは、１つ以上の属性は、以下：
ｉ）トランザクション（Tx）の中で提供される又は参照されるデータ部分、 及び／又は、
ｉｉ）トランザクション（Tx）、
に関連付けられたキーワード、タグ、又は識別子を含む。

望ましくは、トランザクション（Tx）は、以下：
任意トランザクションID（discretionary transaction ID (DTxID)）により識別される論理的親トランザクション（logical parent transaction (LPTx)）に関連付けられた親公開鍵（parent public key (PPK)）；及び親公開鍵（PPK）を用いて生成された署名；を含むインプットを更に含む。

これは、論理的階層構造が、トランザクションとそれらの埋め込まれたデータとの間で構成されることを可能にする。従って、ブロックチェーン上の複数の関連付けられた又は論理的にリンクされたトランザクションが効率的に、セキュアに、及び迅速に処理できる。論理的に関連付けられたトランザクションは、連続したブロック高でブロックチェーンに格納されなくてよいが、それらは、容易に且つセキュアに識別され及び／又はアクセスできる。

望ましくは、当該方法は、前記任意公開鍵（DPK）及び前記トランザクションID（TxID）を使用して、ブロックチェーンの中の前記トランザクション（Tx）又は前記論理的親トランザクションを識別するステップ、を更に含む。

追加又は代替として、本発明は、コンピュータにより実施される方法であって、
トランザクションIDを含むブロックチェーントランザクション（Tx）に公開鍵を関連付けられるステップと、
前記トランザクションID及び前記トランザクション公開鍵に基づき、前記ブロックチェーントランザクション（Tx）を検索するステップと、
を含む方法を提供する。

従って、当該方法は、ブロックチェーンによりデータを格納し、検索し、識別し、通信し、及び／又はアクセスするための改良されたソリューションを提供し得る。当該方法は、電子ネットワーク、特にピアツーピアブロックチェーンネットワークに渡るデータ通信及び交換のための改良を提供し得る。

公開鍵及び／又はトランザクションIDは、上述のように任意であってよい。上述の又はここに記載される任意の特徴は、本発明の本実施形態に従い利用されてもよいが、簡単及び明確さのために引用されない又は再び記載されない。

当該方法は、前記トランザクション（Tx）の中で提供された又はそれから参照されるデータ部分にアクセスし又は処理するステップ、を更に含んでよい。

前記トランザクションは、
トランザクションID（TxID）、プロトコルフラグ、任意公開鍵（DPK）、及び任意トランザクションID(DTxID）を含んでよい。前記トランザクション（Tx）は、データ部分、又はデータ部分への参照を更に含んでよい。データ部分又はデータ部分への参照、プロトコルフラグ、任意公開鍵（DPK）、及び／又は任意トランザクションID（DTxID）は、アウトプット（UTXO）の中で、望ましくはアウトプット（UTXO）に関連付けられたロックスクリプトの中で提供されてよい。

データ部分、データ部分への参照、プロトコルフラグ、任意公開鍵（DPK）及び／又は任意トランザクションID（DTxID）は、後のトランザクションへのインプットとしての後に使用に対してアウトプットを無効にするスクリプトオペコードに続く位置において、トランザクション（Tx）内で提供される。

トランザクション（Tx）は、１つ以上の属性を含んでよい。１つ以上の属性は、以下：
ｉ）トランザクション（Tx）の中で提供される又は参照されるデータ部分、及び／又は、
ｉｉ）トランザクション（Tx）、
に関連付けられたキーワード、タグ、又は識別子を含んでよい。

トランザクション（Tx）は、以下：
論理的親トランザクション（logical parent transaction (LPTx)）に関連付けられた親公開鍵（parent public key (PPK)）であって、前記論理的親トランザクション(LPTx)は任意トランザクションID（DTxID）により識別される、親公開鍵（PPK）；及び親公開鍵（PPK）を用いて生成された署名；を含むインプットを更に含んでよい。

当該方法は、前記任意公開鍵（DPK）及び前記トランザクションID（TxID）を使用して、ブロックチェーンの中の前記トランザクション（Tx）又は前記論理的親トランザクションを識別するステップ、を含んでよい。これは、検索ステップの間に実行されてよい。

プロトコルフラグは、１つ以上のブロックチェーントランザクションの中のデータを検索し、格納し、及び／又は読み出す、ブロックチェーンに基づくプロトコルに関連付けられ及び／又はそれを示してよい。

本発明は、ここの記載する方法の任意の実施形態のステップを実行するよう配置され及び構成される対応するシステムも提供する。当該システムは、プロセッサと、プロセッサによる実行の結果として、システムに本願明細書に記載のコンピュータにより実施される方法のいずれかの実施形態を実行させる実行可能命令を含むメモリと、を含むコンピュータにより実装されるシステムであってよい。

本発明は、実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、本願明細書に記載の方法の実施形態を実行させる、非一時的コンピュータ可読記憶媒体も提供する。

本発明の方法／システムの幾つかの実施形態は、特に「命名及びアドレス指定」と題された章で後述する１つ以上の特徴を含んでよい。

本発明の上述の及び他の態様は、本願明細書に記載の実施形態から明らかであり、及びそれを参照して教示される。本発明の実施形態は、単なる例を用いて及び添付の図面を参照して以下に説明される。

データが複数のアウトプットに格納される、本発明を具現化するブロックチェーントランザクションを示す。 データがインプットに格納される、本発明を具現化するブロックチェーントランザクションを示す。 データが複数のブロックチェーントランザクションのアウトプットに渡り格納される、本発明を具現化するブロックチェーントランザクションのシリーズを示す。 アトミックスワップを用いてデータへのアクセスを許可するために、暗号通貨支払いを送金する、本発明を具現化するブロックチェーントランザクションを示す。 図４のトランザクションの支払いを償還する、本発明を具現化するブロックチェーントランザクションを示す。 アトミックスワップを用いてデータへのアクセスを許可するために、トークンを発行する、本発明を具現化するブロックチェーントランザクションの中で参加者により保持されるシークレット値を示す。 アトミックスワップを用いてデータへのアクセスを許可するために、トークンを発行する、本発明を具現化するブロックチェーントランザクションを示す。 アトミックスワップを用いてデータへのアクセスを許可するために、トークンを発行する、本発明を具現化するブロックチェーントランザクションを示す。 図７及び８のトランザクションを用いて発行されたトークンを償還する、本発明を具現化するブロックチェーントランザクションを示す。 図７及び８のトランザクションを用いて発行されたトークンを償還する、本発明を具現化するブロックチェーントランザクションを示す。 図９及び１０のトランザクションにより交換されるシークレットにアクセスするためのブロックチェーントランザクションを示す。 図９及び１０のトランザクションにより交換されるシークレットにアクセスするためのブロックチェーントランザクションを示す。 本発明の実施形態によるメタネットグラフ構造の説明を提供する。 本発明の実施形態による、MURL検索パスを含むドメイン「bobslog」のためのメタネットグラフツリーの説明を示す。 本発明の一例によるブラウザ－ウォレットの説明のための実施形態の概略、及びそのコア機能が本願の異なるコンポーネントに渡りどのように分割できるかを示す。 コンテンツの検索が、本発明の実施形態のインフラストラクチャ内でどのように実行できるかを示す図を提供する。 本発明の実施形態による、ローカルフルコピーピアとグローバルフルコピーピアとの間の説明のための相互作用を示す。 後述する説明のための使用例を参照する際に使用するためのメタネットツリー（又はグラフ）を示す。 後述する説明のための使用例により具現化される処理を示すフローチャートを示す。 種々の実施形態が実装できるコンピューティング環境を示す概略図である。

用語「Bitcoin」は、ここでは単に便宜上使用され、限定ではないが、Bitcoinプロトコルから導出される全ての変形、及び他のブロックチェーンのための任意の代替プロトコルを含むあらゆる暗号通貨／ブロックチェーンプロトコルを含むことを意図する。本願明細書の残りの部分では、本発明の実施形態の動作を決定するプロトコルは「メタネット（Metanet）プロトコル」と呼ばれる。

用語「コンテンツ」、「デジタルコンテンツ」及び「データ」は、本発明の実施形態によりブロックチェーントランザクションに格納される、それにより参照される、又はそれを介してアクセスされるデータを表すために、ここでは同義的に使用されてよい。データは、トランザクションコード自体の部分として基礎にあるブロックチェーンプロトコルにより要求されるデータとは異なり、ブロックチェーンにより伝達され、通信され、又は格納される追加の／任意のデータである。

＜概要＞
上述のように、コンピューティングノードの間で及びそれらにより、データを格納し、書き込み、アクセスし、及び閲覧するための改良された及び／又は代替的なインフラストラクチャの必要性が認識されている。ブロックチェーン技術に固有の利点（例えば、変更不可能な記録、暗号法の実施された制御及びアクセス、埋め込み型支払いメカニズム、台帳を公に検査する能力、分散型アーキテクチャ、等）を使用することは有利である。しかしながら、「ブロックチェーンにより実装されるインターネット」の構成は、多くの技術的観点から困難である。

これらの困難は、限定ではないが、ネットワーク内のデータの特定の部分、認可されたパーティのみがアクセスを得ることができるように、該データへのアクセスをどのように保護及び制御するか、ピアツーピア方式でパーティからパーティへとデータをどのように転送するか、ネットワーク内の異なる位置に格納されたまま論理的に関連付けることができるように、どのようにデータを構成し、集合的及び増強された結果を提供するために異なる位置からのデータをどのように後に結合するか、階層的方式でデータをどのように提供し及び／又は格納するか、異なるコンピューティングプラットフォームを有するユーザ及びパーティに所望のデータへのアクセスをどのように許可するか、大規模ストレージサーバ及び集中型データ制御部に頼らず又はそれらを必要としないで、（グローバルである可能性のある）コンピューティングネットワークに渡りどのようにデータを格納し、提供し、及び共有するか、並びに、ネットワーク上のこのようなデータ関連活動の効率をどのように向上するか、を含んでよい。

本発明は、幾つかの点でインターネットと類似する方法で、しかし、従来知られているものと完全に異なるハードウェア及びソフトウェアコンポーネントのプラットフォームを用いて、その結果を完全に異なる方法で達成する、このような改良されたソリューションを提供する。本発明の実施形態によると、インターネット／ウェブデータを格納し、それをエンドユーザに提供するサーバは、ブロックチェーンネットワークに存在するブロックチェーントランザクションにより置き換えられる。これを達成するために、幾つかの革新が考案されなければならなかった。これらは、以下の章で説明される。

＜ブロックチェーン「Metanet」にデータを挿入する＞
図１を参照すると、本発明を具現化するブロックチェーントランザクションが示される。ここで、ブロックチェーン上に格納されるべき第１データは、トランザクションの１つ以上の第１アウトプットに格納され、第１データの属性を表す第２データは、トランザクションの１つ以上の第２アウトプットに格納される。第１データの１つ以上の第１部分<Content １>は、トランザクションの使用可能（spendable）アウトプットに格納される。データ<Attribute １>及び<Attribute ２>は、データがMetanetプロトコルに従い格納されていることを示すフラグと一緒にそれぞれ第１データの属性を表し、トランザクションの第２の使用不可能（unspendable）アウトプットに格納される。用語「使用不可能（unspendable）」は、トランザクションの少なくとも１つの第１及び／又は第２アウトプットが、後のトランザクションへのインプットとしての後の使用のためにアウトプットを無効であるとマークするスクリプトオペコード（OP RETURN）を含み得ることを示すために使用される。

コンテンツ及びデータの属性を、トランザクションの別個のアウトプット（UTXO）に格納することは有利である。

図２は、ブロックチェーン上に格納されるべき第１データ<Content １>がトランザクションのインプットに格納される、本発明を具現化するブロックチェーントランザクションを示す。Metanetフラグ、及び属性データ<Attribute １>及び<Attribute ２>は、図１に示した構成と同様の方法で、トランザクションの使用不可能アウトプットに格納される。

＜データ挿入＞
＜データ挿入方法＞
以下のデータをブロックチェーンに挿入できることが望ましい。
ａ）Metanetフラグ
ｂ）属性
ｃ）コンテンツ

コンテンツは、ブロックチェーン上に格納されるべきデータであり、Metanetフラグは、Metanetプロトコルに関連する任意のデータのための識別子として機能する４バイトのプレフィックスであり、一方で、属性は、コンテンツに関するインデックス、許可、及び符号化情報を含む。これは、限定ではないが、データタイプ、暗号化及び／又は圧縮方式を含み得る。このような属性は、メタデータと呼ばれることがある。本願明細書において、この用語は、トランザクションメタデータとの混同を避けるために、使用を避ける。

これは、限定ではないが、データタイプ、暗号化及び／又は圧縮方式を含み得る。このような属性は、メタデータと呼ばれることがある。本願明細書において、この用語は、トランザクションメタデータとの混同を避けるために、使用を避ける。

以下の技術が、このデータをBitcoinスクリプト内に埋め込むために使用できる。

１．OP_RETURN：この方法では、全部のデータ（属性及びコンテンツ）は、明らかな使用不可能トランザクションアウトプットのロックスクリプト内のOP_RETURNの後に置かれる。
この演算子を用いたアウトプットスクリプトの例は以下の通りである。
UTXO０：OP_RETURN <Metanet Flag> <attributes> <content>

２．OP_DROPを伴うOP_RETURN：この場合、OP_RETURNは属性を含み、一方、コンテンツは、使用可能トランザクションスクリプト（ロック又はアンロックのいずれか）内のOP_DROPの前に格納される。
コンテンツは、トランザクションインプット及びアウトプットの中の複数のデータパケットに分割できる。しかしながら、Bitcoinプロトコルにおいて署名され得るのはアウトプットスクリプトだけなので、トランザクションアウトプットにデータを挿入することが有利である。データがトランザクションインプットに挿入された場合、マイナー検証の代わりに、データの有効性を保証するためにデータに対するチェックサムとして、OP_MODが使用できる。例えば、３２ビットOP_MOD演算を実行し、それが予め計算された値に等しいことをチェックし得る。

この場合、属性は、コンテンツデータパケットがどのように再結合されるかに関する情報を含んでよい。更に、再結合されたデータパケットのハッシュH(content１ +content２)を属性として提供することは、推奨される再結合方式が使用されていることを検証することを可能にする。

第２データ挿入方法を実施するトランザクションが、図１に示される。簡単のため、このトランザクションは、その単一のインプットにより署名された、そのアウトプットに挿入されたコンテンツのみを含む。追加インプットに挿入されたコンテンツも、図２に示す本方法を用いて、OP_DROP文を用いて可能であり得る。

コンテンツが非常に大きい場合、該コンテンツを複数のトランザクションに分割することが有利であり得る。このような構成は、図３に示される。図３は、本発明を具現化するブロックチェーントランザクションのペアを示す。ここで、ブロックチェーンに格納されるべき第１データ<Content>は、２つのチャンク<Content chunk １>及び<Content chunk ２>に分割され、これらは、<Content>=<Content chunk １>||<Content chunk ２>のように後に再結合できる。ここで、演算子「||」は、コンテンツデータの２個のチャンクを連結する。この連結演算子は、任意の所望のビット毎、又は同様のピース毎のバイナリ演算により置き換えられてよい。２つのチャンク<Content chunk １>及び<Content chunk ２>は、次に、別個のブロックチェーントランザクションのそれぞれ適切なアウトプットに格納される。一方で、コンテンツデータの属性に関連するデータは、それぞれブロックチェーントランザクションの使用不可能アウトプットに格納される。ここでも、属性は、再結合方式に関する情報を含み得る。例えば、コンテンツは、未処理データ、実行可能プログラム、又はHTMLウェブページであってよい。更に、content１は、content２のブロックチェーン上の位置へのポインタを含んでよい。該ポインタは、ウェブページ内の埋め込まれたHTMLリンクと同じ方法で機能する。

留意すべきことに、両方のトランザクションは同じ公開鍵P（及びECDSA署名）をインプットとして取り入れる。その結果、<Content chunk １>及び<Content chunk ２>は、それぞれTxID１及びTxID２を有する異なるトランザクションに格納されるにも拘わらず、同じ公開鍵Pにより関連付けられ得る。

＜マイナー検証の役割を開発する＞
ここで、マイナーにより実行されるトランザクション検証処理は、このデータを格納するときに利益を得るために使用される。これは、トランザクションアウトプットの中の全部のデータが、少なくとも１つのトランザクションインプットの中の公開鍵Pの所有者により署名されるからであり（SIGHASH|ALLフラグが存在する場合）、この署名は、全部のマイナーが実行するトランザクション検証処理の中でチェックされる。

これは以下を保証する：
・データ完全性：データが壊れている場合、CHECKSIG演算は失敗する。
・データ信頼性：Pの所有者は、データを証明しそれに署名していることが証明される。

これは、特に、図３に示した構成を参照して上述したように、Pのインプット署名がデータの分割されたコンポーネントの間の証明可能なリンクを提供するとき、複数のトランザクションに分割されたコンテンツについて有利である。

＜Rabin署名＞
データ信頼性を証明するための別の方法は、Rabin署名を使用することである。これは、メッセージ全体ではなく、データ自体に署名するために使用できる。これは、署名者がデータの現れる個々の全てのトランザクションに署名する必要がなく、署名が複数のトランザクションで再利用できるので、有利であり得る。

Rabin署名は、スクリプト内で容易に検証できる。これらは、OP_DROPコマンドの前にRabin署名検証を挿入することにより、上述のケース（２）に組み込むことができる。つまり、
<content１> <Rabin Sig (content１)> FUNC_CHECKRABSIGOP_DROP <H(P_１)>[CheckSig P_１]
留意すべきことに、これは、OP_RETURNを含むスクリプトがいずれにしても失敗し、従って検証に達することができないので、上述のケース（１）では行うことができない。

＜Rabin署名の使用の特定の例＞
＜序論＞
デジタル署名は、Bitcoinプロトコルの基本的部分である。それらは、ブロックチェーン上に記録された任意のBitcoinトランザクションが、送信されているBitcoinの正当な保持者により認証されていることを保証する。標準的なBitcoin P２PKHトランザクションでは、トランザクションメッセージは、楕円曲線デジタル署名アルゴリズム（elliptic curve digital signature algorithm (ECDSA)）を用いて署名される。しかしながら、ECDSA署名は、通常、トランザクション全体に対して適用される。

ネットワークの外部からの参加者が、ネットワーク参加者により使用可能になる任意のデータタイプに対する署名を提供することを望得る、Bitcoinブロックチェーンの幾つかの使用例がある。Rabinデジタル署名を使用することにより、データの任意のピースが、それがBitcoinブロックチェーンの外部から生じて１又は複数のトランザクション内に配置されたものである場合でも、署名され得る。

以下に、Rabin暗号システムの代数構造を利用することにより、どのようにBitcoinスクリプト内でデータが直接署名され検証できるかを示す。

＜Rabinデジタル署名＞
＜Rabinデジタル署名アルゴリズム＞
＜背景にある数学的処理＞
定義：Integers mod ｐ
pを法とする整数（integers）は、以下の集合として定義される。

フェルマーの小定理
pを素数とする。次に、任意の整数aに以下を適用する。

オイラーの基準
pを素数とする。rは、以下の場合及び以下の場合にのみ、pを法とする平方余剰である。

モジュラ平方根（p=３ mod ４）
pを素数とし、次式のようにする。

次に、オイラーの基準を満たす任意の整数rについて、aが整数ならば、次式の通りである。

次に、次式の形式のaの解が存在する。

中国の余剰定理
互いに素な正整数n_１,n_２,...,n_kと任意の整数a_１,a_２,...,a_kがペアで与えられると、以下の連立合同式システムは、N=n_１n_２...n_kを法とするユニークな解を有する。

中国の余剰定理の特別な場合として、

の場合に且つその場合にのみ、次式の通りであることが示される：

＜Rabinデジタル署名アルゴリズム＞
Rabinデジタル署名アルゴリズムは、以下の通り説明できる。

任意のメッセージmについて、Hを、k個のアウトプットビットを有する衝突耐性のあるハッシュアルゴリズムであるとする。

鍵を生成するために、次式

になるように、それぞれ長さが約k/２である素数p及びqを選択し、積n=p・qを計算する。秘密鍵は（p,q）であり、公開鍵はn=p・qである。

メッセージmに署名するために、署名者は、次式を満たすように、パディングUを選択する。

署名Sは、次式を用いて計算される。

メッセージmの署名は、ペア（S,U）である。検証は、所与のm、U、及びSについて、次式をチェックすることにより簡単に行うことができる。

これは、範囲０,...,n－１の中に次式のような整数が存在する場合且つその場合にのみ、真である。

因子λは、組合せ（S,λ,U）を提供するために署名の中に安全に含まれてよい。

Rabin署名方式の有利な特徴は以下の通りである。
ａ）署名生成は計算的に高価であるが、署名の検証が計算的に容易である。
ｂ）署名のセキュリティが、素因数分解の困難さにのみ依存する。その結果、Rabin署名は、（RSAと異なり）本質的に偽造不可能である。
ｃ）以下のハッシュ関数値が、公開鍵nと同様の大きさでなければならない。

スクリプト内の検証は、所与の署名を二乗し、モジュラ簡約（modular reduction）を実行し、次に結果が次式に等しいことを確認するだけでよいので、簡単である。

＜Rabin署名証明＞
p、１を素数とし、n=p・qである。中国の余剰定理により、次式：

が示される。

の場合且つその場合にのみ、
次式が示される。

次式を用い

従って

ここで、次式がオイラーの基準を満たすと仮定された。

同様の計算により、次式が示される。

＜BitcoinにおけるRabin署名＞
＜スクリプト内の署名検証＞
Rabin署名を検証するために、少数の算術的及びスタック操作オペコードしか必要ない。以下の形式のRedeemスクリプトを考える。
OP_DUP OP_HASH１６０ <H_１６０> OP_EQUALVERIFY OP_MUL OP_SWAP OP_２ OP_ROLL OP_CAT FUNC_HASH３０７２ OP_ADD OP_SWAP OP_DUP OP_MUL OP_EQUAL

ここで、nは署名者の公開鍵である。これは、以下のインプットが提供された場合且つその場合にのみ、真（TRUE）と評価される。
<S><U><m><λ><n>

ここで、mは任意のメッセージであり、（S,λ,U）は有効なRabin署名である。代替として、Rabin署名が上述の式１を用いて確認された場合、Redeemスクリプトは以下のように与えられる。
OP_DUP OP_HASH１６０ <H_１６０> OP_DUP OP_TOALTSTACK OP_SWAP <roll index> OP_ROLL OP_CAT FUNC_HASH３０７２ OP_SWAP OP_MOD OP_SWAP OP_DUP OP_MUL OP_FROMALTSTACK OP_MOD OP_EQUAL

この場合、スクリプトは、以下のインプットが提供された場合且つその場合にのみ、真（TRUE）と評価される。
<S><U><m><n>

両方のRedeemスクリプトで、３０７２ビットのハッシュ射影関数「FUNC_HASH３０７２」が使用されている。所与のメッセージ／パディング連結では、FUNC_HASH３０７２ハッシュ射影は、以下のスクリプトを用いて生成される。
OP_SHA２５６ {OP_２ OP_SPLIT OP_SWAP OP_SHA２５６ OP_SWAP} (x１１)
OP_SHA２５６ OP_SWAP OP_SHA２５６ {OP_CAT}(x１１)

＜データの圧縮＞
インターネットのデータは、JavaScript及び共通のファイルタイプ、例えばテキストファイル（SML、HTML、等）、ビデオファイル（MPEG、M－JPEG、等）、画像ファイル（GIF、JPEG、等）、及びオーディオファイル（AU、WAV、等）で、例えばhttps://www.doc.ic.ac.uk/~nd/surprise_９７/journal/vol１/mmp/#text詳細に記載されるように、構成される。上述のデータ挿入技術を用いて、これらの異なるデータタイプも、ブロックチェーンに埋め込むことができる。

大きなファイルサイズは、ブロックチェーンに埋め込む前に、幾つかの既存の符号化方式のうちの１つを用いて圧縮できる。ランレングスハフマン符号化のような無損失データ圧縮アルゴリズムは、ZIPファイル、実行可能プログラム、テキスト文書、及びソースコードを含む幾つかのアプリケーションで使用できる。

特定の入力データに依存して、多くの異なるアルゴリズムが存在する。Apple無損失及び適応型変換音響符号化（Apple Lossless and Adaptive Transform Acoustic Coding）は、オーディオファイル、グラフィックファイルの圧縮のためのPNG及びTIFF、を圧縮するために使用できる。一方で、動画ファイルは、多くの無損失ビデオコーデックのうちの１つを用いて圧縮できる。データコンテンツの任意の圧縮は、属性の中のフラグを用いて示すことができる。例えば、属性の中のLZW無損失符号化方式のためのフラグは、<LZW>であり得る。

＜暗号化及び有料復号（paid decryption）＞
＜データの暗号化＞
コンテンツの所有者は、コンテンツをブロックチェーンに埋め込む前に、コンテンツを保護することを選択してよい。これは、コンテンツが、必要な許可を取得しなくては閲覧できないことを保証する。

データ（平文又は他のデータタイプ）の暗号化のために多くの確立された技術が存在する。これらは、非対称暗号化、又は対称暗号化として分類できる。

楕円曲線暗号法（Elliptic Curve Cryptography (ECC)）は、公開－秘密鍵ペアに依存するので、非対称である。それは、最も安全な暗号システムのうちの１つであり、標準的にBitcoinのような暗号通貨において使用される。ECC暗号法では、データを暗号化するために、Koblitzアルゴリズムが使用できる。

対称方式では、データの暗号化及び解読の両方のために、単一の鍵が使用される。高度暗号化標準（Advanced Encryption Standard (AES)）アルゴリズムは、シークレットのようなものをシードとする最も安全な対称アルゴリズムのうちの１つであると考えられ、例えば以下に詳細に記載されている：C. Paar and J. Pelzl, Chapter ４ in “Understanding Cryptography,” Springer－Verlag Berlin Heidelberg ２^nd Ed., ２０１０, pp. ８７－１１８。

ブロックチェーンに格納されたデータを暗号化するとき、基礎にあるブロックチェーンと同じ暗号システムを使用することに利点がある。Bitcoinでは、これは、非対称暗号法ではECC鍵ペアのためのsecp２５６k１規則、及び対称暗号法ではSHA－２５６ハッシュ関数である。これらの利点は次の通りである。
・暗号化のセキュリティレベルが、データが格納される基礎にあるシステムと同じである。
・暗号化データを格納するために必要なソフトウェアアーキテクチャは、より小さなコードベースを有する。
・ウォレットの中の鍵の管理が、トランザクション及び暗号化／解読の両方のために使用できる。
・暗号化と暗号通貨における支払いとの両方に同じ鍵を使用できるので、より効率的であり、より少ない鍵しか必要ない。これは、記憶空間も削減する。
・データを解読する能力を交換／購入するために、より少ない通信チャネルしか必要ない。
・暗号化及びトランザクションのために使用される鍵が同じデータ構造であるので、セキュリティが向上し、特定タイプの鍵を狙った攻撃が軽減される。
・鍵は、基礎にある暗号通貨を用いて購入できる。

説明の目的で、ECCを用いてデータを暗号化するために、どのようにKoblitzアルゴリズムが使用できるかを説明する。

＜Koblitzアルゴリズム＞
ECC鍵ペアP_１=S_１・Gが与えられると、Koblitzアルゴリズムは、誰もが公開鍵P_１を用いてメッセージを暗号化できるようにする。従って、対応する秘密鍵S_１を知っている者だけがメッセージを解読できる。

Koblitz法を用いてメッセージ「hello world」を暗号化することが望ましいと仮定する。これは、文字毎に行われる。最初の文字「h」は、以下のように暗号化され解読される。

１．文字「h」は、secp２５６k１曲線上の点にマッピングされる。これは、平文文字を８ビット数値にマッピングするためにASCII規則を用いて達成される。
曲線上の点は、次に、基点（base point）Gをこの数値により乗算することにより計算される。本例では、「h」は、ASCIIの１０４にマッピングされ、楕円曲線点はP_m=１０４・Gにより与えられる。

２．点P_mは、次に公開鍵P_１を用いて暗号化される。これは、ランダムな一時鍵（ephemeral key）k_０を選択し、点のペアC_m={k_０・G,Q}を計算することにより達成される。ここで、Q:=P_m+k_０・P_１である。これは次にブロードキャストされてよい。

３．秘密鍵S_１の所有者は、P_m=Q－S_１・k_０・Gを計算することにより、元の点を解読できる。それらは、次に、試行錯誤により又はルックアップテーブルを用いて、元のASCII数値を復元し、どの数値xがP_m=x・Gに対応するかを確立してよい。

＜許可を購入するためのブロックチェーンの使用＞
ブロックチェーンにデータを格納することは、支払いメカニズムがシステムに組み込まれるという明らかな利点を有する。支払いは、以下を購入するために使用できる。
・閲覧／使用するための解読データ。
・特定のアドレスにデータを挿入するための許可。

両方の場合に、買い手は、彼らに何かを行う許可を与えるシークレットを購入するために、暗号通貨、例えばBitcoinを使用している。このシークレットは、ハッシュプレイメージ、又は秘密鍵であってよい。

このような購入を行うために効率的且つセキュアな方法は、アトミックスワップを使用することである。これは、セキュアな通信チャネルを最小限に抑え、売り手が支払われ、シークレットが買い手に開示され、又は何もイベントが生じないことを保証する。

暗号通貨での支払いに加えて、アクセストークンを用いて許可を購入することも便利であり得る。これは、買い手が購入を行うために使用できる、買い手の所有するシークレット値（標準的にハッシュプレイメージ）である。このようなトークンは、前もって、買い手によりバルクで購入され、彼らが実際に許可を使用したいときに活性化されてよい。

以下では、図４及び５を参照して、アトミックスワップがどのように実行されるかを説明する。

＜ハッシュパズル又は秘密鍵パズルを用いるアトミックスワップ＞
Aliceがシークレットの所有者であるとする。このシークレットは、知られているハッシュダイジェストのハッシュプレイメージ、又は知られている公開鍵の秘密鍵であってよい。BobがAliceからこのシークレットを購入するためにBitcoinを使用したいとする。アトミックスワップとして知られているメカニズムは、このトランザクションが生じることを可能にするものと説明される。それは、AliceがBitcoinを支払われ、シークレットがBobに開示される、又は何もイベントが生じない、という意味でアトミックである。

当該方法は、以下の通りである。
Aliceは、公開／秘密鍵ペアP_A=S_A・Gの秘密鍵S_Aを所有し、Bobは、公開／秘密鍵ペアP_B=S_B・Gの秘密鍵S_Bを所有する。
Aliceは、知られているハッシュダイジェストH(X)のプレイメージX、又は知られている公開鍵P_１=S_１・Gの秘密鍵S_１であるシークレットを所有する。
彼らは、AliceがBobにシークレットを売るBitcoinの価格に合意している。
これらに先立ち、Bobは、Aliceがデジタル署名のコンポーネントであるr_０を計算できるように、Aliceに一時鍵k_０を送信するためのトランザクションをオフブロックで設定しなければならない。

ここで、図４を参照する。
１．Ｂｏｂは、Ａｌｉｃｅに、ＲｅｄｅｅｍスクリプトR（概略的に記述される）によりロックされた資金を送金する。
ハッシュプレイメージについて、

これは、Redeemスクリプトのインプットの中でプレイメージXを公開させる。
秘密鍵について、

これは、Redeemスクリプトへのインプットから秘密鍵S_１を計算できるようにする。この場合、Bob及びAliceは、r_０を構成するために使用される一時鍵k_０について合意しなければならない。ここで、（r_０,R_y）=k_０・Gである。

２．Aliceは、彼女のシークレット（X又はS_１）を知っているので、彼女は、図５に示すトランザクションを用いて、Bitcoinブロックチェーン上で彼女の資金を使用できる。これは、Bobが彼女のシークレットを決定することを可能にする。

任意的なセキュリティの特徴として、Alice及びBobは、両方のパーティにのみ知られている共有シークレットSを確立するために、彼らの公開鍵P_A、P_Bを使用してよい。これは、国際特許公開番号WO２０１７/１４５０１６号に概説された方法で達成され得る。この場合、Xがブロックチェーン上で公衆に開示されないようにするために、Sがハッシュパズルの中のプレイメージXに加算されてよい。同様に、秘密鍵パズルでは、Alice又はBobのみが秘密鍵を計算できることを保証するために、Sが、一時鍵k_０として使用されてよい。

Aliceが彼女の資金を支払わない場合に、Bobの資金がAliceによりロックされるのを防ぐために、タイムロックされた資金が、手順（procedure）に導入され得る。

＜トークンを用いる購入＞
上述のものと同じ状況が存在するとする。しかし、Aliceのシークレットのために暗号通貨を支払う代わりに、その使用時点で、Bobは、シークレットと引き換えに、前もって購入しておいたアクセストークンを償還（redeem）することを望み得る。

Alice及びBobが従わなければならない手順は、前の章で説明した場合と同様であるが、代わりに同様のアトミックスワップのシーケンスを使用する。処理の２つのフェーズが存在する。つまり、トークン発行及びトークン償還である。

フェーズ１：トークン発行
トークン発行フェーズは、事実上、Bobによるトークンの１回限りの購入である。例えば、Aliceが１０個の異なるシークレットX_１,X_２,...,X_１０を有し、Bobが、それぞれ彼にそれぞれのシークレットへのアクセスを許可する１０個のトークンT_１,T_２,...,T_１０を１回購入することを望むシナリオを考える。

先ず、Bobは、彼にのみ知られているシークレットシード値Yから１０個のトークンのセットを生成する。これらのトークンは、シードの順次ハッシングにより生成され、ハッシュチェーンを形成する。ここで、各トークンは次式のように計算される。

Alice及びBobは、今や１０個のシークレット値を有する。これらは、例えばトークンの償還のために、ハッシュパズルの中で開示され得る。これらのトークンを発行するために、しかしながら、彼らは、それぞれシークレット初期化値I_Alice及びI_Bobも生成しなければならない。これらは次式のように与えられる。

留意すべきことに、Aliceのイニシャライザは単なるランダム整数であり、特別な意味を持たないが、Bobのイニシャライザは、彼の最初のトークンT_１=H^９(Y)のハッシュでなければならない。この方法でトークンのチェーンをイニシャライザに拡張することは、トークンの発行が、連続する償還のために後に使用されるべきトークンを定めることも可能にする。全体で、各参加者により保持されるシークレット値は図６に示される。

ここで、Alice及びBobは、１０個のトークンの購入のために１０個の暗号通貨単位の価格について合意できる。これらのトークンの購入は、多数の方法で生じることができ、これは、ここではアトミックスワップを用いて説明される。アトミックスワップは、それぞれ図７及び８に示されるトランザクションをブロードキャストするAlice及びBobにより開始される。両方のトランザクションの中で、アウトプットは、２つのハッシュパズルに対する解と、有効な署名と、を必要とする。

両方のトランザクションがブロックチェーンに現れると、Alice及びBobは、彼らのイニシャライザ値I_Alice及びI_Bobを共有し、トークン発行のためのアトミックスワップを完了できる。

このアトミックスワップの結果として、Aliceは、１０個のトークンの購入のための支払いを受け取り、両方のイニシャライザシークレットが開示される。留意すべきことに、ここでBobのシークレットI_Bob=H^１０(Y)のみが意味がある。なぜなら、それが解かれるべき最初のハッシュパズル[HashPuzzle (T_１)]を定義するからである。このパズルの解は、イニシャライザH^１０(Y)のプレイメージH^９(Y)である。

フェーズ２：トークン償還
将来のある時点で、Bobは彼の最初のトークンT_１=H^９(Y)を償還し、彼の最初のシークレットX_１を受け取りたいと望むが、彼は既に、有効なトークンを購入することにより、このシークレットに対して支払っている。トークンを償還する処理は、別のアトミックスワップの形式を取る。ここで、ロックハッシュパズルの解は、トークンT_i、及び対応するシークレットX_iである。

彼のトークンを償還するために、Bobは、図９に示す、アウトプットが２つのハッシュパズルによりロックされているトランザクションをブロードキャストしなければならない。Aliceは、このトランザクションを見ると、は、図１０に示す、アウトプットが同じ２つのハッシュパズルによりロックされている彼女自身の同様のトランザクションをブロードキャストする。２人の参加者は、今や、彼らのシークレットT_１及びX_１を交換し、これらのトランザクションのアウトプットをアンロックできる。両方のパーティは、今や、両方のシークレットも公開する正しいアンロックスクリプトを提供することにより、僅かな料金ｘを償還できる。これらのアンロックスクリプトを有するトランザクションは、図１１及び１２に示される。

トークンを償還するこのアトミックスワップの完了は、額ｘが両方のパーティにロックされたアウトプットを使用させるのを奨励するのに十分大きいならば、Aliceの最初のシークレットX_１をBobに開示し、Bobの最初のシークレットT_１をAliceに開示し、暗号通貨資金の総額ゼロの交換を有する。重大なことに、これは、Bobが使用できる次のトークンが、ハッシュパズル[Hash Puzzle H(T_２)]に対する解T_２でなければならないことも確立する。ここで、ターゲットハッシュH(T_２)=T_２はAliceに開示される。この処理は、Bobが彼の最後のトークンT_１０Yを使用するまで、再帰的に繰り返すことができる。

＜命名及びアドレス指定＞
＜ノード及びエッジ構造＞
トランザクション内でデータを提供することにより、ブロックチェーンにデータをどのように挿入できるかを以上に説明した。私たちは、以下に、ノードのアドレス指定、許可、及びコンテンツバージョン制御を可能にする論理的な方法で、これらのトランザクションを構造化するプロトコルを提示する。この分散型ピアMetanetの構造は、既存のインターネットと類似している。

留意すべきことに、これは、基礎にあるブロックチェーンのプロトコル又は総意のルールを変更しない「tier－２」プロトコルである。

ここで説明する構造の目的は以下のものである。
（ｉ）異なるトランザクション内の関連するコンテンツを関連付け、データの検索、識別、及びアクセスを可能にする。
（ｉｉ）人間の読めるキーワード検索を使用したコンテンツの識別を可能にして、検索の速度、精度及び効率を向上する。
（ｉｉｉ）ブロックチェーン内にサーバのような構造を構築しエミュレートする。

私たちのアプローチは、有向グラフとしてMetanetに関連付けられたデータを構造化することである。このグラフのノード及びエッジは、以下に対応する。

ノード（Node）：Metanetプロトコルに関連付けられたトランザクション。ノードはコンテンツを格納する。（用語「コンテンツ」及び「データ」は、本願明細書の中で同義的に使用されることがある）。

ノードは、直後に<Metanet Flag>のあるOP_RETURNを含むことにより、生成される。各ノードは、公開鍵P_nodeで署名される。公開鍵とトランザクションIDとの組合せは、以下のノードのインデックスをユニークに指定する。

使用されるハッシュ関数は、基礎にあるブロックチェーンプロトコルと一貫していなければならない。本発明は、Bitcoinの場合にはSHA－２５６又はRIPEMD－１６０と共に使用されるべきである。

エッジ（Edge）：子ノードの親ノードとの関連付け。
エッジは、署名Sig P_parentがMetanetトランザクションのインプットの中に現れるときに生成される。従って、親のみがエッジを生成することを許可され得る。全部のノードは、最大で１個の親を有してよく、親ノードは、任意の数の子を有してよい。グラフ理論の言葉で言うと、各ノードの入次数は最大で１であり、各ノードの出次数は任意である。

留意すべきことに、エッジは、Metanetプロトコルの一側面であり、それ自体が基礎にあるブロックチェーンに関連付けられたトランザクションではない。

（親を有する）有効なMetanetノードは、以下の形式のトランザクションにより与えられる。
［表１］

このトランザクションは、ノードのインデックス及びその親を指定するために必要な全部の情報を含む。

更に、親ノードの署名が要求されるので、親のみが子へのエッジを生成できる。<T_xID_parent>フィールドが存在しない、又はそれが有効なMetanetトランザクションを指さない場合、ノードは親のない子である。それは、それにより到達可能な、より上のレベルのノードを有しない。

追加属性が、各ノードに追加されてよい。これらは、フラグ、名称、及びキーワードを含んでよい。これらは、本願明細書の中で後述される。

図示のように、ノード（トランザクション）のインデックスは以下に分解できる。
ａ）公開鍵（P_node）：これは、ノードのアドレスとして解釈される。
ｂ）トランザクションＩＤ（TxID_node）：これは、ノードのバージョンとして解釈される。

この構造化から、２つの有利な特徴が生まれる。
１．バージョン制御：同じ公開鍵を有する２個のノードが存在する場合、最大のproof－of－workを有するトランザクションIDを有するノードを、該ノードの最新バージョンとして解釈する。ノードが異なるブロックに存在する場合、これは、ブロック高によりチェックできる。同じブロック内のトランザクションについては、これは、トポロジトランザクション順序付けルール（Topological Transaction Ordering Rule (TTOR)）により決定される。
２．許可：ノードの子は、公開鍵P_nodeの所有者が子ノードの生成においてトランザクションインプットに署名した場合にのみ、生成され得る。従って、P_nodeは、ノードのアドレスだけでなく、子ノードの生成の許可も表す。これは、標準的なBitcoinトランザクションと意図的に類似している。つまり、公開鍵は、アドレスだけでなく、該アドレスに関連付けられた許可でもある。

親ノードの署名がUXTOアンロックスクリプト内に現れるので、トランザクションがネットワークに受け入れられた時点で、標準的なマイナー検証処理を通じて検証されることに留意する。これは、子ノードを生成する許可が、Bitcoinネットワーク自体により検証されることを意味する。

標準的なインターネットプロトコル（IP）アドレスは、特定の時点でネットワーク内でのみユニークであることは留意する価値がある。他方で、Metanet内のノードのインデックスは、いつでもユニークであり、別個のネットワークという概念がない。これは、データが単一のオブジェクトID_nodeに永久にアンカーされることを可能にする。

ノード及びエッジ構造は、図１３に示すように、Metanetをグラフとして視覚化することを可能にする。

＜Metanet内のドメイン、命名、及びコンテンツの位置特定＞
Metanetグラフの階層構造は、豊富なドメインのような構造を出現させる。私たちは、親のないノードを最上位ドメイン（top－level domain (TLD)）として、親のないノードの子をサブドメインとして、孫をサブサブドメイン等として、子のないノードをエンドポイントとして解釈する。図１３を参照する。

ドメイン名は、ID_nodeとして解釈される。Metanet内の各最上位ドメインは、親のないノードであるルートと子のないノードであるリーフとを有する木として考えられてよい。Metanet自体は、グラフを形成する木のグローバルコレクションである。

Metanetプロトコルは、任意のノードがコンテンツデータを含むことを規定しないが、リーフ（子）ノードは、データ木における有向パスの端を表し、従って通常、コンテンツデータを格納するために使用される。しかしながら、コンテンツは、木の中の任意のノードに格納されてよい。ノードに属性として含まれるプロトコル固有のフラグは、データ木の中のノードの役割（ディスク空間、フォルダ、ファイル、又は許可の変更）を指定するために使用されてよい。

インターネットはドメインネームシステム（Domain Name System (DNS)）を使用して、インターネットプロトコル（IP）に人間の読める名称を関連付けることを思い出してほしい。DNSは、ある意味で非集中化されているが、実際には、政府や大企業のような少数の主要プレイヤにより制御される。DNSプロバイダによっては、同じ名称でも異なるアドレスに移動する場合がある。この問題は、短い人間の読める名称をコンピュータの生成した数値にマッピングするとき、発生する。

私たちは、人間の読める上位レベルのドメイン名をルートノードの非集中化インデックスID_rootにマッピングする、等価分散型システムが存在すると仮定する。言い換えると、人間の読める名称をMetanetルートノードインデックスにマッピングする、以下の１対１関数kが存在する。

左辺への入力は、人間の読める単語である。一方で、右辺の出力は、ハッシュダイジェストであり、標準的に２５６ビットのデータ構造である。P_bobsblog及びTxID_bobsblogも、通常、人間には読めないことに留意する。標準的なIPプロトコルでは、これは、www.bobsblog.comから、ネットワーク内の対応するドメインのIPアドレスにマッピングされる。

マップｋは、DNSの発行したドメイン名の人間による可読性を再現する際に、Metanetのインターネットとの後方互換性を保証するための手段として解釈されるべきであるが、Metanetの構造を提供する命名及びアドレス指定方式は、このマップに明示的に依存しない。

マッピング関数kの存在し得る形式は、IPFS（Interplanetary File System）より利用されるDNSLinkシステム、又はOpenNICサービス（https://www.openic.org）を含む。このマッピングは、既存のTXTレコードの中に、DNSの部分として格納できる。これは、IPFSにおけるDNSLinkと類似している。https://docs.ipfs.io/guides/concepts/dnslink/を参照のこと。しかしながら、通常、これらは１対１であるマップを提供するために、非集中化の何からの要素を犠牲にする。https://hackernoon.com/ten－terrible－attempts－to－make－the－inter－planetary－file－system－human－friendly－e４e９５df０c６faを参照のこと。

＜バニティアドレス＞
Metanetノードのアドレスとして使用される公開鍵は、人間の読めるオブジェクトではない。これは、活動の検索、参照、及び入力を、人間のユーザにとって間違えやすく遅いものにし得る。しかしながら、ユーザにより直接解釈可能な平文プレフィックスを含む、人間の認識できる公開鍵アドレス、つまりバニティアドレスP_vanityを生成することが可能である。バニティアドレスは、従来知られている。

このようなアドレスを生成する際の難しさは、所望のプレフィックスの文字長に依存する。これは、人間の認識可能なバニティアドレスが、中央による発行ではなく、生成するための所有者の努力にのみ依存するノードアドレスとして使用されてよいことを意味する。所与のプレフィックスに対して、サフィックスの中の残りの文字により、多数の異なるバニティアドレスが存在する。従って、ユニーク性を保持したまま、多くのノードアドレスが共通のプレフィックスを共有できる。

望ましいプレフィックスを有するバニティアドレスの例は、以下の通りである。
Pbobsblog：bobsblogHtKNngkdXEeobR７６b５３LETtpyT
Prefix：bobsblog
Suffix：HtKNngkdXEeobR７６b５３LETtpyT

上記のバニティアドレスは、名称「bobsblog」からノードインデックスID_bobsblogへのマップを確認（sense check）するため、及びアドレスによりMetanet内ノードの検索可能性を支援するために使用されてよい。プレフィックスはここではユニークではないが、全体のアドレス自体はユニークなエンティティであることに留意する。

選択されたアドレスP_vanityのTxIDとの組合せは、ID_nodeを形成し、それがドメイン名の中央ではない発行者が存在することを意味し（TxIDは非集中化されたproof－of－workにより生成される）、名称がブロックチェーン自体から復元可能なので、有利である。有利なことに、インターネットDNS内に存在する障害点はもはや存在しない。

Metanetドメインは既に許可システム（公開鍵）を提供しているので、所有権を証明するための証明書を発行する必要がない。この目的のためにブロックチェーンを使用することは、例えばnamecoin（https://namecoin.org/）において探求されている。本発明によれば、しかしながら、全てのことが１つのブロックチェーンの中で達成されるので、この機能のために別個のブロックチェーンを使用する必要がない。

これは、従来技術と比べて、本発明により必要とされるリソース（ハードウェア、処理リソース、及びエネルギ）の量を有意に低減する。本発明は、また、機器及びシステムコンポーネントの構成の観点で、完全に異なるアーキテクチャを提供する。

この命名システムの利点は、ユーザが、ハッシュダイジェストではなく記憶しやすい単語（例えば、会社名）によりMetanet内の最上位ドメインを識別できることである。これはまた、ハッシュダイジェストよりもキーワードに対して検索する方が速いので、ドメインに対する検索を速くする。それは、入力誤りを低減し、従って、ブロックチェーンに格納されたデータに対する改良された検索ツールを提供する。

私たちはドメイン名からノードインデックスへのマップを有するので、インターネットのURL（Uniform Resource Locator）のものと同様のリソースロケータを構築できる。私たちは、これをMetanet URL（MURL）と呼び、以下の形式である。

URLのコンポーネントの各々、つまり、プロトコル、ドメイン名、パス、及びファイルは、MURLの構造にマッピングされており、オブジェクトをユーザにとってより直感的にし、インターネットの既存の構造と統合できるようにする。

これは、各ノードが、ドメイン木の中のレベルにおいてユニークな、その公開鍵（アドレス）に関連付けられた名称を有することを前提としている。この名称は、常に、所与のノードについて、MURLの最も右のコンポーネントである。木の中の同じレベルにある２個のノードが同じ名称を有する場合、それらは、同じ公開鍵を有し、従って最新のバージョンが取り入れられる。

以下の表は、Metanetプロトコルとインターネットプロトコルとの間の類似性を与える。
［表：インターネットとMetanetプロトコルとの間の類似性のまとめ］

＜Metanetの検索＞
私たちは、各ノードがユニークなインデックスを有し、それに属する名称を有し得る、Metanetグラフ構造の説明のための実施形態を定めた。これは、MURLを使用してコンテンツの位置を特定することを可能にする。また、迅速な検索機能を可能にするために、私たちは、追加キーワードをノードに帰属させた。

ノードの固定属性は、インデックス及び親ノードのインデックスであり、任意属性は名称及びキーワードである。

一例では、Metanetを検索する実際の方法は、先ず、ブロックエクスプローラを使用して、ブロックチェーンを通じてトロール（trawl）してよく、Metanetフラグを有する全部のトランザクションを識別し、それらが有効なMetanetノードであることを調べ、有効である場合、それらのインデックス及びキーワードをデータベース又は他の記憶リソースに記録する。このデータベースは、次に、所望のキーワードを有するノードを効率的に検索するために使用できる。所望のキーワードを有するノードのインデックスが見付かると、そのコンテンツが、ブロックエクスプローラから読み出され、閲覧できる。

例として、図１４のブランチP_１を考えると、公開鍵P_０、P_１、P_１,１に対応するノードは、それぞれホームページ、トピックページ及びサブトピックページを表す。これらのノードは、名称「bobsblog」、「summer」、及び「caribbean」を与えられ、それらの属性は以下に示される。

この例では、リーフノードP_１,１,１、P_１,１,２、及びP_１,１,３は、それぞれ名称「beaches」、「nightlife」、及び「food」を与えられ、別個のブログ投稿を格納するために使用される。木の中の各ノードに関連するMURL検索パスを含む、完全なドメイン構造が、図のリーフの上に示される。

Metanetは、追加属性としてノードトランザクションにより格納されたコンテンツのハッシュを格納することにより、コンテンツアドレス可能なネットワーク（content addressable network (CAN)）も組み込むことができる。これは、Metanetノードが、インデックス付けされ、コンテンツハッシュにより検索できることも意味する。

上述の命名及びアドレス指定方法は、従来技術に対し、以下を含む多数の技術的利点を提供する。
１．公開鍵アドレス：システムは、ブロックチェーンのように、ノードアドレスを割り当てるために同じ公開－秘密鍵ペアを使用する。これは、同じ鍵セットが、暗号通貨資金の管理、及びコンテンツデータの許可の両方のために使用されることを意味する。これは、効率的且つセキュアなソリューションを提供する。
２．非集中化ドメイン：proof－of－workによってのみ生成できるTxID_nodeを含むことを通じて、ドメイン名の発行が、完全に非集中化される。ドメイン名は、所望のドメイン公開鍵の公平な分配を可能にする、人間の認識可能な公開鍵P_vanity（バニティアドレス）も組み込むことができる。ここでも、このソリューションは、向上した効率及びセキュリティを提供する。
３．グラフ構造：命名及びアドレス指定アーキテクチャは、Metanetノードを含むブロックチェーンデータのサブセットから構成できるグラフを指定する。この設計は、順序付けられた構造を用いて、インターネットの複雑性をブロックチェーンにマッピングする。その結果、それは、セキュアなままに、その機能及び拡張性を完全に再現する。

＜ブラウザ－ウォレットアプリケーション＞
Metanetプロトコルでは、全部のデータがブロックチェーン自体に直接存在することを思い出してほしい。この章で、私たちは、説明のためのコンピュータアプリケーションの実施形態を提示する。ここで、私たちは、便宜上、ブロックチェーンに格納されたMetanetデータに効率的にアクセスし、表示し、及び相互作用できる「ブラウザ－ウォレット」を参照する。

私たちは、この章の残りの部分で詳細な説明を提供する前に、ブラウザ－ウォレットが分散型ピアインターネットとどのようにインタフェースするかというコアコンポーネント及び機能の議論から始める。

＜概要＞
＜コンポーネント＞
ブラウザ－ウォレットは、エンドユーザがブロックチェーン上のMetanetインフラストラクチャと相互作用することを可能にするアプリケーションである。このアプリケーションは、木に埋め込まれた特定のコンテンツについて、Metanetグラフの探索的検索を可能にするべきである。更に、ブラウザ－ウォレットは、コンテンツの読み出し、解読、再結合及びキャッシュ（任意）を扱う。

ブラウザ－ウォレットアプリケーションは、ネイティブ（又は外部）ウォレットをサポートすることにより、これらの要素を暗号通貨支払いメカニズムと結合する。ブラウザ－ウォレットは、単一のコンピュータアプリケーションに結合される以下のコア要素を含む。

ブロックチェーン検索エンジン：ID_node、ノード名、キーワード、ブロック高、及びTxIDを含む種々のインデックスにより、Metanetノードをクエリするために第三者検索エンジンをサポートする。

ディスプレイウインドウ：フルコピーブロックチェーンピアによりブラウザに返されるコンテンツをパック解除（unpack）するソフトウェア。これは、アクセストークンの解読、再結合、キャッシング、及び償還をカバーする。

暗号通貨ウォレット：ブロックチェーンの通貨の専用鍵管理。アプリケーションに本来備わっているか（ネイティブ）、又は外部ウォレット（ソフトウェア又はハードウェア）との通信及び同期を許可できる。標準的なブロックチェーントランザクション、並びに新しいMetanetノードトランザクションを書き込むことができる。アクセス鍵及びアクセストークンのオンチェーンでの購入を調停できる。

暗号通貨公開鍵及びMetanetノードアドレスの両方のために、階層的な決定性鍵管理が利用される。

アクセス鍵／トークンウォレット：購入したアクセス鍵又はトークンのための専用鍵管理。暗号通貨ウォレットを用いて購入した鍵又はトークンを受信できるが、それらに対する許可を有しない。それらは、後に満期になるよう、ユーザから隠されてよい。これは、信頼できる実行環境の使用を通じて達成されてよい。ブロックチェーンと同期化し、及び現在ブロック高をクエリすることにより、時間指定されたアクセスがセキュアになる。

＜機能＞
Metanetブラウザ－ウォレットの仕様は、アプリケーションの以下の機能を保証する。
１．階層的鍵管理：資金を制御するため及びMetanet木（グラフ）を管理するために使用される鍵は同じ階層的決定性鍵インフラストラクチャを利用し、Metanetコンテンツのための鍵記録を保持するユーザの負荷を軽減する。
２．外部暗号通貨ウォレットを指す：外部（アプリケーションに本来備わっていない）ウォレットの認証及び同期化の能力は、障害点としてのブラウザ－ウォレットを除去することにより、更なるセキュリティを可能にする。
アプリケーションは、ブロックチェーントランザクションを記述し、鍵を収容する外部ウォレットの署名を要求し、この責任を別個のソフトウェア又はハードウェアへと委任する。
３．Metanetコンテンツの検索：ブラウザ－ウォレットは、グローベルデータベース内のMetanetノードトランザクションデータをクロールし、インデックス付けし、サービスし、及びランク付けすることを含み得る機能を有する第三者検索エンジンをサポートし及びクエリできる。Metanetプロトコルフラグを含むOP_RETURNトランザクションのデータベースが構成されてよい。BitDB２.０－https://bitdb.network/を参照のこと。
検索エンジンは、データを発見可能にするノードインデックスを、ブラウザ－ウォレットに提供できる。
４．データの読み出し及びブロックチェーンへの書き込み：検索エンジン及びフルノードを使用してブラウザにコンテンツを提供することに加えて、暗号通貨ウォレットのサポートは、ブラウザ－ウォレットからMetanetにコンテンツを直接書き込むことも可能にする。
５．データの伸長及び解読：ブラウザ－ウォレットは、解読鍵を扱い、Metanetコンテンツの伸長をその場で実行できる。
６．ノード識別子（ID_node）のキャッシング：より効率的なルックアップ及びクエリのために、ユニークなノード識別子は、ローカルにキャッシュされ得る。
７．ウェブサーバのバイパス：ノードインデックスが与えられると、ブラウザ－ウォレットは、ピアツーピア（peer－to－peer (P２P)）ブロックチェーンネットワークの任意のフルコピーメンバに、ノードに置かれたコンテンツについてクエリできる。Metanetはオンチェーンに存在するので、任意のフルコピーピアは、ノードのローカルコピー及びそのコンテンツを有していなければならない。
これは、ユーザのブラウザ－ウォレットが、単一のピアをクエリするだけでよいことを意味する。これは、中間ウェブサーバを必要とせず、直接に行うことができる。
図１５は、ブラウザ－ウォレットの概略、及びそのコア機能がアプリケーションの異なるコンポーネントに渡りどのように分割されるかを示す。

＜ブロックチェーン検索エンジン＞
検索エンジン：既存技術
従来知られている検索エンジン（Search engine (SE)）は、強力なウェブクローラがユーザクエリに従いウェブコンテンツの位置を特定し、インデックス付けし、ランク付けすることに頼っている。（同じ基礎にある原理は、Metanetをクロールする第三者ブロックチェーンSEへと拡張できる）。

SEは、クエリの中のキーワードの検索を通じて、関連するHTMLメタタグ及びコンテンツを識別する。クロールの結果は、後にインデックス付けされる。ここで、任意の埋め込み画像／ビデオ／メディアファイルが、分析され、分類される（catalogued）。次に、ユーザの場所、言語、及び装置を考慮して、インデックスの中から最も関連する結果が、プログラムによりランク付けされる。

典型的なSEは、以下の機能を有するべきである。
１．クロール：インターネットデータを識別し、ドメイン名、リンクされたページ、及び関連するキーワードのような関連するメタデータを通じてクロールする。新しいインターネットコンテンツは、既存のコンテンツを通じて発見され、任意の関連情報について更にクロールされる。
２．インデックス付け：コンテンツデータは、分析され、分類される（catalogued）。この情報は、データベースに格納される。
３．提供及びランク付け：コンテンツインデックスは、ユーザのクエリへの関連の順序でランク付けされる。

＜ブロックエクスプローラ＞
インターネット検索エンジン（SE）に類似する最も近いブロックチェーンは、ブロックチェーンエクスプローラ（blockchain explorer）であり、「ブロックエクスプローラ（block explorer）」又は「ブロックチェーンブラウザ（blockchain browser）」と呼ばれることがある。ブロックチェーンエクスプローラは、高レベルでのブロックチェーンのユーザフレントリなクエリを可能にするウェブアプリケーションであり、ウェブブラウザと同様に機能するが、インターネットではなくブロックチェーンに接続される。https://en.bitcoin.it/wiki/Block_chain_browserを参照のこと。

大抵の場合、これらのエクスプローラは、ブロック（ブロックヘッダのハッシュによりインデックス付けされる）、トランザクション（TxIDによりインデックス付けされる）、アドレス及び未使用トランザクションアウトプット（unspent transaction output (UTXO)）をインプットとして取り入れること及び検索することを可能にする。多くのエクスプローラは、生トランザクション及びブロックデータを読み出すために、それら自体のアプリケーションプログラミングインタフェース（application programming interface (API)）を提供する。Https://blockexplorer.com/api－refを参照のこと。

ブロックエクスプローラは、それらの能力を変化させながら、通常、トランザクションを分類し、及び取引される通貨価値、コイン及びアドレスの確認及び履歴のようなそれらの基本情報をユーザにとって理解の容易な形式で表示するために有用である。Bitcoin.com https://explorer.bitcoin.com/bch及びBlockchain.com https://www.blockchain.com/explorerのような多くのエクスプローラは、これらの及びBlockchair https://blockchair.com/のようなより高度なサイトの間で、この情報を選択して提供する方法に不一致が存在するが、更に、トランザクションの個々のインプット及びロックスクリプトを閲覧可能にする。

近年、ブロックチェーンデータに基づきウェブアプリケーションを実行するために使用される基本ブロックチェーンエクスプローラの多くの拡張が存在している。Memo.cash https://memo.cash/protocol及びMatter https://www.mttr.app/homeのようなこれらのアプリケーションは、特定のプロトコル識別子を含むブロックチェーントランザクションを分類し組織化する、並びにそれらの特定のトランザクションの中で符号化されたデータを表示するブロックエクスプローラと同様に動作する。

しかしながら、ブロックチェーンエクスプローラの使用に伴う以下の２つの重要な問題がある。これらは、本発明の実施形態により解決される。
１．ユニバーサル性：トランザクションに格納されたコンテンツデータを閲覧するための業界に渡る標準が現在存在しない。コンテンツデータは、基礎にあるブロックチェーンを生成し及びセキュアにするために使用されるプロトコルに関連しない任意のデータを表す。
２．キーワード検索：トランザクションに格納されたコンテンツデータは、人間の読めるキーワードにより検索可能である必要がある。現在のブロックエクスプローラは、検索入力としてキーワードを取り入れるのではなく、ブロック高、TxID、及びアドレスのようなトランザクションのプロトコルに基づく特性をクエリするために使用されるので、キーワード検索は、通常、現在のブロックエクスプローラの機能ではない。（しかしながら、幾つか、例えばBlockchairは、単語がトランザクションのスクリプトに直接含まれる場合には、単語を検索できる）。

重要なことに、本発明の強力な命名及びアドレス指定構造は、上述のように、従来知られているよりも、一層洗練されたブロックチェーンエクスプローラの構築を実現し及び可能にする。

＜提案されるMetanet検索エンジン＞
ブラウザ－ウォレットアプリケーションは、ノード識別子（ID_node）の発見のために、第三者検索エンジンと通信する。このような第三者は、既存のインターネット検索エンジンの能力を再現する強力な多様なサービスを提供し得ると考えられる。

Metanet検索エンジンの第三者は、Metanetプロトコルフラグにより識別可能な、ブロックチェーンに埋め込まれた（mined）全部のMetanetトランザクションのデータベースを維持する。このデータベースは、ID_node、ノード名、キーワード、TxID、及びブロック高を含む範囲インデックスにより、全部のMetanetノードを分類できる。

Bit DB https://bitdb.network/のようなサービスが既に存在する。これは、ブロックチェーンと絶えず同期し、標準的なデータベースフォーマットでトランザクションデータを維持する。ブラウザ－ウォレットは、Metanetトランザクションをクロールし、インデックス付けし、提供し、及びランク付けする責任を、このような第三者にオフロードし、Metanetグラフに格納されたコンテンツを特定するとき、それらのサービスへの接続を行う。

Metanetデータにのみ専用のデータベースを有することにより、効率的な節約が行われ得る。Bit DBと異なり、これは、全部のトランザクションに関連付けられたデータを格納せず、Metanetフラグを含むデータのみを格納する。MongoDBのような非関係性データベースのような特定のデータベースは、Metanetのグラフ構造を格納する際に更に効率的であり得る。これは、より速いクエリ、より小さな記憶空間、及びMetanetドメイン内の関連コンテンツのより効率的な関連付けを可能にする。

図１６は、Metanetインフラストラクチャ内のコンテンツをユーザが検索するとき、ブラウザ－ウォレットが第三者検索エンジンとどのように相互作用するかを示す。重要なことに、インターネットと対称的に、ルーティングが必要なく、従って、本発明は効率、速度、処理、及び必要なリソースの点で、重要な利点を提供することに留意すべきである。

処理は、以下の通りである。
１．エンドユーザは、ブラウザ－ウォレット検索バーにキーワードを入力する。
２．ブラウザ－ウォレットは、キーワードクエリを第三者SEへ送信する。
３．SEは、キーワードを自身のデータベースに対してチェックし、関連コンテンツを含む任意のMetanetノードのID_nodeを返す。第三者は、関連コンテンツの提案を提供すると共に、各ノードにある他のインデックスもユーザに返すことができる。
４．ブラウザ－ウォレットは、MURLを構成するために、ノード識別子及びそれに関連付けられたドメイン名を使用する。
５．ブラウザ－ウォレットは、ブロックチェーンのフルコピーを有する任意のネットワークピアから、特定のノードに属するコンテンツを要求する。
６．ネットワークピアは、ブラウザ－ウォレットに要求されたコンテンツを提供する。ピアは、ブロックチェーンのコピーを有するので、それらは、コンテンツのコピーも有し、従って、１つの要求のみが行われ、それは決して他のネットワークピアへ転送されない。

第三者SEはMetanetノードの属性の記録をインデックス付けし及び維持する責任のみを有し、一方で、ノードに格納された生コンテンツデータが、代わりに、ブロックチェーンのフルコピーを有するネットワークピア（例えば、フルコピーピア、マイナー、アーカイブ）により格納されることが強調される。

＜コンテンツ表示－Metanetブラウザ＞
ブラウザ－ウォレットアプリケーションは、任意の標準的なウェブブラウザが提供すべき同じフロントエンド能力をエミュレートする。これらの機能は限定ではないが以下を含む。
１．検索（Searching）：コンテンツの位置を特定するために、検索エンジン（SE）へのアクセスを提供する。
２．読み出し（Retrieval）：既知のプロトコル、例えばハイパーテキスト転送プロトコル（Hypertext Transfer Protocol (HTTP)）を用いてコンテンツの転送を実現するために、サーバと津シンする。
３．解釈（Interpreting）：（例えば、JavaScriptの）生コードをパースし、実行する。
４．レンダリング（Rendering）：エンドユーザにより閲覧されるべき、パースされたコンテンツを効果的に表示する。
５．ユーザインタフェース（User interface (UI)）：ユーザ入力のための動作ボタン及びメカニズムを含む、コンテンツと相互作用するための直感的インタフェースを提供する。
６．記憶（Storage）：コンテンツへの繰り返しアクセスを向上するために、インターネットコンテンツのキャッシュ、クッキー、等の、ローカル一時的記憶能力。

特定の実施形態では、ウェブブラウザとして動作することを担うブラウザ－ウォレットアプリケーションのソフトウェアコンポーネントは、それらの属性を用いて（SEを用いて）検索可能且つ（ピアから）読み出し可能なブロックチェーンに埋め込まれたMetanetコンテンツに対して、上述の機能を実行できる。

＜再結合、圧縮解除、及び解読＞
本発明の特定の実施形態によると、ブラウザ－ウォレットアプリケーションのウェブブラウザソフトウェアコンポーネントは、所与のMetanetコンテンツに対して実行される必要のある全部の動作を処理することができる。一般に実行される必要のある多くのこのような動作が存在するが、私たちは、少なくとも以下のものが、Metanetプロトコル及びインフラストラクチャを用いてアプリケーションにより実行されることを想定する。

再結合（Recombination）：Metanetコンテンツが構成され複数の別個のノードトランザクションに挿入される必要のある場合に、アプリケーションは、全部の関連ノードからコンテンツを要求し、元のコンテンツを再構成する。分裂したコンテンツの順序及び構造は、各ノードの属性の中の追加フラグを用いて符号化できる。

圧縮解除（Decompression）：コンテンツデータが圧縮された形式でブロックチェーンに格納される場合、それは、ブラウザ－ウォレットに、どの標準的な圧縮方式が使用されているかを示すために、フラグを含むべきである。アプリケーションは、このフラグに従いコンテンツを圧縮解除する。

解読（Decryption）：コンテンツが暗号化されている場合、暗号化方式を指定するために、フラグが使用されるべきである。アプリケーションは、（後述するように）自身の解読鍵ウォレットから鍵を特定し、使用された暗号化方式に従い使用するためにコンテンツデータを解読する。

これらの動作をコンテンツデータに対して実行する際に、ブラウザ－ウォレットに、所与の動作が実行される必要のあることを示すために、フラグが使用できる。これは、動作の適用されるノードの属性の部分として適切な<operation_flag>が含まれ得る任意の他の動作に一般化される。

＜キャッシング＞
ローカルファイルのキャッシング及びクッキーは、標準的なウェブブラウザの共通の及び重要な機能である。ブラウザ－ウォレットアプリケーションは、ID_nodeの記録及び関心のあるコンテンツに関連する他のノード属性を任意的に保持するために、同様の方法でローカル記憶も使用する。これは、頻繁に訪れるMetanetノードからのコンテンツのより効率的なルックアップ及び読み出しを可能にする。

Metanetは、可変でありプロバイダによってはウェブ閲覧ソフトウェアにより変更され又は検閲され得るインターネットデータのキャッシングに本来伴う問題を解決する。Metanetデータをキャッシングするとき、ユーザは、それがブロックチェーン上の不変記録として初めに含まれたときと同じ状態にあるかを、常に容易に検証できる。

＜暗号通貨ウォレット＞
＜階層的決定性鍵管理＞
決定性鍵DKは、単一の「シード（seed）」鍵から初期化された秘密鍵である（Andreas M. Antonopoulos, Chapter ５ in “Mastering Bitcoin” O’Reilly ２^nd Ed., ２０１７, pp. ９３－９８を参照のこと）。シードは、マスタ鍵として動作するランダムに生成された数値である。決定性鍵を導出するよう、インデックス番号又は「チェーンノード」（HD Wallets－BIP－３２/BIP－４４を参照のこと）のような他のデータとシードを結合するために、ハッシュ関数が使用できる。これらの鍵は、互いに関連付けられ、シード鍵により完全に復元可能である。シードは、異なるウォレット実装の間で、ウォレットの簡単なインポート／エクスポートを可能にし、ユーザがMetanetブラウザ－ウォレットと関連して外部ウォレットを使用したい場合に、更なる自由度を与える。

階層的決定性（hierarchical deterministic (HD)）ウォレットは、決定性鍵のよく知られた導出方法である。HDウォレットでは、親鍵は一連の子鍵を生成し、また、子鍵は一連の孫鍵を導出する、等である。この木のような構造は、幾つかの鍵を管理するための強力なメカニズムである。

好適な実施形態では、HDウォレットは、図１６に示すMetanet構造に組み込むことができる。HDウォレットを使用する利点は以下を含む。
１．構造（Structure）：追加の組織的な意味は、異なる目的のために異なる鍵束を使用することを表し得る。例えば、ユーザは、異なるブランチ（及びそれらの対応するサブ鍵）を異なるタイプのデータに専用にすることができる。
２．セキュリティ（Security）：ユーザは、対応する秘密鍵を有しないで、一連の公開鍵を生成でき、受信のみの能力でHDウォレットを機能させ、安全でないサーバでの使用に適するようにする。また、少数のシークレットしか格納される必要がないので、暴露されるリスクが低い。
３．復元（Recovery）：鍵が失われ／壊れた場合、それらはシード鍵から復元できる。

＜本来（内部）及び外部ウォレットのサポート＞
有利なことに、本発明の実施形態は、伝統的なウェブブラウザの機能を、１つ以上の暗号通貨ウォレットと直接マージできる。これは、機能的には、「インターネット」コンテンツに対する支払いを、「インターネット」コンテンツのエンドユーザへの配信ととのように結合するかである。

これを達成するために、ブラウザ－ウォレットの実施形態は、暗号通貨ウォレットとして動作する専用のビルトインソフトウェアコンポーネントを有してよい。このウォレットは、アプリケーション自体に本来備わっており、暗号通貨鍵を管理するため、及びブラウザ－ウォレット自体の中でMetanetコンテンツについての支払いとしてトランザクションを認可するために使用できる。

これは、アプリケーションのブラウザコンポーネントが、ウォレットコンポーネントに、Metanetコンテンツを閲覧するために、解読鍵、アクセストークン、又はその他のものを購入することにより、必要な支払いを認可することを促すことができることを意味する。アプリケーションは、支払いを処理するために外部の第三者を呼び出す必要がない。従って、関心のあるMetanetコンテンツは、アプリケーションにより消費され、その場で支払われる。

＜外部ウォレット＞
ユーザが彼らの暗号通貨秘密鍵を代わりに外部ウォレット（ソフトウェア又はハードウェア）に管理し又は保持したい又は複数のウォレットを使用したいと望む場合でも、同じ利点及び機能が、本願の実施形態により達成できる。これは、アプリケーションの本来のウォレットの代わりに又はそれと関連して実行されてよい。

このような実施形態では、アプリケーションは、外部ウォレットとのリンク又はペアリングを確立し、それと同期するが、ブラウザ－ウォレット自体の中に秘密鍵を格納しない。代わりに、ブラウザコンポーネントは、コンテンツについての支払いが行われることを促し、アプリケーションは、選択された外部ウォレットからデジタル署名による認可を要求する。この認可はユーザにより行われ、ブラウザ－ウォレットは、トランザクションをブロードキャストし、支払い済みのコンテンツを閲覧できる。

＜Metanetトランザクションの読み出し及び書き込み＞
Metanetの固有の利点は、それが、支払い及びコンテンツデータを記録するために、同じデータ構造、つまりブロックチェーンを使用することである。これは、ソフトウェアウォレットが、暗号通貨の交換に純粋に基づくトランザクションを生成することに加えて、コンテンツデータをMetanetインフラストラクチャに書き込むために使用できることを意味する。

アプリケーションに本来組み込まれたウォレットは、標準的な簡易支払検証（simplified payment verification (SPV)）クライアントよりも複雑なトランザクションをブロックチェーンに書き込むことができる。https://bitcoin.org/en/glossary/simplified－payment－verificationを参照のこと。ウォレットは、ユーザが、彼らのコンピュータからブロックチェーンに埋め込まれるべきコンテンツデータを選択することにより、Metanetノードトランザクションをアプリケーションからブロックチェーンに直接書き込むことを選択できるようにする。

ブラウザ－ウォレットアプリケーションがユーザインタフェース（user interface (UI)）を有するので、ウォレットコンポーネントが、ブラウザコンポーネントの中で又は前もってユーザのコンピュータ上に構成されたコンテンツデータを含むトランザクションを生成しブロードキャストすることを可能にする。この能力は、専用のウォレットがそれ自体で処理することを達成するのは非常に困難である。

＜アクセス鍵／トークンウォレット＞
以上の説明から、Metanetプロトコルに内蔵された、ECC鍵ペア又はAES対称鍵を用いてコンテンツを暗号化する能力、及び対応する解読鍵又はトークンを購入する能力を思い出してほしい。私たちは、これらをアクセス鍵又はアクセストークンと呼ぶ。

このような鍵／トークンは、コンテンツを閲覧又は編集（一回限りの使用又は複数回の使用）する許可をユーザに与え、（望ましい場合には同じ鍵が両方の目的で使用されてよいが）ユーザの暗号通貨ウォレットを制御する鍵とは異なる役割を果たす。この理由のために、アプリケーションの本来備わっている暗号通貨ウォレットと別個に、アクセス鍵及びトークンを格納し及び管理するために使用される新しいウォレットを導入することは有利である。

特定の時間期間の後に、アクセス鍵／トークンを消滅させることにより、Metanetコンテンツへの時間指定されたアクセスの概念を導入することも可能である。これは、アクセス鍵／トークンが信頼できる実行環境（Trusted Execution Environment (TEE)）に格納され、ユーザにより直接アクセス可能でないことを要求することにより、達成できる。

アクセス鍵／トークンが「消滅」し得るという事実は、暗号通貨秘密鍵が消滅するというリスクを負わないことを保証するために、アクセス鍵／トークンを暗号通貨ウォレットに格納しないことの動機付けの要因になり得る。

暗号通貨ウォレットと同様の方法で、解読鍵及びアクセストークンは、効率的な処理及び展開を実現するために決定論的に格納され管理されることができる。解読鍵（例えば、ECC秘密鍵）は、マスタ鍵への後の追加により生成され復元できる。一方で、アクセストークンは、何らかの初期トークンによりシードされるハッシュチェーンを用いて再構成できる。

ここで、暗号通貨ウォレットが、他のユーザと取引する際に及び新しいMetanetノードを生成する際に使用される鍵ペアの決定性鍵の生成を扱うこと、一方で、鍵／トークンウォレットが、暗号通貨ウォレットにより購入された鍵及びトークンを扱うこと、を区別することが重要である。

＜ブロック高許可（Block height permissioning）＞
タイムロックは、ブロック高許可を可能にするためにBitcoinスクリプト言語に含まれ得る。oOp_code OP_CHECKLOCKTIMEVERIFY (CLTV)は、トランザクションアウトプット（UTXO）が使用のために許容されるブロック高を設定する。

ブロック高許可の利点は以下の２つである。
１．バージョン制御（Version control）：Metanetプロトコルでは、最新バージョンのノードが、最大ブロック高にあるノードから識別できる。ブラウザ－ウォレットは、ブロック高によりファイルの最新バージョンを表示するよう設定できるだけでなく、proof－of－workバージョン制御も可能にする。
２．時間指定されたアクセス（Timed access）：ブラウザ－ウォレットアプリケーションは、ユーザにより購入された解読鍵を自動的に周期的に消滅できる。これは、ビューアが、彼らの支払った時間期間の間にのみ、コンテンツデータにアクセスできることを保証する。解読鍵のクローン化は、信頼できる実行環境（trusted execution environment (TEE)）にそれらを格納することにより防ぐことができる。更に、アトミックスワップは、（コンテンツデータの解読のための）決定性鍵Dkの購入を含む。この決定性鍵は公衆に見えるが、TEEは、Dkとセキュアにエンクレーブされた（enclaved）秘密鍵との結合に署名するために使用できる。

ブラウザ－ウォレットは、任意の外部クロック又は第三者の時間のお告げ（time oracle）に頼るのではなく、自身の時間のプロキシとしてブロック高を使用するために、ブロックチェーンの現在状態と同期するよう構成できる。

＜ウェブサーバのバイパス＞
本発明は、ブラウザ（クライアント）及びウェブサーバが分散型ピアインターネットを介して情報を通信し及び交換するための新しいメカニズムを可能にし、これは、ドメインネームシステム（domain name system (DNS)）サーバ及び標準的なネットワークルーティング手順をバイパスする。Http://www.theshulers.com/whitepapers/internet_whitepaper/を参照のこと。本発明は、ブロックチェーンのフルコピーを維持するピアを含む、ブラウザ－ウォレットアプリケーションがコンテンツを提供され得る新しいネットワークアーキテクチャを提供する。

＜ローカルフルコピーピア＞
各々の地理的領域、例えば、郵便番号、町、都市、にあるローカルピアのシステムを考える。私たちは、このローカルネットワークの中で、少なくとも１つのピアが、ブロックチェーンのフルコピーを維持することを前提とする。私たちはこれをローカルフルコピーピア（Local Full－Copy Peer (LFCP)）と呼ぶ。私たちの目的のためには、LFCPは、Metanetフラグを含むブロックチェーントランザクションを格納するだけでよいが、それに限定されない。

全部のユーザは、デフォルトで、LFCPへ「get」要求を送信する。ピアがブロックチェーン全体の完全な最新のコピーを維持するとき、要求される任意のノードIDがLFCPに利用可能なので、全ての要求がサービス可能である。SEがMetanetコンテンツを格納し及び標準的なSEの主要機能を実行するために十分に強力且つ大きい場合、Metanet検索エンジンがLFCPとして動作してもよいことに留意する。

最も簡単な例では、全てのLFCPが、完全なブロックチェーンを格納可能である必要があるとき、同じ記憶及びディスク空間オーバヘッドを有する（出願時に約２００GB）。各LFCPの間の区別は、Metanetユーザからのローカルな要求に応じて、それらがそれらの能力をスケーリングすることである。従って、世界中の各Metanetユーザが彼らの最も近いLFCPをデフォルトで要求する場合、各LFCPは、彼らのローカルな要求を満たすために、彼らの運用能力をスケーリングしようとするべきである。都市のような人口密集地域は、多くのクラスタ化されたサーバを含むLFCP動作を要求する。一方で、より小さな町のような疎な地域は、より小さなLFCP動作を要求する。

ディスク空間要件は汎用的であるが、LFCP毎のCPU要件はローカルネットワークの要求に適応することに留意することが重要である。これは、Freenetのような適応型ネットワークの例である。https://blockstack.org/papers/を参照のこと。

このようなシステムの１つの利点は、所与のID_nodeに関連付けられたコンテンツを読み出すとき、ユーザが、彼らのLFCPと単一の（ローカルな）接続を生成するだけでよいことである。他のピアはそれら自身の要求されたコンテンツを提供されることを保証されるので、LFCPが要求を他のピアへ送信する必要はない。

Metanetは、非集中化及び非冗長性のような、インターネットに勝る多くの利点を提供する。これらは、IFPSのような他のピアツーピア（P２P）ファイル共有サービスと類似している。しかしながら、Metanetは、不変性及び重大なことにネットワークを所与のコンテンツに対する要求で溢れさせる必要を除去することにより、これらの既存のP２Pモデルを改良する。

Metanetインフラストラクチャは、これらのピアのネットワークを利用することにより、任意の１つのLFCPの障害に対してもロバストである。これは、LFCPが無効にされた場合に、エンドユーザが単にデフォルトで彼らの次に近いLFCPを用いることを意味する。これは、任意の所与の時間に要求の観点で能力を下回る又は上回る近くのピアを示すために、LFCPが互いに通信する場合、より効率的にできる。これは、ユーザが彼らの要求を最も適切なピアに送信し、近くのLFCPの間で要求の動的な平衡を確立することを可能にする。

＜グローバルフルコピーピア＞
私たちは、ここで、より小さなピアにとってユニバーサルディスク空間要件が大きくなり過ぎるシナリオを考える。これは、ブロックチェーンのMetanet部分が採択（adoption）によりスケーリングし増大するために生じ得る。

この場合、より小さなLFCPは、人気システムに基づき、Metanetノードトランザクションを格納するために、自身のディスク空間能力を使用するべきである（要求の量及び特性によりコンテンツをランク付けする既存の技術がある）。これは、LFCPが、（要求処理能力のために）それらのCPU及び（コンテンツ提供能力のために）それらの記憶割り当ての両方を、コンテンツの量及び特性の両方においてそれらのローカルな地理的要求に適するよう調整することを意味する。

LFCPが全てのMetanetトランザクションコンテンツを格納できないという事実を解決するために、グローバルフルコピーピア（Global Full－Copy Peer (GFCP)）の概念が利用できる。GFCPは、以下の特性を有するフルコピーピアである。
１．GFCPは、常にブロックチェーンのフルコピーを維持するために、自身のディスク空間能力を増大させる。
２．GFCPは、相当なCPUリソースを有するので、LFCPよりも想到に多くの要求を処理できる。グローバルフルコピーピアは、多数のLFCPが障害になった場合に、要求の急激な増加を処理できなければならない。

GFCPの２つの主な機能がある。第１に、LFCPからオーバーフローリクエストの際に、Metanetコンテンツのユーザ要求のためのフェールセーフとして機能することである。第２に、GFCPは、過去にマイニングされた全部のMetanetコンテンツを格納するためのアーカイブピアとして動作する。これは、多数のLFCPがそれらの記憶準備（provision）から幾つかのコンテンツを省略した場合でも、任意のMetanetノードコンテンツがアクセスできることを保証する。

＜グローバルデータバンク＞
GFCPの概念は、強力なものであり、Metanetの全体的なアーキテクチャが、包括的なグローバルデータバンクを生成するという既存の問題に対するソリューションをどのように提供するかを説明する。

従来は、ユニバーサルなグローバルにアクセス可能なデータバンクは、中央当局により維持される必要があるので、安全に構成することができなかった。この中央当局は、障害点及び信頼点の両方をシステムに注入する。重要なことに、ある組織が全部のインターネットデータを格納し維持することに依存している場合、私たちは、それらが情報を壊すことなく、正しく合法的にそうしていることを信頼する必要がある。

Metanetインフラストラクチャにより、私たちは、これらの問題の両方、信頼の問題及び中央化の問題を、グローバルデータセンタの概念から効果的に除去した。ここで、このようなGFCPは、記憶のために必要なディスク空間を提供することに依存し、格納されるべき情報を検証し及び認証することに依存しないので、このようなGFCPが生成できる。

Metanetにより、何が格納されるかの検証処理は、マイナーにより行われる。従って、ユニバーサルなグローバルデータバンクは、それらがブロックチェーン情報を壊さないので、信頼できる。GFCPは、信頼される必要はなく、記憶を提供するだけでよい。

全部のGFCPが同じ情報を格納できること、ブロックチェーン自体に対して常に検証可能であり証明可能であることは、多数のこのようなGFCPに渡り再現できることを意味する。

これは、多数のグローバルデータバンクを並列に存在させ、証明可能に同じ情報を格納させることにより、単一の障害点を有するという問題を解決することも意味する。

図１７は、２個のLFCP及び１個のGFCPのシステムを示し、個々のピアの障害に対してロバストであるネットワーク内で各ピアが他のピアをどのようにサポートできるかを説明する。

上述のブラウザ－ウォレットアプリケーションの実施形態において実施され得る本発明の態様は、以下を含むがそれに限定されない、従来技術に勝る多数の顕著な特徴及び利点を提供する。
１．決定性鍵：暗号通貨及びMetanetアドレスの両方のための階層的決定性鍵管理は、アプリケーションの同じウォレットコンポーネントの中で実行される。これは、複数の機能を有する鍵の編成が可能になり、それらの記憶要件を軽減し、鍵復元を可能にする。
２．支払いメカニズム：アプリケーションは、消費者が、従来認証し及び信頼を提供する別のアプリケーション又は第三者支払いサービスを指す必要なしに、商人に直接支払うことを可能にする。これは、同じブロックチェーンプラットフォームを介して、デジタルコンテンツの購入及び配信が行われることを可能にする。アプリケーションは、小さな価値の交換を含むBitcoin支払い、又は複数のパーティを含むより複雑なトランザクションの利点を本来備える。
３．ウェブサーバのバイパス：アプリケーションは、従来高容量トラフィック、要求、及びルーティングを処理する伝統的なウェブサーバのバイパスを実現する。これは、アプリケーションが、他のLFCPへ要求を転送する必要がなくユーザにサービスすることを保証されている単一のLFCPからコンテンツを要求するだけでよいからである。これは、全体のトラフィック量、及び各要求の完了時間を削減する。
４．時間指定されたアクセス：アプリケーションは、ブロックチェーンと同期すること及びブロックチェーンを用いてブロックチェーンの現在状態に基づきアクセス許可を実施することにより、コンテンツへの時間指定されたアクセスを実現する。これは、第三者サービスが、元の所有者の権利を保護しながら、時間に渡りユーザの権利を監視する必要を除去する。

使用例：非集中化アプリストア（Swapp store、Swappストア）
ここに提示されるMetanetアーキテクチャについての（説明のみを目的とする）第１の使用例は、アプリケーション（アプリ、app）の非集中化支払い及び配信に関する。

私たちは、アプリ開発者Alice及び消費者Bobが、互いに取引したいと望むシナリオを考える。このトランザクションは、アトミックスワップの形式を取り、その中で、Bobがアプリケーションデータにアクセスすることを許可するシークレット鍵のために、金銭が交換される。暗号化アプリケーションデータは、既に、Metanetノードトランザクションの部分として公開されている。

アトミックスワップアプリケーションは、Swapp（スワップ）として知られている。第三者プラットフォーム（Swappストア）は、Metanetに存在するアプリケーションを分類し広告するために使用されてよい。しかしながら、アクセス鍵のための支払い及びBobのようなユーザへの転送は、第三者を含む必要はなく、商人と消費者との間で直接行うことができる。

以下の章は、Aliceによるアプリの生成から、Bobによるその展開まで、Swappを買い及び売るために使用され得る処理を詳述する。処理を通じて、Alice及びBobは、彼らのそれぞれのブラウザ－ウォレットを使用して、Metanetと相互作用する。

＜発行（Publishing）＞
１．Aliceは、アプリケーションを記述する。このアプリケーションを構成するデータは、<App>により示されるコンテンツである。彼女は、シークレット鍵S_kを用いて、それを暗号化する<e(App)>。
２．Aliceは、ノードトランザクションID_{Alice_App}を生成し、彼女の第１Metanetドメイン（木）を設定する。彼女は、ノードアドレスとして使用されるべき１AliceAppHtKNngkdXEeobR７６b５３LETtpy (P_AliceApp)を生成する。
３．Aliceは、次に、第１ノードの子を生成して、彼女のアプリケーションのMetanetライブラリに対応する木を形成する。Aliceの木ドメインは、図１８に示される。
この木にあるリーフノードのうちの１つは、インデックスID_Appを有する彼女のアプリケーション<App>に対応するノードである。このノードでは、Aliceは、暗号化アプリケーションデータ<e(App)>をノードのインプットスクリプト（scriptSig）に挿入する。アプリデータは、シークレット鍵s_kを用いてKoblitz法を用いて暗号化される。
このノードトランザクションは、以下に示される。
［表３］

４．Aliceは、ID_AliceApp、P_AliceApp、及びドメイン名「AliceApp」を公にブロードキャストする。これは、ソーシャルメディア、インターネットウェブサイトを介して、又は第三者Metanetウェブサイトを使用して、可能である。

＜購入＞
１．Bobは、彼が彼のブラウザ－ウォレット上で閲覧するMetanetウェブサイト（Swappストア）にリストされたパズルゲームをダウンロードし、Aliceのアプリを見たいと望む。
２．Bobは、次に、ウェブサイトからの情報を用いてAliceと連絡を取り、アトミックスワップを設定する。スワップは、BobがBitcoinの合意した価格をAliceに支払い、Aliceがシークレット鍵s_kを開示するよう、又は何もイベントが生じないよう、設計される。
３．アトミックスワップが完了し、Bobのブラウザ－ウォレットは、シークレット鍵s_kを自身のアクセス鍵／トークンウォレットに格納する。

＜展開＞
Bobは、今や、前もってAliceが発行したアプリケーションデータを彼が解読することを可能にする鍵s_kを有する。アプリをダウンロードし、それを展開するために、Bobは、以下を行う。
１．Bobは、Metanet検索エンジン（SE）を用いて、暗号化されたアプリデータ<e(App)>に関連付けられたMURLを見付ける。彼は、キーワード「AliceApp」及び「App」を、彼のブラウザ－ウォレット内の検索バーへの入力として使用する。第三者SEは、クエリを解決し、以下のMURLを返す。
mnp://aliceapp/games/puzzle/app
このロケータは、自身のインプットスクリプトの中に暗号化アプリデータを含むユニークなMetanetノードID_Appに対応する。
２．Bobのブラウザ－ウォレットは、このMURLを受信し、最も近い適切なLFCPへ要求を送信する。このピアは、Bobに要求されたデータ<e(App)>を提供する。
３．ブラウザ－ウォレットは、ID_Appの属性に従いデータを処理する。これは、シークレット鍵s_kを用いてアプリケーションデータを解読し<App>を処理することを含む。
４．Bobは、アプリケーション<App>を彼のブラウザから彼のコンピュータへダウンロードする。Bobは、今や、アクセスを予め購入することなく、アプリケーションをローカルに展開できる。

図１９は、上述の説明のための使用例において概説された全体処理を説明する。フローチャートは、２つのアクションブランチ、つまりAliceのもの（左側から開始する）とBobのもの（右側から開始する）を示す。Aliceに対応するブランチは初期発行フェーズを示し、Bobのものはアトミックスワップを介して購入を設定するフェーズを示す。

Bobのブランチで、アトミックスワップ設定フェーズとして、彼は、以下のトランザクションTxID_Bobをブロードキャストする。
［表４］

このトランザクションでは、アウトプットは、Aliceが使用（spend）するためにBobに開示されるべきシークレット解読鍵s_kを必要とする秘密鍵パズルによりロックされる。

この図の中のAlice及びBobのブランチは、Aliceがアトミックスワップトランザクションの完了に成功する時点で収束する。これは、AliceがトランザクションTxID_Aliceをブロードキャストするとき、達成される。
［表５］

このトランザクションがブロードキャストすると直ぐに、Alice及びBobのアクションは再び分岐する。AliceはxBitcoinの支払いを受け、一方で、Bobはシークレット解読鍵s_kを受信し、MetanetからAliceのアプリケーションを読み出し解読することができる。

図２０を参照すると、本開示の少なくとも一実施形態を実施するために使用され得るコンピューティング装置２６００の説明のための簡略ブロック図が提供される。種々の実施形態で、コンピューティング装置２６００は、上述の図示のシステムのうちのいずれかを実装するために使用されてよい。例えば、コンピューティング装置２６００は、データサーバ、ウェブサーバ、ポータブルコンピューティング装置、パーソナルコンピュータ、又は任意の電子コンピューティング装置として使用するために構成されてよい。図２０に示すように、コンピューティング装置２６００は、主メモリ２６０８及び永久記憶装置２６１０を含む記憶サブシステム２６０６と通信するよう構成され得る１つ以上のレベルのキャッシュメモリ及びメモリ制御部（集合的に２６０２とラベル付けされる）を備える１つ以上のプロセッサを含んでよい。主メモリ２６０８は、図示のように、動的ランダムアクセスメモリ（ＤＲＡＭ）２６１８及び読み出し専用メモリ（ＲＯＭ）２６２０を含み得る。記憶サブシステム２６０６及びキャッシュメモリ２６０２は、本開示で説明されたようなトランザクション及びブロックに関連付けられた詳細事項のような情報の記憶のために使用されてよい。プロセッサ２６０２は、本開示で説明されたような任意の実施形態のステップ又は機能を提供するために利用されてよい。

プロセッサ２６０２は、１つ以上のユーザインタフェース入力装置２６１２、１つ以上のユーザインタフェース出力装置２６１４、及びネットワークインタフェースサブシステム２６１６とも通信できる。

バスサブシステム２６０４は、コンピューティング装置２６００の種々のコンポーネント及びサブシステムが意図した通りに互いに通信できるようにするメカニズムを提供してよい。バスサブシステム２６０４は、単一のバスとして概略的に示されるが、バスサブシステムの代替の実施形態は、複数のバスを利用してよい。

ネットワークインタフェースサブシステム２６１６は、他のコンピューティング装置及びネットワークへのインタフェースを提供してよい。ネットワークインタフェースサブシステム２６１６は、幾つかの実施形態では、コンピューティング装置２６００の他のシステムからデータを受信し及びそれへデータを送信するインタフェースとして機能してよい。例えば、ネットワークインタフェースサブシステム２６１６は、データ技術者が、装置をネットワークに接続することを可能にする。その結果、データ技術者は、データセンタのような遠隔地にいがなら、データを装置へ送信し、データを装置から受信できる。

ユーザインタフェース入力装置２６１２は、キーボード、統合型マウス、トラックボール、タッチパッド、又はグラフィックタブレットのような指示装置、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンのようなオーディオ入力装置、及び他の種類の入力装置のような、１つ以上のユーザ入力装置を含んでよい。通常、用語「入力装置」の使用は、コンピューティング装置２６００に情報を入力する全ての可能な種類の装置及びメカニズムを含むことを意図する。

１つ以上のユーザインタフェース出力装置２６１４は、ディスプレイサブシステム、プリンタ、又はオーディオ出力装置のような非視覚的ディスプレイ、等を含んでよい。ディスプレイサブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、又はプロジェクションのような平面装置、又は他のディスプレイ装置を含んでよい。通常、用語「出力装置」の使用は、コンピューティング装置２６００から情報を出力する全ての可能な種類の装置及びメカニズムを含むことを意図する。１つ以上のユーザインタフェース出力装置２６１４は、例えば、ユーザインタフェースを提示して、ここに記載したプロセス及び変形を実行するアプリケーションとのユーザ相互作用が適切であるとき、そのような相互作用を実現するために使用されてよい。

記憶サブシステム２６０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構造を記憶するコンピュータ可読記憶媒体を提供してよい。アプリケーション（例えば、プログラム、コードモジュール、命令）は、１つ以上のプロセッサにより実行されると、本開示の１つ以上の実施形態の機能を提供し、記憶サブシステム２６０６に格納されてよい。これらのアプリケーションモジュール又は命令は、１つ以上のプロセッサ２６０２により実行されてよい。記憶サブシステム２６０６は、更に、本開示に従い使用されるデータを格納するレポジトリを提供する。例えば、主メモリ２６０８及びキャッシュメモリ２６０２は、プログラム及びデータのための揮発性記憶を提供できる。永久記憶装置２６１０は、プログラム及びデータの永久（不揮発性）記憶を提供でき、磁気ハードディスクドライブ、取り外し可能媒体に関連付けられた１つ以上のフロッピディスクドライブ、取り外し可能媒体に関連付けられた１つ以上の光ドライブ（例えば、ＣＤ－ＲＯＭ、又はＤＶＤ、又はＢｌｕｅ－Ｒａｙ）ドライブ、及び他の同様の記憶媒体を含んでよい。このようなプログラム及びデータは、本開示に記載した１つ以上の実施形態のステップを実行するためのプログラム、及び本開示に記載したトランザクション及びブロックに関連付けられたデータを含み得る。

コンピューティング装置２６００は、ポータブルコンピュータ装置、タブレットコンピュータ、ワークステーション、又は後述する任意の他の装置を含む種々のタイプのものであってよい。さらに、コンピューティング装置２６００は、１つ以上のポート（例えば、USB、ヘッドフォンジャック、光コネクタ、等）を通じてコンピューティング装置２６００に接続可能な別の装置を含み得る。コンピューティング装置２６００に接続され得る装置は、光ファイバコネクタを受けるよう構成される複数のポートを含んでよい。従って、この装置は、光信号を、処理のために装置を接続するポートを通じてコンピューティング装置２６００に送信される電気信号に変換するよう構成されてよい。コンピュータ及びネットワークの絶えず変化する特性により、図２０に示したコンピューティング装置２６００の説明は、装置の好適な実施形態を説明する目的の特定の例としてのみ意図される。図２０に示したシステムより多くの又は少ないコンポーネントを有する多くの他の構成が可能である。

上述の実施形態は、本発明を限定するのではなく、説明すること、及び当業者は添付の特許請求の範囲により定められる本発明の範囲から逸脱することなく多くの代替的実施形態を考案できることに留意すべきである。特許請求の範囲において、括弧内の任意の参照符号は、請求項を限定することを意図しない。用語「有する」及び「含む」（comprising、comprises）等は、任意の請求項又は明細書全体に列挙されたもの以外の要素又はステップの存在を排除しない。本願明細書では、「有する」は「有する又は構成される」を意味し、「含む」は「含む又は構成される」を意味する。要素の単数の参照は、該要素の複数の参照を排除しない。逆も同様である。本発明は、幾つかの別個の要素を含むハードウェアにより、及び適切にプログラムされたコンピュータにより、実装できる。幾つかの手段を列挙する装置クレームでは、これらの手段のうちの幾つかは、１つの同じハードウェアアイテムにより具現化されてよい。単に特定の手段が相互に異なる従属請求項に記載されるという事実は、これらの手段の組み合わせが有利に使用されないことを示さない。

Claims (13)

1. コンピュータにより実施される方法であって、
   少なくとも１つのブロックチェーントランザクション（Tx）を処理するステップ、を含み、
   前記ブロックチェーントランザクション（Tx）は、第１ブロックチェーンプロトコルに従い前記ブロックチェーントランザクションが有効であるために要求されるトランザクションID（TxID）を含み、
   前記ブロックチェーントランザクション（Tx）はアウトプットを含み、
   前記アウトプットは、
   前記ブロックチェーントランザクションが前記第１ブロックチェーンプロトコル以外の更なるプロトコルに従い形成されることを示すプロトコルフラグと、
   任意公開鍵（discretionary public key （DPK））と、
   任意トランザクションID（discretionary transaction ID （DTxID）と、
   を含み、前記任意公開鍵と前記任意トランザクションIDは、前記更なるプロトコルの部分であり、前記第１ブロックチェーンプロトコルにより要求されない、方法。
2. 前記ブロックチェーントランザクション（Tx）は、データ部分、又はデータ部分への参照を更に含む、請求項１に記載の方法。
3. ｉ）前記データ部分、又はデータ部分への参照は、前記ブロックチェーントランザクションの前記アウトプットの中で提供され、及び／又は、
   ｉｉ）前記プロトコルフラグ、及び／又は前記任意公開鍵（DPK）、及び／又は前記任意トランザクションID（DTxID）は、前記アウトプット（UTXO）に関連付けられたロックスクリプトの中で提供される、請求項２に記載の方法。
4. 前記データ部分、前記データ部分への参照、前記プロトコルフラグ、前記任意公開鍵（DPK）及び／又は前記任意トランザクションID（DTxID）は、後のトランザクションへのインプットとしての後に使用に対してアウトプットを無効としてマークするスクリプトオペコードに続く位置において、前記ブロックチェーントランザクション（Tx）の中で提供される、請求項２又は３に記載の方法。
5. 前記ブロックチェーントランザクション（Tx）は１つ以上の属性を更に含む、請求項１～４のいずれかに記載の方法。
6. 前記１つ以上の属性は、以下：
   ｉ）前記ブロックチェーントランザクション（Tx）の中で提供される又は参照されるデータ部分、及び／又は、
   ｉｉ）前記ブロックチェーントランザクション（Tx）、
   に関連付けられたキーワード、タグ、又は識別子を含む、請求項５に記載の方法。
7. 前記ブロックチェーントランザクション（Tx）は、以下：
   論理的親トランザクション（LPTx）に関連付けられた親公開鍵（PPK）であって、前記論理的親トランザクション（LPTx）は、前記任意トランザクションID（DTxID）により識別される、論理的親トランザクション（LPTx）と、
   前記親公開鍵（PPK）を使用して生成された署名と、
   を含むインプットを更に含む、請求項１～６のいずれかに記載の方法。
8. 前記任意公開鍵（DPK）及び前記トランザクションID（TxID）を使用して、ブロックチェーンの中の前記ブロックチェーントランザクション（Tx）又は論理的親トランザクションを識別するステップ、を更に含む請求項１～７のいずれかに記載の方法。
9. 前記プロトコルフラグは、１つ以上のブロックチェーントランザクションの中のデータを検索し、格納し、及び／又は読み出す、ブロックチェーンに基づくプロトコルに関連付けられ及び／又はそれを示し、前記プロトコルは、基礎にあるブロックチェーンのプロトコル又は総意のルールを変更しないtier－２プロトコルである、請求項１～８のいずれかに記載の方法。
10. コンピュータにより実施される方法であって、
    任意公開鍵（DPK）及び任意トランザクションID（DTxID）をブロックチェーントランザクション（Tx）のアウトプットに関連付けるステップであって、
    前記ブロックチェーントランザクションは、第１ブロックチェーンプロトコルに従い前記ブロックチェーントランザクションが有効であるために要求されるトランザクションID（TxID）を含み、
    前記任意公開鍵及び前記任意トランザクションIDは、更なるプロトコルの部分であり、前記第１ブロックチェーンプロトコルにより要求されない、ステップと、
    前記任意トランザクションID及び前記任意公開鍵に基づき、前記ブロックチェーントランザクション（Tx）を検索するステップと、
    を含むコンピュータにより実施される方法。
11. 前記ブロックチェーントランザクション（Tx）の中で提供された又はそれから参照されるデータ部分にアクセスし又は処理するステップ、を更に含む請求項１０に記載のコンピュータにより実施される方法。
12. コンピュータにより実装されるシステムであって、
    プロセッサと、
    前記プロセッサによる実行の結果として、前記システムに請求項１～１１のいずれかに記載のコンピュータにより実施される方法を実行させる実行可能命令を含むメモリと、
    を含むシステム。
13. 実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、請求項１～１１のいずれかに記載の方法を実行させる、非一時的コンピュータ可読記憶媒体。

Images