JP2020528607A - ブロックチェーンネットワークにおいて大規模分散メモリプールを管理するためのコンピュータ実装されたシステム及び方法 - Google Patents

Abstract

ブロックチェーンネットワーク内に実装される、コンピュータ実装された方法が記述される。検証ノードは、複数のトランザクションを有する新たにマイニングされたブロックに関するデータを受信し、また、分散メモリプールに対して、該複数のトランザクションを分散メモリプールから削除する削除要求を送信する。分散メモリプールを格納するノードは、複数のトランザクションを格納し、該複数のトランザクションは、ブロックチェーンのブロックへとマイニングされるのを待っている分散メモリプールの少なくとも一部を形成する。当該コンピュータ実装された方法は更に、ブロックチェーンネットワークの検証ノードからの削除要求を受信し、該削除要求は、新たにマイニングされたブロックに含められた１つ以上のトランザクションを特定し、該削除要求は、前記１つ以上のトランザクションが分散メモリプールから削除されるべきことを指し示す。

Description

本明細書は、概して、ブロックチェーンネットワークのノードにおける実装に適したコンピュータ実装された方法及びシステムに関する。多数のトランザクション及び大きいトランザクションブロックを扱うための改良されたブロックチェーンノード構造、ネットワークアーキテクチャ、及びプロトコルが記述される。本発明は、以下に限られないが、特にビットコイン（Ｂｉｔｃｏｉｎ）ブロックチェーンとの使用に適する。

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

ブロックチェーンは、トランザクション及び他の情報からなる複数のブロックで構成されるコンピュータベースの非中央集権的な分散システムとして実装されるコンセンサスベースの電子台帳である。ビットコインの場合、各トランザクションは、ブロックチェーンシステムにおける参加者間でのデジタル資産の管理の移転を符号化するデータ構造であり、少なくとも１つのインプットと少なくとも１つのアウトプットとを含む。各ブロックが、そのブロックが一緒にチェーン化される先行ブロックのハッシュを含むことで、その開始以前にそのブロックチェーンに書き込まれた全てのトランザクションの恒久的で変更不可能な記録を作り出す。トランザクションは、それらのインプット及びアウトプットに埋め込まれるスクリプトとして知られた小プログラムを含み、それらが、トランザクションのアウトプットが誰によってどのようにアクセスされ得るかを指定する。ビットコインプラットフォーム上では、これらのスクリプトは、スタックベースのスクリプト言語を使用して書かれる。

トランザクションがブロックチェーンに書き込まれるには、そのトランザクションが“検証済み”でなければならない。幾つかのネットワークノードがマイナー（採掘者）として働いて、各トランザクションが有効であることを保証するための作業を実行し、無効なトランザクションはネットワークから拒絶される。例えば、ノードにインストールされているソフトウェアクライアントが、未使用トランザクションアウトプット（unspent transaction outputs；ＵＴＸＯ）を参照するトランザクションに対してこの検証作業を実行する。検証は、そのロッキング及びアンロッキングスクリプトを実行することによって実行され得る。ロッキング及びアンロッキングスクリプトの実行がＴＲＵＥに評価され、且つ特定の他の条件が満たされる場合、トランザクションは有効であり、トランザクションがブロックチェーンに書き込まれることができる。従って、トランザクションがブロックチェーンに書き込まれるには、そのトランザクションが、ｉ）そのトランザクションを受け取るノードによって検証され（そのトランザクションが検証された場合に、そのノードがそれをネットワーク内の他のノードに中継する）、ｉｉ）マイナーによって構築された新しいブロックに追加され、そして、ｉｉｉ）マイニングされ、すなわち、過去のトランザクションの公開台帳に追加されなければならない。ブロックチェーンに十分な数のブロックが追加されてトランザクションを実質的に不可逆にしたとき、トランザクションは承認されたとみなされる。

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

１つの研究分野は、“スマート契約”の実装のためのブロックチェーンの使用である。それらは、機械読み取り可能な契約又は合意の条件の履行を自動化するように設計されるコンピュータプログラムである。自然言語で書かれていた伝統的な契約書とは異なり、スマート契約は、結果を生成するためにインプットを処理し得るルールを有する機械実行可能プログラムであり、そして、それらの結果に応じてアクションを実行させ得る。

ブロックチェーン関連で関心ある他の１つの分野は、ブロックチェーンを介して実世界のエンティティを表現して移転するための‘トークン’（又は‘カラードコイン’）の使用である。潜在的に機密又は秘密のアイテムを、識別可能な意味又は値を持たないトークンによって表現することができる。トークンは、故に、実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。

例えばビットコインといったブロックチェーン技術の未来は、少なくとも部分的に、毎秒発行されるトランザクションの量を増加させることができる新アーキテクチャの提案を当てにしている。そのような新アーキテクチャに対する１つの要求は、ブロックサイズ制限についての現在の限界を取り除くことである。そのシナリオにおいて、１つの技術的問題は、大きいブロックのデータをどのように管理し、そして、非常に大きいブロックチェーンのストレージをどのように管理するのかである。他の１つの技術的問題は、ブロックへとマイニングされてブロックチェーンに組み込まれるのを待っているトランザクションのプールをどのように管理するのかである。ローカルなメモリプールでは十分なストレージ能力を提供することができず、それ故に、分散メモリプール（distributed memory pools；ＤＭＰｓ）に関する新しいモデルを設計する必要がある。トランザクションがブロックチェーンに含められた後には、そのような分散メモリプールからそれらトランザクションを除去することが望ましい。しかしながら、他の１つの技術的問題は、分散メモリプール内で問題となるデータ不一致を生じさせることなく、分散メモリプールからのトランザクションの除去をどのように安全に管理するのかである。更に他の１つの技術的問題は、分散メモリプールに格納されたデータを分断させようとする攻撃に対するセキュリティをも向上させながら、データ不一致の問題をどのように緩和するのかである。

本発明の特定の実施形態の１つの狙いは、ここに記載される技術的解決策を提供することによって、これらの技術的問題に対処することである。特に、本明細書は、分散メモリプール内でのデータ不一致の問題を緩和しながら、分散メモリプールが剪定（プルーニング）されることを可能にするような、ブロックチェーンネットワークにおける検証ノードと分散メモリプールノードとの間での通信及びデータ管理のためのプロトコルを記述する。従って、本発明は、ブロックチェーンネットワークの分散性を維持しながらその容量を増加させることによって技術的に貢献する。

ブロックチェーンネットワークのノード用のコンピュータ実装された方法が記述され、当該コンピュータ実装された方法は、
複数のトランザクションを格納し、該複数のトランザクションは、ブロックチェーンのブロックへとマイニングされるのを待っている分散メモリプールの少なくとも一部を形成し、
ブロックチェーンネットワークの検証ノードからの削除要求を受信し、削除要求は、新たにマイニングされたブロックに含められた１つ以上のトランザクションを特定し、削除要求は、該１つ以上のトランザクションが分散メモリプールから削除されるべきことを指し示す、
ことを有する。

上述の方法は、検証ノードが分散メモリプールと通信することで、ブロックチェーンに組み込まれており、それ故に、分散メモリプールから除去されることができるトランザクションを除去することを可能にする。１つ以上のトランザクションが分散メモリプールから削除されるべきことを指し示す明示的な削除要求の送信／受信は、トランザクションがマイニングされたことの単なる通知とは異なる。従来技術の構成では、マイニングされたトランザクションは、トランザクションが承認されるのに十分なブロックが上にマイニングされたことになるまで、メモリプールから除去されない。従って、メモリプールは、必要とされそうにもない多数のトランザクションを、それらがブロックチェーンにマイニングされた後にかなりの量の時間にわたって含んでいる。さらに、マイナーが、特定の削除要求プロトコルに従わずに、一定期間の時間後にトランザクションを自動的に削除するとすれば、それは特定の状況においてデータ不一致につながり得る。本発明は、これらの問題を認識して対処する。

当該方法は更に、トランザクションに、該トランザクションに対して第１閾値数の削除要求が受信されたときに、分散メモリプールから除去されるものとしてマーキングすることを含み得る。当該方法はまた、トランザクションを、該トランザクションに対して第２閾値数の削除要求が受信されたときに、分散メモリプールから物理的に除去することを含み得る。第２閾値は第１閾値よりも大きい。さらに、第１閾値数の削除要求及び第２閾値数の削除要求が、ブロックチェーンネットワーク内の、閾値数の、異なる検証ノードから来ることが要求される。これらの特徴は、分散メモリプール内でトランザクションが除去されるものとしてマーキングされることに関するコンセンサスのレベルと、トランザクションが分散メモリプールから物理的に除去される前での更なるコンセンサスのレベルとを必要とする。これは、データ不一致の問題が緩和するとともに、分散メモリプールに格納されたデータを分断させようとする攻撃に対するセキュリティを向上させる。トランザクションは実効的に、利用可能、除去される、及び物理的に除去されるという、分散メモリプールに対する３つの状態を有する。除去されるものとしてマーキングされたトランザクションは、必要とされる場合に、分散メモリプール内で再び利用可能であるように復帰されることができる。物理的に削除されるトランザクションは、システムの構成に応じて、復帰可能でないことがある。

トランザクションは、削除要求を受信してから、該トランザクションに対する更なるデータ要求が受信されることなく、閾値時間だけ経過した後にのみ、分散メモリプールから物理的に除去され得る。例えば、閾値時間は、分散メモリプールからの削除が要求されているトランザクションがブロックチェーンに組み込まれた後に、少なくとも１、２、３、４、５、６、又はそれより多くのブロックがブロックチェーンに組み込まれることに相当するとし得る。また、トランザクションは、削除要求を受信してから、該トランザクションに対する更なるデータ要求が受信されることなく経過した時間の降順で、分散メモリプールから物理的に除去されてもよい。当該コンピュータ実装された方法はまた、トランザクションに、該トランザクションが先行して除去されたトランザクションに依存するときに、分散メモリプールから除去されるものとしてマーキングし得る。これらの特徴は、データ不一致の問題を緩和することの更なる助けとなるとともに、分散メモリプールに格納されたデータを分断させようとする攻撃に対するセキュリティを更に向上させる。

削除要求は、分散メモリプールに関連付けられた新たな削除要求データベースに格納されることができる。そのトランザクションを検証しなかったバリデータから受信された削除要求は破棄され得る。トランザクションは、チェックバリデータオプションがイネーブルされている場合にのみ破棄され得る。分散メモリプールから除去されるものとして既にマーキングされたトランザクションに対するデータ要求の数もモニタすることができる。このようなシステムを用いることで、分散メモリプールからの除去のためにマーキングされたトランザクションに対して閾値数のデータ要求が受信された後に、トランザクションは、分散メモリプールへの復帰の候補としてマーキングされ得る。トランザクションは、該トランザクションに対して復帰要求が受信されたときに、又は該トランザクションに対して閾値数の復帰要求が受信されたときに、分散メモリプールから除去されるものとしてのマーキングを解除され得る。閾値数の復帰要求が、ブロックチェーンネットワーク内の、閾値数の、異なる検証ノードから来ることを要求することができる。分散メモリプールから除去されたトランザクションに対する問い合わせに応答して、トランザクションが分散メモリプールから除去されたことを指し示すメッセージが送信され得る。また、このようなメッセージは、トランザクションが分散メモリプールから除去されたことを指し示すとともに、除去された該メッセージに対して受信された削除メッセージの数を指し示すこともできる。やはり、これらの特徴は、データ不一致の問題を緩和することの更なる助けとなるとともに、分散メモリプールに格納されたデータを分断させようとする攻撃に対するセキュリティを更に向上させる。

分散メモリプール管理のためのプロトコルの上述の特徴は、ブロックチェーンネットワーク内の分散メモリプールストレージノードの視点から記述されている。ブロックチェーンネットワーク内の検証ノードの視点から、
複数のトランザクションを有する新たにマイニングされたブロックに関するデータを受信し、
分散メモリプールに、前記複数のトランザクションを当該分散メモリプールから削除する削除要求を送信する、
ことを有するコンピュータ実装された方法が提供される。

削除要求は、好ましくは、コンセンサスプロトコルに影響を及ぼし得る不正な複製の流布を回避するために、ナンス及び／又はタイムスタンプを含むべきである。削除要求はまた、好ましくは、検証ノードの秘密鍵で署名される。

ノードは、自身が検証したトランザクションの記録を記憶し、自身が以前に検証したトランザクションに関してのみ削除要求を送信することができる。削除要求は、チェックバリデータオプションがイネーブルされているときにのみ、ノードが以前に検証したトランザクションに関して送信され得る。また、トランザクションを分散メモリプール内で再び利用可能にするために復帰要求が、例えば、ブロックチェーン再編成の後に、システム内でのデータ一貫性を保持するために送信され得る。

前記削除要求は、
マイニングされたブロックの受信、
ブロックチェーン再編成、及び
二重支払い又はその他の形態のトランザクションコンフリクト、
のうちの１つ以上によって起動されることができる。

分散メモリプールからのトランザクションの剪定は、
手動剪定、
トランザクション期限切れ、及び
前記分散メモリプール内のトランザクションに関してメモリ制限に達したこと、
のうちの１つ以上によって起動されることができる。

本発明の実施形態は、多様な形態で提供されることができる。例えば、コンピュータ実行可能命令を有したコンピュータ読み取り可能記憶媒体を提供することができ、該コンピュータ実行可能命令は、実行されるときに、ここに記載の方法を実行するように１つ以上のプロセッサを構成する。インタフェース装置と、該インタフェース装置に結合された１つ以上のプロセッサと、該１つ以上のプロセッサに結合されたメモリであり、当該メモリはコンピュータ実行可能命令を格納しており、該コンピュータ実行可能命令は、実行されるときに、ここに記載の方法を実行するように上記１つ以上のプロセッサを構成する、メモリと、を有するエレクトロニクス装置も提供することができる。より更には、ここに記載の方法を実行するように構成された、ブロックチェーンネットワークのノードを提供することができる。

