JP7329540B2 - 準安定ビザンチン合意 - Google Patents

Description

この分野は、一般に情報セキュリティに関し、特に暗号通貨および他の用途で使用するコンセンサスプロトコルに関する。
優先権の主張
本出願は、米国仮特許出願第６２／６６９，７３４号、出願日２０１８年５月１０日、発明の名称「Ｍｅｔａｓｔａｂｌｅ Ｂｙｚａｎｔｉｎｅ Ａｇｒｅｅｍｅｎｔ」について優先権を主張し、その出願は参照により全体として本明細書に組み込まれる。

当分野では、複数のビザンチン障害耐性（ＢＦＴ）プロトコルが知られている。これらのプロトコルは、いくつかの場合「分散型コンピューティング」と呼ばれるコンピュータ科学のサブフィールドに属しているとみなされる場合がある。例えば、ＢＦＴプロトコルを使用して、相互に信頼していないマシン（サーバなど）のセットが合意に到達することができる。このような合意は「コンセンサス」とも呼ばれる。通常、ＢＦＴプロトコルはこの状況では、最大しきい値数より多くのサーバが破損しない限りは適切に動作できる（例えば、任意に振る舞ってもよく、ネットワークがコンセンサスに到達しないようにしてもよい）。従来のＢＦＴプロトコルは、ＢｉｔｃｏｉｎおよびＥｔｈｅｒｅｕｍなどの暗号通貨で利用されるＮａｋａｍｏｔｏコンセンサスプロトコルを含む。

例示的な実施形態は、暗号通貨および他の用途で使用する改良されたコンセンサスプロトコルを提供する。いくつかの実施形態では、コンセンサスプロトコルはより具体的には、準安定ネットワークプロ－ビング機構上に例示的に構築されたリーダーレスＢＦＴプロトコルを含む。

例えば、いくつかの実施形態は、コンセンサスを達成するために準安定ネットワークポーリング機構を使用する。上記のＮａｋａｍｏｔｏコンセンサスプロトコルは、コンセンサスを達成するためにプルーフオブワークを使用し、非常に非効率的である。一方に、本明細書で説明される例示的な実施形態における準安定コンセンサスプロトコルは、意思決定が行われておらず、プルーフオブワークを要求しないときは静穏であるが、いくつかの実施形態はプルーフオブワークとともに使用することもできる。

プルーフオブワークを使用しない従来のコンセンサスプロトコルは典型的には、オールツーオールのブロードキャスト機構に依存し、通常リーダーにより促進される。これらのプロトコルは典型的には、２次的メッセージの複雑性コストを招くが、必ず招くとは限らない。加えて、リーダーの存在は典型的には性能ボトルネックを課す。この種のいくつかの従来のプロトコルは、コンセンサスに到達するまで多くの通信ラウンドを要求し、各ラウンドでオールツーオール通信が要求される。これらのおよび他の理由のために、従来の方式は一般に多数のサーバまで大規模化しない。

一方、本明細書で説明される例示的な実施形態における準安定コンセンサスプロトコルは、ネットワークを繰り返しサンプリングするように構成してもよい。

その結果、これらの例示的な実施形態における準安定コンセンサスプロトコルは、ネットワークサイズとともにうまく大規模化し、メッセージ複雑性において非常に効率的であり、従来のシステムよりも高いスループットおよび低い遅延を提供する。

その上、いくつかの実施形態は、有向非巡回グラフ（ＤＡＧ）または他のデータ構造を構築することによりコストを償却する技術を実装し、単一のネットワークポーリングで一度にいくつかのトランザクションに対して暗黙的に投票可能であるが、コストを償却するためにＤＡＧまたは他の種類のデータ構造を使用することは必須ではないことを理解されたい。例示的な実施形態において使用可能な他の種類のデータ構造の例は、トランザクションのリンクリストおよびトランザクションのハッシュリンクチェーンを含む。いくつかの実施形態では、ＤＡＧは、トランザクションの競合を解決するだけでなく、一貫した全順序ログがネットワーク全体で複製されるプラットフォームを提供するように構成された線形順序連鎖データ構造の形態で実装される。

暗号通貨を効率的かつ大規模に展開するのに好適であるが、本開示の技術は、暗号通貨の状況以外の用途を含むさまざまな他の種類の用途に適用することもできる。例えば、本明細書で開示される準安定コンセンサスプロトコルを使用して、所定のセッティング用のコンピュータネットワークで広域コンセンサスを実行することもできる。

一実施形態では、装置は、複数の追加の処理ノードとのコンセンサスプロトコルに参加するように構成された第１の処理ノードを備える。第１の処理ノードは、コンセンサスプロトコルにおけるその参加とともにさらに構成され、追加の処理ノードのそれぞれ選択されたサブセットの繰り返しポーリングを実行し、繰り返しポーリングの結果に応答して、所与のトランザクションの状態を、その所与のトランザクションの複数の可能な状態のうちの特定の１つに解決し（変化させ、変更させ）、所与のトランザクションの解決された（変化された、変更された）状態に少なくとも部分的に基づいて、少なくとも１つの自動アクションを開始する。

いくつかの実施形態において所与のトランザクションの状態を解決することは、繰り返しポーリングの結果を利用して、所与のトランザクションを正当なトランザクションとして承認するべきか否かについての判定を行うことを含む。所与のトランザクションを正当なトランザクションとしてこのように承認することは、所与のトランザクションの「状態を解決すること」と本明細書でより一般的に呼ばれるものの一例と考えられる。他の実施形態では、それぞれが特定の状態に対するコンセンサスベースの解決に従う複数の可能な状態を有する、さまざまな他の種類のトランザクションを処理できる。

いくつかの実施形態では、繰り返しポーリングは複数反復繰り返され、反復のうちの所与の反復は、追加の処理ノードのサンプルを選択することと、選択された追加の処理ノードのそれぞれにクエリを送信することとを含む。いくつかの実施形態におけるサンプルは、ランダムに例示的に選択される確率的サンプルを含む。別の例として、可能であればシードを使用して、サンプルを決定論的に選択することもできる。

クエリに対する少なくともしきい値数の応答の受信に応答して、第１の処理ノードは、受信した応答の少なくとも指定した部分が、第１の処理ノードにおける所与のトランザクションの現在の状態と異なる所与のトランザクションの特定の状態を示すか否かを判定する。代替的に、特定のタイムアウトに到達する前に十分な応答が受信されない場合、このような判定は特定のタイムアウトに到達することに応答して行うこともできる。

受信した応答の指定した部分が、第１の処理ノードにおける所与のトランザクションの現在の状態と異なる所与のトランザクションの特定の状態を示すことに応答して、第１の処理ノードは、所与のトランザクションのその現在の状態を特定の状態に更新する。

追加的にまたは代替的に、いくつかの実施形態における第１の処理ノードは、トランザクションのＤＡＧを管理するように構成され、所与のトランザクションと、相互排他的な競合セットに分割されている複数の他のトランザクションとの間の関係を特徴付ける。所与のそのような実施形態では、ＤＡＧを管理することは例示的に、追加の処理ノードのサンプルを選択すること、選択された追加の処理ノードのそれぞれにクエリを送信すること、およびクエリへの応答に少なくとも部分的に基づいてＤＡＧを更新することを含む。この実施形態におけるＤＡＧの更新は例示的に、１つ以上の追加のトランザクションをＤＡＧに挿入すること、ＤＡＧのトランザクションのそれぞれの信頼度値を更新すること、および／またはＤＡＧのトランザクションを相互排他的な競合セットに再分割することを含む。同様に、他の実施形態では、リンクリストおよびハッシュリンクチェーンなどの他の種類のデータ構造を使用することもできる。

本発明のこれらのおよび他の例示的な実施形態は、内部に具現化されたソフトウェアプログラムコードを有するプロセッサ可読ストレージ媒体を備えるシステム、方法、装置、処理デバイス、集積回路、およびコンピュータプログラム製品を含むが、これらに限定されない。

例示的な実施形態において準安定ビザンチン合意用のコンセンサスプロトコルを実行する機能をとともに構成された情報処理システムである。 例示的な実施形態においてコンセンサスプロトコルの異なる変形形態のための擬似コードの例のセットを示す。 例示的な実施形態においてコンセンサスプロトコルの異なる変形形態のための擬似コードの例のセットを示す。 例示的な実施形態においてコンセンサスプロトコルの異なる変形形態のための擬似コードの例のセットを示す。 例示的な実施形態においてコンセンサスプロトコルの異なる変形形態のための擬似コードの例のセットを示す。 例示的な実施形態においてコンセンサスプロトコルの異なる変形形態のための擬似コードの例のセットを示す。 例示的な実施形態においてコンセンサスプロトコルの異なる変形形態のための擬似コードの例のセットを示す。 例示的な実施形態においてコンセンサスプロトコルに従って生成されたＤＡＧの例を示す。 例示的な実施形態においてコンセンサスプロトコルに従って生成されたＤＡＧの例を示す。

本発明の実施形態は、例えば、コンピュータネットワーク、もしくは他の配置のネットワーク、クライアント、サーバ、処理デバイスおよび他の構成要素を備える情報処理システムの形態で実装できる。このようなシステムの例示的な実施形態が、本明細書で詳細に説明される。しかしながら、本発明の実施形態はより一般的に、さまざまな他の種類の情報処理システムおよび関連するネットワーク、クライアント、サーバ、処理デバイスまたは他の構成要素に適用可能であると理解されるべきである。それに応じて、「情報処理システム」という用語は本明細書で使用される場合、これらのおよび他の配置を包含するように広く解釈されるものとする。「処理デバイス」という用語は本明細書で使用される場合、同様に、例えば、ロボットおよび他のオートマトンをさらに包含するように広く解釈されるものとする。

図１は、例示的な実施形態において、準安定ビザンチン合意用のコンセンサスプロトコルを実行する情報処理システム１００を示す。システム１００は、複数のコンセンサスプロトコルノード１０２－１、１０２－２、１０２－３、．．．１０２－Ｎを含む。コンセンサスプロトコルノード１０２は、ネットワーク１０５上で互いに通信を行うように構成されている。システム１００はさらに、それぞれのコンセンサスプロトコルノード１０２－１および１０２－２を介してネットワーク１０５に結合されているクライアントデバイス１０４－１および１０４－２、ならびにネットワーク１０５に直接結合されている追加のクライアントデバイス１０４－ｍ～１０４－Ｍを含む、複数のクライアントデバイス１０４を備える。多くの他の配置も可能である。

例えば、いくつかの実施形態では、クライアントデバイス１０４はそれぞれ、コンセンサスプロトコルノード１０２のうちの対応する１つを介してネットワーク１０５に結合されている。別の例として、１つ以上のクライアントデバイス１０４は、内部に組み込まれたコンセンサスプロトコルノード１０２のうちの対応する１つを有してもよい。

ネットワークに直接結合されたクライアントデバイス１０４－ｍ～１０４－Ｍはそれぞれ、例えば、さまざまな他の機能を実行するように構成された他の種類の内部構成要素と組み合わせて、その内部構成要素としてコンセンサスプロトコルノードを組み込むように構成できる。いくつかの実施形態では、ネットワークに直接結合されたクライアントデバイス１０４－ｍ～１０４－Ｍは完全に除去されている。

図１の実施形態におけるノード１０２およびクライアントデバイス１０４について使用される変数ｍ、ＭおよびＮのうちの所定のものは、本明細書の他の場所の他の状況では異なる方法で利用されることも留意すべきである。異なる意味は、それぞれの異なる状況から明らかになるであろう。

コンセンサスプロトコルノード１０２は、「処理ノード」と本明細書でより一般的に呼ばれるものの例であり、それぞれメモリに結合されたプロセッサを備える。いくつかの実施形態におけるこのような処理ノードは、それぞれの処理デバイスとして、あるいはそれぞれの処理デバイスの一部として実装されている。その用語が本明細書で広く使用される処理ノードの例は、コンピュータ、サーバおよび他の種類のマシンを含む。より特定の例として、いくつかの実施形態では、コンセンサスプロトコルノード１０２のうちの少なくともあるサブセットが各サーバとして実装されている。

コンセンサスプロトコルノード１０２はそれぞれ、以降でより詳細に説明されるように、コンセンサスプロトコルノード１０２のうちの他のものとのコンセンサスプロトコルに参加するように構成されている。所与の処理デバイスは、コンセンサスプロトコルノード、ならびに他の関係する機能を実装できる。

１つ以上のクライアントデバイス１０４はそれぞれ、例えば、ラップトップコンピュータ、タブレットコンピュータもしくはデスクトップパーソナルコンピュータ、携帯電話、または別の種類のコンピュータもしくは通信デバイス、組み込みデバイス、またはロボット、ならびに複数のそのようなデバイスの組み合わせを含むことができる。上記のように、いくつかの実施形態では、少なくとも１つのクライアントデバイスは、コンセンサスプロトコルノード１０２のうちの対応する１つを実装できる。クライアントデバイス１０４は例示的に、コンセンサスプロトコルノード１０２により処理されるトランザクションを生成する。クライアントデバイス１０４は、各「クライアント」と本明細書ではより一般的に呼ばれる。

システム１００のさまざまな要素間の通信は、図中のネットワーク１０５により集団で表現される１つ以上のネットワーク上で起こると仮定されている。ネットワーク１０５は例示的に、例えば、インターネットなどのグローバルコンピュータネットワーク、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、衛星ネットワーク、電話網もしくはケーブル網、セルラーネットワーク、Ｗｉ－ＦｉもしくはＷｉＭＡＸなどの無線プロトコルを使用して実装される無線ネットワーク、またはこれらのおよび他の種類の通信ネットワークのさまざまな部分もしくは組み合わせを含むことができる。

図に示されるように、コンセンサスプロトコルノード１０２－１は、プロセッサ１２０、メモリ１２２およびネットワークインターフェース１２４を備える。プロセッサ１２０は、メモリ１２２およびネットワークインターフェース１２４に動作可能に結合されている。プロセッサ１２０は、準安定ビザンチン合意用のコンセンサスプロトコルに関連した機能を実装するソフトウェアプログラムコード１２１を実行するように構成されている。

プロセッサ１２０は、例えば、マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、中央処理ユニット（ＣＰＵ）、算術ロジックユニット（ＡＬＵ）、グラフィックス処理ユニット（ＧＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、または他の同様の処理デバイス構成要素、ならびに他の種類および配置の処理回路を、任意の組み合わせで含んでもよい。また、プロセッサ１２０により実行されるソフトウェアプログラムコード１２１の少なくとも一部は、メモリ１２２に格納され、実行のためにプロセッサ１２０によりそこから取り出される。

