特表 2022-508247 信頼度ベースのコンセンサスを伴う高性能分散型記録システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-01-19

(54)【発明の名称】信頼度ベースのコンセンサスを伴う高性能分散型記録システム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20220112BHJP

   H04L 45/64 20220101ALI20220112BHJP

【ＦＩ】

H04L9/32 200Z

H04L45/64

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021529791

(86)(22)【出願日】2019-11-27

(85)【翻訳文提出日】2021-07-21

(86)【国際出願番号】 US2019063598

(87)【国際公開番号】W WO2020112994

(87)【国際公開日】2020-06-04

(31)【優先権主張番号】62/771,792

(32)【優先日】2018-11-27

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．Ｌｉｎｕｘ

(71)【出願人】

【識別番号】504266979

【氏名又は名称】アカマイ テクノロジーズ インコーポレイテッド

(74)【代理人】

【識別番号】100091568

【弁理士】

【氏名又は名称】市位 嘉宏

(72)【発明者】

【氏名】カーバー、デビッド、シー

(72)【発明者】

【氏名】アル・シェニブル、リーン、ケー

(72)【発明者】

【氏名】デローター、サミュエル

(72)【発明者】

【氏名】エルブ、サミュエル

(72)【発明者】

【氏名】シュトックマン、ウラジミル

(72)【発明者】

【氏名】ディーガン、パトリック、エー

(72)【発明者】

【氏名】フーマン、トーマス

【テーマコード（参考）】

5K030

【Ｆターム（参考）】

5K030GA15

5K030HC20

(57)【要約】

多数のトランザクションがスケーラブルで信頼性があり、安全且つ効率的な方法で同時に処理される高性能分散型台帳およびトランザクション・コンピューティング・ネットワーク・ファブリックである。一実施形態では、コンピューティング・ネットワーク・「コア」は、チェーンのブロックの通信、処理および記憶が、トランザクション自体が遠く離れたソースから発生している場合であっても、非常に高い性能および低いレイテンシで、同時に実行されることを可能にするように、データを編成する分散型ブロックチェーンネットワークをサポートするように構成される。このデータ編成は、処理メッシュとして構成された自律的で協調的なコンピューティングノード内のトランザクション空間のセグメント化に依存している。本システムはまた、信頼度ベースのコンセンサス、および自動化されたフォーク解決を提供する。本アプローチは、基礎となるネットワークが停止した場合にブロックチェーンが動作し続けられるようにし、完全なコンセンサスが達成される前の任意の不確実な期間にクライアントがトランザクションの処分について決定することを可能にする。

【特許請求の範囲】

【請求項1】

トランザクション要求を受信して、追加される一方の不変なデータブロックのチェーンに加工する、ネットワークコアを構成するトランザクション処理コンピューティング要素のセットに関連して運用する方法であって、データブロックはトランザクションの集合であり、トランザクションがデータブロック内に記録されて存在することは暗号化ハッシュにより検証可能であり、前記トランザクション要求は、サードパーティに関連付けられるレガシーコンピューティング基盤から生じるものであり、
前記レガシーコンピューティング基盤と前記ネットワークコアとの間に、前記トランザクション要求が前記ネットワークコアに入るエントリポイントとして機能する複数のエッジサーバを含む、オーバーレイネットワークを構成することと、
信頼度ベースのコンセンサスアルゴリズムにしたがい、前記トランザクション処理コンピューティング要素を使用して、ブロックの個々のセグメントをマイニングすることと
を含む、方法。

【請求項2】

前記信頼度ベースのコンセンサスアルゴリズムにより、フォーキングを防ぐのに十分な定足数分のトランザクション処理コンピューティング要素が存在しない場合に、前記追加される一方の、不変なデータブロックのチェーンに対するマイニングの継続を可能にする、請求項１に記載の方法。

【請求項3】

前記フォーキングを防ぐのに十分な定足数分のトランザクション処理コンピューティング要素が存在しないのは、ネットワーク停止が原因である、請求項２に記載の方法。

【請求項4】

前記ネットワークコアは複数のウォレットを含む、請求項２に記載の方法。

【請求項5】

前記複数のウォレットのうちの所与のウォレットが、前記ネットワークコアが前記追加される一方の不変なデータブロックのチェーン内のデータブロックの確定に合意した程度を特定するデータを受信する、請求項４に記載の方法。

【請求項6】

前記追加される一方の不変なデータブロックのチェーンの２つ以上のチェーンに対して競合解決を実施することをさらに含む、請求項２に記載の方法。

【請求項7】

前記コンセンサスアルゴリズムが、トランザクション処理コンピューティング要素のセット全体にわたって、固定長ラウンドにおいて遂行される、請求項１に記載の方法。

【請求項8】

前記ラウンドのそれぞれについて、前記トランザクション処理コンピューティング要素のうちの１つをリーダーとして選出することをさらに含む、請求項７に記載の方法。

【請求項9】

前記コンセンサスアルゴリズムの実行中、１つ以上のトランザクション処理コンピューティング要素が、有効であると判断されたデータブロックに署名をする、請求項７に記載の方法。

【請求項10】

前記コンセンサスアルゴリズムの実行中、１つ以上のトランザクション処理コンピューティング要素が、１つ以上のデータブロックを確定して前記追加される一方の不変なデータブロックのチェーンにする、請求項１に記載の方法。

【請求項11】

前記ネットワークコアでのネットワーク分割に関連してフォークが生じる、請求項２に記載の方法。

【請求項12】

前記フォークを検出して解決することをさらに含む、請求項１１に記載の方法。

【請求項13】

前記追加される一方の不変なデータブロックのチェーンが、ブロックチェーンである、請求項１に記載の方法。

【請求項14】

トランザクション要求を受信して、追加される一方の不変なデータブロックのチェーンに加工する、ネットワークコアを構成するトランザクション処理コンピューティング要素のセットに関連して運用する方法であって、データブロックはトランザクションの集合であり、トランザクションがデータブロック内に記録されて存在することは暗号化ハッシュにより検証可能であり、
サードパーティに関連付けられるレガシーコンピューティング基盤から発するトランザクション要求を受信することと、
前記トランザクション要求を受信したことに応答し、前記トランザクション処理コンピューティング要素が前記チェーンでのフォークを防ぐのに十分な定足数分は存在しない場合に、信頼度ベースのコンセンサスアルゴリズムにしたがい、前記トランザクション処理コンピューティング要素を使用して、データブロックの個々のセグメントをマイニングすることと、
前記フォークを検出してそれから回復することと
を含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本特許出願は、一般に、分散型ネットワークにおけるコンピューティングリソースのセットにわたる分散型記録システムを管理することに関する。

【背景技術】

【0002】

分散型コンピュータシステムは、従来技術においてよく知られている。そのような分散型コンピュータシステムの１つは、サービスプロバイダによって運用および管理される「コンテンツ配信ネットワーク」（ＣＤＮ）または「オーバーレイネットワーク」である。サービスプロバイダは、通常、サービスプロバイダの共有インフラストラクチャを使用するサードパーティ（顧客）に代わってコンテンツ配信サービスを提供する。この種の分散型システムは、通常、コンテンツ配信、ウェブ・アプリケーション・アクセラレーション、または外部委託元サイトのインフラストラクチャの他のサポートなどの様々なサービスを容易にするように設計されたソフトウェア、システム、プロトコルおよび技術とともに、ネットワークまたは複数のネットワークによってリンクされた自律型コンピュータの集まりを指す。ＣＤＮサービスプロバイダは、通常、顧客ポータルに用意された後にネットワークに展開されるデジタルプロパティ（ウェブサイトなど）を介してサービス配信を提供する。

【0003】

ブロックチェーンは、暗号化を使用してリンクおよび保護されるブロックと呼ばれる継続的に増加するレコードのリストである。各ブロックは、通常、前のブロックにそれをリンクする暗号化ハッシュとトランザクションデータとを含む。分散型台帳として使用する場合、ブロックチェーンは、通常、新たなブロックを有効化するためのプロトコルに集合的に準拠するピアツーピアネットワークによって管理される。記録されると、任意の所与のブロックのデータは、ネットワークの大多数の結託を必要とする後続の全てのブロックを変更せずに遡及的に変更されることはできない。ブロックチェーンは、イベントの記録、様々なレコード管理アクティビティ（識別子管理、トランザクション処理、出所の文書化など）およびその他に適している。一般化すると、ブロックチェーンは、後続の全てのブロックの変更およびネットワークの結託なしにはレコードを遡及的に変更することができないように、多くのコンピュータにわたるトランザクションを記録するために使用される非中央集権化された分散型デジタル台帳である。典型的なブロックチェーンでは、ブロックは、ハッシュされてデータ構造に符号化される有効なトランザクションのバッチを保持する。この構造では、前述のように、各ブロックは、ブロックチェーン内の前のブロックにそれをリンクする暗号化ハッシュを含む。リンクされたブロックは、チェーンを形成する。この反復プロセスは、元の起源（または最初の）ブロックに遡って、前のブロックの整合性を確認する。

【0004】

ブロックチェーンの実装を用いて、様々な応用分野をサポートすることができ、その一部はセキュリティ要件を高めてきた。ビットコイン、イーサリウム、および他の派生物などの既知のシステムでは、ウォレットにより使用される秘密鍵（すなわち、ウォレットに関連付けられる値を使用すること）をセキュアにすることに、主に注目している。さらに、ウォレットのセキュリティは、このようなシステムの設計および実装において引き続き重要な考慮事項であり、また、例えば、ホスト型またはサーバベースのウォレット、サーバベースの連署または複数署名ベースのトランザクション、ならびに口座の運用管理および関連付けられた値などの拡張した使用例のセットがあり、これらはさらなるセキュリティ上の課題を提示する。特に、これらの機能は著しい利点を提供するが、攻撃表面、すなわち、潜在的なセキュリティ侵害の数および経路をさらに大きくする可能性がある。

【発明の概要】

【0005】

本開示は、（情報または値の変形、変換または転送を含む）多数のトランザクションがスケーラブルで信頼性があり、安全且つ効率的な方法で同時に処理される高性能分散型台帳およびトランザクション・コンピューティング・ネットワーク・ファブリックを提供する。一実施形態では、コンピューティング・ネットワーク・ファブリックまたは「コア」は、チェーンのブロックの通信、処理および記憶が、トランザクション自体がリモートソースから発生している場合であっても、ほとんど同期せずに、非常に高い性能および低いレイテンシで、同時に実行されることを可能にするように、ブロックチェーンのデータを編成する分散型ブロックチェーンネットワークをサポートするように構成される。このデータ編成は、処理メッシュとして構成された自律的で協調的なコンピューティングノード内のトランザクション空間のセグメント化に依存している。各コンピューティングノードは、通常、コア内の他の全てのノードと機能的に同等であり、各ノードは、システムの全負荷を負担できることが好ましい。コンピューティングノードは、通常、コンピューティング、通信および記憶要素のクラスタを備える。より一般的には、コアネットワークを構成する全てのコンピューティングノードは、互いに等しいと見なされることが好ましく、スタンドアロンの個々のノードは、信頼できると見なされない。さらに、互いに関して、ノードは、自律的に動作し、好ましくは、いずれのノードも他のノードを制御することができない。ノードは、全体としてブロックチェーンの一貫した論理的に完全なビューを維持しながら、互いに独立してブロックを操作する。

【0006】

一実施形態では、処理コアは、例えば、ＣＤＮなどのオーバーレイネットワークのエッジサーバなどのエッジネットワークを介してアクセス可能である。この実施形態では、ＣＤＮエッジネットワークは、メッセージ処理サービスを提供するグローバルベースの分散型システムをサポートし、メッセージは、トランザクションに関連付けられている。エンドユーザのマシンおよびサービスは、トランザクション要求と、分散型記録システムをサポートするコアに対する応答とをその後にルーティングする、ＣＤＮエッジネットワークと最初に相互作用する。

【0007】

本明細書の主題は、「信頼度ベースのコンセンサス」の概念、および上述のようなブロックチェーン記録システムにおける自動化されたフォーク解決（fork resolution）を導入する。特に、本アプローチは、基礎となるネットワークが停止した場合にブロックチェーンが動作し続けられるようにし、完全なコンセンサス（ファイナリティ）が達成される前の任意の不確実な期間にクライアント（例えば、ウォレット）がトランザクションの処分について決定することを可能にする。

【0008】

上記は、主題のより適切な特徴のいくつかを概説している。これらの特徴は、単なる例示であると解釈されるべきである。開示された主題を異なる方法で適用することによって、または説明されるように主題を変更することによって、多くの他の有益な結果を得ることができる。

【図面の簡単な説明】

【0009】

主題およびその利点をより完全に理解するために、ここで添付の図面と併せて以下の説明を参照する。

【図1】本開示にかかる、トランザクションがブロックチェーンに編成された分散型記録システムを提供するネットワーキングアーキテクチャを示すブロック図である。

【図2】本明細書の技術にかかるブロックセグメンテーションを示している。

【図3】セグメント化されたブロックチェーンを示している。

【図4】セグメントの移行および再割り当てプロセスを示している。

【図5】本開示のノード間セグメント処理プロセスを示している。

【図6A】トランザクション有効化を実行しているときの代表的なコンピューティングノードのブロック図およびその動作を示している。

【図6B】ブロックマイニングおよび検証を実行しているときの図６Ａのコンピューティングノードおよびその動作を示している。

【図7】本開示の同時処理技術の高レベル描写である。

【図8】本開示にかかるストリーミングブロックの生成、送信および有効化を提供するために様々なノードおよびノード要素の間で実行される動作の詳細な描写である。

【図9】コンピューティング・ネットワーク・ファブリックに関連付けられることができるコンテンツ配信ネットワーク（ＣＤＮ）アーキテクチャを示している。

【図10】代表的なマシン構成を示している。

【図11】オーバーレイネットワークエッジのネットワークによって囲まれた決済ネットワークコアのブロック図を示している。

【図12】マーチャント接続モジュールと、エッジサーバネットワークと、ブロックチェーンベースの分散型記録システムのコア要素との間の、エンドツーエンドの接続性を示している。

【図13】分散型記録システムが、どのようにレガシー基盤と統合されるかを示している。

【図14】コンセンサスのラウンド、特に、リーダー選出、ブロック生成、およびブロックｗｉｔｎｅｓｓに関連付けられる事象についてのタイミング図である。

【発明を実施するための形態】

【0010】

全体的な高レベル設計
図１は、トランザクションがブロックチェーンに編成された分散型記録システムを実装するためのスケーラブルな高性能アーキテクチャを示している。高レベルでは、システムは、示されているように複数の機能領域、すなわち、周辺１００ａ、エッジ１００ｂ、およびコア１００ｃに分割されている。システムは、配信、管理、運用、管理、構成、分析などを容易にするために他の機能領域を備えることができるが、簡単にするために、これらの領域は示されていない。本明細書において使用される場合、周辺１００ａは、一般に、境界１０１に関連付けられた要素を指す。これらの要素は、通常、クライアントサーバベースの電子ウォレットまたはウォレットデバイス、端末および販売時点管理デバイス、レガシー金融ネットワーク要素および関連するアダプタを含む。一般に、本明細書において使用される場合、限定されるものではないが、金融トランザクションを含む、トランザクションの作成および消費に関与する任意の要素は、周辺１０１内の要素とすることができる。周辺は、グローバルに広がることができる。エッジ１００ｂは、通常、境界１０２に関連付けられたオーバーレイネットワークの要素を指す。代表的な要素は、これらに限定されるものではないが、オーバーレイ・エッジ・ネットワーク（例えば、Ａｋａｍａｉ（登録商標）などのＣＤＮ）で実行される処理、通信および記憶要素（エッジサーバ、スイッチ／ルータ、ディスク／ＳＳＤ）を含む。上述したようなＣＤＮは、有利には、要求されたトランザクションおよびそれらに関連する結果を集約し、（周辺機器における要素との間で）後述するように効率的にルーティングする、（エンドユーザ／デバイスと比べて）低レイテンシのプレゼンスポイントを提供する。ウォレットサービスは、エッジ内に配置されることができる。エッジ要素はまた、個別に、集合的に、および他のサービスと連携して、攻撃および他の敵対的な活動からコア１００ｃを保護するセキュリティ境界として機能する。ＣＤＮ固有の実装が好ましいが、本明細書のシステムにおける典型的なエッジネットワークは、ＣＤＮエッジネットワークに限定される必要はない。これに限定されるものではないが、クラウドベースのシステムを含む新規なまたは既存の任意の適切なネットワークが使用されることができる。

【0011】

コア１００ｃは、境界１０３に関連付けられた要素を指す。後述するように、コア１００ｃは、これらに限定されるものではないが、スループット、応答時間、セキュリティおよびデータの整合性を含む特定の性能要件を満たすトランザクションブロックチェーンの処理および記憶をともにサポートするノードの高性能ネットワークであることが好ましい。この文脈におけるノード（「コンピューティングノード」と呼ばれることもある）は、通常、コンピューティング、通信および記憶要素のクラスタである。より一般的には、本明細書において使用されるクラスタは、１つ以上の、そしておそらく多くのコンピューティング、通信および記憶要素を指す。一実施形態では、コア１００ｃは、オーバーレイネットワークノードを備えるが、コア１００ｃは、ＣＤＮとは異なり且つ（説明されるように）コア動作専用のノードのセットを備えることができるため、これは要件ではない。通常、コンピューティングノードは、ネットワークトランジットによって相互接続され、トポロジ的なボトルネックを軽減または排除する高度な相互接続性を有する。

【0012】

高性能を促進するために、好ましくは、コアネットワークは、高品質、大容量、および多様な相互接続を使用して構築される。コアネットワークの特定の構成は、通常、ブロックチェーンに実装されているコンセンサスプロトコルの性質に少なくとも部分的に基づく実装に依存している。使用されるコンセンサスプロトコルに応じて、コアネットワーク全体のレイテンシが十分に低いネットワーク通信を確保するために、必要に応じて、コアネットワークのサイズ（および／またはその中の様々なコンピューティングノードの分布）が制限されることもできる。

【0013】

非限定的な一実装では、ＣＤＮエッジ１００ｂは、（例えば、所与の地理における複数のネットワーク化されたデータセンタにわたって配置される）コアネットワーク１００ｃに関連付けられたグローバルベースのサービスをサポートする。

【0014】

再び図１を参照すると、メッセージ１０４は、トランザクション要求をエッジサーバ（例えば、ＣＤＮエッジサーバなど）に送信するデバイス（例えば、エンドユーザデバイス、電子ウォレットなど）の例である。多数のそのようなメッセージ（そして本明細書で説明するようにコアネットワークに送信されてコアネットワークによって処理されるものである）は、世界中のサーバ、デバイス、およびウォレットから発信されると予想されることを理解されたい。メッセージは、永続的な接続または一時的な接続を介して送信されるだけでなく、それらのネットワークが本明細書で説明するシステム機能をネイティブにサポートするために構築されたレガシーまたはネットワークインフラストラクチャの目的の一部とすることができる新たなまたは既存のネットワークを介して送信されることができる。さらに、メッセージは、システムへの任意の単一の進入ポイントへの依存を減らすために１つ以上のエッジサーバに送信されることができる。

【0015】

メッセージ１０５は、トランザクション（おそらくメッセージ１０４に含まれるものを含む）をコアノード１１０（ノード１１０のセットが描かれている）の適切な要素にルーティングするエッジ要素の例である。所与のトランザクションの場合、同じトランザクションまたは同じトランザクションのハッシュ（または他のダイジェスト）を他のコアノードの適切な要素にルーティングする複数のメッセージ１０５が存在することができる。全てのメッセージ１０５がトランザクションの完全な表現を含む必要はない。トランザクションのダイジェストが送信され、（１）コア要素にトランザクションの存在を認識させ、（２）完全なトランザクションを含むメッセージの整合性をチェックする堅牢な方法を提供することができる。これは、全てのコアノードの適切な要素に対する到来トランザクションメッセージの完全な、さらに効率的な伝播を可能にする。また、従来のゴシッププロトコルに関連するネットワーク負荷を大幅に削減し、さらに、例えばセキュリティを侵害されたエッジエレメントのトランザクションの検閲や破損からの保護を提供する。

【0016】

メッセージ１０６は、トランザクションを他のコアノードの適切な要素にルーティングするコアノード要素の例である。コアノード要素がシステムのコアノードにわたるトランザクションまたはトランザクションダイジェストの伝播に参加するように、複数のメッセージ１０６が存在することができる。メッセージ１０６を受信するコアノードは、次に、他のメッセージ１０６を生成し、システムのコアノード全体にメッセージをさらに伝播することができる。

【0017】

トポロジ認識データ伝播
任意のデータ伝播プロトコルが使用されることができるが、本明細書の１つの好ましいアプローチは、基盤となるネットワークトポロジへの伝播を形成することにより、従来のランダム化ピアツーピアゴシッププロトコルのコストとレイテンシを改善することである。協調して、メッセージ１０４、１０５、および１０６は、トポロジ的に最も近い要素から始まり、トポロジ的に少ないまたは最も近くない要素に到達する伝播の経路を含む。他のエッジ要素にメッセージ１０４を送信するデバイスは、通常、ネットワーク全体の様々な伝播経路をたどる。これは、異なる方向に伝播するメッセージ１０７、１０８、および１０９によって示されている。さらに、所与のデバイスから始まる伝播の経路は、一般に、適切な負荷バランシングとセキュリティを実現するために時間とともに変化することがある。

【0018】