本発明のこれら及び他の態様が、ここに記載される実施形態を参照して解明されて明らかになる。以下、本発明の実施形態が、単なる例として、以下を含む添付の図面を参照して説明される。
ブロックの全体構造を示している。 ユーザがトランザクションを提起した時点からそれがブロックチェーン上で終了するまでのステップを例示する動作図に関して、ビットコインネットワークの改良アーキテクチャを示している。 メンプール（mempool）内で承認を待っているトランザクションの合計サイズの一例を示すグラフである。 内部中央集権的ストレージ機関にリンクされた複数のノードを示している。 各ノードが分散メンプール及び分散ストレージ機関の双方の一部である構成を例示している。 新しいノード構造がビットコインネットワークにどのように適合するかを例示しており、検証ノードがストレージプールのメンバーであり、それらプールが共に非中央集権的な分散ビットコインネットワークを有するネットワーク構成を示している。 新しいノードの機能を示している。 現行プロトコルへの変更を構成する新しいマークルツリー構造を例示している。 ブルームフィルタを作成する際のワークフローを示している。 可逆ブルームフィルタ（ＩＢＦ）及び可逆ブルームルックアップテーブル（ＩＢＬＴ）にトランザクションがどのようにエンコードされるかを例示するワークフローを示している。 バリデータノードｖ及びメンプールノードｓを含むメンプールクラスタを例示している。 新たにマイニングされたブロックに関する更新を受信するバリデータノードｖ_ｎ（０≦ｎ＜Ｎ）を示しており、ブロックを検証した後、バリデータが、発行されたトランザクションに関するＤＥＬＥＴＥ（削除）要求を分散メモリプール（ＤＭＰ）に送信し、各メンプールノードｓｍ（０≦ｍ＜Ｍ）が、Ｓ_ＤＢテーブル上の格納要求及びＲ_ＤＢテーブル上の除去要求を追跡する。 トランザクションｉｄｉの状態図を示しており、バリデータから受信したメッセージのタイプ（すなわち、ＳＴＯＲＥ、ＲＥＭＯＶＥ、ＲＥＶＥＲＴ）と数（例えば、Ｎ、Ｎ＊、Ｎ＊＊）に応じて、トランザクションは、状態を、Ａｖａｉｌａｂｌｅ、Ｒｅｍｏｖｅｄ、又はＰｈｙｓｉｃａｌｌｙ Ｒｅｍｏｖｅに変化させることができる。

ブロックチェーンネットワークノードのタイプ
ブロックチェーンネットワークは、招待なしで又は他メンバーの同意なしで、誰でも参加し得るピアツーピアオープンメンバーシップネットワークとして記述され得る。その下でブロックチェーンネットワークが動作するブロックチェーンプロトコルのインスタンスを走らせている分散エレクトロニクス装置は、ブロックチェーンネットワークに参加することができる。そのような分散エレクトロニクス装置は、ノードとして参照され得る。ブロックチェーンプロトコルは、例えば、ビットコインプロトコル又は他の暗号通貨とし得る。

ブロックチェーンプロトコルを走らせ、ブロックチェーンネットワークのノードを形成するエレクトロニクス装置は、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバ、コンピュータファームなどのコンピュータ、スマートフォンなどのモバイル装置、スマートウォッチなどのウェアラブルコンピュータ、又は他のエレクトロニクス装置を含め、様々なタイプのものとし得る。

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

現在、ノードは、複数のブロックにグループ化されて該複数のブロックの各々がチェーン内の先行ブロックのハッシュが含んだブロックチェーン上の全てのトランザクションのグローバル台帳を維持している。グローバル台帳は分散台帳であり、各ノードが、グローバル台帳の完全なコピー又は部分的なコピーを格納し得る。グローバル台帳に影響を与えるノードによるトランザクションが他のノードによって検証されることで、グローバル台帳の妥当性が維持される。例えばビットコインプロトコルを使用するものなど、ブロックチェーンネットワークを実装して動作させることの詳細は、当業者によって理解されることになる。

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

ノードは、それらの機能に応じて、異なるタイプ又はカテゴリのものであるとし得る。提案されていることには、ウォレット、マイニング、フルブロックチェーンメンテナンス、及びネットワークルーティングノードという、ノードに関連付けられる４つの基本機能が存在する。これらの機能のバリエーションが存在してもよい。ノードは、それらの機能のうちの２つ以上を有していてもよい。例えば、“フルノード”は、４つの全ての機能を提供する。従って、軽量なノードは、例えばデジタルウォレットにて実装され得るとともに、ウォレット及びネットワークルーティングの機能のみを果たし得る。デジタルウォレットは、ブロックチェーン全体を格納するのではなく、ブロックを照会するときにインデックスとしての役割を果たし得るものであるブロックヘッダを追跡し得る。ノードは、例えばＴＣＰ／ＩＰ（通信制御プロトコル）などのコネクション指向のプロトコルを用いて、互いに通信する。

マーチャントノード（ここでは時々、“Ｍ−ｎｏｄｅ”（“Ｍノード”）として参照する）といった、更なるタイプ又はカテゴリのノードが提供されてもよい。Ｍノードは、トランザクションの高速伝搬に焦点を当てるように設計される。それらは、ブロックチェーン全体を格納してもよいし、しなくてもよく、また、マイニング機能は実行しない。その意味で、それらは軽量なノード又はウォレットに類似するが、それらは、トランザクションの高速伝搬を可能にするという追加の機能を含む。Ｍノードの動作上の焦点は、特に他のＭノードへの、未承認トランザクションの迅速な検証及び伝搬であり、それら他のＭノードから、それら未承認トランザクションがブロックチェーンネットワーク内の他のノードへと迅速に押し出される。この機能を容易にするために、Ｍノードは、さもなければ管理プロトコル下のノードに対して許可され得るものであるいっそう多くの着信コネクション及び特には発信コネクションを許可される。

これらＭノードは集合的に、マーチャントネットワーク（又は“Ｍ−ｎｅｔ”（“Ｍネット”））として参照されることがある。用語“マーチャント”は、“特化された”を意味するとして解釈されてもよい。Ｍノードは、ブロックチェーンネットワークに統合され得る。各Ｍノードは、それがＭノードの機能を実行できることを保証することになる一定のハードウェア能力及びパフォーマンス能力を満たした、ブロックチェーンネットワーク上の特化されたノードである。すなわち、Ｍネットは、ブロックチェーンネットワーク内であちこちに分散されたサブネットワークと見なされ得る。（１つ以上の）Ｍノードが、１つ以上の専用の機能又はサービスを実行するように構成及び設定され得る。

Ｍネットが信頼性をもって動作して、ある一定のセキュリティレベルでサービスを提供することができるためには、ＭノードがＭネット全体の良好な通覧を維持する必要があり、従って、効率的なルーティングプロトコルが整備されている必要がある。Ｍノードが開始トランザクションを受信するたびに、そのＭモードはそのトランザクションを、幾つかの他のＭノードと他のノードとにブロードキャストする必要がある。Ｍネットの文脈において、これは、複数巡回セールスマン問題（multiple traveling salesman problem；ＭＴＳＰ）に対する解を見つけるということになる。この問題に取り組むソリューションは多すぎるほどあり、それらのうちのいずれか１つがＭネットで採用され得る。Ｍノードは各々、何らかの最新の形態のルーティング最適化を走らせる。

一部の実装において、Ｍネットは、非中央集権的なＩＰマルチキャストタイプのネットワークとして実装される。すなわち、ブロックチェーンネットワークへの着信トランザクションの高速拡散を可能にするために、マルチキャストを用いて、トランザクションがＭネット中に迅速にブロードキャストされることを保証することができ、全てのＭノードが、次いで、ブロックチェーンネットワーク内の他のノードにトランザクションを転送することに集中することを可能にする。

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

例えばビットコインなどの一部のブロックチェーンネットワークは、ノード間通信にＴＣＰを使用している。ＴＣＰを用いて送られるデータパケットは、順序付けの目的で使用される関連シーケンス番号を有する。これに加えて、ＴＣＰプロトコルは、コネクションを確立する時とコネクションを終了させる時との双方で、３方向ハンドシェイク手順を伴う。ＴＣＰ上で送られるパケットは関連するオーバーヘッドを伴い、それらはシーケンス番号を付随し、また、３方向ハンドシェイクプロトコルが存在する。コネクションを確立する際には１２８−１３６バイトが送信されているが、コネクションを閉じることは１６０バイトをかける。従って、パケット伝送におけるハンドシェイクは、最大で２９６バイトをかける。さらに、ノードが新たなトランザクションを受信するとき、そのノードは他のノードに、トランザクションのハッシュを含むインベントリメッセージ（ＩＮＶ）を通知する。ＩＮＶメッセージを受信するノードは、そのトランザクションのハッシュが以前に見たことがあるものであるかをチェックし、そうでない場合、そのノードはＧＥＴＤＡＴＡメッセージを送信することによって、そのトランザクションを要求することになる。ノードＡからノードＢにトランザクションを伝送するのに必要な時間は、Ｔ１＝ｖｅｒｉｆｉｃａｔｉｏｎ＋ＴＣＰ（ｉｎｖ＋ｇｅｔｄａｔａ＋ｔｘ）であり、ここで、ＴＣＰ（）は、ＴＣＰハンドシェイク手順によって導入されるオーバーヘッドを時間に関して示す。

Ｍノードは、他のノードとの通信のためにＴＣＰを使用するように構成されることができ、これは、ビットコインのような既存のプロトコルによって強制されている。しかしながら、それらは、ＭノードからＭノードへの通信のために、あるいは、より好適には、マルチキャストの状況においてＭノードから複数のＭノードへの通信のために、ユーザデータグラムプロトコル（User Datagram Protocol；ＵＤＰ）のようなコネクションレスプロトコルを使用してもよい。ＴＣＰとは異なり、ＵＤＰはハンドシェイクプロトコルを伴わず、故に、Ｍノードはより迅速にトランザクションを伝搬することができる。これはまた、実際のトランザクションを一度も送ることなく、繰り返しのＩＮＶメッセージを送ることによって、悪意のあるノードが他のノードを結びつけることを回避することができる。

ＵＤＰの軽量性は、ある一定のトレードオフと関連付けられる。存在するエラーチェックが少なく、また、エラー回復は存在しない。一部の実装において、ＵＤＰのこれらの制約は、アプリケーション層の機能としてエラー回復、順序付け、及び再送信を実装することを通じて、アプリケーションレベルで克服されることができる。アプリケーションレベルにエラーチェックを置くことは、ネットワークからオーバーヘッドを取り除く。

一状況例において、ブロックチェーンネットワーク上の通常のノードが、例えばマーチャントベースの支払いなどの、Ｍネットを介して処理されることを望むトランザクションを生成する。そのノードは、そのトランザクションをＭノードに送信し、そして、そのＭモードがマルチキャストを用いてそれを他のＭノードにブロードキャストしてもよいし、あるいは、そのノードがＭノードのＩＰマルチキャストアドレスを知っている場合には、そのトランザクションを直接的に複数のＭノードに送信してもよい。一部の例では、Ｍネットの全てのＭノードが単一のマルチキャストアドレスのメンバーであり、故に、そのアドレスに送信される全てのトランザクションが全てのＭノードによって受信されるが、一部のケースでは、Ｍネットに関連付けられた２つ以上のマルチキャストアドレスが存在することがあり、受信したＭノードが、そのトランザクションをＭネット全体に伝搬させるために他のマルチキャストアドレスへのトランザクションの更なるブロードキャストが必要であるかを、ルーティング情報から評価し得る。

マルチキャストは、新たなトランザクションの全てのＭノードへ高速な初期伝搬を確実にするのを支援するが、マルチキャストソリューションは、高まるトランザクションスループットに由来するブロックチェーンネットワークのスケーラビリティ問題に必ずしも対応しない。典型的に、ネットワーク内の各ノードが、自身が見た、マイナーがプローフオブワーク（proof-of-work）を完了することによってブロックチェーンに組み込まれることが未だ済んでいない未承認のトランザクション、を含むメンプール（mempool）を維持している。支払処理での使用から生じるトランザクションの数における大きい成長は、各メンプールに格納するトランザクションの量を増加させる。従って、Ｍネット内のノードは、ほぼ同時に新たなトランザクションを受信することができるものの、それらは、大きくて速く変化するメンプールに関するストレージ能力制限を有し得る。

この問題に対処するために、Ｍノードは、マルチキャストを使用することに代わるものとして、分散ハッシュテーブル（Distributed Hash Table；ＤＨＴ）によって実装された共有メンプールを使用し得る。

５００バイトなるトランザクション（ＴＸ）の平均サイズと、〜１０^４ＴＸ／ｓなるトランザクションレートとを仮定すると、Ｍネットは、１日当たり〜４００ＧＢの着信データを受信することになり得る。この全てのデータが、未承認トランザクションのメンプールに可変量の時間にわたって保存される必要がある。従って、Ｍネットは、かなりのストレージと、データを高速に格納する能力とを必要とする。個々のＭノード各々に過大な要求を課さないために、Ｍノードは、ＤＨＴに頼った共有メモリを実装する。各Ｍノードに全ての着信ＴＸをそれ自身のメンプールに保持させる代わりに、各Ｍノードが、全体のうちの特定の割合と、残りの部分のハッシュ及び関連するキー値のみを保存する。

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

同じ概念が、ブロックチェーン上の全ての未使用アウトプットのセットを含むデータベースであるＵＴＸＯデータベースに適用され得る。ＵＴＸＯデータベースは、ノードのセット間でコンテンツを共有するためにＤＨＴを用いて構築され得る。

Ｍネット用の共有メンプールを実装するのに使用され得る数多くの可能なＤＨＴアーキテクチャ及びプロトコルが存在している。１つの例はＰａｓｔｒｙ（ＴＭ）であるが、他にも数多く存在する。Ｐａｓｔｒｙ（ＴＭ）は、分散システム上で情報を保管及び移転することができるオーバレイネットワークを維持するために設計されたプロトコルである。Ｐａｓｔｒｙ（ＴＭ）ネットワーク内の各ノードは、１２８ビットの識別子を割り当てられ、それを用いて、（０から２^１２８−１までの範囲の）円形のノードＩＤ空間内でのノード位置が指し示される。ＩＤは、ノードがネットワークに参加するときにランダムに割り当てられる。各ノードが、ルーティングテーブル、近隣（ネイバーフッド）セット、及びリーフセットを維持する。