対応するプロセッサにより実行するそのようなプログラムコードを格納する所与のそのようなメモリは、内部に具現化されたプログラムコードを有するプロセッサ可読ストレージ媒体と本明細書でより一般的に呼ばれるものの一例であり、例えば、ＳＲＡＭ、ＤＲＡＭもしくは他の種類のランダムアクセスメモリ、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ、磁気メモリ、光学メモリ、または他の種類のストレージデバイスなどの電子メモリを任意の組み合わせで含んでもよい。

このようなプロセッサ可読ストレージ媒体を含む製造品は、本発明の実施形態と考えられる。本明細書で使用される場合、「製造品」という用語は、一時的な伝播信号を除外すると理解されるべきである。

他の実施形態では、プロセッサ可読ストレージ媒体を含む他の種類のコンピュータプログラム製品を実装することもできる。

加えて、本発明の実施形態は、本明細書で開示されるように、準安定ビザンチン合意用のコンセンサスプロトコルに関連した処理動作を実行するように構成された処理回路を含む集積回路の形態で実装してもよい。

ネットワークインターフェース１２４は、コンセンサスプロトコルノード１０２－１が他のシステム要素とネットワーク１０５上で通信可能なように構成され、例示的に１つ以上の従来の送受信器を備える。

コンセンサスプロトコルノード１０２－１はさらに、サブサンプリングされたポーリングモジュール１３０、確信度および／または信頼度カウンタ１３２、ならびに既知のトランザクション１３４の有向非巡回グラフ（ＤＡＧ）を備える。コンセンサスプロトコルノード１０２－１のサブサンプリングされたポーリングモジュール１３０、カウンタ１３２およびＤＡＧ１３４のうちの１つ以上の少なくとも一部は、メモリ１２２に格納され、プロセッサ１２０により実行されるソフトウェアを少なくとも部分的に利用して実装できる。例えば、本明細書で開示される準安定ビザンチン合意用のコンセンサスプロトコルは例示的に、サブサンプリングされたポーリングモジュール１３０を使用してコンセンサスプロトコルノード１０２のうちの他のものをサンプリングすること、ならびにカウンタ１３２およびＤＡＧ１３４を管理することを含む。

既に示したように、「有向非巡回グラフ」またはＤＡＧという用語は本明細書で使用される場合、広く解釈されるものとする。その上、さまざまな非ＤＡＧデータ構造を他の実施形態で使用することもでき、例えば、シングルトン判定を含む実施形態では、ＤＡＧまたは他のデータ構造の使用を完全に除去することもできる。したがって、ＤＡＧ１３４は、他の実施形態では、他の種類のデータ構造に置き換えることも、完全に除去することもできると理解されたい。

システム１００の他のコンセンサスプロトコルノード１０２はそれぞれ、コンセンサスプロトコルノード１０２－１に対して上で説明したものと同様の方法で構成されていると仮定されている。他の実施形態では、他の処理ノード構成を使用することもできる。

動作中、コンセンサスプロトコルノード１０２はそれぞれ、本明細書で開示される種類のコンセンサスプロトコルを実行する際に、コンセンサスプロトコルノード１０２のうちの他のものの選択されたサブセットと相互作用する。例えば、そのサブサンプリングされたポーリングモジュール１３０を介したコンセンサスプロトコルノード１０２－１は、他のコンセンサスプロトコルノード１０２のそれぞれ選択されたサブセットの繰り返しポーリングを実行し、繰り返しポーリングの結果に応答して、所与のトランザクションの状態を、その所与のトランザクションの複数の可能な状態のうちの特定の１つに解決し、所与のトランザクションの解決された状態に少なくとも部分的に基づいて少なくとも１つの自動アクションを開始する。繰り返しポーリングは、確率的に（すなわち、ランダムに）または決定論的に選択されたノードのサブセットを超えてもよい。

いくつかの実施形態では、所与のトランザクションは暗号通貨トランザクションを含むが、さまざまな他の種類のトランザクションをサポートすることもできる。したがって、「トランザクション」という用語は本明細書で使用される場合、広く解釈されるものとする。例えば、その用語が本明細書で広く使用されるように所与のトランザクションの状態を解決することは、変数の複数の可能な値のうちの特定の１つを判定すること、コマンドまたはスクリプトが実行されるべきか否かを判定することなどを含むことができる。したがって、所与のトランザクションは、システム１００のコンセンサスプロトコルノード１０２による可能な状態のうちの特定の１つへのコンセンサスベースの解決に好適な複数の可能な状態を有する任意の種類の情報要素を備えることができる。

図２～４とともに以降で説明される例示的な実施形態では、所与のトランザクションを解決することは、例えば、コンセンサスプロトコルの動作を通して、変数に対する｛赤色もしくは青色｝または｛承認もしくは拒否｝のいずれかなどの特定の値を判定することを含む。図５～９とともに以降で説明される他の実施形態は、より一般的にトランザクションを指す。

この点では、いくつかの実施形態は、多値コンセンサスおよび／または多重トランザクションコンセンサス、ならびに異なる数の候補を含む他の配置をサポートするように構成できることを理解されたい。それに応じて、例示的な実施形態は、１つ、２つ、または２つより多くの候補の間で状態を解決することができ、本明細書で開示される任意の特定の２価の例に限定されるとみなすべきではない。

コンセンサスプロトコルノード１０２は例示的に、多数方向に集団で「従う」ように構成され、言い換えると、図２～４の変数に対する赤色または青色の状態など、所与のトランザクションの特定の状態に関する所定のコンセンサスに「倒れる」ように構成されている。したがって、コンセンサスプロトコルノード１０２の相互作用により、いったんコンセンサスに到達すると、所与のトランザクションの状態は複数の可能な状態のうちの特定の１つに解決される。その解決前の所与のトランザクションの状態は、本明細書では「準安定」状態とも呼ばれる。この種の一実施形態におけるコンセンサスプロトコルは、準安定コンセンサスプロトコルと本明細書では呼ばれる。

そのような実施形態におけるコンセンサスプロトコルノード１０２はそれぞれ例示的に、所与のトランザクションの初期状態を選択、確立、あるいは判定し、他のコンセンサスプロトコルノード１０２の異なるサブセットを繰り返しサンプリングし、ノードのそれらのサンプリングされたサブセットにより現在有利な特定の状態を判定し、しきい値が満たされた場合、多数の状態優先度に従う。この繰り返しサンプリングは例示的に、すべてのコンセンサスプロトコルノード１０２により実質的に同時に実行され、それらのノードはそれぞれ、そのノードのうちの他のものに対してサブサンプリングされたポーリングを実行する。可能性が高いコンセンサスプロトコルノード１０２は最終的に、所与のトランザクションの特定の状態に関するコンセンサスに到達するであろう。上記のように、コンセンサスプロトコルノード１０２がその状態に関するコンセンサスに到達するまで、その状態は未解決のままである。しかしながら、それは、例えば、「未知」から「可能性が高い」、「承認」、あるいは解決まで時間的に発展できる。

例示的な実施形態における準安定コンセンサスプロトコルは、本明細書の他の場所でより詳細に説明されるように、ビザンチン障害耐性を提供するように構成されている。

所与のトランザクションの解決された状態に少なくとも部分的に基づいて開始される自動アクションは、分散台帳の保守に関連したさまざまなアクションを含むことができるが、コマンドまたはスクリプトの実行を開始するなど、多くの他の自動アクションを実行することもできる。

例えば、いくつかの実施形態では、所与のトランザクションの解決された状態に少なくとも部分的に基づいて、コンセンサスプロトコルノード１０２－１により開始される自動アクションは、第１のコンセンサスプロトコルノード１０２－１、およびコンセンサスプロトコルノード１０２のうちの他のものにより集団で管理された分散台帳に、所与のトランザクションを特徴付けるエントリーを追加することを含む。

暗号通貨を含むいくつかの実施形態では、この種の配置におけるエントリーは例示的にブロックを備え、分散台帳はブロックチェーンを備える。所与のこのようなブロックチェーンは典型的には、所定数の線形連鎖ブロックとしてモデル化されるが、本明細書における例示的な実施形態はより一般的に、トランザクションおよび／またはコントラクトに対する情報を保持する構造化ブロックの任意の配置を潜在的に包含するブロックチェーンを指す。したがって、本明細書におけるブロックチェーンを含む実施形態は、線形連鎖ブロックに限定されるとみなすべきではない。

いくつかの実施形態におけるブロックチェーンは、コンセンサスプロトコルノード１０２により集団で管理される暗号通貨ブロックチェーンを含む。そのような実施形態では、所与のトランザクションは、例えば、指定された量の暗号通貨を暗号通貨アドレスに関連付けるために利用されるブロックチェーントランザクションを含むことができる。

上で示したように、「ブロックチェーン」という用語は本明細書で使用される場合、分散台帳および他の同様の配置を包含するように広く解釈され、それらは相互に関連するデータブロックを含む暗号化動作を実行する複数の処理デバイスにより集団で管理されるものとする。

したがって、本明細書の実施形態で使用されるブロックチェーンは、例えば、任意のユーザーがブロックチェーントランザクションの検証用のコンセンサス構築に参加できる「非許可型」つまり公開ブロックチェーン、ならびにユーザーの制限されたセットのみがブロックチェーントランザクションの検証用のコンセンサス構築に参加できる「許可型」つまりプライベートブロックチェーンを含むことができる。いくつかの実施形態では、参加者のセットは、Ｓｙｂｉｌ制限機構を使用して制限でき、その機構は例示的に、単一のユーザーが表現可能な識別子の数を制限するために参加者がリソースを提示することを要求し、プルーフオブワーク、プルーフオブステーク、プルーフオブオーソリティ、プルーフオブスペース、プルーフオブタイム、プルーフオブエラプスドタイムなど、ならびにそれらの組み合わせを含んでいる。

いくつかの実施形態における所与のブロックチェーンは、１つ以上のスマートコントラクトプログラムを備えることができる。ブロックチェーンのこのようなスマートコントラクトプログラムはそれ自体、複数の別個のプログラムを含んでもよい。

他の実施形態は、本明細書で開示される種類の準安定ビザンチン合意用のコンセンサスプロトコルを利用し、ブロックチェーンを含まない支払いまたは他のトランザクションを処理するように構成できる。

いくつかの実施形態では、コンセンサスプロトコルにおけるコンセンサスプロトコルノード１０２の特定のものの参加は、コンセンサスプロトコルノード１０２のそれぞれによる１つ以上の指定されたプルーフの提出を要求する少なくとも１つの規定の制御機構に従って制御されている。いくつかの実施形態における指定されたプルーフは例示的に、上記のプルーフオブステークまたはプルーフオブオーソリティなどのプルーフオブワーク以外のプルーフを含む。しかしながら、いくつかの実施形態は制御機構としてプルーフオブワークを利用するように構成できることを理解されたい。本明細書の例示的な実施形態における所与のそのようなプルーフは、所定の従来のプロトコルのようなコンセンサスを達成するために利用されるのではなく、Ｓｙｂｉｌ攻撃の問題に対処するために利用される。

サブサンプリングされたポーリングモジュール１３０により実行される繰り返しポーリングは例示的に、所定数の反復に対して繰り返される。いくつかの実施形態では、反復の数は、コンセンサスプロトコルノード１０２の数のほぼ対数であるが、そのような配置は必須ではない。他の実施形態では、他の種類の繰り返しポーリングを使用することもできる。「サブサンプリングされたポーリング」などの用語は本明細書で使用される場合、例えば、コンセンサスプロトコルノード１０２－１が、他のコンセンサスプロトコルノード１０２の異なるサブセットをランダムにまたは他の方法で選択し、複数のポーリング間隔のそれぞれにおいてポーリングを行う配置を包含するように広く解釈されるものとする。

そのようなポーリングは、ポーリング間隔のそれぞれにおいてコンセンサスプロトコルノード１０２－１によりポーリングされる他のコンセンサスプロトコルノード１０２の数が、システム内の他のコンセンサスプロトコルノード１０２の総数であるＮ－１より少ないという点で「サブサンプリングされた」と考えられる。例えば、特定のポーリング間隔でポーリングを行うために選択されるコンセンサスプロトコルノード１０２の所与のサンプルは例示的に、擬似乱数発生器（ＰＲＮＧ）または他の同様の配置を使用してランダムに例示的に選択される確率的サンプルを含む。この種の実施形態は本明細書では、確率的ポーリングを実行すると呼ばれる。別の例として、可能であればシードを使用してサンプルを決定論的に選択することもできる。そのような決定論的サンプリング配置では、任意の決定論的機能を使用してもよい。したがって、例示的な実施形態は、ポーリング用のコンセンサスプロトコルのサブセットを選択するために使用される特定の種類のサンプリングについては限定されない。

この点では、本明細書で開示される例示的な実施形態においてポーリングされるノードの数は典型的には、従来のＢＦＴプロトコルに含まれるノードの数よりはるかに少ないことにも留意すべきである。例えば、従来のＢＦＴプロトコルは通常、Ｎ個のノードの少なくとも約２／３、または可能であればＮ個のノードの２／３を超える関与を要求するが、本明細書で開示される例示的な実施形態は、Ｎ個のノードの非常にわずかな部分のサブサンプリングされたポーリングを利用するように構成でき、それにより従来のＢＦＴプロトコルに対して著しい利点を提供する。

また、コンセンサスプロトコルノード１０２は、集団で「ネットワーク」と呼ばれ、サブサンプリングされたポーリングは「ネットワークをサンプリングする」と呼ばれる。コンセンサスプロトコルノードのこのようなネットワークを含むシステム１００などの情報処理システムは、単に「システム」とも本明細書では呼ばれる。

いくつかの実施形態におけるコンセンサスプロトコルノード１０２－１は、繰り返しポーリングの結果を利用して、既知のトランザクションのＤＡＧ１３４を管理するように構成されている。ＤＡＧ１３４は例示的に、所与のトランザクションと複数の他のトランザクションとの間の関係を特徴付ける。ＤＡＧ１３４は、既知のトランザクションを特徴付ける「データ構造」と本明細書でより一般的に呼ばれるものの一例である。他の実施形態においてＤＡＧ１３４の代わりに使用可能な他の種類のデータ構造は、例えば、トランザクションのリンクリストおよびトランザクションのハッシュリンクチェーンを含む。そのようなデータ構造は、ツリーベース形式を含む、さまざまな異なる種類の形式を取ることができ、例示的な実施形態はこの点では限定されない。