サービス発見および高性能マッピング
再び図１を参照すると、メッセージが送信される前に、メッセージを発信する各要素は、通常、受信要素のアドレスを発見しなければならない。アドレスは、インターネットプロトコル（ＩＰ）アドレス、またはいくつかの種類のネットワーク（例えば、ピアツーピアネットワークまたはオーバーレイネットワーク）のアドレス空間における他の名称もしくは番号とすることができる。他の要素のアドレスの発見は、様々な方法で実現されることができるが、一般に、一連の要素属性を発見サービスに送信することと、返信としてアドレス情報を受信することとを含む。好ましい一実施形態では、発見されるシステム要素の属性は、ドメイン名として符号化され、それにより、システムがＣＤＮの高性能ドメイン名ルックアップサービスを使用して必要なアドレス情報を返信することを可能にする。オーバーレイネットワークのマッピング技術を使用することは、いくつかの利点を提供する。それは、最大規模の展開さえも可能とするように大規模なドメイン名空間をサポートする。これは、例えば、エッジ要素が、トランザクションをコアノードだけでなく、トランザクションの識別子空間の関連部分を処理するコアノード内の特定の要素にさえもルーティングすることを可能にする。これと同じ種類の細粒度ルーティングは、コアノード要素間の通信のために行うことができ、特に、ＣＤＮ ＤＮＳサービスを使用すると、セグメントのセット、パーティション、またはトランザクション情報の他のグループを処理する１つのノードの要素は、同じセグメント、パーティション、またはトランザクション情報の他のグループを処理する他のコアノードの要素にメッセージを直接送信することができる。トラフィックは、低レベルのネットワークルータ／スイッチの一般的なセットを通過することができるが、コアノードは、各トランザクションを個別に検査してルーティングする必要がないことから、これは有利である。この方法でＣＤＮネームサービスを使用すると、再構成もサポートする。特に、ノードの構成が変化した場合、例えば、トランザクション空間の一部の責任が１つのサーバから他のサーバに移行されることから、変化は、ネームサービスのマッピングシステムを介して迅速に且つ効率的に伝達される。ＣＤＮネームサービスを使用する他の利点は、一時停止の概念をサポートすることである。したがって、エッジ要素またはコアノード要素が正常に機能しなくなったり、動作不能になったりした場合、マッピングシステムは、問題から遠ざけるようにトラフィックをマッピングすることができる。ＣＤＮネームサービスを使用するさらなる利点は、高解像度の容量消費測定に基づいてトラフィックの負荷バランシングをサポートするためのそのようなシステムの能力である。このアプローチはまた、周辺のデバイスが最小限の基盤となるサービスおよびネットワークコンポーネントを共有するエッジ要素のアドレス情報を受信することができるように、ルートと領域の多様性もサポートする。ＣＤＮ ＤＮＳサービスはまた、レイテンシの最適化もサポートする。例えば、コアノード要素は、いくつかの近接基準を満たす他のコアノード要素のアドレスを受信することができる。

【0019】

代替の実施形態は、位置または方向認識マッピングを利用する。したがって、例えば、コアノード要素は、所望の位置もしくは方向にあるまたは方向性グラフを構成するノード要素に応答がアドレスを提供するように、位置または方向情報（地理的またはトポロジ方向のいずれか）によって符号化されたドメイン名を使用することができる。この機能は、マッピングシステムに固有とすることができるかまたはマッピングシステムに付属することができる。この方法でのトポロジ的マッピングは、低レイテンシのトポロジ認識データ伝播機構を提供する。

【0020】

一般化
本明細書において使用される場合、ブロックは、一般に、トランザクションデータの任意の集約または関連付けを指す。特定のフォーマットは必要ない。ブロックチェーンは、暗号化を使用してリンクおよび保護されるブロックと呼ばれる継続的に拡大するレコードのリストである。ブロックチェーンの各ブロックは、通常、前のブロックにリンクする暗号化ハッシュとトランザクションデータとを含む。分散型台帳として使用する場合、ブロックチェーンは、通常、ノード間通信と新たなブロックの有効化のためのプロトコルに集合的に準拠するピアツーピアネットワークによって管理される。記録されると、任意の所与のブロックのデータは、ネットワークの大多数の結託を必要とする後続の全てのブロックを変更せずに遡及的に変更されることはできない。

【0021】

本明細書の技術は、ブロックチェーンを使用してトランザクションデータを記録することができるが、本開示のシステムのアーキテクチャおよび関連するトランスポート機構は、トランザクションデータの他の編成にも適用することができるため、これは限定されるものではない。さらに、ブロックのチェーンまたはシーケンスにおけるようなブロックチェーンの概念は、これらに限定されるものではないが、ブロックツリー、ブロックグラフなどを含むブロックの任意の編成とすることができる。

【0022】

マイニングは、ブロックチェーンにおける前のブロックを参照するヘッダを有する順序付けられたトランザクションのブロックを生成する行為である。公の（無許可の）ブロックチェーンコンセンサスシステムでは、マイニングは、一般に、競争として構成され、生成されたブロック（およびその祖先）がマイニング競争およびその後のコンセンサスプロセスに耐えた場合、それは確定され、永続的な記録の一部と見なされる。理想的なシステムでは、あるラウンドから次のラウンドへの（すなわち、あるブロックから次のブロックへの）マイニング責任は、参加者間でランダムに分散される。正式には、理想的なシステムでは、マイニングの決定は、予測可能ではなく、影響を与えることができず、検証可能である。しかしながら、現実世界の用途では、分散は、完全にランダムである必要はない。例えば、作業証明システムでは、マイニング能力が高いエンティティほど競争に勝つ確率が高いため、分散は、実際にはランダムではない。

【0023】

セグメンテーション
従来のブロックチェーンの実装では、ブロックチェーンを単純なブロックのシーケンスとして扱う。そのようなアプローチは、通常、処理のボトルネックを形成し、ブロックチェーンをその集約形式で通信および記憶することによって、ブロックチェーン実装の達成可能な性能を厳しく制限する。

【0024】

対照的に、本明細書で説明するアプローチは、その通信、処理および記憶が非常に高い性能でほとんど同期せずに同時に実行されることを可能にするように単一チェーンのデータを編成することにより、公知の技術から逸脱している。理解されるように、このデータ編成は、ブロックチェーンの一貫した論理的に完全なビューを維持しながら、各ノード内のトランザクション空間のセグメント化に依存することが好ましい。このアプローチはまた、連合またはシャーディングされたブロックチェーンのセットを構成する複数のチェーンのそれぞれにも適用されることができ、ブロックチェーン操作の性能を改善し、それにより、作業を減らし、オフチェーン（いわゆる「レイヤ２」）システムの性能を向上させる。

【0025】

このアプローチでは、ネットワークにまたがるコンセンサスアルゴリズムが使用され、システムが正しい最終結果を生成することを確実にする。使用できる特定のコンセンサスアルゴリズムは、限定されるものではない。しかしながら、各ノード内の操作では、ノードの要素が正しく信頼できると想定している。ノードに障害が発生したり、攻撃者によって破壊された場合、システムは、ネットワークの残りの部分に依存して、サービスの整合性と可用性を維持するとともに、障害および侵入検出機能をサポートする。見てわかるように、この設計アーキテクチャは、システム要素がブロックチェーンデータ編成と整合するように、ノードの内部が、高性能、低レイテンシの通信ファブリックで実行される疎結合分散型システムとして編成されることを可能にする。結果として得られるアーキテクチャは、公知の技術と比較してはるかに高い性能の実装を提供する。

【0026】

ブロックセグメンテーション
図２を参照すると、ブロック２００は、トランザクションｉｄ（Ｔｘｉ）によって、いくつかのセグメント２０２ａ－ｎ（ここで、ｎ＝１０００）と、ヘッダ（Ｈｄｒ）２０４とにセグメント化される。セグメント２０２およびヘッダ２０４は、ブロックチェーンのブロックを表すが、それらは、（多くの場合）個別に処理、送信および記憶されることができる。図２に１０００として示されるセグメント２０２の数は、数がより多くても少なくてもよく、時間とともにまたは動的に変化してもよい。好ましくは、十分な数のセグメントが選択されて、データのセグメンテーション（編成）を変更する必要なしに、基礎となるリソースの実質的な将来の成長を可能にするのに十分な大きさの空間を形成する。

【0027】

この実施形態では、ブロックセグメンテーションは、通常、ネットワークの全てのノードによって共有される外部から見える属性である。見てわかるように、セグメントによってブロックデータを編成することにより、ブロック情報を交換するノードの性能と効率を大幅に向上させる。特に、本明細書のアプローチは、所与のセグメントの処理を担当するノードのコンポーネントが、所与のセグメントの処理を担当する他のノードのコンポーネントと直接通信することを可能にする。さらに、コンポーネントへのセグメントのマッピングは、ノード間で異なることができ、それにより、例えば、トランザクションデータの総量を処理する際にノードが異なる数のリソースを使用することを可能にすることによるなど、スケールアップ（またはスケールダウン）展開を可能にする。

【0028】

代替の実施形態では、セグメンテーションの詳細は、厳密にノードの内部属性のままであってもよい。そのような実施形態では、ノードのコンポーネントへのセグメントのマッピングは、任意とすることができる。この代替手段は、ノードの構成の独立性を高めることができるが、一般に、ノード内のトランザクションレイヤルーティングのいくつかの形式を含む、ノード間のより詳細な（例えば、トランザクションごとの）データ交換を必要とする。

【0029】

本明細書で使用される場合、セグメンテーションという用語は、暗黙的であれ明示的であれ、１つのノードの要素が他のノードの要素と相互作用して一度に複数のトランザクションのデータを交換することができるように、トランザクションデータの任意のグループ化、パーティション化、シャーディングなどを意味するために使用される。

【0030】

ヘッダ２０４は、いくつかの必須要素、すなわち、前のブロックヘッダのハッシュ２１０、ブロックのコンテンツのマークルルート２０８、およびブロックのマイナーが実際に正当なマイナーであったことを示す証明２０６を含む。他の情報が含まれてもよい。

【0031】

ブロックチェーンセグメンテーション
図３を参照すると、セグメント化されたブロックは、一時的に、セグメント化されたブロックチェーンを形成し、そのいくつかのブロックは保留されている（すなわち、まだ確定されていない）が、その他のブロックは確定されている（すなわち、ブロックチェーンに追加されている）。この例では、図示されている各マシン３００は、保留中のブロックと確定されたブロックとの双方をサポートするが、これは要件ではない。この分散型の編成は、このアプローチがブロックツリーまたはブロックグラフ構造などに関して、他のシナリオにも適用可能とすることができるため、ブロック「チェーン」に限定されるものではない。ブロックはまだ全体であるが、そのセグメントは、ブロックをモノリシックに処理するよりも効率的に処理されることから、このアプローチは有利である。図３に示されるように、様々な数のセグメントが異なるマシンリソースに割り当てられ、組み合わせられることができる。この種の編成は、仮想化およびコンテナ化された環境に特に適用可能であるが、いずれも恩恵を達成するために必要ではない。

【0032】

図４を参照すると、システムリソースへのセグメントの割り当ては、例えば、アップグレード、メンテナンスおよび障害回復をサポートするために、時間とともに変化することができる。この場合、１つのマシン４０２が故障したかまたはオフラインになり、それが処理していたセグメントが他のマシンに移行される。このアプローチは、日常的および緊急の理由の双方で、仮想またはコンテナ化されたコンピューティング要素を移行するという確立された概念によく適合する。

【0033】

セグメンテーションおよびノード間通信
図５を参照すると、セグメンテーションをノードの公開された属性にすることにより、ノード内の要素は、他のノードの要素と直接通信して、セグメントの細分性に関する情報を交換することができる。ノードへのセグメントのマッピングは、全てのノードにわたって同じである必要はない。

【0034】

後述するように、好ましい実施形態では、システムのコンピューティングノードは、それぞれ、トランザクション有効化、ならびにブロックマイニングおよび検証などの複数の別個の機能またはモード（動作役割）を実行することができる（多くの場合に実行する）。実際、所与のコンピューティングノードは、多くの場合、同時に複数のそのようなモードで動作する。典型的な動作シナリオでは、特定のノードは、マイニングに使用されることができるが、通常、全てのコンピューティングノードは、何がマイニングされるかを検証する。

【0035】

図５は、ブロックマイニングおよびブロック検証の編成が好ましくはセグメンテーションの存在下で達成される方法を示している。この例では、他のコンピューティングノード５００ｂ、５００ｃおよび５００ｄがブロックを検証する（本明細書では「検証」と呼ぶ）マシンを備える一方で、コンピューティングノード５００ａにおけるブロックの生成／マイニングのために使用される多数のマシンが存在すると想定している。図示のように、ブロック・マイニング・イベントは、ブロックのマイニングまたは生成を開始しようとしていることを通知する、マイニングノード５００ａによって（一般に、生成および有効化ブロックヘッダを処理する要素によって）ネットワークの他のノード（この例では、ノード５００ｂ、５００ｃおよび５００ｄ）に送信されるメッセージ５０２によって開始される。ノード５００ｂ、５００ｃおよび５００ｄの対応する要素は、このメッセージを受信し、マイニングノードの要素からのマイニングされたブロックデータを予期するようにそれらのノードの処理要素に通知する。同時に、５０３などの複数のメッセージシーケンスが、生成されたセグメントごとに、それらのセグメントを処理するマイニングノードの要素によって、リモート検証ノードの各セグメントを処理する要素に（それぞれ）送信される。

【0036】

マイニングされたセグメントが終了すると、そのセグメントを担当する要素からブロックヘッダを担当する要素にメッセージ５０４が送信される。メッセージは、とりわけ、生成されたセグメントのマークルルートを含む。全てのメッセージ５０４が送受信されると、ブロックヘッダを担当する要素は、ブロック・マークル・ツリーの上部を作成し、ヘッダにマークルルートを保存する。そして、ヘッダの生成および検証の処理を担当する他のノードの要素にメッセージ５０５を送信する。有効化を実行する際、セグメントのメッセージ５０３を受信すると、セグメントを処理する受信ノード要素は、受信したトランザクションを有効化し、セグメントのマークルツリーを計算し、完了すると、ヘッダを処理するノードの要素にメッセージ５０６を送信する。その要素は、全てのセグメントのメッセージ５０６からブロックヘッダを再構築し、それをメッセージ５０５内のマイニングノードから受信したヘッダと比較する。ヘッダがマッチする場合、ブロックは受け入れられ、そのノードの事前に確定されたブロックのセットに追加される。

【0037】

一実施形態では、トランザクションが検証に失敗するかまたは再構築されたヘッダがマイニングノードから送信されたヘッダとマッチしない場合、ブロックは拒否され、全ての変更が逆行されてノードから消去される。

【0038】

他の実施形態では、有効化ノードは、同じセグメントについてメッセージ５０６の異なる値にマイニングするマシンにフラグを立てることができ、それにより、１つ以上の故障または悪意のあるマシンからシステムを保護する。

【0039】

上述した処理を以下により詳細に説明する。

【0040】

セグメンテーションおよびノード編成
図６Ａおよび図６Ｂは、システムのコンピューティングノードの動作を示し、図６Ａは、初期トランザクション有効化に関与するノード要素の動作を示し、図６Ｂは、ブロックマイニングおよび検証に関与するノード要素の動作を示している。

【0041】

図６Ａおよび図６Ｂに示されるように、ノードは、トランザクション有効化ならびにブロックマイニングおよび検証に関連する個別にスケーラブルなタスクを実行するためにともに機能するいくつかの要素またはコンポーネントを含む。これらのコンポーネントは、ノードコーディネータ６０１、１組のセグメントハンドラ６０４、１組のトランザクションハンドラ６０９、１組のＵＴＸＯ（未使用トランザクション出力、Ｕｎｓｐｅｎｔ Ｔｒａｎｓａｃｔｉｏｎ Ｏｕｔｐｕｔ）ハンドラ６１４、および１組の署名検証部６１７を含む。セグメントハンドラおよびトランザクションハンドラは、別個のものとして示されているが（これが好ましい）、これらの機能は、後述するように双方の機能を実行する複合ハンドラに組み合わせられることができる。さらに、通常、各ハンドラには複数のインスタンスがあるが、その処理能力に応じて１つで十分な場合もある。

【0042】

背景として、そして上記のように、好ましくは、各ノードは、システムにおける他の全てのノードと機能的に同等であり、各ノードは、システムの全負荷を担う。より一般的には、システムにおける全てのノードは、互いに等しいと見なされ、スタンドアロンの個々のノードは、信頼できると見なされない。さらに、互いに関して、ノードは、自律的に動作し、いずれのノードも、別のノードを制御することができない。

【0043】

ノードは、一般に、以下のように動作する。トランザクション有効化においては、図６Ａを参照すると、通常、未処理のトランザクションがエッジマシン（または他のノード）から転送されるときに、６１２においてそれら未処理のトランザクションがノードにおいて継続的に受信され、最初にトランザクションハンドラ６０９によって処理される。トランザクションは、通常、（例えば、それに関連付けられたまたはそこで実行されているウォレットサービスによって）ウォレットまたはウォレットのセットに作成され、ウォレットは、通常、エッジマシンと相互作用し、周辺からトランザクション要求を受信するか、または６１２において受信されてトランザクションハンドラ６０９によって処理される場合、ブロックチェーントランザクションをコアに転送する。一般に、トランザクションハンドラによる未処理のトランザクションの処理が「有効化」であり、未処理のトランザクションがトランザクションハンドラによって「有効化」されると、トランザクションは、トランザクションハンドラのメモリプール（または「ｍｅｍプール」）に配置される。トランザクションハンドラによって有効であると見出されなかった未処理のトランザクションは拒否され、ハンドラのメモリプールに配置されない。

【0044】

この目的のために、受信（すなわち、未処理のトランザクションがノードへ進入）すると、トランザクションハンドラ６０９は、通常、２つの基本的なアクションを実行する。図６Ａに示されるように、トランザクションハンドラ６０９は、（６１５において）ＵＴＸＯハンドラ６１４にクエリを出し、トランザクションへの入力が存在するかどうかを判定し、存在する場合、（６１６において）ＵＴＸＯハンドラ６１４によって管理されているＵＴＸＯ空間からそれらの入力を取得する。入力が存在しない場合、クエリを受信したＵＴＸＯハンドラは、トランザクションハンドラに通知し、トランザクションハンドラは、未処理のトランザクションを拒否する。ＵＴＸＯハンドラ６１４から入力を受信すると、トランザクションハンドラ６０９は、（６１８において）署名検証部６１７を参照して、各入力に関連付けられたロック解除スクリプト（デジタル署名）が有効かどうかを判定する。通常、各入力は、トランザクションのロック解除スクリプト（デジタル署名）を含むため、署名検証部によって実行される署名検証は、トランザクションによって使用される各ＵＴＸＯに関連付けられたロックスクリプト（公開鍵）と署名がマッチするかを確認する署名検証を含む。この動作の詳細については、以下に説明する。したがって、この確認は、暗号化動作を含み、計算集約的であり、したがって、署名検証部は、ＵＴＸＯハンドラから受信した有効な入力についてのみトランザクションハンドラによって参照されることが好ましい。署名検証部６１７は、６１９において入力（特に、入力署名）の有効性を確認する。トランザクションハンドラは、入力がトランザクションハンドラによって受信されると、ＵＴＸＯハンドラおよび署名検証部と同時に相互作用することができる。全ての入力署名が署名検証部６１７によって検証されると、未処理のトランザクションは、トランザクションハンドラによって「有効」または「有効化済み」と見なされ、６１５において、トランザクションハンドラ６０９は、新たなトランザクションに関連付けられたＵＴＸＯを担当するＵＴＸＯハンドラ６１４において新たなトランザクション出力（ＵＴＸＯ）を作成する。この動作では、作成要求は、１つのＵＴＸＯハンドラ、すなわち、トランザクションに関連付けられたトランザクションｉｄ空間の部分においてＵＴＸＯを処理する１つのハンドラにのみ送信される。また、図示されているように、（６１５において）作成呼び出しが送信され（クエリおよび署名検証が成功した後）、新たなトランザクション出力（ＵＴＸＯ）を開始する。

【0045】

この方法で全ての入力が検証されると、未処理のトランザクションがトランザクションハンドラのメモリプールに配置される。そして、（有効化された）未処理のトランザクションは、６１３を介して全ての他のノードに出力（すなわち、伝播）され、未処理のトランザクションを受信する他の各ノードは、ここで説明したのと同様の一連の動作を実行する。これで未処理のトランザクションのローカル有効化動作を完了し、これは、結果としてトランザクションハンドラのメモリプールに入れられる。上述したプロセスは、未処理のトランザクションがノードにおいて（再度、エッジマシンまたは他のノードのいずれかから）受信されると継続する。

【0046】

したがって、未処理のトランザクションを受信するトランザクションハンドラは、トランザクションへの入力が存在するかどうかを（ＵＴＸＯハンドラのクエリから）判定し、存在する場合は、それらの値とロックスクリプト（アドレスまたはウォレットアドレスと呼ばれることもある公開鍵を含む）が何であるかを判定する。それは、各入力のロック解除スクリプト（デジタル署名）を確認し、全ての署名が有効である場合、トランザクションハンドラは、未処理のトランザクションをその関連するメモリプールに収容（保存）する。このようにして、有効化済みの未処理のトランザクションは、各ハンドラのメモリプールに蓄積される。したがって、各トランザクションハンドラのメモリプールには、ブロックチェーンにおけるブロックセグメント（したがってブロック）に対してマイニングされる（すなわち、割り当てられる）ことを実質的に「待機している」トランザクションの集合（セット）が存在する。好ましくは、システムは、最小待機時間を強制して、新たなトランザクションが伝播してシステムの他のノードによって有効化されることを可能にする。