ロバストなＤＨＴをサイズ決定する際に考慮すべき１つのファクタは、ネットワーク全体の堅牢性及び信頼性を保証するために必要とされるレプリカの数である。既に述べたように、複数のノードがネットワークに対して参加及び離脱することができ、このことが、データの可用性に影響を与えるべきでない。トランザクションＡを格納しているノードがネットワークを離脱する場合、ネットワークの別の部分でトランザクションＡを見つける必要がある。例えばビットコインのような既存のブロックチェーンネットワークでは、ネットワークが、ネットワーク内の全ノードの数に等しい数のブロックチェーンレプリカ（平均で５０００レプリカ）を有するが、このことがスケーラビリティに影響を及ぼす。

Ｍネットの一構成では、全てのＭノードでメンプールが完全に複製されるわけではなく、代わりにＤＨＴによって実装される。信頼性を提供するために、ＤＨＴは、幾らかの重複を有するように実装されることができ、すなわち、各トランザクションデータアイテムが、全てのＭノードではないが、２つ以上のＭノードに複製される。一例として、ＤＨＴは、最小で２個のレプリカを指定するように実装され得る。これは、ある確率で２つのノードが任意の所与の１時間以内で同時にダウンすることをもたらし、該確率は、ノード間の完全なる独立性を仮定して、（１／（２４×３６５））^２＝１３０×１０^−８となる。

新たなトランザクションを分散メンプールに格納するプロセスは、故に、ＤＨＴを用いて分散メンプールが実装される以下のステップを有し得る。そのプロセスは、ノードがＭノードにトランザクションを送信することを含む。Ｍノードが、実装に応じてトランザクション又はトランザクションＩＤをハッシュして、キー値を取得する。キー値は、トランザクションが格納されるべきＭノード又は複数のＭノード（複製データの場合）を指し示す。次いで、Ｍノードがトランザクションを分散メンプールに格納し、これは、キー値とＭネット内のＭノードの割当てＩＤとに基づいて、トランザクションが格納されるべき正しい（１つ以上の）Ｍノードにトランザクションをルーティングすることを含む。Ｍノードは、関与するＤＨＴプロトコルに応じてアクナリッジメントを受信し得る。Ｍノードが通常ノードから新たなトランザクションを受信するとき、Ｍノードはトランザクションの真正性を検証するために特定の検証演算を実行し得る。

トランザクションがハッシュされることで、トランザクションのキーが生成され得る。キーは、ＤＨＴ内のどこにトランザクションが格納されるべきかを指し示すことができ、それは、現在のＭノード以外のノードであり得る。Ｍノードは、次いで、そのトランザクションが動作中のＤＨＴ内に既にあるかを評価する。各Ｍノードが、Ｍネットを構成するＭノードの間でのキー空間の分割に基づいて、格納されたトランザクションの一部を有する。一部の構成において、キー空間は、参加しているＭノードの間で分割される。分割は、ネットワークの弾力性のために複製を生じさせるように重複を伴い得る。例えばＰａｓｔｒｙ（ＴＭ）を使用するなどの一部の実装では、各Ｍノードに固有のキー又はＩＤ番号が割り当てられ、トランザクションは、トランザクションのキー値に対する近接性に基づいて、Ｍノード又は複数のＭノード（複製が望まれる場合）に格納され得る。Ｍノードは、トランザクションの格納部分をローカルに有し得るとともに、残りの部分のハッシュ又はキー値を有し得る。従って、Ｍノードは、動作中にローカルデータに基づいて、新たなトランザクションがＤＨＴ内にあるかを評価することができ得る。

そのトランザクションがＤＨＴ内にない場合、Ｍノードは、動作中に、そのキー値に基づいて、トランザクションをＤＨＴに格納する。一般的な意味において、これは、ｐｕｔ（ｋ，ｔｘ）演算の形態をとることができ、ここで、ｋはキー値であり、ｔｘはトランザクションである。適用可能なＤＨＴルーティングプロトコルが、トランザクションが適切な（１つ以上の）Ｍノードに送られて、それに格納されることを保証する。ＤＨＴは、選択された実装に応じて、分散ハッシュテーブルに関する様々なプロトコルに従って動作し得る。Ｍネットにトランザクションを格納するためのＤＨＴの使用は、全てのＭノードにトランザクションをルーティングするためのＭネット内でのＩＮＶ／ＧＥＴＤＡＴＡメッセージの使用を回避する。

動作において、Ｍノードは、この例では、ブロックチェーンネットワークの通常のトランザクション転送プロトコルに従って、ブロックチェーンネットワーク内の通常ノードにトランザクションを送信し得る。例えば、通常ノードへの通信は、ノード間コネクションのためにＴＣＰを使用し得る。

一構成において、Ｍノードは、プロセッサ、ネットワークインタフェース、及びメモリを含む。Ｍノードは、ネットワーク接続性と、ここに記載される機能を実行するのに十分なプロセッシングリソース及びメモリリソースとを有する任意の好適なコンピューティングハードウェアを用いて実装され得る。Ｍノードは、ここに記載される機能を実装するためのプロセッサ実行可能命令を含み得る。一部のケースにおいて、プロセッサ実行可能命令はブロックチェーンマーチャントノードアプリケーションとして参照され得るが、理解されることには、これらの命令は、ハードウェア及びオペレーティングシステムに応じて、１つ以上のモジュール、アプリケーション、スクリプト、又は他のプログラミング構造にて実装され得る。プロセッサは、マルチコアプロセッサ及び／又は複数のプロセッサを含み得る。

メモリは、そのＤＨＴキー値すなわちＭノードＩＤに部分的に基づいたＤＨＴベースのメンプールの割当て部分を含むデータを格納する。この実装例では、メモリは更に、ルーティングテーブル、近隣セット、リーフセットを格納する。ルーティングテーブルは、Ｍネット内の特定のルーティング宛先のリストを含み、ノードがデータのパケットを受信するとき、そのノードは、そのデータをどこに送信すべきかを知るためにルーティングテーブルを参照する。ルーティングテーブルはまた、各宛先がそのＭノードからどれだけ離れているかについての情報を含み得る。近隣セットは、例えば近接性メトリック（ピングレイテンシ）に基づいた近いＭノードに関する情報を含む。リーフセットは、数値的に近いＭノードを含む。Ｍノード同士が数値的に近いとは、それらのキー値（ノードＩＤ）が数値的に近い場合である。メモリは、以下で更に説明されるように、Ｍノード評判（レピュテーション）テーブルを更に含む。

スケーラビリティを提供するために、ＤＨＴを使用してメンプールを実装することに加えて、Ｍ−ｎｅｔは、ノードがＭネットに参加することを可能にする。新たなノードは、その参加要求をＭノードのうちの１つに向けることができるよう、既にＭネットの一部である少なくとも１つのＭノードのアドレスを持つ必要がある。Ｍノードは、新たなノードに照会することを伴い得るものである特定の検証アクションを実行し得る。例えば、Ｍネットは、Ｍノードに対して規定した、Ｍネットに参加することに関連した一組の最低基準を有し得る。例示として、その基準は、利用可能な最低プロセッシングリソース、又は利用可能な最低空きメモリ、又は接続性要件を含み得る。

新たなノードを検証するために実行される何らかの検証演算をＭノードが完了したと仮定して、Ｍノードは、次いで、ＤＨＴの動作を支配する何らかのＤＨＴプロトコルに従って、ｊｏｉｎｒｅｑｕｅｓｔ（）をＤＨＴに転送する。次いで、ＤＨＴが新たなノードと通信して、それに、ルーティングテーブル、キー値（ノードＩＤ）、及び該新たなノードがＭネット上の新たなＭノードとして機能することを可能にするその他のデータを提供する。

理解されることには、ノードがＭネットに参加することができる容易さは、悪意あるノードがネットワークに参加してしまい得るという脆弱性を生み出す。潜在的な悪意あるノードを特定して隔離するために、一構成は、ノード挙動ランキングを追跡及び更新するために使用されるＭノード評判テーブルをＭノードが格納することを提供する。新たなノードがネットワークに参加するとき、ノードＩＤフィールドによって示されるように、そのノードがＭノード評判テーブルに追加され得る。このテーブルは、一部の実装において、参加時間を更に含み得る。このテーブルは更に、そのＭノードに関するスコア又は評価を含む。

スコアは、特定の挙動メトリックに基づいて上下に調整され得る。例えば、Ｍノードがトランザクションの転送に失敗したり、ある期間にわたってサイレントのままであったり、トランザクションではないと判定されるトラフィックでＭネットを溢れさせたり、又はこれら以外で否定的挙動に携わったりする場合、そのランキングは低下又は減少させられ得る。ノードのスコアが予め設定された最低値を下回ると、そのノードはＭネットから排除され得る。

特定のＭノードで維持管理されるＭノード評判テーブルは、Ｍネット全体ではなく、その近隣者のスコアを追跡することに限られてもよい。従って、新たなＭノードが時点ｔにネットワークに参加する時には、その近隣者のＭノード評判テーブルは、新たなノードについて如何なる情報も含んでいないが、時点ｔから、それらは、ノードレジスタテーブルに情報を格納して、新たなノードの評判を築き始める。例えば、新たなノードがサイレントノードである場合、すなわち、それがネットワーク上で受け取る情報を転送しない場合、全ての隣接者が、この挙動をそれらそれぞれのＭノード評判テーブルに記録し始め、例えば、新たなノードのＩＤに否定的な値を割り当てる。ある特定の時間ｔ＋ｎの後に、新たなノードに気付いている全てのノードのＭノード評判テーブルが否定的な値を含んでいる場合、それらのノードは、新たなノードを隔離してそれをネットワークから追放することを決定し得る。

Ｍネットの分散メンプール内のトランザクションは、承認される前に、すなわち、ブロックチェーンに追加されるブロックに組み込まれて承認される前に、かなりの期間待つことがある。ブロックが“承認された”と見なされるのは、その上でブロックチェーンに十分な数の後続ブロックが追加され、その結果、異なる分岐すなわちフォークに変えるためにチェーンの成長を逆転させてそのブロックを除去することが計算的に実現困難になったときである。

メンプールのサイズ及び柔軟性とトランザクションの量とのために、所与のトランザクションが、ビットコインのような一部のブロックチェーン実装においてよりも長きにわたって承認されないことがあり得る。従来のビットコイン実装では、トランザクションは、それがブロックへと組み込まれるとすぐにメンプールから除去される。これは、ブロックが最終的にオーファンブロックになった場合に、ブロック内の全てのトランザクションがネットワーク上で再送されることを意味する。これは、実現困難であったり、高速トランザクションネットワークの場合に特定のトランザクションを承認するのに長い遅延を生じさせたりし得る。

従って、一部の実装において、メンプールは、トランザクションが組み込まれたブロックの承認の数、すなわち、トランザクションが組み込まれたブロックに続いてブロックチェーンに追加されたブロックの数を追跡し得る。所定数の承認が行われた後にのみ、メンプールからトランザクションが削除される。この所定数は、４、５、６、７、又は所与の実装での任意の好適数とし得る。メンプールのデータエントリは、トランザクションＩＤフィールド、トランザクションフィールド、及び承認数（number of confirmations；ＮｏＣ）フィールドを含むように構造化され得る。他の一実装では、ＮｏＣを追跡するのではなく、メンプールデータエントリが単にブロック番号を記録してもよい。ブロック番号から、ブロックチェーンの現在のブロック番号に基づいて、何回の承認が行われたかを算定することができる。

必要数の承認が行われると、メンプールから安全にトランザクションが削除され得る。斯くして、オーファンブロックの場合のトランザクションロスが存在せず、トランザクションは、必要数の承認の後に永久に除去されることになる。

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

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

ブロックヘッダは：
１．バージョン番号（４バイト）
２．先行ブロックヘッダのハッシュ（３２バイト）
３．マークルルートハッシュ（３２バイト）
４．時間（４バイト）
５．ターゲット閾値（ｎＢｉｔｓ−４バイトとしてエンコード）
６．ナンス（４バイト）
を含む。

現在、ブロックはおよそ２０００のトランザクションを含み、およそ１０分ごとにブロックがマイニングされている（１０分というブロック時間は、最初の承認時間とチェーン分裂で無駄になる時間との間の妥協として設定されたものである）。これは、毎秒７トランザクションという理論上の最大値に対し、毎秒およそ３．５トランザクションというトランザクションレートを提供する。対照的に、ＶＩＳＡは毎秒およそ１００００トランザクションというレートで動作し、毎秒５００００＋のトランザクションに達することができる。

明らかなことには、競争力のある決済システムを作り出すためには、現在の制約を何らかの方法で迂回することが必要となる。１０分というブロック時間は十分に確立されているので、ブロックサイズ、ひいては、ブロックチェーン自体への変更を検討することが必須である。本明細書にて、例えば毎秒およそ５００００トランザクションを扱うことができるであろうスケーラブルなソリューションが記述される。

現行ブロックサイズへの増分、又は更には制限の完全なる除去が、多く議論され、時々、論争を巻き起こす話題となっている。現行サイズを保つこと及びそれを増加させることの双方が大きい利益とトレードオフとを有するので、どちらの側にも強い議論があるようである。

トランザクションレートｒを仮定して、必要なブロックサイズを計算することができる。以下では、（平均）１０分のブロック時間を仮定する。従って、Ｔ（ｒ）をブロック当たりのトランザクションの数とすると、

となる。ｓ_Ｔｘが平均トランザクションサイズであるとすると、ブロックサイズＢ（ｒ，ｓ_Ｔｘ）は

として表されることができる。従って、ｒ＝５００００Ｔｘｓ／ｓ＝５００バイトである状況を考えると、手早く簡単に算出できる計算により、

となる。

