特表2023-544422ネットワーク内の分散データベースのための方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-10-23
(54)【発明の名称】ネットワーク内の分散データベースのための方法及び装置
(51)【国際特許分類】
G06F 16/182 20190101AFI20231016BHJP
【ＦＩ】
G06F16/182
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023521031
(86)(22)【出願日】2021-10-05
(85)【翻訳文提出日】2023-05-31
(86)【国際出願番号】 US2021053595
(87)【国際公開番号】W WO2022076429
(87)【国際公開日】2022-04-14
(31)【優先権主張番号】63/088,298
(32)【優先日】2020-10-06
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
(71)【出願人】
【識別番号】523122883
【氏名又は名称】ヘデラ ハッシュグラフ，エルエルシー
(74)【代理人】
【識別番号】100079108
【弁理士】
【氏名又は名称】稲葉 良幸
(74)【代理人】
【識別番号】100109346
【弁理士】
【氏名又は名称】大貫 敏史
(74)【代理人】
【識別番号】100117189
【弁理士】
【氏名又は名称】江口 昭彦
(74)【代理人】
【識別番号】100134120
【弁理士】
【氏名又は名称】内藤 和彦
(72)【発明者】
【氏名】ベアード，リーモン シー．，サード
(57)【要約】
いくつかの実施形態では、方法は、分散データベースのためのアドレスブックを定義することを含む。アドレスブックは、ネットワークを介して分散データベースを実装する計算デバイスのセットからの各計算デバイスの識別子を含む。方法は、計算デバイスのセットからの計算デバイスから、アドレスブックを更新するためのトランザクションを含むイベントを受信することと、アドレスブックを使用する分散データベースのコンセンサスプロトコルに基づいて、イベントの受信ラウンドを算出することと、を更に含む。方法は、トランザクションに基づいてアドレスブックを更新して、イベントの受信ラウンド又はアドレスブックへの更新のうちの少なくとも１つの、所定の数のラウンド後に、更新されたアドレスブックを定義することを更に含む。
【特許請求の範囲】
【請求項1】
方法であって、分散データベースのためのアドレスブックを定義することであって、前記アドレスブックが、ネットワークを介して前記分散データベースを実装する複数の計算デバイスからの各計算デバイスの識別子を含む、定義することと、
前記複数の計算デバイスからの計算デバイスから、前記アドレスブックを更新するためのトランザクションを含むイベントを受信することと、
前記アドレスブックを使用する前記分散データベースのコンセンサスプロトコルに基づいて、前記イベントの受信ラウンドを算出することと、
前記トランザクションに基づいて前記アドレスブックを更新して、前記イベントの前記受信ラウンド又は前記アドレスブックへの以前の更新のうちの少なくとも１つの、所定の数のラウンド後に、更新されたアドレスブックを定義することと、を含む、方法。
【請求項2】
前記アドレスブックを更新するための前記トランザクションが、前記分散データベースを実装する前記複数の計算デバイスに計算デバイスを追加すること、又は前記分散データベースを実装する前記複数の計算デバイスから計算デバイスを除去すること、のうちの少なくとも１つを含む、請求項１に記載の方法。
【請求項3】
前記アドレスブックが、前記分散データベースを実装する前記複数の計算デバイスからの各計算デバイスについてのステーク値を含み、前記アドレスブックを更新するための前記トランザクションが、前記複数の計算デバイスからの少なくとも１つの計算デバイスについての前記ステーク値を修正することを含む、請求項１に記載の方法。
【請求項4】
前記分散データベースに関連付けられた複数のイベントからの各イベントの受信ラウンドが、そのイベントに対する子孫イベントのセットに基づいており、前記子孫イベントのセットが、前記更新の前に、前記アドレスブックを使用して算出され、前記子孫イベントのセットが、前記更新の後に、前記更新されたアドレスブックを使用して算出される、請求項１に記載の方法。
【請求項5】
前記コンセンサスプロトコルが、前記コンセンサスプロトコルの各ラウンドについてのイベントのセットを識別するように構成されており、各ラウンドについての前記イベントのセットが、複数のイベントからの各イベントの受信ラウンドを決定するために前記コンセンサスプロトコルによって使用され、前記アドレスブックを使用して、前記複数のイベントからの各イベントについての属性が算出され、
前記複数のイベントからの各イベントが、前記更新されたアドレスブックが定義されているラウンドの前記イベントのセットからの少なくとも１つのイベントの先祖でないときに、前記更新されたアドレスブックを使用して、そのイベントについての前記属性が再算出される、請求項１に記載の方法。
【請求項6】
前記コンセンサスプロトコルが、前記コンセンサスプロトコルの各ラウンドについてのイベントのセットを識別するように構成されており、各ラウンドについての前記イベントのセットが、複数のイベントからの各イベントの受信ラウンドを決定するために前記コンセンサスプロトコルによって使用され、前記アドレスブックを使用して、前記複数のイベントからの各イベントについての属性が算出され、
前記複数のイベントからの各イベントが、前記更新されたアドレスブックが定義されているラウンドの前記イベントのセットからの少なくとも１つのイベントの先祖であるときに、前記更新されたアドレスブックを使用して、前記複数のイベントからのそのイベントについての前記属性が再算出されない、請求項１に記載の方法。
【請求項7】
前記更新することが、前記アドレスブックへの前記以前の更新の前記所定の数のラウンド後に、前記更新されたアドレスブックを定義することを含み、前記更新されたアドレスブックが、前記アドレスブックへの前記以前の更新が発生したラウンドと前記更新されたアドレスブックが定義されるラウンドとの間の受信ラウンド数を有するイベント内の前記アドレスブックへの更新を含む、請求項１に記載の方法。
【請求項8】
前記更新することが、前記イベントの前記受信ラウンドの前記所定の数のラウンド後に、前記更新されたアドレスブックを定義することを含み、前記所定の数のラウンドが、１よりも大きい、請求項１に記載の方法。
【請求項9】
前記複数の計算デバイスからの各計算デバイスの前記識別子が、前記複数の計算デバイスからのその計算デバイスに対する公開鍵である、請求項１に記載の方法。
【請求項10】
装置であって、複数の計算デバイスに動作可能に結合されたネットワークを介して、前記複数の計算デバイスによって実装される分散データベースに関連付けられた、計算デバイスのメモリと、
前記メモリに動作可能に結合されたプロセッサと、を備え、前記プロセッサが、
前記分散データベースのためのアドレスブックを定義することであって、前記アドレスブックが、前記分散データベースを実装する前記複数の計算デバイスからの各計算デバイスの識別子を含む、定義することと、
前記複数の計算デバイスからの計算デバイスから、前記アドレスブックを更新するためのトランザクションを含むイベントを受信することと、
複数のイベントからの各イベントについての属性を算出することであって、前記イベントが、前記複数のイベントに含まれる、算出することと、
前記アドレスブックを使用する前記分散データベースのコンセンサスプロトコルに基づいて、前記イベントの受信ラウンドを算出することであって、前記受信ラウンドが、前記イベントの子孫であるイベントのセットからの閾値イベント数に基づく、算出することと、
前記トランザクションに基づいて前記アドレスブックを更新して、前記イベントの前記受信ラウンド又は前記アドレスブックへの以前の更新のうちの少なくとも１つの、所定の数のラウンド後に、更新されたアドレスブックを定義することと、
前記複数のイベントからの各イベントが前記イベントのセットからの子孫イベントを有しないときに、前記更新されたアドレスブックを使用して、そのイベントについての前記属性を再算出することと、を行うように構成されている、装置。
【請求項11】
前記プロセッサが、前記トランザクションに基づいて前記アドレスブックを更新して、前記イベントの前記受信ラウンドの前記所定の数のラウンド後に、前記更新されたアドレスブックを定義するように構成されており、前記所定の数のラウンドが、１よりも大きい、請求項１０に記載の装置。
【請求項12】
前記プロセッサが、前記トランザクションに基づいて前記アドレスブックを更新して、前記アドレスブックへの前記以前の更新の前記所定の数のラウンド後に、前記更新されたアドレスブックを定義するように構成されており、前記更新されたアドレスブックが、前記アドレスブックへの前記以前の更新が発生したラウンドと前記更新されたアドレスブックが定義されるラウンドとの間の受信ラウンド数を有するイベント内の前記アドレスブックへの更新を含む、請求項１０に記載の装置。
【請求項13】
前記アドレスブックを更新するための前記トランザクションが、前記分散データベースを実装する前記複数の計算デバイスに計算デバイスを追加すること、又は前記分散データベースを実装する前記複数の計算デバイスから計算デバイスを除去すること、のうちの少なくとも１つを含む、請求項１０に記載の装置。
【請求項14】
前記複数のイベントからの各イベントが前記イベントのセットからの子孫イベントを有しないときに、前記プロセッサが、前記更新されたアドレスブックを使用して、そのイベントについての前記属性を再算出しないように構成されている、請求項１０に記載の装置。
【請求項15】
プロセッサによって実行されるべき命令を表すコードを記憶する非一時的プロセッサ可読媒体であって、前記コードが、前記プロセッサに、ネットワークを介して、分散データベースを実装する複数の計算デバイスに、かつ前記分散データベースを実装するノードとして、接続することと、
前記複数の計算デバイスのうちの計算デバイスから、コンセンサスプロトコルの完了したラウンドに関連付けられた前記分散データベースの状態を受信することであって、前記状態が、前記完了したラウンドに関連付けられたイベントのコアセットの指標を、前記イベントのコアセットからの各イベントのラウンド識別子とともに含む、受信することと、
前記複数の計算デバイスから、前記状態に関連付けられた複数のイベントを受信することと、
前記イベントのコアセットと、前記イベントのコアセットからの各イベントの前記ラウンド識別子と、に基づいて、前記複数のイベントからの各イベントについての属性のセットを算出することと、
前記複数のイベントと、前記複数のイベントについての前記属性のセットと、に基づいて、有向非巡回グラフ（ＤＡＧ）を構築することと、
前記ＤＡＧを使用して、前記コンセンサスプロトコルの次のラウンドに関連付けられたイベントの順序を算出することと、を行わせるためのコードを含む、非一時的プロセッサ可読媒体。
【請求項16】
前記イベントのコアセットの前記指標が、前記イベントのコアセットからの各イベントについてのハッシュ値を含む、請求項１５に記載の非一時的プロセッサ可読媒体。
【請求項17】
前記イベントのコアセットが、前記完了したラウンドの所定の数のラウンド前のラウンドの世代である世代を有するイベントを含まない、請求項１５に記載の非一時的プロセッサ可読媒体。
【請求項18】
前記プロセッサに、前記複数のイベントから、前記完了したラウンドの所定の数のラウンド前のラウンドの世代である世代を有するイベントを破棄させるためのコードを更に含む、請求項１５に記載の非一時的プロセッサ可読媒体。
【請求項19】
前記状態が、前記複数の計算デバイスからの所定の割合の計算デバイスによってデジタル署名されている、請求項１５に記載の非一時的プロセッサ可読媒体。
【請求項20】
前記プロセッサに前記複数のイベントを受信させるための前記コードが、前記プロセッサが前記複数のイベントから他のイベントを受け入れる前に、前記イベントのコアセットから各イベントを受け入れるように、前記プロセッサに前記複数のイベントを受信させるためのコードを含む、請求項１５に記載の非一時的プロセッサ可読媒体。【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本出願は、２０２０年１０月６日に出願された、「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ ｗｉｔｈｉｎ ａ Ｎｅｔｗｏｒｋ」と題される米国仮特許出願第６３／０８８，２９８号の優先権及び利益を主張し、その全体が参照により本明細書に組み込まれる。
本出願は、２０２０年１０月６日に出願された、「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ ｗｉｔｈｉｎ ａ Ｎｅｔｗｏｒｋ」と題される米国仮特許出願第６３／０８８，２９８号の優先権及び利益を主張し、その全体が参照により本明細書に組み込まれる。
【背景技術】
【0002】
本明細書に説明される実施形態は、概してデータベースシステムに関し、より詳細には、ネットワーク内の複数のデバイスにわたってデータベースシステムを実装するための方法及び装置に関する。
【0003】
一部の既知の分散データベースシステムは、分散データベースシステム内の値に対するコンセンサスを達成しようと試みる（例えば、トランザクションが発生する順序に関して）。例えば、オンラインマルチプレーヤゲームは、ユーザがゲームをプレイするためにアクセスすることができる、多くのコンピュータサーバを有する可能性がある。２人のユーザがゲーム内の特定のアイテムを同時にピックアップしようと試みる場合、分散データベースシステム内のサーバが最終的に、２人のユーザのうちのどちらが最初にアイテムをピックアップしたかについての合意に達することが重要となる。
【0004】
そのような分散コンセンサスは、Ｐａｘｏｓアルゴリズム又はその変形などの、方法及び／又はプロセスによって扱うことができる。そのような方法及び／又はプロセスの下では、データベースシステムの１つのサーバが「リーダ」として設定され、リーダがイベントの順序を決定する。（例えば、マルチプレーヤゲーム内の）イベントは、リーダに転送され、リーダがイベントの順序付けを選択し、かつリーダがその順序付けをデータベースシステムの他のサーバにブロードキャストする。
【0005】
ただし、そのような既知のアプローチは、データベースシステムのユーザ（例えば、ゲームのプレーヤ）によって信頼される当事者（例えば、中央管理サーバ）によって運用されるサーバを使用する。したがって、リーダ又は信頼できる第三者がデータベースシステムを操作する必要のない分散データベースシステムのための、方法及び装置が必要とされている。
【発明の概要】
【0006】
いくつかの実施形態では、方法は、分散データベースのためのアドレスブックを定義することを含む。アドレスブックは、ネットワークを介して分散データベースを実装する計算デバイスのセットからの各計算デバイスの識別子を含む。方法は、計算デバイスのセットからの計算デバイスから、アドレスブックを更新するためのトランザクションを含むイベントを受信することと、アドレスブックを使用する分散データベースのコンセンサスプロトコルに基づいて、イベントの受信ラウンドを算出することと、を更に含む。方法は、トランザクションに基づいてアドレスブックを更新して、イベントの受信ラウンド又はアドレスブックへの更新のうちの少なくとも１つの、所定の数のラウンド後に、更新されたアドレスブックを定義することを更に含む。
【図面の簡単な説明】
【0007】
【図1】一実施形態による、分散データベースシステムを例解する高レベルのブロック図である。
【図2】一実施形態による、分散データベースシステムの計算デバイスを例解するブロック図である。
【図3】一実施形態による、ハッシュグラフの例を例解する。
【図4】一実施形態による、ハッシュグラフの例を例解する。
【図5】一実施形態による、ハッシュグラフの例を例解する。
【図6】一実施形態による、ハッシュグラフの例を例解する。
【図7】一実施形態による、第１の計算デバイスと第２の計算デバイスとの間の通信フローを例解するフロー図である。
【図8】一実施形態による、ハッシュグラフの例である。
【図9】一実施形態による、ハッシュグラフの例である。
【図10A】一実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図10B】一実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図11A】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図11B】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図12A】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図12B】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図13A】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図13B】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図13C】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図13D】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図13E】別の実施形態による、ハッシュグラフとともに使用するための例示的なコンセンサス方式を例解する。
【図14】一実施形態による、分散データベースシステムに関連付けられたアドレスブックを例解する。
【図15】一実施形態による、アドレスブックを更新する方法を例解するフローチャートである。
【図16】一実施形態による、計算デバイスが分散データベースに接続及び／又は加入する方法を例解するフローチャートである。
【発明を実施するための形態】
【0008】
いくつかの実施形態では、方法は、分散データベースのためのアドレスブックを定義することを含む。アドレスブックは、ネットワークを介して分散データベースを実装する計算デバイスのセットからの各計算デバイスの識別子を含む。方法は、計算デバイスのセットからの計算デバイスから、アドレスブックを更新するためのトランザクションを含むイベントを受信することと、アドレスブックを使用する分散データベースのコンセンサスプロトコルに基づいて、イベントの受信ラウンドを算出することと、を更に含む。方法は、トランザクションに基づいてアドレスブックを更新して、イベントの受信ラウンド又はアドレスブックへの更新のうちの少なくとも１つの、所定の数のラウンド後に、更新されたアドレスブックを定義することを更に含む。
【0009】
いくつかの実施形態では、装置は、計算デバイスのセットに動作可能に結合されたネットワークを介して、計算デバイスのセットによって実装される分散データベースに関連付けられた、計算デバイスのメモリと、該メモリに動作可能に結合されたプロセッサと、を含む。プロセッサは、分散データベースのためのアドレスブックを定義するように構成されている。アドレスブックは、分散データベースを実装する計算デバイスのセットからの各計算デバイスの識別子を含む。プロセッサは、計算デバイスのセットからの計算デバイスから、アドレスブックを更新するためのトランザクションを含むイベントを受信し、イベントのグループからの各イベントについての属性（例えば、ラウンド番号又は作成されたラウンド）を算出するように構成されている。イベントは、イベントのグループに含まれる。プロセッサは、アドレスブックを使用する分散データベースのコンセンサスプロトコルに基づいて、イベントの受信ラウンドを算出するように構成されている。受信ラウンドは、イベントの子孫であるイベントのセットからの閾値イベント数に基づくことができる。プロセッサは、トランザクションに基づいてアドレスブックを更新して、イベントの受信ラウンド又はアドレスブックへの以前の更新のうちの少なくとも１つの、所定の数のラウンド後に、更新されたアドレスブックを定義するように更に構成されている。プロセッサは、イベントのグループからの各イベントがイベントのセットからの子孫イベントを有しないときに、更新されたアドレスブックを使用して、そのイベントについての属性を再算出するように構成されている。
【0010】
いくつかの実施形態では、非一時的プロセッサ可読媒体は、プロセッサによって実行されるべき命令を表すコードを記憶する。コードは、プロセッサに、ネットワークを介して、分散データベースを実装する計算デバイスのセットに、かつ分散データベースを実装するノードとして、接続させるためのコードを含む。コードは、プロセッサに、計算デバイスのセットからの計算デバイスから、コンセンサスプロトコルの完了したラウンドに関連付けられた分散データベースの状態を受信させるためのコードを更に含む。完了したラウンドに関連付けられたイベントのコアセットの指標を、イベントのコアセットからの各イベントのラウンド識別子とともに含む、状態。コードは、プロセッサに、計算デバイスのセットから、状態に関連付けられたイベントのセットを受信させ、イベントのコアセットと、イベントのコアセットからの各イベントのラウンド識別子と、に基づいて、イベントのセットからの各イベントについての属性のセットを算出させるためのコードを更に含む。コードは、プロセッサに、イベントのセットと、イベントについての属性のセットと、に基づいて、有向非巡回グラフ（directed acyclic graph、ＤＡＧ）を構築させ、該ＤＡＧを使用して、コンセンサスプロトコルの次のラウンドに関連付けられたイベントの順序を算出させるためのコードを含む。
【0011】
いくつかの実施形態では、装置は、第１の計算デバイスにおける分散データベースのインスタンスを含み、この第１の計算デバイスは、計算デバイスのセットに動作可能に結合されたネットワークを介して、分散データベースを実装する計算デバイスのセット内に含まれるように構成されている。装置はまた、分散データベースのインスタンスを記憶するメモリに動作可能に結合されたプロセッサも含む。プロセッサは、第１の時間に、イベントの第１のセットにリンクされた第１のイベントを定義するように構成されている。プロセッサは、第１の時間後の第２の時間に、計算デバイスのセットからの第２の計算デバイスから、（１）第２の計算デバイスによって定義され、かつ（２）イベントの第２のセットにリンクされた、第２のイベントを表す信号を受信するように構成されている。プロセッサは、少なくともプロトコルの結果に基づいて、イベントの第３のセットに関連付けられた順序を識別するように構成される。イベントの第３のセットからの各イベントは、イベントの第１のセット、又はイベントの第２のセット、のうちの少なくとも１つからのものである。プロセッサは、イベントの第３のセットに関連付けられた順序を、分散データベースのインスタンスに記憶するように構成されている。
【0012】
いくつかの場合、イベントの第３のセットからの各イベントは、属性のセット（例えば、シーケンス番号、世代番号、ラウンド番号、受信ラウンド数、及び／又はタイムスタンプなど）に関連付けられている。プロトコルの結果は、イベントの第３のセットからの各イベントについての属性のセットからの各属性に対する値を含むことができる。属性のセットからの第１の属性に対する値は、第１の数値を含むことができ、属性のセットからの第２の属性に対する値は、第１の数値に関連付けられたバイナリ値を含むことができる。イベントの第３のセットからのイベントに対する第２の属性に対するバイナリ値（例えば、ラウンドインクリメント値）は、そのイベントと、そのイベントにリンクされたイベントの第４のセットとの間の関係が、基準（例えば、そのイベントによって強く識別されるイベントの数）を満たすかどうかに基づくことができる。イベントの第４のセットからの各イベントは、（１）イベントの第３のセットからのイベントの先祖であり、かつ（２）イベントの第４のセットからの残りのイベントとして、第１の共通属性（例えば、共通ラウンド番号、ラウンドＲの第１のイベントであるという指標など）に関連付けられている。第１の共通属性は、計算デバイスのセットからの各計算デバイスによって定義されたイベントが、第１の特定の値（例えば、ラウンドＲの第１のイベントであるという指標など）に関連付けられる、第１の／初期のインスタンスを示すことができる。
【0013】
属性のセットからの第３の属性の値（例えば、受信ラウンド数）は、イベントと、イベントにリンクされた、イベントの第５のセットとの間の関係に基づく第２の数値を含むことができる。イベントの第５のセットからの各イベントは、イベントの子孫であり、イベントの第５のセットからの残りのイベントとして、第２の共通属性（例えば、有名である）に関連付けられる。第２の共通属性は、（１）計算デバイスのセットからの各計算デバイスによって定義される第２のイベントが、第１の特定の値とは異なる第２の特定の値に関連付けられる第１のインスタンスを示す第３の共通属性（例えば、ラウンドＲの第１のイベント又はウィットネスである）、及び（２）指標のセットに基づく結果に関連付けられ得る。指標のセットからの各指標は、イベントの第６のセットからのイベントに関連付けることができる。イベントの第６のセットからの各イベントは、第１の／初期のインスタンスを示す第４の共通属性に関連付けることができ、計算デバイスのセットからの各計算デバイスによって定義される第３のイベントは、第１の特定の値及び第２の特定の値とは異なる、第３の特定の値に関連付けられる。いくつかの場合、第１の特定の値は第１の整数（例えば、第１のラウンド番号Ｒ）であり、第２の特定の値は第１の整数よりも大きい第２の整数（例えば、第２のラウンド番号Ｒ＋ｎ）であり、第３の特定の値は第２の整数よりも大きい第３の整数（例えば、第３のラウンド番号Ｒ＋ｎ＋ｍ）である。
【0014】
本明細書で使用される場合、モジュールは、例えば、特定の機能を実施することに関連付けられた、動作可能に結合された電気構成要素の任意のアセンブリ及び／又はセットとすることができ、例えば、メモリ、プロセッサ、電気トレース、光コネクタ、（ハードウェアで実行される）ソフトウェアなどを含むことができる。
【0015】
本明細書で使用される場合、「ａ」、「ａｎ」、及び「ｔｈｅ」という単数形は、文脈が明確にそうでないと指示しない限り、複数の指示対象を含む。したがって、例えば、「モジュール」という用語は、単一のモジュール又はモジュールの組み合わせを意味することが意図される。例えば、「ネットワーク」は、単一のネットワーク又はネットワークの組み合わせを意味することが意図される。
【0016】
図１は、一実施形態による、分散データベースシステム１００を例解する高レベルのブロック図である。図１は、４つの計算デバイス（計算デバイス１１０、計算デバイス１２０、計算デバイス１３０、及び計算デバイス１４０）にわたって実装された分散データベース１００を例解するが、分散データベース１００が、図１には示されていない計算デバイスを含む任意の数の計算デバイスのセットを使用することができることを理解されたい。ネットワーク１０５は、有線ネットワーク及び／又は無線ネットワークとして実装され、かつ計算デバイス１１０、１２０、１３０、１４０を動作可能に結合するために使用される、任意のタイプのネットワーク（例えば、ローカルエリアネットワーク（local area network、ＬＡＮ）、広域ネットワーク（wide area network、ＷＡＮ）、仮想ネットワーク、電気通信ネットワーク）であることができる。本明細書で更に詳細に説明されるように、いくつかの実施形態では、例えば、計算デバイスは、インターネットサービスプロバイダ（Internet Service Provider、ＩＳＰ）及びインターネット（例えば、ネットワーク１０５）を介して互いに接続されたパーソナルコンピュータである。いくつかの実施形態では、ネットワーク１０５を介して、計算デバイス１１０、１２０、１３０、１４０の任意の２つの間で接続を定義することができる。図１に示されるように、例えば、計算デバイス１１０と、計算デバイス１２０、計算デバイス１３０、又は計算デバイス１４０のうちのいずれか１つとの間で接続を定義することができる。
【0017】
いくつかの実施形態では、計算デバイス１１０、１２０、１３０、１４０は、中間ネットワーク及び／又は代替ネットワーク（図１には図示せず）を介して、互いに通信（例えば、互いにデータを送信、及び／又は互いからデータを受信）し、かつネットワークと通信することができる。そのような中間ネットワーク及び／又は代替ネットワークは、ネットワーク１０５と同じタイプ及び／又は異なるタイプのネットワークであることができる。
【0018】
各計算デバイス１１０、１２０、１３０、１４０は、他の計算デバイスのうちの１つ以上にデータを送信及び／又は他の計算デバイスのうちの１つ以上からデータを受信するためにネットワーク１０５上でデータを送信するように構成された、任意のタイプのデバイスとすることができる。図１に、計算デバイスの例を示す。計算デバイス１１０は、メモリ１１２、プロセッサ１１１、及び出力デバイス１１３を含む。メモリ１１２は、例えば、ランダムアクセスメモリ（random access memory、ＲＡＭ）、メモリバッファ、ハードドライブ、データベース、消去可能プログラマブル読み出し専用メモリ（erasable programmable read-only memory、ＥＰＲＯＭ）、電気的消去可能読み出し専用メモリ（electrically erasable read-only memory、ＥＥＰＲＯＭ）、読み出し専用メモリ（read-only memory、ＲＯＭ）などであり得る。いくつかの実施形態では、計算デバイス１１０のメモリ１１２は、分散データベースのインスタンス（例えば、分散データベースインスタンス１１４）に関連付けられたデータを含む。いくつかの実施形態では、メモリ１１２は、プロセッサに、モジュール、プロセス、及び／又は機能を実行させる命令を記憶し、これらのモジュール、プロセス、及び／又は機能は、同期イベントの記録、並びに／又は他の計算デバイスとの前の同期イベントの記録、並びに／又は同期イベントの順序、並びに／又はイベント内のトランザクションの順序、同期イベント及び／若しくはトランザクションの順序を識別することに関連付けられたパラメータ、並びに／又はパラメータの値（例えば、トランザクションを定量化するデータベースフィールド、イベントが発生する順序を定量化するデータベースフィールド、及び／又は値がデータベースに記憶され得る任意の他の好適なフィールド）を、分散データベースの別のインスタンス（例えば、計算デバイス１２０における分散データベースインスタンス１２４）に送信及び／又はそれから受信することに関連付けられている。
【0019】
分散データベースインスタンス１１４は、例えば、データを操作するように構成することができ、データの記憶、修正、及び／又は削除を含む。いくつかの実施形態では、分散データベースインスタンス１１４は、アレイのセット、データ構造のセット、リレーショナルデータベース、オブジェクトデータベース、ポストリレーショナルデータベース、及び／又は任意の他の好適なタイプのデータベース若しくはストレージであり得る。例えば、分散データベースインスタンス１１４は、任意の特定の機能及び／又は産業に関連するデータを記憶することができる。例えば、分散データベースインスタンス１１４は、特定の金融商品の所有権の履歴に関連する値及び／又は値のベクトルを含む、（例えば、計算デバイス１１０のユーザの）金融トランザクションを記憶することができる。一般に、ベクトルは、パラメータの値の任意のセットとすることができ、パラメータは、異なる値をとることができる任意のデータオブジェクト及び／又はデータベースフィールドとすることができる。したがって、分散データベースインスタンス１１４は、いくつかのパラメータ及び／又はフィールドを有することができ、その各々は、値のベクトルに関連付けられる。値のベクトルは、そのデータベースインスタンス１１４内のパラメータ及び／又はフィールドの実際の値を決定するために使用される。いくつかの場合、分散データベースインスタンス１１４は、同期イベントの記録、他の計算デバイスとの前の同期イベントの記録、同期イベントの順序、イベント内のトランザクションの順序、同期イベント及び／又はトランザクションの順序を識別することに関連付けられたパラメータ及び／又は値（例えば、本明細書に説明されるコンセンサス方式を使用して順序を算出する際に使用される）、パラメータの値（例えば、トランザクションを定量化するデータベースフィールド、イベントが発生する順序を定量化するデータベースフィールド、及び／又は値をデータベースに記憶することができる任意の他の好適なフィールド）を記憶する。
【0020】
いくつかの場合、分散データベースインスタンス１１４はまた、データベース状態変数及び／又は現在の状態を記憶することもできる。現在の状態は、トランザクションの結果に関連付けられた状態、残高、条件及び／又は同様のものであり得る。同様に述べると、状態は、トランザクションによって修正されたデータ構造及び／又は変数を含むことができる。他の場合、現在の状態は、別個のデータベース及び／又はメモリ１１２の一部分に記憶することができる。更に他の場合、現在の状態は、計算デバイス１１０とは異なる計算デバイスのメモリに記憶することができる。
【0021】
いくつかの場合、分散データベースインスタンス１１４はまた、（鍵、値）ペアのセットなどの他のデータ構造を実装するために使用することもできる。分散データベースインスタンス１１４によって記録されるトランザクションは、例えば、（鍵、値）ペアのセット内の（鍵、値）ペアの追加、削除、又は修正であり得る。
【0022】
いくつかの場合、分散データベースシステム１００又は分散データベースインスタンス１１４、１２４、１３４、１４４のうちのいずれかにクエリを行うことができる。例えば、クエリは鍵を含むことができ、分散データベースシステム１００又は分散データベースインスタンス１１４、１２４、１３４、１４４から返される結果は、鍵に関連付けられた値とすることができる。また、いくつかの場合、分散データベースシステム１００又は分散データベースインスタンス１１４、１２４、１３４、１４４のうちのいずれかは、トランザクションを通して修正することもできる。例えば、データベースを修正するトランザクションは、修正トランザクションを認可する当事者によるデジタル署名を含むことができる。
【0023】
分散データベースシステム１００は、例えば、様々なユーザに関連付けられた属性を分散識別情報システムに記憶するなど、多くの目的で使用することができる。例えば、そのようなシステムは、ユーザの識別情報及び／又は識別子を「鍵」として使用し、ユーザに関連付けられた属性のリストを「値」として使用することができる。いくつかの場合、識別情報及び／又は識別子は、そのユーザに知られている対応する秘密鍵を有する暗号公開鍵であり得る。各属性は、例えば、その属性をアサートする権利を有する機関によってデジタル署名され得る。各属性は、例えば、属性を読み出す権利を有する個人又は個人のグループに関連付けられた公開鍵を用いて暗号化することもできる。いくつかの鍵又は値は、鍵又は値を修正及び／又は削除することを認可された当事者の公開鍵のリストを、これらの鍵又は値に添付することもできる。
【0024】
別の例では、分散データベースインスタンス１１４は、ゲームプレイアイテムの現在のステータス及び所有権などの多人数同時参加型ゲーム（Massively Multiplayer Game、ＭＭＧ）に関連するデータを記憶することができる。いくつかの場合、分散データベースインスタンス１１４は、図１に示されるように、計算デバイス１１０内に実装することができる。他の場合、分散データベースのインスタンスは、計算デバイスによって（例えば、ネットワークを介して）アクセス可能であるが、計算デバイス内には実装されない（図１には図示せず）。
【0025】
計算デバイス１１０のプロセッサ１１１は、分散データベースインスタンス１１４を走らせるかつ／又は実行するように構成された、任意の好適な処理デバイスであり得る。例えば、プロセッサ１１１は、本明細書で更に詳細に説明されるように、計算デバイス１２０から信号を受信することに応答して分散データベースインスタンス１１４を更新し、かつ／又は信号を計算デバイス１２０に送信させるように構成することができる。より具体的には、本明細書で更に詳細に説明されるように、プロセッサ１１１は、別の計算デバイスからのトランザクションに関連付けられた同期イベント、同期イベントの順序に関連付けられた記録、及び／又は同様のものを受信することに応答して分散データベースインスタンス１１４を更新するための、モジュール、機能、及び／又はプロセスを実行するように構成することができる。いくつかの実施形態では、プロセッサ１１１は、分散データベースの別のインスタンス（例えば、計算デバイス１２０における分散データベースインスタンス１２４）に記憶されたパラメータの値を受信することに応答して分散データベースインスタンス１１４を更新するための、かつ／又は計算デバイス１１０における分散データベースインスタンス１１４に記憶されたパラメータの値を計算デバイス１２０に送信させるための、モジュール、機能、及び／又はプロセスを実行するように構成することができる。いくつかの実施形態では、プロセッサ１１１は、汎用プロセッサ、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array、ＦＰＧＡ）、特定用途向け集積回路（Application Specific Integrated Circuit、ＡＳＩＣ）、デジタル信号プロセッサ（Digital Signal Processor、ＤＳＰ）などであり得る。
【0026】
ディスプレイ１１３は、液晶ディスプレイ（liquid crystal display、ＬＣＤ）、陰極線管ディスプレイ（cathode ray tube display、ＣＲＴ）などの任意の好適なディスプレイであり得る。他の実施形態では、計算デバイス１１０、１２０、１３０、１４０のいずれかは、ディスプレイ１１３、１２３、１３３、１４３の代わりに、又はそれに加えて、別の出力デバイスを含む。例えば、計算デバイス１１０、１２０、１３０、１４０のうちのいずれか１つは、音声出力デバイス（例えば、スピーカ）、触覚出力デバイス、及び／又は同様のものを含むことができる。更に他の実施形態では、計算デバイス１１０、１２０、１３０、１４０のいずれかは、ディスプレイ１１３、１２３、１３３、１４３の代わりに、又はそれに加えて、入力デバイスを含む。例えば、計算デバイス１１０、１２０、１３０、１４０のうちのいずれか１つは、キーボード、マウス、及び／又は同様のものを含むことができる。
【0027】
図１では単一の計算デバイス内にあるように示されているが、いくつかの場合、分散データベースを更新するためのモジュール、機能、及び／又はプロセスを実行するように構成されたプロセッサは、その関連付けられた分散データベースとは別個の計算デバイス内にあり得る。そのような場合、例えば、プロセッサは、ネットワークを介して分散データベースインスタンスに動作可能に結合することができる。例えば、プロセッサは、（例えば他の分散データベースインスタンスとの同期の結果として）イベント及び／又はトランザクションの順序を識別するためにコンセンサス方式を実行することができ、かつイベント及び／又はトランザクションの順序を含む信号を、関連する分散データベースインスタンスにネットワークを介して送信することができる。次いで、関連付けられた分散データベースインスタンスは、イベントの順序、トランザクションの順序、及び／又はトランザクションの順序に基づく状態変数を、関連付けられた分散データベースインスタンスに記憶することができる。このように、分散データベースに関連付けられた機能及びストレージを分散させることができる。更に、データベースが、分散データベースシステムに関連付けられたモジュール、機能、及び／又はプロセス（例えば、コンセンサス方式）を実装するプロセッサを有する計算デバイスとは別個の計算デバイス内に実装される場合であっても、プロセッサは、その関連付けられた分散データベースインスタンスにクエリを行い、データベース状態変数及び／又は現在の状態、並びに本明細書に説明される他の好適な動作を、その分散データベースインスタンス内に記憶することができる。他の場合、本明細書に説明される機能及び／又は方法は、任意の数の計算デバイスにわたって（例えば、分散コンピューティング環境及び／又はクラスタ内で）実行することができ、そのような機能及び／又は方法の結果及び／又は値は、任意の好適な計算デバイスにおけるメモリ及び／又はストレージに記憶することができる。
【0028】
計算デバイス１２０は、プロセッサ１２１、メモリ１２２、及びディスプレイ１２３を有し、これらはそれぞれ、プロセッサ１１１、メモリ１１２、及びディスプレイ１１３と構造的及び／又は機能的に同様であり得る。また、分散データベースインスタンス１２４は、分散データベースインスタンス１１４と構造的及び／又は機能的に類似し得る。
【0029】
計算デバイス１３０は、プロセッサ１３１、メモリ１３２、及びディスプレイ１３３を有し、これらはそれぞれ、プロセッサ１１１、メモリ１１２、及びディスプレイ１１３と構造的及び／又は機能的に同様であり得る。また、分散データベースインスタンス１３４は、分散データベースインスタンス１１４と構造的及び／又は機能的に類似し得る。
【0030】
計算デバイス１４０は、プロセッサ１４１、メモリ１４２、及びディスプレイ１４３を有し、これらはそれぞれ、プロセッサ１１１、メモリ１１２、及びディスプレイ１１３と構造的及び／又は機能的に同様であり得る。また、分散データベースインスタンス１４４は、分散データベースインスタンス１１４と構造的及び／又は機能的に類似し得る。
【0031】
計算デバイス１１０、１２０、１３０、１４０は、互いに類似しているものとして示されているが、分散データベースシステム１００の各計算デバイスは、他の計算デバイスとは異なり得る。分散データベースシステム１００の各計算デバイス１１０、１２０、１３０、１４０は、例えば、コンピューティングエンティティ（例えば、デスクトップコンピュータ、ラップトップコンピュータなどのパーソナルコンピューティングデバイス）、携帯電話、携帯情報端末（personal digital assistant、ＰＤＡ）などのうちのいずれか１つであり得る。例えば、計算デバイス１１０はデスクトップコンピュータであり得、計算デバイス１２０はスマートフォンであり得、計算デバイス１３０はサーバであり得る。
【0032】
いくつかの実施形態では、計算デバイス１１０、１２０、１３０、１４０のうちの１つ以上の部分は、ハードウェアベースのモジュール（例えば、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ））及び／又はソフトウェアベースのモジュール（例えば、メモリに記憶された及び／又はプロセッサで実行される、コンピュータコードのモジュール）を含むことができる。いくつかの実施形態では、計算デバイス１１０、１２０、１３０、１４０に関連付けられた機能（例えば、プロセッサ１１１、１２１、１３１、１４１に関連付けられた機能）のうちの１つ以上は、１つ以上のモジュール（例えば、図２を参照のこと）に含まれ得る。
【0033】
計算デバイス（例えば、計算デバイス１１０、１２０、１３０、１４０）のプロパティ、計算デバイスの数、及びネットワーク１０５を含む、分散データベースシステム１００のプロパティは、任意の数の方法で選択され得る。いくつかの場合、分散データベースシステム１００のプロパティは、分散データベースシステム１００の管理者によって選択され得る。他の場合、分散データベースシステム１００のプロパティは、分散データベースシステム１００のユーザによって集合的に選択され得る。
【0034】
分散データベースシステム１００が使用されるため、計算デバイス１１０、１２０、１３０、及び１４０の間で、リーダは指名されない。具体的には、計算デバイス１１０、１２０、１３０、又は１４０のいずれも、計算デバイス１１０、１２０、１３０、１４０の分散データベースインスタンス１１４、１２４、１３４、１４４に記憶された値間の紛争を解決するためのリーダとして識別及び／又は選択されない。代わりに、イベント同期プロセス、投票プロセス、コンセンサス方式及び／若しくはプロトコル、並びに／又は本明細書に説明される他の方法を使用して、計算デバイス１１０、１２０、１３０、１４０は、パラメータの値に集合的に収束することができる。
【0035】
分散データベースシステムにリーダを有しないことにより、分散データベースシステムのセキュリティを増加させる。具体的には、リーダがある状態では、単一の攻撃点及び／又は障害点が存在する。悪意のあるソフトウェアがリーダに感染した場合、かつ／又はリーダの分散データベースインスタンスにおけるパラメータの値が悪意を持って改ざんされた場合、障害及び／又は不正確な値が、他の分散データベースインスタンス全体に伝搬される。しかしながら、リーダのないシステムでは、攻撃及び／又は障害の単一点は存在しない。具体的には、リーダのないシステムの分散データベースインスタンス内のパラメータが値を含む場合、その値は、本明細書で更に詳細に説明されるように、その分散データベースインスタンスがシステム内の他の分散データベースインスタンスと値を交換した後に変化する。追加的に、本明細書に説明される、リーダのない分散データベースシステムは、本明細書で更に詳細に説明されるように、デバイス間で送信されるデータの量を低減しながら収束の速度を増加させる。
【0036】
図２は、一実施形態による、分散データベースシステム（例えば、分散データベースシステム１００）の計算デバイス２００を例解する。いくつかの実施形態では、計算デバイス２００は、図１に関して図示及び説明された計算デバイス１１０、１２０、１３０、１４０と同様であり得る。計算デバイス２００は、プロセッサ２１０及びメモリ２２０を含む。プロセッサ２１０及びメモリ２２０は、互いに動作可能に結合される。いくつかの実施形態では、プロセッサ２１０及びメモリ２２０は、それぞれ、図１に関して詳細に説明されたプロセッサ１１１及びメモリ１１２と同様であり得る。図２に示されるように、プロセッサ２１０は、データベース収束モジュール２１１及び通信モジュール２１０を含み、メモリ２２０は、分散データベースインスタンス２２１を含む。通信モジュール２１２は、計算デバイス２００が他の計算デバイスと通信すること（例えば、他の計算デバイスにデータを送信すること、及び／又は他の計算デバイスからデータを受信すること）を可能にする。いくつかの実施形態では、通信モジュール２１２（図１には図示せず）は、計算デバイス１１０が計算デバイス１２０、１３０、１４０と通信することを可能にする。通信モジュール２１０は、例えば、ネットワークインターフェースコントローラ（network interface controller、ＮＩＣ）、無線接続、有線ポート、及び／又は同様のものを含むことができ、かつ／又はそれらを可能にすることができる。そのため、通信モジュール２１０は、（例えば、図１のネットワーク１０５又はインターネット（図示せず）などのネットワークを介して）計算デバイス２００と別のデバイスとの間の通信セッションを確立及び／又は維持することができる。同様に述べると、通信モジュール２１０は、計算デバイス２００が別のデバイスにデータを送信すること、及び／又は別のデバイスからデータを受信することを可能にすることができる。
【0037】
いくつかの場合、データベース収束モジュール２１１は、イベント及び／又はトランザクションを他の計算デバイスと交換し、データベース収束モジュール２１１が受信するイベント及び／又はトランザクションを記憶し、イベント間の参照のパターンによって定義された半順序に基づいて、イベント及び／又はトランザクションの順序付け（例えば、コンセンサス又は全順序）を算出することができる。各イベントは、（そのイベントを先の２つのイベント及びそれらの先祖イベントにリンクする、かつその逆も同様の）先の２つのイベントの識別子（例えば、暗号ハッシュ）、ペイロードデータ（記録されるトランザクションなど）、現在時刻、イベントの作成者がそのイベントが最初に定義された時刻であるとアサートするタイムスタンプ（例えば、日付及びＵＴＣ時刻）などの他の情報、及び／又は同様のものを含む記録であり得る。通信している計算デバイスの各々は、「メンバ」又は「ハッシュグラフメンバ」と呼ばれる。いくつかの場合、メンバによって定義された第１のイベントは、別のメンバによって定義された単一のイベントのハッシュのみを含む。そのような場合、メンバは、前の自己ハッシュ（例えば、そのメンバによって以前に定義されたイベントのハッシュ）をまだ有していない。いくつかの場合、分散データベース内の第１のイベントは、（その分散データベースに対して前のイベントが存在しないため）任意の前のイベントのハッシュを含まない。
【0038】
いくつかの実施形態では、先の２つのイベントのそのような暗号ハッシュは、イベントを入力として使用する暗号ハッシュ関数に基づいて定義されるハッシュ値であり得る。具体的には、そのような実施形態では、イベントは、（そのイベントの情報を表す）バイトの特定のシーケンス又はストリングを含む。イベントのハッシュは、そのイベントに対するバイトのシーケンスを入力として使用してハッシュ関数から返される値であり得る。他の実施形態では、イベントに関連付けられた任意の他の好適なデータ（例えば、識別子、シリアル番号、イベントの特定の部分を表すバイトなど）をハッシュ関数への入力として使用して、そのイベントのハッシュを算出することができる。任意の好適なハッシュ関数は、ハッシュを定義するために使用することができる。いくつかの実施形態では、各メンバは、所与のイベントに対して各メンバで同じハッシュが生成されるように、同じハッシュ関数を使用する。次いで、イベントは、イベントを定義及び／又は作成するメンバによってデジタル署名され得る。いくつかの実装形態では、ハッシュ値ではなく、イベントの任意の他の好適な識別子が使用され得る。
【0039】
いくつかの場合、イベントのセット及びそれらの相互接続は、有向非巡回グラフ（ＤＡＧ）を形成し得る。いくつかの場合、ＤＡＧ内の各イベントは、（そのイベントを先のイベント及びそれらの先祖イベントにリンクする、かつ逆もまた同様の）０以上（例えば、２つ）前のイベントを参照し、各参照は、厳密に先のイベントに対するものであるため、ループは存在しない。いくつかの実施形態では、ＤＡＧは暗号ハッシュに基づいているため、データ構造は、ハッシュグラフと呼ぶことができる（本明細書では「ｈａｓｈＤＡＧ」とも呼ばれる）。他の実施形態では、ＤＡＧは、イベントの任意の他の好適な識別子に基づくことができる。ハッシュグラフ又はＤＡＧは、半順序を直接符号化し、これは、ＹがＸのハッシュを含む場合、又はＸのハッシュを含むイベントのハッシュをＹが含む場合、又は任意の長さのそのような経路について、イベントＸがイベントＹの前に来ることが既知であることを意味する。ただし、ＸからＹへ、又はＹからＸへの経路がない場合、半順序は、どのイベントが最初に来たかを定義しない。したがって、データベース収束モジュールは、半順序から、全順序又はコンセンサス順序を算出することができる。これは、計算デバイスが同じ順序を算出するように、計算デバイスによって使用される任意の好適な決定論的関数によって行うことができる。いくつかの実施形態では、各メンバは、各同期後にこの順序を再算出することができ、最終的に、これらの順序は、コンセンサスが出現するように収束し得る。
【0040】
コンセンサスアルゴリズム及び／又は方法は、ハッシュグラフ、ＤＡＧ内のイベントの全順序若しくはコンセンサス順序、及び／又はイベント内に記憶されたトランザクションの順序を決定するために使用することができる。トランザクションの順序は同様に、順序に従ってそれらのトランザクションを実施した結果として、データベースの状態を定義し得る。定義されたデータベースの状態は、データベース状態変数として記憶され得る。いくつかの実施形態では、分散データベースのインスタンス（例えば、分散データベースインスタンス１１４）は、ハッシュグラフ、及び／又はトランザクション、及び／又はトランザクションの順序、及び／又はイベント、及び／又はイベントの順序、及び／又はトランザクションを実施したことから生じる状態を記憶する。
【0041】
いくつかの場合、データベース収束モジュールは、以下の関数を使用して、ハッシュグラフ内の半順序から全順序（コンセンサス順序とも呼ばれる）を算出することができる。他の計算デバイスの各々（「メンバ」と呼ばれる）について、データベース収束モジュールは、ハッシュグラフを調べて、イベント（及び／又はそれらのイベントの指標）がそのメンバによって受信された順序を発見することができる。次いで、データベース収束モジュールは、そのメンバが各イベントに数値の「ランク」を割り当てたかのように算出することができ、ランクは、そのメンバが受信した第１のイベントに対して１であり、そのメンバが受信した第２のイベントに対して２であり、以下同様である。データベース収束モジュールは、ハッシュグラフ内の各メンバについてこれを行うことができる。次いで、各イベントについて、データベース収束モジュールは、割り当てられたランクの中央値を算出することができ、それらの中央値によってイベントをソートすることができる。ソートは、２つの同順位のイベントをそれらのハッシュの数値順によってソートすること、又は各メンバのデータベース収束モジュールが同じ方法を使用する他の何らかの方法によるなど、決定論的なやり方で均衡を破ることができる。このソートの結果が全順序である。
【0042】
図６は、半順序から全順序（又はコンセンサス順序）を決定するための一例のハッシュグラフ６４０を例解する。ハッシュグラフ６４０は、２つのイベント（最も下のストライプ模様の円及び最も下のドット模様の円）と、各メンバがそれらのイベントの指標を最初に受信するとき（他のストライプ模様の円及びドット模様の円）と、を例解する。上部における各メンバの名前は、どのイベントがそれらの半順序又は遅い順で最初であるかによって色付けされる。ドット模様よりもストライプ模様の初期投票の方が多く、したがって、これらのメンバの各々に対するコンセンサス投票は、ストライプ模様である。言い換えれば、メンバは、最終的に、ストライプ模様のイベントがドット模様のイベントの前に発生したという合意に収束する。
【0043】
この例では、メンバ（Ａｌｉｃｅ、Ｂｏｂ、Ｃａｒｏｌ、Ｄａｖｅ、及びＥｄとラベル付けされた計算デバイス）は、イベント６４２が最初に発生したか又はイベント６４４が最初に発生したかのコンセンサスを定義するように機能する。ストライプ模様の各円は、メンバがイベント６４４（及び／又はそのイベント６４４の指標）を最初に受信したイベントを示す。同様に、ドット模様の各円は、メンバがイベント６４２（及び／又はそのイベント６４２の指標）を最初に受信したイベントを示す。ハッシュグラフ６４０に示されるように、Ａｌｉｃｅ、Ｂｏｂ、及びＣａｒｏｌは各々、イベント６４２の前にイベント６４４（及び／又はイベント６４４の指標）を受信した。Ｄａｖｅ及びＥｄは両方とも、イベント６４４（及び／又はイベント６４４の指標）の前にイベント６４２（及び／又はイベント６４２の指標）を受信した。したがって、より多くのメンバがイベント６４２の前にイベント６４４を受信したので、各メンバによって、イベント６４４がイベント６４２の前に発生したことを示すための全順序を決定することができる。
【0044】
他の場合、データベース収束モジュールは、異なる関数を使用して、ハッシュグラフにおける半順序から全順序及び／又はコンセンサス順序を算出することができる。そのような実施形態では、例えば、データベース収束モジュールは、全順序を算出するために、以下の関数を使用することができ、式中、正の整数Ｑは、メンバによって共有されるパラメータである。
【0045】
【数1】
【0046】
この実施形態では、ｆａｓｔ（ｘ，ｙ）は、ｘが作成及び／又は定義されたほぼ直後に、ｃｒｅａｔｏｒ（ｘ）の意見によってイベントの全順序におけるｙの位置を与える。Ｑが無限大である場合、上記は、先で説明される実施形態と同じ全順序を算出する。Ｑが有限であり、かつ全てのメンバがオンラインである場合、上記は、先で説明される実施形態と同じ全順序を算出する。Ｑが有限であり、かつ少数のメンバが所与の時間にオンラインである場合、この関数により、オンラインメンバは、それらの間で、新しいメンバが１つずつゆっくりとオンラインになる際にも変更されないコンセンサスに達することができる。しかしながら、ネットワークの分割が存在する場合、各分割のメンバは、それらメンバ自体のコンセンサスに達することができる。次いで、分割が修復されると、より小さい分割のメンバは、より大きい分割のコンセンサスを採用する。
【0047】
更に他の場合、図８～図１３Ｅに関して説明されるように、データベース収束モジュールは、異なる関数を使用して、ハッシュグラフにおける半順序から全順序を算出することができる。図８～図９に示されるように、各メンバ（Ａｌｉｃｅ、Ｂｏｂ、Ｃａｒｏｌ、Ｄａｖｅ、及びＥｄ）は、イベント（図８に示される１４０１～１４１３、図９に示される１５０１～１５０６）を作成及び／又は定義する。図８～図１３Ｅに関して説明される関数及びサブ関数を使用して、イベントの全順序は、本明細書で更に詳細に説明されるように、イベントをそれらの受信ラウンドによってソートし、それらの受信タイムスタンプによって均衡を破り、それらの署名によってそれらの均衡を破ることによって、算出することができる。他の場合、イベントの全順序は、イベントをそれらの受信ラウンドによってソートし、（それらの受信タイムスタンプの代わりに）それらの受信世代によって均衡を破り、それらの署名によってそれらの均衡を破ることによって、算出することができる。以下の段落では、イベントの順序を決定するために、イベントの受信ラウンド及び受信世代を算出及び／又は定義するために使用される関数について詳細を記述する。以下の用語が、図８～図１３Ｅに関連して使用及び例解される。
【0048】
「親」：ＹがＸのハッシュを含む場合、イベントＸはイベントＹの親である。例えば、図８では、イベント１４１２の親は、イベント１４０６及びイベント１４０８を含む。
【0049】
「先祖」：イベントＸの先祖は、Ｘ、Ｘの親、Ｘの親の親、以下同様である。例えば、図８では、イベント１４１２の先祖は、イベント１４０１、１４０２、１４０３、１４０６、１４０８、及び１４１２である。イベントの先祖は、そのイベントにリンクされていると言うことができ、逆もまた同様である。
【0050】
「子孫」：イベントＸの子孫は、Ｘ、Ｘの子、Ｘの子の子、以下同様である。例えば、図８では、イベント１４０１の子孫は、図に示される全てのイベントである。別の例では、イベント１４０３の子孫はイベント１４０３、１４０４、１４０６、１４０７、１４０９、１４１０、１４１１、１４１２、及び１４１３である。イベントの子孫は、そのイベントにリンクされていると言うことができ、逆もまた同様である。
【0051】
「Ｎ」：母集団中のメンバの総数。例えば、図８では、メンバは、Ａｌｉｃｅ、Ｂｏｂ、Ｃａｒｏｌ、Ｄａｖｅ、及びＥｄとラベル付けされた計算デバイスであり、Ｎは５に等しい。
【0052】
「Ｍ」：Ｎの一定の割合よりも大きい（例えば、Ｎの２／３よりも大きい）最小整数。例えば、図８では、割合が２／３であると定義される場合、Ｍは４に等しい。他の場合、Ｍは、例えば、Ｎの異なる割合（例えば、１／３、１／２など）、特定の事前定義された数、及び／又は任意の他の好適な様式であるように定義され得る。
【0053】
「自身の親」：イベントＸの自身の親は、同じメンバによって作成及び／又は定義された、Ｘの親イベントＹである。例えば、図８では、イベント１４０５の自身の親は１４０１である。
【0054】
「自身の先祖」：イベントＸの自身の先祖は、Ｘ、Ｘの自身の親、Ｘの自身の親の自身の親、以下同様である。
【0055】
「シーケンス番号（Sequence Number）」（又は「ＳＮ」）：イベントの整数属性であり、イベントの自身の親のシーケンス番号に１を加えたものとして定義される。例えば、図８では、イベント１４０５の自身の親は１４０１である。イベント１４０１のシーケンス番号は１であるので、イベント１４０５のシーケンス番号は２（すなわち、１に１を加えたもの）である。
【0056】
「世代番号（Generation Number）」（又は「ＧＮ」）：イベントの整数属性であり、イベントの親の世代番号の最大値に１を加えたものとして定義される。例えば、図８では、イベント１４１２は、２つの親、イベント１４０６及び１４０８を有し、それぞれ世代番号４及び２を有している。したがって、イベント１４１２の世代番号は５（すなわち、４に１を加えたもの）である。
【0057】
「ラウンド増分（Round Increment）」（又は「ＲＩ」）：イベントの属性であり、０又は１のいずれかであり得る。
【0058】
「ラウンド番号（Round Number）」（又は「ＲＮ」）：イベントの整数属性。いくつかの場合、これは、作成されたラウンド（round created）又は作成されたラウンド（created round）とも呼ばれる。いくつかの場合、ラウンド番号は、イベントの親のラウンド番号の最大値にイベントのラウンド増分を加えたものとして定義することができる。例えば、図８において、イベント１４１２は、２つの親、イベント１４０６及び１４０８を有し、両方ともラウンド番号１を有する。イベント１４１２はまた、ラウンド増分１を有する。したがって、イベント１４１２のラウンド番号は２（すなわち、１に１を加えたもの）である。他の場合、イベントは、Ｒが、全てがラウンド番号Ｒ－１を有する異なるメンバによって定義及び／又は作成される少なくともＭ個のイベントをイベントが強く見る（本明細書に説明される）ことができるような最小整数である場合に、ラウンド番号Ｒを有することができる。そのような整数が存在しない場合、イベントのラウンド番号は、デフォルト値（例えば、０、１など）であることができる。そのような場合、イベントのラウンド番号は、ラウンド増分を使用せずに算出することができる。例えば、図８において、ＭがＮの１／２倍よりも大きい最小整数であると定義される場合、Ｍは３である。この場合、イベント１４１２は、各々が異なるメンバによって定義された、ラウンド番号１を有するＭ個のイベント１４０１、１４０２、及び１４０８を強く見ている。イベント１４１２は、異なるメンバによって定義された、ラウンド番号２を有する少なくともＭ個のイベントを強く見ることができない。したがって、イベント１４１２のラウンド番号は２である。いくつかの場合、分散データベースにおける第１のイベントは、ラウンド番号１を含む。他の場合、分散データベースにおける第１のイベントは、０又は任意の他の好適な数のラウンド番号を含むことができる。
【0059】
「フォーキング」：イベントＸ及びイベントＹが同じメンバによって定義及び／又は作成され、かつどちらも他方の自身の先祖でない場合、イベントＸは、イベントＹとのフォークである。例えば、図９では、メンバＤａｖｅは、両方が同じ自身の親（すなわち、イベント１５０１）を有するイベント１５０３及び１５０４を作成及び／又は定義することによってフォークさせ、これによりイベント１５０３はイベント１５０４の自身の先祖ではなく、イベント１５０４はイベント１５０３の自身の先祖ではない。
【0060】
フォーキングの「識別」：フォーキングは、互いにフォークである２つのイベントの後に作成及び／又は定義された第３のイベントによって、これらの２つのイベントが両方とも第３のイベントの先祖である場合に、「識別」することができる。例えば、図９では、メンバＤａｖｅは、イベント１５０３及び１５０４を作成することによってフォークし、そのいずれも他方の自身の先祖ではない。イベント１５０３及び１５０４が両方ともイベント１５０６の先祖であるため、このフォークは、後のイベント１５０６によって識別することができる。いくつかの場合、フォークの識別は、特定のメンバ（例えば、Ｄａｖｅ）が不正を行ったことを示すことができる。
【0061】
イベントの「識別」：イベントＸが、イベントＹとのフォークである先祖イベントＺを有しない場合、Ｘは、先祖イベントＹを「識別する」又は「見る」。例えば、図８では、イベント１４０３がイベント１４１２の先祖であり、かつイベント１４１２が、イベント１４０３とのフォークである先祖イベントを有しないため、イベント１４１２は、イベント１４０３を識別する（「見る」とも呼ばれる）。いくつかの場合、イベントＸは、ＸがイベントＹの以前のフォーキングを識別しない場合、イベントＹを識別することができる。そのような場合、イベントＸが、イベントＹに後続するイベントＹを定義するメンバによるフォーキングを識別したとしても、イベントＸはイベントＹを見ることができる。イベントＸは、フォーキングに後続するそのメンバによるイベントを識別しない。更に、メンバが、両方ともがそのメンバの履歴における第１のイベントである２つの異なるイベントを定義する場合、イベントＸは、フォーキングを識別することができ、そのメンバによるイベントを識別しない。
【0062】
イベントの「強い識別」（本明細書では「強く見ること」とも呼ばれる）：イベントＸは、ＸがＹを識別する場合、Ｘと同じメンバによって作成及び／又は定義された先祖イベントＹを「強く識別する」（又は「強く見る」）。（１）Ｘ及びＹの両方を含み、（２）イベントＸの先祖であり、（３）先祖イベントＹの子孫であり、（４）Ｘによって識別され、（５）各々がＹを識別することができ、（６）少なくともＭ個の異なるメンバによって作成及び／又は定義される、イベントのセットＳが存在する場合、イベントＸは、Ｘと同じメンバによって作成及び／又は定義されない先祖イベントＹを「強く識別」する。例えば、図８では、ＭがＮの２／３よりも大きい最小整数であると定義される場合（すなわち、Ｍ＝１＋ｆｌｏｏｒ（２Ｎ／３）であり、これはこの例では４であり得る）、イベント１４１２は、先祖イベント１４０１を強く識別する。なぜなら、イベント１４０１、１４０２、１４０６、及び１４１２のセットは、イベント１４１２の先祖でありかつイベント１４０１の子孫である少なくとも４つのイベントのセットであり、それらは、それぞれ、４つのメンバＤａｖｅ、Ｃａｒｏｌ、Ｂｏｂ、及びＥｄによって作成及び／又は定義され、イベント１４１２は、イベント１４０１、１４０２、１４０６、及び１４１２の各々を識別し、イベント１４０１、１４０２、１４０６、及び１４１２の各々は、イベント１４０１を識別するからである。同様に述べると、イベントＸ（例えば、イベント１４１２）は、Ｘが、各々がＹを見ることができる異なるメンバによって作成又は定義された、少なくともＭ個のイベント（例えば、イベント１４０１、１４０２、１４０６、及び１４１２）を見ることができる場合、イベントＹ（例えば、イベント１４０１）を「強く見る」ことができる。
【0063】
「ラウンドＲの第１」イベント（本明細書では「ウィットネス」とも呼ばれる）：あるイベントが、（１）ラウンド番号Ｒを有し、（２）Ｒよりも小さいラウンド番号を有する自身の親を有するか又は自身の親を有しない場合、そのイベントは「ラウンドＲの第１」イベント（又は「ウィットネス」）である。例えば、図８では、イベント１４１２は、ラウンド番号２を有し、その自身の親がラウンド番号１（すなわち、２よりも小さい）を有するイベント１４０８であるので、「ラウンド２の第１」イベントである。
【0064】
いくつかの場合、イベントＸのラウンド増分は、Ｘが少なくともＭ個の「ラウンドＲの第１」イベントを「強く識別する」場合に限り、１であると定義され、ここで、Ｒはその親の最大ラウンド番号である。例えば、図８において、ＭがＮの１／２倍よりも大きい最小整数であると定義される場合、Ｍは３である。次いで、イベント１４１２は、全てがラウンド１の第１のイベントであるＭ個のイベント１４０１、１４０２、及び１４０８を強く識別する。１４１２の両方の親はラウンド番号１を有し、１４１２は少なくともＭ個のラウンド１の第１のイベントを強く識別し、したがって、１４１２のラウンド増分は１である。「ＲＩ＝０」とマークされた図中のイベントは各々、少なくともＭ個のラウンド１の第１のイベントを強く識別することに失敗し、したがって、それらのラウンド増分は０である。
【0065】
いくつかの場合、以下の方法を使用して、イベントＸが先祖イベントＹを強く識別できるかどうかを判断することができる。ラウンドＲの第１の各先祖イベントＹについて、メンバごとに１つの整数の配列Ａ１を維持し、イベントＸの最も低いシーケンス番号を与えると、そのメンバがイベントＸを作成及び／又は定義した場合、ＸはＹを識別できる。各イベントＺについて、ＺがＷを識別することができるように、そのメンバによって作成及び／又は定義されたイベントＷの最も高いシーケンス番号を与え、メンバごとに１つの整数の配列Ａ２を維持する。Ｚが先祖イベントＹを強く識別できるかどうかを判断するためには、Ａ１［Ｅ］≦Ａ２［Ｅ］であるような要素位置Ｅの数をカウントする。イベントＺは、このカウントがＭよりも大きい場合に限り、Ｙを強く識別することができる。例えば、図８では、メンバＡｌｉｃｅ、Ｂｏｂ、Ｃａｒｏｌ、Ｄａｖｅ、及びＥｄは各々、イベント１４０１を識別することができ、ここで、識別することができる最古のイベントは、それぞれ、それらのメンバのイベント｛１４０４、１４０３、１４０２、１４０１、１４０８｝である。これらのイベントは、シーケンス番号Ａ１＝｛１，１，１，１，１｝を有する。同様に、イベント１４１２によって識別される、メンバの各々による最新のイベントは、イベント｛なし、１４０６、１４０２、１４０１、１４１２｝であり、ここで、１４１２はＡｌｉｃｅによるイベントを識別することができないため、Ａｌｉｃｅは「なし」としてリストされる。これらのイベントは、それぞれシーケンス番号Ａ２＝｛０，２，１，１，２｝を有し、ここで、全てのイベントが正のシーケンス番号を有するので、０は、Ａｌｉｃｅが１４１２によって識別されるイベントを有しないことを意味する。リストＡ１をリストＡ２と比較すると、結果｛１≦０，１≦２，１≦１，１≦１，１≦２｝が与えられ、これは、真である４つの値を有する｛偽，真，真，真，真｝に等しい。したがって、１４１２の先祖でありかつ１４０１の子孫である４つのイベントのセットＳが存在する。４は少なくともＭであり、したがって、１４１２は１４０１を強く識別する。
【0066】
Ａ１及びＡ２を用いてイベントＸが先祖イベントＹを強く識別できるかどうかを判断するための方法を実装する更に別の変形は、以下のとおりである。両方の配列内の整数要素が１２８未満である場合、各要素を１バイトに記憶し、そのような８つの要素を６４ビットの１ワードにパックし、Ａ１及びＡ２をそのようなワードの配列とすることが可能である。Ａ１内の各バイトの最上位ビットは０に設定することができ、Ａ２内の各バイトの最上位ビットは１に設定することができる。対応する２つのワードを減算し、次いで、最上位ビットを除く全てを０にするマスクを用いてビットごとのＡＮＤを実施し、次いで、７ビット位置だけ右シフトして、Ｃプログラミング言語で、（（Ａ２［ｉ］－Ａ１［ｉ］）＆０ｘ８０８０８０８０８０８０８０８０）＞＞７）と表される値を得る。これは、０に初期化された実行アキュムレータＳに加算することができる。これを複数回行った後、バイトをシフト及び加算することによってアキュムレータをカウントに変換して、（（Ｓ＆０ｘｆｆ）＋（（Ｓ＞＞８）＆０ｘｆｆ）＋（（Ｓ＞＞１６）＆０ｘｆｆ）＋（（Ｓ＞＞２４）＆０ｘｆｆ）＋（（Ｓ＞＞３２）＆０ｘｆｆ）＋（（Ｓ＞＞４０）＆０ｘｆｆ）＋（（Ｓ＞＞４８）＆０ｘｆｆ）＋（（Ｓ＞＞５６）＆０ｘｆｆ））を得る。いくつかの場合、これらの算出は、Ｃ、Ｊａｖａ、及び／又は同様のプログラミング言語で実施することができる。他の場合、算出は、Ｉｎｔｅｌ及びＡＭＤによって提供されるAdvanced Vector Extensions（ＡＶＸ）命令、又はグラフィックス処理ユニット（graphics processing unit、ＧＰＵ）若しくは汎用グラフィックス処理ユニット（general-purpose graphics processing unit、ＧＰＧＰＵ）における同等物などのプロセッサ固有命令を使用して実施することができる。いくつかのアーキテクチャでは、１２８、２５６、５１２、又はそれ以上のビットなど、６４ビットよりも大きいワードを使用することによって、算出をより高速に実施することができる。
【0067】
「有名」イベント：ラウンドＲイベントＸは、（１）イベントＸが「ラウンドＲの第１の」イベント（又は「ウィットネス」）であり、かつ（２）後述されるビザンチン合意プロトコルの実行を介して「はい」の判断に達した場合、「有名」である。いくつかの実施形態では、ビザンチン合意プロトコルは、分散データベースのインスタンス（例えば、分散データベースインスタンス１１４）及び／又はデータベース収束モジュール（例えば、データベース収束モジュール２１１）によって実行することができる。例えば、図８では、ラウンド１の５つの第１のイベント１４０１、１４０２、１４０３、１４０４、及び１４０８が示されている。Ｍが、Ｎの１／２倍よりも大きい最小整数であると定義され、これが３である場合、１４１２はラウンド２の第１のイベントである。プロトコルがより長く実行される場合、ハッシュグラフは上方に成長し、最終的に、他の４つのメンバもまた、この図の上部の上方にラウンド２の第１のイベントを有することになる。ラウンド２の各第１のイベントは、ラウンド１の第１のイベントの各々が「有名」であるかどうかについての「投票」を有する。イベント１４１２は、１４０１、１４０２、及び１４０３が有名であることに対して、はいを投票するであろうが、これは、これらが、識別することができるラウンド１の第１のイベントだからである。イベント１４１２は、１４０４が有名であることに対していいえを投票するであろうが、これは、１４１２が１４０４を識別できないからである。１４０２などの、ラウンド１の所与の第１のイベントについて、そのイベントの「有名」であるか否かの状態は、それが有名であるか否かに対するラウンド２の各第１のイベントの投票を算出することによって決定される。次いで、これらの投票は、ラウンド３の第１のイベントに、次いで、ラウンド４の第１のイベントに、などのように伝搬し、最終的に、１４０２が有名であったかどうかについて合意に達するまで伝播する。同じプロセスが、他の第１のものに対して繰り返される。
【0068】
ビザンチン合意プロトコルは、「ラウンドＲの第１の」イベントの投票及び／又は判断を収集及び使用して、「有名なイベントを識別することができる。例えば、「ラウンドＲ＋１の第１の」イベントＹは、ＹがイベントＸを「識別」することができる場合に「はい」を投票し、そうでない場合に「いいえ」を投票する。投票は、任意のメンバによって判断に達するまで、ラウンドＧごとに、Ｇ＝Ｒ＋２、Ｒ＋３、Ｒ＋４などについて算出される。判断に達するまで、ラウンドＧごとに投票が算出される。これらのラウンドのうちのいくつかは「多数決」ラウンドであってよく、他のいくつかのラウンドは「コイン」ラウンドであり得る。いくつかの場合、例えば、ラウンドＲ＋２は、多数決ラウンドであり、将来のラウンドは、多数決ラウンド又はコインラウンドのいずれかとして（例えば、事前定義されたスケジュールに従って）指定される。例えば、いくつかの場合、将来のラウンドが多数決ラウンドであるか又はコインラウンドであるかは、連続する２つのコインラウンドはあり得ないという条件が与えられて、任意に判断することができる。例えば、５つの多数決ラウンド、次に１つのコインラウンド、次に５つの多数決ラウンド、次に１つのコインラウンドがあり、合意に達する限り繰り返される、ということが事前定義され得る。
【0069】
いくつかの場合、ラウンドＧが多数決ラウンドである場合、投票は、以下のように算出することができる。Ｖ（Ｖは「はい」又は「いいえ」のいずれかである）に投票する少なくともＭ個のラウンドＧ－１の第１を強く識別するラウンドＧイベントが存在する場合、コンセンサス判断は、Ｖであり、ビザンチン合意プロトコルは、終了する。そうでない場合、ラウンドＧの各第１のイベントは、ラウンドＧの各第１のイベントが強く識別することができるラウンドＧ－１の第１のイベントの多数決である、新しい投票を算出する。多数決ではなく同順位がある場合、投票は、「はい」と指定することができる。
【0070】
同様に述べると、ＸがラウンドＲのウィットネス（又はラウンドＲの第１）である場合、ラウンドＲ＋１、Ｒ＋２などにおける投票の結果を算出することができ、ここで、各ラウンドにおけるウィットネスは、Ｘが有名であるかどうかについて投票している。ラウンドＲ＋１では、Ｘを見ることができる全てのウィットネスは、はいを投票し、他のウィットネスは、いいえを投票する。ラウンドＲ＋２では、全てのウィットネスが、強く見ることができるラウンドＲ＋１のウィットネスの投票の多数決に従って投票する。同様に、ラウンドＲ＋３では、全てのウィットネスが、強く見ることができるラウンドＲ＋２のウィットネスの投票の多数決に従って投票する。これは、複数のラウンドにわたって継続することができる。同順位の場合、投票は、はいに設定することができる。他の場合、同順位は、いいえに設定することができるか、又はランダムに設定することができる。任意のラウンドが、いいえに投票する少なくともＭ個のウィットネスを有する場合、選挙は終了し、Ｘは有名ではない。任意のラウンドが、はいに投票する少なくともＭ個のウィットネスを有する場合、選挙は終了し、Ｘは有名である。はいもいいえも少なくともＭ個の投票を有しない場合、選挙は次のラウンドに続く。
【0071】
例として、図８において、示された図の下にあるラウンドの、ある第１のイベントＸを考える。この場合、ラウンド１の各第１のイベントは、Ｘが有名であるかどうかに関する投票を有する。イベント１４１２は、ラウンド１の第１のイベント１４０１、１４０２、及び１４０８を強く識別することができる。したがって、イベント１４１２の投票は、それらのイベントの投票に基づく。これが多数決ラウンドである場合、１４１２は、｛１４０１、１４０２、１４０８｝のうちの少なくともＭ個がはいの投票を有するかどうかをチェックする。そうである場合、判断は、はいであり、合意に達している。少なくともそれらのうちＭ個がいいえに投票した場合、判断は、いいえであり、合意に達している。投票が、いずれの方向においても少なくともＭ個を有しない場合、１４１２は、１４０１、１４０２、及び１４０８の投票の多数決である投票を与えられる（同順位があった場合、はいを投票することによって均衡を破る）。その投票は次いで、次のラウンドで使用され、合意に達するまで続けられ得る。
【0072】
いくつかの場合、ラウンドＧがコインラウンドである場合、投票は以下のように算出することができる。イベントＸが、Ｖ（Ｖは「はい」又は「いいえ」のいずれかである）に投票するラウンドＧ－１の少なくともＭ個の第１を強く識別することができる場合、イベントＸはその投票をＶに変更することになる。そうでない場合は、ラウンドＧがコインラウンドである場合、ラウンドＧの各第１のイベントＸは、その投票を、イベントＸの署名の最下位ビットであると定義される擬似ランダム決定（いくつかの場合、コインフリップに類似する）の結果に変更する。
【0073】
同様に述べると、そのような場合において、選挙がラウンドＲ＋Ｋ（コインラウンド）に達し、ここで、Ｋが指定された係数（例えば、３、６、７、８、１６、３２又は任意の他の好適な数などの数の倍数）である場合、選挙はそのラウンドで終了しない。選挙がこのラウンドに達した場合、少なくとももう１ラウンド継続することができる。そのようなラウンドでは、イベントＹがラウンドＲ＋Ｋウィットネスである場合において、Ｖを投票しているラウンドＲ＋Ｋ－１からの少なくともＭ個のウィットネスを強く見ることができる場合、ＹはＶに投票する。そうでない場合、Ｙは、ランダム値に従って（例えば、イベントＹの署名の１ビット（例えば、最下位ビット、最上位ビット、ランダムに選択されたビット）であって、暗号「共有コイン」プロトコル及び／又は任意の他のランダム決定を使用して、イベントＹのタイムスタンプに従って、１＝はいであり、かつ０＝いいえであるか、又はその逆である、１ビットに従って）、投票する。このランダム決定は、Ｙが作成される前は予測不可能であり、したがって、イベント及びコンセンサスプロトコルのセキュリティを増加させることができる。
【0074】
例えば、図８では、ラウンド２がコインラウンドであり、投票がラウンド１の前の何らかのイベントが有名であったかどうかについてのものである場合、イベント１４１２は、まず、｛１４０１、１４０２、１４０８｝のうちの少なくともＭ個がはいに投票したかどうか、又はそれらのうちの少なくともＭ個がいいえに投票したかどうかをチェックする。当てはまる場合、１４１２は、同じように投票する。いずれかの方向に投票する少なくともＭ個がない場合、１４１２は、（例えば、Ｅｄがイベント１４１２に署名したとき、イベント１４１２を生成及び／又は定義したときに生成した、イベント１４１２に対するデジタル署名の最下位ビットに基づいて）ランダム又は擬似ランダムな投票を有することになる。
【0075】
いくつかの場合、擬似ランダム決定の結果は、暗号共有コインプロトコルの結果であってよく、暗号共有コインプロトコルは、例えば、ラウンド番号の閾値署名の最下位ビットとして実装され得る。
【0076】
上で説明されるように、いくつかの実装形態では、ハッシュグラフコンセンサス方式は、例えば、ラウンドＲにおけるウィットネスＸの有名さを決定することを含むことができる。上で説明されるように、ラウンドＲ＋１から初期投票を集め、各イベントがＸの子孫であるかどうかに従ってはい又はいいえを投票する各イベントをカウントすることができる。代替アプローチとして、「Ｒ＋１」の代わりに「Ｒ＋２」（又は「Ｒ＋１」の代わりに「Ｒ＋３」、「Ｒ＋４」など）から初期投票を集めることが挙げられ得る。そのアプローチでは、任意選択的に追加のステップを追加することができる。詳細には、そのような実装形態では、ラウンドＲの第１のイベントＸ（又はラウンドＲのウィットネスＸ）が、母集団の３分の２より多く（すなわち、２Ｎ／３より多くのメンバ）によって作成及び／又は定義されたラウンドＲ＋１のウィットネスの先祖であるときはいつでも、Ｘは直ちに有名であると宣言され、Ｘに対するいかなる投票が算出される前であっても、選挙は直ちに終了する。第２の代替アプローチとして、Ｒ＋１から集められた初期投票を用いてＲに対する選挙を実行することが挙げられ得、その場合、有名であると決定されたラウンドＲにおいてウィットネスを作成及び／又は定義したメンバの数が、所与の閾値Ｔを下回る（例えば、２Ｎ／３メンバを下回る）場合、Ｒ＋２から集められた初期投票を用いて２回目の選挙を再実行する。同様に述べると、ラウンドＲ＋１からの投票を使用して識別された、ラウンドＲに対する有名なウィットネスの数が不十分である場合、ラウンドＲ＋１ではなくラウンドＲ＋２からの投票を使用して選挙を最初から完全に再実行することができる（すなわち、ラウンドＲ＋１からの投票を使用した選挙の結果は破棄され、ラウンドＲ＋２からの投票を使用して選挙を再実行する）。いくつかの実装形態では、別の代替として、Ｒ＋１から集められた初期投票を用いてＲに対する選挙を実行することが挙げられ得、その場合に、有名であると決定されたラウンドＲにおけるウィットネスを作成及び／又は定義したメンバの数が、所与の閾値Ｔを下回る（例えば、２Ｎ／３メンバを下回る）場合、ラウンドＲに対する有名なウィットネス（例えば、ジャッジ）は、ラウンドＲ＋１における有名なウィットネスの先祖であるラウンドＲにおけるウィットネスであると定義され得る（メンバごとにラウンドＲにおける１つの有名なウィットネスのみを保証するために、いくつかが除去される）。
【0077】
システムは、上で説明される擬似ランダム決定の結果を算出するための方法のいずれか１つから構築することができる。いくつかの場合、システムは、様々な方法を何らかの順序で循環させる。他の場合、システムは、異なる方法の中から事前定義されたパターンに従って選択することができる。
【0078】
「受信ラウンド」：イベントＸは、ラウンド番号Ｒを有するラウンドＲの有名な第１のイベント（又は有名なウィットネス）のうちの少なくとも半分がＸの子孫であるように、かつ／又はＸを見ることができるように、Ｒが最小整数である場合、Ｒの「受信ラウンド」を有する。他の場合、任意の他の好適な割合を使用することができる。例えば、別の場合、イベントＸは、ラウンド番号Ｒを有するラウンドＲの有名な第１のイベント（又は有名なウィットネス）のうちの少なくとも事前定義された割合（例えば、４０％、６０％、８０％など）がＸの子孫であるように、かつ／又はＸを見ることができるように、Ｒが最小整数である場合、Ｒの「受信ラウンド」を有する。
【0079】
いくつかの場合、イベントＸの「受信世代」は、以下のように算出することができる。イベントＸを識別することができる各ラウンドＲの第１のイベントをどのメンバが作成及び／又は定義したかを求める。次いで、Ｘを識別することができるそのメンバによる最古のイベントの世代番号を決定する。次いで、Ｘの「受信世代」をそのリストの中央値であるように定義する。
【0080】
いくつかの場合、イベントＸの「受信タイムスタンプ」Ｔは、Ｘを識別するかつ／又は見る各メンバによる第１のイベントを含むイベント内のタイムスタンプの中央値であり得る。例えば、イベント１４０１の受信タイムスタンプは、イベント１４０２、１４０３、１４０３、及び１４０８のタイムスタンプの値の中央値であり得る。いくつかの場合、イベント１４０１のタイムスタンプを中央値算出に含めることができる。他の場合、Ｘの受信タイムスタンプは、Ｘを識別する又は見るための各メンバによる第１のイベントであるイベント内のタイムスタンプの値の、任意の他の値又は組み合わせであり得る。例えば、Ｘの受信タイムスタンプは、タイムスタンプの平均、タイムスタンプの標準偏差、（例えば、算出から最古のタイムスタンプ及び最新のタイムスタンプを除去することにより）修正された平均、及び／又は同様のものに基づき得る。更に他の場合、拡張中央値を使用することができる。
【0081】
いくつかの場合、イベントの全順序及び／又はコンセンサス順序は、イベントをそれらの受信ラウンドによってソートすること、それらの受信タイムスタンプによって均衡を破ること、及びそれらの署名によってそれらの均衡を破ることによって算出される。他の場合、イベントの全順序は、イベントをそれらの受信ラウンドによってソートすること、それらの受信世代によって均衡を破ること、及びそれらの署名によってそれらの均衡を破ることによって算出することができる。前述の段落では、イベントの受信ラウンド、受信タイムスタンプ、及び／又は受信世代を算出及び／又は定義するために使用される関数を指定する。
【0082】
他の場合、各イベントの署名を使用する代わりに、そのイベントの署名を、そのラウンドにおける同じ受信ラウンド及び／又は同じ受信世代を有する、有名なイベント又は有名なウィットネスの署名とＸＯＲして使用することができる。他の場合、イベント署名の任意の他の好適な組み合わせを使用して、イベントのコンセンサス順序を定義するために均衡を破ることができる。所与のラウンドにおける有名なウィットネスのＸＯＲされた署名の結果は、潜在的な攻撃者及び他のエンティティが予測及び／又は操作することが困難な擬似乱数を表す。したがって、いくつかの実装形態では、ＸＯＲされた署名は、予測不可能な乱数のソース（すなわち、「ランダムビーコン」）として使用することができる。乱数は、様々なハッシュグラフプロセスにおいて使用することができる。
【0083】
更に他の場合、「受信世代」をリストの中央値として定義する代わりに、「受信世代」をリスト自体であるように定義することができる。次に、受信世代によってソートする場合、２つの受信世代は、それらのリストの中間要素によって比較することができ、中間の直前の要素によって均衡を破り、中間の直後の要素によってそれらの均衡を破り、均衡が破れるまで、これまで使用した要素の前の要素と後の要素とを交互に入れ替えることによって続けられる。
【0084】
いくつかの場合、タイムスタンプ中央値は、「拡張中央値」と置換することができる。そのような場合、タイムスタンプのリストは、単一の受信タイムスタンプではなく、各イベントに対して定義され得る。イベントＸのタイムスタンプのリストには、Ｘを識別及び／又は見る各メンバによる第１のイベントを含めることができる。例えば、図８では、イベント１４０１のタイムスタンプのリストは、イベント１４０２、１４０３、１４０３、及び１４０８のタイムスタンプを含むことができる。いくつかの場合、イベント１４０１のタイムスタンプもまた含めることができる。タイムスタンプのリストとの均衡を破る（すなわち、２つのイベントが同じ受信ラウンドを有する）とき、各イベントのリストの中間タイムスタンプ（又は偶数の長さの場合、２つの中間タイムスタンプのうちの第１又は第２の所定のタイムスタンプ）が比較され得る。これらのタイムスタンプが同じである場合、中間タイムスタンプの直後のタイムスタンプを比較することができる。これらのタイムスタンプが同じである場合、中間タイムスタンプの直前のタイムスタンプを比較することができる。これらのタイムスタンプも同じである場合、すでに比較された３つのタイムスタンプの後のタイムスタンプが比較される。これは、均衡が破れるまで交互に続けることができる。上の考察と同様、２つのリストが同一である場合、２つの要素の署名によって均衡を破ることができる。
【0085】
更に他の場合、「短縮拡張中央値」を「拡張中央値」の代わりに使用することができる。そのような場合、各イベントに対してタイムスタンプのリスト全体が記憶されるわけではない。代わりに、リストの中央付近の数個の値のみが記憶され、比較のために使用される。
【0086】
受信タイムスタンプ中央値は、潜在的に、イベントの全順序を算出することに加えて、他の目的のために使用され得る。例えば、Ｂｏｂは、Ｂｏｂが契約に拘束されることに同意することを示す契約に署名する可能性があるが、これは、Ａｌｉｃｅがこの同じ契約に署名するトランザクションを含むイベントＸがあり、Ｘの受信タイムスタンプが特定の期限にあるか又はその前である場合にのみ行われる。その場合、上で説明されるように「受信タイムスタンプ中央値」によって示されるように、Ａｌｉｃｅが期限後に契約に署名した場合、Ｂｏｂは契約によって拘束されないであろう。
【0087】
いくつかの実装形態では、Ａｌｉｃｅが、フォークである（同じ自身の親を有する）２つのイベントＸ及びＹを作成し、ＢｏｂがＸを受信した場合、Ｂｏｂによって定義された後続のイベントは、Ｘを見ることができる。後に、ＢｏｂがＹを受信すると、その後のＢｏｂの将来のイベントは、（Ｂｏｂがフォークを識別するのでもはやＸ又はＹを見ることができない。いくつかの実装形態では、これは、Ｂｏｂの将来のイベントがＸを見続け、Ｙを見ないように変更することができる。同様に述べると、メンバがイベントを見ることができると、その見ることは「スティッキー」であり、メンバの将来のイベントは、そのイベントを見続けるが、そのイベントのフォークを見ない。これを使用して、コンセンサス方式及び／又はアルゴリズムは、もはやフォークを検出又はフォークに反応する必要はなくなる。定義は、述語（ｘはｙを見ることができるか？（can x see y?））から関数（ｘはどのウィットネスを見ることができるか？（which witness can x see?））に変化する。
【0088】
いくつかの実装形態では、定義ｓｅｅ、ｓｔｒｏｎｇｌｙＳｅｅ、及びｆｏｒｋ関数を削除することができ、コンセンサス方式及び／又はアルゴリズムは、ｌａｓｔＳｅｅ、ｆｉｒｓｔＳｅｅ、ｓｔｒｏｎｇｌｙＳｅｅＰ、ｓｔｒｏｎｇｌｙＳｅｅＳ１、ｓｅｅＴｈｒｕＰ、ｆｉｒｓｔＳｅｌｆＷｉｔｎｅｓｓＳ、及びｆｉｒｓｔＷｉｔｎｅｓｓＳの項を使用することができる（例えば、図１３Ａ～図１３Ｅに示される関数を参照のこと）。これらの関数の各々は、イベントｘ及びメンバｍを与えられ、メンバｍによって作成された一意のイベントを返し、イベントｘによって（何らかの方法で）見られる。Ｓ、Ｓ１、又はＰで終わる名前のうちのいくつかは、返されたイベントが、（それぞれ）ｘの自身のラウンド（ｘの作成されたラウンド）、自身のラウンドから１を引いたもの、又は親ラウンドであることを示す。各関数について、そのような可視イベントがない場合、又は
【0089】
【数2】
【0090】
【数3】
【0091】
図１３Ａ～図１３Ｅで使用される関数ビルダ表記では、満たされる「ｉｆ」を複数の行が有する場合、最初の（上部の）行が使用される。また、論理ＯＲ（Ｖ）は短絡であると仮定されるため、ｐが真であり、ｑが未定義である場合（ｑの定義に無限再帰がある得る場合など）に、ｐＶｑは真として定義される。
【0092】
図１３Ａ～図１３Ｅの例示的な定義は、効率的な様式で直接実装することができる。図１３Ａ及び図１３Ｂの式には存在記号又は全称記号がほとんどないため、これらの算出は簡単である。効率的な実装形態は、関数ｌａｓｔＳｅｅ、ｓｔｒｏｎｇｌｙＳｅｅＰ、ｒｏｕｎｄ、ｆｉｒｓｔＳｅｌｆＷｉｔｎｅｓｓＳ、及びｆｉｒｓｔＷｉｔｎｅｓｓＳをメモ化することを含む。図１３Ｂの他の関数、ｐａｒｅｎｔＲｏｕｎｄ、ｓｅｅＴｈｒｕ、ｓｔｒｏｎｇｌｙＳｅｅＳ１、及びｆｉｒｓｔＳｅｅは、メモ化されない場合がある。各々は、イベント及びメンバの関数である。したがって、関数は、各メンバの配列の１つの要素を有する、各イベントに対する配列を記憶することによってメモ化され得る。図１３Ａ～図１３Ｅの例示的な定義は、互いに再帰的に依存し、所与のイベントｘに対して任意の所与の関数が呼び出されたときに、その関数がｘに適用されるその関数の下にリストされた関数に依存せず、ｘの先祖にのみ依存するような順序でリストされている。
【0093】
いくつかの場合、分散データベースの状態は、コンセンサスが達成された後に定義され得る。例えば、Ｓ（Ｒ）がラウンドＲにおいて有名なウィットネスによって見ることができるイベントのセットである場合、最終的に、Ｓ（Ｒ）におけるイベントの全ては、既知の受信ラウンド及び受信タイムスタンプを有することになる。その時点で、Ｓ（Ｒ）におけるイベントのコンセンサス順序は既知であり、変化しない。この時点に達すると、メンバは、イベントの表現及びそれらの順序を算出及び／又は定義することができる。例えば、メンバは、Ｓ（Ｒ）におけるイベントのハッシュ値を、それらのイベントのコンセンサス順序に算出することができる。次に、メンバは、（そのメンバの秘密鍵を使用して）ハッシュ値にデジタル署名し、そのメンバが定義する次のイベントにハッシュ値を含めることができる。これは、変化しない所与の順序をＳ（Ｒ）内のイベントが有することをそのメンバが決定したことを、他のメンバに知らせるために使用することができる。少なくともＭ個のメンバ（又は任意の他の好適な数又は割合のメンバ）が、Ｓ（Ｒ）に対するハッシュ値に署名した（したがって、ハッシュ値によって表される順序に同意した）後、イベントのそのコンセンサスリストは、メンバの署名のリストとともに、コンセンサス順序がＳ（Ｒ）内のイベントに対して主張されたとおりであったことを証明するために使用され得る、単一ファイル（又は他のデータ構造）を形成することができる。いくつかの場合、イベントが（本明細書に説明される）分散データベースシステムの状態を更新するトランザクションを含む場合、ハッシュ値は、コンセンサス順序でＳ（Ｒ）内のイベントのトランザクションを適用した後の分散データベースシステムの状態のものであり得る。
【0094】
いくつかの場合、（上で説明されるような）Ｍは、総メンバの数の単なる分数、割合及び／又は値ではなく、各メンバに割り当てられた重み値に基づくことができる。そのような場合、各メンバは、分散データベースシステムにおけるその関心及び／又は影響に関連付けられたステークを有する。そのようなステークは、重み値であり得る。そのメンバによって定義される各イベントは、その定義メンバの重み値を有すると言うことができる。この場合、Ｍは、全てのメンバの総ステークの分数とすることができる。Ｍに依存するものとして上で説明されるイベントは、少なくともＭのステーク合計を有するメンバのセットが同意したときに発生する。したがって、それらのステークに基づいて、特定のメンバは、システム及びコンセンサス順序がどのように導出されるかに対してより大きな影響を有することができる。いくつかの場合、イベントにおけるトランザクションは、１つ以上のメンバのステークを変更し、新しいメンバを追加し、かつ／又はメンバを削除することができる。そのようなトランザクションがＲの受信ラウンドを有する場合は、受信ラウンドが算出された後、ラウンドＲのウィットネスの後のイベントは、メンバの修正されたステーク及び修正されたリストを使用して、それらのラウンド番号及び他の情報を再算出する。ラウンドＲのイベントが有名であるかどうかについての投票は、古いステーク及びメンバリストを使用するが、Ｒの後のラウンドについての投票は、新しいステーク及びメンバリストを使用する。コンセンサスを決定するために重み値を使用することに関する更なる詳細は、米国特許出願第１５／３８７，０４８号として２０１６年１２月２１日に出願され、「Ｍｅｔｈｏｄｓ Ａｎｄ Ａｐｐａｒａｔｕｓ Ｆｏｒ Ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ Ｗｉｔｈｉｎ Ａ Ｎｅｔｗｏｒｋ」と題された、米国特許第９，６４６，０２９号に説明されており、その全体が参照により本明細書に組み込まれる。
【0095】
いくつかの場合、特定のメンバを「レイジーメンバ」として識別及び／又は指定することができる。そのような場合、レイジーメンバは、通常メンバ又は非レイジーメンバと同様のイベントを定義及び／又は作成することができる。加えて、レイジーメンバによって定義及び／又は作成されたイベントをハッシュグラフに含めることができ、そのようなイベントのコンセンサス順序を算出及び／又は識別することができる。ただし、レイジーメンバによって定義されるイベントのラウンド増分は、０である。したがって、レイジーメンバによって定義されるイベントのラウンド番号（又は作成されたラウンド）は、イベントの親のラウンド番号の最大値に等しい。同様に述べると、レイジーメンバによって定義されるイベントのラウンド増分は０であるので、レイジーメンバによって定義されるイベントのラウンド番号（又は作成されたラウンド）は、イベントの親のラウンド番号の最大値より大きくすることはできない。
【0096】
更に、いくつかの場合、レイジーメンバによって定義されるイベントは、選挙に投票する資格がなく、レイジーメンバによって定義されるイベントは、ラウンドＲの第１のイベント又はウィットネスになる資格がなく、かつ／又は別のイベントを強く見るために通常のメンバ若しくはレイジーメンバによって定義されるイベントの中間イベントとしてみなされない。したがって、レイジーメンバに課された制限は、ハッシュグラフによって実行される計算の低減をもたらす一方で、セキュリティ及びコンセンサス順序の完全性を依然として維持する。メンバは、任意の好適な基準に基づいて、レイジーメンバとして選択され得る。例えば、いくつかの場合、メンバは、各ラウンドで実行される決定論的擬似ランダム選択に基づいて、ラウンドの開始時に事前定義されて、信頼レベルに基づいて、ステークの量に基づいて、他のメンバの投票に基づいて、かつ／又はランダムに選択されて、レイジーメンバとして指定され得る。いくつかの場合、レイジーメンバとして指定されたメンバは、ラウンドごとに異なる可能性があり、いくつかの他の場合、レイジーメンバとして指定されたメンバは、異なるラウンドにわたって同じままである。いくつかの他の場合、メンバではなくイベントを「レイジー」イベントとして指定することができる。そのような場合、各ラウンドにおいて、メンバを選択する代わりにレイジーイベントが選択され得る。
【0097】
したがって、いくつかの場合、第１のメンバのプロセッサは、決定論的擬似ランダム関数に基づいて、メンバの第１のグループ（例えば、計算デバイス）と、メンバの第２のグループ（例えば、計算デバイス）とを定義することができる。メンバの第１のグループは、非レイジーメンバであり得、メンバの第２のグループは、レイジーメンバであり得る。いくつかの場合、メンバの第１のグループは、分散データベースのメンバ（例えば、計算デバイス）に関するメンバの第２のグループの絶対補集合である。第１のメンバ（又は第１のメンバのプロセッサ）は、第２のメンバ（例えば、計算デバイス）から、メンバのセット（例えば、計算デバイスのセット）によって定義されるイベントの第１のセットにリンクされたイベントを受信することができる。メンバのセットは、メンバの第１のグループからの少なくとも１つのメンバと、メンバの第２のグループからの少なくとも１つのメンバとを含む。プロセッサは、メンバの第１のグループからのメンバによって定義されたイベントの第１のセットからのイベントのパラメータ（例えば、ラウンド番号、ラウンド増分、投票、ウィットネスであることの指標、有名なウィットネスであることの指標など）の値を使用した、かつメンバの第２のグループからのメンバによって定義されたイベントの第１のセットからのイベントのパラメータの値を使用しない、（例えば、本明細書に説明される）コンセンサスプロトコルの結果として、イベントの第２のセットに関連付けられた順序を識別することができる。プロセッサは、イベントの第２のセットに関連付けられた順序に少なくとも部分的に基づいて、分散データベースのインスタンスにおいて示されるトランザクションのセットに関連付けられた順序を識別することができ、トランザクションのセットに関連付けられた順序を、分散データベースのインスタンスに記憶することができる。
【0098】
前述の用語、定義、及びアルゴリズムは、図８～図１３Ｅに説明される実施形態及び概念を例解するために使用される。図１０Ａ及び図１０Ｂは、数学的形式で示されるコンセンサス方式及び／又はプロセスの第１の例示的な適用を例解する。図１１Ａ及び図１１Ｂは、数学的形式で示されるコンセンサス方式及び／又はプロセスの第２の例示的な適用を例解し、図１２Ａ及び図１２Ｂは、数学的形式で示されるコンセンサス方式及び／又はプロセスの第３の例示的な適用を例解し、図１３Ａ～図１３Ｅは、数学的形式で示されるコンセンサス方式及び／又はプロセスの第４の例示的な適用を例解する。
【0099】
図２では、データベース収束モジュール２１１及び通信モジュール２１２は、プロセッサ２１０内に実装されるものとして図２に示されている。いくつかの実施形態では、データベース収束モジュール２１１及び／又は通信モジュール２１２は、メモリ２２０内に実装することができる。いくつかの実施形態では、データベース収束モジュール２１１及び／又は通信モジュール２１２は、ハードウェアベース（例えば、ＡＳＩＣ、ＦＰＧＡなど）であり得る。
【0100】
（例えば、図１に関して本明細書に説明されるように）トランザクションは、分散データベース内のデータ及び／又は状態を変更することができるのと同じように、トランザクションは、分散データベースのメンバを追加、除去、及び／又は修正することによって、分散データベース（例えば、分散データベースを実装する計算デバイスのセット）のメンバシップを修正することもできる。いくつかの実装形態では、分散データベースのメンバは、分散データベースを実装する計算デバイスのセット（例えば、図１の計算デバイス１１０、１２０、１３０、１４０）に１つ以上の計算デバイスを追加及び／又はそれから１つ以上の計算デバイスを除去することによって、経時的に変化し得る。同様に述べると、分散データベースを実装する計算デバイスのセット１１０、１２０、１３０、１４０は、計算デバイスのセット１１０、１２０、１３０、１４０からの計算デバイスが計算デバイスのセット１１０、１２０、１３０、１４０から除去される、かつ／又は計算デバイスのセット１１０、１２０、１３０、１４０に追加されると、経時的に変化し得る。いくつかの場合、除去された計算デバイスは、後で分散データベースシステムに再接続することができる。
【0101】
アドレスブックは、任意の所与の時間に分散データベースのメンバ（すなわち、分散データベースを実装する計算デバイス）を追跡するために使用され得る。図１４は、一実施形態による、分散データベースシステムに関連付けられたアドレスブック１４００を例解する。アドレスブック１４００は、図１の分散データベースシステム１００内の計算デバイス１１０、１２０、１３０、１４０の各々に対するエントリを含む。具体的には、アドレスブック１４００は、分散データベースを実装する計算デバイスのセット（図１に関して図示及び説明した計算デバイス１１０、１２０、１３０、１４０）の、公開鍵のセット（Ａ、Ｂ、Ｃ及びＤ）を含むように定義されている。コンセンサスを決定するためにステークが使用される（例えば、デバイスのステークが、デバイスがコンセンサスプロセスに対して有する影響の量を示す）実装形態では、アドレスブック１４００は、各計算デバイスに関連付けられたステークの量も含むことができる。
【0102】
トランザクションが、分散データベースを実装する計算デバイスのセットから計算デバイスを追加、削除、及び／又は修正するとき、トランザクションは、アドレスブックを変更及び／又は更新することができる。例えば、分散データベースから計算デバイス１４０を除去するためのトランザクションが分散データベースに入力され、（例えば、分散データベースのコンセンサス順序内で）順序付けられた場合、トランザクションを実行することができ、計算デバイス１４０を分散データベースから除去することができる。このトランザクションに応答して、計算デバイス１４０のエントリを含まない新しいアドレスブックを定義することができる。別の例では、新しい計算デバイスを分散データベースに追加するトランザクションが分散データベースに入力され、（例えば、分散データベースのコンセンサス順序内で）順序付けられた場合、（例えば、公開鍵及び／又はステークの量を含む）エントリを有する新しいアドレスブックを、新しい計算デバイスのために定義することができる。更に別の例では、１つ以上の計算デバイスに関連付けられたステークの量を変更するトランザクションが分散データベースに入力され、順序付けられた場合、ステークの変更を反映する新しいアドレスブックを定義することができる。例えば、ステークが各計算デバイスによって保持される暗号通貨コインの量を反映する場合、トランザクションは、計算デバイス１４０が計算デバイス１３０に５つのコインを送金することを反映することができる。トランザクションが順序付けられ実行された後、計算デバイス１４０が現在７０個のコインを有し、計算デバイス１３０が３５個のコインを有することを反映して、新しいアドレスブックを定義することができる。
【0103】
いくつかの実装形態では、コンセンサスプロトコルの各ラウンドは、新しいアドレスブックを有することができる（例えば、分散データベースを実装する各計算デバイスは、コンセンサスプロトコルの各ラウンドに対してそのアドレスブックを更新することができる）。具体的には、アドレスブック内の情報が（例えば、分散データベースを実装する計算デバイスを追加、除去、及び／又は修正するトランザクションを介して）変更されると、各計算デバイスは、そのアドレスブックを更新して、アドレスブックへの変更を行うトランザクションを反映することができる。そのような変更は、そのような変更を含むイベントがコンセンサスプロトコルを介して受信ラウンドに割り当てられた後に、ラウンドのアドレスブックに反映され得る。具体的には、ラウンドｒのアドレスブックＡｒは、ｒ未満の受信ラウンドを有するイベントにおけるトランザクション（すなわち、ｒ－１以下の受信ラウンドを有するイベントにおけるトランザクション）を反映することができる。同様に、ｒの受信ラウンドを有するイベントが識別されると、ｒ＋１未満の受信ラウンドを有するトランザクションを実装して、ラウンドｒ＋１の新しいアドレスブックＡｒ＋１を定義することができる。したがって、そのような実装形態では、アドレスブックは、ラウンドごとに更新され得る。これにより、トランザクションがアドレスブックに迅速に影響を及ぼすことを保証することができる。
【0104】
いくつかの実装形態では、ラウンドｒのアドレスブックＡｒは、ラウンドごとに更新されないが、代わりに、ｒの受信ラウンドを有するイベントが識別された所定の数ｐのラウンド後に更新される（例えば、分散データベースを実装する各計算デバイスは、それに応じてそのアドレスブックを更新することができる）。例えば、そのような実装形態では、ラウンドｒのアドレスブックＡｒは、Ａｒ－ｐのコピーであると定義され、次いで、ｒ－ｐ以下の受信ラウンドを有するイベント内の有効なトランザクションによって修正される。したがって、ｐ＝２の場合、ラウンドｒのアドレスブックＡｒは、ｒ－２以下の受信ラウンドを有するイベント内のアドレスブックに影響を与えるトランザクションからの更新（例えば、分散データベースを実装する計算デバイスを追加、削除、及び／又は修正する）を含む。いくつかの実装形態では、ｐに対する任意の他の好適な値が使用され得る（例えば、３、４、５など）。これは、新しいアドレスブックがコンセンサスプロトコル内で使用される前にコンセンサストランザクションを処理するためのｐ－１ラウンドの持続時間を、（例えばバックグラウンドスレッドを使用して）計算デバイスに提供する。この追加の時間は、コンセンサスプロトコルにおける休止及び／又は遅延を回避することに役立つことができる。
【0105】
いくつかの実装形態では、ラウンドｒのアドレスブックＡｒは、代わりに、アドレスブックへの以前の更新から所定の数ｐのラウンド後に更新される（例えば、分散データベースを実装する各計算デバイスは、それに応じてそのアドレスブックを更新することができる）。例えば、そのような実装形態では、ラウンドｒのアドレスブックＡｒは、ｐの倍数でない任意のラウンドのＡｒ－１のコピーであると定義することができる。そうでない場合、アドレスブックＡｒは、ｒ－１以下の受信ラウンドを有するイベントにおけるトランザクションを反映する。同様に述べると、アドレスブックは、ｐラウンドごとに更新することができる。一例として、ｐ＝１０である場合、Ａｒは、１０の倍数でない任意のラウンドｒに対するＡｒ－１の未修正のコピーとして定義することができる。そうではなく、ｒが１０の倍数である場合、Ａｒは、ｒ－１０からｒ－１の受信ラウンドを有するイベント内の有効なトランザクションによって修正されるＡｒ－１０のコピーである。いくつかの実装形態では、倍数ｐは、任意の好適な数（例えば、２、５、１０、２０など）であり得る。これにより、（本明細書で更に詳細に説明されるように）新しいアドレスブックが定義されるときに、イベントのラウンド番号（又は作成されたラウンド）の再算出をより少なくすることができる。具体的には、アドレスブックを更新する前に、アドレスブックへの変更の複数のラウンドをバッチ処理することにより、同じアドレスブックを使用して複数のラウンドのラウンド番号を算出及び再算出することを保証する。複数のラウンドに対して同じアドレスブックを使用することにより、アドレスブックが変化した後にイベントのラウンド番号（又は作成されたラウンド）を再算出する必要性を低減する。
【0106】
いくつかの実装形態では、コンセンサスプロトコルは、アドレスブックへの以前の更新後に所定の数ｐのラウンドを待つこと、及びアドレスブックを更新する前にコンセンサスが達成された後に所定の数ｋのラウンドを待つこと、の両方を行うことができる。例えば、そのような実装形態では、ラウンドｒのアドレスブックＡｒは、ｐの倍数でない任意のラウンドのＡｒ－１のコピーであると定義することができる。そうではなく、ラウンドがｐの倍数である場合、アドレスブックＡｒは、ｒ－ｋ以下の受信ラウンドを有するイベントにおけるトランザクションを反映することができる。一例として、ｐ＝１０かつｋ＝２である場合、Ａｒは、１０の倍数ではない任意のｒに対するＡｒ－１の未修正のコピーとして定義することができる。そうではなく、ｒが１０の倍数である場合、Ａｒは、ｒ－１１からｒ－２の受信ラウンドを有するイベント内の有効なトランザクションによって修正されるＡｒ－１１のコピーである。これは、新しいアドレスブックがコンセンサスプロトコル内で使用される前に、各計算デバイスがコンセンサストランザクションを処理するための追加の時間を（例えばバックグラウンドスレッドを使用して）提供するという利点とともに、アドレスブックに適用する前に複数のラウンドの変更をバッチ処理するという利点を提供することができる。
【0107】
ラウンドｒにおいて有名なウィットネスについてコンセンサスに達した後、受信ラウンドｒを有するイベントを識別することができ、新しいアドレスブックＡｒ＋１を（上で考察されたように）算出することができる。いくつかの実装形態では、各イベントは、新しいアドレスブックＡｒ＋１を使用して再算出された、作成されたラウンドを有することができる。これは、ラウンドｒ＋１において、有名なウィットネスを識別するために行われる。したがって、各アドレスブックについて、及びそのアドレスブックに関連付けられたラウンドについて、イベントは、作成された異なるラウンドを有し得る。
【0108】
いくつかの実装形態では、イベントに対して再算出され作成されるラウンドの数を低減するために、いくつかのイベントを凍結されたものとして識別することができる。凍結されたイベントは、新しいアドレスブックが定義されるときに再算出される、作成されたラウンドを有しない。具体的には、イベントがラウンドｒ又はそれより前の任意の有名なウィットネスの先祖である場合、それは凍結されているとみなすことができ、そのイベントの作成されたラウンドは、後続のラウンドにおいて再算出されないか又は後続のアドレスブックを使用して再算出されない。一方、イベントがラウンドｒ又はそれより前の任意の有名なウィットネスの先祖でない場合、そのイベントの作成されたラウンドは、（ラウンドｒ＋１のアドレスブックがラウンドｒのアドレスブックから変更されている場合は）ラウンドｒ＋１のアドレスブックＡｒ＋１を使用してラウンドｒ＋１で再算出される。同様に、先に進めると、ラウンドｒ＋１における有名なウィットネスが識別され、受信ラウンドｒ＋１を有するイベントが識別された後、追加のイベントがラウンドｒ＋１又はそれより前の有名なウィットネスの先祖である場合、追加のイベントが凍結される可能性がある。そのような凍結されたイベントは、ラウンドｒ＋２において再算出されたそれらの作成されたラウンドを有しない。これは、コンセンサスプロトコルの将来のラウンドについて同様に継続することができる。
【0109】
いくつかの実装形態では、再算出は、親ラウンドがｒ＋２であるときに（強く見るのではなく）多数決を見る（又は識別する）ことと、親ラウンドがｒ＋１であるときに（絶対多数決ではなく）ただ１つを見ることとの、２つのラウンドについて修正され得る。これは、待ち時間と計算複雑性との間のトレードオフを制御することができ、計算コストを増加させるが、コンセンサスを達成するための待ち時間を減少させる。いくつかの実装形態では、各イベントが複数の他の親イベントを有することを可能にするように、分散データベースを実装する各計算デバイスを多くの他の計算デバイスと実質的に同時に同期させることによって、待ち時間を低減することもできる。
【0110】
図１５は、一実施形態による、アドレスブックを更新する方法１５００を例解するフローチャートである。方法１５００は、分散データベースを実装する計算デバイスのセットからの計算デバイスのプロセッサによって実行することができる。方法１５００は、１５０２において、分散データベースのためのアドレスブックを定義することを含む。いくつかの実装形態では、アドレスブックは、ネットワークを介して分散データベースを実装する計算デバイスのセットからの各計算デバイスの、識別子（例えば、公開鍵）及び／又は他の情報（例えば、ステーク値）を含む。
【0111】
１５０４において、アドレスブックを更新するためのトランザクションを含むイベントが受信される。例えば、イベントには、分散データベースを実装する計算デバイスのセットに計算デバイスを追加すること、分散データベースを実装する計算デバイスのセットから計算デバイスを除去すること、分散データベースを実装する計算デバイスのセットからの計算デバイスに関連付けられたステーク値を更新すること、及び／又は同様のことのためのトランザクションを含むことができる。
【0112】
１５０６において、アドレスブックを使用する分散データベースのコンセンサスプロトコルに基づいて、イベントの受信ラウンドが算出される。例えば、本明細書に開示されるものなどの任意の好適なコンセンサスプロトコルを使用して、イベントの受信ラウンド（又は順序に関連付けられた属性）を算出することができる。
【0113】
１５０８において、トランザクションに基づいてアドレスブックを更新して、イベントの受信ラウンド又はアドレスブックへの以前の更新のうちの少なくとも１つの、所定の数のラウンド後に、更新されたアドレスブックを定義する。上で考察されたように、いくつかの実装形態では、アドレスブックは、イベントの受信ラウンドの所定の数のラウンド後のトランザクションに基づいて、更新することができる。いくつかの実装形態では、アドレスブックは、アドレスブックへの以前の更新の所定の数のラウンドだけ更新され得る（例えば、ラウンドがｐの倍数であるときに発生するアドレスブックへの更新）。
【0114】
いくつかの実装形態では、コンセンサスプロトコルは、コンセンサスプロトコルの各ラウンドについてのイベントのセット（例えば、有名なウィットネス）を識別するように構成される。各ラウンドについてのイベントのセットは、イベントのグループから各イベントの受信ラウンドを決定するために、コンセンサスプロトコルによって使用され得る。更に、アドレスブックを使用して、イベントのグループからの各イベントについての属性（例えば、作成されたラウンド）が算出され得る。属性は、イベントのグループからの各イベントが、更新されたアドレスブックが定義されているラウンドのイベントのセットからの少なくとも１つのイベントの先祖でないときに、更新されたアドレスブックを使用して再算出され得る。同様に、属性は、イベントのグループからの各イベントが、更新されたアドレスブックが定義されているラウンドのイベントのセットからの少なくとも１つのイベントの先祖であるときに、更新されたアドレスブックを使用して、イベントのグループからのそのイベントについて再算出されない。
【0115】
いくつかの実装形態では、イベントは、分散データベース内に、かつ／又はＤＡＧの一部として無期限に保持される。いくつかの実装形態では、イベントは、古くなると破棄することができる。例えば、イベントが十分に古い場合、そのイベントはａｎｃｉｅｎｔ（古代の）として分類することができる。いくつかの実装形態では、計算デバイスは、任意選択的に、分散データベースのその計算デバイスのインスタンスからａｎｃｉｅｎｔイベントを削除することができる。イベントが更に古い場合、イベントはｅｘｐｉｒｅｄ（期限切れの）として分類することができ、計算デバイスは、分散データベースのその計算デバイスのインスタンスからそのイベントを破棄する。分散データベースが、イベントがａｎｃｉｅｎｔであるときまでに、イベントに関するコンセンサスに達していない場合（例えば、分散データベースがそのイベントの受信ラウンドを識別していない場合）、そのイベントはｓｔａｌｅ（古い）として分類することができる。そのような実装形態では、ｓｔａｌｅとして分類されたイベントには、受信ラウンド又はコンセンサスタイムスタンプが割り当てられず、コンセンサス順序の一部にならず、イベント内のトランザクションは処理されない。したがって、イベント内のトランザクションは、共有された状態又はアドレスブックに影響を及ぼさない。更に、イベントが期限切れになると、他のメンバ（分散データベースを実装する計算デバイス）との同期中にイベントがもはや送信されなくなる。しかしながら、いくつかの実装形態では、メンバは、同期中に古代のイベントを交換し続けて、遅れている可能性があるメンバ（例えば、遅れているそのようなメンバは、そのようなイベントをａｎｃｉｅｎｔとして依然として考慮しない可能性がある）に、これらのイベントを依然として考慮させることができる。
【0116】
いくつかの場合、イベントは、その全ての親がＤＡＧ又はハッシュグラフにすでに存在する場合にのみ、ＤＡＧ又はハッシュグラフに追加される。他の実装形態では、親がＤＡＧ又はハッシュグラフに存在しないが、その親がａｎｃｉｅｎｔ又はｅｘｐｉｒｅｄのいずれかである場合、イベントを依然としてＤＡＧ又はハッシュグラフに追加することができる。
【0117】
いくつかの実装形態では、期限切れ及び／又は古代のイベントの閾値は、イベントが作成されてからａｎｃｉｅｎｔ又はｅｘｐｉｒｅｄになるまでのラウンドの数によって定義され得る。一例として、閾値は、ｅｘｐｉｒｅｄＤｕｒａｔｉｏｎ＞ａｎｃｉｅｎｔＤｕｒａｔｉｏｎ＞０として定義することができる。ａｎｃｉｅｎｔＤｕｒａｔｉｏｎ及びｅｘｐｉｒｅｄＤｕｒａｔｉｏｎの値は、任意の好適な値であり得る。例えば、いくつかの実装形態では、ａｎｃｉｅｎｔＤｕｒａｔｉｏｎ＝４及びｅｘｐｉｒｅｄＤｕｒａｔｉｏｎ＝８である。他の実装形態では、ａｎｃｉｅｎｔＤｕｒａｔｉｏｎ及び／又はｅｘｐｉｒｅｄＤｕｒａｔｉｏｎに対して任意の他の値が使用され得る。
【0118】
いくつかの実装形態では、各イベントは、そのイベントの親イベントの各々について主張された世代番号（又は世代）の指標を含むことができる。そのような実装形態では、イベントの世代番号は、イベントの親の主張された世代番号の最大値に１を加えたものであり得る。親を持たないイベントは、世代番号１を有することができる。
【0119】
分散データベース（又は分散データベースを実装する計算デバイス）、ＤＡＧ、又はハッシュグラフが、特定の受信ラウンド（例えば、分散データベースが以前に受信ラウンドｒに対するコンセンサスを有していなかった受信ラウンドｒ）を有するイベントに対するコンセンサスに達すると、ラウンドｒの世代番号は、ラウンドｒにおける有名なウィットネスであるイベントの最小世代番号とすることができる。いくつかの実装形態では、イベントｘは、ａｎｃｉｅｎｔＤｕｒａｔｉｏｎより少ないコンセンサス達成するために、イベントｘが、直近のラウンドに等しいラウンドの世代番号未満である世代番号を有する場合、ａｎｃｉｅｎｔとみなすことができる。同様に述べると、イベントｘは、ｇｅｎ（ｘ）＜ｇｅｎ（ｒ－ａｎｃｉｅｎｔＤｕｒａｔｉｏｎ）であり、式中、ｇｅｎ（ｘ）は、イベントｘの世代番号であり、ｇｅｎ（ｒ－ａｎｃｉｅｎｔＤｕｒａｔｉｏｎ）は、コンセンサス－ａｎｃｉｅｎｔＤｕｒａｔｉｏｎを達成するための直近のラウンドｒから生じるラウンドの世代番号である場合、ａｎｃｉｅｎｔとみなすことができる。同様に、いくつかの実装形態では、イベントｘは、ｅｘｐｉｒｅｄＤｕｒａｔｉｏｎより少ないコンセンサス（又はｇｅｎ（ｘ）＜ｇｅｎ（ｒ－ｅｘｐｉｒｅｄＤｕｒａｔｉｏｎ））を達成するために、イベントｘが、直近のラウンドに等しいラウンドの世代番号未満である世代番号を有する場合、ｅｘｐｉｒｅｄとみなすことができる。
【0120】
いくつかの実装形態では、ラウンドｒのイベントのコアセットＳｒが定義され得る。ラウンドｒのイベントのコアセットは、ラウンドｒでコンセンサスに達した直後の、凍結された、非古代の、非期限切れのイベントとして定義され得る。同様に述べると、ラウンドｒのイベントのコアセットＳｒは、ラウンドｒにおける凍結されたウィットネスのセットであってよく、これにはラウンドｒ及び以前のラウンドにおけるそれらのウィットネスの先祖が伴い、それらの世代は、イベントが古代でも期限切れでもないように、十分に最近のものである。イベントのコアセットは、本明細書に説明される分散データベースシステムが非同期ビザンチン障害耐性（asynchronous byzantine fault tolerance、ＡＢＦＴ）特性を有し続けることを証明するのに有用であり得る。例えば、イベントがまだ破棄されておらず、アドレスブックがまだ変更されていないので、ラウンド１の基本ケースについてはコンセンサスを保証することができる。次いで、ラウンドｒについてコンセンサスが真であり、全ての正直な（honest）メンバがラウンドｒ＋１について同じイベントのコアセットＳｒ及び同じアドレスブックを有する場合、全てがラウンドｒ＋１の同じコンセンサスに達し、ｒ＋１の同じイベントのコアセットＳｒ＋１及びコンセンサスイベント、並びにｒ＋２のアドレスブックに同意する。したがって、誘導によってコンセンサスを証明することができる。
【0121】
いくつかの実装形態では、新しいメンバ（計算デバイス）が分散データベースに加入する場合、かつ／又はメンバが接続解除された後に分散データベースに再接続する場合、そのメンバは、コンセンサスが取得された最近のラウンドｒの時点で、別のメンバ（計算デバイス）から分散データベースに関連付けられた最新の情報及びイベントを受信することができる。いくつかの実装形態では、最新の情報は、分散データベースの、所定の数及び／又は割合（例えば、分散データベースにおけるメンバの１／３及び／又は総ステークの１／３）の現在のメンバ及び／又はステークによってデジタル署名された、分散データベースの状態であり得る。ラウンドｒまでのコンセンサストランザクションの結果を反映するラウンドｒの時点での署名された状態に加えて、新しい又は再接続しているメンバは、ハッシュグラフ、ＤＡＧ、及び／又は分散データベースに関する追加の情報を取得することができる。例えば、新しい又は再接続しているメンバは、別のメンバから、ｒがコンセンサスを有する最新のラウンドである時点での、ラウンドｒのコアセットＳｒ内のイベント、ラウンドｒのコアセットＳｒ内のイベントのハッシュ値、及び／又は各非古代ラウンドにおける一意の有名なウィットネスの最小世代を受信することができる。この情報が与えられると、新しい又は再接続しているメンバは、ハッシュグラフ、ＤＡＧ、及び／又は分散データベースに加入又は再加入することができる。
【0122】
いくつかの実装形態では、可能であれば、再接続しているメンバは、それらのイベント並びに／又はそれらのハッシュグラフ、ＤＡＧ及び／若しくは分散データベースのインスタンスの状態を、ハッシュグラフ、ＤＡＧ及び／又は分散データベースをリブート前又は退去する前に、メモリに書き込むことができる。次いで、再接続しているメンバは、リブート後、並びに／又はハッシュグラフ、ＤＡＧ及び／若しくは分散データベースに再接続するときに、イベント及び／又は状態を読み出すことができる。これにより、リブート後、並びに／又はメンバがハッシュグラフ、ＤＡＧ、及び／若しくは分散データベースに再接続及び／若しくは再加入しているときに、同期のための帯域幅を節約することができるが、必須ではない。
【0123】
一例として、メンバ計算デバイスＡｌｉｃｅは（計算デバイスＡｌｉｃｅにおけるプロセッサを使用して）、ラウンドｒまでのラウンド及びラウンドｒを含むラウンドについて、分散データベースの有名なウィットネスを決定及び／又は識別するために、分散データベースのＡｌｉｃｅのインスタンスにおけるＤＡＧ及び／又はハッシュグラフを使用することができる。次に、Ａｌｉｃｅは、ｒ以下の受信ラウンドを有するイベントのコンセンサス順序を算出することができる。コンセンサス順序を使用して、Ａｌｉｃｅは、イベント内のトランザクションをコンセンサス順序で処理して、分散データベースの状態を決定することができる。Ａｌｉｃｅは、分散データベースの状態のハッシュ値を算出し、状態のハッシュ値を含むトランザクションを有する新しいイベントを定義して送信することができる。Ａｌｉｃｅは、Ａｌｉｃｅの秘密鍵を使用して、このイベント及び／又はトランザクションにデジタル署名することができる。次いで、Ａｌｉｃｅは、分散データベースの状態が、分散データベースの、所定の数及び／又は割合（例えば、分散データベースにおけるメンバの少なくとも１／３及び／又は総ステークの１／３）の現在のメンバ及び／又はステークによってデジタル署名されるように、この状態に一致する分散データベースの他のメンバからデジタル署名を収集することができる。
【0124】
この例では、計算デバイスＢｏｂが（例えば、イベントにおけるトランザクションを介してアドレスブックに追加されることによって）ネットワークに加入する（又は再接続する）場合、Ａｌｉｃｅは、ラウンドｒの署名された状態（例えば、分散データベースの、所定の数及び／又は割合の現在のメンバ及び／又はステークによってデジタル署名されたラウンドｒの状態）をＢｏｂに送信することができる。次いで、Ｂｏｂは、分散データベースの他のメンバとの同期を開始することができる。具体的には、他のメンバとの同期を通してイベントを受信することができる。Ｂｏｂは、最初に、古代ではないが、その親が（ラウンドｒの終了の時点での古代の定義により）古代である、イベントを受け入れることができる。次いで、Ｂｏｂは、その親が古代であるか又はＢｏｂが受信したより古いイベントの中にある、イベントを受け入れることができる。これらのイベントを使用して、Ｂｏｂは、ＤＡＧの構築及び／又は定義を開始することができる。これは、Ｂｏｂが現在までのイベントを受信するまで継続することができ、その時点で、Ｂｏｂはキャッチアップされ、完全な参加メンバになることができる。
【0125】
参加メンバとして、Ｂｏｂは、Ｂｏｂが今後受信するイベントの受信ラウンドを算出することができる。（本明細書で考察されるように）異なるラウンドに対して異なるアドレスブックが使用されるので、Ｂｏｂは、アドレスブックＡｒ＋１を使用してイベントの各々の受信ラウンドを単純に算出することはできない。したがって、いくつかの実装形態では、署名された状態は、Ｓｒ内の各イベントに対して作成されたラウンドを伴ってＳｒ内の各イベントとともに、Ｂｏｂを含むことができ、かつ／又は（Ａｌｉｃｅから）Ｂｏｂに送信することができる。次いで、Ｂｏｂは、Ｓｒ内の各イベントに対して作成されたコンセンサスラウンドを知る。次いで、この情報を使用して、Ｂｏｂは、ラウンドｒ－１及び今後のラウンドにおけるイベントについて作成されたコンセンサスラウンドを算出することができる。ｒ－１の前に作成されたイベントを有するイベントの場合、Ｂｏｂは、作成されたラウンドを知らないが、これらのイベントは、ラウンドｒ＋１以降の有名なウィットネスの算出には使用されないので、問題にならない。
【0126】
Ｓｒ内の各イベントをＢｏｂに送信するものとして上で説明されるが、いくつかの実装形態では、両方の親イベントの作成されたラウンドよりも大きい作成されたラウンドを持つ、Ｓｒ内のイベントのみが、署名された状態とともに、加入する（又は再接続する）メンバ（Ｂｏｂなど）に送信される。これにより、他のイベントの作成されたラウンドが、ボブによって、最も高い作成されたラウンドを持つ親イベントからの作成されたラウンドをコピーすることによって再算出されるのに十分な情報が提供される。
【0127】
いくつかの実装形態では、署名された状態とともに送信されるものとして上で考察された、Ｓｒ内の各イベントのハッシュ値は、イベント自体ではなく、署名された状態とともに送信される。したがって、そのような実装形態では、状態は、ハッシュ値の３つのリスト、すなわち、親と、ラウンドｒ、ｒ－１、及びｒ－２との両方において作成された、作成されたラウンドよりも大きい作成されたラウンドを有するＳｒ内のイベントのハッシュ値を含む、かつ／又はそれとともに送信される。そのような実装形態では、再接続時又は新たな接続時に、Ｂｏｂは、ハッシュ値が署名された状態とともに記憶され、かつ／又は署名された状態とともに送信されるイベントをＢｏｂが受信するまで、他のメンバと同期することができる。具体的には、Ｂｏｂは、Ｂｏｂが受信する各イベントについてハッシュ値を算出し、かつそのハッシュ値をＢｏｂが状態とともに受信したハッシュ値と比較することによって、同期中にそのようなイベントを識別することができる。次に、Ｂｏｂは、適切な作成されたラウンドを、状態内の及び／又は状態とともに送信されたハッシュ値を有する、１つのイベントの先祖と、状態内の及び／又は状態とともに送信されたハッシュ値を有する、別のイベントの子孫との両方である任意のイベントに割り当てることができる。Ｂｏｂは、作成されたラウンドの所定の値（例えば、－∞）を、Ｂｏｂが親イベントを有していない、任意の他のイベントに割り当てることもできる。この情報に基づいて、Ｂｏｂは、ＤＡＧを定義することができ、Ｂｏｂは、アドレスブックＡｒ＋１を使用して、上で説明されるようにＢｏｂが受信する他のイベントの作成されたラウンドを算出することができる。次に、Ｂｏｂは、更なるラウンドがコンセンサスに達し、Ｂｏｂが他のメンバとの同期を介して更なるイベントを受信すると、通常の参加メンバとしてそこから継続することができる。
【0128】
図１６は、計算デバイスが分散データベースに接続及び／又は加入する方法１６００を例解するフローチャートである。方法１６００は、計算デバイスのプロセッサによって実行することができる。方法１６００は、１６０２において、ネットワークを介して、分散データベースを実装する計算デバイスのセットに、かつ分散データベースを実装するノードとして、接続することを含む。例えば、計算デバイスは、分散データベースのアドレスブックに追加されることによって、メンバ及び／又はノードとして分散データベースに加入することができる。これは、（本明細書に説明されるように）分散データベースのコンセンサスプロトコルを使用して順序付けられたイベント内のトランザクションを使用して行うことができる。
【0129】
１６０４において、コンセンサスプロトコルの完了したラウンドに関連付けられた分散データベースの状態が、計算デバイスのセットからの計算デバイスから受信される。いくつかの実装形態では、状態は、分散データベースの、所定の数及び／又は割合（例えば、分散データベースにおけるメンバの少なくとも１／３及び／又は総ステークの１／３）の現在のメンバ及び／又はステークによってデジタル署名され得る。状態は、所与のラウンドｒの時点での分散データベースの状態であり得る（例えば、ｒの受信ラウンド又は前に実行及び／若しくは処理されたラウンドを有するイベントに含まれるトランザクションを有する）。いくつかの実装形態では、状態は、イベントのコアセットからの各イベントのラウンド識別子とともに、完了したラウンドに関連付けられたイベントのコアセットの指標（例えば、イベントのコアセットからの各イベントのハッシュ値）を含むか、又はそれとともに送信される。いくつかの実装形態では、イベントのコアセットは、完了したラウンドの以前の所定の数のラウンドである世代を有する（例えば、期限切れ及び／又は古代である）イベントを含まない。
【0130】
１６０６において、状態に関連付けられたイベントのセットが、計算デバイスのセットから受信される。イベントのセットは、計算デバイスのセットからの他の計算デバイスとの同期に基づいて受信され得る。
【0131】
１６０８において、イベントのコアセットと、イベントのコアセットからの各イベントに対するラウンド識別子と、に基づいて、イベントのセットからの各イベントについての属性のセットが算出される。例えば、コンセンサスプロトコル（例えば、作成されたラウンド、各ラウンドの有名なウィットネスなど）に関して本明細書に説明される属性は、イベントのセットからの各イベントについて算出することができる。
【0132】
１６１０において、イベントのセットと、イベントのセットについての属性のセットと、に基づいて、有向非巡回グラフ（ＤＡＧ）が構築され、１６１２において、ＤＡＧを使用して、コンセンサスプロトコルの次のラウンドに関連付けられたイベントの順序が算出される。分散データベースに接続及び／又は加入する計算デバイスは、完全に機能する、最新のメンバとして、機能し続けることができる。
【0133】
いくつかの場合、分散データベース（例えば、図１に関して図示及び説明される）は、暗号通貨を実装するために使用することができる。そのような場合、各分散データベースインスタンス１１４、１２４、１３４、１４４は、暗号通貨を記憶するために１つ以上のウォレットデータ構造（本明細書ではウォレットとも呼ばれる）を定義することができる。いくつかの場合、分散データベースに関連付けられていないユーザ（例えば、分散データベースのメンバではない計算デバイス）も、そのようなウォレットを作成及び／又は定義することができる。ウォレットデータ構造は、鍵ペア（公開鍵及び秘密鍵）を含むことができる。いくつかの場合、ウォレットの鍵ペアは、そのウォレットを生じさせる計算デバイスによって生成され得る。例えば、Ａｌｉｃｅがウォレット（Ｗ、Ｋ）を定義し、Ｗが公開鍵（ウォレットの識別子のように振る舞い得る）であり、Ｋが秘密鍵である場合、Ａｌｉｃｅは、分散データベースの残りのインスタンスにＷを（例えば、イベントにおいて）公開することができるが、分散データベースの他のインスタンス（又はそれらのユーザ）が、ウォレットＷがＡｌｉｃｅに関連付けられていることを識別することができないように、Ａｌｉｃｅの識別情報を匿名に保つ。
【0134】
図７は、一実施形態による、イベントを同期させる２つの計算デバイスの信号フロー図を例解する。具体的には、いくつかの実施形態では、分散データベースインスタンス７０３及び８０３は、収束を取得するためにイベントを交換することができる。計算デバイス７００は、計算デバイス８００との関係に基づいて、計算デバイス７００への近接度に基づいて、計算デバイス７００に関連付けられた順序付けられたリストに基づいて、及び／又は同様のものに基づいて、ランダムに計算デバイス７００と同期することを選択することができる。いくつかの実施形態では、計算デバイス８００は、分散データベースシステムに属する計算デバイスのセットから計算デバイス７００によって選択され得るので、計算デバイス７００は、続けて複数回計算デバイス８００を選択することができるか、又はしばらくの間計算デバイス８００を選択しない場合がある。他の実施形態では、以前に選択された計算デバイスの指標を計算デバイス７００で記憶することができる。そのような実施形態では、計算デバイス７００は、計算デバイス８００を再び選択することができるようになる前に、所定の数の選択を待つことができる。上で説明したように、分散データベースインスタンス７０３及び８０３は、それぞれ、計算デバイス７００のメモリ及び計算デバイス８００のメモリにおいて実装することができる。
【0135】
いくつかの実装形態では、計算デバイス７００は、一度に実行される複数のスレッドを有することができ、各スレッドは別のメンバと同期する。したがって、計算デバイス７００は、計算デバイス８００に加えて他の計算デバイス（図７には図示せず）と同期することができる。いくつかの場合、計算デバイス７００は、初回又は最初に各スレッドのための接続を確立し、その後、ハートビートメッセージを周期的に送信する（例えば、ハートビートを１秒間に２回送信する）ことによって、各接続をアライブ又はオープンに維持することができる。したがって、いくつかの場合、計算デバイス７００は、計算デバイスが同期のために別のメンバ又は計算デバイスとの接続を確立するたびに、転送レイヤセキュリティ（Transfer Layer Security、ＴＬＳ）プロトコル（例えば、記録プロトコル及びハンドシェイクプロトコル）によって別様に引き起こされる同期待ち時間又は遅延を防止することができる。他のメンバ又は計算デバイスとの接続（接続のプールとして含む）を確立及び維持することに関する更なる詳細は、２０１８年７月１１日に米国特許出願第１６／０３２，６５２号として出願され、「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｅｆｆｉｃｉｅｎｔｌｙ Ｉｍｐｌｅｍｅｎｔｉｎｇ ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ ｗｉｔｈｉｎ ａ Ｎｅｔｗｏｒｋ」と題された米国特許第１０，３７５，０３７号に見出すことができ、その全体が参照により本明細書に組み込まれる。
【0136】
図３～図６は、一実施形態によるハッシュグラフの例を例解する。５つのメンバが存在し、その各々は、濃い垂直線によって表される。各円は、イベントを表す。イベントから下に向かう２本の線は、前の２つのイベントのハッシュを表す。この例における全てのイベントは、各メンバの第１のイベントを除いて、下に向かう２本の線（同じメンバへの１本の濃い線及び別のメンバへの１本の薄い線）を有する。時間は、上に向かって進む。図３～図６において、分散データベースの計算デバイスは、Ａｌｉｃｅ、Ｂｏｂ、Ｃａｒｏｌ、Ｄａｖｅ、及びＥｄとして示される。そのような指標は、図１に関して図示及び説明される計算デバイス１１０、１２０、１３０、及び１４０と構造的及び機能的に同様の計算デバイスを指すことを理解されたい。以下の段落は、分散データベースを実装するための例示的なシステムを含む。実施例のいずれも、以下に列挙されるか、又は本明細書に別様に説明される他の実施例、デバイス、方法、及び／又はシステムと組み合わせることができることを理解されたい。
【0137】
例示的なシステム１：計算デバイス７００がＡｌｉｃｅと呼ばれ、計算デバイス８００がＢｏｂと呼ばれる場合、それらの間の同期は、図７に例解することができる。ＡｌｉｃｅとＢｏｂとの間の同期は、例えば、以下のとおりである。
－Ａｌｉｃｅは、分散データベース７０３に記憶されたイベントをＢｏｂに送信する。
－Ｂｏｂは、以下を含む新しいイベントを作成及び／又は定義する。
－－Ｂｏｂが作成及び／又は定義した最後のイベントのハッシュ
－－Ａｌｉｃｅが作成及び／又は定義した最後のイベントのハッシュ
－－上記のＢｏｂによるデジタル署名
－Ｂｏｂは、分散データベース８０３に記憶されたイベントをＡｌｉｃｅに送信する。
－Ａｌｉｃｅは新しいイベントを作成及び／又は定義する。
－ＡｌｉｃｅはＢｏｂにそのイベントを送信する。
－Ａｌｉｃｅは、ハッシュグラフの関数として、イベントの全順序を算出する
－Ｂｏｂは、ハッシュグラフの関数として、イベントの全順序を算出する
－Ａｌｉｃｅは、分散データベース７０３に記憶されたイベントをＢｏｂに送信する。
－Ｂｏｂは、以下を含む新しいイベントを作成及び／又は定義する。
－－Ｂｏｂが作成及び／又は定義した最後のイベントのハッシュ
－－Ａｌｉｃｅが作成及び／又は定義した最後のイベントのハッシュ
－－上記のＢｏｂによるデジタル署名
－Ｂｏｂは、分散データベース８０３に記憶されたイベントをＡｌｉｃｅに送信する。
－Ａｌｉｃｅは新しいイベントを作成及び／又は定義する。
－ＡｌｉｃｅはＢｏｂにそのイベントを送信する。
－Ａｌｉｃｅは、ハッシュグラフの関数として、イベントの全順序を算出する
－Ｂｏｂは、ハッシュグラフの関数として、イベントの全順序を算出する
【0138】
任意の所与の時間に、メンバは、各イベントを作成及び／又は定義した計算デバイス及び／又は分散データベースインスタンスに関連付けられた識別子とともに、これまでに受信されたイベントを記憶することができる。各イベントは、初期イベント（親ハッシュを有しない）と、新しい各メンバ（単一の親イベントハッシュを有し、それらを加入させた既存のメンバのイベントを表す）に対する第１のイベントとを除いて、先の２つのイベントのハッシュを含む。このイベントのセットを表す図を描くことができる。それは、各メンバに対する垂直線と、そのメンバによって作成及び／又は定義された各イベントに対するその線上のドット又は円とを示すことができる。イベント（より高いドット）が先のイベント（より低いドット）のハッシュを含むときはいつでも、２つのドット間に斜線が引かれる。イベントは、そのイベントがそのイベントのハッシュを介して（直接的に又は中間イベントを通じて）他のイベントを参照することができる場合、別のイベントにリンクされていると言うことができる。
【0139】
例えば、図３は、ハッシュグラフ６００の一例を例解する。イベント６０２は、Ｃａｒｏｌとの同期後の結果として、Ｂｏｂによって作成及び／又は定義される。イベント６０２は、イベント６０４（Ｂｏｂによって作成及び／又は定義された以前のイベント）のハッシュと、イベント６０６（Ｃａｒｏｌによって作成及び／又は定義された以前のイベント）のハッシュとを含む。いくつかの実施形態では、例えば、イベント６０２内に含まれるイベント６０４のハッシュは、その直近の先祖イベントであるイベント６０８及び６１０へのポインタを含む。したがって、Ｂｏｂは、イベント６０２を使用してイベント６０８及び６１０を参照し、前のイベントへのポインタを使用してハッシュグラフを再構成することができる。いくつかの場合、イベント６０２は、ハッシュグラフ６００内の他のイベントにリンクされていると言うことができる。なぜなら、イベント６０２は、ハッシュグラフ６００内のイベントの各々を、先の先祖イベントを介して参照することができるからである。例えば、イベント６０２は、イベント６０４を介してイベント６０８にリンクされる。別の例では、イベント６０２は、イベント６０６及びイベント６１２を介して、イベント６１６にリンクされる。
【0140】
例示的なシステム２：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）からのシステムであって、イベントはまた、記録するためのトランザクション又は他の情報の「ペイロード」を含む。そのようなペイロードを使用して、計算デバイスの直前のイベント以降に発生した、かつ／又は定義された任意のトランザクション及び／又は情報でイベントを更新することができる。例えば、イベント６０２は、イベント６０４が作成及び／又は定義された以降にＢｏｂによって実施された、任意のトランザクションを含むことができる。したがって、イベント６０２を他の計算デバイスと同期させるとき、Ｂｏｂはこの情報を共有することができる。したがって、Ｂｏｂによって実施されたトランザクションは、イベントに関連付けられ、イベントを使用して他のメンバと共有され得る。いくつかの実装形態では、例示的なシステム２はまた、例示的なシステム２を具体的に参照しない場合がある、本明細書に開示される他の例示的なシステムにも適用することができる。
【0141】
例示的なシステム３：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）からのシステムであって、イベントは、デバッグ、診断、及び／又は他の目的に有用な、現在時刻及び／又は日付も含む。時刻及び／又は日付は、計算デバイス（例えば、Ｂｏｂ）がイベントを作成及び／又は定義するローカル時刻及び／又は日付であり得る。そのような実施形態では、そのようなローカル時刻及び／又は日付は、残りのデバイスと同期されない。他の実施形態では、時刻及び／又は日付は、デバイスにわたって（例えば、イベントを交換するときに）同期され得る。更に他の実施形態では、時刻及び／又は日付を決定するために、グローバルタイマを使用することができる。
【0142】
例示的なシステム４：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）からのシステムであって、Ａｌｉｃｅは、Ｂｏｂによって作成及び／又は定義されたイベントも、そのようなイベントの先祖イベントも、Ｂｏｂに送信しない。ｙがｘのハッシュを含む場合、又はｙがｘの子孫であるイベントのハッシュを含む場合、イベントｘはイベントｙの先祖である。同様に述べると、そのような実施形態では、Ｂｏｂは、Ａｌｉｃｅによってまだ記憶されていないイベントをＡｌｉｃｅに送信し、Ａｌｉｃｅによってすでに記憶されているイベントを送信しない。
【0143】
例えば、図４は、イベント６２２（黒色の円）の先祖イベント（ドット模様の円）及び子孫イベント（ストライプ模様の円）を例解する、例示的なハッシュグラフ６２０を例解する。線はイベントの半順序を確立し、ここで、先祖は黒色のイベントの前に来て、子孫は黒色のイベントの後に来る。半順序は、白色のイベントが黒色のイベントの前であるか後であるかを示すものではないため、それらのシーケンスを決定するには全順序又はコンセンサス順序を使用する。別の例として、図５は、１つの特定のイベント（塗りつぶされた円）と、各メンバがそのイベントの指標を最初に受信したとき（ストライプ模様の円）とを例解する例示的なハッシュグラフを例解する。Ｃａｒｏｌがイベント６２４を作成及び／又は定義するためにＤａｖｅと同期するとき、Ｄａｖｅは、イベント６２２の先祖イベントをＣａｒｏｌに送信しない。なぜなら、Ｃａｒｏｌは、そのようなイベントをすでに認識しており、受信しているからである。代わりに、Ｄａｖｅは、Ｃａｒｏｌがまだ受信していない、かつ／又はＣａｒｏｌの分散データベースインスタンスに記憶していないイベントを、Ｃａｒｏｌに送信する。いくつかの実施形態では、Ｄａｖｅは、Ｃａｒｏｌが以前に受信したイベントについてＤａｖｅのハッシュグラフが明らかにするものに基づいて、Ｃａｒｏｌに送信すべきイベントを識別することができる。イベント６２２は、イベント６２６の先祖である。したがって、イベント６２６の時点で、Ｄａｖｅはすでにイベント６２２を受信している。図４は、Ｃａｒｏｌからイベント６２２を受信したＢｏｂからイベント６２２を受信したＥｄから、Ｄａｖｅがイベント６２２を受信したことを示す。更に、イベント６２４の時点で、イベント６２２は、Ｃａｒｏｌによって作成及び／又は定義された、Ｄａｖｅが受信した最後のイベントである。したがって、Ｄａｖｅは、イベント６２２及びその先祖以外のＤａｖｅが記憶したイベントをＣａｒｏｌに送信することができる。追加的に、イベント６２６をＤａｖｅから受信すると、Ｃａｒｏｌは、Ｃａｒｏｌの分散データベースインスタンスに記憶されたイベント内のポインタに基づいて、ハッシュグラフを再構築することができる。他の実施形態では、Ｄａｖｅは、Ｃａｒｏｌがイベント６２２をＤａｖｅ（図４には図示せず）に送信し、イベント６２２（及びその中の参照）を使用してＤａｖｅが識別して、Ｃａｒｏｌがすでに受信したイベントを識別することに基づいて、どのイベントをＣａｒｏｌに送信すべきかを識別することができる。ハッシュグラフを再構築することによって、Ｃａｒｏｌは、コンセンサスプロトコルの各ラウンドについてＤａｖｅから実際に投票を受信することなく、上で説明されるコンセンサスプロトコルにおいてＤａｖｅがどのように投票するであろうかを決定することができる。同様に、Ｃａｒｏｌのハッシュグラフに基づいて、Ｃａｒｏｌは、分散データベースの残りの各メンバが、特に投票を受信することなく、どのように投票するであろうかを決定することができる。これは、コンセンサスプロトコルの各ラウンドに対する投票が分散データベースのメンバ間で交換されないので、ネットワークトラフィックを低減する。
【0144】
例示的なシステム５：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）からのシステムであって、受信側がイベントの先祖を受信及び／又は記憶するまでそのイベントが送信されないような順序で、両方のメンバが、イベントを他方に送信する。したがって、送信側は、イベントを最も古いものから最も新しいものへ送信し、その結果、受信側は、２つのハッシュをすでに受信された２つの先祖イベントと比較することによって、イベントが受信されるときに各イベント上の２つのハッシュをチェックすることができる。送信側は、送信側のハッシュグラフの現在の状態（例えば、送信側によって定義されたデータベース状態変数）と、そのハッシュグラフが受信側がすでに受信したことを示すものとに基づいて、どのイベントを受信側に送信すべきかを識別することができる。図３を参照すると、例えば、Ｂｏｂがイベント６０２を定義するためにＣａｒｏｌと同期しているとき、Ｃａｒｏｌは、イベント６１９が、Ｃａｒｏｌが受信したＢｏｂによって作成及び／又は定義された最後のイベントであることを識別することができる。したがって、Ｃａｒｏｌは、Ｂｏｂがそのイベント及びその先祖を知っていると判定することができる。これによりＣａｒｏｌはＢｏｂに、イベント６１８及びイベント６１６（すなわち、Ｃａｒｏｌが受信したイベントのうちＢｏｂがまだ受信していない最も古いイベント）を最初に送信することができる。次いで、Ｃａｒｏｌは、Ｂｏｂにイベント６１２を送信し、次いでイベント６０６を送信することができる。これは、Ｂｏｂが、イベントを容易にリンクしてＢｏｂのハッシュグラフを再構築することを可能にする。ＢｏｂはＣａｒｏｌにイベントを要求しないため、Ｃａｒｏｌのハッシュグラフを使用してＢｏｂがまだ受信していないイベントを識別することにより、同期の効率を増加させることができ、ネットワークトラフィックを低減することができる。
【0145】
他の実施形態では、直近のイベントを最初に送信することができる。受信側が、（直近のイベント内の２つの以前のイベントのハッシュ及び／又は直近のイベント内の以前のイベントへのポインタに基づいて）２つの以前のイベントのうちの１つをまだ受信していないと判定した場合、受信側は、送信側にそのようなイベントを送信するように要求することができる。これは、受信側が直近のイベントの先祖を受信及び／又は記憶するまで行うことができる。図３を参照すると、そのような実施形態では、例えば、ＢｏｂがＣａｒｏｌからイベント６０６を受信するとき、Ｂｏｂは、イベント６０６内の、イベント６１２及びイベント６１４のハッシュを識別することができる。Ｂｏｂは、イベント６０４を作成及び／又は定義するときに、イベント６１４がＡｌｉｃｅから以前に受信されたと判定することができる。したがって、ＢｏｂはＣａｒｏｌにイベント６１４を要求する必要はない。Ｂｏｂはまた、イベント６１２がまだ受信されていないことを判定することもできる。次いで、ＢｏｂはＣａｒｏｌにイベント６１２を要求することができる。次いで、Ｂｏｂは、イベント６１２内のハッシュに基づいて、Ｂｏｂがイベント６１６又は６１８を受信していないことを判定することができ、したがって、これらのイベントをＣａｒｏｌに要求することができる。イベント６１６及び６１８に基づいて、Ｂｏｂは、イベント６０６の先祖を受信したことを判定することができる。
【0146】
例示的なシステム６：例示的なシステム５からのシステム（又は本明細書に開示される任意の他の例示的なシステム）であって、メンバが次に送信するいくつかのイベント間の選択肢を有するときに、イベントが、そのメンバによって作成及び／又は定義されたそれまでに送信されたバイトの総数を最小化するように選択されるという、追加の制約を伴う。例えば、ＡｌｉｃｅにはＢｏｂに送信するイベントが２つだけ残されており、１つは１００バイトであり、かつＣａｒｏｌによって作成及び／又は定義されたものであり、１つは１０バイトであり、かつＤａｖｅによって作成及び／又は定義されたものであり、またこの同期においてそれまでに、ＡｌｉｃｅがすでにＣａｒｏｌによる２００バイトのイベントを送信しておりＤａｖｅによる２１０バイトのイベントを送信していた場合、Ａｌｉｃｅは、最初にＤａｖｅイベントを送信し、続いてＣａｒｏｌイベントを送信すべきである。２１０＋１０＜１００＋２００であるからである。これは、単一のメンバが単一の巨大なイベントを送出するか又は大量の小さいイベントを送信するかのいずれかの攻撃に対処するために使用することができる。（例示的なシステム７に関して考察されるように、）トラフィックが大部分のメンバのバイト制限を超える場合では、例示的なシステム６の方法は、正当なユーザのイベントではなく、攻撃者のイベントが無視されることを保証することができる。同様に述べると、攻撃は、（接続を拘束する１つの巨大イベントに対して防御するために）より大きいイベントの前により小さいイベントを送信することによって低減することができる。更に、メンバが単一の同期でイベントの各々を（例えば、ネットワーク制限、メンババイト制限などにより）送信できない場合、そのメンバは、攻撃者によって定義及び／又は作成されたイベントを単に送信し、他のメンバによって作成及び／又は定義された（少数のうちの）いずれのイベントも送信しないのではなく、各メンバから少数のイベントを送信することができる。
【0147】
例示的なシステム７：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）からのシステムであって、ＢｏｂがＡｌｉｃｅに、この同期中に受信する意思がある最大バイト数を示す数を送信し、かつＡｌｉｃｅがＡｌｉｃｅの制限を返信する、追加の第１のステップを伴う。次に、Ａｌｉｃｅは、次のイベントがこの限度を超えそうになると送信を停止する。Ｂｏｂは同じことを行う。このような実施形態では、これは転送されるバイト数を制限する。これは、収束までの時間は増加させ得るが、同期ごとのネットワークトラフィックの量を低減させる。
【0148】
代替的又は追加的に、いくつかの実装形態では、同期プロセスごとのバイト数の制限、及び／又は同期プロセスごとに同期されることが許可されるイベントの数の制限が、分散データベース内に実装される。例えば、Ａｌｉｃｅは、Ｂｏｂにまだ知られていないイベントをＢｏｂに送信することができ、次いで、Ａｌｉｃｅに関連付けられたデータベースのインスタンスは、次のイベントが、許容可能なバイト数（すなわち、同期されたデータの量）又は同期される許容可能なイベント数のいずれかに基づく同期閾値を超える、かつ／又はそれに達すると、データパケット及び／又はイベントの送信を停止及び／又は終了することができる。そのような場合のイベントの伝送は、両方のイベントが同期している場合、イベントを送信する前にイベントの親を送信することによって実施することができる。
【0149】
いくつかの場合、ＡｌｉｃｅがＢｏｂと同期しており、Ｂｏｂに２つのイベント、例えばイベントＸ及びイベントＹを送信する必要があり、Ｂｏｂがすでにそれらの両方のイベントの全ての親を有している場合、Ａｌｉｃｅはどちらを最初に送信するかを選択することができる。いくつかの実装形態では、Ａｌｉｃｅは、Ｘ内の全てのバイトに、Ａｌｉｃｅがこの同期中にすでに送信したＸの作成者による全てのイベント内のバイトを加えた合計バイト（Ｂｘ）を算出することができる。同様に、Ｙ内のバイト及びこれまでに送信されたＹの作成者によるイベントに対する総バイト（Ｂｙ）を算出することができる。次に、Ａｌｉｃｅは、Ｂｘ＜Ｂｙの場合はＹの前にＸを送信し、Ｂｙ＜Ｂｘの場合は、Ｘの前にＹを送信し、Ｂｘ＝Ｂｙの場合は、いずれかの順序で送信することを選択することができる。
【0150】
いくつかの場合、２つのメンバ間の同期は、（例えば、サービス妨害攻撃を防止するために）同期ごとの受信イベントの最大数に制限され得る。その同期に関連する全てのイベントが受信される前にそのような限界に達した場合、同期は早く終了する。いくつかの他の場合、各同期イベントは、（受信イベントの数に限定される代わりに、又はそれに加えて）受信バイトの最大数に限定され得る。したがって、受信イベントの最大数及び受信バイトの最大数などの制限を使用して、同期中に別のメンバ（例えば、Ａｌｉｃｅ）から受信側メンバ（例えば、Ｂｏｂ）によって受信及び／又は受け入れられるイベント及び／又はバイトの数を制約又は調整することができる。前述の制限は、悪意のあるメンバが大きなイベントを作成するか、又は膨大な数の小さいイベントでネットワークを氾濫させる攻撃を防止することができる。また、これらの制限は、例えば、１つのメンバが平均量のデータトラフィックを扱うが、データトラフィックの急増を扱わない低帯域幅接続を有するときに、グレースフルデグラデーションを保証する。
【0151】
いくつかの実装形態では、コンセンサスがまだ識別されていない全ての既知のイベントが、トランザクションを含まない空のイベントである場合、メンバ又は計算デバイスは、別のメンバ又は計算デバイスとの同期を開始しない。これにより、長い期間新しいトランザクションがない場合に、メンバが帯域幅を浪費しないことを保証する。
【0152】
いくつかの場合、コンセンサスの欠如によって、メンバ又は計算デバイスのメモリのオーバフローが引き起こされる可能性がある。例えば、コンセンサスがまだ識別されていないイベントのセットは、例えば、母集団の少なくとも１／３がオフラインである場合、所与の閾値を超えて成長又は増加する可能性がある。これは、オンラインであるメンバが少なすぎるときに、コンセンサスが導出されない可能性があるからである。したがって、メンバ又は計算デバイスのメモリは、コンセンサスに達することができないイベントの累積数でオーバフローする可能性がある。コンセンサスが達成され得ない蓄積されたイベントによるメモリオーバフローを防止するために、各メンバ及び／又は計算デバイスは、コンセンサスがまだ達成されていないイベントの閾値に達すると、そのメンバ又は計算デバイスが、そのメンバ又は計算デバイスが認識しているイベントのうちのいくつかについてコンセンサスに達するまで、任意の新しいイベントを定義及び／又は作成することを拒否することができるように構成され得る。別の言い方をすれば、いくつかの場合、コンセンサスの欠如により、コンセンサスを達成することができない場合（例えば、オンラインでありコンセンサスを導出することができるメンバが少なすぎる場合）、オーバフローが引き起こされる可能性がある。したがって、（例えば、オンラインのメンバが少なすぎるために）コンセンサス順序に入れることができないイベントのオーバフローを防止するために、メンバは、オフラインメンバのいくつかからイベントを受信して、より古いイベントのいくつかに関するコンセンサスに達することができるまで、追加のイベントを定義しない。
【0153】
例示的なシステム８：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）からのシステムであって、同期化プロセスの開始時に、以下のステップが追加された。
－Ａｌｉｃｅは、Ｂｏｂによって作成及び／若しくは定義されたイベント、又はＢｏｂによって作成及び／若しくは定義されたイベントの先祖であるイベントをスキップして、Ａｌｉｃｅが受信及び／又は記憶したイベントのセットであるＳを識別する。
－Ａｌｉｃｅは、Ｓ内の各イベントを作成及び／又は定義したメンバを識別し、メンバのＩＤ番号のリストをＢｏｂに送信する。Ａｌｉｃｅはまた、Ａｌｉｃｅがすでに受信及び／又は記憶した各メンバによって作成及び／又は定義されたイベントの数を送信する。
－Ｂｏｂは、他のメンバによって作成及び／又は定義された、Ｂｏｂが受信したイベントの数のリストを返信する。
－Ａｌｉｃｅは、Ｂｏｂがまだ受信していないイベントのみをＢｏｂに送信する。例えば、ＡｌｉｃｅがＢｏｂに、ＡｌｉｃｅがＣａｒｏｌによって作成及び／又は定義された１００個のイベントを受信したことを示し、Ｂｏｂが、ＢｏｂがＣａｒｏｌによって作成及び／又は定義された９５個のイベントを受信したことを返信した場合、Ａｌｉｃｅは、Ｃａｒｏｌによって作成及び／又は定義された直近の５個のイベントのみを送信する。
－Ａｌｉｃｅは、Ｂｏｂによって作成及び／若しくは定義されたイベント、又はＢｏｂによって作成及び／若しくは定義されたイベントの先祖であるイベントをスキップして、Ａｌｉｃｅが受信及び／又は記憶したイベントのセットであるＳを識別する。
－Ａｌｉｃｅは、Ｓ内の各イベントを作成及び／又は定義したメンバを識別し、メンバのＩＤ番号のリストをＢｏｂに送信する。Ａｌｉｃｅはまた、Ａｌｉｃｅがすでに受信及び／又は記憶した各メンバによって作成及び／又は定義されたイベントの数を送信する。
－Ｂｏｂは、他のメンバによって作成及び／又は定義された、Ｂｏｂが受信したイベントの数のリストを返信する。
－Ａｌｉｃｅは、Ｂｏｂがまだ受信していないイベントのみをＢｏｂに送信する。例えば、ＡｌｉｃｅがＢｏｂに、ＡｌｉｃｅがＣａｒｏｌによって作成及び／又は定義された１００個のイベントを受信したことを示し、Ｂｏｂが、ＢｏｂがＣａｒｏｌによって作成及び／又は定義された９５個のイベントを受信したことを返信した場合、Ａｌｉｃｅは、Ｃａｒｏｌによって作成及び／又は定義された直近の５個のイベントのみを送信する。
【0154】
例示的なシステム９：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）からのシステムであって、不正者を識別及び／又は扱うための追加の機構を伴う。各イベントは２つのハッシュを含み、１つは、そのメンバによって作成及び／又は定義された最後のイベントからのもの（「自己ハッシュ」）であり、１つは、別のメンバによって作成及び／又は定義された最後のイベントからのもの（「外部ハッシュ」）である。メンバが、同じ自己ハッシュを有する２つの異なるイベントを作成及び／又は定義する場合、そのメンバは「不正者」である。Ａｌｉｃｅが、同じ自己ハッシュを用いてＤａｖｅにより作成及び／又は定義された２つの異なるイベントを受信することによって、Ｄａｖｅが不正者であることを発見した場合、Ａｌｉｃｅは、Ｄａｖｅが不正者であるというインジケータを記憶し、将来自分と同期することを控える。Ａｌｉｃｅが、Ｄａｖｅが不正者であることを発見し、依然としてＤａｖｅと再び同期し、その事実を記録する新しいイベントを作成及び／又は定義する場合、Ａｌｉｃｅも不正者になり、Ａｌｉｃｅが更にＤａｖｅと同期していることを学習する他のメンバは、Ａｌｉｃｅとの同期を停止する。いくつかの実施形態では、これは一方向の同期のみに影響を与える。例えば、Ａｌｉｃｅは、識別子のリストと各メンバについてＡｌｉｃｅが受信したイベントの数とを送信する場合、不正者のＩＤ又はカウントを送信しないため、Ｂｏｂは、任意の対応する数を返信しない。次いで、ＡｌｉｃｅはＢｏｂに、Ｂｏｂがそのようなイベントを受信したという指標をＡｌｉｃｅが受信していない、不正者のイベントを送信する。その同期が終了した後、Ｂｏｂはまた、（ＢｏｂがＤａｖｅを不正者としてまだ識別していない場合は）Ｄａｖｅが不正者であると判定することもでき、Ｂｏｂはまた、その不正者と同期することを拒否する。
【0155】
例示的なシステム１０：例示的なシステム９におけるシステム（又は本明細書に開示される任意の他の例示的なシステム）であって、Ａｌｉｃｅが、Ａｌｉｃｅが識別した不正者のリスト及びＡｌｉｃｅが依然として記憶しているその不正者のイベントのリストをＢｏｂに送信することによって同期プロセスを開始し、Ｂｏｂが、Ａｌｉｃｅが識別した不正者に加えてＢｏｂが識別した任意の不正者を返信する、という追加を伴う。次いでＡｌｉｃｅとＢｏｂは通常どおり継続するが、互いに同期するときに不正者のカウントを与えない。
【0156】
例示的なシステム１１：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）におけるシステムであって、同期中に受信される任意の新しいイベントの内部のトランザクションに基づいて、（例えば、システムのメンバによって定義されるデータベース状態変数によって捕捉されるような）現在の状態を繰り返し更新するプロセスを伴う。これは第２のプロセスも含むことができ、この第２のプロセスは、イベントのシーケンスが変化するといつでも、先の状態のコピーに戻り、新しい順序でイベントを処理することによって現在の状態を再算出することによって、その状態（例えば、イベントの順序）を繰り返し再構築する。したがって、例えば、各計算デバイスは、状態の２つのバージョンを維持することができる（１つは、（半順序に基づいて）新しいイベント及びトランザクションが受信されたときに更新され、１つは、（全順序又はコンセンサス順序に基づいて）コンセンサスが達成された後にのみ更新される）。ある時点で（例えば、ある時間期間の後、所与の数のイベントが定義及び／又は受信された後など）、新しいイベント及びトランザクションが受信されたときに更新される状態のバージョンを破棄することができ、コンセンサスが達成された後にのみ更新される状態の新しいコピーを、新しいイベント及びトランザクションが受信されたときに更新される状態の新しいバージョンとして作ることができる。これは、両方の状態の同期を保証することができる。
【0157】
いくつかの実施形態では、現在の状態は、トランザクションの結果に関連付けられた状態、残高、条件及び／又は同様のものである。同様に述べると、状態は、トランザクションによって修正されたデータ構造及び／又は変数を含むことができる。例えば、トランザクションが銀行口座間の送金である場合、現在の状態は、口座の現在の残高であり得る。別の例では、トランザクションがマルチプレーヤゲームに関連付けられている場合、現在の状態は、ポジション、ライフの数、取得されたアイテム、ゲームの状態、及び／又はゲームに関連付けられた同様のものであり得る。
【0158】
例示的なシステム１２：例示的なシステム１１におけるシステム（又は本明細書に開示される任意の他の例示的なシステム）であって、状態（例えば、銀行口座残高、ゲーム状態など）を維持するための「高速クローン」ａｒｒａｙＬｉｓｔの使用によってより高速にされたシステムである。高速クローンａｒｒａｙＬｉｓｔは、１つの追加の特徴を有するアレイのように振る舞うデータ構造であり、オリジナルのコピーである新しいオブジェクトを作成及び／又は定義するように見える「クローン」動作をサポートする。クローンに対する変更はオリジナルに影響を及ぼさないので、クローンは真のコピーであるかのように振る舞う。しかしながら、クローンを作成することは、１つのａｒｒａｙＬｉｓｔの内容全体を別のａｒｒａｙＬｉｓｔにコピー及び／又は更新することを実際には伴わないので、クローニング動作は、真のコピーを作成するよりも高速である。オリジナルリストの２つのクローン及び／又はコピーを有する代わりに、各々がハッシュテーブル及びオリジナルリストへのポインタを有する、２つの小さいオブジェクトを使用することができる。クローンに書き込みが行われると、ハッシュテーブルは、どの要素が修正されたか、及び新しい値を記憶する。ある場所で読み出しが実施されるとき、ハッシュテーブルが最初にチェックされ、その要素が修正された場合、ハッシュテーブルからの新しい値が返される。そうでない場合、元のａｒｒａｙＬｉｓｔからの要素が返される。このようにして、２つの「クローン」は、初めは元のａｒｒａｙＬｉｓｔへのポインタにすぎない。しかし、各々が繰り返し修正されるにつれて、ａｒｒａｙＬｉｓｔは、それ自体と元のリストとの間の差異を記憶する大きなハッシュテーブルを有するように成長する。クローン自体をクローン化して、データ構造をオブジェクトのツリーに拡張させることができ、各オブジェクトはそれ自体のハッシュテーブル及びその親へのポインタを有する。したがって、読み出しは、要求されたデータを有する頂点が見出されるまで、又はルートに到達するまで、ツリーのウォークアップを引き起こす。頂点が大きすぎるか又は複雑になった場合、それを親の真のコピーで置き換えることができ、ハッシュテーブル内の変更をコピーに対して行うことができ、ハッシュテーブルを破棄することができる。加えて、クローンがもはや必要でなくなった場合、ガーベッジコレクション中に、ツリーからクローンを除去することができ、ツリーを折り畳むことができる。
【0159】
例示的なシステム１３：例示的なシステム１１におけるシステム（又は本明細書に開示される任意の他の例示的なシステム）であって、状態（例えば、銀行口座残高、ゲーム状態など）を維持するための「高速クローン」ハッシュテーブルの使用によってより高速にされたシステムである。これは、ツリーのルートがａｒｒａｙＬｉｓｔではなくハッシュテーブルであることを除いて、システム１２と同じである。
【0160】
例示的なシステム１４：例示的なシステム１１におけるシステム（又は本明細書に開示される任意の他の例示的なシステム）であって、状態（例えば、銀行口座残高、ゲーム状態など）を維持するための「高速クローン」リレーショナルデータベースの使用によってより高速にされたシステムである。例えば、高速クローンデータベースは、例示的なシステム１１に関して考察されるように、状態の２つのコピーを維持するために使用することができる。これは、既存のリレーショナルデータベース管理システム（Relational Database Management System、ＲＤＢＭＳ）の周りのラッパーとして振る舞うオブジェクトである。見かけの各「クローン」は、実際には、ＩＤ番号と、データベースを含むオブジェクトへのポインタとを有するオブジェクトである。ユーザのコードがデータベース上で構造化照会言語（Structure Query Language、ＳＱＬ）クエリを実施しようとするとき、そのクエリは最初に修正され、次に実際のデータベースに送信される。実際のデータベースは、各テーブルがクローンＩＤのための１つの追加フィールドを有することを除いて、クライアントコードによって見られるデータベースと同一である。例えば、クローンＩＤ１を有するオリジナルデータベースが存在し、次いで、ＩＤ２及びＩＤ３を有するデータベースの２つのクローン（例えば、状態の２つのコピーを維持するために使用される）が作成されると仮定する。各テーブルの各行は、クローンＩＤフィールドに１、２、又は３を有する。クエリがユーザコードからクローン２へのものであるとき、クエリは、フィールドに２又は１を有する行からのみ読み出されるように修正される。同様に、３までの読み出しは、３又は１のＩＤを有する行を探す。構造化照会言語（ＳＱＬ）コマンドがクローン２に行き、行を削除するように言い、その行が１を有する場合、コマンドは、１を３に変更するだけであるべきであり、これにより、その行を、もはやクローン２及び３によって共有されておらず、３のみに可視であるものとしてマークする。いくつかのクローンが動作中である場合、行のいくつかのコピーを挿入することができ、各々を異なるクローンのＩＤに変更することができ、それにより、新しい行は、その行を「削除した」ばかりのクローンを除くクローンに可視となる。同様に、クローン２に行が追加される場合、その行は２のＩＤを有するテーブルに追加される。行の修正は、削除したのち挿入することと等価である。前述のように、いくつかのクローンがガーベッジコレクションされる場合、ツリーを簡略化することができる。そのツリーの構造は、クローンにはアクセス可能ではないが純粋に内部で使用される、追加のテーブルに記憶される。
【0161】
例示的なシステム１５：例示的なシステム１１におけるシステム（又は本明細書に開示される任意の他の例示的なシステム）であって、状態を維持するための「高速クローン」ファイルシステムの使用によってより高速にされたシステムである。これは、ファイルシステムのラッパーとして振る舞うオブジェクトである。ファイルシステムは、ファイルシステムの異なるバージョンを管理するために高速クローンリレーショナルデータベースを使用して、既存のファイルシステムの上に構築される。基礎となるファイルシステムは、多数のファイルを、１つのディレクトリに記憶するか、又は（ディレクトリを小さく保つために）ファイル名に従って分割して記憶する。ディレクトリツリーはデータベースに記憶することができ、ホストファイルシステムには提供されない。ファイル又はディレクトリがクローンされるとき、「クローン」は単にＩＤ番号を有するオブジェクトであり、データベースは、このクローンが現在存在することを反映するように修正される。高速クローンファイルシステムがクローンされた場合、ユーザには、あたかも新しいハードドライブ全体が作成及び／又は定義され、既存のハードドライブのコピーで初期化されたかのように見える。１つのコピーへの変更は、他のコピーに影響を及ぼさない可能性がある。実際には、各ファイル又はディレクトリのコピーは１つのみであり、ファイルが１つのクローンを介して修正されたときにコピーが行われる。
【0162】
例示的なシステム１６：例示的なシステム１５（又は本明細書に開示される任意の他の例示的なシステム）におけるシステムであって、高速クローンファイルシステム内のファイルの各Ｎバイト部分について、別個のファイルが、ホストオペレーティングシステム上で作成及び／又は定義される。Ｎは、例えば４０９６又は１０２４のような何らかの好適なサイズであり得る。このようにして、大きなファイルにおいて１バイトが変更される場合、大きなファイルの１つのチャンクのみがコピーされ修正される。これはまた、数バイトしか異ならない多くのファイルをドライブに記憶するときの効率を増加させる。
【0163】
例示的なシステム１７：例示的なシステム１１（又は本明細書に開示される任意の他の例示的なシステム）におけるシステムであって、各メンバは、各メンバが作成及び／又は定義したイベントの一部又は全部に、以前のある時間における状態のハッシュを、その時点までに発生したイベントの数とともに含み、イベントの順序についてのコンセンサスが現在存在することをメンバが認識及び／又は識別することを示す。あるメンバが、所与の状態について大多数のユーザからそのようなハッシュを含む署名されたイベントを収集した後、そのメンバは次いで、その時点におけるコンセンサス状態の証明としてそれを記憶し、その時点の前のイベント及びトランザクションをメモリから削除することができる。
【0164】
例示的なシステム１８：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）におけるシステムであって、中央値又は多数決を算出する演算は、重み付けされた中央値又は重み付けされた多数決と置換され、メンバは、メンバの「ステーク」によって重み付けされる。ステークとは、そのメンバの投票がどれだけ重要かを示す数である。ステークは、暗号通貨での持ち株であり得るか、又は、単に、メンバが最初に加入するように招待されたときに割り当てられ、その後そのメンバが加入するように招待した新しいメンバの間で分割される任意の数であり得る。古いイベントは、十分なメンバがコンセンサス状態に同意し、それによりその総ステークが、存在するステークの多数決となったときに、破棄することができる。メンバによって寄与されるランクの中央値を使用して全順序が算出された場合、結果は、メンバの半分がより高いランクを有し、半分がより低いランクを有する数である。一方、重み付けされた中央値を使用して全順序が算出された場合、結果は、総ステークの約半分がそれより低いランクに関連付けられ、半分がそれより高いランクに関連付けられる数である。重み付けされた投票及び中央値は、シビル攻撃を防止するのに有用であり得、このシビル攻撃では、１つのメンバが膨大な数の「ソックパペット」ユーザを加入するように招待し、それらのユーザの各々は、招待しているメンバによって制御される偽名にすぎない。招待しているメンバが招待されているメンバとのステークを分割することを強制される場合、ソックパペットは、コンセンサス結果を制御しようと試みる攻撃者にとって有用ではない。したがって、いくつかの状況においてはプルーフオブステークが有用であり得る。
【0165】
例示的なシステム１９：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）におけるシステムであって、単一の分散データベースの代わりに、階層内に複数のデータベースが存在する。例えば、ユーザがメンバである単一のデータベース、次いで、各々がメンバのサブセットを有するいくつかのより小さいデータベース、又は「チャンク」が存在する可能性がある。イベントがチャンク内で発生するとき、それらのイベントは、そのチャンクのメンバ間で同期され、そのチャンク外のメンバ間では同期されない。次いで、時折、コンセンサス順序がチャンク内で決定された後に、結果として生じる状態（又はコンセンサス全順序を有するイベント）は、大きいデータベースのメンバシップ全体と共有することができる。
【0166】
例示的なシステム２０：例示的なシステム１１（又は本明細書に開示される任意の他の例示的なシステム）におけるシステムであって、（例えば、システムのメンバによって定義されるデータベース状態変数によって捕捉されるような）状態を更新するためのソフトウェアを更新するイベントを有する能力を有する。例えば、イベントＸ及びＹは、それらのイベント内のトランザクションを読み出し、次いで状態を適切に更新するソフトウェアコードに従って、状態を修正するトランザクションを含むことができる。次いで、イベントＺは、ソフトウェアの新しいバージョンが現在利用可能であるという通知を含むことができる。全順序が、イベントがＸ、Ｚ、Ｙの順序で起こることを示す場合、Ｘ内のトランザクションを古いソフトウェアで処理し、次いでＹ内のトランザクションを新しいソフトウェアで処理することによって、状態を更新することができる。しかし、コンセンサス順序がＸ、Ｙ、Ｚであった場合、Ｘ及びＹの両方を古いソフトウェアで更新することができ、これは異なる最終状態を与える可能性がある。したがって、そのような実施形態では、コードをアップグレードするための通知をイベント内で行うことができ、その結果、コミュニティは、古いバージョンから新しいバージョンにいつ切り替えるかについてコンセンサスに達することができる。いくつかの実施形態では、コードは、イベントＺ（コードをアップグレードするための通知を含む）の受信ラウンドの後のラウンドで古いバージョンから新しいバージョンに切り替えることができる。したがって、イベントＺが受信ラウンドｒを有すると判定された場合、ラウンドｒ又はその前の受信ラウンドを有する任意のイベントは、古いバージョンを使用して順序付けられるであろう。同様に、ラウンドｒの時点で受信ラウンドをまだ有していない任意のイベントは、新しいバージョンを使用して順序付けされるであろう。これにより、メンバが同期状態を維持することを保証する。また、アップグレード中であっても、プロセスをリブート又は再始動することを必要とせずに、システムが実行したままであることができることを保証する。
【0167】
例示的なシステム２１：例示的なシステム１（又は本明細書に開示される任意の他の例示的なシステム）におけるシステムであって、ハッシュグラフのメンバ又は計算デバイスは、分散データベースの署名された状態を定義することによって、分散データベースのインスタンスから不要なイベントを除去するように構成されている。いくつかの実装形態では、メンバ又は計算デバイスは、メモリのオーバフローを防止し、かつ／又はメモリリソースを節約するために、追加のプロセスを実行することができる。例えば、メンバ又は計算デバイスは、規則又は基準のセットに基づいて、古いイベントを定期的に破棄することができる。ルールは、例えば、イベントの受信ラウンドからラウンド番号（又は作成されたラウンド）を引いたものが、所与の閾値を超える場合、又はイベントの世代が閾値未満である場合に（例えば、ｅｘｐｉｒｅｄＤｕｒａｔｉｏｎ又はａｎｃｉｅｎｔＤｕｒａｔｉｏｎに基づく）、イベント内のトランザクションを無視又は破棄することを述べることができる。いくつかの場合、イベントは、それらの親のハッシュ及び各親に対して作成されたラウンドを含む。したがって、１つ以上の親が、あまりにも多くのラウンド前に作成されたために無視又は破棄されたことに起因して欠落している（例えば、本明細書に説明されるように、ａｎｃｉｅｎｔ又はｅｘｐｉｒｅｄである）場合であっても、所与のイベントを同期中に依然として受け入れることができる。したがって、署名された状態は、署名された状態の前のラウンドではあるが、署名された状態が無視又は破棄されるほど前ではないラウンドにおいて定義及び／又は作成されたイベントのハッシュを含み得る。不必要なイベントを除去又は破棄することにより、分散データベース（例えば、ハッシュグラフのメンバ）を実装する計算デバイスのセット間で冗長又は無関係なイベントを同期させることによって引き起こされるオーバーヘッドを減少させ、かつそのような計算デバイスのセットのローカルメモリの過少利用を減少させる。イベントを除去すること及び／又は破棄することに関する更なる詳細は、２０１７年１２月１９日に出願された「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｂａｓｅ ｔｈａｔ Ｅｎａｂｌｅｓ Ｄｅｌｅｔｉｏｎ ｏｆ Ｅｖｅｎｔｓ」と題される米国特許出願第１５／８４６，４０２号として出願された、米国特許出願公開第２０１８／０１７３７４７号に見出すことができ、その全体が参照により本明細書に組み込まれる。
【0168】
更に、いくつかの実装形態では、別のメンバとの同期中に、計算デバイスは、構文的に不正確である（例えば、構文解析しない）、又は無効なデジタル署名を有する受信イベントを拒否することができる。更に、いくつかの実装形態では、同期中に、期限切れの受信イベントを拒否することができる。更に、いくつかの実装形態では、同期中に、計算デバイスにおいて欠落している（例えば、その計算デバイス又は分散データベースのインスタンスのメモリ又はＤＡＧ内にない）、非古代の、非期限切れの親イベントを有する受信されたイベントは、非古代の、非期限切れの親イベントが受信されるまで、拒否され得る。
【0169】
上で説明されるシステムは、最終的なコンセンサスを有する、分散コンセンサスのための効率的な収束メカニズムを作成及び／又は達成することが予想される。以下に示されるように、これについていくつかの定理を証明することができる。
【0170】
例示的な定理１：イベントｘが半順序でイベントｙに先行する場合、所与の時間における、所与のメンバの他のメンバの知識において、他のメンバの各々は、ｙの前にｘの指標を受信するか、又はｙの指標をまだ受信していない。
【0171】
証明：イベントｘが半順序でイベントｙに先行する場合、ｘはｙの先祖である。メンバが初めてｙの指標を受信するとき、そのメンバはすでにｘの指標を先に受信しているか（この場合、ｙの前にｘを聞いている）、又は同期により、そのメンバにｘ及びｙの両方が提供される場合である（この場合、単一の同期中に受信されたイベントは、例示的なシステム５に関して説明された先祖関係と一致する順序で受信されたとみなされるので、その同期中にｙの前にｘを聞く）。証明終わり。
【0172】
例示的な定理２：任意の所与のハッシュグラフについて、ｘが半順序でｙに先行する場合、ｘは、そのハッシュグラフについて算出される全順序において、ｙに先行する。
【0173】
証明：ｘが半順序でｙに先行する場合、定理１により、
全てのｉについて、ｒａｎｋ（ｉ，ｘ）＜ｒａｎｋ（ｉ，ｙ）であり、
式中、ｒａｎｋ（ｉ，ｘ）は、メンバｉによってイベントｘに割り当てられるランクであり、ｘがメンバｉによって受信された第１のイベントである場合は１であり、第２のイベントである場合は２であり、以下同様である。ｍｅｄ（ｘ）を全てのｉにわたるｒａｎｋ（ｉ，ｘ）の中央値とし、ｍｅｄ（ｙ）についても同様とする。
全てのｉについて、ｒａｎｋ（ｉ，ｘ）＜ｒａｎｋ（ｉ，ｙ）であり、
式中、ｒａｎｋ（ｉ，ｘ）は、メンバｉによってイベントｘに割り当てられるランクであり、ｘがメンバｉによって受信された第１のイベントである場合は１であり、第２のイベントである場合は２であり、以下同様である。ｍｅｄ（ｘ）を全てのｉにわたるｒａｎｋ（ｉ，ｘ）の中央値とし、ｍｅｄ（ｙ）についても同様とする。
【0174】
所与のｋについて、ｒａｎｋ（ｉ１，ｘ）が、ｋ番目に最小のｘランクであり、ｒａｎｋ（ｉ２，ｙ）が、ｋ番目に最小のｙランクであるように、ｉ１及びｉ２を選択する。ゆえに、
ｒａｎｋ（ｉ１，ｘ）＜ｒａｎｋ（ｉ２，ｙ）である。
ｒａｎｋ（ｉ１，ｘ）＜ｒａｎｋ（ｉ２，ｙ）である。
【0175】
これは、ｒａｎｋ（ｉ２，ｙ）が、ｙランクのうちのｋ個以上であり、ｙ個の順位の各々が、対応するｘランクよりも厳密に大きいためである。したがって、ｒａｎｋ（ｉ２，ｙ）は、ｘランクのうちの少なくともｋ個よりも厳密に大きく、したがって、ｋ番目に最小のｘランクよりも厳密に大きい。この論証は、任意のｋについて当てはまる。
【0176】
ｎを、メンバの数（ｉ値の数）とする。したがって、ｎは奇数又は偶数のいずれかでなければならない。ｎが奇数である場合、ｋ＝（ｎ＋１）／２とし、ｋ番目に最小のランクが中央値となる。したがって、ｍｅｄ（ｘ）＜ｍｅｄ（ｙ）である。ｎが偶数である場合、ｋ＝ｎ／２であるとき、ｋ番目に最小のｘランクは、ｋ番目に最小のｙランクよりも厳密に小さく、（ｋ＋１）番目に最小のｘランクも、（ｋ＋１）番目に最小のｙランクよりも厳密に小さくなる。したがって、２つのｘランクの平均は、２つのｙランクの平均よりも小さくなる。したがって、ｍｅｄ（ｘ）＜ｍｅｄ（ｙ）である。したがって、両方の場合において、ｘランクの中央値は、ｙランクの中央値よりも厳密に小さくなる。したがって、中央値ランクにより振る舞いをソートすることによって全順序が定義される場合、ｘは、全順序においてｙに先行する。証明終わり。
【0177】
例示的な定理３：「ゴシップ期間」が、既存のイベントが同期を通じて全てのメンバに伝搬する時間量である場合、
１ゴシップ期間後：全てのメンバが、イベントを受信した
２ゴシップ期間後：全てのメンバが、それらのイベントの順序に合意する
３ゴシップ期間後：全てのメンバが、合意に達したことを知る
４ゴシップ期間後：全てのメンバが、他の全てメンバからデジタル署名を取得し、このコンセンサス順序を裏書きする。
１ゴシップ期間後：全てのメンバが、イベントを受信した
２ゴシップ期間後：全てのメンバが、それらのイベントの順序に合意する
３ゴシップ期間後：全てのメンバが、合意に達したことを知る
４ゴシップ期間後：全てのメンバが、他の全てメンバからデジタル署名を取得し、このコンセンサス順序を裏書きする。
【0178】
証明：Ｓ０を、所与の時間Ｔ０までに作成及び／又は定義されたイベントのセットとする。全てのメンバが最終的に他の全てのメンバと無限に頻繁に同期する場合、１の確率で、最終的にＳ０内のイベントが全てのメンバに拡散した時間Ｔ１が存在し、それにより全てのメンバが全てのイベントを認識するようになる。これが第１のゴシップ期間の終わりである。Ｓ１を、時間Ｔ１に存在し、かつＴ０にはまだ存在しなかったイベントのセットとする。次に、１の確率で、全てのメンバがセットＳ１内の全てのイベントを受信した時間Ｔ２が最終的に存在し、これは時間Ｔ１に存在したものである。これが第２のゴシップ期間の終わりである。同様に、Ｔ３は、Ｔ２までに存在するがＴ１の前には存在しないＳ２内の全てのイベントが、全てのメンバに拡散するときである。各ゴシップ期間は、最終的に１の確率で終了することに留意されたい。平均して、ｎ個のメンバがある場合、各々は、ｌｏｇ２（ｎ）回の同期を実施するのに要するだけ持続する。
【0179】
時間Ｔ１までに、全てのメンバは、Ｓ０内の全てのイベントを受信したことになる。
【0180】
時間Ｔ２までに、所与のメンバＡｌｉｃｅは、Ｓ０内の全てのイベントを受信している他のメンバの各々の記録を受信したことになる。したがって、Ａｌｉｃｅは、Ｓ０内の、全てのメンバについて全ての振る舞いのランク（そのメンバがその振る舞いを受信した順序）を算出し、次いで、ランクの中央値によってイベントをソートすることができる。結果として生じる全順序は、Ｓ０内のイベントに対して変化しない。これは、結果として生じる順序が、各メンバがそれらのイベントの各々の指標を最初に受信した順序の関数であり、その順序は変化しないからである。Ａｌｉｃｅの算出した順序は、Ｓ０イベントの間に散在するＳ１からのいくつかのイベントを有する可能性がある。それらのＳ１イベントは、それらがＳ０イベントのシーケンス内にある場合、依然として変化し得る。しかし、Ｓ０内のイベントの相対的な順序は変化しない。
【0181】
時間Ｔ３までに、Ａｌｉｃｅは、Ｓ０及びＳ１の和集合に関する全順序を学習し、その和集合におけるイベントの相対順序は変化しない。更に、Ａｌｉｃｅは、このシーケンス内で、Ｓ１からの最古のイベントを見つけることができ、Ｓ１の前のイベントのシーケンスは、Ｓ０以外の新しいイベントの挿入によってさえも変化しないと結論付けることができる。したがって、時間Ｔ３までに、Ａｌｉｃｅは、第１のＳ１イベントの前の履歴内のイベントの順序についてコンセンサスが達成されたと判断することができる。Ａｌｉｃｅは、この順序で発生するこれらのイベントから生じる状態のハッシュ（例えば、Ａｌｉｃｅによって定義されたデータベース状態変数によって捕捉される）にデジタル署名し、Ａｌｉｃｅが生成及び／又は定義する次のイベントの一部としてこの署名を送出することができる。
【0182】
時間Ｔ４までに、Ａｌｉｃｅは、他のメンバから同様の署名を受信したことになる。その時点で、Ａｌｉｃｅは、署名のそのリストを、署名が証明する状態とともに単に保持するだけでよく、Ａｌｉｃｅは、第１のＳ１イベントの前に記憶したイベントを破棄することができる。証明終わり。
【0183】
本明細書に説明されるシステムは、コンセンサスを迅速かつ安全に達成する分散データベースを説明する。これは、多くの用途に有用な構築ブロックであり得る。例えば、トランザクションが１つの暗号通貨ウォレットから別の暗号通貨ウォレットへの暗号通貨の送金を記述する場合、かつ状態が単に各ウォレット内の通貨金額のステートメントである場合、このシステムは、既存のシステムにおける費用のかかるプルーフオブワークを回避する暗号通貨システムを構成する。自動規則施行により、これが現在の暗号通貨では一般的でない特徴を追加することが可能となる。例えば、あるウォレットが一定期間にわたって暗号通貨を送信も受信もしない場合、そのウォレットが削除され、その値が他の既存のウォレットに、それらが現在保有している額に比例して分配される、という規則を施行することによって、失われたコインは復元され、デフレを回避することができる。このようにして、ウォレット用の秘密鍵が失われた場合であっても、マネーサプライは増大又は縮小しないであろう。
【0184】
別の例は、サーバ上でプレイされる多人数同時参加型オンライン（Massively Multiplayer Online、ＭＭＯ）ゲームのように振る舞うが、中央サーバを使用することなくそれを達成する分散ゲームである。コンセンサスは、いかなる中央サーバも制御されることなく、達成することができる。
【0185】
別の例は、そのようなデータベースの上に構築されるソーシャルメディアのためのシステムである。トランザクションはデジタル署名され、メンバは他のメンバについての情報を受信するので、これは、現在のシステムよりも優れたセキュリティ及び利便性の利点を提供する。例えば、電子メールは返信アドレスを偽造することができないので、強力なアンチスパムポリシーを有する電子メールシステムを実装することができる。そのようなシステムはまた、電子メール、ツイート、テキスト、フォーラム、ウィキ、及び／又は他のソーシャルメディアによって現在行われている機能を単一の分散データベースにおいて組み合わせて、統合されたソーシャルシステムになることもできる。
【0186】
他の用途には、グループが全体として協働して契約又は文書に署名する、グループデジタル署名などのより高度な暗号機能が含まれ得る。この形態及び他の形態のマルチパーティ計算は、そのような分散コンセンサスシステムを使用して有用に実装することができる。
【0187】
別の例に、公開台帳システムがある。誰もが、システムに何らかの情報を記憶するために料金を支払うことができ、１年につき１バイト当たりで少額の暗号通貨（又は現実世界の通貨）を支払い、システムに情報を記憶する。次いでこれらの資金は、そのデータを記憶するメンバと、合意を達成するために繰り返し同期して稼働するメンバとに自動的に分配することができる。これにより、メンバが同期するたびに、少額の暗号通貨をメンバに自動的に送信することができる。
【0188】
これらの例は、分散コンセンサスデータベースが多くの用途の構成要素として有用であることを示す。データベースは費用のかかるプルーフオブワークを使用せず、場合によってはより安価なプルーフオブステークを代わりに使用するので、データベースは、より小型のコンピュータ又はモバイル及び埋め込みデバイス上でさえ実行されるフルノードで実行することができる。
【0189】
２つ前のイベントのハッシュ（１つの自己ハッシュ及び１つの外部ハッシュ）を含むイベントとして上で説明されたが、他の実施形態では、メンバは、３つ前のイベントのハッシュ（１つの自己ハッシュ及び２つの外部ハッシュ）を含むイベントを作成及び／又は定義するために、２つの他のメンバと同期することができる。更に他の実施形態では、任意の数のメンバからの前のイベントの任意の数のイベントハッシュを、イベント内に含むことができる。いくつかの実施形態では、異なるイベントは、前のイベントの異なる数のハッシュを含むことができる。例えば、第１のイベントは、２つのイベントハッシュを含むことができ、第２のイベントは、３つのイベントハッシュを含むことができる。
【0190】
イベントは、前のイベントのハッシュ（又は暗号ハッシュ値）を含むものとして上で説明されたが、他の実施形態では、イベントは、ポインタ、識別子、及び／又は前のイベントへの任意の他の好適な参照を含むように作成及び／又は定義され得る。例えば、イベントは、前のイベントに関連付けられ、それを識別するために使用されるシリアル番号を含み、したがってイベントをリンクするように作成及び／又は定義することができる。いくつかの実施形態では、そのようなシリアル番号には、例えば、イベントを作成及び／又は定義したメンバに関連付けられた識別子（例えば、メディアアクセス制御（media access control、ＭＡＣ）アドレス、インターネットプロトコル（Internet Protocol、ＩＰ）アドレス、割り当てられたアドレス、及び／又は同様のもの）と、そのメンバによって定義されたイベントの順序とを含むことができる。例えば、１０という識別子を有し、イベントが、そのメンバによって作成及び／又は定義された１５番目のイベントであるメンバは、１０１５という識別子をそのイベントに割り当てることができる。他の実施形態では、イベントに識別子を割り当てるために、任意の他の好適なフォーマットを使用することができる。
【0191】
他の実施形態では、イベントは完全な暗号ハッシュを含むことができるが、同期中はそれらのハッシュの部分のみが送信される。例えば、ＡｌｉｃｅがＢｏｂにハッシュＨを含むイベントを送信し、ＪがＨの最初の３バイトであり、Ａｌｉｃｅが、Ａｌｉｃｅが記憶したイベント及びハッシュのうち、ＨがＪから始まる唯一のハッシュであると判定した場合、Ａｌｉｃｅは、同期中にＨの代わりにＪを送信することができる。次に、Ｂｏｂが、Ｊで始まる別のハッシュをＢｏｂが有すると判定した場合、Ｂｏｂは、Ａｌｉｃｅに返信して完全なＨを要求することができる。このようにして、ハッシュを、伝送中に圧縮することができる。
【0192】
上で図示及び説明された例示的なシステムは、他のシステムを参照して説明されるが、他の実施形態では、例示的なシステム及びそれらの関連付けられた機能の任意の組み合わせを実装して、分散データベースを作成及び／又は定義することができる。例えば、例示的なシステム１、例示的なシステム２、及び例示的なシステム３は、分散データベースを作成及び／又は定義するために組み合わせることができる。別の例として、いくつかの実施形態では、例示的なシステム１０は、例示的なシステム１は伴うが、例示的なシステム９を伴わずに、実装することができる。更に別の例では、例示的なシステム７は、例示的なシステム６と組み合わせて例示的なシステム６とともに実装することができる。更に他の実施形態では、例示的なシステムの任意の他の好適な組み合わせを実装することができる。
【0193】
様々な実施形態が上で説明されてきたが、それらが限定ではなく、例としてのみ提示されていることを理解されたい。上で説明される方法が、特定の順序で発生する特定のイベントを示す場合、特定のイベントの順序は修正され得る。追加的に、特定のイベントは、可能であれば並列プロセスで並行して実施され得、上で説明されるようにシーケンシャルに実施され得る。
【0194】
本明細書に説明されるいくつかの実施形態は、様々なコンピュータ実装動作を実施するための命令又はコンピュータコードを有する非一時的コンピュータ可読媒体（非一時的プロセッサ可読媒体とも称することができる）を含むコンピュータストレージ製品に関する。コンピュータ可読媒体（又はプロセッサ可読媒体）は、それ自体が一時的な伝搬信号（例えば、空間又はケーブルなどの伝送媒体上で情報を搬送する伝搬電磁波）を含まないという意味で、非一時的である。媒体及びコンピュータコード（コードとも称することができる）は、特定の目的のために設計及び構築されたものであり得る。非一時的コンピュータ可読媒体の例は、ハードディスク、フロッピーディスク、及び磁気テープなどの磁気ストレージ媒体、コンパクトディスク／デジタルビデオディスク（Compact Disc/Digital Video Disc、ＣＤ／ＤＶＤ）、コンパクトディスク読み出し専用メモリ（Compact Disc-Read Only Memory、ＣＤ－ＲＯＭ）、及びホログラフィックデバイスなどの光ストレージ媒体、光ディスクなどの光磁気ストレージ媒体、搬送波信号処理モジュール、並びに特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（Programmable Logic Device、ＰＬＤ）、読み出し専用メモリ（ＲＯＭ）、及びランダムアクセスメモリ（ＲＡＭ）デバイスなど、プログラムコードを記憶し、実行するように特に構成されているハードウェアデバイスを含むが、これらに限定されない。本明細書で説明される他の実施形態は、例えば、本明細書で考察される命令及び／又はコンピュータコードを含むことができるコンピュータプログラム製品に関する。
【0195】
コンピュータコードの例は、マイクロコード又はマイクロ命令、コンパイラによって生成されるような機械命令、ウェブサービスを生成するために使用されるコード、及びインタープリタを使用してコンピュータによって実行される高レベル命令を含むファイルを含むが、これらに限定されない。例えば、実施形態は、命令型プログラミング言語（例えば、Ｃ、Ｆｏｒｔｒａｎなど）、関数型プログラミング言語（Ｈａｓｋｅｌｌ、Ｅｒｌａｎｇなど）、論理型プログラミング言語（例えば、Ｐｒｏｌｏｇ）、オブジェクト指向型プログラミング言語（例えば、Ｊａｖａ、Ｃ＋＋など）、又は他の好適なプログラミング言語及び／又は開発ツールを使用して実装され得る。コンピュータコードの更なる例は、制御信号、暗号化コード、及び圧縮コードを含むが、これらに限定されない。
【0196】
様々な実施形態が上で説明されてきたが、それらが限定ではなく、例としてのみ提示されており、形態及び詳細における様々な変更が行われ得ることを理解されたい。本明細書に説明される装置及び／又は方法の任意の部分は、相互排他的な組み合わせを除いて、任意の組み合わせで組み合わされ得る。本明細書に説明される実施形態は、説明される異なる実施形態の機能、構成要素、及び／又は特徴の様々な組み合わせ及び／又は部分組み合わせを含むことができる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10A】
【図10B】
【図11A】
【図11B】
【図12A】
【図12B】
【図13A】
【図13B】
【図13C】
【図13D】
【図13E】
【図14】
【図15】
【図16】
【国際調査報告】