【0047】

ここで、ノードコーディネータ６０１がブロックをブロックチェーンにマイニングするときだと判定したと想定する。ブロックをマイニングするという概念は、ブロックがシステムの所定のコンセンサスアルゴリズムにしたがって確定的であるとノードコーディネータが判断したときに生じる（以下により詳細に説明する）ものであり、実際にブロックをブロックチェーンに追加するという概念とは異なる。通常、「マイナー」として機能するノードのサブセットが常に存在する。本明細書の技術によれば、説明したように、ブロックをコンポジットとしてマイニングする代わりに、ブロックは、「セグメント」単位でマイニングされる。すなわち、ブロックの個々のセグメントは（同時か並列式であるかにかかわらず）別個に、具体的にはセグメントハンドラ６０４によってマイニングされる。

【0048】

このために、ここで図６Ｂを参照すると、ノードコーディネータ６０１は、６０５を介してそれらのセグメントのマイニングを開始するように、その関連するセグメントハンドラ６０４に指示する。このコマンドは、通常、開始時刻、期間、および終了時刻を含む。ノードコーディネータはまた、マイニングされたブロックセグメントデータがマイニングノードのセグメントハンドラからシステムの他のノードのセグメントハンドラに直接（６０７を介して）送信されることを予期するように、（６０２を介して）システム内の他のノードコーディネータに通知する。セグメントハンドラのジョブは、トランザクションハンドラのメモリプールから有効化済みの未処理のトランザクションを取得および受信し、ブロックが確定されてブロックチェーンに追加される場合に、それらの有効化済みトランザクションをブロックセグメント（したがって、ブロック）で最終的に永続化するためにステージング（ｓｔａｇｅ）することである。代替の実施形態では、セグメントハンドラは、有効化済みのトランザクションのダイジェスト（ハッシュ）を取得および受信することができ、その場合、将来の永続化のためにトランザクションをステージングするジョブは、トランザクションハンドラにシフトする。

【0049】

後述するように、好ましくは、ブロック内の各セグメントの実際の永続性（およびブロックチェーン自体でのブロックの永続性）は、セグメントハンドラがノードコーディネータによってブロックを確定するように指示されるまで発生しない。通常、これは限定されるものではないが、セグメントハンドラ６０４とトランザクションハンドラ６０９との間に１：１の関係がある。上記のように、これらの機能は、実装において組み合わせることができ、１：１の関係が示されているが、ノードは、任意数のいずれかの種類のハンドラによって構成されることができる。

【0050】

マイニングを開始するコマンドを受信すると、６１０において、セグメントハンドラ６０４は、それぞれのメモリプール内のトランザクションをブロックに割り当て、未処理の各トランザクション（またはそのハッシュ）を返すように、（セグメントハンドラのためにセグメントを処理する）トランザクションハンドラに対して要求する。しかしながら、トランザクションハンドラは、そのメモリプールから要求元のセグメントハンドラに未処理のトランザクションを返す前に、マイニングされるブロックに関してトランザクション入力を最初に「使用する（ｓｐｅｎｄ）」（すなわち、実際のトランザクション値を入力に適用する）必要があり、それは（６２０を介して）使用要求をＵＴＸＯハンドラに送信することによって行われる。示されているように、ＵＴＸＯハンドラは、使用要求を適用し、それらのローカルデータを更新して、（６２１を介して）その結果（成功または失敗）をトランザクションハンドラに返す。

【0051】

失敗の応答が発生した場合、トランザクションハンドラは、６２０を介してＵＴＸＯハンドラにトランザクションの全ての成功した使用動作を取り消すように指示する必要がある。この衝突検出およびロールバックは、ＵＴＸＯハンドラにおいてロック（または複数のＵＴＸＯハンドラを有するノードの場合には分散型ロック）を取得することを未然に防ぎ、したがって高コストを回避する楽観的同時並行処理制御機構を構成する。これは、ＵＴＸＯ使用動作の効率的な高スループットの低レイテンシ処理を可能にする。

【0052】

全てのトランザクション入力の使用に成功すると、トランザクションハンドラは、６２０を介してＵＴＸＯハンドラにトランザクション出力（トランザクションのＵＴＸＯ）をブロックに割り当てるように指示し、６１１を介して未処理のトランザクション（および／またはそのダイジェスト）を要求元のセグメントハンドラに転送して戻す。

【0053】

ここで説明したセグメントハンドラとトランザクションハンドラとの相互作用は、トランザクションハンドラが図６Ａに示され且つ上述したように未処理のトランザクションを受信して処理し続けるときに実行される。図６Ｂを再び参照すると、セグメントハンドラ６０４は、互いに対して並列に動作し、各セグメントハンドラは、関連するトランザクションハンドラに同様の要求を行う。したがって、通常、マイニングされるブロックの特定のセグメントに関連付けられたセグメントハンドラとトランザクションハンドラとのペアがある。トランザクションハンドラ６０９は、要求元のセグメントハンドラ６０４に、そのメモリプールからの未処理の各トランザクションを、未処理のトランザクションについて計算されたダイジェストとともに提供することによって応答する。セグメントハンドラ６０４は、各トランザクション（およびそのダイジェスト）を受信し、トランザクションを当該セグメントの論理シーケンスにシーケンス化する。各セグメントハンドラは、その関連付けられているトランザクションハンドラから受信する未処理のトランザクションに対しても同様に動作するため、ブロックのセグメントは、同時に（セグメントハンドラによって）マイニングされる。セグメントハンドラが未処理のトランザクションをシーケンス処理するときに、それは、（６０７を介して）トランザクションのダイジェストを取得し、それらを（好ましくはダイジェストのみ）他の全てのノードに出力する。ネットワークの他のノードは、セグメントハンドラから伝播されたダイジェストを使用して、ローカルにマイニングされているセグメントを有効化する。セグメントハンドラはまた、６０８を介して（他のノードの）他のセグメントハンドラからダイジェストを受信する。

【0054】

セグメントハンドラ６０４は、セグメントが有効であると判定すると、その処理の結果、すなわち、セグメントに対して計算されたマークルツリーのルートを、６０６を介してノードコーディネータに返す。マイニング中、ノードコーディネータは、セグメントが有効であると信頼する。（同時に動作する）他のセグメントハンドラ６０４は、同様に機能し、それらのセグメントが同様に完了したことを示すそれらのマイニング結果を返す。

【0055】

（全てのセグメントのマークルルートを使用して）全てのセグメントハンドラがノードコーディネータに応答すると、ノードコーディネータは、（全てのセグメントマークルルートから）全体的なブロック・マークル・ツリーを計算し、全体的なブロック・マークル・ルートおよびその他の情報を組み込んだブロックヘッダを生成する。次に、ノードコーディネータは、６０２を介してブロックヘッダを含むマイニング完了メッセージをネットワーク内の他のノードコーディネータに送信／伝播した後、それらの他のノードコーディネータは、ブロック・マークル・ルートを使用して、次に説明するようにそれらのブロック検証プロセスを完了する。

【0056】

特に、ここで、ノードコーディネータ６０１が、６０３を介して、それ自体のブロックマイニング動作を開始する他のノードのノードコーディネータから送信されたマイニング開始メッセージを受信すると仮定する。これは、他のノードからマイニングおよび送信されたブロックデータのブロック検証プロセスを開始する。ブロック検証プロセスは、ブロックマイニングプロセスのバリエーションであるが、２つは異なり、多くの場合、ノードは、双方のプロセスに同時に関与する。実際、ノードは、通常、一度に１つのブロックのみをマイニングするが、同時に複数の到来ブロックを検証することもできる。マイニングと同様に、本明細書で説明する技術にしたがって、説明したように、ブロックをコンポジットとして検証する代わりに、好ましくは、ブロックは「セグメント」単位で検証される。すなわち、ブロックの個々のセグメントは（同時か並列式であるかにかかわらず）別個に、具体的にはセグメントハンドラ６０４によって検証される。

【0057】

このために、６０５を介して、ノードコーディネータ６０１は、それらがマイニングプロセスにおいてブロックにトランザクションをマイニング／割り当てるため、６０８において他のノードからトランザクションハッシュを受信し、それに応答して、マイニングノードのセグメントハンドラによって行われた関連するトランザクションブロックの割り当てを検証するようにその関連するセグメントハンドラ６０４に指示する。好ましくは、セグメントデータの検証は、（データが受信されるのにともない）漸進的に、およびマイニングノード内のブロックセグメントへの追加のトランザクションのマイニング／割り当てと同時に実行される。

【0058】

６０８を介して、トランザクションハッシュを受信すると、セグメントハンドラ６０４は、６１０を介してトランザクションハッシュをセグメントのトランザクションの処理を担当するトランザクションハンドラ６０９に転送する。セグメントハンドラからトランザクションハッシュを受信すると、トランザクションハンドラ６０９は、そのメモリプール内の関連するトランザクションレコードを調べる。

【0059】

トランザクションがメモリプールから欠落している場合、トランザクションハンドラ６０９は、（６２２を介して）要求を送信し、（６２３を介して）好ましくはトランザクションのマイニングを担当するマイニングノードにおけるトランザクションハンドラから欠落した未処理のトランザクションを受信する。この要求／応答アクションは、優先度の高い方法で迅速に処理されることが好ましい。欠落した未処理のトランザクションを受信すると、トランザクションのブロック割り当ての検証を再開する前に、トランザクションハンドラ６０９は、トランザクションをメモリプールに追加する前に、上述したようにトランザクションを有効化する必要がある。

【0060】

そのメモリプールからトランザクションを正常に取得すると、トランザクションハンドラは、上述したようにローカルにマイニングされているブロックにトランザクションを割り当てるのと同じように、検証されているブロックセグメントへのトランザクションの割り当てを実行する。しかしながら、割り当てが失敗した場合、セグメントおよびそれがその一部であるブロックの検証は失敗する（すなわち、ブロックは拒否される）。

【0061】

その後、ノードコーディネータは、所定のコンセンサスアルゴリズムを適用して、ブロックを確定することを決定する。このため、ノードコーディネータは、ブロックヘッダを永続化し、ノードのセグメントハンドラにブロックを確定するように指示する。そうすることで、ノードコーディネータは、ブロック・マークル・ツリー全体を各セグメントハンドラに提供する。次に、各セグメントハンドラは、ブロックに関連付けられたセグメントのセットを永続化し、関連するトランザクションハンドラにブロックを確定するように指示する。そうすることで、セグメントハンドラは、各トランザクションハンドラがそのセグメントのセットに必要とするブロック全体のマークルツリーの一部を生成してトランザクションハンドラに提供する。次に、各トランザクションハンドラは、そのアクティブなメモリプールから確定されたトランザクションを削除し、特に、トランザクションハンドラがセグメントハンドラから受信したブロックの全体的なマークルツリーの一部から派生したマークル証明を使用して、確定されたトランザクションについてエッジ（またはウォレット）から受信した任意の未処理のトランザクション要求に応答する。そして、トランザクションハンドラは、トランザクションの処理に関してトランザクションハンドラが受信することができる後続のクエリをサポートするために使用されることができる場合、確定されたトランザクションをメモリに保存する。次に、トランザクションハンドラは、ブロックを確定するように全てのＵＴＸＯハンドラに指示する。それに応じて、ＵＴＸＯハンドラは、確定されたブロックにおいて使用されたＵＴＸＯを永続的に使用済みとしてマークし、確定されたブロックに割り当てられたＵＴＸＯを永続的に作成済みとしてマークする。したがって、このようにブロックヘッダおよびセグメントをディスクに永続化することは、ブロックチェーンにブロックを追加する。実装に応じて、ブロックチェーンにそのように書き込まれたブロックは、最終的なものと見なされることができる（したがって、実質的に不変である）。

【0062】

要約すると、上述したノード処理では、トランザクションハンドラは、通常はエッジマシンから未処理のトランザクションを受信する。トランザクションハンドラが未処理のトランザクションを有効化（およびローカルメモリプールに配置）した後、トランザクションハンドラは、未処理のトランザクションを、その未処理のトランザクションの有効化も担当する他のノードの適切なトランザクションハンドラに伝播する。その後、ブロックセグメントのマイニングを開始するというノードコーディネータの決定に応じて、トランザクションハンドラは、そのメモリプールからブロックセグメントに未処理のトランザクションのセットをマイニングし（割り当て）、各セグメントを処理している要求元のセグメントハンドラにそれらの未処理のトランザクション（およびそれらの関連するダイジェスト）を送信する。セグメントハンドラは、受信したトランザクションをセグメントにシーケンス化し、その際、セグメントハンドラは、セグメントを構成するトランザクションのダイジェストのリストを、他のマイナーノードにおいてそれらのセグメントの処理を担当する他のセグメントハンドラに転送する。したがって、未処理のトランザクションは、全てのノードのトランザクションハンドラ全体に伝播するが、セグメントハンドラは、検証されることになるセグメントのトランザクションダイジェストのみを送信するのが好ましい。ブロックセグメントのマイニングおよび検証中に、トランザクションハンドラは、上述したように他のノードのセグメントハンドラと通信する、それらのローカルセグメントハンドラを参照する。したがって、異なるノードのトランザクションハンドラは、互いに通信して、（ＵＴＸＯおよび署名検証機能を使用して）それらの各メモリプールに有効化されたトランザクションを投入する。セグメントハンドラ（したがって、マイニングを処理するノードコーディネータ）は、互いに通信して、ブロックチェーンにセグメントを含むブロックを投入する。前述のように、トランザクションハンドラおよびセグメントハンドラは、別個のサービスである必要はない。

【0063】

上述したように、ブロック検証は、ブロックマイニングと同様である。ただし、検証の場合は、セグメントハンドラがトランザクションハッシュをそのトランザクションハンドラに供給しており、そのトランザクションハンドラは「有効」（未処理のトランザクションに関して）または「無効」（受信したブロック全体に関して）の応答を示すが、後者の応答は、マイナーが誤ってまたは敵対的に行動している場合を除き発生してはならないことを除く。マークルツリーおよびルートを生成および処理する上述した技術は、トランザクションをそれらのブロックに結び付ける好ましい暗号化機構である。検証中、および完了時に、ノードコーディネータが全てのセグメントハンドラから結果を取得すると、コーディネータは、ブロック全体のマークルルートを再度計算するが、今回は、そのルートを、マイニングブロックコーディネータによって送信されたブロックヘッダに提供されるルートと比較する。それらがマッチしない場合、ブロックは、無効として破棄される。

【0064】

本明細書で使用される用語は、限定を意図するものではない。本明細書において使用される場合、「有効化」という用語は、そのメモリプールに入れられる未処理のトランザクションを受信したときにトランザクションハンドラが実行する動作のために使用される。上記のように、トランザクションを有効化するために、トランザクションハンドラは、ＵＴＸＯハンドラにクエリを出して、参照されているＵＴＸＯの利用可能性を確認し、（入力の）署名を確認するために署名検証部と会話する。対照的に、「検証」という用語は、ノードコーディネータによって開始されたコンセンサスを同様に実行している他のノードから受信したブロックセグメントのコンテンツを検証する行為のために使用される。トランザクション有効化はまた、「ブロックセグメント検証」（コーディネータおよびセグメントハンドラが他のノードから受信したブロックセグメントデータに対して行う処理）との対比で、コーディネータが（ブロックセグメントを含む）ブロックに対してマイニング動作を開始したことに応答する、「初期トランザクション検証」と見なすこともできる。また、「マイニング」という用語は、「割り当て」と呼ばれることもあり、これは、トランザクションをブロックセグメントに割り当てまたは関連付けるようにセグメントハンドラによって指示されたときにトランザクションハンドラが実行すること、すなわち、セグメントハンドラによるブロックセグメントへのその組み込みに関するトランザクションのトランザクションハンドラによる検証を意味する。上記のように、これを達成するために、トランザクションハンドラは、そのＵＴＸＯハンドラと通信して、既存のＵＴＸＯを「使用」し、新たなＵＴＸＯをブロックセグメントに「割り当てる」。

【0065】

また、「ハンドラ」の概念は、限定を意図するものではない。ハンドラは、本明細書では「コーディネータ」と呼ばれることがあり、ハンドラの基本的な動作または機能は、プロセス、プログラム、インスタンス、実行スレッド、プログラム命令セットなどとして実装することができる。

【0066】

上記は好ましい動作を説明しているが、ハンドラがそのタスクを単数で処理する必要はない。したがって、セグメントハンドラは、ブロックを構成するセグメントの一部または全てを処理することができる。トランザクションハンドラは、特定の、または複数の（さらには全ての）セグメントに属するトランザクションを処理することができる。ＵＴＸＯハンドラは、ＵＴＸＯ空間内の一部または全てのパーティションを処理することができる。ここでの「パーティション」という用語は、セグメントから区別するために便宜上使用されているが、いずれの用語も限定とみなれるべきではない。

【0067】

以下は、好ましい実装における上述したノードコンポーネントに関する追加の詳細を提供する。

【0068】

ノードの調整（コーディネーション）
ノードコーディネータ６０１は、ネットワーク・コンセンサス・アルゴリズムに参加して、ノードがブロックをマイニングするかどうか、および他のどのノードからマイニングされたブロックデータを受信することを予期すべきかを決定する。ノードがブロックをマイニングする場合、ノードコーディネータ６０１は、メッセージを（６０２を介して）ネットワーク内の他のノードコーディネータに送信する。ノードコーディネータ６０１はまた、ブロックをマイニングしているノード内の他のノードコーディネータから（６０３を介して）メッセージを受信する。説明したように、ノードコーディネータ６０１は、（６０５を介して）ノードのセグメントハンドラ６０４に対してメッセージの形で、ブロックセグメントのマイニングを開始することと、他のいずれかのノードからマイニングされたブロックセグメントを受信して有効化するかを通知する。ノードのセグメントハンドラ６０４は、各ブロックセグメントを構成するトランザクションのマークルルートを（６０６を介して）メッセージの形でノードコーディネータ６０１に返す。

【0069】

ノード調整の他の局面は、任意の所与の時点でネットワークにおいてアクティブになっている可能性がある１つ以上のチェーンブランチに対応するノードローカル表現を管理することである。通常、ブロックチェーンは、確定の時点までの単一のブロックシーケンスから構成される。確定は、多くの場合、チェーン内のいくつかの深いブロックに設定されるが、確定する内容とタイミングの決定は、ネットワーク全体のコンセンサスを管理するルールにしたがう。予め確定されるブロックチェーンの部分は、確定前に解決される可能性のある複数のブランチチェーンから構成される。上記のように、例えば、複数のノードが同時にマイニングする場合、それらは、いくつかの共通の祖先ブロックを有する複数のブランチにブロックチェーンをフォークする。ノードコーディネータ６０１は、アクティブなブランチを追跡し、ノードがマイニングしている場合、それらがマイニングしているブランチ、および各リモートマイナーがマイニングしているブランチを、セグメントハンドラ６０４に通知する責を担う。

【0070】

セグメント処理
また説明されるように、セグメントハンドラ６０４は、ブロックセグメンテーション空間の一部を表すいくつかのブロックセグメントの生成および／または有効化を処理する。具体的には、セグメントハンドラは、（６０５を介して）メッセージの形でノードコーディネータ６０１によって指示されたようにブロックセグメントの生成を開始する。マイニングするとき、セグメントハンドラ６０４は、６０７を介して、マイニングされたブロックセグメントデータを、検証される他のノードのセグメントハンドラに送信する。セグメントハンドラ６０４は、（６０８を介して）メッセージの形でマイニングノードのセグメントハンドラからブロックセグメントデータを受信する。トランザクションのマイニングおよび有効化を実行するために、セグメントハンドラ６０４は、また前述したように、関連するトランザクションハンドラのセット６０９と相互作用する。

【0071】

トランザクション処理
トランザクションハンドラ６０９は、メモリプールに追加されてネットワークに伝播されるトランザクションの有効化、マイニングされたブロックに含まれるトランザクションの生成、およびマイニングノードから受信したブロックの一部として含まれるトランザクションの検証を処理する。上記のように、トランザクションセグメンテーション空間の分布は、トランザクションハンドラ６０９とセグメントハンドラ６０４とで同じであってもよく、または異なっていてもよい。例えば、セグメントハンドラ機能によって必要とされる計算リソースは、ごく少数のそのようなハンドラが全てのブロックセグメントを処理するために使用される程度に十分に少なくてもよいのに対して、トランザクションハンドラ機能によって必要とされる計算リソースは、そのような各ハンドラが関連するセグメントハンドラ６０４よりも少ない数のセグメントのトランザクションを管理することが必要となる程度に十分多くなる可能性がある。

【0072】

トランザクションハンドラ機能は、また前述したように、システムにおける他の重要な役割、すなわち、トランザクションアドミッション（「有効化」とも呼ばれる）および伝播を果たす。トランザクションハンドラ６０９は、エッジから直接的にまたはネットワーク内の他のトランザクションハンドラを介して間接的に（６１２を介して）メッセージの形でトランザクションを受信する。トランザクションハンドラ６０９は、受信した全てのトランザクションを有効化し、有効な場合、トランザクションを未処理のトランザクションのプール（そのメモリプール）に保存し、随意にトランザクションをメッセージの形でネットワーク内の他のノードに伝播する（６１３を介して）。このように、トランザクションハンドラ機能は、全てのノードが全ての到来トランザクションおよび関連する到来トランザクションダイジェストを適時に且つ効率的な方法で受信するように、トランザクションデータの伝播を編成する。

