JP7208164B2 - ブロックチェーン・ネットワークにおいてラージ・ブロックを管理するためのコンピュータ実装システム及び方法 - Google Patents

Description

本明細書は概してブロックチェーン・ネットワークのノードにおける実装に適したコンピュータ実装方法及びシステムに関する。多数のトランザクション及び大きなトランザクション・ブロックを扱うための修正されたブロックチェーン・ノード構造、ネットワーク・アーキテクチャ、及びプロトコルが説明される。本発明はビットコイン・ブロックチェーンに使用することに特に適しているがこれに限定されない。

本書では電子的なコンピュータ・ベースの分散型の全ての形態の台帳を含むように用語「ブロックチェーン」を使用する。これらは、ブロックチェーン及びトランザクション・チェーン技術、許可された及び許可されていない台帳、共有台帳、並びにそれらの変形を含むが、これらに限定されない。ブロックチェーン技術の最も広く知られている応用はビットコイン台帳であるが、他のブロックチェーン実装が提案され開発されている。本明細書では、便宜上及び説明の目的でビットコインが参照されるかもしれないが、本発明は、ビットコイン・ブロックチェーンで使用することに限定されず、代替的なブロックチェーンの実装及びプロトコルが、本発明の範囲内に属することに留意すべきである。

ブロックチェーンはコンセンサス・ベースの電子台帳であり、これはトランザクション及びその他の情報により構成されるブロックにより構成される、コンピュータ・ベースの非セントラル化された分散システムとして実装される。ビットコインの場合、各トランザクションは、ブロックチェーン・システムの参加者間のディジタル資産のコントロールの移動をエンコードするデータ構造であり、少なくとも１つの入力及び少なくとも１つの出力を含む。各ブロックは、共にチェーン化されるようになる先行するブロックのハッシュを含み、開始以来ブロックチェーンに書き込まれている全てのトランザクションについての永続的で変更不可能な記録を作成する。トランザクションは、トランザクションの入力及び出力に組み込まれるスクリプトと呼ばれる小さなプログラムを含み、スクリプトは、トランザクションの出力がどのように誰によってアクセスされ得るかを指定する。ビットコイン・プラットフォームでは、これらのスクリプトはスタック・ベースのスクリプト言語を使用して書かれる。

トランザクションがブロックチェーンに書き込まれるためには、それが「検証済み（ｖａｌｉｄａｔｅｄ）」でなければならない。幾つかのネットワーク・ノードは、マイナーとして振る舞い、各トランザクションが有効であることを保証するために作業を行い、無効なトランザクションはネットワークから拒否される。例えば、ノードにインストールされたソフトウェア・クライアントは、未使用残高（ｕｎｓｐｅｎｔ ｔｒａｎｓａｃｔｉｏｎ ｏｕｔｐｕｔ：ＵＴＸＯ）を参照するトランザクションに対してこの検証作業を実行する。検証は、そのロック及びアンロック・スクリプトを実行することによって実行されてもよい。ロック及びアンロック・スクリプトの実行がＴＲＵＥに評価され、特定の他の条件が満たされる場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれることができる。従ってトランザクションがブロックチェーンに書き込まれるためには、ｉ）トランザクションを受け取るノードによって検証され、トランザクションが有効である場合には、そのノードがそれをネットワーク内の他のノードへ中継すること；及びｉｉ）マイナーによって構築された新しいブロックに追加されること；及びｉｉｉ）採掘されること、即ち、過去のトランザクションの公の台帳に追加されることを要する。トランザクションを実質的に不可逆的にする程度に十分な数のブロックがブロックチェーンに追加されると、トランザクションは合意されたと考えられる。

ブロックチェーン技術は、暗号通貨の実装を利用することに最も広く知られているが、ディジタル起業家は、新しいシステムを実現するために、ビットコインが基礎としている暗号セキュリ・ティシステムと、ブロックチェーンに格納され得るデータとの双方を使用することを探求し始めている。ブロックチェーンが、暗号通貨での支払いに純粋に限定されない自動化されたタスク及びプロセスに使用され得るならば、非常に有利であろう。このようなソリューションは、ブロックチェーンの利点（例えば、イベントの恒久的な改ざん防止記録、分散処理など）を、それらの用途でいっそう多様化しつつ利用し得るであろう。

１つの研究分野は「スマート契約（ｓｍａｒｔ ｃｏｎｔｒａｃｔｓ）」の実装のためにブロックチェーンを利用することである。これらは、機械読み取り可能な契約又は合意の条件の履行を自動化するように設計されたコンピュータ・プログラムである。自然言語で書かれる伝統的な契約とは異なり、スマート契約は、結果を生成するために入力を処理することが可能であり、次いでそれらの結果に依存してアクションを実行させることが可能なルールを含む機械実行可能プログラムである。

ブロックチェーン関連の他の関心領域は、ブロックチェーンを介して現実世界のエンティティを表現及び転送するための「トークン」（又は「カラー・コイン」）を使用することである。潜在的にセンシティブな又は秘密のアイテムは、認識可能な意味又は値を持たないトークンによって表現されることが可能である。従って、トークンは、現実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。

ＵＳ２０１５／０２８７０２６は、ホット・ウォレット・サービス・システムを開示している。ホット・ウォレット・サービス・システムは、１つ以上のユーザ・デバイスから金融トランザクションを受信し、マルチ署名認証システムを実装する複数の認証サーバーを使用して金融トランザクションを認証し、ディジタル署名を集約し、認証された金融トランザクションを仮想通貨ネットワークに伝搬させる。金融トランザクションが仮想通貨ネットワークにより伝播されると、金融トランザクションは、通常の方法で仮想通貨ネットワークのマイナー・エンティティによって、公の共有台帳に組み込まれることが可能である。

ＣＮ１０６５４８３４９は、ブロックチェーン・ネットワーク内の全てのノードが全てのトランザクションのトランザクション情報を検証する必要がある場合、このプロセスはかなりのワークロードを生成し、ノードに多大な圧力をかけてしまう問題に関連している。ＣＮ１０６５４８３４９に記載されているソリューションは、全てのノードがトランザクション情報を検証しなければならないことを要求するのではなく、トランザクション情報を検証するために、第１のノードから複数の選択された第２ノードへトランザクション情報を伝搬することである。第２ノードはランダムで不規則な方法で選択され、悪意のある詐欺（ｆｒａｕｄ）の可能性を防止し、全てのノードがトランザクション情報を検証する必要もない。

ＷＯ２０１７／１６２９０４は、トランザクション遅延が削減され、リソースの二重送金が、リソース管理システムで新ブロックが確立される前にトランザクションを検証することにより軽減される、ブロックチェーン・ベースのリソース管理システムに関連している。少なくとも１つの検証ノードは、トランザクションを検証し、検証受諾メッセージをマーチャントに提供し、アイテムを顧客にリリースするために提供される。従って、ブロックチェーンの次のブロックが確立されるのを待たずに、売却を確実に完了させることができる。また、検証ノードは、検証ノードのセットに検証リクエストを配布し、検証ノードのセットからレスポンスを受信できることも開示されている。次いで、検証ノードは、検証ノードのセットからのレスポンスの何れもがトランザクションに対する拒否ではない場合であってその場合に限り、検証受諾メッセージをマーチャントに送信してよい。ブロックチェーン内でブロックを確立する時が到来した場合に、ブロックを確立するノードは、直近に確立されたブロック以降に行われた一連のトランザクションをコンパイルすることができ、次のブロックはこの一連のトランザクションを含むことが更に開示されている。

ＵＳ２０１６／０２５９９３７、ＷＯ２０１７／００４５２７、及びＷＯ２０１７／０１１６０１は、現在のビットコイン・ブロックチェーン・ネットワークがどのように構成され機能するかを説明している。特に、個々のトランザクションは、ネットワークを介して伝播され、マイニングによりブロックチェーンに組み込まれ、ここで、マイニング・ノードは、トランザクションのセットを選択し、トランザクションをプロトタイプ・ブロックにグループ化し、従来の「プルーフ・オブ・ワーク」方式でノンスの値を決定する。マイナーが有効なノンスを発見すると、そのブロックは他のノードによって検証され、ブロックチェーンに組み込まれる。

ＵＳ２０１５／０３１０４２４は、マルチ・モーダル暗号鍵アドレス・マッピングによってユーザ・ディレクトリ・データを生成するシステムを開示している。暗号通貨ネットワークは暗号ノードを備え、暗号通貨のユーザのトランザクションのセットを公に検証する。ノードは、トランザクションを中継し、検証台帳を維持し、及び／又は暗号通貨をマイニングすることによって、暗号通貨ネットワークに参加することができる。

本書執筆時点で、ビットコイン・ブロックチェーン・ネットワークは、約２０００トランザクションを含むブロック・サイズに基づいており、ブロックは約１０分ごとにマイニングされている（１０分のブロック時間は、最初の確認時間とチェーン・スプリットに費やされる時間との間の妥協として設定されている）。これは約３．５トランザクション／秒というトランザクション処理速度を提供する。対照的に、ＶＩＳＡシステムは、約１００００トランザクション／秒というトランザクション処理速度で動作し、５００００トランザクション／秒以上に到達し得る。

競争力のある決済システムを構築するためには、ブロックチェーン・ネットワークの現在の制約を何らかの方法で回避する必要があることは明らかである。１０分のブロック時間は十分に制定されているので、ブロック・サイズ、従ってブロックチェーン自体の変更を考慮することが必須である。本明細書では、例えば約５万トランザクション／秒を処理し得るスケーラブルなソリューションが説明される。重要なことに、非セントラルかされた分散されシステム・アーキテクチャを維持しながら、高いトランザクション速度をサポートし得るソリューションが提供される。

ビットコイン・ネットワークの現在のアーキテクチャから、大量の同時トランザクションが処理され得るものへの移行は、ネットワーク全体にインフラストラクチャ負担圧力をかける。多数のトランザクションをより効率的に、より高速に検証し中継することが可能なノードのシステムが提案されている。トランザクションの量に起因して、分散アプローチが、メモリプール（ｍｅｍｐｏｏｌ）（まだ処理されておらずブロックチェーンに保存されていない未処理トランザクション）の設計において提案される。大量に増加したトランザクションは、ブロック・サイズに圧力をかけ、ブロック・サイズが所定の制限を超えると、ストレージ・インフラストラクチャの問題が生じることになる。本明細書では、大きなギガバイト・サイズのブロックを処理及び格納する問題に対するソリューションが説明される。

本明細書は修正されたブロックチェーン・ネットワーク・アーキテクチャを記載しており、修正されたアーキテクチャは複数の専用トランザクション検証ノードを含み、そのノードは、トランザクションを検証し、ブロックチェーン・ネットワーク内の他のトランザクション検証ノードと共に、検証されたトランザクションを分散された非セントラル化されたストレージを維持するように構成される。トランザクション検証ノードは、更に、検証済みトランザクションのリストをマイナーのために準備し、検証済みトランザクションのリストをマイナーに提供する代わりに、ディジタル資産のためのコミットメント・トランザクションを作成するように構成される。従って、専用トランザクション検証ノードは、トランザクションを検証し、検証済みトランザクションのリストを構築し、及びこれらのリストを有償でマイナーに提供するという観点から、マイナーにサービスを提供する。トランザクションがマイニングされると、マイニングされたトランザクションはトランザクション検証ノードに戻され、トランザクション検証ノードは、マイニングされたトランザクションの大きなブロックを構築し、専用ストレージ・ノードに大きなブロックを格納する。

本発明の一態様はポスト・マイニング機能（ｐｏｓｔ－ｍｉｎｉｎｇ ｆｕｎｃｔｉｏｎａｌｉｔｙ）に関連する。ブロックチェーン・ネットワークのノードのためのコンピュータ実装方法が提供され、コンピュータ実装方法は：
複数の検証されたトランザクションに対応するブロックチェーン・ネットワークからマイニングされたデータを受信するステップ；
マイニングされたデータに基づいてブロックを組み立てるステップ；及び
組み立てられたブロックを、ブロックチェーンに格納するためにストレージ・エンティティへ送信するステップを含む。

このような方法は、マイナーが大きなブロックを構築して格納し、そのようなブロックをブロックチェーン・ネットワークで送信することを必要とせずに、ノードが、ストレージ・エンティティに格納される大きなブロックを構築することを可能にする。更に、このアーキテクチャは、まだ成長し続ける大きなブロックチェーンを格納する専用の大規模な格納エンティティの使用を可能にする。