これは、代わって、Ｏ（１０^６）Ｇｂ／年というストレージ要件につながる。とても明らかなことには、このサイズのブロックでは、ブロック伝搬とストレージとの双方に対して僅かに異なるアプローチが必要である。以下の表１は、トランザクションレート、平均トランザクションサイズ、ブロックサイズ、及び必要な月次及び年次のストレージ空間の量の間の関係を示している。

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

特別な複数の検証ノード（分散ハッシュテーブルＤＨＴによってそれらの間で共有メモリを維持管理する）がトランザクションを受信し、それらを検証し、そして、それらをメンプールに割り当てるシステムが提供される。そして、それら検証ノードは、有効なトランザクションハッシュのリストを提供することであるそれらのサービスをマイナーに提供する。マイナーが、それらのハッシュに基づいてプレブロック（ブロックスケルトン）を組み立て、ハッシュパズルを解くことを試みる。パズルの解が見つかったとき、勝ったマイナーがブロックスケルトンを検証ノードに送り返す。これらは、ブロックを検証し、それが格納されることを保証する。当初、検証ノードがそれら自身でブロックを格納することが可能であり且つ適当であろう。ブロックサイズが最終的に、サイズにおける特定の閾値を超えると、検証ノードは、ａ）それら自身のストレージ能力を拡張する、又はｂ）特殊化されたストレージノードに格納をアウトソーシングする、のいずれかを行うことになる。これら２つのアーキテクチャが、本明細書中で後述される。

新しいフルノード
Ｏ（１０）ＧＢオーダーのブロックサイズでは、ブロックチェーンの全体像をホストするためのストレージ容量を提供することをＰＣタイプのノードに頼ることは、もはや実現可能でないように思われる。それに代えて、Ｏ（１）ＰＢ又はそれより多くのストレージを提供する施設が必要となる（表１参照）。その場合、ネットワークの分散され、非中央集権的で、ノートラストな性質を保持しながら、新たなブロックを収容するシステムを作り出すことが難題となる。

２つのタイプのフルノード構造と、それら２つのタイプの組み合わせとが考えられる。

１． 付随したペタバイトストレージラックを備えた検証ノード
２． 現行のビットコインネットワークそれ自体とよく似た、内部非中央集権的な分散ピア・ツー・ピア（Ｐ２Ｐ）単一ノードネットワークに基づいた、付随したストレージプールを備えた検証ノード
３． １と２との組み合わせ。

提案するソリューションは、今日のビットコインネットワーク上で動作している所謂フルノードに似たノードを導入することによって、常時、ブロックチェーンの分散された非中央集権的な記録を保つという問題を解決しようと試みるが、対照的に、ブロックのサイズ及びトランザクションの数の成長とともにスケーリングする能力を有する。

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

範囲内の対極にて、我々は、大部分が個々のノードで構成される非中央集権的な分散ストレージソリューションを有する。良い例は、Ｓｔｏｒｊ（Ｗｉｌｋｉｎｓｏｎ等、２０１６年）、Ｓｉａ（ＮｅｂｕｌｏｕｓＬａｂｓ）及びＭａｉｄＳａｆｅ（ｍａｉｄｓａｆｅ）である。Ｓｔｏｒｊの場合、その機能は、参加者がストレージ空間を提供することに対して報酬を得ることに基づく。

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

ビットコインエコシステムは、非中央集権的なやり方で分布されたブロックチェーン全体の複数のレプリカの存在に大きく頼っているので、全てのフルノードが補償されることが重要であることが明らかになる。これは、基本的に勝者が全賞金を獲得するゲームであるマイニングとは大きく異なる。マイナーは、公開ブロックチェーンに行き着くために自身の（勝った）ブロックを当てすることになるので、フルノードを格納することに報いることがマイナーの利益となる。

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

技術的要件
述べたように、新しいフルノードを議論する際に検討すべき２つの全体的に異なるアーキテクチャが存在する（表２参照）。

新しいフルノードは、２つのタイプのストレージ：
１） メンプール用のランダムアクセスメモリ（ＲＡＭ）のような分散ハッシュテーブル（ＤＨＴ）メモリ／ストレージ、
２） ブロックチェーン用の永続的なテープ／ディスクのようなストレージ、
を維持管理する必要がある。

述べたように、トランザクションレートｒ＝５００００Ｔｘ／ｓでは、ブロックがＯ（１０）Ｇｂになると期待され、これは、〜３６５×２４×６×１５Ｇｂ＝７．９・１０^５Ｇｂ＝０．８Ｐｂ／年という年間ストレージ要求を意味する（表１参照）。

表２は、現行のフルノードと将来のフルノードとの間の比較を示している。

同時に、ラック／クラスタはメンプールを維持管理する必要がある。これは、素早いブロック復元を可能にすることになる。メンプールの必要サイズは、算定するのがより困難である。現在、およそ１メガバイト（〜１Ｍｂ）のブロックサイズ及び毎秒およそ４トランザクション（〜４Ｔｘ／ｓ）で、メンプール内で待っているトランザクションの合計サイズは、２とおよそ７０メガバイト（〜７０Ｍｂ）との間で振動する。図３は、承認のためにメンプールで待機しているトランザクションの合計サイズを示すグラフである。

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

新しいフルノードがビットコインネットワークにどのように適合するかを可視化する１つの方法が、検証ノードがストレージプールのメンバーであるネットワーク構成を示した図６に示されている。これらのプールが一緒になって、非中央集権的な分散ビットコインネットワークを有する。

フルノード動作
大きいブロックのシナリオでは、単に空間要求のためではなく、別の状況に直面する。メンプールは、ブロックの等価量、すなわち、およそ１５ギガバイト（〜１５Ｇｂ）、好ましくは、次にマイニングされるブロックの等価量を受け入れることができるべきである。これが、対処される必要のあるオーバーヘッドとも組み合わされる。

１）メンプールは、他の検証ノードと同期する必要がある。これは、可逆ブルームルックアップテーブル（Invertible Bloom filter Lookup Table；ＩＢＬＴ）を交換することを伴う（Ｍｉｃｈａｅｌ Ｔ． Ｇｏｏｄｒｉｃｈ，２０１１）
２）ＩＢＬＴは精査される必要があり、欠落トランザクション（Ｔｘ）が検索される
３）追加で検索されたＴｘは検証される必要がある
４）マイナー又は他のフルノードから受信したブロックスケルトンに基づくブロックの組み立て。

新しいフルノードは、最新のメンプールを保つ。それは、マイナー並びに他の検証ノード及び新フルノードと交換したＩＢＬＴによってそれを行う。

マイナーは、
１． ナンスｎ
２． ＩＢＬＴ
３． コインベーストランザクション
で構成されるブロックスケルトン（タプル）を送信する。

これに基づいて、新しいフルノードは、（特定のルールセットに従って）トランザクションを然るべく順序付け、新たにマイニングされたブロックを組み立てる。新しいフルノードは、次いで、それら自身のストレージにブロックを格納することと、他の新しいフルノードにスケルトンを伝搬させることとに進む。プロトコルについては、より詳細に本明細書中で後述する。

インセンティブ
特定の構成の１つの重要な特徴は、新しいノード構造及びサービスの提供を奨励するインセンティブをシステムに組み込むことである。ブロックチェーンを格納することに伴うかなりのコストのため、インセンティブが必要となる。図７は、新しいフルノードの機能を示している。新しいフルノードは、主に以下の２つのタイプのサービスに対して報酬を受ける：
１）検証済みトランザクションのリストを編集し、マイニングの準備を整える。そして、トランザクションのハッシュ値（マークルルート）が、リストを選択してブロックをマイニングするマイナーに送られる；
２）勝ったマイナーが、マイニングしたブロックのスケルトンを幾つかの新しいフルノードに送信する。スケルトンは、以下を含むものであるコインベーストランザクションを含む：
ａ． マイニング報酬
ｂ． 検証済みリストを提供するための支払いメカニズムとして使用されるコミットメントスキームの一部である秘密
ｃ． ブロックチェーン上のブロックのブロック検証及び／又は保管に対する支払い。

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

インセンティブは、１００ブロックの承認時間Ｔ_１００にある：
１）マイナーは、報酬を要求するためにｔ〜Ｔ_１００にわたって待つ必要がある
２）検証ノードは、ブロック内のＴｘを検証することについての料金を受け取る前に、ｔ〜Ｔ_１００にわたって待つ必要がある
３）新しいフルノードは、ブロック組み立て料金及びサイズ依存ストレージ支払を受け取る前に、ｔ〜Ｔ_１００にわたって待つ必要がある。

従って、１００ブロック承認時間が、マイナーがスケルトンブロック（支払いを含む）を、ある範囲の新しいフルノードに伝搬させるのに必要なインセンティブを与えることになり、新しいフルノードは、スケルトンブロックを他の新しいフルノードに伝搬させるインセンティブを受けることになる。

また、指摘しておくべきことには、マイナーは、ブロックに含めることを望む（トランザクションの）リストを自由に選択できる。従って、我々は、マイナーがコミットメントトランザクションから選択してそれらによって購入することができる検証済みトランザクションのリストを編集することによって検証ノードが競争し合うことで構成されるマーケットを想定している。

マイニング再訪
ビットコインエコシステムは、マイニングのプロセスに頼っている。マイナーが、トランザクション（Ｔｘ）をメンプール（又は、ここで想定しているように、特殊化された検証ノード）から集め、それらをブロックへと編成し、ハッシュパズルを解く解（ナンス）を見つけることを試みる。ブロックヘッダが、ブロックチェーン上の先行ブロックのハッシュと、トランザクションのマークルツリーのルートと、マイナーによって含められるナンスとを含む。パズルを解くことは、先行ブロックハッシュ及びマークルルートと連結されたナンス（繰り返し選択される）の二重ＳＨＡ２５６ハッシュを計算し、それがいわゆる難易度ターゲットよりも小さいかをチェックすることからなる。それが下回る場合には、パズルは解かれており、上回る場合には、複数のナンスにわたってのイテレーションが続く。これは、新しいパラダイムにおいても変わらないままである。課題を課すのは、巨大化されたブロックサイズと、マイニングされたブロックのネットワークにわたる配信である。Ｇｂサイズのブロックでは、ブロック全体をネットワーク上でブロードキャストすることは必ずしも実現可能でないことになる。

その代わりに、我々は、以下のステップに従うソリューションを提案する：
１． マイナーが、検証／Ｍノード及び／又は新しいフルノードから、検証済みトランザクションのリストを受け取る
２． マイナー自身が、Ｔｘハッシュ値の自身のメンプールを運用してもよいし、運用しなくてもよく、それは特定の順序付け規則に従う。そのような順序付けの例は、［https://www.cryptocoinsnews.com/bitcoin-in-bloom-how-iblts-allow-bitcoin-scale/］にて与えられている
３． マイナーが、ナンスｎを決定することによってハッシュパズルを解く
４． 次に、ハッシュツリー（マークルツリー、ここではＨＴとして参照する）が計算され、格納されたツリーのルートが計算される（次のセクションを参照）
５． Ｔｘのこのリストを用いて、ＩＢＬＴが作成される。ＩＢＬＴは、２つのセット（例えば、メンプール）間の内容の差を計算するため、及び２つのセットを調整するために使用されることができる
６． タプル｛ｎ；ＩＢＬＴ；コインベースＴｘ；ＨＴルート｝が検証／Ｍノードにブロードキャストされる
７． 新しいフルノードが、メンプールのＤＨＴ及びブロックチェーンのストレージを運用する
８． プールが、タプル｛ｎ；ＩＢＬＴ；コインベースＴｘ；ＨＴルート｝に基づいてブロックを組み立てなおし、ａ）それら自身でブロックを格納することによって、又はｂ）特殊化されたストレージノード上に格納することのいずれかによって、ブロックをブロックチェーン上に記録する。

マイナー間のレースの回避
マイナーは、幾つかの検証ノードで構成されるマーケットから、検証済みトランザクションのリストを選択できることになる。特に断りのない限り、マイナーは自身の潜在的収益を最大化するリストを選択すると仮定するのが公正である。注意深い読者は、このことが、マイナーが主に同じノードから同じリストを選ぶことにつながり得る、と指摘するかもしれない。これは、ひいては、何人かのマイナーが同じブロックをマイニングしようとして、互いにレースする状況になる。これは、ハッシュ力が最も大きい（一人以上の）マイナーに有利に働くであろう。

我々は、ブロックヘッダに追加のフィールドを付加することを提案する。このフィールドは、各マイナーによって選択された乱数を含む。これは、各マイナーが異なる開始点から始めることを保証し、従って、そのブロックを解くことが単にハッシュ力に行き着くことを防止することになる。これは、ひいては、マイナーが、同様であるが個々に選んだ僅かに異なるブロックをマイニングする傾向がある現在の状況を模倣することになる。

プロトコル
ここで、新しいフルノードを動作させるために必要なプロトコルを説明する。

提案するシステムが機能するために、関与するノード（バリデータ、マイナー、新しいフルノード）のメンプールは、トランザクションに関する順序付け規則に従うべきである。ここで、我々は、Ｇａｖｉｎ Ａｎｄｒｅｓｅｎによって提案された正準（カノニカル）順序付けを使用することを提案する。そこでは、順序付けはブロック内のトランザクションのリストに関係していたが、ここでは、我々は、全ての検証ノード及び新しいフルノードがそれらのメンプールに同じ規則を使用するという考えを提示する。

その規則は、以下のように要約されることができる：
１）トランザクションを先行トランザクションハッシュに対して昇順に並べ替える
２）ソート済みリストから、後のトランザクションに依存しない最初のトランザクションを追加する。

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

ここで、我々は、ある手順によって以下のようにして計算されるマークルツリーを提案する：
検証ノードが、リトルマークルルート（Little Merkle Root）を計算する。この手順は、幾つかの例外：
１）コインベーストランザクションは省略される
２）所謂コミットメントトランザクションが含まれる
３）マイナーは、コインベーストランザクションを生成し、それをリトルマークルルートハッシュと連結し、それがマークルルートハッシュを生み出す
を除いて、標準的なマークルルートを計算する場合と同じである。

これを、新しいマークルツリー構造を例示する図８に示す。なお、これは、現行プロトコルへの変更を構成する。

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