【0073】

ＵＴＸＯの処理
好ましくは、ＵＴＸＯは、発信トランザクションのハッシュまたはダイジェストである識別子（ｔｘｉｄ）、および発信トランザクションにおける出力のインデックスによって識別される。ＵＴＸＯはまた、２つの他の情報部分（その識別には使用されない）、すなわち、値および「ロックスクリプト」を有する。一般に、ロックスクリプトは、指示のセットまたは単に出力に関連付けられた公開鍵である。公開鍵は、アドレスまたはウォレットアドレスと呼ばれることもある。ロックスクリプト（例えば、公開鍵）は、値とともにトランザクションの出力において伝達され、通常、ＵＴＸＯ識別情報およびその値とともにＵＴＸＯデータベースに記憶される。したがって、初期トランザクション有効化時にＵＴＸＯハンドラにクエリを出すと、値およびロックスクリプト（公開鍵）の双方を返す。ＵＴＸＯを新たなトランザクションへの入力として使用するために、新たなトランザクション（基本的にはその出力）は、使用されるＵＴＸＯの公開鍵と暗号的にマッチする秘密鍵によって署名される必要がある。この署名は、各トランザクション入力で提供され、一般に「ロック解除スクリプト」と呼ばれる。ロック解除スクリプトは、指示のセットまたは単にデジタル署名とすることができる。したがって、デジタル署名は、トランザクションの出力値を、値の受信者がおそらく対応する秘密鍵（後でロック解除スクリプトの作成に使用される）を有するロックスクリプト（公開鍵）にバインドする。署名検証部は、（ウォレットまたはその暗号化要素のみが秘密鍵を有するため）秘密鍵を有しない。署名検証部は、（ロックスクリプトからの）公開鍵および（ロック解除スクリプトからの）署名を受信し、署名検証部は、公開鍵に対して署名を検証し、それにより、マッチする秘密鍵によって署名が作成されたことを証明する。要約すると、所与のインデックスにおけるトランザクション出力は、ロックスクリプト（公開鍵）および値を有する。トランザクション入力は、発信元のｔｘｉｄ、インデックス、およびロック解除スクリプト（署名）を有する。

【0074】

トランザクションを処理するために、上記のように、トランザクションハンドラは、（６１５および６２０を介して）メッセージによってＵＴＸＯハンドラ６１４のセットと相互作用し、各トランザクションに関連付けられた未使用のトランザクション出力（ＵＴＸＯ）を作成し、クエリを出し、使用し、および割り当てる。各ＵＴＸＯ動作はまた、（６２０を介して）メッセージの形の取り消し要求を用いて逆行することもできる。この可逆性は、トランザクションが全体として完了できなかった場合に、トランザクションハンドラ６０９が首尾よく完了することができたトランザクションの部分を取り消すことを可能にすることから、価値がある。同時並行性を可能にし且つ競合を防止するためにＵＴＸＯデータベースをロックする代わりに、ここでシステムは、競合の検出および部分的に完了したトランザクションのＵＴＸＯ動作の逆行に頼ることが好ましい。この文脈における競合は、これらに限定されるものではないが、（ポリシーが規定するところに応じて）それが存在するかまたは確定される前にＵＴＸＯを使用する試み、他のトランザクションによって既に使用されているＵＴＸＯの使用、またはトランザクションを不完全な状態にする任意の他のＵＴＸＯ動作の失敗を含む。

【0075】

上記のように、各ＵＴＸＯは、有効化するためにトランザクションについて正常に実行される必要がある値およびロックスクリプトを有する。スクリプトは、他のトランザクションへの入力としてＵＴＸＯの使用をロックするために実行される必要がある指示のセットである。通常、スクリプトは、ＵＴＸＯを入力として使用するトランザクションに署名するために使用される必要がある秘密鍵に対応する公開鍵素材を含む。

【0076】

累積するＵＴＸＯの数は大きくなる可能性があることから、ＵＴＸＯ空間はまた、ブロックがトランザクション識別子によってセグメント化されるのと同様の方法でトランザクション識別子によってパーティション化されることが好ましいが、パーティション化空間およびセグメンテーション空間は、独立してそれぞれのニーズに応じて分割されることが好ましい。ＵＴＸＯ処理は、ＵＴＸＯを生成するトランザクションハンドラによって実行されることができるが、ＵＴＸＯの処理は、以下の２つの理由のためにトランザクション処理から分離されることが好ましい：（１）リソース要求が異なるため、および（２）トランザクションハンドラ機能を分離することが、トランザクションおよびＵＴＸＯハンドラがより効率的に実行することを可能にするため。好ましくは、ＵＴＸＯ空間はまた、ノードの集約メモリおよび記憶リソースをより効率的に使用するためにパーティション化される。このセグメンテーションを適用することにより（すなわち、トランザクションセグメンテーション空間を介して）、高度にスケーラブルでタイミングが制約されたソリューションが提供される。

【0077】

署名検証
図６Ａのブロック図の最後の要素は、署名検証部６１７のセットによって提供される署名検証機能である。上記のように、トランザクションは、トランザクションの入力に関連付けられた秘密鍵のセットによって署名されることが好ましい。ノードにおいて最も計算量の多いタスクは、トランザクションの署名を検証することである。そのため、重要な計算リソースは、好ましくは署名検証専用である。各署名検証部６１７は、署名検証負荷の一部をサポートするのに必要な計算リソースを利用することが好ましく、トランザクションハンドラ機能は、（６１８を介して）メッセージを使用して利用可能な署名検証部６１７のセット全体に署名検証負荷を分散させ、有効化されることになるデータを送信し、（６１９を介して）返信としてメッセージの形で肯定応答または否定応答を受信する。一実施形態では、これらの動作は、署名検証をいくつかの他の処理（例えば、トランザクション処理）と組み合わせることによって実行される。他の実施形態では、図示および説明されるように、より高いスケーラビリティを可能にするために、他の要素から分離した署名検証部６１７を有効にすることにより、処理要求に対応する。

【0078】

ブロックの生成、送信、および検証のパイプライン化
図７を参照すると、従来のブロックチェーンベースのシステムは、ブロックの生成（マイニング）、送信、および検証をシリアル化する。そのようなシステムでは、マイナーによってブロックが生成され（７０１）、ブロックの生成が完了すると、ブロックは検証のために他のノードに送信され（７０２）、ノードがブロックの受信を完了すると、それらはブロックの検証を開始する（７０３）。そのようなシリアルベースの処理は、特に前述の動作文脈、すなわち、潜在的にグローバルベースのネットワークにわたってトランザクションメッセージが生成されている場合、非効率的であり、スケーリングしない。

【0079】

例えば、１秒あたり数百万のリアルタイムトランザクションを処理することができるなど、高い性能要件を有するシステムを構築しようとする場合、そのような現在の実装アプローチは、完全に不十分である。このため、本明細書のアプローチでは（および上述したように）、これらの処理ステージは、同時並行性のためにパイプライン化される。したがって、本明細書の技術によれば、マイナーがブロックデータを生成する（７０４）一方で、以前に生成されたブロックデータは、検証のためにノードに送信される（７０５）。検証ノードは、完全なブロックを受信する前に、且つおそらくはマイナーがブロックのマイニングを完了するずっと前に、マイニングされたブロックデータを受信し、ブロックのトランザクションの検証を開始する（７０６）。

【0080】

図５によれば、ブロックの生成、送信、および検証のパイプラインもまた、ブロックの各セグメントごとにインスタンス化され、したがって、ブロックセグメントが並列に動作されることを理解されたい。その結果、並列処理およびパイプライン処理を組み合わせることにより、同時並行性が向上する。

【0081】

ブロック生成、送信、および有効化のストリーミング
図８を参照すると、パイプライン化されたブロックの生成、送信、および検証をサポートするために、ストリーミングされたブロックセグメントの生成、送信、および検証プロセスが、２つのノード、すなわち、マイナーノード８０１と検証ノード８０５との間で示されている。１つの検証ノード８０５が示されているが、上述したように、通常、ネットワーク内の全てのノードは、マイニングされたブロックを検証する。また説明したように、このプロセスはまた、通常、マイナーノード８０１によってマイニングされる他のブロックセグメントの同じプロセスと同時に実行される。上記のように、ネットワーク内で同時に動作する、複数のマイナーノード８０１と、複数のストリーミングされた生成、送信、および有効化プロセスが存在することができる。この例では、永続化のためにセグメントをステージングする責任は、前述のように、セグメントハンドラではなくトランザクションハンドラに関連付けられることに留意されたい。

【0082】

生成
図８に示すように、プロセスは、マイニングノードコーディネータ８０２がネットワーク上のブロックをマイニングするための基準を満たしたときに開始される。一実施形態では、この基準は、それが満たすことをマイナーが証明することができる確率条件（例えば、ある閾値を下回る信頼できるあるいは検証可能な乱数）とすることができる。マイナー選択（リーダー選出）の任意の基準が適用可能である。ノードコーディネータ８０２は、メッセージ８０９を送信して、マイニングノードセグメントハンドラ８０３がブロックセグメントの生成を開始することを要求する。ノードコーディネータ８０２はまた、マイナーノードのセグメントハンドラ８０３からのマイニングされたブロックセグメントを予期するように有効化ノードのコーディネータ８０６に指示するメッセージ８１０を送信する。各マイニングセグメントハンドラ８０３は、トランザクションハンドラ８０４が各々に関連付けられて収集された未処理のトランザクションのプールからブロックへのトランザクションの割り当てを開始することを指示するメッセージ８１１を、関連するトランザクションハンドラ８０４に送信する。トランザクションハンドラ８０４は、（直接的にまたは他のノードのトランザクションハンドラを介して）エッジから受信した未処理のトランザクション（ブロックまたはその任意の祖先に対して以前に割り当てられていなかったトランザクション）を繰り返し検査する。トランザクション検証（上述したトランザクション有効化）のいくつかの局面は、トランザクションが最初に受信されたときに事前に実行されることができることを理解されたい。検証済みのトランザクション割り当てごとに、トランザクションハンドラ８０４は、（１）完全なトランザクションレコード８１３をブロックセグメント８３１に追加し、（２）ダイジェスト（例えば、ハッシュ）を含むメッセージ８１４をストリームの形でセグメントハンドラ８０３に送信する。

【0083】

送信
セグメントハンドラ８０３は、メッセージのストリーム８１４から１つ以上のトランザクションダイジェストを収集し、メッセージのストリーム８１５の形でトランザクションダイジェストを、生成されたセグメントデータの有効化を担当する各有効化ノード８０５におけるセグメントハンドラ８０７に送信する。示されるように、メッセージのストリーム８１４におけるメッセージの数は、メッセージのストリーム８１５におけるメッセージの数とは異なることができるが、双方のストリームにおいて送信されるトランザクションダイジェストの総数は、通常同じである。

【0084】

ノード８０５を有効化する際に、セグメントハンドラ８０７は、メッセージのストリーム８１５を受信し、トランザクションダイジェストを抽出し、１つ以上のメッセージ８１６をトランザクションハンドラ８０８に送信する。メッセージのストリーム８１５および８１６を構成するメッセージの数は、異なることができる。この実施形態では、送信されたメッセージ８１０、メッセージ８３３で終わるメッセージのストリーム８１５、およびメッセージ８２３は、ノード要素からノード要素に直接的にユニキャストまたはマルチキャストで送信され、他のノードの要素を介して間接的に伝播され、またはネットワーク要素を介してルーティングもしくは転送されることができる。データは、集約または分離されて移動することができる。

【0085】

検証
検証トランザクションハンドラ８０８は、トランザクションダイジェストを受信し、（他のノードのトランザクションコーディネータを介して直接）エッジから受信した未処理のトランザクションを検索する。検索が成功すると、それは、トランザクションの割り当てを検証する。検証が成功すると、トランザクションハンドラ８０８は、（１）メッセージ８１８において検証確認をセグメントハンドラ８０７に送信し、（２）完全なトランザクションレコード８１７をブロックセグメント８３２に追加する。

【0086】

ストリーム処理の終了
一実施形態では、ストリーミング生成、送信、および検証プロセスは、マイニングノードコーディネータ８０２が生成停止メッセージ８１９を全てのマイニングセグメントハンドラ８０３に送信すると終了する。このシナリオでは、ノードは、非同期で動作し、実行ラウンド間に明示的な時間境界がないものと仮定される。他の実施形態では、ノードは、同期して動作することができ、プロセスは、特定の時間に到達したときに終了する。

【0087】

プロセスが終了すると、各セグメントハンドラ８０３は、生成停止メッセージ８２０をその関連するトランザクションハンドラ８０４に送信する。各トランザクションハンドラ８０４はまだ進行中の任意のトランザクション割り当てを終了または中止し、セグメントハンドラ８０３に対するメッセージ８２１の形で、ブロックセグメントに含まれる任意の残りの割り当てられたトランザクションとともにマイニングを停止したことを認める。

【0088】

セグメントハンドラ８０３は、任意の未送信のトランザクションハッシュとストリームの終わりの指示とをメッセージ８３３の形で有効化ノードのセグメントハンドラ８０７に送信する。各セグメントハンドラ８０３は、各セグメントのトランザクションハッシュからマークルツリーを計算し、メッセージ８２２においてノードコーディネータ８０２にマークルツリールート（マークルルートまたはＭＲ）を送信する。ノードコーディネータ８０２は、ブロックの全てのセグメントのマークルルートを受信すると、セグメントのマークルルートからブロック全体のマークルツリーの上部を計算し、前のブロックヘッダのハッシュ、そのマイニング証明、およびブロック全体のマークルルート、ならびにその他のデータから構成されるブロックヘッダを生成する。失敗すると、ノードコーディネータ８０２はパージメッセージ８２７を各セグメントハンドラ８０３に送信し、次に、各セグメントハンドラがパージメッセージ８２８をその関連するトランザクションハンドラ８０４に送信し、次いでトランザクションハンドラがブロックセグメントを破棄する。成功すると、ノードコーディネータ８０２は、メッセージ８２３の形でブロックヘッダを全ての有効化ノードコーディネータ８０６に送信する。

【0089】

各検証ノードのセグメントハンドラ８０７がメッセージ８３３の形でストリームの終わりの指示を受信すると、それらは、次に、それらの関連するトランザクションハンドラ８０８に、ストリームの終わりの検証を指示するメッセージ８３４を送信する。各セグメントハンドラ８０７は、その関連するトランザクションコーディネータ８０８から全ての未処理のトランザクション割り当て検証の確認を受信すると、そのセグメントのマークルツリーを計算し、メッセージ８２４における各セグメントのマークルルートを検証ノードコーディネータ８０６に送信する。検証ノードコーディネータが各セグメントのマークルルートを受信すると、ブロックヘッダを生成し、生成されたブロックヘッダがメッセージ８２３の形で受信したブロックヘッダとマッチすることを検証する。ブロックヘッダがマッチしない場合には、パージメッセージ８２５を各有効化セグメントハンドラ８０７に送信し、次に、各検証セグメントハンドラがパージメッセージ８２６をその関連するトランザクションハンドラ８０８に送信し、次いでトランザクションハンドラがブロックセグメントを破棄する。

【0090】

ブロックの確定
上述のように、上述したシステムでは、ブロックは、それが確定されるまで永続化されていない。好ましくは、ブロックは、ノードコーディネータが規定されたコンセンサスアルゴリズムに準拠して確定されるべきだと結論付けるまでは、確定されない。対照的に、好ましくはマイニングの終わりでは、ブロックは永続化されていない。むしろ、マイニング後、ブロックは、（コンセンサスアルゴリズムにしたがって）確定されるまで、またはコンセンサスアルゴリズムの適用に耐えられなかったことから破棄（パージ）されるまで、追跡されるだけである。

【0091】

したがって、上述したように、このアプローチは、ブロックセグメンテーションおよび他の上述した特徴（例えば、トポロジ認識データ伝播、非ブロッキングアーキテクチャ、楽観的同時並行制御、パーティション化、マルチキャストおよびその他の特徴）と組み合わせて、高品質、低レイテンシ、高度に相互接続されたコアネットワーク（メッシュ）を活用することにより、中央のいかなるトランザクションのルーティングまたはスイッチング（例えば、大量のトランザクションのルートを占める必要があるレイヤ７スイッチ）も用いることなく、計算効率の高いトランザクション処理システムを提供する。好ましくは、アーキテクチャは、グローバルＣＤＮネットワークと組み合わせて使用され、グローバルな範囲を提供し、このアプローチは、コアネットワークにおけるコンピューティング要素を発見して相互作用するために、ＣＤＮマッピング技術が（例えば、クライアントおよび他のトランザクションサービスにより）便利に活用されることを有利に可能にする。

【0092】

暗号化サーバのサポート
説明してきたような分散型記録システムの別の局面には、商業用途における使用に必要な、高性能ならびに高レベルな安全性、セキュリティ、および信頼性を可能にする、許可されたネットワーク環境を構築することを伴う。無許可のオープンなインターネットとは異なり、システムの様々な要素は、例えば、公開鍵基盤（ＰＫＩ）に依拠して信頼の鎖（ｃｈａｉｎ ｏｆ ｔｒｕｓｔ）、信頼境界（ｔｒｕｓｔ ｂｏｕｎｄａｒｙ）、セキュアな運用管理フィーチャーを確立し、コンセンサス、リーダー選出、フォーク防止および抑止などの特定の局面を推し進めることが好ましい。

【0093】

上述のように、上述のオーバーレイネットワークベースの設計では、周辺機器、エッジ、およびコア要素は、相互認証済の暗号化接続を介して互いに通信することが好ましい。この環境では、このような接続を確立するために使用される鍵の流出および悪用を防ぐことが望ましい。さらには、やはり上述したように、コアネットワーク内のコンピューティングノードは、通常ブロックを生成する（マイニングする）ノードの真正性を有効化するために用いられる１つ以上の公開鍵／秘密鍵の対を有する。さらには、生成されたブロックを有効化するノードは、通常それらの鍵を使用して、ブロックに署名することによりあるブロックの有効性をエンドースする。通常の動作環境では、公開鍵／秘密鍵の対は乱数シーケンスを作製するためにも使用され、乱数シーケンスは次いでマイナーを選択するために、および／または潜在的にマイナーのサブセットを選択して複数の予め確定されるチェーンを剪定するために使用される。これらの事例の全てにおいて、秘密鍵のあらゆるセキュリティ侵害は、潜在的なセキュリティ上の懸念を生じさせる。その上、（上述してきたような）コンセンサスベースのコアネットワークに関して、最大何らかの数までのセキュリティを侵害されたノードで正確性が保証される。したがって、秘密鍵を保護すること、およびそれらの使用を可能にするデータを検証することは、広範なネットワークセキュリティ侵害に対する多層防御（ｄｅｆｅｎｓｅ－ｉｎ－ｄｅｐｔｈ）および軽減策をもたらす。実際、ウォレットが関与する信頼できるコンピューティング環境では、それらの使用を可能にする秘密鍵を保護すること、およびデータを検証することは（以下で説明するように）、物理的セキュリティ侵害およびネットワークベースのセキュリティ侵害の両方に対する防御の第一線を提供する。鍵のセキュリティ侵害のリスクを軽減するために、セキュアなサーバベースの技術（本明細書では時に「暗号化サーバ（ＣＳ：ｃｒｙｐｔｏｓｅｒｖｅｒ）」と称される）を使用して、分散型記録システムの様々な部分に１つ以上の暗号化サポートサービス（すなわち「暗号化サービス」）を備えることにより、その使用を可能にする秘密鍵およびロジックが周辺、エッジ、およびコアサービス実行環境から切り離されることが好ましい。暗号化サービスは特に秘密鍵を秘匿し、悪用されないよう安全にしておくために用いられる高度なセキュリティプロファイルを提供するように設計される。

【0094】

したがって、一局面では、説明したような暗号化サービスを使用してウォレットの秘密鍵を保護することができる。例えば、トランザクションは、受取人ウォレットが公開鍵とともに金額を支払人ウォレットに提供することで開始する場合がある。支払人ウォレットは秘密鍵を所有していない。代わりに、受取人ウォレットは、暗号化サービスにより維持される秘密鍵に関連付けられる情報を所有することが好ましい。それに応じて、支払人ウォレットは暗号化サービスに、好ましくはセキュア且つ相互認証済の通信を使用して、要求を送信する。要求は、秘密鍵に関連付けられた情報を含むデータを、署名されるトランザクションデータ（または、トランザクションデータのダイジェスト、またはハッシュ）とともに含むことが好ましい。暗号化サービスはトランザクションデータおよび関連付けられた秘密鍵情報を検証し、提供されたデータ（またはその一部）に対して署名を行い、応答として署名を返す。署名されたトランザクションは、記録システムに追加される。代表的な使用例では、受取人ウォレットから支払人ウォレットに送信されたデータは、限定なく、レガシーＩＳＯ－８５８３メッセージ、新しいまたは既存の他の決済またはトランザクションＡＰＩメッセージ、パスコード、ＰＩＮなどを含む任意のデータであることができる。このアプローチの利点は、支払人ウォレットへのインターフェースが公開であり、且つ進化することができる一方で、支払人ウォレットと暗号化サービスとの間のインターフェースは秘密であり、且つ安定的なままであり、これにより攻撃表面としての脆弱性を大幅に低減できることである。暗号化サービスを使用することのさらなる利点は、これにより支払人ウォレットに与えられるデータを使用して台帳にポストされるトランザクションを構築することが可能になることである。その上、元々のデータおよび暗号化サービスに送信される構築されたトランザクションの両方を用いて、本アプローチは元々のデータの検証、ならびに構築されたトランザクションがその正しい表現であることの検証を（暗号化サービスにより）可能にする。