コンピュータ実装方法は更に：
ブロックチェーン・ネットワークからトランザクションを受信するステップ；
ブロックチェーン・ネットワークから受信したトランザクションを検証するステップ；
ブロックチェーン・ネットワーク内の他のノードとともに、検証されたトランザクションの分散された非セントラル化されたストレージを維持するステップ；及び
検証されたトランザクションに対応するデータであって検証されたトランザクションのリストを含むデータを、マイニングのためにブロックチェーン・ネットワークへ分配するステップを含む。各々のリストは、ブロックへのマイニングのために検証されたトランザクションの完全なリストを提供することができる。

このような方法は、ブロックチェーン・ネットワーク内の他のノードとの検証済みトランザクションの分散された非セントラル化されたストレージを維持しつつ、検証機能を実行するマイナーの要件を効果的に除去する。更に、この方法は、トランザクション検証ノードが、検証されたトランザクションに対応するデータを準備し、マイニングのためにブロックチェーン・ネットワークに分配することにより、マイナーにサービスを提供することを可能にする。例えば、本方法は、検証されたトランザクションのリストが、準備され分配されることを可能にする。

ブロックチェーン・ネットワーク内の他のトランザクション検証ノードとの検証済みトランザクションの分散された非セントラル化されたストレージを維持するステップは、分散され非セントラル化された方法で検証済みトランザクションの最新リストを維持するために、ブロックチェーン・ネットワークのトランザクション検証ノードを同期化するステップを含んでもよい。例えば、検証ノードは、可逆ブルーム・フィルタ・ルックアップ・テーブル（ｉｎｖｅｒｔｉｂｌｅ ｂｌｏｏｍ ｆｉｌｔｅｒ ｌｏｏｋｕｐ ｔａｂｌｅｓ）を交換することによって同期させられることが可能である。検証されたトランザクションはまた、検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、ブロックチェーン・ネットワーク内のトランザクション検証ノードにわたって共通のオーダリング・システムが使用されるように、定義された順序でソートされることも可能である。例えば、正規のオーダリング・システムは、検証済みトランザクションの分散された非セントラル化されたストレージを維持するために使用されることが可能である。これは、ネットワークを横断するトランザクション・データが一貫した方法で維持されることを保証する一方、非セントラル化された分散されたストレージを保持する特に効率的な方法であることが発見された。

検証されたトランザクションに対応するデータを、マイニングのためにブロックチェーン・ネットワークに分配するステップは、検証されたトランザクションのリストに対応するデータ（可逆ブルーム・ルックアップ・テーブル及び検証されたトランザクションのリストに対応する任意の付随データであって、検証されたトランザクションがブロックに含まれているもの）を準備するステップを含むことが可能である。更に、検証されたトランザクションに対応するデータを、マイニングのためにブロックチェーン・ネットワークに配布するステップは、検証されたトランザクションのリストに対応するデータをマイナーに提供するのと引き換えに、ディジタル資産のコミットメント・トランザクションを作成するステップを含むことが可能である。例えば、ハッシュ（マークル）ツリー、パトリシア・ツリー、又は他のタイプのラディックス・ツリー（ｒａｄｉｘ ｔｒｅｅ）が、包含されるコミットメント・トランザクションとともに計算されることが可能である。

検証トランザクションに対応するデータが配布され、関連する暗号パズル、例えばハッシュ・パズルを解くことによってマイニングされた後、マイニングされたデータは、マイナーによってブロックチェーン上で直接的に格納されるのではなく、トランザクション検証ノードへ返送される。次に、このマイニングされたデータが、（大きな）ブロックに組み立てられ、大量のデータの格納のために特別に構成されたストレージ・エンティティに及び／又は分散されたストレージ・システムの何れかに格納されることが可能である。上述したように、これは、大きなブロックを構築及び格納し、そのようなブロックをブロックチェーン・ネットワークで送信することをマイナーに要求せずに、ストレージ・エンティティに格納される大きなブロックを、検証ノードが構築することを可能にする。更に、アーキテクチャは、常に成長し続ける大きなブロックチェーンを格納する専用の大規模ストレージ・エンティティの使用を可能にする。

ブロックチェーン・ネットワークから受信されるマイニングされたデータは、検証されたトランザクションに対応するブロック・ヘッダを含むことが可能である。マイニングされたデータはまた、採掘されたデータに基づいてブロックをアセンブル及び／又は記憶することに対するディジタル資産のトランザクションを含むことができる。更に、この方法は、ディジタル資産を受信する前に、最小ブロック数に関連付けられた期間ｔの間待機する条件を含むことが可能である。これは、プロバイダが、検証済みトランザクションのリストを（例えば、可逆ブルーム・ルックアップ・テーブルの形式で）マイニングのために提供すること、及び／又はマイニングされたブロックをブロックチェーン上で格納することに対して報いられるように、検証ノードを提供するためのインセンティブ・スキームを提供する。ディジタル資産を受け取る前に最低期間を必要とすることは、或る範囲のノードへスケルトン・ブロック（支払いを含む）を伝播させるようにマイナーにインセンティブを与え、ノードは他のノードへスケルトン・ブロックを伝播するようにインセンティブを受ける。

マイニングされたデータに基づいてブロックを組み立てるステップは、例えば、各ブロックが少なくとも２、４、６、８、１０、５０、１００、５００、１０００、又は１００００メガバイトのサイズを有する大きなブロックを組み立てるステップを含み得る。経時的に上限は増えるが、１ペタバイトという公称上限値が指定されてもよい。各ブロックは、例えば、少なくとも５０００、１００００、５００００、１０００００、５０００００又は１００００００トランザクションを含み得る。上限は時間の経時的に増えるが、１ブロック当たり１０^１２トランザクションという公称上限値が指定されてもよい。上述したように、本明細書に記載された方法、ノード、及びブロックチェーン・ネットワーク・アーキテクチャは、多数のトランザクションを構築及び記憶することをマイナーに要求せずに、ラージ・ブロックが構築され及びストレージ・エンティティに記憶されることを可能にする。これは、システムが大幅に引き上げられたトランザクション速度を処理できるようにする。

本明細書に記載される方法では、ブロックは、マイナーによって提供される乱数を含むブロック・ヘッダを含むように修正され得る。即ち、トランザクション検証ノードは、ブロックチェーン・ネットワークから解決されたトランザクションを受信する場合に、マイナーによって提供された乱数を含むブロック・ヘッダを含むブロックを処理するように構成されることが可能である。これは、ブロック・ヘッダに対する変更を構成し、それによって、マイナーはブロック・ヘッダに挿入される番号を選択したり、又はランダムに生成したりすることが可能である。これは、たとえ同じトランザクション・リストが多数のマイナーによって選ばれたとしても、マイナー達が同一のブロックを採掘しようと競わないことを保証する助けとなる。

データの上述のラージ・ブロックを記憶する記憶装置は、ブロックチェーン・ネットワーク上の複数のトランザクション検証ノード間で共用されることが可能であり、複数のトランザクション検証ノードは、ブロックチェーン・ネットワーク上でスーパー・ノードを形成し、共用される記憶装置は、共通のストレージ・ノード、分散されたストレージ、又はそれら２つの組み合わせの何れかである。このアーキテクチャは、ブロックチェーン・ネットワーク上のスーパー・ノードの形成を導出し、ブロックチェーンを記憶し、ブロックチェーン・ネットワークにサービスを提供する専用記憶装置の提供を可能にする。

上記に鑑み、ブロックチェーン・ネットワークのスーパー・ノードもまた提供され、スーパー・ノードは：
上述されたような複数の検証ノード；及び
ブロックチェーンを格納する共有されるストレージ・エンティティ；
を備え、共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又はそれら両者の組み合わせの何れかであり、及び
複数の検証ノードにより組み立てられたブロックは、共有されるストレージ・エンティティへ送信され格納され、それにより共有されるストレージ・エンティティはブロックチェーンを維持する。

このアーキテクチャは、本明細書に記載される方法及び構成の目的であるトランザクション・レートの所望の増加を達成するために必要とされる大きなブロック・サイズを処理することにいっそう適している。例えば、共有されるストレージ・エンティティは、少なくとも１００ギガバイトのストレージ容量、より好ましくは少なくとも１、１０、１００、又は１０００テラバイトのストレージ容量を有するように構成され得る。上限は経時的に増加するが、１０^６テラバイト、場合によっては１０^６ヨタバイトという公称上限値が指定され得る。

全体的なネットワーク・アーキテクチャに関し、複数のこのようなスーパー・ノードを含むブロックチェーン・ネットワークが提供され得る。スーパー・ノードは、ブロックチェーン・ネットワークで接続されることが可能であり（ただし、重複しない）、各スーパー・ノードの共有されるストレージ・エンティティは、ブロックチェーンのコピーを格納するように設定される。スーパー・ノードは、スーパー・ノードとして機能するプールを形成するノードのグループを効果的に含む。ブロックチェーンの分散された性質を維持するためには、有利なことに、一定数の（例えば、少なくとも１０、５０、１００、又は１０００であり、選択的に１００，０００，０００未満の）そのようなスーパー・ノードが存在すべきである。

本発明の実施形態は、様々な形態で提供され得る。例えば、実行されると本明細書に記載されている方法を実行するようにプロセッサを構築するコンピュータ実行可能命令を含むコンピュータ読み取り可能な記憶媒体が提供され得る。電子デバイスはまた：インターフェース；インターフェースに結合される１つ以上のプロセッサ；及び１つ以上のプロセッサに結合されるメモリを有するように提供されることが可能であり、メモリは、実行されると、本願で説明されている方法を１つ以上のプロセッサに実行させるコンピュータ実行可能命令を保存している。更に、ブロックチェーン・ネットワークの検証トランザクション・ノードが提供されることが可能であり、検証トランザクション・ノードは、本明細書で説明される方法を実行するように構成される。

本明細書で説明される発明は、以下説明されるように、背景技術のセクションで議論される先行技術とは異なる。

ＵＳ２０１５／０２８７０２６は、いったん仮想通貨ネットワークを介して金融トランザクションが伝播されると、その金融トランザクションは、標準的な方法で仮想通貨ネットワークのマイナー・エンティティによって、公の共有台帳に組み込まれ得ることを開示している。従って、ＵＳ２０１５／０２８７０２６は、特殊なストレージ・ノードを使用してブロックチェーン上で保存するために、マイナーに代わって、採掘されたトランザクションの大きなブロックを収集及び構築するノードを開示していない。更に、ＵＳ２０１５／０２８７０２６は、採掘されたデータが、採掘されたデータに基づいてブロックを組み立て、及び／又は組み立てられたブロックを記憶することの対価として、ディジタル資産のトランザクションを含むことを開示していない。

同様に、ＣＮ１０６５４８３４９、ＷＯ２０１７／１６２９０４、ＵＳ２０１６／０２５９９３７、ＷＯ２０１７／００４５２７、ＷＯ２０１７／０１１６０１、及びＵＳ２０１５／０３１０４２４は、特殊なストレージ・ノードを使用してブロックチェーン上で保存するために、マイナーに代わって、採掘れたトランザクションの大きなブロックを収集及び構築するノードを開示していない。更に、これらの文献は、採掘されたデータに基づいてブロックを組み立て、及び／又は組み立てられたブロックを保存することと引き換えに、採掘されたデータがディジタル資産のトランザクションを含むことを開示していない。むしろ、文献は、現在のブロックチェーン・ネットワーク・アーキテクチャを使用する標準的なマイニング手順を開示しており、マイニング・ノードが一組のトランザクションを選択し、そのトランザクションをプロトタイプ・ブロックにグループ化し、従来の「プルーフ・オブ・ワーク」方式でノンスの値を決定し、そしていったんマイナーが有効なノンスを発見すると、そのブロックは他のノードによって検証され、ブロックチェーンに組み込まれる。

上記に鑑みて、本発明はブロックチェーン・ネットワーク内で大きなギガバイト・サイズのブロックをより効率的に処理及び格納するためのユニークなアーキテクチャ及び方法を提供するものと確信する。

本発明のこれら及び他の態様は、本明細書に記載される実施形態から明らかであり、それを参照して解明される。本発明の実施形態は、単なる例示として、添付図面を参照して説明される。
図１はブロックの全体構造を示す。 図２は、ユーザがトランザクションをサブミットした時点からブロックチェーン上で終了するまでのステップを示す動作図によるビットコイン・ネットワークの修正されたアーキテクチャを示す。 図３は、確認のためにメモリプールで待機しているトランザクションの合計サイズの一例を示すグラフを示す。 図４は、内的にセントラル化されたストレージ施設にリンクされた複数のノードを示す。 図５は、各ノードが、分散されたメモリプール及び分散されたストレージ施設双方の一部分である構成を示す。 図６は、新しいノード構造がビットコイン・ネットワークにどのように適合するかを示し、検証ノードがストレージ・プールのメンバーであり、プールが一緒に非セントラル化され分散されたビットコイン・ネットワークを構成するネットワーク構成を示す。 図７は新しいノードの機能を示す。 図８は、現在のプロトコルに対する修正を為す新しいマークル・ツリー構造を示す。 図９はブルーム・フィルタを作成するワークフローを示す。 図１０は、トランザクションが、可逆ブルーム・フィルタ（ＩＢＦ）及び可逆ブルーム・ルックアップ・テーブル（ＩＢＬＴ）でどのようにエンコードされるから示すワークフローを示す。