いくつかの実施形態では、ＤＡＧ１３４自体は、トランザクションの競合を解決するだけでなく、一貫した全順序ログがネットワーク全体で複製されるプラットフォームを提供するように構成された線形順序連鎖データ構造の形態で実装される。このような一実施形態におけるログの各エントリーは、指定された汎用ユーザーデータのコンテナとして機能してもよい。例えば、アプリケーションの状態遷移は、各コンテナ内のコマンドとしてエンコードできる。したがって、正しいノードは一貫して複製されたアプリケーション状態を有し、サービスに障害耐性を提供するであろう。

「有向非巡回グラフ」という用語は本明細書で使用される場合、そのようなデータ構造を包含するように広く解釈されるものとする。他の実施形態は、所与のトランザクションの状態を解決する際に、既知のトランザクションのＤＡＧまたは他のデータ構造を管理あるいは利用する必要がないことも理解されたい。

いくつかの実施形態では、繰り返しポーリングの結果に応答して所与のトランザクションの状態を解決することは、繰り返しポーリングの結果を利用して、所与のトランザクションを正当なトランザクションとして承認すべきか否かの判定を行うことを含む。この点では、不当なトランザクションは決して承認できないが、すべての正当なトランザクションが承認されるわけではないことも留意すべきである。したがって、正当なトランザクションは、例えば、少なくとも２つの状態｛承認または拒否｝をその可能な状態として有することができる。より一般的には、この例では３つの可能な状態、すなわち、承認、拒否および未定があり、未定は最初の２つの状態のいずれにもまだ到達していないことを示す。

既に示したように、繰り返しポーリングの結果に応答して所与のトランザクションの状態を解決することは、変数の複数の可能な値のうちの特定の１つを判定すること、コマンドまたはスクリプトを実行するべきか否かを判定することなどを含むことができる。コンセンサスベースの解決に従うこれらのおよびさまざまな他の種類のトランザクションは、他の実施形態において使用することもできる。それに応じて、正当なトランザクションとして所与のトランザクションを承認することは、所与のトランザクションに対して「状態を解決すること」と本明細書でより一般的に呼ばれるものの一例と考えられる。その用語が本明細書で広く使用される所与のトランザクションの状態を解決することとともに、さまざまな他の配置を使用することもできる。したがって、トランザクションを承認することを指す例示的な実施形態は、トランザクションの状態が解決される特定の方法をいずれにせよ限定するとみなすべきではない。

上記のように、繰り返しポーリングは例示的に複数反復（複数のループを）繰り返される。いくつかの実施形態におけるコンセンサスプロトコルノード１０２－１により実行される反復のうちの所与の反復は、より具体的には、他のコンセンサスプロトコルノード１０２のサンプルを選択すること、および選択されたコンセンサスプロトコルノード１０２のそれぞれにクエリを送信することを含む。

クエリに対する少なくともしきい値数の応答の受信に応答して、コンセンサスプロトコルノード１０２－１は、受信した応答の少なくとも指定した部分が、コンセンサスプロトコルノード１０２－１における所与のトランザクションの現在の状態と異なる所与のトランザクションの特定の状態を示すか否かを判定する。代替的に、特定のタイムアウトに到達する前にしきい値数の応答が受信されない場合、このような判定は特定のタイムアウトに到達することに応答して行うことができる。

受信した応答の指定した部分が、コンセンサスプロトコルノード１０２－１における所与のトランザクションの現在の状態と異なる所与のトランザクションの特定の状態を示すことに応答して、コンセンサスプロトコルノード１０２－１は、第１の処理ノードにおける所与のトランザクションの現在の状態を特定の状態に更新する。

このような実施形態では、繰り返しポーリングの結果に応答して所与のトランザクションの状態を例示的に解決することは例示的に、複数反復の完了時に所与のトランザクションの状態を現在の状態に解決することを含む。

いくつかの実施形態におけるコンセンサスプロトコルノード１０２－１は、所与のトランザクションの状態を解決する際に１つ以上のカウンタ１３２を利用する。カウンタ１３２は例示的に、少なくとも１つの確信度カウンタおよび／または少なくとも１つの信頼度カウンタを含む。

例えば、いくつかの実施形態では、コンセンサスプロトコルノード１０２－１は、繰り返しポーリングの所定数の連続的な反復を示す確信強度カウンタを管理し、そのため、受信した応答の少なくとも指定した部分が所与のトランザクションの特定の状態を示す。このような実施形態において繰り返しポーリングの結果に応答して所与のトランザクションの状態を解決することは例示的に、確信強度カウンタがしきい値を超えたことに応答して所与のトランザクションの状態を特定の状態に解決することを含む。

追加的にまたは代替的に、コンセンサスプロトコルノード１０２－１は、所与のトランザクションの可能な状態のそれぞれの信頼度カウンタを管理し、信頼度カウンタはそれぞれ、対応する状態を示す応答を生成した反復のうちの複数の反復へのクエリの総数を示す。そのような実施形態における繰り返しポーリングの結果に応答して所与のトランザクションの状態を解決することは例示的に、その可能な状態の信頼度カウンタが可能な状態のうちの少なくとも１つの他のものの信頼度カウンタを超えることに応答して、所与のトランザクションの状態を可能な状態のうちの１つに解決することを含む。

所与のトランザクションに対して２つより多くの可能な状態があるこの種のいくつかの実施形態では、所与のトランザクションの状態を解決することは例示的に、その可能な状態の確信度カウンタが他の可能な状態のすべての信頼度カウンタを超えることに応答して、所与のトランザクションの状態を２つより多くの可能な状態のうちの１つに解決することを含む。他の実施形態は、所与のトランザクションの状態を解決するための追加のまたは代替的な要件を規定してもよい。

いくつかの実施形態では、応答の指定した部分がトランザクションの特定の状態を示すポーリングは、複数の他の、可能であれば関係するトランザクションの特定の状態を暗黙的に示してもよい。例えば、第１のユーザーのＡｌｉｃｅが第２のユーザーのＢｏｂに彼女の暗号通貨のコインのすべてを支出したとシステムが判定した場合、彼女が第３のユーザーのＣｈａｒｌｉｅにそれらを支出しなかったと同時に判断してもよい。

上記のように、例示的な実施形態におけるコンセンサスプロトコルノード１０２－１は、既知のトランザクションのＤＡＧ１３４を管理する。ＤＡＧ１３４は、所与のトランザクションと複数の他のトランザクションとの間の関係を特徴付ける。この種のいくつかの実施形態では、トランザクションは互いに排他的な競合セットに分割され、ここで競合という概念は、アプリケーションで定義され、したがって、処理されるトランザクションの特定の種類などの要因に基づいて実施形態ごとにさまざまであってもよい。互いに競合するトランザクションは、競合セットを形成すると本明細書では呼ばれ、そのうちの単一のトランザクションのみを承認できる。競合セットの単一のトランザクションをそのように承認することは、そのトランザクションの「状態を解決すること」と本明細書ではより一般的に呼ばれるものの一例である。

そのような実施形態においてＤＡＧ１３４を管理することは、より具体的には、コンセンサスプロトコルノード１０２のサンプルを選択すること、選択されたコンセンサスプロトコルノード１０２のそれぞれにクエリを送信すること、およびクエリへの応答に少なくとも部分的に基づいてＤＡＧ１３４を更新することを含む。例えば、ＤＡＧ１３４を更新することは、１つ以上の追加のトランザクションをＤＡＧ１３４に挿入すること、ＤＡＧ１３４のトランザクションのそれぞれの信頼度値を更新すること、および／またはＤＡＧ１３４のトランザクションを相互排他的な競合セットに再分割することを含む。そのような実施形態において繰り返しポーリングの結果に応答して所与のトランザクションの状態を解決することは例示的に、所与のトランザクションがその競合セット内の唯一のトランザクションであり、所与のトランザクションがしきい値を超える信頼度値を有することに応答して状態を解決することを含む。別の例として、繰り返しポーリングの結果に応答して所与のトランザクションの状態を解決することは、その可能な状態の信頼度カウンタが可能な状態のうちの少なくとも１つの他のものの信頼度カウンタを超えることに応答して、その状態を複数の可能な状態のうちの１つに解決することを含む。

上記のように、他のコンセンサスプロトコルノード１０２はそれぞれ、コンセンサスプロトコルノード１０２－１に対して上で説明したものと同様の方法で動作するように例示的に構成され、コンセンサスプロトコルノード１０２が、所与のトランザクションの複数の可能な状態の中から所与のトランザクションの特定の状態へのコンセンサスに集団で到達可能にする。

図１に示した構成要素および他のシステム要素の特定の配置は、例示的なものとしてのみ提示され、多くの代替的な実施形態が可能であることを理解されたい。例えば、コンセンサスプロトコルノード１０２およびクライアントデバイス１０４のうちの１つ以上はそれぞれ、暗号通貨アカウントに関連した暗号通貨支払いを行うかまたは受け取ることとともに利用される暗号通貨ウォレットなど、追加のまたは代替的な構成要素を含むことができる。また、既に示したように、システム１００の所与の処理デバイスはいくつかの実施形態では、コンセンサスプロトコルノードおよびクライアントデバイスの両方を含むことができる。ブロックチェーンノードなどの他の種類の処理ノードを追加的にまたは代替的に使用することもできる。処理ノードおよび関連する処理デバイスの多くの代替的な配置を使用することもできる。

例示的な実施形態は、ブロックチェーンもしくは暗号通貨、または任意の他の特定の種類のトランザクションでの使用に限定されないことも理解するべきである。それに応じて、本明細書で開示される種類の準安定コンセンサスプロトコルは、さまざまな他の種類のトランザクションで使用するために直接的な方法で適用できる。したがって、「トランザクション」という用語は本明細書で使用される場合、例えば、実行されるコマンドもしくはスクリプト、または開示されるコンセンサスプロトコルを使用して解決することに好適な任意の他の種類の情報要素を包含するように広く解釈されるものとする。

ここで、図２～９を参照しながら、例示的な実施形態の動作に関する追加の詳細が説明される。この実施形態は、Ｓｌｕｓｈ、Ｓｎｏｗｆｌａｋｅ、ＳｎｏｗｂａｌｌおよびＡｖａｌａｎｃｈｅと呼ばれる変形形態を含む準安定コンセンサスプロトコルの一例のファミリーを含む。これらのプロトコルの変形形態は、それぞれの例示的な実施形態と考えられるため、以降で説明されるそれらの対応する実装の特定の詳細は、いずれにせよ限定するものと解釈されるべきではない。このようなプロトコルの変形形態は、既に説明したようにシステム１００の準安定コンセンサスプロトコル配置のより詳細な実装とみなすこともできる。

既に示したように、従来のＢＦＴプロトコルは、ＢｉｔｃｏｉｎおよびＥｔｈｅｒｅｕｍなどの暗号通貨で利用されるＮａｋａｍｏｔｏコンセンサスプロトコルを含む。分散処理ノードのセット内で合意を達成することはより一般的には、数十億人にサービスを提供するインターネット規模のサービスから数十億ドルの価値のある暗号通貨まで、無数のアプリケーションのコアにある。

現在まで、この問題に対して２つの主要な解決策のファミリーがある。従来のコンセンサスプロトコルは、オールツーオール通信に依存し、すべての正しいノードが絶対的な確実性で同じ意思決定に到達することを保証する。２次の通信オーバーヘッドおよび正確なメンバーシップの知識を要求するため、多数の参加者まで大規模化することは困難であった。

一方、Ｎａｋａｍｏｔｏコンセンサスプロトコルは確率的な安全性保証を提供する。Ｎａｋａｍｏｔｏコンセンサスの意思決定は、ある程度の確率εで元に戻る場合がある。プロトコルパラメータにより、この確率を任意に小さく表現でき、価値の高い金融システムをこの基盤上に構築できる。このファミリーは、任意のノードがいつでもシステムに参加できるオープンで無許可のセッティングに自然に適合する。それでも、これらのコンセンサスプロトコルはコストがかかり、無駄が多く、性能が制限される。意思決定が行われない場合でも、それらのセキュリティはマイナーによる一定の参加に依存しているという点で、構築により、それらは静穏になることができない。現在、Ｂｉｔｃｏｉｎに関連するマイニングは、約６０ＴＷｈ／年の速度でエネルギーを消費する。その上、これらのおよび他の従来のＢＦＴコンセンサスプロトコルは、単純な再パラメータ化により克服することが困難な固有の拡張性ボトルネックに苦しんでいる。

以降の図２～９とともに説明される例示的な実施形態は、コンセンサスプロトコルの新しいファミリーを提供する。ゴシップアルゴリズムにより触発され、このファミリーは意図的な準安定機構によりその安全性を獲得する。具体的には、システムはランダムにネットワークを繰り返しサンプリングし、同じ結果に向かって正しいノードを導くことにより動作する。分析により、この準安定機構は強力であり、大きなネットワークを事実上不可逆的な状態に素早く移動できることがわかる。

Ｎａｋａｍｏｔｏコンセンサスと同様に、これらの例示的な実施形態におけるプロトコルファミリーは、コンセンサス障害の可能性を任意に小さくできる調節可能なセキュリティパラメータを使用して確率的な安全性保証を提供する。Ｎａｋａｍｏｔｏコンセンサスとは異なり、このプロトコルは環境に優しく、静穏で効率的であり、プルーフオブワークに依存せず、意思決定を行わないときエネルギーを消費しない。これらの例示的な実施形態におけるプロトコルの効率は少なくとも部分的に、各ノードが、ある小さなセキュリティパラメータｋに対してＯ（ｋ×ｌｏｇ（ｎ））～Ｏ（ｋ）の範囲の通信オーバーヘッドを要求し（一方、リーダーベースのコンセンサスプロトコルは、Ｏ（ｎ）通信を要求する１つ以上のノードを有する）、かつこのプロトコルは依存するトランザクションの間で半順序のみを確立するという特徴による。

以降でより詳細に説明されるように、これらの実施形態におけるコンセンサスプロトコルは例示的に、「善良な」トランザクション、すなわち、正しいクライアントにより発行されたものに対してのみ生存性を保証するように構成され、したがって、他のトランザクションと競合しないことが保証される。暗号通貨のセッティングでは、暗号化署名は、鍵の所有者のみが特定のコインを支出するトランザクションを作成できることを強いる。正しいクライアントは規定どおりのプロトコルに従うため、安全性および生存性の両方が保証される。一方、説明されるプロトコルは、互いに競合するビザンチンクライアントにより提出された悪意あるトランザクションの生存性を保証しない。そのような意思決定はネットワークを失速させる場合があるが、善良なトランザクションには安全上影響しない。これは合理的なトレードオフであり、その結果得られるシステムは複雑な支払いシステムを構築するのに十分であることを示す。