【0095】

上述の構成には多くの変形例がある。例えば、暗号化サービスは、ネットワークを介してアクセス可能である場合があるが、同一のマシンまたはデバイス上で、セキュアエンクレーブなどの、切り離されて保護された（おそらくは暗号化されて）メモリ空間に存在していてもよい。さらには、単一の暗号化サービスが、または暗号化サービスの小型のセットとして、複数の（おそらくは多数の）ウォレットの鍵を保護するために使用することができる。

【0096】

暗号化サービスは、ブロック生成（マイニング）および有効化のために使用される秘密鍵を保護するためにも使用される場合がある。この局面では、ブロック生成および有効化アクティビティは、公開鍵基盤（ＰＫＩ）で強化され、それによりブロックは、その内容により単に有効化されるだけではなく、マイニングノードの真正性によっても有効化される。したがって、説明してきたように、例えばマイナーがブロック（またはその一部）を生成していると想定する。述べたように、通常ブロックのヘッダは、ブロックが依存する先行ブロックのハッシュなどの様々な情報を含む。ブロックのヘッダに含まれる通常の情報に加え、システムはブロックをマイニングするノードがそのブロックに署名することを要求することができる。そのような文脈では、そのような目的に用いられる１つ以上の秘密鍵がセキュアなままであることが重要である。この目的のために、暗号化サービスは、秘密鍵の流出および悪用のリスクを、このような鍵をアプリケーションおよびサービスロジックから切り離しておくことにより、軽減する。この文脈では、マイナーによって検証され署名されるものは、ブロック属性、ブロックに含まれる他のあらゆるデータ、生成時点のシステムの状態、以前マイニングされたブロックに含まれる署名など、これらに限定されるものではないが、任意のものであり得る。

【0097】

好ましくは、信頼できるコンピューティング環境を用いて暗号化サービスを提供する。一実装の実施形態では、暗号化サービス（または暗号化サーバ）は、通常、トランザクションネットワークに関連付けられる鍵管理システムとシームレスに相互運用する、各トランザクションネットワークサーバ（例えばウォレットサービス多ウォレットプロセッサ）に付属する、ネットワーク化セキュリティ機器を備える。

【0098】

代表的な暗号化サービスは、米国特許第９，６４７，８３５号明細書に記載されているようなものであり、その開示は、参照により本明細書に組み込まれる。そこで説明されるように、代表的なサーバ側（暗号化サーバ（ＣＳ））プロセスは、物理的なセキュリティを有しオーバーレイネットワークエッジサーバの実行環境とは異なる実行環境で実行される。暗号化サーバデーモンは、負荷をレポートするネットワークからの入来要求を管理すること、ならびにログおよび関連情報を生成する役目を果たす。この信頼できるコンピューティング環境により保護されるシークレット（例えば、秘密鍵）は、例えばデーモンだけがアクセス可能な信頼できるハードウェアに記憶されることにより、セキュアに維持される。このタイプの信頼できるコンピューティング環境は、Ｉｎｔｅｌ（Ｒ）ＳＧＸ（Ｓｏｆｔｗａｒｅ Ｇｕａｒｄ Ｅｘｔｅｎｓｉｏｎｓ）によりサポートされるもの、または付属の好ましくはプログラム可能なハードウェアセキュリティモジュール（「ＨＳＭ」または、エンクレーブ）などのＨＳＭを活用することができる。代表的な実施形態では、暗号化サービスはケージ化されたネットワークセットアップ内で、エンクレーブにより保護された秘密鍵（または他のシークレット）を用いて実行する。エンクレーブは、通常、静的にコンパイルされ、ＢＩＯＳおよびカーネルのサポートを必要とし、エンクレーブは同じ場所に配置されていない（ダイ上にない）いかなるハードウェアまたはソフトウェアとも対話しない、および対話できないことが好ましい。上述のコンポーネントが好ましいが、あらゆるメモリ暗号化の信頼できるコンピューティング要素をこれらの目的に使用することができる。

【0099】

暗号化サービスは、それぞれが多数のトランザクションを扱う数百または数千に至る暗号化サーバを含むネットワークベースのサービスを含む場合がある。システムのコンピューティングノードは、説明したような信頼できるコンピューティング環境に関連付けられていることが好ましい。より一般的には、コンポーネント自身のいずれもが信頼されない、または信頼できるコンポーネントのセットが少ない（説明したような）動作シナリオにおいても、セキュアな（信頼できる）サービスが、コンポーネント上に構築される。特に、説明したように、ブロックチェーンネットワークのコンピューティングノードは、互いを信頼する必要はなく、一般にウォレットは、台帳が有効であること、およびトランザクションがその台帳上にあることの暗号法的証明を必要とする限りは、台帳を信頼しない。台帳上のトランザクションは、トランザクション入力ごとに個々に署名され、したがって自己検証可能であることが好ましい。換言すると、台帳サービスを提供するコンピューティングノードを必ずしも信頼することなく、台帳を信頼することができる。

【0100】

ブロックチェーンコンセンサスプロセスはマイニングに依存しており、上記のように、マイニングは通常ブロックチェーンにおける前のブロックを参照するヘッダを有する順序付けられたトランザクションのブロックを生成する行為である。

【0101】

説明したように、分散型記録システムは、コンピューティングノードのセットを含む、許可された、高度にセキュアなコンピューティング環境を提供する。マイニングに関して、マイニング証明は、ノードがブロックまたはその一部の正当なマイナーであることを数学的に証明する、コンピューティングノードによって提示されるデータである。データは、ブロックチェーンが適切に構築されていること（すなわち、信頼）が自己検証可能であるように、ブロックヘッダに記録されることが好ましい。1つのアプローチによれば、何らかの利用可能な信頼できる乱数源を用いてマイニング証明が与えられることが好ましい。このようなアプローチでは、ノードは、真の乱数を生成して所望の性質を発揮するマイニング証明の作製を容易にするために、メモリが暗号化された信頼できるコンピューティング要素を使用することが好ましい。

【0102】

以下は本明細書で使用される用語の用語解説である。

【0103】

ブロックチェーンは、追加される一方の、不変なデータブロックのチェーンであり、トランザクションがブロック内に記録されて存在すること、およびブロックがチェーン内に存在することは、暗号化ハッシュにより検証可能である。ブロックは、トランザクションの集合である。ブロックは、自身を前のブロックにリンさせる暗号化ハッシュを含み、チェーンを形成する。複数のブロックが前のブロックにリンクされる可能性があるが、前のブロックにリンクすることができる確定されたブロックは１つだけである。

【0104】

マーチャント（ｍｅｒｃｈａｎｔ）は、決済のために商品またはサービスの取引を実行するエンティティである。マーチャントは、加盟店銀行により管理される銀行口座を有し、通常有効な決済要求を生成する役割を果たす販売時点管理端末（または他のレガシー基盤）を維持している。より一般的には、販売時点管理端末は、決済要求を生成するマーチャント接続モジュール（ＣＭ）のタイプのものである。

【0105】

ウォレットは、秘密鍵－公開鍵の対、および未使用のトランザクション出力への参照の集合であり、それらは「記憶された値」であって、トランザクションを生成するために使用される。「ウォレットサービス」は、通常、ウォレットの集合をセキュアに維持するソフトウェアエンティティであり、外部エンティティと、ブロックチェーンをサポートして対応する応答を処理するコンピューティングノードのコアネットワークとの間で要求をプロキシする。

【0106】

ウォレットサービスは、多ウォレットプロセッサ（ＷＰ）または等価な処理機能を利用することができる。

【0107】

上述のように、未使用のトランザクション出力（ＵＴＸＯ）は、いくつかの値を含みアドレスに関連付けられた、確定されたトランザクションからの出力である。ＵＸＴＯは、入力（使用済）として、関連付けられた秘密鍵を保持するウォレットにより作製されたトランザクションに渡すことができる。ＵＸＴＯを使用することができるのは、一回だけである。

【0108】

アクワイアラ（ａｃｑｕｉｒｅｒ）は、銀行口座が保持される機関である。アクワイアラは、通常、決済要求を認可する役目を果たすレガシー基盤を運用する。この基盤は、時にアクワイアラまたはオペレータのための接続モジュールと称される。

【0109】

ビジネスサーバは、クリアリング、オペレータおよびマーチャント銀行処理、企業コンプライアンスなど、１つ以上のサービスを提供する、決済ネットワークの外部のサービスである。

【0110】

台帳サービス（時に「１つ以上の台帳サービス（ｌｅｄｇｅｒ ｓｅｒｖｉｃｅｓ）」とも称される）は、トランザクションを処理し、コア台帳を維持する分散型システムである。コア台帳は、本明細書において説明されるブロックチェーン技術を利用して台帳サービスにより維持される記録システムである。コア台帳は、トランザクションを処理してブロックチェーンを作製する分散型システムである。

【0111】

決済ネットワークは、ウォレットサービスとブロックチェーンコア台帳（台帳サービス）を組み合わせたネットワークである。ウォレットサービスは、クライアントトランザクションを受信し、トランザクションをウォレットプロセッサ（例えば、ＷＰ）にルーティングし、必要な決済ロジックを適用し、次いで有効なトランザクションを台帳サービスに転送する。すると、台帳サービスがウォレットサービスからトランザクションを受信し、それらを有効化、処理し、ブロックチェーンベースの台帳に記録する。元々のレガシートランザクションおよびそれに対応する台帳サービス由来のブロックチェーントランザクションから成る、処理済みのトランザクションは、長期的な存続性のためにストレージサービスに記憶することができる。ストレージシステムは、履歴的なクエリに応答すること、および災害時復旧用のバックアップを提供することのために使用することができる。決済ネットワークは、管理トラフィックを扱うためのインターフェースを提供するために、データ連携サービスを含む場合もある。顧客のトランザクションは、ウォレットサービスを介してシステムに入るが、管理上の要求（ウォレット更新、データセンタ更新、履歴的クエリなど）は、それらを正しいサービスに転送する前に要求を有効化するデータ連携サービスを介してシステムに入る。データ連携サービスは、ＲＥＳＴｆｕｌなアプリケーションプログラミングインターフェース（ＡＰＩ）エンドポイントのセットを公開し、結果として、ＴＬＳ相互認証済のＲＥＳＴベースのＨＴＴＰ要求を作製し、ＪＳＯＮにより表現されるデータを送信することができる任意のクライアントをサポートすることが好ましい。

【0112】

上述の用語を参照して、図１１は、オーバーレイネットワークエッジサーバ１１００が、マーチャントコネクタ（ＭＥＲ）１１０４、または管理サーバ１１０６のいずれかから、決済ネットワークコア１１０２に入る要求のためのエントリポイントとして機能する代表的なシステムの別の図である。随意的に、エッジは、決済ネットワークコア１１０２からアクワイアラ／オペレータベースのコネクタ（ＯＰＲ）１１０８に送信される要求のためのエントリポイントとして機能する。前述のように、性能上の利点の中でもとりわけ、オーバーレイネットワークは、ルーティングの最適化、攻撃に対するレジリエンス、レート制限、および要求が決済ネットワークコアノードに転送される前にクライアント認証を提供することを行う。このようにコアノードを隔離することによって、オーバーレイネットワークは様々な攻撃に対するレジリエンス、ならびに様々なタイプのローカル化されたインターネットの問題に対する軽減策をもたらす。描かれているように、オーバーレイネットワークエッジは決済ネットワークコアを実質的に取り囲んでおり、他のコンポーネント（マーチャントコネクタなど）はそこを通って接続されて決済ネットワークコアサービスに達するようになっている。エッジネットワークのスケールが大きいため、決済ネットワークはエッジを使用して適当な決済ネットワークコアノード同士のトラフィックをバランスさせ、作業負荷に応じて線形にスケーリングすることが可能である。

【0113】

エッジは、インターネットスケールの攻撃からの保護を与え、非認証済みの要求が決済ネットワークコアに到達するのをブロックし、相互認証要求を満足することに失敗した接続をブロックする。エッジは、ＳＹＮフラッドおよびＵＤＰフラッドなどの非ＨＴＴＰベースのＤＤｏＳトラフィックに対する保護も行う。加えて、エッジはパフォーマンスおよび信頼性を向上させる。ＴＬＳおよびＴＣＰ接続は、パフォーマンスを向上するためにマーチャントコネクタの近くで終了することが好ましい。エッジから決済ネットワークコアへの接続プールは、ＴＬＳネゴシエーションのオーバヘッドを低減する。各エッジノードは任意の決済ネットワークコアノードと通信することができ、場所固有の要求を適当な場所にルーティングすることが好ましい。この最適化されたルーティングは、密集しているかメンテナンスを受けている決済ネットワークコアの場所を回避することが好ましい。管理サーバおよびマーチャントコネクタは、アクワイアラコネクタと同様、同一のプロトコルおよび方法を使用してエッジに接続することが好ましい。決済ネットワークコアサービスは、エッジにクライアントとして接続し、アクワイアラコネクタサーバにルーティングされる場合もある。

【0114】

決済ネットワークコアへの全てのＨＴＴＰＳ要求は、まず、ＴＬＳが終了しクライアントの識別情報が検証されているエッジに送信されることが好ましい。マーチャントＭＥＲおよび管理サーバのクライアントは、設定されたドメイン名を使用して決済ネットワークコアに接続することが好ましい。

【0115】

以下のセクションでは、クライアントと、エッジと、決済ネットワークコアとの間の代表的な接続フローを詳細に説明する。

【0116】

マーチャントコネクタおよびその下流コンポーネント（例えば、ＰＯＳ端末およびカード）が物理的且つ電子的にセキュアであることが好ましい。図１２に描かれているように、マーチャントコネクタ１２００は、（管理されたホスト名に対する）ＤＮＳルックアップの解決によりオーバーレイネットワークエッジ１２０２に結合し、それにより、エッジサーバに対応する１つ以上のエッジＩＰアドレスが得られる。これらのサーバは、インターネットトポロジの観点からマーチャントコネクタ１２００に近いことが好ましく、インターネット上でポート４４３を用いる標準の相互認証済のＴＬＳ暗号化ＨＴＴＰコールを使用する。エッジ１２０２から決済ネットワークコア１２０４まで、オーバーレイネットワークは接続フローを制御し、それらのプライバシおよび真正性に責任を負うことが好ましい。エッジ１２０２は、複数のＩＳＰおよび地理的場所にわたって非常に多岐に展開されることが好ましいが、通常決済ネットワークコア１２０４は、小規模な地理的スケールで（例えば、インターネットを介してエッジ１２０２と通信する高度にセキュアな場所に）展開される。エッジとコアとの間のトラフィックは、暗号化され、認証され、認可されることが好ましい。特に、トランジットでは全てのメッセージがＴＬＳベースの相互認証済の接続を使用して暗号化されることが好ましい。描かれているように、メッセージ認証ドメインは、セキュリティ侵害された中間者（ＭＩＴＭ：ｍａｎ－ｉｎ－ｔｈｅ－ｍｉｄｄｌｅ）要素に対してメッセージを偽造から保護するべく、エンドツーエンドであることが好ましい。これは、決済ネットワークコアが受信するメッセージが、いかなる決済ネットワークコアシステムまたは人物によっても署名されたことがない鍵によって署名されているものとして検証可能であることを保証する。対応するアサーションが、やはりマーチャントコネクタが決済ネットワークコアから受信する全てのメッセージのために行われることが好ましい。

【0117】

オーバーレイネットワークエッジは、決済ネットワークコア（クライアントとして機能している）をアクワイアラ／オペレータＯＰＲ１１０８（図１１）に結合するために、または管理サーバ１１０６を決済ネットワークコアに結合するために使用されることが好ましい。

【0118】

使用例
上記は、例えば（これに限定されるものではないが）決済ネットワークにおいて使用するための高性能コア分散型台帳およびトランザクションファブリックについて説明している。トランザクションは、ソースの値を宛先に移動するプリミティブに限定されず、むしろ、値または情報の変形、変換または転送を伴う任意の処理に限定される。性能コアは、限定されるものではないが、金融システムへの高性能トランザクション処理を含む無数の使用例をサポートするための基盤を提供する。

【0119】

本明細書において使用される場合、処理時間は、動作要求（例えば、金融動作要求）が受信されてから応答が利用可能になるまでの経過時間として定義される。特定の動作は、台帳において複数のトランザクションを必要とすることができる。必要な全てのトランザクションが台帳に安全に記憶され、関連する全てのビジネスロジックが実行された場合、動作は完全に処理されたと見なされる。好ましくは、処理時間は、それよりも短くない場合（例えば、サブ秒）、数秒程度である。この方法で処理時間を維持することに加えて、コアネットワークは、大量の動作をサポートする。動作スループットは、コアネットワークによって動作が処理される速度として定義される。これは限定されるものではないが、望ましいスループットは、１秒あたり最大１０^６（以上）の動作とすることができる。

【0120】

一実施形態では、上述したアーキテクチャは、分散型台帳、すなわち、金融メッセージ台帳を提供する。台帳は、前述のブロックチェーン技術によって保護されたトランザクションの不滅のログを提供する。この文脈において使用される場合、ネットワークは、取得者（ＡＣＱ）および／または発行者（ＩＳＳ）への要求およびそれらからの応答を転送する既存の金融取引システムとインターフェース接続する機能を含む。代替の使用例は、管理値台帳であり、これは、管理された信用枠（または借方）に対するトランザクションの処理を可能にする。この使用例は、ＡＣＱ／ＩＳＳが、ＡＣＱ／ＩＳＳに連絡することなく後で貸方に記入／借方に記入されるネットワーク上のアカウント残高をプロビジョニングすることを可能にする。管理されたクレジットラインを超えるトランザクションは、ＡＣＱ／ＩＳＳにクエリを送信して承認を要求するためのフォールバックをトリガすることができる。典型的な使用では、トランザクションフローは、以下のとおりである。メッセージは、サイズが約１ＫＢと仮定される。そのメッセージは、エッジによって受信され、コアブロックチェーンネットワークにわたって（そこから）配信される。トランザクションが確定した後（およびブロックチェーン受信が受信されると）、エッジから応答が送信される。全体として、最大往復時間は、好ましくは２秒以下のオーダーである。さらに、決済ネットワークは、処理された全てのトランザクションについて追加の１ＫＢメッセージが決済のために決済ネットワークから送信される１日の終わりのバッチ決済プロセスを処理することができる。これらのバッチ処理されたトランザクションは、数時間以内に処理されてログに記録されることが予期される。

【0121】

トランザクションを高速且つ低レイテンシで処理する必要がある任意の他の使用例は、このアーキテクチャから恩恵を受けることができる。ロイヤルティポイントの管理は、非金銭的用途の１つの非限定的な例である。

【0122】

本明細書のアーキテクチャもまた非常に安全である。暗号化、認証、デジタル署名およびその他の技術が使用され、顧客のプライバシおよびデータの整合性を保証する。

【0123】

本明細書の技術は、データセキュリティを全て犠牲にすることなく、（処理されたトランザクションの数に関して）高性能および非常に低いレイテンシを示すグローバルな記録システムを提供する。

【0124】

本明細書の管理対象ネットワークは、非常に安全な許可ネットワークである。したがって、トランザクションの収集およびブロックの構築時間は、ネットワーク全体にブロックを伝播するのにかかる時間近くまで低減される。本明細書のアプローチは、ネットワークのレイテンシがインターネット上の任意のリモート位置間で一般に１秒未満であるという事実を利用しており、さらに、これらのレイテンシは、前述した方法で高度に分散されたエッジ周辺および分散性の低いコアを使用することによってさらに短縮される。

【0125】

説明されているアーキテクチャは、高性能であり、既知のブロックチェーンネットワーク環境に存在する多くの問題、すなわち、ネットワークレイテンシ、ネットワーク使用率、確認深度、クロックスキュー、トポロジ的ボトルネックおよびその他の要因を解消する。ソリューションを容易にするために、上記のように、コアネットワーク自体は、良好な地理的およびトポロジ的近接性を有することが好ましい。コンセンサスプロトコル（ブロックチェーンネットワークにおいて使用されるプロトコルなど）は、大容量のメッセージングに依存することが多いため、これは望ましいことである。これは、ブロックの伝播時間がシステムの応答時間要件に対して適時に留まることを保証するため、好ましくは、使用されるコンセンサスプロトコルに応じて、コアネットワークは、低いネットワークレイテンシおよび高い相互接続性を有する。オーバーレイの安全なエッジネットワークを活用して、非常に安全で高性能な完全にグローバルな決済ネットワークを確保します。

【0126】

ブロックチェーンシステムは、確認の概念を含む。トランザクションが確認され、ブロックチェーンのブロックに追加されると、１つの確認があると見なされる。ブロックチェーンに追加される後続の各ブロックは、そのトランザクションの確認レベルを上げる。トランザクションの確認が多いほど、トランザクションをブロックチェーンから削除することが困難になる。ほとんどのブロックチェーンシステムは、トランザクションが確定されて永続的であると見なされるまで、特定の数の確認を待機する規則を採用しており、これは、「確認深度」と呼ばれる。好ましくは、本明細書のソリューションは、構成可能または可変の確認深度を利用して、トランザクションの回復力要件をサポートする。

【0127】

コア内のコンピューティングノードは、好ましくはタイムサーバを使用して時間同期される。