本明細書では、大きなギガバイト・サイズのブロックを処理して格納する問題に対するソリューションが説明される。

ブロックチェーン・ネットワーク・ノード及び検証ノードのタイプ
ブロックチェーン・ネットワークは、招待無しに及び他のメンバーからの同意も無しに、誰でも参加してよいピア・ツー・ピア・オープン・メンバーシップ・ネットワークとして説明されてよい。ブロックチェーン・ネットワークが動作するブロックチェーン・プロトコルのインスタンスを実行する分散された電子デバイスは、ブロックチェーン・ネットワークに参加することができる。このような分散電子デバイスは、ノードと称されることが可能である。ブロックチェーン・プロトコルは、例えば、ビットコイン・プロトコル又は他の暗号通貨であってもよい。

ブロックチェーン・プロトコルを実行し、ブロックチェーン・ネットワークのノードを形成する電子デバイスは、例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、サーバー、コンピュータ・ファームなどのコンピュータ、スマートフォンなどのモバイル・デバイス、スマート・ウォッチなどのウェアラブル・コンピュータ、又は他の電子デバイスなどの様々なタイプのものであってもよい。

ブロックチェーン・ネットワークのノードは、有線及び無線通信技術を含み得る適切な通信技術を使用して互いに結合される。多くの場合、ブロックチェーン・ネットワークは、少なくとも部分的にインターネットを介して実装され、ノードの幾つかは、地理的に分散した場所に配置され得る。

現在、ノードは複数のブロックにグループ化されるブロックチェーン上の全てのトランザクションのグローバルな台帳を維持し、各ブロックはチェーン内で先行するブロックのハッシュを含む。グローバル台帳は、分散した台帳であり、各ノードは、グローバル台帳の完全なコピー又は一部のコピーを保存することができる。グローバル台帳に影響を与えるノードによるトランザクションは、他のノードによって検証され、グローバル台帳の有効性が維持される。ビットコイン・プロトコルを使用するもののようなブロックチェーン・ネットワークの実装及び動作の詳細は、当業者に理解されるであろう。

各トランザクションは、典型的には、１つ以上のインプット及び１つ以上のアウトプットを有する。インプット及びアウトプットに埋め込まれたスクリプトは、トランザクションのアウトプットがどのように誰によってアクセスされ得るかを指定する。トランザクションのアウトプットは、トランザクションの結果として値が転送される先のアドレスであってもよい。この値は、未使用残高（ＵＴＸＯ）として、そのアウトプット・アドレスに関連付けられる。その後、後続のトランザクションは、その値を消費又は分散するために、インプットとしてそのアドレスを参照することができる。

ノードは、それらの機能に応じて、異なるタイプ又はカテゴリのものであり得る。ノードに関連する４つの基本的な機能：ウォレット、マイニング、フル・ブロックチェーン・メンテナンス、及びネットワーク・ルーティングが存在することが示唆されている。これの機能についてのバリエーションが存在し得る。ノードは１つより多い機能を有していてもよい。例えば、「フル・ノード」は４つ全ての機能を提示する。ライトウェイト・ノードは、例えば、ディジタル・ウォレットに実装されてもよく、またウォレット及びネットワーク・ルーティング機能のみを発揮してもよい。ディジタル・ウォレットは、ブロックチェーン全体を格納するのではなく、ブロックを照会する場合にインデックスとして役立つブロック・ヘッダを追跡することができる。ノードは、ＴＣＰ／ＩＰ（伝送制御プロトコル）等のコネクション指向プロトコルを用いて互いに通信する。

ノードの追加のタイプ又はカテゴリが提供されてもよい：マーチャント・ノード（ａ ｍｅｒｃｈａｎｔ ｎｏｄｅ）（本明細書では、しばしば「Ｍ－Ｎｏｄｅ」と呼ばれる）。Ｍ－Ｎｏｄｅは、トランザクションの高速伝搬に焦点を当てるように設計されている。それらは、完全なブロックチェーンを記憶しても記憶しなくてもよく、マイニング機能を実行しない。その意味で、それらはライトウェイト・ノード又はウォレットに類似しているが；トランザクションの高速伝播を可能にする追加の機能を含んでいる。Ｍ－Ｎｏｄｅの運用上の焦点は、未確認トランザクションの迅速な検証と伝播、特に他のＭ－Ｎｏｄｅへの伝播であり、当該他のＭ－Ｎｏｄｅから、未確認トランザクションはブロックチェーン・ネットワークの他のノードへ迅速にプッシュされる。この機能を容易にするために、Ｍ－Ｎｏｄｅには、管理プロトコルの下でノードに対して許可される可能性のある、進入する及び特に進出する多数のコネクションが許可される。

Ｍ－Ｎｏｄｅは、マーチャント・ネットワーク（又は「Ｍ－ｎｅｔ」）と総称されてもよい。「マーチャント」という用語は「専門的な（ｓｐｅｃｉａｌｉｓｅｄ）」という意味として解釈されてもよい。Ｍ－Ｎｏｄｅはブロックチェーン・ネットワークに統合されてもよい。各々のＭ－Ｎｏｄｅは、ブロックチェーン・ネットワークにおける特殊なノードであり、Ｍ－Ｎｏｄｅの機能を実行できることを保証する特定のハードウェア及びパフォーマンス能力を満たす。即ち、Ｍ－ｎｅｔはブロックチェーン・ネットワーク内のサブ・ネットワークと考えられ、ブロックチェーン・ネットワークを通じて分散され得る。Ｍ－Ｎｏｄｅは、一つ以上の専用の機能又はサービスを実行するように配置され及び構成されてもよい。

Ｍ－ｎｅｔが確実に動作し、所定のセキュリティ・レベルでサービスを提供できるようにするためには、Ｍ－ｎｏｄｅはＭ－ｎｅｔ全体の良好な概観を維持する必要があり、従って効率的なルーティング・プロトコルが整っている必要がある。Ｍ－ｎｏｄｅが開始トランザクションを受信するたびに、他のノードに加えて、幾つかの他のＭ－ｎｏｄｅへそれをブロードキャストする必要がある。Ｍ－ｎｅｔの状況では、これは複数巡回セールスマン問題（ＭＴＳＰ）の解を見つけることになる。この問題に取り組む解決策は多数存在し、そのうちの１つがＭ－ｎｅｔで使用されてもよい。Ｍ－ｎｏｄｅの各々は何らかの最新の形式でルーティングの最適化を実行する。

幾つかの実装では、Ｍ－ｎｅｔは非セントラル化されたＩＰマルチキャスト・タイプのネットワークとして実装される。即ち、ブロックチェーン・ネットワークへの到来するトランザクションの高速な拡散を可能にするために、マルチキャストが使用されてもよく、トランザクションがＭ－ｎｅｔを通じて迅速にブロードキャストされることを保証し、次いで全てのＭ－ノードが、ブロックチェーン・ネットワーク内の他のノードへトランザクションを転送することに焦点を合わせることを可能にする。

マルチキャスト・ネットワーク・アーキテクチャは、情報を受け取ることに関心のある各ノードに対するデータの重複なしに、宛先ノードのグループへのデータの同時分配の可能性を許容する。ノードがマルチキャスト送信を受信することを希望する場合、マルチキャスト・グループに参加し（登録段階）、その後、マルチキャスト・グループ上で送信された全てのデータを受信することができるであろう。ＩＰマルチキャストは、何台の受信機が存在するかについての事前知識を必要とセズに、より大きな受信者集団に拡大することが可能であり、ネットワーク・インフラストラクチャは、１回だけパケットを送信することをソースに要求することによって、効率的に使用される。マルチキャスト・ネットワークの性質のために、（ＴＣＰのような）コネクション指向プロトコルの使用は、多数の他のノードとの同時通信に起因して実用的ではない。従って、コネクションレス・プロトコルが使用される。

ビットコイン等の幾つかのブロックチェーン・ネットワークは、ノード・ツー・ノード通信にＴＣＰを使用する。ＴＣＰを使用して送信されるデータ・パケットは、順序付けのために使用される関連シーケンス番号を有する。これに加えて、ＴＣＰプロトコルは、コネクションを確立する時と終了する時の両方で、３方向ハンドシェイク手順を含む。ＴＣＰ上で送信されるパケットは、関連するオーバーヘッドと共に到来し、それらは関連するシーケンス番号を有し、３方向ハンドシェイク・プロトコルがある。コネクションを確立するには、１２８～１３６バイトが送信され、コネクションを閉じるには１６０バイトのコストがかかる。従って、パケット伝送におけるハンドシェイクは、高々２９６バイトのコストがかかる。更に、ノードが新しいトランザクションを受信すると、他のノードに、トランザクションのハッシュを含むインベントリ（ＩＮＶ）メッセージを通知する。ＩＮＶメッセージを受信するノードは、そのトランザクションのハッシュが以前に発見されているか否かを検査する：発見されていない場合、ノードはＧＥＴＤＡＴＡメッセージを送信することによってトランザクションを要求する。ノードＡからノードＢへトランザクションを送信するために必要な時間は、
Ｔ１＝ｖｅｒｉｆｉｃａｔｉｏｎ＋ＴＣＰ（ｉｎｖ＋ｇｅｔｄａｔａ＋ｔｘ）
であり、ＴＣＰ（）は、ＴＣＰハンドシェイク手順によって導入されるオーバーヘッドを時間の観点から示す。

Ｍ－ｎｏｄｅは、ビットコインのように、既存のプロトコルによって強制される他ノードとの通信のためにＴＣＰを使用するように設定されてもよい。しかしながら、それらは、Ｍ－ｎｏｄｅからＭ－ｎｏｄｅへの通信、あるいは、より適切には、マルチキャスト状況においてＭ－ｎｏｄｅから複数のＭ－ｎｏｄｅへの通信のために、ユーザ・データグラム・プロトコル（ＵＤＰ）等のコネクションレス・プロトコルを使用してもよい。ＴＣＰとは異なり、ＵＤＰはハンドシェイク・プロトコルを含まないので、Ｍ－ｎｏｄｅはより速やかにトランザクションを伝播することができる。これは、実際のトランザクションを送信することなく繰り返されるＩＮＶメッセージを送信することによって、悪意のノードが他ノードと結びつくことを回避することも可能である。

ＵＤＰのライトウェイトの性質は或る種のトレードオフに関連する。誤り検査が少なく、誤り復元も行われない。幾つかの実装では、これらのＵＤＰの制限は、アプリケーション・レイヤの機能として、誤り復元、順序付け、及び再送を実装することによって、アプリケーション・レベルで克服されることが可能である。アプリケーション・レベルで誤り検査を行うことは、ネットワークからオーバーヘッドを排除する。

一例では、ブロックチェーン・ネットワーク上の通常のノードは、マーチャント・ベースの支払いのような、Ｍ－ｎｅｔを介して処理されることを望むトランザクションを生成する。それはトランザクションをＭ－ｎｏｄｅへ送信することができ、Ｍ－ｎｏｄｅは次いでマルチキャストを使用してそれを他のＭ－ｎｏｄｅへブロードキャストしてもよいし、或いはＭ－ｎｏｄｅのＩＰマルチキャスト・アドレスを知っている場合には、トランザクションを複数のＭ－ｎｏｄｅへ直接的に送信してもよい。幾つかの例では、Ｍ－ｎｅｔのすべてのＭ－ｎｏｄｅは単一のマルチキャスト・アドレスのメンバーであり、従って、そのアドレスに送信される全てのトランザクションは、全てのＭ－ｎｏｄｅによって受信される；しかしながら、場合によっては、Ｍ－ｎｅｔに関連する１つより多いマルチキャスト・アドレスが存在してもよく、受信Ｍ－ｎｏｄｅは、トランザクションを完全なＭ－ｎｅｔへ伝搬するために、トランザクションの他のマルチキャスト・アドレスへの更なるブロードキャストが必要か否かをルーティング情報から評価してもよい。