それに応じて、例示的な実施形態は、ランダム化されたサンプリングおよび準安定な意思決定に基づいてコンセンサスプロトコルの新しいファミリーに、強力な確率的安全性保証、および正しいクライアントの生存性保証を提供する。

以降のプロトコルファミリーの説明は、すべて同じ共通の準安定機構に基づいて、非ビザンチンプロトコルであるＳｌｕｓｈから始まり、Ｓｎｏｗｆｌａｋｅ、ＳｎｏｗｂａｌｌおよびＡｖａｌａｎｃｈｅを徐々に構築する。Ｓｌｕｓｈ、ＳｎｏｗｆｌａｋｅおよびＳｎｏｗｂａｌｌは、堅牢性を高める単一規則のバイナリコンセンサスプロトコルであり、ＡｖａｌａｎｃｈｅはＳｎｏｗｂａｌｌを完全な暗号通貨ソリューションに拡張する。他の用途に対して他の拡張が可能であることは当業者に明らかであろう。

ＢｉｔｃｏｉｎのＮａｋａｍｏｔｏコンセンサスと同様に、確率的な安全性保証を採用する。εを適切に小さく選択することで、コンセンサス障害を事実上実行不可能にし、ＣＰＵの計算ミスまたはハッシュ衝突よりも少ない頻度にできるため、この確率的保証は、実際には従来の安全性保証と区別できない。

このプロトコルファミリーは集団で、システムが有用なＢｉｔｃｏｉｎのような暗号通貨を実装することを可能にするが、性能および拡張性は劇的によくなる。他の実施形態では、大規模な確率的コンセンサスを含む他のアプリケーションを構築することもできる。それが課す多くの課題のため、これらの例示的な実施形態では暗号通貨用途に集中する。

正しいノードＣおよびビザンチンノードＢから構成されたノードＮの集まりを仮定し、ここでｎ＝｜Ｎ｜である。例示的な目的で、Ｂｉｔｃｏｉｎの未使用トランザクション出力（ＵＴＸＯ）モデルとして共通に知られているものを採用する。このモデルでは、クライアントが認証され、既存のＵＴＸＯを完全に消費し、新しいＵＴＸＯを発行する暗号署名トランザクションを発行する。ノードとは異なり、クライアントは意思決定処理に参加せず、コンセンサスプロトコルを実行するノードにトランザクションを供給するだけである。同じＵＴＸＯを消費し、異なる出力を生成する場合、２つのトランザクションが競合する。正しいクライアントは競合するトランザクションを発行することは決してなく、ビザンチンクライアントが正しいクライアントにより発行されたトランザクションとの競合を偽造することもできない。しかしながら、ビザンチンクライアントは、互いに競合する複数のトランザクションを発行でき、正しいクライアントは、それらのトランザクションのうちの１つを消費できるだけである。したがって、これらの例示的な実施形態におけるコンセンサスプロトコルのファミリーの目的は、ビザンチン挙動の存在下で競合しないトランザクションのセットを承認することである。各クライアントは、トランジションが承認されたトランザクションの全順序リストにより定義される複製状態マシン（ＲＳＭ）と考えることができる。同様に、所与のトランザクションに対してそのように承認することは、所与のトランザクションの「状態を解決すること」と本明細書でより一般的に呼ばれるものの一例である。

プロトコルファミリーは、高い確率（「ｗｈｐ」）で以降の保証を提供する。

プロパティＰ１：安全性。２つの正しいノードが競合するトランザクションを承認することはないであろう。

プロパティＰ２：生存性。正しいクライアントにより発行される任意のトランザクション（「善良なトランザクション」）は最終的に、あらゆる正しいノードにより承認されるであろう。

無条件の合意の代わりに、我々の方式は、安全性が確率１－εで維持されることを保証し、ここでセキュリティパラメータεの選択はシステム設計者およびアプリケーションの制御下にある。

例示的な実施形態に対するこの分析は、強力な適応的敵対者、例えば、ネットワーク内のあらゆるノードの内部状態および通信を観察できるが、正しいノード間の通信に干渉できない敵対者を仮定している。ネットワークのすべてのメンバーがすべての参加者に知られているとは仮定していないが、むしろネットワークの視点では一時的にいくつかの相違を有する場合がある。Ｂｉｔｃｏｉｎと同様に、ノードが十分に多くの正しいノードと接続し、ネットワークの統計的に偏りのない視点を取得できる安全なブートストラッピングシステムを仮定している。公開鍵基盤（ＰＫＩ）は仮定していない。公開鍵署名およびハッシュ関数に関係した標準的な暗号硬度を仮定している。

図２は、例示的な実施形態において、Ｓｌｕｓｈと本明細書では呼ばれる単純な準安定プロトコルを示す。Ｓｌｕｓｈはビザンチン障害に対する耐性はないが、以降のＢＦＴプロトコルの例示として提供する。解説を容易にするために、赤色および青色の２つの競合する色の間の意思決定を使用してＳｌｕｓｈの動作を説明する。ある変数に対する複数の可能な値に関するこの意思決定は、所与のトランザクションの状態を解決するものと本明細書でより一般的に呼ばれるものの一例である。

Ｓｌｕｓｈでは、ノードは最初、無色の状態で開始する。クライアントからトランザクションを受信すると、無色のノードは、それ自体の色をトランザクションで保持されるものに更新し、クエリを開始する。クエリを実行するために、ノードは、ランダムで均一にネットワークの小さな一定サイズ（ｋ）のサンプルを選択し、クエリメッセージを送信する。クエリを受信すると、無色のノードはクエリ内の色を採用し、その色で応答し、それ自体のクエリを開始するが、色付きのノードは現在の色で応答するだけである。いったんクエリ中のノードがｋ個の応答を収集するか、または特定のタイムアウトに到達した後、同じ色に対して一部がαｋ以上であるか否かをチェックし、ここで、０．５より大きなαがプロトコルパラメータである。αｋのしきい値が満たされ、サンプリングされた色がノード自体の色と異なる場合、ノードはその色に反転する。その後、クエリステップに戻り、合計ｍ回のラウンドに対してクエリの以降のラウンドを開始する。最後に、ノードは時刻ｍで終了した色を判定する。タイムアウトは読みやすさのために図から省略されていることも留意すべきである。

この単純なプロトコルは、所定数の好ましいプロパティを有する。第１に、それはほとんどメモリレスであり、ノードは、その現在の色以外にラウンド間の状態を保持せず、特に他のピアとの相互作用の履歴を管理しない。第２に、あらゆる参加者にクエリを行う従来のコンセンサスプロトコルとは異なり、あらゆるラウンドが、ランダムにネットワークの小さな一定サイズのスライスだけをサンプリングすることを含む。第３に、ネットワークが５０／５０の赤色－青色分割の準安定状態で開始しても、サンプリングにおけるランダムな摂動により１つの色がややエッジを得ることになり、その後の繰り返しサンプリングがその不均衡を蓄積し、増幅するであろう。最後に、ｍが十分高く選択されている場合、Ｓｌｕｓｈは、すべてのノードがｗｈｐで同じく着色されることを保証する。各ノードは、ラウンドごとに一定の予測可能な通信オーバーヘッドを有し、ｍはｎとともに対数的に増大する。

Ｓｌｕｓｈプロトコルは、ビザンチンノードの存在下での強力な安全性保証を提供しない。特に、正しいノードが１つの色に対する優先度を生成する場合、ビザンチン敵対者はノードを反対の色に反転させ、ネットワークのバランスを保持し、意思決定を妨げるように試みることができる。より多くの状態ストレージをノードに導入する我々の第１のＢＦＴプロトコルでこれに対処する。

図３は、既に説明したＳｌｕｓｈプロトコル上に構築されたＢＦＴを有する準安定コンセンサスプロトコルを示す。Ｓｎｏｗｆｌａｋｅは、その現在の色においてノードの確信強度を捕捉する単一のカウンタでＳｌｕｓｈを補強する。このようなカウンタは、「確信度カウンタ」と本明細書で呼ばれるものの一例である。このノードごとのカウンタは、そのノードによるネットワークの連続的なサンプルがすべて同じ色を生成した数を格納する。そのカウンタが別のセキュリティパラメータであるβを超えると、ノードは現在の色を承認する。図３のプロトコルは、以降の修正を含む。
１．各ノードはカウンタｃｎｔを管理する。
２．色が変化するたびに、ノードはｃｎｔを０にリセットする。
３．ノードと同じ色に対してαｋ個以上の応答を生成するあらゆるクエリが成功すると、ノードはｃｎｔを増加させる。

プロトコルがビザンチンノードの所与のしきい値および所望のε保証に対して正しくパラメータ化される場合、プロパティＰ１（安全性）およびプロパティＰ２（生存性）の両方を保証できる。後で示すように、それ以降は正しいノードが２価の状態より意思決定に向かう傾向が高い位相シフト点が存在する。さらに、それ以降は意思決定が避けられない帰還不能点が存在する。ビザンチンノードは位相シフトを超えると制御を失い、正しいノードは帰還不能点を超えると関与を開始し、同じ色のｗｈｐを採用する。

図４は、Ｓｎｏｗｂａｌｌと呼ばれる次のプロトコルを示すが、それはＳｎｏｗｆｌａｋｅに信頼度の表示を追加する。Ｓｎｏｗｆｌａｋｅの状態の概念は一時的であり、カウンタは色が反転するたびにリセットされる。理論的には、このプロトコルは最低限の状態で強力な保証を行うことができるが、ここではより永続的な信用の概念を組み込むことにより攻撃がより困難になるようにプロトコルを改善する。Ｓｎｏｗｂａｌｌは、図に示すように、それらの対応する色のしきい値結果を生成したクエリの数を捕捉する信頼度カウンタでＳｎｏｗｆｌａｋｅを補強する。ノードは、ある色に対してβ個の連続的な「チット」を取得するか否かを判定するが、そのようなチットは、本明細書の他の場所でより詳細に説明される。しかしながら、ノードは、未収の信頼度の合計に基づいて優先度を変更するだけである。ＳｎｏｗｆｌａｋｅとＳｎｏｗｂａｌｌの違いは次のとおりである。
１．クエリが成功するごとに（すなわち、ノードの色に一致する少なくともαｋ個の応答で）、ノードはその色に対するその信頼度カウンタを増加させる。
２．その現在の色における信頼度が新しい色の信頼度値よりも低くなると、ノードは色を切り替える。

Ｓｎｏｗｂａｌｌは、Ｓｎｏｗｆｌａｋｅよりも攻撃が困難であるだけでなく、多規則プロトコルにも容易に一般化される。

図５、６および７は、Ａｖａｌａｎｃｈｅと呼ばれるさらなるプロトコルのそれぞれの部分を示し、それは、すべての既知のトランザクションのＤＡＧを管理する多規則プロトコルにＳｎｏｗｂａｌｌを拡張する。ＤＡＧは「ジェネシス頂点」と呼ばれる単一のシンクを有する。ＤＡＧの例が図８および９に示されている。ＤＡＧを管理することは、２つの著しい利点を提供する。第１に、ＤＡＧ頂点に１度投票すれば、ジェネシス頂点への経路上のすべてのトランザクションに対して暗黙的に投票することになるため、効率を改善する。第２に、Ｂｉｔｃｏｉｎのブロックチェーンと同様に、ＤＡＧがトランザクションの運命に絡んでいるため、セキュリティも改善する。これにより、正しいノードの承認なしに過去の意思決定を取り消すことが困難になる。

クライアントがトランザクションを作成すると、トランザクションに不可分に含まれる１つ以上の親に名前を付け、ＤＡＧのエッジを形成する。ＤＡＧにおいて符号化された親子関係は、アプリケーション固有の依存性に対応してもよいが、対応する必要はなく、例えば、子トランザクションは、親トランザクションで受け取った資金を支出する必要はなく、あるいはそれと何らかの関係を有する必要もない。「先祖セット」という用語を使用して、履歴内で戻る親エッジを介して到達可能なすべてのトランザクションを指し、「子孫」という用語は、すべての子トランザクションおよびそれらの跡継ぎを指す。

ＤＡＧの管理における中心的な課題は、競合するトランザクションの中から選択を行うことである。既に述べたように、本明細書における競合の概念は例示的に用途ごとに定義され、したがって、実施形態ごとにさまざまであってもよい。我々の暗号通貨用途では、同じ資金を支出するトランザクション（二重支出）は互いに競合し、競合セット（図８の網掛けの領域）を形成し、そこから１つのみが承認される。善良なトランザクションの競合セットは常にシングルトンであることに留意されたい。

Ａｖａｌａｎｃｈｅは、各競合セットに対してＳｎｏｗｂａｌｌインスタンスを具現化する。Ｓｎｏｗｂａｌｌは繰り返しクエリおよび複数のカウンタを使用して、競合するトランザクション（色）で構築された信頼量を捕捉するが、ＡｖａｌａｎｃｈｅはＤＡＧ構造を利用してトランザクションの子孫を使用する。具体的には、トランザクションＴがクエリされるとき、ＤＡＧエッジに従うことによりＴから到達可能なすべてのトランザクションは暗黙的にクエリの一部となる。Ｔおよびその先祖全体が、それらのそれぞれの競合セットにおいて現在優先されるオプションである場合にのみ、ノードはクエリに肯定的に応答するであろう。応答者のしきい値よりも多くが肯定的に投票する場合、トランザクションは、「チット」と本明細書で呼ばれるものを収集すると言われる。ノードは次いで、そのトランザクションの子孫におけるチットの総数としてそれらの信頼度を計算する。それらはたった一度だけトランザクションにクエリを行い、子孫に追加された新しい頂点および可能なチットに依存して、それらの信頼度を構築する。結合は、最初に見たトランザクションに対する初期の優先度により切断される。チットはＤＡＧ構造から分離され、攻撃者が多数のＤＡＧ頂点を生成する攻撃に対してプロトコルを免疫性にすることに留意されたい。

Ａｖａｌａｎｃｈｅでは、正しい各ノードｕは、セット

において学習したすべてのトランザクションを追跡し、相互排他的な競合セットＰ_Ｔ、

に分割する。競合は推移的であるため、Ｔ_ｉとＴ_ｊが競合している場合、それらは同じ競合セットに属し、すなわち、Ｐ_Ｔｉ＝Ｐ_Ｔｊである。この関係は、非直感的に聞こえる場合があるが、同じ資金を支出するという曖昧さがあるため競合するトランジションは等価性を有する。

ＴがトランザクションＴ’に親エッジを有する場合、Ｔ’←Ｔと書く。