【0128】

コアネットワークは、非ブロッキングフルメッシュ相互接続トポロジとして構成されることができる。１つの好ましいアプローチは、コアネットワークを高回復力の部分メッシュ相互接続トポロジとして実装する。しかしながら、（ネットワークの停止および攻撃に対する）回復力とブロック伝播時間のバランスをとるために、前述したように、効率的なトポロジ認識データ伝播プロトコルが実装されることが好ましい。プロトコルは、編成がネットワークレイヤにおいて行われるマルチキャストプロトコルに基づいて構築されることが好ましい。

【0129】

本明細書において使用される場合、ノードは、ネットワーク上のコンピューティングの高（上位）レベルユニットである。通常、ノードは、ノードの作業負荷を処理する１つ以上の物理マシン（サーバ）から構成される。好ましくは、ノードの実装は、他のノードから抽象化され、そのような他のノードに対して、各ピアノードは、ネットワーク上で単一のエンティティとして見える。トランザクションレート（例えば、１秒あたり１００万トランザクション）をサポートするために、ノードは、複数の物理マシンに構成されることが好ましい。上記のように、好ましくは、ノードはまた、ミリ秒未満の正確なタイムスタンプを生成するために使用されるタイムサーバも有する。さらに、ノードは、コンセンサスに必要な署名およびエントロピを生成するために使用される暗号化エンジンおよび乱数ジェネレータ（ＲＮＧ）サーバを含む。最後に、ノードは、到来トランザクションを処理し且つ上述した方法でブロックチェーンにそれらを追加するトランザクション処理サーバを含む。

【0130】

本明細書で説明した許可ベースのアプローチでは、ノードは、マイニング証明を提供することにより、それ自体がマイナーであることを証明する。マイニング証明は、ノードがブロック（またはそのセグメント）の正当なマイナーであることを数学的に証明するノードによって提示されるデータである。証明は、適切なブロックチェーンの構築（すなわち、信頼）が自己検証可能であるように、ブロックヘッダに記録される。限定を意図するものではないが、分散型検証可能ランダム機能（ＤＶＲＦ）が使用され、マイニング証明を容易にすることができる。代替のアプローチは、ハードウェアで生成された信頼できる乱数の使用を含む。

【0131】

実現技術
上記のように、本開示の技術は、コンテンツ配信ネットワーク（ＣＤＮ）などのオーバーレイネットワークの文脈内で実装されることができるが、これは限定ではない。図９に示すようなこの種の既知のシステムでは、分散型コンピュータシステム１００は、コンテンツ配信ネットワーク（ＣＤＮ）として構成され、インターネットの周りに分散された１組のマシン１０２ａ－ｎを有すると仮定される。通常、ほとんどのマシンは、インターネットのエッジの近く、すなわち、エンドユーザアクセスネットワークまたはその近くにあるサーバである。ネットワーク動作コマンドセンタ（ＮＯＣＣ）１０４は、システム内の様々なマシンの動作を管理する。ウェブサイト１０６などのサードパーティサイトは、コンテンツ（例えば、ＨＴＭＬ、埋め込みページオブジェクト、ストリーミングメディア、ソフトウェアダウンロードなど）の配信を、分散型コンピュータシステム１００、特に「エッジ」サーバにオフロードする。通常、コンテンツプロバイダは、コンテンツプロバイダのドメインまたはサブドメインをサービスプロバイダの権限のあるドメイン名サービスによって管理されるドメインに指定すると、エイリアスによって（例えば、ＤＮＳ ＣＮＡＭＥによって）それらのコンテンツ配信をオフロードする。コンテンツを希望するエンドユーザは、そのコンテンツをより確実に且つ効率的に取得するために分散型コンピュータシステムに誘導される。詳細は示していないが、分散型コンピュータシステムはまた、エッジサーバから使用状況やその他のデータを収集し、そのデータを領域または領域セットにわたって集約し、監視、ロギング、アラート、請求、管理およびその他の運用および管理機能を容易にするために他のバックエンドシステム１１０、１１２、１１４および１１６にそのデータを渡す分散型データ収集システム１０８などの他のインフラストラクチャを含むこともできる。分散型ネットワークエージェント１１８は、ネットワークならびにサーバの負荷を監視し、ネットワーク、トラフィックおよび負荷データを、ＣＤＮによって管理されるコンテンツドメインについて信頼できるＤＮＳクエリ処理機構１１５に提供する。分散型データ伝送機構１２０が使用され、制御情報（例えば、負荷バランシングを容易にするためにコンテンツを管理するためのメタデータなど）をエッジサーバに配信することができる。

【0132】

図１０に示すように、所与のマシン２００は、１つ以上のアプリケーション２０６ａ－ｎをサポートするオペレーティングシステムカーネル（Ｌｉｎｕｘまたはバリアントなど）２０４を実行するコモディティハードウェア（例えば、インテルペンティアムプロセッサ）２０２を備える。例えば、コンテンツ配信サービスを容易にするために、所与のマシンは、通常、ＨＴＴＰプロキシ２０７（「グローバルホスト」プロセスと呼ばれることもある）、ネームサーバ２０８、ローカル監視プロセス２１０、分散型データ収集プロセス２１２などのアプリケーションのセットを実行する。ストリーミングメディアの場合、マシンは、通常、サポートされるメディア形式によって要求される１つ以上のメディアサーバを含む。

【0133】

ＣＤＮエッジサーバは、好ましくは構成システムを使用してエッジサーバに配信される構成ファイルを使用して、好ましくはドメイン固有で顧客固有ベースで、１つ以上の拡張コンテンツ配信特徴を提供するように構成される。所与の構成ファイルは、好ましくはＸＭＬベースであり、１つ以上の高度なコンテンツ処理特徴を容易にするコンテンツ処理ルールおよびディレクティブのセットを含む。構成ファイルは、データ転送機構を介してＣＤＮエッジサーバに配信されることができる。米国特許第７，１１１，０５７号明細書は、エッジサーバのコンテンツ制御情報を配信および管理するための有用なインフラストラクチャを示しており、このおよび他のエッジサーバ制御情報は、ＣＤＮサービスプロバイダ自体、または（エクストラネットなどを介して）発信元サーバを動作させるコンテンツプロバイダの顧客によってプロビジョニングされることができる。

【0134】

ＣＤＮは、米国特許第７，４７２，１７８号明細書に記載されているような記憶サブシステムを含むことができ、その開示は、参照により本明細書に組み込まれる。

【0135】

ＣＤＮは、サーバキャッシュ階層を動作させて、顧客コンテンツの中間キャッシングを提供し、そのようなキャッシュ階層サブシステムの１つは、米国特許第７，３７６，７１６号明細書に記載されており、その開示は、参照により本明細書に組み込まれる。

【0136】

ＣＤＮは、米国特許出願公開第２００４００９３４１９号明細書に記載されている方法で、クライアントブラウザ、エッジサーバおよび顧客発信元サーバ間で安全なコンテンツ配信を提供することができる。そこで説明されているアプローチは、ＳＳＬで保護されたエッジネットワークと呼ばれることもある。一般的な運用シナリオでは、安全なコンテンツ配信は、一方ではクライアントとエッジサーバプロセスとの間、他方ではエッジサーバプロセスと発信元サーバプロセスとの間でＳＳＬベースのリンクを行使する。これは、ＳＳＬで保護されたウェブページおよび／またはそのコンポーネントを、エッジサーバを介して配信されることを可能にする。セキュリティを強化するために、サービスプロバイダは、エッジサーバに関連する追加のセキュリティを提供することができる。これは、セキュリティカメラによって監視されるロックされたケージに配置されたエッジサーバを備える安全なエッジ領域の動作と、鍵管理サービスの提供などを含むことができる。ここでの一実施形態では、ウォレットサービスは、ＳＳＬで保護されたエッジネットワークの前または後に配置されることができる。

【0137】

一般的な動作では、コンテンツプロバイダは、ＣＤＮによって提供したいコンテンツプロバイダのドメインまたはサブドメインを識別する。ＣＤＮサービスプロバイダは、コンテンツプロバイダドメインをエッジネットワーク（ＣＤＮ）ホスト名に（例えば、正規名またはＣＮＡＭＥを介して）関連付け、そして、ＣＤＮプロバイダは、そのエッジネットワークホスト名をコンテンツプロバイダに提供する。コンテンツプロバイダのドメインまたはサブドメインへのＤＮＳクエリがコンテンツプロバイダのドメイン名サーバにおいて受信されると、それらのサーバは、エッジネットワークのホスト名を返すことによって応答する。エッジネットワークのホスト名は、ＣＤＮを指し、そのエッジネットワークのホスト名は、その後にＣＤＮネームサービスを介して解決される。そのために、ＣＤＮネームサービスは、１つ以上のＩＰアドレスを返す。次に、要求元のクライアントブラウザは、ＩＰアドレスに関連付けられたエッジサーバに対して（例えば、ＨＴＴＰまたはＨＴＴＰＳを介して）コンテンツ要求を行う。要求は、発信元のコンテンツプロバイダのドメインまたはサブドメインを含むホストヘッダを含む。ホストヘッダを有する要求を受信すると、エッジサーバは、その構成ファイルを確認して、要求されたコンテンツドメインまたはサブドメインが実際にＣＤＮによって処理されているかどうかを判定する。その場合、エッジサーバは、構成において指定されるように、そのドメインまたはサブドメインのコンテンツ処理ルールおよびディレクティブを適用する。これらのコンテンツ処理ルールおよびディレクティブは、ＸＭＬベースの「メタデータ」構成ファイル内に配置されることができる。

【0138】

上述したクライアントからエッジサーバへのマッピング技術は、ウォレットまたはウォレットサービス（「クライアント」）をエッジサーバに関連付けるために使用されることができる。典型的な使用例では、そのウォレットまたはウォレットサービスから開始された、またはそれに関連付けられたトランザクションは、その後、本明細書で説明するようなさらなる処理のためにエッジサーバを通過してコアに進む。上記のように、ウォレットまたはウォレットサービス（またはその一部）はまた、ウォレット要求がエッジを介してウォレットまたはウォレットサービスにわたり、コアに進むように、エッジの内側に存在することもある。トランザクション処理の一部は、エッジサーバにおいて実行されることができる。

【0139】

上述した各プロセスは、好ましくは、専用マシンとして、１つ以上のプロセッサにおいて実行可能なプログラム命令のセットとしてコンピュータソフトウェアに実装される。

【0140】

本明細書の主題が提供される代表的なマシンは、ＬｉｎｕｘまたはＬｉｎｕｘバリアントオペレーティングシステムを実行するインテルハードウェアプロセッサベースのコンピュータと、説明した機能を実行するための１つ以上のアプリケーションである。上述したプロセスの１つ以上は、説明された機能を実行するためのコンピュータプログラムとして、すなわち、コンピュータ命令のセットとして実装される。

【0141】

上記は、本発明の特定の実施形態によって実行される特定の動作の順序を説明しているが、代替の実施形態は、異なる順序で動作を実行し、特定の動作を組み合わせ、特定の動作を重複することができるなどのため、そのような順序は例示であることを理解されたい。本明細書における所与の実施形態への言及は、記載された実施形態が特定の特徴、構造、または特性を含むことができることを示すが、全ての実施形態は、必ずしも特定の特徴、構造、または特性を含まなくてもよい。

【0142】

開示された主題は、方法またはプロセスの文脈において説明されてきたが、主題はまた、本明細書の動作を実行するための装置にも関する。この装置は、必要な目的のために特別に構築された特定のマシンであってもよく、またはコンピュータに記憶されたコンピュータプログラムによって選択的にアクティブ化または再構成されるコンピュータを備えてもよい。そのようなコンピュータプログラムは、これらに限定されるものではないが、光ディスク、ＣＤ－ＲＯＭ、および光磁気ディスクを含む任意の種類のディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気もしくは光カード、または電子命令を記憶するのに適した任意の種類の媒体などの、それぞれがコンピュータシステムバスに接続されているコンピュータ可読記憶媒体に記憶されることができる。本発明の所与の実装は、Ｌｉｎｕｘなどのオペレーティングシステムを実行する標準のインテルハードウェアプラットフォーム上のＤＮＳ準拠ネームサーバ（例えば、ＢＩＮＤ）と連動して実行される所与のプログラミング言語で書かれたソフトウェアである。機能は、ネームサーバコードに組み込まれてもよく、またはそのコードの補助として実行されてもよい。本明細書における技術を実装するマシンは、プロセッサ、上述した方法を実行するためにプロセッサによって実行される命令を保持するコンピュータメモリを備える。

【0143】

システムの所与のコンポーネントは別個に説明されているが、当業者は、機能のいくつかが所与の命令、プログラムシーケンス、コード部分などにおいて組み合わされるまたは共有されることができることを理解するであろう。

【0144】

システムの所与のコンポーネントは別個に説明されているが、当業者は、機能のいくつかが所与の命令、プログラムシーケンス、コード部分などにおいて組み合わされるまたは共有されることができることを理解するであろう。本明細書で説明するアプリケーションまたは機能は、他のアプリケーションへのフックの提供、プラグインとしての機構の使用の促進、機構へのリンクなどによって、ネイティブコードとして実装されることができる。

【0145】

本明細書の技術は、一般に、技術または技術分野に対する上述した改善、ならびに様々な分野に対する特定の技術改善を提供する。

【0146】

上述した各プロセスは、好ましくは、専用マシンとして、１つ以上のプロセッサにおいて実行可能なプログラム命令のセットとしてコンピュータソフトウェアに実装される。

【0147】

エッジネットワークは、様々な技術を使用してコアと通信することができる。利用されることができる代表的なオーバーレイネットワーク技術は、米国特許出願公開第２０１５／０１８８９４３号明細書および同２０１７／０１９５１６１号明細書に記載されているものを含み、それらの開示は、参照により本明細書に組み入れられる。とりわけ、これらの公開は、一般にオーバーレイを介した、ならびに（非公開で管理されることができる）企業データセンタとサードパーティのソフトウェア・アズ・ア・サービス（ＳａａＳ）プロバイダとの間の広域ネットワーク（ＷＡＮ）アクセラレーションサービスを促進するために使用されるＣＤＮリソースを説明している。１つの典型的なシナリオでは、いわゆるルーティングオーバーレイは、既存のコンテンツ配信ネットワーク（ＣＤＮ）インフラストラクチャを活用して、ダウンリンクを迂回するかまたは最小レイテンシを有する経路を見つけることにより、トランスポートプロトコルとしてインターネットプロトコル（ＩＰ）を使用する任意のアプリケーションの大幅な性能向上を提供する。他のアプローチは、マルチキャスト、ユニキャスト、ブロードキャストまたはその他のパケット転送技術を使用して、エッジからコアにメッセージを提供することである。

【0148】

本明細書の技術は、一般に、技術または技術分野に対する上述した改善、ならびに全て上述したように、分散型ネットワーキング、分散型トランザクション処理、広域ネットワークにアクセス可能なトランザクション処理システム、高性能、低レイテンシのトランザクション処理システム、非ブロッキングフルメッシュ相互接続システムなどを含む様々な分野に対する特定の技術改善を提供する。

【0149】

コンセンサス
ブロックチェーンのコンセンサスプロセスはマイニングに依拠しており、上記のように、マイニングは通常、ブロックチェーンにおける前のブロックを参照するヘッダを有する順序付けられたトランザクションのブロックを生成する行為である。本技法は、図１３に示されるシステムに実装することができ、そこではレガシー基盤（決済端末１３００）がオーバーレイネットワークのエッジサービス１３０２を介して決済ネットワークとインターフェースしている。一実施形態では、決済ネットワークは、ウォレットサービス１３０４、台帳サービス１３０６、ストレージサービス１３０８、およびデータ連携サービス１３１０を含み、データ連携サービスは、ある機関（銀行など）とインターフェースしている。

【0150】

以下では、本開示による信頼度ベースのコンセンサス技法についての設計を説明する。

【0151】

システム要件は、以下のとおりであることが好ましい：一貫性、可用性、スケーラビリティ、およびパフォーマンス。一貫性は、過負荷、敵対的な行為、コンポーネントの障害、ネットワーク分割（network partition）などの様々な条件下において、単一の有効なブロックチェーンを維持する、または取り戻すという概念である。可用性は、ノード障害および部分的なネットワーク停止に関わらず、システムの能力を機能させ続けるよう維持するという概念である。スケーラビリティは、１秒あたりのトランザクション数が増加した場合に、システムが線形にスケーリングする能力である。パフォーマンスは、所与の時間内に台帳内で確定を達成するという概念である。

【0152】

１つのリーダーを選ぶ
ラウンドごとに、単一のマイナーだけが、選出されることが好ましい。これは、マイナーがゼロとなるラウンドおよび過剰なマイナーがいるラウンドの両方、ならびに潜在的なフォークのクラスを除去し、システムのコストを削減する。

【0153】

本明細書におけるアプローチでは、許可されたブロックチェーンネットワークは、ウォレットに対し、それらのトランザクションの処理に関する情報を提供する。ノードがしきい値分の署名シェアを受信するまで停止するのではなく、ブロックのそれぞれ個々の署名が信頼度をそのブロックのトランザクションに付加するよう機能することが好ましい。ノードは、受信したそれぞれ有効なブロックに署名して、この署名データを他のノードおよびウォレットに伝搬させる。このことを、ブロックの有効性についての証人となるノードにおけるように、ｗｉｔｎｅｓｓする（witnessing）と称する。この署名データは、ブロックに含まれるトランザクションの耐久性のスコアまたは信頼尺度として解釈可能な暗号法的エビデンスを、他のノードおよびウォレットに与える。すなわち、ウォレットは、より多くのノードがブロックをｗｉｔｎｅｓｓするのを見ると、ブロックのトランザクションが確定されることをより確信できるようになる。

【0154】

ブロックの信頼度を検証するコストを削減するために、マルチシグネチャの暗号法的アプローチが用いられることが好ましい。したがって、ブロックのｗｉｔｎｅｓｓ署名は、ｗｉｔｎｅｓｓの公開鍵の集約である単一の公開鍵を使用して検証することができる単一の署名に集約される。これにより、好ましくはｗｉｔｎｅｓｓを識別するリストに付属する単一の署名および公開鍵を用いてする信頼度の表現が可能にする。ブロックの信頼度を検証するために、検証者はｗｉｔｎｅｓｓの公開鍵を集約し、得られる公開鍵が信頼度の公開鍵と同じかどうかをチェックし、その公開鍵を用いてその署名を検証する。

【0155】

信頼度の利用
信頼度データは、コアネットワークがブロックの確定に合意する程度についての情報をウォレットに提供する。この情報は、様々な方法で利用される可能性がある。より一般的には、これは、任意の機関（例えば、銀行）およびその顧客のためにポリシーまたはビジネスロジックが定義および実装されるメカニズムである。その上、競合解決オプションが高度に自動化されて実装されることが好ましい。

【0156】

信頼度ベースのフォーク解決
信頼度を利用して、システムは以下のようにフォークを解決することができる。

【0157】

まず、２つ以上のチェーン（フォーク）が提示されると、システムは最大の信頼度を有するチェーンを採用する。引き分け（信頼度が同等）である場合、決定論的な引き分け解消戦略が適用される。

【0158】

勝者チェーンが選ばれると、ノードは、障害から回復するのとほぼ同じ方法で、そのチェーンを回復させる。回復が完了すると、ノードは、他のノードによって生成されたブロックを検証することに戻る。しかしながら、捨てられたチェーン上のトランザクションが再処理（再有効化および伝搬）されるまで、ノードはそれ自身のブロックの生成に戻らないことが好ましい。

【0159】

捨てられたチェーンからのトランザクションは、新たに受信されたかのように再有効化されることが好ましい。真のネットワーク分割があった場合、大部分のトランザクションが有効化され、収束したネットワークの残りに伝搬されるべきである。しかしながら、現実のネットワーク分割がなかった場合、全てではないが多くのトランザクションは既に勝者チェーンに存在することになり、これらは複製であることが判明するため、有効化に失敗することになる。

【0160】

再有効化に失敗したトランザクションは、複製であることがわからない限り、競合トランザクションストリームの形態で、台帳から出力されることが好ましい。競合トランザクションストリームは、規定のビジネスロジックを適用することができ、かつ／または外部に通信することができるウォレットによって消費されるため、それに応じて外部のビジネスロジックがバランスを調節することができる。

【0161】

ブロックの間隔
コンセンサスアルゴリズムは、クロックが同期されてノードのセット全体にわたって固定長の間隔（ラウンド）で進行し、ノード間の通信遅延は限られていることが好ましい。簡略化のため、以下の設計ではラウンドの持続時間は一定のままであることを仮定している。

【0162】

リーダー選出
任意の所与のコンセンサスのラウンドについて、唯一のリーダーが選出されることが好ましい。選出は、好ましくはしきい値署名を用いて明らかにされるような、ネットワークグローバルな決定論的乱数を用いて行われることが好ましい。しきい値署名を使用することは、敵対者が、どのノードが将来のラウンドをリードるすかについての先見性を得ることができる前に、しきい値分のノードのセキュリティ侵害を行わなければならないことを意味する。

【0163】

Ｗｉｔｎｅｓｓする（Ｗｉｔｎｅｓｓｉｎｇ）
ノードのローカルチェーンに関して検証するブロックを提示されると、ノードは自身の識別情報鍵を使用してブロックに署名し、その署名をブロードキャストする。そうすることで、ノードはブロックの有効性についての証人となる。

【0164】