マルチキャストは、全てのＭ－ｎｏｄｅへの新しいトランザクションの高速な初期伝播を確実にすることを支援する；しかしながら、マルチキャスト・ソリューションは、トランザクション・スループットの増加に起因するブロックチェーン・ネットワークのスケーラビリティ問題に必ずしも取り組んでいない。ネットワークの各ノードは、典型的には、発見されて確認されていないトランザクションを含むメモリプールであって、プルーフ・オブ・ワークを完了するマイナーによって未だブロックチェーンに組み込まれていないメモリプールを維持する。支払処理での使用から生じるトランザクション数の著しい増加は、各メモリプールに格納するトランザクション量を増やす。従って、Ｍ－ｎｅｔ中のノードは、ほぼ同時に新しいトランザクションを受信することができるが、それらは、大きく且つ急速に変化するメモリプールに関して、記憶能力の制限を有し得る。

この問題に対処するために、Ｍ－ｎｏｄｅは、マルチキャストを使用する代替例として、分散ハッシュ・テーブル（ＤＨＴ）によって実装される共有メモリを使用することができる。

５００バイトというトランザクション（ＴＸ）の平均サイズ、～１０^４ＴＸ／ｓという伝送レートを仮定すると、Ｍ－ｎｅｔは、毎日約４００ＧＢの入力データを受信し得る。このデータは全て、未確認トランザクションのメモリプールの中でさまざまな期間にわたって格納されることを要する。従って、Ｍ－ｎｅｔは、データを高速に記憶するために、かなりのストレージ及び能力を必要とする。個々のＭ－ｎｏｄｅそれぞれに過剰に多くの要求を課さないために、Ｍ－ｎｏｄｅはＤＨＴを当てにする共有メモリを実装する。各Ｍ－ｎｏｄｅが全ての到来するＴＸを自身のメモリプールに保持する代わりに、各Ｍ－ｎｏｄｅは全体のうちの特定の部分と、残りの部分のハッシュ及び関連するキー値とを保持するのみである。

ＤＨＴは非セントラル化された分散システムのクラスであり、ノード間のキー・セットのメンバシップ分割を可能にし、所与のキーの所有者に対してのみ効率的かつ最適化された方法でメッセージを送信することができる。ネットワークの各ノードはハッシュ・テーブルのアレイのセルとして見ることが可能である。ＤＨＴは、多数のノードを管理するために設計され、新しいノードがネットワークに参加し、古いノードが離脱及びクラッシュする可能性を、共有データの完全性を損なうことなく許容する。ＤＨＴは、非セントラル化（中央の権限も中央による調整もない）、スケーラビリティ（システムは何百万ものノードで効率的な動作をする）、及びフォールト・トレランス（システムは信頼性があり、ネットワークに参加、離脱又はクラッシュするノードを管理することができる）を保証する。ネットワークの各ノードは、少数の他ノードとのみ接触し続けることができ、従って、変化があった際又は新しいデータの存在下において、ネットワークはオーバーロードにならない。

同じ概念は、ＵＴＸＯデータベース、即ちブロックチェーン上のすべての未使用アウトプット力のセットを含むデータベースに適用され得る。ＵＴＸＯデータベースは、一群のノードの間で内容を共有するために、ＤＨＴを使用して構築され得る。

Ｍ－ｎｅｔのための共有メモリを実装するために使用され得る多くの可能なＤＨＴアーキテクチャ及びプロトコルがある。一例はＰａｓｔｒｙ（商標）であるが、他にも多くの例がある。Ｐａｓｔｒｙ（商標）は、分散システムで情報を格納して転送することが可能なオーバレイ・ネットワークを維持するために設計されたプロトコルである。Ｐａｓｔｒｙ（商標）ネットワークの各ノードには、１２８ビットの識別子が割り当てられ、識別子は（０から２^１２８－１に及ぶ）巡回ノードＩＤ空間内のノードの位置を示すために使用される。ＩＤは、ノードがネットワークに参加する場合にランダムに指定される。各ノードは、ルーティング・テーブル、隣接セット（ａ ｎｅｉｇｈｂｏｕｒｈｏｏｄ ｓｅｔ）、及びリーフ・セット（ａ ｌｅａｆ ｓｅｔ）を維持する。

ロバストなＤＨＴの寸法決定において考慮すべき１つの要因は、ネットワーク全体のロバスト性と信頼性とを保証するために必要なレプリカの数である。既に述べたように、ノードはネットワークに参加したり立ち去ることが可能であり、このことはデータの利用可能性に影響を与えるべきでない。トランザクションＡを格納するノードがネットワークを離れる場合、ネットワークの別の部分でトランザクションＡを発見する必要がある。例えばビットコインのような既存のブロックチェーン・ネットワークでは、ネットワークは、ネットワーク内の全ノード数（平均５０００レプリカ）に等しい数のブロックチェーン・レプリカを有しているが、このことはスケーラビリティに影響する。

１つのＭ－ｎｅｔ構成では、メモリプールは、全てのＭ－ｎｏｄｅで完全に複製されるわけではなく、代わりにＤＨＴによって実現される。信頼性を提供するために、ＤＨＴは、幾つかのオーバーラップを有するように実装されてもよく；即ち、各トランザクション・データ・アイテムは、１つより多いＭ－ｎｏｄｅで複製されるが、全てのＭ－ｎｏｄｅにおいてではない。例として、ＤＨＴは、２つのレプリカという最小数を指定するように実装され得る。これは、２つのノードが任意の所与の１時間に一度に落ちる確率をもたらし、これは、次のようなノード間の完全な独立性を仮定している。

従って、分散されたメモリプールに新しいトランザクションを格納するためのプロセスは、以下のステップを含み、ここで分散されたメモリプールはＤＨＴを用いて実装される。プロセスは、ノードがＭ－ｎｏｄｅへトランザクションを送信することを含む。Ｍ－ｎｏｄｅは、キー値を取得するために、実装に応じてトランザクション又はトランザクションＩＤをハッシュする。キー値は、トランザクションが格納されるべきＭ－ｎｏｄｅ又は複数のＭ－ｎｏｄｅ（複製されたデータの場合）を指定する。次に、Ｍ－ｎｏｄｅはトランザクションを分散されたメモリプールに格納し、このプロセスは、Ｍ－ｎｅｔ内のＭ－ｎｏｄｅのキー値及び割り当てられたＩＤに基づいて、トランザクションが格納されるべき正しいＭ－ノードへトランザクションをルーティングすることを含んでもよい。Ｍ－ｎｏｄｅは、関与するＤＨＴプロトコルに応じて、確認応答を受信してもよい。Ｍ－ｎｏｄｅが正規のノードから新しいトランザクションを受信すると、Ｍ－ｎｏｄｅはトランザクションの真正を検証するために所定の検証オペレーションを実行することができる。

トランザクションは、トランザクションのキーを生成するためにハッシュされるかもしれない。キーは、現在のＭ－ｎｏｄｅ以外のノードにあるかもしれない、ＤＨＴ内のどこにトランザクションが格納されるべきかを示すことができる。Ｍ－ｎｏｄｅは、次いでトランザクションが既に動作中のＤＨＴにあるか否かを評価する。各Ｍ－ｎｏｄｅは、Ｍ－ｎｅｔを構成するＭ－ｎｏｄｅ間の鍵空間の分割に基づいて、格納されたトランザクションの一部を有する。幾つかの構成では、鍵空間は参加しているＭ－ｎｏｄｅ間で分割される。この分割は、ネットワークの弾力性（ｒｅｓｉｌｉｅｎｃｙ）のための複製を引き起こすように、オーバーラップを含んでもよい。Ｐａｓｔｒｙ（商標）を使用するような幾つかの実装では、各々のＭ－ｎｏｄｅは固有のキー又はＩＤ番号の割り当てを受け、トランザクションは、トランザクションのキー値に対する近接性に基づいて、Ｍ－ｎｏｄｅ又は複数のＭ－ｎｏｄｅ（複製が望まれる場合）に格納されてもよい。Ｍ－ｎｏｄｅは、ローカルにトランザクションの格納された部分と、残りの部分のハッシュ値又はキー値とを有し得る。従って、Ｍ－ｎｏｄｅは、動作中のローカル・データに基づいて、新しいトランザクションがＤＨＴ内にあるか否かを評価することができる。

トランザクションがＤＨＴ内にない場合、Ｍ－ｎｏｄｅは、動作中に、そのキー値に基づいて、トランザクションをＤＨＴに格納する。一般的な意味においてこれは、ｐｕｔ（ｋ，ｔｘ）オペレーションの形式をとることが可能であり、ｋはキー値であり、ｔｘはトランザクションである。適用可能なＤＨＴルーティング・プロトコルは、トランザクションが適切なＭ－ｎｏｄｅへ送信され、そこで保存されることを保証する。ＤＨＴは、選択される実装に依存して、分散されたハッシュ・テーブルに関する種々のプロトコルに従って機能することができる。Ｍ－ｎｅｔにトランザクションを格納するためのＤＨＴの使用は、全てのＭ－ｎｏｄｅにトランザクションをルーティングするために、Ｍ－ｎｅｔ内でＩＮＶ／ＧＥＴＤＡＴＡメッセージを使用することを回避する。

動作中に、Ｍ－ｎｏｄｅはこの例では、ブロックチェーン・ネットワークの通常のトランザクション転送プロトコルに従って、ブロックチェーン・ネットワーク内の正規のノードへトランザクションを送信することができる。例えば、通常のノードへの通信は、ノード・ツー・ノード接続のためにＴＣＰを使用してもよい。

ある構成では、Ｍ－ｎｏｄｅは、プロセッサ、ネットワーク・インターフェース、及びメモリを含む。Ｍ－ｎｏｄｅは任意の適切なコンピューティング・ハードウェアを使用して実現されることが可能であり、そのコンピューティング・ハードウェアは、ネットワーク接続性を有し、本明細書に記載の機能を実行するのに十分な処理及びメモリ・リソースを有する。Ｍ－ｎｏｄｅは、本明細書に記載の機能を実装するためのプロセッサ実行可能命令を含んでもよい。幾つかのケースにおいて、プロセッサ実行可能命令はブロックチェーン・マーチャント・ノード・アプリケーションと呼ばれてもよいが、この命令は、ハードウェア及びオペレーティング・システムに応じて、１つ以上のモジュール、アプリケーション、スクリプト、又は他のプログラミング構造で実装され得ることが理解されるであろう。プロセッサはマルチ・コア・プロセッサ及び／又は複数のプロセッサを含んでもよい。

メモリは、部分的には、そのＤＨＴキー値、即ちＭ－ｎｏｄｅＩＤに基づいて、ＤＨＴベースのメモリプールの割り当てられた部分を含むデータを格納する。この実装例では、メモリはルーティング・テーブル、近隣セット、及びリーフ・セットを更に格納する。ルーティング・テーブルは、Ｍ－ｎｅｔ内の特定のルーティング宛先のリストを含み、ノードがデータのパケットを受信すると、そのデータを送信する場所を知るためにルーティング・テーブルを参照する。また、ルーティング・テーブルは、各宛先がＭ－ｎｏｄｅからどれだけ離れているかについての情報を含んでもよい。近隣セットは、例えば近接メトリック（例えば、ピンの待ち時間（ｐｉｎｇ ｌａｔｅｎｃｙ））に基づいて、近接Ｍ－ｎｏｄｅに関する情報を含む。リーフ・セットは、数値的に近いＭ－ｎｏｄｅを含む。複数のＭ－ｎｏｄｅは、それらのキー値（ノードＩＤ）が数値的に近い場合、数値的に近い。メモリは、以下で更に説明されるように、Ｍ－ｎｏｄｅレピュテーション・テーブル（ａｎ Ｍ－ｎｏｄｅ ｒｅｐｕｔａｔｉｏｎ ｔａｂｌｅ）を更に含む。

スケーラビリティを提供するために、ＤＨＴを使用してメモリプールを実装することに加えて、Ｍ－ｎｅｔは、ノードがＭ－ｎｅｔに参加することを許容する。新しいノードはＭ－ｎｅｔの既に存在する部分の少なくとも１つのＭ－ｎｏｄｅのアドレスを有する必要があり、そのため、Ｍ－ｎｏｄｅの１つへ参加リクエストを差し向けることができる。Ｍ－ｎｏｄｅは、新しいノードを照会することを含み得る所定の検証アクションを実行することができる。例えば、Ｍ－ｎｅｔは、Ｍ－ｎｅｔがＭ－ｎｏｄｅに対して指定する、Ｍ－ｎｅｔに参加することに関連する一組の最小限の基準を有していてもよい。例示として、基準は、利用可能な最小限の処理リソース、利用可能な最小限の空きメモリ、又は接続要件を含むことができる。

新しいノードを検証するために検証オペレーションが実行されるものが何であれ、Ｍ－ｎｏｄｅが完了したと仮定すると、ＤＨＴプロトコルがＤＨＴのオペレーションを支配するものが何であれそれに従って、Ｊｏｉｎｒｅｑｕｅｓｔ（）をＤＨＴへ転送する。次に、ＤＨＴは、新しいノードと通信し、ルーティング・テーブル、キー値（ノードＩＤ）、及び任意の他のデータを提供し、新たなノードがＭ－ｎｅｔ上の新しいＭ－ｎｏｄｅとして機能することを可能にする。