という関係性はその反射推移閉包であり、ＴからＴ’への経路を示す。異なるノードにより構築されたＤＡＧは互換性が保証される。具体的には、Ｔ’←Ｔの場合、Ｔを有するシステム内のあらゆるノードはまた、Ｔ’および同じ関係のＴ’←Ｔを有し、逆に

であれば、Ｔ’←Ｔで終わるノードはないであろう。

各ノードｕは、次のように子孫から信頼度値ｄ_ｕ（Ｔ）を計算でき、

ここで、Ｃ_ｕＴ’は、ノードｕに対するＴ’のチット値を表す。各トランザクションは最初は０のチット値を有し、その後、ノードはクエリ結果を取得する。ノードがクエリの後にαｋ個の賛成票のしきい値を収集する場合、値Ｃ_ｕＴ’は１に設定され、そうでなければ永久に０のままである。したがって、チット値は、その関連のトランザクションのワンタイムクエリからの結果を反映し、その後、不変になるが、その子孫においてより多くのチットを収集することにより、ＤＡＧが増大するにつれてｄ（Ｔ）は増加できる。ｃ_Ｔ∈｛０，１｝であるため、信頼度値は単調である。

加えて、ノードｕは、システムを含む既知のノードＮ_ｕ⊆Ｎのそれ自体のローカルリストを管理する。以降の例示を簡略化するために、とりあえずＮ_ｕ＝Ｎと仮定し、曖昧にならない状況では添字ｕを省略する。

各ノードは、各トランザクション上で投票を求めるためと、新たに発見されたトランザクションの存在を他のノードに通知するための両方に機能するクエリを中心とするイベント駆動型状態マシンを実装する。特に、ノードｕがクエリを介してトランザクションＴを発見すると、Ｔが図６のプロシージャＯＮＲＥＣＥＩＶＥＴＸを介して配信された後、ｋ個のランダムなピアをサンプリングし、それらにメッセージを送信することによりワンタイムクエリの処理を開始する。

ノードｕは、競合するトランザクション∀Ｔ”∈Ｐ_Ｔ’の中で

であるように各Ｔ’が現在優先されるか否かをチェックすることによりクエリに返答する。あらゆる単一の先祖Ｔ’がこの基準を満たす場合、トランザクションは強く優先されると言われ、賛成票（１）を受信する。いずれのＴ’でもこの基準に当てはまらない場合、反対票（０）を生成する。ｕがｋ個の応答を蓄積すると、Ｔに対してαｋ個の賛成票があるか否かをチェックし、そうである場合、Ｔに対してチット（チット値ｃ_Ｔ：＝１）を付与する。上記の処理は、各トランザクションＴに対してチット値および関連する信頼度を有するＤＡＧのラベルを生成する。

図８は、＜チット，信頼度＞値の一例を示すＡｖａｌａｎｃｈｅにより構築された例示的なＤＡＧ８００を示す。より暗いボックスは、信頼度値が高いトランザクションを示す。網掛けの各領域でトランザクションは最大１件まで承認される。Ｓｎｏｗｂａｌｌと同様に、Ａｖａｌａｎｃｈｅでのサンプリングは、その競合セット内の単一のトランザクションの優先度に対して肯定的なフィードバックを生成するであろう。例えば、Ｔ_２はＴ_３よりも大きな信頼度を有するため、その子孫はＴ_３と比較して将来チットを収集する可能性が高い。

Ｂｉｔｃｏｉｎと同様に、Ａｖａｌａｎｃｈｅはトランザクションの承認点の判定をアプリケーションに任せている。アプリケーションはＩＳＡＣＣＥＰＴＥＤ述語を提供し、それは、トランザクションにおいてリスクのある値と、いつ判定するかを決定するために意思決定が戻される可能性を考慮できる。

トランザクションに関与することは、「安全な早期の関与」と本明細書で呼ばれるものを通じて実行できる。善良なトランザクションの場合、Ｔは、その競合セット内の唯一のトランザクションであり、しきい値β_１よりも高い信頼度を有する場合に承認される。Ｓｎｏｗｂａｌｌと同様に、Ｔは、連続して成功したクエリのしきい値数β_１の後で承認することもできる。親との生存性の問題により、善良なトランザクションを承認することに失敗しても、異なる親で再発行されれば承認される可能性がある。

図６に示す擬似コードは、Ａｖａｌａｎｃｈｅが親の選択を実行し、トランザクションに絡む方法を示す。同じＵＴＸＯを消費して生成するトランザクションは互いに競合しないため、任意のトランザクションを異なる親で再発行できる。

各ノードにより実行されるＡｖａｌａｎｃｈｅプロトコルのメインループは、図５の擬似コードにより例示される。各反復では、ノードは、まだクエリされていないトランザクションＴを選択しようとする。そのようなトランザクションが存在しない場合、ループは新しいトランザクションが

に追加されるまで停止するであろう。次いで、ｋ個のピアを選択し、それらのピアにクエリを行う。これらのピアのうちのαｋを超えるものが肯定的な応答を返す場合、チット値は１に設定される。その後、その先祖におけるトランザクションの各競合セットの優先トランザクションを更新する。次に、ＴはセットＱに追加されるため、ノードにより再びクエリされることは決してないであろう。ｋ個のピアのうちのいくつかが応答しない場合、追加のピアを選択するコードは簡略化のために省略されるが、当業者に理解されるように直接的な方法で実装することもできる。

図７は、ノードがピアｊからトランザクションＴに対するクエリを受信すると何が起きるかを示す。後者が既に有していない限り、まずＴを

に追加する。次いで、Ｔが現在強く優先されるか否かを判定する。そうである場合、ノードはピアｊに肯定的な応答を返す。それ以外の場合、否定的な応答を返す。なお疑似コードでは、ノードがＴを知っているとき、それはまたＴの先祖全体を再帰的に知っていると仮定している。これは、その先祖全体が再帰的に取り出されるまで、Ｔの送出を延期することにより達成できる。実際には、トランザクションを普及させる追加のゴシップ処理は並行して使用されるが、簡略化のために疑似コードには示されていない。

所定の独立した別個の仮定の下で、上で説明したコンセンサスプロトコルのＡｖａｌａｎｃｈｅファミリーは、プロパティＰ１（安全性）およびプロパティＰ２（生存性）に確率１－εを提供することを示すことができ、ここで、εは、システム設計者の必要性に従って設定可能なセキュリティパラメータである。

ここで、プロパティＰ１およびＰ２、ならびに他の特徴に関して、上で説明したコンセンサスプロトコルファミリーを詳細に分析する。

プロパティＰ１に関しては、システムスケジューラとも呼ばれるグローバルスケジューラの視点を通してプロトコルを分析する。ゴシップの普及に基づくＢｉｔｃｏｉｎおよび他のブロックチェーンプロトコルと同様に、ゴシップが既知の時間境界内にすべての正しいノードに広がると仮定する。言い換えれば、同期通信ネットワークを仮定し、ここでシステムはラウンドで進行し、各ラウンドの開始時にグローバルスケジューラは、ランダムに均一に単一の正しいノードｕを選択する。ノードｕは、ラウンドの終了時までにその状態をサンプリングし、かつ更新するであろう。ビザンチン敵対者はｕの識別子を認識しているであろう。その上、敵対者は常にネットワーク内のすべてのノードの内部状態の完全な知識を有し、ｕがその隣のサンプルセットを選択した直後に、その制御下にあるすべてのノードの状態を完全に更新することができる。本質的に、敵対者は、正しいノードの状態を直接更新できないことにより制約されるだけである。

ネットワークは赤色または青色に着色したノードセットと考えることができる。新しい各ラウンドは、その色を変更するか、またはその現在の色における信頼度を高めるかのいずれかでノードのうちの１つの状態を更新する。システムのダイナミクスは、エピデミックネットワークのものと似ており、ここで、ノードはいくつかの確率分布上で選択された関数を使用して、隣の状態に基づいてそれらの状態を更新する。すべての可能な実行経路を追跡することは不可能であろうが、それは、あらゆるラウンドにおいて、分岐実行の可能な数が（可能な正しいノードの数）×（ノードがサンプリング可能な結果のすべての可能なｋ個のサンプルの選択）と等しいからである。その上、このタスクの難易度は、ビザンチン敵対者のために著しく増幅され、その最適な攻撃戦略は、可能であればそれ自体が非決定論的に未知の関数上で選択される。

このシステムの分析を可能にする簡略化は、すべての実行経路およびすべての可能な敵対的戦略を追跡する必要性をなくし、むしろこの状態を達成する方法に関係なく、所望の単一の状態に完全に集中することである。より具体的には、我々の分析のコアを抽出可能な洞察は、システムの不可逆性状態を特定することであり、その状態では、非常に多くの正しいノードが赤色または青色のいずれかを奪い、少数の色に戻る可能性は非常に低くなる。

２つ吸収状態を有する出生死滅Ｍａｒｋｏｖ過程を通してＳｌｕｓｈプロトコルをモデル化するが、ここで、すべてのノードは赤色であるか、または青色である。我々の構成では、すべての状態（吸収状態を除く）は一過性であり、その状態に決して戻らない非ゼロ確率があることを意味する。我々の分析は、Ｓｌｕｓｈプロトコルは、有限の時間内で非ゼロ確率を有する吸収状態に到達することを示す。その上、２つの色のうちの１つに収束する確率は、局所的なラウンドカウンタのみを使用して正確に測定できる。実際、Ｓｌｕｓｈは対数ステップのｗｈｐに近い意思決定に収束する。

Ｓｎｏｗｆｌａｋｅの場合、すべてのノードが正しいという仮定を緩和し、ノードのいくつかの部分が敵対的であると仮定している。重要な洞察は、不可逆的な状態、または帰還不能点が存在することであり、その後、システムは吸収状態のｗｈｐに収束するであろう。その上、正しいノードは、いつシステムが帰還不能点を超えたかを判定するだけである。これら２つの保証をともに構成すると、安全性違反の確率はεより厳密には小さくなり、所望のように構成できる。当然のことながら、安全性と生存性との間には本質的な緊張関係があるが、実用的である好適なパラメータが見出すことができる。ｋの値が大きいほど、収束性が遅くなることを犠牲にして、正しいノードに対してより高いレベルのセキュリティが得られる。

ＳｎｏｗｂａｌｌはＳｎｏｗｆｌａｋｅに比べて改善されており、Ｓｎｏｗｆｌａｋｅでは、ネットワークサンプルのランダムな摂動が、履歴の部分的な形態を導入することにより低減され、これを信頼度と呼ぶ。Ｍａｒｋｏｖ連鎖を使用してＳｎｏｗｂａｌｌをモデル化することは、状態空間の爆発問題のために困難である。特に、正しい各ノードの色の優先度を単に追跡するだけでは十分ではなく、分析はそれらの信頼度についての情報を管理することも行わなければならない。分析を可能にするために、ボールとつぼのゲームを介して数学的基礎を構築するが、ここで、各つぼは正しいノードの１つを表現し、ボールのカウントはどちらかの色の信頼度に対応する。このモデルを使用して、分析はさまざまな裾不等式を適用して、Ｓｎｏｗｂａｌｌの安全性保証がＳｎｏｗｆｌａｋｅのものより厳密には強いことを証明する。特に、いったんシステムが帰還不能点に到達すると、復帰する確率はＳｎｏｗｆｌａｋｅよりも厳密には低くなる。

最後に、Ｓｎｏｗｂａｌｌの安全性保証はＡｖａｌａｎｃｈｅのものにマッピングすることができ、それはＤＡＧを使用してコストを償却するＳｎｏｗｂａｌｌの具体的なインスタンス化である。ＡｖａｌａｎｃｈｅのＤＡＧの構造自体は投票に対応していないことに留意すると、これはＤＡＧを利用する他のコンセンサスプロトコルとの間の微妙な違いである。ＤＡＧは単なる性能の最適化であり、それ自体コンセンサス処理に完全に直交している。

プロパティＰ２に関しては、ＳｎｏｗｆｌａｋｅおよびＳｎｏｗｂａｌｌの両方がカウンタを使用して連続的な多数のサポートを追跡することに留意されたい。敵対者は善良なトランザクションに対する競合を偽造できないため、最初は、すべての正しいノードは、赤色または⊥を有し、ここで、⊥は「未定」を表す。競合を偽造することができず、⊥はプロトコルにより許可されないため、ビザンチンノードは赤色以外の返答でクエリに応答することはできない。したがって、ビザンチンノードに対する唯一の不正行為は返答を拒否することである。クエリがタイムアウトした場合、正しいノードが再サンプリングを行うため、予想される収束により、すべての正しいノードは、有限の数のラウンドのｗｈｐ内で全員一致した赤色の値で終了するであろう。

Ａｖａｌａｎｃｈｅは、それぞれが単一規則のインスタンスである無関係な競合セットの運命に絡むＤＡＧ構造を導入する。この絡み合いは緊張関係を具現化しており、未定の親に善良なトランザクションを付着させることは、意思決定に向かってトランザクションを推進するのに役立つが、親に悪意があることが判明した場合、トランザクションは生存性障害を被る危険にさらされる。この緊張関係を解決し、２つの機構の助けを借りて生存性保証を提供することができる。

第１に、適応的な親選択戦略を利用するが、そこではトランザクションはＤＡＧのライブエッジに付着させ、ジェネシス頂点により近い新しい親と再試行させる。このプロシージャは、異議のない判定後の親と終了することが保証され、異議のある悪意あるトランザクションによりトランザクションが生存性障害を被らないことを保証する。２次的な機構は、判定後の先祖との善良なトランザクションが十分なチットを受け取ることを保証する。正しいノードは、十分な子孫を欠き、ノーオペレーション（「ｎｏｐ」）トランザクションを発する善良なトランザクションに対してＤＡＧを調べ、それらの信頼性を高めるのに役立つ。これら２つの機構が所定の場所にあれば、最悪の場合、ＡｖａｌａｎｃｈｅはＳｎｏｗｂａｌｌの別個のインスタンスに縮退し、したがって、善良なトランザクションに対して同じ生存性保証を提供することが容易にわかる。

上で説明した例示的な実施形態におけるプロトコルファミリーに関する追加の洞察は、以降のことを含む。

第１に、プロトコルはステップ関数ではなく、その基礎となる関数が滑らかである安全性および生存性の両方の保証をもたらす。多くの他のコンセンサスプロトコルでは、安全性は敵対的ノードの固定しきい値数（１／３など）まで保証され、それを超える保証は提供されない。我々のプロトコルでは、敵対的割合が事前に確立された境界を超えると、保証は素直に劣化する。例えば、最適なシステムパラメータを選択して、故障確率εで正確に１／５の敵対的存在を承認できる。しかしながら、システムが１／５を超える敵対的存在に直面する場合、故障確率は直ちに１になるのではなく、わずかにεを上回るまで劣化する。

