(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023103330
(43)【公開日】2023-07-26
(54)【発明の名称】ブロックチェーン・ネットワークにおけるトランザクション検証ノードのための方法、記憶媒体、電子デバイス、トランザクション検証ノード、スーパー・ノード及びブロックチェーン・ネットワーク
(51)【国際特許分類】
G06F 21/64 20130101AFI20230719BHJP
H04L 9/32 20060101ALI20230719BHJP
【FI】
G06F21/64
H04L9/32 200Z
【審査請求】有
【請求項の数】24
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2023076998
(22)【出願日】2023-05-09
(62)【分割の表示】P 2022058089の分割
【原出願日】2018-06-05
(31)【優先権主張番号】1709098.6
(32)【優先日】2017-06-07
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】1709099.4
(32)【優先日】2017-06-07
(33)【優先権主張国・地域又は機関】GB
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】デステファニス,ジュゼッペ
(72)【発明者】
【氏名】マデオ,シモーネ
(72)【発明者】
【氏名】モティリンスキ,パトリック
(72)【発明者】
【氏名】ヴィンセント,ステファヌ
(57)【要約】 (修正有)
【課題】ブロックチェーン・ネットワークのトランザクション検証ノードにおける実装において、高いトランザクション速度をサポートするソリューションを提供する。
【解決手段】方法は、ブロックチェーン・ネットワークからトランザクションを受信することと、ブロックチェーン・ネットワークから受信したトランザクションを検証することと、ブロックチェーン・ネットワークにおける他のトランザクション検証ノードとともに、検証済みトランザクションの分散された非セントラル化されたストレージを維持することと、検証されたトランザクションに対応するデータを、マイニングのためにブロックチェーン・ネットワークへ分配することと、を含む。
【選択図】
図7
【特許請求の範囲】
【請求項1】
ブロックチェーン・ネットワークのトランザクション検証ノードのためのコンピュータで実行される方法であって:
(i)前記ブロックチェーン・ネットワークからトランザクションを受信するステップ;
(ii)前記ブロックチェーン・ネットワークから受信したトランザクションを検証するステップ;
(iii)前記ブロックチェーン・ネットワークにおける他のトランザクション検証ノードを用いて、検証されたトランザクションについての分散された非セントラル化されたストレージを維持するステップ;
を含む方法。
【請求項2】
請求項1に記載の方法において、前記ブロックチェーン・ネットワークにおける他のトランザクション検証ノードを用いて、検証されたトランザクションについての分散された非セントラル化されたストレージを維持するステップは、検証されたトランザクションの最新のリストを非セントラル化された分散された方法で維持するために、前記ブロックチェーン・ネットワークにおけるトランザクション検証ノードを同期させるステップを含む、方法。
【請求項3】
請求項2に記載の方法において、前記検証ノードは、可逆ブルーム・フィルタ・ルックアップ・テーブルを交換することにより同期させられる、方法。
【請求項4】
請求項1-3のうちの何れか1項に記載の方法において、前記検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、前記ブロックチェーン・ネットワークにおけるトランザクション検証ノードにわたって共通の順序体系が使用されるように、前記検証されたトランザクションが所定の順序でソートされる、方法。
【請求項5】
請求項4に記載の方法において、前記検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、前記検証されたトランザクションは、正規の順序体系を利用する所定の順序にソートされる、方法。
【請求項6】
請求項5に記載の方法において、前記検証されたトランザクションが、正規の順序体系を利用する所定の順序にソートされることは、
前のトランザクションのハッシュに関して昇順にトランザクションを並べ;且つ
後続のトランザクションに依存しないトランザクションを追加すること
によって行われる、方法。
【請求項7】
請求項1-6のうちの何れか1項に記載の方法において、前記検証されたトランザクションに対応するデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配するステップは:
検証されたトランザクションのリストに対応するデータを準備するステップ;
を含む、方法。
【請求項8】
請求項1-7のうちの何れか1項に記載の方法において、前記検証されたトランザクションに対応するデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配するステップは:
前記検証されたトランザクションのリストに対応する前記データをマイナーに提供することに対する見返りとしてディジタル資産のコミットメント・トランザクションを作成するステップ;
を含む、方法。
【請求項9】
請求項7に記載の方法において、ハッシュ・ツリー、パトリシア・ツリー、又は別のタイプのラディックス・ツリーが、包含されるコミットメント・トランザクションとともに算出される、方法。
【請求項10】
請求項1-9のうちの何れか1項に記載の方法において、前記検証されたトランザクションに対応するデータは、可逆ブルーム・ルックアップ・テーブル及び任意の付随するデータの形式で前記ブロックチェーン・ネットワークへ分配される、方法。
【請求項11】
請求項1-9のうちの何れか1項に記載の方法において、
(v)前記検証されたトランザクションに対応する採掘されたデータを、前記ブロックチェーン・ネットワークから受信するステップ;
(vi)前記採掘されたデータに基づいてブロックを組み立てるステップ;及び
(vii)ブロックチェーン上に保存するために、組み立てられたブロックをストレージ・エンティティへ送信するステップ; を含む方法。
【請求項12】
請求項11に記載の方法において、前記ブロックチェーン・ネットワークから受信される前記採掘されたデータは、前記検証されたトランザクションに対応するブロック・ヘッダを含む、方法。
【請求項13】
請求項11又は12に記載の方法において、前記採掘されたデータは、前記採掘されたデータに基づいてブロックを組み立てることに対する見返りとしてディジタル資産のトランザクションを含む、方法。
【請求項14】
請求項11-13のうちの何れか1項に記載の方法において、前記採掘されたデータは、組み立てられたブロックの格納に対する見返りとしてディジタル資産のトランザクションを含む、方法。
【請求項15】
請求項13又は14に記載の方法において、前記ディジタル資産を受け取る前に、最低限のブロック数に関連する期間tの間待機する条件を更に含む、方法。
【請求項16】
請求項11-15のうちの何れか1項に記載の方法において、前記採掘されたデータに基づいて複数のブロックを組み立てるステップは、各ブロックが少なくとも2メガバイトのサイズを有するラージ・ブロックを組み立てるステップを含む、方法。
【請求項17】
請求項11-16のうちの何れか1項に記載の方法において、前記ブロックはマイナーにより提供される乱数を含むブロック・ヘッダを含む、方法。
【請求項18】
請求項11-17のうちの何れか1項に記載の方法において、前記ストレージ・エンティティは前記ブロックチェーン・ネットワークにおける複数のトランザクション検証ノード間で共有され、前記複数のトランザクション検証ノードは前記ブロックチェーン・ネットワークにおけるスーパー・ノードを形成し、前記共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又は両者の組み合わせのうちの何れかである、方法。
【請求項19】
実行されると請求項1-18のうち何れか1項に記載の方法を実行するようにプロセッサを構築するコンピュータ実行可能命令を含むコンピュータ読み取り可能な記憶媒体。
【請求項20】
インターフェース・デバイス;
前記インターフェース・デバイスに結合される1つ以上のプロセッサ;
前記1つ以上のプロセッサ結合されるメモリ;
を含む電子デバイスであって、前記メモリは、実行されると請求項1-18のうち何れか1項に記載の方法を実行するように前記プロセッサを構築するコンピュータ実行可能命令を格納している、電子デバイス。
【請求項21】
請求項1-18のうち何れか1項に記載の方法を実行するように構成された、ブロックチェーンのトランザクション検証ノード。
【請求項22】
請求項21に記載の検証ノード複数個;及び
前記ブロックチェーンを格納する共有されるストレージ・エンティティ;
を含む、ブロックチェーンのスーパー・ノードであって、前記共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又は両者の組み合わせのうちの何れかであり、
前記複数の検証ノードにより組み立てられるブロックは、前記共有されるストレージ・エンティティへ送信され格納されることにより、前記共有されるストレージ・エンティティは前記ブロックチェーンを維持する、スーパー・ノード。
【請求項23】
請求項22に記載のスーパー・ノードにおいて、前記共有されるストレージ・エンティティは少なくとも100ギガバイトの記憶容量を有するスーパー・ノード。
【請求項24】
請求項22又は23に記載のスーパー・ノードを複数個含むブロックチェーン・ネットワークであって、
前記スーパー・ノードは前記ブロックチェーン・ネットワークで接続されており、各スーパー・ノードの前記共有されるストレージ・エンティティは前記ブロックチェーンのコピーを記憶するように構成されており、前記ブロックチェーン・ネットワークは少なくとも10個のスーパー・ノードを含む、ブロックチェーン・ネットワーク。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書は概してブロックチェーン・ネットワークのトランザクション検証ノードにおける実装に適したコンピュータ実装方法及びシステムに関する。多数のトランザクション及び大きなトランザクション・ブロックを扱うための修正されたブロックチェーン・ノード構造、ネットワーク・アーキテクチャ、及びプロトコルが説明される。本発明はビットコイン・ブロックチェーンに使用することに特に適しているがこれに限定されない。
【背景技術】
【0002】
本書では電子的なコンピュータ・ベースの分散型の全ての形態の台帳を含むように用語「ブロックチェーン」を使用する。これらは、ブロックチェーン及びトランザクション・チェーン技術、許可された及び許可されていない台帳、共有台帳、並びにそれらの変形を含むが、これらに限定されない。ブロックチェーン技術の最も広く知られている応用はビットコイン台帳であるが、他のブロックチェーン実装が提案され開発されている。本明細書では、便宜上及び説明の目的でビットコインが参照されるかもしれないが、本発明は、ビットコイン・ブロックチェーンで使用することに限定されず、代替的なブロックチェーンの実装及びプロトコルが、本発明の範囲内に属することに留意すべきである。
【0003】
ブロックチェーンはコンセンサス・ベースの電子台帳であり、これはトランザクション及びその他の情報により構成されるブロックにより構成される、コンピュータ・ベースの非セントラル化された分散システムとして実装される。ビットコインの場合、各トランザクションは、ブロックチェーン・システムの参加者間のディジタル資産のコントロールの移動をエンコードするデータ構造であり、少なくとも1つの入力及び少なくとも1つの出力を含む。各ブロックは、共にチェーン化されるようになる先行するブロックのハッシュを含み、開始以来ブロックチェーンに書き込まれている全てのトランザクションについての永続的で変更不可能な記録を作成する。トランザクションは、トランザクションの入力及び出力に組み込まれるスクリプトと呼ばれる小さなプログラムを含み、スクリプトは、トランザクションの出力がどのように誰によってアクセスされ得るかを指定する。ビットコイン・プラットフォームでは、これらのスクリプトはスタック・ベースのスクリプト言語を使用して書かれる。
【0004】
トランザクションがブロックチェーンに書き込まれるためには、それが「検証済み(validated)」でなければならない。幾つかのネットワーク・ノードは、マイナーとして振る舞い、各トランザクションが有効であることを保証するために作業を行い、無効なトランザクションはネットワークから拒否される。例えば、ノードにインストールされたソフトウェア・クライアントは、未使用残高(unspent transaction output:UTXO)を参照するトランザクションに対してこの検証作業を実行する。検証は、そのロック及びアンロック・スクリプトを実行することによって実行されてもよい。ロック及びアンロック・スクリプトの実行がTRUEに評価され、特定の他の条件が満たされる場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれることができる。従ってトランザクションがブロックチェーンに書き込まれるためには、i)トランザクションを受け取るノードによって検証され、トランザクションが有効である場合には、そのノードがそれをネットワーク内の他のノードへ中継すること;及びii)マイナーによって構築された新しいブロックに追加されること;及びiii)採掘されること、即ち、過去のトランザクションの公の台帳に追加されることを要する。トランザクションを実質的に不可逆的にする程度に十分な数のブロックがブロックチェーンに追加されると、トランザクションは合意されたと考えられる。
【0005】
ブロックチェーン技術は、暗号通貨の実装を利用することに最も広く知られているが、ディジタル起業家は、新しいシステムを実現するために、ビットコインが基礎としている暗号セキュリ・ティシステムと、ブロックチェーンに格納され得るデータとの双方を使用することを探求し始めている。ブロックチェーンが、暗号通貨での支払いに純粋に限定されない自動化されたタスク及びプロセスに使用され得るならば、非常に有利であろう。このようなソリューションは、ブロックチェーンの利点(例えば、イベントの恒久的な改ざん防止記録、分散処理など)を、それらの用途でいっそう多様化しつつ利用し得るであろう。
【0006】
1つの研究分野は「スマート契約(smart contracts)」の実装のためにブロックチェーンを利用することである。これらは、機械読み取り可能な契約又は合意の条件の履行を自動化するように設計されたコンピュータ・プログラムである。自然言語で書かれる伝統的な契約とは異なり、スマート契約は、結果を生成するために入力を処理することが可能であり、次いでそれらの結果に依存してアクションを実行させることが可能なルールを含む機械実行可能プログラムである。
【0007】
ブロックチェーン関連の他の関心領域は、ブロックチェーンを介して現実世界のエンティティを表現及び転送するための「トークン」(又は「カラー・コイン」)を使用することである。潜在的にセンシティブな又は秘密のアイテムは、認識可能な意味又は値を持たないトークンによって表現されることが可能である。従って、トークンは、現実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。
【0008】
US2015/0287026は、ホット・ウォレット・サービス・システムを開示している。ホット・ウォレット・サービス・システムは、1つ以上のユーザ・デバイスから金融トランザクションを受信し、マルチ署名認証システムを実装する複数の認証サーバーを使用して金融トランザクションを認証し、ディジタル署名を集約し、認証された金融トランザクションを仮想通貨ネットワークに伝搬させる。金融トランザクションが仮想通貨ネットワークにより伝播されると、金融トランザクションは、通常の方法で仮想通貨ネットワークのマイナー・エンティティによって、公の共有台帳に組み込まれることが可能である。ホット・ウォレット・サービス・システムは仮想通貨ネットワークを監視し且つクレジット・レーティング及びスコアを生成することが可能な分析システムを更に有し、クレジット・レーティング及びスコアは、例えば、所定の金融トランザクションがマルチ・シグネチャ認証システムによって処理されることを防止するために使用され得る。
【0009】
CN106548349は、ブロックチェーン・ネットワーク内の全てのノードが全てのトランザクションのトランザクション情報を検証する必要がある場合、このプロセスはかなりのワークロードを生成し、ノードに多大な圧力をかけてしまう問題に関連している。CN106548349に記載されているソリューションは、全てのノードがトランザクション情報を検証しなければならないことを要求するのではなく、トランザクション情報を検証するために、第1のノードから複数の選択された第2ノードへトランザクション情報を伝搬することである。第2ノードはランダムで不規則な方法で選択され、悪意のある詐欺(fraud)の可能性を防止し、全てのノードがトランザクション情報を検証する必要もない。
【0010】
WO2017/162904は、トランザクション遅延が削減され、リソースの二重送金が、リソース管理システムで新ブロックが確立される前にトランザクションを検証することにより軽減される、ブロックチェーン・ベースのリソース管理システムに関連している。少なくとも1つの検証ノードは、トランザクションを検証し、検証受諾メッセージをマーチャントに提供し、アイテムを顧客にリリースするために提供される。従って、ブロックチェーンの次のブロックが確立されるのを待たずに、売却を確実に完了させることができる。また、検証ノードは、検証ノードのセットに検証リクエストを配布し、検証ノードのセットからレスポンスを受信できることも開示されている。次いで、検証ノードは、検証ノードのセットからのレスポンスの何れもがトランザクションに対する拒否ではない場合であってその場合に限り、検証受諾メッセージをマーチャントに送信してよい。ブロックチェーン内でブロックを確立する時が到来した場合に、ブロックを確立するノードは、直近に確立されたブロック以降に行われた一連のトランザクションをコンパイルすることができ、次のブロックはこの一連のトランザクションを含むことが更に開示されている。
【0011】
US2016/0259937、WO2017/004527、及びWO2017/011601は、現在のビットコイン・ブロックチェーン・ネットワークがどのように構成され機能するかを説明している。特に、個々のトランザクションは、ネットワークを介して伝播され、マイニングによりブロックチェーンに組み込まれ、ここで、マイニング・ノードは、トランザクションのセットを選択し、トランザクションをプロトタイプ・ブロックにグループ化し、従来の「プルーフ・オブ・ワーク」方式でノンスの値を決定する。マイナーが有効なノンスを発見すると、そのブロックは他のノードによって検証され、ブロックチェーンに組み込まれる。
【0012】
US2015/0310424は、マルチ・モーダル暗号鍵アドレス・マッピングによってユーザ・ディレクトリ・データを生成するシステムを開示している。暗号通貨ネットワークは暗号ノードを備え、暗号通貨のユーザのトランザクションのセットを公に検証する。ノードは、トランザクションを中継し、検証台帳を維持し、及び/又は暗号通貨をマイニングすることによって、暗号通貨ネットワークに参加することができる。
【発明の概要】
【0013】
本書執筆時点で、ビットコイン・ブロックチェーン・ネットワークは、約2000トランザクションを含むブロック・サイズに基づいており、ブロックは約10分ごとにマイニングされている(10分のブロック時間は、最初の確認時間とチェーン・スプリットに費やされる時間との間の妥協として設定されている)。これは約3.5トランザクション/秒というトランザクション処理速度を提供する。対照的に、VISAシステムは、約10000トランザクション/秒というトランザクション処理速度で動作し、50000トランザクション/秒以上に到達し得る。
【0014】
競争力のある決済システムを構築するためには、ブロックチェーン・ネットワークの現在の制約を何らかの方法で回避する必要があることは明らかである。10分のブロック時間は十分に制定されているので、ブロック・サイズ、従ってブロックチェーン自体の変更を考慮することが必須である。本明細書では、例えば約5万トランザクション/秒を処理し得るスケーラブルなソリューションが説明される。重要なことに、非セントラルかされた分散されシステム・アーキテクチャを維持しながら、高いトランザクション速度をサポートし得るソリューションが提供される。
【0015】
ビットコイン・ネットワークの現在のアーキテクチャから、大量の同時トランザクションが処理され得るものへの移行は、ネットワーク全体にインフラストラクチャ負担圧力をかける。多数のトランザクションをより効率的に、より高速に検証し中継することが可能なノードのシステムが提案されている。トランザクションの量に起因して、分散アプローチが、メモリプール(mempool)(まだ処理されておらずブロックチェーンに保存されていない未処理トランザクション)の設計において提案される。大量に増加したトランザクションは、ブロック・サイズに圧力をかけ、ブロック・サイズが所定の制限を超えると、ストレージ・インフラストラクチャの問題が生じることになる。本明細書では、大きなギガバイト・サイズのブロックを処理及び格納する問題に対するソリューションが説明される。
【0016】
本明細書は修正されたブロックチェーン・ネットワーク・アーキテクチャを記載しており、修正されたアーキテクチャは複数の専用トランザクション検証ノードを含み、そのノードは、トランザクションを検証し、ブロックチェーン・ネットワーク内の他のトランザクション検証ノードと共に、検証されたトランザクションを分散された非セントラル化されたストレージを維持するように構成される。トランザクション検証ノードは、更に、検証済みトランザクションのリストをマイナーのために準備し、検証済みトランザクションのリストをマイナーに提供する代わりに、ディジタル資産のためのコミットメント・トランザクションを作成するように構成される。従って、専用トランザクション検証ノードは、トランザクションを検証し、検証済みトランザクションのリストを構築し、及びこれらのリストを有償でマイナーに提供するという観点から、マイナーにサービスを提供する。トランザクションがマイニングされると、マイニングされたトランザクションはトランザクション検証ノードに戻され、トランザクション検証ノードは、マイニングされたトランザクションの大きなブロックを構築し、専用ストレージ・ノードに大きなブロックを格納する。
【0017】
本発明の一態様はトランザクションを受信し、検証し、格納し、マイニングのためにブロックチェーン・ネットワークへ分配する検証ノードにおける方法に関連する。ブロックチェーン・ネットワークのトランザクション検証ノードのためのコンピュータ実装方法が提供され、コンピュータ実装方法は:
【0018】
(i)ブロックチェーン・ネットワークからトランザクションを受信するステップ;
(ii)ブロックチェーン・ネットワークから受信したトランザクションを検証するステップ;
(iii)ブロックチェーン・ネットワーク内の他のトランザクション検証ノードとともに、検証されたトランザクションの分散された非セントラル化されたストレージを維持するステップ;及び
(iv)検証されたトランザクションに対応するデータを、マイニングのためにブロックチェーン・ネットワークへ分配するステップを含む。
【0019】
マイニングのためにブロックチェーン・ネットワークへ分配される検証されたトランザクションに対応するデータは、検証されたトランザクションのリストを含む。各々のリストは、ブロックへのマイニングのために検証されたトランザクションの完全なリストを提供することができる。
【0020】
このような方法は、ブロックチェーン・ネットワーク内の他のトランザクション検証ノードとの検証済みトランザクションの分散された非セントラル化されたストレージを維持しつつ、検証機能を実行するマイナーの要件を効果的に除去する。更に、この方法は、トランザクション検証ノードが、検証されたトランザクションに対応するデータを準備し、マイニングのためにブロックチェーン・ネットワークに分配することにより、マイナーにサービスを提供することを可能にする。例えば、本方法は、検証されたトランザクションのリストが、準備され分配されることを可能にする。
コンピュータで実現される方法は更に:
(v)検証されたトランザクションに対応するブロックチェーン・ネットワークから採掘されたデータを受信するステップ;
(vi)採掘されたデータに基づいてブロックを組み立てるステップ;及び
(vii)ブロックチェーンに格納するためにストレージ・エンティティへ、組み立てられたブロックを送信するステップ;
を含むことが可能である。
これらの更なる方法は、大きなブロックを構築して格納し、そのようなブロックをブロックチェーン・ネットワークで伝送することをマイナーに要求することなく、検証ノードが、ストレージ・エンティティに格納されるべきラージ・ブロックを構築することを可能にする。更に依然としてアーキテクチャは、大きく且つ依然として成長しつつあるブロックチェーンを格納することに特化したラージ・スケール・ストレージ・エンティティを使用することを許容する。
【0021】
ブロックチェーン・ネットワーク内の他のトランザクション検証ノードとの検証済みトランザクションの分散された非セントラル化されたストレージを維持するステップは、分散され非セントラル化された方法で検証済みトランザクションの最新リストを維持するために、ブロックチェーン・ネットワークのトランザクション検証ノードを同期化するステップを含んでもよい。例えば、検証ノードは、可逆ブルーム・フィルタ・ルックアップ・テーブル(invertible bloom filter lookup tables)を交換することによって同期させられることが可能である。検証されたトランザクションはまた、検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、ブロックチェーン・ネットワーク内のトランザクション検証ノードにわたって共通のオーダリング・システムが使用されるように、定義された順序でソートされることも可能である。例えば、正規のオーダリング・システムは、検証済みトランザクションの分散された非セントラル化されたストレージを維持するために使用されることが可能である。これは、ネットワークを横断するトランザクション・データが一貫した方法で維持されることを保証する一方、非セントラル化された分散されたストレージを保持する特に効率的な方法であることが発見された。
【0022】
検証されたトランザクションに対応するデータを、マイニングのためにブロックチェーン・ネットワークに分配するステップは、検証されたトランザクションのリストに対応するデータ(可逆ブルーム・ルックアップ・テーブル及び検証されたトランザクションのリストに対応する任意の付随データであって、検証されたトランザクションがブロックに含まれているもの)を準備するステップを含むことが可能である。更に、検証されたトランザクションに対応するデータを、マイニングのためにブロックチェーン・ネットワークに配布するステップは、検証されたトランザクションのリストに対応するデータをマイナーに提供するのと引き換えに、ディジタル資産のコミットメント・トランザクションを作成するステップを含むことが可能である。例えば、ハッシュ(マークル)ツリー、パトリシア・ツリー、又は他のタイプのラディックス・ツリー(radix tree)が、包含されるコミットメント・トランザクションとともに計算されることが可能である。
【0023】
検証トランザクションに対応するデータが配布され、関連する暗号パズル、例えばハッシュ・パズルを解くことによってマイニングされた後、マイニングされたデータは、マイナーによってブロックチェーン上で直接的に格納されるのではなく、トランザクション検証ノードへ返送される。次に、このマイニングされたデータが、(大きな)ブロックに組み立てられ、大量のデータの格納のために特別に構成されたストレージ・エンティティに及び/又は分散されたストレージ・システムの何れかに格納されることが可能である。上述したように、これは、大きなブロックを構築及び格納し、そのようなブロックをブロックチェーン・ネットワークで送信することをマイナーに要求せずに、ストレージ・エンティティに格納される大きなブロックを、検証ノードが構築することを可能にする。更に、アーキテクチャは、常に成長し続ける大きなブロックチェーンを格納する専用の大規模ストレージ・エンティティの使用を可能にする。
【0024】
ブロックチェーン・ネットワークから受信されるマイニングされたデータは、検証されたトランザクションに対応するブロック・ヘッダを含むことが可能である。マイニングされたデータはまた、採掘されたデータに基づいてブロックをアセンブル及び/又は記憶することに対するディジタル資産のトランザクションを含むことができる。更に、この方法は、ディジタル資産を受信する前に、最小ブロック数に関連付けられた期間tの間待機する条件を含むことが可能である。これは、プロバイダが、検証済みトランザクションのリストを(例えば、可逆ブルーム・ルックアップ・テーブルの形式で)マイニングのために提供すること、及び/又はマイニングされたブロックをブロックチェーン上で格納することに対して報いられるように、検証ノードを提供するためのインセンティブ・スキームを提供する。ディジタル資産を受け取る前に最低期間を必要とすることは、或る範囲のノードへスケルトン・ブロック(支払いを含む)を伝播させるようにマイナーにインセンティブを与え、ノードは他のノードへスケルトン・ブロックを伝播するようにインセンティブを受ける。
【0025】
マイニングされたデータに基づいてブロックを組み立てるステップは、例えば、各ブロックが少なくとも2、4、6、8、10、50、100、500、1000、又は10000メガバイトのサイズを有する大きなブロックを組み立てるステップを含み得る。経時的に上限は増えるが、1ペタバイトという公称上限値が指定されてもよい。各ブロックは、例えば、少なくとも5000、10000、50000、100000、500000又は1000000トランザクションを含み得る。上限は時間の経時的に増えるが、1ブロック当たり1012トランザクションという公称上限値が指定されてもよい。上述したように、本明細書に記載された方法、ノード、及びブロックチェーン・ネットワーク・アーキテクチャは、多数のトランザクションを構築及び記憶することをマイナーに要求せずに、ラージ・ブロックが構築され及びストレージ・エンティティに記憶されることを可能にする。これは、システムが大幅に引き上げられたトランザクション速度を処理できるようにする。
【0026】
本明細書に記載される方法では、ブロックは、マイナーによって提供される乱数を含むブロック・ヘッダを含むように修正され得る。即ち、トランザクション検証ノードは、ブロックチェーン・ネットワークから解決されたトランザクションを受信する場合に、マイナーによって提供された乱数を含むブロック・ヘッダを含むブロックを処理するように構成されることが可能である。これは、ブロック・ヘッダに対する変更を構成し、それによって、マイナーはブロック・ヘッダに挿入される番号を選択したり、又はランダムに生成したりすることが可能である。これは、たとえ同じトランザクション・リストが多数のマイナーによって選ばれたとしても、マイナー達が同一のブロックを採掘しようと競わないことを保証する助けとなる。
【0027】
データの上述のラージ・ブロックを記憶する記憶装置は、ブロックチェーン・ネットワーク上の複数のトランザクション検証ノード間で共用されることが可能であり、複数のトランザクション検証ノードは、ブロックチェーン・ネットワーク上でスーパー・ノードを形成し、共用される記憶装置は、共通のストレージ・ノード、分散されたストレージ、又はそれら2つの組み合わせの何れかである。このアーキテクチャは、ブロックチェーン・ネットワーク上のスーパー・ノードの形成を導出し、ブロックチェーンを記憶し、ブロックチェーン・ネットワークにサービスを提供する専用記憶装置の提供を可能にする。
【0028】
上記に鑑み、ブロックチェーン・ネットワークのスーパー・ノードもまた提供され、スーパー・ノードは:
上述されたような複数の検証ノード;及び
ブロックチェーンを格納する共有されるストレージ・エンティティ;
を備え、共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又はそれら両者の組み合わせの何れかであり、及び
複数の検証ノードにより組み立てられたブロックは、共有されるストレージ・エンティティへ送信され格納され、それにより共有されるストレージ・エンティティはブロックチェーンを維持する。
【0029】
このアーキテクチャは、本明細書に記載される方法及び構成の目的であるトランザクション・レートの所望の増加を達成するために必要とされる大きなブロック・サイズを処理することにいっそう適している。例えば、共有されるストレージ・エンティティは、少なくとも100ギガバイトのストレージ容量、より好ましくは少なくとも1、10、100、又は1000テラバイトのストレージ容量を有するように構成され得る。上限は経時的に増加するが、106テラバイト、場合によっては106ヨタバイトという公称上限値が指定され得る。
【0030】
全体的なネットワーク・アーキテクチャに関し、複数のこのようなスーパー・ノードを含むブロックチェーン・ネットワークが提供され得る。スーパー・ノードは、ブロックチェーン・ネットワークで接続されることが可能であり(ただし、重複しない)、各スーパー・ノードの共有されるストレージ・エンティティは、ブロックチェーンのコピーを格納するように設定される。スーパー・ノードは、スーパー・ノードとして機能するプールを形成するノードのグループを効果的に含む。ブロックチェーンの分散された性質を維持するためには、有利なことに、一定数の(例えば、少なくとも10、50、100、又は1000であり、選択的に100,000,000未満の)そのようなスーパー・ノードが存在すべきである。
【0031】
本発明の実施形態は、様々な形態で提供され得る。例えば、実行されると本明細書に記載されている方法を実行するようにプロセッサを構築するコンピュータ実行可能命令を含むコンピュータ読み取り可能な記憶媒体が提供され得る。電子デバイスはまた:インターフェース;インターフェースに結合される1つ以上のプロセッサ;及び1つ以上のプロセッサに結合されるメモリを有するように提供されることが可能であり、メモリは、実行されると、本願で説明されている方法を1つ以上のプロセッサに実行させるコンピュータ実行可能命令を保存している。更に、ブロックチェーン・ネットワークの検証トランザクション・ノードが提供されることが可能であり、検証トランザクション・ノードは、本明細書で説明される方法を実行するように構成される。
【0032】
本明細書で説明される発明は、以下説明されるように、背景技術のセクションで議論される先行技術とは異なる。
【0033】
US2015/0287026のホット・ウォレット・サービス・システムは、トランザクションを受信し、トランザクションを認証し、トランザクションをマイニングのためにブロックチェーン・ネットワークへ分配することを開示しているように思われる。しかしながら、US2015/0287026のホット・ウォレット・サービス・システムは、ブロックチェーン・ネットワークにおける他のトランザクション検証ノードとともに、検証されたトランザクションの分散された非セントラル化された格納を維持していない。むしろUS2015/0287026のホット・ウォレット・サービス・システムは、複数のサービスを利用してマルチ・シグネチャ認証システムを扇動している。認証ファクタを集約することにより以後に検証される任意のトランザクションが、仮想通貨ネットワークへ伝播されているに過ぎず、分散された非セントラル化された方式でホット・ウォレット・サービス・システムに格納されていない。更に、検証されたトランザクションのリストを準備すること、及び検証されたトランザクションのリストをマイナーに提供することに対する見返りとしてディジタル資産のコミットメント・トランザクションを作成すること、についての示唆はUS2015/0287026に存在しない。
CN106548349はトランザクションを受信し、トランザクションを検証し、検証したトランザクションをマイニングのためにブロックチェーン・ネットワークへ分配することを開示しているように思われる。しかしながら、CN106548349は、ブロックチェーン・ネットワークにおける他のトランザクション検証ノードとともに、検証されたトランザクションの分散された非セントラル化された格納を維持することを開示していない。更に、検証されたトランザクションのリストを準備すること、及び検証されたトランザクションのリストをマイナーに提供することに対する見返りとしてディジタル資産のコミットメント・トランザクションを作成すること、についての示唆はCN106548349に存在しない。
WO2017/162904はトランザクションを受信し、トランザクションを検証し、検証したトランザクションをブロックチェーンに組み込むために分配することを開示しているように思われる。しかしながら、2017/162904は、ブロックチェーン・ネットワークにおける他のトランザクション検証ノードとともに、検証されたトランザクションの分散された非セントラル化された格納を維持することを開示していない。更に、検証されたトランザクションのリストを準備すること、及び検証されたトランザクションのリストをマイナーに提供することに対する見返りとしてディジタル資産のコミットメント・トランザクションを作成すること、についての示唆はWO2017/162904に存在しない。
【0034】
US2016/0259937、WO2017/004527、及びWO2017/011601は、マイニング・ノードが一組のトランザクションを選択し、そのトランザクションをプロトタイプ・ブロックにグループ化し、従来の「プルーフ・オブ・ワーク」方式でノンスの値を決定することを開示している。いったんマイナーが有効なノンスを発見すると、そのブロックは他のノードによって検証され、ブロックチェーンに組み込まれる。US2016/0259937、WO2017/004527、及びWO2017/011601は、分散されたプールを提供するブロックチェーン・ネットワークにおいて他のトランザクション検証ノードとともに検証済みトランザクションの分散された非セントラル化された格納を維持し、検証済みトランザクションのリストがマイニングのためにマイナーに提供されることを開示していない。同様に、US2015/0310424は、トランザクションを受信し、トランザクションを検証し、他のトランザクション検証ノードとともに検証済みトランザクションの分散された非セントラル化された格納を維持し、検証済みトランザクションのリストを準備し、検証済みトランザクションのリストをマイナーに提供することに対する見返りとしてディジタル資産のコミットメント・トランザクションを作成する検証ノードを開示していない。
【0035】
上記に鑑みて、本発明はブロックチェーン・ネットワーク内で大きなギガバイト・サイズのブロックをより効率的に処理及び格納するためのユニークなアーキテクチャ及び方法を提供するものと確信する。
【図面の簡単な説明】
【0036】
本発明のこれら及び他の態様は、本明細書に記載される実施形態から明らかであり、それを参照して解明される。本発明の実施形態は、単なる例示として、添付図面を参照して説明される。
【
図2】
図2は、ユーザがトランザクションをサブミットした時点からブロックチェーン上で終了するまでのステップを示す動作図によるビットコイン・ネットワークの修正されたアーキテクチャを示す。
【
図3】
図3は、確認のためにメモリプールで待機しているトランザクションの合計サイズの一例を示すグラフを示す。
【
図4】
図4は、内的にセントラル化されたストレージ施設にリンクされた複数のノードを示す。
【
図5】
図5は、各ノードが、分散されたメモリプール及び分散されたストレージ施設双方の一部分である構成を示す。
【
図6】
図6は、新しいノード構造がビットコイン・ネットワークにどのように適合するかを示し、検証ノードがストレージ・プールのメンバーであり、プールが一緒に非セントラル化され分散されたビットコイン・ネットワークを構成するネットワーク構成を示す。
【
図8】
図8は、現在のプロトコルに対する修正を為す新しいマークル・ツリー構造を示す。
【
図9】
図9はブルーム・フィルタを作成するワークフローを示す。
【
図10】
図10は、トランザクションが、可逆ブルーム・フィルタ(IBF)及び可逆ブルーム・ルックアップ・テーブル(IBLT)でどのようにエンコードされるから示すワークフローを示す。
【発明を実施するための形態】
【0037】
本明細書では、大きなギガバイト・サイズのブロックを処理して格納する問題に対するソリューションが説明される。
【0038】
ブロックチェーン・ネットワーク・ノード及び検証ノードのタイプ
ブロックチェーン・ネットワークは、招待無しに及び他のメンバーからの同意も無しに、誰でも参加してよいピア・ツー・ピア・オープン・メンバーシップ・ネットワークとして説明されてよい。ブロックチェーン・ネットワークが動作するブロックチェーン・プロトコルのインスタンスを実行する分散された電子デバイスは、ブロックチェーン・ネットワークに参加することができる。このような分散電子デバイスは、ノードと称されることが可能である。ブロックチェーン・プロトコルは、例えば、ビットコイン・プロトコル又は他の暗号通貨であってもよい。
【0039】
ブロックチェーン・プロトコルを実行し、ブロックチェーン・ネットワークのノードを形成する電子デバイスは、例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、サーバー、コンピュータ・ファームなどのコンピュータ、スマートフォンなどのモバイル・デバイス、スマート・ウォッチなどのウェアラブル・コンピュータ、又は他の電子デバイスなどの様々なタイプのものであってもよい。
【0040】
ブロックチェーン・ネットワークのノードは、有線及び無線通信技術を含み得る適切な通信技術を使用して互いに結合される。多くの場合、ブロックチェーン・ネットワークは、少なくとも部分的にインターネットを介して実装され、ノードの幾つかは、地理的に分散した場所に配置され得る。
【0041】
現在、ノードは複数のブロックにグループ化されるブロックチェーン上の全てのトランザクションのグローバルな台帳を維持し、各ブロックはチェーン内で先行するブロックのハッシュを含む。グローバル台帳は、分散した台帳であり、各ノードは、グローバル台帳の完全なコピー又は一部のコピーを保存することができる。グローバル台帳に影響を与えるノードによるトランザクションは、他のノードによって検証され、グローバル台帳の有効性が維持される。ビットコイン・プロトコルを使用するもののようなブロックチェーン・ネットワークの実装及び動作の詳細は、当業者に理解されるであろう。
【0042】
各トランザクションは、典型的には、1つ以上のインプット及び1つ以上のアウトプットを有する。インプット及びアウトプットに埋め込まれたスクリプトは、トランザクションのアウトプットがどのように誰によってアクセスされ得るかを指定する。トランザクションのアウトプットは、トランザクションの結果として値が転送される先のアドレスであってもよい。この値は、未使用残高(UTXO)として、そのアウトプット・アドレスに関連付けられる。その後、後続のトランザクションは、その値を消費又は分散するために、インプットとしてそのアドレスを参照することができる。
【0043】
ノードは、それらの機能に応じて、異なるタイプ又はカテゴリのものであり得る。ノードに関連する4つの基本的な機能:ウォレット、マイニング、フル・ブロックチェーン・メンテナンス、及びネットワーク・ルーティングが存在することが示唆されている。これの機能についてのバリエーションが存在し得る。ノードは1つより多い機能を有していてもよい。例えば、「フル・ノード」は4つ全ての機能を提示する。ライトウェイト・ノードは、例えば、ディジタル・ウォレットに実装されてもよく、またウォレット及びネットワーク・ルーティング機能のみを発揮してもよい。ディジタル・ウォレットは、ブロックチェーン全体を格納するのではなく、ブロックを照会する場合にインデックスとして役立つブロック・ヘッダを追跡することができる。ノードは、TCP/IP(伝送制御プロトコル)等のコネクション指向プロトコルを用いて互いに通信する。
【0044】
ノードの追加のタイプ又はカテゴリが提供されてもよい:マーチャント・ノード(a merchant node)(本明細書では、しばしば「M-Node」と呼ばれる)。M-Nodeは、トランザクションの高速伝搬に焦点を当てるように設計されている。それらは、完全なブロックチェーンを記憶しても記憶しなくてもよく、マイニング機能を実行しない。その意味で、それらはライトウェイト・ノード又はウォレットに類似しているが;トランザクションの高速伝播を可能にする追加の機能を含んでいる。M-Nodeの運用上の焦点は、未確認トランザクションの迅速な検証と伝播、特に他のM-Nodeへの伝播であり、当該他のM-Nodeから、未確認トランザクションはブロックチェーン・ネットワークの他のノードへ迅速にプッシュされる。この機能を容易にするために、M-Nodeには、管理プロトコルの下でノードに対して許可される可能性のある、進入する及び特に進出する多数のコネクションが許可される。
【0045】
M-Nodeは、マーチャント・ネットワーク(又は「M-net」)と総称されてもよい。「マーチャント」という用語は「専門的な(specialised)」という意味として解釈されてもよい。M-Nodeはブロックチェーン・ネットワークに統合されてもよい。各々のM-Nodeは、ブロックチェーン・ネットワークにおける特殊なノードであり、M-Nodeの機能を実行できることを保証する特定のハードウェア及びパフォーマンス能力を満たす。即ち、M-netはブロックチェーン・ネットワーク内のサブ・ネットワークと考えられ、ブロックチェーン・ネットワークを通じて分散され得る。M-Nodeは、一つ以上の専用の機能又はサービスを実行するように配置され及び構成されてもよい。
【0046】
M-netが確実に動作し、所定のセキュリティ・レベルでサービスを提供できるようにするためには、M-nodeはM-net全体の良好な概観を維持する必要があり、従って効率的なルーティング・プロトコルが整っている必要がある。M-nodeが開始トランザクションを受信するたびに、他のノードに加えて、幾つかの他のM-nodeへそれをブロードキャストする必要がある。M-netの状況では、これは複数巡回セールスマン問題(MTSP)の解を見つけることになる。この問題に取り組む解決策は多数存在し、そのうちの1つがM-netで使用されてもよい。M-nodeの各々は何らかの最新の形式でルーティングの最適化を実行する。
【0047】
幾つかの実装では、M-netは非セントラル化されたIPマルチキャスト・タイプのネットワークとして実装される。即ち、ブロックチェーン・ネットワークへの到来するトランザクションの高速な拡散を可能にするために、マルチキャストが使用されてもよく、トランザクションがM-netを通じて迅速にブロードキャストされることを保証し、次いで全てのM-ノードが、ブロックチェーン・ネットワーク内の他のノードへトランザクションを転送することに焦点を合わせることを可能にする。
【0048】
マルチキャスト・ネットワーク・アーキテクチャは、情報を受け取ることに関心のある各ノードに対するデータの重複なしに、宛先ノードのグループへのデータの同時分配の可能性を許容する。ノードがマルチキャスト送信を受信することを希望する場合、マルチキャスト・グループに参加し(登録段階)、その後、マルチキャスト・グループ上で送信された全てのデータを受信することができるであろう。IPマルチキャストは、何台の受信機が存在するかについての事前知識を必要とセズに、より大きな受信者集団に拡大することが可能であり、ネットワーク・インフラストラクチャは、1回だけパケットを送信することをソースに要求することによって、効率的に使用される。マルチキャスト・ネットワークの性質のために、(TCPのような)コネクション指向プロトコルの使用は、多数の他のノードとの同時通信に起因して実用的ではない。従って、コネクションレス・プロトコルが使用される。
【0049】
ビットコイン等の幾つかのブロックチェーン・ネットワークは、ノード・ツー・ノード通信にTCPを使用する。TCPを使用して送信されるデータ・パケットは、順序付けのために使用される関連シーケンス番号を有する。これに加えて、TCPプロトコルは、コネクションを確立する時と終了する時の両方で、3方向ハンドシェイク手順を含む。TCP上で送信されるパケットは、関連するオーバーヘッドと共に到来し、それらは関連するシーケンス番号を有し、3方向ハンドシェイク・プロトコルがある。コネクションを確立するには、128~136バイトが送信され、コネクションを閉じるには160バイトのコストがかかる。従って、パケット伝送におけるハンドシェイクは、高々296バイトのコストがかかる。更に、ノードが新しいトランザクションを受信すると、他のノードに、トランザクションのハッシュを含むインベントリ(INV)メッセージを通知する。INVメッセージを受信するノードは、そのトランザクションのハッシュが以前に発見されているか否かを検査する:発見されていない場合、ノードはGETDATAメッセージを送信することによってトランザクションを要求する。ノードAからノードBへトランザクションを送信するために必要な時間は、
T1=verification+TCP(inv+getdata+tx)
であり、TCP()は、TCPハンドシェイク手順によって導入されるオーバーヘッドを時間の観点から示す。
【0050】
M-nodeは、ビットコインのように、既存のプロトコルによって強制される他ノードとの通信のためにTCPを使用するように設定されてもよい。しかしながら、それらは、M-nodeからM-nodeへの通信、あるいは、より適切には、マルチキャスト状況においてM-nodeから複数のM-nodeへの通信のために、ユーザ・データグラム・プロトコル(UDP)等のコネクションレス・プロトコルを使用してもよい。TCPとは異なり、UDPはハンドシェイク・プロトコルを含まないので、M-nodeはより速やかにトランザクションを伝播することができる。これは、実際のトランザクションを送信することなく繰り返されるINVメッセージを送信することによって、悪意のノードが他ノードと結びつくことを回避することも可能である。
【0051】
UDPのライトウェイトの性質は或る種のトレードオフに関連する。誤り検査が少なく、誤り復元も行われない。幾つかの実装では、これらのUDPの制限は、アプリケーション・レイヤの機能として、誤り復元、順序付け、及び再送を実装することによって、アプリケーション・レベルで克服されることが可能である。アプリケーション・レベルで誤り検査を行うことは、ネットワークからオーバーヘッドを排除する。
【0052】
一例では、ブロックチェーン・ネットワーク上の通常のノードは、マーチャント・ベースの支払いのような、M-netを介して処理されることを望むトランザクションを生成する。それはトランザクションをM-nodeへ送信することができ、M-nodeは次いでマルチキャストを使用してそれを他のM-nodeへブロードキャストしてもよいし、或いはM-nodeのIPマルチキャスト・アドレスを知っている場合には、トランザクションを複数のM-nodeへ直接的に送信してもよい。幾つかの例では、M-netのすべてのM-nodeは単一のマルチキャスト・アドレスのメンバーであり、従って、そのアドレスに送信される全てのトランザクションは、全てのM-nodeによって受信される;しかしながら、場合によっては、M-netに関連する1つより多いマルチキャスト・アドレスが存在してもよく、受信M-nodeは、トランザクションを完全なM-netへ伝搬するために、トランザクションの他のマルチキャスト・アドレスへの更なるブロードキャストが必要か否かをルーティング情報から評価してもよい。
【0053】
マルチキャストは、全てのM-nodeへの新しいトランザクションの高速な初期伝播を確実にすることを支援する;しかしながら、マルチキャスト・ソリューションは、トランザクション・スループットの増加に起因するブロックチェーン・ネットワークのスケーラビリティ問題に必ずしも取り組んでいない。ネットワークの各ノードは、典型的には、発見されて確認されていないトランザクションを含むメモリプールであって、プルーフ・オブ・ワークを完了するマイナーによって未だブロックチェーンに組み込まれていないメモリプールを維持する。支払処理での使用から生じるトランザクション数の著しい増加は、各メモリプールに格納するトランザクション量を増やす。従って、M-net中のノードは、ほぼ同時に新しいトランザクションを受信することができるが、それらは、大きく且つ急速に変化するメモリプールに関して、記憶能力の制限を有し得る。
【0054】
この問題に対処するために、M-nodeは、マルチキャストを使用する代替例として、分散ハッシュ・テーブル(DHT)によって実装される共有メモリを使用することができる。
【0055】
500バイトというトランザクション(TX)の平均サイズ、~104TX/sという伝送レートを仮定すると、M-netは、毎日約400GBの入力データを受信し得る。このデータは全て、未確認トランザクションのメモリプールの中でさまざまな期間にわたって格納されることを要する。従って、M-netは、データを高速に記憶するために、かなりのストレージ及び能力を必要とする。個々のM-nodeそれぞれに過剰に多くの要求を課さないために、M-nodeはDHTを当てにする共有メモリを実装する。各M-nodeが全ての到来するTXを自身のメモリプールに保持する代わりに、各M-nodeは全体のうちの特定の部分と、残りの部分のハッシュ及び関連するキー値とを保持するのみである。
【0056】
DHTは非セントラル化された分散システムのクラスであり、ノード間のキー・セットのメンバシップ分割を可能にし、所与のキーの所有者に対してのみ効率的かつ最適化された方法でメッセージを送信することができる。ネットワークの各ノードはハッシュ・テーブルのアレイのセルとして見ることが可能である。DHTは、多数のノードを管理するために設計され、新しいノードがネットワークに参加し、古いノードが離脱及びクラッシュする可能性を、共有データの完全性を損なうことなく許容する。DHTは、非セントラル化(中央の権限も中央による調整もない)、スケーラビリティ(システムは何百万ものノードで効率的な動作をする)、及びフォールト・トレランス(システムは信頼性があり、ネットワークに参加、離脱又はクラッシュするノードを管理することができる)を保証する。ネットワークの各ノードは、少数の他ノードとのみ接触し続けることができ、従って、変化があった際又は新しいデータの存在下において、ネットワークはオーバーロードにならない。
【0057】
同じ概念は、UTXOデータベース、即ちブロックチェーン上のすべての未使用アウトプット力のセットを含むデータベースに適用され得る。UTXOデータベースは、一群のノードの間で内容を共有するために、DHTを使用して構築され得る。
【0058】
M-netのための共有メモリを実装するために使用され得る多くの可能なDHTアーキテクチャ及びプロトコルがある。一例はPastry(商標)であるが、他にも多くの例がある。Pastry(商標)は、分散システムで情報を格納して転送することが可能なオーバレイ・ネットワークを維持するために設計されたプロトコルである。Pastry(商標)ネットワークの各ノードには、128ビットの識別子が割り当てられ、識別子は(0から2128-1に及ぶ)巡回ノードID空間内のノードの位置を示すために使用される。IDは、ノードがネットワークに参加する場合にランダムに指定される。各ノードは、ルーティング・テーブル、隣接セット(a neighbourhood set)、及びリーフ・セット(a leaf set)を維持する。
【0059】
ロバストなDHTの寸法決定において考慮すべき1つの要因は、ネットワーク全体のロバスト性と信頼性とを保証するために必要なレプリカの数である。既に述べたように、ノードはネットワークに参加したり立ち去ることが可能であり、このことはデータの利用可能性に影響を与えるべきでない。トランザクションAを格納するノードがネットワークを離れる場合、ネットワークの別の部分でトランザクションAを発見する必要がある。例えばビットコインのような既存のブロックチェーン・ネットワークでは、ネットワークは、ネットワーク内の全ノード数(平均5000レプリカ)に等しい数のブロックチェーン・レプリカを有しているが、このことはスケーラビリティに影響する。
【0060】
1つのM-net構成では、メモリプールは、全てのM-nodeで完全に複製されるわけではなく、代わりにDHTによって実現される。信頼性を提供するために、DHTは、幾つかのオーバーラップを有するように実装されてもよく;即ち、各トランザクション・データ・アイテムは、1つより多いM-nodeで複製されるが、全てのM-nodeにおいてではない。例として、DHTは、2つのレプリカという最小数を指定するように実装され得る。これは、2つのノードが任意の所与の1時間に一度に落ちる確率をもたらし、これは、次のようなノード間の完全な独立性を仮定している。
【数1】
【0061】
従って、分散されたメモリプールに新しいトランザクションを格納するためのプロセスは、以下のステップを含み、ここで分散されたメモリプールはDHTを用いて実装される。プロセスは、ノードがM-nodeへトランザクションを送信することを含む。M-nodeは、キー値を取得するために、実装に応じてトランザクション又はトランザクションIDをハッシュする。キー値は、トランザクションが格納されるべきM-node又は複数のM-node(複製されたデータの場合)を指定する。次に、M-nodeはトランザクションを分散されたメモリプールに格納し、このプロセスは、M-net内のM-nodeのキー値及び割り当てられたIDに基づいて、トランザクションが格納されるべき正しいM-ノードへトランザクションをルーティングすることを含んでもよい。M-nodeは、関与するDHTプロトコルに応じて、確認応答を受信してもよい。M-nodeが正規のノードから新しいトランザクションを受信すると、M-nodeはトランザクションの真正を検証するために所定の検証オペレーションを実行することができる。
【0062】
トランザクションは、トランザクションのキーを生成するためにハッシュされるかもしれない。キーは、現在のM-node以外のノードにあるかもしれない、DHT内のどこにトランザクションが格納されるべきかを示すことができる。M-nodeは、次いでトランザクションが既に動作中のDHTにあるか否かを評価する。各M-nodeは、M-netを構成するM-node間の鍵空間の分割に基づいて、格納されたトランザクションの一部を有する。幾つかの構成では、鍵空間は参加しているM-node間で分割される。この分割は、ネットワークの弾力性(resiliency)のための複製を引き起こすように、オーバーラップを含んでもよい。Pastry(商標)を使用するような幾つかの実装では、各々のM-nodeは固有のキー又はID番号の割り当てを受け、トランザクションは、トランザクションのキー値に対する近接性に基づいて、M-node又は複数のM-node(複製が望まれる場合)に格納されてもよい。M-nodeは、ローカルにトランザクションの格納された部分と、残りの部分のハッシュ値又はキー値とを有し得る。従って、M-nodeは、動作中のローカル・データに基づいて、新しいトランザクションがDHT内にあるか否かを評価することができる。
【0063】
トランザクションがDHT内にない場合、M-nodeは、動作中に、そのキー値に基づいて、トランザクションをDHTに格納する。一般的な意味においてこれは、put(k,tx)オペレーションの形式をとることが可能であり、kはキー値であり、txはトランザクションである。適用可能なDHTルーティング・プロトコルは、トランザクションが適切なM-nodeへ送信され、そこで保存されることを保証する。DHTは、選択される実装に依存して、分散されたハッシュ・テーブルに関する種々のプロトコルに従って機能することができる。M-netにトランザクションを格納するためのDHTの使用は、全てのM-nodeにトランザクションをルーティングするために、M-net内でINV/GETDATAメッセージを使用することを回避する。
【0064】
動作中に、M-nodeはこの例では、ブロックチェーン・ネットワークの通常のトランザクション転送プロトコルに従って、ブロックチェーン・ネットワーク内の正規のノードへトランザクションを送信することができる。例えば、通常のノードへの通信は、ノード・ツー・ノード接続のためにTCPを使用してもよい。
【0065】
ある構成では、M-nodeは、プロセッサ、ネットワーク・インターフェース、及びメモリを含む。M-nodeは任意の適切なコンピューティング・ハードウェアを使用して実現されることが可能であり、そのコンピューティング・ハードウェアは、ネットワーク接続性を有し、本明細書に記載の機能を実行するのに十分な処理及びメモリ・リソースを有する。M-nodeは、本明細書に記載の機能を実装するためのプロセッサ実行可能命令を含んでもよい。幾つかのケースにおいて、プロセッサ実行可能命令はブロックチェーン・マーチャント・ノード・アプリケーションと呼ばれてもよいが、この命令は、ハードウェア及びオペレーティング・システムに応じて、1つ以上のモジュール、アプリケーション、スクリプト、又は他のプログラミング構造で実装され得ることが理解されるであろう。プロセッサはマルチ・コア・プロセッサ及び/又は複数のプロセッサを含んでもよい。
【0066】
メモリは、部分的には、そのDHTキー値、即ちM-nodeIDに基づいて、DHTベースのメモリプールの割り当てられた部分を含むデータを格納する。この実装例では、メモリはルーティング・テーブル、近隣セット、及びリーフ・セットを更に格納する。ルーティング・テーブルは、M-net内の特定のルーティング宛先のリストを含み、ノードがデータのパケットを受信すると、そのデータを送信する場所を知るためにルーティング・テーブルを参照する。また、ルーティング・テーブルは、各宛先がM-nodeからどれだけ離れているかについての情報を含んでもよい。近隣セットは、例えば近接メトリック(例えば、ピンの待ち時間(ping latency))に基づいて、近接M-nodeに関する情報を含む。リーフ・セットは、数値的に近いM-nodeを含む。複数のM-nodeは、それらのキー値(ノードID)が数値的に近い場合、数値的に近い。メモリは、以下で更に説明されるように、M-nodeレピュテーション・テーブル(an M-node reputation table)を更に含む。
【0067】
スケーラビリティを提供するために、DHTを使用してメモリプールを実装することに加えて、M-netは、ノードがM-netに参加することを許容する。新しいノードはM-netの既に存在する部分の少なくとも1つのM-nodeのアドレスを有する必要があり、そのため、M-nodeの1つへ参加リクエストを差し向けることができる。M-nodeは、新しいノードを照会することを含み得る所定の検証アクションを実行することができる。例えば、M-netは、M-netがM-nodeに対して指定する、M-netに参加することに関連する一組の最小限の基準を有していてもよい。例示として、基準は、利用可能な最小限の処理リソース、利用可能な最小限の空きメモリ、又は接続要件を含むことができる。
【0068】
新しいノードを検証するために検証オペレーションが実行されるものが何であれ、M-nodeが完了したと仮定すると、DHTプロトコルがDHTのオペレーションを支配するものが何であれそれに従って、Joinrequest()をDHTへ転送する。次に、DHTは、新しいノードと通信し、ルーティング・テーブル、キー値(ノードID)、及び任意の他のデータを提供し、新たなノードがM-net上の新しいM-nodeとして機能することを可能にする。
【0069】
ノードがM-netに参加し得ることの容易性は、悪意のノードがネットワークに参加し得るという脆弱性を生み出すことが理解されるであろう。潜在的な悪意のノードを識別して隔離するために、1つの構成は、ノードの挙動ランキングを追跡及び更新するために使用されるM-node評判テーブルを格納するM-nodeを提供する。新しいノードがネットワークに参加すると、ノードIDフィールドによって示されるようにして、そのノードはM-node評判テーブルに追加され得る。テーブルは、幾つかの実装において、参加時間を更に含んでもよい。テーブルはそのM-nodeに関するスコア及び格付けを含む。
【0070】
スコアは、特定の行動メトリックに基づいて上下に調整され得る。例えば、M-nodeがトランザクションを転送することに失敗したり、一定期間にわたってサイレントのままであったり、トランザクションではないと判断されたトラフィックでM-netを溢れさせたり、あるいは、否定的な振る舞いに関わっている場合、そのランキングは、落とされたり又は減少させられたりする。ノードのスコアがあらかじめ設定された最小値を下回る場合、ノードはM-netから除外されるかもしれない。
【0071】
特定のM-nodeで維持されるM-node評判テーブルは、完全なM-netではなく、その近隣のスコアを追跡することに限定されてもよい。従って、新しいM-nodeが時刻tでネットワークに参加する場合、その近隣のM-node評判テーブルは、新しいノードについての情報を含んでおらず、その時点tから、それらは、ノード・レジスタ・テーブルに情報を格納する新しいノードの評判を構築し始める。例えば、新しいノードがサイレント・ノードである場合、それはネットワーク上で受け取る情報を転送しないことを意味し、全ての隣接者は、例えば新しいノードのIDに負の値を割り当てるなど、各自それぞれのM-node評判テーブルにこの挙動を記録し始める。ある時間t+nの後、新しいノードに気付いている全てのノードのM-node評価テーブルが負の値を含んでいる場合、ノードは新しいノードを分離し、それをネットワークから禁止することを決定し得る。
【0072】
M-netの分散されたメモリプール内のトランザクションは、確認される前、即ちブロックチェーンに追加され確認されるブロックに組み込まれる前に、かなりの時間待つかもしれない。ブロックはそれより上のブロックチェーンに十分な数の後続のブロックが追加された場合に「確認された」とみなされ、その結果、異なる枝又はフォークに変化するようにチェーンの成長を逆転させ及びブロックを除去することは計算上不可能であるようになる。
【0073】
メモリプールのサイズと柔軟性とトランザクションの量とに起因して、ビットコインのような或るブロックチェーン実装よりも長い間、所与のトランザクションが確認されない可能性がある。従来のビットコイン実装では、トランザクションは、それがブロックに組み込まれるとすぐに、メモリプールから取り除かれる。これは、ブロックが、オーファン・ブロック(親ブロックの無いブロック)となった場合に、ブロック内の全てのトランザクションがネットワーク上で再送されることを意味する。これは、非現実的であるかもしれず、また、高速トランザクション・ネットワークの場合、特定のトランザクションを確認するために長い遅延を生じるかもしれない。
【0074】
従って、幾つかの実装において、メモリプールは、トランザクションが組み込まれているブロックのコンファメーション数、即ちトランザクションが組み込まれたブロックに続くブロックチェーンに追加されたブロック数を追跡することができる。あらかじめ決められた数のコンファメーションが行われた後にのみ、トランザクションはメモリプールから除外される。所定の数は、所与の実装に関する4、5、6、7又は任意の適切な数であってもよい。メモリプール・データ入力は、トランザクションIDフィールド、トランザクション・フィールド、及びコンファメーション数(NoC)フィールドを含むように構成されてもよい。別の実装では、NoCを追跡するのではなく、メモリプール・データ入力は、単にブロック番号を記録してもよい。ブロック番号から、ブロックチェーンの現在のブロック番号に基づいて、何回のコンファメーションが発生したかを評価することが可能である。
【0075】
いったん必要数のコンファメーションが行われると、トランザクションはメモリプールから安全に除外され得る。このようにして、オーファン・ブロックの場合にトランザクションの損失はなくなり、トランザクションは、必要数のコンファメーションの後に、永久的に削除される。
【0076】
本明細書の以下の部分で説明されるようなソリューションは、上述したような高速検証ノードの修正されたタイプを使用する。新しいフル・ノード構成が説明され、これは、大規模ストレージ能力と改良された動作プロトコルとで強化されたM-node検証アーキテクチャである。M-nodeとストレージ・ノードとは一緒になって新しいフル・ノードのコアを構成する。必要な技術的要件と技術的ソリューションとを含む新しいノード構造が詳細に説明され、持続可能なインセンティブ・モデルが提供される。
【0077】
ブロック・サイズ及びストレージ条件
現在のブロック・サイズは1Mbである。現在、ブロックは、所謂マジック・ナンバー(常に同じ値)と、ブロックの実際のサイズを示す値と、所謂ブロック・ヘッダと、ブロックに含まれるトランザクションの数と、そして最後に実際のトランザクションのリストとを含むフィールドで構成される。後者は常にコインベース・トランザクションから始まり、これはブロックをマイニングすることに対する報酬を含むトランザクションである。
図1にブロックの全体構造が示されている。
【0078】
ブロック・ヘッダは以下を含む:
1.バージョン番号(4バイト)
2.前のブロック・ヘッダのハッシュ(32バイト)
3.マークル・ルート・ハッシュ(32バイト)
4.時間(4バイト)
5.ターゲット閾値(nビットとしてエンコードされる-4バイト)
5.ノンス(4バイト)
【0079】
現在、ブロックは約2000のトランザクションを含み、ブロックは約10分ごとに採掘される(10分のブロック時間は、最初のコンファメーション時間とチェーン分割に費やされる時間との間の妥協として設定されている)。これは、理論上最大7トランザクション/秒で、約3.5トランザクション/秒というトランザクション・レートを提供する。対照的に、VISAは約10000トランザクション/秒のレートで動作し、50000トランザクション/秒以上に到達し得る。
【0080】
競争支払システムを構築するためには、現在の制約についての何らかの迂回策が必要であることは明らかである。10分間のブロック時間は十分に確立されているので、ブロック・サイズ、即ちブロックチェーン自体の変更を考慮することが必須である。本明細書では、例えば毎秒約50000トランザクションを処理し得るスケーラブルなソリューションが説明される。
【0081】
現在のブロック・サイズの増加、あるいは制限の完全な撤廃でさえそれらは、多くの議論の的となっており、時には論争の話題となっている。現在のサイズを維持すること及びそれを増加させることは何れも多大な恩恵とトレードオフをもたらすので、双方の側に有力な主張があるように思われる。
【0082】
トランザクション・レートをrと仮定すると、我々は必要なブロック・サイズを計算することができる。以下、(平均して)10分のブロック時間が仮定される。そこで、T(r)をブロック当たりのトランザクション数とする。
T(r)=r・6・10
2 block
-1
s
Txがバイト単位の平均トランザクション・サイズである場合、ブロック・サイズB(r,s
Tx)は次のように表すことが可能である。
B(r,s
Tx)=s
Tx・T(r)=s
Tx・r・6・10
2
従って、r=50000Txs/s及びs
Tx=500バイトであるシナリオを考察すると、簡単なバック・オブ・エンベロープ計算は次のようになる。
【数2】
【0083】
これは、O(106)Gb/yearというストレージ条件を導く。このサイズのブロックでは、ブロック伝搬とストレージの両方に対してわずかに異なるアプローチが必要であることは明らかである。以下の表1は、トランザクション・レート、平均トランザクション・サイズ、ブロック・サイズ、及び月次及び年次の必要なストレージ・スペース量を示す。
【0084】
【表1】
表1:トランザクション・レート、平均トランザクション・サイズ、ブロック・サイズ、及び必要な月次及び年次ストレージ・スペース量の関係
【0085】
新たなビットコイン・ネットワーク
ビットコイン・ネットワークに対して提案するアーキテクチャが
図2に示されており、これは、ユーザがトランザクションをサブミットした時点からそれがブロックチェーン上で終了するまでのステップを示す動作図を示す。
【0086】
特殊な検証ノード(分散ハッシュ・テーブルDHTによって自身の間で共有メモリプールを維持する)がトランザクションを受信し、それらを検証し、それらをメモリプールに割り振るシステムが提供される。その後、検証ノードは、有効なトランザクション・ハッシュのリストをマイナーに提供する各自のサービスを提供する。マイナーは、これらのハッシュに基づいてプレ・ブロック(ブロック・スケルトン)(pre-blocks(block skeletons))を組み立て、ハッシュ・パズルを解こうとする。パズルのソリューションが発見されると、勝利したマイナーはブロック・スケルトンを検証ノードへ返送する。これらは、ブロックを検証し、ブロックが保存されることを保証する。最初に、検証ノードがブロック自体を格納することは可能であり、実現可能である。ブロック・サイズが最終的にサイズの特定の閾値を超えると、検証ノードは:a)独自のストレージ機能を拡張するか;又はb)特殊なストレージ・ノードに格納することをアウトソースする。本明細書では2つのアーキテクチャが後に議論される。
【0087】
新しいフル・ノード
O(10)GBというオーダーのブロック・サイズでは、ブロックチェーンのフル・イメージをホスティングするためのストレージ容量を提供するためにPCタイプのノードを当てにすることは、もはや実行不可能であるように思われる。その代わりに、O(1)PB又はより多くのストレージを提供する施設が必要とされる(表1参照)。そこで問題は、ネットワークの分散、非セントラル化、非トラスト性を維持しながら、新しいブロックを収容するシステムを構築することである。
【0088】
2種類の完全なノード構造と、これらの2種類の組み合わせが考えられる:
1.関連するペタバイト・ストレージ・ラックを有する検証ノード
2.現在のビットコイン・ネットワークそれ自体に非常に類似する、内的に非セントラル化された分散されたピア・ツー・ピア(P2P)シングル・ノード・ネットワークに基づく関連ストレージ・プールを有する検証ノード
3.1及び2の組み合わせ
【0089】
提案されるソリューションは、現在のビットコイン・ネットワークで動作する所謂フル・ノードに類似するノードを導入することにより、ブロックチェーンの分散された非セントラル化された記録を常に維持する問題を解決しようと試みるが、現在のビットコイン・ネットワークとは対照的に、ブロックのサイズとトランザクション数の増加に伴ってスケーリングできる能力を有する。
【0090】
この相違は純粋に構造及びハードウェア関連の問題に限られない。書き込み時に動作する家庭用PCベースのフル・ノードとは対照的に、ここで提案される新たなノードは特殊なノードである。それらはかなりの額の投資を必要とし、従ってインセンティブの仕方は非常に異なる。スケーラブルなパラダイムでは、M-node(検証ノード)と新たなフル・ノード(検証ノードとストレージ・ノードとの組み合わせ)との両方が、それらのサービスに対する補償を期待している。
【0091】
スペクトルの他方端では、非セントラル化され分散化されたストレージ・ソリューションがあり、その大部分は個人のノードで構成される。良い例は、Storj(Wilkinson et al.,2016)、Sia(NebulousLabs)及びメイドセーフ(Maidsafe)である。Storjの場合、その機能は、参加者がストレージ・スペースの提供に対して報酬を得ることに基づいている。
【0092】
上述したように、ペタバイト(Pb)ラックとピア・ツー・ピア(P2P)ストレージ・システムの両方から構成されるスーパー・ノードを想定することも可能である。
【0093】
ビットコイン・エコシステムは、非セントラル化された方法で分散されたブロックチェーン全体の複数のレプリカの存在に大きく依存しているので、全てのフル・ノードが補償されることは重要であることは明らかである。これは、本質的には勝者が全ての賞を獲得するゲームであるマイニングとは非常に相違する。マイナーは(勝ち取った)ブロックを当てにして公のブロックチェーンにたどり着くので、全てのノードを格納することに報いることは、彼らの利益になる。
【0094】
ノードはスーパー・ノードとして機能するプールにグループ化される。ブロックチェーンの分散性を維持するためには、そのようなスーパー・ノードが一定数(100以上)存在しなければならない。スーパー・ノードは接続されるがオーバーラップしていない。
【0095】
技術的要件
上述したように、新たなフル・ノードを議論する場合に考察されるべき2つの全体的に相違するアーキテクチャが存在する(表2参照)。
【0096】
新たなフル・ノードは、2つのタイプのストレージを維持する必要がある:
1)メモリプールのための分散されたハッシュ・テーブル(DHT)メモリ/ストレージのようなランダム・アクセス・メモリ(RAM)
2)ブロックチェーンのストレージのような永続的なテープ/ディスク
上述したように、r=50000Tx/sのトランザクション・レートに関し、ブロックはO(10)Gbであるように期待され、これは、
~365×24×6×15Gb=7.9・105Gb=0.8Pb/yr
という年次ストレージ要求を意味する(表1参照)。
【0097】
表2は現在のフル・ノードと将来のフル・ノードとの間の比較を示す:
【表2】
【0098】
同時に、ラック/クラスタはメモリプールを維持する必要がある。これは速やかなブロック復元を許容する。メモリプールの必要なサイズを評価することはより困難である。現在、約1メガバイト(~1Mb)のブロック・サイズ、毎秒約4トランザクション(~4Tx/s)で、メモリプールで待機しているトランザクションの合計サイズは、2ないし約70メガバイト(~70Mb)の間で揺れている。
図3は、コンファメーションのためにメモリプールで待機しているトランザクションの合計サイズを示すグラフである。
【0099】
上述したように、大量のデータを保存することができる、基本的に異なる2つの構造、及びそれらの組み合わせを想定している。2つの構造は
図4及び
図5に示されている。
図4は、内的にセントラル化されたストレージ装置へのアクセスを有する複数のノードを含む構成を示す。
図5は、各ノードが分散されたメモリプールと分散されたストレージ装置との両方の一部である構成を示す。
図4に描かれたアーキテクチャは、幾つかの検証ノードを所有及び維持する、より大きなエンティティに適しているように思われ、その検証ノードは全てエンティティの自身のストレージ装置に対するアクセスを有する。これに対して、
図5に示されるアーキテクチャは、完全に非セントラル化されている。これは、十分なストレージ容量を有する家庭で所有されるPCのような、共有された分散ストレージ・プールに参加することを望む個々のノードに適したソリューションである。このために使用される基本的なストレージ技術は既に存在している(例えば、Storj、Sia、MaidSafe)。
【0100】
新しいフル・ノードがビットコイン・ネットワークにどのように適合するかを可視化する1つの方法が
図6に示されており、
図6は検証ノードがストレージ・プールのメンバーであるネットワーク構成を示す。プールは共に、非セントラル化された分散されたビットコイン・ネットワークを含む。
【0101】
フル・ノード・オペレーション
ラージ・ブロックのシナリオでは、単にスペース要件に起因するだけではない別の状況に直面する。メモリプールは、ブロックに相当するもの、即ち約15ギガバイト(~15Gb)、好ましくは次に掘削されるブロックに対する等価量を収容できるべきである。これは、考慮する必要のあるオーバーヘッドと組み合わせる必要がある。
1)メモリプールは他の検証ノードと同期する必要がある。これは可逆ブルーム・フィルタ・ルックアップ・テーブル(Invertible Bloom filter Lookup Tables)を交換することを含む(Michael T.Goodrich,2011)
2)IBLTは精査され、欠落しているトランザクション(Tx’s)が取得される
3)追加的に取得されたTxは検証されることを要する
4)マイナー及び他のフル・ノードから受信されたブロック・スケルトンに基づいてブロックを組み立てる。
新たなフル・ノードは、最新のメモリプールを保持する。これは、マイナー、他の検証ノード及び新たなフル・ノードともに交換されるIBLTによって行われる。
【0102】
マイナーは以下のものにより構成されるブロック・スケルトン(タプル)を送信する:
1.ノンス,n
2.IBLT
3.コインベース・トランザクション
これに基づいて、新たなフル・ノードは相応して(特定のルール・セットに従って)トランザクションを注文し、新たに採掘されたブロックを組み立てる。次に、新たなフル・ノードは、他の新たなフル・ノードにスケルトンを伝搬するだけでなく、各自自身のストレージにブロックを格納する処理を進める。プロトコルは本明細書で後に更に詳細に説明される。
【0103】
インセンティブ
特定のコンフィギュレーションの1つの重要な特徴は、新たなノード構造とサービスの提供を奨励するためにシステムにインセンティブを構築することである。ブロックチェーンを格納することに付随する多大なコストに起因して、インセンティブが必要とされる。
図7は新たなフル・ノードの機能を示す。新たなフル・ノードは、主に以下の2種類のサービスに対して報酬を与えられる:
1)検証されたトランザクションのリストをコンパイルし、マイニングに備える。トランザクションのハッシュ値(Merkle root)がマイナーへ送信され、そのマイナーはリストを選択してブロックを採掘する。
2)勝利したマイナーは採掘したブロックのスケルトンを幾つかの新たなフル・ノードへ送信する。スケルトンはコインベース・トランザクションを含み、以下のa~c.を含む:
a.マイニング報酬
b.検証されたリストを提供する支払メカニズムとして使用されるコミットメント・スキームの一部であるシークレット
c.ブロック検証、及び/又はブロックチェーンにおけるブロックのストレージに対する支払。
【0104】
[トランザクション]検証ノードは、有料システムによってトランザクションの検証に関して払い戻しを受ける。受ける側の検証/新たなフル・ノードは以下のうちの1つ以上に関して報酬を受ける:
1)検証されたトランザクション(Tx)ハッシュのリストをマイナーに提供すること(上記b.参照)。
2)ブロック・スケルトンからブロックを組み立て直すこと(「定額」料金)。
3)ブロックのサイズ(「MBストレージ」単位の支払)。
【0105】
インセンティブは100ブロック・コンファメーション時間T100の間にある。
1)マイナーは彼らの報酬を請求するためにt~T100の間待機する必要がある。
2)検証ノードは、ブロック中のTxを検証することに関して彼らの手数料を受ける前に、t~T100の間待機する必要がある。
3)新たなフル・ノードは、ブロック構築手数料及びサイズ依存性ストレージ支払を受ける前に、t~T100の間待機する必要がある。
【0106】
従って、100ブロックのコンファメーション時間は、スケルトン・ブロック(支払いを含む)を、ある範囲内の新たなフル・ノードへ伝播させるために必要なインセンティブをマイナーに提供し、新たなフル・ノードは、スケルトン・ブロックを他の新たなフル・ノードに伝播するように刺激されるであろう。
【0107】
また、ブロックに含まれることを希望する(トランザクションの)リストをマイナーが自由に選択することは、指摘されるべきである。かくて、マイナーがコミットメント・トランザクションによって選択及び購入することが可能な検証されたトランザクションのリストをまとめることによって、競合する検証ノードを含む市場を想定し得る。
【0108】
改訂されたマイニング
ビットコイン・エコシステム(The Bitcoin ecosystem)は採掘の過程に依存する。マイナーは、トランザクション(Txs)をメモリプール(又はここで想定されるように、特殊な検証ノード)から収集し、それらをブロックに組織し、ハッシュ・パズルを解く解(ノンス)を発見しようと試みる。ブロック・ヘッダは、ブロックチェーンにおける前のブロックのハッシュ、トランザクションのマークル・ツリーのルート(根元)、及びマイナーによって含められるノンスを含む。パズルを解くことは、前のブロック・ハッシュ及びマークル・ルートと連結されたノンス(反復的に選択される)の二重SHA256ハッシュを計算すること、及びそれがいわゆる困難性ターゲットより小さいか否かを検査することから構成される。仮にそれがノンスを下回るならば、パズルは解決されており、仮にそれを上回るならば、ノンスに対する反復が続く。これは、新しいパラダイムでも変わらずに残る。問題をもたらすものは、非常に拡大されたブロック・サイズ、及びネットワークを横断する採掘されたブロックの分布である。Gbサイズのブロックでは、ネットワークにおいてブロック全体をブロードキャストすることは必ずしも必須でない。
【0109】
むしろ我々は以下のステップに従うソリューションを提案する:
1.マイナーが、検証されたトランザクションのリストを、検証/M-node及び/又は新たなフル・ノードから受信する。
2.マイナー自身は所定の順序付けの慣例に従うTxハッシュ値の各自自身のメモリプールを運営してもしなくてもよく、そのような順序付けの一例は以下に示されている。
[https://www.cryptocoinsnews.com/bitcoin-in-bloom-how-iblts-allow-bitcoin-scale/]
3.マイナーはノンス,nを決定することによってハッシュ・パズルを解く。
4.次に、ハッシュ・ツリー(マークル・ツリー、ここではHTとして言及される)が計算され、ツリーのルートが格納される(次のセクションを参照されたい)。
5.TxsのこのリストはIBLTを作成するために使用される。IBLTは(例えば、メモリプールの)2つのセットの間の内容の相違を算出し、2つのセットをリコンサイル(reconcile)するために使用されることが可能である。
6.タプル{n;IBLT;コインベースTx:HTルート}が検証/M-nodeへブロードキャストされる。
7.新たなフル・ノードは、ブロックチェーンに関するストレージ及びメモリプールに関するDHTを運用する。
8.プールは、タプル{n;IBLT;コインベースTx:HTルート}に基づいてブロックを組み立て直し、a)ブロック自身を格納することにより、又はb)特殊なストレージ・ノードに格納することにより、ブロックチェーン上でブロックを記録する。
【0110】
マイナー間の競争回避
マイナーは、幾つかの検証ノードで構成される市場から、検証済みトランザクションのリストを選択することができるであろう。特に断りのない限り、マイナーは、彼らの可能性のある収益を最大化するリストを選択するであろうと仮定することは妥当である。注意深い読者は、これはマイナーが主に同じノードから同じリストを選ぶことにつながり得ることを指摘するかもしれない。これは、何人ものマイナーが同じブロックを採掘しようとして、互いに競い合う状況を招くであろう。このことは、最大のハッシュ能力を有するマイナーに有利に働くであろう。
【0111】
我々は、ブロック・ヘッダに追加フィールドを追加することを提案する。このフィールドは、各マイナーによって選択される乱数を含む。これは、各マイナーが異なる開始点から出発することを保証し、従って、そのブロックの解を探すことが単に、ハッシュする能力の問題に落とされてしまうことを防止する。これは、マイナーが同じような、しかし個々に選んだ、僅かに異なるブロックを採掘する傾向がある現在の状況に似ている。
【0112】
プロトコル
ここで、新しいフル・ノードを動作させるために必要なプロトコルを説明する。提案したシステムが、関わりのあるノード(検証者、採掘者、新しいフル・ノード・・・)のメモリプールを機能させるためには、トランザクションの順序付け規則に従うべきである。ここで、ギャビン・アンダーセンによって提案された正規順序(the canonical ordering)を使用することを提案する。そこでは順序付けはブロック内のトランザクションのリストに関係しているが、ここで我々は、全ての検証ノードと新しいフル・ノードが、それらのメモリプールに同じ規則を使用するというアイディアを提示する。
【0113】
規則は以下のように要約されることが可能である:
1)前のトランザクションのハッシュに関して昇順にトランザクションを並べる。
2)並べられたリストから、後続のトランザクションに依存しない最初のトランザクションを追加する。
【0114】
前述したように、ブロックは所謂マークル・ルート・ハッシュを含む。これは、コインベース・トランザクションを含む全てのトランザクションをハッシュし、その後、マークル・ルート・ハッシュに到達するまで、ハッシュの連結をハッシュすることによって生成される。マイナーがコインベース・トランザクションを生産しているという事実がなければ、検証ノードはマークル・ツリー全体、従ってマークル・ルートと対応するハッシュを計算し得る、ということは明らかである。
【0115】
ここで、次の方法の手続きを用いて計算されるマークル・ツリーを提案する:
検証ノードはリトル・マークル・ルート(a Little Merkle Root)を計算する。手順は、幾つかの例外と共に、標準的なマークル・ルートを計算する場合と同じである:
1)コインベース・トランザクションは省かれる。
2)いわゆる通信トランザクションが含められる。
3)マイナーはコインベース・トランザクションを生成し、それをリトル・マークル・ルート・ハッシュに連結し、マークル・ルート・ハッシュを生成する。
【0116】
これは、新しいマークル・ツリー構造を示す
図8に示されている。これは現在のプロトコルに対する修正を為すことに留意を要する。
【0117】
ブロック・ヘッダに対する修正
上述したように、我々は、マイナーにより選択された乱数を含む追加のフィールドを、ブロック・ヘッダに追加することを提案する。従ってハッシュ・パズルを解くことは、以下のように変わる:
【数3】
Prev.Block Hash:赤
Marke Root:緑
nonce:青
RND:紫
【0118】
従って我々は乱数を含む追加フィールドにより、採掘された新しいブロックのブロック・ヘッダが強化されることを提案する。ブロック・ヘッダは以下を含む:
1.バージョン番号(4バイト)
2.先行ブロック・ヘッダのハッシュ(32バイト)
3.マークル・ルート・ハッシュ(32バイト)
4.時間(4バイト)
5.ターゲット閾値(nビットとしてエンコードされる-4バイト)
6.ノンス(4バイト)
7.乱数(4バイト)
【0119】
検証→マイナー
検証ノード:
○ 要求に応じて、検証ノード(新しいフル・ノードであってもなくてもよい)が、採掘される検証済みトランザクションのリストを準備する。
○ 検証者ノードがコミットメント・トランザクション(a commitment transaction)を作成する。
○ 所謂リトル・マークル・ルート(前節参照)が、包含されるコミットメント・トランザクションとともに算出される。
○ 検証者ノードが2つのIBLT:
1)ブロック内の全てのトランザクションについて(IBLT1);及び
2)ブロック内の全ての対応するTRxIDについて(IBLT2)
を準備する。
○ 検証者ノードがマイナーへ:
1)リトル・マークル・ルート
2)IBLT1
3)IBLT2(オプション-マイナーが自身のTxID-/メモリプールとともに動作する場合のみ)
4)先行ブロック・ハッシュ
5)上記のハッシュ・チェックサム
を送信する。
【0120】
マイナー:
○ 検証ノードからデータを受信すると、マイナーは、コインベース・トランザクションを作成する処理を進め、これは、マイニングに対する報酬、及び新たなフル・ノードのブロック検証/ストレージに対する報酬(マイナーが採掘されたブロックを送信することを希望する送付先)を含む。更に、コインベース・トランザクションは、コミットメント・トランザクションにおけるシークレットと一致する、シークレットを有するアウトプット・フィールドを含む。
○ マイナーは、検証者ノードから受信したリトル・マークル・ルートを使用し、それをコインベース・トランザクションと結合し、マークル・ルート・ハッシュを作成する。
○ マイナーは今やハッシュ・パズルを解き始めるために必要な全ての情報を有している。
○ マイニングは上述した方法で進行する。
【0121】
マイナー→新たなフル・ノード
マイナー:
○ ブロックがマイニングされると、マイナーは以下のものを新たなフル・ノードのリストに送信する:
○ ノンス(パズルに対する解),n
○ コインベース・トランザクション
○ ブロック・ヘッダ
○ マークル・ルート
○ リトル・マークル・ルート
○ IBLT1
○ IBLT2(オプション)
○ ハッシュ・チェックサム
【0122】
新たなフル・ノード:
○ 適切な報酬がコインベース・トランザクションにあるか否かを検査する。
○ チェックサム(ハッシュ)を計算することにより、受信データは一貫していることをノードが確認する。
○ ブロック中のトランザクションがメモリプールに存在することを確認するためにノードがIBLT1を利用する。
○ IBLT1を利用してメモリプールを照会し、ノードがブロックを組み立てる。次いでブロックは格納される(新たなフル・ノード及びストレージに関するセクション参照)。
○ マイナーから受信したデータ他の新たなフル・ノードへブロードキャストされる。
【0123】
カスタマイズされたトランザクション・リスト
我々は、検証されるトランザクションのマーケットがマイナーのニーズに適合するような状況を想定している。マイナーは、彼らの可能性を最大化するリストを選ぶ傾向があり、検証中のM-nodeは、そのような傾向でピック・アップを行うであろう。
【0124】
2つ以上のリストからトランザクションを組み合わせることにより、マイナーが自身のブロックをカスタマイズすることを希望するケースがあるかもしれない。2つのIBLT間の相違を計算することにより、2つのセット間のセット調停(set reconciliation)を行うことが可能である。次に、マイナーは、差異を含むIBLTを提供ノードの1つへ返送し、このようにして、リストを作成するのに必要な情報を取得し、このリストは、両方のリストにある全てのトランザクションを含む。
【0125】
マイナーが幾つかのリストに基づいて各自自身のリストを作成したい場合には、さらなる課題が生じるように思われる。ここでは、様々な点について簡単に述べる。
【0126】
マイナーが様々な検証ノードからのリストを組み合わせるならば、マークル・ルートがどのように組み合わせられるべきかは不明確である。ここで我々は以下を提案する:
個々のリトル・マークル・ルートについてのビッグ・リトル・マークル・ルート(a Big Little Merkle root)を構築すること;及び
ビッグ・リトル・マークル・ルートをコインベース・トランザクションと結合すること。
【0127】
追加費用は、リスト/ブロックに追加される追加トランザクションの量に比例しない。様々なメモリプールがかなりオーバーラップするであろうと仮定することは妥当であるので、リストを組み合わせることは、異なるリストから少数の(相対的に言って)トランザクションを追加することになるであろう。しかし、リストを組み合わせるために、マイナーは各検証ノードから(コミットメント・トランザクションによって)全リストを「購入」しなければならないであろう。これがマイナーにとって有益なアプローチとなるか否かは、まだ分からない。
【0128】
幾つかの検証ノードからのリストを組み合わせることは、マイナーと検証ノードを提供する各々との間にコミットメントを必要とする。マイナーによるこのシステムの悪用を想像することが可能である。現在のところ、全てのコミットメント・トランザクションがブロックに行き着くことを強制するルール/プロトコルは存在しない。1つの可能性は、検証ノードが各ブロックをチェックし、トランザクションを含むブロックを拒否できることである。
【0129】
サマリー
今日のビットコイン・ネットワークは、計算労力という意味で、非常にマイナーを中心にしている。トランザクション量の大幅な増加により、これは必ずしも実現可能であるとは限らない。本明細書で説明されるソリューションは、さまざまな作業を、それに応じて特化されたノードに委託することにつながり、マイナーはよりいっそう自ら専門化されることになる。検証されたトランザクションのリストをまとめ、ブロック・スケルトンに基づいてブロックを再構築し、保管することは、全てかなりのリソースを必要とする機能である。従って、ビットコイン・ネットワークの構造は変化し、それに伴ってインセンティブも変化すると予想される。これらの問題について本明細書で詳細に説明した。
【0130】
本明細書で導入される新たな要素の中で以下の事項に言及することができる:
○ 新たなタイプのノード構造。本明細書で新たなフル・ノード又はスーパー・ノードと呼ばれ、検証するM-nodesに対する拡張であってもなくてもよい。
○ ノードは、検証ノードからマイナーへ及びマイナーから新しいフル・ノードへの双方についてのGbサイズ・ブロックのブロードキャストを効果的に可能にするプロトコルで動作する。
○ ブロックチェーンを記憶するための2つの全体的な記憶構造。これは、提案される新しいフル・ノードの一部であってもなくてもよい。
○ 検証されるトランザクションの前ブロック・リストのマーケットの作成、及びブロックの組み立て及び格納を可能にするインセンティブ・モデル。
○ マイナーが各自自身のメモリプールを維持する必要性から解放する新たなマークル・ツリー構造。
○ 乱数を有するブロック・ヘッダの追加フィールドの追加。乱数は、マイニング活動が単にハッシュ処理能力に基づく競争になってしまうことを回避するために、マイナーによって選択される。
○ 検証は特殊なコミットメント・トランザクションを利用して報いられる。
【0131】
ブルーム・フィルタ及びIBLTs
このセクションでは、いわゆる「ブルーム・フィルタ(Bloom filters)」の特性と、「可逆ブルーム・ルックアップ・テーブル」と呼ばれるものへの拡張とを要約する。
【0132】
最も簡易な形式では、ブルーム・フィルタはアレイである。アレイはそれに関連付けられる2つのパラメータ、M及びkを有する。Mはアレイのビット数であり、kは以下の数式のような異なるハッシュ関数H
kの数であり、
【数4】
ここで、S
16は16進文字列の空間であり、そこにハッシュ関数が作用する。トランザクションTx
0が集合に属するか否かを決定するために、ブルーム・フィルタが作成され、我々はH
1(Tx
0)・・・H
k(Tx
0)を計算し、次いで対応するビットがアレイの中で1に設定されているか否かを検査する必要がある。
図9はブルーム・フィルタを作成する際のワークフローを示す。
【0133】
1つ以上がそうでない場合、Tx
0は確実に対象集合には無い。しかしながら、ブルーム・フィルタは偽陽性(false positives)を許容する。これは、ビットを1に変化させるハッシュ関数の確率が、
p=1/|アレイのサイズ|=1/M
であるという事実に由来する。従って、所謂
【数5】
により、所与のハッシュ関数によってビットは1に設定されない。従って、k個のハッシュ関数が存在する場合、所与のビットが1に設定されない確率は次のようになる:
【数6】
n個の要素が挿入される必要がある場合、それは次のようになる:
【数7】
【0134】
ブルーム・フィルタの明らかな欠点の1つは、任意の特定の順序を追跡せず維持しないことである。フィルタリングされるべきアイテムのインデックスを維持することを希望する場合、我々はフィルタの機能を拡張する必要があることは、直ぐに明らかになる。ここでは、可逆ブルーム・フィルタ(IBFs)及び可逆ブルーム・ルックアップ・テーブル(IBLTs)加わる。
【0135】
アレイにおいてビットをアクティブ化するだけではなく、鍵のXOR合計、ハッシュ値(前述のように)、及び全体のカウンタが、IBFの各フィールドに格納される。この手順は
図10に示されており、
図10は、IBF/IBLTにおいてトランザクションがどのようにエンコードされるかを示すワークフローを示す。
【0136】
アプリケーション
2つのノードN1及びN2を有し、それぞれがメモリプールm1及びm2を維持していると仮定する。各メモリプールは16進文字列全体S16のうちの要素を含む。更に、Andresenにより提案され、本明細書で上記で概説されているように、メモリプールは順序規則(an ordering convention)に従っていると仮定する。N1がm1をN2へ送り、今やN2は2つの方法でセット・リコンシリエーションにアプローチすることができる:
1)Δm=m2-m1により集合の差分を計算する((David Eppstein,2011),(Michael T.Goodrich,2011)を参照されたい)。
2)m2におけるトランザクションに関して反復を行い、N1のメモリプールに存在するか否かをチェックする。
【0137】
IBLTは少なくとも2つの目的で使用され得ることが分かる:
1)各自のメモリプールに既に有しているトランザクションに基づいて、ノードに、採掘されたブロックをアセンブルさせ、それらが有していないブロックを識別及び取得することを支援すること。
2)異なるノードに所属するメモリプールの間で所定レベルの同期を維持すること。
【0138】
トランザクションはビットコインを転送することができるが、ユーザは、情報、契約、及びトークン等の本明細書に記載される方法及びシステムを使用して、他のリソースを交換することができることが理解されるべきである。トークンは、トークンに関連付けられたスマート契約に従って資産又はリソースを表し、その結果、トークンのコントロールが、資産又はリソースのコントロールをもたらす。スマート契約それ自体はブロックチェーン外で格納されてもよいし、あるいは1つ以上のトランザクションの中に格納されてもよい。
【0139】
リファレンス
An Integrated World.(n.d.).Retrieved from 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.).Retrieved from 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.).Retrieved from github.com: https://github.com/NebulousLabs/Sia O(1) Block Propagation. (n.d.).Retrieved from github.com:https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2
Wikipedia.(n.d.).Retrieved from https://en.wikipedia.org/wiki/Distributed_hash_table
Wilkinson et al.(2016, December 15). Retrieved from https://storj.io/storj.pdf
【0140】
上述の実施形態は本発明を限定するものではなく、本発明を例示するものであること、当業者は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく、多くの代替実施形態を設計することが可能であることに留意すべきである。特許請求の範囲においては、括弧内に付された如何なる参照符号も、特許請求の範囲を限定するものと解釈されてはならない。「~を含んでいる」及び「~を含む」等の用語は、何れかの請求項又は明細書全体に列挙されたもの以外の要素又は工程の存在を排除しない。本明細書において、「~を含む」とは、「~を含む、又は~から構成される」ことを意味し、「~を含んでいる」とは、「~を含んでいる、又は~から構成されている」ことを意味する。要素の単独的な参照は、複数のそのような要素の参照を除外するものではなく、その逆もまた同様である。本発明は、幾つかの別個の要素を含むハードウェアによって、及び適切にプログラムされたコンピュータによって実施され得る。幾つかの手段を列挙する装置クレームにおいては、これらの手段の幾つかは、1つの同一ハードウェア・アイテムによって具体化されてもよい。複数の事項が相互に異なる従属請求項で引用されているという単なる事実は、これらの事項の組み合わせが有利に使用できないことを示すものではない。
【0141】
(付記1)
ブロックチェーン・ネットワークのトランザクション検証ノードに対するコンピュータで実現される方法であって:
(i)前記ブロックチェーン・ネットワークからトランザクションを受信するステップ;
(ii)前記ブロックチェーン・ネットワークから受信したトランザクションを検証するステップ;
(iii)前記ブロックチェーン・ネットワークにおける他のトランザクション検証ノードとともに、検証されたトランザクションについての分散された非セントラル化されたストレージを維持するステップ;及び
(iv)前記検証されたトランザクションに対応するデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配するステップ;
を含む方法。
(付記2)
前記ブロックチェーン・ネットワークにおける他のトランザクション検証ノードとともに、検証されたトランザクションについての分散された非セントラル化されたストレージを維持する前記ステップが、検証されたトランザクションの最新のリストを非セントラル化された分散された方法で維持するために、前記ブロックチェーン・ネットワークにおけるトランザクション検証ノードを同期させるステップを含む、付記1に記載のコンピュータで実現される方法。
(付記3)
前記検証ノードは、可逆ブルーム・フィルタ・ルックアップ・テーブルを交換することにより同期させられる、付記2に記載のコンピュータで実現される方法。
(付記4)
前記検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、前記ブロックチェーン・ネットワークにおけるトランザクション検証ノードにわたって共通の順序体系が使用されるように、前記検証されたトランザクションが所定の順序でソートされる、付記1-3のうち何れか1項に記載のコンピュータで実現される方法。
(付記5)
前記検証されたトランザクションの分散された非セントラル化されたストレージを維持するために、前記検証されたトランザクションは、正規の順序体系を利用して決定される順序にソートされる、付記4に記載のコンピュータで実現される方法。
(付記6)
前記検証されたトランザクションに対応するデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配する前記ステップが:
検証されたトランザクションのリストに対応するデータを準備するステップ
を含む、付記1-5のうち何れか1項に記載のコンピュータで実現される方法。
(付記7)
前記検証されたトランザクションに対応するデータを、マイニングのために前記ブロックチェーン・ネットワークへ分配する前記ステップが:
前記検証されたトランザクションのリストに対応する前記データをマイナーに提供することに対する見返りとしてディジタル資産のコミットメント・トランザクションを作成するステップ
を含む付記1-6のうち何れか1項に記載のコンピュータで実現される方法。
(付記8)
ハッシュ・ツリー、パトリシア・ツリー、又は他のタイプのラディックス・ツリーが、包含される前記コミットメント・トランザクションとともに算出される、付記7に記載のコンピュータで実現される方法。
(付記9)
前記検証されたトランザクションに対応する前記データは、可逆ブルーム・ルックアップ・テーブル及び任意の付随するデータの形式で前記ブロックチェーン・ネットワークへ分配される、付記1-8のうち何れか1項に記載のコンピュータで実現される方法。
(付記10)
(v)前記検証されたトランザクションに対応する採掘されたデータを前記ブロックチェーン・ネットワークから受信するステップ;
(vi)前記採掘されたデータに基づいて複数のブロックを組み立てるステップ;及び
(vii)ブロックチェーンにおいて格納するためにストレージ・エンティティへ、組み立てられたブロックを送信するステップ;
を更に含む、付記1-9のうち何れか1項に記載のコンピュータで実現される方法。
(付記11)
前記ブロックチェーン・ネットワークから受信される前記採掘されたデータは、前記検証されたトランザクションに対応するブロック・ヘッダを含む、付記10に記載のコンピュータで実現される方法。
(付記12)
前記採掘されたデータは、前記採掘されたデータに基づいてブロックを組み立てることに対する見返りとしてディジタル資産のトランザクションを含む、付記10又は11に記載のコンピュータで実現される方法。
(付記13)
前記採掘されたデータは、組み立てられたブロックの格納に対する見返りとしてディジタル資産のトランザクションを含む、付記10-12のうち何れか1項に記載のコンピュータで実現される方法。
(付記14)
前記ディジタル資産を受け取る前に、最低限のブロック数に関連する期間tの間待機する条件を更に含む付記12又は13に記載のコンピュータで実現される方法。
(付記15)
前記採掘されたデータに基づいて複数のブロックを組み立てる前記ステップが、各ブロックが少なくとも2メガバイトのサイズを有するラージ・ブロックを組み立てるステップを含む、付記10-14のうち何れか1項に記載のコンピュータで実現される方法。
(付記16)
前記ブロックはマイナーにより提供される乱数を含むブロック・ヘッダを含む、付記10-15のうち何れか1項に記載のコンピュータで実現される方法。
(付記17)
前記ストレージ・エンティティは前記ブロックチェーン・ネットワークにおける複数のトランザクション検証ノード間で共有され、前記複数のトランザクション検証ノードは前記ブロックチェーン・ネットワークにおけるスーパー・ノードを形成し、前記共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又は両者の組み合わせのうちの何れかである、付記10-16のうち何れか1項に記載のコンピュータで実現される方法。
(付記18)
実行されると付記1-17のうち何れか1項に記載の方法を実行するようにプロセッサを構築するコンピュータ実行可能命令を含むコンピュータ読み取り可能な記憶媒体。
(付記19)
インターフェース・デバイス;
前記インターフェース・デバイスに結合される1つ以上のプロセッサ;
前記1つ以上のプロセッサ結合されるメモリ;
を含む電子デバイスであって、前記メモリは、実行されると付記1-17のうち何れか1項に記載の方法を実行するように前記1つ以上のプロセッサを構築するコンピュータ読み取り可能な命令を格納している、電子デバイス。
(付記20)
付記1-17のうち何れか1項に記載の方法を実行するように構成される、ブロックチェーンのトランザクション検証ノード。
(付記21)
付記20に記載の検証ノード複数個;及び
前記ブロックチェーンを格納する共有されるストレージ・エンティティ;
を含む、ブロックチェーンのスーパー・ノードであって、前記共有されるストレージ・エンティティは、共通のストレージ・ノード、分散されたストレージ、又は両者の組み合わせのうちの何れかであり、
前記複数の検証ノードにより組み立てられるブロックは、前記共有されるストレージ・エンティティへ送信及び格納されることにより、前記共有されるストレージ・エンティティは前記ブロックチェーンを維持する、スーパー・ノード。
(付記22)
前記共有されるストレージ・エンティティは少なくとも100ギガバイトのストレージ容量を有する、付記21に記載のスーパー・ノード。
(付記23)
付記22又は23に記載のスーパー・ノードを複数個含むブロックチェーン・ネットワークであって、
前記スーパー・ノードは前記ブロックチェーン・ネットワークで接続されており、各スーパー・ノードの前記共有されるストレージ・エンティティは前記ブロックチェーンのコピーを格納するように構成されており、前記ブロックチェーン・ネットワークは少なくとも10個のスーパー・ノードを含む、ブロックチェーン・ネットワーク。
【外国語明細書】