ノードがＭ－ｎｅｔに参加し得ることの容易性は、悪意のノードがネットワークに参加し得るという脆弱性を生み出すことが理解されるであろう。潜在的な悪意のノードを識別して隔離するために、１つの構成は、ノードの挙動ランキングを追跡及び更新するために使用されるＭ－ｎｏｄｅ評判テーブルを格納するＭ－ｎｏｄｅを提供する。新しいノードがネットワークに参加すると、ノードＩＤフィールドによって示されるようにして、そのノードはＭ－ｎｏｄｅ評判テーブルに追加され得る。テーブルは、幾つかの実装において、参加時間を更に含んでもよい。テーブルはそのＭ－ｎｏｄｅに関するスコア及び格付けを含む。

スコアは、特定の行動メトリックに基づいて上下に調整され得る。例えば、Ｍ－ｎｏｄｅがトランザクションを転送することに失敗したり、一定期間にわたってサイレントのままであったり、トランザクションではないと判断されたトラフィックでＭ－ｎｅｔを溢れさせたり、あるいは、否定的な振る舞いに関わっている場合、そのランキングは、落とされたり又は減少させられたりする。ノードのスコアがあらかじめ設定された最小値を下回る場合、ノードはＭ－ｎｅｔから除外されるかもしれない。

特定のＭ－ｎｏｄｅで維持されるＭ－ｎｏｄｅ評判テーブルは、完全なＭ－ｎｅｔではなく、その近隣のスコアを追跡することに限定されてもよい。従って、新しいＭ－ｎｏｄｅが時刻ｔでネットワークに参加する場合、その近隣のＭ－ｎｏｄｅ評判テーブルは、新しいノードについての情報を含んでおらず、その時点ｔから、それらは、ノード・レジスタ・テーブルに情報を格納する新しいノードの評判を構築し始める。例えば、新しいノードがサイレント・ノードである場合、それはネットワーク上で受け取る情報を転送しないことを意味し、全ての隣接者は、例えば新しいノードのＩＤに負の値を割り当てるなど、各自それぞれのＭ－ｎｏｄｅ評判テーブルにこの挙動を記録し始める。ある時間ｔ＋ｎの後、新しいノードに気付いている全てのノードのＭ－ｎｏｄｅ評価テーブルが負の値を含んでいる場合、ノードは新しいノードを分離し、それをネットワークから禁止することを決定し得る。

Ｍ－ｎｅｔの分散されたメモリプール内のトランザクションは、確認される前、即ちブロックチェーンに追加され確認されるブロックに組み込まれる前に、かなりの時間待つかもしれない。ブロックはそれより上のブロックチェーンに十分な数の後続のブロックが追加された場合に「確認された」とみなされ、その結果、異なる枝又はフォークに変化するようにチェーンの成長を逆転させ及びブロックを除去することは計算上不可能であるようになる。

メモリプールのサイズと柔軟性とトランザクションの量とに起因して、ビットコインのような或るブロックチェーン実装よりも長い間、所与のトランザクションが確認されない可能性がある。従来のビットコイン実装では、トランザクションは、それがブロックに組み込まれるとすぐに、メモリプールから取り除かれる。これは、ブロックが、オーファン・ブロック（親ブロックの無いブロック）となった場合に、ブロック内の全てのトランザクションがネットワーク上で再送されることを意味する。これは、非現実的であるかもしれず、また、高速トランザクション・ネットワークの場合、特定のトランザクションを確認するために長い遅延を生じるかもしれない。

従って、幾つかの実装において、メモリプールは、トランザクションが組み込まれているブロックのコンファメーション数、即ちトランザクションが組み込まれたブロックに続くブロックチェーンに追加されたブロック数を追跡することができる。あらかじめ決められた数のコンファメーションが行われた後にのみ、トランザクションはメモリプールから除外される。所定の数は、所与の実装に関する４、５、６、７又は任意の適切な数であってもよい。メモリプール・データ入力は、トランザクションＩＤフィールド、トランザクション・フィールド、及びコンファメーション数（ＮｏＣ）フィールドを含むように構成されてもよい。別の実装では、ＮｏＣを追跡するのではなく、メモリプール・データ入力は、単にブロック番号を記録してもよい。ブロック番号から、ブロックチェーンの現在のブロック番号に基づいて、何回のコンファメーションが発生したかを評価することが可能である。

いったん必要数のコンファメーションが行われると、トランザクションはメモリプールから安全に除外され得る。このようにして、オーファン・ブロックの場合にトランザクションの損失はなくなり、トランザクションは、必要数のコンファメーションの後に、永久的に削除される。

本明細書の以下の部分で説明されるようなソリューションは、上述したような高速検証ノードの修正されたタイプを使用する。新しいフル・ノード構成が説明され、これは、大規模ストレージ能力と改良された動作プロトコルとで強化されたＭ－ｎｏｄｅ検証アーキテクチャである。Ｍ－ｎｏｄｅとストレージ・ノードとは一緒になって新しいフル・ノードのコアを構成する。必要な技術的要件と技術的ソリューションとを含む新しいノード構造が詳細に説明され、持続可能なインセンティブ・モデルが提供される。

ブロック・サイズ及びストレージ条件
現在のブロック・サイズは１Ｍｂである。現在、ブロックは、所謂マジック・ナンバー（常に同じ値）と、ブロックの実際のサイズを示す値と、所謂ブロック・ヘッダと、ブロックに含まれるトランザクションの数と、そして最後に実際のトランザクションのリストとを含むフィールドで構成される。後者は常にコインベース・トランザクションから始まり、これはブロックをマイニングすることに対する報酬を含むトランザクションである。図１にブロックの全体構造が示されている。

ブロック・ヘッダは以下を含む：
１．バージョン番号（４バイト）
２．前のブロック・ヘッダのハッシュ（３２バイト）
３．マークル・ルート・ハッシュ（３２バイト）
４．時間（４バイト）
５．ターゲット閾値（ｎビットとしてエンコードされる－４バイト）
５．ノンス（４バイト）

現在、ブロックは約２０００のトランザクションを含み、ブロックは約１０分ごとに採掘される（１０分のブロック時間は、最初のコンファメーション時間とチェーン分割に費やされる時間との間の妥協として設定されている）。これは、理論上最大７トランザクション／秒で、約３．５トランザクション／秒というトランザクション・レートを提供する。対照的に、ＶＩＳＡは約１００００トランザクション／秒のレートで動作し、５００００トランザクション／秒以上に到達し得る。

競争支払システムを構築するためには、現在の制約についての何らかの迂回策が必要であることは明らかである。１０分間のブロック時間は十分に確立されているので、ブロック・サイズ、即ちブロックチェーン自体の変更を考慮することが必須である。本明細書では、例えば毎秒約５００００トランザクションを処理し得るスケーラブルなソリューションが説明される。

現在のブロック・サイズの増加、あるいは制限の完全な撤廃でさえそれらは、多くの議論の的となっており、時には論争の話題となっている。現在のサイズを維持すること及びそれを増加させることは何れも多大な恩恵とトレードオフをもたらすので、双方の側に有力な主張があるように思われる。

トランザクション・レートをｒと仮定すると、我々は必要なブロック・サイズを計算することができる。以下、（平均して）１０分のブロック時間が仮定される。そこで、Ｔ（ｒ）をブロック当たりのトランザクション数とする。
Ｔ（ｒ）＝ｒ・６・１０^２ ｂｌｏｃｋ^－１
ｓ_Ｔｘがバイト単位の平均トランザクション・サイズである場合、ブロック・サイズＢ（ｒ，ｓ_Ｔｘ）は次のように表すことが可能である。
Ｂ（ｒ，ｓ_Ｔｘ）＝ｓ_Ｔｘ・Ｔ（ｒ）＝ｓ_Ｔｘ・ｒ・６・１０^２
従って、ｒ＝５００００Ｔｘｓ／ｓ及びｓ_Ｔｘ＝５００バイトであるシナリオを考察すると、簡単なバック・オブ・エンベロープ計算は次のようになる。

これは、Ｏ（１０^６）Ｇｂ／ｙｅａｒというストレージ条件を導く。このサイズのブロックでは、ブロック伝搬とストレージの両方に対してわずかに異なるアプローチが必要であることは明らかである。以下の表１は、トランザクション・レート、平均トランザクション・サイズ、ブロック・サイズ、及び月次及び年次の必要なストレージ・スペース量を示す。

表１：トランザクション・レート、平均トランザクション・サイズ、ブロック・サイズ、及び必要な月次及び年次ストレージ・スペース量の関係

新たなビットコイン・ネットワーク
ビットコイン・ネットワークに対して提案するアーキテクチャが図２に示されており、これは、ユーザがトランザクションをサブミットした時点からそれがブロックチェーン上で終了するまでのステップを示す動作図を示す。

特殊な検証ノード（分散ハッシュ・テーブルＤＨＴによって自身の間で共有メモリプールを維持する）がトランザクションを受信し、それらを検証し、それらをメモリプールに割り振るシステムが提供される。その後、検証ノードは、有効なトランザクション・ハッシュのリストをマイナーに提供する各自のサービスを提供する。マイナーは、これらのハッシュに基づいてプレ・ブロック（ブロック・スケルトン）（ｐｒｅ－ｂｌｏｃｋｓ（ｂｌｏｃｋ ｓｋｅｌｅｔｏｎｓ））を組み立て、ハッシュ・パズルを解こうとする。パズルのソリューションが発見されると、勝利したマイナーはブロック・スケルトンを検証ノードへ返送する。これらは、ブロックを検証し、ブロックが保存されることを保証する。最初に、検証ノードがブロック自体を格納することは可能であり、実現可能である。ブロック・サイズが最終的にサイズの特定の閾値を超えると、検証ノードは：ａ）独自のストレージ機能を拡張するか；又はｂ）特殊なストレージ・ノードに格納することをアウトソースする。本明細書では２つのアーキテクチャが後に議論される。

新しいフル・ノード
Ｏ（１０）ＧＢというオーダーのブロック・サイズでは、ブロックチェーンのフル・イメージをホスティングするためのストレージ容量を提供するためにＰＣタイプのノードを当てにすることは、もはや実行不可能であるように思われる。その代わりに、Ｏ（１）ＰＢ又はより多くのストレージを提供する施設が必要とされる（表１参照）。そこで問題は、ネットワークの分散、非セントラル化、非トラスト性を維持しながら、新しいブロックを収容するシステムを構築することである。

２種類の完全なノード構造と、これらの２種類の組み合わせが考えられる：
１．関連するペタバイト・ストレージ・ラックを有する検証ノード
２．現在のビットコイン・ネットワークそれ自体に非常に類似する、内的に非セントラル化された分散されたピア・ツー・ピア（Ｐ２Ｐ）シングル・ノード・ネットワークに基づく関連ストレージ・プールを有する検証ノード
３．１及び２の組み合わせ

提案されるソリューションは、現在のビットコイン・ネットワークで動作する所謂フル・ノードに類似するノードを導入することにより、ブロックチェーンの分散された非セントラル化された記録を常に維持する問題を解決しようと試みるが、現在のビットコイン・ネットワークとは対照的に、ブロックのサイズとトランザクション数の増加に伴ってスケーリングできる能力を有する。

この相違は純粋に構造及びハードウェア関連の問題に限られない。書き込み時に動作する家庭用ＰＣベースのフル・ノードとは対照的に、ここで提案される新たなノードは特殊なノードである。それらはかなりの額の投資を必要とし、従ってインセンティブの仕方は非常に異なる。スケーラブルなパラダイムでは、Ｍ－ｎｏｄｅ（検証ノード）と新たなフル・ノード（検証ノードとストレージ・ノードとの組み合わせ）との両方が、それらのサービスに対する補償を期待している。

スペクトルの他方端では、非セントラル化され分散化されたストレージ・ソリューションがあり、その大部分は個人のノードで構成される。良い例は、Ｓｔｏｒｊ（Ｗｉｌｋｉｎｓｏｎ ｅｔ ａｌ．，２０１６）、Ｓｉａ（ＮｅｂｕｌｏｕｓＬａｂｓ）及びメイドセーフ（Ｍａｉｄｓａｆｅ）である。Ｓｔｏｒｊの場合、その機能は、参加者がストレージ・スペースの提供に対して報酬を得ることに基づいている。

上述したように、ペタバイト（Ｐｂ）ラックとピア・ツー・ピア（Ｐ２Ｐ）ストレージ・システムの両方から構成されるスーパー・ノードを想定することも可能である。