第２に、これらのプロトコルは、安全性および生存性のトレードオフを外部化する。システム設計者は、１／２を超える敵対的存在などの壊滅的事象の下でも、生存性を犠牲にして安全性を保証することを選択できる。これは、従来のまたはＮａｋａｍｏｔｏベースのコンセンサスプロトコルでは利用できない強力な調整を提示する。

コンセンサスプロトコルに対しては多数の攻撃ベクトルがある。ここでは、Ｓｙｂｉｌ攻撃とフラッディング攻撃という２つの最も重要な攻撃を考える。

Ｓｙｂｉｌ攻撃に関しては、コンセンサスプロトコルは典型的には、参加者のほんの一部が敵対的であるという仮定に基づいて保証を提供する。ネットワークが任意の参加者に素朴に開いたままにされている場合、これらの境界が侵害される可能性がある。特に、多数の識別子が敵対者により生成されるＳｙｂｉｌ攻撃を使用して、敵対者の境界を超える可能性がある。Ｓｙｂｉｌ問題は典型的には、コンセンサスとは別個に処理され、当然そのため、Ｓｙｂｉｌ制御機構は基礎となるより複雑な合意プロトコルとは異なるが、これはあらゆるコンセンサスプロトコルがあらゆるＳｙｂｉｌ制御機構と結合できることを意味するものではない。例えば、Ｎａｋａｍｏｔｏコンセンサスは、プルーフオブワークを使用してＳｙｂｉｌを制限し、採掘者はハードウェア投資を継続的に賭ける必要がある。他のプロトコルは、プルーフオブステークまたはプルーフオブオーソリティに依存する。上記の例示的な実施形態で説明されるコンセンサスプロトコルは任意のＳｙｂｉｌ制御機構を採用することができるが、プルーフオブステークはそれらの静穏な動作と最も整合している。プルーフオブステークやプルーフオブオーソリティなどの制御機構は、プルーフオブワークに関連するエネルギー非効率性を回避する。暗号通貨は、Ｓｙｂｉｌ攻撃に対処するため、これらのおよび他の制御機構と組み合わせて本明細書で開示されるコンセンサスプロトコルを使用して実装できる。

フラッディング攻撃に関しては、このような攻撃は任意の分散システムにとって潜在的な問題である。保護機構がない場合、攻撃者は多数のトランザクションを生成し、ＤＡＧを氾濫させ、ストレージを消費する可能性がある。ネットワーク層の保護、プルーフオブオーソリティ、または経済的機構を含む、そのような攻撃を阻止する多数の技術がある。Ａｖａｌａｎｃｈｅでは、トランザクション手数料を使用すると、攻撃者がその制御下にあるアドレスにお金を戻そうとしても、このような攻撃は高額になる。

コミュニケーションの複雑性に関しては、悪意あるトランザクションに対して生存性が保証されていないため、善良なトランザクションの場合のみのメッセージ複雑性分析に集中する。善良なトランザクションの場合、ＳｎｏｗｆｌａｋｅおよびＳｎｏｗｂａｌｌは両方ともＯ（ｋｎ×ｌｏｇ（ｎ））メッセージの後に終了することが保証される。これは、エピデミックアルゴリズムに関係した周知の結果から得られる。Ａｖａｌａｎｃｈｅの場合の通信の複雑性はより微妙である。Ａｖａｌａｎｃｈｅにより誘起されたＤＡＧが、ＤＡＧの幅に対応し、親選択アルゴリズムにより判定される予想分岐係数ｐを有するようにする。β意思決定しきい値を考慮すると、意思決定点に到達したばかりのトランザクションは関連する子孫Ｙを有するであろう。ｍはＹの予想深さにする。Ａｖａｌａｎｃｈｅネットワークを発展させて、深度ｙでＤＡＧを凍結すると、それはおよそｐｙ個の頂点／トランザクションを有し、そのうちのｐ（ｙ－ｍ）個が期待値内で決定される。ｐｍ個の最近のトランザクションのみが意思決定に必要な子孫を欠くであろう。各ノードに対して、各クエリはｋ個のサンプルを要求し、したがって、トランザクションごとの総メッセージコストは期待値（ｐｋｙ）／（ｐ（ｙ－ｍ））＝ｋｙ／（ｙ－ｍ）になる。システムが常に発展する際、ｍはＤＡＧの未定の領域により判定される定数であるため、ノードごとのメッセージ複雑性はＯ（ｋ）となるが、総複雑性はＯ（ｋｎ）となる。

例示的な実施形態の動作を評価するために、ＢｉｔｃｏｉｎトランザクションをＡｖａｌａｎｃｈｅに完全に移植し、ベアボーン支払いシステムを実装した。以降では、この例の実装が暗号通貨の中心で値転送プリミティブをサポート可能な方法を説明し、Ａｍａｚｏｎ ＡＷＳ上での大規模な展開を通してそのスループット、拡張性、および遅延を調べ、最後に他のシステムからの既知の結果との比較を提供する。

この例のシステムの特定の特徴、パラメータ、および他の構成の詳細は、例示のためのみに提示され、要件または限定と考えるべきではないことを理解されたい。完全な暗号通貨を展開することは一般に、ブートストラッピング、ミンティング、ステーキング、アンステーキング、およびインフレ－ション制御などの機能を含むことも留意すべきである。既知の技術は、本明細書で明示的に対処されていない範囲で、そのような問題に対処する直接的な方法で適用できる。

この例の実装を説明するため、トランザクションがＵＴＸＯトランザクションを含むと仮定している。ＡｖａｌａｎｃｈｅにおけるＤＡＧ構造に加えて、支出依存性を捕捉するＵＴＸＯグラフを使用して、支払いシステムの台帳を実現する。曖昧さを避けるために、送金トランザクションのデータを符号化するトランザクションを示すが、ＡｖａｌａｎｃｈｅのＤＡＧ頂点においてトランザクション

を呼び出す。

Ｂｉｔｃｏｉｎからトランザクションおよびアドレス機構を継承する。最も簡単な場合、トランザクションは複数の入力および出力からなり、対応する精算スクリプトがある。アドレスは公開鍵のハッシュにより識別され、署名は対応する秘密鍵により生成される。完全なスクリプト言語を使用して、ＵＴＸＯを支出するために精算スクリプトが認証されることを保証する。ＵＴＸＯは正当なトランザクションにより完全に消費され、指名された受領者により支出可能な新しいＵＴＸＯを生成できる。マルチ入力トランザクションは複数のＵＴＸＯを消費し、Ａｖａｌａｎｃｈｅでは複数の競合セットに現れる場合がある。これらを正しく説明するために、トランザクション入力ペア（Ｉｎ_ａ１など）をＡｖａｌａｎｃｈｅ頂点として表現する。

図９は、本実施形態においてＡｖａｌａｎｃｈｅにより使用される論理ＤＡＧ構造に従って構成された一例のＤＡＧ９００を示す。網掛けの小さな正方形はダミー頂点であり、明確化のためにＤＡＧトポロジーを形成するのに役立つだけであり、直接エッジに置き換えてもよい。円形のグレーの領域は競合セットである。

各ペアが未使用の出力を１つだけ支出するため、トランザクション入力ペアの競合関係は過渡的である。あるトランザクションのすべての入力に対してＩＳＡＣＣＥＰＴＥＤの結合を使用し、図９に示すように、そのすべての入力が承認されない限りトランザクションが承認されないことを保証する。この着想に続いて、クエリごとに複数のトランザクションをともにバッチ処理できるように、トランザクション入力ペアのＤＡＧを最終的に実装する。

システムの大規模化を助けるために所定数の最適化を実行する。第１に、信頼度の再帰的定義は、他の方法ではコストのかかるＤＡＧ横断を要求する場合があるため、ＤＡＧにレイジー更新を使用する。ＤＡＧ上のアクティブな各頂点に対して現在のｄ（Ｔ）値を管理し、子孫の頂点がチットを取得したときだけそれを更新する。検索経路は承認された頂点で切り詰めることができるため、拒否された頂点が限られた数の子孫を有し、ＤＡＧの未定の領域が一定のサイズにとどまる場合、更新に対するコストは一定である。第２に、悪意あるクライアントが大量の競合するトランザクションを生成できるため、競合セットは実際には非常に大きくなる可能性がある。各競合セットに対してコンテナデータ構造を維持する代わりに、各ＵＴＸＯから、競合セット全体の代表として存在する優先トランザクションへのマッピングを作成する。これにより、ノードは将来の競合、およびクエリへの適切な応答を素早く判定できる。最後に、ｋ個の応答を待つことなく、αｋのしきい値が満たされるとすぐ早期に終了することによりクエリ処理を高速化する。

上で説明した例の実装は、数百（１２５）～数千（２０００）の仮想マシンインスタンスを実行することによりＡｍａｚｏｎ ＥＣ２上で試験を行った。それぞれが個々のノードをシミュレートするｃ５．ｌａｒｇｅインスタンスを使用する。ＡＷＳは最大２Ｇｂｐｓの帯域幅を提供するが、Ａｖａｌａｎｃｈｅプロトコルは最大でも約１００Ｍｂｐｓを利用する。

我々の例の実装は、２つのバージョンのトランザクションをサポートしており、一方は専用のＵＴＸＯ形式であるが、他方はＢｉｔｃｏｉｎ ０．１６から直接コードを使用する。サポートされている両方の形式は、Ｂｉｔｃｏｉｎからのｓｅｃｐ２５６ｋ１暗号ライブラリを使用し、ウォレットに同じアドレス形式を提供する。すべてのシミュレーションは、ジオレプリケーションを除き専用の形式を使用し、ジオレプリケーションでは両方の結果が与えらる。

別個のクライアント処理を作成することにより、ユーザーからの新しいトランザクションの一定のフローをシミュレートし、各処理が別個のウォレットを管理し、新しい受領者アドレスとのトランザクションを生成し、Ａｖａｌａｎｃｈｅノードにリクエストを送信する。いくつかのそのようなクライアント処理を使用して、システムの容量を使い切る。各トランザクションに対する受領者の数は、Ｂｉｔｃｏｉｎの現在の平均トランザクションサイズである約２５０バイトの平均トランザクションサイズ（トランザクションごとに平均１～２個の入力／出力および安定なＵＴＸＯサイズ）を達成するように調整される。ネットワークを効率的に利用するために、クエリ中に最大４０件のトランザクションをバッチ処理するが、個々のトランザクション粒度において信頼度値を管理する。

報告されたすべてのメトリクスは、すべてのクライアントの観点から行われたエンドツーエンドの測定値を反映している。すなわち、クライアントは、スループットについて１秒ごとに確認されたトランザクションの総数を調べ、各トランザクションに対して、遅延のための確認タイムスタンプから開始タイムスタンプを減算する。セキュリティパラメータについては、ｋ＝１０、α＝０．８、β_１＝１１、β_２＝１５０を利用し、１０２４年までのＭＴＴＦを生成した。他の実施形態では、他のセキュリティパラメータを使用することもできる。

まず、トランザクションで飽和させ、トランザクションが定常状態で確認される速度を調べることにより、システムのスループットを測定する。この実験では、まず、１０件のクライアント処理を有する１２５個のノード上でＡｖａｌａｎｃｈｅを実行し、それぞれが所与の時刻において４００件の未払いのトランザクションを管理する。

システムは、バッチサイズが２０の場合は６８５１トランザクション／秒（ｔｐｓ）、バッチサイズが４０の場合は７００２ｔｐｓ超を達成することがわかった。システムは、既知の性能を有する他のブロックチェーンと比較して小さなバッチサイズで飽和する。Ｂｉｔｃｏｉｎはブロックごとに数千件のトランザクションをバッチ処理し、Ａｌｇｏｒａｎｄは２～１０メガバイトのブロック、すなわち、８．４～４１．９Ｋｔｘ／バッチを使用し、Ｃｏｎｆｌｕｘは４メガバイトのブロック、すなわち、１６．８Ｋｔｘ／バッチを使用する。これらの従来のシステムは、単一の意思決定を行うのが比較的遅く、したがって、より良い性能のために非常に大きなバッチ（ブロック）サイズを要求する。小さなバッチサイズで高スループットを達成することは、以降でより詳細に説明するように低遅延を意味する。

Ａｖａｌａｎｃｈｅコンセンサスに参加するノードの数の観点でシステムがどの程度の規模であるかを調べるために、同一のセッティングで実験を行い、ノードの数を１２５個から２０００個まで変化させる。

シグネチャ検証が有効な場合、ネットワークが倍率１６でｎ＝２０００まで増大するとき、全体のスループットは６９０９ｔｐｓまで約１．３４％劣化することがわかった。この劣化は、繰り返し実行の性能変動と比較してわずかである。

Ａｖａｌａｎｃｈｅは３つのソースからその拡張性を得るが、第１に、支出関係のみを捕捉する半順序を管理することで、すべてのトランザクションを線形化する従来のＢＦＴ複製ログより並列処理を可能にし、第２に、リーダーがいないため自然にボトルネックを回避し、最後に、意思決定ごとに各ノードが処理しなければならないメッセージの数がＯ（ｋ）であり、ネットワークが大規模化するにつれて増大しない。

次に、ボトルネックが我々の例の実装にある場所を調べる。シグネチャ検証を無効にすると、スループットは約２．６倍高くなる。これは、暗号検証オーバーヘッドが、我々の例の実装における現在のボトルネックであることを示している。このボトルネックは、トランザクション検証をＧＰＵにオフロードすることにより対処できる。そのような最適化がなくても、７Ｋｔｐｓは、既存のブロックチェーンをはるかに超えている。

遅延に関して、その提出の瞬間から承認されると確認されるまでに費やした時間として、トランザクションの遅延を定義する。この例の実装についてのシミュレーションは、２０００個のノードでのスループット測定と同じセットアップを使用して、ほとんどのトランザクションが約０．３秒以内に確認されることを示している。最も共通の遅延は約２０６ミリ秒であり、分散は低く、ノードがほぼ同時にグループとしての最終値に収束することを示す。これらのシミュレーションで観察した最大遅延は約０．４秒である。

また、異なる数のノードに対するトランザクション遅延もシミュレーションした。中央値の遅延は、ネットワークサイズにほぼ依存しないことが見出された。