信頼度
ブロックについての集約ｗｉｔｎｅｓｓ署名情報はその信頼度を構成し、ブロックに含まれるトランザクションの耐久性の尺度として機能する。信頼度は、ｗｉｔｎｅｓｓ署名の配布により、個別に（通常運用時）または集約形態で（フォーク解決時）のいずれかで通信される。

【0165】

ブロック検証
ノードは、ブロックの検証を完了すると、ブロックのヘッダ、ノードのブロックｗｉｔｎｅｓｓ署名、およびブロックに関連付けられるトランザクションについてのブロックチェーンレシートを送信する。さらなるｗｉｔｎｅｓｓ署名がない場合、ブロックは最小限の信頼度（信頼度１）を有すると言われ、最終ではないと考えられる。

【0166】

ブロックの確定
ブロック検証は、アクティブなプロセスであるが、ブロックの確定（コンセンサス）は、規定のしきい値を超えるブロックの信頼度に関連付けられる状態である。ブロックの信頼度がしきい値を超えているという証明を受け取ったオブザーバは、所与のブロックおよびその全ての祖先が、祖先の信頼度に関わらず、ブロックチェーン上で確定されることを知って、安全に動作することができる

【0167】

フォークの許可
フォークは、真のネットワーク分割など、稀な状況下でのみ生じることが予測されるが、システムはブロックチェーン中でのフォークを許可するように構成可能である。この特徴によって、普及しているビジネスロジックの用途に応じて、おそらくはデグレードした状態ではあるが、決済ネットワークが運転し続けられるよう、広範な停止の間でも台帳サービスの可用性を維持することができる。

【0168】

フォークの解決
ブロックの信頼度を利用して、ノードは自動的にフォークを検出して解決する。ＵＴＸＯの使用を巡って競合していないトランザクションは、自動的に主チェーンに追加されるか、またはそれらが複製であれば破棄される。競合トランザクションは、外部の要素に報告され、解決される。

【0169】

用語
●λは、システムがサポートすることができる、１秒当たりのトランザクション数を表す。
●Ｔは、コア台帳が１つのトランザクションを確定するのに許容される最大時間を表す。
●ｎは、システム内のノードの総数を表す。
●ｆは、システムが安全に許容することができる、悪意のあるノードの数を表す。
●Ｆ≧ｆは、悪意のあるノードおよび単純にクラッシュしたノードを含む、システムが安全に許容することができる障害ノードの総数を表す。
●Ａ_ｉは、ラウンドｉでのリーダーを表す
〇ある所与のラウンドについて、ｌ個の異なるリーダーを許可する場合、これらを

【数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】

は、結合した署名が有効かどうかを判断する。
●ＵＩＤ_ｊ＝Ｈ（ＰＫ_ｊ）は、ノードｊの一意な識別子を表す。
●Ｃｈａｉｎ_ｊ（Ｂ_ｉ）は、Ｂ_ｉを含むノードｊのチェーン内で深さ≦ｉにあるブロックを表わす。
●Ｃｈａｉｎ_ｊ［ｘ：ｙ］（Ｂ_ｉ）は、Ｂ_ｉを含むノードｊのチェーン上のラウンドｘからｙまでのブロックを表わす。
●ＳｅｌｅｃｔＣｈａｉｎ_ｊ（Ｗ_ｉ，Ｚ_ｉ）→Ｙ_ｉ∃｛Ｗ_ｉ，Ｚ_ｉ｝は、Ｃｈａｉｎ_ｊ（Ｗ_ｉ）およびＣｈａｉｎ_ｊ（Ｚ_ｉ）に含まれる情報のみを考慮する決定論的なチェーン選択戦略を用いることによって、（引き分けを解消するべく）どのチェーンに続くかを返す関数とする。
●ＶｅｒｉｆｙＨｅａｄｅｒＣｈａｉｎ_ｊ（Ｂ_ｉ）→Ｚ ｏｒ ＦＡＩＬは、共通の祖先ブロックＺが特定されるまで、またはプロセスが失敗するまで（ヘッダの検証に失敗する、共通の祖先を見つけることができない、など）、何らかの他のノードｊのＣｈａｉｎ_ｊ（Ｂ_ｉ）に含まれるブロックヘッダを検索読み出して検証する関数とする。

【0170】

追加的な仮定
以降のアルゴリズムは、以下の追加的な仮定に依拠する：
●何らかの信頼できる管理者Ａｄｍｉｎが存在し、その公開鍵ＰＫ_{Ａｄｍｉｎ}は全てのノードが知っており、その秘密鍵ＳＫ_{Ａｄｍｉｎ}は非常に強固に保護されていると仮定する。
〇Ａｄｍｉｎは、ノード秘密鍵素材を所有しておらず、結果的にブロックをｗｉｔｎｅｓｓすることができないし、リーダー選出にも参加できないことが好ましいことに留意されたい。
●全ての善意のノードのリストが同一となるように、各ノードは全ての他のノードを認識しており、全てのノードｊについてのＰＫ_ｊを知っており、ソートされたリストＮ＝［ＵＩＤ_１，．．．，ＵＩＤ_ｎ］を有していると仮定する。
〇Ｎ_Ｅは、ネットワークエポックＥの間の、Ｎの値を表す。
●Ｈｅａｌｔｈ（ｊ）の出力が、ノードｊが現在有効なリーダーとして機能することができるかどうか（すなわち、あるマイニングラウンドの持続時間内にブロックのマイニングを終了するために必要なリソースを有しているかどうか）を示すブール値となるように、或る健全なモニタリング処理Ｈｅａｌｔｈが存在すると仮定する。
●ネットワークが健全な場合に何らかの最大時間Δ内でＮにある全ての善意のノードによってメッセージｘが受信されるように、任意のノードがＢｒｏａｄｃａｓｔ_Ｎ（ｘ）をコールすることによってメッセージｘを確実に伝搬することができるような、或るセキュアなマルチキャストプロトコルＢｒｏａｄｃａｓｔが存在すると仮定する。このプロトコルには、ブロードキャストされたメッセージを受信する任意のノードが送信側のノードの識別情報およびメッセージコンテンツの完全性を検証することができるように、認証メカニズムが含まれる。
●所与の任意の時刻における任意の２つのノード間のクロック値の差が、最大でもδとなるように、全てのノードが大まかに同期されたクロックを有すると仮定する。
〇クロックは、独立的に、信頼できる外部ソースに同期されることが好ましい。

【0171】

決定論的なリーダー選出
目的
設計により、敵が将来的なリーダーの識別情報を予測すること、またはそれに影響を及ぼすことを妨げつつ、リーダーを決定論的に選出することが好ましい。そのような決定論的なスキームは、いくつかの望ましいプロパティを与える：
●１ラウンド当たりの、一定の最大数のリーダーを保証する能力
●分岐／フォークの程度に対して上限を設ける能力
●全てのノードが善意的且つ健全である場合、不必要なゼロマイナーラウンドの回避

【0172】

これらの性質を得るため、全てのノード（または、その参加者）が、各ラウンドの初めに、そのラウンドのリーダーの識別情報を導出可能な乱数の値について合意することが好ましい。理想的には、これは、できるだけ少ない通信で、且つ少なくとも１つの善意のノードからの入力を必要とするやり方で行われるべきである。

【0173】

選択アルゴリズム
●ネットワークエポックＥの間にラウンドｉについてのリーダー選出プロセスに参加するために、ノードｊは

【数26】

を計算し、時刻τ_ｉにおいて

【数27】

をコールする。
〇全てのラウンドのリーダーの識別情報は、

【数28】

が実行されるとすぐに決定されることに留意されたい。署名シェアをブロードキャストするのは、その所定の識別情報を明らかにすることを支援するためだけである。
●任意のノードｊ’から署名シェアを受信すると、ノードｊは、

【数29】

をコールして、それが有効かどうかを判断する。
●ノードｊが、少なくともｍ個の有効な署名シェア（それぞれが、自分自身を含め、異なるノードによって生成されたものである）のセット

【数30】

を編集してしまうと、次に

【数31】

を計算する。
●

【数32】

が真である場合、ｊはＡ_ｉ＝Ｎ_Ｅ［Ｈ（Ｋ_ｉ）％ｎ］となるように次のリーダーを決定する
●受信した有効な署名シェアがｍ個より少ない場合、または

【数33】

が偽である場合、ｊは次のリーダーを決定することができず、ラウンドｉについてヌルブロックを挿入しなければならない。

【0174】

プロパティ
●ラウンドごとのリーダー選出プロセスは、先行するラウンドからの入力なしに運用されることが好ましい。
●各リーダーの識別情報は、全ての先行するリーダーの識別情報から完全に独立していることが好ましい。

【0175】

ブロックの信頼度および確定
システムがトランザクションのオーダリングに関してコンセンサスに達するために、そのトランザクションのオーダリングがシステムの全コンポーネントによって合意されるよう、ブロックが「確定された」こと、すなわち、当該ブロックは恒久的にブロックチェーンに追加されたことをアサートするためのメカニズムまたは基礎が提供される。

【0176】

追加的に、また説明したように、あるブロックの確定に先立って、そのブロックに対する何らかの「信頼度」の概念を有することが有用である。これは、あるブロックが確定される確からしさを表現するメトリックである。

【0177】

確定アルゴリズム
●時刻τ_ｉ＋１において、Ａ_ｉは

【数34】

をコールする
●Ｂ_ｉを受信して検証した後、ノードｊは

【数35】

を計算して、

【数36】

をコールする。この時点で、ｊがＢ_ｉをｗｉｔｎｅｓｓしたと言える。
●ノードｊが何らかのブロックＢ_ｉをｗｉｔｎｅｓｓした時、または別のノードから、そのノードがＢ_ｉをｗｉｔｎｅｓｓしたことを示す有効な署名シェアを受信した時はいつでも、その集約署名

【数37】

を更新し、且つ

【数38】

のようにセットする。ここで、

【数39】

は、受信した署名シェアの数である。
〇ノードが同一ラウンドで２つ以上のブロックをｗｉｔｎｅｓｓする場合、現在および将来のラウンドについてのその全てのｗｉｔｎｅｓｓ署名は、無視されることが好ましい。このように振る舞うノードは、セキュリティを侵害されているか、または障害のいずれかであるため、ネットワークから取り除かれ、スコーチ（ｓｃｏｒｃｈ）され、セキュアであることが検証され、そして新しいノードとしてネットワークに再度追加されなければならない（新しい識別情報鍵で）。
●Ｂ_ｉの各祖先ｂについて、ｊはＣ_ｊ（ｂ）＝ｍａｘ（Ｃ_ｊ（ｂ），Ｃ_ｊ（Ｂ_ｉ））をセットする
●一旦Ｃ_ｊ（Ｂ_ｉ）≧ωとなると、Ｂ_ｉは確定されており、ｊのチェーンから除去されてはならない。
〇ブロックの確定は、グローバルトルゥースであるが、異なるノードは、ｗｉｔｎｅｓｓ署名をいつ受信したかに応じて、異なる時刻に所与のブロックが確定されたことを知ることに留意されたい。

【0178】

ヌルブロック
●ノードが時刻τ_ｉ＋１＋Δまでに有効なＢ_ｉを受信しなかった場合、またはＡ_ｉの識別情報がわからなかった場合、ノードは、ラウンドｉについてヌルブロック（β_ｉと表す）を挿入し、通常のブロックをｗｉｔｎｅｓｓしているかのように

【数40】

をコールする。
●ノードは、所与のラウンドでヌルおよび非ヌルブロックの両方をｗｉｔｎｅｓｓしている署名シェアを受信するが、ｗｉｔｎｅｓｓされている実際のブロックに対するその信頼度だけを更新する。
●Ａ_ｉが、ラウンドｉの間の任意の時点でＨｅａｌｔｈ（Ａ_ｉ）＝Ｆａｌｓｅであると判断した場合、先制的にβ_ｉをそのブロックチェーンにアペンドして、

【数41】

をコールする。このメッセージを受信する任意のノードｊは、そのラウンドでは非ヌルブロックがマイニングされないことを知っているため、直ちに

【数42】

をコールすべきである。これにより、ノードがβ_ｉに対する（したがってその祖先に対する）高度な信頼を確立することができ、それによりフォーク後の回復を加速させることができる。

【0179】

ラウンドのタイミング
ノードは、所与のラウンドについてのリーダー選出に、任意に早く参加することができるが、理想的には各リーダーの識別情報は、実際にノードがリーダーとして機能する必要があるまで、未知のままであるべきである。これは、敵対者が（例えば）リーダーに対してＤｏＳ攻撃を実行してリーダーがそのブロックを仕上げるのを妨げることを、阻止するためである。しかしながら、善意のノードは、時刻τ_ｉ＋１までにＢ_ｉを生成するのに十分な時間を持ってＡ_ｉがその識別情報を知るように、十分に早くリーダー選出プロセスに参加しなければならない。これを容易にするべく、ラウンドｉが時刻τ_ｉに開始する際、各善意のノードは、

【数43】

をコールすることにより、リーダーＡ_ｉの特定に参加する。

【0180】

Ａ_ｉがその識別情報を知り、Ｂ_ｉ－１の検証を終えると、Ｂ_ｉについてのブロックのアナウンスメントをブロードキャストし、Ｂ_ｉの生成および他のノードへのストリーミングを開始することができる。Ａｉは、Ｂ_ｉに関する全てのデータの送信を、時刻τ_ｉ＋１での次のラウンドの開始までに終えなければならない。任意のノードｊがＢ_ｉ－１の検証を終えると、ノードは

【数44】

をコールして、そのブロックをｗｉｔｎｅｓｓする。または、ノードがＢ_ｉ－１を時刻

【数45】

までに検証することができない（または受信しない）場合、ノードは代わりに

【数46】

をコールして、そのラウンドについてヌルブロックをｗｉｔｎｅｓｓする。

【0181】

ノードは、そのチェーンにＢ_ｉまたはβ_ｉを追加しているかどうかを、いずれか一方についての確定しきい値分のｗｉｔｎｅｓｓ署名を受信するとすぐに、外部エンティティ（例えば、ウォレットサービス）に通知する場合があり、ネットワークが健全な場合、これは時刻

【数47】

までに起こると期待される。何らかの理由で、ノードがその時刻までにＢ_ｉまたはβ_ｉが確定されたことを確認できない場合、ノードはこの情報を（

【数48】

において）エクスポートするために最大１ラウンド後まで待機することもできる。

【0182】

図１４のダイアグラムは、リーダー選出、ブロック生成、およびブロックｗｉｔｎｅｓｓに関連してラウンドｉで生じる事象のタイミングを示している。クロック同期スキューδは、関連する他の遅延については無視できると期待されるため、このダイアグラムおよび上述の説明では、それを考慮していないことに留意されたい。

【0183】

トランザクションの受信および確定
本明細書におけるアプローチは、１秒当たり或る最小数のトランザクションが最終的に確定されるブロックに追加されることを保証する。これは、互いに通信することができる少なくともｍ個の善意的且つ健全なノードを仮定している。

【0184】

これを保証するために、各ブロックは、少なくとも何らかの数のトランザクションを保有できなければならず、この数は、保証する必要があるトランザクション速度、悪意のあるノードまたは障害ノードがリーダーに選出される確率、およびマイニングラウンドの持続時間の関数である。

【0185】

フォークの解決
ネットワーク分割に起因するもの、ソフトウェア問題に起因するもの、または時刻τ_ｉ＋ｔの後でブロックヘッダＢ _ｉ を受信するため、ノードのサブセットがＢ_ｉを拒否し、ヌルブロックβ_ｉをｗｉｔｎｅｓｓすることに起因するものを除いて、設計によりフォークとなる原因を限定する。

【0186】

フォークの解決は、全てのこれらの状況について同一であり、以下のプロパティが示されるべきである：
●確定したブロックは変位（任意のノードでチェーンから除去）されない。
●高信頼度のブロックが先行するラウンドで低信頼度のブロックブロックを置換することなしに、低信頼度のブロックが高信頼度のブロックを変位させることはない。
●ノード上でのフォーク解決が終了するまでのコストは、フォークの深さおよび関与するトランザクションの数と線形関係でなければならない。
●フォークがインメモリトランザクション履歴（数時間、または数日）より長く永続化しない場合には、変位させられたチェーン上の非競合のトランザクションは解決時に正常に再有効化されて主チェーンに追加されるか、または複製として適切に破棄されるべきである。

【0187】

全体的なフォーク解決アルゴリズム
フォークは、４つの高レベルステップを伴うプロセスを使用して解決されることが好ましい：
●検出：ノードが低信頼度のチェーン上にあるかどうかを判断するプロセスであり、もしそうであれば、ブロックがリセットされた共通祖先の深さおよびブロックハッシュ、ならびに現在の深さｙを記録し、それにより当該ノードは、深さｘ＞ｙに達した後であるが、低信頼度のチェーンに含まれるトランザクションを後でリプレイすることができる。
●リセット：ブレイン（ノードコーディネータとしてコンセンサスを実行しているコンピューティングノード）はマイニングを停止し、他のノードコンポーネントに対して深さｚにリセットするよう命令する。ブレインは、次のステップに入る前に、リセットが完了するまで待機する。捨てられたチェーンからのトランザクションを含む一時的なメモリプールが、各トランザクションハンドラ内で作成される。
●回復（リセットと並行して行われてよい）：このステップでノードは通常の回復プロセスに入るが、いくつかの修正を伴う：
〇ノードは、ブロックを確定すると、確定済みブロック内のトランザクションを一時的なメモリプールから除去する。
●リプレイ：リプレイステップは、深さｙに達した時に実施され、トランザクションハンドラは、捨てられたチェーンからのトランザクションを再有効化してブロードキャストし、あらゆる競合トランザクションの通知を送信する。

【0188】

ヘッダチェーン検証アルゴリズム
チェーン検証プロセスでは、受け取ったチェーンが深さｉから後方に共通祖先の深さｚまでのローカルチェーン内の全てのブロックよりも高い信頼度を有しているかを検証することにより、当該チェーンの正当性を検証する。受け取ったチェーン中の全てのヘッダおよび信頼度の値が検証され、ローカルチェーンよりも高い信頼度を有している場合、ｚのみを返す。

【0189】

ＶｅｒｉｆｙＨｅａｄｅｒＣｈａｉｎ_ｊ（Ｂ_ｉ）→ｚ ｏｒ ＦＡＩＬ：
●Ｒは、Ｂ_ｉと同一のチェーン中の受信したブロックを表す。
●Ｌは、ローカルチェーンのブロックを表す。
●Ｃ（ｌｏｃａｌ）は、このノードのローカルチェーン信頼度を表し、最初はＬ_ｉの信頼度にセットされる。
●Ｃ（ｒｅｍｏｔｅ）は、受信したリモートチェーン信頼度を表し、Ｃ（Ｂ_ｉ）＝＝Ｃ（Ｒ_ｉ）にセットされる。
●ｊは、ループ内の深さを表し、最初はｉにセットされる。
●Ｌ_ｊ！＝Ｒ_ｊである間：
〇ヘッダおよびＲ_ｊ親Ｒ_ｊ－１の信頼度を取得する
〇ヘッダおよびＲ_ｊ－１の信頼度を検証する
■失敗した場合、ＦＡＩＬを出力して、終了する
〇Ｃ（Ｒ_ｊ－１）＞Ｃ（ｒｅｍｏｔｅ）である場合、Ｃ（ｒｅｍｏｔｅ）＝Ｃ（Ｒ_ｊ－１）にセットする
〇Ｃ（Ｌ_ｊ－１）＞Ｃ（ｌｏｃａｌ）である場合、Ｃ（ｌｏｃａｌ）＝Ｃ（Ｌ_ｊ－１）にセットする
〇Ｃ（ｒｅｍｏｔｅ）＜Ｃ（ｌｏｃａｌ）である場合、ＦＡＩＬを出力して、終了する。
■

【数49】

〇そうでなければ、ｊ＝ｊ－１にセットする
●ｊをリターンする
〇この時点でＬ_ｊ＝＝Ｒ_ｊであり、これは共通祖先が深さｊにあることを意味する。

【0190】

チェーン選択アルゴリズム
チェーン選択戦略を用いて、同一の信頼レベルを有する２つの候補チェーンがある場合に、決定論的にどのチェーンに続くかを選択する。
ＳｅｌｅｃｔＣｈａｉｎ（Ｗ_ｉ，Ｑ_ｉ，ｚ）→Ｙ_ｉ∃｛Ｗ_ｉ，Ｑ_ｉ｝
●パラメータ：
ａ．Ｗ_ｉおよびＱ_ｉは、深さｚに共通祖先を持つ２つの異なるチェーンの先端を表す、深さｉにある２つのブロックである。
ｂ．Ｗ_ｉまたはＱ_ｉを返す
●プロパティ：
ａ．深さ［ｚ＋１：ｉ］におけるブロックを表す同一のチェーンビューを所与として、決定論的である
●戦略：
ａ．深さｚ＋１における最も好ましいリーダーに基づいてチェーンを選択する
ｂ．トランザクションの数が最大のチェーンに基づく。
ｃ．深さ［ｚ＋１：ｉ］の間で、ヌルブロックの数が最少のチェーンに基づく
ｄ．最初の（ａ）を最終手段の引き分け解消法として上述の戦略を重み付けした組み合わせ。

【0191】