ビットコイン・エコシステムは、非セントラル化された方法で分散されたブロックチェーン全体の複数のレプリカの存在に大きく依存しているので、全てのフル・ノードが補償されることは重要であることは明らかである。これは、本質的には勝者が全ての賞を獲得するゲームであるマイニングとは非常に相違する。マイナーは（勝ち取った）ブロックを当てにして公のブロックチェーンにたどり着くので、全てのノードを格納することに報いることは、彼らの利益になる。

ノードはスーパー・ノードとして機能するプールにグループ化される。ブロックチェーンの分散性を維持するためには、そのようなスーパー・ノードが一定数（１００以上）存在しなければならない。スーパー・ノードは接続されるがオーバーラップしていない。

技術的要件
上述したように、新たなフル・ノードを議論する場合に考察されるべき２つの全体的に相違するアーキテクチャが存在する（表２参照）。

新たなフル・ノードは、２つのタイプのストレージを維持する必要がある：
１）メモリプールのための分散されたハッシュ・テーブル（ＤＨＴ）メモリ／ストレージのようなランダム・アクセス・メモリ（ＲＡＭ）
２）ブロックチェーンのストレージのような永続的なテープ／ディスク
上述したように、ｒ＝５００００Ｔｘ／ｓのトランザクション・レートに関し、ブロックはＯ（１０）Ｇｂであるように期待され、これは、
～３６５×２４×６×１５Ｇｂ＝７．９・１０^５Ｇｂ＝０．８Ｐｂ／ｙｒ
という年次ストレージ要求を意味する（表１参照）。

表２は現在のフル・ノードと将来のフル・ノードとの間の比較を示す：

同時に、ラック／クラスタはメモリプールを維持する必要がある。これは速やかなブロック復元を許容する。メモリプールの必要なサイズを評価することはより困難である。現在、約１メガバイト（～１Ｍｂ）のブロック・サイズ、毎秒約４トランザクション（～４Ｔｘ／ｓ）で、メモリプールで待機しているトランザクションの合計サイズは、２ないし約７０メガバイト（～７０Ｍｂ）の間で揺れている。図３は、コンファメーションのためにメモリプールで待機しているトランザクションの合計サイズを示すグラフである。

上述したように、大量のデータを保存することができる、基本的に異なる２つの構造、及びそれらの組み合わせを想定している。２つの構造は図４及び図５に示されている。図４は、内的にセントラル化されたストレージ装置へのアクセスを有する複数のノードを含む構成を示す。図５は、各ノードが分散されたメモリプールと分散されたストレージ装置との両方の一部である構成を示す。図４に描かれたアーキテクチャは、幾つかの検証ノードを所有及び維持する、より大きなエンティティに適しているように思われ、その検証ノードは全てエンティティの自身のストレージ装置に対するアクセスを有する。これに対して、図５に示されるアーキテクチャは、完全に非セントラル化されている。これは、十分なストレージ容量を有する家庭で所有されるＰＣのような、共有された分散ストレージ・プールに参加することを望む個々のノードに適したソリューションである。このために使用される基本的なストレージ技術は既に存在している（例えば、Ｓｔｏｒｊ、Ｓｉａ、ＭａｉｄＳａｆｅ）。

新しいフル・ノードがビットコイン・ネットワークにどのように適合するかを可視化する１つの方法が図６に示されており、図６は検証ノードがストレージ・プールのメンバーであるネットワーク構成を示す。プールは共に、非セントラル化された分散されたビットコイン・ネットワークを含む。

フル・ノード・オペレーション
ラージ・ブロックのシナリオでは、単にスペース要件に起因するだけではない別の状況に直面する。メモリプールは、ブロックに相当するもの、即ち約１５ギガバイト（～１５Ｇｂ）、好ましくは次に掘削されるブロックに対する等価量を収容できるべきである。これは、考慮する必要のあるオーバーヘッドと組み合わせる必要がある。
１）メモリプールは他の検証ノードと同期する必要がある。これは可逆ブルーム・フィルタ・ルックアップ・テーブル（Ｉｎｖｅｒｔｉｂｌｅ Ｂｌｏｏｍ ｆｉｌｔｅｒ Ｌｏｏｋｕｐ Ｔａｂｌｅｓ）を交換することを含む（Ｍｉｃｈａｅｌ Ｔ．Ｇｏｏｄｒｉｃｈ，２０１１）
２）ＩＢＬＴは精査され、欠落しているトランザクション（Ｔｘ’ｓ）が取得される
３）追加的に取得されたＴｘは検証されることを要する
４）マイナー及び他のフル・ノードから受信されたブロック・スケルトンに基づいてブロックを組み立てる。
新たなフル・ノードは、最新のメモリプールを保持する。これは、マイナー、他の検証ノード及び新たなフル・ノードともに交換されるＩＢＬＴによって行われる。

マイナーは以下のものにより構成されるブロック・スケルトン（タプル）を送信する：
１．ノンス，ｎ
２．ＩＢＬＴ
３．コインベース・トランザクション
これに基づいて、新たなフル・ノードは相応して（特定のルール・セットに従って）トランザクションを注文し、新たに採掘されたブロックを組み立てる。次に、新たなフル・ノードは、他の新たなフル・ノードにスケルトンを伝搬するだけでなく、各自自身のストレージにブロックを格納する処理を進める。プロトコルは本明細書で後に更に詳細に説明される。

インセンティブ
特定のコンフィギュレーションの１つの重要な特徴は、新たなノード構造とサービスの提供を奨励するためにシステムにインセンティブを構築することである。ブロックチェーンを格納することに付随する多大なコストに起因して、インセンティブが必要とされる。図７は新たなフル・ノードの機能を示す。新たなフル・ノードは、主に以下の２種類のサービスに対して報酬を与えられる：
１）検証されたトランザクションのリストをコンパイルし、マイニングに備える。トランザクションのハッシュ値（Ｍｅｒｋｌｅ ｒｏｏｔ）がマイナーへ送信され、そのマイナーはリストを選択してブロックを採掘する。
２）勝利したマイナーは採掘したブロックのスケルトンを幾つかの新たなフル・ノードへ送信する。スケルトンはコインベース・トランザクションを含み、以下のａ～ｃ．を含む：
ａ．マイニング報酬
ｂ．検証されたリストを提供する支払メカニズムとして使用されるコミットメント・スキームの一部であるシークレット
ｃ．ブロック検証、及び／又はブロックチェーンにおけるブロックのストレージに対する支払。

［トランザクション］検証ノードは、有料システムによってトランザクションの検証に関して払い戻しを受ける。受ける側の検証／新たなフル・ノードは以下のうちの１つ以上に関して報酬を受ける：
１）検証されたトランザクション（Ｔｘ）ハッシュのリストをマイナーに提供すること（上記ｂ．参照）。
２）ブロック・スケルトンからブロックを組み立て直すこと（「定額」料金）。
３）ブロックのサイズ（「ＭＢストレージ」単位の支払）。

インセンティブは１００ブロック・コンファメーション時間Ｔ_１００の間にある。
１）マイナーは彼らの報酬を請求するためにｔ～Ｔ_１００の間待機する必要がある。
２）検証ノードは、ブロック中のＴｘを検証することに関して彼らの手数料を受ける前に、ｔ～Ｔ_１００の間待機する必要がある。
３）新たなフル・ノードは、ブロック構築手数料及びサイズ依存性ストレージ支払を受ける前に、ｔ～Ｔ_１００の間待機する必要がある。

従って、１００ブロックのコンファメーション時間は、スケルトン・ブロック（支払いを含む）を、ある範囲内の新たなフル・ノードへ伝播させるために必要なインセンティブをマイナーに提供し、新たなフル・ノードは、スケルトン・ブロックを他の新たなフル・ノードに伝播するように刺激されるであろう。

また、ブロックに含まれることを希望する（トランザクションの）リストをマイナーが自由に選択することは、指摘されるべきである。かくて、マイナーがコミットメント・トランザクションによって選択及び購入することが可能な検証されたトランザクションのリストをまとめることによって、競合する検証ノードを含む市場を想定し得る。

改訂されたマイニング
ビットコイン・エコシステム（Ｔｈｅ Ｂｉｔｃｏｉｎ ｅｃｏｓｙｓｔｅｍ）は採掘の過程に依存する。マイナーは、トランザクション（Ｔｘｓ）をメモリプール（又はここで想定されるように、特殊な検証ノード）から収集し、それらをブロックに組織し、ハッシュ・パズルを解く解（ノンス）を発見しようと試みる。ブロック・ヘッダは、ブロックチェーンにおける前のブロックのハッシュ、トランザクションのマークル・ツリーのルート（根元）、及びマイナーによって含められるノンスを含む。パズルを解くことは、前のブロック・ハッシュ及びマークル・ルートと連結されたノンス（反復的に選択される）の二重ＳＨＡ２５６ハッシュを計算すること、及びそれがいわゆる困難性ターゲットより小さいか否かを検査することから構成される。仮にそれがノンスを下回るならば、パズルは解決されており、仮にそれを上回るならば、ノンスに対する反復が続く。これは、新しいパラダイムでも変わらずに残る。問題をもたらすものは、非常に拡大されたブロック・サイズ、及びネットワークを横断する採掘されたブロックの分布である。Ｇｂサイズのブロックでは、ネットワークにおいてブロック全体をブロードキャストすることは必ずしも必須でない。

むしろ我々は以下のステップに従うソリューションを提案する：
１．マイナーが、検証されたトランザクションのリストを、検証／Ｍ－ｎｏｄｅ及び／又は新たなフル・ノードから受信する。
２．マイナー自身は所定の順序付けの慣例に従うＴｘハッシュ値の各自自身のメモリプールを運営してもしなくてもよく、そのような順序付けの一例は以下に示されている。
［ｈｔｔｐｓ：／／ｗｗｗ．ｃｒｙｐｔｏｃｏｉｎｓｎｅｗｓ．ｃｏｍ／ｂｉｔｃｏｉｎ－ｉｎ－ｂｌｏｏｍ－ｈｏｗ－ｉｂｌｔｓ－ａｌｌｏｗ－ｂｉｔｃｏｉｎ－ｓｃａｌｅ／］
３．マイナーはノンス，ｎを決定することによってハッシュ・パズルを解く。
４．次に、ハッシュ・ツリー（マークル・ツリー、ここではＨＴとして言及される）が計算され、ツリーのルートが格納される（次のセクションを参照されたい）。
５．ＴｘｓのこのリストはＩＢＬＴを作成するために使用される。ＩＢＬＴは（例えば、メモリプールの）２つのセットの間の内容の相違を算出し、２つのセットをリコンサイル（ｒｅｃｏｎｃｉｌｅ）するために使用されることが可能である。
６．タプル｛ｎ；ＩＢＬＴ；コインベースＴｘ：ＨＴルート｝が検証／Ｍ－ｎｏｄｅへブロードキャストされる。
７．新たなフル・ノードは、ブロックチェーンに関するストレージ及びメモリプールに関するＤＨＴを運用する。
８．プールは、タプル｛ｎ；ＩＢＬＴ；コインベースＴｘ：ＨＴルート｝に基づいてブロックを組み立て直し、ａ）ブロック自身を格納することにより、又はｂ）特殊なストレージ・ノードに格納することにより、ブロックチェーン上でブロックを記録する。

マイナー間の競争回避
マイナーは、幾つかの検証ノードで構成される市場から、検証済みトランザクションのリストを選択することができるであろう。特に断りのない限り、マイナーは、彼らの可能性のある収益を最大化するリストを選択するであろうと仮定することは妥当である。注意深い読者は、これはマイナーが主に同じノードから同じリストを選ぶことにつながり得ることを指摘するかもしれない。これは、何人ものマイナーが同じブロックを採掘しようとして、互いに競い合う状況を招くであろう。このことは、最大のハッシュ能力を有するマイナーに有利に働くであろう。

我々は、ブロック・ヘッダに追加フィールドを追加することを提案する。このフィールドは、各マイナーによって選択される乱数を含む。これは、各マイナーが異なる開始点から出発することを保証し、従って、そのブロックの解を探すことが単に、ハッシュする能力の問題に落とされてしまうことを防止する。これは、マイナーが同じような、しかし個々に選んだ、僅かに異なるブロックを採掘する傾向がある現在の状況に似ている。

プロトコル
ここで、新しいフル・ノードを動作させるために必要なプロトコルを説明する。提案したシステムが、関わりのあるノード（検証者、採掘者、新しいフル・ノード・・・）のメモリプールを機能させるためには、トランザクションの順序付け規則に従うべきである。ここで、ギャビン・アンダーセンによって提案された正規順序（ｔｈｅ ｃａｎｏｎｉｃａｌ ｏｒｄｅｒｉｎｇ）を使用することを提案する。そこでは順序付けはブロック内のトランザクションのリストに関係しているが、ここで我々は、全ての検証ノードと新しいフル・ノードが、それらのメモリプールに同じ規則を使用するというアイディアを提示する。