我々は、故に、マイニングされた新たなブロックのブロックヘッダが、乱数を含む追加フィールドで強化されることを提案する。ブロックヘッダは、以下を含むことになる：
１．バージョン番号（４バイト）
２．先行ブロックヘッダのハッシュ（３２バイト）
３．マークルルートハッシュ（３２バイト）
４．時間（４バイト）
５．ターゲット閾値（ｎＢｉｔｓ−４バイトとしてエンコード）
６．ナンス（４バイト）
７．乱数（４バイト）。

検証→マイナー
検証ノード：
・ 要求を受けて、検証ノード（新しいフルノードであってもよいし、そうでなくてもよい）は、マイニングされるべき検証済みトランザクションのリストを用意する；
・ 検証ノードは、コミットメントトランザクションを作成する；
・ コミットメントトランザクションを含めて、所謂リトルマークルルート（前のサブセクションを参照）が計算される；
・ 検証ノードは、２つのＩＢＬＴ：
１）ブロック内の全てのトランザクションについて（ＩＢＬＴ１）、及び
２）ブロック内の全ての対応するＴｘＩＤについて（ＩＢＬＴ２）
を用意する；
・ 検証ノードは、マイナーに：
１）リトルマークルルート
２）ＩＢＬＴ１
３）ＩＢＬＴ２（オプション−マイナーが自身のＴｘＩＤ／メンプールで動作する場合のみ）
４）先行ブロックハッシュ
５）以上のもののハッシュチェックサム
を送信する。

マイナー：
・ 検証ノードからのデータの受信を受けて、マイナーはコインベーストランザクションを作成することに進む。コインベーストランザクションは、マイニングに対する報酬と、マイニングしたブロックを送りたい新しいフルノードのブロック検証／ストレージに対する報酬とを含む。さらに、コインベーストランザクションは、コミットメントトランザクション内の秘密と合致する秘密を有する出力フィールドを含む；
・ マイナーは、検証ノードから受信したリトルマークルルートを使用し、マークルルートハッシュを作成するために、それをコインベーストランザクションと結合する；
・ マイナーは、もはや、ハッシュパズルを解き始めるのに必要な全ての情報を有する；
・ 先述の線に沿ってマイニングが進む。

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

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

カスタマイズされたトランザクションリスト
我々は、検証済みトランザクションのマーケットがマイナーのニーズに適応することとなる状況を想定している。マイナーは、自身の可能性を最大化するリストを選ぶ傾向にあり、検証しているＭノードは、そのような傾向を捕えている。

マイナーが２つ以上のリストからのトランザクションを結合することによって自身のブロックをカスタマイズすることを望むかもしれない場合が存在し得る。２つのＩＢＬＴ間の差を計算することによって、２つのセット間の設定調整を行うことが可能である。マイナーは、次いで、差を含むＩＢＬＴを提供元のノードのうちの１つに送り返し、斯くして、双方のリストの全てのトランザクションを含むリストを作成するのに必要な情報を取り出す。

マイナーが幾つかのリストに基づいてそれ自身のリストを編集することを望む場合、更なる難題が導入されると思われる。ここで、我々は、様々な点について手短に述べる。

マイナーが様々な検証ノードからのリストを組み合わせるとした場合、マークルルートをどのように結合すべきかが不明である。ここで、我々は、以下を提案する：
個々のリトルマークルルートのビッグリトルマークルルートを構築し、そして、
ビッグリトルマークルルートをコインベーストランザクションと結合する。

追加費用は、リスト／ブロックに追加されるトランザクションの量に比例しない。それら様々なメンプールはかなり重複していると仮定するのが公正であるから、リストを結合することは、異なるリストからの（相対的に言って）少数のトランザクションを追加することになる。しかし、リストを結合するために、マイナーは、各検証ノードから（コミットメントトランザクションによって）リスト全体を“購入”しなければならないことになる。これがマイナーにとって有益なアプローチとなるかは、現時点では不明である。

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

ノードの構造と動作の概要
今日のビットコインネットワークは、計算上の労力の点で、重度にマイニングを中心にしている。トランザクション量が大幅に増加すると、これは必ずしも実現可能になるとは限らない。本明細書に記述されるソリューションは、様々な作業を、然るべく特殊化されたノードに委ねることにつながり、マイナー自身もよりいっそう特殊化されたものとなる。検証済みトランザクションのリストを編集すること、ブロックスケルトンに基づいてブロックを再構築すること、及び保管することは、全て、かなりのリソースを必要とすることになる機能である。従って、ビットコインネットワークの構造が変化し、また、それにと共にインセンティブも変化すると予想される。我々は、本明細書中でそれらの問題を詳細に記述している。

本明細書にて紹介される要素は、以下を含む：
・ ここでは新しいフルノード又はスーパーノードと呼んでいる新しいタイプのノード構造であり、これは、検証Ｍノードに対する拡張であってもよいし、そうでなくてもよい：
・ ノードが、検証ノードからマイナーへ及びマイナーから新しいフルノードへの双方でのＧｂサイズのブロックのブロードキャストを効果的に可能にするプロトコルで動作する；
・ ブロックチェーンを格納するための２つの全体的ストレージ構造であり、これは、提案する新しいフルノードの一部であってもよいし、そうでなくてもよい；
・ 検証済みトランザクションのプレブロックリストのマーケットの創造と、マイニング後のブロック組み立て及び保管とを可能にするインセンティブモデル；
・ それ自身のメンプールを維持管理する必要からマイナーを解放する新しいマークルツリー構造；
・ マイニングの行為が純粋にハッシュ力に基づくレースになることを回避するための、マイナーによって選択される乱数を有した、ブロックヘッダ内の追加フィールドの追加；
・ 検証が、特別なコミットメントトランザクションを用いて報酬を受ける。

一実装によれば、ブロックチェーンネットワークのノード用のコンピュータ実装された法が提供され、当該コンピュータ実装された方法は、
複数の検証済みトランザクションに対応するマイニングされたデータをブロックチェーンネットワークから受信し、
前記マイニングされたデータに基づいてブロックを組み立て、そして、
組み立てたブロックをブロックチェーン上の格納用のストレージエンティティに送信する、
ことを有する。

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

コンピュータ実装された方法は更に、
ブロックチェーンネットワークからトランザクションを受信し、
ブロックチェーンネットワークから受信したトランザクションを検証し、
ブロックチェーンネットワーク内の他のノードと共に、検証済みトランザクションの分散された非中央集権的なストレージを維持管理し、そして、
前記検証済みトランザクションに対応するデータを、検証済みトランザクションのリストを有するデータをマイニングするために、ブロックチェーンネットワークに配信する、
ことを有し得る。各リストが、ブロックへとマイニングされる検証済みトランザクションの完全なリストを提供することができる。

このような方法は、ブロックチェーンネットワーク内の他のノードと共に、検証済みトランザクションの分散された非中央集権的なストレージを保持しながら、マイナーが検証機能を実行する必要を効果的に取り除く。さらに、この方法は、トランザクション検証ノードが、検証済みトランザクションに対応するデータを用意して、マイニングのためにブロックチェーンネットワークに配信することにより、マイナーにサービスを提供することを可能にする。例えば、この方法は、検証済みトランザクションのリストが用意されて配信されることを可能にする。

ブロックチェーンネットワーク内の他のトランザクション検証ノードと共に検証済みトランザクションの分散された非中央集権的なストレージを維持管理するステップは、非中央集権的で分散的なやり方で検証済みトランザクションの最新リストを維持するために、ブロックチェーンネットワーク上のトランザクション検証ノードを同期化させることを有し得る。例えば、検証ノードは、可逆ブルームフィルタルックアップテーブルを交換することによって同期されることができる。検証済みトランザクションはまた、検証済みトランザクションの分散された非中央集権的なストレージを維持するために、ブロックチェーンネットワーク内のトランザクション検証ノードにまたがって共通の順序付けシステムが使用されるように、定められた順序にソートされることができる。例えば、正準順序付けシステムを使用して、検証済みトランザクションの分散された非中央集権的なストレージを維持管理することができる。分かっていることには、これは、ネットワークにわたるトランザクションデータが一貫した方法で維持管理されることを保証しながら、非中央集権的な分散ストレージを保持することの、特に効率的なやり方である。

検証済みトランザクションに対応するデータをマイニングのためにブロックチェーンネットワークに配信するステップは、検証済みトランザクションのリストに対応するデータ（例えば、検証済みトランザクションのリストに対応する可逆ブルームルックアップテーブル及び付随データなどであり、検証済みトランザクションはブロックに含まれる）を用意することを含み得る。さらに、検証済みトランザクションに対応するデータをマイニングのためのブロックチェーンネットワークに配信するステップは、検証済みトランザクションのリストに対応するデータをマイナーに提供することの代わりに、デジタル資産に関するコミットメントトランザクションを作成することを含むことができる。例えば、コミットメントトランザクションを含めて、ハッシュ（マークル）ツリー、パトリシア（Patricia）ツリー、又は他のタイプの基数ツリーを計算することができる。

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

ブロックチェーンネットワークから受信されるマイニングされたデータは、検証済みトランザクションに対応するブロックヘッダを含むことができる。マイニングされたデータはまた、マイニングされたデータに基づいてブロックを組み立てる及び／又は格納することの代わりに、デジタル資産に関するトランザクションを含むことができる。さらに、この方法は、デジタル資産を受信することに先立って、最小ブロック数に関連付けられた期間ｔにわたって待つことの要求を含むことができる。これは、検証ノードを提供するためのインセンティブスキームを提供する。何故なら、提供者は、検証済みトランザクションのリスト（例えば、可逆ブルームルックアップテーブルの形態）をマイニングのために及び／又はブロックチェーン上にマイニングされたブロックを格納するために提供したことに対する報酬を受けることになるからである。デジタル資産を受け取ること前に最低期間を要求することは、マイナーがある範囲のノードにスケルトンブロック（支払いを含む）を伝搬させることのインセンティブを与え、また、ノードは、他のノードにスケルトンブロックを伝搬させるインセンティブを与えられることになる。

マイニングされたデータに基づいてブロックを組み立てるステップは、例えば、少なくとも２、４、６、８、１０、５０、１００、５００、１０００、又は１００００メガバイトのサイズを持つ各ブロックを用いて大きいブロックを組み立てることを伴うことができる。上限は時間とともに大きくなることになるが、１ペタバイトという公称上限値が指定されてもよい。各ブロックは、例えば、少なくとも５０００、１００００、５００００００、１００００００、５００００００、又は１００００００トランザクションを有し得る。上限は時間とともに大きくなることになるが、ブロック当たり１０^１２トランザクションという公称上限値が指定されてもよい。先に示したように、ここに記載される方法、ノード、及びブロックチェーンネットワークアーキテクチャは、マイナーが多数のトランザクションを構築及び記憶することを必要とせずに、大きいブロックが構築されてストレージエンティティ上に格納されることを可能にする。これは、大幅に上昇されたトランザクションレートをシステムが取り扱うことを可能にする。

ここに記載される方法では、ブロックが、マイナーによって提供される乱数を含んだブロックヘッダを含むように変更され得る。すなわち、トランザクション検証ノードが、解かれたトランザクションをブロックチェーンネットワークから受信するときに、マイナーによって提供される乱数を含んだブロックヘッダを含むブロックを処理するように構成され得る。これは、ブロックヘッダへの変更を構成し、それによって、マイナーは、ブロックヘッダに挿入される数字を選択するかランダムに生成するかすることができる。これは、同じトランザクションリストが多数のマイナーによって選ばれるときであっても、マイナーが同じブロックをマイニングしようとして競い合うことがないことを確保する助けとなる。

上述の大きいブロックのデータを格納するストレージエンティティは、ブロックチェーンネットワーク上の複数のトランザクション検証ノード間で共有されることができ、それら複数のトランザクション検証ノードは、ブロックチェーンネットワーク上のスーパーノードを形成し、共有ストレージエンティティは、共通のストレージノード、分散ストレージ、又はこれら２つの組み合わせのいずれかである。このアーキテクチャは、ブロックチェーンネットワーク上のスーパーノードの形成につながるとともに、ブロックチェーンを格納してブロックチェーンネットワークにサービス提供する専用ストレージ機関の提供を可能にする。

以上に鑑み、ブロックチェーンネットワークのスーパーノードも提供され、スーパーノードは：
先述のような複数の検証ノードと、
ブロックチェーンを格納する共有ストレージエンティティと、
を有し、
共有ストレージエンティティは、共通のストレージノード、分散ストレージ、又はこれら２つの組み合わせのいずれかであり、
複数の検証ノードによって組み立てられたブロックが、共有ストレージエンティティに送信されてその上に格納され、それにより、共有ストレージエンティティがブロックチェーンを維持管理する。

このアーキテクチャは、ここに記載される方法及び構成の狙いであるトランザクションレートにおける望ましい上昇を達成するのに必要とされる大きいブロックサイズを取り扱うことに、よりいっそう適している。例えば、共有ストレージエンティティは、少なくとも１００ギガバイトの記憶容量、より好ましくは少なくとも１、１０、１００、又は１０００テラバイトの記憶容量を有するように構成され得る。上限は時間とともに大きくなることになるが、１０^６テラバイト又は更には１０^６ヨタバイトという公称上限値が指定されてもよい。

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

ブルームフィルタ及びＩＢＬＴ
このセクションで、我々は、所謂ブルームフィルタの特性、及び可逆ブルームルックアップテーブルと呼ばれるそれらの拡張をまとめる。

その最も単純な形態において、ブルームフィルタは配列である。その配列は、Ｍ及びｋという、それに関連付けられた２つのパラメータを有する。Ｍは、配列におけるビット数であり、ｋは、異なるハッシュ関数Ｈ_ｋの数であり、

となる。ここで、Ｓ_１６は、その上でハッシュ関数が動作する１６進文字列の空間である。トランザクションＴ_Ｘ０が、それに関してブルームフィルタが作成されたセットに属するかを決定するために、我々は、Ｈ_１（Ｔ_Ｘ０）．．．Ｈ_ｋ（Ｔ_Ｘ０）を計算し、その後、対応するビットが配列内で１に設定されているかをチェックする必要がある。図９は、ブルームフィルタを作成する際のワークフローを示している。