次に、未使用の出力を２重支払いする不正なクライアントにより発行される悪意あるトランザクションが、正直なクライアントにより作成された善良なトランザクションの遅延にどのように影響を与えるかを調べる。保留中のトランザクションの一部（０～２５％）が一部の既存のものと競合する場合に、不正なクライアントをシミュレートするための戦略を採用する。クライアント処理は、すべてのシミュレーションされた保留中のトランザクションの中でいくつかの二重支出トランザクションのフローを指定し、競合するトランザクションを異なるノードに送信することによりこれを達成する。以前の実験と同じｎ＝１０００のセットアップを使用し、確認されるトランザクションのスループットおよび遅延のみを測定する。

Ａｖａｌａｎｃｈｅの遅延は、不正なクライアントによりわずかに影響されることが見出された。驚くべきことに、悪意あるトランザクションの割合が増大すると、最大遅延はやや低下する。悪意あるトランザクションの導入により、全体的な有効スループットが低下し、したがってシステム負荷を軽減するため、この挙動が発生する。また、善良なトランザクションのスループットは、悪意あるトランザクションの比率とともに減少する。さらに、スループットの減少は、不正なクライアントの数に比例しているようであり、すなわち、攻撃者にはレバレッジは提供されない。

ジオレプリケーションに関しては、ほぼ実質的な数の到達可能なＢｉｔｃｏｉｎノードであるような２０の主要都市を選択した。これらの都市は、北米、ヨーロッパ、西アジア、東アジア、オセアニアなどをカバーし、到達可能なノードの数が最も多い上位１０カ国もカバーしている。ＷｏｎｄｅｒＮｅｔｗｏｒｋノードからのグローバルｐｉｎｇ統計に基づいて遅延およびジッタリングマトリックスを使用し、ｔｃおよびｎｅｔｅｍを使用してＬｉｎｕｘ（登録商標）カーネルにおけるネットワークパケットの遅延をエミュレートする。２０００個のノードが各都市に均一に分散され、同じ都市内のノード間で追加のネットワーク遅延はエミュレートされないと仮定している。多くの商品ネットワークリンクがあるインターネット規模のセッティングをシミュレートするため、処理ごとの帯域幅を２０Ｍｂｐｓに制限する。各都市にクライアント処理を割り当て、任意の瞬間に都市ごとに４００件の未払いのトランザクションを管理する。

このシナリオでは、Ａｖａｌａｎｃｈｅは平均スループット３４０１ｔｐｓを達成し、標準偏差は３９ｔｐｓである。トランザクション遅延の中央値は１．３５秒であり、最大遅延は４．２５秒である。トランザクションに対してネイティブなＢｉｔｃｏｉｎコードもサポートしており、この場合、スループットは３５３０ｔｐｓであり、σ＝９２ｔｐｓである。

上で説明した例のシステムを従来のＡｌｇｏｒａｎｄおよびＣｏｎｆｌｕｘシステムと比較した。Ａｌｇｏｒａｎｄ、Ｃｏｎｆｌｕｘ、Ａｖａｌａｎｃｈｅはすべて、それらの設計において基本的に異なる。Ａｌｇｏｒａｎｄのコミティ規模のコンセンサスアルゴリズムは従来のＢＦＴコンセンサスカテゴリに分類され、Ｃｏｎｆｌｕｘはより高いスループットを容易にするためにＤＡＧ構造によりＮａｋａｍｏｔｏコンセンサスを拡張しているが、Ａｖａｌａｎｃｈｅは準安定に基づく新しいプロトコルファミリーに属する。追加的に、Ｂｉｔｃｏｉｎをベースラインとして使用する。

ＡｌｇｏｒａｎｄおよびＡｖａｌａｎｃｈｅの両方の評価は、ＥＣ２上でサイズ２０００の意思決定ネットワークを使用する。我々の評価は、共有ｃ５．ｌａｒｇｅインスタンスを選択したが、Ａｌｇｏｒａｎｄはｍ４．２ｘｌａｒｇｅを使用した。これら２つのプラットフォームは、ｃ５．ｌａｒｇｅに対するわずかなＣＰＵクロック速度エッジを除いて非常に類似しており、これらの実験では我々の処理は３０％しか消費しないため、ほとんど未使用になる。我々の実験で選択されたセキュリティパラメータは、２０％のビザンチンノードの存在下で１０^－９未満の安全性違反確率を保証するが、Ａｌｇｏｒａｎｄの評価は、２０％のビザンチンノードで５×１０^－９未満の違反確率を保証する。

Ａｌｇｏｒａｎｄの評価もＣｏｎｆｌｕｘの評価も、暗号化検証のオーバーヘッドを考慮していない。それらの評価は、メガバイトのダミーデータを保持するブロックを使用し、ＭＢ／時間またはＧＢ／時間単位のスループットを提示する。そのため、Ｂｉｔｃｏｉｎトランザクション（および我々のトランザクション）の平均サイズ２５０バイトを使用してスループットを導く。一方、我々の実験は実際のトランザクションを保持し、すべての暗号化オーバーヘッドを考慮する。

スループットは、Ｂｉｔｃｏｉｎでは３～７ｔｐｓ、Ａｌｇｏｒａｎｄでは８７４ｔｐｓ（１０メガバイトブロックで）、Ｃｏｎｆｌｕｘでは３３５５ｔｐｓ（すなわち、同じセッティングの下でのＡｌｇｏｒａｎｄのスループットの３．８４倍）である。

一方、Ａｖａｌａｎｃｈｅは、コミティまたはプルーフオブワークなしで最大２０００ノードまで一貫して３４００ｔｐｓ超を達成する。遅延については、Ｂｉｔｃｏｉｎで１０～６０分後、Ａｌｇｏｒａｎｄで約５０秒後、Ｃｏｎｆｌｕｘで７．６～１３．８分後、およびＡｖａｌａｎｃｈｅで１．３５秒後にトランザクションが確認される。

Ａｖａｌａｎｃｈｅは、スループットと遅延の両方においてＡｌｇｏｒａｎｄよりはるかによく動作するが、それは、Ａｌｇｏｒａｎｄはコミティを選択するために検証可能なランダム関数を使用し、全順序ログを管理するが、Ａｖａｌａｎｃｈｅは半順序のみを確立するためである。Ａｌｇｏｒａｎｄはリーダーベースであり、コミティによりコンセンサスを実行するが、Ａｖａｌａｎｃｈｅはリーダーレスである。

ＡｖａｌａｎｃｈｅはＣｏｎｆｌｕｘと同様のスループットを有するが、その遅延は３３７～６１３倍よくなる。また、ＣｏｎｆｌｕｘはＤＡＧ構造を使用して、コンセンサスのコストを償却し、スループットを増加させるが、なおプルーフオブワークを使用してＮａｋａｍｏｔｏコンセンサスに根ざしており、したがって、Ａｖａｌａｎｃｈｅの非常に短い確認時間を提供することはできない。

ブロックチェーンシステムでは通常、バッチ処理による遅延を犠牲にすることでスループットを改善できる。性能の実際のボトルネックは、システムが毎秒行うことができる意思決定の数であり、これはＡｌｇｏｒａｎｄにおけるビザンチン合意（ＢＡ＊）およびＣｏｎｆｌｕｘにおけるＮａｋａｍｏｔｏコンセンサスのいずれかにより基本的に制限される。

上記の説明から、例示的な実施形態が従来のコンセンサスプロトコルに対して著しい利点を提供することは明らかである。

例えば、上記の例示的な実施形態において説明したコンセンサスプロトコルの新しいファミリーは、非常に効率的で、かつ堅牢である。それらはうまく規模拡大し、高スループットおよび素早い最終状態を達成し、正確なメンバーシップの知識なしで動作し、壊滅的な敵対的攻撃の下で素直に劣化する。

そのような実施形態はより具体的には、準安定機構の周りに構築されたリーダーレスのビザンチン障害耐性プロトコルのファミリーを含む。このプロトコルは、ビザンチン敵対者の存在下で強力な確率的安全性保証を提供するが、それらの並列性により、高スループットおよび拡張性を達成することができる。プルーフオブワークに依存するブロックチェーンとは異なり、それらは静穏で環境に優しい。Ｏ（ｎ）情報を（交換されるビット数の観点で）処理するリーダーノードを有する従来のコンセンサスプロトコルとは異なり、あるセキュリティパラメータｋに対してＯ（ｋ）を超える処理を行うノードはない。

本明細書で開示されるコンセンサスプロトコルは、さまざまな異なる用途で使用できる。例えば、このコンセンサスプロトコルは、暗号通貨および他のブロックチェーン用途において改良された性能を提供できる。上で説明した実験は、その例の実装が、同様の機能を果たす既存のシステムと比較して、高いスループット（３４００ｔｐｓ）を達成し、低い確認遅延（１．３５秒）を提供し、うまく規模拡大できることを示す。

図１～９とともに示され説明される特定の配置は、例示的なものとしてのみ提示され、多くの代替的な実施形態が可能であることが理解されよう。したがって、本明細書で開示されるさまざまな実施形態は、いずれにせよ限定するものと解釈されるべきではない。他の実施形態では、準安定コンセンサスプロトコルを実行するための多くの代替的な配置を利用できる。

例えば、他の実施形態では、図２～７に示される例のプロトコルの特定の処理動作を変更してもよい。

別の例として、上で説明した所定の実施形態における同期性の仮定は他の実施形態では緩和することができ、非同期下であっても強力な保証が可能であることが予想される。

また、当業者は、他の実施形態では、処理動作および関連するシステム実体構成の多くの他の代替的な配置を使用できることを認識するであろう。

したがって、他の実施形態は、例示的な実施形態の実体と比較して、追加のまたは代替的なシステム実体を含むことが可能である。また、他の実施形態では、特定のシステムおよびデバイス構成、ならびに関連する準安定コンセンサスプロトコルを変更できる。

上で説明した情報処理システム配置は例示的なものに過ぎず、他の実施形態では、代替的なシステム配置を使用できることも留意すべきである。

本明細書で説明される情報処理システムにおける所与のクライアント、サーバ、処理ノードまたは他の構成要素は例示的に、メモリに結合されたプロセッサを含む対応する処理デバイスを利用して構成されている。プロセッサは、メモリ内に格納されたソフトウェアプログラムコードを実行し、処理動作の性能および他の機能を制御する。また、処理デバイスは、１つ以上のネットワーク上で通信をサポートするネットワークインターフェースを備える。

プロセッサは、例えば、マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、ＣＰＵ、ＡＬＵ、ＧＰＵ、ＤＳＰ、または他の同様の処理デバイス構成要素、ならびに処理回路の他の種類および配置を、任意の組み合わせで含んでもよい。例えば、本明細書で開示される処理デバイスの所与の暗号処理モジュールは、そのような回路を使用して実装できる。

メモリは、処理デバイスの機能の一部を実装する際、プロセッサにより実行するソフトウェアプログラムコードを格納する。対応するプロセッサにより実行するそのようなプログラムコードを格納する所与のそのようなメモリは、内部に具現化されたプログラムコードを有するプロセッサ可読ストレージ媒体と本明細書でより一般的に呼ばれるものの一例であり、例えば、ＳＲＡＭ、ＤＲＡＭもしくは他の種類のランダムアクセスメモリ、ＲＯＭ、フラッシュメモリ、磁気メモリ、光学メモリ、または他の種類のストレージデバイスなどの電子メモリを任意の組み合わせで含んでもよい。

そのようなプロセッサ可読ストレージ媒体を含む製造品は、本発明の実施形態と考えられる。「製造品」という用語は本明細書で使用される場合、一過性の伝播信号を除外するように理解されるべきである。

他の実施形態では、プロセッサ可読ストレージ媒体を含む他の種類のコンピュータプログラム製品を実装できる。

加えて、本発明の実施形態は、準安定コンセンサスプロトコルに関連した処理動作、ならびに他の関係する機能を実行するように構成された処理回路を含む集積回路の形態で実装してもよい。

所与の実施形態における処理デバイスは、例えば、ラップトップ、タブレットもしくはデスクトップパーソナルコンピュータ、携帯電話、または他の種類のコンピュータもしくは通信デバイスを任意の組み合わせで含むことができる。例えば、本明細書で開示されるように、準安定コンセンサスプロトコルに参加するための処理デバイスとしてコンピュータまたは携帯電話を利用できる。それぞれのシステム実体に関連した処理デバイスを含む情報処理システムのさまざまな要素間のこれらのおよび他の通信は、１つ以上のネットワーク上で行われてもよい。

本明細書で開示される情報処理システムは、１つ以上の処理プラットフォーム、またはその一部を使用して実装してもよい。

例えば、情報処理システムの少なくとも一部を実装するために使用可能な処理プラットフォームの１つの例示的な実施形態は、物理的基盤上で実行するハイパーバイザーを使用して実装した仮想マシンを含むクラウド基盤を備える。そのような仮想マシンは、１つ以上のネットワーク上で互いに通信を行う各処理デバイスを含んでもよい。

このような実施形態におけるクラウド基盤はさらに、ハイパーバイザーの制御下で仮想マシンのそれぞれ上で実行するアプリケーションの１つ以上のセットを備えてもよい。また、少なくとも１つの基礎となる物理マシンを使用して仮想マシンのセットをそれぞれ提供する複数のハイパーバイザーを使用することもできる。１つ以上のハイパーバイザーにより提供される仮想マシンの異なるセットは、情報処理システムのさまざまな構成要素の複数のインスタンスを構成する際に利用してもよい。

本明細書で開示される情報処理システムの少なくとも一部を実装するために使用可能な処理プラットフォームの別の例示的な実施形態は、少なくとも１つのネットワーク上で互いに通信を行う複数の処理デバイスを備える。処理プラットフォームの各処理デバイスは、メモリに結合されたプロセッサを備えると仮定されている。

同様に、これらの特定の処理プラットフォームは例としてのみ提示され、情報処理システムは、追加のまたは代替的な処理プラットフォーム、ならびに多くの別個の処理プラットフォームを任意の組み合わせで含んでもよく、そのようなプラットフォームはそれぞれ、１つ以上のコンピュータ、サーバ、ストレージデバイス、または他の処理デバイスを備える。

例えば、本発明の実施形態を実装するために使用される他の処理プラットフォームは、仮想マシンを含む仮想化基盤の代わりに、またはそれに加えて、異なる種類の仮想化基盤を含むことができる。したがって、いくつかの実施形態では、システム構成要素は、クラウド基盤または他の種類の仮想化基盤において少なくとも部分的に実行することが可能である。