規則は以下のように要約されることが可能である：
１）前のトランザクションのハッシュに関して昇順にトランザクションを並べる。
２）並べられたリストから、後続のトランザクションに依存しない最初のトランザクションを追加する。

前述したように、ブロックは所謂マークル・ルート・ハッシュを含む。これは、コインベース・トランザクションを含む全てのトランザクションをハッシュし、その後、マークル・ルート・ハッシュに到達するまで、ハッシュの連結をハッシュすることによって生成される。マイナーがコインベース・トランザクションを生産しているという事実がなければ、検証ノードはマークル・ツリー全体、従ってマークル・ルートと対応するハッシュを計算し得る、ということは明らかである。

ここで、次の方法の手続きを用いて計算されるマークル・ツリーを提案する：
検証ノードはリトル・マークル・ルート（a Little Merkle Root）を計算する。手順は、幾つかの例外と共に、標準的なマークル・ルートを計算する場合と同じである：
１）コインベース・トランザクションは省かれる。
２）いわゆる通信トランザクションが含められる。
３）マイナーはコインベース・トランザクションを生成し、それをリトル・マークル・ルート・ハッシュに連結し、マークル・ルート・ハッシュを生成する。

これは、新しいマークル・ツリー構造を示す図８に示されている。これは現在のプロトコルに対する修正を為すことに留意を要する。

ブロック・ヘッダに対する修正
上述したように、我々は、マイナーにより選択された乱数を含む追加のフィールドを、ブロック・ヘッダに追加することを提案する。従ってハッシュ・パズルを解くことは、以下のように変わる：

Ｐｒｅｖ．Ｂｌｏｃｋ Ｈａｓｈ：赤
Ｍａｒｋｅ Ｒｏｏｔ：緑
ｎｏｎｃｅ：青
ＲＮＤ：紫

従って我々は乱数を含む追加フィールドにより、採掘された新しいブロックのブロック・ヘッダが強化されることを提案する。ブロック・ヘッダは以下を含む：
１．バージョン番号（４バイト）
２．先行ブロック・ヘッダのハッシュ（３２バイト）
３．マークル・ルート・ハッシュ（３２バイト）
４．時間（４バイト）
５．ターゲット閾値（ｎビットとしてエンコードされる－４バイト）
６．ノンス（４バイト）
７．乱数（４バイト）

検証→マイナー
検証ノード：
○ 要求に応じて、検証ノード（新しいフル・ノードであってもなくてもよい）が、採掘される検証済みトランザクションのリストを準備する。
○ 検証者ノードがコミットメント・トランザクション（ａ ｃｏｍｍｉｔｍｅｎｔ ｔｒａｎｓａｃｔｉｏｎ）を作成する。
○ 所謂リトル・マークル・ルート（前節参照）が、包含されるコミットメント・トランザクションとともに算出される。
○ 検証者ノードが２つのＩＢＬＴ：
１）ブロック内の全てのトランザクションについて（ＩＢＬＴ１）；及び
２）ブロック内の全ての対応するＴＲｘＩＤについて（ＩＢＬＴ２）
を準備する。
○ 検証者ノードがマイナーへ：
１）リトル・マークル・ルート
２）ＩＢＬＴ１
３）ＩＢＬＴ２（オプション－マイナーが自身のＴｘＩＤ－／メモリプールとともに動作する場合のみ）
４）先行ブロック・ハッシュ
５）上記のハッシュ・チェックサム
を送信する。

マイナー：
○ 検証ノードからデータを受信すると、マイナーは、コインベース・トランザクションを作成する処理を進め、これは、マイニングに対する報酬、及び新たなフル・ノードのブロック検証／ストレージに対する報酬（マイナーが採掘されたブロックを送信することを希望する送付先）を含む。更に、コインベース・トランザクションは、コミットメント・トランザクションにおけるシークレットと一致する、シークレットを有するアウトプット・フィールドを含む。
○ マイナーは、検証者ノードから受信したリトル・マークル・ルートを使用し、それをコインベース・トランザクションと結合し、マークル・ルート・ハッシュを作成する。
○ マイナーは今やハッシュ・パズルを解き始めるために必要な全ての情報を有している。
○ マイニングは上述した方法で進行する。

マイナー→新たなフル・ノード
マイナー：
○ ブロックがマイニングされると、マイナーは以下のものを新たなフル・ノードのリストに送信する：
○ ノンス（パズルに対する解），ｎ
○ コインベース・トランザクション
○ ブロック・ヘッダ
○ マークル・ルート
○ リトル・マークル・ルート
○ ＩＢＬＴ１
○ ＩＢＬＴ２（オプション）
○ ハッシュ・チェックサム

新たなフル・ノード：
○ 適切な報酬がコインベース・トランザクションにあるか否かを検査する。
○ チェックサム（ハッシュ）を計算することにより、受信データは一貫していることをノードが確認する。
○ ブロック中のトランザクションがメモリプールに存在することを確認するためにノードがＩＢＬＴ１を利用する。
○ ＩＢＬＴ１を利用してメモリプールを照会し、ノードがブロックを組み立てる。次いでブロックは格納される（新たなフル・ノード及びストレージに関するセクション参照）。
○ マイナーから受信したデータ他の新たなフル・ノードへブロードキャストされる。

カスタマイズされたトランザクション・リスト
我々は、検証されるトランザクションのマーケットがマイナーのニーズに適合するような状況を想定している。マイナーは、彼らの可能性を最大化するリストを選ぶ傾向があり、検証中のＭ－ｎｏｄｅは、そのような傾向でピック・アップを行うであろう。

２つ以上のリストからトランザクションを組み合わせることにより、マイナーが自身のブロックをカスタマイズすることを希望するケースがあるかもしれない。２つのＩＢＬＴ間の相違を計算することにより、２つのセット間のセット調停（ｓｅｔ ｒｅｃｏｎｃｉｌｉａｔｉｏｎ）を行うことが可能である。次に、マイナーは、差異を含むＩＢＬＴを提供ノードの１つへ返送し、このようにして、リストを作成するのに必要な情報を取得し、このリストは、両方のリストにある全てのトランザクションを含む。

マイナーが幾つかのリストに基づいて各自自身のリストを作成したい場合には、さらなる課題が生じるように思われる。ここでは、様々な点について簡単に述べる。

マイナーが様々な検証ノードからのリストを組み合わせるならば、マークル・ルートがどのように組み合わせられるべきかは不明確である。ここで我々は以下を提案する：
個々のリトル・マークル・ルートについてのビッグ・リトル・マークル・ルート（ａ Ｂｉｇ Ｌｉｔｔｌｅ Ｍｅｒｋｌｅ ｒｏｏｔ）を構築すること；及び
ビッグ・リトル・マークル・ルートをコインベース・トランザクションと結合すること。

追加費用は、リスト／ブロックに追加される追加トランザクションの量に比例しない。様々なメモリプールがかなりオーバーラップするであろうと仮定することは妥当であるので、リストを組み合わせることは、異なるリストから少数の（相対的に言って）トランザクションを追加することになるであろう。しかし、リストを組み合わせるために、マイナーは各検証ノードから（コミットメント・トランザクションによって）全リストを「購入」しなければならないであろう。これがマイナーにとって有益なアプローチとなるか否かは、まだ分からない。

幾つかの検証ノードからのリストを組み合わせることは、マイナーと検証ノードを提供する各々との間にコミットメントを必要とする。マイナーによるこのシステムの悪用を想像することが可能である。現在のところ、全てのコミットメント・トランザクションがブロックに行き着くことを強制するルール／プロトコルは存在しない。１つの可能性は、検証ノードが各ブロックをチェックし、トランザクションを含むブロックを拒否できることである。

サマリー
今日のビットコイン・ネットワークは、計算労力という意味で、非常にマイナーを中心にしている。トランザクション量の大幅な増加により、これは必ずしも実現可能であるとは限らない。本明細書で説明されるソリューションは、さまざまな作業を、それに応じて特化されたノードに委託することにつながり、マイナーはよりいっそう自ら専門化されることになる。検証されたトランザクションのリストをまとめ、ブロック・スケルトンに基づいてブロックを再構築し、保管することは、全てかなりのリソースを必要とする機能である。従って、ビットコイン・ネットワークの構造は変化し、それに伴ってインセンティブも変化すると予想される。これらの問題について本明細書で詳細に説明した。

本明細書で導入される新たな要素の中で以下の事項に言及することができる：
○ 新たなタイプのノード構造。本明細書で新たなフル・ノード又はスーパー・ノードと呼ばれ、検証するＭ－ｎｏｄｅｓに対する拡張であってもなくてもよい。
○ ノードは、検証ノードからマイナーへ及びマイナーから新しいフル・ノードへの双方についてのＧｂサイズ・ブロックのブロードキャストを効果的に可能にするプロトコルで動作する。
○ ブロックチェーンを記憶するための２つの全体的な記憶構造。これは、提案される新しいフル・ノードの一部であってもなくてもよい。
○ 検証されるトランザクションの前ブロック・リストのマーケットの作成、及びブロックの組み立て及び格納を可能にするインセンティブ・モデル。
○ マイナーが各自自身のメモリプールを維持する必要性から解放する新たなマークル・ツリー構造。
○ 乱数を有するブロック・ヘッダの追加フィールドの追加。乱数は、マイニング活動が単にハッシュ処理能力に基づく競争になってしまうことを回避するために、マイナーによって選択される。
○ 検証は特殊なコミットメント・トランザクションを利用して報いられる。

ブルーム・フィルタ及びＩＢＬＴｓ
このセクションでは、いわゆる「ブルーム・フィルタ（Ｂｌｏｏｍ ｆｉｌｔｅｒｓ）」の特性と、「可逆ブルーム・ルックアップ・テーブル」と呼ばれるものへの拡張とを要約する。

最も簡易な形式では、ブルーム・フィルタはアレイである。アレイはそれに関連付けられる２つのパラメータ、Ｍ及びｋを有する。Ｍはアレイのビット数であり、ｋは以下の数式のような異なるハッシュ関数Ｈ_ｋの数であり、

ここで、Ｓ_１６は１６進文字列の空間であり、そこにハッシュ関数が作用する。トランザクションＴｘ_０が集合に属するか否かを決定するために、ブルーム・フィルタが作成され、我々はＨ_１（Ｔｘ_０）・・・Ｈ_ｋ（Ｔｘ_０）を計算し、次いで対応するビットがアレイの中で１に設定されているか否かを検査する必要がある。図９はブルーム・フィルタを作成する際のワークフローを示す。

１つ以上がそうでない場合、Ｔｘ_０は確実に対象集合には無い。しかしながら、ブルーム・フィルタは偽陽性（ｆａｌｓｅ ｐｏｓｉｔｉｖｅｓ）を許容する。これは、ビットを１に変化させるハッシュ関数の確率が、
ｐ＝１／｜アレイのサイズ｜＝１／Ｍ
であるという事実に由来する。従って、所謂

により、所与のハッシュ関数によってビットは１に設定されない。従って、ｋ個のハッシュ関数が存在する場合、所与のビットが１に設定されない確率は次のようになる：

ｎ個の要素が挿入される必要がある場合、それは次のようになる：

ブルーム・フィルタの明らかな欠点の１つは、任意の特定の順序を追跡せず維持しないことである。フィルタリングされるべきアイテムのインデックスを維持することを希望する場合、我々はフィルタの機能を拡張する必要があることは、直ぐに明らかになる。ここでは、可逆ブルーム・フィルタ（ＩＢＦｓ）及び可逆ブルーム・ルックアップ・テーブル（ＩＢＬＴｓ）加わる。

アレイにおいてビットをアクティブ化するだけではなく、鍵のＸＯＲ合計、ハッシュ値（前述のように）、及び全体のカウンタが、ＩＢＦの各フィールドに格納される。この手順は図１０に示されており、図１０は、ＩＢＦ／ＩＢＬＴにおいてトランザクションがどのようにエンコードされるかを示すワークフローを示す。

アプリケーション
２つのノードＮ_１及びＮ_２を有し、それぞれがメモリプールｍ_１及びｍ_２を維持していると仮定する。各メモリプールは１６進文字列全体Ｓ_１６のうちの要素を含む。更に、Ａｎｄｒｅｓｅｎにより提案され、本明細書で上記で概説されているように、メモリプールは順序規則（ａｎ ｏｒｄｅｒｉｎｇ ｃｏｎｖｅｎｔｉｏｎ）に従っていると仮定する。Ｎ_１がｍ_１をＮ_２へ送り、今やＮ_２は２つの方法でセット・リコンシリエーションにアプローチすることができる：
１）Δｍ＝ｍ_２－ｍ_１により集合の差分を計算する（（Ｄａｖｉｄ Ｅｐｐｓｔｅｉｎ，２０１１），（Ｍｉｃｈａｅｌ Ｔ．Ｇｏｏｄｒｉｃｈ，２０１１）を参照されたい）。
２）ｍ_２におけるトランザクションに関して反復を行い、Ｎ_１のメモリプールに存在するか否かをチェックする。