１つ以上がそうでない場合、間違いなくＴ_Ｘ０はクエリされたセット内にないことになる。しかしながら、ブルームフィルタは偽陽性を許容する。これは、ハッシュ関数がビットを１に変化させる確率が、ｐ＝１／［配列のサイズ］＝１／Ｍであることに因る。従って、いわゆる

で、所与のハッシュ関数によってはビットが１に設定されない。

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

である。ｎこの要素を挿入する必要がある場合、これは、

となる。

ブルームフィルタの１つの明白な欠点は、それが特定の順序を追跡したり維持したりしないことである。すぐに明らかになることには、フィルタリング対象であるアイテムの索引付けを維持することを望むのであれば、フィルタの機能を拡張する必要がある。これこそが、可逆ブルームフィルタ（Invertible Bloom Filters；ＩＢＦｓ）及び可逆ブルームルックアップテーブル（Invertible Bloom filter Lookup Tables；ＩＢＬＴｓ）が登場するとことである。

配列のビットをアクティブにするだけであることに代えて、キーのＸＯＲサム、ハッシュ値（以前のような）、及び全体カウンタがＩＢＦの各フィールドに格納される。この手順を、ＩＢＦ／ＩＢＬＴにトランザクションがどのようにエンコードされるのかを例示するワークフローを示す図１０に例示する。

アプリケーション
それぞれメンプールｍ_１及びｍ_２を維持管理する２つのノードＮ_１及びＮ_２を有すると仮定する。各メンプールが、１６進文字列Ｓ_１６の母集団からの要素を含む。さらに、Ａｎｄｒｅｓｅｎによって提案され且つ本明細書中で前に概説したような順序付け規則にメンプールが従うと仮定する。

ここで、Ｎ_１がｍ_１をＮ_２に送信し、Ｎ_２は今や、２つの方法にてセット調整にアプローチすることができる。

１）Δｍ＝ｍ_２−ｍ_１によってセット差を計算する（（Ｄａｖｉｄ Ｅｐｐｓｔｅｉｎ，２０１１），（Ｍｉｃｈａｅｌ Ｔ．Ｇｏｏｄｒｉｃｈ，２０１１）を参照）；
２）ｍ_２内のトランザクション上で反復して、それらがＮ_２のメンプール内に存在するかをチェックする。

我々は、ＩＢＬＴを少なくとも２つの目的で使用することができることを理解している：
１）ノードに、それらが既に自身のメンプール内に有するトランザクションに基づいて、マイニングされたブロックを組み立てさせるとともに、それらが有していないものを特定して取り出す助けとする；
２）異なるノードに属するメンプール間で一定レベルの同期を維持する。

分散メンプールの剪定（プルーニング）
上述のように、例えばビットコインといったブロックチェーン技術の未来は、少なくとも部分的に、毎秒発行されるトランザクションの量を増加させることができる新アーキテクチャの提案を当てにしている。そのような新アーキテクチャに対する１つの要求は、ブロックサイズ制限についての現在の限界を取り除くことである。このシナリオにおいて、ローカルなメモリプールでは十分なストレージ能力を提供することができず、それ故に、分散メモリプール（ＤＭＰｓ）に関する新しいモデルを設計する必要がある。分散メモリプールの管理のための改良アーキテクチャは、以下の特徴を提供する：
分散メモリプールに格納されたトランザクションの有効性に関するグローバルコンセンサス；
格納された情報の一貫性及び完全性；
高速な読み出し及び書き込み処理；及び
分散メモリプールにおけるルーティング及びストレージ攻撃に対するセキュリティ機構。

トランザクションが新たにマイニングされたブロックに含められると、ＤＭＰ内の対応するコピーは、もはや保存される必要がないかもしれない。このセクションにおいて、我々は、ＤＭＰからのトランザクションの安全な除去のためのプロトコルを提供することによって、以前のアーキテクチャを拡張する。

我々は、提供されるＤＭＰアーキテクチャ及び分散ハッシュテーブル（ＤＨＴ）演算の概要を提示する。我々はまた、ＤＭＰ内のトランザクションの剪定に関する分散コンセンサスに至るための新しい機構を導入する。さらに、ＤＭＰ内でのデータ不一致を解決するための複数の異なるポリシーが提示され、それらポリシーは：
トランザクションは、削除されるものとしてマーキングされ得るが、依然としてメンプールノードにローカルに保存され得る；
同じトランザクションは、あるメンプールノードで削除されるものとしてマーキングされ得るが、依然として別のメンプールノードで利用可能であり得る；
ブロックチェーン再編成が、以前にメンプールから削除されたトランザクションの保管を必要とし得る。

現行のビットコインネットワークにおける個々のノードは、分散メモリプール（ＤＭＰ）を提供するノードのクラスタとして見ることができる。提案するＤＭＰは、誠実なノード間の個々の信頼関係から構成されたネットワークに展開される分散ハッシュテーブル（ＤＨＴ）構造を当てにする。ノードのコネクションセットが、ルーティング情報とアプリケーションレベル情報の双方の集合上に構築される。トラスト証明の発行又は保管に中央機関が関与することはなく、各ノードが、それ自身の信頼できるピアの記録を維持管理する。

悪意あるエンティティは、何らかの形態の攻撃を行うためには、ネットワークに参加する必要がある。例えば、シビル攻撃は、システムを損ねるために、多数の偽識別子の作成に焦点を当てている［Ｊｏｈｎ Ｒ．Ｄｏｕｃｅｕｒ，Ｔｈｅ Ｓｙｂｉｌ Ａｔｔａｃｋ，Ｆｉｒｓｔ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｓｙｓｔｅｍｓ，Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ，Ｌｏｎｄｏｎ，２００２］。ネットワークに接続されたシビルノードが、正規のルーティングクエリを遮り又は遅延させ、間違ったルーティング情報を流布させ得る。ここに記載されるＤＨＴルーティングプロトコルは、略線形（サブリニア）時間及び空間複雑性を有し、以下の仮定に基づく：
ノードは、誠実なノードと悪意あるノードとを区別することができない；
誠実なノードの大多数が、他の誠実なノードへのいっそう多くのコネクションを持つ；及び
各ノードが、キー空間のパーティションに関する情報を保管する責任を持つ。

ＤＨＴプロトコルは、２つの主要な関数を提供する：
各ＤＨＴノードでルーティングテーブルを構築しキーを挿入するために、ＵＰＤＡＴＥ（）が使用される；及び
キーｋによって表されるターゲットのキー値レコードを見つけるために、ＤＨＴノードｘによってＧＥＴ（ｘ，ｋ）が使用される。

各ＤＨＴノードｘは、通常、公開鍵Ｐ_ｘと現在のＩＰアドレスａｄｄｒ_ｘによって識別される。この情報が、レコードｓｉｇｎ_ｘ（Ｐ_ｘ，ａｄｄｒ_ｘ）と安全にリンクされ、ここで、ｓｉｇｎ_ｘ（）は、対応する秘密鍵での署名を表す。そして、ノードＩＤが、署名されたレコードを使用してＤＨＴに格納される。ノードが場所を変える又は新しいＩＰアドレスを受け取るとき、新しいレコード［Ｐ_ｘ，ａｄｄｒ_ｘ］がＤＨＴに格納されなければならない。悪意あるノードが、誤ったキー−値ペアを挿入することがある。ＧＥＴメソッドが、返されたキー−値レコード内の署名を検証する責任を持つ。

データルーティングネットワークは、無向グラフによって表されることができる。悪意あるエッジが悪意あるノードを誠実なノードに接続し、誠実なエッジが２つの誠実なノードを接続する。任意数のシビル識別子を作成することは、悪意あるエンティティにとって計算的に手頃であり得るが、悪意あるエッジを作成することは、シビル管理の識別子のうちの１つへの信頼できるリンクを確立するために、誠実なノードを説得する必要がある。誠実領域を２つに分割するスパースカット（sparse cut）存在しなければ、誠実なノードで始まる短いランダムウォークは、誠実なノードで終わる可能性が高い。

ノードのルーティングテーブルは、ネットワーク内で独立したランダムウォークを開始することによって構築されることができる。ノードは、各ウォークの受信ノードから１つ以上のランダムなキー−値レコードを収集する。このルーティング情報はルックアップ中に使用され、ローカルテーブルがそのキーを含んでいない場合、ルックアップメッセージがノードのセットにマルチキャストされる。１つ以上の受信ノードが、クエリさせたキー−値レコードをローカルに格納している可能性が高い。他のノードのテーブルに対する直接的な要求は送信されない。従って、悪意あるノードは、リモートテーブル内の誤ったエントリの数を恣意的に増やすことができない。

悪意あるノードが所望のアウトプットを力ずくで見付けて、２つの誠実キーの間に誤ったキーを挿入することを防止するために、キーは、例えばハッシュといった確定関数を用いて共有空間に格納されることはない。従って、２つのキー間の距離を測定する機能は規定されないことになる。各ノードｘが、キー空間全体にＩＤが一様に分散された、他のノードへのポインタを含む長距離ルーティングテーブルを構築する。ポインタは、ランダムウォークを開始し、終了ノードからランダムＩＤを収集することによって格納される。近距離ルーティングテーブルは、キー−値レコードを含む。これらのキーは、予め定められた順序付けに従って、ノードのＩＤに最も近く従ったものである。

このルーティング構造は、（ａ）ノード障害を管理することができ、すなわち、ルーティングテーブルにおける冗長性が、キー値を取り出すための代替パスを提供し；（ｂ）キー変更を管理することができ、すなわち、キーの追加又は削除は、キーの分布とＤＨＴ空間内の長距離ポインタの分布との間の不整合につながり；及び（ｃ）ネットワーク接続の変化を管理することができ、すなわち、信頼されるコネクションの追加又は削除は、スパースカットが誠実ネットワークを分けておらず且つエンドポイントが悪意あるものになっていない限り、ルーティング性能に影響を与えない。新しい鍵の同期及び可用性が、周期的なＵＰＤＡＴＥ呼び出しによって提供される。

信頼されるコネクションの概念は、ＤＨＴ基盤において安全性及び完全性を提供するための基本である。ネットワーク内に新たなエッジを作成することには、２つの異なる機構が関与し得る。

主観的コネクションは、例えば、グローバル又はローカルなよく知っているエンティティについての友好、契約、及び信頼といった、ピア間の社会的又は専門的な関係上に築かれる。例えば、非営利組織、研究機関、政府機関、及び特定の協定に署名した民間企業は、信頼できるコネクションであることができる。

推移的コネクションは、ネットワーク上のランダムパスの数を増加させるための論理特性及び信頼度に基づく。ホップ・バイ・ホップ・ウォークにおけるランダム性の増加は、悪意あるノードが悪意あるエッジの脆弱性を利用することをいっそう困難にする。他のノード間の信頼されるコネクションを認識するために、署名されたメッセージをピア間で交換することができる。ノードは、ランダムウォークで個々のホップを選択する確率を調整するために、又は新たな推移的コネクションを初期化するために、その信頼されるコネクションに異なる重みを割り当てることを決定し得る。全てのノードがそれ自身の重みを担う。誠実なノードは、それらのコネクションの重みを、それらのピアのルーティング挙動に従って調整することになり、ノードは、その短距離ルーティングテーブル内にキーがフォールインすることになる場合に、有効なキー−値レコードを提供できないとし得る。従って、新たなランダムウォークが弱いエッジを通過することが防止され、悪意あるノードの影響が時間とともに減少することになる。

ＤＭＰ機能は、特殊化されたビットコインノードのクラスタによって提供される。クラスタ内で、検証ノードが新たな着信トランザクションを収集及び検証する一方で、メンプールノードが検証済みトランザクションを永続的に記憶することを担う。図１１は、複数の検証ノードｖと複数のメンプールノードｓとを有するメンプールクラスタの設計を示している。これら２つのタイプのノードの機能は、同一の物理的エンティティによって提供されてもよいし、異なるエンティティに埋め込まれてもよい。

ＤＭＰは、検証済みトランザクションの保管及び検索という２つの基本的動作を提供する。トランザクションｔ_ｉが与えられと、識別子ｉｄ（ｔ_ｉ）をｉｄ_ｉ＝Ｈ（ｔ_ｉ）として割り当てることができ、ここで、Ｈはハッシュ関数を表す。この識別子が、ＤＭＰにおいてキーとして使用されることになる。特定のマルチキャストアドレスを使用して、トランザクションをクラスタ内の複数のバリデータから受信することができる。次いで、各バリデータが独立にトランザクションを検証する。しかしながら、基礎をなすＤＨＴ構造は、キークラスタリング攻撃を防止するために、キー空間にトランザクションＩＤを埋め込まない。従って、トランザクションはＤＭＰ内のランダムノードに格納されることができる。所与のトランザクション又は所与のグループのトランザクションに対して、バリデータノードはＲ ＳＴＯＲＥメッセージ要求をランダムメンプールノードに送信することができ、ここで、Ｒはデータ複製係数である。

Ｎ個のバリデータが独立にトランザクションｔ_ｉを検証すると仮定する。各バリデータｖが、Ｖ_ＤＢと呼ばれるローカルデータベースを維持管理する。このデータベースの各エントリが、トランザクションｉｄ_ｉの識別子と検証についてのバイナリデシジョンとを含む。各バリデータが、ローカルな決定に従ってＳＴＯＲＥ（ｔ_ｉ，ｉｄ_ｉ）又はＲＥＪＥＣＴ（ｉｄｉ）メッセージをＤＭＰに送信することになる。

各メンプールノードｓは、Ｎ／２＋１個のＳＴＯＲＥメッセージを受信した場合にのみｔ_ｉを格納する。あるいは、ノードは、最初のＳＴＯＲＥメッセージを受信するとすぐに、定足数に達するのに必要なＮ／２個の更なるＳＴＯＲＥメッセージの受信のためのタイマーを起動する。十分なコンファメーションを受信することなくタイムアウトを越える場合、そのトランザクションは破棄される。各メンプールノードｓ_ｍはまた、ｔ_ｉについて、受信したコンファメーションの数Ｎ_ｉ，ｍ＞Ｎ／２＋１を保持する。