したがって、他の実施形態では、追加のまたは代替的な要素の異なる配置を使用してもよいことが理解されるべきである。これらの要素の少なくともサブセットは、共通の処理プラットフォーム上に集団で実装してもよく、そのような要素はそれぞれ、別個の処理プラットフォーム上に実装してもよい。

また、情報処理システムでは、コンピュータ、サーバ、ストレージデバイス、または他の構成要素の多くの他の配置が可能である。そのような構成要素は、任意の種類のネットワークまたは他の通信媒体上で情報処理システムの他の要素と通信を行うことができる。

既に示したように、本明細書で開示されるシステムの構成要素は、メモリに格納され、処理デバイスのプロセッサにより実行される１つ以上のソフトウェアプログラムの形態で少なくとも部分的に実装できる。例えば、あるシステムの準安定コンセンサスプロトコル実体または関係する構成要素に関連した所定の機能は、ソフトウェアの形態で少なくとも部分的に実装できる。

本明細書で説明される情報処理システムの特定の構成は例示に過ぎず、他の実施形態における所与のそのようなシステムは、具体的に示されるものに加えて、またはその代わりに、そのようなシステムの従来の実装において共通に見出される種類の１つ以上の要素を含む他の要素を含んでもよい。

例えば、いくつかの実施形態では、情報処理システムは開示された技術を利用し、他の状況において追加のまたは代替的な機能を提供するように構成してもよい。

したがって、暗号通貨の状況で準安定コンセンサスプロトコルを提供する場面において、本明細書のいくつかの実施形態で例示される技術は、他の状況で使用するための直接的な方法に適用できる。それに応じて、本発明の例示的な実施形態は、暗号通貨またはそれらに関連する処理状況に限定されるとみなすべきではない。

本明細書に記載される実施形態で使用される特定の処理ステップは例示にすぎず、他の実施形態が処理動作の異なる種類および配置を利用できることも理解されたい。例えば、例示的な実施形態において連続的に実行されるように示される所定の処理ステップは、他の実施形態では少なくとも部分的に互いに並行して実行できる。

本明細書で説明される発明の実施形態は例示的なものに過ぎないことを再び強調すべきである。本発明の他の実施形態は、本明細書で説明される特定の例示的な実施形態において、および多くの代替的な処理状況において利用されるものとは異なるさまざまな種類および配置の情報処理システム、ネットワークおよびデバイスを利用して実装できる。加えて、所定の実施形態を説明する状況において本明細書で行われる特定の仮定を他の実施形態に適用する必要はない。これらのおよび多くの他の代替的な実施形態は、当業者には容易に明らかとなるであろう。

Claims (27)

1. メモリに結合されたプロセッサを含む第１の処理ノードを備える装置であって、
   前記第１の処理ノードは、追加の処理ノードとのコンセンサスプロトコルに参加するように構成され、
   前記第１の処理ノードは、前記コンセンサスプロトコルへの前記第１の処理ノードの参加とともに、
   前記追加の処理ノードのそれぞれ選択されたサブセットの繰り返しポーリングを実行し、
   前記繰り返しポーリングの結果に応答して、所与のトランザクションの状態を、前記所与のトランザクションの複数の可能な状態のうちの特定の１つに解決し、
   前記所与のトランザクションの前記解決された状態に少なくとも部分的に基づいて、少なくとも１つの、分散台帳の保守に関連した自動アクションを開始するようにさらに構成されている、装置。
2. 前記コンセンサスプロトコルは、ビザンチン障害耐性を提供するように構成されている、請求項１に記載の装置。
3. 前記少なくとも１つの自動アクションは、前記分散台帳に前記所与のトランザクションを特徴付けるエントリーを追加することを含み、前記分散台帳は前記第１のおよび追加の処理ノードにより集団で管理される、請求項１に記載の装置。
4. 前記エントリーはブロックを含み、前記分散台帳はブロックチェーンを含む、請求項３に記載の装置。
5. 前記コンセンサスプロトコルへの前記第１のおよび追加の処理ノードの参加は、前記第１のおよび追加の処理ノードのそれぞれによる１つ以上の指定されたプルーフの提出を要求する少なくとも１つの規定の制御機構に従って制御されている、請求項１に記載の装置。
6. 前記指定されたプルーフは、プルーフオブステーク、プルーフオブオーソリティ、プルーフオブスペース、プルーフオブタイム、プルーフオブエラプスドタイム、ならびにこれらの任意の組み合わせを含む、請求項５に記載の装置。
7. 前記繰り返しポーリングの所与のインスタンスは、前記追加の処理ノードのランダムサンプルをポーリングすることを含む、請求項１に記載の装置。
8. 前記繰り返しポーリングの所与のインスタンスは、前記追加の処理ノードの決定論的サンプルをポーリングすることを含む、請求項１に記載の装置。
9. 前記繰り返しポーリングは、複数反復繰り返され、そのような各反復は前記追加の処理ノードの異なる選択されたサブセットをポーリングする、請求項１に記載の装置。
10. 前記第１の処理ノードは、前記繰り返しポーリングの前記結果を利用して、前記所与のトランザクションと複数の他のトランザクションとの間の関係を特徴付けるデータ構造を管理するようにさらに構成され、前記データ構造は、有向非巡回グラフ、リンクリスト、およびハッシュリンクチェーンのうちの少なくとも１つを含む、請求項１に記載の装置。
11. 前記繰り返しポーリングの結果に応答して所与のトランザクションの前記状態を解決することは、前記繰り返しポーリングの前記結果を利用して、前記所与のトランザクションを正当なトランザクションとして承認するべきか否かについての判定を行うことを含む、請求項１に記載の装置。
12. 前記繰り返しポーリングが複数反復繰り返され、前記反復のうちの所与の反復は、
    前記追加の処理ノードのサンプルを選択することと、
    前記選択された追加の処理ノードのそれぞれにクエリを送信することと、
    前記クエリに対する少なくともしきい値数の応答の受信に応答して、前記受信した応答の少なくとも指定した部分が、前記第１の処理ノードにおける前記所与のトランザクションの現在の状態と異なる前記所与のトランザクションの特定の状態を示すか否かを判定することと、
    前記受信した応答の前記指定した部分が、前記第１の処理ノードにおける前記所与のトランザクションの現在の状態と異なる前記所与のトランザクションの特定の状態を示すことに応答して、前記第１の処理ノードにおける前記所与のトランザクションの前記現在の状態を前記特定の状態に更新することと、を含む、請求項１に記載の装置。
13. 前記繰り返しポーリングの結果に応答して前記所与のトランザクションの前記状態を解決することは、前記複数反復の完了時に前記所与のトランザクションの前記状態を前記現在の状態に解決することを含む、請求項１２に記載の装置。
14. 前記第１の処理ノードは、前記受信した応答の少なくとも指定した部分が前記所与のトランザクションの前記特定の状態を示す、前記繰り返しポーリングの連続的な反復の数を示す確信強度カウンタを管理するようにさらに構成されている、請求項１２に記載の装置。
15. 前記繰り返しポーリングの結果に応答して前記所与のトランザクションの前記状態を解決することは、前記確信強度カウンタがしきい値を超えることに応答して前記所与のトランザクションの前記状態を前記特定の状態に解決することを含む、請求項１４に記載の装置。
16. 前記第１の処理ノードは、前記所与のトランザクションの前記可能な状態のそれぞれの信頼度カウンタを管理するようにさらに構成され、前記信頼度カウンタのそれぞれは、前記対応する状態を示す応答を生成した、前記反復のうちの複数の反復にわたるクエリの総数を示す、請求項１２に記載の装置。
17. 前記繰り返しポーリングの結果に応答して前記所与のトランザクションの前記状態を解決することは、その可能な状態の前記信頼度カウンタが、前記可能な状態のうちの少なくとも１つの他のものの前記信頼度カウンタを超えることに応答して、前記所与のトランザクションの前記状態を前記可能な状態のうちの１つに解決することを含む、請求項１６に記載の装置。
18. 前記第１の処理ノードは、前記所与のトランザクションと、複数の他のトランザクションとの間の関係を特徴付ける、トランザクションの有向非巡回グラフを管理するようにさらに構成され、前記トランザクションは、相互排他的な競合セットに分割される、請求項１に記載の装置。
19. 前記有向非巡回グラフを管理することは、
    前記追加の処理ノードのサンプルを選択することと、
    前記選択された追加の処理ノードのそれぞれにクエリを送信することと、
    前記クエリへの応答に少なくとも部分的に基づいて前記有向非巡回グラフを更新することと、を含み、
    前記有向非巡回グラフを更新することは、
    １つ以上の追加のトランザクションを前記有向非巡回グラフに挿入することと、
    前記有向非巡回グラフの前記トランザクションのそれぞれの信頼度値を更新することと、
    前記有向非巡回グラフの前記トランザクションを相互排他的な競合セットに再分割することと、のうちの１つ以上を含む、請求項１８に記載の装置。
20. 前記繰り返しポーリングの結果に応答して前記所与のトランザクションの前記状態を解決することは、前記所与のトランザクションがその競合セット内の唯一のトランザクションであり、前記所与のトランザクションがしきい値を超える信頼度値を有することに応答して、前記状態を解決することを含む、請求項１９に記載の装置。
21. 前記繰り返しポーリングの結果に応答して前記所与のトランザクションの前記状態を解決することは、その可能な状態の信頼度カウンタが、前記可能な状態のうちの少なくとも１つの他のものの信頼度カウンタを超えることに応答して、前記状態を前記可能な状態のうちの１つに解決することを含む、請求項１９に記載の装置。
22. 方法であって、
    メモリに結合されたプロセッサを含む第１の処理ノードを、追加の処理ノードとの分散コンセンサスプロトコルに参加するように構成することを含み、
    前記コンセンサスプロトコルへの前記第１の処理ノードの参加とともに、前記第１の処理ノードは、
    前記追加の処理ノードのそれぞれ選択されたサブセットの繰り返しポーリングを実行し、
    前記繰り返しポーリングの結果に応答して、所与のトランザクションの状態を、前記所与のトランザクションの複数の可能な状態のうちの特定の１つに解決し、
    前記所与のトランザクションの前記解決された状態に少なくとも部分的に基づいて、少なくとも１つの、分散台帳の保守に関連した自動アクションを開始する、方法。
23. 前記繰り返しポーリングは複数反復繰り返され、前記反復のうちの所与の反復は、
    前記追加の処理ノードのサンプルを選択することと、
    前記選択された追加の処理ノードのそれぞれにクエリを送信することと、
    前記クエリに対する少なくともしきい値数の応答の受信に応答して、前記受信した応答の少なくとも指定した部分が、前記第１の処理ノードにおける前記所与のトランザクションの現在の状態と異なる前記所与のトランザクションの特定の状態を示すか否かを判定することと、
    前記受信した応答の前記指定した部分が、前記第１の処理ノードにおける前記所与のトランザクションの現在の状態と異なる前記所与のトランザクションの特定の状態を示すことに応答して、前記第１の処理ノードにおける前記所与のトランザクションの前記現在の状態を前記特定の状態に更新することと、を含む、請求項２２に記載の方法。
24. 前記第１の処理ノードが、前記所与のトランザクションと、複数の他のトランザクションとの間の関係を特徴付ける、トランザクションの有向非巡回グラフを管理することをさらに含み、前記トランザクションは、相互排他的な競合セットに分割されており、前記有向非巡回グラフを管理することは、
    前記追加の処理ノードのサンプルを選択することと、
    前記選択された追加の処理ノードのそれぞれにクエリを送信することと、
    前記クエリへの応答に少なくとも部分的に基づいて、前記有向非巡回グラフを更新することと、を含み、
    前記有向非巡回グラフを更新することは、
    １つ以上の追加のトランザクションを前記有向非巡回グラフに挿入することと、
    前記有向非巡回グラフの前記トランザクションのそれぞれの信頼度値を更新することと、
    前記有向非巡回グラフの前記トランザクションを相互排他的な競合セットに再分割することと、のうちの１つ以上を含む、請求項２２に記載の方法。
25. １つ以上のソフトウェアプログラムのプログラムコードを格納するコンピュータ可読ストレージ媒体であって、前記プログラムコードが、追加の処理ノードとのコンセンサスプロトコルに参加するように構成された第１の処理ノードにより実行されたら、前記コンセンサスプロトコルへのその参加とともに、前記第１の処理ノードに、
    前記追加の処理ノードのそれぞれ選択されたサブセットの繰り返しポーリングを実行することと、
    前記繰り返しポーリングの結果に応答して、所与のトランザクションの状態を、前記所与のトランザクションの複数の可能な状態のうちの特定の１つに解決することと、
    前記所与のトランザクションの前記解決された状態に少なくとも部分的に基づいて、少なくとも１つの、分散台帳の保守に関連した自動アクションを開始することと、を行わせる、コンピュータ可読ストレージ媒体。
26. 前記繰り返しポーリングが複数反復繰り返され、前記反復のうちの所与の反復は、
    前記追加の処理ノードのサンプルを選択することと、
    前記選択された追加の処理ノードのそれぞれにクエリを送信することと、
    前記クエリに対する少なくともしきい値数の応答の受信に応答して、前記受信した応答の少なくとも指定した部分が、前記第１の処理ノードにおける前記所与のトランザクションの現在の状態と異なる前記所与のトランザクションの特定の状態を示すか否かを判定することと、
    前記受信した応答の前記指定した部分が、前記第１の処理ノードにおける前記所与のトランザクションの現在の状態と異なる前記所与のトランザクションの特定の状態を示すことに応答して、前記第１の処理ノードにおける前記所与のトランザクションの前記現在の状態を、前記特定の状態に更新することと、を含む、請求項２５に記載のコンピュータ可読ストレージ媒体。
27. 前記所与のトランザクションと、複数の他のトランザクションとの間の関係を特徴付ける、トランザクションの有向非巡回グラフを管理する、前記第１の処理ノードをさらに備え、前記トランザクションは、相互排他的な競合セットに分割されており、前記有向非巡回グラフを管理することは、
    前記追加の処理ノードのサンプルを選択することと、
    前記選択された追加の処理ノードのそれぞれにクエリを送信することと、
    前記クエリへの応答に少なくとも部分的に基づいて前記有向非巡回グラフを更新することと、を含み、
    前記有向非巡回グラフを更新することは、
    １つ以上の追加のトランザクションを前記有向非巡回グラフに挿入することと、
    前記有向非巡回グラフの前記トランザクションのそれぞれの信頼度値を更新することと、
    前記有向非巡回グラフの前記トランザクションを相互排他的な競合セットに再分割することと、のうちの１つ以上を含む、請求項２５に記載のコンピュータ可読ストレージ媒体。

Images