ＩＢＬＴは少なくとも２つの目的で使用され得ることが分かる：
１）各自のメモリプールに既に有しているトランザクションに基づいて、ノードに、採掘されたブロックをアセンブルさせ、それらが有していないブロックを識別及び取得することを支援すること。
２）異なるノードに所属するメモリプールの間で所定レベルの同期を維持すること。

トランザクションはビットコインを転送することができるが、ユーザは、情報、契約、及びトークン等の本明細書に記載される方法及びシステムを使用して、他のリソースを交換することができることが理解されるべきである。トークンは、トークンに関連付けられたスマート契約に従って資産又はリソースを表し、その結果、トークンのコントロールが、資産又はリソースのコントロールをもたらす。スマート契約それ自体はブロックチェーン外で格納されてもよいし、あるいは１つ以上のトランザクションの中に格納されてもよい。

リファレンス
Ａｎ Ｉｎｔｅｇｒａｔｅｄ Ｗｏｒｌｄ．（ｎ．ｄ．）．Ｒｅｔｒｉｅｖｅｄ ｆｒｏｍ ｈｔｔｐｓ：／／ｗｗｗ．ａｎｉｎｔｅｇｒａｔｅｄｗｏｒｌｄ．ｃｏｍ／ｗｈａｔｓ－ｉｎ－ａ－ｂｌｏｃｋ／
Ｄａｖｉｄ Ｅｐｐｓｔｅｉｎ，Ｍ．Ｔ．（２０１１）．Ｗｈａｔ’ｓ ｔｈｅ Ｄｉｆｆｅｒｅｎｃｅ？ Ｅｆｆｉｃｉｅｎｔ Ｓｅｔ Ｒｅｃｏｎｃｉｌｉａｔｉｏｎ ｗｉｔｈｏｕｔ Ｐｒｉｏｒ Ｃｏｎｔｅｘｔ．ＡＣＭ． ｍａｉｄｓａｆｅ．（ｎ．ｄ．）．Ｒｅｔｒｉｅｖｅｄ ｆｒｏｍ ｇｉｔｈｕｂ．ｃｏｍ： ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ｍａｉｄｓａｆｅ／Ｗｈｉｔｅｐａｐｅｒｓ
Ｍｉｃｈａｅｌ Ｔ．Ｇｏｏｄｒｉｃｈ，Ｍ．Ｍ．（２０１１）．Ｉｎｖｅｒｔｉｂｌｅ Ｂｌｏｏｍ Ｌｏｏｋｕｐ Ｔａｂｌｅｓ．Ｃｏｍｍｕｎｉｃａｔｉｏｎ，Ｃｏｎｔｒｏｌ， ａｎｄ Ｃｏｍｐｕｔｉｎｇ（Ａｌｌｅｒｔｏｎ），２０１１ ４９ｔｈ Ａｎｎｕａｌ Ａｌｌｅｒｔｏｎ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ．
ＮｅｂｕｌｏｕｓＬａｂｓ．（ｎ．ｄ．）．Ｒｅｔｒｉｅｖｅｄ ｆｒｏｍ ｇｉｔｈｕｂ．ｃｏｍ： ｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／ＮｅｂｕｌｏｕｓＬａｂｓ／Ｓｉａ Ｏ（１） Ｂｌｏｃｋ Ｐｒｏｐａｇａｔｉｏｎ． （ｎ．ｄ．）．Ｒｅｔｒｉｅｖｅｄ ｆｒｏｍ ｇｉｔｈｕｂ．ｃｏｍ：ｈｔｔｐｓ：／／ｇｉｓｔ．ｇｉｔｈｕｂ．ｃｏｍ／ｇａｖｉｎａｎｄｒｅｓｅｎ／ｅ２０ｃ３ｂ５ａ１ｄ４ｂ９７ｆ７９ａｃ２
Ｗｉｋｉｐｅｄｉａ．（ｎ．ｄ．）．Ｒｅｔｒｉｅｖｅｄ ｆｒｏｍ ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｄｉｓｔｒｉｂｕｔｅｄ＿ｈａｓｈ＿ｔａｂｌｅ
Ｗｉｌｋｉｎｓｏｎ ｅｔ ａｌ．（２０１６， Ｄｅｃｅｍｂｅｒ １５）． Ｒｅｔｒｉｅｖｅｄ ｆｒｏｍ ｈｔｔｐｓ：／／ｓｔｏｒｊ．ｉｏ／ｓｔｏｒｊ．ｐｄｆ

上述の実施形態は本発明を限定するものではなく、本発明を例示するものであること、当業者は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく、多くの代替実施形態を設計することが可能であることに留意すべきである。特許請求の範囲においては、括弧内に付された如何なる参照符号も、特許請求の範囲を限定するものと解釈されてはならない。「～を含んでいる」及び「～を含む」等の用語は、何れかの請求項又は明細書全体に列挙されたもの以外の要素又は工程の存在を排除しない。本明細書において、「～を含む」とは、「～を含む、又は～から構成される」ことを意味し、「～を含んでいる」とは、「～を含んでいる、又は～から構成されている」ことを意味する。要素の単独的な参照は、複数のそのような要素の参照を除外するものではなく、その逆もまた同様である。本発明は、幾つかの別個の要素を含むハードウェアによって、及び適切にプログラムされたコンピュータによって実施され得る。幾つかの手段を列挙する装置クレームにおいては、これらの手段の幾つかは、１つの同一ハードウェア・アイテムによって具体化されてもよい。複数の事項が相互に異なる従属請求項で引用されているという単なる事実は、これらの事項の組み合わせが有利に使用できないことを示すものではない。

Claims (24)

1. ブロックチェーン・ネットワークのノードに対するコンピュータで実現される方法であって、前記ブロックチェーン・ネットワークにおいて、検証するノードはマイニングのノードとは区別され、当該方法は：
   複数の検証されたトランザクションに対応する採掘されたデータを前記ブロックチェーン・ネットワークから受信するステップ；
   前記採掘されたデータに基づいて複数のブロックを組み立てるステップ；及び
   ブロックチェーンにおいて格納するためにストレージ・エンティティへ、組み立てられたブロックを送信するステップ；
   を含む方法。
2. 前記ブロックチェーン・ネットワークから受信される前記採掘されたデータは、前記検証されたトランザクションに対応するブロック・ヘッダを含む、請求項１に記載のコンピュータで実現される方法。
3. 前記採掘されたデータは、前記採掘されたデータに基づいてブロックを組み立てることに対する見返りとしてディジタル資産のトランザクションを含む、請求項１又は２に記載のコンピュータで実現される方法。
4. 前記採掘されたデータは、組み立てられたブロックの格納に対する見返りとしてディジタル資産のトランザクションを含む、請求項１－３のうち何れか１項に記載のコンピュータで実現される方法。
5. 前記ディジタル資産を受け取る前に、最低限のブロック数に関連する期間ｔの間待機する条件を更に含む請求項３又は４に記載のコンピュータで実現される方法。
6. 前記採掘されたデータに基づいて複数のブロックを組み立てる前記ステップが、各ブロックが少なくとも２メガバイトのサイズを有するラージ・ブロックを組み立てるステップを含む、請求項１－５のうち何れか１項に記載のコンピュータで実現される方法。
7. 前記ブロックはマイナーにより提供される乱数を含むブロック・ヘッダを含む、請求項１－６のうち何れか１項に記載のコンピュータで実現される方法。
8. 前記ブロックチェーンに前記ブロックを格納するステップを更に含む請求項１－７のうち何れか１項に記載のコンピュータで実現される方法。
9. 前記ストレージ・エンティティは前記ブロックチェーン・ネットワークにおける複数のノード間で共有され、前記複数のノードは前記ブロックチェーン・ネットワークにおけるスーパー・ノードを形成し、前記共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又は両者の組み合わせのうちの何れかである、請求項１－８のうち何れか１項に記載のコンピュータで実現される方法。
10. 前記ブロックチェーン・ネットワークからトランザクションを受信するステップ；
    前記ブロックチェーン・ネットワークから受信したトランザクションを検証するステップ；
    前記ブロックチェーン・ネットワークにおける他のノードとともに、検証されたトランザクションについての分散された非セントラル化されたストレージを維持するステップ；及び
    前記検証されたトランザクションに対応するデータであって検証されたトランザクションのリストを含むデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配するステップ；
    を更に含む請求項１－９のうち何れか１項に記載のコンピュータで実現される方法。
11. 前記ブロックチェーン・ネットワークにおける他のノードとともに、検証されたトランザクションについての分散された非セントラル化されたストレージを維持する前記ステップが、検証されたトランザクションの最新のリストを非セントラル化された分散された方法で維持するために、前記ブロックチェーン・ネットワークにおけるノードを同期させるステップを含む、請求項１０に記載のコンピュータで実現される方法。
12. 前記ノードは、可逆ブルーム・フィルタ・ルックアップ・テーブルを交換することにより同期させられる、請求項１１に記載のコンピュータで実現される方法。
13. 前記検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、前記ブロックチェーン・ネットワークにおけるノードにわたって共通の順序体系が使用されるように、前記検証されたトランザクションが所定の順序でソートされる、請求項１０－１２のうち何れか１項に記載のコンピュータで実現される方法。
14. 前記検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、前記検証されたトランザクションは、正規の順序体系を利用して前記所定の順序でソートされる、請求項１３に記載のコンピュータで実現される方法。
15. 前記検証されたトランザクションに対応するデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配する前記ステップが：
    検証されたトランザクションのリストに対応するデータを準備するステップ
    を含む、請求項１０－１４のうち何れか１項に記載のコンピュータで実現される方法。
16. 前記検証されたトランザクションに対応するデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配する前記ステップが：
    前記検証されたトランザクションのリストに対応する前記データをマイナーに提供することに対する見返りとしてディジタル資産のコミットメント・トランザクションを作成するステップ
    を含む請求項１０－１５のうち何れか１項に記載のコンピュータで実現される方法。
17. ハッシュ・ツリー、パトリシア・ツリー、又は他のタイプのラディックス・ツリーが、包含される前記コミットメント・トランザクションとともに算出される、請求項１６に記載のコンピュータで実現される方法。
18. 前記検証されたトランザクションに対応する前記データは、可逆ブルーム・ルックアップ・テーブル及び任意の付随するデータの形式で前記ブロックチェーン・ネットワークへ分配され、前記検証されたトランザクションはブロックに含まれる、請求項１０－１７のうち何れか１項に記載のコンピュータで実現される方法。
19. 実行されると請求項１－１８のうち何れか１項に記載の方法を実行するようにプロセッサを構築するコンピュータ実行可能命令を含むコンピュータ読み取り可能な記憶媒体。
20. インターフェース・デバイス；
    前記インターフェース・デバイスに結合される１つ以上のプロセッサ；
    前記１つ以上のプロセッサ結合されるメモリ；
    を含む電子デバイスであって、前記メモリは、実行されると請求項１－１８のうち何れか１項に記載の方法を実行するように前記１つ以上のプロセッサを構築するコンピュータ読み取り可能な命令を格納している、電子デバイス。
21. 請求項１－１８のうち何れか１項に記載の方法を実行するように構成される、ブロックチェーンのノード。
22. 請求項２１に記載のノード複数個；及び
    前記ブロックチェーンを格納する共有されるストレージ・エンティティ；
    を含む、ブロックチェーンのスーパー・ノードであって、前記共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又は両者の組み合わせのうちの何れかであり、
    前記複数のノードにより組み立てられるブロックは、前記共有されるストレージ・エンティティへ送信及び格納されることにより、前記共有されるストレージ・エンティティは前記ブロックチェーンを維持する、スーパー・ノード。
23. 前記共有されるストレージ・エンティティは少なくとも１００ギガバイトのストレージ容量を有する、請求項２２に記載のスーパー・ノード。
24. 請求項２２又は２３に記載のスーパー・ノードを複数個含むブロックチェーン・ネットワークであって、
    前記スーパー・ノードは前記ブロックチェーン・ネットワークで接続されており、各スーパー・ノードの前記共有されるストレージ・エンティティは前記ブロックチェーンのコピーを格納するように構成されており、前記ブロックチェーン・ネットワークは少なくとも１０個のスーパー・ノードを含む、ブロックチェーン・ネットワーク。

Images