検証済みトランザクションｔ_ｉの検索は、メッセージＱＵＥＲＹ（ｉｄ_ｉ）のブロードキャストを必要とする。ｔ_ｉの格納を担っているメンプールノードが、メッセージＤＡＴＡ（ｔ_ｉ）をクエリノードに送信することになる。ｔ_ｉを格納するのにＭ個のメンプールノードが必要とされる場合には、格納されたトランザクションが一貫したものであるとみなすために、少なくともＭ／２＋１個のＤＡＴＡメッセージがクエリノードによって受信されるべきである。さらに、クエリノードは、Ｖ_ＤＢに格納された情報に従ってｔ_ｉの有効性を評価するために、ＶＡＬＩＤＩＴＹ＿ＲＥＱ（ｔ_ｉ）メッセージを用いてＮ／２＋１個のランダムバリデータにインターロゲートし得る。

ますます増加するトランザクション活動の管理用のスケーラブルなアーキテクチャは、大量のデータとともに動作するストレージインフラストラクチャを必要とする。例えば、１０Ｋ ｔｘｎ／ｓのトランザクションレートで１ＫＢのトランザクション平均サイズは、月当たりのブロックで〜２７ＴＢのストレージを必要とする。

Ｍネットクラスタ内で、２つの異なるストレージアーキテクチャ（又はそれらの組み合わせ）が提案される。第１のアーキテクチャは、中央集権的なストレージ機関へのアクセスをそれら全てが有する幾つか検証ノードを所有及び維持する大きめのエンティティに好適である。対照的に、完全に非中央集権的にされたアーキテクチャは、共用の分散ストレージプールに参加することを望む、十分なストレージ容量を備えた個々のノードに好適である。

以下では、我々は、トランザクション依存関係を表すために、以下の用語を使用する：
トランザクションは、親と呼ぶ先行トランザクションのアウトプットを使用することができる；
トランザクションは、子と呼ぶ後続トランザクションに対するアウトプットを作成することができる。

トランザクション依存関係、又はトランザクションのチェーンを作成して、子が親の前に付加されることを必要とする複雑なトランザクションワークフローを表し得る［Ｂｉｔｃｏｉｎ Ｃｏｒｅ ソースコード ＵＲＬ：https://github.com/bitcoin/bitcoin］。トランザクションのチェーンがネットワークを横切って伝送されるとき、データ到着順序がデータ送信順序と一致しないことがある。その場合、未知の親トランザクションを参照するトランザクションを格納するために、受信側のノードによってオーファントランザクションプールが使用される。親が分かると、親によって作成されたＵＴＸＯを参照する何れのオーファンも、オーファンプールから解放され、再帰的に再検証される。そして、トランザクションのチェーン全体が、正しい順序で再構築されてトランザクションプールに含められる。従って、新たなトランザクションがメンプールに追加されるときには、メンプール内の子はいない。何故なら、そのような子はオーファンになるからである。

サービス妨害攻撃を防ぐために、メモリに格納されるオーファントランザクションの数には制限がある。プール内のオーファントランザクションの数が、許された最大数を超えると、プールサイズが限度内に戻るまで、ランダムに選択されたオーファントランザクションがプールから排除される。

ローカルメモリプールは、ノード視点のブロックチェーンと一致するトランザクションのセットが含む。トランザクションは、以下の理由のうちの１つに起因してローカルメンプールから削除されることができる：
マイニングされたブロックでのトランザクション公開、新たなブロックが検証されると、そのトランザクションはメンプールから削除される；
ブロックチェーン再編成（ｒｅｏｒｇ）。ブロックがブロックチェーンから切り離される場合、それのトランザクションが移し戻される；
ブロック内トランザクションとの衝突（二重支払い）。新たなブロックが検証されると、そのブロック内のトランザクションと衝突する全てのトランザクションが、それらに依存するものを加えて、メンプールから除去される。

また、ローカルメンプールの構成に応じて、以下の更なるケースが考えられる：
手動剪定；
期限切れ；及び
ローカルメモリサイズ制限。

トランザクションとその子とを削除するとき、実際の削除を実行する前に、トランザクションの完全なセットが計算されなければならない。さもなければ、メンプールが、親を検索することが不可能な不一致状態になってしまい得る。除去されるようにマーキングされた所与のトランザクションの全ての先祖が更新される必要がある。従って、チェーン内の中間トランザクションは、全ての関連するトランザクションの全ての状態が更新されるまで除去されることができない。

ｒｅｏｒｇの場合、新たなトランザクションはメンプール内の子を有することがあり、一貫性のない状態を引き起こし得る。何故なら、切り離されたブロックに由来するトランザクションの子孫トランザクションが存在し得るからである。この場合、メンプール内のブロック内トランザクションのブロック外の子孫がチェックされなければならない。Ｂｉｔｃｏｉｎ Ｃｏｒｅでは、関数ＵｐｄａｔｅＦｏｒＤｅｓｃｅｎｄａｎｔｓが、メンプールに追加された個々のトランザクションの子孫を更新するために使用され、また、メンプール内に子トランザクションを有し得る［Ｂｉｔｃｏｉｎ Ｃｏｒｅソースコード ＵＲＬ：https://github.com/bitcoin/bitcoin］。

先述したように、勝ったマイナーはブロックスケルトンを検証ノードに送り返す。ブロックスケルトンは、ナンス、可逆ブルームフィルタルックアップテーブル（ＩＢＬＴ）、及びコインベーストランザクションで構成される。これに基づいて、検証ノードは：
１． 特定のルールセットに従ってトランザクションを順序付け；
２． 新たにマイニングされたブロックを組み立て；
３． そのブロックをそれら自身のストレージに格納することを進め；
４． スケルトンを他の新しいフルノードに伝搬させる、
ことができる。

従って、検証ノードは新しく公開されたトランザクションに気付く。各バリデータノードは、独立に、トランザクションＩＤのリストを含む削除メッセージをＤＭＰに送信する。バリデータは、以前に検証したトランザクションに対してのみ削除要求を送信し得る（ｃｈｅｃｋ＿ｖａｌｉｄａｔｏｒ＿ｓｅｎｄがイネーブル）。この情報はデータベースＶ_ＤＢ（Ｖａｌｉｄａｔｏｒ ｄａｔａｂａｓｅ）に格納される。このモデルによれば、メンプールノードは、そのトランザクションを検証しなかったバリデータから受信した削除要求を破棄し得る（ｃｈｅｃｋ＿ｖａｌｉｄａｔｏｒ＿ｒｃｖがイネーブル）。この情報はデータベースＳ_ＤＢ（Ｓｔｏｒａｇｅ ｄａｔａｂａｓｅ）に格納される。これら２つのｃｈｅｃｋ＿ｖａｌｉｄａｔｏｒ＿ｓｅｎｄオプション及びｃｈｅｃｋ＿ｖａｌｉｄａｔｏｒ＿ｒｃｖオプションは、ハードコードされてもよいし、独立に設定可能であってもよい。削除メッセージは、バリデータの秘密鍵で署名される。メッセージは、コンセンサスプロトコルに影響を及ぼし得る不正な複製の流布を回避するために、ナンス又はタイムスタンプを含まなければならない。

図１２は、新たにマイニングされたブロックに関する更新を受け取るバリデータノードｖ_ｎ（０≦ｎ＜Ｎ）を示している。ブロックを検証した後、バリデータは、公開されたトランザクションに関するＤＥＬＥＴＥ要求をＤＭＰに送信する。各メンプールノードｓ_ｍ（０≦ｍ＜Ｍ）が、Ｓ_ＤＢテーブル上の格納要求及びＲ_ＤＢテーブル上の除去要求を追跡する。図１２に示すように、格納されたトランザクション各々に対する削除要求を追跡するために、新しいテーブルＲ_ＤＢ（Ｒｅｍｏｖａｌ ｄａｔａｂａｓｅ）が各メンプールノードによって使用される。メンプールノードｍ＜Ｍについてのバリデータｎ＜Ｎからのトランザクションｔ_ｉに対する削除要求を与えられると、ローカルＲ_ＤＢ（ｍ）テーブルはブールｒ_ｍｎ値を含むことになる。例えば、Ｎ＝１００であり、且つ各メンプールノードが１０分毎に１０Ｍトランザクションを３日間保存することができる場合、Ｒ_ＤＢ（ｍ）のサイズは、１００・１０^７・３・２４・６＝４３２ＧＢが境界となる。なお、この数字は、過去３日間にローカルに保存された全てのトランザクションが承認されておらず、且つ各テーブルエントリに１バイトが必要とされるという、殆ど起こりにくいワーストケースシナリオを表している。少なくとも１桁又は２桁小さい大きさのテーブルサイズ（例えば、〜４ＧＢ）の方が、より現実的なシナリオを表す可能性が高い。しかしながら、メンプールノードに要求される高いストレージ能力のため、我々は、ローカルテーブルの最大サイズに制約は課さない。

Ｎ^ＭＡＸ＞Ｎを、クラスタにＳＴＯＲＥ又はＤＥＬＥＴＥメッセージを送信し得るバリデータの最大数とする。選択された分散アーキテクチャに応じて、Ｎ^ＭＡＸは、ネットワーク内のバリデータの総数に一致することもあるし、特定のＤＭＰクラスタのサイズに比例することもある。ＤＭＰクラスタのサイズは、メンプールノードの数及び／又はローカルに格納され得るトランザクションの総量によって与えられる。

我々は、クラスタ内のローカルメンプールノードｓ_ｍに格納されているトランザクションｔｉが除去されるべきかを決定するための何らかの基準を導入する：
少なくともＮ^＊＜Ｎ^ＭＡＸのバリデータがＤＥＬＥＴＥ要求を送信する。バリデータは実際には、ｃｈｅｃｋ＿ｖａｌｉｄａｔｏｒ＿ｓｅｎｄ及びｃｈｅｃｋ＿ｖａｌｉｄａｔｏｒ＿ｒｃｖの設定に応じたＮ^＊に寄与し得る。一方又は双方のオプションが設定される場合、我々はＮ^＊≒Ｎ（近似）を課し得る。いずれのオプションも設定されない場合には、可能な限り高いコンセンサスを達成するために、我々はＮ^＊＞Ｎを推奨する。

ｔ_ｉは、以前に除去されたトランザクションｔ_ｊに依存する。双方のトランザクションがｓ_ｍに格納されたものであり、且つｔ_ｊが安全に除去された場合、ｔ_ｉも安全に除去されることができる（トランザクションの除去に関するコンセンサスに達した場合、従属トランザクションは無効とみなされるにちがいなく、除去されるものとしてマーキングされる）。他のメンプールノードへの信号伝達は必要とされない。

我々は、ＤＭＰが特定のサービス妨害攻撃を防ぐために単一のメンプールノードにトランザクションのチェーンを格納することを強制しない。従って、メンプールノードは、チェーン内の個々のトランザクションの状態のために、一貫性のない状態にあることがある。これは、トランザクションチェーンに関連するデータを要求するビットコインノードが、ＤＭＰへの特定のクエリ要求によって不一致について学習する限り、問題を表すものではない。例えば、ビットコインノードはトランザクションｔ_ｉについてＤＭＰに尋ねる。このトランザクションは、第２のトランザクションｔ_ｊに依存する。第２のトランザクションについてＤＭＰにクエリした後、ノードは、ｔ_ｊがもはや格納されていないことを発見する。従って、ＤＭＰ内の一部のメンプールノードになおも格納されているとしても、ｔ_ｉを利用できないものと考えるのがノードの責任である。長期的な不一致が、恒久的な剪定によって解決されることになる。

コンセンサスに達した場合、トランザクションｔ_ｉは、除去されるものとしてローカルにマーキングされる。しかしながら、セキュリティ上の理由から、トランザクションは物理的に除去されないとし得る。我々は、いつトランザクションがｓ_ｍから物理的に削除されるべきかを決定するための２つの基準を導入する：
少なくともＮ^＊＊≧Ｎ^＊のバリデータがＤＥＬＥＴＥ要求を送信する。Ｎ^＊＊の値は、剪定コンセンサスが完全に安全であると考えるのに十分な高さであるべきである；
最後のＤＥＬＥＴＥ要求が受信されてから、ΔＴ_ｉ＞ΔＴ^＊の長さの時間が経過しているとともに、ｔ_ｉに対する更なるデータ要求は転送されていない。ΔＴ^＊の値は、ｒｅｏｒｇイベントの確率が無視できると考えるのに十分な高さであるべきである。６ブロック承認ルールによれば、トランザクションは、新たにマイニングされたブロック内でのその公開からおおよそ１時間後に、ネットワークによって受け入れられたと、安全にみなされることができる。

しかしながら、ｓ_ｍのメモリ制約に応じて、上の基準が満たされていなくても、ｔ_ｉが除去されてもよい。トランザクションは、ΔＴ_ｉの降順でソートされて、恒久的削除のために選択され得る。チェーンに属し且つｓ_ｍに格納されている複数のトランザクションが同時に削除されなければならない。トランザクションチェーンの剪定についてのバリデータへの通知は必要とされない。トランザクションチェーンに関するデータを必要とするビットコインノードは、ＤＭＰへの特定のクエリ要求によって不一致を学習する。

メンプールノードは、除去されるものとして既にマーキングされているトランザクションに対するデータ要求を収集し得る。個々のトランザクションに対する複数のデータ要求を受信することは、異なる意味を持ち得る：
無用なデータを保持するサービス妨害攻撃；
ブロックチェーンｒｅｏｒｇ、及びトランザクションをＤＭＰに転送し返す必要性。

要求が正当でないこともあるので、メンプールノードは、これらのデータ要求の結果として何のアクションも取らない。データ要求カウンタを使用して、除去されるトランザクションを復帰の候補としてマーキングし得る。これらの候補は、物理的な剪定に関してなおも検討され得る。物理的な剪定に対して優先ポリシーが実装されている場合、復帰に関する候補トランザクションには、より低い優先度が割り当てられ得る。