フォーク検出アルゴリズム
ノードが未知の親ブロックハッシュを参照するブロックアナウンスメントを受信すると、フォークが検出される。当該ノードは親ブロックのヘッダを読み出し、その信頼度の値を検証し、その値がその現在のチェーンと等しいか、またはそれより高いかどうかをチェックする。等しいかまたはより高い値である場合、ノードは、共通祖先が特定されるまで、またはプロセスが失敗するまで、ヘッダチェーンの読み出しおよび検証を開始する。検証可能な最高の信頼度を有するチェーンは、主チェーンと称される。同一の深さｘにある２つのチェーンが、同一の信頼度を有する場合、ＳｅｌｅｃｔＣｈａｉｎ（Ｗ_ｉ，Ｚ_ｉ，ｃ）を用いることにより、深さ＜＝ｘにあるブロック内の情報に基づいて決定論的なチェーン選択戦略が適用される。ここで（Ｗ_ｘ，Ｚ_ｘ）は引き分けチェーンの先端のブロックを表し、ｃはそれらの共通祖先の深さを表す。
●ノードのチェーンの先端は、深さｙのブロックＹであり、信頼度Ｃ（Ｙ）を有すると仮定する
●ノードは、そのチェーンにおける信頼度の変化を追跡し続け、ｐをチェーンの信頼度が最後に低下したブロックの深さであると仮定する。
●ノードは、未知の親ブロックＸを有するブロックＸ２のアナウンスメントを受信する。
●ノードは、チェーン内の深さｘにあるブロックＸのヘッダをクエリして、その信頼値Ｃ（Ｘ）を検証する。
●ｘ！＝ｙである場合、プロセスを終了する。
●Ｃ（Ｘ）＞＝Ｃ（Ｙ）である場合、チェーン検証プロセスＶｅｒｉｆｙＨｅａｄｅｒＣｈａｉｎ_ｊ（Ｂ_ｉ）に入り、条件により：
〇深さｚで共通祖先ブロックＺを出力し、続行する
〇ＦＡＩＬを出力し、プロセスを終了する
●Ｃ（Ｘ）＝＝Ｃ（Ｙ）である場合、決定論的なチェーン選択戦略ＳｅｌｅｃｔＣｈａｉｎ（Ｘ，Ｙ，ｚ）を用いて、当該ノードが主チェーン上にあるかどうかを判断する：
〇出力がＹである場合、ノードは主チェーン上にあり、プロセスを終了する
●ノードは、主チェーン上にないか、または主チェーン上で（Ｙ＝＝Ｚ）に遅れを取っており、Ｙ！＝Ｚである場合、リセットプロセスに入り、そうでなければ、回復プロセスに入る。

【0192】

チェーンリセットアルゴリズム
ノードを深さｙから深さｚにリセットして、Ｃｈａｉｎ［ｚ：ｙ］（Ｙ）に含まれるトランザクションを、将来のリプレイのために、一時的なメモリプールに移動させる。Ｙは、リセット前にノードチェーンの先端にあるブロックである。
●ノードコーディネータとしてコンセンサスを実行しているコンピューティングノードは、ノードコンポーネントに対して「深さｚにリセット」の指示を発行する。これは、スナップショット回復指示ではない。
●トランザクションハンドラは、コマンドをＵＴＸＯハンドラに転送し、深さｙから深さｚ＋１までのブロックに含まれるトランザクションを、一時的なメモリプールに移動させる。
●ＵＴＸＯハンドラは、そのＵＴＸＯ状態を指定された深さにリセットするよう試行する。リセットが失敗した場合、ブレインに通知される。
●リセットの失敗：
〇ブレインは、最近接のスナップショット（高信頼度のチェーン上にある可能性がある）を特定し、ＵＴＸＯハンドラに対してそのスナップショットから復元するよう指示する。
〇ＵＴＸＯハンドラは、指定されたスナップショットからその状態を正常に復元すると、通知を送信する。

【0193】

チェーン回復アルゴリズム
●主チェーンに追いついていない間：
●
〇コンセンサスを実行しているノードは、次のブロックについてのブロックヘッダをフェッチして検証し、それが主チェーン上にあることを確かにする
■このステップは、深さ＜ｘのブロックヘッダについての「検出」の間に完了されている
〇他のコンポーネントに対して、ブロックを検証するよう命令する。これは、通常のブロック検証ワークフローと同様のプロセスにしたがう。
■トランザクションハンドラはリクエストを出し、ブロック内の各セグメントを有効化／検証し、全てのセグメントのトランザクションが正常に割り当てられている場合は、セグメントマークルルートをブレインに送信し、または割り当てに失敗があれば失敗したことを送信する。
■ここで説明したプロセスと通常のトランザクション有効化との唯一の違いは、ブロックが確定された時、確定したトランザクションが一時的なメモリプールにあれば、トランザクションハンドラがそれらを除去しようと試行することである。
●ノードは、いつ同期した／追いついたと考えられるか？
〇ノードの現在の深さｙが、受信したブロックアナウンスメントの深さｗから１だけ少ない深さの場合。ｗ－１＝＝ｙ。

【0194】

トランザクションリプレイアルゴリズム
これは、捨てられたチェーン上にあったトランザクションをリプレイし、競合を特定するプロセスである。このプロセスは、深さｚにリセットされたノードが、回復プロセスにおいて、その元の深さｙに達すると、開始する。ブロックが有効化されると複製は一時的なメモリプールから除去されるため、このプロセスを深さｙで開始することにより、ブロック内に存在する複製トランザクションが採用されたチェーンの深さ［ｚ＋１：ｙ］から再ブロードキャストされることを防止する。
●トランザクションハンドラは、トランザクションを、マイノリティチェーンに含まれるトランザクションを含む一時的なメモリプールから、主メモリプールに移動させるように試行する。
●トランザクションが正常に主メモリプールに受け入れられると、トランザクションは他のノードに転送される。
●トランザクションが受け入れられることに失敗した（ダブルスペンド）場合、「競合検出」通知が、適当な当事者に送信される。
●一時的なメモリプールにあったトランザクションのいずれかが、将来のブロックへの割り当てに失敗したか、または主メモリプールへ追加された後タイムアウトした場合、「競合検出」通知が、適当な当事者に送信される。

【0195】

ネットワーク構成変更
このシステムは、構成変更を実装するために、何らかのメカニズムを必要とすることが好ましい。高レベルでは、構成変更の実装形態は、ネットワークエポックＥ⇒Ｅ’をインクリメントすることによりマークされる。新しい構成における全てのノードは、Ｅ’を含む第１のブロックを、このブロックが確定されたと考えられる前に、（直接的に、または間接的に）ｗｉｔｎｅｓｓしなければならない。

【0196】

構成パラメータは、Δ，ω，ｔ，などの事柄、およびＨのパラメータを含むことができる。しかし、最も可能性が高いのは、ネットワークＮ⇒Ｎ’を構成するノードのセットに対する変更である。例えば、向上したトランザクション処理能力を持つノードを追加すること、またはクラッシュしてしまった、もしくはセキュリティを侵害されたノードを除去すること。全てのノードが、Ｎへの変更が有効になる時点について合意しなければならない。２つのノードが何らかのラウンドｉについてＮ_ｉの値に合意しない場合、これらのノードは、Ａ_ｉの識別情報およびＣ（Ｂ_ｉ）の値に対して合意しない可能性が非常に高く、どちらも非常に問題である。ブロックチェーンがノード間のコンセンサスを確立するよう既に機能しているため、理想的な解決法は、あるブロック内に構成変更情報が存在することである。
構成変更は、Ａｄｍｉｎによって開始されることが好ましい。
構成変更が有効になれる前に、公開鍵｛ＰＫ_１，．．．，ＰＫ_ｎ’｝を有するノードの新しいセットＮ’は、好ましくは

【数50】

を、まとめて実行することにより、リーダー選出鍵の新しいセットを生成し、この場合、新しいしきい値ｍ’は、以前のしきい値ｍに等しくても、等しくなくてもよい。このプロセスは、全ての善意のノードからの参加を必要とするため、これを完了するためには、ネットワークが未分割である必要がある。この鍵再作成（rekeying）手順は、Ｎ＝Ｎ’であったとしても全ての構成変更について行われる。

【0197】

構成変更アルゴリズム
以下のステップでは、Ａｄｍｉｎが構成変更を実装し、ネットワークをエポックＥからＥ’へ（Ｅ⇒Ｅ’）移行可能にする。
１．Ａｄｍｉｎは、ネットワークに追加したいノードのセットＪ、および／またはネットワークから除去したいノードのセットＲ⊂Ｎを決定する。すなわち、Ｎ_Ｅ’＝（Ｎ_Ｅ－Ｒ）＋Ｊ。
〇Ａｄｍｉｎは、予めノードｊ∈Ｎ_Ｅ’ごとに、識別情報鍵ＰＫ_ｊを知っていなければならない。
〇ＪおよびＲは、両方がヌルのセットである可能性があり、この場合、Ｎ_Ｅ＝Ｎ_Ｅ’。
２．Ｋ’を、Ｎ_Ｅ’における全てのノードについての、公開の識別情報鍵（｛ＰＫ_１，．．．，ＰＫ_ｎ’｝）のソート済セットとする。
３．Ａｄｍｉｎは、Ｎ_Ｅ’がリーダー選出署名スキームにおいて用いる適当なしきい値ｍ’を決定する。
４．Ａｄｍｉｎは、少なくともＥ’、Ｋ’、ｍ’を含む新しいネットワーク構成に関する全ての情報を含む、Ｃｏｎｆｉｇ_Ｅ’を構築する。
５．Ａｄｍｉｎは、

【数51】

を計算する。
６．Ａｄｍｉｎは、

【数52】

について

【数53】

をコールする。
〇いくつかの

【数54】

について

【数55】

をコールしてもよいが、これは厳密には必要ではない。
７．Ｎ_Ｅ’中の各ノードは、

【数56】

がＴｒｕｅを出力することを確認する。
８．

【数57】

が実行される。
９．任意のノードｊ∈（Ｎ_Ｅ－Ｒ）が、エポックＥ’について、そのリーダー選出鍵

【数58】

を受信してしまうと、そのノードがリーダーとして生成する次のブロックは、Ｃｏｎｆｉｇ_Ｅ’および

【数59】

を含む構成ブロックである。
〇ｊは、生成するあらゆる介在ヌルブロックについて、ネットワークエポックＥを使い続けなければならない。
〇ｊは、ネットワークエポックＥ’のブロックを生成または受信するまで、ネットワークエポックＥの他のノードからのブロックを正常に（その古い鍵のセットを使って）処理し続けなければならない。
１０．ノードが、初めにＭ_Ｅ’を受信することなく、ネットワークエポックＥ’のブロックを受信した場合、それを無視し（しかし、破棄しない）、Ａｄｍｉｎに連絡して構成変更メッセージを見落としたのかどうかを確認すべきである。これが起こり得る２つの可能なシナリオが存在する：
〇ノードがＲのメンバであり、メンバーシップ変更がそれなしで完了した。
〇ブロックが、悪意のあるノードまたは障害ノードにより送信された。
１１．ノードがＭ_Ｅ’を受信しているが、

【数60】

からそのリーダーシップ鍵の新しいセットを受信する前に、Ｎ_Ｅ’中のノードからネットワークエポックＥ’のブロックを受信する場合、ノードは、これらの鍵を受信するまで停止しなければならない。
１２．ノードｊが、一旦ネットワークエポックＥ’のラウンドｉでブロックを生成またはｗｉｔｎｅｓｓすると、全てのｉ’＞ｉについて

【数61】

を使用して

【数62】

を計算しなければならない。この時点で、ノードは、そのリーダー選出鍵をＥ＜Ｅ’である全ての構成について削除することができるが、それは鍵が再利用されないからである。また、ノードは、ネットワークエポックＥ＜Ｅ’である将来のあらゆるブロックアナウンスメントを無視することができる。
１３．Ｒ内のノードのｗｉｔｎｅｓｓ署名は、ネットワークエポックＥ’のいかなるブロックにも信頼度を与えない。
１４．ネットワークエポックＥ’のブロックのいずれも、少なくとも１つのそのようなブロックがＮ_Ｅ’内の全てのノードによってｗｉｔｎｅｓｓされるまでは、確定されたと考えることはできない。ブロックの子孫は、ωの標準確定しきい値だけを必要とする。
１５．先行メッセージＭ_Ｅ（何らかのＥ＜Ｅ’について）の鍵生成プロセスがまだ進行中の間に、ノードが構成変更メッセージＭ_Ｅ’を受信した場合、ノードは古いプロセスを捨て、Ｍ_Ｅ’で指定されるノードのセットで最初からやり直さなければならない。
〇ネットワークエポック数が単調に増加する一方で、より新しい数を優先して構成変更が中止された場合、チェーン上で数がスキップされる。この場合、新しいネットワークエポックを初期化する構成ブロックは、スキップされたあらゆるネットワークエポックを示すＡｄｍｉｎからの署名を含むべきである。

【0198】

鍵の管理
高レベルでは、全てのリーダー選出および識別情報鍵の管理は、管理メッセージにより進められることが好ましい。通常、２つのタイプの鍵再作成事象が生ずる：
１）リーダー選出鍵シェアが変わる。
２）識別情報鍵が変わる。これは、同時的なリーダー選出鍵シェアの変更を必要とする。

【0199】

ＣＡを有する共通管理鍵が存在する。管理鍵および管理ＣＡの両方の公開部分は、ブロックチェーンのジェネシスブロックに記憶されることが好ましい。

【0200】

管理鍵のローテーション
任意の時点で、新しい管理鍵を、管理ＣＡにより署名されたネットワークにブロードキャストすることができる。これは、次の生成ノードによって、次の構成ブロック内に配置される。ＣＡ自身が類似の操作によりローテーション可能である。ＣＡ秘密鍵は、セキュアな方法によりオフラインで記憶されるべきである。

【0201】

識別情報鍵
識別情報鍵は、マルチシグネチャをサポートする非対称暗号系（Ｓ）の一部である。各ノードは、一意且つ永続的な識別情報鍵を有し、その公開部分がブロックチェーンに対して公開される。この鍵がローテーションされると、当該ノードはシステムの残りの部分によって新しいノードのように扱われる。各ノードの識別情報鍵は、以下のように、他のノードの識別情報鍵から独立して発行させ、そしてローテーション可能である：

【0202】

Ａｄｍｉｎはノードに対して、新しい識別情報鍵を生成し、この鍵を所有していることの証明を提供するように依頼する。次いで、Ａｄｍｉｎは、署名済みネットワーク構成変更メッセージを、ノードの新しい識別情報鍵（古いほうではない）を含むネットワークに対して発行する。これにより、標準的なネットワーク構成変更手順が開始し、結果としてノードはその新しい識別情報鍵でネットワークに追加され、古い鍵は取り消される。

【0203】

識別情報鍵の公開部分はブロックチェーン上で公開されるため、これらはウォレットサービスにより検証可能であり、使用可能である。公開された構成ブロックヘッダは、識別情報鍵の完全なリスト、およびそれらの有効性を証明するＡｄｍｉｎからの署名を含む。管理鍵を使用することにより、ブロックに対する信頼度に関わらず、これらの新しい識別情報鍵を検証することが可能である。ネットワークエポックは、これらの鍵変更によるリプレイ攻撃を防ぐよう機能する。

【0204】

リーダー選出鍵シェア
リーダー選出鍵シェアは、各ノードが秘密鍵シェアを保持する（ｍ，ｎ）しきい値暗号系（Ｓ）の一部である。

【0205】

リーダー選出鍵の初期化とローテーション
Ａｄｍｉｎがネットワーク構成変更を開始する都度、新しい構成におけるノードのセットは新しいリーダー選出鍵のセットを生成しなければならない。このプロセスは、本明細書におけるネットワーク構成変更のセクションにおいて詳述されている。この変更を開始するには、Ａｄｍｉｎが新しい構成における全てのノードの公開識別情報鍵を知っていること、および新しい構成における全てのノードがＡｄｍｉｎの公開鍵を知っていることが必要である。新しい構成における各ノードは、その新しい秘密リーダー選出鍵シェア、ノード相互の公開リーダー選出鍵シェア、およびマスターリーダー選出公開鍵を取得することになる。

【0206】

新しい構成でのノードのうちの１つによって生成された次の非ヌルブロックは、新しいネットワークエポック番号、その構成での全ノードの公開識別情報鍵、リーダー選出マスター公開鍵、および新しいリーダー選出しきい値ｍを（最低でも）含む構成ブロックとなる。また、非ヌルブロックは、これを証明するＡｄｍｉｎの署名、および包含可能なその他の構成情報も含まなければならない。

【0207】

他の全てのノードのリーダー選出鍵を同時にローテーションすることなく、単一のノードのリーダー選出鍵をローテーションすることは、望ましくない（おそらく可能ですらない）。Ａｄｍｉｎが、他の構成パラメータを全く変更することなくリーダー選出鍵をローテーションしたい場合、Ａｄｍｉｎは、ネットワークエポック番号を増やす以外は以前の構成変更と同一の構成変更を単純に開始する。リーダー選出鍵は、単一のネットワークエポックの期間中、使用されることが好ましい。

【0208】

システムブートストラップ／ジェネシスブロック処理
ジェネシスブロックは、第１の管理ＣＡおよびリーフ証明書（ｃｅｒｔ）を含むことが好ましい。第１の信頼できる管理ＣＡおよびリーフ証明書は、何らかの信頼できる方法により、帯域外の各ノードに配信されなければならない。

【0209】

第１のブロックがリーダー選出アルゴリズムを用いて公開されるのに先立って、リーダーが選出される。これは、識別情報およびリーダー選出鍵のローテーション手順にしたがい、その結果をジェネシスブロックに記憶する必要がある。

【0210】

永続性
●各ノードｊは、ｗｉｔｎｅｓｓされたブロックのテーブルを維持しなければならない。

【数63】

をコールしてブロックＢ_ｉをｗｉｔｎｅｓｓする前に、ノードはそのテーブルに（ｉ，Ｈ（Ｂ_ｉ））をアペンドする。そのテーブルが、何らかのエントリ（ｉ，Ｈ（Ｂ_ｉ））を含む場合、ノードは、ハッシュがＨ（Ｂ_ｉ）と一致しないラウンドｉのブロックをｗｉｔｎｅｓｓしてはならない。これは、クラッシュから回復した後、ノードが二重投票することを防ぐ。
●各ノードｊは、

【数64】

すなわち、その直近に確定されたブロックのラウンド数、ハッシュ、および集約ｗｉｔｎｅｓｓ署名を維持しなければならない。この値が更新されると、テーブル中のｉ＜ＦＩＮ_ｊであるｗｉｔｎｅｓｓされたブロックの任意のエントリを破棄してよい。
●各ノードは、その現在のネットワークエポックＥを維持しなければならない。この値は、ノードが新しいネットワークエポックのブロックについてのｗｉｔｎｅｓｓ署名を生成するか、または送信する前に更新される。
●各ノードｊは、

【数65】

、すなわちネットワークエポックＥについてのそのノードのリーダー選出鍵を、受信した時から、ノードがネットワークエポックＥ’＞Ｅのブロックを生成またはｗｉｔｎｅｓｓした後まで、永続化させなければならない（この時点で、Ｅ’についてのリーダーシップ鍵は既に永続化されている）。
●各ノードｊは、その識別情報鍵（ＰＫ_ｊ，ＳＫ_ｊ）を永続化しなければならない。Ａｄｍｉｎが、ノードが新しい識別情報鍵を生成することを要求する場合、ノードは、新しい公開鍵をＡｄｍｉｎに送信する直前に新しい鍵を更新して永続化させ、その新しい公開識別情報鍵を含む構成ブロックを（その新しい鍵で）生成するか、またはｗｉｔｎｅｓｓした後、古い鍵を削除することができる。
〇あるノードの識別情報鍵がクラッシュの間に紛失してしまった場合、当該ノードは回復時に新しいノードとして扱われ、その永続化された他の状態の全てが破棄されるべきである。

【0211】

ウォレットサービス
リーダー選出
ウォレットサービスは、リーダー選出を認識していることが好ましい。ウォレットサービスは、マスター公開リーダー選出鍵を用いることにより、ウォレットサービスが少なくともｍ個のノードから有効な署名シェアを受信するラウンドごとに、リーダーの識別情報を検証することができる。

【0212】

信頼度
ウォレットサービスは、ブロックの信頼度を認識していることが好ましい：
●ブロックヘッダストリームを受信する各ウォレットサービスコンポーネントは、ブロックヘッダストリームとともに受信する集約ｗｉｔｎｅｓｓ署名を検証する責任がある。あるブロックについての信頼度の更新は、そのブロックまたはその子孫についての新しい署名が受信された時に、行われる。
●ブロックヘッダストリームを受信する各ウォレットサービスコンポーネントは、識別情報鍵ローテーションを、構成ブロックからの新しい識別情報鍵を、正確に解釈、検証およびロードすることにより、処理できなければならない（これは、ウォレットサービスが管理署名を検証できることを意味している）。
●ウォレットサービスは、ポリシーおよびトランザクションロジックの実行を、ウォレットの有効なＵＴＸＯの関連付けられた信頼度に基づいて、管理する。例えば、ウォレットサービスは、これらの意味合い／制約に基づいて、例えば、ウォレットが低信頼度の決済を受け入れるかどうか、またはウォレットが決済において低信頼度のＵＴＸＯを使用するかどうかなど、ポリシーのプロビジョニング、管理、および実行を担当する。

【0213】

図１４は、コンセンサスラウンド、特に、リーダー選出、ブロック生成、およびブロックｗｉｔｎｅｓｓに関連付けられる事象についてのタイミング図である。

【0214】

上述の説明と併せて、以下を特許請求する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【国際調査報告】