除去されるとしてマークされているが、なおもローカルに保存されているトランザクションは、バリデータからのＲＥＶＥＲＴ（復帰）メッセージが受信された場合にのみ、復帰されることができる。バリデータは、チェーンｒｅｏｒｇが行われる場合に、ＤＭＰに信号伝達することを担う。メンプールノードは、トランザクションを再び利用可能にするために、ある一定数の固有のＲＥＶＥＲＴメッセージを収集する必要がある。我々はＮ、Ｎ^＊、及び／又はＮ^＊＊パラメータの関数としてのメッセージ数を推奨する。例えば、ＲＥＶＥＲＴメッセージの最低数は、ＮとＮ^＊の間の平均値に等しいとし得る。

表３は、剪定プロトコルによって使用される設定可能パラメータをまとめている。

トランザクションを管理するプロトコルは、以下のメッセージを含む：
ＲＥＣＥＩＶＥＤ（ｔ_ｉ） 新たな未検証トランザクションｔ_ｉが受信されたときにトリガされるバリデータのコールバック；
ＳＴＯＲＥ（ｔ_ｉ，ｉｄ_ｉ） 有効なトランザクションｔ_ｉ及びキーｉｄ_ｉを格納するためのバリデータの要求；
ＳＴＯＲＥ（ｉｄ_ｉ） 有効なトランザクションキーｉｄ_ｉを格納するためのバリデータの最適化された要求；
ＱＵＥＲＹ（ｉｄ_ｉ） キーｉｄ_ｉを有するトランザクションに関する一般ノードの要求；
ＤＡＴＡ（ｔ_ｉ） トランザクションｔ_ｉのクエリ要求に対するメンプールノードの応答；
ＶＡＬＩＤＩＴＹ＿ＲＥＱ（ｔ_ｉ） トランザクションｔ_ｉの有効性をダブルチェックするための一般ノードの要求；
ＶＡＬＩＤＩＴＹ＿ＡＣＫ（ｔ_ｉ） トランザクションｔ_ｉに関する有効性要求に対するバリデータの回答。

ここに提示される拡張は、以下の更なるメッセージを必要とする：
ＲＥＭＯＶＥ（ｉｄ_ｉ） ｉｄ_ｉによって特定されるトランザクションを除去するためのバリデータの要求；
ＲＥＶＥＲＴ（ｉｄ_ｉ） チェーンｒｅｏｒｇ後に、ｉｄ_ｉによって特定されるトランザクションを復帰させるためのバリデータの要求；
ＲＥＭＯＶＥＤ（ｉｄ_ｉ） ｉｄ_ｉによって特定される除去されるトランザクションに関するクエリ要求に対するメンプールノードの回答。情報がなおも利用可能である場合、このメッセージは、ｉｄ_ｉによって特定されるトランザクションに関してメンプールノードによって受信されたＲＥＭＯＶＥメッセージの数を含み得る。

バリデータの要求に応じた、ｉｄｉによって特定されるトランザクションの完全な状態図を図１３に示す。バリデータから受信されるメッセージのタイプ（すなわち、ＳＴＯＲＥ、ＲＥＭＯＶＥ、ＲＥＶＥＲＴ）及び数（例えば、Ｎ、Ｎ^＊、Ｎ^＊＊）に応じて、トランザクションは状態を、Ａｖａｉｌａｂｌｅ（利用可能）、Ｒｅｍｏｖｅｄ（除去される）、又はＰｈｙｓｉｃａｌｌｙ Ｒｅｍｏｖｅｄ（物理的に除去される）に変化させることができる。トランザクション状態“物理的に除去される”は復帰されることができない。しかしながら、ローカルファイルシステム及びオペレーティングシステムによって提供される機能に応じて、データがなおも復元され得ることがある。

なお、上述の実施形態は、本発明を限定するものではなく、例示するものであり、当業者は、添付の請求項によって規定される本発明の範囲から逸脱することなく、数多くの代わりの実施形態を設計することができる。例えば、理解されるべきことには、トランザクションはビットコインを転送することができるが、ユーザは、それに代えて、例えば情報、契約、及びトークンなどの他の資源を、ここに記載された方法及びシステムを用いて交換し得る。トークンは、そのトークンに関連付けられたスマート契約に従った資産又は資源を表し、そのトークンの管理がその資産又は資源の管理を可能にする。スマート契約それ自体は、ブロックチェーン外に格納されてもよく、あるいは、１つ以上のトランザクションの内部に格納されてもよい。

請求項において、括弧内に置かれた如何なる符号も、請求項を限定するものと解釈されるべきでない。用語“有している”及び“有する”並びにこれらに類するものは、いずれかの請求項又は明細書全体に列挙されたもの以外の要素又はステップの存在を除外するものではない。本明細書において、“有する”は“含む又はからなる”を意味し、“有している”は“含んでいる又はからなっている”を意味する。単数形での要素の参照は、それらの要素の複数形での参照を除外するものではなく、その逆もまた然りである。本発明は、幾つかの別個の要素を有するハードウェアによって、また、適切にプログラムされたコンピュータによって実装され得る。幾つかの手段を列挙するデバイスクレームにおいて、それらの手段のうちの幾つかが、同一のハードウェアアイテムによって具現化されてもよい。特定の複数の手段が相互に異なる従属請求項に記載されているという単なる事実は、それらの手段の組み合わせが有利に使用され得ないということを指し示すものではない。

参考文献
− An Integrated World. (n.d.) https://www.anintegratedworld.com/whats-in-a-block/から検索
− David Eppstein, M. T. (2011). What's the Difference? Efficient Set Reconciliation without Prior Context. ACM.
− maidsafe. (n.d.). github.com:https://github.com/maidsafe/Whitepapersから検索
− Michael T. Goodrich, M. M. (2011). Invertible Bloom Lookup Tables. Communication, Control, and Computing (Allerton), 2011 49th Annual Allerton Conference on.
− NebulousLabs. (n.d.). github.com:https://github.com/NebulousLabs/Siaから検索
− O(1) Block Propagation. (n.d.). github.com:https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2から検索
− Wikipedia. (n.d.). https://en.wikipedia.org/wiki/Distributed_hash_tableから検索
− Wilkinson et al. (2016, December 15). https://storj.io/storj.pdfから検索
− John R. Douceur. The Sybil Attack. First International Workshop on Peer-to-Peer Systems. Springer-Verlag, London, UK, 2002
− Bitcoin Core source code. URL: https://github.com/bitcoin/bitcoin

Claims (32)

1. ブロックチェーンネットワークのノード用のコンピュータ実装された方法であって、
   複数のトランザクションを格納し、該複数のトランザクションは、ブロックチェーンのブロックへとマイニングされるのを待っている分散メモリプールの少なくとも一部を形成し、
   前記ブロックチェーンネットワークの検証ノードからの削除要求を受信し、該削除要求は、新たにマイニングされたブロックに含められた１つ以上のトランザクションを特定し、該削除要求は、前記１つ以上のトランザクションが前記分散メモリプールから削除されるべきことを指し示す、
   ことを有するコンピュータ実装された方法。
2. トランザクションに、該トランザクションに対して第１閾値数の削除要求が受信されたときに、前記分散メモリプールから除去されるものとしてマーキングする、
   ことを更に有する請求項１に記載のコンピュータ実装された方法。
3. トランザクションを、該トランザクションに対して第２閾値数の削除要求が受信されたときに、前記分散メモリプールから物理的に除去する、
   ことを更に有する請求項２に記載のコンピュータ実装された方法。
4. 前記第２閾値は前記第１閾値よりも大きい、
   請求項３に記載のコンピュータ実装された方法。
5. 前記第１閾値数の削除要求及び前記第２閾値数の削除要求が、前記ブロックチェーンネットワーク内の、閾値数の、異なる検証ノードから来ることが要求される、
   請求項３又は４に記載のコンピュータ実装された方法。
6. トランザクションは、削除要求を受信してから、該トランザクションに対する更なるデータ要求が受信されることなく、閾値時間だけ経過した後にのみ、前記分散メモリプールから物理的に除去される、
   請求項１乃至５のいずれか一項に記載のコンピュータ実装された方法。
7. 前記閾値時間は、前記分散メモリプールからの削除が要求されているトランザクションが前記ブロックチェーンに組み込まれた後に、少なくとも１、２、３、４、５、６、又はそれより多くのブロックが前記ブロックチェーンに組み込まれることに相当する、
   請求項６に記載のコンピュータ実装された方法。
8. トランザクションは、削除要求を受信してから、該トランザクションに対する更なるデータ要求が受信されることなく経過した時間の降順で、前記分散メモリプールから物理的に除去される、
   請求項１乃至７のいずれか一項に記載のコンピュータ実装された方法。
9. トランザクションに、該トランザクションが先行して除去されたトランザクションに依存するときに、前記分散メモリプールから除去されるものとしてマーキングする、
   ことを更に有する請求項８に記載のコンピュータ実装された方法。
10. 前記削除要求はデータベースに格納される、
    請求項１乃至９のいずれか一項に記載のコンピュータ実装された方法。
11. 前記トランザクションを検証しなかったバリデータから受信された削除要求は破棄される、
    請求項１乃至１０のいずれか一項に記載のコンピュータ実装された方法。
12. 前記トランザクションは、チェックバリデータオプションがイネーブルされている場合にのみ破棄される、請求項１１に記載のコンピュータ実装された方法。
13. 前記分散メモリプールから除去されるものとして既にマーキングされたトランザクションに対するデータ要求の数をモニタする、
    ことを更に有する請求項１乃至１２のいずれか一項に記載のコンピュータ実装された方法。
14. 前記分散メモリプールからの除去のためにマーキングされたトランザクションに対して閾値数のデータ要求が受信された後に、トランザクションに前記分散メモリプールへの復帰の候補としてマーキングする、
    ことを更に有する請求項１乃至１３のいずれか一項に記載のコンピュータ実装された方法。
15. トランザクションに、該トランザクションに対して復帰要求が受信されたときに、前記分散メモリプールから除去されるものとしてのマーキングを解除する、
    ことを更に有する請求項１乃至１４のいずれか一項に記載のコンピュータ実装された方法。
16. トランザクションに、該トランザクションに対して閾値数の復帰要求が受信されたときに、前記分散メモリプールから除去されるものとしてのマーキングを解除する、
    ことを更に有する請求項１乃至１５のいずれか一項に記載のコンピュータ実装された方法。
17. 前記閾値数の復帰要求が、前記ブロックチェーンネットワーク内の、閾値数の、異なる検証ノードから来ることが要求される、
    請求項１６に記載のコンピュータ実装された方法。
18. 前記分散メモリプールから除去されたトランザクションに対する問い合わせに応答して、トランザクションが前記分散メモリプールから除去されたことを指し示すメッセージを送信する、
    ことを更に有する請求項１乃至１７のいずれか一項に記載のコンピュータ実装された方法。
19. トランザクションが前記分散メモリプールから除去されたことを指し示す前記メッセージは、除去された該メッセージに対して受信された削除メッセージの数も指し示す、
    請求項１８に記載のコンピュータ実装された方法。
20. トランザクションは、利用可能、除去される、及び物理的に除去されるという、前記分散メモリプールに対する３つの状態を有する、
    請求項１乃至１９のいずれか一項に記載のコンピュータ実装された方法。
21. ブロックチェーンネットワークのノード用のコンピュータ実装された方法であって、
    複数のトランザクションを有する新たにマイニングされたブロックに関するデータを受信し、
    分散メモリプールに、前記複数のトランザクションを当該分散メモリプールから削除する削除要求を送信する、
    ことを有するコンピュータ実装された方法。
22. 前記削除要求は、ナンス及び／又はタイムスタンプを含む、
    請求項２１に記載のコンピュータ実装された方法。
23. 前記削除要求は、前記ノードの秘密鍵で署名される、
    請求項２１又は２２に記載のコンピュータ実装された方法。
24. 前記ノードは、自身が検証したトランザクションの記録を記憶し、自身が以前に検証したトランザクションに関してのみ削除要求を送信する、
    請求項２１乃至２３のいずれか一項に記載のコンピュータ実装された方法。
25. 前記削除要求は、チェックバリデータオプションがイネーブルされているときにのみ、前記ノードが以前に検証したトランザクションに関して送信される、請求項２４に記載のコンピュータ実装された方法。
26. トランザクションを前記分散メモリプール内で再び利用可能にするために復帰要求を送信する、
    ことを更に有する請求項２１乃至２５のいずれか一項に記載のコンピュータ実装された方法。
27. 前記復帰要求はブロックチェーン再編成の後に送信される、
    請求項２６に記載のコンピュータ実装された方法。
28. 前記削除要求は、
    マイニングされたブロックの受信、
    ブロックチェーン再編成、及び
    二重支払い又はその他の形態のトランザクションコンフリクト、
    のうちの１つ以上によって起動される、
    請求項１乃至２７のいずれか一項に記載のコンピュータ実装された方法。
29. 前記分散メモリプールからのトランザクションの剪定は、
    手動剪定、
    トランザクション期限切れ、及び
    前記分散メモリプール内のトランザクションに関してメモリ制限に達したこと、
    のうちの１つ以上によって起動される、
    請求項１乃至２８のいずれか一項に記載のコンピュータ実装された方法。
30. コンピュータ実行可能命令を有したコンピュータ読み取り可能記憶媒体であって、前記コンピュータ実行可能命令は、実行されるときに、請求項１乃至２９のいずれか一項に記載の方法を実行するように１つ以上のプロセッサを構成する、コンピュータ読み取り可能記憶媒体。
31. インタフェース装置と、
    前記インタフェース装置に結合された１つ以上のプロセッサと、
    前記１つ以上のプロセッサに結合されたメモリであり、当該メモリはコンピュータ実行可能命令を格納しており、該コンピュータ実行可能命令は、実行されるときに、請求項１乃至２９のいずれか一項に記載の方法を実行するように前記１つ以上のプロセッサを構成する、メモリと、
    を有するエレクトロニクス装置。
32. ブロックチェーンネットワークのノードであって、請求項１乃至２９のいずれか一項に記載の方法を実行するように構成されたノード。

Images